Solicitar estorno de NFe não está sendo executado

[Former Member]

Olá,

estamos com todo o cenário de NFe 2.0 para todas as nossas filiais testadas e validadas, exceto o processo de cancelamento de NFe. Ao "solicitar estorno" da NFe a mesma fica com a "engrenagem" como status e não há retorno algum. Checamos a NFe na SEFAZ e a NFe não está estornada. A impressão é de que o GRC não está recebendo/agindo após o ERP disparar a solicitação de estorno.

Alguém tem alguma idéia do que pode estar faltando aplicar? Estamos no patch 15 do SLL-NFE e gostaríamos de evitar de aplicar o patch 16, pois teríamos que realizar todos os testes novamente.

Grata,

Lucimara

[Former Member]

Lucimara, boa tarde

estou exatamente com o mesmo problema que o seu em um cliente.

Você poderia nos enviar o trecho modificado e o novo código com a correção?

Verifiquei a nota e a SAP ainda não atualizou a nota...

obrigado

[Former Member]

Olá Ariel,

é só comentar o código abaixo:

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

programa J_1BNFE_MONITOR_F06

***

IF wa_nfe_alv-tpemis IS NOT INITIAL. "1454408

SHIFT wa_nfe_alv-docnum9 LEFT. "1454408

ENDIF. "1454408

Abraço,

Lucimara

[Former Member]

Lucimara com todo respeito vc merece um beijo! rsss

Muitissimo obrigado! estamos com este problema a algumas semanas... e deu certo!!!!

obrigado pela ajuda

um grande abraç

[Former Member]

SLL-NFE SP15 sei não.....acho que precisa pelo menos das notas do 16 para rodar redondo.

At.,

Bernardo Braga

[former_member193386]

nao, nao precisa, mesmo no 15 ela deveria estar conseguindo fazer a inutilizacao

[henrique_pinto]

Lembro de um prob com assinatura de cancelamento no SP15.

Eu tb atualizaria logo pro SP17.

Abs,

Henrique.

[former_member193386]

Se eu nao me engano, tem uma nota que corrijia isso tbem. Por isso de perguntar se tem erro na sxi_monitor

[former_member182114]

Carlos, respira antes de responder... tem pessoas ouvindo que podem interpretar mal o que vc tá dizendo.

nao, nao precisa, 

O SP mínimo para trabalhar com layout 2.0 é o SP17 ou SP15 + todas as notas subsequentes até o SP17. Traduzindo SP17.

mesmo no 15 ela deveria estar conseguindo fazer a inutilizacao

Correto

@Lucimara,

Não vá a produção sem o SP17, existem problemas nas interfaces do NFESC que tem problemas conhecidos e corrigidos. Além de erros de validação e melhorias. Quanto aos testes, as modificações não chegam a modificar o comportamento requisitando retestar 100% dos cenários, mas sim teste básico de funcionamento, basicamente é estabilização do suporte ao layout 2.0.

Voltando à questão original. Para entendermos o que está acontecendo, onde o processo está parado, precisamos dos status do ERP e do GRC:

ERP: J_1BNFE_ACTIVE: DOCSTAT, SCSTA e MSSTAT

GRC: /xnfe/nfehd-STATCOD e /xnfe/nfe_hist-WASSTAT e /xnfe/nfe_hist-ERROR_STATUS

Atenciosamente, Fernando Da Ró

[Former Member]

Olá Fernando,

J_1BNFE_ACTIVE-DOCSTAT = 1

J_1BNFE_ACTIVE-SCSTA = 1

J_1BNFE_ACTIVE-MSSTAT = A

/xnfe/nfehd-STATCOD = 100

/xnfe/nfe_hist-WASSTAT = 5

/xnfe/nfe_hist-ERROR_STATUS = " "

Grata,

Lucimara

[former_member182114]

Bom dia Lucimara,

Não há registro que o GRC recebeu o pedido de cancelamento, apesar do ERP ter o SCS próprio.

Marque a NF-e no monitor J1BNFE e tente a opção NF-e -> Request Canc.Again.

Atenciosamente, Fernando Da Ró

[former_member193386]

Lucimara, no PI, execute a transacao SXI_MONITOR e veja se existe algum erro reportado lá

[former_member193386]

Ola Lucimara

O que está aocntecendo podem ser duas hipoteses:

1) Vcs nao aplicaram o decouple e o documento pode estar bloqueado para atualizacao, mas isso só ocorre com alguns documentos

2) A solucao de NFe, quando o GRC recebe a confirmacao de cancelamento/inutilizacao, aprovada pelo SEFAZ ele dispara a atualizacao dos dados no ECC, o processo no ECC, inclui o extorno do documento, caso exista algum problema com o estorno, o status da nfe fica pendente de atualizacao pelo GRC pois o processo dá rollback em todo o processo do retorno do status DENTRO do ECC, que é o mais comum, valide com o funcional se o extorno standart do documento esta ok.

[henrique_pinto]

Ela disse que nao está estornada na SEFAZ.

@Lucimara,

no monitor de NFe do GRC, qual o status do processo da nota em questão?

E, se houver, qual o status de erro?

Abs,

Henrique.

[former_member193386]

nao me atentei a esse detalhe Henrique, valeu por lembrar.

[Former Member]

Olá Henrique,

Status do documento = 1

Status comunicação do sistema = 1

não há mensagem de erro no ERP.

Olá Carlos,

nenhum erro no monitor do GRC também.

estou investigando a aplicação do decouple.

Obrigada pelo apoio!

Lucimara

[former_member193386]

Lucimara e o restante dos status que o fernando pediu

[henrique_pinto]

Lucimara,

esses status sao do monitor do ERP (J1BNFE).

Eu perguntei os status do GRC, na tela webdynpro "Monitor de NFe".

Abs,

Henrique.

[Former Member]

Fernando,

mesmo solicitando novamente o estorno, os status continuam os mesmos.

Henrique,

seguem os status do monitor do GRC:

status do processo = 5

status de erro = " "

código status = 100

Att,

Lucimara

[henrique_pinto]

O tipo de NFe (NFe type) está = 1?

Parece que a msg nem chega no GRC msm.

O MSSTAT no ERP está = A ou B?

Abs,

Henrique.

[former_member182114]

Bom dia Lucimara,

Ao fazer a operação Resend você está recebendo algum tipo de erro na tela?

No log da NF-e (coluna NF-e Log na J1BNFE) está com bandeira vermelha? Se sim, que erro tem por lá?

Qual o conteúdo do campo ACTU_REQU (process step)? O ícone está na engrenagem ?

Você tem autorização para efetuar o cancelamento?

Aconteceu algo de especial com esta NF-e para ficar nesta situação?

Atenciosamente, Fernando Da Ró

[Former Member]

Henrique,

NFe type = 1

MSSTAT = A

Att.,

Lucimara

[henrique_pinto]

Além do que o Fernando falou, veja tb na SM58 do ERP e do GRC se há alguma msg de erro.

Abs,

Henrique.

[Former Member]

Olá Fernando,

seguem as respostas:

Ao fazer a operação Resend você está recebendo algum tipo de erro na tela? Assim que solicito o novamente o estorno, recebo a mensagem "Processamento NF-e correto" no rodapé do J1BNFE.

No log da NF-e (coluna NF-e Log na J1BNFE) está com bandeira vermelha? Se sim, que erro tem por lá? Está com a bolinha verde.

Qual o conteúdo do campo ACTU_REQU (process step)? O ícone está na engrenagem ? O campo etapa está vazio e o ícone está na engrenagem.

Você tem autorização para efetuar o cancelamento? Sim.

Aconteceu algo de especial com esta NF-e para ficar nesta situação? Não, qualquer NF-e que tento cancelar ocorre o mesmo problema.

Att.,

Lucimara

[Former Member]

Olá Henrique,

nenhuma mensagem de erro no SM58.

Att.,

Lucimara

[former_member193386]

e na smq2 no ambiente GRC ?

[former_member182114]

Bom dia Lucimara,

Tá difícil de achar alguma evidência...

Se você criar uma NF-e agora, receber a autorização e logo em seguida pedir cancelamento mesmo assim acontece?

Verifique no GRC, transação ST22 se tem erro.

Se não tiver erro, faça um teste de ir direto ao GRC e pedir o cancelamento via SE37, função /XNFE/NFE_CANCEL.

IV_ID = chave de acesso

IV_LOGSYS = sistema lógico do ERP

IV_AUTHCOD = protocolo da autorização de emissão

IV_TPAMB = ambiente

IV_SYNCRON = X

IV_XJUST = justificativa do cancelamento

Observe se tem alguma mensagem de erro na execução direta na resposta da SE37 e o conteúdo de retorno EV_MSGTYP.

Atenciosamente, Fernando Da Ró

[henrique_pinto]

Lucimara,

só pra confirmar: inutilizacao funciona mas cancelamento nao?

Ou ambos nao funcionam?

Se forem ambos, pode ser um problema de comunicacao.

Já vi uns casos em que msgs RFCs assincronas simplesmente nao chegavam no lado destino, nao lembro a razao.

Abs,

Henrique.

[Former Member]

Bom dia!

Carlos, nenhuma entrada na SMQ2.

Fernando,

Se você criar uma NF-e agora, receber a autorização e logo em seguida pedir cancelamento mesmo assim acontece? Sim, o mesmo problema ocorre.

Verifique no GRC, transação ST22 se tem erro. Nenhum erro na ST22.

Se não tiver erro, faça um teste de ir direto ao GRC e pedir o cancelamento via SE37, função /XNFE/NFE_CANCEL.

IV_ID = chave de acesso

IV_LOGSYS = sistema lógico do ERP

IV_AUTHCOD = protocolo da autorização de emissão

IV_TPAMB = ambiente

IV_SYNCRON = X

IV_XJUST = justificativa do cancelamento

Observe se tem alguma mensagem de erro na execução direta na resposta da SE37 e o conteúdo de retorno EV_MSGTYP.

nenhuma mensagem na execução direta da SE37. O conteúdo de retorno EV_MSGTYP = B.

Henrique,

só pra confirmar: inutilizacao funciona mas cancelamento nao?

Ou ambos nao funcionam? Ambos não funcionam.

Att.,

Lucimara

[former_member182114]

Bom dia Lucimara,

Seus testes indicam que o GRC está recebendo e processando o cancelamento.

O problema deve estar na ligação assincrona como o Henrique mencionou ou codificação. Tem certeza que não tem nada na SM58 no GRC? Tentou com user = *

Sugiro um break-point na função J_1B_NFE_SEND_REQUESTS focando a chamada ao form call_xnfe.

Atenciosamente, Fernando Da Ró

[Former Member]

Olá Fernando,

A SM58 não traz nada mesmo. Quanto a função, foi debugada, ele chega até a função que cancela a NFe e retorna como B-MS Received: Cancellation Request.

Vamos aplicar o patch 17.

Agradeço a todos pelo esforço em resolver o problema. Espero que após a aplicação do patch tenhamos sucesso e o erro seja resolvido.

Abraço,

Lucimara

[former_member182114]

Bom dia Lucimara,

Aplique sim o SP17, porém não pelo motivo desta thread (pelo menos ainda não confirmamos a root cause...rss)...

Via debug chegou no GRC (pelo menos o B indica isso), certo?

O que aconteceu depois, os status mudaram por lá?

Na RFC do ERP para o GRC você está com um usuário de logon no GRC? Tem direito de debug?

Tente debugar a função /xnfe/nfe_cancel e verifique o que acontece por lá...

Atenciosamente, Fernando Da Rós

Edited by: Fernando Ros on Jan 13, 2011 3:10 PM

[henrique_pinto]

Lucimara,

o fato de ser em ambos e o fato de, em debug, funcionar, parece indicar que o problema é de fato na comunicacao assincrona.

Nesse caso, se for isso mesmo, o problema nao será resolvido com update do GRC apenas, necessita avaliar a causa de as msgs RFCs assincronas nao estarem sendo enviadas a partir desse ERP.

Abs,

Henrique.

[Former Member]

Olá Henrique,

Acabou ocorrendo o que você previu. Aplicamos o patch 17 e o problema não foi resolvido.

Você sabe se há alguma nota específica relacionada as mensagens RFCs assincronas?

Grata,

Lucimara

[henrique_pinto]

Lembro que era alguma razao relacionada a Basis (tipo, alguma fila que tinha q ser executada, ou algum job a ser schedulado).

Infelizmente, nao lembro da solucao...

Abs,

Henrique.

[former_member182114]

Bom dia Lucimara,

Por favor abra um chamado em XX-CSC-BR-NFE, tem alguns detalhes que ficam melhor vistos "in locu".

Depois você atualiza a thread com o resultado.

Atenciosamente, Fernando Da Ró

[carloshenrique_penteado]

Senhores,

Dei uma analisada neste problema, no ambiente do cliente, devido à demora da SAP no atendimento do chamado.

Identifiquei que a chave de acesso não está sendo gerada de acordo. O novo campo TPEMIS do layout 2.0 não está sendo preenchido para CANCELAMENTO, apenas emissão da NFe.

Analisei o ponto da J_1B_NFE_SEND_REQUESTS antes do envio ao call_xnfe.

Isto pode justificar o não recebimento da solicitação de cancelamento do lado do GRC?

O SP17 já não deveria ter ajustado todos os pontos necessários de geração de Chave de Acesso.

Obrigado desde já,

Carlos Penteado.

[former_member182114]

Bom dia Carlos,

A geração da chave de acesso é feita pelo ERP, não pelo GRC.

Este caso de cancelamento é inutilização? Em sendo cancelamento de nota autorizada, não tem mudança de chave de acesso.

Atenciosamente, Fernando Da Ró

[Former Member]

Bom dia!

o problema que estávamos com cancelamento/inutilização na versão 2.0 foi finalmente resolvido.

A SAP identificou um trecho incorreto do programa abaixo que está na nota 1454408 para nossa versão 603. Corrigimos o código manualmente e funcionou. A SAP irá realizar a correção na nota também.

Agradeço a todos os que participaram nesta thread tentando nos ajudar.

Abraço,

Lucimara Martins

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

programa J_1BNFE_MONITOR_F06:

***

IF wa_nfe_alv-tpemis IS NOT INITIAL. "1454408

SHIFT wa_nfe_alv-docnum9 LEFT. "1454408

ENDIF. "1454408