Após HTTP_TIMEOUT, como reprocessar os CTe´s

[eduspg]

Pessoal, bom dia.

Estou com alguns CTe´s parados e com status de enviado no monitor do GRC, porém os logs na SXMB_MONI consta um erro de HTTP_TIMEOUT.

Gostaria de saber como faço para reiniciar ou restartar estes CTe´s?

Obrigado, Eduardo Cordeiro.

[former_member182114 · Accepted solution]

Bom dia Eduardo,

O esperado é que o processo no monitor caia em erro e você só precise reiniciar o lote de CT-e pelo monitor. Quais os status do lote no monitor?

Atenciosamente, Fernando Da Rós

[eduspg · Accepted solution]

Fernando, grato pelo retorno.

O lote fica status de documento: "Esperando Resposta" e o status da comunicação "Enviada ao Sistema de Mensagem".

Pelo fato do documento ter ficado bastante tempo com o mesmo status, acabei olhando no PI o motivo e lá constava o erro de HTTP_TIMEOUT.

Att, Eduardo Cordeiro.

[former_member182114 · Accepted solution]

Bom dia Eduardo,

Estou suspeitando que não os acknowledgments não estão fluindo ou sendo processados corretamente.

Neste processo no XI, você vê o NEGATIVE_ACKNOWLEDGMENT gerado?

Verifique se o CT-e está na tabela /xnfe/acknowledg, a propósito quantos registros tem na tabela?

Verifique se o report /xnfe/get_acknowledgment está escalonado (intervalo 1 minuto).

Atenciosamente, Fernando Da Rós

[eduspg · Accepted solution]

Boa tarde Fernando.

Não foi gerado o NEGATIVE_ACKNOWLEDGMENT e a tabela /xnfe/acknowledg não possui nenhuma ocorrência, ou seja, todos os processos foram "limpos" da tabela.

Você sabe me dizer como eu faço para reprocessar este documento que ficou parado no PI? Existe alguma ferramenta para tal caso?

Obrigado, Eduardo.

[rhviana · Accepted solution]

Eduardo ,

Esse erro esta mais suspeito para erro ou senha do usuario de comunicação provavelmente (proxy) invalida.

Http_timeout. 401 ? 403 ? 500 ?

Você já fez um check das comunicacões entre o PI e o GRC ?

Att,

Ricardo Viana.

[eduspg · Accepted solution]

Ricardo, boa tarde.

Muito obrigado pelo retorno.

Eu fiz os testes de comunicação e ocorreu tudo certo, visto que o erro é intermitente e no momento dos testes não ocorreu.

Uma outra característica que notei é que na maioria dos erros os lotes estão com tamanho máximo (50 Ct-e´s por Lote) e em lotes menores tudo ocorre perfeitamente.

Erro ------------------------

<SAP:P1>402</SAP:P1>

<SAP:P2>ICM_HTTP_TIMEOUT</SAP:P2>

Att, Eduardo

[rhviana · Accepted solution]

Eduardo boa noite,

Então acredito que encontrei a resposta do seu ICM_HTTP_TIMEOUT.

Provavelmente esses lotes que não estão conseguindo fechar com o número máximo de CTe´s está ocorrendo o estouro do tempo da conexão aberta.

Pede para o seu basis verificar o tempo de timeout das conexões HTTP com ICM, favor, verificar link abaixo também:

Página 7.

http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/c059d583-a551-2c10-e095-eb5d95e03...

Suba o valor de timeout ou reajuste a quantidade de CTe´s/Lote.

Atenciosamente,

Ricardo VIana.

[henrique_pinto · Accepted solution]

Oi Eduardo,

o erro em nao voltar pro GRC está justamente em nao gerar esse neg ack.

Tem que se entender porque o mesmo não foi gerado.

Se você abre o detalhe da msg assíncrona GRC -> BPM na SXMB_MONI do PI, vc nao tem uma entrada abaixo dela (como se fosse uma resposta) com erro?

Vc pode tb tentar entrar no log gráfico do BPM (workflow graphic log) clicando em "PE" na coluna de Receiver da msg assíncrona GRC -> BPM, e ver se houve algum erro na geração do negative ack (é uma linha de exception no BPM).

O alert category NFE_ALRT_CAT foi criado corretamente na ALRTCATDEF?

Abs,

Henrique.

[eduspg · Accepted solution]

Ricardo, obrigado pelo retorno.

Como tentativa vou solicitar ao BASIS que aumente o tempo de TIMEOUT, pois a composição de CTe´s por lote é fixa em 50, desta forma não há como diminuir.

Obrigado pelo retorno e logo que efetuarmos mais testes eu atualizo o post com o novo comportamento.

Att, Eduardo Cordeiro.