CFGTRIB Master — Venda híbrida cClassTrib 000001: Impacto em código e customizações

Introdução

Venda híbrida cClassTrib 000001 faz parte do conjunto mais avançado de temas do Configurador de Tributos do TOTVS Protheus. Este artigo foi construído com base na documentação oficial “Como calcular IBS/CBS cClassTrib 000001 na venda Híbrida?”, publicada em 2025-12-04, e consultada em 2026-09-01. O recorte é impacto em código e customizações, com foco em identificar quando código é necessário e quando não deve ser inventado.

Neste lote final, os exemplos foram tratados com rigor adicional. Um exemplo numérico publicado pela TOTVS é identificado como oficial; uma conta criada apenas para explicar o raciocínio é identificada como didática; e trechos como operandos, parâmetros e campos são apresentados como configuração documentada. O objetivo é impedir que um exemplo técnico seja confundido com regra tributária universal.

O que a TOTVS confirma

• A TOTVS documenta cenário híbrido no qual os tributos legados permanecem no fluxo tradicional e IBS/CBS são tratados no CFGTRIB.
• A Regra de Escrituração é criada após a importação da tabela cClassTrib.
• O exemplo demonstra registros de IBS/CBS em CJ3 e F2D.

Esses são os fatos que sustentam o artigo. Qualquer classificação, alíquota, NCM, benefício, vigência ou tratamento fiscal real deve ser confirmado pela área responsável da empresa.

Exemplo de valor prático

Tipo de exemplo: CALC.

Exemplo didático baseado no cenário oficial: mercadoria R$ 1.000, base IBS/CBS determinada pela fórmula da operação e alíquotas de teste apenas para homologação. O artigo não presume que os percentuais do exemplo sejam os da empresa.

O exemplo deve ser reproduzido primeiro em homologação. Se envolver valores, monte uma memória de cálculo independente. Se envolver configuração, registre o estado anterior e o posterior. Se envolver campo ou operando, confirme sua existência na release utilizada.

Quando usar código

Código só deve entrar quando a necessidade não é atendida pela configuração padrão ou quando a TOTVS fornece uma rotina automática/documentação específica. Não invente assinatura de ExecAuto, campo ou parâmetro.

Antes de customizar, pergunte: há operando padrão? há Regra de Fórmula? há Facilitador? há ExecAuto documentado? há integração já prevista? Quanto mais lógica fiscal permanecer no motor configurável, menor o custo futuro de manutenção.

Arquitetura do processo

Uma análise confiável separa o cenário em oito camadas:

1. Requisito fiscal: o que a legislação e a área Fiscal determinam.
2. Dados mestres: produto, participante, NCM, serviço, UF, classificação e vigência.
3. Enquadramento: perfis, Tipo de Operação e demais critérios.
4. Cálculo: base, alíquota, fórmula e dependências.
5. Escrituração: CST, cClassTrib, cBenef, incidência e totalização.
6. Persistência: registros como F2D/CJ3 quando usados pelo cenário.
7. Documento ou integração: NF-e, CT-e, Financeiro, SIGAEIC etc.
8. Evidência: logs, XML, memória de cálculo e aprovação.

Essa arquitetura evita a prática perigosa de ajustar apenas o valor final.

Cenário prático de risco

A equipe copia uma configuração de exemplo e o cálculo fecha, mas a classificação não foi aprovada pelo Fiscal. A correção não é técnica: é voltar à premissa, documentar a decisão e só então homologar.

O ponto central é que o CFGTRIB não pode ser sustentado por conhecimento informal. O cenário precisa ser compreensível e reproduzível por outra pessoa.

Memória de cálculo

Quando houver cálculo, mantenha uma memória com:

• valor da mercadoria/serviço;
• acréscimos;
• descontos;
• tributos que compõem a base;
• tributos excluídos;
• base final;
• alíquota;
• arredondamento;
• valor final;
• regra e classificação aplicadas.

A memória deve usar os mesmos dados do documento de homologação. Assim, uma diferença pode ser localizada por etapa.

Fórmulas do CFGTRIB

Fórmulas devem ser tratadas como lógica fiscal versionada. Operandros como O:VAL_MERCADORIA, O:ZERO, O:BASE_INTEGRACAO e O:ALIQUOTA_INTEGRACAO aparecem em cenários oficiais distintos. Regras de Tributo também podem ser consultadas para compor outras bases.

Não substitua um operando padrão por customização sem necessidade. A configuração nativa tende a ser mais fácil de atualizar e auditar.

Código e automação

Nem todo tema precisa de código. Quando a TOTVS oferece ExecAuto, como FISA164 ou FISA166, use a documentação específica da rotina para montar os parâmetros. Este lote deliberadamente não inventa arrays ou assinaturas que não estejam disponíveis na fonte consultada.

Para auditoria, consultas próprias devem ser somente leitura. Se precisar automatizar relatórios, confirme campos no dicionário e encapsule a consulta de forma que a mudança de release possa ser detectada.

CJ3 e F2D

Nos cenários de IBS/CBS, a TOTVS documenta CJ3 e F2D como estruturas relevantes. Use-as para responder perguntas diferentes: o que foi calculado? e como foi escriturado?

Uma divergência entre elas é sinal para investigar regra, classificação e geração do documento. Não é autorização para editar os registros manualmente.

XML e autorizadores

NF-e e CT-e adicionam uma camada externa. Validação de schema, rejeição e autorização precisam ser registradas, mas não substituem a decisão Fiscal.

Em uma homologação completa, compare memória de cálculo → Protheus → CJ3/F2D → XML → retorno do autorizador. Esse encadeamento é muito mais confiável do que validar somente a tela da rotina.

Financeiro

Regras Financeiras possuem componentes próprios: título, cálculo, vencimento, retenção, cumulatividade e vigência. Quando um cenário passa pelo Financeiro, inclua esses componentes no teste.

Evite parametrização tributária duplicada em cadastros básicos e Regra Financeira quando a documentação do cenário orienta centralizar o tratamento no novo mecanismo.

Importação

No SIGAEIC, a lógica é diferente: determinados tributos já são calculados no módulo de importação e o CFGTRIB os recebe por Operandos de Integração. Nesse caso, o teste deve provar identidade de valor entre origem e destino, e não refazer o cálculo no Configurador.

Essa distinção é importante para customizações: um código antigo que recalcula o tributo pode se tornar incorreto quando a arquitetura passa a integrar valores prontos.

Migração TES → CFGTRIB

A TOTVS documenta que parte dos campos da TES permanece por função de integração, mesmo com a migração do motor fiscal. Portanto, “migrar o tributo” não significa eliminar a TES indiscriminadamente.

Crie uma matriz de dependências antes de desativar campos ou customizações. Para cada campo, identifique módulo consumidor, função operacional e substituição prevista.

Performance e manutenção em massa

Recursos como MV_FACAUTO, Facilitador, FISA164 e FISA166 podem reduzir trabalho manual, mas ampliam a importância da governança. Inserção em massa de produto ou participante em perfil errado produz erro em escala.

Depois de qualquer manutenção em massa, faça amostragem de registros de diferentes categorias e valide operações reais.

Troubleshooting por camada

Quando surgir erro, siga esta ordem:

1. ambiente/release;
2. consistência estrutural;
3. dados mestres;
4. perfis;
5. classificação;
6. base e alíquota;
7. fórmula/dependências;
8. escrituração;
9. integração/documento;
10. customização.

Essa ordem evita culpar o CFGTRIB por uma falha de cadastro ou, inversamente, procurar no cadastro um problema de integração.

Casos de teste obrigatórios

Para Venda híbrida cClassTrib 000001, mantenha pelo menos:

• cenário principal;
• cenário que não deve enquadrar;
• valor zero ou isento quando fizer sentido;
• operação com arredondamento;
• devolução/cancelamento quando existir;
• participante ou produto de perfil alternativo;
• filial/UF alternativa;
• reprocessamento;
• comparação após atualização;
• validação de integração posterior.

Indicadores

Acompanhe mensalmente:

• regras sem responsável;
• classificações vencidas/desatualizadas;
• documentos com rejeição;
• regras concorrentes;
• divergências CJ3 × F2D;
• cenários híbridos pendentes;
• customizações que recalculam tributos;
• falhas de integração;
• tempo para corrigir incidente;
• percentual de regressão executada.

O que evitar

• copiar código de exemplo como padrão da empresa;
• usar alíquota demonstrativa em produção;
• inventar parâmetro ou tabela;
• alterar F2D/CJ3 diretamente;
• customizar antes de pesquisar operandos nativos;
• usar ExecAuto sem documentação da rotina;
• considerar XML autorizado como única evidência;
• migrar TES sem mapear integrações;
• ampliar perfil para “fazer calcular” sem análise;
• aprovar regra sem memória de cálculo.

Conclusão

Venda híbrida cClassTrib 000001 mostra por que o CFGTRIB precisa ser tratado como uma plataforma fiscal governada. A flexibilidade do motor só produz segurança quando a empresa consegue explicar de onde o dado veio, qual regra o transformou, onde foi persistido e como chegou ao documento ou módulo seguinte.

Para identificar quando código é necessário e quando não deve ser inventado, use exemplos oficiais como laboratório, não como atalho. A combinação ideal é: documentação TOTVS para o comportamento do produto, área Fiscal para a decisão tributária, memória de cálculo para a matemática e homologação para provar que tudo funciona em conjunto.

Validação independente do exemplo

Antes de considerar o exemplo de Venda híbrida cClassTrib 000001 aprovado, refaça o cenário fora do Protheus. Para cálculos, use uma planilha simples com valores de entrada, operações matemáticas, casas decimais e arredondamento explícitos. Para configurações, documente cada campo alterado, valor anterior, valor novo e fonte oficial que justificou a mudança. Para operandos ou parâmetros, registre a tela e a release em que foram validados.

O objetivo dessa validação independente é criar uma referência que não dependa da própria rotina testada. Se o Protheus e a planilha divergem, a equipe consegue isolar se a diferença está na base, alíquota, fórmula, arredondamento ou enquadramento. Se a divergência ocorre apenas no XML, a investigação avança para escrituração e geração do documento.

Critério de comparação

Use uma tabela de evidência com cinco colunas:

Essa estrutura é simples, mas evita homologações baseadas apenas em observação visual.

Configuração segura em ambientes reais

Nunca faça a primeira configuração em produção. Crie um cenário controlado em homologação com produto, participante e operação conhecidos. Quando o tema depender de UF, NCM, CFOP, serviço ou classificação, escolha dados que permitam provar claramente o enquadramento.

Depois da configuração, teste também o não enquadramento. Por exemplo, altere o participante, produto, UF ou Tipo de Operação para uma condição que não deveria usar a regra. Se a regra continuar sendo aplicada, o perfil pode estar amplo demais.

Em ambientes com múltiplas filiais, repita o teste em pelo menos uma filial de contexto diferente. Isso é especialmente importante para ICMS, DIFAL, FECP, benefícios e operações de importação.

Segurança para código e customizações

Quando código for necessário, adote três controles mínimos. Primeiro, valide se existe rotina automática ou operando padrão documentado. Segundo, encapsule a customização para que ela possa ser desativada durante testes do padrão. Terceiro, registre quais campos, tabelas ou funções oficiais ela consome.

Não grave diretamente em F2D, CJ3, F2B ou outras tabelas do CFGTRIB para “corrigir” imposto. Esse tipo de intervenção remove rastreabilidade e pode gerar inconsistência em processos posteriores. O código deve acionar interfaces suportadas ou atuar em pontos de extensão documentados.

Para ExecAuto, use exatamente a assinatura e os arrays publicados pela TOTVS para a release. Se a Central apenas informa que uma rotina possui ExecAuto e remete ao TDN, o artigo deve parar nesse ponto até que a documentação específica seja consultada.

Roteiro de revisão após atualização

Após aplicar pacote fiscal, Expedição Contínua, atualização de dicionário ou mudança de release:

1. confira se os campos e operandos continuam disponíveis;
2. execute os principais cálculos de referência;
3. teste pelo menos uma exceção;
4. compare CJ3/F2D quando aplicável;
5. gere o documento eletrônico;
6. revise regras financeiras ou integrações;
7. valide customizações;
8. documente diferenças;
9. reprove a mudança se houver resultado não explicado;
10. atualize a evidência da regra somente depois da aprovação.

Essa disciplina transforma o lote de exemplos em uma base de conhecimento reutilizável para implantação e sustentação.