mcp-wms-wiki/wiki/limagrain/01-inbound/etiquette-rfid.md

title, tags, status, standard_ref, jira_refs, confluence_refs, sources, last_updated, author

title	tags	status	standard_ref	jira_refs	confluence_refs	sources	last_updated	author
Étiquette support RFID - Mono-référence & Multiréférence	inbound outbound RFID étiquette ZPL EPC GS1 support	draft	concepts/labels.md	LIM-68		Jira LIM-68 (lecture directe) CR réunion évolution encodage RFID 2026-07-06	2026-07-20	Arthur

Étiquette support RFID - Mono-référence & Multiréférence

Résumé : étiquette support (HU) imprimée et encodée RFID via ZPL, dans deux flux - réception fournisseur/intersite et étiqueteuse automatique en expédition. Deux rapports : mono-référence (A5 détaillé, QR Code GS1) et multiréférence (SSCC seul). Une évolution de l'encodage RFID (7 bits en banque EPC) est décidée mais en attente de validation client.

Standard EasyWMS : → voir Labels, Reception et Stations (station ETQ type 58). Ce qui suit documente les spécificités Limagrain par rapport au standard.

Contexte projet

Le client Limagrain veut un rapport d'étiquette personnalisé pour ses HU (supports). L'étiquette est produite dans deux flux :

• Réception fournisseur/intersite : impression automatique à la confirmation de création du conteneur sur le poste de travail (voir Réception fournisseur - étape 5). Réimpression possible via l'action « Imprimer étiquette » du menu poste.
• Expédition - étiqueteuse automatique : lorsque la palette arrive à la station étiqueteuse (postes de sortie TK), la station demande au WMS quoi faire ; le WMS envoie un print command avec l'un des deux rapports selon que la palette est mono ou multiréférence (voir Étiqueteuse automatique).

Ref. LIM-68 - revue de code validée (24/03/2026) pour l'encodage actuel ; évolution encodage RFID en attente client (voir plus bas).

Rapport mono-référence - Format A5

N	Champ	Source WMS	Remarque
-	Quantité	Quantité + UdM	En haut de l'étiquette
1	Code support (court)	6 derniers chiffres du code support	En gras
2	Code-barres	Code 128 du code support au format GS1
3	Code support (complet)	Code support avec préfixe (00)
4	Espèce (Specie)	ITM.CstAtt01
5	Traitement commercial	ITM.Family.Description
6	Variety print on bag	Tel quel
7	-	ITM.CstAtt03
8	Lot officiel (Official Batch)	Premier Alias de l'article
9	Lot interne (Internal Batch)	ITM.Code	= Lot SAP
10	Code GTIN	ITM.CstAtt05
11	Date	-	Vide (date non connue de l'ERP)
12	QR Code GS1	Voir section ci-dessous

QR Code GS1

Le QR Code GS1 encode les identifiants suivants :

AI (Application Identifier)	Contenu	Source
00	Numéro HU (code support)	Code support WMS
01	Code GTIN	ITM.CstAtt05
10	Lot officiel	Premier Alias de l'article
21	Lot SAP	ITM.Code
37	Quantité	Quantité déclarée

La date de production (AI 11) a été supprimée du QR Code.

Rapport multiréférence

Pour une palette multiréférence (contenu hétérogène), le rapport se limite à imprimer et encoder le code SSCC du support - aucun détail article/lot. Le SSCC est encodé en RFID selon le même mécanisme ZPL que le mono-référence.

Variante mono-référence pour l'étiqueteuse automatique

Une variante du rapport mono-référence affiche la quantité ; elle est utilisée par l'étiqueteuse automatique en expédition (demande d'optimisation du 08/06/2026).

Implémentation (workflows)

L'impression est portée par un workflow custom qui génère le code ZPL puis lance l'impression. Process : obtenir le conteneur et son stock, remplir le ZPL avec ces infos, puis appeler PrinterJobPrintDocCommand.

Élément AD	Type	Rôle
CST_PrintRFIDLabel	Workflow	Génère le ZPL et envoie l'étiquette à l'imprimante. Entrée : conteneur (code ou Id) + imprimante. L'activité code « Set label data » construit les données ZPL depuis les infos conteneur, pour un conteneur mono ou multiréférence. Termine par PrinterJobPrintDocCommand.
Reception_PrintContainerLabels_UI	Workflow	Appelle CST_PrintRFIDLabel (génère l'étiquette depuis le code conteneur) - impression en réception.
Container_MovedEvent_PR_V1	Workflow	Ajoute l'attribut taskFinish à l'activité « labeller container moved ».
Container_MovedEventHandler_Labeler_PR	Workflow	Imprime l'étiquette si une imprimante est disponible (déclenché à l'étiqueteuse auto).
CST_PrintInfo_2	Ressource	Log FR/EN : « Printing report {0} from workflow {1} ».

⚠️ Contraintes techniques :

• Le code conteneur doit faire 18 caractères (standard) pour être imprimé.
• Le format étant du ZPL, PDF24 ne fonctionne pas : il faut installer une imprimante virtuelle dédiée ZPL.
• Bonne pratique EasyWMS : tout WF qui lance une impression doit logger (d'où CST_PrintInfo_2).

Encodage RFID (ZPL) - implémentation actuelle

L'impression combine l'impression physique (texte, codes-barres) et l'encodage de la puce RFID, via des commandes ZPL (Zebra Programming Language).

Structure de base

^XA
  ; --- Encodage RFID ---
  ^RFW,H^FD<données>^FS

  ; --- Contenu imprimé ---
  ^FO50,50^ADN,36,20^FD<texte affiché>^FS
^XZ

Commandes ZPL utilisées

Commande	Rôle
^XA / ^XZ	Début et fin du bloc ZPL
^MMT	Active le mode RFID sur l'imprimante
^RS8,,,1	Timeout RFID = 8, 1 retry en cas d'échec d'encodage
^RFW,A,0,5,3	Écriture RFID en ASCII, depuis le bloc 0, sur 5 blocs (20 octets), en banque User (3)
^FD…^FS	Donnée à encoder (18 caractères max)

Exemple concret

^XA
^MMT
^RS8,,,1
^RFW,A,0,5,3^FDSupport123456789012^FS
^FO30,20^A0N,30,25^FDRapport de support^FS
^XZ

Cet encodage ASCII 8 bits en banque User (3) est l'implémentation validée en mars 2026. Il est remplacé par l'encodage 7 bits EPC ci-dessous (décision 06/07/2026, en attente).

Évolution - encodage 7 bits en banque EPC (en attente)

Statut : décidé en réunion du 06/07/2026, en attente de validation client et de la spec de packing Bartender/Eliatys. Dev non démarré.

Décision

Passage à un encodage 7 bits ASCII (table non étendue) en banque EPC, en remplacement de l'ASCII 8 bits en User memory. Motif : les HU_ID ne sont plus uniquement numériques.

Contraintes matériel

• Puce Impinj M830, EPC 128 bits, pas de mémoire User.
• Deux formats de HU_ID à encoder :
  • SSCC : 18 caractères numériques (ex. 036607231002097859)
  • Contenant réutilisable : 8 caractères alphanumériques, 4 lettres + 4 chiffres (ex. VGOC2080)
• 18 × 7 = 126 bits → tient dans 128 (marge de 2 bits, nulle au-delà de 18 caractères).

Changements dans CST_PrintRFIDLabel (activité « Set label data »)

• Le packing 7 bits n'existe pas nativement en ZPL (^RFW = A/H/E uniquement) : il doit être fait en C# dans le WF - prendre les 7 bits de poids faible de chaque caractère, concaténer (18 car. → 126 bits), padder à 128 bits, convertir en 32 caractères hexa.
• Écrire en hexa dans la banque EPC : ^RFW,H,...,1. Paramètres bloc/longueur à valider sur la ZT421 prêtée. Tester aussi ^RFW,E (gère automatiquement le mot PC / la longueur).
• La convention de packing doit être identique bit pour bit à celle de Bartender (ordre MSB/LSB, position du padding, longueur variable) - ne pas coder avant d'avoir la spec Eliatys, sinon les puces prod (SAP) et EasyWMS ne seront pas mutuellement décodables.
• Verrouillage : ajouter le perma-lock Zebra une fois l'encodage validé, et le rendre paramétrable (activable/désactivable).

Lecture côté WMS (à développer)

• Le portique CIPAM renvoie l'hexa brut ; EasyWMS décode.
• Il faut distinguer l'ancien encodage (prod déjà étiquetée cette année, numérique) du nouveau 7 bits.
• Discriminant retenu (MAJ 08/07/2026) : la longueur de l'hexa reçu. Chaque puce déclare sa longueur via son mot PC → l'inventaire renvoie 32 hexa (128 bits) pour une puce nouvelle et sa longueur d'origine (probablement 24 hexa / 96 bits) pour une legacy. Plus simple que parser le PC. Seuil exact à figer avec les échantillons legacy (action JBR/SVA).

Points de vigilance

• Lecture 96/128 bits - RÉSOLU (confirmé CIPAM, 07/2026) : les 5 premiers bits (0-4) du mot PC = longueur EPC en mots de 16 bits (8 pour 128 bits). Si le PC est bien positionné à l'écriture, l'inventaire renvoie automatiquement la bonne quantité de bits, sans reconfiguration globale des lecteurs. → À l'écriture : garantir PC = 8 mots (^RFW,E le fait ; en ^RFW,H, écrire le PC à la main).
• Perma-lock viable : le numéro de palette n'est jamais réécrit (un changement = nouvelle étiquette). À appliquer uniformément par tous les émetteurs (EasyWMS/Zebra + Bartender/SAP).

Séquencement

Dev à réaliser après : (1) validation par toutes les parties que le 7 bits convient, (2) réception de la spec de packing Bartender, (3) tests physiques écriture/lecture sur les 2 formats + impact perma-lock. Un exemple de code C# de packing/dépacking 7 bits est fourni dans le ticket LIM-68 (commentaire 07/07/2026).

Points d'attention

• L'imprimante doit être compatible ZPL avec encodage RFID (choix fournisseur à valider - voir questions ouvertes)
• Code conteneur RFID = 18 caractères (limite dure du nouvel encodage 7 bits : 18 × 7 = 126 bits ≤ 128)
• Étiquette mono-référence au format A5 paysage ; date (champ 11) volontairement vide (non connue de l'ERP en réception)
• Deux émetteurs de puces coexistent (EasyWMS/Zebra et Bartender/SAP) : la convention d'encodage et le perma-lock doivent être strictement alignés

Questions ouvertes

• Validation client du passage à l'encodage 7 bits EPC (attente réponse au mail d'Arthur) - bloque le dev
• Réception de la spec de packing Bartender (Eliatys) - prérequis dev
• Seuil exact de longueur hexa pour discriminer legacy vs nouveau encodage (échantillons legacy - action JBR/SVA)
• Tests physiques écriture/lecture sur ZT421 + impact perma-lock

Historique des modifications

Date	Auteur	Modification
2026-05-12	Arthur	Création initiale depuis LIM-68 (mono-référence)
2026-07-17	Arthur	Relecture commentaires : multiréférence (SSCC), variante étiqueteuse auto, implémentation WF (CST_PrintRFIDLabel, revue validée 24/03), évolution encodage 7 bits EPC (décision 06/07, en attente)

Références

Source	Type	Date
LIM-68	Ticket Jira (9 commentaires)	2026-03 → 2026-07
Réunion évolution encodage RFID	CR réunion	2026-07-06