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