[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

[DiegoParadeda]

Subdivisão em PRs:

stock_price:

• [14.0][Crédito de impostos]: Crédito de impostos pt1 - adiciona stock price e impostos creditáveis por Tax/CST #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:

1. 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).

2. 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

[OCA-git-bot]

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

[ygcarvalh]

Em termos de lógica e código, lgtm!

[ygcarvalh]

@DiegoParadeda você pode fazer um squash dos commits depois que o PR for revisado?

[rvalyi]

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.

[DiegoParadeda]

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

[mileo]

LGTM

[OCA-git-bot]

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). 🤖

[mileo]

@DiegoParadeda pode adicionar dados de demonstração e uns testes mais usuais?

[mileo]

LTGM

[renatonlima]

@mileo eu vou revisar esse PR e tbm o do simples nacional do @antoniospneto

[rvalyi]

@renatonlima consegue dar uma posição sobre esse PR?

[mileo]

@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.

[DiegoParadeda]

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).

[renatonlima]

Olá @DiegoParadeda,

Primeiramente obrigado pela contribuição com o projeto e segundo desculpa pela demora em revisar o seu PR, mas finalmente consegui fazer a revisão, o primeiro ponto importante que iria sugerir era dividir esse PR em dois, o primeiro para corrigir o valor do preço unitário na stock.move para que o calculo do custo médio fique correto e o segundo PR para corrigir os lançamentos contábeis no caso das entradas de compras e valorização do estoque.

Agora comentando sobre a implementação do PR:

Eu não acho uma boa ideia implementar o campo stock_price_br no mixim do documento fiscal, porque no caso das saídas como em um pedido de venda ou em uma ordem de entrega por exemplo, esse campo seria calculado a partir do preço unit da saída, o que esta errado, porque no caso das saídas o stock_price_br é o preço de custo do cadastro do produto (que foi calculado na entrada do produto), então eu diria que não faz muito sentido esse campo estar no mixim do fiscal.document.line

O preço unitário de entrada para o calculo do custo médio basicamente é:

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]

Esse é o calculo básico, mas claro que existe outros fatores que vai depender o perfil fiscal do emitente e destinatário (Se a empresa é do simples nacional ou regime normal), se a operação é de material para uso e consumo, ou se o campo ind_final (consumidor final está definido no documento fiscal), se o destinatário é indústria ou equiparado a industria, o CFOP e a CST de cada imposto, 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.

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.

Sobre os lançamentos contábeis, um problema que existe hoje tanto na entrada quanto na saída são as contabilizações dos valores de frete, seguro e outros custos que estão incluidos nas contas de receitas nas saídas e nas contas de despesas / custos nas entradas vai ser importante corrigir esse problema para ter os lançamentos contábeis corretos.

Talvez algo que seja necessário ser configurado na linha da operação fiscal ou no CFOP são as contas contábeis de receita/despesa/custo e dos impostos se tem alguma conta redutora como nas receitas (ICMS sobre vendas) e etc...

[renatonlima]

@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.

[DiegoParadeda]

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.

[mileo]

@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.