Skip to Content

Oi Pessoal,


Estamos disponibilizando um guia para analisar incidentes relacionados com a nota fiscal eletrônica tanto no ERP como no SAP NF-e (GRC).

Cenários:

Cancelamento por evento não finalizado no ERP

Tag não mapeada corretamente para o XML

Caso vocês tenham mais idéias e/ou sugestões de cenários sintam-se livres para sugerir este material ( tanto tópicos como o conteúdo ).

OBS: Este post foi migrado de um “SCN Document” que não será migrado para a nova plataforma.

Cancelamento por evento não finalizado no ERP

Como começar a análise?

Eu sempre sugiro começar da própria transação J1BNFE, monitor de NFe no ERP.

O que analisar?

Recomendo começar pelos campos “Etapa do Processo”, “status do documento”, status de comunicação do sistema e status do sistema de mensageria. Além disso, é necessário clicar no na flag de eventos para poder visualizar o status do evento.

Os status necessários para cada etapa de qualquer processo (autorização, cancelamento, inutilização) podem ser vistos no help do ERP:

Statuses in NF-e/CT-e Monitor

Para entender um pouco mais do processo do cancelamento basta seguir a descrição abaixo. Uma recomendação adicional é sempre procurar por SAP Notes utilizando os objetos relacionados com o processo ( funções, tabelas, estruturas ) e/ou utilizando ferramentas automatizadas da SAP como o ANST  (Automated Note Search Tool ).

1- NF-e com inconsistência entre J_1BNFE_EVENT and J_1BNFE_ACTIVE:

No caso abaixo, por exemplo, há uma inconsistência  no documento, pois o status do evento é “autorizado” e o status da NF-e é “esperando resposta da mensageria”.

A causa mais comum desse erro é a falta da SAP Note 2029305.

A solução desse problema seria manual, executar a função J_1B_NFE_XML_IN simulando a autorização do cancelamento (DOCNUM, AUTHCODE = Protocolo da SEFAZ, AUTHDATE = Data de autorização na SEFAZ, AUTHTIME = Hora da autorização na SEFAZ, CODE = 101 para cancelamento e MSGTYP = 4 autorização para cancelamento )

Picture1.png

2- NF-e (sem inconsistência) esperando resposta do GRC para cancelamento

Esse procedimento acima resolve o problema no caso da tabela de eventos do ERP estar fora de sincronia com a tabela J_1BNFE_ACTIVE.

Porém existem outros cenários de erro em que a tabela de eventos e a tabela active estão em sincronia ( ambas esperando resposta do SAP NF-e / GRC )

Picture2.png

Neste caso a recomendação é verificar como estão os status dos documentos no SAP NF-e / GRC. Se o status do “Cancelamento” for OK ( 01 / Verde ) então bastaria executar a funcionalidade “Repetir etapa process” assim como na imagem abaixo:

Picture3.png

Essa funcionalidade está disponível a partir do SP20

Se o status do “Cancelamento” fosse “135 – Autorizado” e o passo do “update para o ERP” estivesse com Erro ( 02 / Vermelho ) então bastaria executar a funcionalidade “Continuar processo” assim como na imagem abaixo:

Picture4.png

No caso de você não possuir o SP20 e precisar trazer o update de volta pro ERP é possível executar a função /XNFE/PROCSTEP_EV_ERPUPDAT no SAP NF-e para reenviar o status de OK para o ERP.

Porém há casos em que esses procedimentos de disparar a atualização do SAP NF-e ( GRC ) para o ERP podem não funcionar por “n” motivos ( falta de SAP Notes, modificação de funções core, validações incorretas ou commit work dentro de BAdI, problema de conexão ou RFC entre os dois ambientes, etc… )

3- NF-e (sem inconsistência) esperando resposta do GRC para cancelamento porém update do GRC não funcionou

Se esse procedimentos acima não estiverem funcionando, então a última opção para analisar/resolver o problema seria executar a função J_1BNFE_EVENT_IN do lado do ERP para simular o processamento e depurar o programa para identificar a causa da atualização não ser realizada.

Picture7.png

Os parâmetros abaixo são necessários para a execução manual da função. Uma dica interessante caso você não saiba como preenchê-los é botar um breakpoint no SAP NF-e ( GRC ) antes da chamada da J_1BNFE_EVENT_IN e executar a função /XNFE/PROCSTEP_EV_ERPUPDAT. Desta forma seria possível ver quais os parâmetros passados pelo SAP NF-e para o ERP.

Picture6.png

Já do lado do ERP o começo do processamento da J_1BNFE_EVENT_IN tem o FORM process_nfe_for_cancel_event que verifica se o cancelamento foi autorizado, se todas as informações necessárias foram recebidas do SAP NF-e e após isso o programa irá chamar a função J_1B_NFE_XML_IN.

Picture8.png

A função J_1B_NFE_XML_IN por sua vez tem algumas validações dos status da tabela active e também do método check_subsequent_documents da BAdI CL_NFE_PRINT e do período contábil.

Picture9.png

Nesse ponto é possível adicionar regras de negócio para verificar/estornar outros documentos que normalmente não fazem parte do fluxo da NF-e.

Picture10.png

Além disso vale ressaltar que o programa também faz a verificação se o período contábil associado com a empresa ( company code ) está aberto. A lógica do cancelamento da nota fiscal no ERP não permite o estorno se o período contábil está fechado. É necessário, antes de realizar o fechamento, fazer uma varredura dos status das notas fiscais a fim de identificar documentos que estão em processo de cancelamento porém não estão cancelado, a fim de evitar problemas futuros para o fiscal ( nota cancelada na SEFAZ porém não pode mais ser cancelada no ERP ).

Picture12.png

Picture11.png

4- NF-e já cancelada na J_1BNFE_ACTIVE porém parada na etapa “2 – Cancelar documento de origem”

Em muitos casos o ERP irá passar pelas validações acima, porém pode não finalizar o cancelamento com sucesso e parar com o status abaixo:

Picture13.png

Nesse caso o processo de cancelamento/atualização da tabela J_1BNFE_ACTIVE foi realizado com sucesso, porém o documento de origem da NF ( fatura, documento de material, remessa, etc… ) não pode ser estornado por alguma razão.

Para verificar essa razão você pode clicar no log da J1BNFE ( bandeirinha vermelha ). Caso o erro não seja claro ( como por exemplo “No Batch input data for screen XXXX XXXX ) é possível também solicitar o estorno do documento de origem ( conforme imagem abaixo ) e depurar esse processo de cancelamento.

Picture14.png

O código abaixo mostra uma parte da função J_1B_NFE_CANCEL, que identifica qual o tipo de documento de origem e realiza um “call transaction” para a respectiva transação de estorno conforme as imagens abaixo:

Picture15.png

Uma dica para depurar o processo é alterar a variável lv_mode de P para A, desta forma a transação de cancelamento será executada na tela e caso exista algum erro ele será mostrado diretamente na tela.

Picture16.png,

Tag do XML não é mapeada corretamente


Como começar a análise?

É sugerido começar pela função J_1B_NF_MAP_TO_XML que é onde basicamente começa o mapeamento das informações para a estruturas que serão enviadas para a mensageria ( SAP NF-e ).

O que analisar?

Dentro da função J_1B_NF_MAP_TO_XML as informações das tabelas do ERP serão lidas e será feito um mapeamento preliminar onde serão populados os dados das estruturas xml* (xmlh de header e xmli de item).

A dica para verificar um problema é criar um breakpoint at statement “RFC”. Ao executar o programa com esse breakpoint isso irá levar até a função /XNFE/OUTNFE_CREATE.


Neste ponto é necessário verificar se as tabelas/estruturas GT_RFC* e GS_RFC* estão com a informação necessária ou não. No caso da informação estar correta nesse ponto então o problema é no mapeamento dos dados no SAP NF-e. No caso da informação não estar preenchida ou estar com uma informação incorreta então o problema é no mapeamento dos dados no SAP ERP.


Picture1.png

Para o layout 3.10 especificamente o mapeamento final dos dados ocorre dentro do perform call_message_system_comm onde os dados das estruturas xml* serão mapeados para as GT_RFC* e GS_RFC* que serão realmente enviadas para a mensageria.

Picture2.png

No final do perfom call_message_system_comm há a chamada do SAP NF-e, na função /XNFE/OUTNFE_CREATE.

Picture3.png

A dica para identificar onde um campo é preenchido no ERP é utilizar a busca “in main program” utilizando no nome da tag do XML ( ou campo/estrutura do SAP ERP) e assim visualizar a linda do código onde a informação é preenchida.

Picture4.png

Existem basicamente três jeitos de preencher uma informação nas estruturas do SAP ERP:

1 – A partir das tabelas j1bnf* e dados mestre.

2 – Cálculos em tempo de execucao a partir de tabelas

3 – Badi’s

Nas imagens abaixo voces podem ver respectivamente os pontos do codigo onde sao chamados os métodos de header e item:

Picture6.pngPicture5.png

Picture7.png

No final do processamento do programa ele irá realizar uma chamada para o GRC usando a função /xnfe/outnfe_create de acordo com a imagem abaixo:

Picture3.png

No GRC o programa irá receber os dados do ERP e irá passar pela validação técnica na função /xnfe/outvalidation e se tudo estiver tecnicamente correto então o programa passará para a função /xnfe/outnfe_transform onde as estruturas da proxy serão preenchidas conforme imagens abaixo:

Picture8.png

No form fill_proxy_structure o programa irá verificar o que foi enviado pelo ERP e mapear os campos relevantes de acordo com a hierarquia de informações do XML e isto será transformado para o formato XML pela proxy no passo seguinte:

Picture9.png

att,

Renan Correa

To report this post you need to login first.

9 Comments

You must be Logged on to comment or reply to a post.

  1. Nailton Cruz

    Eu estou caso de Cte que está na etapa D. Ele está autorizado e tentaram cancelar. O cancelamento foi rejeitado a numeração não consta no livro de saída. Como faço para ele voltar a aparecer no livro fiscal de saída e ficar com status concluido na J1BNFE?

    (0) 

Leave a Reply