Imagine que a equipe já tenha revisado os cálculos tributários do sistema de gestão empresarial (ERP). Mesmo assim, ao adaptar o emissor, surgem outras perguntas: onde gravar os novos valores, em que posição gerar cada elemento XML, quando um grupo pode aparecer e qual rejeição deve ser evitada. Essas decisões pertencem ao contrato técnico do documento fiscal.
A NT 2026.008 acrescenta informações de valor líquido e de ICMS previsto no pagamento antecipado à Nota Fiscal Eletrônica (NF-e) e à Nota Fiscal de Consumidor Eletrônica (NFC-e), com diferenças de aplicação entre os modelos. O trabalho envolve persistência, geração do XML, totalização e testes. Atualizar apenas a tela ou o componente de emissão não garante que todas essas partes continuem coerentes.
Este artigo trata dessas adaptações, sem desenvolver fórmulas de formação ou decomposição de preços. A análise foi conferida em 14 de outubro de 2026, usando a versão 1.00 disponível no catálogo consultado. Datas posteriores são previsões documentais; antes de liberar uma atualização do emissor, é necessário reconferir versão, pacote de esquemas e cronograma aplicável.
Leia o contrato antes de alterar o gerador
Há três informações que precisam ser registradas separadamente: a versão da nota técnica, a identificação do pacote de esquemas XML e a situação de implantação das regras. Uma nota publicada descreve a alteração; o esquema XSD, arquivo que define elementos, tipos e organização do XML, permite conferir a estrutura; as regras de negócio estabelecem condições que não se resumem à existência de uma tag.
Essa distinção apareceu na pesquisa. O catálogo de esquemas consultado listava o pacote 010f, associado a outras alterações. O arquivo baixado tinha o diretório interno PL_010f_v1.04 e cinco XSD. Nenhum deles continha os identificadores dos novos campos líquidos ou do grupo de ICMS previsto. Isso é uma constatação sobre aquele pacote, não uma afirmação de que nenhum outro arquivo possa estar disponível em outra data.
Foi executado um ensaio estrutural isolado: a declaração de prod foi copiada do esquema oficial, com suas dependências preservadas. Um grupo de produtos compatível com esse contrato passou; a inclusão dos novos campos foi recusada pelo validador. O teste não utilizou uma NF-e completa nem realizou transmissão. Ele demonstra por que acrescentar propriedades à classe do documento não atualiza, por si só, o contrato aceito pelo XSD instalado.
Campos líquidos: sequência não significa uma nova tag
No grupo de produtos, a tabela introduz a sequência identificada como I11a, depois de vProd. Ela reúne vUnComLiq, valor líquido unitário, e vProdLiq, valor líquido total do item. O identificador I11a e a indicação de sequência são referências do leiaute; não devem ser transformados em elementos XML inventados.
A sequência aparece com ocorrência 0–1, enquanto cada um de seus dois campos tem ocorrência 1–1 dentro dela. Portanto, o modelo de dados deve tratar o par como uma informação estruturada: quando a sequência for usada, os dois valores precisam estar disponíveis para a geração. A observação de obrigatoriedade futura não elimina essa relação interna.
O unitário vUnComLiq tem formato 11v0–10: até onze posições na parte inteira e de zero a dez casas decimais. O total vProdLiq usa 13v2, com até treze posições na parte inteira e duas casas decimais. A escolha de tipo no banco e na aplicação precisa comportar essa precisão; reduzir tudo ao mesmo tipo monetário de duas casas pode perder informação antes da geração do documento.
Na totalização, vProdLiqTot fica sob total e representa a soma dos líquidos dos itens, também no formato 13v2. Embora sua ocorrência estrutural seja 0–1, há uma regra que exige seu preenchimento quando algum item informa vProdLiq. Este é um exemplo concreto de por que “opcional no leiaute” não significa “dispensável em qualquer operação”.
Mapa de organização previsto no leiaute. A sequência I11a é uma referência documental, sem elemento XML próprio.
ICMS previsto: uma alternativa condicionada à operação
O grupo ICMSPrevistoPagtoAntecip pertence a ICMS, dentro de imposto. Seu filho vICMSPrevisto informa o ICMS que incidirá no fornecimento futuro. O campo usa 13v2 e deve ser informado com zero quando não houver ICMS devido nesse fornecimento, conforme a orientação do leiaute.
A tabela classifica o grupo como CG, grupo exclusivo. Isso significa uma alternativa dentro da estrutura de ICMS, e não um bloco adicional que possa ser acumulado indiscriminadamente com qualquer grupo de tributação. No objeto usado pelo emissor, convém tornar explícita essa escolha para impedir combinações contraditórias antes da serialização.
As condições indicadas são a nota de débito de pagamento antecipado, com tpNFDebito=06, e a compra governamental com recebimento de pagamento e fornecimento posterior, com tpOperGov=4. As validações do grupo são direcionadas à NF-e, modelo 55; informá-lo na NFC-e, modelo 65, gera uma condição de uso indevido prevista na nota.
Também não se deve confundir ausência com zero. Ausência representa um elemento não informado; zero é um valor efetivamente transmitido. A aplicação precisa preservar essa distinção desde o cadastro da operação até o objeto enviado ao gerador. Preencher zero em todos os documentos não resolve a ausência de enquadramento e pode criar um grupo indevido.
Rejeições: confira o gatilho, não apenas o número
Os códigos ajudam a localizar problemas, mas o tratamento depende do modelo, da operação, dos campos presentes e da situação de implantação. Uma mensagem voltada ao suporte deve explicar essas condições e apontar o dado a revisar, em vez de apenas repetir que a nota foi rejeitada.
Para os valores líquidos, as verificações são:
- 1278 — I11c-10: ausência de
vProdLiq. A exigência geral está marcada como implementação futura na versão 1.00. - 1279 — I11c-20: em nota normal, quando o líquido foi informado, sua relação com o unitário e a quantidade deve ser consistente. A regra admite diferença de um centavo para mais ou para menos.
- 1282 — W01a-10: algum item informa
vProdLiq, mas o totalvProdLiqTotnão foi informado. - 1283 — W01a-20: o total líquido informado difere do somatório dos líquidos dos itens.
Para o ICMS previsto, há outros caminhos:
- 1280 — NB01-10: grupo informado em NFC-e, modelo 65.
- 1280 — NB01-20: em NF-e, grupo informado sem que a operação corresponda a
tpNFDebito=06outpOperGov=4. - 1281 — NB01-30: grupo ausente em NF-e enquadrada em uma dessas duas situações. Essa exigência possui cronograma próprio.
Observe que 1280 corresponde a duas regras. Se o registro do emissor guardar apenas o código, o suporte poderá confundir uma restrição de modelo com uma restrição de operação. Guardar o identificador da regra detectada na pré-validação, o modelo e os indicadores relevantes facilita o diagnóstico, sem alterar a resposta recebida do autorizador.
Os códigos representam condições previstas na versão consultada. A ativação deve ser conferida por regra e ambiente.
Alterações que também afetam o código existente
A revisão não termina nos campos novos. A regra B25-80 recebe uma exceção que permite o grupo de ICMS previsto na nota de débito de pagamento antecipado. Uma pré-validação antiga que proíba qualquer informação de ICMS nessa finalidade precisa ser revista para reconhecer a exceção, preservando as demais condições.
A UB16-10, relacionada à composição da base de IBS e CBS, foi removida na versão consultada. O emissor não deve continuar apresentando essa regra como rejeição vigente dessa nota técnica. Remover a regra técnica também não significa dispensar a apuração correta dos tributos segundo a legislação aplicável.
As regras VB01-10 e VB01-20, referentes ao total do item, foram alteradas e permanecem assinaladas como implementação futura. A representação prevista para 2027 incorpora IBS, CBS e Imposto Seletivo em vProd, com a exceção indicada para importação. A adaptação prática é revisar o caminho da totalização e impedir uma nova soma de parcelas já compreendidas no bruto, sem reconstruir aqui a matemática do preço.
Os trechos riscados do PDF merecem leitura visual: uma extração simples de texto pode manter expressões removidas como se ainda estivessem válidas. Na pesquisa deste artigo, as páginas dessas alterações foram renderizadas e conferidas. Esse cuidado evita transformar uma diferença editorial do documento em uma regra implementada incorretamente.
Cronograma: disponibilidade e exigência têm datas diferentes
O comunicado da Coordenação Técnica do ENCAT de 5 de outubro de 2026 adiou o cronograma geral da NT 2026.008 v1.00: homologação em 26 de outubro de 2026 e produção em 16 de novembro de 2026. Essas datas substituem as previsões gerais de 5 de outubro e 3 de novembro da nota. A regra NB01-30, que exige o grupo de ICMS previsto nas operações correspondentes, mantém cronograma próprio na documentação consultada: 1º de fevereiro de 2027 em homologação e 1º de março de 2027 em produção.
Essas datas não tornam obrigatórios todos os campos ao mesmo tempo. A ausência geral de vProdLiq permanece como implementação futura na versão analisada; já o preenchimento de informações aciona verificações de coerência e de total. O planejamento precisa registrar essas diferenças para não antecipar uma exigência nem ignorar uma condição aplicável.
Cronograma geral atualizado pelo comunicado ENCAT de 05/10/2026; conferência em 14/10/2026. Datas gerais, exceções e regras futuras são tratadas separadamente.
Antes da distribuição, registre a versão efetivamente usada pelo componente e os arquivos XSD instalados. A consulta feita em outubro não comprova a situação de um autorizador em novembro. Havendo nova versão do documento ou do pacote, a comparação deve ser refeita antes de ativar a geração dos elementos.
Uma sequência prática para adaptar e testar o emissor
Comece pelo modelo de dados. Acrescente os valores líquidos com precisão adequada, represente o grupo de ICMS previsto como alternativa e diferencie valor não informado de valor zero. Depois revise importações, exportações e cópias de objetos entre módulos, para que os dados não desapareçam entre o faturamento e a emissão.
Na geração do XML, confira nomes, hierarquia e ordem contra o esquema compatível. A linha do leiaute que anuncia uma sequência não autoriza criar um elemento com seu identificador. Para quem usa Delphi e componentes de terceiros, é necessário verificar o suporte efetivo na versão instalada; este artigo não certifica uma versão específica de biblioteca.
A matriz de testes deve cobrir presença e ausência dos dois campos líquidos; total líquido ausente quando um item o informa; somatório divergente; emissão normal e demais finalidades; grupo de ICMS previsto em modelo 65; e, no modelo 55, operações com cada indicador permitido e sem nenhum deles. Inclua o grupo ausente nas situações elegíveis, observando a data própria da exigência.
Nos testes de precisão, examine o XML gravado, e não apenas a tela formatada. Nos testes de estrutura, valide contra o XSD correto. Na homologação, guarde pedido, resposta, versão do emissor, pacote e ambiente. A aprovação em uma dessas etapas não substitui as demais: um ensaio local de grupo, como o realizado nesta pesquisa, tem alcance menor que a autorização de uma nota completa.
Por fim, mantenha uma forma de identificar qual configuração gerou cada documento. Se uma atualização produzir rejeições, essa informação ajuda a localizar uma diferença de schema ou de operação. A liberação deve decorrer das evidências de teste, com orientação clara para o suporte, e não somente da presença de novas propriedades no código.
Conclusão
Implementar a NT 2026.008 exige conectar dados, estrutura XML e regras condicionais. O ponto central é reconhecer que um campo opcional na tabela pode ser exigido por uma condição, que um grupo exclusivo não cabe em qualquer documento e que uma regra publicada pode ter ativação futura.
Para a equipe do emissor, o resultado esperado é uma atualização explicável: versão identificada, esquema compatível, escolhas de grupo consistentes, rejeições diagnosticáveis e testes registrados. A formação do preço permanece em seu próprio fluxo; aqui, o objetivo é transportar e validar corretamente as informações fiscais, respeitando o alcance do que foi efetivamente conferido.
Referências
COORDENAÇÃO TÉCNICA DO ENCAT; SVRS. Comunicado de 5 de outubro de 2026: alteração de datas de homologação e produção de notas técnicas. Portal da Nota Fiscal Eletrônica, 2026. Disponível em: https://dfe-portal.svrs.rs.gov.br/NFe/Avisos/3008. Acesso em: 14 out. 2026.
PORTAL DA NOTA FISCAL ELETRÔNICA. Documentos vigentes: notas técnicas. Portal da Nota Fiscal Eletrônica, [s. d.]. Disponível em: https://www.nfe.fazenda.gov.br/portal/listaConteudo.aspx?tipoConteudo=6WfrpZYE4Ik%3D. Acesso em: 14 out. 2026.
PORTAL DA NOTA FISCAL ELETRÔNICA. Esquemas XML. Portal da Nota Fiscal Eletrônica, [s. d.]. Disponível em: https://www.nfe.fazenda.gov.br/portal/listaConteudo.aspx?tipoConteudo=BMPFMBoln3w%3D. Acesso em: 14 out. 2026.
PORTAL DA NOTA FISCAL ELETRÔNICA. Manual de Orientação do Contribuinte: visão geral. Versão 7.00. Portal da Nota Fiscal Eletrônica, nov. 2020. Disponível em: https://www.nfe.fazenda.gov.br/portal/exibirArquivo.aspx?conteudo=LrBx7WT9PuA%3D. Acesso em: 14 out. 2026.
PORTAL DA NOTA FISCAL ELETRÔNICA. Reforma Tributária do Consumo: valor líquido do produto. Nota Técnica 2026.008, versão 1.00. Portal da Nota Fiscal Eletrônica, set. 2026. Disponível em: https://www.nfe.fazenda.gov.br/portal/exibirArquivo.aspx?conteudo=qAoMot6VyiY%3D. Acesso em: 14 out. 2026.
PORTAL DA NOTA FISCAL ELETRÔNICA. Schemas XML NF-e: pacote de liberação nº 010f. NT 2025.002 v.1.50 e NT 2026.007 v.1.00. Portal da Nota Fiscal Eletrônica, 31 ago. 2026. 1 arquivo ZIP. Disponível em: https://www.nfe.fazenda.gov.br/portal/exibirArquivo.aspx?conteudo=8ITFuBLltXs%3D. Acesso em: 14 out. 2026.
0 comentário(s)