Rejeição 539-Rejeicao: Duplicidade de NF-e, com diferenca na Chave de Acesso sem retorno da chave anterior

[Milton Ferreira]

Olá, boa tarde!

Estou com problema SEFAZ / MG quando retorna rejeição 539 não está vindo a chave anterior para tratamento adequado.
Trecho do log:

 

04/10/23 13:49:30:495 - Travar
04/10/23 13:49:30:495 - NFe_Enviar, Limpando Resp
04/10/23 13:49:30:495 - NFe_Enviar, Assinando
04/10/23 13:49:30:501 - NFe_Enviar, Validando
04/10/23 13:49:30:519 - NFe_Enviar, Enviando
04/10/23 13:49:30:685 - NFe_Enviar, Proces.Resp Enviar
04/10/23 13:49:30:686 - NFe_Enviar, Consultando Retorno
04/10/23 13:49:32:834 - NFe_Enviar, Proces.Resp Retorno
04/10/23 13:49:32:835 -    MoverStringParaPChar. StrLen:1128, BufLen:256
04/10/23 13:49:32:835 -    SetRetorno(0, [Envio]
CStat=103
CUF=31
DhRecbto=04/10/2023 13:49:29
Msg=Lote recebido com sucesso
NProt=
NRec=310000083657035
TMed=1
VerAplic=W-3.1.39
Versao=4.00
XMotivo=Lote recebido com sucesso
tpAmb=2

[Retorno]
CStat=104
CUF=31
ChaveDFe=31231007932214000145550010000005481037365217
DhRecbto=
Msg=Nota(s) não confirmadas:548->539-Rejeicao: Duplicidade de NF-e, com diferenca na Chave de Acesso
Protocolo=
VerAplic=W-3.1.39
Versao=4.00
XMotivo=Lote processado
cMsg=0
nRec=310000083657035
tpAmb=2
xMsg=

[NFe548]
Id=
XML=<protNFe versao="4.00"><infProt><tpAmb>2</tpAmb><verAplic>J-3.1.39</verAplic><chNFe>31231007932214000145550010000005481037365217</chNFe><dhRecbto>2023-10-04T13:49:29-03:00</dhRecbto><digVal>N0Cg3jBzWtU1BInaPPms5aGKHQA=</digVal><cStat>539</cStat><xMotivo>Rejeicao: Duplicidade de NF-e, com diferenca na Chave de Acesso</xMotivo></infProt></protNFe>
cStat=539
chDFe=31231007932214000145550010000005481037365217
dhRecbto=04/10/2023 13:49:29
digVal=N0Cg3jBzWtU1BInaPPms5aGKHQA=
nProt=
tpAmb=2
verAplic=J-3.1.39
xMotivo=Rejeicao: Duplicidade de NF-e, com diferenca na Chave de Acesso
)
04/10/23 13:49:32:836 - Destravar
04/10/23 13:49:32:836 - LIB_UltimoRetorno
04/10/23 13:49:32:837 -    MoverStringParaPChar. StrLen:1128, BufLen:1466
04/10/23 13:49:32:837 -    Codigo:0, Mensagem:[Envio][CR][LF]CStat=103[CR][LF]CUF=31[CR][LF]DhRecbto=04/10/2023 13:49:29[CR][LF]Msg=Lote recebido com sucesso[CR][LF]NProt=[CR][LF]NRec=310000083657035[CR][LF]TMed=1[CR][LF]VerAplic=W-3.1.39[CR][LF]Versao=4.00[CR][LF]XMotivo=Lote recebido com sucesso[CR][LF]tpAmb=2[CR][LF][CR][LF][Retorno][CR][LF]CStat=104[CR][LF]CUF=31[CR][LF]ChaveDFe=31231007932214000145550010000005481037365217[CR][LF]DhRecbto=[CR][LF]Msg=Nota(s) n[195][163]o confirmadas:548->539-Rejeicao: Duplicidade de NF-e, com diferenca na Chave de Acesso[CR][LF]Protocolo=[CR][LF]VerAplic=W-3.1.39[CR][LF]Versao=4.00[CR][LF]XMotivo=Lote processado[CR][LF]cMsg=0[CR][LF]nRec=310000083657035[CR][LF]tpAmb=2[CR][LF]xMsg=[CR][LF][CR][LF][NFe548][CR][LF]Id=[CR][LF]XML=<protNFe versao="4.00"><infProt><tpAmb>2</tpAmb><verAplic>J-3.1.39</verAplic><chNFe>31231007932214000145550010000005481037365217</chNFe><dhRecbto>2023-10-04T13:49:29-03:00</dhRecbto><digVal>N0Cg3jBzWtU1BInaPPms5aGKHQA=</digVal><cStat>539</cStat><xMotivo>Rejeicao: Duplicidade de NF-e, com diferenca na Chave de Acesso</xMotivo></infProt></protNFe>[CR][LF]cStat=539[CR][LF]chDFe=31231007932214000145550010000005481037365217[CR][LF]dhRecbto=04/10/2023 13:49:29[CR][LF]digVal=N0Cg3jBzWtU1BInaPPms5aGKHQA=[CR][LF]nProt=[CR][LF]tpAmb=2[CR][LF]verAplic=J-3.1.39[CR][LF]xMotivo=Rejeicao: Duplicidade de NF-e, com diferenca na Chave de Acesso[CR][LF]

 

Alguém com o mesmo problema ou tem algo que estou deixando passar?

[Daniel InfoCotidiano]

Boa tarde @Milton Ferreira
Veja regra de validação:

A propriedade cNF vc salva no banco para usar caso necessite reenviar, consultar a nota.. etc?
Esta gerando com o mesmo cNFE da nota anterior a rejeição?
Se puder anexar o log completo ou nos enviar para [email protected]
No corpo da mensagem, favor colar o link deste post para que possamos identifica-lo
 

[Milton Ferreira]

1 hora atrás, Daniel InfoCotidiano disse:

Boa tarde @Milton Ferreira
Veja regra de validação:

A propriedade cNF vc salva no banco para usar caso necessite reenviar, consultar a nota.. etc?
Esta gerando com o mesmo cNFE da nota anterior a rejeição?
Se puder anexar o log completo ou nos enviar para [email protected]
No corpo da mensagem, favor colar o link deste post para que possamos identifica-lo
 

Boa tarde, 

Não estou enviando com o mesmo número, o processo foi migrado do Monitor para a Lib Java, no monitor não precisava de enviar o mesmo número.
Há alguma diferença no processo?

[Diego Foliene]

6 minutos atrás, Milton Ferreira disse:

Boa tarde, 

Não estou enviando com o mesmo número, o processo foi migrado do Monitor para a Lib Java, no monitor não precisava de enviar o mesmo número.
Há alguma diferença no processo?

O cNF é o um código aleatório que você deve controlar e armazenar.

Veja que ele faz parte do modelo NFe.ini.

Ele faz parte da chave de acesso da NF-e, sendo usado para dar mais segurança a ela.

Se você não controla, toda vez que gera, o componente/monitor/lib se encarrega de gerar um novo para você. Se o cNF for diferente, a chave de acesso inevitavelmente vai ser diferente também.

10 minutos atrás, Milton Ferreira disse:

Boa tarde, 

Não estou enviando com o mesmo número, o processo foi migrado do Monitor para a Lib Java, no monitor não precisava de enviar o mesmo número.
Há alguma diferença no processo?

Você está tentando re-enviar uma NF-e que tentou antes e deu erro?

[Milton Ferreira]

Obrigado pelo retorno de vocês, com a ajuda consegui entender e resolver a situação.

O que acontece? Quando usava o monitor, o XML só era salvo na pasta após a autorização, então quando dava rejeição de duplicidade, o sistema buscava os arquivos na pasta e atualizava o banco de dados com o XML autorizado anteriormente, esse processo ocorria após a rejeição. Dessa forma não era preciso salvar o cNF visto que a informação já estava no XML anterior.
Com a Lib, o arquivo XML é salvo na pasta antes mesmo da autorização, logo se ocorre a rejeição por duplicidade e posteriormente o sistema buscar na pasta, buscará o arquivo sem o protocolo de autorização, então o sistema gerava um novo XML, logo com outro cNF.
Então coloquei o sistema para salvar cNF ainda deu erro de DigestValue ao consultar a nota pq eram arquivos com horários diferentes, então mudei a ordem das coisas. Quando a nota está rejeitada no sistema, antes de tentar realizar a emissão, ele busca na pasta de arquivos, se possuir um XML correspondente autorizado, ele apenas o consulta e salva os dados no banco de dados.
 

Minha explicação ficou um pouco confusa, porém funcionou, aceito sugestões caso exista um processo melhor.

Obrigado!

 

[Daniel InfoCotidiano]

Obrigado por reportar.

Fechando. Para novas dúvidas, criar um novo tópico.