Cómo integrar EDIFACT IFTMIN con tu TMS, paso a paso

Si tu equipo de logística lleva semanas peleándose con un pack de onboarding EDI lleno de códigos de segmento y cualificadores que nadie en la empresa sabe interpretar, esto te va a sonar familiar. La integración EDI transportista TMS vía EDIFACT IFTMIN/IFTSTA sigue siendo, en 2026, el camino obligatorio para conectar con la mayoría de transportistas de carretera europeos, y este artículo explica cómo montarla de principio a fin, desde la MIG del transportista hasta el go-live.

Por qué EDIFACT sigue siendo el idioma de tus transportistas en 2026

Porque siguen sin aceptar otra cosa. La mayoría de los transportistas de carretera europeos todavía no acepta una reserva a través de una API REST limpia: quieren un mensaje EDIFACT IFTMIN, y devuelven las actualizaciones de estado como IFTSTA. No es una cuestión de gustos tecnológicos, es que sus sistemas internos siguen construidos sobre EDIFACT y así seguirá siendo mientras no cambien de plataforma.

En España, este intercambio no es un acuerdo informal entre dos empresas. Existen organismos miembros de GS1 Internacional en cada país encargados de regular y adaptar el estándar a las necesidades del escenario nacional, y ese es el papel que juega la Asociación Española de Codificación Comercial (AECOC), ahora GS1 España. El estándar EANCOM que gestiona está compuesto por guías de implantación detalladas de los mensajes UN/EDIFACT, y es un subset totalmente compatible con el estándar EDIFACT completo. Esto significa que cuando negocias con un transportista español o que opera en España, probablemente ya trabajarás sobre una base EANCOM, no sobre EDIFACT puro.

Qué necesitas antes de empezar

Antes de mapear un solo segmento necesitas cinco piezas encima de la mesa: la MIG (Message Implementation Guide) específica del transportista con su versión exacta, tus propios identificadores GLN o ID EDI, el canal de conectividad confirmado, acceso a un entorno de certificación, y el mapeo previo desde tu TMS o ERP.

• La MIG del transportista, no la especificación genérica UN/EDIFACT. Es el documento propio del transportista, no el estándar genérico, y hay que confirmar la versión exacta: D.96A y D.21A siguen siendo comunes en producción a pesar de que existan versiones más recientes.
• Tus identificadores propios. GLN o IDs EDI asignados por el transportista para cada expedidor, consignatario y punto de origen/destino.
• El protocolo de conectividad exacto: AS2, SFTP o VAN, con credenciales confirmadas por escrito.
• Un entorno de certificación real del transportista, no solo documentación en PDF.
• El mapeo desde tu TMS/ERP (SAP, Oracle, Microsoft Dynamics) hacia la estructura del transportista.

Sobre protocolos, no hay un único camino válido. Una plataforma EDI compatible debe soportar cualquier estándar o protocolo: AS2, OFTP2, SFTP, EDIFACT, X12 o VDA, y conectarse con SAP, Oracle, Microsoft Dynamics o cualquier ERP, WMS o TMS sin modificar tus sistemas internos, algo que ofrecen proveedores como EDICOM. Si trabajas con pocos transportistas de alto volumen, AS2 directo suele bastar; si la lista es larga y heterogénea, una VAN simplifica el mantenimiento.

Paso a paso: cómo montar la integración IFTMIN/IFTSTA

El proceso completo tiene ocho pasos, desde pedir la MIG hasta medir si la conexión aguanta en producción.

1. Solicita al transportista su MIG específica de IFTMIN/IFTSTA, con versión y lista completa de segmentos exigidos. No asumas que el "estándar" que te envían es el mismo que usó otro transportista el mes pasado.
2. Confirma tus GLN/ID EDI y el canal de conectividad exacto (AS2, SFTP o VAN) por escrito con el contacto de integración del transportista, no por email informal.
3. Mapea los segmentos clave desde tu TMS/ERP a la estructura IFTMIN del transportista. El mensaje IFTMIN transporta ubicaciones de recogida y entrega, mercancía, pesos y nivel de servicio, referenciando el envío comercial; el segmento NAD identifica expedidor, consignatario y transportista, mientras que TDT y EQD describen el modo de transporte y las necesidades de equipamiento. Añade BGM, LOC, DTM y RFF a tu checklist de mapeo.
4. Prueba con un envío real no productivo en el entorno de certificación del transportista, no en producción directamente.
5. Trata un CONTRL negativo como un fallo de segmento o cualificador a corregir, nunca como un fallo de envío. Es la forma en que el sistema del transportista te dice exactamente qué campo no cumple su MIG.
6. Mapea los códigos de evento de IFTSTA entrantes a tu propio conjunto de hitos internos. La captura de la prueba de entrega cierra el servicio de transporte, existen estados multitramo para combinaciones aéreo-marítimas, y una plataforma de visibilidad agrega los mensajes IFTSTA hacia el portal del cliente.
7. Ejecuta un periodo en paralelo contra tu proceso actual antes del cutover. Envía los mismos envíos reales por el nuevo flujo EDI y por tu proceso manual o de portal existente al mismo tiempo, y reconcilia los timestamps de estado y los datos de POD entre ambos antes de tocar el interruptor del cutover.
8. Mide dos señales de éxito tras el go-live. Sal a producción y monitoriza: vigila las tasas de acuse y la completitud de IFTSTA en un dashboard, porque el silencio del sistema del transportista no es lo mismo que éxito, es una señal que hay que investigar, no una prueba de que todo va bien.

Cómo saber que funcionó

Dos números te dicen si la conexión está lista para producción, no solo teóricamente viva. Tu tasa de acuse CONTRL sobre el IFTMIN saliente debería situarse en o cerca del 100%: cualquier cifra por debajo significa que hay ficheros fallando silenciosamente la validación estructural en el lado del transportista. El CONTRL es el acuse técnico de recibo, así que si no llega, tu mensaje puede haberse perdido sin que lo sepas.

La segunda señal es la completitud del IFTSTA: cada hito acordado (recogida, tránsito, entrega, POD) debe llegar dentro del SLA pactado en el onboarding. Si faltan hitos de forma sistemática, el problema suele estar en el mapeo de códigos de evento, no en la conectividad.

Un fallo habitual: el "EDIFACT-compliant" que no lo es

Que un transportista diga "somos EDIFACT-compliant" no garantiza que su estructura sea idéntica a la de otro transportista que dice exactamente lo mismo. Los requisitos exactos de segmento dependen del directorio de mensajes (D.96A, etc.) y de la guía de implementación de tu socio comercial. Cada MIG puede tener su propio dialecto dentro del mismo estándar. La solución no es asumir compatibilidad entre transportistas: testea cada uno de forma individual, documenta las diferencias encontradas y usa tu primer build como plantilla reutilizable para el siguiente, no como copia exacta.

Un segundo fallo habitual aparece cuando el volumen de IFTSTA crece: latencia alta o mensajes duplicados en los hitos de estado. La solución pasa por procesamiento idempotente en tu TMS y deduplicación por referencia de control del mensaje, para que un mismo evento no dispare dos actualizaciones distintas en tu sistema interno.

Cuándo escalar de EDI punto a punto a una capa de conectividad multi-transportista

Replicar este proceso transportista por transportista no escala bien cuando trabajas con decenas de ellos, cada uno con su MIG, su dialecto y su protocolo. Aquí es donde entra la decisión entre seguir con conexiones 1:1 o adoptar una capa "hub" que centralice EDI y API desde un único punto de integración.

La diferencia no es solo de comodidad. Elige EDI cuando gestionas rutas estables de alto volumen con relaciones de transportista ya establecidas: aunque sea un proceso "más antiguo", sigue existiendo porque es rentable y funciona de forma fiable. Pero plataformas como Cargoson, junto con soluciones de Transporeon y nShift, han respondido ofreciendo capacidades de doble modo, permitiendo que datos críticos de auditoría sigan por EDI mientras otros flujos se gestionan vía API. Si tu cartera de transportistas ya supera la docena, vale la pena evaluar una de estas capas de conectividad como Cargoson, EDICOM, Transportial o el propio módulo EDI de tu ERP antes de firmar la vigésima integración punto a punto.

Checklist final antes de dar por cerrado el proyecto

• MIG del transportista confirmada, con versión exacta documentada
• GLN/ID EDI propios validados por escrito con el transportista
• Mapeo de BGM, NAD, TDT, LOC, DTM y RFF completado y probado en certificación
• Periodo en paralelo ejecutado y reconciliado contra el proceso anterior
• Tasa de acuse CONTRL cercana al 100% en producción
• Completitud de IFTSTA dentro del SLA pactado, con procesamiento idempotente activo
• Diferencias de dialecto documentadas para reutilizar en el siguiente transportista

Con esta lista cerrada, el siguiente transportista que incorpores debería tomarte una fracción del tiempo que te llevó el primero. Si no es así, el problema no está en EDIFACT, está en que sigues tratando cada integración como un proyecto desde cero.