Ajuda com Duplicidade da NFE

[Fernando Mendes]

Pessoal me ajuda por favor.

Estou usando o componente ACBRNFE 2.0, de vez em quanto acontece de um cliente emitir uma nota e aparecer 2 idênticas no site da receita.

Porem em um cliente acontece direto.

Ele manda a 99 e aparece a 100 idêntica a 99, ele sabe pq aparece esse erro:

100->Rejeição: Duplicidade de NF-e, com diferença na Chave de Acesso [chNFe][nRec]

Aí só resta cancelar a nota duplicada.

Pelo q eu pesquise isso é pq a internet está ruim se não me engano.

Mas tá acontecendo com frequência, tem como impedir que isso aconteça?

Desculpa se eu estiver criando um tópico que já tem uma solução, mas eu pesquisei no fórum antes de postar.

[Régys Silveira]

Acontece de vez em quando de "engasgar" nota eletrônica no servidor aqui em MG, dai eu faço uma consulta de status da nota se tudo estiver ok eu atualizo o status dele e continuo.

[Fernando Mendes]

O problema não é engasgo é bem pior.

Para cada uma nota q o cliente emite aparece 2 igual e valias porem se for 100 aparece tb a 101 idêntica, porem valida e ele tem q pagar imposto em dobro.

Nesse caso ele tem q emitir a 102.

No final se ele emitiu 1000 notas, terá 2000 todas validas, vai ter q pagar tudo imposto tudo dobrado.

E se fosse de vez em quando eu nem ligava, mas é sempre.

[Italo Giurizzato Junior]

Boa tarde Fernando,

Como funciona a sua aplicação?

Ela envia a nota e se não obter exito na sua autorização, é gerado uma nova com o próximo numero e tenta novamente?

O componente não gera automaticamente o numero da nota, apenas a chave.

Sugiro você revisar a rotina que trata o retorno, pelo o que foi exposto, tem alguma coisa errada na sua aplicação.

Não acredito que a SEFAZ iria gerar duas notas com numeros sequenciais, o componente não faz isso tambem, conclui-se que o problema esta na sua aplicação, ou esta alimentando o componente com os dados da mesma nota duas vezes, mas com numeros de NF em sequencia (100 e 101 por exemplo) ou esta enviando apenas uma e quando não obtem o retorno de autorizado, automanticamente manda novamente mas com outro numero.

Espero ter ajudado.

[strago]

uma outra possibilidade é você não estar limpando as notas existentes no componente antes de carregar outra e transmitindo assim .

EX : Crio a nota Nº 100 valido/assino e mando carregar o xml dessa nota 100 logo em seguida ( nesse caso, o componente já está com a nota 100 carregada e voce mandou carregar o xml gerando uma segunda nota no componente, não olhei os fontes pra ver como ele trata isso, mas se o componente mantém as duas notas e você transmite, está enviando dados duplicados a sefaz (que teria que rejeitar uma delas).

[Fernando Mendes]

Pessoal ainda não resolvi o problema.

O incremento da nota é manual.

Ou seja, se ele mandar a 100 e der erro o programa não incrementa automaticamente para 101. Nem tenta um novo envio.

Ele barra e mostra o erro, para que o usuário decida o que fazer.

Agora se a 100 foi enviada com sucesso, o programa mostra que foi bem sucedido abre o Danfe para impressão ou envio por email.

Até aqui tudo bem.

Vejam que a nota 100 foi bem sucedida, e não ouve incremento para 101 nem o programa se quer fez referencia a ela.

O problema vem agora, ele envia a 101 e o componente devolve essa mensagem postada acima dizendo que ela já existe, no programa ela não existe nem se quer houve referencia a mesma.

Mas o componente devolveu a chave e o cliente pode consultar no site para ver oq houve.

A chave da 101 é diferente da 100 e o numero também, campos como protocolo são diferentes, porem tudo o conteúdo é identifico, produtos, valores, impostos.

E como se o cliente enviasse a 101 com as mesmas informações da 100.

E isso vai acontecendo. A 101 ele não pode enviar pq já existe só pode cancelar. Envia a 102 e aparece a 103 no site da receita. De vez em quando não dá erro, envia a 105 e não aparece a 106 no site.

Estou usando o comando:

ACBrNFe1.NotasFiscais.Clear;

Antes de Gerar, Assinar e Enviar.

Não existe envio em lote, é uma de cada vez.

Nem existe lopping para tentar mais que um envio.

Agora eu não sei se no componente existe looping para tentar enviar varias vezes em caso de falha.

Se existe, por favor me digam onde ele se encontra que eu retiro, prefiro uma unica tentativa.

OBS: isso só acontece em um cliente que a internet é ruim, ofereceram pra ela uma internet de 5 mb mais a navegação é péssima e o download de um arquivo de 10 mb pode demorar uma hora. Os cliente que a internet está perfeita mesmo que a velocidade seja menor isso não acontece.

[André Ferreira de Moraes]

O componente não faz nenhuma tentativa de reenvio automática. Apenas a consulta de retorno do lote que é feita automaticamente pelo componente qdo usado o comando ACBrNFe1.Enviar(nLote);

[strago]

Pergunto denovo ... Está limpando o componente antes do lançamento de outra nota ?

A classe de NFe do componente deriva de um TCollection, ou seja, pode haver mais de uma nota armazenada (o que viabiliza o envio de lotes), se você não limpar as NFes do componente pode estar manipulando dados de uma nota já emitida e com isso gerando duplicidade no conteúdo.

Mas uma coisa é certa, o problema está no seu código, só resta saber onde.

[Fernando Mendes]

Pessoal o problema ainda não foi sanado.

Porem fiz alguns testes junto ao cliente.

Vi q existe uma forma de gerar a chave de uma nota que o componente nem fez mesão a ela.

Então gerei a chave da nota 251 e consultei no site da receita, obviamente não existe.

Pedi para ele emitir a 250, foi emitida com sucesso.

Pela logica tem q aparecer no site a 251 tb. Mas não, não existia 251, o programa enviou apenas a 250. Tudo certo até aqui.

Então mandei ele envia a 251, e bingo, deu erro dizendo q ela já existe.

Como se acabamos de consultar?

Fomos consultar de novo e nota estava lá, mas diferente do que eu imaginei, ela não é idêntica a 250, ao contrario, tem todos os dados que ele preencheu para a 251.

Ou seja foi emitida, mas o componente retornou um erro e não sucesso.

Isso é ruim por que agora a nota existe no site da receita, mas como deu erro, ele não tem o xml autorizado nem o danfe. (a não ser que ele use o recuperar xml da receita).

As chances do erro estar no meu código são pequenas pq ele é bem simples vou até postar uma parte do que é feito.

if not(InputQuery('WebServices Enviar', 'Numero da Nota', vAux)) then

exit;

ACBrNFe1.NotasFiscais.Clear;

if rgTipoDanfe.ItemIndex = 0 then self.ACBrNFeDANFERave1.TipoDANFE := tiRetrato;

if rgTipoDanfe.ItemIndex = 1 then self.ACBrNFeDANFERave1.TipoDANFE := tiPaisagem;

IF rgFormaEmissao.ItemIndex = 0 THEN ACBrNFe1.Configuracoes.Geral.FormaEmissao := tenORMAL;

IF rgFormaEmissao.ItemIndex = 2 THEN ACBrNFe1.Configuracoes.Geral.FormaEmissao := teContingencia;

IF rgFormaEmissao.ItemIndex = 3 THEN ACBrNFe1.Configuracoes.Geral.FormaEmissao := teSCAN;

IF rgFormaEmissao.ItemIndex = 4 THEN ACBrNFe1.Configuracoes.Geral.FormaEmissao := teDPEC;

IF rgFormaEmissao.ItemIndex = 4 THEN ACBrNFe1.Configuracoes.Geral.FormaEmissao := teFSDA;

GerarNFe(vAux);

ACBrNFe1.NotasFiscais.Assinar;

ACBrNFe1.NotasFiscais.Items[0].SaveToFile;

ACBrNFe1.Enviar(vAux);

enviada := true;

ACBrNFe1.NotasFiscais.ImprimirPDF;

copyFILE (PANSICHAR(ACBrNFe1.NotasFiscais.Items[0].NomeArq),PANSICHAR('C:\NF\NF ' + vaux + '-nfe.xml'),TRUE);

COPYFILE (PANSICHAR(copy(ACBrNFe1.NotasFiscais.Items[0].NomeArq, 1 , length(ACBrNFe1.NotasFiscais.Items[0].NomeArq) - 8) + '.PDF'), PANSICHAR('C:\NF\NF' + VAUX +'.PDF'),TRUE);

ShowMessage('Arquivo gerado em: '+ACBrNFe1.NotasFiscais.Items[0].NomeArq);

Bem básico mesmo é praticamente o que o demo faz.

Observem que estou usando o comando ACBrNFe1.NotasFiscais.Clear, logo só pode ter uma nota no lote. Não postei o conteúdo da função GerarNfe. Mas é basicamente um copiar e colar do demo.

E o erro é na função ACBrNFe1.Enviar(vAux). Que é toda controlada pelo componente.

Seria como se eu tentasse executar a função enviar 2 vezes. Mas se eu fizesse isso a primeira iria gerar um xml autorizado e abrir o Danfe, a segunda daria erro.

Mas não, o erro de duplicidade é retorno pela função Enviar, e não pelo meu sistema.

Não é algo como eu verificar na base de dados se a nota existe e sim o próprio componente devolver o erro e não executar o código subsequente a ele.

O que eu imaginei:

Em alguma parte do componente ele tenta fechar a conexão com o web servidor mais do que uma vez em caso de erro. Porem ele não pegou que houve sucesso em uma das tentativas. Logo a próxima tentativa do looping vai dar um erro de duplicidade.

Não consegui identificar em que parte o componente faz isso mas acho que é aqui:

while Processando do

begin

if TACBrNFe( FACBrNFe ).Configuracoes.WebServices.IntervaloTentativas > 0 then

sleep(TACBrNFe( FACBrNFe ).Configuracoes.WebServices.IntervaloTentativas)

else

sleep(vCont);

if vCont > (TACBrNFe( FACBrNFe ).Configuracoes.WebServices.Tentativas*1000) then

break;

vCont := vCont +1000;

end;

To pensando em alterar as propriedades AguardarConsultaRet e Intervalo de Tentativas.

Não acredito que vá ajudar muito, pois o que eu precisava é que o componente pegasse que houve sucesso.

Afinal de nada adianta aumentar ou diminuir o numero de tentativas, mesmo que eu coloque apenas uma, ele tem que dizer se houve sucesso.

Bom se dessa vez vocês não conseguirem me ajudar eu vou postar todo o código.

Agradeço muito pela atenção.

[Fernando Mendes]

Por Favor pessoal me ajudem.

A situação já tá desesperadora.

[Angelo Gomes]

No começo do tópico vc falou que ele sempre gerava duas notas identicas na receita, agora vc falou que parece que ele tenta enviar duas vezes a mesma nota. Afinal, qual das duas situações esta ocorrendo?

Segundo, vc já tentou emitir pelo demo lá no seu cliente, pra ver se acontece o mesmo??

[Fernando Mendes]

No começo do tópico vc falou que ele sempre gerava duas notas identicas na receita, agora vc falou que parece que ele tenta enviar duas vezes a mesma nota. Afinal, qual das duas situações esta ocorrendo?

Segundo, vc já tentou emitir pelo demo lá no seu cliente, pra ver se acontece o mesmo??

A primeira situação foi um engano, o cliente me passou oq ele achava.

A segunda sim é verdadeira, eu mesmo fiz os testes.

O componente ao enviar a nota da um erro, vc imagina q se ouve um erro a nota então não foi enviada.

Pois foi sim, só consultar no site q ela está lá.

Mas como o componente retornou um erro, vc não tem o xml autorizado com protocolo.

O erro é exatamente oq eu postei de duplicidade na chave, unica parte q ele me passou corretamente.

Vou explicar oq acontece.

O componente tem um looping onde ele tenta se comunicar com o web servidor até conseguir ou desiste depois de X tentativas configuradas pelo usuário.

Porem, suponhamos q na quinta tentativa ouve sucesso, o componente não reconhece que ouve sucesso e continua tentando, na segunda vez que ele conseguir, vai dar um erro dizendo que a nota já foi emitida, por tanto duplicidade na chave, que é o que acontece se você tentar emitir uma nota que já foi emitida.

Conseguiram entender?

Simples é como pedir para um jogador chutar a bola no gol até acertar, só que ninguém avisa ele quando ele acertar e ele continua tentando.

OBS: só acontece nesse cliente q a internet é péssima, o mesmo sistema em outros clientes não dá esse erro.

OBS2: O Demo nesse cliente q a internet é péssima tb dá erro.

[BigWings]

Difícil saber ser debugar o código, mas pode ser que você esteja gerando duas notas no lote, com a mesma numeração.

Tente usar o método ACBrNFE1.WebServices.Envia() no lugar de ACBrNFE1.Enviar().

O Enviar() faz a chamada a geração do XML e assinatura, que você já tinha feito anteriormente.

[Souza]

1º faz o teste com o Demo em seu local de trabalho, (veja se acontece o msmo "erro")

2º faz o teste com o Demo em seu cliente (veja se acontece o msmo "erro")

a partir dai tire suas próprias conclusões, ou o erro é no componente ou no seu código...

[Angelo Gomes]

Fernando, posso estar enganado, mas o loop é somente para buscar o retorno do envio de uma nota. O componente envia somente uma vez, e fica tentando buscar o retorno daquele lote.

[Fernando Mendes]

Realmente a função ACBrNFE1.Enviar() faz tudo, sendo que eu já fiz.

Joguei para o cliente outra versão com a função ACBrNFE1.WebServices.Envia().

Espero q dessa vez de certo.

Eu já falei mas vou repetir:

No meu local de serviço:

O Demo não dá Problema.

O Meu sistema não dá problema.

Em outros clientes:

O Demo não dá Problema.

O Meu sistema não dá problema.

Nesse cliente especifico:

O Demo dá Problema.

O Meu sistema dá problema.

E muitos outros programas q ele usa dá problema.

[Juliomar Marchetti]

Formatar micro? windows pirata? Virus?

Anti-Virus?

são possibilidades, desculpe a intromição mas são sugestões que vieram a cabeça lendo todo o post

[Angelo Gomes]

A internet no cliente é ruim pq? Por falta de opção de uma melhor, o cliente não quer trocar por uma melhor, estrutura ruim? Não pega 3G lá??

[Fernando Mendes]

Pq foi dada de graça para ele uma internet de 5 mb pelo parceiro. Só q é muito ruim, vc digita uma frase no msn e cai, mais uma e cai. Até terminar a conversa a outra pessoa já desistiu.

Porem ele não troca jamais, pois se ele quiser outra ele vai ter q pagar por ela.

[juaumkiko]

Altere o código do componente para nao consultar o retorno após o envio.

Assim você teria o envio, numero de recibo comprovando que vc enviou mas nao teria o retorno do processamento.

Depois faça uma rotina no seu sistema que consulte o retorno pelo recibo.

[Alexsander]

Quando isto ocorrer, faça um CONSULTARNFE com a chave informada pela SEFAZ passando o endereço do XML; isto irá colocar o recibo no arquivo local. Depois basta atualizar seu banco de dados com o xml, o protocolo, etc.

Não cancele a segunda NF que você gerou: ela sequer foi emitida, nem poderia ser cancelada. Você precisa apenas marcá-la como descartada no seu BD (ou mesmo deletar, se quiser).

[Mateus Carvalho]

Fernando, será que seu cliente não está lhe comendo bronha? As 2 linha abaixo parecem dar margem para isto :

if not(InputQuery('WebServices Enviar', 'Numero da Nota', vAux)) then

exit;

pelo que entendi, o teste que tu fez com relação as notas 250 e 251, vc estava no telefone. Tu tem como fazer este teste ao vivo com o cliente?

Uma "possível possibilidade" que vejo ai, é que seu cliente gerou a nota 250, e enviou, depois ele clicou novamente e digitou 251 (estando ainda na nota 250).

abraços

[Fernando Mendes]

Fernando, será que seu cliente não está lhe comendo bronha? As 2 linha abaixo parecem dar margem para isto :

if not(InputQuery('WebServices Enviar', 'Numero da Nota', vAux)) then

exit;

pelo que entendi, o teste que tu fez com relação as notas 250 e 251, vc estava no telefone. Tu tem como fazer este teste ao vivo com o cliente?

Uma "possível possibilidade" que vejo ai, é que seu cliente gerou a nota 250, e enviou, depois ele clicou novamente e digitou 251 (estando ainda na nota 250).

abraços

Fiz ao vivo vários testes. Primeiro foi apenas por telefone, mas eu fui até lá e o erro acontecia mesmo.

Porem eu utilizei a solução postada de colocar ACBrNFE1.WebServices.Envia() no lugar de ACBrNFE1.Envia(). Parece que resolveu, não tenho certeza. Mas até agora o cliente não reclamou mais.

[moisesaugusto]

Ola, Fernando. boa tarde.

Eu estava procurando ajuda numa rotina para evitar a duplicidade na emissão de nf-e então deparei-me com seu tópico, que me pareceu pertinente ..

Só por curiosidade, gostaria de saber se o seu problema foi solucionado, com o envio da nota utilizando o comando acbrNfe1.Webservices.... etc...

Abraços.

Por oportuno, gostaria de saber como eu saberia o nome do arquivo a ser gerado ANTES dele ser gravado no .XML, para que eu possa consultar se já existe uma nota com o mesmo numero (ou com a mesma chave) no diretorio que utilizo para as autorizadas (tem de ser antes de gravar, para eu desenvolver a rotina de confirmação // ou alteraçãoi ).

Aqui vai parte do codigo que uso atualmente :

ACBrNFe1.NotasFiscais.Assinar;

ACBrNFe1.NotasFiscais.GerarNFe;

ACBrNFe1.NotasFiscais.Items[0].SaveToFile;

ShowMessage('Arquivo gerado em: '+ ACBrNFe1.NotasFiscais.Items[0].NomeArq);

Obrigado.

[RandsBaloon]

Oi, acontece com um cliente meu também. Acho que o erro tá no XML. Vai duas vezes o valor dentro do Xml. Mais na fazenda tudo certinho. Estou tentando ajustar, agora junto com o Layout 4.00.

Não informava tipo de pagamento. Vou ver se é isso. Mais estou com esse problema também. Eu uso AcbrMonitor Plus. Meu aplicativo gera um arquivo txt. e e enviado pelo mesmo. Na fazenda consta a nota certinho. Mais no contador o tributo aumentou. ele diz que tipo assim: a venda no mês deu 10.000, mais quando enviei os xml's  informou 20.000. Se alguém souber fico agradecido.

Editado 6 Outubro, 2017 por RandsBaloon