Saltar al contenido

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
Nave de almacén con estanterías de palés, zona de preparación de pedidos y una carretilla elevadora

Foto: Axisadman · CC BY-SA 3.0

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.

  1. 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.
  2. Unidad de carga: lo que se mueve físicamente (palé, bulto, caja, contenedor), con su identificador, peso y medidas. Pertenece a un envío.
  3. 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.
  4. Tramo: el desplazamiento entre dos paradas consecutivas de un viaje. Es donde la unidad de carga y el vehículo se encuentran.
  5. 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

Esquema de referencia (propuesta de diseño, no un estándar)
EntidadClave y campos esencialesRelaciónQuién la crea
EnvíoIdentificador propio y referencia del cliente; cargador, destinatario, origen, destino, condiciones, fechas pactadasTiene 1..n unidades de cargaAtención al cliente o importación del pedido
Unidad de cargaIdentificador físico (por ejemplo, el SSCC de la etiqueta), tipo, peso, medidas, remontable o noPertenece a 1 envío; se asigna a 1..n tramosQuien prepara la mercancía; se confirma al recogerla
ViajeIdentificador, vehículo (tractora y remolque), conductor, transportista efectivo, fechaTiene 2..n paradas y 1..n tramosTráfico al planificar
ParadaViaje, orden, dirección, tipo (recogida, entrega, tránsito), ventana horariaPertenece a 1 viajeTráfico; se completa con eventos reales
TramoViaje, parada de salida y de llegada, distancia, en carga o en vacíoPertenece a 1 viaje; agrupa 0..n unidadesSe deriva de las paradas
Asignación unidad-tramoUnidad, tramo, estado (prevista, cargada, descargada), marcas de tiempoUne unidades y tramos (n:m)Tráfico al planificar; eventos al ejecutar
EventoObjeto afectado, tipo, momento, origen, autor, evidenciaSe refiere a envío, unidad, parada o asignaciónConductor, 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

Envíos y unidades de carga
  1. 01E-101

    Cliente y destino
    Cliente 1 → ciudad A
    Unidades
    U1, U2, U3 (palés)
    Peso total
    1.140 kg
  2. 02E-102

    Cliente y destino
    Cliente 1 → ciudad B
    Unidades
    U4 (palé)
    Peso total
    420 kg
  3. 03E-103

    Cliente y destino
    Cliente 2 → ciudad A
    Unidades
    U5, U6 (palés) y U7 (bulto suelto)
    Peso total
    760 kg
Viajes, tramos y asignaciones
Viaje y tramoDe → aUnidades asignadasEstado
V-1 · T1Polígono (recogida) → plataforma de tránsitoU1 a U7Descargadas en plataforma
V-2 · T1Plataforma → ciudad A, parada 1 (Cliente 1)U1, U2, U5, U6, U7En curso
V-2 · T2Ciudad A, parada 1 → ciudad A, parada 2 (Cliente 2)U5, U6, U7Prevista
V-3 · T1Plataforma → ciudad BU4Prevista
Sin tramoPlataformaU3Pendiente: 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

Escenarios habituales frente al esquema
EscenarioQué cambia en los datosQué no cambia
Un envío no cabe en un vehículoSus unidades se asignan a tramos de dos viajesUn solo envío, un solo cliente, una sola línea de factura
Consolidación de varios clientesUn tramo agrupa unidades de varios envíosCada envío conserva su documento, sus condiciones y su tarifa
Tránsito en plataformaLa unidad cierra un tramo de un viaje y abre otro de un viaje distintoLa unidad mantiene su identificador y su historial
Cambio de vehículo en rutaEl viaje cambia de vehículo o se crea un viaje nuevo desde la parada del cambioEnvíos y unidades no se duplican
Entrega parcial o rechazo de una unidadLa asignación de esa unidad queda rechazada con su evento y su evidenciaLas demás unidades del envío siguen su curso
Subcontratación de un tramoEl viaje de ese tramo tiene otro transportista efectivoEl 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

Síntomas de un modelo mal separado
Error de modeloSíntoma en la operaciónCorrección
Matrícula como columna del envíoAl partir un envío en dos camiones se duplica el envío y se factura dos vecesMover el vehículo al viaje y relacionar por unidades
Unidades de carga sin identificador propioNadie sabe qué palé falta tras una entrega incompletaIdentificador por unidad y lectura en carga y descarga
Estado del envío escrito a manoEl cliente ve «entregado» con un palé todavía en plataformaDerivar el estado de asignaciones y eventos
Viaje sin paradasNo se puede calcular el vacío ni el orden de entregaModelar paradas y derivar tramos en carga y en vacío
Peso facturable guardado como pesoLas sumas de carga útil no cuadran con la básculaSeparar 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

  1. 01¿Puede un envío tener unidades en dos viajes distintos sin duplicarse?
  2. 02¿Puede un tramo llevar unidades de varios envíos y clientes, y cada envío conservar su documento y su tarifa?
  3. 03¿Tiene cada unidad de carga un identificador que se lee en carga y en descarga?
  4. 04¿Pertenecen el vehículo, el conductor y el transportista efectivo al viaje y no al envío?
  5. 05¿Se derivan los estados del envío de las asignaciones y los eventos?
  6. 06¿Se corrigen los eventos con eventos nuevos, con autor y motivo?
  7. 07¿Están separados el peso real de cada unidad y el peso facturable de cada envío?
  8. 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.

Más sobre ingeniería de software

Relacionado

Todo el conocimiento

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.