Knowledge Base · Plans · Manufacturing

دورة التصنيع حسب الطلب (Make-to-Order)
تحليل دورة العميل وربطها بمديول الصناعة الحالي

مطابقة كاملة بين الدورة اللي وصفها العميل (طلب إنتاج → تطوير → إنتاج → موافقة محاسبية → أمر إنتاج → صرف) وبين الموجود فعليًا في Modules/Production + الـ FE، مع تحديد الفجوات الحقيقية واقتراح خطة الربط.

الخلاصة: المديول مبني ~90% — الناقص هو «واجهة الطلب» + «3 بوابات موافقة محاسبية»، نوصّلها مش نبنيها من الصفر.
المصدر: مسح بـ 9 وكلاء متوازيين للـ BE والـ FE والوثائق · مُتحقَّق بالكود (file:line) · 2026-06-18
~90%
من ميكانيكا الدورة مبنية ومشحونة بالفعل
45+
شاشة مصنع موجودة (8 مجموعات منيو)
3
بوابات موافقة محاسبية ناقصة تمامًا
1
كيان جديد رئيسي: «طلب الإنتاج»

§1 الملخص التنفيذي

الدورة اللي وصفها العميل ليست شيئًا جديدًا على النظام — هي تقريبًا نفس workflow «التصنيع التعاقدي/التول» الموثّق بالفعل في mfg-pharma-toll-fitgap.html. كل الميكانيكا الثقيلة موجودة: BOM متعدد المستويات، Routing مستقل، حساب تكلفة 3-أرجل، دورة أمر إنتاج بحالات مُلزَمة على السيرفر، صرف خامات FEFO بقيود WIP متوازنة، توليف/أمانة، و~28 تقرير تكاليف + Cost-AI.

✅ الموجود جاهز (نعيد استخدامه)

  • المنتج + المرفقات: نظام مرفقات polymorphic — أي منتج يشيل PDF وصور بأي عدد (موجود BE، ناقص زر رفع في الـ UI).
  • BOM + المكوّنات + العمليات كاملة (حتى supply_source والبدائل).
  • Routing + مراكز عمل بمعدلات تكلفة + RollUpStandardCost (مادة/عمالة/أوفرهيد).
  • أمر الإنتاج + Order Cockpit: stepper + تبويب توفّر الخامات + تكلفة + GL + pegging.
  • الصرف وترحيل التكلفة: DR WIP / CR مخزون، FEFO، دفعات.
  • محرك موافقات عام في Core (متعدد المستويات بثريشولد) — مبني بس غير موصّل.

🔴 الناقص فعلًا (الشغل الصافي)

  • كيان «طلب إنتاج» (Intake): واجهة دخول العميل — غير موجود ككيان قياسي.
  • توجيه المنتج الجديد (مالوش BOM) → قسم التطوير كـ workflow — غير موجود.
  • بوابة محاسبية 1: اعتماد الطلب → توليد أمر بيع → ثم أمر إنتاج.
  • بوابة محاسبية 2: منع إطلاق أمر الإنتاج إلا بموافقة.
  • بوابة محاسبية 3: منع صرف الخامات الإضافية إلا بموافقة.
  • حقول تسجيل قانونية على المنتج + ترقية «فحص توفّر الخامات» من استشاري → بوابة.
المعنى العملي: مفيش إعادة بناء. إحنا بنركّب «طبقة رفيعة» (واجهة طلب + توصيل محرك الموافقات عند 3 نقاط) فوق أساس صناعي ناضج وجاهز.

§2 دورة العميل المطلوبة

7 مراحل عبر 4 أقسام، فيها 3 بوابات موافقة محاسبية إلزامية (لا انتقال إلا بموافقة).

1
الاستقبال / التول
طلب إنتاج
العميل يختار منتج موجود أو يضيف جديد + كمية + يرفع البيانات القانونية / PDF / صورة التركيبة (مربوطة بالمنتج وتتعاد).
2
التطوير (R&D)
عمل الـ BOM
لو المنتج جديد ومالوش BOM، يظهر لقسم التطوير اللي يصمّم قائمة المكوّنات.
3
الإنتاج
إكمال BOM + Route
الإنتاج يكمّل الـ BOM (تعبئة…) ويصمّم مسار العمليات → تطلع تكلفة المنتج.
4
الحسابات
اعتماد → أمر بيع
الحسابات تراجع وتعتمد الطلب فيتولّد أمر بيع. لا يتحول لأمر إنتاج إلا بالاعتماد.
بوابة 1
5
تخطيط + حسابات
أمر إنتاج + إطلاق
يتحوّل لأمر إنتاج → تخطيط + تأكد توفّر الخامات. لا إطلاق إلا بموافقة الحسابات.
بوابة 2
6
المخزن / الإنتاج
صرف الخامات
تتصرف خامات الـ BOM من المخزن ويبدأ الإنتاج ويمشي على المراحل.
7
الحسابات
خامات إضافية
أي طلب خامات إضافية برّه الـ BOM لازم الحسابات توافق عليه قبل ما يطلع من المخزن.
بوابة 3
الفكرة المحورية: 3 بوابات موافقة محاسبية تحكم الانتقال — (1) الطلب→أمر بيع، (2) إطلاق أمر الإنتاج، (3) صرف الخامات الإضافية. ده القلب الناقص في النظام الحالي.

§3 مطابقة كل مرحلة بالسيستم الحالي

موجود جاهز للاستخدام جزئي موجود بس محتاج تعديل/تفعيل ناقص بناء جديد
المرحلةالموجود في النظامالحالةالمرجع / الفجوة
1. طلب الإنتاج
(اختيار/إضافة منتج + كمية + مرفقات)
المنتج + الكمية موجودين. المرفقات polymorphic (attachments) تشيل PDF/صور (10MB). عقد التول (MfgTollContract/Line) عمليًا «واجهة طلب» جاهزة ~70%: مربوط بعميل، سطوره تختار منتج موجود أو تكتب منتج جديد free-text، كمية، مرفقات، دورة حياة، ويولّد أمر إنتاج لكل سطر. جزئي مفيش كيان «طلب إنتاج» قياسي. عقد التول فريمه «خامة العميل/consignment» = فريم تجاري غلط للـ MTO. مفيش زر رفع مرفقات في الـ UI. MfgTollContractLine.php:28-88
2. التطوير يعمل BOM محرّر BOM كامل (/factory/boms): مكوّنات + عمليات + تقدير تكلفة. حالة Draft/Active/Inactive موجودة. جزئي الـ BOM بيتولد Active على طول — مفيش draft→موافقة، مفيش ملكية قسم (تطوير)، ومفيش queue «منتج محتاج BOM». BomController.php · BomStatus.php
3. الإنتاج: إكمال BOM + Route → تكلفة Routing مستقل (MfgRoutingHeader/Operation) + مراكز عمل بمعدلات + RollUpStandardCost يحسب 3 أرجل (مادة من BOM + عمالة/أوفرهيد من الـ Routing). موجود مكتمل. RollUpStandardCost.php · routing.component (ملاحظة: وقت التجهيز setup غير مُوزّع في v1).
4. الحسابات تعتمد → أمر بيع بوابة 1 أمر البيع موجود (SalesOrder) بحالاته. محرك موافقات عام في Core (متعدد المستويات + ثريشولد مبلغ). الربط SO↔MO موجود عبر MfgPegging. ناقص أمر البيع بيتعمل بدون موافقة. محرك الموافقات غير موصّل ومافيهوش أنواع «إنتاج». مفيش مسار «اعتماد الطلب → إنشاء أمر بيع → أمر إنتاج». ApprovalDocumentType.php · SalesOrderController.php
5. أمر إنتاج: تخطيط + توفّر خامات + إطلاق بوابة 2 دورة أمر الإنتاج كاملة (planned→released→…) + تخطيط MRP/MPS/CRP + تبويب توفّر الخامات (readiness) ownership-aware + حجز المخزون عند الإطلاق. جزئي الإطلاق (ReleaseProductionOrder) يتم بـ permission إنتاجي فقط — مفيش بوابة موافقة محاسبية. فحص توفّر الخامات استشاري ومابيمنعش الإطلاق. ReleaseProductionOrder.php · OrderCockpit::readiness
6. صرف خامات الـ BOM IssueMaterialsMfgMaterialIssue يلفّ InventoryIssue: FEFO + دفعات + قيد DR WIP / CR مخزون. Staging + backflush موجودين. موجود شغّال. ملاحظة: الصرف خطوة صريحة (مش تلقائي عند الإطلاق)، وبـ production.consume (مخزن/إنتاج).
7. خامات إضافية بموافقة بوابة 3 ناقص مفيش كيان «طلب خامات إضافية»، مفيش سقف كمية ضد الـ BOM (الصرف فوق الـ BOM مسموح بحرية)، ومفيش توقيع حسابات قبل خروج المخزن. IssueMaterials.php (لا cap / لا approval)

§4 الفجوات الحقيقية (الشغل الصافي الجديد)

أ) كيان «طلب الإنتاج» (Production Request) — الواجهة الأمامية

نكلون شكل عقد التول (MfgTollContract) لكن بفريم MTO قياسي: رأس مربوط بعميل + سطور (منتج موجود أو منتج جديد free-text) + كمية مستهدفة + مرفقات (قانونية/PDF/صورة تركيبة) + دورة حياة فيها حالة «بانتظار اعتماد الحسابات». نشيل material_ownership='customer' (خامة المصنع مش العميل).

ب) توجيه المنتج الجديد → قسم التطوير

منطق «منتج بلا BOM ⇒ يدخل طابور التطوير» + ملكية قسم على الـ BOM + حالة draft→معتمد. حاليًا الـ BOM بيتولد Active مباشرة ومفيش طابور. (الموجود فقط: علم order_type=rnd/pilot وهو عمود ميت بلا UI أو منطق.)

ج) الـ 3 بوابات المحاسبية — أكبر بند بناء

  • بوابة 1: اعتماد طلب الإنتاج ⇒ إنشاء أمر بيع ⇒ ثم تحويله لأمر إنتاج (عبر MfgPegging).
  • بوابة 2: فحص موافقة داخل ReleaseProductionOrder::execute قبل الانتقال planned→released.
  • بوابة 3: فحص موافقة داخل IssueMaterials لأي صرف يتجاوز الـ BOM/الكمية المخططة.

د) تحسينات داعمة

  • حقول تسجيل قانونية/تنظيمية على المنتج (regulatory_* / JSON) + علم product_class (منتج تام/خام).
  • زر رفع مرفقات في شاشة المنتج/الطلب (العرض موجود، الرفع ناقص).
  • (اختياري) ترقية readiness من استشاري → بوابة صلبة قبل الإطلاق.

هـ) فجوات صغيرة موثّقة (خارج نطاق الدورة)

  • زر «تسوية الأوفرهيد» (الـ BE جاهز).
  • أعمدة order_type/production_type ميتة — نُعيد توظيفها أو نشيلها.
  • تكلفة إعادة التشغيل (rework) غير مكتملة.
  • أداة مطابقة WIP الفعلي مفقودة.

§5 المعمارية المقترحة (نوصّل مش نبني)

1 · محرك الموافقات الموجود = أساس الـ 3 بوابات

في Core محرك موافقات كامل (ApprovalWorkflow + Levels بثريشولد مبلغ + موافق role/user + auto-approve). بس مفصول: submitForApproval() ما بينادَاش من الإنتاج، والموافقة بتحدّث السجل فقط (مفيش event يغيّر حالة المستند)، وApprovalDocumentType مافيهوش أنواع إنتاج.

التوصيل المطلوب (3 خطوات صغيرة):

  • نضيف لـ ApprovalDocumentType أنواع: ProductionRequest, ProductionLaunch, MaterialIssue (تحت ApprovalModule::Production الموجود).
  • نضيف event/callback عند fully_approved ينقل حالة المستند المرتبط (trait Approvable خفيف).
  • نحط فحص الموافقة عند 3 نقاط: إنشاء أمر البيع من الطلب، ReleaseProductionOrder، IssueMaterials (للإضافي).

2 · «طلب الإنتاج» — نكلون نمط التول

نسخة قياسية من MfgTollContract: نفس شكل (عميل + سطور منتج-موجود/جديد + كمية + مرفقات + دورة حياة)، بدون ملكية العميل. الفعل «سطر معتمد ⇒ أمر إنتاج» جاهز كقالب في CreateOrderFromTollContractLine — نشيل material_ownership='customer' ونضيف فرع «منتج جديد ⇒ التطوير».

3 · الربط SO↔MO + التكلفة جاهزين

MfgPegging (sales_order_id + production_order_id) موجود — نستخدمه كرابط الـ MTO. وكل قيود التكلفة (صرف/تأكيد/استلام/إغلاق) شغّالة عبر listeners. مفيش أي تغيير محاسبي مطلوب.

قرار موثّق سابقًا نلتزم بيه: ماتبنيش طبقة تخطيط/readiness موازية — حسّن OrderCockpit::readiness الموجود (Phase B اتشطب لأنه كرّرها).

§6 خطة التنفيذ المقترحة بالمراحل

مرحلة 1
تسجيل المنتج + المرفقات — حقول قانونية/تنظيمية + product_class على المنتج، وزر رفع مرفقات (PDF/صورة تركيبة) في شاشة المنتج. (أقل مخاطرة، قيمة فورية، ومستقلة.)
BE: products migrationFE: product-detail uploadيعيد استخدام Attachment الموجود
مرحلة 2
كيان «طلب الإنتاج» + توجيه التطوير — كيان الطلب (كلون التول) + شاشة intake + منطق «منتج جديد بلا BOM ⇒ طابور التطوير» + حالة BOM draft→معتمد + ملكية قسم.
BE: ProductionRequestBOM status workflowFE: شاشة طلب + طابور تطوير
مرحلة 3
الـ 3 بوابات المحاسبية — توصيل محرك الموافقات: أنواع إنتاج + trait/event + فحص عند (الطلب→أمر بيع) و(الإطلاق) و(الصرف الإضافي) + كيان «طلب خامات إضافية» بسقف ضد الـ BOM.
Core: ApprovalDocumentTypeApprovable trait + eventReleaseProductionOrder gateIssueMaterials gate
مرحلة 4
صقل + اختياري — ترقية readiness لبوابة صلبة، شاشات اعتماد للحسابات (inbox)، وتنظيف الأعمدة الميتة. + الفجوات الصغيرة الموثّقة عند الحاجة.
readiness كبوابةAccounting approval inboxcleanup
ترتيب المراحل مبني على «المخاطرة الأقل والاستقلالية الأعلى أولًا». مرحلة 3 هي الأثقل والأهم (قلب طلب العميل) لكنها تبني على 1 و2.

§7 قرارات مفتوحة محتاج رأيك فيها

1) «قسم التول» عند الاستقبال: ده اسم قسم الاستقبال/المبيعات عندهم، ولا فعلاً تصنيع تعاقدي بخامة العميل (toll)؟ ده بيحدد هنكلون نمط التول كـ MTO عادي (خامة المصنع) ولا نستخدم التول الموجود مباشرة (خامة العميل).
2) «أمر بيع» مقابل «أمر إنتاج»: الاعتماد بيعمل أمر بيع وبعدها أمر إنتاج — صح؟ يعني الطلب يولّد أمر بيع للعميل (الفاتورة/السعر)، وبالتوازي أمر إنتاج للمصنع، ومربوطين بـ pegging. تأكيد؟
3) فحص توفّر الخامات: عايزه «بوابة صلبة» تمنع الإطلاق لو الخامات ناقصة، ولا «تحذير» فقط والحسابات تقرر؟
4) تعريف «خامات إضافية»: أي صرف يتجاوز كمية الـ BOM المخططة = إضافي محتاج موافقة؟ ولا بس لو طلب مادة مش موجودة أصلًا في الـ BOM؟
5) من يعتمد: بوابة واحدة (محاسب) لكل البوابات، ولا متعددة المستويات بثريشولد مبلغ (المحرك بيدعم الاتنين)؟

§8 مراجع (خطط موجودة نبني عليها)