Calculadora de pago regular y horas extra

El algoritmo es totalmente determinista, de modo que las mismas entradas siempre producen el mismo JSON para demos de nómina, bots de RR.

Entradas: tarifa horaria, horas regulares, horas extra y multiplicador

Los recuentos de horas negativos y los multiplicadores negativos también se rechazan para que un cambio accidental de signo falle de forma ruidosa en lugar de inventar negativos absurdos en un recibo. Toda la validación ocurre antes de cualquier matemática monetaria, así que las peticiones incorrectas nunca producen filas de pago a medias que una interfaz pueda malinterpretar como éxito. Usted ya decide qué horas son regulares frente a extraordinarias según sus normas locales o la política de la empresa; esta calculadora multiplica lo que envía en lugar de inventar un umbral de semana de cuarenta horas o una tabla diaria de horas extra. Esa separación mantiene clara la intención de búsqueda: quien ya conoce su división regular y OT quiere las líneas de dinero, no un motor de jurisdicción. Envíe un cuerpo JSON con cuatro campos obligatorios que describen un solo periodo de pago. hourly_rate es el salario base por hora como número finito no negativo o cadena numérica; se aceptan los alias rate, wage, hourly y pay_rate cuando su cliente ya nombra el campo de otra forma. regular_hours son las horas de tiempo normal pagadas a esa tarifa base; los alias hours, straight_hours, regular y straight_time se mapean al mismo valor para que los constructores de formularios conserven etiquetas familiares sin reescribir cargas útiles. overtime_hours son las horas premium del mismo periodo de pago; se admiten los alias ot_hours, overtime y ot para que las exportaciones de hojas de tiempo mapeen columnas con mínimo código de unión. overtime_multiplier es la prima expresada como múltiplo de la tarifa base —por ejemplo 1.5 significa tiempo y medio y 2 significa doble tiempo—, no un porcentaje del salario; los alias multiplier, ot_multiplier, ot_rate y premium se mapean al mismo campo. Las tarifas horarias negativas fallan la validación con invalid_input porque no describen una nómina normal. Tarifas, totales de horas o multiplicadores extremadamente grandes se limitan para que la matemática del Worker isolate permanezca acotada y predecible bajo carga. Faltar cualquiera de los cuatro campos falla con invalid_input nombrando la clave ausente. Documente los cuatro campos una vez en su SDK y reutilice las mismas formas para demos, bots y pruebas de integración.

Cómo se calculan el pago regular, el de horas extra y el bruto

Las fórmulas centrales son las que la gente ya usa a mano en una hoja de tiempo o una estimación semanal. El bruto es la suma de esas dos líneas, de modo que las ganancias regulares y de horas extra permanecen visibles como componentes separados en lugar de colapsar en un total opaco. Los productos intermedios usan aritmética de coma flotante ordinaria; después cada campo monetario se redondea half-up a dos decimales para que los resultados parezcan moneda en un recibo y no fracciones binarias largas que confunden a cajeros y auditores. Ejemplo: una tarifa de veinte, cuarenta horas regulares, cinco horas extra y un multiplicador de 1.5 produce ochocientos de pago regular, ciento cincuenta de horas extra, una tarifa OT efectiva de treinta y un bruto de novecientos cincuenta tras el redondeo. La misma matemática para toda jurisdicción es un alcance de producto intencional: umbrales diarios de OT, reglas del séptimo día y retención fiscal serían intenciones de búsqueda y contratos distintos. El pago regular es igual a hourly_rate por regular_hours. El pago de horas extra es igual a hourly_rate por overtime_multiplier por overtime_hours. La respuesta también devuelve ot_hourly_rate como hourly_rate por el multiplicador para que las interfaces muestren el salario efectivo de OT junto a la tarifa base sin recalcularlo en el cliente. La respuesta hace eco de la tarifa horaria normalizada, las horas regulares, las horas extra y el multiplicador, y luego devuelve ot_hourly_rate, regular_pay, overtime_pay y gross_pay, más currency_decimals igual a dos y method igual a overtime_gross para un ramificado estable del cliente entre versiones. Use regular_pay solo cuando solo necesite la línea de tiempo normal; use overtime_pay cuando un informe necesite la línea premium; use gross_pay cuando una factura de contratista o una estimación semanal necesite el importe combinado.

Uso de la API, precios, flujos de trabajo y límites prácticos

Use la API prepago cuando un bot de RR. HH., un panel de freelancing, un portal de personal o un ayudante de hojas de tiempo necesite un contrato KIT estable a $0.002 por ítem exitoso; los fallos de validación nunca consumen saldo tras el rechazo del motor. Los autores que envían SDK pueden mapear regular_pay, overtime_pay y gross_pay directamente a interfaces de recibo, mensajes de estimación y columnas de exportación sin reinventar el redondeo half-up del dinero. Cuando cite el precio de la API en el texto del producto, use el marcador de catálogo $0.002 para que las páginas publicadas se mantengan alineadas con el piso de precio en vivo tras actualizaciones del catálogo.