{"id":61449,"date":"2023-12-08T20:55:29","date_gmt":"2023-12-08T11:55:29","guid":{"rendered":"https:\/\/monolith.law\/no\/?p=61449"},"modified":"2024-01-04T21:10:15","modified_gmt":"2024-01-04T12:10:15","slug":"no-payment-by-user","status":"publish","type":"post","link":"https:\/\/monolith.law\/no\/it\/no-payment-by-user","title":{"rendered":"Hva er loven n\u00e5r betaling for systemutvikling ikke er gjort?"},"content":{"rendered":"\n<p>For en leverand\u00f8r som tar p\u00e5 seg systemutviklingsoppgaver, kan det i en viss forstand v\u00e6re den st\u00f8rste risikoen n\u00e5r brukeren ikke betaler for tjenesten, til tross for at den er levert. Kostnadene for systemutvikling best\u00e5r ofte av dyktige fagfolk som programmerere, og det er ofte tilfeller der personalkostnadene er h\u00f8ye. Det kan v\u00e6re en liv-og-d\u00f8d-situasjon hvis inntektsgenereringen blir forsinket. I denne artikkelen vil vi diskutere juridiske aspekter som leverand\u00f8ren b\u00f8r vurdere i tilfeller der brukeren ikke svarer p\u00e5 betaling av honoraret.<\/p>\n\n\n\n<div id=\"ez-toc-container\" class=\"ez-toc-v2_0_53 counter-hierarchy ez-toc-counter ez-toc-grey ez-toc-container-direction\">\n<div class=\"ez-toc-title-container\">\n<span class=\"ez-toc-title-toggle\"><\/span><\/div>\n<nav><ul class='ez-toc-list ez-toc-list-level-1 ' ><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-1\" href=\"https:\/\/monolith.law\/no\/it\/no-payment-by-user\/#Forst_bekreft_om_det_er_mulig_a_kreve_betaling\" title=\"F\u00f8rst, bekreft om det er mulig \u00e5 kreve betaling\">F\u00f8rst, bekreft om det er mulig \u00e5 kreve betaling<\/a><ul class='ez-toc-list-level-3'><li class='ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-2\" href=\"https:\/\/monolith.law\/no\/it\/no-payment-by-user\/#Dokumenter_som_skal_sjekkes_for_a_undersoke_om_det_er_mulig_a_kreve_betaling\" title=\"Dokumenter som skal sjekkes for \u00e5 unders\u00f8ke om det er mulig \u00e5 kreve betaling\">Dokumenter som skal sjekkes for \u00e5 unders\u00f8ke om det er mulig \u00e5 kreve betaling<\/a><\/li><\/ul><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-3\" href=\"https:\/\/monolith.law\/no\/it\/no-payment-by-user\/#Neste_bekreft_hvor_mye_du_kan_kreve_i_honorar\" title=\"Neste, bekreft hvor mye du kan kreve i honorar\">Neste, bekreft hvor mye du kan kreve i honorar<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-4\" href=\"https:\/\/monolith.law\/no\/it\/no-payment-by-user\/#Til_slutt_vurdering_av_viktige_sporsmal_ved_faktisk_rettssak\" title=\"Til slutt, vurdering av viktige sp\u00f8rsm\u00e5l ved faktisk rettssak\">Til slutt, vurdering av viktige sp\u00f8rsm\u00e5l ved faktisk rettssak<\/a><ul class='ez-toc-list-level-3'><li class='ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-5\" href=\"https:\/\/monolith.law\/no\/it\/no-payment-by-user\/#Vaer_oppmerksom_pa_muligheten_for_motsoksmal\" title=\"V\u00e6r oppmerksom p\u00e5 muligheten for mots\u00f8ksm\u00e5l\">V\u00e6r oppmerksom p\u00e5 muligheten for mots\u00f8ksm\u00e5l<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-6\" href=\"https:\/\/monolith.law\/no\/it\/no-payment-by-user\/#Vurder_ogsa_om_det_virkelig_er_fordelaktig_for_virksomheten\" title=\"Vurder ogs\u00e5 om det virkelig er fordelaktig for virksomheten\">Vurder ogs\u00e5 om det virkelig er fordelaktig for virksomheten<\/a><\/li><\/ul><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-7\" href=\"https:\/\/monolith.law\/no\/it\/no-payment-by-user\/#Oppsummering\" title=\"Oppsummering\">Oppsummering<\/a><\/li><\/ul><\/nav><\/div>\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Forst_bekreft_om_det_er_mulig_a_kreve_betaling\"><\/span>F\u00f8rst, bekreft om det er mulig \u00e5 kreve betaling<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<ul>\n<li>En situasjon der leverand\u00f8ren har levert produktet til brukeren, men brukeren aksepterer ikke leveransen, noe som f\u00f8rer til forsinkelser i faktureringsprosessen.<\/li>\n\n\n\n<li>Til tross for at man trodde at inspeksjonen var fullf\u00f8rt, er det en eller annen uoverensstemmelse mellom brukerens forst\u00e5else, og de nekter \u00e5 betale.<\/li>\n<\/ul>\n\n\n\n<p>Dette er situasjoner som realistisk sett kan oppst\u00e5.<br><\/p>\n\n\n\n<p>For \u00f8vrig, n\u00e5r brukeren inspiserer spesifikasjonene til det ferdige systemet og aksepterer leveransen, kalles dette &#8220;inspeksjon&#8221; i systemutviklingsterminologi. Betydningen av denne inspeksjonen og hva man b\u00f8r vurdere n\u00e5r fremdriften ikke er tilfredsstillende, er forklart i detalj i artikkelen nedenfor.<\/p>\n\n\n\n<p>Relatert artikkel: <a href=\"https:\/\/monolith.law\/corporate\/estimated-inspection-of-system-development\" target=\"_blank\" rel=\"noreferrer noopener\">Anvendelsesomr\u00e5der for inspeksjons- og antatt inspeksjonsklausuler i systemutvikling<\/a><\/p>\n\n\n\n<p>En generell forklaring p\u00e5 inspeksjonen selv er overlatt til artikkelen ovenfor, men fra et juridisk perspektiv, om brukerens inspeksjon kan sies \u00e5 v\u00e6re fullf\u00f8rt eller ikke, m\u00e5 vurderes med tanke p\u00e5 bestemmelsene om &#8220;antatt inspeksjonsklausuler&#8221;.<\/p>\n\n\n\n<p>Med dette i bakhodet, er det f\u00f8rste punktet som b\u00f8r vurderes n\u00e5r brukeren nekter \u00e5 betale, som f\u00f8lger:<\/p>\n\n\n\n<ol>\n<li>Er jobben fullf\u00f8rt i utgangspunktet, eller er den fortsatt uferdig?<\/li>\n\n\n\n<li>Er det mulig \u00e5 anvende garantiansvaret for mangler (Artikkel 635 i den japanske sivilloven)?<\/li>\n<\/ol>\n\n\n\n<p>Grunnen til at vi f\u00f8rst b\u00f8r bekrefte de to punktene ovenfor, er at hvis jobben ikke er fullf\u00f8rt i utgangspunktet, og det ikke er noen anvendelse av garantiansvaret for mangler (Artikkel 635 i den japanske sivilloven), vil det ikke v\u00e6re mulig \u00e5 forvente betaling, selv om en rettssak blir anlagt.<\/p>\n\n\n\n<p>S\u00e5, hva b\u00f8r leverand\u00f8rens representant unders\u00f8ke for \u00e5 vurdere de to punktene ovenfor? La oss se p\u00e5 hvilke dokumenter som b\u00f8r bekreftes nedenfor.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Dokumenter_som_skal_sjekkes_for_a_undersoke_om_det_er_mulig_a_kreve_betaling\"><\/span>Dokumenter som skal sjekkes for \u00e5 unders\u00f8ke om det er mulig \u00e5 kreve betaling<span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<table style=\"border-collapse: collapse;width: 100%\">\n<tbody>\n<tr>\n<td style=\"width: 100%;background-color: #f0f8ff;text-align: left\">Leveringsdokument<br>Hvis det ikke finnes et leveringsdokument, antas det at leveringen ikke er fullf\u00f8rt og at arbeidet ikke er ferdig.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n\n\n\n<table style=\"border-collapse: collapse;width: 100%\">\n<tbody>\n<tr>\n<td style=\"width: 100%;background-color: #e6e6fa;text-align: left\">Dokument som varsler resultatet av inspeksjonen<br>Dette er det viktigste dokumentet n\u00e5r man skal avgj\u00f8re om arbeidet kan betraktes som fullf\u00f8rt. I tillegg, hvis inspeksjonen er utsatt p\u00e5 grunn av brukerens omstendigheter, er det ogs\u00e5 lurt \u00e5 sjekke hvordan &#8220;antatt inspeksjonsklausul&#8221; er beskrevet i kontrakten.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n\n\n\n<table style=\"border-collapse: collapse;width: 100%;height: 117px\">\n<tbody>\n<tr style=\"height: 117px\">\n<td style=\"width: 100%;background-color: #f0ffff;text-align: left;height: 117px\">Oppgaveadministrasjonsoversikt<br>Dette dokumentet gir informasjon om hvilke oppgaver som har blitt identifisert s\u00e5 langt, og hvilke tiltak som har blitt tatt. Det gir ogs\u00e5 informasjon om tilstanden til feil og problemer som har oppst\u00e5tt etter levering, og status for reparasjoner.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n\n\n\n<table style=\"border-collapse: collapse;width: 100%\">\n<tbody>\n<tr>\n<td style=\"width: 100%;background-color: #f5fffa;text-align: left\">Kravspesifikasjonsdokument, design-dokument og endringsstyringsdokument, m\u00f8tereferater, etc.<br>Ved \u00e5 klargj\u00f8re hvilken forst\u00e5else brukeren og leverand\u00f8ren hadde i utgangspunktet, blir dette dokumentet som avklarer hva som skal kalles feil og problemer.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n\n\n\n<p>For mer informasjon om hvordan du h\u00e5ndterer endringer i systemspesifikasjoner og hvordan du lager endringsstyringsdokumenter, se en annen artikkel.<\/p>\n\n\n\n<p>Relatert artikkel: <a href=\"https:\/\/monolith.law\/corporate\/howto-manage-change-in-system-development\" target=\"_blank\" rel=\"noreferrer noopener\" title=\"Juridisk perspektiv p\u00e5 hvordan h\u00e5ndtere endringsstyring i systemutvikling\">Juridisk perspektiv p\u00e5 hvordan h\u00e5ndtere endringsstyring i systemutvikling<\/a><\/p>\n\n\n\n<table style=\"border-collapse: collapse;width: 100%;height: 88px\">\n<tbody>\n<tr style=\"height: 88px\">\n<td style=\"width: 100%;background-color: #f0fff0;text-align: left;height: 88px\">Oppsigelsesvarsel eller dokument som beskriver brukerens intensjon<br>Dette er en metode for \u00e5 forst\u00e5 hva brukeren har tenkt med hensyn til \u00e5 ikke fortsette med inspeksjonen (eller ikke betale bel\u00f8nningen).<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Neste_bekreft_hvor_mye_du_kan_kreve_i_honorar\"><\/span>Neste, bekreft hvor mye du kan kreve i honorar<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<figure class=\"wp-block-image\"><img decoding=\"async\" src=\"https:\/\/monolith.law\/wp-content\/uploads\/2019\/07\/shutterstock_1063376933-1024x683.jpg\" alt=\"\" class=\"wp-image-3536\" \/><figcaption class=\"wp-element-caption\">Hvordan beregner man p\u00e5 nytt bel\u00f8pet som skal kreves etter endring av spesifikasjoner?<\/figcaption><\/figure>\n\n\n\n<p>Prinsippet er at bel\u00f8pet som kan kreves, skal v\u00e6re angitt i kontrakten. Men det kan v\u00e6re tilfeller der det ikke er en ordentlig kontrakt (eller et dokument som tilsvarer dette) igjen hvis det er gjort endringer i spesifikasjonene osv. etterp\u00e5. Hvordan man beregner p\u00e5 nytt estimatet basert p\u00e5 etterf\u00f8lgende grunner som endring av spesifikasjoner, tillegg av funksjoner, osv., er forklart i detalj i artikkelen nedenfor.<\/p>\n\n\n\n<p>Relatert artikkel: <a href=\"https:\/\/monolith.law\/corporate\/increase-of-estimate\">Er det mulig \u00e5 \u00f8ke estimatbel\u00f8pet for systemutvikling etterp\u00e5?<\/a><\/p>\n\n\n\n<p>Metoden for \u00e5 beregne estimatet p\u00e5 nytt er som beskrevet i denne artikkelen, men spesielt fra perspektivet av \u00e5 vurdere om det er mulig \u00e5 \u00f8ke bel\u00f8pet som skal kreves, vil vi se p\u00e5:<\/p>\n\n\n\n<ol>\n<li>Tilgjengeligheten og innholdet i estimatet for tilleggsutvikling og funksjonskorrigeringer<\/li>\n\n\n\n<li>Reaksjonen fra brukersiden til estimatet<\/li>\n\n\n\n<li>Tilgjengeligheten av enighet om bel\u00f8pet i forhold til situasjonen som for\u00e5rsaket tilleggsutvikling og funksjonskorrigeringer som er oppf\u00f8rt i problemstyringslisten<\/li>\n<\/ol>\n\n\n\n<p>Det sentrale punktet er \u00e5 unders\u00f8ke om det var enighet mellom brukersiden og &#8220;bestilling av arbeid for det bel\u00f8pet&#8221; (med andre ord, om kontrakten kan sies \u00e5 v\u00e6re inng\u00e5tt).<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Til_slutt_vurdering_av_viktige_sporsmal_ved_faktisk_rettssak\"><\/span>Til slutt, vurdering av viktige sp\u00f8rsm\u00e5l ved faktisk rettssak<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<h3 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Vaer_oppmerksom_pa_muligheten_for_motsoksmal\"><\/span>V\u00e6r oppmerksom p\u00e5 muligheten for mots\u00f8ksm\u00e5l<span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<p>I systemutvikling er det ikke uvanlig at n\u00e5r enten brukeren eller leverand\u00f8ren saks\u00f8ker den andre parten, kan det komme et mots\u00f8ksm\u00e5l. Det vil si, det kan v\u00e6re noen argumenter fra brukerens side i situasjoner der betalingen ikke blir gjort.<\/p>\n\n\n\n<p>F\u00f8rst og fremst, selv om brukeren har forskjellige samarbeidsforpliktelser i systemutvikling, b\u00f8r man ikke glemme at leverand\u00f8ren, som en ekspert i systemutvikling, har et bredt skj\u00f8nn og stort ansvar. Vi har en detaljert forklaring p\u00e5 prosjektledelsesforpliktelsene som leverand\u00f8ren har for systemutvikling i f\u00f8lgende artikkel.<\/p>\n\n\n\n<p>Relatert artikkel: <a href=\"https:\/\/monolith.law\/corporate\/project-management-duties\">Hva er prosjektledelsesforpliktelser i systemutvikling?<\/a><\/p>\n\n\n\n<p>Med andre ord, det er n\u00f8dvendig \u00e5 n\u00f8ye vurdere p\u00e5 forh\u00e5nd om det er mulig \u00e5 legge skylden p\u00e5 brukeren som ensidig nekter \u00e5 betale. Hvis vi ser p\u00e5 tidligere rettsavgj\u00f8relser, er det mange tilfeller der leverand\u00f8ren opprinnelig saks\u00f8kte for betaling, men brukeren mots\u00f8kte med krav om gjenoppretting til den opprinnelige tilstanden eller erstatning for skade.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Vurder_ogsa_om_det_virkelig_er_fordelaktig_for_virksomheten\"><\/span>Vurder ogs\u00e5 om det virkelig er fordelaktig for virksomheten<span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<p>Selv om leverand\u00f8rens argumenter blir akseptert og det er anerkjent i retten at det er mulig \u00e5 kreve betaling, hvis situasjonen eskalerer til rettssak, kan det forventes at det vil v\u00e6re vanskelig \u00e5 fortsette transaksjonene i fremtiden. I tillegg, selv om dine argumenter blir akseptert i retten, b\u00f8r du v\u00e6re forberedt p\u00e5 at det kan ta ganske lang tid f\u00f8r du faktisk mottar betaling. Hvis du ogs\u00e5 tar i betraktning at tid og kostnader for \u00e5 g\u00e5 til retten ikke er sm\u00e5, kan det ofte v\u00e6re bedre \u00e5 heller gj\u00f8re en innsats for \u00e5 finne et kompromiss.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Oppsummering\"><\/span>Oppsummering<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<p>Hvis en bruker ikke overholder betalingsforpliktelsene, vil det v\u00e6re n\u00f8dvendig \u00e5 gjennomg\u00e5 flere typer dokumenter for \u00e5 vurdere problemet juridisk. I tillegg er det ikke nok \u00e5 bare ha god dokumenth\u00e5ndtering, man m\u00e5 ogs\u00e5 vurdere hvilke organisatoriske risikoer og ulemper man kan st\u00e5 overfor hvis man til slutt bestemmer seg for \u00e5 g\u00e5 til s\u00f8ksm\u00e5l.<\/p>\n\n\n\n<p>Det er sant at grundig dokumenth\u00e5ndtering i det daglige vanligvis h\u00f8rer til p\u00e5 operativt niv\u00e5. Men hvis man bestemmer seg for \u00e5 g\u00e5 til s\u00f8ksm\u00e5l basert p\u00e5 lagrede dokumenter og materialer, kan det bli en alvorlig ledelsesbeslutning. I slike uvanlige situasjoner b\u00f8r man forst\u00e5 hele prosessen, samtidig som man anerkjenner at det er her samholdet og organisasjonsevnen mellom ledelsen og de operative blir satt p\u00e5 pr\u00f8ve.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>For en leverand\u00f8r som tar p\u00e5 seg systemutviklingsoppgaver, kan det i en viss forstand v\u00e6re den st\u00f8rste risikoen n\u00e5r brukeren ikke betaler for tjenesten, til tross for at den er levert. Kostnadene for  [&hellip;]<\/p>\n","protected":false},"author":32,"featured_media":62647,"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\/61449"}],"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=61449"}],"version-history":[{"count":2,"href":"https:\/\/monolith.law\/no\/wp-json\/wp\/v2\/posts\/61449\/revisions"}],"predecessor-version":[{"id":62646,"href":"https:\/\/monolith.law\/no\/wp-json\/wp\/v2\/posts\/61449\/revisions\/62646"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/monolith.law\/no\/wp-json\/wp\/v2\/media\/62647"}],"wp:attachment":[{"href":"https:\/\/monolith.law\/no\/wp-json\/wp\/v2\/media?parent=61449"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/monolith.law\/no\/wp-json\/wp\/v2\/categories?post=61449"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/monolith.law\/no\/wp-json\/wp\/v2\/tags?post=61449"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}