[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

[mbcosta]

l10n_br_stock_account load demo data by hook

Alterações do PR:

• l10n_br_stock_account

Ocorre um problema semelhante ao do PR #3606 com o l10n_stock_account
ao instalar duas vezes o modulo, como o CI faz em alguns PRs, por exemplo o PR de migração do #3571 o noupdate=1 dos XML parece ser ignorado e acaba retornando um Warning

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

2025-01-29 16:09:51,456 701 WARNING odoo odoo.modules.loading: Module l10n_br_stock_account 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](https://github.com/OCA/l10n-brazil/actions/runs/13035384911/job/36364402057?pr=3571#step:9:712), 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_account/demo/stock_inventory_demo.xml:5, somewhere inside
<record id="stock_account_inventory_1" model="stock.quant">
        <field name="product_id" ref="product.product_product_12"/>
        <field name="inventory_quantity">100.0</field>
        <field name="location_id" model="stock.location" eval="obj().env.ref('stock.warehouse0').lot_stock_id.id"/>
    </record>

Mas nesse caso além do Warning também ocorre um erro

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

2025-01-29 16:09:52,720 701 ERROR odoo odoo.addons.l10n_br_stock_account.tests.test_invoicing_picking: ERROR: InvoicingPickingTest.test_fields_freight_insurance_other_costs
Traceback (most recent call last):
  File "/opt/odoo-venv/lib/python3.10/site-packages/odoo/addons/l10n_br_stock_account/tests/test_invoicing_picking.py", line 498, in test_fields_freight_insurance_other_costs
    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 "/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: Simples Remessa!

Para resolver o problema o que fiz foi criar um método que Cria ou Informa o ir.property para associar o Diário Contábil a Operação Fiscal algo que antes era feito via XML pelos arquivos https://github.com/OCA/l10n-brazil/blob/16.0/l10n_br_stock_account/demo/fiscal_operation_generic.xml https://github.com/OCA/l10n-brazil/blob/16.0/l10n_br_stock_account/demo/fiscal_operation_simple.xml com esse método foi possível apagar esses arquivos XML e se necessário por algum motivo, como nos testes desse módulo, chamar o método com uma linha e essa associação é feita.

Ao rodar o pre-commit algumas alterações foram incluidas, estão em um commit separado.

• l10n_br_fiscal

Inclui o método para criar os ir.property no l10n_br_fiscal para permitir usa-lo em outros módulos, devido aos erros no PR de migração do l10n_br_delivery vai ser necessário fazer o mesmo com os módulos l10n_br_sale, l10n_br_purchase, l10n_br_sale_stock dessa forma é possível evitar códigos duplicados, vou fazer as alterações em PRs separados para diminuir o DIFF e facilitar a Revisão e deixar esse PR de referencia com o método no l10n_br_fiscal.

cc @OCA/local-brazil-maintainers

[OCA-git-bot]

Hi @renatonlima,
some modules you are maintaining are being modified, check this out!

[rvalyi]

@mbcosta vamos olhar isso com calma. Apenas para te informar, estamos ciente que essa parte de dados de demo e de testes esta um pouco uma bagunça (aquelas contribuiçoẽs de dados de demo que o pessoal de sempre fez sem pensar muito e depois caga e anda né...). Ai eu iniciei esses 2 PRs para começar a melhorar isso na 16.0:

• [16.0][l10n_br_fiscal][IMP] l10n_br_fiscal: standardize data+demo load #3567
• [16.0][REF][l10n_br_base][l10n_br_fiscal][l10n_br_account] tests don't depend on demo #3563

cc @renatonlima @marcelsavegnago @antoniospneto

[mbcosta]

@rvalyi valeu, obrigado pelo retorno, eu vi os PRs mas peço para avaliarem os seguintes pontos:

• Essa alteração é bem simples, carregar os Dados de Demo via post_init_hook ( no caso do PR no l10n_br_stock apenas isso ) e um método para Informar ou Criar o ir.property para associar o Diário Contábil e a Operação Fiscal, os pontos que vejo que podem ser considerados na Revisão são:
  • avaliar se esse método deve estar no l10n_br_fiscal/tools.py ou l10n_br_fiscal/tests/tools.py
  • alguma forma de testar a criação do ir.property para manter a Cobertura dos Testes, essa parte do código é chamada no Initialize test db mas não no momento dos Testes, talvez alguma alteração na lógica

• Acredito que de certa forma esse PR ajuda na Separação dos Dados de Demonstração dos Testes porque com o método que cria esses ir.property para associar o Diário Contábil e a Operação Fiscal, já vai ser possível apagar os seguintes arquivos XMLs
  https://github.com/OCA/l10n-brazil/blob/16.0/l10n_br_stock_account/demo/fiscal_operation_generic.xml
  https://github.com/OCA/l10n-brazil/blob/16.0/l10n_br_stock_account/demo/fiscal_operation_simple.xml
  https://github.com/OCA/l10n-brazil/blob/16.0/l10n_br_sale/demo/fiscal_operation_generic.xml
  https://github.com/OCA/l10n-brazil/blob/16.0/l10n_br_sale/demo/fiscal_operation_simple.xml
  https://github.com/OCA/l10n-brazil/blob/16.0/l10n_br_purchase/demo/fiscal_operation_generic.xml
  https://github.com/OCA/l10n-brazil/blob/16.0/l10n_br_purchase/demo/fiscal_operation_simple.xml

É importante dizer que esses casos ir.property são os principais responsáveis por muitos dos erros que são vistos nessa combinação de Dados de Demonstração e Testes, usando um método isso fica dinâmico e podendo ser usado dentro dos Testes sem grandes dificuldades como estou fazendo nesse PR

E ao deixar de usar os Dados de Demonstração vai ser possível apenas alterar os XML IDs por valores criados pelos Testes e chamar o método inform_journal_in_fiscal_operation por exemplo

https://github.com/akretion/l10n-brazil/blob/16.0-REF-sale_load_demo_data_by_hook/l10n_br_sale/hooks.py

• Até onde entendi a ideia é separar os Dados Demonstração dos Testes mas não vamos apaga-los, certo? Porque eu testei esse carregamento via post_init_hook com l10n_br_base, simulando os mesmos comandos do CI e é possível ver que uma vez instalado pelo Initialize test db esses dados não serão carregados novamente, o que não acontece hoje

Isso funciona sem erros, mas ao evitar tanto que esse módulo ou outros acabem carregando os Dados de Demonstração duas vezes nós podemos salvar Tempo de Processamento do CI tornando o CI mais rápido e eficiente com uma mudança simples que não gera muito DIFF facilitando a Revisão e assim podendo integrar isso de forma rápida sendo um passo inicial nessa melhoria dos Testes.

• Esses PRs não afetam diretamente nada do que foi feito nos PRs de Separação do Testes, o que facilita um rebase sem erros, hoje se forem integrados/merge vão nos permitir tanto destravar a migração do l10n_br_delivery quanto outros módulos que venham a ter um comportamento semelhante no CI, como comentei por serem alterações simples facilitam a Revisão e se necessário alguma Correção ou Refatoração poderão ser feitas sem grandes dificuldades

Portanto na minha opinião hoje seria melhor considerar incluir esses PRs para que as Migrações e a Separações dos Testes dos Dados de Demonstração possam ser feitas de forma independente o que penso ser melhor nesse momento por não colocar as migrações desses módulos dependendo da separação dos testes, ou em outras palavras vai permitir ver essas duas questões em paralelo de forma independente.

Se acreditarem ser melhor para Revisão posso tanto ver de criar um PR único par alteração no l10n_br_fiscal 2e00dea ou mesmo criar um PR com todas as alterações desse PR e do #3608 #3609