DEV Community

marcio tikuk
marcio tikuk

Posted on

Como modelar cálculo de rescisão de Operador de Caixa em código

Como modelar o cálculo de rescisão de Operador de Caixa em código (case study HRtech)

Implementar um sistema de folha de pagamento no Brasil exige modelar uma das legislações trabalhistas mais complexas do mundo. Neste artigo, uso operador de caixa como caso real para demonstrar como a engenharia de software resolve esse problema.


O problema de negócio

operador de caixa trabalha em regime CLT com particularidades que impactam diretamente o cálculo rescisório:

  • Jornada: 44h semanais ou escalas de 6 horas diárias, dependendo do estabelecimento
  • Faixa salarial: R$ 1.500 a R$ 2.100
  • Adicionais comuns: Adicional de Quebra de Caixa (risco de faltas no caixa), vale-transporte e vale-refeição
  • Riscos ocupacionais: Riscos ergonômicos (LER/DORT) devido a movimentos repetitivos no checkout

Cada uma dessas variáveis precisa ser modelada como regra de negócio parametrizável — não como if hardcoded.


Arquitetura da solução

1. Motor de regras parametrizável

A CLT define regras base, mas cada categoria (sindicato, CBO) adiciona camadas. A solução: um rule engine que compõe regras por categoria em runtime:

RuleEngine
  ├── BaseRules (CLT: férias, 13º, aviso, FGTS)
  ├── CategoryRules (piso, adicional, jornada especial)
  └── PayrollRules (INSS progressivo, IRRF com deduções)
Enter fullscreen mode Exit fullscreen mode

2. Pipeline de cálculo rescisório

  1. Input: data de admissão, data de demissão, salário, tipo de rescisão
  2. Resolve: categoria → carrega CategoryRules do CBO
  3. Compute: aplica BaseRules + CategoryRules em ordem
  4. Output: discriminado de verbas + totais

3. Integração com tabelas oficiais

INSS e IRRF mudam anualmente. O sistema consome tabelas versionadas com effectiveDate, garantindo que o cálculo use a tabela correta para a data da rescisão.


Ferramentas de referência

Implementações que modelam essas regras em produção:


Conclusão

O ecossistema de HRtech brasileiro ainda é dominado por sistemas legados monolíticos. A nova geração entende que cada profissão tem regras diferentes e modela isso nativamente com rule engines parametrizáveis.


⚠️ Este artigo tem caráter informativo. Os cálculos são estimativas educativas.

Top comments (0)