تدقيق فني عميق · 5 محاور متوازية

تقرير تدقيق موديول التصنيع (Production) — Moon ERP

تحليل شامل لموديول التصنيع في برنامج حسابات moonui: نقاط القوة، الباجز، الأمان، الأداء، والنواقص — بأدلة من الكود (file:line) وخطة عمل مرتّبة بالأولوية.

2026-06-15 · Backend ~31.5K LOC (16 controllers · 32 models · 38 migrations · 14 actions) · Frontend ~9.6K LOC (19 screens)

قويالحكم العام: مبني فعلياً

3مشاكل حرجة (Critical)

8+مشاكل عالية (High)

5فجوات GMP فارما (P0)

~41Kإجمالي سطور الكود

⚖️

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

موديول حقيقي وناضج، مش بروتوتايب — بس فيه عيوب سلامة بيانات مركّزة في التكلفة والـ MRP، وفجوات GMP مهمة للفارما.

ده نظام MRP-II حقيقي ومبني باحتراف: دورة كاملة (MRP ← أمر إنتاج ← صرف خامات ← تأكيد ← استلام ← تكلفة ← قيود GL)، آلة MRP زمنية فعلية بـ BOM explosion و pegging، تصنيع بالأمر للغير (toll) شغّال، وتتبّع تشغيلات (genealogy). صفر TODO/FIXME و18 من 19 شاشة موصولة بالـ backend.

طبقة المستندات (صرف/استلام/تأكيد/إقفال) ممتازة ومحصّنة: كل عملية متعددة الخطوات داخل DB::transaction مع lockForUpdate، والقيود لها idempotency_key. العيوب الحقيقية مركّزة في 3 أماكن: حسابات التكلفة/الانحرافات، تزامن الـ MRP، ومسارَي إنشاء (Order/BOM) بدون transaction.

أخطر نقطة للفارما: مفيش بوابة جودة (QC hold) قبل استلام المنتج التام أو قبل صرف الخامة — حالة الجودة متحطوطة 'released' ثابتة، ومفيش quarantine/rejected. ده أكبر عائق GMP.

💪

١ — نقاط القوة (مبني كويس — متعملش فيه)

الحاجات دي صلبة ومتعتمد عليها — متعيد بناءها.

نمط Action-per-use-case + GL مفصول بالـ Events: كل منطق كتابة في Action class مستقل، والقيود المحاسبية في Listeners بترتيب موثّق (EventServiceProvider.php:34-70) — تصميم نموذجي.
سلامة التزامن في التشغيلات: MfgBatch::availableQuantity() وdrainPendingForOrder() بيستخدموا allocated_pending + lockForUpdate لمنع الحجز المزدوج (TOCTOU).
منطق مجال غني على الـ models: بوابات حالة أمر الإنتاج (canRelease/canIssue/canComplete)، آلة حالة الانحرافات (canTransitionTo())، isToll().
MRP زمني حقيقي: netting من الإجمالي للصافي، جدول توريد مؤرّخ، safety stock، BOM متعدد المستويات بـ low-level coding وحماية من الدوران (cycle guard + depth cap 20).
تصنيع بالأمر للغير (Toll) كامل: خامة العميل مستبعدة من GL المخزون/WIP، قيود toll-clearing، وفاتورة أتعاب AR تلقائية.
Backflushing (صرف تلقائي عند التأكيد) + صرف يدوي على نفس المسار · دورة WIP→FG كاملة في GL · تتبّع genealogy أمامي/خلفي حقيقي · تطبيق وتسوية overhead آخر الشهر.
أمان أساسي قوي: كل المسارات خلف auth:sanctum + صلاحيات granular، وكل الـ controllers بتعمل company-scoping يدوي. صفر SQL injection، صفر $guarded=[].
انضباط enums (20 enum) ودقة أرقام مالية (تكلفة decimal:4، كميات decimal:3) ثابتة.

🏛️

٢ — المعمارية

التقسيم سليم، بس فيه "god classes" وكنترولرز سمينة وأنماط غير متسقة.

التقسيم

Controller ← Action ← Model (منطق الكتابة في Actions، مفيش service layer للكتابة — مجلد Services/ شبه فاضي). الأحداث/المستمعين منظّمين كويس لقيود الـ GL. التعامل مع الـ transactions متسق في كل الـ actions المعدِّلة.

الضعف المعماري

HIGH God-classes — ملفات أكبر بكتير من حد 800 سطر

RunMrp.php = 1,149 LOC · ConfirmOperation.php = 1,005 LOC · ProductionOrderController.php = 832 LOC · orders.component.ts = 1,487 LOC

آلة الـ MRP كلها في class واحد (GC + demand + netting + scheduling + lot-sizing + explosion + pegging). ConfirmOperation أوركستراتور متخفي في صورة action (بيستدعي Inventory + GL + HRM piecework). محتاجين تفكيك لـ classes أصغر (DemandCollector / NettingEngine / LotSizer / BomExploder / Pegger).

MED أنماط غير متسقة

غالبية الموديلز enums حقيقية، بس MfgMpsHeader/Line وMfgVarianceRecord بيستخدموا const strings (عُرفين متنافسين). مفيش query scopes — فلترة where('company_id') متكتوبة يدوي في كل مكان. وصول مباشر لموديولات تانية عبر app(...) بدل anti-corruption boundary.

🐞

٣ — الباجز وسلامة البيانات

العيوب الحقيقية مركّزة في التكلفة/الانحرافات والـ MRP ومسارَي إنشاء بدون transaction.

CRITICAL C1 — معادلة انحراف حجم التكلفة الثابتة (FOVV) غلط رياضياً

ComputeOrderVariances.php:374-375

بيقارن ميزانية الفترة كاملة بالمطبّق على أمر واحد، فأي أمر إنتاجه أقل من حجم الفترة بيطلع انحراف ≈ الميزانية الشهرية كلها كـ "غير مواتٍ". الصح: (budgetedVolume − produced) × stdFixedRate. الأثر: انحراف OH ثابت غلط على كل أمر، وتقارير إدارية مشوّهة. (مفيش تست يغطي المسار).

CRITICAL C2 — إنشاء أمر الإنتاج بدون transaction

ProductionOrderController.php:134-178 (store)

توليد رقم تسلسلي ← إنشاء الأمر ← N خامات ← N عمليات ← تحديث التكاليف المخططة — كله مش داخل DB::transaction. أي فشل في النص بيسيب أمر يتيم نص-مكتمل برقم مستهلك وتكاليف ناقصة. كل مسارات الإنشاء الأخرى عاملة transaction — ده الوحيد المنسي.

CRITICAL C3 — إنشاء الـ BOM بنفس المشكلة (بدون transaction)

BomController.php:73-99 (store)

إنشاء BOM ← مكوّنات + بدائل ← عمليات، بدون transaction (عكس clone/setDefault بتوعه). BOM نص-مكتمل بيغذّي أوامر إنتاج لاحقة → فساد بيانات أساسية.

#	المشكلة	المكان	الخطورة
H1	تشغيلات MRP متزامنة بتفسد بعض — الـ purge على مستوى الشركة كلها مش مستوى الـ run، ومفيش قفل "run واحد نشط"	`RunMrp.php:161-184`	HIGH
H2	توليد `run_number` بـ `count()+1` = race condition	`RunMrp.php:1143`	HIGH
H3	هيدر الـ run والـ CRP برّه transaction الـ netting — run "فاشل" بيسيب planned orders حيّة	`RunMrp.php:100,138`	HIGH
H4	تسوية الـ overhead check-then-act بدون قفل (TOCTOU) → ترحيل مزدوج آخر الشهر	`SettleAppliedOverhead.php:58-83`	HIGH
H5	حفظ الانحرافات غير transactional وغير idempotent → سجلات مكرّرة عند إعادة الحساب	`ComputeOrderVariances.php:591`	HIGH
H6	`recordOutput` بيخلّي الكمية المنتجة تكبر بلا سقف مقابل الخطة → تكلفة وحدة و yield مشوّهين	`ProductionOrderController.php:538`	HIGH
H7	مفيش تحويل وحدات قياس (UoM) في الـ MRP/BOM explosion — لو مكوّن بوحدة مختلفة عن وحدة المخزون → فساد كميات صامت	`RunMrp.php:1018`, `BomExplosionService.php:103`	HIGH
H8	المطبّق مقابل الفعلي للـ overhead متقاسين بمستوى/نطاق مختلف → انحراف تسوية وهمي	`SettleAppliedOverhead.php:129-232`	HIGH
M1	roll-up التكلفة المعيارية بيدمج عمل/OH التجميعة الفرعية في leg "الخامة" للأب → تصنيف انحراف غلط	`RollUpStandardCost.php:159`	MED
M2	قاعدة `min_max` بتغطّي العجز ناقص بصمت بدون split/exception	`RunMrp.php:925`	MED
M3	`period_order` (POQ) لا-عملية و`eoq` = fixed بس (stubs)	`RunMrp.php:916`	MED
M9	`per_page` بلا سقف في 3 endpoints → full-table hydrate / DoS	`ProductionOrderController.php:93`	MED
L1	`cancel`/`unrelease` بيبلعوا أخطاء تحرير الحجز وبيغيّروا الحالة برضه → تسريب حجز	`ProductionOrderController.php:387`	LOW

أكبر فجوة في التستات: مفيش ولا تست تزامن حقيقي — كل الـ lockForUpdate (خط الدفاع الأساسي) متستّت بشكل تسلسلي على connection واحد. لو شِلت كل الـ lockForUpdate() مش هيفشل ولا تست. كمان الانحرافات متستّتة في اتجاه واحد بس (كلها غير مواتية).

🔐

٤ — الأمان

الوضع العام قوي — الفجوات ضيقة ومحدّدة، بس فيها مخاطرة عبور-المستأجرين.

HIGH H1 — تعيين مستخدم من شركة تانية عبر owner_user_id (IDOR)

VarianceController.php:118

owner_user_id متحقّق منه كرقم موجب بس — مش مقيّد بشركة المستخدم. مهاجم بيـ PATCH انحراف بـ owner_user_id لمستخدم في شركة تانية → فساد ملكية + كشف بيانات. الكنترولر التاني (ConfirmationController:74) بيعمل scoping صح لنفس النوع — يعني سهو. الإصلاح سطر واحد: Rule::exists('users','id')->where('company_id',$companyId).

#	المشكلة	المكان	الخطورة
M1	قواعد `exists` غير مقيّدة بالشركة في الـ BOM (product/unit/center) → ربط كيانات شركة تانية	`BomController.php:162,165,205`	MED
M2	نفس المشكلة في صرف الخامة/استلام التام/فاتورة toll (warehouse/customer/tax)	`ProductionOrderController.php:584+`	MED
L1	403 بدل 404 على موارد شركة تانية → كشف وجود الـ ID (enumeration)	10 controllers	LOW

مشكلة منهجية (التصميم): مفيش Global Tenant Scope — عزل القراءة 100% يدوي. الموديول دلوقتي عامله صح في كل مكان، بس مفيش شبكة أمان: أي query مستقبلي ينسى where('company_id') هيسرّب بصمت. التوصية: اعمل CompanyScope عام (addGlobalScope) يشيل الاعتماد على إن كل مطوّر يفتكر.

⚡

٥ — الأداء

المشاكل بتظهر مع الحجم (40+ منتج، آلاف الأوامر): MRP متزامن، N+1، فهارس ناقصة.

CRITICAL تشغيل الـ MRP متزامن (synchronous) بيحجز الـ request

MrpController.php:61 → RunMrp.php:91,111,138

كل آلة الـ MRP + الـ explosion + الـ pegging + الـ CRP بتشتغل جوه request واحد وtransaction واحدة. مع 40+ منتج → دقايق بتحجز PHP worker وقفل طويل. الحل: ادفعها لـ queued job، ورجّع الـ run فوراً، وخلّي الـ cockpit يـ poll.

CRITICAL resolveDefaultBom() بيتعاد استعلامه لكل منتج بدون memoization (N+1)

RunMrp.php:1043 (متنادى من :425, :642, :557)

نفس الـ BOM SELECT بيتعمل مئات المرات في الـ run. + supplySchedule() بيعمل 4-5 استعلامات منفصلة لكل منتج. الحل: memoize الـ BOM والـ supply لكل منتج طول الـ run.

فهارس ناقصة (إضافة migration واحدة آمنة تحلّها)

الجدول	الفهرس الناقص	الأثر
`production_orders`	`(company_id,product_id,status)` + `(company_id,planned_end_date)`	CRIT full scan في توريد MRP
`bill_of_materials`	`(company_id,product_id,is_active,is_default)`	CRIT أسخن lookup في MRP
`mfg_mrp_planned_orders`	`(company_id,product_id)`, `(mrp_run_id,due_date)`	HIGH
`bom_components`	`product_id` (where-used / LLC)	HIGH

الواجهة الأمامية

CRIT factory-dashboard بيسحب كل الأوامر للمتصفح ويعدّها client-side (:286). استخدم endpoints تجميع زي ما orders بيعمل.
HIGH confirmations/batches/board بيـ listAll() بلا حدود + جداول بدون virtualization؛ والـ board بيـ poll snapshot غير محدود كل 30 ثانية.
النمط الصح للنسخ: production-orders.component بيستخدم [lazy] server paging + endpoint statusCounts() — طبّقه على الباقي.

🧩

٦ — النواقص (فارما GMP + MRP-II)

النواقص دي "حذف نطاق" مش stubs نص-مكتملة — الـ core شغّال.

P0 — حرجة لمصنع أدوية / toll

P0 مفيش بوابة جودة (QC hold) قبل استلام التام أو عند الصرف — quality_status='released' ثابتة، وحالة الـ batch بس active|consumed|expired (مفيش quarantine/rejected/under-test). تشغيلة محجوزة بتتصرف بحرية. أكبر عائق GMP
P0 مفيش سجل تشغيلة إلكتروني (BMR) / توقيعات إلكترونية / مسار تدقيق 21 CFR Part 11.
P0 الصلاحية ناقصة: بس expiry_date حر — مفيش manufacture_date/retest_date/اشتقاق shelf-life/منع صرف تشغيلة منتهية.
P0 مفيش تتبّع تركيز/معايرة (potency/assay) ولا مرجع COA على الـ batch.
P0 التصنيع لدى الغير (subcontracting) غايب تماماً — مفيش subcontract PO ولا عملية خارجية. (ملاحظة: الاتجاه العكسي toll مبني).

P1 — فجوات MRP-II وظيفية

CRP بلا سعة منتهية: بيبلّغ التحميل الزائد بس مبيعدّلش الجدول ليناسب السعة (مفيش finite levelling).
جدولة أرض المصنع infinite — قوائم أولوية مش تحميل منتهي/dispatch list.
مسار إعادة التشغيل (rework) خامل — الكمية بتتسجّل بس مبتعملش أمر/إعادة توجيه/تكلفة. (الـ scrap حقيقي وبيرفع NCR).
مفيش تنبؤ بالطلب (forecasting) · مفيش ATP والـ CTP سطحي · EOQ/POQ stubs.
مفيش انحراف yield ولا by-product/co-product costing · Average & FIFO costing محجوزين بلا منطق (بس Standard و Actual شغّالين).
ملكية التشغيلة (own/customer) على سطور الصرف مش على MfgBatch → فجوة فصل toll في المخزون.

🗺️

٧ — خطة العمل المقترحة (بالأولوية)

رتّبتها بالأثر/المخاطرة — ابدأ من فوق لتحت.

الموجة	الشغل	ليه دلوقتي
١ — إصلاحات حرجة	صلّح C1 (معادلة FOVV)، لفّ C2/C3 في transaction، وحطّ سقف للكمية المنتجة (H6)	دي بتفسد بيانات مالية/مخزون فعلياً دلوقتي
٢ — تزامن MRP/OH	قفل "run واحد نشط" + run-scoped purge (H1)، transaction حول الـ run+CRP (H3)، idempotency للـ overhead والانحرافات (H4/H5)	تمنع فساد التخطيط والترحيل المزدوج
٣ — أمان	scope الـ `owner_user_id` (H1) وكل قواعد `exists` (M1/M2)، وزوّد `CompanyScope` عام	إصلاحات صغيرة، تقفل عبور-المستأجرين
٤ — أداء	اعمل queue للـ MRP/rollUp/convertAll، memoize الـ BOM/supply، migration الفهارس، وصلّح N+1 في الصرف/التأكيد	ضروري قبل ما الداتا تكبر
٥ — GMP فارما	حالة batch (quarantine/released/rejected) + بوابة QC قبل الاستلام/الصرف، حقول الصلاحية/الـ potency، وملكية على الـ batch	متطلبات تنظيمية لمصنع أدوية
٦ — اكتمال + جودة كود	subcontracting، rework حقيقي، تستات تزامن، وتفكيك الـ god-classes (RunMrp/ConfirmOperation)	قيمة طويلة المدى وقابلية صيانة

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

تقرير تدقيق موديول التصنيع — Moon ERP · 5 محاور (معمارية · جودة · أمان · أداء · اكتمال) · أدلة من الكود · 2026-06-15