É a base de todo o resto. Quem é o cidadão, quais são as unidades, quem são os servidores, que empresas existem no município — e quem pode ver o quê.
O sistema nasceu no hospital, onde "pessoa" era só paciente. Hoje a mesma pessoa é paciente, contribuinte, aluno e servidor — em cadastros separados, sem vínculo, com endereço em vocabulários diferentes.
O cadastro único resolve isso: aqui fica o que é da pessoa — nome, documentos, filiação, contato e onde mora. O que é do vínculo fica no vínculo: cartão SUS e alergia no paciente, inscrição municipal no contribuinte.
A chave é o identificador interno, não o CPF. CPF é dado, não identidade: é digitado errado, muda por decisão judicial, e o recém-nascido só ganha o dele semanas depois do primeiro atendimento. Se o vínculo guardasse o CPF, corrigir um dígito quebraria a ligação com todos os atendimentos daquela pessoa.
A base já mostra o caso: o mesmo CPF aparece em quatro prefeituras diferentes. É a mesma pessoa atendida em quatro municípios, cada um com seu cadastro.
Um índice global recusaria isso e — pior — deixaria um município enxergar o cidadão do outro.
A defesa contra duplicidade tem quatro camadas:
O cidadão é editado de vários lugares: a tela do cadastro manda tudo, o atendimento manda o endereço, o contribuinte manda o contato.
Montar o registro inteiro a cada gravação faria a tela que manda pouco apagar o que as outras preencheram.
Por isso só se grava o que veio na requisição — inclusive o nome, que se fosse gravado sempre escreveria vazio por cima do cadastro.
Quem entra é o munícipe pelo navegador, sem usuário do sistema. A identificação é CPF e data de nascimento, conferidos a cada chamada.
Não é autenticação forte e não pretende ser: é o que separa "digitei um CPF" de "sou o dono deste CPF".
Três decisões sustentam isso:
O cadastro de fornecedores responde "quem é a empresa X?". O diretório responde a pergunta que o comprador público realmente faz.
A diferença não é cosmética: o comprador não sabe o código de atividade de material de limpeza, não sabe como o fornecedor descreveu a própria atividade, e não vai procurar por "COMÉRCIO VAREJISTA DE ARTIGOS DE LIMPEZA E HIGIENE". Ele digita "material de limpeza" — e a busca precisa achar.
E a busca é declarada, não semântica — de propósito. Uma busca por similaridade acertaria mais, mas não teria como explicar por que a empresa A apareceu antes da B. Num diretório que orienta compra pública, isso é exatamente o que não se pode ter: ranqueamento opaco de fornecedor é direcionamento por outro nome.
Ir para a tela: Tipos de fornecimento
Os tipos eram fixos. Agora vivem no banco, e o município cria os seus: quem compra muito material de construção quer "Depósito de material" separado de "Fornecedor" genérico — e antes precisava pedir alteração de código para isso.
As áreas continuam fixas, e é decisão consciente: área corresponde a módulo do sistema. Deixar criar área nova produziria tipo que nenhuma tela consegue usar, porque a listagem de cada módulo filtra pela área dele.
Toda consulta filtra por município. Aqui isso é mais grave que em outros módulos, porque a lista inclui e-mail e permissão.
Uma demonstração com os dados do seu município mostra melhor que qualquer descrição. Sem compromisso.