टेलीकॉम बिलिंग - रेटिंग प्रक्रिया

किसी घटना के घटने के लिए दर / मूल्य है। दर के उदाहरणों में टेलीफोन कॉल की अवधि के लिए शुल्क शामिल हैं: उदाहरण के लिए: "0.40 INR प्रति 1 मिनट" या एक विशिष्ट मात्रा। उदाहरण के लिए: 1MB डाउनलोड के लिए 10.00 INR या इसे सेवा की गुणवत्ता के लिए चार्ज किया जा सकता है।

हमने पहले ही समझाया कि ईवेंट उत्पाद / सेवा उपयोग की एकल घटना है। घटनाओं को नेटवर्क तत्वों द्वारा सीडीआरएस / यूडीआर के रूप में कैप्चर किया जाता है और रेटिंग और बिलिंग के लिए बिलिंग सिस्टम को पास किया जाता है।

रेटिंग व्यक्तिगत घटनाओं के प्रभार / मूल्य को निर्धारित करने की प्रक्रिया है। उदाहरण के लिए, 2 मिनट की कॉल की कीमत 0.80 INR प्रति मिनट 0.40 INR की दर के साथ है।

रेटिंग इंजन, जो बिलिंग सिस्टम का हिस्सा है, इस रेटिंग फ़ंक्शन को करता है।

रेटिंग प्रक्रिया

रेटिंग इंजन कॉल रिकॉर्ड रिकॉर्ड्स (CDRs) या उपयोग विवरण रिकॉर्ड्स (UDRs) नामक डेटा रिकॉर्ड के रूप में घटनाओं को प्राप्त करता है, जो किसी उत्पाद / सेवा के उपयोग का वर्णन करता है। एक सीडीआर डेटा की एक स्ट्रिंग है जिसमें कॉल की जानकारी जैसे कॉल दिनांक और समय, कॉल की लंबाई, कॉलिंग पार्टी, पार्टी कहा जाता है, आदि, जो घटनाओं को रेट करने के लिए उपयोग की जाती हैं।

रेटिंग / रेटिंग इंजन के बुनियादी कार्यों की एक सूची है -

  • रोमिंग उपयोग के मामले में मध्यस्थता प्रणाली या अन्य सेवा प्रदाताओं या रोमिंग भागीदारों से सीडीआर स्वीकार करना।

  • सीडीआर मान्य करना और किसी भी डुप्लिकेट रिकॉर्ड को समाप्त करना। इन डुप्लिकेट घटनाओं को बाद में सत्यापन के लिए डेटाबेस तालिका में संग्रहीत किया जाता है।

  • घटना के लिए चार्ज किए जाने वाले ग्राहक खाते का निर्धारण करने के लिए। यहां, दर प्रक्रिया घटना स्रोत (मोबाइल नंबर या आईपी पता, आदि) को उठाती है और यह सत्यापित करने के लिए डेटाबेस की जांच करती है कि क्या यह घटना स्रोत किसी खाते से जुड़ा हुआ है। इस कदम को इवेंट गाइडिंग कहा जाता है।

  • यदि घटना को निर्देशित नहीं किया जा सकता है, तो इस घटना को अस्वीकार कर दिया जाएगा और इसे सस्पेंस श्रेणी में रखा जा सकता है। इन अस्वीकृत घटनाओं को बाद में सत्यापन के लिए एक डेटाबेस तालिका में संग्रहीत किया जाता है।

  • रेटिंग टैरिफ (जिसे रेट प्लान भी कहा जाता है) के अनुसार घटना की लागत / मूल्य की गणना करना।

  • किसी भी लागू रेटिंग समय छूट को लागू करने के लिए। यह पहले पांच मिनट मुफ्त हो सकता है और उसके बाद सामान्य दर पर कॉल लिया जाएगा। इस तरह के डिस्काउंट को रेटिंग टाइम डिस्काउंट कहा जाता है।

  • डेटाबेस में रेट किए गए ईवेंट को बिलिंग उद्देश्य के लिए स्टोर करना या बिलिंग के लिए बाहरी सिस्टम पर भेजना।

निम्नलिखित छवि रेटिंग इंजन और इससे जुड़े कार्यों का अवलोकन दिखाती है -

ग्राहक की जानकारी चार्ज / मूल्य गणना में उपयोग करने के लिए दर योजना (रेटिंग टैरिफ) निर्धारित करती है। रेटिंग इंजन रेटिंग टेबल का उपयोग करता है, और प्रत्येक कॉल के लिए वास्तविक शुल्क की गणना करने के लिए सीडीआर (जैसे दिन की दूरी, कॉल का स्थान, अवधि या घटना की मात्रा, आदि) से घटना की जानकारी का उपयोग करता है।

डुप्लिकेट ईवेंट

एक डुप्लिकेट घटना को किसी भी निष्पक्ष घटना के रूप में परिभाषित किया जाता है जो निम्नलिखित सभी तरीकों से किसी अन्य निष्पक्ष घटना से संबंधित है -

  • खाता संख्या समान हैं।
  • घटना के स्रोत समान हैं।
  • ईवेंट प्रकार आईडी समान हैं।
  • घटना की तारीखें और समय समान हैं।

डुप्लिकेट घटनाओं की पहचान करने के लिए बिलिंग सिस्टम में किसी अन्य मानदंड को परिभाषित किया जा सकता है। ऐसी कई परिस्थितियाँ हैं जिनके कारण डुप्लिकेट ईवेंट बिलिंग सिस्टम में सबमिट किए जा सकते हैं -

  • मध्यस्थता प्रणाली के फ़िल्टरिंग तंत्र की विफलता।
  • मध्यस्थता प्रणाली सॉफ्टवेयर में कोडिंग त्रुटियां।
  • रेटिंग इंजन को पास किए जा रहे ईवेंट फ़ाइल के सभी या भाग का दोहराव।

अस्वीकृत घटनाएँ

जब बिलिंग सिस्टम एक विशेष घटना के साथ एक समस्या का सामना करता है, तो अपमानजनक घटना को खारिज कर दिया जाता है। निम्न में से किसी के साथ समस्याओं के कारण अस्वीकृति हो सकती है -

  • घटना ही।
  • दर योजना।
  • ग्राहक और खाता डेटा।
  • कॉन्फ़िगरेशन डेटा।

किसी घटना को अस्वीकार करने के तीन मुख्य कारण हैं -

  • पार्सिंग त्रुटियां बिलिंग सिस्टम को ईवेंट विवरण रिकॉर्ड में जानकारी को पढ़ने से रोकती हैं। एक पार्सिंग त्रुटि हो सकती है क्योंकि ईवेंट रिकॉर्ड में डेटा दूषित या गलत प्रारूप में है।

  • अजेय त्रुटियां जेनेवा को घटना स्रोत या घटना से जुड़े खाते की पहचान करने से रोकती हैं। एक अनिर्दिष्ट त्रुटि हो सकती है क्योंकि बिलिंग सिस्टम डेटाबेस में इवेंट स्रोत अभी तक मौजूद नहीं है।

  • अप्राप्य त्रुटियां बिलिंग सिस्टम को घटना की लागत की गणना करने से रोकती हैं। दर योजना के साथ समस्याओं के कारण एक अयोग्य त्रुटि हो सकती है।

सभी अस्वीकृत घटनाओं को एक विशेष खाते में पोस्ट किया जाता है, जिसे कहा जाता है internal account या suspense account और इन अस्वीकृत घटनाओं को कहा जाता है suspense events। वित्त विभाग सभी अस्वीकृत घटनाओं पर नज़र रखता है और उन्हें राजस्व हानि के एक भाग के रूप में गिना जाता है। आईटी विभाग हमेशा खारिज की गई घटनाओं को हल करने और राजस्व बचाने के लिए उन्हें ठीक से रेट करने के लिए ध्यान देता है।

यदि अस्वीकार की गई घटना को ठीक नहीं किया जा सकता है और ऑपरेटर इसे आंतरिक खाते में पोस्ट नहीं करना चाहता है, तो घटना को खारिज किया जा सकता है। जब किसी घटना को छोड़ दिया जाता है, तो उसे रेटिंग इंजन के पास जमा नहीं किया जाएगा और आगे कोई प्रयास नहीं किया जाएगा।

वास्तविक समय रेटिंग

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

रीयल-टाइम सिस्टम प्रक्रिया में ई-कॉमर्स लेनदेन और डेटा डाउनलोड शामिल हैं। कोई भी एप्लिकेशन जहां घटनाओं को रेट किया जाना चाहिए और ग्राहक के खाते में जल्दी से लागू किया जाना चाहिए, वास्तविक समय की रेटिंग के लिए उपयुक्त उम्मीदवार है।

रीरेटिंग इवेंट्स

ऐसी कई स्थितियाँ हैं जिनमें घटनाओं को रोकना आवश्यक हो सकता है। उदाहरण के लिए, जब -

  • उपयोग की गई दर योजना में त्रुटि के कारण गलत तरीके से मूल्य घटनाएँ हुईं।

  • गलत खाते (गलत इवेंट स्रोत पंजीकरण के कारण) के खिलाफ इवेंट लोड किए गए थे।

  • मौजूदा दर योजना को अंतिम और अगली बिलिंग तिथियों के बीच कुछ बिंदु पर बदल दिया गया था।

  • किसी उत्पाद के लिए रेट प्लान, प्राइस प्लान या इवेंट सोर्स को पूर्वव्यापी रूप से बदल दिया गया है।

घटनाओं को पुन: व्यवस्थित करने की प्रक्रिया बहुत सरल है और यह इस प्रकार है -

  • प्रदान की गई उपयोगिता का उपयोग करके डेटाबेस से सभी घटनाओं को अनलोड / अनरेट करें। अधिकांश बिलिंग सिस्टम सभी मूल्यांकित घटनाओं को अनलोड या अनलोड करने के लिए एक उपयोगिता प्रदान करता है।

  • समस्या जहां भी हो उसे ठीक करें।

  • रेटिंग इंजन द्वारा रेटिंग के लिए घटनाओं को फिर से सबमिट करें।

आंशिक घटनाएँ

आंशिक घटनाएं एक ग्राहक के संतुलन को बनाए रखने की अनुमति देती हैं जबकि एक घटना प्रगति पर है।

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

थ्रेसहोल्ड और क्रियाएँ

रेटिंग इंजन स्वचालित रूप से यह देखने के लिए जांच कर सकता है कि रेटिंग समय छूट थ्रेसहोल्ड सहित किसी भी रेटिंग समय सीमा तक पहुंचा गया है या नहीं।

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

यदि रेटिंग समय कार्रवाई करना आवश्यक है, तो जितना संभव हो उतना वास्तविक समय रेटिंग होना आवश्यक है।

आगे क्या है?

अब तक, हमने देखा है कि कैसे ग्राहक उपयोग उत्पन्न करता है और मध्यस्थता प्रणाली उस उपयोग (CDR) को बिलिंग सिस्टम में कैसे धकेलती है और बिलिंग सिस्टम उन CDR को कैसे रेट करता है।

अगले अध्याय में, हम चर्चा करेंगे कि पूरे महीने के लिए सभी रेटेड सीडीआर को कैसे इकट्ठा किया जाए और अंतिम चालान / बिल उत्पन्न किया जाए, जो प्रदान की गई सेवाओं के लिए राजस्व इकट्ठा करने के लिए अंतिम ग्राहक को भेजा जाता है।