cancel
Showing results for 
Search instead for 
Did you mean: 

GRC: Batch com status Request Sent parados

Former Member
0 Kudos

Olá Pessoal,

Um lote ficou parado com status 04 - Request Sent. O erro ocorreu no PI (No receiver could be determined) na interface de Batch Request. Ajustei a configuração para reenviar o lote no entanto no GRC não constava erro do PI e o lote permaneceu com status de Request Sent. Procurei alguma fila parada na SMQ1/SMQ2 no GRC e PI e não encontrei nada.

Só conseguí sair do impasse e fazer o reenvio do batch request quando fui na tabela /XNFE/BAT_HIST e alterei o registro mais recente forçando o '40' no STATUS_ERROR.

Estamos no SP13, gostaria de saber se isso é um bug ou se deixei de verificar alguma coisa no GRC / PI.

Desde já agradeço,

Daniela Machado

Accepted Solutions (1)

Accepted Solutions (1)

former_member182114
Active Contributor
0 Kudos

Bom dia Daniela,

Nas versões atuais do GRC é raríssimo a necessidade de intervenção em tabela, no seu caso após a correção dos receivers, você deveria restartar a mensagem no XI para seu correto término pois era uma situação não de erro final e sim temporária.

Entretanto tem casos onde somente acertando / reconstruindo os dados das tabelas é possível prosseguir, como uma falha de banco de dados.

Para os casos como falha na Sefaz e entre sistemas, é provável que os jobs de housekeeping não estejam corretamente configurados no sistema, ou o número de tentativas deles até a solução (intervenção manual) não foi suficiente, tem opções no XI/PI para o restart nos vários níveis onde o problema pode ocorrer (mensagem, queue, acknowledgment, BPE...).

Em resumo, quando a situação está em 02 ou 06 para NF-e, ou 02 ou 04 para batch e não há erro significa que o problema está por conta do PI e deve ser resolvido por lá.

Se precisar de apoio para identificar a causa raiz e como sair da situação abra um chamado para SLL-NFE para investigação, se acostumar com a marreta provavelmente terá que usá-la esporadicamente em PRD, o que não é correto.

Atenciosamente, Fernando Da Rós

-

-


PS: Esqueci de comentar, quando em caso de "adequar" os status fazer conforme o Carlos comentou, deixando o máximo de rastro possível. Quando uma investigação a posteriori é necessária é importante saber que aconteceu alguma intervenção externa.

Edited by: Fernando Ros on Jun 4, 2010 5:02 PM

Former Member
0 Kudos

Bom dia Da Rós,

Muito obrigada pela resposta.

Eu tentei dar um restart na mensagem de erro via SXMB_MONI e também na request inicial que ficou com o aknowledgement "waiting" mas, não sei se por configuração do ambiente de PI no cliente ou não, apareceu mensagem de erro que eu não poderia dar um restart numa mensagem com esse status. Pedi um help para o administador do PI no cliente e ele me informou que normalmente erros de Receiver Determination normalmente não podem ser reprocessados por serem categorizados como "system error". Isso procede? Há alguma configuração no ambiente que trava esse restart da mensagem para que eu não ficar refém da marreta em casos semelhantes?

Desde já agradeço,

Daniela

henrique_pinto
Active Contributor
0 Kudos

Daniela,

vc nao consegue restartar a msg pq eh uma msg sincrona, nao tem a ver o fato de ser system error.

Msg sincrona, por definicao, se teve erro no momento da execucao isso deve ser repassado pra aplicacao requerente para tratamento na aplicacao (daí a necessidade do ack).

Pode ser que o ack nao tenha voltado por falta ou falha da configuracao do communication channel do tipo XI Receiver.

Você já efetuou essa configuracao? A HTTP Destination que está sendo utilizada está funcionando corretamente?

Note que o ack é considerado como uma msg assincrona de volta do PI pro app system requerente (no caso, o GRC), e portanto precisa que esta configuracao esteja ok já pra voltar.

Vc consegue ver se teve erro de ack indo na msg original na SXMB_MONI do PI (nao a msg sincrona, mas a 1a msg assíncrona que veio do GRC pro PI); do lado esquerdo, no pipeline, se tiver erro vc vai ver algum simbolo de erro pro ack voltar.

Abs,

Henrique.

former_member182114
Active Contributor
0 Kudos

Bom dia Daniela,

Henrique explicou tudo, inclusive bem melhor que eu.

Eu disse em termos do restart, mas esqueci que as vezes não é o problema do restart em si e sim um ACK NEG que não chegou na parte ABAP.

Se o ACK NEG chegar, então o GRC atualiza o ERROR_STATUS e é possível o restart pela interface.

Atenciosamente, Fernando Da Ró

Former Member
0 Kudos

Henrique / Da Rós,

Pelo que estou percebendo, o problema está no fato do ack não ter voltado para o GRC abap.

Na moni, a mensagem original (BATSR_nfeRetRecepcao_OB) está com um "?" e status de "still awaiting acknowledgement" na coluna Ack. Status.

Sobre a configuração do CC XI Receiver que você comentou Henrique, acredito que está tudo ok porque com excessão desse envio do Batch Request, os outros passos onde o GRC é atualizado funcionou normalmente, como a atualização do monitor com o status de processamendo da Sefaz depois que eu conseguí reenviar a requisição do lote.

Uma coisa que reparei na MONI, no gráfico do BPM, é que parece que os Exceptions não foram disparados, apesar do erro no Receiver Determination, pois as setas verdes foram até o step "Merge nRec from request with response message" e pararam por aí. Isso pode ter relação com a configuração de Alertas? Pois eu ainda não as configurei aqui.

Att,

Daniela

former_member182114
Active Contributor
0 Kudos

Bom dia Daniela,

Vamos dizer que está parado pq nenhuma informação final chegou no GRC, esta informação pode ser uma auth/reject da Sefaz ou então um ACK Negative. Esta bola verde com interrogação fica no lado GRC esperando, e do lado PI tem que estar acontecendo algo, ou é restartável ou é falha ao enviar o ACK.

A propósito, só este processo está com a bola verde interrogativa ou todos os outros?

Encontram-se também ACK's Ok (carimbo verde) ou negativos (carimbo vermelho) ?

Sua tabela /xnfe/acknowledg está com muitos registros ?

Você está com o PI 7.1?

Configurou o alerta NFE_ALRT_CAT conforme abaixo?

http://help.sap.com/saphelp_grcnfe10/helpdata/en/6c/b208d6770843988e47593a99165210/frameset.htm

Atenciosamente, Fernando Da Rós

Edited by: Fernando Ros on Jun 4, 2010 8:46 PM - Correções de Português e clareza da resposta

Former Member
0 Kudos

Oi Da Rós.. segue as respostas:

A propósito, só este processo está com a bola verde interrogativa ou todos os outros?

Daniela: Sim, apenas este processo onde eu tive erro no Receiver Determination. Assinatura, Envio de Lote e o Request Lote (que reenviei depois do erro corrigido) estão com o carimbo no Ack.

Encontram-se também ACK's Ok (carimbo verde) ou negativos (carimbo vermelho) ?

Daniela: Apenas ACK's Ok, ainda há poucas execuções no ambiente porque os testes funcionais só começam segunda e eu enviei algumas notas para validar a comunicação. ACK's negativos ainda não existem.

Sua tabela /xnfe/acknowledg está com muitos registros ?

Daniela: Pouquíssimos, não chegam nem a dez (como disse os testes funcionais não começaram ainda).

Você está com o PI 7.1?

Daniela: Sim, PI 7.1

Configurou o alerta NFE_ALRT_CAT conforme abaixo?

http://help.sap.com/saphelp_grcnfe10/helpdata/en/6c/b208d6770843988e47593a99165210/frameset.htm

Daniela: Ainda não configurei o alerta.

Mais uma vez obrigada,

Daniela

former_member182114
Active Contributor
0 Kudos

Bom dia Daniela,

É provável que a falta do alerta esteja causando este problema, "descobrimos" em um cliente tempos atrás que ocorreu uma mudança no PI 7.1 que gera uma exception no processamento do BPM quando é para gerar um alerta e este não existe. Isto é uma mudança de comportamento em relação ao PI 7.0 que a equipe de PI está revendo, pois a princípio não deveria dar este erro.

O que a equipe de desenvolvimento do PI sugeriu é que criassemos este alerta quando PI 7.1 e o problema é eliminado.

Por favor, crie o alerta conforme o help.sap, recrie a situação de erro do no receiver, e faça um novo teste. Um ACK NEG tem que chegar no GRC e sua situação na interface ir para Erro PI, podendo ser restartado no monitor web dynpro do GRC NFE.

Quanto à tabela /xnfe/acknowledg esta deve estar sempre com ZERO registros se não tem nada no PI, claro que o sistema ainda está com coisas que não estão voltando, depois que resolver esta questão do 04 de forma automática, limpe esta tabela e monitore-a para não deixar registros parados aí.

Faça o teste e nos dê feedback.

Atenciosamente, Fernando Da Ró

Former Member
0 Kudos

Da Rós,

Vou configurar o alerta e recriar a situação de erro.

Darei o retorno o mais breve possível.

Att,

Daniela

Former Member
0 Kudos

Da Rós,

Você está certo, a falta do alerta causa esse problema no PI 7.1.

Eu configurei a categoria de alerta e recriei o erro (no Receiver Determination). Resultado: CommunicationException disparado no BPM, ACK NEG gerado e lote no GRC com ERROR_STATUS = 40 (sem nenhuma ação manual :-DDD).

Problema resolvido!

Muito obrigada pela ajuda.

Att,

Daniela

Answers (1)

Answers (1)

former_member193386
Active Contributor
0 Kudos

aparentemente sim, tive o mesmo problema e realizei um processo parecido, a unica diferenca foi que eu criei um linha nova e nao alterei a ultima, é importante manter o historico o mais realista possivel. Comigo ocorreu por uma falha de comunicacao com o sefaz, a nfe já havia inclusive sido criada