Calculateur d'heures sup

Un taux horaire négatif est rejeté avec une erreur claire invalid_input, car un salaire négatif ne décrit pas un calcul de brut valide.

Entrées : taux horaire, heures régulières, heures sup et multiplicateur

Les comptes d'heures négatifs et les multiplicateurs négatifs sont aussi rejetés pour qu'un changement de signe accidentel échoue bruyamment au lieu d'inventer des négatifs absurdes sur une fiche de paie. Toute la validation a lieu avant tout calcul monétaire, ainsi les mauvaises requêtes ne produisent jamais de lignes de paie à moitié remplies. Vous décidez déjà quelles heures sont régulières versus supplémentaires selon vos règles locales ; ce calculateur multiplie ce que vous envoyez plutôt que d'inventer une politique de semaine de quarante heures. Envoyez un corps JSON avec quatre champs obligatoires. hourly_rate est le salaire de base par heure sous forme de nombre fini non négatif ou de chaîne numérique ; les alias rate, wage, hourly et pay_rate sont acceptés lorsque votre client nomme déjà le champ autrement. regular_hours sont les heures de temps de base payées à ce taux de base ; les alias hours, straight_hours, regular et straight_time se mappent à la même valeur pour que les constructeurs de formulaires gardent des libellés familiers. overtime_hours sont les heures premium de la même période de paie ; les alias ot_hours, overtime et ot sont pris en charge. overtime_multiplier est la prime exprimée comme un multiple du taux de base —par exemple 1.5 signifie temps et demi et 2 signifie double temps—, non un pourcentage du salaire ; les alias multiplier, ot_multiplier, ot_rate et premium se mappent au même champ. Les taux horaires négatifs échouent à la validation avec invalid_input car ils ne décrivent pas une fiche de paie normale. Les taux, totaux d'heures ou multiplicateurs extrêmement grands sont plafonnés pour que les calculs du Worker isolate restent bornés. L'absence de l'un des quatre champs échoue avec invalid_input en nommant la clé manquante.

Comment la paie régulière, les heures sup et le brut sont calculés

Les formules centrales sont celles que l'on utilise déjà à la main sur une feuille de temps. Le brut est la somme de ces deux lignes. Les produits intermédiaires utilisent l'arithmétique flottante ordinaire ; ensuite chaque champ monétaire est arrondi half-up à deux décimales pour que les résultats ressemblent à de la monnaie sur une fiche de paie plutôt qu'à de longues fractions binaires. Exemple : un taux de vingt, quarante heures régulières, cinq heures sup et un multiplicateur de 1.5 donnent huit cents de paie régulière, cent cinquante d'heures sup, un taux OT effectif de trente et un brut de neuf cent cinquante après arrondi. La même mathématique pour chaque juridiction est un périmètre produit volontaire : seuils quotidiens d'OT, règles du septième jour et retenues fiscales seraient d'autres intentions de recherche et d'autres contrats. La paie régulière égale hourly_rate multiplié par regular_hours. La paie des heures sup égale hourly_rate multiplié par overtime_multiplier multiplié par overtime_hours. La réponse renvoie aussi ot_hourly_rate comme hourly_rate multiplié par le multiplicateur pour que les interfaces montrent le salaire effectif OT à côté du taux de base. La réponse renvoie en écho le taux horaire normalisé, les heures régulières, les heures sup et le multiplicateur, puis renvoie ot_hourly_rate, regular_pay, overtime_pay et gross_pay, plus currency_decimals égal à deux et method égal à overtime_gross pour un branchement client stable. Utilisez regular_pay seul lorsque vous n'avez besoin que de la ligne de temps de base ; utilisez overtime_pay lorsqu'un rapport a besoin de la ligne premium ; utilisez gross_pay lorsqu'une facture de contractant ou une estimation hebdomadaire a besoin du montant combiné. Des entrées identiques produisent toujours un JSON identique car le chemin est de l'arithmétique pure sans réseau, sans graine aléatoire et sans horloge murale.

Usage de l'API, tarification, flux de travail et limites pratiques

Utilisez l'API prépayée lorsqu'un bot RH, un tableau de bord freelancing, un portail de staffing ou un aide aux feuilles de temps a besoin d'un contrat KIT stable à $0.002 par élément réussi ; les échecs de validation ne consomment jamais de solde après le rejet du moteur. Les auteurs livrant des SDK peuvent mapper regular_pay, overtime_pay et gross_pay directement dans des interfaces de fiche de paie et des messages d'estimation. Lorsque vous citez le prix de l'API dans le texte produit, utilisez l'espace réservé catalogue $0.002 pour que les pages publiées restent alignées sur le plancher de prix en direct.