Novo: "Erro atualização status ERP"

[Former Member]

Olas.

Atualizamos o GRC para o SP 13 e estou com uma dúvida relativa a nova funcionalidade/botão "Erro atualização status ERP".

Notei que, em alguns casos, uma nota é autorizada e é atualizado corretamente o status no ERP com "Autorizada". Porem, por algum motivo o GRC considerou que nao foi atualizada e em uma nova tentativa de atualizar, o erro: "NF-e xxx tem status de doc."Autorizada"; novo status de doc."Autorizada" não é permitido".

Porem a nota fica com erro no GRC (Erro ERP = 107). Não poderia ignorar o fato e não considerar no GRC como um erro (uma vez que não ha nada mais a fazer) ?

At.,

Bernardo Braga

[former_member182114 · Accepted solution]

Bom dia Bernardo,

Concordo contigo quando ao não fazer sentido um "Nao posso autorizar uma nota autorizada", principalmente quando olhamos para um evento.

Porém, o que levou aos desenvolvedores deixar desta forma é que existe uma comuicação do GRC ao ERP com status inválido e isto tem que ficar logado, o que pra mim faz sentido.

Então a conclusão é que esta situação é um sintoma de algo incorreto e não o erro em si.

Agora... Por que isto acontece ( causa mais comum 😞

- Na resposta do lote, imaginando 10 NF-es num lote... As respostas destas 10 notas são enviadas ao ERP através da função J_1B_NFE_XML_IN_TAB.

- Esta função irá verificar/atualizar cada status de cada nota fazer um COMMIT e após isto chamar o método CL_NFE_PRINT -> CALL_RSNAST00

- Se acontecer algo dentro deste método que resulte na instrução MESSAGE, causará uma quebra da RFC...

- O GRC recebe uma resposta falha de comunicação e todas as notas são colocadas na /xnfe/backstatus para futura retransmissão, mesmo que n NF-es tenham sido processadas e commitadas no banco...

- Para estas que já foram gravadas cairá na situação em que vc se encontra.

O que fazer:

- Investigar se todos os tratamentos no método da BAdI estão sendo corretamente feitos. Ex.: Somente chamar a impressão se for realmente para imprimir. Ex.: NF-e emitida em contingência já foi impressa, então não precisa ser processada... Outra, se a autorização é para cancelar 101, não precisa também... e por aí vai.

- Uma transação que pode ajudar é a RSRFCTRC no GRC, ela tem todos os logs de RFC é possível que a informação origem da falha seja encontrada aí.

- Uma forma de diminuir muito o problema é colocar todo o processamento de impressão automática em um FM p/ execução assincrona: Veja esta discussão:

Como cada caso é um caso, talvez exista algum motivo particular no seu sistema para gerar estas "não confirmações", pode ser código seu o situação sua que o standard não trata. Por isso é importante a investigação para saber como resolver de verdade a issue.

Atenciosamente, Fernando Da Ró

[Former Member · Accepted solution]

Concordo que o fato do GRC marcar a nota com "Erro ERP = 107" é um sintoma de que ha algo errado

e que deve ser verificado a causa do problema.

Porem o fato de deixar a nota no GRC com erro (e sem possibilidade de reverter), irá causar uma série de tentativas de

reenvio por parte dos usuários atraves da aba "Erro atualização status ERP".

Não poderia deixar o log do problema na /XNFE/BACKSTATUS, porem não considerar como um erro (no caso do Erro ERP = 107)?

At.,

Bernardo Braga

[former_member182114 · Accepted solution]

Bom dia Bernardo,

Também concordo contigo. Na solução, o problema é mais embaixo, a mensagem completa você vê apenas no R/3. No GRC ambas as infos chegam como 107 que significa impossibilidade de ir de um status a outro. Nós sabemos que é de autorizado a autorizado no texto R/3, então pensando cá entre nós acho que seria necessário um novo status para este AUTH TO AUTH e no GRC o tratamento poderia ser IGNORAR.

Sinceramente não sei como seria para os desenvolvedores, modificarem seus códigos ou entender que o cliente tem problemas.

Você fez alguma investigação quanto ao sintoma?

Atenciosamente, Fernando Da Rós

-

-

---

Editando: Faz uma investigação e cria um chamado, daí teremos todas as respostas

[Former Member · Accepted solution]

Fiz uma pequena investigação pela RSRFCTRC e detectei 2 erros frequentes. Acredito que o 1o deve estar relacionado a entrada do registro na /XNFE/BACKSTATUS (mas não tenho certeza). Pela analise FLASH que fiz parece algo a ver com ARFCSSTATE / LOCK.

• Trace file opened at 20100315 125544 GRNLNDST SAP-REL 700,0,221 RFC-VER U 3

======> Não existe dados para este documento BMJF 981512463 .

ABAP Programm: /XNFE/SAPLAPPL_PROCESSES (Transaction: )

Called function module: J_1B_NFE_XML_IN_TAB

User: INTERFACES (Client: 320)

Destination: LOGSYS310 (handle: 3, 58802314, {4B9E9F01-535F-016E-E100-80000A0101

SERVER> RFC Server Session (handle: 1, 58801204, {4B9E25E1-4261-0103-E100-80000A

SERVER> Caller host:

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

SERVER> Called function module: TRFC_QIN_DEST_SHIP

• Trace file opened at 20100315 131127 GRNLNDST SAP-REL 700,0,221 RFC-VER U 3

======> Comando ao tRFC/qRFC: Executar novamente a unidade lógica de trabalho.

ABAP Programm: SAPLERFC (Transaction: )

Called function module: ARFC_DEST_SHIP

User: WF-BATCH (Client: 310)

Destination: WORKFLOW_LOCAL_310 (handle: 2, 59736503, {4B9EAB34-5728-016D-E100-8

SERVER> RFC Server Session (handle: 1, 59730491, {4B9ED9A7-535F-016E-E100-80000A

SERVER> Caller host:

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

SERVER> Called function module: ARFC_RUN_NOWAIT

obs.: Vou abrir um chamado.

At.,

Bernardo Braga

Edited by: Bernardo Braga on Mar 15, 2010 5:17 PM

[former_member182114 · Accepted solution]

Bom dia Bernardo,

Este erro abaixo, acontece no R/3 em algum momento e faz a conexão RFC ser fechada abruptamente.

======> Não existe dados para este documento BMJF 981512463.

Que documento é este ? pelo código parece customer specific.

Uma forma de isolar é fazer uma Função remota e colocar todo código do CALL_RSNAST00 dentro... Veja a thread indicada. Isto isola os problemas e você pode monitorá-los na SM58 do R/3.

Este aqui está mais relacionado ao trabalho do XI, é tido como normal e auto tratável se sua quantidade não for exagerada... Normalmente está relacionada a falta de DIALOGs para execução.

======> Comando ao tRFC/qRFC: Executar novamente a unidade lógica de trabalho.

Atenciosamente, Fernando Da Ró

[Former Member · Accepted solution]

Ja havia repassado essa informação de isolar a chamada CALL_RSNAST00 para eliminar as entradas indevidas na /XNFE/BACKSTATUS, porem nada foi feito. Como não eu não posso interferir em programas de outro módulo SAP, irei abrir um problema interno para tratar deste assunto.

De qualquer forma, ainda creio que o GRC não deva deixar a nota com erro para casos em que não ha nada a ser feito, pois o usuário vai ficar clicando 700 vezes no botão de enviar para o ERP e depois vai reclamar que o GRC não esta funcionando.

Abri um chamado para verificar a possibilidade de ignorar este erro 107.

At.,

Bernardo Braga

[Former Member · Accepted solution]

Fernando, hoje temos o código abaixo no método Z_IMPRESSAO_AUTOMATICA.

........

executa um select aqui.

........

depois tem o código abaixo. No caso pego este trecho TODO abaixo:

CALL FUNCTION 'J_1BNFE_CALL_RSNAST00'

EXPORTING

i_active = wa_active

i_dimme = 'X'

EXCEPTIONS

no_printer = 1

print_error = 2

OTHERS = 3.

IF sy-subrc <> 0.

CALL FUNCTION 'J_1B_NFE_ERROR_PROTOKOLL'

EXPORTING

i_docnum = p_active-docnum.

ENDIF.

COMMIT WORK AND WAIT.

E coloco dentro da RFC com os parametros de importacao WA_ACTIVE e DOCNUM e chamo a RFC IN BACKGROUND TASK desta maneira:?

RFC:

CALL FUNCTION 'Z_RFC_XXXXXX'

IN BACKGROUND TASK

EXPORTING

WA_ACTIVE_L = wa_active

DOCNUM = p_active-docnum.

At.,

Bernardo Braga

[former_member182114 · Accepted solution]

Bom dia Bernardo,

A chamada está correta, mas precisa de um COMMIT WORK após o CALL FUNCTION IN BACKGROUND TASK.

Não precisa ser COMMIT WORK AND WAIT, pois nenhum resultado é esperado.

Atenciosamente, Fernando Da Ró

[Former Member · Accepted solution]

Esse COMMIT WORK AND WAIT foi incluido especificamente para tratar de um problema que não tenho conhecimento, por isso acho melhor não alterar.

Se eu deixar o COMMIT WORK AND WAIT dentro da RFC criada (como esta agora), resolve o problema do GRC?

Ou preciso de um COMMIT WORK adicional após a chamada RFC?

At.,

Bernardo Braga

[former_member182114 · Accepted solution]

Bernardo,

Precisa de um COMMIT WORK adicional no método após o CALL FUNCTION IN BACKGROUND para "dispará-lo", se não num processamento de 10 notas, a última pode não irá ser impressa.

Atenciosamente, Fernando Da Rós

Editando: Após implementar, comece a observar a SM58 no ERP para ver quando algo ficar com erro na chamada desta função Z. Isso irá ajudar em correções do programa de impressão ou outros sub-Zs, que hoje não são visíveis aos olhos dos funcionais/tecnicos do ERP.

[Former Member · Accepted solution]

Bom dia.

Coloquei o código dentro de uma RFC Z: Z_RFC_XXX', mas ao inves de chamar:

CALL FUNCTION 'Z_RFC_XXX' IN BACKGROUND TASK

Estou chamadno:

CALL FUNCTION 'Z_RFC_XXX STARTING NEW TASK 'NFERFCIMPRESSAO' DESTINATION 'NONE'

Pois tive o mesmo problema citado abaixo (The function module "Z_RFC_XXX" was called via RFC, but has

not been released for 'remote' calls.):

E nao conseguimos (com BASIS) executar de jeito nenhum.

Estou chamando da seguinte forma:

CALL FUNCTION 'Z_RFC_XXX' STARTING NEW TASK 'NFERFCIMPRESSAO' DESTINATION 'NONE'

EXPORTING

WA_ACTIVE_L = wa_active

DOCNUM = p_active-docnum.

COMMIT WORK.

Esta correto? O fato de não ter eliminado o erro ERP 107, pode ser outro problema?

At.,

Bernardo Braga

[Former Member · Accepted solution]

Só esta ocorrendo para 2 filiais (das 80).

Vou analisar um pouco e posto aqui se achar alguma coisa.

At.,

Bernardo Braga

[former_member182114 · Accepted solution]

Bom dia Bernardo,

A questão de colocar todo o conteúdo da BAdI em uma função e chamar assincronamente deve resolver qse 100% ou boa parte pelo menos, mas não é garantia de 100%. O que está sendo "atacado" é o ponto com mais incidência de problema.

Quanto ao NEW TASK ao invés de BACKGROUND você acaba perdendo o log na SM58 que é muito bom para monitoramento.

Verifique na característica da função (SE37 primeira aba) se a função está marcada como 'remote enabled'.

Atenciosamente, Fernando Da Ró

[henrique_pinto · Accepted solution]

E se for chamada sincrona, nao precisa de commit work pra chamada em si.

Abs,

Henrique.

[Former Member · Accepted solution]

A função esta marcada como 'remote enabled'.

Ao trocar o IN BACKGROUND TASK para NEW TASK funcionou. (não reclama mais do: ...not been released for 'remote' calls.).

Teve um problema no Grupo de Funções da RFC durante o transporte que tambem pode ter causado o erro. O ABAP vai analisar aqui.

Porem meu problema mesmo são os registros da /XNFE/BACKSTATUS. Aparentemente reduziu bastante, mas ainda tem muito e se deixo o JOB do UPDATE_ERP_BACKEND, as NF-e ficam tudo com status Erros ERP = 107 - e X(erro) no monitor GRC, causando a impressão de erro na nota.

Abri um chamado para verificar a possibilidade de ignorar esse Erro ERP 107 (pode até continuar a gravar na BACKSTATUS para indicar que tem um problema). Estou aguardando.

Vou continuar monitorando o ambiente aqui se se descobrir alguma novidade, eu posto.

Muito obrigado.

At.,

Bernardo Braga

[former_member182114 · Accepted solution]

Bom dia Bernardo,

Enquanto aguardamos a resposta ao chamado sobre o 107, vamos tentar resolver a questão da chamada da função:

Faça um programa Z somente testando a chamada da função em IN BACKGROUND.

Execute com o seu usuário e com o usuário da interface, se falhar veja na transação SU53 qual authcheck falhou e dê os direitos.

Outra ponto, verifique se o método SET_COMMIT da implementação ativa da BAdI CL_NFE_PRINT está setando com o código e_commitcall = 'X' conforme texto da SAP Note 1163056.

Atenciosamente, Fernando Da Ró

[Former Member · Accepted solution]

Bom dia a todos.

Nota 1452523 liberada para questão da atualização Erro ERP. (nota é do XX-CSC-BR-NFE: SAPKH60018)

Quanto a comunicação GRC/ERP, nosso ambiente esta com commit = 'X'.

O que vou fazer agora é tentar eliminar de alguma forma (pelo menos para chamada RFC do GRC) os "messages" que ocorrem no SAP.

O crescimento da backlog reduziu pela metade após a criação do Z para isolar o CALLR..., mas ainda é muito alto.

Vou postando as ações na medida que for reduzindo.

Agradeço mais uma vez.

At.,

Bernardo Braga

Edited by: Bernardo Braga on Mar 26, 2010 11:54 AM

[Former Member · Accepted solution]

Só para esclarecer uma dúvida:

A função J_1BNFE_CALL_RSNAST00 pode ser chamada IN BACKGROUND TASK como abaixo:

CALL FUNCTION 'J_1BNFE_CALL_RSNAST00' IN BACKGROUND TASK

Mesmo ela não sendo (attributes) uma "Remote-Enabled Module"?

(ela, em meu ambiente, é uma "Normal Function Module")

Pergunto isso pois no Help (ABAP Keyword documentation) do "CALL FUNCTION - IN BACKGROUND TASK" o seguinte texto descreve o efeito: "Transactional call of a remote-enabled function module specified in func via the RFC interface"

E mesmo nao tendo funcionado em minha primeira tentativa, pretendo tentar novamente.

Grato.

At.,

Bernardo Braga

[henrique_pinto · Accepted solution]

Bernardo,

o remote-enabled function serve para vc chamar a funcao a partir de um outro logical system (instancia/client), atraves de uma RFC Destination (que vc passa com o parametro 'DESTINATION lv_dest' apos o "IN BACKGROUND TASK").

O background task vai fazer com que essa funcao nao seja imediatamente executada. Ela eh adicionada na fila de background (vc pode ver pela SM58) e depois executada de acordo com disponibilidade de Work Processes.

Abs,

Henriuqe.