Olá desenvolvedor. Neste artigo você verá como ocorre a rejeição NFCe: duplicidade Nfce já autorizada com tipo de emissão normal.
Queremos informar através desse post sobre a rejeição NFCe de duplicidade em contingência e como este problema foi resolvido com a adição de um novo campo no seu RP (Retorno de Processamento).
Essa rejeição estava ocorrendo quando o .xml de uma NFCe emitida em contingência era enviado para ser autorizado e a Sefaz rejeitava esta por duplicidade com diferença na chave de acesso, pois já havia sido gerada uma chave em contingência e agora consta outra de emissão normal.
Entenda como acontece a emissão primeiro:
Fluxo de emissão normal de uma NFCe
O diagrama abaixo representa o fluxo de emissão em modo normal de uma NFCe:
Os processos em LARANJA são processos em que a emissão em modo de contingência pode ser ocasionada.
Quando ocorre a contingência?
Os principais motivos pelo qual o Client realiza a emissão em contingência de uma NFCe são:
- Client não consegue comunicar com o WebService (provável problema de conexão com a Internet na rede do emitente) (processo Envia NFCe);
- WebService da Sefaz temporariamente indisponível ou (processo Envia para Sefaz);
- Cliente não recebe retorno do WebService da NS Tecnologia dentro do tempo limite configurado:
- Internet do contribuinte muito lenta ou (processos Envia retorno para Client e Recebe retorno do WS);
- WebService da Sefaz demorou para responder ao WebService da NS Tecnologia (processo Recebe retorno da Sefaz).
O que acontece quando a emissão é feita em contingência?
Quando não é possível emitir normalmente o Client realiza o processo de emissão em contingência realizando os seguintes passos:
- Adiciona no XML as informações de contingência e salva para envio posterior;
- Imprime o Danfe NFCe com as informações de contingência e;
- Gera RP de retorno com o status OFFLINE no arquivo TXT de emissão.
A cada 3 minutos o Client verifica se existem .xmls emitidos em contingência aguardando envio. Se existir um ou mais .xmls, os passos abaixo serão realizados:
- Client envia o XML para o WebService da NS Tecnologia se for possível;
- O WebService da NS Tecnologia envio o XML para o WebService da Sefaz, recebe o retorno e encaminha para o Client;
- O Client adiciona o registro RP de retorno no arquivo contingencia_ret.txt e gera o XML da NFCe se tiver sido autorizada.
Quando a rejeição por duplicidade ocorre?
O diagrama abaixo demonstra o fluxo de emissão de NFC-e em contingência que ocasiona a rejeição por duplicidade:
- Os processos destacados em VERDE são os processos executados pela emissão em modo normal de uma NFCe;
- Os processos destacados em LARANJA são os processos executados pela em modo de contingência de uma NFCe e;
- Os processos destacados em VERMELHO são os processos executados quando o WebService da Sefaz autorizou a NFCe emitida em modo, mas demorou excessivamente para devolver a resposta para o WebService da NS Tecnologia.
Neste fluxo o Client emite a NFCe e deixa o .xml de contingência (emitido com tipo de emissão 9-Contingência Offline) aguardando para ser enviado posteriormente. No entanto, a Sefaz autoriza o XML original (emitido com tipo de emissão 1-Normal), mas demora excessivamente para retornar o resultado do processo para o WebService da NS Tecnologia, fazendo com que o mesmo não consiga enviar o resultado de processo de volta para o Client, pois a conexão foi perdida.
Após alguns minutos, o Client realiza o envio do XML de contingência para ser autorizado e a Sefaz retorna a Rejeição 539 – Duplicidade de NFe, com diferença na Chave de Acesso, pois a NFCe já encontra-se autorizada e a chave de acesso é diferente pois o tipo de emissão já autorizado é Normal e o XML enviado está como Contingência.
Como este problema é resolvido?
Quando o Client recebe o status de duplicidade no envio dos XMLs emitidos em contingência, ele compara o digestValue do XML da NFCe autorizada com o digestValue do XML da NFCe em contingência. Se os mesmos forem iguais, as NFCes são as mesmas e neste caso o Client irá salvar o XML autorizado na pasta Documentos e irá adicionar o RP no arquivo contingencia_ret.txt colocando no campo chaveAdic a chave correta da NFCe autorizada.
O exemplo abaixo demonstra como o registro RP será gerado:
RP|1…818|lHtFew…E/cg=|100|Autorizado o uso da NF-e com tipo de emissão normal|NFe43160107364617000135650010000026269000021616|1|2626|2016-01-19T16:25:05-02:00|https://www.sefaz.rs.gov.br/NFCE/NFCE-COM.aspx?…|NFe43160107364617000135650010000026261000021610
Os campos salientados são os campos que devem ser observados:
- xMotivo: Alterado de Autorizado o uso da NFe para Autorizado o uso da NFe com tipo de emissão normal;
- chNFe: Contém a chave da NFCe impressa em contingência (a mesma chave gerada no RP do arquivo de emissão) e;
- chaveAdic: Contém a chave da NFCe autorizada.
A chave gerada no campo chaveAdic é a chave que deve ser utilizada para manutenção desta NFC-e. Por manutenção entende-se todos os processos relacionadas com uma NFCe (ex.: reimpressão, cancelamento, envio para a contabilidade…).
Parceiro atente-se pois essa é a chave que você precisa buscar no seu banco de dados agora.
Leia também:
Mantenha-se atualizado, acesse nossas páginas abaixo:
Contatos
Comercial:
Skype: comercial_newssystems
E-mail: comercial@newssytems.eti.br
Telefone: (51) 3692-1123
Suporte Técnico:
Skype: suporte_newssystems , desenvolvimento_newssystems
E-mail: suporte@nstecnologia.com.br, desenvolvimento@newssystems.eti.br
Telefone: (51) 3671-2053
Gostou do Post? Caso você não conheça nossa API entre em contato conosco!
Não consigo visualizar o esquema.
Excelente texto, como sempre a nstecnologia esta de parabens. Porem imagens desse artigo não aparecem, principalmente o diagrama do fluxo de emissão da NFCe.
Olá Isaac, tudo bem?
Muito obrigado pelas palavras e pelo alerta.
Já corrigimos as imagens.
Grade abraço!