Webshop die geen back-ups maakte verliest rechtszaak van softwareleverancier

| AE 12971 | Ondernemingsvrijheid | 9 reacties

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. Dat meldde Security.nl vorige week. De koppeling bleek gegevens van crediteuren in het boekhoudprogramma te overschrijven met debiteurenboekingen. 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 backup 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 backups 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

Deel dit artikel

  1. Ik moet bekennen dat ik als programmeur ook wel eens voor een dergelijke oplossing gekozen heb. Echter heeft dat dan meestal enkel betrekking op tijdelijke situaties waarbij er zicht is om dat te corrigeren op termijn. En zelfs dan, pak je een verschil van een paar miljoen, waarbij je kan onderbouwen dat het minimaal X jaar duurt voordat die zouden gaan overlappen (X > 100 idealiter).

    De exacte (hihi) constraints hier ken ik niet. ExactOnline kent gewoon een UUID toe aan je debiteuren. Als je die gebruikt onder water in plaats van het numerieke getal is er niets aan de hand. Anders had men toch altijd nog wel een fors hoger getal kunnen kiezen als ‘offset’.

    Maargoed, het leest als een prachtige cowboy club waarbij men snel software de grond uit stampt en hoopt voor het beste. De afnemer doet hetzelfde, en dat levert dan uiteindelijk ooit op een dag dit geneuzel op….

    Ooit, uiteindelijk, gaat, wellicht, de software industrie wel volwassen worden?

  2. Tsja. De cookiemelding van de aanklager (staat in de gelinkte uitspraak) overtuigt mij ook niet dat ze aan de AVG voldoen (“accepteer alles, ook als je de website blijft gebruiken”).

    Toch zet ik vraagtekens bij wat die leverancier (ook genoemd in de uitspraak) nou zou leveren en heeft geleverd. Wie heeft die id ranges bedacht, en hoe is dat in beeld geweest bij die leverancier?

    Die leverancier schermt ook met lekkere teksten als:

    Als Certified Exact partner ondersteunen wij alle productlijnen van Exact Software. Dankzij onze brede kennis richten we je bedrijfsvoering veel efficiënter in en realiseren we vernieuwende oplossingen, helemaal verweven met Exact.
    en
    Heb (of wil) je een webshop? Kies dan voor Exact Online Handel, zo verwerk je bijvoorbeeld feilloos je artikelen, orders en voorraden.

    Zij lijken de specialist voor koppelingen te zijn. Mag je dan wat meer verwachten?

  3. 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.

    Hier moest ik toch even een traantje wegpinken.

    Een of meerdere extra kolommen om het type account aan te geven, of desnoods een extra tabel waren te duur?

    • Ja. Exact Online gebruikt intern nog steeds het onderstel van het originele gegevensmodel vanuit Exact voor Dos, waar in de tabel ‘accounts’ wel een type-aanduiding bestond, maar waar in latere productlijnen (Exact Globe, en Online) tabellen met extra informatie voor debiteuren en crediteuren aan zijn toegevoegd. In oorsprong was het toevoegen van een extra tabel apart voor debiteuren en crediteuren dus inderdaad te duur qua geheugenruimte. Dat dat sinds 1983 niet is aangepast is nu eenmaal zoals het is.

  4. Tja, als programmeur gebruik ik dus altijd een GUID ter identificatie, daar deze statistisch uniek zijn. Dat scheelt een hoop problemen. Crediteurnummers en debiteurnummers kunnen dan gewoon genummerd zijn maar bij import/export worden die gewoon als data meegenomen en niet als sleutel gebruikt. Je kunt dan alles zelfs in een enkele tabel blijven dumpen. Jammer alleen dat je dan meerdere crediteuren en debiteuren kunt hebben met hetzelfde nummer dus een klant-type erbij en dan een unieke sleutel op nummer+type maakt dat dan weer bruikbaar.

    Maar goed, ik heb in de 40 jaar dat ik dit doe al zoveel slechte implementaties gezien van databases dat ik mij afvraag hoe het kan dat het steeds net goed gaat. Een beetje zoals een kip die een drukke snelweg oversteekt en heelhuids aankomt aan de overkant. Als dat nou vaker mis zou gaan dan evolueert het systeem vanzelf kippen die de snelweg niet meer oversteken.

  5. Het is zo jammer dat de uitspraak niets verteld over hoe de koppeling tot stand is gekomen. Wellicht heeft de webshopeigenaar wel zelf aangegeven dat zijn relaties met een vast nummer moesten beginnen en heeft de softwarebouwer wel gezegd dat ‘dat heel onverstandig is’. Met dit soort zaken is het altijd makkelijk te roepen dat ‘wij techneuten’ het anders zouden doen zonder de verdere inhoudelijke werking van de koppeling te kennen en de gemaakte afspraken daarover tussen webshop en softwarebouwers.

Laat een reactie achter

Handige HTML: <a href=""> voor hyperlinks, <blockquote> om te citeren en <em> en <strong> voor italics en vet.

(verplicht)

Volg de reacties per RSS