Wat gebeurt er als twee klanten tegelijk het laatste exemplaar bestellen?

Het korte antwoord

Er zijn twee situaties, en ze lopen verschillend af.

De eerste situatie lost je webshop zelf op. De tweede is het werk van de koppeling. Die kan het gat niet helemaal dichten, want er zit altijd tijd tussen een order op het ene kanaal en de nieuwe stand op het andere. Wel kan hij het gat klein maken en vooraf vastleggen welke order het stuk krijgt, zodat de afloop elke keer dezelfde is.

Binnen één webshop: het platform vergrendelt

WooCommerce reserveert de voorraad zodra bij het afrekenen de order wordt aangemaakt. In de broncode staat hoe: per product komt er een regel in de tabel wc_reserved_stock, en die regel wordt alleen geschreven als de voorraad min wat al gereserveerd is nog genoeg is. De database vergrendelt de voorraad zolang die controle loopt, zodat twee gelijktijdige afrekeningen niet allebei slagen. De tweede klant krijgt de melding dat er niet genoeg stuks van het product op voorraad zijn. De reservering geldt voor het aantal minuten dat bij de voorraadinstelling Hold stock staat, standaard 60; daarna vervalt een onbetaalde order en komt de voorraad terug.

Shopify verplaatst bestelde stuks van beschikbaar (available) naar toegezegd (committed). Toegezegd zijn volgens Shopify de stuks in een order die nog niet is verzonden. Een variant met voorraadbeleid DENY is niet meer te bestellen als er niets beschikbaar is; met CONTINUE wel, en dan gaat de stand onder nul.

Beide platforms zien alleen hun eigen orders. Een order op bol, in een B2B-portaal of in de winkel bestaat voor de webshop pas als de koppeling de nieuwe stand doorgeeft.

Tussen twee kanalen: het gat tussen twee standen

Een artikel heeft nog 1 stuk vrij in het WMS. De webshop krijgt elke wijziging direct door, bol krijgt elke 15 minuten een nieuwe stand. Om 10:02 verkoopt de webshop het laatste stuk. bol toont tot de ronde van 10:15 nog steeds 1, en om 10:04 bestelt daar iemand hetzelfde artikel.

Hoe vaak dat gebeurt is uit te rekenen. Drie getallen bepalen het:

• hoe vaak per week een artikel op zijn laatste stuk komt: in dit voorbeeld 120 keer;
• hoe vaak zo'n artikel op het andere kanaal verkoopt: gemiddeld 0,4 keer per uur;
• hoe lang dat kanaal een oude stand toont: bij een ronde van 15 minuten gemiddeld de helft, 7,5 minuten, ofwel 0,125 uur.

120 maal 0,4 maal 0,125 is 6 dubbele verkopen per week. Bij 400 bestelde artikelen op bol per week zijn 6 annuleringen 1,5%. De streefwaarde van bol is hoogstens 2% van de bestelde artikelen per week; wie bij 3 of meer annuleringen daarboven komt, krijgt een strike. Een drukke week met 200 keer een laatste stuk geeft 200 maal 0,4 maal 0,125 is 10 dubbele verkopen: 2,5% bij hetzelfde aantal artikelen op bol.

Gaat de stand per wijziging naar bol, binnen ongeveer een minuut, dan wordt het 120 maal 0,4 maal 1/60 uur is 0,8 per week. Een buffer van 1 op bol voor deze artikelen haalt het laatste stuk daar helemaal uit de verkoop. Welke stroom per wijziging loopt en welke in rondes, staat in realtime of batch.

Wie krijgt het laatste stuk?

Het gat wordt kleiner, niet nul. Dus moet vastliggen wat er gebeurt als het toch gebeurt. Er zijn drie regels die je kunt kiezen, per artikelgroep of per kanaal.

De eerste regel is de eenvoudigste en de makkelijkst uit te leggen. De tweede beperkt de schade op bol, ten koste van een klant in je eigen webshop die je zelf kunt bellen. De tijdstippen worden in UTC vergeleken, omdat kanalen hun tijd in verschillende zones doorgeven; hoe dat werkt staat in datums en tijdzones.

Elke regel eindigt op dezelfde plek: de order die het stuk niet krijgt, gaat met de reden op een controlelijst. Hij wordt niet stil doorgeboekt in het ERP en niet stil geannuleerd. Is er een inkooporder onderweg, dan krijgt de klant de datum daarvan; hoe dat loopt staat bij backorders.

Wat de koppeling doet om het gat klein te houden

Naast een snellere stand en een buffer zijn er twee fouten die de koppeling zelf kan maken, en die hij moet afvangen.

Een oude stand over een nieuwe schrijven. De koppeling leest om 10:01 dat er 1 vrij is en schrijft die 1 om 10:03 naar Shopify. Om 10:02 is daar het laatste stuk verkocht en stond Shopify op 0. Zonder controle staat het artikel weer te koop. Shopify heeft hiervoor in de mutatie inventorySetQuantities een vergelijking: de koppeling geeft in changeFromQuantity mee welke stand hij verwacht. Het veld is verplicht; wie de controle bewust overslaat, geeft null mee.

{
  "input": {
    "name": "available",
    "reason": "correction",
    "quantities": [
      {
        "inventoryItemId": "gid://shopify/InventoryItem/10482",
        "locationId": "gid://shopify/Location/2001",
        "quantity": 1,
        "changeFromQuantity": 1
      }
    ]
  }
}

Staat Shopify inmiddels op 0, dan weigert het de wijziging met de foutcode CHANGE_FROM_QUANTITY_STALE. De koppeling leest de stand opnieuw en rekent opnieuw uit. Sinds API-versie 2026-04 vraagt deze mutatie ook een verplichte idempotentiesleutel, zodat een herhaalde aanroep na een time-out niet twee keer wordt uitgevoerd. Dat staat in de documentatie van Shopify, nagelezen op 3 oktober 2026.

Open orders twee keer of niet aftrekken. bol trekt bij een voorraadstand met managedByRetailer op false alle open bol-orders er zelf van af. Op true trekt bol alleen de orders af die na de laatste update zijn binnengekomen. Stuurt de koppeling de vrije voorraad uit het WMS, waar de open bol-orders al af zijn, met de verkeerde instelling, dan gaan ze er twee keer af en staat een leverbaar artikel op nul. Andersom gaan ze er niet af en verkoopt bol meer dan er ligt.

Wat betekent dit voor je koppeling?

Het laatste stuk twee keer verkopen is niet helemaal te voorkomen zolang er twee kanalen zijn. Wel is het te beperken en voorspelbaar te maken. Wij bouwen de koppeling met een stand per wijziging waar het kanaal dat toelaat, een buffer per artikelgroep waar het niet kan, schrijfacties die een oudere stand niet over een nieuwe zetten, en de regel die jij kiest voor wie het stuk krijgt. Daarna draaien en bewaken we hem.

Een order die het stuk niet krijgt, staat met de reden en de gekozen afhandeling in het dashboard. Hoe de voorraadstroom verder loopt staat op voorraad en beschikbaarheid, de buffers per kanaal op veiligheidsvoorraad en buffers. Vertel op welke kanalen je verkoopt, dan hoor je hoe groot het gat nu is.