Cómo integrar tu TMS con SAP S/4HANA paso a paso

Antes de empezar: qué necesitas tener listo

Integrar tu TMS con SAP S/4HANA no es un proyecto de fin de semana, pero tampoco necesita convertirse en una odisea de seis meses si sabes qué preguntar antes de sentarte con tu equipo de Basis. Lo primero: identifica exactamente qué edición de SAP tiene tu empresa. No es una pregunta retórica. Cloud Public Edition, Private Cloud Edition y On-Premise tienen caminos de integración radicalmente distintos, y confundirlos es el error número uno que veo repetirse en proyectos de integración TMS SAP S/4HANA.

Antes de arrancar necesitas cuatro cosas sobre la mesa:

• Confirmación por escrito (o al menos por correo del equipo Basis) de qué edición de SAP S/4HANA corre tu empresa, incluyendo el release exacto si es Cloud Public Edition.
• Acceso al SAP Business Accelerator Hub (antes API Business Hub) para consultar el catálogo de APIs disponibles para tu edición específica.
• Un usuario técnico con autorizaciones para activar Communication Scenarios en SOAMANAGER o en el Fiori Launchpad de administración.
• Un TMS con conectividad documentada hacia SAP, ya sea vía IDoc, OData o ambas. No todos los TMS "multi-carrier" ligeros cubren esto: plataformas como SAP TM, Cargoson, MercuryGate, Descartes o Oracle TM publican conectores específicos, pero conviene pedirle a tu proveedor la ficha técnica exacta antes de firmar nada.

Si tu empresa está en pleno proceso de migración desde ECC, este es también el momento de decidir si el proyecto de integración TMS va en paralelo a la migración o después. Hacerlo en paralelo ahorra tiempo, pero solo si tu equipo de Basis tiene ancho de banda real, no teórico.

Paso 1: Decidir entre API OData e IDoc según tu edición de SAP

La respuesta corta: si estás en Private Cloud Edition o On-Premise, probablemente vas a usar IDocs, no las APIs de Transportation Management más recientes. Según el SAP Business Accelerator Hub, las APIs OData de Transportation Management (por ejemplo API_FREIGHTORDER, API_FREIGHTBOOKING, API_FREIGHTUNIT y API_CONSIGNMENTORDER) no están soportadas para SAP S/4HANA Private Cloud Edition ni para SAP S/4HANA On-Premise. Esto está documentado en la SAP Knowledge Base Article 3703361, y es exactamente el tipo de letra pequeña que los equipos de IT descubren tarde, cuando ya han comprometido fechas de go-live con el proveedor de TMS.

Para Stock Transport Orders, el panorama en Cloud Public Edition ha mejorado notablemente. Con el release 2602, SAP entregó API_STOCKTRANSPORTORDER, una API OData V4 completa para integración de Stock Transport Orders, construida sobre el modelo ABAP RESTful Application Programming (RAP), y asegurada mediante el Communication Scenario SAP_COM_0A80. Antes de esa versión, había que usar la app Fiori "Manage Purchase Orders", sin automatización ni conectividad de sistemas externos vía API. Si tu negocio depende de traslados intercompañía o intracompañía de stock, esta API cambia el juego, pero solo aplica si estás en Cloud Public Edition.

La tabla siguiente resume qué camino toma cada edición:

Paso 2: Activar el Communication Scenario correcto

Si tu edición sí soporta APIs OData de TM, el siguiente paso técnico es activar el Communication Scenario adecuado. Para Stock Transport Order Integration, la API está asegurada vía Communication Scenario SAP_COM_0A80. En la práctica, esto se traduce en tres tareas para tu equipo Basis:

1. Entrar a la transacción SOAMANAGER (o el equivalente en Fiori Launchpad para Cloud Public Edition) y localizar SAP_COM_0A80 en la lista de escenarios de comunicación.
2. Crear el sistema de comunicación entrante que representará al TMS externo, asignándole un ID único y las credenciales de autenticación (OAuth2 o Basic Auth, según lo que soporte tu TMS).
3. Generar el usuario de comunicación asociado y asignarle exactamente los roles de autorización necesarios para el escenario, ni uno más. Esto evita problemas de auditoría de seguridad más adelante.

Si tu edición es Private Cloud o On-Premise y no tienes acceso a este Communication Scenario específico, no pierdas tiempo buscándolo: no aplica para ti. Salta directamente al paso 3 con la ruta IDoc.

Paso 3: Configurar el intercambio de documentos (IDoc o API)

Aquí es donde se bifurca de verdad el proyecto, dependiendo de si vas por IDoc o por API.

Ruta IDoc. Si estás en On-Premise conectando hacia SAP Integration Suite en BTP, este escenario se enfoca en transmitir un IDoc (por ejemplo ORDERS, INVOIC, DESADV, MATMAS) desde un sistema S/4HANA on-premise hacia un flujo de integración (iFlow) desplegado en SAP BTP. La configuración técnica implica definir un puerto XML HTTP en S/4HANA y asociarlo con un destino RFC que apunte al endpoint del iFlow en SAP Integration Suite, con autenticación mediante Basic Authentication usando credenciales de la instancia de servicio de BTP, y comunicación segura mediante SSL/TLS importando el certificado del servidor al Trust Manager de S/4HANA. Para transporte, los tipos de mensaje relevantes son ORDERS (pedido de venta que dispara la necesidad de transporte), DESADV (aviso de expedición hacia el cliente o almacén) y SHPMNT (documento de embarque que representa el shipment físico en el sistema de logística de ECC/S4).

Ruta API. Si estás en Cloud Public Edition, el documento central que vas a mapear es el Transportation Order. El Transportation Order (TOR) es el documento de negocio central en SAP TM y representa un acuerdo de flete legalmente vinculante entre un cargador y un transportista. Lo interesante para equipos técnicos es que la inversión reciente de SAP hace que los datos del TOR sean accesibles de forma limpia a través del modelo RAP estándar y disponibles como Data Product, eliminando la necesidad de llamadas BAPI de ABAP o acceso directo a tablas. En términos prácticos, esto significa que las entidades FreightOrder, FreightBooking y FreightUnit dejan de ser una caja negra para tu equipo de integración y se vuelven consumibles vía servicios OData V4 estándar.

Paso 4: Mapear campos críticos entre TMS y SAP

Este es el paso que más tiempo consume en la práctica, y el que menos se documenta en las guías técnicas. Como mínimo necesitas mapear:

• Fecha y hora de recogida y entrega (pickup/delivery date-time), asegurando que ambos sistemas usen la misma zona horaria de referencia.
• Transportista asignado, verificando que el código de partner en SAP coincida exactamente con el carrier code en el TMS (aquí aparecen la mayoría de errores silenciosos).
• Peso y volumen, con unidades de medida homogéneas (kg vs. lb, m³ vs. ft³).
• Incoterm de la operación.
• Dirección de origen y destino, incluyendo el código postal en el formato que espera cada sistema.
• Número de pedido de venta o de unidad de flete (Freight Unit) que sirve de referencia cruzada entre ambos sistemas.

El error típico aquí no es técnico, es de gobernanza de datos: nadie define de antemano quién es el "sistema maestro" para el código de transportista. Resuélvelo antes de escribir una sola línea de mapeo, no después.

Paso 5: Probar en entorno de desarrollo/calidad

Antes de tocar producción, crea una orden de transporte de prueba desde el TMS y verifica que llegue correctamente a SAP. Cómo saber que funcionó:

1. Si vas por API: el freight order aparece en la app Fiori correspondiente (o en la transacción equivalente en SAP TM) con estado correcto, sin errores en el monitor de APIs.
2. Si vas por IDoc: revisa la transacción WE02 (visualización de IDocs) o WE05 (lista de IDocs) y confirma que el estado del IDoc sea 03 (datos pasados al puerto correctamente) o el equivalente de procesamiento exitoso, sin segmentos de error.
3. El TMS recibe la confirmación de vuelta, ya sea un acuse de recibo o una actualización de estado, cerrando el ciclo bidireccional.

Si el IDoc queda en estado de error (51 o similar), no lo reproceses a ciegas: revisa primero el segmento específico que falló en WE02, casi siempre apunta a un campo obligatorio que llegó vacío desde el TMS.

Fallo común y cómo resolverlo

El error más frecuente que veo en proyectos reales: el equipo de integración intenta llamar a API_FREIGHTORDER en un sistema Private Cloud o On-Premise y la API simplemente no responde, o ni siquiera aparece en el catálogo del Business Accelerator Hub para esa edición. No es un bug ni un problema de configuración, es una limitación documentada por SAP: estas APIs de Transportation Management no están soportadas para esas ediciones.

La solución pasa por dos caminos. El primero es cambiar a IDocs conectados vía un middleware EDI: soluciones como las que describe SEEBURGER permiten enrutar dinámicamente entre IDocs y APIs según lo que necesite cada escenario, protegiendo la inversión existente en estructuras IDoc mientras se abre la puerta a APIs cuando estén disponibles. El segundo camino es trabajar con un TMS que ya tenga resuelta esta brecha con conectores nativos documentados para ambas vías: opciones como Cargoson, AEB TMS, Descartes o MercuryGate ofrecen esta flexibilidad de conexión según la edición SAP del cliente, evitando que tu equipo tenga que descubrir la limitación a mitad de proyecto.

Paso a producción y monitorización continua

Antes del go-live, revisa este checklist mínimo: certificados SSL/TLS activos y no próximos a caducar, roles de autorización revisados por el equipo de seguridad (no solo por el consultor que hizo la configuración), alertas configuradas para IDocs o llamadas API con error, y un plan de rollback documentado por si algo falla en las primeras 48 horas.

La gobernanza no termina en el go-live. Durante el primer mes, revisa los logs de integración semanalmente, no mensualmente. Los errores de mapeo de campos suelen aparecer en las primeras dos o tres semanas de operación real, cuando el volumen de transacciones supera lo que se probó en calidad. Herramientas como Cargoson, junto con SAP TM nativo, Oracle TM, Blue Yonder o Manhattan Active, ofrecen conectores preconfigurados que reducen buena parte de este trabajo manual de mapeo, pero ningún conector sustituye la revisión humana de las primeras semanas de producción. Ese trabajo, lo sabe cualquiera que haya pasado por un go-live de integración, sigue siendo tuyo.