कोटेशन और छूट की मंज़ूरी: एक कीमत जिसे सब जानते हों

कोटेशन और छूट की मंज़ूरी चार नियमों से नियंत्रण में रहती है: वैधता तारीखों वाली एक प्राइस लिस्ट जिससे सब कीमत तय करते हैं, क्रमांकित कोटेशन जिनमें नया संस्करण कभी उस संस्करण को नहीं मिटाता जिसे ग्राहक पहले ही देख चुका है, ऐसा मार्जिन जिसे मंज़ूरी देने वाला कोटेशन जाने से पहले देखता है, और एक छूट मंज़ूरी मैट्रिक्स जिसके स्तर मालिक तय करता है और जिसे याददाश्त नहीं बल्कि सिस्टम लागू करता है। जब ग्राहक किसी विशेष संस्करण को स्वीकार करता है, तो वह सेल्स ऑर्डर या अनुबंध बन जाता है, जिसकी ओर बाद की हर डिलीवरी, इनवॉइस और विवाद वापस इशारा करता है।

पहले भाग के अभ्यास से कोटेशन तक

पहले भाग में हमने उधार पर बिक्री को सात स्टेशनों के रूप में दिखाया था और एक अभ्यास सुझाया था: अपने दस सबसे पुराने बकाया इनवॉइस को उनके कोटेशन, उनके ऑर्डर और उनकी डिलीवरी के सबूत तक वापस खोजें। पहला दस्तावेज़ जो आपने खोजा, वह था ग्राहक द्वारा स्वीकार किया गया कोटेशन। अगर आपको तीन संस्करणों वाला कोटेशन मिला और किसी को पक्का नहीं पता कि कौन-सा स्वीकार हुआ, या ऐसी छूट मिली जिसके बारे में कोई नहीं बता सकता कि किसने दी, तो हम यहीं से शुरू करते हैं। कोटेशन से पहले जो आता है, यानी अवसरों और संभावित ग्राहकों की फ़ॉलो-अप, वह इस सीरीज़ से बाहर है; उसे हमने सऊदी व्यवसायों के लिए हमारी CRM गाइड में कवर किया है।

वैधता तारीखों वाली एक प्राइस लिस्ट

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

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

• फ़ैक्टरी या डिस्ट्रीब्यूटर। हर आइटम और बिक्री इकाई की कीमत, संभवतः हर ग्राहक समूह के लिए अलग लिस्ट के साथ, जैसे होलसेल और प्रोजेक्ट, जहाँ मालिक तय करता है कि कौन किस समूह में आता है।
• कॉन्ट्रैक्टर। बार-बार आने वाले कार्य-आइटमों की यूनिट दरें, जिनसे हर कोटेशन में बिल ऑफ़ क्वांटिटीज़ की कीमत लगती है, उन आइटमों के साथ जिनकी कीमत प्रोजेक्ट दर प्रोजेक्ट तय होती है।
• मेंटेनेंस कंपनी या प्रॉपर्टी ऑपरेटर। किसी परिभाषित दायरे के लिए एक विज़िट, एक घंटे या मासिक अनुबंध की कीमत, और उस कीमत में क्या शामिल है बनाम क्या अलग से लिया जाता है, जैसे स्पेयर पार्ट्स और अतिरिक्त काम।

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

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

क्रमांकित कोटेशन: हर संस्करण वैसा ही रहता है जैसा ग्राहक ने देखा

पहले भाग में हमने एक ऐसी छूट का वर्णन किया था जो WhatsApp पर भेजे गए संशोधित संस्करण में दिखाई दी और कभी ऑर्डर के साथ सहेजी नहीं गई। ऐसा इसलिए होता है क्योंकि कोटेशन आमतौर पर उसी फ़ाइल में संशोधित होते हैं: सेल्सपर्सन कोटेशन खोलता है, कीमत या मात्रा बदलता है, और पिछले संस्करण के ऊपर सेव कर देता है। दो हफ़्ते बाद ग्राहक कोटेशन स्वीकार करता है, लेकिन कौन-सा संस्करण? जो सेल्सपर्सन के लैपटॉप पर है, ज़रूरी नहीं कि वही ग्राहक के पास हो।

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

कोटेशन में केवल कीमत नहीं, बल्कि वह सब भी होता है जिसकी आगे हर किसी को ज़रूरत पड़ेगी:

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

जब ग्राहक किसी विशेष संस्करण को स्वीकार करता है, तो वह संस्करण सेल्स ऑर्डर या अनुबंध बन जाता है, और अगर ग्राहक ने परचेज़ ऑर्डर नंबर भेजा है तो वह भी उसके साथ सहेजा जाता है। उस क्षण से हर डिलीवरी, इनवॉइस और विवाद इसी ऑर्डर की ओर इशारा करता है, इसलिए किसी भी इनवॉइस से आप उस कीमत तक पहुँच सकते हैं जिसे ग्राहक ने स्वीकार किया और यह भी कि उसकी छूट किसने मंज़ूर की, जो ठीक वही है जिसे आप पहले भाग के अभ्यास में खोज रहे थे।

कोटेशन जाने से पहले मंज़ूरी देने वाले के सामने मार्जिन

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

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

तब मंज़ूरी देने वाला एक ही स्क्रीन पर लिस्ट कीमत, माँगी गई कीमत, लागत, छूट से पहले और बाद का मार्जिन, और सेल्सपर्सन द्वारा लिखा गया कारण देखता है: किसी प्रतिस्पर्धी की कीमत, बड़ी मात्रा, या किसी ऐसे सेक्टर का नया ग्राहक जिसमें कंपनी प्रवेश करना चाहती है। वही छूट एक कोटेशन पर स्वीकार्य और दूसरे पर अस्वीकार्य हो सकती है, क्योंकि हर एक के पीछे का मार्जिन अलग है।

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

छूट मंज़ूरी मैट्रिक्स: कौन-सी छूट कौन मंज़ूर करता है?

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

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

संख्याओं से ज़्यादा ज़रूरी यह जानना है कि छूट किसे माना जाए, क्योंकि कीमत में रियायत हमेशा "छूट" नाम की पंक्ति पर नहीं आती:

• स्पष्ट छूट किसी कोटेशन पंक्ति पर या कोटेशन के कुल योग पर।
• बिना शुल्क के अतिरिक्त मात्रा, या डिलीवरी और इंस्टॉलेशन जिनका सामान्यतः शुल्क लगता है और अब मुफ़्त हैं।
• इस ग्राहक की सामान्य शर्तों से लंबी भुगतान शर्तें, क्योंकि वह आपकी अपनी नकदी से दिया गया वित्तपोषण है।
• मेंटेनेंस अनुबंध पर अतिरिक्त विज़िट, सामान्य से लंबी वारंटी, या दायरे से बाहर का छोटा काम बिना शुल्क के।

ये सभी एक ही मैट्रिक्स से गुज़रते हैं; वरना आप लिखी हुई छूट को नियंत्रित करते हैं और बिना लिखी रियायत को अनियंत्रित छोड़ देते हैं। ख़रीद की तरफ़ के नियम यहाँ भी लागू होते हैं: कोई अपनी ही छूट मंज़ूर नहीं करता, अधिकार व्यक्ति का नहीं बल्कि भूमिका का होता है, हर मंज़ूरी देने वाले का उसकी अनुपस्थिति के लिए एक नामित प्रतिनिधि होता है, और मंज़ूरी कोटेशन संस्करण पर ही मंज़ूरी देने वाले के नाम और समय के साथ दर्ज होती है, ताकि अगर मंज़ूरी के बाद संस्करण बदले तो वह उनके पास वापस जाए। अनुरोध मंज़ूरी देने वाले के फ़ोन पर एक लिंक के रूप में पहुँचता है जिससे वे लैपटॉप खोले बिना मंज़ूरी दे सकें, क्योंकि धीमी मंज़ूरी ही सेल्सपर्सन को फ़ोन पर वादा करने की ओर धकेलती है।

इनवॉइस से पहले क्यों और बाद में क्यों नहीं? कोटेशन में मंज़ूर की गई छूट कीमत का हिस्सा होती है और पहली बार में ही इनवॉइस पर दिखती है। बिक्री के बाद वादा की गई छूट VAT कार्यान्वयन विनियमों के तहत अलग रास्ता लेती है: अनुच्छेद 40(1) आपूर्ति का मूल्य बदलने वाली स्थितियों में उस मूल्य को गिनता है जिस पर पहले से सहमति हुई और फिर किसी भी कारण से बदल गया, जिसमें बिक्री पूरी होने के बाद दी गई अतिरिक्त छूट भी शामिल है। अगर ऐसा टैक्स इनवॉइस जारी होने के बाद होता है और उस पर लगा VAT देय VAT से अधिक है, तो अनुच्छेद 54 एक ऐसा क्रेडिट नोट माँगता है जो मूल इनवॉइस का स्पष्ट संदर्भ दे, और जो घटना वाले महीने के अगले महीने की 15 तारीख तक जारी हो। तो इनवॉइस के बाद किसी कॉल पर दी गई छूट सेल्सपर्सन और ग्राहक के बीच नहीं रहती; वह समय-सीमा वाला टैक्स दस्तावेज़ बन जाती है, और हो सकता है फ़ाइनेंस को पता ही न हो कि उसे वह जारी करना है। किसी विशेष मामले के लिए पूछने की जगह आपका टैक्स सलाहकार है।

Origami का दृष्टिकोण

जब हम किसी कंपनी के लिए कोटेशन वर्कफ़्लो बनाते हैं, तो हम इससे शुरू करते हैं कि वह आज वास्तव में कीमत कैसे तय करती है: सेल्सपर्सन कीमतें कहाँ से लेते हैं, एक कोटेशन आमतौर पर कितने संस्करणों से गुज़रता है, छूट कौन मंज़ूर करता है, और प्रमुख ग्राहकों की विशेष कीमतें कहाँ रहती हैं। फ़ोन पर दी गई छूट हमें यह बताने से पहले कि नियंत्रण कहाँ कड़ा करना है, यह बताती है कि मौजूदा मंज़ूरी कहाँ बहुत धीमी है।

फिर हम उसे ऐसे वर्कफ़्लो में बदलते हैं जिसे सिस्टम लागू करता है: वैधता तारीखों वाली प्राइस लिस्ट, क्रमांकित संस्करणों वाले कोटेशन जिनकी फ़ाइलें रिकॉर्ड से आती हैं, हर भूमिका को उसकी अनुमतियों के अनुसार दिखाया गया मार्जिन, एक छूट मैट्रिक्स जिसके स्तर मालिक बिना प्रोग्रामर के बदल सकता है, फ़ोन तक पहुँचने वाली मंज़ूरियाँ, और एक स्वीकृत कोटेशन जो आपके अकाउंटिंग सिस्टम और ई-इनवॉइसिंग से जुड़ा सेल्स ऑर्डर बन जाता है। यह उन कस्टम सिस्टम का हिस्सा है जो हम हमारी सेवाओं के तहत बनाते हैं।

इस हफ़्ते का अभ्यास: अपने ग्राहकों द्वारा स्वीकार किए गए पिछले बीस कोटेशन की समीक्षा करें

किसी भी सिस्टम से पहले, आपको इस बात की तस्वीर चाहिए कि प्राइस लिस्ट और ग्राहक के बीच वास्तव में क्या होता है। एक सेल्स मैनेजर और एक फ़ाइनेंस मैनेजर इसे एक या दो बैठकों में कर सकते हैं:

• ग्राहकों द्वारा स्वीकार किए गए पिछले बीस कोटेशन निकालें, और अगर पहले भाग के अभ्यास में आपको दस इनवॉइस के पीछे के कोटेशन मिले थे तो उन्हें भी जोड़ें।
• हर कोटेशन के लिए पूछें कि कीमत कहाँ से आई: मौजूदा प्राइस लिस्ट से, किसी पुराने कोटेशन से, या हाथ से टाइप की गई।
• हर कोटेशन के संस्करण गिनें, उस संस्करण की पहचान करें जिसे ग्राहक ने स्वीकार किया, और जाँचें कि क्या आप उसे ठीक वैसा ही ढूँढ सकते हैं जैसा उसने देखा था।
• कोटेशन में हर रियायत की सूची बनाएँ: छूट, मुफ़्त मात्रा, मुफ़्त डिलीवरी, लंबी भुगतान शर्तें या अतिरिक्त विज़िट, और हर एक के बगल में यह कि उसे किसने मंज़ूर किया और वह मंज़ूरी कहाँ दर्ज है।
• नोट करें कि क्या मार्जिन ज्ञात था उस व्यक्ति को जिसने कोटेशन मंज़ूर किया, ठीक उस क्षण जब उसने मंज़ूरी दी।

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

अगले भाग में

अब कीमत का एक स्रोत है, कोटेशन के संस्करण सुरक्षित हैं, और हर छूट का एक मंज़ूरी देने वाला है जिसे सब जानते हैं। अगला भाग पहली शिपमेंट से पहले के स्टेशन पर जाता है: क्रेडिट सीमाएँ और गारंटियाँ। हम एक ऐसे ग्राहक रिकॉर्ड से शुरू करते हैं जिसे ग्राहक जोड़ते समय एक बार दो मुफ़्त आधिकारिक स्रोतों से जाँचा जाता है, फिर क्रेडिट सीमा और भुगतान शर्तें जो मालिक तय करता है और सिस्टम हर ऑर्डर और हर डिलीवरी पर जाँचता है, फिर वे गारंटियाँ जिनमें से मालिक उधार पर बेचने से पहले चुन सकता है।

स्रोत

• ज़कात, कर और सीमा शुल्क प्राधिकरण (ZATCA): VAT कानून के कार्यान्वयन विनियम (आधिकारिक अरबी पाठ) — अनुच्छेद 40(1) (आपूर्ति का मूल्य बदलने वाली स्थितियाँ, जिनमें बिक्री पूरी होने के बाद दी गई अतिरिक्त छूट शामिल है), और अनुच्छेद 54(1), 54(4) और 54(6) (क्रेडिट नोट, मूल इनवॉइस का उनका स्पष्ट संदर्भ, और उनके जारी होने की समय-सीमा)।