Omnichannel inventory: आख़िरी पीस का वादा सिर्फ़ एक बार

आख़िरी नीली जैकेट दो ग्राहकों को चाहिए। एक दुकान के counter पर है, दूसरा online checkout कर रहा है। दोनों screen पर एक पीस available है। जैकेट किसे मिलेगी? यह समझाने के लिए बनाया गया उदाहरण है, किसी ग्राहक की case study नहीं। यही असली समस्या है: एक channel वादा कर चुका है, दूसरे को अभी पता नहीं।

ज़्यादा channel तभी उपयोगी हैं जब उनके वादे पूरे हों। हर जगह बेचना ज़रूरी नहीं। लेकिन website, दुकान और chat orders साथ चलाएँ तो stock का स्पष्ट प्रामाणिक स्रोत, location rules और exceptions सँभालने की व्यवस्था चाहिए।

इस guide में जैकेट को availability से reservation, dispatch, return और cash settlement तक देखेंगे। भरोसेमंद inventory के फ़ैसले समझेंगे; सिर्फ़ shared database से हर गलती ख़त्म होने का दावा नहीं करेंगे।

कई चैनल क्यों गड़बड़ी में बदल जाते हैं

अलग-अलग stock masters overselling की एक वजह हैं। Receipt देर से दर्ज होना, ग़लत गिनती, expired reservation न छूटना, offline POS और ग़लत SKU mapping भी वजह हो सकते हैं। स्पष्ट ownership, भरोसेमंद message delivery, reconciliation और failure handling हों तो अलग systems भी अच्छे चल सकते हैं। Sync होना अपने-आप में ख़राबी नहीं।

लक्षण जाने-पहचाने हैं:

• overselling भीड़ वाले दिनों में, और फिर माफ़ी के साथ order कैंसल।
• छिपा हुआ stock: outlet में सामान है, पर online "out of stock" दिख रहा है।
• courier का हाथ से काम: पते कॉपी करके courier portal में डालना, फिर tracking नंबर वापस कॉपी करना।
• बिना मिलाया COD: courier ने जो पैसा वसूला, उसे किसी ने order से मिलाकर नहीं देखा।
• return का सामान बिक्री वाले stock में वापस नहीं आता, या ग़लत लोकेशन पर पहुँच जाता है।

आर्किटेक्चर: खाता एक, दरवाज़े कई

Sales channel और physical location अलग हैं। Website channel है, outlet stock location। Fulfilment rules के अनुसार एक order कई locations से भी जा सकता है। एक authoritative inventory process सभी channels को read-only availability view दे सकता है। वह view पुराना हो सकता है; अंतिम acceptance guarded reservation से हो, पुराने screen से नहीं।

काउंटर नहीं, हर movement का खाता

Receipt, dispatch, transfer, जाँच के बाद return और approved adjustment जैसे physical movements का रिकॉर्ड रखें। Reservation को उनके साथ commitment की तरह अलग track करें। Reservation से वादा करने की क्षमता बदलती है; डिब्बा गोदाम से बाहर नहीं जाता। तेज़ पढ़ने के लिए balance summaries रख सकते हैं, बशर्ते वे लगातार सही update हों और मूल records से मिल सकें।

• Traceability: हर movement और reservation का source, actor, समय और वजह जोड़ें। History मिटाने के बजाय documented adjustment करें।
• Concurrency control: transactional availability check, सही locking या दूसरी tested atomic व्यवस्था चाहिए। आख़िरी पीस न पाने वाले request को सुरक्षित reject और record करें।
• Valuation: quantities accounting में मदद करती हैं, लेकिन costing method, landed cost और posting policy finance अलग approve करे।

असल में कितना है, और कितना promise कर सकते हैं?

हर SKU, location और unit of measure के लिए quantities तय करें। Damaged goods या safety stock हो तो तीन labels काफ़ी नहीं:

Quantity	मतलब
On hand	इस location पर असल में मौजूद; परिभाषा में शामिल blocked units सहित।
Reserved	Accepted orders के लिए तय, अभी dispatch नहीं हुआ।
Unavailable	Damaged, quarantine या दूसरे कारण से blocked; reservations को छोड़कर।
Safety buffer	Policy के अनुसार अलग रोकी गई मात्रा।
Available to promise	Buckets अलग हों तो: on hand − reserved − unavailable − safety buffer।

उदाहरण: on hand 12, पहले से reserved 3, damaged या quarantine में 2, safety buffer 1। ये buckets अलग हों तो available to promise = 12 − 3 − 2 − 1 = 6। Incoming purchase order आज भेजने लायक stock नहीं है। Future receipt पर backorder लें तो उसे अलग promise और सही अनुमानित तारीख़ के साथ दिखाएँ।

जब दो channel आख़िरी पीस चाहते हैं

अब आख़िरी जैकेट पर लौटें। Availability जाँचना और reservation commit करना एक guarded operation हो, जिसके बीच दूसरा sale वही पीस न ले सके। सिर्फ़ ledger यह लागू नहीं करता। Cancel या expiry पर reservation एक बार छोड़ें; dispatch पर उसे इस्तेमाल करते समय physical stock दो बार न घटाएँ। POS offline हो तो अलग stock allowance दें, या reconnect होने तक आख़िरी पीस का वादा सीमित करें।

ख़ुद देखिए

इस छोटे वीडियो में warehouse, outlet, stock की movement और low-stock alert एक ही inventory में दिखाए गए हैं।

POS counter: वही stock, वही customer

Shared platform POS का काम आसान कर सकता है, लेकिन business rules अपने-आप तय नहीं होते। मान लेने के बजाय ये बातें test करें:

• हर register की location तय करें; shift बंद करते समय cash, card और दूसरे tenders अलग मिलाएँ।
• Channel-specific price, promotion और tax rules तय करें। एक engine अलग वैध rules भी चला सकता है।
• Customer identity सावधानी से जोड़ें। 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 का सबूत है, cash मिलने या revenue recognize करने का सार्वभौमिक नियम नहीं। Fulfilment, payment, return और settlement अलग states रखें। समर्थित routine steps automate करें और unresolved exceptions किसी तय operator को दें।

1. Quote और validate: address, coverage, price और delivery promise जाँचें। असामान्य orders का निष्पक्ष review करें; पुराना return अकेले fraud का प्रमाण नहीं।
2. Reserve: available stock order को दें और expiry या cancellation release तय करें।
3. Pick और dispatch: actual lines, location और parcel identity दर्ज करें। Delivery record configured workflow से बनेगा, कोई सार्वभौमिक नियम नहीं।
4. सुरक्षित booking: unique shipment reference दें। Timeout के बाद retry से पहले जाँचें courier ने booking बनाई या नहीं। Failures दिखाएँ और bounded backoff रखें।
5. Updates: provider verify करें, duplicates पहचानें और देर से या उलटे क्रम में आए messages से सही बाद वाली state न बिगड़ने दें।
6. पैसा मिलाएँ: remittance को orders, fees, refunds, tax और adjustments से मिलाएँ। Differences जाँचें; delivered parcel bank receipt नहीं है।

तीनों नतीजों को सही तरीक़े से सँभालें

• Delivered: असल में स्वीकार की गई lines और quantities दर्ज करें। Payment, loyalty और accounting के अलग approved rules लगाएँ।
• Partly delivered: line-level evidence रखें। Missing, refused और रास्ते के items अलग सुलझाएँ; पूरा order delivered न करें।
• Returned: पहले inspection में भेजें। स्वीकार किए गए, दोबारा बेचने योग्य units ही receiving location पर available हों। Refund और accounting correction की अलग approval और posting rules हों।

Parcel पहुँचा, लेकिन पैसा नहीं मिला

COD समझने का उदाहरण: courier ने 100 currency units लिए, documented fee 8 काटी और 92 भेजे। Gross collection, fee और bank receipt साथ मिलाएँ। अगर 90 भेजे तो बचे 2 को जाँच के लिए साफ़ दिखाएँ, चुपचाप write-off न करें। सही accounts और tax treatment finance तय करे। Settlement के बाद return आए तो linked adjustments चाहिए; मूल payment evidence न मिटाएँ।

नीचे के delivery tour में courier, zone, driver और हर parcel का live status दिखाया गया है।

setup checklist: आठ क़दम में एक inventory

1. Locations, sellable conditions और हर stock field का authoritative source लिखें।
2. Channels के SKU/variant, units और barcode mappings साफ़ करें।
3. Opening quantity और cost approve करें; count के दौरान movements के लिए cut-off और reconciliation रखें।
4. पहले एक channel और location जोड़ें; reservation, expiry और cancellation test करें।
5. आख़िरी पीस के simultaneous requests और 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 owners और permission limits तय करें; pilot का हिसाब मिलने पर विस्तार करें।

वो आँकड़े जो बताएँगे कि सब ठीक है

माप	परिभाषा
Count-line accuracy	सही SKU-location lines ÷ checked lines × 100; value differences अलग दिखाएँ।
Stock-related cancellation	एक ही cohort में stock न होने से cancel accepted orders ÷ accepted orders।
Delivery outcome	Dispatch cohort के अनुसार delivered, partial, returned और open parcels।
Unmatched remittance	बिना समझाए differences की राशि और उम्र; सिर्फ़ imported files की गिनती नहीं।
Settlement lead time	Settled items में delivery से settlement का समय, साथ में unsettled items की उम्र।

Operations और finance के साथ baseline और targets तय करें। तुलना से पहले cohort, समय-सीमा और denominator लिखें। सभी के लिए एक “अच्छा” stock percentage या सात दिन का COD target नहीं होता। इन metrics में inventory, delivery और payment records जुड़ते हैं; सिर्फ़ stock ledger से सभी नहीं निकलते।

इन ग़लतियों से बचें

• एक database में भी ग़लत count, duplicate message या unauthorized adjustment हो सकते हैं। Reconcile करें।
• Quantity चुपचाप overwrite न हो; वजह, evidence और ज़रूरत पर approval लें।
• Transfer में dispatch और receipt अलग रखें; रास्ते का stock दोनों locations पर एक साथ sellable न हो।
• Minimum access दें। Courier को उस shipment की delivery details चाहिए, salary, पूरी customer list या सभी margins नहीं।
• Duplicate, failed और पुराने updates देखें। Timeout के बाद बिना जाँचे retry करने से दो courier bookings बन सकती हैं।

StoreConsole इसे कैसे सँभालता है

StoreConsole demo में अपना order लेकर Inventory, POS और Delivery का पूरा रास्ता जाँचें। अपने configuration में modules, courier capabilities और permissions की पुष्टि करें। सिर्फ़ सफल sale नहीं; आख़िरी पीस का conflict, damaged return और unmatched remittance भी देखें।

मुख्य बातें

• Stock promise authoritative reservation से करें, screen refresh से नहीं।
• Physical quantity, commitments और न बेचने योग्य quantity अलग रखें।
• Delivery, return, refund और remittance जुड़े हुए लेकिन अलग processes हैं।
• Traceable adjustments, सीमित access और exception owner रखें।
• नया channel खोलने से पहले मुश्किल उदाहरणों से workflow साबित करें।

स्रोत और समीक्षा

समीक्षा: 4 नवंबर 2026। Shopify की inventory-state documentation समझाती है कि on-hand stock का सब हिस्सा बिक्री के लिए available नहीं होता। PostgreSQL locking mechanisms सही transaction में मदद करते हैं; उसके design की जगह नहीं लेते। यहाँ के calculations और workflows शिक्षण के उदाहरण हैं, product feature guarantee नहीं।

• Shopify: inventory states
• PostgreSQL: explicit locking

अनिचुर रहमान सॉफ़्टवेयर आर्किटेक्ट और StoreConsole के संस्थापक हैं। वे बढ़ते कारोबारों के लिए कॉमर्स और ERP सिस्टम डिज़ाइन करते हैं — ख़ास ध्यान event-driven आर्किटेक्चर, डेटा की शुद्धता और अपने सर्वर पर चलने वाले सिस्टम पर।