Como o RH.Me realiza seus cálculos

Essa separação é intencional. Máscaras no navegador ajudam a digitar, mas a autoridade final está no servidor. Campos críticos são validados novamente em PHP antes do resultado.

Computadores representam muitos números decimais de forma aproximada quando usam ponto flutuante. Em cálculos monetários repetidos, isso pode gerar diferenças residuais. O RH.Me converte operações críticas para centavos inteiros sempre que o motor permite.

Esse cuidado é protegido por testes e golden masters: um centavo de diferença em um cenário homologado é tratado como regressão, não como “aproximação aceitável”.

INSS e IRRF mudam ao longo do tempo. Por isso as tabelas ficam associadas à competência. Se o sistema não possui uma tabela válida, o comportamento esperado é bloquear e exigir atualização — não usar silenciosamente o ano anterior.

Quando a classificação não é segura, a revisão humana é parte do processo. Automatizar não significa mascarar incerteza.

A interface possui navegação, botões, marca e mensagens de apoio. O documento oficial não. O projeto separa a prévia do resultado final e utiliza geração vetorial própria para os documentos homologados.

A edição Free não mantém cadastro persistente de empresas, colaboradores, histórico ou PDFs emitidos. A sessão suporta o fluxo temporário e formulários sensíveis usam CSRF validado no servidor. Código que não precisa ser público é separado do webroot dentro da arquitetura da aplicação.

Um princípio central é bloquear ou sinalizar situações fora da regra implementada. Férias em dobro, calendários de feriados completos, particularidades de instrumentos coletivos e interpretações jurídicas não devem ser resolvidos por suposição silenciosa.

Essa postura parece menos “mágica”, mas é mais útil: em RH, uma resposta transparente vale mais que uma automação confiante e errada.

Um cenário homologado possui entradas conhecidas e resultado esperado. Quando uma alteração de código muda esse resultado, o teste falha e exige revisão. Isso protege especialmente cálculos de INSS, IRRF, férias e totais monetários.

O objetivo não é impedir evolução, e sim evitar que uma correção visual mude um cálculo sem que ninguém perceba.

Quando uma tabela muda, o dado da competência é atualizado em arquivo próprio e passa por testes. O mesmo princípio vale para rubricas e regras de documentos. Releases homologadas são tratadas como baseline para permitir comparação e rollback.

Formatar CPF, CNPJ, CEP ou moeda melhora a experiência, mas o navegador pode ser manipulado. Por isso o backend volta a validar os dados críticos. O frontend orienta; o servidor decide se a requisição é aceitável.

Nos fluxos de férias e documentos, a aplicação usa o padrão POST → 303 → GET. Depois de processar o formulário, o navegador recebe uma URL de prévia. Assim, atualizar a página não precisa repetir automaticamente a operação enviada.

Quando falta tabela tributária, quando um fracionamento deixa saldo impossível ou quando uma data obrigatória não existe, o sistema deve sinalizar. Esse comportamento reduz o risco de um resultado aparentemente completo carregar uma hipótese que o usuário nunca informou.

Tributos, layouts e orientações oficiais mudam. Por isso a metodologia trata competência e versão como parte do cálculo e mantém fontes oficiais como referência editorial. Uma tabela correta em janeiro não deve ser presumida correta para qualquer competência futura.

A manutenção do produto exige revisar parâmetros, testes e documentação quando houver mudança normativa relevante. A página de metodologia existe também para deixar essa dependência explícita.

Um sistema de cálculo não deveria produzir um número apenas porque recebeu campos suficientes. Casos fora do escopo, competência sem tabela, datas incompatíveis ou informação essencial ausente precisam resultar em bloqueio, alerta ou pedido de conferência.

Esse comportamento pode parecer menos “mágico”, mas é mais útil: evita transformar incerteza em precisão aparente. No RH.Me, reconhecer limites faz parte do desenho funcional.