# RESUME — ISS-2026-9260 · الصرف على أمر إنتاج من شاشة إذن الصرف

**الحالة:** ✅ **التنفيذ اكتمل على `hazemdev2`** (BE + FE) · منشور على `/app` للاختبار · **غير ملتزم في git** · **مفيش دمج على main ولا شحن للعملاء** — دي خطوة المالك (`/fullpush`).
**آخر تحديث:** 2026-07-26 · **الفرع:** hazemdev2 · **الحزمة المنشورة:** `main-I2VM4Q7K.js` · **`I18N_VERSION`:** `20260725b`

---

## اللي اتعمل

أمين المخزن بقى يقدر — من شاشة **أذون الصرف** — يصرف خامات على **أمر إنتاج**، ولو مفيش أمر مناسب يعمل **أمر مؤقت** في نفس اللحظة ويصرف عليه فورًا. وكل ده خلف **مفتاح شركة** لأن مون بيشتغل بوضع إنتاج أو تجاري.

| WP | الوصف | النتيجة |
|---|---|---|
| **WP1** | إذن الصرف المربوط بأمر إنتاج بيسجّل أثره عند الاعتماد **سواء إعداد موافقة أمين المخزن مفتوح أو مقفول** — كان قبل كده بيخصم المخزون بلا `MfgMaterialIssue` ولا WIP ولا استهلاك ولا فكّ حجز (**stock↔GL desync صامت**) | ✅ |
| **WP1b** | **[بلوكر اتقفل]** المال بالوحدة الأساسية · الخطة والحجز والبوابة **بوحدة الخطة** — إصلاح WP1 كان بيفكّ 12 مقابل مساهمة 2 و**يدمّر حجز أوامر تانية** | ✅ |
| **WP2** | المفتاح + `POST orders/quick` + `GET orders?issuable=1&search=` + علامة `order_type='stock_issue'` **بلا migration** | ✅ |
| **WP3** | الواجهة: نوع مرجع «أمر إنتاج» + منتقي الأوامر + حوار الأمر المؤقت | ✅ |
| **WP4** | رسالة رفض الصرف الزائد بتسمّي الصنف ورقم الأمر والخطوة التالية | ✅ |
| **إغلاق** | العلامة بقت **مقروءة ومفلترة** (Resource + فلتر + بادج «من إذن صرف» + فلتر «نوع الأمر») — كانت متنفّذة نصّها | ✅ |

## الأرقام

| | خط الأساس | النهاية |
|---|---|---|
| Production | 594 / 10 | **625 / 10** |
| Inventory | 541 / 1 | **541 / 1** |
| FE build | أخضر | **أخضر** — بلا أي تحذير جديد |

العشرة فشل سابقة وموثّقة: 6 `ProductionVarianceTest` · 3 `CostAiAnomalyVarianceTest` · 1 `ConsignmentFoundationTest`. **صفر فشل جديد في كل WP.**

## المراجعات
كل WP اتراجع بـopus منفصل، وفي الآخر **مراجعة تماسّ شاملة** للأربعة مع بعض: **صفر حرج · صفر عالي** — «ماقدرتش أركّب سيناريو تنتج فيه الأربع WPs مع بعض رقمًا غلط أو ترحيلًا مزدوجًا أو كتابة عبر التينانتس أو رجوعًا جزئيًا، ما تنتجه أي واحدة لوحدها». الترحيل مرة-واحدة محمي بـ**خمس** طبقات مستقلة.

**العيوب اللي المراجعات منعتها قبل ما توصل للمالك:** انحدار تدمير حجز أوامر تانية (WP1b) · بوابة الميزة **ماكانش ينفع تتفتح أصلًا** (مفيش سويتش في شاشة الإعدادات) · 422 غير قابل للإصلاح عند تعديل إذن قديم بعد إقفال المفتاح · `COALESCE` ناقصة كانت **بتمسح تكلفة** في الباكفلَش · تعطيل المنتقي كان هيسحب `reference_id` من الحمولة بصمت · اختبار كان **بيشفّر الافتراض بدل ما يختبره** فخلّى الانحدار يعدّي أخضر.

## يتقال للعميل في التسليم (لازم)
1. **تصحيح:** الحبيبة **لكل خامة** — صنف مصروف **مش ضمن خطة** الأمر بيعدّي **حر** (مفيش بوابة)، مش بيتحاسب كصرف زائد زي ما قلت له. متسق مع منطق إجابته، ومغطّى باختبار صريح دلوقتي.
2. **حد معروف:** الأمر المؤقت مالوش **مخزن مصدر** ⇒ الصرف عليه **من شاشة الإنتاج** بيرفض لحد ما الإنتاج يكمّله. الصرف من شاشة أذون الصرف شغّال عادي. (ولو حد عمل `unrelease` للأمر المؤقت بيتقفل نهائيًا.)

## مؤجّلات ⇒ تذاكر منفصلة
- **`CancelMaterialIssue` بيعيد حجز سطور الأمانات** اللي `applyEffects` ماكانش فكّها ⇒ دورة صرف←إلغاء بتضخّم الحجز. **سابق، من ISS-9166.** التعليق اتصحّح والكود مااتغيّرش.
- **فكّ الحجز دايمًا على مخزن الأمر** حتى لو الصرف من مخزن تاني ⇒ «اتساق المخزن».
- **تطبيع لقطة الخطة للوحدة الأساسية** (5 كتّاب + backfill) — **محتاج قرار عميل**.
- **`assertPerLineRouting`** بيقارن كمية مدخلة بأرصدة أمانات أساسية · **`BackflushFromStaging`** بيمرّر كمية بوحدة الخطة لـ`decreaseStock` بلا وحدة.
- **ثغرة تغطية:** مفيش اختبار بيمسّ الشكل الحقيقي `source_warehouse_id = null` للأمر المؤقت (اتأكّد بالقراءة).

## نقطة الاستئناف
التنفيذ خلص. الباقي **مش شغل كود**: نشر التحقّق على التذكرة (بالتصحيح والحد المعروف أعلاه)، وانتظار اختبار العميل، ثم `/fullpush` من المالك.
تفاصيل كل قرار ومراجعة في `LEDGER.md` جنب الملف ده.