[16.0][MIG] l10n_br_sale_stock

[rvalyi]

same as #3532 but including #2955 and rebased on 16.0 now that #3558 is merged

cc @antoniospneto @mbcosta @renatonlima @marcelsavegnago

[mbcosta]

@rvalyi e quem estiver acompanhando, as atualizações feitas:

• Removi o script de migração da extração no commit da migração v15

• Nos testes

  • a partir da v16 é possível configurar o sale_invoicing_policy no setupclass
  • campo display_type tem mais opções no account.move.line do que no sale.order.line
  • campo anlytic_precision é preenchido abrindo a linha no Form, por isso parece ser algo do teste, na tela não acontece
  • em alguns casos ao Confirmar uma Fatura de Pagamentos Antecipados/Down Paymens o programa acaba reconciliando e movendo a Fatura como Paga e se houver uma tentativa de se pagar, como o teste fazia antes, o programa retorna erro de que "Não resta nada para Pagar"

File "/usr/local/lib/python3.10/site-packages/odoo/addons/account/wizard/account_payment_register.py", line 601, in default_get
raise UserError(_("You can't register a payment because there is nothing left to pay on the selected journal items."))
odoo.exceptions.UserError: You can't register a payment because there is nothing left to pay on the selected journal items.

Isso deve acontecer quando o método action_post do account.move https://github.com/OCA/OCB/blob/16.0/addons/account/models/account_move.py#L3860 chama o action_post do account.payment https://github.com/OCA/OCB/blob/16.0/addons/account/models/account_payment.py#L934 que chama o método _create_paired_internal_transfer_payment https://github.com/OCA/OCB/blob/16.0/addons/account/models/account_payment.py#L922

• O número de Linhas no Pedido de Vendas e na Fatura quando existem Linhas de Seção, Nota e Pagamentos Adiantados é igual agora na v16 porque a Linha de Separação de Pagamentos Adiantados/Down Payments foi incluída no Pedido de Vendas

• Commit MIG WIP, último commit, agora contém apenas a indicação para o Teste usar o PR de migração do sale_stock_picking_invoicing [16.0][MIG][sale_stock_picking_invoicing] account-invoicing#1857 e seria melhor fazer a Revisão do módulo para que depois do merge seja possível remover esse commit, e mudar o status do PR de Rascunho/Draft para Pronto para a Revisão/Ready to Review

• Fiz um commit separado para facilitar na Revisão pelo diff mas pode ser um amend ao Commit de migração

• Deveríamos considerar após o Merge do PR de extração [14.0][REF] l10n_br_sale_stock: Extraction referent the creation of the module sale_stock_picking_invoicing #2955 refazer o PR de Migração para V15, fazer o merge, e em seguida refazer esse PR? Não parece ser complexo e pode ser feito se acharem melhor

[rvalyi]

/ocabot migration l10n_br_sale_stock

[rvalyi]

@mbcosta valeu pelos fixes e pelas explicações. sobre "refazer o PR de Migração para V15, fazer o merge, e em seguida refazer esse PR? " foi incluido o commit de migração usando cherry-pick então enquanto esse commit de migração para a v15 não sofrer alterações não tem motivo de "refazer o PR depois do merge". Daria exactemente na mesma...

A outra questão é que hoje temos uma certa pressa em migrar para a v16 e até para versões superiores, a gente não pode perder muito tempo com coisas da v15... Quando as migrações são triviais e acontecem no caminho beleza, mas se precisa mais trabalho eu diria que fica para a responsabilidade de quem quiser ter o modulo na v15...

Vale a pena dizer que como a v15 sera menos completa do que a v16 e deve mais ser visto como uma etapa e uma boia de salva vidas pros malucos que usaram as versões erradas até se tocar e nisso numa migração nem vale a pena incluir o l10n-brazil da 15.0 no addons-path... Futuramente com a entrada do Antonio no PSC e a maturidade maior dos modulos é possivel que a gente chega a "suportar" versões impares de forma mais assumida, mas eu diria que para a v15 meio que ja era... Agora caso for alterado o commit de migração para a v15, basta dar um rebase -i aqui e fazer o pick do novo commit de migração, eh o que eu tenho feito quando teve casos assim.

[mbcosta]

Valeu @rvalyi obrigado pelo retorno, concordo com "hoje temos uma certa pressa em migrar para a v16 e até para versões superiores" vou ver de fazer PRs de migração diretamente para v16.

O PR de migração do sale_stock_picking_invoicing para a v16 agora está com status Pronto para Revisão então para quem estiver acompanhando seria importante ajudar nessa Revisão para que depois do Merge ser possível tirar o último commit desse PR 1c68ba6 e mudar o status aqui para o Pronto para Revisão

[mbcosta]

Foi feito um force-push aqui para uma correção simples devido as alterações no #3592 o onchange_invoice_state acaba sendo chamado e no Teste do Caso Sem Operação Fiscal ou Fora do Brasil a Operação Fiscal Padrão acaba sendo informada por isso é necessário informar False no campo para não criar o Documento Fiscal aqui https://github.com/akretion/l10n-brazil/blob/16.0-mig-l10n_br_sale_stock-ak/l10n_br_sale_stock/tests/test_sale_stock.py#L425 a partir disso aproveitei para fazer um rebase e assim atualizar a branch, até para poder testar o PR de forma atualizada.

O erro nos testes não tem relação com o PR https://github.com/OCA/l10n-brazil/actions/runs/13021853644/job/36323995620?pr=3570#step:9:2891

2025-01-29 00:16:23,020 523 ERROR odoo odoo.addons.l10n_br_account_payment_order.tests.test_payment_order_change: ERROR: TestPaymentOrderChange.test_change_date_maturity_multiple
Traceback (most recent call last):
  File "/__w/l10n-brazil/l10n-brazil/l10n_br_account_payment_order/tests/test_payment_order_change.py", line 65, in test_change_date_maturity_multiple
    self._send_and_check_new_cnab_code(
  File "/__w/l10n-brazil/l10n-brazil/l10n_br_account_payment_order/tests/test_base_class.py", line 136, in _send_and_check_new_cnab_code
    self._send_new_cnab_code(aml_to_change, code_to_send, warning_error)
  File "/__w/l10n-brazil/l10n-brazil/l10n_br_account_payment_order/tests/test_base_class.py", line 126, in _send_new_cnab_code
    change_wizard.doit()
  File "/__w/l10n-brazil/l10n-brazil/l10n_br_account_payment_order/wizards/account_move_line_change.py", line 63, in doit
    self.account_move_line_ids._identify_cnab_change(
  File "/__w/l10n-brazil/l10n-brazil/l10n_br_account_payment_order/models/l10n_br_cnab_change_methods.py", line 33, in _identify_cnab_change
    cnab_code = record._get_cnab_date_maturity(new_date)
  File "/__w/l10n-brazil/l10n-brazil/l10n_br_account_payment_order/models/l10n_br_cnab_change_methods.py", line 206, in _get_cnab_date_maturity
    raise UserError(
odoo.exceptions.UserError: New Date Maturity 2025-02-28 is equal to actual Date Maturity 2025-02-28

Estou buscando resolver o problema no PR #3600

[mbcosta]

Testando o PR junto ao PR de migração do l10n_br_delivery acabou aparecendo um problema que é referente a sequencia de instalação dos módulos nos Testes tanto locais quanto aqui no CI, que é quando o programa "instala duas vezes o modulo" o que acontece no processo do CI, o programa por algum motivo ignora o noupdate=1 e tenta recarregar o arquivo o que gera erro e também ocorre no caso dos ir.property que associam o Diário Contábil/account.journal a Operação Fiscal :

https://github.com/OCA/l10n-brazil/actions/runs/13035384911/job/36364402057?pr=3571#step:9:3112

2025-01-29 16:14:51,252 701 ERROR odoo odoo.addons.l10n_br_sale_stock.tests.test_sale_stock: ERROR: TestSaleStock.test_down_payment
Traceback (most recent call last):
  File "/opt/odoo-venv/lib/python3.10/site-packages/odoo/addons/l10n_br_sale_stock/tests/test_sale_stock.py", line 499, in test_down_payment
    invoice = self.create_invoice_wizard(picking)
  File "/opt/odoo-venv/lib/python3.10/site-packages/odoo/addons/stock_picking_invoicing/tests/common.py", line 40, in create_invoice_wizard
    wizard.action_generate()
  File "/opt/odoo-venv/lib/python3.10/site-packages/odoo/addons/stock_picking_invoicing/wizards/stock_invoice_onshipping.py", line 221, in action_generate
    invoices = self._action_generate_invoices()
  File "/opt/odoo-venv/lib/python3.10/site-packages/odoo/addons/stock_picking_invoicing/wizards/stock_invoice_onshipping.py", line 510, in _action_generate_invoices
    invoice, invoice_values = self._build_invoice_values_from_pickings(
  File "/__w/l10n-brazil/l10n-brazil/l10n_br_purchase_stock/wizards/stock_invocing_onshipping.py", line 19, in _build_invoice_values_from_pickings
    invoice, values = super()._build_invoice_values_from_pickings(pickings)
  File "/opt/odoo-venv/lib/python3.10/site-packages/odoo/addons/l10n_br_sale_stock/wizards/stock_invoice_onshipping.py", line 16, in _build_invoice_values_from_pickings
    invoice, values = super()._build_invoice_values_from_pickings(pickings)
  File "/opt/odoo-venv/lib/python3.10/site-packages/odoo/addons/sale_stock_picking_invoicing/wizards/stock_invoice_onshipping.py", line 33, in _build_invoice_values_from_pickings
    invoice, values = super()._build_invoice_values_from_pickings(pickings)
  File "/opt/odoo-venv/lib/python3.10/site-packages/odoo/addons/l10n_br_stock_account/wizards/stock_invoice_onshipping.py", line 78, in _build_invoice_values_from_pickings
    invoice, values = super()._build_invoice_values_from_pickings(pickings)
  File "/opt/odoo-venv/lib/python3.10/site-packages/odoo/addons/stock_picking_invoicing/wizards/stock_invoice_onshipping.py", line 366, in _build_invoice_values_from_pickings
    journal = self._get_journal()
  File "/opt/odoo-venv/lib/python3.10/site-packages/odoo/addons/l10n_br_stock_account/wizards/stock_invoice_onshipping.py", line 60, in _get_journal
    raise UserError(
odoo.exceptions.UserError: Invalid Journal! There is not journal defined for this company: Sua Empresa in fiscal operation: Venda!

Esse erro já havia sido visto no issue #1197 e acredito que ao incluir um método para Informar ou Criar esses ir.property no PR #3607 especificamente o commit 2e00dea esse erro deve deixar de acontecer, porém ainda não é possível instalar diretamente o l10n_br_sale_stock e testar porque acontece outro erro mas agora referente a Faturas Desbalanceadas, mas isso ainda é um erro referente a sequencia de instalação dos módulos porque se for instalado o l10n_br_account e depois o l10n_br_sale_stock o erro não aparece, talvez seja possível resolver recalculando os Dados criados dentro do hook, é preciso analisar, bom uma parte do problema foi resolvida.

Com essas última alterações feitas aqui em conjunto com os PRs #3606 #3607 #3608 #3609 #3611 os erros nos Testes do l10n_br_delivery devem ser resolvidos deixando o PR Verde.

Aproveitei e fiz o rebase para atualizar a branch, por enquanto esse PR vai ter erros nos Testes porque depende do #3607

[rvalyi]

depois que o modulo sale_stock_picking_invoicing foi migrado para a 16.0 eu dei um force push aqui mas os testes estão falhando por causa de #3617

[rvalyi]

@mbcosta #renatonlima @antoniospneto @marcelsavegnago dei um rebase aqui para verificar que ficou verdinho depois dops ultimos merges. Porem eu acho que meus comentarios aqui #3606 (review) valem pro ultimo commit.

[mbcosta]

@rvalyi o PR vai ficar com erro devido o último commit 6bbc0b7 porque é onde estou passando a usar o Hooks e o método que criar os ir.porperty para assoaciar os Diários as Operações Fiscais não vai ser encontrado porque está em outro PR, o l10n_br_sale_stock não precisa disso para ficar Verde mas sem isso l10n_br_delivery não vai ficar Verde, é possível remover esse último commit para ver essa questão depois de aprovado o merge em outro PR especifico sobre isso se acreditarem ser melhor

[rvalyi]

@rvalyi o PR vai ficar com erro devido o último commit 6bbc0b7 porque é onde estou passando a usar o Hooks e o método que criar os ir.porperty para assoaciar os Diários as Operações Fiscais não vai ser encontrado porque está em outro PR, o l10n_br_sale_stock não precisa disso para ficar Verde mas sem isso l10n_br_delivery não vai ficar Verde, é possível remover esse último commit para ver essa questão depois de aprovado o merge em outro PR especifico sobre isso se acreditarem ser melhor

Eu tirei o ultimo commit, vamos ver como ficou. Realmente accredito que tem coisas que temos que fazer nos hooks, Mas idealmente seria o minimo possivel... Pode ir pensando numa forma...