[16.0][MIG] l10n_br_delivery

[rvalyi]

same as #3553 but using #3570 and rebased on fresh 16.0

cc @antoniospneto @mbcosta @renatonlima @marcelsavegnago

[rvalyi]

/ocabot migration l10n_br_delivery

[mbcosta]

Atualizando, a migração do módulo está dependendo dos PRs:

• [16.0][MIG] l10n_br_sale_stock #3570 e consequentemente do [16.0][MIG][sale_stock_picking_invoicing] account-invoicing#1857 aqui seria importante um retorno dos Desenvolvedores da Localização, os testes e as funcionalidades podem ser vistas instalando o l10n_br_sale_stock para ter certeza de que o sale_stock_picking_invoicing está funcionando de acordo com o que é esperado pela Localização

Para evitar os erros ao "instalar duas vezes o módulos", como ocorre aqui no CI, e para criar os ir.property que associam os Diários Contabéis da Empresa com as Operações Fiscais de forma dinâmica e evitar erros devido a sequencias de instalação dos módulos:

• [16.0][REF] l10n_br_stock: Carregando os Dados de Demonstração pelo post_init_hook  #3606
• [16.0][REF+IMP] l10n_br_stock_account, l10n_br_fiscal: Carregando os Dados de Demo via hook e incluído método para associar o Diário a OP Fiscal  #3607 nesse PR está sendo incluído o método que cria ou informa os ir.property por isso os PRs abaixo dependem desse PR
• [16.0][REF] l10n_br_purchase: Carregando os Dados de Demo pelo post_init_hook e criando os Property dos Diários nas OP Fiscal via método #3608
• [16.0][REF] l10n_br_sale: Carregando os Dados de Demo via post_init_hook e criando os Property dos Diários nas OP Fiscal via método #3609

Parece que devido a forma como o teste aqui é criado isso passou a dar erro no módulo l10n_br_fiscal_edi:

• [16.0][FIX] l10n_br_fiscal_edi: Evita erro por chamar o método back2draft duas vezes #3611

Para manter a compatibilidade com os Casos de Uso Fora do Brasil ou mesmo quando a Empresa é do Brasil mas por algum motivo decide criar um Pedido de Vendas Sem Operação Fiscal, isso pode ser visto rodando os testes do módulo delivery

$ odoo -d test -u delivery --workers 0 --stop-after-init --test-enable

• [16.0][FIX+IMP] l10n_br_sale: Casos Sem Operação Fiscal ou Fora do Brasil #3598
• [16.0][REF] l10n_br_stock_account: Não informar a Operação Fiscal Padrão quando a Empresa não é do Brasil #3599

Com esses PRs e usando os mesmo comandos do CI para instalar e testar esse PR no ambiente local os testes deixaram de retorna erros, portanto depois dos merges dos PRs acima acredito que o PR deve ficar verde e pronto para Revisão.

[rvalyi]

@mbcosta dei um rebase aqui e alterei o ultimo commit. Mas pelo jeito ta falhando no modulo l10n_br_purchase_stock provavelmente pelas questões do dados de demo/hook que vc comentou @mbcosta . Eu não analisei ainda...

cc @renatonlima @marcelsavegnago @antoniospneto

[mbcosta]

Essa Linha é realmente necessária? Não tive erros removendo, tem alguma justificativa? Alguém viu algum problema, qual?

[antoniospneto]

se os testes passarem, não vejo mal remover

[antoniospneto]

@rvalyi consegue dar um rebase?

Como a PR #3570 entrou já dá pra remover o commit do test-requeriments.

As falhas que estavam sendo acusado nos testes é por que os dados de demonstração do módulo l10n_br_stock falharam no carregamento devido ao erro a baixo:

2025-02-11 18:58:11,996 582 WARNING odoo odoo.modules.loading: Module l10n_br_stock demo data failed to install, installed without demo data 
Traceback (most recent call last):
  File "/opt/odoo/odoo/tools/convert.py", line 698, in _tag_root
    f(rec)
  File "/opt/odoo/odoo/tools/convert.py", line 599, in _tag_record
    record = model._load_records([data], self.mode == 'update')
  File "/opt/odoo/odoo/models.py", line 4412, in _load_records
    data['record']._load_records_write(data['values'])
  File "/opt/odoo/addons/stock/models/stock_quant.py", line 307, in _load_records_write
    return super(StockQuant, self.with_context(inventory_mode=True))._load_records_write(values)
  File "/opt/odoo/odoo/models.py", line 4343, in _load_records_write
    self.write(values)
  File "/opt/odoo/addons/stock/models/stock_quant.py", line 351, in write
    raise UserError(_("Quant's editing is restricted, you can't do this operation."))
odoo.exceptions.UserError: Quant's editing is restricted, you can't do this operation.

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/opt/odoo/odoo/modules/loading.py", line 90, in load_demo
    load_data(cr, idref, mode, kind='demo', package=package)
  File "/opt/odoo/odoo/modules/loading.py", line 72, in load_data
    tools.convert_file(cr, package.name, filename, idref, mode, noupdate, kind)
  File "/opt/odoo/odoo/tools/convert.py", line 763, in convert_file
    convert_xml_import(cr, module, fp, idref, mode, noupdate)
  File "/opt/odoo/odoo/tools/convert.py", line 829, in convert_xml_import
    obj.parse(doc.getroot())
  File "/opt/odoo/odoo/tools/convert.py", line 749, in parse
    self._tag_root(de)
  File "/opt/odoo/odoo/tools/convert.py", line 711, in _tag_root
    raise ParseError('while parsing %s:%s, somewhere inside\n%s' % (
odoo.tools.convert.ParseError: while parsing /opt/odoo-venv/lib/python3.10/site-packages/odoo/addons/l10n_br_stock/demo/stock_inventory_demo.xml:9, somewhere inside
<record id="stock_inventory_sn_1" model="stock.quant">
            <field name="product_id" ref="product.product_product_24"/>
            <field name="inventory_quantity">16.0</field>
            <field name="location_id" model="stock.location" eval="obj().env.ref('l10n_br_stock.wh_empresa_simples_nacional').lot_stock_id.id"/>
        </record>

Estranho é que nas outras PRs nem mesmo no merge do módulo l10n_br_stock deu essa falha..

Eu penso também que no futuro a gente pode tentar melhorar esse módulo para não criar tanta dependencia, talvez no odoo v18, por exemplo alguém que usa o módulo l10n_br_account_nfe, mas não usa o l10n_br_sale_stock poder adicionar a informação da transportadora na nota fiscal.

[rvalyi]

Opa vou dar rebase sim...

[rvalyi]

@mbcosta @antoniospneto @renatonlima @marcelsavegnago eu dei um rebase tirando a linha problematica que o @mbcosta sugeriu #3571 (comment) e inclui os 9 commits que o @mbcosta fez aqui para limpar o carregamento dos dados de demo no #3629 e ficou verde.

Nisso tou botando pronto para revisar, mesmo que seria interessante considerar a proposta do @antoniospneto #3644 antes do merge. A gente tem que balançar tb a pressa em migrar o modulo (sendo que ainda vem o l10n_br_delivery_nfe por cima ainda) e as possibilidades de melhorias que podem entrar depois...

[antoniospneto]

@rvalyi por mim tudo bem se der sequência do merge assim, a questão que levantei pode ser discutido mais pra frente.