टैक्स आईडी सत्यापन: चेक अंक असल में क्या साबित करता है

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

यह फ़र्क़ सैद्धांतिक नहीं है। जो टीम इन दोनों को मिला देती है, वह ऐसा वैलिडेटर बनाती है जो एक ही बार में दोनों दिशाओं में नाकाम होता है: वह गढ़े हुए नंबर स्वीकार कर लेता है, और असली ग्राहकों को अस्वीकार कर देता है। नीचे वह ढांचा है जिससे यह दोनों नाकामियां एक साथ ठीक होती हैं।

टैक्स पहचानकर्ता क्या है?

यह किसी कर प्राधिकरण द्वारा किसी करदाता को दिया गया पहचानकर्ता है, और दुनिया भर में उसका आयोजन आश्चर्यजनक रूप से अलग है। इसे समझे बिना कोई भी सत्यापन नियम जल्द ही बेमेल हो जाता है।

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

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

कुछ टैक्स नंबरों में चेक अंक क्यों होता है?

क्योंकि चेक अंक डिज़ाइन के समय का एक सस्ता, असरदार तरीका है टाइपिंग की गलतियां पकड़ने का। किसी लंबे पहचानकर्ता में एक अंक गलत टाइप होना, दो अंकों का आपस में बदल जाना, या आसपास के अंक दब जाना बहुत आम मानवीय त्रुटियां हैं। जब संरचना में एक अतिरिक्त अंक जोड़ा जाता है जिसकी गणना बाकी अंकों से तय नियम से होती है, तो इनमें से बहुत सी गलतियां किसी सर्वर तक पहुंचने से पहले ही पकड़ी जा सकती हैं।

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

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

क्या सत्यापन पास कर लेना मतलब नंबर असली है?

नहीं। पास होना यह बताता है कि संरचना अंदर से सुसंगत है, और बस इतना।

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

अस्तित्व की पुष्टि सिर्फ़ जारी करने वाला प्राधिकरण कर सकता है। व्यवहार में इसका मतलब है कि स्तर पैटर्न आधारित सुझाव तक ही सीमित रहें और यह दावा करने से रुकें कि कोई नंबर वैध है या नहीं।

इस तालिका का हर नकारात्मक नतीजा किसी अलग संदेश की मांग करता है। कोई भी नहीं कहता कि कारोबार मौजूद नहीं है; वे यह कहते हैं कि जो जांच चलाई गई वह उतना ही पकड़ सकी।

सत्यापन की परतें कैसे बनानी चाहिए?

तीन परतों में, जहां हर परत वही सवाल पूछे जिसका जवाब वह असल में दे सकती है।

1. स्थानीय संरचना — विराजक हटाएं, केस सामान्य करें, और सिर्फ़ वह अस्वीकार करें जो किसी भी ज्ञात प्रारूप में संभव ही नहीं। यह परत तेज़ है, ऑफ़लाइन है, और इसे किसी वैल्यू के बारे में कुछ दावा नहीं करना चाहिए।
2. राष्ट्रीय चेक अंक — सिर्फ़ जहां नियम प्रकाशित और सत्यापित हो। नाकामी को ऐसी चेतावनी की तरह पेश करें कि इसमें टाइपो की संभावना है, जिसे उपयोगकर्ता ठीक कर सके।
3. आधिकारिक लुकअप — अगर संबंधित प्राधिकरण आधिकारिक सेवा प्रकाशित करता है, तो वही अस्तित्व का अधिकार है। यह अतुल्यकालिक हो सकता है और इसका बर्ताव साफ़ तौर पर बताया जाना चाहिए।

परतों को मिलाएं नहीं। अगर संरचना परत का नतीजा और लुकअप परत का नतीजा एक ही बूलियन में बदल दिए जाएं, तो अनुपलब्ध सेवा और गलत नंबर एक जैसी एरर बन जाती हैं, और टीम पता भी नहीं लगा पाती कि उसका सिस्टम क्यों कुछ ग्राहकों को रोक रहा है।

डेवलपर्स के लिए: एरर, कैश और ऑडिट ट्रेल

बूलियन के बजाय स्पष्ट नतीजे का प्रकार रखें। असत्यापित, आकार में सही, लुकअप से पुष्ट, और लुकअप में नहीं मिला — ये चार मान एक सच झूठ से कहीं ज़्यादा उपयोगी हैं, और यही फ़र्क़ है जिससे कोई प्रोडक्ट टीम तय कर पाती है कि कौन से नतीजे आगे बढ़ने दें और कौन से मैनुअल समीक्षा में जाएं।

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

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

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

अगले कदम

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