Configurador de Tributos TOTVS Protheus: tabelas, relacionamentos e BI para governança fiscal

# Configurador de Tributos da TOTVS Protheus: tabelas, relacionamentos e como construir um BI para governança fiscal

Introdução

O Configurador de Tributos (CFGTRIB / FISA170) é uma das estruturas mais importantes do TOTVS Protheus para empresas que precisam transformar regras fiscais complexas em parametrizações rastreáveis. Em vez de concentrar toda a lógica tributária em cadastros legados ou customizações, o configurador separa perfis, bases de cálculo, alíquotas, fórmulas, regras tributárias, escrituração, apuração e movimentos em conjuntos de tabelas especializadas.

Essa flexibilidade resolve um problema importante, mas cria outro: governança. À medida que crescem o número de filiais, produtos, participantes, operações, tributos, CSTs, cClassTrib, regras e vigências, torna-se difícil responder perguntas aparentemente simples:

• Quantas regras tributárias estão cadastradas?
• Quais estão aprovadas e quais continuam em teste?
• Quais regras estão vencidas ou próximas do fim da vigência?
• Existem regras sem perfil, base, alíquota ou escrituração coerente?
• Quais regras efetivamente estão sendo utilizadas nas notas fiscais?
• Há cadastros duplicados ou sobrepostos?
• Uma mesma regra está sendo usada por todas as filiais esperadas?
• Quais tributos possuem maior número de regras?
• Quais regras nunca geraram movimento?
• Qual regra calculou determinado imposto em uma NF?
• O compartilhamento entre empresas e filiais está coerente?
• Uma alteração cadastral aumentou rejeições ou divergências fiscais?

É exatamente nesse ponto que um BI do Configurador de Tributos deixa de ser apenas um painel e passa a funcionar como uma camada de governança fiscal.

Nota técnica importante: este artigo separa o que é documentado oficialmente pela TOTVS do que é proposta de arquitetura analítica. Os relacionamentos físicos devem ser confirmados no dicionário SX3/SIX e na release instalada antes da criação de JOINs em produção.

---

1. O que é o CFGTRIB

A documentação da TOTVS descreve o Configurador de Tributos como uma estrutura criada para permitir tributos configuráveis. Elementos como origem, destino, produto, cliente, fornecedor e CFOP são tratados por cadastros específicos, e componentes como base, alíquota, incidência, recolhimento, retenção e geração de títulos podem ser combinados na definição das regras.

Isso muda a forma de enxergar o fiscal no ERP.

Em um modelo simplificado, podemos imaginar:

CONTEXTO DA OPERAÇÃO

        |

        +-- Origem / Destino

        +-- Participante

        +-- Operação

        +-- Produto

        |

        v

PERFIS TRIBUTÁRIOS

        |

        v

REGRA TRIBUTÁRIA

        |

        +-- Base de Cálculo

        +-- Alíquota

        +-- Fórmula

        +-- Tributo

        +-- Escrituração

        |

        v

CÁLCULO NO DOCUMENTO

        |

        v

F2D - TRIBUTOS GENÉRICOS CALCULADOS

        |

        +-- SD1 / D1_IDTRIB

        +-- SD2 / D2_IDTRIB

        |

        v

ESCRITURAÇÃO / APURAÇÃO / TÍTULOS

O desenho acima é conceitual. Ele é extremamente útil para BI, porque separa cadastro, regra e movimento.

---

# 2. Mapa das principais tabelas

A TOTVS lista oficialmente um conjunto amplo de tabelas do Configurador de Tributos. Para fins de BI, vale organizá-las por domínio.

2.1 Perfis tributários

Essas tabelas representam uma parte fundamental do contexto de incidência.

Em termos de BI, elas respondem principalmente à pergunta:

Para quais operações, participantes, produtos e combinações determinada configuração fiscal foi desenhada?

Um painel pode mostrar, por exemplo, quantidade de produtos por perfil, participantes sem perfil, operações sem cobertura, perfis com poucos registros e perfis excessivamente genéricos.

---

2.2 Regras de cálculo

Esse é o coração lógico do cálculo.

A F2B merece atenção especial. Ela representa a Regra Tributária / Regra de Cálculo do documento fiscal.

A TOTVS documenta o campo F2B_REGRA como o código da regra. Também documenta, a partir da versão 12.1.2310, o campo F2B_STATUS, com:

• 1 = Em Teste
• 2 = Aprovada

O status é especialmente valioso para BI, pois permite criar uma visão de governança entre configuração em homologação e configuração liberada.

Indicadores recomendados

• regras em teste;
• regras aprovadas;
• regras por tributo;
• regras por filial;
• regras por vigência;
• regras vencidas;
• regras que vencem em 7, 15, 30, 60 e 90 dias;
• regras sem utilização;
• regras com utilização após vencimento;
• regras criadas recentemente;
• regras alteradas recentemente, quando houver trilha disponível.

---

# 3. Cadastro dos tributos e integração

F2E — Cadastro de Tributo

A F2E representa o cadastro dos tributos utilizados pelo mecanismo.

No BI, ela pode funcionar como uma dimensão central:

DIM_TRIBUTO

   |

   +---- regras

   +---- movimentos

   +---- apuração

   +---- títulos

Com isso, torna-se possível criar indicadores como:

• número de regras por tributo;
• documentos calculados por tributo;
• valor calculado por período;
• quantidade de filiais utilizando cada tributo;
• tributos cadastrados sem movimento;
• tributos com regra mas sem cálculo;
• tributos calculados sem a cobertura cadastral esperada.

---

F2C — Tributos De/Para

A F2C integra a estrutura de tributos genéricos com identificações utilizadas por outros processos.

Em governança, qualquer estrutura de De/Para merece atenção especial porque pode gerar inconsistência silenciosa: o cálculo pode existir, mas uma integração ou interpretação posterior pode não reconhecer corretamente o tributo.

Um BI pode criar uma página específica de Integridade De/Para, destacando cadastros sem correspondência e possíveis duplicidades.

---

# 4. F2D: a tabela que liga configuração ao que realmente aconteceu

A F2D — Tributos Genéricos Calculados é uma das tabelas mais importantes para um BI.

Enquanto F20–F2B representam principalmente a configuração, a F2D representa o resultado do cálculo tributário no documento fiscal.

A documentação TOTVS informa que documentos de entrada e saída podem ser ligados aos tributos calculados por meio de:

SD1.D1_IDTRIB

SD2.D2_IDTRIB

Esses identificadores permitem localizar o registro correspondente na F2D.

A própria TOTVS orienta esse caminho para descobrir qual Regra de Cálculo foi aplicada a uma Nota Fiscal.

Conceitualmente:

SD1 / SD2

    |

    | D1_IDTRIB / D2_IDTRIB

    v

   F2D

    |

    v

   F2B

 Regra Tributária

Esse caminho é extremamente poderoso.

O BI deixa de responder apenas “o que está cadastrado?” e passa a responder:

“Qual configuração realmente foi utilizada?”

---

# 5. O relacionamento F2B_REGRA

A TOTVS esclarece um ponto que evita erros de modelagem.

O código F2B_REGRA não é gravado diretamente em SFT, SF3 e CD2 como uma referência universal da nova regra.

Segundo a documentação, o código da regra aparece nas estruturas:

• F2B — F2B_REGRA;
• F2D — campo relacionado documentado pela TOTVS;
• CIN — CIN_REGRA;
• CJ2 — CJ2_CODIGO.

Isso é importante porque uma consulta simplista tentando localizar F2B_REGRA diretamente em todas as tabelas fiscais tradicionais pode produzir uma visão incorreta.

Para BI, prefira construir a linhagem a partir dos IDs e relacionamentos efetivamente documentados, validando os índices e campos no dicionário da release.

---

# 6. Escrituração: CJ2 e CJ3

A regra de cálculo responde essencialmente:

Como calcular?

A regra de escrituração acrescenta outra dimensão:

Como o resultado deve ser classificado/escriturado?

Em um BI fiscal completo, cálculo e escrituração não deveriam aparecer isolados.

Uma visão recomendada:

REGRA

  |

  +-- Tributo

  +-- Base

  +-- Alíquota

  +-- Fórmula

  +-- Perfil

  +-- Escrituração

  +-- Status

  +-- Vigência

O painel pode procurar regras aprovadas sem escrituração esperada, divergências de configuração e movimentos cuja escrituração mereça revisão.

A TOTVS também inclui CJ3 entre as tabelas cujo modo de compartilhamento não deve ser alterado.

---

# 7. CST: CJ0 e CJ1

Com IBS e CBS, o controle das classificações tributárias ganhou ainda mais importância.

Um BI pode transformar CST em dimensão analítica e cruzá-lo com:

• tributo;
• regra;
• produto;
• operação;
• CFOP;
• filial;
• documento;
• rejeições;
• cClassTrib, quando disponível na estrutura/versionamento utilizado pela empresa.

Isso permite encontrar combinações improváveis ou não homologadas.

Exemplo:

CST

 |

 +-- Regra A

 +-- Regra B

 +-- Regra C

      |

      +-- produtos

      +-- operações

      +-- documentos

Quanto maior o número de regras para uma mesma classificação, maior a necessidade de explicar por que elas existem.

---

# 8. Apuração

A TOTVS lista as seguintes tabelas:

Aqui surge outra camada de BI:

DOCUMENTO

   ↓

CÁLCULO

   ↓

ESCRITURAÇÃO

   ↓

APURAÇÃO

   ↓

AJUSTES

   ↓

TÍTULO

O BI pode realizar reconciliações entre essas etapas.

Exemplos:

Calculado x Apurado

Valor calculado em documentos

-

Valor considerado na apuração

=

Diferença a investigar

Apurado x Título

Valor da apuração

-

Valor dos títulos gerados

=

Diferença

Esses indicadores ajudam a encontrar falhas antes do fechamento.

---

# 9. Regras financeiras

O Configurador também possui uma estrutura específica para regras financeiras.

A documentação TOTVS relaciona, entre outras:

• FKK — Regras Financeiras Retenção;
• FKL — Regras de Títulos;
• FKN — Regra de Cálculo;
• FKO — Regras de Retenção;
• FKP — Regras de Vencimento;
• FKQ — Tributos Fiscais Calculados;
• FKS — Cabeçalho Tabelas Financeiras;
• FKT — Regra de Cumulatividade;
• FKU — Regra de Valores Acessórios;
• FKV — Regra de Deduções;
• FOO — Tipos de Impostos;
• FOI — Tipo de Retenção x Naturezas;
• FOJ — Tipo de Retenção x Clientes;
• FOK — Tipo de Retenção x Fornecedores;
• FOS, FOT, FOU e FOV — valores e características complementares de retenção.

Isso permite criar um segundo domínio no BI:

FISCAL

  |

  +-- Documento Fiscal

  +-- IBS/CBS/ICMS/IPI...

  |

FINANCEIRO

  |

  +-- Natureza

  +-- Cliente/Fornecedor

  +-- Retenção

  +-- Vencimento

  +-- Título

Um painel corporativo pode mostrar os dois universos sem misturá-los indevidamente.

---

# 10. Compartilhamento de tabelas: ponto crítico

Esse assunto merece um painel próprio.

A TOTVS destaca que o compartilhamento deve ser definido de acordo com a estrutura da companhia e alerta que alterar essa estratégia depois da implantação pode comprometer a confiabilidade da base.

A documentação agrupa para análise:

Perfis

F20

F21

F22

F23

F24

F25

F26

CIO

Regras de cálculo

F27

F28

F29

F2B

CIN

Escrituração

CJ2

Além disso, a SX5 precisa ser considerada na análise.

A TOTVS informa que determinadas tabelas não devem ter seu modo de compartilhamento alterado:

F2D

F2F

F2H

F2I

F2J

F2K

F2L

F2M

CJ3

Para BI, isso gera um indicador extremamente interessante:

Matriz de compartilhamento

A implementação deve consultar o dicionário/configuração real do ambiente, e não assumir valores universais.

---

# 11. Por que o BI muda o jogo

O FISA170 é excelente para configurar.

O BI deve ser excelente para observar.

Essa diferença é fundamental.

O usuário fiscal normalmente entra no configurador procurando uma regra específica. O BI faz o movimento inverso: examina milhares de registros procurando padrões, exceções, lacunas e riscos.

---

# 12. Dashboard 1 — Saúde do CFGTRIB

Cards:

Tributos cadastrados

Regras cadastradas

Regras aprovadas

Regras em teste

Regras vencidas

Regras próximas do vencimento

Regras sem movimento

Perfis sem utilização

Regras com alto volume de documentos

Gráficos:

• regras por tributo;
• regras por status;
• regras por filial;
• regras por vigência;
• crescimento mensal de regras;
• top regras por documentos calculados.

---

# 13. Dashboard 2 — Cobertura tributária

Objetivo:

Descobrir se os cadastros cobrem o universo operacional.

Cruzar:

Produtos

x

Participantes

x

Operações

x

Origem/Destino

x

Tributos

x

Regras

O painel deve procurar:

• produto sem perfil;
• cliente/fornecedor sem perfil quando necessário;
• operação sem perfil;
• perfil sem regra;
• regra sem tributo;
• regra sem base;
• regra sem alíquota quando esperada;
• regra sem escrituração;
• combinação nunca utilizada.

---

# 14. Dashboard 3 — Regras em Teste x Aprovadas

O campo F2B_STATUS abre uma excelente oportunidade.

F2B_STATUS = 1 → Em Teste

F2B_STATUS = 2 → Aprovada

Crie indicadores:

% regras aprovadas

% regras em teste

tempo médio em teste

regras em teste há mais de 30 dias

regras aprovadas sem movimento

regras em teste que aparecem em simulação

Se a empresa possuir processo de mudança formal, o BI pode integrar chamado, responsável, data de homologação e aprovação.

---

# 15. Dashboard 4 — Utilização real das regras

Essa talvez seja a tela mais valiosa.

Partindo de SD1/SD2 e F2D, descubra quais regras efetivamente calcularam tributos.

Exemplo conceitual:

Documento

   → D1_IDTRIB / D2_IDTRIB

       → F2D

           → Regra

               → F2B

Não copie esse desenho diretamente para produção sem validar campos, índices, filial e deleção lógica no seu dicionário.

Indicadores:

• documentos por regra;
• valor calculado por regra;
• produtos por regra;
• clientes por regra;
• CFOPs por regra;
• filiais por regra;
• última utilização;
• regra nunca utilizada;
• regra aprovada sem utilização;
• regra antiga ainda muito utilizada.

---

# 16. Dashboard 5 — Vigências e sobreposição

Um dos maiores riscos em motores tributários configuráveis é a coexistência de regras que parecem atender ao mesmo contexto.

O BI pode criar um detector de sobreposição.

Exemplo conceitual:

Mesmo tributo

+ mesmo perfil de produto

+ mesmo perfil de participante

+ mesma operação

+ períodos de vigência sobrepostos

= ALERTA

Nem toda sobreposição é erro.

Mas toda sobreposição relevante merece explicação.

Classificação sugerida:

VERDE    → combinação única

AMARELO  → possível sobreposição

VERMELHO → mesma combinação + vigência concorrente

---

# 17. Dashboard 6 — Auditoria da Reforma Tributária

Para IBS/CBS, crie uma área dedicada.

Dimensões:

• IBS Estadual;
• IBS Municipal;
• CBS;
• CST;
• cClassTrib;
• operação;
• CFOP;
• produto;
• NCM;
• filial;
• regra;
• vigência.

Indicadores:

Produtos sem configuração RTC

Operações sem cobertura

Regras IBS/CBS em teste

Regras RTC aprovadas

Documentos com IBS/CBS

Valor de IBS

Valor de CBS

Regras nunca utilizadas

Divergências por classificação

O objetivo é transformar a implantação da Reforma Tributária em um processo mensurável.

---

# 18. Dashboard 7 — Linha do tempo da configuração

Imagine selecionar uma regra e visualizar:

REGRA: IBS_VENDA_001



Criada

  ↓

Alterada

  ↓

Em teste

  ↓

Homologada

  ↓

Aprovada

  ↓

Primeiro documento

  ↓

100 documentos

  ↓

Última utilização

Se o ambiente não possuir trilha histórica suficiente nas tabelas operacionais, essa visão exige capturas periódicas, auditoria ou uma camada histórica própria no Data Warehouse.

Essa é uma distinção importante: estado atual não é histórico.

---

# 19. Arquitetura recomendada do Data Warehouse

Não recomendo conectar o Power BI diretamente às tabelas transacionais com dezenas de JOINs complexos e transformar o relatório em uma réplica do banco Protheus.

Crie uma camada analítica.

Dimensões

DIM_TRIBUTO

DIM_REGRA_TRIBUTARIA

DIM_PERFIL_PRODUTO

DIM_PERFIL_PARTICIPANTE

DIM_PERFIL_OPERACAO

DIM_ORIGEM_DESTINO

DIM_CST

DIM_CLASSIFICACAO_TRIBUTARIA

DIM_PRODUTO

DIM_PARTICIPANTE

DIM_FILIAL

DIM_CFOP

DIM_DATA

Fatos

FATO_TRIBUTO_CALCULADO

FATO_DOCUMENTO_FISCAL

FATO_APURACAO

FATO_AJUSTE

FATO_TITULO_TRIBUTO

FATO_REJEICAO

FATO_SNAPSHOT_CFGTRIB

---

# 20. Snapshot diário: recurso decisivo

Uma das melhores decisões para esse BI seria criar uma tabela de snapshot.

Exemplo:

BI_CFGTRIB_SNAPSHOT

Campos conceituais:

DATA_SNAPSHOT

EMPRESA

FILIAL

REGRA

TRIBUTO

STATUS

DT_INICIO

DT_FIM

BASE

ALIQUOTA

ESCRITURACAO

PERFIL_PRODUTO

PERFIL_PARTICIPANTE

PERFIL_OPERACAO

HASH_CONFIGURACAO

O HASH_CONFIGURACAO pode representar a combinação dos atributos importantes.

Se amanhã o hash mudar:

HASH ontem != HASH hoje

o BI sabe que a regra foi alterada.

Isso permite responder:

O que mudou no CFGTRIB desde ontem?

Esse controle é extremamente poderoso para fechamento fiscal.

---

# 21. Detector automático de alterações

Um processo ETL diário pode:

1. extrair as tabelas de configuração;
2. normalizar campos;
3. calcular hash;
4. comparar com o snapshot anterior;
5. classificar inclusão, alteração ou exclusão lógica;
6. registrar diferença;
7. atualizar o BI;
8. disparar alerta para mudanças críticas.

Exemplo:

REGRA IBS001



Ontem:

Alíquota = 0,10

Status = Aprovada



Hoje:

Alíquota = 0,05

Status = Aprovada



ALERTA:

Regra aprovada sofreu alteração.

Esse tipo de alerta muda completamente a governança do cadastro tributário.

---

# 22. Score de risco das regras

O BI pode atribuir um score interno — não fiscal/legal — para priorização operacional.

Exemplo:

+20 regra em teste

+20 vigência vencida

+15 sem escrituração esperada

+15 sem utilização

+10 alteração recente

+10 grande quantidade de produtos

+10 sobreposição detectada

Resultado:

0–20   acompanhamento normal

21–40  revisar

41–60  atenção

61+    prioridade de auditoria

O score não determina se a regra está fiscalmente correta. Ele apenas direciona a equipe para cadastros com maior necessidade de revisão.

---

# 23. Indicadores que eu colocaria na tela principal

Governança

Total de regras

Aprovadas

Em teste

Vencidas

A vencer

Alteradas nos últimos 7 dias

Sem utilização

Cobertura

Produtos cobertos

Participantes cobertos

Operações cobertas

Filiais cobertas

Tributos configurados

Movimento

Documentos calculados

Valor total por tributo

Top 10 regras

Regras sem movimento

Última utilização

Qualidade

Possíveis duplicidades

Sobreposição de vigência

Cadastro órfão

Regra sem dependência esperada

Divergência de compartilhamento

Alteração em regra aprovada

---

# 24. Drill-through: da diretoria até a NF

O BI ideal deve permitir:

Tributo

 ↓

Regra

 ↓

Perfil

 ↓

Produto

 ↓

Filial

 ↓

Documento

 ↓

Item

 ↓

Tributo calculado

A diretoria enxerga risco e cobertura.

O fiscal enxerga regra e classificação.

A TI enxerga tabela, ID e relacionamento.

O suporte chega ao documento que materializou o problema.

Esse é o ponto em que o BI deixa de ser apenas gerencial e se torna também uma ferramenta operacional.

---

# 25. Integridade referencial lógica

Bancos Protheus nem sempre devem ser interpretados como um modelo relacional clássico com foreign keys físicas para tudo.

Por isso, o BI precisa implementar integridade lógica.

Exemplos de testes:

F2D sem regra correspondente

Regra apontando para cadastro inexistente

Perfil sem itens

Tributo sem regra

Regra sem movimento

Movimento com referência que não resolve

Escrituração órfã

Cada teste pode gerar:

STATUS

SEVERIDADE

TABELA

CHAVE

DESCRIÇÃO

DATA_DETECÇÃO

Isso cria um verdadeiro Data Quality Fiscal.

---

# 26. Cuidados com D_E_L_E_T_ e filial

Qualquer extração Protheus precisa considerar dois pontos clássicos:

D_E_L_E_T_

FILIAL

Não basta fazer JOIN apenas pelo código lógico.

A chave efetiva pode depender de filial, compartilhamento, índice e desenho da tabela.

Portanto:

Nunca transforme exemplos conceituais deste artigo em JOINs de produção sem conferir SX3, SIX e a configuração de compartilhamento do ambiente.

---

# 27. Por que consultar SX3 e SIX

Antes de desenvolver o BI:

• consulte SX3 para metadados dos campos;
• consulte SIX para índices;
• confira X2_MODO/estrutura de compartilhamento;
• valide o comportamento por empresa e filial;
• identifique campos customizados;
• identifique alterações específicas da release.

Isso evita construir um BI tecnicamente bonito sobre relacionamentos errados.

---

# 28. Roadmap de implantação

Fase 1 — Inventário

Mapear:

F20–F2N

CIN

CIO

CJ0–CJL

FK*

FO*

SD1

SD2

e somente as demais tabelas realmente utilizadas no ambiente.

Fase 2 — Dicionário

Documentar:

Tabela

Campo

Descrição

Tipo

Índice

Compartilhamento

Domínio

Relacionamento lógico

Fase 3 — Data Warehouse

Criar dimensões e fatos.

Fase 4 — Qualidade

Implementar:

• órfãos;
• duplicidades;
• vigências;
• cobertura;
• status;
• utilização.

Fase 5 — Reforma Tributária

Criar visão dedicada a IBS/CBS.

Fase 6 — Alertas

Monitorar alterações e riscos.

---

# 29. Modelo de catálogo técnico

Uma tabela de metadados interna pode ter:

Esse catálogo ajuda muito quando Fiscal, Controladoria e TI precisam falar a mesma língua.

---

# 30. BI como ferramenta de controle interno

A maior oportunidade não está no gráfico.

Está no controle.

Com o BI, a empresa pode estabelecer políticas:

Toda regra aprovada precisa ter responsável.

Toda alteração de regra aprovada deve ser monitorada.

Toda regra deve possuir vigência coerente.

Toda regra crítica precisa de evidência de homologação.

Toda regra sem utilização por determinado período deve ser revisada.

Toda sobreposição precisa ser justificada.

Toda divergência de compartilhamento precisa ser analisada.

O Configurador de Tributos deixa então de ser apenas um cadastro técnico e passa a fazer parte formal da governança fiscal.

---

# 31. O ganho para Fiscal, TI e Controladoria

Fiscal

Obtém visão de cobertura, vigências, regras e classificações.

TI

Obtém rastreabilidade de tabelas, relacionamentos, movimentos e alterações.

Controladoria

Obtém indicadores de risco, aderência, exceções e evolução da implantação.

Gestão

Obtém uma pergunta muito mais importante do que “o sistema está atualizado?”:

Qual é o nível de controle que temos sobre as regras tributárias que determinam nossos documentos fiscais?

---

# 32. Conclusão

O Configurador de Tributos do TOTVS Protheus é muito mais do que a rotina FISA170. Ele forma um ecossistema de dados fiscais composto por perfis, regras, fórmulas, tributos, escrituração, movimentos, apuração e componentes financeiros.

As tabelas F20 a F26 estruturam perfis. F27, F28, F29, F2B e CIN participam do universo de cálculo. F2E representa o cadastro do tributo. F2D materializa tributos calculados nos documentos. CJ2/CJ3 entram na escrituração. F2G a F2N suportam apuração e processos relacionados. CJ0/CJ1, CIO e as estruturas financeiras complementam o ecossistema.

O maior salto de maturidade acontece quando esses dados deixam de ser consultados apenas durante um erro.

Um BI do CFGTRIB pode funcionar como radar permanente:

CADASTRO

   ↓

RELACIONAMENTO

   ↓

REGRA

   ↓

MOVIMENTO

   ↓

ESCRITURAÇÃO

   ↓

APURAÇÃO

   ↓

CONTROLE

Com snapshots, indicadores de cobertura, detecção de órfãos, análise de vigências, monitoramento de status, rastreamento F2D → documento, alertas de alterações e dashboards específicos para IBS/CBS, a empresa passa de uma postura reativa para uma postura de governança tributária orientada a dados.

E esse talvez seja o maior valor do BI: não calcular o imposto no lugar do Protheus, mas responder continuamente se as regras que fazem o Protheus calcular estão completas, coerentes, vigentes, aprovadas e efetivamente utilizadas.