सदस्यता, शेष राशि और मूल्य निर्धारण योजना में परिवर्तन [बंद]

Question

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

ऐसे देश हैं जहां आप प्रदाताओं के भुगतान के कारण आवर्ती बिलिंग का उपयोग नहीं कर सकते हैं या भुगतान की संभावनाएं खराब हैं या इसके लिए कोई समर्थन नहीं है या बहुत महंगे हैं (माइक्रोपायमेंट)। और ऐसे लोग हैं जो आवर्ती बिलिंग का उपयोग नहीं करना चाहते हैं, लेकिन वर्ष के अंत में अपने बिल का मैन्युअल रूप से भुगतान करते हैं / चालान का भुगतान करते हैं। तो कृपया सुझाव न दें कि पेपाल आवर्ती बिलिंग, पुनरावृत्ति या इसी तरह की सेवाओं के लिए।

स्थिति
मान लें कि आपके पास एक मॉडल है जो सदस्यता योजना (उदा User) की सदस्यता ले सकता है । इस मॉडल में एक क्षेत्र है जो एक सदस्यता योजना के पहचानकर्ता को संग्रहीत करता है जिसे वर्तमान में सदस्यता ली गई है। इसलिए, हर योजना में परिवर्तन दर्ज किया जाता है।

SubscriptionPlanChangesनिम्नलिखित परिवर्तनों को रिकॉर्ड करने वाले निम्नलिखित क्षेत्रों के साथ एक मॉडल (जैसे ) है:

• subscriberसब्सक्राइबर मॉडल से संबंधित ( Userइस मामले में)
• from_plan योजना पहचानकर्ता को परिभाषित करने से पहले मॉडल में बदलाव किया गया था
• to_plan योजना पहचानकर्ता को परिभाषित करते हुए अब मॉडल का चयन किया गया है
• created_at एक तारीख-समय क्षेत्र में परिवर्तन का भंडारण है
• valid_until वास्तविक सदस्यता मान्य होने तक दिनांक संग्रहीत करता है
• paid_at एक दिनांक-समय क्षेत्र भी है जो परिभाषित करता है कि क्या (और कब) सदस्यता का भुगतान किया गया था

बेशक, यह लेआउट चर्चा योग्य है।

खाता संतुलन का प्रश्न
जब कोई उपयोगकर्ता अपनी सदस्यता योजना को बदलता है, तो मुझे योजना क्षेत्रों की तुलना करने, प्रिसिंग प्राप्त करने और वर्तमान योजना valid_untilऔर उसकी कीमत के आधार पर नई योजना के लिए कटौती की गणना करने की आवश्यकता होती है। कहें: आपने योजना A के एक वर्ष के लिए सदस्यता ली है, लेकिन 6 महीने के बाद, आप योजना B में अपग्रेड करते हैं, इसलिए आपको योजना A के 6 महीने के लिए भुगतान की गई कीमत का आधा हिस्सा मिलता है।

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

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

एक अन्य विकल्प है, इस के लिए एक अतिरिक्त रिकॉर्ड बनाने के लिए जहां होगा from_planऔर to_planएक ही पहचानकर्ता (इस प्रकार का प्रतीक "कोई परिवर्तन नहीं") कर रहे हैं। लेकिन यह किसी भी तरह से खाते की शेष राशि की गणना में हस्तक्षेप नहीं करेगा?

अगर कोई मुझे इस तरह की सदस्यता को संभालने वाले लॉजिक्स के बारे में सही दिशा में इंगित कर सकता है, तो मैं इसकी बहुत सराहना करूंगा।

---

अद्यतन
अब तक मदद के लिए धन्यवाद। मुझे लगता है कि मेरा प्रश्न बहुत अस्पष्ट था इसलिए मैं कम अमूर्तता का उपयोग करके अधिक सटीक होने की कोशिश करूंगा। दुर्भाग्य से, मैं अभी तक अपनी समस्या को हल नहीं कर सका।

केस A
User चयन कर सकता है Subscription Plan A। यह वर्तमान SubscriptionPlanChangeमें इसका ट्रैक रखने के लिए स्टोर करता है। 5 महीने के बाद, Userअपनी सदस्यता अपग्रेड करें Subscription Plan B। इसलिए वह अप्रयुक्त 7 महीने के लिए योजना की कीमत में कटौती करते हुए, अपनी नई सदस्यता के लिए कीमत चुकाता है।

केस बी
3 महीने के बाद, Userवापस उसके पास जाता है Subscription Plan A। उसे भुगतान नहीं करना है, लेकिन इसके लिए एक शेष राशि प्राप्त करता है ताकि, सदस्यता के अंत में, उसे अपनी नई सदस्यता के लिए कटौती की गई राशि मिल जाए।

केस C
User एक उप-सेवा के लिए एक सदस्यता योजना का चयन कर सकता है जिसमें स्वतंत्र सदस्यता योजना है। वही Case Aऔर Case Bउस उप-सेवा सदस्यता के लिए आवेदन कर सकते हैं।

_Case D_ उपयोगकर्ता अपनी सदस्यता को रद्द कर देता है। इससे उसका संतुलन बिगड़ जाता है।

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

मुझे यह भी पक्का नहीं है कि यदि शेष राशि को यूजर्स मॉडल में ही स्टोर किया जाना चाहिए, या यदि यह संग्रहीत नहीं है, लेकिन संग्रहीत डेटा / इतिहास के आधार पर किसी भी समय गणना की जा सकती है।

ध्यान देने योग्य कुछ बातें, हालांकि मुझे नहीं लगता कि उन्हें समस्याओं का सामना करना चाहिए:

• यह एक होना जरूरी नहीं है User, यह कुछ भी हो सकता है, यही कारण है Subscriberकि बहुरूपी है
• Plansजरूरी नहीं कि योजनाएं हों, लेकिन Magazinesजैसा उल्लेख किया जा सकता है । यही मैंने केस सी और केस डी के साथ वर्णित किया है ।

Comments

एक चीज जो आप निश्चित रूप से कर सकते हैं, वह है कि प्रत्येक मुद्दे को एक मूल्य (जो योजना पर निर्भर हो सकता है जैसे कि संयोजन [योजना, मुद्दा] नक्शे [मुद्दे की कीमत]), और फिर बस प्रत्येक ग्राहक की शेष राशि पर नज़र रखें। (या जो भी शब्दावली आपको पसंद हो)।

— बजे एक CVn

सभी को धन्यवाद, मुझे प्रश्न को अपडेट करने की आवश्यकता थी क्योंकि मैं अभी तक अपनी समस्या को हल नहीं कर सका।

— pduersteler

क्या मैं पूछ सकता हूं कि आपने इसे कैसे लागू किया?

— जेसीएम

Answer 1

दुर्भाग्य से, एक जटिल समस्या का उत्तर आमतौर पर जटिल होता है। आपसे मेरी सलाह केवल प्रासंगिक जानकारी को सहेजना होगा, फिर बड़ी तस्वीर बनाने के लिए एक मॉडल का उपयोग करें।

दूसरे शब्दों में, आपकी तालिका SubscriptionPlanChanges में इसकी कुंजी के लिए निम्नलिखित जानकारी होगी:

• ग्राहक
• योजना
• से मान्य

इस तरह, आप उसी ग्राहक के लिए कई योजनाओं की अनुमति देते हैं जो ओवरलैप कर सकते हैं। अन्य क्षेत्रों में शामिल हैं:

• तब तक वैध
• तक भुगतान किया गया
• दर (0 भी अगर मुफ्त)

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

एक बार जब आप इसे प्राप्त कर लेते हैं, तो उपयोगकर्ता के क्रेडिट की गणना अपेक्षाकृत सरल होती है। यदि दो योजनाएं ओवरलैप नहीं कर सकती हैं, तो आप अंतिम तिथि की "वैधता" और वर्तमान योजना के "मान्य" के बीच की दो तिथियों को कम करके अंतिम तिथि निर्धारित करें। प्रारंभ तिथि "तिथि से मान्य" और "तिथि तक" (यदि परिभाषित है) के बीच दो तिथियों में से अधिक है। भुगतान (या क्रेडिट) की गणना उस योजना के उपर्युक्त प्रारंभ और समाप्ति तिथियों के बीच के समय के अंतराल से गुणा की गई दर पर की जा सकती है।

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

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

मुझे उम्मीद है इससे आपको अपने प्रश्न का उत्तर मिल गया।

Comments

बहुत धन्यवाद, कुछ प्रकाश डाला! हालांकि मुझे लगता है कि मैं "वैध" क्षेत्र के बारे में स्पष्ट नहीं था। valid_untilआपकी मेरी शब्दावली थी paid_until। सदस्यता की योजना की अधिकतम लंबाई नहीं है।

— पोडरस्टेलर

@pduersteler आह मेरी गलती तब। यह केवल गणना को इतना आसान बनाता है, क्योंकि "समाप्ति" की तारीख नई योजना की शुरुआत है।

— नील

दर भुगतान की गई राशि है? यदि हाँ, तो यह एक और इकाई हो सकती है, उदाहरण के लिए एक चालान, क्या मैं सही हूं?

— जेसीएम

Answer 2

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

ID, UserId, TransactionDate, क्रेडिट (जब आप उपयोगकर्ता को क्रेडिट देते हैं और उपयोगकर्ता क्रेडिट का उपयोग करते समय नकारात्मक होता है)

उपयोगकर्ता को उसे शेष राशि दिखाने के लिए बस क्रेडिट का योग करें।

आशा है कि यह आपके कुछ काम का है ...