Erro digestvalue

[mgmobile]

Boa tarde Srs. 

Novamente venho relatar problemas de digestvalue.

Estou com problemas para anexar o arquivo de log e o xml , pois o arquivo de log esta com 8mb , como devo proceder ?

OBSERVAÇÃO : Este problema passou a acontecer após a versão 1.2.0.67 

[Kiko Fernandes]

Boa noite! Abra ele no notepad e filtre (escolha) as últimas informações ou então apague ou copie o log para outra pasta e comece um novo log e simule o erro e anexe.

[EMBarbosa]

16 horas atrás, mgmobile disse:

Estou com problemas para anexar o arquivo de log e o xml , pois o arquivo de log esta com 8mb , como devo proceder ? 

Sugestão: Passe a criar um arquivo de log por dia. Sempre que iniciar sua aplicação, configure o arquivo de log para uma pasta de logs e com o nome do dia atual.

[mgmobile]

Segue o trecho do arquivo log.txt:

NFe_Arq6687]
Arquivo=C:\xxxxx\NFE\ENVIADOSERECEBIDOS\35190720780884000151550010000066871009966877-nfe.xml
31/07/2019 17:03:30 - NFE.ConsultarNFe("35190720780884000151550010000066871009966877")
31/07/2019 17:03:31 - ERRO: 
DigestValue do documento 35190720780884000151550010000066871009966877 nao confere.
31/07/2019 17:11:46 - ATENÇÃO: Chave RSA Privada NÃO pode ser lida no arquivo "swh.ini".

31/07/2019 17:11:46 - ACBr MonitorPLUS Ver.1.2.0.72
31/07/2019 17:11:46 - Aguardando comandos ACBr
31/07/2019 17:11:46 - Monitorando Arquivos em: 
31/07/2019 17:11:46 - Respostas gravadas em: C:\xxxxx\NFE\RETORNO\
31/07/2019 17:11:47 - Log de comandos será gravado em: C:\ACBrMonitorPLUS\LOG.TXT
31/07/2019 17:12:33 - Dados da Sw.House gravados com sucesso
31/07/2019 17:12:34 - ATENÇÃO: Chave RSA Privada NÃO pode ser lida no arquivo "swh.ini".

35190720780884000151550010000066871009966877-nfe.xml

[José M. S. Junior]

Boa tarde, estamos verificando esta rotina... Mas no ACBrMonitorPlus aba ( DFe/Geral ) tem a opção: "Validar Digest Value ao Consultar XML" tente desmarcar essa opção.

[Italo Giurizzato Junior]

Bom dia,

Será que ao executar o método ConsultarNFe, apesar de estar passando apenas a chave ele não esta achando o XML da nota e após obter o retorno da SEFAZ esta tentando atualizar o XML e ao tentar realizar essa atualização ou seja acrescentar ao XML o protocolo de autorização detecta que o DigestValue da assinatura não confere com o DigestValue retornado pela consulta?

Para mim é a única explicação.

[mgmobile]

Olá Srs.

Veja este caso .  Segue o trecho do log.txt .

 

[mgmobile]

14 minutos atrás, mgmobile disse:

Olá Srs.

Veja este caso .  Segue o trecho do log.txt .

[NFe_Arq1772]
Arquivo=C:\MGMobile\NFE\ENVIADOSERECEBIDOS\35190874289984000109550010000017721009917723-nfe.xml
02/08/2019 10:37:50 - NFE.ConsultarNFe("35190874289984000109550010000017721009917723")
02/08/2019 10:37:51 - OK: Autorizado o uso da NF-e
[Consulta]
CStat=100
CUF=35
ChNFe=35190874289984000109550010000017721009917723
DhRecbto=02/08/2019 09:06:19
DigVal=8v/wMNsQREPuKTinx0WG9nnlN20=
Msg=Autorizado o uso da NF-e
NProt=135190555245065
VerAplic=SP_NFE_PL009_V4
Versao=4.00
XMotivo=Autorizado o uso da NF-e
cMsg=0
tpAmb=1
xMsg=

02/08/2019 10:38:06 - NFE.ImprimirDanfePDF("C:\MGMobile\NFE\XML\35190874289984000109550010000017721009917723-nfe.xml")
02/08/2019 10:38:06 - OK: Arquivo criado em: C:\MGMobile\NFE\PDF\35190874289984000109550010000017721009917723-NFe.pdf
02/08/2019 10:39:26 - NFE.StatusServico
02/08/2019 10:39:27 - OK: Servico em Operacao

 

após desmarcar a opção " validar digest value ao consultar XML"  parou de dar o problema no entanto apresentou outro , erro de lote não processado e na sequencia outra mensagem "Autorizado o uso da NF-e" .

14 minutos atrás, mgmobile disse:

 

 

[José M. S. Junior]

Por favor anexe o log completo com esse erro, isso parece não ter haver com erro e sim o retorno da Consulta retornado pela SEFAZ...

[mgmobile]

40 minutos atrás, José M. S. Junior disse:

Por favor anexe o log completo com esse erro, isso parece não ter haver com erro e sim o retorno da Consulta retornado pela SEFAZ...

 

LOG.TXT

[José M. S. Junior]

Não identifiquei erro de Lote não processado nesse log...

Notei diversas notas com erro de duplicidade, sendo enviada com a mesma chave... neste caso a SEFAZ retorna que Lote foi recebido com sucesso, mas retorna uma rejeição de duplicidade, ou seja, recebeu o lote mas não autorizou...

Este também é o motivo que estava apresentando divergência no DigestValue na consulta. A Nota foi transmitida e autorizada na Sefaz, ao tentar enviar a mesma Nota Criando e enviando Novamente é gerado um XML com novo digestValue, quando o ACBrMonitor está configurado para comparar o digestvalue, o valor retornado na consulta e do xml gravado na pasta do Monitor não são iguais... 

[mgmobile]

44 minutos atrás, José M. S. Junior disse:

Não identifiquei erro de Lote não processado nesse log...

Notei diversas notas com erro de duplicidade, sendo enviada com a mesma chave... neste caso a SEFAZ retorna que Lote foi recebido com sucesso, mas retorna uma rejeição de duplicidade, ou seja, recebeu o lote mas não autorizou...

Este também é o motivo que estava apresentando divergência no DigestValue na consulta. A Nota foi transmitida e autorizada na Sefaz, ao tentar enviar a mesma Nota Criando e enviando Novamente é gerado um XML com novo digestValue, quando o ACBrMonitor está configurado para comparar o digestvalue, o valor retornado na consulta e do xml gravado na pasta do Monitor não são iguais... 

a mensagem de erro de lote apresentou  na tela e na sequencia veio a outra mensagem erro de lote não processado , veja esta imagem .

depois dessa imagem se eu for tentar emitir uma nova nota vai dar erro de duplicidade.

Editado 2 Agosto, 2019 por mgmobile

[José M. S. Junior]

A mensagem de Lote não processado aparentemente não é retornado pelo ACBrMonitor, pode validar pelo log de resposta... (Todo erro é gerado no log do ACBrMonitor) 

A NFe está sendo autorizada no primeiro envio...

[mgmobile]

45 minutos atrás, José M. S. Junior disse:

A mensagem de Lote não processado aparentemente não é retornado pelo ACBrMonitor, pode validar pelo log de resposta... (Todo erro é gerado no log do ACBrMonitor) 

A NFe está sendo autorizada no primeiro envio...

Veja José não vejo muito sentido nisso , pois na versão 1.2.0.67 o sistema funciona perfeitamente , após atualizar para 1.2.0.72 que o problema começa .

[José M. S. Junior]

Se possível anexe o log.txt das duas versões no momento do envio. O fato é que todo erro ou resposta enviado via comando ao ACBrMonitor fica registrado no log e no arquivo resposta. Não gera erro em tela...

Precisamos comparar o log para verificar onde está o problema...

[mgmobile]

2 horas atrás, José M. S. Junior disse:

Se possível anexe o log.txt das duas versões no momento do envio. O fato é que todo erro ou resposta enviado via comando ao ACBrMonitor fica registrado no log e no arquivo resposta. Não gera erro em tela...

Precisamos comparar o log para verificar onde está o problema...

Amigo como disse lá no inicio da conversa o outro log esta com mais de 8mb . Fica complicado  resolver um problema assim . Se quiser eu posso fazer um conferencia com você para voce acompanhar em tempo real .

[José M. S. Junior]

Pode renomear o arquivo de log, assim o ACBrMonitor vai criar um novo log e começar a gravar do zero (Aliás não é bom deixar o arquivo de log ficar muito grande, existe uma configuração para limitar a qtd de linhas do log... ).

Sempre identificamos os possíveis problemas através dos logs. Por isso sempre solicitamos para anexa-los... Caso contrário ficaremos em suposições apenas, pois nos testes locais o envio está ocorrendo normalmente...

[mgmobile]

49 minutos atrás, José M. S. Junior disse:

Pode renomear o arquivo de log, assim o ACBrMonitor vai criar um novo log e começar a gravar do zero (Aliás não é bom deixar o arquivo de log ficar muito grande, existe uma configuração para limitar a qtd de linhas do log... ).

Sempre identificamos os possíveis problemas através dos logs. Por isso sempre solicitamos para anexa-los... Caso contrário ficaremos em suposições apenas, pois nos testes locais o envio está ocorrendo normalmente...

Segue os dois arquivos de logs a imagem do lote processado e os arquivos xlm.

41190809095640000105550010000064951009964958-nfe.xml 41190809095640000105550010000064981009964984-nfe.xml LOG-1.0.2.67.TXT LOG-1.0.2.72.TXT

[José M. S. Junior]

A mensagem refletida no seu sistema, não está com a mesma descrição da mensagem retornada pela SEFAZ, por isso está confundindo...

O erro retornado pela SEFAZ é de Duplicidade de NFe, ou seja já existe uma NFe autorizada com essa chave, quando tentou enviar...

[Retorno]
CStat=104
CUF=41
ChaveDFe=41190809095640000105550010000064951009964958
Msg=Nota(s) não confirmadas:
6495->204-Duplicidade de NF-e [nRec:411110218343545]
Protocolo=
VerAplic=PR-v4_4_7
Versao=4.00
XMotivo=Lote processado
cMsg=0
nRec=411110218346720
tpAmb=2
xMsg=

Já a mensagem de Autorizado o Uso, se refere a Consulta que realizou após a tentativa de envio. A SEFAZ retornou que a NFe já se encontra autorizada..

05/08/2019 14:08:30 - NFE.ConsultarNFe("41190809095640000105550010000064951009964958")
05/08/2019 14:08:30 - OK: Autorizado o uso da NF-e
[Consulta]
CStat=100
CUF=41
ChNFe=41190809095640000105550010000064951009964958
DhRecbto=02/08/2019 14:50:59
DigVal=JPUA5XOMwrSDvO74/UrCpIDep8k=
Msg=Autorizado o uso da NF-e
NProt=141190000663106
VerAplic=PR-v4_4_7
Versao=4.00
XMotivo=Autorizado o uso da NF-e
cMsg=0
tpAmb=2
xMsg=

No retorno de Envio da NFe, sua aplicação deve ler o grupo [Retorno] e tag "Msg" e "cStat", pois o envio é Assíncrono, ou seja, o lote pode ser recebido com sucesso, mas o retorno pode relatar um problema, como esse de duplicidade de chaves..

[mgmobile]

10 minutos atrás, José M. S. Junior disse:

A mensagem refletida no seu sistema, não está com a mesma descrição da mensagem retornada pela SEFAZ, por isso está confundindo...

O erro retornado pela SEFAZ é de Duplicidade de NFe, ou seja já existe uma NFe autorizada com essa chave, quando tentou enviar...

[Retorno]
CStat=104
CUF=41
ChaveDFe=41190809095640000105550010000064951009964958
Msg=Nota(s) não confirmadas:
6495->204-Duplicidade de NF-e [nRec:411110218343545]
Protocolo=
VerAplic=PR-v4_4_7
Versao=4.00
XMotivo=Lote processado
cMsg=0
nRec=411110218346720
tpAmb=2
xMsg=

Já a mensagem de Autorizado o Uso, se refere a Consulta que realizou após a tentativa de envio. A SEFAZ retornou que a NFe já se encontra autorizada..

05/08/2019 14:08:30 - NFE.ConsultarNFe("41190809095640000105550010000064951009964958")
05/08/2019 14:08:30 - OK: Autorizado o uso da NF-e
[Consulta]
CStat=100
CUF=41
ChNFe=41190809095640000105550010000064951009964958
DhRecbto=02/08/2019 14:50:59
DigVal=JPUA5XOMwrSDvO74/UrCpIDep8k=
Msg=Autorizado o uso da NF-e
NProt=141190000663106
VerAplic=PR-v4_4_7
Versao=4.00
XMotivo=Autorizado o uso da NF-e
cMsg=0
tpAmb=2
xMsg=

No retorno de Envio da NFe, sua aplicação deve ler o grupo [Retorno] e tag "Msg" e "cStat", pois o envio é Assíncrono, ou seja, o lote pode ser recebido com sucesso, mas o retorno pode relatar um problema, como esse de duplicidade de chaves..

DEsculpe mas sua resposta não ficou clara . Ainda não consegui compreender porque na versão 1.2.0.67 não apresentava isso e na versão 1.2.0.72 esta apresentando.

[Italo Giurizzato Junior]

Boa tarde,

O ACBrMonitor esta sempre sofrendo correções e ou melhorias, pode ser que alguma dessas alterações passou a apresentar essa mensagem.

Uma coisa é certa a sua aplicação deixa o usuário enviar a mesma nota mais de uma vez e isso esta errado, uma prova disso é a rejeição por duplicidade.

Se após o envio não tiver o retorno que acusa que a nota foi autorizada ou não, o passo seguinte é realizar uma consulta e não enviar novamente.

Ao consultar se a nota realmente foi enviada e autorizada teremos o protocolo de autorização ou a rejeição acusando a informação errada.

Por outro lado se ocorreu algum erro no envio, a consulta vai nos informar que a nota não existe no banco de dados da SEFAZ.

Devemos liberar o usuário para enviar novamente a mesma nota quando a mesma for rejeitada com alguma informação errada, ou se a mesma não consta na base de dados.

Lembrando que se a nota foi rejeitada, antes do usuário enviar novamente deve corrigir a informação errada.

 

[José M. S. Junior]

44 minutos atrás, mgmobile disse:

DEsculpe mas sua resposta não ficou clara . Ainda não consegui compreender porque na versão 1.2.0.67 não apresentava isso e na versão 1.2.0.72 esta apresentando.

No log da versão anterior, não retornou rejeição de duplicidade de chave, foi autorizada... 

Por algum motivo na versão atual os dados que você está passando para geração da NFe é de uma NF que já foi autorizada na SEFAZ, inclusive com o mesmo número...