MDF-e abstract models

Este módulo es la base para la emisión del Manifesto Eletrônico de Documentos Fiscais (MDF-e, modelo 58) en Odoo, proporcionando una estructura de datos completa y fiel al leiaute oficial 3.00 de la SEFAZ.

Es importante entender que este módulo actúa como una biblioteca de modelos abstractos (mixins) y no realiza la emisión del MDF-e por sí solo. Su finalidad es ser la base para un módulo de implementación, como el l10n_br_mdfe, que es responsable de mapear estos modelos en los documentos fiscales de Odoo (l10n_br_fiscal.document) y de comunicarse con los web services de la SEFAZ. Esta arquitectura, que separa la estructura de datos de la lógica de emisión, es la misma utilizada con éxito en los módulos de la Nota Fiscal Eletrônica (l10n_br_nfe_spec y l10n_br_nfe).

El MDF-e es un documento fiscal que agrega y vincula múltiples documentos (como NF-e y CT-e) que amparan una carga transportada en un único vehículo, simplificando la fiscalización durante el trayecto.

Principales Conceptos y Estructura del MDF-e

El módulo l10n_br_mdfe_spec mapea con precisión la estructura jerárquica del manifiesto. Los conceptos más importantes implementados son:

• Agrupación por Municipio de Descarga (infMunDescarga): Esta es la principal lógica organizacional de un MDF-e. El módulo permite agrupar todos los documentos fiscales (NF-e y CT-e) que serán entregados en un mismo municipio, garantizando el correcto armado del XML.
• Documentos Vinculados: Dentro de cada municipio de descarga, es posible vincular:
• Conocimientos de Transporte (infCte): Para operaciones donde el emisor es un prestador de servicio de transporte.
• Notas Fiscales (infNFe): Para operaciones de transporte de carga propia o por transportadoras que realizarán la emisión de CT-e Globalizado posteriormente.
• Manifiestos Anteriores (infMDFeTransp): Utilizado en operaciones específicas del modal acuaviario.
• Totalizadores (tot): El módulo contiene modelos para totalizar la carga, incluyendo la cantidad de documentos, el valor total de la carga y el peso bruto total.
• Seguro de la Carga (seg): Estructuras para informar los datos del seguro, el responsable (emisor o contratante), la aseguradora y los números de póliza y avería.

Estructura por Modal de Transporte

El MDF-e exige informaciones distintas para cada modalidad de transporte. El l10n_br_mdfe_spec ofrece modelos de datos específicos para cada uno de ellos:

• Rodoviario (mdfe.30.rodo): Es el más detallado, incluyendo:
• infANTT: Informaciones para la Agencia Nacional de Transportes Terrestres, como el RNTRC.
• infCIOT: Para el Código Identificador de la Operación de Transporte.
• valePed: Para el Vale-Peaje obligatorio.
• infContratante e infPag: Para identificar a los contratantes y detallar las informaciones de pago del flete.
• veicTracao, veicReboque, condutor: Modelos para detallar los vehículos de la composición y sus respectivos conductores.
• Aéreo (mdfe.30.aereo): Contempla campos para el número del vuelo (nVoo), y los códigos IATA/OACI de los aeródromos de embarque (cAerEmb) y destino (cAerDes).
• Acuaviario (mdfe.30.aquav): Aborda datos como el IRIN, el número del viaje (nViag), los puertos y terminales de embarque, descarga y transbordo, además de informaciones del convoy.
• Ferroviario (mdfe.30.ferrov): Permite detallar las informaciones del tren (prefijo, origen, destino) y de cada vagón de la composición.

Generación de Código Automatizada

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

Aunque los esquemas XSD oficiales del MDF-e son publicados y mantenidos 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 esos 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 del xsdata-odoo al directorio correspondiente.

Links:

• GitHub - akretion/xsdata-odoo: Odoo abstract model generator from xsd schemas using xsdata
• GitHub - akretion/nfelib: nfelib - bindings Python para e ler e gerir XML de NF-e, NFS-e nacional, CT-e, MDF-e, BP-e

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

Prefijo de los campos y versión

Con más de 500 campos fiscales solo en el MDF-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 MDF-e, la 2.0, la 3.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 mdfe30_. 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.