Ward van der Put

Je moet de belangrijkste kenmerken van producten of diensten vermelden. Een wettelijke leeftijdsgrens lijkt mij wel een productkenmerk dat zó belangrijk is dat je het moet noemen. Je moet bovendien uitleggen hoe de webwinkel te werk gaat. Ook de ID-controle aan de voordeur lijkt me voldoende opvallend om niet onvermeld te laten, bijvoorbeeld in de servicepagina's, de algemene voorwaarden of de winkelwagen. Vraag is vooral hoe je dan de leeftijdsgrens moet melden. Een disclaimer is het niet, want daarmee wijs je aansprakelijkheid of een andere verantwoordelijkheid op voorhand af. Het is eerder een "claimer": wij verkopen geen alcohol aan minderjarigen. Je kunt die melding bijvoorbeeld in de footer onderop elke webpagina zetten. Een schreeuwerige pop-up waarin de bezoeker geboortedatum moet invullen, is niet nodig: je gaat namelijk niet gelijk 18+-content tonen. Verder zou ik van de geboortedatum een verplicht gegeven in de winkelwagen maken. Mocht bij de ID-controle aan de voordeur blijken dat de klant minderjarig is, waarna de bestelling retour komt, dan kun je daarmee gemakkelijker de kosten verhalen op de koper: u hebt valse gegevens opgegeven bij het plaatsen van de bestelling, dus we verhalen op u de overbodige kosten die gepaard gaan met het mislukken van de levering.

Als je minder van het oude stempel was geweest, dan had ik Disqus aanbevolen. Plus een Cheaque T-shirt.

Zo lastig is het nu ook weer niet: ID Check aan de deur

Zo bedoelde ik het ook. Even per PB een FWD naar Norbert. De shit van de aap komt namelijk vaak pas met doorvragen uit de mouw drijven.... De briefcorrespondentie tussen twee reuzen is een apart literair genre. Can't wait. :)

Nee, dat is niet brutaal hoor. Met zoveel getheoretiseer gebeurt dat vanzelf: stront komt altijd bovendrijven.

Helemaal mee eens: niet interpoleren of middelen, want dan neigt het zwaartepunt vanzelf naar middelmatigheid.

De Belastingdienst heeft geen stralingsdeskundige nodig om vast te stellen wat stralingsdeskundigen met elkaar doen in een ruimte die alleen voor stralingsdeskundigen toegankelijk is. Follow the money... Er is een hele paper trail van contracten, correspondentie en betalingen waaruit de Belastingdienst ook kan afleiden hoe de vork in de stralingsdeskundige steekt. Die mag de Belastingdienst opvragen en dat doet zij in de praktijk ook.

Bij webwinkels die de doorstart niet kunnen maken, zul je echter vaak kunnen constateren dat ze overlijden aan een sluimerende kinderziekte die ze al vanaf de start onder de leden hadden. Er worden in de avonduren en weekends honderden uren in gestoken, maar daar staat geen reële arbeidsvergoeding tegenover. Verder doorgroeien wordt onmogelijk als die avond- en weekenduren eenmaal op zijn: er fulltime voor gaan blijkt financieel niet haalbaar omdat daar onvoldoende inkomen tegenover staat. Dat is een van de redenen waarom ongeveer de helft van de webshops na 2 jaar stopt. In het Shopping2020-onderzoek kwam de expertgroep Online Ondernemen dan ook met onder andere deze aanbeveling: Zo'n webwinkel kun je wel verkopen, maar of je zo'n webwinkel moet willen kopen, is nog maar de vraag.

Ben je als freelance journalist niet vrijgesteld van btw?

De relatie met een energieleverancier is echter vooral kwantitatief, nauwelijks kwalitatief: maandelijks voorschot betalen en één keer per jaar het verschil afrekenen. Ik heb wel een zakelijk energiecontract, maar dat is omdat ik niet bang ben om daarover zelf te onderhandelen in plaats van het over te laten aan een of andere prijsvergelijkingssite die de kickback fee voor oversluiten in eigen zak steekt. Bovendien ben ik energieleverancier dankzij de overcapaciteit* op mijn zonnepanelen. * Die kan ik sinds kort afromen met een nieuwe inverter waarmee ik het kantoor A++ kan koelen en A+ verwarmen. Ik moet het wekelijkse dag-nacht-patroon alleen nog beter inprogrammeren voor een optimale match tussen verbruik en conform.

Voor de kwaliteitsbewaking en kwaliteitsverbetering van software werkt het ook heel goed. In test-driven development (TDD) kennen we het vergelijkbare mantra: red, green, refactor. Je legt de requirements van software eerst vast in unittests die aanvankelijk allemaal een rode fail hebben (red). Daarna ga je ontwerpen en programmeren totdat alle fouten verdwenen zijn (green). Voor nieuwe features en requirements refactor je de bestaande code voor een update door nieuwe unittests tot te voegen aan de tests die je al had. En dan ben je weer aan het begin van de cyclus bij red. In stappen: 1. Add a test. 2. Run all tests and see if the new test fails. 3. Write the code. 4. Run tests. 5. Refactor code. Vooral in de open-source beweging wordt daarover stevig gedebatteerd. Volgens het ene kamp zijn tests de heilige graal, volgens het andere kamp zitten ze enorm in de weg en beide kampen hebben op hun manier natuurlijk helemaal gelijk. Als ik aan het einde van de dag nog een rode F in PHPUnit heb, dan slaap ik slecht. ;D

Sockpuppet?

5W1H (Dan is de methodiek makkelijker te onthouden.)

Het lijkt mij veel aannemelijker dat een leasemaatschappij weet wat het verschil tussen huur, huurkoop en operational lease is.

Met een gevalideerd SSL-certificaat kun je e-mail via S/MIME voorzien van een zogeheten gekwalificeerde elektronische handtekening. Elke fatsoenlijke e-mailclient ondersteunt het, alleen is het inderdaad bijna onbegonnen werk om de gemiddelde e-mailgebruiker uit te leggen in welk elektronische sleutelgat hij jouw public key moet steken. De enige die ik het de afgelopen decennia ooit heb zien gebruiken, is de leverancier van mijn SSL-certificaat. ;D Misschien is Idensys en het eID Stelsel, de "opvolger" van DigiD die ook bedoeld is voor ondernemingen, een betere oplossing.

Met, zonder overdrijven, grote regelmaat zie ik dat ondernemers vastlopen met hun website omdat het het handige neefje geen tijd meer voor ze heeft. Die is dan gaan studeren... Zo misplaatst is de opmerking helaas niet. Als je zelf een app wilt bouwen, denk ik dat je om te beginnen vooral heel goed naar je uren moet kijken en dat eens moet vergelijken met wat een webbureau rekent voor een professioneel gebouwde native app of webapp.

Niet met de DigiD van de klant maar met een machtiging, zou ik dan als verzekeraar eigenlijk wel een beetje verwachten… Hoe werkt het bruggetje in algemene voorwaarden dan eigenlijk? Als algemene voorwaarden de hoogte van de schade beperken tot wat de verzekeraar uitkeert en die niet uitkeert, dan is de uitkomst toch hetzelfde?

Kleine toevoeging: het voorzichtigheidsbeginsel wordt niet genoemd in het Handboek Ondernemen. Om wat voor kosten gaat het precies? Bijvoorbeeld de aanschafkosten van bedrijfsmiddelen, zoals een nieuwe pc, kun je namelijk wel uitsmeren over meerdere jaren door ze te activeren (op de balans te zetten als vaste activa) en er vervolgens jaarlijks maximaal 20% op af te schrijven.

Veel webwinkels hebben een keurmerk van de Grote Drie en hanteren daarom de algemene voorwaarden die zijn voorgeschreven door het keurmerk (bij Thuiswinkel Waarborg en Webshop Keurmerk in overleg met de Consumentenbond) of die worden aanbevolen door het keurmerk (bij WebwinkelKeur). • https://www.thuiswinkel.org/bedrijven/lid-worden/voorwaarden/algemene-voorwaarden-thuiswinkel • https://www.keurmerk.info/Home/KeurmerkCode • https://www.webwinkelkeur.nl/webwinkel/voorbeeld-algemene-voorwaarden-webwinkel/ Daarin is consument al zó gedefinieerd dat je voor zakelijke klanten kunt afwijken van de algemene voorwaarden, dus je kunt overeenkomen wat jullie goeddunkt. Precies. Als ik vermoed dat bescherming van het consumentenrecht mij wel goed kan uitkomen, bijvoorbeeld omdat ik wil kunnen retourneren of minimaal 2 jaar garantie wil, dan bestel ik zakelijke aankopen gewoon onder mijn eigennaam. Wat mij bij mijn leveranciers wel eens overkomt, is dat zij zelf een bestelling deels of geheel annuleren. Irritant, maar daarover zou ik dan toch ook wat opnemen in de voorwaarden.

Als anderen je factureren zonder daarbij best practices te volgen, moet je zelf GIGO voorkomen. Een best practice is ook zoveel mogelijk van dit soort praktijkvoorbeelden in unittests verzamelen en dan doorontwikkelen tot je geen rode Fail-vlaggetjes meer over hebt: red/green/refactor. 8)

Bij ontvangen facturen is de logica in factuurnummers en bestandsnamen echter zoek. Dan krijg je juweeltjes zoals jaarfactuur_2016.pdf met factuurkenmerk FK-16868-22308393 naast creditnota foobar_67890_ideal_4831649.pdf met factuurnummer 4831649 (twee concrete voorbeelden uit mijn administratie). Daarom zou ik die logica een niveau hoger aanbrengen: in de mapnaam in plaats van de bestandsnaam. Alles van mei 2016 sla ik daarom op in de map /2016/05/, alles van juni 2016 in /2016/06/ enzovoort. In combinatie met datumfuncties in een spreadsheet kom je dan uiteraard een heel eind. Kun je iets dan nog niet terugvinden, dan biedt Google Drive nog een oplossing: Google is erg goed* in zoeken. * Goed maar niet perfect: Gmail zoekt wel in PDF-bijlagen maar niet in CSV-bestanden.

Vreselijk. Alsof je de afgelopen (bijna) 5 jaar in gratis Bootstrap-omgevingen hebt geleefd en dat *dus* de norm is geworden. Dus niet. Wat valt jezelf zoal op als je dit experiment vergelijkt met professionele ticketing- en supportsystemen?

Een consument kijkt vooral naar het totaalplaatje. Nauwelijks naar het totaalbedrag exclusief btw. En al helemaal niet naar de inclusief-en-exclusief-btw-opbouw van afzonderlijke factuurregels. Daarom is de psychologische prijsstelling die @prinsrachid zijdelings aanstipt een interessant fenomeen: € 9,99 lijkt een bedrag van een andere orde dan € 10,01. Meer in het algemeen doet het er niet toe. Als je consumenten belooft dat het "alles bij elkaar" € 9,99 is, dan is het dus niet € 10,01.

Je moet afstappen van de idee dat afrondingsverschillen niet kloppen; die kloppen juist wél, want daarom zijn het verschillen. Het enige dat je kunt doen, en dat redelijkerwijs van je verlangd kan worden, is dat je de verschillen zo klein mogelijk houdt. Dat doe je door zo min mogelijk af te ronden en door zo lang mogelijk met zo lang mogelijke getallen te rekenen. (Dat de weergave van een getal afwijkt van het getal waarmee je rekent, hoef ik iemand die zelf software bouwt niet uit te leggen, gok ik.) En als je alles op de cent nauwkeurig kloppend hebt, moet je nog fijn even een ander afrondingsverschil wegwerken: je doet aangifte in hele euro's, waarbij je in je voordeel mag afronden. Maar gelukkig zit het anderzijds daarom soms mee en verdwijnen je eigen afrondingsverschillen als sneeuw voor de zon. Het verleggen van btw zou ik trouwens nog eens even nalezen. Je maakt mogelijk een beginnersfout die ik beginners wel vaker zie maken: je kunt niet automatisch alle btw verleggen naar klanten met een btw-nummer.