<h1 class="title">Módulo fiscal brasileiro</h1> <p><a class="reference external" 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" 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" href="https://github.com/OCA/l10n-brazil/tree/12.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" href="https://translation.odoo-community.org/projects/l10n-brazil-12-0/l10n-brazil-12-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" href="https://runbot.odoo-community.org/runbot/124/12.0"><img alt="Try me on Runbot" src="https://img.shields.io/badge/runbot-Try%20me-875A7B.png" /></a></p> <img alt="https://raw.githubusercontent.com/OCA/l10n-brazil/12.0/l10n_br_fiscal/static/img/fiscal_dashboard.png" src="https://raw.githubusercontent.com/OCA/l10n-brazil/12.0/l10n_br_fiscal/static/img/fiscal_dashboard.png" /> <a name="classificacoes-fiscais"></a> <h2>Classificações fiscais</h2> <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"> <li>tipo fiscal</li> <li>NCM (com ligações com os impostos)</li> <li>genêro fiscal</li> <li>CEST</li> <li>NBM</li> <li>NBS</li> <li>tipo de serviço</li> <li>unidades fiscais</li> </ul> </dd> <dt>Parceiros:</dt> <dd><ul class="first last simple"> <li>CNAE</li> <li>perfil fiscal</li> </ul> </dd> </dl> <a name="conceito-de-documento-fiscal"></a> <h2>Conceito de documento fiscal</h2> <p>O Odoo nativo não tem o conceito de documento fiscal. O conceito mais parecido seria o <code>account.invoice</code> 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 <code>l10n_br_fiscal.document</code> 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 <code>l10n_br_fiscal</code>, 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 <code>l10n_br_fiscal</code> é 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><code>nfelib</code>: 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><code>l10n_br_nfe_spec</code>: 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><code>l10n_br_nfe</code>: 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 <code>erpbrasil.doc</code> (baseada em Python Zeep). Importante: no caso da <code>NFS-e</code>, 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 <code>l10n_br_fiscal.document</code> e das linhas dele <code>l10n_br_fiscal.document.line</code> é na verdade feito dentro de mixins <code>10n_br_fiscal.document.mixin</code> e <code>10n_br_fiscal.document.line.mixin</code> 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: <code>sale.order</code>, <code>purchase.order</code>, <code>stock.picking</code>... Isso é bem visível nos módulos que estendem esse módulo:</p> <pre> <code lang="text">|-- l10n_br_fiscal |-- l10n_br_sale |-- l10n_br_purchase |-- l10n_br_account |-- ...</code> </pre> <p>Porem o caso do invoice Odoo no modulo <code>l10n_br_account</code> é 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 <code>l10n_br_account</code> é que um invoice Odoo passa a ter um <code>_inherits = &quot;l10n_br_fiscal.document&quot;</code> 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 <code>10n_br_fiscal.document.mixin</code> e <code>10n_br_fiscal.document.line.mixin</code> no invoice e invoice.line, esses campos fiscais apareceriam também nas tabelas <code>account_invoice</code> e <code>account_invoice_line</code> 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: <code>10n_br_fiscal.document.mixin.methods</code> e <code>10n_br_fiscal.document.line.mixin.methods</code> que são injectados nos objetos <code>account_invoice</code> e <code>account_invoice_line</code> respectivamente dentro do modulo <code>l10n_br_account</code>.</p> <a name="impostos-brasileiros"></a> <h2>Impostos brasileiros</h2> <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> <li>IPI</li> <li>PIS</li> <li>COFINS</li> <li>ISSQN</li> <li>IRPJ</li> <li>II</li> <li>CSLL</li> <li>INSS</li> </ul> <p>O módulo l10n_br_fiscal também lida com:</p> <ul class="simple"> <li>ST</li> <li>retenções</li> </ul> <img alt="https://raw.githubusercontent.com/OCA/l10n-brazil/12.0/l10n_br_fiscal/static/img/fiscal_line.png" src="https://raw.githubusercontent.com/OCA/l10n-brazil/12.0/l10n_br_fiscal/static/img/fiscal_line.png" /> <img alt="https://raw.githubusercontent.com/OCA/l10n-brazil/12.0/l10n_br_fiscal/static/img/fiscal_total.png" src="https://raw.githubusercontent.com/OCA/l10n-brazil/12.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 <code>account.tax</code>. A Akretion até criou o projeto <code>OCA/account-fiscal-rule</code> 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 <code>account.fiscal.position</code> nativo na parte fiscal e pelo contrário, isso nos obrigava a ter um registro <code>account.tax</code> para cada aliquota e nos obrigava a manter centenas de taxas e dezenas de milhares de regras para selecionar a &quot;posição fiscal&quot; 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 <code>l10n_br_account</code>, ligamos os objetos nativos <code>account.tax</code> 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> <a name="operacoes-fiscais"></a> <h2>Operações fiscais</h2> <blockquote> <img alt="https://raw.githubusercontent.com/OCA/l10n-brazil/12.0/l10n_br_fiscal/static/img/fiscal_operation.png" src="https://raw.githubusercontent.com/OCA/l10n-brazil/12.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 ´´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:</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 <code>account.fiscal.position</code> neste módulo.</li> </ul> <p>Com tudo, optamos por criar um objeto <code>l10n_br_fiscal.operation</code> que faz exactamente o que precisamos para o Brasil. Mais adiante, no módulo <code>l10n_br_account</code> é 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="id1">Installation</a></li> <li><a class="reference internal" href="#configuration" id="id2">Configuration</a></li> <li><a class="reference internal" href="#usage" id="id3">Usage</a></li> <li><a class="reference internal" href="#known-issues-roadmap" id="id4">Known issues / Roadmap</a></li> <li><a class="reference internal" href="#bug-tracker" id="id5">Bug Tracker</a></li> <li><a class="reference internal" href="#credits" id="id6">Credits</a></li> </ul> </div> <a name="installation"></a> <h3><a class="toc-backref" href="#id1">Installation</a></h3> <p>To install this module, you need to:</p> <ul class="simple"> <li>do this ...</li> </ul> <a name="configuration"></a> <h3><a class="toc-backref" href="#id2">Configuration</a></h3> <p>To configure this module, you need to:</p> <ul class="simple"> <li>go to ...</li> </ul> <a name="usage"></a> <h3><a class="toc-backref" href="#id3">Usage</a></h3> <p>To use this module, you need to:</p> <ul class="simple"> <li>go to ...</li> </ul> <a name="known-issues-roadmap"></a> <h3><a class="toc-backref" href="#id4">Known issues / Roadmap</a></h3> <ul class="simple"> <li>TODO!</li> </ul> <a name="bug-tracker"></a> <h3><a class="toc-backref" href="#id5">Bug Tracker</a></h3> <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 smashing it by providing a detailed and welcomed <a class="reference external" href="https://github.com/OCA/l10n-brazil/issues/new?body=module:%20l10n_br_fiscal%0Aversion:%2012.0%0A%0A**Steps%20to%20reproduce**%0A-%20...%0A%0A**Current%20behavior**%0A%0A**Expected%20behavior**">feedback</a>.</p> <p>Do not contact contributors directly about support or help with technical issues.</p> <a name="credits"></a> <h3><a class="toc-backref" href="#id6">Credits</a></h3> <a name="authors"></a> <h2>Authors</h2> <ul class="simple"> <li>Akretion</li> </ul> <a name="contributors"></a> <h2>Contributors</h2> <ul class="simple"> <li>Renato Lima &lt;<a class="reference external" href="mailto:renato.lima&#64;akretion.com.br">renato.lima&#64;akretion.com.br</a>&gt;</li> <li>Raphaël Valyi &lt;<a class="reference external" href="mailto:raphael.valyi&#64;akretion.com.br">raphael.valyi&#64;akretion.com.br</a>&gt;</li> <li>Magno Costa &lt;<a class="reference external" href="mailto:magno.costa&#64;akretion.com.br">magno.costa&#64;akretion.com.br</a>&gt;</li> <li>Luis Felipe Mileo &lt;<a class="reference external" href="mailto:mileo&#64;kmee.com.br">mileo&#64;kmee.com.br</a>&gt;</li> <li>Marcel Savegnago &lt;<a class="reference external" href="mailto:marcel.savegnago&#64;escodoo.com.br">marcel.savegnago&#64;escodoo.com.br</a>&gt;</li> <li>Luis Otavio Malta Conceição &lt;<a class="reference external" href="mailto:luis.malta&#64;kmee.com.br">luis.malta&#64;kmee.com.br</a>&gt;</li> </ul> <a name="maintainers"></a> <h2>Maintainers</h2> <p>This module is maintained by the OCA.</p> <a class="reference external image-reference" href="https://odoo-community.org"><img alt="Odoo Community Association" src="https://odoo-community.org/logo.png" /></a> <p>OCA, or the Odoo Community Association, is a nonprofit organization whose mission is to support the collaborative development of Odoo features and promote its widespread use.</p> <p>Current <a class="reference external" href="https://odoo-community.org/page/maintainer-role">maintainer</a>:</p> <p><a class="reference external" href="https://github.com/renatonlima"><img alt="renatonlima" src="https://github.com/renatonlima.png?size=40px" /></a></p> <p>This module is part of the <a class="reference external" href="https://github.com/OCA/l10n-brazil/tree/12.0/l10n_br_fiscal">OCA/l10n-brazil</a> project on GitHub.</p> <p>You are welcome to contribute. To learn how please visit <a class="reference external" href="https://odoo-community.org/page/Contribute">https://odoo-community.org/page/Contribute</a>.</p>