Cómo integrar IFTSTA en tu TMS para visibilidad real

Qué es IFTSTA y por qué determina tu nivel real de visibilidad

IFTSTA es el mensaje UN/EDIFACT que reporta el estado del transporte y sus cambios de estado (evento) entre las partes acordadas, tal como lo define el estándar de UN/ECE para la versión D03A. En términos prácticos: es el mensaje que le dice a tu TMS que un envío ha sido recogido, ha salido de almacén, está en tránsito o se ha entregado. Sin él, tu equipo de logística sigue dependiendo de llamadas de comprobación y hojas de Excel actualizadas a mano.

IFTSTA es el mensaje UN/EDIFACT usado para reportar el estado del transporte de un envío o su equipo en hitos definidos: reservado, recogido, cargado en puerto, cargado, salido, llegado, descargado, entregado, y es el mensaje de seguimiento del mundo del transporte multimodal y forwarding. Cada IFTSTA lleva la referencia del envío, el código de estado y la razón, la ubicación y la fecha/hora del evento. Si ya has trabajado con el IFTMIN (la orden de transporte que le envías al transportista), IFTSTA es su contraparte: la respuesta que cierra el ciclo. De hecho, IFTMIN puede combinarse con hitos IFTSTA hasta la prueba de entrega, formando el par de mensajes que sostiene toda la relación EDI con un transportista de carretera europeo.

La razón por la que sigue siendo tan relevante en 2026 es simple: la mayoría de transportistas de carretera europeos todavía no aceptan una reserva a través de una API REST limpia, quieren un mensaje EDIFACT IFTMIN, y devuelven las actualizaciones de estado como IFTSTA. Esto no es una preferencia técnica caprichosa. Es la infraestructura real sobre la que operan cientos de transportistas de carretera, sobre todo en automoción, industrial y gran consumo, sectores que estandarizan en EDIFACT para plantas y proveedores fuera de Norteamérica.

Qué necesitas antes de empezar: checklist de prerrequisitos

Antes de escribir un solo mapeo, necesitas cinco piezas en su sitio. Saltarte alguna significa rehacer trabajo en la tercera semana, cuando ya creías tener el proyecto avanzado.

• La Guía de Implementación del Mensaje (MIG) del transportista, no el estándar genérico. El documento propio del transportista, no la especificación genérica de UN/EDIFACT, porque cada transportista interpreta el estándar a su manera.
• Confirmación de la versión de directorio exacta. D.96A y D.21A siguen siendo comunes en producción a pesar de que existen versiones más nuevas. No asumas que todos tus transportistas usan la misma.
• Identificadores propios. Necesitas GLN o IDs EDI asignados por el transportista para cada centro de expedición y de entrega, que se usarán en los segmentos NAD y LOC.
• Canal de conectividad confirmado. AS2, SFTP o suscripción a un VAN, con los certificados o credenciales intercambiados por escrito.
• Un traductor o mapeador EDI entre tu TMS/ERP y la conexión del transportista, ya sea nativo (como el módulo EDI de SAP TM) o de un proveedor externo.

Paso a paso: configurar el flujo IFTSTA con tu TMS

Con los prerrequisitos listos, el trabajo se reduce a mapear campos, definir hitos, montar el canal y probar antes de escalar. Así es como se hace, en orden:

1. Mapea los campos internos de tu TMS a los segmentos EDIFACT. El mensaje usa una estructura jerárquica: UNH abre la transacción, BGM lleva el nombre del documento y la referencia, los datos de las partes usan NAD, y los segmentos de fecha (DTM), ubicación (LOC) y código de estado completan el hito. Documenta esta correspondencia campo a campo en una hoja de mapeo, no solo en la cabeza del integrador.
2. Define los códigos de hito que necesitas. No pidas todos los códigos que existen en el estándar. Decide qué eventos son operativamente relevantes: recogida confirmada, salida de almacén, en ruta, incidencia (retraso, rechazo), y entrega con POD. Menos códigos bien entendidos superan a una lista exhaustiva que nadie interpreta igual.
3. Configura el canal AS2 o SFTP con el transportista. Esto implica intercambiar certificados AS2 o credenciales SFTP, y confirmar por escrito el AS2 ID o la dirección del buzón VAN con el contacto de integración del transportista.
4. Ejecuta mensajes de prueba en un entorno sandbox. Genera IFTSTA de ejemplo con datos ficticios pero estructuralmente reales y verifica que tu traductor los interpreta sin errores de parseo.
5. Valida contra la implementation guide real del transportista, no contra el estándar genérico. Aquí es donde suelen aparecer las primeras discrepancias entre lo que el transportista dice que envía y lo que realmente llega.
6. Activa en producción con un transportista piloto antes de escalar al resto de tu red. Un solo transportista con volumen medio te permite detectar problemas de mapeo sin bloquear toda tu operación de visibilidad.

Si trabajas con un TMS multicarrier tipo Cargoson conectado a tu ERP, o con SAP TM directamente, el traductor EDI suele integrarse como una capa intermedia que traduce IFTSTA entrante a los campos nativos de estado de envío de tu sistema, sin que el equipo de operaciones tenga que tocar segmentos EDIFACT nunca.

La alternativa y el complemento: API REST y webhooks de visibilidad

No todo el ecosistema de transporte vive en EDIFACT. Las plataformas de visibilidad han apostado por API y webhooks porque ofrecen algo que un lote EDI por definición no puede: notificación inmediata en el momento del evento. La API REST es más flexible y en tiempo real: el sistema consulta o recibe el dato bajo demanda, con webhooks que notifican los eventos como salida, llegada o documento disponible.

project44 es un ejemplo claro de este modelo aplicado a transporte por carretera. Gracias al seguimiento API, una sola integración permite transmitir automáticamente la ubicación a project44 para ofrecer visibilidad en tiempo real con ETA predictivos, y la plataforma puede recibir datos a través de sistemas API, EDI o CSV, lo que confirma que ambos mundos conviven en la práctica, no se sustituyen.

La recomendación que suele funcionar mejor no es elegir un bando, sino combinarlos según el volumen y la urgencia del dato. Muchos cargadores usan la API para el seguimiento y el EDI para los flujos masivos. Tiene sentido: EDI está probado, es robusto y ya lo exige tu transportista principal de carretera en Europa; API te da la inmediatez para excepciones críticas o para clientes finales que esperan un tracking tipo consumidor.

Cuando se trata de centralizar múltiples fuentes de tracking (GPS, EDI, API) en una sola capa de visibilidad, TMS multicarrier como Cargoson, junto con plataformas como Transporeon, MercuryGate o el propio project44, cumplen esa función de torre de control: reciben IFTSTA de unos transportistas y webhooks de otros, y presentan una vista unificada sin que el usuario de operaciones tenga que saber qué protocolo hay detrás de cada envío.

Cómo saber que funciona: verificación y KPIs de éxito

La integración funciona cuando el porcentaje de envíos con hitos IFTSTA recibidos correctamente supera un umbral objetivo, normalmente en torno al 95%, y cuando el tiempo entre el evento real y su registro en el TMS es consistente, no errático. Dos comprobaciones son innegociables antes de dar el proyecto por cerrado:

• Cobertura de hitos: revisa qué porcentaje de envíos activos está recibiendo al menos los hitos críticos (recogida, entrega) y cuáles se quedan huérfanos por fallos de mapeo o de conectividad.
• Deduplicación por referencia de control: en flujos de alto volumen, es habitual recibir el mismo hito repetido por reintentos del transportista. Sin una clave de deduplicación basada en la referencia de control del mensaje, tu TMS acumula duplicados que distorsionan cualquier reporting posterior.

El modo de fallo más común: el "dialecto" propio del transportista

Este es el problema que más tiempo consume en cualquier proyecto de integración IFTSTA, y casi nunca aparece en la documentación inicial del transportista. El transportista asegura seguir el estándar EDIFACT, pero su implementación real difiere del genérico en detalles que solo se descubren probando: campos opcionales que en la práctica son obligatorios, códigos de estado propios que no coinciden con el catálogo estándar, o segmentos LOC que esperan un formato de ubicación distinto al que documentaste.

La solución no es elegante, pero funciona: pide siempre la MIG específica del transportista, nunca te conformes con el estándar UN/EDIFACT genérico como referencia única. Testea con mensajes reales, no solo con ejemplos de manual, antes de mover nada a producción. Y mantén una tabla de mapeo de códigos de estado por transportista, porque el código que un transportista usa para "incidencia en aduana" puede no significar lo mismo en el sistema del siguiente.

Checklist final y próximos pasos

Antes de arrancar necesitas la MIG del transportista, la versión de directorio confirmada, tus identificadores GLN o EDI propios, el canal AS2/SFTP acordado y un traductor EDI operativo. Después, el camino es: mapear campos, definir hitos, configurar el canal, probar en sandbox, validar contra la MIG real y lanzar con un piloto antes de escalar. Combina esto con API y webhooks donde el transportista o la plataforma de visibilidad lo permita, y usa un TMS multicarrier como capa de consolidación si gestionas más de un puñado de transportistas con protocolos distintos.

Si todavía gestionas esta visibilidad transportista por transportista, sin una capa centralizada que unifique EDI y API, ese es probablemente tu siguiente cuello de botella, y vale la pena revisar antes las comparativas de TMS multicarrier que hemos publicado en este blog.