odoo-addon-l10n-br-fiscal 16.0.1.18.1__py3-none-any.whl → 16.0.1.18.2__py3-none-any.whl

odoo/addons/l10n_br_fiscal/README.rst

@@ -7,7 +7,7 @@ Módulo fiscal brasileiro
    !! This file is generated by oca-gen-addon-readme !!
    !! changes will be overwritten.                   !!
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
-   !! source digest: sha256:9fa01cd837e4c47121656b5ea00d0dd8a35417a08afadb987905da99d4ae3699
+   !! source digest: sha256:a248da3cdce943ad2d1d06331dca73ca572668dbf62b6786726192e4a000e1f2
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
 
 .. |badge1| image:: https://img.shields.io/badge/maturity-Production%2FStable-green.png
@@ -28,109 +28,213 @@ Módulo fiscal brasileiro
 
 |badge1| |badge2| |badge3| |badge4| |badge5|
 
-.. image:: https://raw.githubusercontent.com/OCA/l10n-brazil/16.0/l10n_br_fiscal/static/img/fiscal_dashboard.png
-
+|image|
 
 Classificações fiscais
-~~~~~~~~~~~~~~~~~~~~~~
+----------------------
 
-Primeramente, este módulo traz uma variedade de cadastros fiscais para produtos, parceiros ou empresas. Na hora de emitir documentos fiscais como NF-e, NFS-e etc... até empresas do regime simplificado ou MEI precisam de vários desses cadastros. E empresas do regime normal precisam deles para calcular os impostos ou emitir documentos fiscais.
+Primeramente, este módulo traz uma variedade de cadastros fiscais para
+produtos, parceiros ou empresas. Na hora de emitir documentos fiscais
+como NF-e, NFS-e etc... até empresas do regime simplificado ou MEI
+precisam de vários desses cadastros. E empresas do regime normal
+precisam deles para calcular os impostos ou emitir documentos fiscais.
 
 Produtos:
-  * tipo fiscal
-  * NCM (com ligações com os impostos)
-  * genêro fiscal
-  * CEST
-  * NBM
-  * NBS
-  * tipo de serviço
-  * unidades fiscais
+
+-  tipo fiscal
+-  NCM (com ligações com os impostos)
+-  genêro fiscal
+-  CEST
+-  NBM
+-  NBS
+-  tipo de serviço
+-  unidades fiscais
 
 Parceiros:
-  * CNAE
-  * perfil fiscal
 
+-  CNAE
+-  perfil fiscal
 
 Conceito de documento fiscal
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-O Odoo nativo não tem o conceito de documento fiscal. O conceito mais parecido seria o ``account.move`` e até a versão 10.0 a localização estendia o invoice para suportar as NF-e e NFS-e apenas. Naquela época não era razoável você cogitar fazer o SPED no Odoo, o próprio core do Odoo não tinha maturidade para isso então era válido a abordagem empírica de ir suportando mais casos de NFe dentro do invoice Odoo apenas.
-
-Porém, na v12, amadurecemos o framework XML/SOAP de forma que se torna razoável suportar vários documentos fiscais (NF-e, NFS-e, MDF-e, CT-e, EFD-Reinf, e-Social, GNRE, BP-e...) com a qualidade OCA dentro do Odoo. Também, apesar de complexo, o core do Odoo finalmente tem suporte suficiente para as operações de uma empresa que faria o SPED.
-
-Nisso se torna interessante ter o conceito de documento fiscal ``l10n_br_fiscal.document`` independente do invoice Odoo para suportar todos os documentos fiscais mesmo, de forma modular. Um outro motivo para ter o conceito de documento fiscal fora do módulo account é que quando você analisa o código deste módulo ``l10n_br_fiscal``, quase nada dele poderia ser feito pelo módulo account do Odoo. Então ter esse módulo l10n_br_fiscal que não depende do módulo account também é uma forma de modularizar a localização para facilitar a manutenção dela, especialmente quando se trata de migrar e que o módulo pode ter mudado bastante como foi o caso entre a v8.0 e a v9.0 ou a v12.0 e v13.0 por exemplo. Facilita também a governança do projeto possibilitando que pessoas sejam responsáveis por diferentes partes. O módulo l10n_br_fiscal foi principalmente extraído do módulo l10n_br_l10n_br_account_product das v7.0 as v.10.0.
-
-Esse módulo ``l10n_br_fiscal`` é agnóstico de qualquer tecnologia XML ou SOAP. Ele contém apenas o que há de comum entre os documentos fiscais mas esses últimos são implementados em outros módulos. Para um determinado documento fiscal como a Nf-e, você tem então por exemplo:
-
-* ``nfelib``: um pacote de data bindings puro Python (que não depende do Odoo). Em geral usamos um gerador de código para gerar esses bindings a partir dos esquemas XSD da fazenda.
-* ``l10n_br_nfe_spec``: um modulo de mixins Odoo geridos também a partir dos XSD. Esses mixins são apenas as estruturas de dados das especificações antes de ser injectados em objetos Odoo existantes (como res.partner ou l10n_br_fiscal.document) ou até tornados concretos caso não exite objetos na Odoo ou na OCA para eles já.
-* ``l10n_br_nfe``: um módulo Odoo que trata de injectar esses mappings fiscais nos objetos Odoo e que implementa a lógica como os wizards para a transmissão.
-
-A transmissão é realizada usando uma lib de transmissão como ``erpbrasil.doc`` (baseada em Python Zeep). Importante: no caso da ``NFS-e``, a ausência de padrão nacional hoje e a simplicidade do modelo (comparado com a NFe) faz que foi decidido de não usar um módulo de mixins fiscais Odoo geridos, o mapping é com a lib de binding é feito manualmente, família de NFS-e por família.
-
-Alem disso a maioria do codigo do ``l10n_br_fiscal.document`` e das linhas dele ``l10n_br_fiscal.document.line`` é na verdade feito dentro de mixins ``10n_br_fiscal.document.mixin`` e ``10n_br_fiscal.document.line.mixin`` respectivamente. Esses mixins podem assim ser injectados em outros objetos Odoo que precedem os documentos fiscais e podem armazenar então o mesmo tipo de informação: ``sale.order``, ``purchase.order``, ``stock.picking``... Isso é bem visível nos módulos que estendem esse módulo:
-
-.. code-block:: text
-
-    |-- l10n_br_fiscal
-        |-- l10n_br_sale
-        |-- l10n_br_purchase
-        |-- l10n_br_account
-        |-- ...
-
-
-Porem o caso do invoice Odoo no modulo ``l10n_br_account`` é diferente ainda. Pois já se tem a tabela independente do documento fiscal cuja grande maioria das dezenas e até centenas de campos fiscais (no caso de muitos tipos de documentos fiscais) não são redundante com os do invoice Odoo. Se a gente injetasse esses mixins dentro do invoice, aí sim essas centenas de campos seriam duplicados entre o invoice e o documento fiscal. Por isso, o sistema que foi adotado no modulo ``l10n_br_account`` é que um invoice Odoo passa a ter um ``_inherits = "l10n_br_fiscal.document"`` de forma que se pilota o documento fiscal através do invoice, oferecendo o mesmo tipo de integração como antes. O mesmo tipo de mecanismo acontece com a linha do documento fiscal.
-
-Sendo assim, já pelos _inherits, o invoice Odoo e as linhas dele já vão puxar todos campos fiscais como se eles fossem das suas respectivas tabelas sem duplicar eles no banco. Se alem disso a gente injetasse os mixins ``10n_br_fiscal.document.mixin`` e ``10n_br_fiscal.document.line.mixin`` no invoice e invoice.line, esses campos fiscais apareceriam também nas tabelas ``account_move`` e ``account_move_line`` de forma redundantes com os campos puxados pelos _inherits. Para não ter esse problema, os métodos fiscais comuns (sem os campos) foram ainda extraidos nos mixins: ``10n_br_fiscal.document.mixin.methods`` e ``10n_br_fiscal.document.line.mixin.methods`` que são injectados nos objetos ``account_move`` e ``account_move_line`` respectivamente dentro do modulo ``l10n_br_account``.
-
+----------------------------
+
+O Odoo nativo não tem o conceito de documento fiscal. O conceito mais
+parecido seria o ``account.move`` e até a versão 10.0 a localização
+estendia o invoice para suportar as NF-e e NFS-e apenas. Naquela época
+não era razoável você cogitar fazer o SPED no Odoo, o próprio core do
+Odoo não tinha maturidade para isso então era válido a abordagem
+empírica de ir suportando mais casos de NFe dentro do invoice Odoo
+apenas.
+
+Porém, na v12, amadurecemos o framework XML/SOAP de forma que se torna
+razoável suportar vários documentos fiscais (NF-e, NFS-e, MDF-e, CT-e,
+EFD-Reinf, e-Social, GNRE, BP-e...) com a qualidade OCA dentro do Odoo.
+Também, apesar de complexo, o core do Odoo finalmente tem suporte
+suficiente para as operações de uma empresa que faria o SPED.
+
+Nisso se torna interessante ter o conceito de documento fiscal
+``l10n_br_fiscal.document`` independente do invoice Odoo para suportar
+todos os documentos fiscais mesmo, de forma modular. Um outro motivo
+para ter o conceito de documento fiscal fora do módulo account é que
+quando você analisa o código deste módulo ``l10n_br_fiscal``, quase nada
+dele poderia ser feito pelo módulo account do Odoo. Então ter esse
+módulo l10n_br_fiscal que não depende do módulo account também é uma
+forma de modularizar a localização para facilitar a manutenção dela,
+especialmente quando se trata de migrar e que o módulo pode ter mudado
+bastante como foi o caso entre a v8.0 e a v9.0 ou a v12.0 e v13.0 por
+exemplo. Facilita também a governança do projeto possibilitando que
+pessoas sejam responsáveis por diferentes partes. O módulo
+l10n_br_fiscal foi principalmente extraído do módulo
+l10n_br_l10n_br_account_product das v7.0 as v.10.0.
+
+Esse módulo ``l10n_br_fiscal`` é agnóstico de qualquer tecnologia XML ou
+SOAP. Ele contém apenas o que há de comum entre os documentos fiscais
+mas esses últimos são implementados em outros módulos. Para um
+determinado documento fiscal como a Nf-e, você tem então por exemplo:
+
+-  ``nfelib``: um pacote de data bindings puro Python (que não depende
+   do Odoo). Em geral usamos um gerador de código para gerar esses
+   bindings a partir dos esquemas XSD da fazenda.
+-  ``l10n_br_nfe_spec``: um modulo de mixins Odoo geridos também a
+   partir dos XSD. Esses mixins são apenas as estruturas de dados das
+   especificações antes de ser injectados em objetos Odoo existantes
+   (como res.partner ou l10n_br_fiscal.document) ou até tornados
+   concretos caso não exite objetos na Odoo ou na OCA para eles já.
+-  ``l10n_br_nfe``: um módulo Odoo que trata de injectar esses mappings
+   fiscais nos objetos Odoo e que implementa a lógica como os wizards
+   para a transmissão.
+
+A transmissão é realizada usando uma lib de transmissão como
+``erpbrasil.doc`` (baseada em Python Zeep). Importante: no caso da
+``NFS-e``, a ausência de padrão nacional hoje e a simplicidade do modelo
+(comparado com a NFe) faz que foi decidido de não usar um módulo de
+mixins fiscais Odoo geridos, o mapping é com a lib de binding é feito
+manualmente, família de NFS-e por família.
+
+Alem disso a maioria do codigo do ``l10n_br_fiscal.document`` e das
+linhas dele ``l10n_br_fiscal.document.line`` é na verdade feito dentro
+de mixins ``10n_br_fiscal.document.mixin`` e
+``10n_br_fiscal.document.line.mixin`` respectivamente. Esses mixins
+podem assim ser injectados em outros objetos Odoo que precedem os
+documentos fiscais e podem armazenar então o mesmo tipo de informação:
+``sale.order``, ``purchase.order``, ``stock.picking``... Isso é bem
+visível nos módulos que estendem esse módulo:
+
+.. code:: text
+
+   |-- l10n_br_fiscal
+       |-- l10n_br_sale
+       |-- l10n_br_purchase
+       |-- l10n_br_account
+       |-- ...
+
+Porem o caso do invoice Odoo no modulo ``l10n_br_account`` é diferente
+ainda. Pois já se tem a tabela independente do documento fiscal cuja
+grande maioria das dezenas e até centenas de campos fiscais (no caso de
+muitos tipos de documentos fiscais) não são redundante com os do invoice
+Odoo. Se a gente injetasse esses mixins dentro do invoice, aí sim essas
+centenas de campos seriam duplicados entre o invoice e o documento
+fiscal. Por isso, o sistema que foi adotado no modulo
+``l10n_br_account`` é que um invoice Odoo passa a ter um
+``_inherits = "l10n_br_fiscal.document"`` de forma que se pilota o
+documento fiscal através do invoice, oferecendo o mesmo tipo de
+integração como antes. O mesmo tipo de mecanismo acontece com a linha do
+documento fiscal.
+
+Sendo assim, já pelos \_inherits, o invoice Odoo e as linhas dele já vão
+puxar todos campos fiscais como se eles fossem das suas respectivas
+tabelas sem duplicar eles no banco. Se alem disso a gente injetasse os
+mixins ``10n_br_fiscal.document.mixin`` e
+``10n_br_fiscal.document.line.mixin`` no invoice e invoice.line, esses
+campos fiscais apareceriam também nas tabelas ``account_move`` e
+``account_move_line`` de forma redundantes com os campos puxados pelos
+\_inherits. Para não ter esse problema, os métodos fiscais comuns (sem
+os campos) foram ainda extraidos nos mixins:
+``10n_br_fiscal.document.mixin.methods`` e
+``10n_br_fiscal.document.line.mixin.methods`` que são injectados nos
+objetos ``account_move`` e ``account_move_line`` respectivamente dentro
+do modulo ``l10n_br_account``.
 
 Impostos brasileiros
-~~~~~~~~~~~~~~~~~~~~
-
-O módulo l10n_br_fiscal lida com os principais impostos brasileiros como:
-
-* ICMS do Simples Nacional
-* ICMS do Regime normal
-* IPI
-* PIS
-* COFINS
-* ISSQN
-* IRPJ
-* II
-* CSLL
-* INSS
+--------------------
+
+O módulo l10n_br_fiscal lida com os principais impostos brasileiros
+como:
+
+-  ICMS do Simples Nacional
+-  ICMS do Regime normal
+-  IPI
+-  PIS
+-  COFINS
+-  ISSQN
+-  IRPJ
+-  II
+-  CSLL
+-  INSS
 
 O módulo l10n_br_fiscal também lida com:
 
-* ST
-* retenções
-
-
-.. image:: https://raw.githubusercontent.com/OCA/l10n-brazil/16.0/l10n_br_fiscal/static/img/fiscal_line.png
-
-.. image:: https://raw.githubusercontent.com/OCA/l10n-brazil/16.0/l10n_br_fiscal/static/img/fiscal_total.png
-
-É notório que o cálculo dos impostos no Brasil é muito especial e muito trabalhoso. Geralmente é o motivo pelo qual os ERPs internacionais não tem grande fatia de mercado brasileiro.
-
-Até a versão 10.0, tentamos usar e estender o objeto Odoo ``account.tax``. A Akretion até criou o projeto ``OCA/account-fiscal-rule`` para determinar as alíquotas de cada imposto de accordo com os parâmetros da operação fiscal. Porém, a gente acabava usando quase nada do ``account.fiscal.position`` nativo na parte fiscal e pelo contrário, isso nos obrigava a ter um registro ``account.tax`` para cada aliquota e nos obrigava a manter centenas de taxas e dezenas de milhares de regras para selecionar a "posição fiscal" Odoo que aplicaria as taxas corretas. E você ainda tinha que gerir essas dezenas de milhares de regras para uma determinada empresa do regime normal. Conclusão: era inviável nos projetos menores de tentar se encaixa na lógica do Odoo para calcular os impostos brasileiros.
-
-Nisso criamos neste módulo os modelos de taxas que representam exatamente o funcionamentos dos impostos brasileiros. Além dos cálculos, esses modelos também nos servem a carregar as tabelas dos impostos. E mais adiante, no módulo ``l10n_br_account``, ligamos os objetos nativos ``account.tax`` as alíquotas dos impostos brasileiros.
-
-Claro esses modelos dos impostos atendem as empresas do regime normal, mas é bom lembrar que até empresas do regime simplificado precisam desses modelos para realizar as operações com ST (Substituição Tributária)...
-
+-  ST
+-  retenções
+
+|image1|
+
+|image2|
+
+É notório que o cálculo dos impostos no Brasil é muito especial e muito
+trabalhoso. Geralmente é o motivo pelo qual os ERPs internacionais não
+tem grande fatia de mercado brasileiro.
+
+Até a versão 10.0, tentamos usar e estender o objeto Odoo
+``account.tax``. A Akretion até criou o projeto
+``OCA/account-fiscal-rule`` para determinar as alíquotas de cada imposto
+de accordo com os parâmetros da operação fiscal. Porém, a gente acabava
+usando quase nada do ``account.fiscal.position`` nativo na parte fiscal
+e pelo contrário, isso nos obrigava a ter um registro ``account.tax``
+para cada aliquota e nos obrigava a manter centenas de taxas e dezenas
+de milhares de regras para selecionar a "posição fiscal" Odoo que
+aplicaria as taxas corretas. E você ainda tinha que gerir essas dezenas
+de milhares de regras para uma determinada empresa do regime normal.
+Conclusão: era inviável nos projetos menores de tentar se encaixa na
+lógica do Odoo para calcular os impostos brasileiros.
+
+Nisso criamos neste módulo os modelos de taxas que representam
+exatamente o funcionamentos dos impostos brasileiros. Além dos cálculos,
+esses modelos também nos servem a carregar as tabelas dos impostos. E
+mais adiante, no módulo ``l10n_br_account``, ligamos os objetos nativos
+``account.tax`` as alíquotas dos impostos brasileiros.
+
+Claro esses modelos dos impostos atendem as empresas do regime normal,
+mas é bom lembrar que até empresas do regime simplificado precisam
+desses modelos para realizar as operações com ST (Substituição
+Tributária)...
 
 Operações fiscais
-~~~~~~~~~~~~~~~~~
+-----------------
+
+   |image3|
 
-  .. image:: https://raw.githubusercontent.com/OCA/l10n-brazil/16.0/l10n_br_fiscal/static/img/fiscal_operation.png
+No Odoo nativo, o conceito mais parecido com a operação fiscal e o
+``account.fiscal.position``. E ate a versão 10.0, era o que a gente
+usava. Porém, a posição fiscal do Odoo não resolve muito os nossos
+problemas pois:
 
-No Odoo nativo, o conceito mais parecido com a operação fiscal e o ``account.fiscal.position``. E ate a versão 10.0, era o que a gente usava. Porém, a posição fiscal do Odoo não resolve muito os nossos problemas pois:
+-  no Brasil se tem uma operação fiscal por linha de documento fiscal
+-  a posição fiscal do Odoo desconhece a lógica da parametrização fiscal
+   brasileira
+-  já que puxamos o cadastro dos impostos no módulo l10n_br_fiscal fora
+   do módulo account (sem depender dele), não temos ainda o objeto
+   ``account.fiscal.position`` neste módulo.
 
-* no Brasil se tem uma operação fiscal por linha de documento fiscal
-* a posição fiscal do Odoo desconhece a lógica da parametrização fiscal brasileira
-* já que puxamos o cadastro dos impostos no módulo l10n_br_fiscal fora do módulo account (sem depender dele), não temos ainda o objeto ``account.fiscal.position`` neste módulo.
+Com tudo, optamos por criar um objeto ``l10n_br_fiscal.operation`` que
+faz exactamente o que precisamos para o Brasil. Mais adiante, no módulo
+``l10n_br_account`` é realizado a integração entre a posição fiscal do
+Odoo e essa operação fiscal.
 
-Com tudo, optamos por criar um objeto ``l10n_br_fiscal.operation`` que faz exactamente o que precisamos para o Brasil. Mais adiante, no módulo ``l10n_br_account`` é realizado a integração entre a posição fiscal do Odoo e essa operação fiscal.
+.. |image| image:: https://raw.githubusercontent.com/OCA/l10n-brazil/16.0/l10n_br_fiscal/static/img/fiscal_dashboard.png
+.. |image1| image:: https://raw.githubusercontent.com/OCA/l10n-brazil/16.0/l10n_br_fiscal/static/img/fiscal_line.png
+.. |image2| image:: https://raw.githubusercontent.com/OCA/l10n-brazil/16.0/l10n_br_fiscal/static/img/fiscal_total.png
+.. |image3| image:: https://raw.githubusercontent.com/OCA/l10n-brazil/16.0/l10n_br_fiscal/static/img/fiscal_operation.png
 
 **Table of contents**
 
@@ -140,24 +244,40 @@ Com tudo, optamos por criar um objeto ``l10n_br_fiscal.operation`` que faz exact
 Installation
 ============
 
-Para instalar o módulo l10n_br_fiscal, você precisa de instalar primeiro os pacotes Python
+Para instalar o módulo l10n_br_fiscal, você precisa de instalar primeiro
+os pacotes Python
 
-* erpbrasil.base
-* erpbrasil.assinatura
+-  erpbrasil.base
+-  erpbrasil.assinatura
 
 Configuration
 =============
 
 Para uma boa configuração fiscal, você tem que revisar bem:
 
-* em Configurações: as operaçoes fiscais que você vai usar, as linhas de operação fiscal e as definições das taxas nessas linhas.
-* a configuração fiscal da sua empresa (aba fiscal)
-* a configuração fiscal dos clientes e fornecedores (aba fiscal) e dos produtos (aba fiscal).
+-  em Configurações: as operaçoes fiscais que você vai usar, as linhas
+   de operação fiscal e as definições das taxas nessas linhas.
+-  a configuração fiscal da sua empresa (aba fiscal)
+-  a configuração fiscal dos clientes e fornecedores (aba fiscal) e dos
+   produtos (aba fiscal).
 
 Usage
 =====
 
-Você pode criar documentos fiscais direitamente pelo menu fiscal, mas a princípio você vai pilotar a criação de documentos fiscais a partir dos invoices Odoo, usando módulos adicionais como l10n_br_account, l10n_br_sale, l10n_br_purchase...
+Você pode criar documentos fiscais direitamente pelo menu fiscal, mas a
+princípio você vai pilotar a criação de documentos fiscais a partir dos
+invoices Odoo, usando módulos adicionais como l10n_br_account,
+l10n_br_sale, l10n_br_purchase...
+
+Known issues / Roadmap
+======================
+
+
+
+Changelog
+=========
+
+
 
 Bug Tracker
 ===========
@@ -173,35 +293,35 @@ Credits
 =======
 
 Authors
-~~~~~~~
+-------
 
 * Akretion
 
 Contributors
-~~~~~~~~~~~~
+------------
 
-* `Akretion <https://www.akretion.com/pt-BR>`_:
+-  `Akretion <https://www.akretion.com/pt-BR>`__:
 
-  * Renato Lima <renato.lima@akretion.com.br>
-  * Raphaël Valyi <raphael.valyi@akretion.com.br>
-  * Magno Costa <magno.costa@akretion.com.br>
+   -  Renato Lima <renato.lima@akretion.com.br>
+   -  Raphaël Valyi <raphael.valyi@akretion.com.br>
+   -  Magno Costa <magno.costa@akretion.com.br>
 
-* `KMEE <https://www.kmee.com.br>`_:
+-  `KMEE <https://www.kmee.com.br>`__:
 
-  * Luis Felipe Mileo <mileo@kmee.com.br>
-  * Luis Otavio Malta Conceição <luis.malta@kmee.com.br>
+   -  Luis Felipe Mileo <mileo@kmee.com.br>
+   -  Luis Otavio Malta Conceição <luis.malta@kmee.com.br>
 
-* `Escodoo <https://www.escodoo.com.br>`_:
+-  `Escodoo <https://www.escodoo.com.br>`__:
 
-  * Marcel Savegnago <marcel.savegnago@escodoo.com.br>
+   -  Marcel Savegnago <marcel.savegnago@escodoo.com.br>
 
-* `Engenere <https://engenere.one>`_:
+-  `Engenere <https://engenere.one>`__:
 
-  * Antônio S. Pereira Neto <neto@engenere.one>
-  * Felipe Motter Pereira <felipe@engenere.one>
+   -  Antônio S. Pereira Neto <neto@engenere.one>
+   -  Felipe Motter Pereira <felipe@engenere.one>
 
 Maintainers
-~~~~~~~~~~~
+-----------
 
 This module is maintained by the OCA.
 

odoo/addons/l10n_br_fiscal/__manifest__.py

@@ -10,7 +10,7 @@
     "maintainers": ["renatonlima"],
     "website": "https://github.com/OCA/l10n-brazil",
     "development_status": "Production/Stable",
-    "version": "16.0.1.18.1",
+    "version": "16.0.1.18.2",
     "depends": [
         "product",
         "l10n_br_base",