توحيد العملة في Moon ERP

الخلاصة في سطرين

البرنامج مكانش عنده إجابة واحدة لسؤال «الشركة دي بتتعامل بأي عملة؟». كان عنده تلاتة: المحاسبة والمبيعات والمشتريات بيفترضوا KWD، والمعمل (LIS) بيفترض SAR، والمتجر الإلكتروني بيفترض EGP — كل واحد مكتوب في الكود نفسه. يعني نفس الشركة تقدر تطبع فاتورة بعملة وإيصال بعملة تانية.

والأسوأ إن أغلب صفوف الفلوس مكانش مكتوب عليها عملة أصلًا: ٥٥٤ صف من ٦٤١ في جداول المدفوعات والسندات والتحويلات فاضيين تمامًا من العملة، لأن كل قواعد التحقق كاتبة nullable — فأي مسار إنشاء مايذكرش الحقل بيكتب فراغ في صمت.

الرقم اللي بيحكي القصة

ده مش انطباع — ده إحصاء فعلي على قاعدة moonui2_dev_be لكل جدول بيحمل فلوس:

لاحظ آخر سطر: sales_invoices مش فاضية — دي المشكلة التانية، وهي أخطر من الفراغ: بيانات مكتوبة وغلط.

السبب الجذري: تلات قيم افتراضية في برنامج واحد

لما الكود مايلاقيش عملة، بيرجع لقيمة مكتوبة فيه. المشكلة إن كل موديول اتكتب في وقت مختلف وبتفكير مختلف، فطلعت تلات إجابات:

وفي حالة واحدة كانت أوحش: StorefrontSeoMetadata.php:210 مكانش عنده افتراضي خالص — كان بيكتب strtoupper((string) $company->currency) على طول. لو عمود الشركة فاضي، بيطلع لجوجل "priceCurrency": "" في بيانات المنتج المهيكلة، وده بيلغي العرض من نتائج التسوّق.

واقعة «EG» — كود عملة مش موجود في الدنيا

شركة «بلاك سيركل» (رقم 4) عملتها المعرَّفة SAR، والتعريفين متطابقين (العمود companies.currency وcurrencies.is_base — مفيش تعارض هنا). ومع ذلك فواتيرها الـ٣٢ اتقسمت كده:

وفي جدول العملات نفسه لقيت صفّين:

id=7  co=4  code=EG    active=0   جنيه
id=8  co=4  code=EGP   active=0   جنيه مصري

يعني حد كتب «EG» بالغلط، اكتشف الغلط، عمل «EGP» صح، وعطّل الاتنين — لكن الفاتورة INV-2026-00006 (بتاريخ 2026-04-28، بمبلغ 95.000، وحالتها مدفوعة) فضلت شايلة الكود الغلط للأبد.

ليه دخل أصلًا؟

لقيت الباب مفتوح على مصراعيه في StoreCurrencyRequest.php:20:

'code' => ['required', 'string', 'max:10'],

أي نص لحد ١٠ حروف كان يعدّي ككود عملة. مفيش أي تحقق من إنه كود ISO-4217 حقيقي.

اللي اتصلّح فعلًا — ١٩ ملف

كل تعديل تحت ده منفّذ ومتحقّق نحويًا، مش اقتراح:

١. توحيد القراءة (١٠ مواقع)

كل الافتراضيات المكتوبة في الكود اتشالت، وبقى كله بيسأل نفس المصدر: app(CompanyCurrency::class)->code($companyId).

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

٢. قفل مسار الكتابة (٧ نماذج + طبقة جديدة)

تفاصيلها في القسم الجاي.

٣. قفل بيانات العملات الرئيسية (ملف واحد)

StoreCurrencyRequest — شرحه فوق في واقعة EG.

٤. الواجهة (Angular) — وفيها كان مستخبّي رابع افتراضي

مسحت moon-erp/src كلها. الواجهة عندها مصدر واحد بالفعل (CompanyCurrencyService) وأغلب الشاشات بتستخدمه — بس فيه تلات نتايج حقيقية:

الباقي (دالتا طباعة السندات وخدمات LIS) مسجّل بالتفصيل في «الباقي المفتوح» تحت — مش متسكّت عليه.

الطبقة المشتركة الجديدة — FillsCompanyCurrency

الملف: Modules/Core/app/Concerns/FillsCompanyCurrency.php

ده أهم جزء في الشغل كله، والسبب إني عملته كده مهم: مكانش ينفع أصلّح ٤٠ شاشة. لو صلّحت الشاشات واحدة واحدة، أول شاشة جديدة تتكتب بعد كده هترجع تكتب فراغ تاني. فالإصلاح اتحط عند الحدّ اللي كل المسارات بتعدّي منه — لحظة إنشاء الصف نفسها.

static::creating(function ($model) {
    // لو الحقل فاضي فقط — عمرها ما بتلمس اختيار المستخدم
    if (in_array('currency_id', $fillable) && $model->currency_id === null) {
        $model->currency_id = $currency->id($companyId);
    }
    if (in_array('currency_code', $fillable) && blank($model->currency_code)) {
        $model->currency_code = $currency->code($companyId);
    }
});

مطبّقة على السبعة اللي الإحصاء أثبت خواءهم — ولا واحد زيادة عن الدليل: SalesPayment · PurchasePayment · PaymentVoucher · ReceiptVoucher · AccountTransfer · PurchaseBill · BankAccount.

دفتر الأستاذ — ليه قررت أسيبه زي ما هو

journal_entry_lines هو أكبر رقم في الإحصاء: ٥٢٣ من ٥٢٣ من غير عملة. الحاجة السهلة كانت إني أملاه زي الباقي. مافعلتش، وده السبب — وهو سبب بالدليل مش برأي.

روحت شفت مين بيقرأ العمود ده أصلًا. الجهة الوحيدة اللي بتاخد قرار بناءً عليه هي CurrencyRevaluationService.php:51:

->whereNotNull('currency_id')
->where('currency_id', '!=', $baseCurrencyId)

الاستعلام بيستبعد الفاضي وعملة الأساس مع بعض. يعني في المنطق ده NULL معناها بالظبط «بعملة الشركة» — وهي معلومة محمولة مش إهمال.

السطور اللي فعلًا بعملة أجنبية بتاخد عملتها من المستند المصدر (ApprovePaymentVoucher وApproveReceiptVoucher بينقلوا $voucher->currency_id) — والسندات دي بقت مضمونة العملة دلوقتي بعد التعديل. يعني الأستاذ بيتحسّن من المنبع، وده المكان الصح.

حاجات شكلها غلط وهي سليمة — سِبتها عمدًا

المراجعة اللي بتبلّغ عن كل حاجة كأنها عيب بتفقد قيمتها. ده اللي فحصته وقررت إنه صح:

الملاحظة الوحيدة على NumberToWordsService إن الـparameter الافتراضي بتاعها 'KWD' — بس كل نداءاتها بتمرّر العملة صراحةً، والنداءات دي بقت سليمة بعد التعديل.

قرارات محتاجة منك

التلاتة دول بيمسّوا مستندات مالية مرحّلة، ودي مش حاجة أعملها من نفسي حتى مع تفويض «صحّح مباشرة» — التصحيح المباشر للكود، مش لفواتير مقفولة.

قرار ١ — الفاتورة INV-2026-00006 بكود «EG» اتنفّذ

فاتورة مدفوعة بمبلغ 95.000 وسعر صرف 1.000000. سعر الصرف = ١ على شركة عملتها SAR معناه إن المبلغ ده ريال واتسمّى غلط، مش جنيه.

• ترشيحي: تتصحّح لـSAR بترحيل بيانات مُوثَّق (لأن سعر الصرف ١ بيقول كده).
• البديل: تتسمّى EGP — بس ساعتها المبلغ غلط لأن ٩٥ جنيه ≠ ٩٥ ريال.
• البديل التالت: تتساب كما هي كسجل تاريخي، ونمنع تكرارها بس (اللي عملته فعلًا).

قرار ٢ — الـ١٣ فاتورة بالدينار الكويتي على شركة سعودية اتنفّذ

إجماليها 3,038.900 وكلها سعر صرف ١. نفس المنطق: دي شبه مؤكد مبالغ بالريال واتختمت بالدينار من الافتراضي القديم 'KWD' اللي شِلته النهاردة.

• ترشيحي: ترحيل بيانات يصحّح currency_code لـSAR للفواتير اللي exchange_rate = 1 وعملة شركتها مختلفة — بشرط موافقتك، وبنسخة احتياطية قبلها، وبتقرير بالصفوف اللي اتغيّرت.
• مالمش الحق أعمله من غير كلمة منك — دي فواتير مقفولة.

قرار ٣ — الـ٥٥٤ صف الفاضيين الموجودين حاليًا لسه مفتوح

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

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

قرار ٤ — صفّ العملة «EG» في البيانات الرئيسية اتنفّذ

معطّل بالفعل (is_active=0) فمش هيظهر لحد. أرشّح حذفه بعد ما نحسم قرار ١، عشان مايفضلش لغم لو حد فعّله بالغلط. لكن لو الفاتورة هتفضل شايلة «EG»، لازم الصف يفضل موجود.

الباقي المفتوح — بأمانة

حاجات لقيتها ومقدرتش أقفلها في الشغل ده، مسجّلة هنا عشان ماتضيعش: