Closed mbcosta closed 2 weeks ago
O PR está dependendo do https://github.com/OCA/l10n-brazil/pull/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
Não revisei ainda, mas aproveitando a modificação não seria melhor que a politica de faturamento seja por operação fiscal.
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
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.
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: https://github.com/OCA/l10n-brazil/pull/3150
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 https://github.com/OCA/l10n-brazil/pull/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.
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 https://github.com/OCA/l10n-brazil/pull/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 https://github.com/erpbrasil/erpbrasil.edoc/pull/52 ou https://github.com/erpbrasil/erpbrasil.edoc/pull/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
O erro dos testes foi contornado aqui https://github.com/OCA/l10n-brazil/pull/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
Com o merge dos PRs de extração esse PR foi simplificado e agora tem apenas:
/ocabot merge nobump
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.
Congratulations, your PR was merged at 135f691176e7d22dece3a942606d69ffd0ffe770. Thanks a lot for contributing to OCA. ❤️
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 https://github.com/OCA/l10n-brazil/pull/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:
cc @rvalyi @renatonlima @marcelsavegnago @mileo