search

OCA / l10n-brazil

Localização brasileira oficial do Odoo.
https://odoo-community.org/psc-teams/brazil-66
GNU Affero General Public License v3.0
235 stars 244 forks source link

[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 #3145

Closed mbcosta closed 2 weeks ago

mbcosta commented 2 months ago

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

mbcosta commented 2 months 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

mileo commented 2 months ago

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

mbcosta commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

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

mbcosta commented 2 months ago

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.

mbcosta commented 2 months ago

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

mbcosta commented 2 months ago

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

mbcosta commented 2 weeks ago

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

rvalyi commented 2 weeks ago

/ocabot merge nobump

OCA-git-bot commented 2 weeks ago

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 commented 2 weeks ago

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