W

WMS और WCS के साथ पुट वॉल सिस्टम को एकीकृत करने के लिए तीन समन्वित डेटा प्रवाह की आवश्यकता होती है: WMS से नीचे की ओर ऑर्डर और वेव डेटा, वॉल से ऊपर की ओर प्लेसमेंट और कन्फर्मेशन इवेंट, और WCS और वॉल कंट्रोलर के बीच उपकरण कमांड। वास्तविक समय ऑर्डर ट्रैकिंग तब प्राप्त होती है जब प्रत्येक स्कैन इवेंट में एक ऑर्डर पहचानकर्ता, एक लाइन पहचानकर्ता और एक टाइमस्टैम्प होता है, और जब WMS उन इवेंट्स को डिस्प्ले डेटा के बजाय इन्वेंट्री-संबंधित लेनदेन के रूप में मानता है। जो प्रोजेक्ट विफल होते हैं वे आमतौर पर प्रोटोकॉल पसंद पर नहीं, बल्कि मैपिंग स्वामित्व और इवेंट सिमेंटिक्स पर विफल होते हैं। मानक कॉन्फ़िगरेशन के लिए इंटरफ़ेस विकल्प हमारे पुट वॉल सिस्टम पेज पर वर्णित हैं।

तीन संदेश प्रवाह

1. नीचे की ओर: ऑर्डर, वेव और क्यूब़ी असाइनमेंट

WMS एक वेव भेजता है जिसमें ऑर्डर हेडर, SKU और मात्रा के साथ ऑर्डर लाइनें, और प्रत्येक ऑर्डर के लिए क्यूब़ी असाइनमेंट शामिल होता है। यह संदेश संस्करणित होना चाहिए, क्योंकि रद्दीकरण, शॉर्ट पिक और मध्य-वेव प्रतिस्थापन सामान्य हैं। एक वॉल कंट्रोलर जो केवल एक एकल अपरिवर्तनीय वेव स्वीकार करता है, या तो परिवर्तनों को अस्वीकार कर देगा या, इससे भी बदतर, उन्हें चुपचाप लागू कर देगा।

2. ऊपर की ओर: प्लेसमेंट, कन्फर्मेशन और कंप्लीशन

प्रत्येक स्कैन एक इवेंट उत्पन्न करता है: आइटम SKU, लक्ष्य ऑर्डर, क्यूब़ी, ऑपरेटर, टाइमस्टैम्प, और परिणाम (प्लेस किया गया, अस्वीकृत, अपवाद)। WMS को कन्फर्म किए गए प्लेसमेंट को एक वास्तविक लेनदेन के रूप में मानना चाहिए जो ऑर्डर स्थिति को अपडेट करता है, न कि UI सिग्नल के रूप में। यही ऑर्डर ट्रैकिंग को वास्तविक समय बनाता है बजाय शिफ्ट के अंत में पुनर्निर्मित होने के।

3. पार्श्व: उपकरण कमांड और स्थिति

जहां वॉल कन्वेयर या सॉर्टर के साथ इंटरफेस करता है, WCS रिलीज कमांड जारी करता है और क्यूब़ी-फुल, ब्लॉकर और फॉल्ट सिग्नल प्राप्त करता है। WCS को भौतिक रूटिंग निर्णयों का स्वामित्व लेना चाहिए; WMS को ऑर्डर निर्णयों का स्वामित्व लेना चाहिए। दो जिम्मेदारियों को मिलाना सबसे आम वास्तुशिल्प त्रुटि है।

एकीकरण विकल्प की तुलना

डेटा मॉडल आवश्यकताएँ

• अद्वितीय इवेंट आईडीताकि डुप्लिकेट कन्फर्मेशन को सुरक्षित रूप से छोड़ा जा सके।
• ऑर्डर-लाइन ग्रैन्युलैरिटी; ऑर्डर-स्तरीय इवेंट आंशिक प्लेसमेंट का समर्थन नहीं कर सकते।
• ऑपरेटर और स्टेशन पहचानकर्ताजवाबदेही और उत्पादकता विश्लेषण के लिए।
• मोनोटोनिक टाइमस्टैम्पएक सिंक्रनाइज़्ड घड़ी से; ड्रिफ्टिंग कंट्रोलर ट्रैकिंग को दूषित करते हैं।
• कारण कोडप्रत्येक अपवाद के लिए, एक निश्चित एन्यूमरेशन में मैप किया गया।
• क्यूब़ी स्थिति इतिहासकेवल वर्तमान स्थिति नहीं, इसलिए ड्वेल टाइम को मापा जा सकता है।

विशिष्ट एकीकरण दोष

स्वीकृति परीक्षण चेकलिस्ट

• ऑर्डर को मध्य-वेव में रद्द करके वेव संस्करण संघर्ष का परीक्षण किया गया।
• प्रेरण के दौरान नेटवर्क हानि का परीक्षण डुप्लिकेट और खोए हुए इवेंट के लिए किया गया।
• अपवाद प्रवाह का परीक्षण एंड-टू-एंड किया गया, जिसमें WMS कारण-कोड मैपिंग शामिल है।
• कंट्रोलर, WCS और WMS के बीच घड़ी सिंक्रनाइज़ेशन सत्यापित किया गया।
• विलंबता को 95वें पर्सेंटाइल पर मापा गया, औसत पर नहीं।
• फेलओवर व्यवहार प्रलेखित: WMS अनुपलब्ध होने पर क्या होता है?
• ऐतिहासिक इवेंट प्रतिधारण ऑडिट और उत्पादकता विश्लेषण के लिए परिभाषित किया गया।

गो-लाइव कटओवर अनुक्रम

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

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

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

इंटरफ़ेस दस्तावेज़ीकरण जो आपको प्राप्त होना चाहिए

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

इन छह दस्तावेजों के बिना, हर भविष्य का परिवर्तन रिवर्स इंजीनियरिंग बन जाता है, और पुट वॉल सिस्टम धीरे-धीरे एक ब्लैक बॉक्स बन जाता है जिसे केवल मूल इंटीग्रेटर ही सुरक्षित रूप से संशोधित कर सकता है।

गो-लाइव के बाद परिवर्तन नियंत्रण

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

निष्कर्ष

वास्तविक समय ऑर्डर ट्रैकिंग बैंडविड्थ पर नहीं, बल्कि इवेंट सिमेंटिक्स पर निर्भर करती है। परिभाषित करें कि ऑर्डर मैपिंग का स्वामित्व किसके पास है, प्रत्येक प्लेसमेंट को आइडम्पोटेंसी कुंजी के साथ एक लेन-देन संबंधी इवेंट बनाएं, भौतिक रूटिंग को WCS के साथ और ऑर्डर लॉजिक को WMS के साथ रखें, और गो-लाइव से पहले विफलता पथों का परीक्षण करें। मानक वॉल कॉन्फ़िगरेशन के लिए इंटरफ़ेस क्षमताएं हमारे पुट वॉल सिस्टम श्रेणी पृष्ठ पर वर्णित हैं।