प्रत्येक ऑब्जेक्ट, प्रत्येक मॉक और अंतिम लोड समान छह चरणों से गुजरते हैं: एक्सट्रैक्ट (ग्राहक डेटा स्वामी), मैप (माइग्रेशन कंडक्टर और प्रमुख उपयोगकर्ता), वैलिडेट (कॉकपिट के नियम), गैर-उत्पादन में ट्रायल लोड (माइग्रेशन कंडक्टर), रिकंसाइल (वित्त नियंत्रक), और कटओवर (काउंटडाउन स्वामी)।
जब तक सब कुछ साफ़ न हो जाए, तब तक लूप चलता रहता है। अस्वीकृत रिकॉर्ड कॉकपिट के कारण कोड के साथ उसके डेटा स्वामी के पास वापस चला जाता है, और अगला मॉक पूरे ऑब्जेक्ट को फिर से चलाता है। लक्ष्य टेनेंट में कभी भी मैन्युअल रूप से कुछ भी ठीक नहीं किया जाता है - ऐसा करने से ऑडिट ट्रेल में एक ऐसे लोड का विवरण रह जाएगा जो कभी हुआ ही नहीं।
| चलाएँ | कब | स्वीकार करें जब |
|---|---|---|
| एम1 | टी-10 → टी-9 | सभी ऑब्जेक्ट लोड हो जाते हैं; 5% से कम होने पर अस्वीकार कर दिए जाते हैं और असाइन कर दिए जाते हैं |
| एम2 | टी-7 → टी-6 | शून्य टीबी डेल्टा; उप-लेजर टाई; 0.5% से कम अस्वीकृतियाँ |
| शुष्क-परीक्षण कटाई | टी-4 → टी-3 | शून्य डेल्टा; कटओवर विंडो के भीतर की अवधि; रनबुक अपडेट की गई |
| पूर्वाभ्यास डेटा | टी-2 → टी-1 | पूर्वाभ्यास सफल रहा |
| अंतिम | टी-0 | शून्य डेल्टा; नियंत्रक हस्ताक्षर करता है |
सामंजस्य गणित है
- गणना और हैश योग: प्रति वस्तु निकाले गए = लोड किए गए + अस्वीकृत; राशियों और मात्राओं पर हैश योग।
- ट्रायल बैलेंस: प्रत्येक खाते, इकाई और आयाम के लिए लेगेसी बैलेंस − TRANXACT बैलेंस = 0।
- उप-लेजर: एआर एजिंग, एपी एजिंग, स्टॉक वैल्यूएशन और एसेट रजिस्टर, ये सभी अपने जीएल कंट्रोल अकाउंट के बराबर होते हैं।
टूलकिट के डेल्टा फ़ॉर्मूले किसी भी गैर-शून्य मान पर लाल हो जाते हैं, और वित्त नियंत्रक तभी हस्ताक्षर करता है जब प्रत्येक पंक्ति शून्य हो, या स्पष्ट रूप से समझाई और अनुमोदित की गई हो। कॉकपिट का रन लॉग—किसने क्या, कब, कितने रिकॉर्ड लोड किए, कितने अस्वीकृत किए—वह ऑडिट ट्रेल है जिसके आधार पर वे हस्ताक्षर करते हैं।
निष्कर्षण स्रोत पर निर्भर करता है
प्रोजेक्ट प्लान वर्कबुक में प्रत्येक स्रोत सिस्टम की अपनी अलग शीट होती है। पैटर्न अलग-अलग होते हैं — बड़े ERP के लिए मानक रिपोर्ट और टेबल एक्सट्रैक्ट, क्लाउड अकाउंटिंग के लिए सेव्ड सर्च या CSV एक्सपोर्ट, अन्य के लिए लेजर और वाउचर के XML या Excel एक्सपोर्ट, स्प्रेडशीट के लिए सीधे भरे गए कॉकपिट टेम्प्लेट — और सावधानियां भी अलग-अलग होती हैं: कंपनी कोड बनाम एंटिटी, सेगमेंट बनाम डाइमेंशन, स्प्रेडशीट में स्रोत पर कोई सत्यापन नहीं। गाइड में उत्पाद के अनुसार पूरी तालिका दी गई है।
टी-0 रनबुक (उदाहरण के तौर पर समय)
| समय | चरण | स्वामी |
|---|---|---|
| टी-1 18:00 | अंतिम पुराने लेन-देन; रोक की घोषणा की गई | उलटी गिनती के मालिक |
| टी-1 18:30 | पूर्व अवधि का समापन; अंतिम टेबल टेबल और उप-लेजर रिपोर्ट | वित्तीय नियंत्रक |
| टी-1 20:00 | प्रत्येक वस्तु के लिए अंतिम अर्क | डेटा स्वामी |
| टी-1 21:00 | ड्राई-रन अनुक्रम में अंतिम कॉकपिट लोड | प्रवासन संचालक |
| टी-0 02:00 | टीबी और उप-लेजर का मिलान — अंतर = 0 | वित्तीय नियंत्रक |
| टी-0 06:00 | उत्पादन एंडपॉइंट्स के साथ एकीकरण | ऑप्स पायलट |
| टी-0 07:00 | पुरानी केवल पढ़ने योग्य साइट; उपयोगकर्ता सक्षम; लाइव होने से पहले संचार | फ्लाइट लीड |
| T-0 ≈ 11:00 | उत्पादन में पहला चालान पोस्ट किया गया | प्रमुख उपयोगकर्ता, बिक्री |
प्रत्येक चरण का एक नामित स्वामी, एक नियोजित अवधि और एक रोलबैक नोट होता है, और टूलकिट नियोजित समाप्ति समय और ड्राई रन के मुकाबले विचलन की गणना करता है।
कैल्डरवुड के M2 में 1400 इन्वेंट्री 2,450,009.10 (लेगेसी में) और 2,449,909.10 (TRANXACT में) दिखा रहा है: अंतर 100.00 है, जिसे CHECK के रूप में चिह्नित किया गया है। इसका कारण एक स्टॉक लाइन का लॉट नंबर न होने के कारण अस्वीकार किया जाना है। यह कारण कोड के साथ वेयरहाउस डेटा स्वामी को वापस भेजा जाता है, और अगला मॉक पूरे स्टॉक ऑब्जेक्ट को फिर से चलाता है - कोई भी व्यक्ति TRANXACT में लाइन को मैन्युअल रूप से दर्ज नहीं करता है।
इसे अजमाएं कैल्डरवुड का ड्राई रन शून्य पर समाप्त होता है, लेकिन 11 घंटे की कटओवर अवधि के मुकाबले 13 घंटे लगते हैं, क्योंकि नौ P1 अवधि के जर्नल धीरे-धीरे लोड होते हैं। T-Minus क्या करने का सुझाव देता है?
दायरा कम करें, समय सीमा न बढ़ाएं: पी1 जर्नल के पीरियड डेटा को T-Plus में स्थानांतरित करें और गो-लाइव के बाद उन्हें लोड करें, न कि कटओवर को लंबा खींचें। यदि कोई ड्राई रन ठीक से नहीं होता है, तो वह सुधार सूची है, न कि तारीख में देरी।