NT 009 em produção restrita: o que testar antes de o leiaute mudar em produção

O Comitê Gestor da NFS-e liberou no ambiente de produção restrita três evoluções da Nota Técnica 009, versão 1.0, como parte da implantação gradual de alterações do leiaute. São elas: o reposicionamento dos campos CST e cClassTrib na estrutura do XML, a inclusão de novos fatos geradores na API de emissão (códigos 99.02 a 99.04) e a criação do grupo vAjusteBC a partir do merge dos grupos vDedRed e gReeRepRes. O ponto prático para quem integra é que o leiaute em produção segue, até 30/11/2026, o definido pela Nota Técnica nº 004, Versão 2.0 — ou seja, o que está em teste não é o que roda hoje em produção.

O problema concreto aparece quando a integração trata o ambiente de testes como espelho automático da produção. Um XML que muda de posição de campo, uma API que passa a aceitar novos códigos de fato gerador e um grupo que deixa de existir com o nome antigo exigem conferência própria: validar o esquema XSD publicado para a produção restrita, verificar se o mapeamento do ERP aponta para o caminho correto de CST e cClassTrib e checar se o código de fato gerador usado pela operação está entre os previstos. Nada disso é obrigação nova por si; é conferência de aderência ao leiaute que será implantado em produção em 01/12/2026.

Vale separar o que é mudança de leiaute do que é rejeição do autorizador. O texto oficial é explícito ao recomendar que municípios e contribuintes testem todas as evoluções a fim de garantir eventuais correções necessárias, e registra que ajustes da versão 1.01 e superiores da NT 009 também serão disponibilizados primeiro em produção restrita. Também informa que as notas de finalidade de ajuste e os eventos específicos para a RTC serão implantados conforme cronograma a ser divulgado — um lembrete de que nem tudo que envolve a reforma está coberto por esta liberação.

Para quem opera emissão de NFS-e, o valor de testar cedo está em descobrir divergência de mapeamento enquanto o ambiente de produção ainda aceita o leiaute anterior. A FoxNFe contribui nesse ponto pela rastreabilidade: cada cálculo gera uma resolução tributária imutável, vinculada a tenant, item, NCM/NBS, data, operação e versão da tabela e do calculador. Isso ajuda a investigar por que um documento saiu com determinada classificação quando a regra ou o produto mudou. O limite é claro: o registro comprova o que foi calculado com a configuração vigente; não substitui a conferência do leiaute, não valida a escolha de CST e cClassTrib e não garante aceite do autorizador.