CFGTRIB - Comércio Exterior

CFGTRIB avançado — COFINS de Importação no CFGTRIB: Checklist de homologação

Artigo avançado sobre cofins de importação no cfgtrib no CFGTRIB do TOTVS Protheus, com documentação oficial, converter o tema em critérios objetivos de teste, riscos e homologação.

Introdução

COFINS de Importação no CFGTRIB é um dos tópicos avançados do Configurador de Tributos do TOTVS Protheus. Neste artigo, o assunto é tratado como checklist de homologação, com foco em converter o tema em critérios objetivos de teste. A base factual vem exclusivamente da documentação oficial da TOTVS consultada até 2026-09-01.

O objetivo prático é representar contribuição de importação integrada ao SIGAEIC. 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 documenta COFINS de importação no CFGTRIB.
  • O cenário recebe o valor calculado pelo SIGAEIC.
  • A codificação apresentada no exemplo deve ser analisada pelo usuário.

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 Comércio Exterior, 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.

Checklist de homologação

  • fonte TOTVS e data registradas;
  • release e pacotes conferidos;
  • dados mestres revisados;
  • cenário positivo executado;
  • cenário de exceção executado;
  • regra e classificação esperadas comprovadas;
  • persistência nas tabelas esperadas verificada;
  • XML ou integração conferidos quando aplicável;
  • resultado comparado com memória funcional;
  • evidência anexada ao chamado ou projeto;
  • aprovação da área Fiscal registrada;
  • plano de regressão definido para próxima atualização.

Modelo de análise ponta a ponta

Use uma matriz com as seguintes colunas:

Camada Pergunta
Requisito Qual tratamento Fiscal foi aprovado?
Dados Quais cadastros e valores alimentam o processo?
Enquadramento Qual perfil ou Tipo de Operação deve selecionar a regra?
Cálculo Base, alíquota e fórmula representam a memória aprovada?
Escrituração CST, CCT, incidência e demais campos estão coerentes?
Persistência Quais tabelas recebem o resultado?
Documento XML/CT-e/NF-e corresponde ao esperado?
Integração Outro módulo envia ou recebe valores?
Evidência O teste consegue ser reproduzido?

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

O XML é autorizado e a equipe encerra o teste. Na conciliação posterior, CJ3 e F2D mostram informação diferente do esperado. O caso demonstra por que autorização externa e persistência interna precisam ser conferidas separadamente.

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

COFINS de Importação no CFGTRIB 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 converter o tema em critérios objetivos de teste, 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.

Fontes e referências

  1. Cross Segmento - TOTVS Backoffice (Linha Protheus) - SIGAEIC - Cadastro da Contribuição COFINS no Configurador de Tributos — TOTVS Central de Atendimento · Acessar fonte · acesso 2026-09-01
  2. Cross Segmento - TOTVS Backoffice (Linha Protheus) - SIGAEIC - Configurador de Tributos (CFGTRIB) na Importação — TOTVS Central de Atendimento · Acessar fonte · acesso 2026-09-01
  3. CROSS Segmentos - TOTVS Backoffice Linha Protheus - FIS - Campos que armazenam as informações dos impostos IBS e CBS — TOTVS Central de Atendimento · Acessar fonte · acesso 2026-09-01
Aviso educacional

Este artigo é informativo e não substitui orientação profissional individualizada.

Conteúdos relacionados