ACBR está gerando chave diferente da que estou enviando

[HASA]

Bom dia,

Quando um cliente exclui/deleta o XML de alguma nota fiscal, meu sistema gera um novo XML, com a Chave e dados originais do primeiro XML porém sem assinatura e autorização de uso.

Há um tempo atrás, quando solicitava que o ACBR consultasse o a Nota junto a Receita, ele adicionava a Assinatura e Autorização de uso e o XML voltava a ter valor fiscal, hoje em dia, quando solicito que o ACBR consulte a Nota, ele gera uma nova chave de acesso e retorna um erro, dizendo que a chave não confere.

O que pode estar acontecendo para que o ACBR gere uma nova chave??

[André Ferreira de Moraes]

Poste como vc está realizando esta consulta e um XML de exemplo.

[HASA]

Olá Andre, desculpe demorar tanto para responder é que mesmo postando como faço (que é o jeito certo como mando o help do monitor) resolvi vasculhar o forum até descobrir alguem que teve o mesmo problema, e encontrei esse post:

Transcrevo abaixo a resposta que interessa:

Puts cara denovo aconteceu esse mesmo problema, porém agora verifiquei nos fontes e tem uma forma de solucionar este problema para que não ocorra novamente.

O Fato:

O componente gera um numero randomico com digito verificador (10 ultimas posições), e o acressenta na chave da nota.

Se vc como eu fez meio nas "coxas" ou na pressa, vai dar problema.

Ex de feito nas coxas:

Grava_NOTA;

Gera_XML;

ENVIA;

(M#@#!#@ caiu a conexão ou estou ou timeout)

caso isso aconteça você deveria ter a chave ou o XML, para efetuar a consulta antes de tentar enviar a nota novamente da seguinte forma;

Cosulta;

Retornou não cadastrada, repete o comando,

Gera_XML; ENVIA;

caso você não tenha nem a chave nem o XML, aí a coisa fica feia, por ser um numero rândomico a cada novo comando , Gera_XML será gerada uma nova chave diferente da anterior e um novo xml com o mesmos dados, porem chaves diferentes e nome de arquivos diferentes (caso vc salve as os arquivos de envio/resposta) para consultar a nota anterior tem que tentar descobrir que numero foi gerado no primeiro XML (coisa praticamente impossivel).

COMO EVITO ISSO???

É bem simples, porém não veio no manual de instrução... aqui vai meu exemplo.

ACBRNFe.NotasFiscais.Items[0].NFe.Ide.nNF := StrToInt(Numero.Text); // Passa o numero da nota para o componente.

ACBRNFe.NotasFiscais.Items[0].NFe.Ide.cNF := StrToInt(Numero.Text);

//Passa o mesmo numero para a CNF para evitar que seja gerado um numero randomico, assim a chave independente da vez que é gerada será sempre a mesma para este numero da Nota.

Ou seja: foi resolvido porque ele uso o componente e eu uso o MONITOR não tenho como carregar ACBRNFe.NotasFiscais.Items[0].NFe.Ide.cNF com o numero da chave correta sem gerar novo número randomico, creio que seja esse o problema, quando consulta a nota o MONITOR gera nova chave estou enviando como segue:

NFE.CONSULTARNFE("35XXXXXXXXXXXXXXXX550010000000050000000058")

HONÓRIO

[André Ferreira de Moraes]

Veja http://anfm.blogspot.com.br/2009/09/cam ... ndo-o.html

[identificacao]

Codigo= - cNF

[HASA]

Hummmm, esqueci de dizer uma coisa, eu envio um XML para que o Monitor assine, se eu envio a nota NFE.ENVIARNFE("c:\35XXXXXXXXXXXXXXXX550010000000050000000058-nfe.xml",1,0,0) beleza o xml que meu sistema cria recebe a assinatura e a autorização belezinha, mas... se houver uma que de energia por exemplo ou o XML foi perdido pelos N motivos e eu pego essa mesma chave e aponto um XML identico a primeira vez o Monitor muda a chave, envio essa NFE.CONSULTARNFE("35XXXXXXXXXXXXXXXX550010000000050000000058") no TXT para o Monitor e dentro do XML tbm gerado com essa chave, mas não da certo!? O Monitor re-envia a nota com outra chave gerando uma rejeição de Duplicidade de nota,

Desde já agradeço,

Honório

[André Ferreira de Moraes]

Poste o lod do ACBrNFeMonitor e os arquivos que esta enviando.

[HASA]

André vou demorar um pouco para postar o retorno o certificado que eu tinha perdeu a validade agora vou ter que solicitar a outro cliente o exprestimo do mesmo ok, ou vou ainda tentar fazer acontecer em um cliente para te enviar, por favor aguarde...

Honório

[HASA]

André, tem mais uma coisa que não comentei, ao enviar um XML para o monitor eu envio a chave certinha e tal, mas... o acbr troca não só na consulta mas... tbm no primeiro envio, é que quando fiz as consistências e em função da pressa para atender o cliente eu passei a pegar a chave que o acbr retorna (já que o xml autorizado ficara com a nova chave gerada) e gravo em meu BD, já tinha até esquecido disso pois com está funcinando certinho (mesmo trocando a chave, porque fico com a chave correta) não me lembrei de te falar no inicio, ou seja, o problema está na importação de um XML como o anexo a essa mensagem, uma forma de você testar o que digo é pegando atraves do RECUPERARXML.exe (acho que é assim o nome do exe) e submeter uma consulta do mesmo ao monitor via arquivo de texto, não utilizar o proprio monitor ok, ai creio que você verá o problema ai vivo.

Honório

000022517-nfe.xml

[André Ferreira de Moraes]

Envie os LOGs do ACBrNFeMonitor.

[HASA]

Ok, ainda não consegui fazer os testes é que havia me lembrado desses fatos e achei melhor relatar, aguarde que estarei indo em um cliente e te envio ok

Mais uma vez obrigadop pela atenção,

Honório

[HASA]

Andre encontrei alguem com o mesmo problema:

Acho que agora vai,

Hasa

[HASA]

Olá André, fico feliz em informar que o problema estava mesmo no meu sistema o colega Kiko no forum do Toledo respondeu uma questão que foi mesmo 2 por 1, meu erro estava na cNF que na chave e no nome do arquivo informava o correto e enviava para o acbr outra cNF consequentemente o acbr gerava a nova chave, fico muito grato pelo sua esforço em tentar me ajudar, e desculpe o transtorno,

HASA