[14.0][REF+IMP] l10n_br_purchase_stock: Renomeando o campo da Politica de Fatura e adaptando código para o caso Sem Operação Fiscal

[mbcosta]

Renomeando o campo da Politica de Fatura e adaptando código para o caso Sem Operação Fiscal,

A principal alteração do PR é renomear o campo 'purchase_create_invoice_policy' para 'purchase_invoicing_policy' como os modulos l10n_br_purchase_stock e o l10n_br_sale_stock são semelhantes e no PR de extração do l10n_br_sale_stock #2955 foi pedido essa alteração achei melhor seguir nesse mesmo caminho, outras alterações foram feitas aqui e se acharem necessário posso ver de extrair:

• Inclui o ind_final nos dados de demonstração para criar os Pedidos com o valor certo
• Removi o cabeçalho de Licença do arquivo init
• O método _prepare_br_fiscal_dict passou a ser chamado apenas quando o campo da Operação Fiscal estiver definido
• Desnecessário chamar os métodos _onchange_fiscal_operation_id, _onchange_fiscal_operation_line_id porque o _onchange_product_id_fiscal já chama
• Refatorei os testes para passar a usar o l10n_br_stock_account/tests/common.py reduzindo e evitando código duplicado e inclui o teste do caso Sem Operação Fiscal

cc @rvalyi @renatonlima @marcelsavegnago @mileo

[mbcosta]

O PR está dependendo do #3144 porque mesmo que um Pedido de Compra não tenha uma Operação Fiscal definida no momento de criação da Ordem de Seleção/stock.picking o método default preenche o campo o que ocasiona o erro https://github.com/OCA/l10n-brazil/actions/runs/9719228627/job/26828633098?pr=3145#step:8:1779

[mileo]

Não revisei ainda, mas aproveitando a modificação não seria melhor que a politica de faturamento seja por operação fiscal.

[mbcosta]

O erro dos testes parece não ter relação com as alterações do PR:

https://github.com/OCA/l10n-brazil/actions/runs/9752572945/job/26916313332?pr=3145

024-07-01 23:51:37,824 563 CRITICAL odoo odoo.modules.module: Couldn't load module l10n_br_nfe
2024-07-01 23:51:37,824 563 CRITICAL odoo odoo.modules.module: No module named 'nfelib.v4_00'

File "/__w/l10n-brazil/l10n-brazil/l10n_br_fiscal_dfe/tests/init.py", line 1, in
from . import test_dfe
File "/__w/l10n-brazil/l10n-brazil/l10n_br_fiscal_dfe/tests/test_dfe.py", line 9, in
from nfelib.v4_00 import retDistDFeInt
ModuleNotFoundError: No module named 'nfelib.v4_00'

[rvalyi]

valeu @mbcosta isso é porque eu tirei os antigos bindings generateDS na última release da nfelib (tem apenas do xsdata agora). Para a nfe nao usamos mais os antigos mas parece que ainda tinha treta com os bindings da DFe. Vou ver isso. Se vc for testar local, pode usar nfelib==2.0.7 por exemplo para nao puxar a última versão ou pode botar aqui no test-requirements.txt de forma temporária até eu arrumar o módulo de DFe.

[rvalyi]

O erro dos testes parece não ter relação com as alterações do PR:

https://github.com/OCA/l10n-brazil/actions/runs/9752572945/job/26916313332?pr=3145

024-07-01 23:51:37,824 563 CRITICAL odoo odoo.modules.module: Couldn't load module l10n_br_nfe 2024-07-01 23:51:37,824 563 CRITICAL odoo odoo.modules.module: No module named 'nfelib.v4_00'

File "/__w/l10n-brazil/l10n-brazil/l10n_br_fiscal_dfe/tests/init.py", line 1, in from . import test_dfe File "/__w/l10n-brazil/l10n-brazil/l10n_br_fiscal_dfe/tests/test_dfe.py", line 9, in from nfelib.v4_00 import retDistDFeInt ModuleNotFoundError: No module named 'nfelib.v4_00'

Eu fix esse PR para resolver esse teste de dfe: #3150

[mbcosta]

valeu @mileo

Bom podemos avaliar, pelos casos de uso que vi essa criação da Fatura pela Ordem de Seleção/Picking acaba acontecendo nas Empresas que tem setores como um Departamento, ou mesmo um funcionário, de Compras e outro de Entrada/Inspeção/Recebimento pode existir uma separação física e esses setores/funcionários não devem acessar ou mesmo ver o que é de cada setor, o Comprador não deve ver o Estoque e o Almoxarife não deve ver os Pedidos de Compra, até por questões de dupla validação para evitar erros/auditoria/anti-fraude tem também o caso de que como o Odoo por padrão define por Produto se a criação da Fatura deve ser por Recebimento/Entrega ou Pedido/Quantidades Solicitadas com esse modulo isso acaba definindo de forma geral para todos os Produtos que será por Entrega, quer dizer independente do que está definido no Produto, exceção Tipo Serviço, se a Politica for Picking só depois do Recebimento vai ser possível criar a Fatura, então hoje eu não conheço ou sei de um caso de uso onde isso seja por Operação Fiscal, teria? Até porque o padrão do Odoo permite ser mais especifico por permitir definir por Produto, se você tiver esse caso e puder detalhar podemos avaliar, mas acredito que se for feito precisaria coexistir com essa definição geral porque dependendo da empresa podem existir diversas Operações Fiscais e isso acabaria sendo repetitivo e passível de erro, por alguma não estar parametrizada, quando para determinadas Empresas isso já deve ser um padrão para todos os casos; como coloquei os casos de uso que conheço isso acaba sendo sempre geral ou a Empresa cria as Faturas a partir do Pedido de Compra ou da Ordem de Seleção.

Caso você confirme que existe essa necessidade é bom avaliar se isso também se aplica para Vendas, porque o caso do l10n_br_sale_stock que é semelhante está sendo extraído para o repo do account-invoicing #2955 então se for necessário algo nesse sentido teríamos que ver alguma forma de fazer isso funcionar porque no sale_stock_picking_invoicing não existe "Operação Fiscal".

Estou buscando deixar esse PR simples para permitir uma Revisão fácil e rápida aprovação, porque estou vendo de fazer o mesmo que está sendo feito no sale_stock_picking_invoicing no momento de criar a Fatura chamar os métodos _prepare do modulo purchase https://github.com/OCA/OCB/blob/14.0/addons/purchase/models/purchase.py#L547 https://github.com/OCA/OCB/blob/14.0/addons/purchase/models/purchase.py#L1171 para evitar a necessidade de "glue" módulos e tornar a Fatura criada pelo stock.picking mais semelhante possível com a criada pelo Pedido de Compra evitando divergências, mas ainda estou vendo quando as Linhas de Seção e notas são incluídas e achei melhor já subir esse PR para adiantar e ter menos código para revisar, no caso do l10n_br_sale_stock por exemplo eu estou considerando começar a extrair commits para ver se fica mais fácil e com isso mais rápida a revisão, então essa alteração que você comentou se for feita eu acredito que será melhor em outro PR.

[mbcosta]

valeu @rvalyi

Vi que você já havia comentado sobre essa atualização, esse PR aqui não é algo emergencial então acredito que pode esperar pela solução definitiva, pelo o que entendi do PR de correção #3150 agora está faltando atualizar o erprbrasil.edoc

File "/opt/odoo-venv/lib/python3.8/site-packages/erpbrasil/edoc/nfe.py", line 953, in inutilizacao
raiz = retInutNFe.infInutType(
NameError: name 'retInutNFe' is not defined

Seria a continuação desse PR erpbrasil/erpbrasil.edoc#52 ou erpbrasil/erpbrasil.edoc#58 ?

@mileo pelo PR acima parece que você e o pessoal da KMEE também estavam vendo sobre essa atualização do xsdata vocês conseguem ou já tem algo no sentido de atualizar essa lib? Já que isso vai passar a dar erro tanto aqui como em novas implementações

[mbcosta]

O erro dos testes foi contornado aqui #3154 , com isso o PR está Pronto para Revisão

OBS.: No merge usar o nobump porque o PR já está alterando a versão do modulo para 14.0.2.0.0 para chamar o script de migração

[mbcosta]

Com o merge dos PRs de extração esse PR foi simplificado e agora tem apenas:

• remoção do cabeçalho de licença no arquivo init quando tem apenas import
• Renomeando o campo purchase_create_invoice_policy para purchase_invoicing_policy, já que por ser semelhante ao l10n_sale_stock e no PR de extração do modulo para o sale_stock_picking_invoicing [14.0][REF] l10n_br_sale_stock: Extraction referent the creation of the module sale_stock_picking_invoicing #2955 isso acabou sendo pedido achei melhor fazer o mesmo

[rvalyi]

/ocabot merge nobump

[OCA-git-bot]

Hey, thanks for contributing! Proceeding to merge this for you.
Prepared branch 14.0-ocabot-merge-pr-3145-by-rvalyi-bump-nobump, awaiting test results.

[OCA-git-bot]

Congratulations, your PR was merged at 135f691. Thanks a lot for contributing to OCA. ❤️