Co je přijetí vývoje systému a kdy se uplatňuje klauzule o předpokládaném přijetí

Fází, kde se v oblasti vývoje systémů často vyskytují právní problémy, je fáze “předání a převzetí”.

“Předání a převzetí” odkazuje na povinnost objednatele provést inspekci a kontrolu, když dodavatel dodá výsledný produkt. Pokud objednatel po dodání neprovede “předání a převzetí”, dodavatel, neboli vendor, se ocitá v právně nestabilní pozici.

Aby se tyto problémy vyřešily, smlouvy často obsahují klauzuli o “předpokládaném předání a převzetí”.

V tomto článku vysvětlíme, kdy se uplatňuje “předpokládané předání a převzetí”, na základě skutečných soudních případů.

Co je přejímka v systémovém vývoji?

Nejprve, “přejímka” v projektu systémového vývoje znamená, že uživatel, který je objednatelem, kontroluje a prověřuje, zda výsledný produkt (v tomto případě IT systém), který dodal dodavatel, odpovídá specifikacím a účelu, pro který byl objednán.

Z pohledu vývojáře by to mohlo být chápáno jako “ověření, zda je skutečně dokončeno”, a může být považováno za součást testovacího procesu.

Práce na vývoji IT systému má povahu, která často umožňuje velkou míru uvážení na straně dodavatele. Proto může dojít k rozdílům mezi skutečným výrobkem a tím, co uživatel požadoval.

Obecně řečeno, úspěšná přejímka znamená, že uživatel sám ověřil, že byl skutečně dodán výsledek, který odpovídá tomu, co uživatel požadoval (nebo účelu, pro který byl požadován vývoj systému).

Co se týče skutečného způsobu uzavírání smluv, i když je možné předpokládat případy, kdy se později ukáže, že systém má vady, často se setkáváme s tím, že úspěšná přejímka je stanovena jako podmínka pro platbu odměny.

Pozor na klauzuli o předpokládaném převzetí

Pokud dojde k problémům v fázi převzetí, uživatel i dodavatel se ocitnou v nepříjemné situaci.

Například, co se stane, když dodavatel vytvoří výsledný produkt a již ho představil, ale z důvodu situace na straně uživatele, uživatel odmítá převzetí?

Pro takové případy je často do smlouvy o vývoji systému začleněna klauzule, která se nazývá “klauzule o předpokládaném převzetí”.

Co je to doložka o předpokládaném přijetí?

(Přijetí daného softwaru) Článek 28
Strana A musí provést kontrolu daného softwaru, který je součástí dodávky, během doby stanovené v individuální smlouvě (dále jen “kontrolní doba”) podle specifikace kontroly uvedené v předchozím článku a musí zkontrolovat, zda systémová specifikace a daný software odpovídají.

2. Pokud daný software splňuje kontrolu uvedenou v předchozím odstavci, Strana A musí podepsat a odevzdat certifikát o úspěšné kontrole Straně B. Pokud daný software nesplňuje kontrolu uvedenou v předchozím odstavci, Strana A musí rychle odevzdat Straně B dokument, který jasně uvádí konkrétní důvody nesplnění, a požadovat opravu nebo doplnění. Pokud jsou důvody nesplnění uznány, Strana B musí opravit bezplatně a dodat Straně A během doby stanovené po konzultaci, a Strana A musí provést kontrolu uvedenou v předchozím odstavci znovu v potřebném rozsahu.

3. Pokud certifikát o úspěšné kontrole není odevzdán, ale Strana A nevyjádří námitky s jasnými konkrétními důvody písemně během kontrolní doby, daný software se považuje za splnění kontroly stanovené v tomto článku.

4. Přijetí daného softwaru je dokončeno s úspěšnou kontrolou stanovenou v tomto článku.

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

Je třeba poznamenat, že z právního hlediska je výraz “považováno” v odstavci 3 bodem, na který bychom měli upozornit. Pokud se na to podíváme z hlediska právní terminologie, “považovat” a “předpokládat” mají ve skutečnosti zcela odlišné významy.

Považovat…
→ I když ve skutečnosti není XX, je právně považováno za stejné jako v případě XX

(Příklad) Pokud během testu ovládáte smartphone, je to považováno za podvádění
→ Bez ohledu na to, zda bylo ovládání smartphonu během testu skutečně podvádění, jsou přijata stejná opatření jako v případě podvádění.

Předpokládat…
→ Pokud neexistují žádné důkazy popírající skutečnost XX, je XX považováno za skutečnost.

(Příklad) Pokud během testu sledujete smartphone, je to považováno za podvádění
→ Zásadně se předpokládá, že došlo k podvádění, ale pokud můžete prokázat, že to bylo pro jiný účel než podvádění, může být toto rozhodnutí později zvráceno. (Nicméně, takové oznámení byste obvykle na místě testu neslyšeli.)

Jinými slovy, mezi “předpokládat” a “považovat” je obrovský rozdíl v obtížnosti zvrácení. Zde je zahrnuto pojetí “bez ohledu na skutečnost, zda bylo přijetí úspěšné, je to považováno za stejné jako v případě úspěšného přijetí”.

Soudní případy související s ustanovením o předpokládaném přijetí

Existují případy, kdy ustanovení o předpokládaném přijetí mělo rozhodující význam v soudním řízení. Například následující citovaný rozsudek se týká případu, kdy uživatel neprovedl přijetí v předepsané lhůtě a později podal žalobu s tvrzením, že potřebné funkce nebyly implementovány. Soud však na základě ustanovení o předpokládaném přijetí rozhodl, že dodání již bylo dokončeno.

V tomto konkrétním smluvním vztahu bylo stanoveno, že společnost Y musí po dodání systému provést kontrolu bez zbytečného odkladu a do 10 dnů oznámit přijetí písemnou formou. Pokud takové oznámení není provedeno do uvedeného termínu, považuje se za přijetí. Protože v tomto případě nelze připustit, že bylo oznámeno o nesrovnalostech v kontrole, je možné potvrdit skutečnost dodání a přijetí.

Rozsudek tokijského okresního soudu ze dne 29. února 2012 (Heisei 24)

Na druhou stranu, i když bylo stanoveno toto ustanovení o předpokládaném přijetí, existují soudní případy, které jeho uplatnění odmítly a uznaly porušení povinností ze strany dodavatele.

Následující citovaný rozsudek se týká případu, který se liší od předchozího soudního případu v tom, že dodavatel neposkytl potřebnou spolupráci pro provedení přijetí.

Žalobce (dodavatel) tvrdí, že žalovaný (uživatel) neprovedl oznámení o výsledcích kontroly do 10 dnů od dodání výsledku, a proto se podle článku 9 odst. 4 smlouvy o vývoji softwaru považuje výsledek za přijatý. Avšak, aby mohlo dojít k takovému výsledku, je nezbytná spolupráce žalobce, kterou však žalobce neposkytl žalovanému. Proto v tomto případě, i když žalovaný neprovedl oznámení o výsledcích kontroly do 10 dnů od dodání výsledku, podle článku 9 odst. 4 smlouvy o vývoji softwaru se nepovažuje za to, že žalovaný přijal software.

Rozsudek tokijského okresního soudu ze dne 23. června 2004 (Heisei 16)

Je možné se domnívat, že účelem systému předpokládaného přijetí je uvolnit dodavatele z nestabilní pozice, kdy “i když chce rychle pokročit k přijetí, nemůže to udělat kvůli jednostranným okolnostem uživatele a práce se zdržuje”, a udržet vztahy mezi oběma stranami spravedlivé.

Proto není možné, aby se situace vyvinula tak, že “použijeme ustanovení o předpokládaném přijetí jako štít, abychom nějak získali čas a odkládali přijetí jako takové a nakonec nám to všechno nějak nandali, i když je to vadné zboží”, což by bylo značně odchýlené od tohoto účelu.

Pokud je přijetí “považováno” za schválené, uživatel musí zaplatit odměnu za vývoj systému. Soud se snaží rozhodovat spravedlivě, zohledňuje i tuto závažnost a zahrnuje také situaci spolupráce ze strany dodavatele.

Jako podpora pro takové rozhodnutí mohou být důležitými důkazy nejen smlouvy, ale také zápisy z jednání související s pokrokem vývoje systému. Podrobnosti o tom jsou vysvětleny v následujícím článku.

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

Pro informace o tom, jaké komplexní povinnosti má dodavatel jako odborník na vývoj systémů vůči projektu, se podívejte na následující článek.

I když by měl uživatel provést přijetí jako základní princip, dodavatel by měl jako odborník na vývoj systémů poskytnout různé formy spolupráce pro přijetí. Tento bod bude zřejmý, pokud vezmeme v úvahu obsah následujícího článku.

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

Vzorce, kdy se při přejímce objeví vady

Samozřejmě, může se stát, že se v průběhu přejímací fáze objeví nedostatky systému (v právní terminologii se často používá slovo “vada”). Pro právní problémy v tomto případě se podrobněji podívejte na následující článek.

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

Shrnutí

V systémovém vývoji je “předání a převzetí” zásadně ukazatelem úplného splnění povinností dodavatele, a proto je velmi důležité jak pro uživatele, tak pro dodavatele. Aby se zde nevyskytly vážné problémy, je důležité, aby obě strany, objednatel i dodavatel, dobře rozuměly “klauzuli o předpokládaném předání a převzetí”.

Pokud se předpokládá, že předání a převzetí nebude probíhat hladce, je důležité, aby obě strany pečlivě sladily své pochopení ustanovení týkajících se předání a převzetí, zejména již v předchozí fázi smlouvy.