--- title: "Étiquette support RFID - Mono-référence & Multiréférence" tags: [inbound, outbound, RFID, étiquette, ZPL, EPC, GS1, support] status: draft standard_ref: concepts/labels.md jira_refs: [LIM-68] confluence_refs: [] sources: ["Jira LIM-68 (lecture directe)", "CR réunion évolution encodage RFID 2026-07-06"] last_updated: 2026-07-20 author: 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](../../concepts/labels.md), > [Reception](../../concepts/reception.md) et > [Stations](../../concepts/stations.md) (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](reception-fournisseur.md) - é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](../04-outbound/flux-expedition.md#étiqueteuse-automatique)). Ref. [LIM-68](https://easywmsfrance.atlassian.net/browse/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 ```zpl ^XA ; --- Encodage RFID --- ^RFW,H^FD^FS ; --- Contenu imprimé --- ^FO50,50^ADN,36,20^FD^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 ```zpl ^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](https://easywmsfrance.atlassian.net/browse/LIM-68) (commentaire 07/07/2026). ## Points d'attention - L'imprimante doit être **compatible ZPL** avec encodage RFID (choix fournisseur à valider - voir [questions ouvertes](../08-transverse/questions-ouvertes.md)) - 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](https://easywmsfrance.atlassian.net/browse/LIM-68) | Ticket Jira (9 commentaires) | 2026-03 → 2026-07 | | Réunion évolution encodage RFID | CR réunion | 2026-07-06 |