Notas parando em status 3 Assinado sem status de erro e sem lote.

[Former Member]

Bom dia NF-e Gurus,

Estou enfrentando um problema em nosso ambiente XI/PI de dev onde as notas estão ficando paradas com status 3, sem status de erro e não estão sendo atribuídas a um lote. O job com /XNFE/PROCESS_REPORTS está rodando com sucesso.

O ultimo lote criado a dois dias atrás, está com status 3 e erro 70 código 215.

No monitor de status de serviço SEFAZ, todos os serviços estão verdes.

Já alterei na tabela /XNFE/NFE_HIST algumas notas para o status 2 código 28 mas elas retornam para o status 3 e ficam paradas.

Onde posso obter mais informações (logs) sobre o problema ou o que pode estar causando este erro?

Obrigado desde já.

Raphael Maciel

[Former Member · Accepted solution]

Bom Dia Pessoal,

Na verdade o problema que o Raphael estava tendo era por que não havia uma configuração de lotes para o tipo de contingência (Tipo 2)

Na tabela NFEHD tínhamos notas tipo 2 e tipo 1 porém só tínhamos o cadastro para o tipo 1.

Cadastramos a configuração do tipo 2 e tudo está rodando OK.

Henrique

Passamos por uma situação interessante que só descobri debugando o código.

O códgo entrou em loop infinito por não tem a configuração do tipo 2 na BATCUS.

No collect_batch form CHECK_BATCH nós temos o seguinte código

Ensure that all remaining NFes will send

WHILE NOT lt_next_batch IS INITIAL.

PERFORM close_batch USING lt_next_batch

CHANGING lv_size

lv_quant

lt_next_batch.

ENDWHILE.

No form Close_batch ele testa se o tamnho dos arquivos não superou o tamanho permitido (informação que ele colhe da batcus através do tipo de nota)

Como ele não tinha o tipo de contingência na BATCUS, para as notas de tipo 2, ele estava utilizando o registro zerado da BATCUS, assim ele nunca sai deste loop.

Interrompemos o programa que já estava rodando no COLLECT_BATCH a 4 dias, cadastramos o tipo na BATCUS (Através do Portal Web) e ele não travou mais.

Grande Abraço

Rapha, Pode fechar o tópico ?

Abraç

[henrique_pinto · Accepted solution]

Thiago,

quando o programa nao acha um parametro adequado, entao ele deveria usar o registro default (onde o nome do campo e o valor associado aparecem vazios, na tabela).

Vcs criaram o registro default?

Abs,

Henrique.

[Former Member]

Henrique

Tínhamos sim, aliás a configuração estava perfeita antes de começar a emitir nota com o tipo 2. Eles já estão trabalhando em Homologação a pelo menos 2 meses, porém a partir de segunda começaram a testar notas de contingência.

Tínhamos o registro zerado (Gerado pelo GENERATE_BATCUS)

e o registro tipo 1 gerado manualmente com as configurações padrão

Agora acrescentamos um tipo para notas 2 e um para notas tipo 5 (que são os dois tipos de contigência que serão utilizados)

Comentei sobre o loop por que verifiquei que o códio não prevê uma parada se não houver o tipo correto na batcus.

Abraç

[henrique_pinto]

Thiago,

entao há um erro, pois ele deveria usar o default no caso de nao ter encontrado algum registro especifico.

Por favor, abra um chamado sobre o assunto.

Att,

Henrique.

[Former Member]

Henrique,

Na verdade ele faz isso sim, ele utiliza o registro default.

O problema é que quando ele usa o registro default para comparar o tamanho máximo permitido do XML no loop que eu postei acima ele nunca cairá na condição de saída do loop.

Vamos abrir um chamado sim e vamos colocar a condição de simulação.

Abraço e obrigado mais uma vez

Suzano

[henrique_pinto]

Isso soh aconteceria se o tamanho maximo que tah no registro default fosse menor do que o do XML que está pendente.

Mas o registro default vem com o tamanho de 500.000 bytes; vcs alteraram esse valor?

Abs,

Henrique.

[former_member182503]

Raphael,

eu tentaria ver se o programa /XNFE/PROCESS_REPORTS não está travado (SM50) ou verificaria na SM12 se os locks desse programa estão se renovando. Se for o caso, pare o job e agende-o denovo.

Se não funcionar, eu tentaria parar o job e roda-lo na mão, debugando, para ver porque ele não cria o lote.

Outro ponto de atenção seria ver se na tabela /XNFE/NFEBAT existem notas onde o BATCHID está vazio.

[]s

[Former Member]

Job /XNFE/PROCESS_REPORTS esta rodando no mesmo mandante do GRC ?

[henrique_pinto]

A dica do Bernardo reflete algo bem comum de acontecer.

Quando vc tem o PI e o GRC na mesma instancia, se o report é executado no client do Integration Server e nao no Application Server, nao vai funcionar.

Abs,

Henrique.