Em razão do consumo indevido do ambiente de autorização de documentos fiscais eletrônicos, que chega a acarretar mais de 9 milhões de requisições em loop (repetidamente) em um dia, as secretarias estaduais da Fazenda de todo o país, incluindo, portanto, a do  Rio Grande do Sul, vão aplicar bloqueios na emissão de NF-e (Nota Fiscal eletrônica) e NFC-e (Nota Fiscal de Consumidor eletrônica) por parte desses usuários.

A prática está prevista na Nota Técnica 2018/002 (disponível no link) e serve para evitar o comprometimento da estabilidade e da disponibilidade dos ambientes autorizadores mantidos pelas secretarias da Fazenda Autorizadoras e pelo Ambiente Nacional.

O consumo indevido, em sua maioria, é fruto de falhas nos aplicativos dos sistemas emissores de documentos fiscais eletrônicos dos contribuintes. A falha mais comum é o consumo dos Web Services do ambiente de autorização em loop para a mesma mensagem. Ao adotar essa prática de reenvio, o aplicativo da empresa acaba por receber sempre a mesma rejeição, sobrecarregando os sistemas.

Diante da definição, e visando a evitar as penalidades previstas e outras decorrentes da falta de emissão de notas fiscais, os contribuintes devem entrar em contato com seus fornecedores de sistemas imediatamente para que façam as adequações necessárias. Para a NFC-e, também pode ser feita consulta ao Manual de Boas Práticas no desenvolvimento de emissor de NFC-e, disponível no link.

Principais Rejeições

As principais rejeições que fazem com que a aplicação da empresa opere em loop são:

– Rejeição “778 – Informado NCM inexistente”

Aplicativo da empresa envia a NFC-e e recebe a rejeição “778 – Informado NCM inexistente”. A aplicação da empresa se mantém em loop enviando a mesma NF-e / NFC-e muitas vezes no mesmo dia, e em alguns casos durantes vários dias, recebendo sempre a mesma rejeição.

Ação da empresa: revisar previamente o seu cadastro de produtos, evitando esse tipo de rejeição. Caso ocorra, corrigir o cadastro e o item correspondente na Nota Fiscal antes do reenvio.

– Rejeição “204 – Duplicidade de NF-e”

Aplicativo da empresa envia a NF-e / NFC-e para o ambiente de autorização e este documento fiscal eletrônico é autorizado. Provavelmente o aplicativo da empresa, por algum motivo, não recebe a resposta do ambiente de autorização, reenviando a mesma NF-e / NFC-e em loop, de modo a receber sempre a mesma rejeição.

Ação da empresa: ao identificar esse erro, marcar a nota como autorizada e não enviá-la novamente. Caso necessário, o protocolo de autorização pode ser obtido pelo Web Service de consulta protocolo, informando a chave de acesso correspondente. 

– Rejeição “539 – Duplicidade da NF-e, com diferença na Chave de Acesso”

Caso semelhante ao anterior, mas neste caso o aplicativo da empresa reenvia a mesma NF-e / NFC-e, com a mesma Série e Número da NF-e, mas com tipo de emissão diferente (emissão em contingência). O ambiente de autorização devolve a rejeição “539 – Duplicidade da NF-e, com diferença na Chave de Acesso” e o aplicativo da empresa se mantém em loop, reenviando a mesma mensagem e recebendo a mesma rejeição.

Ação da empresa: nesse tipo de rejeição, a aplicação da Sefaz Autorizadora retorna a chave de acesso da Nota Fiscal previamente autorizada. Ao identificar esse erro, marcar a nota como autorizada e não enviá-la novamente. Caso necessário, o protocolo de autorização pode ser obtido pelo Web Service de consulta protocolo, informando a chave de acesso da Nota Fiscal previamente autorizada. 

– Rejeição “291 – Certificado de Assinatura – Data de Validade”

Todas as NF-e / NFC-e são assinadas digitalmente com o Certificado Digital da empresa emitente. O aplicativo da empresa não mantém controle sobre a Data de Validade deste Certificado Digital e continua utilizando um Certificado Digital vencido para a assinatura dos documentos enviados. Todos os documentos fiscais são rejeitados com a rejeição “291 – Certificado de Assinatura – Data de Validade” e a empresa se mantém por dias utilizando um certificado vencido e recebendo a mesma rejeição.

Ação da empresa: a aplicação da empresa deve manter controle sobre a data de vencimento do certificado digital, evitando a ocorrência desse tipo de erro. Caso ocorra, as notas rejeitadas precisam ser assinadas com um certificado digital válido antes de serem reenviadas. 

– Rejeição “383 – Item com CSOSN indevido” e Rejeição “766 – Item com CST Indevido”

As empresas participantes ou não do Simples Nacional informam esta condição na Nota Fiscal, preenchendo o campo de CRT (Código de Regime Tributário) com o valor correspondente. Em relação à tributação do ICMS, para cada item deve ser informado o CST (Código de Situação Tributária) ou CSOSN (Código da Situação da Operação do Simples Nacional), conforme o CRT informado. O aplicativo da empresa falha na manutenção desta informação, desrespeitando uma validação simples e documentada no MOC (Manual de Orientação do Contribuinte), recebe a rejeição e se mantém em loop reenviando a mesma NF-e / NFC-e, de modo a seguir recebendo a mesma rejeição.

Ação da empresa: a aplicação da empresa deve controlar a forma de tributação da nota fiscal em conformidade com os dados do contribuinte informados também nessa mesma nota fiscal, evitando tal rejeição. Caso ocorra, corrigir a informação do contribuinte (campo CRT) ou do item (campo CST ou CSOSN), deixando-as em conformidade antes de reenviar a nota fiscal.

Fonte: Governo do Estado do Rio Grande do Sul