ما الذي يجعل البرمجيات المالية مختلفة عن تطبيق ويب عادي

"إنه مجرد تطبيق ويب ببضعة حقول إضافية"

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

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

1. المال ليس رقمًا عشريًا (float)

يمكن لتطبيق عادي أن يقرّب رقمًا معروضًا ويمضي قدمًا. أما دفتر الأستاذ فلا يستطيع ذلك. إذا خزّنت العملة كرقم عشري (floating-point)، فإن أخطاء التقريب الصغيرة تتراكم عبر آلاف المعاملات إلى أن يختل توازن الدفاتر — و"اختلال توازن الدفاتر" ليس تذكرة خلل عادية، بل حالة طوارئ في العمل.

الحل مملّ وإلزامي في آنٍ واحد: استخدام أعداد صحيحة للسنتات أو نوع بيانات عشري (decimal) مناسب، وعدم استخدام الأرقام العشرية في JavaScript إطلاقًا، وتمرير كل عملية حسابية — الضريبة، والخصومات، والتقسيمات، ومبالغ الاحتجاز (retention) — عبر قاعدة تقريب واحدة موحّدة في كل أنحاء قاعدة الشيفرة (codebase). نحن نعامل هذا كقاعدة فحص آلي (linting)، لا كملاحظة عابرة في مراجعة الكود.

2. لا شيء يُحذف

التطبيقات العادية تحذف السجلات باستمرار، سواء حذفًا ناعمًا (soft-delete) أو حذفًا كاملاً (hard-delete). أما الأنظمة المالية فلا تحذف — بل تصحّح، وتحتفظ بالنسخة الأصلية. دفتر الأستاذ ذو الإضافة فقط (append-only) يعني أن كل قيد يصبح غير قابل للتغيير بمجرد ترحيله (posted)؛ فالخطأ يُعالج بقيد جديد مرتبط بعكس اتجاهه، لا بتعديل القيد الأصلي أو حذفه. وهذا بالضبط ما يجعل النظام جاهزًا للتدقيق: فبإمكان المدقق تتبّع التاريخ الكامل لأي دولار، لا حالته الحالية فقط.

هذا القرار وحده يعيد تشكيل نموذج بياناتك بالكامل. فالجداول تحتاج إلى حقول posted_at وreversed_by وcreated_by في كل سجل مالي منذ اليوم الأول — إذ إن إضافة خاصية عدم القابلية للتغيير لاحقًا على مخطط (schema) صُمم أصلاً للسماح بالتعديل هو عملية إعادة بناء كاملة، لا مجرد ترحيل (migration).

3. كل إجراء عالي المخاطر يحتاج إلى عين ثانية

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

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

4. إعادة المحاولة تُنتج أموالاً مكررة إن سمحت لها بذلك

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

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

5. قواعد الاحتفاظ بالبيانات ووقت التشغيل ليست بيدك

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

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

كيف يبدو هذا في كل قطاع

التجزئة — نقطة الألم عادةً هي التسوية (reconciliation): يجب أن تتطابق مبيعات نقاط البيع (POS)، وتسويات معالج البطاقات، ومدفوعات الموردين، عبر عشرات المواقع، يوميًا، وبشكل تلقائي.

البناء — الفوترة المرحلية على طراز AIA وتتبّع مبالغ الاحتجاز (retention) يعنيان أن "الفاتورة" لا تصبح نهائية إلا بعد التحقق من إنجاز مرحلة معينة من المشروع؛ فدفتر الأستاذ يجب أن يمثّل الدفع الجزئي والمشروط، لا مجرد حالتي "مدفوع" أو "غير مدفوع". وقد بنينا هذا بالضبط لمقاول عقارات سكنية متعددة الوحدات وتجارية — راجع دراسة الحالة.

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

المؤسسي — دفاتر أستاذ المنح، وقيود المانحين، وميزانيات الأقسام، كلها تحتاج إلى محاسبة على مستوى الصناديق (fund-level): فالمال المخصص لغرض معين لا يمكن أن يغطي غرضًا آخر دون علم أحد، ويجب أن يكون لكل دولار مسار قابل للتتبع يعود إلى مصدره.

ما الذي يكلفك هذا فعليًا

لا شيء من هذا هندسة غريبة — إنها أنماط منضبطة ومفهومة جيدًا، تُطبَّق باتساق. لكنها تعني أن الوحدة المالية تستغرق وقتًا أطول من ميزة CRUD مماثلة، وتكلف أكثر لكل شاشة. في تجربتنا، تستغرق وحدة واحدة مركّزة — مثل تكاليف المشاريع (job costing)، أو استقبال المطالبات، أو لوحة تحكم للتسوية — من 10 إلى 16 أسبوعًا. أما مجموعة مالية متعددة الوحدات تغطي عدة عناصر مما سبق في آنٍ واحد، فتستغرق عادةً من 5 إلى 9 أشهر، مع إطلاق أول جزء قابل للاستخدام خلال أول 12 أسبوعًا.

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

الخلاصة

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