Cómo integrar Flexxus con Persat sin doble carga

Un técnico llega a un consorcio en Córdoba a retirar doce matafuegos para recarga. Anota el trabajo en Persat, carga al consorcio como cliente nuevo porque nunca lo habían facturado, arma el pedido de recarga. Perfecto: el trabajo de campo quedó documentado.

Después el papel llega a la oficina. Alguien abre Flexxus, busca al consorcio, no lo encuentra, lo da de alta de nuevo escribiendo el CUIT a mano, y retipea el pedido ítem por ítem para emitir la Nota de Pedido. Media hora. Y si en el medio se equivoca de cliente —porque hay tres razones sociales parecidas— el error queda en el ERP, que es donde vive la facturación.

Este artículo es sobre ese espacio entre los dos sistemas. Lo escribimos después de construir la integración entre Persat y Flexxus para Matafuegos Córdoba, que hoy mueve más de 600 pedidos de recarga por mes sin que nadie los cargue dos veces.

El problema no es Persat, y tampoco es el ERP

Los dos sistemas hacen bien lo suyo. Persat gestiona la operación en la calle: rutas, visitas, órdenes de trabajo, formularios que completa el técnico con el celular. Flexxus gestiona la administración: cuentas corrientes, catálogo, precios, comprobantes, facturación.

El problema aparece porque el negocio no está partido en dos. Un cliente nuevo es el mismo cliente en los dos lados. Un pedido tomado en la calle tiene que terminar en un comprobante. El precio que el técnico cotiza frente al cliente tiene que ser el precio real de la lista, no el que se acuerda de memoria.

Cuando no hay integración, el puente lo hace una persona. Y ese puente humano tiene tres costos que casi nunca se miden:

• Tiempo administrativo. Retipear pedidos y altas de clientes es trabajo puro de transcripción, sin valor agregado.
• Latencia. Entre que el técnico cierra el trabajo y el pedido está en el ERP pasan horas o días. La facturación se atrasa, la cobranza se atrasa.
• Errores silenciosos. Cotizar con un precio viejo, cargar el pedido al cliente equivocado, dar de alta un duplicado. Ninguno de los tres avisa cuando ocurre; aparecen después, en la factura o en la cuenta corriente.

Qué hay que sincronizar realmente: son tres dominios, no uno

El error más común al encarar una integración es pensarla como "pasar los datos". Los datos no son uno solo: son tres dominios distintos, con direcciones y frecuencias distintas, y cada uno tiene su propia lógica.

Fijate que las direcciones no coinciden. Los clientes van del campo a la administración, el catálogo va de la administración al campo. Si diseñás la integración como un único proceso que "sincroniza todo", te vas a encontrar peleando contra el modelo real del negocio. Conviene tratar cada dominio como un flujo independiente, con su propia frecuencia y su propio manejo de errores.

La decisión que define el proyecto: cómo se vincula un cliente con otro

Esta es la parte difícil, y es donde se define si la integración es confiable o si es una bomba de tiempo.

Persat y Flexxus tienen cada uno su propio identificador interno de cliente. No son el mismo número y no hay forma de que lo sean. Así que ante un cliente cargado en la calle, el integrador tiene que responder una pregunta incómoda: ¿este cliente ya existe en el ERP, o es nuevo?

Lo resolvimos con una cascada de criterios, de más fuerte a más débil:

1. CUIT exacto. Si el CUIT coincide, es el mismo cliente. Es el único criterio que consideramos definitivo.
2. Razón social, verificando CUIT. Si el nombre coincide, todavía chequeamos el CUIT antes de dar el vínculo por bueno.
3. Si no hay certeza, no se vincula. Se marca para revisión de una persona y no se toca nada en el ERP.

Ese tercer punto es el más importante y el que más se resiste a implementar, porque implica aceptar que el sistema a veces no resuelve solo. Pero la alternativa es peor. Un match por aproximación que se equivoca no genera un error visible: genera una modificación silenciosa sobre el cliente equivocado en el sistema de facturación. Eso se descubre semanas después, cuando alguien recibe una factura que no le corresponde.

La regla que aplicamos es simple: antes de modificar o dar de baja algo en el ERP, el vínculo tiene que ser confiable. Si no lo es, el sistema se frena y avisa. Frenarse es un resultado aceptable. Escribir sobre el cliente equivocado, no.

Que un aviso repetido no genere dos comprobantes

Toda integración basada en eventos va a recibir el mismo aviso dos veces. Puede ser porque la red falló y el emisor reintentó, porque un operador guardó el formulario dos veces, o porque alguien reprocesó algo a mano desde el panel. No es un caso raro: es el funcionamiento normal.

Si el integrador no está preparado, cada aviso duplicado se convierte en un comprobante duplicado en el ERP. Y limpiar comprobantes duplicados en un sistema de facturación es un trabajo tedioso.

La protección tiene dos partes:

• Un formulario ya procesado no genera un segundo comprobante. El integrador registra qué se generó a partir de qué, y si el aviso vuelve a llegar, reconoce que ya lo hizo y no lo repite.
• Un vínculo confirmado a mano no se pisa. Si una persona revisó un caso dudoso y resolvió a qué cliente del ERP corresponde, la próxima corrida automática respeta esa decisión.

El resultado práctico es que reprocesar un aviso es seguro. Y eso cambia la operación del día a día: cuando algo falla, el operador puede reintentar desde el panel sin llamar a nadie ni preguntar si "va a duplicar".

Tiempo real donde importa, cada seis horas donde alcanza

No todo necesita ser instantáneo, y forzar tiempo real donde no hace falta te sale caro en complejidad y en llamadas a la API.

Para clientes y pedidos usamos eventos: apenas pasa algo en el campo, Persat le avisa al integrador, que responde al instante y procesa el trabajo pesado por detrás. El operador no espera. Si el pedido no se puede armar, el motivo exacto vuelve a Persat donde el operador lo ve, y sale un aviso por mail, sin frenar el resto del trabajo.

Para el catálogo usamos una corrida cada seis horas que baja los productos de Flexxus, calcula el precio con IVA ya incluido y sube a Persat sólo lo que cambió. Un catálogo completo son miles de artículos; reenviarlos enteros cada vez es lento, caro y te choca contra los límites de la API. Comparar contra el estado anterior y mandar el delta convierte una corrida de horas en una de minutos.

El criterio general: usá eventos para lo que dispara una acción de negocio y no puede esperar; usá corridas programadas con delta para lo que es referencia y tolera unas horas de desfasaje. Cuando el circuito es de logística y lo que viaja son remitos, el balance cambia: lo contamos en cómo cerramos el circuito de entregas entre un ERP y Persat.

El caso: Matafuegos Córdoba

Matafuegos Córdoba es una empresa cordobesa de protección contra incendios: venta, recarga y mantenimiento de matafuegos, sistemas de detección y extinción, señalética y asesoramiento. Trabaja desde 2014 con empresas, instituciones, consorcios, comercios y municipios de todo el país.

Gestionaban el trabajo en la calle con Persat y lo administrativo con Flexxus. Dos sistemas que funcionaban bien por separado, con más de cinco técnicos en la calle y todo el trabajo de transcripción en el medio.

Después de la integración:

Los +600 pedidos mensuales son el número que más nos gusta, porque antes cada uno de esos pedidos era alguien retipeando en Flexxus lo que ya estaba escrito en Persat.

Qué mirar antes de encarar una integración así

Si estás evaluando conectar tu sistema de campo con tu ERP, estas son las preguntas que conviene responder antes de escribir una línea de código:

• ¿Qué sistema manda en cada dato? Para cada dominio tiene que haber una única fuente de verdad. Si los dos lados pueden editar lo mismo, vas a tener conflictos permanentes.
• ¿Con qué campo vas a vincular los clientes? Si no tenés un identificador fuerte y cargado con disciplina —en Argentina, el CUIT—, el proyecto empieza por limpiar datos, no por integrar.
• ¿Qué pasa cuando falla? Una integración sin registro de lo que hizo y sin forma de reintentar es una caja negra. Cuando algo salga mal, y va a salir, nadie va a poder explicar qué pasó.
• ¿Qué tolerancia de desfasaje tiene cada dato? Un precio puede estar cuatro horas atrasado. Un pedido, no.
• ¿Quién resuelve los casos dudosos? Tiene que haber una persona con un panel donde ver lo que quedó frenado y decidir.

Cómo lo hacemos en Nimbus

Somos partner de Persat y distribuidores de Flexxus, así que trabajamos los dos lados de esta integración: configuramos los circuitos en Persat, conocemos la API del ERP y construimos el motor de sincronización que los une.

No es un conector genérico de catálogo. Cada integración se diseña sobre el circuito real del cliente —qué se carga en la calle, qué comprobante tiene que salir, con qué criterio se vinculan las cuentas— y después la operamos: monitoreo, avisos cuando algo falla y un panel donde reenviar lo que quedó pendiente.

Si tu equipo trabaja en la calle con Persat y tu administración vive en otro sistema, el patrón se repite aunque el ERP cambie. Lo hicimos también con Calipso, para llevar deuda y cobranzas al vendedor, y cuando el circuito excede lo que resuelve un producto de fábrica entra desarrollo a medida.

¿Integrás Flexxus u otro ERP con Persat? Diseñamos y operamos integraciones a medida para que el dato viaje solo entre tu sistema de gestión y tu equipo en la calle. Contanos tu caso en sistemasnimbus.com/persat y te decimos en una llamada si tu circuito se puede automatizar y qué haría falta.