Hvad er scenarierne for anvendelse af 'Systemudviklingsaccept' og 'Formodet acceptklausuler'?

Et område, hvor juridiske problemer ofte opstår i forbindelse med systemudvikling, er ‘afleveringsfasen’.

‘Aflevering’ refererer til inspektions- og kontrolforpligtelsen, der opstår på kundens side, når leverandøren har leveret produktet. Hvis kunden ikke foretager ‘aflevering’ uanset hvor lang tid der er gået efter levering, vil leverandøren juridisk set befinde sig i en usikker position.

For at løse sådanne problemer er der ofte en klausul om ‘formodet aflevering’ inkluderet i kontrakten.

I denne artikel vil vi forklare, under hvilke omstændigheder ‘formodet aflevering’ anvendes, baseret på faktiske retssager.

Hvad er accepttest i systemudvikling?

Først og fremmest er ‘accepttest’ i et systemudviklingsprojekt, hvor brugeren, der er bestilleren, inspicerer og kontrollerer det produkt (her henviser vi til IT-systemet), som leverandøren, der er ordremodtageren, har leveret, for at se om det opfylder de specifikationer, der er fastsat for det formål, det blev bestilt til.

Set fra udviklerens synspunkt kan det også betragtes som en testproces, der tjekker, om det virkelig er færdigt.

Arbejdet med at udvikle et IT-system har en tendens til at give leverandøren en stor grad af skøn på grund af dets forretningsmæssige karakter, og det er muligt, at der kan opstå en forskel mellem det produkt, der faktisk er blevet produceret, og det, som brugeren har anmodet om.

Generelt set betyder det at bestå accepttesten, at brugeren selv har bekræftet, at det produkt, der faktisk er blevet leveret, stemmer overens med det, som brugeren har anmodet om (eller det formål, for hvilket systemudviklingen blev anmodet om).

I praksis er mange kontrakter struktureret sådan, at betalingen er betinget af, at accepttesten er bestået, selvom det er muligt at forudse, at der kan opstå fejl i systemet efterfølgende.

Vær opmærksom på klausulen om betragtet accept

Når der opstår problemer i acceptfasen, kan det sætte både brugeren og leverandøren i en vanskelig situation.

For eksempel, hvad sker der, hvis leverandøren har produceret resultatet, og allerede har præsenteret det, men brugerens repræsentant, af en eller anden grund, ikke vil acceptere det?

For at imødekomme sådanne situationer, er der ofte en klausul i systemudviklingskontrakten, der kaldes “betragtet accept”.

Hvad er en betragtet acceptklausul?

(Accept af den pågældende software) Artikel 28
For den pågældende software blandt de leverede varer, skal A inspicere den i overensstemmelse med inspektionsspecifikationerne i den foregående artikel inden for den periode, der er fastsat i den individuelle kontrakt (herefter kaldet “inspektionsperioden”), og kontrollere, om systemspecifikationerne og den pågældende software stemmer overens.

2. Hvis den pågældende software overholder inspektionen i den foregående paragraf, skal A underskrive og forsegle inspektionscertifikatet og overdrage det til B. Desuden, hvis den pågældende software ikke består inspektionen i den foregående paragraf, skal A hurtigt overdrage et dokument, der klart angiver den specifikke årsag til manglende overensstemmelse, til B og anmode om rettelser eller tilføjelser, og når årsagen til manglende overensstemmelse anerkendes, skal B rette det gratis inden for den aftalte frist efter drøftelser og levere det til A, og A skal udføre inspektionen som angivet i den foregående paragraf igen i det omfang, der er nødvendigt.

3. Selv hvis inspektionscertifikatet ikke overdrages, hvis A ikke fremsætter indsigelser ved at angive en specifik årsag skriftligt inden for inspektionsperioden, betragtes den pågældende software som bestået inspektionen som angivet i denne artikel.

4. Accepten af den pågældende software betragtes som fuldført med inspektionens godkendelse som angivet i denne artikel.

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

Det er værd at bemærke, at udtrykket “betragtes som” i paragraf 3 er et vigtigt punkt juridisk set. Hvis man ser på det som et juridisk udtryk, har “betragtes som” og “antages at være” faktisk helt forskellige betydninger.

Betragtes som…
→Selvom det faktisk ikke er XX, behandles det juridisk set som om det var XX.

(Eksempel) Hvis du bruger en smartphone under en test, betragtes det som snyd.
→Uanset om det, du faktisk gjorde med din smartphone, var snyd eller ej, vil du blive behandlet som om du havde snydt.

Antages at være…
→Medmindre der er særlige beviser, der benægter det, behandles XX som en kendsgerning.

(Eksempel) Hvis du kigger på en smartphone under en test, antages det at være snyd.
→Det antages som standard, at der har været snyd, men hvis du kan bevise, at det var til et andet formål end snyd, kan denne afgørelse blive omstødt senere. (Selvfølgelig vil du normalt ikke høre en sådan meddelelse på et teststed.)

Med andre ord er der en stor forskel mellem “antages at være” og “betragtes som” i forhold til, hvor svært det er at omstøde det. “Uanset om det faktisk er blevet accepteret eller ej, behandles det som om det er blevet accepteret” er den betydning, der er indeholdt her.

Retssager relateret til betragtet acceptklausulen

Der har været tilfælde i fortiden, hvor bestemmelsen om betragtet accept har haft en afgørende betydning i retssager. For eksempel er den følgende domstolsafgørelse fra et tilfælde, hvor brugeren indgav en klage efter acceptperioden, hævdede, at de nødvendige funktioner ikke var implementeret, og sagen gik til retten. Men retten afgjorde, baseret på bestemmelsen om betragtet accept, at leveringen allerede var fuldført.

I denne kontrakt er det fastsat, at Y Company skal inspicere systemet straks efter levering og give skriftlig meddelelse om accept inden for 10 dage, og at hvis der ikke gives meddelelse inden for denne periode, vil det blive betragtet som accepteret, og da det ikke kan anerkendes, at der er givet meddelelse om ikke-overensstemmende punkter i denne inspektion, kan levering og accept anerkendes.

Tokyo District Court, February 29, 2012 (Heisei 24) decision

Men på den anden side er der også retssager, hvor selvom denne betragtede acceptbestemmelse var på plads, blev dens anvendelse nægtet, og leverandørens misligholdelse blev anerkendt.

Den følgende domstolsafgørelse er fra en sag, hvor, i modsætning til den tidligere retssag, leverandøren havde undladt at yde den nødvendige bistand til at udføre accepten, selvom det var nødvendigt.

Plaintiff (leverandør) hævder, at ifølge artikel 9, afsnit 4 i softwareudviklingskontrakten, hvis sagsøgte (bruger) ikke giver meddelelse om inspektionsresultaterne inden for 10 dage efter levering af resultatet, vil resultatet blive betragtet som accepteret. Men for at dette resultat kan opnås, er det nødvendigt med bistand fra sagsøgeren, og det anerkendes, at sagsøgeren ikke har ydet denne bistand til sagsøgte, så selvom sagsøgte ikke har givet meddelelse om inspektionsresultaterne inden for 10 dage efter levering af resultatet, kan det ikke betragtes som, at sagsøgte har accepteret softwaren i henhold til artikel 9, afsnit 4 i softwareudviklingskontrakten.

Tokyo District Court, June 23, 2004 (Heisei 16)

Det antages, at formålet med systemet for betragtet accept er at frigøre leverandøren hurtigt fra en ustabil position, hvor “selvom vi gerne vil gå videre med accepten hurtigt, kan vi ikke gøre det på grund af brugerens ensidige omstændigheder, og arbejdet er forsinket”, og at holde forholdet mellem de to parter fair.

Derfor kan man ikke sige, at “vi vil bruge betragtet acceptklausulen som et skjold, forsøge at købe tid, forsinke accepten selv, og bare skubbe noget, selvom det er en defekt produkt, på brugeren”.

Hvis det “betragtes som” at accepten er bestået, skal brugeren betale for systemudviklingen. Under hensyntagen til denne alvorlighed, sigter retten mod at træffe en fair afgørelse ved at tage højde for leverandørens samarbejdsstatus.

Mødeprotokoller, der følger med fremskridtene i systemudviklingen, kan også være vigtige beviser til støtte for sådanne afgørelser. Dette er detaljeret forklaret i følgende artikel.

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

For mere information om, hvilke omfattende forpligtelser leverandøren har som en ekspert i systemudvikling, se følgende artikel.

Selvom acceptopgaven i princippet skal udføres af brugeren, er det naturligt at forstå, at leverandøren også skal yde forskellige former for bistand til accepten som en ekspert i systemudvikling, når man tager højde for indholdet af følgende artikel.

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

Mønstre hvor mangler opdages ved accepttest

Det er dog muligt, at mangler i systemet (ofte omtalt som “defekter” i juridisk terminologi) kan blive opdaget under accepttestfasen. For juridiske spørgsmål i denne sammenhæng, se venligst nedenstående artikel for mere information.

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

Opsummering

I systemudvikling er “afleveringsforretningen”, som principielt indikerer fuldførelsen af leverandørens forpligtelser, meget vigtig for både brugeren og leverandøren. For at undgå alvorlige problemer her, bør både ordregiver og leverandør have en god forståelse af “betingelserne for betinget aflevering”.

Desuden, i tilfælde af at afleveringsforretningen ikke går glat, er det vigtigt at begge parter nøje afstemmer deres forståelse af bestemmelserne vedrørende afleveringsforretningen, især fra kontraktens indgåelse.