NF-e Consulta pelo xml DigestValue não confere

[DOCFABIO]

Boa Tarde a todos.

Tenho uma NF-e autorizada em homologação. Quando uso a função de consultar ela altera o DigestValue do xml, na primeira vez aparentemente dá certo, mas se consultar de novo vai dar a mensagem "DigestValue do documento 43150905883223000168550010000007171000007170 não confere."

Rotina:
       dm.ACBrNFe1.NotasFiscais.Clear;
       dm.ACBrNFe1.NotasFiscais.LoadFromFile(43150905883223000168550010000007171000007170-nfe original.xml);
       dm.ACBrNFe1.Consultar;

 

Resultado: "DigestValue do documento 43150905883223000168550010000007171000007170 não confere." 
Realmente o digestvalue foi alterado ao Consultar.

Em anexo os 2 arquivos.

Desde já agradeço qualquer dica.

Ps.: Trunk2 atualizado hoje.

43150905883223000168550010000007171000007170-nfe original.xml

43150905883223000168550010000007171000007170-nfe.xml

Editado 14 Setembro, 2015 por DOCFABIO

[Italo Giurizzato Junior]

Boa tarde Fabio,

Seria interessante neste caso termos o XML de retorno do envio que consta o primeiro DisgestValue e o de retorno a consulta.

Desta forma vamos saber quem esta gerando o DisgestValue errado.

[DOCFABIO]

O primeiro arquivo de retorno não tenho mais pois ele substituiu mas anotei antes o digestvalue: <DigestValue>umMI0sLsacDVEwadMFJSRmH53v8=</DigestValue>

E o último arquivo de retorno da consulta em anexo. Nele aparentemente está o correto, mas quando salva o xml final ele grava outro digest (anexo lá em cima). <DigestValue>NKASAfX5hiw6qvpL8yRSYBYuLGg=</DigestValue>

 

43150905883223000168550010000007171000007170-sit.xml

[Italo Giurizzato Junior]

Bom dia Fabio,

Descobri o motivo de estar gerando um novo DigestValue.

O XML "original" não possui a TAG <nItemPed> já o outro possui, isso faz com que ao assinar novamente tenhamos um novo DigestValue.

A TAG nItemPed é opcional, e por se tratar de uma informação numérica do tipo inteiro, o componente não gera a TAG se o valor for zero, mas a TAG foi gerada justamente com o valor zero na segunda vez, porque?

Vamos a um teste, ao executar o LoadFromFile passe como segundo parâmetro o valor False, isso vai fazer com que o componente não gere o XML novamente.

Exemplo:

dm.ACBrNFe1.NotasFiscais.Clear;
dm.ACBrNFe1.NotasFiscais.LoadFromFile(sNomeXML, False);
dm.ACBrNFe1.Consultar;

[DOCFABIO]

Então tá explicado. Eu realmente tenho que manipular essa tag <nItemPed> assunto já tratado aqui (http://www.projetoacbr.com.br/forum/topic/19850-campo-nitemped-integer-para-string/#comment-133948), altero o fonte do acbr para usar essa tag como string e não integer em razão de uma multi-nacional que exige receber o xml com esse campo preenchido assim: 00123 se o campo for inteiro vai cortar o zero na frente e eles não aceitam, dá erro pra eles na hora de importar xml, sabemos que errado isso por parte deles mas infelizmente eles exigem, dizem que todos mandam certo, etc.

Voltei o fonte original e deu tudo certo. Desculpa ter colocado aqui um problema causado por mim mesmo.

Eu costumo alterar o fonte do acbr nos arquivos PCNNFE.PAS e pcnNfeW.pas trocando nitemped de integer para string. Talvez tenha que fazer isso também em algum outro lugar, ou, se não for pedir muito, fazer o que outro usuário pediu no post acima de trocar geral no acbr esse campo para string? A princípio é mais fácil tratar string como inteiro do que o contrário...

Quanto ao teste que você pediu, realmente daí ele não gera um novo xml e fica o xml original com o digest correto.

Obs.: No trunk1 mesmo usando como string o Consultar não gerava essa diferença.

Editado 15 Setembro, 2015 por DOCFABIO

[Italo Giurizzato Junior]

Fabio,

Alterei o tipo do campo nItemPed de Integer para String.

Fiz isso não por causa de algumas empresas quererem colocar zeros a esquerda, mas sim pelo fato desse campo ser numérico e ter tamanho fixo igual a 6, conforme consta na Nota Técnica 2013/005 versão 1.22 página 57.

[DOCFABIO]

Que ótimo. Obrigado Italo.

Vou atualizar aqui.

[Edgar]

Boa tarde a todos,

Estou enfrentando o mesmo problema acima referente ao Digestvalue, e meus fontes não houveram alterações, o que notei nos testes efetuados é que o fato de haver todo o processo de adição da nf-e no componente e posteriormente a consulta para verificar sua existência origina-se erro.

Notei que se utilizo o comando ACBrNFe.NotasFiscais.Clear o erro não ocorre ao consultar, contudo ao capturar o xml ele está vazio devido a chamada da função Clear.

Cheguei alterar o momento da consulta, deixando a função acima da adição da nota no componente, porém o problema é que ao capturar o xml ele não vem com os dados de autorização.

Existe alguma forma de concatenar os dados de autorização da nf-e com o xml gerado pelo componente ?

 

Em anexo xml gerado através da consulta e geração da nf-e e xml ativo na SEFAZ (homologação).

 

Observação: este procedimento de geração do xml e consulta funciona no trunk1, ele foi criado para corrigir problema de duplicidade de notas fiscais que devido problemas de comunicação com a resposta da SEFAZ não atualizava os dados de autorização da nf-e.

 

35151210296642000133550010000039391000039394 (ERP).xml

35151210296642000133550010000039391000039394 (SEFAZ).xml

35151210296642000133550010000039391000039394-ped-sit.xml

35151210296642000133550010000039391000039394-sit.xml

[Italo Giurizzato Junior]

Bom dia Edgar,

O Clear tem que ser executado antes de você carregar o XML exemplo:

ACBrNFe.NotasFiscais.Clear;

ACBrNFe.NotasFiscais.LoadFromFile(sArqXML);

ACBrNFe.Consultar;

Outra coisa quando você diz capturar o XML após a consulta o que você quer dizer?

Se você se refere a salvar o arquivo em disco, você atribuiu o valor True a propriedade: Configuracoes.Arquivos.Salvar ?

Agora se você esta lendo uma propriedade para salvar no banco de dados como é a linha?

[Edgar]

7 horas atrás, Italo Jurisato Junior disse:

Bom dia Edgar,

O Clear tem que ser executado antes de você carregar o XML exemplo:

ACBrNFe.NotasFiscais.Clear;

ACBrNFe.NotasFiscais.LoadFromFile(sArqXML);

ACBrNFe.Consultar;

Outra coisa quando você diz capturar o XML após a consulta o que você quer dizer?

Se você se refere a salvar o arquivo em disco, você atribuiu o valor True a propriedade: Configuracoes.Arquivos.Salvar ?

Agora se você esta lendo uma propriedade para salvar no banco de dados como é a linha?

Boa tarde Italo,

Já localizei o problema que estava ocorrendo, houve alteração nas informações do xml referente a alíquota do ICMS de 18% para 12%, com isto ao validar o xml começou ocorrer este problema de Digestvalue, efetuei a correção para a alíquota correta e funcionou corretamente.

Em relação aos questionamentos acima, na realidade o que eu precisava era capturar o xml completo com os dados de autorização, onde faço através do comando ACBrNFe.NotasFiscais.Items[0].XML, como o clear era utilizado antes, ao tentar capturar o arquivo era originado o erro sobre o componente estar vazio.

 

Desculpe pela falta de atenção e obrigado pelo seu posicionamento Italo.

[tchuck]

Estou com o problema acima ja coloquei como false mas o problema continua, alguem sabe de alguma formula para resolver esse problema.

[Italo Giurizzato Junior]

Bom dia,

Para que o DigestValue que esta no XML da NF-e ser diferente do que consta no retorno da consulta é simples, algum dado do da NF-e foi alterado, o XML foi gerado e assinado novamente, consequentemente o seu DigestValue é recalculado.

Vamos a um exemplo:

1. suponha que o XML foi gerado, assinado, valido e enviado para a SEFAZ.

2. Por algum motivo não ocorreu o retorno do protocolo de autorização.

3. Para corrigir esse problema o XML é carregado e é feita a consulta.

4. Mas surge o erro informando que o DigestValue não confere.

No passo 3 o XML é carregado com o LoadFromFile (por exemplo) só que esse método possui 2 parâmetros, o primeiro informamos o caminho mais nome do XML que desejamos carregar e o segundo que é opcional tem como valor padrão True, isso faz com que o XML seja gerado e assinado novamente. Por outro lado se for False, o XML é apenas carregado exatamente como ele esta gravado.

Mas tem pessoas que preferem alimentar novamente o componente lendo as informações do banco de dados para gerar e assinar e depois consultar, tudo bem, mas e se nesse meio tempo alguém realizar uma pequena alteração no cadastro do destinatário, por exemplo acrescentar uma virgula no endereço ou trocar um Z por S. Isso já é suficiente para que o DigestValue seja diferente.

Concluímos que é preciso avaliar como esta sendo feita essa rotina e muda-la, no meu entendimento devemos apenas ler o XML através do LoadFromFile e atribuir o valor False para o segundo parâmetro e não recriar do zero o XML.

Espero ter ajudado.

[tchuck]

Bom dia Italo, bom eu fiz das duas formas usando o False e o True mas mesmo assim o erro ainda continua, e o cadastro do cliente não foi alterado.

Por exemplo fiz uma nota em offline e quando vou consultar a mesma ja aparece o problema

[Italo Giurizzato Junior]

Quando você emite uma nota Offline, depois ela tem que ser enviada para SEFAZ.

Ela foi enviada?

Você alterou algum dado dessa nota ao envia-la para SEFAZ, por exemplo o tipo de emissão?

[tchuck]

esse que esta sendo o problema, quando é offline e mando consultar esta dando o problema, bom estou fazendo isso com o banco de dados do cliente e o mesmo me informou que so envia a nota offiline e quando é consultada esta dando o problema

[Italo Giurizzato Junior]

Como você esta falando em offline estou entendendo que a nota seja uma NFC-e, correto?

Sendo assim, não existe essa história de enviar offline.

Você gera a Nota segundo o tipo de emissão offline e imprime o DANFE.

Depois a nota tem que ser enviada sem nenhuma alteração para SEFAZ quando os problemas forem sanados.

Não se deve alterar o tipo de emissão para normal ao ser enviada para SEFAZ.

Só é necessário a consulta caso a nota que foi enviada não recebeu o protocolo de autorização, por motivo de falha no retorno.

 

[tchuck]

O problema é a bendita data de emissão que esta sendo alterada, fiz a alteração e creio q foi sanado o problema estou testando para ver se o problema ira continuar mas até o momento deu certinho... com as mudanças no sistema

[alessandro pancotte]

Pessoal eu sei que ja discutiram sobre este erro do digestvalue, mas segue meu problema.

Tentei enviar uma NFCe em homologação para fazer alguns testes, na hora o sistema apresentou um erro, mas chegou a enviar o xml, porem nao gravou os dados no meu banco de dados.

A nota foi enviada pra receita, porem não gravei nenhuma informação no banco e também fiquei sem o xml original, ou seja, no meu sistema ficou como se a NFCe nunca tivesse sido enviada.

Repeti o processo de enviar novamente, ai ele gera o xml mas da a mensagem DigestValue do documento 41160109005135000114650010000001991000001990 não confere.

Eu tenho feito da seguinte maneira, monto o xml, 

Pude observar que o digestvalue que vem no retorno realmente é diferente do que foi gerado qdo tento enviar novamente

Digestvalue do retorno -> 'ZBZlu7SVdlJfjVbxay4Ksz2GeP8='

Deixei a propriedade ValidarDigest = false, enviei novamente e deu certo.

Acabei de ler o manual Acbrnfe 1.04 e nao achei nada especifico sobre o campo digestvalue, a não ser onde diz que a propriedade True faz a comparação.

Gostaria de uma orientação, caso aconteca novamente como citei acima, onde a NFCe esta autorizada mas por alguma razão não foi gravado nada no banco.

E tambem se devo deixar a propriedade true ou false, e por que?

 

41160109005135000114650010000001991000001990-nfe erro digestvalue.xml

41160109005135000114650010000001991000001990-nfe funciona.xml

[Italo Giurizzato Junior]

Boa tarde Alessandro,

Acredito que seria interessante antes de realizar o envio, salvar no banco o XML gerado, assinado e validado, assim você não ocorre esse risco de nem sequer ter o XML da venda, você não acha?

E ao receber o protocolo de autorização salvar em um outro campo o XML completo, ou seja, assinado e com o protocolo de autorização.

[alessandro pancotte]

Boa tarde Italo,

Sim, acredito ser uma alternativa segura.

Obrigado pelo retorno.