BATCH STATUS 3 - Enviado ao SEFAZ e depois o lote fia parado

[former_member193386]

Pessoal

Estou tendo um erro em ambiente produtivo com o SEFAZ CE que é o seguinte, o processo corre corretamente de alguns lotes porém quando eles chegam no status 3, nao há erro nem nada, o lote fica parado e nao vai para o status 04 para solicitar o retorno do Sefaz

Alguem já passou por isso ?

P.S.: trata-se de um problema intermitente, nao esta ocorrendo com todos os lotes.

Edited by: Carlos Rodrigo Pereira on Sep 2, 2010 5:35 PM

[Former Member · Accepted solution]

Sim. Acontece comigo tambem Ainda nem tive tempo de analisar.

E não só com SEFAZ CE. Com qualquer uma. Principalmente em momentos de pico de processamento ou fechamento de mês.

Mas não é frequente.

Eu estou no SP13 PRD.

At.,

Bernardo Braga

Edited by: Bernardo Braga on Sep 2, 2010 8:01 PM

[former_member193386 · Accepted solution]

Bem, eu analisei aqui e parece que isso só está ocorrendo com uma filial ( por mais bizarro que pareca ) estou acompanhando e vendo se consigo identificar o porque isso ocorre, se eu verifico a nfe no sefaz que esta dentro do lote ela foi recebida e autorizada, porenquanto estou fazendo um "workaround" ( lê-se marretando ) a NFE_HIST mudando o status do LOTE para 04 e erro 40 reenviando o pelo monitor, mas isso nao pode ser a unica solucao, se alguem mais tiver mais alguma informacao eu agradeco.

[henrique_pinto · Accepted solution]

Pra isolar se o problema é no tratamento do retorno do envio ou no processamento da verificacao:

1) Esses lotes que ficam parados, estao sendo gravados com process = 'X', apos o update pra status 03?

2) Há algum log de erro de update no DB (SM14 ou outros)?

3) Há algum erro no inbound proxy de retorno do envio do lote?

4) Há alguma fila parada/desregistrada, na SMQ1 ou SMQ2, no PI e no GRC?

Abs,

Henrique.

[former_member193386 · Accepted solution]

todas as respostas negativas, é isso que estoua chando estranho, e o pior, aprece que acontece apenas com uma filial da empresa mas estou monitorando isso

[former_member193386 · Accepted solution]

bem pessoal, aparentemente resolvi o problema, pode ser um bug, mas essa filial eu diminui o tempo de espera para montar o lote nas configuracoes de lote do GRC para 5 segundos, antes estava em 10, aparentemente o processo entrava em looping ou se perdia de alguma maneira

[former_member182114 · Accepted solution]

Bom dia Carlos / Bernardo,

Este comportamento não parece ser um comportamento externo, verifiquem os jobs de PI se estão corretamente ativados e no client correto. Se precisar de ajuda abre um chamado no SLL-NFE.

@Carlos,

Este tempo de 10 para 5 segundos que reduziu é para o fechamento de lote? Se for isto pode provocar menos NF-es por lote e isso por si só pode gerar mais "serviço" para o sistema causando mais problemas nos momentos de pico. Quantas NF-es seu sistema emite por dia?

Atenciosamente, Fernando Da Ró

[former_member193386 · Accepted solution]

essa filial emite poucas nfes no dia, sem problemas com isso, todas as filiais juntas estao emitindo um pouco mais de 100 notas diarias e essa especificamente esta emitindo umas 10 a 20 notas dias, nada significativo

[former_member182114 · Accepted solution]

Bom dia Carlos,

Com este volume pequeno geral pode deixar 5 segundos para fechamento do lote sem linha específica para nenhum CNPJ.

Independente disso não existe ligação desta configuração interna com problemas na Sefaz.

Poderia colar o histórico de um lote destes (/xnfe/bat_hist)?

Atenciosamente,

Fernando Da Rós

PS: Independente do volume de notas, o tempo de segundos para reconsulta não deve ser inferior a 60 segundos.

[former_member193386 · Accepted solution]

Fernando, posso tentar correr atras de um mas nao vai ter nada de anormal, digo isso porque eu mesmo vi, o /xnfe/bat_hist simplesmente vai até o status 3 e para, o que eu fiz para marretar o problema foi gerar mais uma linha, ja que conferi e a nota estava no sefaz, com o status 4 e erro 40, assim pude reinicializar o processo pelo proprio monitor do grc.

Olhei todos os logs do sistema e nao vi erro nenhum a considerar, por isso eu afirmo que era uma coisa BIZARRA, ainda mais quando eu diminui o tempo do lote resolveu. Cheguei a pensar que era um problema até do SEFAZ que se perdia mas creio que nao seja, uma das coisas que eu pensei hoje de manha vindo para o trabalho é que poderia ser tbem um tempo muito curto de timeout de alguma configuracao de ambiente, e por algum motivo esse processo demorar muito aguardando e me gerar um dump mas ai estaria um log na st22 o que nao ocorria.

[Former Member · Accepted solution]

Ocorreu novamente ontem a noite. Veja Historico do lote que estranho: 1,2,3,4,3 ? (obs.: Não houve ação "manual" na tabela. A nota foi faturada as 21:25:50)

ERTIME BATSTAT ERROR_STATUS

20.100.903.002.550,9377170 01

20.100.903.002.551,1592550 02

20.100.903.002.605,7585340 02 36

20.100.903.003.237,9847600 02

20.100.903.003.309,9061330 02

20.100.903.003.310,7763320 03

20.100.903.003.312,2902060 04

20.100.903.003.344,3007990 03

obs.: Marreitei agora (depois deste log acima via nova linha 4 40)

At.,

Bernardo Braga

Edited by: Bernardo Braga on Sep 3, 2010 1:48 PM

[former_member193386 · Accepted solution]

estranho né Fernando, nenhum erro.

[Former Member · Accepted solution]

Chamado aberto: 722052 / 2010

[former_member182114 · Accepted solution]

Bom dia Carlos,

Tá explicado:

20.100.903.003.237,9847600 02

20.100.903.003.309,9061330 02

20.100.903.003.310,7763320 03

20.100.903.003.312,2902060 04

20.100.903.003.344,3007990 03

O lote estava parado no monitor de lote, então um usuário precisou fazer o restart dele para voltar a rodar.

Repare que tem dois processos sendo reiniciados:

20.100.903.003.237,9847600 02

20.100.903.003.309,9061330 02

Então a interface BATCH foi enviada duas vezes ao PI, ou seja quas entregas à SEFAZ:

20.100.903.003.310,7763320 03

20.100.903.003.344,3007990 03

O "problema" acontece quando o primeiro lote entregue volta da Sefaz

20.100.903.003.310,7763320 03 <--- RECIBO DA PRIMEIRA ENTREGA

20.100.903.003.312,2902060 04 <--- MANDOU CONSULTAR O STATUS NA SEFAZ E MUDOU O PROCESS PARA R

20.100.903.003.344,3007990 03 <--- RECIBO DA SEGUNDA ENTREGA SOBREESCREVEU O RECIBO ANTERIOR, esta entrega "nova" com certeza terminará em 204. E o processo para pois lote 03 com process = R o job não pega por achar que já foi pedido, mudando o process para X vai acontecer o 04 e 05.

Além disso, o BATSR iniciado pelo status 04 voltará na interface porém o GRC não encontrará mais o lote daquele recibo poooois foi sobreescrito com o segundo 03.

Bom, essa é a explicação !!! Agora o que rolou pra fazer isso é no seu sistema.

Por acaso você tem algum job de restart automático Z? Os locks para evitar duplicidades estão lá?

Lembro que em outra thread quando discutimos isso para apoiar uma colega falei bastante deste ponto.

Mesmo no processo Z, tem um novo "buraco" que acontece em sistemas altamente sobrecarregados corrigido agora pela SAP Note 1496066 para o SP16. Agora não me lembro exatamente, mas acho que este tratamento foi implementado a partir do SP11 ou 12. Well de qualquer forma não importa todo mundo vai mesmo pro SP15/SP16.

@Carlos / Eduardo,

Com base nisso dêem uma investigada no seu sistema e dê feedback aqui. Às vezes foram dois usuários diferentes, ou um usuário online e o job...

Atenciosamente, Fernando Da Ró

[former_member193386 · Accepted solution]

Isso no caso do Bernardo, no meu, fica parado no 3 e nao faz nada por horas

100 000000000000085 20.100.902.181.726,2510000 01 PISUPER

100 000000000000085 20.100.902.181.726,3140000 02 PISUPER

100 000000000000085 20.100.902.181.730,3920000 03 PISUPER

100 000000000000085 20.100.902.182.040,1670000 04 PISUPER

100 000000000000085 20.100.902.181.730,3920001 04 40 PISUPER

100 000000000000085 20.100.902.182.042,9170000 05 PISUPER

Acima um exemplo, quando ficou parado no status 3 o qu eu fiz, criei uma nova linha com status 04 e erro 40 e reinicializei pelo monitor do grc ai o processo seguiuu normalmente criando um novo status 04 ( sem erro ) e depois o 05 retornando o status para o ECC.

Edited by: Carlos Rodrigo Pereira on Sep 3, 2010 2:51 PM

[former_member182114 · Accepted solution]

Bom dia Carlos,

Você diz não ter encontrado nada com erro, isto me parece falta de algum dos jobs de housekeeping.

Verifique na lista abaixo de os jobs estão corretamente implementados:

http://help.sap.com/saphelp_nw70/helpdata/en/cd/20bc3ff6beeb0ce10000000a114084/content.htm

SWWERRE, SWWDHEX, SWEQSRV e SWWCLEAR no client PI

RSXMB_RESTART_MESSAGES em ambos os clients (GRC e PI).

Sempre tem um motivo por isto acontecer, não é normal em SP15 precisar destes workarounds.

Por favor, se os jobs estiverem ok, abra um chamado para SLL-NFE para investigação.

Atenciosamente, Fernando Da Ró

[Former Member · Accepted solution]

Realmente dois usuários distintos reenviaram

20.100.903.002.550,9377170 01 XXX

20.100.903.002.551,1592550 02 XXX

20.100.903.002.605,7585340 02 36 XXX

20.100.903.003.237,9847600 02 Usuario1

20.100.903.003.309,9061330 02 Usuario2

Porém não temos nenhuma outra forma de reenvio de lote que não seja pelo monitor GRC.

At.,

Bernardo Bratga

[Former Member · Accepted solution]

Realmente dois usuários distintos reenviaram

20.100.903.002.550,9377170 01 XXX

20.100.903.002.551,1592550 02 XXX

20.100.903.002.605,7585340 02 36 XXX

20.100.903.003.237,9847600 02 Usuario1

20.100.903.003.309,9061330 02 Usuario2

Porém não temos nenhuma outra forma de reenvio de lote que não seja pelo monitor GRC.

At.,

Bernardo Bratga

[henrique_pinto · Accepted solution]

Oi Bernardo,

vcs já aplicaram o SP15?

O lock para evitar o reenvio de lote por usuarios diferentes em paralelo foi implementado em algum SP nao tao recente mas tb nao veio de cara. Se vc tiver num SP antigo, pode ser a causa.

Abs,

Henrique.

[former_member193386 · Accepted solution]

nesse projeto especificamente ainda é sp14 ( O MEU O DO BERNARDO EU NAO SEI )

[henrique_pinto · Accepted solution]

Nao essa correcao que estou falando é anterior a isso, tipo SP8 ou SP9.

Nao deve ser a causa do seu problema.

Abs,

Henrique.

[Former Member · Accepted solution]

Então deve ser isso. Vamos aplicar o SP15 dia 19 de setembro.

Vou aguardar.

Qualquer coisa eu abro outra thread.

Muito obrigado.

At.,

Bernardo Braga

[former_member193386 · Accepted solution]

todo o houkeeping esta certo, todas as tarefas estao agendadas corretamente, parece que a minha solucao de diminuuir o tempo funionou, nou houveram mais lotes parados

[former_member182114 · Accepted solution]

Bom dia Carlos,

A mudança do tempo me parece uma coincidência estou suspeitando de instabilidade da Sefaz.

Você está com PI 7.1? O Alert do GRC está criado?

O BATSR response está ok, e o ack está ok também como recebido?

O conteúdo da resposta BATSR tem o receipt number?

Tem dumps na ST22? Erros de atualização na SM13?

Aproveite o incidente para buscar a causa raiz. Sempre tem uma explicação.

Atenciosamente, Fernando Da Ró

[former_member193386 · Accepted solution]

usamos o Pi 7.0 nesse projeto, nao existem erros na st22 nao olhei na sm13, mas o resto esta ok, tenho essa politica de nao aceitar que as coisas funcionam por milagre também, ainda estou olhando isso, o mais engracado é que estava acontecendo somente com uma filial

retificando, olhei a sm13 tbem e nada

Edited by: Carlos Rodrigo Pereira on Sep 3, 2010 11:19 PM

[former_member182114 · Accepted solution]

Bom dia Carlos,

Então foque no BATSR, cola a resposta da Sefaz aqui.

Atenciosamente, Fernando Da Ró

[former_member193386 · Accepted solution]

Bem fernando

o proximo erro eu coloco, pq, depois de dois dias vai ser impossivel achar esse lote agora, mas agradeco as dicas, obrigado mesmo

[Former Member]

Post Duplicado.