Mis on lepingu tühistamise viisid süsteemiarenduses?
Süsteemiarenduse projektid on pikad ja seetõttu on loomulik, et nende edenemise käigus võib tekkida olukordi nagu “põlemine”. Ja kuigi oleks ideaalne, kui kasutajad ja müüjad suudaksid alati ühes rütmis liikuda, peaksime arvestama ka võimalusega, et lepingu lõpetamist võidakse mingil hetkel kaaluda.
Selles artiklis selgitame lepingu “lõpetamise” õiguslikku võimalust, mis on süsteemiarenduse kontekstis oluline.
Süsteemiarenduse ja tühistamise seos
Mis on tsiviilõiguse alusel tühistamine?
Muudetud tsiviilseadustikus on lepingu “tühistamise” üldised sätted sätestatud paragrahvides 540 kuni 548. Lepingu tühistamine tähendab, et juba sõlmitud lepingu mõju kaotatakse tagantjärele.
Kui rääkida kasutaja ja tarnija suhtest, siis tavaliselt, kui leping on sõlmitud, on tarnijal kohustus süsteemi arendada ja kasutajal on kohustus tasu maksta. Ja need kohustused muutuvad mõlema poole “õigusteks”. Kui see tühistatakse, siis mõlema poole kohustused ja õigused naasevad lepingu sõlmimise eelsele seisule. Seega, isegi kui on veel täitmata kohustusi, kaob kohustus neid täita ja mõlemal poolel tekib kohustus naasta lepingu sõlmimise eelsele seisule. Seda nimetatakse “algse olukorra taastamise kohustuseks”.
Muuseas, kui samal ajal on tekkinud kahju, on võimalik ka eraldi kahjude hüvitamine.
Süsteemiarenduse praktiline töö ja tühistamise seos
Neile, kes on tuttavad äriõigusega, nagu süsteemiarendus, võib lepingu “tühistamine” esmalt meenutada tühistamisteatist. Kuid õiguslikult, isegi kui piirduda süsteemiarenduse kontekstiga, jagunevad alusparagrahvid tühistamise põhjuste järgi kaheks suureks kategooriaks.
Kui põhjuseks on kohustuse mittetäitmine (täitmise viivitus)
(Näide) Kui tarnija ei vasta tarnimisele, hoolimata asjaolust, et ta on ületanud algselt lubatud tähtaja
Tsiviilseadustiku paragrahv 541 Kui üks pooltest ei täida oma kohustust, võib teine pool määrata mõistliku aja ja nõuda selle täitmist ning kui selle aja jooksul ei ole täitmist toimunud, võib teine pool lepingu tühistada.
Süsteemiarenduse lepingu puhul on “üks pooltest” tarnija ja tema “kohustus” on valmistada ja tarnida süsteem vastavalt nõuetele. Seega, kui tarnija ei tarni hoolimata tähtaja ületamisest, tähendab see teisisõnu, et tarnija ei ole tööd tähtajaks lõpetanud. Aga mis on “töö lõpetamine” süsteemiarenduse kontekstis? Selle kohta on üksikasjalik selgitus allpool toodud artiklis.
https://monolith.law/corporate/completion-of-work-in-system-development[ja]
Kui põhjuseks on puuduste garantii kohustus
(Näide) Kui tarnija poolt tarnitud süsteemil on palju vigu ja andmete ebatäpsusi ning hiljem selgub, et see ei sobi praktiliseks kasutamiseks
Tsiviilseadustiku paragrahv 635 Kui töö objektil on puudusi ja seetõttu ei saa lepingu sõlmimise eesmärki saavutada, võib tellija lepingu tühistada. Kuid see ei kehti hoonete ja muude maapealsete ehitiste kohta.
Muuseas, kui vaadata süsteemiarenduse projekti vaatenurgast, siis tarnija poolt lepingu tühistamise avaldus ei ole tavaline. Tavaliselt peaks eeldama, et kasutaja teeb tarnijale tühistamisavalduse.
Puuduste garantii kohustuse kohta on üksikasjalik selgitus allpool toodud artiklis.
https://monolith.law/corporate/defect-warranty-liability[ja]
Lõpetamisteate ja sellega seotud õigusprobleemid
Lõpetamisteade on dokument, mida kasutatakse (tavaliselt kasutaja poolt tarnijale) lepingu lõpetamise teatamiseks. Seadusesättena võib viidata järgmisele:
Tsiviilseadustiku § 541: Kui üks pool ei täida oma kohustusi, võib teine pool määrata mõistliku aja nõude täitmiseks ja kui nõue ei ole selle aja jooksul täidetud, võib teine pool lepingu lõpetada.
Kui vaadata seda süsteemiarenduse dokumendina, siis lõpetamisteate eripära on see, et see ei ole mõeldud projekti sujuva kulgemise tagamiseks, vaid projekti lõpetamiseks. Samuti on oluline omadus see, et see on dokument, millelt oodatakse otseseid õiguslikke tagajärgi.
Kuid nagu eespool toodud sättest nähtub, erinevalt lepingust, on see (teatud tingimustel) piisav ainult ühe poole tahteavalduseks. Kui kasutaja esitab tarnijale lõpetamisteate, võib tarnija poolt vastutav isik olla probleemi ees, et “isegi kui ma loen lõpetamisteate, ei saa ma aru, miks leping lõpetati”. Niisiis, kui palju peaks kasutaja lõpetamisteate koostamisel lõpetamise põhjust täpselt märkima?
Kas tühistamisteatele tuleks kirjutada tühistamise põhjus?
Varasemate kohtuotsuste põhjal ei ole tühistamisteates tühistamise põhjuse selgitamine tingimata vajalik. Allpool tsiteeritud kohtuotsus käsitleb juhtumit, kus tarnitud süsteemil esines probleeme, mis viisid õigusliku vaidluseni. Küsimus oli selles, kui palju peaks kasutaja pool tühistamise avalduses süsteemi probleeme täpselt mõistma ja neid täpselt välja tooma. Kohtu seisukoht oli järgmine:
Tühistamise avalduses ei pea tingimata näitama tühistamise põhjust ja mitme tühistamise põhjuse korral saab tühistamise teha ühe avaldusega. Kui tühistamise avalduses tuuakse välja mingi põhjus, siis eriliste asjaoludeta, näiteks kui ei ole selgelt öeldud, et teiste põhjuste korral ei tühistata, peetakse seda avaldust kõigi olemasolevate põhjuste alusel kogu lepingu lõpetamise avalduseks.
Tokyo District Court, December 22, Heisei 16 (2004)
Kohtu seisukoht on, et “mitme tühistamise põhjuse korral saab tühistamise teha ühe avaldusega”. Teisisõnu, oluline on, kas lepinguosalisel on tühistamise tahe, mitte see, kas ta peab üksikasjalikult välja tooma tühistamise täpse põhjuse.
Seega, isegi kui tarnitud süsteem on veel lõpetamata või on olulisi defekte, mis teevad sellest “Japanese ~” seaduse alusel vastutuse küsimuse, ei pea neid küsimusi tühistamise avalduse tegemisel arvesse võtma. Isegi kui need keerulised küsimused jätta esialgu kõrvale, on võimalik tühistamise avaldus esitada ja hiljem, kui tekib vaidlus, võib tühistamise aluseks olla nii täitmise viivitus kui ka vastutus defektide eest.
- Tarnitud on lõpetamata süsteem… → kohustuse rikkumine
- Tarnitud on süsteem, millel on olulised defektid… → vastutus defektide eest
Isegi kui põhjust ei täpsustata üksikasjalikult, on tühistamise avaldus tühistamise avaldusena kehtiv.
Siiski, kui tühistamise põhjus on täpselt välja toodud ja tühistamisteade esitatud, on ka eeliseid, näiteks võimalus vältida kommunikatsiooni segadust või arusaamatusi tarnijaga. Samuti on see kasulik tühistamisteate saajale, sest kui tal on mõte tühistamise põhjusele, on vähem muret, et see võib hiljem vaidluseks muutuda. Seega on tõsi, et tühistamise põhjus tuleks võimaluse korral selgelt kirja panna.
Mis on “mõistlik aeg”, mille on määratlenud teade?
Veel üks küsimus, mida võib kaaluda, on see, kui pikk on “mõistlik aeg” Jaapani tsiviilseadustiku (Minpō) § 541 järgi. Kuid selle küsimuse puhul ei pruugi olla vaja liiga murelik olla. Sest isegi kui te ei ole määranud “mõistlikku aega” enne teate esitamist, on lepingu lõpetamine võimalik, kui teatest on möödunud mõistlik aeg. Samuti on lepingu lõpetamine võimalik isegi siis, kui teate esitamise ajal ei ole möödunud “mõistlik aeg”, kuid mõistlik aeg on möödunud, mis on selgelt kinnitatud ka kohtupraktikas.
Süsteemiarendusprojektides, kus esineb täitmise viivitus või defektide garantii vastutus, ei ole tõenäoline, et pärast “mõistliku aja” määramist ja teate esitamist toimub tarnimine või defektide parandamine. Arvestades seda, ei ole tõenäoline, et praktilises töös tekiks tõsiseid vaidlusi “mõistliku aja” üle.
Süsteemiarenduse viivituse määratlust selgitame eraldi artiklis.
https://monolith.law/corporate/performance-delay-in-system-development[ja]
Kuidas teavitada vabastamise teatist?
Vabastamisteatise teavitamise meetodi osas, pole probleemi, millist meetodit kasutada, kui teade jõuab lõpptulemusena kohale (veelgi enam, kui saab tõestada, et see jõudis kindlalt kohale).
Seega, pole vaja olla liiga närviline protseduuriliste küsimuste pärast. Tõepoolest, praktikas on kalduvus eelistada meetodeid nagu sertifitseeritud post, et vältida hilisemaid “ütlesin-ei öelnud” probleeme. Kuid kui saab kinnitada, et see jõudis vastuvõtjani, pole probleemi ka lihtsamate meetodite, nagu faks või e-kiri, kasutamisel. Kuid lõppkokkuvõttes, kui asi jõuab kohtusse, on vaja tõestada, et “see jõudis vastuvõtjani”, ja selles mõttes võib öelda, et sertifitseeritud post on turvaline.
Kokkuvõte
Selles artiklis oleme süsteemiarenduse kontekstis käsitletud lepingu tühistamise küsimust. Praktiline teadmine, kuidas tühistamist läbi viia, on muidugi oluline, kuid samuti on oluline mõista, kuidas teha seaduslikult kehtivaid tahteavaldusi. Usun, et see teadmine on kergesti rakendatav erinevates olukordades.
Category: IT
Tag: ITSystem Development