Retorno de status ACBrNFe1.Consultar para 539: Duplicidade de NF-e, com diferença na Chave de Acesso

[Caique Bendia]

Gostaria de saber  se existe uma forma de diferenciar os ACBrNFe1.WebServices.Consulta.cStat de uma nota com duplicidade de uma nota com Rejeição 539 - Duplicidade de NF-e com diferença na Chave de Acesso?

Estou fazendo uma rotina para corrigir esse tipo de rejeição, porém preciso antes verificar qual dos dois tipos de rejeição a nota se encontra. 

att.

[Juliomar Marchetti]

Bom dia

salvo algum engano 204 duplicidade de nf-e  e o 539 dessa

[Italo Giurizzato Junior]

Boa tarde Caique,

Você na verdade tem dois problemas:

1. Duplicidade de NF-e.

2. Diferença na chave. 

Vou começar pelo segundo.

Quando ocorre a diferença na chave?

A chave de um DF-e Documento Fiscal Eletrônico (no caso NF-e) entre outras coisas possui o valor de cNF = Código da Nota Fiscal que por orientação da SEFAZ tem que ser um código aleatório.

O seu problema é que você esta atribuindo o valor zero ao campo cNF, isso faz com que o componente gere um código aleatório, sendo que o correto seria a sua aplicação gerar esse código e guardar no banco de dados no mesmo registro que contem os demais dados da nota.

Desta forma ao ler os dados da nota para preencher os campos do componente o valor de cNF também seria lido, se essa informação não sofrer alteração toda vez que você gerar o XML da respectiva nota o cNF sempre será o mesmo.

Com essa alteração que estou lhe propondo você não terá mais uma rejeição com diferença de chave.

Agora vamos ao seu primeiro problema.

Se esta tendo problema de Duplicidade é porque a nota esta sendo enviada para a SEFAZ mais de uma vez.

Tenho certeza absoluta que quando ocorre algum erro de internet o procedimento adotado é enviar a nota novamente, correto?

Pois bem esta errado.

Se ocorrer um erro de internet não devemos enviar a nota novamente, pois quem disse a você que o erro ocorreu no envio?

O erro pode ter ocorrido no retorno, logo o procedimento correto é carregar o XML assinado através do método LoadFromFile e em seguida executar o método Consultar.

Se a nota foi enviada com sucesso e foi autorizada o método Consultar vai retornar o protocolo de autorização, como o XML assinado esta carregado, ele será atualizado, ou seja, vai receber o protocolo de autorização, desta forma o XML passar a ter validade jurídica e você pode imprimir o DANFE e enviar por e-mail para o cliente.

Agora se o erro ocorreu no envio da nota, o Consultar vai retornar uma rejeição acusando que a nota não consta na base de dados, ai sim você envia novamente.

 

Para saber mais sobre a chave de um DF-e leia o artigo abaixo:

Leia também:

 

e esse outro:

 

[Caique Bendia]

 

Italo, Muito obrigada! Minha aplicação funciona exatamente assim, farei as mudanças indicadas, e consultar aos tópicos .

 

23 horas atrás, Juliomar Marchetti disse:

Bom dia

salvo algum engano 204 duplicidade de nf-e  e o 539 dessa

Exato  Juliomar ! Obrigada.