Mecalux/mcp-wms-wiki
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

lint(limagrain): corrections completes Phase 1+2

Browse Source 
- 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
This commit is contained in:
Arthur
2026-07-20 12:56:42 +02:00
parent 23eb3f3c84
commit 7496aafe64
59 changed files with 6457 additions and 2023 deletions
Download Patch File Download Diff File Expand all files Collapse all files
wiki/limagrain/01-inbound/etiquette-rfid.md
+170 -37
View File
@@ -1,54 +1,65 @@
---
title: "Étiquette support RFID — Format mono-référence"
tags: [inbound, outbound, RFID, étiquette, ZPL, GS1, support]
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/reception.md
standard_ref: concepts/labels.md
jira_refs: [LIM-68]
confluence_refs: []
sources: [LIM-68_Etiquette_RFID.md]
last_updated: 2026-05-12
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 — Format mono-référence
# Étiquette support RFID - Mono-référence & Multiréférence
> **Résumé** : étiquette A5 imprimée lors de la réception
> fournisseur/intersite, contenant les informations du support (code,
> article, lot, GTIN) avec un QR Code GS1 et un encodage RFID via ZPL.
> **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 [Reception](../../concepts/reception.md)
> **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 souhaite un rapport d'étiquette personnalisé pour
ses HU (supports) dans le flux de réception fournisseur/intersite.
L'étiquette est imprimée automatiquement à la confirmation de création
du conteneur sur le poste de travail (voir
[Réception fournisseur](reception-fournisseur.md) — étape 5a). Elle
peut aussi être réimprimée depuis le menu principal du poste (action
« Imprimer étiquette »).
Le client Limagrain veut un rapport d'étiquette personnalisé pour ses HU
(supports). L'étiquette est produite dans deux flux :
Ref. [LIM-68](https://easywmsfrance.atlassian.net/browse/LIM-68) —
attente déploiement pour test.
- **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)).
## Format A5 — Contenu de l'étiquette
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 |
| - | 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` | |
| 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) |
| 11 | Date | - | Vide (date non connue de l'ERP) |
| 12 | QR Code GS1 | Voir section ci-dessous | |
## QR Code GS1
@@ -65,11 +76,47 @@ Le QR Code GS1 encode les identifiants suivants :
> La date de production (AI `11`) a été **supprimée** du QR Code.
## Encodage RFID (ZPL)
## Rapport multiréférence
L'impression de l'étiquette combine l'impression physique (texte,
codes-barres) et l'encodage de la puce RFID intégrée, le tout via
des commandes **ZPL** (Zebra Programming Language).
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
@@ -104,25 +151,111 @@ des commandes **ZPL** (Zebra Programming Language).
^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
(contrainte fournisseur à valider — voir question ouverte dans
[Réception fournisseur](reception-fournisseur.md))
- Le code support encodé en RFID fait **18 caractères** (5 blocs de
4 octets = 20 octets en banque User 3)
- L'étiquette est au format **A5 paysage**
- La date (champ 11) est volontairement vide car non connue de l'ERP
au moment de la réception
- 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 |
| 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 | 2026 |
| [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 |