image

Waarom is het maken van back-ups relevant bij schade door een fout van een softwareleverancier?

woensdag 20 oktober 2021, 10:42 door Arnoud Engelfriet, 20 reacties

Heb jij een interessante vraag op het snijvlak van privacy, cybersecurity en recht? Stuur je vraag naar juridischevraag@security.nl. Elke week geeft ict-jurist Arnoud Engelfriet in deze rubriek antwoord.

Juridische vraag:Vorige week las ik: Een webshop die geen back-ups van haar boekhoudgegevens maakte, en door een probleem met een softwarekoppeling klantgegevens verloor, heeft de rechtszaak tegen de leverancier van de koppeling verloren. De koppeling bleek gegevens van crediteuren in het boekhoudprogramma te overschrijven met debiteurenboekingen. Dat lijkt mij een ernstige fout, maar omdat de webshop geen backups had moest ze toch alles zelf betalen. Hoe zit dat juridisch?

Antwoord: Inderdaad: volgens het Gerechtshof staat het vast dat de webshop geen back-ups maakte en heeft de softwareleverancier met recht aangevoerd dat de webshop zelf verantwoordelijk is voor het regelmatig maken van back-ups. "Dat zij dat achterwege heeft gelaten, terwijl het wel mogelijk was, is dan ook een omstandigheid die haar valt toe te rekenen", aldus het hof.

Het gaat concreet om een koppeling tussen het bekende webshoppakket Magento en Exact Online, waardoor de transacties van de Magento webshop worden doorgestuurd naar de boekhoudsoftware van Exact. Meelezende QA specialisten mogen even wegkijken, voor de rest:

Het boekhoudprogramma maakt gebruik van een tabel van nummering waarbij voor debiteuren en crediteuren dezelfde tabel wordt gebruikt. Beide groepen krijgen om die reden een verschillend startnummer. Voor debiteuren (klanten met een account en gastklanten zonder een account) is in dit geval gekozen voor een nummer beginnend met 3.000 respectievelijk 7.000 en voor crediteuren beginnend met 1-2.999 en vanaf 15.000. De crediteuren moeten handmatig worden ingevoerd, de debiteuren (zowel de bestellingen van klanten met een account als die van gastklanten) worden door de koppeling automatisch in het boekhoudprogramma ingevoerd.

Deze wijze van scheiden van relaties staat onder programmeurs ook wel bekend als een WTF want op deze manier is het natuurlijk mogelijk dat het aantal aankopen zo oploopt dat je de 15.000 aantikt en dat je debiteur dan een crediteur is. En dat gebeurde ook, omdat er een foutje zat in het toekennen van nummers bij klanten die als gast bestellen:

Hallo … De gast accounts beginnen bij 7000. Inmiddels hebben we al meer dan 8000 gast accounts, waardoor je dus uit komt op de nummering van de crediteuren.

Dit hoort natuurlijk niet te gebeuren, en pijnlijk voor de webshop was vervolgens dat men geen back-up had van de relevante tabellen zodat het een berg werk was om alle debiteuren en crediteuren weer in ere te herstellen. Is dit nu het soort fout waar je voor aansprakelijk bent vanuit je zorgplicht als ICT-er? Helaas komt het Hof niet aan die vraag toe, maar ze bevestigt wel dat we zoiets best “eigen schuld” kunnen noemen.

Iedereen die met digitale gegevens werkt in de bedrijfsvoering, moet daar gewoon back-ups van hebben. Want of het nou gaat om ransomware, dikke vingers of een API koppeling die debiteuren moet invoeren maar die soms als crediteur aanmerkt, als je die data kwijt bent dan heb je een enórm probleem.

Juridisch gezien kom je dan uit bij "eigen schuld" (art. 6:101 BW): weliswaar ontslaat dat de leverancier niet van aansprakelijkheid, maar hij hoeft minder van de schade te vergoeden omdat de gevolgen mede aan de webwinkel te wijten zijn.

Het is aannemelijk dat geen handmatig herstel met de gevorderde kosten nodig was geweest als de door [de webwinkel] gestelde tekortkoming achterwege zou zijn gebleven (zo die na bewijslevering zou komen vast te staan). Maar dat geldt ook indien [de webwinkel] zelf de nodige zorgvuldigheid zou hebben betracht door een back-up te maken. De kosten van de advocaat in verband met het verhaal van herstelkosten bij [de leverancier] zouden ook niet gemaakt zijn.

Je kunt je natuurlijk afvragen of de leverancier niet meer had moeten doen. Nee, niet in dit geval:

Het hof betrekt daar ook bij (i) dat het ging om een standaardkoppeling tegen een lage prijs zonder abonnement, (ii) dat de koppeling als zodanig jarenlang goed heeft gefunctioneerd, (iii) dat [de webwinkel] zelf voor Exact Online heeft gekozen, (iv) dat zij zich in de werking en de beperkingen daarvan kennelijk niet voldoende heeft verdiept, (v) dat de koppeling is hersteld en (vi) dat [de webwinkel] niet onderbouwd heeft gesteld dat zij door het tijdelijk kwijtraken van enkele gegevens van crediteuren (andere financiële) problemen heeft ondervonden.

Met name dat laatste geeft voor mij de doorslag: er zijn geen daadwerkelijke problemen, alleen maar rotzooi die opgeruimd moest worden omdat er geen backup was. Heel vervelend, maar dát is dan het gevolg van je eigen schuld.

Ondertussen blijft wel open de vraag of de leverancier beter had moeten programmeren, bijvoorbeeld een check dat het debiteurennummer altijd kleiner dan 15.000 had moeten zijn. Als je een koppeling met Exact verkoopt, en die heeft deze rare constructie in haar database-tabellen, dan moet je zulke dingen wel doen lijkt me. Maar kennelijk komt het weinig voor dat Exact Online-gebruikers meer dan 8000 klanten zonder registratie hebben?

Arnoud Engelfriet is Ict-jurist, gespecialiseerd in internetrecht waar hij zich al sinds 1993 mee bezighoudt. Hij werkt als partner bij juridisch adviesbureau ICTRecht. Zijn site Ius mentis is één van de meest uitgebreide sites van Nederland over internetrecht, techniek en intellectueel eigendom. Hij schreef twee boeken, De wet op internet en Security: Deskundig en praktisch juridisch advies.

Reacties (20)
20-10-2021, 11:23 door Bitje-scheef
Ondertussen blijft wel open de vraag of de leverancier beter had moeten programmeren, bijvoorbeeld een check dat het debiteurennummer altijd kleiner dan 15.000 had moeten zijn. Als je een koppeling met Exact verkoopt, en die heeft deze rare constructie in haar database-tabellen, dan moet je zulke dingen wel doen lijkt me. Maar kennelijk komt het weinig voor dat Exact Online-gebruikers meer dan 8000 klanten zonder registratie hebben?

Zeer terechte opmerking, die in mijn ogen, door de rechter had mogen worden meegenomen in de uitspraak.
Helaas komen dit soort software/DB struikelingen wel vaker voor, vooral bij uitgebreide ERP systemen.
Altijd goed voor vuurwerk.
20-10-2021, 11:27 door Anoniem
Ik vind de stelling van de rechter in deze heel redelijk, ik heb vroeger op de administratie gewerkt en daar werden dagelijks incremental backups gemaakt en wekelijks full backups. Dat ging nog op tape en de tapes gingen off-site.

Waar ik me meer zorgen over maak, is de manier waarop de tabellen bij Exact Online zijn ingericht. Dat je 1 tabel gebruikt voor zowel de debiteuren als de crediteuren, vind ik logisch, de basisgegevens voor beide groepen zijn (nagenoeg) identiek. Maar het onderscheid tussen een debiteur en een crediteur maken, door de waarde van het nummer, is om te huilen. 1 extra kolom met als enige mogelijke waardes de D en de C, maakt het hier geschetste probleem onmogelijk. Misschien dat Exact daar iets aan moet doen en dat Exact een deel van de kosten hoort te vergoeden, omdat hier een simpele oplossing was geweest, dat het probleem al vanaf dag 1 in de kiem had kunnen smoren?
20-10-2021, 11:48 door Krakatau
Het gaat concreet om een koppeling tussen het bekende webshoppakket Magento en Exact Online, waardoor de transacties van de Magento webshop worden doorgestuurd naar de boekhoudsoftware van Exact.

Magento? Dus PHP-stack? Magento + PHP-stack heeft een slechte reputatie als het om veiligheid gaat. De keuze daarvoor in combinatie met het niet maken van backups is niet erg professioneel.
20-10-2021, 12:15 door Anoniem
Ik snap niet helemaal hoe de database gestructureerd is, maar voor een 16 bit computer is dit een hele logische oplossing van Exact. Ze zijn opgericht in 1984 volgens wikipedia.

Nu zou je overal 64 bit registers gebruiken als je nieuwe software ontwerpt, maar dit moeten legacy ontwerp keuzes zijn geweest en het is dan heel moeilijk om zo iets te veranderen zonder alles helemaal opnieuw te ontwerpen en te schrijven.

Ook op moderne hardware kan een programma uit zijn geheugen lopen en wat er dan gebeurt is nooit fraai om te zien. Je hebt het dan over gekillde processen op een willekeurig moment of andere programma's die vastlopen omdat ze geen geheugen meer kunnen alloceren.
20-10-2021, 12:48 door Anoniem
De vraag is natuurlijk wat de klant in dit geval gehad had aan een backup.
Kennelijk is het probleem niet meteen ontdekt toen de 1e debiteur met nummer 15000 de bijbehorende crediteur
overschreef. Want als het om maar 1 zo'n geval ging dan was het handmatig herstel niet zo kostbaar geweest.
Kennelijk heeft het een aardig tijdje doorgemodderd voor men er achter was dat er iets fout was en wat dat dan was.

Wat heb je dan nog aan die backup? Gewoon de status van (bijvoorbeeld) 3 weken geleden terug zetten was vast
geen oplossing geweest want dan was alles wat in die 3 weken gebeurd is weg.
En wat dan? De backup op een 2e omgeving terug zetten en dan stuk voor stuk alle crediteur records herstellen?
Dat was vast ook een boel handwerk geweest.
En het maken van een programma/script wat dat automatisch regelt vergt een hoge mate van deskundigheid mbt de
interne werking van dat Exact pakket om dat te kunnen doen zonder dat er krititeke fouten in de data integriteit komen.

Nog maar los van het feit dat de oorzaak van het probleem (domme keuzes bij de nummering) dan ook nog niet
is opgelost, dus dat gaat ook nog weer moeite en geld kosten.

Er is duidelijk sprake van een faal, maar wat de kosten beperkende rol van de aanwezigheid van een backup is bij
het oplossen daarvan, dat betwijfel ik.
20-10-2021, 12:50 door Anoniem
Door Krakatau:
Magento? Dus PHP-stack? Magento + PHP-stack heeft een slechte reputatie als het om veiligheid gaat. De keuze daarvoor in combinatie met het niet maken van backups is niet erg professioneel.
Volgens mij ging het niet over een backup van Magento (die zal er vast ook niet zijn) maar over een backup van Exact.
Daar in waren immers de gegevens overschreven. Gegevens die Magento waarschijnlijk niet aangeleverd heeft maar
die handmatig zijn ingevoerd direct in Exact.
20-10-2021, 14:59 door Anoniem
Door Anoniem: De vraag is natuurlijk wat de klant in dit geval gehad had aan een backup.
Dit is precies een argument dat ik aangehaald zou hebben. Een backup is om menselijk/technisch falen te herstellen, dit is een misprogrameersel. Niet een tabel die "oeps" weggegooid was, of een disk die corrupt is geraakt, maar een bug in software die pas na weken, maanden of misschien jaren te ontdekken was. Ja, dan heb je niets meer aan backups.
20-10-2021, 20:27 door Anoniem
Door Anoniem:
Door Anoniem: De vraag is natuurlijk wat de klant in dit geval gehad had aan een backup.
Dit is precies een argument dat ik aangehaald zou hebben. Een backup is om menselijk/technisch falen te herstellen, dit is een misprogrameersel. Niet een tabel die "oeps" weggegooid was, of een disk die corrupt is geraakt, maar een bug in software die pas na weken, maanden of misschien jaren te ontdekken was. Ja, dan heb je niets meer aan backups.

Een misprogrameersel is ook een menselijk/technisch falen.

Als je pas na maanden/jaren erachter komt dat er iets mis is met bepaalde data, dan is dat blijkbaar geen belangrijke data.
Net zoals je backups hoort maken van belangrijke data, hoor je ook integriteitschecks van data te doen die niet corrupt mag worden. Of monitoring van services die niet onbeschikbaar mogen zijn. Dat hoort een standaardpraktijk te zijn!

Ooit al eens een library gebruikt die kan rekenen met datums? Je wil niet weten hoeveel crap er is dat niet eens weet dat er schrikkeljaren bestaan, etc.
De meeste programmeurs weten echt niet wat ze aan het doen zijn en zijn al blij als iets compiled zonder "errors", laat staan "warnings".
21-10-2021, 02:15 door Anoniem
Mooi vonnis want net als de rechter vind ik ook dat als je bedrijfsmatige software gebruikt, de simpele vraag over backups inmiddels wel algemeen toch eens naar boven had moeten komen.

Tegelijk is de overwinning voor de softwareboer wel heel slecht voor het vertrouwen in softwareboeren in het algemeen. Toen ik mijn eerste Porsche kocht werd ik erop gewezen dat de auto weliswaar leuk kan gassen maar ook veel betere remmen heeft dan menig andere auto. Dus dat vooral in noodstopgevallen ik goed in de spiegel moest kijken omdat de auto achter me meer remweg nodig had. Een paar praktijktests later bewezen dat ook. Gaat dat mis dan kun je natuurlijk ook je geld niet terugkrijgen van de dealer. Logisch.

Met name bij oplevering van dynamische systemen is het toch ook wel een beetje een zorgplicht van een softwareboer om op backups te wijzen of uit te leggen wat redundancy is. Opleveren met enkel kijk maar het werkt en morgen ook nog dus de rest zoek je maar uit en hier is de factuur is dan wel door de rechter vastgesteld geen nalatigheid. Maar netjes is het ook niet. Veel klanten huren je juist in omdat ze zelf je kennis niet in huis hebben. Voor de softwareboer dus gefeliciteerd met je overwinning maar ook bedankt voor het dubbel wantrouwen dat ik later bij mijn eerste gesprek moet zien weg te nemen, cowboy met je manke debiteuren/crediteuren nummers!
21-10-2021, 08:57 door Anoniem
Ik zie hier een hoop reacties voorbij komen, met een dikke vinger naar hoe ExactOnline de debiteuren / crediteuren registreert.

Allereerst kan ik aangeven dat bewust voor 1 tabel is gekozen, omdat het ook mogelijk is dat een relatie zowel een debiteur als een crediteur is. Dit is handig wanneer je een verkoopfactuur met een inkoopfactuur wilt verrekenen.

Daarnaast heb je altijd issues wanneer meerdere systemen (in dit geval Exact en Magento) een debiteuren/crediteuren bestand laat beheren. Dat is geen goede zaak, maar als je niet anders kan, doe het dan wel goed.

Wat ik in dit geval niet begrijp, is dat er zo weinig ruimte is gelaten tussen een crediteuren nummering en debiteuren nummering. Het relatie nummer in Exact Online kan 18 posities bevatten, waarvan Magento heeft besloten (of de klant) om er maar 5 van te gebruiken. Dat is dan vragen om moeilijkheden.
21-10-2021, 10:50 door Anoniem
Door Anoniem:
Allereerst kan ik aangeven dat bewust voor 1 tabel is gekozen, omdat het ook mogelijk is dat een relatie zowel een debiteur als een crediteur is.
Dat is inderdaad een slimme beslissing. Ik ken systemen die 2 tabellen gebruiken en dat is gewoon niet fijn, je zit
altijd weer met die dubbele vermeldingen en ook is het lastig in allerlei queries.

Wat ik in dit geval niet begrijp, is dat er zo weinig ruimte is gelaten tussen een crediteuren nummering en debiteuren nummering. Het relatie nummer in Exact Online kan 18 posities bevatten, waarvan Magento heeft besloten (of de klant) om er maar 5 van te gebruiken. Dat is dan vragen om moeilijkheden.

Dat vond ik ook al raar. Ik ken Exact niet maar ik vond die grenzen tamelijk dom en willekeurig gekozen. Geen idee of dat een domme beslissing tijdens de implementatie, een default situatie of iets anders is.
Ik zou in ieder geval ook veel grotere ranges gebruikt hebben en ook zeker niet van die rare ranges.
Doe dan zo iets:
- crediteuren vanaf 1000000
- zelf ingevoerde debiteuren vanaf 2000000
- dynamisch gemaakte debiteuren (via de koppeling) vanaf 3000000

Dan kun je makkelijk zien wat je bij de hand hebt en loopt het voorlopig niet fout.
Komt het niet vaak voor dat je een debiteurnummer moet intypen dan kunnen nog langere nummers gebruikt worden, maar dit is een afweging want het is heel vervelend als je steeds lange nummers met heel veel nullen erin moet overtypen. Het aantal nullen moet in een oogopslag zichtbaar zijn en dan is 6 posities wel ongeveer het maximum.
21-10-2021, 11:40 door MathFox
Door Anoniem:
Door Anoniem: De vraag is natuurlijk wat de klant in dit geval gehad had aan een backup.
Dit is precies een argument dat ik aangehaald zou hebben. Een backup is om menselijk/technisch falen te herstellen, dit is een misprogrameersel. Niet een tabel die "oeps" weggegooid was, of een disk die corrupt is geraakt, maar een bug in software die pas na weken, maanden of misschien jaren te ontdekken was. Ja, dan heb je niets meer aan backups.
Je kunt de de backup restoren in een nieuwe Exact installatie en daaruit de overschreven crediteureninformatie exporteren. In je echte boekhouding hernummer je de nieuwe klanten (en past het klantnummer in hun facturen aan), daarna importeer je de zojuist geëxporteerde crediteurenkaarten.
21-10-2021, 12:59 door Anoniem
Door Anoniem:
Door Anoniem:
Allereerst kan ik aangeven dat bewust voor 1 tabel is gekozen, omdat het ook mogelijk is dat een relatie zowel een debiteur als een crediteur is.
Dat is inderdaad een slimme beslissing. Ik ken systemen die 2 tabellen gebruiken en dat is gewoon niet fijn, je zit
altijd weer met die dubbele vermeldingen en ook is het lastig in allerlei queries.

Wat ik in dit geval niet begrijp, is dat er zo weinig ruimte is gelaten tussen een crediteuren nummering en debiteuren nummering. Het relatie nummer in Exact Online kan 18 posities bevatten, waarvan Magento heeft besloten (of de klant) om er maar 5 van te gebruiken. Dat is dan vragen om moeilijkheden.

Dat vond ik ook al raar. Ik ken Exact niet maar ik vond die grenzen tamelijk dom en willekeurig gekozen. Geen idee of dat een domme beslissing tijdens de implementatie, een default situatie of iets anders is.
Ik zou in ieder geval ook veel grotere ranges gebruikt hebben en ook zeker niet van die rare ranges.
Doe dan zo iets:
- crediteuren vanaf 1000000
- zelf ingevoerde debiteuren vanaf 2000000
- dynamisch gemaakte debiteuren (via de koppeling) vanaf 3000000

Dan kun je makkelijk zien wat je bij de hand hebt en loopt het voorlopig niet fout.
Komt het niet vaak voor dat je een debiteurnummer moet intypen dan kunnen nog langere nummers gebruikt worden, maar dit is een afweging want het is heel vervelend als je steeds lange nummers met heel veel nullen erin moet overtypen. Het aantal nullen moet in een oogopslag zichtbaar zijn en dan is 6 posities wel ongeveer het maximum.

Er bestaat zoiets als databasenormalisatie die ervoor zorgt dat je een database bouwt (met relaties) op een zodanige manier dat er geen duplicate informatie inzit.

Een personen/bedrijfs gegevens zijn identiteiten, en heeft op zich niets met debiteur/crediteur/klant te maken, dus zit dit in een specifieke tabel.
Slechts voor transacties waarin er debiteuren/crediteuren vereist zijn, wordt er vanuit een specifieke debiteur/crediteur tabel naar die identiteitabel verwezen, etc...

Voor security redenen (insecure direct references) is ook niet aangewezen om voorspelbare ID's te gebruiken. Je maakt ze beter random door bijvoorbeeld een GUID te gebruiken.
21-10-2021, 13:54 door [Account Verwijderd] - Bijgewerkt: 21-10-2021, 13:55
Door Anoniem: ...
De meeste programmeurs weten echt niet wat ze aan het doen zijn en zijn al blij als iets compiled zonder "errors", laat staan "warnings".

Er duikt bij mij een beeld op van een baby met een kaasschaaf (raadsel: het is rood, het zit in een hoek en wordt steeds kleiner).
21-10-2021, 17:02 door Anoniem
Door Anoniem:
Door Anoniem:
Allereerst kan ik aangeven dat bewust voor 1 tabel is gekozen, omdat het ook mogelijk is dat een relatie zowel een debiteur als een crediteur is.
Dat is inderdaad een slimme beslissing. Ik ken systemen die 2 tabellen gebruiken en dat is gewoon niet fijn, je zit
altijd weer met die dubbele vermeldingen en ook is het lastig in allerlei queries.

Wat ik in dit geval niet begrijp, is dat er zo weinig ruimte is gelaten tussen een crediteuren nummering en debiteuren nummering. Het relatie nummer in Exact Online kan 18 posities bevatten, waarvan Magento heeft besloten (of de klant) om er maar 5 van te gebruiken. Dat is dan vragen om moeilijkheden.

Dat vond ik ook al raar. Ik ken Exact niet maar ik vond die grenzen tamelijk dom en willekeurig gekozen. Geen idee of dat een domme beslissing tijdens de implementatie, een default situatie of iets anders is.
Ik zou in ieder geval ook veel grotere ranges gebruikt hebben en ook zeker niet van die rare ranges.
Doe dan zo iets:
- crediteuren vanaf 1000000
- zelf ingevoerde debiteuren vanaf 2000000
- dynamisch gemaakte debiteuren (via de koppeling) vanaf 3000000

Dan kun je makkelijk zien wat je bij de hand hebt en loopt het voorlopig niet fout.
Komt het niet vaak voor dat je een debiteurnummer moet intypen dan kunnen nog langere nummers gebruikt worden, maar dit is een afweging want het is heel vervelend als je steeds lange nummers met heel veel nullen erin moet overtypen. Het aantal nullen moet in een oogopslag zichtbaar zijn en dan is 6 posities wel ongeveer het maximum.

De opzet qua nummerreeksen is niet zo gek gedacht, en zo houd je inderdaad overzicht.
Helaas verteld de uitspraak van het gerechtshof niet of dit wellicht zo ook door de softwareleverancier is voorgesteld aan de webwinkelier. Wellicht heeft de webwinkelier wel aangegeven dat hij per se debiteuren uit de webshop in een bepaalde reeks wilde hebben en heeft hij kennis genomen van de eventuele beperkingen die daaraan zitten.

Wellicht dat het hof daarom ook het niet hebben van een back-up de webwinkelier aanrekent. En is dit niet direct een bug van de softwareleverancier....
22-10-2021, 10:19 door Anoniem
Hoezeer ik het maken van backup ook toejuig, deze uitspraak stelt mij teleur.
De reden hiervoor is dat we steeds meer toegaan naar een maatschappij waarbij schade veroorzaakt door een ander afgewimpeld wordt onder het mom van nalatigheid van diegene die de schade leidt.

Wanneer ik mijn fiets niet op slot zet en deze wordt gejat, dan betaalt de verzekering niet uit.
Hier kan ik in zekere zin nog iets mee omdat ik de verzekeraar vraag aan mij schade te vergoeden die niet door de verzekeraar is veroorzaakt (maar door de dief van mijn fiets).

Op het moment dat iemand tegen mijn auto aanrijdt en aanvoert dat ik 'nalatig' ben geweest door op dat specifieke moment op die specifieke plaats te zijn wordt het anders.
Ben ik echt nalatig geweest?

Nu stond mijn auto geparkeerd voor mijn huis en niet in de garage naast mijn huis.
Diegene die tegen mijn auto aanrijdt voert aan dat mijn auto beter beschermd zou zijn geweest tegen schade indien ik deze in mijn garage had geparkeerd en dat ik daarmee nalatig ben geweest waardoor er een onnodig grote schade is ontstaan waarop ik zelf invloed heb gehad en die ik zelf had kunnen voorkomen.

Deze uitspraak geeft de mogelijkheid mij in bovengenoemd voorbeeld op te laten draaien voor de schade aan mijn auto. Dat lijkt mij geen goede zaak.
De veroorzaker van de schade zou in alle gevallen aansprakelijk moeten zijn voor de door hem veroorzaakte schade!
22-10-2021, 10:25 door Anoniem
Door Anoniem: Toen ik mijn eerste Porsche kocht werd ik erop gewezen dat de auto weliswaar leuk kan gassen maar ook veel betere remmen heeft dan menig andere auto. Dus dat vooral in noodstopgevallen ik goed in de spiegel moest kijken omdat de auto achter me meer remweg nodig had. Een paar praktijktests later bewezen dat ook. Gaat dat mis dan kun je natuurlijk ook je geld niet terugkrijgen van de dealer. Logisch.

De gedachtefout die je hier maakt is dat niet de dealer diegene is die de schade veroorzaakt, maar diegene die bij jou achterop rijdt.
Het is dus volkomen onlogisch om met deze schade naar de dealer te gaan.

Jouw voorbeeld wordt interessant wanneer diegene die jou van achteren heeft aangereden gaat aanvoeren dat hij jou niet geraakt zou hebben indien jouw auto minder goede remmen zou hebben gehad en dat jij, door het rijden in een auto met hele goede remmen, invloed hebt gehad op de hoogte van de schade en dat jij daardoor minimaal mede verantwoordelijk bent en dus minimaal een deel van de schade zou moeten vergoeden.

Deze redenering kan en mag nooit gehoor krijgen bij een rechter!
22-10-2021, 11:17 door Anoniem
Door Anoniem:
Door Anoniem:
Door Anoniem:
Allereerst kan ik aangeven dat bewust voor 1 tabel is gekozen, omdat het ook mogelijk is dat een relatie zowel een debiteur als een crediteur is.
Dat is inderdaad een slimme beslissing. Ik ken systemen die 2 tabellen gebruiken en dat is gewoon niet fijn, je zit
altijd weer met die dubbele vermeldingen en ook is het lastig in allerlei queries.

Wat ik in dit geval niet begrijp, is dat er zo weinig ruimte is gelaten tussen een crediteuren nummering en debiteuren nummering. Het relatie nummer in Exact Online kan 18 posities bevatten, waarvan Magento heeft besloten (of de klant) om er maar 5 van te gebruiken. Dat is dan vragen om moeilijkheden.

Dat vond ik ook al raar. Ik ken Exact niet maar ik vond die grenzen tamelijk dom en willekeurig gekozen. Geen idee of dat een domme beslissing tijdens de implementatie, een default situatie of iets anders is.
Ik zou in ieder geval ook veel grotere ranges gebruikt hebben en ook zeker niet van die rare ranges.
Doe dan zo iets:
- crediteuren vanaf 1000000
- zelf ingevoerde debiteuren vanaf 2000000
- dynamisch gemaakte debiteuren (via de koppeling) vanaf 3000000

Dan kun je makkelijk zien wat je bij de hand hebt en loopt het voorlopig niet fout.
Komt het niet vaak voor dat je een debiteurnummer moet intypen dan kunnen nog langere nummers gebruikt worden, maar dit is een afweging want het is heel vervelend als je steeds lange nummers met heel veel nullen erin moet overtypen. Het aantal nullen moet in een oogopslag zichtbaar zijn en dan is 6 posities wel ongeveer het maximum.

De opzet qua nummerreeksen is niet zo gek gedacht, en zo houd je inderdaad overzicht.
Helaas verteld de uitspraak van het gerechtshof niet of dit wellicht zo ook door de softwareleverancier is voorgesteld aan de webwinkelier. Wellicht heeft de webwinkelier wel aangegeven dat hij per se debiteuren uit de webshop in een bepaalde reeks wilde hebben en heeft hij kennis genomen van de eventuele beperkingen die daaraan zitten.

Wellicht dat het hof daarom ook het niet hebben van een back-up de webwinkelier aanrekent. En is dit niet direct een bug van de softwareleverancier....
Nee die reeks is super dom bedacht, want je kan de grens niet ophogen omdat dat niet compatible is met oude data. Zoals iemand hierboven al zei een account moet uniek zijn (bv GUID of werken met een extra tabel) met een referentie naar soort (crediteur, debiteur of allebei).
Verder hangt het natuurlijk ook af van wat exact in de gebruikers licentie heeft staan. Er zijn bedrijven die melden dat ze nooit aansprakelijk zijn. Als je dat niet accepteert mag je hun software niet gebruiken.
22-10-2021, 12:10 door Anoniem
Door Anoniem:
Door Anoniem: Toen ik mijn eerste Porsche kocht werd ik erop gewezen dat de auto weliswaar leuk kan gassen maar ook veel betere remmen heeft dan menig andere auto. Dus dat vooral in noodstopgevallen ik goed in de spiegel moest kijken omdat de auto achter me meer remweg nodig had. Een paar praktijktests later bewezen dat ook. Gaat dat mis dan kun je natuurlijk ook je geld niet terugkrijgen van de dealer. Logisch.

De gedachtefout die je hier maakt is dat niet de dealer diegene is die de schade veroorzaakt, maar diegene die bij jou achterop rijdt.
Het is dus volkomen onlogisch om met deze schade naar de dealer te gaan.

Jouw voorbeeld wordt interessant wanneer diegene die jou van achteren heeft aangereden gaat aanvoeren dat hij jou niet geraakt zou hebben indien jouw auto minder goede remmen zou hebben gehad en dat jij, door het rijden in een auto met hele goede remmen, invloed hebt gehad op de hoogte van de schade en dat jij daardoor minimaal mede verantwoordelijk bent en dus minimaal een deel van de schade zou moeten vergoeden.

Deze redenering kan en mag nooit gehoor krijgen bij een rechter!
Nutteloze vergelijking en Hij zegt ook niet dat de schade bij de dealer verhaald kan worden.
24-10-2021, 08:52 door Anoniem
Exact is altijd al drama geweest. Ooit eens een backup terug moeten zetten. Factuur 32767 (of iets dicht in de buurt) was geweest. En toen er door gefactureerd werd verdween nummer 1.

Backup terug was 1. En toen de paniek omdat er niet meer gefactureerd kon worden.
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.