CFGTRIB avançado — Validação do XML de IBS/CBS: Troubleshooting passo a passo

Introdução

Validação do XML de IBS/CBS é um dos tópicos avançados do Configurador de Tributos do TOTVS Protheus. Neste artigo, o assunto é tratado como troubleshooting passo a passo, com foco em diagnosticar falhas pela cadeia de dados e regras. A base factual vem exclusivamente da documentação oficial da TOTVS consultada até 2026-09-01.

O objetivo prático é usar validadores técnicos sem confundir validação de schema com conformidade fiscal. Sempre que a TOTVS apresenta códigos, alíquotas, NCMs, classificações ou valores em seus exemplos, eles são tratados aqui como demonstração técnica do produto. A decisão fiscal real deve ser validada para a empresa, operação, UF, regime e vigência correspondentes.

O que a TOTVS documenta

• A TOTVS mantém documentação de adequação da NF-e às versões da Nota Técnica 2025.002 relacionadas a IBS/CBS.
• A página relaciona a configuração do CFGTRIB, cClassTrib e atualizações necessárias ao ambiente.
• A TOTVS referencia o validador de NF-e da SEFAZ como recurso externo para validação técnica do XML.
• A validação técnica externa não substitui a avaliação fiscal do conteúdo da operação.

Esses pontos estabelecem o limite do que pode ser afirmado como comportamento documentado do Protheus. Recomendações de governança, auditoria e projeto apresentadas nas próximas seções são boas práticas para organizar a implantação.

Por que este tema é importante

O CFGTRIB deixa explícita uma característica importante dos motores fiscais modernos: o resultado não depende apenas de uma alíquota. Depende de dados mestres, contexto da operação, perfil, classificação, base, fórmula, regra de escrituração e integração com módulos consumidores.

Em Documentos Eletrônicos, essa cadeia merece atenção porque uma falha pode aparecer em locais diferentes. Um erro de classificação pode surgir no XML; um erro de enquadramento pode resultar em ausência ou duplicidade de imposto; uma falha de persistência pode aparecer apenas na escrituração; e uma integração mal desenhada pode recalcular um valor que deveria apenas ser recebido.

Ordem de troubleshooting

1. Reproduza o erro sem alterar o ambiente.
2. Confirme os dados da operação.
3. Confira release e atualização.
4. Verifique perfis e critérios de enquadramento.
5. Revise regra, base, alíquota e escrituração.
6. Analise mensagens, logs e retorno externo.
7. Compare registros persistidos.
8. Verifique customizações apenas depois do padrão.
9. Corrija a causa, não o registro final.
10. Execute regressão após a correção.

Modelo de análise ponta a ponta

Use uma matriz com as seguintes colunas:

Essa matriz reduz a tendência de começar o diagnóstico pelo banco de dados ou pela customização sem antes comprovar o comportamento padrão.

Cenário prático

Uma nova regra é criada para resolver exceção do TMS, mas outra regra já existente continua enquadrando a operação. O imposto é duplicado. O diagnóstico deve revisar o Tipo de Operação e os critérios de concorrência.

O aprendizado desse cenário é simples: uma implementação fiscal precisa provar origem, transformação e destino da informação. Apenas observar o valor final é insuficiente.

Dados mestres e classificações

No CFGTRIB, classificações precisam ser governadas como dado mestre. A tabela cClassTrib é um exemplo claro: a TOTVS documenta a importação da tabela oficial e recomenda acompanhar suas atualizações. Isso significa que a empresa precisa controlar versão, data da importação, ambiente e impacto em regras de escrituração.

O mesmo princípio vale para Tipos de Operação no TMS, códigos de benefício, tributos de importação e perfis. Não permita manutenção sem identificação de responsável e justificativa.

Persistência: CJ3 e F2D

A documentação de IBS/CBS identifica CJ3 e F2D como estruturas relevantes. A CJ3 registra dados de escrituração por item, enquanto F2D armazena informações do tributo genérico calculado.

Uma conciliação útil compara documento, CJ3 e F2D por item e tributo. Divergências devem ser investigadas na configuração que originou os registros, e não corrigidas por UPDATE direto.

XML, NF-e e CT-e

Quando o processo termina em documento eletrônico, confira a versão do schema, as tags geradas e o retorno do autorizador. A TOTVS mantém documentação específica para NF-e e CT-e com IBS/CBS.

A autorização do documento é um controle técnico. A empresa ainda precisa comprovar que a classificação e a memória de cálculo são adequadas à operação. Da mesma forma, um validador externo pode ajudar a identificar problemas de schema sem decidir o tratamento tributário.

TMS e concorrência de regras

No TMS, a TOTVS documenta ligação entre DV1_OPER/DUG_OPER e F26_TPOPER. Essa relação é especialmente importante porque regras concorrentes podem produzir duplicidade de imposto.

Ao testar TMS, registre qual Tipo de Operação foi usado, quais regras poderiam enquadrar e por que somente a esperada deve ser selecionada. Inclua esse teste sempre que novas regras forem adicionadas.

Importação e Operandos de Integração

O SIGAEIC é um ótimo exemplo de que o CFGTRIB nem sempre é o local de cálculo original. A documentação da TOTVS afirma que, no cenário de importação, o módulo já calcula determinados tributos e o CFGTRIB recebe os valores por Operandos de Integração.

Isso exige um modelo diferente de homologação: em vez de recalcular, é necessário conciliar o valor de origem com o valor recebido e escriturado. Se houver diferença, investigue o contrato de integração antes de alterar a fórmula.

Arredondamento e rejeições

A Rejeição 318 documentada no TMS demonstra que detalhes de arredondamento e base podem gerar falhas mesmo quando a diferença é pequena. Mantenha casos de teste com valores que produzam casas decimais e compare o resultado ao manual técnico aplicável.

Não crie tolerâncias próprias para “forçar” autorização. Use a configuração e as regras documentadas, e escale ao autorizador quando a própria documentação indicar essa necessidade.

Tratamento híbrido

Cenários híbridos exigem documentação explícita de quem calcula cada tributo. Um desenho mínimo deve indicar:

• tributo;
• motor responsável;
• regra ou cadastro de origem;
• escrituração esperada;
• XML esperado;
• plano de migração;
• data de revisão.

Sem essa matriz, a empresa pode manter regras duplicadas ou assumir que um tributo já migrou quando ainda depende do legado.

SQL e auditoria técnica

Consultas de auditoria podem ajudar a comparar tabelas, mas devem ser somente leitura. Antes de montar qualquer SQL, confirme os campos e tabelas na documentação da release.

Uma consulta útil deve responder uma pergunta de negócio, por exemplo: “quais itens possuem IBS/CBS na F2D sem a escrituração esperada na CJ3?” ou “quais documentos do cenário de teste receberam a classificação prevista?”. Evite SQL genérico que apenas despeja milhares de registros sem critério.

Erros de ambiente versus erros fiscais

O artigo de ERROR.LOG do FISA170 mostra que nem toda falha do Configurador é uma regra tributária incorreta. Inconsistências estruturais, como duplicidade em cadastro de apoio, podem impedir a carga da rotina.

No troubleshooting, classifique primeiro o erro: ambiente, dado mestre, enquadramento, cálculo, escrituração, integração ou autorizador externo. Essa classificação reduz o tempo gasto investigando a camada errada.

Critérios de aceite

Considere o cenário aprovado quando:

1. a interpretação Fiscal foi formalizada;
2. a documentação TOTVS aplicável foi registrada;
3. release e pacotes foram conferidos;
4. perfis e classificações foram validados;
5. cálculo ou integração reproduz o valor esperado;
6. CJ3/F2D ou estruturas aplicáveis foram conferidas;
7. XML ou retorno externo foi validado;
8. exceções foram testadas;
9. não houve impacto em cenário não relacionado;
10. evidências e aprovação foram registradas.

Indicadores para sustentação

Acompanhe:

• regras sem responsável;
• classificações sem data de revisão;
• rejeições por tipo;
• divergências entre cálculo e escrituração;
• operações híbridas ainda não migradas;
• regras concorrentes encontradas;
• falhas de integração;
• incidentes após atualização;
• tempo para corrigir inconsistências;
• cenários homologados por release.

Conclusão

Validação do XML de IBS/CBS deve ser tratado como parte de uma arquitetura fiscal, não como ajuste isolado. O valor real do CFGTRIB está na capacidade de combinar regras e dados de forma rastreável, mas essa flexibilidade exige controles sólidos.

Para diagnosticar falhas pela cadeia de dados e regras, a recomendação central é sempre a mesma: usar a TOTVS como referência do comportamento do produto, a área Fiscal como responsável pelo tratamento tributário e a homologação como prova de que dados, regras, persistência e documentos funcionam juntos.