Belangrijke gegevenselementen (KDE)

Deze term uit de woordenlijst maakt deel uit van de SG Systems Global Bibliotheek met richtlijnen voor regelgeving en bedrijfsvoering.

Bijgewerkt in januari 2026 • traceerbaarheid KDE's, gebeurtenisgestuurde gegevensregistratie, lotidentificatie, koppeling van handelspartners, hoeveelheden en meeteenheden, tijd-/locatiestempels, CTE-mapping, FSMA 204-gereedheid, EPCIS-afstemming, 24-uurs datasetrespons • Voornamelijk traceerbaarheid in de voedselvoorzieningsketen (FTL-voedsel, gereedheid voor terugroepacties, gereedheid voor audits)

Kerngegevenselementen (KDE's) zijn de specifieke, verplichte gegevensvelden die beschrijven wat er tijdens een traceerbaarheidsgebeurtenis is gebeurd: wie erbij betrokken was, welk product is verplaatst of gewijzigd, welke partij(en) erbij betrokken waren, hoeveel erbij betrokken was en wanneer/waar de gebeurtenis plaatsvond. KDE's zijn belangrijk omdat traceerbaarheid niet mislukt door een gebrek aan documentatie, maar doordat de belangrijkste identificatoren ontbreken, inconsistent zijn, te laat worden vastgelegd of niet aan elkaar gekoppeld zijn tussen gebeurtenissen. Het correct vastleggen van KDE's is essentieel om "traceerbaarheid door reconstructie" te voorkomen, een trage, foutgevoelige en moeilijk te verdedigen methode bij inspecties of terugroepacties.

In de moderne voedseltraceerbaarheid worden KDE's (Key Data Elements) meestal besproken in de context van FSMA 204 (de traceerbaarheidsregel van de FDA). Maar KDE's vormen ook de praktische ruggengraat van bredere systemen: traceerprogramma's van retailers, traceerbaarheidsaudits van GFSI (Global Food Safety Integration) en interne programma's voor de voorbereiding op terugroepacties. De benamingen variëren, maar de operationele vereiste is hetzelfde: je moet snel een samenhangende, aan partijen gekoppelde dataset kunnen produceren. Daarom sluiten KDE's vanzelfsprekend aan op het principe van ' één-op-één-onder' , op de volledige traceerbaarheid van partijen en op de verwachting van een reactietijd van 24 uur.

Laten we het maar meteen zeggen: KDE-compliance gaat niet over het toevoegen van meer velden aan een spreadsheet. Het gaat erom ervoor te zorgen dat de weinige velden die er echt toe doen, worden vastgelegd op het moment van de gebeurtenis, gevalideerd in de juiste context, behouden blijven tijdens transformaties en op aanvraag kunnen worden geëxporteerd. Als uw KDE's uit het geheugen worden getypt nadat de vrachtwagen is vertrokken, is uw traceerbaarheidsdataset fictie. Als uw KDE's scan-gestuurd en gecontroleerd zijn, wordt uw traceerbaarheid een systeemeigenschap – betrouwbaar, zelfs wanneer de processen druk zijn.

"Als je voor traceerbaarheid maar vijf dingen vastlegt, leg dan deze vast: wie, wat, welke partij, hoeveel en wanneer/waar – op het moment dat de gebeurtenis plaatsvindt."

1) Wat KDE's zijn en waarom ze belangrijk zijn

KDE's zijn de gestandaardiseerde velden die traceerbaarheid snel en verdedigbaar maken. Ze zijn belangrijk omdat traceerbaarheid een reactievermogen vereist: wanneer een ingrediëntenpartij betrokken is, wanneer een klant ziekte meldt of wanneer de FDA om een ​​dataset vraagt, moet u reageren met feiten – niet met gissingen. KDE's leveren die feiten door ervoor te zorgen dat elk gebeurtenisrecord de minimale informatie bevat die nodig is om de keten te verbinden.

Vanuit systeemperspectief zijn KDE's (Key Data Elements) de tools die verspreide operationele data omzetten in een traceerbare dataset. Met de juiste KDE's kun je een overzichtelijke gebeurtenisketen exporteren. Zo niet, dan ben je gedwongen om de gebeurtenissen te reconstrueren door documenten te lezen en mensen te interviewen. Reconstructie kan soms werken, maar het is een traag en kwetsbaar proces dat onder tijdsdruk faalt.

2) KDE's versus documenten: waarom "PO + BOL" niet genoeg is

Veel organisaties gaan ervan uit dat traceerbaarheid neerkomt op "we hebben inkooporders voor inkomende goederen en vrachtbrieven voor uitgaande goederen". Dat is documenttraceerbaarheid, en die schiet meestal tekort zodra je precisie op lotniveau nodig hebt. Documenten bieden commerciële context; KDE's bieden lot-gerelateerde gebeurtenisinformatie.

Veelvoorkomende hiaten die alleen in documenten voorkomen:

• De orderregels bevatten geen leverancierslotnummer.
• Op vrachtbrieven staan ​​de hoeveelheden en producten vermeld, maar niet de lotcodes.
• ASN's bestaan ​​wel, maar zijn niet gekoppeld aan wat er daadwerkelijk is geladen.
• De transformatie (input→output) bestaat helemaal niet in documenten.
• Gemengde pallets en herverpakkingen ondermijnen elke aanname die uitsluitend op documenten gebaseerd is.

KDE-programma's vervangen geen documenten; ze koppelen documenten aan gebeurtenisrecords op basis van lotnummer en gebeurtenistijdstip.

3) KDE-categorieën: wie/wat/welke/hoeveel/wanneer/waar

De eenvoudigste manier om KDE's operationeel te maken, is door ze te behandelen als categoriegroepen die bij elke traceerbare gebeurtenis aanwezig moeten zijn:

Door uw administratie te standaardiseren aan de hand van deze categorieën, kunt u zich met minimale aanpassingen aanpassen aan de meeste regelgeving en klantprogramma's.

4) Lot-identiteit: de KDE waar alles van afhangt

De lotidentificatie is de primaire sleutel die gebeurtenissen met elkaar verbindt. Volgens FSMA 204 wordt dit concept vaak uitgedrukt als een traceerbaarheidslotcode (TLC) . In algemene traceerbaarheid kan dit uw interne lot-/batchnummer zijn. De naamgeving doet er niet toe; de ​​eigenschappen wel:

• Uniek: Dit verschijnsel is niet terugkerend gedurende de houdbaarheids- en onderzoeksperioden.
• Vastgelegd tijdens het evenement: De gegevens worden vastgelegd tijdens de ontvangst, verwerking en verzending, niet later.
• Behouden ondanks transformaties: Invoerpartijen zijn gekoppeld aan uitvoerpartijen (geen doodlopende wegen).
• Zichtbaar in uitgaande gegevens: Het komt voor in de standaard KDE-distributies, waardoor een voorwaartse tracering mogelijk is.
• Doorstaat gemengde operaties: Gemengde pallets, deelleveringen en herverpakkingen behouden de lotidentiteit via de koppeling tussen doos en SSCC.

Als de lotidentificatie zwak is, kunnen de overige KDE's dit niet compenseren. Je kunt wel weten wie wanneer heeft verzonden, maar je kunt niet weten om welke loten het ging. Dat is geen traceerbaarheid.

5) KDE's in FSMA 204: hoe CTE's bepalen wat je vastlegt

FSMA 204 organiseert de KDE-vastlegging per gebeurtenistype (CTE's). Dit is belangrijk omdat de KDE-set enigszins verandert afhankelijk van de gebeurtenis: bij ontvangst ligt de nadruk op de afzender en de vastlegging van leverancierslotnummers; bij verzending ligt de nadruk op de ontvanger en zendingidentificaties; bij transformatie ligt de nadruk op de koppeling tussen input en output en de afstemming van hoeveelheden.

De praktische conclusie is simpel: KDE's moeten worden vastgelegd op de plek waar de gebeurtenis plaatsvindt. Je "CTE-kaart" is je workflowkaart. Als je niet weet waar CTE's in je fabriek voorkomen, kun je KDE's niet betrouwbaar vastleggen.

Daarom implementeren veel bedrijven KDE-programma's door drie kernsjablonen te bouwen: ontvangst , transformatie en verzending , plus een gecontroleerd uitzonderingspad.

6) KDE's ontvangen: correct een stap terugzetten

Het ontvangen van KDE's is uw bewijs van "één stap terug". De belangrijkste items die u bij ontvangst moet vastleggen zijn:

• Identiteit en locatie van de afzender/leverancier,
• Identificatie van leverancierslotnummers (en interne lottoewijzing),
• productidentiteit (artikel/SKU),
• hoeveelheid ontvangen en meeteenheid,
• ontvangsttijd/locatie,
• verbanden tussen afhandeling (quarantaine/vasthouding/vrijlating) en bewijs van acceptatie (certificaat van analyse/inspectie indien vereist).

De meeste problemen met KDE beginnen hier: getypte leverancierspartijen, ontbrekende analysecertificaten (CoA's), gemengde pallets die als één partij worden geregistreerd en "opslaan vóór afhandeling". Als u de registratieprocedure bij ontvangst verbetert, wordt de verdere traceerbaarheid aanzienlijk beter.

7) Transformatie-KDE's: input→output-koppeling en massabalans

Transformatie-KDE's zijn de plek waar traceerbaarheid interne genealogie wordt. Het transformatierecord moet de volgende koppelingen bevatten:

• Invoerlijst met partijen (welke partijen zijn verbruikt),
• uitvoer van een lijst met batches (welke batches zijn aangemaakt),
• verbruikte en geproduceerde hoeveelheden (inclusief afval/herbewerking/verliezen),
• Tijdstip/locatie van de gebeurtenis en context van de uitvoering/batch.

Transformatie is de meest voorkomende doodlopende weg bij traceeronderzoeken, omdat veel fabrieken wel registreren "we hebben batch X gemaakt", maar niet "batch X heeft deze specifieke partijen verbruikt". Als een leverancierspartij betrokken is, is de vraag: welke eindproductpartijen bevatten deze partij? Dat antwoord is alleen mogelijk als de KDE's voor transformatie compleet zijn.

Transformatiegegevens moeten ook de hoeveelheden via massabalans controleren . Als dit niet lukt, interpreteren auditors dit als ontbrekende traceergegevens ("product is ergens heen gegaan").

8) KDE's verzenden: bewijs van een stap voorwaarts en bevestiging van de waarheid

Het verzenden van KDE's is het bewijs van "één stap vooruit". Bij de verzendbevestiging moet u het volgende vastleggen:

• Identiteit van de verzendpartner
• zendingsidentificaties (order-ID, vrachtbriefnummer, ASN indien van toepassing),
• Identificatie van de verzonden partij (TLC/partijcodes),
• aantallen verzonden per partij/artikel,
• Verzendtijd/locatie en bewijs van overdracht (manifest/zegel/handtekening indien van toepassing).

Verzending is het punt waar traceerbaarheid het vaakst wordt omzeild, omdat de druk op de laad- en loskade hoog is. Daarom is "verzendingbevestiging moet aan lotnummer gekoppeld zijn" de belangrijkste controle in de meeste KDE-programma's. Als u verzendt zonder lotnummeridentificatie, is uw traceerbaarheid traag en onoverzichtelijk.

9) Aggregatie en gemengde pallets: behoud van identiteit zonder vertraging van het laadperron

Echte magazijnen maken gemengde pallets en gesplitste dozen. Het behoud van de identiteit vereist een strategie:

• Identiteit op casusniveau: . GS1-128 en scan gevallen waarin gemengde pallets vaak voorkomen.
• Identiteit op palletniveau: . SSCC en houd palletinhoudlijsten bij; verzendscans SSCC, niet elke doos.
• Beheerelementen opnieuw opbouwen: Als de inhoud van het pallet verandert, moet de SSCC-inhoudslijst opnieuw worden opgebouwd onder controle (geen "stille wijzigingen").

Als gemengde pallets informeel worden behandeld, kunnen de KDE's voor verzending de verkeerde partijomvang registreren, wat het risico op onder- of overmelding bij terugroepacties vergroot.

10) Regels voor datakwaliteit: validatie, gecontroleerde uitzonderingen en audit trails

KDE-programma's falen wanneer gegevens gemakkelijk onjuist kunnen worden ingevoerd. Regels voor gegevenskwaliteit moeten in workflows worden ingebouwd:

• validatie: Controle van lotformaat, controle van verwachte context, normalisatie van de meeteenheid.
• Gecontroleerde uitzonderingen: Bij scanfouten en vervangingen moeten gestructureerde uitzonderingstickets met verificatie worden gebruikt.
• Audittrails: Voor bewerkingen is een reden voor de wijziging vereist; de oorspronkelijke waarden blijven behouden (zie controlespoor).
• Statusbeperking: vasthouden/loslaten De verzending en consumptie van niet-toegestane partijen moet worden geblokkeerd.

Het principe is eenvoudig: als het systeem gebruikers toestaat verder te gaan zonder de KDE's te voltooien, zullen ze dat ook doen. Je voorkomt hiaten door het voltooien van de KDE's een vereiste te maken, geen voorkeur.

11) Eenheden, hoeveelheden en vangstgewicht: de regel "de wiskunde moet kloppen"

Aantallen zijn essentieel, omdat "wie het heeft ontvangen" niet voldoende is. Bij terugroepacties moet je weten hoeveel er precies door getroffen is. De registratie van aantallen moet consistent zijn:

• Gebruik gestandaardiseerde meeteenheden en omrekeningen (vermijd "soms dozen, soms ponden").
• Registreer de daadwerkelijk verzonden hoeveelheden, niet de bestelde hoeveelheden.
• Afwijkingen in de statistieken en de redenen daarvoor (korte keuzes, blessures, wissels),
• Registreer het vangstgewicht waar van toepassing en koppel variabele gewichten aan de lotidentificatie.
• Verzoening via massabalans over transformaties en verzendingen.

Als de aantallen niet kloppen, lijkt uw dataset onvolledig. Auditors interpreteren dat als ontbrekende gegevens, en het onderzoek wordt dan breder opgezet.

12) EPCIS-afstemming: KDE-opnamen omzetten in uitwisselingsklare gebeurtenissen

EPCIS is een gangbare standaard voor het weergeven van gebeurtenisgebaseerde traceerbaarheid. KDE-capture sluit naadloos aan op EPCIS, omdat EPCIS-gebeurtenissen in wezen "KDE's in een gestandaardiseerde vorm" zijn. Wanneer uw KDE-capture op een gestructureerde manier werkt:

• Het ontvangen wordt een EPCIS-objectgebeurtenis (tijdstip van de gebeurtenis, locatie, identificatiegegevens, verwijzingen naar zakelijke transacties).
• Verzending wordt een EPCIS-objectgebeurtenis (verzendcontext via zakelijke transacties, SSCC/case-ID's).
• De transformatie wordt een EPCIS-transformatiegebeurtenis (input-identificaties → output-identificaties met hoeveelheden).

EPCIS lost het probleem van zwakke opnames niet op. Het maakt sterke opnames uitwisselbaar en machineleesbaar.

13) Reactietijd van 24 uur: hoe het KDE-ontwerp de ophaalsnelheid bepaalt

De praktische test voor de gereedheid van KDE is de snelheid waarmee gegevens kunnen worden opgevraagd. Als een toezichthouder om een ​​dataset vraagt, moet u deze snel kunnen leveren (vaak binnen 24 uur ). De snelheid waarmee gegevens kunnen worden opgevraagd, hangt af van:

• De lotidentiteit moet consistent zijn bij alle evenementen.
• Gebeurtenisgegevens worden geïndexeerd op lot/tijd/handelspartner.
• transformaties die expliciet aan elkaar gekoppeld zijn (geen doodlopende wegen),
• Verzendgegevens zijn gekoppeld aan lotnummers (geen verzendingen die alleen uit SKU's bestaan).
• De export wordt gestandaardiseerd (CSV/EPCIS) in plaats van handmatig samengevoegd.

Als je vertaalspreadsheets nodig hebt om evenementen met elkaar te verbinden, zul je onder druk traag en foutgevoelig werken.

14) Praktische sjablonen: minimale werkbare vormen voor ontvangst/transformatie/verzending

Als je een "minimaal functionele" KDE-formulierenset nodig hebt, houd het dan extreem eenvoudig:

Deze sjablonen komen direct overeen met de categorieën "wie/wat/welke/hoeveel/wanneer/waar" en zijn compatibel met op gebeurtenissen gebaseerde exports.

15) Controlemaatregelen die lacunes voorkomen: harde poorten en escalatiepaden

Sjablonen voorkomen geen hiaten. Poorten wel. De meest impactvolle KDE-besturingselementen:

• Ontvangstpoort: De ontvangst kan niet worden afgesloten zonder identificatie en bestemming van de leverancierspartij.
• Transformatiepoort: Een batch kan niet worden afgesloten zonder een lijst met inkomende partijen en een toewijzing van uitgaande partijen.
• Scheepspoort: Verzending kan niet worden bevestigd zonder vastlegging van lot-/SSCC-identificatie.
• Houd de poort vast: Niet-toegestane partijen kunnen niet worden verzonden of geconsumeerd – punt uit.
• Uitzonderingsdiscipline: Elke handmatige invoer vereist verificatie en een toelichting op de reden van de wijziging; trendafwijkingen worden als KPI's beschouwd.

Als je "zonder gaten" wilt, heb je minstens deze vijf poorten nodig.

16) Testen van de KDE-gereedheid: gesimuleerde terugroepacties en doodlopende oefeningen

De enige eerlijke manier om te bewijzen dat KDE gereed is, is door het te testen. Voer het volgende commando uit:

• Gesimuleerde terugroepactie met willekeurige loting: Selecteer een voltooide partij en genereer snel de dataset voor ontvangst/transformatie/verzending.
• Leverancierslottracering: Begin bij een leverancierspartij en maak een lijst van alle afgewerkte partijen die hierdoor zijn beïnvloed (bewijs van transformatie).
• Voorwaartse traceringsoefening: Selecteer een partij en maak een lijst van alle klanten/zendingen die deze partij hebben ontvangen, inclusief de aantallen.
• Oefening met massabalans: Vergelijk de geproduceerde/verzonden/op voorraad zijnde/afvalhoeveelheid voor het geselecteerde bereik.

Elke doodlopende weg betekent dat er een tekortkoming in KDE bestaat. Verbeter de workflow en test opnieuw. Zo bereik je pas echt volwassenheid.

17) KPI's: meten van de volledigheid en afwijking van KDE

Meet het systeem zodat afwijkingen vroegtijdig worden gedetecteerd:

Wanneer het aantal uitzonderingen toeneemt, is dat geen probleem met de rapportage. Het is een probleem met de workflow: printers, scanners, de procedures voor de voorbereiding van documenten, de etikettering van leveranciers of de training.

18) Foutpatronen: hoe KDE-programma's "bestaan" maar niet werken

• Invoer achteraf. KDE's hebben de gegevens later ingevuld om audits te doorstaan; de tijdlijnen komen niet overeen met de werkelijkheid.
• Documentvervanging. Inkooporders/vrachtbrieven verstrekt zonder aan partijen gekoppelde gebeurtenisgegevens.
• Blinde vlek bij transformatie. Invoer is niet gekoppeld aan uitvoer; interne genealogie is een gok.
• Verzending per artikelnummer (SKU). Niet-vastgelegde kavels aan boord van het schip bevestigen dit; de voorwaartse tracering wordt breder.
• Handmatige invoer is genormaliseerd. Typen wordt routine; het aantal fouten neemt toe.
• Gemengde pallet-snelkoppelingen. Meerdere partijen verzonden, maar geregistreerd als één partij.
• De beslaglegging wordt niet gehandhaafd. Niet-toegestane kavels kunnen worden verplaatst en verzonden, waardoor de administratie een bekentenis wordt.

De oplossing is niet "meer papierwerk". De oplossing is het vastleggen van gebeurtenissen op het moment zelf, workflows waarbij eerst gescand wordt, strikte toegangspoorten en gecontroleerde uitzonderingen met audit trails.

19) Hoe dit in kaart wordt gebracht op V5 door SG Systems Global

V5 ondersteunt de KDE-discipline door KDE's te behandelen als workflow-uitvoer in plaats van handmatige formulieren:

• Scangestuurde ontvangst registreert leveranciersbatches, hoeveelheden en afhandelingscriteria.
• Transformatiegegevens koppelen invoerbatches aan uitvoerbatches met overeenkomende hoeveelheden.
• Scan-gestuurde verzending legt de lot-/SSCC-identificatie vast tijdens het laden, inclusief koppeling met de verzendbestemming en documentuitvoer.
• Door middel van blokkerings-/vrijgavepoorten wordt de verzending en consumptie van niet-goedgekeurde partijen voorkomen.
• Uitzonderingsworkflows registreren scanfouten en vervangingen met goedkeuringen en auditsporen.
• Exporteren ondersteunt snelle datasetrespons en, indien nodig, EPCIS-compatibele gebeurtenisgegevens.

In de praktijk maakt V5 van KDE-capture de "standaardmethode" voor het uitvoeren van de taak, zodat je mensen er later niet meer aan hoeft te herinneren om de capture te maken.

20) Uitgebreide FAQ

Vraag 1. Zijn KDE's alleen voor FSMA 204-voedingsmiddelen?
KDE's zijn een algemeen concept voor traceerbaarheid, maar FSMA 204 maakt ze expliciet voor CTE's en FTL-voedingsmiddelen. Zelfs buiten het toepassingsgebied van FSMA 204 verbetert de KDE-discipline de paraatheid voor terugroepacties en de verdedigbaarheid bij audits.

Vraag 2. Wat is de allerbelangrijkste KDE?
Lotidentificatie (TLC/lotcode). Als de lotidentificatie ontbreekt of inconsistent is, is uw dataset onbruikbaar, ongeacht hoeveel andere velden u wel heeft.

Vraag 3. Moeten we voldoen aan de EPCIS-normen?
Niet per se. EPCIS is een veelgebruikt uitwisselingsformaat, maar naleving hangt af van het snel en consistent vastleggen en produceren van de vereiste KDE-dataset. EPCIS is nuttig wanneer handelspartners een gestandaardiseerde uitwisseling vereisen.

Vraag 4. Hoe kunnen we scanfouten afhandelen zonder hiaten te creëren?
Gebruik gecontroleerde uitzonderingen: handmatige invoer met verificatie door een tweede persoon, redencode en auditlogboek. Registreer scanfouten als KPI en los de onderliggende oorzaken op (afdrukkwaliteit van labels, reiniging van de scanner, labels van de leverancier).

Vraag 5. Hoe bewijzen we dat we klaar zijn voor KDE?
Voer gesimuleerde terugroepacties met willekeurige batches uit en eis een complete dataset van ontvangst/verwerking/verzending met afgestemde aantallen. Als je deze snel kunt exporteren zonder conversie-spreadsheets, is je KDE-programma echt.

Gerelateerde lectuur (houd het praktisch)
KDE-discipline komt tot leven wanneer je scan-gestuurde systemen bouwt. ontvangende, lot-gekoppeld transformatiesen scangestuurd verzending met harde poorten die sluitingsgebeurtenissen zonder lotidentificatie voorkomen. Bewijs dit vervolgens continu met schijnbare terugroepacties en snelle datasetexporten afgestemd op Reactie binnen 24 uur verwachtingen.