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

odoo/addons/l10n_br_fiscal/models/document_fiscal_mixin_methods.py

@@ -21,7 +21,7 @@ class FiscalDocumentMixinMethods(models.AbstractModel):
         vals.pop("id", None)
 
         if default:  # in case you want to use new rather than write later
-            return {"default_%s" % (k,): vals[k] for k in vals.keys()}
+            return {f"default_{k}": vals[k] for k in vals.keys()}
         return vals
 
     def _get_amount_lines(self):
@@ -121,11 +121,12 @@ class FiscalDocumentMixinMethods(models.AbstractModel):
                         line.freight_value = amount_freight_value * (
                             line.freight_value / amount_freight_old
                         )
-                    record._get_product_amount_lines()[
-                        -1
-                    ].freight_value = amount_freight_value - sum(
-                        line.freight_value
-                        for line in record._get_product_amount_lines()[:-1]
+                    record._get_product_amount_lines()[-1].freight_value = (
+                        amount_freight_value
+                        - sum(
+                            line.freight_value
+                            for line in record._get_product_amount_lines()[:-1]
+                        )
                     )
                 else:
                     amount_total = sum(
@@ -136,11 +137,12 @@ class FiscalDocumentMixinMethods(models.AbstractModel):
                             line.freight_value = amount_freight_value * (
                                 line.price_gross / amount_total
                             )
-                    record._get_product_amount_lines()[
-                        -1
-                    ].freight_value = amount_freight_value - sum(
-                        line.freight_value
-                        for line in record._get_product_amount_lines()[:-1]
+                    record._get_product_amount_lines()[-1].freight_value = (
+                        amount_freight_value
+                        - sum(
+                            line.freight_value
+                            for line in record._get_product_amount_lines()[:-1]
+                        )
                     )
                 for line in record._get_product_amount_lines():
                     line._onchange_fiscal_taxes()
@@ -169,11 +171,12 @@ class FiscalDocumentMixinMethods(models.AbstractModel):
                         line.insurance_value = amount_insurance_value * (
                             line.insurance_value / amount_insurance_old
                         )
-                    record._get_product_amount_lines()[
-                        -1
-                    ].insurance_value = amount_insurance_value - sum(
-                        line.insurance_value
-                        for line in record._get_product_amount_lines()[:-1]
+                    record._get_product_amount_lines()[-1].insurance_value = (
+                        amount_insurance_value
+                        - sum(
+                            line.insurance_value
+                            for line in record._get_product_amount_lines()[:-1]
+                        )
                     )
                 else:
                     amount_total = sum(
@@ -184,11 +187,12 @@ class FiscalDocumentMixinMethods(models.AbstractModel):
                             line.insurance_value = amount_insurance_value * (
                                 line.price_gross / amount_total
                             )
-                    record._get_product_amount_lines()[
-                        -1
-                    ].insurance_value = amount_insurance_value - sum(
-                        line.insurance_value
-                        for line in record._get_product_amount_lines()[:-1]
+                    record._get_product_amount_lines()[-1].insurance_value = (
+                        amount_insurance_value
+                        - sum(
+                            line.insurance_value
+                            for line in record._get_product_amount_lines()[:-1]
+                        )
                     )
                 for line in record._get_product_amount_lines():
                     line._onchange_fiscal_taxes()
@@ -217,11 +221,12 @@ class FiscalDocumentMixinMethods(models.AbstractModel):
                         line.other_value = amount_other_value * (
                             line.other_value / amount_other_old
                         )
-                    record._get_product_amount_lines()[
-                        -1
-                    ].other_value = amount_other_value - sum(
-                        line.other_value
-                        for line in record._get_product_amount_lines()[:-1]
+                    record._get_product_amount_lines()[-1].other_value = (
+                        amount_other_value
+                        - sum(
+                            line.other_value
+                            for line in record._get_product_amount_lines()[:-1]
+                        )
                     )
                 else:
                     amount_total = sum(
@@ -232,11 +237,12 @@ class FiscalDocumentMixinMethods(models.AbstractModel):
                             line.other_value = amount_other_value * (
                                 line.price_gross / amount_total
                             )
-                    record._get_product_amount_lines()[
-                        -1
-                    ].other_value = amount_other_value - sum(
-                        line.other_value
-                        for line in record._get_product_amount_lines()[:-1]
+                    record._get_product_amount_lines()[-1].other_value = (
+                        amount_other_value
+                        - sum(
+                            line.other_value
+                            for line in record._get_product_amount_lines()[:-1]
+                        )
                     )
                 for line in record._get_product_amount_lines():
                     line._onchange_fiscal_taxes()

odoo/addons/l10n_br_fiscal/models/document_move_mixin.py

@@ -247,7 +247,9 @@ class DocumentMoveMixin(models.AbstractModel):
                         {
                             "source_document_id": self.id,
                             "subsequent_operation_id": subsequent_id.id,
-                            "fiscal_operation_id": subsequent_id.subsequent_operation_id.id,
+                            "fiscal_operation_id": (
+                                subsequent_id.subsequent_operation_id.id
+                            ),
                         },
                     )
                 )

odoo/addons/l10n_br_fiscal/models/document_serie.py

@@ -79,7 +79,7 @@ class DocumentSerie(models.Model):
         return super().create(vals_list)
 
     def name_get(self):
-        return [(r.id, "{}".format(r.name)) for r in self]
+        return [(r.id, f"{r.name}") for r in self]
 
     def _is_invalid_number(self, document_number):
         self.ensure_one()

odoo/addons/l10n_br_fiscal/models/product_template.py

@@ -26,8 +26,8 @@ class ProductTemplate(models.Model):
     # demo products of type 'product' (this type is added to product.template
     # in the stock module).
     # For some reason when running the tests, some inverse method fields then fail when
-    # reading 'product' value for the product type. It seems it is because l10n_br_fiscal
-    # doesn't depend on stock. But we don't want such a dependency.
+    # reading 'product' value for the product type. It seems it is because
+    # l10n_br_fiscal doesn't depend on stock. But we don't want such a dependency.
     # So a workaround to avoid the bug we add the 'product' value to the selection.
     type = fields.Selection(
         selection_add=[("product", "Storable Product")],

odoo/addons/l10n_br_fiscal/models/subsequent_document.py

@@ -3,7 +3,6 @@
 # License AGPL-3 or later (http://www.gnu.org/licenses/agpl)
 #
 
-from __future__ import division, print_function, unicode_literals
 
 from odoo import api, fields, models
 

odoo/addons/l10n_br_fiscal/models/subsequent_operation.py

@@ -2,8 +2,6 @@
 # License AGPL-3 - See http://www.gnu.org/licenses/agpl-3.0.html
 
 
-from __future__ import division, print_function, unicode_literals
-
 from odoo import fields, models
 
 from ..constants.fiscal import SITUACAO_EDOC

odoo/addons/l10n_br_fiscal/models/tax_definition.py

@@ -20,11 +20,7 @@ class TaxDefinition(models.Model):
     _description = "Tax Definition"
 
     def _get_complete_name(self):
-        return "{tax_group}-{tax}-{cst_code}".format(
-            tax_group=self.tax_group_id.name,
-            tax=self.tax_id.name,
-            cst_code=self.cst_code,
-        )
+        return f"{self.tax_group_id.name}-{self.tax_id.name}-{self.cst_code}"
 
     @api.depends("tax_group_id", "tax_id", "cst_code")
     def _compute_display_name(self):

odoo/addons/l10n_br_fiscal/readme/CONFIGURE.md

@@ -0,0 +1,7 @@
+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).

odoo/addons/l10n_br_fiscal/readme/CONTRIBUTORS.md

@@ -0,0 +1,12 @@
+- [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>\>
+- [KMEE](https://www.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):
+  - Marcel Savegnago \<<marcel.savegnago@escodoo.com.br>\>
+- [Engenere](https://engenere.one):
+  - Antônio S. Pereira Neto \<<neto@engenere.one>\>
+  - Felipe Motter Pereira \<<felipe@engenere.one>\>

odoo/addons/l10n_br_fiscal/readme/DESCRIPTION.md

@@ -0,0 +1,196 @@
+![image](../static/img/fiscal_dashboard.png)
+
+## 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.
+
+Produtos:  
+- 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
+
+## 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:
+
+``` 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 também lida com:
+
+- ST
+- retenções
+
+![image](../static/img/fiscal_line.png)
+
+![image](../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)...
+
+## Operações fiscais
+
+> ![image](../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 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.

odoo/addons/l10n_br_fiscal/readme/HISTORY.md

@@ -0,0 +1 @@
+

odoo/addons/l10n_br_fiscal/readme/INSTALL.md

@@ -0,0 +1,5 @@
+Para instalar o módulo l10n_br_fiscal, você precisa de instalar primeiro
+os pacotes Python
+
+- erpbrasil.base
+- erpbrasil.assinatura

odoo/addons/l10n_br_fiscal/readme/ROADMAP.md

@@ -0,0 +1 @@
+

odoo/addons/l10n_br_fiscal/readme/USAGE.md

@@ -0,0 +1,4 @@
+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...