Plano de homologação das rejeições Protheus publicadas em setembro de 2026: Guia técnico completo

Introdução

Plano de homologação das rejeições Protheus publicadas em setembro de 2026 integra o novo lote de tratamentos da Reforma Tributária publicado pela TOTVS em setembro de 2026. O foco aqui é explicar a regra, a causa e a solução do início ao fim.

O que a TOTVS documenta

• Entre 9 e 11/09/2026 a seção oficial recebeu um novo bloco de tratamentos RTC.
• O lote cobre finalidade, cClassTrib, diferimento, alíquotas, crédito presumido, estorno, ZFM/ALC e referências por item.
• Nem toda rejeição é falha do Protheus: a 1193 pode exigir acionamento da SEFAZ quando o XML está conforme.

Solução principal

Adicionar os códigos à suíte de regressão Protheus/TSS e classificar cada falha.

Priorização sugerida

P1: 1023, 1029, 1031, 1036, 1040, 1069. P2: referências por item. P3: finalidade, crédito presumido, estorno e ZFM/ALC.

Guia técnico

Registre finalidade, CST, cClassTrib, participantes, regras do FISA170 e XML. Confirme enquadramento, cálculo/escrituração, geração no TSS e validação da SEFAZ.

Solução central: Adicionar os códigos à suíte de regressão Protheus/TSS e classificar cada falha..

Fluxo de investigação

Cadastro/classificação → Perfis/contexto → FISA170 → cálculo/escrituração → TSS/XML → SEFAZ.

Checklist

• preservar XML original;
• identificar item;
• conferir artigo TOTVS;
• revisar release e TSS;
• confirmar CST/cClassTrib;
• revisar FISA170;
• fazer cálculo manual quando houver fórmula;
• conferir origem quando houver DFeReferenciado;
• regerar XML;
• homologar e arquivar evidência.

Evite atalhos

Não faça UPDATE em F2D, CJ3, DKN ou tabelas fiscais. Não remova tags manualmente. Não troque cClassTrib ou benefício apenas para autorizar.

Revisão independente

Refaça o cálculo em planilha quando houver fórmula, ou monte tabela com chave/item/participantes quando o problema for referenciamento. Compare antes e depois da correção.

Monitoramento pós-produção

Acompanhe reincidência, novas rejeições relacionadas, diferenças por filial e comportamento do TSS. Uma correção só está estabilizada quando não cria efeitos colaterais.

Conclusão

A correção segura acontece na origem: classificação, regra, cálculo, referência ou atualização. Depois, gere novo XML, valide em homologação e documente o resultado.

Conteúdo técnico baseado em documentação oficial TOTVS publicada entre 9 e 11/09/2026. Tratamentos fiscais e classificações devem ser confirmados pela área Fiscal/Contábil.

Validação funcional antes da produção

Antes de liberar a correção, compare o comportamento do Protheus com uma memória independente. Quando a rejeição envolver cálculo, reproduza a conta em planilha com base, alíquota, redução, diferimento, devolução e arredondamento explícitos. Quando envolver referenciamento, monte uma tabela com chave de origem, item, CNPJ/CPF do emitente e destinatário. Quando envolver classificação, registre CST, cClassTrib e a versão da tabela usada.

A validação deve responder três perguntas: a regra correta foi escolhida? o valor/grupo gerado está correto? o XML representa fielmente o resultado interno?. Se qualquer uma delas ficar sem resposta, a autorização da nota não deve ser usada como única evidência de que o problema foi resolvido.

Evidências para suporte e auditoria

Um pacote de evidências útil pode conter:

01_xml_rejeitado.xml

02_retorno_sefaz.txt

03_print_regra_cfgtrib.png

04_memoria_calculo.xlsx

05_release_build_tss.txt

06_xml_corrigido.xml

07_retorno_autorizado.txt

Se a ocorrência envolver DFeReferenciado, acrescente a chave da nota de origem, item de origem e participantes envolvidos. Se envolver F2D/CJ3, use consultas apenas de leitura e anexe a evidência correspondente. Se o artigo oficial indicar possível problema no autorizador, guarde também o resultado do validador nacional ou de outro ambiente comparável.

Teste negativo obrigatório

Além do cenário corrigido, execute um caso semelhante que não deve usar a mesma regra. Essa etapa é essencial para evitar parametrizações amplas demais. Uma correção que faz a nota rejeitada autorizar, mas passa a aplicar diferimento, crédito presumido ou classificação a operações indevidas, não está concluída.

Exemplos de teste negativo:

• outro CST sem direito ao mesmo grupo;
• cClassTrib diferente;
• participante ou UF diferente;
• nota sem vínculo de origem;
• benefício fiscal fora da área incentivada;
• documento de finalidade diferente.

Política de atualização

Rejeições da Reforma Tributária mudam rapidamente com novas versões de Nota Técnica, patches, fontes e TSS. Portanto, associe cada solução à data do artigo TOTVS, release testada e versão do ambiente. Evite registrar a solução apenas como “ajustar campo X”.

Após atualização de Protheus, TSS ou pacote fiscal, repita pelo menos os cenários mais críticos. Essa rotina de regressão transforma a coleção de artigos em uma base operacional para sustentação e não apenas em material de consulta.

Critério de encerramento do incidente

Considere a rejeição encerrada somente quando houver:

• causa identificada;
• correção aplicada na origem;
• XML novo gerado;
• homologação concluída;
• cenário negativo executado;
• evidência arquivada;
• responsável Fiscal/Contábil de acordo, quando aplicável.

Esse critério reduz reincidência e evita soluções improvisadas.