Wat is de wetgeving bij niet-betaling voor systeemontwikkeling?
Voor leveranciers die systeemontwikkelingswerkzaamheden op zich nemen, is het grootste risico misschien wel dat de gebruiker niet betaalt, ondanks dat het product is geleverd. De kosten voor systeemontwikkeling bestaan grotendeels uit geschoolde werknemers, waaronder programmeurs, waardoor de personeelskosten vaak hoog zijn. Het niet kunnen innen van omzet kan soms een kwestie van leven of dood worden. In dit artikel zullen we, uitgaande van het scenario waarin de gebruiker niet reageert op de betaling van de vergoeding, de zaken die de leverancier moet overwegen vanuit een juridisch perspectief bespreken.
Allereerst, controleer of het mogelijk is om een vergoeding te vragen
- De leverancier heeft het product geleverd aan de gebruiker, maar de gebruiker accepteert de levering niet, waardoor de facturatie wordt vertraagd
- Ondanks de perceptie dat de acceptatie voltooid was, is er een discrepantie met de perceptie van de gebruiker, die weigert te betalen
Dit zijn situaties die in de praktijk zeker kunnen voorkomen.
Daarnaast, in de terminologie van systeemontwikkeling, wordt het proces waarbij de gebruiker de specificaties van het voltooide systeem controleert en de levering accepteert, ‘acceptatie’ genoemd. De betekenis van deze ‘acceptatie’ en de zaken die overwogen moeten worden als de voortgang niet bevredigend is, worden in detail uitgelegd in het volgende artikel.
Gerelateerd artikel: Toepassingsgebied van de clausule voor veronderstelde acceptatie in systeemontwikkeling[ja]
Hoewel de algemene uitleg over de acceptatie zelf wordt overgelaten aan het bovenstaande artikel, is het noodzakelijk om te overwegen of de acceptatie door de gebruiker juridisch voltooid kan worden genoemd, rekening houdend met de bepalingen van de ‘veronderstelde acceptatieclausule’.
Met dit in gedachten, zijn de eerste punten die overwogen moeten worden in het geval dat de gebruiker weigert te betalen, de volgende:
- Is het werk in de eerste plaats voltooid, of is het nog niet voltooid?
- Kan de garantie voor gebreken (Artikel 635 van het Japanse Burgerlijk Wetboek) worden toegepast of niet?
De reden waarom de bovenstaande twee punten eerst moeten worden gecontroleerd, is dat als het werk niet is voltooid en de garantie voor gebreken (Artikel 635 van het Japanse Burgerlijk Wetboek) niet van toepassing is, er geen verwachting is dat de betaling zal worden gedaan, zelfs als een rechtszaak wordt aangespannen.
Dus, wat moet de verantwoordelijke persoon aan de kant van de leverancier specifiek onderzoeken om de bovenstaande twee punten te overwegen? Laten we eens kijken welke documenten moeten worden gecontroleerd.
Documenten die moeten worden gecontroleerd om de mogelijkheid van vergoeding aan te vragen
Leveringsbon Als er geen leveringsbon is, wordt aangenomen dat de levering nog niet is voltooid en dat het werk nog niet is afgerond. |
Document dat de resultaten van de inspectie meldt Dit is het belangrijkste document bij het beoordelen of een taak als voltooid kan worden beschouwd. Daarnaast is het ook goed om te controleren hoe de ‘deemed acceptance clause’ is vermeld in het contract, vooral als de inspectie is uitgesteld vanwege de gebruiker. |
Taakbeheer overzichtstabel Dit document geeft inzicht in welke problemen er tot nu toe zijn gevonden en welke maatregelen er zijn genomen. Het is ook een document om de status van problemen en defecten die na de levering aan het licht zijn gekomen, en de status van de reparaties te begrijpen. |
Vereisten specificatiedocument, ontwerpdocument en wijzigingsbeheerdocument, notulen van verschillende vergaderingen, enz. Door te verduidelijken welk begrip de gebruiker en de leverancier oorspronkelijk hadden, wordt duidelijk wat als een probleem of defect moet worden beschouwd. |
Overigens, hoe het beheer van wijzigingen in de specificaties van het te ontwikkelen systeem en de methode voor het opstellen van wijzigingsbeheerdocumenten worden beheerd, wordt in detail uitgelegd in een apart artikel.
Gerelateerd artikel: Hoe veranderingen in systeemontwikkeling te beheren vanuit een juridisch perspectief[ja]
Opzeggingsbericht of document dat de intentie van de gebruiker vermeldt Dit is een manier om te weten wat de intentie van de gebruiker is als hij niet verder wil gaan met de inspectie (of niet wil betalen voor de vergoeding). |
Controleer vervolgens hoeveel u in rekening kunt brengen
Het bedrag dat u in rekening kunt brengen, staat in principe vermeld in het contract. Echter, als er na het feit wijzigingen in de specificaties zijn aangebracht, kan het zijn dat er geen adequaat contract (of een document van vergelijkbare aard) beschikbaar is. De methode voor het herberekenen van de offerte op basis van latere redenen zoals wijzigingen in specificaties en toevoegingen van functies wordt in detail uitgelegd in het volgende artikel.
Gerelateerd artikel: Is het mogelijk om het geschatte bedrag voor systeemontwikkeling achteraf te verhogen?[ja]
Hoewel de methode voor het herberekenen van de offerte zoals beschreven in dit artikel is, vooral vanuit het oogpunt van het overwegen van de mogelijkheid van een verhoging van het factuurbedrag, zou men moeten kijken naar:
- De aanwezigheid en inhoud van de offerte voor extra ontwikkeling en functiecorrecties
- De reactie van de gebruiker op de offerte
- De aanwezigheid van een overeenkomst over de situatie die extra ontwikkeling en functiecorrecties veroorzaakt, zoals vermeld in de lijst met taakbeheer, en het bedrag daarvan
Met andere woorden, het proces bestaat uit het onderzoeken of er overeenstemming was met de gebruiker over het punt van “het plaatsen van een bestelling voor dat bedrag” (met andere woorden, of er een contract is gesloten).
Ten slotte, overweging van kwesties bij het daadwerkelijk voeren van een rechtszaak
Let op de mogelijkheid van een tegenvordering
In systeemontwikkeling is het niet ongebruikelijk dat wanneer een gebruiker of leverancier een rechtszaak aanspant tegen de andere partij, deze op zijn beurt een tegenvordering instelt. Dit betekent dat er ook enige grieven kunnen zijn aan de kant van de gebruiker in situaties waarin er geen betaling van vergoedingen plaatsvindt.
Systeemontwikkeling vereist in de eerste plaats dat de gebruiker verschillende verplichtingen nakomt, maar het is belangrijk om niet te vergeten dat de leverancier, als expert in systeemontwikkeling, een breed scala aan discretie en grote verantwoordelijkheid draagt. We hebben de projectmanagementverplichtingen die de leverancier heeft ten aanzien van systeemontwikkeling in detail uitgelegd in het volgende artikel.
Gerelateerd artikel: Wat zijn de projectmanagementverplichtingen in systeemontwikkeling?[ja]
Met andere woorden, het is noodzakelijk om van tevoren goed na te denken over de vraag of het mogelijk is om de schuld te leggen bij de gebruiker die eenzijdig weigert te betalen. Als we kijken naar eerdere rechtszaken, zijn er veel gevallen waarin de leverancier oorspronkelijk een rechtszaak aanspande om betaling te eisen, maar de gebruiker op zijn beurt een verplichting tot herstel van de oorspronkelijke staat of een vordering tot schadevergoeding instelde.
Ook moet worden overwogen of er daadwerkelijk zakelijke voordelen zijn
Zelfs als de argumenten van de leverancier worden geaccepteerd en het mogelijk is om betaling te eisen in een rechtszaak, als de situatie escaleert tot een rechtszaak, is het te verwachten dat het in de praktijk moeilijk zal zijn om toekomstige transacties voort te zetten. Bovendien, zelfs als uw argumenten worden geaccepteerd in een rechtszaak, moet u erop voorbereid zijn dat het aanzienlijk wat tijd kan kosten voordat u daadwerkelijk betaling ontvangt. Als u ook rekening houdt met de tijd en kosten die gepaard gaan met het voeren van een rechtszaak, kan het vaak beter zijn om inspanningen te leveren om een compromis te vinden.
Samenvatting
Als een gebruiker weigert een beloning te betalen, vereist een juridische beoordeling van het probleem de controle van verschillende soorten documenten. Bovendien is het niet voldoende om alleen een grondig documentbeheer te hebben, maar moet ook worden overwogen welke organisatorische risico’s en nadelen er zijn als uiteindelijk wordt besloten om een rechtszaak aan te spannen.
Het is waar dat het grondig beheren van documenten op dagelijkse basis meestal een taak is op operationeel niveau. Echter, als het besluit wordt genomen om een rechtszaak aan te spannen op basis van opgeslagen documenten en materialen, kan dit een belangrijke managementbeslissing worden. Het is belangrijk om te begrijpen dat in dergelijke onregelmatige situaties de cohesie en organisatorische kracht van zowel het operationele als het managementniveau op de proef worden gesteld. Het is raadzaam om een goed begrip te hebben van het hele proces.
Category: IT
Tag: ITSystem Development