Integração MM-IM/FI com impostos

Esse não é um conteúdo original meu, na verdade esse é um post de 2015 do Eduardo Rubia (antigo mestre JEDI da localização brasil na SAP) e que ficou perdido no mundo devido a troca de plataforma da SAP Community.

O post original estava no endereço http://scn.sap.com/docs/DOC-63018 e hoje não está mais disponível, porém, graças a pirataria almas bondosas que guardaram o PDF é possível restaurar essa pérola de conhecimentos SAP.
Abaixo segue o post na íntegra:

“Caros,
Uma das integrações mais antigas e menos entendidas do mundo localizado é o dos lançamentos contábeis na MIGO (& afins) relacionados às condições de impostos. Muita gente já desbravou a lógica por trás disso na raça (leia-se: debug e caderninho), mas muitos ainda penam para entender como ela funciona.
Pensando nisso, desenterrei esse artigo que comecei escrever há um bom tempo para compartilhar por aqui. Vou fazer uma longa introdução sobre a integração nativa MM-IM/FI standard, para depois aprofundar na parte de localização.

1. O que determina lançamentos contábeis em MM-IM?

Em Inventory Management, os lançamentos contábeis são determinados através das value strings associadas ao tipo de movimento.
A value string é basicamente o link entre MM e FI. A value string define quais são os lançamentos contábeis possíveis para uma dada operação logística (a.k.a. movimento de mercadorias).
Cada lançamento contábil possível é representado por uma transaction key (OBYC). A transaction key é o direcionador que diz qual conta contáb il receb erá o montante pertinente à operação em questão.
Assim, temos o primeiro conceito a ser entendido: tipo de movimento (1) determina value string (2), que determinam transaction keys (3), que por fim determinam as contas contábeis (4). Assim, a value string é apenas um agregador de transaction keys.
OMJJ -> Update Control

OBYC

Integração MM-IM/FI com procedimento de cálculo (TAXBRJ/TAXBRA)

2. Um pouco mais sobre value string e transaction keys.

As value strings existentes são definidas pela SAP. Elas são códigos internos, não configuráveis e não se
deve/recomenda criar strings custom – mas sim buscar uma que se adapte ao movimento de mercadorias que estiver sendo criado (no caso se movimentos Z).
Para cada value string há uma rotina de mesmo nome no código, que em tempo de execução é chamada para desencadear a lógica pré-definida e popular as variáveis de cada uma das transaction keys (mais sobre isso a seguir). Existem também posting strings específicas de algumas industry solutions (IS-OIL, por exemplo). Toda a lógica acima ocorre debaixo do function group MBGB – mais especificamente no módulo de função MB_CALCULATE_VALUES. Este FM é o orquestrador da integração IM/FI, e dentro dele vamos encontrar as chamadas para as rotinas das value strings. Aqui está encapsulada a “inteligência” da integração IM/FI:
Exemplo: chamada da value string WE01

É a partir deste ponto do código que são definidos os valores a serem lançados em cada uma das transaction keys (BSX, WRX, TXO…) – lembrando que cada posting string atua somente nas transaction keys prédefinidas na T156W (a seguir explico).
Não é possível criar novos transaction keys via configuração – e tampouco é necessário, já que virtualmente todos os lançamento contáveis possíveis já são previstos.
Neste link do SAP Help são descritas e explicadas todas as transaction keys existentes, bem como suas
funções.Não é preciso entender todas elas, mas algumas são mais importantes, as quais listo abaixo:

Transaction Key – Utilização
BSX – Conta de estoque/material
WRX – Conta transitória
PRD – Conta de diferenças de preço
AUM – Ganhos/perdas com transferências de estoque
TXO – Tansitória de impostos para STO (exclusiva para localização)*

*A transaction key TXO é utilizada nos processos de STO localizados, com os movimentos 861/862, 833/835 e suas respectivas devoluções/estornos. Ela é gerada com a execução das CATTs de Localização Brasil, e é utilizada nas value strings WA04 (saída de STO) e TXBR (entrada de STO Brasil).
Uma outra maneira de ver as transaction keys associadas a cadas value string é olhando diretamente na
tabela T156W. Nesta tabela, podemos ver adicionalmente mais uma informação relevante: o campo chamado FELDN.

Este campo representa o nome da variável correspondente à transaction k ey em tempo de execução. É uma informação importante para ser lembrada durante o debug (ali na MB_CALCULATE_VALUES), pois vamos sempre monitorar a variável de interesse de acordo com o lançamento contábil que estivermos analisando.
Exemplo 1: se o valor que está indo para a conta transitória estiver incorreto, vamos monitor a variável VWERE, pois ela contém o montante que será lançado na transaction key WRX
Exemplo 2: se o valor que está indo para o material/estoque estiver incorreto, vamos monitorar a variável BESTD, pois ela contém o montante que será lançado na transaction key BSX.
Dica: Veja também e coloque eu seus favoritos este link para dicas de debug relacionadas a valuation em
MM.

3. Melhorando a análise: prevendo lançamentos

Evidentemente que todas as informações passadas até aqui não têm nenhuma serventia se o consultor de MM não souber o quê ele espera da contab ilidade. Tem muito consultor de MM que diz que quem define o que vai para a contabilidade é o FI. Eu discordo. O FI define para qual conta vai um valor, mas o sentido funcional por trás de um documento contábil – IMHO – é estabelecido pelo MM (ou pelo módulo que dispara a integração).
Por isso, é fundamental que antes de iniciar a análise, o consultor pegue um papel e uma caneta, desenhe o que ele espera ver na contabilidade, e a partir de agora passe também a incorporar nesse desenho as transaction keys que ele espera ver valorizadas (e eventualmente também as variáveis, se precisar de um debug)
Exemplo 1: recebimento de mercadoria
Conta Valor TK Variável
Conta de material ………… 1.000,00 + ………. BSX…….. BESTD
Conta transitória…………….1.000,00 – ………. WRX……. VWERE
Exemplo 2: saída de transferência entre centros com reavaliação
Conta Valor TK Variável
Conta de material origem… 1.000,00 – ………. BSX…….. BESTD
Conta de material destino… 950,00 +………. BSX…….. BESTU
Ganho/perda com reaval….. 50,00 + ………. AUM……. UMDIF

4. Integração com TAXBRA/TAXBRJ

Ok, e os impostos? Os lançamentos de impostos em IM são determinados por 3 coisas:

4.1. Valores das condições de imposto calculadas (“o quê”)

Os valores das condições de imposto aqui serão calculados caso um tax code seja informado na movimentação de
mercadorias (nenhuma novidade). Em tempo de execução, são as linhas da tabela interna xkomv[], que é
populada pela função PRICING antes da função de integração IM/FI.

4.2. Chave de lançamento de imposto (“onde”)

Trata-se das chaves definidas na transação OBCN, e vinculadas às condições no procedimento de cálculo.
Estas chaves definem tanto o aspecto contábil do tipo de imposto (entrada, saída, custo, despesa, etc – tudo configurado na OBCN), quanto qual a conta contábil que vai receber o montante da condição (configuração feita na OB40).

OBQ3:

OBCN:

4.3. Mapeamento de condições de impostos para value string (“como”)

Esse mapeamento é realizado na tabela/view J_1BIM01 e tem por finalidade definir como uma condição de imposto deve ser lançada em FI para uma certa value string. Já sabemos que cada value string contém uma série de transaction keys possíveis de serem lançadas. A partir do momento em que introduzimos novos lançamentos relacionados a impostos, devido ao desbalanço que isso gerará, é preciso dizer como eles devem figurar na contabilidade, para que o sistema ajuste os valores das transaction keys (BSX, WRX, etc) conforme necessário.
J_1BIM01V:

Vamos entender um pouco melhor essa configuração. A parte destacada em amarelo indica o FELDN – ou seja, o nome da variável em tempo de execução (já falamos dele lá em cima) – que será usado para armazenar o montante referente ao imposto lançado. No caso acima, TINP1 terá o valor do ICM1 para movimentos que utilizem a value string WE01 (exemplo: 801, 811).
Vocês certamente notarão que não tem um matchcode para selecionar o FELDN. Pois é. Isso ocorre porque, como comentei, o FELDN é o nome de uma variável do programa. Para saber todos os existentes, tem que olhar diretamente no código. Mas já fiz isso pra vocês, e selecionei os principais (há outros, mas que evitamos utilizar – a lista completa está na estrutura J_1BIMIFTAX):
FELDN Utilização
TOUT0 – TOUT9 Impostos de saída
TINP0 – TINP9 Impostos de entrada
TAX01 – TAX10 DIFAL

Importante: Considerando que o FELDN é uma variável, é fundamental garantir que o mesmo FELDN não seja utilizado para mais de uma condição ativa no mesmo tax code. Motivo: se isso não for feito, a variável irá assumir sempre o valor da última condição lida. Consequência? Erro no documento contábil ou erro de balanço.
Já a parte destacada em laranja indica que tipo de partida contábil está sendo criada. Em geral utilizamos “Tax – general”, ou “Material”.
Dica: É importante salientar que o Line Item ID é influenciado pelo flag “Non Deductible” definido na OBCN. Se for indicado lá que o imposto é “não dedutível”, a linha será automaticamente criada como um lançamento na conta do material.

5. Quase no fim…

Agora que temos entendidos “o quê”, “onde” e “como”, já podemos fazer a mágica acontecer…, certo?
……. quase!
Ainda temos que considerar um último e importantíssimo ponto, que é a parte “hard coded” de tudo isso. Sim. Assim como a inteligência para popular os transaction keys para cada posting string é fixo (não configurável), a inteligência que ajusta os transaction keys em função dos impostos tamb ém é hard coded. Onde? Em 2 pontos no código:

5.1. FORM j_1b_tx_calculate_tax (FUGR MBGB).

Este form é chamado dentro da MB_CALCULATE_VALUES, a partir das subrotinas de cada value string localizada:
TXBR, COBR, WE01, WA01, WA04, WE06. (Quem quiser se aprofundar mais, dê um where-used list no form). A função deste form é agregar as condições de impostos processadas em “categorias” de lançamentos. Cada categoria de lançamento produz um efeito no resto das transaction keys do value string.
Exemplo: lançamentos com FELDN = TINPx (entradas) são somados, e o total influenciará o valor de BSX (BESTD – estoque), WRX (VWERE – transitória) e/ou PRD (PRDIF – diferença de preço).
Por isso, Dica: é fundamental entender como um imposto deve figurar no documento contábil, a fim de entender como o valor influencia o restante dos lançamentos.

5.2. FM J_1B_IM_TX_CALCULATE_TAX_NEW

Este módulo de função é chamado de dentro do ponto 5.1. acima. Ele desempenha basicamente as seguintes funções:
a. loop na xkomv[], para ler as condições de imposto com valor
b. loop na j_1bim01, para direcionar o valor das condições para o FELDN localizado
c. para cada condição de imposto, ajuste dos FELDN standard conforme necessário
Tecnicamente falando, é essencialmente isso. Não é simples, mas eventualmente, a gente acaba aprendendo. A dica é, se possível, investir no debug, pois como parte da lógica é hard coded fica muito fácil de entender.

6. Melhorando a análise II: prevendo lançamentos incluindo impostos

Vamos usar os mesmos exemplos anteriores, mas considerando agora cenários localizados que requerem
lançamentos de impostos na movimentação de mercadoria:

Exemplo 1: recebimento de mercadoria no processo de entrega futura com ICMS

Conta Valor… TK… Variável… Condição de imposto
Conta de material ………… 1.000,00 + ………. BSX…….. BESTD
Conta transitória…………….1.000,00 – ………. WRX……. VWERE
Crédito de ICMS …………… 136,36 + ………. VS2 …….. TINP1 ……… ICM1
ICMS em trânsito …………. 136,36 – ………. ICC ………TINP3 ……… IC1O

Exemplo 2: saída de transferência entre centros com reavaliação e recolhimento de ICMS + IPI

Conta … Valor… TK.,, Variável… Condição de imposto

Conta de material origem… 1.000,00 – ………. BSX…….. BESTD
Conta de material destino… 950,00 +……… BSX…….. BESTU
Ganho/perda com reaval….. 50,00 + ………. AUM……. UMDIF
ICMS a recolher…………….. 136,00 – ……….. MW2……. TOUT1 …… ICM3
IPI a recolher………………… 85,00 – ……….. MW1……. TOUT0 …… IPI3
Impostos em trânsito………. 221,00 + ………. TXO ……. TOUTX (hard coded)

“Exercício
Quem quiser treinar o assunto, seguem alguns cenários interessantes para fazer a previsão de lançamentos.
Recebimento de mercadoria consignada com ICMS
Recebimento de ativo com DIFAL (dica: nota 844630 já dá metade da resposta…)
Estorno de entrada de entrega futura para consumo

Autor: EDUARDO RUBIA”

Quer ficar ligado nas novidades de localização? Entra no grupo da S4CN no Telegram e segue a gente no canal do Youtube

Mais infos sobre a localização Brasil no ERP, direto da sap, vocês podem conferir no SAP community na tag de S/4HANA logistics for Brazil

Outros posts sobre Localização você pode conferir filtrando pela categoria NFE/CTE ou Localização BR Geral.

Outros posts sobre TDF você pode conferir filtrando pela categoria TDF/ACR.

Valeu Gurizada,

Renan Correa