Capture KDE d'expédition

Ce terme du glossaire fait partie du SG Systems Global Bibliothèque de guides réglementaires et opérationnels.

Mise à jour janvier 2026 • Données clés d'expédition FSMA 204, traçabilité sortante, confirmation d'expédition au niveau du lot, SSCC et GS1-128, preuves BOL/ASN, chaîne de traçabilité, transfert au transporteur, logique de palettes mixtes, récupération conforme aux exigences d'audit • Principalement pour la fabrication et la distribution de produits alimentaires et de boissons (FSMA 204, traçabilité SQF/BRCGS, préparation aux rappels)

La capture des éléments de données clés (KDE) lors de l'expédition est un processus rigoureux de collecte et de validation des KDE sortants requis au moment de l'expédition. Ce processus permet de prouver précisément ce qui a été expédié, les lots d'origine, les quantités , la date et le destinataire, sans avoir à reconstituer la vérité ultérieurement. Concrètement, l'expédition ne se résume pas à « envoyer une commande ». Il s'agit d'une opération de traçabilité qui doit générer des preuves liées au lot, valables lors d'un exercice de simulation de rappel , d'un exercice de rappel réel ou d'une inspection.

La collecte des données KDE relatives à l'expédition devient cruciale en vertu de la section 204 de la FSMA, car c'est lors de l'expédition que la traçabilité interne des lots se transforme en traçabilité externe (un lot en amont/un lot en aval). Si vous expédiez sans enregistrer l'identité des lots, vous pourrez certes effectuer un suivi interne, mais vous ne pourrez pas identifier avec certitude quels clients ont reçu quels lots. Cela entraîne des notifications générales et un périmètre de rappel disproportionné. C'est exactement l'inverse de ce qu'un programme de préparation aux rappels de produits bien conçu est censé offrir.

Soyons francs : la plupart des programmes de traçabilité sont performants jusqu’à l’expédition. C’est à ce moment-là que les contrôles sont le plus souvent contournés (à cause de l’affluence au quai) et que les données sont le plus souvent saisies tardivement (parce que le camion est sur le point de partir). La solution Shipping KDE Capture résout ce problème en transformant la confirmation d’expédition en un événement contrôlé et automatisé par analyse, garantissant ainsi l’exhaustivité des données avant la fermeture de la porte du camion.

« Si vous ne pouvez pas prouver quels lots ont quitté le quai dans quel camion, vous n'avez pas de traçabilité à l'exportation, vous avez juste de l'espoir. »

1) Que signifie concrètement « capture KDE d’expédition » ?

La capture KDE d'expédition signifie que vous traitez la confirmation d'expédition comme un événement de preuve contrôlée. Dès que le produit quitte votre responsabilité, vous enregistrez son identité et sa quantité, vous les associez aux identifiants du destinataire et de l'expédition, et vous conservez cet enregistrement dans une structure permettant sa récupération.

Dans un système mature, la « capture » ​​n’est pas une note libre. Il s’agit de données validées, créées par exécution :

• Les lots/caisses/palettes sont scannés, non saisis au clavier.
• Les expéditions sont liées aux objets BOL/ASN/manifeste,
• Les quantités correspondent aux prélèvements et à l'inventaire.
• Les exceptions sont capturées sous forme d'événements structurés.
• Les retenues sont appliquées afin que vous ne puissiez pas expédier ce qui ne devrait pas l'être.

Si vos KDE n'existent que parce que quelqu'un a saisi des valeurs après le départ du camion, vous n'avez pas de « capture », mais une reconstruction.

2) Pourquoi l'expédition est l'événement décisif en matière de traçabilité

L'expédition est le moment où la traçabilité devient externe. En interne, il est souvent possible de reconstituer les lots utilisés dans un processus de production grâce aux registres de production. En externe, il est impossible de savoir qui a reçu quoi si ces informations n'ont pas été enregistrées au moment de l'expédition, car les clients reçoivent des chargements mixtes, reconditionnent les produits dans les centres de distribution et dépalettisent immédiatement.

Le transport maritime engendre également des conséquences irréversibles :

• Une fois expédiée, vous en perdez le contrôle physique.
• Si l'identité est erronée, les notifications et la récupération deviennent plus générales,
• Si les quantités ne concordent pas, votre bilan massique devient suspect.
• Si vous ne pouvez pas prouver l'heure de la remise et le destinataire, votre argumentaire « un vers le haut/un vers le bas » devient fragile.

C’est pourquoi les organismes de réglementation et les clients considèrent de plus en plus la traçabilité des exportations comme une capacité de conformité essentielle, et non comme une simple tâche administrative.

3) Carte du périmètre : expéditions, transferts et mouvements sortants

La capture KDE relative aux expéditions ne se limite pas aux « envois clients ». Elle s'applique à tout événement sortant entraînant un changement de responsabilité ou de lieu ayant une incidence sur la traçabilité :

Dans chaque cas, la logique KDE est la même : capture de l’identité, de la quantité, du lieu/de l’heure et de la contrepartie.

4) KDE d'expédition principaux : ce que vous devez saisir lors de la confirmation d'expédition

Les KDE de livraison se regroupent généralement en quelques catégories. Les champs exacts varient selon le programme, le produit et le partenaire commercial, mais l'ensemble minimal viable opérationnel ressemble à ceci :

L'essentiel est que ces champs soient liés au lot. Sans ce lien, les informations « qui/quoi/combien » se réduisent à un simple enregistrement d'expédition dont la traçabilité est très limitée.

5) Modèle d'identité : lot, caisse, palette, SSCC et chargements mixtes

La réussite de la capture KDE dépend entièrement de la granularité de l'identité. Il existe trois niveaux d'identité courants :

• Au niveau du lot uniquement : Les registres d'expédition indiquent quels lots ont été expédiés, mais pas quelles caisses/palettes les contenaient.
• Au niveau du cas : Les cas sont identifiés (par exemple, GS1-128) et liés à des lots ; les expéditions capturent les cas.
• Niveau palette (SSCC) : Les palettes sont identifiées via SSCC et liées aux caisses/lots qu'elles contiennent ; les expéditions capturent les SSCC.

L'identification au niveau de la palette constitue souvent le meilleur compromis opérationnel : scanner un seul SSCC et capturer le lien vers le contenu, plutôt que de scanner chaque caisse manuellement. Cependant, cette méthode n'est valable que si les enregistrements de composition et de contenu des palettes sont exacts.

Les chargements mixtes complexifient l'identification. Une même remorque peut contenir plusieurs produits et plusieurs lots. Une même palette peut contenir des produits mixtes. Sans un suivi d'identification adéquat, la traçabilité ultérieure devient complexe et coûteuse. C'est pourquoi de nombreux logiciels associent la capture KDE d'expédition à l' identification des caisses (GS1-128) et des palettes (SSCC).

6) Capture pilotée par la numérisation : comment éliminer la « traçabilité dactylographiée »

La traçabilité par saisie est lente et sujette aux erreurs. La capture KDE pilotée par analyse est la solution idéale car l'analyse produit :

• Moins d'erreurs de transcription,
• capture d'événements horodatés,
• validation du contexte (vous pouvez rejeter les lots erronés ou les SSCC erronés),
• Confirmation d'expédition rapide sous pression,
• une preuve, conforme aux exigences d'audit, que la capture d'identité a eu lieu en temps réel.

Un flux de travail d'expédition basé sur la numérisation comprend généralement :

• Ordre de numérisation ou ID de chargement,
• emplacement de préparation du scan et affectation remorque/porte,
• numérisez les SSCC ou les étiquettes des boîtiers au fur et à mesure de leur chargement.
• vérifier que les objets scannés correspondent à la commande et sont éligibles (statut de publication),
• Clôturer l'expédition et générer les documents manifestes/BOL/ASN.

Si la numérisation est facultative, elle sera ignorée les jours de forte activité. C'est pourquoi la gestion des échecs de numérisation et des exceptions est essentielle dans le secteur de l'expédition.

7) Documents d'expédition : connaissement, avis d'expédition, manifeste et preuve de remise

La capture des données KDE relatives à l'expédition est plus fiable lorsqu'elle est liée aux documents d'expédition officiels. Un « registre de transfert » cohérent est indispensable. Les documents courants incluent :

• Connaissement (BOL): Document légal d'expédition définissant le destinataire, le transporteur et les détails du chargement.
• ASN: notification électronique au partenaire commercial, incluant souvent l'identification des caisses/palettes.
• Manifeste d'expédition: résumé détaillé de la remise (contenu du camion).
• Preuve de prise en charge : Signature du transporteur, horodatage et preuve de scellé/contrôle de porte, le cas échéant.

L'élément clé est la liaison : le bon de livraison/l'avis d'expédition/le manifeste doivent être associés aux identifiants scannés (lots/SSCC) et non générés à partir de quantités de commande génériques. Si des documents peuvent être générés sans identification de lot, la traçabilité est impossible.

8) L'expédition comme cause d'encéphalopathie traumatique chronique : preuves relatives à l'heure, au lieu et à la garde de l'événement

L’expédition est un « événement de suivi critique » dans la plupart des modèles de traçabilité car elle représente un transfert de propriété. Sur le plan opérationnel, la capture KDE des expéditions doit répondre aux questions suivantes :

• quand a eu lieu le transfert de garde (date/heure),
• où a-t-il été transféré (installation/quai) ?
• qui a pris en charge (transporteur/partenaire commercial),
• quelles identités ont été déplacées (identifiants de lot/SSCC/de dossier),
• quelle quantité déplacée (unités/poids).

C'est pourquoi la capture KDE par envoi n'est pas optionnelle si vous souhaitez un suivi rapide. Vous ne pouvez pas contacter les clients si vous ne pouvez pas prouver quels clients ont reçu quels lots.

9) Contrôles de la chaîne du froid et des voies d'acheminement : lors de l'expédition de données clés environnementales (DCE), l'intégrité de la température est prise en compte.

Pour les produits thermosensibles, la collecte des données d'expédition (KDE) s'étend souvent aux preuves d'intégrité de la chaîne du froid. Cela peut inclure :

• confirmation du pré-refroidissement de la remorque et du temps d'attente à quai,
• validation de la voie (produit froid chargé dans une remorque froide),
• Attribution et vérification des enregistreurs de température,
• vérification du joint de remorque dans le cadre de l'intégrité de la garde,
• Des exceptions sont déclenchées en cas de non-respect des exigences de temps de maintien ou de température.

Les contrôles de la chaîne du froid sont défaillants lors du transport car c'est sur le quai que le produit est exposé. Si les conditions de transport ne peuvent être prouvées, les litiges relatifs à la température en aval deviennent insolubles et l'évaluation des risques devient alors trop large et prudente.

10) Exceptions : commandes partielles, substitutions, envois fractionnés et prélèvements incomplets

La capture KDE doit pouvoir gérer les exceptions du monde réel sans compromettre la traçabilité.

Les exceptions courantes en matière d'expédition comprennent :

• Sélection courte : Quantité expédiée inférieure à la quantité commandée ; il est impératif d'enregistrer la quantité réelle et les lots expédiés.
• Substitutions Lot différent ou article de remplacement expédié ; il faut vérifier l'admissibilité et consigner le changement comme une exception vérifiable.
• Expéditions fractionnées : Une commande expédiée en plusieurs livraisons/jours ; chaque envoi doit avoir son propre package KDE.
• Palettes mixtes : Lots mixtes sur une palette ; l’identité au niveau de la caisse ou la liaison du contenu de la palette doivent être préservées.
• Retravailler/reconditionner à l'expédition : Le reconditionnement de dernière minute crée une nouvelle identité d'emballage ; l'identité du lot doit être préservée.

Un système robuste traite les exceptions comme des événements structurés, assortis d'approbations le cas échéant, et non comme de simples notes textuelles. Dans le cas contraire, le registre d'expédition devient non fiable.

11) Arrêt des expéditions et immobilisations : empêcher que la capture de KDE ne devienne une fiction

La capture KDE relative à l'expédition n'est crédible que si vous ne pouvez pas expédier les produits en attente. Si votre entrepôt peut expédier des lots en attente, votre enregistrement KDE peut sembler complet, mais cela prouve que vous avez expédié un produit que vous n'auriez pas dû. Il s'agit d'un manquement à la conformité, et non d'un problème de documentation.

La capture KDE devrait donc être intégrée à :

• maintenir/relâcher contrôle d'accès par statut,
• quarantaine blocs de mouvement,
• alertes d'exception de mouvement pour les sélections de lot ou de statut incorrects,
• La confirmation d'expédition est bloquée lorsqu'un lot inclus n'est pas éligible.

Soyons clairs : si votre ERP peut « confirmer l’expédition » sans vérifier l’éligibilité des lots, vos enregistrements de traçabilité deviennent illusoires sous la pression. Le système doit bloquer les expéditions non conformes, et non les documenter.

12) Sorties EPCIS : transformer les KDE de livraison en événements prêts pour l’échange

De nombreuses organisations utilisent EPCIS pour l'échange de données de traçabilité événementielles. L'expédition est un événement EPCIS naturel car il s'agit d'un « événement objet » et/ou d'un « événement d'expédition » comportant des informations d'identité, de date, de lieu et de contexte commercial.

La capture KDE en production prend en charge EPCIS en garantissant que l'événement comporte :

• date et lieu de l'événement,
• étape commerciale (expédition) et disposition,
• identifiants (SSCC, identifiants de cas, références de lot, le cas échéant),
• point de lecture (quai/porte) le cas échéant,
• références de transactions commerciales (ASN, BOL, PO),
• Identifiants des parties (expéditeur, destinataire, transporteur le cas échéant).

L'idée principale : si vous capturez correctement les KDE lors de la confirmation de l'expédition, la génération d'EPCIS prêts pour l'échange devient un résultat de reporting plutôt qu'un projet de données manuel.

13) Réponse en 24 heures : comment conditionner rapidement les preuves KDE sortantes

La capture des données KDE relatives à l'expédition est l'une des exigences les plus courantes en matière de réponse sous 24 heures. Lorsqu'un organisme de réglementation ou un client demande « qui a reçu ce lot », votre réponse doit être rapide et justifiée.

Un dossier de preuves KDE sortantes solide comprend généralement :

• récapitulatif d'expédition (date et heure d'expédition, adresse de livraison, transporteur, numéro de commande),
• Liste des lots et quantités expédiées,
• Identifiants SSCC/dossiers lorsqu'ils sont utilisés,
• attaché BOL et/ou ASN,
• détails du manifeste (ce qui était chargé),
• exceptions (sélections courtes, substitutions) consignées avec les raisons et les approbations,
• Confirmation de statut indiquant que les lots expédiés ont été libérés au moment de l'expédition.

Si vous pouvez effectuer ces opérations en quelques heures, le traçage direct devient une routine. Dans le cas contraire, chaque demande de traçage se transforme en casse-tête.

14) Indicateurs clés de performance (KPI) : mesure de l’exhaustivité et de la dérive des données KDE d’expédition

On ne peut améliorer ce qu'on ne mesure pas. Parmi les indicateurs clés de performance (KPI) utiles pour le suivi des expéditions chez KDE, on peut citer :

Une fréquence élevée d'exceptions n'est pas toujours négative ; elle peut refléter la réalité. Le risque réside dans les exceptions non documentées, non autorisées ou incohérentes. Il s'agit alors de défaillances de traçabilité.

15) Posture d'audit : ce que les auditeurs testent en profondeur dans les documents d'expédition

Les auditeurs testent la robustesse de la capture KDE en demandant une traçabilité ascendante. Ils sélectionnent souvent un lot fini et demandent :

• quels clients l'ont reçu,
• quels chargements le transportaient et quand,
• combien a été expédié,
• quels produits restent en stock,
• Comment savoir si l'enregistrement est complet et non reconstitué ?

Ils peuvent également vous demander de démontrer que les blocages empêchent l'expédition : tentez d'expédier un lot bloqué (de manière contrôlée) et prouvez que le système le bloque. Si le blocage n'existe pas, la capture KDE d'expédition n'est pas crédible car le système peut expédier des produits en dehors des règles de traçabilité établies.

16) Copier/coller le tableau de bord de préparation

Utilisez ceci comme un test interne sans détour. Si vous ne trouvez pas de réponse claire, corrigez le processus, pas la formulation.

17) Schémas d'échec : comment la capture KDE est falsifiée

• Registres d'expédition des commandes uniquement. Les expéditions sont enregistrées par UGS sans numéro de lot ; le suivi ultérieur devient plus complexe.
• Numéros de lot dactylographiés. Beaucoup de texte saisi de mémoire ; le risque d'erreurs de transcription et de corrections ultérieures augmente.
• ASN/BOL non liés à des identités. Des documents existent, mais ils ne prouvent pas quels lots ont été chargés.
• Cécité gustative mixte. Les palettes contiennent plusieurs lots, mais un seul lot est enregistré.
• Les exceptions sont gérées verbalement. Les substitutions et les scissions se produisent sans capture structurée.
• Contenir les fuites. Le statut indique « attente », le quai est toujours occupé ; le pire type de défaillance de contrôle.
• Reconstitution a posteriori. Les KDE sont intervenus ultérieurement pour « faire fonctionner la traçabilité ». Les auditeurs peuvent le constater.

La solution est toujours la même : confirmation d’expédition basée sur l’analyse, validation stricte, exceptions structurées et contrôles stricts empêchant les expéditions non admissibles.

18) Comment cela correspond à V5 par SG Systems Global

La version 5 prend en charge la capture KDE pour l'expédition en faisant de l'expédition un événement contrôlé et piloté par analyse, lié à la généalogie des lots et aux documents d'expédition. Concrètement, la version 5 permet de :

• Confirmation de capture liée au lot d'expédition à l'aide des scans SSCC/de cas et des règles de validation,
• générer les manifestes sortants et les lier à BOL/ASN objets,
• imposer maintenir/relâcher ce système de blocage empêche l'expédition des lots non éligibles.
• Capture des exceptions structurées (substitutions, prélèvements partiels, expéditions fractionnées) avec approbations,
• produire des résultats de traçabilité rapides (« qui a reçu ce lot ») et un support un-up/un-down paquets de suivi,
• exporter des données événementielles pour les normes d'échange telles que Prolongation EPCIS au besoin.

Ces contrôles s'intègrent naturellement aux systèmes V5 WMS (exécution des expéditions et contrôle des mouvements), V5 MES (généalogie des lots et liaison avec la production) et V5 QMS (mises en attente, écarts et exceptions gérées). L'API V5 Connect assure l' intégration aux systèmes ERP et aux systèmes des transporteurs .

19) FAQ étendue

Q1. La capture KDE est-elle uniquement requise pour l'expédition des aliments relevant de la FSMA 204 ?
La norme FSMA 204 est un facteur déterminant, mais de nombreux programmes clients et audits GFSI exigent également un lien précis entre les lots sortants et les produits concernés. Même en dehors des catégories couvertes par la norme FSMA 204, ce lien est essentiel pour des rappels de produits précis et justifiés.

Q2. Quel est le moyen le plus rapide d'améliorer la capture KDE lors de l'expédition ?
Passez à une confirmation d'expédition basée sur la numérisation. Si vous saisissez encore les numéros de lot manuellement, vous risquez des erreurs et des erreurs de saisie. L'expédition via SSCC représente souvent la mise à niveau la plus avantageuse pour les opérations sur palettes.

Q3. Quels sont les principaux problèmes rencontrés par KDE lors de l'expédition ?
Palettes mixtes et substitutions de dernière minute. Sans identification précise des caisses/palettes et sans gestion des exceptions, la traçabilité devient imprécise et peu fiable.

Q4. Comment gérons-nous les livraisons partielles ?
Considérez chaque envoi comme un événement KDE distinct : enregistrez l’identité, les quantités et les documents pour chaque envoi partiel. Ne fusionnez pas les envois partiels en un seul enregistrement ultérieurement, car cela crée une ambiguïté.

Q5. Comment prouver que le système est réel ?
Effectuez un test de traçabilité en amont d'un rappel de produit : sélectionnez un lot fini et générez rapidement le dossier « qui l'a reçu » (expéditions, clients, quantités et documents associés : bon de livraison/avis d'expédition/manifeste). Si cela nécessite une intervention manuelle, votre système de capture KDE n'est pas encore au point.

Lectures complémentaires (restez pratique)
La capture KDE pour l'expédition devient durable lorsqu'elle est associée à une identité forte au niveau du boîtier/de la palette (GS1-128 et SSCC), capture d'événements validée (Prolongation EPCIS), et un confinement exécutoire (maintenir/relâcher (avec blocage des expéditions). Prouvez-le ensuite par exercices de rappel et des packages de suivi rapide qui prennent en charge les exigences de réponse des enregistrements en 24 heures.