[14.0] l10n_br_account, l10n_br_fiscal: Possibilidade de informar os valores dos impostos manualmente.

[antoniospneto]

A proposta desta PR é adicionar a possibilidade do usuário informar a base ou valor manualmente para qualquer imposto.

é uma continuação da PR #2550

O diff tá um pouco grande mas é porque mexeu bastante no XML da visão que tava com a formatação zuada.

• Incluir testes
• Adicionar grupo de permissão para a edição manual.

[OCA-git-bot]

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

[mileo]

@antoniospneto da uma olhada nesse conceito que pode te ajudar:

#1412

[douglascstd]

Perfeito, isso resolveria o issue: #2072
Só adicionaria um grupo de permissão, e separar esse grupo em:

• Edição Fiscal Manual Faturas de Vendas
• Edição Fiscal manual Fatura de Compra

Assim é possível distinguir exatamente quem vai ter esse tipo de autorização :-)

[antoniospneto]

Perfeito, isso resolveria o issue: #2072 Só adicionaria um grupo de permissão, e separar esse grupo em:

• Edição Fiscal Manual Faturas de Vendas
• Edição Fiscal manual Fatura de Compra

Assim é possível distinguir exatamente quem vai ter esse tipo de autorização :-)

Boa @douglascstd vamos adicionar os grupos de permissão, já estava no plano a gente por.

[antoniospneto]

@antoniospneto da uma olhada nesse conceito que pode te ajudar:

#1412

Fala @mileo sim eu estudei a proposta do 1412 antes, mas eu não achei muito interessante o conceito dela, por isso decidimos propor uma solução alternativa, acho que a forma que fizemos nessa PR a experiência para o usuário final fica melhor, pois você tem o controle individual em cada campo, se você quiser por a base manual em apenas um campo por exemplo você preenche o campo manual deste imposto e só esse será assumido o valor manual, todo o resto será calculado automaticamente. Ter que ficar fazendo configurações na operação fiscal para decidir se é manual , automático , ou só uma parte manual também não achamos interessante, não parece ser pratico. A pr 1412 também está muito desatualizada, com código conflitando e pelos comentários parece que tem problema não resolvidos, aí tbm não consegui testar na prática..

[rvalyi]

@antoniospneto @felipemotter @renatonlima @marcelsavegnago vale a pena ver que a Odoo SA ta fez um patch assim na v16 (não verifiquei esse comportamento na 14):
odoo/odoo#127154

Ou seja, o Odoo espera que ao digitar ou importar uma nota de entrada o valor no account.move.line possa ser alterado. Eu imagino que ainda assim a gente pode querer alterar o alíquota ou a base de uma taxa, mas enfim é interessante ver a forma como eles esperam lidar com essa questão lá fora.

[douglascstd]

[FUNCIONAL REVIEW] APPROVED

Testes realizados:
1.Inserido valores de base nos campos manuais
Com isso é assumido o valor inserido como o valor base e o Odoo calcula o imposto usando a nova base

2. Inserido o valor do imposto nos campos manuais
   É assumido o valor do imposto, mantendo o valor da base como original

Os lançamentos de diários assumem os valores manuais quando inseridos

[marcelsavegnago]

LGTM

[antoniospneto]

@douglascstd @marcelsavegnago obrigado pela revisão, aqui a gente usa essa PR em produção há alguns meses.

Porém temos o impasse que essa PR adiciona quase 40 campos novos nas linhas do documento fiscal, na fatura, no pedido..
Podem haver soluções melhores para esse problema, mas eu no momento não tenho nada melhor a propor.

Eu andei estudando um pouco o que o @rvalyi comentou aqui #2559 (comment) eu compreendi um pocuo o uso do context manager que tá sendo feito ali, mas ainda não consegui pensar em como posso fazer uma solução alternativa a essa PR aproveitando esse conceito. Teria que ver se realmente se aplica nesse caso..

[rvalyi]

Pessoal, eu vou voltar com argumentos aqui, mas o trabalho que eu fiz para importar as NFe's e desabilitando o tax engine neste caso me convenceu que a abordagem desta PR não esta legal. Pois é perfeitamente possivel usar os campos que ja tempos e apenas ter alguma considção para poder edita-los e desativar o tax engine ou parte dele neste caso. Mais tarde eu falo mais. Mas de imediato vou tb alterar meu PR para impedir o tax engine se for line.document_id.imported_document e não pelo context, pois mesmo se vc editar algo numa linha do que vc importou não deveria recalcular os valores.

[antoniospneto]

Pessoal, eu vou voltar com argumentos aqui, mas o trabalho que eu fiz para importar as NFe's e desabilitando o tax engine neste caso me convenceu que a abordagem desta PR não esta legal. Pois é perfeitamente possivel usar os campos que ja tempos e apenas ter alguma considção para poder edita-los e desativar o tax engine ou parte dele neste caso. Mais tarde eu falo mais. Mas de imediato vou tb alterar meu PR para impedir o tax engine se for line.document_id.imported_document e não pelo context, pois mesmo se vc editar algo numa linha do que vc importou não deveria recalcular os valores.

@rvalyi

Uma coisa interessante sobre a abordagem nesta PR é que o usuário pode escolher quais impostos lidar manualmente, sem ter que desativar o cálculo automático para todo o resto. Isso é algo que a PR #1412 não oferecia

[rvalyi]

Olá @antoniospneto então basicamente com meu PR de importação da NFe a gente vê que é possível lançar os impostos manualmente e que o tax engine use esses valores manuais nós lançamentos sem re-calcular. O PR da KMEE botava a condição na operação fiscal. Eu não sei se seria interessante (@renatonlima alguma ideia?) mas a gente TB poderia imaginar um flag na linha tipo "manual_tax" e aí qdo vc marcar esse flag na interface por examplo vc poderia editar os campos que vc quiser e depois o tax engin usaria esses valores manuais como se for uma linha de documento importado. Não sei se seria vantagem ter um flag por tipo de imposto, mas ainda seria possível. O que vc acha @antoniospneto

Nota: na importação da NFe eu acabei não usando o PR da KMEE pois não era interessante ter a condição no context (tem que ser persistente caso o usuário editar algo na nota que importou depois) e nem tinha que ser pela operação fiscal. Tb tive que adaptar bastante vara funcionar na v14.

[marcelsavegnago]

@antoniospneto consegue fazer um rebase ai por favor ?

[rvalyi]

@antoniospneto consegue fazer um rebase ai por favor ?

Eh mas eu aconselho estudar um pouco a abordagem aqui em vez disso #2781 Pois neste outro PR, eu importo os impostos assim como eles estão no XML (sem re-fazer os calculos) e acho que é um pouco a ideia. So que faço isso sem ter que re-definir monte de campos. Enfim eu acho que é algo para pensar melhor.

[marcelsavegnago]

@antoniospneto consegue fazer um rebase ai por favor ?

Eh mas eu aconselho estudar um pouco a abordagem aqui em vez disso #2781 Pois neste outro PR, eu importo os impostos assim como eles estão no XML (sem re-fazer os calculos) e acho que é um pouco a ideia. So que faço isso sem ter que re-definir monte de campos. Enfim eu acho que é algo para pensar melhor.

Vou olhar sim.. vlwww.. @antoniospneto de qq forma se conseguir fazer o rebase eu agradeço.. tenho um caso que estamos utilizando esta PR e vamos ter que manter por enquanto :D

[antoniospneto]

Eh mas eu aconselho estudar um pouco a abordagem aqui em vez disso #2781 Pois neste outro PR, eu importo os impostos assim como eles estão no XML (sem re-fazer os calculos) e acho que é um pouco a ideia. So que faço isso sem ter que re-definir monte de campos. Enfim eu acho que é algo para pensar melhor.

@rvalyi, percebo que no PR #2781 o processo é simplificado pelo fato de não requerer cálculos adicionais para os impostos, já que todos são extraídos diretamente do XML, correto?

No entanto, na proposta atual, oferecemos aos usuários a flexibilidade de definir manualmente o valor de determinados impostos. Por exemplo, um usuário pode optar por inserir manualmente apenas a base de cálculo do ICMS, enquanto para os demais impostos, o sistema continuaria a realizar os cálculos automaticamente.

[rvalyi]

Eh mas eu aconselho estudar um pouco a abordagem aqui em vez disso #2781 Pois neste outro PR, eu importo os impostos assim como eles estão no XML (sem re-fazer os calculos) e acho que é um pouco a ideia. So que faço isso sem ter que re-definir monte de campos. Enfim eu acho que é algo para pensar melhor.

@rvalyi, percebo que no PR #2781 o processo é simplificado pelo fato de não requerer cálculos adicionais para os impostos, já que todos são extraídos diretamente do XML, correto?

No entanto, na proposta atual, oferecemos aos usuários a flexibilidade de definir manualmente o valor de determinados impostos. Por exemplo, um usuário pode optar por inserir manualmente apenas a base de cálculo do ICMS, enquanto para os demais impostos, o sistema continuaria a realizar os cálculos automaticamente.

OK entendo. Porem eu diria que seria melhor num modulo adicional. Pois raramente tem essa necessidade e o modulo l10n_br_fiscal já ta com 30k linhas de Python e XML, não fica nada legal enfiar mais uns 700 linhas nele para algo pouco usado. Eh exactamente assim de 500 em 500 linhas que engordou até 30k linhas. Acabou de entrar mais umas 500 linhas para FCP ST uns 2 dias atras (e ai isso a gente não podia muito jogar para outro modulo) então isso a gente tem que ter disciplina senão a gente sai do trilho.

Outra coisa: vale a pena se questionar se não seria melhor uma account.fiscal.position ao nivel do account.move determinar se tem que ser manual ou não. A gente vê que no Odoo Enterprise eles usam o account,fiscal.position para determinar se é manual ou se vai ser pelo Avalara e isso até em outros paises do que o Brasil. Sera se a gente não pode seguir essa logica?

[antoniospneto]

@rvalyi

Utilizar o account.fiscal.position tbm não é que buscamos alcancar aqui, não ficaria flexivel como é proposto aqui na PR.
O usuario decide enquanto tá digitando a fatura se quer informar o imposto manual ou não.

Mas vamos estudar para propor uma nova PR, penso que por em um módulo adicional pode ser a solução que agrade a todos.

[marcelsavegnago]

@rvalyi

Utilizar o account.fiscal.position tbm não é que buscamos alcancar aqui, não ficaria flexivel como é proposto aqui na PR. O usuario decide enquanto tá digitando a fatura se quer informar o imposto manual ou não.

Mas vamos estudar para propor uma nova PR, penso que por em um módulo adicional pode ser a solução que agrade a todos.

Temos uns 3 casos com esta necessidade de alteração da base de calculo..

[rvalyi]

@rvalyi
Utilizar o account.fiscal.position tbm não é que buscamos alcancar aqui, não ficaria flexivel como é proposto aqui na PR. O usuario decide enquanto tá digitando a fatura se quer informar o imposto manual ou não.
Mas vamos estudar para propor uma nova PR, penso que por em um módulo adicional pode ser a solução que agrade a todos.

Temos uns 3 casos com esta necessidade de alteração da base de calculo..

Eu realmente acredito que pode ter o caso. Porem olha so em 10 anos a gente ficou apenas com projetos onde não precisava. Outro ponto é que empresas do Simples não precisam. Ai olha estamos até tentando passar a tesoura nos mais de 20k linhas que tem no l10n_br_fiscal, coisa que não se vê na OCA de jeito nehnum #3010
A tendencia seria mais a gente ver o que teria que no l10n_br_fiscal que empresas do simples não precisam de jeito nenhum e que daria para jogar em modulos adicionais e se tiver como lidar com os testes do regime normal para continuar com impacto minimo...

Outro ponto: vejam a complexidade que é de migrar o l10n_br_account para a v16: 78b667e (e não foi mais simples para migrar o modulo account_global_discount por examplo). Com esse tipo de mudança so deixariam esse meu trabalho de migração mais impossível ainda.... Ou seja mais lento...

Realmente o sucesso da OCA se deve muito no fato de ser extremamente modular: cada modulo é pequeno, relativamente simples de entender, de migrar. Se não gostar do modulo não instala etc... Não é porque tivemos contribuidores que nunca entenderam isso que temos que continuar desse jeito né...

Mas com essa ressalva, a funcionalidade esta muito bem vindo isso sim.

[antoniospneto]

@rvalyi, mas eu acho que dá pra seguir com um logica parecida com o que vc propos em #2781 tbm, depois vou ter que estudar melhor.

Mas ai teria que ter algo que o usuário pudesse deixar o sistema fazer o calculo automatico de todos os impostos, seriá bom um botão "calcular impostos" ai depois o usuário clica em algo para desabilitar o "calculo automatico dos impostos" altera/sobreescreve manualmente o imposto que quer e em seguida confirma a fatura.

não fica tão flexivel quanto é hoje com a proposta desta PR, mas resolve o problema tbm.

[antoniospneto]

@rvalyi esqueci de comentar, mas sim, eu realmente entendo o desafio e esforço gigantesco que são necessario para a migração dos módulos e isso normalmente cai pra quem está mantendo o projeto, e isso realmente é foda, agora a engenere tá focada em outros assuntos, mas assim que possivel a gente retorna nisso e propoem de uma forma diferente

[rvalyi]

@rvalyi esqueci de comentar, mas sim, eu realmente entendo o desafio e esforço gigantesco que são necessario para a migração dos módulos e isso normalmente cai pra quem está mantendo o projeto, e isso realmente é foda, agora a engenere tá focada em outros assuntos, mas assim que possivel a gente retorna nisso e propoem de uma forma diferente

Sem problema, sei que nos nos entendemos e a Engenere sempre somou no projeto desde o inicio. No caso, se precisar de uns hook ou outro para suportar modulo extra a gente consegue sim. Eh que realmente a parte do engine de taxa no account foi foda migrar (isso ja acertei na real) então ter que lidar com casos que tem que mudar porque é manual e que na v14 era onchange e que na v16 fica tudo super interdependente com computes ai é punk.

[antoniospneto]

Pessoal, to fechando essa PR, não prentendemos manter dessa forma.