decagestiónTECNOLOGÍA PARA EL TRANSPORTE
Integración SAP y DeCA

Integrar el DeCA con SAP: alcance, datos y controles

Conectar SAP con el documento electrónico de control no consiste en sacar todos los campos de una entrega y convertirlos directamente en PDF. Primero hay que identificar la edición, versión y proceso logístico de la empresa; después, localizar qué objeto representa el envío y qué datos legales no están en SAP o se conocen más tarde. Esta guía delimita un alcance realista para SAP S/4HANA, compara API y archivo, y define controles para emitir el DeCA antes de la salida sin prometer compatibilidad universal.

1437 palabras

Define el paisaje SAP antes de hablar de un conector

SAP no es una instalación única. Una empresa puede utilizar SAP S/4HANA Cloud Public Edition, S/4HANA Cloud Private Edition, S/4HANA on-premise, ECC u otro producto con desarrollos propios. Las interfaces, objetos, autorizaciones y ciclos de actualización cambian entre ediciones y releases. Por eso el inventario inicial debe recoger producto, versión, módulos logísticos, sociedad, centros expedidores, sistema de transporte relacionado y middleware disponible.

La documentación actual de SAP S/4HANA Cloud describe el servicio OData Outbound Delivery (A2X), con nombre técnico API_OUTBOUND_DELIVERY_SRV_0002. Ese servicio trabaja con cabecera, posiciones, socios, direcciones, flujo documental, números de serie y textos, entre otros nodos. Su existencia no demuestra que esté activado en una instalación ni que contenga todos los datos exigidos por el DeCA. Hay que confirmar el alcance publicado para la release concreta y el escenario de comunicación habilitado.

  • Producto, edición, release y modalidad de alojamiento.
  • Procesos de ventas, entrega, expedición y transporte implicados.
  • Ampliaciones, campos Z, BAdI, interfaces y módulos propios.
  • Integration Suite, middleware alternativo o intercambio por archivo disponible.

Elige el objeto SAP que representa cada envío

El DeCA se formaliza para cada envío sujeto al ámbito de la Orden FOM/2861/2012. En SAP, la entrega de salida suele ser una candidata más próxima al movimiento físico que el pedido de ventas o la factura, pero la decisión depende del proceso. Puede haber una entrega con varias expediciones, agrupaciones, transporte gestionado en SAP TM o datos completados en un sistema externo. La clave documental debe corresponder a la unidad que realmente viaja, no solo al número que resulte más fácil consultar.

Prepara una matriz con pedido, entrega, expedición, unidad de transporte y documento de facturación. Para cada uno anota identificador, momento de creación, estado que autoriza la salida y relación con los demás. Esa matriz evita emitir demasiado pronto con información provisional o demasiado tarde, cuando el vehículo ya ha iniciado el servicio. También permite construir una clave idempotente para que un reintento del middleware no genere otro DeCA.

  • Identificador estable de la expedición y sociedad responsable.
  • Estado SAP que indica que los datos están listos para validar.
  • Relación entre entrega, posiciones, transporte y documentos posteriores.
  • Regla para anulaciones, particiones, agrupaciones y reintentos.

Mapea los datos legales y su responsable

La Orden exige identificar al cargador contractual con nombre o razón social, NIF y domicilio, y al transportista efectivo con nombre o razón social y NIF. También requiere origen, destino, naturaleza y peso, fecha, matrículas y, cuando proceda, autorización especial. Socios y direcciones de una entrega SAP pueden ayudar, pero un rol de interlocutor no debe equipararse automáticamente a una figura contractual. La empresa debe aprobar la correspondencia entre roles SAP y obligaciones del transporte.

El artículo 7 consolidado distribuye la responsabilidad de la exactitud: el cargador contractual responde de partes, origen, destino, naturaleza y peso; el transportista efectivo, de autorización especial, fecha y matrículas. El mapa de integración debe incluir origen técnico, transformación, formato, obligatoriedad y responsable funcional de cada dato. Si una matrícula se recibe desde SAP TM, un portal del transportista o una pantalla de tráfico, esa procedencia debe quedar registrada.

  • Socios: cargador contractual y transportista efectivo sin confundir roles comerciales.
  • Ubicaciones: lugar real de carga y descarga, no domicilio administrativo por defecto.
  • Mercancía: descripción comprensible, peso y unidad con regla de agregación documentada.
  • Vehículo: tractor, remolque y autorización especial aportados por la fuente responsable.
  • Trazabilidad: entrega SAP, versión del mapeo, fecha de lectura y usuario que valida.

API OData, Integration Suite o archivo controlado

Una integración por API puede consultar entregas y sus nodos mediante la interfaz publicada para la edición y release. Si la empresa ya utiliza SAP Integration Suite, un flujo puede transformar el mensaje, aplicar validaciones, controlar reintentos y enviar solo los campos necesarios a DecaGestion. El middleware no debe convertir un error funcional en un éxito técnico: una entrega sin peso o sin figura contractual necesita quedar pendiente con un motivo visible.

Para un piloto, un archivo CSV estructurado puede reducir dependencias y facilitar la revisión del mapa. El fichero debe tener contrato de columnas, codificación, límite de filas, referencia única y controles contra fórmulas o duplicados. No conviene extraer directamente tablas internas sin una interfaz estable y autorización del equipo SAP, porque el modelo y la lógica pueden variar. La elección entre API y archivo depende de volumen, frecuencia, ventana operativa, licencias, soporte y capacidad de recuperación.

  • API: confirma servicio, versión, operaciones permitidas y filtros de lectura.
  • Middleware: registra correlación, reintentos, errores y mensajes retenidos.
  • Archivo: valida esquema, tamaño, duplicados y campos antes de importar.
  • En todos los caminos: conserva la referencia SAP y no vuelvas a emitir por un reintento.

Autenticación y permisos sin exponer SAP

SAP Integration Suite admite OAuth 2.0 y documenta el flujo Client Credentials para clientes de API. La autenticación entrega un token de acceso después de validar las credenciales, y la autorización debe limitar lo que el cliente puede consultar. Cuando el entorno admita certificados de cliente, pueden utilizarse dentro del esquema configurado. Los secretos, claves y certificados permanecen en el servidor o en el almacén de seguridad; nunca deben viajar al navegador ni guardarse en un archivo de mapeo.

Crea una identidad técnica dedicada, con lectura sobre los objetos y sociedades necesarios. Separa desarrollo, prueba y producción, y prueba la revocación y rotación antes de depender del flujo. Los roles de diseño de Integration Suite son potentes y no deben reutilizarse como credencial de ejecución. Además de autenticación, aplica límites de mensajes, validación de esquemas, registros sin contenido sensible y alertas cuando la cola se acumule o el token no pueda renovarse.

  • Usuario o cliente técnico exclusivo para la integración.
  • Permisos mínimos por API, operación, sociedad y datos necesarios.
  • Secretos y certificados gestionados fuera del código y del frontend.
  • Auditoría de despliegues, rotaciones, fallos de autorización y cambios de alcance.

Convertir los datos en PDF, URL y QR

La Resolución de 5 de junio de 2026 exige que la aplicación transforme los datos estructurados en el fichero electrónico antes del inicio efectivo del servicio y registre fecha y hora de creación y modificación. El resultado es un PDF nativo digital, legible y de hasta 5 MB. Debe incluir un QR con la URL única del documento, y esa dirección HTTPS tiene que producir la descarga directa del PDF durante una inspección sin credenciales ni pasos manuales adicionales.

Un mensaje procesado correctamente por SAP o por Integration Suite no prueba que el documento esté disponible para el conductor. El estado final necesita confirmar generación, almacenamiento, entrega y recuperación. Si cambia la matrícula u otro dato durante el trayecto, la rectificación conserva el dato anterior y el motivo o crea un nuevo PDF completo con URL y QR nuevos, manteniendo el original. La actualización en SAP debe relacionarse con esa versión documental, no sustituirla sin historial.

  • Valida los campos esenciales antes de generar el fichero.
  • Registra el instante, referencia de origen y versión del documento.
  • Comprueba QR y descarga desde un móvil sin sesión iniciada.
  • Conserva originales, rectificaciones y acceso durante el plazo aplicable.

Piloto de aceptación antes de pasar a producción

Construye datos sintéticos para entregas con una y varias posiciones, destinos distintos, transportistas diferentes, remolque, autorización especial y un campo obligatorio ausente. Simula un reintento, una anulación y un cambio de matrícula. La aceptación debe demostrar que el mismo evento no duplica documentos, que los errores quedan recuperables y que ninguna expedición incompleta aparece como emitida.

Después abre cada PDF, revisa metadatos y tamaño, escanea el QR desde otra red y descarga el fichero. Compara los valores con SAP y con la fuente que completa los datos de tráfico. Documenta resultados por edición y release. Los campos Z, ampliaciones o procesos de SAP TM pueden requerir desarrollo y cotización independiente. El piloto valida ese paisaje SAP y ese mapa de datos; no certifica cualquier instalación ni sustituye el análisis jurídico de operaciones especiales.

  • Prueba datos correctos, incompletos, duplicados, anulados y rectificados.
  • Interrumpe temporalmente la conexión y confirma recuperación sin pérdida.
  • Verifica acceso al PDF desde el recorrido real del conductor.
  • Aprueba el mapa funcional, técnico y de responsabilidades antes del arranque.

Preguntas frecuentes

¿Existe un conector DeCA universal para SAP?

No puede asegurarse para todas las ediciones y procesos. El alcance depende del producto, release, módulos, interfaces activas, campos propios y sistema que gestione el transporte.

¿La entrega de salida contiene todos los campos?

Puede aportar referencias, posiciones, socios y direcciones, pero hay que validar el contenido real. Matrículas, autorización especial o la figura contractual pueden proceder de SAP TM, tráfico, el transportista u otro sistema.

¿Es obligatorio utilizar SAP Integration Suite?

No. Puede usarse una API directa correctamente protegida, otro middleware o un archivo controlado. La decisión depende de la arquitectura, licencias, volumen, soporte y controles de recuperación.

¿Qué ocurre con los campos Z y desarrollos propios?

Deben inventariarse y mapearse en la instalación concreta. Si no están disponibles en una interfaz soportada, pueden necesitar una ampliación o desarrollo separado con alcance y presupuesto acordados.

Fuentes oficiales y técnicas

  1. BOE — Orden FOM/2861/2012 consolidada, artículos 1 a 9
  2. BOE — Resolución de 5 de junio de 2026 sobre sistemas y DeCA
  3. SAP Help — Outbound Delivery y campos para entrega y transporte
  4. SAP Help — OAuth 2.0 en SAP Integration Suite

Fuentes consultadas o verificadas el 18 de septiembre de 2026. Verifica siempre la versión consolidada y su aplicación a tu caso.