Manual de Orientação ao Contribuinte da Nota Fiscal de Serviço de Comunicação Eletrônica

1. Introdução

Este Manual tem por objetivo definir as especificações e os critérios técnicos necessários para a integração entre os Portais das Secretarias de Fazenda das Unidades Federadas e os sistemas das empresas emissoras da Nota Fiscal Fatura de Serviço de Comunicação Eletrônica — NFCom.

A versão original do Manual e os documentos que o atualizam podem ser encontrados no Portal da NFCom da SVRS, onde também se encontram os pacotes de liberação de schemas e demais documentos.

2. Considerações Iniciais

A NFCom foi desenvolvida de forma integrada pelas Secretarias de Fazenda das Unidades Federadas, pela Agência Nacional de Telecomunicações — ANATEL, pela Receita Federal do Brasil — RFB e por representantes das empresas do segmento de comunicações. A coordenação e a responsabilidade pelo desenvolvimento e pela implantação do projeto foram atribuídas ao ENCAT.

2.1 Conceitos

2.1.1 NFCom (modelo 62)

A Nota Fiscal Fatura de Serviço de Comunicação Eletrônica é um documento emitido e armazenado eletronicamente, de existência apenas digital, cuja validade jurídica é garantida pela assinatura digital do emitente e pela autorização de uso da administração tributária da unidade federada do contribuinte.

A NFCom, modelo 62, poderá ser utilizada, a critério das unidades federadas, para substituir:

• Nota Fiscal de Serviço de Comunicação, modelo 21;
• Nota Fiscal de Serviço de Telecomunicações, modelo 22.

2.1.2 DANFE-COM

O Documento Auxiliar da Nota Fiscal Fatura de Serviço de Comunicação Eletrônica — DANFE-COM — é o documento auxiliar impresso em papel. Suas especificações e modelos de leiaute estão definidos no Anexo II do MOC.

2.1.3 Chave de Acesso da NFCom

A Chave de Acesso da NFCom possui 44 caracteres e é composta pelos campos abaixo, dispersos no leiaute do documento. Com a implantação do CNPJ alfanumérico, as 12 primeiras posições do CNPJ do emitente passam a admitir letras maiúsculas e números, mantendo-se numéricas as duas posições dos dígitos verificadores.

• cUF: código da UF do emitente;
• AAMM: ano e mês de emissão;
• CNPJ: CNPJ do emitente, com 14 posições. Expressão regular prevista: [A-Z0-9]{12}[0-9]{2};
• mod: modelo do documento fiscal;
• serie: série do documento fiscal;
• nNF: número do documento fiscal;
• tpEmis: forma de emissão;
• nSiteAutoriz: site do autorizador que recepcionou a NFCom;
• cNFCom: código numérico que compõe a chave;
• cDV: dígito verificador da chave.

A expressão regular da chave passa a suportar letras nas 12 primeiras posições do CNPJ: [0-9]{6}[A-Z0-9]{12}[0-9]{26}. O dígito verificador garante a integridade da chave de acesso, protegendo-a principalmente contra erros de digitação.

2.1.4 Chave Natural da NFCom

A Chave Natural é composta pela UF, pelo CNPJ do emitente, pela série, pelo número e pelo modelo do documento, além da forma de emissão e do site em que a NFCom foi autorizada. O Sistema de Autorização de Uso valida a existência de documento previamente autorizado e rejeita novos pedidos com duplicidade da Chave Natural no mesmo ambiente.

3. Arquitetura de Comunicação com o Contribuinte

3.1 Modelo Conceitual

O ambiente autorizador disponibiliza serviços específicos para:

1. recepção de uma NFCom, modelo 62, em modelo síncrono;
2. consulta da situação atual da NFCom;
3. consulta do status do serviço;
4. registro de eventos.

O fluxo é sempre iniciado pelo aplicativo do contribuinte. O Web Service devolve a resposta e conclui o processamento na mesma conexão.

Arquitetura de Comunicação — visão conceitual reproduzida em formato acessível.

3.2 Padrões Técnicos

3.2.1 Padrão de Documento XML

Codificação. Os documentos seguem a recomendação W3C para XML 1.0 e utilizam codificação UTF-8. Cada arquivo deve possuir uma única declaração XML:

Namespace. O documento deve possuir uma única declaração de namespace no elemento raiz, sem prefixos:

A declaração do namespace da assinatura digital deve ser realizada na própria tag <Signature>.

Otimização. Salvo nos campos obrigatórios pelo leiaute ou pela legislação, não devem ser incluídas tags com conteúdo zero ou vazio. Também não devem ser incluídos zeros não significativos, espaços no início ou no fim de campos, comentários, anotações, documentação ou caracteres de formatação entre as tags.

Validação. Antes do envio, o contribuinte deve validar a NFCom e as demais mensagens XML pelo Schema XSD disponibilizado pelo ambiente autorizador.

3.2.2 Padrão de Comunicação

A comunicação utiliza a Internet e Web Services disponibilizados pela Secretaria de Fazenda da circunscrição do contribuinte ou por SEFAZ Virtual. O protocolo é TLS 1.2, com autenticação mútua. A troca de mensagens utiliza SOAP 1.2 e XML no padrão Document/Literal, conforme o WS-I Basic Profile.

As solicitações são enviadas por NFComDadosMsg e os resultados são devolvidos por NFComResultMsg.

3.2.3 Padrão de Certificado Digital

O certificado deve ser emitido por Autoridade Certificadora credenciada pela ICP-Brasil, do tipo A1 ou A3, e conter o CNPJ da pessoa jurídica titular. Ele é exigido em três momentos:

1. Assinatura das mensagens: certificado de um dos estabelecimentos da empresa emissora, com uso de chave para assinatura digital, atributo de não repúdio e CNPJ em otherName OID = 2.16.76.1.3.3.
2. Transmissão: certificado com o CNPJ do responsável pela transmissão, que não precisa ser o mesmo do estabelecimento emissor, e extensão Extended Key Usage com permissão de Autenticação Cliente.
3. QR Code em contingência offline: utiliza-se o certificado empregado na assinatura da NFCom para assinar a chave de acesso.

3.2.4 Padrão da Assinatura Digital

As mensagens enviadas ao ambiente autorizador devem ser assinadas digitalmente com certificado que contenha o CNPJ do estabelecimento matriz ou do estabelecimento emissor da NFCom.

O XML não deve conter <X509SubjectName>, <X509IssuerSerial>, <X509IssuerName>, <X509SerialNumber> ou <X509SKI>. Deve-se evitar também <KeyValue>, <RSAKeyValue>, <Modulus> e <Exponent>, pois essas informações são obtidas do certificado.

A tag <infNFCom> é assinada e identificada pelo atributo Id, formado pela chave de acesso precedida de NFCom. No atributo URI de <Reference>, esse identificador é precedido por #NFCom.

• assinatura XML Digital Signature, formato Enveloped;
• certificado X.509 emitido por AC credenciada pela ICP-Brasil;
• cadeia EndCertOnly;
• certificado A1 ou A3, sendo recomendado o uso de HSM;
• chave compatível com certificados A1 e A3, de 1024 bits;
• função assimétrica RSA e message digest SHA-1;
• codificação Base64;
• transformações Enveloped e C14N.

3.2.5 Validação da Assinatura Digital pelo Ambiente Autorizador

O ambiente autorizador extrai a chave pública, verifica a validade do certificado, monta e valida a cadeia de confiança e as LCRs, valida o uso da chave para assinatura, confirma que se trata de certificado de usuário final, adota as regras do RFC 3280 e verifica a integridade e a validade temporal das LCRs. A conferência pode ocorrer online ou por download periódico.

3.2.6 Resumo dos Padrões Técnicos

3.3 Modelo Operacional

As solicitações seguem implementação síncrona: o processamento é imediato e o resultado é obtido em uma única conexão.

O Web Service encaminha o resultado ao aplicativo do contribuinte e, se não houver outra mensagem, a conexão é encerrada.

3.4 Padrão de Mensagens dos Web Services

3.4.1 Área de Dados das Mensagens

A área <Body> da mensagem SOAP contém o documento definido para o Web Service acessado. Na recepção, a mensagem é compactada em GZip e convertida para Base64. Consulta, recepção de eventos e status utilizam XML sem compactação. O SOAP Header não deve ser informado.

3.4.2 Validação da Estrutura XML

A versão do leiaute controla as alterações da estrutura das mensagens. O parser valida cada XML contra seu Schema; qualquer divergência provoca erro de validação. O aplicativo deve gerar o leiaute em vigor e informar a versão na tag correspondente.

3.4.3 Schemas XML das Mensagens

A versão é acrescentada ao nome do arquivo após o literal _v, como em NFCom_v1.00.xsd e tiposGeral_v1.00.xsd. Quando um tipo básico muda, os Schemas que o utilizam também devem ser atualizados, inclusive nas declarações import ou include.

3.5 Versão dos Schemas XML

3.5.1 Liberação das Versões

Os Schemas válidos são disponibilizados no Portal Nacional da NFCom. Cada conjunto é distribuído em um Pacote de Liberação identificado por PL_NFCom e pela versão compatível do MOC, como PL_NFCom_1.00.zip.

3.5.2 Correção de Pacote de Liberação

Correções que não alterem a estrutura e não exijam adaptação dos aplicativos podem ser distribuídas sem mudança da versão principal do pacote, acrescentando-se letra minúscula, como em NFCom_PL_1.00a.zip.

3.5.3 Divulgação de Novos Pacotes

Novos pacotes e atualizações são divulgados por Nota Técnica no Portal Nacional da NFCom.

3.5.4 Controle de Versão

O controle nacional define a versão vigente e as versões anteriores ainda suportadas por todas as SEFAZ. Mensagens em versão não suportada são rejeitadas com erro específico, na versão mais recente do leiaute de resposta em uso.

3.6 Sistema de Registro de Eventos

O Sistema de Registro de Eventos — SRE — permite registrar fatos de interesse da NFCom originados pelo contribuinte ou pela administração tributária. Um evento pode alterar a situação do documento ou substituí-lo por outro.

O serviço é síncrono, disponibilizado pelo ambiente autorizador e propagado aos demais órgãos interessados. A mensagem contém identificação do autor, do evento e da NFCom vinculada, informações específicas e assinatura digital.

O Web Service é único e trata os eventos de forma genérica. O leiaute possui uma parte comum e uma parte específica, inserida em uma tag do tipo any.

3.6.1 Relação dos Tipos de Evento

3.6.2 Eventos de Marcação

Os eventos de marcação são gerados automaticamente pelo Fisco quando um documento referencia outro, como na substituição e na nota de ajuste. Eles são assinados com certificado digital da Secretaria de Fazenda autorizadora e devem constar da consulta pública dos documentos referenciados.

3.7 Data e Hora de Emissão e Outros Horários

Os campos de data e hora utilizam UTC completo com TimeZone. São aceitos horários na faixa UTC de −11 a +12. Exemplo: 2010-08-19T13:00:15-03:00.

3.8 SEFAZ Virtual

A unidade federada pode utilizar uma SEFAZ Virtual mediante Protocolo de Cooperação. O credenciamento e a autorização de uso continuam sob responsabilidade da SEFAZ de circunscrição do contribuinte. Para a empresa, a operação é transparente; a mudança visível é o endereço dos Web Services.

4. Web Services

Há um Web Service para cada serviço, com um método correspondente. Solicitação e retorno ocorrem na mesma conexão. O processo é iniciado pelo contribuinte, em XML e SOAP, por TLS com autenticação mútua. O primeiro erro encontrado interrompe o processamento e gera mensagem com código e descrição.

As URLs e os WSDLs são disponibilizados no Portal Nacional da NFCom. A descrição detalhada de cada serviço será apresentada nas páginas próprias do menu Web Services.

5. Web Services — Informações Adicionais

5.1 Ambiente de Homologação e Produção

O ambiente autorizador mantém ambientes de homologação e produção. A homologação é destinada a testes e integração; os documentos emitidos nesse ambiente não possuem valor fiscal. A entrada em produção depende de avaliação prévia das equipes de TI e de negócio da empresa.

Testes inadequados em produção podem acionar os mecanismos de controle de uso indevido e causar bloqueios administrativos.

5.2 Tratamento de Caracteres Especiais no XML

Caracteres que afetam o parser devem ser representados por sequências de escape:

5.3 Cálculo do Dígito Verificador da Chave de Acesso

Com o CNPJ alfanumérico, todos os caracteres que compõem a chave — números e letras — devem ser substituídos pelo número correspondente da tabela ASCII, subtraído de 48. Depois dessa conversão, aplica-se o módulo 11 à totalidade dos valores resultantes.

Os valores são multiplicados, da direita para a esquerda, pela sequência 2, 3, 4, 5, 6, 7, 8, 9, reiniciada sucessivamente. A soma das ponderações é dividida por 11:

Quando o resto for 0 ou 1, o DV será 0. No exemplo oficial, a soma é 644; o resto da divisão por 11 é 6 e o DV resultante é 5.

5.4 Número do Protocolo

O protocolo identifica univocamente as transações de autorização de uso e registro de eventos. Possui 16 posições:

• tipo 1: SEFAZ Autorizadora;
• tipo 2: autorizado em site alternativo do autorizador;
• tipo 3: SEFAZ Virtual RS.

O site é informado como 0 quando houver apenas um. O sequencial é numérico e anual. No DANFE-COM, o protocolo é acompanhado da data e da hora.

5.5 Tempo Médio de Resposta

O tempo médio de resposta mede a performance do serviço nos últimos cinco minutos. Ele considera o intervalo entre o recebimento da mensagem e o armazenamento do resultado do processamento. Valores inferiores a um segundo são informados como um segundo, e frações são arredondadas para cima.