odoo13-addon-l10n-br-fiscal 13.0.3.1.0

税务分类

首先，此模块引入了各种与产品、合作伙伴或公司相关的税务登记。在发行诸如NF-e、NFS-e等税务文件时……即使是简化税收制度或MEI公司也需要这些登记。而正常税收制度的企业则需要它们来计算税款或发行税务文件。

产品

• 税务类型

• NCM（与税收相关联）

• 税务类别

• CEST

• NBM

• NBS

• 服务类型

• 税务单位

合作伙伴

• CNAE

• 税务概要

税务文件概念

Odoo原生没有税务文件的概念。最相似的概念可能是account.invoice，甚至在10.0版本中，本地化扩展了invoice以仅支持NF-e和NFS-e。在那个时代，在Odoo中做SPED是不合理的，因为Odoo本身的核心还没有成熟到那个程度，所以当时仅支持Odoo中的NFe案例是合理的。

然而，在v12中，我们使XML/SOAP框架成熟，使其成为支持多种税务文件（NF-e、NFS-e、MDF-e、CT-e、EFD-Reinf、e-Social、GNRE、BP-e...）的合理选择，这些文件在OCA质量内得到了支持。此外，尽管复杂，但Odoo核心最终也足以支持进行SPED操作的企业。

在Odoo中，将税务文件的概念（l10n_br_fiscal.document）独立于发票模块，以支持所有税务文件，并以模块化方式存在，这是一个有趣的点。另一个在会计模块之外拥有税务文件概念的原因是，当你分析此模块（l10n_br_fiscal）的代码时，几乎没有什么可以由Odoo的会计模块完成。因此，拥有不依赖于会计模块的l10n_br_fiscal模块，也是将本地化模块化以便于维护的一种方式，特别是在涉及迁移时，因为模块可能已经发生了很大的变化，例如在v8.0和v9.0或v12.0和v13.0之间。这也有助于项目治理，使得人们可以负责不同的部分。l10n_br_fiscal模块主要从v7.0到v10.0的l10n_br_l10n_br_account_product模块提取而来。

此模块（l10n_br_fiscal）对任何XML或SOAP技术都是中立的。它仅包含税务文件中共同的部分，但这些部分在其他模块中实现。对于特定的税务文件，如Nf-e，例如

• nfelib：一个纯Python数据绑定包（不依赖于Odoo）。通常，我们使用代码生成器从农场的XSD模式生成这些绑定。

• l10n_br_nfe_spec：一个Odoo混入模块，也由XSD管理。这些混入只是规范的结构数据，在注入到现有的Odoo对象（如res.partner或l10n_br_fiscal.document）之前，或者在没有对象在Odoo或OCA中时，甚至成为具体对象。

• l10n_br_nfe：一个处理将税务映射注入到Odoo对象并实现逻辑的Odoo模块，例如用于传输的向导。

传输使用传输库如erpbrasil.doc（基于Python Zeep）进行。重要提示：在NFS-e的情况下，由于目前没有国家标准和模型（与NFe相比）的简单性，因此决定不使用Odoo管理的混入税务模块，映射是通过绑定库手动完成的，NFS-e家族通过家族。

此外，大多数< span class="docutils literal">l10n_br_fiscal.document和其行< span class="docutils literal">l10n_br_fiscal.document.line的代码实际上是在混入< span class="docutils literal">10n_br_fiscal.document.mixin和< span class="docutils literal">10n_br_fiscal.document.line.mixin中完成的。因此，这些混入可以注入到其他Odoo对象中，这些对象在税务文件之前，并可以存储相同类型的信息：sale.order，purchase.order，stock.picking等。这在扩展此模块的模块中非常明显。

|-- l10n_br_fiscal
    |-- l10n_br_sale
    |-- l10n_br_purchase
    |-- l10n_br_account
    |-- ...

但是，在< span class="docutils literal">l10n_br_account模块中的Odoo发票情况是不同的。因为已经有一个独立的税务文件表，其中大多数（在许多税务文件类型的情况下）数十甚至数百个税务字段不是与Odoo发票冗余的。如果我们把这些混入注入到发票中，那么这些数百个字段就会在发票和税务文件之间重复。因此，在< span class="docutils literal">l10n_br_account模块中采用的方法是，一个Odoo发票现在有一个< span class="docutils literal">_inherits = "l10n_br_fiscal.document"，这样就可以通过发票来操作税务文件，提供与之前相同类型的集成。同样的机制也发生在税务文件行上。

因此，通过_inherits，Odoo发票及其行已经可以拉取所有税务字段，就像它们来自各自的表一样，而不会在数据库中重复它们。除此之外，如果我们向invoice和invoice.line注入了10n_br_fiscal.document.mixin和10n_br_fiscal.document.line.mixin混合，这些税务字段也会以冗余的方式出现在account_invoice和account_invoice_line表中，与由_inherits拉取的字段重复。为了避免这个问题，我们在mixins中提取了常见的税务方法（不带字段）：10n_br_fiscal.document.mixin.methods和10n_br_fiscal.document.line.mixin.methods，它们分别注入到模块l10n_br_account中的account_invoice和account_invoice_line对象中。

巴西税

l10n_br_fiscal模块处理巴西的主要税种，例如

• 简易国家ICMS

• 正常制度ICMS

• IPI

• PIS

• COFINS

• ISSQN

• IRPJ

• II

• CSLL

• INSS

l10n_br_fiscal模块还处理

• ST

• 扣款

显然，在巴西计算税款非常特殊且繁琐。这通常是国际ERP在巴西市场份额不大的原因。

直到10.0版本，我们尝试使用和扩展Odoo的account.tax对象。Akretion甚至创建了项目OCA/account-fiscal-rule，以根据税务操作参数确定每个税种的税率。然而，我们几乎未使用account.fiscal.position的本地部分，相反，这迫使我们为每个税率创建一个account.tax记录，并迫使我们维护数百个税率和数十万个规则来选择Odoo将应用的正确“税务位置”。您还必须管理这些数十万个规则，以针对正常制度下的特定公司。结论：在小型项目中尝试将逻辑适应Odoo以计算巴西税款是不可行的。

因此，我们在本模块中创建了代表巴西税务操作的模型。除了计算之外，这些模型还用于加载税务表。此外，在模块l10n_br_account中，我们将本地account.tax对象与巴西税率的税率相连接。

当然，这些税务模型适用于正常制度下的企业，但最好记住，即使是简易制度下的企业也需要这些模型来执行与ST（税收替代）相关的操作...

税务操作

在Odoo原生中，与税务操作最相似的概念是“account.fiscal.position”。直到10.0版本，这是我们使用的内容。然而，Odoo的税务位置并未很好地解决我们的问题，因为

• 在巴西，每个税务文件行都有一个税务操作

• Odoo的税务位置不了解巴西税务参数的逻辑

• 由于我们在模块l10n_br_fiscal中（而不是account模块）之外拉取了税务登记，因此我们还没有在这个模块中的account.fiscal.position对象。

因此，我们选择创建一个l10n_br_fiscal.operation对象，它正好符合我们对巴西的需求。在模块l10n_br_account中，我们将在稍后进行税务位置和税务操作之间的集成。

目录

作者

• Akretion

贡献者

• Renato Lima <renato.lima@akretion.com.br>

• Raphaël Valyi <raphael.valyi@akretion.com.br>

• Magno Costa <magno.costa@akretion.com.br>

• Luis Felipe Mileo <mileo@kmee.com.br>

• Marcel Savegnago <marcel.savegnago@escodoo.com.br>

• Luis Otavio Malta Conceição <luis.malta@kmee.com.br>

维护者

此模块由OCA维护。

OCA，或Odoo社区协会，是一个非营利组织，其使命是支持Odoo功能的协作开发并推广其广泛使用。

当前 维护者

此模块是GitHub上的 OCA/l10n-brazil 项目的组成部分。

欢迎您贡献。要了解如何贡献，请访问 https://odoo-community.org/page/Contribute。