Ingeniería de software
Cómo modelar viajes, envíos y unidades de carga
Un sistema de transporte necesita al menos cuatro entidades separadas: el envío que contrata un cliente, la unidad de carga física que se mueve, el viaje que hace un vehículo y el tramo que une dos paradas de ese viaje. La relación que lo sostiene todo no es envío-viaje, sino unidad de carga-tramo. Esta guía propone un esquema concreto, lo prueba con un grupaje hipotético resuelto en tablas y señala las decisiones que, mal tomadas, obligan a rehacer el modelo cuando llega el primer transbordo.
- Publicado
- Revisado
- Lectura
- 8 min
- Apartados
- 08
- Por
- colectivedata

Foto: Axisadman · CC BY-SA 3.0
En este artículo · 8 apartados
01La respuesta corta: cuatro entidades y una relación central
Casi todos los programas de tráfico nacen con una tabla de pedidos y una columna de matrícula. Funciona mientras cada pedido va entero en un camión y de un origen a un destino. En cuanto un envío se reparte en dos vehículos, un camión lleva mercancía de seis clientes o un palé cambia de vehículo en un andén de tránsito, esa tabla deja de poder responder a preguntas sencillas: dónde está este palé, qué documentos lleva este camión, cuánto se factura este envío.
- Envío: lo que un cliente contrata entre un origen y un destino, con sus condiciones. Es la unidad de contrato, de documento y de factura.
- Unidad de carga: lo que se mueve físicamente (palé, bulto, caja, contenedor), con su identificador, peso y medidas. Pertenece a un envío.
- Viaje: lo que hace un vehículo con un conductor en un periodo, como secuencia de paradas. Es la unidad de coste y de planificación.
- Tramo: el desplazamiento entre dos paradas consecutivas de un viaje. Es donde la unidad de carga y el vehículo se encuentran.
- Relación central: cada unidad de carga se asigna a uno o varios tramos. Del envío a los viajes se llega a través de sus unidades, no con una columna de matrícula en el envío.
02El contexto: por qué un pedido no es un envío ni un viaje
La separación no es un capricho de diseño; la piden las propias normas y los documentos que el sistema tiene que generar. La Ley 15/2009, del contrato de transporte terrestre de mercancías, define al cargador como quien contrata en nombre propio la realización de un transporte y al porteador como quien asume la obligación de realizarlo, con medios propios o subcontratándolo (artículo 4). La carta de porte recoge, entre otros datos, la cantidad de mercancía determinada por su peso o expresada de otra manera (artículo 10). Todo eso pertenece al envío, no al camión.
El documento de control administrativo de la Orden FOM/2861/2012 se formaliza en relación con cada envío (artículo 1) y debe recoger, entre sus datos esenciales, el cargador contractual, el transportista efectivo, origen y destino, naturaleza y peso de la mercancía, la matrícula del vehículo y la fecha (artículo 6). Es decir: datos del envío y datos del viaje en el mismo documento. Si el modelo los mezcla en una sola tabla, el primer cambio de vehículo obliga a duplicar envíos; si los separa, el documento se compone a partir de las relaciones. Los requisitos de formato del documento electrónico se tratan en la guía del DeCA.
En el ámbito europeo, el Reglamento (UE) 2020/1056, aplicable desde el 21 de agosto de 2024, establece el marco para comunicar por vía electrónica la información reglamentaria del transporte de mercancías a las autoridades, mediante plataformas certificadas, y prevé un conjunto de datos comunes cuyo contenido concretan los actos delegados del artículo 7. Un modelo que ya separa envío, unidad de carga y movimiento de transporte encaja mejor con ese tipo de intercambio que uno construido alrededor del pedido.
03El esquema: entidades, claves y cardinalidades
| Entidad | Clave y campos esenciales | Relación | Quién la crea |
|---|---|---|---|
| Envío | Identificador propio y referencia del cliente; cargador, destinatario, origen, destino, condiciones, fechas pactadas | Tiene 1..n unidades de carga | Atención al cliente o importación del pedido |
| Unidad de carga | Identificador físico (por ejemplo, el SSCC de la etiqueta), tipo, peso, medidas, remontable o no | Pertenece a 1 envío; se asigna a 1..n tramos | Quien prepara la mercancía; se confirma al recogerla |
| Viaje | Identificador, vehículo (tractora y remolque), conductor, transportista efectivo, fecha | Tiene 2..n paradas y 1..n tramos | Tráfico al planificar |
| Parada | Viaje, orden, dirección, tipo (recogida, entrega, tránsito), ventana horaria | Pertenece a 1 viaje | Tráfico; se completa con eventos reales |
| Tramo | Viaje, parada de salida y de llegada, distancia, en carga o en vacío | Pertenece a 1 viaje; agrupa 0..n unidades | Se deriva de las paradas |
| Asignación unidad-tramo | Unidad, tramo, estado (prevista, cargada, descargada), marcas de tiempo | Une unidades y tramos (n:m) | Tráfico al planificar; eventos al ejecutar |
| Evento | Objeto afectado, tipo, momento, origen, autor, evidencia | Se refiere a envío, unidad, parada o asignación | Conductor, almacén, telemática o integración |
Dos detalles sostienen el resto. Primero, la tabla de asignación unidad-tramo es la única que dice dónde está físicamente una unidad; el estado del envío se deriva de ella y de los eventos, no se teclea. Segundo, el vehículo pertenece al viaje y no al envío: cuando un remolque cambia, cambia el viaje o se crea otro, y los envíos no se tocan.
04Caso trabajado: un grupaje con tránsito (ejemplo hipotético)
Esquema por capas · 04
01E-101
- Cliente y destino
- Cliente 1 → ciudad A
- Unidades
- U1, U2, U3 (palés)
- Peso total
- 1.140 kg
02E-102
- Cliente y destino
- Cliente 1 → ciudad B
- Unidades
- U4 (palé)
- Peso total
- 420 kg
03E-103
- Cliente y destino
- Cliente 2 → ciudad A
- Unidades
- U5, U6 (palés) y U7 (bulto suelto)
- Peso total
- 760 kg
| Viaje y tramo | De → a | Unidades asignadas | Estado |
|---|---|---|---|
| V-1 · T1 | Polígono (recogida) → plataforma de tránsito | U1 a U7 | Descargadas en plataforma |
| V-2 · T1 | Plataforma → ciudad A, parada 1 (Cliente 1) | U1, U2, U5, U6, U7 | En curso |
| V-2 · T2 | Ciudad A, parada 1 → ciudad A, parada 2 (Cliente 2) | U5, U6, U7 | Prevista |
| V-3 · T1 | Plataforma → ciudad B | U4 | Prevista |
| Sin tramo | Plataforma | U3 | Pendiente: no cabe por peso en V-2 |
Con estas dos tablas el sistema responde sin ambigüedad a lo que se pregunta en una mañana normal. El envío E-101 está en estado parcial: dos palés en reparto y uno en plataforma, y su factura no debe emitirse como entregada. El viaje V-2 lleva unidades de dos envíos de dos clientes, de modo que necesita al menos un documento de control por cargador contractual: la resolución del DeCA solo permite agrupar en un documento los envíos con el mismo cargador contractual y el mismo transportista efectivo. El palé U3 aparece en una lista de pendientes con su motivo, en lugar de desaparecer entre viajes. Y si mañana V-2 cambia de remolque, se actualiza el viaje y los documentos que dependen de él, sin crear envíos nuevos.
05Escenarios de grupaje y cómo los resuelve el modelo
| Escenario | Qué cambia en los datos | Qué no cambia |
|---|---|---|
| Un envío no cabe en un vehículo | Sus unidades se asignan a tramos de dos viajes | Un solo envío, un solo cliente, una sola línea de factura |
| Consolidación de varios clientes | Un tramo agrupa unidades de varios envíos | Cada envío conserva su documento, sus condiciones y su tarifa |
| Tránsito en plataforma | La unidad cierra un tramo de un viaje y abre otro de un viaje distinto | La unidad mantiene su identificador y su historial |
| Cambio de vehículo en ruta | El viaje cambia de vehículo o se crea un viaje nuevo desde la parada del cambio | Envíos y unidades no se duplican |
| Entrega parcial o rechazo de una unidad | La asignación de esa unidad queda rechazada con su evento y su evidencia | Las demás unidades del envío siguen su curso |
| Subcontratación de un tramo | El viaje de ese tramo tiene otro transportista efectivo | El cargador contractual del envío no cambia |
06Decisiones de diseño que conviene tomar al principio
- Identificador físico de la unidad: si la mercancía ya llega con SSCC, úsalo. GS1 España lo describe como un código de 18 dígitos que identifica de forma única cada unidad logística, que asigna quien confecciona el bulto y que no debe reasignarse hasta un año después de la fecha de envío. Si no llega etiquetada, genera tu propio identificador y etiquétala al recogerla.
- Estados derivados, no tecleados: el estado del envío (pendiente, parcial, entregado) se calcula a partir de las asignaciones y de los eventos. Si se escribe a mano, acabará contradiciendo a los datos.
- Eventos inmutables: una recogida mal registrada se corrige con un evento nuevo que anula el anterior, con autor y motivo. El historial es lo que permite responder a una reclamación.
- Unidades de medida explícitas: kilos, centímetros y metros cúbicos en campos con su unidad; nada de «peso» sin saber si es bruto, neto o facturable. El peso facturable es un cálculo sobre el envío, no un dato de la unidad.
- Paradas antes que tramos: el usuario planifica paradas; los tramos se derivan. Así no hay tramos huérfanos cuando se reordena una ruta.
- Versiones de lo que genera documentos: si un envío ya tiene documento emitido, cualquier cambio que afecte a sus datos esenciales debe dejar rastro y regenerar el documento según el procedimiento que corresponda.
07Errores frecuentes y cómo detectarlos
| Error de modelo | Síntoma en la operación | Corrección |
|---|---|---|
| Matrícula como columna del envío | Al partir un envío en dos camiones se duplica el envío y se factura dos veces | Mover el vehículo al viaje y relacionar por unidades |
| Unidades de carga sin identificador propio | Nadie sabe qué palé falta tras una entrega incompleta | Identificador por unidad y lectura en carga y descarga |
| Estado del envío escrito a mano | El cliente ve «entregado» con un palé todavía en plataforma | Derivar el estado de asignaciones y eventos |
| Viaje sin paradas | No se puede calcular el vacío ni el orden de entrega | Modelar paradas y derivar tramos en carga y en vacío |
| Peso facturable guardado como peso | Las sumas de carga útil no cuadran con la báscula | Separar peso real por unidad y peso facturable por envío |
Una prueba rápida para un modelo existente: intenta representar el caso trabajado de esta guía. Si para hacerlo hay que duplicar un envío, inventar un viaje sin vehículo o escribir una nota en un campo de observaciones, el modelo está pidiendo una separación que no tiene.
Para decidir
Criterios para decidir y checklist de revisión del modelo
- 01¿Puede un envío tener unidades en dos viajes distintos sin duplicarse?
- 02¿Puede un tramo llevar unidades de varios envíos y clientes, y cada envío conservar su documento y su tarifa?
- 03¿Tiene cada unidad de carga un identificador que se lee en carga y en descarga?
- 04¿Pertenecen el vehículo, el conductor y el transportista efectivo al viaje y no al envío?
- 05¿Se derivan los estados del envío de las asignaciones y los eventos?
- 06¿Se corrigen los eventos con eventos nuevos, con autor y motivo?
- 07¿Están separados el peso real de cada unidad y el peso facturable de cada envío?
- 08¿Se pueden reconstruir, para un envío cualquiera, sus viajes, sus documentos y su factura?
Si tu sistema actual falla en varias de estas preguntas, no siempre hay que cambiarlo: a veces basta con una capa que mantenga unidades y asignaciones al lado del programa de tráfico. Podemos revisar contigo el modelo de datos que tienes y decidir qué separar primero.
Fuentes
- Ley 15/2009, de 11 de noviembre, del contrato de transporte terrestre de mercancías (texto consolidado) — Boletín Oficial del Estado
- Orden FOM/2861/2012, de 13 de diciembre, por la que se regula el documento de control administrativo exigible para la realización de transporte público de mercancías por carretera (texto consolidado) — Boletín Oficial del Estado
- Reglamento (UE) 2020/1056 del Parlamento Europeo y del Consejo, de 15 de julio de 2020, sobre información electrónica relativa al transporte de mercancías (DOUE-L-2020-81225) — Boletín Oficial del Estado (copia del DOUE)
- SSCC, código seriado de unidad logística — GS1 España
Contenido informativo elaborado por colectivedata. No sustituye un análisis específico de tu caso.
Más sobre ingeniería de software
Relacionado
Guía · IntegracionesQué debe tener un TMS para gestionar el DeCAPara gestionar el documento electrónico de control administrativo (DeCA), un TMS tiene que guardar los datos del artículo 6 de la Orden FOM/2861/2012 y generar con ellos un PDF nativo de 5 MB como máximo antes de que empiece el servicio.
Guía · GuíasDiseño de una tabla de tarifas de transporteUna tabla de tarifas de transporte bien diseñada es un modelo de datos, no una hoja con precios.
Guía · Ingeniería de softwareCómo diseñar trazabilidad de piezas por número de serieLa trazabilidad por número de serie consiste en poder contar la historia completa de cada pieza: de qué está hecha, por dónde pasó, quién intervino y qué se midió.
Guía · Ingeniería de softwareCuándo conviene modernizar un software legacyQue un programa sea antiguo no es motivo suficiente para sustituirlo: muchos sistemas veteranos funcionan bien y concentran años de conocimiento del negocio.
Guía · Ingeniería de softwareDigitalización de documentación técnica de ingenieríaDigitalizar la documentación de ingeniería no consiste en escanear planos ni en mover carpetas a la nube.
IntegracionesInteroperabilidad de datosQue un dato signifique lo mismo en todos los sistemas que lo usan: contratos de datos con responsable, validaciones en la entrada, linaje de cada cifra y un proceso para cambiar.
IntegracionesAPIs, webhooks y eventosCómo diseñar las interfaces entre sistemas para que un mensaje repetido, un servidor caído o una versión nueva no corrompan datos ni dejen huecos sin explicar.
CapacidadTMS a medidaUn sistema de gestión de transporte construido sobre el modelo viaje, envío y unidad de carga, que genera documentos, costes y facturación desde los mismos datos.
SoluciónRentabilidad por viajeUna capa de cálculo sobre el TMS, la telemática y el ERP que imputa a cada viaje sus costes directos y su parte del retorno en vacío, con reglas escritas y datos trazables.
SoluciónGrupaje y consolidaciónUna capa de reglas sobre el TMS que propone qué envíos van en cada vehículo, explica cada asignación y cada rechazo, y retiene lo que necesita revisión humana.
También relacionado
Siguiente paso
¿Tienes una decisión de arquitectura parecida?
Cuéntanos dónde debe ejecutarse el sistema, con qué se conecta y qué no puede fallar.
Sin compromiso de aceptación: estudiamos cada caso antes de proponer nada. Cómo tratamos la información que compartes.