التحليل الشامل لإضافة موديول التصنيع إلى Moon ERP
الخريطة، الفجوات، التكاملات، وخطة البناء

القرار الأول: أين يُبنى؟ — توسعة Modules/Production القائم، لا موديول جديد

الـ ERP يحتوي بالفعل موديول إنتاج مبدئياً (7 جداول: مراكز إنتاج، BOM بمكوناته وعملياته، أوامر إنتاج بموادها وعملياتها) — والفحص أثبت أن جداوله هي نفسها كيانات المواصفة في صورتها الأولية، وأن لديه واجهة Angular كاملة و19 صلاحية مسجّلة وترقيم مستندات جاهز، بينما لا توجد عليه أي بيانات إنتاج ولا يشير إليه أي موديول آخر. لذا القرار: التوسعة في المكان — الجداول السبعة تُمدّد لتطابق المواصفة، وكل الكيانات الجديدة (24 جدولاً: المسارات، العُدد والقوالب، التخطيط MPS/MRP/CRP، التأكيدات، التكلفة المعيارية والانحرافات السبعة، صالة الإنتاج) تُنشأ ببادئة mfg_، وبادئة الصلاحيات تبقى production.*. إنشاء Modules/Manufacturing منفصل كان سيعني ازدواج الصلاحيات والترقيم والواجهة ثم مشروع إهلاك للقديم — هدر صافٍ.

القرار الثاني: ماذا يُعاد استخدامه؟ — التصنيع «عميل» لتسعة موديولات

• المخزون: الصرف والاستلام حصراً عبر مستندات ApproveIssue/ApproveReceipt القائمة (لا لمس مباشر للأرصدة)، والتسعير FIFO/متوسط من StockService — مخازن أمانة بعلم consignment لمواد العميل (التصنيع بالأجر Toll).
• الحسابات: كل قيود دورة التكلفة (تحت التشغيل ← انحرافات ← تسوية) حصراً عبر CreateJournalEntry — ومراكز التكلفة وسجل الأصول الثابتة موجودان فعلاً (للقوالب يُضاف فقط إهلاك بالاستخدام).
• المشتريات: مخرجات MRP تتحول طلبات شراء داخل دورة الاعتماد القائمة. المبيعات: أوامر البيع مصدر الطلب للـ MPS مع ربط Pegging. الموارد البشرية: العمالة والورديات وتكلفة التأكيدات. الجودة QMS: الفحص أثناء التشغيل وعدم المطابقة على الهالك — بلا جداول جودة مكررة. الصيانة CMMS: مراكز العمل والقوالب أصول قابلة للصيانة بعدادات اللقطات. النواة: دليل الأصناف ووحدات القياس والموافقات والمرفقات.
• قاعدة الاتجاه الواحد: التصنيع يستورد من الجميع للأمام، ولا يقرأ أي موديول جداول mfg_ أبداً (حتى تغذية رواتب القطعة تُدفع إلى جدول تملكه HRM) — نفس وصفة LIS المجرّبة.

سؤالك: ما الناقص؟ — في الاتجاهين

ناقص في Moon ERP (يُبنى ضمن المراحل): حجوزات المواد reserve/release (العمود موجود بلا منطق)، إجراء CreatePurchaseRequest من MRP، تتبع اللوط/الباتش والجينيالوجيا في حركة المخزون، تقويم تشغيل وورديات لمراكز العمل، إهلاك بالاستخدام UnitsOfProduction للقوالب، ربط مراكز العمل بمراكز التكلفة، نمط واجهة لمس لصالة الإنتاج. وناقص في المواصفة نفسها (نقد خبير للتحليل المُسلَّم): آلية تحويل وحدات القياس بين مستويات الـ BOM، تتبع اللوط من الخام للمنتج، التعاقد الخارجي لعمليةٍ ضمن المسار (وليس فقط Toll)، أوامر إعادة التشغيل والتصرف في المعيب، تفاصيل المنتجات المشتركة/الثانوية وطريقة توزيعها، تقويم التخطيط، إدارة أوامر التغيير الهندسي ECO، ومصدر التنبؤ بالطلب — كلها موثقة بدرجات الخطورة والعلاج المقترح في قسم الفجوات.

خطة البناء — 7 مراحل بأول منفعة مبكرة

1. المرحلة 0 (S): تثبيت الأساس — إصلاح الـ FKs الدفاعية، مساهم الصلاحيات، إعدادات الحسابات production.*.
2. المرحلة 1 (L) ⭐ أول زيادة قابلة للاستخدام: بيانات أساسية v2 + أوامر إنتاج حقيقية ترحّل مخزوناً وقيوداً (صرف خام ← تحت التشغيل ← استلام تام).
3. المرحلة 2 (L): المسارات والعُدد/القوالب وتأكيدات العمليات وتكلفة التحويل.
4. المرحلة 3 (M): محرك التكلفة المعيارية والانحرافات السبعة والتسوية الشهرية.
5. المرحلة 4 (L): التخطيط — MRP وPegging وطلبات الشراء الآلية وCRP وMPS مبسّط.
6. المرحلة 5 (M): صالة الإنتاج — طرفيات اللمس والتقدم الآلي ولوحة لحظية.
7. المرحلة 6 (L): التصنيع بالأجر، جينيالوجيا الباتشات، التعميق مع الجيران.

الجودة والمنهجية

11 وكيل فحص على Opus 4.8 (7 قرأوا أجزاء المواصفة بلا فقد + 4 خرّطوا كود الـ ERP الفعلي بالملف والسطر)، ثم 4 محللي قرار أنتجوا الخريطة والفجوات والعقود وخارطة الطريق، ثم مراجعة عدائية مستقلة طاردت التناقضات فرصدت 5 مخالفات (أهمها: وثيقة عقود كُتبت بهوية موديول خاطئة، وتجاوزان لقناة المستندات) — وأُصلحت جميعها في الملفات قبل إصدار هذا التقرير، وصحّحت المراجعة أيضاً ادعاءً خاطئاً بغياب سجل الأصول الثابتة (موجود ومتحقق منه). الملحق الفني manufacturing-erp-analysis.md مُعدّ ليُغذّى مباشرة إلى Claude Code عند بدء التنفيذ.

تحديث (11 يونيو): متطلبات عميل حقيقي — مصنع أدوية تصنيع للغير

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

القرار الأول والحاسم: توسعة Modules/Production في مكانها — لا وحدة جديدة

بعد تدقيق كامل للوحدة الحالية (التقرير 10)، القرار هو EXTEND in place وليس إنشاء Modules/Manufacturing موازية. الأسباب:

• مخاطرة ترحيل شبه معدومة: لا بيانات إنتاجية (البذّار فارغ)، لا مفاتيح أجنبية واردة من أي وحدة أخرى، لا اختبارات ستنكسر.
• سقالة مدفوعة الثمن مسبقاً: 19 صلاحية مسجلة في RolePermissionSeeder، وواجهة Angular كاملة (features/production) بتطابق تام مع الـ API، وترقيم مستندات جاهز عبر SequenceService('production','order').
• الجداول السبعة الحالية هي نفسها كيانات المواصفة: مراكز العمل وقوائم المواد وأوامر الإنتاج موجودة بهيكل صحيح وتحتاج أعمدة إضافية فقط.
• وحدة موازية تعني ازدواجاً: ازدواج فضاء الصلاحيات production.* والتسلسلات والواجهة، ثم مشروع إهلاك للوحدة القديمة بلا أي عائد.

قاعدة التسمية: الجداول السبعة القديمة تحتفظ بأسمائها، وكل جدول جديد يأخذ البادئة mfg_ وفق وصفة الوحدات السريرية الموثقة. بادئة الصلاحيات تبقى production.* وتُسجَّل كمساهم في Core PermissionDependencyRegistry تماماً كما تسجل وحدة المختبرات lis.

مسار ترحيل الجداول السبعة الحالية

جدول القرارات الكامل — كياناً بكيان

الوصفة المنزلية: التعدادات وآلات الحالات والأحداث

• التعدادات (PHP Enums): 20+ تعداداً في Modules/Production/app/Enums تغطي تعدادات المواصفة الأحد عشر كلها (production_type, material_ownership, procurement_type, costing_method, labor_calc, issue_type, issue_level, resource_type, lot_sizing_rule, order_status, operation_status) إضافة لتعدادات دورات حياة BOM/Routing/Tool والمستندات.
• آلات الحالات: الأمر Planned→Released→InProcess→Completed→Closed (+إلغاء من أول حالتين)؛ العملية Waiting→Ready→InProgress→Completed؛ العُدّة Available→Mounted→Maintenance→Retired (الدورات تُحتسب فقط في Mounted)؛ المستندات الثلاثة Draft→Posted→Reversed.
• الأحداث والمستمعون: ProductionOrderReleased, MaterialIssued, OperationCompleted, ConfirmationPosted, GoodsReceiptPosted, ProductionOrderClosed — كل ترحيل دفتري عبر مستمع يستدعي Modules\Accounting\Actions\CreateJournalEntry حصراً، بوسم source_type='production_order' وبُعد مركز التكلفة على كل سطر.
• Actions للتقاطعات: ReleaseProductionOrder, PostMaterialIssue, PostConfirmation, PostGoodsReceipt, CloseProductionOrder, RunMps/RunMrp/RunCrp, ComputeStandardCost, FirmPlannedOrders, PromiseDate.
• القواسم الموروثة مجاناً: BaseModel/TenantAware (company_id)، DataScope لنطاق الفروع، SequenceService لترقيم كل مستند، وإضافة حالة Production لتعداد ApprovalModule في Core.

لمسات صغيرة محسوبة خارج الوحدة

1. المخزون: واجهة حجز/تحرير فوق عمود reserved_quantity القائم وغير المستخدم + أنواع حركة production_issue/production_receipt + إضافة حالة ProductionOrder لتعدادي أنواع المرجعية ReceiptReferenceType/IssueReferenceType (كلاهما تعداد منضبط اليوم) + علم مخازن الأمانة.
2. المحاسبة: عمودا نوع ومدير مركز التكلفة + بذر حسابات WIP والمحمَّل والانحرافات + طريقة إهلاك بالاستخدام UnitsOfProduction لقيود إهلاك العُدد (سجل الأصول الثابتة والموازنات موجودان ويُعاد استخدامهما كما هما).
3. المشتريات: استخلاص CreatePurchaseRequest كـ Action قابل للنداء من MRP.
4. المبيعات: عمود promised_date فقط (اسم قانوني وحيد — قرار D-16).
5. QMS وCMMS: قيد مفتاح production_order_id وعمود operation_no في QMS؛ مغذّي قراءات عداد الدورات في CMMS + مدخل قراءة فقط GetDowntimeWindows لخصم الأعطال من طاقة CRP بلا قراءة جداول مباشرة.
6. الموارد البشرية: Action جديد بملكية HRM RecordPieceworkEntry + جدول ترحيلي تملكه HRM لأجر القطعة (المرحلة 6)؛ حقول معدل الأجر مؤجلة — الإصدار الأول يعتمد معدلات مركز العمل.

واجهة Angular — توسعة features/production

تبقى المجموعة على المسار production بنفس حارسي moduleGuard/permissionGuard، وتضاف مجلدات: routings, tools, planning/{mps,mrp,crp}, execution/{issues,confirmations,receipts}, shop-floor (محطة لمسية مستنسخة من نمط pos-layout مع لوحة مشرف حية) وcosting للانحرافات وتحليل باريتو — بإعادة استخدام مكونات data-table/form-dialog/print المشتركة ومفاتيح ترجمة إنجليزية أولاً.

المنهجية: وما الذي فحصناه واستبعدناه لأنه موجود فعلاً

قبل إعلان أي فجوة تحققنا منها في الكود الفعلي. عدة مرشّحين ثبت أنهم ليسوا فجوات لأن البنية موجودة ومجرّبة، وهذا بحد ذاته خبر إيجابي للإدارة:

• محرك تحويل وحدات القياس موجود وقوي: unit_groups وunits بمعامل تحويل دقيق، وتحويلات لكل منتج في product_units — لا حاجة لبناء جديد، فقط سياسة استخدام (انظر B1).
• مراكز التكلفة على القيود موجودة: جدول cost_centers هرمي، والبعد التحليلي journal_entry_lines.cost_center_id مفعّل في التقارير، مع خدمة توزيع CostAllocationService جاهزة.
• قضبان الحوكمة موروثة مجاناً: ترقيم المستندات SequenceService، عزل الشركات BaseModel/TenantAware، نطاق الفروع DataScope، سجل الصلاحيات PermissionDependencyRegistry، والمرفقات والتدقيق — كلها مثبتة بوحدة المختبرات.
• طبقة الجودة لا تُبنى من جديد: وحدة QMS القائمة تغطيها — جدولا qms_inspection_plans وqms_inspections يحملان أصلاً عمود production_order_id بانتظار وحدة التصنيع، أما عدم المطابقة qms_non_conformances فترتبط عبر inspection_id فقط.
• موازنات مراكز التكلفة موجودة (تدقيق كود): جدولا budgets وbudget_lines في المحاسبة يحملان موازنة شهرية m1–m12 لكل حساب ومركز تكلفة — تُعاد كما هي لتغذية انحراف FOVV؛ الناقص الوحيد حجم الإنتاج الموازني (A25).
• سجل الأصول الثابتة موجود (تدقيق كود): fixed_assets مع فئات وقيود إهلاك وخدمة كاملة — يبقى فقط إضافة طريقة إهلاك بالاستخدام لإهلاك القوالب (A26).
• وعود التسليم ATP/CTP ليست فجوة في الوثيقة: الملف الثاني يحددها بالكامل؛ الفجوة في جانب Moon فقط (حقل استقبال التاريخ الموعود في المبيعات — A14).

الاتجاه A — ما ينقص Moon ERP: الفجوات الحرجة الاثنتا عشرة

القاسم المشترك في الفجوات الحرجة: وحدة الإنتاج الحالية هيكل عظمي نظيف لكنه معزول مالياً ومخزنياً — لا يرحّل قيداً واحداً ولا يحرّك صنفاً واحداً.

الاتجاه A — الفجوات المهمة والتحسينية

الاتجاه B — ما أغفلته الوثيقة نفسها: نقد خبير قبل التنفيذ

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

جدول المخاطر الموحّد (الفجوات الحرجة والمهمة)

ترتيب تنفيذي مقترح: الفجوات الحرجة في الاتجاه A هي مسار البناء نفسه، أما فجوات الاتجاه B الحرجة والمهمة فيجب حسمها كملاحق مكتوبة قبل بدء خطوات البناء الاثنتي عشرة — كلفة حسمها اليوم صفحات، وكلفة تجاهلها إعادة بناء طبقتي التنفيذ والتكاليف.

الخلاصة للإدارة: لا توجد فجوة واحدة تستدعي تعديلاً جوهرياً في وحدات المحاسبة أو المخزون أو المشتريات — القضبان موجودة ومجرّبة، والعمل الحرج كله «أسلاك ربط» تُبنى داخل وحدة التصنيع نفسها. أما الوثيقة فتُعتمد كما هي بشرط إلحاق الملاحق القصيرة التي تحسم الحواف التشغيلية (الإسناد الخارجي، إعادة التشغيل، المرتجعات، العكوس، التقويم، التتبع، السماحيات) قبل اليوم الأول من التنفيذ — وقد جُدولت كتابتها الآن في مسار ملاحق المرحلة 0 بخارطة الطريق (المالك: مهندس المنتج + خبير المصنع، مدة أسبوع، بوابة إلزامية قبل خروج المرحلة 1).

القاعدتان الحاكمتان

• للأمام = استدعاء متزامن: عندما يحتاج التصنيع شيئاً من وحدة أخرى يستدعي Action معتمداً لديها داخل نفس المعاملة — لا اتصال HTTP ولا كتابة مباشرة في جداول الغير.
• للخلف = حدث نطاقي: لا تستورد أي وحدة قائمة كود التصنيع إطلاقاً؛ كل ردود الفعل تُنفَّذ كمستمعين داخل وحدة التصنيع نفسها يستدعون Actions الوحدات المستهدفة، فيبقى اتجاه الاعتماد دائماً خارجاً من التصنيع.

مصفوفة التفاعل مع كل موديول

عقود الأحداث المسماة

المداخل المسماة التي يستدعيها التصنيع

خريطة الترحيل المحاسبي لدورة التكلفة

1. صرف المواد: مدين WIP / دائن مخزون الخام — بالكمية × تكلفة الصرف الفعلية — نوع production_material_issue.
2. الأجور المباشرة عند التأكيد: مدين WIP / دائن أجور مُحمَّلة — بالساعات × المعدل أو الكمية × أجر القطعة — نوع production_labor.
3. الأعباء الصناعية عند التأكيد: مدين WIP / دائن أعباء مُحمَّلة — بمُسبّب التكلفة × معدل التحميل (كلاهما على مركز العمل: عمود cost_driver الجديد × overhead_rate القائم) — نوع production_overhead؛ ومفاتيح الحسابات كلها في فضاء production.* الواحد الذي تبذره المرحلة 0 نفسها.
4. الخردة غير الطبيعية: مدين مصروف خردة / دائن WIP — نوع production_scrap.
5. استلام التام بالمعياري مع توزيع القيمة على الدرجات (A/B/C): مدين مخزون التام / دائن WIP — نوع production_receipt.
6. التسوية عند الإقفال: الرصيد المتبقي في WIP يُحلَّل إلى الانحرافات السبعة (سعر واستخدام المواد ← المشتريات/الإنتاج، معدل وكفاءة العمالة ← الإنتاج، إنفاق وكفاءة الأعباء ← الإدارة، حجم الأعباء الثابتة ← المبيعات/الإدارة) ضمن حدود تفاوت: أقل من 2% طبيعي، 2–5% مراقبة، أكثر من 5% تحقيق — نوع production_variance.
7. نهاية الشهر: مطابقة الأعباء المُحمَّلة مع الفعلية بعد توزيع مراكز الخدمة، وترحيل الفرق لقائمة الدخل قبل إغلاق الفترة المالية.

في أوامر التشغيل لحساب الغير (Toll) لا يُقيَّد أي عنصر مواد — مواد العميل أمانة بلا قيمة دفترية، وWIP يحمل تكلفة التحويل فقط، والإيراد فاتورة أجر تشغيل عبر المبيعات تمر للفوترة الإلكترونية كالمعتاد.

قانون الاعتماد

• التصنيع يستورد للأمام ثماني وحدات؛ ولا تستورد أي وحدة التصنيع أبداً — كل ردود الفعل مستمعون داخل التصنيع يستدعون مداخل الوحدات الأخرى.
• مفاتيح الربط الخارجية تعيش على جانب التصنيع فقط: mfg_peggings.sales_order_id، mfg_tools.cmms_asset_id/fixed_asset_id، production_centers.cost_center_id؛ ولا تقرأ أي وحدة أجنبية جدول mfg_* (تغذية الرواتب تُدفع إلى جدول تملكه HRM).
• الأستاذ العام حصراً عبر CreateJournalEntry، والمخزون حصراً عبر StockService وإجراءاته، والترقيم حصراً عبر SequenceService.
• الأحداث تُطلق بعد نجاح المعاملة، والمستمعون قابلون لإعادة التنفيذ دون تكرار أثر.

لماذا نخالف ترتيب المواصفة في ثلاث نقاط؟

المواصفة تضع «التكاملات» في الخطوة الأخيرة (12) وتبني التخطيط (MPS/MRP/CRP) قبل التنفيذ. قرارنا المدروس عكس ذلك في ثلاث نقاط، التزاماً بقاعدة المواصفة نفسها «كل حدث فعلي يُرحّل قيداً محاسبياً لحظياً» وبوصفة Moon ERP المجرَّبة:

• قلب 1 التكاملات تُنسَج داخل كل مرحلة منذ اليوم الأول (قيود عبر Modules\Accounting\Actions\CreateJournalEntry وحركات مخزون عبر ApproveIssue/ApproveReceipt) — لأن أكبر فجوة في الموديول الحالي هي بالضبط غياب الترحيل للمخزون والمحاسبة.
• قلب 2 التنفيذ الفعلي (أوامر تشغيل بصرف واستلام حقيقيين) يسبق التخطيط: المصنع يستطيع العمل بأوامر يدوية مربحة دون MRP، لكن MRP لا يعمل أبداً دون أرصدة مخزون موثوقة وقوائم مكونات صحيحة.
• قلب 3 تأجيل MPS الكامل (استهلاك التنبؤات والأسوار الزمنية) لعدم وجود مصدر تنبؤات في النظام؛ نبدأ MRP من أوامر البيع المؤكدة sales_orders ونقاط إعادة الطلب.

وقرار الاتجاه المعتمد: التوسعة في المكان — نمدّ موديول Modules/Production القائم ولا نعيد بناءه؛ لا توجد بيانات إنتاجية ولا مفاتيح خارجية واردة، والواجهة الأمامية وخريطة الـ19 صلاحية جاهزتان. التقدير: S ≈ أسبوع مطوّر، M ≈ 2–4 أسابيع، L ≈ 4–8 أسابيع — وهذا مقياس للمراحل ويختلف عن مقياس الفجوات المفردة في قسم الفجوات (S = أيام / M ≤ 3 أسابيع / L > 3 أسابيع)؛ لا يُسقط أحدهما على الآخر عند وضع الميزانية.

المراحل ومخرجاتها التشغيلية

مراحل مستقبلية محجوزة الواجهات وخارج هذه الخطة: الجدولة التفصيلية APS، حساب OEE، أوامر التغيير الهندسي PLM/ECO، والتقاط بيانات الآلات (IoT).

إصلاحات الفجوات المسبقة لكل مرحلة (من الاتجاه المعتمد)

• قبل المرحلة 1: بناء حجز المخزون StockService::reserve()/release() على عمود reserved_quantity اليتيم، وأنواع حركة إنتاجية في MovementType مع إضافة حالة ProductionOrder لتعدادي أنواع المرجعية (صرف واستلام)، وتأسيس حسابات WIP/FG ومفاتيح إعدادات production.*_account_id عبر AutoAccountService (نفس الفضاء المبذور في المرحلة 0)، وربط production_centers بمراكز التكلفة.
• قبل المرحلة 2: مصدر أجر العامل هو معدل مركز العمل labor_cost_rate (قرار D-06 — حقول HRM مؤجلة كتجاوز اختياري بعد الإصدار الأول، بلا تعديل مخطط في HRM)، وجدول قراءات عدادات cmms_asset_meters لتراكم دورات القوالب، وإضافة طريقة الإهلاك بالاستخدام UnitsOfProduction في المحاسبة (سجل الأصول الثابتة موجود ومتحقق منه).
• قبل المرحلة 3: عمود type على cost_centers (إنتاجي/خدمي/مساعد)، وتأسيس حسابات الانحرافات السبعة، ومدخلا FOVV: إعادة استخدام موازنات budget_lines القائمة + عمود حجم موازني على مركز العمل (لا هجرة Enum على products — طريقة التكلفة تسكن جدول الامتداد D-20).
• قبل المرحلة 4: استخراج Purchases\Actions\CreatePurchaseRequest (إنشاء طلبات الشراء اليوم حبيس الـController)، وعمود promised_date على sales_orders بالاسم القانوني الوحيد (D-16) مع Action الكتابة SetPromisedDate، وبناء كيان تقويم العمل والورديات (فجوة لم تحلّها المواصفة أصلاً).
• قبل المرحلة 6: ترقية الدفعات إلى كيان أول الدرجة في المخزون (اليوم batch_number نص حر)، وإضافة operation_no ومفاتيح خارجية حقيقية لجداول QMS.

استراتيجية ترحيل البيانات والتأسيس (الجداول السبعة القائمة)

1. الإبقاء على الجداول السبعة دون إعادة تسمية: لا بيانات إنتاجية ولا مفاتيح خارجية واردة — مخاطر الترحيل شبه معدومة؛ الجداول الجديدة فقط تأخذ بادئة mfg_.
2. إيقاف النمط الدفاعي: هجرة تحقق واحدة تثبّت الشكل النهائي للجداول السبعة، وكل تغيير لاحق إضافي (ALTER) — لا تكرار لنمط force_create.
3. هجرة تحويل الحالات: draft→planned، confirmed→released، in_progress→in_process مع تحديث Angular في الإصدار نفسه.
4. تحويل bom_operations إلى توجيه مُصدَّر في المرحلة 2 (توليد mfg_routing_header لكل BOM له عمليات)، ثم إيقاف الجدول القديم بعد إصدار انتقالي.
5. التأسيس (Seeders): بذر مفاتيح الإعدادات والحسابات المحاسبية والصلاحيات لكل مرحلة، وحزمة بيانات تجريبية «مصنع الميلامين» (خامة مسحوق، قالب 1 و4 تجاويف، درجات A/B/C) تُستخدم للعرض ولاختبارات الذهب معاً.

استراتيجية الاختبار (بوابة خروج لكل مرحلة)

اختبارات Pest وفق نمط النظام مع حد أدنى 80% تغطية قبل اعتماد أي مرحلة: المرحلة 1 تُثبت توازن كل قيد محاسبي وخصم المخزون وثبات اللقطة المجمّدة بعد الإطلاق؛ المرحلة 2 اختبارات وحدات خالصة لرياضيات التجاويف وتخصيص NRV؛ المرحلة 3 اختبار خاصية أن مجموع الانحرافات السبعة يساوي متبقي WIP حتى القرش؛ المرحلة 4 ملفات ذهبية لسيناريو الميلامين (6000 طبق، عبء 148% يُحل بقالب 4 تجاويف إلى 33 ساعة)؛ المرحلتان 5 و6 اختبارات تزامن الطرفيات وتتبّع النسب وعدم تقييم مخزون الأمانة.

قرارات مطلوبة من الإدارة

الخلاصة التنفيذية للمسار

ست مراحل بأحجام S, L, L, M, L, M, L: المصنع يعمل فعلياً (مخزون وقيود حقيقية على أوامر يدوية) بنهاية المرحلة 1، وكل مرحلة لاحقة تضيف قدرة مكتملة بذاتها — تكلفة التحويل، ثم الانحرافات السبعة، ثم MRP/CRP، ثم شاشات الورش اللحظية، ثم التشغيل لحساب الغير والتتبع — دون أي إعادة عمل، لأن التكامل مع المخزون والمحاسبة مبنيّ من الأساس داخل كل مرحلة لا مؤجَّلاً إلى الخطوة الأخيرة كما اقترحت المواصفة.

نظرة عامة على النضج والاستخدام

الموديول قائم على نفس بنية باقي الموديولات (BaseModel مع company_id، فصل الفروع، وترقيم المستندات عبر SequenceService)، وله واجهة Angular كاملة وصلاحيات مُسجَّلة في Core. لكنه غير مُفعَّل فعلياً في الإنتاج: لا يوجد بيانات أولية (Seeder فارغ)، ولا اختبارات، ولا أي موديول آخر يشير إليه.

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

ملاحظة: ترحيل الجداول مكتوب بأسلوب دفاعي عبر ثلاث هجرات (2026_03_31_000001_create_production_tables ثم ...000002_ensure... ثم ...000003_force_create...) كلها بشرط if (! Schema::hasTable(...))، وهو ما يدل على مشاكل سابقة في تطبيق الهجرات (استنتاج).

دورة حياة أمر التشغيل المُطبَّقة

1. draft — إنشاء الأمر وترقيمه عبر SequenceService('production','order')، وتعبئة المواد/العمليات تلقائياً من الـBOM إن وُجد.
2. confirmed — عبر confirm (يُسمح فقط من draft).
3. in_progress — عبر start؛ يسجّل actual_start_date.
4. أثناء التشغيل: consume (تسجيل استهلاك المواد) وrecord-output (تسجيل الكمية المنتجة والهالك).
5. completed — عبر complete؛ يحسب التكاليف الفعلية من المواد والعمليات.
6. cancelled — عبر cancel (من draft أو confirmed فقط).

ما الذي يرحّله فعلياً للمخزون والمحاسبة؟

• لا يوجد أي ترحيل للمخزون: consume وrecord-output يحدّثان أعمدة الكمية داخل جداول الإنتاج فقط ولا يُنشئان أي حركة مخزون (StockMovement) ولا يخصمان/يضيفان رصيداً في Inventory.
• لا يوجد أي قيد محاسبي: لا استدعاء لـModules\Accounting\Actions\CreateJournalEntry؛ التكلفة تُحسب وتُعرض دفترياً فقط (حقول actual_material_cost / actual_labor_cost وتقرير costing).
• عمود account_id في production_centers معرّف لكنه غير مستخدم في أي ترحيل (استنتاج).

التكامل والصلاحيات

• الصلاحيات الـ19 مُسجَّلة فعلاً في Modules\Core\database\seeders\RolePermissionSeeder.php (الأسطر 709–727) ومُطبَّقة كـMiddleware في الـControllers، ومتطابقة تماماً مع حُرّاس Angular.
• واجهة Angular كاملة تحت src/app/features/production (centers, boms, orders, reports) مع خدمات وموديلات في core/services وcore/models وعناصر تنقّل في nav-items.config.ts.
• غياب أي Events/Listeners/Actions/Services؛ EventServiceProvider فارغ، ولا يوجد مجلد Actions للتكامل العابر للموديولات حسب «وصفة» النظام.
• لا يشير أي موديول آخر إلى جداول أو نماذج الإنتاج (لا مفاتيح خارجية واردة من خارج الموديول).

تغطية مفاهيم المواصفة (Spec Coverage)

التوصية

الموديول الحالي نواة هيكلية نظيفة ومتوافقة مع «وصفة» النظام لكنها سطحية وظيفياً وغير مستخدمة في الإنتاج (لا بيانات، لا اختبارات، لا مراجع خارجية). التوصية: التوسعة في مكانه (Extend in place) بالبناء فوق الجداول والصلاحيات والواجهة القائمة — لا إعادة بناء كاملة — مع إضافة الطبقات الناقصة (ترحيل المخزون، القيود المحاسبية عبر CreateJournalEntry، الأحداث/المستمعين، طبقة الإصدارات، MRP، والعدد/القوالب). مخاطر الترحيل شبه معدومة لعدم وجود بيانات أو ارتباطات قائمة (استنتاج).

سيِّد الأصناف ووحدات القياس (Item Master & UoM)

سيِّد المنتجات مملوك لوحدة Modules\Core ومشترَك بين كل الوحدات؛ المخزون والمشتريات يشيران إليه بمفتاح خارجي فقط. البنية الأساسية لوحدات القياس والتحويلات قوية وجاهزة لإعادة الاستخدام في قوائم المكوّنات (BOM) ومسارات التصنيع.

• جدول المنتجات products يحوي حقول إعادة الطلب جاهزة: min_stock_level وmax_stock_level وreorder_point، إضافةً إلى track_inventory ووحدة الأساس base_unit_id.
• المتغيّرات مدعومة عبر product_variants وعلَم has_variants.
• وحدات القياس هرمية: unit_groups ثم units بمعامل تحويل conversion_factor، مع تحويلات على مستوى المنتج في product_units.
• فجوة تصنيف الأصناف ناقص: ProductType لا يحوي سوى Product وService — لا يوجد تمييز مادة خام / تحت التشغيل (WIP) / منتج نهائي، ولا procurement_type (تصنيع مقابل شراء)، ولا material_ownership (ملكيتنا مقابل أمانة العميل). استنتاج

التتبّع بالدُفعة والتسلسل (Batch / Lot / Serial)

التتبّع بالرقم التسلسلي (Serial) مكتمل ومُدار بجدول product_serials مع دورة حياة مُلزَمة عند الاستلام والصرف. أمّا التتبّع بالدُفعة (Batch/Lot) فهو ناقص جوهرياً: لا يوجد جدول رئيسي للدُفعات ولا أرصدة على مستوى الدُفعة؛ batch_number وexpiry_date مجرّد حقول نصّية على بنود الاستلام/الصرف. أرصدة المخزون وطبقات التكلفة مفهرسة بـ(منتج/متغيّر/مستودع) فقط دون الدُفعة.

فجوة التصنيع يحتاج نَسَب الدُفعات (أي دُفعات المواد الخام دخلت في أي دُفعة منتج نهائي) والصرف وفق الأقرب انتهاءً (FEFO) — وهذا غير ممكن في النموذج الحالي ويتطلّب جدول أرصدة دُفعات وخدمة مخزون واعية بالدُفعة. استنتاج

خدمة المخزون المركزية (StockService)

كل حركات المخزون تمرّ عبر Modules\Inventory\Services\StockService. تدعم الخدمة طريقتَي تقييم: الوارد أولاً صادر أولاً (FIFO) عبر طبقات التكلفة، والمتوسّط المرجّح (WAC) عبر الرصيد. الطريقة تُضبَط على مستوى الشركة بإعداد inventory.valuation_method (الافتراضي weighted_avg).

• increaseStock() يزيد الكمية ويُحدِّث المتوسّط ويُنشئ دائماً طبقة تكلفة inventory_cost_layers وحركة في inventory_movements.
• decreaseStock() يستهلك أقدم الطبقات في وضع FIFO أو يستخدم متوسّط التكلفة في وضع WAC.
• getIssueCost() يحسب تكلفة الصرف للمعاينة دون استهلاك، وgetProductCost() يُرجِع التكلفة الجارية.
• فجوة الحجز غير مُفعَّل برمجياً: عمود reserved_quantity موجود وكذلك خاصية available_quantity (الكمية المتاحة = الكمية − المحجوزة)، لكن لا توجد أي دالّة تكتب قيمة الحجز. على التصنيع بناء منطق الحجز والإفراج بنفسه. استنتاج
• فجوة أنواع الحركات في MovementType لا تشمل حركات إنتاجية (صرف إنتاج / استلام إنتاج / هالك / إعادة تشغيل).
• فجوة لا يوجد تكلفة معيارية (Standard Cost) ولا حسابات انحرافات؛ حقل cost_method على المنتج لا تقرؤه الخدمة.

تدفّق الاستلام والشراء (GRN & Receipt Flow)

النمط المرجعي الذي يجب أن يحاكيه التصنيع لاستلام المنتجات النهائية موجود في PurchaseGrnController::approve(): يُنشئ مستند استلام InventoryReceipt بحالة مسوّدة ثم يستدعي ApproveReceipt::execute() الذي يزيد المخزون فعلياً ويُنشئ طبقة التكلفة. أوضاع الاستلام (purchases.grn_mode): مباشر، أو باستلام، أو باستلام مع فحص جودة.

1. توليد رقم المستند عبر SequenceService::generateNext($company,'inventory','receipt').
2. إنشاء InventoryReceipt بحالة Draft وبنوده مع تمرير batch_number وexpiry_date وserial_numbers.
3. استدعاء app(ApproveReceipt::class)->execute($receipt, $userId) لزيادة المخزون.
4. تحديث كميات الاستلام على أمر الشراء وإعادة احتساب حالته.

طلب الشراء ← أمر الشراء (مدخل MRP)

سيُنشئ تخطيط الاحتياجات (MRP) طلبات شراء آلياً. الطلب موجود في purchase_requests (مع needed_by وpriority وcost_center_id وconverted_to_order_id)، ويتحوّل إلى أمر شراء عبر مسار convertFromRequest الذي يَسِم الطلب بحالة Converted. حدود إعادة الطلب مخزّنة على المنتج، لكن وحدة التنبيهات ReorderAlertController تنبيهية فقط ولا تُنشئ طلبات شراء آلياً.

فجوة إنشاء طلب الشراء يقع اليوم داخل المتحكّم فقط؛ يُنصَح باستخراج إجراء Purchases\Actions\CreatePurchaseRequest ليستدعيه MRP داخلياً دون المرور عبر واجهة HTTP. استنتاج

الترحيل المحاسبي وتكلفة البضاعة المباعة (GL & COGS)

نقطة جوهرية: وحدة المخزون لا تُرحِّل أي قيود محاسبية — حركة المخزون منفصلة عن الترحيل المحاسبي. الوحدة المستهلِكة هي من تكتب القيد دائماً عبر البوّابة الوحيدة Modules\Accounting\Actions\CreateJournalEntry:

• المشتريات: PostPurchaseBill يُرحِّل مدين المخزون / دائن الموردين.
• المبيعات: PostSalesInvoice::handleCogsAndStock يحسب التكلفة عبر StockService ثم يُرحِّل مدين تكلفة البضاعة المباعة / دائن المخزون ويستدعي decreaseStock وينشئ InventoryIssue.
• الأثر على التصنيع: عليه أن يكتب بنفسه قيود تحت التشغيل (WIP) والتكاليف المُحمَّلة والانحرافات محاكياً نفس الوصفة.

الاستدعاءات البرمجية الدقيقة لوحدة التصنيع

ملخّص الفجوات الجوهرية للمجلس

• لا يوجد سيِّد دُفعات ولا أرصدة على مستوى الدُفعة (التسلسل فقط مكتمل).
• منطق الحجز غائب رغم وجود عمود reserved_quantity.
• لا تصنيف أصناف تصنيعي (خام/تحت التشغيل/نهائي) ولا ملكية أمانة (Consignment).
• لا تكلفة معيارية ولا انحرافات؛ لا أنواع حركات إنتاجية.
• المخزون لا يُرحِّل محاسبياً — التصنيع يكتب قيوده بنفسه عبر CreateJournalEntry.
• لا إجراء برمجي لإنشاء طلب الشراء؛ إعادة الطلب تنبيهية فقط؛ لا نموذج مواقع فرعية.

القناة الوحيدة المعتمدة للترحيل المحاسبي

أي ترحيل إلى دفتر الأستاذ العام يمر حصراً عبر إجراء واحد معتمد هو Modules\Accounting\Actions\CreateJournalEntry بدالة execute(array $data, array $lines). هذه القناة تضمن التوازن، ومنع الترحيل على الحسابات الرئيسية (الإجمالية)، والتحقق من وجود فترة مالية مفتوحة، وتحويل العملات تلقائياً. وحدة المختبرات Modules\LIS\Actions\PostLabInvoice تستخدم هذه القناة فعلياً لترحيل تكلفة المبيعات موزّعةً على مراكز التكلفة — وهو نفس الأسلوب الذي ستتبعه وحدة التصنيع بحذافيره.

• كل سطر قيد يحمل بُعد cost_center_id — وهو البُعد التحليلي الذي يلتقط تكلفة كل مركز إنتاجي (ضغط، تجميع، تشطيب).
• كل قيد يحمل source_type وsource_id لربطه بالمستند المصدر (سيكون production_order هنا).
• الترحيل التلقائي مُفعّل افتراضياً عبر إعداد accounting.auto_post_entries؛ وأي فشل يُبقي القيد كمسودة آمنة دون إيقاف العملية التشغيلية.
• ربط الحسابات يتم بالإعدادات لا بالكود الصلب، عبر SettingsService مع سلاسل احتياطية.

مراكز التكلفة موجودة بالفعل

خلافاً لما قد يُفترض، مراكز التكلفة كيان قائم وكامل في وحدة الحسابات عبر جدول cost_centers ونموذج Modules\Accounting\Models\CostCenter بهيكل هرمي (أب/أبناء). كما أن توزيع تكاليف مراكز الخدمة على مراكز الإنتاج مبني فعلاً عبر CostAllocationService وAllocationRule. وتقارير الأستاذ العام GeneralLedgerService تدعم الترشيح حسب مركز التكلفة. لذلك مراكز التكلفة ليست بناءً جديداً — الناقص فقط هو تصنيف نوع المركز (إنتاجي/خدمي/مساعد) وبعض طرق التوزيع المتقدمة.

كيف تُرحَّل دورة الإنتاج تحت التشغيل ← الانحرافات ← التسوية

1. صرف المواد للأمر: مدين WIP (إنتاج تحت التشغيل) / دائن مخزون المواد الخام — بنوع production_material_issue.
2. العمالة المباشرة: مدين WIP / دائن أجور مُحمَّلة — بنوع production_labor.
3. الأعباء الصناعية غير المباشرة: مدين WIP / دائن أعباء مُحمَّلة (MOH Applied) — بنوع production_overhead (معدل التحميل موجود في production_centers.overhead_rate).
4. استلام المنتج التام بالتكلفة المعيارية: مدين مخزون التام / دائن WIP — بنوع production_receipt.
5. التسوية: الرصيد المتبقي في WIP = إجمالي الانحراف؛ يُحلَّل إلى الانحرافات السبعة (سعر/استخدام المواد، معدل/كفاءة العمالة، إنفاق/كفاءة الأعباء، حجم الأعباء الثابتة) ويُرحَّل لحسابات الانحراف في قائمة الدخل مع تصفير الأمر — بنوع production_variance.

كل ما سبق يُرحَّل عبر CreateJournalEntry دون أي تعديل على مخطط الحسابات؛ حسابات الإنتاج تحت التشغيل والانحرافات هي حسابات تفصيلية تُهيّأ ببيانات أولية، ومركز التكلفة هو البُعد القائم على السطر. استنتاج: تسلسل القيود

القضبان المتوفّرة من النواة (Core)

الفجوات التي تتطلّب بناءً جديداً

• لا يوجد أي ترحيل محاسبي من وحدة Production حالياً (صفر استدعاءات لـCreateJournalEntry)، كما أن وحدة المخزون لا تُرحِّل للأستاذ — وهذه أكبر فجوة وتُبنى بالكامل داخل وحدة التصنيع. فجوة كبرى
• جدول مراكز التكلفة بلا عمود type (إنتاجي/خدمي/مساعد) المطلوب في المواصفة. استنتاج
• نموذج المنتج Products يحوي cost_method كنص حر فقط، دون مُعدّد طرق التكلفة (Standard/Actual/Average/FIFO) ودون التكلفة المعيارية المُفصّلة. فجوة
• مُعدّد ApprovalModule يقتصر على المبيعات والمشتريات؛ يلزم إضافة حالة Production. فجوة
• لا توجد مفاتيح إعدادات ولا حسابات مزروعة لـWIP والأعباء المُحمَّلة والانحرافات؛ تُضاف عبر SettingDefinition وAutoAccountService. استنتاج
• محرّك الانحرافات السبعة (مع حدود التفاوت وتقرير باريتو وتوجيه المسؤولية) منطق خالص جديد داخل وحدة التصنيع.

1. المبيعات: مصدر الطلب لخطة الإنتاج الرئيسية (Sales → MPS Demand)

يقرأ التصنيع الطلبات المؤكَّدة من جدول sales_orders وبنوده sales_order_items لتغذية خطة الإنتاج الرئيسية (MPS) عبر حقل confirmed_orders_qty، ولربط أوامر التشغيل بالطلب عبر جدول الربط Pegging (علاقة كثير-لكثير بين الطلب والإنتاج). جدول sales_orders يملك بالفعل expected_delivery_date وdelivery_status وstatus، وبند الطلب يتتبّع delivered_quantity وinvoiced_quantity.

• المنتج المطلوب يُعرَّف عبر product_id وproduct_variant_id في sales_order_items — وهو نفس مرجع products الذي يبني عليه التصنيع قائمة المكوّنات (BOM).
• تحويل عرض السعر إلى طلب مُتتبَّع عبر sales_quotations.sales_order_id وsales_orders.quotation_id.
• الفرع وسلسلة الشركة جاهزان (company_id, branch_id) لفصل النطاق (DataScope).

فجوة لا يوجد في sales_orders أي حقل «وعد التسليم المتاح» (ATP/CTP) ولا حقل رجوعي يحمل التاريخ المُتعهَّد به من التصنيع؛ الوعد بالتسليم القائم يدوي (expected_delivery_date) دون ربط بقدرة الإنتاج (استنتاج). يلزم خطّاف (Action) من التصنيع يكتب التاريخ المُتعهَّد ويُحدِّث delivery_status عند الربط (Pegging).

2. الموارد البشرية: العمالة وتسعير التأكيدات (HRM → Labor Costing)

تأكيدات العمليات (Confirmation) تُسجِّل ساعات/كميات العامل، ويجب تسعيرها من بيانات الموارد البشرية. جدول employees يربط الموظف بالمستخدم عبر user_id (سلسلة employees.user_id → users.id)، ويملك basic_salary فقط. الورديات في shifts (start_time, end_time, working_hours, is_night_shift) والحضور في attendances (worked_hours, overtime_hours).

فجوة جوهرية لا يوجد حقل «أجر بالساعة» (hourly_rate) ولا «أجر بالقطعة» (piece_rate) على مستوى الموظف؛ الأجر بالساعة مُشتَقّ حسابياً داخل PayrollService من basic_salary / salaryDays / hoursPerDay فقط. وبما أن مواصفات التصنيع تتطلب وضعين (labor_calc ∈ {Hourly, PieceRate})، يلزم مصدر معدّل صريح للتأكيدات، إما حقل جديد أو خدمة معدّلات في الموارد البشرية (استنتاج).

3. الجودة: الفحص أثناء التشغيل وعدم المطابقة على الهالك (QMS Replaces Spec-Internal Quality)

تنصّ المواصفة صراحةً (ملف 06 §6.5) على أن «إدارة الجودة» مرحلة لاحقة تتعلّق بتأكيدات الإنتاج (الدرجات/أكواد الأسباب وبوابات الفحص على العمليات) — وموديول الجودة القائم يغطّيها بالفعل، فلا حاجة لبناء جداول جودة داخل التصنيع. الأهم: جداول qms_inspection_plans وqms_inspections تحمل بالفعل عمود production_order_id، أي أنها صُمِّمت أصلاً للربط بأوامر التشغيل.

• أكواد أسباب الهالك (reason_code في تأكيد التصنيع) تُغذّي تحليل باريتو، وتُترجَم إلى qms_non_conformances عند تجاوز عتبة.
• بوابة الجودة على الاستلام (Goods_Receipt quality_status ∈ {Released, OnHold, Rejected}) تُحسَم عبر نتيجة qms_inspections.result.

فجوة لا يوجد عمود مفتاح أجنبي رسمي على qms_inspections.production_order_id (مجرّد unsignedBigInteger دون constrained) لأن جداول التصنيع لم تُنشأ بعد؛ كما تنقص رابطة operation_no لتثبيت الفحص على عملية بعينها (استنتاج).

4. الصيانة: مراكز العمل والقوالب كأصول (CMMS → Work Centers & Molds)

تنصّ المواصفة (§6.5) على أن الصيانة (PM) «تُقلِّل قدرة مركز العمل أثناء نوافذ التوقّف». موديول الصيانة يوفّر cmms_assets (مع specifications JSON وparent_asset_id) ليمثّل الآلة/القالب كأصل، وcmms_pm_schedules للصيانة الدورية، وcmms_work_orders لأوامر الصيانة بحقل downtime_hours وfailure_code ونوع WorkOrderType ∈ {Preventive, Corrective}.

• القالب/المول (Tool في المواصفة) يُسجَّل كـcmms_assets فئة قوالب؛ مركز العمل (Work_Center) أصل آلة.
• توقّف الإنتاج ↔ أمر صيانة: cmms_work_orders.downtime_hours + actual_start/end يخصمان القدرة المتاحة من CRP.
• تشغيل الصيانة بعدّاد عتبة: cmms_pm_schedules.meter_field + meter_threshold يدعمان «صيانة كل N ضربة» للقوالب.

فجوة لا يوجد جدول قراءات عدّاد (مثل cmms_asset_meters) يجمع عدد ضربات القالب التراكمي (cycles_used في المواصفة) ليُطلِق صيانة العتبة؛ الحقل meter_field نصّي فقط دون مصدر بيانات تراكمي. كما أن cmms_work_order_labor يربط بـuser_id لا بـemployee_id (استنتاج).

5. الواجهة الأمامية: تنظيم الموديول والحُرّاس والشاشة الطرفية (Frontend Conventions)

الواجهة Angular مستقلّة المكوّنات (Standalone) بمسارات كسولة. كل موديول مجموعة مسارات تحت حارس الموديول moduleGuard (يمنع تجاوز تعطيل الموديول)، وكل مسار فرعي تحت permissionGuard مع data.permissions ببادئة الموديول (مثل ['manufacturing.']). المكوّنات تُحمَّل عبر loadComponent الكسول.

1. ورشة التصنيع: تخطيط (manufacturing-layout) + لوحة + بيانات أساسية (BOM/Routing/Work Center/Tool).
2. شاشات التخطيط (MPS/MRP/CRP) والتنفيذ (أمر تشغيل، صرف مواد، تأكيد، استلام).
3. شاشة طرفية لمسية لأرضية المصنع: أهداف لمس كبيرة، أزرار [Start]/[Done]، طابور الأوامر الجاهزة، إدخال كمية/درجة/هالك — على نمط pos-layout.
4. لوحة إشراف حيّة (Real-time Dashboard) تعرض موضع كل أمر وكشف الاختناقات.

النطاق ودورة حياة الإنتاج

تغطي الوحدة دورة الإنتاج الكاملة: البيانات الأساسية ← التخطيط ← التنفيذ ← التكاليف، إضافة إلى طبقة التحكم بأرضية المصنع Shop Floor Control (SFC) للتتبع اللحظي. ما يلي خارج النطاق ويتم التكامل معه لا إعادة بنائه: دفتر الأستاذ العام، نواة المخزون والمستودعات، نواة المشتريات، أوامر المبيعات، الموارد البشرية والرواتب.

الطبقات المعمارية الأربع

تتدفق البيانات من الأعلى للأسفل، مع حلقة مغلقة: انحرافات التكاليف وتعارضات السعة في CRP تعود لتصحيح التخطيط.

المطلب الجوهري: العمومية (The Genericity Mandate)

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

القواعد التصميمية الشاملة (Cross-Cutting Rules)

تنطبق هذه القواعد على كل كيان وعملية في الوحدة:

• اللقطات المجمّدة (Frozen Snapshots): عند Release أمر الإنتاج يُؤخذ نسخة مجمّدة من الـ BOM والـ Routing النشطين؛ أي تغيير لاحق في البيانات الأساسية لا يؤثر على الأوامر المُصدَرة — حمايةً للتكلفة التاريخية ومسار التدقيق.
• الحالة كآلة حالات (State Machine): كل كيان معاملاتي (أمر، صرف، تأكيد، استلام) له حالة صريحة بانتقالات وشروط مسبقة وآثار جانبية محددة — لا تغييرات حالة عشوائية.
• علاقة كثير-لكثير بين الطلب والإمداد: أمر مبيعات قد ينقسم لعدة أوامر إنتاج، وأمر إنتاج قد يخدم عدة أوامر مبيعات؛ جدول Pegging يسجّل الروابط.
• التعدد المستوياتي في كل شيء: الـ BOM والأوامر والتكاليف تدعم تعشيشاً غير محدود (منتج تام ← تجميعة فرعية ← مكوّن ← مادة خام) عبر التكرار (recursion).
• الإعداد بدلاً من الكود: كل نقطة تباين هي حقل لا مسار برمجي.
• كل حدث فعلي يُولّد قيداً محاسبياً: صرف المواد والتأكيد واستلام البضاعة كلٌ يُنتج قيد GL؛ التكلفة منسوجة داخل التنفيذ لا خطوة دفعية لاحقة.
• تجريد الموارد: السعة تُستهلك عبر كائنات Resource بأنواع مختلفة؛ السعة الفعلية للعملية مقيّدة بـالحد الأدنى المتاح عبر كل الموارد المطلوبة.

آلتا الحالة المسمّاتان (State Machines)

حالة أمر الإنتاج order_status:

1. Planned — مُخطَّط
2. Released — مُصدَر (تؤخذ هنا اللقطة المجمّدة)
3. InProcess — قيد التنفيذ
4. Completed — مكتمل
5. Closed — مُغلق

حالة العملية operation_status:

1. Waiting — منتظر
2. Ready — جاهز
3. InProgress — قيد التشغيل
4. Completed — مكتمل

التعدادات الحاكمة (Key Enumerations)

حالة البناء المرجعية (Build Status)

ماذا يعني هذا لـ Moon ERP

• تكامل لا إعادة بناء: GL عبر Modules\Accounting\Actions\CreateJournalEntry فقط، والمخزون عبر وحدة Inventory، والمشتريات/المبيعات/الموارد البشرية عبر وحداتها القائمة — مطابق لمبدأ "خارج النطاق" في المواصفة.
• وحدة Production الحالية تملك بالفعل BillOfMaterials وBomComponent/Operation وProductionOrder وProductionCenter — أساس يُبنى عليه، لكنه يحتاج توسعة لتعدد التجاويف والمنتجات المشتركة وتجريد الموارد.
• التعدادات الـ ١١ تُنفَّذ كـ Enums داخل الوحدة وفق وصفة Moon ("enums per state machine")؛ وآلتا الحالة order_status/operation_status تُنفَّذان كآلات حالة بأحداث ومستمعين.
• "كل حدث فعلي يُولّد قيداً" يتطابق تماماً مع نمط Moon المُثبت (PostLabInvoice → CreateJournalEntry): صرف/تأكيد/استلام كل منها يستدعي قيداً مزامناً.
• اللقطات المجمّدة وترقيم المستندات تتكئان على SequenceService، وBaseModel/TenantAware يضمنان company_id ونطاق الفرع عبر DataScope — مطابق لوصفة الوحدات السريرية.
• خرائط الصلاحيات تُسجَّل في Core PermissionDependencyRegistry ببادئة mfg، تماماً كما تفعل LIS.
• المطلب الجوهري (الإعداد بدلاً من الكود) يحمي Moon من تفرّع الكود لكل عميل مصنع: كل سلوك خاص يصبح حقل إعداد بقيمة افتراضية شائعة.

الغرض والمبدأ الحاكم

تلتزم هذه الطبقة بـ«تفويض العمومية» (Genericity Mandate): لا يُكتب أي سلوك خاص بمصنع واحد كمسار برمجي مستقل، بل يُعبَّر عنه بحقل/قيمة تعداد (config) ينحاز افتراضيًا للسلوك الشائع ثم يتفرّع منه. مصنع الميلامين مذكور كحالة اختبار إجهاد فقط — وليس قالبًا يُبرمَج عليه.

• نسخة مجمّدة: عند إطلاق أمر الإنتاج تُلتقط نسخة من الـBOM والـRouting النشطين؛ أي تعديل لاحق لا يمسّ الأوامر المُطلَقة (حماية التكلفة التاريخية والتدقيق).
• الحالة كآلة حالات: كل كيان له status بانتقالات وشروط وآثار محددة، لا تغييرات عشوائية.
• تعدّد المستويات: الـBOM يدعم التداخل اللانهائي (منتج نهائي ← تجميعة فرعية ← مكوّن ← خام) عبر التكرار (recursion).
• تجريد الموارد: الطاقة تُستهلك بكائنات Resource من نوع { Machine, Tool, Labor }؛ طاقة العملية محكومة بـأدنى مورد متاح.

الكيان: قائمة المكوّنات (BOM — Bill of Materials)

هوية تصنيع المنتج: ما المكوّنات وكمياتها لإنتاج وحدة واحدة. يجب أن يدعم التداخل متعدد المستويات. يتكوّن من رأس (BOM_Header) وأسطر (BOM_Line).

رأس القائمة (BOM_Header)

سطر القائمة (BOM_Line)

• الكمية الأساسية افتراضها 1 (لكل قطعة)؛ التعبئة المشتركة (مثل كرتونة لكل طقم) تُعالَج على مستوى التجميعة الأب لا على كل قطعة.
• متعدد المستويات: قد يكون مكوّن السطر نفسه ذا BOM (تجميعة فرعية / نصف مصنّع)، والـMRP يفكّكه تكراريًا.
• المستهلكات الزهيدة (تكلفة مهملة يصعب قياسها لكل وحدة) لا تُدرَج كسطر، بل تُعامَل كتكلفة غير مباشرة (overhead) عبر علم أو حذف.
• القيمة Phantom في bom_type تمثّل تجميعة عابرة يُفكَّك من خلالها دون تخزينها — مذكورة دون تفصيل سلوكها هنا.

الكيان: المسار (Routing)

مسار التصنيع: تسلسل العمليات ومن ينفّذ كلًا منها وكم تستغرق — يتيح الجدولة وحساب الزمن. يتكوّن من رأس (Routing_Header) وعمليات (Routing_Operation).

رأس المسار (Routing_Header)

عملية المسار (Routing_Operation)

• المعادلة المحورية للقولبة/تعدد المخرجات: time_per_piece = cycle_time / cavity_count؛ والافتراضي cavity_count = 1 يعيدها للسلوك العادي للتصنيع المنفصل.
• queue_time وmove_time يؤثران في زمن التوريد لكن غالبًا لا يُحسبان في التكلفة.
• قد تتطلب العملية أداة بالإضافة لمركز العمل — ويجب توفّر الاثنين معًا للتشغيل (تقاطع موارد).

الكيان: مركز العمل (Work Center)

حيث يحدث العمل. هو الواجهة بين الإنتاج والمحاسبة — كل التكاليف تتدفّق من خلاله.

معادلة الطاقة الفعّالة: effective_capacity = daily_capacity × capacity_multiplier × efficiency% × utilization% — ويستخدم الـCRP الطاقة الفعّالة لا الإجمالية.

• قاعدة الفصل: ما يحدّد مركز عمل منفصل هو نوع العملية وتكلفتها لا عدد الآلات. آلات متطابقة بعمل وتكلفة متطابقة = مركز واحد بمضاعِف؛ عمل أو تكلفة مختلفة = مراكز منفصلة.

الكيان: الأداة / الإسطمبة (Tool / Mold)

في صناعات القولبة الإسطمبة هي قيد الطاقة لا الآلة. مُعمَّمة كـResource من نوع Tool. مصنع بلا قوالب ببساطة لا يملك موارد أدوات — فينهار التجريد بسلاسة.

• بدء التوفّر للموارد المتعددة: available_start = MAX(earliest free time across all required resources).
• الإهلاك بالاستخدام: تتآكل الأداة بالدورات لا بالتقويم؛ والمركّبة/العاملة فقط تتآكل. depreciation_per_piece = purchase_cost / life_cycles / cavity_count.

نقطة عامة: نمط حساب العمالة (labor_calc)

يحدّد حقل labor_calc على مركز العمل (أو الصنف) طريقة حساب تكلفة العمالة المباشرة:

• Hourly: cost = labor_hours × labor_rate
• PieceRate: cost = quantity × piece_rate (وقد يتغيّر معدل القطعة حسب المنتج/المقاس)

الأثر: تحت PieceRate يتحمّل العامل البطيء تكلفته (يكسب أقل) لا المصنع — فلا يوجد «انحراف كفاءة عمالة» تقليدي، وينتقل الانحراف إلى الآلة/التكلفة غير المباشرة. يجب أن يدعم النظام كلا النمطين.

آلات الحالات (State Machines)

حالة قائمة المكوّنات BOM_Header.status:

1. Draft
2. Active
3. Inactive
4. Obsolete

حالة المسار Routing_Header.status:

1. Draft
2. Active
3. Inactive

حالة الأداة Tool.status (والمركّبة فقط تتآكل):

1. Available
2. Mounted
3. Maintenance
4. Retired

نقاط التهيئة والتعدادات (Config Points)

ماذا يعني هذا لـ Moon ERP

• وحدة Production الحالية هيكل رفيع: جداول bill_of_materials وbom_components وbom_operations وproduction_centers تغطّي جزءًا فقط؛ المواصفة تتجاوزها بكثير وتتطلّب توسعة أو إعادة بناء وفق «وصفة الوحدات السريرية» (جداول مسبوقة، enums لكل آلة حالات، أحداث ومستمعون، Actions للاستدعاء عبر الوحدات).
• غياب في الـBOM الحالي: الإصدارات والصلاحية (effective_from/to، approved_by)، وbom_type، وissue_type/issue_level، وoperation_seq الرابط بين المكوّن والعملية، والبدائل، والتداخل متعدد المستويات (recursion).
• غياب في الـRouting: لا يوجد كيان مسار مستقل بإصدار وصلاحية ونوع، ولا حقول cavity_count/cycle_time/queue_time/move_time/critical_operation/required_skill_code — وهي مفصلية للقولبة والجدولة.
• غياب كيان الأداة/الإسطمبة تمامًا، وهو القيد الحقيقي للطاقة في صناعات القولبة، مع دورة حياته وإهلاكه بالاستخدام (life_cycles/cycles_used). مرشّح للتمثيل عبر resource_type أو ربطه بوحدة CMMS للأصول والصيانة.
• production_centers الحالي مبسّط (capacity_per_hour/cost_per_hour) ويفتقد capacity_multiplier، الكفاءة/الاستغلال، التقويم، فصل معدلات الإعداد/العمالة/الآلة، وlabor_calc، وbottleneck_flag — كلها مطلوبة للطاقة الفعّالة والتكلفة.
• الاعتماديات تُلبَّى من Core/المحاسبة: الأصناف والوحدات (Product/Unit)، مراكز التكلفة (Accounting)، الترقيم (SequenceService)، الاعتمادات (ApprovalWorkflowService — يحتاج توسعة تعداد لـECO)، والتقويم/المهارات من HRM؛ وكلها تتكامل عبر Actions لا إعادة بناء.
• «النسخة المجمّدة» عند إطلاق أمر الإنتاج تتطلّب التقاط الـBOM+Routing النشطَين كلقطة — نمط جديد على وحدة Production الحالية يجب إدخاله.

المخرجات الثلاثة للتخطيط

تنتج طبقة التخطيط ثلاث مخرجات فقط؛ يُنصح بالاحتفاظ بها كنموذج ذهني. المدخلات هي: طلب العميل، البيانات الرئيسية (شجرة المكوّنات BOM والمسار Routing ومراكز العمل)، المخزون الحالي، إعدادات الصنف، وملكية المادة.

المكوّن الأول: جدول الإنتاج الرئيسي (MPS)

يقرّر ماذا نُنتج وكم ومتى. في وضع الصنع حسب الطلب يتحوّل دوره من «متنبّئ» إلى «مترجِم للطلبات + فاحص قبول وطاقة». يتفرّع سلوكه حسب نوع الإنتاج production_type:

المعادلة الأساسية: الرصيد المتاح المتوقَّع (PAB)

المعادلة الجوهرية لكل فترة زمنية t:

• PAB[t] = PAB[t-1] + scheduled_production[t] - demand[t]
• قيمة demand[t] تُحسب وفق قواعد استهلاك التوقّع وحواجز الزمن أدناه.

استهلاك التوقّع (Forecast Consumption)

الطلبات الفعلية تستهلك التوقّع ولا تُضاف إليه — لمنع الحساب المزدوج:

• consumed = MIN(actual_orders[t], forecast[t])
• remaining_forecast = forecast[t] - consumed
• total_demand[t] = actual_orders[t] + remaining_forecast
• إذا تجاوزت الطلبات الفعلية التوقّع: total_demand[t] = actual_orders[t]

الإعدادات: forecast_consumption_method ∈ {None, Backward, Forward, Both} وconsumption_window.

حواجز الزمن (Time Fences)

تُحدَّد المنطقة بحسب بُعد الفترة عن اليوم، لمنع «عصبية النظام»: الخطة قريبة المدى مستقرّة وبعيدة المدى مرنة.

القدرة على الوعد (CTP — Capable to Promise)

جوهر الصنع حسب الطلب: وعد تسليم مبني على الطاقة لا على المخزون. يحسب الحِمل على كل مركز عمل عبر مسار الصنف، ويعتمد عنق الزجاجة (أعلى موعد ممكن) كموعد وعد:

1. لكل عملية في المسار: إن كان مركز العمل من نوع مكبس cycles = Q / cavity_count ثم load += cycles × cycle_time + setup_time، وإلا load += Q × run_time + setup_time.
2. لكل مركز عمل مطلوب: إيجاد أبكر فتحة earliest[wc] = find_earliest_slot(wc, load[wc]).
3. الموعد الموعود = MAX(earliest[wc]) (عنق الزجاجة يقرّر).
4. الإرجاع: «في الموعد» إن كان promised ≤ D، وإلا أبكر موعد ممكن.

تقسيم الطلبات وتجميعها (Many-to-Many)

• طلب كبير ← عدّة جداول تسليم (مثلاً شهرية).
• عدّة طلبات متشابهة ← أمر إنتاج واحد (لتقليل التجهيز وتبديل القوالب).
• تُسجَّل الروابط في جدول التعشيق Pegging: { production_order_id, sales_order_id, allocated_quantity } (يُعرَّف في الملف 06).

نموذج بيانات MPS وحساب ATP

المتاح للوعد ATP له ثلاثة أنماط (إعداد): Discrete (الإنتاج ناقص الطلبات حتى الإنتاج التالي)، Cumulative (مجاميع تراكمية)، وLook-ahead (الأكثر أمانًا).

المكوّن الثاني: تخطيط احتياجات المواد (MRP)

يحوّل أوامر الإنتاج إلى احتياجات مواد: ماذا نشتري/نصنع، وكم، ومتى. هو عملية وليس جدولاً، وينتج «أوامر مخطّطة» مؤقّتة. إعدادات الصنف:

خوارزمية MRP وتفجير شجرة المكوّنات

تُعالَج الأصناف مستوى بمستوى من الأعلى (التام = 0) إلى الأعمق (الخام):

1. Gross[t] = طلب MPS (للتام) + الطلب المعتمد من الآباء (للمكوّن).
2. Available[t] = on_hand + open_POs[t] + open_WOs[t] - reserved[t].
3. Net[t] = MAX(0, Gross[t] - Available[t] + safety_stock).
4. Order_Qty = apply_lot_sizing(Net[t], lot_rule).
5. Release_Date = Required_Date - lead_time.
6. إن كان procurement_type == Make: تفجير الـBOM لتوليد طلب معتمد للمكوّنات والتعشيق الأعمق تكراريًا.

تفجير الـBOM يطبّق الهدر لكل سطر: required = Q × line.quantity × (1 + line.scrap_pct)، ويتكرّر للمكوّنات من نوع Make.

قواعد تحجيم الدفعة (Lot Sizing)

الأصناف كثيفة العُدد تستخدم PeriodOrder/Fixed لتجميع الطلب وتقليل تركيب القوالب.

فرع التصنيع لدى الغير (Toll) ومخرجات MRP

• عند توليد شراء لمكوّن مملوك للعميل material_ownership == Customer: لا يُصدَر أمر شراء، بل يُتحقَّق من كفاية الكمية المورَّدة من العميل، وعند النقص يُطلق تنبيه.
• المخرجات: أوامر شراء مخطّطة ← وحدة المشتريات؛ أوامر إنتاج مخطّطة ← طبقة التنفيذ؛ رسائل استثناء («سيتأخّر»، «أعِد الجدولة للداخل/الخارج»، «ألغِ»).

المكوّن الثالث: تخطيط احتياجات الطاقة (CRP)

يفترض MRP طاقة لانهائية؛ يحقن CRP الواقع للتحقّق من توفّر طاقة مراكز العمل والعُدد والعمالة في الوقت المطلوب. في مصانع العُدد يكون CRP أهمّ من MRP (المواد سهلة؛ جدولة عدّة قوالب على عدّة مكابس هي المشكلة الحقيقية).

1. حساب الحِمل لكل أمر مخطّط وعملية (نفس صيغة المكبس/غير المكبس في CTP).
2. توزيع الأحمال على الفترات.
3. تجميع لكل مورد: Total_Load[resource, period] = Σ loads.
4. المقارنة: Util = Total_Load / effective_capacity × 100.
5. حلّ التحميل الزائد: إعادة جدولة / عمل إضافي / وردية إضافية / تأجيل أمر / استخدام قالب متعدّد التجاويف.

تقاطع الموارد: earliest_start = MAX(machine_free_time, tool_free_time, labor_free_time) — القيد المُلزِم هو المورد الأقل توفّرًا، والقالب مورد متنقّل يُتتبَّع عبر المكابس (resource_type ∈ {Machine, Tool, Labor}). يدعم النظام نمطين: RCCP (قطع خشن على MPS للموارد الحرجة، يستخدمه CTP لقبول الطلب) وCRP (تفصيلي على MRP لكل الموارد).

مثال الميلامين: مركز المكبس بطاقة 90 ساعة في الأسبوع 3، طلب 6000 طبق بقالب أحادي التجويف ودورة 80 ثانية = 133 ساعة، فالاستغلال 148% (تحميل زائد)؛ والحلّ المطروح استخدام قالب رباعي التجاويف = 33 ساعة فقط — ما يربط قرار جدولة (CRP) باختيار بيانات رئيسية (أيّ قالب).

الفجوة المعروفة: الجدولة التفصيلية (APS) والحلقة المغلقة

• CRP يكتشف التحميل الزائد لكنه لا يرتّب العمليات ساعة بساعة على آلات بعينها؛ مكوّن APS مستقبلي يتولّى التسلسل الزمني (Gantt) وتقليل عمليات تبديل القوالب واحترام التسخين وأنماط الورديات.
• واجهة APS: تستهلك الأوامر المخطّطة + المسار + تقاويم الموارد، وتُصدر جدولاً مرحليًا زمنيًا يُنفّذه SFC (الملف 05).
• الحلقة المغلقة: تعارض CRP يُغذّي MPS لتعديل promised_date وإعادة التشغيل؛ وانحرافات التكلفة (الملف 04) تُحدّث المعايير والتخطيط المستقبلي.

ماذا يعني هذا لـ Moon ERP

• وحدة Production الحالية تملك BillOfMaterials وBomComponent وBomOperation وProductionOrder وProductionCenter (يحوي capacity_per_hour)، لكن لا توجد طبقة تخطيط (لا MPS ولا MRP ولا CRP) — هذه الطبقة بناء جديد بالكامل وفق نفس وصفة الوحدات.
• كيانات جديدة مطلوبة بجداول مُسبَّقة: mfg_mps_headers وmfg_mps_lines وmfg_item_mrp_settings (امتداد على Core\Product على نمط AccBpExt) وmfg_planned_orders وmfg_pegging وmfg_crp_loads.
• التعدادات تُمثَّل كـ enums لكل آلة حالة: production_type وmrp_type وlot_sizing_rule وresource_type ومنطقة الزمن FROZEN/SLUSHY/LIQUID وحالة الاستغلال OVERLOAD/OK/UNDERLOAD.
• المدخلات تأتي عبر Actions من وحدات قائمة: الطلب من Modules\Sales\SalesOrder، المتاح من Modules\Inventory\StockBalance، التوريد المفتوح من Modules\Purchases\PurchaseOrder وProductionOrder؛ ومخرجات الشراء المخطّط تُحوَّل إلى PurchaseRequest مع تخطّي مكوّنات العميل.
• تنقص ERP اليوم: مصدر تنبؤ بالطلب (لا يوجد)، وتقويم/ورديات الموارد اللازم لـfind_earliest_slot وeffective_capacity، وجدول تعشيق Pegging، وخدمة تحويل وحدات القياس. يجب توفيرها قبل تشغيل MPS/CRP بدقّة.
• ترقيم المستندات عبر SequenceService، وحصر الفروع عبر DataScope، وخريطة الصلاحيات تُسجَّل في Core PermissionDependencyRegistry ببادئة mfg؛ وأيّ ترحيل تكلفة لاحق يمرّ حصرًا عبر Modules\Accounting\Actions\CreateJournalEntry.

التسلسل العام للطبقة

1. Production Order — أمر الإنتاج (العقد الداخلي المُصرِّح بالإنتاج)
2. Material Issue — صرف المواد من المخزون الخام إلى تحت التشغيل
3. Confirmation — تأكيد ما نُفِّذ فعلياً لكل عملية (كميات، عمالة، هالك)
4. Goods Receipt — استلام المنتج التام إلى مخزون الأصناف الجاهزة

كل وثيقة لاحقة ترتبط بأمر إنتاج محدّد، وتورِث القواعد الحاكمة من ملف المبادئ: اللقطة المُجمَّدة، آلات الحالة، الربط متعدد-إلى-متعدد بين الطلب والإمداد، التكرار متعدد المستويات، التهيئة بدل الترميز، وقيد محاسبي لكل حدث فعلي.

3.1 أمر الإنتاج (Production Order)

العقد الداخلي الذي يُصرِّح بإنتاج كمية محددة من منتج محدد. الفكرة الجوهرية هي اللقطة المُجمَّدة: عند الانتقال من Planned إلى Released يأخذ الأمر نسخة مُجمَّدة من شجرة المكوّنات BOM ومسار التشغيل Routing النشطين؛ أي تعديل لاحق على البيانات الرئيسية لا يؤثر على هذا الأمر — حمايةً للتكلفة التاريخية ومسار التدقيق.

حقول رأس الأمر Production_Order_Header

بنود المكوّنات Order_Component (نسخة مُجمَّدة من سطور الـ BOM)

بنود العمليات Order_Operation (نسخة مُجمَّدة من مسار التشغيل)

آلة الحالة لأمر الإنتاج (الانتقالات وآثارها)

1. Planned → Released: أخذ لقطة الـ BOM والـ Routing؛ حجز المواد؛ حجز الأداة والطاقة
2. Released → InProcess: بدء أول صرف أو تأكيد؛ يبدأ تتبّع الزمن
3. InProcess → Completed: اكتمال كل العمليات؛ الكمية المؤكّدة ≈ كمية الأمر
4. Completed → Closed: إقفال «تحت التشغيل»؛ حساب الانحرافات النهائية؛ منع أي ترحيلات لاحقة

• شبكة الأوامر: ترتبط الأوامر أباً بابن؛ أمر تجميع المنتج يولّد أوامر إنتاج القطع التي تولّد أوامر أنصاف مُصنَّعة، وكلٌّ يعرف أصله وفروعه — وتُتتبَّع التأخيرات بالسير عبر الشبكة.
• الكمية المؤكّدة قد تكون توزيعاً على درجات الجودة وليست رقماً مفرداً (راجع 3.3) — أي confirmed_quantity يُعمَّم إلى { grade → qty }.
• فرع التصنيع لدى الغير (Toll): عند Released لا تُحجَز/تُشترى مواد العميل بل يُتحقَّق من كفاية الأمانة؛ وعند Closed يذهب الناتج لملكية العميل والتكلفة = أجر التحويل فقط.

3.2 صرف المواد (Material Issue)

أول حركة محاسبية حقيقية: تنتقل المادة من مخزون الخام RM إلى «تحت التشغيل» WIP. لكل وثيقة صرف نوع وتوقيت ومستوى تفصيل.

حقول الصرف Material_Issue_Header و Material_Issue_Line

أنواع الصرف (يختلف التوقيت)

خوارزمية الصرف والقيد المحاسبي

1. التحقق: الأمر Released/InProcess؛ المتاح ≥ الكمية؛ المادة ضمن لقطة الـ BOM
2. جلب التكلفة cost_price = get_cost(material, costing_method)
3. إنقاص المتاح والمحجوز؛ زيادة WIP[order] += qty × cost_price
4. الترحيل: Debit WIP / Credit Raw Materials بمقدار qty × cost_price
5. تحديث order_component[material].issued += qty

فرع الأمانة: إذا كانت ملكية المادة للعميل تُصرف من مخزون أمانة منفصل لا من مخزونك، والمحاسبة تختلف (لا يوجد «دائن مخزون خام» بتكلفتك لأنها ليست أصلاً لك)؛ تُسجَّل حركة «استهلاك مادة العميل» للتتبّع فقط.

• مستوى الصرف يُعمِّم الصرف على مستوى الوردية: يسحب العامل مواد وردية كاملة مقدّماً، وتُجرى التسوية في نهاية الوردية لإظهار انحراف الاستهلاك.
• كل سطر BOM يختار نوعه ومستواه: الثقيل/الغالي → Manual؛ الصغير → Backflush؛ المُهمَل → يُعامَل كتكلفة غير مباشرة ولا يُصرَف.
• حالة اختبار الميلامين: يسحب العامل 16 كجم بودرة وينتج 300 طبق؛ النظري = 300 × 0.15 × 1.03؛ وانحراف الاستهلاك = المصروف − (المُنتَج × الـ BOM) يُظهر هدر البودرة دون تتبّع لكل قطعة.

3.3 التأكيد (Confirmation)

يسجّل ما نُفِّذ فعلياً من الأمر لكل عملية: كم أُنتِج، كم من العمالة/زمن الآلة استُهلك، وكم الهالك — وهو المصدر الحقيقي للأرقام الفعلية مقابل المعايير.

كيانات التأكيد

القاعدة الجوهرية للمردود

خوارزمية التأكيد (مع الـ Backflush والقيود)

1. التحقق: الأمر InProcess؛ العملية مفتوحة
2. إن كانت العملية بها مواد Backflush: consumed = total_input × BOM_qty وصرف تلقائي
3. تكلفة العمالة حسب labor_calc: Hourly → labor_hours × labor_rate أو PieceRate → produced × piece_rate
4. machine_cost = machine_hours × machine_rate؛ overhead = (labor_hours + machine_hours) × overhead_rate
5. الترحيل: Debit WIP / Credit Labor Applied + Machine Applied + Overhead Applied
6. الهالك: Debit Scrap Expense / Credit WIP بمقدار scrap × unit_cost
7. إن كان Final: إقفال العملية؛ وإن لم تكن الأخيرة: تحويل العملية التالية إلى Ready (← SFC)

توزيع تكلفة المنتجات المشتركة (طريقة صافي القيمة البيعية NRV)

الدرجة الأعلى سعراً تمتصّ تكلفة أكبر؛ والمصانع العادية تستخدم درجة واحدة فيؤول الأمر إلى السلوك المعياري المفرد.

3.4 استلام المنتج التام (Goods Receipt)

الخطوة الأخيرة: يدخل المنتج التام المخزون، فيُقفَل «تحت التشغيل» ويُفتَح مخزون الأصناف الجاهزة FG، محوِّلاً التكلفة المتراكمة إلى تكلفة منتج جاهز للبيع.

كيانات الاستلام

خوارزمية الاستلام (التكلفة المعيارية)

1. Total_WIP = Σ(material + labor + machine + overhead)
2. متعدّد الدرجات: تقسيم إلى سطور، لكلٍّ تكلفته المخصَّصة (راجع 3.3)؛ زيادة FG_Inventory[item, grade]
3. الترحيل: Debit FG Inventory (standard×qty) + Debit Variance Acct (الفارق) / Credit WIP (الفعلي)
4. إن Full: الأمر → Completed
5. إن مرتبطاً بأوامر بيع: توزيع الكميات على العملاء؛ ثم حساب الانحرافات النهائية والأمر → Closed

مثال الاستلام متعدّد الدرجات (ميلامين): أمر مكبس 100 طبق → 3 سطور + هالك: A: 70 @ 11.77، B: 18 @ 7.06، C: 7 @ 3.53، هالك 5؛ القيد: Debit FG-A 824 / FG-B 127 / FG-C 25 / Scrap 24 ; Credit WIP 1000.

فرع التصنيع لدى الغير: الناتج يذهب لملكية العميل لا لمخزونك؛ الإيراد = أجر التحويل فقط (Debit Customer / Credit Toll-service revenue)؛ ويُقفَل «تحت تشغيل التحويل» (عمالة+آلة+غير مباشر، بلا مواد).

بوابة الانحراف النهائي: عند الإقفال تُحسَب وتُحلَّل الانحرافات (سعر/استخدام/عمالة/غير مباشر) وهي مدخل طبقة التكاليف (ملف 04).

القيود المحاسبية التي تولّدها هذه الطبقة

ماذا يعني هذا لـ Moon ERP

• وحدة Production الحالية لديها ProductionOrder بحالات Draft, Confirmed, InProgress, Completed, Cancelled فقط — تختلف جذرياً عن آلة المواصفة (Planned→Released→InProcess→Completed→Closed) ولا تتضمن «اللقطة المُجمَّدة» ولا وثائق الصرف/التأكيد/الاستلام؛ يلزم توسيعها أو إعادة بناؤها وفق الوصفة المعتمدة.
• لا توجد كيانات Material Issue و Confirmation و Goods Receipt في الوحدة اليوم — تُبنى كجداول مُسبَّقة (prefixed) بآلات حالة وأحداث نطاق (Domain Events) ومُستمعين، على وصفة LIS المثبتة.
• الصرف والاستلام يُسنَدان إلى وحدة Inventory القائمة: InventoryIssue (به reference_type/reference_id مناسب لربط الصرف بأمر الإنتاج) و InventoryReceipt و InventoryCostLayer و StockService الذي يوفّر تكلفة FIFO — أي أن get_cost() يُطلَب من Inventory لا يُحسَب داخل التصنيع.
• كل القيود (WIP، خام، عمالة/آلة/غير مباشر مُحمَّل، هالك، أصناف جاهزة، انحراف، إيراد Toll) تُرحَّل حصراً عبر Modules\Accounting\Actions\CreateJournalEntry — قيد واحد لكل حدث فعلي، تماماً كنمط PostLabInvoice في LIS.
• تعميمات المواصفة (المردود توزيع درجات، العمالة بالقطعة، توزيع التكلفة عبر الدرجات) تُترجَم إلى حقول/تعدادات قابلة للتهيئة، احتراماً لمبدأ «التهيئة بدل الترميز» — وتنطبق على معظم المصانع بدرجة واحدة دون تعقيد.
• أرقام الوثائق عبر SequenceService، نطاق الفروع عبر DataScope، الصلاحيات تُسجَّل في PermissionDependencyRegistry ببادئة الوحدة، وكل النماذج تَرِث BaseModel/TenantAware لعزل الشركات (company_id).

1. طريقة التكلفة (Costing Method)

قرار استراتيجي حول كيفية تقييم المخزون والإنتاج، يُحدَّد مرة واحدة ويصعب تغييره، وهو قابل للتهيئة لكل صنف على حدة عبر الحقل Item.costing_method. النظام مُلزَم بدعم طرق مختلطة: معيارية للمنتجات النهائية (لإتاحة الانحرافات وتقييم مخزون مستقر)، ومتوسط متحرك للمواد الخام متقلبة الأسعار.

المعادلات الأساسية:

• Average: new_avg = (existing_qty×old_cost + new_qty×new_cost) / total_qty
• FIFO: issue at oldest batch prices, in order

كيان بناء التكلفة المعيارية Standard_Cost يحمل: std_material_cost، std_labor_cost، std_overhead_cost، std_total_cost، last_updated، update_frequency. مثال الميلامين: المسحوق (سعر متقلب) → Average، والأطباق → Standard

2. عناصر التكلفة (Cost Elements)

إجمالي تكلفة المنتج = ثلاثة عناصر، لكل منها مصدره وحسابه: Total Cost = Direct Material + Direct Labor + Manufacturing Overhead.

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

محرّك الأعباء cost_driver ∈ { LaborHours, MachineHours, DirectMaterialCost, UnitsProduced }. أنواع الأعباء: متغيّرة (كهرباء، مستهلكات)، ثابتة (إيجار، إهلاك، رواتب)، شبه متغيّرة (صيانة). في نهاية الشهر: مقارنة الأعباء المُحمّلة بالفعلية → فرق زائد/ناقص التحميل → قائمة الأرباح والخسائر.

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

3. مراكز التكلفة (Cost Center)

وحدة محاسبية تُراكم تكاليف جزء من المصنع، فتُمكّن من قول "تكلفة الكبس X وتكلفة التجميع Y". الكيان Cost_Center يحمل: cc_id، type، parent_cc، manager_id، budget_amount، actual_amount، status.

نوع المركز type ∈ { Production, Service, Auxiliary }. قاعدة عامة: تُوزَّع التكاليف الخدمية بالسبب لا بالتساوي؛ صيانة المكابس تُحمَّل أساساً على مركز الكبس لا توزَّع بالتساوي. مثال الميلامين: صيانة 8000 بطريقة Direct → CC-PRESS 90%=7200، CC-FINISH 10%=800، CC-ASSEMBLY 0%

4. تحليل الانحرافات: الانحرافات السبعة (Variance Analysis)

المخرج الأهم. Variance = actual − standard. الإجمالي وحده عديم الفائدة؛ القيمة في التفكيك، إذ يشير كل نوع إلى مشكلة محددة ومالك مسؤول.

• تحت نظام PieceRate لا ينطبق LRV/LEV التقليديان (العامل البطيء يضر نفسه)؛ ينتقل الانحراف إلى الآلة/الأعباء.
• FOVV حرج عندما تكون التكاليف الثابتة كبيرة: انخفاض الإنتاج يوزّع الثابت على وحدات أقل → تكلفة وحدة أعلى. هذا يقود رؤية "شغّل بكامل الطاقة".

حدود التسامح (Tolerance): <2% طبيعي بلا تحقيق، 2–5% مراقبة، >5% يتطلّب تحقيقاً. المنطق الشهري: لكل أمر مُقفَل تُحسب الانحرافات السبعة، وكل انحراف يتجاوز الحد يُصنَّف ويُوجَّه لمالكه، ثم يُولَّد تقرير Pareto بأكبر الأسباب.

1. شهرياً، لكل أمر إنتاج مُقفَل (Closed)
2. احسب الانحرافات السبعة
3. لكل انحراف يتجاوز حدّ التسامح: صنّفه (مواد/عمالة/أعباء) ووجّهه للمالك
4. ولّد تقرير Pareto (أكبر الأسباب أولاً) — يُغذّي تصحيح التخطيط (حلقة مغلقة)

المنتجات المشتركة (Joint-products): التكلفة تتبع القيمة لا تُقسَّم بالتساوي. grade.cost = total_cost × (grade.qty × grade.price) / total_sale_value — فتمتص الدرجة A (الأغلى) أكبر تكلفة للوحدة.

محاسبة الإنتاج تحت التشغيل والإقفال الدوري (WIP & Settlement)

التكلفة منسوجة داخل التنفيذ لا مرحلة دفعية لاحقة: صرف المواد، تأكيد العمالة، وتحميل الأعباء عند التأكيد، كلٌّ يُولّد قيداً مديناً لحساب WIP؛ واستلام المنتج التام يُقفل WIP إلى المنتجات التامة. في نهاية الفترة تُسوّى فروق تحميل الأعباء إلى قائمة الأرباح والخسائر وتُحسب الانحرافات السبعة لكل أمر مُقفَل.

ماذا يعني هذا لـ Moon ERP

• القيود المحاسبية كلها تمر حصراً عبر Modules\Accounting\Actions\CreateJournalEntry: حسابات WIP، Raw Materials، Labor Applied، MOH Applied، Finished Goods، وحسابات الانحرافات وزائد/ناقص التحميل.
• مركز التكلفة موجود فعلاً: Modules\Accounting\Models\CostCenter — يلزم التأكد من حمله للحقول type/parent_cc/budget/actual/status ومن إمكانية وسم سطور القيد JournalEntryLine بمركز التكلفة.
• تقييم المخزون متعدد الطرق لكل صنف يعتمد على Modules\Inventory\Models\InventoryCostLayer (يدعم Average/FIFO طبقياً) مع إضافة Standard/Actual واختيار الطريقة لكل صنف.
• الإقفال الدوري يستند إلى FiscalYear/FiscalPeriod وحدثي PeriodClosed/FiscalYearClosed لتشغيل تسوية الأعباء وحساب الانحرافات شهرياً.
• الإهلاك بالاستخدام للقوالب يتطلب عدّاد دورات على سجل العُدّة/القالب (غير موجود حالياً في وحدة Production) — فجوة يجب سدّها.
• سجل التكلفة المعيارية Standard_Cost وبيانات الموازنة وحجم الإنتاج المُخطَّط لكل مركز مطلوبة لحساب FOVV وانحرافات المركز.

الموقع داخل المعمارية

تقع رقابة الصالة بين التخطيط والتنفيذ وتربطهما لحظياً: تقرأ مسار التصنيع Routing (التسلسل المعرّف مسبقاً كبيانات أساسية ثابتة) لتعرف «ما العملية التالية»، وتكتب التأكيد Confirmation (الإنجاز الفعلي) عبر محرّك التنفيذ القائم. تنبيه جوهري: رقابة الصالة ليست هي المسار Routing — المسار هو التسلسل المعرّف الثابت، أما رقابة الصالة فهي التنفيذ اللحظي لذلك التسلسل.

• الطبقة الجديدة المطلوب بناؤها = الواجهة اللحظية + الانتقال الآلي بين الطرفيات + لوحة المتابعة الحيّة.
• نحو 80٪ من المنطق موجود مسبقاً: المسار معرّف، وحالة العملية Order_Operation قائمة، ومحرّك التأكيد جاهز.
• هذه وظيفة بمستوى نظام تنفيذ التصنيع MES.

الآلية الجوهرية

كل قسم يقابله شاشة طرفية لمركز عمل؛ وإغلاق العامل للمرحلة هو تأكيد عملية؛ وانتقال الأمر للمرحلة التالية هو تقدّم آلي في خطوة المسار؛ ورؤية الجميع للحالة لحظياً هي المتابعة الحيّة لصالة الإنتاج.

الكيان المحوري — حالة العملية اللحظية (Order_Operation)

هذا الكيان قائم مسبقاً على جدول Order_Operation (المعرّف في طبقة التنفيذ)؛ ودور رقابة الصالة هو تفعيل تتبّعه اللحظي فقط، لا إنشاء جدول جديد.

آلة الحالة للعملية (operation_status)

منطق التقدّم الآلي عند الضغط على «Done»

1. تعيين operation[N].status = Completed وختم end_time = now.
2. تسجيل التأكيد (الكمية + توزيع الدرجات + الهالك) عبر استدعاء محرّك التنفيذ القائم.
3. استدعاء routing.get_next(N) لقراءة المسار وتحديد العملية التالية.
4. إن وُجدت عملية تالية: تعيين operation[next].status = Ready وإشعار مركز عملها فتظهر على طرفيته.
5. إن لم توجد (آخر عملية): تعيين order.status = Completed فيصبح الأمر جاهزاً لاستلام البضاعة GR.

العلاقة الجسرية: routing.get_next(N) يجيب «ما التالي؟» (من المسار)، وحالة العملية تسجّل «أين نقف» (لحظياً).

مثال تطبيقي — مسار: كبس ← إزالة زوائد ← صنفرة ← تدريج

1. طرفية الكبس: يصل WO-001؛ يضغط العامل [Start] فتصير العملية InProgress.
2. يضغط [Done] فتُسجّل الكمية وتصير العملية Completed.
3. يقرأ النظام المسار فيجد التالية «إزالة الزوائد»، فيجعلها Ready ويُشعر طرفيتها.
4. يظهر WO-001 تلقائياً على طرفية إزالة الزوائد — وهذا هو «التقدّم».
5. تستمر السلسلة حتى التدريج (آخر عملية) فيصبح الأمر Completed وجاهزاً للاستلام.

الطرفية لكل قسم (Terminal UI)

• طابور الأوامر الواردة بحالة Ready، مرتّبة حسب الأولوية/الجدول الزمني.
• للأمر النشط: زرّا [Start] / [Done] فقط.
• عند Done: طلب الكمية، وتوزيع الدرجات، والهالك مع reason_code.
• تعرض: رقم الأمر، المنتج، الكمية المستهدفة، وهذه العملية فقط.
• فرض التسلسل: لا تظهر عملية إلا بعد اكتمال سابقتها.
• مصمّمة لبيئة الصالة: أزرار لمس كبيرة، أدنى حدّ من الكتابة، واحتمال العمل دون اتصال مع المزامنة لاحقاً.

لوحة المتابعة الحيّة للمشرف (Real-time Dashboard)

لوحة حيّة تُظهر لكل أمر عمليته الحالية ونسبة إنجازها، مثل: WO-001: Sanding (Op 30) — 60%، WO-002: Pressing — just started، WO-003: Waiting for press (mold busy). ومنها كشف الاختناق اللحظي: تكدّس أوامر بحالة Waiting قبل مورد معيّن يكشف أنه القيد الحالي — ترتبط بتخطيط السعة CRP لكنها لحظية لا تقديرية.

الآثار التشغيلية الخمسة

نطاق البناء والتكاملات الاختيارية

• المطلوب بناؤه فعلياً: الواجهة اللحظية + الانتقال الآلي بين الطرفيات + اللوحة الحيّة — لا إعادة بناء التنفيذ.
• تكاملات اختيارية لنظام MES أكمل (مذكورة لا مواصَفة): التقاط بيانات الآلة IoT، حساب OEE، مسح الباركود/RFID.
• تنبيه: OEE مذكور مرّتين دون أي معادلة أو تعريف — يُعدّ مرحلة مستقبلية؛ هذا الجزء يلتقط الأزمنة الفعلية فقط لتمكين حسابه لاحقاً.

ماذا يعني هذا لـ Moon ERP

• لا جدول جديد للكيان المحوري — يُعاد استخدام Order_Operation من طبقة التنفيذ، وتُضاف عليه آلة الحالة الرباعية كـ enum وفق وصفة الوحدات السريرية.
• التقدّم الآلي يُنفَّذ بنمط الأحداث والمستمعين: حدث عند Done ← مستمع يسجّل التأكيد ويستدعي routing.get_next ويُشعر مركز العمل التالي.
• أي ترحيل محاسبي ناتج عن التأكيد يمرّ حصراً عبر Modules\Accounting\Actions\CreateJournalEntry — لا كتابة مباشرة في دفتر الأستاذ.
• صلاحيات mfg.{resource}.{action} (مثل mfg.terminal.confirm) تُسجَّل في PermissionDependencyRegistry بـ Core، ونطاق الفروع عبر DataScope، والترقيم عبر SequenceService.
• طرفية الصالة تُبنى في واجهة Angular بمفاتيح ترجمة إنجليزية أولاً؛ والإشعار اللحظي يحتاج قناة بثّ (websockets/إشعارات Core) لدفع الأوامر الجاهزة على الطرفية التالية.
• لوحة الاختناق تستهلك CRP كمرجع للسعة المخطّطة وتقابلها بالواقع — يتطلب جاهزية طبقتي التخطيط والتنفيذ أولاً (الطبقة 11 في ترتيب البناء).

1. خريطة التكامل — «التصنيع ليس جزيرة»

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

2. قواعد التكامل الجوهرية

• الأمانة / التصنيع لدى الغير (Consignment / Toll): المادة المملوكة للعميل تُحفظ في دلو مخزون منفصل بقيمة ownership = Customer، ولا تُقيَّم أبداً كأصل خاص بالمصنع، ولا تُطلق أبداً عملية شراء.
• القيود المحاسبية فورية: منسوجة داخل أحداث التنفيذ لحظياً، وليست دفعة ليلية مجمّعة.
• الحجوزات في المخزون: تُنشأ عند إطلاق الأمر (Release) وتُستهلك عند صرف المواد (Material Issue).

3. نموذج البيانات الموحد — البيانات الأساسية (Master Data)

4. نموذج البيانات الموحد — التخطيط (Planning)

5. نموذج البيانات الموحد — التنفيذ (Execution)

6. نموذج البيانات الموحد — التكلفة والكيانات العابرة (Costing & Cross-cutting)

7. ملخص العلاقات والتعدديات الرئيسية

• Item 1—* BOM_Header 1—* BOM_Line *—1 Item (مكوّن) — متعدد المستويات تكراري
• Item 1—* Routing_Header 1—* Routing_Operation *—1 Work_Center، و Routing_Operation *—1 Tool
• Work_Center *—1 Cost_Center
• Sales_Order *—* Production_Order (عبر Pegging)، و Sales_Order 1—* Delivery_Schedule
• Production_Order 1—* من: Order_Component / Order_Operation، Material_Issue، Confirmation (← Yield بالدرجات)، Goods_Receipt (سطر لكل درجة)، Variance_Record

8. قوائم القيم الحاكمة (Enums — file 00 §0.5)

9. ترتيب البناء المُلزَم — كل خطوة تعتمد على سابقتها

1. البيانات الأساسية + CRUD (BOM تكراري، Routing، Work_Center، Tool)
2. إعدادات MRP للصنف Item_MRP_Settings + التكلفة المعيارية Standard_Cost
3. خطة الإنتاج الرئيسية MPS (استهلاك التنبؤ، أسوار الزمن، CTP)
4. تخطيط الاحتياجات MRP (التفجير التكراري، تحجيم الدفعات، فرع التصنيع لدى الغير)
5. تخطيط الطاقة CRP (تقاطع الموارد، كشف التحميل الزائد)
6. أمر الإنتاج (اللقطة المجمّدة، آلة الحالة، شبكة الأوامر)
7. صرف المواد (3 أنواع، 3 مستويات، الأمانة)
8. التأكيد (توزيع الدرجات، الأجر بالقطعة، القيود)
9. استلام البضاعة (متعدد الدرجات، بوابة الانحراف، فرع التصنيع لدى الغير)
10. التكلفة (الطرق، العناصر، مراكز التكلفة، 7 انحرافات)
11. مراقبة أرضية المصنع SFC (حالة العمليات لحظياً، واجهة الطرفيات، التقدم التلقائي، لوحة المعلومات)
12. التكاملات (المبيعات، المشتريات، المخزون، دفتر الأستاذ، الموارد البشرية)

10. المراحل المستقبلية المُحددة (غير مفصّلة)

ماذا يعني هذا لـ Moon ERP

• تملك Moon ERP بالفعل وحدة Production لكنها رفيعة جداً (3 ترحيلات / 7 نماذج: BillOfMaterials, BomComponent/Operation, ProductionOrder, ProductionCenter) ولا تغطي MPS/MRP/CRP ولا التكلفة ولا التأكيد متعدد الدرجات ولا SFC — هذه المواصفة تتطلب توسعتها جذرياً وفق «وصفة الوحدات» (جداول مُسبَّقة، enums لكل آلة حالة، أحداث + مستمعون، Actions للنداءات عبر الوحدات).
• التكامل المحاسبي يُنفَّذ عبر Modules\Accounting\Actions\CreateJournalEntry فقط (نمط النداء المتزامن المُعتمَد كما في PostLabInvoice)، ويجب أن يكون فورياً عند كل صرف/تأكيد/استلام كما تفرض المواصفة.
• الطلب↔التوريد عبر Pegging و Delivery_Schedule يربط مباشرةً بكيان SalesOrder في وحدة Sales القائمة؛ والأوامر المخططة من MRP تُغذّي وحدة Purchases (PurchaseRequest/PurchaseOrder).
• حجوزات وحركات المادة الخام←تحت التشغيل←التام والدفعات/المواقع تُسند إلى وحدة Inventory القائمة (InventoryMovement, StockBalance, InventoryCostLayer) مع الحاجة لدلو ملكية منفصل لمخزون الأمانة ownership=Customer.
• تُسجَّل خرائط الصلاحيات في Core PermissionDependencyRegistry بادئة mfg، ويُطبَّق نطاق الفرع عبر Core DataScope، وترقيم المستندات عبر SequenceService، والكيانات ترث BaseModel/TenantAware (company_id).
• معدلات أجور العمالة والأجر بالقطعة (labor_calc) تتبادل مع وحدة HRM (الرواتب/بنود الراتب)؛ ومراكز التكلفة Cost_Center تتقاطع مع مراكز التكلفة في وحدة Accounting.
• المراحل المستقبلية تنسجم مع وحدات Moon القائمة: QMS للجودة، CMMS للصيانة الوقائية وإدارة العدد/القوالب — ما يقلّل البناء الجديد لو رُبطت الواجهات منذ الآن.

ترجمة كلام العميل إلى المصطلح القياسي ثم إلى ركيزة النظام

الدورة الأولى — التكلفة الاستكشافية (تسعير عرض الأسعار)

دورة لا تُحدث أي أثر مخزني أو محاسبي؛ مخرجها عرض سعر مؤقت يبدأ دورة الإنتاج إذا قَبِله العميل.

تسلسل الدورة الأولى

1. العميل يقدّم المنتج + التركيبة + الكمية المستهدفة ← المبيعات تفتح mfg_cost_estimates بحالة Draft. R-01
2. الإسناد إلى R&D ← بناء قائمة تركيب مبدئية Engineering/Draft. R-02
3. الإسناد إلى الحسابات ← تفجير القائمة وتطبيق معدلات مركز العمل وcost_driver ← نسخة في mfg_cost_estimate_versions (الحالة Estimated). R-03
4. اعتماد التكلفة (Quoted) ← المبيعات تعيد التكلفة المبدئية للعميل كمستند مؤرّخ الصلاحية. R-04
5. نهاية الدورة الأولى — بلا مخزون ولا قيد ولا التزام؛ المخرج عرض مُسعّر يُمهّد للدورة الثانية إن قُبِل.

الدورة الثانية — الإنتاج (تصنيع حسب الطلب): المرحلة (أ) التجربة

الدورة الثانية — المرحلة (ب): أمر رسمي ← تثبيت ← تخطيط ← دفعة ← حجز ← تصنيع ← استلام

المتطلبات العابرة للمراحل

• R-17 شاشات بوابات المراحل: واجهة Angular لكل مرحلة تعرض بيانات تلك المرحلة فقط وزر/أزرار التقدّم للمرحلة التالية، مدعومة بجدول mfg_order_stage_gates بمفتاح الملف (من حرّك الملف ومتى ومن أين إلى أين). كل انتقال محكوم بصلاحية production.*. المراحل التجارية (Quotation, Trial, Awaiting-Advance …) تعيش على آلة mfg_order_cases (الملحق 35) — آلة حالات أمر الإنتاج المعتمدة (Planned → Released → InProcess → Completed → Closed) لا تتسع ولا تُمسّ. الشاشات لا تتجاوز أي آلة حالات — الزر يستدعي نفس الـAction الذي تعرضه الواجهة البرمجية. تفسير «مرحلة إنتاجية» مُسجَّل OQ-9.
• R-18 نَسَب المستندات المربوط بالأمر: كل تقدير وتجربة ودفعة وأمر إنتاج وصرف وتأكيد واستلام يحمل مفاتيح الربط؛ ويجب أن يعيد عرض النَسَب بناء السلسلة: طلب تسعير ← قائمة مبدئية ← عرض ← تجربة ← أمر رسمي ← قائمة مثبّتة ← خطة ← دفعة ← حجز ← أمر تصنيع ← صرف ← تأكيدات ← استلام ← فاتورة تشغيل.
• R-19 استلام/إرجاع خامة العميل (مستند إدخال الأمانة — سدّ U-2): خامة العميل الحرة تدخل مخزن الأمانة عبر مستند استلام مخزني حقيقي يعتمده ApproveReceipt بفرع تتبّعي بلا تقييم وبلا قيد (ملك العميل في عُهدة)، بمرجع الملف وتسجيل اللوطات في الأنساب؛ والمتبقي غير المستخدم يعود عند الإقفال بمستند الصرف المرآتي + تسوية ختامية (المستلَم − المصروف − خردة الأمانة D-30 = المرتجع). لا رصيد مخزني يُمسّ خارج مستندات الاعتماد أبداً.
• R-20 تسليم عينة التجربة للعميل (سدّ U-3): مخرَج التجربة يُستلم في دلو تقييم (مخزن-كحالة، غير قابل للبيع)، والتسليم للعميل مستند تسليم عينة (صرف تتبّعي من دلو التقييم) يُختم على mfg_trial_batches — وتسجيل قرار العميل (R-07) مشروط بوجوده.
• R-21 فوترة الخامة المشتراة بالنيابة (تمرير — سدّ U-1): الخامة المشتراة لحساب العميل ملك المصنع حتى الفوترة (مخزون ذاتي محجوز للملف وأوامر شراؤها موسومة «تُفوتر على العميل»)؛ عند استلام التام في فرع التشغيل تُخلى حصتها من WIP بقيد production_toll_material_cogs، وتحمل الفاتورة النهائية سطر تمرير الخامة بالتكلفة (+ نسبة مناولة تعاقدية) بجوار أجر التحويل — فتتسوّى الدفعة (نسبة من تكلفة الخامة، D-25) على فاتورة تحتوي الخامة التي موّلتها: حساب النقدية يُقفل.

تسلسل الدورة الثانية الكامل

1. طلب التجربة: العميل يطلب عينة ← mfg_trial_batches + أمر order_type=Trial تنفّذه R&D مربوطاً بالتقدير/الملف. R-05
2. تشغيل التجربة: إصدار→صرف→تأكيد→استلام→إقفال حقيقي؛ التقاط تكلفة/عائد/خردة التجربة؛ المخرَج إلى دلو التقييم ثم تسليمه بمستند العينة. R-06 R-20
3. تقييم التجربة: قرار العميل (مستند التسليم شرط) ← Passed أو Failed؛ الفشل ← إعادة تجربة أو تخلٍّ. R-07
4. الأمر الرسمي: عند الموافقة تنشئ المبيعات أمر العميل المؤكد؛ كل ما بعده يُربط به. R-08
5. تثبيت القائمة: R&D ترقّي المبدئية إلى Production/Active. R-09
6. التخطيط والجاهزية: احتساب الاحتياجات (إجمالي←صافي)، فصل المشترى بالنيابة عن مواد العميل، مسوّدات طلبات شراء تُجهَّز ولا تُرفع. R-10
7. بوابة الدفعة: لأن المصنع يشتري الخام بالنيابة، يجب أن يدفع العميل دفعة مقدمة ← Received عبر سند القبض (LA-1)؛ الإصدار والشراء بالنيابة محجوبان حتى الاستيفاء — وطلبات الشراء تُرفع الآن فقط. R-11
8. إدخال خامة العميل (إن وُجدت): تُستلم في مخزن الأمانة بمستند الاستلام التتبّعي. R-19
9. إنشاء أمر التصنيع (الإصدار): تجميد اللقطة وتنفيذ الحجز كأثر جانبي (مخزون ذاتي و/أو أمانة + الأداة) وإطلاق ProductionOrderReleased. R-13 R-12
10. صرف المواد: إدانة WIP للمملوكة؛ مواد العميل حركة تتبّع فقط. R-14
11. التصنيع: تأكيدات العمليات وقيود الأجور/الأعباء والتقدّم الآلي. R-15
12. الإنهاء والاستلام في مخزن التام: مدين تام / دائن WIP (المملوك) أو فرع التشغيل (تام بملكية العميل + فاتورة نهائية = أجر تحويل + سطر تمرير الخامة R-21 تُسوَّى عليها الدفعة)؛ إرجاع/تسوية خامة العميل غير المستخدمة (R-19)؛ الأمر يكتمل ويُقفل. R-16
13. شاشات المراحل (R-17) تنقل الأمر بين كل خطوة، والنَسَب (R-18) يبقيه مربوطاً بأمر العميل طوال الوقت.

الأشياء الجديدة/المعدّلة التي يُدخلها هذا الملحق

ما لم يحدده العميل — أسئلة مفتوحة تتطلب اعتماداً قبل البناء

تعديلات خطة الطريق (على القسم 23)

• المرحلة 0 (مسار الملاحق): اعتماد الأسئلة المفتوحة عبر السجل المرجعي الوحيد في الملحق 36 رابعاً (D-23..D-36 + OQ-9) — لا بالترقيم الموضعي القديم «OQ-1..OQ-8 = D-23..D-30» (سُحب؛ مثلاً OQ-1/OQ-3←D-23، OQ-2←D-25، OQ-4←D-30، OQ-5←D-34، OQ-6←D-35، OQ-7←D-28، OQ-8←D-36). بوابة صلبة: لا بناء لواجهة العميل دون هذه القرارات.
• مرحلة جديدة 2.5 — «واجهة العميل» (M) بعد المرحلة 1 (التنفيذ الحقيقي) والمرحلة 2 — لأن معدلات العمالة/الماكينات وcost_driver التي يسعّر بها التقدير تصل في المرحلة 2 — وقبل المرحلة 4 (التخطيط): mfg_cost_estimates + النسخ، دورة حياة القائمة المبدئية، mfg_trial_batches مع دلو التقييم ومستند العينة (تركب قضبان أوامر المرحلة 1 بوسم Trial)، وشاشات الدورة الأولى والملف. نواة الملف وبوابة الدفعة (mfg_customer_advances + شرط الإصدار) وجدول البوابات تصل أصلاً في المرحلة 2 — انظر الملحق 36 ثالثاً (الذي أعاد تسمية الموضع المؤقت «1.5»).
• لا تغيير على مراحل الأمانة/التشغيل والحجز والتأكيد والانحرافات — هذا الملحق يستهلكها.

المتطلبات المشتقّة من المقابلة

تصف المقابلة دورتين ومطلباً واجهيّاً شاملاً:

• الدورة 1 — التكلفة الاستكشافية: العميل يحضر منتجاً بتركيبته ويطلب تسعيراً استكشافياً ← طلب ← R&D يضع قائمة مواد مبدئية (Draft BOM) ← المحاسبة تحسب تكلفة مبدئية ← تُعاد للعميل كعرض سعر. (IR-1, IR-2, IR-3)
• الدورة 2 — الإنتاج بالأوردر: كل المستندات مربوطة بأوردر العميل (IR-4)؛ مرحلة تجربة بدفعة عيّنة حقيقية التكلفة يصنعها R&D (IR-5)؛ عند الموافقة ← أوردر رسمي ← R&D يعتمد قائمة المواد والتخطيط يحدد الكميات والجاهزية (IR-6) ← دفعة تحت حساب إلزامية قبل الحجز لأن المصنع يشتري الخامات نيابةً عن العميل (IR-7) ← قد يورّد العميل خامات تبقى ملكه (IR-8) ← حجز ← أمر تصنيع ← صرف ← تصنيع ← استلام للمخزن.
• واجهات المراحل (IR-9): شاشات مخصّصة لكل مرحلة إنتاجية يُنقل الأوردر منها من مرحلة لأخرى — أوسع من طرفيات عامل طابق المصنع.

جدول الأحكام — متطلبٌ متطلبٌ مقابل التحليل المنشور

السبب الجذري للفجوات

التحليل المنشور خريطةٌ تنفيذية للمواصفة، والمواصفة نفسها تبدأ من أوردر عميل مؤكَّد وتنتهي باستلام تام الصنع وحساب تكلفته — تنمذج المصنع ودفاتره ببراعة. لكن سير العميل يضيف قمعاً تجارياً وهندسياً قبل الأوردر لم تتصوّره المواصفة:

• قمع التسعير قبل البيع (IR-1→IR-3): طلب ← تركيبة R&D مبدئية ← سعر استكشافي ← عرض. لا تسعير ولا وضع تكلفة استكشافي ولا فاعل R&D في المواصفة — الطلب مؤكَّد سلفاً حين يبدأ نموذجها. أكبر نقطة عمياء، وهي تجارية لا تصنيعية.
• دورة دفعة التجربة (IR-5): تشغيل إنتاجي حقيقي لكنه مؤقّت نتيجته قرار عميل، لا مخزون تام. تعداد order_type بلا حالة تجربة.
• شراء مشروط بالدفعة (IR-7): قاعدة ضبط نقدي لأعمال الأجرة (لا تشترِ خامة قبل دفع العميل) عند نقطة الإطلاق. المواصفة تحجز دون شرط.
• سير عمل مرحلي بالأقسام + واجهاته (IR-6 جزئياً، IR-9): العميل يفكّر بالأقسام والمراحل؛ الخطة المنشورة تفكّر بالمحرّكات والوحدات. المحرّكات موجودة وطبقة الأوركسترا وشاشاتها غير موجودة.

كل ما هو أسفل الأوردر الرسمي المؤكَّد (دورة حياة القائمة، MRP/CRP، الحجز، الصرف، التأكيد، الاستلام، التكلفة، أمانة الأجرة، الربط) مغطّى بالفعل — IR-4 وIR-8 إصابتان مباشرتان، وIR-2/IR-3/IR-6 تُعيد استخدام محرّكات قائمة ينقصها غراء سير العمل.

بنود العمل الجديدة (إضافة لخطة 23) — C-01..C-08

جداول جديدة من هذا الملحق: mfg_costing_requests (+سطور)، mfg_cost_estimates، واختيارياً mfg_quotes (يُفضَّل إعادة استخدام عرض سعر Sales)، واختيارياً mfg_order_deposits (يُفضَّل إعادة استخدام دفعة مقدمة محاسبية/بيعية). صافٍ 2–4 جداول mfg_* جديدة فوق الـ24 المنشورة، رهن التحقق من إمكانية إعادة الاستخدام.

قرارات مطلوبة من الإدارة (تمتدّ من D-01..D-22)

الترقيم المرجعي = الملحق 36 رابعاً (D-23..D-36 + OQ-9). هذا الجدول اقترح القرارات؛ السجل المرجعي يحمل الأرقام والتوصيات النهائية ويتقدّم على أي تباين أدناه (مثلاً توصية D-24 هنا تجاوزها اعتماد order_type=Trial).

الخلاصة

التحليل المنشور يغطّي بالكامل قلب التصنيع المرتبط بالأوردر والأجرة/الأمانة الذي يحتاجه هذا العميل (IR-4, IR-8) — الربط الشامل بالأوردر ومناولة مواد العميل إصابتان مباشرتان، يكفيهما سحب الأجرة/الأمانة للأمام زمنياً (C-07/D-27). ومحرّكات الهندسة والتخطيط لـ IR-2/IR-3/IR-6 موجودة (دورة حياة القائمة، لفّ التكلفة المعيارية، MRP/CRP) لكن ينقصها غراء سير العمل وفاعل R&D ووضع التكلفة الاستكشافي ومستند العرض. القدرات الثلاث الجديدة فعلاً كلها خارج عالم المواصفة: دورة التسعير الاستكشافي/RFQ (IR-1 ❌)، ودورة دفعة التجربة (IR-5 ❌)، وبوابة الدفعة المقدمة قبل الحجز (IR-7 ❌) — مع واجهات أوركسترا المراحل (IR-9 🟡). تصير بنوداً C-01..C-08 وقراراتٍ في السجل المرجعي الوحيد (الملحق 36 رابعاً — D-23..D-36 + OQ-9) مُلحقةً بخطة 23. لا شيء منها يبطل المعمار المنشور؛ كلّها إضافية وتعيد استخدام السكك القائمة.

الدورتان كما وصفهما صاحب المصنع

• الدورة الأولى — التكلفة الاستكشافية: العميل يأتي بمنتج وتركيبته ويطلب تسعيراً استكشافياً ← قسم البحث والتطوير يصنع قائمة مواد مبدئية (Draft BOM) ← المحاسبة تحسب التكلفة المبدئية ← يعود السعر المبدئي للعميل كعرض سعر.
• الدورة الثانية — الإنتاج بالأوردر: كل المستندات معلّقة على أوردر العميل. (أ) تجربة: ينتج البحث والتطوير دفعة عيّنة حقيقية بتكلفة حقيقية. (ب) عند الموافقة ← أوردر رسمي ← تثبيت قائمة المواد ← التخطيط يحدد الكميات ويتحقق من الجاهزية ← العميل يدفع دفعة تحت حساب (لأن المصنع يشتري الخامات بالنيابة عنه) وقد يورّد العميل خاماته التي تبقى ملكه ← إن صحّت الماليات ← حجز المواد ← أمر التصنيع ← الصرف ← التصنيع ← الإنهاء ← الاستلام في مخزن التام.
• طلب إضافي: العميل يريد واجهة لكل مرحلة إنتاجية لتحريك الأوردر من مرحلة لأخرى من تلك الواجهات.

الخلاصة التنفيذية: لبنات الدورة مقابل الموجود في النظام

1) عروض الأسعار وتحويلها إلى أوردر — موجود وجاهز

العمود الفقري للدورة 1 (عرض السعر) وللأوردر الرسمي في الدورة 2 مبنيٌّ بالكامل في Modules/Sales.

• النموذج: SalesQuotation.php برأس وبنود وإجماليات وتاريخ صلاحية، وحقل ربط عكسي sales_order_id (سطر 56).
• دورة الحياة: Draft → Sent → Accepted/Rejected/Expired → Converted/Cancelled مع duplicate لإعادة التسعير (المتحكم SalesQuotationController).
• التحويل: SalesOrderController::convertFromQuotation() (سطر 368) مشروط بحالة Accepted، ينسخ الرأس والبنود ويعلّم العرض Converted؛ المسار POST quotations/{quotation}/convert-to-order.

قيد التطبيق على الدورة: سعر الدورة 1 هو SalesQuotation مسعّر من قائمة المواد المبدئية؛ والأوردر الرسمي للدورة 2 هو ناتج convertFromQuotation. كل مستندات الدورة 2 يجب أن تتعلّق بمعرّف هذا الأوردر، أي أن أوامر الإنتاج الجديدة (mfg_*) تحتاج مفتاحاً أجنبياً sales_order_id.

2) دفعة العميل تحت الحساب ومعالجتها المحاسبية — جزئي (البنية حاضرة، غير موصولة)

هذه أدقّ نقطة مالياً: الدفعة تحت الحساب التزام مقدم على المصنع وليست تحصيلاً لذمة مدينة. تسجيلها كدفعة بيع عادية يشوّه الذمم والإيراد معاً.

• الحساب الصحيح موجود في الشجرة: DefaultChartOfAccountsSeeder سطر 44 ← 2104 إيرادات مقدمة (التزامات/دائن)، ومقابله 1106 مصروفات مدفوعة مقدماً.
• سند قبض عام: ReceiptVoucher.php به partner_id وحساب استلام وربط متعدد الأشكال reference_type/reference_id وبنود لكل منها account_id خاص.
• ترحيله محايد للحساب: ApproveReceiptVoucher::buildJournalLines() (سطر 76) يجعل النقدية/البنك مديناً والحساب الموجود على البند دائناً — فيمكن قيد الدفعة من ح/ النقدية إلى ح/ 2104 إيرادات مقدمة بلا تعديل كود، بمجرد تحديد حساب البند.

الناقص: لا ربط بأوردر ولا دلالة «دفعة مطلوبة قبل الإطلاق» ولا بوابة «هل اكتملت الدفعة؟». وSalesPayment أداة خاطئة هنا لأنه مقيّد بـinvoice_id وPostSalesPayment مثبّت على «من ح/ النقدية إلى ح/ الذمم المدينة» مقابل فاتورة (أسطر 30–56) — لا مسار للالتزام المقدم. كما لا توجد سابقة مالية في LIS (كلمة advance هناك تعني تقدّم حالة لا دفعة).

التعديل المقترح: خطوة دفعة على مسار الأوردر تُصدر ReceiptVoucher بـreference_type=sales_order وبند دائن لحساب دفعات عملاء تحت الحساب (يصلح 2104 أو حساب فرعي جديد 2105). والبوابة المالية = مجموع سندات الدفعة المعتمدة ≥ الدفعة المطلوبة. عند الفوترة النهائية تُخصم الدفعة (من ح/ الإيرادات المقدمة إلى ح/ الذمم أو الإيراد).

3) خامات العميل المملوكة له (التصنيع بالأمانة) — مفقود

قال صاحب المصنع صراحةً إن العميل قد يورّد خاماته وتبقى ملكه. لا يعرف Moon ERP اليوم مفهوم ملكية المخزون إطلاقاً.

• Warehouse.php لا يحمل أي حقل مالك؛ حقوله: type, account_id, allow_negative_stock.
• WarehouseType = Main, Sub, Transit, Damaged, Returns — لا نوع Consignment/مملوك للعميل.
• بحث consign/owned_by/ownership في وحدة المخزون = صفر نتيجة؛ الرصيد والحركات بلا مالك.

الأثر: خامات العميل ستُقيَّم وتُرحَّل لمخزون الشركة (تضخيم الأصول) وقد تُصرف لأوامر أخرى — والمصنع حائزٌ لها بالأمانة لا بالملكية.

خياران للتعديل: (1) علم المخزن — وفق القرار المعتمد سلفاً D-15 هو العلم warehouses.is_consignment لا نوع تعداد WarehouseType::Consignment جديد — مع owner_partner_id على المخازن، يكون تقييمها خارج الدفاتر (لا قيد أصل)، والصرف منها لا يولّد سطر تكلفة مواد. (تصحيح: الصياغة الأصلية اقترحت قيمة تعداد جديدة متجاهلةً اعتماد D-15 لصيغة العلم — الملحقان 33 و36 يتبعان D-15.) (2) إضافة owner_partner_id على stock_balances والحركات (فارغ = ملك الشركة) مع تصفية الرصيد والتقييم حسب المالك. كلاهما بناء جديد.

4) سير البحث والتطوير ودفعة التجربة — جزئي

• قائمة المواد المبدئية حالة قائمة: BomStatus = Active, Inactive, Draft — قائمة R&D الاستكشافية هي BillOfMaterials في حالة Draft.
• دفعة حقيقية بتكلفة حقيقية = ProductionOrder ذاته (يحمل تكاليف مواد/عمالة/أعباء مخططة وفعلية).

الناقص: لا مفهوم «دفعة تجربة» (ProductionOrder بلا حقل kind/is_trial ولا ربط customer_id/sales_order_id). ووحدة CMMS صيانة أصول (CmmsAsset, CmmsWorkOrder, CmmsPmSchedule) لا تصلح للبحث والتطوير رغم اسم «أمر عمل». لا كيان مشاريع/مهام لاستقبال طلب R&D قبل وجود قائمة مواد.

التعديل: نمذجة التجربة كـProductionOrder بـkind=trial وsales_order_id لترث كل بنية التكلفة والمخزون وتبقى معلّقة على أوردر العميل.

5) سير الموافقات لبوابات المراحل — جزئي (محرك موجود، الإنتاج غير مسجّل)

يوجد محرك موافقات عام في Core يصلح تماماً للبوابات التي يريدها العميل (اعتماد القائمة، تأكيد الدفعة، إطلاق الأوردر، قبول التجربة).

• ApprovalWorkflow.php وApprovalLog.php ومتحكماتهما وحالات ApprovalLogStatus.
• لكن النطاق محدود: ApprovalModule = Sales, Purchases فقط؛ وApprovalDocumentType يغطي عروض/أوامر/فواتير البيع والشراء — لا أنواع إنتاج (قائمة مواد، أمر إنتاج، دفعة تجربة).

التعديل: إضافة ApprovalModule::Production وأنواع مستندات (bom, production_order, trial_batch) لإعادة استخدام المحرك بدل بناء منطق موافقات خاص.

6) خط CRM لاستقبال طلبات التسعير — مفقود (شكل CRM غير مناسب)

Modules/CRM وحدة دعم وتذاكر لا خط مبيعات: نماذجها CrmTicket, CrmTicketComment, CrmSlaPolicy, CrmCustomerInteraction, CrmCustomerTag — لا Lead/Opportunity/Pipeline/Stage.

الأثر: لا خط فرص يستضيف استقبال «العميل يأتي بمنتج → طلب تسعير». والحل العملي: (1) إعادة استخدام SalesQuotation كسجل RFQ (حالة Draft = طلب مفتوح) — الأرخص، فيصير الطلب الاستكشافي والعرض سجلاً واحداً تحمل حالاته القمع. (2) أو تسجيل الاستفسار في CrmCustomerInteraction ثم توليد عرض. خط CRM كامل غير مطلوب لتلبية العميل.

7) انتقالات مراحل الإنتاج وطلب «واجهة لكل مرحلة» — جزئي

• ProductionOrderController يتيح confirm/start/complete/consume(الصرف)/recordOutput/cancel كلٌّ محمي بصلاحية — هذا هيكل واجهات المراحل.
• ProductionOrderStatus = Draft, Confirmed, InProgress, Completed, Cancelled مع حُرّاس انتقال — آلة حالات صغيرة.
• بدائية الحجز خاملة: StockBalance به reserved_quantity ودالة available = quantity - reserved_quantity لكن لا كود يكتب الحجز — خطوة «احجز المواد للأوردر» لها عمود تستقر فيه دون إجراء حجز بعد.

الناقص لمسار العميل: لا customer_id/sales_order_id على أمر الإنتاج، ولا مرحلة تجربة ولا بوابة دفعة مكتملة ولا مرحلة حجز ولا فحص جاهزية/تخطيط — الآلة الحالية تقفز Draft→Confirmed→InProgress.

التعديل: آلة مراحل تجارية موازية (لا توسعة ProductionOrderStatus — حُسمت كمظلّة mfg_order_cases في الملحق 35) لسلسلة العميل مثل: Requested → TrialInProgress → TrialAccepted → AwaitingDeposit → Released(+Reserved) → InProgress → Completed → ReceivedToFG، وتوصيل إجراء حجز يزيد reserved_quantity. تصحيح ترتيبي: وفق الصف 13 المعتمد في الخريطة، الحجز أثر جانبي لإجراء الإصدار — فمرحلة «محجوز» يدخلها الإصدار ولا تسبقه أبداً (السلسلة الأصلية هنا وضعت الحجز قبل الإصدار وكان ذلك ترتيباً دائرياً مخالفاً للتصميم المعتمد). كل مرحلة تقابل واجهة بنسبة 1:1.

جديد مقابل معاد استخدامه (لملحق خارطة الطريق)

• يُعاد استخدامه: دورة SalesQuotation وconvertFromQuotation؛ محرك ترحيل ReceiptVoucher؛ حساب 2104؛ BomStatus::Draft؛ محرك ApprovalWorkflow؛ بنية تكلفة ProductionOrder؛ عمود reserved_quantity.
• يُوسَّع: إضافة sales_order_id + customer_id + kind لأمر الإنتاج؛ ApprovalModule::Production؛ افتراض دفعة ReceiptVoucher دائنة لالتزام مقدم ومربوطة بالأوردر؛ توصيل إجراء الحجز؛ توسعة آلة حالات الإنتاج.
• يُبنى جديداً: ملكية المخزون للعميل (علم is_consignment المعتمد D-15 + owner_partner_id بتقييم خارج الدفاتر)؛ كيان/علم دفعة التجربة؛ استقبال RFQ (المُوصى به: إعادة استخدام عرض السعر بحالة Draft لا خط CRM جديد).

المبدأ الحاكم: الدواء لا يضيف محرّكات كثيرة — بل يرفع الخطورة ويقلب الافتراضات

المواصفة manufacturing_spec مصمَّمة عامّة لكل الصناعات (مثالها أطباق الميلامين)، وتؤجّل طبقة الجودة صراحةً، ولا تنصّ على قاعدة تتبُّع للتشغيلات. أرقام التشغيلة batch_no/lot_no فيها مجرد نصّ حر، وحالة الجودة مجرد قائمة quality_status ∈ {Released, OnHold, Rejected}. هذا مقبول لمصنع عام، لكنه غير كافٍ لمصنع دواء: بنود يعتبرها التحليل المنشور قابلة للتأجيل تصبح هنا متطلبات تنظيمية إلزامية. أبرز مثال: حالة جودة التام تُضبط افتراضياً على Released (القرار D-21) — وهذا غير مقبول دوائياً؛ يجب حجز التام للفحص قبل أن يصبح مخزوناً قابلاً للبيع.

الجدول المرجعي: البنود الثمانية وحالتها مقابل التحليل المنشور

P1 — سجل تصنيع التشغيلة وترقيمها (BMR & Batch Numbering) — لاحق، حرج

كل تشغيلة مُصنَّعة يجب أن تحمل سجلاً واحداً قابلاً للتدقيق يربط الأمر المُفرَج عنه بـ: لقطة قائمة المواد/المسار المجمَّدة، كل عمليات الصرف (بأرقام تشغيلات المواد الخام المستهلَكة)، الفحوصات البينية، المُشغِّل والمعدّة، الانحرافات، العائد، وتوقيع الإفراج. أرقام التشغيلات يجب أن تكون متسلسلة منضبطة بلا فجوات ومستقلّة عن رقم الأمر.

• المكوّنات موجودة بالفعل: اللقطة المجمَّدة في production_order_materials/_operations، ووثائق mfg_material_issues/mfg_confirmations/mfg_goods_receipts، والترقيم عبر SequenceService.
• الجديد فقط: طبقة تجميع/طباعة السجل فوق هذه الصفوف + مفتاح تسلسل مخصّص للتشغيلة SequenceService::generateNext(company,'production','batch') — لا محرّك معاملات جديد (نظير ثغرة بطاقات المسار A21).
• المرحلة: التقاط ربط batch_no في Phase 1/2 (رخيص وإضافي)؛ طباعة/تجميع السجل بالانحرافات والتواقيع في Phase 6 مع بوابات الجودة وأنساب التشغيلات.

P2 — حجز التام للفحص قبل التحويل (QC Release Hold) — لاحق، حرج

هذا أهم انحراف دوائي عن الخطة العامة: التام لا يصير مخزوناً قابلاً للبيع عند الاستلام، بل يدخل حالة حجز/حجر صحي للفحص ولا يُفرَج عنه إلا بقرار جودة/شخص مؤهَّل.

• مُدرَج بالفعل: سطر التام يحمل quality_status ∈ {Released, OnHold, Rejected} (الجدول mapping صف 22)، وجداول QMS تحمل production_order_id، والبوابات مجدولة في Phase 6.
• المشكلة: القرار D-21 يجعل الافتراض Released حتى Phase 6 — وهذا غير مطابق دوائياً.
• العلاج (بلا مخطّط جديد): قلب الافتراض إلى OnHold لشركات الدواء عبر تهيئة production.gr_default_quality_status، وتوجيه التام المحجوز إلى مخزن حجر (نمط المخزن-كحالة، نظير علم is_consignment) أو منع توفّره للبيع حتى qms_inspections.result = Released. مُستهلِك «متابعة بوابة استلام التام» موجود أصلاً على حدث GoodsReceiptPosted.
• المرحلة: منطق البوابة Phase 6؛ قلب الافتراض + مخزن الحجر قابل للتسليم كبند تهيئة صغير في Phase 1 لهذا العميل.

P3 — تتبُّع التشغيلة والصلاحية و FEFO (Lot/Expiry/FEFO/Genealogy) — لاحق، حرج

رقم التشغيلة وتاريخ الصلاحية إلزاميان لا نصّ حرّ؛ الصرف بنظام الأقرب انتهاءً أولاً؛ والنسب الكامل (أي تشغيلات مواد خام دخلت أي تشغيلة تام) شرط قانوني للاستدعاء؛ والصلاحية تمنع صرف/بيع المنتهي.

• مُدرَج بالفعل كثغرة حرجة: هذه هي ثغرة A4 («التشغيلة/اللوط ليست من الدرجة الأولى… batch_number/expiry_date نصّ حرّ… لا FEFO») + الثغرة المواصفية B2 («غياب التتبُّع كقاعدة») + القرار D-14، المجدولة في Phase 6.
• إعادة التصنيف دوائياً: A4 حرجة أصلاً؛ الدواء يجعلها غير قابلة للتأجيل لهذا العميل — خطّ دواء لا يمكن أن يبدأ قانونياً بدون تشغيلة+صلاحية+FEFO+نسب. هذا أقوى مرشّح للتقديم من Phase 6 ليُسلَّم في نفس إصدار تشغيل العميل.

P4 — مواصفة الفنّ المطبعي والتغليف لكل عميل (Artwork/Packaging Spec) — اختياري/لاحق، مهم

في التصنيع للغير يكون الفنّ المطبعي والتغليف خاصّاً بالعميل والسوق ومضبوط الإصدار؛ واستخدام نسخة خاطئة/قديمة خطأ من فئة الاستدعاء. مواد التغليف نفسها مكوّنات قائمة مواد مضبوطة بأرقام تشغيلات.

• جديد: لا ذكر للفنّ المطبعي أو ضبط مواصفة التغليف في md/20 ولا md/21؛ المواصفة تنمذج التغليف كمكوّن عادي فقط.
• العلاج: سيّد إصدارات فنّ/ملصق مفتاحه (العميل، المنتج، السوق) بإصدار معتمد سارٍ (إعادة استخدام Attachment + نمط ترقيم إصدارات قائمة المواد A9)؛ يشير سطر تغليف قائمة المواد إلى الإصدار المعتمد. خفيف، يركب مع تعميق التصنيع للغير في Phase 6.

P5 — العيّنات المحفوظة/المرجعية (Retained Samples) — لاحق، مهم

تُلزِم GMP بحفظ عيّنات مرجعية من كل تشغيلة لمدة صلاحية المنتج + هامش، مُسجَّلة وقابلة للاسترجاع.

• جديد: غير موجود في أي وثيقة منشورة.
• العلاج: سجل عيّنات محفوظة مرتبط بـbatch_no (يعتمد على P1/P3)، واختيارياً حجز كمّية صغيرة من التام عند الاستلام في مخزن «عيّنات محفوظة» (نمط المخزن-كحالة). يُجدوَل مع عمل الجودة/التشغيلات في Phase 6.

P6 — التنظيف/التحويل بين المنتجات على خطّ مشترك (Cleaning/Changeover) — لاحق، مهم

على المعدّات المشتركة يكون التنظيف/التحويل المُعتمَد بين منتجين إلزامياً (منع التلوّث المتبادل)، ويستهلك طاقة فعلية وتكلفة فعلية، ويحجز بدء المنتج التالي.

• جزئي/جديد: setup_time موجود (صف 5) ويمكن أن يستوعب زمن التحويل، لكن التنظيف كخطوة منفصلة معتمَدة ومُكلَّفة غير منمذج؛ وتصنيف التوقّف الأوسع ثغرة مواصفية مفتوحة (B15). أثر طاقته على CRP جديد فعلاً.
• العلاج: نمذجة التحويل/التنظيف كنوع عملية مسار أو إعداد معتمد على التسلسل على مركز العمل؛ إدخال مدّته في الطاقة الفعّالة لـCRP (عمل التقويم/الطاقة A8/B4 في Phase 4) وتكلفته في تكلفة التحويل (Phase 2). للإصدار الأول يكفي تقريبه بـsetup_cost_rate + setup_time.

P7 — ربط ملف التسجيل الدوائي (Regulatory Dossier Linkage) — اختياري/لاحق، مهم

كل منتج مُصنَّع مرتبط بـملف تسجيل/إذن تسويق (مثل تسجيل هيئة الدواء). يجب أن تطابق قائمة المواد/المسار المعتمدة الملف المسجَّل، وأن يُرفَع علَم عند تصنيع منتج غير مسجَّل أو منتهي التسجيل.

• جديد: لا مفهوم تسجيل/ملف في التحليل المنشور.
• العلاج: سيّد تسجيل خفيف (المنتج، السوق، رقم التسجيل، تواريخ السريان، إصدار قائمة المواد المعتمد) مع فحص عند الإفراج عن الأمر. يعيد استخدام ترقيم إصدارات قائمة المواد (A9) + Attachment. اختياري للإصدار الأول؛ علَم استشاري كافٍ للبدء.

P8 — مطابقة العائد كبوابة إلزامية للإفراج (Yield Reconciliation Gate) — لاحق، مهم

تُلزِم GMP بـميزان مواد/مطابقة عائد لكل تشغيلة — يجب أن تتطابق المدخلات مع (المخرجات + الهالك + العيّنات) ضمن حدود معتمدة، وأن يُفسَّر ويُعتمَد العائد خارج الحدود قبل الإفراج.

• جزئي: المواصفة تحسب yield% = Σgrades / input، وجداول mfg_confirmation_yields/_details تلتقط كمّيات الدرجات/الهالك (صفّا 19–20). الجديد هو المطابقة كبوابة صلبة (نطاقات حدود + تفسير إلزامي + منع الإفراج عند التجاوز) نظير نطاقات تفاوت الانحرافات في التكاليف لكن مطبَّقة على ميزان المواد لإفراج التشغيلة.
• العلاج: إعادة استخدام نمط نطاقات التفاوت (طبيعي/تحقيق) على حساب العائد؛ العائد خارج الحدود يرفع انحرافاً ويمنع إفراج الجودة (يرتبط بـP2). الالتقاط من Phase 2؛ بوابة منع الإفراج مع الجودة في Phase 6.

خلاصة المراجعة المتقاطعة: مُدرَج مقابل جديد

التوصية النهائية للإدارة

الدواء لا يضيف محرّكاً كبيراً للخطة المنشورة؛ بل يرفع الخطورة ويغيّر الافتراضات لضبط الإفراج (P2) وتتبُّع التشغيلة/الصلاحية (P3 = ثغرة A4/B2 المُدرَجة، وقد صارت غير قابلة للتفاوض للتشغيل)، ويضيف حزمة صغيرة من مصنوعات GMP (سجل التشغيلة، العيّنات المحفوظة، إصدارات الفنّ/التغليف، ربط الملف، بوابة مطابقة العائد). نوصي بـتقديم ثغرة A4 (التشغيلة+الصلاحية+FEFO+النسب) لتُسلَّم مع أول إصدار تشغيلي لهذا العميل، وقلب افتراض حالة جودة التام إلى OnHold لشركة الدواء فوراً.

توحيد التسمية (يحسم ما ورد في الملاحق السابقة)

الملحق 30 اقترح mfg_quotations + mfg_quotation_costings، والملحق 31 اقترح mfg_costing_requests + mfg_cost_estimates. هذا الملف يثبّت التسمية النهائية: رأس التقدير هو mfg_cost_estimates (طلب التسعير + حالة المسار التجاري في كيان واحد) وإصدارات الحساب المتعاقبة في mfg_cost_estimate_versions (سجل غير قابل للتعديل — كل إعادة حساب صفٌّ جديد). أما عرض السعر الموجَّه للعميل فليس جدولاً جديداً: هو SalesQuotation الموجود فعلاً في Modules/Sales بدورة حياته الكاملة وتحويله إلى أوردر (دليل الملحق 32 §1)، ويُربط بالتقدير عبر sales_quotation_id. هذه التسمية صادق عليها الملحق 36 (ورقة الدلتا الموحَّدة) — لا وجود لـmfg_quotations في أي وثيقة معتمدة؛ وإجمالي الملاحق الموحَّد +6 جداول (24 ← 30): هذا الزوج + mfg_order_cases وmfg_trial_batches وmfg_customer_advances وmfg_order_stage_gates.

1) الكيانات: ماذا نبني وماذا نعيد استخدامه

2) آلة الحالات مع الفاعلين (البيع، البحث والتطوير، المحاسبة)

قواعد عابرة لكل الانتقالات: كل انتقال محكوم بصلاحية production.estimates.*؛ القائمة المبدئية تظل غير مؤهلة لأي أمر إنتاج طوال الدورة؛ ولا أثر مالي أو مخزني في أي خطوة — قناة القيود الوحيدة في النظام CreateJournalEntry لا تُستدعى في هذه الدورة أصلاً.

3) الأحداث ومن يستهلكها

كلها في Modules\Production\Events وتُطلق بعد نجاح المعاملة، ومستهلكوها مستمعون داخل وحدة الإنتاج يستدعون إجراءات الوحدات الأخرى للأمام (قانون العقود — الملحق 22 §2: لا وحدة تستورد الإنتاج أبداً).

4) شاشات المراحل (نمط واجهة-لكل-مرحلة الذي طلبه العميل — R-17)

• لوحة مسار التقديرات (البيع + الإدارة): كانبان Draft / Estimated / Quoted / Won / Lost مع شارة انتهاء الصلاحية — المدخل لكل الشاشات.
• شاشة استقبال طلب التسعير (البيع): اختيار العميل، وصف المنتج، رفع التركيبة، الكمية المستهدفة ← زر CreateCostEstimate.
• ورشة القائمة المبدئية (البحث والتطوير): طابور الطلبات الواردة، إنشاء المنتج المرشَّح، تأليف قائمة Engineering/Draft ببنود قد تكون بأسعار يدوية لخامات غير مخزّنة ← زر SubmitDraftBom.
• ورشة التكاليف (المحاسبة): طابور القوائم الجاهزة، تشغيل المحاكاة، تحليل مواد/عمالة/غير مباشرة لكل إصدار، تاريخ الإصدارات، الاعتماد، وإعادة الحساب.
• شاشة عرض السعر (البيع): نسبة الربح، السعر، الصلاحية، توليد وإرسال SalesQuotation وPDF، وزرّا فوز/خسارة (الفوز معطَّل عند انتهاء الصلاحية).
• شاشة نسب التقدير (قراءة للجميع): خط زمني كامل من الطلب حتى النتيجة ثم مستندات الدورة الثانية بعد الفوز، عبر mfg_peggings.

كل شاشة تعرض بيانات مرحلتها وأزرار انتقالها فقط، والزر يستدعي نفس الإجراء الذي تكشفه الواجهة البرمجية — الشاشات لا تتجاوز آلة الحالات أبداً. شرائح الصلاحيات: production.estimates.create للبيع، production.estimates.rnd.draft_bom للبحث والتطوير، production.estimates.cost وapprove_costing للمحاسبة، quote وconvert للبيع، والمشرف يشمل الكل.

5) مسار التحويل: تقدير فائز ← مدخل دورة الإنتاج

1. قبول العميل يمر عبر منطق التحويل الموجود مُستدعىً حصراً عبر الإجراء الأمامي Modules\Sales\Actions\ConvertQuotationToOrder (استخلاص الملحق 36 رقم 19 من المتحكم convertFromQuotation — نفس وصفة CreatePurchaseRequest؛ الإنتاج لا يستدعي متحكم وحدة أخرى أبداً، قانون العقود §0.1): SalesQuotation = Accepted ← أوردر بيع رسمي يُختم على التقدير — هذا الأوردر هو مرساة الدورة الثانية الذي تتعلق به كل المستندات اللاحقة.
2. ترقية المنتج المرشَّح Prospect ← Active فيصبح مؤهلاً للمخزون والتخطيط والبيع.
3. القائمة المبدئية لا تُرقَّى تلقائياً: تُسلَّم للدورة الثانية وهي Draft، ويثبّتها البحث والتطوير (Engineering/Draft ← Production/Active، نسخة نشطة واحدة لكل نافذة سريان) بعد نتيجة دفعة التجربة لأن دروس التجربة تدخل في التركيبة النهائية — وإن تخطى العميل التجربة جاز الترقية فوراً.
4. بذر صف mfg_peggings يربط التقدير بالأوردر فيكتمل النسب من طلب التسعير حتى استلام التام.
5. التفرع: (أ) تجربة — mfg_trial_batches + أمر إنتاج order_type=Trial ينفذه البحث والتطوير على قضبان التنفيذ الحقيقية بتكلفة وقيود حقيقية (أول قيد محاسبي في حياة هذا العميل يقع هنا، في الدورة الثانية لا الأولى)؛ أو (ب) مباشرة — تثبيت القائمة ← التخطيط ← بوابة الدفعة تحت الحساب ← الحجز ← الإطلاق.
6. استمرارية التكلفة: الإصدار الفائز من mfg_cost_estimate_versions هو خط الأساس الذي تُقارن به تكلفة التجربة الفعلية، ومرشَّح لبذر أول تكلفة معيارية في mfg_standard_costs بعد تفعيل القائمة.

6) موضعها في خارطة الطريق وقرارات التوقيع

تهبط الدورة في المرحلة 2.5 «واجهة العميل» (الملحق 36 ثالثاً — الموضع الذي سمّاه الملحق 30 §6 مؤقتاً «1.5»): بعد المرحلة 1 (دورة حياة القائمة) وبعد المرحلة 2 — لأن معدلات العمالة/الماكينات وcost_driver التي يسعّر بها التقدير تصل في المرحلة 2 لا المرحلة 1 (تصحيح للادعاء السابق بأن المرحلة 1 تكفي) — ومستقلة عن محرك التخطيط. وضع المحاكاة هو سحبٌ مبكر لرياضيات تجميع التكلفة من المرحلة 3 بنسخة تقديرية فقط (البند C-03) دون الحاجة لمحرك الانحرافات. القرارات المطلوب توقيعها قبل البناء (من السجل المرجعي — الملحق 36 رابعاً): D-31 بناء القمع التجاري (كان يُستشهد به سابقاً برقم «D-23» المؤقت)، D-26 حالة المنتج المرشَّح، D-29 إعادة استخدام عرض سعر البيع (الدليل مثبت)، وD-34/OQ-5 مدة صلاحية العرض (الافتراضي 30 يوماً، والعرض المنتهي يمنع التحويل حتى يُعاد تسعيره).

قرار النمذجة: كيان مظلّة رفيع mfg_order_cases وليس أعمدة على أمر الإنتاج

كان الخياران: إضافة أعمدة القضية والدفعة على production_orders، أو كيان مظلّة رفيع يعلو أوامر الإنتاج. التوصية الحاسمة: كيان المظلّة — للأسباب التالية:

• قضية واحدة ↔ عدة أوامر إنتاج: القضية تملك أمر (أو أوامر) التجربة order_type=Trial مع حلقات إعادة التجربة، والأمر الرئيسي، وربما دفعات مجزّأة — صفّ أمر واحد لا يتسع لدورة حياة تمتد على أوامر متعددة.
• سبع من أربع عشرة محطة تحدث ولا يوجد أمر إنتاج مُصدَر أصلاً (أمر البيع، طلب التجربة، اعتماد التجربة، تثبيت القائمة، فحص التخطيط، بوابة الدفعة، والإلغاء المبكر) — الأعمدة لن تجد صفاً تسكنه.
• آلتا حالات بعمود فقري واحد: آلة أمر الإنتاج المالية/التنفيذية (Planned → Released → InProcess → Completed → Closed) تبقى كما اعتُمدت في المرحلة الأولى دون أي توسيع؛ آلة القضية طبقة تنسيق تجارية فوقها.
• الدفعة المقدمة على مستوى القضية لا الأمر: دفعة واحدة تغطي الارتباط كله (تجربة + أمر رئيسي)، فترتبط mfg_customer_advances بالقضية طبيعياً.
• لوحة المراحل تعمل على القضايا: بطاقات الكانبان قضايا، وطرفيات الصالة تبقى على مستوى العملية داخل محطة واحدة.

الامتداد على production_orders يقتصر على: case_id (يقبل الفراغ — أوامر التخزين العادية بلا قضية)، إضافة Trial إلى تعداد order_type، وعمود sales_order_id مباشر (مع بقاء mfg_peggings المرجع الكمي للتخطيط). لا أعمدة دفعة على الأوامر إطلاقاً. ويُعاد ربط جدول التدقيق mfg_order_stage_gates بمفتاح case_id (تعديل على الملحق 30)؛ فيصبح صافي الجداول الجديدة في الملاحق ستة والإجمالي الكلي ثلاثين (mfg_cost_estimates، mfg_cost_estimate_versions، mfg_trial_batches، mfg_customer_advances، mfg_order_stage_gates، mfg_order_cases) — صادق عليه الملحق 36. قاعدة الفصل عن محرك الاعتماد (Core ApprovalWorkflow): جدول البوابات سجل تدقيق لكل حركة؛ التوقيعات البشرية (تثبيت القائمة، حكم التجربة، الإعفاء من الدفعة، إفراج الجودة) تركب محرك الاعتماد القائم كشرط مسبق للانتقال — لا آليتي اعتماد متوازيتين.

آلة الحالات بالبوابات: كل انتقال = شرط + صلاحية + Action + حدث

كل انتقال يستدعي Action واحداً محكوماً بصلاحية: يتحقق من البوابة، يغيّر المحطة، يسجّل سطراً في mfg_order_stage_gates (من، متى، من أين إلى أين، ولقطة تقييم البوابة)، ثم يطلق الحدث بعد إتمام المعاملة. الإلغاء متاح من أي محطة قبل دخول التصنيع مع فك الحجوزات ومعالجة الدفعة (ردّ أو مصادرة حسب السياسة).

سياسة تكلفة التجربة (قابلة للضبط — تحسم OQ-1 وOQ-3)

• فوترة (Bill): تُفوتر التجربة بالتكلفة + هامش متفق كفاتورة خدمة مبيعات عند قرار العميل — نجح أو فشل.
• استيعاب (Absorb): عند إقفال أمر التجربة: مدين مصروف بحث وتطوير / دائن تحت التشغيل (production_trial_absorb).
• رصيد عند الفوز (Credit-on-win): تُرحَّل التكلفة إلى أصل مؤجل (production_trial_defer)؛ عند الفوز تُطبَّق كخصم على الفاتورة النهائية، وعند الخسارة تُشطب لمصروف البحث والتطوير.
• الافتراضي من إعداد production.trial_cost_policy مع تجاوز لكل قضية؛ وأوامر Trial تُستبعد من معايرة التكلفة المعيارية وتُقرَّر منفصلة.

المعالجة المحاسبية: من التزام الدفعة إلى تسويتها

القبض النقدي يركب ReceiptVoucher القائم (ترحيله محايد الحساب) — وهذا هو تعديل القانون المعتمد LA-1/D-33 على §5.4: قيد السند نفسه هو ترحيل الدفعة الوحيد (ترحيل واحد، لا نداء موازياً لـCreateJournalEntry) — والباقي عبر CreateJournalEntry حصراً؛ الحسابات تُحل من مفاتيح إعدادات production.* وتُزرع كحسابات تفصيلية — ومنها حساب جديد 2105 «دفعات عملاء تحت الحساب» تحت الإيرادات المقدمة.

شاشات المراحل: لوحة كانبان + ورشة عمل لكل محطة

لوحة واحدة مركزها القضية (production/cases/board): الأعمدة هي المحطات والبطاقات هي القضايا، والسحب معطّل عمداً — الحركة لا تتم إلا من زر المرحلة الذي يستدعي نفس الـAction الذي تعرضه الواجهة البرمجية، فلا تجاوز لآلة الحالات أبداً، وكل نقلة مسجّلة في mfg_order_stage_gates. ولكل محطة ورشة عمل مخصصة تعرض طابورها وقائمة تحقق حية لبوابتها وزر التقدّم الوحيد:

علاقتها بطرفيات صالة الإنتاج: الطرفيات (المرحلة الخامسة من الخارطة) تبقى على مستوى العملية داخل محطة InProduction وحدها — المشغّل يبدأ وينهي العمليات ويرسل التأكيدات، ولا يحرّك القضية أبداً؛ القضية تتقدم تلقائياً من الأحداث التي تطلقها تلك التأكيدات نفسها. طبقتان لكل منهما آلة حالاتها، تربطهما الأحداث.

تنبيه تفسيري (السؤال المفتوح OQ-9 — يُحسم عند بوابة المرحلة 0): هذا القسم كله يقرأ «واجهات لكل مرحلة إنتاجية» على أنها مراحل الملف التجارية. إن قصد العميل مراحل التصنيع الفيزيائية (خلط/تحبيب/كبس/تعبئة — قراءة مرجَّحة دوائياً) فالجواب ورش لكل عملية مسار فوق عمليات التوجيه: تخدمها طرفيات المرحلة 5 مع شاشة مراقبة قراءة-فقط لكل عملية يمكن شحنها مبكراً في 2.5. والجدولة (قرار D-28 المعدَّل): لوحة المسار MVP في المرحلة 2، الورش الحرجة للبوابات في 2.5، والإكمال والصقل في 5.

الأحداث والصلاحيات

• اثنا عشر حدثاً جديداً في Modules\Production\Events (من ProductionCaseOpened حتى CaseClosed وCaseCancelled) + حدثا الأمانة CaseConsignmentReceived/CaseConsignmentReturned تُطلق بعد إتمام المعاملة بمستمعين معصومين من التكرار — وخمسة أحداث قائمة يُعاد استخدامها (ProductionOrderReleased، MaterialIssued، ConfirmationPosted، GoodsReceiptPosted، ProductionOrderClosed) تقود التقدّم الآلي للقضية. هذا القاموس — مع أحداث التقدير الخمسة في الملحق 34 — هو قاموس الأحداث القانوني الوحيد (صادق عليه الملحق 36). قانون الاتجاه محفوظ: لا وحدة خارجية تستورد الإنتاج.
• شريحة صلاحيات لكل محطة تحت المساهم production القائم: المبيعات (فتح/تجربة/قرار/تسليم)، R&D (إنشاء التجربة/تثبيت القائمة)، التخطيط (الفحص والإصدار)، الحسابات (تسجيل الدفعة، والإعفاء production.case.deposit_waive بصلاحية مرتفعة)، المخازن (استلام الأمانة والصرف)، الجودة (الإفراج)، والمشرف يعبر الكل (الافتراضي المقترح لـOQ-7). فضاء production.case.* هذا — مع production.estimates.* للدورة الأولى — هو التصنيف القانوني الوحيد للصلاحيات (صادق عليه الملحق 36).
• مفاتيح إعدادات جديدة: production.default_advance_percent، production.advance_basis، production.trial_cost_policy، production.trial_allow_draft_bom، production.customer_advance_account_id، production.gr_default_quality_status (للدواء: OnHold).

التسلسل الكامل للقضية

1. أمر بيع مؤكد ← فتح قضية mfg_order_cases مرقمة عبر SequenceService.
2. طلب تجربة بسياسة تكلفة محددة ← أمر إنتاج حقيقي order_type=Trial تنفّذه R&D بتكلفة كاملة.
3. اعتماد العميل للتجربة بتوقيع موثّق (أو إعادة التجربة / الإلغاء).
4. R&D تثبّت القائمة Production/Active وتُختم على القضية.
5. التخطيط يفجّر القائمة ويفصل المملوك عن مواد العميل ويجهّز مسوّدات طلبات الشراء بالنيابة (لا تُرفع بعد).
6. بوابة الدفعة المانعة: لا حجز ولا شراء ولا تصنيع قبل تخصيص سندات القبض الكافية (أو إعفاء موثَّق) — قيد السند: مدين النقدية / دائن التزام دفعات العملاء (LA-1)؛ وعند الاستيفاء تُرفع طلبات الشراء بالنيابة الآن فقط.
7. الإصدار يجمّد اللقطة ويحجز المواد كأثره الجانبي مربوطةً بالأمر؛ مواد العميل تكون قد دخلت الأمانة بمستند الاستلام التتبّعي (U-2) بلا أي تكلفة علينا مع تتبّع لوطاتها في النَسَب.
8. التصنيع على القضبان القائمة (صرف ← تأكيدات ← استلام) وطرفيات الصالة تعمل داخل هذه المحطة فقط.
9. الاستلام محتجزاً OnHold ← إفراج الجودة ← مخزن التام.
10. إذن التسليم + الفاتورة النهائية عبر CreateServiceInvoice (أجر التحويل + سطر تمرير الخامة بالنيابة في التشغيل) + تسوية الدفعة المقدمة على الفاتورة + إرجاع/تسوية خامة العميل المتبقية ← إقفال القضية بعد ترحيل الانحرافات.

موضع الملحق في الخارطة

يهبط هذا التصميم وفق جدولة الملحق 36 ثالثاً (التي تتقدّم على موضع «1.5» المؤقت في الملحق 30 — والصحيح بعد المرحلة 2 لأن معدلات العمالة/الأعباء وcost_driver تصل فيها): نواة الملف وبوابة الدفعة وجدول البوابات ولوحة المسار في المرحلة 2، والتقديرات والتجارب والورش الحرجة في المرحلة 2.5 «واجهة العميل» — وفحص التخطيط هنا تفجير محلي لأمر واحد يسبق MRP الكامل ويطيع نفس بوابة الدفعة. التعديلات على الوثائق المنشورة: إضافة Trial وcase_id وsales_order_id لخريطة 20 (الصف 13) + استثناء D-32 على الصف 2، إضافة شرط بوابة الدفعة على ReleaseProductionOrder (ويحجب رفع طلبات الشراء بالنيابة أيضاً) وتعديل LA-1/D-33 على §5.4 وأنواع القيود الجديدة وإجراءات CreateServiceInvoice/ReceiveCustomerMaterial/ReturnCustomerMaterial للقسم 22، وإعادة ربط mfg_order_stage_gates بالقضية في الملحق 30 — والأسئلة المفتوحة أصبحت إعدادات قابلة للضبط بانتظار تصديق المجلس عبر السجل المرجعي (الملحق 36 رابعاً: D-23..D-36 + OQ-9).

أولاً — تعديلات الخريطة (على الوثيقة 20)

إجمالي الجداول الجديدة يرتفع من 24 إلى 30 جدول mfg_* (+6: التقديرات، نسخ التقديرات، ملفات الأوامر، التجارب، الدفعات، بوابات المراحل). كل بند: ما هو، هل هو جديد أم تعديل على موجود، أين يعيش، ولماذا.