صندوق الإجازة لكل راتب

يُرفض عدد فترات دفع صفري بـ invalid_input بدل التظاهر بأن القسمة على صفر خطة؛ كما تُرفض الميزانيات والأرصدة وأعداد الفترات السالبة. عندما تبلغ المدخرات الحالية الهدف أو تتجاوزه، يكون per_paycheck صفرًا وalready_funded صحيحًا. المسار حساب حتمي خالص —بلا شبكة، بلا نموذج فائدة، بلا بذرة عشوائية، بلا اعتماد على الساعة— لذا يعيد المشغّل المجاني في المتصفح وAPI المسبق الدفع نفس JSON بعد التقريب العشري الثابت في كل استدعاء.

ماذا يعني الادخار لكل راتب للإجازة بميزانية رحلة ثابتة

تطبق الحساب فقط: remaining يساوي أقصى صفر والهدف ناقص الحالي، وper_paycheck يساوي صفرًا عندما يكون remaining صفرًا، وإلا per_paycheck يساوي remaining مقسومًا على pay_periods.

كيف تستدعون الـ API وما الذي يعود

فضّلوا أعدادًا عارية على سلاسل منسقة كعملة؛ تُقبل أعداد السلاسل فقط عندما تطابق نمطًا عدديًا منتهيًا صارمًا بلا علامات دولار أو فواصل. أرسلوا جسم JSON بثلاثة أعداد منتهية مطلوبة: goal (أسماء بديلة target, vacation_budget, budget, trip_cost, amount) ميزانية الإجازة غير السالبة؛ current (أسماء بديلة current_savings, saved, balance, savings) المبلغ غير السالب المدخر أصلًا؛ وpay_periods (أسماء بديلة periods, paychecks, remaining_paychecks, paycheck_count, n_paychecks) العدد الموجب بصرامة للرواتب المتبقية حتى الرحلة. يجب أن تبقى القيم المطلقة ضمن تريليون واحد حتى تظل النواتج الوسيطة منتهية بدقة مزدوجة IEEE على الـ Worker وفي المتصفح. يجب أن يكون حقل pay_periods موجبًا بصرامة؛ تُرفض قيمة صفر أو شبه صفر بـ invalid_input لأنكم لا تمولون رحلة عبر صفر أيام دفع، كما يُرفض عدد فترات سالب. عند النجاح تعكس الاستجابة goal وcurrent وpay_periods مقربة؛ وتعيّن remaining وtotal_to_save للمبلغ غير السالب ما زال مطلوبًا؛ وper_paycheck للاقتطاع المتساوي؛ وalready_funded لقيمة منطقية؛ وformula للسلسلة الموثقة؛ وmessage لملخص إنجليزي قصير؛ وsteps لمصفوفة مرتبة من أسطر الاستبدال. التحقق الفاشل —حقول مفقودة، أعداد غير منتهية، قيم خارج الحدود المطلقة، goal أو current سالب، pay_periods صفر أو سالب، أو remaining أو per_paycheck محسوب غير منتهٍ— يعيد invalid_input ولا يُحاسب أبدًا. التسعير $0.002 ثابت لكل طلب ناجح بوحدة item. عدّوا الرواتب المتبقية بأنفسكم من تقويم الدفع وتاريخ الرحلة قبل استدعاء الـ API.

نصائح عملية وحدود وعمليات بحث ذات صلة

تستهدف هذه الصفحة من يبحث عن حاسبة صندوق إجازة لكل راتب، أو كم يدخر كل راتب لرحلة، أو ادخار رحلة بيوم الدفع عبر الإنترنت؛ ليست أداة قيمة مستقبلية بفائدة مركبة، ولا جدول إطفاء قرض، ولا حاسبة أشهر حتى الهدف تأخذ وديعة ثابتة وتحل الزمن. فضّلوا هذه القدرة عندما تعرفون الميزانية والرصيد وعدد الرواتب المتبقية وتحتاجون فقط الاقتطاع المتساوي؛ إذا تضمنت خطتكم فائدة أو زيادات فاستخدموا نموذج نمو مخصصًا بدلًا منها. استخدموا وحدة العملة نفسها لـ goal وcurrent وper_paycheck المعاد —لا تخلطوا الدولارات والسنتات كأنهما نفس المقياس دون تحويل أولًا. أبقوا pay_periods موجبًا بصرامة؛ تجارب المتصفح المجانية التي ترسل صفرًا تصيب invalid_input ولن تُحاسب على الـ API. عند التعليم أو الاختبار، اقرنوا أمثلة: هدف ثلاثة آلاف مع حالي ستمائة واثنتي عشرة فترة دفع لمسار مائتين لكل راتب بالضبط؛ حالة لا يكون فيها remaining مضاعفًا نظيفًا فيكون الاقتطاع العشري غير صحيح؛ حالة يساوي فيها current الهدف أو يتجاوزه فيكون per_paycheck صفرًا؛ وpay_periods صفر عمدًا لإظهار مسار invalid_input الصارم. المهام الفاشلة التي تعيد invalid_input لا تستهلك الرصيد المسبق الدفع، ما يبقي سكربتات الاستكشاف رخيصة عندما يرسل المطورون عمدًا عدد فترات صفر. فحوصات الذهاب والإياب سهلة: أعيدوا حساب أقصى صفر والهدف ناقص الحالي يدويًا، اقسموا على pay_periods، وأكدوا المساواة مع per_paycheck المنشور ضمن نفس تقريب الاثنتي عشرة منزلة على حقول المال.