Problemas re-envio NF-e: Cenário NFESC

[Former Member]

Olá,

Sabemos que o cenário NFESC_WebAS_Outbound_NFeStatusCheck (B2B) tem um problema para o re-envio da checagem do status de uma NF-e, quando por algum motivo a checagem não tenha sido efetuada após a entrada na NF-e no GRC.

Temos algumas NF-es com esse problema e tentamos o re-envio do e-mail com essa NF-e para o GRC para que o seu status seja checado, mas isso não está ocorrendo.

Alguém teria alguma idéia do que fazer ou o que pode estar ocorrendo?

Obrigado.

[former_member182114 · Accepted solution]

Bom dia Bruno,

Olhei o código e não vi motivo para um não reprocessamento.

Me diga duas coisas, após mandar o email você encontra as duas interfaces (uma pro B2B e outra pro NFESC) na SXI_MONITOR ?

Atenciosamente, Fernando Da Ró

[Former Member · Accepted solution]

Olá Fernando, tudo bem?

Para essas NF-e re-enviadas, eu não consigo visualizar qualquer entrada na sxi_monitor para a checagem de status. As novas que estão chegando, estão processando numa boa...

Tem alguma idéia?

Obrigado.

Abraços.

Edited by: Bruno Ambrio on Feb 3, 2010 4:49 PM

[henrique_pinto · Accepted solution]

Bruno,

entao sua informacao está errada.

Nao é que a interface NFESC nao seja executada apos entrada da Nota no GRC, aparentemente o caso é que a entrada no GRC nao ocorre!

Note que a camada PI tem diversos mecanismos para evitar envio de mensagem duplicada. Provavelmente ele identificou que a msg que está chegando jah havia sido trafegada e nao está retransmitindo. Como vc está simulando essa retransmissão? File adapter em test mode ou vc está usando Mail adapter e está enviando n vezes o mesmo email pra caixa de entradas de nfe?

Abs,

Henrique.

[former_member182114 · Accepted solution]

Bom dia Bruno,

Muito estranho mesmo, pelo sintoma o comportamento indesejado vem do Mail Adapter e antes das interfaces do GRC.

Faça um teste:

- no Adpter marque a opção Fetch Report (para monitorar no SXI_MONITOR o que está sendo lido no email)

- pegue um XML novo e coloque na sua máquina

- envie este XML por email para a conta ligada ao processamento de NF-e

- verifique tudo que acontece no XI

- envie um novo email com o mesmo XML

- verifique tudo que acontece e nos conte

Atenciosamente, Fernando Da Ró

[Former Member · Accepted solution]

Olá Henrique,

Estou usando Mail Adapter e re-enviando n vezes o e-mail...

Alguma idéia?

Obrigado.

[henrique_pinto · Accepted solution]

Oi Bruno,

como falei, acho que o Mail Adapter bloqueia emails 100% identicos para evitar retransmissao da msg msg n vezes.

Tente mudar o Subject ou, se nao funcionar, algum dado simples dentro do XML (e.g. altere algum dado string, por exemplo, nome da rua).

Abs,

Henrique.

[Former Member · Accepted solution]

Olá Fernando e Henrique,

Desculpe pela demora, estive olhando outras coisas por aqui.

Fiz o teste do Fernando, mas quando ativei o Fetch Report, passou a ocorrer um erro no Canal de Comunicação:

exception caught during processing mail message; com.sap.aii.af.mp.module.ModuleException: com.sap.aii.af.ra.ms.api.DeliveryException: Received HTTP response code 500 : Internal Server Error caused by: com.sap.aii.af.ra.ms.api.DeliveryException: Received HTTP response code 500 : Internal Server Error

Então, eu retirei o flag e voltou a funcionar normal.

Assim, como vc falou, eu enviei uma NF-e (que não existia no GRC), e ela foi checada corretamente. Peguei a mesma e re-enviei e ela foi checada novamente.

Para a NF-e nova (e para a re-enviada também), pude verificar mensagens para ela para o recebimento de e-mail e para o envio ao SEFAZ.

Henrique, eu também fiz o que você falou, troquei apenas alguns dados (nome de rua por exemplo), mas ainda não funcionou.

Teriam alguma luz para resolver?

Agradeço novamente a atenção.

Abraços.

[former_member182114 · Accepted solution]

Bom dia Bruno,

Pelo que entendi seu problema está resolvido.

O que você inicialmente não conseguia agora está conseguindo, não é isto?

Atenciosamente, Fernando Da Ró

[Former Member · Accepted solution]

Olá Fernando,

O problema ainda não foi resolvido...

As notas que eu re-enviei e tive a re-checagem do status, foram notas novas... As antigas, que estão lá paradas há quase 3 semanas, que não estão indo...

Está muito estranho, não?

Abraços.

[henrique_pinto · Accepted solution]

Bruno,

para as msgs que vc nao vê na SXMB_MONI, busque pelo log de processamento da mensagem no adapter pelo Message Monitoring, do RWB (escolha Adapter Engine na opcao Component).

Vah em detalhes e depois no audit log, creio que vc poderá identificar o que está acontecendo com a mensagem.

Abs,

Henrique.

[former_member182503 · Accepted solution]

Bruno,

você já tentou chamar diretamente o proxy para essas NF-e's?

FM /XNFE/005A_NFE_STATUS_OUT, passando o access key e outros dados e analizando o retorno dele via SXI_MONITOR ou até mesmo com break-point de usuário no FM /XNFE/005A_NFE_STATUS_IN

[]'s

José Nunes

[Former Member · Accepted solution]

Henrique e Jose,

Vou fazer o procedimento que vocês me disseram e logo retorno com o resultado.

Obrigado pelas dicas.

Abraços.

[Former Member · Accepted solution]

Bruno,

você já tentou chamar diretamente o proxy para essas NF-e's?

FM /XNFE/005A_NFE_STATUS_OUT, passando o access key e outros dados e analizando o retorno dele via SXI_MONITOR ou até mesmo com break-point de usuário no FM /XNFE/005A_NFE_STATUS_IN

[]'s

José Nunes

Olá José,

Estou tentando executar a função /XNFE/005A_NFE_STATUS_OUT, mas não consigo achar de onde vou puxar os parametros:

IV_VERSION (acho que é 005A não?)

IV_MODUS

IV_VERSNUM

IV_CABEC

Já procurei na chamada ao metodo que o Henrique falou no post (), mas não consegui achar de onde pegá-los

Eu passei alguns parametros para executar, ele executou o cenário NFESC, mas dá um erro no monitor do PI dizendo "Rejeição: Cabeçalho - Falha no Schema XML"...

Poderia me dar uma força?

Abraços.

[former_member182503 · Accepted solution]

Bruno,

IV_NFEID = seu access key

IV_CUF = UF do access key

IV_TPAMB = 2 para homologação / 1 para produção

IV_TPEMIS = 1 para emissão normal

IV_VERSION = 1.07

IV_MODUS = não sei o que preencher aqui, deixe em branco... funciona

IV_VERSNUM = 001

IV_TYPE = 1

IV_CABEC = 1.02

[]'s

[former_member182114 · Accepted solution]

Bom dia Pessoal,

O IV_MODUS:

E = External - usado no B2B de incoming com destinação na /xnfe/xmlin

I = Internal - usado no processo de envio de notas emitidas pela empresa /xnfe/xml

Evitem fazer programas que utilizam-se desta função diretamente com IV_MODUS = I, isto pode fazer o GRC "se perder" pois ele controla rigidamente o Status Query

Quanto ao problema da thread. Tá realmente muito estranho, que diferença existe entre as notas velhas e as novas ? ou talvez entre o XML's velho e os XML's novos ?

São da mesma Sefaz ? ou os antigos de uma e os novos de outra ?

Atenciosamente, Fernando Da Rós

Edited by: Fernando Ros on Feb 9, 2010 12:29 AM

[Former Member · Accepted solution]

José e Henrique,

Obrigado pela força. Descobrimos o erro...

As NF-es que não estavam sendo re-enviadas, eram NF-es de homologação que enviaram para o e-mail de produção. Descobri isso após o José informar que o parametro IV_TPAMB era 1 para produção e 2 para homologação.

Só gostaria de entender se existe alguma rotina que checa se é homologação ou produção antes de fazer a checagem do status da NF-e, pois quando executei a função /XNFE/005A_NFE_STATUS_OUT, foi retornado o erro 217, onde eu o vi pelo sxi_monitor.

Esse erro não deveria aparecer no SAP GRC Monitor?

Obrigado pela ajuda novamente!

Abraços.

[henrique_pinto · Accepted solution]

Sim, o 217 deveria aparecer sim. Soh que qdo vc faz consulta e informa o tpAmb errado, se nao me engano o erro eh diferente (217 = nota nao existe; o erro que daria era "ambiente diverge do informado").

Anyway, verifique se nao há condicao no receiver determination do B2B de entrada que esteja fazendo esse filtro (talvez soh repasse as notas com tpAmb = 1).

Abs,

Henrique.

[Former Member · Accepted solution]

Henrique,

Desculpa pela informação incorreta. Realmente, a mensagem é "Rejeição: Ambiente informado diverge do Ambiente de recebimento (código 252)".

Não configuramos nenhuma condição com o tpAmb no receiver determination. Eu acredito que exista algum lugar no código onde é feita a verificação, comparando o tpamb da NF-e com as configurações do GRC NF-e, por esse motivo, essas NF-es não são sequer enviadas para checagem...

Fernando,

como eu disse acima, essas NF-es antigas, estão com o atributo tpamb (igual a 2) para homologação. Na verdade, essa conta de e-mail que configuramos, já possuia NF-es antes do projeto e alguns fornecedores devem ter enviado essas NF-es para essa conta.

Obrigado.

Abraços.

[henrique_pinto · Accepted solution]

Oi Bruno,

vou checar qdo tiver mais folgado, mas nao lembro de ter nada relacionado a tpAmb na entrada nao.

Abs,

Henrique.

[Former Member · Accepted solution]

Olá Henrique,

Sem problemas. Valeu!

Abraços.