I den f\u00f8lgende rettsavgj\u00f8relsen ble det oppdaget problemer med systemet som leverand\u00f8ren hadde levert, som for eksempel behandlingstid og kommunikasjonskostnader. Selv om slike problemer ble funnet, var hele utviklingsprosessen fullf\u00f8rt, og sp\u00f8rsm\u00e5let var om dette kunne anses som “arbeidets fullf\u00f8ring”. Resultatet var at arbeidet ble ansett som fullf\u00f8rt.<\/p>\n
\nJapansk sivilrettslov (\u6c11\u6cd5) \u00a7 632 og \u00a7 633 fastsetter at tidspunktet for betaling av vederlag til entrepren\u00f8ren er n\u00e5r entrepren\u00f8ren har fullf\u00f8rt arbeidet og overlevert arbeidsobjektet til bestilleren. P\u00e5 den annen side fastsetter \u00a7 634 at hvis arbeidsobjektet har mangler, er entrepren\u00f8ren ansvarlig for disse (f\u00f8rste ledd), og inntil entrepren\u00f8ren har oppfylt sitt ansvar for manglene, har bestilleren rett til \u00e5 holde tilbake betalingen (andre ledd). If\u00f8lge disse bestemmelsene i japansk sivilrettslov, skiller loven mellom tilfeller der arbeidsresultatet er ufullstendig p\u00e5 grunn av mangler i arbeidsobjektet og tilfeller der arbeidet ikke er fullf\u00f8rt<\/u>, og det forst\u00e5s at selv om arbeidsobjektet har mangler, enten de er skjulte eller \u00e5penbare, anses arbeidet som fullf\u00f8rt. om entrepren\u00f8ren har fullf\u00f8rt arbeidet eller ikke, b\u00f8r vurderes ut fra om arbeidet er fullf\u00f8rt til siste trinn som opprinnelig avtalt i kontrakten<\/u>, og bestilleren kan ikke nekte \u00e5 betale vederlaget bare fordi arbeidsobjektet har mangler.<\/p>\n
<\/p>\n<\/blockquote>\n
<\/p>\n
<\/p>\n
I den ovennevnte dommen ble det vurdert at “arbeidets fullf\u00f8ring” er oppfylt s\u00e5 lenge den siste fasen av systemutviklingen er fullf\u00f8rt. Som en l\u00f8sning p\u00e5 mangler i systemet som leverand\u00f8ren har laget (ofte referert til som “mangler” i juridisk terminologi), finnes det et eget system for ansvar for mangler.<\/p>\n
<\/p>\n
<\/p>\n
Derfor, selv om begrepet “arbeidets fullf\u00f8ring” tolkes noe bredt, vil det ikke n\u00f8dvendigvis f\u00f8re til urettferdighet for brukeren. Oppsummert kan dette uttrykkes som f\u00f8lger:<\/p>\n
<\/p>\n
<\/p>\n
\u3010Forpliktelse i en entreprisekontrakt = Arbeidets fullf\u00f8ring = Fullf\u00f8ring av alle faser\u3011
<\/p>\n
<\/p>\n
Den ovennevnte rettsavgj\u00f8relsen viser hvordan man kan skille mellom disse problemene.<\/p>\n
<\/p>\n
<\/p>\n
Videre, n\u00e5r det gjelder “arbeidets fullf\u00f8ring”, kan vi ogs\u00e5 vurdere det fra perspektivet “brukerens godkjenning”. Vi har en egen artikkel som forklarer juridiske problemer n\u00e5r brukerens godkjenning ikke g\u00e5r som planlagt.<\/p>\n
<\/p>\n
<\/p>\n\nhttps:\/\/monolith-law.jp\/corporate\/estimated-inspection-of-system-development<\/div>\n<\/figure>\n
<\/p>\n
<\/span>Hva det betyr \u00e5 fullf\u00f8re et juridisk arbeid<\/span><\/h2>\n<\/p>\n
<\/p>\nI en oppdragsavtale kan man kreve betaling etter at arbeidet er anerkjent som fullf\u00f8rt.<\/figcaption>\n<\/figure>\n<\/p>\n
<\/p>\n
Innen systemutvikling, n\u00e5r “arbeidets fullf\u00f8ring” er anerkjent, betyr det at forpliktelsen er oppfylt, og man kan ikke lenger holdes ansvarlig for mislighold av forpliktelser. I en oppdragsavtale kan man ikke kreve betaling med mindre arbeidet er fullf\u00f8rt, og selv om det er avtalt forskuddsbetaling, m\u00e5 disse i utgangspunktet tilbakebetales. P\u00e5 den annen side, hvis det er anerkjent at arbeidet er fullf\u00f8rt, vil leverand\u00f8ren kun v\u00e6re ansvarlig for mangelsansvar og kvalitetsgarantier i henhold til kontrakten.<\/p>\n
<\/p>\n
<\/p>\n
At leverand\u00f8ren frigj\u00f8res fra misligholdsansvar betyr at muligheten for at brukeren kan heve kontrakten blir betydelig redusert. Dette er fordi heving av kontrakten basert p\u00e5 mangelsansvar er begrenset til tilfeller hvor kontraktens form\u00e5l ikke kan oppn\u00e5s. Hvis kontrakten heves, mister leverand\u00f8ren ogs\u00e5 retten til \u00e5 kreve betaling (med andre ord, de vil ikke motta noen betaling), noe som ofte f\u00f8rer til tvister om “arbeidets fullf\u00f8ring” i praksis.<\/p>\n
<\/p>\n
<\/p>\n
For en detaljert forklaring om “heving” av kontrakter innen systemutvikling, se artikkelen nedenfor.<\/p>\n
<\/p>\n
<\/p>\n\nhttps:\/\/monolith-law.jp\/corporate\/cancellation-of-contracts-in-system-development<\/div>\n<\/figure>\n
<\/p>\n
<\/span>Viktige merknader ved fullf\u00f8ring av arbeid<\/span><\/h2>\n<\/p>\n
<\/p>\n
<\/span>Hvordan h\u00e5ndtere endringer i spesifikasjoner og tillegg i utvikling<\/span><\/h3>\n<\/p>\n
<\/p>\n
For leverand\u00f8rer kan det oppst\u00e5 situasjoner der de allerede har oppfylt de opprinnelige spesifikasjonene, men blir bedt om \u00e5 gj\u00f8re endringer eller legge til funksjoner, noe som gj\u00f8r det vanskelig \u00e5 avslutte arbeidet. I slike tilfeller oppst\u00e5r sp\u00f8rsm\u00e5let om n\u00e5r man skal avslutte systemutviklingen. En detaljert forklaring p\u00e5 dette finner du i artikkelen nedenfor.<\/p>\n
<\/p>\n
<\/p>\n\nhttps:\/\/monolith-law.jp\/corporate\/increase-of-estimate<\/div>\n<\/figure>\n
<\/span>V\u00e6r oppmerksom p\u00e5 endringer i den japanske sivilretten<\/span><\/h3>\n<\/p>\n
<\/p>\n
Reglene for ansvar for mangler i kontrakter har tradisjonelt v\u00e6rt komplekse og vanskelige \u00e5 forst\u00e5, og dette omr\u00e5det er sterkt p\u00e5virket av endringer i den japanske sivilretten. Hvordan man b\u00f8r tolke “mangler” i lys av disse endringene, er detaljert forklart i artikkelen nedenfor.<\/p>\n
<\/p>\n
<\/p>\n\nhttps:\/\/monolith-law.jp\/corporate\/defect-warranty-liability<\/div>\n<\/figure>\n
<\/p>\n
<\/span>Oppsummering<\/span><\/h2>\n<\/p>\n
<\/p>\n
I denne artikkelen har vi forklart veien fra systemutviklingsprosjekter, som ofte kan virke som om de “ikke har noen utvei”, til \u00e5 knytte dem til det juridiske konseptet “fullf\u00f8ring av arbeid”. Selv om utgangen for hvert enkelt prosjekt kan variere avhengig av utviklingskravene, er det ikke uvanlig at det juridiske konseptet “fullf\u00f8ring av arbeid” kan v\u00e6re en veiledende tr\u00e5d n\u00e5r det oppst\u00e5r tvister rundt disse punktene.<\/p>\n
<\/p>","protected":false},"excerpt":{"rendered":"
Systemutvikling er vanligvis en langvarig prosess, og det kan ofte kreves endringer i spesifikasjoner eller implementering av nye funksjoner flere ganger. For leverand\u00f8rene som tar p\u00e5 seg arbeidet, ka […]<\/p>\n","protected":false},"author":32,"featured_media":84039,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[16],"tags":[19,31],"acf":[],"_links":{"self":[{"href":"https:\/\/monolith.law\/no\/wp-json\/wp\/v2\/posts\/70946"}],"collection":[{"href":"https:\/\/monolith.law\/no\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/monolith.law\/no\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/monolith.law\/no\/wp-json\/wp\/v2\/users\/32"}],"replies":[{"embeddable":true,"href":"https:\/\/monolith.law\/no\/wp-json\/wp\/v2\/comments?post=70946"}],"version-history":[{"count":2,"href":"https:\/\/monolith.law\/no\/wp-json\/wp\/v2\/posts\/70946\/revisions"}],"predecessor-version":[{"id":84043,"href":"https:\/\/monolith.law\/no\/wp-json\/wp\/v2\/posts\/70946\/revisions\/84043"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/monolith.law\/no\/wp-json\/wp\/v2\/media\/84039"}],"wp:attachment":[{"href":"https:\/\/monolith.law\/no\/wp-json\/wp\/v2\/media?parent=70946"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/monolith.law\/no\/wp-json\/wp\/v2\/categories?post=70946"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/monolith.law\/no\/wp-json\/wp\/v2\/tags?post=70946"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}