MONOLITH LAW OFFICE+81-3-6262-3248Zilele săptămânii 10:00-18:00 JST[English Only]

MONOLITH LAW MAGAZINE

IT

Se poate încheia un contract de dezvoltare a sistemului fără un contract scris?

IT

Se poate încheia un contract de dezvoltare a sistemului fără un contract scris?

În dezvoltarea de sisteme, nu este neobișnuit ca dezvoltatorii să înceapă lucrul înainte de a crea un contract. Cu toate acestea, acest flux de lucru este, în practică, “periculos”. Dacă nu există un contract, există riscul ca, în cazul în care apar probleme ulterior, clientul să spună că “contractul încă nu a fost încheiat, deci nu este necesar să plătim o remunerație”. În disputele legate de dezvoltarea de sisteme, nu este neobișnuit ca încheierea contractului în sine să fie contestată și ca deciziile să fie luate în detrimentul dezvoltatorilor. Ca dezvoltator, există riscul de a nu primi plata dacă clientul decide să oprească proiectul sau să treacă la o altă companie. De asemenea, așa cum vom menționa mai târziu, există cazuri în care încheierea contractului este negată chiar dacă a fost creat un contract.

Aici, vom explica structura legală pentru a solicita bani în cazul în care încheierea contractului de dezvoltare a sistemului este respinsă sau nu este recunoscută.

Încheierea unui contract

În principiu, un contract se încheie atunci când ambele părți sunt de acord cu elementele contractului (coincidența dintre declarația de intenție de a aplica și declarația de intenție de a accepta).

Odată ce contractul este încheiat, ambele părți sunt obligate de acesta, iar dacă una dintre părți nu îndeplinește conținutul contractului, cealaltă parte poate forța executarea prin instanță sau poate solicita despăgubiri pentru neexecutare. “Elementele contractului” trebuie să fie specificate sau concrete la un nivel care să permită forțarea executării și recunoașterea neexecutării.

Încheierea unui contract este o problemă foarte importantă

Încheierea unui contract de dezvoltare a sistemului

Natura unui contract de dezvoltare a sistemului este în principal un contract de lucrări și un contract de mandat. Contractul de lucrări promite finalizarea lucrării și plata pentru aceasta. Contractul de mandat cu plată promite executarea lucrării și plata pentru aceasta.

https://monolith.law/corporate/contract-and-timeandmaterialcontract[ja]

Prin urmare, dacă există un acord între părți cu privire la “conținutul lucrării sau al activității” și “suma plății”, care sunt elementele contractului, se consideră că contractul a fost încheiat.

De asemenea, este posibil să se încheie un contract doar prin promisiuni verbale, fără a fi necesar un contract scris.

Cererea de bani în cazul în care contractul de dezvoltare a sistemului este anulat după încheiere

Dacă contractul de dezvoltare a sistemului a fost încheiat și utilizatorul spune că îl va anula unilateral, din punct de vedere juridic, se consideră că a fost notificată rezilierea contractului.

Dacă un contract de lucrări este în vigoare, furnizorul poate fi reziliat de către utilizator în orice moment până la finalizarea lucrării, dar se prevede că este într-o poziție în care poate fi despăgubit (Articolul 641 al Codului Civil Japonez). Prin urmare, dacă utilizatorul nu a plătit despăgubiri, furnizorul poate solicita despăgubiri pentru “daune”, care sunt suma cheltuielilor pe care le-a suportat până în acel moment și suma plății pe care ar fi putut-o obține, minus costurile pe care le-a putut economisi prin evitarea finalizării sistemului.

De asemenea, dacă un contract de mandat este în vigoare, când mandatul se încheie în timpul executării, mandatarul poate solicita plata în funcție de proporția de executare (Articolul 648 alineatul (3) al Codului Civil Japonez revizuit). Prin urmare, furnizorul poate solicita plata pentru munca deja efectuată.

Rezultatul contractului de dezvoltare a sistemului

Specificitatea conținutului sistemului

De obicei, tranzacțiile între companii, în special contractele cu sume mari, sunt realizate în scris, astfel încât, dacă există un contract, este mai ușor de recunoscut încheierea acestuia.

Sistemul care este subiectul dezvoltării se concretizează treptat prin diverse procese, astfel încât specificitatea conținutului sistemului, care reprezintă “conținutul muncii” în elementele contractului de subcontractare, este considerată suficientă dacă se înțelege domeniul și descrierea generală a sistemului care urmează să fie implementat.

În cazurile judecate, nu există dispute cu privire la încheierea contractului de bază și a acordului de confidențialitate, iar în contractul de bază există o mențiune că “suportul tehnologic pentru afacerile de e-commerce, suportul pentru construirea site-urilor web și activitățile conexe” sunt delegate, dar nu au fost specificate detaliile concrete ale afacerii de e-commerce, domeniul activităților delegate, sau domeniul de dezvoltare și proiectare ca sistem, astfel încât încheierea contractului a fost negată.

Chiar dacă ați creat un contract de bază pentru dezvoltarea sistemului, dacă conținutul muncii sau al activităților este abstract și nu este specific, este dificil de recunoscut încheierea contractului. Încheierea contractului poate fi recunoscută prin contracte care descriu în mod concret conținutul muncii sau al activităților și suma remunerației, la un nivel care poate impune îndeplinirea și poate recunoaște neîndeplinirea.

De asemenea, explicăm în detaliu punctele de atenție pentru contractele între inginerii individuali și corporații în articolul de mai jos.

https://monolith.law/corporate/engineer-joint-enterprise-contract[ja]

Furnizorul prezintă estimări și specificații, iar utilizatorul le aprobă și plasează comanda

De obicei, tranzacțiile între companii se fac în scris, deci dacă nu există un contract, este dificil să se recunoască încheierea acestuia. În dezvoltarea de sisteme, este adesea cazul că lucrul începe înainte de a se crea un contract, dar cum este considerată încheierea contractului în acest caz?

Într-un caz judecat (decizia Tribunalului Districtual Nagoya din 28 ianuarie 2004 (2004)), se menționează că încheierea unui contract de dezvoltare a sistemului se realizează astfel:

  • După negocieri între furnizor și utilizator pentru confirmarea specificațiilor,
  • Furnizorul prezintă specificații și estimări,
  • Acestea sunt aprobate de utilizator și se plasează comanda.

În acest caz, furnizorul a primit de la utilizator, care era o autoritate locală, o solicitare de implementare a unui sistem de contabilitate financiară, etc. În răspuns la un RFP intitulat “Cerere pentru prezentarea unei propuneri privind implementarea sistemului de informații administrative generale”, furnizorul a prezentat o propunere și o estimare, iar utilizatorul a emis o “notificare de adoptare”. Furnizorul nu a examinat suficient conținutul activității utilizatorului, etc., fără a se consulta cu utilizatorul, și nu s-a putut confirma faptul că s-a discutat în detaliu în cadrul utilizatorului despre conținutul personalizării și costurile. Propunerea furnizorului nu era specifică, nu era clar ce a aprobat utilizatorul, și nu s-a putut recunoaște încheierea contractului.

Voi explica în detaliu despre încheierea contractului menționată în acest caz, luând în considerare și alte cazuri judecate.

După negocieri între furnizor și utilizator pentru confirmarea specificațiilor

Din faptul că se spune “după negocieri”, dacă se află “în negocieri” cu privire la elementele contractuale, cum ar fi conținutul sistemului și suma remunerației, este dificil să se recunoască încheierea contractului dacă nu s-a ajuns la un acord.

În orice caz, într-un contract de prestări de servicii, se poate stabili că prețul este prețul de piață, deci există cazuri în care s-a recunoscut că s-a încheiat un contract de prestări de servicii la un preț echivalent cu prețul de piață, deoarece utilizatorul a aprobat conținutul sistemului și “suma aproximativă” a remunerației.

Pentru a putea spune că “au avut loc negocieri”, furnizorul ar trebui să discute suficient cu utilizatorul despre conținutul activității acestuia, conținutul sistemului, etc., și să înregistreze acest lucru în e-mailuri, minute de ședințe, etc.

Furnizorul prezintă specificații și estimări, iar utilizatorul le aprobă și plasează comanda

  • Dacă utilizatorul emite o comandă sau o comandă, este mai ușor să se recunoască încheierea contractului. Dacă furnizorul prezintă o cerere sau efectuează lucrări pe baza unei comenzi, etc., este mai probabil să se recunoască că există un “acord” și, prin urmare, să se recunoască încheierea contractului.
  • Notificările interne ale utilizatorului sunt adesea în sensul că se intenționează să se încheie un contract în viitor, și este dificil să se recunoască încheierea contractului. Cu toate acestea, dacă nu există o astfel de mențiune și se descrie cât mai concret posibil despre elementele contractuale, cum ar fi conținutul dezvoltării sistemului și suma remunerației, acest lucru va contribui la recunoașterea încheierii contractului.
  • Este dificil să se recunoască încheierea contractului dacă memorandumurile, acordurile, notele de confirmare sunt pe baza presupunerii că se va încheia un contract separat sau dacă conținutul este abstract.
  • Dacă nu există o ștampilă pe proiectul de contract, ștampilarea este în sensul încheierii, și este dificil să se recunoască încheierea contractului.
  • Estimările sunt dovezi pentru recunoașterea sumei remunerației convenite între părți.

În plus, în dezvoltarea de sisteme, dacă procesul a avansat până la un anumit punct și se solicită modificarea specificațiilor ulterioare sau adăugarea de funcții, dacă este posibil să se solicite o sumă suplimentară la suma estimată inițial, etc., detalii sunt explicate în detaliu în articolul de mai jos.

https://monolith.law/corporate/increase-of-estimate[ja]

Acord de lichidare

În cazul în care se efectuează lucrări la indicația utilizatorului, presupunând încheierea unui contract, este posibil să fie recunoscut un “acord de lichidare”, care prevede lichidarea remunerației pentru munca efectuată până la oprirea lucrărilor. Pentru a facilita recunoașterea acestui acord, ar fi bine să obțineți de la utilizator o înregistrare scrisă, cum ar fi o notificare internă, cu privire la metoda de lichidare a remunerației în cazul în care contractul nu a fost încheiat, sau să obțineți aprobarea unei persoane autorizate de utilizator pentru documentul scris creat de furnizor.

Configurația legală pentru a solicita bani în cazul în care nu se recunoaște încheierea unui contract

Ce se întâmplă dacă nu se recunoaște încheierea unui contract?

Neglijența în încheierea contractului

Când începeți negocierile pentru încheierea unui contract, părțile au obligația, conform principiului bunei credințe (Articolul 1, alineatul 2 al Codului Civil Japonez), de a se strădui să nu încalce proprietatea celuilalt. Dacă nu se ajunge la încheierea unui contract, puteți solicita despăgubiri dacă există circumstanțe obiective care au făcut ca cealaltă parte să se aștepte la încheierea contractului și dacă există culpabilitate. Acest lucru se numește neglijență în încheierea contractului.

Vă vom prezenta un rezumat al cazurilor în care a fost recunoscută neglijența în încheierea contractului în jurisprudență.

  • Vânzătorul a finalizat definiția cerințelor la cererea utilizatorului și a implementat o parte din proiectarea de bază și detaliată. Cu toate acestea, chiar înainte de încheierea contractului, un alt companie a fost selectată și nu s-a ajuns la încheierea contractului.
  • Vânzătorul a continuat lucrul la cererea utilizatorului de a respecta termenul limită, iar data încheierii contractului a fost stabilită în apropiere. Cu toate acestea, în cadrul companiei utilizatorului, pregătirile pentru dezvoltarea internă au fost în curs, dar acestea au fost ascunse și nu s-a ajuns la încheierea contractului.
  • Vânzătorul a fost notificat de către utilizator că a fost ales ca constructor, nu au existat niciun fel de îndoieli cu privire la estimarea costurilor și, pe baza discuțiilor cu utilizatorul, a efectuat lucrări pentru stabilirea specificațiilor. Cu toate acestea, contractul a fost refuzat pe motiv că nu se putea ajunge la un acord cu privire la suma estimată.

Pe de altă parte, ca exemplu de cazuri în care nu a fost recunoscută neglijența în încheierea contractului, putem menționa cazurile în care posibilitatea de a alege o altă companie sau condițiile pentru încheierea contractului au fost explicitate.

Dacă, în ciuda faptului că ați continuat lucrul la cererea utilizatorului, nu ați fost informați despre posibilitatea de a alege o altă companie sau despre condițiile de acord, și negocierile contractuale au fost anulate brusc din aceste motive, este posibil să vi se recunoască dreptul de a solicita despăgubiri.

Nu există nicio dispută cu privire la faptul că cheltuielile pe care le-ați suportat până acum sunt incluse în “daune”. În plus, există cazuri în care s-a considerat că profitul pentru munca efectivă este inclus. De asemenea, dacă puteți prezenta dovezi că ați refuzat o ofertă de la o altă companie și ați suferit daune echivalente cu profitul pe care l-ați fi obținut dacă ați fi lucrat după aceea, se poate considera că acestea sunt incluse.

Articolul 512 din Codul Comercial Japonez

Dacă vânzătorul a efectuat acțiuni legate de dezvoltarea sistemului pentru utilizator, poate solicita o remunerație rezonabilă în conformitate cu Articolul 512 din Codul Comercial Japonez.

Când începeți negocierile pentru dezvoltarea unui sistem, este bine să vă înțelegeți reciproc conținutul sistemului și suma remunerației, folosind e-mailuri sau minute de întâlnire, și să lăsați dovezi care să recunoască că există circumstanțe care vă fac să credeți că încheierea contractului este sigură și că elementele contractului au fost concretizate.

Chiar dacă vi se refuză plata pe motiv că nu ați încheiat un contract, cum ar fi menționat mai sus, este posibil să vi se recunoască dreptul de a solicita bani.

Rezumat

Așa cum am menționat, instanțele de judecată tind să aibă o abordare “negativă” în cazul relațiilor contractuale în care nu există un contract scris, cel puțin în comparație cu percepția companiei contractante. Din perspectiva companiei contractante, ar dori să spună că “trebuia să începem să lucrăm mai întâi și contractul urma să fie încheiat ulterior, deci contractul este deja în vigoare”. Cu toate acestea, acest argument nu este întotdeauna acceptat.

De asemenea, dacă încheierea contractului este negată, există cazuri în care puteți solicita bani prin structuri legale, cum ar fi neglijența în încheierea contractului sau Articolul 512 din Legea Comercială Japoneză, dar nici aceasta nu este o situație “certă”.

Dacă trebuie să începeți lucrul înainte de a încheia un contract, trebuie să:

  • În primul rând, să recunoașteți că acesta este un act cu risc și să decideți dacă merită să alocați resurse pentru acest proiect, ținând cont de acest risc (în special în cazul întreprinderilor mici și mijlocii sau al startup-urilor, există situații în care trebuie să luați decizia de a “acționa mai întâi” pentru a obține experiență de afaceri cu o corporație mare. Acesta este un proces decizional de management posibil dacă riscul este luat în considerare.)
  • Considerați dacă nu puteți încheia un acord de lichidare în cazul în care contractul nu este încheiat

Se poate spune că este necesar să aveți acest tip de gândire.

Managing Attorney: Toki Kawase

The Editor in Chief: Managing Attorney: Toki Kawase

An expert in IT-related legal affairs in Japan who established MONOLITH LAW OFFICE and serves as its managing attorney. Formerly an IT engineer, he has been involved in the management of IT companies. Served as legal counsel to more than 100 companies, ranging from top-tier organizations to seed-stage Startups.

Category: IT

Tag:

?napoi la ?nceput