17 reacties

  1. Ook bij een forum is het soms wel in het belang van het bedrijf om niet rucksichtloss alles weg te gooien. Het zou bijzonder vervelend zijn als een troll na een ban zijn account kan laten verwijderen en zichzelf weer kan inschrijven om met een schone lei opnieuw te kunnen trollen.

  2. Hoewel ik geen expert ben in winkelsoftware ken ik diverse andere software die het verwijderen van accounts gewoonweg niet ondersteunt. En zelfs in de database is het moeilijk om account met de hand te verwijderen door database restricties Technisch is het dus ook niet evident

    Het selectief wissen van gegevens uit een account na een aantal jaren zou je in principe misschien wel kunnen ondersteunen maar is gewoon niet kosteffectief genoeg om in te bouwen.

    1. Het is nu niet kosteffectief omdat het niets oplevert. Maar als ze zouden controleren en er flinke boetes op staan, is dat anders lijkt me? Het lijkt me niet heel moeilijk om uit te vinden welke software hiervoor niet gebouwd is en gezien die software dan vaak door een flink aantal webwinkels wordt gebruikt, is het makkelijk om gericht te controleren. Als dat er vervolgens voor zorgt dat die software een uitstroom van klanten ziet en een grote roep om verandering, moeten zij wel iets. Dan komt er in ieder geval ondersteuning in de vorm van software die het kán, en dan is het nog een kwestie van het juist instellen door de klant (en met klant bedoel ik dan de winkelier, gezien die klant van de software-ontwikkelaar is).

  3. Voor webwinkeliers is het vanuit de software soms alles of niets

    Valt dat onder de noemer onkunde? Met een SQL client kun je die data wel degelijk individueel van die klant opzoeken en verwijderen of onleesbaar maken voor die SQL gebruiker maar voor root leesbaar. De software zou dat kunnen implementeren bij de knop “verwijder hier uw account”. Eventueel met een uitleg zoals bovenstaande. Het feit dat de software dat niet kan is toch niet het probleem van de klant?

    1. Er zijn natuurlijk ook genoeg software developers die geen support meer leveren wanneer er handmatig edits gedaan zijn in de database in plaats van enkel via de daarvoor bedoelde interface van het software pakket waar je dit soort acties dus niet zomaar zonder gevolgen kan uitvoeren.

  4. 1) Er bestaan al jaren (zeker sinds 1997) normeringen, niet alleen bedoeld voor overheden, waarin vernietigingsfunctionaliteiten voor software staan beschreven (bv. MoReq2010, NEN 2082 en NEN-ISO 16175). Erg handig om daar compliant aan te zijn ook in relatie tot de AVG. 2) Staat in de voorwaarden van winkeliers een regel dat de accountgegevens van een klant onderdeel zijn van de winkeladministratie volgens het BW of moeten we daar maar impliciet van uitgaan? Van wie zijn de accountgegevens eigenlijk?

  5. Als je het account van de klant niet kunt verwijderen zou je dan nu juist wel of niet inloggen onmogelijk moeten maken door bv het password weg te gooien? Als inloggen mogelijk blijft maak je duidelijk dat het account nog steeds bestaat maar als je inloggen onmogelijk maakt dan schep je mogelijk de illusie dat het account wèl verwijderd is.

  6. Die factuur in dat account van die klant moet dus bewaard worden, net als de ‘overeenkomst’, de registratie van de bestelling.

    Wat staat er dan precies in die ‘registratie’ van de bestelling? Verder dan de besteldatum kom ik niet, maar die staat gewoon op de factuur.

    1. Daar zit ik inderdaad ook aan te denken.

      Afhankelijk van hoe je facturen gegenereerd worden (on the fly bij het opvragen of eenmaal bij het aanmaken en als PDF opgeslagen), zou je zelfs zo ver kunnen gaan om de volledige gegevens van die klant te ‘scramblen’. Dus de NAW-gegevens vervangen door een Lorum Ipsum uittreksel en inderdaad het e-mailadres aanpassen naar een gegenereerd e-mailadres en klaar is Kees.

      Als facturen níet worden opgeslagen bij het aanmaken en dus iedere keer gegenereerd worden als die wordt gedownload, dan zit je wel met een probleem. Voor de belastingdienst dan, niet voor de klant. Want die kiest er zelf voor om zijn account te laten ‘verwijderen’.

  7. Iedereen die iets van boekhouding én van databases én van SQL weet kan bevestigen dat er normalerwege in zo’n klantaccount alleen een verwijzing naar de eigenlijke factuur (waarop de naw-gegevens v.d. klant staan) zal worden bewaard. Indien de software dus een beetje volgens de normen is geprogrammeerd dan wordt de factuur helemaal niet verwijderd als het klantaccount wordt verwijderd. Dus heeft dat bedrijf m.i. een drogreden gebruikt om een niet terzake kundige klant te overbluffen. Gewoon nogmaals eisen dat het account wordt verwijderd of – zoals al is gesuggereerd – tenminste wordt geanonimiseerd (of dit goed Nederlands is weet ik even niet).

  8. Moet een webwinkel meer gegevens bewaren dan een fysieke winkel waar mensen met contant geld betalen? Bij die fysieke winkel weet de winkelier toch ook niet wie wat heeft gekocht? Hij kan hooguit een administratie bijhouden van wat ‘ie wanneer voor welke prijs heeft verkocht, maar niet aan wie.

Geef een reactie

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