E agora: Erro SAP FMUP127 Modificação da classif.contábil na geração de documentos (v.txt.descr.)!

Esse erro ocorre quando o módulo PSM-FM está ativo no sistema e há algum equívoco no processo de derivação configurado  por meio da transação FMDERIVE.

Para facilitar o entendimento dessa postagem, dividiremos em três tópicos:
  • Entendendo os eventos de derivação CHECK e PROJECT;
  • Localizando o erro no processo de derivação;
  • Consertando o erro.
Entendendo os eventos de derivação CHECK e PROJECT

Pensando somente no módulo de MM, uma vez que o módulo de PSM-FM foi ativado no sistema, pelo menos um centro financeiro e um item financeiro precisa ser derivado sempre que uma requisição, pedido, MIGO ou MIRO forem lançados no sistema.

O lançamento de qualquer um desses documentos no módulo de MM dispara um processo de derivação em FM que é subdividido em duas etapas, também conhecidos como eventos.

O primeiro deles é o evento CHECK. Ele visa passar por todas as regras de derivação de FM configuradas na transação FMDERIVE como forma de classificar qual o centro financeiro e item financeiro que o documento original derivará. Ele é acionado antes que o documentos seja criado e passe por qualquer outra configuração do módulo de CO ou FI, tais como a repartição automática de documento configurada no NewGL.

O segundo evento é chamado de PROJECT. Ele visa passar por todas as regras novamente para garantir a consistência entre todos os documentos que serão lançados no SAP, por exemplo: Quando uma MIRO é lançada, uma série de documentos é lançada em diversos módulos do SAP, temos o documento contábil em FI, o documento de custos em CO, o documento de orçamento em FM, a nota fiscal no cenário brasileiro etc. Esse evento visa garantir que todos os documentos sejam criados contendo centros e itens financeiros aderentes ao que foi inicialmente configurado na FMDERIVE.

Em algumas situações, por um erro de configuração na transação da FMDERIVE, em cada passo da derivação um centro financeiro ou item financeiro é derivado, gerando assim uma inconsistência que apresenta o erro informado no título dessa postagem.

Localizando o erro no processo de derivação

Uma vez que o erro é apresentado para o usuário, temos então que iniciar o diagnóstico para entender onde está a inconsistência no processo de derivação.

Uma ferramenta bastante útil é a ativação do trace do módulo de FM feito através da própria transação FMDERIVE. Ao acessar essa transação, há um botão que faz essa ativação.

Botão de ativação do trace na transação FMDERIVE

Uma vez feita a ativação, é preciso simular o lançamento do documento na transação de negócio que originou o erro. No momento da gravação desse documento, o usuário será notificado com uma tela onde ele poderá acompanhar a derivação de cada linha do documento que será criado, bem como a respectiva derivação de cada um deles em cada um dos eventos informados acima.

Tela do trace para cada linha de lançamento

Para cada linha do documento que será criado, essa tela acima será apresentada ao usuário final. Nela é possível verificar qual é o evento que está sendo acionado naquela respectiva derivação (Seta Vermelha), bem como os campos que dão origem ao processo de derivação (Retângulo Preto - Objetos FI/MM) e os campos derivados por meio das regras cadastradas na FMDERIVE (Retângulo Verde - Classificação contábil de Ado/GM).

Se forem muitas linhas de lançamento, será necessário pegar um papel e caneta, ou com ajuda do bloco de notas do próprio windows, ir anotando cada uma das derivação no evento CHECK e verificar qual derivação que está sendo diferenciada no evento PROJECT.

Como boa prática, é sempre bom colocar tanto o item financeiro como o centro financeiro similar aos campos que originarão as derivações. Na imagem acima é possível observar que o centro de custo 30040400CC deriva para o 30040400CCCF. Isso auxilia bastante no momento de verificar se a derivação ocorreu conforme planejado ou não. Claro que fazer algo dessa natureza dependerá das regras de negócio da empresa, nem sempre será possível fazer essas associações.

Algo bem ilógico nessa tela é que a passagem para a próxima derivação é feita clicando no botão com o ícone do X no canto inferior direito da tela.

Outra ferramenta que pode auxiliar na análise é o botão que aparece na base da tela do trace chamado de Exibir Log. Ele apresentará todas as regras definidas na transação FMDERIVE e mostrará qual regra foi ativada para fazer a derivação apresentada. 

Tela exibida para detalhando o log da derivação

Consertando o erro

O ajuste do erro é bem particular em cada situação, porém ele quase sempre necessitará de um ajuste na transação FMDERIVE. Para trazer uma exemplo para vocês, vou descrever um caso prático que peguei recentemente e como foi feita a devida correção.

Em um local onde há implementado o PSM-FM, o cliente solicitou que o controle orçamentário não fosse feito no menor nível empresarial, com isso, por meio das regras de derivação, foi simulada uma chamada recursiva com uma das regras derivando do centro de custo para o centro financeiro e outra, imediatamente depois, derivando esse centro financeiro para um segundo centro financeiro, chamado pela empresa de centro financeiro orçável, sendo esse último, o centro financeiro final a ser derivado pelo módulo.

Assim como na regras de validação do módulo de FI, transação GGB0, cada regra de derivação possui também uma configuração de condição de acionamento. Além disso, uma regra de comportamento caso o objeto derivado já possua um valor encontrado por uma regra anterior. Foi exatamente nessa regra de comportamento que encontramos a inconsistência que estava disparando o erro FMUP 127.

A regra estava configurada com a opção abaixo marcada.

Configuração da condição de acionamento da regra de derivação

Como é possível observar, a opção de sobregravar estava levando a uma dupla derivação nos dois eventos existentes de derivação, pois no evento CHECK, a derivação passava por duas regras, uma que derivava do centro de custo Inicial para o primeiro centro financeiro. Depois ela passava do primeiro centro financeiro para o segundo centro financeiro, por conta da regra que simulava a recursividade.

Quando a derivação ocorria novamente no evento PROJECT, a primeira derivação do centro de custo para o centro financeiro não ocorria, pois já havia uma centro financeiro derivado na etapa anterior, porém quando ele passava pela segunda regra que pegaria um centro financeiro e derivaria para um outro centro financeiro, ele gerava um erro, pois como a condição estava marcando a opção de sobregravação, o centro financeiro final derivado no evento CHECK era modificado e então o erro aparecia para o usuário final.

Abaixo segue um esquema para facilitar o entendimento do que foi explicado acima. Vocês podem observar que ao final de cada um dos eventos, os centros financeiros eram distintos.

Regras de derivação no exemplo prático do problema


Como forma de complementar o assunto abordado, encorajo-os a olhar esse Wiki da própria SAP sobre o erro: Wiki SAP FMUP 127

Além disso, segue algumas notas SAP sobre assuntos abordados nessa postagem que podem auxiliá-los na análise desse erro e no entendimento de ferramentas aqui utilizadas para a solucioná-lo:

SAP Note: 666322 - Fmderive tool trace
SAP Note: 2090247 - FMUP127: how to analyze, debug and the main notes.

Comentários

Postagens mais visitadas deste blog

How to: Dicas secretas no SAP

How to: Dados Mestres MM - Materiais - Parte 2

E agora: Erro SAP M7064 - Documento não contém item selecionável