Erro 241

[Former Member]

Pessoal:

Hoje tivemos um caso em que as notas retornaram com erro '999' do SEFAZ de Goias. Um usuário tentou inutilizar uma das notas e ela retornou com status 241 (Rejeição: Um número da faixa já foi utilizado). Este status não permite utilizar o botão de Reset.

Alguém já passou por isso e sabe se existe uma solução "tradicional" para consertar este status? Na SEFAZ, a nota esta autorizada

Obrigado,

[former_member182114 · Accepted solution]

Bom dia Luciano,

"tradicional" é sacanagem né..rssss

Seguinte, isto meio que encrenca mesmo, pelo que sei hoje existe esse gap no desenvolvimento. Tinha um chamado tempos atrás para poder fazer o RESET desta tentativa de inutilização e poder reenviar com NFe -> Send, daí acontece o que o Bernardo disse.

Pelo que lembro após o Accept que o Bernardo falou para reenviar teria que "tradicionalmente" fazer o R/3 esquecer que envio para mandar novamente. Este meu conhecimento já tem um tempo então acho que já modificaram.

Tenta aí e dá feedback pro fórum.

Atenciosamente, Fernando Da Ró

[Former Member · Accepted solution]

A opção de aceitar rejeição e tentar enviar de novo não funciona justamente porque ele não atualiza os status da J_1BNFE_ACTIVE e J_1BNFDOC corretamente. O que dá para fazer é tentar cancelar, mas ela volta com o mesmo status.

Parece que a unica solução é alterar os status mesmo, no ERP e no GRC. Vou fazer isso e digo que aconteceu

[former_member182114 · Accepted solution]

Bom dia Luciano,

Assim funciona (na mão): Você fazendo o Accept e voltando ao 999, depois fazendo a o RESET bypassando via debug a tratativa de não é uma situação em que o RESET é viável.

Poderia abrir um chamado à SAP em XX-CSC-BR-NFE? Esta ação é importante para que não precisemos dar o /h para estes eventos provacados por (Sefaz e/ou Usuários, ou os dois juntos ).

Observação: Para algumas situações em que a Sefaz responde 999 esta info é represada no GRC (se não me engano a partir do SP13) e não repassada ao ERP, para que o usuário manualmente dê um "Status Query" e talvez receba a autorização de primeira. Infelizmente, já aconteceram casos em que a Sefaz "guardou" o lote para processar depois, tipo de minutos a horas, e após o usuário efetuar o Status Query e receber um 217 (NF-e não exista na base da Sefaz), tentou o RESET + Envio normalmente e a Sefaz gerou a duplicidade.... Well, coisas do dia dia de NF-e. O chamado é para ter a opção de o usuário se livrar do problema de travamento de status principlamente para esta situação alcançada como 241 onde não dá para inutilizar pois está autorizado, porém o ERP não volta ao status de aguardando a autorização de emissão.

Atenciosamente, Fernando Da Ró

[henrique_pinto · Accepted solution]

Se nao me engano, somente se o 999 ocorrer a nivel de lote que é tratado pelo GRC.

Se ocorrer a nivel de nota, continua voltando pro ERP e causando isto.

Abs,

Henriuqe.

[former_member182114 · Accepted solution]

Sim sim, mas depende de mais duas coisas:

- versão do support package (antes não represava)

- procedimento do usuário que mesmo recebendo um 999 não faz a verificação na Sefaz ou a tentativa de RESET + Envio.

Abraços, Fernando

[Former Member · Accepted solution]

Funcionou alterando algumas tabelas. No entanto, agora tenho que cancelar a nota e esta voltando com erro 215. No xml, o protocolo não está sendo preenchido. Debugando vi que do lado do ERP, na chamada da função /XNFE/NFE_CANCEL, o protocolo esta sendo preenchido. Alguma idéia do que pode ser?

Obrigado,

[former_member182114 · Accepted solution]

Bom dia Luciano,

Sua alteração não foi eficiente.

Você "acertou" os status apenas? E o XML ? Está no KPro?

Cuidado com o problema fiscal de não o ter.

O protocolo de autorização existe na J_1BNFDOC? E na Active? Tem na NFEHD?

Atenciosamente, Fernando Da Ró

[Former Member · Accepted solution]

Realmente, estou checando e nao encontro o xml. Pior do que eu pensava. Alguma sugestão?

Quanto ao protocolo, esta na NFEHD, esta na J_1BNFDOC mas não está na J_1BNFE_ACTIVE porque ao tentar cancelar, ele limpa o conteúdo do AUTHCOD so nesta tablea. Mesmo colocando, ele não funciona também

Acho que neste caso o protocolo é lido diretamente do xml. Como ele não encontra gera o problema. Me parece que é isso.

Obrigado,

Edited by: Luciano Pozzani on Sep 22, 2010 1:00 AM

Edited by: Luciano Pozzani on Sep 22, 2010 1:04 AM

[former_member182114 · Accepted solution]

Bom dia Luciano,

Já que você fez intervenções, sugiro que se basei em uma nota não enviada e comece tudo novamente.

Deixando o ERP e o GRC como se não tivessem enviado.

Daí comece com envio... Vai dar rejeição 204, faça o update status query, depois peça o cancelamento.

Atenciosamente, Fernando Da Ró

[Former Member · Accepted solution]

Encontrei o problema. O protocolo é retirado da /xnfe/xml, campo docid. Esta vazio.

Neste momento, não dá para deixar como se não houvesse enviado porque já tentei fazer um cancelamento. Ou não?

Obrigado,

[former_member182114 · Accepted solution]

Tentou mas não conseguiu.

Se você tem o XML dentro do KPro siga em frente.

Se não, sugiro recomeçar.

Atenciosamente, Fernando Da Rós

good night...

[Former Member · Accepted solution]

Tks, funcionou colocando o numero do protocolo na tabela. No entanto, realmente estou sem o xml de autorização.

Vou procurar como gerá-lo. Aliás, tenho outro caso bastante interessante em que preciso subir um xml gerado externamente direto pelo emissor gratuito para o Kpro. Mas esta é para outro forum.

Obrigado,

Edited by: Luciano Pozzani on Sep 22, 2010 1:40 AM

[Former Member]

Faz o seguinte. Opção aceitar rejeição e depois reenviar pelo SAP.

Ai a nota vai ficar com "Duplicidade" no GRC. Consulta o status da nota pelo monitor GRC, botão "Consulta do status" e pronto.

At.,

Bernardo Braga