في نافذتَي «تعديل إذن الصرف» و«تعديل إذن الإضافة»، جدول بنود الأصناف واسع (المنتج، المتغيّرات، المخزون، الوحدة، المطلوب/الكمية، المصروف، مخزن المصدر، صاحب الأمانة، رقم الدفعة…) ومحتاج تمرير أفقي. العميل عايز يقدر يتحكّم في عرض الأعمدة وترتيبها (وإخفاء اللي مايحتاجهوش) — «زي الفواتير» بالظبط: يسحب العمود يوسّعه/يضيّقه، ويسحبه يغيّر مكانه، ويخفي أعمدة.
فاتورة المبيعات (وباقي المستندات) بتستخدم مكوّن مشترك TransactionLineItemsComponent (src/app/shared/components/transaction-line-items/) اللي فيه:
| القدرة | الآلية | المرجع |
|---|---|---|
| إظهار/إخفاء عمود + زر ترس ⚙ | docConfig.fieldVisible() + popover | invoices.component.html:440 · doc-config.service.ts:227 |
| إعادة الترتيب (سحب رأس العمود) | Angular CDK DragDrop → setLineColumnOrder() | transaction-line-items.ts:352 · doc-config.service.ts:290 |
| تغيير العرض (مقبض سحب على الرأس) | Pointer-Events → setLineColumnWidth() | transaction-line-items.ts:389 · doc-config.service.ts:321 |
التخزين: الثلاثة (ظهور + ترتيب + عرض) بيتحفظوا في إعداد واحد core.document_settings عبر PUT /core/settings — على مستوى الشركة (per-company)، ومحمي بصلاحية core.settings. مفيش أي حفظ per-user لتخطيط الأعمدة في البرنامج كله.
الشاشتان لا تستخدمان المكوّن المشترك — كل واحدة <table> HTML عادية مكتوبة بالكامل يدويًا (بسبب خلاياها الخاصة: منتقي الأمانة، بادج المخزون، شِيبس السيريال/اللوط، الباركود). docConfig بيتحكّم في ظهور عمود أو اثنين فقط؛ الباقي وعرض كل الأعمدة وترتيبها ثابت في الكود.
| الشاشة | docKey | أعمدة يتحكّم فيها docConfig | باقي الأعمدة |
|---|---|---|---|
إذن الصرفstock-issues.component | inventory.issue | unit_id فقط | ثابتة دائمًا: المنتج، المتغيّر، المخزون، المطلوب، المصروف، مخزن المصدر، صاحب الأمانة، الدفعة |
إذن الإضافةstock-receipts.component | inventory.receipt | unit_id + unit_cost | ثابتة دائمًا: المنتج، المتغيّر، المخزون، الكمية، إجمالي التكلفة، الدفعة |
DOC_CONFIG_REGISTRY الحالي، الـdocKey للشاشتين مُسجَّل بـ٣ حقول سطر فقط (product/unit/quantity) — باقي أعمدة الجدول غير مُسجَّلة أصلًا، فحتى الإظهار/الإخفاء مش متاح لها اليوم.جلب نفس تجربة الفاتورة إلى جدولَي إذن الصرف والإضافة: (أ) إظهار/إخفاء كل الأعمدة، (ب) إعادة ترتيب بالسحب، (ج) تغيير العرض بالسحب — مع حفظ التفضيل بحيث يفضل ثابت بعد إعادة فتح الشاشة.
| القدرة | الفاتورة (موجود) | إذن الصرف/الإضافة (الآن) | المطلوب عمله |
|---|---|---|---|
| إظهار/إخفاء عمود | كامل ⚙ | عمود–اثنين فقط | تسجيل كل الأعمدة + زر الترس على الجدولين |
| إعادة الترتيب (سحب) | موجود | غير موجود | سحب الرأس + احترام الترتيب المحفوظ عند رسم الصفوف |
| تغيير العرض (سحب) | موجود | غير موجود | مقبض عرض على الرأس + عرض محفوظ لكل عمود |
| حفظ التفضيل | شركة-عام (core.settings) | لا يوجد | قرار: شركة-عام (زي الفاتورة) أم per-user؟ (قسم 8) |
| الملف | الدور في التغيير |
|---|---|
src/app/core/services/doc-config.service.ts | تسجيل كل أعمدة inventory.issue/inventory.receipt؛ استخدام lineColumnOrder/Width الموجودين أصلًا |
transaction-line-items.component.ts | مصدر آلية السحب/العرض/الترتيب — نُعيد استخدامها (استخراج موجِّه/directive أو تبنّي المكوّن) |
stock-issues.component.html / .ts | تحويل رسم الأعمدة إلى مقاد بالترتيب + مقابض الرأس + زر الترس |
stock-receipts.component.html / .ts | نفس الشيء لجدول الإضافة |
i18n ar.json/en.json | مفاتيح تسميات الأعمدة الجديدة في الترس |
Backend: لا تغيير على الأغلب — التخزين الحالي core.document_settings عبر /core/settings كافٍ للخيار «شركة-عام». (per-user يحتاج تخزين جديد — قسم 8.)
locked) — لا تُخفى؛ تبقى دائمًا ظاهرة حتى لو أُعيد ترتيبها.core.settings (زي الفاتورة) وأمين المخزن مالوش الصلاحية → مش هيقدر يعدّل الأعمدة. ← قرار جوهري في قسم 8.WP1 — تسجيل الأعمدة + الإظهار/الإخفاء (ترس ⚙): سجّل كل أعمدة الجدولين في DOC_CONFIG_REGISTRY وأضف زر الترس على الشاشتين (نمط الفاتورة). أقل مخاطرة — بيوصّل أغلب القيمة
WP2 — إعادة الترتيب + تغيير العرض: استخرج آلية DragDrop+Resize من المكوّن المشترك إلى موجِّه قابل لإعادة الاستخدام، وطبّقه على رؤوس الجدولين، وحوّل رسم الصفوف ليكون مقادًا بترتيب الأعمدة (بدل ترتيب <td> الثابت) مع احترام العرض المحفوظ. أكبر — رسم الصف يتغيّر
WP3 — i18n + مراجعة + بناء: مفاتيح التسميات، مراجعة Codex/opus، ng build، نشر /app.
تسلسل موصى به: WP1 أولًا (يُسلَّم ويُجرَّب)، ثم WP2 بعد تأكيد العميل على السلوك والصلاحية.
الفاتورة بتحفظ ترتيب/عرض/ظهور الأعمدة على مستوى الشركة (إعداد واحد، محمي بصلاحية core.settings). الأبسط والأسرع والمتّسق = نفس الشيء هنا. لكن لو المطلوب إن كل أمين مخزن يرتّب جدوله بنفسه (ولمّا العميل قال «يمكن اتحكم» ممكن يقصد ده) → نحتاج تخزين per-user جديد. أي واحد؟
لو اخترنا «شركة-عام» فالمنطقي إن اللي يعدّل الأعمدة هو صاحب صلاحية إعدادات (زي الفاتورة تمامًا) — يظبطها مرة وتسري على الكل. لو اخترنا «per-user» فكل مستخدم يعدّل بتاعه بلا صلاحية خاصة. القرار مربوط بـQ1.
إظهار/إخفاء الأعمدة (WP1) لوحده بيحل «الجدول مزدحم» بأقل مخاطرة وسرعة. الترتيب+العرض (WP2) أكبر شوية. أبدأ بـWP1 وأسلّمه، ثم WP2؟ أم تعمل الاتنين مع بعض؟
إذن الصرف + إذن الإضافة يتعملهم نفس التحسين معًا (نفس الآلية). موافق؟
جدول بنود «تعديل إذن الصرف» — قبل (أعمدة ثابتة، بلا تحكّم) مقابل بعد (مقبض سحب ⋮⋮ لإعادة الترتيب + مقبض عرض على حافة الرأس + زر ترس ⚙ للإظهار/الإخفاء):
| # | المنتج | المتغيّرات | المخزون | الوحدة | المطلوب | المصروف | مخزن المصدر | الأمانة | الدفعة |
|---|---|---|---|---|---|---|---|---|---|
| 1 | PRD·i7319 | — | 13.90 | كيلو | 6.06 | 6.06 | مخزن ١ | — | FEFO |
| 2 | PRD·i0639 | — | 487 | قطعة | 300 | 300 | مخزن ١ | — | FEFO |
| # | ⋮⋮المنتج | ⋮⋮المخزون | ⋮⋮المطلوب | ⋮⋮المصروف | ⋮⋮مخزن المصدر | ⋮⋮الأمانة |
|---|---|---|---|---|---|---|
| 1 | PRD·i7319 | 13.90 | 6.06 | 6.06 | مخزن ١ | — |
| 2 | PRD·i0639 | 487 | 300 | 300 | مخزن ١ | — |
stock-issues.component.html (رؤوس + رسم الصف مقاد بالترتيب) وstock-receipts.component.html بنفس الشكل. لا يتغيّر أي منطق حفظ/اعتماد — تحكّم عرض بحت.تحليل Phase 1 — بلا كود. بانتظار قرارات العميل (قسم 8) قبل أي تنفيذ. | ISS-2026-9169 · Moon ERP · hazemdev2