فوترة البرمجيات المقدمة كخدمة (SaaS) لعدة مؤسسات ليست مهمة شهرية تخصم من كل حساب. هي سجل اتفاقات وأحداث يجيب عن أسئلة واضحة: أي مؤسسة اشترت أي خطة؟ ومتى تغير استحقاقها؟ وما الذي صدر في الفاتورة؟ وأي محاولة دفع سوّتها؟ وما الذي يظل متاحاً بعد فشل الدفع أو الإلغاء؟ خلط هذه المفاهيم في حقول حالة قليلة يجعل الدعم والمالية والنظام يقدمون إجابات متناقضة.
هذا الدليل يفصل الخطط والاشتراكات والاستحقاقات وproration والفواتير ومحاولات الدفع وdunning والتسوية، دون ربط النموذج بمزود دفع محدد.
احمِ حد المستأجر أولاً
يجب أن ينتمي كل سجل فوترة إلى المؤسسة الصحيحة، وأن تطبق كل query وصلاحية ذلك الحد. قد ينتمي المستخدم إلى أكثر من مؤسسة بأدوار مختلفة. لا يجوز لمسؤول فوترة في مؤسسة رؤية فاتورة أو مرجع دفع لمؤسسة أخرى.
استخدم policies على الخادم وقيود قاعدة البيانات، لا فلترة الواجهة. اختبر العزل في التنزيل والتصدير وcallbacks والمهام وأدوات الدعم.
افصل كتالوج الخطط عن اتفاق العميل
يعرض catalog الخطط والأسعار والدورات والعملات والحدود الحالية. أما subscription فيحفظ اتفاق المؤسسة في وقت محدد. إذا تغير السعر العام، قد يبقى عميل على شروطه السابقة. لا تحسب فاتورة قديمة من صف خطة قابل للتعديل.
احتفظ بإصدار أو معرف سعر وsnapshot للشروط التي تفسر كل فاتورة. عرف الضرائب والخصومات والفترات التجريبية والأسعار المتفاوض عليها والخطط القديمة.
مثّل الاستحقاقات صراحة
تجيب الفوترة عما اشتراه العميل، وتجيب entitlements عما يسمح به المنتج: عدد مستخدمين أو تقرير أو مساحة أو تكامل. لا تنشر فحص اسم الخطة في أجزاء الكود.
خدمة استحقاق تقيم المؤسسة والميزة والحد والوقت وأي override. هذا يسهل الترقية والتجربة والمنح المؤقتة وإعادة تسمية الخطط دون كسر السلوك.
صمّم دورة الاشتراك
يمكن أن تشمل الحالات trialing وactive وpast due وpaused وscheduled to cancel وcancelled، لكن يجب أن تعكس قواعد العمل. حدد الحدث الذي ينقل الحالة وأثره على الوصول وإمكانية العودة.
احفظ أوقات البداية والفترة الحالية والتغيير المجدول والإلغاء والنهاية. لا يكفي is_active لشرح إلغاء مستقبلي أو فترة سماح.
اجعل الفاتورة سجلاً غير قابل للمحو
تضم الفاتورة بنوداً وكميات وأسعاراً وخصومات وضريبة وعملة ومجاميع وهوية المؤسسة وتواريخ ومراجع. بعد الإصدار، يتم التصحيح بمسار معتمد بدل تعديل التاريخ بصمت.
استخدم minor units أو تمثيلاً مالياً صحيحاً، لا floating point. حدد التقريب واختبر الحدود. راجع متطلبات الفوترة الحالية مع محاسب والجهة الرسمية.
اكتب قواعد احتساب فرق الفترة بأمثلة
يوزع proration القيمة عند تغيير الاشتراك وسط الفترة، ولا توجد صيغة واحدة صحيحة. قد تحسب رصيد الوقت المتبقي، أو تؤجل downgrade للتجديد، أو تمنع تغييراً. تؤثر الأشهر والمناطق الزمنية والتقريب.
اكتب ترقية في منتصف الفترة، وخفضاً مجدولاً، وزيادة مقاعد، وإلغاء تجربة، وتغييرين قبل الفاتورة. يجب أن توافق المالية والمنتج والهندسة على البنود والوقت نفسه.
افصل محاولة الدفع عن الفاتورة
قد تمر الفاتورة بمحاولات فاشلة ثم نجاح، أو تسوية جزئية أو استرداد. خزّن كل محاولة بالمزود والمبلغ والعملة والحالة وidempotency key والمرجع والأحداث. لا تستبدل حالة الفاتورة بآخر callback.
لا تعتبر صفحة عودة المستخدم إثباتاً. تحقق من الخادم والمبلغ والمرجع، وعالج الحدث المتكرر بأمان. تشرح خدمة التكاملات هذه الحدود.
استقبل Webhooks مع توقع التأخير والتكرار
تحقّق من توقيع محتوى الطلب كما وصل، واحفظ معرف الحدث، ثم استجب سريعاً وانقل المعالجة إلى طابور موثوق. قد تصل الأحداث بترتيب مختلف، لذلك يجب أن يقبل المعالج إعادة التنفيذ من دون تكرار الأثر المالي.
اعزل الحدث غير المعروف للمراجعة، ووفر replay مصرحاً ومسجلاً. يشرح دليل Webhooks والاستعلام الدوري الاستعادة والترتيب بمزيد من العمق.
عالج تعثر الدفع كرحلة عميل
يشمل dunning تسجيل سبب الفشل، وتقرير إعادة المحاولة وتوقيتها، وإبلاغ مسؤول الفوترة، وتمكين تحديث وسيلة الدفع، وتطبيق فترة السماح، ثم تقييد أو إنهاء الخدمة وفق السياسة.
فرق بين فشل مؤقت ورفض دائم عندما يوفر المزود السبب. استخدم retries محدودة وتوقف عندما لا تفيد. يجب أن تكون الرسالة واضحة وتقود إلى إجراء حساب مباشر.
حدد السماح والتقييد
الإغلاق الفوري قد يمنع العميل من تصدير بياناته أو إصلاح الفوترة، والوصول المفتوح بلا نهاية يضعف التحصيل. صمم فترة سماح وتقييداً تدريجياً معلناً.
لا تحذف البيانات بسبب محاولة فاشلة. الاحتفاظ وإنهاء العقد قرارات منفصلة عن الدفع.
طابق التسوية مع سجل الفواتير والمدفوعات
قارن الدفعات والاستردادات الداخلية مع تسوية المزود والرسوم والانعكاسات والإيداع. احتفظ بمراجع تربط السطر في الاتجاهين وأظهر النقص والتكرار واختلاف المبلغ.
نفذ التسوية دورياً واجعل لكل فرق مالكاً. لا تصلح الفرق بتعديل مجموع الفاتورة؛ سجل adjustment مع سبب وصلاحية.
قياس الاستخدام يحتاج عقد بيانات
حدد الحدث القابل للفوترة ووحدته ومصدره ونافذة التجميع وسياسة التأخير والتصحيح وما يراه العميل. استخدم معرفاً ثابتاً لمنع العد مرتين. احتفظ بسجل يكفي للنزاع.
اعرض الاستخدام الحالي وتأخر القياس، ونبه قبل الحدود عند الحاجة. metering منتج بيانات يحتاج إصدار schema ومراقبة وإعادة تشغيل.
أعط الدعم أدوات آمنة
قد يحتاج الدعم timeline، أو إعادة إرسال إشعار، أو جدولة إلغاء، أو منح تمديد موثق، أو replay حدث. اجعل الإجراءات مقيدة بأسباب وaudit log. تعديل قاعدة البيانات يفسد التسوية.
اعرض خطاً زمنياً للاشتراك والفواتير والمحاولات والأحداث والإشعارات والاستحقاقات حتى يمكن تفسير الحالة.
اختبر الوقت والمال
استخدم clock قابلاً للتحكم. اختبر حدود الأشهر والسنة الكبيسة والمناطق الزمنية وانتهاء التجربة والأحداث المتأخرة والمكررة والاسترداد الجزئي والتغييرات المجدولة.
اختبر عزل المستأجر وصلاحيات كل إجراء. استخدم sandbox للمزود مع اختبارات محلية ثابتة لآلة الحالات.
انقل الفوترة دون إعادة الشحن
عند النقل، استورد العملاء وشروط الاشتراك والفترة والفواتير القائمة والأرصدة ومراجع المزود. حدد من يملك التجديد أثناء cutover وطابق عينات ومجاميع قبل التفعيل.
احتفظ بخريطة معرفات ولا تنشئ دفعة لأن السجل وصل حديثاً. حدد نقطة لا يمكن بعدها rollback دون معالجة أحداث مالية جديدة.
بنية تنمو دون خدمات مصغرة مبكرة
يمكن أن تضم application واحدة catalog وsubscription service وentitlement evaluator وinvoice ledger وpayment attempts وprovider adapters وevent inbox وdunning وreconciliation مع حدود داخلية واضحة.
تبني خدمة تطوير SaaS هذه المسؤوليات، ويساعد دليل التطوير المخصص أم SaaS في تحديد ما إذا كان بناء الفوترة مبرراً أصلاً.
إغلاق السجل
اختبار الفوترة ليس نجاح أول خصم، بل قدرة الدعم على تفسير ترقية وحدث مكرر وفشل ورصيد ووصول حالي من timeline واحد. اكتب أمثلة الدورة وproration مع المالية أولاً، ثم أرسل سير الفوترة قبل اختيار واجهة المزود.
