Cancelamento de NF-e parado (batch status 05, process status 02)

[eduardohartmann]

Bom dia pessoal,

Ontem tivemos um problema no GRC/PI de um cliente, onde por alguma razão o certificado estava sendo rejeitado. Depois de vários problemas causados por isso, foi resetado o j2ee e o sistema voltou a operar normalmente.

As sequelas disso foram duas notas para as quais foi solicitado o cancelamento, agora elas estão com status de processamento 02 (Sent to Signature Service) e batch status 05 (Result Received).

Seguindo uma orientação para um caso parecido (),

peguei os MsgIDs das mensagens dessas NFs na /xnfe/acknowledg (ambas com SIGNC), encontrei-as no SXI_MONITOR do PI, onde elas são listadas 2x cada, com os seguintes status

1 - Status = Transfer to Process Engine (, Ack. Status = branco

2 - Status = Processed Successfully, Ack. Status = Still awaiting acknowledgment (bola verde com interrogação)

Ao tentar dar restart nas mensagens, recebo a seguinte mensagem de erro:

You cannot restart XML message E07AFA5FD584CEF1B15C3C4A927627EC with this status/type

Message no. XMS_ADM085

Diagnosis

You want to reschedule an XML message that has already been processed (Restart). However, the XML message status or type does not permit a restart.

System Response

You can only restart asynchronous XML messages.

Furthermore, you can only reschedule XML messages with errors. You cannot restart correctly processed XML messages or XML messages with the status Being Processed.

Tem algo que possa ser feito sem ter que alterar tabelas?

Como a equipe responsável pelo PI/GRC fica fora do BR, é bem complicado conseguir autorização para qquer coisa nesse sentido em PRD.

ps.: Agora cliquei no "Expand all messages", para cada um dos MsgIDs, apareceram 2 novas linhas, uma com status = Scheduled (bandeira verde) e outra com status Scheduled for Outbound Processing (seta preta), ambos com o awaiting ack.

=> SMQ1 e SMQ2 ambas sem entradas.

Obrigado!

Eduardo Hartmann

[henrique_pinto · Accepted solution]

Eduardo,

O NFe type = 2 (cancelamento)?

Se sim, me parece que o pedido de cancelamento foi enviado pra assinatura e nao teve resposta, provavelmente devido ao fato de o J2EE estar fora. Nesse caso, o batch status é irrelevante (ele só é relevante pro processo de envio de NFe, não pra cancelamento/inutilização).

O "correto" seria vc identificar onde a mensagem de assinatura parou (i.e. se em alguma fila - SMQ1/SMQ2, se tem q restartar o BPM etc.). Mas como o passo de assinatura é stateless, diferentemente do processamento da SEFAZ, vc poderia simplesmente "marretar" um status de erro de assinatura de cancelamento na /xnfe/nfe_hist (verifique o valor apropriado do error status no domínio do campo) e restartar a assinatura do cancelamento pelo monitor de NFe do GRC, aba de erro de assinatura.

Abs,

Henrique.

[Former Member · Accepted solution]

Oi Henrique,

Sim, o status de processamento é 02... foi enviada a solicitação de cancelamento para assinatura e não teve retorno. O batch status só mandei para confirmar que a NF foi autorizada (status=05).

Lembro que tinha uma fila parada com 2 registros, mas foi eliminada..... Tem algum jeito de recuperar esta info?

Sobre a possibilidade de marretar a tabela, gostaria de evitar essa opção, pois vou passa meio dia justificando a necessidade para os "donos" do GRC/PI.

Se não houver outra maneira por dentro do PI/GRC, vamos ter que partir para o update

Tks,

Eduardo

[henrique_pinto · Accepted solution]

Vixe... Muito provavelmente esses 2 registros eram os pedidos de assinatura dessas 2 notas. 😛

Nao tem como recuperar, por isso que indicamos para NUNCA deletar registro de filas, principalmente em produção. Sempre tente restartar.

Se as mensagens de assinatura tiverem sido realmente deletadas da fila, a marreta passa a não ser só uma opção, mas sim a única solução. Mas como falei, o serviço de assinatura é stateless, ou idempotente (i.e. vc pode reenviar a mesma mensagem N vezes e sempre vai ter a mesma resposta, que é o XML assinado), entao o restart dele nao vai gerar nenhum efeito colateral indesejado (ao contrario de vc restartar na marra o envio do pedido de cancelamento para a SEFAZ).

Abs,

Henrique.

[Former Member · Accepted solution]

Ok... estou pedindo o acesso para update...

Uma dúvida: se eu pegar a mensagem que foi enviada do GRC ao PI, tem como enviá-la manualmente?

Abraço,

Eduardo

[henrique_pinto · Accepted solution]

Tem. Vc pode executar o proxy manualmente pela SPROXY, e daí dá ctrl+v no payload que vc copiou.

Se vc tiver o payload, talvez seja melhor do que o insert manual do status de erro.

Abs,

Henrique.

[eduardohartmann · Accepted solution]

Bom dia Henrique,

Lady Murphy... ao rodar a SPROXY e escolher a interface, quando mando executar a tela fica travada... provavelmente relacionado ao SAPGUI que está instalado aqui (o mesmo acontece se usamos o Editor ABAP novo ao debugar no ERP).

Estamos vendo se conseguimos "destravar" o dito cujo, senão a solução vai ser via update... já solicitei a criação de views de atualização para as tabelas que mais precisamos alterar... vamos ver se passa

Abraço,

Eduardo

[henrique_pinto · Accepted solution]

Tenta via webgui (its):

http://<host>:<porta_abap>/sap/bc/gui/sap/its/webgui

E os serviços /sap/bc/gui/sap/its/webgui e o /sap/public/bc/its/mimes tem que ter sido ativado antes na SICF.

(Mais detalhes na nota https://service.sap.com/sap/support/notes/816973).

A porta abap é, por default, 80xx, onde xx = sys number.

Abs,

Henrique.

[eduardohartmann · Accepted solution]

Oi Henrique,

Pelo Webgui deu certo... claro que não antes de dar erro por falta de acesso (NO_AUTHORITY) hehehe

Depois de conseguir o acesso, funcionou, conseguimos dar sequencia nas assinaturas e o restante funcionou automaticamente.

Valeu a força!!

Abraço,

Eduardo

[henrique_pinto · Accepted solution]

Show de bola!

Abs,

Henrique.