Integración EDI para el transporte de mercancías por carretera en Europa

El EDI no es la mitad heredada de su red. Es la mitad conforme a la normativa

El comercio minorista lo exige, la automoción se asienta sobre él y la facturación del transporte funciona con él. Tratar el EDI como algo de lo que migrar es como los cargadores acaban con dos verdades paralelas: una fuente API para los transportistas que podían soportarla y una fuente de ficheros para los que más importan comercialmente.

La arquitectura viable no es una migración. Ambos canales llegan al mismo sitio, se normalizan en el mismo evento interno y nada en los sistemas posteriores sabe por qué canal llegó cada dato. La elección entre uno u otro según el socio se trata en API frente a EDI en el transporte por carretera.

Mensajes que intercambiamos

Cómo circulan realmente los ficheros

AS2 para los socios que ya lo usan, SFTP cuando basta con un intercambio más sencillo y OFTP2 cuando la automoción lo requiere. Se admiten las redes de valor añadido cuando un socio insiste, aunque conviene revisar el coste por volumen antes de confiar a una de ellas un flujo de estados de alta frecuencia.

La frecuencia importa más que el transporte. Un fichero de estados transmitido cada hora le ofrece un registro, no visibilidad, lo cual sirve para facturar pero resulta inútil para quien planifica. Cuando un socio solo puede enviar con una frecuencia amplia, sus datos de hitos sirven para conciliar y su posición en tiempo real procede de la telemática en su lugar. Ambas son complementarias, no alternativas.

El mapeo, y por qué es por socio aunque todos cumplan la norma

La conformidad no resuelve el significado. Dos transportistas pueden enviar un IFTSTA conforme al estándar y rellenarlo de forma distinta, y la discrepancia recurrente es qué cuenta como llegada: alcanzar la entrada, alcanzar el muelle o el momento en que el conductor lo notifica.

Por eso el mapeo se acuerda explícitamente, campo a campo, y se guarda asociado al socio. Cada mensaje entrante recibe una clave de idempotencia construida a partir de la referencia del envío, el estado y la hora del evento, porque los ficheros se reenvían y una llegada duplicada duplica el tiempo de permanencia registrado. Los eventos se ordenan por la hora del evento y no por la de recepción, ya que una salida llega a menudo en un fichero antes que la llegada a la que sigue. El detalle de los códigos de estado se encuentra en la guía sobre los mensajes de estado EDI 214 e IFTSTA.

eCMR y eFTI, la parte con fecha límite

El Reglamento 2020/1056 obliga a las autoridades competentes de toda la UE a aceptar la información de transporte en formato electrónico, y la consecuencia práctica para un cargador es que la carta de porte deja de ser un documento en papel que viaja en la cabina y pasa a ser un dato estructurado que debe poder presentarse cuando se solicite.

Eso cambia lo que debe llevar el flujo documental: los propios datos del envío, los eventos de firma y una pista de auditoría que vincule ambos con la carga. La parte documental se trata en la página de software eCMR , y el comportamiento de la carta de porte electrónica frente al papel en la práctica se expone en eCMR frente a la carta de porte CMR en papel.

Las siete semanas

La puesta EN FUNCIONAMIENTO está garantizada en siete semanas, y el calendario es el mismo en cada integración porque el lado de la plataforma nunca cambia. Lo que varía es la rapidez con la que su equipo puede facilitar un sistema de pruebas y una persona de contacto designada.

1. Semanas 1 y 2, análisis. Acordamos la lista de campos, la dirección de cada campo y qué sistema es el autorizado para él. Esta es la reunión que decide si el proyecto será sencillo, y omitirla es la razón por la que las integraciones se desvían.
2. Semanas 3 y 4, conexión. Credenciales, endpoints y un primer mensaje circulando en un entorno de pruebas. Todavía no se mapea nada, estamos comprobando el canal.
3. Semana 5, mapeo y eventos. Sus campos sobre nuestro modelo de eventos, incluida la definición de llegada, que es la más discutida de todas.
4. Semana 6, ejecución en paralelo. Ambos sistemas en funcionamiento, con el recuento de eventos comparado a diario. Cualquier discrepancia es un error de mapeo detectado antes de que nadie dependa de él.
5. Semana 7: puesta en marcha y traspaso. Los sistemas que consumen los datos cambian de origen y la supervisión pasa a su equipo, junto con el informe de conciliación que le avisa cuando un flujo deja de enviar datos.

Ubicación de los datos, RGPD e ISO 27001

Los datos de transporte son datos operativos sobre conductores y vehículos identificables, así que quedan sujetos al RGPD sea cual sea la vía por la que nos llegan. En una revisión de seguridad europea suelen plantearse tres cuestiones, y las respuestas no cambian según la integración.

• Dónde residen los datos. El tratamiento y el almacenamiento permanecen dentro de la UE.
• Quién puede verlos. Sus datos de transporte permanecen dentro de su red de transportistas de confianza. Cada transportista ve solo las cargas que tiene asignadas, no el conjunto de su red.
• Cómo se gobiernan. TrucksOnTheMap cuenta con la certificación ISO 27001, y los controles que importan en una integración de transporte son el control de accesos, la conservación de los datos y el registro de auditoría de cada evento.

Los datos de posición plantean su propia cuestión de conservación. Decida de antemano cuánto tiempo se guardan las señales en bruto frente a los eventos derivados, porque son los eventos derivados los que necesitan sus KPI y es el rastro en bruto lo que preguntará un comité de empresa.

Preguntas frecuentes

¿Qué mensajes EDI admiten para el transporte por carretera?

EDIFACT IFTMIN para la instrucción de transporte, IFTMBF e IFTMBC para la solicitud y la confirmación de reserva, IFTSTA para el estado, IFTMAN para el aviso de llegada, DESADV cuando el centro receptor reserva a partir de un aviso de expedición, e INVOIC para la facturación del transporte y la autofacturación. Se admiten X12 204, 214 y 210 cuando interviene un socio norteamericano.

¿Cómo llegan hasta ustedes los ficheros EDI?

AS2 para los socios que ya lo usan, SFTP cuando basta con un intercambio más sencillo y OFTP2 cuando la automoción lo requiere. Se admiten las redes de valor añadido cuando un socio insiste, aunque conviene revisar el coste por volumen antes de confiar a una de ellas un flujo de estados de alta frecuencia.

¿Por qué hay que acordar un mapeo EDI por cada socio?

Porque la conformidad no resuelve el significado. Dos transportistas pueden enviar un IFTSTA conforme al estándar y rellenarlo de forma distinta, y la discrepancia recurrente es qué cuenta como llegada: la entrada, el muelle o el momento en que el conductor lo notifica. Por eso el mapeo se acuerda campo a campo y se guarda asociado al socio.

¿Pueden coexistir las fuentes EDI y API sin generar dos versiones de la verdad?

Sí, mediante un único modelo de eventos interno al que ambos canales se asignan en el extremo. Cada evento lleva su origen y si su marca temporal se generó automáticamente o se introdujo a mano, cada mensaje entrante recibe una clave de idempotencia construida a partir de la referencia, el estado y la hora del evento para que los reenvíos no puedan duplicar una llegada, y los eventos se ordenan por la hora del evento y no por la de recepción.

¿Qué supone el eFTI para nuestros flujos EDI?

El Reglamento 2020/1056 obliga a las autoridades competentes de toda la UE a aceptar la información de transporte en formato electrónico, de modo que la carta de porte pasa a ser un dato estructurado que debe poder presentarse cuando se solicite, en lugar de un papel que viaja en la cabina. El flujo documental debe por tanto llevar los datos del envío, los eventos de firma y una pista de auditoría que vincule ambos con la carga.

Envíenos un fichero de ejemplo

Un IFTSTA o un 214 real de su mayor transportista nos dice más en diez minutos que un taller de análisis de requisitos en todo un día.