anterior

Nueva normativa: DeCA

La Ley 09/2025 del 3 de diciembre y en especial la Disposición transitoria octava indica de la obligatoriedad, a partir del 5 de octubre del 2026 la emisión 'electrónica' del Documento de Control Administrativo, denominado ahora Documento Electrónico de Control Administrativo: DeCA.

El DeCA deberá incluir un código QR que permita la descarga del documento de control por parte de las autoridades ante una posible inspección de carretera.

Ponemos a tu disposición información adicional en los siguientes enlaces:

La gestión que realiza TP.NET en lo referente al DeCA es una gestión nativa y no requiere de ningún otro software / plataforma / TMS ajeno, externo o de terceros.

TP.NET dispone de 4 opciones sobre el DeCA que se configuran en la pantalla de parámetros y que se describen a continuación.

1) TP.NET no gestiona el DeCA

No se activa la gestión del DeCA en la pantalla de configuración:



Existen diversos motivos para indicar que TP.NET no gestione el DeCA:

2) TP.NET gestiona el código QR del DeCA pero no lo 'sube' automáticamente




TP.NET genera el código QR en el propio ticket de báscula (ahora llamado DeCA) pero no lo 'sube' automáticamente a ningún sitio.

En el ticket de báscula se muestra el código QR. Si Tráfico lee ese código QR lo que ocurrirá es que se descargará ese mismo documento en formato PDF siempre y cuando se haya publicado manualmente en una nube para su acceso público.



Consideración importante para esta opción:

La normativa, que puedes consultar en el PDF Webinar que está al principio de esta página, establece para la URL de descarga de forma clara y que no deja lugar a dudas o ambigüedades lo siguiente:
Se hace especial énfasis en lo anterior, ya que puede ser probable y posible que, para una 'nube' de tipo OneDrive, SharePoint, Google Drive, DropBox, etc, ocurra lo siguiente:
Por lo tanto, asegúrate que tu 'nube' no realiza ninguno de los 2 puntos anteriores.

3) TP.NET gestiona el código QR del DeCA y lo 'sube' automáticamente usando una API externa a TP.NET




TP.NET genera el código QR y automáticamente al finalizar la pesada, 'sube' el ticket de báscula que incluye ese código QR a una nube (gestionada por el cliente) mediante una API externa a TP.NET

En el ticket de báscula se muestra el código QR. Si Tráfico lee ese código QR lo que ocurrirá es que se descargará ese mismo documento en formato PDF.



TP.NET llama a la API indicada en la configuración, usando un método POST y usando como argumento el parámetro con nombre file en el body del post que contiene el documento PDF.

En este enlace (Se abre en una pestaña nueva) hay información adicional al respecto.

Tanto la API externa como la gestión de la nube por parte del cliente (o del proveedor de la API externa) es ajena a TP.NET y tal y como se indica en la configuración, el proveedor de la API será el responsable de que los archivos se guarden correctamente y sean públicos para que Tráfico pueda acceder a ellos mediante el código QR.

Consideración importante para esta opción:

Las mismas consideraciones indicadas para la opción 2]

4) TP.NET solución 'llave en mano': gestión del código QR del DeCA y 'subida' automática

Las tres opciones anteriores no requieren de licencia adicional en TP.NET ya que el proceso es manual o ajeno a TP.NET

Esta cuarta opción sí requiere de una licencia especial, pero ofrece un sistema completamente 'listo para usar' sin configuraciones especiales. Además puede combinarse con el envío automático por e-mail al conductor para tener un sistema completamente desatendido en lo que respecta al DeCA.

El principal hándicap, obstáculo o dificultad de esta nueva normativa no es la generación del código QR, que puede ser más o menos trivial. El principal obstáculo es conseguir que los documentos PDF sean públicos desde una nube segura y accesibles para su descarga por parte de Tráfico. La solución 'llave en mano' de TP.NET cubre esta necesidad y se encargará de todo el proceso, de forma transparente:



TP.NET genera el código QR y automáticamente al finalizar la pesada, 'sube' el ticket de báscula que incluye ese código QR a una nube gestionada por DAII, que asegurará que el ticket de báscula en formato PDF esté accesible para Tráfico para su descarga. La nube gestionada por DAII usa Microsoft Azure con servidores ubicados dentro de la Unión Europea, asegurando un SLA de un 99,95 % y con conexión segura https TLS v1.2 con certificado digital emitido por una autoridad certificadora.

En el ticket de báscula se muestra el código QR. Si Tráfico lee ese código QR lo que ocurrirá es que se descargará ese ticket en formato PDF.



Al usar esta opción el cliente no se tiene que preocupar por la gestión de la nube, ya que esta opción 'llave en mano' se ocupará de todos estos aspectos. Simplemente se hace una pesada y TP.NET se encargará de todo.

Para los documentos enviados a nuestra nube, es obligatorio y necesario que la hora de Windows en el equipo que tiene TP.NET esté sincronizada con un servidor de hora. Si la hora de Windows en el PC de TP.NET que sube los DeCAs a nuestra nube no es correcta, se producirá un error de tipo wrong header [3] y el PDF no se subirá a la nube. Ten esto en cuenta ya que es ìmportante para este caso.


Detalle en la barra de estado que indica que todos los documentos se han subido correctamente (verde):



Detalle en la barra de estado que indica que algún documento no se ha subido correctamente (amarillo):



Si se hace click en esa opción de la barra de estado se mostrará el detalle de las últimas 'subidas', ya sean subidas correctas o incorrectas.

En la pantalla del parte de pesadas ahora existe una nueva opción para re-subir un documento, por ejemplo si se hace una modificación. Sí además está configurada la opción de envío automático por mail, se genera el PDF, se envía por e-mail y se sube automáticamente a la nube de DAII:



Código QR en editor de albaranes

En caso de modificar o crear nuevas plantillas de tickets, TP.NET guarda la dirección de descarga en:



El contenido del código QR puede usar el campo URL_DECA

Propiedades del código QR:



Contenido del código QR:



Gestión del DeCA

La gestión del DeCA (incluyendo el código QR y la subida automática a una NUBE) se realiza tanto de las pesadas realizadas manualmente desde la pantalla principal de TP.NET o de las pesadas realizadas desde el Servidor Web, pero también se puede realizar desde:

Pesadas realizadas desde un Terminal de Pesaje Automático (TPA):



Pesadas realizadas desde TP.TOUCH:



Anexo

Ante la avalancha de consultas recibidas por este tema, y en general, por el desconocimiento de la normativa legal, hemos generado este anexo:

DeCA en TP.NET: quién es quién y qué debe contener el ticket

En todas las operaciones hay que distinguir claramente dos figuras:

TP.NET permite gestionar estas figuras mediante sus tablas de Empresa transportista, Conductor y Operador de Transporte. El ticket/DeCA puede adaptarse para incluir los datos necesarios en cada caso.

Importante: que el ticket/DeCA se genere desde la báscula de una planta no significa que la empresa que opera la báscula sea necesariamente el cargador contractual. El documento debe identificar correctamente a cada interviniente.

Caso 1 — Vendemos el material y contratamos el transporte

Ejemplo: nuestra empresa vende 25 t de árido a un cliente y nosotros contratamos directamente al transportista para llevarlo al cliente.

El ticket/DeCA de TP.NET debe identificar claramente:

Ejemplo:

Cargador contractual: Áridos Barcelona, S.L.
Transportista efectivo: Transportes Pérez, S.L.
Origen: Planta Barcelona
Destino: Cliente XYZ, Girona
Mercancía: Árido 0/20
Neto: 26.480 kg

Caso 2A — El cliente contrata directamente al transportista y este viene a nuestra planta

Ejemplo: vendemos el material al cliente. El cliente de Asturias contrata directamente a Transportes Pérez para recogerlo en nuestra planta de Barcelona y llevarlo a Asturias.

El ticket/DeCA de TP.NET debe indicar:

Ejemplo:

Cargador contractual: Cliente Asturias, S.A.
Transportista efectivo: Transportes Pérez, S.L.
Expedidor/planta de carga: Áridos Barcelona, S.L.
Origen: Planta Barcelona
Destino: Oviedo
Neto: 26.480 kg

La clave: no debemos poner nuestra empresa como cargador contractual simplemente porque el ticket se genere en nuestra báscula.

Caso 2B — El cliente contrata a un operador de transporte

Ejemplo: el cliente de Asturias contrata a un operador de transporte, que organiza el servicio y contrata a Transportes Pérez para realizar físicamente el viaje.

El ticket/DeCA de TP.NET debe diferenciar:

Ejemplo:

Cargador contractual: Cliente Asturias, S.A.
Operador de transporte: Logística Norte, S.L.
Transportista efectivo: Transportes Pérez, S.L.
Expedidor/planta: Áridos Barcelona, S.L.
Neto: 26.480 kg

La clave: no confundir operador de transporte con transportista efectivo. Son papeles diferentes y TP.NET dispone de tablas separadas para gestionarlos.

Caso 3 — Nuestra empresa vende el material y contrata el transporte, pero la carga se realiza en otra planta

Ejemplo: nuestra empresa vende el árido y contrata a Transportes Pérez. El material, sin embargo, se carga en una planta externa que utilizamos como punto de expedición.

El ticket/DeCA debe identificar:

La clave: el lugar donde se realiza físicamente la carga no determina por sí solo quién es el cargador contractual.

Caso 4A — El cliente contrata al transportista; nosotros somos la planta de carga

Ejemplo: el cliente de Asturias es quien contrata al transportista. El camión viene a nuestra planta de Barcelona, donde cargamos el material y obtenemos el peso definitivo.

Este es un caso en el que TP.NET resulta especialmente útil. El camión puede llegar con un DeCA generado previamente por el cargador contractual o el transportista. Una vez realizada la carga y obtenida la pesada definitiva, TP.NET puede generar desde la propia báscula el documento con los datos definitivos.

El ticket/DeCA generado por TP.NET debería mostrar, como mínimo:

Cargador contractual: Cliente Asturias, S.A.
Transportista efectivo: Transportes Pérez, S.L.
Expedidor/planta de carga: Nuestra empresa
Origen: Planta Barcelona
Destino: Asturias
Mercancía: Árido 0/20
Tara: 14.820 kg
Bruto: 41.300 kg
Neto: 26.480 kg
Matrícula: 1234-ABC / remolque XXXXX
Fecha/hora: XX/XX/XXXX XX:XX
QR: URL del PDF DeCA

El documento se imprime en la báscula y se entrega al conductor.

La clave: que el DeCA se genere desde nuestra báscula no convierte a nuestra empresa en cargador contractual. El documento debe identificar al cliente como cargador contractual y al transportista como transportista efectivo.

Caso 4B — El cliente contrata el transporte y nosotros también somos el transportista

Ejemplo: el cliente contrata a nuestra empresa para realizar el transporte y somos nosotros quienes ponemos el camión/conductor que realiza físicamente el viaje.

El ticket/DeCA debe indicar:

Cargador contractual: Cliente XYZ
Transportista efectivo: Nuestra empresa
Origen: nuestra planta
Destino: cliente
Mercancía
Peso real
Matrícula(s)
Fecha/hora
QR/URL

La clave: aquí nuestra empresa puede aparecer simultáneamente como planta/expedidor y como transportista efectivo, pero sigue sin ser el cargador contractual si quien contrató el transporte fue el cliente.

Regla práctica para configurar TP.NET

Antes de generar el ticket/DeCA hay que responder a estas dos preguntas:

  1. ¿Quién contrata directamente el transporte?
    → Cargador contractual
  2. ¿Quién realiza físicamente el transporte?
    → Transportista efectivo

Después, TP.NET puede añadir además:

No se debe confundir quién genera físicamente el documento desde TP.NET con quién es jurídicamente el cargador contractual.

En particular, una planta puede generar desde su propia báscula un DeCA en el que el cargador contractual sea un tercero.

Esquema rápido

Caso Cargador contractual Transportista efectivo ¿Desde dónde puede generarse el ticket/DeCA?
1 Nuestra empresa Transportista contratado por nosotros Nuestra báscula
2A Cliente Transportista del cliente Nuestra báscula
2B Según contratación Transportista que realiza el viaje Nuestra báscula
3 Nuestra empresa Transportista contratado por nosotros Báscula de la planta de carga
4A Cliente Transportista del cliente Nuestra báscula
4B Cliente Nuestra empresa Nuestra báscula

En todos los casos: el documento debe permitir identificar inequívocamente quién es el cargador contractual, quién es el transportista efectivo, qué se transporta, origen, destino, vehículo, fecha/hora y los restantes datos exigibles, además del QR/URL correspondiente al DeCA.


(*) Aclaración ¿No es 2A y 4A lo mismo?:

Podría existir una diferencia comercial, no jurídica a efectos del DeCA:

2A: vosotros vendéis el material al cliente y el cliente contrata el transporte.

4A: el material/servicio puede pertenecer a una operación en la que el cliente es quien encarga la expedición y vosotros actuáis como planta de carga, aunque no seáis necesariamente quienes venden la mercancía.

Pero desde el punto de vista de quién es cargador contractual, quién es transportista efectivo y qué debe hacer TP.NET, son equivalentes.

Tendiendo lo anterior en cuenta, si quieres, puedes considerar 2A igual que 4A.

Resumen

TP.NET — DeCA: ¿qué empresa pongo en cada campo?

Antes de generar el DeCA, identifica primero las dos figuras principales:

Que el ticket se genere desde nuestra báscula NO determina quién es el cargador contractual.

¿Qué selecciono en TP.NET?

Dato de TP.NET ¿Qué persona/empresa corresponde?
Empresa transportista La empresa que realiza físicamente el transporte.
Conductor El conductor que realiza ese transporte.
Operador de transporte El operador que interviene en la organización del transporte, cuando exista.
Cargador contractual Quien contrató directamente el transporte.
Expedidor / planta La planta donde se expide/carga físicamente la mercancía.

Ejemplos rápidos

Caso 1

Nosotros vendemos y nosotros contratamos el transporte.

Caso 2A

El cliente contrata al transportista y el camión viene a nuestra planta.

Caso 2B

El cliente utiliza un operador de transporte.

No confundir operador de transporte con transportista efectivo.

Caso 3

Nosotros contratamos el transporte, pero la carga se realiza en otra planta.

Caso 4A

El cliente contrata el transporte y el camión carga en nuestra planta.

TP.NET puede generar el DeCA desde nuestra báscula aunque nosotros no seamos el cargador contractual.

Caso 4B

El cliente contrata el transporte y nosotros realizamos físicamente el viaje.

El ticket/DeCA debe dejarlo claro

Regla de oro: quien genera el ticket desde TP.NET no tiene por qué ser el cargador contractual. Primero se determina quién contrató el transporte y quién lo realiza físicamente; después se configura el documento.


(*) Aclaración 2B: Depende de cómo esté estructurada realmente la contratación. Lo importante para el usuario de TP.NET es no confundir la tabla de Operador de Transporte con la de Empresa transportista.

TP.NET — DeCA: Uso de transportista y conductor. ¿Quién es el transportista efectivo?

Depende. Si el conductor es empleado/contratado por el transportista o no y de quien es propiedad del camión.

En este caso el transportista efectivo es Transportes Pérez, S.L.

Miguel García no es el transportista efectivo por el mero hecho de conducir el camión.

Si Miguel García es autónomo y él mismo realiza materialmente el transporte, entonces Miguel García puede ser el transportista efectivo, aunque Transportes Pérez, S.L. sea quien haya contratado con el cliente y haya subcontratado a Miguel.

En caso de subcontratación:

Cliente Asturias → contrata a Transportes Pérez → Transportes Pérez subcontrata a Transportes López → Miguel García, empleado de Transportes López, hace el viaje.

La clave es la empresa/transportista que está al final de la cadena de subcontratación, no la persona física que conduce.

La propia definición normativa del documento de control exige identificar como transportista efectivo al transportista que realiza el transporte, y el Ministerio, en la FAQ, dice expresamente que, cuando hay subcontratación sucesiva, las responsabilidades del DeCA recaen en “quien realiza materialmente el transporte, el último de la cadena de subcontratación” y en quien lo contrata, es decir, el cargador contractual.

Ten en cuenta que en TP.NET hay dos tablas diferenciadas, una para transportistas y otra para conductores, que en muchas ocasiones, y basada en nuestra experiencia tiende a confundirse y usarse el transportista como conductor, cuando realmente, a efectos jurídicos son dos figuras diferentes.

TP.NET dispone de todas las tablas y campos necesarios para cumplir con la legislación vigente: Orden FOM/2861/2012, LOTT 102.2 16/1987, Ley 14/2022 de 1 de agosto y Ley 09/2025 del 3 de diciembre. Otra cuestión es que el cliente haga uso de TP.NET y utilice los campos/tablas de forma no adecuada.

TP.NET — DeCA: Conservación de los PDF ante inspecciones en la empresa

La normativa exige que el código QR sea accesible por tráfico durante al menos 7 días naturales.

Esa es la normativa para la inspección. Sin embargo existe otra normativa para la conservación, que afecta a:

Esas dos figuras jurídicas están obligadas por ley a mantener durante 1 año el documento electrónico en formato PDF.

Ante una posible inspección, ya bien en la empresa del cargador contractual o del transportista efectivo, pasados, uno, dos, tres, nueve u once meses tras la finalización del servicio, la inspección requerirá del documento electrónico, y en ningún caso aceptará el 'documento impreso'.

El cargador contractual, habitualmente la figura jurídica que tiene TP.NET, la báscula y que genera el ticket, dispone de esos documentos PDF en la carpeta configurada en TP.NET

El transportista efectivo debería usar el código QR para obtener el documento electrónico tan pronto como inicie o finalice el servicio, y no a los 178 días (es un ejemplo).

La política de retención de los documentos PDF almacenados en nuestra nube es de 1 año. Transcurrido ese periodo, los documentos ya no serán accesibles.

De todos modos aconsejamos 2 cosas: