Blog / Global Digital Vibes

ClefinCode - Core Banking ERP الجزء 2 – نموذج البيانات، دفتر الأستاذ والمنتجات الأساسية

في سياقنا المصرفي الأساسي، تشمل الكيانات الرئيسية: Client (الطرف الذي يمتلك الحسابات)، Account (مثل حسابات الودائع أو القروض المرتبطة بالعميل)، Transaction (حركات الأموال التي تؤثر على الحسابات)، Product Definition (المواصفات الخاصة بالمنتجات المالية)، و General Ledger Entry

September 15, 2025 · 59 min read

النموذج البياني المعياري وكيانات المصرف الأساسية

يُعتبر نموذج البيانات القوي أساس نظام المصرف الأساسي. فهو يحدد جميع الكيانات التجارية الرئيسية وعلاقاتها بطريقة متسقة وموحدة [1]. في سياقنا المصرفي الأساسي، تشمل الكيانات الرئيسية: Client (الطرف الذي يمتلك الحسابات)، Account (مثل حسابات الودائع أو القروض المرتبطة بالعميل)، Transaction (حركات الأموال التي تؤثر على الحسابات)، Product Definition (المواصفات الخاصة بالمنتجات المالية)، و General Ledger Entry (سجلات المحاسبة المزدوجة) [1]. تُشكل هذه الكيانات المعيارية نظام السجل لعمليات البنك، مما يضمن أن جميع الوحدات (الودائع، القروض، المدفوعات، إلخ) تتحدث بلغة مشتركة عن العملاء والحسابات والمعاملات.

تشمل مبادئ التصميم الأساسية مستوى عالٍ من التطبيع (3NF أو أعلى) لقاعدة بيانات المعالجة المعاملاتية عبر الإنترنت (OLTP) للقضاء على الشذوذ وضمان سلامة البيانات [1]. على سبيل المثال، يتم تخزين بيانات العميل مرة واحدة وربطها بجميع حساباته، وكل حساب يشير إلى تعريف منتج بدلاً من تكرار خصائص المنتج. هذا النموذج المعياري يتجنب التعريفات المعزولة أو المكررة لـ “client” أو “account” عبر الوحدات، مما يتيح الاتساق وسهولة التكامل. إذا كانت هناك حاجة إلى أداء تحليلي، يمكن إجراء إلغاء التطبيع في مخططات تقارير منفصلة أو مستودعات بيانات، وليس في مخطط OLTP الأساسي [1].

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

erDiagram
    Client ||--o{ Account : "owns" 
    Account ||--o{ Transaction : "records" 
    Account ||--|| ProductDefinition : "of type" 
    ProductDefinition ||--o{ InterestRateCurve : "uses" 
    ProductDefinition ||--o{ FeeSchedule : "uses" 
    LoanAccount ||--|{ Collateral : "secured by" 
    Account ||--|| GLAccount : "mapped to" 
    Transaction ||--o{ GLPosting : "posts"

الشكل: مخطط ERD مبسط لكيانات المصرف الأساسية (client, account, transaction, product, GL, إلخ). يمكن لكل Client أن يمتلك عدة Accounts (مثل: التوفير، الجاري، القرض). ينتج كل Account العديد من Transactions مع مرور الوقت. يرتبط الحساب بـ ProductDefinition الذي يحدد شروطه (معدلات الفائدة، الرسوم) عبر InterestRateCurve و FeeSchedule. قد تشير حسابات Loan إلى Collateral. ترتبط الحسابات بـ GL accounts لأغراض المحاسبة، وتولد كل Transaction GL postings متوازنة. يفصل هذا التصميم بشكل واضح بين بيانات العملاء، إعدادات المنتجات، والسجلات المالية، متبعاً نموذجاً معيارياً [1].

يستخدم نموذج البيانات أنواع بيانات وقيود صارمة مناسبة للمجال المصرفي: يتم استخدام أنواع رقمية ذات فاصلة ثابتة للمبالغ النقدية لتجنب أخطاء الفاصلة العائمة؛ المفاتيح تكون فريدة وغير فارغة، إلخ. هذا يفرض الاتساق على مستوى قاعدة البيانات. من خلال تعريف العلاقات (foreign keys) بين الجداول (على سبيل المثال كل Account يرتبط بـ Client و Product)، نحافظ على سلامة المراجع – لا يمكن أن يوجد حساب بدون عميل صالح، إلخ. كما أن دليل الحسابات (هيكل GL) هو أيضاً جزء من نموذج البيانات، مما يضمن أن كل معاملة مالية لديها حسابات دفتر أستاذ مناسبة معرفة. بشكل عام، هذا النموذج المعياري محايد للتطبيقات وشامل، ويعمل كـ “خزنة رقمية” لجميع البيانات المالية للبنك [1][1].

دفتر الأستاذ المزدوج: الثبات، المعالجة المكررة، والمطابقة

في صميم المصرف الأساسي يوجد General Ledger (GL)، والذي يعمل وفقاً لمبادئ المحاسبة ذات القيد المزدوج. كل معاملة مالية تسجل على الأقل قيد مدين واحد وقيد دائن واحد بمبالغ متساوية، مما يضمن بقاء دفتر الأستاذ متوازناً في جميع الأوقات [1]. يُطبق النظام قواعد القيد المزدوج بشكل صارم – لأي عملية تسجيل، يجب أن يكون مجموع المدين مساوياً لمجموع الدائن – مما يضمن حالة متوازنة ومتسقة للدفاتر [1]. يتم التعامل مع القيود المركبة متعددة الأطراف (على سبيل المثال، صرف قرض يؤثر على عدة حسابات) بشكل ذري: إما أن تُسجل جميع الأطراف أو لا شيء، مما يحافظ على سلامة المعاملات بما يتماشى مع مبادئ ACID [1].

الثبات (Immutability): بمجرد تسجيل معاملة في دفتر الأستاذ، يجب أن تكون غير قابلة للتغيير – لا يتم أبداً تحديث أو حذف القيود التاريخية، وإنما يمكن فقط إضافة قيود جديدة لمعادلة أو عكس القيود السابقة. تتم التصحيحات عبر قيود عكسية بدلاً من تعديل القيد الأصلي [1]. يوفر هذا النهج مسار تدقيق واضح: يظهر الخطأ الأصلي وقيد التصحيح معاً، ويبقى دفتر الأستاذ سجلاً زمنياً واضحاً لا يمكن العبث به. على سبيل المثال، إذا تم المبالغة في احتساب الفائدة المستحقة، يتم إدخال قيد عكسي (سالب) لإلغاء الفرق، بدلاً من تعديل القيد الأصلي للفائدة. يُعتبر الثبات أمراً بالغ الأهمية ليس فقط للامتثال للتدقيق، ولكن أيضاً للاتساق المنطقي (منع التغييرات بأثر رجعي التي قد تفك الارتباط بين الدفاتر الفرعية أو التقارير). يحافظ النظام على سجلات قابلة للتحقق من جميع تغييرات البيانات الحرجة لدعم التدقيق [1].

المعالجة المكررة (Idempotency): في بيئة موزعة أو تعتمد على الخدمات المصغرة (microservices)، يجب أن يتعامل نظام تسجيل القيود في دفتر الأستاذ مع الطلبات المكررة أو المعاد إرسالها بشكل آمن. يتم تحديد كل معاملة بواسطة مرجع فريد (transaction ID أو GUID). تكون منطقية التسجيل idempotent، أي إذا تم استلام رسالة المعاملة نفسها مرتين (بسبب إعادة محاولة من الشبكة أو خطأ)، فسيتعرف النظام على التكرار ولن يسجلها مرتين. يمكن تحقيق ذلك عن طريق التحقق من وجود transaction ID في دفتر الأستاذ قبل إنشاء قيد جديد. تضمن المعالجة المكررة أن العملاء لا يتم خصمهم مرتين وأن الحسابات تبقى دقيقة حتى إذا حدثت مشكلات في الاتصال أثناء عملية التسجيل.

المطابقة مع الدفاتر الفرعية (Sub-Ledgers): في المصرف الأساسي، غالباً ما تحتفظ أنظمة المنتجات مثل الودائع، القروض، البطاقات، والمدفوعات بـ دفاتر فرعية (سجلات حسابات تفصيلية) يتم تجميعها في دفتر الأستاذ العام. من الضوابط الأساسية مطابقة هذه الدفاتر الفرعية مع حسابات التحكم في GL. على سبيل المثال، يجب أن يكون مجموع جميع أرصدة حسابات ودائع العملاء (من نظام الودائع) مساوياً لرصيد حساب GL “التزامات الودائع” (حساب تحكم) في GL [2]. يقوم النظام بأتمتة هذه المطابقة من خلال إنشاء تقارير أو فحوصات تقارن مجموع الحسابات الفردية مع رصيد GL. “المفتاح لمطابقة الودائع هو التأكد من أن رصيد حساب GL الخاص بودائع العملاء (حساب تحكم) يتوافق مع دفتر حسابات الودائع التفصيلي”[2]. أي فرق سيشير إلى خطأ في التسجيل أو مشكلة في النظام يجب التحقيق فيها. تمتد هذه المطابقة لتشمل القروض (مجموع كل أرصدة أصل القروض يجب أن يساوي GL الخاص بالقروض المستحقة القبض)، والبطاقات (إجمالي المستحقات مقابل GL)، إلخ. قد يفرض الهيكل هذا من خلال قواعد تسجيل معاملاتي – مثل: عند تغير رصيد حساب وديعة، يتم إنشاء قيد GL مطابق فوراً للحفاظ على التزامن – وأيضاً من خلال فحوصات نهاية اليوم.

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

علاوة على ذلك، تتم معالجة التزامن والذرية (concurrency and atomicity) بعناية: يتم التسجيل في حسابات ودفاتر متعددة ضمن معاملة قاعدة بيانات واحدة لمنع أي تحديثات جزئية – مثل أن يتم إدخال جانبي القيد المزدوج أو لا شيء. يستخدم نظام المصرف الأساسي عادة قدرات المعاملات (ACID) الخاصة بقاعدة البيانات لضمان ذلك (غالباً مع الإجراءات المخزنة أو مدير المعاملات في الكود). يتم ضبط مستويات العزل (Isolation) بحيث لا تؤثر الحالة المؤقتة لمعاملة على أخرى (لا توجد قراءات غير دقيقة على حسابات الأرصدة، إلخ)، مما يحافظ على الاتساق[1].

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

تعريفات JSON Schema للمنتجات والحسابات

لتمكين التكامل والتمدد المرن، يمثل النظام الكائنات الأساسية باستخدام JSON schemas – وهي ممارسة مستخدمة في منصات المصرف الأساسية الحديثة [4]. إن تعريف الكائنات مثل الحسابات والمنتجات في JSON يجعلها سهلة التسلسل لـ APIs ويسمح بالتمدد المعتمد على الإعدادات. “تستخدم Zeta Tachyon مخططات JSON قابلة للتمدد كتمثيل داخلي لكل كائن. يأتي كل مخطط مع سمات معرفة مسبقاً، ويمكن للمؤسسات المالية بسهولة تمديد المخطط لإضافة حقول أو هياكل مخصصة.”[4] نحن نتبنى نهجاً مشابهاً: كل كيان أساسي (product definition، حساب وديعة، حساب قرض، إلخ) لديه مخطط JSON أساسي يمكن تمديده حسب الحاجة دون كسر المنطق الأساسي.

فيما يلي نقدم أمثلة على هياكل JSON schema (على مستوى مخطط عام) لعدة كيانات رئيسية في محرك المنتجات. تحدد هذه المخططات السمات وأنواع البيانات التي سيتضمنها كل كيان. عملياً، يمكن صياغتها رسمياً باستخدام معيار JSON Schema (مع "type": "object", "properties": {...})، ولكن هنا نعرضها كبيانات شبيهة بـ JSON من أجل التوضيح.

ProductDefinition: يحدد معايير المنتج المالي (وديعة، قرض، إلخ). يتضمن المعرفات، فئة المنتج، العملة، إعدادات الفائدة والرسوم، إلخ.

{
  "productId": "TD-12M-USD",
  "name": "12-Month Fixed Term Deposit USD",
  "category": "TermDeposit",
  "currency": "USD",
  "termMonths": 12,
  "interestRateCurve": {
      "rateType": "Fixed",
      "annualRate": 0.05
  },
  "feeSchedule": {
      "earlyWithdrawalFeePercent": 1.0
  },
  "penaltyRate": 0.00,
  "allowOverdraft": false
}

مثال: منتج وديعة لأجل بفائدة سنوية ثابتة 5%، مدة 12 شهراً، ورسوم 1% على السحب المبكر. سيحدد JSON schema الخاص بـ ProductDefinition كل نوع حقل بشكل رسمي (مثل productId كسلسلة نصية، category كقائمة قيم enum، interestRateCurve ككائن له مخطط خاص به، إلخ)، مما يضمن الاتساق عبر جميع منتجات البنك.

DepositAccount: يمثل حساباً تحت الطلب (مثل CASA – الحساب الجاري أو التوفير). يرتبط بعميل ومنتج، ويتتبع الرصيد والحالة.

{
  "accountId": "SA-10004567",
  "clientId": "C000123",
  "productId": "CASA-SAV-USD",
  "branchCode": "001",
  "currency": "USD",
  "balance": 5023.55,
  "availableBalance": 5023.55,
  "status": "Open",
  "openedDate": "2025-09-01",
  "accruedInterest": 5.23
}

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

LoanAccount: يمثل تسهيلاً ائتمانياً (قرضاً) حصل عليه العميل. يتضمن رأس المال، شروط الفائدة، الجدول الزمني، ويرتبط بالضمانات ومعلومات المخصصات.

{
  "loanAccountId": "LN-000091",
  "clientId": "C000987",
  "productId": "TERM-LOAN-USD",
  "principalAmount": 10000.00,
  "currency": "USD",
  "disbursementDate": "2025-01-15",
  "maturityDate": "2026-01-15",
  "interestRateCurve": {
      "rateType": "Floating",
      "index": "SOFR",
      "margin": 0.02
  },
  "repaymentSchedule": [
      { "dueDate": "2025-02-15", "amountDue": 881.67, "status": "Paid" },
      { "dueDate": "2025-03-15", "amountDue": 881.67, "status": "Due" },
      "... (etc for each installment) ..."
  ],
  "collaterals": [
      { "collateralId": "COL-44556", "type": "RealEstate", "value": 15000.0 }
  ],
  "stage": "Stage1",
  "expectedCreditLoss": 45.00
}

مثال: قرض لأجل قدره 10,000 دولار مع أقساط شهرية. يتضمن مخطط LoanAccount حقولاً لرأس المال الأصلي، التواريخ الأساسية، InterestRateCurve (هنا معدل عائم محدد بمؤشر + هامش)، ومصفوفة repaymentSchedule التي تسرد تاريخ الاستحقاق والمبلغ المستحق لكل قسط. كما يمكنه الإشارة إلى Collateral مقدم للقرض (بالمعرف، النوع، القيمة). بشكل لافت، يتضمن حقلاً لـ stage و expectedCreditLoss لدعم مخصصات IFRS 9 (المرحلة 1/2/3 ومخصص الخسارة المقابل). يوضح هذا كيف أن نموذج البيانات مهيأ لبيانات مخاطر الائتمان.

InterestRateCurve: يحدد كيفية احتساب معدلات الفائدة لمنتج ما. بدلاً من معدل واحد، يمكن أن يشمل معدلات متدرجة، مؤشرات، إلخ. للتبسيط، يظهر مثالان: معدل ثابت ومعدل عائم مرتبط بمؤشر:

{
  "rateType": "Fixed",
  "annualRate": 0.05
}

{
  "rateType": "Indexed",
  "index": "SOFR",
  "indexTerm": "3M",
  "margin": 0.015
}

في مصطلحات JSON schema، قد يكون InterestRateCurve هيكل oneOf يسمح بأنواع فرعية مختلفة (ثابت مقابل عائم)، أو كائن واحد مع حقول اختيارية اعتماداً على rateType. يُستخدم هذا الكائن من قبل ProductDefinition أو LoanAccount لحساب الفائدة.

FeeSchedule: يحدد الرسوم المطبقة على منتج أو حساب. يمكن أن يكون قائمة من عناصر الرسوم مع محفزات (مبنية على الأحداث أو دورية). على سبيل المثال:

{
  "fees": [
    { "feeCode": "MONTHLY_MAINT", "description": "Monthly Maintenance Fee", "amount": 5.00, "frequency": "Monthly" },
    { "feeCode": "OVERDRAFT_FEE", "description": "Overdraft Usage Fee", "amount": 25.00, "trigger": "OverdraftUsed" }
  ]
}

هذا يشير إلى رسم شهري قدره 5 دولارات ورسم 25 دولاراً في كل مرة يتم فيها استخدام السحب على المكشوف. يضمن المخطط أن كل إدخال رسوم يحتوي على الحقول المطلوبة (feeCode، amount، وأما frequency أو شرط trigger). سيقوم محرك المنتجات في النظام المصرفي الأساسي بتفسير هذا الهيكل لفرض الرسوم تلقائياً في الأوقات المناسبة.

Collateral: يمثل الأصول المرهونة مقابل القروض. قد يتضمن مخطط بسيط معرفاً، نوعاً، قيمة تقديرية، وربطاً بالقرض أو العميل:

{
  "collateralId": "COL-44556",
  "type": "RealEstate",
  "description": "123 Elm St. Property",
  "valuationAmount": 15000.0,
  "valuationDate": "2024-12-01",
  "linkedLoanId": "LN-000091"
}

قد يتضمن Collateral أيضاً حقولاً لحسابات LTV (loan-to-value) أو تقييمات متعددة. سيتم ربط الضمانات بحسابات القروض، ولكن يتم الاحتفاظ بها ككيان منفصل للمرونة (يمكن أن يضمن ضمان واحد عدة قروض أو العكس في السيناريوهات المعقدة).

تجعل هذه مخططات JSON النظام قابلاً للتمدد. يمكن لأنواع المنتجات الجديدة إدخال حقول أو كائنات جديدة دون تعديل الكود الأساسي – على سبيل المثال، إضافة حقل "rewardPoints" إلى مخطط حساب بطاقة الائتمان، أو سمات إضافية إلى Client (معلومات KYC، إلخ). كما أن استخدام JSON يسهل التكامل عبر REST APIs: يمكن للبيانات التدفق داخلاً وخارجاً بصيغة ذاتية الوصف يفهمها الأنظمة الخارجية. هذا يتماشى مع بنية معتمدة على الـ API وأنماط “schema-on-read” الحديثة حيثما كان مناسباً. سيتم التحكم في نسخ كل مخطط لإدارة التغييرات بمرور الوقت.

ملاحظة: نحن لا نكرر الحقول أو الوحدات القياسية الخاصة بـ ERPNext هنا (مثل بيانات العملاء الرئيسية، والتي يتعامل معها ERPNext بالفعل) – نحن نركز على عناصر المخطط الجديدة الخاصة بالمصارف. من خلال الاستفادة من إطار عمل doctype الخاص بـ ERPNext (المدعوم بـ MariaDB)، يمكن لهذه الهياكل المحددة بـ JSON أن تُطابق مع doctypes أو جداول فرعية حسب الحاجة، ولكن تمثيل JSON يوفر مخططاً واضحاً وغير متعلق بالتكنولوجيا لنموذج البيانات.

تقسيم دفتر الأستاذ العام للمحاسبة متعددة الفروع وبين الفروع

تعمل البنوك غالباً بفروع أو كيانات قانونية متعددة، مما يستلزم تصميماً مجزءاً لدفتر الأستاذ العام (GL) لتتبع البيانات المالية حسب الفرع أو المنطقة أو القسم، إلخ. بدلاً من رقم حساب مسطح، يتم عادةً تنظيم دليل الحسابات بعدة مقاطع في كل كود GL. كل مقطع يرمز إلى بعد من أبعاد العمل – على سبيل المثال: رمز الفرع، رمز الحساب الطبيعي، وربما رمز المنتج/القسم[5][5]. يسمح دفتر الأستاذ المجزأ بالتقارير المرنة (يمكن إنشاء ميزان مراجعة على مستوى الفرع أو تقارير مالية موحدة لجميع الفروع عن طريق الجمع عبر المقاطع).

على سبيل المثال، قد يتم تنسيق كود GL كـ [Branch]-[AccountType]-[Product]. لنفترض أن “1000” يرمز إلى الحساب الطبيعي للنقد، و“01” هو الفرع 1، و“02” هو الفرع 2. إذن النقد في الفرع 1 يمكن أن يكون الحساب 01-1000، والنقد في الفرع 2 02-1000. يمكن إعداد تقارير لكل مقطع بشكل فردي أو مجتمعة[5][5]. عن طريق جمع 01-1000 و02-1000، نحصل على إجمالي النقد. من خلال النظر إلى المقطع 01 عبر جميع الحسابات، نحصل على الميزانية العمومية للفرع 1. يلبي هذا التصميم المتطلبات التنظيمية حيث يجب تتبع أداء كل فرع، كما يتيح أيضاً دمج البيانات على مستوى المؤسسة. وكما يوضح أحد المصادر: “المقطع هو جزء من دليل الحسابات يمثل عنصراً من هيكل عملك، مثل قسم أو موقع أو فرع أو منطقة أو منتج. يتم دمج كل مقطع لتشكيل سلسلة GL.”[5]. المفتاح هو اختيار المقاطع التي تلتقط مناظر التقارير المطلوبة دون جعل رموز الحسابات طويلة أو معقدة بشكل مفرط [5]. في تصميمنا، سنشمل مقاطع على الأقل لـ الفرع والحساب الطبيعي، وربما النوع الفرعي (مثل خط المنتج أو مركز التكلفة) إذا لزم الأمر للتحليل الربحي التفصيلي.

التجميع متعدد الفروع (Multi-Branch Consolidation): سيدعم النظام إعداد بيانات مالية موحدة عبر الفروع. يمكن القيام بذلك من خلال هيكلة هرمية لمقطع الفرع (على سبيل المثال، رموز المناطق تجمع عدة فروع) أو عبر عمليات تجميع منفصلة. على سبيل المثال، قد تنتمي رموز الفروع “001” و“002” إلى المنطقة “01”، بحيث يمكن تجميع البيانات المالية عن طريق الجمع على مستوى المنطقة. يمكننا تخصيص رمز فرع خاص (مثل “000” أو “HO”) للحسابات الخاصة بالمقر الرئيسي أو الموحدة. قد يسمح التصميم بـ التجميع متعدد المستويات، مثل: فرع -> منطقة -> بلد -> مجموعة، عن طريق التعامل مع المقطع الأول كرمز هرمي. تسمح الأنظمة المصرفية الأساسية الحديثة بـ التقارير الطبقية بحيث يتم إنتاج ميزان مراجعة منفصل، حساب الأرباح والخسائر، والميزانية العمومية لجميع الطبقات – فرع، منطقة، قسم، وتجميع شامل[3]. يتبع تصميم دفتر الأستاذ العام لدينا أفضل الممارسات هذه: كل إدخال مالي يحمل معرف الفرع بحيث يكون التجميع المالي الآلي ممكناً دون تعديلات يدوية.

المعاملات بين الفروع (Inter-Branch Transactions): عندما يجري أحد الفروع معاملات مع فرع آخر (أو مع المقر الرئيسي)، يضمن التعامل الخاص بقاء دفاتر كلا الفرعين متوازنة محلياً وأن أرصدة ما بين الفروع متطابقة. عادةً ما يتم استخدام حسابات “مستحق لـ/مستحق من” بين الفروع (Due To/Due From). لأي معاملة تتضمن فرعين، يقوم النظام بإنشاء قيود متطابقة في هذه الحسابات. على سبيل المثال، إذا احتاج الفرع A (001) إلى قيد حساب عميل في الفرع B (002)، فقد تكون القيود: خصم حساب مستحق لـ 002 في الفرع A، وقيد لحساب العميل في الفرع B؛ وفي الوقت نفسه، في دفاتر الفرع B، يتم خصم حساب العميل وقيد حساب مستحق من 001 [6][6]. بهذه الطريقة، تبقى دفاتر كل فرع متوازنة، وتتعادل حسابات المستحق لـ/المستحق من بين الفروع مع بعضها عند التجميع. في نظام Oracle المصرفي على سبيل المثال، يتم تكوين مجموعة من الحسابات الداخلية لكل زوج من الفروع: “مستحق لـ فرع 2” (التزام) و“مستحق من فرع 2” (أصل) في الفرع 1، والعكس صحيح للفرع 2 [6][6]. سيطبق نظامنا مخططاً مشابهاً.

سنقوم بتعريف مصفوفة تسوية بين الفروع (inter-branch settlement matrix) بحيث يعرف النظام أي حسابات GL يجب استخدامها لكل زوج من الفروع (أو الفرع والمقر الرئيسي) للقيود بين الفروع. اعتماداً على تفضيل المؤسسة، يمكن أن تكون المحاسبة بين الفروع: مباشرة (كل زوج من الفروع لديه حسابات مباشرة مع بعضهم)، أو عبر المقر الرئيسي (تتدفق جميع قيود بين الفروع عبر حسابات المقر الرئيسي)، أو عبر مراكز إقليمية [6][6]. مبدئياً، قد ننفذ نهجاً أبسط (مثل عبر المقر الرئيسي)، مما يقلل عدد الحسابات المطلوبة. سيقوم النظام بالتصعيد تلقائياً إلى المستوى المناسب إذا لم تتم المحافظة على علاقة مباشرة [6]. النتيجة هي أن أي معاملة بين الفروع ستولد قيوداً متوازنة في هذه الحسابات الخاصة، والتي يجب أن تتعادل إلى صفر عند تجميع جميع الفروع.

مثال: إذا أرسل الفرع 001 مبلغ 100 دولار إلى الفرع 002 (ربما قام عميل من الفرع 001 بإيداع نقدي يحتاج إلى أن يُقيد في حساب يُدار بواسطة الفرع 002)، فإن النظام سيقوم بـ:

في دفتر الأستاذ للفرع 001: مدين حساب النقد $100، دائن “مستحق لفرع 002” $100.
في دفتر الأستاذ للفرع 002: مدين “مستحق من فرع 001” $100، دائن حساب وديعة العميل $100.

دفاتر الفرع 001 متوازنة (انخفاض أصل النقد، وزيادة التزام بين الفروع). دفاتر الفرع 002 متوازنة (زيادة أصل بين الفروع، وزيادة التزام العميل). من منظور البنك ككل، تتعادل حسابات مستحق لـ/مستحق من 001-002 مع بعضها. يضمن النظام أن تبقى هذه الحسابات بين الشركات (بين الفروع) متزامنة ويوفر تقارير مطابقة لتسليط الضوء على أي مراكز غير متوازنة بين الفروع (والتي قد تشير إلى قيد مفقود في أحد الفروع). يسهل هذا التصميم أيضاً إعداد التقارير التنظيمية حسب الفرع وتسعير التحويلات الداخلية بين الفروع عند الحاجة (يمكن اعتبار الفروع كمراكز ربح تتعامل مع بعضها عبر هذه الحسابات).

أخيراً، قد يتضمن تصميم مقطع دفتر الأستاذ العام قسم أو مقطع منتج إذا لزم الأمر للمحاسبة الداخلية. على سبيل المثال، إذا أردنا تتبع الإيرادات حسب خط المنتج (التوفير مقابل القروض) في GL، فقد ندمج مقطع المنتج أو نستخدم مراكز التكلفة. ومع ذلك، نظراً لأن الدفاتر الفرعية تسجل بالفعل معلومات المنتج، فإن نهجاً بديلاً هو اشتقاق مثل هذه التقارير من الدفاتر الفرعية بدلاً من توسيع دليل الحسابات. في النسخة الأولية (MVP)، قد نحافظ على بنية المقطع بسيطة (فرع + حساب طبيعي)، ونعتمد على الأبعاد في التقارير لربحية المنتجات. يمكن إدخال مقاطع إضافية مع توسع النظام، مع مراعاة التحذير: لا تُنشئ “سلاسل GL طويلة بشكل مبالغ فيه” عن طريق الإفراط في تقسيم المقاطع – التزم بما هو مهم وثابت نسبياً[5].

محرك المنتجات للمنتجات المصرفية الأساسية (CASA، الودائع لأجل، السحب على المكشوف، القروض، إلخ)

محرك المنتجات مسؤول عن تحديد كيفية عمل المنتجات المصرفية المختلفة – من حساب الفوائد إلى الرسوم، الغرامات، والمخصصات. سندعم مجموعة من المنتجات الأساسية: CASA (الحسابات الجارية وحسابات التوفير)، الودائع لأجل، السحب على المكشوف، القروض (تشمل الأفراد، الشركات الصغيرة والمتوسطة، الشركات الكبرى)، بالإضافة إلى الرسوم/العمولات، الغرامات، ومخصص خسائر القروض (IFRS 9). لكل نوع منتج ميزات فريدة، لكن محركنا سيستخدم إطار عمل مشترك بحيث يكون إضافة منتج جديد (أو نسخة منه) في الغالب مجرد تكوين (عبر تعريفات JSON للمنتجات) بدلاً من تغييرات في الكود.

1. الحساب الجاري وحساب التوفير (CASA): هذه هي حسابات الإيداع تحت الطلب. سيتولى محرك المنتجات ما يلي:

احتساب الفوائد على التوفير: عادةً ما تُحتسب الفوائد على حسابات التوفير على الأرصدة اليومية ويتم دفع الفائدة شهرياً أو ربع سنوي. سيستخدم المحرك معدل الفائدة (الذي يمكن أن يكون متدرجاً حسب الرصيد أو ثابتاً) من ProductDefinition ورصيد الحساب اليومي لاحتساب الفائدة. العديد من حسابات التوفير لديها فائدة متدرجة (مثل: 3% للأرصدة حتى $1k، 4% للأرصدة فوق $1k، إلخ)، والتي يمكن أن يمثلها InterestRateCurve كشرائح. الحسابات الجارية (checking accounts) غالباً لا تدفع فوائد (أو تدفع نسبة ضئيلة)، وهو ما يتم تكوينه ببساطة كفائدة 0% في المنتج.
الحد الأدنى للرصيد والرسوم: غالباً ما تفرض منتجات CASA حداً أدنى للرصيد أو رسوم صيانة. يسمح FeeSchedule بتكوين رسوم شهرية مثلاً، يقوم المحرك بفرضها تلقائياً (خصم من الحساب، قيد لحساب دخل الرسوم) وفق جدول محدد. إذا كان المنتج يتطلب حداً أدنى للرصيد، يمكن للمحرك التحقق من الأرصدة وربما إعفاء الرسوم إذا تم استيفاء المعايير.
ميزة السحب على المكشوف: بعض الحسابات الجارية لديها حد للسحب على المكشوف (بشكل أساسي خط ائتمان مرتبط). في نموذجنا، يمكن التعامل مع السحب على المكشوف كمنشأة ائتمانية مرتبطة بالحساب. يمكن لمحرك المنتجات إما اعتباره نوعاً خاصاً من حسابات القروض المرتبطة بحساب الودائع، أو بشكل أبسط، السماح لرصيد حساب الودائع بأن يصبح سالباً حتى حد معين. في كلتا الحالتين، سيتم احتساب الفائدة على السحب على المكشوف (عادة بمعدل أعلى يُفرض على الأرصدة السالبة). يمكننا تكوين معدل فائدة للسحب على المكشوف في المنتج، وسيقوم المحرك باحتساب فائدة السحب على المكشوف كلما كان رصيد الحساب أقل من الصفر. كما تتم معالجة رسوم السحب على المكشوف (رسوم لمرة واحدة على السحب، أو فوائد دورية) من خلال FeeSchedule ومنطق الفائدة.

2. الودائع لأجل (Term Deposits / Fixed Deposits): الوديعة لأجل لها مدة ثابتة وغالباً معدل فائدة ثابت. السلوكيات الرئيسية:

المدة والاستحقاق: يحدد تعريف المنتج طول المدة (مثلاً 12 شهراً) وما إذا كان السحب المبكر مسموحاً. سيتتبع المحرك تاريخ بدء الوديعة وتاريخ استحقاقها. عند الاستحقاق، يمكن أن يتم تجديدها تلقائياً (إذا أشار المنتج إلى التجديد التلقائي) أو قيد الأصل + الفوائد إلى حساب محدد.
الفائدة: عادةً يمكن دفع الفائدة بشكل دوري (مثل دفعات ربع سنوية) أو عند الاستحقاق. يمكن لتكوين المنتج تحديد تكرار دفع الفائدة. سيدعم محرك الفائدة لدينا (كما هو موضح في القسم التالي) كلا من الدفع الدوري (تُقيد الفائدة إما في حساب الوديعة لأجل أو حساب آخر) والتراكم حتى الاستحقاق. إذا تم دفع الفائدة خلال المدة، يبقى الأصل كما هو؛ إذا كانت الفائدة مركبة، تتم إضافة الفائدة إلى الأصل عند تلك الفترات (مما يزيد فعلياً الأساس لحساب الفوائد اللاحقة). قد يكون معدل الفائدة ثابتاً للمدة أو، في بعض الحالات، عائماً مرتبطاً بمؤشر (أقل شيوعاً للودائع، لكن بعض البنوك تقدم ودائع عائمة).
الغرامات على السحب المبكر: إذا كسر العميل الوديعة قبل الاستحقاق، يجب أن يطبق المحرك غرامة أو فائدة مخفضة حسب ProductDefinition. على سبيل المثال، قد يتضمن FeeSchedule earlyWithdrawalFeePercent (كما في مثال JSON لدينا) أو قد يتم تخفيض معدل الفائدة. سيحسب المحرك مبلغ الغرامة (مثل 1% من الأصل أو خسارة فائدة الربع الأخير) ويُنشئ القيود اللازمة (مدين دفعة العميل، دائن حساب دخل الغرامات).
المخصصات: تمثل الودائع لأجل التزاماً على البنك (البنك مدين بالمال للعميل)، لذا فإن مخصصات المخاطر الائتمانية غير مطبقة (المخصصات تخص القروض، وليس الودائع). ومع ذلك، يجب أن يضمن المحرك أن تظهر الودائع لأجل في GL تحت حسابات الالتزامات المناسبة مجزأة حسب الفروع.

3. القروض (Retail/SME/Corporate): القروض هي أصول (مبالغ مستحقة على العملاء للبنك) ولها دورة حياة معقدة. سيتعامل محرك القروض مع:

جداول السداد (Amortization Schedules): بالنسبة للقروض التقليدية للأفراد أو الشركات الصغيرة والمتوسطة، يُستخدم عادةً جدول سداد متناقص مع دفعات دورية متساوية (قسط سنوي/شهري ثابت). يمكن للمحرك إنشاء جدول السداد (كما في LoanAccount JSON) استناداً إلى المدخلات: الأصل، معدل الفائدة، المدة، وتكرار الدفع. سيدعم فترات سماح، دفعات بالونية، إلخ، كما هو مكون. بالنسبة للقروض المؤسسية، قد تكون هناك فترات فوائد فقط أو جداول دفع غير منتظمة – يجب أن يكون المحرك مرناً لقبول جدول مخصص أو هيكل فوائد فقط.
الاستحقاق ورأسملة الفوائد (Accrual and Capitalization): تُحتسب الفوائد على القروض يومياً. سيقوم المحرك إما بتحميلها على القرض (رأسملة إذا لم يتم دفعها) أو استحقاقها للسداد. ندعم رأسملة الفوائد إذا سمح المنتج بذلك (أي إضافة الفوائد غير المدفوعة إلى الأصل، وهو أمر شائع في بعض التسهيلات المؤسسية أو سيناريوهات السداد السلبي)، أو إبقائها منفصلة.
المعدلات العائمة وإعادة التسعير (Floating Rates and Repricing): العديد من القروض، وخاصة المؤسسية، تستخدم معدلات عائمة (مثل SOFR + هامش يتم إعادة ضبطها كل 3 أو 6 أشهر). يحدد InterestRateCurve للمنتج ذلك، ويجب أن يكون المحرك قادراً على إعادة تسعير القروض في المواعيد المحددة. هذا يعني أنه في كل تاريخ إعادة ضبط للمعدل، يتم جلب قيمة المؤشر الجديدة وتحديث معدل القرض الفعلي. قد يتغير جدول المدفوعات المستقبلية (للقروض ذات الدفعات المتغيرة) أو للقروض ذات الفوائد فقط قد تختلف الفوائد المستحقة. يدعم نموذج بياناتنا تخزين المؤشر والهامش في InterestRateCurve هذا. يمكن للنظام أن يتكامل مع مصدر أسعار الفائدة أو يسمح بإدخال أسعار المؤشر يدوياً.
الرسوم والعمولات: غالباً ما تحتوي منتجات القروض على رسوم لمرة واحدة (رسوم إنشاء، رسوم معالجة) ورسوم متكررة (رسوم تجديد سنوية لخطوط الائتمان، رسوم التزام على الأرصدة غير المسحوبة، رسوم تأخير السداد، إلخ). باستخدام FeeSchedule، يمكن لمحرك المنتجات تطبيق هذه تلقائياً: على سبيل المثال، عند صرف القرض، يتم فرض رسوم إنشاء 1% (مدين حساب القرض أو حساب وديعة العميل، دائن حساب دخل الرسوم)؛ على خطوط الائتمان غير المسحوبة، يتم فرض رسوم التزام دورياً؛ عند التخلف عن الدفع، تُفرض رسوم تأخير أو فائدة جزائية.
الفائدة الجزائية (Penalty Interest): إذا تأخر سداد القرض، قد يتم فرض فائدة على المبلغ المتأخر بمعدل جزائي أعلى. يمكن أن يتضمن تعريف المنتج معدل جزائي أو قواعد جزائية (مثل: بعد 10 أيام من التأخير، فرض 2% إضافية على القسط المتأخر). سيكتشف المحرك المبالغ المتأخرة ويحتسب الفائدة الجزائية وفقاً لذلك، بشكل منفصل عن الفائدة العادية.
المخصصات (IFRS 9): بالنسبة للقروض، يجب التعامل مع مخصص خسائر القروض وفقاً لنموذج الخسائر الائتمانية المتوقعة (ECL) في IFRS 9. يتطلب IFRS 9 أنه من اليوم الأول، يتم الاحتفاظ بمخصص لانخفاض محتمل في القيمة، وأن يتم تصنيف القروض في ثلاث مراحل تعكس التدهور الائتماني [7]: المرحلة 1 (قيد الأداء – خسارة متوقعة لمدة 12 شهراً)، المرحلة 2 (زيادة كبيرة في المخاطر الائتمانية – خسارة متوقعة مدى الحياة)، المرحلة 3 (متعثرة – خسارة متوقعة مدى الحياة مع الاعتراف بإيراد الفائدة على أساس صافٍ). سيحافظ محركنا على حقل المرحلة (stage) في كل LoanAccount (كما هو موضح في JSON) ومخصص الخسارة المقابل. في البداية، يكون القرض الجديد في المرحلة 1 ونحسب مخصصاً (مثل 0.5% من التعرض كـ ECL لمدة 12 شهراً، حسب معايير المخاطر). إذا زادت المخاطر الائتمانية للقرض (مثل: تجاوز الاستحقاق 30 يوماً أو معايير أخرى)، ينتقل إلى المرحلة 2 وتزداد المخصصات إلى خسارة متوقعة مدى الحياة (وهي أعلى). المرحلة 3 إذا تعثر. يتم بالتالي تصنيف القروض إلى ثلاث مراحل: المرحلة 1 (Performing)، المرحلة 2 (Under-performing)، والمرحلة 3 (Non-performing)[7]. سيتكامل محرك المنتجات مع وحدة المخصصات التي قد تحسب ECL الفعلي (باستخدام نماذج PD، LGD، EAD – قد تكون خارج نطاق النسخة الأولية MVP للتنفيذ الكامل). ومع ذلك، كحد أدنى سيدعم النظام تحديث المخصصات يدوياً أو عبر مخصصات مبنية على قواعد بسيطة (مثل: المرحلة 1 = 1%، المرحلة 2 = 5%، المرحلة 3 = 50% أو حسب الحالة). يجب أن يُنشئ المحرك شهرياً قيود مخصصات: مدين مصروف المخصص (P&L) ودائن مخصص خسائر القروض (حساب مقابل للأصول) في GL لأي زيادة مطلوبة في المخصص، أو عكس إذا أمكن تحرير المخصصات. يضمن ذلك أن يعكس GL الخسائر الائتمانية المتوقعة للمحفظة بما يتماشى مع IFRS 9. تسمح الحقول stage وECL المخزنة في حساب القرض بالتقارير وتُستخدم في الاعتراف بالفوائد (يجب أن تعترف القروض في المرحلة 3 بالفوائد على أساس صافٍ، مما يعني فعلياً التوقف عن الاحتساب أو فصلها).
إعادة الهيكلة والشطب (Restructuring and Write-offs): يتضمن التعامل المتقدم مع القروض إمكانية إعادة هيكلة القروض (مما قد يتطلب تتبعاً منفصلاً للشروط الأصلية مقابل المعاد هيكلتها) وشطب القروض في المرحلة 3 (Stage 3) (مما ينقلها من الدفاتر النشطة إلى السجلات التذكيرية). على الرغم من أن ذلك قد يكون خارج نطاق النسخة الأولية (MVP)، يتوقع نموذج البيانات لدينا أعلاماً خاصة لإعادة الهيكلة (مثل ربط قرض معاد هيكلته بمعرف القرض الأصلي) وحالة للشطب. يرتبط ذلك بالمخصصات: إذا تم شطب القرض، يتم استخدام أي مخصص متبقٍ.

قروض الأفراد مقابل الشركات الصغيرة والمتوسطة مقابل القروض المؤسسية: الفروق تكمن بشكل أساسي في الحجم والتعقيد: قد تحتوي القروض المؤسسية على عدة سحوبات (tranches)، أو شروط تعاقدية (covenants)، أو تكون مجمعة (syndicated – بعدة مقرضين). قد يتم إدخال هذه الميزات لاحقاً. بالنسبة للنسخة الأولية MVP، يغطي قرض تقليدي متناقص (amortizing) وسحب على المكشوف (خط ائتمان متجدد) معظم الاحتياجات. نصمم محرك المنتجات ليكون معتمداً على المعلمات (parametric) – مثلاً، يمكن نمذجة خط ائتمان متجدد كقرض بدون جدول سداد ثابت ولكن بحد ائتمان وفائدة شهرية مستحقة؛ هذا في الأساس هو كيفية التعامل مع السحب على المكشوف أو بطاقة الائتمان. من خلال تكوين المنتج كـ “متجدد” (دون جدول سداد، فقط دفعات دنيا)، نغطي خطوط الائتمان والبطاقات. يمكن أن يكون القرض المؤسسي طويل الأجل مجرد قرض أكبر ربما مع فوائد فقط ودفعات بالونية – ويمكن تكوينه عبر الجدول. وبالتالي، يخدم محرك واحد الجميع، مع مرونة يوفرها تكوين الجداول ومعدلات الفائدة.

4. الرسوم والعمولات (Fees and Charges): يدعم المحرك نوعين من الرسوم: رسوم مبنية على الأحداث (event-driven) ورسوم دورية (periodic). أمثلة الرسوم المبنية على الأحداث تشمل رسوم أجهزة الصراف الآلي، رسوم التحويلات المالية، رسوم الإغلاق المبكر – يتم تحفيزها عبر معاملة أو إجراء معين. تشمل الرسوم الدورية رسوم الصيانة، رسوم البطاقات السنوية، إلخ، والتي تحدث وفق جدول محدد. يسمح جزء FeeSchedule من تعريفات المنتجات بإعداد هذه الرسوم. من المرجح أن يحتوي المحرك على معالج رسوم (fee processor) يتحقق يومياً من أي رسوم يجب تطبيقها (مثل: في اليوم الأول من كل شهر، يتم خصم الرسوم الشهرية من جميع الحسابات؛ عند إغلاق الحساب، يتم فرض رسوم إغلاق الحساب، إلخ). عند حدوث حدث الرسوم، يُنشئ المحرك القيود المحاسبية المقابلة (مثل: مدين حساب العميل أو القرض، دائن حساب دخل الرسوم المناسب). يمكن أن تكون الرسوم أيضاً متدرجة أو مشروطة (معفاة للعملاء المميزين، إلخ)، والتي يمكن التعامل معها عبر قواعد المنتج أو سمات العميل – يمكن لتصميمنا أن يدمج تقييم القواعد إذا لزم الأمر (ربما لاحقاً، أو عبر البرمجة النصية في ERPNext).

5. الغرامات (Penalties): الغرامات هي في الأساس فئة فرعية من الرسوم/الفوائد ولكنها عادةً ما ترتبط بعدم التزام العميل (مثل التأخير في الدفع). يتعامل المحرك مع الفائدة الجزائية كمعدل فائدة خاص يُفعّل عند حدوث المخالفة. على سبيل المثال، إذا تأخر سداد قرض 10 أيام، قد يتم فرض رسم تأخير بقيمة X$ (رسوم لمرة واحدة)، ويمكن أن تبدأ فائدة جزائية بنسبة Y% على المبلغ المتأخر بالتراكم. يحتاج المحرك إلى مراقبة تواريخ الاستحقاق (التي يعرفها من الجداول) والمبالغ المستحقة لتحفيز هذه الغرامات. يتم تخزين معدلات أو مبالغ الغرامات في تكوين المنتج (أو تكوين عام) لضمان الاتساق. وكما في الرسوم الأخرى، تنتج الغرامات قيود GL (دخل للبنك، وزيادة في التزامات العميل أو مطلب سداد فوري).

6. مخصصات IFRS9: كما ذُكر ضمن القروض، سيتكامل محرك المنتجات مع عملية المخصصات. بالنسبة للنسخة الأولية MVP، قد ننفذ نهجاً مبسطاً: يمكن للنظام تمييز القروض كمرحلة 1/2/3 واستخدام نسب محددة مسبقاً لمخصص الخسائر. النهج الأكثر تقدماً (وربما خارج نطاق MVP) هو التكامل مع نموذج مخاطر ائتمانية (ربما عبر وحدة ClefinCode Analytics أو خدمة خارجية) يحسب الخسارة المتوقعة باستخدام PD (احتمالية التعثر)، LGD (الخسارة عند التعثر)، إلخ، شهرياً. بغض النظر عن طريقة الحساب، يتمثل دور المحرك في الحفاظ على البيانات المطلوبة (مثل الأيام المتأخرة عن الاستحقاق، تغييرات في درجة الائتمان، إلخ، لتحديد المرحلة) وإنشاء القيود المحاسبية الخاصة بالمخصصات. يؤثر IFRS9 أيضاً على الاعتراف بإيراد الفائدة: عندما يكون القرض في المرحلة 3 (متعثر ائتمانياً)، يجب الاعتراف بإيراد الفائدة على صافي القيمة الدفترية (القرض مطروحاً منه المخصص) [8][9] – أي التوقف عن احتساب الفوائد على الجزء المتوقع عدم تحصيله. سيأخذ محرك الفوائد (في القسم أدناه) ذلك في الاعتبار إما بإيقاف الفوائد أو ضمان تحويلها إلى حساب معلق بعد فترة معينة من التأخير (يرتبط هذا بحالة “non-accrual” التي يجب أن يدعمها النظام للقروض في المرحلة 3 – العديد من البنوك تتوقف عن احتساب الفوائد على القروض غير العاملة).

باختصار، يوفر محرك المنتجات إطاراً قائماً على التكوين (config-driven) لإدارة سلوك أنواع الحسابات المختلفة. يمكن إطلاق منتجات جديدة (مثل حساب توفير جديد بهيكل متدرج مختلف، أو نوع قرض جديد) عن طريق إضافة ProductDefinition JSON والمعلمات المرتبطة، دون كتابة كود مخصص لمنطق الفائدة/الرسوم. يستخدم المحرك هذه المعلمات لتوجيه الحسابات اليومية (الفوائد، الرسوم) ومعالجة الأحداث (الاستحقاق، إلخ). من خلال تغطية CASA، الودائع لأجل، السحب على المكشوف، وأنواع القروض المختلفة، نلبي الاحتياجات المصرفية الأساسية للأفراد والأعمال. يمكن التعامل مع منتجات إضافية مثل بطاقات الائتمان بشكل مشابه للسحب على المكشوف/القروض المتجددة، وقد تتم إضافة منتجات تمويل التجارة أو الخزينة لاحقاً (قد تتطلب وحدات منفصلة ولكن تكامل GL سيبقى ثابتاً). نحن نتعمد عدم تكرار وحدات ERPNext القياسية مثل الفواتير العادية أو وظائف المحاسبة غير الخاصة بالمصارف. بدلاً من ذلك، نمد ERPNext بقدرات المنتجات هذه، مع الاستفادة من الأطر الموجودة (مثل: يمكننا استخدام إغلاق الفترات المحاسبية في ERPNext، ولكن معززة بقيود احتساب الفوائد، إلخ). الهدف هو محرك منتجات موحد يضمن معالجة جميع المنتجات المالية بدقة واتساق داخل النظام الأساسي.

محرك حساب الفوائد والرسوم (الاستحقاق، التركيب، السداد، معدل الفائدة الفعلي)

يعد احتساب الفوائد أساسياً في العمل المصرفي، ويجب على محركنا التعامل مع طرق واعتبارات احتساب مختلفة. نقوم بتقسيم ذلك إلى: احتساب الفائدة المستحقة مقابل الفائدة المُرحلة (Interest Accrual vs. Posting)، الفائدة المركبة (Compounding)، إطفاء الفوائد والرسوم (Amortization)، واعتبارات معدل الفائدة الفعلي (Effective Interest Rate - EIR).

الاستحقاق مقابل الأساس النقدي (Accrual vs. Cash Basis): سيستخدم النظام المحاسبة على أساس الاستحقاق للفوائد والرسوم. هذا يعني أن إيراد أو مصروف الفائدة يتم الاعتراف به بمرور الوقت عند اكتسابه أو تكبده، وليس فقط عند الدفع. بالنسبة لحساب الإيداع، فإن مصروف الفائدة على البنك (الفائدة المستحقة للعملاء) يُحتسب يومياً؛ وبالنسبة للقرض، يتم احتساب إيراد الفائدة يومياً عند اكتسابه. سيشغّل المحرك عملية احتساب يومية (أو حتى في الوقت الفعلي مع كل معاملة إذا لزم الأمر) تحسب الفائدة لكل حساب لليوم وتُسجلها. يمكن تسجيل الاستحقاق إما في حقل تذكيري (مثل الحقل accruedInterest في الحساب) ويتم ترحيله دورياً إلى GL، أو يُرحل مباشرةً يومياً إلى GL. أفضل الممارسات هي ترحيل استحقاقات الفوائد إلى الحسابات وحسابات GL الخاصة باستحقاقات الفوائد على الأقل شهرياً [3]. تقوم العديد من البنوك بالاحتساب يومياً في النظام الأساسي ولكنها تقوم بتحديث رصيد العميل شهرياً فقط. ومع ذلك، فإن وجود احتساب محدث داخلياً (وفي GL) أمر بالغ الأهمية لبيانات مالية دقيقة في أي وقت. من المرجح أن يُرحل نظامنا قيود الاستحقاق في نهاية كل يوم (EOD): على سبيل المثال، بالنسبة لحساب التوفير، يتم يومياً قيد مدين مصروف الفوائد (P&L) ودائن فائدة مستحقة الدفع (حساب التزام في GL أو يُقيد مباشرةً في حساب الإيداع إذا اخترنا تراكمها في الرصيد) بمقدار الفائدة المستحقة لذلك اليوم. وبالمثل بالنسبة للقروض، يُقيد مدين فائدة مستحقة القبض (أصل للفوائد المستحقة) ودائن إيراد الفوائد. يمكن دمج هذه القيود يومياً أو حسب الحساب حسب الحاجة. نضمن أن يتم عكس هذه القيود أو تعديلها عند حدوث المدفوعات الفعلية (مثل: عند دفع الفائدة، يتم تصفية الفائدة المستحقة/المعاد احتسابها).

يترتب على استخدام المحاسبة على أساس الاستحقاق آثار: يجب أن نتعامل مع التغييرات المؤرخة بأثر رجعي بعناية (موضحة في القسم التالي) – إذا تم إدخال معاملة بتاريخ سابق يؤثر على الفائدة، يجب أن يعيد النظام احتساب الفائدة المستحقة للفترة المتأثرة أو إنشاء قيد تسوية. هذا معقد ولكنه جانب مهم في دفتر الأستاذ المصرفي.

الاحتساب المستمر (Continuous Accruals): تشير عبارة “الاحتساب المستمر” إلى ترحيل استحقاقات الفوائد بشكل مستمر (يومي أو حتى أثناء اليوم) بدلاً من الانتظار حتى نهاية الفترة. يعتمد محركنا أسلوب الاحتساب المستمر. هذا يوفر اعترافاً أكثر سلاسة بالدخل ويزيل القفزات الكبيرة في نهاية الفترة. كما يتماشى مع ممارسات المحاسبة المستمرة (continuous accounting) حيث يتم تحديث الدفاتر يومياً، مما يسهل إغلاق الشهر بسرعة أكبر. على سبيل المثال، بدلاً من الانتظار حتى نهاية الشهر للاعتراف بجميع فوائد القروض، سيقوم النظام باحتساب 1/30 من الفائدة الشهرية كل يوم، بحيث تعكس قائمة الدخل والميزانية العمومية الواقع حتى يوم أمس [3]. وهذا مهم بشكل خاص للأدوات طويلة الأجل مثل القروض – فهو يمنع القفزات المفاجئة في الاعتراف بالإيرادات.

الفائدة المركبة (Compounding): تعني الفائدة المركبة أن الفائدة تُضاف إلى الأصل، ثم يتم حساب الفائدة في الفترات اللاحقة على الأصل المتزايد. سيدعم محركنا قواعد التركيب المحددة على مستوى المنتج. بالنسبة للودائع، يقوم العديد من حسابات التوفير بالتركيب شهرياً (تُضاف الفائدة المكتسبة كل شهر إلى الرصيد وتصبح هي نفسها خاضعة للفائدة بعد ذلك). قد تُركب الودائع لأجل فقط عند الاستحقاق (أو لا تُركب إطلاقاً إذا كانت الفائدة تُدفع). بالنسبة للقروض، لا يُطبق التركيب عادةً على القروض الجارية (عادةً تستخدم الفائدة البسيطة بين فترات الدفع)، ولكن إذا فاتت دفعة، فقد يتم رسملة (تركيب) الفائدة إذا سمح العقد. أيضاً، بعض المنتجات مثل رسملة الفوائد خلال فترة السماح (مثل: خلال فترة سماح، تتراكم الفوائد وتُضاف إلى الأصل). سنسمح بعلم في تعريف المنتج لـ “تكرار التركيب” – على سبيل المثال، إذا تم ضبطه على شهري لحسابات التوفير، سيقوم المحرك في نهاية كل شهر بأخذ الفائدة المستحقة وقيدها في رصيد الحساب (مما يزيد الأصل للفترة التالية). سيتم ذلك من خلال قيد: مدين مصروف الفوائد، دائن حساب الوديعة (وبنفس الوقت تقليل التزام الفوائد المستحقة إذا كنا نحتسبها كالتزام). بالنسبة للقروض، يمكن أن يتم تفعيل الرسملة عبر أحداث (مثل نهاية فترة السماح أو عند إعادة الهيكلة).

الإطفاء (Amortization): في سياق القروض، يشير الإطفاء عادةً إلى توزيع المدفوعات بمرور الوقت (والذي نتعامل معه عبر الجداول). ولكن أيضاً، إطفاء الرسوم (fee amortization) أمر حاسم بموجب طريقة معدل الفائدة الفعلي (EIR). يتطلب IFRS 9 (وقبله IAS 39) أن يتم إطفاء بعض الرسوم (مثل رسوم الإنشاء أو التكاليف المباشرة) على مدى عمر القرض كتعديل على إيراد الفوائد، باستخدام معدل الفائدة الفعلي (EIR). معدل الفائدة الفعلي هو معدل العائد الداخلي الذي يخصم تماماً التدفقات النقدية المتوقعة للقرض إلى قيمته الدفترية الأولية [10]. في الممارسة العملية، إذا كان للقرض رسوم إنشاء، لا يمكن للبنك الاعتراف بهذه الرسوم فوراً كإيراد؛ يجب توزيعها على مدى مدة القرض كجزء من عائد الفائدة. وبالتالي، سيأخذ محركنا أي رسوم مقدمة تُعتبر جزءاً من حساب EIR ويشملها في جدول الإطفاء. على سبيل المثال، إذا كان قرض بقيمة $10,000 بمعدل 5% وفُرضت رسوم $100، قد يكون EIR أعلى قليلاً من 5%. يجب الاعتراف بإيراد الفائدة للقرض في كل فترة عند EIR على القيمة الدفترية [9]. يمكن للمحرك حساب EIR للقروض (ليس بالأمر البسيط ولكنه ممكن باستخدام التكرار أو صيغة إذا كانت الدفعات منتظمة). بالنسبة لـ MVP، قد نبسط عبر إطفاء الرسوم خطياً على مدى المدة (وهو تقريب). ومع ذلك، استهدافاً للامتثال، نلاحظ أن “إيراد الفائدة يُحسب بتطبيق معدل الفائدة الفعلي على التكلفة المطفأة (القيمة الدفترية الإجمالية مطروحاً منها أي مخصص خسائر)”[9]. يقوم نظامنا بتخزين التكلفة المطفأة (amortized cost) للقروض (وهي الأصل بالإضافة إلى العناصر المرسملة مطروحاً منها السداد والمخصصات) ويمكنه احتساب الفائدة على هذا الأساس.

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

مثال على (Effective Interest Rate - EIR) والإطفاء: لنفترض قرض لمدة 3 سنوات بقيمة 100,000$ بنسبة فائدة سنوية 5% مع رسم إصدار 2,000$ مدفوع من قبل العميل. فعلياً يستلم العميل 98,000$ لكنه مدين بـ 100,000$ بالإضافة إلى الفائدة. قد تكون (EIR) حوالي 5.7%. في النظام الأساسي عند الصرف سيتم قيد أصل القرض 100,000$ دائن، نقدية 98,000$ مدين، وقيد دخل غير مكتسب (رسوم) 2,000$ دائن. على مدار فترة القرض، يتم تحويل هذا المبلغ 2,000$ تدريجياً إلى دخل فوائد. المحرك يمكنه إما (a) حساب (EIR) داخلياً وبنائه في جدول الفوائد (مفضل)، أو (b) إطفاء مبلغ 2,000$ بطريقة خطية (أبسط). هدفنا هو (a) في التصميم، لكن (b) قد يكون نهج (MVP) إذا كان هناك قيود زمنية. في جميع الأحوال، عند استحقاق القرض سيكون مبلغ 2,000$ قد تم الاعتراف به بالكامل كدخل فوائد على دفعات. نموذج البيانات يصنف الرسم كتأجيل في البداية.

ترحيل الفائدة والإقفال: حسابات الفائدة والرسوم غالباً يجب أن تراعي أوقات الإقفال وقواعد نهاية الفترة. بالنسبة للاحتساب اليومي، نأخذ في الاعتبار رصيد الإقفال اليومي لكل يوم لحساب الفائدة. إذا دخلت معاملة بعد وقت الإقفال (مثل بعد عملية نهاية اليوم)، قد تُعتبر معاملة لليوم التالي لأغراض الفائدة. يجب أن يسمح المحرك بإعداد طريقة حساب الفائدة: على سبيل المثال، بعض البنوك تستخدم (Day-Based Accrual) (تراكم الفائدة على أرصدة نهاية اليوم)، بينما قد يستخدم آخرون التتبع المستمر للأرصدة. سنعتمد غالباً على نهاية اليوم للبساطة. في نهاية الشهر أو الربع، يقوم النظام "بإقفال" الفوائد لذلك الفترة – مثل ترحيل أي تراكم متبقٍ ثم إعادة تعيين العدادات. هذا غالباً داخلي لأن التراكم المستمر يعني أننا لا نرى فرقاً كبيراً في نهاية الفترة. لكن من ناحية كشوف العملاء، قد تظهر الفوائد أو تُقيد في فترات محددة، وهو ما ينظمه المحرك.

محرك الرسوم بالمثل يمكنه تراكم الرسوم إذا لزم الأمر (مع أن معظم الرسوم لمرة واحدة). إحدى الحالات قد تكون رسم سنوي يُقسَّط شهرياً 1/12 – لكن عادة البنوك تخصمه دفعة واحدة. للاستكمال، إذا كان الرسم يحتاج تراكم (إيراد مؤجل)، يمكن التعامل معه بآليات مشابهة (التزام مؤجل واعتراف دوري). لكن من المرجح أنه غير مطلوب في (MVP).

باختصار، يضمن محرك الفوائد والرسوم ما يلي:

يتم حساب تراكم الفوائد يومياً لكل حساب حامل للفوائد (ودائع وقروض) بناءً على القواعد الدقيقة (عدد الأيام الفعلي، طريقة العد مثل 30/360 أو actual/365 إذا تم تحديدها، إلخ).
يتم إنشاء قيود التراكم بحيث تعكس الحسابات المالية الفوائد المكتسبة/المتحملة حتى تاريخه.
في الفترات المحددة، يتم رسملة الفوائد أو دفعها أو تحصيلها حسب شروط المنتج (مثل فائدة التوفير تقيد شهرياً في الحساب، وفائدة القرض تُحصّل شهرياً من العميل).
يتم تحصيل الرسوم عند نقاط التحفيز الصحيحة وتسجيلها بشكل مناسب.
جميع الحسابات متوافقة مع المعايير المحاسبية ((EIR) للقروض) والتوقعات التنظيمية (عدم احتساب فوائد على القروض غير العاملة، إلخ).
يجب على المحرك أيضاً التعامل مع حالة عدم التراكم: إذا كان القرض في المرحلة 3 (متأثر ائتمانياً)، يجب أن يتوقف النظام عن تراكم الفوائد كدخل (أو نقل الفوائد إلى حساب معلق). العديد من الأنظمة الأساسية تصنف هذه الحسابات كغير تراكمية وأي فوائد محسوبة تكون فقط كبيان. سنقوم بدمج هذه القاعدة: عندما loanAccount.stage = Stage3، قد يستمر حساب الفائدة (لمعرفة مقدار الفائدة المستحقة تقنياً من المقترض) لكن القيد المحاسبي سيكون مدين بفوائد معلقة مستحقة ودائن بدخل فوائد فقط إذا لزم الأمر؛ غالباً البنوك لا تعترف بها إطلاقاً حتى يتم تحصيلها (وهو ما يعادل أساس النقد لهذا القرض). يمكننا تنفيذ خيار عند مستوى المنتج أو الحساب لتعطيل "الاعتراف بالفوائد" عند عدم التراكم. وهذا يرتبط بالتحوط والمحاسبة (أدناه).

الدقة والاختبار: لأن حسابات الفوائد حساسة وتخضع لتدقيق كبير (العملاء سيشتكون إذا كانت فوائد مدخراتهم غير دقيقة حتى قليلاً)، سنستخدم حساب عشري عالي الدقة ونختبر بأمثلة معروفة. يجب أن يكون النظام قابلاً للإعداد لمختلف طرق عد الأيام (Actual/365, Actual/360, إلخ) اعتماداً على العرف المحلي أو العملة (بعض العملات تستخدم سنة 360 يوماً للفوائد). تعريف المنتج يمكن أن يحمل هذه المعلومة، وسيطبقها المحرك وفقاً لذلك.

اعتبارات محاسبية خاصة (Accrual Continuity, Back-dated Entries, Cut-off, Suspense, Multi-Currency, Hedge Accounting)

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

التراكم المستمر وإقفال الفترات: كما ذُكر، يقوم النظام بتراكم الفوائد والرسوم يومياً. عند نهاية الفترة (شهرية أو سنوية)، يتم فرض إقفال لتصفية الحسابات للتقارير. جميع المعاملات حتى وقت الإقفال تخص تلك الفترة؛ أي معاملات بعدها تخص الفترة التالية. ستتضمن عملية نهاية اليوم في نظامنا حد فاصل واضح: بمجرد أن "تُغلق" دفاتر اليوم (أو الشهر)، تُعتبر المعاملات التالية بتاريخ الفترة التالية. إذا لزم تسجيل معاملة بتاريخ قيمة أقدم (مدخلة بأثر رجعي)، قد يسمح النظام بذلك لكن مع ضوابط (تُناقش أدناه). الإقفال يؤثر أيضاً على الفوائد: الفوائد المتراكمة حتى نهاية الشهر يجب أن تظهر في قائمة الأرباح والخسائر لذلك الشهر. وبما أننا نراكم يومياً، فهذا يتم تلقائياً – في اليوم الأخير من الشهر، يضمن قيد التراكم اليومي تسجيل الفوائد حتى ذلك اليوم. لا حاجة لقيد "تراكم" كبير منفصل في نهاية الشهر، باستثناء التأكد من أن حسابات التراكم (فوائد مستحقة الدفع/القبض) تعكس الإجمالي بشكل صحيح. يجب أن ينتج النظام قيود تراكم إذا كانت هناك عناصر غير متراكمة يومياً (مثل الفوائد على القروض غير العاملة التي لم تُقيد). لكن بشكل عام، يضمن نهج التراكم المستمر مع الإقفال المناسب أن تكون البيانات المالية محدثة.

التعديلات بأثر رجعي (Back-Dated Adjustments): في الممارسة العملية، أحياناً تُدخل المعاملات متأخرة – مثلاً، إيداع شيك من الأسبوع الماضي يتم تسجيله اليوم فقط، لكن بتاريخ القيمة ليوم الإيداع الفعلي. يمكن أن تؤدي القيود بأثر رجعي إلى إفساد التراكمات والأرصدة للفترات السابقة. نظامنا سيسمح بالتأريخ الرجعي فقط ضمن معايير مضبوطة (ربما فقط ضمن نفس الفترة المحاسبية ومع موافقة). إرشادات بنك بنغلادش تنص صراحة على “يتطلب (dual control - maker/checker) لأي قيد بقيمة سابقة (back-dated)”[3]. سنقوم بفرض ذلك: أي معاملة بتاريخ قيمة أسبق من اليوم (خصوصاً إذا كانت في فترة مغلقة) ستتطلب موافقة المشرف. كما سيقوم النظام تلقائياً بتعديل الفوائد للقيود بأثر رجعي. على سبيل المثال، إذا تم إيداع قبل 5 أيام وتم تسجيله متأخراً، يجب أن يكون حساب التوفير قد كسب فائدة لتلك الأيام الخمسة – يمكن للنظام حساب الفائدة المفقودة وإضافتها كقيد تعديل. أحد الأساليب هو إعادة حساب الرصيد اليومي بأثر رجعي وحساب الفرق في الفائدة مقابل ما تم تراكمه سابقاً. يمكن ترحيل الفرق كقيد تعديل في يوم التسجيل الحالي (مع وسمه كتعديل فائدة بأثر رجعي). وبالمثل بالنسبة للقروض، فإن دفعة تم تسجيلها بأثر رجعي من الأسبوع الماضي تعني أن القرض كان برصيد أقل خلال تلك الأيام مما سُجل مبدئياً، وبالتالي تراكمت فوائد زائدة – يجب على النظام عكس الفائدة الزائدة. تنفيذ ذلك بدقة قد يكون معقداً، لذا قد يُبسط في (MVP): مثلاً منع التأريخ الرجعي خارج حدود مسموحة، أو ترحيل جميع تأثيرات المعاملات المؤرخة بأثر رجعي في يوم التسجيل فقط (أي دون تعديل التراكمات السابقة، فقط يؤثر على المستقبل). ومع ذلك، من أجل الدقة، من المثالي التعامل معه. سنسجل ذلك كمنطقة تتطلب تصميم دقيق: المعاملة المؤرخة بأثر رجعي تؤدي إلى إعادة حساب الفائدة من تاريخ القيمة حتى اليوم الحالي وترحيل قيد تصحيحي. دفتر الأستاذ سيحافظ دائماً على القيود الأصلية (لن نعيد فتح الأيام المغلقة)، لكن قيداً جديداً (بتاريخ اليوم) يمكن أن يعدل تأثير المعاملة المؤرخة. هذا يحافظ على وضوح مسار التدقيق ويتجنب العبث بالبيانات المغلقة (يظهر التعديل في دخل الفترة الحالية).

حسابات المعلق والتسوية (Suspense and Clearing Accounts): حسابات المعلق (Suspense accounts) هي حسابات مؤقتة للاحتفاظ بالمعاملات التي لا يمكن تصنيفها أو مطابقتها فوراً[11]. في البنوك، هذه شائعة في أنظمة الدفع والمطابقة. على سبيل المثال، قد يُقيد تحويل وارد في حساب معلق إذا لم يُحدد الحساب الوجهة فوراً؛ وبمجرد تحديده، يُنقل خارج الحساب المعلق. سيكون لدى نظامنا حسابات معلقة محددة مسبقاً (أكواد (GL)) لمختلف الوحدات (معلق المدفوعات، معلق الصراف الآلي، إلخ). يجب أن يضمن تكامل دفتر الأستاذ العام أن تتم تسوية أي من هذه القيود – أي أن حساب المعلق يجب أن يصل إلى الصفر بعد تسوية البند. سنستخدم أيضاً حسابات التسوية (clearing accounts) في مسارات مثل تسويات ما بين البنوك: مثلاً، عند إصدار شيك مصرفي، يتم خصم العميل وقيد حساب تسوية الشيكات المصدرة؛ عند صرف الشيك، يتم خصم ذلك الحساب وقيد النقدية – إذا سارت الأمور بشكل صحيح، تكون التسوية صفراً. يجب أن يدعم النظام وسم المعاملات كـ "مسوية" وترحيل الطرف المقابل تلقائياً. تُستخدم حسابات المعلق أيضاً لحالات عدم التوازن أو الأخطاء، لكننا نسعى لتقليلها عبر التحقق المسبق. ومع ذلك، وجود حساب معلق يضمن أن ميزان المراجعة يمكن أن يُقفل حتى لو كان هناك مشكلة مؤقتة، دون إخفاء الحقيقة – لأن حسابات المعلق ستتم مراقبتها والإبلاغ عنها.

على سبيل المثال، إذا لم يتمكن النظام خلال اليوم من تطبيق المدفوعات الواردة من شبكة البطاقات على الحسابات فوراً (ربما لم تتطابق أرقام الحسابات)، قد تبقى في "مدفوعات غير مطبقة" كمعلق. يقوم فريق العمليات لدينا بالتحقق ثم تمرير قيود تعديل لنقل هذه المبالغ إلى الحسابات الصحيحة أو إرجاعها، إلخ. سيوفر النظام القدرة على نقل القيود من المعلق إلى الحسابات النهائية بمجرد تحديدها (مع سجل تدقيق واضح بمن قام بالحل). وفقاً للتعريفات المحاسبية، “حساب المعلق هو حساب مؤقت يستخدم لتسجيل القيود الغامضة… قبل أن تُسند إلى الحسابات الصحيحة.”[12] – تصميمنا يتبنى هذا المبدأ مع أكواد (GL) مخصصة للمعلقات.

التسوية المستمرة لحسابات المعلق: نخطط لتضمين تقارير تُظهر جميع البنود المفتوحة في حسابات المعلق/التسوية، وتصنفها حسب العمر، وتضمن أنه يتم التحقيق فيها لتجنب تراكم أرصدة غير معروفة. يجب أن يقوم نظام مصرفي أساسي بأتمتة جزء كبير من عملية المطابقة (مثل المطابقة التلقائية لملفات الخصم المباشر الواردة مع الذمم المدينة المتوقعة)، لكن التدخل اليدوي مطلوب دائماً لبعض البنود. يمكن أن تدعم سير عمل (ClefinCode Chat) – التي سنناقشها لاحقاً – إشعار الموظفين المسؤولين عندما يُرحل بند إلى حساب معلق، كتنبيه لاتخاذ إجراء.

إعادة تقييم العملات المتعددة (Multi-Currency Revaluation): إذا كان البنك يتعامل بعملات متعددة، فإن بعض الحسابات (دفتر الأستاذ العام وحسابات العملاء) ستكون مقومة بعملة أجنبية. تتطلب المعايير المحاسبية إعادة التقييم لأرصدة العملات الأجنبية لتقديمها بقيمة معادلة بعملة التقرير (الوظيفية) عند كل تاريخ تقرير. سيدعم نظامنا المحاسبة متعددة العملات: كل حساب له عملته الخاصة، وهناك عملة أساسية لدفتر الأستاذ العام (مثل USD). بالنسبة لأي حسابات (GL) بعملة أجنبية (مثل حسابات نوسترو، قروض بالعملات الأجنبية، إلخ)، في نهاية الفترة سيقوم المحرك بإعادة تقييمها باستخدام أحدث أسعار الصرف. العملية: “إعادة تقييم حسابات الميزانية العمومية المقومة بعملات أجنبية لتعكس تغيرات أسعار الصرف… في نهاية كل فترة محاسبية، يتم حساب المكاسب أو الخسائر، وإنشاء قيد لتعديل الأرصدة مقابل حساب مكاسب/خسائر غير محققة، ثم عكس هذا القيد في بداية الفترة التالية”[13][13]. سنطبق ذلك بالضبط. على سبيل المثال، إذا كان البنك يحتفظ بـ €10,000 في حساب نوسترو باليورو، وكان سعر الصرف الشهر الماضي €1 = $1.1، والآن €1 = $1.05، فإن القيمة بالدولار انخفضت من $11,000 إلى $10,500. سيقوم النظام بإنشاء قيد خسارة غير محققة في سعر الصرف: مدين مصروف خسارة عملات $500، دائن حساب “مكاسب/خسائر غير محققة – نوسترو EUR” بمبلغ $500، لتتماشى دفاتر الدولار مع الواقع. يتم عكس هذا القيد في اليوم الأول من الفترة التالية (لأن الفترة الجديدة ستعيد التقييم من جديد). إذا تحركت العملة إيجابياً، سيكون هناك مكسب (قيد دائن في الدخل، مدين في حساب الخسائر غير المحققة). المفتاح هو وجود حساب (GL) مخصص لمكاسب/خسائر غير محققة (لكل عملة) لحفظ هذه التعديلات[13]. بالنسبة للبنود خارج الميزانية أو بعض المراكز، قد نقوم أيضاً بإعادة التقييم لكن مباشرة إلى قائمة الدخل إذا لزم الأمر. حسابات العملاء بالعملة الأجنبية عادة لا تُعاد تقييمها في الدفاتر لأن التزام العميل بهذه العملة (دفتر الأستاذ في هذه العملة منفصل). لكن في التقارير المجمعة، قد يُعبر عنها بعملة الأساس – وهذا يتم عادة في التقارير، لا بتغيير الأرصدة الفعلية. سنركز أساساً على حسابات (GL). مثلاً، قرض باليورو في الدفاتر، يتم تحويل الرصيد القائم إلى الدولار في القوائم المالية باستخدام سعر نهاية الفترة – مع ترحيل مكسب/خسارة غير محققة على قيمة القرض. يمكن لنظامنا التعامل مع القرض كبند ميزانية يحتاج إعادة تقييم (وهذا صحيح، لأن قيمة أصل البنك بالدولار تتغير). نعم، سنعيد تقييم القروض والودائع بالعملات الأجنبية بنفس الطريقة عبر (GL). يبقى دفتر الأستاذ الفرعي بالعملة الأصلية لكن دفتر الأستاذ العام يُترجم. يجب أن نخزن أسعار الصرف ونوفر أداة لتشغيل إعادة التقييم في نهاية الشهر. هذا يضمن الامتثال للمعايير المحاسبية (ASC 830 / IAS 21).

المحاسبة التحوطية (Hedge Accounting): بعض البنوك تستخدم المشتقات أو أدوات التحوط الأخرى لإدارة المخاطر (مثل مقايضات أسعار الفائدة لتحوط القروض ذات السعر الثابت، أو العقود الآجلة للعملات لتحوط القروض أو الودائع بالعملات الأجنبية، إلخ). إذا تم تطبيق المحاسبة التحوطية، فإن الهدف هو تقليل تقلبات قائمة الدخل عبر مواءمة المحاسبة لأداة التحوط مع البند المحوط. وفق (IFRS 9)، قد تكون المحاسبة التحوطية معقدة، لكن بشكل عام:

التحوط بالقيمة العادلة (Fair Value Hedges): مثل تحوط قرض بسعر فائدة ثابت عبر مقايضة سعر فائدة. تتغير القيمة العادلة للقرض مع أسعار الفائدة؛ وتتحرك المقايضة بالعكس. إذا تم اعتمادها كتحوط بالقيمة العادلة، سيقوم النظام بتقييم القرض بالقيمة السوقية عبر قائمة الدخل وكذلك المقايضة، بحيث تتعادل المكاسب/الخسائر[14]. سيحتاج نظامنا لتعديل القيمة الدفترية للقروض المحوطة لتغيرات القيمة العادلة المنسوبة للمخاطر المحوطة. هذا متقدم؛ قد لا ننفذ المحاسبة الكاملة للتحوط بالقيمة العادلة في (MVP)، لكن التصميم يترك مساحة (ربما تكامل مع نظام الخزينة). على الأقل، سنضع إشارة على القروض المحوطة ونتجنب تطبيق المعالجة العادية (التكلفة المطفأة) عليها؛ بدلاً من ذلك، التعامل معها حسب قواعد التحوط.
تحوط التدفقات النقدية (Cash Flow Hedges): مثل تحوط مدفوعات الفائدة المتغيرة لقرض أو هامش فائدة عبر أداة مشتقة. هنا، يتم تسجيل التغيرات في القيمة العادلة للأداة المشتقة في (OCI – الدخل الشامل الآخر) وتُرحل إلى قائمة الدخل عند حدوث التدفقات النقدية المحوطة[14][14]. سيحتاج دفتر الأستاذ لدينا إلى حسابات (OCI) (احتياطيات ضمن حقوق الملكية) وتتبع فعالية التحوط. هذا تقني للغاية وربما خارج نطاق (MVP)، لكن من الناحية المفاهيمية، نضمن أن هيكل (GL) يحتوي على حسابات (OCI) ويمكنه استيعاب قيود تعديلات التحوط عند الحاجة.

يتطلب تطبيق المحاسبة التحوطية تحديد العلاقة واختبار الفعالية (التأكد من أن التحوط فعال في تعويض المخاطر). يمكن للنظام المساعدة عبر السماح بربط أداة التحوط مع مجموعة قروض مثلاً، ومن ثم أتمتة القيود المحاسبية إذا توفرت التغيرات في القيمة العادلة. في الوقت الحالي، يمكننا القول إن قيود المحاسبة التحوطية ستُدار من خلال قيود يدوية أو وحدة منفصلة مرتبطة بـ (GL)، بدلاً من محرك المنتج الأساسي. لكن دفتر الأستاذ العام لدينا جاهز “لتوفير وسيلة لتقليل تقلبات القوائم المالية عند تحوط مخاطر محددة”، عبر وضع المكاسب/الخسائر في قائمة الدخل أو (OCI) بشكل مناسب[14].

على سبيل المثال، إذا كان لدينا محفظة من القروض ذات السعر الثابت محوطة بمقايضات أسعار الفائدة (تحوط بالقيمة العادلة)، فعندما تتغير الأسعار: تنخفض القيمة العادلة للقروض (والتي في المحاسبة على أساس التكلفة المطفأة لا نعترف بها، لكن في المحاسبة التحوطية نعترف بها)، فنقوم بقيد خسارة على القروض مدين، وقيد القيمة الدفترية للقرض دائن؛ أما المقايضة فترتفع قيمتها، فنقيد مكسباً دائن ونقيد أصل المشتقة مدين. الأثر الصافي في قائمة الدخل يكون صغيراً. بدون المحاسبة التحوطية، كان تقييم المشتقة بالقيمة السوقية سيؤثر على قائمة الدخل بينما يبقى القرض بالتكلفة، مما يسبب تقلباً[14]. وبالمثل في حالة تحوط عملة أجنبية لسند: عادة إعادة التقييم بالعملة الأجنبية تُسجل في قائمة الدخل، لكن إذا تم تعيينه كتحوط استثمار صافٍ مثلاً، يمكن وضعه في (OCI).

ملخص المحاسبة التحوطية في النظام: سنحدد إذا كانت هناك أصول أو التزامات معينة مُعينة في علاقات تحوط. يمكن للنظام الاحتفاظ بخريطة لعلاقات التحوط (غالباً خارج الدفاتر كتوثيق). يمكن تهيئة القواعد المحاسبية مسبقاً: مثلاً، في التحوط بالقيمة العادلة لمخاطر سعر الفائدة، يتم تعطيل المعالجة العادية بالتكلفة المطفأة للفائدة لذلك الصك وتسجيل تغيرات القيمة العادلة المقدمة من وحدة التقييم. وبما أن هذا متقدم، قد نخطط له في مرحلة لاحقة. لكن نضمن أن (GL) لديه المرونة (مثل الحقول لتحديد الصك كـ (FVTPL – Fair Value Through P&L) بدلاً من التكلفة المطفأة إذا كان محوطاً، إلخ). يسمح (IFRS 9) باستراتيجيات تحوط أكثر من (IAS 39) القديم، لذا في التصميم نبقي المجال مفتوحاً.

اعتبارات أخرى:

ضوابط الإقفال: في نهاية الشهر، بعد إعادة التقييم والتراكمات وإقفال الدفاتر، أي قيود بعد ذلك تذهب للفترة التالية. إذا كان لابد من تعديل فترة مغلقة، يتطلب ذلك إعادة فتحها وإعادة تشغيل العمليات مع وجود سجل تدقيق. سيحتوي النظام على وضعية للتعديلات (تأريخ رجعي مع إعادة فتح)، لكنها ستكون مقيدة بشكل كبير.
مراقبة حسابات المعلق/التسوية: كجزء من العمليات اليومية، أي حساب معلق غير صفري يجب أن يطلق تحقيقاً. يمكن لتصميمنا أن يندمج مع سير العمل أو على الأقل لوحات متابعة تبرز ذلك (لتقليل المخاطر التشغيلية).
المراكز متعددة العملات ورأس المال: سيتعامل النظام أيضاً مع إعادة تقييم حسابات رأس المال إذا لزم الأمر وميزان مراجعة متعدد العملات حسب القطاعات. قد يكون هذا خارج نطاق (MVP)، لكن نذكره من أجل الاستكمال.

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

ضوابط (Maker-Checker) وقوالب الترحيل

تُعتبر الضوابط الداخلية القوية أساسية في نظام مصرفي أساسي لمنع الأخطاء والمعاملات غير المصرح بها. ننفذ آلية (Maker-Checker - 4-Eyes) في جميع أنحاء النظام. هذا يعني أن المعاملات أو التغييرات الحرجة تتطلب على الأقل مستخدمين مختلفين: أحدهما للإدخال (Maker) والآخر للمراجعة/الموافقة (Checker). وفقاً لأفضل الممارسات (والإرشادات التنظيمية)، “يجب أن يدعم النظام وظيفة (maker-checker) في الوقت الفعلي للإدخال، التحقق، التعديل، الاعتماد، وما بعد الاعتماد من قِبل مستخدمين مختلفين بناءً على الحساب، المنتج، ونوع المعاملة.”[3]. في نظامنا:

أي دفعة عالية القيمة، أو قيد دفتر أستاذ عام، أو قيد مؤرخ رجعياً، أو فتح حساب جديد، أو تغيير في سعر الفائدة، أو أي عملية حساسة أخرى يمكن تهيئتها لتتطلب (maker-checker). على سبيل المثال، معاملة بالعملات الأجنبية فوق حد معين قد تتطلب موافقة المشرف. قيد مؤرخ رجعياً بالتأكيد سيتطلب ذلك[3]. سير العمل هو أن إدخال (maker) يُحفظ في حالة معلقة، ويجب على (checker) (بصلاحية مناسبة) مراجعة التفاصيل إما لاعتمادها أو رفضها. فقط عند الاعتماد يتم ترحيلها فعلياً إلى دفتر الأستاذ. هذا أمر بالغ الأهمية لاكتشاف الأخطاء (مثل قيام صراف بإدخال 1,000,000$ بدلاً من 100$) وردع الاحتيال الداخلي (لا يمكن لشخص واحد تحريك الأموال دون أن يراه آخر).
يقوم النظام بتسجيل كل من معرفات المستخدم (maker) و(checker) والطوابع الزمنية كجزء من سجل تدقيق المعاملة[3]. هذا يوفر المساءلة وإمكانية التتبع. إذا تم رفض إدخال من قبل (checker)، يقوم النظام أيضًا بتسجيل سبب الرفض.

سنجعل (maker-checker) قابلاً للتكوين حسب نوع المعاملة والمبلغ – على سبيل المثال، العمليات منخفضة المخاطر يمكن أن تُرحل تلقائياً، بينما الأخرى تحتاج إلى تحكم مزدوج. هذا يوازن بين الكفاءة والأمان. يحتوي (ERPNext) على محرك سير عمل يمكنه تسهيل مثل هذه الموافقات، والتي يمكننا الاستفادة منها في (doc types) المخصصة لدينا (مثل “GL Journal Entry” أو “Loan Approval” doc).

قوالب الترحيل: لضمان الاتساق وتقليل الأخطاء اليدوية في المحاسبة، نستخدم قوالب الترحيل للأنماط المتكررة من المعاملات. يقوم قالب الترحيل بتحديد القيود المحاسبية (debits/credits) التي يجب إنشاؤها لحدث أعمال معين مسبقًا. بهذه الطريقة، عند حدوث الحدث، يقوم النظام تلقائيًا بإنشاء جميع قيود GL اللازمة دون أن يضطر المحاسب لاختيار الحسابات كل مرة. على سبيل المثال:

عند صرف قرض: سيحدد القالب “مدين حساب قرض رئيسي GL، دائن حساب وديعة العميل (أو حساب المقاصة) GL” للمبلغ المصروف، وربما “مدين رسوم المعالجة المستحقة، دائن حساب دخل الرسوم GL” لأي رسوم مقدمة. نوع المنتج أو المعاملة هو الذي سيشغل هذا القالب.
عند استلام قسط قرض: يقول القالب “مدين نقدية/حساب عميل، دائن دخل الفوائد (لجزء الفائدة)، دائن أصل القرض (لجزء الأصل)، دائن دخل الغرامة (إذا كان أي جزء يذهب للغرامة)”. يمكن للمحرك تقسيم السداد إلى مكونات وتطبيق خطوط القالب وفقًا لذلك.
لسحب وديعة: القالب “مدين التزام وديعة العميل GL، دائن نقدية GL” (الحالة الأبسط).
احتساب الفوائد على الادخار: القالب “مدين مصروف الفوائد، دائن فوائد مستحقة الدفع (أو مباشرة دائن حساب الوديعة)” للاحتساب اليومي.
دفعة الفوائد الشهرية على قرض: القالب “مدين فوائد مستحقة القبض، دائن دخل الفوائد” (لعكس الاستحقاق إلى دخل محقق) و“مدين دفعة العميل، دائن فوائد مستحقة القبض” عند الدفع – أو إذا تم الدفع مباشرة دون استحقاق مسبق، “مدين دفعة العميل، دائن دخل الفوائد”.

من خلال تكوين هذه القوالب مرة واحدة، يضمن النظام أن المحاسبة لكل حدث تتم بشكل كامل وصحيح. هذا يقلل الاعتماد على معرفة المستخدم الفردي لأي حسابات GL يجب استخدامها. سيكون لدينا في التصميم ربط بين أنواع المعاملات وحسابات GL (يمكن أن يكون جزءًا من (ProductDefinition) أو تكوين منفصل). بمصطلحات (ERPNext)، يمكننا الاستفادة من إعدادات الحسابات الموجودة في (doctypes) (مثلما يسمح (ERPNext’s Sales Invoice) بربط العناصر بحسابات الدخل؛ بالمثل، نربط معاملات المنتج بحسابات GL). لمحرك خاص بالأنظمة المصرفية الأساسية، قد ننشئ جدولاً أو JSON في (ProductDefinition) مثل: "postingRules": [ { "event": "LoanDisbursement", "debit": "LoansReceivable", "credit": "CashAccount"} , ...]. يمكن أن يشير هذا إلى رموز الحسابات أو أنواعها، والتي يقوم النظام بترجمتها إلى أرقام GL الفعلية (ربما باستخدام فرع الحساب ديناميكياً).

كما يُلاحظ أن ميزة قوالب الترحيل موجودة أيضًا في حلول الصناعة: بناءً على القوالب والأحداث المحددة مسبقًا، يتم ترحيل قيود المدين والدائن بما في ذلك جميع التفاصيل تلقائيًا، مما يلغي الحاجة إلى قيود دفتر يومية يدوية للعمليات القياسية[15]. سيسمح نظامنا بالحفاظ على هذه القوالب بحيث إذا تغيرت السياسة المحاسبية (مثل حساب GL جديد لرسوم معينة)، يمكن للمسؤول تحديث القالب بدلاً من الكود.

مثال: اعتبر رسوم السحب على المكشوف عندما يصبح الحساب سالبًا. الحدث = “تحصيل رسوم السحب على المكشوف”. يمكن أن يكون القالب: مدين حساب العميل (مما يزيد رصيده على المكشوف)، دائن حساب “دخل الرسوم – سحب على المكشوف” GL لمقدار الرسوم X$. يكتشف النظام الحدث (انخفض رصيد الحساب إلى أقل من 0 لأكثر من Y يومًا مثلاً)، وينشئ هذا القيد المحاسبي تلقائيًا وفقًا للقالب. بدون القالب، قد يضطر الموظف للقيام به يدويًا، مما يعرضه للأخطاء أو احتمال نسيانه.

(Maker-Checker) على قوالب الترحيل: حتى تكوين قوالب الترحيل يجب أن يكون تحت تحكم (maker-checker) – التغييرات في حساب GL المستخدم لحدث ما هي تغييرات حساسة يجب أن يوافق عليها مدراء المالية. لذلك سيسجل نظامنا التغييرات وسيتطلب الموافقة اختياريًا على التغييرات في التكوين.

الترحيل الدفعي والتوازن الذاتي: عند قيام المستخدمين بإنشاء قيود يومية يدوية (مثل تسوية)، سيفرض النظام أن تكون الدفعة متوازنة قبل السماح بالإرسال[3][3]. أيضًا، إذا كان مسموحًا للمستخدم بإدخال قيد يومية (قد لا تكون بعض التسويات الداخلية معتمدة على قالب)، يتم تطبيق (maker-checker) ويقوم النظام بإجراء فحص التوازن الذاتي للتأكد من أن المدين = الدائن[3]. لا يسمح (ERPNext) بالفعل بقيود يومية غير متوازنة، لذا نستفيد من ذلك.

مستويات التفويض: إلى جانب وجود (checker) واحد فقط، يمكن للنظام دعم مستويات موافقة متعددة للمعاملات الكبيرة جدًا[3]. على سبيل المثال، قد تحتاج دفعة قدرها 1 مليون دولار إلى موافقتين (مدير ثم مدير أقدم). نقوم بتكوين مصفوفات (Delegation of Authority (DOA)) التي تحدد الحدود للمستخدمين. سيقرأ النظام تلك القواعد لتوجيه الموافقات وفقًا لذلك (يمكن لسير عمل (ERPNext) التعامل مع مستويات متعددة). نضمن أيضًا ألا يتمكن (maker) من الموافقة على معاملته الخاصة (فصل الواجبات).

جميع أحداث الترحيل، سواء كانت آلية عبر القوالب أو يدوية، سيتم تسجيلها في سجل تدقيق (audit log) مع معرفات المستخدمين (بما في ذلك (maker) و(checker) كحقول منفصلة)[3]. هذا أمر بالغ الأهمية أثناء عمليات التدقيق أو التحقيقات – حيث يمكن معرفة من قام بإنشاء القيد ومن قام بالموافقة عليه، مع الطوابع الزمنية.

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

تدفقات العمل والإشعارات المدفوعة بالأحداث (ClefinCode Chat Integration)

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

التقاط الأحداث: تشمل الأحداث الرئيسية في النظام مثل: فتح حساب جديد، إيداع، سحب كبير، الموافقة على قرض، صرف قرض، استحقاق أو تأخر دفعة قرض، إضافة فائدة، فرض رسوم، دخول الحساب في السحب على المكشوف، استحقاق وديعة لأجل، تجهيز كشوفات، إلخ. سيكون لدينا في هيكلنا ناشر أحداث (يمكن أن يكون بسيطًا مثل (hooks) في منطق (ERPNext doctype) أو (database triggers)، أو (message queue)) يرسل رسالة منظمة لهذه الأحداث. على سبيل المثال، عند إضافة الفائدة الشهرية إلى حساب توفير، يمكن نشر حدث “InterestCredited” مع تفاصيل الحساب والمبلغ.

مشغلات تدفق العمل: لدى (ClefinCode Chat) (الذي يمكن تصوره كخدمة دردشة آلية أو خدمة إشعارات) تدفقات عمل معدة للاستجابة لأحداث معينة. على سبيل المثال:

عند حدث فتح حساب، يتم إرسال رسالة ترحيب للعميل عبر قناته المفضلة (رسالة SMS، بريد إلكتروني، تطبيق دردشة) مع تفاصيل الحساب. وربما أيضًا يتم إخطار الموظفين الداخليين لمراجعة مستندات KYC إذا لزم الأمر (تدفق عمل داخلي).
عند أحداث المعاملات (مثل إيداع أو سحب يتجاوز حدًا معينًا)، يتم إرسال إشعار فوري للعميل: “لقد أودعت 5,000$، رصيدك الجديد هو X$.” يتوقع العديد من العملاء تنبيهات فورية للأمان والوعي.
عند صرف قرض، يتم إرسال إشعار: “تم صرف قرضك، جدول السداد مرفق.” وربما أيضًا إخطار موظف القرض داخليًا للمتابعة بشأن مستندات الضمان.
تذكيرات استحقاق الدفع: يمكن لتدفق العمل في المحادثة إنشاء تذكيرات قبل بضعة أيام من موعد استحقاق قسط قرض أو استحقاق وديعة لأجل: “عميلنا العزيز، دفعة قدرها Y$ مستحقة على قرضك في 15 أكتوبر. يرجى التأكد من وجود رصيد كافٍ.” أو “ستستحق وديعتك في 20 أكتوبر، يرجى زيارة فرعنا للتجديد أو السحب.”
تنبيه تخلف عن الدفع: إذا فات موعد الدفع، يتم تشغيل تنبيه: “دفعة قرضك المستحقة في X متأخرة الآن. يرجى الدفع لتجنب الغرامات.”
إشعار فرض رسوم: إذا تم فرض رسوم أو غرامة، يتم إشعار العميل: “تم فرض رسوم سحب على المكشوف قدرها 25$ على حسابك.”
تنبيهات انخفاض الرصيد أو العتبة: إذا انخفض رصيد الحساب عن حد محدد مسبقًا أو أصبح سالبًا، يتم إخطار العميل.
نشاط مشبوه أو معاملات كبيرة: إذا قام النظام الأساسي برفع علامة (ربما عبر التكامل مع قواعد الاحتيال)، يمكن للمحادثة التفاعل مع العميل (“هل حاولت إجراء تحويل عبر الإنترنت بمبلغ 5000$؟ أجب بنعم للتأكيد إذا كان ذلك أنت.”).

من المرجح أن يكون لدى (ClefinCode Chat) القدرة على إرسال الرسائل عبر قنوات متعددة (إشعارات تطبيق الهاتف، رسائل SMS، بريد إلكتروني، واتساب، إلخ). سنقوم بدمجه بحيث يستقبل بيانات الحدث ويشكل رسالة وفقًا لذلك. وربما يمكنه فعل المزيد: السماح للعميل بالرد أو طلب معلومات. على سبيل المثال، إذا أراد العميل معرفة رصيد حسابه، يمكنه أن يسأل روبوت المحادثة وسيقوم بالاستعلام من النظام الأساسي والرد.

نظرًا للطلب بالتحديد، نركز على الأحداث الخاصة بالمنتجات التي تولد إشعارات/كشوفات للعملاء. هذا يعني في الغالب إشعارات صادرة. سنضمن أن كل عملية توليد كشف حساب للعميل تؤدي إلى إرسال بريد إلكتروني آلي يحتوي على ملف (PDF) للكشف أو رسالة محادثة “كشفك الشهري جاهز، انقر هنا للتنزيل.” يمكن للنظام إعداد الكشوفات (وهو ما يمكن لـ(ERPNext) القيام به عبر توليد ملفات PDF للكشوف المالية لكل حساب) في نهاية الشهر ثم استدعاء خدمة المحادثة لتوزيعها. هذا يقلل من العمل اليدوي ويحسن تجربة العملاء.

تدفقات عمل (ClefinCode Chat) للعمليات الداخلية: إلى جانب ما يواجه العميل، يمكن لبعض الأحداث تشغيل تدفقات عمل داخلية. على سبيل المثال، يمكن تسهيل تدفقات الموافقة عبر المحادثة: قد يتلقى المدير رسالة “طلب القرض #123 بانتظار موافقتك. أجب APPROVE أو انقر على الرابط للمراجعة.” قد يرتبط هذا بذكاء اصطناعي أو على الأقل نظام تفاعلي. أو يمكن تسليم تقارير يومية للإدارة عبر المحادثة كل صباح (موقف الرصيد، إلخ). هذا امتداد لنهجنا المدفوع بالأحداث.

دور المحادثة وتكامل تدفق العمل هو توفير واجهة محادثة وطبقة تفاعل في الوقت الفعلي فوق النظام الأساسي. كما هو مذكور في اتجاهات الصناعة، المصرفية المحادثية تسمح بالإشعارات الاستباقية، والمعاملات الآلية، والتفاعل المخصص، كل ذلك عبر قناة واحدة مثل واتساب[16][16]. في الواقع، يعكس تصميمنا هذا: منصة موحدة حيث تؤدي الأحداث من النظام الأساسي (مثل حركة حساب غير اعتيادية) إلى تواصل فوري. على سبيل المثال، “يمكن للبنوك إرسال إشعارات استباقية كلما حددت حركات غير اعتيادية، ويمكن للعملاء اتخاذ إجراء (مثل حظر بطاقاتهم) عبر المحادثة”[16]. في حالتنا، إذا حدث تسجيل دخول أو معاملة مشبوهة، يمكن أن يؤدي حدث إلى مطالبة المحادثة العميل بالتأكيد أو تزويده بالخطوات التالية.

التكامل الفني: من المرجح أن ننفذ ذلك عبر نظام (messaging queue) أو (webhook). يمكن لـ(ERPNext) استدعاء (webhooks) عند أحداث المستندات، أو يمكننا استخدام أحداث إطار عمل (Frappe). لضمان الموثوقية، يمكن أن يقوم وسيط رسائل صغير (مثل Redis أو RabbitMQ) بصف الأحداث لضمان عدم فقدانها وتنظيم التدفق إذا لزم الأمر. تشترك خدمة (ClefinCode Chat) في أنواع الأحداث ذات الصلة. ونظرًا لأن بعض الإشعارات حرجة (مثل كشوفات تنظيمية)، سنبني أيضًا منطق إعادة المحاولة أو التتبع لضمان التسليم (ربما باستخدام AWS SNS/SQS إذا كنا على AWS، أو Twilio للرسائل القصيرة، إلخ، اعتمادًا على القناة).

التخصيص وخصوصية البيانات: يمكن تخصيص محتوى الإشعارات (باستخدام اسم العميل، اسم مستعار للحساب، إلخ) لتعزيز تجربة المستخدم. يتم أخذ الخصوصية بعين الاعتبار – لن نرسل أرقام الحسابات الكاملة أو المعلومات الحساسة في قنوات النصوص العادية. ربما نستخدم الإخفاء الجزئي (“الحساب المنتهي بـ 4567”). من المرجح أن يختار العملاء القنوات التي يرغبون بتلقي الإشعارات عبرها.

مثال على الاستخدام: يمكن أن يتيح جانب (conversational AI) للعميل الاستعلام عبر المحادثة مثل “ما هو رصيدي؟”. سيقوم روبوت المحادثة بالتحقق من هوية المستخدم (ربما عبر كلمة مرور أو رمز (OTP)) ثم يستعلم من واجهة برمجة التطبيقات (API) للنظام الأساسي للحصول على رصيد الحساب ويرد به. بالمثل، “أرسل لي آخر كشف حساب” – يمكنه جلب ملف PDF وتسليمه. مثال آخر: إذا استحقت وديعة لأجل، يمكن لروبوت المحادثة أن يسأل العميل “هل ترغب في تجديد وديعتك لفترة أخرى؟ أجب 1 بنعم، 2 للتحويل إلى التوفير.” وبناءً على الرد، يبدأ تدفق عمل في النظام الأساسي (مثل التجديد بالسعر الحالي أو إنشاء مهمة للموظفين). هذه احتمالات مستقبلية تظهر كيف يمكن لـ(ClefinCode Chat) تحسين التفاعلية.

بالنسبة إلى (MVP)، يجب تنفيذ التنبيهات الصادرة وتوزيع الكشوفات على الأقل. هذا بالفعل يعزز قيمة النظام بشكل كبير، حيث يحصل العملاء على معلومات في الوقت المناسب. لقد أظهرت أمثلة (WhatsApp banking) معدلات اعتماد عالية، حيث قامت بعض البنوك بأتمتة حوالي 98% من الاستفسارات عبر المحادثة وتقليل حجم المكالمات[16]. نهجنا يتماشى مع هذه الاتجاهات.

باختصار، لا يعمل النظام المصرفي الأساسي بمعزل – بل هو متصل بـطبقة اتصال فوري (ClefinCode Chat) تضمن إعلام العملاء والموظفين فورًا بالأحداث المهمة. هذا يؤدي إلى شفافية أعلى (حيث يعرف العملاء دائمًا ما يحدث في حساباتهم) وخدمة أفضل (يمكن معالجة المشكلات بشكل أسرع، وتكون المعلومات الروتينية متاحة بسهولة). كما أنه يقلل من عبء العمل على مراكز الاتصال والفروع للاستفسارات والإشعارات الأساسية. من خلال تصميم أحداث النظام وتدفقات المحادثة معًا، نضمن أنه لكل معاملة أو تغيير حالة مهم، هناك تواصل أو مطالبة بإجراء مناسب، مما يخلق تجربة مصرفية أكثر استجابة وحداثة[16].

خدمات (ClefinCode Cloud): القابلية للتوسع، النسخ، والمرونة (AWS/On-Premise)

سيتم بناء المنصة مع مراعاة القابلية للتوسع والمرونة، مع الاستفادة من خدمات (ClefinCode Cloud) التي يمكن نشرها على (AWS) أو في بيئة داخلية (On-Premise). نحن ندرك أن أحمال عمل المصرفية الأساسية تتطلب توافرًا عاليًا (حيث أن التوقف يمكن أن يكون مكلفًا ماليًا وسمعياً)، ومع نمو البنك، يجب أن يتعامل النظام مع أحجام متزايدة من المعاملات والبيانات. يتضمن تصميمنا استراتيجيات لتوسيع نموذج البيانات، ونسخ الدفتر المحاسبي، وضمان المرونة ضد الأعطال أو الكوارث.

نموذج بيانات وقاعدة بيانات قابلة للتوسع: يستخدم (ERPNext (Frappe)) قاعدة بيانات (MariaDB) كقاعدة بيانات أساسية (مع محرك (InnoDB) للمعاملات). توفر (MariaDB) التوافق الكامل مع (ACID) وهو أمر بالغ الأهمية للمصرفية. بالنسبة للتوسع، لدينا عدة خيارات[17]:

النسخ الرئيسي-التابع (Master-Replica Replication): يمكننا استخدام خادم (MariaDB) أساسي للكتابة وواحد أو أكثر من النسخ للمهام التي تعتمد بكثافة على القراءة (مثل التقارير، التحليلات)[17]. “النسخ يسمح بنسخ البيانات من خادم (MySQL/MariaDB) واحد إلى واحد أو أكثر من التوابع… يُستخدم لتوسيع عمليات القراءة، وتوفير التوافر العالي والتكرار الجغرافي.”[17]. في سياقنا، قد يكون لدينا نسخة واحدة متزامنة في الوقت الفعلي لمعالجة استعلامات التقارير أو لاستخدامها كحل بديل إذا فشل الخادم الرئيسي. هذا سهل الإعداد نسبيًا ومن المرجح أن يكون جزءًا من نشر (MVP): قاعدة (AWS RDS) لـ(MariaDB) أو (Aurora MySQL) كخادم رئيسي ونسخة قراءة في منطقة توافر أخرى.
التقسيم/التجزئة (Partitioning/Sharding): مع نمو البيانات (سنوات من المعاملات)، قد نفكر في تقسيم الجداول الكبيرة (مثل قيود دفتر المعاملات) حسب التاريخ أو حسب نطاق الحساب[17]. تدعم (MariaDB) تقسيم الجداول، مما يمكن أن يحسن أداء الاستعلامات على الجداول الضخمة عن طريق تقليم الأقسام. التجزئة الأفقية (التقسيم حسب شريحة العملاء) هي نهج آخر إذا لزم الأمر في المستقبل البعيد، ولكن ليس من المرجح في (MVP) ما لم يكن هناك توسع هائل. نصمم المخطط بحيث يكون تقسيمه حسب التاريخ (مثل كل سنة مالية) ممكنًا دون تغييرات برمجية – على سبيل المثال، عن طريق تضمين التاريخ في المفتاح الأساسي أو باستخدام مفاتيح ملائمة للتقسيم. تلاحظ ورقة توسيع (ERPNext) أن التقسيم يمكن أن يتم لبيانات المعاملات الكبيرة متعددة السنوات بناءً على السنة المالية[17]، ونتوقع استخدام هذا النهج بعد بضع سنوات من البيانات.
التوسع العمودي مقابل الأفقي: في البداية، سيتعامل التوسع العمودي (إعطاء قاعدة البيانات المزيد من المعالجات/الذاكرة) في السحابة مع النمو. لكننا نلتزم بخطة التوسع الأفقي: خوادم تطبيق متعددة، وربما نسخ قراءة، وفي النهاية تقسيم الخدمات إذا لزم الأمر. البنية صديقة للسحابة.

نسخ الدفتر والمرونة: يُعد الدفتر (GL وسجلات المعاملات) البيانات الأكثر أهمية. سنقوم بتنفيذ النسخ في الوقت الفعلي إلى نسخة احتياطية جاهزة للتشغيل لضمان التوافر العالي. على (AWS)، يوفر نشر (Multi-AZ RDS) نسخة احتياطية جاهزة ويتم التبديل إليها تلقائيًا إذا تعطلت النسخة الأساسية، مما يوفر المرونة. بالإضافة إلى ذلك، يمكن أن يكون لدينا نسخة احتياطية داخلية لأغراض النسخ الاحتياطي أو المتطلبات التنظيمية. بالنسبة للنشر الداخلي (On-Premise)، يمكننا استخدام (MariaDB Galera Cluster) للتكرار المتزامن متعدد الرؤوس[17]. “يُعتبر (Galera Cluster for MySQL) عنقودًا حقيقيًا متعدد الرؤوس قائمًا على التكرار المتزامن، مما يوفر وقت تشغيل عالٍ للنظام، وعدم فقدان البيانات، وقابلية للتوسع للنمو المستقبلي.”[17]. هذا يعني أن جميع العقد تحتوي على نفس البيانات في جميع الأوقات، وإذا فشلت عقدة واحدة، تستمر العقد الأخرى. قد نختار (Galera) في البيئات التي تتطلب وقت توقف صفري (حيث يمكنه حتى السماح بمواصلة العمليات على شبكة محلية إذا فقدت عقدة واحدة، ثم إعادة المزامنة عند استعادتها).

من المحتمل أن تشمل خدمات (ClefinCode Cloud) طبقة إدارة تنسق مثل هذه العناقيد، سواء باستخدام خدمات (AWS) المُدارة أو الإدارة الذاتية على (Kubernetes). نخطط لاستخدام الحاويات (يمكن تشغيل ERPNext في Docker) بحيث يصبح نشر الإعدادات متعددة العقد أسهل. الأجزاء عديمة الحالة (stateless) (خوادم الويب، العمال في الخلفية) يمكن توسيعها خلف موازن تحميل، بينما قاعدة البيانات (stateful) تستخدم النسخ/العناقيد.

تعدد المناطق والتعافي من الكوارث (DR): للبنوك العاملة في مناطق متعددة أو التي تتطلب (DR)، يمكننا نسخ قاعدة البيانات عبر المناطق (مع التكرار غير المتزامن لتجنب مشكلات الكمون). على سبيل المثال، نسخة قراءة أو حتى نسخة غير نشطة في مركز بيانات بعيد يمكن ترقيتها إذا تعطلت المنطقة الرئيسية. تقدم (AWS) نسخ قراءة عبر المناطق يمكننا استخدامها. سنقوم أيضًا بتنفيذ نسخ احتياطية منتظمة (لقطات يومية وأرشفة (binlog)) في حالة احتجنا إلى استعادة نقطة زمنية تتجاوز ما يغطيه التكرار (مثل الأخطاء المنطقية).

مرونة الخدمات: إلى جانب البيانات، تحتاج خدمات التطبيق (خادم API، مجدول المهام في الخلفية) إلى وقت تشغيل عالٍ. سنستضيف في إعداد احتياطي مزدوج: إذا كان على (AWS)، باستخدام مناطق توافر متعددة (AZs) للتبديل. على سبيل المثال، قاعدة البيانات الأساسية في منطقة، والنسخة الاحتياطية في أخرى؛ وخوادم التطبيقات، واحدة على الأقل في منطقتين خلف (Application Load Balancer - ALB). إذا تعطلت منطقة، يستمر النظام في الأخرى. سيستفيد نشرنا السحابي من التعافي التلقائي (auto-healing) (إذا فشلت حاوية أو جهاز افتراضي، يُعاد تشغيله تلقائيًا). إذا كان داخليًا (On-Premise)، سننشئ عنقودًا مشابهًا أو على الأقل خادم احتياطي جاهز للتشغيل.

(ClefinCode Cloud) (الخدمات المُدارة): إذا قدمت (ClefinCode) منصة سحابية، فمن المرجح أنها توفر بيئة (Kubernetes) مُدارة أو افتراضية لتشغيل حزمة المصرفية الأساسية مع المراقبة والتوسع. سنقوم بدمج ذلك، مما يعني أن المقاييس (CPU، الذاكرة، استعلامات قاعدة البيانات) تتم مراقبتها ويمكن أتمتة مشغلات التوسع (مثل تشغيل المزيد من العمال خلال ضغط نهاية الشهر). تم تصميم نموذج البيانات ليتوسع أفقيًا بحيث يمكنك تقسيم الحمل بين خدمات مختلفة إذا لزم الأمر: على سبيل المثال، تشغيل عملية منفصلة لحساب الاستحقاقات في الخلفية، أو خدمات قراءة منفصلة للتحليلات.

MariaDB لـ(ERPNext): نلاحظ بوضوح أننا نستخدم (MariaDB) (متوافقة مع MySQL) كقاعدة البيانات – حيث يستخدم (ERPNext) بشكل افتراضي (MariaDB) (حاليًا MariaDB 10.x). هذه القاعدة مثبتة في الأداء العالي للمعاملات المعقدة. نضمن استخدام الفهرسة المناسبة (على معرفات الحسابات، التواريخ، إلخ) لتحسين الأداء في الاستعلامات مثل استرجاع معاملات الحساب أو إعداد تقارير الدفتر. يمكن لـ(MariaDB) التعامل بشكل مريح مع آلاف المعاملات في الثانية على أجهزة جيدة، خاصة مع الضبط (مثل حجم (buffer pool) إلخ). إذا ظهرت الحاجة لتجاوز ما يمكن لمثيل واحد التعامل معه، نلجأ إلى التقنيات الأفقية المذكورة. ولكن بالنظر إلى أحجام المعاملات المصرفية الأساسية للعديد من البنوك الصغيرة، يمكن التعامل معها على خادم قوي واحد، مما يمنحنا مساحة كافية للنمو.

الخدمات عديمة الحالة وإمكانية الخدمات المصغرة: بينما نقوم في البداية بالتنفيذ ضمن وحدة (ERPNext) أحادية (monolith) (وهي في حد ذاتها أحادية معيارية)، نضع في الاعتبار مبادئ الخدمات المصغرة. نموذج البيانات شبه معياري (القروض، الودائع، GL يمكن أن تكون تطبيقات منفصلة مستقبلاً). إذا لزم الأمر، يمكن لـ(ClefinCode Cloud) فصل خدمة ترحيل GL كخدمة مستقلة تستدعيها وحدات أخرى (للتوسع الشديد أو لدمج أنظمة متعددة). يساعدنا نموذج البيانات المعياري المعتمد هنا: حتى إذا تم فصلها فعليًا، فإنها تشترك في نفس التصميم المنطقي للمخطط، مما يسهل التكامل.

اختبار التوسع: سنقوم بإجراء اختبارات حجم – على سبيل المثال، تشغيل معاملات سنة كاملة لـ 100 ألف حساب في بيئة اختبار – لمعرفة أداء الاستعلامات. سيحدد هذا ما إذا كنا بحاجة إلى تقسيم أو إضافة فهارس. يجب أن يحافظ النظام على استجابة أقل من ثانية للاستعلامات الشائعة (مثل الاستعلام عن الرصيد) وأن يكون قادرًا على ترحيل المعاملات في غضون بضعة ميلي ثانية إلى بضع مئات من الميلي ثانية لكل منها (اعتمادًا على إدخال/إخراج البيانات). يساعد استخدام قاعدة بيانات مُدارة سحابيًا حيث يمكننا توسيع (IOPS) والمعالج بسهولة عبر تغيير حجم المثيل.

إجراءات المرونة والتبديل: سنوثق ونؤتمت إجراءات التبديل. على سبيل المثال، إذا فشلت قاعدة البيانات الرئيسية، ستتحول (AWS) إلى النسخة الاحتياطية في حوالي أقل من دقيقة عادةً؛ يجب أن يعيد التطبيق الاتصال (يستخدم (ERPNext) مجموعة اتصالات، لذا يجب التأكد من أنه يمكنه إعادة المحاولة أو يتم إعلامه). إذا فشل خادم تطبيق، يتوقف موازن التحميل عن إرسال حركة المرور وتتحمل الخوادم الأخرى الحمل. نخطط أيضًا لـالتحديثات المتدرجة (rolling updates): باستخدام بيئة من 3 مراحل (Dev/Staging/Prod)، نختبر التغييرات في التطوير، ثم المرحلة التجريبية، ثم ننشر في الإنتاج مع أقل وقت توقف (ربما باستخدام (blue-green) أو (bench migrate) مع نافذة صيانة). يضمن هذا خط النشر المكون من 3 مراحل استقرار الإصدارات.

بالإضافة إلى ذلك، ولأجل المرونة، نأخذ في الاعتبار الشبكة والطاقة: سيتم التوصية بنشر داخلي (On-Premise) مع (UPS) وشبكة احتياطية. في السحابة، تتولى بنية (AWS) التحتية التعامل مع ذلك على مستوى منطقة التوافر.

سلامة الدفتر عند الأعطال: أحد أهم المخاوف هو تجنب المعاملات الجزئية إذا حدث تعطل أثناء الترحيل. من خلال الاعتماد على التزام المعاملات في قاعدة البيانات، إما أن يتم ترحيل المعاملة بالكامل أو لا يتم ترحيل أي جزء منها. ومع النسخ المتماثل، إما أن يتم نسخ الالتزام أو إذا تعطلت النسخة الأساسية قبل الالتزام فلن يكون هناك شيء لنسخه. يضمن عنقود (Galera) عدم فقدان البيانات من خلال الالتزام المتزامن لعقد متعددة[17]. عند استخدام النسخ غير المتزامن، هناك احتمال ضئيل أن تكون آخر معاملة لم تُنسخ عند التعطل – للتخفيف من ذلك، قد نستخدم النسخ شبه المتزامن (حيث ينتظر الخادم الأساسي تأكيد نسخة واحدة على الأقل). في جميع الحالات، يتم إعطاء الأولوية للاستدامة – نفضل تحمل تأخير بسيط إذا كان ذلك يضمن المتانة.

خدمات السحابة للمراقبة: من المرجح أن توفر (ClefinCode Cloud) لوحات مراقبة. سنقوم بدمج السجلات والقياسات: سجل الاستعلامات البطيئة لقاعدة البيانات، سجلات أخطاء التطبيق، إلخ. يمكن تعيين تنبيهات للظروف غير العادية (مثل تأخر النسخ، ارتفاع وحدة المعالجة المركزية، انخفاض القرص). تساعد هذه المراقبة الاستباقية على الحفاظ على وقت تشغيل عالٍ.

الخيار الداخلي (On-Premise): ليس كل البنوك ستلجأ إلى السحابة؛ بعض البيئات التنظيمية تتطلب تشغيلًا داخليًا. يمكن نشر تصميمنا داخليًا على مجموعة من الخوادم أو الأجهزة الافتراضية. بدلاً من (AWS RDS)، سنستخدم عنقود (MariaDB) مدار ذاتيًا (Galera أو رئيسي-تابع قياسي مع (Pacemaker) للتبديل). وبدلاً من موازن تحميل (AWS)، ربما (HAProxy). تظل البنية مشابهة. قد تقدم خدمات (ClefinCode) أيضًا جهازًا مخصصًا أو مرجعًا معماريًا للنشر الداخلي (مع احتمال وجود (OpenStack) أو (Kubernetes) لمحاكاة السحابة). سنضمن عدم وجود قفل خاص بالسحابة؛ على سبيل المثال، يمكن استخدام تخزين (S3) للوثائق في السحابة، لكن داخليًا قد نستخدم (NAS) محلي أو (MinIO). وبما أن التطبيق مكتوب في الغالب بلغة (Python)، فيمكن تشغيله في أي مكان.

وباختصار، توفر خدمات (ClefinCode Cloud) بنية تحتية قوية لحل المصرفية الأساسية مع:

قابلية عالية للتوسع: قادرة على إضافة خوادم (توسع أفقي) أو ترقية الخوادم (رأسي) بسلاسة للتعامل مع الحمل المتزايد[1]. مصممة للتوسع الأفقي قدر الإمكان (المكونات عديمة الحالة). استراتيجيات تقسيم البيانات حسب الحاجة.
توافر عالٍ: التكرار على جميع المستويات (نسخ قاعدة البيانات، عقد تطبيق متعددة، نشر متعدد المناطق AZ) لتجنب نقاط الفشل الأحادية.
مرونة البيانات: نسخ احتياطية قوية واستعادة، بدون اعتماد على تخزين واحد. إذا كان على (AWS)، نسخ متعددة المناطق ولقطات؛ إذا كان داخليًا، نسخ احتياطية ليلية وربما شريطية/خارج المنطقة لـ(DR). لا يتم فقد أي معاملة بفضل استراتيجيات النسخ والالتزام.
تحسين الأداء: باستخدام التخزين المؤقت في الذاكرة (يستخدم (ERPNext) (Redis) للتخزين المؤقت وكطابور – لدينا (Redis) في البنية لأشياء مثل طابور المهام وربما تخزين البيانات المقروءة بشكل متكرر)، واستخدام نسخ القراءة أو مستودع البيانات للتقارير الثقيلة بحيث يبقى النظام الأساسي سريعًا.
خط نشر مكون من 3 مراحل: نحتفظ بثلاث بيئات – التطوير (للبناء والاختبارات الفردية)، (UAT/Staging) للاختبار من قبل المستخدمين واختبارات الأداء (تشبه الإنتاج)، والإنتاج. هذا يسمح باختبار أي ميزة أو تكوين جديد في بيئة آمنة قبل تشغيله فعليًا، مما يمنع المشاكل الكارثية. يمكن إعداد (CI/CD) آلي للنشر في بيئة الاختبار، وتشغيل الاختبارات، ثم الترقية للإنتاج. يضمن هذا الخط تطور النظام الأساسي بطريقة مضبوطة، وهو أمر أساسي لنظام مصرفي حرج.

من خلال معالجة هذه الجوانب، نضمن أن النظام المصرفي الأساسي سيكون قابلًا للتوسع لأحجام مؤسسية، قويًا ضد الأعطال، وقادرًا على العمل على مدار الساعة طوال أيام الأسبوع. سواء اختار البنك العميل الاستضافة على السحابة (AWS) أو في مركز بياناته الخاص، تدعم البنية كلا الخيارين – مما يوفر مزايا السحابة مثل المرونة على (AWS)، أو التحكم الداخلي مع تركيز أكبر على إعدادات التوافر المحلي. قاعدة بيانات (MariaDB) كأساس للمعاملات لديها استراتيجيات مثبتة للتوسع والتوافر العالي التي نستفيد منها[17][17]. في الواقع، تقوم طبقة (ClefinCode Cloud) بتبسيط هذه التعقيدات وتقدم للبنك خدمة موثوقة: يمكن للمصرفيين الوثوق بأن الدفتر متسق ومتاح، والتركيز على الأعمال بدلاً من الحفاظ على تشغيل الخوادم.

نطاق (MVP) واعتبارات التنفيذ

في تصميم حل المصرفية الأساسية هذا، من المهم تحديد نطاق المنتج الأدنى القابل للتطبيق (MVP) بوضوح، نظرًا لاتساع الميزات التي تمت مناقشتها. الهدف من (MVP) هو تقديم نظام مصرفي أساسي وظيفي يدعم المنتجات الأساسية والامتثال، في إطار زمني معقول، بينما قد يتم تأجيل بعض الميزات المتقدمة إلى مراحل لاحقة. فيما يلي مخطط لما يتضمنه (MVP) وما قد يكون في مرحلة لاحقة، إلى جانب ملاحظات حول النشر المرحلي (خطة من ثلاث مراحل) وخيارات التكنولوجيا مثل (MariaDB) وتكامل (ERPNext):

المتضمن في (MVP):

نموذج البيانات الأساسي والكيانات الرئيسية: تم تنفيذ النموذج المرجعي للبيانات مع العملاء، الحسابات (إيداع & قرض)، المعاملات، تعريفات المنتجات، وقيود GL بشكل كامل في (MVP). هذا يضمن أن لدينا الأساس لدعم العمليات المصرفية. تم إعداد (ERD) أولي والجداول اللازمة في قاعدة البيانات (أو (doctypes) في (ERPNext)) التي تغطي هذه الكيانات.
وظائف حسابات الودائع (CASA): القدرة على فتح حسابات التوفير والحسابات الجارية، ترحيل الإيداعات والسحوبات، حساب الفوائد على حسابات التوفير، وفرض الرسوم الأساسية. يتم تضمين تحديثات الرصيد في الوقت الفعلي وترحيلات الدفتر لهذه المعاملات.
حسابات القروض (الإقراض الأساسي): دعم القروض الشخصية/قروض المؤسسات الصغيرة والمتوسطة وقروض السحب على المكشوف. يشمل ذلك إنشاء حساب قرض بجدول سداد، احتساب الفوائد يوميًا، السماح بالصرف والسداد، وتطبيق رسوم التأخير. يمكن للنظام التعامل على الأقل مع قرض مقسط قياسي وائتمان دوار (سحب على المكشوف) في (MVP).
محرك المحاسبة مزدوج القيد: محرك ترحيل GL موجود في (MVP). جميع المعاملات من الدفاتر الفرعية تولد قيود GL متوازنة مقابلة. تم إعداد دليل الحسابات (مع تقسيم الفروع)، ويمكن للنظام إنتاج ميزان مراجعة. تم تنفيذ عدم قابلية القيود للتغيير وآلية العكس.
المحاسبة متعددة الفروع: سيتضمن (MVP) قدرات متعددة الفروع بقدر أن كل معاملة تحمل رمز فرع ويمكننا إنتاج دفاتر خاصة بكل فرع. سيتم تنفيذ التسوية بين الفروع عبر حسابات (Due To/Due From) على الأقل في نموذج أساسي “عبر المكتب الرئيسي” (مركز المقاصة). هذا يعني إذا تعامل الفرع A مع الفرع B، سنستخدم حسابات المكتب الرئيسي كوسيط إذا لم يتم تكوين حسابات مباشرة، مما يضمن إمكانية ترحيل المعاملات. سنقوم بتضمين واجهة تكوين لحسابات بين الفروع.
احتساب الفوائد والرسوم (الميزات الأساسية): احتساب الفوائد اليومية للودائع والقروض ضمن النطاق. يتم تضمين ترحيل الفوائد المستحقة إلى حسابات GL المناسبة (استحقاقات دخل/مصروف الفوائد). يتم تضمين رسملة الفوائد الدورية للتوفير (شهريًا) واحتساب الفائدة على القروض (شهريًا). يتم تضمين فرض الرسوم الأساسية (مثل رسوم الحساب الشهرية، رسوم إنشاء القرض، رسوم التأخير الثابتة). يتم تضمين الفائدة المركبة شهريًا على التوفير.
تصنيف مراحل IFRS9 (جزئي): يدرك نموذج بيانات النظام مراحل IFRS9 ويمكنه تصنيف القروض إلى المرحلة 1،2،3 (عاملة، متعثرة جزئيًا، متعثرة كليًا). بالنسبة لـ(MVP)، قد لا ننفذ نماذج (ECL) المعقدة، لكن سنسمح بتحديد مرحلة القرض يدويًا أو عبر قواعد بسيطة (مثل: أيام متأخرة >30 ← مرحلة 2، >90 ← مرحلة 3). يمكن أن تكون المحاسبة للمخصصات في (MVP) مبسطة: على سبيل المثال، نحتفظ بحساب مخصص ونسمح للمستخدمين بإدخال نسب خسارة متوقعة، ثم يمكن للنظام حساب مبلغ المخصص وترحيل قيد. هذا يضمن الامتثال بوجود شيء للمخصصات، حتى لو كانت الحسابات أولية في البداية. سيتم تنفيذ طريقة سعر الفائدة الفعلي للتعرف على الفوائد في المرحلة 3 (عدم الاستحقاق) بشكل أساسي (إيقاف احتساب الفوائد على القروض في المرحلة 3 عبر وضع علامة عدم استحقاق). محرك IFRS9 كامل (مع منحنيات PD/LGD) خارج نطاق (MVP)، لكن (MVP) يضمن وجود الإطار (حقول، حسابات GL) لإضافته لاحقًا.
تدفقات عمل (Maker-Checker): على الأقل للمعاملات الحرجة (مثل تسويات دفتر الأستاذ العام، القيود المرتجعة، فتح الحسابات، المدفوعات الكبيرة) يتم تنفيذ عملية موافقة (maker-checker). من المرجح أن نستفيد من سير عمل (ERPNext) أو (doctype) موافقة مخصص. يضمن (MVP) أن أي معاملة مرتجعة أو عالية القيمة لا يمكن إنهاؤها بدون موافقة، مما يحقق مطلب التدقيق الأساسي.
قوالب الترحيل: تم تكوين القوالب المحاسبية الرئيسية للمعاملات القياسية في (MVP) (الصرف، السداد، خصم/إيداع الوديعة، احتساب الفائدة، دفع الفائدة، فرض الرسوم). هذا يقلل من الجهد اليدوي من اليوم الأول. قد تكون ثابتة نسبيًا في (MVP) (ربما في الكود أو ملفات التكوين)، وفي مراحل لاحقة يمكننا إنشاء واجهة مستخدم لموظفي المالية لتعديل القوالب. لكن (MVP) سيتضمن الرئيسية مضبوطة بشكل صحيح.
إشعارات (ClefinCode Chat) (انتقائية): سيتضمن (MVP) بعض الإشعارات ذات القيمة العالية من خلال تكامل (ClefinCode Chat) – على الأرجح تنبيهات المعاملات وإشعارات الرصيد/الكشوفات. على سبيل المثال، كلما حدثت معاملة تتجاوز مبلغًا معينًا، يتم إرسال رسالة SMS أو محادثة؛ يتم إرسال الكشوفات الشهرية عبر البريد الإلكتروني تلقائيًا. قد يكون التفاعل الثنائي الأساسي (مثل الرد على رسالة) محدودًا في (MVP)، لكن يمكن اختبار تفاعل بسيط أو اثنين (استعلام الرصيد عبر المحادثة) كإثبات مفهوم. التركيز الأساسي هو الإشعارات الصادرة لإبقاء العملاء على اطلاع (ميزة سريعة الربح).
نشر (ClefinCode Cloud) على (AWS): سيتم نشر (MVP) في بيئة سحابية (إذا اختار العميل السحابة) مع إعداد (HA) الموصوف (قاعدة بيانات متعددة المناطق AZ، إلخ). سنستخدم (MariaDB on AWS (Amazon RDS)) كقاعدة بيانات مُدارة في (MVP) لضمان الاستقرار والتركيز على منطق التطبيق بدلاً من إدارة قاعدة البيانات. (MariaDB) متوافقة بالكامل وخيار مستقر معروف لـ(ERPNext). يتيح استخدام (AWS) أيضًا التوفير السريع لبيئات التطوير/الاختبار/الإنتاج (“النشر ثلاثي المراحل”: التطوير، الاختبار المرحلي (UAT)، الإنتاج جميعها في السحابة، معزولة). إذا اختار العميل التشغيل الداخلي، يمكن تثبيت (MVP) على عدة خوادم أو أجهزة افتراضية باستخدام نفس البنية (MariaDB، Python، إلخ) ولكن مع جهد أكبر في العمليات. لكن وجود البنية المرجعية السحابية سيسرع حتى النشر الداخلي (نحاكي البنية).
المرونة والنسخ الاحتياطي الأساسي: في (MVP)، نقوم بتكوين النسخ الاحتياطية (لقطات يومية آلية أو تفريغات SQL) وعلى الأقل نسخة قراءة/نسخة احتياطية من قاعدة البيانات. نضمن أيضًا وجود مراقبة للتوافر. ربما ليس هناك توسع آلي كامل (غير مطلوب حتى ينمو الحمل)، لكن البنية جاهزة للتوسع.

المؤجل لما بعد (MVP) (مراحل مستقبلية):

حاسبة IFRS9 المتقدمة (ECL): دمج نموذج كامل للخسائر الائتمانية المتوقعة (مع مصفوفات الانتقال، العوامل الاقتصادية المستقبلية، إلخ) سيكون بعد (MVP). في (MVP) نتعامل مع المراحل والمخصصات اليدوية/الثابتة؛ وفي مرحلة لاحقة يمكن دمجه مع وحدة مخاطر أو استيراد من حسابات (Excel) لأتمتة المخصصات بشكل أكثر دقة.
محاسبة التحوط: هذه ميزة متقدمة لن يتم تناولها على الأرجح في (MVP). إذا كان لدى البنك أنشطة تحوط، فقد يديرون محاسبة التحوط خارج النظام أو عبر قيود تسوية يدوية. في إصدار مستقبلي يمكن إدخال القدرة على تعيين التحوطات والتعامل تلقائيًا مع تعديلات القيمة العادلة/قيود (OCI).
منتجات الخزينة (صفقات FX، المشتقات): خارج نطاق (MVP). ربما تتم معالجتها في نظام منفصل أو يتم دمجها لاحقًا. يركز (MVP) على الودائع والقروض.
أنواع منتجات إضافية: بطاقات الائتمان (رغم أنها مشابهة للسحب على المكشوف، إلا أن جوانب مثل نقاط المكافآت ودورة الفوترة قد تحتاج منطقًا مخصصًا)، التمويل التجاري (اعتمادات، كفالات)، المنتجات الاستثمارية، إلخ، ستكون تحسينات مستقبلية. ومع ذلك، فإن محرك المنتجات المرن لدينا يعني أن إضافة منتج بطاقة ائتمان لاحقًا هو في الغالب مسألة تكوين بالإضافة إلى بعض الميزات الفريدة (مثل حساب فترة السماح لبطاقات الائتمان) التي يمكننا برمجتها لاحقًا.
محرك رسوم/تسعير معقد: يتعامل (MVP) مع الرسوم المباشرة. يمكن إضافة محرك رسوم قائم على القواعد بشكل أكثر تعقيدًا (إعفاءات، عروض ترويجية، رسوم خدمات متدرجة) بعد الحصول على ملاحظات من العمليات.
أتمتة تدفقات العمل لجميع العمليات: سيتضمن (MVP) (maker-checker) ولكن ليس بالضرورة نظام (BPM) كامل لأشياء مثل إنشاء القروض (قد يكون يدويًا جزئيًا أو عبر نماذج بسيطة). في المستقبل، قد ندمج سير عمل إنشاء القروض (التطبيق، خطوات الموافقة) في النظام أو عبر (ClefinCode Chat) لفتح حسابات العملاء، إلخ.
المصرفية الحوارية المدعومة بالذكاء الاصطناعي على نطاق كامل: بينما يتضمن (MVP) إشعارات، فإن روبوت محادثة ذكي كامل يمكنه التعامل مع 98% من الاستفسارات (مثل مثال بنك (Banco Bolivariano)[16]) هو هدف طويل الأمد. سنكرر قدرات المحادثة مع المزيد من الأسئلة والأجوبة، وربما دمج مع محرك (AI NLP).
تحسين الأداء للتوسع الضخم: سيتم اختبار (MVP) لقاعدة المستخدمين المتوقعة مبدئيًا (بضع فروع، عملاء معتدلون). للتوسع الكبير جدًا (ملايين الحسابات)، قد نحتاج إلى تحسينات إضافية (مثل التقسيم أو طبقات التخزين المؤقت) والتي سننفذها حسب الحاجة عندما نصل إلى تلك المستويات.

خطة النشر من ثلاث مراحل:

سنتبع خطة نشر من 3 مراحل للتنفيذ والاختبار:

المرحلة 1 – التطوير والاختبارات الفردية: في هذه المرحلة، يقوم الفريق بتكوين النظام الأساسي (نموذج البيانات، تعريفات المنتجات، GL) واختبار المكونات الفردية (منطق الترحيل، احتساب الفوائد) ببيانات تجريبية. قد تكون هذه البيئة على خوادم محلية أو بيئة سحابية للتطوير. تحدث تكرارات وتعديلات متكررة هنا.
المرحلة 2 – اختبار قبول المستخدم (UAT): نقوم بنشر النظام في بيئة اختبار مرحلي (staging) تشبه الإنتاج. يتم تحميل بيانات تجريبية (أو بيانات مرحلية من نظام قائم إن وجدت). يحاكي المستخدمون الفعليون (عمليات البنك، المالية، إلخ) المعاملات اليومية في هذه البيئة. يتحققون من أن النظام يفي بالمتطلبات – على سبيل المثال، الفوائد المحسوبة تطابق حساباتهم اليدوية، التقارير تبدو صحيحة، وتدفقات العمل منطقية. يتم إصلاح أي مشكلات في هذه المرحلة. قد يستمر اختبار (UAT) لعدة أسابيع من الاختبارات الموازية ضد العملية القديمة لبناء الثقة.
المرحلة 3 – الإطلاق في الإنتاج: بعد الموافقة على (UAT)، نقوم بالنشر في بيئة الإنتاج. في البداية، قد يكون إطلاقًا تجريبيًا (ربما لفرع واحد أو شريحة من العملاء) كاختبار. يتم إجراء ترحيل البيانات (إذا جاء من نظام سابق) بعناية، ويتم تحميل الأرصدة اعتبارًا من تاريخ الانتقال. ثم نبدأ التشغيل المباشر، ربما خلال فترة نشاط منخفض (مثل عطلة نهاية الأسبوع) لتقليل التأثير. بعد التشغيل المباشر، نراقب عن كثب (تبدأ مراقبة (ClefinCode Cloud) بقوة هنا).

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

اعتبارات (MariaDB) و(ERPNext):

لقد أثبتت (MariaDB) قدرتها على التوسع للمصرفية الأساسية (حتى بعض الأنظمة السحابية الحديثة تعمل على (MySQL/MariaDB) للدفاتر الأساسية). سنقوم بضبط (MariaDB) بالإعدادات المناسبة (مثل (buffer pool)، حدود الاتصال) لاستخدامنا. سيتعامل (ORM) الخاص بـ(ERPNext) (إطار (Frappe)) مع الكثير من التفاعلات. يجب أن نضمن استخدام المعاملات في الكود عند الترحيل إلى جداول متعددة (وهو ما يمكن لـ(Frappe) القيام به عبر إدارة معاملات قاعدة البيانات). ملاحظة: (MariaDB) مقابل (PostgreSQL) – يستكشف (ERPNext) حاليًا (PostgreSQL)، لكن (MariaDB) هو الافتراضي حاليًا. نلتزم بـ(MariaDB) في الوقت الحالي لتجنب أي مشكلات توافق غير معروفة في مشروع بالغ الأهمية كهذا، ما لم نحدد سببًا مقنعًا للتغيير.

نلاحظ أيضًا أن (MariaDB) تدعم أنواع بيانات JSON ومخازن الوثائق إذا لزم الأمر – والتي يمكن أن تكون مفيدة لتخزين البيانات المرنة (مثل تخزين (ProductDefinition) أو (FeeSchedule) مباشرة كـ(JSON) في عمود). قد نستخدم هذه الميزة لحقول الامتداد، ولكن بحذر لأن (ERPNext) لا يستخدم أعمدة (JSON) على نطاق واسع. قد نستخدم الجداول العادية للحقول الأساسية وربما حقل JSON/نصي واحد لأي سمات مخصصة (لتلبية متطلبات غير متوقعة دون تغييرات على قاعدة البيانات).

الأمان: سيضمن (MVP) أيضًا الأمان الأساسي – الوصول المستند إلى الأدوار (لا يمكن للصرافين الموافقة على معاملاتهم الخاصة، إلخ)، التشفير عند الحاجة (ربما تشفير بيانات PII الحساسة أو استخدام (HTTPS) لجميع التفاعلات مع العملاء، إلخ). نظرًا لأنه نظام سحابي، سنضمن أن النشر في (AWS) آمن (عزل VPC، تشفير أثناء التخزين في (RDS)، إلخ).

في الختام، يقدم (MVP) منصة مصرفية أساسية عملية مع جميع الميزات الأساسية ضمن النطاق: المحاسبة مزدوجة القيد متعددة الفروع، خدمة منتجات الإيداع/القروض، معالجة الفوائد/الرسوم، الامتثال الأساسي لمعايير (IFRS)، والتكامل مع تدفقات عمل الإشعارات – جميعها مبنية على بنية تحتية سحابية قابلة للتوسع وآمنة (مع (MariaDB RDBMS) في جوهرها). نتجنب إضاعة الوقت في إعادة بناء ما يقدمه (ERPNext) بالفعل (إطار دفتر الأستاذ العام، إدارة المستخدمين، إلخ) ونركز على التوسعات الخاصة بالمجال. ينتج عن هذا النهج (MVP) قوي يمكن توسيعه في مراحل مستقبلية لدمج المزيد من التحليلات المتقدمة، والمنتجات، والأتمتة مع نمو احتياجات البنك. ستُبنى كل مرحلة لاحقة فوق النواة المستقرة المقدمة في (MVP)، مما يضمن رحلة سلسة من خط أساسي عملي إلى نظام مصرفي أساسي حديث وشامل.

المصادر: تتماشى مبادئ التصميم والميزات الموضحة مع أفضل الممارسات والأدبيات الحديثة في أنظمة المصرفية الأساسية[1][1][2][4][5][6][7][9][13][14][3][16][17][17]، مع تكييفها في سياق تطبيق قائم على (ERPNext). تم التخطيط لكل مكون من النظام، من نموذج البيانات إلى النشر السحابي، لتلبية الهدفين المزدوجين الغنى الوظيفي والمتانة التشغيلية المطلوبة في المصرفية الأساسية.

Global Digital Vibes