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ábil receberá 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
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 key 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 contabilidade. 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ãoseja 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.
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)
7. 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
Fonte: Eduardo Rubia - SAP SCN
Nenhum comentário:
Postar um comentário
Observação: somente um membro deste blog pode postar um comentário.