एक SKU लेबल नहीं है। यह आपके पूरे ऑपरेशन की प्राथमिक कुंजी है — और अधिकांश स्टोर अपनी गलती से, एक बार में एक उत्पाद लॉन्च करके, अपनी योजना बनाते हैं।
3PL ऑनबोर्डिंग कॉल ठीक चल रही है जब तक कि वे आपकी मास्टर SKU फ़ाइल नहीं मांगते। आप कैटलॉग निर्यात करते हैं, CSV खोलते हैं, और इसे वैसे ही देखते हैं जैसे कोई अजनबी देखेगा: 8oz-amber, AMBER CANDLE 8, candle_amber_8oz_new, 00123, और Amber 8oz (2024 restock)। पांच नामकरण युग, एक उत्पाद। आप जानते हैं कि कौन सा क्या है। पृथ्वी पर कोई और नहीं जानता — जिसमें, जैसा कि पता चलता है, आपके कनेक्ट होने वाले आधे सॉफ़्टवेयर भी शामिल हैं।
इसलिए आप "SKU नामकरण सर्वोत्तम प्रथाएं" खोजते हैं और एक ही सलाह के पृष्ठ प्राप्त करते हैं: सुसंगत रहें, वर्णनात्मक रहें, इसे छोटा रखें। सब सच है, कुछ भी उपयोगी नहीं है, क्योंकि असली सवाल वे हैं जिन्हें वे पोस्ट छोड़ देते हैं। क्या SKU का *मतलब* कुछ होना चाहिए? किसका अपना SKU होना चाहिए? आपको वास्तविक बारकोड की आवश्यकता कब होती है? और वह जिसका कोई जवाब नहीं देता: जब तीन साल का बिक्री इतिहास पुराने नामों से जुड़ा हो तो आप एक खराब योजना को कैसे ठीक करते हैं?
SKU स्वच्छता बुनियादी ढांचा क्यों है, हाउसकीपिंग नहीं
अधिकांश स्टोर जिस झूठ के तहत काम करते हैं वह यह है: "एक SKU सिर्फ एक आंतरिक लेबल है — कोई भी अद्वितीय स्ट्रिंग काम करती है, और हम उन्हें बाद में हमेशा साफ कर सकते हैं।"
यह सच लगता है क्योंकि एक सिस्टम के अंदर, यह *सच* है। Shopify को परवाह नहीं है कि आपके SKU में स्पेस और इमोजी हैं। समस्या उस क्षण आती है जब दूसरा सिस्टम तस्वीर में आता है — और बड़े पैमाने पर, हमेशा और अधिक सिस्टम होते हैं। आपका प्लेटफ़ॉर्म बिक्री रिकॉर्ड करता है। आपका वेयरहाउस या 3PL उसे उठाता है। आपका इन्वेंट्री सॉफ़्टवेयर उसे गिनता है। आपका अकाउंटिंग सिंक उसे पोस्ट करता है। उन सिस्टमों में से कोई भी डेटाबेस साझा नहीं करता है। उन्हें जोड़ने वाली एकमात्र चीज़ SKU स्ट्रिंग है, जिसे अक्षर दर अक्षर मिलाया जाता है।
यह SKU को आपके ऑपरेशन की प्राथमिक कुंजी बनाता है, और प्राथमिक कुंजियों के नियम होते हैं जो लेबल के नहीं होते: हमेशा अद्वितीय, हमेशा स्थिर, श्रृंखला के हर सिस्टम में संग्रहीत और मिलान योग्य। "उन्हें बाद में साफ करें" महंगा हिस्सा है — एक प्राथमिक कुंजी का नाम बदलना हर उस जॉइन को तोड़ देता है जिसका वह संदर्भ देता है, जो ठीक वही माइग्रेशन समस्या है जिस पर हम आएंगे।
SKU नामकरण सर्वोत्तम प्रथाएं: एक ऐसी योजना डिजाइन करना जो बची रहे
दो ईमानदार दर्शन हैं, और राउंडअप आमतौर पर एक होने का दिखावा करते हैं।
संरचित SKU अर्थ को एन्कोड करते हैं: श्रेणी, उत्पाद लाइन, विशेषता, आकार। एक मानव पिक सूची को पढ़कर CDL-AMB-08 को 8 औंस एम्बर मोमबत्ती के रूप में पहचान सकता है और स्कैनर के बिना गलत चयन को पकड़ सकता है। इसकी कीमत नाजुकता है। उत्पादों को पुनर्वर्गीकृत किया जाता है, लाइनों का नाम बदला जाता है, एक विशेषता कोड अक्षरों से बाहर हो जाता है - और हर बार जब वास्तविकता एन्कोडिंग से हट जाती है, तो आप नाम बदलने का खिंचाव महसूस करेंगे। नाम बदलना सबसे बड़ा पाप है।
अनुक्रमिक SKU कुछ भी एन्कोड नहीं करते हैं: 10041, 10042, 10043। वे कभी झूठ नहीं बोलते, कभी नहीं बदलते, और कभी भी नाम बदलने की आवश्यकता नहीं होती है, क्योंकि उन्होंने कभी कुछ दावा नहीं किया। इसकी कीमत यह है कि मनुष्य उन्हें पढ़ नहीं सकते हैं, इसलिए सटीकता पूरी तरह से स्कैनिंग पर निर्भर करती है। वेयरहाउस-ग्रेड ऑपरेशन अनुक्रमिक रूप से खुशी-खुशी चलते हैं; रसोई की मेज पर ऑर्डर पैक करने वाला संस्थापक गलत पिक करेगा।
व्यावहारिक नियम: केवल वही एन्कोड करें जो आइटम के बारे में कभी नहीं बदलेगा, और बाकी सब कुछ देखें। श्रेणी और एक या दो पहचान विशेषताएँ आमतौर पर सुरक्षित होती हैं। आपूर्तिकर्ता, गोदाम स्थान, मूल्य स्तर, मौसम, वर्ष - कभी नहीं। ये अस्थिर तथ्य हैं जो उत्पाद फ़ील्ड में आते हैं जो SKU *से* जुड़े होते हैं, न कि उसमें *निर्मित* होते हैं। एक SKU जो आपूर्तिकर्ता को एन्कोड करता है, वह उस दिन झूठ बन जाता है जिस दिन आप आपूर्तिकर्ता बदलते हैं, और फिर आप भ्रामक कोड और विनाशकारी नाम बदलने के बीच चयन कर रहे होंगे।
आप जो भी दर्शन चुनें, स्वरूपण नियम गैर-परक्राम्य हैं, क्योंकि वे उस चीज़ के बारे में हैं जो हर CSV आयात, API कॉल और बारकोड स्कैन से बच जाती है:
- बड़े अक्षर, अंक, हाइफ़न। कुछ और नहीं। स्पेस को असंगत रूप से ट्रिम किया जाता है; स्लैश, एम्परसेंड और उद्धरण अंततः कहीं न कहीं URL और CSV पार्सिंग को तोड़ देते हैं।
- दो SKU को अलग करने के लिए केस पर कभी भरोसा न करें। कुछ सिस्टम केस-संवेदनशील होते हैं, कुछ नहीं -
abc-1औरABC-1एक टूल में दो उत्पाद हैं और अगले में टकराव है। - शून्य को आगे न रखें। स्प्रेडशीट उन्हें चुपचाप हटा देती हैं, और आपके SKU पाइपलाइन का आधा हिस्सा किसी बिंदु पर स्प्रेडशीट से होकर गुजरता है।
- O अक्षर को प्रतिबंधित करें (और I को प्रतिबंधित करने पर विचार करें)। कोई व्यक्ति अंततः हाथ से एक SKU टाइप करेगा, और O/0 भ्रम से अवास्तविक उत्पाद बनते हैं।
- इसे 20 वर्णों से कम रखें। फ़ील्ड सीमाएँ सिस्टम के अनुसार भिन्न होती हैं, और एक छोटा किया गया SKU एक मौन नाम परिवर्तन है।
- एक सेवानिवृत्त SKU को किसी भिन्न उत्पाद के लिए कभी भी पुन: उपयोग न करें। ऐतिहासिक रिपोर्ट हमेशा के लिए उस स्ट्रिंग पर जुड़ जाती हैं।
यहां बताया गया है कि यह लागू होने पर कैसा दिखता है। एक काल्पनिक घरेलू सामान ब्रांड, एल्डर और ऐश, पहले और बाद में:
| उत्पाद | पहले (अनुमान के पांच युग) | बाद में (CATEGORY-LINE-SIZE) |
|---|---|---|
| एम्बर मोमबत्ती, 8 औंस | 8oz-amber |
CDL-AMB-08 |
| एम्बर मोमबत्ती, 16 औंस | AMBER CANDLE 16 |
CDL-AMB-16 |
| देवदार मोमबत्ती, 8 औंस | candle_cedar_8oz_new |
CDL-CDR-08 |
| माचिस, मानक बॉक्स | 00123 |
MCH-STD-01 |
| विक ट्रिमर | ट्रिमर (2024) |
TLS-TRM-01 |
तीन खंड, सब कुछ बड़े अक्षरों में, कुछ भी अस्थिर एन्कोड नहीं किया गया है। योजना चतुर नहीं है। यही बात है - चतुर योजनाएं वे हैं जिन्हें अठारह महीनों में नाम बदलने की आवश्यकता होगी।
वेरिएंट विस्फोट की समस्या
किसी भी योजना का सबसे पहले परीक्षण उसके आकार/रंग मैट्रिक्स से होता है। 6 साइज़ और 8 रंगों में टी-शर्ट की एक स्टाइल 48 SKU है; दस स्टाइल 480 है। यहीं पर स्टोर या तो अपने कैटलॉग को बहुत बढ़ा देते हैं या उसे बहुत कम कर देते हैं, और दोनों ही नुकसानदायक हैं।
इसे हल करने वाला नियम: एक वेरिएंट का अपना SKU होना चाहिए यदि उसे अलग से गिना जाता है, चुना जाता है, खरीदा जाता है, या उसका मूल्य निर्धारित किया जाता है। एक बड़ा नीला टी और एक छोटा काला टी अलग-अलग भौतिक इकाइयाँ हैं जो अलग-अलग शेल्फ पर हैं — अलग SKU, कोई बहस नहीं। लेकिन उपहार रैप, उत्कीर्णन पाठ, वारंटी ऐड-ऑन? वे ऑर्डर-लाइन विकल्प हैं, स्टॉक इकाइयाँ नहीं। उन्हें SKU देना डाउनस्ट्रीम हर गिनती को दूषित करता है।
दो उप-नियम। उन वेरिएंट के लिए SKU न बनाएं जिन्हें आप वास्तव में स्टॉक नहीं करते हैं — एक सैद्धांतिक रंग मैट्रिक्स ब्लोट है जो हर सिंक और मैपिंग जॉब को धीमा कर देता है। और बंडल: एक किट जो प्री-असेंबल की गई है और एक इकाई के रूप में चुनी जाती है, वह एक वास्तविक SKU है; एक वर्चुअल बंडल को इसके बजाय घटक SKU को घटाना चाहिए। चाहे आपका इन्वेंट्री टूल उस अंतर को अच्छी तरह से संभालता है या नहीं, यह मूल्यांकन मानदंडों में से एक है जो IMS में मायने रखता है।
बारकोड SKU नहीं हैं
ये लगातार भ्रमित हो जाते हैं, और जैसे-जैसे आप स्केल करते हैं, अंतर मायने रखता है।
आपका SKU आंतरिक है। आपने इसका आविष्कार किया है, आप इसके मालिक हैं, यह मुफ़्त है, और इसका मतलब केवल आपके व्यवसाय के अंदर कुछ है। एक बारकोड — एक UPC या EAN, दोनों GTIN परिवार के सदस्य — उत्पाद के लिए एक वैश्विक पहचानकर्ता है, जो GS1 प्रणाली के माध्यम से जारी किया गया है, जिसका अर्थ है कि कोई भी उत्पाद को बेचता है, यह वही मायने रखता है।
आपको पंजीकृत वाले कब चाहिए? तीन दरवाजे, मोटे तौर पर सख्ती के क्रम में। मार्केटप्लेस: प्रमुखों को आम तौर पर उत्पाद सूचीबद्ध करने के लिए GTIN की आवश्यकता होती है (निजी-लेबल वस्तुओं के लिए ब्रांड-रजिस्ट्री और छूट पथ के साथ), और वे GS1 के अपने रिकॉर्ड के विरुद्ध कोड को मान्य करने की ओर बढ़ गए हैं — इसीलिए तीसरे पक्ष के पुनर्विक्रेताओं से सस्ते UPC ब्लॉक एक झूठी अर्थव्यवस्था हैं जो बाद में सत्यापन में विफल हो सकती हैं। रिटेल: यदि कोई चेन खरीदार कभी भी आपके उत्पाद को रजिस्टर पर स्कैन करता है, तो पंजीकृत कोड टेबल स्टेक हैं। 3PLs: लगभग सभी को हर यूनिट पर एक स्कैन करने योग्य बारकोड की आवश्यकता होती है — लेकिन कई खुशी-खुशी आपके अपने SKU का कोड 128 बारकोड स्वीकार करेंगे यदि आप खुदरा या मार्केटप्लेस में बिक्री नहीं कर रहे हैं, जिसमें आपका कोई खर्च नहीं होता है।
तो ईमानदार क्रम: पहले हमेशा साफ SKU; जब वेयरहाउस को स्कैन करने की आवश्यकता हो तो SKU-आधारित बारकोड; जब कोई मार्केटप्लेस या खुदरा विक्रेता दरवाजा खटखटाए तो पंजीकृत GTIN। आवश्यकताएँ और शुल्क बदलते रहते हैं — कुछ भी खरीदने से पहले वर्तमान GS1 आवश्यकताओं और प्रत्येक चैनल के लिस्टिंग नियमों की जाँच करें।
अपने इतिहास को तोड़े बिना SKU का नाम बदलना
अब मुश्किल वाला। आपने अपने कैटलॉग को देखा है और एक साफ योजना में माइग्रेट करना चाहते हैं। समस्या: आपके द्वारा चलाए जाने वाले हर सिस्टम पुराने स्ट्रिंग्स पर जुड़ते हैं। बिक्री वेग इतिहास, पुन: ऑर्डर पॉइंट, वेयरहाउस बिन असाइनमेंट, लेखांकन मैपिंग — इन-प्लेस का नाम बदलें और उन सभी जॉइन में से प्रत्येक चुपचाप टूट जाता है। इससे भी बदतर, सिस्टम इस बात पर असहमत हैं कि नाम बदलना क्या है: कुछ आपको SKU फ़ील्ड संपादित करने और उत्पाद के इतिहास को बनाए रखने देते हैं; अन्य बदले हुए SKU को शून्य इतिहास वाली एक बिल्कुल नई वस्तु मानते हैं। कुछ भी छूने से पहले जानें कि आपके प्रत्येक सिस्टम का व्यवहार कैसा है।
निरंतरता बनाए रखने वाला प्रवासन पैटर्न:
- पहले एक क्रॉसवाक तालिका बनाएँ — पुराना SKU, नया SKU, दिनांक, उत्पाद का नाम। यह फ़ाइल स्थायी है: यह कैसे एक 2024 रिपोर्ट और एक 2027 रिपोर्ट एक ही भौतिक उत्पाद का वर्णन करती है।
- एक स्वच्छ सीमा पर कट ओवर करें — भौतिक गणना के ठीक बाद, महीने के अंत में। शेल्फ लेबल और सिस्टम रिकॉर्ड एक साथ फ्लिप होने चाहिए, और गणना वह एकमात्र क्षण है जब आप दोनों पर भरोसा करते हैं।
- एक साथ हर सिस्टम में विंडो का समन्वय करें: प्लेटफ़ॉर्म, इन्वेंट्री टूल, 3PL (जिसे लीड टाइम की आवश्यकता होगी और री-लेबलिंग स्टॉक के लिए शुल्क ले सकता है), और आपके लेखांकन सिंक के उत्पाद मैपिंग। एक आधा-प्रवाहित सप्ताह — नए SKU पुराने को उठाते हुए गोदाम के साथ बिक रहे हैं — किसी भी स्थिर स्थिति से बदतर है।
- जहां सिस्टम उनका समर्थन करते हैं, वहां उपनामों का उपयोग करें, ताकि पुराने SKU संक्रमण के दौरान नए SKU में हल हो जाएं बजाय त्रुटि होने के।
- पुराने SKU को रिटायर करें; उन्हें कभी भी हटाएं या पुन: उपयोग न करें। वे आपका इतिहास रखते हैं। यदि कैटलॉग बड़ा है तो श्रेणी की लहरों में प्रवास करें — एक निहित गलती एक वैश्विक गलती से बेहतर है।
एक SKU, पांच सिस्टम — किताबों सहित
यहाँ उपरोक्त सभी का परीक्षण है: स्ट्रिंग CDL-AMB-08 का मतलब Shopify या WooCommerce में, 3PL के गोदाम प्रणाली में, आपके इन्वेंट्री टूल में, और आपकी लेखा फ़ाइल में एक ही भौतिक मोमबत्ती होना चाहिए। उनके बीच हर एकीकरण उस पर मेल खाता है, अक्षर दर अक्षर। जब मिलान विफल हो जाता है, तो कुछ भी इसकी घोषणा नहीं करता है — ऑर्डर अभी भी सिंक होता है, पिक अभी भी होता है। यह बस *गलत* होता है, और आपको गणना के समय या महीने के अंत में इसका पता चलता है।
किताबें वह जगह हैं जहाँ यह वित्तीय रूप से ठोस हो जाता है, इसलिए यहाँ एक पुल पैराग्राफ है जो यह पोस्ट आपको owes है। प्रति-उत्पाद लेखांकन — केवल राजस्व को एक साथ नहीं, बल्कि SKU द्वारा मार्जिन जानना — तभी काम करता है जब प्रत्येक SKU QuickBooks में एक विशिष्ट आइटम पर मैप होता है। वह SKU-स्तरीय उत्पाद मैपिंग ठीक वही है कि कैसे LedgerPort जैसा सिंक टूल प्रत्येक उत्पाद के राजस्व को सही जगह पर रूट करता है, और इसकी ऑटो-मैप सुविधा आपके कैटलॉग को SKU या उत्पाद नाम से QuickBooks आइटम से मिलाती है — जिसका अर्थ है कि एक स्वच्छ योजना एक पास में मैप हो जाती है, जबकि पांच-युग का कैटलॉग मैन्युअल मिलान और फ़ॉलबैक लंपिंग का मतलब है। टूल आपकी स्वच्छता को इनहेरिट करता है; यह इसे बना नहीं सकता। वह मैपिंग क्या संभव बनाती है — वास्तविक उत्पाद-स्तरीय लागत और मार्जिन दृश्यता — QuickBooks में Shopify विक्रेताओं के लिए COGS के हमारे गाइड में शामिल है।
अनाकर्षक भुगतान
आप नामकरण परंपराओं के लिए आए थे और एक डेटाबेस स्कीमा डिजाइन करने में समाप्त हुए — जो कि SKU का काम वास्तव में है। भुगतान डिजाइन द्वारा अदृश्य है: 3PL ऑनबोर्डिंग जहां मास्टर फ़ाइल को किसी स्पष्टीकरण की आवश्यकता नहीं है, इन्वेंट्री प्रवासन जिसमें महीनों के बजाय दिन लगते हैं, उत्पाद-मार्जिन रिपोर्ट जहां प्रत्येक पंक्ति का मतलब एक वास्तविक चीज़ है।
Alder & Ash की पहले और बाद की तालिका को डिजाइन करने में एक दोपहर और माइग्रेट करने में एक समन्वित महीने का अंत लगा — और अब से ब्रांड द्वारा जोड़ा गया प्रत्येक सिस्टम स्वच्छ संस्करण को इनहेरिट करता है। यही सौदा है: अब एक जानबूझकर दोपहर, बाद में हर एकीकरण पर एक चक्रवृद्धि कर के मुकाबले।
वही प्राथमिक कुंजी अंततः डॉलर ले जाती है, न कि केवल गणना, और डॉलर पक्ष के अपने स्वच्छता नियम होते हैं। जब आप उस आधे के लिए तैयार हों, तो ई-कॉमर्स लेखांकन के लिए हमारी संपूर्ण मार्गदर्शिका से शुरुआत करें।
