Integrar DB Schenker en tu TMS: EDI IFTMIN paso a paso

Si gestionas transporte con DB Schenker en España desde hace años, ya sabes que su integración no pasa por una API REST moderna, sino por un stack EDIFACT que lleva funcionando casi sin cambios desde que empezaste a usarlo. El reto ahora es doble: construir correctamente el EDI IFTMIN DB Schenker para reservar transporte, y entender qué ha cambiado en ese flujo tras la fusión legal con DSV que se cerró el 1 de enero de 2026. Esta guía cubre ambas cosas, paso a paso, con los campos y mensajes exactos que necesitas verificar.

Por qué DB Schenker sigue funcionando con EDIFACT (no con API REST)

Porque su infraestructura de reserva y seguimiento nunca migró a REST. DB Schenker still runs core booking and tracking on UN/EDIFACT, not REST. Esto contrasta con transportistas más jóvenes que nacieron API-first, y significa que si integras a volumen con ellos necesitas dominar tres mensajes concretos.

La documentación propia de DB Schenker lista tres mensajes con los que trabajarás: un IFTMIN en S93A para reservar envíos, un IFTMCS en S93A como recibo y confirmación de que el EDI se ha recibido, y un IFTSTA en D96A que transporta observaciones ocurridas, como un segmento STS+ANT que significa que el envío ha llegado a una terminal. Dicho de otro modo: reservas con IFTMIN, confirmas con IFTMCS, y haces seguimiento con IFTSTA. Si tu TMS ya habla EDIFACT con otro transportista tradicional, la estructura te resultará familiar.

Lo que necesitas antes de empezar

Antes de mapear un solo segmento, reúne lo siguiente. Sin esto, perderás días en idas y vueltas con soporte técnico de DB Schenker.

• Cuenta comercial activa con DB Schenker (hoy, legalmente, DSV Road Spain) con acceso EDI habilitado en tu contrato.
• Identificadores de emisor y receptor (GLN o ID EDI) pactados con DB Schenker para el envelope UNB.
• Tus datos de conexión AS2 u OFTP2: certificados, AS2-ID o SSID de OFTP2, y el endpoint de gateway correspondiente a tu país.
• Las guías de implementación de campos IFTMIN S93A e IFTSTA de DB Schenker, que especifican su uso de segmentos condicionales y obligatorios sobre el estándar base UN/EDIFACT.
• Un entorno de pruebas o test harness, si DB Schenker lo ofrece, para validar mensajes antes de ir a producción.

Cómo construir y enviar el IFTMIN paso a paso

Con los accesos listos, el flujo completo desde que generas el pedido hasta que tienes confirmación tarda típicamente un ciclo de desarrollo corto si ya tienes experiencia EDIFACT. Estos son los pasos concretos.

1. Mapea el pedido de transporte a los segmentos IFTMIN. El mensaje debe llevar las mercancías, los puntos de recogida y entrega, las fechas, el nivel de servicio y cualquier manipulación especial como control de temperatura o clasificación de mercancías peligrosas. El segmento TDT, especifica información sobre el transporte como el modo, el medio, su número de referencia de transporte y la identificación del vehículo.
2. Completa el segmento RFF con el número de envío, la referencia del pedido y tu número interno de remitente, para poder cruzar después cada evento IFTSTA con tu pedido original en el TMS.
3. Fija el envelope UNB con los identificadores de emisor y receptor que hayas pactado con DB Schenker. Un error habitual es dejar un ID de entorno de pruebas activo en producción: el mensaje se transmite pero nunca llega al sistema correcto.
4. Cifra y transmite el mensaje por AS2. Tu sistema genera el mensaje EDI, por ejemplo un pedido de transporte IFTMIN, y lo cifra usando el certificado público del transportista para que solo él pueda abrirlo. Después lo firmas con tu propio certificado privado, de modo que el transportista pueda verificar que realmente viene de ti, y lo transmites por HTTP/S. El gateway AS2 de DB Schenker descifra la carga, verifica tu firma y procesa el pedido de transporte en su propio sistema.
5. Confirma la recepción técnica y comercial. Necesitas conciliar correctamente las respuestas CONTRL, IFTMCS e IFTSTA que recibas de vuelta. El sistema de Schenker responde con un MDN que confirma la recepción, y por separado, el IFTMCS actúa como recibo y confirmación de que el EDI se ha recibido.
6. Suscríbete a las actualizaciones IFTSTA. La guía de campos IFTSTA de DB Schenker confirma que la referencia de consignación que envías se devuelve sin cambios en las actualizaciones de estado, identificada por AAM como el número de consignación o el número de albarán que DB Schenker asigna. A medida que el envío avanza, Schenker empuja actualizaciones de estado de vuelta por el mismo canal AS2 usando IFTSTA, que transporta observaciones ocurridas a lo largo de la ruta.

Cómo saber que la integración funciona

Hay tres señales concretas que confirman que el IFTMIN quedó bien construido, no tres suposiciones. Primero, el mensaje debe generar un CONTRL técnico sin errores de sintaxis, no un rechazo. Segundo, debe llegar un IFTMCS como confirmación comercial del booking, independiente del MDN de transporte. Tercero, los eventos IFTSTA posteriores (recogida, tránsito, entrega, llegada a terminal vía STS+ANT) deben reflejarse en tu TMS con la misma referencia de consignación que enviaste, sin que tu equipo tenga que cruzarlos manualmente.

Fallo común: el interchange queda rechazado

El error más frecuente no es un campo mal mapeado, sino un rechazo de bajo nivel que no distingues de un error de contenido. Vas a necesitar los bytes exactos para diagnosticar problemas de delimitadores o de juego de caracteres. La tentación es reenviar el mismo mensaje esperando que esta vez pase, pero EDI no tiene una convención de reintento con backoff exponencial; reenviar a ciegas un mensaje estructuralmente roto solo produce otro rechazo con una nueva referencia de interchange, quemando tu secuencia de números de control para nada.

La solución práctica: revisa primero si el CONTRL marca un rechazo de sintaxis (delimitadores, encoding, segmento fuera de secuencia) frente a un simple error de transporte AS2 (certificado caducado, MDN no recibido). DB Schenker añade sus propias reglas condicionales y obligatorias sobre el estándar, así que pasa el mensaje generado por un validador EDIFACT genérico y, si DB Schenker lo ofrece, por su propio test harness antes de reintentar nada en producción.

Qué cambia (y qué no) tras la fusión DB Schenker-DSV en 2026

Lo técnico del IFTMIN no cambia; lo que cambia es quién hay detrás del gateway y con qué razón social firmas. La integración en la división de Road y el legal merge entre DSV y Schenker en España se completó el 1 de enero de 2026. En la práctica, las actividades de la filial española de Schenker se repartieron entre DSV Air & Sea, DSV Road Spain y DSV Solutions Spain, con un proceso de escisión total sin liquidación de la antigua Schenker Logistics SAU.

Para el día a día de tu integración, esto significa revisar tres cosas concretas antes de dar nada por cerrado: tus identificadores de emisor/receptor en el UNB (¿siguen apuntando a la entidad correcta?), tus certificados AS2 (¿el gateway sigue siendo el mismo endpoint o ha migrado a infraestructura DSV?) y tu punto de contacto técnico de soporte EDI. Para transporte terrestre puedes seguir usando temporalmente las herramientas online de Schenker, salvo excepciones indicadas por tu interlocutor comercial, y tu operativo de tráfico o comercial te mantendrá informado sobre la migración a los sistemas DSV.

No esperes que esto se resuelva de un día para otro. DSV ha integrado un 30% de DB Schenker y espera completar el proceso a finales de 2026, un calendario que se aceleró: el plan anterior apuntaba a finales de 2028. El propio CEO de DSV lo resumió con claridad en la presentación de resultados: "Timeline on the Schenker integration will be done end of year 2026, with full financial impact on the synergies in 2027." Mientras dure esta ventana, conviene re-verificar la configuración EDI cada vez que tu contacto comercial anuncie un cambio de sistema, no solo una vez al cierre del proyecto.

Encajar esto en una arquitectura híbrida EDI/API con tu TMS

La mayoría de cargadores grandes no corren un solo protocolo: EDIFACT para transportistas tradicionales como DB Schenker/DSV, y APIs REST para los que ya nacieron digitales. El gateway nativo de DB Schenker no deja alternativa: soporta IFTMIN/IFTMCS/IFTSTA vía AS2/OFTP2, con un modelo de integración exclusivamente EDI y sin capa de abstracción, así que el trabajo de "traducir" ese EDI a algo que tu ERP entienda recae en ti o en la plataforma intermedia que elijas.

Si tu equipo de compras no quiere mantener un parser EDIFACT a medida para cada transportista heredado, una plataforma como Cargoson abstrae ese trabajo detrás de una capa única, dejando que el IFTMIN, el IFTMCS y el IFTSTA sigan viajando por AS2 tal como DB Schenker los espera, sin que tu ERP tenga que saberlo.

Checklist final

• Identificadores de emisor/receptor en el UNB verificados contra la entidad legal correcta (DSV Road Spain, no la antigua Schenker Logistics SAU).
• Certificados AS2 vigentes y apuntando al endpoint de gateway activo, no a uno heredado.
• IFTMIN validado contra la guía de campos S93A de DB Schenker, no solo contra el estándar EDIFACT base.
• CONTRL recibido sin rechazo de sintaxis en los últimos envíos de prueba.
• IFTMCS llegando como confirmación comercial, separado del MDN de transporte.
• Eventos IFTSTA (incluyendo STS+ANT) reflejándose correctamente en tu TMS con la referencia de consignación intacta.
• Punto de contacto técnico de soporte EDI confirmado tras la migración a sistemas DSV.
• Plan de reintento documentado que distinga rechazo estructural de error de transporte AS2, para no quemar números de control sin motivo.