Poupança de férias por pagamento

Uma contagem zero de períodos de pagamento é rejeitada com invalid_input em vez de fingir que dividir por zero é um plano; orçamentos, saldos e contagens de períodos negativos também são rejeitados. Quando a poupança atual já atinge ou supera a meta, per_paycheck é zero e already_funded é verdadeiro. O caminho é aritmética determinística pura —sem rede, sem modelo de juros, sem semente aleatória, sem dependência do relógio— de modo que o executor gratuito do navegador e a API pré-paga devolvem o mesmo JSON após o arredondamento decimal fixo cada vez que você a invoca.

O que significa poupar por pagamento para férias com orçamento fixo de viagem

Aplica apenas a aritmética: remaining igual ao máximo de zero e meta menos atual, per_paycheck igual a zero quando remaining é zero, caso contrário per_paycheck igual a remaining dividido por pay_periods.

Como chamar a API e o que volta

Prefira números puros em vez de strings formatadas como moeda; números em string só são aceites quando coincidem com um padrão numérico finito estrito sem sinais de dólar nem vírgulas. Envie um corpo JSON com três números finitos obrigatórios: goal (aliases target, vacation_budget, budget, trip_cost, amount), o orçamento de férias não negativo; current (aliases current_savings, saved, balance, savings), o montante não negativo já poupado; e pay_periods (aliases periods, paychecks, remaining_paychecks, paycheck_count, n_paychecks), a contagem estritamente positiva de salários restantes até a viagem. Os valores absolutos devem permanecer dentro de um trilhão para que os produtos intermediários sigam finitos em precisão dupla IEEE no Worker e no navegador. O campo pay_periods deve ser estritamente positivo; um valor zero ou quase zero é rejeitado com invalid_input porque não se pode financiar uma viagem com zero dias de pagamento, e uma contagem de períodos negativa também é rejeitada. Em caso de sucesso a resposta ecoa goal, current e pay_periods arredondados; define remaining e total_to_save para o montante não negativo ainda necessário; per_paycheck para a reserva uniforme; already_funded para um booleano; formula para a string documentada; message para um resumo breve em inglês; e steps para um array ordenado de linhas de substituição. A validação falhada —campos ausentes, números não finitos, valores fora dos limites absolutos, um goal ou current negativo, um pay_periods zero ou negativo, ou um remaining ou per_paycheck calculado não finito— devolve invalid_input e nunca é cobrada. O preço é um US$ 0,002 fixo por pedido bem-sucedido com unidade item. Conte você mesmo os salários restantes a partir do seu calendário de pagamento e da data da viagem antes de chamar a API.

Dicas práticas, limites e buscas relacionadas

Esta página visa quem busca uma calculadora de poupança de férias por pagamento, quanto poupar a cada salário para uma viagem, ou poupança de viagem por dia de pagamento online; não é uma ferramenta de valor futuro com juros compostos, nem um calendário de amortização de empréstimo, nem uma calculadora de meses até a meta que recebe um depósito fixo e resolve o tempo. Prefira esta capacidade quando já souber o orçamento, o saldo e quantos salários restam e só precisar da reserva uniforme; se o seu plano inclui juros ou aumentos, use em vez disso um modelo de crescimento dedicado. Use a mesma unidade de moeda para goal, current e o per_paycheck devolvido —não misture dólares e centavos como se fossem a mesma escala sem converter primeiro. Mantenha pay_periods estritamente positivo; experimentos gratuitos no navegador que enviam zero acertam invalid_input e não serão cobrados na API. Ao ensinar ou testar, combine exemplos: meta de três mil com atual de seiscentos e doze períodos de pagamento para um caminho exato de duzentos por pagamento; um caso em que remaining não é múltiplo limpo de modo que a reserva decimal não é inteira; um caso em que current já iguala ou supera a meta de modo que per_paycheck é zero; e um pay_periods deliberadamente zero para demonstrar a rota dura de invalid_input. Tarefas falhadas que devolvem invalid_input não consomem saldo pré-pago, o que mantém baratos os scripts exploratórios quando desenvolvedores enviam de propósito uma contagem de períodos zero. Verificações de ida e volta são fáceis: recalcule à mão o máximo de zero e meta menos atual, divida por pay_periods e confirme que iguala o per_paycheck publicado com o mesmo arredondamento a doze decimais nos campos de dinheiro.