Ce reprezintă acceptarea dezvoltării sistemului și când se aplică clauza de acceptare prezumată?

În cadrul dezvoltării de sisteme, momentul în care problemele legale sunt cel mai probabil să apară este faza de “acceptare”.

“Acceptarea” se referă la obligația de inspecție și verificare care revine comanditarului atunci când prestatorul de servicii livrează produsul final. Dacă, de exemplu, comanditarul nu efectuează “acceptarea” pentru o perioadă nedefinită după livrare, prestatorul de servicii, sau furnizorul, se va afla într-o poziție legală instabilă.

Pentru a rezolva aceste probleme, contractele includ adesea o clauză de “acceptare prezumată”.

În acest articol, vom explica când se aplică “acceptarea prezumată”, bazându-ne pe exemple din cazuri reale.

Ce înseamnă acceptarea în dezvoltarea de sisteme

În primul rând, “acceptarea” în proiectele de dezvoltare a sistemelor se referă la procesul prin care utilizatorul, care este comanditarul, inspectează și verifică dacă produsul livrat de către furnizor, în acest caz un sistem IT, corespunde specificațiilor și scopului pentru care a fost comandat.

Din perspectiva dezvoltatorului, acest proces poate fi considerat ca o etapă de testare pentru a verifica dacă sistemul a fost finalizat într-adevăr.

Deoarece natura muncii de dezvoltare a sistemelor IT permite o mare discreție din partea furnizorului, este posibil să apară discrepanțe între produsul efectiv creat și ceea ce utilizatorul a solicitat.

În termeni generali, acceptarea înseamnă că utilizatorul a verificat personal că produsul care corespunde cu ceea ce a solicitat (sau cu scopul pentru care a cerut dezvoltarea sistemului) a fost efectiv livrat.

În practica contractuală, deși este posibil să se descopere ulterior că sistemul are defecte, este frecvent să se stabilească plata recompensei în funcție de acceptare.

Atenție la clauza de acceptare implicită

Odată ce apar probleme în faza de acceptare, atât utilizatorii cât și furnizorii se pot confrunta cu situații dificile.

De exemplu, ce se întâmplă dacă furnizorul a creat produsul final și l-a prezentat deja, dar persoana responsabilă din partea utilizatorului nu acceptă produsul din motive personale?

Pentru a anticipa astfel de situații, în contractele de dezvoltare a sistemelor este adesea inclusă o clauză numită “clauza de acceptare implicită”.

Ce este clauza de acceptare implicită?

(Acceptarea software-ului în cauză) Articolul 28
În ceea ce privește software-ul în cauză dintre bunurile livrate, partea A trebuie să efectueze o inspecție în perioada stabilită în contractul individual (denumită în continuare “perioada de inspecție”) în conformitate cu specificațiile de inspecție ale articolului anterior și să verifice dacă software-ul în cauză corespunde specificațiilor sistemului.

2. Dacă software-ul în cauză este conform cu inspecția menționată în paragraful anterior, partea A va semna și sigila certificatul de conformitate și îl va înmâna părții B. În plus, dacă software-ul în cauză nu trece de inspecția menționată în paragraful anterior, partea A va înmâna rapid părții B un document care indică motivele concrete pentru care a fost respins și va solicita corecturi sau completări. Când motivele de respingere sunt recunoscute, partea B va corecta și livra software-ul părții A gratuit în termenul stabilit prin consultări, iar partea A va efectua din nou inspecția specificată în paragraful anterior, în măsura necesară.

3. Chiar dacă certificatul de conformitate nu este înmânat, dacă partea A nu obiectează în scris cu motive concrete în perioada de inspecție, software-ul în cauză va fi considerat ca fiind conform cu inspecția specificată în acest articol.

4. Acceptarea software-ului în cauză se finalizează cu conformitatea inspecției specificate în acest articol.

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

De asemenea, din punct de vedere juridic, termenul “considerat” din alineatul 3 este un punct care ar trebui să atragă atenția. Dacă îl privim ca un termen juridic, “considerat” și “presupus” au de fapt semnificații complet diferite.

Considerat…
→ Chiar dacă în realitate nu este așa, este tratat ca și cum ar fi așa din punct de vedere juridic

(Exemplu) Dacă operezi un smartphone în timpul unui examen, este “considerat” ca fiind trișat.
→ Indiferent dacă ceea ce făceai cu smartphone-ul era sau nu trișat, se vor lua măsuri ca și cum ar fi fost trișat.

Presupus…
→ Dacă nu există dovezi care să nege un anumit fapt, acesta este tratat ca un fapt.

(Exemplu) Dacă te uiți la un smartphone în timpul unui examen, este “presupus” că ai trișat.
→ În principiu, se presupune că a avut loc trișarea, dar dacă poți să demonstrezi că smartphone-ul a fost folosit în alt scop, această decizie poate fi răsturnată ulterior. (Cu toate acestea, este puțin probabil să auzi un astfel de anunț într-un centru de examinare.)

Prin urmare, există o diferență semnificativă între “presupus” și “considerat” în ceea ce privește dificultatea de a răsturna aceste presupuneri. Acesta include sensul de “a fi tratat la fel ca și cum ar fi trecut de acceptare, indiferent de faptul dacă a trecut sau nu de acceptare”.

Exemple de cazuri juridice legate de prevederile clauzei de acceptare implicită

Există cazuri în trecut în care prevederile clauzei de acceptare implicită au avut un rol decisiv în instanță. De exemplu, în hotărârea citată mai jos, un utilizator a intentat un proces, susținând că funcțiile necesare nu au fost implementate după o perioadă stabilită, fără a accepta livrarea. Cu toate acestea, instanța a decis că livrarea a fost deja finalizată, pe baza prevederilor clauzei de acceptare implicită.

În cadrul acestui contract, compania Y a fost obligată să inspecteze sistemul imediat după livrare și să notifice în scris acceptarea acestuia în termen de 10 zile. Dacă nu se face nicio notificare până la data limită, se consideră că sistemul a fost acceptat. Prin urmare, nu se poate admite că au existat notificări despre aspecte care nu corespund inspecției, astfel că se poate confirma faptul că livrarea și acceptarea au avut loc.

Hotărârea Tribunalului din Tokyo, 29 februarie 2012 (Heisei 24)

Pe de altă parte, există și cazuri juridice în care, chiar dacă exista această clauză de acceptare implicită, instanța a negat aplicarea acesteia și a recunoscut încălcarea obligațiilor din partea furnizorului.

Cazul menționat în hotărârea citată mai jos diferă de exemplul anterior prin faptul că, deși era necesară cooperarea furnizorului pentru a efectua acceptarea, furnizorul a neglijat această cooperare.

Plângătorul (furnizorul) susține că, deoarece pârâtul (utilizatorul) nu a notificat rezultatele inspecției în termen de 10 zile de la livrarea rezultatelor, conform articolul 9, alineatul 4 al contractului de dezvoltare a software-ului, rezultatele sunt considerate acceptate. Cu toate acestea, pentru ca acest rezultat să fie realizat, cooperarea plângătorului este esențială, iar plângătorul nu a oferit această cooperare pârâtului. Prin urmare, în acest caz, chiar dacă pârâtul nu a notificat rezultatele inspecției în termen de 10 zile de la livrarea rezultatelor, nu se poate considera că pârâtul a acceptat software-ul conform articolul 9, alineatul 4 al contractului de dezvoltare a software-ului.

Hotărârea Tribunalului din Tokyo, 23 iunie 2004 (Heisei 16)

Se poate presupune că scopul sistemului de clauză de acceptare implicită este de a elibera rapid furnizorul dintr-o poziție instabilă, în care, deși dorește să avanseze rapid cu acceptarea, nu poate face acest lucru din cauza circumstanțelor unilaterale ale utilizatorului, și de a menține o relație echitabilă între părți.

Prin urmare, nu este posibil să se abată în mod semnificativ de la acest scop și să folosească clauza de acceptare implicită ca scut pentru a amâna acceptarea în sine și să împingă orice produs defect.

Dacă se consideră că acceptarea a fost aprobată, utilizatorul trebuie să plătească o remunerație pentru dezvoltarea sistemului. Luând în considerare și această gravitate, instanța a încercat să facă o judecată echitabilă, luând în considerare și starea de cooperare a furnizorului.

În sprijinul acestei decizii, procesul-verbal al progresului dezvoltării sistemului poate fi o dovadă importantă, nu doar contractul. Detalii despre acest lucru sunt explicate în articolul de mai jos.

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

De asemenea, pentru a înțelege ce obligații are furnizorul ca expert în dezvoltarea de sisteme în cadrul unui proiect, vă rugăm să consultați articolul de mai jos.

Chiar dacă acceptarea este în principiu responsabilitatea utilizatorului, faptul că furnizorul, ca expert în dezvoltarea de sisteme, ar trebui să ofere diverse forme de cooperare pentru acceptare, va fi înțeles ca o poveste naturală, luând în considerare conținutul articolului de mai jos.

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

Modele în care se găsesc defecte la recepție

Desigur, este posibil ca în etapa de recepție să se descopere deficiențe ale sistemului (în termeni legali, se folosește adesea cuvântul “defect”). În acest caz, pentru problemele legale implicate, vă rugăm să consultați articolul de mai jos.

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

Rezumat

În dezvoltarea de sisteme, “acceptarea” indică în principiu finalizarea îndeplinirii obligațiilor din partea furnizorului, deci se poate spune că este extrem de importantă atât pentru utilizatori, cât și pentru furnizori. Pentru a evita probleme grave aici, atât comandantul, cât și comandatul ar trebui să înțeleagă bine “clauza de acceptare presupusă”.

Și, în cazul improbabil în care acceptarea nu decurge fără probleme, se consideră important ca ambele părți să se alinieze conștient de la etapa contractului inițial, în special în ceea ce privește prevederile legate de acceptare.