Chave duplicata mas diferente

[Thiago Sist. Auditor]

Bom dia, eu estou com o seguinte problema: Eu configurei no componente do ACBr para fazer 3 tentativas para pegar o retorno da SEFAZ num intervalo de 1/2 segundo entre elas caso o código de retorno  sejam (103, 104, 105, 12002, 12007) eu aguardo 3 segundos e faço uma consulta para ver ser o código de retorno mudou para (100) caso contrario gero uma nota em contingencia para poder liberar o cliente no caixa. Depois num monitor que fiz de acompanhamento de notas de rejeição e contingencia dento envia- as notas de contingencia algumas me retorna a rejeição (539 - Duplicidade de NF-e com diferença na Chave de Acesso [chNFe:99999999999999999999999999999999999999999999][nRec:999999999999999]) com a unica diferença é o tipo de envio da nota.

O que aconteceu neste caso foi eu tentei enviar "Normal" e não conseguir o retorno de autorizado pela SEFAZ então gerei em "Contingencia", mas a nota foi enviada realmente "normal" e a SEFAZ demorou muito no retorno e tentei retransmitir ela em contingencia causando esta rejeição. Ajustar isso é tranquilo o problema é que o cliente levou o cupom com o QR Code de transmissão em contingencia e ele nunca vai conseguir consultar esta nota já que na minha primeira tentativa em normal havia sido enviada.

Alguém poderia me ajudar como tentar resolver este tipo de problema com alguma sugestão. Obrigado.

[BigWings]

9 minutos atrás, ribeirot disse:

Bom dia, eu estou com o seguinte problema: Eu configurei no componente do ACBr para fazer 3 tentativas para pegar o retorno da SEFAZ num intervalo de 1/2 segundo entre elas caso o código de retorno  sejam (103, 104, 105, 12002, 12007) eu aguardo 3 segundos e faço uma consulta para ver ser o código de retorno mudou para (100) caso contrario gero uma nota em contingencia para poder liberar o cliente no caixa. Depois num monitor que fiz de acompanhamento de notas de rejeição e contingencia dento envia- as notas de contingencia algumas me retorna a rejeição (539 - Duplicidade de NF-e com diferença na Chave de Acesso [chNFe:99999999999999999999999999999999999999999999][nRec:999999999999999]) com a unica diferença é o tipo de envio da nota.

O que aconteceu neste caso foi eu tentei enviar "Normal" e não conseguir o retorno de autorizado pela SEFAZ então gerei em "Contingencia", mas a nota foi enviada realmente "normal" e a SEFAZ demorou muito no retorno e tentei retransmitir ela em contingencia causando esta rejeição. Ajustar isso é tranquilo o problema é que o cliente levou o cupom com o QR Code de transmissão em contingencia e ele nunca vai conseguir consultar esta nota já que na minha primeira tentativa em normal havia sido enviada.

Alguém poderia me ajudar como tentar resolver este tipo de problema com alguma sugestão. Obrigado.

O Manual de Contingência Off-Line da NFC-e diz o que fazer pra evitar esse problema.

a- Fazer a tentativa de envio da NFCe 

b- Caso ocorra qualquer erro por falha de conexão seja do estabelecimento ou do webservice, gerar uma nova NFCe, com nova numeração, em contingência Off-Line, e marcar a nota onde houve o erro para cancelamento.

Quando o problema que causou o erro estiver solucionado:

a- Fazer a consulta da NFCe marcada para cancelamento,

b- Se estiver autorizada, fazer o cancelamento da nota, caso contrário, fazer a inutilização da numeração.

Isso evita que se entregue uma NFCe ao consumidor de ter a chave alterada posteriormente.

[Thiago Sist. Auditor]

Em 08/01/2018 at 09:28, BigWings disse:

O Manual de Contingência Off-Line da NFC-e diz o que fazer pra evitar esse problema.

a- Fazer a tentativa de envio da NFCe 

b- Caso ocorra qualquer erro por falha de conexão seja do estabelecimento ou do webservice, gerar uma nova NFCe, com nova numeração, em contingência Off-Line, e marcar a nota onde houve o erro para cancelamento.

Quando o problema que causou o erro estiver solucionado:

a- Fazer a consulta da NFCe marcada para cancelamento,

b- Se estiver autorizada, fazer o cancelamento da nota, caso contrário, fazer a inutilização da numeração.

Isso evita que se entregue uma NFCe ao consumidor de ter a chave alterada posteriormente.

Obrigado BigWings, mas eu fico preocupado em com supermercado que varias vendas e acontece isso imagina a quantidade de nota que vou ter que cancelar. Acho que abriria um alerta junto a SEFAZ.

[Cristiano Caritá]

O que eu faço é o seguinte: Para evitar uma grande quantidade de NFC-e marcados para cancelamento/inutilização, caso encontre uma falha de comunicação ou timeout, mudo para modo de emissão em contingência, e só dali a 5 minutos a partir do início da entrada em contingência (isso deixo configurável) o programa vai tentar mudar novamente para modo de emissão online. Para habilitar novamente o modo de emissão online, eu testo antes o status do webservice para ver se está em operação. Se não estiver, testo novamente dali a 5 minutos, e assim por diante. Ao retornar ao modo online, o sistema envia automaticamente os NFC-e que ficaram em contingência e que ainda não foram transmitidos e também faz a inutilização/cancelamento daqueles que tiveram a numeração pulada,  Isso diminui drasticamente a quantidade de NFc-e pendentes de inutilização/cancelamento. Note que se ao tentar enviar o NFC-e retornar código de erro 12007, não é necessário pular a numeração, pois nesse caso a requisição ao webservice nem chegou a ir para a internet.

[Thiago Sist. Auditor]

24 minutos atrás, Cristiano Caritá disse:

O que eu faço é o seguinte: Para evitar uma grande quantidade de NFC-e marcados para cancelamento/inutilização, caso encontre uma falha de comunicação ou timeout, mudo para modo de emissão em contingência, e só dali a 5 minutos a partir do início da entrada em contingência (isso deixo configurável) o programa vai tentar mudar novamente para modo de emissão online. Para habilitar novamente o modo de emissão online, eu testo antes o status do webservice para ver se está em operação. Se não estiver, testo novamente dali a 5 minutos, e assim por diante. Ao retornar ao modo online, o sistema envia automaticamente os NFC-e que ficaram em contingência e que ainda não foram transmitidos e também faz a inutilização/cancelamento daqueles que tiveram a numeração pulada,  Isso diminui drasticamente a quantidade de NFc-e pendentes de inutilização/cancelamento. Note que se ao tentar enviar o NFC-e retornar código de erro 12007, não é necessário pular a numeração, pois nesse caso a requisição ao webservice nem chegou a ir para a internet.

Boa Cristiano, eu estava pensando em fazer algo parecido com isso mesmo mas seria manual eu fiz um monitor de NFCe e havia pensado em o fiscal de caixa quando detectar este problema is até o monitor e dar uma carga para todos os caixas para entrarem em envio de contingencia e no máximo por 1h depois desse tempo voltaria ao normal automaticamente. Mas esta validação para ver se esta de volta automático é uma boa.

[Thiago Sist. Auditor]

Pessoal entendi o processo que tenho que fazer mas infelizmente fiz algumas notas erradas exemplo emitir uma nota Nº 20 Normal e não conseguir resposta da SEFAZ então meu sistema fazia o seguinte pegava esta mesma nota 20 e trocava para contingencia e as vezes causava erro de duplicidade com chave diferente então eu apenas acertava a chave para a correta. Mas meu XML ficava errado já que eu havia trocado o tipo de emissão. Então eu estava querendo refazer estes XML novamente para arquiva-los corretamente. Então o que eu faria geraria o XML com a chave correta e mandava assina  para informar que é meu realmente e ao consultar a chave a sefaz me retorna o protocolo que eu adicionaria no meu XML. Mas a questão é que a assinatura muda por causa acredito eu q a data e hora são diferentes. Minha grande duvida é eu posso fazer isso ou é uma ilegalidade? Eu deixo meu cliente com o XML divergente. Lembrando eu não mudo nada referente a valores e tributação e nada mais é o mesmo que já conta na SEFAZ.

[carlosinfoteen]

53 minutos atrás, ribeirot disse:

Pessoal entendi o processo que tenho que fazer mas infelizmente fiz algumas notas erradas exemplo emitir uma nota Nº 20 Normal e não conseguir resposta da SEFAZ então meu sistema fazia o seguinte pegava esta mesma nota 20 e trocava para contingencia e as vezes causava erro de duplicidade com chave diferente então eu apenas acertava a chave para a correta. Mas meu XML ficava errado já que eu havia trocado o tipo de emissão. Então eu estava querendo refazer estes XML novamente para arquiva-los corretamente. Então o que eu faria geraria o XML com a chave correta e mandava assina  para informar que é meu realmente e ao consultar a chave a sefaz me retorna o protocolo que eu adicionaria no meu XML. Mas a questão é que a assinatura muda por causa acredito eu q a data e hora são diferentes. Minha grande duvida é eu posso fazer isso ou é uma ilegalidade? Eu deixo meu cliente com o XML divergente. Lembrando eu não mudo nada referente a valores e tributação e nada mais é o mesmo que já conta na SEFAZ.

Verifica na pasta dos xml que normalmente o ACBR vai cariar os dois xml o que foi tentado enviar normal e o que esta em contingencia.

Dai você pode tentar +/- assim para ajustar os xml sem o protocolo de autorização mencionado... Lembre é só uma dica, você pode melhorar e automatizar este processo.

 

if OpenDialog1.Execute then
                begin

                    ACBrNFe.NotasFiscais.Clear;
                    ACBrNFe.NotasFiscais.LoadFromFile(OpenDialog1.FileName, False); //----- carrega o teu xml (chave com envio normal que nao retornou o protoco) pra receber o protocolo
                    ACBrNFe.Consultar();

                    ///-------Tua rotina de atualizacao do BD

                end;

 

 

 

[BigWings]

1 hora atrás, ribeirot disse:

Minha grande duvida é eu posso fazer isso ou é uma ilegalidade?

É ilegal pois impede o consumidor de fazer a consulta da nota, seja pelo QRCode ou pela chave da nota, o que torna ela sem nenhum valor fiscal.

[Thiago Sist. Auditor]

21 minutos atrás, BigWings disse:

É ilegal pois impede o consumidor de fazer a consulta da nota, seja pelo QRCode ou pela chave da nota, o que torna ela sem nenhum valor fiscal.

Sim o cupom que foi com cliente esta errado mesmo mas como é loja de eletrodoméstico o cliente é identificado por causa da garantia e seria solicitado a a troca do cupom.

41 minutos atrás, carlosinfoteen disse:

Verifica na pasta dos xml que normalmente o ACBR vai cariar os dois xml o que foi tentado enviar normal e o que esta em contingencia.

Dai você pode tentar +/- assim para ajustar os xml sem o protocolo de autorização mencionado... Lembre é só uma dica, você pode melhorar e automatizar este processo.

 

if OpenDialog1.Execute then
                begin

                    ACBrNFe.NotasFiscais.Clear;
                    ACBrNFe.NotasFiscais.LoadFromFile(OpenDialog1.FileName, False); //----- carrega o teu xml (chave com envio normal que nao retornou o protoco) pra receber o protocolo
                    ACBrNFe.Consultar();

                    ///-------Tua rotina de atualizacao do BD

                end;

 

 

 

Infelizmente eu especifico um nome do arquivo e caminho certo para salvar o xml no ACBR, então sempre que mudo o xml ele modifica o mesmo XML.

[BigWings]

26 minutos atrás, ribeirot disse:

Sim o cupom que foi com cliente esta errado mesmo mas como é loja de eletrodoméstico o cliente é identificado por causa da garantia e seria solicitado a a troca do cupom.

"Se" houver a troca do cupom não teria problemas, mas quando a empresa não fizer isso e for autuada, pode ter certeza que vão jogar a culpa no sistema e você terá que responder por isso.

[Gildenor]

Em 08/01/2018 at 09:28, BigWings disse:

O Manual de Contingência Off-Line da NFC-e diz o que fazer pra evitar esse problema.

a- Fazer a tentativa de envio da NFCe 

b- Caso ocorra qualquer erro por falha de conexão seja do estabelecimento ou do webservice, gerar uma nova NFCe, com nova numeração, em contingência Off-Line, e marcar a nota onde houve o erro para cancelamento.

Quando o problema que causou o erro estiver solucionado:

a- Fazer a consulta da NFCe marcada para cancelamento,

b- Se estiver autorizada, fazer o cancelamento da nota, caso contrário, fazer a inutilização da numeração.

Isso evita que se entregue uma NFCe ao consumidor de ter a chave alterada posteriormente.

Ok. Porem o manual nao especifica que acao tomar em relacao a primeira NFCe  quando o prazo de cancelar estiver excedido.

Neste caso, o que os colegas tem feito?

[Aurino]

Bom Dia Senhores.

No exemplo, caso o prazo de cancelamento não esteja no prazo, qual procedimento a ser adotado para essa situação?
Nesse caso, é ideal a partir do primeiro erro de retorno, emitir em OFFLINE as proximas notas até um certo tempo para ser verificado novamente a consulta do webservices e retornar a emissao em NORMAL, isso seria interessante?

[Cristiano Caritá]

1 minuto atrás, Fr. Silva disse:

Bom Dia Senhores.

No exemplo, caso o prazo de cancelamento não esteja no prazo, qual procedimento a ser adotado para essa situação?
Nesse caso, é ideal a partir do primeiro erro de retorno, emitir em OFFLINE as proximas notas até um certo tempo para ser verificado novamente a consulta do webservices e retornar a emissao em NORMAL, isso seria interessante?

Isso é exatamente o que eu faço. Veja minha explicação neste tópico (dia 12/01/2018)

[BigWings]

8 minutos atrás, Gildenor disse:

Ok. Porem o manual nao especifica que acao tomar em relacao a primeira NFCe  quando o prazo de cancelar estiver excedido.

Neste caso, o que os colegas tem feito?

Quando não é mais possível cancelar a NFCe eu emito uma NFe de entrada para fazer o estorno.

 

[CleitonMaciel]

Pegando o gancho do colega que abriu o tópico, 

Quando se transmite a NFCe e por acaso ocorre erro de time out  12002. No caso a NFCe foi pra sefaz esta autorizada o uso (100), mas não houve retorno no tempo correto. Ocorre que entrou em contingência offline. Já mudou o tipo de emissão na chave.

No monitor que tenho pra verificar as pendencias de transmissão, ele tenta enviar novamente a nota, aquela nota que não foi atualizada no tempo hábil retorna: Rejeição Código: 539  Motivo: Duplicidade de NF-e, com diferenca na Chave de Acesso.

Então de acordo o manual, deve se guardar essa nota no sistema, gerar outra com nova numeração pro cliente.
Depois cancelar a anterior.

É exatamente isso que vocês fazem?
 

[Thiago Sist. Auditor]

16 horas atrás, CleitonMaciel disse:

Pegando o gancho do colega que abriu o tópico, 

Quando se transmite a NFCe e por acaso ocorre erro de time out  12002. No caso a NFCe foi pra sefaz esta autorizada o uso (100), mas não houve retorno no tempo correto. Ocorre que entrou em contingência offline. Já mudou o tipo de emissão na chave.

No monitor que tenho pra verificar as pendencias de transmissão, ele tenta enviar novamente a nota, aquela nota que não foi atualizada no tempo hábil retorna: Rejeição Código: 539  Motivo: Duplicidade de NF-e, com diferenca na Chave de Acesso.

Então de acordo o manual, deve se guardar essa nota no sistema, gerar outra com nova numeração pro cliente.
Depois cancelar a anterior.

É exatamente isso que vocês fazem?
 

12002 e 12009 é que a rede esta fora do ar não ha nenhuma comunicação com a internet. Sempre que ocorre uma falha de comunicação a sefaz orienta guardar a numeração e depois cancelar ou inutilizar a numeração e fazer uma segunda numeração de nota em contigencia offline.  Se transmitir uma numeração no modo normal é proibido alterar a mesma numeração para contingencia offline.

[CleitonMaciel]

Eu aumentei o time out pra 10000 ms, pode ocorre erro de instabilidade.
Pode ser que ao enviar a rede esta tudo ok, mas no retorno ocorreu algum problema.

 

 

Editado 4 Maio, 2018 por CleitonMaciel

[Edy]

Ao detectar esses erros, meu sistema transmite a nota com a px numeração... a que houve um problema entra na grade de "Notas para Análise", e ativa uma variável que deixa a aplicação em Contingência Offline por 3 transmissão de NFCe ( as próximas ). Após a 3ª nota enviada em contingência ele checa o status da internet, se estiver OK, volta ao modo normal, e se o problema não for Internet e sim o servidor da sefaz, vai o ocorrer o mesmo erro da situação inicial, e novamente o sistema pula uma numeração, coloca a nota na grade de análise, e continua offline... depois essas notas em análises são consultadas e canceladas, e a numeração inutilizada, já que as offlines que possui números diferentes serão as oficiais e transmitida oficialmente para a Sefaz... bem, a lógica é bem parecida com a de alguns colegas já postada... relatei aqui para ser mais uma ideia que pode ser implantada.

Um detalhe: Eu também até hoje não entendi a lógica do Governo em implantar e até multar uma empresa por não sair impresso a possibilidade de consulta do cliente da Nota pelo QR-CODE ou pelo link, porque em pesquisa que li, confirma até o que já pensava: 97% dos consumidores brasileiros não dão a mínima em verificar a nota que recebe via QR-CODE ou via Link...Francamente, não sei quem troço vai num supermercado, loja de roupas, bares, etc e vai ta se preocupando em ver se a nota está na Sefaz ou não... a vantagem pra o governo deve ser a de Multar as empresas, só pode!

Editado 6 Maio, 2018 por Edy
correção

[gss200610]

Aqui onde moro teve casos que pulou mais de 1000 numeros devido a erros de internet, e proibiram o envio offline direto, tem que ficar online e so aceitam 10% em contigencia das notas. ai quero ver como vai fazer nesses casos onde tem que ficar pulando numero e gerando o proximo, como resolver entao?, se a internet nao volta de forma alguma, entao vou ficar só gerando numero e deixar um monte de notas pra traz pra cancelar é isso?