Qué debe tener un TMS para gestionar el DeCA

El apartado primero exige que la aplicación contemple en sus bases, al menos, los datos del artículo 6 de la Orden FOM/2861/2012. La tabla los traduce a entidades de un TMS e indica quién responde de cada dato según el artículo 7, porque eso define qué usuario debe poder editarlo y qué validación conviene aplicar.

Dos detalles dan problemas en la práctica. El primero: muchos TMS guardan «cliente» y «remitente», pero no «cargador contractual». Cuando un operador logístico subcontrata a un autónomo, el cargador contractual frente a ese autónomo es el operador, no el cliente final. El segundo: el transportista efectivo cambia cuando se subcontrata un tramo, y el documento debe reflejar quién lo hace realmente.

El apartado segundo fija las características del fichero. Cada una se convierte en una decisión de implementación que conviene dejar escrita en la especificación del TMS.

Hay un orden lógico que evita errores: primero se reserva la URL, después se genera el QR con esa URL, a continuación se compone el PDF que incluye el QR y, por último, se publica en el repositorio. Si generas el PDF antes de conocer la URL, acabarás regenerándolo y la fecha de creación ya no coincidirá con la registrada.

El apartado tercero es el que más condiciona la arquitectura. La URL debe empezar por https:// con TLS 1.2 o superior, puede llevar tokens o cifrado, pero no puede caducar antes de que termine el servicio. Al invocarla, los agentes de vigilancia del transporte deben obtener la descarga directa del PDF. No es válida una URL que lleve a una página con inicio de sesión, con botones de descarga o con cualquier interacción manual. Siete días naturales después de terminar el servicio se puede desactivar la descarga.

• Separa dos capas: la URL pública, con un identificador largo e impredecible, y el archivo interno, donde vive el PDF durante el plazo de conservación.
• Configura el servidor para responder con el PDF y el tipo de contenido correcto, sin redirecciones a portales ni cookies obligatorias.
• Asocia a cada URL la fecha de fin del servicio y programa la desactivación pública a partir del séptimo día natural, si decides usar esa posibilidad.
• Registra cada descarga (fecha, hora, IP) para poder demostrar disponibilidad sin bloquear el acceso.
• Elige libremente el dominio: la resolución indica que no requiere comunicación previa.

La conservación es otra obligación: cargador contractual y transportista efectivo deben conservar los ficheros al menos un año, en el mismo repositorio o en otro. Cada uno puede tener el suyo y, si el fichero lo generó uno de ellos, al otro le basta con poder descargarlo durante ese año. Si tu TMS genera el DeCA para transportistas subcontratados, eso implica darles acceso de descarga durante un año, aunque la URL pública ya esté desactivada.

Durante el servicio los datos cambian: un remolque distinto, una descarga adicional, un peso corregido. El apartado quinto admite dos métodos y el apartado séptimo deja claro que son la única forma válida de modificar un DeCA; las anotaciones a mano sobre una copia impresa no se tienen en cuenta.

El apartado sexto permite agrupar varios envíos en un mismo DeCA cuando el cargador contractual y el transportista efectivo son los mismos, identificando para cada envío origen, destino, naturaleza y peso. El orden en que aparecen no implica orden de ejecución. Para el TMS, eso significa permitir documentos con varias líneas de envío sin perder la relación de cada línea con su pedido.

La copia para el conductor se entrega antes del inicio efectivo del servicio, en el móvil o impresa, y siempre con el QR. En una inspección, el conductor presenta el DeCA con el QR o, en su defecto, solo el QR. Por eso la aplicación del conductor debe mostrar el QR también sin cobertura.

Un operador logístico contrata a un transportista autónomo un servicio interior con dos descargas. El operador es el cargador contractual y el autónomo, el transportista efectivo. El TMS del operador genera el DeCA y lo comparte con el autónomo. A mitad de ruta, una avería obliga a enganchar otro semirremolque.

El mismo caso con el método 1 mantendría la URL y el QR, pero exigiría que el PDF muestre la matrícula antigua tachada como no válida, la nueva y el motivo del cambio. Es más cómodo para el conductor y más exigente para el generador de documentos.

• Generar el PDF al cerrar el servicio, para facturar, en lugar de antes de empezarlo.
• Usar como URL un enlace a un portal que pide usuario o muestra un botón «descargar».
• Enlaces firmados que caducan a las 24 horas en servicios de varios días.
• Fotografiar el albarán y subir la imagen como si fuera el DeCA.
• Guardar las fechas de creación solo en la base de datos y no en los metadatos del PDF, o al revés.
• Corregir datos sobrescribiendo el fichero sin dejar rastro del valor anterior.
• Dar por hecho que el cliente es el cargador contractual cuando hay intermediarios.
• Borrar los ficheros al desactivar la URL pública, antes de cumplir el año de conservación.

Ninguno de estos fallos se ve en una demostración del TMS. Aparecen en la primera inspección o en la primera subcontratación en cadena, por eso conviene probar el flujo con casos reales de tu operativa antes de la fecha de exigibilidad.