برمجيات التقنية المالية

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

أغلى الأخطاء في الأنظمة التي تحمل تدفّقًا ماليًا هي:

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

تُنتج كلّ حركة مالية سطرين على الأقلّ: مدين ودائن. والرصيد هو حاصل جمع هذه السطور؛ ولا يُحفظ في حقل مستقلّ. وبذلك يمكن دائمًا الإجابة عن سؤال «لماذا الرصيد هكذا؟» بقائمة الحركات.

ويحمل كلّ استدعاء خارجي مفتاح عملية (idempotency). فالطلب الثاني الوارد بالمفتاح نفسه لا يُنتج سجلًّا جديدًا، بل يعيد نتيجة الطلب الأول. ونشرح تفصيله في دليل مفتاح العملية في تكامل واجهات API.

وبين حالات العملية تُعدّ «لم يصل ردّ» حالة مستقلّة، ولا تُحسب فاشلة تلقائيًا. وتُغلق هذه السجلّات بملفّ المطابقة الوارد من الطرف المقابل.

• الدفتر: دليل الحسابات، وسطور المدين والدائن، وإقفال الفترة، وتعدّد العملات.
• الدفع: نقاط البيع الافتراضية، والتقسيط، والإرجاع الجزئي، ومرجع الإرجاع، ومسار 3D.
• المحفظة / الرصيد مسبق الدفع: الشحن، والإنفاق، والحجز، والإرجاع، وحدّ الرصيد.
• المطابقة: مطابقة ملفّات البنوك ومؤسسات الدفع، وقائمة الفروق.
• العمولة والاستقطاع: تسجيل العمولة والحجز وفرق تاريخ القيمة بنودًا منفصلة.
• الصلاحيات والتدقيق: الوصول القائم على الأدوار، ونطاق البيانات، وسجلّ تدقيق غير قابل للحذف.

حركة الحسابات البنكية وقنوات التحصيل (التكامل البنكي)، ونقاط البيع الافتراضية ومؤسسات الدفع، وأنظمة المستندات الإلكترونية، والمحاسبة وERP، وخدمات التحقّق من الهوية، وطبقة تكامل واجهات API للتطبيقات المؤسسية.

• تشفير على مستوى الحقل في الحقول الحسّاسة؛ وتُستبدل ببيانات البطاقة رموز بديلة.
• تُحدَّد الصلاحية بـنطاق البيانات إلى جانب الصلاحية القائمة على الأدوار.
• يُحفظ سجلّ التدقيق منفصلًا وبصورة غير قابلة للتعديل.
• في استدعاءات الخدمات الخارجية تُعرَّف المهلة وإعادة المحاولة وسلوك قاطع الدارة.
• يُتحقّق من خطّاف الويب بفحص التوقيع؛ وتُرفض إعادة الإرسال.

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

• الرصيد مسبق الدفع / المحفظة: متابعة مسار الشحن والإنفاق والإرجاع بدفتر قابل للتدقيق.
• منصّة تحصيل: مطابقة تلقائية للتحصيل الوارد من قنوات متعدّدة مع الحساب الجاري.
• تحصيل الموزعين/الاشتراكات: الدفع المتكرّر، وإدارة السحب الفاشل، وسياسة إعادة المحاولة.
• مسار الدفع في السوق الإلكتروني: مستحقّات البائع، واستقطاع العمولة، وحساب يوم الدفع.

1. الدفتر والهوية: دليل الحسابات، وآلة الحالات، وقاعدة مفتاح العملية.
2. ربط القنوات: نقاط البيع الافتراضية، والبنك، ومسارات الإرجاع والإرجاع الجزئي.
3. المطابقة: تحليل الملفّات، وقواعد المطابقة، وقائمة الفروق.
4. التقارير: ضبط العمولة، وتقادم الذمم، وتوقّع النقد.

هل تحتفظون ببيانات البطاقة في النظام؟

التصميم الافتراضي هو عدم الاحتفاظ ببيانات البطاقة: بل يُحفظ الرمز البديل العائد من مؤسسة الدفع. وفي الحالات التي يلزم فيها الاحتفاظ ببيانات البطاقة في النظام، يتغيّر النطاق والمسؤولية، ويُتّفق على ذلك على حدة في بداية المشروع.

هل يمكن ضمان تنفيذ العملية «مرّة واحدة بالضبط»؟

لا في الأنظمة الموزّعة. فالهدف الواقعي هو وصول الطلب مرّة واحدة على الأقلّ، وألّا يعالج المستقبِل الطلب نفسه مرّة ثانية. ويوفّر ذلك مفتاح العملية وآلة الحالات.

كيف تُصنَّف فروق المطابقة؟

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

كيف تعمل مع نظام المحاسبة الحالي لدينا؟

الدفتر لا يحلّ محلّ المحاسبة؛ بل يُنتج القيود التي ستُنقل إليها. ويُعرَّف في بداية المشروع دوريةُ النقل والتفصيلُ الذي تُنتَج به القيود.