Rejeição NFe - Duplicidade com Diferença na Chave

[Valdir Dill]

Boa tarde,

Gostaria de apresentar uma mensagem mais transparente para o usuário quando ocorrer a rejeição de duplicidade de NFe com diferença na chave.

Para isso eu precisaria capturar a chave retornada na rejeição para, por exemplo, verificar o mês/ano dessa chave, já que esse erro muitas vezes ocorre porque o usuário tenta enviar uma nota hoje, mas que já foi autorizada em mês anterior.
Porém, não estou conseguindo fazer essa capturar da chave.

Quando o retorno vem assim: "Duplicidade de NF-e, com diferenca na Chave de Acesso [chNFe:15180926228562000180650010000102311165735226]", seria até bastante simples, ou seja, bastaria aplicar um onlyNumber(textoRejeicao). Aí ficaria apenas a chave.
Mas esse texto de retorno não é padrão. Além do texto da rejeição acima, às vezes vem "Rejeicao: Duplicidade de NF-e, com diferenca na Chave de Acesso [chNFe: 15181108905700000137550010000015931143828485][nRec:154000407154332]". Possivelmente tenha ainda outros textos de retorno dessa rejeição.Acredito que cada servidor traga o texto em seu layout diferente. 

Se alguém tiver uma dica...

Obrigado.

[Rafael Dias]

Estes textos são retornado pela SEFAZ, não é gerado pelo ACBr.

[Valdir Dill]

7 minutos atrás, Rafael Dias disse:

Estes textos são retornado pela SEFAZ, não é gerado pelo ACBr.

Sim Sim @Rafael DiasEstou ciente disso. Se você olhar bem no post vai ver que inclusive comento que o texto muda em função do servidor que retorna a rejeição.

Meu pedido de ajuda seria mais para ver se algum colega já desenvolveu alguma função para capturar essa chave no texto de retorno ou então que tenha alguma dica para me passar sobre essa situação, entende?

obrigado.

Editado 24 Novembro, 2018 por valdirdill

[Rafael Dias]

@valdirdill desculpa erro meu e não prestar atenção corretamente na sua mensagem, eu pessoalmente não tenho nenhuma função para tratar isso desta maneira.

[Amarildo de Matos]

boa tarde.. voce podera fazer isso no seu proprio sistema.. se olhar o retorno que é o sai,txt e contem essa informação., pegue ela, e filtre no seu codigo fonte.. e ai, voce colocar a 

mensagem que desejar.. 

mas tem de olhar , o porque de estar acontecendo, pois quando da duplicidade, é que voce mandou mais de uma vez, e o xml ja tenha retornado..

o ideal é voce fazer o seguinte:

pegue um certificado de um cliente seu, gere homologaçoes. e faça gerar erro de duplicidade para ver o que voce tera de fazer para resolve-lo..

ok.;

 

[Amarildo de Matos]

capaz.. rafael.. nao foi erro teu nao. tu esta aqui ajudando num sabado.. e tudo ajuda, se tu nao tivesse respondido eu nao teria visto a mensagem dele..

[Valdir Dill]

Bom dia,

Criei a função abaixo que resolve o meu problema. Pelo menos enquanto algum servidor não criar um texto de retorno novo para esse erro, hehe! Compartilho a função para que talvez possa ajudar alguém na mesma situação.

function EhErroDuplicidadeNota(VErro : String; Var VChaveDuplicComDifChave : String) : boolean;
begin
 {formas que essa rejeição retorna:
 1 - "Erro: Nota(s) não confirmadas: XXX->539-Rejeicao: Duplicidade de NF-e, com diferenca na Chave de Acesso
     [chNFe: 15181108905700000137550010000015931143828485][nRec:154000407154332]". XXX é o nr da nota.
 2 - "Rejeicao: Duplicidade de NF-e, com diferenca na Chave de Acesso [chNFe:15180926228562000180650010000102311165735226]";
 3 - "Duplicidade de NF-e, com diferenca na Chave de Acesso. [41180513971229000115650010000000791477402492] [nRec:918000000409987]".}

 result := true;

 VErro := upperCase(TFuncPubl.TiraAcentos(VErro));

 if pos('DUPLICIDADE DE NF-E', VErro) = 0 then exit(false); //se não é duplicidade

 if pos('COM DIFERENCA NA CHAVE DE ACESSO', VErro) = 0 then exit(true); //vai voltar como true pqe é duplicidade. Só não é com difereça de chave.

 VChaveDuplicComDifChave := emptyStr;
 if pos('[NREC:', VErro) > 0 then //retornos 1 ou 3
  begin
   if pos('[CHNFE: ', VErro) > 0 then VChaveDuplicComDifChave := copy(VErro, pos('[CHNFE: ', VErro) + length('[CHNFE: '), 44)
   else VChaveDuplicComDifChave := copy(VErro, pos('[', VErro) + length('['), 44);
  end
 else
  VChaveDuplicComDifChave := copy(VErro, pos('[CHNFE:', VErro) + length('[CHNFE:'), 44); //retorno 2

 if VChaveDuplicComDifChave = emptyStr then exit(true); //vai voltar como true pqe é duplicidade. Só não conseguiu capturar a chave.

 if (VChaveDuplicComDifChave <> emptyStr) and (not ValidaChaveDocEletr(VChaveDuplicComDifChave)) then VChaveDuplicComDifChave := emptyStr; //se retorno não for exatamente como nas 3 opções acima, o copy não retornaria algo, mas seria uma chave não válida.
end;

Abraços.

 

[Italo Giurizzato Junior]

Bom dia a todos,

Valdir, se aparece a mensagem de duplicidade ou duplicidade com diferença na chave, isso significa que a sua aplicação deixa o usuário enviar a mesma nota mais de uma vez.

E isso esta errado.

Quando o usuário clicar no botão de Envio a sua aplicação marca a nota como enviada (no banco de dados) e só remove essa marcação caso a nota venha a ser rejeitada, pois se a nota foi rejeitada ela é passível de correção e um novo envio.

Mas e se ocorreu algum erro de conexão ao enviar?

Simples, a sua aplicação precisa ter um botão de Consulta, este por sua vez vai carregar o XML assinado da nota que foi enviada e que ocorreu erro de conexão e em seguida o método Consultar é executado.

Se ocorreu erro de conexão (timeout por exemplo) não sabemos se ele ocorreu durante o envio ou retorno, concorda?

Pois bem ao realizar a consulta se o problema foi no retorno teremos o status da nota, que pode ser Autorizada, Denegada ou Rejeitada.

Se foi rejeitada devemos remover a marcação de enviado para que o usuário possa fazer as devidas correções e enviar novamente.

Agora se a nota foi Autorizada ou Denegada o XML que esta assinado será atualizado recebendo o protocolo de autorização ou  denegação.

Pode também ser retornado o status 217 que diz que a nota não consta na base de dados.

Neste caso esta claro que o erro de conexão ocorreu no envio, ai sim, devemos enviar a nota novamente.

Valdir, se você seguir essas instruções acima, vai notar que nunca mais terá problemas de Duplicidade de notas.

Espero ter ajudado.

[Valdir Dill]

7 minutos atrás, Italo Jurisato Junior disse:

Bom dia a todos,

Valdir, se aparece a mensagem de duplicidade ou duplicidade com diferença na chave, isso significa que a sua aplicação deixa o usuário enviar a mesma nota mais de uma vez.

E isso esta errado.

Quando o usuário clicar no botão de Envio a sua aplicação marca a nota como enviada (no banco de dados) e só remove essa marcação caso a nota venha a ser rejeitada, pois se a nota foi rejeitada ela é passível de correção e um novo envio.

Mas e se ocorreu algum erro de conexão ao enviar?

Simples, a sua aplicação precisa ter um botão de Consulta, este por sua vez vai carregar o XML assinado da nota que foi enviada e que ocorreu erro de conexão e em seguida o método Consultar é executado.

Se ocorreu erro de conexão (timeout por exemplo) não sabemos se ele ocorreu durante o envio ou retorno, concorda?

Pois bem ao realizar a consulta se o problema foi no retorno teremos o status da nota, que pode ser Autorizada, Denegada ou Rejeitada.

Se foi rejeitada devemos remover a marcação de enviado para que o usuário possa fazer as devidas correções e enviar novamente.

Agora se a nota foi Autorizada ou Denegada o XML que esta assinado será atualizado recebendo o protocolo de autorização ou  denegação.

Pode também ser retornado o status 217 que diz que a nota não consta na base de dados.

Neste caso esta claro que o erro de conexão ocorreu no envio, ai sim, devemos enviar a nota novamente.

Valdir, se você seguir essas instruções acima, vai notar que nunca mais terá problemas de Duplicidade de notas.

Espero ter ajudado.

Bom dia,

Obrigado pelas dicas Italo.

Eu concordo com tudo que você colocou, mas na prática a coisa é um pouco mais complexa do que isso. Sim, com certeza se suas dicas forem colocadas em prática, vai diminuir as rejeições por duplicidade, mas a palavra "nunca", está bem longe de ser uma realidade, hehe!

Veja bem, usuário é capaz de fazer chover quando ele está sozinho operando um sistema.

Tem usuário que reinicia um banco de dados do zero e não atualiza a última nota enviada. Tem usuário que metade das notas ele envia, metade é o contador que envia pelo emissor gratuito. Tem usuário que envia a nota em um mês e só no mês seguinte faz a conciliação. Aí a chave da nota já é outra por causa do mês e a consulta daquela nota retorna como nota não enviada. Enfim, existem várias situações como essas que acabem gerando duplicidade, por mais que façamos um controle.

Mas repito, suas dicas são importantes e, com certeza vão me ajudar a diminuir essas rejeições.

Obrigado.