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/static/description/index.html

@@ -367,16 +367,19 @@ ul.auto-toc {
 !! This file is generated by oca-gen-addon-readme !!
 !! changes will be overwritten.                   !!
 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
-!! source digest: sha256:9fa01cd837e4c47121656b5ea00d0dd8a35417a08afadb987905da99d4ae3699
+!! source digest: sha256:a248da3cdce943ad2d1d06331dca73ca572668dbf62b6786726192e4a000e1f2
 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! -->
 <p><a class="reference external image-reference" href="https://odoo-community.org/page/development-status"><img alt="Production/Stable" src="https://img.shields.io/badge/maturity-Production%2FStable-green.png" /></a> <a class="reference external image-reference" href="http://www.gnu.org/licenses/agpl-3.0-standalone.html"><img alt="License: AGPL-3" src="https://img.shields.io/badge/licence-AGPL--3-blue.png" /></a> <a class="reference external image-reference" href="https://github.com/OCA/l10n-brazil/tree/16.0/l10n_br_fiscal"><img alt="OCA/l10n-brazil" src="https://img.shields.io/badge/github-OCA%2Fl10n--brazil-lightgray.png?logo=github" /></a> <a class="reference external image-reference" href="https://translation.odoo-community.org/projects/l10n-brazil-16-0/l10n-brazil-16-0-l10n_br_fiscal"><img alt="Translate me on Weblate" src="https://img.shields.io/badge/weblate-Translate%20me-F47D42.png" /></a> <a class="reference external image-reference" href="https://runboat.odoo-community.org/builds?repo=OCA/l10n-brazil&amp;target_branch=16.0"><img alt="Try me on Runboat" src="https://img.shields.io/badge/runboat-Try%20me-875A7B.png" /></a></p>
-<img alt="https://raw.githubusercontent.com/OCA/l10n-brazil/16.0/l10n_br_fiscal/static/img/fiscal_dashboard.png" src="https://raw.githubusercontent.com/OCA/l10n-brazil/16.0/l10n_br_fiscal/static/img/fiscal_dashboard.png" />
+<p><img alt="image" src="https://raw.githubusercontent.com/OCA/l10n-brazil/16.0/l10n_br_fiscal/static/img/fiscal_dashboard.png" /></p>
 <div class="section" id="classificacoes-fiscais">
 <h1>Classificações fiscais</h1>
-<p>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.</p>
-<dl class="docutils">
-<dt>Produtos:</dt>
-<dd><ul class="first last simple">
+<p>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.</p>
+<p>Produtos:</p>
+<ul class="simple">
 <li>tipo fiscal</li>
 <li>NCM (com ligações com os impostos)</li>
 <li>genêro fiscal</li>
@@ -386,28 +389,71 @@ ul.auto-toc {
 <li>tipo de serviço</li>
 <li>unidades fiscais</li>
 </ul>
-</dd>
-<dt>Parceiros:</dt>
-<dd><ul class="first last simple">
+<p>Parceiros:</p>
+<ul class="simple">
 <li>CNAE</li>
 <li>perfil fiscal</li>
 </ul>
-</dd>
-</dl>
 </div>
 <div class="section" id="conceito-de-documento-fiscal">
 <h1>Conceito de documento fiscal</h1>
-<p>O Odoo nativo não tem o conceito de documento fiscal. O conceito mais parecido seria o <tt class="docutils literal">account.move</tt> 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.</p>
-<p>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.</p>
-<p>Nisso se torna interessante ter o conceito de documento fiscal <tt class="docutils literal">l10n_br_fiscal.document</tt> 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 <tt class="docutils literal">l10n_br_fiscal</tt>, 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.</p>
-<p>Esse módulo <tt class="docutils literal">l10n_br_fiscal</tt> é 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:</p>
+<p>O Odoo nativo não tem o conceito de documento fiscal. O conceito mais
+parecido seria o <tt class="docutils literal">account.move</tt> 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.</p>
+<p>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.</p>
+<p>Nisso se torna interessante ter o conceito de documento fiscal
+<tt class="docutils literal">l10n_br_fiscal.document</tt> 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 <tt class="docutils literal">l10n_br_fiscal</tt>, 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.</p>
+<p>Esse módulo <tt class="docutils literal">l10n_br_fiscal</tt> é 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:</p>
 <ul class="simple">
-<li><tt class="docutils literal">nfelib</tt>: 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.</li>
-<li><tt class="docutils literal">l10n_br_nfe_spec</tt>: 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á.</li>
-<li><tt class="docutils literal">l10n_br_nfe</tt>: 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.</li>
+<li><tt class="docutils literal">nfelib</tt>: 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.</li>
+<li><tt class="docutils literal">l10n_br_nfe_spec</tt>: 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á.</li>
+<li><tt class="docutils literal">l10n_br_nfe</tt>: 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.</li>
 </ul>
-<p>A transmissão é realizada usando uma lib de transmissão como <tt class="docutils literal">erpbrasil.doc</tt> (baseada em Python Zeep). Importante: no caso da <tt class="docutils literal"><span class="pre">NFS-e</span></tt>, 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.</p>
-<p>Alem disso a maioria do codigo do <tt class="docutils literal">l10n_br_fiscal.document</tt> e das linhas dele <tt class="docutils literal">l10n_br_fiscal.document.line</tt> é na verdade feito dentro de mixins <tt class="docutils literal">10n_br_fiscal.document.mixin</tt> e <tt class="docutils literal">10n_br_fiscal.document.line.mixin</tt> 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: <tt class="docutils literal">sale.order</tt>, <tt class="docutils literal">purchase.order</tt>, <tt class="docutils literal">stock.picking</tt>… Isso é bem visível nos módulos que estendem esse módulo:</p>
+<p>A transmissão é realizada usando uma lib de transmissão como
+<tt class="docutils literal">erpbrasil.doc</tt> (baseada em Python Zeep). Importante: no caso da
+<tt class="docutils literal"><span class="pre">NFS-e</span></tt>, 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.</p>
+<p>Alem disso a maioria do codigo do <tt class="docutils literal">l10n_br_fiscal.document</tt> e das
+linhas dele <tt class="docutils literal">l10n_br_fiscal.document.line</tt> é na verdade feito dentro
+de mixins <tt class="docutils literal">10n_br_fiscal.document.mixin</tt> e
+<tt class="docutils literal">10n_br_fiscal.document.line.mixin</tt> 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:
+<tt class="docutils literal">sale.order</tt>, <tt class="docutils literal">purchase.order</tt>, <tt class="docutils literal">stock.picking</tt>… Isso é bem
+visível nos módulos que estendem esse módulo:</p>
 <pre class="code text literal-block">
 |-- l10n_br_fiscal
     |-- l10n_br_sale
@@ -415,12 +461,36 @@ ul.auto-toc {
     |-- l10n_br_account
     |-- ...
 </pre>
-<p>Porem o caso do invoice Odoo no modulo <tt class="docutils literal">l10n_br_account</tt> é 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 <tt class="docutils literal">l10n_br_account</tt> é que um invoice Odoo passa a ter um <tt class="docutils literal">_inherits = &quot;l10n_br_fiscal.document&quot;</tt> 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.</p>
-<p>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 <tt class="docutils literal">10n_br_fiscal.document.mixin</tt> e <tt class="docutils literal">10n_br_fiscal.document.line.mixin</tt> no invoice e invoice.line, esses campos fiscais apareceriam também nas tabelas <tt class="docutils literal">account_move</tt> e <tt class="docutils literal">account_move_line</tt> 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: <tt class="docutils literal">10n_br_fiscal.document.mixin.methods</tt> e <tt class="docutils literal">10n_br_fiscal.document.line.mixin.methods</tt> que são injectados nos objetos <tt class="docutils literal">account_move</tt> e <tt class="docutils literal">account_move_line</tt> respectivamente dentro do modulo <tt class="docutils literal">l10n_br_account</tt>.</p>
+<p>Porem o caso do invoice Odoo no modulo <tt class="docutils literal">l10n_br_account</tt> é 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
+<tt class="docutils literal">l10n_br_account</tt> é que um invoice Odoo passa a ter um
+<tt class="docutils literal">_inherits = &quot;l10n_br_fiscal.document&quot;</tt> 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.</p>
+<p>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 <tt class="docutils literal">10n_br_fiscal.document.mixin</tt> e
+<tt class="docutils literal">10n_br_fiscal.document.line.mixin</tt> no invoice e invoice.line, esses
+campos fiscais apareceriam também nas tabelas <tt class="docutils literal">account_move</tt> e
+<tt class="docutils literal">account_move_line</tt> 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:
+<tt class="docutils literal">10n_br_fiscal.document.mixin.methods</tt> e
+<tt class="docutils literal">10n_br_fiscal.document.line.mixin.methods</tt> que são injectados nos
+objetos <tt class="docutils literal">account_move</tt> e <tt class="docutils literal">account_move_line</tt> respectivamente dentro
+do modulo <tt class="docutils literal">l10n_br_account</tt>.</p>
 </div>
 <div class="section" id="impostos-brasileiros">
 <h1>Impostos brasileiros</h1>
-<p>O módulo l10n_br_fiscal lida com os principais impostos brasileiros como:</p>
+<p>O módulo l10n_br_fiscal lida com os principais impostos brasileiros
+como:</p>
 <ul class="simple">
 <li>ICMS do Simples Nacional</li>
 <li>ICMS do Regime normal</li>
@@ -438,38 +508,69 @@ ul.auto-toc {
 <li>ST</li>
 <li>retenções</li>
 </ul>
-<img alt="https://raw.githubusercontent.com/OCA/l10n-brazil/16.0/l10n_br_fiscal/static/img/fiscal_line.png" src="https://raw.githubusercontent.com/OCA/l10n-brazil/16.0/l10n_br_fiscal/static/img/fiscal_line.png" />
-<img alt="https://raw.githubusercontent.com/OCA/l10n-brazil/16.0/l10n_br_fiscal/static/img/fiscal_total.png" src="https://raw.githubusercontent.com/OCA/l10n-brazil/16.0/l10n_br_fiscal/static/img/fiscal_total.png" />
-<p>É 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.</p>
-<p>Até a versão 10.0, tentamos usar e estender o objeto Odoo <tt class="docutils literal">account.tax</tt>. A Akretion até criou o projeto <tt class="docutils literal"><span class="pre">OCA/account-fiscal-rule</span></tt> 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 <tt class="docutils literal">account.fiscal.position</tt> nativo na parte fiscal e pelo contrário, isso nos obrigava a ter um registro <tt class="docutils literal">account.tax</tt> 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.</p>
-<p>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 <tt class="docutils literal">l10n_br_account</tt>, ligamos os objetos nativos <tt class="docutils literal">account.tax</tt> as alíquotas dos impostos brasileiros.</p>
-<p>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)…</p>
+<p><img alt="image1" src="https://raw.githubusercontent.com/OCA/l10n-brazil/16.0/l10n_br_fiscal/static/img/fiscal_line.png" /></p>
+<p><img alt="image2" src="https://raw.githubusercontent.com/OCA/l10n-brazil/16.0/l10n_br_fiscal/static/img/fiscal_total.png" /></p>
+<p>É 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.</p>
+<p>Até a versão 10.0, tentamos usar e estender o objeto Odoo
+<tt class="docutils literal">account.tax</tt>. A Akretion até criou o projeto
+<tt class="docutils literal"><span class="pre">OCA/account-fiscal-rule</span></tt> 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 <tt class="docutils literal">account.fiscal.position</tt> nativo na parte fiscal
+e pelo contrário, isso nos obrigava a ter um registro <tt class="docutils literal">account.tax</tt>
+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.</p>
+<p>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 <tt class="docutils literal">l10n_br_account</tt>, ligamos os objetos nativos
+<tt class="docutils literal">account.tax</tt> as alíquotas dos impostos brasileiros.</p>
+<p>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)…</p>
 </div>
 <div class="section" id="operacoes-fiscais">
 <h1>Operações fiscais</h1>
 <blockquote>
-<img alt="https://raw.githubusercontent.com/OCA/l10n-brazil/16.0/l10n_br_fiscal/static/img/fiscal_operation.png" src="https://raw.githubusercontent.com/OCA/l10n-brazil/16.0/l10n_br_fiscal/static/img/fiscal_operation.png" />
-</blockquote>
-<p>No Odoo nativo, o conceito mais parecido com a operação fiscal e o <tt class="docutils literal">account.fiscal.position</tt>. 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:</p>
+<img alt="image3" src="https://raw.githubusercontent.com/OCA/l10n-brazil/16.0/l10n_br_fiscal/static/img/fiscal_operation.png" /></blockquote>
+<p>No Odoo nativo, o conceito mais parecido com a operação fiscal e o
+<tt class="docutils literal">account.fiscal.position</tt>. 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:</p>
 <ul class="simple">
 <li>no Brasil se tem uma operação fiscal por linha de documento fiscal</li>
-<li>a posição fiscal do Odoo desconhece a lógica da parametrização fiscal brasileira</li>
-<li>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 <tt class="docutils literal">account.fiscal.position</tt> neste módulo.</li>
+<li>a posição fiscal do Odoo desconhece a lógica da parametrização fiscal
+brasileira</li>
+<li>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
+<tt class="docutils literal">account.fiscal.position</tt> neste módulo.</li>
 </ul>
-<p>Com tudo, optamos por criar um objeto <tt class="docutils literal">l10n_br_fiscal.operation</tt> que faz exactamente o que precisamos para o Brasil. Mais adiante, no módulo <tt class="docutils literal">l10n_br_account</tt> é realizado a integração entre a posição fiscal do Odoo e essa operação fiscal.</p>
+<p>Com tudo, optamos por criar um objeto <tt class="docutils literal">l10n_br_fiscal.operation</tt> que
+faz exactamente o que precisamos para o Brasil. Mais adiante, no módulo
+<tt class="docutils literal">l10n_br_account</tt> é realizado a integração entre a posição fiscal do
+Odoo e essa operação fiscal.</p>
 <p><strong>Table of contents</strong></p>
 <div class="contents local topic" id="contents">
 <ul class="simple">
 <li><a class="reference internal" href="#installation" id="toc-entry-1">Installation</a></li>
 <li><a class="reference internal" href="#configuration" id="toc-entry-2">Configuration</a></li>
 <li><a class="reference internal" href="#usage" id="toc-entry-3">Usage</a></li>
-<li><a class="reference internal" href="#bug-tracker" id="toc-entry-4">Bug Tracker</a></li>
-<li><a class="reference internal" href="#credits" id="toc-entry-5">Credits</a></li>
+<li><a class="reference internal" href="#known-issues-roadmap" id="toc-entry-4">Known issues / Roadmap</a></li>
+<li><a class="reference internal" href="#changelog" id="toc-entry-5">Changelog</a></li>
+<li><a class="reference internal" href="#bug-tracker" id="toc-entry-6">Bug Tracker</a></li>
+<li><a class="reference internal" href="#credits" id="toc-entry-7">Credits</a></li>
 </ul>
 </div>
 <div class="section" id="installation">
 <h2><a class="toc-backref" href="#toc-entry-1">Installation</a></h2>
-<p>Para instalar o módulo l10n_br_fiscal, você precisa de instalar primeiro os pacotes Python</p>
+<p>Para instalar o módulo l10n_br_fiscal, você precisa de instalar primeiro
+os pacotes Python</p>
 <ul class="simple">
 <li>erpbrasil.base</li>
 <li>erpbrasil.assinatura</li>
@@ -479,17 +580,28 @@ ul.auto-toc {
 <h2><a class="toc-backref" href="#toc-entry-2">Configuration</a></h2>
 <p>Para uma boa configuração fiscal, você tem que revisar bem:</p>
 <ul class="simple">
-<li>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.</li>
+<li>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.</li>
 <li>a configuração fiscal da sua empresa (aba fiscal)</li>
-<li>a configuração fiscal dos clientes e fornecedores (aba fiscal) e dos produtos (aba fiscal).</li>
+<li>a configuração fiscal dos clientes e fornecedores (aba fiscal) e dos
+produtos (aba fiscal).</li>
 </ul>
 </div>
 <div class="section" id="usage">
 <h2><a class="toc-backref" href="#toc-entry-3">Usage</a></h2>
-<p>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…</p>
+<p>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…</p>
+</div>
+<div class="section" id="known-issues-roadmap">
+<h2><a class="toc-backref" href="#toc-entry-4">Known issues / Roadmap</a></h2>
+</div>
+<div class="section" id="changelog">
+<h2><a class="toc-backref" href="#toc-entry-5">Changelog</a></h2>
 </div>
 <div class="section" id="bug-tracker">
-<h2><a class="toc-backref" href="#toc-entry-4">Bug Tracker</a></h2>
+<h2><a class="toc-backref" href="#toc-entry-6">Bug Tracker</a></h2>
 <p>Bugs are tracked on <a class="reference external" href="https://github.com/OCA/l10n-brazil/issues">GitHub Issues</a>.
 In case of trouble, please check there if your issue has already been reported.
 If you spotted it first, help us to smash it by providing a detailed and welcomed
@@ -497,7 +609,7 @@ If you spotted it first, help us to smash it by providing a detailed and welcome
 <p>Do not contact contributors directly about support or help with technical issues.</p>
 </div>
 <div class="section" id="credits">
-<h2><a class="toc-backref" href="#toc-entry-5">Credits</a></h2>
+<h2><a class="toc-backref" href="#toc-entry-7">Credits</a></h2>
 </div>
 </div>
 <div class="section" id="authors">

odoo/addons/l10n_br_fiscal/tests/test_fiscal_document_generic.py

@@ -1076,7 +1076,7 @@ class TestFiscalDocumentGeneric(TransactionCase):
         additional_data = self.nfe_not_taxpayer.fiscal_line_ids[0].additional_data
         self.assertEqual(
             additional_data,
-            "manual comment test - Valor Aprox. dos Tributos: R$ 0,00"
+            "manual comment test - Valor Aprox. dos Tributos: R$ 0,00",
             # TODO FIXME changed 0.00 to 0,00 to get tests pass on v13, but not
             # correct
         )

odoo/addons/l10n_br_fiscal/tests/test_ibpt.py

@@ -25,8 +25,7 @@ def _not_every_day_test(method, self, modulo=7, remaining=0):
         return method(self)
     else:
         return lambda: _logger.info(
-            "Skipping test today because datetime.now().day %% %s != %s"
-            % (modulo, remaining)
+            f"Skipping test today because datetime.now().day % {modulo} != {remaining}"
         )
 
 

odoo/addons/l10n_br_fiscal/tools.py

@@ -72,13 +72,13 @@ def build_edoc_path(
     try:
         os.makedirs(caminho, exist_ok=True)
     except Exception as e:
-        _logger.error("Falha de permissão ao acessar diretorio do e-doc {}".format(e))
+        _logger.error(f"Falha de permissão ao acessar diretorio do e-doc {e}")
     return caminho
 
 
 def remove_non_ascii_characters(value):
     result = ""
-    if value and type(value) is str:
+    if value and isinstance(value, str):
         result = (
             normalize("NFKD", value)
             .encode("ASCII", "ignore")