[RFC] Permitir a criação de múltiplos documentos fiscais a partir de uma invoice.

[mileo]

Dado o seguinte cenário, um pedido de vendas, com os seguintes itens:

1 - Produto: R$ 10,00
2 - Serviço: R$ 15,00
3 - Doação: R$ 1,00 - Usando o módulo sale_donation: https://github.com/OCA/donation/tree/11.0/donation_sale

Total do pedido de venda: 36,00 R$

No mundo perfeito seria criado, apenas uma invoice referente a todos os itens.

E os seguintes documentos fiscais para cada item:

1 - NF-E
2 - NFS-E
3 - S/ Documento fiscal

Atualmente isso não é possível na localização, não sei se vala a pena fazer-mos que seja.

Só estou abrindo a questão, pois se alguém lembrar de mais alguma coisa, podemos ir discutindo aqui!

[]s

@rvalyi @renatonlima @hendrixcosta @sadamo @gabrielcardoso21 @marcelsavegnago

[mileo]

Lembrei de um segundo cenário que estávamos falando esses dias.

Na nota fiscal de serviços temos alguns detalhes:

1. Alguns provedores só aceitam um item. E como cada NFs-e só aceita um tipo de serviço. O que se faz é agrupar as notas com os itens do mesmo tipo de serviço.

2. Alguns provedores aceitam mais de um item, desde que do todos tenham o mesmo tipo de serviço.

[rvalyi]

Bom, primeiro eu não vou me pronunciar se realmente tem essa necessidade porque isso eu na sei avaliar. Sera se os outros ERP nacionais tem esse conceito de apenas um invoice e com varios documentos fiscais por trás?
Em bom lembrar que tb existe a possibilidade da nota conjugada, ou de ter apenas um sale.order e varios invoices (o l10n_br_sale faz esse split), ou um so agreement (contrato) OCA e varios invoices e documentos por tras. E enfim talvez possivel juntar os account.move.line de varios documentos no mesmo account.move (por examplo lancamento de venda com os lancamento de stock do stock_account), sobre juntar de varios invoices ai teria que estudar, especialmente como ficaria na v13/v14 e talvez nao seria uma boa.

Bem a partir dai vou admitir a hipótese que realmente precisamos que um mesmo invoice possa ter varios documentos fiscais mesmo como vc @mileo colocou.

No modelo atual da v12, 2 coisas sao herdadas do documentos fiscal no invoice:

1. campos, como o partner_id, a data... isso pelo _inherits do invoice para o fiscal document.
2. metodos atraves do mixin l10n_br_fiscal.document.mixin.methods desse PR [12.0][MIG[REF] Split Fiscal Mixin Document in two class Fields and Methods #881

No caso dos campos, para a grande maioria deles eu entendo que cada documento fiscal seria meio que uma copia desses mesmos campos comum com o invoice e que apenas (ou quase) os campos adicionais do documento fiscal e as linhas seriam diferentes.

Nisso eu imagino que uma solucao tecnica poderia ser:
No account.invoice.line, ter um related_fiscal_document_id baseado em document_line_id.document_id.

Em 95% dos casos onde tem so um documento fiscal por tras de um invoice:

Nesses casos, esse related_fiscal_document_id sempre aponta no fiscal_document_id do invoice da linha. E ai eh muito importante ter as vantagens de ergonomia (fica muito igual dos tutorias oficiais da Odoo SA/OCA) e consistência dos dados que tras os _inherits/inherit do modelo atual para esses 95% dos casos.

Para os 5% de casos excepcionais que vc menciona onde teria sim ate um documento fiscal por linha:

Ai nesse caso, a gente poderia ter um cuidado especial dentro de alguns metodos l10n_br_fiscal.document.mixin.methods (por examplo transmitir, cancela) para que nao se possa executar o método e ter um warning do tipo, "vc deve navegar no documento fiscal especifico da linha para efetuar aquela ação!"

Eu acho que no invoice poderia entao ter um campo boolean do tipo is_singe_edoc computado que olharia se o related_fiscal_document_id de tods invoice line eh o mesmo ou nao. Ai o warning que eu falei no paragrafo antes, simplesmente testaria esse is_singe_edoc.

Um outro problema vai ser a aba totalizadora, ou abas especificas do documento fiscal, como NFe, NFSe etc...
Ai nesse caso, eu proponho que nas abas especifica, a gente tenha um group de visibilidade baseado no valor desse is_singe_edoc
Caso is_singe_edoc == False ai a gente esconde a aba e/ou manda o usuario ver o detalho navegando no documento fiscal especifico da linha.

[rvalyi]

tecnicamente, a forma que eu vejo de realizar isso, seria que no invoice.line, vc tivesse um botao tipo "ligar a um documento fiscal especifico". Qdo o usuario clicar, aconteceria um copy() do fiscal_documment_id do invoice (com a atualizacao correcta de alguns campos, como o tipo do documento, a serie etc...) e ligaria esse novo documento fiscal no document_id da linha, e chamaria os onchanges adequedos.

Seria possível imaginar que ao salvar um invoice, o codigo por tras desse botão rodasse de forma automática para cada linha, se o houver alguma parametrizacao para permitir isso. Dai com essa parametrização, seria por examplo possivel criar um sale.order com servico e produtos e nao fazer nem o split atual no module l10n_n_br_sale, nem uma nota conjugada, mas acontecer esse split do documento fiscal automaticamente qdo o invoice for salvo/criado pelo modulo sale. Hoje eu diria que muda bastante a forma como trabalhamos na v8 e v10 entao eu nao botaria isso como configuração padrão, pelo menos inicialmente ate a gente ter certeza que isso nao cria problema maior que a gente ainda nao pensou.

[gabrielcardoso21]

Gostei do conceito da nota conjugada. Poderíamos ter um documento relacionado ao account.invoice que tenha o document_type_id='Documento Fiscal Composto' e que tenha vários documentos relacionados pelo campo já existente fiscal_document_related_ids. Podemos até fazer a criação desses documentos utilizando o conceito de operações subsequentes. Tudo isso pode ser feito sem muitas mudanças na arquitetura, com as alterações sugeridas pelo @rvalyi nas linhas do documento e um campo fiscal_document_ids many2many no account.invoice para ajudar na navegabilidade, vejo como algo que resolve o problema sem mudar toda a arquitetura.

[rvalyi]

Na vdd o codigo atual ja suporta a nota conjugada e isso desde a v8. Eu acho que poderia ter sim esse 'Documento Fiscal Composto' mas eh bom ter na mente que isso nao deve substituir a NFe conjugada. E tb eh bom ter uma configuracao para que esse 'Documento Fiscal Composto' passe a substituir a nota conjugada (documento fiscal unico) ou nao. Pois por examplo ate agora com dezenas de clientes nao tivemos a necessidade de 'Documento Fiscal Composto', mas isso nao significa que nao existe a necessidade claro. Seria o caso pro Ginfes entao?

O lance eh que o sistema do _inherits permite assim como na v7,8 e 10 de assimilar o invoice com o documento fiscal, sendo que na v12 vc pode tb usar o modulo fiscal apenas ou um documento fiscal sem invoice entao. Mas eh bom guardar na mente que toda documentacao e modulos do Odoo e da OCA sempre vao usar o invoice do Odoo (mesmo ele sendo assimilado ao account.move nas v13/v14) e nao sabem nada de documento fiscal. Nisso eh essential que os casos simples continuam simples, com essa assimilação possivel. Pois isso facilita a documentação e a navegação, não precisa clicar para abri o documento fiscal a principio o que leva segundos a mais, confunde a navegação, fica chato num dispositivo movel... Então eh bom usar os documentos compostos o obrigar a navegar no documento fiscal apenas se quando for realmente preciso.
cc @renatonlima

[marcos-mendez]

Eu gostei da ideia, é o tipo de coisa que acontece direto com transporte próprio:

PRODUTO - NF-e
SERVIÇO - Transporte do Produto - NFS-e

[github-actions]

There hasn't been any activity on this issue in the past 6 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 30 days.
If you want this issue to never become stale, please ask a PSC member to apply the "no stale" label.

[rvalyi]

Pessoal esse meu PR vai facilitar esse tipo de caso: se vc gerir (da forma como quiser) varios documentos fiscais, pode juntar no mesmo account.move: #2761