प्रत्येक रजिस्टर को संपादित किए बिना हर लोकेशन पर कीमत में बदलाव कैसे लागू करें?
यदि कीमत में बदलाव का मतलब हर रजिस्टर को संपादित करना है, तो कीमत आपके कैटलॉग में नहीं, बल्कि आपके हार्डवेयर में है। प्रति-रजिस्टर प्राइस बुक क्यों विफल होती हैं, कौन से वैकल्पिक समाधान काम करते हैं, और एक केंद्रीय संपादन को हर लोकेशन तक कैसे पहुँचना चाहिए।
Mathias NielsenCEO, Final POS
आप एक केंद्रीय कैटलॉग में एक बार बदलाव करके और हर रजिस्टर को उससे डेटा पढ़ने देकर हर लोकेशन पर कीमत में बदलाव लागू करते हैं। पूरा उत्तर यही है। यदि आपका सिस्टम इसके बजाय आपसे हर रजिस्टर के पास जाने, छह बैक ऑफिस में रिमोट एक्सेस करने या USB स्टिक से फ़ाइल लोड करने के लिए कहता है, तो कीमत वास्तव में आपकी मूल्य सूची (प्राइस लिस्ट) में नहीं है। यह हार्डवेयर में स्थित है। और जो कीमत हार्डवेयर में होती है, उसे वहीं बदलना पड़ता है जहाँ हार्डवेयर मौजूद है。
कीमत में बदलाव का मतलब हर रजिस्टर को संपादित करना क्यों होता है?
क्योंकि पुराने POS सिस्टम हर रजिस्टर को उसके अपने छोटे डेटाबेस के रूप में देखते हैं। डिवाइस एक स्थानीय प्राइस बुक (रजिस्टर की सहेजी गई वस्तुओं और कीमतों की सूची) स्टोर करता है, और चेकआउट उस स्थानीय कॉपी से पढ़ता है। हेड ऑफिस एक सही मास्टर स्प्रेडशीट रख सकता है, लेकिन रजिस्टर को यह पता नहीं होता कि वह अस्तित्व में है। जब रजिस्टर सिस्टम ऑफ रिकॉर्ड (वह कॉपी जिस पर वास्तव में सब भरोसा करते हैं) होता है, तो हर रजिस्टर को व्यक्तिगत रूप से बदलाव के बारे में बताना पड़ता है।
वह डिज़ाइन तब समझ में आता था जब रजिस्टर ऑफ़लाइन मशीनें थे और कनेक्टिविटी एक लग्जरी थी। सालों पहले यह समझ से बाहर हो गया, लेकिन डेटा मॉडल कई इंस्टॉल किए गए सिस्टम में बच गया, और कुछ नए सिस्टम में भी जिन्होंने इसकी नकल की। इसका परिणाम वही पैटर्न है जो रिपोर्टिंग के स्थान पर दैनिक CSV निर्यात का उपयोग में दिखता है: डेटा कहाँ स्थित है, इसकी भरपाई के लिए कर्मचारी लगातार एक मैन्युअल दिनचर्या चला रहे हैं।
प्रति-रजिस्टर मूल्य संपादन से वास्तव में आपको क्या नुकसान होता है?
इसमें लगने वाली शाम से भी ज़्यादा नुकसान होता है। इसके पूर्वानुमानित विफलताएँ:
लोकेशन के बीच अंतर आना (ड्रिफ्ट)। एक ही SKU (यूनिक प्रोडक्ट कोड) की कीमत डाउनटाउन में कुछ और मॉल में कुछ और दर्ज होती है क्योंकि मार्च में एक रजिस्टर छूट गया था। जब तक कोई ग्राहक नहीं टोकता, तब तक किसी का ध्यान नहीं जाता। इन्वेंट्री रिकॉर्ड पहले से ही खुद ब खुद बदलते रहते हैं; हाथ से कॉपी की गई कीमतों में अंतर और तेज़ी से आता है।
छूटे हुए डिवाइस। जो रजिस्टर बिक्री के बीच में था, बंद था, या अपडेट के दौरान जिसे भूल गए थे, उसमें पुरानी प्राइस बुक ही बनी रहती है, और वह हफ़्तों तक पुरानी कीमत ही वसूलता रहेगा।
शेल्फ टैग और रसीद में असमानता। मैन्युअल संपादन का हर दौर स्कैन की गई कीमत और शेल्फ पर लगे लेबल के मेल न खाने का एक नया मौका होता है, और जो ग्राहक इस अंतर को पकड़ लेता है, वह आपकी दुकान की अन्य कीमतों पर भी थोड़ा कम भरोसा करता है।
अस्पष्ट रिपोर्ट। जब एक ही हफ़्ते में एक उत्पाद तीन अलग-अलग कीमतों पर बिकता है, तो मार्जिन रिपोर्ट का कोई खास मतलब नहीं रह जाता, और समाधान/मिलान करना (आपकी रिपोर्ट का वास्तव में लेनदेन हुए पैसे से मिलान करना) एक कठिन शोध बन जाता है।
काम के घंटों के बाद का श्रम। प्रति-रजिस्टर संपादन दुकान बंद होने का इंतज़ार करते हैं, इसलिए या तो इनमें ओवरटाइम का खर्च आता है या ये लटके रहते हैं। जब सप्लायर की लागत पहले ही बढ़ चुकी हो, तो इंतज़ार का हर दिन उस मार्जिन का नुकसान है जो आप दान कर रहे हैं।
प्रति-रजिस्टर सिस्टम पर कौन से वैकल्पिक समाधान टिके रहते हैं?
यदि आप आज प्रति-रजिस्टर मूल्य निर्धारण के साथ अटके हुए हैं, तो कुछ दिनचर्या दूसरों की तुलना में कम विफल होती हैं:
बैच में काम करें, कभी भी दोबारा टाइप न करें। एक मास्टर प्राइस फ़ाइल रखें और इसे सिस्टम के निर्यात (एक्सपोर्ट) और आयात (इंपोर्ट) टूल के माध्यम से लोड करें, भले ही आपको इसे डिवाइस दर डिवाइस करना पड़े। कीपैड पर नंबरों को दोबारा टाइप करने से ही गलतियाँ शुरू होती हैं।
एक मास्टर रजिस्टर तय करें। यदि आपका सिस्टम एक रजिस्टर के कॉन्फ़िगरेशन को दूसरों में कॉपी कर सकता है, तो एक ही डिवाइस को स्रोत बनाएं और उसका क्लोन बनाएं। बिल्कुल न होने से आधा सिंक बेहतर है।
बदलाव की समय-सीमा की ज़िम्मेदारी लें। एक व्यक्ति, तारीख वाली एक मास्टर फ़ाइल, हर डिवाइस को शामिल करने वाली एक चेकलिस्ट। ज़्यादातर गलतफहमियाँ "मुझे लगा आपने रजिस्टर 2 कर दिया" से ही शुरू होती हैं।
देखकर नहीं, स्कैन करके सत्यापित करें। अपडेट के बाद, हर लोकेशन पर कुछ बदले हुए सामानों के लिए टेस्ट सेल चलाएँ। सेटिंग्स स्क्रीन कुछ और कह सकती है जबकि चेकआउट कुछ और कीमत वसूल सकता है।
मूल्य-परिवर्तन लॉग रखें। जब बाद में कीमतों में अंतर दिखाई देता है, तो तारीख वाला लॉग ही सही निदान और अंदाज़े के बीच का अंतर होता है।
ईमानदारी से समझें कि यह क्या है: एक डिज़ाइन त्रुटि का रखरखाव। यह हर कर-मुक्त खरीदार के लिए हाथ से कर हटाने जैसी ही श्रेणी में आता है, जहाँ एक व्यक्ति वह काम बार-बार कर रहा है जो डेटा मॉडल को एक बार में कर देना चाहिए था।
वास्तव में कीमत में बदलाव कैसे काम करना चाहिए?
कीमत केवल एक ही जगह होनी चाहिए: क्लाउड में एक केंद्रीय कैटलॉग, जहाँ हर रजिस्टर अपनी कॉपी का मालिक होने के बजाय उस कैटलॉग के क्लाइंट के रूप में काम करे। उत्पाद रिकॉर्ड बदलें और लागू (पुश) करने के लिए कुछ नहीं बचेगा, क्योंकि कोई अन्य चीज़ कीमत को सहेजकर नहीं रख रही है। पारंपरिक इंस्टॉलेशन की तुलना में क्लाउड सिस्टम का यही मुख्य तर्क है, जिसे हर व्यवसाय के लिए POS सिस्टम: आपके लिए कौन सा प्रकार सही है? में शामिल किया गया है।
Final POS में, कैटलॉग इसी तरह बनाया गया है। उत्पाद मर्चेंट हब में एक उत्पाद सूची (Product List) में रहते हैं, कीमत उत्पाद रिकॉर्ड का एक फ़ील्ड है, और आउटलेट (आपकी स्टोर लोकेशन) यह नियंत्रित करते हैं कि प्रत्येक उत्पाद कहाँ बेचा जाता है। हर आउटलेट पर हर स्टेशन एक ही रिकॉर्ड पढ़ता है, इसलिए एक बार कीमत संपादित करना ही पूरा काम है।
दो महत्वपूर्ण बातें। किसी अपडेट को प्राप्त करने के लिए रजिस्टर का ऑनलाइन होना अभी भी आवश्यक है, इसलिए सत्यापन चरण केवल यह पुष्टि करने तक सीमित रह जाता है कि डिवाइस कनेक्ट हैं या नहीं, न कि फिर से नंबर दर्ज करने में। और यदि आप जानबूझकर अलग-अलग लोकेशन पर अलग-अलग कीमतें वसूलते हैं, तो यह एक मूल्य निर्धारण निर्णय है जो एक नियम के रूप में कैटलॉग में होना चाहिए, न कि ऐसी चीज़ जिसे हाथ से रजिस्टरों में अंतर आने देकर फिर से बनाया जाए।
तो, प्रत्येक रजिस्टर को संपादित किए बिना हर लोकेशन पर कीमत में बदलाव कैसे लागू करें?
प्रति-रजिस्टर सिस्टम पर, आप ऐसा नहीं कर सकते। आप बदलाव को बैच करते हैं, जहाँ सिस्टम अनुमति देता है वहाँ क्लोन करते हैं, और टेस्ट स्कैन के साथ सत्यापित करते हैं, क्योंकि यह डिज़ाइन इससे बेहतर कुछ नहीं प्रदान करता है। केंद्रीय कैटलॉग वाले सिस्टम पर, आप उत्पाद को एक बार संपादित करते हैं और आपका काम हो जाता है। अंगूठे का नियम: यदि कीमत बदलने का मतलब हार्डवेयर को छूना है, तो इसके विपरीत होने के बजाय आपके रजिस्टर आपके कैटलॉग के मालिक हैं। यदि आप किसी नए सिस्टम का मूल्यांकन कर रहे हैं, तो अपने डेमो स्क्रिप्ट पर "एक कीमत बदलें और मुझे दिखाएं कि यह हर रजिस्टर पर लागू हुई" लिखें, फिर आपके स्विच करने के बाद पहले सप्ताह की सेटअप चेकलिस्ट के माध्यम से काम करें।
अक्सर पूछे जाने वाले प्रश्न
POS रजिस्टर पर प्राइस बुक क्या होती है?
यह रजिस्टर की स्थानीय रूप से सहेजी गई वस्तुओं और कीमतों की सूची है जिसे चेकआउट पढ़ता है। पुराने POS सिस्टम पर हर डिवाइस अपनी खुद की कॉपी रखता है, यही वजह है कि हर रजिस्टर पर कीमत में बदलाव को दोहराना पड़ता है।
मेरी लोकेशन एक ही उत्पाद के लिए अलग-अलग कीमतें क्यों दिखाती हैं?
क्योंकि हर रजिस्टर अपना खुद का कीमत डेटा रखता है, और किसी बिंदु पर एक डिवाइस से अपडेट छूट गया था। हाथ से कॉपी की गई कीमतों में उसी तरह अंतर आ जाता है जैसे हाथ से गिने गए स्टॉक में आता है; एक केंद्रीय कैटलॉग उन कॉपियों को हटा देता है जिनमें अंतर आता है।
मैं यह कैसे सत्यापित करूँ कि कीमत में बदलाव हर रजिस्टर तक पहुँच गया है?
प्रत्येक लोकेशन पर कुछ बदले हुए सामानों के लिए एक टेस्ट सेल चलाएँ। सेटिंग्स स्क्रीन नई कीमत प्रदर्शित कर सकती है जबकि चेकआउट अभी भी पुरानी कीमत वसूल रहा हो, इसलिए रसीद पर भरोसा करें, कॉन्फ़िगरेशन पेज पर नहीं।
क्या मैं जानबूझकर अलग-अलग लोकेशन पर अलग-अलग कीमतें निर्धारित कर सकता हूँ?
कुछ व्यवसाय जानबूझकर लोकेशन के आधार पर कीमत तय करते हैं, और यह कैटलॉग या मूल्य निर्धारण सेटिंग्स में एक नियम होना चाहिए, न कि प्रति डिवाइस मैन्युअल संपादन। इस पर भरोसा करने से पहले जाँच लें कि आपका सिस्टम लोकेशन प्राइसिंग को कैसे मॉडल करता है।
क्या क्लाउड POS हर लोकेशन पर तुरंत कीमतें अपडेट करता है?
बदलाव तुरंत साझा कैटलॉग पर लागू होता है। जो रजिस्टर ऑफ़लाइन है, वह फिर से कनेक्ट होने पर इसे प्राप्त कर लेता है, इसलिए बाकी जांच यह सुनिश्चित करना है कि प्रत्येक डिवाइस ऑनलाइन है या नहीं, न कि फिर से नंबर दर्ज करना।