Módulo fiscal brasileiro

Clasificaciones fiscales

En primer lugar, este módulo trae una variedad de registros fiscales para productos, socios o empresas. A la hora de emitir documentos fiscales como NF-e, NFS-e etc... incluso las empresas del régimen simplificado o MEI necesitan varios de estos registros. Y las empresas del régimen normal los necesitan para calcular los impuestos o emitir documentos fiscales.

Productos:

• tipo fiscal
• NCM (con enlaces con los impuestos)
• género fiscal
• CEST
• NBM
• NBS
• tipo de servicio
• unidades fiscales

Socios:

• CNAE
• perfil fiscal

Concepto de documento fiscal

Odoo nativo no tiene el concepto de documento fiscal. El concepto más parecido sería el account.move e incluso hasta la versión 10.0 la localización extendía el invoice para soportar las NF-e y NFS-e solamente. En aquella época no era razonable que consideraras hacer el SPED en Odoo, el propio core de Odoo no tenía madurez para eso, así que era válido el enfoque empírico de ir soportando más casos de NFe dentro del invoice Odoo solamente.

Sin embargo, en la v12, maduramos el framework XML/SOAP de forma que se vuelve razonable soportar varios documentos fiscales (NF-e, NFS-e, MDF-e, CT-e, EFD-Reinf, e-Social, GNRE, BP-e...) con la calidad OCA dentro de Odoo. También, aunque complejo, el core de Odoo finalmente tiene soporte suficiente para las operaciones de una empresa que haría el SPED.

Con esto se vuelve interesante tener el concepto de documento fiscal l10n_br_fiscal.document independiente del invoice Odoo para soportar todos los documentos fiscales realmente, de forma modular. Otro motivo para tener el concepto de documento fiscal fuera del módulo account es que cuando analizas el código de este módulo l10n_br_fiscal, casi nada de él podría hacerse mediante el módulo account de Odoo. Entonces tener este módulo l10n_br_fiscal que no depende del módulo account también es una forma de modularizar la localización para facilitar su mantenimiento, especialmente cuando se trata de migrar y que el módulo puede haber cambiado bastante como fue el caso entre la v8.0 y la v9.0 o la v12.0 y v13.0 por ejemplo. También facilita la gobernanza del proyecto posibilitando que personas sean responsables de diferentes partes. El módulo l10n_br_fiscal fue principalmente extraído del módulo l10n_br_l10n_br_account_product de las v7.0 a las v.10.0.

Este módulo l10n_br_fiscal es agnóstico de cualquier tecnología XML o SOAP. Contiene solo lo que hay en común entre los documentos fiscales, pero estos últimos se implementan en otros módulos. Para un determinado documento fiscal como la Nf-e, tienes entonces por ejemplo:

• nfelib: un paquete de data bindings puro Python (que no depende de Odoo). En general usamos un generador de código para generar esos bindings a partir de los esquemas XSD de la hacienda.
• l10n_br_nfe_spec: un módulo de mixins Odoo gestionados también a partir de los XSD. Esos mixins son solo las estructuras de datos de las especificaciones antes de ser inyectados en objetos Odoo existentes (como res.partner o l10n_br_fiscal.document) o incluso convertidos en concretos en caso de que no existan objetos en Odoo o en la OCA para ellos ya.
• l10n_br_nfe: un módulo Odoo que se encarga de inyectar esos mappings fiscales en los objetos Odoo y que implementa la lógica como los wizards para la transmisión.

La transmisión se realiza usando una lib de transmisión como erpbrasil.doc (basada en Python Zeep). Importante: en el caso de la NFS-e, la ausencia de estándar nacional hoy y la simplicidad del modelo (comparado con la NFe) hace que se haya decidido no usar un módulo de mixins fiscales Odoo gestionados, el mapping con la lib de binding se hace manualmente, familia de NFS-e por familia.

Además, la mayoría del código del l10n_br_fiscal.document y de sus líneas l10n_br_fiscal.document.line está en realidad hecho dentro de mixins 10n_br_fiscal.document.mixin y 10n_br_fiscal.document.line.mixin respectivamente. Esos mixins pueden así ser inyectados en otros objetos Odoo que preceden a los documentos fiscales y pueden almacenar entonces el mismo tipo de información: sale.order, purchase.order, stock.picking... Esto es bien visible en los módulos que extienden este módulo:

Sin embargo, el caso del invoice Odoo en el módulo l10n_br_account es diferente aún. Pues ya se tiene la tabla independiente del documento fiscal cuya gran mayoría de las decenas e incluso cientos de campos fiscales (en el caso de muchos tipos de documentos fiscales) no son redundantes con los del invoice Odoo. Si inyectáramos esos mixins dentro del invoice, ahí sí esos cientos de campos serían duplicados entre el invoice y el documento fiscal. Por eso, el sistema que se adoptó en el módulo l10n_br_account es que un invoice Odoo pasa a tener un _inherits = "l10n_br_fiscal.document" de forma que se pilota el documento fiscal a través del invoice, ofreciendo el mismo tipo de integración como antes. El mismo tipo de mecanismo ocurre con la línea del documento fiscal.

Siendo así, ya por los _inherits, el invoice Odoo y sus líneas ya van a traer todos los campos fiscales como si fueran de sus respectivas tablas sin duplicarlos en la base de datos. Si además inyectáramos los mixins 10n_br_fiscal.document.mixin y 10n_br_fiscal.document.line.mixin en el invoice e invoice.line, esos campos fiscales aparecerían también en las tablas account_move y account_move_line de forma redundante con los campos traídos por los _inherits. Para no tener ese problema, los métodos fiscales comunes (sin los campos) fueron además extraídos en los mixins: 10n_br_fiscal.document.mixin.methods y 10n_br_fiscal.document.line.mixin.methods que son inyectados en los objetos account_move y account_move_line respectivamente dentro del módulo l10n_br_account.

Impuestos brasileños

El módulo l10n_br_fiscal lidia con los principales impuestos brasileños como:

• ICMS del Simples Nacional
• ICMS del Régimen normal
• IPI
• PIS
• COFINS
• ISSQN
• IRPJ
• II
• CSLL
• INSS

El módulo l10n_br_fiscal también lidia con:

• ST
• retenciones

Es notorio que el cálculo de los impuestos en Brasil es muy especial y muy laborioso. Generalmente es el motivo por el cual los ERPs internacionales no tienen gran cuota de mercado brasileño.

Hasta la versión 10.0, intentamos usar y extender el objeto Odoo account.tax. Akretion incluso creó el proyecto OCA/account-fiscal-rule para determinar las alícuotas de cada impuesto de acuerdo con los parámetros de la operación fiscal. Sin embargo, terminábamos usando casi nada del account.fiscal.position nativo en la parte fiscal y, por el contrario, eso nos obligaba a tener un registro account.tax para cada alícuota y nos obligaba a mantener cientos de tasas y decenas de miles de reglas para seleccionar la "posición fiscal" Odoo que aplicaría las tasas correctas. Y todavía tenías que gestionar esas decenas de miles de reglas para una determinada empresa del régimen normal. Conclusión: era inviable en los proyectos menores intentar encajar en la lógica de Odoo para calcular los impuestos brasileños.

Con esto creamos en este módulo los modelos de tasas que representan exactamente el funcionamiento de los impuestos brasileños. Además de los cálculos, esos modelos también nos sirven para cargar las tablas de los impuestos. Y más adelante, en el módulo l10n_br_account, enlazamos los objetos nativos account.tax a las alícuotas de los impuestos brasileños.

Claro que esos modelos de los impuestos atienden a las empresas del régimen normal, pero es bueno recordar que incluso las empresas del régimen simplificado necesitan esos modelos para realizar las operaciones con ST (Substituição Tributária)...

Operaciones fiscales

>

En Odoo nativo, el concepto más parecido a la operación fiscal es el account.fiscal.position. Y hasta la versión 10.0, era lo que usábamos. Sin embargo, la posición fiscal de Odoo no resuelve mucho nuestros problemas pues:

• en Brasil se tiene una operación fiscal por línea de documento fiscal
• la posición fiscal de Odoo desconoce la lógica de la parametrización fiscal brasileña
• ya que traemos el registro de los impuestos en el módulo l10n_br_fiscal fuera del módulo account (sin depender de él), no tenemos aún el objeto account.fiscal.position en este módulo.

Con todo, optamos por crear un objeto l10n_br_fiscal.operation que hace exactamente lo que necesitamos para Brasil. Más adelante, en el módulo l10n_br_account se realiza la integración entre la posición fiscal de Odoo y esa operación fiscal.