Millal kohaldatakse süsteemiarenduse üleandmise ja eeldatava üleandmise klausleid?

Süsteemiarenduse valdkonnas on õiguslikke probleeme kõige lihtsam tekitada “vastuvõtmise” etapis.

“Vastuvõtmine” viitab tellija kohustusele kontrollida ja üle vaadata toodet, mille tarnija on tarninud. Kui tellija ei teosta “vastuvõtmist” pärast tarnimist, siis tarnija ehk müüja jääb õiguslikult ebastabiilsesse olukorda.

Selliste probleemide lahendamiseks on lepingutes sageli sisse kirjutatud “vaikimisi vastuvõtmise” klauslid.

Selles artiklis selgitame, millistel juhtudel kohaldatakse “vaikimisi vastuvõtmist”, tuginedes tegelikele kohtuotsustele.

Mis on süsteemiarenduse vastuvõtmine?

Alustuseks, “vastuvõtmine” süsteemiarenduse projektis tähendab, et tellija, kes on kasutaja, kontrollib ja kontrollib tarnijalt, kes on müüja, saadud tulemusi (siin viidatakse IT-süsteemile), kas need vastavad tellitud eesmärkidele jne.

Kui vaadata seda arendaja vaatenurgast, võib seda määratleda ka kui “kontrollimist, kas see on tõesti valmis”, mis on testiprotsessi osa.

IT-süsteemide arendamine on oma olemuselt selline töö, kus müüja, kes on tellija, võib suuresti otsustada, mistõttu võib tekkida erinevusi tegelikult loodud toote ja kasutaja poolt nõutava vahel.

Üldiselt öeldes tähendab vastuvõtmise läbimine, et kasutaja on ise kinnitanud, et tegelikult on tarnitud tulemus, mis vastab sellele, mida kasutaja soovis (või mille arendamist ta palus).

Tegeliku lepingu sõlmimise viisina on palju juhtumeid, kus hoolimata asjaolust, et süsteemis võib ilmneda defekte, on vastuvõtmise läbimine seotud tasu maksmise tingimusega.

Pöörake tähelepanu nn aktsepteerimisklauslile

Kui aktsepteerimise faasis tekib probleeme, satuvad nii kasutajad kui ka müüjad keerulisse olukorda.

Näiteks, mis juhtub, kui müüja on loonud tulemuse ja on selle juba esitanud, kuid kasutaja esindaja ei nõustu aktsepteerimisega oma asjaolude tõttu?

Selliseid olukordi silmas pidades on süsteemiarenduse lepingutes sageli kaasatud nn “aktsepteerimisklausel”.

Mis on deemeeritud aktsepteerimise klausel?

(Antud tarkvara aktsepteerimine) Artikkel 28
Kõigi tarnitavate toodete hulgas peab tellija kontrollima antud tarkvara vastavust süsteemi spetsifikatsioonidele ja kontrollima, kas see vastab eelmises artiklis määratletud kontrollspetsifikatsioonidele individuaalses lepingus määratletud perioodi jooksul (edaspidi “kontrolliperiood”).

2. Kui antud tarkvara vastab eelmises lõigus määratletud kontrollile, peab tellija allkirjastama ja pitseerima aktsepteerimisdokumendi ning andma selle tarnijale. Kui antud tarkvara ei vasta eelmises lõigus määratletud kontrollile, peab tellija tarnijale kiiresti esitama kirjaliku põhjenduse, miks see ei vastanud, ning nõudma parandusi või täiendusi. Kui põhjendus on aktsepteeritud, peab tarnija parandama tarkvara tasuta määratud ajaperioodi jooksul ja tellija peab vajadusel uuesti läbi viima eelmises lõigus määratletud kontrolli.

3. Kui aktsepteerimisdokumenti ei anta, kuid tellija ei esita kontrolliperioodi jooksul kirjalikult konkreetset põhjendust, loetakse antud tarkvara selle artikli kohaselt kontrolli läbinuks.

4. Antud artikli kohaselt aktsepteeritud kontrolli tulemusena loetakse antud tarkvara aktsepteerimine lõppenuks.

https://www.meti.go.jp/policy/it_policy/keiyaku/model_keiyakusyo.pdf [ja]

Seaduslikult on märkimisväärne punkt kolmandas lõigus kasutatud väljend “loetakse”. Kui vaadata seda seadusliku terminina, on “loetakse” ja “eeldatav” tegelikult täiesti erineva tähendusega.

Loetakse…
→Isegi kui tegelikkuses ei ole see nii, käsitletakse seda seaduslikult samamoodi nagu see oleks.

(Näide) Kui kasutate testi ajal nutitelefoni, “loetakse” see spikerdamiseks.
→Sõltumata sellest, kas nutitelefoni kasutamine oli tegelikult spikerdamine või mitte, rakendatakse samu meetmeid nagu spikerdamise korral.

Eeldatav…
→Kui pole erilisi tõendeid, mis eitaksid asjaolu, käsitletakse seda asjaolu tõena.

(Näide) Kui vaatate testi ajal nutitelefoni, “eeldatav” see spikerdamiseks.
→Põhimõtteliselt eeldatakse, et spikerdamine toimus, kuid kui saab tõestada, et see oli mõne muu eesmärgi jaoks, võib seda otsust hiljem muuta. (Kuigi tavaliselt ei kuule sellist teadet testikeskuses.)

Seega, “eeldatav” ja “loetakse” erinevad oluliselt selle poolest, kui suur on nende ümberlükkamise takistus. Siin on mõeldud, et “sõltumata sellest, kas see on läbinud aktsepteerimise või mitte, koheldakse seda samamoodi nagu see oleks läbinud aktsepteerimise”.

Kohtupraktika seoses deeming-klausli sätetega

On olnud juhtumeid, kus deeming-vastuvõtu klausli sätted on kohtus otsustava tähendusega. Näiteks allpool tsiteeritud kohtuotsuses esitas kasutaja kaebuse, et teatud perioodi jooksul ei vastanud ta vastuvõtule ja hiljem väitis, et vajalikke funktsioone ei olnud rakendatud. Kuid kohus otsustas, et tuginedes deeming-klausli sätetele, oli tarnimine juba lõpule viidud.

Selles lepingus oli Y ettevõttel kohustus pärast süsteemi tarnimist viivitamatult läbi viia kontroll ja teavitada sellest kirjalikult 10 päeva jooksul, ning kui teatist ei ole nimetatud tähtajaks saadetud, loetakse see vastuvõtuks. Seetõttu ei saa me tunnistada, et on olnud teateid, mis ei vasta kontrollile, ning me saame kinnitada tarnimise ja vastuvõtu asjaolu.

Tokyo District Court judgment, February 29, 2012 (2012)

Teiselt poolt, isegi kui see deeming-vastuvõtu sätte oli paigas, on olemas kohtupraktika, mis eitab selle kohaldamist ja tunnistab tarnija kohustuste rikkumist.

Allpool tsiteeritud kohtuotsuse juhtum erineb eelmainitud kohtupraktikast selles, et vastuvõtu läbiviimiseks oli vaja tarnija koostööd, kuid tarnija ei teinud seda koostööd.

Hageja (tarnija) väidab, et kostja (kasutaja) ei teavitanud 10 päeva jooksul pärast tulemuste tarnimist kontrolli tulemustest, seega loetakse tulemused vastuvõetuks vastavalt tarkvaraarenduslepingu artiklile 9, lõige 4. Kuid selle tulemuse saavutamiseks on vaja hageja koostööd, kuid hageja ei ole kostjale sellist kontrolli teinud, seega ei saa me sel juhul öelda, et kuna kostja ei teavitanud 10 päeva jooksul pärast tulemuste tarnimist kontrolli tulemustest, loetakse tarkvaraarenduslepingu artikli 9, lõike 4 alusel, et kostja on tarkvara vastu võtnud.

Tokyo District Court judgment, June 23, 2004 (2004)

Deeming-vastuvõtu klausli põhimõtteks on vabastada tarnija kiiresti ebastabiilsest olukorrast, kus “töö on seiskunud, sest kasutaja ei saa ühepoolsete asjaolude tõttu vastuvõtuga edasi minna”, ja hoida mõlema osapoole suhteid õiglasena.

Seega, kui see kõrvale kaldub sellest põhimõttest, ei saa me rääkida sellest, et “kasutame deeming-vastuvõtu klauslit kilbina, et aega võita ja vastuvõttu edasi lükata, ja surume selle lihtsalt vigase toote või mis tahes muu peale”.

Kui vastuvõtt “peetakse” heakskiidetuks, peab kasutaja maksma süsteemiarenduse eest tasu. Arvestades ka seda olulist aspekti, on kohtu eesmärk kaasata tarnija koostöö olukord ja teha õiglane otsus.

Toetuseks sellisele otsusele võib süsteemiarenduse edenemisega seotud protokollid olla olulised tõendid, mitte ainult lepingud. Selle kohta on üksikasjalikumalt kirjutatud allpool toodud artiklis.

https://monolith.law/corporate/the-minutes-in-system-development[ja]

Muide, milliseid kohustusi peaks tarnija kui süsteemiarenduse spetsialist kandma projekti suhtes tervikuna, vaadake allpool toodud artiklit.

Kuigi vastuvõtu peaks põhimõtteliselt läbi viima kasutaja, peaks tarnija kui süsteemiarenduse spetsialist tegema vastuvõtuks erinevaid koostöövorme. See punkt on arusaadav, kui võtta arvesse allpool toodud artikli sisu.

https://monolith.law/corporate/project-management-duties[ja]

Vead, mis leitakse ülevaatuse käigus

Muidugi, on võimalik, et süsteemi ülevaatuse etapis ilmnevad puudused (õiguslikult kasutatakse sageli sõna “defekt”). Sel juhul on seaduslikud probleemid, palun vaadake allpool toodud artiklit üksikasjade kohta.

https://monolith.law/corporate/defect-warranty-liability[ja]

Kokkuvõte

Süsteemiarenduses on “vastuvõtmine” põhimõtteliselt näitaja, et tarnija poolne kohustus on täielikult täidetud, seega võib öelda, et see on oluline nii kasutaja kui ka tarnija jaoks. Selleks, et siin tõsiseid probleeme ei tekiks, peaksid nii tellija kui ka töövõtja “vaikimisi vastuvõtmise klausli” suhtes olema hästi informeeritud.

Ja kui vastuvõtmine ei suju, peaksid mõlemad pooled juba lepingu sõlmimise etapis eriti hoolikalt läbi arutama vastuvõtmisega seotud sätteid, et vältida mis tahes probleeme.