سيِّد الأصناف ووحدات القياس (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.
• لا إجراء برمجي لإنشاء طلب الشراء؛ إعادة الطلب تنبيهية فقط؛ لا نموذج مواقع فرعية.