वेरिएंट और बंडल के साथ उत्पाद कैटलॉग: स्कीमा और UI पैटर्न

क्यों वेरिएंट और बंडल जल्दी जटिल हो जाते हैं

एक कैटलॉग तब सरल दिखता है जब हर उत्पाद एक आइटम, एक कीमत और एक स्टॉक संख्या हो। रंग, साइज, सब्सक्रिप्शन अवधि, या क्षेत्र-विशेष पैकेजिंग जोड़ते ही यह सरलता टूट जाती है। एक ही “Products” तालिका अब बुनियादी सवालों का जवाब नहीं दे पाती: हम असल में क्या बेच रहे हैं, और इसे कैसे ट्रैक करें?

शॉपिंग करने वाले भी उम्मीद करते हैं कि जानकारी सही हो। वे विकल्प चुनना चाहते हैं, सही कीमत तुरंत देखना चाहते हैं, और जानना चाहते हैं कि उनकी चुनी हुई कॉम्बिनेशन आज भेजी जा सकती है या नहीं। अगर पेज कहता है “In stock” लेकिन चुनी गई साइज उपलब्ध नहीं है, तो भरोसा जल्दी घटता है। अगर कीमत केवल चेकआउट पर बदलती है, तो सपोर्ट टिकट और रिटर्न बढ़ते हैं।

बंडल एक दूसरी परत की जटिलता जोड़ते हैं क्योंकि वे प्रोडक्ट की तरह दिखते हैं पर नियमों की तरह व्यवहार करते हैं। एक “Starter Kit” में एक बोतल, एक पंप और फ़िल्टर्स का सेट हो सकता है। इसकी उपलब्धता पुर्जों पर निर्भर करती है, और आपकी लागत व रिपोर्टिंग का अर्थ भी साफ होना चाहिए।

आपका कैटलॉग पिघलने लगा है अगर:

• आप विकल्प दिखाने के लिए डुप्लिकेट SKUs बनाते हैं।
• स्टॉक काउंट गलत लगने लगते हैं, खासकर बंडल बिक्री के बाद।
• एडमिन स्क्रीन लगभग एक जैसी आइटम की लंबी सूचियों से भर जाती हैं।
• डिस्काउंट और टैक्स सिंगल आइटम के लिए काम करते हैं पर किट्स के लिए टूटते हैं।
• रिपोर्टिंग नहीं बता पाती कि “असल में क्या बेचा गया?”

इसे ठीक करने का हल ज्यादातर अनुशासन है: एक ऐसा डेटा मॉडल जो स्थिर रहे, और UI पैटर्न जो विकल्प चुनने और उपलब्धता को ग्राहकों व आपकी टीम के लिए स्पष्ट करते हों।

साधारण भाषा में शब्द: विकल्प, वेरिएंट, SKU, बंडल

जब लोग “वेरिएंट” कहते हैं, तो अक्सर वे कुछ अलग विचार मिला देते हैं। शब्दों को शुरू में सही रखना बाद में (स्कीमा, UI, इन्वेंटरी) के फैसलों को बहुत आसान बनाता है।

अधिकांश टीमें इन परिभाषाओं का उपयोग करती हैं:

• Option: ग्राहक द्वारा की जाने वाली पसंद, जैसे Size या Color।
• Option value: किसी Option के अंदर एक मान, जैसे Size = M या Color = Black।
• Variant: option values का एक सटीक संयोजन, जैसे Size M + Color Black।
• SKU: एक बिकने योग्य यूनिट जिसे आप ऑप्स और इन्वेंटरी में ट्रैक करते हैं। एक वेरिएंट अक्सर एक SKU से मैप होता है, पर हमेशा नहीं।
• Bundle / kit / multipack: अन्य उत्पादों से बना एक उत्पाद। Bundle एक मार्केटिंग ग्रुपिंग है (आप पार्ट्स को अलग भी बेच सकते हैं)। Kit “साथ ही भेजना चाहिए” वाला सेट है। Multipack वही आइटम कई बार दोहराना है (3-पैक मोज़े)।

IDs भी व्यवहार में उलझ जाती हैं। एक internal ID वह है जो आपका डेटाबेस इस्तेमाल करता है। SKU आपका ऑपरेशनल कोड है (पिकिंग, रीप्लेनिशमेंट, रिपोर्ट्स में)। Barcode (UPC/EAN) वही है जो स्कैनर्स पढ़ते हैं। एक SKU के कई बारकोड हो सकते हैं (विभिन्न रीजन), और कुछ आइटमों के पास कोई बारकोड भी नहीं होता।

यह तय करने का अच्छा नियम कि क्या कुछ बिकने योग्य वेरिएंट होना चाहिए: अगर उसकी कीमत, इन्वेंटरी, वजन या शिपिंग नियम अलग हो सकते हैं, तो इसे sellable मानें। उसी टी-शर्ट का Size M और Size XL आमतौर पर अलग स्टॉक गिनती मांगते हैं, इसलिए उन्हें अलग SKU होना चाहिए।

तय करें कि आपका कैटलॉग क्या सपोर्ट करेगा

स्कीमा चुनने से पहले उस सवालों से शुरू करें जिनके जवाब बिज़नेस को रोज चाहिए। जब कोई आइटम देखे, क्या आप भरोसे के साथ कह सकते हैं: क्या यह अभी उपलब्ध है, इसकी कीमत क्या है, कैसे शिप होगा, और कौन से टैक्स नियम लागू होंगे?

एक उपयोगी तरीका यह तय करना है कि हर “फैक्ट” किस जगह रहेगा। साझा तथ्य प्रोडक्ट पर रखें, और बदलने वाले तथ्य वेरिएंट (SKU) पर रखें। अगर आप दोनों जगह मिलाते हैं, तो एक ही बग को दो जगह फिक्स करने का चक्कर रहेगा।

जो सवाल आम तौर पर प्रोडक्ट-लेवल बनाम वेरिएंट-लेवल फील्ड तय करते हैं:

• अगर यह साइज/कलर/मटेरियल के अनुसार बदलता है, तो यह वेरिएंट पर होना चाहिए।
• अगर यह हर विकल्प संयोजन के लिए सही है, तो यह प्रोडक्ट पर होना चाहिए।
• अगर आप इसे SKU के हिसाब से रिपोर्ट करते हैं (बिक्री, मार्जिन, रिटर्न), तो इसे वेरिएंट पर स्टोर करें।
• अगर ऑपरेशंस इसे पिक/पैक/शिप के लिए इस्तेमाल करती है, तो उसे उसी जगह रखें जहाँ वे काम करते हैं: SKU पर।
• अगर यह सुरक्षित रूप से व्युत्पन्न किया जा सकता है (जैसे डिस्प्ले नाम option values से), तो इसे व्युत्पन्न करें और केवल सोर्स स्टोर करें।

एक स्रोत सत्य रखें। उदाहरण के लिए, “price” को दोनों जगह न रखें जब तक रोल्स स्पष्ट न हों (जैसे product में MSRP और variant में असली सेल प्राइस)।

बदलाव के लिए योजना बनाएं। आप बाद में नया option जोड़ सकते हैं (जैसे “Length”), कोई वेरिएंट रिटायर कर सकते हैं, या सप्लायर परिवर्तन के बाद SKUs मर्ज कर सकते हैं। यह सब तब सुगम होता है जब वेरिएंट पहली श्रेणी के रिकॉर्ड हों, सिर्फ लेबल न हों।

अगर आप AppMaster में बना रहे हैं, तो Data Designer में स्पष्ट एंटिटी नेमिंग आवश्यकताओं के बदलने पर मेंटेन करना आसान बनाती है।

उत्पादों और वेरिएंट के लिए एक व्यावहारिक स्कीमा

एक साफ स्कीमा उस समय कैटलॉग को समझने योग्य रखता है जब एक सरल उत्पाद दर्जनों बिकने योग्य कॉम्बिनेशन में बदल जाए। लक्ष्य है कि shoppers द्वारा किए गए choices (वे क्या चुनते हैं) को अलग रखें उन sellable आइटमों से (जो आप वास्तव में स्टॉक करते और शिप करते हैं)।

एक भरोसेमंद सेट एंटिटीज़:

• Product: पैरेंट आइटम (name, description, brand, category, default images)
• Option: एक choice type (Size, Color)
• OptionValue: अनुमति दी गई मान (Small, Medium, Red, Blue)
• Variant: बिकने योग्य यूनिट (एक मानों का संयोजन)
• VariantOptionValue: एक join तालिका जो Variant को उसके चुने हुए OptionValues से जोड़ती है

Variant यूनिकनेस वह जगह है जहाँ कई कैटलॉग गलत होते हैं। सबसे सुरक्षित तरीका नॉर्मलाइज़्ड है: हर Variant के लिए हर Option पर सिर्फ एक OptionValue लागू करें, और duplicate कॉम्बिनेशन रोकें। अगर आप गति भी चाहें, तो Variant पर एक कम्प्यूटेड “variant key” रखें जैसे color=red|size=m (या उसका हैश) और इसे Product के लिए unique बनाएं।

वे फील्ड जो हर कॉम्बिनेशन के अनुसार बदलते हैं, उन्हें Variant पर रखें, न कि Product पर: SKU, barcode, price, compare-at price, cost, weight, dimensions, status (active/discontinued), और images (या तो एक मुख्य इमेज या एक छोटा इमेज सेट)।

कस्टम एट्रिब्यूट्स (जैसे “material” या “care instructions”) के लिए नए कॉलम जोड़ते रहने से बचें। PostgreSQL में Product या Variant पर एक JSONB फील्ड अच्छा काम करता है, और ऐप में एक छोटा validation लेयर जोड़ें।

SKU नियम जो समय के साथ टिकें

SKU उस बिकने योग्य यूनिट की पहचान है जिसे आप बनाये रखने का वादा करते हैं। इसे एक सवाल का जवाब देना चाहिए: “हमने असल में कौन सा आइटम बेचा?” इसे आपका मार्केटिंग नाम, पूरा विकल्प टेक्स्ट, सीजन या कोई पूरी कहानी नहीं बनाना चाहिए। अगर आप इसे ओवरलोड कर देंगे, तो बाद में कुछ भी बदलना मुश्किल हो जाएगा और रिपोर्ट टूटेंगी।

शुरू में तय करें कि SKUs मैन्युअल असाइन होंगे या जनरेटेड। मैन्युअल SKUs तब बेहतर हैं जब आपके पास ERP, बारकोड, या सप्लायर SKUs हैं जो मेल खाना चाहिए। जनरेटेड SKUs तब बेहतर हैं जब आपके पास बहुत सारे वेरिएंट हों और आपको कंसिस्टेंसी चाहिए, बशर्ते नियम बीच में बदलें नहीं। एक सामान्य माध्यम यह है कि आपके पास एक फिक्स्ड बेस SKU हो जिसे आप कंट्रोल करते हैं, और वेरिएंट एट्रिब्यूट्स के लिए एक छोटा जनरेटेड सफिक्स हो।

पढ़ने योग्य और बढ़ने पर टिकने वाले नियम:

• एक बार ऑर्डर होने के बाद SKUs स्थिर रखें। पुराने SKUs को कभी नाम बदल कर “फिक्स” न करें।
• internal ID को SKU से अलग रखें। SKU लोगों के लिए, ID डेटाबेस के लिए।
• प्रोडक्ट फैमिली के लिए छोटे प्रीफिक्स का प्रयोग करें (उदाहरण: TSH, MUG), पूरे शब्द नहीं।
• ऐसे अर्थ से बचें जो बदल सकते हैं (जैसे “2026” या “SUMMER”) जब तक कि आपका बिज़नेस वाकई वैसा न चले।

डिसकंटिन्यूड SKUs को हटाना नहीं चाहिए। उन्हें inactive मार्क करें, उनकी प्राइस हिस्ट्री रखें, और उन्होंने जो पुरानी ऑर्डर्स, रिफंड्स और रिपोर्ट्स में दिखना चाहिए, वैसा रखें। अगर आप SKU बदलते हैं, तो एक “replaced by” रेफरेंस रखें ताकि सपोर्ट ट्रेस कर सके क्या हुआ।

वैलिडेशन नियम समय के साथ धीमी क्षति को रोकते हैं: सभी sellable आइटमों में SKU यूनिकनेस enforce करें, केवल letters, numbers और hyphens की अनुमति दें, एक स्पष्ट max length सेट करें (अक्सर 20-32 chars), और विशेष मामलों के लिए प्रीफिक्स रिज़र्व रखें (जैसे “BND-” बंडल्स के लिए)। AppMaster में ये चेक डेटा constraints और एक Business Process के रूप में अच्छे से फिट होते हैं जो नियम टूटने पर सेव को ब्लॉक करते हैं।

सरल 'इन-स्टॉक' और 'आउट-ऑफ-स्टॉक' से आगे इन्वेंटरी लॉजिक

इन्वेंटरी तब भ्रमित हो जाती है जब वही “प्रोडक्ट” कई अलग बिकने योग्य यूनिट्स का मतलब रखता है। नियम लिखने से पहले तय करें कि आपका इन्वेंटरी यूनिट क्या होगा: क्या आप स्टॉक को प्रोडक्ट लेवल पर ट्रैक करेंगे, वेरिएंट लेवल पर, या दोनों पर?

अगर ग्राहक साइज या कलर चुनते हैं, तो वेरिएंट-लेवल स्टॉक सामान्यतः सबसे सुरक्षित होता है। एक शर्ट overall में “in stock” हो सकता है, पर Small-Blue वेरिएंट sold out हो सकता है। प्रोडक्ट-लेवल स्टॉक उन आइटमों के लिए काम करता है जहाँ वेरिएंट्स भौतिक रूप से स्टोर किए जाने वाले आइटम को नहीं बदलते (उदाहरण: डिजिटल लाइसेंस के अलग-बिलिंग प्लान)। कुछ टीमें दोनों रखती हैं: रिपोर्टिंग के लिए प्रोडक्ट-लेवल, और बिक्री के लिए वेरिएंट-लेवल।

Overselling रोकना किसी एक जादुई फ्लैग से ज्यादा स्पष्ट स्टेट्स की बात है। ज्यादातर कैटलॉग्स को reservations (कार्ट या unpaid ऑर्डर के लिए यूनिट अस्थायी रखना), backorders (बिक्री की अनुमति देना पर स्पष्ट शिप डेट बताना), stock buffers (sync देरी को कवर करने के लिए छिपी मात्रा), और atomic updates (स्टॉक घटाने का ऑपरेशन उसी समय जो ऑर्डर कन्फर्म करता है) की जरूरत होती है।

एज केस वह जगह हैं जहाँ “मिस्ट्री स्टॉक” आता है। रिटर्न केवल इंस्पेक्शन के बाद स्टॉक में जोड़ना चाहिए, न कि जब रिटर्न लेबल बनाया जाए। डैमेज्ड आइटम्स को अलग स्टेटस या लोकेशन पर भेजें ताकि वे sellable न दिखें। स्टॉक समायोजन का ऑडिट ट्रेल होना चाहिए (किसने क्या और क्यों बदला), खासकर अगर कई चैनल इन्वेंटरी अपडेट करते हैं।

बंडल्स और किट्स के लिए एक प्रमुख नियम: अगर बंडल सिर्फ एक ग्रुपिंग है तो उस बंडल रिकॉर्ड को decrement न करें। इसके बजाय, कंपोनेंट आइटम्स को घटाएँ। एक 3-पैक को उसी SKU की 3 इकाइयाँ घटानी चाहिए; एक किट में हर कंपोनेंट की एक इकाई घटेगी।

उदाहरण: एक "Starter Kit" में 1 बोतल और 2 फ़िल्टर्स हैं। अगर आपके पास 10 बोतलें और 15 फ़िल्टर हैं, तो किट की उपलब्धता 7 है क्योंकि फ़िल्टर्स सीमा हैं। कंपोनेंट-आधारित गणित रिपोर्टिंग, रिफंड और रेस्टॉकिंग को सुसंगत रखता है।

AppMaster में यह साफ़ तौर पर Variant तालिकाओं और Business Process Editor में reservation/decrement लॉजिक से मैप होता है, ताकि हर चेकआउट एक जैसे नियमों का पालन करे।

रिपोर्टिंग तोड़े बिना बंडल और किट मॉडल करना

बंडल्स वे जगह हैं जहाँ कैटलॉग अक्सर स्पेशल केस की तरफ भागते हैं। सबसे सरल तरीका यह है कि बंडल्स को सामान्य sellable आइटम्स के रूप में मॉडल करें, फिर उन्हें कंपोनेंट्स की स्पष्ट सूची से जोड़ें।

एक साफ संरचना है: Product (sellable item) प्लस BundleLines। हर BundleLine किसी कंपोनेंट SKU (या कंपोनेंट प्रोडक्ट और आवश्यक वेरिएंट) की ओर इशारा करती है और एक मात्रा स्टोर करती है। ऑर्डर अभी भी “एक आइटम” दिखाएगा, पर जब आपको लागत, इन्वेंटरी और फुलफिलमेंट डिटेल चाहिए तो आप इसे पार्ट्स में एक्सपेंड कर सकते हैं।

अधिकांश बंडल सेटअप इन में से एक फिट होते हैं:

• Fixed bundle (kit): हमेशा वही कंपोनेंट्स और मात्राएँ।
• Configurable bundle: ग्राहक अनुमत कंपोनेंट्स में से चुनता है (फिर भी ऑर्डर पर लाइनों के रूप में सेव होता है)।
• Virtual bundle: मार्केटिंग ग्रुपिंग (अक्सर इन्वेंटरी प्रभाव नहीं), मर्चेंडाइजिंग के लिए उपयोगी बिना फुलफिलमेंट लॉजिक के।

प्राइसिंग वह जगह है जहाँ टीमें गलती से रिपोर्टिंग तोड़ देती हैं। पहले से तय करें कि ऑर्डर लाइन पर क्या दिखाई देगा, और क्या मार्जिन व इन्वेंटरी रिपोर्ट्स को फीड करेगा। सामान्य तरीके हैं: फिक्स्ड बंडल प्राइस, पार्ट्स का जोड़, या डिस्काउंटेड सम (उदाहरण: “किसी भी 3 आइटम चुनें, सबसे सस्ता 50% ऑफ”)।

इन्वेंटरी में समान सख्ती रखें: एक किट तभी उपलब्ध है जब हर आवश्यक कंपोनेंट आवश्यक मात्रा में उपलब्ध हो। रिपोर्टिंग के लिए बिक्री के दो दृश्यों को स्टोर करें:

• Sold item: बंडल SKU (राजस्व, कन्वर्शन, और मर्चेंडाइजिंग के लिए)।
• Consumed components: विस्तारित BundleLines (स्टॉक मूवमेंट, COGS, और पिकिंग लिस्ट के लिए)।

AppMaster में यह नेचुरली फिट होता है: एक Bundle तालिका और BundleLine पंक्तियाँ, Business Processes जो चेकआउट पर कंपोनेंट्स को एक्सपेंड करती हैं और एक ट्रांजैक्शन में बंडल सेल और कंपोनेंट उपभोग दोनों लिखती हैं।

विकल्प और वेरिएंट चुनने के लिए UI पैटर्न

अच्छा ऑप्शन UI लोगों को आगे बढ़ने में मदद करता है। खराब UI उन्हें अनुमान लगाने, एरर झेलने, और छोड़ जाने पर मजबूर कर देता है। मुख्य बात यह है कि खरीदार को जल्दी से एक वास्तविक, खरीदने योग्य वेरिएंट की ओर निर्देशित करें, साथ ही साफ़ दिखाएँ कि उनकी पसंद क्या बदल रही है।

कस्टमर-फेसिंग: पहले विकल्प, फिर वेरिएंट

एक भरोसेमंद पैटर्न यह है कि आप विकल्प (Size, Color, Material) प्रस्तुत करें, फिर केवल वही चुनें दिखाएँ जो अब भी मायने रखता है।

ग्राहक को किसी भी कॉम्बिनेशन को चुनने दें और Add to cart पर फेल होने से बेहतर है कि आप असंभव कॉम्बिनेशन को तभी disable कर दें जब उपयोगकर्ता पहले से कोई विकल्प चुन चुका हो। उदाहरण के लिए, जब कोई Color = Black चुनता है, तो जो साइज Black में नहीं हैं उन्हें disabled कर दें (remove न करें), ताकि ग्राहक समझ सके क्या उपलब्ध नहीं है।

जैसे-जैसे चयन बदलता है, उन हिस्सों को अपडेट करें जो सबसे ज्यादा मायने रखते हैं: कीमत (सेल प्राइस और किसी भी बंडल डिस्काउंट सहित), मुख्य इमेज (चुने हुए रंग/स्टाइल के मेल खाने वाली), स्टॉक स्थिति (सटीक वेरिएंट स्टॉक, न कि सामान्य प्रोडक्ट स्टॉक), डिलीवरी अनुमान (अगर वेरिएंट के अनुसार बदलता है), और वैकल्पिक रूप से SKU या “Item code” सपोर्ट के लिए।

इंटरफ़ेस शांत रखें। कुछ विकल्प समूह एक बार में दिखाएँ, बड़े ड्रॉपडाउन से बचें जब swatches या बटन बेहतर काम करें, और वर्तमान चयन स्पष्ट रखें।

एडमिन-फेसिंग: वेरिएंट को स्प्रेडशीट जैसे एडिट करें

एडमिन में लोगों को गति चाहिए, सुंदरता नहीं। एक वेरिएंट ग्रिड अच्छा काम करता है: हर रो एक SKU, और हर कॉलम एक ऑप्शन या नियम (price, barcode, weight, stock, active/inactive)। आम कार्यों के लिए bulk actions जोड़ें जैसे price अपडेट, availability टॉगल, या images असाइन करना।

यदि आप इसे AppMaster में बनाते हैं, तो एक व्यावहारिक सेटअप है: Variant तालिका से बाइंडेड एक ग्रिड, फ़िल्टर्स (option value, active status, low stock), और बचाने से पहले नियमों का वैलिडेट करने वाली एक bulk update action।

चरण-दर-चरण: वेरिएंट चयन और बंडल उपलब्धता चेक

एक चयन फ़्लो सरल लगना चाहिए, पर इसके पीछे कड़े नियम होने चाहिए। लक्ष्य यह है कि हमेशा पता हो कि खरीदार किस सटीक SKU को कॉन्फ़िगर कर रहा है, और क्या इसे अभी खरीदा जा सकता है।

वेरिएंट चयन (सिंगल प्रोडक्ट)

प्रोडक्ट का नाम और इमेज ही लोड करने से अधिक चाहिए। आपको पूरे सेट के option values और वे वेरिएंट कॉम्बिनेशंस चाहिए जो SKU के रूप में मौजूद हैं।

एक भरोसेमंद फ्लो:

1. प्रोडक्ट, उसके विकल्प, और सभी मौजूद वेरिएंट (या वैध कॉम्बिनेशंस का एक संक्षिप्त मानचित्र) लोड करें।
2. शॉपर के वर्तमान चयन को स्टोर करें (उदा.: Size=M, Color=Black) और हर क्लिक पर अपडेट करें।
3. हर परिवर्तन के बाद, चयनित option values की तुलना अपने वेरिएंट लिस्ट से करके मिलान वेरिएंट खोजें।
4. अगर मिलान हो और वह purchasable हो (active, price सेट, blocked नहीं), तो Add to cart को सक्षम करें।
5. अगर कोई मिलान नहीं है, तो Add to cart disabled रखें और शॉपर को वैध विकल्प की ओर गाइड करें।

एक छोटा UI डिटेल जो निराशा रोके: पहले किए गए विकल्पों के तुरंत बाद असंभव option values को disable कर दें। अगर Size=M केवल Black में है, तो M चुनते ही अन्य रंग unavailable दिखें।

बंडल उपलब्धता (कंपोनेंट्स से बना किट)

बंडल के लिए, “in stock” एक संख्या नहीं होती। यह कंपोनेंट्स पर निर्भर करती है। सामान्य नियम है:

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

उदाहरण: एक “Starter Kit” में 1 बोतल और 2 फ़िल्टर्स चाहिए। अगर आपके पास 10 बोतलें और 9 फ़िल्टर हैं, तो उपलब्धता है min(floor(10/1)=10, floor(9/2)=4) = 4 kits।

एरर संदेश स्पष्ट होने चाहिए। “Out of stock” की बजाय “सिर्फ 4 किट उपलब्ध हैं (यह बंडल फिल्टर्स से सीमित है)” बेहतर है। AppMaster में यह चेक Business Process में आसानी से व्यक्त किया जा सकता है: पहले matching variant निकालें, फिर बंडल लिमिट्स कैलकुलेट करें, और UI को दिखाने के लिए एक स्पष्ट स्थिति लौटाएँ।

सामान्य गलतियाँ और जाल जिनसे बचें

कैटलॉग तब टूटते हैं जब आप “जो कुछ भी मौजूद हो सकता है” के लिए मॉडल बनाते हैं बजाय “वह जो आप वाकई बेचेंगे” के। सबसे तेज़ तरीका खुद को कठिनाइयों में डालने का यह है कि आप हर संभावित विकल्प कॉम्बिनेशन पहले ही जेनरेट कर दें, फिर बढ़ते कैटलॉग को साफ रखते हुए जूझें।

वेरिएंट बनाना जो कभी स्टॉक नहीं होंगे क्लासिक जाल है। अगर आपके पास 4 रंग x 6 साइज x 3 मटेरियल हैं तो यह 72 वेरिएंट बनता है। अगर सिर्फ 10 बिकेंगे, तो बाक़ी 62 रिकॉर्ड कचरा, गलती के द्वार और रिपोर्टिंग धीमी करते हैं।

प्राइसिंग एक और चुपचाप बग का स्रोत है। समस्या तब शुरू होती है जब एक ही कीमत कई जगह मौजूद हो (product, variant, price table, promo table) बिना एक स्रोत सत्य के। एक सरल नियम मदद करता है: बेस प्राइस एक बार स्टोर करें, और ओवरराइड केवल वहीं रखें जहाँ सचमुच ज़रूरी हो (उदा., एक वेरिएंट की अलग कीमत)।

बंडल और किट इन्वेंटरी में तब फेल होते हैं जब आप बंडल और उसके कंपोनेंट्स दोनों को घटा देते हैं। अगर आप एक “Starter Kit” बेचते हैं जिसमें 1 बोतल और 2 फ़िल्टर्स हैं, और आप 1 kit घटाते हैं और साथ ही 1 बोतल और 2 फिल्टर्स भी घटाते हैं, तो स्टॉक बहुत जल्दी शून्य दिखेगा। बंडल को sellable आइटम के रूप में रखें, पर उपलब्धता और decrement उसके कंपोनेंट्स से कैलकुलेट करें।

एडमिन टूल्स नुकसान कर सकते हैं अगर वे अवैध डेटा की अनुमति देते हैं। जल्दी ही गार्डरेल जोड़ें:

• डुप्लिकेट SKUs को ब्लॉक करें, भले ही वे archived आइटमों में हों।
• हर वेरिएंट के लिए सभी option values आवश्यक करें (कोई “size missing” न हो)।
• दो वेरिएंट्स को एक ही option कॉम्बिनेशन शेयर करने से रोकें।
• बंडल कंपोनेंट्स की वैलिडेट करें (कोई zero मात्रा नहीं, कोई गुम SKU नहीं)।

अंत में, परिवर्तन के लिए योजना बनाएं। बाद में नया option जोड़ना (जैसे जूतों के लिए “Width”) एक माइग्रेशन है, चेकबॉक्स नहीं। तय करें पुराने वेरिएंट्स के साथ क्या होगा, डिफॉल्ट कैसे सेट होंगे, और पुराने ऑर्डर्स अपना मूल SKU और विकल्प स्नैपशॉट कैसे रखें।

शिप करने से पहले त्वरित चेक

लॉन्च से पहले उन चीजों पर एक पास कर लें जो असल जीवन में टूटती हैं: SKUs खोजना, स्टॉक अपडेट करना, और असंभव खरीद को रोकना।

सुनिश्चित करें कि हर sellable SKU आसानी से पहुँच में हो। सर्च को नाम, SKU कोड, barcode/GTIN, और प्रमुख एट्रिब्यूट्स (जैसे साइज या रंग) से खोज मिलने चाहिए। वेयरहाउस में स्कैनिंग का उपयोग करते हैं तो कुछ फिजिकल स्कैन टेस्ट करें और पुष्टि करें कि वे सटीक SKU पर आते हैं, सिर्फ पैरेंट प्रोडक्ट पर नहीं।

सख्ती से तय करें कि स्टॉक बदलाव कहाँ होते हैं। एक स्रोत सत्य चुनें (आपकी इन्वेंटरी मूवमेंट लॉजिक) और सुनिश्चित करें कि हर इवेंट उसे ही उपयोग करे: ऑर्डर, रद्द, रिफंड, मैन्युअल समायोजन, और बंडल असेंबली। अगर स्टॉक दो स्क्रीन या दो वर्कफ़्लो में एडिट हो सकता है, तो drift निश्चित है।

लॉन्च चेक जो चलाने योग्य हैं:

• UI में विकल्प चुनें और पुष्टि करें कि अवैध कॉम्बिनेशंस जल्द ही ब्लॉक हो जाते हैं (add-to-cart से पहले), न कि चेकआउट में पता चलें।
• बंडलों के लिए पुष्टि करें कि उपलब्धता सबसे तंग कंपोनेंट द्वारा और सही मात्रा से चलती है (किसी किट के लिए 2 बैटरियाँ चाहिए तो उपलब्धता आधी होनी चाहिए)।
• एक SKU रिटायर करें और जाँचें कि वह ब्राउज़िंग और सर्च से गायब हो, पर पुराने ऑर्डर्स, इनवॉइस और रिपोर्ट्स में सही दिखे।
• एक टेस्ट ऑर्डर रखें, उसे रद्द करें, फिर फिर से रखें; स्टॉक साफ़-सुथरा लौटना और पुनः आरक्षित होना चाहिए।

अगर आप AppMaster बना रहे हैं, तो स्टॉक अपडेट नियमों को एक Business Process में रखें और हर पथ से उसे कॉल करें। यही एक आदत अधिकांश इन्वेंटरी बग रोकती है।

उदाहरण परिदृश्य और व्यावहारिक अगले कदम

मान लीजिए एक एपरल शॉप है जिसे गंभीर कैटलॉग की जरूरत है।

आप एक टी-शर्ट बेचते हैं जिसमें दो विकल्प हैं: Size (S, M, L) और Color (Black, White)। हर खरीदी जा सकने वाली कॉम्बिनेशन अपना वेरिएंट, SKU, प्राइस (यदि आवश्यक), और इन्वेंटरी रखती है।

स्कीमा में, “Classic T-shirt” के लिए एक Product रिकॉर्ड रखें, दो Option रिकॉर्ड (Size, Color), और कई Variant रिकॉर्ड। हर Variant अपने चुने हुए option values स्टोर करता है (उदा.: Size=M, Color=Black) और SKU रखता है (उदा.: TSH-CL-M-BLK). इन्वेंटरी वेरिएंट-लेवल पर ट्रैक की जाती है, न कि प्रोडक्ट-लेवल पर।

UI पर, विकल्पों को संकुचित रखें और dead ends को रोकें। एक साफ पैटर्न यह है: पहले सभी Colors दिखाएँ, फिर चुने गए Color के लिए केवल वे Sizes दिखाएँ जो मौजूद हैं (या उल्टा)। अगर “White + L” मौजूद नहीं है, तो उसे सेलेक्ट करने की अनुमति न दें, या उसे disabled दिखाएँ और स्पष्ट नोट दें।

अब एक बंडल जोड़ें: “Gift Set” जिसमें शामिल हैं:

• 1x Classic T-shirt (किसी भी वेरिएंट)
• 1x Sticker pack (सरल SKU)

बंडल उपलब्धता सबसे तंग कंपोनेंट से सीमित होती है। अगर Sticker pack स्टॉक 5 है, तो आप 5 से अधिक बंडल नहीं बेच सकते, भले ही T-shirts पर्याप्त हों। अगर बंडल को किसी विशिष्ट T-shirt वेरिएंट (उदा., Black M) की आवश्यकता है, तो बंडल स्टॉक min(StickerPackStock, BlackMStock) होगा।

AppMaster में व्यावहारिक अगले कदम:

• Data Designer में तालिकाएँ बनाएं (Products, Options, OptionValues, Variants, VariantOptionValues, Inventory, Bundles, BundleComponents)।
• Business Process Editor में “find valid variants” और “calculate bundle availability” लागू करें।
• उसी प्रोजेक्ट से वेब और नेटिव मोबाइल UI जनरेट करें, और हर जगह वही वेरिएंट फिल्टरिंग और उपलब्धता नियम उपयोग करें।

यदि आप इसे तेज़ी से एंड-टू-एंड प्रोटोटाइप करना चाहते हैं, तो AppMaster (appmaster.io) पूरे ऐप्स के साथ रियल बिज़नेस लॉजिक बनाने के लिए डिज़ाइन किया गया है, और यही चीज़ वेरिएंट चयन और बंडल इन्वेंटरी नियमों पर निर्भर करती है।