Cómo generar el DeCA desde Odoo: CSV, API y controles

Empieza por la expedición, no por todas las tablas de Odoo

El primer paso es elegir un registro que identifique de forma estable la operación que se documentará. Según la configuración, la referencia puede partir de un pedido de venta, una entrega, un albarán, un movimiento logístico o un modelo propio. No existe una correspondencia universal: dos bases de Odoo pueden tener aplicaciones, campos de Studio y módulos desarrollados de manera distinta. Antes de integrar, toma una expedición ficticia y localiza el origen real de cada dato.

La Orden FOM/2861/2012 exige un documento por cada envío sujeto a su ámbito. Entre los datos esenciales figuran cargador contractual, transportista efectivo, origen, destino, naturaleza y peso de la mercancía, fecha, matrículas y autorización especial cuando corresponda. Un contacto comercial puede aportar razón social, NIF o domicilio, pero no debe asumirse que la dirección de facturación es el lugar de carga ni que el cliente de la venta ocupa siempre el papel de cargador contractual.

Identifica la versión, modalidad de alojamiento, plan y módulos activos de Odoo.
Selecciona el objeto y la referencia que representan una expedición concreta.
Enumera campos estándar, campos de Studio y modelos desarrollados a medida.
Señala qué información llega después desde tráfico o desde el transportista.

Opción 1: exportar un archivo controlado

La documentación oficial de Odoo explica la exportación e importación de registros y el uso de archivos CSV o Excel. Para un piloto DeCA, una exportación filtrada permite revisar el contenido antes de automatizarlo. Conviene guardar una plantilla con nombres de columna estables, codificación conocida y una fila por expedición. Si un pedido contiene varias líneas, debe acordarse cómo se agregan naturaleza, unidades y peso sin perder información relevante.

El identificador externo es especialmente útil. Odoo documenta que conservar el External ID permite relacionar registros y actualizar datos sin crear duplicados. En el flujo documental, la referencia de Odoo debe combinarse con la organización y el tipo de objeto para construir una clave idempotente. Así, volver a entregar el mismo archivo puede actualizar un borrador o informar de que ya fue procesado, en lugar de emitir dos documentos.

Aplica en Odoo un filtro que deje solo las expediciones pendientes del periodo.
Exporta únicamente los campos necesarios y conserva el identificador externo.
Rechaza fórmulas, columnas desconocidas, filas duplicadas y formatos ambiguos.
Muestra una previsualización y los errores antes de confirmar la importación.

Opción 2: integrar mediante la API externa

Odoo 19 incorpora la API externa JSON-2, accesible por HTTP con una clave y sujeta a los permisos, reglas de registro y acceso a campos del usuario. La propia documentación indica que el acceso externo está disponible en planes Custom y que los modelos, campos y métodos dependen de cada base. Por eso una integración debe descubrir y fijar el contrato de datos de la instalación concreta, sin copiar nombres técnicos de un ejemplo y darlos por universales.

La conexión debería leer solo registros autorizados y evitar operaciones de escritura si no son necesarias. Odoo recomienda un usuario bot dedicado para integraciones prolongadas. La clave debe permanecer en el servidor, tener alcance y duración limitados, rotarse antes de caducar y revocarse si deja de usarse. En Odoo 19 las claves generadas manualmente no pueden durar más de tres meses; este detalle debe incorporarse al mantenimiento para que una caducidad no interrumpa la preparación de documentos.

Confirma que el plan y la versión permiten el método de API elegido.
Usa un usuario técnico con los permisos mínimos sobre modelos y campos concretos.
Guarda las claves fuera del navegador y registra rotación y revocación.
Trata 401, 403, límites y errores de negocio sin descartar expediciones pendientes.

Mapear responsabilidades y campos del DeCA

El mapeo debe indicar para cada dato el modelo y campo de Odoo, la transformación aplicada y la persona responsable de validarlo. El cargador contractual responde de la exactitud de las partes, origen, destino, naturaleza y peso; el transportista efectivo responde de autorización especial, fecha y matrículas. La automatización puede comprobar formatos o detectar ausencias, pero no puede decidir por sí sola qué entidad ocupa cada papel contractual.

No todos los datos tienen que residir en Odoo. Puede ser más seguro combinar la información comercial con una pantalla de tráfico que complete vehículo, remolque y transportista efectivo. Un campo condicional, como la autorización especial, debe activarse cuando corresponda a la operación. Las observaciones deben mantenerse separadas de los campos esenciales y no utilizarse como contenedor genérico para esconder datos que deberían ser estructurados.

Partes: nombre o razón social, NIF y domicilio exigible.
Trayecto: origen y destino reales del envío.
Mercancía: naturaleza, peso y unidad o regla de cálculo.
Transporte: fecha, tractor, remolque y autorización especial cuando proceda.
Trazabilidad: referencia Odoo, responsable, fecha de lectura y estado documental.

Emitir el PDF antes de que empiece el servicio

La Resolución de 5 de junio de 2026 exige transformar los datos conocidos en el fichero electrónico antes del inicio efectivo del servicio y registrar la fecha y hora de creación. El resultado debe ser un PDF nativo digital, legible y de hasta 5 MB. Cada documento almacenado necesita una URL única y un código QR; la URL utiliza HTTPS y debe producir la descarga directa del PDF durante una inspección, sin credenciales ni pasos manuales adicionales.

La marca de pedido confirmado o entrega preparada en Odoo no acredita por sí sola que el DeCA se haya generado y entregado. El flujo necesita estados distintos para extracción, validación, emisión, entrega al conductor y rectificación. Si la matrícula cambia durante el servicio, debe conservarse el dato anterior y el motivo o generarse un nuevo PDF completo con su URL y QR, manteniendo el original. Actualizar únicamente el registro de Odoo deja sin resolver la versión documental que va a bordo.

Bloquea la emisión si falta un campo esencial.
Registra la fecha de creación y cada modificación del fichero.
Entrega una copia electrónica o impresa con QR al conductor.
Conserva el documento y sus versiones durante el plazo aplicable.

Prueba de aceptación con CSV y API

Prepara datos sintéticos para varias situaciones: una entrega simple, varias líneas de mercancía, un destino distinto de la facturación, remolque, un registro sin peso y un cambio de matrícula. Ejecuta primero el recorrido por archivo y, si la API está disponible, compara los mismos campos obtenidos por JSON-2. La prueba debe demostrar que ambos caminos aplican las mismas validaciones y que un reintento no duplica documentos.

Comprueba después el resultado fuera de Odoo: abre el PDF, revisa tamaño y datos, escanea el QR desde un móvil sin sesión, descarga el fichero y simula una rectificación. Documenta los campos que no pudieron obtenerse y quién los completa. Si la base utiliza módulos propios, nombres técnicos modificados o reglas particulares, el conector necesita análisis y presupuesto. La prueba valida el flujo configurado; no certifica todas las bases de Odoo ni sustituye la revisión jurídica de cada transporte.

Verifica casos correctos, incompletos, duplicados y rectificados.
Prueba permisos insuficientes y caducidad de la clave sin perder la cola.
Revisa el QR y la descarga desde otra red y sin autenticación previa.
Aprueba por escrito el mapa de campos antes de automatizar producción.

Preguntas frecuentes

¿Odoo incluye un DeCA válido de serie?

No puede afirmarse para todas las versiones y bases. Odoo aporta registros, exportación e interfaces de integración, pero el PDF, el QR, la URL, los campos y la trazabilidad deben comprobarse en la solución configurada.

¿Es mejor usar CSV o API?

El CSV facilita un piloto revisable y puede ser suficiente con poco volumen. La API reduce pasos repetidos, pero exige plan compatible, permisos mínimos, gestión de claves, tratamiento de errores y un contrato estable de campos.

¿Qué identificador evita duplicados?

Puede partir del External ID o de otra referencia estable de Odoo, combinada con la empresa y el tipo de objeto. El servidor debe comprobar esa clave de forma idempotente antes de crear el documento.

¿Qué pasa si existen módulos personalizados?

Hay que revisar los modelos, campos, permisos y eventos reales de esa base. Las personalizaciones pueden requerir un mapeo o desarrollo separado y no se incluyen automáticamente en una conexión estándar.

Fuentes oficiales y técnicas

Fuentes consultadas o verificadas el 17 de septiembre de 2026. Verifica siempre la versión consolidada y su aplicación a tu caso.