Nota Duplicada NF-e 2.0

[rhviana]

Bom dia pessoALL,

Gostaria de solucionar uma dúvida, após a implementação da NF-e 2.0 está ocorrendo um problema de impressção duplicada.

O programa /xnfe/update_erp_status, está agendado de 5min em 5 min, isso pode ser o causador do problema ?

Estamos no sp17 com algumas notas do sp18.

Esse programa realmente precisa continuar sendo agendado, após o sp 17 ?

Atenciosamente,

Ricardo Viana.

[rhviana]

Obrigado atencao

[rhviana]

Estava gerando algumas notas manuais, processo normal de um usuário, e todas essas notas estão caindo na /xnfe/backstatus.

A questão é que as notas retornaram para ECC. Quando job roda, ele atualiza novamente, deletando as informações da backstatus, porém, como retorno já havia acontecido ele realiza a impressão duas vezes.

Quando a nota é gerada via j1b1n, writer, o problema não ocorre !

Detalhe o erro só está ocorrendo com um codigo de formulario apenas, todas as outras estão funcionando perfeito, independente se o job está ou não agendado.

Será que é algum problema no formulário desse tipo de nota ?

Obg

Edited by: rviana on Mar 31, 2011 5:52 PM

[henrique_pinto]

Pode ser algum problema no tratamento da BAdI de impressao, que é executada pela mesma funcao que atualiza o DB no retorno (J_1B_NFE_XML_IN_TAB). É possível que o DB seja salvo mas algo um erro na BAdI esteja sendo interpretado pelo GRC como falha na comunicacao e, portanto, ele salva para reenvio.

Dê uma lida nas sugestões aqui:

Abs,

Henrique.

[rhviana]

Henrique,

Estava verificando o que voce falou, a priore o abap não encontrou erros.

Verificamos a outra thread, as notas informadas estão aplicadas.

Alguma luz ? Estamos tentando rastrear o por que ela está caindo na backstatus toda hora.

O retorno é feito para o ECC, mesmo assim, continua indo para backstatus.

Att,

[henrique_pinto]

Tente ativer o trace (ST01) para o usuario da RFC Destination do GRC pro ERP.

Abs,

Henrique.

[rhviana]

Henrique,

Acabei de ativar, verificando log apareceu essas informações abaixo:

16015.974 ? Client 4 0 dbix06hp_NFQ_44 ? Client J_1B_NFE_XML_IN_TAB 484 0

1.200 / /BACKST REEXEC 1 0 INSERT VALUES( '020' , '35110371673990000177550080000407491497846675' , '1' , 20110331173429.973479 , 0034882909 , '135110003326831' , '100' , 'LGSYNQE210' ,

Após a execução da função J_1B_NFE_XML_IN_TAB , está sendo inserido o valor na backstatus.

Isso está ocorrendo apenas para um tipo de NF-e.

Att,

[henrique_pinto]

Esse trace foi no ERP ou GRC?

Eu tinha falado pra tentar ver no ERP o motivo do erro.

Tem uma gambiarra pra debugar RFC executada em background tb.

No codigo do ERP, vc insere um loop infinito no codigo abap que só sai se uma variavel lá for valor = 'X', e inicaliza ela com '' (e coloca o wait up to x seconds pra nao matar o processador).

Daí executa o processo, loga no ERP com o mesmo usuario da RFC Destination, entra na SM50, verifique o work process onde está rodando o loop infinito, e vai em Program/Session -> Program -> Debugging, daí vc "assume" a execucao do programa, edita a variavel pra 'X' sai do loop e continua a execucao. Claro, se o erro que tava dando só acontecer em modo background, vc nao vai ver.

Abs,

Henrique.

[rhviana]

Esse trance é o ECC !

Estamos tentando rastrear.. mais não sei o que pode ser isso.

Apenas um tipo de formulario...

[former_member182114]

Bom dia Ricardo,

Provavelmente tem algum problema neste formulário / configuração de impressão, ou até mesmo o código da BAdI que trata casos e para este vai em algum caminho diferente.

O job tem que ficar ativo sim, e o que está fazendo a dupla impressão são duas coisas:

- retransmissão devido à primeira ter "falhado" - provavelmente a impressão gerou algum MESSAGE na tela e isto "quebra" a RFC e para o GRC fica como "não enviado", por isso cai na backstatus

- na segunda transmissão, o ERP não processa e informa ao GRC um código 109 (se não me engano) tirando da backstatus, porém executa a BAdI novamente e imprime mais uma vez...

- em tese, a segunda impressão poderia ser evitada se na BAdI o check do PRINTD IS INITIAL fosse feito

O melhor é SEMPRE implementar todo este código dentro da CALL_RSNAST00 de forma assíncrona (dica que o Henrique passou acima), e se acontecer algum erro não impactará o GRC e a mensagem fantasma estará visível na SM58.

Outra forma de obter estas mensagens é olhar o log de RFC no lado do GRC, transação RSRFCTRC e procure pelos erros quando chamando a J_1B_NFE_XML_IN_TAB (ctrl + F e procura por XML_IN) a mensagem que aconteceu no ERP estará à frente de ===>

A partir da mensagem de erro procure a solução.

Atenciosamente, Fernando Da Ró

[rhviana]

Fernando,

Estava analisando junto com abap, parece que é um problema interno que está fazendo a conexão quebrar.

*********************************************************

• Somente para Formulário ZF08

IF wk_header-form EQ 'ZF08'.

• Faturamento Hoteis Submarino

PERFORM f_fat_submarino.

ENDIF.

**********************************************************

Estamos vendo aqui, obrigado pela atençao.

[former_member182114]

Bom dia Ricardo,

Muito bom, dica: Pegue todo o código do método CALL_RSNAST00 e coloque numa função RFC para ser chamada assincronamente (dica postada pelo Henrique), além de resolver 100% deste caso tem outra vantagem que vou apontar no relatório para vocês referente a performance... Alguns processamentos no ERP não estão sendo imediatos, provocando delays nas filas do integration server por até 6 segundos, causando delay no processamento de ntoas.

Atenciosamente, Fernando Da Ró