NFe e NFCe: nota divulga cronograma, regras de validação, datas de ativação e mais novidades

A Nota Técnica 2019.001 traz alterações importantes nas regras de validação da Nota Fiscal Eletrônica (NFe) e da Nota Fiscal de Consumo Eletrônica (NFCe).

O Sistema Nota Fiscal Eletrônica liberou nesta segunda-feira (18) a Nota Técnica 2019.001 com a Criação e Atualização de Regras de Validação da Nota Fiscal eletrônica (NFe) e da Nota Fiscal de Consumo Eletrônica (NFCe).

As novidades e alterações da nota estão destacadas em amarelo no arquivo, que está disponível aqui, e inclui entre outras mudanças:

• Alteração do leiaute, nomeando a tag do grupo de Crédito Presumido;
• Alteração do leiaute, nomeando a tag do grupo de Crédito Presumido (tag:gCred, Id:I05g);
• Alteração das Regras de Validação que tratam das operações de aquisição ou prestação de serviços (RV I08-160 e I08-70); e eliminação da RV I08-17, sobre o mesmo assunto;
• Alteração da data de ativação das Regras de Validação referentes à tabela de cBenef por CST para o Distrito Federal: alteração da data de ativação em produção para NFC-e (modelo 65), pelo Distrito Federal, das regras de validação N12-85, N12-86 e N12-94;
• Inclusão da obrigatoriedade de código de benefício fiscal para o Espírito Santo: incluída a obrigatoriedade de preenchimento, na NF-e modelo 55, do código de benefício fiscal para o Espírito Santo conforme legislação interna do Estado
• Observação: o schema entra em produção em 06/05/2024;
• Alteração da data de ativação das Regras de Validação referentes à tabela de cBenef por CST para o Distrito Federal, para NFC-e (modelo 65), pelo Distrito Federal, das regras de validação N12-85, N12-86 e N12-94;
• Entre as novidades em destaque está a criação da Regra de Validação I05g-10 a ser ativada a partir de 02/09/2024 em produção, verificando a permissão de utilização do grupo de informações sobre crédito presumido na UF. Essa nova regra permite que determinada UF possa validar o correto preenchimento da tag: gCred. Além disso, inclui a exceção que exclui a NFF da aplicação da regra.
• A nota ainda divulga o cronograma de ativação de regras de validação para SP e altera as datas de ativação das Regras de Validação referentes à tabela de cBenef por CST para Santa Catarina.

Novidades e Alterações Gerais

Além das validações, as NTs podem introduzir outras melhorias:

• Novos Códigos de Rejeição: Cada nova regra ou alteração geralmente vem acompanhada de um ou mais códigos de rejeição específicos. Isso é uma “novidade” importante para quem trabalha com TI, pois facilita a depuração e o entendimento do motivo da não autorização.
• Melhorias na Performance dos Web Services (Implícitas): Embora a NT não detalhe diretamente, o objetivo de otimizar a qualidade dos dados pode levar a melhorias na performance geral dos sistemas da SEFAZ, ao reduzir o processamento de notas com erros básicos.
• Foco na Inteligência Fiscal: Ao coletar dados mais limpos e detalhados, a Receita Federal e as SEFAZes aprimoram sua capacidade de análise fiscal e cruzamento de informações.

Regras de Validação Aprimoradas

Este é o cerne das alterações trazidas pela NT 2019.001. As regras de validação são o conjunto de verificações que o sistema da SEFAZ faz ao receber uma NFe ou NFCe para autorizá-la. Se alguma regra não for cumprida, a nota é rejeitada, e um “código de rejeição” é retornado, indicando o erro.

As novas e alteradas regras visam:

• Maior Consistência de Dados: Garantir que os dados informados sejam lógicos e estejam em conformidade com a legislação.
• Combate à Sonegação e Fraudes: Dificultar a emissão de notas com informações incorretas ou incompletas que possam ser usadas para fins ilícitos.
• Padronização: Forçar o uso correto de campos e códigos específicos.

Exemplos de Regras de Validação Comuns e Possíveis Alterações (Baseadas em NTs em Geral, Incluindo a 2019.001 em seu escopo de aprimoramento):

• Validação de GTIN (Global Trade Item Number/EAN):
  • Antes: O campo cEAN (código de barras do produto) poderia ser preenchido incorretamente ou com valores genéricos.
  • Depois: A NT 2019.001, assim como outras, intensificou a validação do GTIN. Se o produto possui GTIN, ele deve ser informado, e a SEFAZ pode validar se o GTIN informado é válido (ou seja, se ele existe na base de dados do Cadastro Centralizado de GTIN). Se não for válido ou estiver ausente quando deveria estar, a nota é rejeitada (ex: Rejeição 882: GTIN (cEAN) inválido).
• Validação de CRT (Código de Regime Tributário) com CST/CSOSN:
  • Antes: Era possível que um emissor do Simples Nacional (CRT=2) utilizasse um CST (Código de Situação Tributária) de regime normal, ou vice-versa, sem ser rejeitado.
  • Depois: A NT 2019.001 reforçou as regras de compatibilidade. Um emitente do Simples Nacional deve usar os CSOSN (Código de Situação da Operação do Simples Nacional) específicos para o Simples, e um emitente do Regime Normal deve usar os CSTs. A incompatibilidade gera rejeição (ex: Rejeição 388: Código de Situação Tributária do IPI incompatível com o Código de Enquadramento Legal do IPI).
• Validação de Endereços e Códigos de Município/UF:
  • Antes: Erros de digitação ou códigos de IBGE inválidos para municípios podiam passar.
  • Depois: Validações mais rigorosas garantem que o endereço do emitente e do destinatário, especialmente o código do município (cMun) e a UF, correspondam a dados válidos na tabela do IBGE.
• Regras de Pagamento:
  • Antes: As informações de pagamento eram mais flexíveis.
  • Depois: A NT 2019.001 (e complementares) trouxe mais detalhes e validações para o grupo de informações de pagamento (<pag>), exigindo que o valor do pagamento (vPag) seja igual ao valor total da NFe/NFCe, ou que os tipos de pagamento sejam consistentes. Isso ajuda a rastrear a forma como a transação foi concluída.

Campos e Grupos de Campos Chave na NT 2019.001

1. Detalhamento do Pagamento (<pag> e <detPag>)

Este grupo foi um dos mais impactados, visando maior transparência sobre como a transação foi paga.

• indPag (Indicador da Forma de Pagamento): Embora já existisse, a NT 2019.001 (e complementares) trouxe novas validações e cenários de uso para este campo, especialmente para diferenciar pagamentos à vista, a prazo, e outros.
• Grupo <detPag> (Detalhe do Pagamento): Este grupo permite informar mais detalhes sobre a forma de pagamento utilizada. A NT 2019.001 intensificou o uso e as validações dentro dele, com destaque para as informações de cartão.
  • vPag (Valor do Pagamento): A validação deste campo foi aprimorada, exigindo que o somatório dos vPag informados (se houver múltiplos pagamentos) seja compatível com o valor total da nota (vNF).
  • Sub-grupo de Cartão (<card>): Este sub-grupo, utilizado quando a forma de pagamento é cartão de crédito ou débito, ganhou maior relevância e validações mais rigorosas, incluindo campos como:
    • tpAtr (Tipo de Integração do Pagamento): Indica se o pagamento com cartão foi integrado com o sistema do contribuinte (ex: TEF) ou não integrado (ex: POS).
    • CNPJ (CNPJ da Instituição de Pagamento): CNPJ da operadora da maquininha de cartão.
    • tBand (Bandeira da Operadora de Cartão): Código da bandeira do cartão (ex: Visa, Mastercard, Elo).
    • cAut (Código de Autorização): Código de autorização da operação de cartão.

Impacto para o seu Negócio: Se o seu negócio envolve vendas diretas, especialmente com pagamentos via cartão, a correta implementação e preenchimento desses campos é crucial. Um sistema de gestão ou PDV que emite NFCe precisa estar integrado com as informações da transação de cartão para preencher esses dados automaticamente e evitar rejeições.

2. GTIN (cEAN e cEANTrib) – Validação Reforçada

Enquanto os campos cEAN (GTIN do produto comercial) e cEANTrib (GTIN da unidade tributável) já existiam, a NT 2019.001 intensificou drasticamente a validação deles.

• Exigência de Preenchimento: Para produtos que possuem GTIN cadastrado (o código de barras reconhecido mundialmente), o seu preenchimento correto se tornou mandatório.
• Consulta ao Cadastro Centralizado de GTIN: Foi estabelecido um processo de validação em que o GTIN informado na nota é consultado em um cadastro centralizado (mantido pela GS1 Brasil). Se o GTIN não for válido (não existir, ou não pertencer ao CNPJ emitente, ou ter um formato inválido), a nota é rejeitada.

Impacto para o seu Negócio: Se você for vender produtos, a gestão do cadastro de produtos com seus respectivos GTINs (códigos de barras) se torna uma tarefa de alta prioridade. Erros nesse campo podem gerar rejeições de larga escala, impactando o fluxo de vendas. Sistemas de catálogo de produtos precisarão de validação de GTIN robusta.

3. Indicador de IE do Destinatário (indIEDest)

Este campo, já existente, teve suas regras de validação aprimoradas para garantir a consistência das informações do destinatário. Ele indica se o destinatário é:

• Contribuinte do ICMS (possui Inscrição Estadual).
• Contribuinte isento de Inscrição Estadual.
• Não Contribuinte.

Impacto para o seu Negócio: A correta identificação da situação fiscal do seu cliente (destinatário) é essencial. Se a indIEDest for informada incorretamente (ex: indicar que o destinatário tem IE quando na verdade é isento ou não contribuinte), ou se a IE for informada quando não deveria, a nota pode ser rejeitada. Isso reforça a necessidade de um cadastro de clientes preciso e atualizado.

4. Validação do Código do Município (cMun)

Embora não sejam “novos campos”, as validações para o cMun (Código do Município, segundo tabela do IBGE) do emitente, destinatário, local de entrega e retirada foram rigorosamente aprimoradas.

• Exigência de Código Válido: O sistema autorizador passou a validar se o código do município informado realmente existe na tabela do IBGE e se corresponde à Unidade da Federação (UF) informada.

Impacto para o seu Negócio, Pedro: Garante a precisão geográfica dos documentos fiscais, auxiliando na fiscalização e na distribuição de impostos. Seus cadastros de endereços precisarão ser consistentes com a tabela oficial do IBGE.