En transporte y transitario, el trabajo no se lo come a menudo el porte en sí, sino todo lo que lo rodea. Un pedido entra por correo, la confirmación vuelve en PDF, la carta de porte CMR viaja con el conductor y la tarifa está en la hoja de cálculo de una persona. Para un director de transporte o de liquidaciones eso suma una sola cosa: la información sobre un pedido se dispersa por decenas de sitios, y ninguno de ellos es la fuente de verdad. Una plataforma de software TMS bien diseñada reúne ese flujo, desde la entrada del pedido hasta la facturación.
Por nuestra experiencia, lo difícil no es dibujar una pantalla de «lista de pedidos», sino cerrar la cadena completa de documentos y dinero para que cuadre - lo que cuenta aquí es la coherencia de los datos, la auditabilidad y las integraciones, no una interfaz vistosa. No pretendemos tener una caja que encaje en cualquier transitario; en su lugar, cubrimos el proyecto con personas que diseñan y mantienen esos sistemas, en modelo de refuerzo de equipo o de equipo dedicado.
¿Por qué se ahogan las cargas en papeleo y correo?
El papel y un buzón funcionan bien mientras el volumen es bajo. El problema empieza con la escala: cada cambio de ruta, cada corrección de tarifa y cada documento que falta exigen copiar y pegar a mano, y la liquidación se hace «de memoria». Solemos ver unas cuantas fuentes recurrentes de fricción:
- pedidos por muchos canales a la vez (correo, teléfono, portal de cliente, EDI), sin un registro único,
- documentos sueltos en PDF y escaneos, desconectados de un envío concreto,
- tarifas en hojas de cálculo que nunca siguen el ritmo de los anexos y los recargos de combustible,
- liquidación a fin de mes, cuando la mitad de los detalles ya se han olvidado.
¿Cómo ordenamos el registro de pedidos y envíos?
La base de un TMS es un registro coherente en el que el pedido, el envío y los documentos son un único registro conectado, no tres mundos separados. Lo diseñamos en torno al flujo de trabajo real del transitario: la capa lleva un pedido por sus estados, desde la entrada, pasando por la asignación de transportista y vehículo, hasta la entrega y el cierre, y cada cambio deja un rastro. Describimos cada envío con los atributos que se usan en la liquidación y en los informes (dimensiones, peso, número de palés, Incoterms, ruta, transportista), y esos mismos datos alimentan después la tarificación y la factura.
¿Qué es el e-CMR y cómo digitalizamos los documentos de transporte?
La clásica carta de porte CMR es papel con firmas, fácil de perder y difícil de buscar. El e-CMR es su equivalente electrónico, basado en el protocolo adicional al convenio CMR, con firma digital y marca de tiempo en lugar de un bolígrafo. Para la liquidación eso cambia las reglas: el documento está disponible justo después de la entrega, no una semana más tarde cuando vuelve la carpeta del conductor.
En los proyectos de documentación montamos el flujo para que cada documento quede atado a un envío y a un estado concretos. Digitalizamos no solo el propio e-CMR, sino toda la familia de papeles de transporte: prueba de entrega (POD), pedidos, documentos de almacén, listas de empaque. Cuando un cliente todavía necesita papel, mantenemos una impresión coherente con la versión digital.
¿Cómo preparar los datos para el despacho de aduanas?
En los movimientos internacionales, el despacho de aduanas necesita datos completos y coherentes, o el envío se queda parado en la frontera. Un TMS puede preparar esos datos una vez, en el origen, y pasarlos adelante en lugar de obligar a reintroducirlos en otro sistema más.
Añadimos al registro los campos necesarios para las declaraciones: códigos arancelarios (HS/CN), país de origen, valor de la mercancía, peso, datos del expedidor y del destinatario. Como no pretendemos ser una agencia de aduanas, diseñamos una exportación e integración limpias con los sistemas aduaneros o con un agente: los datos salen en un formato acordado, listos para declarar.
¿Cómo funciona el motor de tarifas?
Una tarifa de transporte rara vez es un único número. Normalmente es un tarifario que depende de la ruta, el peso, el volumen, las zonas, los recargos de combustible y los anexos individuales con el cliente, y cuando todo eso vive en una hoja de cálculo, cada cambio es un riesgo. Por eso el corazón de un TMS es un motor de tarificación que calcula el precio a partir de reglas, no de la memoria de un comercial.
Montamos un motor así con unos pocos elementos que tienen que jugar juntos:
- tarifarios y tarifas por cliente, ruta, zona y tipo de carga,
- reglas de recargos (combustible, aduanas, ADR, reserva) aplicadas automáticamente,
- tarifarios versionados con fechas de validez, para que una tarifa antigua nunca caiga sobre un pedido nuevo,
- simulación y comparación de variantes antes de confirmar un pedido.
La misma lógica pone precio a un pedido a la entrada y lo liquida a la salida, de modo que la oferta y la factura por fin coinciden.
¿Cómo automatizamos la facturación y la liquidación?
La liquidación deja al descubierto cualquier hueco anterior. Si los datos del pedido, los documentos y las tarifas están en un mismo sitio, la factura y la liquidación con el transportista casi se escriben solas. Construimos una capa de liquidación que compara lo acordado con lo realmente ejecutado y captura las diferencias antes de que lleguen a contabilidad.
Esta capa hace varias cosas a la vez: calcula el importe al cliente y el coste del transportista, reúne recargos y correcciones, comprueba que esté el conjunto completo de documentos (POD, e-CMR) y prepara los datos para el sistema financiero y contable. La liquidación con el transportista corre sobre la misma lógica, así que el margen se ve en cada pedido y no solo en el informe mensual.
¿Cómo conectar un TMS con EDI y ERP?
Un TMS no vive solo. De un lado están los clientes y sus pedidos por EDI; del otro, el ERP, la contabilidad, la telemática y los portales de los transportistas. El valor del sistema crece allí donde deja de ser una isla.
Conectamos un TMS con su entorno para que los datos circulen sin reteclear a mano:
- EDI (por ejemplo EDIFACT, mensajes IFTMIN/IFTSTA) para intercambiar pedidos y estados con los clientes,
- ERP y el sistema contable para facturas, costes y registros de socios,
- telemática y GPS para estados y tiempos de entrega en ruta,
- APIs y webhooks hacia portales de cliente y bolsas de carga.
Tratamos cada integración como un contrato: formato acordado, gestión de errores, reintentos y monitorización, para que un mensaje malo no atasque todo el flujo.
¿Qué competencias aportamos a un proyecto de TMS?
En este tema no vendemos un despliegue de estantería; aportamos a las personas capaces de diseñar, construir y mantener un sistema así. Damos forma al equipo según el alcance concreto, no por si acaso, y cubrimos normalmente los roles que de verdad empujan un proyecto de TMS:
- un analista / arquitecto que entiende los procesos de transitario y los traslada a un modelo de datos,
- un desarrollador de backend que construye el motor de tarifas, la liquidación y la capa de integración,
- un desarrollador de frontend responsable de un panel de tráfico y liquidación legible,
- un especialista en integraciones / EDI que enlaza el TMS con el ERP, las aduanas y la telemática,
- opcionalmente un especialista DevOps que monta los entornos, el pipeline de CI/CD y la monitorización.
Verificamos las competencias antes de empezar y enchufamos al equipo al ritmo del cliente.
¿Cómo lo hacemos en RITS?
Lo hacemos como partner nearshore desde Polonia, con experiencia en proyectos de alta complejidad de datos e integraciones. No fingimos tener en un cajón un despliegue de TMS para un transitario concreto; en su lugar entregamos las competencias que cierran un proyecto así, desde el análisis hasta el mantenimiento.
Primero entendemos el proceso y solo después elegimos la tecnología y el equipo. Trabajamos en una zona horaria cercana, así que el equipo entra sin una rampa larga y va asumiendo poco a poco el flujo de pedidos, documentos y liquidaciones. Lo más habitual es que operemos como software a medida construido por nuestro equipo, o como refuerzo de equipo cuando hay que completar rápido competencias que faltan.
¿Por dónde empezar a construir un TMS?
Empieza por el tramo que más duele, normalmente el camino del pedido a la factura. Ese tramo revela qué datos faltan, qué documentos hay que digitalizar y dónde se desvía la tarifa respecto a la liquidación. El resto de los módulos se apilan después sobre la misma base. Tratamos las diferencias entre modelos de colaboración en nuestro artículo sobre modelos de colaboración en TI.
¿Pones en orden las cargas, los documentos y la liquidación? Hablemos - ajustaremos un equipo y una arquitectura a tu TMS.