No sistema Governa, a matrícula serve como um identificador importante para cada servidor, sendo obrigatória e única dentro do contexto de um registro. Entretanto, o sistema permite que um servidor tenha mais de uma matrícula em casos específicos, como diferentes vínculos ou cargos. No código a seguir, retirado do arquivo Servidor.java, a matrícula é definida como um campo obrigatório e único por registro.
Arquivo: Servidor.java
@Column(name = "matricula", nullable = false, unique = true)
private Long matricula;
nullable = false: A matrícula não pode ser nula, sendo um campo obrigatório.unique = true: Define a matrícula como única para o registro, mas não impede a criação de múltiplos registros com matrículas distintas para o mesmo servidor.Cada registro de servidor no Governa está vinculado a uma empresa específica. A associação é feita através de uma relação de «muitos para um», permitindo que múltiplos registros de servidores sejam associados a uma mesma empresa.
Arquivo: Servidor.java
@ManyToOne
@JoinColumn(name = "id_empresa", referencedColumnName = "id")
private Empresa empresa;
@ManyToOne: Define a relação «muitos para um» entre servidores e empresas.@JoinColumn: Especifica a coluna de junção com a entidade Empresa.Para garantir que as novas matrículas sejam sequenciais, o sistema consulta a maior matrícula já registrada para a empresa. Isso permite que a próxima matrícula gerada seja única no contexto da empresa, mantendo uma sequência ordenada.
Arquivo: IServidorRepositorio.java
@Query("SELECT Max(matricula) FROM Servidor ser WHERE ser.empresa.id = :idEmpresa")
Long findMaiorMatricula(@Param("idEmpresa") Long idEmpresa);
Max(matricula): Obtém a maior matrícula registrada para a empresa especificada.Após encontrar a maior matrícula existente para uma empresa, o sistema gera uma nova matrícula incrementando o valor encontrado. Se não houver matrículas registradas, o sistema inicia com o valor 1.
Arquivo: ServidorBO.java
// Busca a maior matrícula existente para a empresa
Long maiorMatricula = servidorRepositorio.findMaiorMatricula(empresaId);
// Incrementa a maior matrícula ou define como 1, se não houver matrícula
Long novaMatricula = maiorMatricula != null ? maiorMatricula + 1 : 1L;
// Atribui a nova matrícula ao servidor
servidor.setMatricula(novaMatricula);
findMaiorMatricula: Busca a maior matrícula para a empresa.maiorMatricula + 1: Incrementa o valor para criar uma nova matrícula única.O sistema verifica se já existe um registro de servidor com a mesma matrícula para evitar duplicidade.
Arquivo: ServidorBO.java
// Busca servidor pela matrícula
Servidor servidorRecuperado = this.buscarPorEmpresaEMatricula(servidor.getEmpresa().getId(), servidor.getMatricula());
// Se o servidor já existir com a mesma matrícula
if (servidorRecuperado != null) {
// Lança uma exceção para impedir duplicidade
throw new RestricaoNegocioExcecao("Matrícula já existente.");
}
buscarPorEmpresaEMatricula: Busca registros de servidor pela matrícula e empresa.No sistema Governa, a geração de matrícula segue uma sequência local para cada empresa, permitindo o cadastro de múltiplas matrículas para o mesmo servidor quando necessário. O processo é resumido em:
Durante a análise dos códigos do sistema Governa e das procedures disponíveis no banco de dados, não foi encontrada nenhuma lógica que implemente a separação automática de matrículas por faixas específicas, como mencionado nos requisitos (ex.: (1- PM, 2- Bombeiro, 3- Servidor)).
Aparentemente, o sistema Governa utiliza apenas a abordagem sequencial para a geração de matrículas, onde cada nova matrícula é atribuída conforme o próximo número disponível, sem distinção de categorias de servidores.
No entanto, o sistema Governa permite que o usuário informe a matrícula manualmente no momento do cadastro. Essa flexibilidade pode justificar a diferença de faixa de matrícula observada nas numerações das matrículas dos servidores e informada nos requisitos do estudo.
Foi realizada uma busca no banco de dados de treinamento do sistema Governa para identificar as faixas de matrículas em uso. A análise revelou que, aparentemente, apenas as faixas 1000, 2000 e 3000 possuem servidores registrados conforme pode-se observar na imagem abaixo.

O campo de matrícula é amplamente referenciado no sistema Governa. Qualquer alteração nesse campo pode gerar impacto em diversas áreas do sistema.
Abaixo, está a listagem das tabelas que utilizam a coluna de matrícula no banco de dados do Governa, demonstrando o alto grau de dependência e a complexidade que mudanças nesse campo poderiam gerar.


No sistema e-Estado, a matrícula é um campo obrigatório para cada servidor, mas segue uma lógica de geração baseada em faixas numéricas definidas para diferentes tipos de vínculo (ex.: 07 - Estagiário, 09 - Celetista Temporário, 310 - Servidor público eventual, etc… ). Essas faixas foram implementadas para categorizar os servidores conforme o vínculo, estabelecendo um intervalo numérico específico para cada categoria. Assim, a matrícula no e-Estado não é apenas um identificador único, mas também reflete a natureza do vínculo do servidor.
A lógica de faixas de matrícula é uma característica essencial no e-Estado. Para cada tipo de vínculo, o sistema reserva um intervalo de números — uma faixa de matrícula específica. Esse intervalo é definido com um número inicial e um número final, garantindo que todas as matrículas para um tipo de vínculo permaneçam dentro de uma faixa predefinida. Quando um servidor é registrado com um vínculo específico, o sistema automaticamente verifica a última matrícula utilizada dentro daquela faixa e gera uma nova matrícula sequencial.
Arquivo: Reserva_matricula.php
public function get_matricula() {
$this->db->select('s.matricula as ultima_matricula_na_reserva, reserva.reserva_inicial, reserva.reserva_final');
$this->db->from('configuracoes.reserva_matricula reserva');
$this->db->join('recursos_humanos.servidor s', 's.matricula >= reserva.reserva_inicial AND s.matricula <= reserva.reserva_final', 'left');
$this->db->where('reserva.tipo_vinculo_id', $this->tipo_vinculo_id);
$this->db->order_by('s.matricula', 'desc');
$this->db->limit(1);
$query = $this->db->get()->row();
return $query;
}
Neste trecho, o sistema busca a última matrícula usada na faixa destinada ao tipo de vínculo do servidor. Assim, ele determina a próxima matrícula a ser gerada.
Quando um novo servidor é registrado, o sistema busca a maior matrícula usada dentro da faixa numérica reservada para o vínculo do servidor, garantindo que a nova matrícula fique dentro dos limites estabelecidos.
Arquivo: Reserva_matricula.php
$proxima_matricula = ($query->ultima_matricula_na_reserva == null ? $query->reserva_inicial : ($query->ultima_matricula_na_reserva + 1));
if ($proxima_matricula > $query->reserva_final) {
$this->session->set_flashdata('msg', 'error_faixa_matricula_esgotada');
return false;
}
Aqui, o sistema calcula a próxima matrícula de acordo com a última usada:
O e-Estado valida cada matrícula gerada para garantir que permaneça dentro do limite da faixa definida. Caso a nova matrícula exceda o reserva_final, o sistema impede a criação e retorna uma mensagem de erro.
A estrutura de faixas no e-Estado permite uma organização por tipo de vínculo, facilitando a categorização dos servidores e o controle de dados segmentados. Diferente do Governa, que utiliza uma sequência única sem divisão por faixas e onde aparentemente esta divisão se dá de forma manual, o e-Estado gera matrículas específicas que possibilitam uma identificação rápida do tipo de vínculo do servidor. Contudo, essa segmentação também pode criar múltiplas matrículas para um mesmo servidor caso ele ocupe diferentes vínculos ao longo do tempo, o que precisa ser considerado em qualquer tentativa de integração ou unificação entre sistemas.
O fluxo de geração de matrícula no e-Estado consiste nos seguintes passos:
Durante a análise no banco de desenvolvimento do e-Estado, foi verificada a utilização de faixas de numeração para as matrículas dos servidores, evidenciando uma estrutura mais ampla e separada por tipo de vínculo, ao contrário do Governa. Na consulta realizada, foram encontrados registros em todas as faixas de numeração verificadas: 1000, 2000, 3000, 4000, 5000, 6000, 7000, 8000 e 9000. Conforme pode-se observar na imagem abaixo.

Tipos de vínculos identificados no e-Estado:
| ID | Nome |
|---|---|
| 6 | Estatutário militar comissionado |
| 7 | Estagiário |
| 8 | Federal |
| 5 | Estatutário Efetivo Militar |
| 4 | Estatutário em Comissão |
| 10 | Celetista Indeterminado |
| 9 | Celetista Temporário |
| 13 | Inativo |
| 14 | Pensionista |
| 15 | Agente Político |
| 17 | Cedido |
| 18 | Voluntário |
| 19 | Tutor |
| 12 | Externo |
| 20 | Empresas Públicas |
| 3 | Estatutário Efetivo |
| 22 | Menor Aprendiz - CIEE |
| 101 | Empregado - Geral, inclusive o empregado público da administração direta ou indireta contratado pela CLT |
| 201 | Avulso |
| 202 | Avulso |
| 501 | Segurado Especial |
| 102 | Empregado - Trabalhador rural por pequeno prazo da Lei 11.718/2008 |
| 103 | Empregado - Aprendiz |
| 104 | Empregado - Doméstico |
| 105 | Empregado - Contrato a termo firmado nos termos da Lei 9.601/1998 |
| 106 | Trabalhador temporário - Contrato nos termos da Lei 6.019/1974 |
| 107 | Empregado - Contrato de trabalho Verde e Amarelo - sem acordo para antecipação mensal da multa rescisória do FGTS |
| 108 | Empregado - Contrato de trabalho Verde e Amarelo - com acordo para antecipação mensal da multa rescisória do FGTS |
| 303 | Exercente de mandato eletivo |
| 111 | Empregado - Contrato de trabalho intermitente |
| 301 | Servidor público titular de cargo efetivo, magistrado, ministro de Tribunal de Contas, conselheiro de Tribunal de Contas e membro do Ministério Público |
| 302 | Servidor público ocupante de cargo exclusivo em comissão |
| 304 | Servidor público exercente de mandato eletivo, inclusive com exercício de cargo em comissão |
| 305 | Servidor público indicado para conselho ou órgão deliberativo, na condição de representante do governo, órgão ou entidade da administração pública |
| 306 | Servidor público contratado por tempo determinado, sujeito a regime administrativo especial definido em lei própria |
| 307 | Militar |
| 308 | Conscrito |
| 309 | Agente público - Outros |
| 310 | Servidor público eventual |
| 311 | Ministros, juízes, procuradores, promotores ou oficiais de justiça à disposição da Justiça Eleitoral |
| 312 | Auxiliar local |
| 313 | Servidor público exercente de atividade de instrutoria, capacitação, treinamento, curso ou concurso, ou convocado para pareceres técnicos ou depoimentos |
| 401 | Dirigente sindical - Informação prestada pelo sindicato |
| 410 | Trabalhador cedido/exercício em outro órgão/juiz auxiliar - Informação prestada pelo cessionário/destino |
| 701 | Contribuinte individual - Autônomo em geral, exceto se enquadrado em uma das demais categorias de contribuinte individual |
| 711 | Contribuinte individual - Transportador autônomo de passageiros |
| 712 | Contribuinte individual - Transportador autônomo de carga |
| 721 | Contribuinte individual - Diretor não empregado, com FGTS |
| 722 | Contribuinte individual - Diretor não empregado, sem FGTS |
| 723 | Contribuinte individual - Empresário, sócio e membro de conselho de administração ou fiscal |
| 731 | Contribuinte individual - Cooperado que presta serviços por intermédio de cooperativa de trabalho |
| 734 | Contribuinte individual - Transportador cooperado que presta serviços por intermédio de cooperativa de trabalho |
| 738 | Contribuinte individual - Cooperado filiado a cooperativa de produção |
| 741 | Contribuinte individual - Microempreendedor individual |
| 751 | Contribuinte individual - Magistrado classista temporário da Justiça do Trabalho ou da Justiça Eleitoral que seja aposentado de qualquer regime previdenciário |
| 761 | Contribuinte individual - Associado eleito para direção de cooperativa, associação ou entidade de classe de qualquer natureza ou finalidade, bem como o síndico ou administrador eleito para exercer atividade de direção condominial, desde que recebam remuneração |
| 771 | Contribuinte individual - Membro de conselho tutelar, nos termos da Lei 8.069/1990 |
| 781 | Ministro de confissão religiosa ou membro de vida consagrada, de congregação ou de ordem religiosa |
| 901 | Estagiário |
| 902 | Médico residente ou residente em área profissional de saúde |
| 903 | Bolsista |
| 904 | Participante de curso de formação, como etapa de concurso público, sem vínculo de emprego/estatutário |
| 906 | Beneficiário do Programa Nacional de Prestação de Serviço Civil Voluntário |
A unificação da geração de matrículas entre o Governa e o e-Estado apresenta desafios significativos devido às diferenças nas estruturas e nas lógicas de matrícula de cada sistema.
No Governa, é comum que servidores tenham múltiplas matrículas, e muitas das vezes mais de uma matrícula ativa simultaneamente, porém baseado no estudo do código, aparentemente não há como programaticamente fazer a identificação de qual tipo de vínculo é aplicado a cada matrícula específica de um servidor.
Governa: Utiliza uma matrícula única por servidor dentro de uma empresa, mas permite múltiplas matrículas por servidor, cada uma potencialmente representando uma relação de vínculo ou contrato distinta.
e-Estado: Baseia-se em faixas de matrícula para cada tipo de vínculo, o que facilita a segmentação, mas impede uma correspondência direta com o modelo de dados do Governa.
A unificação exigiria consolidar dados históricos fragmentados no Governa, onde múltiplas matrículas por servidor representam diferentes períodos, vínculos ou cargos. No e-Estado, a separação por faixas cria um registro ordenado por tipo de vínculo, dificultando a fusão com o modelo do Governa sem perda de contexto.
Identificar e consolidar vínculos é uma tarefa complexa, especialmente no Governa, onde muitos servidores possuem mais de uma matrícula e alguns deles têm até 16 matrículas e inclusive com mais de uma matrícula ativa. A falta de uma associação clara entre cada matrícula e seu tipo de vínculo no governa, pode torna esta unificação arriscada.
As matrículas provavelmente são usadas como identificadores em sistemas interligados. Modificar faixas e unificar a lógica de matrículas exigiria ajustes em todos esses sistemas para evitar inconsistências e interrupções nos serviços.
A complexidade da unificação entre Governa e e-Estado reside na necessidade de compatibilizar múltiplas matrículas por servidor com a lógica de faixas de vínculo do e-Estado. A transição requeriria uma estratégia de mapeamento e auditoria rigorosa para garantir a integridade dos dados e evitar a perda de informações críticas relacionadas aos dados históricos dos servidores.
A regra de geração de matrículas no sistema e-Estado é baseada em faixas numéricas designadas para diferentes tipos de vínculo, facilitando a categorização dos servidores de acordo com a natureza de seu vínculo (ex.: 07 - Estagiário, 09 - Celetista Temporário, 310 - Servidor público eventual, etc… ). No entanto, aplicar diretamente essa lógica ao sistema Governa, que possui uma estrutura mais simplificada e não adota faixas por tipo de vínculo, apresenta dificuldades. A adaptação para esse modelo poderia comprometer a integridade dos dados e a organização dos vínculos, dado que o Governa permite múltiplas matrículas sem amarração direta a tipos específicos de vínculo.
A unificação de múltiplas matrículas por servidor, especialmente no contexto do Governa, apresenta um desafio considerável. A presença de servidores com várias matrículas — algumas ativas simultaneamente — indica diferentes vínculos, contratos ou períodos de serviço. Consolidar essas informações em uma única matrícula poderia causar perda de dados relevantes sobre o histórico e os direitos do servidor.
Além disso, para unificar as matrículas, seria necessário rastrear e validar todas as associações de vínculos para cada matrícula, tarefa que demandaria auditoria minuciosa. Essa unificação, embora tecnicamente possível, traz riscos altos de inconsistência nos registros e exige esforços significativos para garantir que cada vínculo seja corretamente identificado e preservado no sistema consolidado.
A implementação de restrições por faixa de matrícula no Governa implicaria na necessidade de categorizar servidores de acordo com diferentes grupos (ex: PM, Bombeiro, Servidor). Embora possível, essa abordagem exigiria reclassificar matrículas existentes para garantir que cada uma respeite a faixa associada ao vínculo do servidor. Esse ajuste poderia impactar processos administrativos que atualmente não dependem de categorização explícita por faixa.
Além disso, estabelecer faixas para matrículas existentes implica alterações no fluxo de geração e consulta de matrículas, o que pode demandar modificações nos sistemas interligados. A implementação de faixas como no e-Estado resultaria em um esforço de adaptação considerável.
Expandir os três primeiros dígitos da matrícula para representar diferentes categorias no intuito de unificar os sistemas Governa e e-Estado apresenta desafios consideráveis. Esse ajuste exigiria uma revisão na estrutura de identificação dos servidores para evitar sobreposição entre matrículas de categorias distintas. A reutilização das matrículas atuais sem gerar duplicidades ou inconsistências requer uma auditoria detalhada e, possivelmente, adaptações nos sistemas e processos que utilizam a matrícula como identificador principal. Embora teoricamente viável, essa abordagem exigiria uma transição complexa, com impactos nos registros históricos, nos processos de geração de matrículas e nos sistemas integrados.