Notas Paradas no Monitoramento

[Former Member]

Srs,

De tempos em tempos algumas NF-es faturadas ficam presas no monitor J1BNFE (Engranagem).

Pesquizando na SEFAZ, estas notas são aprovadas; Então, precisamos forçar elas via report /XNFE/UPDATE_ERP_STATUS e /XNFE/UPDATE_ERP_STATUS_DIAL.

Isto ocorre exporádicamente e não conseguimos encontrar um erro explicito para este ocorrido.

Fizemos várias pesquinas sem sucesso:

- Via Moni

- Via tabelas (/XNFE/NFE_HIST, /XNFE/BAT_HIST, /XNFE/ACKNOWLEDG, /XNFE/NFEBAT, /XNFE/NFEBAT, /XNFE/NFEHD, /XNFE/XMLIN, etc)

- RWB

- Via tcodes (SM12, SM21, SM13)

- Os jobs /XNFE/UPDATE_ERP_STATUS, /XNFE/PROCESS_REPORTS e /XNFE/CHECK_SRV_STATUS; estão schedulados.

Nossa solução GRC NFE, está em ambiente produtivo e funcionando perfeitamente. Este fato ocorre exporádicamente e não conseguimos encontrar algum log de erro para explicar tal fato.

Alguém poderia me ajudar a entender o que pode estar ocorrendo?

Grato,

Ricardo

[former_member193386]

provavelmente o usuario do sistema entrou no documento da nf para verificar os dados ou alterar o mesmo bloqueando a atualizacao dos dados por parte do GRC no ECC.

Esse problema não retorna erro no XI justamente porque os dados foram enviados para a RFC de processamento de ECC que tbem não retorna erro consideravel no processo.

A solucao seria definir um processo interno no ECC ou dentro da rotina do usuario para que essas notas nao sejam abertas para edicao depois de enviadas ao SEFAZ

[former_member193386]

Explicando de maneira mais detalhada, o momento de atualizacao dos dados do ECC pelo GRC não é utilizado o PI para a chamada da RFC, essa RFC é chamada diretamente pelo GRC e disparada no ambiente do ECC via RFC Destination (SM59) previamente configurada para a comunicacao entre os ambientes na SM59.

Por isso não existe erro de mensageria a ser exibido no monitor de msgs, muito menos, log de erro no GRC, já que os dados realmente foram enviados ao ECC, que não retorna erro algum porque o registro esta bloqueado por um usuario ou qualquer outro processo.

[Former Member]

Carlos, obrigado por sua pronta resposta!

É justificavel sua explicação, pois chequei alguns logs via tcode AL11 (/usr/sap/P78/DVEBMGS30/work/dev_rfc*), e encontrei o seguinte log de erro abaixo:

• Trace file opened at 20100521 110216 GMT: SAP-REL 700,0,201 RFC-VER U 3 1055766*

======> Command to tRFC/qRFC: Execute LUW again.

ABAP Programm: SAPLERFC (Transaction: )

Called function module: ARFC_DEST_SHIP

User: WF-BATCH (Client: 120)

Destination: WORKFLOW_LOCAL_120 (handle: 2, 45897070, {4BF5A6AD-C9CD-169E-E100-0000995893E4})

SERVER> RFC Server Session (handle: 1, 45895012, {4BF6A060-4513-25DE-E100-0000995893E4})

SERVER> Caller host:

SERVER> Caller transaction code: (Caller Program: SAPLARFC)

SERVER> Called function module: ARFC_RUN_NOWAIT

A RFC (WORKFLOW_LOCAL_120), foi criada pelo usuário PISUPER. Esta RFC está sendo autênticada pelo usuário WF-BATCH, que é um tipo de usuário de sistema.

Este usuário (WF-BATCH), faz parte do grupo SUPER e possue SAP_ALL.

Só não entendi uma coisa: Qdo vc menciona, "provavelmente o usuario do sistema entrou no documento da nf para verificar os dados ou alterar". Vc referencia o usuário WF-BATCH (por exemplo) ou o usuário que criou a NF-e (user final - dialog)?

E porque este usuário faz este tipo de check?

Desculpe minha ignorância, mas vc poderia me explicar como eu posso definir um processo interno no ECC ou dentro da rotina do usuario para que essas notas nao sejam abertas para edicao depois de enviadas ao SEFAZ?

Mais uma vez, muito obrigado por sua pronta resposta.

Ricardo,

PS.: Verifiquei também as tcodes SMQ1 e SMQ2, e também não localizei nenhum lock nestas entradas.

[former_member193386]

na verdade quando falo de usuario, digo o usuario humano mesmo, algum dos funcionarios responsaveis pela criação do documento da nf esta editando ou com a nf aberta e o sistema, mesma usando um usuario com todos os privilegios nao consegue alterar os dados porque o mesmo encontra-se locado pelo usuario, ou qualquer outro processo que esteja atualizando os dados da nf que não seja o GRC.

[Former Member]

Perfeito,

Imaginei isto mesmo...Coisa de funcionais! ;o)

Carlos,

Vc sabe me dizer se existe alguma rotina, para eu executar quando estas notas ficam presas?

Um job por exemplo ou um report para eu schedular um job de tempos em tempos?

Sei que é demais, mas vc puder me dizer qual objeto de autorização (PFCG) eu bloqueio este acesso dos usuários, ficarei muito agradecido?

Muito obrigado mesmo por sua ajuda,

Ricardo

[former_member193386]

vc nao encontra os locks posteriomente inclusive porque o usuario deve abrir o documento e depois fechar o mesmo após a tentativa de atualizacao por parte do grc

[Former Member]

Muito obrigado Carlos,

Farei uma pesquiza e tentarei resolvê-lo.

Postarei a solução para todos.

Valeu,

Ricardo

[former_member193386]

na realidade acho que é mais facil procurar uma solucao atraves das configuracoes de SD, bloqueando o doc depois que o usuario salvar a nf ou algo do genero

[Former Member]

Em um cliente no qual implementamos a NF-e com mensageria NON-SAP, para contornar esse problema de documento aberto e não atualização da NF-e no monitor (e processos relacionados), criamos um programa a ser rodado via job, com o intuito de verificar na mensageria o status das notas pendentes de retorno. O retorno para o ECC é feito através da RFC XML_IN, atualizando somente as notas com status diferente do já existente no ECC (ou seja, se na mensageria a mesma já estivesse aprovada, rejeitada, cancelada, etc... enquanto no ECC está aguardando algum retorno).

Foi uma solução "limpa", pois utiliza o processo standard do ECC para atualizar os devidos status.

Fica a dica...

Cordialmente,

Alexandre B. Dambrowski

Consultor SAP ABAP

Novo Hamburgo/RS - Brasil

[Former Member]

Srs,

Muito obrigado por todas respostas.

Estarei verificando e qdo tiver uma solução, postarei aqui novamente.

Muito agradecido,

Ricardo

[Former Member]

Srs,

O problema aparentemente foi resolvido, após ter schedulado um job (RSXMB_RESTART_MESSAGES), num período de 5 min.

Vou acompanhar e darei mais detalhes futuros.

Grato,

Ricardo

PS.: Dúvidas sobre schedules de jobs no ambiente de XI, visitem a página: http://help.sap.com/saphelp_nw70/helpdata/en/cd/20bc3ff6beeb0ce10000000a114084/content.htm