كتالوج المنتجات مع المتغيرات والحزم: المخطط وأنماط واجهة المستخدم

لماذا تتعقّد المتغيرات والحزم بسرعة

يبدو الكتالوج بسيطًا عندما يكون كل منتج عنصرًا واحدًا بسعر واحد وعدد مخزون واحد. أضف اللون أو المقاس أو طول الاشتراك أو تغليفًا خاصًا بمنطقة ما، وتنهار تلك البساطة. جدول "المنتجات" الواحد لم يعد قادرًا على الإجابة عن أسئلة أساسية: أي شيء بالضبط نبيعه، وكيف نتتبعه؟

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

تضيف الحزم طبقة ثانية من التعقيد لأنها تبدو كمنتجات لكنها تتصرف كقواعد. قد يتضمن "طقم البداية" زجاجة واحدة ومضخة وعبوة فلاتر. يعتمد توفره على الأجزاء، ولا بد أن تظل تكاليفك وتقاريرك منطقية.

علامات أن الكتالوج بدأ ينهار:

• تنشئ SKUs مكررة فقط لتمثيل خيار.
• تبدو أعداد المخزون خاطئة، خاصة بعد مبيعات الحزم.
• تصبح شاشات الإدارة قوائم طويلة من عناصر متشابهة تقريبًا.
• تعمل الخصومات والضرائب للأصناف الفردية لكنها تنهار للكيِتات.
• لا تجيب التقارير على "ما الذي بيع فعلاً؟"

الحل في الغالب انضباط: نموذج بيانات يبقى متسقًا، وأنماط واجهة مستخدم تجعل اختيار الخيارات والتوافر واضحًا للعملاء وفريقك.

مصطلحات بلغة بسيطة: الخيارات، المتغيرات، SKUs، الحزم

عندما يقول الناس "متغيرات" غالبًا يخلطون بين عدة أفكار. توضيح الكلمات مبكرًا يجعل قرارات لاحقة (المخطط، الواجهة، المخزون) أسهل.

تستخدم معظم الفرق هذه التعريفات:

• الخيار: اختيار يمكن للمتسوق أن يقوم به، مثل المقاس أو اللون.
• قيمة الخيار: قيمة داخل خيار، مثل المقاس = M أو اللون = أسود.
• المتغير: تركيبة واحدة دقيقة من قيم الخيارات، مثل مقاس M + لون أسود.
• SKU: وحدة قابلة للبيع تتتبعها العمليات والمخزون. عادةً ما يرتبط المتغير بSKU واحد، لكن ليس دائمًا.
• الحزمة / الكيِت / العبوة المتعددة: منتج مكوّن من منتجات أخرى. الحزمة هي تجميع تسويقي (يمكن بيع الأجزاء منفصلة). الكيِت هو مجموعة "يجب شحنها معًا". العبوة المتعددة هي نفس العنصر مكررًا (عبوة مكونة من 3 جوارب).

تتشتت المعرفات أيضًا عمليًا. المعرف الداخلي هو ما يستخدمه قاعدة بياناتك. الـ SKU هو رمزك التشغيلي (يُستخدم في التجهيز والتعبئة والتقارير). الباركود (UPC/EAN) هو ما تقرأه الماسحات. يمكن أن يكون للـ SKU الواحد عدة باركودات (مناطق مختلفة)، وبعض العناصر ليس لديها باركود.

قاعدة جيدة لتقرير ما إذا كان شيء ما يجب أن يكون متغيرًا قابلًا للبيع: إذا كان يمكن أن يكون له سعر مختلف، مخزون مختلف، وزن أو قواعد شحن مختلفة، اعتبره قابلاً للبيع. عادةً نفس القميص بالمقاس M و XL يحتاجان إلى أعداد مخزون منفصلة، لذا يجب أن يكونا SKUs منفصلة.

قرّر ما يحتاج الكتالوج لديك إلى دعمه

قبل أن تختار مخططًا، ابدأ بالأسئلة التي يجب أن يجيب عليها العمل كل يوم. عندما ينظر شخص إلى عنصر، هل يمكنك الإجابة بثقة: هل متاح الآن، ما تكلفته، كيف سيشحن، وما قواعد الضريبة المطبقة؟

طريقة مفيدة للتفكير هي تحديد أين يعيش كل "حقيقة". ضع الحقائق المشتركة على مستوى المنتج، والحقائق المتغيرة على مستوى المتغير (SKU). إذا خلطتهما، ستنتهي وإصلاح نفس الخطأ في مكانين.

أسئلة عادةً ما تحدد الحقول على مستوى المنتج مقابل مستوى المتغير:

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

حافظ على مصدر حقيقة واحد. على سبيل المثال، لا تخزّن "السعر" في المنتج والمتغير معًا ما لم تكن الأدوار واضحة (مثل المنتج به MSRP، والمتغير به سعر البيع الفعلي).

خطط للتغيير. قد تضيف خيارًا جديدًا لاحقًا (مثل "الطول"), أو تتوقف عن بيع متغير, أو تدمج SKUs بعد تغيّر المورد. يسير هذا بسلاسة أكبر عندما تكون المتغيرات سجلات أساسية، لا مجرد تسميات.

إذا كنت تبني في AppMaster، تسهيل تسمية الكيانات بوضوح في Data Designer يجعل الصيانة أسهل عند تغير المتطلبات.

مخطط عملي للمنتجات والمتغيرات

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

مجموعة كيانات يعتمد عليها:

• المنتج: العنصر الأب (الاسم، الوصف، العلامة التجارية، الفئة، الصور الافتراضية)
• الخيار: نوع الاختيار (مقاس، لون)
• قيمة الخيار: القيم المسموح بها (صغير، متوسط، أحمر، أزرق)
• المتغير: وحدة قابلة للبيع (تركيبة واحدة من القيم)
• VariantOptionValue: جدول وصل يربط المتغير بقيم الخيارات المختارة

تفرد المتغيرات هو المكان الذي يخطئ فيه الكثيرون. المنهج الأكثر أمانًا هو التطبيعي: فرض قيمة خيار واحدة لكل خيار لكل متغير، ومنع التركيبات المكررة. إذا أردت السرعة أيضًا، خزّن "مفتاح المتغير" محسبًا مثل color=red|size=m (أو هاش منه) على المتغير وفترض تفرده لكل منتج.

حافظ على الحقول التي تتغير حسب التركيبة على المتغير، وليس المنتج: SKU، الباركود، السعر، سعر المقارنة، الكلفة، الوزن، الأبعاد، الحالة (نشط/متوقف)، والصور (صورة رئيسية أو مجموعة صور صغيرة).

لسمات مخصصة (مثل "المادة" أو "تعليمات العناية"), تجنّب إضافة أعمدة جديدة بلا حدود. حقل JSONB على المنتج أو المتغير يعمل جيدًا في PostgreSQL، مقترنًا بطبقة تحقق صغيرة في التطبيق.

قواعد SKU تبقى متسقة مع الزمن

الـ SKU هو معرف لوحدة قابلة للبيع تعد بالثبات. يجب أن يجيب على سؤال واحد: "أي عنصر بالضبط بعناه؟" لا ينبغي أن يحمل اسمك التسويقي الكامل أو نص الخيار الكامل أو الموسم أو قصة طويلة. إذا أثقلت الـ SKU بمعانٍ متغيرة، يصبح من الصعب تغيير أي شيء لاحقًا دون كسر التقارير.

قرّر مبكرًا ما إذا كانت SKUs تُعيّن يدويًا أم تُولَّد. الـ SKUs اليدوية أكثر أمانًا عندما لديك بالفعل ERP أو باركودات أو SKUs موردين يجب أن تتطابق. الـ SKUs المولَّدة أكثر أمانًا عند وجود الكثير من المتغيرات وتحتاج اتّساقًا، بشرط ألا تتغير قواعد التوليد منتصف العام. حل وسط شائع هو SKU أساسي ثابت تتحكم فيه، زائد لاحقة قصيرة مولّدة لخصائص المتغير.

قواعد تبقى قابلة للقراءة وتتحمل النمو:

• اجعل SKUs ثابتة بعد حدوث طلب. لا "تصحّح" SKUs القديمة بإعادة تسميتها.
• فصل المعرف الداخلي عن الـ SKU. استخدم الـ SKU للناس، والمعرف للقاعدة.
• استخدم بادئات قصيرة لعائلات المنتجات (مثل TSH، MUG)، لا كلمات كاملة.
• تجنّب المعاني القابلة للتغير (مثل "2026" أو "SUMMER") إلا إذا كان عملك يعتمد ذلك فعليًا.

لا تحذف SKUs المتوقفة. علّمها كغير نشطة، احتفظ بتاريخ أسعارها، واحتفظ بخيار اختيارها في الطلبات والمرتجعات والتقارير السابقة. إذا استبدلت SKU، خزّن مرجع "استبدل بواسطة" حتى يتمكن الدعم من تتبع ما حدث.

قواعد التحقق تمنع تلفًا بطيئًا عبر الزمن: فرض تفرد SKU عبر كل العناصر القابلة للبيع، السماح فقط بالحروف والأرقام والواصلات، تحديد طول أقصى واضح (غالبًا 20-32 حرفًا)، وحجز بادئات لحالات خاصة (مثل "BND-" للحزم).

في AppMaster، تناسب هذه الفحوص كقيود بيانات مع عملية أعمال تمنع الحفظ إذا خالف شيء القواعد.

منطق المخزون أبعد من المتوفر/غير المتوفر

يتعقّد المخزون عندما قد يعني نفس "المنتج" وحدات قابلة للبيع متعددة. قبل أن تكتب قواعد، اختر وحدة المخزون: هل تتتبع المخزون على مستوى المنتج، مستوى المتغير، أم كلاهما؟

إذا يختار العملاء المقاس أو اللون، فالمستوى المتغير عادةً هو الأكثر أمانًا. قد يكون القميص "متوفرًا" عمومًا، لكن متغير Small-Blue قد يكون نفدًا. مستوى المنتج يعمل للأصناف التي لا تغير كيف تخزن فعليًا (مثل رخص رقمية بخطط تسعير مختلفة). تبقي بعض الفرق كلا المستويين: مستوى المنتج للتقارير، ومستوى المتغير للبيع.

منع البيع الزائد أقل عن علم واحد وأكثر عن حالات واضحة. تحتاج معظم الكتالوجات إلى حجوزات (حجز وحدات مؤقتًا للسِلات أو الطلبات غير المدفوعة)، طلبات مؤجلة (السماح بالبيع مع مواعيد شحن واضحة)، عوازل مخزون (كمية مخفية لتغطية تأخّر التزامن)، وتحديثات ذرّية (تقليل المخزون في نفس العملية التي تؤكد الطلب).

الحالات الحدية هي مصدر "مخزون غامض". يجب أن تعيد المرتجعات إلى المخزون فقط بعد الفحص، ليس عند إنشاء ملصق الإرجاع. يجب أن تنتقل العناصر التالفة إلى حالة أو موقع منفصل حتى لا تظهر قابلة للبيع. تحتاج تعديلات المخزون إلى أثر تدقيقي (من عدّل ماذا ولماذا)، خصوصًا إذا كانت قنوات متعددة تحدث المخزون.

تضيف الحزم والكيِتات قاعدة رئيسية: لا تقلل سجل "الحزمة" إذا كانت الحزمة مجرد تجميع. قلل عناصر المكونات بدلاً من ذلك. عبوة 3 قطع يجب أن تقلل ثلاث وحدات من نفس الـ SKU؛ الكيِت يجب أن يقلل وحدة واحدة من كل مكوّن.

مثال: "طقم البداية" يتضمن 1 زجاجة و2 فلتر. إذا كان لديك 10 زجاجات و15 فلتر، توفر الطقم هو 7 لأن الفلاتر هي المحدّ.

الرياضيات المعتمدة على المكونات تحافظ على تناسق التقارير والمرتجعات وإعادة التخزين.

في AppMaster، ينسجم هذا بسهولة مع جداول المتغيرات في Data Designer ومنطق الحجز/الخصم في محرر العمليات التجارية، بحيث يتبع كل سحب القواعد نفسها.

نمذجة الحزم والكيِتات دون كسر التقارير

تميل الحزم إلى أن تجعل الكتالوج ينزلق إلى حالات خاصة. أبسط نهج هو نمذجة الحزم كعناصر قابلة للبيع عادية، ثم إرفاق قائمة مكونات واضحة.

هيكل نظيف هو: المنتج (عنصر قابل للبيع) زائد BundleLines. كل BundleLine تشير إلى SKU مكوّن (أو منتج مكوّن بالإضافة إلى المتغير المطلوب) وتخزن كمية.

لاتزال الطلبات تعرض "عنصرًا واحدًا"، لكن يمكنك توسيعه إلى أجزاء عندما تحتاج التكلفة أو المخزون أو تفاصيل التنفيذ.

معظم إعدادات الحزم تنطبق في أحد الأنماط:

• حزمة ثابتة (كيِت): مكونات وكميات ثابتة دائمًا.
• حزمة قابلة للتكوين: يختار العميل من مكونات مسموح بها (محفوظة كخطوط على الطلب).
• حزمة افتراضية: تجميع تسويقي (غالبًا بدون أثر على المخزون)، مفيدة للعرض دون إجبار منطق التنفيذ.

التسعير هو المكان الذي يكسر فيه الفرق التقارير عن غير قصد. قرّر مسبقًا ما الذي يظهر على سطر الطلب، وما يغذي تقارير الهامش والمخزون. نُهج شائعة: سعر ثابت للحزمة، مجموع الأجزاء، أو مجموع مخفّض بقواعد لكل مكوّن (مثال: "اختر أي 3 عناصر، الأرخص بنصف السعر").

يجب أن يكون المخزون صارمًا بنفس الدرجة: يكون الكيِت متاحًا فقط إذا كان كل مكوّن مطلوب متاحًا بالكمية اللازمة. للتقارير، خزّن وجهتين للبيع:

• العنصر المباع: SKU الحزمة (للعائد، التحويل، والتسويق).
• المكونات المستهلكة: توسيع BundleLines (لحركة المخزون، COGS، وقوائم الالتقاط).

في AppMaster، ينسجم ذلك بطبيعة الحال: جدول Bundle زائد صفوف BundleLine، مع عمليات تجارية توسّع المكونات عند السحب وتكتب كلًا من بيع الحزمة واستهلاك المكونات في معاملة واحدة.

أنماط واجهة المستخدم لاختيار الخيارات والمتغيرات

واجهة الخيارات الجيدة تُبقي الناس مستمرين. الواجهة السيئة تجعلهم يخمنون، يواجهون أخطاء، ويغادرون. المفتاح هو إرشاد المتسوقين إلى متغير قابل للشراء مبكرًا، مع توضيح ما تغيّره اختياراتهم.

واجهة العميل: الخيارات أولًا، المتغيرات ثانيًا

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

مثال: بمجرد اختيار Color = Black، يجب أن تصبح المقاسات التي لا توجد باللون الأسود معطلة (وليس محذوفة)، حتى يفهم العميل ما هو غير متاح.

مع تغير الاختيار، حدّث الأجزاء الأكثر أهمية: السعر (بما في ذلك سعر العرض وأي خصم حزمة)، الصور الرئيسية (المتوافقة مع اللون أو النمط المختار)، حالة المخزون (مخزون المتغير الدقيق، لا مخزون المنتج العام)، تقدير التسليم (إذا اختلف حسب المتغير)، وخياراتًا إضافية مثل SKU أو "رمز العنصر" للدعم.

حافظ على واجهة هادئة. أظهر مجموعات خيارات قليلة في كل مرة، تجنّب القوائم الضخمة عندما تعمل العيّنات أو الأزرار بشكل أفضل، واجعل الاختيار الحالي واضحًا.

واجهة الإدارة: عدّل المتغيرات كشكل جدول بيانات

في الإدارة، يحتاج الناس السرعة لا الجمال. تعمل شبكة المتغيرات جيدًا: كل صف هو SKU، وكل عمود هو خيار أو قاعدة (سعر، باركود، وزن، مخزون، نشط/غير نشط). أضف إجراءات جماعية لمهام شائعة مثل تحديث الأسعار أو تبديل التوفر أو تعيين الصور.

إذا بنيت هذا في AppMaster، إعداد عملي هو شبكة مرتبطة بجدول Variant مع فلاتر (قيمة الخيار، الحالة النشطة، المخزون المنخفض)، وإجراء تحديث جماعي يتحقق من القواعد قبل الحفظ.

خطوة بخطوة: اختيار المتغير والتحقّق من توافر الحزم

يجب أن يبدو تدفق الاختيار بسيطًا، لكنه يحتاج قواعد صارمة تحت الغطاء. الهدف أن تعرف دائمًا أي SKU بالضبط يكوّن المتسوق، وهل يمكن شراؤه الآن.

اختيار المتغير (منتج واحد)

حمّل أكثر من اسم المنتج والصور. تحتاج المجموعة الكاملة من قيم الخيارات (مقاس، لون) وقائمة التركيبات الصالحة التي توجد كـ SKUs.

تدفق موثوق:

1. احصل على المنتج، خياراته، وكل المتغيرات الموجودة (أو خريطة مدمجة للتركيبات الصالحة).
2. خزّن اختيارات المتسوق الحالية (مثل: Size=M, Color=Black) وحدثها عند كل نقرة.
3. بعد كل تغيير، ابحث عن المتغير المطابق بمقارنة قيم الخيارات المختارة مع قائمة المتغيرات.
4. إذا وُجد مطابق وكان قابلًا للشراء (نشط، سعر محدد، غير محظور)، فعل زر "أضف إلى السلة".
5. إذا لم يوجد مطابق، إبقِ زر الإضافة معطلاً ووجّه المتسوق إلى اختيار صالح.

تفصيل بسيط يمنع الإحباط: عيّن قيم الخيارات المستحيلة بمجرد إجراء اختيارات سابقة. إذا كان Size=M يوجد فقط باللون الأسود، أظهر الألوان الأخرى غير متاحة بمجرد اختيار M.

توافر الحزمة (كيِت مكوّن من مكونات)

بالنسبة للحزم، "المتوفر" ليس رقمًا واحدًا. يعتمد على المكونات. القاعدة المعتادة:

bundle_available = minimum over components of floor(component_stock / component_qty_per_bundle)

مثال: طقم يحتاج 1 زجاجة و2 فلتر. إذا كان لديك 10 زجاجات و9 فلاتر، التوفر هو min(floor(10/1)=10, floor(9/2)=4) = 4 أطقم.

يجب أن تكون رسائل الخطأ عملية. أفضل أن تقول "متوفر فقط 4 أطقم (الفلاتر تحد هذا الطقم)" بدلًا من "غير متوفر". في AppMaster، من السهل التعبير عن هذا في عملية تجارية: احسب المتغير المطابق أولًا، ثم حدود الحزمة، ثم أعد حالة واضحة للواجهة لعرضها.

أخطاء فائدة يجب تجنّبها

ينهار الكتالوج عندما تصممه من أجل "كل ما قد يوجد" بدلًا من "ما ستبيعه فعلاً". أسرع طريقة لوضع نفسك في مأزق هي توليد كل تركيبة ممكنة مقدمًا، ثم محاولة الحفاظ على نظافتها مع نمو الكتالوج.

إنشاء متغيرات لن تُخزّن أبدًا هو الفخ الكلاسيكي. إذا كان لديك 4 ألوان × 6 مقاسات × 3 مواد = 72 متغيرًا، وإذا سيُباع منها 10 فقط فعليًا، فإن الـ 62 سجلًا المتبقية تخلق فوضى، تدعو للأخطاء، وتبطئ التقارير.

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

تفشل الحزم والكيِتات في المخزون عندما تخصم الحزمة ومكوناتها معًا. إذا بعت "طقم البداية" الذي يتضمن 1 زجاجة و2 فلتر، فإن خصم 1 طقم وخصم 1 زجاجة و2 فلتر يجعل المخزون يصل للصفر مبكرًا. احتفظ بالحزمة كعنصر قابل للبيع، لكن احسب التوفر والخصومات من مكوناتها.

أدوات الإدارة يمكن أن تسبب ضررًا إذا سمحت ببيانات غير صالحة. أضف حواجز مبكرًا:

• حظر SKUs المكررة، حتى عبر العناصر المؤرشفة.
• اجبر كل متغير على امتلاك كل قيم الخيارات (لا "مقاس مفقود").
• منع متغيرين من مشاركة نفس تركيبة القيم.
• التحقق من مكونات الحزمة (لا كميات صفرية، لا SKUs مفقودة).

أخيرًا، خطط للتغيير. إضافة خيار جديد لاحقًا (مثل "العرض" للأحذية) هي عملية ترحيل، ليست مجرد مربع اختيار. قرّر ماذا يحدث للمتغيرات الحالية، كيف تُعيَّن القيم الافتراضية، وكيف تحافظ الطلبات القديمة على لقطة خياراتها وSKU الأصلي.

فحوصات سريعة قبل الإطلاق

قبل الإطلاق، قم بجولة على الأشياء التي تكسر في الواقع: إيجاد SKUs، تحديث المخزون، ومنع الشراء المستحيل.

تأكد أن كل SKU قابل للبيع سهل الوصول. يجب أن يجد البحث SKU بالاسم، رمز SKU، الباركود/GTIN، والصفات الرئيسية (مثل المقاس أو اللون). إذا تستخدم المسح في المستودع، اختبر بعض المسحات الفيزيائية وتأكد أنها تصل إلى الـ SKU الدقيق، لا فقط المنتج الأب.

كن صارمًا بشأن أين تحدث تغييرات المخزون. اختر مصدر حقيقة واحد (منطق حركة المخزون) وتأكد أن كل حدث يستخدمه: الطلبات، الإلغاءات، المرتجعات، التعديلات اليدوية، وتجميع الحزم. إذا أمكن تعديل المخزون في شاشتين أو مسارين، فالانحراف مضمون.

فحوصات الإطلاق التي تستحق التشغيل:

• اختر الخيارات في الواجهة وتأكد أن التركيبات غير الصالحة تُحجب مبكرًا (قبل الإضافة للسلة)، وليس عند الدفع.
• بالنسبة للحزم، تأكد أن التوفر يقوده المكوّن الأكثر ندرة والكمية الصحيحة (2 بطارية لكل طقم يقلل التوفر للنصف).
• أوقف SKU وتحقق أنه يختفي من التصفح والبحث، لكنه لا يزال يظهر بشكل صحيح في الطلبات والفواتير والتقارير السابقة.
• نفّذ طلبًا تجريبيًا، ألغِه، ثم نفّذه مجددًا؛ يجب أن يعود المخزون ويحجز نظيفًا.

إذا كنت تبني في AppMaster، احتفظ بقواعد تحديث المخزون في عملية تجارية واحدة واستدعها من كل مسار. تلك العادة الواحدة تمنع معظم أخطاء المخزون.

مثال عملي وخطوات تالية عملية

تخيّل متجر ألبسة ما يزال بحاجة إلى كتالوج جاد.

تبيع قميصًا كلاسيكيًا بخيارين: المقاس (S, M, L) واللون (أسود، أبيض). كل تركيبة قابلة للشراء هي متغير مستقل مع SKU وسعر إن لزم وأيضًا مخزون مستقل.

في المخطط، احتفظ بسجل منتج واحد لـ "قميص كلاسيكي"، سجلين خيار (المقاس، اللون)، وعدة سجلات متغير. كل متغير يخزن قيم الخيارات المختارة (مثل: Size=M, Color=Black) وSKU (مثل: TSH-CL-M-BLK). يتتبع المخزون على مستوى المتغير، لا مستوى المنتج.

على الواجهة، قَصّر الخيارات وتجنّب النهايات الميتة. نمط نظيف: عرض كل الألوان أولًا، ثم عرض المقاسات التي توجد فقط للون المختار (أو بالعكس). إذا لم توجد "أبيض + L"، فلا تسمح باختياره، أو أظهره معطلاً مع ملاحظة واضحة.

أضف الآن حزمة: "طقم هدايا" يتضمن:

• 1x قميص كلاسيكي (أي متغير)
• 1x مجموعة ملصقات (SKU بسيط)

تُحدد توفر الحزمة بالمكوّن الأكثر قسوة. إذا كان مخزون مجموعة الملصقات 5، فلا يمكنك بيع أكثر من 5 حزم حتى وإن كان لدى القمصان مخزون كافٍ. إذا كانت الحزمة تتطلب متغير قميص محدد (مثل أسود M)، فالتوفر هو min(مخزون الملصقات، مخزون أسودM).

خطوات عملية تالية في AppMaster:

• ابنِ الجداول في Data Designer (Products, Options, OptionValues, Variants, VariantOptionValues, Inventory, Bundles, BundleComponents).
• نفّذ "إيجاد المتغيرات الصالحة" و"حساب توفر الحزم" في محرر العمليات التجارية.
• ولّد واجهات ويب ومحمول من نفس المشروع، مستخدمًا قواعد التصفية والتوافر نفسها في كل مكان.

إذا أردت طريقة سريعة لنموذج أولي شامل، فـ AppMaster (appmaster.io) مصمَّم لبناء تطبيقات كاملة بمنطق أعمال حقيقي، وهذا بالضبط ما تعتمد عليه قواعد اختيار المتغيرات وحساب مخزون الحزم.