Calculateur paie régulière et heures sup

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 basculement accidentel de signe échoue bruyamment au lieu d'inventer des négatifs absurdes sur un bulletin. Toute la validation a lieu avant tout calcul monétaire, ainsi les mauvaises requêtes ne produisent jamais de lignes de paie à moitié remplies qu'une interface pourrait lire comme un succès. Vous décidez déjà quelles heures sont régulières versus supplémentaires selon vos règles locales ou la politique de l'entreprise ; ce calculateur multiplie ce que vous envoyez plutôt que d'inventer un seuil de semaine de quarante heures ou un tableau quotidien d'heures sup. Cette séparation garde claire l'intention de recherche : ceux qui connaissent déjà leur répartition régulière et OT veulent les lignes d'argent, pas un moteur de juridiction. Envoyez un corps JSON avec quatre champs obligatoires qui décrivent une seule période de paie. 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 simple payées à ce taux de base ; les alias hours, straight_hours, regular et straight_time correspondent à la même valeur afin que les constructeurs de formulaires conservent des libellés familiers sans réécrire les charges utiles. 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 pour que les exports de feuilles de temps mappent les colonnes avec un minimum de code de liaison. 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 correspondent 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 et prévisibles sous charge. L'absence de l'un des quatre champs échoue avec invalid_input en nommant la clé manquante. Documentez les quatre champs une fois dans votre SDK et réutilisez les mêmes formes pour démos, bots et tests d'intégration.

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

Les formules centrales sont celles que les gens utilisent déjà à la main sur une feuille de temps ou une estimation hebdomadaire. Le brut est la somme de ces deux lignes, de sorte que les gains réguliers et d'heures sup restent visibles comme composants séparés au lieu de s'effondrer en un total opaque. 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 un bulletin plutôt qu'à de longues fractions binaires qui déroutent caissiers et auditeurs. Exemple : un taux de vingt, quarante heures régulières, cinq heures sup et un multiplicateur de 1.5 donne 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 toute 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 d'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 affichent le salaire effectif d'OT à côté du taux de base sans le recalculer côté client. La réponse répète 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 entre versions. Utilisez regular_pay seul lorsque vous n'avez besoin que de la ligne de temps simple ; utilisez overtime_pay lorsqu'un rapport a besoin de la ligne premium ; utilisez gross_pay lorsqu'une facture de prestataire ou une estimation hebdomadaire a besoin du montant combiné.

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

Utilisez l'API prépayée lorsqu'un bot RH, un tableau de freelancing, un portail de staffing ou un aide de feuille de temps a besoin d'un contrat KIT stable à $0.002 par élément réussi ; les échecs de validation ne consomment jamais le solde après le rejet du moteur. Les auteurs qui livrent des SDK peuvent mapper regular_pay, overtime_pay et gross_pay directement dans des interfaces de bulletin, des messages d'estimation et des colonnes d'export sans réinventer l'arrondi half-up monétaire. Lorsque vous citez le prix de l'API dans le texte produit, utilisez le marqueur de catalogue $0.002 pour que les pages publiées restent alignées sur le plancher de prix en direct après les mises à jour du catalogue.