Calculadora de pagamento regular e hora extra

Entradas: taxa horária, horas regulares, horas extras e multiplicador

Contagens de horas negativas e multiplicadores negativos também são rejeitados para que inversões acidentais de sinal falhem de forma ruidosa em vez de inventar negativos absurdos num recibo. Toda a validação ocorre antes de qualquer matemática monetária, assim pedidos inválidos nunca produzem linhas de pagamento pela metade que uma UI possa ler como sucesso. Você já decide quais horas são regulares versus extras segundo as suas regras locais ou a política da empresa; esta calculadora multiplica o que você envia em vez de inventar um limiar de semana de quarenta horas ou uma tabela diária de hora extra. Essa separação mantém clara a intenção de busca: quem já conhece a divisão regular e OT quer as linhas de dinheiro, não um motor de jurisdição. Envie um corpo JSON com quatro campos obrigatórios que descrevem um único período de pagamento. hourly_rate é o salário base por hora como número finito não negativo ou string numérica; os aliases rate, wage, hourly e pay_rate são aceitos quando o seu cliente já nomeia o campo de outra forma. regular_hours são as horas de tempo normal pagas a essa taxa base; os aliases hours, straight_hours, regular e straight_time mapeiam para o mesmo valor para que construtores de formulários mantenham rótulos familiares sem reescrever cargas. overtime_hours são as horas premium do mesmo período de pagamento; os aliases ot_hours, overtime e ot são suportados para que exportações de folhas de ponto mapeiem colunas com código de cola mínimo. overtime_multiplier é o prêmio expresso como múltiplo da taxa base — por exemplo 1.5 significa tempo e meio e 2 significa hora dobrada —, não um percentual do salário; os aliases multiplier, ot_multiplier, ot_rate e premium mapeiam para o mesmo campo. Taxas horárias negativas falham na validação com invalid_input porque não descrevem um contracheque normal. Taxas, totais de horas ou multiplicadores extremamente grandes são limitados para que a matemática do Worker isolate permaneça limitada e previsível sob carga. Faltar qualquer um dos quatro campos falha com invalid_input nomeando a chave ausente. Documente os quatro campos uma vez no seu SDK e reutilize as mesmas formas para demos, bots e testes de integração.

Como o pagamento regular, o de hora extra e o bruto são calculados

As fórmulas centrais são as que as pessoas já usam à mão numa folha de ponto ou estimativa semanal. O bruto é a soma dessas duas linhas, de modo que os ganhos regulares e de hora extra permanecem visíveis como componentes separados em vez de colapsar num total opaco. Os produtos intermediários usam aritmética de ponto flutuante comum; depois cada campo monetário é arredondado half-up a duas casas decimais para que os resultados pareçam moeda num contracheque e não frações binárias longas que confundem caixas e auditores. Exemplo: uma taxa de vinte, quarenta horas regulares, cinco horas extras e um multiplicador de 1.5 produz oitocentos de pagamento regular, cento e cinquenta de hora extra, uma taxa OT efetiva de trinta e um bruto de novecentos e cinquenta após o arredondamento. A mesma matemática para toda jurisdição é um escopo de produto intencional: limiares diários de OT, regras do sétimo dia e retenção de impostos seriam intenções de busca e contratos diferentes. O pagamento regular é igual a hourly_rate vezes regular_hours. O pagamento de hora extra é igual a hourly_rate vezes overtime_multiplier vezes overtime_hours. A resposta também devolve ot_hourly_rate como hourly_rate vezes o multiplicador para que UIs mostrem o salário efetivo de OT ao lado da taxa base sem recalcular no cliente. A resposta ecoa a taxa horária normalizada, as horas regulares, as horas extras e o multiplicador, e então devolve ot_hourly_rate, regular_pay, overtime_pay e gross_pay, mais currency_decimals igual a dois e method igual a overtime_gross para ramificação estável do cliente entre versões. Use regular_pay sozinho quando só precisar da linha de tempo normal; use overtime_pay quando um relatório precisar da linha premium; use gross_pay quando uma fatura de contratado ou estimativa semanal precisar do valor combinado.

Uso da API, preços, fluxos de trabalho e limites práticos

Use a API pré-paga quando um bot de RH, um painel de freelancing, um portal de staffing ou um auxiliar de folha de ponto precisar de um contrato KIT estável a US$ 0,002 por item bem-sucedido; falhas de validação nunca consomem saldo após o motor rejeitar o pedido. Combine este endpoint com ferramentas de impostos ou descontos só se você já conhecer as regras de líquido separadamente — esta capacidade não retém impostos, não aplica benefícios, não converte moedas nem inventa diferenciais de turno. Autores que enviam SDKs podem mapear regular_pay, overtime_pay e gross_pay diretamente em UIs de contracheque, mensagens de estimativa e colunas de exportação sem reinventar o arredondamento half-up do dinheiro. Quando citar o preço da API no texto do produto, use o marcador de catálogo US$ 0,002 para que as páginas publicadas fiquem alinhadas com o piso de preço ao vivo após atualizações do catálogo.