कानूनी स्वरूप: अधिकार क्षेत्र के हिसाब से कंपनी के प्रकार

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

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

कानूनी स्वरूप क्या तय करता है?

वह कारोबार का ढांचा तय करता है। पंजीकरण के समय चुने गए स्वरूप से चार चीज़ें निकलती हैं।

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

यह स्वरूप यह भी तय करता है कि कानून में इकाई को क्या कहा जाएगा। कोई रजिस्ट्री ऐसा नाम स्वीकार नहीं करेगी जो ऐसी संरचना का दावा करे जिसके तहत कंपनी पंजीकृत नहीं है, और इसीलिए नाम तथा स्वरूप में सुसंगति होनी ही चाहिए।

किसी ठेठ अधिकार क्षेत्र में कौन से स्वरूप होते हैं?

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

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

एक ही कारोबार को अलग जगहों पर अलग स्वरूप क्यों चाहिए?

क्योंकि सीमा पर उपलब्ध विकल्पों की सूची बदल जाती है, और उस सूची के हर विकल्प से जुड़ी लागत तथा दायित्व भी।

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

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

नाम का प्रत्यय और कानूनी स्वरूप एक ही है?

प्रत्यय उसका दिखने वाला संकेत है, और बस इतना ही। नाम पर लगा प्रत्यय स्वरूप की घोषणा करता है; स्वरूप ख़ुद कानून से परिभाषित होता है और रजिस्टर में दर्ज होता है।

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

तो: स्वरूप को डेटा के रूप में रखें, उसके साथ देश रखें, और प्रत्यय को डिस्प्ले तथा सुसंगति जांच के लिए इस्तेमाल करें, सत्य का स्रोत मानने के लिए नहीं।

सिस्टम में स्वरूपों को कैसे मॉडल करना चाहिए?

एक नियंत्रित शब्दावली के रूप में — यानी एक सूची — जो किसी देश या अधिकार क्षेत्र से बंधी हो, जिसमें स्थिर आंतरिक कोड और डिस्प्ले के लिए स्थानीयकृत लेबल हों।

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

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

इतिहास दूसरी ज़रूरत है। कंपनियां स्वरूप बदलती हैं — निजी कंपनी सार्वजनिक बनती है, भागीदारी निगमित होती है — और जो सिस्टम पुरानी वैल्यू पर नई लिख देता है वह किसी पुराने रिकॉर्ड को समझाने की क्षमता खो देता है। मौजूदा स्वरूप, उसके लागू होने की तारीख़, और पिछली वैल्यू रखें, और बदलाव को एक घटना मानें।

डेवलपर्स के लिए: सूचियां, स्थानीयकरण और इतिहास

स्वरूप को एक कोड और एक अधिकार क्षेत्र कोड के रूप में दर्शाएं, और इंसान के पढ़ने लायक लेबल को रेंडर के समय किसी स्थानीयकरण तालिका से निकालें। इससे भंडारित वैल्यू स्थिर रहती है जबकि डिस्प्ले हर भाषा में सही हो सकता है।

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

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

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

अगले कदम

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