সাবস্ক্রিপশন, ব্যালেন্স এবং মূল্য পরিকল্পনা পরিকল্পনার হ্যান্ডলিং [বন্ধ]

Question

উপস্থাপিত
আমার উদ্দেশ্য সাবস্ক্রিপশন পরিচালনা করতে একাধিক প্রকল্পের জন্য পুনরায় ব্যবহারযোগ্য কোড তৈরি করা (এবং এটি গিথুবে প্রকাশও করা)। আমি স্ট্রাইপ এবং পুনরাবৃত্ত বিলিং সরবরাহকারীদের সম্পর্কে জানি, তবে এই মডিউলটি কী লক্ষ্য করে তা নয়। অ্যাকাউন্টের ভারসাম্য গণনা, সাবস্ক্রিপশন পুনর্নবীকরণের জন্য সহজ বিজ্ঞপ্তি এবং মূল্য গণনা পরিচালনা করার জন্য এটি কেবল একটি মোড়ক / সহায়ক হতে হবে।

এমন দেশ রয়েছে যা সরবরাহকারীরা বা অর্থ প্রদানের সম্ভাবনাগুলি দুর্বল বা এর জন্য কোনও সমর্থন না থাকায় বা খুব ব্যয়বহুল (মাইক্রোপেমেন্টস) কারণে আপনি পুনরাবৃত্ত বিলিং ব্যবহার করতে পারবেন না। এবং এমন লোকেরা আছেন যাঁরা পুনরাবৃত্ত বিলিং ব্যবহার করতে চান না তবে বছরের শেষে ম্যানুয়ালি / চালানকে চালিত করে তাদের বিল পরিশোধ করতে চান। সুতরাং দয়া করে পেপাল পুনরাবৃত্তি বিলিং, পুনরাবৃত্তি বা অনুরূপ পরিষেবাদির পরামর্শ দিবেন না।

পরিস্থিতি ধরা
যাক আপনার একটি মডেল রয়েছে যা সাবস্ক্রিপশন প্ল্যানে সাবস্ক্রাইব করতে পারে (উদাঃ User)। এই মডেলটির এমন একটি ক্ষেত্র রয়েছে যা এটি বর্তমানে সাবস্ক্রাইব হওয়া সাবস্ক্রিপশন পরিকল্পনার সনাক্তকারীকে সঞ্চয় করে। সুতরাং, প্রতিটি পরিকল্পনা পরিবর্তনের উপর, পরিবর্তনটি রেকর্ড করা হয়।

SubscriptionPlanChangesনিম্নলিখিত ক্ষেত্রগুলি উল্লিখিত পরিবর্তনগুলি রেকর্ড করে একটি মডেল রয়েছে (উদাঃ )

• subscriberসাবস্ক্রাইব মডেল সম্পর্কিত ( Userএই ক্ষেত্রে)
• from_plan মডেল পরিবর্তনের আগে পরিকল্পনা শনাক্তকারীকে সংজ্ঞায়িত করে
• to_plan পরিকল্পনা সনাক্তকারীকে সংজ্ঞায়িত করা মডেল এখন নির্বাচন করেছেন has
• created_at পরিবর্তনটি সংরক্ষণ করার জন্য একটি তারিখ-সময় ক্ষেত্র
• valid_until প্রকৃত সাবস্ক্রিপশন বৈধ না হওয়া পর্যন্ত তারিখ সঞ্চয় করে
• paid_at এটি একটি তারিখ-সময় ক্ষেত্র যা সংজ্ঞা দেয় (এবং কখন) সাবস্ক্রিপশন প্রদান করা হয়েছিল

অবশ্যই, সেই বিন্যাসটি আলোচনাযোগ্য।

অ্যাকাউন্টের ভারসাম্যের প্রশ্ন
যখন একজন ব্যবহারকারী তার সাবস্ক্রিপশন প্ল্যান পরিবর্তন করে, তখন আমার পরিকল্পনার ক্ষেত্রগুলি তুলনা করতে হবে, প্রাইসিংগুলি পেতে হবে এবং বর্তমান পরিকল্পনার valid_untilএবং এর দামের ভিত্তিতে নতুন পরিকল্পনার জন্য ছাড়ের গণনা করতে হবে। বলুন: আপনি পরিকল্পনার এক বছরের জন্য সাবস্ক্রাইব করেছেন তবে months মাস পরে আপনি বি প্ল্যানে আপগ্রেড করেছেন, সুতরাং আপনি পরিকল্পনার for মাসের জন্য অর্ধেক প্রদত্ত দামের ছাড় পাবেন get

আমি কী ভাবছি: যদি কোনও ব্যবহারকারী যেমন মুক্ত পরিকল্পনায় স্যুইচ করে তবে তার একটি ক্রেডিট রয়েছে যা ব্যবহারকারী আবার স্যুইচ করতে চাইলে কেটে নেওয়া যায়। আপনি কি কোনও অতিরিক্ত ক্ষেত্রে সেই মানটি ক্যাশে রাখতে পারবেন, বা প্রতিবার সেই ব্যবহারকারীর সাথে সম্পর্কিত সমস্ত রেকর্ডের মাধ্যমে গণনা করবেন? আপনি কি টেবিল বিন্যাস সম্পর্কে কিছু যুক্ত / পরিবর্তন করবেন?

সহজ বোধগম্যতার প্রশ্ন
যখন সাবস্ক্রিপশন সময়সীমা শেষ হবে, ব্যবহারকারী বিজ্ঞাপিত হয়ে যায় এবং আবার অর্থ প্রদানের মাধ্যমে তার সাবস্ক্রিপশন পুনর্নবীকরণের সম্ভাবনা থাকে। সবচেয়ে সহজ উপায় হ'ল কেবল আপডেট করা paid_atএবং valid_untilনতুন সাবস্ক্রিপশন বিকল্পগুলি। তবে, আমি নিশ্চিত নই যে আপনি যদি কারও প্রয়োজন হতে পারে এমন প্রতিটি ডেটা, অর্থ প্রদান / সাবস্ক্রিপশন ইতিহাসের মতো সঞ্চয় করেন কিনা।

আরেকটি বিকল্প হ'ল এটির জন্য একটি অতিরিক্ত রেকর্ড তৈরি করা হবে, যেখানে from_planএবং to_planএকই শনাক্তকারী রয়েছে (সুতরাং "কোনও পরিবর্তন নয়" প্রতীকী)। তবে কি কোনওভাবে অ্যাকাউন্টের ভারসাম্য গণনা করতে হস্তক্ষেপ করবে না?

যদি কেউ এই জাতীয় সাবস্ক্রিপশন পরিচালনা করার লজিক্স সম্পর্কে আমাকে সঠিক দিকে নির্দেশ করতে পারে তবে আমি এটির খুব প্রশংসা করব।

---

আপডেট
এখন অবধি সহায়তার জন্য ধন্যবাদ। আমি মনে করি আমার প্রশ্নটি খুব অস্পষ্ট ছিল তাই আমি কম বিমূর্ততা ব্যবহার করে আরও সুনির্দিষ্ট হওয়ার চেষ্টা করব। দুর্ভাগ্যক্রমে, আমি আমার সমস্যাটি এখনও সমাধান করতে পারিনি।

কেস এ
User নির্বাচন করতে পারে Subscription Plan A। এটি বর্তমানে SubscriptionPlanChangeএটির ট্র্যাক রাখতে একটি সঞ্চয় করে। যেমন 5 মাস পরে Userতার সাবস্ক্রিপশনটি আপগ্রেড করে Subscription Plan B। সুতরাং তিনি তার নতুন সাবস্ক্রিপশনের জন্য মূল্য পরিশোধ করেন, অব্যবহৃত 7 মাসের জন্য পরিকল্পনার দামটি বাদ দিয়ে।

কেস বি
3 মাস পরে, Userতার কাছে ফিরে আসে Subscription Plan A। তাকে দিতে হবে না তবে এর জন্য একটি ভারসাম্য পান যাতে সাবস্ক্রিপশন শেষে, তিনি তার নতুন সাবস্ক্রিপশনের জন্য সেই ব্যালেন্সটি কেটে যায় gets

কেস সি
User একটি সাব-সাবস্ক্রিপশনের জন্য সাবস্ক্রিপশন প্ল্যান নির্বাচন করতে পারে যার স্বাধীন সাবস্ক্রিপশন পরিকল্পনা রয়েছে। একই Case Aএবং Case Bউপ-পরিষেবা সাবস্ক্রিপশনের জন্য আবেদন করতে পারে।

_Case D_ ব্যবহারকারী তার একটি সদস্যতা বাতিল করে। এটি তার ভারসাম্যের শীর্ষে উঠে আসে।

আমার প্রশ্ন (বর্তমানে কমপক্ষে) মূলত সেই ডেটা কীভাবে সঠিকভাবে সংরক্ষণ করা যায় তার উপর নির্ভর করে যাতে আমি ব্যবসায়ের বিশ্লেষণের জন্য সাবস্ক্রিপশনের একটি ইতিহাস পুনরুত্পাদন করতে পারি এবং ব্যালেন্স গণনা করতে পারি, সাবস্ক্রিপশনের উপর ভিত্তি করে বকেয়া পেমেন্ট পেতে পারি etc.

আমিও নিশ্চিত নই যে ভারসাম্যটি সংরক্ষণ করা উচিত eg উদাহরণস্বরূপ ব্যবহারকারীগণের মডেল নিজেই, বা এটি সঞ্চিত না থাকলে তবে সঞ্চিত ডেটা / ইতিহাসের ভিত্তিতে যে কোনও সময় গণনা করা যায়।

কিছু বিষয় লক্ষণীয়, যদিও আমি মনে করি না যে তাদের সমস্যার সমাধান করা উচিত:

• এটি একটি Userহতে হবে না, এটি যে কোনও কিছু হতে পারে, এজন্যই Subscriberপলিমারফিক হয়
• Plansঅগত্যা পরিকল্পনা হতে হবে না, তবে যেমন Magazinesউল্লিখিত মত হতে পারে । আমি কেস সি এবং কেস ডি দিয়ে এটি বর্ণনা করেছি ।

Comments

একটি জিনিস যা আপনি অবশ্যই করতে পারেন তা হ'ল প্রতিটি ইস্যুকে একটি মূল্য নির্ধারণ করা (যা পরিকল্পনার উপর নির্ভর করতে পারে যেমন [ইস্যু মূল্যে] সমন্বয় [পরিকল্পনা, ইস্যু] মানচিত্র) এবং তারপরে প্রতিটি ম্যাগাজিনে প্রতিটি গ্রাহকের ভারসাম্য রক্ষা করা যায় simply (বা আপনি যে কোনও পরিভাষা পছন্দ করেন)

— একটি সিভিএন

সবাইকে ধন্যবাদ, আমার প্রশ্নটি আপডেট করার দরকার ছিল কারণ আমি এখনও আমার সমস্যার সমাধান করতে পারি নি।

— pduersteler

আমি জিজ্ঞাসা করতে পারি আপনি কীভাবে এটি বাস্তবায়ন শেষ করেছেন?

— জেসিএম

Answer 1

দুর্ভাগ্যক্রমে, একটি জটিল সমস্যার উত্তর সাধারণত জটিল। আপনার কাছে আমার পরামর্শটি হ'ল কেবল প্রাসঙ্গিক তথ্য সংরক্ষণ করুন, তারপরে আরও বড় চিত্রটি তৈরি করতে একটি মডেল ব্যবহার করুন।

অন্য কথায়, আপনার টেবিল সাবস্ক্রিপশন প্ল্যানচেঞ্জগুলির এর কীটির জন্য নিম্নলিখিত তথ্য থাকবে:

• গ্রাহক
• পরিকল্পনা
• বৈধ হবে

এইভাবে, আপনি একই গ্রাহকের জন্য একাধিক পরিকল্পনার মঞ্জুরি দিয়েছেন যা ওভারল্যাপ করতে পারে। অন্যান্য ক্ষেত্রগুলির মধ্যে রয়েছে:

• বৈধতার সীমা
• অবধি প্রদান
• রেট (এছাড়াও 0 বিনামূল্যে যদি)

লক্ষ্য করুন যে "পরিকল্পনা থেকে" বা "পরিকল্পনা" নেই। যদিও আপনার সেগুলি থাকতে পারে, তথ্যটি অতিরিক্ত অতিরিক্ত এবং আপনার নিজের থেকে গণনা করা যায় (এই জাতীয় তথ্য সংরক্ষণের অর্থ এটি ধারাবাহিক রাখার অতিরিক্ত কাজ আপনার কাছে রয়েছে)। যখন নতুন পরিকল্পনা শুরু হয়, বিদ্যমান পরিকল্পনাগুলি সংশোধন না করে আপনি এগুলি ছেড়ে যান এবং কেবল একটি নতুন রেকর্ড যুক্ত করেন add নতুন নতুন পরিকল্পনার পরে যদি আর কোনও ওভারল্যাপিংয়ের পরিকল্পনা উপস্থিত থাকে তবে আপনি সিদ্ধান্ত নিতে পারেন আপনি এটি মুছতে চান (এইভাবে আরও স্বজ্ঞাত)। আপনি যখন কোনও গ্রাহকের জন্য এই পরিকল্পনাগুলি লোড করেন, আপনি তাদের "বৈধ থেকে" তারিখ অনুসারে তাদের সাজান।

আপনি এটিটি একবার পেয়ে গেলে, কোনও ব্যবহারকারীর ক্রেডিট গণনা করা তুলনামূলকভাবে সহজ। যদি দুটি পরিকল্পনা ওভারল্যাপ করতে না পারে তবে শেষের তারিখ নির্ধারণ করার জন্য আপনি পূর্ববর্তী পরিকল্পনার "বৈধ অবধি" তারিখ এবং বর্তমান পরিকল্পনার "বৈধ থেকে" এর মধ্যে দুটি তারিখের চেয়ে কম গ্রহণ করবেন take শুরুর তারিখটি "বৈধ থেকে" তারিখ এবং "প্রদত্ত অবধি" তারিখের মধ্যে দুটি তারিখের চেয়ে বৃহত্তর (সংজ্ঞায়িত হলে)। তারপরে পেমেন্ট (বা ক্রেডিট) উপরে উল্লিখিত শুরু হওয়া এবং সেই পরিকল্পনার শেষ তারিখগুলির মধ্যে সময়ের ব্যবধানের সাথে গুণিত হারের ভিত্তিতে গণনা করা যেতে পারে।

এইভাবে, আপনি তাত্ত্বিকভাবে যা কিছু জানা দরকার তা গণনা করতে পারেন। আমি গণনা করা মানগুলি সংরক্ষণ করার চেষ্টা করার বিরুদ্ধে পরামর্শ দেব, যেহেতু এটি বিদ্যমান থাকবে যখন কোনও বিদ্যমান রেকর্ড সংশোধন, যুক্ত বা মুছে ফেলা হবে।

আপনি কীভাবে এই মানগুলি গণনা করবেন তার বিভিন্নতা একটি অতিরিক্ত ধরণের ক্ষেত্র যুক্ত করে পরিচালনা করা যায়। আপনার কোডে, আপনার মূল অ্যালগোরিদমকে জটিল গণনার তুলনায় তুলনামূলকভাবে পরিষ্কার রাখতে আপনি বিশেষ পরিকল্পনা গণনার যুক্তি পরিচালনা করতে বিশেষ হ্যান্ডলার তৈরি করতে পারেন। এখনও যদি আপনি কোনও মামলার জন্য কোনও হ্যান্ডলার তৈরি করার ব্যবস্থা করেন তবে কোনও ধরণের নির্দিষ্ট করা হয়নি, তাই আপনার যে কোনও গণনা করার প্রয়োজন হয় তা করতে আপনাকে যা করতে হবে তা হ'ল প্রকার অনুসারে উপযুক্ত হ্যান্ডলারকে কল করতে হবে।

আমি আশাকরি এটাই আপনার প্রশ্নের উত্তর।

Comments

অনেক ধন্যবাদ, যে কিছু আলো ফেলে! যদিও আমি মনে করি আমি "বৈধ" ক্ষেত্রটি সম্পর্কে অস্পষ্ট ছিলাম। valid_untilআমার আপনার পরিভাষা ছিল paid_until। সাবস্ক্রাইব করার কোনও পরিকল্পনার সর্বোচ্চ দৈর্ঘ্য নেই।

— pduersteler

@pduersteler আহ আমার ভুল তখন। এটি কেবল গণনাটিকে আরও সহজ করে তোলে, যেহেতু "শেষ" তারিখটি নতুন পরিকল্পনার শুরু মাত্র।

— নীল

হার কি পরিমাণ দেওয়া হয়? যদি হ্যাঁ, তবে এটি অন্য সত্তা হতে পারে, উদাহরণস্বরূপ একটি চালান, আমি ঠিক আছি?

— জেসিএম

Answer 2

উপরের উত্তর ছাড়াও, আমি ক্রেডিট সহ একটি টেবিল তৈরি করব, যেখানে কোনও ক্রেডিট বর্তমান মুদ্রার সমান হবে। যখনই ব্যবহারকারী কোনও সস্তা বিকল্পে স্যুইচ করে, অব্যবহৃত ভারসাম্য ক্রেডিট হিসাবে প্রবেশ করে। যখনই ব্যবহারকারীর কিছু অর্থ দিতে হবে, আপনি প্রথমে ক্রেডিট ব্যবহার করবেন এবং ক্রেডিটগুলি ফুরিয়েছে বা উপস্থিত না থাকলে কেবল অর্থ প্রদানের জন্য জিজ্ঞাসা করবেন। যদি এই বিকল্পটি ব্যবহার করে থাকেন তবে যদি কোনও বিবাদ দেখা দেয় তবে ব্যবহার-পরিস্থিতি পুনরুত্পাদন করতে সক্ষম হবার জন্য সারণীটিকে লেনদেন-তালিকা হিসাবে তৈরি করুন। উদাহরণ:

আইডি, ইউজারআইডি, লেনদেনের তারিখ, ক্রেডিট (যখন আপনি ব্যবহারকারীকে ক্রেডিট দেবেন তখন ইতিবাচক এবং ব্যবহারকারী যখন ক্রেডিট ব্যবহার করবেন)

ব্যবহারকারীর তাকে ভারসাম্য দেখানোর জন্য ক্রেডিটগুলি যোগ করুন।

আশা করি এটি আপনার কিছুটা কাজে আসবে ...