Moon ERP · خطة تنفيذ — الحل الدائم (نسخة مُحدَّثة)

التسليم الجزئي + ربط التكلفة بالتسليم الفعلي — ومن يرى ماذا، وبأي إعداد Partial delivery, COGS-at-issue, role visibility & selectable flows via settings

نسخة مُحدَّثة بناءً على ملاحظاتك: (1) كيف يعرف المحاسب أن الفاتورة سُلِّم نصفها وأن جزءاً لم يُسلَّم؟ (2) كيف يعرف أمين المخزن أنه صرف نصف الكمية وأن هناك متبقّياً، وألّا يُنسى أو يُصرف مرتين؟ (3) إعدادات في المخازن والمبيعات لاختيار المسار. (4) إقفال الفاتورة على المُسلَّم لو الباقي لن يُسلَّم (إشعار دائن مالي). لا توجد بيانات قديمة (كلها تجريبية) → أُسقطت مرحلة التسوية.

📅 2026-06-22 (rev2) الفرع: hazemdev2 → main التنفيذ: subagent-driven + Pest TDD جديد: نموذج صرف جزئي + رؤية الأدوار + إعدادات المسارات

المحتويات

★ إجابات أسئلتك الأربعة (ابدأ هنا)
1 · المبدأ الحاكم
2 · الإعدادات والمسارات القابلة للاختيار
3 · نموذج الصرف الجزئي (مطلوب/منصرف/متبقٍّ)
4 · رؤية المحاسب · رؤية أمين المخزن
5 · المعمارية والمكوّنات
6 · المراحل والمهام (TDD)
7 · مصفوفة الاختبارات
8 · المخاطر · القبول · التنفيذ · المراجع

★ إجابات أسئلتك الأربعة (ملخّص الحل)

① كيف يعرف المحاسب أن الفاتورة سُلِّم نصفها وأن جزءاً لم يُسلَّم؟

على الفاتورة نفسها: عمودا «مُسلَّم / متبقٍّ» لكل سطر + شارة حالة pending/partial/full (fulfillment_status).
تقرير محاسبي جديد: «مفوتر ولم يُسلَّم بعد» (Invoiced-but-undelivered) — يسرد كل فاتورة فيها إيراد معترف به وبضاعة لم تخرج كاملة، بقيمة المتبقّي.
محاسبياً: الإيراد كامل (100) لكن COGS يتبع التسليم (50 الآن) → ربح الوحدات غير المسلَّمة لم يُعترف به بعد. هذا صحيح وقياسي، ومرئي عبر التقرير أعلاه + فحص الاتساق GL⇄المخزون.

② كيف يعرف أمين المخزن أنه صرف نصف الكمية؟

سطر الإذن يعرض ثلاث قيم صريحة: المطلوب (quantity=100) · المنصرف (issued_quantity=50) · المتبقّي (50) — لا تخمين.
حالة الإذن تصبح partially_issued بدل «معتمَد كامل»، فيُرى فوراً أنه ناقص.
«قائمة عمل التسليمات» (worklist) في المخازن تُظهر كل الأذون/الفواتير ذات المتبقّي.

③ لو صُرف نصفه — كيف لا يُنسى المتبقّي أو يُصرف مرتين؟

لا يُنسى: عند الصرف الجزئي يُنشأ تلقائياً إذن صرف متبقٍّ (back-order) بحالة Draft للكمية الباقية (قابل للإيقاف بإعداد) — يظل في طابور المخزن حتى يُصرف.
لا يُصرف مرتين / لا زيادة: فحص صارم — مجموع المنصرف عبر كل الأذون ≤ المفوتر لكل سطر؛ أي محاولة لتجاوز المتبقّي تُرفض (over_delivery).
كل إذن متبقٍّ عند اعتماده يسجّل COGS الخاص به ويُحدّث «المُسلَّم» على الفاتورة حتى يكتمل.

④ لو الباقي (50) مش هيتسلّم خالص — كيف نُقفل حساب العميل ونعكسه على الفاتورة بدقة؟

هذه الحالة لم تكن مغطّاة في rev2 وأضفناها الآن (المرحلة 8). الحل = إشعار دائن مالي فقط للكمية غير المسلَّمة، دون أي حركة مخزون (لأن البضاعة لم تخرج أصلاً):

Dr Sales Revenue 750 (عكس إيراد الـ50 غير المسلَّمة) Dr VAT Payable 112.5 (عكس ضريبتها) Cr Accounts Receivable 862.5 (العميل يدين بقيمة الـ50 المسلَّمة فقط)

حساب العميل يُقفل صح: رصيد ذمم هذه الفاتورة يصبح 862.5 (50 وحدة فقط) — يُسدَّد ويُقفل بدقة.
لا أثر مخزني/COGS: الـ50 لم تُصرف فلم يُسجَّل لها COGS وما زالت في المخزن (صحيح) — لا نُرجعها ولا نعكس تكلفة.
الفاتورة تعكسه: delivered=50, cancelled=50, الحالة short_closed (لا تظهر «بانتظار تسليم»). أي إذن متبقٍّ مفتوح يُلغى تلقائياً.
متوافق ضريبياً: يُنشأ كإشعار دائن رسمي يتدفّق لـ ZATCA/ETA عبر وحدة EInvoicing (نفس مسار مرتجع المبيعات).

1 المبدأ الحاكم (الـ Invariant)

لكل بيع، يُسجَّل قيد Dr COGS / Cr Inventory بواسطة نفس الحدث الذي يُخرج البضاعة فعلياً، بنفس الكمية المنصرفة، وبتكلفة لحظة الصرف. ولكل سطر فاتورة: المنصرف عبر كل الأذون ≤ المفوتر، والمتبقّي = المفوتر − المنصرف، مرئي دائماً.

// ثوابت يجب أن تتحقّق في كل لحظة
رصيد حساب المخزون GL   ==  Σ StockBalance.total_value
COGS المعترف به        ==  تكلفة ما خرج فعلياً فقط
Σ issued_quantity(سطر) ==  delivered_quantity(سطر فاتورة)  ≤  quantity(المفوتر)

2 الإعدادات والمسارات القابلة للاختيار مطلوبك

بدل فرض مسار واحد، نضيف إعدادات في المبيعات والمخازن تتيح اختيار سلوك مختلف لكل منشأة. كل الإعدادات الجديدة لها قيمة افتراضية تحافظ على السلوك الحالي (لا انحدار).

إعدادات المبيعات (`sales.*`)

المفتاح	القيم	الافتراضي	الأثر
`sales.cogs_recognition_point` جديد	invoice · delivery	invoice	متى يُسجَّل COGS: مع الفاتورة (المسار «أ») أم مع الصرف الفعلي (المسار «ب»). المفتاح الرئيسي الصريح بدل الاستنتاج الضمني.
`sales.auto_create_stock_issue_on_invoice` (موجود)	true/false	false	توليد إذن صرف تلقائياً عند ترحيل الفاتورة.
`sales.auto_approve_stock_issue_on_invoice` (موجود)	true/false	false	اعتماد الإذن المُولَّد فوراً (تسليم كامل آلي، بلا تدخّل مخزن).
`sales.allow_partial_delivery` جديد	true/false	true	السماح لأمين المخزن بصرف أقل من المفوتر (صرف جزئي).
`sales.auto_create_backorder` جديد	true/false	true	إنشاء إذن صرف Draft تلقائي للمتبقّي بعد الصرف الجزئي.
`sales.block_over_delivery` جديد	true/false	true	منع صرف أكثر من المفوتر تراكمياً.
`sales.stock_deduction_point` (موجود)	invoice · delivery	invoice	متى يُخصم المخزون فعلياً (يتناغم مع `cogs_recognition_point`).

إعدادات المخازن (`inventory.*` + على مستوى المخزن)

المفتاح	القيم	الافتراضي	الأثر
`inventory.allow_partial_issue` جديد	true/false	true	السماح بإدخال `issued_quantity` أقل من `quantity` على سطر الإذن.
`inventory.auto_approve_issues` (موجود)	true/false	—	قد يمنع الاعتماد التلقائي حتى لو طلبته المبيعات.
`inventory.valuation_method` (موجود)	fifo · weighted_avg	weighted_avg	أساس حساب التكلفة لقيد COGS.
`warehouse.allow_negative_stock` (موجود، لكل مخزن)	true/false	false	السماح بالرصيد السالب (يسمح بالصرف رغم نقص المخزون).
`warehouse.require_issue_approval` جديد (اختياري)	true/false	true	هل يلزم اعتماد منفصل للإذن أم يكفي الإنشاء.

ثلاثة مسارات جاهزة (Presets) — يختار المستخدم واحداً

المسار	التركيبة	مناسب لـ	الصرف الجزئي؟
① فوري بسيط	cogs=invoice auto_create=false	تجزئة/POS — تسليم لحظي، فاتورة = خروج فوري	لا
② مدفوع بالتسليم المُوصى به للجملة	cogs=delivery auto_create=true auto_approve=false allow_partial=true auto_backorder=true	جملة/مخزون حقيقي — المخزن يصرف فعلياً (كامل أو جزئي)	نعم
③ تسليم آلي كامل	cogs=delivery auto_create=true auto_approve=true	ثقة كاملة بالمخزون — الإذن يُعتمد آلياً بالكامل	لا

المسار ① هو السلوك الحالي تماماً (محفوظ). المسار ② هو الذي يحقّق سؤالك بالكامل. تبديل المسار = تغيير إعدادات فقط، بلا كود.

3 نموذج الصرف الجزئي (مطلوب / منصرف / متبقٍّ)

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

سطر الإذن — أعمدة جديدة

quantity = المطلوب (يُنسخ من الفاتورة = 100) — ثابت.
issued_quantity جديد = المنصرف فعلاً (يدخله المخزن = 50)، افتراضي يساوي quantity.
source_item_id جديد = يربط بسطر الفاتورة بدقة.
المتبقّي = quantity − issued_quantity (محسوب).

حالة الإذن — قيمة جديدة

enum IssueStatus الحالي: draft approved cancelled. نضيف:

partially_issued — اعتُمد الإذن لكن issued_quantity < quantity في سطر واحد على الأقل. حالة نهائية لهذا الإذن، والمتبقّي ينتقل لإذن back-order.

تدفّق الصرف الجزئي

المخزن يفتح الإذن (مطلوب 100) ويُدخل المنصرف 50

يُدخل issued_quantity=50 (مسموح لأن allow_partial_issue=true) ويعتمد. فحص: Σ issued عبر كل الأذون لهذا السطر ≤ 100 وإلا يُرفض (block_over_delivery).

عند الاعتماد

خصم المخزون 50 · قيد Dr COGS 500 / Cr Inventory 500 · حالة الإذن = partially_issued · delivered_quantity(الفاتورة)=50 · fulfillment_status=partial.

إنشاء إذن المتبقّي تلقائياً (إن كان `auto_create_backorder=true`)

إذن Draft جديد مربوط بنفس الفاتورة، quantity=50 (المتبقّي)، يظهر في طابور المخزن. وإلا، زر يدوي «صرف المتبقّي».

اعتماد إذن المتبقّي (50)

قيد Dr COGS 500 / Cr Inventory 500 · delivered_quantity=100 · fulfillment_status=full. اكتمل.

لماذا «المنصرف» على السطر وليس مجرد تعديل الكمية؟ لأن تعديل الكمية لـ50 يُفقد المعلومة أن المطلوب كان 100 — فلا يعرف المخزن ولا المحاسب أن هناك متبقّياً. تسجيل quantity وissued_quantity معاً يجعل «النصف المنصرف» و«النصف المتبقّي» حقيقة ظاهرة على المستند نفسه.

4 رؤية المحاسب · رؤية أمين المخزن

👔 رؤية المحاسب

على الفاتورة: أعمدة مفوتر/مُسلَّم/متبقٍّ لكل سطر + شارة fulfillment_status.
تقرير «مفوتر ولم يُسلَّم»: كل الفواتير ذات إيراد معترف وبضاعة لم تكتمل، بقيمة المتبقّي — للمتابعة والإقفال الشهري.
دفتر الأستاذ: COGS يتبع التسليم؛ فحص tie-out يضمن مخزون GL = الفعلي دائماً.
قيد كل تسليم موسوم source_type=inventory_issue_cogs → مسار تدقيق من القيد للإذن للفاتورة.

📦 رؤية أمين المخزن

على الإذن: مطلوب/منصرف/متبقٍّ صريحة + حالة partially_issued.
طابور التسليمات (worklist): فلتر بالأذون Draft + الفواتير ذات fulfillment_status ≠ full — لا يضيع متبقٍّ.
إذن المتبقّي يُنشأ تلقائياً ويظهر كـ Draft بانتظار الصرف.
حماية: لا يمكن صرف أكثر من المتبقّي (رفض over_delivery)، وفحص المخزون المتاح كما اليوم.

5 المعمارية والمكوّنات

نستخدم أحداث Laravel لإبقاء Inventory غير معتمِدة على Sales/Accounting (Inventory تُطلق، Sales تستمع وتُسجِّل) — مطابق لنمط InvoicePosted القائم.

المكوّن	النوع	الدور
`InventoryIssueApproved` / `InventoryIssueCancelled`	حدث (Inventory)	يُطلقان داخل المعاملة عند الاعتماد/الإلغاء.
`PostSaleCogsOnIssueApproved`	مستمع (Sales)	للأذون البيعية: قيد COGS بالمنصرف + تحديث delivered_quantity/الحالة + إنشاء back-order.
`ReverseSaleCogsOnIssueCancelled`	مستمع (Sales)	عكس قيد COGS وإعادة حساب التسليم.
`SalesGlAccountResolver`	خدمة (Sales)	استخراج حلّ حسابات COGS/المخزون (DRY) من PostSalesInvoice.
`FulfillmentService`	خدمة (Sales)	حساب delivered/remaining/status + فحص over-delivery + بناء إذن المتبقّي.
أعمدة DB	هجرات	`issued_quantity`, `source_item_id`, `cogs_journal_entry_id`, `delivered_quantity`, `fulfillment_status`
إعدادات	setting defs + seeder	المفاتيح الجديدة في القسم 2.

6 المراحل والمهام (TDD)

كل مهمة: اختبار فاشل أولاً → حد أدنى → ينجح → commit. كل مهمة قابلة للمراجعة منفردة. كل مهمة باك-إند تنتهي بـ bash local-deploy.sh + php artisan test + chown moonui2:moonui2.

أسس DB + تعريفات الإعدادات

منخفض

migration: inventory_issue_items.issued_quantity (decimal, افتراضي = quantity)، .source_item_id (FK nullable).
migration: inventory_issues.cogs_journal_entry_id (FK nullable).
migration: sales_invoice_items.delivered_quantity (افتراضي 0)، sales_invoices.fulfillment_status (افتراضي 'pending').
enum IssueStatus ← PartiallyIssued + label؛ enum FulfillmentStatus.
setting definitions + seeder: كل مفاتيح القسم 2 بقيمها الافتراضية.
$fillable/$casts للموديلات الأربعة.

اختبار: الأعمدة + الافتراضيات + قابلية الكتابة
اختبار: تعريفات الإعدادات تُقرأ بقيمها الافتراضية

القبول: هجرات تمر، إعدادات افتراضية مقروءة، لا تغيير سلوكي بعد.

استخراج `SalesGlAccountResolver` + `FulfillmentService`

منخفض

استخراج حلّ الحسابات من PostSalesInvoice.php:305-334؛ وخدمة FulfillmentService: remainingFor(line), recomputeStatus(invoice), assertNotOverDelivered(line, qty).

اختبار وحدة لأولوية حلّ الحساب (مطابق للحالي)
اختبار وحدة لحسابات remaining/status/over-delivery
إعادة توجيه PostSalesInvoice للخدمة — سلوك مطابق

حدث الاعتماد + إدخال `issued_quantity`

متوسط

ApproveIssue.php: استخدم issued_quantity (لا quantity) في الخصم والتكلفة؛ احترم allow_partial_issue؛ اضبط الحالة Approved أو PartiallyIssued؛ أطلق InventoryIssueApproved داخل المعاملة.
طلب التحديث/الاعتماد + المتحكّم: قبول issued_quantity لكل سطر.

اختبار: اعتماد بـ issued=50/مطلوب=100 → خصم 50، حالة partially_issued
اختبار: over-delivery مرفوض
اختبار: allow_partial_issue=false يمنع issued<quantity
اختبار: الحدث يُطلَق مرة واحدة

المستمع: COGS عند التسليم + delivered + back-order

متوسط · القلب

PostSaleCogsOnIssueApproved.php + تسجيله في Sales EventServiceProvider.

if ($issue->reference_type !== Sale) return;
if ($issue->cogs_journal_entry_id) return;                 // idempotent
$je = createJournalEntry(Dr COGS / Cr Inventory = Σ items.total_cost,
        source_type='inventory_issue_cogs', idempotency="issue-cogs-{id}");
$issue->update(['cogs_journal_entry_id'=>$je->id]);
fulfillment->applyDelivery($issue);          // delivered_quantity += issued, recompute status
if (settings('sales.auto_create_backorder') && remaining>0)
        fulfillment->createBackorderIssue($invoice);

اختبار: قيد COGS بالمنصرف (500 لا 1000)
اختبار: delivered/status يُحدَّثان
اختبار: back-order Draft يُنشأ بالمتبقّي عند تفعيله، ولا يُنشأ عند إيقافه
اختبار: إذن غير بيعي لا يتأثّر · idempotency · FIFO+WAC

توجيه COGS بمفتاح `cogs_recognition_point`

متوسط

PostSalesInvoice.php:52-58: سجّل COGS عند الفاتورة فقط إذا cogs_recognition_point=invoice (المسار «أ»). عند delivery: إيراد فقط، والمستمع (م4) يتولّى COGS.

اختبار: =invoice → COGS عند الفاتورة (لا انحدار للمسار «أ»)
اختبار: =delivery → إيراد فقط عند الفاتورة
اختبار تكامل: فاتورة 100 → صرف 50 → COGS=500 فقط، GL=الفعلي

تغيير سلوكي مقصود لمن يفعّل المسار «ب». محفوظ خلف الإعداد، والافتراضي يبقى «أ».

الإلغاء: عكس COGS + خصم delivered

متوسط

InventoryIssueCancelled + إطلاقه في CancelIssue.php
ReverseSaleCogsOnIssueCancelled + تسجيله
CancelSalesInvoice: تسلسل إلغاء الأذون

اختبار: اعتماد ثم إلغاء → صافي COGS=0، GL=الفعلي
اختبار: delivered يُخصم والحالة تُعاد
اختبار: إلغاء فاتورة يسلسل لأذونها

صرف المتبقّي يدوياً + طابور التسليمات (API)

متوسط

action CreateRemainingIssue + POST /api/sales/invoices/{id}/create-issue
endpoint قائمة: الفواتير/الأذون ذات المتبقّي (worklist) للمخزن.

اختبار: إنشاء إذن متبقٍّ ينتج الكمية الصحيحة، يمنع لو full
اختبار: worklist يُرجع غير المكتمل فقط · صلاحيات · نطاق شركة

إقفال الفاتورة على المُسلَّم — إشعار دائن للمتبقّي غير المُسلَّم

متوسط · مطلوبك

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

migration/model SalesReturn: عمود affects_inventory (افتراضي true).
PostSalesReturn::handleReverseCogs (PostSalesReturn.php:158): تخطّي ساق المخزون/COGS عندما affects_inventory=false — يبقى عكس الإيراد/الضريبة/الذمم فقط.
action CloseInvoiceShort + POST /api/sales/invoices/{id}/close-short.
migration: sales_invoice_items.cancelled_quantity (افتراضي 0).
enum FulfillmentStatus ← ShortClosed؛ setting sales.allow_short_close (افتراضي true).

// CloseInvoiceShort: للكمية المتبقّية غير المسلَّمة (= quantity − delivered)
$return = SalesReturn(invoice, affects_inventory=false, items=remaining @ سعر الفاتورة);
postSalesReturn($return);              // Dr Revenue/VAT / Cr AR فقط — لا مخزون
$line->update(['cancelled_quantity'=>$remaining]);
cancelOpenBackorderIssues($invoice);   // أي إذن متبقٍّ مفتوح يُلغى
fulfillment->markShortClosed($invoice); // delivered + cancelled == invoiced

اختبار: إقفال قصير لـ50 → قيد Dr Revenue 750 / Dr VAT 112.5 / Cr AR 862.5، بلا حركة مخزون/COGS
اختبار: رصيد ذمم الفاتورة = قيمة المُسلَّم فقط؛ الحالة short_closed
اختبار: أي إذن back-order مفتوح يُلغى تلقائياً
اختبار: delivered + cancelled == invoiced (لا متبقٍّ معلّق)
اختبار: allow_short_close=false يمنع العملية

لماذا مالي فقط؟ الـ50 لم تُصرف من المخزن (نموذج COGS-عند-التسليم) فلا COGS لعكسه ولا بضاعة لإرجاعها — نُصحّح الإيراد/الضريبة/الذمم فقط. يختلف عن «مرتجع مبيعات» عادي (بضاعة مُسلَّمة تعود للمخزن، حيث affects_inventory=true).

تقرير المحاسب + فحص الاتساق tie-out

منخفض

تقرير «مفوتر ولم يُسلَّم» (Sales) — فواتير fulfillment≠full بقيمة المتبقّي.
AccountingIntegrityService: فحص مخزون GL == Σ StockBalance.total_value.

اختبار: التقرير يسرد الجزئي بقيمة صحيحة
اختبار: tie-out يمر في السيناريو الصحيح ويكشف فرقاً مصطنعاً

الواجهة (Angular) — الأدوار

متوسط

شاشة الإعدادات (المبيعات/المخازن): المفاتيح الجديدة + اختيار المسار (preset).
عرض/قائمة الفاتورة: أعمدة مُسلَّم/متبقٍّ + شارة الحالة + زر «صرف المتبقّي».
شاشة إذن الصرف: حقل «المنصرف» مقابل «المطلوب» + المتبقّي + حالة partially_issued.
شاشة طابور التسليمات + i18n (en/ar).

شارات/أعمدة بترجمة ثنائية
بناء FE + نشر /app (تنظيف chunks) + chown

التوثيق + changelog

منخفض

بند [Unreleased] (EN+{{ar}}) — الميزة + الإعدادات الجديدة + «فجوة الـseeder»
تحديث KB + إغلاق بند INDEX

لا مرحلة تسوية بيانات قديمة — أكّدتَ أن كل الفواتير تجريبية. إن لزم، تُمسح/يُعاد البذر فقط.

7 مصفوفة الاختبارات (Pest)

#	السيناريو	المتوقَّع
T1	المسار «أ» (`cogs=invoice`, auto_create=false)	إيراد+COGS كامل عند الفاتورة — لا انحدار
T2	المسار «ب» — فاتورة فقط	إيراد فقط، لا COGS
T3	اعتماد إذن issued=50/مطلوب=100	خصم50، COGS=500، حالة partially_issued، delivered=50, status=partial
T4	back-order تلقائي للمتبقّي	إذن Draft 50 يُنشأ (وعند الإيقاف لا يُنشأ)
T5	اعتماد المتبقّي 50	COGS إجمالي=1000، status=full
T6	over-delivery (محاولة صرف 60 من متبقٍّ 50)	رفض `block_over_delivery`
T7	`allow_partial_issue=false`	منع issued<quantity
T8	إلغاء إذن معتمَد	عكس COGS، delivered يُخصم، GL=الفعلي
T9	FIFO و weighted_avg	COGS=تكلفة الحركة في الحالتين
T10	idempotency (اعتماد/حدث مزدوج)	قيد واحد
T11	إذن إنتاج لا بيعي	لا COGS مبيعات
T12	tie-out بعد كل سيناريو	GL inventory == Σ stock value
T13	تقرير «مفوتر ولم يُسلَّم»	يسرد الجزئي بقيمة المتبقّي
T14	إقفال قصير (المتبقّي 50 لن يُسلَّم)	Dr Revenue 750 / Dr VAT 112.5 / Cr AR 862.5، بلا مخزون/COGS، status=short_closed، ذمم الفاتورة=قيمة المُسلَّم
T15	إقفال قصير مع back-order مفتوح	الإذن المتبقّي يُلغى، delivered+cancelled==invoiced

8 المخاطر · القبول · التنفيذ · المراجع

المخاطر والتراجع

الخطر	التخفيف
فشل المستمع يترك مخزوناً منصرفاً بلا قيد	متزامن داخل معاملة الاعتماد → الفشل يُرجع كل شيء (ذرّية)
ازدواج قيد COGS	م5 توقف قيد الفاتورة في وضع التسليم + idempotency + حارس cogs_journal_entry_id
كسر المسار «أ» (الأغلبية)	محفوظ خلف `cogs_recognition_point=invoice` + T1
ضياع المتبقّي	back-order تلقائي + طابور التسليمات + over-delivery guard
اختلاف تكلفة FIFO إطلالة/استهلاك	T9 يثبّتها؛ المصدر = قيمة الحركة الفعلية

التراجع: كل مرحلة commit منفصل؛ الميزة محوطة بالإعدادات (تعطيلها يعيد المسار «أ»)؛ الأعمدة nullable/افتراضية فالهجرات عكوسة.

معايير القبول (DoD)

✅ فاتورة 100 → صرف 50: COGS=500 فقط، GL=الفعلي، وتظهر مُسلَّم/متبقٍّ للمحاسب والمخزن.
✅ المتبقّي 50 لا يضيع (back-order/worklist) ولا يُصرف زيادة (over-delivery guard).
✅ الإلغاء يعكس بالكامل · المسار «أ» دون تغيير · tie-out يمر.
✅ الإعدادات الثلاثة (المسارات) تعمل بالتبديل دون كود.
✅ كل اختبارات المصفوفة خضراء · pint نظيف · مراجعة opus نهائية · FE منشور · changelog+KB محدّثان.

ترتيب التنفيذ

1 DB+إعدادات → 2 خدمات → 3 حدث+issued_qty → 4 مستمع COGS+back-order → 5 توجيه COGS → 6 إلغاء → 7 المتبقّي+worklist → 8 إقفال قصير/إشعار دائن → 9 تقرير+tie-out → 10 FE → 11 توثيق

المراحل 1–5 = الحد الأدنى القابل للإطلاق (يصلح المحاسبة + الصرف الجزئي الأساسي). 6–10 تكمل التجربة والرؤية (الإلغاء، الإقفال القصير، التقارير، الواجهة). التنفيذ subagent-driven: implementer ثم task-reviewer ثم حلقة إصلاح، ومراجعة opus نهائية. النماذج: sonnet للتنفيذ، haiku للمراجعات الصغيرة، opus للنهائية.

ملحق: مراجع الكود

المكوّن	الملف:السطر	الإجراء
ترحيل الفاتورة (إيراد/COGS/إذن)	Sales/.../PostSalesInvoice.php:32-94, 179-401	توجيه COGS + source_item_id (م5،1)
حلّ حسابات المخزون (للاستخراج)	PostSalesInvoice.php:305-334	استخراج (م2)
اعتماد الإذن	Inventory/.../ApproveIssue.php:22-170	issued_quantity + حدث + حالة (م3)
إلغاء الإذن	Inventory/.../CancelIssue.php:19-64	حدث عكس (م6)
حالة الإذن (enum)	Inventory/.../Enums/IssueStatus.php	+ PartiallyIssued (م1)
سطر الإذن (fillable/casts)	Inventory/.../Models/InventoryIssueItem.php:19-44	+ issued_quantity/source_item_id (م1)
محرّك القيود	Accounting/.../CreateJournalEntry.php:27	استهلاك (م4،6)
خدمة النزاهة	Accounting/.../AccountingIntegrityService.php:24-150	tie-out (م8)
EventServiceProvider (Inv/Sales)	{Inventory,Sales}/.../Providers/EventServiceProvider.php	تسجيل (م3،4،6)

خطة تنفيذ (rev2) للحل الدائم — مبنية على تتبّع كود فعلي في hazemdev2. لم تُنفَّذ تعديلات بعد. المرجع التحليلي: sales-partial-issue-accounting.html.
Moon ERP · knowledge-base/plans/sales-partial-issue-fix-plan.html · 2026-06-22 (rev2)

★ إجابات أسئلتك الأربعة (ملخّص الحل)

① كيف يعرف المحاسب أن الفاتورة سُلِّم نصفها وأن جزءاً لم يُسلَّم؟

② كيف يعرف أمين المخزن أنه صرف نصف الكمية؟

③ لو صُرف نصفه — كيف لا يُنسى المتبقّي أو يُصرف مرتين؟

④ لو الباقي (50) مش هيتسلّم خالص — كيف نُقفل حساب العميل ونعكسه على الفاتورة بدقة؟

1 المبدأ الحاكم (الـ Invariant)

2 الإعدادات والمسارات القابلة للاختيار مطلوبك

إعدادات المبيعات (sales.*)

إعدادات المخازن (inventory.* + على مستوى المخزن)

ثلاثة مسارات جاهزة (Presets) — يختار المستخدم واحداً

3 نموذج الصرف الجزئي (مطلوب / منصرف / متبقٍّ)

سطر الإذن — أعمدة جديدة

حالة الإذن — قيمة جديدة

تدفّق الصرف الجزئي

المخزن يفتح الإذن (مطلوب 100) ويُدخل المنصرف 50

عند الاعتماد

إنشاء إذن المتبقّي تلقائياً (إن كان auto_create_backorder=true)

اعتماد إذن المتبقّي (50)

4 رؤية المحاسب · رؤية أمين المخزن

👔 رؤية المحاسب

📦 رؤية أمين المخزن

5 المعمارية والمكوّنات

6 المراحل والمهام (TDD)

أسس DB + تعريفات الإعدادات

استخراج SalesGlAccountResolver + FulfillmentService

حدث الاعتماد + إدخال issued_quantity

المستمع: COGS عند التسليم + delivered + back-order

توجيه COGS بمفتاح cogs_recognition_point

الإلغاء: عكس COGS + خصم delivered

صرف المتبقّي يدوياً + طابور التسليمات (API)

إقفال الفاتورة على المُسلَّم — إشعار دائن للمتبقّي غير المُسلَّم

تقرير المحاسب + فحص الاتساق tie-out

الواجهة (Angular) — الأدوار

التوثيق + changelog

7 مصفوفة الاختبارات (Pest)

8 المخاطر · القبول · التنفيذ · المراجع

المخاطر والتراجع

معايير القبول (DoD)

ترتيب التنفيذ

ملحق: مراجع الكود

إعدادات المبيعات (`sales.*`)

إعدادات المخازن (`inventory.*` + على مستوى المخزن)

إنشاء إذن المتبقّي تلقائياً (إن كان `auto_create_backorder=true`)

استخراج `SalesGlAccountResolver` + `FulfillmentService`

حدث الاعتماد + إدخال `issued_quantity`

توجيه COGS بمفتاح `cogs_recognition_point`