Atualização GRC / Monitor J1BNFE

[adrianafernanda_simes]

Boa tarde!

Pessoal,

Podem me ajudar com a questão abaixo?

A usuária solicitou o cancelamento de uma NFe e neste momento estava acontecendo atualização do mensageria. A NFe foi autorizada (código SEFAZ 100) e cancelada (código SEFAZ 101), porém no monitor não houve atualização, somente no GRC vejo que está tudo ok. Estou com dúvida agora, porque eu poderia fazer a atualização pela SE37 na função J_1B_NFE_XML_IN. Mas como ela foi cancelada, não tenho o docnum de estorno. Como devo proceder?

A mesma coisa ocorreu com uma nota que estava rejeitada, mas o erro apontado foi corrigido, neste caso está mais fácil, pois é só eu informar o protocolo, o código 100, status 1 e docnum que permanece o mesmo.

Aguardo comentários.

Obrigada.

Adriana Simões

[henrique_pinto · Accepted solution]

Olá Adriana,

nao entendi, no ERP o status da NFe na J1BNFE é "em processamento" (engrenagem)?

Se sim, o GRC deveria tentar reenviar o status automaticamente, através do job /XNFE/UPDATE_ERP_STATUS. Verifique se esse job foi schedulado e se a nota em questao está na tabela /XNFE/BACKSTATUS.

De qq maneira, se quiser resolver manualmente, bastaria que vc chame a J_1B_NFE_XML_IN_TAB com a chave de acesso ou docnum original, protocolo de cancelamento (vc vê no campo NPROT da /XNFE/XML do GRC, para a entrada de cancelamento c/ TYPE = 2 ou no XML de cancelamento) e msg type = 4 (cancelamento autorizado). Se vc fez o processamento normal de cancelamento, nao existe docnum de cancelamento ainda (o documento só é estornado no ERP quando da volta da autorizacao da SEFAZ).

Att.

Henrique.

[former_member182114 · Accepted solution]

Bom dia Adriana,

Verifique se o registro que você está no GRC e não "chegou" no R/3 está na tabela /XNFE/BACKSTATUS (contém os params necessários à IN_TAB). O report que o Henrique comentou lê os registros não processados desta tabela.

Outra coisa, apesar de ser possível processar diretamente no R/3 através da função J_1BNFE_XML_IN_TAB recomendo fortemente que você tente fazer isto através do report a partir do GRC, pois pode ter alguma situação relativo ao usuário da RFC GRC-> ERP, que tem que ser mapeado para evitar problemas em produção.

Lembrando que ao retornar cancelamentos a função IN_TAB irá disparar os cancelamentos relativos à NF-e então o usuário da RFC GRC->ERP tem que logar no mesmo idioma (devido a customizing client dependant) e ter os direitos para realizar tais cancelamentos.

Atenciosamente,

Fernando Da Rós

Edited by: Fernando Da Ros on Apr 7, 2009 12:16 AM

[adrianafernanda_simes · Accepted solution]

Boa tarde!

Fernando,

Preciso de um help.

O processo é: o usuário emite a NFe, recebe a autorização da SEFAZ (100) e por algum motivo ele resolve cancelar, após a solicitação de cancelamento, o status se altera no monitor (J1BNFE), o GRC processa e fica com status de OK dizendo que a NFe está cancelada. Porém, quando voltamos para o monitor (J1BNFE) a nota não foi atualizada, ou seja, fica com o status 100 e não 101 e sem o retorno (bandeira verde) de ok.

Isso está ocorrendo com frequencia.

O que poderia estar causando isso? Digo: a SEFAZ autoriza, o GRC é atualizado, mas o ECC não recebe a atualização.

Att.

Adriana Simões

[former_member182114 · Accepted solution]

Bom dia Adriana,

Esta questão do retorno ao ERP merece inclusive uma thread nova. E não tem uma resposta exata para cada problema, porém algumas coisas que podem ser.

Antes da Nota Fiscal Eletrônica, cada usuário era responsável pelo cancelamento de seus processos, então ele deveria ter todos os direitos possíveis e este cancelamento era executa ON-LINE e qualquer tipo de erro era exibido no mesmo instante para o usuário.

Com a Nota Fiscal Eletrônica, deve-se antes de cancelar solicitar autorização da Fazenda, então quem irá de fato executar as transações de cancelamento passou do usuário solicitante ao usuário da RFC de retorno sentido GRC --> ERP, daí reside diversos problemas que podem ser:

1) RFC GRC --> ERP não está logando no mesmo idioma dos usuários do R/3. Problema: Existem algumas configurações que são dependente de idioma e nem todos os clientes mantém estes textos para todos os idiomas. Como é comum usuários de comunicação serem configurados em inglês, isto tem sido um erro comum. Verificar / adequar na SM59 do GRC o idioma de logon.

2) Direitos do usuário - O usuário desta mesma RFC está sem os devidos direitos para proceder com o cancelamento no R/3. Para teste coloque um usuário SAP_ALL na RFC e faça um teste, se for isso vc deve adequar os direitos do usuário.

3) As vezes funciona... --> A mensageria e a Sefaz tabalham com "nota fiscal" independente de que processo gerou, porém o ERP ao proceder o cancelamento irá gerar a transação correta conforme o processo que o gerou (SD, MM, Writer...), além de incluir dados em FI/CO, conforme processo.

Se já realizou os passos anteriores e ainda assim está com problemas, sugiro executar diretamente no R/3 a RFC que o GRC executa J_1B_NFE_XML_IN_TAB, os parâmetros podem ser obtidos da tabela /XNFE/BACKSTATUS do GRC. Esta tabela contém todos os registros enviados e recusados pelo ERP.

OBSERVAÇÃO PERTINENTE: Só utilizem esta função para testes desta natureza. NUNCA para "autorizar" o ERP, deixando de lado algum status preso no GRC. Isto poderá gerar maiores problemas pois o GRC é o guardião do status autorizado, bem como do XML.

Atenciosamente,

Fernando Da Ros

-

-

---

Esta questão está resolvida ? Dê feedback. Se estiver marque como resolvida.

[Former Member · Accepted solution]

Ola Adriana

Quando a nota esta autorizada ficao no monitor status 1 de autorizada e 0 .

Quando voce pede no monitor para cancelar ele fica com a engrenagem e o status fica 1 e 1 - pedido de cancelamento

Quando o GRC responde OK no monitor deve ficar 1 de autorizada e 2 de autorizado o cancelamento, E a nota no sap fica cancelada

As vezes que este processo ficou para do comigo, sempre tinha um log, a bandeira ficava vermelha.

Neste log tinha uma mensagem de erro em algum batch input.

se era um faturamento seria um erro na VF11.

Isso aconteceu porque meu usuario de comunicacao nao tinha perfil para fazer nenhuma transacao de cancelamento

O monitor no cancelamento faz VL09, ou VF11 , ou MR8M ou MBST ou J1B3N . Entao ficava dando erro na hora de cancelar no sap.

Isso aconteceu tambem quando algum doc do processo estava aberto em outra tela. Ai o sap nao consegue cancelar.

E isso aconteceu em um processo que um programa Z cria a nota writer mas coloca na referencia um doc faturamento de referencia que nao gera NF. O sap quando ve a referencia BI tentava cancelar o doc faturamento e isso dava erro porqeu na verdade a nota foi criada por uma J1B1N e deveria ser cancelada pela J1B3N

Espero ter ajudado

Renata Hopp

E o GRC fica mandando a resposta varias vezes.

[Former Member · Accepted solution]

Bom dia a todos, gostaria de saber se podem me ajudar , eu estou com um problema pois estou fazendo testes de alguns cenários no ambiente QAS, por um problema de configuração perdeu-se o caminho para a validação das notas , mas ja arrumamos e o que aconteceu, algumas notas ficarm presas na engrenagem , entrei no GRC do QAS e liberei as notas mas na J1BNFE as notas não atualizam continuam presas na engrenagem, alguém poderia me ajudar.