El EDI 214 es el mensaje que indica a un cargador dónde se encuentra una carga. Formalmente es el X12 Transportation Carrier Shipment Status Message, y toda la documentación que hay en internet está escrita pensando en Norteamérica, lo que supone un problema si sus rutas van de Róterdam a Milán. El transporte por carretera europeo utiliza un mensaje distinto para la misma función y, cada vez más, no utiliza ninguno de los dos, porque esos mismos datos llegan ahora mediante una API de visibilidad del transporte por carretera en tiempo real en su lugar.
Este es el mensaje de estado en los tres canales: qué información lleva el 214, qué hace EDIFACT en su lugar en Europa y qué aspecto tiene el equivalente en forma de evento.
Qué contiene realmente un 214
Un 214 es un informe, no una instrucción. Pertenece a una familia: el 204 ofrece la carga, el 990 la acepta o la rechaza, el 214 informa de qué ha pasado con ella y el 210 la factura. Enviar un 214 de una carga que nunca se ofreció es un error habitual y confuso al estrenar una conexión.
El contenido es más reducido de lo que da a entender toda la documentación que lo rodea. Tres cosas importan:
- La referencia que identifica el envío, que viaja en el segmento B10. Si la referencia del transportista y la suya no coinciden y no hay ninguna referencia cruzada, no se puede aprovechar nada más del mensaje.
- El estado en sí, que viaja en el AT7: un código de estado, un código de motivo opcional y una fecha y hora.
- Dónde ocurrió, que viaja en los segmentos de ubicación, normalmente como ciudad, provincia o región y país, en lugar de coordenadas.
Todo lo demás es opcional y la mayoría de las implementaciones lo ignoran.
Los códigos de estado que soportan el grueso del tráfico
La lista de códigos X12 abarca decenas de valores. En la práctica, alrededor de una docena concentran casi todo el tráfico real en una ruta de carga completa o de grupaje:
- X3 llegada al punto de carga
- CP carga finalizada en el punto de recogida
- AM cargado en el camión
- AF el transportista ha salido del punto de recogida con la mercancía
- X6 en ruta hacia el punto de entrega
- X2 fecha y hora estimadas de llegada al destinatario
- AG entrega estimada
- X1 llegada al punto de entrega
- D1 descarga finalizada en el punto de entrega
- CD el transportista ha salido del punto de entrega
- AH intento de entrega
- SD envío retrasado
- CA envío cancelado
Un código de retraso o de incidencia solo resulta útil si va acompañado de su código de motivo. Un SD por sí solo dice que la carga va con retraso, algo que el receptor ya sabe. Un SD con un motivo que distinga entre una cola en la frontera, una avería o un destinatario que ha cerrado antes de tiempo es lo que marca la diferencia entre un simple flujo de estados y un proceso real de gestión de incidencias.
Qué utiliza Europa en su lugar
X12 es un estándar norteamericano. El transporte por carretera europeo funciona con EDIFACT, y el mensaje de estado es IFTSTA, el International Multimodal Status Report. Convive con IFTMIN para la instrucción de transporte e IFTMAN para el aviso de llegada, con la misma lógica de familia que el conjunto X12.
Desde el punto de vista estructural, IFTSTA cumple las mismas tres funciones: una referencia que identifica el envío, un estado que viaja en el segmento STS con las listas de códigos UN/EDIFACT para el estado y su motivo, una ubicación en LOC y la información horaria en DTM. La Recomendación 24 de UN/CEFACT existe precisamente para armonizar los códigos de estado de comercio y transporte entre estas implementaciones.
El inconveniente es que la semántica de los códigos se acuerda en cada guía de implementación y no de forma universal. Dos transportistas pueden enviarle un IFTSTA perfectamente conforme a la norma y entender cosas muy distintas por un mismo estado, sobre todo en torno a qué cuenta como llegada: a la entrada, al muelle o en el momento en que el conductor lo comunica. Por eso cada mapeo EDI es un trabajo a medida con cada socio, aunque ambas partes cumplan el estándar, y por eso conectar al transportista número cuarenta cuesta lo mismo que conectar al cuarto.
Los mismos eventos a través de una API
Una API de visibilidad expresa los mismos hitos como eventos en lugar de como un fichero. El conjunto es deliberadamente reducido, porque un conjunto pequeño de eventos que todos los transportistas pueden generar vale más que uno completo que solo tres de ellos soportan: asignado, en ruta hacia la recogida, llegada a la recogida, cargado, salida de la recogida, en ruta hacia la entrega, llegada a la entrega, descargado, prueba de entrega capturada e incidencia notificada.
Hay tres diferencias que cambian el comportamiento de los datos, y ninguna de ellas es el formato.
El evento llega cuando ocurre. Un 214 o un IFTSTA viajan en un fichero sujeto a una ventana de transmisión. El evento existe en su sistema al cerrarse esa ventana, no en el instante en que el camión cruzó la entrada. Allí donde importa la diferencia entre un registro y la información en vivo, es la diferencia que se explica en la guía sobre track and trace en el transporte por carretera europeo.
La marca de tiempo puede generarse de forma automática. El cruce de una geocerca produce una hora de llegada que nadie ha tecleado. Un mensaje de estado introducido por un conductor o un planificador produce una hora de llegada que alguien ha tecleado, a menudo al final de la jornada, y si esa parte tuviera que pagar la paralización, eso no sirve como prueba.
La posición es continua y no puntual. Un mensaje de estado le dice que el camión ha alcanzado un hito. Un flujo de posición le dice dónde se encuentra entre hitos, que es justo lo que hace posible predecir la llegada, tal como se explica en el artículo sobre cómo el aprendizaje automático alcanza una alta precisión en la ETA.
Cómo relacionar los tres sin perder significado
Cualquier cargador que gestione canales mixtos acaba manteniendo una tabla de equivalencias. Cuatro reglas evitan que pierda fiabilidad.
- Normalice según sus propios nombres de evento, no según el código que recibe. Decida internamente qué significa «llegada a la entrega», en una sola frase, y asocie a esa definición el X1, el estado IFTSTA correspondiente y el evento de la API. Almacenar los códigos en bruto e interpretarlos al leerlos garantiza que dos equipos los interpreten de forma distinta.
- Registre el origen y el método de generación en cada evento. El canal y si la marca de tiempo procede de una geovalla, de una app para conductores de camión o de una entrada manual. Cada cifra de tiempo de permanencia, de paralización y de cumplimiento de plazos depende de esa distinción, y no puede reconstruirse después.
- Trate cada evento como reproducible. Los ficheros EDI se reenvían y los webhooks se reintentan. Sin una clave de idempotencia construida a partir de la referencia del envío, el estado y la hora del evento, un reenvío crea una segunda llegada y el cálculo del tiempo de permanencia se duplica sin que nadie lo note.
- Dé por hecho que los mensajes llegarán desordenados. Una salida puede llegar antes que la llegada a la que sigue. Ordene por hora del evento y no por hora de recepción, y rechace cualquier transición de estado que sea imposible en lugar de almacenarla.
La prueba de entrega es el único hito que conviene tratar por separado, porque incorpora un documento y, a menudo, una firma, no solo una marca de tiempo, y su gestión se aborda en la guía sobre ePOD y apps para conductores.
Nada de esto deja obsoleto el 214. Si un socio norteamericano lo envía y funciona, funciona. Lo que no es, es el estándar europeo por defecto, y montar una arquitectura de estados en torno a la semántica de X12 porque la documentación era la más fácil de encontrar es un error que aflora dos transportistas después. Defina primero qué significan sus hitos, acéptelos luego desde el canal que cada transportista pueda sostener y mantenga aparte la cuestión de quién opera los flujos, tal como se expone en la comparativa de los modelos 3PL y 4PL.
