arthur
7496aafe64
- Bloquants: mermaid 03-picking/_index reconstitue (archive 11-05), 13 liens vers pages squelette retires, 2 liens recibles (anoxie, application-dictionary) - Conventions: 910 em dashes -> tirets simples, 145 checklists -> puces question, 13 questions resolues barrees - Liens: 9 ancres reparees (slugs GitHub) - Delta: 12 standard_ref remappes, blocs Standard EasyWMS + sections References ajoutes, front matter complete - Glossaire: 15 termes standard deplaces en section rappel avec renvoi - Rapport: limagrain/_lint_report.md (Phase 1 + Phase 2 + re-scan final) - Inclut les pages des sessions precedentes non commitees + CLAUDE.md et consume.log en l'etat
262 lines
11 KiB
Markdown
262 lines
11 KiB
Markdown
---
|
||
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<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
|
||
|
||
```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 |
|