Del remito del ERP a la app del chofer: cómo cerrar el circuito de entregas

En casi todas las empresas que reparten mercadería propia, el circuito de entrega está cortado en dos lugares.

El primer corte es a la salida. El ERP sabe perfectamente qué hay que entregar: tiene los remitos pendientes, el cliente, la sucursal, la dirección. Pero esa información no llega sola a la app que usa el chofer —en este caso, Persat. Alguien la carga a mano, o la exporta a una planilla, o —más común de lo que parece— el chofer sale con los remitos impresos y se arregla.

El segundo corte es a la vuelta, y es peor. El chofer entregó, entregó parcial o no pudo entregar. Esa información existe, el chofer la sabe, pero volver a escribirla en el ERP depende de que alguien la transcriba al final del día. A veces se hace tarde. A veces no se hace.

Mientras el circuito está cortado, la oficina no sabe qué pasó en la calle hasta que termina el día. Y el ERP —que es donde se factura y se controla— tiene un estado que no es el real.

Este artículo cuenta cómo cerramos ese circuito para Empack, integrando su ERP CDI con Persat.

Por qué el retorno es la mitad difícil

Empujar datos hacia el campo es la parte fácil. Leés los remitos pendientes del ERP, los creás como entregas en la app, listo. Si falla, lo reintentás en la próxima corrida y no pasó nada grave.

El retorno es otra cosa. Cuando el chofer cierra una entrega, ese evento ocurre una sola vez. Si el aviso se pierde —se cayó la red, el servidor estaba reiniciando, el ERP no respondió— nadie lo va a volver a generar. La entrega quedó cerrada en la app y pendiente en el ERP, y esa diferencia no se arregla sola. Peor: nadie se entera de que existe.

Por eso el diseño del retorno necesita tres cosas que el camino de ida no necesita:

• Reintentos. Si el ERP no responde en el momento, el aviso se vuelve a intentar en vez de descartarse.
• Una corrida de recuperación. Cada tanto, un proceso compara lo que está cerrado en el campo contra lo que el ERP tiene registrado, y reenvía lo que quedó colgado. Es la red que atrapa lo que se escapó de los reintentos.
• Registro de todo. Cada aviso recibido y cada escritura al ERP queda con su detalle, para poder responder "¿qué pasó con esta entrega?" sin adivinar.

Si vas a construir una integración bidireccional y tenés que elegir dónde poner el esfuerzo de ingeniería, ponelo acá.

Quién manda cuando los dos sistemas dicen cosas distintas

Hay una situación que aparece siempre y que conviene resolver por diseño, no por parche.

El chofer marca la entrega como entregada. El aviso viaja al ERP. Pero el ERP, por su propio ciclo interno, sigue informando ese remito como pendiente durante un rato. La próxima corrida lee el ERP, ve el remito pendiente y —si nadie definió una regla— vuelve a crear la entrega o la reabre. El chofer ve reaparecer un trabajo que ya hizo.

La regla que aplicamos: una entrega ya cerrada no se revierte, aunque el ERP la siga informando como pendiente. El trabajo del chofer manda sobre el estado del ERP en ese punto del circuito.

Es una decisión de negocio disfrazada de decisión técnica, y por eso conviene tomarla explícitamente y escribirla. Cuando el flujo va en el sentido contrario —del campo hacia la administración— el criterio también cambia, y lo desarrollamos en cómo integramos Flexxus con Persat. En cada dominio de la integración tiene que quedar claro qué sistema gana ante un desacuerdo. Si no lo definís, la respuesta termina siendo "gana el último proceso que corrió", que es la peor de todas porque cambia según la hora.

Al mismo tiempo hay que cubrir el caso inverso. Si alguien borra a mano un cliente o una sucursal en Persat, el integrador lo detecta en la próxima corrida y lo vuelve a crear. Los datos maestros vienen del ERP y se reconstruyen solos; el resultado del trabajo de campo, no se pisa.

El circuito completo, paso a paso

Así queda armado el flujo cuando las dos direcciones funcionan:

El paso 2 corre automático cada pocos minutos, así que un remito cargado a la mañana está disponible para asignar casi enseguida. El paso 4 es instantáneo: no espera al cierre del día.

El paso 6 parece menor y es el que más se nota en la operación. Un resumen diario por mail —uno general para la oficina y uno por vendedor con sólo sus entregas— convierte la integración en algo visible. Sin ese mail, cuando todo funciona bien nadie se entera de que hay una integración; con el mail, el equipo tiene todos los días un espejo de lo que pasó en la calle.

Cuando el ERP no es uno solo

Un detalle que aparece en empresas que crecieron por partes: el ERP puede tener más de un sistema o más de una razón social conviviendo. En el caso de Empack son dos, Empack y Almax, cada uno con su propia cartera de clientes.

Desde el lado del chofer eso no debería existir. El chofer tiene una hoja de ruta con paradas; no le importa de qué sistema vino cada cliente. El integrador se encarga de leer los dos, unificarlos y publicarlos en Persat como un único conjunto de clientes y sucursales.

Vale la pena preguntarlo temprano en cualquier proyecto de integración: ¿el ERP es uno, o son varios que se ven como uno? La respuesta cambia el diseño, y si aparece a mitad del desarrollo, obliga a rehacer la capa de datos maestros.

El caso: Empack

Empack es una empresa de embalaje industrial con más de 30 años de trayectoria, desde 1991. Importa, fracciona y comercializa film stretch, polietileno con burbujas, cintas, papel panal y máquinas de embalaje, con distribución a todo el país desde su planta en el Parque Industrial Tortuguitas, Buenos Aires.

Gestionan la operación sobre el ERP CDI, con dos sistemas —Empack y Almax— y un equipo de reparto que lleva el pedido hasta el cliente final. Antes de la integración, las entregas se cargaban a mano en la app de logística, el chofer salía sin sus paradas geolocalizadas y el resultado de cada entrega volvía tarde al ERP, o no volvía.

El número que cambia la operación no es el de clientes, es el "tiempo real" de la anteúltima fila. Que el estado de cada entrega vuelva al ERP en el momento significa que la oficina puede facturar, reclamar o reprogramar el mismo día, no al siguiente.

Qué mirar antes de encarar el circuito de entregas

• ¿Qué condición define que un remito está listo para entregar? Tiene que ser un estado concreto y consultable en el ERP, no un criterio que vive en la cabeza de alguien.
• ¿Tus clientes tienen dirección geolocalizable? Si las direcciones están escritas de cualquier forma, la primera etapa del proyecto es normalizarlas. Un punto mal ubicado en el mapa le hace perder media hora al chofer.
• ¿Qué estados de cierre necesitás? Entregada, parcial y no entregada suele ser el mínimo. Cada uno tiene que tener su equivalente exacto en el ERP, y esa traducción hay que definirla con administración, no con sistemas.
• ¿El ERP acepta que le escriban? Muchos ERP se dejan leer con facilidad y son mucho más restrictivos para recibir escrituras. Conviene confirmarlo antes de prometer un circuito cerrado.
• ¿Quién mira que el circuito esté sano? Aunque todo sea automático, alguien tiene que recibir un aviso cuando algo queda trabado.

Cómo lo hacemos en Nimbus

Somos partner de Persat y construimos el motor de sincronización que lo conecta con el ERP que ya tenés. En este caso fue CDI; el patrón se repite con otros sistemas de gestión, porque lo que cambia es la API, no el circuito.

Lo que aportamos no es sólo el desarrollo: es el diseño del circuito —qué estado dispara qué, qué gana ante un desacuerdo, qué pasa cuando falla— y después la operación, con monitoreo, reintentos y avisos. Si tu caso además necesita tableros para ver la performance de la operación en la calle, lo llevamos a Nimbus BI.

Publicamos también cómo resolvimos el tercer circuito sobre Persat: Calipso, para llevar deuda y cobranzas al vendedor en la calle.

¿Tus entregas todavía viajan en planillas? Si el ERP sabe qué hay que entregar pero la calle se entera a mano, hay un circuito para cerrar. Escribinos en sistemasnimbus.com/persat y lo miramos juntos: en una llamada te decimos qué parte se puede automatizar y qué haría falta de tu ERP.