Lote parado no status 3 - Enviado as autoridades

[Former Member]

Bom dia a todos!!

Estou com um problema que tem acontecido muito essas ultimas semanas que e o seguinte.

Algumas notas ficam em processamento com o status 4 (incluido no lote) ao verificar o lote, o mesmo tambem esta em processamento com o status 3 (enviado as autoridades).

Ao tentar consultar a nota no SEFAZ, ela ja esta la, portanto o problema e mesmo na consulta que o PI faz da nota no SEFAZ. O PI nao esta chamando esse processo.

Alguem passou por isso, tem alguma sugestao?

Muito obrigado!

[Former Member · Accepted solution]

Olá Lucas,

Tudo bem?

Seria legal verificar os seguintes pontos:

- Verifique se o job do processo NF-e esta sendo executado corretamente.

- Verifique se na sxj_monitor qual a resposta para as mensagens da interface de busca de status de NF-e?

- Verifique se na sm58 tem algum registro de erro?

Um abraço.

Aguardo seus comentários.

César Sevilha.

[Former Member · Accepted solution]

Beleza Cesar e vc?

Então, dois pontos eu consegui verificar SM58, sem erros e JOB normal, inclusive no dia que deram erro alguns lotes, foram geradas mais de 4 mil notas. Porém no monitor eu não consegui visualizar, pois os casos que eu tinha em PRD (nem DEV nem QAS apresentaram tal erro), já não estão mais em processamento.

Caso curioso, é que quando eu reenviei os lotes eles foram com sucesso, deu apenas o erro de duplicidade, mas após status request a nota ficou ok.

PS: Eu reenviei via R3, eu zerei os campos de status da Active e reenviei via J1BNFE.

Na verdade eu postei aqui para saber se alguém tinha passado por algo parecido.

Att.

Lucas

[Former Member · Accepted solution]

Após aplicar as notas para a versão 2.00 este erro ocorreu duas vezes comigo. Uma delas foi a ultima vez que a SEFAZ MG teve alguns problemas de processamento por um breve periodo na semana passada. Depois nunca mais.

Não tive tempo de analisar pois estava na correria. Simplesmente marquei o lote como erro e reenviei.

Se ocorrer novamente, vou analisar e posto aqui o que achar.

obs: Apesar de já ter aplicado as notas do 2.00, continuo emitindo notas no 1.10

obs2: Já apliquei o SP16 do GRC e praticamente todas notas do SP17 (falta as 3 ultimas que deve ser aplicada junto com a nova nota do SP18 relativo a formação de lotes).

At.,

Bernardo Braga

[Former Member · Accepted solution]

Oi Lucas,

tudo blz tb..

Legal que tudo esta ok.

Em produção nunca tive nada parecido com esse problema mas em QA nos testes integrados da versão 2.0 tivemos algo parecido e nessa ocasião o problema estava na Sefaz, aparentemente ela não estava indisponípivel porem algum bug estava acontecendo. Depois de algum tempo consegui realizar o batch query e tudo funcionou perfeitamente.

Sobre os erros na sm58 era algo sobre "workflow local"?

Att.

César.

[Former Member · Accepted solution]

Fala Cesar!

Então, no dia em que os lotes estavam parados não há erros na SM58, mas hoje por exemplo existem alguns sim como esse que você falou "WORKFLOW_LOCAL_001".

Att.

[Former Member · Accepted solution]

Oi Lucas,

Da uma olhada nessa nota:

Note 1473792 - Temporary error due to processing in tRFC

Acho que pode resolver o problema com o workflow local.

Estava com esse problema na sm58, percebi que os acknowledgment das mensagens não voltavam e verifique que na sm58 algumas coisas realmente ficavam paradas. Essa nota resolveu o meu problema e pode evitar que você tenha problemas futuros com mensagens que dependam que retorno de acknowledgment.

Att.

César Sevilha.

[Former Member · Accepted solution]

Valeu Cesar,

Eu apliquei essa nota, agora é esperar o decorrer da semana e ver se não aparece mais os erros de WORKFLOW.

Hoje antes de aplicar em DEV, verifiquei a PRD e não havia tais erros.

Mas de qualquer forma obrigado pela dica!

Abs.

Bom ano novo!

[Former Member · Accepted solution]

Oi Lucas,

Legal, depois adicione os comentários se o problema com a sm58 foi solucionado.

Um abraço e um ótimo ano novo.

César.

[Former Member · Accepted solution]

Fala Cesar!

Cesar, eu apliquei a nota que você sugeriu e realmente não ocorreram mais aqueles erros de WORKFLOW LOCAL.

Porém o erro inicial dessa thread que são os lotes parados no status 3 voltaram a acontecer.

Relmente já investigamos de várias formas e não tenho uma luz do porquê desses lotes ficarem parados.

Desde já, agradeço!

Att.

Lucas Costa

[former_member193386 · Accepted solution]

Lucas, um dos pontos que vc deveria verificar nesses casos é se aconteceu alguma indisponibilidade do SEFAZ no horario que esses lotes ficaram paradoes. Uma pergunta, esse problema acontece com qual frequencia ?

[Former Member · Accepted solution]

Boa tarde!

Então, pelo que eu vi a SEFAZ estava normal. E inclusive esse issue aconteceu em dias variados e com as SEFAZes de SP e MG. Hoje por exemplo, já fazia algum tempo que não estava acontecendo esse problema, mas ficaram 2 notas de dois lotes diferentes paradas.

Att.

Lucas Costa

[former_member193386 · Accepted solution]

e isso só ocorre no seu ambiente de QA e nao no PRD, certo?

[Former Member · Accepted solution]

Não, ao contrario.

Apenas em PRD.

Att.

Lucas

[former_member193386 · Accepted solution]

certo, o que tem de diferente atualmente seu QA do PRD?

[Former Member · Accepted solution]

No QAS e no DEV estamos com a versão 2.0 que ainda não tem data de Go-Live por causa da SEFAZ do PR que ainda não se adequou.

Mas no mais tardar em março teremos que ter o GO LIVE.

Creio eu, que na versão 2.0 esse problema não ocorra mais. Mas de qualquer forma gostaria de saber o porquê desse problema.

Att.

Lucas

[former_member193386 · Accepted solution]

bem, em dev esta ocorrendo isso ?

[Former Member · Accepted solution]

Não.

Apenas na PRD.

Att.

Lucas

[former_member182114 · Accepted solution]

Bom dia Lucas,

Voltando ao problema original de status 03.

Isto acontece para que Secretaria / serviço / layout?

Atenciosamente, Fernando Da Rós

PS: A uns dias atrás aconteceu um caso na Sefaz SP em que ela reportou lote processado, porém não informou o recibo para o "próximo passo" (layout 1.10)

[Former Member · Accepted solution]

Bom dia Fernando.

Esse erro aconteceu primeiro na SEFAZ SP depois MG, e ontem quando comentei que aconteceu novamente, foi na SEFAZ do PR.

Na do PR eu notei que o status do serviço, que aqui roda a cada 15 min o job de verificação de status, ficou fora por 15 min. Talvez tenha haver essa indisponibilidade com o erro.

Na produção estamos com a versão 1.10.

Att.

Lucas

[former_member182114 · Accepted solution]

Bom dia Lucas,

Poderia coletar exemplos da resposta da Sefaz para estes casos em que fica parado (payload da BATSR*IB)?

Talvez seja um novo "tratamento" que o GRC esteja precisando.

Atenciosamente, Fernando Da Ró

[Former Member · Accepted solution]

Oi Lucas bom dia,

Tudo blz?

Legal que o erro na SM58 não esta mais acontecendo, agora precisamos fechar esse problema com o lote.

Seria legal verificar na sxi_monitor no dia e na hora que ocorreu o problema a resposta da mensagem do lote, talvez lá tenha algo mais detalhado para analisarmos.

O seu job para validar o status da Sefaz esta rodando de 10 em 10 minutos? Se você verificar o status da Sefaz pelo monitor do GRC irá ver o status da Sefaz dos ultimos 10 minutos, seria legal verificar a resposta das mensagens de consulta de status da Sefaz na hora do problema pela sxi_monitor para ter certeza que o problema realmente não esta na Sefaz.

Como o Calos disse é necessário verificar a diferença entre os ambiente já que isso esta ocorrendo somente em PROD.

Abs.

César.

[Former Member · Accepted solution]

Fernando,

O problema é que os lotes que estavam parados já foram reenviados.

A solução que eu encontrei para que essas NFes não ficassem paradas e que funcionou foi:

1- Excluir a nota e o lote gerado do PI

2- Voltar o status da nota (via marreta) no R3

3- Reenviar a nota.

Como a nota já estava na SEFAZ, vai voltar com o erro de duplicidade, mas aí é só dar o status request.

Assim, essa é uma medida paleativa que aqui no cliente onde estou, necessita de mais de uma pessoa envolvida, uma vez que eu não tenho nem acesso ao R3 PRD, muito menos à se38 para rodar o programa marreta. Por esse motivo, e por muitos outros que todos sabemos, quero mesmo é achar a solução para a raiz do problema.

Das primeiras vezes que deu esse problema eu verifiquei o SXI_MONITOR e nada tinha de anormal.

Att.

Lucas

[Former Member · Accepted solution]

Beleza Cesar e vc?

Então, em PRD estamos emitindo na versão 1.1, e DEV e QAS em 2.0.

Mas mesmo, que estivessem iguais creio que seria dificil simular esse problema.

Em PRD geramos em torno de 5 mil notas dia. E desse montante tiramos esse problema em mais ou menos uns 3 ou 4 lotes em dias distintos e alteranados.

Att.

Lucas

[former_member182114 · Accepted solution]

Bom dia Lucas,

Este que é o problema... rsss

A resposta da Sefaz é recebida e processada sem problemas, ou seja, não tem erro técnico que fique explítico e ao que parece o GRC não está tratando esta "novidade".

Da próxima vez que acontecer pegue o payload do BATCH*IB (tinha escrito BATSR, mas o correto é a interface de envio) e poste por aqui para analisá-lo.

Atenciosamente, Fernando Da Rö

[Former Member · Accepted solution]

Pessoal,

Eu gostaria muito de passar mais informações,

mas realmente não possuo.

Vou esperar acontecer novamente e procurar novamente.

Mesmo assim agradeço a ajuda de todos.

Att.

Lucas

[Former Member · Accepted solution]

Fernando,

Então, não ocorre o erro até o SEFAZ, mas mesmo assim o ciclo do processo não fecha.

"Legalmente falando" está OK, pois nós mandamos a nota para o governo.

Porém, no R3 o usuário não consegue sequer imprimir o DANFE, pois a nota no R3 fica em processamento.

E na verdade, eu acho que vc tinha escrito correto sim, o serviço que eu acho que não está sendo acionado pelo PI é o BATSR.

Pois os lotes param no status 3 que é o "enviado as autoridades" se eu não me engano, e o próximo passo seria mesmo o BATSR, que é a consulta do status do lote no SEFAZ. Se não estou enganado.

Assim que eu conseguir algo de mais concreto eu posto aqui para todos, porque confesso que está muito "nebuloso"...rs Sem as informações.

Att.

Lucas

[former_member182114 · Accepted solution]

Bom dia Lucas,

Sem problemas Lucas, e obrigado pelo esforço de prover os detalhes. Aguardaremos quando acontecer novamente.

Do PI a interface é a BATCH mesmo, porém a mensagem BATCH*IB (resposta da Sefaz) ou mesmo a resposta sincrona caso você faça log. Só existiria o BATSR para status 04.

Atenciosamente, Fernando Da Ró