Consumo Indevido: Evite o Bloqueio das Emissões de NFe e NFCe

Após alerta para o Consumo Indevido, orientamos como evitar o Bloqueio das Emissões de NFe e NFCe.

No mês de maio entrou em vigor uma regra de validação da Sefaz que realizará o Bloqueio das Emissões de NFe e NFCe nas empresas que praticarem o Consumo Indevido, ou seja, emitindo muitas vezes uma NFe ou NFCe com a mesma rejeição. Você pode verificar a análise completa dessa Nota Técnica (NT) em nosso blog, clicando aqui.

Em resumo, sempre que uma NFe ou NFCe for enviada mais de 30 vezes, retornando sempre a mesma rejeição, o emitente ficará bloqueado na Sefaz durante 01 hora, recebendo sempre o retorno:

Rejeição 656: Consumo indevido pelo aplicativo da empresa [det: Quantidade de rejeições encontradas: XXX, NFe: CHAVE_ACESSO].

O mesmo serve para os demais eventos relacionados a NFe e NFCe. Neste artigo, iremos explicar uma forma de evitar que o seu cliente acabe atingindo o número máximo de consultas e seja bloqueado por Consumo Indevido!

Como preparar o sistema para evitar o bloqueio por Consumo Indevido?

A melhor maneira de realizar esse tratamento em seu sistema, é através da leitura de retornos de processamento, pois através do retorno de processamento (chamaremos de RP), você consegue identificar se uma nota foi autorizada ou rejeitada.

De uma forma geral, a Sefaz sempre retornará alguns dados específicos no RP; são eles:

tpAmb (tipo de ambiente)
verAplic (versão do aplicativo que recebeu o lote)
chNFe (chave de acesso da NFe)
dhRecbto (data-hora de processamento)
nProt (número de protocolo)
digVal (digest value)
cStat (código do status de resposta)
xMotivo (descrição literal do status de resposta)

Você precisará ler o cStat, pois ele nos dirá se a nota foi autorizada ou rejeitada. Os códigos de status de resposta vão do 100 ao 796, e também é utilizado o valor 999 para erros não catalogados. Sempre que o valor do campo cStat for igual a 100, significará que o documento foi autorizado, e qualquer um dos demais valores do intervalo representa rejeição.

A melhor forma de evitar o bloqueio por Consumo Indevido é verificando se o último cStat foi de rejeição, antes de liberar a emissão. Para isso, você precisa ter uma coluna em seu banco de dados que irá armazenar esse valor.
Com base nestes dados, a proposta de tratamento é a seguinte:

Em resumo, o fluxograma acima quer nos dizer que:

Ao exibir a tela de emissão para o usuário, você deve verificar se o cStat daquela nota no banco de dados é igual a -1 (definimos o -1 como valor padrão porque nenhum código de status da Sefaz terá esse valor, como vimos anteriormente, mas você pode definir outro valor. Desta forma, o -1 nos indica que a nota está liberada para emissão).
- Se o cStat for igual a -1, você pode habilitar o botão de emissão da nota e, após a emissão do documento, você deve ler o retorno e armazenar o valor do campo cStat;
- Se o cStat for diferente de -1, quer dizer que aquela nota já foi emitida e retornou com rejeição*, então você deve desabilitar o botão de emissão, e deixar que o usuário apenas possa clicar no botão de edição da nota, para corrigir o problema;
  - No momento em que o usuário abrir a tela de edição, você pode realizar dois tratamentos:
    1. Já liberar o botão de emissão, deixando na responsabilidade do usuário realmente editar a nota (mais simples);
    2. Esperar o fechamento da tela e realizar uma comparação entre o último conteúdo do documento e o atual para verificar se realmente foi alterado, e então liberar o botão de emissão (mais complexo);

* o fato de o cStat não possuir o valor -1 não nos garante que a nota foi rejeitada, pois ela pode ter sido: autorizada (100, 150) ou denegada (110, 301, 302, 303). Porém, em qualquer um destes casos, também não deve-se habilitar mais o botão de emissão da NFe; estes, porém, em hipótese alguma.

Sugestão de conteúdo (Vídeo):

Na API da NS Tecnologia

Se você utiliza nossas APIs de NFe e NFCe, será mais fácil realizar o tratamento do RP e a leitura do cStat, pois nós disponibilizamos o RP em formato JSON, o que facilita a leitura dos dados. Basta ler o cStat do JSON e você poderá guardar com facilidade os dados no seu banco, sem precisar ler o XML da nota. Assim fica mais fácil de você configurar o sistema e evitar o bloqueio por Consumo Indevido.

Conclusão

A solução apresentada acima é um das possibilidades que podem ser utilizadas para tratar o problema. Porém, sempre é válido alertar os usuários do seu sistema para que estejam cientes de que podem ser bloqueados ao emitir de forma incorreta. Se você ficou com alguma dúvida, entre em contato com a nossa equipe, estamos sempre à disposição para ajudá-lo e tirar dúvidas!

Gostou do Post? Caso você não conheça nossa API entre em contato conosco!