Repository
OCA/l10n-brazil · module folder · Try on Runboat
Module version
Category
Localisation
Folder size
1.0 MB
License
AGPL-3
Application
No
Auto-installable
No
Website
https://github.com/OCA/l10n-brazil
Last tracking update
2026-08-20 17:13:52
Authors
Akretion, Odoo Community Association (OCA)
Maintainers
Akretion, Odoo Community Association (OCA)
Committers
Raphaël Valyi, Renato Lima, Weblate, OCA-git-bot, oca-ci, CristianoMafraJunior
Odoo dependencies
Python dependencies
erpbrasil.base, email-validator, num2words, phonenumbers
System dependencies
None
Required by
l10n_br_purchase, l10n_br_sale, l10n_br_stock_account
Description
# Visão Geral

O módulo `l10n_br_account` integra o motor fiscal brasileiro (`l10n_br_fiscal`) ao framework contábil nativo do Odoo (módulo `account`). Ele integra a complexa lógica da tributação e dos documentos fiscais do Brasil com as faturas e lançamentos contábeis conforme as normas de contabilidade brasileiras.

O módulo atende desde a automação na emissão de notas para empresas do Simples Nacional até os cenários contábeis mais exigentes do regime normal (Lucro Real/Presumido).

# Arquitetura e Integração: Decorator Pattern (`_inherits`)

A arquitetura do módulo se baseia no mecanismo de herança por composição `_inherits` do Odoo para criar uma composição dinâmica entre os modelos fiscais e contábeis:

*   **account.move** herda de **l10n_br_fiscal.document**
*   **account.move.line** herda de **l10n_br_fiscal.document.line**

Esta abordagem, análoga ao *Decorator Pattern*, oferece as seguintes vantagens:

1.  **Gerenciamento Unificado**: Permite controlar o Documento Fiscal diretamente pela interface da Fatura do Odoo. Campos fiscais (CFOP, NCM, valores de impostos) são acessados e computados de forma transparente, como se fossem nativos do `account.move.line`.

2.  **Baixíssima Redundância de Dados**: A herança por composição evita a duplicação de centenas de campos fiscais nas tabelas contábeis. A "fonte da verdade" fiscal é sempre o registro em `l10n_br_fiscal.document`, garantindo um banco de dados normalizado e consistente.

3.  **Modularidade e Manutenção**: A lógica fiscal complexa permanece encapsulada no `l10n_br_fiscal`. Para assegurar a reatividade dos campos computados na interface da fatura, o módulo utiliza um *mixin* especializado (`l10n_br_account.decorator.mixin`) que gerencia a herança de métodos e campos dinâmicos.

# Principais Funcionalidades e Casos de Uso

# Uso Simplificado: Cálculo dos impostos e criação dos Documentos Fiscais

O módulo `l10n_br_account` é a peça chave para automatizar a emissão de documentos fiscais a partir de qualquer fluxo de negócio que gere uma fatura no Odoo, como:
*   Ordens de Venda (`sale.order`)
*   Ordens de Compra (`purchase.order`)
*   Movimentações de Estoque (`stock.picking`)
*   Contratos (`contract.contract`), entre outros.

A **Operação Fiscal** pré-configurada orquestra o preenchimento automático de todos os dados necessários, permitindo a geração de NF-e, NFS-e e outros documentos com mínima intervenção.

# Uso Avançado: Lançamentos contábeis corretos para as empresas do Regime Normal

Para empresas no Lucro Real ou Presumido, o `l10n_br_account` habilita uma gestão contábil e fiscal precisa e aderente à legislação.

*   **Lançamentos Contábeis de Impostos**: Conecta os impostos fiscais (`l10n_br_fiscal.tax`) aos contábeis (`account.tax`), garantindo que a validação de uma fatura gere os lançamentos corretos para ICMS, IPI, PIS, COFINS, etc., em suas respectivas contas (custo, recuperável, despesa).

*   **Operações Sem Impacto Financeiro**: Suporta operações como "Remessa para Industrialização", permitindo a emissão do documento fiscal obrigatório e o lançamento correto dos impostos, mas sem gerar contas a pagar ou a receber, mantendo a integridade fiscal e contábil.

*   **Composição de Valores Financeiros**: Gerencia a correta composição do valor financeiro das faturas. Por exemplo, assegura que o valor do IPI, quando não recuperável, seja somado ao contas a pagar do fornecedor.

*   **Importação de Documentos (XML)**: Facilita a importação de documentos de fornecedores, criando simultaneamente o `l10n_br_fiscal.document` com os dados fiscais e a fatura de fornecedor (`account.move`) pronta para validação e pagamento.

# Escopo e Delimitação do Módulo

O nome `l10n_br_account` deriva do módulo `account`, que ele estende. É importante notar que o módulo `account` do Odoo, em sua essência, é focado em faturamento, embora contenha os conceitos fundamentais de planos de contas e lançamentos contábeis.

Para uma contabilidade completa de uma empresa no regime normal, mesmo utilizando o Odoo Enterprise, é necessária a instalação de dezenas de módulos adicionais da OCA, provenientes de diversos repositórios da OCA. O `l10n_br_account`, apesar do nome, **não substitui** este ecossistema. Ele se concentra na ponte fiscal-contábil. Funções como conciliação avançada (através de módulos como `account_reconcile`), gestão de ordens de pagamento, integração bancária (CNAB) e importação de extratos são tratadas por dezenas de outros módulos específicos da OCA...

Por outro lado, é importante ressaltar que os autores deste módulo possuem clientes do regime normal com uma contabilidade significativamente mais completa do que a oferecida nativamente pelo Odoo Enterprise, baseando-se exclusivamente em módulos de código aberto da OCA. Alcançar tal nível de sofisticação, no entanto, exige anos de experiência em implementação e uma escolha estratégica da versão do Odoo. É importante evitar versões muito recentes, para as quais o ecossistema de módulos da OCA ainda não atingiu a maturidade e estabilidade necessárias após o processo de migração (uma versão nova do Odoo mal tem 500 módulos da OCA migrados depois de 6 meses, mas tem quase 2000 depois de um ano e quase 3000 depois de 3 anos).

Vale a pena mencionar que lançamentos de Custo da Mercadoria Vendida (CMV) e outros lançamentos de contabilidade de estoque IFRS/IAS2, são tipicamente realizados através da combinação do módulo nativo `stock_account`, do `l10n_br_stock_account` (deste mesmo repo) e da ativação do modo "anglo-saxon" no seu plano de contas.

# Detalhes sobre o modelo de dados

# Cardinalidade: Documentos Fiscais e Lançamentos Contábeis

A arquitetura suporta cenários onde um único lançamento financeiro (`account.move`) agrupa múltiplos documentos fiscais, como uma fatura única para pagar vários Conhecimentos de Transporte (CT-e). Esta flexibilidade é garantida por três campos-chave:

*   **account.move.fiscal_document_id**: O campo `Many2one` que implementa o `_inherits`. Representa o documento fiscal "principal" ou em edição na interface da fatura.

*   **account.move.line.fiscal_document_line_id**: O pilar da arquitetura. Permite que **cada linha** da fatura aponte para uma linha de um documento fiscal distinto. É isso que possibilita agregar múltiplos documentos em um único `account.move`.

*   **account.move.fiscal_document_ids**: Campo `One2many` computado que agrega todos os documentos fiscais vinculados às linhas da fatura, oferecendo uma visão completa e consolidada quando o lançamento tem mais de um documento fiscal.

A flexibilidade do design é bidirecional. O sistema também gerencia nativamente cenários onde **um lançamento contábil (`account.move`) não possui nenhum documento fiscal associado**. Isso é fundamental para operações puramente contábeis ou não fiscais, como:
*   Lançamentos de folha de pagamento.
*   Operações financeiras ou contábeis em empresas de um grupo multinacional que não operam no Brasil.

Além disso, mesmo dentro de uma fatura fiscalizada, a associação é granular. Apenas as linhas de produto (`invoice_line_ids` com `display_type='product'`) são vinculadas a uma `l10n_br_fiscal.document.line`. Linhas de impostos, de contas a pagar/receber, ou linhas de anotação/seção permanecem como lançamentos puramente contábeis, sem linha de documento fiscal específica.

# Observação sobre a Normalização do Modelo de Dados

Idealmente, o modelo de dados teria redundância zero. Contudo, para simplificar a injeção de mixins fiscais — em especial o `l10n_br_fiscal.document.line.mixin` — e alavancar a lógica nativa do Odoo, foi uma decisão de design manter a nomenclatura de um pequeno e controlado conjunto de campos, como `partner_id`, `company_id`, `user_id`, `currency_id`, `product_id`, `quantity`, `price_unit` e `name`.

Como consequência, existe uma redundância mínima e gerenciada. Considerando os milhares de campos necessários para a diversidade de documentos fiscais brasileiros, apenas cerca de quatro campos do `account.move` e quatro do `account.move.line` são efetivamente duplicados. Para garantir a integridade, estes campos (apelidados de *shadow fields*) são cuidadosamente sincronizados em tempo real, inclusive durante a edição de novos registros em memória (fase `NewId`), assegurando total consistência entre a fatura e o documento fiscal.

# A Separação Estratégica dos Mixins Fiscais

No caso do `account.move`, o objetivo era obter os campos do `l10n_br_fiscal.document` sem duplicá-los (o que o `_inherits` faz perfeitamente), mas também precisávamos de seus métodos (como `_compute_fiscal_tax_ids` ou `_compute_tax_fields`). Se usássemos `_inherit` no mixin principal (`l10n_br_fiscal.document.mixin`), teríamos os métodos, mas os campos seriam duplicados, quebrando o princípio de normalização.

Por outro lado, modelos como `sale.order` e `purchase.order` não são uma representação de um documento fiscal, mas sim precursores dele. Portanto, eles podem usar uma herança simples (`_inherit`) diretamente no mixin principal (`l10n_br_fiscal.document.mixin`), pois precisam tanto dos campos quanto dos métodos para preparar os dados que serão posteriormente utilizados na geração do documento fiscal.

# Modelo UML Simplificado

![UML account.move](../static/img/account_move.png)

![UML account.move.line](../static/img/account_move_line.png)

# Aviso Importante: Pré-requisitos e Complexidade

Para utilizar o `l10n_br_account` de forma eficaz, é necessário ter domínio aprofundado de dois ecossistemas complexos: o módulo `account` nativo do Odoo e o motor `l10n_br_fiscal` deste repositório.

O `account` é o maior e mais intrincado módulo do Odoo, constituindo por si só um ERP financeiro completo, e não apenas um simples software de emissão de notas para microempresas. Por sua vez, o `l10n_br_fiscal` é o maior módulo entre os mais de 3000 disponíveis na OCA. Este módulo, `l10n_br_account`, está também entre os três mais complexos da localização brasileira e exige um uso avançado do ORM do Odoo para gerenciar a dualidade documento fiscal/lançamento contábil.

A implementação bem-sucedida de um ERP estrangeiro no Brasil é uma tarefa que demanda profissionais altamente qualificados, com anos de experiência em programação backend (Python) e implantação de verdadeiros sistemas ERP. Uma implementação não se resume a baixar e instalar módulo (apenas 1% do trabalho); envolve análise de processos, configuração, migração de dados e customizações, migração de modulos OCA a partir de outras versões... Subestimar essa complexidade invariavelmente leva a projetos problemáticos e custos elevados no longo prazo.

Este aviso serve para alinhar expectativas e reforçar que o sucesso de uma implantação Odoo no Brasil depende de expertise técnica e funcional aprofundada. Infelizmente, este mercado atrai aventureiros que subestimam essa complexidade ou que vendem projetos acreditando ser possível terceirizar a execução sem grande compromisso com a entrega, explorando a falta de informação do cliente. Este cenário caracteriza um "market for lemons", onde a assimetria de informação torna difícil distinguir entre fornecedores qualificados e despreparados, impedindo o desenvolvimento de um mercado de implementação maduro.

Agravando a situação, onde se esperaria uma garantia criteriosa de qualidade, o ecossistema corporativo "oficial" investe pesadamente em propaganda para mascarar essa realidade, promovendo uma visão onde a consultoria de implementação é tratada como uma commodity. Esse modelo, focado em comissões pela venda de licenças (muitas vezes desnecessárias ao utilizar o ecossistema da OCA), alimenta um mercado paralelo notório de "parceiros fantoches/bucha de canhão" que compram certificações oficiais de empresas estrangeiras para simular uma competência que não possuem. Cuidado com profissionais que ostentam certificações compradas para transferir a responsabilidade da implementação sem o devido suporte ou conhecimento real. Não se deixe enganar por narrativas que simplificam a complexidade do projeto para priorizar a venda de licenças!

# Conclusão

O `l10n_br_account` possui um design robusto que unifica as complexas lógicas fiscal e contábil do Brasil dentro do Odoo. Sua arquitetura, projetada por especialistas para especialistas, oferece uma plataforma flexível e confiável, capaz de sustentar operações de alta complexidade e garantir a conformidade fiscal e contábil das empresas que utilizam a localização brasileira da OCA.

Code Analysis

Views touched (14)
XML IDNameModelTypeStatus
account_document_form_inherit l10n_br_account.document.form.inherit l10n_br_fiscal.document form Inherits l10n_br_fiscal.document_form
account_move_reversal_form account.move.reversal.form account.move.reversal form Inherits account.view_account_move_reversal
document_import_wizard_form l10n_br_account.document.import.wizard.form l10n_br_fiscal.document.import.wizard form Inherits l10n_br_fiscal.document_import_wizard_form
document_line_form l10n_br_fiscal.document.line.form l10n_br_fiscal.document.line form Inherits l10n_br_fiscal.document_line_form
fiscal_operation_form fiscal.operation.form l10n_br_fiscal.operation form Inherits l10n_br_fiscal.operation_form
fiscal_operation_line_form fiscal.operation.line.form l10n_br_fiscal.operation.line form Inherits l10n_br_fiscal.operation_line_form
fiscal_operation_search fiscal.operation.search l10n_br_fiscal.operation search Inherits l10n_br_fiscal.operation_search
fiscal_operation_tree fiscal.operation.tree l10n_br_fiscal.operation tree Inherits l10n_br_fiscal.operation_tree
invoice_form l10n_br_account.invoice.form account.move form Inherits account.view_move_form
invoice_search l10n_br_account.invoice.search account.move search Inherits account.view_account_invoice_filter
invoice_tree l10n_br_account.invoice.tree account.move tree Inherits account.view_invoice_tree
l10n_br_account_partner_form l10n_br_account.res.partner.form res.partner form Inherits account.view_partner_property_form
l10n_br_account_product_view_account_invoice_report_search l10n_br_account.invoice.report.search account.invoice.report search Inherits account.view_account_invoice_report_search
l10n_br_account_tax_form l10n_br_account.tax.form account.tax form Inherits account.view_tax_form
HTTP endpoints (0)

No HTTP endpoints found for this module.

Models touched (20)

New fields (0)

No new fields.

Public methods (1)
  • load_fiscal_taxes(self, companies=None)
    Create missing account.tax for Brazil. Add missing account.account for the Brazilian taxes. Relate account taxes with fiscal taxes to enable the Brazilian tax engine to kick in with the installed chart of account.

New fields (0)

No new fields.

Public methods (0)

No public methods.

New fields (25)
  • cest_id Many2one → l10n_br_fiscal.cest
    comodel_name='l10n_br_fiscal.cest' string='CEST'
  • cfop_id Many2one → l10n_br_fiscal.cfop
    comodel_name='l10n_br_fiscal.cfop' string='CFOP'
  • cofins_value Float
    digits='Account' string='COFINS Value'
  • discount_value Float
    digits='Account'
  • document_serie_id Many2one → l10n_br_fiscal.document.serie
    comodel_name='l10n_br_fiscal.document.serie'
  • document_type_id Many2one → l10n_br_fiscal.document.type
    comodel_name='l10n_br_fiscal.document.type' string='Fiscal Document Type'
  • fiscal_operation_id Many2one → l10n_br_fiscal.operation
    comodel_name='l10n_br_fiscal.operation' string='Operation'
  • fiscal_operation_line_id Many2one → l10n_br_fiscal.operation.line
    comodel_name='l10n_br_fiscal.operation.line' string='Operation Line'
  • fiscal_type Selection
    selection=PRODUCT_FISCAL_TYPE
  • freight_value Float
    digits='Account'
  • icms_destination_value Float
    digits='Account' string='Valor Difal Destino'
  • icms_origin_value Float
    digits='Account' string='Valor Difal Origem'
  • icms_value Float
    digits='Account' string='Valor ICMS'
  • icmsfcp_value Float
    digits='Account' string='Valor Difal FCP'
  • icmsst_value Float
    digits='Account' string='Valor ICMS ST'
  • ii_value Float
    digits='Account' string='II Value'
  • insurance_value Float
    digits='Account'
  • ipi_value Float
    digits='Account' string='IPI Value'
  • issqn_value Float
    digits='Account'
  • issuer Selection
    selection=DOCUMENT_ISSUER
  • nbm_id Many2one → l10n_br_fiscal.nbm
    comodel_name='l10n_br_fiscal.nbm' string='NBM'
  • ncm_id Many2one → l10n_br_fiscal.ncm
    comodel_name='l10n_br_fiscal.ncm' string='NCM'
  • other_value Float
    digits='Account'
  • pis_value Float
    digits='Account' string='PIS Value'
  • service_type_id Many2one → l10n_br_fiscal.service.type
    comodel_name='l10n_br_fiscal.service.type'
Public methods (0)

No public methods.

New fields (0)

No new fields.

Public methods (1)
  • create_document_from_attachment(self, attachment_ids=None)

New fields (4)
  • document_electronic Boolean
    related='document_type_id.electronic' string='Electronic?'
  • fiscal_document_id Many2one → l10n_br_fiscal.document
    comodel_name='l10n_br_fiscal.document' copy=False index='btree_not_null' ondelete='cascade' readonly=False store=True string='Fiscal Document'
  • fiscal_document_ids One2many → l10n_br_fiscal.document
    comodel_name='l10n_br_fiscal.document' compute='_compute_fiscal_document_ids' help='In some rare cases (NFS-e, CT-e...) a single account.move\n may have several different fiscal documents related to its account.move.lines.\n ' string='Fiscal Documents'
  • fiscal_operation_type Selection
    compute='_compute_fiscal_operation_type' related=None selection=FISCAL_IN_OUT_ALL
Public methods (21)
  • action_document_back2draft(self)
    Sets fiscal document to draft state and cancel and set to draft the related invoice for both documents remain equivalent state.
  • action_document_cancel(self)
  • action_document_correction(self)
  • action_document_invalidate(self)
  • action_document_send(self)
  • action_send_email(self)
  • action_view_invoice(self)
  • button_cancel(self)
  • button_draft(self)
    Set the move to draft state, handling fiscal documents.
  • button_import_fiscal_document(self)
    Import move fields and invoice lines from the fiscal_document_id record if there is any new line to import. You can typically set fiscal_document_id to some l10n_br_fiscal.document record that was imported previously and import its lines into the current move.
  • copy_data(self, default=None)
  • create(self, vals_list)
    @api.model_create_multi
  • default_get(self, fields_list)
    @api.model
  • ensure_one_doc(self)
  • import_fiscal_document(self, fiscal_document, move_id=None, move_type='in_invoice')
    @api.model
    Import the data from an existing fiscal document into a new invoice or into an existing invoice. First it transfers the "shadowed" fields and fill the other mandatory invoice fields. The account.move onchanges of these fields are properly triggered as if the invoice was filled manually. Then it creates each account.move.line and fill them using their fiscal_document_id onchange.
  • open_fiscal_document(self)
    If there is only 1 fiscal document (usual case), open the fiscal form view for it. Open the tree view in the case of several fiscal documents.
  • unlink(self)
    Allow to delete draft or cancelled invoices
  • update_payment_term_number(self)
  • view_pdf(self)
  • view_xml(self)
  • write(self, vals)

New fields (8)
  • discount Float
    compute='_compute_discounts' store=True
  • document_type_id Many2one → l10n_br_fiscal.document.type
    comodel_name='l10n_br_fiscal.document.type' related='move_id.document_type_id' string='Fiscal Document Type'
  • fiscal_document_line_id Many2one → l10n_br_fiscal.document.line
    comodel_name='l10n_br_fiscal.document.line' copy=False index='btree_not_null' ondelete='cascade' string='Fiscal Document Line'
  • name Char
    inverse='_inverse_name'
  • payment_term_number Char
    help="Stores the installment number in the format 'current-total'. For example, '1-3' for the first of three installments, '2-3' for the second, and '3-3' for the last installment."
  • price_unit Float
    inverse='_inverse_price_unit'
  • product_uom_id Many2one
    inverse='_inverse_product_uom_id'
  • quantity Float
    inverse='_inverse_quantity'
Public methods (5)
  • copy_data(self, default=None)
  • create(self, vals_list)
    @api.model_create_multi
  • default_get(self, fields_list)
    @api.model
  • unlink(self)
  • write(self, values)

New fields (3)
  • force_fiscal_operation_id Many2one → l10n_br_fiscal.operation
    comodel_name='l10n_br_fiscal.operation' string='Force Fiscal Operation'
  • force_fiscal_operation_journal_id Many2one
    related='force_fiscal_operation_id.journal_id'
  • journal_id Many2one
    compute='_compute_journal_id' precompute=True store=True
Public methods (1)
  • reverse_moves(self, is_modify=False)

New fields (1)
  • fiscal_tax_ids One2many → l10n_br_fiscal.tax
    comodel_name='l10n_br_fiscal.tax' related='tax_group_id.fiscal_tax_group_id.tax_ids' string='Fiscal Taxes'
Public methods (1)
  • compute_all(self, price_unit, currency=None, quantity=1.0, product=None, partner=None, is_refund=False, handle_price_include=True, include_caba_tags=False, rounding_method=None, fixed_multiplicator=1, fiscal_taxes=None, operation_line=False, ncm=None, nbs=None, nbm=None, cest=None, cfop=None, discount_value=None, insurance_value=None, other_value=None, ii_customhouse_charges=None, freight_value=None, fiscal_price=None, fiscal_quantity=None, uot_id=None, icmssn_range=None, icms_origin=None, ind_final=FINAL_CUSTOMER_NO)
    Returns all information required to apply taxes (in self + their children in case of a tax goup). We consider the sequence of the parent for group of taxes. Eg. considering letters as taxes and alphabetic order as sequence : [G, B([A, D, F]), E, C] will be computed as [A, D, F, C, E, G] RETURN: { 'total_excluded': 0.0, # Total without taxes 'total_included': 0.0, # Total with taxes 'taxes': [{ # One dict for each tax in self # and their children 'id': int, 'name': str, 'amount': float, 'sequence': int, 'account_id': int, 'refund_account_id': int, 'analytic': boolean, }] }

New fields (1)
  • fiscal_tax_group_id Many2one → l10n_br_fiscal.tax.group
    comodel_name='l10n_br_fiscal.tax.group' string='Fiscal Tax Group'
Public methods (1)
  • deductible_tax(self, type_tax_use='sale')

New fields (0)

No new fields.

Public methods (0)

No public methods.

New fields (0)

No new fields.

Public methods (0)

No public methods.

New fields (0)

No new fields.

Public methods (1)
  • create(self, vals_list)
    @api.model_create_multi

New fields (14)
  • company_id Many2one
    default=None precompute=True readonly=False related='proxy_company_id' store=True
  • date_in_out Datetime
    compute='_compute_date_in_out' inverse='_inverse_date_in_out' store=True
  • document_date Datetime
    compute='_compute_document_date' inverse='_inverse_document_date' store=True
  • fiscal_line_ids One2many
    copy=False
  • incoterm_id Many2one → account.incoterms
    comodel_name='account.incoterms' compute='_compute_incoterm_id' inverse='_inverse_incoterm_id' string='Fiscal Inconterm'
  • move_count Integer
    compute='_compute_move_count' readonly=True string='Invoice count'
  • move_ids One2many → account.move
    comodel_name='account.move' inverse_name='fiscal_document_id' string='Invoices'
  • partner_id Many2one
    precompute=True readonly=False related='proxy_partner_id' store=True
  • partner_shipping_id Many2one
    precompute=True readonly=False related='proxy_partner_shipping_id' store=True
  • proxy_company_id Many2one → res.company
    comodel_name='res.company' default=<expr> help='Technical Field.' string='Company (proxy)'
  • proxy_partner_id Many2one → res.partner
    comodel_name='res.partner' help='Technical Field.' string='Partner (proxy)'
  • proxy_partner_shipping_id Many2one → res.partner
    comodel_name='res.partner' help='Technical Field.' string='Shipping Partner (proxy)'
  • proxy_user_id Many2one → res.users
    comodel_name='res.users' help='Technical Field.' string='User (proxy)'
  • user_id Many2one
    default=None precompute=True readonly=False related='proxy_user_id' store=True
Public methods (8)
  • action_document_back2draft(self)
  • action_document_confirm(self)
  • action_view_invoice(self)
  • cancel_move_ids(self)
  • create(self, vals_list)
    @api.model_create_multi
    It's not allowed to create a fiscal document line without a document_type_id anyway. But instead of letting Odoo crash in this case we simply avoid creating the record. This makes it possible to create an account.move without a fiscal_document_id despite the _inherits system: Odoo will write NULL as the value in this case.
  • exec_after_SITUACAO_EDOC_DENEGADA(self, old_state, new_state)
  • message_post(self, **kwargs)
    @api.returns('mail.message', <expr>)
    broadcast message_post to all related account.move so messages in a fiscal document chatter are visible in the related account moves.
  • unlink(self)

New fields (1)
  • first_imported_move_id Integer
Public methods (1)
  • action_import_and_open_move(self)
    This is the import wizard confirmation action that will trigger the account.move importation for the current file. After the importation, it either redirect for processing the next file if any, either it redirect to the imported account.move(s) at the end of the attachments sequence.

New fields (14)
  • account_line_ids One2many → account.move.line
    comodel_name='account.move.line' inverse_name='fiscal_document_line_id' string='Invoice Lines'
  • company_id Many2one → res.company
    comodel_name='res.company' precompute=True readonly=False related='proxy_company_id' store=True string='Company'
  • document_id Many2one → l10n_br_fiscal.document
    check_company=True comodel_name='l10n_br_fiscal.document' compute='_compute_document_id' index=True ondelete='cascade' precompute=True readonly=False store=True string='Fiscal Document (Account)'
  • move_id Many2one → account.move
    comodel_name='account.move' precompute=True related='account_line_ids.move_id' store=True string='Invoice'
  • name Char
    compute='_compute_name' precompute=True readonly=False store=True
  • product_id Many2one → product.product
    comodel_name='product.product' precompute=True readonly=False related='proxy_product_id' store=True string='Product'
  • proxy_company_id Many2one → res.company
    comodel_name='res.company' help='Technical Field.' precompute=True readonly=False related='document_id.company_id' store=True string='Company (proxy)'
  • proxy_name Char
    help='Technical Field.' string='Name (proxy)'
  • proxy_partner_id Many2one → res.partner
    comodel_name='res.partner' help='Technical Field.' string='Partner (proxy)'
  • proxy_price_unit Float
    help='Technical mirror.' string='Unit Price (proxy)'
  • proxy_product_id Many2one → product.product
    comodel_name='product.product' string='Product (proxy)'
  • proxy_quantity Float
    help='Technical Field.' string='Quantity (proxy)'
  • quantity Float
    precompute=True readonly=False related='proxy_quantity' store=True string='Quantity'
  • uom_id Many2one
    inverse='_inverse_uom_id'
Public methods (1)
  • create(self, vals_list)
    @api.model_create_multi
    Override the create method to ensure it filters out account.move.line records that lack a valid document_id or fiscal_operation_line_id. Prevent the creation of fiscal document lines without these mandatory fields to avoid system crashes due to invalid records. If the conditions are not met, return an empty list instead of creating any records. This supports the creation of account.move.line records with NULL values for fiscal_document_line_id where necessary.

New fields (3)
  • deductible_taxes Boolean
    company_dependent=True
  • fiscal_position_id Many2one → account.fiscal.position
    comodel_name='account.fiscal.position' company_dependent=True string='Fiscal Position'
  • journal_id Many2one → account.journal
    comodel_name='account.journal' company_dependent=True domain="[('type', 'in', {'out': ['sale', 'general'], 'in': ['purchase', 'general'], 'all': ['sale', 'purchase', 'general']}.get(fiscal_operation_type, []))]" string='Account Journal'
Public methods (0)

No public methods.

New fields (1)
  • fiscal_position_id Many2one → account.fiscal.position
    comodel_name='account.fiscal.position' company_dependent=True string='Fiscal Position'
Public methods (0)

No public methods.

New fields (0)

No new fields.

Public methods (3)
  • account_taxes(self, user_type='sale', fiscal_operation=False, company=False)
  • create(self, vals_list)
    @api.model_create_multi
  • unlink(self)

New fields (0)

No new fields.

Public methods (1)
  • account_tax_group(self)

New fields (0)

No new fields.

Public methods (1)
  • write(self, values)
    Overriden so we can change the currency_id of base.main_company and specific demo companies even if constraints would normally prevent it.

Loading…

Loading…

Loading…

Loading…

Loading…

Loading…

Loading…

Loading…

Loading…

Loading…