Dúvida - Job /XNFE/UPDATE_ERP_STATUS

[Former Member]

Amigos, bom dia!

Configurei um job para rodar o programa /XNFE/UPDATE_ERP_STATUS para garantir que o status da NFe seja atualizado na J1BNFE, porém observei que as notas no monitor J1BNFE estão com o log "NF-e xxxxxxxxxx tem status de doc."Autorizada"; novo status de doc."Autorizada" não é permitido" e com uma bandeira vermelha, verifiquei que estas mesmas notas estão tabela /XNFE/BACKSTATUS (do GRC) e existem vários registros dela na tabela J_1BNFE_INVALID (do ERP)



Minha dúvida é:



A limpeza da tabela não deveria ser feita no momento em que o ERP conseguisse fazer a atualização de status?

Desde já obrigado pela ajuda!

Edited by: Alexandre Rezende on Jun 2, 2009 2:01 PM

Edited by: Alexandre Rezende on Jun 2, 2009 2:12 PM

[former_member182114 · Accepted solution]

Bom dia Alexandre,

Você está certo. O comportamento desejado após a execução do report /XNFE/UPDATE_ERP_STATUS (sem informar NF-e) é enviar ao ERP e após processamento do ERP eliminar da tabela /XNFE/BACKSTATUS.

Infelizmente, existem situações que acabam por incluir indevidamente uma NF-e processada na tabela /XNFE/BACKSTATUS. O caso mais comum disto acontecer está relacionado à erros na implementação na BADI de impressão CL_NFE_PRINT->CALL_RSNAST00.

Como a chamada do GRC ao ERP é uma chamada RFC, não pode ocorrer a instrução MESSAGE. Isto faz com que todos os registros que foram enviados ao GRC pela função J_1BNFEXMLINTAB vão automaticamente para tabela /XNFE/BACKSTATUS, independente se foram ou não devidamente processadas. Quando não ocorreu a gravação tudo ok, porém se já aconteceu a gravação de status então o ERP não aceitará esta NF-e novamente, e enviará a mensagem como você mencionou... Não posso autorizar pois já está autorizado... Isso acontece especialmente no processamento de lotes c/ várias NF-es.

Dicas:

- este job deve ser schedulado entre 30min e 60min

- implementar a SAP Note 1327465 pois envia ao R/3 NFe uma a uma, ao invés do lote todo

- modificar o código da BADI de impressão CL_NFE_PRINT->CALL_RSNAST00

- somente chamar a função J_1BNFE_CALL_RSNAST00 para as situações em que deseja impressão e que ela possa realmente ser feita

- chamar a função J_1BNFE_CALL_RSNAST00 IN BACKGROUND TASK, desta forma qualquer mensagem gerada internamente na função de impressão não irá gerar erro na RFC e você deve monitorar estas mensagens na SM58 do próprio ERP

- abaixo segue um código de exemplo que levam estes itens em consideração

Existem situações onde mesmo assim o R/3 pode não processar alguma transmissão.

Após implementada estas sugestões, limpe a tabela /xnfe/backstatus e certifique-se que cada linha que ficar mais de um dia na /xnfe/backstatus tenha um bom motivo.

Atenciosamente, Fernando Da Rós

Edited by: Fernando Da Ros on Jun 2, 2009 2:16 PM

[former_member182114]

IF  i_active-code EQ '100'         "NF-e autorizada
AND i_active-printd IS INITIAL     "só imprimir automaticamente se ainda não foi impressa
AND i_active-cancel IS INITIAL     "não faz sentido imprimir autom. se ela foi cancelada
AND i_active-conting_s IS INITIAL. "não faz sentido imprimir autom. se ela foi alternada 
                                   "p/conting. pois deverá ser cancelada

********** outros tratamentos, preparações e chamar função J_1BNFE_CALL_RSNAST00
  CALL FUNCTION 'J_1BNFE_CALL_RSNAST00'
  IN BACKGROUND TASK
  EXPORTING
    i_active = i_active
  EXCEPTIONS
    no_printer = 1
    others = 2.

  COMMIT WORK.

  IF sy-subrc = 0.
    CALL FUNCTION 'J_1B_NFE_ERROR_PROTOKOLL'
    EXPORTING
      i_docnum = i_active-docnum.
  ENDIF.
 
ENDIF.

[Former Member]

Bom dia Fernando,

Minha dúvida está nas 4 primeiras linhas onde é feito o controle de impressão, qual seria o impacto na atualização de status?

Digo isso pois já tenho criado um controle de impressão e estou sendo questionado por este código.

O restante do código é igual ao que você me passou.

Obrigado pela ajuda!

Abraços!

[former_member182114]

O código está igual ? Inclusive o IN BACKGROUND TASK e COMMIT ?

Sobre as quatro primeiras linhas de código, trata-se de um filtro e deve ser adequado em cada cliente. Talvez mais IF's talvez menos IF's, é o negócio quem vai dizer.

Vamos à intenção dele:

- este método é executado em 100% dos retornos do GRC, ou seja, numa rejeição de schema 215, num cancelamento (autorização ou rejeição), numa inutilização, numa aprovação de NF-e.....

- a impressão do DANFE só deve ser feita em duas situações (contingência ou autorização)

- a contingência normalmente é impressa manualmente, antes da Sefaz responder..... Então não vejo muito sentido em deixar a chamada automática para contingência

Quanto aos IF's:

- code = somente imprimir a NF-e no momento em que recebe autorização da Sefaz (isto é independente de contingência)

- printd = não imprimir automaticamente se já foi impresso (apenas para economizar papel)

- cancel = a NF-e já pode ter sido alternada para contingência e cancelada manualmente, então não vejo sentindo em imprimir este Danfe se já foi cancelado

- contig_s = a NF-e foi alternada para contingência, situação de exceção em que a NF-e deverá ser cancelada, então também imagino que não faça sentido a impressão automática

Não tinha passado corretamente a nota a aplicar, segue SAP Note 1327465

Outra coisa, se seu código já está assim, verifique na SM58 se existem registros parados por lá.

Espero ter ajudado, Atenciosamente, Fernando Da Ró

[former_member182503]

Fernando,

só a título de curiosidade...

dentro da BADI, a função J_1BNFE_CALL_RSNAST00 deve ser chamada IN BACKGROUND TASK ?

Durante alguns testes de impressão automatica, ele gerava dump(CALL_FUNCTION_NOT_REMOTE), que este FM não poderia rodar em BG.

Segue trecho do dump:

The function module "J_1BNFE_CALL_RSNAST00" was called via RFC,

but is not flagged as being able to be used for remote calls.

Error in the ABAP Application Program

The current ABAP program "SAPLJ_1B_NFE" had to be terminated because it has

come across a statement that unfortunately cannot be executed.

The function module "J_1BNFE_CALL_RSNAST00" was called via RFC, but has

not been released for 'remote' calls.

The following types must be released for a 'remote' call:

a) Call Function 'J_1BNFE_CALL_RSNAST00' Destination ...

b) Call Function 'J_1BNFE_CALL_RSNAST00' In Background Task ...

c) Call Function 'J_1BNFE_CALL_RSNAST00' Starting New Task ...

O problema é, não era uma chamada RFC(Até pq este FM citado não está marcado como Remote Enabled Module) e sim a chamada do FM IN BACKGROUND MODE.

CALL FUNCTION 'J_1BNFE_CALL_RSNAST00'
    IN BACKGROUND TASK
    EXPORTING
      i_active          = i_active
      I_DIMME         = 'X'
      I_PRINTER       = 'VM05'
   EXCEPTIONS
     print_error       = 1
     OTHERS            = 2.

[former_member182114]

Bom dia José Nunes,

Ao chamar a função J_1BNFE_CALL_RSNAST00 IN BACKGROUND TASK, o programa executa em uma LUW separada da execução do retorno do GRC. Desta forma qualquer message 'E' ou message 'A', ou dump que seja na impressão não representará um problema de entrega ao GRC. Até porque, se chegou até a BADI de impressão é porque já atualizou os status de processamento na J_1BNFDOC e J_1BNFE_ACTIVE e deu commit.

A função não é habilitada para RFC, verifique com a equipe de Basis como está a configuração de distribuição RFC, é provável que tenha uma característica especial que esteja forçando chamada remota.

De qualquer forma, o truque é separar a impressão do código principal, se quiser você pode colocar o código inteiro da BADI em uma função RFC Z, chamar in background task e deixar o J_!BNFE_CALL_RSNAST00 síncrono, sem o IN BACKGROUND TASK.

Observação: IN BACKGROUND TASK é uma execução assíncrona. Não é uma execução em background como os reports que rodam em background (canal BGD), será executado em diálogo online tipo (DIA).

Atenciosamente, Fernando Da Ró

[former_member182503]

Fernando, obrigado pela rápida resposta.

Outro ponto que me atentei é o exemplo que consta no documento NFe_CustGuide_V2_0.pdf presente na nota #1018098 referente a esta chamada(pagina 19):

7 Appendix

7.1 Example Coding for BAdI Method CALL_RSNAST00

This Coding can be used after installation of note 1037070.

call function u2018J_1BNFE_CALL_RSNAST00u2019

exporting

i_active = i_active

i_nfdoc = i_nfdoc

exceptions

no_printer = 1

others = 2

.

if sy-subrc <> 0.

call function 'J_1B_NFE_ERROR_PROTOKOLL'

exporting

i_docnum = i_active-docnum.

endif.

The function J_1BNFE_CALL_RSNAST00 is in the standard delivery for NF-e.

It provides the following interface:

I_ACTIVE must always be filled with from the BADI interface.

I_NFDOC can be filled from the BADI interace when the printer should be

determined as maintained in the output configuration

I_KAPPL for NF-e the default Application u2019NFu2019 has to be used

I_NACHA for printing the transmission medium must be set to 1 as per

Default

I_DIMME print immediately is per default set to X, can bes et to space

When the output should not be printed immediately

I_PRINTER can be used when the output should be send to a different

printer as defined in the output determination for NF-e

When during the BADI process error occurs, the messages are written in the error log

and can be controlled with the report J_1BNFE_MONITOR.

No caso, ele cita um parâmetro i_nfdoc, que não existe. Provavelmente é um exemplo antigo e este documento necessita revisão.

Mais uma vez, obrigado.

[former_member182114]

Bom dia José Nunes,

Concordo com você, na verdade o parâmetro até existe (é do tipo J_1BNFDOC e opcional), porém não é utilizado.

É por isso que o fórum, wikis, artigos e blogs são bem melhores de acompanhar que a documentação original (passado um tempo).

Atenciosamente, Fernando Da Ró

[Former Member]

Olá Alexandre,

Como resolveu esta questão? Estou com o mesmo problema.

No meu caso, o log na J1BNFE aparece com status de uma nota autorizada, porém continua com a bandeira vermelha.

Ao acessar o log ele diz que o Documento já existe (Document XXXXX already exists). E o último usuário que atualizou o log foi o usuário da RFC que conecta no R/3.

Esqueci de mencionar: não escalonei o JOB para rodar o /XNFE/UPDATE_ERP_STATUS e mesmo assim continuo com o problema.

Obrigado,