Migração para NFS-e Nacional: plano de homologação de setembro e outubro para usuários Protheus

Introdução

Migração para NFS-e Nacional: plano de homologação de setembro e outubro para usuários Protheus é uma pauta diretamente ligada às mudanças publicadas ou colocadas em produção em agosto de 2026. Para evitar um problema comum em conteúdos sobre Reforma Tributária — transformar expectativa em funcionalidade já disponível — este artigo separa claramente três coisas: o fato oficial de agosto, o que a TOTVS efetivamente documenta para o Protheus e as ações de preparação que a empresa pode executar sem inventar parametrizações.

O foco prático deste artigo é plano de migração antes de novembro. A data de corte da pesquisa é 2026-09-01. Isso é relevante porque layouts, notas técnicas, atos conjuntos e documentação do Protheus podem receber revisões posteriores.

O que mudou em agosto de 2026

A fonte oficial usada como base registra os seguintes pontos:

• A Resolução CGSN nº 191/2026 tornou obrigatória a NFS-e de padrão nacional para ME e EPP optantes do Simples a partir de 1º de novembro de 2026.
• A emissão deverá ocorrer pelo Emissor Nacional, por aplicação web ou integração via API.
• A Receita esclareceu que as regras de CBS e IBS para optantes do Simples passam a produzir efeitos a partir de 1º de janeiro de 2027.

O primeiro cuidado é interpretar a mudança no seu alcance exato. Uma regra de validação de documento, por exemplo, não deve ser confundida com uma regra de apuração. Um cronograma de NFS-e não significa automaticamente que todos os municípios usam o mesmo fluxo. Uma nova API pública também não prova que o ERP possua integração nativa com ela. Essa distinção evita projetos baseados em premissas não confirmadas.

O que a TOTVS documenta para o Protheus

Na documentação oficial da TOTVS consultada para este tema, foram confirmados os seguintes elementos:

• Em atualização datada de 11 de agosto de 2026, a TOTVS orienta aplicar o último pacote de Expedição Contínua do Protheus para municípios aderentes ao emissor nacional.
• A documentação também orienta manter o RPO do TSS, schemas, URLs e configuração NEWNFSE atualizados nos ambientes que exigem manutenção local.
• A TOTVS indica configuração da NFS-e Nacional pela rotina FISA022 e referencia a documentação de IBS/CBS no XML.

Neste tema há documentação TOTVS diretamente ligada ao processo de NFS-e Nacional no Backoffice Protheus/TSS, o que permite citar os procedimentos oficialmente documentados. Mesmo assim, a release e o ambiente do cliente devem ser conferidos antes de qualquer aplicação.

Esse método é importante porque o Protheus possui diferentes releases, pacotes de Expedição Contínua, TSS local ou compartilhado, customizações ADVPL e integrações próprias de cada cliente. O procedimento correto precisa ser compatível com o ambiente realmente instalado.

Impacto prático no processo

A pergunta mais útil não é apenas “o sistema está atualizado?”, mas “qual processo de negócio pode mudar ou falhar por causa desta atualização?”. No contexto do módulo TSS / NFS-e, a análise deve começar pelo fluxo completo: origem do dado, cadastro, cálculo ou regra de negócio, geração do documento ou integração, retorno externo e reflexo fiscal/financeiro.

Em agosto de 2026, várias mudanças atingiram justamente as fronteiras entre ERP e plataformas governamentais. Isso aumenta a importância de validar formatos, datas de vigência, credenciais, schemas, códigos de classificação e comportamento de exceções. Um ambiente pode continuar transmitindo documentos e, ainda assim, estar produzindo informação incompleta ou inconsistente.

Também é necessário mapear customizações. Qualquer fonte ADVPL, middleware, ETL, robô, API própria ou validação em banco que trate CNPJ, XML, CST, classificação tributária, data de emissão, regime do Simples ou autenticação externa deve entrar na matriz de impacto. O fato de o núcleo padrão do Protheus estar preparado não garante que uma customização antiga aceite o novo cenário.

Ações recomendadas no Protheus

Para esta pauta, uma sequência segura de trabalho é:

1. Confirmar adesão do município ao padrão nacional.
2. Atualizar protheus/tss conforme a documentação oficial.
3. Testar emissão, consulta e substituição em homologação.

Além dessas ações, registre a release do Protheus, a versão do TSS quando aplicável, a data do último pacote de Expedição Contínua e os responsáveis técnico e funcional pelo teste. Se a documentação TOTVS indicar um procedimento específico, siga exatamente essa fonte; se não indicar, abra a análise como pendência de produto em vez de criar uma solução por tentativa e erro.

Roteiro de homologação

Monte pelo menos quatro cenários. O primeiro deve reproduzir a operação mais comum. O segundo deve usar uma situação de borda — por exemplo, regime diferente, documento substituído, CNPJ alfanumérico, ausência de determinada informação ou API indisponível, conforme o tema. O terceiro deve exercitar cancelamento, estorno ou reprocessamento quando esses eventos existirem. O quarto deve conferir o reflexo nos módulos integrados.

Em cada cenário, guarde evidências do dado de entrada, configuração aplicada, XML ou payload transmitido, retorno do serviço externo, documento gerado e reflexo no Protheus. Essa documentação transforma a homologação em prova de aderência, e não em uma percepção de que “funcionou”.

Quando houver mudança de schema ou nota técnica, valide também o comportamento de rejeição. Quando houver flexibilização de validações, faça o teste inverso: confirme se o sistema ainda consegue produzir corretamente os campos, mesmo que o autorizador não rejeite sua ausência. Quando houver nova regra do Simples, não altere o ERP antes de a área tributária definir o enquadramento aplicável à empresa.

Pontos de atenção para Fiscal e TI

A área Fiscal deve ser dona da interpretação tributária e da memória de cálculo. TI deve ser responsável pela integridade da implementação, atualização de componentes, rastreabilidade e observabilidade. Essa divisão reduz o risco de um analista técnico decidir sozinho um enquadramento fiscal ou de a área fiscal solicitar um ajuste incompatível com a arquitetura do produto.

Outro cuidado é a gestão de vigência. Agosto trouxe regras com efeitos em datas diferentes: algumas imediatamente, outras em novembro de 2026, janeiro de 2027 ou até com prazo temporário até 2028. O ERP deve refletir a vigência correta, e a documentação interna precisa registrar quando a regra começa, termina ou deve ser revista.

Para temas governamentais ainda sem página TOTVS específica, a ação responsável é acompanhar a Central de Atendimento, TDN, Espaço Legislação e Central de Download. Não é adequado inventar nomes de patches, parâmetros, tabelas ou rotinas com base apenas no texto legal.

Indicadores que ajudam no acompanhamento

Uma equipe madura pode acompanhar a implantação com indicadores simples: percentual de cenários homologados, quantidade de rejeições por tipo, volume de documentos com divergência de IBS/CBS, incidentes após atualização, integrações ainda não adaptadas, customizações impactadas e prazo médio para corrigir inconsistências.

Nos assuntos de conformidade, também vale medir quantos documentos foram reprocessados, quantas divergências foram identificadas por conciliação e quantas pendências possuem responsável e prazo. Esses indicadores ajudam a transformar a Reforma Tributária em um programa gerenciável, em vez de uma sucessão de correções emergenciais.

Conclusão

Migração para NFS-e Nacional: plano de homologação de setembro e outubro para usuários Protheus mostra por que agosto de 2026 foi um mês de forte movimentação para equipes fiscais e de ERP. A resposta adequada não é simplesmente ativar novos campos, mas entender o alcance da norma, confrontar a documentação da TOTVS, homologar o processo de ponta a ponta e manter evidências.

Quando a TOTVS documenta uma funcionalidade específica, use essa documentação como referência principal para o produto. Quando a novidade existe apenas no canal governamental, trate o impacto no Protheus como uma análise a validar. Essa postura conserva a qualidade técnica do ambiente e evita que uma interpretação não confirmada seja transformada em configuração de produção.