ERP मॉड्यूल वास्तव में कैसे एकीकृत होते हैं

"एकीकृत" शब्द तीन अलग-अलग चीज़ें छिपाता है

लगभग हर ERP ब्रोशर "एकीकृत" शब्द का उपयोग करता है। उसके नीचे कम से कम तीन व्यवस्थाएँ होती हैं, जो महीने के अंत में कुछ ग़लत होने पर बहुत अलग ढंग से व्यवहार करती हैं। पहली है फ़ाइल या शेड्यूल्ड बैच ट्रांसफ़र: एक सिस्टम एक्सपोर्ट करता है, दूसरा इंपोर्ट करता है, आम तौर पर रात में। दूसरी है API या मिडलवेयर सिंक्रोनाइज़ेशन, जहाँ दो अलग डेटाबेस संदेशों के आदान-प्रदान से तालमेल में रहते हैं। तीसरी है सचमुच साझा डेटा, जहाँ मॉड्यूल अलग सिस्टम हैं ही नहीं, बल्कि तालिकाओं के एक समूह, एक जनरल लेज़र और मास्टर रिकॉर्ड्स के एक समूह पर अलग-अलग दृश्य हैं।

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

व्यावहारिक प्रश्न यह नहीं कि कौन-सा स्तर सबसे अच्छा है, बल्कि यह कि हर प्रवाह किस स्तर का हक़दार है। बैंक स्टेटमेंट का रात में ट्रांसफ़र ठीक है। लाइव पॉइंट ऑफ़ सेल के पीछे स्टॉक स्तरों का रात में ट्रांसफ़र ठीक नहीं है। Skyline Nexus अपने मॉड्यूलों के लिए तीसरे स्तर पर है: अकाउंटिंग, पॉइंट ऑफ़ सेल और इन्वेंटरी, CRM, रखरखाव, HR, फ़्लीट और एसेट्स एक ही लेज़र और मास्टर रिकॉर्ड्स के एक ही समूह में लिखते हैं, और जहाँ ग्राहक के पास पहले से रखने लायक सिस्टम है, वहाँ बाहरी सिस्टमों से API के ज़रिए जुड़ते हैं।

भटकाव मास्टर डेटा से शुरू होता है

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

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

सबलेज़र और कंट्रोल अकाउंट

जनरल लेज़र सारांशित शेष रखता है। विवरण सबलेज़र में रहता है, और हर सबलेज़र लेज़र के एक कंट्रोल अकाउंट से जुड़ा होता है। प्राप्य खाते (accounts receivable) हर ग्राहक इनवॉइस और रसीद की एक लाइन रखते हैं, जिनका योग प्राप्य कंट्रोल अकाउंट के बराबर होता है। देय खाते (accounts payable) आपूर्तिकर्ता बिलों के लिए यही करते हैं। इन्वेंटरी की हलचलें स्टॉक कंट्रोल अकाउंट में पोस्ट होती हैं, और माल बाहर जाने पर बिक्री लागत मान्य होती है। पेरोल सकल वेतन, नियोक्ता अंशदान, कटौतियाँ और शुद्ध देयताएँ पोस्ट करता है। फ़िक्स्ड एसेट्स परिवर्धन, मूल्यह्रास और निपटान को एसेट लागत और संचित मूल्यह्रास के सामने पोस्ट करते हैं। पॉइंट ऑफ़ सेल बिक्री, एकत्रित टैक्स, भुगतान के प्रकार और, जहाँ परपेचुअल इन्वेंटरी का उपयोग होता है, हर बिक्री का लागत पक्ष पोस्ट करता है।

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

रिकॉन्सिलिएशन एक ऐसी रिपोर्ट होनी चाहिए जिसे आप कभी भी चला सकें, न कि कोई स्प्रेडशीट जिसे कोई व्यक्ति संभालता हो। जब मॉड्यूल एक ही लेज़र साझा करते हैं, तो रिकॉन्सिलिएशन लगभग स्वतः-सिद्ध होता है। जब नहीं करते, तो यह वह अकेली सबसे महत्वपूर्ण जाँच है जिसे आप स्वचालित कर सकते हैं।

पोस्टिंग नियम और ऑडिट ट्रेल

लेज़र की हर लाइन को किसी स्रोत दस्तावेज़ तक ट्रेस किया जा सकना चाहिए: इनवॉइस नंबर, गुड्स रसीद, पेरोल रन, मूल्यह्रास शेड्यूल, पॉइंट-ऑफ़-सेल लेन-देन। अगर कोई लाइन बिना स्रोत के मौजूद है, तो किसी ने प्रक्रिया को बायपास किया है। दस्तावेज़ पहचानकर्ता को लेज़र लाइन के साथ चलना चाहिए, किसी अलग मैपिंग तालिका में नहीं बैठना चाहिए।

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

इंटीग्रेशन वास्तव में कहाँ टूटते हैं

विफलता के तरीक़े सुपरिचित हैं और लगभग हमेशा वही होते हैं।

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

आइडेम्पोटेंसी, और यह साबित करना कि दोनों पक्ष सहमत हैं

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

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

शाखाएँ और मुद्राएँ

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

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

क्षेत्रीय टिप्पणी: क्लियरेंस समय को बदल देता है

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

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