Entendendo o Consumo Indevido Retornado pela SEFAZ

O retorno da rejeição de consumo indevido ocorre quando um grande volume de requisições indevidas no servidor da SEFAZ, em um período muito curto.

Por exemplo, uma empresa envia um documento e o mesmo é rejeitado. Mas a empresa continua enviando esse mesmo documento várias vezes (em looping), e sempre obtendo a mesma rejeição.

Esse número excessivo de requisições pode comprometer os Web Services, causando instabilidades e inoperância do ambiente autorizador. Dessa forma, se alguma empresa estiver utilizando os serviços da SEFAZ de forma indevida, poderá receber como retorno essa rejeição, e sofrer um bloqueio temporário, ou seja, não poderá mais efetuar nenhuma requisição nos Web Services da SEFAZ.

Para evitar que isso aconteça, listamos abaixo algumas boas práticas que os emissores devem seguir, de acordo com a Nota Técnica 2018.002.

Web Service de Autorização

NF-e/NFC-e* - enviada com mais de 30 rejeições* iguais:
Contribuinte ficará com o WS de autorização recebendo a rejeição 656 – Rejeição: Consumo indevido pelo aplicativo da empresa [det: Quantidade de rejeições encontradas: XXX, NF-e: CHAVE_ACESSO] por até 1 (uma)* hora para todas as requisições.

Observação 1: Caso após o tempo de 1 (uma)* hora o contribuinte envie novamente a mesma NF-e/NFC-e* e tenha a mesma rejeição, ele poderá voltar a receber a rejeição 656 por até 1 (uma)* hora, e isso se repetirá até ele parar de enviar a NF-e com a mesma rejeição. Essa mesma observação também se aplica para os WS de eventos e inutilização.
Observação 2: A verificação do contribuinte para receber a rejeição 656 poderá ser feita em tempo de conexão pela identificação do CNPJ do certificado digital de transmissão mais o endereço IP (CNPJ + IP) ou pela identificação do CNPJ do emitente (emit/CNPJ). Essa mesma observação também se aplica para os WS de eventos, inutilização e consulta protocolo.
Observação 3: A critério da UF, após 50* bloqueios o contribuinte poderá receber a rejeição 656 permanentemente, até entrar em contato com a UF autorizadora. Essa mesma observação também se aplica para os WS de eventos e inutilização.

Web Service de Eventos

Evento enviado com mais de 20* rejeições iguais:
Contribuinte ficará com o WS de Eventos recebendo a rejeição 656 – Rejeição: Consumo indevido pelo aplicativo da empresa [det: Quantidade de rejeições encontradas: XXX, NF-e: ID_EVENTO] por até 1 (uma)* hora para todas as requisições.

Web Service de Inutilização

Inutilização enviada com mais de 20* rejeições iguais:
Contribuinte (CNPJ + IP) ficará com o WS de Inutilização recebendo a rejeição 656 – Rejeição: Consumo indevido pelo aplicativo da empresa [det: Quantidade de rejeições encontradas: XXX, Inutilização: ID_INUT] por até 1 (uma)* hora para todas as requisições.

Web Service de Consulta Protocolo

Utilizado apenas quando for consultado um documento que está pendente de consulta.

NF-e consultada mais de 10* vezes em 1 (uma)* hora:
Contribuinte ficará com o WS de Consulta Protocolo recebendo a rejeição 656 – Rejeição: Consumo indevido pelo aplicativo da empresa [det: Número máximo de consultas excedido (10) para a NF-e: CHAVE_ACESSO] por até 1 (uma)* hora para todas as requisições.

Observação 1: Após o tempo de 1 (uma)* hora o contribuinte poderá fazer novamente mais 10* consultas da mesma chave de acesso.

Outros Serviços

Se for verificado algum tipo de envio em looping (mais de 40* envios repetidos) em outro Web Service que gere erro ou onere o sistema autorizador o contribuinte ficará com o Web Service recebendo a rejeição 656 – Rejeição: Consumo indevido pelo aplicativo da empresa [det: DESC_ERRO] por até 1 (uma)* hora para todas as requisições.

(*) Critérios preferenciais, parametrizáveis por ambiente autorizador.

* A parametrização dos valores definidos como referência para a rejeição 656 poderão ser alterados a qualquer tempo, a critério do sistema autorizador, de acordo com o comportamento identificado no sistema.

Erros e Problemas mais Comuns

O erro e problema mais comum encontrado pelas UFs é o envio repetido (em looping) de requisições para os Web Services dos sistemas autorizadores de documentos fiscais eletrônicos.

Seguem alguns exemplos de "Consumo Indevido" dos Web Services existentes:

WEB SERVICES	APLICAÇÃO COM ERRO/PROBLEMA
Envio de lote de NF-e	- Aplicação da empresa em "looping" enviando o mesmo lote de NF-e rejeitado por erro de Schema ou em "loop" com NF-e rejeitada por um erro específico. - Usuário do sistema fica enviando manualmente a mesma NF-e (efeito pica-pau).
Consulta Resultado do Lote	- Aplicação da empresa efetua "looping" consultando os números de Recibo de Lote em sequência, mesmo para Número de Recibo que não foram gerados para sua empresa. - Usuário do sistema fica enviando manualmente a mesma consulta (efeito pica-pau).
Evento da NF-e	- Aplicação da empresa em "looping" enviando o mesmo Pedido de Cancelamento ou Evento, que sempre é rejeitado. Usuário do sistema fica enviando manualmente o mesmo cancelamento ou evento (efeito pica-pau).
Inutilização de Numeração	- Aplicação da empresa em "looping" enviando o mesmo pedido de inutilização, que sempre é rejeitado. - Usuário do sistema fica enviando manualmente o mesmo pedido de Inutilização (efeito pica-pau).
Consulta Situação da NF-e (Consulta Protocolo).	- Algumas empresas utilizam esta consulta para verificar a disponibilidade dos serviços da SEFAZ Autorizadora, consultando a mesma Chave de Acesso, em "looping". - Algumas empresas mantêm em "looping" uma consulta as Chaves de Acesso de NF-e destinadas para sua empresa. Em alguns casos, fica sendo consultada uma Chave de Acesso inexistente durante meses. - Usuário do sistema fica enviando manualmente o mesmo pedido de consulta da NF-e (efeito pica-pau).
Consulta Status Serviço	- Aplicação em "loop" consumindo o Web service em uma frequência maior do que a prevista.