طلبت حاجتين على قسم اختيار المنتج/الأصناف (في البيع والشراء وكل مكان): (1) توحيد الـ padding وشكل الخانات مع حقل البحث عن المنتج، (2) هل ممكن المستخدم يتحكّم في عرض الأعمدة لكل مكان على حدة (سحب/إظهار-إخفاء) ويتحفظ بشكل دائم. ده التحليل بالحقائق من الكود + خطة قابلة للتنفيذ.
تنويه مهم (بعد تحقّق فعلي بالكود): اللي مشترك فعلًا في كل المستندات هو حقل البحث عن المنتج (app-product-search — مستخدم في
19 شاشة: بيع/شراء/مرتجعات/تصنيع/مخازن) — وده اللي بيخلّيها كلها نفس الشكل في البحث. لكن الجدول كامل
(الأعمدة وترتيبها وباقي الخانات) لسه متكرّر يدويًا في كل شاشة — موحّد بس عبر المكوّن TransactionLineItemsComponent في أمر البيع وحده.
الخلاصة: الاتنين قابلين للتنفيذ — بس العقبة إن الجدول (مش البحث) مش موحّد. نوحّد المستندات على المكوّن المشترك الأول، وبعدها «الأعمدة القابلة للسحب والمحفوظة» تبقى سهلة. وعندنا نصف الحل موجود: إظهار/إخفاء الحقول محفوظ فعلًا (لكن لكل الشركة مش لكل مستخدم).
app-product-search → 19 شاشة (مشترك ✓) ·
TransactionLineItemsComponent → 1 شاشة فقط (أمر البيع). فاللبس كان: المشترك هو البحث مش الجدول.
| المستند | بيستخدم المكوّن المشترك؟ | تعريف الأعمدة |
|---|---|---|
| أمر بيع (Sales Order) | ✅ نعم — TransactionLineItemsComponent | config array (lineDescriptor.columns) |
| فاتورة بيع | ❌ جدول خاص بيه | hardcoded في الـ HTML + lineColRatios |
| أمر/فاتورة شراء | ❌ جدول خاص | hardcoded في الـ HTML |
| مرتجعات / عروض أسعار | ❌ (على الأرجح خاص) | hardcoded |
المكوّن المشترك مصمَّم صح — وصف تعريفي (descriptor) فيه الأعمدة كـ data، ورندر حسب النوع:
// shared/components/transaction-line-items/transaction-line.types.ts interface TxColumn { key: string; // اسم الحقل type: TxCellType; // product | select | number | percent | computed | action labelKey: string; // مفتاح الترجمة width?: string; // '26%' أو '120px' visible?: () => boolean; // إظهار/إخفاء تفاعلي }
app-product-search) موحّد فعلًا في كل المستندات (19 شاشة). فلو شفت إن كل الشاشات «نفس الشكل في البحث» — ده صح: هو نفس المكوّن المشترك. اللي بيختلف بين الشاشات هو تركيب الأعمدة والخانات حواليه، مش البحث نفسه.| العنصر | الـ padding (رأسي) | ملاحظة |
|---|---|---|
حقل البحث عن المنتج .ps-input (مستقل) | 0.55rem فوق/تحت | أطول قليلًا |
حقول الكمية/السعر p-inputNumber | 0.3rem | أقصر |
| نفس البحث جوه المكوّن المشترك | 0.3rem (override) | متوافق داخل الجدول الموحّد ✓ |
يعني جوه المكوّن المشترك الأطوال متوافقة (المكوّن بيعمل override). التفاوت بيظهر في الشاشات اللي مش مستخدماه (لأنها بتطبّق ستايلها الخاص)، وفي الستايل الافتراضي للبحث لما يُستخدم لوحده. حل بسيط: توكِن CSS موحّد لارتفاع/padding خانة الجدول.
| القدرة | الحالة اليوم | التخزين |
|---|---|---|
| إظهار/إخفاء حقل (عمود) لكل مستند | 🟡 موجود — DocConfigService | backend (إعداد core.document_settings) — لكل الشركة |
| إلزامية حقل (required) لكل مستند | 🟡 موجود | نفس المكان (لكل الشركة) |
| إظهار/إخفاء أعمدة شاشات القوائم (مش الأصناف) | ❌ مؤقت (في الذاكرة) | مايتحفظش — يرجع مع الـ reload |
| ترتيب الأعمدة (سحب reorder) | ❌ غير موجود | — |
| عرض الأعمدة (resize) | ❌ غير موجود | — |
| تفضيلات لكل مستخدم (مش الشركة) | ❌ غير موجود | — |
DocConfigService (محفوظ في الباك-إند لكل الشركة). الناقص للطلب الكامل = الترتيب بالسحب، العرض، والتخصيص لكل مستخدم بدل لكل الشركة.جهد: منخفض ممكن وسهل — وجزء منه متحقّق أصلًا.
البحث عن المنتج نفسه متوحّد فعلًا (نفس المكوّن في 19 شاشة) فهو متّسق. اللي بيختلف هو الخانات المجاورة (الكمية/السعر/الخصم) وارتفاع خلية الجدول بين الشاشات اللي بتكتب جدولها يدويًا.
الحل: نعرّف توكِن/كلاس CSS موحّد لخانة جدول الأصناف (نفس الارتفاع، نفس الـ padding، نفس الـ border-radius والـ focus) ونطبّقه على
حقل البحث .ps-input وحقول p-inputNumber/p-select سواء جوه المكوّن المشترك أو بره. المكوّن المشترك بيعمل ده جزئيًا بالفعل
(override لـ 0.3rem) — نعمّمه ونثبّته كمعيار.
التوصية: ننفّذه كجزء من التوحيد (السؤال 2) — لأن أول ما كل الشاشات تستخدم نفس المكوّن، الشكل بيتوحّد تلقائيًا من مكان واحد.
ممكن — نعم. بس بيمرّ بثلاث طبقات، والترتيب مهم:
نحوّل فاتورة البيع + أوامر/فواتير الشراء + المرتجعات + عروض الأسعار تستخدم TransactionLineItemsComponent بوصف descriptor خاص بكل واحدة
(زي أمر البيع بالظبط). كده الأعمدة كلها تبقى data في مكان واحد — وده الأساس لأي تحكّم. مكسب جانبي: توحيد الشكل (السؤال 1) بيحصل مجانًا.
المكوّن المشترك بيستخدم <table> عادي (مش p-table). نضيف:
DragDrop على رؤوس الأعمدة (الأبسط مع جدول HTML)، أو نحوّل لـ PrimeNG p-table مع reorderableColumns + resizableColumns.p-table.عندنا مسارين للتخزين:
| الخيار | المكان | المناسب لـ |
|---|---|---|
أ) توسيع DocConfigService (الموجود) | backend — لكل الشركة، لكل مستند | «إعداد مرة واحدة للشركة كلها» — أسرع، يبني على الموجود |
| ب) خدمة تفضيلات لكل مستخدم (جديدة) | backend user_ui_preferences (user × document) أو localStorage | «كل مستخدم يرتّب جدوله زي ما يحب» — ده اللي بتقصده غالبًا بـ«سحب ويحفظ دائم» |
حاليًا التحكّم محفوظ لكل الشركة (DocConfigService). لو عايز كل مستخدم يرتّب أعمدته بشكله الخاص ويتحفظ معاه على أي جهاز → الخيار (ب).
sales.order ≠ sales.invoice ≠ purchases.bill…) في DocConfigService. فـ«تخصيص لكل مكان» متوفّر هيكليًا — ينقص بس نمدّه ليشمل الترتيب/العرض + (اختياريًا) البُعد لكل مستخدم.DocConfigService (لكل الشركة، لكل مستند). لو طُلب لكل مستخدم → خدمة user_ui_preferences.
p-table (يجي بـ resizableColumns جاهز).
DocConfigService. الناقص = الترتيب بالسحب + العرض + (لو عايز) التخصيص لكل مستخدم.