किसी भी बिजनेस ऑनबोर्डिंग प्रवाह का पहला असली दबाव कंपनी के रिकॉर्ड पर पड़ता है। नाम, पंजीकरण संख्या, कर पहचान, पंजीकृत पता और प्रतिनिधि का विवरण — ये पांच चीजें एक साथ सही होनी चाहिए, वरना नीचे की हर प्रक्रिया झूठे निष्कर्ष पर पहुंचती है। जब आपका टेस्ट डेटा असली ग्राहकों का हो, तो यह जांचना भारी और संवेदनशील दोनों हो जाता है। कंपनी डेटा जनरेटर इसी जगह आता है, पर उसका फायदा पूरी तरह इस बात पर निर्भर है कि वह बनाया गया रिकॉर्ड अंदर से कितना सुसंगत है।
एक कंपनी का रिकॉर्ड अकेले फ़ील्ड का ढेर नहीं है। वह एक ऐसा बयान है जिसमें हर फ़ील्ड बाकी फ़ील्डों से बंधा है, और इन बंधनों की दिशा होती है। अगर आप अधिकार क्षेत्र बदलते हैं, तो कानूनी रूप, पंजीकरण संख्या का ढांचा, कर पहचान का ढांचा और पते का प्रारूप — सबको बदलना पड़ता है। जो जनरेटर इन बंधनों को नहीं समझता, वह ऐसे रिकॉर्ड बनाता है जो देखने में ठीक लगते हैं और परीक्षण में कभी टिकते ही नहीं।
कंपनी के नाम में कानूनी रूप प्रत्यय क्यों जुड़ा होता है?
कंपनी के नाम के आखिर में जो जुड़ा हुआ हिस्सा दिखता है, वह सजावट नहीं है। वह उस देश के कानून का हिस्सा है जिसमें वह इकाई दर्ज है। जर्मनी में जो प्रत्यय दिखता है वह सीमित देयता वाली कंपनी का संकेत देता है, स्पेन में वही भूमिका एक और रूप निभाता है, और मलेशिया में प्रत्यय के साथ कर्तव्य और संरचना दोनों बदल जाती है। यही बात खाड़ी देशों, तुर्की और दक्षिण एशिया के प्रत्ययों पर भी लागू होती है — हर प्रत्यय पीछे एक रजिस्ट्री, एक कानून और एक रिपोर्टिंग व्यवस्था खींचकर लाता है।
इसका सीधा अर्थ यह है कि प्रत्यय और अधिकार क्षेत्र अलग-अलग मनमानी से नहीं भरे जा सकते। अगर ऐसा रिकॉर्ड बनाया जाए जिसमें एक देश का प्रत्यय हो, दूसरे देश के ढांचे का पंजीकरण संख्या हो, और तीसरे देश का पता हो, तो वह कंपनी किसी भी दुनिया की रजिस्ट्री में दर्ज नहीं हो सकती। ऐसा रिकॉर्ड हानिरहित नहीं है, क्योंकि वह ऐसी जांच को पास करने की कोशिश करता है जिसे असली कंपनी के लिए पास करना संभव ही नहीं था।
समस्या अक्सर विराम चिह्न और विशेष अक्षरों पर सबसे पहले दिखती है। कुछ प्रत्ययों में बिंदु लगाना अनिवार्य नहीं है पर प्रचलित है, कुछ में आवश्यक है। तुर्की में एक विशेष अक्षर होता है जिसे उसके सरल रूप में बदलने से नाम की पहचान बदल जाती है। ऐसे नाम आम हैं जिनमें और का चिह्न आता है, और ऐसे भी जिनमें एक ही अक्षर दो बार जुड़कर बोलने में भिन्न लगता है। जो फ़ॉर्म इन चिह्नों को काट देता है, वह वैध नाम को अवैध बना देता है, और जो उन्हें अनदेखा करता है, वह दो अलग कंपनियों को एक मान लेता है।
अच्छा परीक्षण इसलिए नाम पर नहीं, नाम के साथ चलने वाले प्रत्यय पर केंद्रित होता है। आपको यह देखना चाहिए कि फ़ॉर्म किसी देश का प्रत्यय स्वीकार करता है या नहीं, और जब उपयोगकर्ता दूसरे देश का प्रत्यय चुनता है तो बाकी फ़ील्ड अपने आप बदलते हैं या नहीं। जो फ़ॉर्म प्रत्यय को स्वतंत्र पाठ मानकर चलता है, वह आगे किसी न किसी बिंदु पर असंगत रिकॉर्ड बनाएगा।
पंजीकरण संख्या और कर पहचान संख्या एक चीज नहीं हैं
ऑनबोर्डिंग में सबसे आम मॉडलिंग गलती यह है कि पंजीकरण संख्या और कर पहचान संख्या को एक ही फ़ील्ड मान लिया जाए। ये दो अलग जगहों से आते हैं और दो अलग काम करते हैं। पंजीकरण संख्या कंपनी रजिस्ट्री से मिलती है और यह बताती है कि इकाई उस देश में दर्ज है। कर पहचान संख्या कर विभाग से मिलती है और इसका संबंध रिपोर्टिंग और भुगतान से है। एक इकाई के पास दोनों हो सकती हैं, एक भी हो सकती है, और कुछ मामलों में एक ही संख्या दोनों काम कर सकती है।
इंटरनेट पर ऐसा कोई वैश्विक मानक नहीं है जो बताए कि पंजीकरण संख्या कितनी लंबी होगी या उसमें कौन से अक्षर आएंगे। हर देश का अपना ढांचा है, और कई देशों के अंदर भी कई ढांचे चलते हैं, क्योंकि अलग-अलग कानूनी रूपों के लिए अलग रजिस्ट्री होती हैं। कुछ संख्याएं केवल अंकों की होती हैं, कुछ में अक्षर पहले आते हैं, कुछ में साल शामिल होता है, और कुछ में क्षेत्रीय कोड भी जुड़ता है। इसका मतलब यह है कि लंबाई या ढांचे के आधार पर कोई सार्वभौमिक जांच नहीं लिखी जा सकती।
कर पहचान संख्या में अक्सर देश का कोड पहले जुड़ा होता है, और यह कोड उस अधिकार क्षेत्र से मेल खाना चाहिए जो रिकॉर्ड के बाकी हिस्से में बताया गया है। यहां एक बहुत साफ ढांचा बनता है: कर पहचान का पहला हिस्सा अधिकार क्षेत्र से बंधा है, इसलिए दोनों को अलग-अलग मनमानी से नहीं भरा जा सकता। ऐसे रिकॉर्ड जो एक देश का कोड दिखाते हैं पर दूसरे देश की संख्या का ढांचा रखते हैं, जांच में नकली लगते हैं — और ठीक वही नकलीपन है जिसे यह डेटा पकड़ना चाहता था।
इसलिए टेस्ट डेटा में दोनों फ़ील्ड अलग रखें, और दोनों को अधिकार क्षेत्र से बांधें। नकारात्मक परीक्षण भी जरूरी है: ऐसा टेस्ट बनाएं जिसमें कर पहचान का देश कोड जानबूझकर अधिकार क्षेत्र से अलग हो, और देखें कि आपका सिस्टम इसे पकड़ता है या चुपचाप स्वीकार कर लेता है। जो सिस्टम इसे स्वीकार करता है, वह आगे कभी भी इसी तरह की गलती पर बिना शोर काम करता रहेगा।
LEI और D-U-N-S पहचानकर्ता क्या हैं?
कुछ पहचानकर्ता वैश्विक स्तर पर बनाए गए हैं ताकि एक ही इकाई को अलग-अलग देशों की रजिस्ट्रियों में अलग-अलग तरह से पहचाने जाने की समस्या कम हो। इनमें से एक ऐसा पहचानकर्ता है जो बीस अक्षरों और अंकों से बनता है, जिसमें पहला हिस्सा उस संस्था को दर्शाता है जिसने इसे जारी किया और अंतिम दो अंक जांच अंक होते हैं। इन दो जांच अंकों का होना ही इसे पंजीकरण संख्या से अलग बनाता है, क्योंकि इससे यह स्वयं सत्यापित किया जा सकता है कि संख्या गढ़ी गई है या असली है।
दूसरी तरफ एक ऐसा पहचानकर्ता है जो नौ अंकों का होता है और जिसे सरकारी रजिस्ट्री नहीं, बल्कि एक व्यावसायिक डेटा कंपनी जारी करती है। यह फर्क महत्वपूर्ण है। यह पहचानकर्ता आधिकारिक दर्जे का प्रमाण नहीं है, और इसे उस तरह नहीं देखा जाना चाहिए जैसे किसी सरकारी रजिस्ट्री की प्रविष्टि देखी जाती है। लोग इसे अक्सर अधिकारिक मान लेते हैं क्योंकि यह बहुत व्यापक रूप से इस्तेमाल होता है, पर इसका स्रोत निजी है और इसका रखरखाव भी निजी हाथों में है।
जनरेटर के लिए इससे जो सबसे साफ नियम निकलता है, वह यह है कि उसे स्पष्ट रूप से बताना चाहिए कि वह जांच अंकों को सही रखता है या नहीं। अगर वह सही रखता है, तो सिस्टम की सत्यापन प्रक्रिया को उस स्तर तक परखा जा सकता है जहां वह जांच अंकों की गणना करती है। अगर वह नहीं रखता, तो यह साफ-साफ बताया जाना चाहिए, वरना आपका टेस्ट ऐसे डेटा का उपयोग करेगा जो हमेशा विफल होगा और विफलता का कारण आपके सिस्टम में नहीं होगा।
यहीं एक अद्भुत जाल भी छिपा है। अगर जनरेटर हर बार मान्य जांच अंक वाला पहचानकर्ता बनाता है, तो आपका नकारात्मक परीक्षण कभी नकारात्मक नहीं होगा। अगर वह हर बार अमान्य बनाता है, तो आपका सकारात्मक पथ कभी हरा नहीं होगा। दोनों तरह का डेटा चाहिए, और यह तय करने का अधिकार आपके पास होना चाहिए — इसलिए जनरेटर में इसका कोई स्विच मिलना जरूरी है।
कौन से फ़ील्ड मिलकर KYB रिकॉर्ड को सुसंगत बनाते हैं
अधिकार क्षेत्र वह केंद्रीय फ़ील्ड है जिससे बाकी सब निकलता है। वह तय करता है कि नाम में कौन सा प्रत्यय जुड़ेगा, पंजीकरण संख्या किस ढांचे की होगी, कर पहचान कैसी दिखेगी, और पते की पंक्तियां किस क्रम में लिखी जाएंगी। जो रिकॉर्ड इस केंद्र को मान लेता है और उसके अनुसार बाकी फ़ील्ड ढालता है, वह अंदर से साफ रहता है। जो रिकॉर्ड हर फ़ील्ड को स्वतंत्र मानकर भरता है, वह किसी न किसी मोड़ पर खुद से टकरा जाता है।
दूसरा बंधन पंजीकृत पते का है। पंजीकृत पता उसी देश का होना चाहिए जिसका अधिकार क्षेत्र है, और उसका प्रारूप उसी देश की परंपरा का होना चाहिए। यहीं सबसे ज्यादा सुसंगति टूटती है, क्योंकि बहुत से जनरेटर देश का नाम तो बदल देते हैं पर पते की संरचना वही पुरानी रख देते हैं। इसका नतीजा ऐसा रिकॉर्ड होता है जिसमें डाक कोड का ढांचा एक देश का है और पता दूसरे देश का। ऐसी गलती आंख से पकड़ में नहीं आती, पर जांच में सीधे पकड़ में आती है।
तीसरा बंधन प्रतिनिधि और स्थापना तिथि का है। स्थापना तिथि ऐसी होनी चाहिए जो अधिकार क्षेत्र के कानून के हिसाब से संभव हो, और प्रतिनिधि का डेटा भी उसी देश के अनुरूप होना चाहिए। ऐसा रिकॉर्ड जिसमें स्थापना तिथि बहुत हाल की है पर पंजीकरण संख्या बहुत पुराने ढांचे की है, या जिसमें प्रतिनिधि का नाम उस देश के लिए असंभव लंबाई का है, वह अपने भीतर ही टूटा हुआ है।
इन अनिवार्य क्षेत्रों के बाद कुछ ऐसे फ़ील्ड हैं जिन्हें स्वतंत्र कहा जा सकता है — कर्मचारियों की संख्या, आय का दायरा, उद्योग का वर्गीकरण, वेबसाइट। इनके बीच सीधा बंधन नहीं होता, पर इन्हें भी जानबूझकर बदलना चाहिए। अगर हर बनाई गई कंपनी में कर्मचारियों की संख्या एक ही रहती है और उद्योग हमेशा एक ही दिखता है, तो आपका टेस्ट डेटा आपके सिस्टम की वास्तविक विविधता नहीं परखेगा। यह चुपचाप होने वाली विफलता है, क्योंकि डेटा तो दिखता है, पर उसका दायरा सिकुड़ा हुआ है।
क्या बनाई गई कंपनियां असली इकाइयां होती हैं?
नहीं। जनरेटर जो रिकॉर्ड बनाता है, वह किसी भी देश की किसी भी रजिस्ट्री में दर्ज नहीं है। उसके पीछे कोई कर इतिहास नहीं है, कोई बैंक खाता नहीं है, कोई प्रतिनिधि नहीं है, और कोई कानूनी अस्तित्व नहीं है। वह केवल टेस्ट डेटा है जो ऐसी असली कंपनी जैसा दिखता है जैसी आपके सिस्टम को मिल सकती है।
यही इस डेटा की सबसे बड़ी ताकत है। क्योंकि इसका किसी असली इकाई से कोई संबंध नहीं है, इसे बेझिझक साझा किया जा सकता है। इसे स्क्रीनशॉट में दिखाया जा सकता है, किसी बग रिपोर्ट में चिपकाया जा सकता है, किसी टेस्ट फिक्स्चर में डाला जा सकता है। कोई गोपनीयता घटना नहीं होगी क्योंकि छिपाने के लिए यहां कुछ नहीं है।
इससे एक जरूरी अपेक्षा भी बनती है। जब आप ऐसी कंपनी को किसी सरकारी रजिस्ट्री, किसी सत्यापन सेवा या किसी क्रेडिट जांच में डालें, तो जवाब यही आना चाहिए कि ऐसी कोई इकाई नहीं मिली। यह विफलता नहीं है, यह सही व्यवहार है। जो सिस्टम इस जवाब को गलती मानकर अपना प्रवाह रोक देता है, उसमें सत्यापन और पुष्टि के बीच का फर्क ठीक से बना ही नहीं है।
एक बात का ध्यान रखना जरूरी है। बनाए गए नाम ऐसे नहीं होने चाहिए जो किसी असली, चल रही कंपनी के नाम से टकरा जाएं। अगर वैसा हो जाए, तो आपके टेस्ट डेटा का कोई रिकॉर्ड किसी असली इकाई के बारे में झूठा बयान बन सकता है, और वह नुकसान टेस्टिंग की सुविधा से कहीं बड़ा है। अच्छे जनरेटर ऐसे नाम बनाते हैं जो संरचना में विश्वसनीय हों पर शब्दकोश में न मिलें।
B2B फ़ॉर्म टेस्ट में क्या कवर करना चाहिए
सबसे पहले अधिकार क्षेत्र और कानूनी रूप की जोड़ी परखें। ऐसा टेस्ट बनाएं जिसमें एक देश का प्रत्यय दूसरे देश के रूप के साथ भेजा जाए, और देखें कि आपका फ़ॉर्म उसे पकड़ता है या नहीं। यह सबसे सस्ता टेस्ट है और सबसे ज्यादा असली समस्याएं उजागर करता है, क्योंकि ज्यादातर सिस्टम इस जोड़ी को कभी जांचते ही नहीं।
दूसरा, एक ही रन में कई देशों के पंजीकरण संख्या फ़ील्ड भेजें। कम से कम एक ऐसा मामला रखें जिसकी लंबाई आपके फ़ॉर्म की सीमा से ठीक भीतर हो, और एक ऐसा जिसकी लंबाई बहुत कम हो। ज्यादातर फ़ॉर्म केवल अधिकतम लंबाई जांचते हैं और न्यूनतम पर ध्यान नहीं देते, इसलिए छोटी और बेकार संख्याएं चुपचाप पास हो जाती हैं।
तीसरा, कर पहचान संख्या के नकारात्मक मामले बनाएं। ऐसा कोड भेजें जो अधिकार क्षेत्र से मेल न खाए, ऐसा कोड जो बहुत लंबा हो, और ऐसा कोड जिसमें ऐसे अक्षर हों जो उस व्यवस्था में कभी नहीं आते। देखें कि तीनों में से आपका सिस्टम कितनों को पकड़ता है। जो केवल पहला पकड़ता है, वह आधा सुरक्षित है।
चौथा, क्रम का असर भी परखें, क्योंकि डेमो और स्क्रीनशॉट का क्रम अक्सर वैसा नहीं होता जैसा असली उपयोग में होता है। अगर फ़ॉर्म में देश का चुनाव पंजीकरण संख्या के बाद आता है, तो ऐसे मामले बनाएं जिनमें उपयोगकर्ता पहले संख्या भरे और बाद में देश बदले। बहुत सी सुसंगति गलतियां इसी क्रम से पैदा होती हैं।
पांचवां, उन फ़ील्डों की सीमाएं छुएं जिन्हें अक्सर छोड़ दिया जाता है। ऐसा कंपनी नाम भेजें जिसमें और का चिह्न हो, ऐसा नाम जिसमें प्रत्यय के बिंदु हों, ऐसा नाम जो अधिकतम लंबाई पर ठीक बैठता हो, और ऐसा नाम जो उससे एक अक्षर आगे निकल जाए। इन चारों का व्यवहार अलग-अलग होता है, और चौथा मामला अक्सर उस जगह पर टूटता है जहां सबसे कम ध्यान गया था।
अंत में, इस पूरे डेटा को एक जगह बनाने और एक जगह रखने की आदत डालें। कंपनी के रिकॉर्ड पते और पहचान के साथ मिलकर ही काम करते हैं, इसलिए उन्हें अलग-अलग जगहों से इकट्ठा करने के बजाय एक ही स्रोत से बनाएं। अगर आपको शुरुआत के लिए एक ठोस जगह चाहिए, तो कंपनी टूल से शुरू करें, और उसके साथ सत्यापन के नियम, पते के प्रारूप तथा पहचान के फ़ील्ड को एक ही फिक्स्चर सेट में जोड़कर चलाएं। तब जाकर यह पता चलेगा कि आपका सिस्टम असली रिकॉर्ड संभालने के लिए तैयार है या अभी केवल सुंदर दिखने वाले डेटा पर चल रहा था।