[18.0][FIX] l10n_br_fiscal: fix tax_framework synchronization with partner

[EdnilsonMonteiro]

Correção das issues #4213 e #4328.

• [18.0] l10n_br_base_l10n_br_compat: Erro na view #4328 Alguns campos do addon nativo do odoo base_address_extended não estavam sendo tratados no res_company.py do módulo l10n_br_base.
• [17.0][18.0][BUG] l10n_br_fiscal: Erro no campo de imposto PIS/COFINS ao configurar uma empresa #4213 O domain de field's que faziam um filtro antes de mostrar os regimes disponíveis de acordo com a Estrutura Tributária selecionada gerava erros por causa do parent.tax_framework que não encontrava o verdadeiro campo na tabela res_partner. Foram criadas variáveis simples para computar no Python ao invés do XML qual vai ser a estrutura do domain para fazer o filtro. Assim foi possível obter acesso ao valor de tax_framework e poder fazer o filtro do domain corretamente no XML inserindo a variável com o domain pronto.

[OCA-git-bot]

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

[rvalyi]

@EdnilsonMonteiro vé que deu warnings nos tests e agora na 18.0 a CI não aceita warning nos logs... Deve ser fácil resolver (tem que fazer amend se resolver não novos commits). Eu não parei para analisar ainda mas o @CristianoMafraJunior fez uma outra proposta para resolver o problema com base_address_extended #4331 (não sei se estaria certo apenas tou mencionando).

[EdnilsonMonteiro]

Boa noite, @rvalyi. Corrigi os warnings, mas como as mudanças acabaram adicionando coisas que os testes não cobriam, creio que o codecov deu uma diferença.

[mbcosta]

Valeu @EdnilsonMonteiro obrigado por reportar o problema e buscar resolve-lo, por favor você pode verificar se a alteração proposta no PR

• [18.0][FIX] l10n_br_base: Método _fields_view_get agora é _get_view #4379

resolve o problema que você está buscando corrigir aqui, o problema pode estar relacionado ao uso de um método que passou a ser obsoleto a partir da v17.

[EdnilsonMonteiro]

@mbcosta Boa tarde!

Testei a alteração do PR #4379 e ela resolve o problema da issue #4328 de acordos com meus testes (relacionada ao base_address_extended e à mudança para _get_view).

Entretanto, a issue #4213 (o bug do domain em PIS/COFINS) é de natureza diferente. Ela ocorre devido à dificuldade do XML em resolver o parent.tax_framework em certas condições de visualização. A solução via _compute_tax_domains ataca esse ponto, movendo a lógica do domínio para o servidor (Python), o que garante que o filtro funcione independentemente da profundidade da view.

Portanto, creio que o PR #4379 corrigiu corretamente uma das issues, mas a outra ainda é precisa. Se necessário, altero o código deste PR para tratar apenas da issue #4213.

[mbcosta]

Valeu @EdnilsonMonteiro obrigado pelo retorno e explicação, realmente você está certo o problema do Domain persiste, o tax_framework é um campo compute portanto não existe na tabela, é possível forçar a gravação com um store=True, eu até testei mas não resolveu (talvez seja alguma mudança sobre como acessar um campo parent, não sei), então por enquanto parece que a sua proposta é a mais próxima da solução, acredito que você pode considerar em extrair partes desse PR em novos PRs:

• As alterações no l10n_br_base, referente ao _inverse_street2
• A correção no Domain do campo cnae_secondary_ids https://github.com/OCA/l10n-brazil/blob/18.0/l10n_br_fiscal/models/res_company.py#L134 , isso é uma Correção simples que deve ser Aprovada rapidamente

Com isso esse PR vai passar a ter apenas as alterações referentes a criação desses campos Domain.

Outro ponto o padrão dos Títulos dos PRs é similar com os commits (a diferença é que o commit não vai a versão) ,nesse caso onde está res_company, deveria estar o(s) nome(s) do(s) modulo(s), por exemplo:

[18.0][FIX] l10n_br_base, l10n_br_fiscal: fix tax_framework synchronization with partner

E caso você considere extrair a parte referente ao l10n_br_base vai ficar apenas:

[18.0][FIX] l10n_br_fiscal: fix tax_framework synchronization with partner

Porque você no PR criou campos para fazer o Domain ao invés de usar o método _search como você comentou no Issue #4213 ? Teve algum erro? Parece que usar o _search é a uma solução melhor, ou não?

[EdnilsonMonteiro]

Boa noite, @mbcosta! Eu optei por usar os campos domain ao invés do _search porque me pareceu a solução com melhor manutenibilidade e também eficiência do código. Se eu altero o _search, sempre que for buscar algum imposto do modelo este mesmo trecho de código irá ser executado novamente(gerando overhead). Adicionando somente um campos para fazer o domain eu limito estas buscas apenas para a tela de configurações fiscais da empresa.

Já limpei o PR, removi as alterações da l10n_br_base. O PR #4379 resolveu com sucesso o erro que estava ocorrendo, por isso acho desnecessário alteração nesse quesito.