Escolar Documentos
Profissional Documentos
Cultura Documentos
nota fiscal
FollowRSS feedLike
21 Li kes 23,312 Views 12 C omments
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:
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.
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.
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:
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.
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.
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:
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.
,
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.
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: