█ موجود (0)█ جزئي (21)█ ناقص (7)
الخلاصة بصراحة: الأساس المحاسبي للتصنيع قويّ — التكاليف الفعلية بأنواعها الثلاثة، المعايير والانحرافات، أوامر الإنتاج، التول، المخزون والدفعات والتتبّع، مراكز التكلفة، المرافق المحاسبية والأدوار كلها مبنية وتعمل. لكن الوثيقة وثيقة محاسب تكاليف متقدّم، وفيها طبقة تحليلية‑إدارية (CVP، ربحية العملاء، KPIs لوحة، R&D، الطاقة/المرافق التفصيلية، الذكاء الاصطناعي) غير مبنية بعد. التقدير: ٧ محاور ناقصة تماماً و٢١ موجودة كلياً أو جزئياً. التفصيل تحت — كل محور بمكانه في الكود.
المحاور الـ28 — التفصيل الكامل
جزئي
1 — هيكل التكاليف الأساسي (مواد/عمالة/Overhead)
أين في النظام: BE: Modules/Production/app/Actions/ConfirmOperation.php (computeCost سطر 737-780)، IssueMaterials.php (ربط الاستهلاك بالأمر production_order_id + reference_type=production_order سطر 100/272)، Models/ProductionOrder.php (حقول actual_material_cost/actual_labor_cost/actual_overhead_cost). HRM hook: ConfirmOperation::recordPiecework سطر 931-989. FE: /factory/orders/:id (order-cockpit) + /factory/confirmations.
كيف يعمل اليوم: الثلاث عناصر مبنية بالكامل: المواد المباشرة تُصرف من المخزون بحركة مرتبطة بالأمر (production_order_id) وتُراكم في actual_material_cost. العمالة تُحسب في ConfirmOperation من labor_cost_rate الخاص بمركز الإنتاج إما بالساعة (labor_hours × rate) أو بالقطعة (confirmed_qty × rate) حسب labor_calc. الـ Overhead يُطبّق عبر cost_driver (LaborHours/MachineHours/DirectMaterialCost/UnitsProduced) × overhead_rate. يوجد ربط بـHR عبر hook اختياري (recordPiecework) يكتب قيد piecework في hrm_piecework_entries عند مطابقة المستخدم بموظف، لكنه محمي بـhasTable ويُتجاهل بصمت إن غاب الجدول/الربط.
الناقص / التوصية: لا يوجد مفهوم أوفرتايم (Overtime) إطلاقاً — بحث overtime/over_time في كامل موديول Production لم يُرجع أي نتيجة؛ معدل العمالة ثابت ولا يميّز ساعات إضافية بمعدل مختلف. ربط الحضور بـHR سطحي: الـhook يسجّل قيمة piece-rate فقط (v1: ledger only، بدون payroll wiring الفعلي) ولا يستهلك بيانات الحضور/البصمة من attendance لحساب العمالة الفعلية — أي لا يوجد جسر attendance→تكلفة العمالة. التوصية: إضافة معدل أوفرتايم على مركز الإنتاج/الموظف، وربط فعلي مع HRM attendance لتغذية actual_labor_cost من ساعات الحضور المؤكدة بدل معدل المركز المسطّح.
ناقص
2 — تكاليف البحث والتطوير R&D
أين في النظام: — (لا يوجد). بحث formula/pilot/r_and_d/research/amortiz/feasibility في Modules/Production و Modules كاملاً لم يُرجع أي ملف خاص بالإنتاج (النتائج كلها LIS/Accounting Zakat غير ذات صلة). لا يوجد route تحت /factory/* لذلك.
كيف يعمل اليوم: غير موجود بأي شكل. لا يوجد كيان فورميولا (Formula) منفصل عن BOM، ولا دفعات تجريبية Pilot Batches كنوع أمر مستقل، ولا سير اعتماد منتج جديد، ولا أي آلية لتجميع تكاليف R&D ثم توزيعها/إطفائها (amortization) على الإنتاج الفعلي، ولا دراسة جدوى منتج جديد. أقرب شيء قائم هو BOM (Modules/Production BomController) لكنه هيكل إنتاج معياري وليس فورميولا بحثية بدورة اعتماد.
الناقص / التوصية: بناء كامل مطلوب: (1) كيان Formula/Recipe بإصدارات وحالة اعتماد. (2) نوع أمر/دفعة Pilot Batch يُجمّع تكاليفه في حساب R&D capitalizable منفصل عن WIP الإنتاجي. (3) workflow اعتماد المنتج (draft→pilot→approved). (4) محرّك amortization يوزّع تكلفة التطوير المعتمدة على وحدات الإنتاج اللاحقة (per-unit أو زمني). (5) شاشة جدوى المنتج الجديد. هذا أكبر فجوة بين المحاور الخمسة.
جزئي
3 — أوامر الإنتاج Job Order Costing
أين في النظام: BE: Modules/Production/app/Http/Controllers/ProductionOrderController.php (store سطر ~146 order_number عبر sequenceService، tollInvoice سطر 677-693 customer_id)، Models/ProductionOrder.php (fillable: order_type, production_type, material_ownership)، Enums/ProductionOrderStatus.php (6 حالات). FE: /factory/orders + /factory/orders/:id (order-cockpit بتبويب القيود + الجاهزية + pegging).
كيف يعمل اليوم: Job Order Costing قائم: لكل أمر كود فريد يُولّد من sequenceService (فريد على مستوى الشركة)، تتجمّع عناصر التكلفة (مواد+عمالة+overhead مخطط/فعلي) على مستوى الأمر، حالات الأمر ست (planned→released→in_process→completed→closed/cancelled). الربط بالعميل موجود في مسار التولينغ (tollInvoice يطلب customer_id من business_partners) و material_ownership=customer للتشغيل لدى الغير. الربط بالمنتج عبر product_id/bom_id. Changeover ممثَّل جزئياً عبر setup_time على عمليات الـrouting (RoutingController/BomOperation). شاشة الأرشيف = قائمة الأوامر مع فلتر بحث + حالة Closed.
الناقص / التوصية: (1) الكود فريد للشركة وليس "كود فريد لكل عميل" — لا يوجد ترميز/تسلسل مخصّص بالعميل كما يتطلب التولينغ المتعدد للعملاء. (2) الربط بالعميل موجود فقط لحظة الفوترة (tollInvoice)؛ الأمر نفسه لا يحمل customer_id كحقل أساسي قابل للبحث/التجميع per-customer. (3) production_type/order_type موجودة في fillable لكنها غير مُتحقَّق منها في StoreProductionOrderRequest (لا قيم مُعرّفة enum) — أي "أشكال إنتاج متعددة" غير مفعّلة فعلياً. (4) Changeover محسوب كوقت إعداد فقط، لا كتكلفة تحويل/تنظيف خط مستقلة بين المنتجات. التوصية: إضافة customer_id أساسي على الأمر + ترميز per-customer + تفعيل enum لأنواع الإنتاج.
جزئي
4 — تكاليف المخزون (Carrying/Ordering/Stockout, ROP, Safety Stock, Aging)
أين في النظام: BE: Modules/Inventory/app/Http/Controllers/ReorderAlertController.php (ROP + suggested_order_qty سطر 51/104)، InventoryReportController.php::slowMoving سطر 170-223 (المخزون الراكد بـlast_movement_date)، StockService (FIFO/WAC). Safety stock: Modules/Production StandardCostController::updateItemSetting (safety_stock/reorder_point على mfg_item_mrp_settings). FE: /factory/mrp + شاشات Inventory.
كيف يعمل اليوم: موجود: نقطة إعادة الطلب ROP (reorder_point على المنتج، ReorderAlertController يرصد ما دونها مع severity ويقترح كمية = max_stock − current). Safety Stock مُعرّف كحقل تخطيط على mfg_item_mrp_settings. المخزون الراكد/بطيء الحركة عبر slowMoving (منتجات بلا حركة منذ N يوم، افتراضي 90، مع days_since_movement). تقييم المخزون FIFO/WAC في StockService. movementSummary يعطي ملخص الحركة الافتتاحي/الوارد/المنصرف.
الناقص / التوصية: لا يوجد أي حساب فعلي لتكاليف المخزون الثلاث المطلوبة: Carrying/Holding cost (تكلفة الاحتفاظ) و Ordering cost (تكلفة الطلب) و Stockout cost (تكلفة نفاد المخزون) — بحث carrying/ordering_cost/stockout/holding_cost في Modules/Inventory لم يُرجع شيئاً. الكمية المقترحة لإعادة الطلب حسابية بسيطة (max−current) وليست EOQ (Economic Order Quantity) — لا توجد معادلة EOQ. الـAging موجود فقط كتصنيف "راكد/بطيء" بعتبة أيام، بلا جدول أعمار متدرّج (0-30/30-60/60-90/90+) ولا تكلفة محمّلة على التقادم. التوصية: إضافة محرّك EOQ، وحقول carrying/ordering rate، وتقرير aging متدرّج بقيمة مالية، وتقدير stockout cost.
جزئي
5 — التكاليف المعيارية (معيار/خامة، تحديث دوري، مقارنة، تجميد)
أين في النظام: BE: Modules/Production/app/Actions/RollUpStandardCost.php، StandardCostController.php (index/rollUp/updateItemSetting)، Models/MfgStandardCost.php (std_material/labor/overhead/total + last_rolled_at + update_frequency)، migration 2026_06_12_160000. المقارنة معياري/فعلي: ComputeOrderVariances (MPV/MUV/LRV). FE: /factory/standard-costs (standard-costs.component) + /factory/variances.
كيف يعمل اليوم: موجود: معيار لكل منتج (صف فريد company+product في mfg_standard_costs) بتقسيم مواد/عمالة/overhead، يُحدَّث عبر RollUpStandardCost (roll لمنتج واحد أو للكل من الـBOM النشط). المقارنة المعياري مقابل الفعلي مبنية بالكامل في محرّك الانحرافات ComputeOrderVariances (انحراف سعر المواد MPV، الاستخدام MUV، معدل العمالة LRV) مع workflow تحقيق. شاشة standard-costs تعرض المعايير وتتيح roll فردي/جماعي مع طابع last_rolled_at.
الناقص / التوصية: (1) المعيار على مستوى المنتج النهائي فقط (rolled-up)، وليس "معيار لكل خامة" مستقل قابل للتثبيت — تكلفة الخامة تُسحب لحظياً من المخزون عند الـroll، فلا يوجد سجل معيار سعري مجمّد لكل مادة خام. (2) update_frequency حقل نصّي مخزَّن فقط، لا يوجد job/scheduler يفرض التحديث الدوري تلقائياً — التحديث يدوي بزر roll. (3) لا يوجد تجميد معايير (Freeze/versioning): بحث freeze/frozen في BE وFE لم يُرجع آلية تجميد؛ كل roll يكتب فوق الصف (upsert) بلا إصدار محفوظ ولا قفل، فلا يمكن تثبيت معيار الفترة ومنع تعديله. التوصية: جدول معيار خامة منفصل، scheduler يحترم update_frequency، وآلية إصدارات/تجميد (frozen_at + نسخة الفترة) لمنع الكتابة فوق المعيار المعتمد.
جزئي
6 - تحليل الانحرافات (Variance Analysis)
أين في النظام: BE: Modules/Production/app/Actions/ComputeOrderVariances.php (يُستدعى عند إقفال أمر الإنتاج)، Modules/Production/app/Http/Controllers/VarianceController.php (GET production/variances + PATCH production/variances/{id}/status)، Enums/VarianceClassification.php، Models/MfgVarianceRecord.php. تقرير: ProductionReportController::variance (GET production/reports/variance). FE: /factory/variances (variances.component.ts/html) + تبويب الانحراف في /factory/reports.
كيف يعمل اليوم: المحرك يفكك الفرق بين الفعلي والمعياري لكل أمر إنتاج على المعيار القياسي إلى ست انحرافات: مواد سعر/كمية (MPV/MUV)، عمالة معدل/كفاءة (LRV/LEV)، أوفرهيد متغير إنفاق/كفاءة (VOSV/VOEV)، وأوفرهيد ثابت حجمي (FOVV اختياري ومرتبط بالموازنة). تصنيف F/UF يتم عبر إشارة amount (موجب = غير مواتٍ unfavorable). التصنيف ضمن نطاقات normal<2% / monitor 2-5% / investigate>5%، وعند investigate يُرفع حدث VarianceInvestigationRaised وإشعار، ويبدأ سير عمل تحقيق open→acknowledged→investigating→closed مع owner_role (purchasing/production/management) وختم المستخدم والوقت وملاحظة حل إلزامية عند الإغلاق. شاشة /factory/variances تعرض رسم Pareto حسب نوع الانحراف وإجماليات مواتية/غير مواتية وعدد التحقيقات وفلاتر حسب النوع والتصنيف وحالة سير العمل.
الناقص / التوصية: ثلاث فجوات مقابل المتطلب: (1) عتبة التنبيه في الكود 5% (investigate>5%) وليست 10% المطلوبة — تحتاج جعلها قابلة للضبط أو رفعها إلى 10%؛ (2) لا يوجد تقرير شهري مجدول/مجمّع للانحرافات — التقرير الحالي reports/variance حسب الطلب فقط وبمستوى الأمر الإجمالي (planned vs actual) وليس مفصّلًا بالأنواع الستة، ولا يوجد تجميع شهري أو cron؛ (3) ربط الانحراف بالسبب سطحي: يوجد owner_role وملاحظة حل نصية حرة فقط، بلا تصنيف منظّم لأسباب الجذر (reason taxonomy/codes) كما هو موجود في تنبيهات LIS. كما أن LEV قد يُدمج في LRV عند انعدام ساعات العمل (دين موثّق).
ناقص
7 - نقطة التعادل وتحليل CVP (Break-even & CVP)
أين في النظام: — لا يوجد. بحث grep عن break-even/breakeven/contribution-margin/cvp/margin-of-safety/operating-leverage/cm-ratio/what-if في كامل Modules/ (BE) وكامل src/app (FE) لم يُرجع أي نتيجة.
كيف يعمل اليوم: لا يوجد أي منطق لنقطة التعادل أو هامش المساهمة أو نسبة المساهمة (CM ratio) أو هامش الأمان (MOS) أو الرفع التشغيلي أو تحليل What-If، لا على مستوى المنتج ولا العميل. الموجود فقط هو تكاليف المعياري/الفعلي لأمر الإنتاج وربح المبيعات الإجمالي للمنتج، وكلاهما لا يفصل التكاليف الثابتة عن المتغيرة (شرط أساسي لـ CVP).
الناقص / التوصية: محور غائب بالكامل. يحتاج بناء: تصنيف التكاليف ثابت/متغير، حساب هامش المساهمة لكل منتج وعميل، نقطة التعادل (بالكمية والقيمة)، نسبة المساهمة، هامش الأمان، درجة الرفع التشغيلي، ومحرك What-If تفاعلي، مع شاشة FE جديدة (لا توجد ضمن /factory أو accounting).
جزئي
8 - هوامش الربح (Profit Margins)
أين في النظام: BE: Modules/Sales/app/Http/Controllers/SalesReportController.php::profitByProduct (GET sales/reports/profit-by-product) و SalesReportService.php::profitByProduct (سطور 422-462) — يحسب gross_profit و margin_percent من line_total - discount - total_cost(COGS). FE: شاشة تقارير المبيعات (sales reports). لا يوجد مكافئ في /factory/reports.
كيف يعمل اليوم: يوجد حساب هامش إجمالي (Gross Margin) فقط: الإيراد الصافي ناقص تكلفة البضاعة المباعة (COGS من total_cost في بنود الفاتورة)، ونسبة الهامش = gross_profit / revenue، على مستوى المنتج. تقرير المبيعات أيضًا يُرجع COGS وربح إجمالي في byProduct.
الناقص / التوصية: يوجد فقط الهامش الإجمالي على مستوى المنتج. مفقود: الهامش التشغيلي (Operating Margin) والصافي (Net Margin) — لا تخصيص للمصروفات التشغيلية/الإدارية على المنتج أو العميل؛ لا يوجد مخطط Waterfall لتفكيك الربح؛ لا يوجد Benchmark/مقارنة معيارية أو مقابل فترات. ولا يوجد هامش على مستوى أمر التول (الفاتورة تُنشأ مسودة فقط دون عرض هامش).
جزئي
9 - محرك التسعير (Pricing Engine)
أين في النظام: BE تسعير التول: Modules/Production/app/Actions/CreateTollFeeInvoice.php (POST production/orders/{order}/toll-invoice عبر ProductionOrderController::tollInvoice، سطر 107 routes/api.php)، إعداد production.toll_margin_percent. تسعير عام: Modules/Core ProductPricingTierController + ProductPricingTier (شرائح سعر للمنتج). FE: نموذج فاتورة التول في /factory/orders (production-orders.component.ts سطور 199-275 + tollInvoiceForm).
كيف يعمل اليوم: معادلة سعر التول موجودة: رسم/وحدة = fee_per_unit المُدخل يدويًا، أو افتراضيًا = (تكلفة التحويل/وحدة) × (1 + toll_margin_percent%)، حيث تكلفة التحويل/وحدة = (العمالة الفعلية + الأوفرهيد الفعلي) / الكمية المنتجة. النموذج في FE يطلب customer_id ويتيح تجاوز fee_per_unit واختيار tax_rate. كذلك يوجد نظام شرائح أسعار للمنتجات (ProductPricingTier) في Core.
الناقص / التوصية: المحرك بدائي ومخصص للتول فقط. مفقود: أنماط تسعير Per Unit/KG/Hour صريحة (الموجود وحدة واحدة فقط = الكمية المنتجة)؛ لا يوجد Floor Price (سعر أرضية يمنع البيع تحت التكلفة)؛ لا يوجد تسعير لكل عميل كقاعدة (customer_id يُختار وقت إصدار الفاتورة فقط ولا يُخزَّن على الأمر)؛ لا يوجد تحليل حساسية السعر (price sensitivity/What-If). toll_margin_percent إعداد عام واحد فقط دون تمييز حسب العميل أو المنتج.
ناقص
10 - ربحية العملاء (Customer Profitability)
أين في النظام: أقرب موجود: Modules/Sales/app/Services/SalesReportService.php::byCustomer (سطور 120-153، GET sales/reports/by-customer). لا يوجد أي تحليل ربحية عميل/ABC/cost-to-serve في BE أو FE (grep لم يُرجع نتائج).
كيف يعمل اليوم: تقرير byCustomer يُرجع لكل عميل: عدد الفواتير، الإيراد الإجمالي (gross_revenue = SUM total)، الرصيد المستحق (outstanding_balance)، وتاريخ آخر فاتورة، مرتبًا تنازليًا حسب الإيراد. أي أنه تقرير إيرادات/مديونية للعميل وليس ربحية.
الناقص / التوصية: ربحية العملاء بالمعنى المطلوب غير موجودة. byCustomer لا يطرح أي تكلفة (لا COGS ولا تكلفة خدمة) فهو إيراد فقط. مفقود بالكامل: تحليل ربحية العميل (إيراد − COGS − cost-to-serve)، تصنيف ABC للعملاء، حساب Cost-to-Serve (تكلفة الخدمة/التوصيل/التحصيل لكل عميل)، وترتيب أفضل/أسوأ العملاء ربحيًا. يحتاج بناء كامل مع شاشة FE جديدة.
جزئي
11) الطاقة الإنتاجية (Production Capacity)
أين في النظام: BE: Modules/Production/app/Actions/ComputeCrpLoads.php + Models/MfgCrpLoad.php (migration 2026_06_12_180004_create_mfg_crp_loads_table) — يُشغّل في ذيل RunMrp. ProductionCenter.php يحمل capacity_per_hour, daily_capacity, capacity_multiplier, efficiency_percent, utilization_percent, cost_per_hour, machine_cost_rate. FE: /factory/crp-board (crp-board.component.ts) مُسجّل في production-standalone.routes.ts:145.
كيف يعمل اليوم: محرك CRP يوزّع الحمل (setup + run×qty المشتق من الراوتنج) على أسابيع، ويحسب الطاقة المتاحة لكل مركز عمل من التقويم/daily_capacity مضروبة في الكفاءة والاستخدام، ثم نسبة الاستخدام utilization_pct وحالة overload(>100%)/ok/underload(<50%). يخصم أيضاً توقّف الصيانة (CMMS downtime) من الطاقة المتاحة. لوحة crp-board تعرض الأشرطة بألوان حسب الحالة (overload/underload). الطاقة القصوى لكل ماكينة موجودة كـ capacity_per_hour/daily_capacity والجدولة عبر التقويم والشفتات.
الناقص / التوصية: الناقص: (1) لا توجد حسبة لـ تكلفة الطاقة العاطلة (idle cost) صراحةً — لا يوجد idle_cost/under-applied-capacity variance رغم وجود cost_per_hour؛ حالة underload تُعرض كنسبة فقط بلا تحويلها لقيمة مالية. (2) لا يوجد تنبيه عطالة فعلي (alert/notification) — مجرد تلوين أشرطة على اللوحة، لا إشعار push/قائمة تنبيهات. (3) CRP مبني على راوتنج المنتجات فقط؛ منتج بلا راوتنج غير مرئي للطاقة (موثّق كدَيْن). (4) المقارنة أسبوعية للتخطيط فقط، لا OEE فعلي (متاح/مستغل/جودة) من الأرض. يُوصى بإضافة idle_capacity_cost = (available−required)×cost_per_hour وتنبيه عطالة عند underload متكرر، و OEE فعلي من التأكيدات.
جزئي
12) إدارة الفاقد والهالك (Scrap / Waste Management)
أين في النظام: BE: Modules/Production/app/Actions/ConfirmOperation.php (السطور 146-152: scrap_quantity, rework_quantity, reason_code) + migration 2026_06_12_150000_create_mfg_confirmation_tables (scrap_quantity, rework_quantity, reason_code nullable string). تقرير: ProductionReportController.php::summary (SUM(scrap_quantity)) و::variance. حساب الهالك: ProductionAccountResolver.php (production.scrap_account_id). FE: confirmations.component.ts:156-162 (حقول scrap/rework/reason).
كيف يعمل اليوم: عند تأكيد العملية يُسجّل المُشغّل كمية الهالك (scrap) وإعادة الشغل (rework) و reason_code كنص حر اختياري. يوجد حساب أستاذ scrap_account_id لترحيل تكلفة الهالك. تقرير الإنتاج يُجمّع إجمالي كمية الهالك على مستوى الأوامر ويعرضه في summary/variance مع كمية الهالك لكل أمر.
الناقص / التوصية: الناقص كبير: (1) لا يوجد تصنيف للفاقد بالمرحلة (stage) — الهالك يُسجّل على العملية لكن لا تصنيف مرحلي تحليلي. (2) reason_code نص حر وليس Enum/جدول lookup — لا يوجد ScrapReason enum (قائمة الـEnums لا تحوي RejectionReason/ScrapReason) فلا يمكن تقرير «أكثر الأسباب». (3) لا يوجد حقل «من يتحمل الفاقد» (المصنع/العميل في أوامر التول) أو تصنيف عادي/غير عادي (abnormal). (4) لا توجد مقارنة بمعيار <3% — لا حقل scrap tolerance/standard ولا تنبيه تجاوز. (5) لا يوجد تقرير تكلفة الفاقد بالقيمة المالية (التقرير يعرض الكمية فقط) ولا تقرير «أكثر الأسباب». يُوصى بـ ScrapReason enum + جدول تصنيف، حقل bears_cost (factory/customer)، عمود standard_scrap_pct + تنبيه، وتقرير cost-of-scrap بالقيمة.
جزئي
13) الموازنة التخطيطية (Planning Budget)
أين في النظام: BE: Modules/Accounting (Models/Budget.php, BudgetLine.php; Services/BudgetService.php::getBudgetVsActual/checkAlert/distributeEvenly; Http/Controllers/BudgetController.php::vsActual). Schema: budget_lines يحمل account_id + cost_center_id + annual_amount + m1..m12 (توزيع شهري). FE: features/budgets/budgets.component.ts (207 سطر، CRUD أساسي) + features/reports (loadBudgetVsActual، tab 6 Budget vs Actual) عبر budget.service.ts::vsActual.
كيف يعمل اليوم: موازنة سنوية مربوطة بـ fiscal_year، كل بند على account_id (+cost_center اختياري) مع توزيع شهري m1..m12 ودالة distributeEvenly للتوزيع المتساوي. getBudgetVsActual يقارن المبلغ المخطط مقابل الفعلي المسحوب من JournalEntryLine شهرياً ويحسب variance و variance_percentage. checkAlert يكشف تجاوز الفعلي للموازنة لشهر معيّن. تقرير Budget vs Actual معروض في شاشة التقارير.
الناقص / التوصية: الناقص: (1) الموازنة على مستوى الحساب/مركز التكلفة فقط — لا يوجد بُعد لكل عميل أو لكل منتج (لا partner_id/product_id على budget_lines)، وهو جوهر متطلب «موازنة لكل عميل/منتج» في تصنيع التول. (2) لا يوجد Re-forecasting فعلي — يوجد BudgetType::Revised كحالة لكن لا آلية إعادة توقّع تلقائية بناءً على الفعلي. (3) «تحليل الأسباب» للانحراف غير موجود (حقل سبب/تعليق على الانحراف) — فقط رقم variance. (4) شاشة budgets نفسها CRUD بسيط لا تعرض vs-actual داخلها (المقارنة في شاشة التقارير فقط). يُوصى بإضافة بُعدي customer/product للبنود، وحقل سبب انحراف، ودورة re-forecast.
جزئي
14) إدارة عقود التول (Toll Contract Management)
أين في النظام: BE: ProductionOrder.php::isToll() (material_ownership='customer') + أعمدة production_type/material_ownership/order_type/wip_account_id (migration 2026_06_12_120000_production_order_state_machine_v2). Actions/CreateTollFeeInvoice.php (رسوم التحويل) + ProductionOrderController.php:677 (raise toll fee). إعداد production.toll_margin_percent. FE: production-orders.component.ts:198-273 + 1209 (نموذج فاتورة رسوم التول على شاشة الأوامر).
كيف يعمل اليوم: أمر التول يعمل على خامة مملوكة للعميل (يتخطى الحجز، حركات مخزون بلا GL، تسوية تكلفة التحويل لحساب Toll Clearing). عند الإكمال تُرفع فاتورة مبيعات برسوم التحويل = (العمالة+التكاليف غير المباشرة)/المنتَج × (1 + toll_margin_percent) ما لم يُمرَّر fee_per_unit صراحةً. الهامش يأتي من إعداد عام production.toll_margin_percent. الواجهة تتيح إصدار فاتورة الرسوم باختيار العميل و fee_per_unit الاختياري.
الناقص / التوصية: الناقص جوهري: (1) لا يوجد كيان «عقد تول» (لا جدول toll_contract ولا بنود عقد) — العلاقة تُدار على مستوى الأمر الفردي فقط؛ لا بنود تعاقدية (سعر متفق، حد أدنى كميات، شروط). (2) لا مقارنة التكلفة الفعلية مقابل المتعاقد عليها (لا سعر متعاقد مخزّن للمقارنة). (3) لا يوجد تنبيه هبوط الهامش — toll_margin إعداد عام ثابت، بحث margin drop/alert لم يُرجِع شيئاً في Production. (4) لا تجديد عقد ولا تقرير ربحية العقد (الربحية على مستوى الأمر ضمنياً فقط). كذلك دعم الخامة الجزئية من العميل غير مبني (full-toll فقط، موثّق). يُوصى ببناء كيان TollContract كامل (بنود، سعر متعاقد، تواريخ تجديد، هامش لكل عقد، تنبيه هبوط الهامش، تقرير ربحية).
جزئي
15) إدارة الموردين (Supplier Management)
أين في النظام: BE: Modules/Purchases (Models/SupplierPriceList.php; migration 2026_02_25_700001_create_supplier_price_lists_table: partner_id+product_id+price+currency_id+min_quantity+lead_time_days+valid_from/valid_until+is_active+last_updated_at). SupplierPriceListController.php::compare (السطر 229، يعلّم is_best_price للأرخص الساري) + bulkImport. FE: features/purchases/supplier-prices/supplier-prices.component.ts (193 سطر، CRUD سعر/مورد/منتج/فترة صلاحية) عبر supplier-price.service.ts.
كيف يعمل اليوم: لكل مورد سعر لكل خامة (partner_id × product_id × variant × unit) مع عملة وحد أدنى كمية ومهلة توريد وفترة صلاحية valid_from/until و is_active، وقيد فريد يمنع التكرار. نقطة compare ترتّب أسعار منتج معيّن عبر الموردين وتعلّم الأرخص الساري كـ is_best_price (أفضل مورد). شاشة supplier-prices تدير CRUD الأسعار وتعرض فترة الصلاحية.
الناقص / التوصية: الناقص: (1) تاريخ الأسعار غير محفوظ كسجلّ تاريخي — لا يوجد جدول price_history (البحث لم يُرجِع شيئاً)؛ التعديل يكتب فوق السعر مع last_updated_at فقط، فلا تتبّع تطوّر السعر زمنياً. (2) تنبيه ارتفاع السعر غير موجود (لا spike/increase alert في الكنترولر). (3) ربط الجودة بالفاقد للمورد غير موجود إطلاقاً (لا quality/scrap-by-supplier — البحث فارغ) — لا يمكن قياس أثر جودة المورد على الفاقد. (4) شاشة المقارنة compare غير مستهلكة في الواجهة (لا استدعاء /compare في supplier-price.service ولا زر مقارنة في الـUI) رغم توفّرها بالـBE. يُوصى بجدول price_history + تنبيه ارتفاع السعر + ربط defect/scrap rate بالمورد + ربط شاشة المقارنة بالواجهة.
جزئي
16 - تكاليف الجودة والامتثال (Cost of Quality & Compliance)
أين في النظام: FE: /qms/inspections, /qms/ncr, /qms/reports (src/app/features/qms/*). BE: Modules/QMS — QmsInspectionController, QmsNonConformanceController, QmsCapaController, QmsReportController (routes: inspections, non-conformances, capa-actions, reports/defect-rate|ncr-summary|capa-effectiveness). Batch expiry: Modules/Production MfgBatch.expiry_date. Rework/scrap: Modules/Production ConfirmationController (scrap_quantity, rework_quantity) + ProductionReportController.
كيف يعمل اليوم: توجد منظومة جودة كاملة (خطط فحص، فحوصات، عدم مطابقة NCR بتدفق investigate→issue-capa→close، إجراءات CAPA، تقييم موردين، تقارير معدل العيوب). الفحص يحمل رقم تشغيلة كنص حر (batch_number) ويدعم تكرار PerBatch. الإنتاج يسجل كميات الإعادة (rework_quantity) والهالك (scrap_quantity) في التأكيدات ويجمعها في تقرير الإنتاج. تتبّع التشغيلة وتاريخ الانتهاء (shelf life) موجود في MfgBatch مع شجرة الأنساب (genealogy).
الناقص / التوصية: لا يوجد تصنيف تكلفة الجودة (Prevention/Appraisal/Internal+External Failure) إطلاقاً — لا حقول تكلفة في QMS ولا في NCR/CAPA/Inspection. تكلفة اختبارات المعمل (Lab) غير مرتبطة. لا ربط بين NCR ورقم التشغيلة الفعلي (mfg_batch FK) — فقط نص حر. لا توجد شهادات/امتثال HACCP/ISO/GMP/حلال (لا حقول ولا نماذج). لا تكلفة مالية لإعادة الإنتاج (الكمية تُسجّل لكن لا تُسعّر كتكلفة فشل داخلي). لا ربط للرانة (التشغيلة) بشهادة. المطلوب: جدول cost-of-quality بفئاته الأربع، ربط NCR/CAPA بأمر الإنتاج والتشغيلة + احتساب تكلفتها، وحدة شهادات/امتثال مع ربطها بالتشغيلة.
ناقص
17 - تكاليف سلسلة التوريد (Supply Chain / Landed Cost)
أين في النظام: Modules/Purchases (PurchaseOrder, GRN, Bill controllers) — لا يوجد. Modules/Inventory StockService (FIFO/WAC) — لا توجد مكوّنات تكلفة إضافية. Accounting CoA لديه فقط حسابات Utilities/Factory Utilities كحسابات عامة.
كيف يعمل اليوم: لا يوجد أي تطبيق فعلي. بحث في Modules/Purchases و Inventory عن landed_cost / freight / customs / insurance / clearance / additional_cost لم يُرجع أي نتيجة. الشراء يسجّل سعر الصنف فقط، وتكلفة المخزون تُحسب من سعر الفاتورة دون توزيع مصاريف الشحن/الجمارك/التأمين عليها.
الناقص / التوصية: غياب كامل لمنظومة Landed Cost: لا توزيع لشحن الخامات أو الجمارك أو التأمين أو تكلفة توصيل المنتج على تكلفة الصنف/المخزون. لا حقل لمسؤولية اللوجستيك في العقد (Incoterms). المطلوب: نموذج تكاليف إضافية على أمر الشراء/إذن الاستلام مع قواعد توزيع (بالقيمة/الوزن/الكمية) تُرحّل إلى تكلفة المخزون، وحقول Incoterms ومسؤولية الطرف في عقد التصنيع للغير.
جزئي
18 - تكاليف الموارد البشرية (HR Cost Allocation)
أين في النظام: BE: Modules/HRM PayrollAccountingService (postPayroll/buildJournalLines), PayrollItem (overtime_hours, overtime_amount), Attendance (overtime_hours, leave). Production: مركز التكلفة على ProductionCenter (cost_center_id, labor_cost_rate). Training: Modules/HRM TrainingProgram/TrainingSession.
كيف يعمل اليوم: الرواتب تُحتسب وتُرحّل لقيد محاسبي بحسابات فرعية لكل موظف (Salary Expense / Payable). الأوفرتايم يُحسب على مستوى عنصر الراتب (overtime_hours/overtime_amount) ومن الحضور. الإنتاج لديه labor_cost_rate ومركز تكلفة على مركز الإنتاج، وتكلفة العمالة المباشرة تدخل أمر الإنتاج (Job-Order). برامج التدريب موجودة كنماذج.
الناقص / التوصية: PayrollAccountingService يُرحّل كامل مصروف الرواتب إلى حساب واحد (hrm.salary_expense_account_id) دون أي تقسيم على مراكز التكلفة — لا توزيع رواتب على مراكز التكلفة في القيد. الأوفرتايم لا يُربط بأمر إنتاج محدد (يبقى على مستوى مسير الراتب). لا توجد حقول تكلفة للتدريب إطلاقاً (TrainingProgram/Session بلا cost/fee/budget). لا احتساب لتكلفة الغياب، ولا نسبة عمالة مباشرة/غير مباشرة. المطلوب: توزيع بنود الراتب على مراكز التكلفة في القيد، ربط أوفرتايم الإنتاج بالأمر، حقول تكلفة التدريب، ومؤشر مباشر/غير مباشر.
ناقص
19 - تكاليف الطاقة والمرافق (Energy & Utilities)
أين في النظام: Modules/Production ProductionCenter (machine_cost_rate, overhead_rate, cost_driver) — تحميل عبء فقط. Accounting/Actions/ImportCoaTemplate (حسابات 5203 Utilities, 5404 Factory Utilities) — حسابات GL فقط. لا تطبيق لقياس طاقة.
كيف يعمل اليوم: لا يوجد قياس فعلي للطاقة. الموجود هو معدل عبء/معدل ماكينة (machine_cost_rate, overhead_rate) على مركز الإنتاج يُمتص ضمن تكاليف أمر الإنتاج بطريقة محرّك التكلفة (cost_driver) — أي تحميل تقديري وليس فاتورة فعلية. وحسابات GL للمرافق (مصروف المرافق / مرافق المصنع) في دليل الحسابات لاستقبال الفواتير محاسبياً فقط.
الناقص / التوصية: لا قياس كهرباء لكل ماكينة، ولا توزيع استهلاك الطاقة على الأوامر بناءً على عدّادات/ساعات تشغيل، ولا غاز/مياه منفصلة، ولا تحليل فاتورة المرافق (تباين الاستهلاك مقابل المعياري). بحث energy/electricity/kwh/utility في Production و Accounting لم يُرجع أي منطق قياس. المطلوب: نموذج قراءات عدّادات لكل ماكينة/مركز، قاعدة توزيع الطاقة على الأوامر، وتحليل فاتورة المرافق مقابل التحميل.
جزئي
20 - دورة حياة الأصول (Asset Lifecycle / TCO / Make-or-Buy)
أين في النظام: BE: Modules/CMMS — CmmsAsset (purchase_cost, warranty_expiry, category, parent/child), CmmsWorkOrder (parts/labor totalCost, downtime_hours, failure_code), CmmsReportController (breakdowns/MTBF, costAnalysis by asset/category/month, pm-compliance). Accounting FixedAsset (depreciation, dispose, sell, RunDepreciation). FE: /cmms/assets, /cmms/work-orders, /cmms/reports + /fixed-assets.
كيف يعمل اليوم: CMMS يتتبع الأصل (سعر الشراء، الفئة، التسلسل الهرمي) وأوامر العمل الوقائية/التصحيحية مع تكلفة قطع غيار + عمالة (totalCost) وساعات التوقف وكود العطل والسبب الجذري. التقارير تعطي MTBF، تكرار الأعطال، وتحليل تكلفة الصيانة لكل أصل/فئة/شهر. وزمن الإهلاك وبيع/استبعاد الأصل موجود في Accounting FixedAsset مع RunDepreciation.
الناقص / التوصية: لا توجد تكلفة ملكية إجمالية موحّدة (TCO): أصل CMMS غير مرتبط بأصل Accounting FixedAsset (لا FK)، فالإهلاك في وحدة وتكلفة الصيانة في أخرى دون تجميع. لا تحليل جدوى استبدال (replacement feasibility). لا ربط لصيانة CMMS بأمر الإنتاج/التوقف عن الإنتاج (CmmsWorkOrder لا يحمل production_order_id — يقيس downtime_hours فقط دون أثر تكلفة الإنتاج). لا توجد منطقية Make-or-Buy إطلاقاً (لا نتائج بحث). المطلوب: ربط CmmsAsset↔FixedAsset لتجميع TCO (شراء+إهلاك+صيانة+طاقة+توقف)، نموذج جدوى الاستبدال، ربط أمر العمل بأمر الإنتاج، ومحرّك Make-or-Buy يقارن تكلفة التصنيع الداخلي مقابل الشراء/التعاقد.
جزئي
21 - مراكز التكلفة (Cost Centers)
أين في النظام: BE: Modules/Accounting/CostCenterController (CRUD + tree) + ReportController::costCenterReport (routes/api.php:244 `reports/cost-center/{id}`) + budgetVsActual. ربط مركز الإنتاج بمركز التكلفة: production_centers.cost_center_id (migration 2026_06_12_120000) + ProductionCenter::costCenter(). توزيع التكلفة فعلياً: Listeners/PostConfirmationJournals.php يختم cost_center_id على سطور WIP/Applied. FE: /accounting cost-centers (features/cost-centers) + /factory/centers
كيف يعمل اليوم: شجرة مراكز تكلفة محاسبية كاملة (CRUD + tree). كل مركز إنتاج يُربط بمركز تكلفة عبر cost_center_id، وعند ترحيل قيود التأكيد (PostConfirmationJournals) يُختم cost_center_id على سطور WIP والتحميل، فتتجمّع التكاليف فعلياً على المركز. يوجد تقرير لمركز واحد عبر فترة (transactions + total_debit/credit/net) وتقرير Budget vs Actual للموازنة.
الناقص / التوصية: النواقص: (1) أنواع المراكز الوظيفية المطلوبة (خلط/تعبئة/تغليف/جودة/مخازن/إدارة) غير موجودة — ProductionCenterType محصور في machine/labor/mixed فقط، فلا تصنيف خلط/تعبئة/جودة جاهز. (2) لا يوجد تقرير شهري مُجمّع يعرض كل المراكز جنباً إلى جنب (costCenterReport يخدم مركزاً واحداً فقط). (3) لا توجد مقارنة بالمعيار على مستوى المركز (المقارنة المعيارية موجودة على مستوى الأمر في ComputeOrderVariances وليس المركز). (4) لا تقرير «المراكز الأعلى تكلفة» (ranking). (5) شاشة /factory لا تعرض تقرير مركز التكلفة — يجب الذهاب لشاشة المحاسبة. يُنصح بإضافة center_type وظيفي + تقرير ranking شهري متعدد المراكز مع عمود المعيار/الانحراف.
ناقص
22 - مؤشرات الأداء KPIs Dashboard
أين في النظام: FE: /factory (features/production/factory-dashboard/factory-dashboard.component.ts، 380 سطر). BE: Modules/Production/ProductionReportController::summary (يرجع costs.planned/actual + quantity.scrap). مصادر الداشبورد: ProductionOrderService/ProductionCenterService/BomService فقط.
كيف يعمل اليوم: الداشبورد الحالي بلاطات عدّ أوامر حسب الحالة (planned/released/in_process/completed) + رسم بياني للحالات + عدّ المراكز النشطة وعدد BOM فقط. summary endpoint في الباك يحسب فعلياً تكاليف مخططة/فعلية وكمية scrap لكن الداشبورد لا يستهلكها.
الناقص / التوصية: غياب شبه كامل لمؤشرات الأداء المطلوبة: لا تكلفة وحدة، لا نسبة فاقد (scrap موجودة بالباك لكن غير معروضة كـ KPI)، لا استغلال طاقة (utilization_percent موجود على المركز لكن غير مُجمّع في KPI)، لا Gross/Net margin، لا MOS، لا ROP (بيانات ROP موجودة في Inventory ReorderAlertController لكن غير مربوطة بالداشبورد)، لا «ربحية أضعف عميل» (لا يوجد ربط عميل أصلاً)، لا «تكلفة مركز الخلط». ولا توجد أهداف (targets) ولا حدود تنبيه (thresholds) في أي مكان. يجب بناء KPI endpoint مُجمّع + لوحة تنفيذية تستهلك summary + reorder-alerts + بيانات الطاقة مع أهداف/حدود.
جزئي
23 - التقارير المطلوبة
أين في النظام: BE: Modules/Production/ProductionReportController (summary, variance, efficiency فقط — routes/api.php:145-147). Accounting/ReportController (costCenterReport, budgetVsActual). Inventory ReorderAlertController (reorder-report, stats). FE: /factory/reports (production-reports.component) بثلاث تبويبات: Summary/Efficiency/Variance.
كيف يعمل اليوم: متاح فعلياً: تقرير ملخص الأمر/الحالات + الكميات + التكاليف، تقرير الانحرافات (variance) على مستوى الأمر، تقرير الكفاءة، تقرير مركز التكلفة وBudget vs Actual (محاسبة)، تقرير مستويات المخزون/إعادة الطلب (Inventory). شاشة /factory/reports تجمع 3 تبويبات.
الناقص / التوصية: مفقود من القائمة المطلوبة: لا تقسيم يومي/أسبوعي/شهري/ربع-سنوي (التقارير لقطة حسب الفترة فقط). لا تقرير ربحية العملاء (لا ربط عميل). لا نقطة تعادل (break-even). لا Cost of Quality إطلاقاً (لا وجود لمصطلح CoQ في أي موديول رغم وجود QMS). لا Dashboard تنفيذي. لا YoY ولا دورة حياة الماكينات ولا Aging ولا أداء الموردين كتقارير إنتاج. لا تقرير «مراجع خارجي». والأهم: شاشة /factory/reports لا تحتوي زر تصدير (لا Excel/PDF في component أو html) رغم توفّر ExportService في الـ core. يُنصح ببناء حزمة تقارير دورية مجدولة + تقارير ربحية عميل/مورد + CoQ + إضافة أزرار التصدير لشاشة التقارير.
جزئي
24 - تكاملات النظام
أين في النظام: BE: Actions/IssueMaterials + StockService (auto-deduct)، ConfirmOperation (labor من ساعات التأكيد + hook HRM piecework عبر RecordPieceworkEntry السطر ~971)، PostConfirmationJournals/ReceiveFinishedGoods/CloseProductionOrder (قيود تلقائية)، purchases تغذّي تكلفة المواد عبر StockService/WAC. FE: core/services/export.service.ts (exportExcel/exportPdf).
كيف يعمل اليوم: يعمل فعلياً: الخصم التلقائي للمخزون عند صرف المواد (IssueMaterials عبر StockService بـ FIFO/WAC)؛ القيود التلقائية من الأمر (سلسلة Listeners + Actions تُرحّل WIP/Applied/Settlement تلقائياً)؛ تكلفة المواد تأتي من المشتريات عبر تكلفة المخزون؛ تكامل HR جزئي عبر hook قطعة-عمل (piece-rate) يستدعي HRM\Actions\RecordPieceworkEntry عند تأكيد العملية لو الموظف مربوط بالمستخدم؛ تصدير Excel/PDF متاح عبر ExportService مستخدَم في شاشات centers/boms/orders/confirmations.
الناقص / التوصية: النواقص: (1) الحضور من HR غير مدمج فعلاً — تكلفة العمالة تُحسب من ساعات التأكيد اليدوية × المعدّل، وليس من سجلات حضور/timesheet من HRM؛ الـ hook الموجود piecework فقط ومُحاط بحراسة (يتجاهل صامتاً لو لا يوجد جدول/ربط). (2) المبيعات غير مربوطة بالإنتاج — لا customer_id ولا sales_order_id على ProductionOrder (toll مجرد flag material_ownership='customer' بلا عميل/أمر بيع)، فلا تتبّع ربحية عميل ولا تكلفة فعلية مقابل سعر التشغيل. (3) الجودة لا تُحدّث التكلفة — QMS موجود (Inspection) لكن لا ربط يُسقط تكلفة الرفض/إعادة العمل على الأمر (لا CoQ). (4) لا تكامل Power BI / OData / API تحليلي خارجي إطلاقاً (لا أثر له في أي موديول). (5) التصدير غير متوفّر على شاشة التقارير /factory/reports نفسها. يُنصح بربط عميل/أمر بيع بأمر الإنتاج، استهلاك حضور HRM في تكلفة العمالة، ربط QMS بالتكلفة، وإضافة طبقة تصدير/تكامل تحليلي.
جزئي
25 الامتثال والمراجعة (Audit Trail / قفل الفترات / أرشيف / Recall)
أين في النظام: BE: app/Traits/Auditable.php (spatie/laravel-activitylog عبر BaseModel) + Modules/Core/app/Http/Controllers/ActivityLogController.php (GET /api/activity-log, /api/activity-log/export) + Modules/Accounting/app/Actions/{CloseFiscalPeriod,SoftCloseFiscalPeriod,ReopenFiscalPeriod}.php + Modules/Accounting/app/Http/Controllers/FiscalPeriodController.php (POST fiscal-periods/{period}/reopen). FE: لا توجد شاشة Audit Trail إطلاقًا (لا activity-log في nav-items.config.ts ولا features/activity).
كيف يعمل اليوم: كل create/update/update على الكيانات المحاسبية يُسجَّل تلقائيًا في activity_log عبر trait Auditable مع لقطة before/after (logOnlyDirty) ويشمل المستخدم والتوقيت — والسجل للقراءة فقط (read-only، مطلوب لـ SOCPA/ZATCA). قفل الفترات موجود فعليًا: CloseFiscalPeriod + SoftCloseFiscalPeriod، وأي قيد في فترة مقفلة يُرفض. إعادة الفتح متاحة عبر ReopenFiscalPeriod (تُرفض إذا كانت السنة المالية مقفلة، فيجب فتح السنة أولًا) وتُسجَّل تلقائيًا في الـ activity log كتغيير status.
الناقص / التوصية: ثلاث ثغرات: (1) لا توجد شاشة Audit Trail في الواجهة — الـ endpoint قائم في الباك إند لكن لا واجهة تعرضه أو تصدّره للمراجع، فالأكسس عمليًا غير متاح للمستخدم. (2) ReopenFiscalPeriod لا يلتقط حقل سبب إلزامي عند فتح الفترة للمدير — يغيّر status فقط بدون reason، بينما الوثيقة تشترط فتح الفترة للمدير بسبب موثّق. (3) لا يوجد سجل Recall للرانات (استدعاء/سحب الدفعات) ولا أرشيف دائم مخصص؛ الاعتماد على activity_log العام فقط دون آلية Recall منفصلة. مطلوب: شاشة Audit FE + حقل reason إلزامي على reopen يُمرَّر للـ activity log + كيان/سجل Recall مستقل.
جزئي
26 صلاحيات المستخدمين (6 أدوار حوكمة التكاليف)
أين في النظام: BE: Modules/Production/database/seeders/ProductionRoleSeeder.php (الأدوار الستة المزروعة) + spatie/laravel-permission. FE: src/app/features/roles/roles.component.ts (إدارة أدوار عامة بصلاحيات).
كيف يعمل اليوم: مزروع فعلًا 6 أدوار مصنع مع مصفوفة صلاحيات دقيقة وidempotent: production_planner، production_supervisor، machine_operator، warehouse_storekeeper، quality_inspector، cost_accountant. النظام يقوم على RBAC حقيقي (Spatie) مع permission gates على الـ controllers و data_scope على الأدوار، وكل دور له home_page. دور cost_accountant فعلًا read-only للتكاليف (production.costing + reports + orders.view + mrp.view بدون أي mutation) — يطابق روح 'محاسب لا يعدل المعايير'.
الناقص / التوصية: الأدوار الستة المزروعة هي أدوار تشغيل أرضية المصنع وليست أدوار حوكمة التكاليف الستة المطلوبة في الوثيقة. مطابقة دقيقة: 'محاسب تكاليف لا يعدل المعايير' ≈ cost_accountant (مطابق تقريبًا، لكن لا يوجد منع صريح من تعديل StandardCost — يعتمد على غياب صلاحية الكتابة فقط). الأدوار الناقصة كليًا: (1) مدير تكاليف كامل (full cost manager) — غير موجود كدور مسمّى. (2) مشرف إنتاج لا يرى التكاليف — production_supervisor الحالي بلا production.costing فيخفي التكاليف فعليًا، لكن لا يوجد إخفاء UI صريح للهوامش/التكاليف. (3) مدير عام قراءة فقط (GM read-only لكل شيء) — غير موجود. (4) مدير مشتريات لا يرى الهوامش — غير موجود. (5) مراجع خارجي بوصول مؤقت + Audit Trail — غير موجود (لا آلية صلاحية مؤقتة time-boxed ولا ربط بشاشة Audit). مطلوب: إضافة هذه الأدوار الأربعة، وميزة وصول مؤقت للمراجع، وإخفاء أعمدة التكلفة/الهامش في الواجهة حسب الدور.
جزئي
27 التنبيهات الذكية (9 تنبيهات)
أين في النظام: BE موجود: Modules/Inventory/app/Notifications/ReorderAlertNotification.php + ReorderAlertController.php؛ Modules/Production/app/Notifications/ToolLifeExceededNotification.php + Listeners/NotifyToolLifeExceeded.php؛ Modules/Production/app/Notifications/VarianceInvestigationNotification.php + Listeners/RaiseVarianceInvestigation.php. FE: src/app/features/reorder-alerts/. الباقي: —
كيف يعمل اليوم: ثلاثة تنبيهات فقط من التسعة مبنية فعليًا: (أ) خامة تحت ROP عبر ReorderAlertNotification + شاشة reorder-alerts في الواجهة. (ب) تجاوز عمر الأداة (ToolLifeExceeded) يُرسَل لمستلمي الصيانة/الأدمن عند قلب الأداة لـ maintenance. (ج) انحراف الأمر — VarianceInvestigationNotification يُطلَق عند إغلاق أمر إنتاج بانحرافات مصنّفة investigate ويوجَّه للمسؤول. آلية الإشعار قائمة على Laravel Notifications مع resolveRecipients.
الناقص / التوصية: ستة تنبيهات من التسعة مفقودة كليًا، وواحد ناقص: تنبيه 'أمر تجاوز 10%' غير مربوط بعتبة 10% صريحة — VarianceInvestigationNotification يُطلَق على التصنيف investigate وليس على نسبة 10% مضبوطة. المفقود تمامًا: (1) فاقد >3%، (2) هامش عميل هبط، (3) طاقة عاطلة (idle capacity — رغم وجود CRP loads لا يوجد تنبيه)، (4) عقد قارب الانتهاء، (5) Shelf Life قارب الانتهاء، (6) سعر مورد ارتفع، (7) انحراف موازنة (budget variance). grep لم يجد أي listener/notification لهذه الأنواع. مطلوب: محرك قواعد تنبيهات مع عتبات قابلة للضبط (10%/3%) + 6 إشعارات جديدة + لوحة تنبيهات موحّدة في الواجهة.
ناقص
28 ميزات الذكاء الاصطناعي (6 ميزات تكاليف)
أين في النظام: BE: Modules/Core/app/Services/AiChatService.php + AiSettingsService.php + AiUsageService.php + Controllers/{AiChat,AiSetting,AiUsage,AiPreference}Controller.php (مساعد DeepSeek/GPT عام). FE: src/app/features/ai-settings/ + shared/components/ai-assistant/ + core/services/{ai-assistant,ai-cost-tracker,hr-ai}.service.ts. أما ميزات تكاليف التصنيع الستة: —
كيف يعمل اليوم: الموجود هو مساعد محادثة عام (AI chat assistant) مبني على مزوّد LLM خارجي (DeepSeek/OpenAI) مع تخزين مؤقت للردود (AiResponseCache)، حد توكنات شهري، تتبع الاستهلاك والتكلفة (AiUsageLog بالدولار والجنيه)، وتفضيلات لكل مستخدم/شركة. لا يوجد أي ربط لهذا المحرك بمنطق التكاليف أو الإنتاج.
الناقص / التوصية: أيٌّ من ميزات الذكاء الاصطناعي الست المطلوبة غير موجود: (1) توقع تكلفة الأمر، (2) اكتشاف أنماط غير طبيعية (anomaly detection)، (3) جدولة ذكية (smart scheduling)، (4) التنبؤ بالفاقد، (5) تسعير ذكي، (6) توقع احتياج المخزون. grep على الإنتاج/المخزون لم يجد أي forecast/predict/anomaly/ML model. البنية القائمة (LLM chat + usage tracking) يمكن إعادة استخدامها كطبقة عرض، لكن النماذج التنبؤية ومنطق التكاليف الذكي غير مبنيين. مطلوب: بناء خدمات تنبؤ مخصّصة (قد تستفيد من LLM للتفسير) مربوطة بـ ProductionOrder/StandardCost/StockService، أو نماذج إحصائية للفاقد والاحتياج.
📘 ملحق: الدليل العملي — إيه اللي اتغيّر وتعمل إيه
إجابة سؤال «مش شايف فرق»: التغييرات الكبرى للإصلاح كلها داخل شاشات /factory. اعمل Ctrl+Shift+R أول مرة لمسح الكاش، وروح للأماكن دي:
1) لوحة قيادة الأمر (Order Cockpit) — شاشة الأمر الواحدة المسار: /factory/orders/:id (تفتح من قائمة الأوامر /factory/orders بالضغط على رقم أي أمر). الملفات: order-cockpit.component.ts / .html — تستهلك ProductionOrderService (getById, readiness, getCosting, journalEntries, pegging) و BatchService.
قبل: كان أمر الإنتاج مجرد سطر في جدول. علشان تعرف إيه الخطوة اللي بعدها كنت بتلف على شاشات متفرقة (المواد، الإصدار، الصرف، التأكيدات) ومش واضح هو واقف فين ولا ناقصه إيه. بعد: كل أمر بقى له شاشة قيادة كاملة فيها كل حاجة في مكان واحد. الخطوات العملية: (1) ادخل /factory/orders واضغط على رقم الأمر. (2) فوق هتلاقي الـ Stepper — 5 محطات: مخطط ← مُصدَر ← قيد التشغيل ← مكتمل ← مقفول، والمحطة الحالية مميزة والمحطات اللي عدت عليها عليها علامة صح. (3) تحت الـ Stepper في زر واحد كبير «الخطوة التالية» بيتغير حسب حالة الأمر: لو مخطط يبقى «إصدار»، لو مُصدَر يبقى «صرف المواد»، لو قيد التشغيل يبقى «تسجيل تشغيلة» (+ «استلام منتج تام»)، لو مكتمل يبقى «إقفال». انت بس اضغط الزر الكبير ومتفكرش في الحالة. (4) تبويب «المواد» بيوريك إشارات مرور جاهزية كل مادة: أخضر = متاح، أصفر = منتظر توريد، أحمر = ناقص — ومع الناقص بيظهر «تلميح التوريد» (chips) بأرقام أوامر شراء/إنتاج تغطّي النقص تقدر تضغط عليها وتفتحها. (5) لو ضغطت «إصدار» والمواد فيها ناقص، بوابة الإصدار الذكية بتفتح ديالوج بقائمة الناقص وتسألك «تصدر برغم النقص؟» — يعني مش هتصدر أمر مش جاهز بالغلط. (6) تبويب «شجرة التغذية (Pegging)» بيوريك مين بيغذّي الأمر (موردين المكونات) ومين بيستهلك ناتجه (الأوامر الأب) + طلبات البيع المرتبطة، وكل بطاقة تنقلك لقمرة الأمر التاني. باقي التبويبات: نظرة عامة، العمليات، التكلفة (مخطط/فعلي/انحراف)، القيود المحاسبية، التشغيلات (Batches).
النتيجة: النتيجة المتوقعة: تفتح أي أمر وتعرف فورًا هو واقف فين، إيه الزر الواحد اللي تضغطه دلوقتي، وإيه المواد الناقصة قبل ما تصدّر. نصيحة: اعتمد على الزر الكبير الواحد كـ «المرجع» لكل أمر، وقبل أي إصدار افتح تبويب المواد بُص على إشارات المرور — لو فيه أحمر استخدم تلميح التوريد بدل ما تصدّر وتقف بعدين.
2) قمرة التخطيط (MRP Cockpit) المسار: /factory/mrp. الملفات: mrp/mrp-cockpit.component.ts / .html — تستهلك MrpService (getKpis, listRuns, getRun, run, firmPlannedOrder, convertPlannedOrder, convertAll, listMissingParts).
قبل: تخطيط الاحتياجات كان عملية يدوية مبعثرة؛ بتطلّع المقترحات وتحوّل كل واحد لوحده ومش واضح إيه الأهم ولا الترتيب الصح. بعد: شاشة تخطيط واحدة فيها KPIs + مقترحات مرتّبة + تحويل جماعي. الخطوات العملية: (1) ادخل /factory/mrp. فوق هتلاقي 4 بطاقات KPI: الطلب المفتوح من المبيعات، الأوامر المتأخرة (بتولّع أحمر لو فيه)، أوامر ناقصها مواد (بتولّع أحمر)، وأعلى حِمل على مركز شغل خلال 7 أيام. (2) اضغط زر «تشغيل MRP» فوق يمين، اختار مصدر الطلب (مبيعات / MPS / الاثنين معًا) وأفق التخطيط بالأيام، واضغط «تشغيل». التشغيلة الجديدة هتتفتح أوتوماتيك. (3) في تبويب «المقترحات (Planned)» المقترحات مجمّعة بمستوى البوم — الأعمق الأول (Level 2 فوق Level 1 فوق Level 0) لأن المكونات لازم تتعمل/تتشترى قبل المنتج الأب. كل صف فيه نوعه (إنتاج/شراء)، كمية، تاريخ إطلاق، تاريخ استحقاق، حالة. (4) لكل صف زرّين: «تثبيت (Firm)» علشان تثبّت المقترح، و«تحويل (Convert)» علشان يتحوّل لأمر إنتاج فعلي أو طلب شراء. (5) أهم زر: «تحويل الكل» فوق الجدول — بيحوّل كل المقترحات المرشّحة دفعة واحدة وبالترتيب الصح (الأعمق أولًا) ويوريك كام نجح وكام فشل ورسالة كل فشل. (6) تبويب «النواقص (Missing)» بيوريك المواد اللي ناقصة فعليًا، الكمية الناقصة، متى محتاجينها، والمقترح المناسب لتغطيتها، ومربوطة بأي طلب بيع. في كمان تبويب «الاستثناءات» (متأخر/إعادة جدولة) و«شجرة التغذية».
النتيجة: النتيجة المتوقعة: بضغطة واحدة على «تشغيل» تطلّع كل احتياجاتك مرتّبة جاهزة، وبضغطة «تحويل الكل» تحوّلها كلها لأوامر/طلبات بالترتيب السليم من غير ما تعمل حاجة يدوي. نصيحة: ابدأ يومك من بطاقات الـ KPI — لو «أوامر ناقصها مواد» مولّعة أحمر روح تبويب النواقص قبل ما تحوّل، وخلّي «تحويل الكل» عادتك بدل التحويل الفردي إلا لو عايز تستثني صف معيّن.
3) الترمينال (شاشة لمس المشغّل) — الهوية + الحالة الفارغة الذكية المسار: /factory/terminal (صلاحية production.shopfloor.operate). الملفات: terminal/terminal.component.ts / .html — تستهلك ShopFloorService (queue, start, hold, resume, done) + selectUser من الـ store + ProductionCenterService.
قبل: شاشة المشغّل كانت قائمة عمليات بدون هوية واضحة، ولو اخترت مركز شغل مفيهوش شغل كانت بتطلّع فاضية كده وخلاص بدون ما تعرف هل في غلط ولا فعلًا مفيش. بعد: (1) فوق الشاشة على اليمين ظهرت «بطاقة هوية المشغّل» باسم المستخدم اللي عامل دخول — علشان كل واحد يبان شغّال على أنهي ترمينال. (2) تختار مركز الشغل من القائمة (اختيارك بيتحفظ في المتصفح فبيفضل محفوظ بعد إعادة الفتح). (3) كل عملية بتظهر ككارت كبير لمس بأزرار ضخمة: «بدء» (Start) → «تم» (Done) / «إيقاف مؤقت» (Hold) → «استئناف» (Resume). الكروت ملوّنة بحالتها. (4) زر «تم» بيفتح ديالوج كيباد كبير: الكمية لكل درجة (Grade)، الهالك + سببه، وساعات العمالة/الماكينة اختياري. لما تأكّد، الأمر بيتقدّم أوتوماتيك للعملية التالية (وبيقولك «العملية التالية جاهزة») أو يكمّل الأمر. (5) الحالة الفارغة الذكية: لو اخترت مركز شغل مفيهوش طابور، بدل رسالة فاضية بتظهر رسالة «لا يوجد عمل في مركز كذا» + زر «عرض كل المراكز» يشيل الفلتر فورًا، فمتفضلش حاير. الشاشة كمان بتعمل تحديث أوتوماتيك كل 30 ثانية وفيه علامة «آخر تحديث» / «بيانات قديمة» علشان تعرف الطابور حديث.
النتيجة: النتيجة المتوقعة: المشغّل يعرف هو مين وشغّال على أنهي مركز، ولو الطابور فاضي يعرف إنها مفيش شغل (مش عطل) ويرجع لكل المراكز بضغطة. نصيحة: درّب المشغّلين يستخدموا أزرار بدء/تم/إيقاف فقط ويسجّلوا الهالك وسببه في ديالوج «تم» — ده اللي بيغذّي شاشة الانحرافات صح. لو الكارت ظهر «منتظر» معناه العملية اللي قبلها لسه ماخلصتش.
4) الانحرافات (Variances) — مسار الإقرار ← التحقيق ← الإغلاق المسار: /factory/variances (صلاحية production.costing). الملفات: variances/variances.component.ts / .html — تستهلك VarianceService (listAll, updateStatus) + UserService لأسماء المالكين.
قبل: انحرافات التكلفة كانت أرقام بتتعرض من غير ما حد يتابعها — تشوف إن في فرق وخلاص، مفيش مين مسؤول ولا إثبات إن اتعالج. بعد: الانحراف بقى له دورة عمل واضحة بحالات: مفتوح ← تم الإقرار (acknowledged) ← قيد التحقيق (investigating) ← مغلق (closed). الخطوات العملية: (1) ادخل /factory/variances. فوق 4 بطاقات: إجمالي غير الموات (خسارة)، إجمالي الموات (وفر)، الصافي، وعدد المطلوب التحقيق فيه. (2) تحتها رسم Pareto بيرتّب أنواع الانحراف (MPV/MUV/LRV...) بالأكبر خسارة الأول — علشان تعرف مين أكبر مسبّب تكلفة (قاعدة 80/20). (3) فلاتر تصنيف (الكل/طبيعي/مراقبة/تحقيق) فوق الجدول. (4) في الجدول لكل صف عمود «إجراءات» بزر قائمة: حسب حالة الصف بيوريك الانتقالات المسموحة بس — «إقرار» لو مفتوح، «بدء تحقيق»، أو «إغلاق». (5) لما تختار «إغلاق» بيفتح ديالوج لازم تكتب فيه «ملاحظة المعالجة» (إجباري) وتقدر تعيّن «المالك» (موظف مسؤول) — ومن غير الملاحظة الزر مقفول. الصف بيتحدّث فورًا بالحالة الجديدة واسم المالك.
النتيجة: النتيجة المتوقعة: كل انحراف مهم بيمشي في مسار محاسبة واضح بمسؤول وملاحظة معالجة، فمفيش انحراف بيضيع. نصيحة: ابدأ من رسم الـ Pareto — اشتغل على أول 1-2 نوع لأنهم بيمثّلوا معظم الخسارة، عيّن مالك واكتب ملاحظة معالجة حقيقية عند الإغلاق علشان يبقى عندك سجل تدقيق. ركّز على المصنّفة «تحقيق» أولًا.
5) الأدوار — كل موظف يرى شاشاته فقط التحكم في: factory-layout/factory-layout.component.ts (تفلتر navGroups بـ PermissionService.hasAnyPermission) + production-standalone.routes.ts (كل مسار عليه permissionGuard بصلاحية محددة). أمثلة الصلاحيات: production.orders, production.mrp, production.costing, production.shopfloor.operate, production.shopfloor.supervise, production.boms, production.routings, production.centers, production.confirmations, production.reports.
قبل: كل الشاشات كانت بتظهر للكل بدون تمييز، فالمشغّل كان بيشوف شاشات تخطيط ومحاسبة مالهاش لازمة ليه وده بيلخبط. بعد: قائمة المصنع (السايدبار) بتتفلتر أوتوماتيك حسب صلاحيات الموظف — أي شاشة الموظف ملوش صلاحيتها مش بتظهر له أصلًا، وكمان لو حاول يفتح رابطها بييجي permissionGuard يمنعه. الخطوات العملية (للأدمن): (1) روح إدارة الأدوار/الصلاحيات وأعطِ كل دور الصلاحيات اللي تخصّه فقط: المشغّل ← production.shopfloor.operate (يشوف الترمينال بس)؛ المشرف ← يضيف production.shopfloor.supervise (شاشة البورد الحية)؛ المخطّط ← production.mrp (قمرة التخطيط + MPS + CRP)؛ المحاسب/مراقب التكلفة ← production.costing (الانحرافات + التكاليف القياسية)؛ مدير الإنتاج ← production.orders + production.confirmations + production.reports. (2) سجّل دخول بكل دور وتأكّد إن القائمة بتوريله شاشاته بس. ملاحظة: السوبر أدمن (بصلاحيات فاضية) بيشوف كل حاجة.
النتيجة: النتيجة المتوقعة: كل موظف يفتح المصنع فيلاقي قائمة نضيفة فيها شاشاته اللي يشتغل عليها بس، فمفيش تشتيت ولا دخول لشاشات حساسة. نصيحة: امنح أقل صلاحية تكفي الدور (least privilege): المشغّل مايحتاجش غير الترمينال، والمحاسب مايحتاجش الترمينال. راجع الأدوار دوريًا وامسح أي صلاحية production.* زيادة عن الحاجة.
أُعدّ بتدقيق متوازٍ على الكود الحيّ (Modules/Production·Inventory·Accounting·Sales·Purchases·HRM·QMS·CMMS + شاشات /factory) — قابل للتحديث مع كل تطوير.