Vad är lagen om obetald ersättning för systemutveckling?
För leverantörer som tar på sig systemutvecklingsuppdrag, kan en av de största riskerna vara att “användaren inte betalar för tjänsten trots att den har levererats”. Kostnaden för systemutveckling består till stor del av kvalificerad personal, som programmerare, vilket ofta innebär höga personalkostnader. Om försäljningsintäkterna inte kan samlas in kan det ibland bli en fråga om företagets överlevnad. I denna artikel kommer vi att diskutera vad leverantörer bör överväga när användaren inte svarar på betalningskrav, ur ett juridiskt perspektiv.
Först, bekräfta om det är möjligt att begära betalning
- Trots att leverantören har levererat resultatet till användaren, accepterar inte användaren leveransen, vilket leder till att betalningskravet försenas.
- Trots att man trodde att godkännandet var klart, finns det någon form av missförstånd mellan leverantören och användaren, och användaren vägrar att betala.
Dessa situationer kan mycket väl uppstå i verkligheten.
Notera att när användaren granskar specifikationerna för det färdiga systemet och accepterar leveransen, kallas detta för “godkännande” i systemutvecklingstermer. Betydelsen av detta godkännande och vad man bör överväga när framstegen inte är tillfredsställande förklaras i detalj i följande artikel.
Relaterad artikel: Vad är godkännande och antagande av godkännande i systemutveckling?[ja]
En övergripande förklaring av godkännandet i sig lämnas till ovanstående artikel, men det är nödvändigt att överväga om användarens godkännande kan anses vara slutfört enligt lagen, med hänsyn till bestämmelserna om “antagande av godkännande”.
Med detta i åtanke, de första punkterna att överväga när användaren inte betalar är följande:
- Är arbetet färdigt eller fortfarande ofullständigt?
- Kan ansvar för fel (japansk civil lag 635) tillämpas eller inte?
Anledningen till att vi bör bekräfta ovanstående två punkter först är att om arbetet inte är färdigt och ansvar för fel (japansk civil lag 635) inte tillämpas, kan vi inte förvänta oss att få betalt, även om vi stämmer.
Så, vad bör leverantörens representant undersöka för att överväga ovanstående två punkter? Låt oss titta på vilka dokument som bör kontrolleras nedan.
Dokument att kontrollera för att undersöka möjligheten att begära ersättning
| Leveransnota Om det inte finns någon leveransnota, antas det att leveransen inte har slutförts och att arbetet inte är färdigt. |
| Dokument som meddelar resultatet av godkännandet Detta är det viktigaste dokumentet när man avgör om ett arbete kan betraktas som slutfört. Dessutom, om godkännandet har skjutits upp på grund av användarens omständigheter, bör du också kontrollera hur “presumed acceptance clause” var formulerad i kontraktet. |
| Uppgiftshanteringsschema Detta dokument ger information om vilka problem som har identifierats hittills och vilka åtgärder som har vidtagits. Det är också ett dokument för att förstå situationen för fel och problem som upptäckts efter leverans, och statusen för deras reparation. |
| Kravspecifikationer, design dokument och ändringshanteringsdokument, mötesprotokoll etc. Genom att klargöra vilken förståelse användaren och leverantören ursprungligen hade, blir detta dokument för att klargöra vad som ska kallas ett fel eller problem. |
För mer detaljerad information om hur man hanterar ändringar i systemets specifikationer och hur man skapar ändringshanteringsdokument, se en separat artikel.
Relaterad artikel: Hur man hanterar ändringar i systemutveckling ur ett juridiskt perspektiv
| Uppsägningsmeddelande eller dokument som beskriver användarens avsikt Detta är ett sätt att förstå vad användaren avser med att inte gå vidare med godkännandet (eller att inte betala ersättningen). |
Nästa, bekräfta hur mycket du kan begära i ersättning
Principen är att beloppet som kan begäras ska anges i kontraktet. Men om specifikationer ändras efteråt kan det hända att det inte finns något ordentligt kontrakt (eller ett dokument som motsvarar det). Vi förklarar i detalj hur man räknar om en offert baserat på efterföljande skäl som ändringar i specifikationer och tillägg av funktioner i följande artikel.
Relaterad artikel: Är det möjligt att öka uppskattningen för systemutveckling efteråt?[ja]
Metoden för att räkna om en offert är som beskrivet i denna artikel, men särskilt från perspektivet att överväga om det är möjligt att öka fakturabeloppet,
- Förekomsten och innehållet i offerten för ytterligare utveckling och funktionskorrigeringar
- Användarens reaktion på offerten
- Förekomsten av ett avtal om beloppet i samband med situationen som orsakade ytterligare utveckling och funktionskorrigeringar som anges i problemhanteringslistan
kommer att vara de huvudsakliga punkterna att titta på. Med andra ord kommer processen att undersöka om det fanns en överensstämmelse mellan användaren och “att beställa tjänsten för det beloppet” (det vill säga, om ett kontrakt kan sägas ha ingåtts).
Slutligen, övervägande av frågor vid faktisk rättegång
Var uppmärksam på möjligheten till motkrav
I systemutveckling är det inte ovanligt att om en part (användare eller leverantör) stämmer den andra parten, kan den andra parten i sin tur lägga fram ett motkrav. Det vill säga, det finns någon form av invändning från användarens sida när det gäller att inte betala ersättning.
Från början bär användarsidan olika samarbetsförpliktelser i systemutveckling, men först och främst bör vi inte glömma att leverantören, som en expert på systemutveckling, bär ett brett utrymme för skön och stort ansvar. Vi har detaljerat förklarat leverantörens projektledningsansvar för systemutveckling i följande artikel.
Relaterad artikel: Vad är projektledningsansvaret i systemutveckling?[ja]
Med andra ord, om det är möjligt att skylla på användarsidan som ensidigt vägrar att betala ersättning, bör detta noggrant övervägas i förväg. Om vi ser på tidigare rättsfall, finns det många fall där leverantören ursprungligen stämde för att kräva ersättning, men användaren i sin tur krävde återställande av status quo och skadestånd.
Överväg också om det verkligen är fördelaktigt för företaget
Även om leverantörens argument accepteras och det erkänns i rättegången att det är möjligt att kräva ersättning, om situationen blir komplicerad till den grad att det leder till en rättegång, kan det förväntas att det blir svårt att fortsätta affärstransaktioner i framtiden. Dessutom, även om ditt argument erkänns i rättegången, bör du vara beredd på att det kan ta ganska lång tid innan du faktiskt kan ta emot ersättning. Om du också tänker på att kostnaden och besväret med att gå till rättegång inte är litet, kan det ofta vara bättre och mer rimligt att anstränga sig för att hitta en kompromiss.
Sammanfattning
Om en användare inte betalar den utlovade belöningen, krävs det en juridisk granskning av flera typer av dokument. Dessutom räcker det inte bara med att ha en noggrann dokumenthantering, utan det krävs också en bedömning av vilka organisatoriska risker och nackdelar man kan stå inför om man till slut beslutar att gå till domstol.
Visst, noggrann dokumenthantering i vardagen tillhör vanligtvis arbetsuppgifterna på fältet. Men om man beslutar att gå till domstol baserat på de lagrade dokumenten och materialen, kan det bli en betydande affärsbeslut. I sådana oregelbundna situationer bör man förstå hela processen, tillsammans med insikten att det är här som fältets och ledningens sammanhållning och organisatoriska styrka testas.
Category: IT
Tag: ITSystem Development
