l10n-brazil
l10n-brazil copied to clipboard
OCA
[14.0][Crédito de impostos]: l10n_br_fiscal, l10n_br_purchase_stock: Adiciona taxas não passíveis de crédito na linha da operação / compra
Subdivisão em PRs:
stock_price:
- #3158
lançamentos contábeis:
- WIP
Objetivo
Incluir no fluxo de compra e valorização de estoque o conceito de Impostos passíveis ou não de crédito
Problemas no fluxo atual
Considerando como exemplo dois casos de compra com linhas de operação:
- Compras para Comercialização
- Problema na valorização automática do estoque (o valor deveria ser líquido de imposto)
- Problema no valor do custo automático do produto (o valor também deveria ser líquido de imposto)
- Compras para Uso e Consumo
- Problema na conta de lançamento contábil dos impostos (o valor não é passível de crédito, logo não pode ir para contas de impostos a compensar)
Solução proposta
O PR inclui o campo computado stock_price que será usado para calcular o valor unitário do produto que irá para o estoque.
Outro campo foi adicionado na linha da operação para configurar quais impostos não são passíveis de crédito para o caso. Com base nesse registro o stock_price é computado subtraindo do valor unitário todos os impostos aplicados que não constam na lista de não passíveis de crédito. Em outras palavras, o campo stock_price vai armazenar o custo unitário líquido de impostos passíveis de crédito.
Duas ações são aplicadas a partir dessa lógica:
- Compras para Comercialização (valor líquido):
Nesse caso o valor do stock_price é utilizado no lançamento de diário automático (Inventory Valuation) e na atualização do custo do produto (AVCO, FIFO).
- Compras para Uso e Consumo (valor cheio):
Nesse caso o valor de estoque (AVCO, FIFO) e o valor utilizado no lançamento contábil (Inventory Valuation) ficam iguais, porém as contas dos lançamentos dos impostos (na fatura do fornecedor) são trocadas pela conta da linha do produto. Ou seja, os lançamentos que iriam para as contas de impostos a compensar são redirecionados para a mesma conta que o lançamento do estoque do produto (ex. Custo das Mercadorias Vendidas, como é configurado em alguns casos)
-//-
Utilização e teste
Uma breve demonstração do funcionamento considerando as duas linhas de operação já mencionadas e somente um imposto (ICMS).
Configuração das operações
Compras para Comercialização: default
Compras para Uso e Consumo: adicionar ICMS nas configurações da linha da operação, no campo criado Non-creditable Tax Groups.
Configuração do estoque
Ativar AVCO e valorização automática do estoque.
Compras
Comprar, receber produtos e criar fatura.
Lançamentos contábeis resultantes:
- foi utilizado apenas ICMS 18% para simplificar
Caso 1: Compras para Comercialização
Caso 2: Compras para Uso e Consumo
- sobre o lançamento contábil do imposto na conta: O lançamento não foi deletado, apenas redirecionado para a mesma conta de entrada de estoque
Hi @renatonlima, some modules you are maintaining are being modified, check this out!
@DiegoParadeda você pode fazer um squash dos commits depois que o PR for revisado?
já que estão tocando em lançamentos de compra, eu lembro a vcs que vamos ter que alterar os planos de conta para ativar o modo anglo saxon já que isso é importante para contabilizar CMV e remessas (a parte IAS2 do IFRS). Também impacta pois corrige a conta para contabilizar as compras que ficava errada senão. Eu acho que o modo anglo-saxon não tem impacto com esse problema dos impostos, mas é bom verificar se esse PR continua OK se for com o modo anglo-saxon no plano. Aqui eu sei que usamos uns patch para corrigir os custos de entrada, vamos ver o que o @renatonlima pensa do PR.
já que estão tocando em lançamentos de compra, eu lembro a vcs que vamos ter que alterar os planos de conta para ativar o modo anglo saxon já que isso é importante para contabilizar CMV e remessas (a parte IAS2 do IFRS). Também impacta pois corrige a conta para contabilizar as compras que ficava errada senão. Eu acho que o modo anglo-saxon não tem impacto com esse problema dos impostos, mas é bom verificar se esse PR continua OK se for com o modo anglo-saxon no plano. Aqui eu sei que usamos uns patch para corrigir os custos de entrada, vamos ver o que o @renatonlima pensa do PR.
@rvalyi, bem lembrado, segue o PR2667
This PR has the approved label and has been created more than 5 days ago. It should therefore be ready to merge by a maintainer (or a PSC member if the concerned addon has no declared maintainer). 🤖
This PR has the approved label and has been created more than 5 days ago. It should therefore be ready to merge by a maintainer (or a PSC member if the concerned addon has no declared maintainer). 🤖
Olá @mileo o Renato comentou comigo que viu alguns problemas neste PR, mas ainda não teve tempo de comentar aqui. Eu acho que ele consegue logo, mas nisso seria legal segurar o PR. Por outro lado, como vc deve ter visto a questão do SPED andou a grandes passos do meu lado e logo eu passo isso para vcs completar os mappings.
Olá @mileo o Renato comentou comigo que viu alguns problemas neste PR, mas ainda não teve tempo de comentar aqui. Eu acho que ele consegue logo, mas nisso seria legal segurar o PR. Por outro lado, como vc deve ter visto a questão do SPED andou a grandes passos do meu lado e logo eu passo isso para vcs completar os mappings.
Dei uma olhada no pr do SPED ficou bem legal, vou organizar o time para começar a fazer os mappings a partir do dia 26 final deste mês.
Duas opções para melhorar esse PR seria colocar o campo na tax definition e/ou na categoria de produtos.
Algum retorno sobre esse PR?
cc: @rvalyi @renatonlima @antoniospneto @marcelsavegnago
@mileo @DiegoParadeda uma questão importante vejam de avaliar a revisão que fiz porque eu posso não estar vendo os motivos que levarão vocês a fazer determinadas escolhas nessa implementação, então é bom ouvir vocês sobre isso, por exemplo uma questão que não coloquei no PR mas talvez seja bom avaliar essa valorização é algo dinâmico que depende do usuário/empresa definir quando ocorre( como está hoje no PR ) ou é algo que é sempre igual ? Exemplo todas as Empresas do Regime Tributário X os Impostos Y sempre deve ocorrer essa alteração na Valorização de Estoque, em muitos casos é melhor deixar configurável, como está, mas o modulo l10n_br_fiscal possui um tipo de "inteligencia/motor de impostos e dados Fiscais" então se é há algo que não depende da escolha da empresa talvez seja melhor deixar direto no código, mas acredito que vocês podem avaliar melhor a questão.
@DiegoParadeda veja se esse módulo pode ser uma dependência importante para esse PR: https://github.com/OCA/account-financial-tools/tree/14.0/stock_account_prepare_anglo_saxon_out_lines_hook
@mileo @DiegoParadeda uma questão importante vejam de avaliar a revisão que fiz porque eu posso não estar vendo os motivos que levarão vocês a fazer determinadas escolhas nessa implementação, então é bom ouvir vocês sobre isso, por exemplo uma questão que não coloquei no PR mas talvez seja bom avaliar essa valorização é algo dinâmico que depende do usuário/empresa definir quando ocorre( como está hoje no PR ) ou é algo que é sempre igual ? Exemplo todas as Empresas do Regime Tributário X os Impostos Y sempre deve ocorrer essa alteração na Valorização de Estoque, em muitos casos é melhor deixar configurável, como está, mas o modulo l10n_br_fiscal possui um tipo de "inteligencia/motor de impostos e dados Fiscais" então se é há algo que não depende da escolha da empresa talvez seja melhor deixar direto no código, mas acredito que vocês podem avaliar melhor a questão.
@mbcosta acredito que existem muitos casos em que a valorização/creditável é dinâmica. Por isso vinculamos a lógica com a linha da operação, assim uma mesma empresa pode utilizar estratégias diferentes dependendo do caso.
De qualquer forma vou continuar mapeando os possíveis casos pra ver se conseguimos chegar em uma configuração mais inerente ao motor de impostos. Por enquanto acredito que a configuração manual já atende
@mileo @DiegoParadeda uma questão importante vejam de avaliar a revisão que fiz porque eu posso não estar vendo os motivos que levarão vocês a fazer determinadas escolhas nessa implementação, então é bom ouvir vocês sobre isso, por exemplo uma questão que não coloquei no PR mas talvez seja bom avaliar essa valorização é algo dinâmico que depende do usuário/empresa definir quando ocorre( como está hoje no PR ) ou é algo que é sempre igual ? Exemplo todas as Empresas do Regime Tributário X os Impostos Y sempre deve ocorrer essa alteração na Valorização de Estoque, em muitos casos é melhor deixar configurável, como está, mas o modulo l10n_br_fiscal possui um tipo de "inteligencia/motor de impostos e dados Fiscais" então se é há algo que não depende da escolha da empresa talvez seja melhor deixar direto no código, mas acredito que vocês podem avaliar melhor a questão.
@mbcosta acredito que existem muitos casos em que a valorização/creditável é dinâmica. Por isso vinculamos a lógica com a linha da operação, assim uma mesma empresa pode utilizar estratégias diferentes dependendo do caso.
De qualquer forma vou continuar mapeando os possíveis casos pra ver se conseguimos chegar em uma configuração mais inerente ao motor de impostos. Por enquanto acredito que a configuração manual já atende
Uma das opções é colocar essa informação tax definition e usar o esquema de hierarquia para definir isso, como definimos o imposto do item, teremos a liberdade de fazer isso:
https://github.com/OCA/l10n-brazil/blob/14.0/l10n_br_fiscal/models/tax_definition.py
cc @ygcarvalh @luismalta (estavamos falando disso hj)
@mbcosta @rvalyi @renatonlima @marcelsavegnago @antoniospneto podem revisar por gentileza?
Um outro ponto interessante para por em discussão é o fato que o usuário pode acabar configurando um imposto dentro do pedido de compras e na fatura ajustar manualmente para uma outra aliquota, se essa divergencia acontecer a valorização irá ficar errada, pois é levado em consideração os impostos configurados no pedido e não na fatura, talvez por alguma validação para que os impostos da fatura sejam sempre os mesmo do pedido pode ser uma solução, mas de qualquer modo eu acho que essa PR já é bem interessante assim e essa questão da divergencia pode ser implementado depois.
@mileo eu vou revisar esse PR e tbm o do simples nacional do @antoniospneto
@renatonlima consegue dar uma posição sobre esse PR?
É tem essa também, as vezes é melhor não travar o PR e propor uma correção depois. Ou fazer um comentário rápido, nem que seja um audio no Telegram.
Pessoal, adicionei algumas modificações no PR, poderiam revisar novamente por favor? @rvalyi @mbcosta @renatonlima @mileo @antoniospneto @felipemotter
Movi o campo stock_price_br para o document line mixin
Apesar de já termos conversado algumas vezes sobre manter o campo e compute do campo no purchase_stock, no meu entendimento atual isso impediria a utilização do stock_price para casos de recebimento sem compra (faturamento pelo stock.picking sem compra)! Fiz essa modificação pensando no fluxo de importação de nota (importa nota -> recebe estoque a partir da nota -> valoração auto)
Adicionei valuation_via_stock_price e método de default
O campo valuation_via_stock_price pode ser desativado manualmente na transferência de estoque para "reverter" o efeito do stock_price no custeamento. O método de default foi feito pensando em facilitar heranças no futuro que facilitem o "reverter" (por exemplo, adicionar uma property na configuração geral ou na company para desativar o custeamento líquido de impostos).
@DiegoParadeda,
Só para complementar o meu comentário anterior, a definição das regras de valorização de estoque é regida pelo Comitê de Pronunciamento Técnico no Pronunciamento Técnico CPC 16 esse pronunciamento técnico corresponde ao IAS 2 IASB
No CPC 16 item 11 Custos de aquisição tem a definição:
O custo de aquisição dos estoques compreende o preço de compra, os impostos de importação e outros tributos (exceto os recuperáveis junto ao fisco), bem como os custos de transporte, seguro, manuseio e outros diretamente atribuíveis à aquisição de produtos acabados, materiais e serviços. Descontos comerciais, abatimentos e outros itens semelhantes devem ser deduzidos na determinação do custo de aquisição.
Obrigado pela revisão @renatonlima
Já estou me programando para fazer as correções e quebrar o PR em partes menores. Também tenho algumas dúvidas e observações sobre o seu comentário, você poderia dar uma olhada, por favor?
Sobre o modelo responsável pelo cálculo do stock_price:
Eu não acho uma boa ideia implementar o campo stock_price_br no mixim do documento fiscal
Pretendo criar um novo mixin para o campo e funções, mas ainda estou mapeando quais módulos vão precisar acessar essa informação, talvez essa parte fique por último. A ideia por enquanto é disponibilizar esse campo e suas funções na compra, transferência de recebimento e talvez na fatura.
Sobre as definições de impostos recuperáveis / não recuperáveis
eu entendo que esses fatores deveriam ser tratados no calculo dos impostos ao invés de ser configuráveis na linha da operação fiscal
Entendo que as informações necessárias para definir se um imposto é recuperável não têm origem única. Mas não consegui pensar em um lugar melhor do que a linha da operação para registrar essa "recuperabilidade".
Esse parágrafo é mais confuso, quebrei em duas sessões:
"Um outro ponto é: no Odoo o calculo do custo médio é feito quando é confirmado o picking de recebimento, o preço unitário no stock.move é usado para fazer o calculo do custo médio do produto e nesse ponto já deveria ser calculado o Preço Unitário de Entrada, hoje seria possível implementar na entrada do picking de recebimento esse calculo, que teoricamente funcionaria, mas na prática teria problemas, porque em alguns casos, como um pedido de compras que foi gerado por produtos MTO o mesmo produto pode ter mais de uma linha de pedido de compras e vai acontecer de ter uma NFe com uma linha agrupando os produtos iguais, mas no picking de recebimento vai ter mais de uma linha e isso vai ser um problema para calcular o Preço Unitário de Entrada porque seria necessário fazer o rateio de valores como o de frete por exemplo, e vai gerar problemas de arredondamento, nesse caso na minha opinião o melhor seria ser feito o calculo na linha do documento fiscal e depois copiar o valor do Preço Unitário de Entrada na linha do documento fiscal nas linhas de recebimento correspondente."
1
linha do documento fiscal e depois copiar o valor do Preço Unitário de Entrada na linha do documento fiscal nas linhas de recebimento correspondente.
De certa forma já estou fazendo isso não é? Calculando o stock price no fiscal document line (mixin) e usando o valor calculado como sendo o valor unitário do picking, que por sua vez é usado pra gerar o lançamento contábil de estoque.
2
o mesmo produto pode ter mais de uma linha de pedido de compras e vai acontecer de ter uma NFe com uma linha agrupando os produtos iguais, mas no picking de recebimento vai ter mais de uma linha e isso vai ser um problema para calcular o Preço Unitário de Entrada porque seria necessário fazer o rateio de valores como o de frete por exemplo, e vai gerar problemas de arredondamento
Testei o stock price com valores de frete separados por linha e não tive problema. Não consegui simular um caso em que o rateio dos custos adicionais possa gerar problemas de arredondamento.
Sobre a fórmula de valor de estoque:
Preço Unitário de Entrada = [Preço Unitário] - [Impostos Recuperáveis Incluídos no Preço Unitário] + [Impostos Não Recuperáveis Não Incluídos no Preço Unitário] + [Valor de Frete] + [Valor de Seguro] + [Valor de Outras Despesas]
No meu entendimento essa forma já está sendo respeitada, mas se encontrar algum caso em que não esteja vou tentar corrigir.
@DiegoParadeda o crédito ele é por circunstância e por taxa também, por exemplo:
https://www.lefisc.com.br/materias/2011/252011ir.htm
Então um dois bons locais para você colocar essa informação são a l10n_br_fiscal.cst e l10n_br_fiscal.tax
Depois pode ser necessário criar uma tabela de decisão para facilitar a configuração desses créditos.