Incluindo ICMS e ST no estoque na transferência entre centros
Bom dia amigos da Localização Brasil… Um cenário do mercado (principalmente com operação varejista) costuma dar um trabalho… É o seguinte:
– Preciso fazer uma transferência entre centros, registrando e contabilizando ICMS e ICMS-ST na saída da origem. No processo de entrada esses valores precisam ser contabilizados na conta de estoque (custo do material), incidindo diretamente sobre o PMM.
O movimento de entrada de um processo de transferência tradicional com STO não consegue fazer essa contabilização no custo do material. Já tentei e vi outras pessoas tentando usar os movimentos 861, 835 e alguns movimentos Z. Sempre o resultado é a contabilização em contas de imposto ou até mesmo a não contabilização dos valores de impostos. O standard do SAP não prevê a contabilização no custo mesmo. Isso é fato!
Algumas pessoas optam por informar a conta de estoque na OB40, chave VS2. Isso faz com que a conta de estoque seja contabilizada, mas o material não é valorizado com esse lançamento. A chave de lançamento no documento contábil é apenas 40, e isso não funciona. O contábil da empresa vai ficar louco com a falta de equalização entre a MBEW e a conta de estoque.
Como isso se resolve? Segue uma proposta simples, mas que funciona…
Você deve fazer a transferência saindo com o material por SD, criando ordem de vendas, remessa e fazendo a saída por lá. O cliente é o mesmo vinculado ao centro para efeitos de transferência.
Na saída os impostos são contabilizados em ICMS e ICMS-ST a recolher contra uma conta transitória de estoque de transferência.
Neste momento o material está no “limbo”, se olharmos apenas o standard. O estoque em trânsito deverá ser controlado por tabela Z de log deste processamento. O ideal é que seja construído um cockpit para esse controle.
Já a entrada no destino é feita por “MB1C” utilizando um movimento cópia do 501. Para o movimento novo foram abertos os campos Montante MI e o Base Diferente. O campo montante MI é usado para contabilizar o estoque e o base diferente faz com que os impostos sejam calculados sobre o valor deste campo, ignorando o montante MI.
No campo montante MI você vai informar o valor cheio que deseja contabilizar o estoque. Esse valor vai com custo no centro de origem + ICMS + ICMS-ST. Já o campo base divergente deve ir só com a base de cálculo dos impostos…
O código de imposto a ser utilizado precisa ter apenas as condições standard ICM2 e ICS2, que possuem a chave NVV. Isso fará com que a contabilização seja completamente ignorada, mas os impostos serão carregados na nota fiscal tendo como base de cálculo o valor informado em base diferente.
Exemplo bem simples da contabilização… Saída:
99 – Estoque -10,00
89 – Estoque trânsito +10,00
50 – ICMS -2
50 – ST -2
40 – Estoque trânsito +4 (Sim… O amiguinho de SD precisa usar a conta de estoque em trânsito como se fosse transferência de imposto.)
Entrada:
89 – Estoque +14,00
91 – Estoque -14,00 (Configura uma operação Z da GBB na OMJJ e aponta a conta de trânsito na OBYC.
Claro que é uma customização e possui os contras…
Issue 1. O material fica no limbo com zero controle do trânsito via standard após a saída.
Solução: Construção de uma tabela de LOG para fazer esse controle.
2. A entrada é totalmente desvinculada da saída no standard (mas os cálculos de impostos já são mesmo no standard).
Solução: Através de enhancement você substituirá os valores da nota de entrada pelos valores da nota de saída para garantir equalização nas duas etapas do processo. Pode usar a função J_1B_NF_OBJECT_UPDATE. Mas garanta que os demais processos da sua empresa não serão impactados.
Uma outra saída, menos garantida, só que mais segura e limpa, é sanear as exceções fiscais para que estejam totalmente equalizadas para que os impostos da nota de entrada sejam iguais aos da nota de saída. A não ser que os grupos de impostos atendam tanto MM quanto SD.
3. Se não for um programa Z a fazer o lançamento, o usuário tem que saber exatamente o valor que deve informar em cada campo (montante MI e base diferente).
Solução: Disponibilizar uma transação para que o usuário execute o processo de entrada. O programa vai ler os valores da saída e informá-los corretamente na BAPI que simula a MB1C.
Boa sorte aí! Have fun!
Cristiano, eu entendi a ideia, mas se me permite um comentário cândido, confesso que não me convenci com o trade-off de privilegiar o tributário sacrificando o contábil e o logístico.
Se no SD a saída for via 601, vai ficar em aberto uma conta transitória para ser fechada com billing posterior (o qual suponho que seja lançado depois, certo?). Este billing por sua vez vai gerar um recebível contra esta saída. Como este recebível será tratado, já deixá-lo em aberto implica em influenciar artificialmente as contas de resultado da empresa.
Do ponto de vista de MM, como seria possível garantir que a entrada via 501 na MB1C será no valor e quantidade corretos, em concordância com a NF-e de saída? Suponho que esta tarefa caberia ao Z-log proposto, mas já enxergo aqui um custo de desenvolvimento e governança.
Ademais, na hipótese do material ser avaliado com montantes distintos entre origem e destino, a falta de vínculo entre os movimentos impede que seja feita a correta apropriação de variação de preço que independe de imposto (nas chaves AUM, GBB, PRD, etc). De certa forma impede que o material ledger desempenhe seu papel, já que é quase impossível conciliar as duas pernas.
Uma saída que costumo indicar é nada mais que usar o processo de STO via 862-861 mesmo, lançar os tributos a recolher na saída contra a transitória TXO e utilizar o IVA C0 (ou equivalente) na entrada da mercadoria.
Com o C0, não será gerado documento contábil no 861, e também não será possível lançar em conta de estoque no destino - uma vez que o estoque na planta cliente já foi valorizado na saída da mercadoria:
Saída
Estoque origem ......... -100,00
Estoque destino......... +100,00
ICMS a recolher......... -12,00
ST a recolher............. -20,00
Imposto em trânsito... +32,00
Entrada
<sem lançamentos>
Note que o estoque no destino terá sido valorizado "a menor", sem considerar os tributos. É aqui que sugiro o ajuste subsequente, que consiste em efetuar um lançamento diretamente em FI, debitando TXO e creditando o estoque do material no destino, e compondo o custo real de132,00.
De qualquer forma, parabéns pela iniciativa de compartilhar essa sugestão.
Abraço!
Oi Eduardo.
Suas preocupações são pertinentes, mas seguem meus comentários:
A saída por SD não precisa gerar contas a receber. E a MB1C não vai gerar um contas a receber. Desta forma não sacrificamos o contábil, pois a conta usada como transitório de estoque e impostos na saída, será a mesma conta indicada na OBYC para ser a contra partida do estoque na entrada também.
Essa conta transitória será debitada por SD na saída e creditada por MM na entrada no destino.
Já a equalização dos impostos, é isso mesmo... Só via enhancement no processo de entrada. E o controle disso tudo, como disse no post, só mesmo por uma boa especificação funcional com um bom desenvolvedor ABAP.
Sobre o exemplo que você deu, só deveria existir uma forma certa de ter essa solução definitiva... A SAP alterar o produto para olhar a chave NVV no processo de transferência e entender que isso deve ir para custo do produto (PMM e conta de estoque). Fora isso, existem propostas e mais propostas, que cada cliente enxerga dentro das suas particularidades a mais aderente. Cabe a nós aqui propôr opções. Vamos seguir assim, compartilhando informações e experiências! É bom para todos nós!
Deixo um ponto de atenção para você. Não sei como prevê o lançamento direto por FI para zerar a transitória no processo que descreveu, mas dependendo da chave de lançamento você pode estar atualizando o saldo da conta, mas sem incidir sobre o PMM do produto no centro de destino. Além disso, é importante manter o rastreamento desses lançamentos para identificação de possíveis falhas na BAPI.
Obrigado por comentar e compartilhar suas considerações!
Olá, Cristiano,
Que este cenário deveria ser tratado no standard, não há dúvidas. Este gap existe há 1 década pelo menos. Não sei dizer o que falta para impulsioná-lo, se é respaldo da base instalada (que talvez seja latente), se é alguma restrição técnica, etc... de qualquer forma, acho que toda reunião da ASUG, Localization Summit, etc esse cenário deveria ser martelado, relembrado, comentado. Do contrário, o lugar comum será "A SAP <adjetivo depreciativo> não faz". 🙂
Vamos aos outros pontos: é bem verdade e bem lembrado que o ajuste direto em FI irá conduzir a um desbalanço entre o valor do estoque e a conta de estoque. Este é um ponto que precisaria ser considerado, sem dúvida, demandando um lançamento em MR22 complementar com ou sem geração de um documento de variação de custo no material ledger.
Seriam assim 2 ajustes subsequentes:
1) TXO vs estoque (FB01)
2) Ajuste do valor de estoque e/ou documento de variação de custo em ML (MR22).
Quanto à saída via SD, de fato não precisa gerar um recebível, mas como você não descreveu no artigo qual seria o document flow, supus que seria uma venda normal para cliente, O2C com 601. Não sendo isso, qual movimento você pensou em usar na saída e qual o fluxo de documentos que vc prevê? E como seria gerada a NF-e sem o billing?
Por fim, o cerne central da minha observação anterior está no fato da orquestração do processo depender de um monitor logístico Z, e à entrada de materiais ser feita sem referência a nada, via 501, que por definição é um movimento sem pai nem mãe. Evidente que a especificação deste monitor precisaria ser muito bem elaborada e se for robusta diminui bastante o risco.
A sugestão que dei também tem seus pontos cegos, mas alavanca o uso de outras funcionalidades associadas ao processo de STO, como geração automática de NF-e via remessa de saída, geração de ordem de transferência via processo de MRP, devolução parcial de transferência, etc...
Abraço!
É isso mesmo, Eduardo! Essa é uma outra proposta, mais comum de acontecer no mercado. Processo standard via STO com chamada de MR22 para contabilizar o imposto no estoque e FB01 para zerar transitórias. Já trabalhei com essa solução também e funciona.
Mas é como disse, a partir do momento que o standard não atende uma necessidade, as soluções se customizam e cada cliente escolhe o que é mais aderente. A chamada de MR22 com FB01 deve ocorrer no momento em que a entrada é confirmada no destino, pois se o material for movimentado entre a entrada e o ajuste do preço, você vai distorcer o PMM. Por exemplo...
- Você está transferindo 100 unidades com um total de imposto de R$ 500,00. Com a MR22 você deverá aumentar em R$5,00 o PMM do material.
- Se entre a movimentação e o ajuste metade dessa quantidade tiver sido consumida, quando você lançar os R$500,00 no estoque via MR22, você vai aumentar em R$10,00 o seu PMM.
Esse risco ocorre se a rotatividade for alta. Se você pode bloquear esses materiais até fazer o ajuste, zero risco nesse ponto.
Mas acho que o maior desafio dessa solução com MR22 e FB01 é prever o "undo" no caso de uma devolução dessa transferência.
Você já trabalhou com esse cenário? Se colocou a MR22 e FB01 automatizada deve ter dado um trabalho para controlar esse processo e garantir o undo... Mas é nosso dia a dia... Apresentar opções e o que importa é o cliente feliz.
Eu não cheguei a fazer esse cenário, não, ficou apenas na dimensão do brainstorm. Mas a ideia é que FB01 e MR22 sejam lançadas automaticamente, via desenvolvimento, dentro da mesma LUW da MB01/MIGO com o 861. Idealmente em update task.
Já a questão do estorno e devolução são um problema adicional a ser considerado, sim. Em ambos seriam necessários lançamentos análogos de FB01 e MR22.
Uma terceira via para ser considerada - a qual não tenho domínio técnico para comentar - seria trabalhar com preço standard (ao invés de MAP) + ML, e avaliar a possibilidade de incorporar o saldo da TXO no cálculo do MAP no fechamento do período.
Neste caso (que não sei a viabilidade técnica), a cada saída de mercadoria via 862 seria criado um documento em ML variando o custo no destino no valor da TXO.
A quarta via, por fim, seria fazer um enhancement no seguinte ponto:
Include LMBGBFJ1 --> dentro do form J_1B_TX_CALCULATE_TAX, ao final, mover o valor de iftax-tout para a variável 'BESTU' (que alimenta BSX no estoque de destino).
Abraço!
Rubia
Olá Cristiano,
Legal a dica, mas ainda acho que a SAP deveria resolver este problema.
Todo projeto é a mesma coisa, SAP enrola e não atua.
Enquanto isso, vamos utilizando as manobras técnicas e contornando os problemas.
Um abraço e parabéns pela postagem!
Oi Antonini...
Concordo plenamente! Só não creio que caiba tal esforço agora que o S/4 está sendo concebido aos poucos. Acho que vale concentrar todo o esforço na nova solução para chegar arrebentando no mercado! Ficamos na torcida para que o S/4 nos traga boas novidades no processo de transferência localizado.
Também não conheço a solução do Retail. Não sei se com o IS-Retail essa questão seria atendida, pois esse cenário fiscal é bem voltado para transferências na última cadeia do processo pré-venda, onde a empresa não tem mais onde tomar crédito de imposto.
Obrigado!
Tivemos alguma evolução quanto a esse ponto? A SAP liberou alguma nota ou instrução quanto a esse ajuste?
Olá Pessoal,
Alguém já verificou esse cenário com o processo: 3153630 - Standard process flow for Intracompany Stock Transport Order with Valuated Stock In Transit (STO SiT) for Brazilian Localization?
Att, Marcelo Góis.