TIP: You can type at any time to perform a new search.
Invoicing and accounting entries for Brazil
l10n_br_account · OCA/l10n-brazil
- 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   # 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 ID | Name | Model | Type | Status |
|---|---|---|---|---|
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_idMany2one → l10n_br_fiscal.cestcomodel_name='l10n_br_fiscal.cest'string='CEST' -
cfop_idMany2one → l10n_br_fiscal.cfopcomodel_name='l10n_br_fiscal.cfop'string='CFOP' -
cofins_valueFloatdigits='Account'string='COFINS Value' -
discount_valueFloatdigits='Account' -
document_serie_idMany2one → l10n_br_fiscal.document.seriecomodel_name='l10n_br_fiscal.document.serie' -
document_type_idMany2one → l10n_br_fiscal.document.typecomodel_name='l10n_br_fiscal.document.type'string='Fiscal Document Type' -
fiscal_operation_idMany2one → l10n_br_fiscal.operationcomodel_name='l10n_br_fiscal.operation'string='Operation' -
fiscal_operation_line_idMany2one → l10n_br_fiscal.operation.linecomodel_name='l10n_br_fiscal.operation.line'string='Operation Line' -
fiscal_typeSelectionselection=PRODUCT_FISCAL_TYPE -
freight_valueFloatdigits='Account' -
icms_destination_valueFloatdigits='Account'string='Valor Difal Destino' -
icms_origin_valueFloatdigits='Account'string='Valor Difal Origem' -
icms_valueFloatdigits='Account'string='Valor ICMS' -
icmsfcp_valueFloatdigits='Account'string='Valor Difal FCP' -
icmsst_valueFloatdigits='Account'string='Valor ICMS ST' -
ii_valueFloatdigits='Account'string='II Value' -
insurance_valueFloatdigits='Account' -
ipi_valueFloatdigits='Account'string='IPI Value' -
issqn_valueFloatdigits='Account' -
issuerSelectionselection=DOCUMENT_ISSUER -
nbm_idMany2one → l10n_br_fiscal.nbmcomodel_name='l10n_br_fiscal.nbm'string='NBM' -
ncm_idMany2one → l10n_br_fiscal.ncmcomodel_name='l10n_br_fiscal.ncm'string='NCM' -
other_valueFloatdigits='Account' -
pis_valueFloatdigits='Account'string='PIS Value' -
service_type_idMany2one → l10n_br_fiscal.service.typecomodel_name='l10n_br_fiscal.service.type'
No public methods.
New fields (0)
No new fields.
Public methods (1)-
create_document_from_attachment(self, attachment_ids=None)
New fields (4)
-
document_electronicBooleanrelated='document_type_id.electronic'string='Electronic?' -
fiscal_document_idMany2one → l10n_br_fiscal.documentcomodel_name='l10n_br_fiscal.document'copy=Falseindex='btree_not_null'ondelete='cascade'readonly=Falsestore=Truestring='Fiscal Document' -
fiscal_document_idsOne2many → l10n_br_fiscal.documentcomodel_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_typeSelectioncompute='_compute_fiscal_operation_type'related=Noneselection=FISCAL_IN_OUT_ALL
-
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.modelImport 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)
-
discountFloatcompute='_compute_discounts'store=True -
document_type_idMany2one → l10n_br_fiscal.document.typecomodel_name='l10n_br_fiscal.document.type'related='move_id.document_type_id'string='Fiscal Document Type' -
fiscal_document_line_idMany2one → l10n_br_fiscal.document.linecomodel_name='l10n_br_fiscal.document.line'copy=Falseindex='btree_not_null'ondelete='cascade'string='Fiscal Document Line' -
nameCharinverse='_inverse_name' -
payment_term_numberCharhelp="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_unitFloatinverse='_inverse_price_unit' -
product_uom_idMany2oneinverse='_inverse_product_uom_id' -
quantityFloatinverse='_inverse_quantity'
-
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_idMany2one → l10n_br_fiscal.operationcomodel_name='l10n_br_fiscal.operation'string='Force Fiscal Operation' -
force_fiscal_operation_journal_idMany2onerelated='force_fiscal_operation_id.journal_id' -
journal_idMany2onecompute='_compute_journal_id'precompute=Truestore=True
-
reverse_moves(self, is_modify=False)
New fields (1)
-
fiscal_tax_idsOne2many → l10n_br_fiscal.taxcomodel_name='l10n_br_fiscal.tax'related='tax_group_id.fiscal_tax_group_id.tax_ids'string='Fiscal Taxes'
-
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_idMany2one → l10n_br_fiscal.tax.groupcomodel_name='l10n_br_fiscal.tax.group'string='Fiscal Tax Group'
-
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_idMany2onedefault=Noneprecompute=Truereadonly=Falserelated='proxy_company_id'store=True -
date_in_outDatetimecompute='_compute_date_in_out'inverse='_inverse_date_in_out'store=True -
document_dateDatetimecompute='_compute_document_date'inverse='_inverse_document_date'store=True -
fiscal_line_idsOne2manycopy=False -
incoterm_idMany2one → account.incotermscomodel_name='account.incoterms'compute='_compute_incoterm_id'inverse='_inverse_incoterm_id'string='Fiscal Inconterm' -
move_countIntegercompute='_compute_move_count'readonly=Truestring='Invoice count' -
move_idsOne2many → account.movecomodel_name='account.move'inverse_name='fiscal_document_id'string='Invoices' -
partner_idMany2oneprecompute=Truereadonly=Falserelated='proxy_partner_id'store=True -
partner_shipping_idMany2oneprecompute=Truereadonly=Falserelated='proxy_partner_shipping_id'store=True -
proxy_company_idMany2one → res.companycomodel_name='res.company'default=<expr>help='Technical Field.'string='Company (proxy)' -
proxy_partner_idMany2one → res.partnercomodel_name='res.partner'help='Technical Field.'string='Partner (proxy)' -
proxy_partner_shipping_idMany2one → res.partnercomodel_name='res.partner'help='Technical Field.'string='Shipping Partner (proxy)' -
proxy_user_idMany2one → res.userscomodel_name='res.users'help='Technical Field.'string='User (proxy)' -
user_idMany2onedefault=Noneprecompute=Truereadonly=Falserelated='proxy_user_id'store=True
-
action_document_back2draft(self) -
action_document_confirm(self) -
action_view_invoice(self) -
cancel_move_ids(self) -
create(self, vals_list)@api.model_create_multiIt'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_idInteger
-
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_idsOne2many → account.move.linecomodel_name='account.move.line'inverse_name='fiscal_document_line_id'string='Invoice Lines' -
company_idMany2one → res.companycomodel_name='res.company'precompute=Truereadonly=Falserelated='proxy_company_id'store=Truestring='Company' -
document_idMany2one → l10n_br_fiscal.documentcheck_company=Truecomodel_name='l10n_br_fiscal.document'compute='_compute_document_id'index=Trueondelete='cascade'precompute=Truereadonly=Falsestore=Truestring='Fiscal Document (Account)' -
move_idMany2one → account.movecomodel_name='account.move'precompute=Truerelated='account_line_ids.move_id'store=Truestring='Invoice' -
nameCharcompute='_compute_name'precompute=Truereadonly=Falsestore=True -
product_idMany2one → product.productcomodel_name='product.product'precompute=Truereadonly=Falserelated='proxy_product_id'store=Truestring='Product' -
proxy_company_idMany2one → res.companycomodel_name='res.company'help='Technical Field.'precompute=Truereadonly=Falserelated='document_id.company_id'store=Truestring='Company (proxy)' -
proxy_nameCharhelp='Technical Field.'string='Name (proxy)' -
proxy_partner_idMany2one → res.partnercomodel_name='res.partner'help='Technical Field.'string='Partner (proxy)' -
proxy_price_unitFloathelp='Technical mirror.'string='Unit Price (proxy)' -
proxy_product_idMany2one → product.productcomodel_name='product.product'string='Product (proxy)' -
proxy_quantityFloathelp='Technical Field.'string='Quantity (proxy)' -
quantityFloatprecompute=Truereadonly=Falserelated='proxy_quantity'store=Truestring='Quantity' -
uom_idMany2oneinverse='_inverse_uom_id'
-
create(self, vals_list)@api.model_create_multiOverride 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_taxesBooleancompany_dependent=True -
fiscal_position_idMany2one → account.fiscal.positioncomodel_name='account.fiscal.position'company_dependent=Truestring='Fiscal Position' -
journal_idMany2one → account.journalcomodel_name='account.journal'company_dependent=Truedomain="[('type', 'in', {'out': ['sale', 'general'], 'in': ['purchase', 'general'], 'all': ['sale', 'purchase', 'general']}.get(fiscal_operation_type, []))]"string='Account Journal'
No public methods.
New fields (1)
-
fiscal_position_idMany2one → account.fiscal.positioncomodel_name='account.fiscal.position'company_dependent=Truestring='Fiscal Position'
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…