NF-e com Process Status 02 e 04 (GRC)

[Former Member]

Boa tarde Srs,

Hoje pela manhã deparamos com um erro estranho.

Algumas notas criadas estão em Waiting (J1BNFE).

Em NF-e Monitor, algumas estão com process status 02 e outras com process status 04.

Já tentei indentificar o erro pela SMQ1 e SMQ2 sem sucesso.

Também acessei o SXMB_moni e não consegui localizar nenhum log de erro.

E Message Monitoring (RWB), todos status estão em sucessful. Pela SM37, o Job /XNFE/UPDATE_ERP_STATUS está funcionando perfeitamente e todos os serviços estão ativos.

Alguém já passou por algo parecido e poderia dar uma dica para eu resolver este problema?

Agradeço imensamente toda e qquer ajuda.

Ricardo,

[Former Member · Accepted solution]

Ricardo, boa tarde.

Se:

a) A nota esta com status 02 (sem lote) - Provavelemente o programa /XNFE/PROCESS_REPORTS não esta rodando (deveria estar rodando em um JOB.

b) O lote esta com status 02, esta com erro ? Se sim: reenvie pelo monitor GRC, aba Lote.

obs: Na J1BNFE vai ficar aguardando até o retorno da SEFAZ para o GRC.

Isso é Homologação ou Produção? Se o erro esta no lote, verifica se a SEFAZ esta no ar. Se tiver, reenvie o lote.

At.,

Bernardo Braga

Edited by: Bernardo Braga on Feb 8, 2010 7:13 PM

[Former Member]

Bernardo,

Já existe um job escalonado para este report, e funcionando perfeitamente. Estou monitorando ele via SM50.

O ambiente é produtivo. Notei que não está gerando númeração de lote (Batch) e não está aparendo o icone de reenvio (Status Query).

Fernando,

Pela SXMB_MONI não possui nenhum PE na coluna Outgoing; Todas as bandeiras estão quadriculadas e a maioria com ACK. Status (No errors in acknowledgment), outros com pontos de interrogação (verde). E na SMQ2 realmente não encontrei absolutamente nenhum erro.

Estamos tendo um impacto absurdo, pois a área funcional precisam faturar e solicitei que parassem de enviar notas, até que o problema seja soluciononado.

Agradeço imensamente toda ajuda possível.

Ricardo,

[henrique_pinto]

Ricardo,

se a situacao eh de impacto em producao, abra um chamado VH, o forum nao eh o melhor local para isso.

De qq maneira, vc soh vai ver o PE na SXMB_MONI no client do PI (ainda, verifique se o parametro LOGGING tem o valor = 1 na SXMB_ADM -> Integration Engine Configuration).

Abs,

Henrique.

[Former Member]

Henrique,

Muito obrigado por sua breve resposta, mas já havia sido aberto um chamado hoje pela manhã, assim que foi constatado que havia um erro. Porém, ainda não obtivemos resposta e só solicitei ajuda de nossos amigos no forúm, pela esperança de alguém ter passado pelo mesmo erro e ter uma dica rápida.

De qquer maneira, agradeço imensamente sua ajuda. Já havia checado o SXMB_ADM e o valor está setado com 1.

Efetuarei outros testes, e qdo encontrar-mos a solução, postarei aqui no forúm para nossos amigos.

Mais uma vez, muito obrigado.

Ricardo

[former_member182503]

Ricardo,

Você já verificou os logs da SLG2?

[]'s

José Nunes

[henrique_pinto]

Ricardo,

os acks verdes que vc comentou dao a entender que tem fila parada ou erro no communication channel XI Receiver.

Vc está vendo a SMQ2 em ambos clientes GRC e PI?

Abs,

Henrique.

[Former Member]

Henrique,

Muito obrigado pela resposta!

Mas consegui resolver o problema, acessei a tcode SM21 e notei vários erros do orasid:

"> ORA-28001: the password has expired

Initialization DB-Connect Failed, Return Code 000256

Stop Workproc17, PID 27093"

Com isto o job schedulado (/XNFE/PROCESS_REPORTS), estava preso na SM50, ficando em loop. Toda vez que eu tentava matar o processo para refazer o schedule, criava um semaforo de alerta e o processo continuava preso.

Tentei re-schedular outros jobs (/XNFE/UPDATE_ERP_STATUS e /XNFE/CHECK_SRV_STATUS), porém os mesmos ficavam em release e não ativavam.

O problema foi resolvido, simplesmente resetando na senha do ORASID, executei o comando CLEANIPC (para limpar os semaforos), stop/start na base de dados e re-schedulei os jobs novamente.

Todas as NF-e subiram lindo...

Muito obrigado pela ajuda.

Ricardo

[henrique_pinto]

Ok, estavamos discutindo o problema a nivel de aplicacao, mas existe sempre a possibilidade de estar na camada abaixo.

Att,

Henrique.

[henrique_pinto]

Na SXMB_MONI, procure a entrada referente à interface de inicio do processo (por exemplo, a 1a msg da inteface SIGNN, BATCH ou BATSR), role a barra pra direita e, na coluna Oubtound, procure pela palavra "PE". Veja a cor da bandeira do lado da palavra "PE"; isso indica o status de execucao do BPM: verde = escalonado; vermelho = executado c/ erro; quadriculada = executado c/ sucesso.

Se tiver erro, clique sobre "PE" e isso vai abrir o log de execucao do BPM (vc tb consegue isso pela SXMB_MONI_BPE).

No graphical workflow, vc vai poder ter informacoes do step que falhou e da causa do erro. De qq maneira, vc deveria ter o ack negativo de volta para o application system; se nao está voltando, pode ser erro na HTTP destination PI -> GRC (ou na configuracao do comm channel XI Receiver).

Se tiver c/ sucesso ou escalonado (scheduled), vc deveria ver na SMQ2 ou a entrada do BPM schedulada (se tiver verde; fila XBPE) ou a entrada da msg que deveria ter voltado mas nao voltou ainda (filas tipo XBTO/XBTR*).

Abs,

Henrique.