Duplicidade de NFC-e causado quando recebo o erro 12002

[Orlando Dantas]

Olá. 

Já procurei por tópicos parecidos aqui no fórum, até encontrei mas não me ajudaram a resolver meu problema.

Em vários clientes está dando duplicidade de NFC-e. Já percebi que ele é causado por dois motivos. Um deles é quando os web-services da Sefaz estão com instabilidade, o outro é instabilidade da internet sendo que esse tenho bastante pois a internet na nossa região é muito instável. O que me parece ocorrer é o seguinte, o sistema faz o envio dos dados a Sefaz recebe e autoriza, mas o sistema não tem o retorno e por esse motivo dá o erro 12002 perguntando ao cliente se deseja cancelar a venda ou emitir em contingência, se o cliente optar por emitir em contingência, o sistema grava a venda incrementa a numeração no banco e imprime a nota em contingência, quando ele vai enviar a mesma a Sefaz retorna o erro de duplicidade. Se o cliente optar por cancelar o sistema cancela a venda e não incrementa a numeração no BD, quando ele emite uma nova venda também retorna o erro de duplicidade pois o numero já foi autorizado. Gostaria de saber como que vocês tratam esse erro, pois estou tendo muita reclamação e ligação no suporte por causa do mesmo.

O mesmo erro ocorre até mesmo nas vendas que foram colocadas em contingência por outro motivo. Por exemplo: a venda foi colocada em contingência por que está sem internet, quando o cliente vai enviar essa contingência, ocorre o erro 12002 pelos motivos já explicados acima.

Desde já agradecido por toda ajuda.

145-pro-lot.xml 145-env-lot.xml

[leootoni]

Tenho recebido a mesma mensagem em MG

[mdevit]

Bom dia, sim também passo por isso:
1) Envio o cupom, mas não tenho retorno do envio, 2) Entra em contingência, 3)mais tarde quando enviar novamente da o erro de Duplicidade.

O problema é que na hora da venda, como não houve o retorno, é gerado em contingência e muda a chave de acesso, impresso o cupom e entregue ao cliente, mas na verdade o cupom anterior já foi para Receita com a primeira chave. A chave entregue para o cliente é uma, mas o que já foi para receita é outra.

Qual a melhor solução para isso?

[Amarildo de Matos]

Bom dia..

acho que voce tem de mudar a rotina de criar a contingencia.. nao podendo ser de imediato quando nao retorna.

e antes de gerar nova transmissao , ver se nao veio o retorno do xml na pasta com o protocolo, ou fazer uma consulta para ver se ela ja nao foi feita..

e somente depois disse ver a questao da contigencia.

 

[mdevit]

7 minutos atrás, Amarildo de Matos disse:

Bom dia..

acho que voce tem de mudar a rotina de criar a contingencia.. nao podendo ser de imediato quando nao retorna.

e antes de gerar nova transmissao , ver se nao veio o retorno do xml na pasta com o protocolo, ou fazer uma consulta para ver se ela ja nao foi feita..

e somente depois disse ver a questao da contigencia.

 

Bom dia Amarildo, Obrigado pelo retorno.

Sim, não mencionei essa parte, mas coloco no sistema o comando:
ACBrNFe1.WebServices.Consulta.NFeChave:= vvCHAVE;

ACBrNFe1.WebServices.Consulta.Executar;

Caso não retorne, aí sim coloco em Contingência. São em 4 empresas que acontece isso todos os meses e as que tem mais falhas na internet.

[Orlando Dantas]

13 horas atrás, mdevit disse:

Bom dia Amarildo, Obrigado pelo retorno.

Sim, não mencionei essa parte, mas coloco no sistema o comando:
ACBrNFe1.WebServices.Consulta.NFeChave:= vvCHAVE;

ACBrNFe1.WebServices.Consulta.Executar;

Caso não retorne, aí sim coloco em Contingência. São em 4 empresas que acontece isso todos os meses e as que tem mais falhas na internet.

Olá Também faço esse processo, mas mesmo assim acontece esse problema com meus clientes. Sei que esse é um problema grave e estou sem muita ideia de como resolver.

[mbbortolini]

Senhores, estou enfrentando o mesmo problema, conforme já constatado a maldita instabilidade de internet é o que vem causando isso.

Caso é o seguinte :

- Cliente emitindo NFCe (RS) e em algum momento do dia a conexão de internet se torna instável;

- No log do sistema é possível ver o erro retornado ao executar o serviço de autorização na webservice : 12002 - Time Out;

- No meu tratamento, esse erro é encarado como demora na resposta, logo continuarei invocando o serviço de autorização, no entanto o erro 12002 fica recorrente as vezes por vários minutos até conseguir executar a autorização;

- No entanto em alguns casos após várias tentativa e muitos retornos 12002, o weservice responde diferente, em algum desses momentos a internet de instável passou a falecida ai o retorno é 12007 "O nome do servidor não pode ser resolvido" opa, ai pra mim no meu modesto intendimento isso quer dizer que a internet está OFF, e neste caso, mudo o tipo de emissão para OFF-LINE imprimindo a NFCe em contingência e guardando para posterior transmissão. Até ai nada de anormal.

- Mas aí tem a transmissão da contingência, ai temos  Duplicidade, detalhe, com DIFERENÇA NA CHAVE, mas e ai o que isso quer dizer ? conforme já constatado anteriormente, em algumas das transmissões a nota chegou na SEFAZ e foi processada, mas eu não obtive, nem o retorno, nem o XML.

- Na emissão OFF-LINE a recomendação é alterar somente o TIPO de emissão e informar data e motivo da contingência, logo a numeração não é alterada.

Ao meu ver isso é o que resulta na Duplicidade com diferença na chave pois vejam as chaves abaixo
 43190507885188000141650010001331131041390949 - Chave da nota emitida na SEFAZ 
 43190507885188000141650010001331139041390944 - Chave da nota em contingência a ser transmitida, a qual recebeu o retorno de duplicidade 

 

 

[mbbortolini]

continuando...
Nestas duas chaves a diferença é o tag TpEmiss (e o digito verificador)

Então qual nota é válida, a que processou na SEFAZ (chave1) ou a que o cliente levou impressa (chave2) ?

Solução 1 :

No retorno de duplicidade temos o seguinte retorno :

Citar

539-Rejeicao: Duplicidade de NF-e, com diferenca na Chave de Acesso [chNFe:43190507885188000141650010001331131041390949][nRec:431069695732058]

Seria possível quebrar o retorno pegar a chave que retornou e executar uma consulta na tentativa de recuperar o XML,

Problema : a nota em contingência que o cliente levou, a qual tem uma chave e ao consultar nunca será válida. Ao meu ver isso seria fraude passível de penalizações LOGO SOLUÇÃO 1 é INVÁLIDA.

Solução 2 :

Com o retorno acima, pegar a chave da duplicidade e executar o evento de Cancelamento Por Substituição, aqui temos uma explicação do que é.

Eu ainda não implementei este evento, estou ainda fazendo análise do caso.

Mas aí me deparei com as rejeição para o referido evento : 

Citar

• Rejeição 910: Chave de Acesso NF-e Substituta inválida
• Rejeição 911: Chave de Acesso NF-e Substituta incorreta
• Rejeição 912: NF-e Substituta inexistente
• Rejeição 913: NF-e Substituta Denegada ou Cancelada
• Rejeição 914: Data de emissão da NF-e Substituta maior que 2 horas da data de emissão da NFe a ser cancelada
• Rejeição 915: Valor total da NF-e Substituta difere do valor da NF-e a ser cancelada
• Rejeição 916: Valor total do ICMS da NF-e Substituta difere do valor da NF-e a ser cancelada
• Rejeição 917: Identificação do destinatário da NF-e Substituta difere da identificação do destinatário da NF-e a ser cancelada
• Rejeição 918: Quantidade de itens da NF-e Substituta difere da quantidade de itens da NF-e a ser cancelada
• Rejeição 919: Item da NF-e Substituta difere do mesmo item da NF-e a ser cancelada
• Rejeição 920: Tipo de Emissão inválido no Cancelamento por Substituição

O que me preocupa é a Rejeição 912 pois a contingência não foi transmitida, logo não vai existir 

Problema : ainda estou montando ambiente para verificar o caso, assim que tiver resultado posto aqui.

[BigWings]

34 minutos atrás, mbbortolini disse:

- Mas aí tem a transmissão da contingência, ai temos  Duplicidade, detalhe, com DIFERENÇA NA CHAVE, mas e ai o que isso quer dizer ? conforme já constatado anteriormente, em algumas das transmissões a nota chegou na SEFAZ e foi processada, mas eu não obtive, nem o retorno, nem o XML.

- Na emissão OFF-LINE a recomendação é alterar somente o TIPO de emissão e informar data e motivo da contingência, logo a numeração não é alterada. 

A recomendação do manual é que quando há tentativa de transmissão no modo normal e há erro de comunicação de qualquer tipo, você deve emitir outra NFCe, com nova numeração, em contingência off-line, e marcar a primeira para cancelamento ou inutilização.

Quando a conexão retornar, transmitir a NFCe emitida em contingência, e consultar a primeira, se autorizada fazer o cancelamento, se não existir a NFCe, fazer a inutilização da numeração.

O manual não menciona o cancelamento por substituição que ainda não existia, mas esse deve ser necessário já que tem prazo de cancelamento de 168 horas enquanto o cancelamento normal foi reduzido para 30 minutos.

[mbbortolini]

4 minutos atrás, BigWings disse:

A recomendação do manual é que quando há tentativa de transmissão no modo normal e há erro de comunicação de qualquer tipo, você deve emitir outra NFCe, com nova numeração, em contingência off-line, e marcar a primeira para cancelamento ou inutilização.

 realmente, o meu problema é a numeração.

Agora sim faz sentido usar Cancelamento por substituição.

Obrigado @BigWings pela luz

[Orlando Dantas]

Obrigado galera, já conseguiram me esclarecer um pouco mais. Vou tentar implementar e volto com o retorno.

[mdevit]

Obrigado por este retorno, era a dúvida que estava me matando!!!