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:
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 )
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 )
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:
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:
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.
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.
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.
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.
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.
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 ).
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:
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.
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:
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.
,
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.
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.
No final do perfom call_message_system_comm há a chamada do SAP NF-e, na função /XNFE/OUTNFE_CREATE.
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.
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:
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:
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:
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:
att,
Renan Correa
- SAP Managed Tags:
12 Comments
