Rejeição de inutilização

[eduardohartmann]

Boa tarde Pessoal,

Estou ajudando com a seguinte situação em um cliente:

O usuário criou uma nota de devolução, através da MIRO, que foi rejeitada pela SEFAZ. Estava retornando o Erro 539 - Duplicidade de NF-e com diferença na Chave de Acesso.

Então foi solicitado o cancelamento da NF para lançar novamente. Porém, retornou o erro 241 Rejeicao: Um numero da faixa ja foi utilizado.

Depois aceitamos a rejeição da inutilização/cancelamento, o que alterou o status para 8-Rejeição de cancelar/ignorar aceito pelo usuário.

Porém, agora não é possível Resetar ou colocar em Contingência, ou cancelar, ou nada. Ficou "travado".

O que poderia ser feito nesse caso?

Verifiquei na consulta de inutilização, o número em questão (3501-2) não está inutilizado, mas tem um beeem lá na frente (35500-2) que está inutilizado - inclusive parece que alguém usou uma série errada, essa numeração na casa dos 35000 é de outra série.

Tem problema emitir NF com numeração inferior a uma já inutilizada? Foram emitidas e autorizadas diversas notas esses dias com numeração inferior ao 35000....

Será que só a inutilização está checando isso?

Obrigado!!

Eduardo

[former_member182114]

Bom dia Eduardo,

Esta nota na MIRO é de sua emissão ou de terceiro? Se for de terceiro o processo não deveria ter ido para Sefaz.

Se for sua, é a situação do tipo "a casa caiu", dois DOCNUM's diferentes com mesmo NUMNFE.

Procure dentro do GRC (por ser mais fácil que no ERP) na tabela /xnfe/nfehd pelo NNF = 3501 e SERIE = 2, é provável que tenha mais de uma chave de acesso na mesma empresa.

Atenciosamente, Fernando Da Ró

[eduardohartmann]

Oi Fernando,

Respondendo na sequencia... é uma NF de devolução emitida pela empresa mesmo. O processo está correto. O problema é outro.

...

[Former Member]

Confirma na SEFAZ se esta nota não esta AUTORIZADA.

Já vi SEFAZ retornar rejeição porem na verdade tinha autorizado. Ai usuario solicitou inutilização e sambou tudo....rs.

At.,

Bernardo Braga

[eduardohartmann]

Oi Bernando,

A NF não consta na SEFAZ, nem como inutilizada nem como autorizada - ao menos com a chave de acesso dela...

Abraço,

Eduardo

[former_member182114]

Bom dia Eduardo,

Verifique no GRC/ERP se você tem esta outra numeração em seu sistema, daí você acha a chave de acesso.

Em sendo isso, você precisa "desnumerar" a segunda nota para resolver a questão.

Atenciosamente, Fernando Da Ró

[eduardohartmann]

...

Respirando um pouco pra contar o problema...

Fernando,

Com a sua indicação de ver na /xnfe/nfehd foi possível identificar o cenário monstro que se desenhou:

1 - Temos um job que pega NF de outro sistema (numeração externa) e cria a NF via BAPI da MIRO no ERP, e envia para o GRC;

2 - Se ocorre algum erro de gravação, o job roda novamente a BAPI, até conseguir criar a NF, ou ser eliminada da fila;

3 - As notas do decouple estão aplicadas, porém não está ativo nos parâmetros - está tudo como branco, ao invés de usar outra opção de envio para o GRC (acho que o 2 seria o melhor nesse caso);

4 - Tinha um problema de configuração/cadastro para gerar a MIRO e a NF, daí o job rodou algumas centenas de vezes, e em cada uma delas foi uma NF para o GRC, porém todas com a mesma numeração, fazendo com que na tabela /xnfe/nfehd tenha todas as chaves de acesso desse NFNUM - estão diferentes pois o número aleatório variou...

A primeira vez que foi enviado, a NF foi pra SEFAZ e foi autorizada... as demais todas foram rejeitadas com o erro 539 - Duplicidade de NF-e com diferença na Chave de Acesso.

Enfim, o resto vcs podem imaginar.

Já sugeri que revisem essa configuração do decouple, e para solucionar o problema da NF em questão creio que vamos "ligar" a NF que foi criada no ERP/MIRO com a chave de acesso que foi autorizada (atualizar no ERP o número aleatório e no GRC o docnum na /xnfe/nfehd).

O restante acho que deve ficar redondo, tirando as centenas de envios indevidos para a SEFAZ...

Mais uma vez, muito obrigado pela força!

Abraço,

Eduardo

[former_member182114]

Siniiiiistro.

Podia até ser pior, ainda bem que tinha apenas 1 no ERP

[henrique_pinto]

O fato de ter apenas um NNF nao elimina o fato de poder terem sido consumidos varios docnums.

Eu continuaria a investigacao...

Abs,

Henrique.

[eduardohartmann]

Vero... Vou pedir para darem uma conferida se tem mais notas que não estão no ERP (J_1BNFDOC) e que estão na /xnfe/nfehd... só pra confirmar se é só 1 mesmo

Abraç

[eduardohartmann]

Henrique,

Foram consumidos diversos DOCNUMs, mas somente um NFENUM, por ser numeração externa - talvez tenha acontecido com mais NFs, isso vamos investigar.

Não consegui visualizar outros possíveis problemas no processo/sistema. Vc ficou com alguma "cisma"? Algum outro ponto que precisaria de uma checagem?

Obrigado,

Eduardo

[henrique_pinto]

Creio que o fato de ter multiplos docnums pode dar algum problema na hora de gerar os livros fiscais (apuracoese SPED Fiscal), pois ele vai reportar multiplas vezes a mesma nota, ou pior, na mesma nota o valor vai ser multiplicado. :PPP

Eu avaliaria isso. Talvez abrir chamado e perguntar se vc deveria deletar os docnums multiplicados na mao.

Abs,

Henrique.

[eduardohartmann]

Creio que poderia dar problema mesmo, mas os documentos não foram criados no ERP, apenas no GRC.

No ERP só tem um documento. Assim, entendo que fiscalmente basta resolver os status dessa nota e o restante está ok.

Sds,

Eduardo

[henrique_pinto]

Ah ok, pensei que tivesse consumido e criado no banco do ERP.

Se só criou no GRC, talvez realmente nao tenha tantos impactos.

Mas de qq maneira, deixa anotado num post it na frente do seu pc, pra qq coisa voltar. 😛

Abs,

Henrique.