Omnichannel inventory: শেষ পিসটি একবারই বিক্রির প্রতিশ্রুতি দিন

শেষ নীল jacket-টি দুজন চান। একজন দোকানের counter-এ; অন্যজন online checkout করছেন। দুটো screen-এই available দেখাচ্ছে এক পিস। পণ্যটি কে পাবেন? এটি বিষয়টি বোঝানোর উদাহরণ, কোনো গ্রাহকের case study নয়। Omnichannel-এর আসল সমস্যাটি এখানেই: এক জায়গায় প্রতিশ্রুতি দেওয়া হয়ে গেল, অন্য জায়গা এখনো তা জানে না।

বেশি channel তখনই কাজে আসে, যখন দেওয়া প্রতিশ্রুতি রাখা যায়। সব জায়গায় বিক্রি করতেই হবে—এমন নয়। তবে website, দোকান ও chat order একসঙ্গে চালালে stock-এর নির্দিষ্ট কর্তৃপক্ষ, location rules এবং exception সামলানোর দৃশ্যমান ব্যবস্থা প্রয়োজন।

এই লেখায় jacket-টির available থাকা থেকে reservation, dispatch, return ও টাকা মেলানো পর্যন্ত পথ দেখব। একটাই database থাকলেই সব ভুল বন্ধ হবে—এমন ধারণা না দিয়ে, বিশ্বাসযোগ্য inventory তৈরির সিদ্ধান্তগুলো বুঝব।

একাধিক চ্যানেল কেন বিশৃঙ্খলায় গড়ায়

Stock-এর একাধিক master থাকলে overselling হতে পারে। তবে দেরিতে receipt লেখা, ভুল গণনা, মেয়াদ শেষেও reservation আটকে থাকা, offline POS এবং ভুল SKU mapping-ও কারণ। Ownership, message delivery, reconciliation ও failure handling ঠিক থাকলে আলাদা system-ও ভালো চলতে পারে। Sync থাকাটাই ভুল নয়।

লক্ষণগুলো খুব চেনা:

• overselling ব্যস্ত সময়ে, তারপর দুঃখ প্রকাশ করে order বাতিল।
• লুকিয়ে থাকা stock: outlet-এ পণ্য আছে, অথচ অনলাইনে দেখাচ্ছে "stock শেষ"।
• courier-র হাতের কাজ: ঠিকানা কপি করে courier-র portal-এ বসানো, তারপর tracking নম্বর আবার কপি করে আনা।
• না-মেলানো COD: courier যে টাকা তুলেছে, সেটা কেউ order-এর সঙ্গে মিলিয়ে দেখেনি।
• return-এর পণ্য আর বিক্রির তালিকায় ফেরে না, অথবা ফেরে ভুল লোকেশনে।

আর্কিটেকচার: হিসাবের খাতা একটা, দরজা অনেক

Sales channel আর পণ্য রাখার location আলাদা করুন। Website একটি channel; outlet একটি location। Fulfilment rules মেনে একই order কয়েকটি location থেকেও যেতে পারে। Inventory-র একটি দায়িত্বশীল process সব channel-এ availability-র read-only view দিতে পারে। সেই view পুরোনো হতে পারে; order নেওয়ার চূড়ান্ত সিদ্ধান্তে guarded reservation লাগবে।

কাউন্টার নয়, প্রতিটা movement-র খাতা

পণ্য আসা, পাঠানো, transfer, পরীক্ষা করে return গ্রহণ ও অনুমোদিত adjustment—প্রতিটি physical movement-এর record রাখুন। Reservation আলাদাভাবে commitment হিসেবে রাখুন। Reserve হলে বিক্রির প্রতিশ্রুতি দেওয়ার ক্ষমতা কমে, কিন্তু বাক্সটি গুদাম থেকে বের হয় না। দ্রুত দেখানোর জন্য balance summary রাখা যায়; তা যেন মূল record-এর সঙ্গে ধারাবাহিকভাবে update ও reconcile হয়।

• Traceability: প্রতিটি movement ও reservation-এর source, actor, সময় ও কারণ রাখুন। History মুছে না দিয়ে documented adjustment করুন।
• Concurrency control: transactional availability check, যথাযথ locking বা অন্য পরীক্ষিত atomic ব্যবস্থা লাগবে। শেষ পিসটি না পাওয়া request নিরাপদভাবে reject ও record করুন।
• Valuation: quantity accounting-কে সাহায্য করে, তবে costing method, landed cost ও posting rules finance আলাদাভাবে অনুমোদন করবে।

কতটুকু বাস্তবে আছে, কতটুকু promise করা যাবে?

প্রতিটি SKU, location ও unit-এর হিসাব সংজ্ঞায়িত করুন। Damaged stock বা safety stock থাকলে তিনটি label যথেষ্ট নয়:

Quantity	মানে
On hand	এই location-এ বাস্তবে আছে; সংজ্ঞা অনুযায়ী blocked পণ্যও এর মধ্যে থাকতে পারে।
Reserved	গ্রহণ করা order-এর জন্য ধরা আছে, এখনো dispatch হয়নি।
Unavailable	Damaged, quarantine বা অন্য কারণে blocked; reservation বাদ দিয়ে।
Safety buffer	Policy অনুযায়ী আলাদা করে আটকে রাখা quantity।
Available to promise	ভাগগুলো আলাদা হলে: on hand − reserved − unavailable − safety buffer।

উদাহরণ: on hand ১২, আগে reserved ৩, damaged বা quarantine-এ ২, safety buffer ১। এই ভাগগুলো একে অন্যের মধ্যে গণনা না হলে available to promise = ১২ − ৩ − ২ − ১ = ৬। Purchase order-এ আসার কথা আছে মানেই আজ পাঠানো যাবে না। Future receipt ধরে backorder নিলে সেটি আলাদা প্রতিশ্রুতি হিসেবে সঠিক সম্ভাব্য তারিখসহ দেখান।

দুই channel যখন শেষ পিসটি চায়

এবার শেষ jacket-টিতে ফিরি। Availability পরীক্ষা ও reservation commit এমন একটি নিয়ন্ত্রিত operation হতে হবে, যার মাঝখানে অন্য বিক্রি একই পিস নিতে পারবে না। শুধু ledger থাকলে এটি নিশ্চিত হয় না। Cancel বা expiry-তে reservation একবারই ছাড়ুন; dispatch-এ reservation ব্যবহার করার সময় physical stock দুবার কমাবেন না। POS offline থাকলে আলাদা stock allowance দিন, অথবা reconnect না হওয়া পর্যন্ত শেষ পিসের promise সীমিত করুন।

নিজের চোখে দেখুন

এই ছোট ভিডিওতে একটাই inventory-তে warehouse, outlet, stock-র movement আর low-stock alert দেখানো হয়েছে।

POS counter: একই stock, একই customer

এক platform-এ POS থাকলে কাজ সহজ হতে পারে, তবে business rules নিজে থেকে ঠিক হয় না। ধরে নেওয়ার বদলে এগুলো test করুন:

• প্রতিটি register-এর location ঠিক করুন; shift শেষে cash, card ও অন্য payment আলাদা করে মেলান।
• Channel অনুযায়ী price, promotion ও tax rules লিখুন। একই engine-এও ভিন্ন বৈধ rule থাকতে পারে।
• Customer identity সাবধানে link করুন। Shared history মানে প্রত্যেক cashier সব customer বা finance data দেখতে পারবেন না।
• Pickup expiry, cancellation ও অন্য location-এ return-এর নিয়ম service প্রচারের আগেই ঠিক করুন।
• যেখানে প্রয়োজন SKU-location অনুযায়ী reorder threshold দিন। প্রতিটি sale-এ নতুন alert নয়; threshold crossing-এ duplicate ঠেকিয়ে দায়িত্বশীল ব্যক্তিকে জানান।

delivery চক্র: "order এসেছে" থেকে "টাকা bank-এ"

Delivery status parcel সম্পর্কে তথ্য দেয়; টাকা এসেছে বা revenue recognize করতে হবে—তার সর্বজনীন প্রমাণ নয়। Fulfilment, payment, return ও settlement আলাদা state রাখুন। যেসব ধাপ integration সমর্থন করে সেগুলো automate করুন; অমীমাংসিত exception-এর জন্য নির্দিষ্ট operator রাখুন।

1. Quote ও validate: address, service coverage, charge ও delivery promise যাচাই করুন। অস্বাভাবিক order ন্যায্যভাবে review করুন; আগে return করেছেন মানেই fraud নয়।
2. Reserve: order-এর জন্য available stock ধরুন; expiry ও cancellation release ঠিক করুন।
3. Pick ও dispatch: actual line, location ও parcel identity লিখুন। Delivery record তৈরির ধাপ configuration অনুযায়ী হবে, সবার জন্য এক নয়।
4. নিরাপদ booking: unique shipment reference দিন। Timeout হলে retry-এর আগে courier booking হয়েছে কি না দেখুন। Failure দেখান ও সীমিত backoff ব্যবহার করুন।
5. Update গ্রহণ: provider যাচাই, duplicate শনাক্ত এবং দেরিতে বা উল্টো ক্রমে আসা message সামলান; সঠিক পরের state যেন নষ্ট না হয়।
6. টাকা মেলানো: remittance-এর সঙ্গে order, fee, refund, tax ও adjustment মিলিয়ে দেখুন। অমিল তদন্ত করুন; delivered parcel মানেই bank receipt নয়।

তিনটা ফলাফল ঠিকভাবে সামলান

• Delivered: কোন line কতটুকু গ্রহণ হয়েছে লিখুন। Payment, loyalty ও accounting-এর আলাদা অনুমোদিত rules প্রয়োগ করুন।
• Partly delivered: line অনুযায়ী প্রমাণ রাখুন। Missing, refused ও পথে থাকা পণ্য আলাদা করুন; পুরো order delivered করবেন না।
• Returned: আগে inspection-এ নিন। গ্রহণযোগ্য, আবার বিক্রির উপযুক্ত quantity-ই receiving location-এ available হবে। Refund ও accounting correction-এর নিজস্ব approval ও posting rules থাকবে।

Parcel পৌঁছেছে, কিন্তু টাকা মিলছে না

COD বোঝার উদাহরণ: courier ১০০ currency unit সংগ্রহ করল, documented fee ৮ কেটে bank-এ দিল ৯২। Gross collection, fee ও bank receipt একসঙ্গে মেলান। ৯০ দিলে বাকি ২ তদন্তের জন্য দৃশ্যমান রাখুন; চুপচাপ write-off নয়। কোন account ও tax treatment হবে finance ঠিক করবে। Settlement-এর পরে return এলে linked adjustment লাগবে; মূল payment evidence মুছবেন না।

নিচের delivery tour-এ courier, zone, driver আর প্রতিটা parcel-র live status দেখানো হয়েছে।

setup checklist: আট ধাপে একটাই inventory

1. Location, sellable condition ও প্রতিটি stock field-এর দায়িত্ব লিখুন।
2. Channel-গুলোর SKU/variant, unit ও barcode mapping পরিষ্কার করুন।
3. Opening quantity ও cost অনুমোদন করুন; count-এর সময় movement হলে cut-off ও reconciliation রাখুন।
4. প্রথমে এক channel ও location যুক্ত করুন; reservation, expiry ও cancellation test করুন।
5. শেষ পিসের simultaneous request ও offline POS policy test করুন।
6. Transfer, partial delivery, resaleable return ও damaged return test করুন।
7. Courier timeout, duplicate callback, fee বা short payment-সহ remittance test করুন।
8. Exception owner ও permission ঠিক করুন; pilot-এর হিসাব মেলার পরেই বিস্তৃত করুন।

যে সংখ্যাগুলো বলবে সব ঠিক চলছে

কী মাপবেন	সংজ্ঞা
Count-line accuracy	সঠিক SKU-location line ÷ পরীক্ষা করা line × ১০০; value difference আলাদা দেখান।
Stock-related cancellation	একই নির্ধারিত cohort-এ stock না থাকায় cancel হওয়া accepted order ÷ accepted order।
Delivery outcome	Dispatch cohort অনুযায়ী delivered, partial, returned ও এখনো open parcel।
Unmatched remittance	অব্যাখ্যাত অমিলের টাকার পরিমাণ ও বয়স; শুধু import করা file-এর সংখ্যা নয়।
Settlement lead time	Settled item-এর delivery থেকে settlement-এর সময়, সঙ্গে unsettled item-এর বয়স।

Operations ও finance মিলে baseline ও target ঠিক করুন। তুলনার আগে cohort, সময়সীমা ও denominator নির্দিষ্ট করুন। সবার জন্য একটি “ভালো” stock percentage বা সাত দিনের COD target নেই। এসব KPI-তে inventory, delivery ও payment data লাগে; শুধু stock ledger দিয়ে সব হিসাব হয় না।

যে ভুলগুলো এড়িয়ে চলবেন

• এক database-এও ভুল count, duplicate message বা অনুমতিহীন adjustment থাকতে পারে। নিয়মিত মেলান।
• চুপচাপ quantity overwrite নয়; কারণ, প্রমাণ ও প্রয়োজনীয় approval নিন।
• Transfer-এ dispatch ও receipt আলাদা রাখুন; পথে থাকা stock যেন দুই location-এ একসঙ্গে sellable না হয়।
• যতটুকু প্রয়োজন ততটুকু access দিন। Courier-এর shipment details লাগতে পারে; salary, পুরো customer list বা সব product margin নয়।
• Duplicate, failed ও পুরোনো update দেখুন। Timeout-এর পর না বুঝে retry করলে courier booking দুবার হতে পারে।

StoreConsole বিষয়টা যেভাবে সামলায়

StoreConsole demo-তে নিজের order দিয়ে Inventory, POS ও Delivery মিলিয়ে মহড়া দিন। আপনার configuration-এ কোন module, courier capability ও permission আছে তা যাচাই করুন। শুধু সফল sale নয়—শেষ পিস নিয়ে conflict, damaged return ও না-মেলা remittance দেখতে চান।

সংক্ষেপে

• Screen refresh নয়, দায়িত্বশীল reservation process দিয়ে stock promise করুন।
• Physical quantity, commitment ও বিক্রির অযোগ্য quantity আলাদা রাখুন।
• Delivery, return, refund ও remittance পরস্পর যুক্ত, কিন্তু আলাদা process।
• Traceable adjustment, সীমিত access ও exception owner রাখুন।
• নতুন channel খোলার আগে কঠিন উদাহরণ দিয়ে পুরো workflow যাচাই করুন।

তথ্যসূত্র ও পর্যালোচনা

পর্যালোচনা: ৪ নভেম্বর ২০২৬। Shopify-এর inventory-state documentation দেখায়, on-hand stock-এর সবটাই বিক্রির জন্য available নয়। PostgreSQL-এর locking documentation database mechanism ব্যাখ্যা করে; সঠিক business transaction-এর বিকল্প নয়। এখানকার হিসাব ও workflow বোঝানোর উদাহরণ, product feature guarantee নয়।

• Shopify: inventory states
• PostgreSQL: explicit locking

আনিছুর রহমান একজন সফটওয়্যার আর্কিটেক্ট এবং StoreConsole-এর নির্মাতা। বাড়তে থাকা ব্যবসার জন্য তিনি কমার্স ও ERP সিস্টেম ডিজাইন করেন — বিশেষ মনোযোগ event-driven আর্কিটেকচার, ডেটার নির্ভুলতা আর নিজের সার্ভারে চালানো সিস্টেমের ওপর।