Volver a Ideas
Integraciones 8 min de lectura

Cómo integrar Calipso con Persat: deuda y cobranzas en la mano del vendedor

El vendedor entra a visitar a un cliente sin saber cuánto debe. Cómo conectamos el ERP Calipso de Frund Stark con Persat para llevar clientes geolocalizados, catálogo y cuenta corriente al campo, con una sincronización diaria que no toca el ERP.

S

Sistemas Nimbus

Publicado el 12/08/2026

Hay una escena que se repite en cualquier empresa con vendedores viajando: el vendedor está sentado frente al cliente, cerrando un pedido, y no sabe que ese cliente tiene tres facturas vencidas.

No es negligencia. La información existe, está impecable, y está en el ERP, en una pantalla de la oficina a seiscientos kilómetros. El vendedor tiene dos opciones: llamar a administración y esperar, o seguir adelante sin saber. Casi siempre elige la segunda, porque frenar la visita para hacer una llamada es incómodo delante del cliente.

El costo de esa escena es doble. Se pierde la oportunidad de cobrar en el momento —que es cuando más fácil es cobrar— y se toman pedidos de clientes que quizás deberían estar frenados.

Este artículo cuenta cómo resolvimos eso para Frund Stark, llevando la cuenta corriente de Calipso al mapa de Persat.

Qué necesita el vendedor cuando toca el timbre

Antes de hablar de arquitectura conviene definir qué información hace falta realmente. La tentación es sincronizar todo el ERP; la respuesta útil es más corta. Frente al cliente, el vendedor necesita tres cosas:

Dominio Qué se lleva al campo Para qué
Clientes y direcciones Cada dirección de entrega, geolocalizada Rutear la visita y llegar al lugar correcto
Catálogo Rubro, familia, precio y stock Cotizar con el precio real y no prometer lo que no hay
Cobranzas Saldo por moneda y comprobantes pendientes con importe, vencimiento y estado Saber si cobra, si vende, o las dos cosas

El tercero es el que menos se implementa y el que más cambia la conversación comercial. Un vendedor que abre la ficha del cliente en Persat y ve "debe 1.2 millones, dos facturas vencidas hace 40 días" no tiene la misma visita que uno que entra a ciegas.

Un detalle que parece menor: la deuda sigue al cliente, no a la dirección

Acá hay una trampa de modelado que vale la pena señalar, porque es fácil de pasar por alto y arruina la funcionalidad.

En el ERP, la cuenta corriente es del cliente: una razón social, un CUIT, un saldo. En la herramienta de campo, en cambio, la unidad es el punto en el mapa: cada dirección de entrega es una parada distinta.

Si mapeás la deuda a la dirección, aparece el problema: un cliente con cuatro sucursales tiene la deuda cargada en una sola de ellas, probablemente la casa central. El vendedor que visita el depósito de otra provincia abre la ficha y ve saldo cero. Técnicamente el dato está bien; funcionalmente es inútil, porque el vendedor está parado justo donde no aparece.

La regla que aplicamos: el mismo saldo y los mismos comprobantes pendientes se muestran en todas las direcciones del cliente. El vendedor llega a cualquier sucursal y ve la situación real de la cuenta.

Es una decisión chiquita en código y grande en adopción. Este tipo de detalles —dónde vive el dato desde la perspectiva de quien lo usa— es lo que separa una integración que el equipo usa de una que el equipo ignora.

Sincronización diaria: cuándo alcanza y por qué conviene

No todas las integraciones necesitan tiempo real. Esta corre una vez por día y está bien que así sea.

La pregunta correcta no es "¿cuán rápido puede ser?" sino "¿cuánto desfasaje tolera el negocio?". Para una fuerza de ventas que planifica visitas, un dato de hasta 24 horas de antigüedad es perfectamente utilizable: la deuda de ayer a la noche es la deuda relevante para la visita de hoy. Forzar tiempo real ahí agrega complejidad, costo de infraestructura y carga sobre el ERP sin mejorar ninguna decisión. Hay circuitos donde sí se justifica —cuando el dato dispara una acción inmediata, como en el circuito de entregas que cerramos entre un ERP y Persat— pero una fuerza de ventas no es uno de ellos.

Ahora, "diario" no significa "bruto". La corrida hace cuatro cosas en orden:

  1. Lee Calipso en modo solo lectura y detecta qué cambió desde la última vez.
  2. Envía únicamente el delta. Un mecanismo de comparación evita reenviar lo que ya estaba igual, respetando el límite de la API de Persat. Esto convierte una corrida de horas en una de minutos.
  3. Geolocaliza las direcciones nuevas, validando que caigan dentro de Argentina.
  4. Actualiza deuda y comprobantes, reconciliando la lista: agrega los nuevos, actualiza los que cambiaron y quita los que ya se cobraron.

El paso 4 merece una aclaración. Reconciliar no es lo mismo que agregar. Si sólo agregás comprobantes pendientes, el vendedor termina viendo facturas que el cliente ya pagó, y a la tercera vez que le pasa deja de confiar en la pantalla. Una lista de pendientes tiene que borrar lo que se cobró con la misma disciplina con la que agrega lo que se venció.

Leer el ERP sin tocarlo

Una integración contra un ERP de producción se juega la confianza en el primer mes. Si el equipo de administración sospecha que el proceso puede modificar algo, la integración se cancela antes de demostrar su valor.

Por eso este integrador es de una sola dirección: Calipso nunca se modifica. Se lee en modo solo lectura y se escribe únicamente en Persat. Cuando el flujo de datos es del ERP hacia el campo y no al revés, no hay razón para pedir permisos de escritura sobre el sistema donde vive la facturación.

A eso le sumamos dos cosas más:

  • Salvaguardas contra borrados accidentales de datos maestros. Si una corrida trae inesperadamente cero clientes —porque falló la conexión o cambió una consulta—, el sistema no interpreta eso como "borrá todo".
  • Trazabilidad total. Cada corrida queda registrada paso a paso, con historial y capacidad de deshacer lo enviado. Si algo salió raro, se puede reconstruir qué pasó y revertirlo.

Hay una única vía de retorno, y es de respeto al trabajo del equipo: si un operador corrige a mano la ubicación de un punto en Persat, el integrador la reconoce y no la pisa en la siguiente corrida. Las direcciones que vienen del ERP muchas veces geolocalizan mal, y la persona que conoce el terreno arregla el punto en el mapa. Si el proceso automático le borra esa corrección todas las noches, la corrección deja de hacerse y el mapa queda mal para siempre.

El caso: Frund Stark

Frund Stark S.A. es una industria metalúrgica de Rafaela, Santa Fe, con más de 85 años y cuatro generaciones de trayectoria. Se especializa en herramientas de corte para madera, aluminio, PVC y metal: fabrica, comercializa y repara, con marcas propias y representadas, y atiende clientes en todo el país.

Gestionan clientes, catálogo y cuenta corriente en Calipso. Su equipo de más de cinco vendedores repartidos por el país trabajaba sin ese dato en la mano: para saber cuánto debía un cliente o dónde quedaba exactamente una sucursal, había que volver a la oficina o llamar por teléfono.

Indicador Resultado
Dominios sincronizados 3 (clientes, catálogo y cobranzas)
Vendedores en todo el país con datos al día +5
Frescura máxima del dato 24 h
Clientes del ERP reflejados en Persat ~2.400
Visibilidad de la deuda En todas las direcciones del cliente
Doble carga 0

Qué mirar antes de llevar la cuenta corriente al campo

  • ¿El saldo es uno o son varios? Si trabajás en pesos y dólares, la deuda no es un número: es un número por moneda. Aplanarlo a uno solo genera conversaciones incómodas con el cliente.
  • ¿Qué es un "comprobante pendiente" en tu ERP? Parece obvio y no lo es. Hay que definir con administración qué estados entran, qué pasa con las notas de crédito y qué con los pagos a cuenta no imputados.
  • ¿Querés que el vendedor vea todo? A veces la respuesta es que no: se muestra el saldo pero no el detalle, o se muestra sólo lo vencido. Es una decisión comercial que conviene tomar antes de desarrollar.
  • ¿Tus direcciones geolocalizan? Si están escritas de cualquier forma, hay una etapa previa de normalización. Y hace falta un lugar donde una persona pueda corregir a mano, con la garantía de que su corrección sobrevive.
  • ¿Con qué frecuencia cambia realmente el dato? Si la respuesta es "una vez por día", no construyas tiempo real.

Cómo lo hacemos en Nimbus

Somos partner de Persat y desarrollamos el motor de sincronización a medida contra el ERP que ya tenés. Con Calipso trabajamos en modo solo lectura, sin pedirle al cliente que modifique nada de su sistema de gestión.

Nuestro trabajo no termina en el desarrollo: la integración queda operada, con registro de cada corrida y avisos cuando algo falla. Y si además querés convertir esos datos operativos en tableros de gestión, es lo que hacemos con Nimbus BI. Cuando el circuito requiere algo que ningún producto resuelve de fábrica, entra desarrollo a medida.

Sobre Persat publicamos también el otro circuito que resolvimos: Flexxus, para que los clientes y pedidos cargados en la calle lleguen solos a la administración.

¿Tu equipo comercial sale a la calle sin la cuenta corriente? Si tu ERP tiene el dato y tus vendedores no lo tienen en la mano, se puede resolver sin tocar tu sistema de gestión. Escribinos en sistemasnimbus.com/persat y en una llamada te decimos qué se puede sincronizar de tu ERP y en cuánto tiempo.

¿Te quedó alguna duda?

Contanos tu caso y vemos juntos cómo resolverlo.

Hablemos de tu caso