ভ্যারিয়েন্ট ও বাণ্ডেলসহ পণ্য ক্যাটালগ: স্কিমা ও UI প্যাটার্ন

কেন ভ্যারিয়েন্ট ও বাণ্ডেল দ্রুত জটিল হয়ে যায়

একটা পণ্য ক্যাটালগ সহজ দেখায় যখন প্রতিটি পণ্যই এক আইটেম, এক দাম এবং এক স্টক সংখ্যার মধ্যে সীমাবদ্ধ থাকে। রঙ, সাইজ, সাবস্ক্রিপশন মেয়াদ, বা অঞ্চলে ভিন্ন প্যাকেজিং যোগ করলে সেই সরলতা ভেঙে পড়ে। একটাই “Products” টেবিল এখন মৌলিক প্রশ্নের উত্তর দিতে পারে না: আমরা আসলে কোন নির্দিষ্ট জিনিস বিক্রি করছি, এবং আমরা সেটি কিভাবে ট্র্যাক করব?

শপিংকারীও বিস্তারিত সঠিক দেখতে চান। তারা অপশন বেছে নেবে, সঠিক দাম সাথে সাথেই দেখতে চাইবে, এবং জানতে চাইবে তাদের নির্দিষ্ট পছন্দ আজ পাঠানো যাবে কি না। পেজ যদি “In stock” দেখায় কিন্তু নির্বাচিত সাইজ নেই, আস্থা দ্রুত কমে যায়। দাম কেবল চেকআউটে বদলে গেলে সাপোর্ট টিকিট ও রিটার্ন বাড়ে।

বাণ্ডেলগুলো একটি অতিরিক্ত স্তর জটিলতা নিয়ে আসে কারণ তারা পণ্যের মতো দেখায় কিন্তু নিয়মের মতো আচরণ করে। “Starter Kit” এক বোতল, এক পাম্প এবং একটি ফিল্টার সেট থাকতে পারে। এর পাওয়া যায় কি না সেই সব অংশের উপর নির্ভর করে, এবং আপনার খরচ ও রিপোর্টিংও সঙ্গতিপূর্ণ রাখতে হবে।

আপনার ক্যাটালগ ফাটতে শুরু করেছে—এর কিছু লক্ষণ:

• আপনি কোনো অপশন উপস্থাপন করতে ডুপ্লিকেট SKU তৈরি করছেন।
• বাণ্ডেল বিক্রির পর স্টক গণনা অদ্ভুত দেখায়।
• অ্যাডমিন স্ক্রিনগুলো প্রায় একই ধরনের আইটেমের লম্বা তালিকা হয়ে গেছে।
• ডিসকাউন্ট ও ট্যাক্স একক আইটেমে কাজ করে কিন্তু কিটে ভেঙে পড়ে।
• রিপোর্টিং জিজ্ঞেস করলে “আসলে কি বিক্রি হলো?” বলা যায় না।

সমাধান বেশিরভাগই শৃঙ্খলা: এমন একটি ডেটা মডেল যা ধারাবাহিক থাকে, এবং UI প্যাটার্নগুলো যা বিক্রেতা ও গ্রাহক উভয়ের জন্য অপশন নির্বাচন ও উপলব্ধতা স্পষ্ট করে।

সাধারণ ভাষায় টার্ম: অপশন, ভ্যারিয়েন্ট, SKU, বাণ্ডেল

“ভ্যারিয়েন্ট” বললে মানুষ প্রায়ই কয়েকটি ভিন্ন ধারণা মিশিয়ে ফেলে। শুরুর দিকে শব্দগুলো সঠিক রাখা পরে (স্কিমা, UI, ইনভেন্টরি) সিদ্ধান্ত নেওয়া অনেক সহজ করে দেয়।

অধিকাংশ দল এই সংজ্ঞাগুলো ব্যবহার করে:

• Option: গ্রাহক যে সিদ্ধান্ত নেবে, যেমন Size বা Color।
• Option value: অপশনের একক মান, যেমন Size = M বা Color = Black।
• Variant: অপশন মানগুলোর এক নির্দিষ্ট সংমিশ্রণ, যেমন Size M + Color Black।
• SKU: একটি বিক্রয়যোগ্য ইউনিট যা অপস এবং ইনভেন্টরিতে ট্র্যাক করা হয়। একটি ভ্যারিয়েন্ট প্রায়ই এক SKU-র সাথে মেলে, কিন্তু সবসময় নয়।
• Bundle / kit / multipack: অন্যান্য পণ্য থেকে তৈরি একটি পণ্য। Bundle হলো মার্কেটিং গ্রুপিং (পার্থক্য করে বিক্রি করা যেতে পারে)। Kit হলো “একসাথে পাঠাতে হবে” সেট। Multipack হলো একই আইটেমের পুনরাবৃত্তি (উদাহরণ: 3-প্যাক মোজা)।

ID গুলোও বাস্তবে বিভ্রান্তি সৃষ্টি করে। Internal ID হলো আপনার ডেটাবেস যা ব্যবহার করে। SKU হলো অপারেশনাল কোড (পিকিং, রেপ্লেনিশমেন্ট, রিপোর্টিংয়ে ব্যবহার হয়)। Barcode (UPC/EAN) হলো স্ক্যানার যা পড়ে। এক SKU-র অনেক বারকোড থাকতে পারে (বিভিন্ন অঞ্চলের জন্য), এবং কিছু আইটেমের কোন বারকোড নাও থাকতে পারে।

একটি ভালো নিয়ম: কোনো কিছু বিক্রয়যোগ্য ভ্যারিয়েন্ট হিসেবে বিবেচনা করবেন যদি সেটির দাম, ইনভেন্টরি, ওজন, বা শিপিং নিয়ম ভিন্ন হতে পারে। একই টি-শার্টের Size M ও Size XL সাধারণত আলাদা স্টক কাউন্ট দরকার, তাই আলাদা SKU হওয়া উচিত।

সিদ্ধান্ত নিন আপনার ক্যাটালগকে কী সমর্থন করতে হবে

কোনো স্কিমা বেছে নেওয়ার আগে দৈনন্দিন ব্যবসার যে প্রশ্নগুলো উত্তর দিতে হয় সেগুলো থেকে শুরু করুন। যখন কেউ কোনো আইটেম দেখবে, আপনি আত্মবিশ্বাসের সঙ্গে বলতে পারছেন কি: এটা এখনই পাওয়া যাচ্ছে কি না, দাম কত, কিভাবে পাঠানো হবে, এবং কোন ট্যাক্স নিয়ম প্রযোজ্য?

একটি ব্যবহারিক উপায় হলো সিদ্ধান্ত নেওয়া কোথায় প্রতিটি “ফ্যাক্ট” থাকবে। শেয়ার করা সত্যগুলো Product-এ রাখুন, এবং পরিবর্তিত সত্যগুলো Variant (SKU)-তে রাখুন। মিশালে আপনি একই বাগ দুই জায়গায় ফিক্স করতে বসবেন।

পণ্য-স্তরের বনাম ভ্যারিয়েন্ট-স্তরের ক্ষেত্রগুলো সাধারণত কনফিগার করে:

• যদি এটা সাইজ/রঙ/ম্যাটেরিয়াল অনুযায়ী বদলায়, তাহলে সেটা Variant-এ থাকা উচিত।
• যদি এটা প্রতিটি অপশন সংমিশ্রণের জন্য সত্য হয়, তাহলে সেটা Product-এ।
• যদি আপনি রিপোর্ট করেন SKU প্রতি (বিক্রয়, মার্জিন, রিটার্ন), তাহলে সেটি ভ্যারিয়েন্ট স্তরে সংরক্ষণ করুন।
• যদি অপারেশন পিক/প্যাক/শিপে এটি ব্যবহার করে, সেখানে যেখানে ওয়্যারহাউস কাজ করে সেটাতেই রাখুন: SKU-তে।
• যদি এটা নিরাপদেderive করা যায় (যেমন অপশন মান থেকে ডিসপ্লে নাম), তাহলে উৎসটি সংরক্ষণ করুন এবং প্রয়োজন হলে প্রদর্শন করুন।

একটি উৎস-একটি-সত্য রাখুন। উদাহরণস্বরূপ, “price” উভয় Product ও Variant-এ রাখবেন না যদি না তাদের ভূমিকা স্পষ্ট হয় (যেমন Product-এ MSRP, Variant-এ বিক্রির বাস্তব দাম)।

পরিবর্তনের জন্য পরিকল্পনা করুন। পরে আপনি একটি নতুন অপশন যোগ করতে পারেন (যেমন “Length”), একটি ভ্যারিয়েন্ট অবসর করতে পারেন, বা সরবরাহকারী পরিবর্তনের পরে SKU মার্জ করা লাগতে পারে। যখন ভ্যারিয়েন্ট প্রথম-শ্রেণীর রেকর্ড হয়, তখন এই পরিবর্তনগুলি মসৃণভাবে হয়।

যদি আপনি AppMaster-এ বানান, তাহলে Data Designer-এ স্পষ্ট entity নামকরণ প্রকৃতপক্ষে চাহিদা বদলে গেলে রক্ষণাবেক্ষণ সহজ করে।

পণ্য ও ভ্যারিয়েন্টের জন্য একটি ব্যবহারিক স্কিমা

একটি পরিষ্কার স্কিমা ক্যাটালগকে বোঝাপড়াযোগ্য রাখে যখন একটি সহজ পণ্য অনেকগুলো বিক্রয়যোগ্য সংমিশ্রণে পরিণত হয়। লক্ষ্য হচ্ছে: বিকল্পগুলো (গ্রাহক যা বেছে নেয়) আলাদাভাবে মডেল করা, এবং বিক্রয়যোগ্য আইটেম (আপনি যা স্টক ও পাঠান) আলাদা রাখা।

বিশ্বাসযোগ্য entity গুলো:

• Product: প্যারেন্ট আইটেম (name, description, brand, category, default images)
• Option: একটি অপশন ধরনের (Size, Color)
• OptionValue: অনুমোদিত মানগুলো (Small, Medium, Red, Blue)
• Variant: বিক্রয়যোগ্য ইউনিট (একটি মানের সংমিশ্রণ)
• VariantOptionValue: একটি জয়েন টেবিল যা Variant-কে তার OptionValues-গুলোর সাথে যুক্ত করে

ভ্যারিয়েন্ট ইউনিকনেস অনেক ক্যাটালগে ভুল হয়। সবচেয়ে নিরাপদ পদ্ধতি হলো নর্মালাইজড: প্রতিটি Variant-এর জন্য প্রতিটি Option-এ একটিই OptionValue নিশ্চিত করুন, এবং ডুপ্লিকেট কম্বিনেশন প্রতিরোধ করুন। দ্রুততার প্রয়োজন থাকলে একটি গণনা করা “variant key” রাখুন যেমন color=red|size=m (বা এর হ্যাশ) Variant-এ স্টোর করে Product-অনু্যায়ী ইউনিক enforce করুন।

যে ফিল্ডগুলো সংমিশ্রণে বদলায় সেগুলো Variant-এ রাখুন, Product-এ নয়: SKU, barcode, price, compare-at price, cost, weight, dimensions, status (active/discontinued), এবং images (একটা প্রধান ছবি বা ছোট ইমেজ সেট)।

কাস্টম অ্যাট্রিবিউটগুলোর জন্য (যেমন “material” বা “care instructions”) সর্বদা নতুন কলাম যোগ করবেন না। PostgreSQL-এ Product বা Variant-এ একটি JSONB ফিল্ড ভাল কাজ করে, অ্যাপে সামান্য ভ্যালিডেশন লেয়ারের সাথে।

এমন SKU নিয়ম যা সময়ের সঙ্গে টিকে থাকে

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

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

পাঠযোগ্য ও টেকসই নিয়ম:

• একবার অর্ডার দেয়া হলে SKU স্থিতিশীল রাখুন। পুরানো SKU বদলে ফেলবেন না।
• ইন্টারনাল ID আলাদা রাখুন, SKU মানুষদের জন্য, ID ডাটাবেসের জন্য।
• প্রোডাক্ট পরিবারের জন্য ছোট প্রেফিক্স ব্যবহার করুন (উদাহরণ: TSH, MUG), পুরো শব্দ নয়।
• পরিবর্তনশীল মান (যেমন “2026” বা “SUMMER”) এড়ান যদি না আপনার ব্যবসা সত্যিই সেভাবে চলে।

ডিসকন্টিনিউড SKU মুছে ফেলবেন না। অ-সক্রিয় হিসেবে চিহ্নিত করুন, তাদের দাম ইতিহাস রাখুন, এবং পুরানো অর্ডার/রিফান্ড/রিপোর্টে সেগুলো দেখান। যদি আপনি একটি SKU প্রতিস্থাপন করেন, একটি “replaced by” রেফারেন্স সংরক্ষণ করুন যাতে সাপোর্ট ট্রেস করতে পারে কী ঘটেছে।

ভ্যালিডেশন নিয়ম দীর্ঘমেয়াদে ক্ষতি ঠেকায়: সব বিক্রয়যোগ্য আইটেম জুড়ে SKU ইউনিকনেস প্রয়োগ করুন, শুধু অক্ষর, সংখ্যা, হাইফেন অনুমোদন করুন, একটি স্পষ্ট ম্যাক্স দৈর্ঘ্য সেট করুন (প্রায়শই 20-32 ক্যারেক্টার), এবং বিশেষ কেসের জন্য প্রিফিক্স সংরক্ষণ করুন (যেমন বাণ্ডেলের জন্য “BND-”)। AppMaster-এ এই চেকগুলো ডেটা কন্সট্রেইন্ট এবং একটি Business Process-এ রাখা ভালো যা নিয়ম ভাঙলে সেভ ব্লক করে।

সরল ইন-স্টক / আউট-অফ-স্টক ছাড়াও ইনভেন্টরি লজিক

একই “পণ্য” বহু বিক্রয়যোগ্য ইউনিট বোঝালে ইনভেন্টরি বিভ্রান্তিকর হয়ে পড়ে। নিয়ম লেখা শুরু করার আগে নির্ধারণ করুন ইনভেন্টরি কোন ইউনিটে ট্র্যাক হবে: product level, variant level, নাকি উভয়?

যদি গ্রাহক সাইজ বা রঙ বেছে নেন, variant-level স্টক সাধারণত নিরাপদ। একটি শার্ট overall-এ in stock হতে পারে, কিন্তু Small-Blue ভ্যারিয়েন্ট শেষ হয়ে যেতে পারে। Product-level স্টক কাজ করে ডিজিটাল লাইসেন্স বা যেখানে ভ্যারিয়েন্টগুলো সত্যিকারের শারীরিকভাবে আলাদা নয় এমন ক্ষেত্রে। কিছু দল উভয় রাখে: রিপোর্টিং-এর জন্য product-level, বিক্রির জন্য variant-level।

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

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

বাণ্ডেল ও কিটের এক কী নিয়ম: যদি বাণ্ডেল শুধু গ্রুপিং হয় তাহলে সেটির রেকর্ড থেকে স্টক কমাবেন না। কম্পোনেন্ট আইটেমগুলোর স্টক কমান। একটি 3-প্যাক একই SKU-র তিন ইউনিট কমাবে; একটি কিট প্রতিটি কম্পোনেন্ট থেকে এক করে কমাবে।

উদাহরণ: “Starter Kit”-এ 1 বোতল এবং 2 ফিল্টার আছে। যদি আপনার কাছে 10 বোতল এবং 15 ফিল্টার থাকে, কিটের উপলব্ধতা হবে 7 কারণ ফিল্টার সীমা। কম্পোনেন্ট-ভিত্তিক গণনা রিপোর্টিং, রিফান্ড ও রিস্টকিংকে সঙ্গতিপূর্ণ রাখে।

AppMaster-এ এটি Data Designer-এ ভ্যারিয়েন্ট টেবিল এবং Business Process Editor-এ রিজার্ভেশন/ডিক্রিমেন্ট লজিকে ক্লিয়ারভাবে ম্যাপ হয়, যাতে প্রতিটি চেকআউট একই নিয়ম অনুসরণ করে।

রিপোর্টিং ভাঙ না করে বাণ্ডেল ও কিট মডেল করা

বাণ্ডেল হলো যেখানে ক্যাটালগ প্রায়ই বিশেষ কেসে ঢলে যায়। সবচেয়ে সহজ পদ্ধতি হলো বাণ্ডেলকে সাধারণ বিক্রয়যোগ্য আইটেম হিসেবে মডেল করা, তারপর স্পষ্টভাবে কম্পোনেন্টের তালিকা লাগানো।

পরিষ্কার স্ট্রাকচার: Product (sellable item) এবং BundleLines। প্রতিটি BundleLine একটি কম্পোনেন্ট SKU-র দিকে ইঙ্গিত করে (বা একটি কম্পোনেন্ট প্রোডাক্ট এবং প্রয়োজনীয় ভ্যারিয়েন্ট) এবং পরিমাণ সংরক্ষণ করে। অর্ডারগুলো “একটি আইটেম” হিসেবে দেখায়, কিন্তু দরকার হলে আপনি অংশগুলো বিস্তৃত করে খরচ, ইনভেন্টরি ও ফিলফিলমেন্ট বিস্তারিত পেতে পারেন।

বেশিরভাগ বাণ্ডেল সেটআপ এরকমের একটি ধরনে পড়ে:

• Fixed bundle (kit): সবসময় একই কম্পোনেন্ট ও পরিমাণ।
• Configurable bundle: গ্রাহক অনুমোদিত কম্পোনেন্ট থেকে নির্বাচন করে (অর্ডারে লাইন হিসেবে সংরক্ষণ)।
• Virtual bundle: মার্কেটিং গ্রুপিং (সাধারণত ইনভেন্টরিতে প্রভাব ফেলে না), মার্চেন্ডাইজিংয়ের জন্য উপযোগী।

দাম নির্ধারণ এখানে রিপোর্টিং ভাঙার জায়গা। আগে সিদ্ধান্ত নিন অর্ডার লাইনে কি দেখা যাবে, আর কি খরচ/মার্জিন রিপোর্টে যাবে। সাধারণ পদ্ধতি: স্থির বাণ্ডেল দাম, অংশগুলির যোগফল, অথবা ডিসকাউন্টেড যোগফল (উদাহরণ: “যেকোন 3 আইটেম বেছে নিন, সবার মধ্য থেকে সস্তাটা 50% ছাড়”)।

ইনভেন্টরিও একইভাবে কড়াকড়ি হওয়া উচিত: একটি কিট তখনই পাওয়া যাবে যদি প্রতিটি প্রয়োজনীয় কম্পোনেন্ট প্রয়োজনীয় পরিমাণে পাওয়া যায়। রিপোর্টিংয়ের জন্য বিক্রয়ের দুইটি ভিউ রাখুন:

• Sold item: বাণ্ডেল SKU (রেভিনিউ, কনভার্শন, মার্চেন্ডাইজিংয়ের জন্য)।
• Consumed components: বিস্তৃত BundleLines (স্টক মুভমেন্ট, COGS, পিকিং লিস্টের জন্য)।

AppMaster-এ এটি সহজ: একটি Bundle টেবিল ও BundleLine রো, এবং চেকআউটে কম্পোনেন্টগুলো একসাথে প্রসারিত করে বাণ্ডেলের বিক্রয় এবং কম্পোনেন্ট কনজাম্পশন একটি ট্রানজ্যাকশনে লেখার Business Processes।

অপশন ও ভ্যারিয়েন্ট পছন্দ করার UI প্যাটার্ন

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

কাস্টমার-ফেসিং: অপশন আগে, ভ্যারিয়েন্ট পরে

একটি নির্ভরযোগ্য প্যাটার্ন হলো অপশনগুলো দেখানো (Size, Color, Material), তারপর কেবল সেই চয়েসগুলো দেখানো যা এখনো মানানসই।

গ্রাহককে যেকোন কম্বিনেশনে পছন্দ করতে দেওয়া এবং Add to cart-এ ব্যর্থ হওয়াতে ছেড়ে দেওয়া থেকে বিরত থাকুন—অপশন নির্বাচনের সঙ্গে সঙ্গে অসম্ভব কম্বিনেশনগুলো নিষ্ক্রিয় করুন। উদাহরণ: কেউ Color = Black নির্বাচন করলে Black-এ না থাকা সাইজগুলো ডিসেবল করা উচিত (মুছবেন না), যাতে গ্রাহক বুঝতে পারে কি অনুপলব্ধ।

নির্বাচন বদলালে সবচেয়ে জরুরি অংশগুলো আপডেট করুন: দাম (অফার দামসহ), প্রধান ছবি (নির্বাচিত রঙ/স্টাইল অনুযায়ী), স্ট্যাটাস (নির্দিষ্ট ভ্যারিয়েন্ট স্টক), ডেলিভারি আনুমানিক সময় (যদি ভ্যারিয়েন্ট অনুযায়ী ভিন্ন হয়), এবং অপশনালি SKU বা “Item code” সাপোর্টের জন্য।

ইন্টারফেসটা শান্ত রাখুন। একসাথে কয়েকটা অপশন গ্রুপ দেখান, বিশাল ড্রপডাউন এড়িয়ে চলুন যেখানে সোয়াচ বা বাটন ভাল কাজ করে, এবং বর্তমান নির্বাচন স্পষ্ট করুন।

অ্যাডমিন-ফেসিং: ভ্যারিয়েন্টগুলো স্প্রেডশীটের মতো সম্পাদনা

অ্যাডমিনে মানুষদের দ্রুততা লাগে, সুন্দর কাগজ নয়। একটি ভ্যারিয়েন্ট গ্রিড ভাল কাজ করে: প্রতিটি সারি একটি SKU, প্রতিটি কলাম একটি অপশন বা নিয়ম (দাম, barcode, weight, stock, active/inactive)। বাল্ক অ্যাকশন যোগ করুন সাধারণ কাজের জন্য যেমন দাম আপডেট, availability টগল, বা ছবি অ্যাসাইন।

AppMaster-এ একটি ব্যবহারিক সেটআপ হলো Variant টেবিলে বাউন্ড গ্রিড, ফিল্টার (option value, active status, low stock), এবং সেভ করার আগে নিয়ম ভ্যালিডেট করা বাল্ক আপডেট অ্যাকশন।

ধাপে ধাপে: ভ্যারিয়েন্ট সিলেকশন ও বাণ্ডেল উপলব্ধতা চেক

একটি নির্বাচন ফ্লো সরল লাগা উচিত, কিন্তু এর নিচে কঠোর নিয়ম থাকা প্রয়োজন। লক্ষ্য হলো সবসময় জানাটা কোন নির্দিষ্ট SKU গ্রাহক কনফিগার করছে, এবং সেটি এখনই কেনা যাবে কি না।

ভ্যারিয়েন্ট সিলেকশন (একক পণ্য)

পণ্য নাম ও ছবি কেবল লোড করবেন না। আপনাকে সম্পূর্ণ অপশন ভ্যালুগুলো (Size, Color) এবং বিদ্যমান ভ্যারিয়েন্ট কম্বিনেশনগুলোর তালিকা লাগবে।

একটি নির্ভরযোগ্য ফ্লো:

1. প্রোডাক্ট, তার অপশন এবং সব বিদ্যমান ভ্যারিয়েন্ট (অথবা ভ্যালিড কম্বিনেশনগুলোর একটি কম্প্যাক্ট ম্যাপ) ফেচ করুন।
2. গ্রাহকের বর্তমান সিলেকশন স্টোর করুন (উদাহরণ: Size=M, Color=Black) এবং প্রতিটি ক্লিকে আপডেট করুন।
3. প্রতিটি পরিবর্তনের পরে, নির্বাচিত অপশন মানগুলোকে আপনার ভ্যারিয়েন্ট তালিকার সাথে মিলিয়ে ম্যাচিং ভ্যারিয়েন্ট খুঁজুন।
4. যদি ম্যাচ পাওয়া যায় এবং এটি কিনতে যোগ্য (active, price সেট, ব্লক করা নেই), Add to cart এনেবল করুন।
5. যদি ম্যাচ না থাকে, Add to cart ডিসেবল রাখুন এবং গ্রাহককে একটি বৈধ পছন্দের দিকে গাইড করুন।

একটি ক্ষুদ্র UI ডিটেল যা হতাশা কমায়: অসম্ভব অপশন মানগুলোকে যত শীঘ্র সম্ভব ডিসেবল করুন। যদি Size=M কেবল Black-এই থাকে, তাহলে M সিলেক্ট করলে অন্যান্য রঙগুলো অনুপলব্ধ দেখান।

বাণ্ডেল উপলব্ধতা (কম্পোনেন্ট দিয়ে কিট)

বাণ্ডেলের ক্ষেত্রে “in stock” একক সংখ্যা নয়। এটা কম্পোনেন্টগুলোর উপর নির্ভর করে। সাধারণ নিয়ম:

bundle_available = minimum over components of floor(component_stock / component_qty_per_bundle)

উদাহরণ: একটি “Starter Kit”-এ 1 বোতল এবং 2 ফিল্টার লাগলে। যদি আপনার কাছে 10 বোতল এবং 9 ফিল্টার থাকে, উপলব্ধতা হবে min(floor(10/1)=10, floor(9/2)=4) = 4 কিট।

এরর মেসেজগুলো নির্দিষ্ট হওয়া উচিত। "Only 4 kits available (filters limit this bundle)" এর মতো বার্তা দিন তোলা “Out of stock” দেখানোর বদলে। AppMaster-এ এই ধরনের চেক Business Process-এ সহজে প্রকাশ করা যায়: প্রথমে ম্যাচিং ভ্যারিয়েন্ট খুঁজুন, তারপর বাণ্ডেল লিমিট গণনা করুন, এবং UI-তে দেখানোর জন্য স্পষ্ট স্ট্যাটাস রিটার্ন করুন।

সাধারণ ভুল ও ফাঁদ যা এড়িয়ে চলবেন

ক্যাটালগ তখনই ভাঙে যখন আপনি “সবকিছু যা থাকতে পারে” অনুযায়ী মডেল করেন না যে “আপনি আসলে কি বিক্রি করবেন”। দ্রুতই কোণ থেকে আঁটকে পড়ার সবচে দ্রুত উপায় হলো আগাম সব সম্ভাব্য অপশন কম্বিনেশন জেনারেট করে ফেলা, তারপর সেটাকে পরিষ্কার রাখার চেষ্টা করা।

যে ভ্যারিয়েন্টগুলো কখনো স্টক করা হবে না সেগুলো তৈরি করা ক্লাসিক ফাঁদ। যদি 4 রঙ x 6 সাইজ x 3 ম্যাটেরিয়াল হয়, সেটা 72 ভ্যারিয়েন্ট; কিন্তু কেবল 10টি বিক্রি হবে, বাকি 62 রেকর্ড জঞ্জাল সৃষ্টি করবে, ভুলের সুযোগ বাড়াবে এবং রিপোর্ট ধীর করাবে।

দামও চুপিচুপি বাগের উৎস। সমস্যা শুরু হয় যখন একই দাম একাধিক জায়গায় আছে (product, variant, price table, promo table) এবং কোনো একক সোর্স অফ ট্রুথ নেই। একটি সহজ নিয়ম: বেস দাম একবার স্টোর করুন, তারপর শুধুমাত্র যেখানে সত্যিই প্রয়োজন সেখানে ওভাররাইড রাখুন (উদাহরণ: একটি ভ্যারিয়েন্টের আলাদা দাম)।

বাণ্ডেল ও কিট ইনভেন্টরিতে ব্যর্থ হয় যখন আপনি বাণ্ডেলকেও এবং তার কম্পোনেন্টকেও উভয়কেই ডিক্রিমেন্ট করেন। যদি আপনি একটি “Starter Kit” বিক্রি করেন যা 1 বোতল এবং 2 ফিল্টার নিয়ে তৈরী, 1 কিট এবং একই সাথে 1 বোতল ও 2 ফিল্টার কমালে স্টক অনুমান শিগগিরই শূন্যে চলে যাবে। বাণ্ডেলকে বিক্রয়যোগ্য আইটেম হিসাবে রাখুন, কিন্তু উপলব্ধতা ও ডিক্রিমেন্ট কম্পোনেন্ট থেকেই গণনা করুন।

অ্যাডমিন টুলস ক্ষতিসাধন করতে পারে যদি তারা অবৈধ ডেটা অনুমোদন করে। শুরুর দিকে গার্ডরেইল দিন:

• ডুপ্লিকেট SKU ব্লক করুন, এমনকি আর্কাইভ করা আইটেমের মধ্যেও।
• প্রত্যেক ভ্যারিয়েন্টের সব অপশন ভ্যালু থাকা আবশ্যক (কোন “size missing” নয়)।
• একই অপশন কম্বিনেশন শেয়ার করা দুটি ভ্যারিয়েন্ট নিষিদ্ধ করুন।
• বাণ্ডেল কম্পোনেন্ট ভ্যালিডেট করুন (শূন্য পরিমাণ না, মিসিং SKU না)।

সবশেষে, পরিবর্তনের জন্য পরিকল্পনা করুন। পরে একটি নতুন অপশন যোগ করা (যেমন জুতোর জন্য “Width”) একটি মাইগ্রেশন, কোনো ক্লিক-চেঞ্জ নয়। সিদ্ধান্ত নিন পুরোনো ভ্যারিয়েন্টগুলোর কী হবে, ডিফল্ট কিভাবে সেট করা হবে, এবং পুরোনো অর্ডারগুলো তাদের মূল SKU ও অপশন স্ন্যাপশট কিভাবে রাখবে।

চালানোর আগে দ্রুত চেকলিস্ট

লঞ্চের আগে বাস্তবে ভাঙা এমন জিনিসগুলো পরীক্ষা করুন: SKU খুঁজে পাওয়া, স্টক আপডেট, এবং অসম্ভব কেনাকাটা ব্লক করা।

প্রতিটি বিক্রয়যোগ্য SKU সহজে রিচেবল আছে কিনা নিশ্চিত করুন। সার্চে নাম, SKU কোড, barcode/GTIN, এবং মূল অ্যাট্রিবিউটগুলোর (যেমন সাইজ বা রঙ) মাধ্যমে খুঁজে পাওয়া উচিত। যদি আপনার ওয়্যারহাউসে স্ক্যানিং থাকে, কিছু বাস্তব স্ক্যান টেস্ট করুন এবং নিশ্চিত করুন সেগুলো সঠিক SKU-তে যায়, শুধু parent product-এ নয়।

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

লঞ্চ চেকগুলো যা চালাতে ভাল:

• UI-তে অপশন নির্বাচন করুন এবং নিশ্চিত করুন অবৈধ কম্বিনেশনগুলো আগে ব্লক হচ্ছে (Add-to-cart করার আগেই), চেকআউটে না গিয়ে।
• বাণ্ডেলের ক্ষেত্রে নিশ্চিত করুন উপলব্ধতা সংকীর্ণতম কম্পোনেন্ট দ্বারা নির্ধারিত এবং সঠিক পরিমাণে গোনা হচ্ছে (উদাহরণ: কিটে 2 ব্যাটারি থাকলে উপলব্ধতা অর্ধেক হবে)।
• একটি SKU অবসর করান এবং নিশ্চিত করুন সেটা ব্রাউজিং ও সার্চ থেকে অদৃশ্য হয়, কিন্তু পুরানো অর্ডার, ইনভয়েস ও রিপোর্টে সঠিকভাবে দেখা যায়।
• একটি টেস্ট অর্ডার করুন, বাতিল করুন, তারপর পুনরায় অর্ডার দিন; স্টক ফিরে এসে পরিষ্কারভাবে পুনরায় রিজার্ভ হওয়া উচিত।

AppMaster-এ স্টক আপডেট নিয়মগুলো একটিই Business Process-এ রাখুন এবং প্রতিটি পথ থেকে সেটি কল করুন। এই অভ্যাস বেশিরভাগ ইনভেন্টরি বাগ প্রতিরোধ করে।

উদাহরণ পরিস্থিতি ও ব্যবহারিক পরবর্তী পদক্ষেপ

ধরা যাক একটি অ্যাপারেল দোকান যার ক্যাটালগ এখনও সিরিয়াস রক্ষণাবেক্ষণ দাবি করে।

আপনি একটি টি-শার্ট বিক্রি করেন যার দুইটি অপশন আছে: Size (S, M, L) এবং Color (Black, White)। প্রতিটি কেনাযোজ্য সংমিশ্রণ আলাদা ভ্যারিয়েন্ট, আলাদা SKU, দরকার হলে আলাদা দাম, এবং ইনভেন্টরি রয়েছে।

স্কিমায় একটি Product rekord রাখুন “Classic T-shirt” জন্য, দুটি Option (Size, Color) এবং একাধিক Variant রেকর্ড। প্রতিটি Variant তার নির্বাচিত Option মানগুলো সংরক্ষণ করে (উদাহরণ: Size=M, Color=Black) এবং SKU থাকে (উদাহরণ: TSH-CL-M-BLK). ইনভেন্টরি Variant স্তরে ট্র্যাক করুন, Product স্তরে নয়।

UI-তে পছন্দ সংকুচিত করুন এবং ডেড-এন্ড প্রতিরোধ করুন। একটি পরিষ্কার প্যাটার্ন: প্রথমে সব Colors দেখান, তারপর চosen Color-এ যেসব Sizes আছে শুধু সেগুলো দেখান (অথবা উল্টো)। যদি “White + L” না থাকে, তাহলে সেটা সিলেক্ট করতে দেবেন না বা ডিসেবল করে স্পষ্ট নোট দেখাবেন।

এখন একটি বাণ্ডেল যোগ করুন: “Gift Set” যার মধ্যে রয়েছে:

• 1x Classic T-shirt (যেকোন ভ্যারিয়েন্ট হতে পারে)
• 1x Sticker pack (সাধারণ SKU)

বাণ্ডেল উপলব্ধতা সবচেয়ে সংকীর্ণ কম্পোনেন্ট দ্বারা সীমিত। যদি Sticker pack স্টক 5 থাকে, আপনি 5 টার বেশি বাণ্ডেল বিক্রি করতে পারবেন না, যদিও টি-শার্টের স্টক অনেক আছে। যদি বাণ্ডেল নির্দিষ্ট টি-শার্ট ভ্যারিয়েন্ট (উদাহরণ: Black M) দাবি করে, তখন বাণ্ডেল স্টক হবে min(StickerPackStock, BlackMStock)।

AppMaster-এ ব্যবহারিক পরবর্তী ধাপ:

• Data Designer-এ টেবিলগুলো তৈরি করুন (Products, Options, OptionValues, Variants, VariantOptionValues, Inventory, Bundles, BundleComponents)।
• Business Process Editor-এ “find valid variants” এবং “calculate bundle availability” বাস্তবায়ন করুন।
• একই প্রজেক্ট থেকে ওয়েব ও নেটিভ মোবাইল UI জেনারেট করুন, এবং একই ভ্যারিয়েন্ট ফিল্টারিং ও উপলব্ধতা নিয়ম সব জায়গায় ব্যবহার করুন।

যদি আপনি দ্রুত একটি এন্ড-টু-এন্ড প্রোটোটাইপ চান, AppMaster (appmaster.io) এমনভাবে ডিজাইন করা হয়েছে যাতে পূর্ণ ব্যবসায়িক লজিকসহ অ্যাপ তৈরি করা যায়—ঠিক যেটার ওপর ভ্যারিয়েন্ট সিলেকশন ও বাণ্ডেল ইনভেন্টরি নিয়ম নির্ভর করে।