Integrar TMS o WMS con tu ERP: cómo hacerlo sin parar la operación
Los patrones de integración que funcionan en logística, los errores más frecuentes y cómo diseñar una conexión ERP-TMS o ERP-WMS que aguante en producción.
La integración entre el ERP y el TMS o WMS es el componente técnico que más frecuentemente convierte un proyecto de software logístico exitoso en uno problemático. No porque sea imposible — sino porque se suele diseñar mal o demasiado tarde.
Este artículo explica los patrones de integración que funcionan en producción, los errores que hacen que las integraciones se rompan, y cómo diseñar la conexión desde el principio para que sea mantenible.
Por qué se rompen las integraciones ERP-TMS/WMS
El patrón de integración más frecuente — y el más frágil — es el fichero: export CSV del ERP, import en el TMS o WMS, y vuelta atrás. Funciona en el piloto, donde todo el mundo está pendiente y los formatos son estables. Se rompe en producción cuando: el ERP actualiza la versión y cambia el formato de export, alguien añade un campo obligatorio en el WMS que el ERP no genera, o la importación falla silenciosamente y nadie lo detecta hasta que hay una discrepancia de inventario.
La segunda causa más frecuente: la integración se diseña para el flujo feliz pero no para las excepciones. ¿Qué pasa si el ERP envía una orden con un artículo que no existe en el WMS? ¿Si el TMS intenta cerrar una ruta que el ERP ya ha cancelado? Sin gestión de errores explícita, estas situaciones producen datos inconsistentes que luego requieren corrección manual.
Los patrones de integración que aguantan en producción
API directa con contrato explícito: el ERP expone una API (REST o GraphQL) con documentación clara, el TMS/WMS la consume con un contrato de datos versionado. Cada cambio en el ERP que afecta al contrato dispara un proceso de actualización coordinado. Es el patrón más robusto cuando el ERP lo soporta.
Webhooks con reintentos: el ERP notifica eventos (nueva orden, cambio de estado, cancelación) a los sistemas que los necesitan. Los webhooks tienen reintentos automáticos y un log de eventos procesados. Este patrón es más reactivo que la API síncrona y escala mejor en operaciones con alto volumen de eventos.
Cola de mensajes para operaciones críticas: en operaciones donde no puede perderse ningún evento (movimientos de stock, documentos de transporte, cambios de estado de expedición), una cola de mensajes (RabbitMQ, AWS SQS) garantiza que cada evento se procesa exactamente una vez, aunque algún sistema esté temporalmente no disponible.
El patrón que nunca recomendamos: acceso directo a la base de datos del ERP desde el TMS/WMS. Parece más rápido y sencillo, pero crea un acoplamiento que hace imposible actualizar o cambiar cualquiera de los dos sistemas sin romper el otro.
Diseñar la integración desde el inicio, no al final
El error de proyecto más frecuente: construir el TMS o WMS como sistema independiente y "resolver la integración después". Cuando se llega al paso de integración, los modelos de datos ya están fijados y hay que hacer encaje de bolillos entre dos sistemas que no se diseñaron juntos.
La forma correcta: en la auditoría inicial, antes de diseñar ningún módulo, mapear exactamente qué datos fluyen entre el ERP y el nuevo sistema, en qué dirección, con qué frecuencia y con qué semántica. Eso determina el modelo de datos del nuevo sistema desde el día uno — y evita el rediseño a mitad de proyecto.
Los datos que casi siempre fluyen ERP → TMS/WMS: órdenes de transporte o de trabajo, maestro de artículos, maestro de clientes/destinatarios, tarifas. Los datos que fluyen TMS/WMS → ERP: confirmaciones de entrega o movimiento, documentos firmados, facturación de servicios, ajustes de stock. Cada uno de esos flujos tiene su propio contrato de datos que hay que definir antes de programar. Si quieres revisar la arquitectura de integración de tu proyecto, la auditoría técnica gratuita incluye ese análisis.