Manifestação do Destinatário só funciona para Ciência da Operação

[eduardohartmann]

Caros, bom dia!

Estamos com um problema em um cliente onde 3 dos eventos do MD-e não funcionam, apenas a Ciência da Operação está sendo autorizada corretamente. Estamos com o SP19 e até onde consegui apurar/testar, temos o seguinte resultado:

Event Name	Event Type	Sender Interface	Sender Namespace	Status
Operation Acknowledgment	210210	EVENT_OPPRG_OperationProgress_OB	http://sap.com/xi/NFE/006	Authorized
Operation Confirmation	210200	EVENT_nfeRecepcaoEvento_OB	http://sap.com/xi/NFE/008	Error from PI
Operation Denial	210220	EVENT_nfeRecepcaoEvento_OB	http://sap.com/xi/NFE/008	Error from PI
Operation Terminated	210240	EVENT_nfeRecepcaoEvento_OB	http://sap.com/xi/NFE/008	Error from PI

Para os 3 eventos ccom erro, o status no monitor de eventos fica assim:

No monitor de lote de eventos:

E o retorno do PI (erro no Acknowledgment):

Estou achando que o problema é com a interface usada para os 3 com erro (EVENT_nfeRecepcaoEvento_OB), verifiquei a documentação (SAP Nota Fiscal Eletrônica (SAP Electronic Invoicing for Brazil) - SAP Library) onde menciona as interfaces (também consultei diversos threads, entre eles Cenarios no PI para Manifestação Destinatário e Monitor Portaria

e NFe Mainifesto - Confirmação da operação - onde menciona que o EVENT_OPPRG não deveria ser usado, porém também consta que o cenário do MD-e não foi alterado (não tem correspondente no namespace 008).

No programa que cria os lotes de evento (/XNFE/EVENT_BATCH_SEND) é chamada a FM /XNFE/EV_BAT_BATCH_SEND, que testa se for versão 2.00, envia para interface 006 (chamada opco_batch_send):

E se for versão 3.10 envia para 008:

Procurei notas para o programa, includes e FMs envolvidos, não encontrei nada que pareceu relevante.

No cenário que estamos testando, buscamos a lista dos documentos do webservice de distribuição, em seguida é feita a ciência (automaticamente) e depois tentamos emitir os demais eventos, porém sem sucesso.

Tenho a impressão de a diferença de interfaces está relacionada com o campo /XNFE/EVENTS-XMLVERSION_RDOC não estar preenchido na emissão da Ciência da Operação, enquanto para os demais eventos este campo está preenchido com 3.10.

Alguém tem alguma indicação, seja se estamos com erro de configuração ou de programas?

Se tiverem exemplo de MD-e funcionando no SP19, poderiam compartilhar também se está funcionando com o webservice de DF-e?

Obrigado!

Abraços,

Eduardo Hartmann

[former_member182503]

Eduardo,

O erro de negative acknowledgement no ccBPM pode ser referente a erro de mapping.

A mensagem que está falhando e gerando o negative ack no PI é referente ao namespace 008? Se sim, você consegue ver pelo trace da mensagem qual foi o erro no mapping, ou ainda, você pode copiar o payload e tentar executar o interface mapping diretamente no repository e ver qual erro ocorre.

[]'s

JN   

[eduardohartmann]

JN,

Esse cliente tem uma complicação, o PI é acessível apenas "remotamente" (preciso documentar tudo e pedir para o time responsável fazer e me retornar).

Antes de seguir nessa linha, esqueci de comentar uma coisa: forcei a saída do evento de confirmação pelo namespace 006 e funcionou corretamente - foi autorizado.

Aí fica a pergunta que entendo ser a primeira a ser confirmada: está correto usar a interface EVENT_nfeRecepcaoEvento_OB para esses eventos do MD-e?

Se sim, avanço no ponto do mapping com o time de PI, se não, entendo que o problema é ainda no GRC, na criação da mensagem. Concorda?

Obrigado, abraço!

[former_member182503]

Eduardo,

Realmente, relendo sua análise e comparando com as mensagens do meu ambiente produtivo, me parece que existe um erro no código standard do SAP NF-e com relação ao envio automático do evento de Ciência da Operação.

Debugando, achei a possível causa do problema:

O programa /XNFE/COLLECT_DOCUMENTS faz a leitura dos documentos que não constam no sistema. Após encontrá-los, ele envia automaticamente o evento de ciência da operação através da função /XNFE/NFELIST_TRIGGER_OPAC.

A função /XNFE/NFELIST_TRIGGER_OPAC por sua vez, executa a função /XNFE/EVENT_OPPRG_CREATE, responsável pela criação do evento.

Dentro dela, a primeira coisa executada é a função  /XNFE/B2BNFE_READ_NFE_FOR_UPD, que nada mais é do que a leitura da NF-e de entrada. Esta função não encontra nada no banco de dados e por isso retorna o exception NFE_DOES_NOT_EXIST.

Se a exception for NFE_DOES_NOT_EXIST e o tipo do evento for 210210 ou 210220(ciência ou desconhecimento), ele permite que seja feito através dos dados da nota recebida, sem ela ter que existir em banco(/XNFE/INNFEHD).

Continuando, ele executa a função  /XNFE/NFELIST_READ_WO_LOCK para ler os dados oriundos do processo NFELIST para esta nota. Após a leitura ele faz um move para a estrutura ls_innfehd, mas sem passar o campo xmlversion [aqui está o erro].

Mais para a frente, existe um IF ls_innfehd-xmlversion IS NOT INITIAL. Aqui, ele cai no ELSE, que chama a função  /XNFE/EV_OPPRG_TRANSFORM_OUT. Esta função preenche a estrutura ls_event sem valor no campo xmlversion_rdoc.

Daqui pra frente, a sua análise completa o serviço.

Resumindo:

Quando o evento de Ciência da Operação é disparado pelo job /XNFE/COLLECT_DOCUMENTS, ele desconsidera a versão do XML e acaba gerando uma mensagem na interface EVENT_OPPRG_OperationProgress_OB do namespace http://sap.com/xi/NFE/006, mesmo quando a NF-e contida nela é da versão 3.10.

MAAAAAAAAAAAAS não é isso que gera erro nos demais eventos!

Aqui o meu cenário está exatamente igual ao seu, com a diferença que os demais eventos funcionam. O seu problema está no PI.

Quanto ao erro de PI nos demais eventos:

O Negative Acknowledgement pode ser por erro de comunicação ou por erro de aplicação.

Aplicação:

Confira se o Interface Determination está usando o mapping correto. Veja também se executando o Operation Mapping na mão com o payload em questão gera algum tipo de erro. Confira também o trace da mensagem.

Comunicação:

Revise os canais de comunicação envolvidos, dê uma olhada no communication channel monitoring para os canais para ver se existe alguma atividade.

[]'s

JN

[eduardohartmann]

JN,

Valeu pelas indicações e pela investigação!! Vou pedir os detalhes para o time de PI e retorno aqui ASAP.

abs,

EH

[eduardohartmann]

Faltou responder seu questionamento lá no começo: sim, o NACK ocorre com a interface no namespace 008.

[eduardohartmann]

Para registro, esse problema foi resolvido.

Infelzimente não tenho os detalhes mais, pois foi uma interminável discussão onde insistiam (PI) em dizer que era "temporary connection issue" e não aceitavam que o problema era configuração no PI.

Após centenas de idas e vindas, reaplicação de notas, importação de XI content (inclusive aqueles de PR e BA), passou a funcionar. Atualmente estamos conseguindo fazer a emissão de todos os eventos do MD-e.

Abs,

EH