Divergencia No Xml Do Sefaz Com Oom Xml Gerado Pelo Sistema

[rodrigoogioni]

Bom dia a todos.

 

Vou tentar explicar o melhor possivel por que o problema é bem complicado.

 

Meu cliente gerou uma nfe e a mesma foi assinada pelo governo gerada normalmente e impressa e enviada para o cliente.

Virou o mes e o contador da empresa me ligou informando que consultando a nfe pela chave de acesso na sefaz os dados da nfe divergem.

 

Entao fiz a consulta e constatei que procede, a nfe que foi gerada pelo sistema esta diferente no sefaz.

 

Entao fui um pouco mais a fundo e descobri que ela repetiu a ultima nfe gerada ao inves da nfe que deveria ser enviada.

 

Ex. nfe 294 - cliente x - 3900,00

      nfe 295 - cliente y - 700,00

 

      No sistema esta assim, incluisive com os xmls autorizados.

 

No sefaz esta assim

      nfe 294 - cliente x - 3900,00

      nfe 295 - cliente x - 3900,00

 

Alguem ja passou por isso ou tenha alguma ideia do que posso fazer para isso nao se repetir?

 

Grato

 

[André Ferreira de Moraes]

Vc deve ter alguma rotina de consistência no seu sistema que não permita usar números já utilizados anteriormente.

[...]

vc diz q tem o XML original Autorizado certo? Nele consta 700,00 ou  3900,00???

Se for 700,00, esse seu XML valida aqui:
https://www.sefaz.rs.gov.br/nfe/nfe-val.aspx?

[rodrigoogioni]

Bom dia,

Obrigado pelas respostas

 

Sossystem, todos os xmls que tento validar nesse site da esse erro Parser XML: Data at the root level is invalid. Line 2, position 1. A versão que estou usando é 3.10

 

Andre, nao entendi o porque aconteceu, pois a nfe gerou normalmente, seguindo a sequencia da numeração, imprimindo correntamente, o xml esta validado.

Mas no sefaz, esta diferente. Enviei um email para o CAF e eles disseram que o problema é no meu sistema. Mas fazendo os testes aqui parece que esta tudo correto,

foi um caso isolado que aconteceu, mas se aconteceu uma vez pode acontecer de novo.

 

Existe alguma possibildade de os dados da outra nota terem ficado no componente e terem sido usados no lugar da nota fiscal correta?

Mas ainda fica a duvida, como que imprimiu corretamente, gerou o xml corretamente e so no sefaz ficou divergente...

 

Grato,

[...]

se vc nao limpar o componente antes de usa-lo, os dados vao ficar nele;

A impressao é baseada no XML que provavelmente está invalido, mas como vc disse q nao consegue validar, nao posso te assegurar isso, Entretanto eu nao teria outra explicacao para te dar. A sefaz nao inventa informacao, apenas recebe... entao se ta la é pq foi enviado aquilo...

[rodrigoogioni]

Boa tarde sossystem,

 

Pois é, é complicado, sempre que gero uma nova nota, limpo os dados no componente com o comando

DM.AcbrNFE1.NotasFiscais.Clear;

 

Acredito que seja esse o comando correto para limpar.

 

No meu sistema sempre gera uma nfe por vez, justamente para evitar algum possivel problema.

 

Grato,

[...]

É isso ai entao, eu procuraria um jeito de validar o XML que vc tem guardado. Se a assinatura digital dele bater corretamente, entao não sei...
Se nao bater, já tem a explicação

[rodrigoogioni]

Boa tarde,

 

sossystem, tem algum exemplo de como fazer isso, se for possivel?

 

Grato

[...]

nao tenho, mas quanto ao seu erro de validação vc pode procurar aqui no forum, olha isso por exemplo:

[rodrigoogioni]

Boa tarde a todos,

 

Depois de muito testar, parece-me que descubri o que pode estar acontecendo. Gostaria da ajuda dos amigos para ver se o meu raciocionio esta correto.

 

No meu sistema, o cliente gera um pedido e logo após a nfe, que gera o numero da nfe vamos supor 2500.

O cliente envia a nfe para o sefaz, acredito que na sefaz é autorizada, mas vamos supor que trave o computador e o sistema reinicie antes de registrar as informações no sistema.

Pela logica, o cliente reabriria o sistema, abriria o mesmo pedido e tentaria concluir a nfe novamente. Se no sistema o cstat retornar como duplicidade, ele faz uma consulta, verifica se a nfe

esta autorizada e conclui a nfe e o pedido baseado nessa consulta.

 

Mas vamos supor que o cliente ao inves de abrir o mesmo pedido ele abrir outro e tente enviar outro pedido diferente com a  numeração 2500 ele vai acusar duplicidade, vai consultar, vai ver que esta autorizada,

porem em nome de outro cliente, mas vai acusar que esta autorizada, e vai concluir a nfe e o pedido com o nome dos clientes diferentes.

 

Acredito que no acbr, como é um novo pedido ele gera um novo xml como novos dados, faz a consulta, verifica que esta autorizado no sefaz e atualiza o xml. Acredito que por isso tenho um novo xml autorizado mesmo com os dados não conferindo.

 

Agora a pergunta que faço, tem como verificar os dados que estao na sefaz, para verificar se batem com os dados que estou enviando no novo xml. Ex:

Tenho no sefaz a nfe 2500 com o cliente X e o valor X, no meu novo pedido estou tentando enviar com a mesma numeração o Cliente Y com o valor Y.

 

Se der duplicidade, tem como eu comparar esses dados para fazer um bloqueio?

 

Grato

[André Ferreira de Moraes]

Agora a pergunta que faço, tem como verificar os dados que estao na sefaz, para verificar se batem com os dados que estou enviando no novo xml. Ex:

Tenho no sefaz a nfe 2500 com o cliente X e o valor X, no meu novo pedido estou tentando enviar com a mesma numeração o Cliente Y com o valor Y.

 

Se der duplicidade, tem como eu comparar esses dados para fazer um bloqueio?

Compare o digVal do XML com o digVal retornado pela consulta.

[...]

ou entao, vc pode fazer assim: nao deixe o seu cliente escolher o numero de NFe que ele vai usar. No exemplo acima, na hora que seu cliente criasse um novo pedido, ele teria que pegar uma nova numeracao de Nfe e nao a 2500

[rodrigoogioni]

Boa tarde Andre, Obrigado pela resposta,

 

so para confirmar seria assim?

 

if DM.AcbrNFE1.WebServices.Retorno.NFeRetorno.ProtNFe.Items[0].digVal = DM.ACBrNFe1.NotasFiscais.Items[0].NFe.procNFe.digVal then begin

 

// caso confiram instruções...

 

end;

 

Grato

[dirceu_albrecht]

Comigo já aconteceu isto também... e ainda não consegui uma forma segura de evitar. 

 

Caso alguem tenha uma sugestão eu agradeço.

 

 

Eu envio o xml para a Sefaz... por alguma falha na conexao ou no micro não recebo o retorno e a NFe fica no sistema como pendente. 

 

Normalmente o cliente clica em Enviar novamente e então recebe o retorno de Duplicidade. Então faço a consulta e recebo o protocolo de Autorização que é gravado no xml. Até aí beleza....

 

Acontece que um cliente percebe um erro em algum item  e resolve alterar a NFe. Edita quantidade, etc... (até o destinatario já mudaram) e envia novamente. Recebe a Duplicidade e ao fazer a consulta o  ACBr grava os dados de autorização no xml alterado.

 

Já tentei criar rotina para evitar edições e alterações nas NFe transmitidas, mas o povo sempre acha uma brecha.

 

Penso que a melhor solução seja mesmo o que o André mencionou. Antes de gravar o protocolo de Autorização no xml, fazer a comparação do digVal.

 

Mas dai vem a outra questão. Como recuperar o xml original? Já vi esta mesma questão em outros tópicos mas não vi nenhuma solução aceitável.

 

Abraço a todos.

[rodrigoogioni]

Boa tarde a todos e obrigado pela colaboração

 

Resolvi usando a dica do Andre de comparar pelo digvalue

 

if DM.AcbrNFE1.WebServices.Retorno.NFeRetorno.ProtNFe.Items[0].digVal = DM.ACBrNFe1.NotasFiscais.Items[0].NFe.procNFe.digVal then begin

// caso confiram instruções...

end;

 

Fiz os testes aqui fazendo a primeira nota, e depois repeti propositalmente a mesma nota igualzinha novamente e deu digvalue diferente, dessa forma bloquei para nao permitir a conclusão exibindo uma mensagem ao usuario.

Dessa forma nao tem erro.

 

Grato a todos.