Da denne proces er kontraktbaseret, vil den f\u00e6rdige software osv. blive leveret som et produkt, der skal inspiceres. Paragraf 1 fasts\u00e6tter, at leverancerne skal leveres sammen med en anmodning om accept (ogs\u00e5 en leveringsnota).<\/p>\n\n\n\n
Paragraf 2 fasts\u00e6tter brugerens gennemf\u00f8relse af inspektionen.
Paragraf 3 fasts\u00e6tter brugerens forpligtelse til at samarbejde, da der kan v\u00e6re tilf\u00e6lde, hvor brugerens samarbejde er n\u00f8dvendigt for levering til det sted, der er specificeret i den individuelle kontrakt (f.eks. n\u00e5r levering sker ved at bringe det ind i brugerens kontor, eller n\u00e5r det leveres i en tilstand, hvor det kan fungere i brugerens faktiske driftsmilj\u00f8).
Paragraf 4 er en bestemmelse om risikoen for tab eller skade p\u00e5 leverancerne, og tiden for overf\u00f8rsel af risikoen er opdelt baseret p\u00e5 overf\u00f8rslen af fysisk kontrol.<\/p>\n\n\n\n
\n(Accept af denne software)
Paragraf \u3007: For denne software blandt leverancerne skal Part A inspicere den inden for den periode, der er fastsat i den individuelle kontrakt (herefter kaldet “inspektionsperioden”), i henhold til inspektionsspecifikationerne i den foreg\u00e5ende paragraf og kontrollere, om systemspecifikationerne og denne software stemmer overens.<\/p>\n\n\n\n
2. Hvis denne software er i overensstemmelse med inspektionen i det foreg\u00e5ende afsnit, skal Part A underskrive og forsegle en inspektionsgodkendelsesformular og give den til Part B. Desuden, hvis denne software ikke best\u00e5r inspektionen i det foreg\u00e5ende afsnit, skal Part A hurtigt give Part B en skriftlig forklaring, der klart angiver de specifikke grunde til, at den ikke bestod, og anmode om rettelser eller tilf\u00f8jelser, og n\u00e5r grunden til, at den ikke bestod, er anerkendt, skal Part B rette den gratis inden for den periode, der er fastsat efter dr\u00f8ftelser, og levere den til Part A, og Part A skal udf\u00f8re inspektionen specificeret i det foreg\u00e5ende afsnit igen i det omfang, der er n\u00f8dvendigt.<\/p>\n\n\n\n
3. Selv hvis en inspektionsgodkendelsesformular ikke er givet, hvis Part A ikke angiver en specifik grund i skriftlig form og frems\u00e6tter en indsigelse inden for inspektionsperioden, anses denne software for at have best\u00e5et inspektionen specificeret i denne paragraf.<\/p>\n\n\n\n
4. Accepten af denne software skal betragtes som fuldf\u00f8rt ved godkendelse af inspektionen specificeret i denne paragraf. <\/p>\n<\/blockquote>\n\n\n\n
Da denne proces er kontraktbaseret, fasts\u00e6tter denne paragraf proceduren for accept af den leverede software.<\/p>\n\n\n\n
Paragraf 1 fasts\u00e6tter, at denne software skal inspiceres inden for inspektionsperioden i henhold til inspektionsspecifikationerne, og det skal kontrolleres, om systemspecifikationerne og denne software stemmer overens.
Paragraf 2 p\u00e5l\u00e6gger leverand\u00f8ren en forpligtelse til at rette denne software, hvis det er konstateret, at denne software ikke er i overensstemmelse med systemspecifikationerne.
Paragraf 3 er en bestemmelse, der forhindrer, at accepten forl\u00e6nges p\u00e5 grund af brugerens omst\u00e6ndigheder, ved at fasts\u00e6tte en formodet acceptgodkendelse.
Paragraf 4 klart angiver, at accepten af denne software betragtes som fuldf\u00f8rt ved godkendelse af inspektionen.<\/p>\n\n\n\n
\n(Fejl- og mangelforpligtelse)
Paragraf \u3007: Hvis der efter inspektionen i den foreg\u00e5ende paragraf opdages en uoverensstemmelse (inklusive bugs, herefter i denne paragraf kaldet “fejl”) mellem leverancerne og systemspecifikationerne, kan Part A anmode Part B om at rette den p\u00e5g\u00e6ldende fejl, og Part B skal rette den p\u00e5g\u00e6ldende fejl. Dog skal Part B kun b\u00e6re dette ansvar for rettelser, hvis anmodningen er fremsat af Part A inden for \u25cb m\u00e5neder efter inspektionen i den foreg\u00e5ende paragraf.
2. Uanset det foreg\u00e5ende afsnit, hvis fejlen er mindre, og rettelsen af leverancerne kr\u00e6ver overdreven omkostninger, skal Part B ikke b\u00e6re ansvaret for rettelsen specificeret i det foreg\u00e5ende afsnit.
3. Bestemmelsen i afsnit 1 g\u00e6lder ikke, n\u00e5r fejlen er opst\u00e5et p\u00e5 grund af dokumenter osv. leveret af Part A eller instruktioner givet af Part A. Dog g\u00e6lder dette ikke, hvis Part B ikke har meddelt, at dokumenterne osv. eller instruktionerne var upassende, selvom Part B vidste det. \u3000<\/p>\n<\/blockquote>\n\n\n\n
Da denne proces er kontraktbaseret, fasts\u00e6tter denne paragraf fejl- og mangelforpligtelsen for leverancerne. Gr\u00e6nsen mellem ansvar for manglende opfyldelse af forpligtelser i en situation, hvor opfyldelsen ikke er opfyldt (arbejdet er ikke afsluttet), og fejl- og mangelforpligtelsen i en situation, hvor opfyldelsen er afsluttet (arbejdet er afsluttet), er i praksis sv\u00e6r at afg\u00f8re. Der er en retskendelse (Tokyo District Court, 22. april 2002), der siger, at om systemudvikling kan betragtes som afsluttet eller ej, skal afg\u00f8res ud fra, om arbejdet er afsluttet indtil den sidste proces, der var planlagt i den oprindelige kontrakt. Hvis en fejl opdages efter levering og inspektionsgodkendelse af softwaren, vil fejl- og mangelforpligtelsen i princippet g\u00e6lde.<\/p>\n\n\n\n
Paragraf 1 definerer “uoverensstemmelse med systemspecifikationerne” som en fejl i softwareudviklingsopgaver. For mangler, der opst\u00e5r i den eksterne designfase, bestemmes ansvaret i henhold til bestemmelserne om fejl- og mangelforpligtelse i den eksterne designfase, ikke i denne paragraf. Fejl- og mangelforpligtelsesperioden skal fasts\u00e6ttes som en rimelig periode gennem dr\u00f8ftelser mellem parterne under hensyntagen til st\u00f8rrelsen af informationssystemet, prisen osv.<\/p>\n\n\n\n
Paragraf 2 fasts\u00e6tter en bestemmelse svarende til artikel 634, stk. 1, i Civil Code, hvor det er for h\u00e5rdt at kr\u00e6ve rettelser uden beregning fra leverand\u00f8ren, selvom fejlen er mindre, og rettelsen af leverancerne kr\u00e6ver overdreven omkostninger.<\/p>\n\n\n\n
Paragraf 3 er en bestemmelse svarende til artikel 636 i Civil Code, hvor leverand\u00f8ren ikke er ansvarlig for fejl- og mangelforpligtelsen, hvis fejlen skyldes instruktioner eller dokumenter osv. leveret af brugeren, men hvis leverand\u00f8ren vidste, at dokumenterne osv. eller instruktionerne var upassende og ikke p\u00e5pegede det, kan leverand\u00f8ren ikke undslippe fejl- og mangelforpligtelsen.<\/p>\n\n\n\n
For en detaljeret forklaring p\u00e5, hvorn\u00e5r en fejl er anerkendt, og hvad det specifikke ansvar er, n\u00e5r en fejl er anerkendt, se f\u00f8lgende artikel.<\/p>\n\n\n\n
https:\/\/monolith.law\/corporate\/defect-warranty-liability [ja]<\/a><\/p>\n\n\n\n<\/span>Software driftsforberedelse og overgangsst\u00f8tte<\/span><\/h3>\n\n\n\nI systemmodtagelses- og implementeringsfasen er det almindeligt, at brugeren tager initiativet. I den modelkontrakt, som det japanske Ministerium for \u00d8konomi, Handel og Industri (METI) har fastlagt, er det brugeren, der er hovedakt\u00f8ren, og leverand\u00f8ren st\u00f8tter dette i form af en semi-delegeret model.<\/p>\n\n\n\n
<\/span>Afg\u00f8relse af kontraktens karakter<\/span><\/h2>\n\n\n\nFor at bestemme karakteren af en kontrakt, skal man se p\u00e5 kontrakten som helhed og overveje, om dens form\u00e5l er at “levere et f\u00e6rdigt produkt” eller om det er, at leverand\u00f8ren skal “udf\u00f8re arbejdet p\u00e5 en rimelig m\u00e5de”. En generel retningslinje er, om indholdet af det produkt, der skal fuldf\u00f8res, er blevet bestemt i nogen grad, og om projektet er blevet fremskredet i retning af dette. For at forst\u00e5, hvilke specifikke aspekter man skal fokusere p\u00e5, kan du finde en detaljeret forklaring i artiklen nedenfor.<\/p>\n\n\n","protected":false},"excerpt":{"rendered":"
Det Japanske Ministerium for \u00d8konomi, Handel og Industri har fremlagt modelklausuler for IT-systemudviklingskontrakter i deres “Retningslinjer for forbedring af p\u00e5lideligheden af informationssys […]<\/p>\n","protected":false},"author":32,"featured_media":58125,"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\/da\/wp-json\/wp\/v2\/posts\/58063"}],"collection":[{"href":"https:\/\/monolith.law\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/monolith.law\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/monolith.law\/da\/wp-json\/wp\/v2\/users\/32"}],"replies":[{"embeddable":true,"href":"https:\/\/monolith.law\/da\/wp-json\/wp\/v2\/comments?post=58063"}],"version-history":[{"count":2,"href":"https:\/\/monolith.law\/da\/wp-json\/wp\/v2\/posts\/58063\/revisions"}],"predecessor-version":[{"id":58128,"href":"https:\/\/monolith.law\/da\/wp-json\/wp\/v2\/posts\/58063\/revisions\/58128"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/monolith.law\/da\/wp-json\/wp\/v2\/media\/58125"}],"wp:attachment":[{"href":"https:\/\/monolith.law\/da\/wp-json\/wp\/v2\/media?parent=58063"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/monolith.law\/da\/wp-json\/wp\/v2\/categories?post=58063"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/monolith.law\/da\/wp-json\/wp\/v2\/tags?post=58063"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}