on 09-09-2009 1:27 PM
Olá,
Estamos em produção, com o ambiente estável, porém, ontem apareceram 2 casos no período da manhã e 1 caso no período da tarde referente a SEFAZ SP.
A nota no ECC fica com a engrenagem;
No GRC:
/xnfe/batsta-statcode = 105 u2013 Lote em processamento
/xnfe/bat-hist-batstat = 07 u2013 Lote em processamento, este registro se repete algumas vezes, mas não chega no limite configurado no lote que está configurado com 10 vezes, no ultimo registro gerado o campo ERROR_STATUS = 44
Para resolver rapidamente o problema na produção, u201Climpamosu201D o campos ERROR_STATUS e automaticamente o GRC enviou a consulta de lote para a SEFAZ, que retornou com a autorização da nota, atualizando todos os sistemas corretamente.
Precisamos de uma solução, sem ser u201Cmarretau201D.
Muito obrigada
Tânia Kaç
Henrique,
Não estamos recebendo rejeição, aqui os dados estão todos corretos e todas as notas são aprovadas!
Na sm50 do GRC só está rodando um /XNFE/PROCESS_REPORTS numa sessão, não temos nada em paralelo.
O histórico do lotes estava:
900 000000000000615 20.090.908.112.135,6460000 01 BASIS
900 000000000000615 20.090.908.112.135,6930000 02 BASIS
900 000000000000615 20.090.908.112.139,3520000 03 XADAPTERGRC
900 000000000000615 20.090.908.112.139,0520000 04 BASIS
900 000000000000615 20.090.908.112.142,0530000 04 BASIS
900 000000000000615 20.090.908.112.142,2580000 07 XADAPTERGRC
900 000000000000615 20.090.908.112.144,6620000 07 44 XADAPTERGRC
Por não ter nenhum botão para empurrar disponível no monitor GRC, limpamos o status 44, automaticamente ficou assim:
900 000000000000615 20.090.908.112.135,6460000 01 BASIS
900 000000000000615 20.090.908.112.135,6930000 02 BASIS
900 000000000000615 20.090.908.112.139,3520000 03 XADAPTERGRC
900 000000000000615 20.090.908.112.139,0520000 04 BASIS
900 000000000000615 20.090.908.112.142,0530000 04 BASIS
900 000000000000615 20.090.908.174.707,9800000 04 BASIS
900 000000000000615 20.090.908.174.710,4410000 05 XADAPTERGRC
900 000000000000615 20.090.908.112.142,2580000 07 XADAPTERGRC
900 000000000000615 20.090.908.112.144,6620000 07 XADAPTERGRC
Estamos no GRC SLL-NFE SAPK-10009INSLLNFE,
No PI SLL-NFE-JWS 100 SP8 (1000.100.0.8.0.20090224070346)
SAP AG MAIN_NFE10VAL_C 20090813152553
Abraços,
Tania.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Bom dia Tania,
Você tem mais de um programa /xnfe/process_reports rodando ? ou o /xnef/collect_batch rodando ? ou algum programa Z que faça a consulta à Sefaz ? ou alguma situação especial que pudesse explicar os dois "pedidos" de consulta ao PI ? Ou mais de um servidor ?
Veja:
> 900 000000000000615 20.090.908.112.139,0520000 04 BASIS
> 900 000000000000615 20.090.908.112.142,0530000 04 BASIS
O 04 é o pedido de consulta de status ao PI/SEFAZ...
> 900 000000000000615 20.090.908.112.142,2580000 07 XADAPTERGRC
> 900 000000000000615 20.090.908.112.144,6620000 07 44 XADAPTERGRC
O retorno do PI/SEFAZ pode ser 05 ou 07, como recebeu 105 da Sefaz, virou 07 no GRC.
O primeiro ficou 07 e seria reenviado, o segundo eh que "parou" tudo pois antes de um 07 tem que ter um 04 e não outro 07.
Ou seja, a origem do seu erro 44 está explicada, mas o pq de dois pedidos para Sefaz precisa de investigação.
Atenciosamente,
Fernando Da Rós
Edited by: Fernando Ros on Sep 9, 2009 5:11 PM
Bom dia Tânia,
Analisando melhor o histórico dá para imaginar que você está trabalhando com mais de um servidor, se isso for verdade, provavelmente o que aconteceu é que cada parte do processo ocorreu em servidores diferentes, veja a ordem que deveria estar:
> 900 000000000000615 20.090.908.112.139,0520000 04 BASIS
> 900 000000000000615 20.090.908.112.142,2580000 07 XADAPTERGRC
> 900 000000000000615 20.090.908.112.142,0530000 04 BASIS
> 900 000000000000615 20.090.908.112.144,6620000 07 44 XADAPTERGRC
Ou seja, esperou 0 segundos para reconsulta. Verifique se o tempo de WAIT em /xnfe/batsta para este lote está = 0.
Se tiver pode ser sua configuração com este parâmetro zerado ou a falta da nota 1379714.
Atenciosamente,
Fernando Da Ró
Bom dia Tania,
O valor deste parâmetro refere-se à última coluna da configuração de lote (Tempo de espera, se não me engano).
Devido a um erro de programa (o que a nota corrige), se a linha de configuração de lote default é utilizada ele sempre consta com WAIT = 0.
A partir do SP10, este tempo de consulta pode ter como origem o valor de sua configuração de lote ou então o valor TMED informado pela Sefaz no momento da entrega do lote.
A propósito, e quanto ao número de servidores ? Está usando cluster ? Tem quantos servidores ?
Atenciosamente,
Fernando Da Rós
Edited by: Fernando Ros on Sep 9, 2009 6:51 PM
Olá Fernando,
Utilizamos a linha de configuração de lote default. Sempre gerou WAIT = 0, sem verificar o parametro do lote tmp.esp(seg), depois da nota aplicada está gravando conforme o parametro definido.
Q legal a origem do wait ser o valor informado pela SEFAZ !
Temos 2 servidores ligados em cluster.
Obrigada,
Tania Kaça.
Olá Henrique,
Obrigada pela atenção.
Então, para o erro 42 - Nro maximo de consulta atingido, libera os botões para "empurrar" a mensagem, mas para o erro 44 - Outras mensagens de erro SEFAZ, não está liberando os botões, por isto a "marreta".
Um abraço,
Tania.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Ah, entendi.
Na verdade teria q analisar o porque do erro.
Aparentemente, o GRC está recebendo um status pro lote que ele nao estava esperando.
Já vi isso acontecer qdo chegavam 2 msgs de rejeicao.
É possível que existam jobs em paralelo rodando?
Como está o historico do lote?
Vc está no ultimo SP do GRC?
Abs,
Henrique.
1. com relacao ao procedimento, nao precisa de marreta. Basta ir na aba "Erro de verificacao de Lote" no Monitor de Lotes e restartar o lote por lá (seleciona-lo e clicar no botao "Restart"); **
2. com relacao ao parametro de numero de retries, note que o que a aplicacao faz é usar o Mínimo de cada parametro entre todas as entradas que sao relevantes para uma nota/lote. Entao, por exemplo, suponha que vc setou retry = 10 p/ o CNPJ = X e retry = 5 para NFe com tpAmb = 1, se chegar uma NFe que atende a ambos os parametros (q tenha CNPJ = X e tpAmb = 1), o numero de retries dela será o min(10, 5) = 5.
Abracos,
Henrique.
caso seja desejado, é possível replicar o código do webdynpro que faz esse restart e colocar em um report Z que pode ser schedulado. A idéia é ter restart automatico de lotes parados com erros de envio/verificacao.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
13 | |
2 | |
2 | |
1 | |
1 | |
1 | |
1 | |
1 | |
1 | |
1 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.