Als je geen backup maakt, dan ben je gewoon af. Een prutser.

Dat moet je inderdaad altijd doen maar dat heeft er helemaal niets mee te maken. De data werd overschreven door een bug in de koppeling (is later aangepast).
Het punt is dat bijna elke leverancier afdwingt niet aansprakelijk te zijn anders mag je de software niet gebruiken (Zie bv ook Microsoft EULA)
Ongelooflijk dat het Hof meeging in het backup verhaal.

Wat als de backup hierdoor niet werkt ?

Het verhaal is dus: ben je als software leverancier verantwoordelijk voor de gevolgen van gemaakte fouten, of mag je
eerst gaan kijken welke fouten de klant eventueel gemaakt heeft en als je die kunt vinden de schuld bij de klant leggen.
Het antwoord daarop is dus: het laatste. Helaas, want daardoor komen software leveranciers keer op keer weg met
het maken van fouten en worden ze niet gestimuleerd of gedwongen die te voorkomen.

De enige reden dat je een backup maakt, is dat je hem in geval van nood kan herstellen.

Dus als je backup's maakt en je controleert niet regelmatig of ze bruikbaar zijn voor het doel "terugzetten" dan ben je misschien ook een prutser? :-)

Erg prettig vonnis, want dan kan er mooi weer een regel uit de algemene voorwaarden die zelden worden gelezen. (tenzij hoger beroep natuurlijk.) Algemene voorwaarden zijn niet algemeen bindend, maar wetten en uitspraken wel.

Blijft natuurlijk wel netjes en service om als software leverancier je klanten erop te wijzen. Alsmede commercieel, want kan meerwerk uit komen als de klant zelf niet bekwaam is of geen tijd heeft om aan backups te denken (is het een klant die te veel pingelt en elke cent in twee bijt, na de oplevering natuurlijk).

Bij mij staat het op mijn nieuwe kerstmenu onder de toetjes. Niet verstopt in algemene voorwaarden. De zaak draait nooit op die ene deal, maar op de continuïteit.

Het gepruts en onverantwoordelijk gedrag bij de afnemende partij willen verhalen op een toeleverancier?
Je hebt dan echt niets van eigen verantwoordelijkheid begrepen.

Koop een auto en rijd hem zelf opzettelijk aan gort. Niemand die het normaal vindt dat de schuld bij de autoverkoper ligt.
Probeer je dat wel te doen dan grenst dat aan oplichting.

Niet helemaal, In de database hadden ze users vanaf record 15000
Ze gingen users inserten vanaf record 7000, als je dan meer dan 8000 records invoert ga je vanzelf voorbij record 15000.

a) die rekensom hadden ze kunnen maken
b) beide startwaardes hebben ze zelf bedacht

Dat stukje middleware deed enkel wat er gevraagd werd "schrijf record X weg"

Nee hoor. Het stuur zat vast door een fabricagefout. Hierdoor kon de bocht niet worden genomen.

Inderdaad. Het gaat hier niet om iemand die opzettelijk de auto aan gort rijdt, maar om een auto waaraan door
toedoen van de fabrikant de remleidingen lek zijn, en de gebruiker krijgt een ongeluk waarna de fabrikant gaat
aanvoeren dat je toch echt voor iedere rit onder de auto moet kijken of er remolie gelekt is, en voordat je voluit
wegrijdt altijd een remproef moet doen op lage snelheid.
De klant blijft er mee zitten want "dat moet nou eenmaal iedereen die een auto heeft doen" en de fabrikant gaat
vrijuit met zijn lekke remleidingen.

backups, leuker kunnen we het niet maken.
en dan maak je een SQL backup van 200MB, en je hoster blijkt maar restore points te slikken die max 5MB zijn, hihi..

Bij Exact online download je de backup, maar moet je natuurlijk wel een fatsoenlijke verbinding hebben om die backup te downloaden.
een SQL backup van 200MB? ik kan me niet heugen dat ik zo'n kleine database gezien heb in ene live omgeving. :)

Zo simpel is het niet. Er is hier sprake van twee pakketten waar al het nodige in gebeurt en een koppeling tussen die pakketten van een leverancier die niet die pakketten levert. Voor de webwinkel wordt Magento gebruikt, voor de boekhouding Exact, en waar het hier over gaat is het leveren van een koppeling die gegevens van Magento naar Exact overbrengt.

Men hanteert voor debiteuren (klanten) klantnummers vanaf 3000 voor vaste klanten, en vanaf 7000 gastaccounts. Die worden in Magento aangemaakt en via de koppeling doorgegeven aan Exact. Crediteuren (leveranciers) bestaan alleen in Exact. Die worden vastgelegd in dezelfde tabel als de debiteuren, en die worden handmatig genummerd van 1-2999 en daarna verder vanaf 15000.

Omdat men over de 8000 gastaccounts heen ging in Magento werden er nummers van 15000 en hoger toegekend. Dat zijn nummers in de crediteurenreeks, maar daar heeft Magenta geen weet van, die kent de crediteuren niet. Dus ook zonder de koppeling had men al een probleem gekregen met nummers die in Magento aan een debiteur en in Exact aan een crediteur werden toegekend. Dat probleem is niet door de koppelingssoftware veroorzaakt, dat is een fout in de opzet van de nummering, of in het op tijd bijstellen van de nummertoekenningen in Magenta.

Wat de koppelingssoftware vervolgens deed was niets anders dan dat die van Magento doorkreeg dat (bijvoorbeeld) een gastaccount met nummer 15069 was aangemaakt, en dat gastaccount met het door Magento eraan toegekende nummer vastlegde in Exact. Alleen bestond dat nummer daar al voor een debiteur, en die werd overschreven. Maar de taak van die koppeling was wel degelijk om die nieuwe gastaccount met het toegekende nummer in Exact vast te leggen, en dat deed het. Het hof heeft dan ook geoordeeld dat de koppeling naar behoren functioneerde, die deed precies wat de bedoeling was.

De leverancier heeft hier niet de totale opzet voor de klant gemaakt, maar alleen een component erin geleverd. Als je verschillende onderdelen bij verschillende leveranciers betrekt en het geheel ook nog eens op een voor jou specifieke manier inricht dan ben je als klant toch echt zelf verantwoordelijk voor hoe het geheel samenwerkt.

Ze hebben maatwerkaanpassingen in de koppeling laten maken. Daar hadden ze vast wel in kunnen laten bouwen dat er geen crediteuren kunnen worden overschreven. Dan waren er nog steeds dingen vastgelopen, het nummerconflict was niet opgelost, alleen het overschrijven van gegevens was voorkomen. Dat hebben ze kennelijk verzuimd te regelen in hun maatwerkaanpassingen, want als dat geregeld was hadden ze dat ongetwijfeld met succes kunnen gebruiken in de rechtzaken, en dat is niet gebeurd.

Wat dan overblijft is dat ze zelf verantwoordelijk waren om op tijd in Magenta te regelen dat de nummers in de 15000-reeks zouden worden overgeslagen. Als ze dat hadden gedaan was er niets misgegaan. Maar ook dat hebben ze verzuimd te doen.

Ik zie heel veel verzuim bij de webwinkel. Verzuim om dingen die ze zelf inrichten ook goed te doen, verzuim om dingen die in de maatwerkaanpassingen van de koppeling kunnen worden meegenomen ook mee te nemen, verzuim om op tijd conflicten in de nummering die door hun eigen keuzes zijn veroorzaakt op te lossen, en tenslotte verzuim om backups te maken zodat fouten relatief makkelijk hersteld kunnen worden.

Mooie samenvatting, bedankt voor de moeite.

Wat je beschrijft is typisch hoe grotere dingen fout gaan - een stapeling van individuele keuzes die geen van alle zichtbaar fataal zijn, totdat dan alles samenkomt en het gevolg misgaat .

Met de natte vinger kun je dan herkennen dat er niemand was die zicht had op het totaalplaatje .
Ergens heeft iemand de "vrije" nummers toegewezen voor crediteuren, zonder zicht op de 'gast' accounts vanuit Magento die daar vroeger of later overheen zouden nummeren.
Of misschien die keuze in een heel vroege fase gemaakt ,en is de persoon die dat wist (en wie weet wel riep "boven de 8000 klanten moet er gehernummered worden, maar dat duurt nog een tijd" ) weer vertrokken.

Of misschien was die persoon ook eenmalig ingehuurd om "nieuwe crediteuren aan te maken" , en dan zit je er niet om de hele IT architectuur voor de komende 3/5 jaar op de schop te nemen.

Terecht dat die overall verantwoordelijkheid ligt bij de webshop , en als ze telkens een klusjesman inhuren om een enkel klusje te doen eindig je met een lappendeken van dingetjes die bij elkaar soms misgaan.

Als je het netjes doet als 'klusjesman' waarschuw je als je (andere) ziet die op termijn een probleem gaan zijn. Bij een klant die op de centen is, is dat zinloos. Die wil het niet horen en denk dat de klusjesman alleen maar zit te praten om meer uren te kunnen maken.
(Klant heeft ook niet altijd ongelijk - garages en aannemers hebben het vertrouwen in de eerlijkheid van lieden die waarschuwen voor 'toekomstige problemen' nogal ondermijnd ).

Wat zou de advocaat eigenlijk de webshop hebben voorgespiegeld over de kansen ? Een nette advocaat hoort z'n klant ook advies te geven over hoe de kansen staan en of een zaak enige zin heeft.
Misschien dat de webshop pislink was en riep "maakt niet uit of we verliezen, ik wil die gasten laten zweten" . Of misschien dat de advocaat ook lekker liep te liegen - winst of verlies, de advocaat schrijft uren - dat er "best een sterke zaak lag" .