क्या सिस्टम विकास का अनुबंध बिना अनुबंध पत्र के भी स्थापित हो सकता है?
सिस्टम विकास में, विकासकर्ताओं द्वारा कार्य को आगे बढ़ाने के लिए अक्सर अनुबंध निर्माण से पहले ही काम शुरू कर दिया जाता है। हालांकि, यह प्रवाह वास्तविक रूप से “खतरनाक” है। अनुबंध निर्माण नहीं होने के कारण, बाद में समस्या उत्पन्न होने पर, आदेशकर्ता द्वारा “अभी तक अनुबंध स्थापित नहीं हुआ है, इसलिए मुझे भुगतान करने की आवश्यकता नहीं है” ऐसा कहा जा सकता है, जिससे जोखिम उत्पन्न होता है। वास्तव में, सिस्टम विकास संबंधी विवादों में, अनुबंध की स्थापना स्वयं को विवादित किया जाता है, और फिर, विकासकर्ता के पक्ष में अनुकूल निर्णय लिए जाते हैं। विकासकर्ता के रूप में, आदेशकर्ता द्वारा परियोजना को रोकने या अन्य कंपनी के पास स्थानांतरित करने के मामले में, भुगतान प्राप्त करने का जोखिम होता है। इसके अलावा, नीचे उल्लिखित के अनुसार, अनुबंध निर्माण होने पर भी अनुबंध की स्थापना नकार दी जाती है।
यहां, हम सिस्टम विकास अनुबंध की सफलता या असफलता, और अनुबंध की स्थापना मान्य नहीं की गई होने पर धन की मांग करने के कानूनी ढांचे के बारे में विवरण देंगे।
समझौते का निर्माण
समझौता, सिद्धांततः, दोनों पक्षों के बीच समझौते के तत्वों पर सहमति (आवेदन की इच्छा और स्वीकृति की इच्छा का मेल) के माध्यम से स्थापित होता है।
जब समझौता स्थापित हो जाता है, तो दोनों पक्ष समझौते से बाध्य हो जाते हैं, और यदि एक पक्ष समझौते की शर्तों को पूरा नहीं करता है, तो दूसरे पक्ष को न्यायालय के माध्यम से पूरा करने के लिए बाध्य करने का अधिकार होता है, या अनुपालन नहीं करने के खिलाफ नुकसान भरपाई का दावा कर सकते हैं। ‘समझौते के तत्व’ को विशेष रूप से निर्धारित किया जाना चाहिए, या यह स्पष्ट होना चाहिए।
सिस्टम विकास समझौते का निर्माण
सिस्टम विकास समझौते की प्रकृति मुख्य रूप से ठेका समझौता और अनुबंध समझौता है। ठेका समझौता कार्य के समापन और उसके लिए भुगतान का वादा करता है। शुल्क युक्त अनुबंध समझौता कार्य के पूरा होने और उसके लिए भुगतान का वादा करता है।
https://monolith.law/corporate/contract-and-timeandmaterialcontract[ja]
इसलिए, समझौते के तत्व ‘कार्य या कार्य की विवरण’ और ‘भुगतान राशि’ हैं, और यदि इस पर पक्षों के बीच सहमति होती है, तो समझौता स्थापित होने के लिए माना जाता है।
वैसे, केवल मुख्य वादा भी स्थापित हो सकता है, और समझौता पत्र अनिवार्य नहीं है।
सिस्टम विकास समझौते के निर्माण के बाद रोक दिए जाने पर धन का दावा
यदि सिस्टम विकास का समझौता स्थापित हो चुका है, और उपयोगकर्ता द्वारा एकतरफा रोक दिया जाता है, तो कानूनी रूप से यह माना जाता है कि समझौते का निराकरण सूचित किया गया है।
यदि ठेका समझौता स्थापित हो चुका है, तो विक्रेता को उपयोगकर्ता से, कार्य के समापन तक किसी भी समय निराकरण किया जा सकता है, लेकिन इसके बावजूद नुकसान भरपाई की स्थिति में होने का नियम बनाया गया है (जापानी सिविल कोड धारा 641)। इसलिए, यदि उपयोगकर्ता द्वारा कोई नुकसान भरपाई नहीं की गई है, तो विक्रेता उस समय तक खर्च की गई लागत और प्राप्त होने वाली भुगतान राशि से, सिस्टम के पूरा होने से बचने के कारण बचत की गई लागत को काटकर ‘नुकसान’ का दावा कर सकता है।
इसके अलावा, यदि अनुबंध समझौता स्थापित हो चुका है, तो जब अनुबंध का पालन मध्य में समाप्त होता है, तो ग्राहक पालन की अनुपात में भुगतान का दावा कर सकता है (संशोधित जापानी सिविल कोड धारा 648, अनुच्छेद 3)। इसलिए, विक्रेता पहले से किए गए कार्य के भुगतान का दावा कर सकता है।
सिस्टम विकास समझौते की सफलता या असफलता
सिस्टम सामग्री की विशेषता
सामान्यतः, कंपनियों के बीच लेन-देन, विशेषकर जब राशि बड़ी होती है, तो लिखित रूप में होती है, इसलिए यदि अनुबंध पत्र तैयार किया गया हो, तो अनुबंध की स्थापना को मान्यता दी जाने में आसानी होती है।
विकास के लिए चुने गए सिस्टम को विभिन्न कदमों के माध्यम से धीरे-धीरे विशेष रूप से तैयार किया जाता है, इसलिए ठेका अनुबंध के तत्वों में से एक ‘काम की सामग्री’ के लिए सिस्टम सामग्री की विशेषता, सिस्टम को विशेष रूप से बनाने के लिए रेंज और अवलोकन के स्तर की विशेषता होती है।
न्यायाधीश के फैसले में, मूल अनुबंध पत्र और गोपनीयता संरक्षण अनुबंध के समापन पर कोई विवाद नहीं था, मूल अनुबंध पत्र में ‘ई-कॉमर्स व्यापार तकनीकी सहायता, वेबसाइट निर्माण सहायता और उनसे संबंधित कार्य’ को सौंपने का उल्लेख था, लेकिन ई-कॉमर्स व्यापार की विशेष जानकारी और सौंपे गए कार्य की रेंज, सिस्टम के रूप में विकास, डिजाइन की रेंज को स्पष्ट रूप से नहीं बताया गया था, इसलिए अनुबंध की स्थापना को नकार दिया गया था।
यदि आपने सिस्टम विकास मूल अनुबंध पत्र तैयार किया है, तो भी काम या कार्य सामग्री सामान्य रूप से विशेष रूप से नहीं मानी जाती है, और अनुबंध की स्थापना को मान्यता दी जाने में कठिनाई होती है। काम या कार्य सामग्री, मुआवजा की राशि, जो पूर्णता को मजबूर करती है, और अनुपालन की पहचान करने के लिए पर्याप्त रूप से विशेष रूप से उल्लिखित अनुबंध पत्र आदि के माध्यम से, अनुबंध की स्थापना को मान्यता दी जा सकती है।
वैसे, व्यक्तिगत इंजीनियर और कानूनी व्यक्ति के बीच अनुबंध के संबंध में सतर्क बिंदुओं आदि का विस्तृत विवरण निम्नलिखित लेख में दिया गया है।
विक्रेता प्रस्ताव और विशेषताओं का विवरण प्रस्तुत करता है, और उपयोगकर्ता इसे स्वीकार करके आदेश देता है
सामान्यतः, कंपनियों के बीच कारोबार में लिखित दस्तावेज़ों का उपयोग होता है, इसलिए यदि अनुबंध नहीं बनाया गया है, तो अनुबंध की स्थापना को मान्यता देना मुश्किल हो जाता है। सिस्टम विकास में अक्सर अनुबंध बनाने से पहले काम शुरू कर दिया जाता है, लेकिन ऐसे मामले में, अनुबंध की स्थापना के बारे में कैसे सोचा जाता है?
न्यायाधीश के फैसले (नागोया जिला न्यायालय, 28 जनवरी 2004 (हेइसेई 16)) में, सिस्टम विकास के ठेके के अनुबंध की स्थापना के बारे में निम्नलिखित बातें कही गई हैं:
- विक्रेता और उपयोगकर्ता के बीच विशेषताओं की पुष्टि आदि के व्यापार के बाद,
- विक्रेता द्वारा विशेषताओं का विवरण और प्रस्ताव आदि प्रस्तुत किए जाते हैं,
- और इसे उपयोगकर्ता द्वारा स्वीकार करके आदेश दिया जाता है।
इस न्यायाधीश के फैसले में, विक्रेता ने, उपयोगकर्ता के रूप में स्वशासन निकाय से, वित्तीय लेखांकन सिस्टम आदि की स्थापना के लिए ठेका लिया था, जहां “समग्र प्रशासनिक सूचना सिस्टम की स्थापना के बारे में प्रस्ताव पत्र का प्रस्तुत करने के बारे में (अनुरोध)” शीर्षक वाला RFP प्रस्तुत किया गया था, और इसके जवाब में प्रस्ताव पत्र और प्रस्ताव प्रस्तुत किया गया था, और उपयोगकर्ता ने “चयन सूचना” प्रस्तुत की थी। विक्रेता ने, उपयोगकर्ता के व्यापार की विशेषताओं आदि के बारे में उपयोगकर्ता के साथ बैठक करके या अन्य तरीके से पर्याप्त विचार नहीं किया, और उपयोगकर्ता के अंदर भी कस्टमाइज़ की विशेषताओं और लागत के बारे में विशेष रूप से विचार किया गया था, और विक्रेता के प्रस्ताव पत्र की सामग्री भी विशेष नहीं थी, और उपयोगकर्ता ने किस बात की स्वीकृति दी थी, यह स्पष्ट नहीं था, और अनुबंध की स्थापना को मान्यता नहीं दी गई थी।
न्यायाधीश के फैसले में उल्लिखित अनुबंध स्थापना के बारे में, अन्य न्यायाधीश के फैसलों आदि को भी ध्यान में रखते हुए विस्तार से व्याख्या की जाएगी।
विक्रेता और उपयोगकर्ता के बीच विशेषताओं की पुष्टि आदि के व्यापार के बाद
“व्यापार के बाद” का अर्थ है कि यदि सिस्टम की सामग्री और मुआवजा की राशि जैसे अनुबंध के तत्व “व्यापार के दौरान” होते हैं, तो सहमति नहीं होती है, और अनुबंध की स्थापना को मान्यता देना मुश्किल हो जाता है।
हालांकि, ठेके के अनुबंध में भुगतान को मार्केट रेट के अनुसार निर्धारित किया जा सकता है, इसलिए सिस्टम की सामग्री, “अनुमानित” मुआवजा की राशि आदि के बारे में उपयोगकर्ता ने स्वीकृति दी है, तो मार्केट रेट के अनुरूप भुगतान के साथ ठेके का अनुबंध स्थापित हो गया है, ऐसा माना गया है।
“व्यापार के बाद” के लिए, विक्रेता को, उपयोगकर्ता के व्यापार की सामग्री, सिस्टम की सामग्री आदि के बारे में उपयोगकर्ता के साथ बैठक करके या अन्य तरीके से पर्याप्त विचार करने की सलाह दी जाती है, और इसे ईमेल या मीटिंग के नोट्स आदि में रिकॉर्ड करना चाहिए।
विक्रेता द्वारा विशेषताओं का विवरण और प्रस्ताव आदि प्रस्तुत किए जाते हैं, और इसे उपयोगकर्ता द्वारा स्वीकार करके आदेश दिया जाता है
- यदि उपयोगकर्ता द्वारा आदेश पत्र या आदेश पत्र जारी किया जाता है, तो अनुबंध स्थापना को मान्यता देना आसान हो जाता है। यदि विक्रेता ने आवेदन पत्र प्रस्तुत किया है, या आदेश पत्र आदि के आधार पर काम किया है, तो “सहमति” होने की संभावना अधिक होती है, और अनुबंध स्थापना को मान्यता देना आसान हो जाता है।
- उपयोगकर्ता के आंतरिक निर्देश पत्र में आमतौर पर अनुबंध समापन की योजना की जानकारी होती है, और अनुबंध स्थापना को मान्यता देना मुश्किल होता है। हालांकि, यदि ऐसा कोई उल्लेख नहीं हो, और सिस्टम विकास की सामग्री और मुआवजा की राशि जैसे अनुबंध के तत्वों के बारे में संभवतः विशेष रूप से उल्लेख किया जाए, तो अनुबंध स्थापना को मान्यता देने की दिशा में काम करेगा।
- मेमोरेंडम, समझौता, पुष्टि पत्र आदि का अनुबंध स्थापना को मान्यता देना मुश्किल होता है, यदि यह अन्य अनुबंध समापन के आधार पर हो, या अस्पष्ट सामग्री हो।
- यदि अनुबंध प्रस्ताव पर मुहर नहीं लगी होती है, तो मुहर लगाने का अर्थ होता है कि समापन हो गया है, और अनुबंध स्थापना को मान्यता देना मुश्किल होता है।
- प्रस्ताव पत्र मौलिक रूप से भुगतान की राशि की पुष्टि करने के लिए प्रमाण होता है, जिस पर पक्षों के बीच सहमति होती है।
वैसे, सिस्टम विकास में कुछ हद तक प्रक्रिया के बाद, यदि विशेषताओं में बाद में परिवर्तन की मांग की जाती है, या फ़ंक्शन को जोड़ने की मांग की जाती है, तो पूर्वानुमानित राशि के ऊपर अतिरिक्त शुल्क की मांग करने की क्षमता आदि के विवरण निम्नलिखित लेख में विस्तार से व्याख्या किए गए हैं।
https://monolith.law/corporate/increase-of-estimate[ja]
समझौता समायोजन
यदि आपने अनुबंध के समापन की पूर्व धारणा के साथ उपयोगकर्ता से निर्देश प्राप्त करके कार्य किया है, तो कार्य रोकने के समय आपको उस कार्य के लिए भुगतान करने के लिए ‘समझौता समायोजन’ की मान्यता मिल सकती है। इस समझौते को और अधिक स्वीकार करने के लिए, यदि अनुबंध का समापन नहीं हुआ है, तो भुगतान के समायोजन के तरीके के बारे में, उपयोगकर्ता से अंतर्निहित पत्र आदि लिखित रूप में लिखने के लिए कहें, या विक्रेता द्वारा तैयार किए गए दस्तावेज़ पर उपयोगकर्ता के अधिकारी की सहमति प्राप्त करें।
यदि समझौते की स्थापना स्वीकार नहीं की गई हो, तो धन की मांग करने की कानूनी संरचना
समझौते के निर्माण पर लापरवाही
जब समझौते के निर्माण के लिए वार्ता शुरू होती है, तो पक्षकारों को एक दूसरे की संपत्ति का उल्लंघन न करने का प्रयास करने का एक आपसी आस्था के नियम के तहत दायित्व (जापानी सिविल कोड की धारा 1 क्लॉज 2) उठाना पड़ता है। यदि समझौता स्थापित नहीं होता है, तो पक्षकार को, यदि समझौते की स्थापना निश्चित होने की उम्मीद और दोषपूर्णता के साथ वास्तविक परिस्थितियाँ होती हैं, तो उस दायित्व का उल्लंघन करने के लिए नुकसान भरपाई की मांग कर सकते हैं। इसे समझौते के निर्माण पर लापरवाही कहते हैं।
हम समझौते के निर्माण पर लापरवाही को मान्यता दी गई मामलों का विवरण पेश करते हैं।
- विक्रेता ने उपयोगकर्ता की मांग पर आवश्यकता परिभाषा को समाप्त कर दिया था, और मूल डिजाइन, विस्तृत डिजाइन का एक हिस्सा भी किया गया था, जहां उपयोगकर्ता ने अन्य कंपनियों को बोली लगाने के लिए कार्रवाई करने के लिए अध्यक्ष को अनुमति देने के लिए एक आकारात्मक चीज है, ऐसा विवरण दिया गया था, लेकिन समझौते के निर्माण से ठीक पहले अन्य कंपनी का चयन किया गया, और समझौता स्थापित नहीं हुआ।
- विक्रेता ने उपयोगकर्ता से समय पर डिलीवरी करने की मांग की पूर्ति करने के लिए काम को आगे बढ़ाया, और समझौते के निर्माण की योजना बनाई गई थी, जबकि उपयोगकर्ता के अंदर अपने स्वयं के विकास के लिए तैयारी आगे बढ़ रही थी, लेकिन इसे छिपाया गया, और समझौता स्थापित नहीं हुआ।
- विक्रेता को उपयोगकर्ता से निर्माण कारोबारी के रूप में निर्धारित किया गया था, और कोई संदेह उठाने वाली बात नहीं थी, और उपयोगकर्ता की मुलाकात के आधार पर विशेषताएं निर्धारित करने का काम किया, और खर्च के बारे में भी उपयोगकर्ता ने मान्यता दी थी, जहां अनुमानित राशि सहमत नहीं हो सकी थी, ऐसे कारण से समझौते का निर्माण अस्वीकार कर दिया गया था।
उलटा, जहां समझौते के निर्माण पर लापरवाही को मान्यता नहीं दी गई थी, वहां अन्य कंपनी के चयन की संभावना या समझौते के निर्माण की शर्तें स्पष्ट रूप से बताई गई थीं।
उपयोगकर्ता की मांग पर काम करने के लिए, अपने अलावा किसी और का चयन होने की संभावना या सहमति की शर्तों के बारे में स्पष्ट रूप से बताए बिना, उन्हें अचानक समझौते की वार्ता तोड़ दी गई है, तो नुकसान भरपाई की मांग की मान्यता मिल सकती है।
उस स्थिति में ‘नुकसान’ की सीमा में, जो खर्च अब तक किए गए हैं, उसमें विवाद नहीं है। इसके अलावा, वास्तविक रूप से किए गए काम के हिस्से का लाभ शामिल होने का निर्णय दिया गया है। इसके अलावा, अगर आप अन्य कंपनी से आवेदन को खारिज करते हैं, और उसके बाद काम करते हैं, तो आपको जो लाभ मिला होता है, उसके बराबर का नुकसान हुआ है, यदि आप प्रमाण पेश करते हैं, तो उसके बारे में भी बताया गया है।
जापानी वाणिज्य कानून धारा 512
विक्रेता ने उपयोगकर्ता के लिए सिस्टम विकास संबंधी कार्य किए हैं, तो वे जापानी वाणिज्य कानून धारा 512 के आधार पर, उचित मुआवजा की मांग कर सकते हैं।
सिस्टम विकास के बारे में वार्ता शुरू करने के बाद, सिस्टम की सामग्री और मुआवजा की राशि के बारे में, ईमेल या मीटिंग रिकॉर्ड्स का उपयोग करके दोनों पक्षों को समझना चाहिए, और समझौते की स्थापना की स्थिति और समझौते के तत्वों की विशेषताएं स्पष्ट करने के लिए प्रमाण छोड़ देना चाहिए।
वास्तव में, यदि आपने समझौता नहीं किया है, ऐसे कारण से, यदि आपने भुगतान करने से इनकार कर दिया है, तो ऊपर के अनुसार धन की मांग की मान्यता मिल सकती है।
सारांश
इस प्रकार, न्यायालय आमतौर पर ऐसे संविदा संबंधों के बारे में, जहां संविदा पत्र मौजूद नहीं होता, ‘नकारात्मक’ निर्णय लेने में आसानी होती है, कम से कम यदि हम ठेकेदार कंपनी की समझ के साथ तुलना करें। ठेकेदार कंपनी के दृष्टिकोण से, वे कहना चाहेंगे कि “हमने सिर्फ पहले काम शुरू कर दिया था, संविदा पत्र बाद में समाप्त होना चाहिए था, और संविदा स्वयं पूर्ण हो चुका था”, लेकिन यह दावा हमेशा स्वीकार नहीं किया जाता है।
इसके अलावा, यदि संविदा स्थापना नकार दी गई है, तो उपरोक्त तरीके से, संविदा समापन की लापरवाही या जापानी वाणिज्य कानून धारा 512 (जापानी वाणिज्य कानून) जैसे कानूनी ढांचे के तहत धन की मांग करने की स्थिति भी हो सकती है, लेकिन यह भी ‘निश्चित’ नहीं होता है।
यदि संविदा पत्र समापन से पहले कार्य शुरू करना अनिवार्य हो, तो:
- पहले से ही यह एक जोखिम भरा कार्य है, और इस जोखिम को ध्यान में रखते हुए भी, क्या इस मामले के लिए कार्यबल का उपयोग करना चाहिए, यह व्यवसायिक निर्णय लेना चाहिए (विशेष रूप से छोटे और मध्यम उद्यमों और स्टार्टअप कंपनियों के मामले में, बड़ी कंपनियों से प्रोजेक्ट प्राप्त करने के लिए, ‘पहले ही काम शुरू करने’ का व्यवसायिक निर्णय लेना अनिवार्य हो सकता है। यदि जोखिम को शामिल किया गया है, तो यह एक संभाव्य व्यवसायिक निर्णय हो सकता है।)
- संविदा स्थापना नहीं होने की स्थिति में, क्या विलय समझौता पत्र आदि का समापन संभव है, इसकी जांच करें
ऐसा सोचने की आवश्यकता हो सकती है।
Category: IT
Tag: ITSystem Development
