A rendszerszoftver fejlesztésének átvétele és a feltételezett átvételi záradék alkalmazásának helyzetei

A rendszerfejlesztés során gyakran merülnek fel jogi problémák az “átvétel” szakaszban.

Az “átvétel” azt a kötelezettséget jelenti, amely a megrendelőt terheli, amikor a szerződő fél átadja a munka eredményét. Ha például a megrendelő nem végez “átvételt” a termék átadása után, akkor a szerződő fél, a szállító jogilag bizonytalan helyzetbe kerül.

Ezért a szerződések gyakran tartalmaznak “automatikus átvétel” záradékot a probléma megoldása érdekében.

Ebben a cikkben megvizsgáljuk, milyen esetekben alkalmazható az “automatikus átvétel”, és ezt valós példákon keresztül magyarázzuk el.

Mi az átvételi eljárás a rendszerfejlesztésben?

Az átvételi eljárás a rendszerfejlesztési projektekben alapvetően azt jelenti, hogy a megrendelő, azaz a felhasználó, ellenőrzi és vizsgálja a szállító által szállított eredményeket (itt az IT rendszerekre utalunk), hogy megfelelnek-e a megrendelt célkitűzéseknek.

Ha a fejlesztő szemszögéből nézzük, ez azt jelenti, hogy “valóban befejeződött-e”, ami a tesztelési folyamat részének is tekinthető.

Az IT rendszerek fejlesztése olyan munka, amelynek természeténél fogva a szállítóként működő szállítók mérlegelési joga is nagy lehet, ezért előfordulhat, hogy a ténylegesen előállított termék és a felhasználó által kért termék között eltérés van.

Általánosságban elmondható, hogy az átvételi eljárás sikeres, ha a felhasználó által kért (vagy a rendszer fejlesztésére irányuló kérés) eredményeket ténylegesen szállítják, és ezt a felhasználó maga is megerősíti.

A valós szerződéskötési gyakorlatban is, bár elképzelhető, hogy a rendszerben hibák merülnek fel a későbbiekben, sok esetben az átvételi eljárás sikeres lebonyolítását fizetési feltételként szabják meg.

Figyeljen a “feltételezett átvételi” záradékra

Ha a projekt átvételi szakaszában probléma merül fel, mind a felhasználó, mind a szolgáltató nehéz helyzetbe kerül.

Tegyük fel, hogy a szolgáltató elkészítette a terméket, és már bemutatta azt, de a felhasználói oldal képviselője valamilyen okból nem hajlandó átvenni azt. Mi történik ilyen esetben?

Ilyen helyzetekre való tekintettel a rendszerfejlesztési szerződésekben gyakran szerepel egy “feltételezett átvételi” záradék.

Mi az a feltételezett átvételi záradék?

(A szoftver átvétele) 28. cikk
A szállított termékek közül a szoftverrel kapcsolatban az A félnek az egyedi szerződésben meghatározott időszakon (a továbbiakban “ellenőrzési időszak”) belül az előző cikkben meghatározott ellenőrzési specifikációk alapján kell ellenőriznie, hogy a rendszerspecifikáció és a szoftver összhangban van-e.

2. Ha a szoftver megfelel az előző bekezdésben meghatározott ellenőrzésnek, az A félnek alá kell írnia és lepecsételnie az ellenőrzési minősítést, és át kell adnia azt a B félnek. Ha a szoftver nem felel meg az előző bekezdésben meghatározott ellenőrzésnek, az A félnek azonnal írásban kell közölnie a B féllel a nem megfelelőség konkrét okait, és kérnie kell a javítást vagy kiegészítést. Ha a nem megfelelőség okát elfogadják, a B félnek a megbeszélés alapján meghatározott határidőn belül ingyenesen kell javítania és átadnia azt az A félnek, és az A félnek szükség esetén újra el kell végeznie az előző bekezdésben meghatározott ellenőrzést.

3. Ha az ellenőrzési minősítést nem adják át, de az A fél az ellenőrzési időszak alatt nem emel írásban konkrét okot megjelölve kifogást, a szoftvert úgy tekintjük, hogy megfelelt a jelen cikkben meghatározott ellenőrzésnek.

4. A jelen cikkben meghatározott ellenőrzési minősítést a szoftver átvételének befejezésének tekintjük.

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

Jogi szempontból a 3. bekezdés “feltételezett” kifejezése az, amire különösen figyelni kell. Jogi terminusként nézve a “feltételezett” és a “feltételezett” kifejezések teljesen eltérő jelentéssel bírnak.

Feltételezett…
→Még ha valójában nem is ○○, jogilag úgy kezelik, mintha ○○ lenne

(Példa) Ha a vizsga alatt mobiltelefont használt, azt “feltételezett” csalásnak tekintik
→Függetlenül attól, hogy a mobiltelefon használata valóban csalás volt-e vagy sem, ugyanazokat az intézkedéseket hozzák, mintha csalás történt volna.

Feltételezett…
→Ha nincsenek különösebb bizonyítékok, amelyek cáfolnák a ○○ tényét, akkor a ○○-t tényként kezelik.

(Példa) Ha a vizsga alatt a mobiltelefont nézte, azt “feltételezett” csalásnak tekintik
→Alapvetően úgy ítélik meg, hogy csalás történt, de ha bizonyítható, hogy a mobiltelefont csaláson kívüli célra használták, akkor ez az ítélet később megdönthető. (Bár valószínűleg nem hallana ilyen bejelentést a vizsgahelyszínen.)

Tehát a “feltételezett” és a “feltételezett” között hatalmas a különbség a megdöntésük nehézségében. Itt a “mintha át lett volna véve, függetlenül attól, hogy valójában át lett-e véve” jelentés van.

Ítélkezési példák a feltételezett záradékokkal kapcsolatban

A feltételezett átvételi záradékoknak már a múltban is döntő szerepük volt a bírósági ítéletekben. Például az alábbi idézett ítéletben a felhasználó nem vette át a terméket a megadott időszakban, majd később panaszt emelt, hogy a szükséges funkciók nincsenek implementálva. Azonban a bíróság a feltételezett záradékra hivatkozva úgy ítélt, hogy a termék már átadásra került.

A jelen szerződésben az Y cégnek a rendszer átadása után haladéktalanul ellenőriznie kell, és 10 napon belül írásban értesítenie kell az átvételről. Ha ezen időszak alatt nem érkezik értesítés, akkor azt úgy tekintjük, hogy az átvétel megtörtént, és mivel nem kaptunk értesítést az ellenőrzés során feltárt hibákról, megállapíthatjuk, hogy az átadás és az átvétel megtörtént.

Tokyo District Court, 2012. február 29. (Heisei 24)

Másrészről, még ha a feltételezett átvételi záradék is érvényben volt, vannak olyan ítéletek, amelyek elutasították annak alkalmazását, és elismerték a szállító kötelezettségszegését.

Az alábbi idézett ítéletben a szállító együttműködése volt szükséges az átvételhez, de a szállító nem tett eleget ennek, ami eltér az előzőleg említett ítélettől.

A felperes (szállító) azt állítja, hogy a vádlott (felhasználó) nem értesített az ellenőrzés eredményéről a termék átadásától számított 10 napon belül, ezért a 9. cikk 4. bekezdése alapján a terméket átadottnak tekintjük. Azonban, hogy ez megtörténjen, a felperes együttműködése elengedhetetlen, és a felperes nem nyújtott ilyen segítséget a vádlottnak az ellenőrzéshez, ezért ebben az esetben, csak azért, mert a vádlott nem értesített az ellenőrzés eredményéről a termék átadásától számított 10 napon belül, a 9. cikk 4. bekezdése alapján nem tekintjük úgy, hogy a vádlott átvette a terméket.

Tokyo District Court, 2004. június 23. (Heisei 16)

A feltételezett átvételi záradék rendszerének célja, hogy a szállítót gyorsan felszabadítsa az olyan instabil helyzetből, ahol a felhasználó egyoldalú körülményei miatt nem tud továbblépni az átvételhez, és így a munka elakad, és fenntartja a felek közötti tisztességes viszonyt.

Ezért nem lehet arról beszélni, hogy a feltételezett átvételi záradékot védőpajzsként használva, próbáljunk időt nyerni, és húzzuk az átvételt, majd nyomjuk rá a hibás terméket a felhasználóra.

Ha a terméket “átadottnak tekintik”, a felhasználónak a rendszerfejlesztés ellenértékéül díjat kell fizetnie. Figyelembe véve ezt a súlyos tényt, a bíróság célja, hogy a szállító együttműködési helyzetét is figyelembe véve igazságos ítéletet hozzon.

Az ilyen döntések támogatására a szerződés mellett a rendszerfejlesztés előrehaladtával készült jegyzőkönyvek is fontos bizonyítékok lehetnek. Erről részletesen olvashat az alábbi cikkben.

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

A szállító szerepéről, mint a rendszerfejlesztés szakértőjéről, és arról, hogy milyen átfogó kötelezettségeket vállal a projekttel kapcsolatban, olvashat az alábbi cikkben.

Még ha az átvételi feladatokat alapvetően a felhasználónak kell is elvégeznie, a szállítónak, mint a rendszerfejlesztés szakértőjének, számos együttműködést kell nyújtania az átvételhez. Ez a következő cikk tartalmát figyelembe véve természetesnek tűnik.

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

Hibák felfedezése az átvételi eljárás során

Természetesen előfordulhat, hogy az átvételi eljárás során kiderül, hogy a rendszerben hiányosságok vannak (jogi szempontból gyakran ‘hibának’ nevezik ezeket). Ebben az esetben a jogi kérdésekkel kapcsolatban az alábbi cikkben találhatók részletes információk.

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

Összefoglalás

A rendszerfejlesztés során az “átvétel” alapvetően a szolgáltató oldalának kötelezettségvállalásának teljesítését jelenti, ezért mind a felhasználó, mind a szolgáltató számára rendkívül fontos. Mind a megrendelő, mind a szolgáltató számára fontos, hogy a “feltételezett átvételi záradékot” jól megértsék, hogy elkerüljék a komoly problémákat.

És ha esetleg az átvétel nem halad zökkenőmentesen, fontos, hogy mindkét fél már a szerződéskötés előtti szakaszban alaposan egyeztessen az átvétellel kapcsolatos rendelkezésekről, különösen fontos ez a tudatosság összehangolása.