Waarom verplicht mijn POS mij een product aan te maken voordat ik een eenmalige verkoop kan aanslaan?

Omdat je POS de productcatalogus als de enige 'source of truth' beschouwt, en een eenmalige verkoop geen plaats heeft in dat model. Elke regel op een kassabon moet gekoppeld zijn aan een productrecord, en veel systemen worden geleverd zonder open artikel: geen regeltype waarbij een kassier een naam en een prijs intypt en weer doorgaat. Wanneer een klant je iets geeft dat nooit als product is ingevoerd, heeft de kassa er geen knop voor.

Dus improviseert de kassier, meestal op een van twee manieren: midden in de verkoop een wegwerpproduct aanmaken terwijl de rij groeit, of de verkoop aanslaan op het dichtstbijzijnde echte product en hopen dat niemand het controleert. Beide zorgen voor verkeerde gegevens in je boekhouding.

Waarom moet elke verkoop aan een catalogusrecord gekoppeld zijn?

Omdat bij een catalogusgericht POS het productrecord al het werk doet. Het bevat de prijs, de belastingregel, de voorraadkoppeling en de rapportagecategorie, waardoor afrekenen een opzoekactie is in plaats van gegevensinvoer. Dat ontwerp is perfect voor de overgrote meerderheid van de winkeltransacties, en het is de reden waarom het scannen van een barcode zo snel voelt.

De kloof wordt zichtbaar bij randgevallen: kosten voor een reparatie, een speciale bestelling, bezorgkosten, een afwijkend consignatieartikel dat een leverancier vanmorgen heeft afgegeven. Oude elektronische kassa's regelden dit met een open afdelingstoets (een knop die een ingetypte prijs accepteerde en onder een categorie opsloeg). Veel moderne cloud-POS-systemen hebben die functionaliteit stilzwijgend laten vallen toen ze overstappen op een catalogusgericht ontwerp en hebben deze nooit meer opgebouwd.

Wat doet het personeel eigenlijk als er geen knop voor een open artikel is?

Ze bedenken tijdelijke oplossingen, en die oplossingen kosten meer dan het probleem zelf.

• Wegwerpproducten die midden in een verkoop worden aangemaakt. Een kassier onderbreekt de transactie, opent de cataloguseditor en maakt een "diversen-artikel" aan met de prijs van vandaag. Doe dit een maand lang en je catalogus stroomt vol met rommelrecords die zoekopdrachten, exports en rapporten vervuilen.

• Het raster met nep-producten. Sommige systemen sporen winkeliers aan om producten te maken met namen als "aangepaste verkoop 1" en "aangepaste verkoop 2", elk met een variant per prijsklasse (€ 1,00, € 2,00 enzovoort), zodat de kassier de variant kiest die het dichtst bij het werkelijke bedrag ligt. Dat is een catalogus die zich voordoet als een numeriek toetsenbord, en het rondt je omzet af op de varianten die toevallig bestaan.

• Het aanslaan op het dichtstbijzijnde echte product. Het snelst aan de kassa, het slechtst in de boeken. De vervangende SKU (stock-keeping unit, het productrecord) verliest voorraad die het nooit heeft verkocht, herbesteladviezen worden getriggerd door fantoomvraag en je verkooprapport kent de omzet toe aan het verkeerde product.

• De aantallentruc. Een product van € 1 dat 37 keer wordt aangeslagen levert een regel van € 37 op en een aantal verkochte eenheden dat niets betekent.

Elk van deze oplossingen is onzichtbaar op het moment zelf en kostbaar zodra je rapporten opmaakt. Het is hetzelfde storingspatroon als het POS-systeem van ducttape: de tijdelijke oplossing wordt het systeem, en de rapporten beschrijven de winkel niet meer.

Welke tijdelijke oplossingen houden stand totdat je het oplost?

Als je huidige POS dit niet kan en je deze week niet overstapt, beperk dan de schade:

1. Maak centraal één diversenproduct aan per belastingbehandeling, met de optie om de prijs aan de kassa te overschrijven. Geef ze duidelijke namen, bijvoorbeeld "Diversen belast" en "Diversen onbelast", zodat in ieder geval de belasting op de regel klopt.

2. Blokkeer het bewerken van de catalogus aan de kassa. Tijdelijke producten moeten één keer door een manager worden aangemaakt, nooit halverwege een verkoop door degene die op dat moment aan de kassa staat.

3. Controleer de diversenregels wekelijks. Als de verkoop van diverse artikelen meer is dan een minuscuul gedeelte van de omzet, tast je in het duister over wat er werkelijk verkoopt, op dezelfde manier waarop nachtelijke CSV-exports afwijkingen verbergen tot het einde van de maand.

Dit is triage. Het houdt totalen en belasting consistent, maar elke eenmalige verkoop belandt nog steeds op één grote hoop, en niets ervan herstelt de vertekening van de voorraad door vervangende SKU's.

Hoe zou een eenmalige verkoop eruit moeten zien bij het afrekenen?

Als een volwaardig regeltype, niet als een hack in je catalogus. De kassier typt een naam, typt een prijs, kiest of belasting van toepassing is en welke belastinggroep, en voegt de regel toe aan het winkelwagentje. Het gedraagt zich als elk ander artikel bij de betaling, drukt zijn eigen naam af op de bon, verschijnt als een eigen regel in rapporten en raakt de voorraad nooit aan. Oudere kassa's deden dit al tientallen jaren geleden; er is geen technische reden waarom een modern POS dit niet zou kunnen.

Final biedt dit aan als een aangepaste verkoop: een tabblad naast de catalogus op het verkoopscherm waar je een naam en een bedrag invoert op een numeriek toetsenbord, optioneel een belastinggroep kiest en het toevoegt aan het winkelwagentje zoals elke andere regel. Het is vandaag al live, en de volledige stappen staan in het helpcentrum: hoe je een aangepaste verkoop maakt. Hetzelfde principe geldt voor de andere randgevallen bij het afrekenen die een flexibel systeem moet opvangen, van belastingvrije verkopen tot gesplitste betalingen: beslissingen op regel- en betalingsniveau horen aan de kassa thuis, niet in chirurgische ingrepen in je catalogus.

Eén kanttekening: een open artikel is bedoeld voor écht eenmalige zaken. Als je elke week dezelfde "eenmalige" verkoop aanslaat, heeft het een productrecord verdiend. Het verschil is dat het toevoegen ervan een bewuste catalogusbeslissing wordt in plaats van een noodgeval halverwege een verkoop met een wachtende rij voor je neus.

Dus waarom dwingt je POS je om eerst een product aan te maken?

Omdat het is ontworpen vanuit de veronderstelling dat de catalogus compleet is, en de kassa de plek is waar die veronderstelling meerdere keren per week onderuit gaat. De oplossing is niet meer discipline van het personeel of een netter raster van nep-producten; het is een regeltype voor open artikelen dat een ingetypte naam, een ingetypte prijs en een belastingkeuze accepteert. Vuistregel: als een eenmalige toeslag of verkoop langer duurt dan het intypen van de prijs, mist je POS een regeltype, geen tijdelijke oplossing. Tel hoeveel "diversen"-regels er vorige maand op je rapporten stonden, en als het getal je verrast, controleer dan meteen de rest van je tijdelijke oplossingen.