تدقيق مالي شامل · 6 محاور متوازية

تدقيق الحسابات + المبيعات/المشتريات/المخازن + جاهزية التصنيع

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

2026-06-16 · Accounting ~42.6K LOC (44 model · 40 service · 40 action · 139 route · 63 test) · Sales 17K · Purchases 18.5K · Inventory 16.3K

ناضجالحسابات: نظام محاسبي حقيقي

7+باجز محاسبية حرجة

~85٪جاهزية Sales→MRP (الطلب)

~60٪جاهزية المخازن للتصنيع

18اقتراح إضافة (KSA + كبرى)

⚖️

٠ — الحكم العام

حسابات ناضجة وشاملة فعلاً — بس فيها عيوب سلامة بيانات حرجة في GL. والمخازن محتاجة شغل قبل التصنيع.

الحسابات نظام محاسبي حقيقي وكامل (مش skeleton): دليل حسابات شجري، قيود مزدوجة بـ bcmath، فترات مالية بقفل، عملات متعددة + إعادة تقييم، بنوك وتسويات، أصول ثابتة وإهلاك، موازنات ومراكز تكلفة، زكاة، وZATCA (في موديول EInvoicing). القوائم المالية موجودة (ميزان مراجعة، دخل، مركز مالي، تدفقات). والـ posting موحّد عبر action واحد — تصميم ممتاز.

لكن — العيب الأخطر: القيد المزدوج (مدين=دائن) مش مفروض وقت الحفظ! دالة التحقق validateBalance() موجودة بس **كود ميت مش متنادى**. قيد غير متوازن من أي موديول بيتحفظ ويُرحّل، والخلل بيتكشف لاحقاً بـ scanner مش بيتمنع. ده + باجز الإقفال السنوي المزدوج والترحيل المزدوج = مخاطر مالية حقيقية.

التكامل مع التصنيع: المبيعات→MRP (الطلب) جاهز فعلاً ✅. المشتريات→MRP (التوريد) فيه فجوات (حلقة الشراء بتقف عند موافقة يدوية). المخازن عقد StockService اللي التصنيع بيستخدمه ممتاز، بس التكلفة (WAC layers) والـ UoM والـ lot/expiry محتاجين شغل قبل تشغيل التصنيع جدّياً.

🏛️

١ — الحسابات: المعمارية والموجود (هل شغّال؟)

نعم شغّال وكامل — الدورة المحاسبية مقفولة والقوائم موجودة.

الموجود فعلاً

الدورة كاملة: دليل حسابات شجري ← قيود (إنشاء/اعتماد/ترحيل) ← دفتر أستاذ وميزان مراجعة ← قوائم مالية.
القوائم المالية: ميزان مراجعة، قائمة دخل (P&L)، مركز مالي (Balance Sheet)، تدفقات نقدية، أعمار ديون AR/AP، كشف حساب شريك، موازنة فعلي.
متقدم: إعادة تقييم عملات (IAS 21)، إهلاك أصول، تسوية بنكية بقواعد، قيود متكررة، إقفال سنوي، زكاة، شيكات (PDC).
Posting موحّد: كل الموديولات (Sales/Purchases/Production/LIS/HRM) بتمرّ على action واحد CreateJournalEntry داخل transaction مع idempotency_key.
دقة مالية: bcmath في قلب القيود (مفيش float drift)، 29 enum لآلات الحالة، فصل Action/Service/DTO نظيف.

الحكم: نطاق production-grade حقيقي. ZATCA Phase-2 موجود في موديول EInvoicing منفصل (UBL 2.1 + CSID + clearance) لكنه مدفوع من Sales/POS مش من الحسابات.

ضعف معماري

العقد بيتجاوَز: الموديولات بتنده الـ action بـ raw arrays بدل الـ AccountingServiceInterface/DTO الموجود — فالحدود المعرّفة مش بتفيد.
أنماط ترحيل غير متسقة: التصنيع events→listeners، والباقي imperative.
كنترولرز سمينة: ExpenseRevenueReportController 640 سطر (منطق تقارير في كنترولر).
فشل auto-post صامت: القيد يفضل Draft مع Log::warning بس — الموديول اللي افترض إنه اترحّل ماياخدش إشارة.

🐞

٢ — الحسابات: باجز GL حرجة

العيوب اللي بتأثر على توازن الدفاتر والأرقام المالية مباشرة.

CRITICAL القيد المزدوج مش مفروض وقت الإنشاء/الترحيل (validateBalance كود ميت)

JournalEntryService.php:44 (مش متنادى) · CreateJournalEntry.php:61 · StoreJournalEntryRequest.php (مفيش قاعدة توازن)

القيد بيحسب total_debit/credit ويخزّنهم من غير ما يتأكد إنهم متساويين. قيد غير متوازن بيتحفظ Draft من غير خطأ، والوحيد اللي بيمنع = خطوة الاعتماد (لو مش متجاوَزة). مفيش DB CHECK constraint ولا حارس وقت الكتابة → التوازن معتمد على فحص واحد بيقرأ أعمدة self-reported.

CRITICAL الإقفال السنوي يقدر يشتغل مرتين → أرباح محتجزة مزدوجة

YearEndClosingService.php:25 · ExecuteYearEndClosing.php:44 (مفيش unique على fiscal_year_id)

الحارس بيتأكد بس من isClosed()؛ بعد ReopenFiscalYear الحالة تبقى Reopened فالـ readiness يعدّي تاني. إقفال تاني = نقل صافي الدخل للأرباح المحتجزة مرة كمان → حقوق الملكية مبالغ فيها بسنة كاملة. وكمان: السنة بتتعلّم "مقفولة" حتى لو قيود الإقفال فشلت تترحّل بصمت.

CRITICAL الاعتماد المزدوج/إعادة المحاولة بيرحّل لـ GL مرتين (idempotency_key مش متبعت)

ApprovePaymentVoucher.php:22 · ApproveReceiptVoucher · ApproveExpense · ApproveRevenue

الحارس if(!isDraft()) بدون قفل، والمستند بيتحمّل بدون lockForUpdate. اعتمادان متزامنان (دبل كليك/retry) الاتنين يعدّوا ويرحّلوا → قيدان لمستند واحد. آلية الـ idempotency موجودة في CreateJournalEntry بس مفيش action بيبعت المفتاح.

#	المشكلة	المكان	الخطورة
—	سطر كشف بنكي يقدر يتطابق مرتين/أكثر من قيمته (مفيش unique ولا قفل) → رصيد مسوّى مبالغ فيه	`BankReconciliationService.php:187`	CRIT
—	إشارة ربح/خسارة إعادة التقييم غلط للالتزامات (AP/قروض) — مكسب يتسجّل بدل خسارة	`RevalueForeignBalances.php:59`	HIGH
—	الإهلاك المتناقص ~12× أبطأ (خلط شهور/سنين في المعادلة)	`FixedAssetService.php:48`	HIGH
—	`dispose()` بيحط الخسارة في حساب مصروف الإهلاك ويسيب القيد غير مرحّل → الأصل يفضل في الميزانية	`FixedAssetService.php:230`	HIGH
—	شيك مرتجع/ملغي بعد التحصيل مفيش قيد عكسي → بنك/كاش مبالغ فيه	`ReturnCheck.php · CancelCheck.php`	HIGH
—	رصيد العهدة (petty cash) lost-update بدون قفل → سحب زائد	`PettyCashBalanceService.php:60`	HIGH
—	الإقفال/المقاصة غير transactional وبدون قفل (race)	`CloseFiscalYear.php · ArApService.php:240`	HIGH

فجوة تستات: صفر تغطية لـ idempotency والـ concurrency؛ ومفيش تست بيرسل قيد غير متوازن عبر الـ API ويتوقع رفضه (لأنه مفيش حارس أصلاً). الإقفال المزدوج بعد reopen مش متغطّى. (إيجابي: SequenceService توليد الأرقام atomic وآمن).

🧩

٣ — الحسابات: الناقص مقارنة بالأنظمة الكبرى + نضيف إيه

مقارنة بـ QuickBooks/Xero/Zoho/Odoo/SAP — مع سياق السعودية (ZATCA/زكاة/IFRS).

القدرة	الحالة	ملاحظة
GL أساسي (دليل/قيود/فترات/عملات/متكررة)	موجود	ناضج
القوائم: ميزان/دخل/مركز مالي	موجود	—
قائمة التدفقات النقدية	جزئي	proxy مبسّط — مش indirect method حقيقي (مفيش working-capital/إهلاك add-back). أكبر فجوة صحة
أعمدة المقارنة (سنة سابقة)	ناقص	كل القوائم فترة واحدة بس
تسوية AR/AP على مستوى الفاتورة (allocation)	جزئي	على مستوى الحساب + netting بس
فرق عملة محقّق (realized FX) عند السداد	ناقص	بس unrealized revaluation
إقرار ضريبة القيمة المضافة بصيغة ZATCA	ناقص	في ملخص بالنسبة بس — مفيش نموذج الـ 14 خانة
توقيع ZATCA XAdES/XMLDSIG كامل	جزئي	التوقيع مخزّن كـ XML comment — ممكن يترفض في Phase-2
الزكاة (طريقة صافي الثروة)	موجود	محتاج طبقة تعديلات SOCPA
أبعاد/تحليلية (project/segment) على سطر القيد	جزئي	مركز تكلفة بس
دمج كيانات/Intercompany · إيراد مؤجل · مسار تدقيق hash-chain · workflow اعتماد	ناقص	قدرات enterprise

أولويات الإضافة

المستوى ١ — امتثال السعودية: إقرار VAT بصيغة ZATCA · توقيع XAdES كامل · ضريبة عكسية/استيراد على AP · شهادات WHT · تعديلات زكاة SOCPA.
المستوى ٢ — اكتمال القوائم: تدفقات نقدية indirect حقيقية · أعمدة مقارنة · فرق عملة محقّق · تسوية AR/AP على مستوى الفاتورة · AR/AP متعدد العملات.
المستوى ٣ — enterprise: إطار أبعاد عام (project/department) · إيراد مؤجل/استحقاقات · محاسبة مشاريع · دمج كيانات + intercompany · مسار تدقيق hash-chain · workflow اعتماد قابل للتهيئة · feeds بنكية آلية.

🛒

٤ — المبيعات والمشتريات

مبنيين كويس standalone — بس فيهم فجوات قفل وثغرة استلام خطيرة.

قوي

كل الـ actions المعدِّلة داخل transaction مع فحص enum؛ GL موحّد ومتوازن؛ المرتجعات بتعكس الإيراد/الضريبة/COGS وترجّع المخزون؛ تسوية مدفوعات FIFO بدايلوج كويس. PostLandedCostVoucher هو النمط المرجعي (قفل + idempotency).

محتاج شغل

المشكلة	المكان	الخطورة
استلام بضاعة (GRN) ضد أمر شراء Draft/غير معتمد — يكتب مخزون و received_quantity لأمر لسه ماتعمدش	`PurchaseGrnController.php:335`	CRIT
مسارات إنشاء/تحويل المبيعات مش transactional → headers يتيمة تلوّث طلب الـ MRP	`SalesOrderController.php:120`	HIGH
مسارات الترحيل بدون `lockForUpdate` + بدون `whereNull(journal_entry_id)` → ترحيل/خصم مخزون مزدوج	`PostSalesInvoice.php:32`	HIGH
فاتورة يدوية بتتجاوز فحص حالة الأمر وسقف الكمية؛ مفيش فرض حد ائتماني	`SalesInvoiceController.php:113`	HIGH
`received_quantity` read-modify-write غير atomic؛ مفيش مسار عكس لـ GRN معتمد	`PurchaseGrnController.php:524`	HIGH

📦

٥ — المخازن والتكلفة

عقد StockService ممتاز — بس صحة التكلفة (WAC/FIFO) والقفل والـ lot محتاجين شغل.

قوي وجاهز للتصنيع

عقد reserve/release/ATP صحيح وatomic — التصنيع بيستخدمه صح (حجز عند الإطلاق، تحرير عند الصرف).
MRP بيقرأ المتاح الحقيقي (on-hand − reserved) مش الإجمالي. reserved_quantity متتبّع مع unique index.
تدفّق التكلفة متماسك عبر الـ wrappers (WIP→FG roll-up بيغذّي unit_cost).

محتاج شغل

CRITICAL طريقة WAC مبتستهلكش cost layers → تقارير التقييم مبتتطابقش

StockService.php:126 (FIFO بس) · InventoryCostReportController.php:105 vs InventoryReportController.php:221

في الوضع الافتراضي (weighted_avg) الصرف بيقلّل total_value بس بيسيب remaining_quantity في الطبقات زي ما هي. فتقرير الأعمار (يجمع الطبقات) وتقرير قيمة المخزون (يقرأ StockBalance) مبيتصالحوش بعد أي صرف، والطبقات تكبر بلا حدود.

المشكلة	المكان	الخطورة
تكلفة FIFO بتضيع عند التحويل بين المخازن (يستلم بمتوسط مش بطبقات)	`ShipTransfer.php:61`	HIGH
FIFO بيقلّل التكلفة عند المخزون السالب (الزيادة تتصرف بتكلفة صفر) → COGS أقل	`StockService.php:257`	HIGH
قفل غير متسق: core `increaseStock/decreaseStock` read-modify-write بدون قفل → lost update	`StockService.php:38,141`	HIGH
مفيش lot/expiry على StockBalance وcost layers — genealogy التصنيع مالهاش مقابل في المخزون؛ مفيش FEFO	`StockBalance · InventoryCostLayer`	HIGH
مفيش تحويل وحدات (UoM) عند حدود المخزون — صرف BOM بوحدة مختلفة عن الشراء = جمع غلط	`StockService.php:47`	HIGH

🏭

٦ — جاهزية التكامل مع التصنيع (الحكم المجمّع)

التزاوج صحي وأحادي الاتجاه — لكن فيه ٣ فجوات بتكسر الحلقة المغلقة.

التدفّق	الحالة	التفاصيل
المبيعات → MRP (الطلب)	جاهز ✅	MRP بيقرأ `SalesOrder` بحقول صحيحة و`delivered_quantity` متتبّع فعلاً. أهم تدفّق وهو سليم.
المشتريات → MRP (التوريد)	فجوة	الـ PO المُولّد من MRP بيتعمل `Draft` بس `canConvert()` بيطلب `Approved` → الحلقة بتقف عند موافقة يدوية. والمرتجع مبيقللش `received_quantity` → إشارتا التوريد بتختلفا.
المخازن → التصنيع	العقد ممتاز	reserve/release/ATP صحيح — بس التكلفة (WAC/FIFO) والـ UoM والـ lot محتاجين إصلاح قبل التشغيل الجدّي.
التصنيع → الحسابات (GL)	شغّال	عبر events→listeners بـ idempotency — أنظف نمط في الـ ERP.

الخلاصة: العمود الفقري للطلب (المبيعات) جاهز، والـ GL جاهز. اللي محتاج إصلاح قبل التصنيع الجدّي: (١) قفل حلقة الشراء MRP→PR→PO، (٢) إصلاح تكلفة المخازن (WAC layers + FIFO transfer + negative)، (٣) إضافة UoM وlot/expiry على حدود المخزون عشان batch genealogy.

🖥️

٧ — الـ UI والفورمات (هل شغّالة كويس؟)

أحسن من الـ LIS (فيه design system حقيقي، مفيش شاشات ميتة) — بس فيه فجوات مهمة.

الفورمات

قيد اليومية = أقوى فورم ✅ — موازنة حيّة (الحفظ معطّل لو غير متوازن)، فحص XOR للمدين/الدائن، منتقي حسابات مفلتر.
فاتورة المبيعات غنية بس god component (1,703 سطر). مشكلة الضريبة لكل سطر = صفر ثابت (taxAmount=0) — المستخدم مبيشوفش الضريبة قبل الحفظ!
صرف المخزون: مشكلة مفيش منع صرف أكتر من المتاح — الكمية المتاحة مجرد badge، التحقق على qty≥0.01 بس. خطر سلامة بيانات.
مفيش عرض تطابق ثلاثي (PO↔GRN↔Bill) رغم وجود الداتا.

الشاشات والجودة

مهم الحسابات مالهاش شاشات قوائم مالية! الـ P&L/مركز مالي/تدفقات موجودين بس تحت features/lis/ (دومين تاني)، مش في الحسابات. وميزان المراجعة tab داخل الـ ledger بس.
فيه design system حقيقي (data-table، form-dialog، product-search مُعاد استخدامه في 34 ملف) — عكس الـ LIS.
0 من 38 component بيستخدم OnPush؛ god components (invoices 1703، bills 1558)؛ منطق سطور الفاتورة مكرّر 8 مرات (تغيير قاعدة ضريبة = تعديل 8 أماكن).
مفيش ARIA على الجداول المخصّصة؛ ألوان hex يدوية في المخزون/المشتريات.

أهم تحسينات UI: (١) إظهار الضريبة حيّة في الفواتير، (٢) منع الصرف الزائد، (٣) شاشات قوائم مالية في الحسابات (انقلها من lis)، (٤) عرض تطابق ثلاثي، (٥) استخراج <line-items-grid> مشترك + OnPush.

🗺️

٨ — خطة العمل (بالأولوية)

الموجة	الشغل	ليه
١ — سلامة GL	افرض القيد المزدوج وقت الكتابة (+ DB CHECK)، idempotency_key من كل المعتمِدين + قفل، حماية الإقفال السنوي من التكرار	بتفسد توازن الدفاتر والأرقام دلوقتي
٢ — باجز مالية	إشارة FX للالتزامات، إهلاك متناقص، dispose()، قيد عكس الشيكات، تطابق بنكي مزدوج، قفل العهدة	أرقام مالية غلط
٣ — جاهزية التصنيع	قفل حلقة MRP→PR→PO، GRN ضد PO معتمد، إصلاح WAC layers + FIFO transfer/negative، UoM + lot/expiry على المخزون، قفل post paths	قبل تشغيل التصنيع جدّياً
٤ — امتثال KSA	إقرار VAT بصيغة ZATCA، توقيع XAdES كامل، ضريبة عكسية، شهادات WHT، تعديلات زكاة	تنظيمي
٥ — اكتمال + UI	تدفقات indirect، أعمدة مقارنة، تسوية فاتورة AR/AP، شاشات قوائم مالية في الحسابات، الضريبة الحيّة، منع الصرف الزائد، OnPush + line-items-grid	اكتمال وظيفي وتجربة
٦ — enterprise	أبعاد عامة، إيراد مؤجل، دمج كيانات، مسار تدقيق hash-chain، workflow اعتماد	توسّع مستقبلي

الخلاصة: الحسابات أساس قوي جداً ومتبنيش من جديد — ركّز على إصلاحات سلامة GL (الموجة ١-٢) لأنها بتأثر على الأرقام دلوقتي، وبعدين جاهزية المخازن/الشراء للتصنيع لو هتشغّل التصنيع، وبعدين امتثال KSA.

تدقيق الحسابات + المبيعات/المشتريات/المخازن + جاهزية التصنيع — Moon ERP · 6 محاور · أدلة من الكود · 2026-06-16