[14.0][WIP] Importação de Documentos Fiscais, Integração com Compras e Estoque

[mileo]

Inclui e/ou depende de:

1. [14.0][l10n_br_account][IMP] composite account.move #2761
2. [14.0][l10n_br_fiscal][l10n_br_nfe][l10n_br_account][l10n_br_account_nfe] importação dos account.move com as NFe's - contra-proposta #2781
3. [14.0][NEW] Módulo de integração entre importação de notas fiscais e estoque #2735

Objetivos:

1. Deixar o wizard mais genérico, movendo algumas funções para o fiscal e removendo da nf-e, permitindo implementação da importação de outro documentos (CT-e, NFS-E e etc)
2. Criação ou sincronização da movimentação de estoque;
3. Criação ou sincronização do pedido de compra.
4. Remover o módulo desnecessário: l10n_br_nfe_stock

Este PR provavelmente vai ser quebrado em PRs menores ou alguns commits serão unidos.

[mileo]

Caso de Uso:

1. Caso o usuário esteja no módulo Financeiro/Contábil, será criada uma fatura e o documento fiscal.
2. Caso o usuário esteja no módulo de Estoque, será criado somente o stock.picking e o documento fiscal, a fatura deverá ser criada posteriormente através de uma ação do usuário.
3. Caso o usuário esteja no módulo de Compras, será criada uma compra provisória, ao ser confirmada, as quantidades do picking poderão ser sincronizadas automaticamente.
4. Caso o móduo de DFE esteja instalado e configurado para tal, uma compra provisório poderá ser criada automaticamente.
5. Caso o usuário esteja no módulo fiscal, somente um documento fiscal será criado, ele pode solicitar a criação dos outros documentos após a importação caso ele queira.

@rvalyi @marcelsavegnago @antoniospneto

[rvalyi]

@mileo so basically what you are adding atop of the PR's I made to import the NFe is a new module called l10n_br_nfe_stock and some more code in l10n_br_purchase to sync stock.pickings or purchase.orders with the imported account.move.

The problem is 90% of such code is not specific to the Brazilian localization! In fact everybody in the world importing invoices into Odoo will have interest in relating them with purchase.order and or stock.picking. And with the increase of Odoo EDI capabilities both in the EE and in the OCA it means this is becoming a hot topic in the OCA.
What will happen if we increase the l10n-brazil codebase to deal with that is we will have an even more complex code to migrate and maintain while the rest of the OCA will do something much cleaner with a wider ecosystem in OCA/edi and we will have yet another pile of shitty code to maintain here for nothing.

Sorry but in 10 years of you contributing in the repo, the repo has been full of KMEE modules that YOU USUALLY DON"T MAINTAIN. Just in the fiscal module your last addition of the broken DFe stuff in 2019 led to 500 lines of pure dead code in l10n_br_fiscal for 4 years and the list of un maintained KMEE code in the repo is just huge (I can write it down if you force me too). What about your "financial in fiscal" great idea? What about your proposals to reinvent the deductible Odoo taxes, your proposal to reinvent the IFRS for stock, your proposal to shortcut the account module as you did in your great fork? And I'm pretty sure you think your code in github.com/erpbrasil is OK, well that's a big problem because we are several to think it's far below OCA standards. It sucks because usually it's us who maintain that code, fix the lint issues, fix the broken tests that break the tests in the whole repo (your website* module remember?). So adding code without maintaining it sucks and I have to make it clear. You had more than 10 years to prove you could add great code in the repo and you did pretty much the opposite all these years sadly. You'll probably again tell it's my own opinion and you do great stuff. But if you did great stuff and that was just me persecuting you, in 12 years you would have managed to put more than one single module in the other OCA repo don't you think?

So basically I quite opposed you add code to do these things in the existing modules or even as new modules.

I would advise you to try putting new modules into https://github.com/OCA/edi instead because this is where this logic belongs. And then eventually we could have a couple of overrides in the project to take xPed or nItem stuff into account specifically.
You could start around my colleague @alexis-via proposal here OCA/edi#803

cc @renatonlima @marcelsavegnago @antoniorubiopesol @felipemotter @mbcosta @douglascstd

[mileo]

@mileo so basically what you are adding atop of the PR's I made to import the NFe is a new module called l10n_br_nfe_stock and some more code in l10n_br_purchase to sync stock.pickings or purchase.orders with the imported account.move.

The problem is 90% of such code is not specific to the Brazilian localization! In fact everybody in the world importing invoices into Odoo will have interest in relating them with purchase.order and or stock.picking. And with the increase of Odoo EDI capabilities both in the EE and in the OCA it means this is becoming a hot topic in the OCA. What will happen if we increase the l10n-brazil codebase to deal with that is we will have an even more complex code to migrate and maintain while the rest of the OCA will do something much cleaner with a wider ecosystem in OCA/edi and we will have yet another pile of shitty code to maintain here for nothing.

Sorry but in 10 years of you contributing in the repo, the repo has been full of KMEE modules that YOU USUALLY DON"T MAINTAIN. Just in the fiscal module your last addition of the broken DFe stuff in 2020 led to 500 lines of pure dead code in l10n_br_fiscal and the list of un maintained KMEE code in the repo is just huge (I can write it down if you force me too). And I'm pretty sure you think your code in github.com/erpbrasil is OK, well that's a big problem because we are several to think it's far below OCA standards. It sucks because usually it's us who maintain that code, fix the lint issues, fix the broken tests that brake the tests in the whole repo (your website* module remember?). So adding code without maintaining it sucks and I have to make it clear. You had more than 10 years to prove you could add great code in the repo and you did pretty much the opposite all these years sadly. You'll probably again tell it's my own opinion and you do great stuff. But if you did great stuff and that was just me persecuting you, in 12 years you would have managed to put more than one single module in the other OCA repo don't you think?

So basically I quite opposed you add code to do these things in the existing modules or even as new modules.

I would advise you to try putting new modules into https://github.com/OCA/edi instead because this is where this logic belongs. And then eventually we could have a couple of overrides in the project to take xPed or nItem stuff into account specifically. You could start around my colleague @alexis-via proposal here OCA/edi#803

cc @renatonlima @marcelsavegnago @antoniorubiopesol @felipemotter @mbcosta @douglascstd

@rvalyi eu estou removendo o módulo l10n_br_nfe_stock que foi feito pelo @hirokibastos no PR (#2735) e limpando o código, esse é primeiro passo. Também estou aproveitando a arquitetura o que você implementou na nos dois PRs citados (#2761 e #2781)

Você chegou a ler o que eu escrevi acima? Com certeza aberto a sugestões na implementação e vou dar uma olhada no código do EDI.

Mas também considerando a integração com o estoque e compras.

[mileo]

@rvalyi veja: 6fcbb4b

só não removi de uma vez para não quebrar tudo.

[OCA-git-bot]

Hi @renatonlima, @rvalyi, @antoniospneto, @mbcosta, @felipemotter,
some modules you are maintaining are being modified, check this out!