Definieer eerst wat beschikbaar betekent.
Fysiek aanwezig, vrijgegeven, gereserveerd en beschikbaar zijn verschillende begrippen. Een partij kan in het magazijn staan en toch geblokkeerd zijn voor kwaliteitscontrole. Een pallet kan zijn toegewezen aan een order maar nog op de oorspronkelijke locatie staan. Maak deze verschillen expliciet voordat je een voorraadgetal over systemen verdeelt.
Gebruik voor een eenvoudig model: beschikbaar is de voor dit doel bruikbare voorraad min de actieve reserveringen daarop. Zorg dat geblokkeerde voorraad niet eerst buiten bruikbaar valt en daarna nogmaals wordt afgetrokken. Zodra klanten, partijen, houdbaarheid of verpakkingen andere regels krijgen, moet beschikbaarheid die context meenemen.
Voor een concreet handelsproces werkt de gids over voorraad onderweg beheren uit hoe verwachte aanvoer, klanttoewijzingen en werkelijke ontvangst samenhangen.
Een reservering voor eigenaar A mag geen voorraad van eigenaar B gebruiken. Een aanvraag voor twaalf stuks is evenmin vanzelf één doos. Leg omrekening, afronding en deelverpakkingen vast. Een toekomstig verwachte ontvangst kan meetellen in een leverbelofte, maar is daarmee nog geen fysiek beschikbare pickvoorraad. Dat onderscheid bepaalt welke beslissing de software nu mag nemen.
Lezen en daarna boeken laat ruimte voor een race.
Neem een fictief voorraadvak met tien beschikbare stuks. Twee aanvragen willen ieder zeven stuks reserveren. Als beide processen eerst tien lezen, vervolgens “voldoende” besluiten en pas daarna boeken, kunnen beide slagen. Iedere aanvraag lijkt afzonderlijk correct; de combinatie schendt de afspraak dat je niet meer toewijst dan beschikbaar is.
Dat heet een race condition: de uitkomst hangt af van hoe gelijktijdige handelingen door elkaar lopen. De oplossing hoort bij de plek waar de reservering definitief wordt gemaakt. Een knop tijdelijk uitschakelen in één scherm beschermt niet tegen een andere terminal, webshop of achtergrondtaak.
Kies één beslissende voorraadadministratie per voorraadpool. Andere toepassingen kunnen een indicatie tonen, maar vragen daar de reservering aan. Bij meerdere vestigingen kun je verantwoordelijkheid per pool verdelen, mits duidelijk is wanneer voorraad van de ene naar de andere pool overgaat. Meer hierover staat in de bronafspraken tussen WMS, TMS en ERP.
Maak de reservering één samenhangende wijziging.
Een databasetransactie groepeert wijzigingen die samen moeten slagen of samen moeten worden teruggedraaid. De juiste concurrentiecontrole voorkomt daarnaast dat twee geldige transacties gezamenlijk een ongeldige voorraadtoestand maken. Alleen de woorden “we gebruiken transacties” zijn daarom niet voldoende: ook het isolatieniveau en de manier van lezen en bijwerken doen ertoe.
| Aanpak | Wat doet het ontwerp? | Waar let je op? |
|---|---|---|
| Vergrendelen | Een transactie vergrendelt de betrokken voorraadgegevens voordat zij beschikbaarheid controleert en reserveert. | Houd de transactie kort; voorkom verschillende vergrendelvolgordes. |
| Voorwaardelijk bijwerken | Een wijziging slaagt alleen als de beschikbare hoeveelheid of verwachte versie nog klopt. | Controleer of de wijziging werkelijk is uitgevoerd; herbereken bij een conflict. |
| Serializable transacties | De database bewaakt een uitkomst die overeenkomt met een seriële uitvoering. | Een transactie kan worden afgebroken en moet dan in haar geheel opnieuw worden beoordeeld. |
Deze routes zijn geen uitwisselbare instellingen die ieder voorraadmodel automatisch veilig maken. Als een reservering meerdere locaties of partijen raakt, moeten alle relevante voorwaarden worden beschermd. Een vergrendeling op alleen de orderregel beschermt niet de voorraad waarop een andere order tegelijk aanspraak maakt.
Onderstaande pseudocode laat de samenhang zien. De concrete databasebewerkingen moeten passen bij het gekozen model.
start transactie
controleer handeling-ID op eerdere verwerking
bescherm de betrokken voorraad tegen conflicten
bepaal beschikbare hoeveelheid opnieuw
bij tekort: geef een verklaarbare afwijzing
anders: leg reservering en voorraadwijziging vast
bewaar het resultaat bij de handeling-ID
commit transactieDe controle op de handeling-ID moet zelf ook gelijktijdige herhaling aankunnen, bijvoorbeeld met een unieke databasebeperking binnen de juiste context. Houd externe API-aanroepen en menselijk overleg buiten een open voorraadtransactie. Wachten op een vervoerder terwijl voorraad vergrendeld blijft, kan andere orders onnodig ophouden.
Ontwerp ook vrijgeven, wijzigen en verbruiken.
Een reservering is meer dan een aantal in een kolom. Leg vast welke orderregel zij bedient, welke voorraad zij claimt en welke status zij heeft. Een annulering geeft alleen het nog gereserveerde deel vrij. Een al uitgevoerde pick vraagt mogelijk een teruglegtaak. Het verwijderen van de reservering verplaatst de goederen niet terug naar het vak.
Ook een verlopen reservering vraagt coördinatie. Stel dat een automatisch opruimproces een reservering wil vrijgeven terwijl een picker haar verbruikt. Beide acties moeten dezelfde geldige toestand controleren en tegen gelijktijdige wijziging beschermen. Anders kan voorraad opnieuw beschikbaar komen terwijl die al onderweg naar de paktafel is.
Bewaar de relevante mutaties met reden en verwijzing naar de oorspronkelijke handeling. Een correctie hoort verklaarbaar te zijn; een stille overschrijving van het voorraadgetal maakt latere verschillen moeilijk te onderzoeken. De gids over voorraadverschillen verbindt deze technische registratie aan controles op de werkvloer.
Een lokaal voorraadbeeld geeft geen centrale toewijzing.
Een scanner zonder verbinding kan niet zomaar weten wat andere medewerkers intussen reserveren. Wil je toch offline picken, onderzoek dan vooraf toegewezen werk of een exclusief toegekende voorraadhoeveelheid. De centrale administratie moet die claim blijven respecteren. Een verlopen of ingetrokken toewijzing vraagt bij terugkomst een expliciete conflictbehandeling.
Een lokaal bijgehouden teller alleen biedt die bescherming niet. Maak duidelijk welke handelingen voorlopig zijn en wanneer het centrale systeem ze heeft bevestigd. In onze gids over offline scannerapps staat hoe je dat voor medewerkers begrijpelijk maakt.
Test de afspraak, ook onder gelijktijdige belasting.
Laat twee aanvragen daadwerkelijk tegelijk dezelfde schaarse voorraad aanspreken. Controleer daarna de actieve reserveringen, vrije hoeveelheid en resultaten van beide aanvragen. Test ook een herhaalde aanvraag na een verloren antwoord, een deelannulering en het verlopen tijdens een pick. Een normale order van begin tot eind doorlopen raakt deze conflicten niet vanzelf.
Formuleer vooraf de regels die altijd moeten blijven gelden: bijvoorbeeld geen negatieve vrije voorraad binnen een pool, een reservering die maar één keer kan worden verbruikt en een totaal dat aansluit op de onderliggende mutaties. Kies regels die bij jouw proces passen; backorders of bewust toegestane tekorten vragen een eigen model.
Blade bouwt WMS- en voorraadsystemen op maat, inclusief de proceslogica achter reserveren, picken en corrigeren. Bespreek waar jouw voorraadbelofte spaak loopt. Een voorbeeld van twee conflicterende opdrachten helpt om snel zichtbaar te maken wat de software moet bewaken.