كيف نبني برمجيات مالية لا تخطئ في الحساب

في البرمجيات المالية، الخطأ الصغير لا يبقى صغيراً: هللة مفقودة في كل فاتورة تصبح فرقاً في الصندوق، ودفعة مكررة تصبح خلافاً مع عميل. هذه المبادئ التي نبني بها أنظمتنا المالية.

1. الخادم وحده يحسب

لا تُجري الواجهة أي حساب مالي. السعر، الضريبة، الخصم، الربح، وجدول الأقساط كلها تُحسب على الخادم، والواجهة تعرض النتيجة فقط. في Qistora يمكنك معاينة جدول الأقساط قبل حفظ العقد، لكن المعاينة نفسها تُحسب على الخادم بنفس المحرك الذي سيُنشئ العقد.

2. لا كسور عشرية عائمة

نحسب المبالغ بالأعداد الصحيحة (بالهللة في Books) أو بأنواع عشرية دقيقة، ولا نستخدم الأعداد العائمة (float) في المال أبداً. التقريب يحدث في نقطة واحدة معروفة، بقاعدة واحدة.

3. قيد مزدوج لا يُعدَّل

كل عملية مالية — صرف عقد، تحصيل قسط، دفعة مقدمة، خصم، إعدام دين — تُسجَّل كقيد مزدوج في دفتر الأستاذ. القيود لا تُعدَّل ولا تُحذف؛ التصحيح يكون بقيد عكسي جديد. هكذا يبقى أثر كل قرار محفوظاً، ويمكن إعادة بناء أي رصيد في أي تاريخ.

4. نقرة واحدة = عملية واحدة

الشبكة البطيئة والنقر المزدوج سببان شائعان للدفعات المكررة. لذلك تتطلب كل عملية مالية في Qistora مفتاح منع تكرار (Idempotency Key): إن أُرسل الطلب مرتين، تُعاد النتيجة الأصلية دون تنفيذ ثانٍ. وفي Books تمنع نقطة البيع البيع المزدوج حتى مع بطء الاتصال.

5. المطابقة اليومية

مهمة مجدولة تطابق يومياً بين أرصدة الذمم في الدفتر ومجموع الأقساط القائمة. أي فرق يظهر فوراً في لوحة المعلومات بدل أن يُكتشف بعد أشهر.

6. سجل تدقيق لكل شيء

من سجّل الدفعة؟ من عدّل الإعداد؟ من كشف رقم هوية العميل؟ كل ذلك مسجّل بالمستخدم والوقت ومعرّف الطلب.

---

هذه المبادئ ليست نظرية؛ يمكنك رؤيتها بنفسك في النسخة التجريبية لـ Qistora والنسخة التجريبية لـ Books.