Een bruikbare datadictionary voor magazijngegevens legt per veld exact vast wat het betekent, welk formaat je gebruikt, wie eigenaar is en wanneer een waarde wel of niet mag voorkomen. Juist bij magazijndata gaat het snel mis op vier punten: status, datum, eenheid en verantwoordelijke. Als je die vier onderdelen strak definieert, voorkom je discussies tussen operatie, inkoop, transport en IT. Dat sluit ook aan op werken met standaardcodes in de logistiek: als je met GS1-codes en labelgegevens werkt, helpt het om intern precies vast te leggen wat ieder veld betekent. Voor identificatie van producten en locaties is ook GS1 Nederland relevant met uitleg over GTIN en GLN als identificatiecodes.
Waarom een datadictionary in het magazijn sneller rendeert dan extra rapportages
Veel magazijnen hebben niet te weinig data, maar te veel verschillende betekenissen. Hetzelfde veld kan in het WMS “gereed”, in Excel “verwerkt” en op een label “gepickt” betekenen. Dan ontstaan fouten bij tellingen, voorraadreservering, houdbaarheid en overdracht aan vervoerder of klant.
Een datadictionary voorkomt dat door per gegeven één brondefinitie vast te leggen. Dat is extra belangrijk als je werkt met barcodes, palletlabels of ketenpartners. Werk je met barcodes of logistieke labels, dan is het extra belangrijk dat iedereen dezelfde velddefinities gebruikt. Anders worden gegevens wel gescand, maar intern nog steeds verschillend geïnterpreteerd.
Welke velden minimaal in je datadictionary moeten staan
Beperk je niet tot alleen een veldnaam. Voor magazijngegevens zijn dit de minimale kolommen:
- Veldnaam: bijvoorbeeld receipt_status of expiry_date.
- Zakelijke definitie: wat betekent het veld in gewone taal.
- Objectniveau: artikel, batch, locatie, logistieke eenheid, orderregel of zending.
- Datatype en formaat: tekst, datum, integer, decimaal, codewaarde.
- Toegestane waarden: vaste statuscodes of keuzelijst.
- Eenheid: stuks, dozen, kilo, meter, liter.
- Bronsysteem: WMS, ERP, scannerinvoer, labelsoftware of EDI-bericht.
- Data-eigenaar: afdeling of rol die de definitie beheert.
- Validatieregels: leeg toegestaan, uniek verplicht, alleen toekomst of verleden, afhankelijk van status.
- Koppeling met standaarden: bijvoorbeeld SSCC, GTIN, GLN, batch of relevante AI.
Werk je nog aan de basis van je systeemlandschap, dan helpt het om je datadictionary naast je warehouse management systeem te leggen. Dan zie je sneller waar definities al bestaan en waar gebruikers met eigen lijstjes werken.
Statusdefinities: maak woorden meetbaar
Statusvelden zijn vaak de grootste bron van ruis. Gebruik daarom geen losse termen zonder beslisregel. Definieer per status altijd wanneer een record die status krijgt en welke gebeurtenis de status beëindigt.
Een bruikbare set kan er zo uitzien:
| Veld | Code | Definitie | Eindigt bij |
|---|---|---|---|
| ontvangst_status | OPEN | Zending aangemeld, nog niet fysiek ontvangen | Eerste scan op dock |
| ontvangst_status | RCVD | Fysiek ontvangen, nog niet kwaliteitsvrijgegeven | Kwaliteitscontrole gereed |
| voorraad_status | AVL | Vrij beschikbaar voor allocatie | Reservering, blokkade of pick |
| voorraad_status | HOLD | Niet uitleverbaar door blokkade, afwijking of inspectie | Vrijgave door bevoegde rol |
| pick_status | PICK | Regel is toegewezen aan pickopdracht | Bevestigde pick of annulering |
Belangrijk is dat je geen status gebruikt als opslagplaats voor uitleg. “HOLD” is een status. De reden hoort in een apart veld, zoals hold_reason met waarden als schade, administratieve mismatch of quarantaine.
Datumvelden: niet “datum”, maar precies welk moment
Een veldnaam als datum is in een magazijn praktisch waardeloos. Leg altijd vast welke gebeurtenis wordt bedoeld. Werk je met GS1-gegevens, maak dan ook onderscheid tussen verschillende datumtypen.
Neem daarom minstens deze beslisregels op:
- received_at: eerste fysieke ontvangstscan van de logistieke eenheid.
- putaway_completed_at: moment waarop voorraad op definitieve locatie ligt.
- production_date: datum van productie, alleen gebruiken als bron dat ook echt zo aanlevert.
- pack_date: datum van verpakken, niet verwarren met productie.
- best_before_date: kwaliteitsdatum, niet automatisch een juridische vervaldatum.
- expiry_date: uiterste gebruiks- of vervaldatum indien van toepassing.
Gebruik intern bij voorkeur één technisch datumformaat per systeemkoppeling, bijvoorbeeld ISO-notatie met tijdzone, en leg vast hoe dat zich verhoudt tot labeldata of barcode-inhoud. Zo voorkom je dat een GS1-code correct is, maar je rapportage toch op de verkeerde datum sorteert.
Eenheden: voorkom stille rekenfouten
Een voorraadverschil ontstaat vaak niet door verkeerde telling, maar door een verborgen eenheidswissel. Daarom hoort in je datadictionary niet alleen de waarde, maar ook de eenheid en de conversieregel.
Leg minimaal vast:
- basiseenheid van voorraad, bijvoorbeeld stuk
- transactie-eenheid, bijvoorbeeld doos of pallet
- weeg- of maatvelden, bijvoorbeeld kilogram of liter
- afrondingsregel en aantal decimalen
- conversietabel, bijvoorbeeld 1 doos = 24 stuks
Op logistieke labels kunnen naast identificatie ook meetgegevens of aantallen voorkomen. Dat maakt het extra belangrijk om intern vast te leggen wanneer een waarde een artikelkenmerk is en wanneer een logistieke meetwaarde van die ene eenheid.
Fictief voorbeeld: als een pallet 40 dozen bevat en een doos 24 stuks, dan is “960” alleen bruikbaar als ook vastligt of dat om stuks per pallet, stuks per orderregel of stuks beschikbaar saldo gaat.
Verantwoordelijke: wie beheert definitie en wie mag wijzigen
“Verantwoordelijke” is meer dan een naamveld. Splits dit in drie rollen:
- data-eigenaar: bepaalt de zakelijke definitie
- procesverantwoordelijke: bepaalt wanneer de waarde verandert
- systeembeheerder: beheert technische invoer, mapping en validatie
Gebruik daarnaast unieke identificatie voor objecten in de keten. GS1 Nederland licht toe dat GTIN producten identificeert en GLN locaties en organisaties uniek aanduidt. Dat helpt om in je datadictionary niet alleen “leverancier” of “magazijn” te noteren, maar ook welk identificeerbaar object je precies bedoelt via GTIN en GLN binnen GS1 Digital Identity.
Praktische aanpak in 6 stappen
- Kies één scope: begin met ontvangst, voorraad of uitlevering, niet met het hele magazijn.
- Inventariseer echte velden: uit WMS, ERP, scanners, labels en Excel-exporten.
- Schrap doublures: bundel velden die hetzelfde bedoelen maar anders heten.
- Definieer de vier risicoklassen: status, datum, eenheid en verantwoordelijke eerst.
- Koppel aan standaarden: noteer waar SSCC, GTIN, GLN, batch en datum-AI’s gelden.
- Beheer als wijzigingsdocument: elke nieuwe status of mapping alleen via versiebeheer.
Checklist voor een goede datadictionary
- Elke veldnaam heeft één zakelijke definitie.
- Elke status heeft een start- en eindgebeurtenis.
- Datumvelden verwijzen naar één concreet moment in het proces.
- Elke numerieke waarde heeft een expliciete eenheid.
- Conversies tussen stuk, doos en pallet zijn vastgelegd.
- De data-eigenaar en wijzigingsbevoegdheid zijn benoemd.
- Identificatiecodes sluiten aan op gebruikte standaarden en labels.
- Bronsysteem en validatieregel staan per veld beschreven.
Wat is het verschil tussen SSCC, GTIN en GLN in een magazijndatadictionary?
GTIN wordt gebruikt voor een artikel en GLN voor een locatie of organisatie. Leg in je datadictionary daarnaast ook vast welke code je voor logistieke eenheden gebruikt, zodat objectniveaus niet door elkaar lopen.
Moet elk datumveld hetzelfde formaat hebben?
Intern liefst wel per systeemkoppeling, maar je moet ook vastleggen hoe dat zich verhoudt tot externe standaarden.
Hoe groot moet een eerste datadictionary zijn?
Begin klein. Een eerste versie met 20 tot 40 kritieke velden rond ontvangst, voorraad en uitlevering is vaak al genoeg om fouten zichtbaar te maken en definities af te dwingen.
Deze uitleg is samengesteld met AI en gecontroleerd aan de hand van de vermelde bronnen. Lees over de redactie en onze werkwijze. Er is geen afzonderlijke beoordeling door een menselijke vakspecialist uitgevoerd.
