السجلات والأنظمة الأساسية Core bankingLedgers and core banking

السجلّ قائمة بكل حركة دخلت أو خرجت، مرتّبة بترتيب حدوثها. والرصيد ليس رقماً محفوظاً في خانة، بل حاصل جمع تلك الحركات. والنظام الأساسي هو البرنامج الذي يمسك هذا السجلّ.

الحقيقة في نظام المال هي قائمة الحركات التي أوصلت الحساب إلى حالته الحالية.

ليش ما أحفظ الرصيد في عمود وأزيد وأنقص عليه؟

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

وهو خطأ يُدمّر أنظمة مالية، والسبب أنه يفقد التاريخ.

فتخيّل أن رصيد عميل صار ٤٧٠ ريالاً وهو يقول إنه يجب أن يكون ٥٢٠. فماذا تفعل؟ عندك رقم واحد لا يخبرك من أين جاء. ولا تعرف هل خُصم مرتين، أم لم تُقيَّد دفعة، أم كان الخطأ قبل شهرين.

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

وهذه هي فكرة «السجلّ» كلها: أن الحقيقة هي قائمة ما حدث، لا آخر رقم ظهر.

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

فمن يعدّل سطراً في سجلّ مالي لا يصلح خطأً، بل يمحو دليلاً.

القيد يسبق الرصيد

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

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

ويُسمى تسجيل كل حركة في طرفين «القيد المزدوج» Double-entry. فإذا دفع عميل ١٠٠ ريال لمتجر، ينخفض حساب العميل ١٠٠ ويزيد حساب مستحقات المتجر ١٠٠. ويكون مجموع الطرفين صفراً داخل النظام.

الصفر اختبار لا تجميل

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

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

واكتب قاعدة قاعدة البيانات بحيث ترفض العملية غير المتوازنة قبل حفظها. واجمع طرفي القيد في معاملة واحدة، فلا يثبت الخصم دون الإضافة. ويجب أن يكون التوازن خاصاً بكل عملة، لأن ريالاً ودولاراً لا يلغي أحدهما الآخر.

استخدم الوحدة الصغرى

وخزّن المال أعداداً صحيحة من أصغر وحدة. فمثل مبلغ ١٠٫٢٥ ريالاً بالعدد 1025 هللة. ولا تستخدم عدداً عشرياً عائماً، لأن الحاسوب لا يمثل بعض الكسور بدقة وقد ينتج 0.3000000004.

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

وحدد سياسة التقريب عند حدود واضحة. فقد ينتج حساب رسم جزءاً من هللة. ويجب أن يعرف النظام هل يقرب للأقرب أو للأسفل ومن يتحمل الباقي. ولا تترك كل خدمة تختار قاعدة مختلفة.

لا تعدل التاريخ

ويعني القيد «غير القابل للتعديل» Immutable أنه لا يتغير بعد تسجيله. فإذا دفعت الشركة ٥٠ ريالاً بالخطأ، لا يفتح الموظف السطر ويكتب ٥. وإنما يضيف قيداً معاكساً يعيد ٥٠، ثم يضيف القيد الصحيح بقيمة ٥.

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

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

افصل الحالات المالية

وقد يكون رصيد العميل الدفتري ١٠٠٠ ريال، لكن المتاح ٨٠٠ فقط. فقد حجز فندق ٢٠٠ ولم يسوها بعد. ولذلك افصل الرصيد الدفتري عن المتاح وعن المبالغ المعلقة والمحجوزة.

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

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

طابق العالم الخارجي

وتعني «المطابقة» Reconciliation مقارنة سجلك بمصدر حقيقة خارجي مثل كشف البنك أو ملف شبكة البطاقات. فقد يقول سجلك إنك تنتظر ١٠٠ ألف ريال، بينما أودع البنك ٩٩ ألفاً. ويحتاج الفرق تفسيراً بعملية ورسوم وتوقيت.

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

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

صمم العملية من طرفها إلى طرفها

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

واختبر السيناريوهات المؤلمة قبل الإطلاق. فأوقف الخدمة بعد قبول المزود وقبل القيد، وأرسل الإشعار مرتين، وأخر ملف التسوية يوماً. ويجب أن يعود النظام إلى نتيجة واحدة متوازنة دون تعديل يدوي للتاريخ.

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