Simulador Comparativo: Erros que impedem o funcionamento no TOTVS Protheus

Introdução

O Simulador Comparativo é um dos pilares para compreender o Configurador de Tributos do TOTVS Protheus. A documentação oficial mostra que o CFGTRIB foi concebido para separar elementos fiscais em componentes configuráveis: perfis, base, alíquota, regras, escrituração, fórmulas, apuração e outros elementos podem participar de uma mesma solução fiscal.

Este artigo aborda o assunto como erros que impedem o funcionamento, com foco em mostrar onde configurações incoerentes costumam quebrar o fluxo. O público principal é formado por suporte e key users. A proposta é extrair valor prático da documentação sem inventar parâmetros, tabelas ou comportamentos que não estejam confirmados.

O que a TOTVS confirma

As fontes oficiais consultadas sustentam os seguintes pontos:

• O Simulador Comparativo permite selecionar uma operação já realizada no sistema e simular novamente usando seu contexto.
• A TOTVS indica o recurso para comparar tributos da operação original com os resultados simulados.
• A comparação pode auxiliar na identificação de inconsistências tributárias e ajuste de cenários.
• Quando a nota é calculada pelo CFGTRIB, o Protheus gera um IDTRIB em D1_IDTRIB, D2_IDTRIB e FT_IDTRIB.
• O artigo afirma que o Configurador de Tributos é a primeira fonte de definição do cálculo fiscal.
• Somente quando os perfis de Produto, Participante, Operação e Origem/Destino não enquadram a nota é que o sistema recorre aos cadastros tradicionais.
• SF3, SF1, SF2, SC5 e SC6 não armazenam identificação relacionada ao IDTRIB, conforme o artigo.

Esses fatos funcionam como limite técnico do artigo. Recomendações de implantação, governança e auditoria apresentadas a seguir são boas práticas derivadas desses fatos e devem ser ajustadas à realidade da empresa.

Por que esse tema importa no CFGTRIB

O objetivo central deste recorte é comparar operações já realizadas com uma nova simulação para investigar diferenças tributárias. No Configurador de Tributos, pequenas diferenças de contexto podem mudar completamente o enquadramento. Um produto pode estar no perfil correto, mas o participante não; o CFOP pode estar correto, mas o tipo de operação não; uma regra pode estar tecnicamente cadastrada, mas não estar disponível para operações reais.

Por isso, o CFGTRIB deve ser administrado como um motor de decisão fiscal. O valor calculado é apenas o resultado final de uma cadeia anterior de validações. A equipe precisa conseguir explicar qual regra foi aplicada, por que ela foi escolhida e quais dados levaram ao enquadramento.

Modelo mental recomendado

Uma forma útil de estudar o CFGTRIB é separar o processo em camadas:

1. Contexto da operação — empresa, filial, entrada ou saída, documento e processo de origem.
2. Enquadramento — perfis que descrevem produto, participante, operação e origem/destino.
3. Regra tributária — ligação entre o contexto enquadrado e as definições do tributo.
4. Cálculo — base, alíquota, fórmulas e dependências aplicáveis.
5. Escrituração — forma como o tributo será representado fiscalmente e, quando aplicável, no total do documento.
6. Persistência e rastreabilidade — registros gerados nas tabelas do motor e nas tabelas do documento.
7. Apuração e integrações posteriores — processos que consomem os resultados produzidos.

Essa separação evita o erro de tratar toda divergência como “problema de fórmula”. Muitas falhas estão antes do cálculo, principalmente em perfis, cadastros, status ou vigência; outras surgem depois, na escrituração ou nos processos consumidores.

Erros que impedem o funcionamento: abordagem prática

Para mostrar onde configurações incoerentes costumam quebrar o fluxo, comece construindo uma matriz de controle. Cada item relevante deve conter: objetivo, fonte TOTVS, release testada, perfis envolvidos, regra, responsável funcional, evidência de simulação, evidência de documento real e resultado da conferência.

Não permita que uma regra entre em produção apenas porque o valor ficou igual ao esperado em um único exemplo. O teste deve comprovar o enquadramento e a rastreabilidade. Quando possível, compare uma operação histórica com uma nova simulação; depois confirme em documento real de homologação.

Sequência recomendada

1. Registrar a fonte oficial utilizada.
2. Identificar a release e os pacotes instalados.
3. Mapear os perfis que deveriam enquadrar a operação.
4. Conferir a regra e seus componentes.
5. Executar simulação controlada.
6. Validar a origem do cálculo.
7. Conferir item, escrituração e registros gerados.
8. Executar cenário de exceção.
9. Documentar a aprovação funcional.
10. Manter plano de revisão após atualizações do ambiente.

Cenário prático

A equipe encontra diferença entre o imposto visível no documento e a escrituração. Em vez de alterar a fórmula imediatamente, o diagnóstico deve seguir a origem do cálculo, o IDTRIB, a regra aplicada, a Regra de Escrituração e os registros relacionados.

O valor desse exercício é mostrar que o diagnóstico precisa seguir a cadeia de decisão do CFGTRIB. Alterar a primeira configuração visível pode mascarar a causa real e criar efeitos colaterais em outras operações.

Auditoria e evidências

A documentação oficial de rastreabilidade torna possível distinguir cálculo realizado pelo CFGTRIB de cálculo oriundo dos cadastros tradicionais. Essa informação deve fazer parte da homologação. Para operações críticas, guarde o identificador do tributo, o código da regra, o documento de origem e os registros de escrituração relacionados.

Uma boa evidência de teste deve permitir que outra pessoa reproduza a conclusão. Isso inclui empresa e filial, operação, produto, participante, CFOP, regra esperada, resultado obtido e data. Capturas de tela isoladas são úteis, mas ganham muito mais valor quando acompanhadas de uma descrição do cenário.

Governança de mudanças

O Configurador concentra lógica fiscal. Consequentemente, alterações devem seguir controle semelhante ao de mudanças de software: solicitação, justificativa, homologação, aprovação, implantação e revisão posterior.

O mecanismo de status documentado pela TOTVS reforça essa visão. Há, porém, uma divergência entre artigos oficiais sobre a representação numérica do status. A página específica do mecanismo de aprovação documenta 1 = Em Teste e 2 = Aprovada, enquanto outro artigo apresenta a ordem inversa. Portanto, qualquer automação que leia diretamente o valor deve ser validada contra o dicionário e a documentação específica da release antes de ser utilizada.

Impacto de cadastros e perfis

Perfis são dados fiscais estruturantes. Uma regra excelente pode nunca ser aplicada se o enquadramento não ocorrer. Da mesma forma, um perfil excessivamente amplo pode aplicar uma regra a operações que não deveriam recebê-la.

Para produtos, participantes e operações, mantenha critérios de inclusão documentados. Quando usar recursos de manutenção em massa, como o Facilitador, execute amostragem depois da inclusão e valide se os registros inseridos realmente pertencem ao mesmo tratamento fiscal.

Filiais e compartilhamento

Em ambientes com múltiplas filiais, não assuma que compartilhar tabelas sempre simplifica a operação. A TOTVS orienta considerar regimes tributários e particularidades regionais antes da decisão. A governança deve responder: quais regras são corporativas, quais são estaduais ou municipais, quais dependem da filial e quem aprova alterações.

Uma matriz de compartilhamento bem documentada evita dois problemas: duplicação desnecessária de regras e propagação indevida de uma configuração específica.

Uso dos simuladores

O Simulador de Operações é adequado para testar cenários construídos pela equipe. Já o Simulador Comparativo utiliza o contexto de uma operação que ocorreu no sistema, permitindo confronto entre original e simulação.

Em uma implantação, os dois recursos se complementam. O primeiro ajuda a testar condições planejadas; o segundo é especialmente útil para comparar o novo desenho tributário com operações históricas. Nenhum deles elimina a necessidade de validar documentos reais em homologação.

Riscos e erros que devem ser evitados

• concluir que o CFGTRIB calculou apenas porque o valor ficou correto;
• ignorar a origem do cálculo e o IDTRIB;
• aprovar regra sem testar perfis de enquadramento;
• alterar tabelas diretamente para “corrigir” resultado;
• compartilhar regras entre filiais sem análise fiscal;
• usar manutenção em massa sem revisão;
• confundir cálculo com escrituração;
• presumir que F2B_REGRA aparece em qualquer tabela tradicional;
• aplicar orientação de uma release em outra sem validação;
• manter regra sem documentação de vigência, motivo e responsável.

Checklist de qualidade

Antes de considerar o tema estabilizado, confirme:

• a documentação oficial aplicável foi identificada;
• a release do ambiente é compatível;
• os perfis foram revisados;
• a regra correta foi selecionada;
• a simulação produziu o resultado esperado;
• a origem do cálculo foi comprovada;
• a escrituração foi conferida;
• registros e identificadores estão rastreáveis;
• cenários de exceção foram testados;
• a área fiscal aprovou a conclusão.

Conclusão

Simulador Comparativo não deve ser estudado isoladamente. O CFGTRIB funciona como uma cadeia de decisões e registros. Quanto melhor a empresa documenta enquadramento, regra, simulação, origem do cálculo e escrituração, menor é a dependência de conhecimento informal e mais rápido se torna o diagnóstico.

Para suporte e key users, a principal recomendação é transformar o Configurador em um processo governado: fonte oficial, regra documentada, teste reproduzível, aprovação formal e evidência rastreável. Isso cria uma base segura para os cenários mais complexos que serão aprofundados nos próximos lotes.