| Data de elaboração | 30/06/2026 |
| Responsável pelo estudo | Rodrigo Stefano Sales Nascimento (Assessor) |
| Equipe do estudo | CAOS |
| Alvo | Sistema Governa - RH |
| Origem | Card FPAGAMENTO-2720 — utilizar a data de cadastro das verbas periódicas (vencimento/representação) como base do cálculo proporcional de pagamento. |
| Objetivo | Verificar como o sistema calcula hoje o pagamento proporcional do servidor, confirmar com dados reais se é viável usar a data das verbas como base, e indicar a alternativa mais consistente para subsidiar a decisão de negócio e o planejamento da implementação. |
Quando um servidor inicia o exercício no meio do mês, ele não recebe o valor cheio das verbas daquele mês — recebe proporcionalmente aos dias trabalhados. O valor mensal é dividido por uma base de 30 dias e multiplicado pelos dias de exercício no mês.
A pergunta central deste estudo é qual data marca o início do servidor para esse cálculo:
O cálculo proporcional não é exclusivo de comissionados — vale para qualquer servidor novo (concursado ou comissionado) que possua verbas proporcionais. Um concursado, por exemplo, recebe o proporcional sobre o vencimento do seu cargo efetivo, que é uma verba diferente do «vencimento CDS».
Quem decide se uma verba é proporcional é uma flag de configuração (getProporcional(), gravada na tabela VERBA_ROTINA), não a descrição. No cálculo (CalculoProporcionalidade.java:69), só entram as verbas com essa marca:
if (verba.getProporcional()) { // só verbas marcadas como proporcionais
novoValor = valor / 30 * totalDiasEfetivo; // proporcional aos dias trabalhados
}
Exemplos de proventos que costumam ser proporcionais (variam por servidor):
| Provento | Quem costuma ter |
|---|---|
| Vencimento (do cargo efetivo ou CDS) | Todo servidor |
| Representação CDS | Comissionados |
| Auxílio saúde condicional e similares | Conforme adesão |
calculoPagamentoFolha.xhtml — Movimentação Mensal> Folha de Pagamento> Cálculo> Executar.lancarVerbaPeriodica.xhtml — Movimentação Mensal> Verba Periódica> Verba Periódica.Todo o proporcional parte de uma única data: a de admissão, em três etapas dentro de CalculoPagamentoFolha.java (módulo governa-rh-calculo).
| Etapa | Onde no código | O que faz |
|---|---|---|
| 1 | calcularTotalDiasAReceber (definição ~linha 2059; chamado em 435 e 1103) |
Recebe a data de admissão (getAdmissaoData()) e calcula os dias trabalhados no mês |
| 2 | CalculoProporcionalidade.calcularProporcionalidade (chamada ~linha 602) |
Aplica a proporção às verbas marcadas como proporcionais, e só quando o servidor tem menos de 30 dias e é categoria mensal |
| 3 | Bloco de verbas periódicas (~linhas 626-628) | Tratamento à parte, só quando a competência (mês/ano) da folha ≠ a competência da admissão |
Etapa 1 — calcula os dias do servidor:
// totalDiasAdmissao = dias do mês ANTES de o servidor entrar
totalDiasAdmissao = DateUtil.calcularDiferencaDias(primeiroDiaDoMes, admissao) - 1;
// totalDiasEfetivo = dias trabalhados = 30 menos os dias de ausência no mês
totalDiasEfetivo = 30 - totalDiasAdmissao - totalDiasComissionado - totalDiasFerias - totalDiasDesligamento;
Etapa 2 — aplica a proporção em cada verba:
novoValor = valor / 30; // valor de 1 dia (base 30 fixa, TOTAL_DIAS_MES)
novoValor = novoValor * totalDiasEfetivo; // x dias trabalhados
📌 A mesma régua é aplicada a todas as verbas proporcionais. Para servidor comissionado, o multiplicador é
totalDiasComissionadono lugar detotalDiasEfetivo; o restante é idêntico.
Exemplo: servidor admitido dia 10 → trabalhou 21 dias (30 − 9) → verba de R$ 30 vira 30 / 30 × 21 = R$ 21.
É justamente esse «uma data só, e que é a de admissão» que o card quer substituir.
Etapa 3 — verbas periódicas fora do mês de admissão:
As Etapas 1 e 2 cuidam do mês em que o servidor entrou. Mas uma verba periódica tem datas próprias de início e fim (inicio/fim), independentes da admissão. Pode acontecer de o servidor já ser antigo e uma verba dele começar (ou terminar) no meio de outro mês. Nesse caso a régua «30 − dias de admissão» não vale — só aquela verba precisa ser proporcionalizada, pelos dias dela no mês.
O sistema separa os dois casos pela competência (yyyyMM):
// "a competência da folha é diferente do mês/ano da admissão?"
if (!formatarData(admissao, "yyyyMM").equals(mesReferencia)) {
// → não é o mês de entrada: proporcionaliza a verba periódica pela data DELA
}
📌 Resumo: Etapa 1+2 = proporcional pela data de entrada, no mês de admissão. Etapa 3 = proporcional de uma verba periódica pela data da própria verba, em outro mês.
Pedido: calcular o proporcional do servidor novo usando a data de cadastro da verba periódica no lugar da admissão.
Suposição implícita: o pedido só funciona se cada servidor tiver uma data única para essas verbas. Antes de implementar, foi preciso confirmar no banco se essa premissa é verdadeira.
Pergunta levada ao banco: «Existe servidor com vencimento CDS e representação CDS que começaram em datas diferentes?»
Todas as consultas são somente leitura, com
WITH (NOLOCK)em todas as tabelas, para não gerar lock na base.
WITH verba_alvo AS (
SELECT v.id,
CASE WHEN v.descricao LIKE 'VENCIMENTO CDS%' THEN 'VENCIMENTO'
WHEN v.descricao LIKE 'REPRESENTA%CDS%' THEN 'REPRESENTACAO' END AS tipo_alvo
FROM rh.verba v WITH (NOLOCK)
WHERE (v.descricao LIKE 'VENCIMENTO CDS%' OR v.descricao LIKE 'REPRESENTA%CDS%')
AND v.descricao NOT LIKE 'Nao Util%' AND v.classificacao <> 'DIF'
),
periodicas AS (
SELECT vp.matricula, va.tipo_alvo, vp.inicio
FROM rh.verba_periodica vp WITH (NOLOCK)
JOIN verba_alvo va ON va.id = vp.id_verba
)
SELECT matricula,
MIN(CASE WHEN tipo_alvo='VENCIMENTO' THEN inicio END) AS inicio_vencimento,
MIN(CASE WHEN tipo_alvo='REPRESENTACAO' THEN inicio END) AS inicio_representacao
FROM periodicas
GROUP BY matricula
HAVING COUNT(DISTINCT tipo_alvo)=2
AND MIN(CASE WHEN tipo_alvo='VENCIMENTO' THEN inicio END)
<> MIN(CASE WHEN tipo_alvo='REPRESENTACAO' THEN inicio END);
Resultado: SIM, e em grande quantidade. Exemplos retornados:
| Matrícula | Início do Vencimento | Início da Representação |
|---|---|---|
| 300077904 | 01/01/2026 | 01/08/2008 |
| 300013961 | 01/12/2013 | 01/06/2000 |
| 300000167 | 01/02/2011 | 01/06/2000 |
Servidor 300213096, admitido em 04/11/2025. Suas verbas CDS:
| Código | Verba | Início | Valor |
|---|---|---|---|
| 1703 | VENCIMENTO CDS-04 | 01/12/2025 | R$ 274,56 |
| 1715 | REPRESENTAÇÃO CDS-04 | 02/12/2025 | R$ 2.471,04 |
DECLARE @matricula INT = 300213096;
SELECT vp.matricula, v.codigo, v.descricao AS verba,
vp.inicio AS data_inicio, vp.fim AS data_fim, vp.valor
FROM rh.verba_periodica vp WITH (NOLOCK)
JOIN rh.verba v WITH (NOLOCK) ON v.id = vp.id_verba
WHERE vp.matricula = @matricula
AND (v.descricao LIKE '%VENCIMENTO%' OR v.descricao LIKE '%REPRESENTA%')
ORDER BY vp.inicio;
| Constatação | Implicação para o card |
|---|---|
| Vencimento e representação têm datas de início diferentes no mesmo servidor | Não existe «a data da verba» — existem várias por servidor |
| Ter as duas verbas juntas é o normal do cargo CDS (não é erro) | A premissa do card de «uma verba por servidor» não se sustenta |
| A data da verba é digitada manualmente no lançamento, depois da entrada | É um dado frágil, inadequado como base oficial do cálculo |
Conclusão: a regra, do jeito que está escrita, não pode ser atendida — ela pressupõe uma data única que não existe nos dados.
Existe uma data que é uma só, oficial: a data de efetivo exercício, gravada na posse, quando o servidor entra em exercício.
| Data da verba | Data de efetivo exercício | |
|---|---|---|
| Datas por servidor | Várias (uma por verba) | Uma só |
| Origem | Digitada em cada lançamento | Campo oficial, gravado na posse |
| Cálculo | Cada verba prorrateia diferente → inconsistente | Mesma régua para tudo → consistente |
Servidores novos (admitidos desde 2023):
WITH alvo AS (
SELECT DISTINCT vp.id_servidor
FROM rh.verba_periodica vp WITH (NOLOCK)
JOIN rh.verba v WITH (NOLOCK) ON v.id = vp.id_verba
WHERE (v.descricao LIKE 'VENCIMENTO CDS%' OR v.descricao LIKE 'REPRESENTA%CDS%')
AND v.descricao NOT LIKE 'Nao Util%' AND v.classificacao <> 'DIF'
)
SELECT COUNT(*) AS total,
SUM(CASE WHEN s.data_efetivo_exercicio IS NOT NULL THEN 1 ELSE 0 END) AS com_efetivo,
SUM(CASE WHEN s.data_efetivo_exercicio IS NULL THEN 1 ELSE 0 END) AS sem_efetivo
FROM alvo a JOIN rh.servidor s WITH (NOLOCK) ON s.id = a.id_servidor
WHERE s.admissao >= '2023-01-01';
| Situação | Servidores | % |
|---|---|---|
| Com efetivo exercício | 6.010 | ~85% |
| Sem efetivo exercício | 1.096 | ~15% |
| Total | 7.106 | 100% |
A grande maioria dos servidores novos já tem a data. Para os ~15% sem, a regra usa um fallback: se não houver efetivo exercício, usa a data de admissão (comportamento atual).
PROC_EMPOSSAR_CONCURSO) a procedure grava admissao = GETDATE().NULL); ele só é gravado em outros fluxos (reempossamento, nomeação/edição do cadastro). É justamente esse o caso dos ~15% que caem no fallback.Por isso a data de entrada (efetivo exercício, com fallback de admissão) representa de fato quando o servidor começou, enquanto a data da verba é um lançamento operacional posterior.
Conclusão: a regra do card, na forma escrita (proporcional pela data da verba), é inviável — não há uma data única de verba por servidor, e a data lançada é frágil. Mas a intenção do card (que o proporcional reflita o início real, não a admissão genérica) é legítima e atendível.
Recomendação: usar a data de efetivo exercício como base do proporcional, com fallback para a data de admissão quando ela não existir. Uma data única, oficial e auditável — resolve o card de forma simples, previsível e de baixo risco.
data_efetivo_exercicio (com fallback para admissão)