दस्तावेज़ से तालिका में आए डेटा की जाँच कैसे करें?

फ़ाइल बदलने और जाँच करने को अलग समझें

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

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

हर पंक्ति को मूल दस्तावेज़ से जोड़ें

यह पता चलना चाहिए कि तालिका की पंक्ति किस फ़ाइल और पृष्ठ से आई है। काम की संख्या, दस्तावेज़ पहचान और पृष्ठ सूचना इस संबंध को दर्ज कर सकती हैं। केवल फ़ाइल नाम को अद्वितीय न मानें; उसी नाम की दूसरी प्रति आ सकती है। ज़रूरत हो तो स्रोत का संस्करण भी दर्ज करें। समीक्षक का उसी जानकारी को दोबारा खोज पाना, स्थानांतरण की तकनीक जानने से अधिक महत्वपूर्ण है।

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

फ़ील्ड को उनके अर्थ के अनुसार मिलाएँ

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

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

संख्याओं और पहचान का प्रारूप जाँचें

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

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

अपवाद उपयोगकर्ता को स्पष्ट दिखाएँ

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

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

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

सावधानी: दस्तावेज़ और पहुँच सुरक्षित रखें

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

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

अक्सर पूछे जाने वाले सवाल

तालिका भरी है तो क्या डेटा सही आया है?

नहीं। स्रोत संबंध, फ़ील्ड का अर्थ, संख्या का प्रारूप और रिकॉर्ड के संबंध भी जाँचना ज़रूरी है।

अपठनीय फ़ील्ड अपने आप पूरा करना चाहिए?

पहले से स्वीकृत नियम न हो तो अनुमान न लगाएँ; उसे समीक्षा माँगने वाले अपवाद के रूप में दिखाएँ।

परीक्षण के लिए कौन से दस्तावेज़ चुनें?

साफ़ उदाहरणों के साथ वास्तविक काम के अलग विन्यास और अधूरे फ़ील्ड को शामिल करने वाला छोटा प्रतिनिधि समूह चुनें।