Milyen módszerekkel lehet felbontani a szerződést a rendszerfejlesztés során?

A rendszerfejlesztési projektek hosszú távú projektek, ezért természetesen előfordulhat, hogy a projekt folyamatában “kigyulladnak”. És bár ideális esetben a felhasználók és a szolgáltatók összehangoltan haladnak előre, fontos, hogy felkészüljünk arra is, hogy a szerződést fel kell bontani.

Ebben a cikkben a szerződés “felbontásának” jogi lehetőségét fogjuk megvizsgálni, különös tekintettel a rendszerfejlesztéssel kapcsolatos fontos szempontokra.

A rendszerfejlesztés és a szerződés felbontásának összefüggése

Mit jelent a szerződés felbontása a polgári törvénykönyv szerint?

A módosított Polgári Törvénykönyvben a szerződés ‘felbontásának’ általános rendelkezéseit a 540. és 548. cikkelyek szabályozzák. A szerződés felbontása azt jelenti, hogy a már megkötött szerződés hatását utólag megszüntetjük.

Ha a felhasználó és a szolgáltató közötti viszonylatban beszélünk, általában, ha egyszer a szerződés megkötésre kerül, a szolgáltatóra a rendszer fejlesztésének kötelezettsége hárul, a felhasználóra pedig a díj megfizetésének kötelezettsége. Ezek pedig mindkét fél ‘jogait’ is jelentik. Ha ez felbontásra kerül, a felek által vállalt kötelezettségek és jogok visszaállnak a szerződéskötés előtti állapotra. Tehát, ha még vannak teljesítetlen kötelezettségek, nem csak a teljesítési kötelezettség szűnik meg, hanem a szerződéskötés előtti állapot alapján kötelezettség keletkezik a kölcsönös visszaállításra. Ezt nevezzük ‘eredeti állapot helyreállításának kötelezettségének’.

Megjegyzendő, hogy ha ugyanakkor károk keletkeznek, külön kártérítés is lehetséges.

A rendszerfejlesztés gyakorlatának és a szerződés felbontásának összefüggése

A rendszerfejlesztés és más üzleti tevékenységek jogi gyakorlatában jártas személyek számára a szerződés ‘felbontása’ elsősorban a felbontási értesítést jelenti. Azonban jogilag, még a rendszerfejlesztés kontextusában is, a felbontás alapját képező cikkelyek két nagy csoportra oszthatók az okok szerint.

Ha a kötelezettség nem teljesítése (késedelem) az ok

(Példa) Ha a szolgáltató nem teljesíti a szállítást, annak ellenére, hogy meghaladta az eredetileg megígért határidőt

Polgári Törvénykönyv 541. cikkely: Ha az egyik fél nem teljesíti a kötelezettségét, a másik fél meghatározhat egy megfelelő időtartamot a teljesítés felszólítására, és ha a teljesítés nem történik meg ezen idő alatt, a másik fél felbonthatja a szerződést.

A rendszerfejlesztési szerződésben a ‘fél’ szerepét betöltő szolgáltató ‘kötelezettsége’ a követelményeknek megfelelő rendszer elkészítése és szállítása. Tehát, ha a szolgáltató nem teljesíti a szállítást a határidő lejárta ellenére, más szóval, ha a szolgáltató nem fejezi be a munkát a határidőre. De mit jelent a ‘munka befejezése’ a rendszerfejlesztés szempontjából? Ezt a kérdést részletesen tárgyaljuk az alábbi cikkben.

https://monolith.law/corporate/completion-of-work-in-system-development[ja]

Ha a hibás teljesítés a felbontás oka

(Példa) Ha a szolgáltató által szállított rendszerben sok a hiba vagy az adatok nem konzisztensek, és később kiderül, hogy nem alkalmas a gyakorlati használatra

Polgári Törvénykönyv 635. cikkely: Ha a munka tárgyában hiba van, és emiatt a szerződés célja nem érhető el, a megrendelő felbonthatja a szerződést. Azonban ez nem vonatkozik az épületekre és más földrajzi alkotásokra.

Megjegyzendő, hogy a rendszerfejlesztési projektek szempontjából a szolgáltató részéről a szerződés felbontásának szándékát ritkán fejezik ki. Általában a felhasználó fejezi ki a szolgáltató felé a szerződés felbontásának szándékát.

A hibás teljesítésről részletesen olvashat az alábbi cikkben.

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

Felmondólevél és a hozzá kapcsolódó jogi kérdések

A felmondólevél olyan dokumentum, amelyet (általában a felhasználótól a szolgáltató felé) a szerződés felmondásának szándékával küldenek. A következő törvénycikket érdemes hivatkozni:

Polgári Törvénykönyv (japán: 民法) 541. §: Ha az egyik fél nem teljesíti kötelezettségét, a másik fél meghatározhat egy megfelelő határidőt a teljesítésre, és ha a teljesítés nem történik meg ezen időszak alatt, a másik fél felmondhatja a szerződést.

Ha a rendszerfejlesztéshez kapcsolódó dokumentumokat nézzük, a felmondólevél jellemzője, hogy nem a projekt zökkenőmentes lebonyolítását szolgálja, hanem a projekt befejezését. Ezenkívül fontos jellemzője, hogy közvetlenül bizonyos jogi hatásokat várnak tőle.

Az előző törvénycikk szerint azonban a szerződéstől eltérően, ha bizonyos feltételek teljesülnek, elegendő az egyik fél szándéknyilatkozata. Ha a felhasználó felmondólevelet nyújt be a szolgáltatónak, a szolgáltató által fogadott személy számára problémát jelenthet, hogy “még a felmondólevél elolvasása után sem értem, miért lett felmondva a szerződés”. Tehát mennyire részletesen kell a felhasználónak megjelölnie a felmondás okát a felmondólevélben?

Szükséges-e a felmondás okát feltüntetni a felmondólevélben?

A kérdésre vonatkozóan a korábbi bírósági ítéletek alapján úgy tűnik, hogy nem feltétlenül szükséges a felmondás okát részletesen megjelölni a felmondólevélben. Az alábbi idézett bírósági ítélet egy olyan esetet tárgyal, ahol a szállított rendszer hibái miatt jogi probléma alakult ki. A felhasználói oldalról nézve, amikor a felmondás szándékát kifejezik, kérdéses, hogy mennyire kell részletesen megérteniük a hiba tartalmát, és mennyire kell azt konkrétan megjelölniük. A bíróság ezt a kérdést a következőképpen határozta meg:

A felmondás szándékának kifejezésekor nem feltétlenül szükséges a felmondás okát megjelölni, és több felmondási okot is lehet egyszerre kifejezni. Ha a felmondás szándékát kifejezve egy okot megjelölünk, kivéve, ha különösen jelezzük, hogy más okok miatt nem mondunk fel, a felmondás szándékának kifejezése minden, a felmondás idején létező okra vonatkozik, és azt jelenti, hogy teljesen befejezzük a szerződést.

Tokyo District Court, December 22, 2004 (Heisei 16)

A bíróság álláspontja szerint “több felmondási okot is lehet egyszerre kifejezni”. Vagyis a lényeg az, hogy a szerződő feleknek van-e felmondási szándékuk, nem pedig az, hogy a felmondás részletes okait részletesen meg kell-e jelölni.

Tehát, még ha a termék szállításra került is, nem szükséges dönteni arról, hogy azt befejezetlenként kell-e kezelni, vagy súlyos hibája miatt a szavatossági felelősség kérdése-e. Ezek a finom kérdések akkor is figyelmen kívül hagyhatók, ha a felmondás szándékát kifejezzük. Ha először kifejezzük a felmondás szándékát, akkor még ha később pereskedésre kerül sor is, utólag vitatható, hogy a teljesítési késedelem vagy a szavatossági felelősség volt-e a felmondás alapja.

• A szállított termék befejezetlen… → Szerződésszegés
• Súlyos hibával rendelkező termék szállítása… → Szavatossági felelősség

Még ha az okot nem is határozzuk meg részletesen, a felmondás szándékának kifejezése érvényes a felmondás szándékának kifejezéseként.

Mindazonáltal, ha a felmondás okát konkrétan megjelöljük, és ezt követően nyújtjuk be a felmondólevelet, akkor előnye, hogy még ha a szállítóval való kommunikációban vagy értelmezésben eltérések is vannak, ezeket tisztázni lehet. Emellett a felmondólevél címzettje számára is, ha van ötlete az okra, a későbbi viták esélye is csökken. Ezért valójában jobb, ha a felmondás okát lehetőleg részletesen megjelöljük.

Mennyi időt jelent a „megfelelő időtartam” a felszólításban?

Egy másik fontos kérdés a Japán Polgári Törvénykönyv (japán: Minpō) 541. cikkében szereplő „megfelelő időtartam” hossza. Azonban ezen nem szükséges túlzottan aggódni. Még ha a felszólítás előtt nem határoztunk meg „megfelelő időtartamot”, ha a felszólítás után megfelelő idő telt el, a szerződést fel lehet mondani. Sőt, még ha a felszólítás előtti időszak nem volt „megfelelő időtartam”, a szerződést fel lehet mondani, ha ezt követően megfelelő idő telt el. Ezt a bírói gyakorlat is egyértelműen megerősíti.

Rendszerfejlesztési projektek esetén, ha egyszer teljesítési késedelem vagy hibás teljesítés miatt probléma merül fel, ritkán fordul elő, hogy a „megfelelő időtartam” meghatározása után a felszólításra a szállítás vagy a hibajavítás befejeződik. Figyelembe véve ezeket a tényeket, a gyakorlatban nem valószínű, hogy komoly viták alakulnának ki a „megfelelő időtartam” körül.

A rendszerfejlesztésben a teljesítési késedelem definícióját egy másik cikkben ismertetjük.

https://monolith.law/corporate/performance-delay-in-system-development[ja]

Milyen módon értesíthető a felmondási értesítő?

A felmondási értesítőt illetően, ha a végén az értesítés eljut a címzetthez (sőt, ha később bizonyítható, hogy biztosan eljutott), akkor bármilyen módszer megfelelő.

Ezért nincs szükség arra, hogy túlságosan aggódjon az eljárási kérdések miatt. Valóban, a gyakorlatban gyakran előnyben részesítik azokat a módszereket, mint például a tartalomigazolásos posta, amelyek elkerülik a későbbi “mondta-nem mondta” vitákat. Azonban, ha megerősíthető, hogy az értesítés eljutott a címzettig, akkor nincs probléma azzal sem, ha egyszerűbb módszereket, mint például a faxot vagy az e-mailt használja. Mindazonáltal, ha végül pereskedésre kerül sor, szükség van arra, hogy bizonyítsa, hogy az értesítés “eljutott a másik félhez”, ebből a szempontból biztonságosabb a tartalomigazolás.

Összefoglalás

Ebben a cikkben a szerződés felbontását rendszereztem a rendszerfejlesztés kontextusában. A felbontás gyakorlati tudása természetesen fontos, de ha megértjük a jogilag érvényes szándéknyilatkozatok elvégzésének módját is, akkor ez könnyen alkalmazható tudás lehet.