Diagrama Mestre Circular do Processo — Ecossistema GOVSEC

Relatório de arquitetura · {{ qtdMenus }} menus · {{ qtdSub }} submenus · leitura por eventos e decisões

19/09/2026 · nomes de menu lidos da aplicação

Princípio arquitetural central. Um contribuinte, uma identidade, uma carteira de informações, uma trilha de eventos e múltiplos módulos consumindo a mesma verdade. Nenhum módulo cria cadastro paralelo do contribuinte.

Este relatório não altera o sistema nem o relatório anterior. Onde a ligação não pôde ser comprovada na aplicação, aparece marcada como INTEGRAÇÃO A VALIDAR.

Legenda visual

→ fluxo operacional ⇢ comunicação ↺ retroalimentação ⋯ integração externa ◆DMN · decisão ▣BPMN · processo ◇CMMN · exceção ⚡evento Ggate de aprovação AUTOautomático Hação humana PRIVATIVOato reservado integração auditoria e registro

Filtros

Ativo: {{ filtroLabel }} · {{ filtroNota }}

1 · Visão executiva

O ecossistema em seis estágios. A leitura é circular: nenhum estágio é terminal — todos devolvem estado ao ciclo.

Centro de Integrações

2 · Mapa circular mestre — os 12 menus

Anel de fluxo no sentido horário, com o nome de cada ligação. O anel externo traz os {{ qtdSub }} submenus reais, cada um com sua notação e seu modo de execução — clique em qualquer submenu para abrir o elo completo no painel da seção 5. As cordas tracejadas âmbar são as retroalimentações, numeradas e descritas na lista abaixo.

ANEL EXTERNO · Centro de Integrações · Configurações · Auditoria e Governança escala {{ escalaTxt }}

NÚCLEO · EIXO TRANSVERSAL Identidade única Contribuinte · CPF/CNPJ · Perfil 360º CTR-xxxx · USR-xxxx Todo débito, medida, campanha, protocolo, acordo, pagamento, processo, cessão e lançamento resolve para este identificador.

{{ n.anel }} · {{ n.qtd }} submenus

ELOS DE RETROALIMENTAÇÃO — AS CORDAS TRACEJADAS NUMERADAS

{{ r.num }} {{ r.de }} → {{ r.para }} · {{ r.rotulo }}

Retroalimentações do mapa (cordas tracejadas)

{{ r.de }} → {{ r.para }}

Anéis do ecossistema

NúcleoIdentidade única · Contribuinte · Perfil 360º

Anel 1 · DadosBase Cadastral

Anel 2 · CréditoCrédito e CDA · Rating GRDA

Anel 3 · DecisãoRégua de Cobrança · DMN

Anel 4 · ExecuçãoEsteira · Notificação · CADIN · SERASA · Protesto · Multas · Pesquisa Patrimonial · Averbação

Anel 5 · ComunicaçãoCampanha

Anel 6 · RelacionamentoPortal do Contribuinte · Atendimento e Protocolo

Anel 7 · RegularizaçãoNegociação e Acordos · Parcelas

Anel 8 · ConsequênciaPagamento · Inadimplência · Jurídico e Execução Fiscal

Anel 9 · FinanceiroFinanceiro e Contabilidade · Conciliação

Anel 10 · MercadoCessão

Anel externoRelatórios · Configurações · Auditoria · Centro de Integrações

3 · Mapa horizontal — a jornada em uma página

O mesmo ecossistema em leitura da esquerda para a direita, com os {{ qtdSub }} submenus dentro dos cartões e o nome de cada ligação entre eles. Formato de página única, para impressão e apresentação. Os submenus continuam clicáveis.

ECOSSISTEMA GOVSEC

PÁGINA ÚNICA · PAISAGEM 1600×1320 escala {{ escalaHTxt }}

Jornada integrada da gestão da dívida ativa

Processo detalhado em {{ qtdMenus }} módulos, com {{ qtdSub }} submenus, decisões, eventos e integrações transversais

IDENTIDADE ÚNICA Contribuinte · CPF/CNPJ · Perfil 360º · CTR · USR · mesma verdade em todos os módulos

{{ c.conector }} ▶

RETROALIMENTAÇÃO pagamento conciliado · acordo rompido · resultado de campanha · patrimônio localizado · andamento processual · recompra executada {{ horizRetornos }}

CENTRO DE INTEGRAÇÕES

Camada técnica transversal: APIs, conectores, webhooks, eventos, filas, quality gate, logs, auditoria, credenciais, versionamento, ambientes e evidências.

GOVERNANÇA

Fonte marcada como “a validar” não tem conector comprovado na aplicação. Nenhuma automação autoriza medida com efeito jurídico: o Centro de Integrações provê canal e trilha, mas não pratica ato de cobrança.

4 · Mapa de ligações — submenu a submenu

Os 12 menus em fileira única, com as {{ ligQtd }} ligações no nível de submenu. Toda ligação sai da borda direita da origem e entra na borda esquerda do destino, por faixas livres acima (fluxo) e abaixo (retroalimentação) — nenhuma linha atravessa o corpo de um quadro. Clique num submenu para isolar as ligações dele; clique nos tipos para ligar e desligar famílias de fluxo.

ENVIA PARA

Nenhuma saída declarada na matriz.

▸ {{ x.texto }}

RECEBE DE

Nenhuma entrada declarada na matriz.

◂ {{ x.texto }}

Faixa acima da fileira: fluxo para a frente. Faixa abaixo: retroalimentação e retorno para módulo anterior. Trajeto vertical dentro da coluna: ligação entre submenus do mesmo menu. Toda ligação vem da matriz origem → destino do relatório — nenhum par foi inventado.

5 · Mapa detalhado — menus e submenus

Clique num menu para abrir seus submenus; clique num submenu para ver origem, entrada, processamento, regra, ação, saída, destino, evento e retorno.

Selecione um submenu para ver o elo completo de origem, regra, ação, destino, evento e retorno.

INTEGRAÇÃO A VALIDAR. {{ sel.lacuna }}

6 · Mapa da jornada do contribuinte

Da Base Cadastral ao pagamento ou à execução fiscal, sempre sob o mesmo identificador.

⚡ {{ p.evento }}

▶

↺ Retorno. Silêncio no prazo, contestação, acordo rompido ou pagamento parcial devolvem o contribuinte à decisão da Régua de Cobrança com estado atualizado — a jornada não termina, recomeça.

7 · Mapa da jornada do crédito

O mesmo ciclo visto pelo objeto crédito — do débito recebido ao destino final: recuperado, suspenso, cancelado, cedido ou ajuizado.

⚡ {{ p.evento }}

▶

8 · Mapa de retroalimentação

Todo processo relevante volta ao ciclo. Cada cadeia abaixo termina em nova decisão da Régua.

{{ c.nome }} ↺

9 · Mapa BPMN · DMN · CMMN

O que é processo previsível, o que é decisão e o que é exceção — três naturezas que não se misturam.

{{ n.glifo }} {{ n.nome }} {{ n.qtd }} submenus

10 · Mapa de objetos centrais

As entidades que atravessam os módulos. A cadeia principal é linear; as entidades de apoio se ligam a qualquer ponto dela.

{{ o.nome }} →

ENTIDADES DE APOIO, LIGADAS À MESMA IDENTIDADE

11 · Matriz origem → destino

Toda ligação com nome. {{ matrizIntQtd }} ligações mapeadas · o filtro ativo se aplica a esta matriz.

ORIGEM · SUBMENU	EVENTO	INFORMAÇÃO	REGRA	DESTINO · SUBMENU	MODO	RETORNO
{{ r.origem }} {{ r.origemSub }}	⚡ {{ r.evento }}	{{ r.info }}	{{ r.regra }}	{{ r.destino }} {{ r.destinoSub }}	{{ r.modo }}	{{ r.retorno }}

12 · Matriz de eventos — trilha mestre

{{ eventosQtd }} eventos de negócio, cada um com origem, entidade afetada, regra, resultado e próxima ação. Evento de atualização leva classe — Cadastral recalcula D1, Patrimonial recalcula D3 — pela mesma tipagem do catálogo do Centro de Integrações.

⚡ EVENTO	CLASSE · DIMENSÃO	ORIGEM	ENTIDADE AFETADA	REGRA	RESULTADO	PRÓXIMA AÇÃO
{{ e.nome }}	{{ e.classeRotulo }} recalcula {{ e.classeDim }} —	{{ e.origem }}	{{ e.entidade }}	{{ e.regra }}	{{ e.resultado }}	{{ e.proxima }}

13 · Matriz de retroalimentação

EVENTO	ONDE NASCE	O QUE ATUALIZA	RECALCULA RATING?	VOLTA À RÉGUA?	PRÓXIMO DESTINO
{{ r.evento }}	{{ r.nasce }}	{{ r.atualiza }}	{{ r.rating }}	{{ r.regua }}	{{ r.destino }}

14 · Matriz de dependências

Base para a modelagem do backend: quem depende de quem, e por qual evento.

MÓDULO	DEPENDE DE	ALIMENTA	EVENTO DE ENTRADA	EVENTO DE SAÍDA
{{ d.modulo }}	{{ d.depende }}	{{ d.alimenta }}	{{ d.entrada }}	{{ d.saida }}

15 · Mapa de integrações — camada transversal

O Centro de Integrações não é uma caixa do fluxo: é a camada que alcança as fontes externas e guarda a trilha. Ele não é chamado por cada módulo: autentica um único chamador, o Portal de Gestão.

Ponto único de entrada — quem chama o CI

Portal do Contribuinte e Portal de Atendentes não mantêm credencial de serviço para o Centro de Integrações. Pedem ao Portal de Gestão, que chama em nome deles com a credencial svc_pg_mediacao e devolve o resultado pelo mesmo caminho.

PC → PG → CI → conector → volta por CI → PG → PC

CA → PG → CI → conector → volta por CI → PG → CA

PG → CI — configuração e gestão do cofre, pelo modelo de quatro perfis

O controle que permanece

O escopo de dado de cada chamada deriva só da identidade autenticada de quem a faz. Envelope sem protocolo ou sessão é recusado no Portão de chamadas, antes do conector.

Origem é trilha, não privilégio

O PG propaga o protocolo do PC e o operador da CA para não perder a granularidade da auditoria. São campos declarados e não verificados: cruzam auditorias, nunca concedem acesso.

O CI não é sistema de registro

Protocolo, guia e acordo permanecem no PG. O CI recebe só o evento de integração — “PIX gerado”, “mensagem enviada” — correlacionado por ID de protocolo, nunca o conteúdo dele.

Os cinco canais PG ↔ CI bidirecional

Cada canal tem uma origem de dado só: o Portal de Gestão escreve o pedido, o Centro de Integrações decide, e a decisão volta pela mesma chave — não há segunda fila, nem cópia do outro lado. A autoridade é dividida por natureza do ato: o CI é dono do conector (canal, credencial, status, alçada); o PG é dono do ato de cobrança. Quem publica avisa na hora, na mesma aba e entre abas — sincronização que exige recarregar a página não é sincronização.

PG → CI → PG Modelo de CDA

O PG publica a versão; o CI decide a situação dela. Publicar versão nova não reescreve documento antigo — a CDA já emitida guarda a versão com que saiu.

PG → CI → PG Retificação de CDA

A alçada é do CI: o Portal não aprova a própria retificação. Pedido novo do mesmo registro substitui o pendente em vez de acumular — dois pendentes do mesmo registro é fila contando errado.

PG → CI → PG Cadastro manual de dívida

Lançamento de operador vai à aprovação do CI e volta com aprovador e data. “Cadastro Manual” não é conector do catálogo — é origem de lançamento, e por isso não aparece entre as fontes externas.

CI → PG Catálogo de conectores

O CI publica status, ambiente e método; o PG lê e obedece. Catálogo não publicado devolve ausência de leitura, nunca “ativo” — dizer ativo para conector que ninguém declarou é pior que dizer que não se leu.

PG → CI Trilha de eventos

Cada ato que atravessa um conector publica evento com tela, referência e autor. É trilha, não decisão: nenhum evento aqui muda status de conector.

CADIN e SERASA são o padrão de referência

As duas medidas já operavam assim: elegibilidade e ato no PG, conector e credencial no CI, retirada voltando pela mesma via. Os cinco canais acima reproduzem essa forma — não criam outra.

O que a ponte não faz

Não cria registro dos dois lados por conta própria: só espelha o que existe. Não funde as bases — cada lado segue dono do que é só dele. E não decide: alçada e ato permanecem de quem os tem.

Alcance no PC

O Portal do Contribuinte não lê estes canais: ele vê o efeito — situação do crédito, guia, protocolo. A decisão do CI chega a ele pelo PG, que continua sendo o sistema de registro.

Centro de Integrações camada transversal

Linha pontilhada = integração externa. Fontes marcadas em âmbar não têm conector comprovado na aplicação e ficam como INTEGRAÇÃO A VALIDAR.

Vedações da camada de integração

O Centro de Integrações provê canal, credencial e trilha. Não emite CDA, não inscreve em dívida ativa, não cria campanha, não comunica por conta própria, não aprova medida e não pratica ato de cobrança. Toda decisão pertence ao módulo de negócio; todo ato com efeito jurídico pertence à autoridade competente.

16 · Mapa de governança e alçadas

Classificação de cada ação por modo de execução. Nenhum agente automatizado aprova medida com efeito jurídico.

Camada de governança — Configurações

Gestão de Usuários e Perfis e Permissões operam como camada transversal: RBAC, hierarquia, alçada, segregação de funções, permissões por módulo, ações permitidas e ações proibidas. Toda ação relevante registra usuário, perfil, data e efeito na trilha de auditoria. O escopo por ente e por fundo é requisito da operação multi-ente e está declarado como pendente de modelagem.

17 · Inconsistências encontradas

Auditoria da estrutura: submenu sem origem ou destino, informação sem retorno, cadastro paralelo, fluxo interrompido, ligação ausente, ação sem alçada. {{ achadosQtd }} achados classificados.

Onde aparece. {{ a.onde }}

Encaminhamento. {{ a.acao }}

18 · Recomendações de arquitetura

Em ordem de precedência. Nenhuma exige alterar funcionalidade existente antes da aprovação deste mapa.

19 · O que foi fechado desde este mapa — 13/09/2026, atualizado em 19/09/2026 (ciclo financeiro-contábil)

Elos que o mapa apontava como interrompidos e passaram a existir em código. Cada linha traz o módulo que o sustenta e a verificação que o comprova. Os oito primeiros são o ciclo financeiro-contábil, fechado em 19/09/2026: do pagamento no banco à escrituração e ao fechamento do período — o trecho que este mapa apontava como o vazio maior do ecossistema. Os cinco seguintes entraram entre 17 e 19/09/2026 e três deles não são elo do ciclo de cobrança — são autoridade de acesso, cadastro de tipo e projeto de implantação; entram aqui porque respondem à mesma pergunta. Todos trazem a ressalva que lhes cabe: foram conferidos na tela, não por verificação automatizada própria — e essa diferença fica dita, porque “verificado” e “conferido” não são a mesma prova.

FECHADO {{ f.titulo }} {{ f.cadeia }}

Estava assim. {{ f.antes }}

Ficou assim. {{ f.depois }}

Onde vive. {{ f.onde }}

Verificação: {{ f.verif }}

Continua em aberto — e por quê

A régua não ganhou motor novo — ganhou entradas

A Esteira nunca teve fila gravada: a etapa de cada CDA é derivada a cada leitura pela precedência de estado. Reavaliar a política depois de cada evento já era o comportamento — o que faltava era o fato novo chegar até ela. Acordo do Portal e pagamento conciliado agora entram nessa precedência como qualquer outro estado, e é só isso que mudou. Nenhuma segunda lógica de cobrança foi criada fora do PG: quem decide continua sendo a ordem de precedência, que é a Política de Crédito em código.

Relatório de arquitetura · não altera o sistema nem os relatórios anteriores · nomes de menu e submenu lidos da aplicação · documentos irmãos: docs/RELATORIO_JORNADA_COBRANCA.md · docs/AUDITORIA_INTEGRACAO_BASES.md · docs/AUDITORIA_CI_PG_PC.md