CT-e abstract models

Este módulo es la base para la emisión del Conocimiento de Transporte Electrónico (CT-e, Modelo 57) en Odoo. Proporciona la estructura de datos completa y actualizada, en conformidad con los layouts oficiales de la SEFAZ para el CT-e 4.0.

Es importante resaltar que este módulo no realiza la emisión del CT-e por sí solo. Funciona como una biblioteca de modelos de datos abstractos (mixins). Su función principal es servir de base para un módulo de implementación, como el l10n_br_cte, que es responsable de mapear estos modelos en los documentos fiscales de Odoo (l10n_br_fiscal.document), añadir las reglas de negocio y realizar la comunicación con los web services de la SEFAZ. Esta arquitectura desacoplada sigue el mismo patrón de éxito ya utilizado por los módulos l10n_br_nfe_spec y l10n_br_nfe.

Estructura por Modal de Transporte

Para garantizar la conformidad con las particularidades de cada operación, el módulo implementa modelos de datos específicos para todos los modales de transporte previstos en la legislación:

• Rodoviario (cte.40.rodo): Contempla informaciones esenciales como el RNTRC y las Órdenes de Recolección asociadas.
• Aéreo (cte.40.aereo): Incluye campos para el número de la minuta, el número operativo del conocimiento aéreo (IATA) y detalles sobre la naturaleza y peligrosidad de la carga.
• Acuaviario (cte.40.aquav): Aborda datos como el valor del AFRMM, la identificación del buque, informaciones de balsas y el detalle de contenedores.
• Ferroviario (cte.40.ferrov): Permite detallar el tipo de tráfico (propio, mutuo, etc.) y los ferrocarriles involucrados en la operación.
• Ductoviario (cte.40.duto): Contiene campos para el valor de la tarifa, las fechas de inicio y fin del servicio y las características del ducto.
• Multimodal (cte.40.multimodal): Estructurado para gestionar el Certificado del Operador de Transporte Multimodal (COTM) y las informaciones de seguro asociadas.

Generación de Código Automatizada

La principal característica de este módulo es que el 100% de sus modelos de datos Odoo se generan automáticamente a partir de los esquemas XSD oficiales, publicados por el Portal del CT-e. Esta generación por xsdata-odoo garantiza máxima fidelidad a los layouts fiscales y agilidad en la actualización a nuevas versiones.

Aunque los esquemas XSD oficiales del CT-e se publican y mantienen en el Portal de la SEFAZ, la arquitectura de este proyecto se apoya en la biblioteca nfelib para la tarea de serialización de los datos en XML. Para facilitar el proceso de desarrollo y garantizar la consistencia, la propia nfelib almacena en su repositorio una copia actualizada de estos esquemas oficiales.

Por lo tanto, la práctica recomendada para (re)generar los modelos de este módulo es utilizar un clon local del repositorio de la nfelib como fuente para los archivos de esquema (.xsd), dirigiendo el comando de xsdata-odoo al directorio correspondiente.

Links:

• GitHub - akretion/xsdata-odoo
• GitHub - akretion/nfelib

El comando utilizado para generar los modelos de la versión 4.0 del CT-e fue:

Prefijo de los campos y versión

Con más de 1000 campos fiscales solo en el CT-e, con una media docena de documentos fiscales complejos, con 3000 módulos OCA, existiría un riesgo real de conflicto con los nombres de campos provenientes de los esquemas. Además, tenemos varias versiones del CT-e, la 3.0, la 4.0...

Ante esto se decidió que cada campo tiene un prefijo compuesto del nombre del schema y de algunos dígitos de la versión del esquema. En el caso cte40_. La elección de 2 dígitos permite que una actualización menor del esquema use los mismos campos (y datos en la base de datos entonces) y que un simple update Odoo (--update=...) consiga resolver la migración. Mientras que para un cambio mayor como de 3.0 a 4.0, se asumiría usar nuevos campos y nuevas tablas (para los objetos no Odoo) y que la lib nfelib trabajaría con los campos de la versión mayor del documento fiscal considerado.