Jump to content

Delphi Enterprise 
pela METADE DO PREÇO

botao_delphi.png

Curso Dominando o ACBrMonitor
Novo Módulo Soluções de Varejo
Assine o SAC ACBr em qualquer plano e tenha acesso

Saiba Mais

Balança SM100 performance surpreendente

Tecnologia Japonesa   Teclado e Visor resistentes a água
Consumo inteligente de etiquetas   Baixo custo de manutenção
Comunicação Ethernet e WIFI independentes

Saiba Mais

Impressora de Etiquetas ELGIN - L42 PRO

Protocolos PPLA, PPLB, ZPL, EPL (automático)
Porta USB padrão Opcionais: Ethernet, Serial, Paralela
Sensor de Etiquetas Móvel Garantia de 18 meses

Saiba mais

Orlando Dantas

ANSWERED Duplicidade de NFC-e causado quando recebo o erro 12002

  • Este tópico foi criado há 373 dias atrás.
  • Talvez seja melhor você criar um NOVO TÓPICO do que postar uma resposta aqui

Recommended Posts

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

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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.

 

Share this post


Link to post
Share on other sites
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.

  • Like 1

Share this post


Link to post
Share on other sites
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.

  • Like 1

Share this post


Link to post
Share on other sites

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
 4319050788518800014165001000133113104139094- Chave da nota emitida na SEFAZ 
 4319050788518800014165001000133113904139094- Chave da nota em contingência a ser transmitida, a qual recebeu o retorno de duplicidade 

 

 

Share this post


Link to post
Share on other sites

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.

  • Thanks 1

Share this post


Link to post
Share on other sites
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.

  • Like 1
  • Thanks 1

Equipe ACBr BigWings
Ajude o Projeto ACBr crescer - Assine o SAC

Projeto ACBr

 

 

Share this post


Link to post
Share on other sites
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

  • Like 1

Share this post


Link to post
Share on other sites
  • Este tópico foi criado há 373 dias atrás.
  • Talvez seja melhor você criar um NOVO TÓPICO do que postar uma resposta aqui

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×
×
  • Create New...