FF714 – Erro na chave de lançamento em cenário de compra

Publicado por:Renan Correa Thu, 31 March 2022
Compartilhe:
31 de March de 2022

FF714 – Erro na chave de lançamento em cenário de compra

Semana passada estava configurando um cenário de imposto retido nas compras e eu estava tendo um erro FF714 que não existia regra de lançamento para uma chave de conta, mas o sistema não estava me mostrando nem chave de conta nem condição na mensagem de erro.

Além disso, eu tava na ordem de compra, que regra de lançamento que tá buscando?

Graphical user interface, text, application, email

Description automatically generated

Lá fui eu fazer um debugging para ver o que tava acontecendo.

Procurando a origem do erro

Só pela mensagem de erro (se91 e where-used-list) não achei a causa porque no momento que o erro era chamado eu não tinha nenhuma informação da chave de conta e consequentemente não era possível saber de que condição da pricing vinha o erro.

Nesse caso olhando a Pricing tem dezenas de condições sem chave de contabilização, logo não é muito fácil de achar qual seria a causa do problema.

Por isso tive que voltar um pouco na “stack” do processo e procurar qual condição estava causando esse problema.

Então nesse ponto voltei no debugging ao último LOOP da T_KOMV para procurar qual a condição estava sendo processada por último antes do erro ser disparado.

Achei a condição BXWT no debugging:

Olhando na pricing a condição BXWT estava sem chave de contas, mas isso está certo.

Então porquê o sistema estava tentando processar ela como uma condição para ser contabilizada?

Voltando no debugging, na FM CALCULATE_TAX_ITEM (já tinha citado essa FM no post sobre pontos de debugging na PO) tem o form NAV_ANTEIL_AUS_T_KOMV e aqui achei a explicação do erro:

O sistema desconsidera condições estatísticas “KSTAT = SPACE”. HMMMM…

A BXWT tem que ser estatística!!!

Esse é o problema, a condição estava sem a flag de estatística e estava sendo processada como um imposto a ser contabilizado.

Corrigi a configuração da BXWT (deve ter sido uma clicada errada que desmarcou a condição) e o cálculo na PO funcionou certinho.

Configuração certa

Moral da história: FCQDC, Faz certo que dá certo!

Valeu gurizada!

Renan Correa

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.

5 Comentários
Oldest
Newest Most Voted
Inline Feedbacks
Ver Todos Comentarios
Márcio Santos
Márcio Santos
1 mês atrás

Essa pegadinha sempre me aparece em SD, então já fico de olho nos estatísticos, principalmente quando se fala de impostos.

Márcio Santos
Márcio Santos
1 mês atrás

Alguém teria algum material falando do novo DIFAL em SP na price de MM?

Márcio Santos
Márcio Santos
1 mês atrás
Responder Para  Renan Correa

Renan, mil perdões.

Eu me enrolei em um projeto com o pessoal do México e esqueci de tudo.

Temos agora em SP um cálculo de DIFAL igual ao cálculo normal do ICMS partindo do valor sem ICMS, ou seja, quando receber a nota fiscal a partir desse valor você deverá calcular o ICMS por dentro com a alíquota interna do estado e abater o ICMS cobrado na nota fiscal do fornecedor. Parece ser a mesma regra anterior, mas tem uma sutil diferença.

Ex.
Valor da nota fiscal 1.000 com ICMS de 12% e interna de 18%
Base antiga = 1000
DIFAL: 180-120= 60

Base nova: 1000-120=880/0,82= 1073
DIFAL: (1073*18%)= 193 => 193-120= 73

Nesse exemplo o DIFAL aumentou em R$ 13,00.

Eu encontrei a Snote 2394557, a qual já temos no sistema, porém a BADi ainda não foi ativada.

Preciso estudar um pouco mais para ativá-la. Depois eu comento como foi.

Abraço!

Márcio Santos