دفتر الأستاذ غير القابل للتغيير: كيف أنهينا كابوس تسوية المدفوعات في شركتنا؟

يا جماعة الخير، السلام عليكم ورحمة الله.

اسمحوا لي آخذكم في رحلة قصيرة للوراء، لأيام كانت فيها القهوة هي الوقود الوحيد اللي بيخليني أقدر أواجه جداول الإكسل المرعبة وتقارير المحاسبة اللي ما بتخلص. كنت وقتها في شركة ناشئة بتكبر بسرعة الصاروخ، وكل ما زادت الطلبات والمبيعات، زادت معها الفوضى في قسم المالية. كان السؤال اللي بيتكرر كل آخر شهر زي الكابوس: “أبو عمر، وين راحت المصاري؟”.

كان فريق المحاسبة، الله يعطيهم العافية، يقضون أسابيع في محاولة مطابقة المبالغ اللي دخلت من بوابات الدفع مع السجلات في نظامنا، مع الأخذ بالاعتبار المبالغ المستردة، ورسوم البنوك، وعمليات الاحتيال. كانت العملية أشبه بتركيب أحجية (Puzzle) من مليون قطعة، بس المشكلة إنه في قطع ناقصة وقطع شكلها غلط. كل خطأ كان يعني خسارة مال ووقت، والأهم من هيك، خسارة ثقة.

في ليلة من الليالي، وأنا بقلّب في سجلات قاعدة البيانات وبحاول أتتبع معاملة واحدة ضايعة، خطرت في بالي فكرة جدتي، الله يرحمها. كانت تمسك دفتر ديون صغير، وكل ما حدا أخذ منها شي أو رجّع شي، كانت تسجله في سطر جديد. عمرها ما مسحت سطر قديم، كانت بس تشخط عليه وتكتب تحته “تم التسديد”. بسيطة، واضحة، ومستحيل يتغير فيها التاريخ. وقتها صرخت بنص الليل: “وجدتها! الحل في دفتر جدتي!”.

هذا المبدأ البسيط هو جوهر ما يُعرف اليوم في عالم هندسة البرمجيات بـ “دفتر الأستاذ غير القابل للتغيير” (Immutable Ledger)، وهو اللي أنقذنا من جحيم الأخطاء المحاسبية. خلوني أحكيلكم كيف.

المشكلة الجوهرية: ليش الأنظمة التقليدية بتفشل؟

قبل ما نحكي عن الحل، لازم نفهم أصل المشكلة. معظم الأنظمة اللي بنبنيها في البداية بتعتمد على قاعدة بيانات علائقية (زي MySQL أو PostgreSQL) وفيها جداول زي orders أو payments. المشكلة مش في قاعدة البيانات نفسها، ولكن في الطريقة اللي بنستخدمها فيها.

قابلية التغيير (Mutability): أصل كل الشرور

في قاعدة البيانات التقليدية، إحنا متعودين نستخدم أوامر زي UPDATE و DELETE. بدك تغيّر حالة طلب من “قيد التنفيذ” إلى “تم الشحن”؟ بتعمل UPDATE. العميل ألغى الطلب؟ يمكن تعمل DELETE للطلب كله. هذا الأسلوب كارثي في الأنظمة المالية للأسباب التالية:

• فقدان الأثر (Loss of Audit Trail): لما تغيّر قيمة في حقل، أنت بتمحي القيمة القديمة. ما بتقدر ترجع بالزمن وتعرف شو كان الوضع قبل التغيير. هذا بخلي تتبع الأخطاء شبه مستحيل.
• الأخطاء البشرية والبرمجية: خطأ برمجي صغير (bug) في كود الـ UPDATE ممكن يغير آلاف السجلات المالية بالغلط. تخيل تحديث كل المبالغ وتحويلها لصفر! صارت، وشفتها بعيني.
• الـ Race Conditions: لما يكون في عمليتين بحاولوا يغيروا نفس السجل في نفس اللحظة، ممكن تحصل نتائج غير متوقعة ومدمرة.

غياب مصدر الحقيقة الأوحد (Single Source of Truth)

المشكلة الثانية هي تعدد “مصادر الحقيقة”. قسم المحاسبة عنده شيت إكسل، نظام المدفوعات عنده سجلاته، وقاعدة بياناتنا عندها سجلات تالتة. لما الأرقام ما تتطابق، بتبدأ رحلة العذاب لمعرفة مين الصح ومين الغلط. الحقيقة لازم تكون واحدة، وموجودة في مكان واحد فقط.

الحل: دفتر الأستاذ غير القابل للتغيير (The Immutable Ledger)

دفتر الأستاذ غير القابل للتغيير هو ببساطة سجل لكل الأحداث المالية التي تقع في نظامك. الفكرة الأساسية فيه هي أنك تضيف فقط، ولا تعدّل أو تحذف أبداً (Append-Only).

شو يعني “غير قابل للتغيير”؟

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

• عملية شراء: هي قيد جديد يُضاف للدفتر.
• عملية استرجاع (Refund): ليست حذفاً لعملية الشراء، بل هي قيد جديد سالب القيمة يُضاف للدفتر.
• تعديل على فاتورة: هو ليس UPDATE، بل هو قيدان جديدان: قيد يلغي القديم (بقيمة عكسية)، وقيد يثبت الجديد.

بهذه الطريقة، كل حركة مالية، مهما كانت صغيرة، تصبح حدثاً مسجلاً له طابع زمني ولا يمكن تغييره، مما يخلق مسار تدقيق (Audit Trail) كامل وواضح بنسبة 100%.

كيف بنبنيه؟ التصميم والهيكلية

قد تعتقد أنك بحاجة إلى تقنيات معقدة مثل البلوك تشين. الجواب هو لا. يمكنك بناء دفتر أستاذ قوي جداً باستخدام قاعدة بيانات SQL عادية مع بعض القواعد الصارمة.

هذا مثال على هيكل جدول بسيط لدفتر الأستاذ (ledger_entries):

CREATE TABLE ledger_entries (
    id BIGINT PRIMARY KEY AUTO_INCREMENT,      -- معرّف فريد لكل قيد
    entry_uuid VARCHAR(36) NOT NULL UNIQUE,     -- معرّف فريد عالمي (UUID) لمنع التكرار
    account_id VARCHAR(50) NOT NULL,            -- معرّف الحساب المتأثر (مثل حساب العميل، حساب الإيرادات)
    amount DECIMAL(15, 4) NOT NULL,             -- المبلغ (موجب للدائن، سالب للمدين)
    currency VARCHAR(3) NOT NULL,               -- العملة
    transaction_type VARCHAR(50) NOT NULL,      -- نوع الحركة (PAYMENT, REFUND, FEE, PAYOUT)
    transaction_id VARCHAR(36) NOT NULL,        -- معرّف يربط كل قيود نفس العملية معاً
    metadata JSON,                              -- حقل لتخزين معلومات إضافية (رقم الطلب، سبب الاسترجاع)
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP -- تاريخ ووقت إنشاء القيد
);

-- لضمان عدم التغيير، يجب تقييد صلاحيات الـ UPDATE و DELETE على هذا الجدول
-- من خلال صلاحيات قاعدة البيانات (Database Permissions).

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

التطبيق العملي: من النظرية إلى الكود

لنرى كيف تبدو الأمور على أرض الواقع. لنفترض أن عميلاً اشترى منتجاً بقيمة 100 دولار، وكانت رسوم بوابة الدفع 3 دولارات.

مثال: عملية شراء بسيطة

عملية الشراء الواحدة هذه ليست قيداً واحداً في دفتر الأستاذ، بل هي مجموعة من القيود المترابطة التي يجب أن يكون مجموعها صفراً (مبدأ القيد المزدوج في المحاسبة).

سيتم إنشاء القيود التالية بنفس الـ transaction_id:

1. قيد لإثبات استلام المبلغ:
   • account_id: ‘unsettled_funds’ (الأموال المعلقة)
   • amount: +100.00
   • transaction_type: ‘PAYMENT_RECEIVED’
2. قيد لخصم رسوم بوابة الدفع:
   • account_id: ‘unsettled_funds’ (الأموال المعلقة)
   • amount: -3.00
   • transaction_type: ‘PAYMENT_FEE’
3. قيد لإثبات إيرادات الشركة:
   • account_id: ‘company_revenue’ (إيرادات الشركة)
   • amount: +97.00
   • transaction_type: ‘REVENUE_ACCRUAL’
4. قيد لترحيل الأموال من الحساب المعلق:
   • account_id: ‘unsettled_funds’
   • amount: -97.00
   • transaction_type: ‘INTERNAL_TRANSFER’

لاحظ أن مجموع كل القيود لنفس العملية (100 – 3 + 97 – 97) لا يساوي صفر هنا، وهذا خطأ شائع. المحاسبة المزدوجة تتطلب توازناً. الطريقة الأصح هي كالآتي:

-- Transaction ID: "txn_123"

-- 1. Customer pays 100
{ account: "customer_wallet", amount: -100, type: "PAYMENT" }
{ account: "accounts_receivable", amount: +100, type: "PAYMENT" }

-- 2. Payment gateway charges a 3 fee
{ account: "accounts_receivable", amount: -3, type: "FEE" }
{ account: "payment_fees_expense", amount: +3, type: "FEE" }

-- 3. We recognize the revenue
{ account: "accounts_receivable", amount: -97, type: "REVENUE" }
{ account: "company_revenue", amount: +97, type: "REVENUE" }

الآن، كل مجموعة قيود متوازنة ومجموعها صفر. ورصيد أي حساب (Balance) هو ببساطة مجموع كل القيود المرتبطة به:

SELECT SUM(amount) FROM ledger_entries WHERE account_id = 'company_revenue';

مثال: عملية استرجاع (Refund)

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

-- Transaction ID: "txn_456", Metadata: { original_txn: "txn_123" }

-- Reverse the revenue
{ account: "company_revenue", amount: -97, type: "REFUND" }
{ account: "accounts_receivable", amount: +97, type: "REFUND" }

-- Give money back to customer
{ account: "accounts_receivable", amount: -100, type: "REFUND" }
{ account: "customer_wallet", amount: +100, type: "REFUND" }

-- Maybe the payment gateway refunds the fee, maybe not. Let's assume not.

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

نصائح من خبرة أبو عمر

• ابدأ ببساطة: لست بحاجة إلى أدوات معقدة. جدول PostgreSQL أو MySQL مع قيود صارمة على الصلاحيات هو بداية ممتازة وأكثر من كافية لمعظم الشركات.
• الاتساق هو الملك: يجب أن يمر كل حدث له أثر مالي عبر دفتر الأستاذ. لا توجد استثناءات. أي حركة تتم “خارج” الدفتر ستكسر النظام بأكمله.
• الـ `metadata` صديقك الصدوق: هذا الحقل هو كنزك. خزّن فيه كل ما يمكنك من معلومات إضافية: `order_id`, `customer_id`, `user_who_approved_refund`, `reason`. ستحمد نفسك لاحقاً عندما تحتاج للتحقيق في معاملة معينة بعد 6 أشهر.
• فكر في الأداء من اليوم الأول: حساب الرصيد عن طريق عمل SUM على جدول يحتوي على مليارات القيود سيصبح بطيئاً. خطط مسبقاً لإنشاء جداول ملخصات (Summary Tables) يتم تحديثها بشكل دوري (مثلاً، كل ساعة أو كل ليلة) لتخزين الأرصدة الحالية لكل حساب.
• اجعل العمليات ذرية (Atomic): مجموعة القيود التي تشكل معاملة واحدة (مثل عملية الشراء) يجب أن تنجح كلها معاً أو تفشل كلها معاً. استخدم الـ Transactions في قاعدة البيانات لضمان هذا الأمر.

الخلاصة: نوم هانئ للمحاسبين والمبرمجين 😴

الانتقال إلى نموذج دفتر الأستاذ غير القابل للتغيير كان أحد أفضل القرارات التقنية التي اتخذناها. لقد حوّل عملية التسوية من كابوس يستمر لأسابيع إلى عملية روتينية تتم في دقائق. الفوائد كانت هائلة:

• دقة 100%: لم نعد نتساءل “أين ذهبت الأموال؟”.
• قابلية تدقيق كاملة: يمكننا تتبع كل قرش من دخوله النظام إلى خروجه.
• وضوح وثقة: أصبح لدى فريق المحاسبة ثقة كاملة في الأرقام التي ينتجها النظام.
• تقارير فورية: يمكننا معرفة أرباحنا ورصيدنا في أي لحظة، وليس فقط في نهاية الشهر.

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

ودمتم سالمين.