A Nota Fiscal eletrônica (NF-e) passa por atualizações periódicas para atender a demandas legislativas e otimizar processos fiscais. A Nota Técnica 2013.005 v1.03 detalha as modificações no leiaute da NF-e, migrando da versão 2.00 para a 3.10, e também na Nota Fiscal de Consumidor eletrônica (NFC-e). Estas alterações, implementadas entre 2013 e 2014, visam melhorar a qualidade das informações e a eficiência dos serviços de autorização.

Nota Técnica 2013.005: Visão geral das atualizações

Propósito e escopo

A Nota Técnica 2013.005 v1.03 foi emitida para agrupar e divulgar as necessidades de alteração do leiaute da NF-e, com o objetivo de evitar modificações frequentes nos sistemas de emissão para empresas e Secretarias de Fazenda (SEFAZ). O documento aborda funcionalidades opcionais disponibilizadas pelas SEFAZ para o serviço de autorização de uso da NF-e, as mudanças necessárias para a migração da versão 2.00 para a versão 3.10 do leiaute, e alterações nas regras de validação para melhorar a qualidade da informação prestada pelas empresas.

O histórico de alterações da Nota Técnica indica revisões pontuais:
* Versão 1.01: Incluiu mudanças da NT 2013.006, atualizando o leiaute da NF-e/NFC-e e as regras de validação. Adicionou regras de validação para rejeição de lote síncrono não suportado pela SEFAZ, impedimentos para Carta de Correção (CC-e) e cancelamento fora do prazo na NFC-e. Tornou obrigatória a identificação do Transportador na venda de combustível e adicionou validação opcional por UF sobre a informação da Nota de Empenho para vendas a Órgãos Públicos com desoneração de ICMS. Alterações nos campos de controle do ISSQN também foram implementadas.
* Versão 1.02: Focou em mudanças na documentação, como a eliminação do campo indISSRet e correções de regras de validação. Alterou a regra E03a-40 para aceitar operações internas com a tag idEstrangeiro e E10-30 para garantir o preenchimento do Código do Município para destinatários no exterior. Modificou a validação W03-10 e W16-10 para totais da NF-e. Incluiu regras para direcionar o consumo dos Web Services corretamente (nfeRecepcao vs nfeAutorizacao). No Schema XML, restringiu o campo IE do destinatário a algarismos (não mais "ISENTO"), limitou o percentual de diferimento no ICMS51 a 100%, tornou o campo idEstrangeiro obrigatório para destinatários no exterior e permitiu até 8 ocorrências para o campo NVE.
* Versão 1.03: Introduziu modificações para as SEFAZ Autorizadoras, principalmente após a entrada em produção da versão 3.10. Alterou a data de desativação da NFC-e v3.00 para 31/07/2014. Modificou regras de validação, como a finalidade de emissão para devolução de mercadoria, permitindo novamente a consolidação de múltiplas devoluções em uma única NF-e. Incluiu rejeição da NFC-e para emitentes com Código de Segurança do Contribuinte válido e exceções em validações de CFOP e CST. Alterações no Schema XML permitiram a tag idEstrangeiro sem conteúdo em operações com o Exterior, valores zero para o CST=51 e vAFRMM, e tornou a exigência do grupo de formas de pagamento (YA) na NFC-e um critério da UF.

Serviços de autorização: Inovações

As Secretarias de Fazenda (SEFAZ) implementaram melhorias nos serviços de autorização de uso da NF-e. As empresas podem:
* Solicitar resposta síncrona: Para lotes que contenham somente uma NF-e, sem a necessidade de gerar um recibo para consulta posterior do resultado do processamento.
* Encaminhar mensagem compactada: A mensagem de envio de Lote de NF-e pode ser compactada no padrão GZip, com o resultado convertido para Base64, reduzindo o consumo da rede interna e do canal de Internet em aproximadamente 70%. Este recurso é implementado através do método NfeAutorizacaoLoteZip no Web Service NfeAutorizacao.

Essas melhorias são opcionais. A empresa pode manter o processo de autorização de uso atual, que é assíncrono. Os Web Services foram atualizados: NfeRecepcao2 (envio) e NfeRetRecepcao2 (consulta) para a versão 2.00, e NfeAutorizacao (envio) e NfeRetAutorizacao (consulta) para a versão 3.10.

A infraestrutura de processamento na SEFAZ foi separada para NF-e e NFC-e, incluindo bancos de dados e servidores, devido ao volume de NFC-e. As SEFAZ podem disponibilizar domínios (URLs) diferentes para os dois modelos, com rejeição (450 ou 775) caso o direcionamento esteja incorreto.

Modificações no leiaute da NF-e

A versão 3.10 do leiaute da NF-e trouxe as seguintes mudanças:
* Identificação do modelo: O campo mod (B06) agora pode ser 55 (NF-e) ou 65 (NFC-e).
* Data e Hora de Emissão: Os campos dhEmi (B09) e dhSaiEnt (B10) para data e hora de emissão/saída/entrada, e dhCont (B28) para data e hora de entrada em contingência, foram padronizados para o formato UTC (AAAA-MM-DDThh:mm:ssTZD), aceitando horários de qualquer região do mundo.
* Tipo de Operação: Um novo campo idDest (B11a) identifica se a operação é interna (1), interestadual (2) ou com o exterior (3), permitindo autorização de NF-e interna para destinatários em outras UF ou no exterior.
* Formato do DANFE: O campo tpImp (B21) inclui opções específicas para DANFE NFC-e (4 para impressão normal, 5 para mensagem eletrônica).
* Finalidade de Emissão: A finNFe (B25) agora inclui a finalidade 4 para "Devolução de mercadoria", exigindo que a NF-e contenha apenas itens de devolução e um documento fiscal referenciado.
* Consumidor Final e Presença: Novos campos obrigatórios indFinal (B25a) (0=Normal, 1=Consumidor final) e indPres (B25b) (0=Não se aplica, 1=Operação presencial, 2=Internet, 3=Teleatendimento, 4=NFC-e com entrega em domicílio, 9=Outros).
* Identificação do Destinatário: O campo indIEDest (E16a) indica a condição da Inscrição Estadual (IE) do destinatário (1=Contribuinte ICMS, 2=Contribuinte isento, 9=Não contribuinte). A IE não pode ser informada como "ISENTO" no leiaute 3.10, somente algarismos. Para NFC-e, a identificação do destinatário é opcional em vários níveis, exceto para operações com valor superior ao limite ou entrega a domicílio. O campo idEstrangeiro (E03a) é usado para compradores estrangeiros, podendo ser nulo.
* Autorização para Acesso ao XML: Um novo grupo autXML (GA01) permite que o emitente indique outros CNPJs/CPFs autorizados a acessar o arquivo XML da NF-e.
* Detalhamento do NCM (NVE): Incluído o campo opcional NVE (I05a) para detalhar a Nomenclatura Comum do MERCOSUL (NCM) com a Codificação de Valor Aduaneiro e Estatística.
* Controle de Importação e Exportação: Novos controles para importação por item (tpViaTransp, vAFRMM, tpIntermedio, CNPJ e UFTerceiro do adquirente/encomendante) e o número do Ato Concessório de Drawback (nDraw). Para exportação, um grupo detExport (I50) controla informações por item, sendo obrigatório para alguns CFOPs e contendo campos como nRE (Registro de Exportação) e chNFe (Chave de Acesso da NF-e de exportação indireta).
* Produtos Específicos: Campo pMixGN (LA03) para percentual de Gás Natural em misturas de GLP. Novo grupo nRECOPI (LB01) para operações com papel imune, vinculando ao Registro e Controle das Operações com o Papel Imune Nacional.
* Aumento de Casas Decimais: A alíquota dos impostos permite até 4 casas decimais em diversos campos como pICMS, pRedBC, pICMSST, pIPI, pPIS, pCOFINS e vAliq do ISSQN.
* Grupos de Tributação:
* ICMS: Grupos ICMS20, ICMS30, ICMS40, ICMS51, ICMS70, ICMS90 foram ampliados com campos opcionais para vICMSDeson (valor do ICMS desonerado) e motDesICMS (motivo da desoneração). O grupo ICMS51 (Diferimento) inclui campos para vICMSOp, pDif e vICMSDif. O total da NF-e (W01) agora inclui o vICMSDeson.
* IPI: Permite a concomitância de IPI e ISSQN no mesmo item. Novo grupo opcional (impostoDevol) para informar o vIPIDevol (valor do IPI devolvido) para NF-e de devolução de mercadoria.
* PIS e COFINS: Os grupos PISNT e COFINSNT agora incluem o CST=05 (Operação Tributável, Substituição Tributária). A informação desses grupos é opcional para a NFC-e, mas obrigatória para a NF-e.
* ISSQN: Não exige mais o CNAE quando a Inscrição Municipal é informada. Permite a Inscrição Municipal do Tomador do Serviço. O campo cListServ (U06) adota o formato "NN.NN". O grupo de totais do ISSQN (ISSQNtot) foi ampliado.
* Informações de Comércio Exterior – Exportação: O grupo exporta (ZA01) foi alterado para incluir a UF de Embarque (UFSaidaPais) e a Descrição do Local de Embarque ou Despacho (xLocExporta, xLocDespacho).

Nota Fiscal de Consumidor Eletrônica (NFC-e)

A NFC-e (Modelo 65) foi implementada com base no mesmo leiaute da NF-e (Modelo 55), mas com validações específicas. Sua abrangência se restringe a operações comerciais de venda de mercadoria a consumidor final, realizadas presencialmente ou com entrega a domicílio, exclusivamente dentro do estado (operações internas), sem gerar crédito de ICMS para o adquirente. A aceitação deste modelo de documento, bem como o credenciamento das empresas para sua emissão e a adoção de contingência off-line ou dispensa de impressão do DANFE NFC-e, são facultativos para cada UF.

No preenchimento, a identificação do destinatário na NFC-e é opcional em diversos níveis, permitindo a omissão do grupo dest ou a informação apenas de CPF/CNPJ/idEstrangeiro sem nome ou endereço completo. Contudo, em entregas a domicílio (indPres=4) ou operações com valor superior a um limite estabelecido, a identificação completa do destinatário, endereço de entrega e transportador torna-se obrigatória.

O grupo de formas de pagamento (pag, YA01) para a NFC-e detalha os meios de pagamento (dinheiro, cheque, cartão de crédito/débito, vales) e seus respectivos valores. A soma dos pagamentos deve ser igual ao valor total da NFC-e.

Regras de validação e prazos de implementação

As validações dos dados da NF-e são realizadas pela SEFAZ Autorizadora. Essas regras visam orientar as empresas sobre como informar os dados na NF-e. As validações foram atualizadas para incorporar os novos campos e controles do leiaute 3.10.
Algumas validações alteradas incluem:
* Inscrição Estadual (IE): A validação da IE (C17-20, E17-50) agora desconsidera zeros não significativos antes da verificação do dígito de controle, para facilitar o preenchimento por parte das empresas.
* Destinatário não Habilitado: A critério da UF, a validação do destinatário (5E17-50, 5E17-60) pode ocorrer mesmo sem a IE, verificando se o CNPJ está ativo ou se o destinatário está habilitado a operar na UF, podendo levar à denegação de uso.
* Capítulo do NCM: Uma nova regra (I05-40) verifica a validade do capítulo do NCM (2 posições), rejeitando códigos inválidos.
* Operação com Combustível: A descrição do produto (LA02-10) deve seguir o padrão definido pela ANP.
* Devolução de Mercadoria: Uma finalidade de emissão específica (finNFe=4) foi criada para NF-e de devolução, permitindo unicamente itens relacionados à devolução.
* Critério de Arredondamento: O somatório dos valores dos itens deve corresponder exatamente ao valor total. A verificação do produto da base de cálculo e alíquota aceita uma tolerância de até R$ 0,01.

Os prazos para a entrada em vigência das mudanças foram escalonados:
* NF-e (Modelo 55):
* Ambiente de Homologação: 03/02/2014
* Ambiente de Produção: 10/03/2014
* Desativação da versão 2.00: 01/12/2014
* NFC-e (Modelo 65):
* Desativação da versão 3.00: 31/07/2014
* Para UF do projeto piloto (AC, AM, MA, MT, RN, RS e SE): Homologação em 02/12/2013, Produção em 06/01/2014.
* Para demais UF: cronograma próprio.

Processamento e validação de documentos fiscais

Lote de NF-e: Processamento síncrono e compactação

A arquitetura padrão do Sistema NF-e é assíncrona, onde o emitente envia um lote e recebe um recibo para posterior consulta do resultado. Para otimizar, a nova versão do leiaute introduziu a possibilidade de resposta síncrona para lotes contendo uma única NF-e. Isso elimina a etapa de consulta do recibo. Os Web Services para envio de lote foram atualizados de NfeRecepcao2 (v2.00) para NfeAutorizacao (v3.10) e para consulta de recibo de NfeRetRecepcao2 para NfeRetAutorizacao.

Adicionalmente, para reduzir o tráfego de dados, a mensagem de envio do lote pode ser compactada. O novo método NfeAutorizacaoLoteZip no Web Service NfeAutorizacao aceita a mensagem enviNFe compactada no padrão GZip e convertida para Base64. Uma falha na descompactação retorna o erro 416 – Rejeição: Falha na descompactação da área de dados.

Serviços de consulta e inutilização

Os serviços de consulta de resultado de lote, situação da NF-e e status do serviço tiveram suas mensagens de resposta atualizadas para incluir a Data e Hora do processamento no formato UTC. A inutilização de numeração da NF-e (inutNFe) agora permite especificar o modelo do documento fiscal (55 para NF-e ou 65 para NFC-e) no campo mod. As validações de controle de chamada ao Web Service (C04a, C06) foram incluídas para garantir que as mensagens sejam enviadas para a versão correta do Web Service, rejeitando envios equivocados.

Registro de eventos e regras de validação específicas

As regras de validação para o Registro de Eventos, como Carta de Correção (CC-e) e Cancelamento, foram atualizadas. Para a NFC-e, o evento de Carta de Correção (GA03a) não é permitido (Rejeição: 784). O cancelamento da NFC-e é rejeitado (GA06a, Rejeição: 770) se a nota foi autorizada há mais de 30 minutos. Validações adicionais, como J02f e G04f, verificam a chave de acesso para garantir que o modelo do documento fiscal seja 55 ou 65.

Eliminação das variáveis SOAP Header

No futuro, a utilização de variáveis no SOAP Header para chamadas aos Web Services de autorização será eliminada. Atualmente, versaoDados e cUF são passadas no SOAP Header para otimização inicial. Com a desativação da versão 2.00, as empresas poderão deixar de informar essas variáveis, que passarão a ser lidas diretamente dos atributos versao e de outros campos da mensagem XML. Essa mudança simplifica a comunicação e reduz ocorrências de manutenção.

As regras de validação relativas a essas variáveis, como a que confere se o código da UF do Emitente difere da UF do Web Service (B02-10, Rejeição: 226), permanecem. Uma nova validação (B02-20, Rejeição: 476) foi adicionada para garantir que todas as NF-e de um lote sejam da mesma UF, principalmente para o controle da SEFAZ Virtual. O mesmo princípio se aplica ao Registro de Eventos, com a validação G02a (Rejeição: 477).

Compartilhamento de informações entre SEFAZ

A mudança de leiaute expandiu os critérios de compartilhamento de NF-e autorizadas entre as SEFAZ. Além dos critérios existentes (UF de destino, entrega/retirada, desembaraço, embarque, consumo de combustível e partilha de ICMS), foram adicionados:
* UF do endereço do destinatário em outra UF, mesmo em operação interna.
* UF do adquirente ou do encomendante que aparece na importação (DI/UFTerceiro).
* UF da Chave de Acesso da NF-e referenciada (NFRef/refNFe).
* UF da Nota Fiscal Modelo 1 (NFRef/refNF), Nota Fiscal de Produtor Rural (NFRef/refNFP) ou Conhecimento de Transporte Eletrônico (CT-e) (NFRef/refCTe) referenciados.

Esses critérios visam garantir a distribuição adequada das informações fiscais entre os órgãos de fiscalização pertinentes.

Conclusão

A Nota Técnica 2013.005 v1.03 promoveu uma série de adaptações e aprimoramentos no leiaute da NF-e e da NFC-e, visando otimizar a comunicação, padronizar dados e aprimorar a qualidade das informações fiscais. Contadores e empresários precisam estar atentos a essas especificações, como as mudanças nos formatos de data/hora, na identificação de operações e destinatários, nos novos controles para comércio exterior e nas formas de pagamento para NFC-e. A conformidade com a versão 3.10 do leiaute e a correta aplicação das regras de validação são essenciais para garantir a emissão de documentos fiscais sem intercorrências e o uso eficiente dos serviços disponibilizados pelas SEFAZ.