Erro 202 - Falha no reconhecimento da autoria ou integridade do arquivo digital

Rejeição

202 - Falha no reconhecimento da autoria ou integridade do arquivo digital

Causa

As possíveis causas para que a rejeição aconteça são:

ü Arquivo XML enviado fora da estrutura padrão estabelecido pela legislação.

ü Falha no namespace do arquivo template utilizado para a UF.

ü Assinatura digital (arquivo XML sem assinatura, certificado digital vencido, não atende aos padrões estabelecidos).

ü Falha técnica, servidor da SEFAZ com instabilidade.

Localizando a Informação

Utilizando o Gestão DF-e, clique no Menu  e acesse as opções [NF-e Federal / Consulta de NF-e Emitidas]. 

Utilizando os filtros de pesquisa, busque a nota fiscal que apresentou a rejeição, acione o botão [XML – Baixar XML] e a aplicação fará download do arquivo compactado em pasta específica.

Descompacte o arquivo e utilizando algum editor de texto (exemplo: Bloco de Notas), abra o XML. O arquivo será demonstrado conforme segue:

Copie todo o conteúdo do XML e, utilizando o validador disponível em https://www.sefaz.rs.gov.br/nfe/NFE-VAL.aspx, cole e valide a informação.

Exemplo:

Se houver falhas no conteúdo XML ao validar, o resultado será apresentado como no exemplo abaixo:

Dentre as possíveis causas da rejeição 202, estão:

ü    Arquivo enviado fora da estrutura padrão estabelecida pela legislação 

Quando é realizado o envio de uma NF-e, o XML enviado à SEFAZ é comparado com o padrão estabelecido pela legislação. Pode ocorrer de tais informações chegarem aos servidores da Receita com alguma alteração de estrutura, considerada diferente do estabelecido, causando a rejeição.

Para garantir minimamente a integridade das informações prestadas e a correta formação dos arquivos XML, o contribuinte deverá submeter o arquivo da NF-e e as demais mensagens XML para validação pelo Schema (XSD – XML Schema Definition), disponibilizado pela Secretaria de Fazenda Estadual antes de seu envio.

Os schemas válidos para o Sistema da Nota Fiscal Eletrônica serão disponibilizados no Portal Nacional da NF-e e serão liberados após autorização da Coordenação Técnica do Sistema.

A cada nova liberação será disponibilizado um arquivo compactado contendo o conjunto de schemas a serem utilizados pelas empresas para a geração dos arquivos XML. Este arquivo será denominado “Pacote de Liberação” e será numerado sequencialmente. Os pacotes de liberação serão identificados pelas letras “PL”, seguida do número do pacote. Exemplificando: O pacote PL_001.zip representa o “Pacote de Liberação” nº 1 de schemas da Nota Fiscal Eletrônica.

Os schemas válidos estão contidos no pacote de liberação e são identificados pelo seu nome, seguido da versão do respectivo schema. Por exemplo: o schema de “Envio de Lotes de Nota Fiscal Eletrônica” corresponderá a um arquivo com a extensão .XSD, que terá o nome de “enviNFe_v9.99.xsd”, onde v9.99, corresponde a versão do respectivo schema.

Para identificar quais os schemas que sofreram alteração em um determinado pacote liberado, deve-se comparar o número da versão do schema deste pacote com o do pacote anterior.

Para as atualizações de versões que decorrem de correção de regra de validação, modificação da obrigatoriedade de campo, etc, que não modificam a estrutura do Schema através da inclusão ou exclusão de campos, serão liberados novos pacotes de liberação sem a atualização do número do pacote. Nestas situações os pacotes mais recentes serão identificados com o acréscimo de letras minúsculas do alfabeto, como por exemplo: PL_002a.ZIP, indicando que se trata da primeira versão corrigida do PL_002.ZIP.

O controle de versão de cada um dos schemas válidos para o Sistema Nota Fiscal Eletrônica compreende uma definição nacional sobre:

ü  qual a versão vigente (versão mais atualizada);

ü  quais são as versões anteriores ainda suportadas por todas as SEFAZ.

Este controle de versões permite a adaptação dos sistemas de informática das empresas participantes do Sistema em diferentes datas; desta forma, algumas empresas poderão estar com uma versão de leiaute mais atualizada, enquanto outras empresas poderão ainda estar operando com mensagens em um leiaute anterior.

Não existem mudanças frequentes de leiaute de mensagens e as empresas dispõem de um prazo razoável para implementar as mudanças necessárias, conforme acordo operacional estabelecido.

Mensagens recebidas com uma versão de leiaute não suportada serão rejeitadas com uma mensagem de erro específica na versão do leiaute de resposta mais antiga em uso.

Na geração do arquivo XML da NF-e, com exceção dos campos identificados como obrigatórios no modelo, não deve ser inclusa tag de campo com conteúdo zero (para campos tipos numéricos) ou vazio (para campos tipos caracteres).

A regra deve estender-se para os campos onde não há indicação de obrigatoriedade e que, no entanto, seu preenchimento torna-se obrigatório por estar condicionado à legislação específica ou ao negócio do contribuinte. Neste caso, a tag deve constar com o valor correspondente e, para os demais campos, devem ser eliminadas as tags.

ü   Falha no namespace do arquivo template utilizado para a UF

Quando é feito o envio de uma NF-e, o template é como um molde da mensagem. O WebService aguarda essa mensagem de acordo com esse template, portanto, se houver alterações no arquivo e o emitente da NF-e não estiver gerando-o de acordo com o novo modelo essa rejeição será apresentada demonstrando uma falha. Todavia, na maioria das vezes essa rejeição está relacionada a uma falha da própria SEFAZ.

O documento XML deve conter uma declaração única de namespace no elemento raiz do documento com o seguinte padrão: <enviNFe xmlns=http://www.portalfiscal.inf.br/nfe>

É vedado o uso de declaração namespace diferente do padrão estabelecido. Não é permitida a utilização de prefixos de namespace. Essa restrição visa otimizar o tamanho do arquivo XML. Assim, ao invés da declaração <NFe xmlns:nfe=http://www.portalfiscal.inf.br/nfe> (exemplo para o XML de NF-e com prefixo nfe), deve ser adotada a declaração: <NFe xmlns =”http://www.portalfiscal.inf.br/nfe”>.

A declaração do namespace da assinatura digital deve ser realizada na tag <Signature>, conforme exemplo abaixo.

ü    Falha na assinatura digital (arquivo XML sem assinatura, certificado digital vencido, não atende aos padrões estabelecidos)

O certificado digital utilizado no Sistema Nota Fiscal eletrônica deve ser emitido por Autoridade Certificadora credenciada pela Infraestrutura de Chaves Públicas Brasileira (ICP-Brasil), tipo A1 ou A3, contendo o CNPJ da pessoa jurídica titular do certificado digital no campo otherName OID = 2.16.76.1.3.3.

Os certificados digitais serão exigidos em 2 (dois) momentos distintos:

ü       Assinatura de Mensagens: 

O certificado digital utilizado para essa função deve conter o CNPJ de um dos estabelecimentos da empresa emissora da NF-e. Por mensagens, entenda-se: o Pedido de Autorização de Uso (Arquivo NF-e), o Pedido de Cancelamento de NF-e, o Pedido de Inutilização de Numeração de NF-e, o Registro de Evento e demais arquivos XML que necessitem de assinatura. O certificado digital deve ter o “uso da chave” previsto para a função de assinatura digital, respeitando a Política do Certificado.

ü       Transmissão (durante a transmissão das mensagens entre o servidor do contribuinte e o Portal da Secretaria de Fazenda Estadual)

O certificado digital utilizado para identificação do aplicativo do contribuinte deve conter o CNPJ do responsável pela transmissão da mensagem, não necessariamente o CNPJ da empresa emissora da NF-e, devendo ter a extensão Extended Key Usage com permissão de "Autenticação Cliente".

As mensagens enviadas ao Portal da Secretaria de Fazenda Estadual são documentos eletrônicos elaborados no padrão XML e devem ser assinados digitalmente com um certificado digital que contenha o CNPJ de um dos estabelecimentos da empresa emissora da NF-e objeto do pedido. Alguns elementos presentes dentro do Certificado do contribuinte torna desnecessária a sua representação individualizada no arquivo XML. Portanto, o arquivo XML não deve conter os elementos:

<X509SubjectName>

<X509IssuerSerial>

<X509IssuerName>

<X509SerialNumber>

<X509SKI>

Evitar o uso das tags abaixo, pois as informações são obtidas a partir do Certificado do emitente:

<KeyValue>

<RSAKeyValue>

<Modulus>

<Exponent>

A NF-e utiliza um subconjunto do padrão de assinatura XML definido pelo https://www.w3.org/TR/xmldsig-core/, com o seguinte leiaute:

Schema XML: xmldsig-core-schema_v1.01.xsd

A assinatura do Contribuinte na NF-e é realizada na tag <infNFe> identificada pelo atributo Id, cujo conteúdo é um identificador único (chave de acesso) precedido do literal “NFe” que deve ser informado no atributo URI da tag <Reference>. Para as demais mensagens a serem assinadas, o processo é o mesmo mantendo sempre um identificador único para o atributo Id na tag a ser assinada. Segue abaixo um exemplo:

Para o processo de assinatura o contribuinte não deve fornecer a Lista de Certificados Revogados, já que a mesma será montada e validada por cada Portal da Secretaria de Fazenda Estadual no momento da conferência da assinatura digital.

A assinatura digital do documento eletrônico deverá atender aos seguintes padrões adotados:

ü     Padrão de assinatura: “XML Digital Signature”, utilizando o formato “Enveloped” (http://www.w3.org/TR/xmldsig-core/);

ü     Certificado digital: emitido por AC credenciada no ICP-Brasil (http://www.w3.org/2000/09/xmldsig#X509Data);

ü     Cadeia de certificação: EndCertOnly (incluir na assinatura apenas o certificado do usuário final);

ü      Tipo do certificado: A1 ou A3;

ü      Tamanho da chave criptográfica: compatível com os certificados A1 e A3 (1024 bits);

ü       Função criptográfica assimétrica: RSA http://www.w3.org/2000/09/xmldsig#rsa-sha1);

ü       Função de “message digest”: SHA-1 http://www.w3.org/2000/09/xmldsig#sha1);

ü       Codificação: Base64 (http://www.w3.org/2000/09/xmldsig#base64);

ü     Transformações exigidas: útil para realizar a canonicalização do XML enviado para realizar a validação correta da assinatura digital. São elas: Enveloped (http://www.w3.org/2000/09/xmldsig#enveloped-signature); C14N (http://www.w3.org/TR/2001/REC-xml-c14n-20010315).

O Procedimento para a validação da assinatura digital adotado pelas Secretarias de Fazenda Estaduais é:

ü    Extrair a chave pública do certificado;

ü    Verificar o prazo de validade do certificado utilizado;

ü    Montar e validar a cadeia de confiança dos certificados validando também a LCR (Lista de Certificados Revogados) de cada certificado da cadeia;

ü    Validar o uso da chave utilizada (assinatura digital) de tal forma a aceitar certificados somente do tipo A (não serão aceitos certificados do tipo S);

ü    Garantir que o certificado utilizado é de um usuário final e não de uma autoridade certificadora;

ü    Adotar as regras definidas pelo RFC 3280 para as LCR e cadeia de confiança;

ü    Validar a integridade de todas as LCR utilizadas pelo sistema;

ü    Prazo de validade de cada LCR utilizada (verificar data inicial e final).

A forma de conferência da LCR fica a critério de cada Secretaria de Fazenda Estadual, podendo ser feita de 2 (duas) maneiras: online ou download periódico. As assinaturas digitais das mensagens serão verificadas considerando a lista de certificados revogados disponível no momento da conferência da assinatura.

ü   Falha técnica, servidor da SEFAZ com instabilidade

Neste caso, deve-se aguardar a normalização para envio da nota novamente ou entrar em contato com a SEFAZ do seu estado para análise do problema.

Ao selecionar a nota com a rejeição, o sistema apresenta painel com os detalhes do documento selecionado no grid. Nele é possível avaliar o status do documento.

Como Resolver

Quando uma empresa emissora de NF-e (mod. 55) gera um arquivo eletrônico (XML) contendo as informações fiscais da operação comercial deve-o assinar digitalmente, transformando o arquivo em um documento eletrônico nos termos da legislação brasileira de maneira a garantir a integridade dos dados e a autoria do emissor. Sendo assim, os seguintes pontos devem ser verificados:

ü   Arquivo XML enviado à SEFAZ - deve estar de acordo com a estrutura prevista na legislação. Caso não esteja, deve ser alterado para atender ao padrão estabelecido.

ü   Namespace do arquivo template utilizado para a UF – deve estar de acordo com o padrão exigido pela SEFAZ. Caso não esteja, deve ser alterado ou corrigido de acordo com o padrão. Observar se a rejeição não está relacionada a uma falha da própria SEFAZ.

ü  Falha na assinatura digital (arquivo XML sem assinatura, certificado digital vencido, não atende aos padrões estabelecidos) – verificar a data de validade (início, fim) do certificado digital; o tipo de certificado utilizado (A1, A3); a cadeia de instalação; se está inválido; se está revogado; se o certificado raiz difere da ICP-Brasil.

ü   Falha técnica, servidor da SEFAZ com instabilidade - aguardar normalização para envio da nota novamente ou entrar em contato com a SEFAZ do seu estado para análise do problema.

Essas verificações são importantes porque o arquivo eletrônico será transmitido pela Internet para a Secretaria de Fazenda, Finanças ou Tributação da unidade federada de jurisdição do contribuinte emitente, a qual, após verificar a integridade formal, devolverá um protocolo de recebimento denominado “Autorização de Uso”, sem o qual não poderá haver o trânsito da mercadoria, salvo os casos previstos na legislação para a hipótese de haver problemas técnicos na comunicação do contribuinte com a Receita.

Após a Autorização de Uso, que transforma o documento eletrônico no Documento Fiscal denominado Nota Fiscal Eletrônica, a Secretaria de Fazenda Estadual disponibilizará consulta, através Internet, para o destinatário e outros legítimos interessados, que conheçam a chave de acesso do documento eletrônico.

Referência:

Manual de Orientação ao Contribuinte - Versão 6.00 – página 118