lint(limagrain): corrections completes Phase 1+2

- 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
2026-07-20 12:56:42 +02:00
parent 23eb3f3c84
commit 7496aafe64
59 changed files with 6457 additions and 2023 deletions
@@ -1,11 +1,11 @@
 ---
-title: "Inbound — Vue d'ensemble"
+title: "Inbound - Vue d'ensemble"
 tags: [inbound, index]
 status: draft
 last_updated: 2026-05-12
 ---

-# Inbound — Vue d'ensemble
+# Inbound - Vue d'ensemble

 > **Périmètre** : réception fournisseur, retours, contrôle qualité à réception,
 > messages ERP inbound.
@@ -15,11 +15,11 @@ last_updated: 2026-05-12

 ## Pages de cette section

- [Gestion des camions](gestion-camions.md) — arrivée, quais, déclaration image de quai
+- [Gestion des camions](gestion-camions.md) - arrivée, quais, déclaration image de quai
 - [Réception fournisseur](reception-fournisseur.md)
 - [Réception retour](reception-retour.md)
 - [Contrôle qualité réception](controle-qualite-reception.md)
- [Étiquette RFID](etiquette-rfid.md) — format A5, QR GS1, encodage ZPL
+- [Étiquette RFID](etiquette-rfid.md) - format A5, QR GS1, encodage ZPL
 - [Flux ERP inbound](flux-erp-inbound.md)

 ## Vue synthétique du flux inbound Limagrain
@@ -1,16 +1,16 @@
 ---
-title: "Contrôle qualité réception — Vérification poids PIE"
+title: "Contrôle qualité réception - Vérification poids PIE"
 tags: [inbound, PIE, poids, verrou, inventaire, qualité]
 status: draft
 standard_ref: architecture/galileo-integration.md
-jira_refs: [LIM-66]
+jira_refs: [LIM-66, LIM-108, LIM-114]
 confluence_refs: []
-sources: [FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5.docx, "Réception - LIMAGRAIN - DEV - Confluence.md", LIM-66_Passage_PIE.md, wiki-update-poids-PIE-tolerance.md]
-last_updated: 2026-05-13
+sources: [FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5.docx, "Réception - LIMAGRAIN - DEV - Confluence.md", LIM-66_Passage_PIE.md, wiki-update-poids-PIE-tolerance.md, "Jira LIM-108 (lecture directe 2026-07-20)"]
+last_updated: 2026-07-20
 author: Arthur
 ---

-# Contrôle qualité réception — Vérification poids PIE
+# Contrôle qualité réception - Vérification poids PIE

 > **Résumé** : mécanisme [CUSTOM] de contrôle de poids au passage PIE avec
 > calcul de tolérance par type article, application automatique de verrous
@@ -39,20 +39,20 @@ Le PIE effectue les contrôles suivants :
 | Poids | ≤ 1250 kg |
 | État palette bois | Correct (lames TK ne doivent pas toucher le bois, pas de ski manquant) |

-> Les erreurs sont configurables par type dans easyS — possibilité
+> Les erreurs sont configurables par type dans easyS - possibilité
 > d'envoyer vers différentes destinations selon le type d'erreur
 > (station error type). Exemple : scotch qui dépasse → station de
 > reconditionnement, palette vraiment non conforme → rejet complet.

 ## Formule de calcul du poids

-### Étape 1 — Poids des lignes de stock
+### Étape 1 - Poids des lignes de stock

 ```
 Poids lignes de stock = Poids total mesuré − Poids théorique support (PALETTE_US)
 ```

-### Étape 2 — Répartition au prorata entre lignes de stock
+### Étape 2 - Répartition au prorata entre lignes de stock

 Le poids mesuré est réparti au prorata entre les différentes lignes
 de stock.
@@ -78,7 +78,7 @@ Poids mesuré au PIE = 60 kg (hors palette bois).
 | B (× 1) | 40 kg (ITM) | 80 % | 48 kg |
 | **Total** | 50 kg | 100 % | **60 kg** |

-### Étape 3 — Mise à jour du poids unitaire (CstAtt01)
+### Étape 3 - Mise à jour du poids unitaire (CstAtt01)

 Le **CstAtt01** de chaque ligne de stock est mis à jour avec le poids
 unitaire mesuré :
@@ -93,15 +93,20 @@ Poids unitaire mesuré = Poids réel de la ligne / Quantité de la ligne
 | Poids réel pesé (total) | Champ standard « poids balance » du support |
 | Poids réel de la ligne | Champ « Poids réel » de la ligne de stock |

-> **Priorité CstAtt01** : si CstAtt01 a déjà une valeur (pesée
-> précédente), c'est ce poids unitaire qui est utilisé comme référence
-> pour **tous les calculs du passage PIE** — ratio (étape 2) **et**
-> seuil de tolérance (vérification ci-dessous) — à la place du poids
-> théorique ITM.
+> **Priorité CstAtt01 (répartition uniquement)** : si CstAtt01 a déjà une
+> valeur (pesée précédente), c'est ce poids unitaire qui est utilisé pour
+> la **répartition au prorata** (étape 2), à la place du poids ITM.
+>
+> ⚠️ **Mise à jour 19/06/2026** : cette priorité **ne s'applique plus au
+> seuil de tolérance**. La détection d'écart utilise désormais **toujours
+> le poids ITM théorique** (voir section suivante). L'idée d'utiliser
+> CstAtt01 comme seuil (validée client en mai 2026) a été **abandonnée** :
+> une pesée très erronée fixerait un CstAtt01 aberrant qui fausserait le
+> seuil des passages suivants.

-> **Mise à jour du stock : OUI** — le poids calculé est stocké dans
+> **Mise à jour du stock : OUI** - le poids calculé est stocké dans
 > CstAtt01 de la ligne de stock.
-> **Mise à jour de l'ITM : NON** — le poids théorique de la fiche
+> **Mise à jour de l'ITM : NON** - le poids théorique de la fiche
 > article reste inchangé. Raison : le poids varie en fonction de la
 > production (début/fin de prod), chaque pesée est unique.

@@ -110,40 +115,43 @@ Poids unitaire mesuré = Poids réel de la ligne / Quantité de la ligne

 ## Vérification de la tolérance et blocage

-Ref. [LIM-66](https://easywmsfrance.atlassian.net/browse/LIM-66) — en
-revue de code.
+Ref. [LIM-66](https://easywmsfrance.atlassian.net/browse/LIM-66) - **en
+cours de test client (pré-production)**.

 ### Poids de référence pour le seuil de tolérance

-Le "poids unitaire de l'article" utilisé comme seuil de tolérance suit
-la même règle de priorité que le ratio :
+> ⚠️ **Décision finale (19/06/2026)** : le seuil de tolérance utilise
+> **toujours le poids unitaire ITM théorique** (conversion article), quel
+> que soit l'état de CstAtt01.

-| Situation | Poids de référence utilisé |
-|-----------|---------------------------|
-| CstAtt01 renseigné (pesée précédente) | **CstAtt01** (poids unitaire mesuré) |
-| CstAtt01 vide (premier passage PIE) | **Poids ITM** (conversion article) |
+| Situation | Poids de référence pour le seuil |
+|-----------|----------------------------------|
+| Premier passage PIE **et** passages suivants | **Poids ITM** (conversion article) |

-**Conséquence sur les passages successifs** : après un premier passage
-PIE qui recalibre le poids unitaire (ex. ITM = 10 kg, mesuré = 30 kg),
-le seuil de tolérance au passage suivant sera basé sur 30 kg (CstAtt01).
-Un écart de 20 kg (2 unités au poids ITM d'origine) ne déclenchera pas
-de blocage car il reste inférieur à 1 unité au poids recalibré (30 kg).
+**Historique de la décision** : une première approche (mai 2026, validée
+client) prévoyait un seuil **dynamique** basé sur CstAtt01 (dernier poids
+mesuré) si renseigné, sinon ITM. Elle a été **abandonnée le 19/06/2026** :
+si une pesée très erronée fixe un CstAtt01 aberrant, comparer les pesées
+suivantes à ce seuil fausserait la détection. Le seuil est donc revenu au
+poids **théorique ITM**, stable et fiable.

-> Validé par le client (échange Justine BEUTIN / Olivier, mai 2026).
+> **Note** : CstAtt01 reste calculé et mis à jour à chaque pesée (étape 3)
+> et sert à la **répartition au prorata**, mais **plus** au seuil de
+> tolérance.

 ### [CUSTOM] Palettes mono-référence

 **Condition de blocage** : si l'écart de poids correspond à un écart
 d'une ligne de stock (article manquant ou en trop → écart ≥ poids
-unitaire de référence, cf. tableau ci-dessus) → blocage via verrou sur
-le **support** (pas sur le stock) + alerte SmartUI.
+unitaire **ITM** de l'article) → blocage via verrou sur le **support**
+(pas sur le stock).

-### [CUSTOM] Palettes multi-références — seuil d'alerte
+### [CUSTOM] Palettes multi-références - seuil d'alerte

 Pour les palettes contenant plusieurs articles différents, le système
-utilise le **plus petit poids unitaire de référence** (CstAtt01 si
-renseigné, sinon ITM, par ligne) comme seuil d'alerte. Si l'écart
-total ≥ ce plus petit poids → blocage + alerte.
+utilise le **plus petit poids unitaire ITM** parmi toutes les lignes de
+stock comme seuil d'alerte. Si l'écart total ≥ ce plus petit poids →
+blocage.

 ### Verrous appliqués

@@ -154,12 +162,17 @@ Deux verrous possibles selon le flux :
 | **HORS TOLERANCE** | Tous sauf retour client | La palette **entre quand même dans l'ASRS** malgré le verrou |
 | **ECART RETOUR** | Retour client uniquement | La palette est **refusée et envoyée en rejet** (destination gérée par EasyS) |

-### Notification
+### Gestion de l'erreur

- Création d'une **notification SmartUI** via le circuit classique de
-  notifications basé sur un event (pas d'event custom)
+- La notification SmartUI custom envisagée initialement a été
+  **abandonnée** (barrée dans la spec). Le custom
+  `PIE_EventHandler_CheckToleranceWeight_PR` **redirige vers l'erreur de
+  poids standard** EasyWMS en cas de dépassement de tolérance.
 - Le verrou est posé sur le **support** (pas sur le stock)
- Notification dédiée au rejet générée dans le cas ECART RETOUR
+- Le **flux de rejet PIE** (toutes causes : dimension, poids, étiquette,
+  palette bois), avec renvoi au **poste de travail d'origine**, est documenté
+  dans [Flux de rejet PIE](../02-stockage/rejet-pie.md) (LIM-114). Il remplace
+  l'approche « poumon au sol + notification SmartUI ».

 ### Comportement selon le flux (détail)

@@ -174,7 +187,7 @@ Deux verrous possibles selon le flux :

 Dans tous les cas, le poids est quand même appliqué et recalculé.

-### [CUSTOM] Type ZSIZ — Ajustement automatique
+### [CUSTOM] Type ZSIZ - Ajustement automatique

 Si le type d'article est **ZSIZ** (semi-fini calibré / big-bag), un
 message d'ajustement de stock est envoyé vers SAP via **WSC** contenant
@@ -191,6 +204,36 @@ le poids réel de la HU, **indépendamment de la tolérance**.
 - Le flag d'écart de poids est inclus dans le fichier **LOC** envoyé
  à SAP

+## [SIMULATION] Poids théorique en l'absence de poids Galileo (LIM-108)
+
+> **Statut (LIM-108)** : en cours de test client (pré-production). Mode de
+> fonctionnement **temporaire** pour la simulation.
+
+Lors du passage au PIE, le poids **n'est pas toujours descendu** dans l'event
+Galileo si la palette n'est **pas créée au PIE** (simple passage par la
+station). Dans ce cas, un mode simulation permet de récupérer le **poids
+théorique du conteneur** et de l'utiliser à la place du poids de l'event
+Galileo.
+
+Ce mode est gouverné par le toggle `CST_SimulatePIEScale` (voir
+[Paramètres projet - Toggles](../07-admin/parametres-projet.md#toggles)) :
+quand il est actif, le WMS vérifie si l'event PIE porte un poids ; sinon il
+substitue le poids théorique du conteneur. Sans poids récupéré, les règles
+de poids ([formule](#formule-de-calcul-du-poids), tolérance) s'appliquent
+ensuite normalement.
+
+## Implémentation technique (AD customs)
+
+| Élément AD | Type | Rôle |
+|-----------|------|------|
+| `CST_PIE_ApplyWeightRules_PR` | Workflow | Applique les contrôles et opérations liés au poids au passage PIE. Corrigé (LIM-108, Maxime 18/06/2026) suite à un changement de version. |
+| `PIE_EventHandler_CheckInvalidWeightWithScale_PR` | Workflow | [SIMULATION, LIM-108] Si `CST_SimulatePIEScale` actif : vérifie si l'event porte un poids ; sinon récupère le poids théorique du conteneur et l'utilise. |
+| `PIE_EventHandler_CheckToleranceWeight_PR` | Workflow | Contrôle de tolérance ; redirige vers l'erreur de poids standard en cas de dépassement |
+| `CST_SimulatePIEScale` | Toggle | [SIMULATION, LIM-108] Active la simulation du poids d'event PIE. |
+| `CST_StockView` | Entité | Affiche le CstAtt01 avec le bon type décimal |
+| `CST_Stocks_ForView` | Query | Query de l'entité `CST_StockView` |
+| `StockVList` | View | Affichage du CstAtt01 (poids unitaire mesuré) |
+
 ## Gestion des verrous

 ### Consultation
@@ -220,33 +263,41 @@ de travail **autoriser** la palette à passer le PIE même si hors tolérance.

 ## Points d'attention

-⚠️ Le contrôle poids s'applique à **chaque** passage PIE — une palette
+⚠️ Le contrôle poids s'applique à **chaque** passage PIE - une palette
 peut passer le PIE plusieurs fois (réception → picking → restockage).

 ⚠️ Le poids est porté par le **stock** (CstAtt01 de la ligne), pas par
-la fiche article ITM — chaque pesée est unique.
+la fiche article ITM - chaque pesée est unique.

 ⚠️ Les palettes avec verrou « Réception » sont prioritaires dans
 l'assignation de stock pour l'échantillonnage (permet de combiner
 recomptage + échantillonnage).

-⚠️ Verrou posé sur le **support** (pas sur le stock) — différent du
+⚠️ Verrou posé sur le **support** (pas sur le stock) - différent du
 comportement standard.

 ⚠️ Pour les palettes multi-références, le seuil d'alerte est le plus
-petit poids unitaire parmi toutes les lignes de stock.
+petit poids unitaire **ITM** parmi toutes les lignes de stock.

-⚠️ Après un passage PIE qui recalibre fortement le poids (ex. ITM
-10 kg → CstAtt01 30 kg), le seuil de tolérance au passage suivant
-est proportionnellement plus large. C'est le comportement attendu :
-chaque pesée fait foi pour la suivante.
+⚠️ Le seuil de tolérance est basé sur le poids **ITM théorique** (fixe),
+pas sur CstAtt01 (décision 19/06/2026). CstAtt01 sert uniquement à la
+répartition au prorata et à l'inventaire par pesée, et n'influence plus
+la détection d'écart.
+
+⚠️ [SIMULATION, LIM-108] Le repli sur le poids théorique du conteneur
+(toggle `CST_SimulatePIEScale`) est un mode **temporaire** de simulation :
+il ne doit pas rester actif quand les palettes sont réellement créées et
+pesées au PIE.

 ## Questions ouvertes

- [x] Tolérances : le seuil est dynamique (CstAtt01 > ITM), validé par
-  le client (mai 2026). Pas de valeur fixe par type article.
- [ ] Valeur du poids palette bois fixe (PALETTE_US) (@Théo)
- [ ] Poids variable — vérifier si le standard gère la capture de
+- **Résolu (19/06/2026)** - Tolérances : le seuil est finalement basé sur
+  le poids **ITM théorique** (fixe). L'approche dynamique CstAtt01 > ITM
+  (validée client mai 2026) a été abandonnée.
+- **Ouvert** - Envoi d'un **STV** ou non lors de l'ajustement de stock pour
+  mettre à jour le poids (@Vincent)
+- **Ouvert** - Valeur du poids palette bois fixe (PALETTE_US) (@Théo)
+- **Ouvert** - Poids variable : vérifier si le standard gère la capture de
  poids avec poids moyen activé (@Nicolas)

 ## Historique des modifications
@@ -257,6 +308,8 @@ chaque pesée fait foi pour la suivante.
 | 2026-05-05 | Arthur | Enrichissement : prorata, multi-ref, verrou support, ZSIZ timing |
 | 2026-05-12 | Arthur | LIM-66 : verrous HORS TOLERANCE / ECART RETOUR, CstAtt01 poids unitaire, comportement post-PIE |
 | 2026-05-13 | Arthur | Clarification tolérance CstAtt01 > ITM pour passages PIE successifs (validation client) |
+| 2026-07-16 | Arthur | LIM-66 : **abandon** du seuil CstAtt01 → retour au poids ITM théorique (décision 19/06) ; notification SmartUI abandonnée (redirection erreur standard) ; ajout éléments AD ; statut pré-production ; point ouvert STV ; rejet ECART RETOUR → LIM-114 |
+| 2026-07-20 | Arthur | LIM-108 (lecture directe, pré-production) : section [SIMULATION] repli sur poids théorique du conteneur quand l'event Galileo PIE ne porte pas de poids (palette non créée au PIE), toggle `CST_SimulatePIEScale`, WF `PIE_EventHandler_CheckInvalidWeightWithScale_PR` ; note correction `CST_PIE_ApplyWeightRules_PR` (changement de version) ; point d'attention mode temporaire ; front matter jira_refs/sources/last_updated |

 ## Références

@@ -264,5 +317,7 @@ chaque pesée fait foi pour la suivante.
 |--------|------|------|
 | FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5 | Analyse fonctionnelle | 28/11/2025 |
 | Réception - LIMAGRAIN - DEV - Confluence | Page ateliers DEV | 2026 |
-| [LIM-66](https://easywmsfrance.atlassian.net/browse/LIM-66) | Ticket Jira | 2026 |
-| Échange Justine BEUTIN / Olivier (Limagrain) | Validation client | mai 2026 |
+| [LIM-66](https://easywmsfrance.atlassian.net/browse/LIM-66) | Ticket Jira (PIE poids/verrous - pré-production) | 2026 |
+| [LIM-108](https://easywmsfrance.atlassian.net/browse/LIM-108) | Ticket Jira (simulation poids PIE - pré-production) | 2026 |
+| [LIM-114](https://easywmsfrance.atlassian.net/browse/LIM-114) | Ticket Jira (flux de rejet PIE) | 2026 |
+| Échange Justine BEUTIN / Olivier (Limagrain) | Validation client (approche mai 2026, révisée 19/06) | mai 2026 |
@@ -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 |
@@ -1,8 +1,8 @@
 ---
-title: "Flux ERP inbound — Messages réception"
+title: "Flux ERP inbound - Messages réception"
 tags: [inbound, ERP, ASN, ROR, ROF, REF, ITM, interface]
 status: draft
-standard_ref: architecture/erp-integration.md
+standard_ref: concepts/erp-interface.md
 jira_refs: []
 confluence_refs: []
 sources: [FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5.docx, "CR CONSOLIDES REU ERP LIMAGRAIN V1 - CR.md"]
@@ -10,7 +10,7 @@ last_updated: 2026-05-06
 author: Arthur
 ---

-# Flux ERP inbound — Messages réception
+# Flux ERP inbound - Messages réception

 > **Résumé** : catalogue des messages ERP liés aux processus de réception
 > chez Limagrain, avec direction, déclencheur et contenu principal.
@@ -27,7 +27,7 @@ Pour les messages d'expédition, voir

 ## Messages entrants (SAP → EasyWMS)

-### ITM — Item Master
+### ITM - Item Master

 | Champ | Description |
 |-------|-------------|
@@ -39,13 +39,13 @@ Pour les messages d'expédition, voir
 > ⚠️ Chez Limagrain, les **lots SAP** sont gérés comme des articles (descendus
 > via ITM). L'article Limagrain est un attribut du lot SAP.

-### ASN — Advanced Shipping Notice
+### ASN - Advanced Shipping Notice

 | Champ | Description |
 |-------|-------------|
 | Direction | ERP → WMS |
 | Déclencheur | Création HU avec code SSCC en production |
-| Architecture | **1 ASN = 1 palette de production** (pas d'agrégation — permet suppression individuelle en cas d'annulation) |
+| Architecture | **1 ASN = 1 palette de production** (pas d'agrégation - permet suppression individuelle en cas d'annulation) |
 | Contenu | Numéro HU, article, lot SAP, [CUSTOM] propriétaire Limagrain, statut de stock, quantité (unités de vente) |
 | Timing | Envoyé dès création de la HU avec code SSCC |

@@ -65,7 +65,7 @@ statut (champ vide ou absent du JSON).
 Height/Volume (recalculé au pesage PIE), dates fabrication/expiration,
 numéro de série.

-### ROR — Reception Order Request
+### ROR - Reception Order Request

 | Champ | Description |
 |-------|-------------|
@@ -80,7 +80,7 @@ numéro de série.
 |-------------|-------|--------------------------|-----------|
 | 0 (Fournisseur) | Livraisons DESADV | SupplierCode = "FOURNISSEUR" | Précisée par SAP (override profil) |
 | 1 (Retour) | Retours clients ORDRSP | AccountCode = "CLIENT" | Illimitée (ReceiveLessAllowed=true) |
-| 3 (Transfert) | Transferts inter-sites | — | 0% (palettes identifiées) |
+| 3 (Transfert) | Transferts inter-sites | - | 0% (palettes identifiées) |

 **Paramètres clés** : SingleReceipt = true (pas de reliquat WMS),
 FreeQuantity non nécessaire. Pas de SSCC dans le ROR (récupéré au scan
@@ -98,7 +98,7 @@ RFID en réception).

 ## Messages sortants (EasyWMS → SAP)

-### REF — Reception Fulfilled
+### REF - Reception Fulfilled

 | Champ | Description |
 |-------|-------------|
@@ -109,7 +109,7 @@ RFID en réception).
 | Contrainte | L'emplacement de rangement n'est connu qu'après le stockage en ASRS → attendre que toutes les palettes soient stockées avant d'envoyer le REF |
 | Données | S'appuie sur les données **réelles** (pas théoriques) |

-### ROF — Reception Order Fulfilled
+### ROF - Reception Order Fulfilled

 | Champ | Description |
 |-------|-------------|
@@ -119,7 +119,7 @@ RFID en réception).
 | Reliquats | Pas de gestion de reliquats par EasyWMS. Si réception incomplète, c'est SAP qui gère le reliquat |
 | Hors tolérance | ROF bloqué jusqu'à régularisation par le manager dans SAP (customisation requise) |

-### [CUSTOM] LOC — Location
+### [CUSTOM] LOC - Location

 | Champ | Description |
 |-------|-------------|
@@ -128,7 +128,7 @@ RFID en réception).
 | Contenu | Numéro HU, station départ, station arrivée, workzone arrivée, emplacement arrivée |
 | Condition | Généré uniquement si stations départ et arrivée sont différentes |

-## Diagramme de séquence — Réception production
+## Diagramme de séquence - Réception production

 ```mermaid
 sequenceDiagram
@@ -147,7 +147,7 @@ sequenceDiagram
    WMS->>SAP: LOC (emplacement)
 ```

-## Diagramme de séquence — Réception extérieure
+## Diagramme de séquence - Réception extérieure

 ```mermaid
 sequenceDiagram
@@ -174,7 +174,7 @@ sequenceDiagram
 ⚠️ Le message REF est retardé jusqu'à validation PIE de tous les conteneurs
 (peut prendre du temps si file d'attente PIE longue).

-⚠️ Le message LOC n'est pas standard — c'est un [CUSTOM] spécifique
+⚠️ Le message LOC n'est pas standard - c'est un [CUSTOM] spécifique
 Limagrain pour traçabilité emplacement dans SAP.

 ⚠️ Les modifications dans les master data ne doivent **pas** être faites
@@ -185,7 +185,7 @@ directement dans EasyWMS (risque d'écrasement par prochain ITM).
 | Date | Auteur | Modification |
 |------|--------|--------------|
 | 2026-05-05 | Arthur | Création initiale depuis AF V1.5 |
-| 2026-05-06 | Arthur | Enrichissement ASN (1 par palette, attributs logistiques, champs non utilisés), ROR (InboundType, tolérances, SingleReceipt), REF (clôture manuelle, zone stockage, contrainte rangement), ROF (rôle, reliquats, hors tolérance) — depuis CR consolidé ERP |
+| 2026-05-06 | Arthur | Enrichissement ASN (1 par palette, attributs logistiques, champs non utilisés), ROR (InboundType, tolérances, SingleReceipt), REF (clôture manuelle, zone stockage, contrainte rangement), ROF (rôle, reliquats, hors tolérance) - depuis CR consolidé ERP |

 ## Références

@@ -1,16 +1,16 @@
 ---
-title: "Gestion des camions — Arrivée, quais et déclaration image de quai"
+title: "Gestion des camions - Arrivée, quais et déclaration image de quai"
 tags: [inbound, camion, quai, TRF, image-de-quai, étiquette, SmartUI]
 status: draft
 standard_ref: concepts/reception.md
-jira_refs: [LIM-62, LIM-63, LIM-64, LIM-65]
+jira_refs: [LIM-62, LIM-63, LIM-64, LIM-65, LIM-96, LIM-97, LIM-102]
 confluence_refs: []
-sources: [LIM-62_gestion-camions.md, LIM-63_64_65.md]
-last_updated: 2026-05-06
+sources: [LIM-62_gestion-camions.md, LIM-63_64_65.md, "Jira LIM-96 (V2, préprod, revue de code validée 25/06)", "Jira LIM-97 (Gestion camions V2, préprod, validé Vincent 02/07)"]
+last_updated: 2026-07-20
 author: Arthur
 ---

-# Gestion des camions — Arrivée, quais et déclaration image de quai
+# Gestion des camions - Arrivée, quais et déclaration image de quai

 > **Résumé** : flux complet depuis l'arrivée physique d'un camion jusqu'à la
 > déclaration des palettes sur une image de quai (poumon de réception). Couvre
@@ -24,6 +24,15 @@ author: Arthur
 > camions (plaque, quai, affichage chauffeur) et un workflow TRF dédié pour la
 > déclaration des palettes sur les images de quai.

+> **Statut Jira (20/07/2026)** : LIM-62 (Gestion camions **V1**) est **clôturé /
+> annulé** (validation fonctionnelle par Justine le 27/05/2026). La suite est
+> reprise par
+> [LIM-97 - Gestion camions V2](https://easywmsfrance.atlassian.net/browse/LIM-97)
+> (**En cours de test client / préprod**, validée par Vincent Charvet le
+> 02/07/2026). Les étapes 1 et 2 ci-dessous intègrent le détail définitif V2,
+> dont le mécanisme **faux stage / vrai stage** d'assignation de l'image de
+> quai.
+
 ## Contexte projet

 Chez Limagrain, le flux de réception commence **avant** le déchargement : un
@@ -65,14 +74,14 @@ sequenceDiagram
    AGV->>AGV: Récupère palettes sur image de quai
 ```

-## Étape 1 — Annonce du camion (LIM-62)
+## Étape 1 - Annonce du camion (LIM-62)

 ### Création de la réception

 L'agent de quai accède à la vue **Ordre d'entrée > Réceptions** dans SmartUI.
 Il crée une nouvelle réception en saisissant :

- **Plaque d'immatriculation** (champ "Camion", ex-"Document") — non
+- **Plaque d'immatriculation** (champ "Camion", ex-"Document") - non
  obligatoire à la création, peut être renseignée après coup
 - **Destination** : `PARKING` (quai fictif d'attente) par défaut, ou un quai
  réel si disponible
@@ -93,20 +102,60 @@ Ce contrôle est implémenté dans le `VAssistCreateReceptionOE` (steps 2 et 3)
 et dans la vue des ordres d'entrées. L'exception compare le `InboundClassCode`
 de chaque OE sélectionné au premier de la liste.

-## Étape 2 — Assignation du quai (LIM-62)
+## Étape 2 - Assignation du quai ET de l'image de quai (LIM-62 → LIM-97 V2)

 L'agent consulte les disponibilités via le **tableau d'occupation des quais**
-(ViewDetailPanel dans la vue `ReceptionVList`). Il sélectionne la réception et
-assigne un quai réel.
+(ViewDetailPanel dans la vue `ReceptionVList`). Il sélectionne la réception,
+puis assigne **deux éléments** :
+
+- un **quai réel** (`QUAI_01` à `QUAI_06`) ou le quai fictif `PARKING` ;
+- une **image de quai** (poumon de réception) sur laquelle les palettes seront
+  déposées.
+
+L'assignation se fait au niveau de l'image de quai **prise comme une unité**,
+et non au niveau de ses 26 sous-emplacements.
+
+### Mécanisme faux stage / vrai stage (V2)
+
+> [CUSTOM] Contournement mis en place car EasyWMS ne sait pas assigner une
+> image de quai comme un objet unique.
+
+Écart constaté au développement (LIM-97) par rapport à la tâche initiale
+LIM-62 :
+
+- Aucune commande standard ne permet d'assigner une station en tant que
+  **Stage / DockStage** : le WMS ne sait assigner qu'un **emplacement**. Une
+  assignation « station = Stage » devrait passer par un `CstAtt`.
+- Si on proposait le **vrai stage** (le poumon physique réel) à l'assignation,
+  le WMS afficherait ses **26 sous-emplacements** (soit 286 au total sur les
+  11 poumons). L'opérateur ne pourrait pas le choisir comme une unité.
+
+Solution retenue : deux notions de stage par image de quai.
+
+| Notion | Rôle |
+|--------|------|
+| **Faux stage** (`A` à `K`) | Station fictive, une par image de quai, portant un nom propre simple. C'est ce que l'opérateur **sélectionne sur le PC**, en plus du quai réel. Sa seule raison d'être : présenter l'image de quai comme un **objet unique** (une seule sélection, sans dérouler les 286 emplacements). |
+| **Vrai stage** | Le **poumon physique** de 26 emplacements où les palettes sont réellement déposées. Il conserve une **route vers le quai d'expédition** (à préserver pour le chargement camion). |
+
+L'opérateur choisit donc, pour chaque réception : (1) un quai réel (ou
+`PARKING`), (2) un faux stage (`A` à `K`) représentant l'image de quai.
+
+> ⚠️ **Effet de bord** : les tâches générées ont pour destination le **faux
+> stage** et non un emplacement réel du poumon. Le rattachement faux stage →
+> emplacement du vrai stage → quai d'expédition relève d'un mécanisme de
+> routage encore ouvert (custom sur la fin d'ordre au PS), car il touche au
+> flux d'expédition. Voir [Questions ouvertes](#questions-ouvertes) et
+> [Assignation automatique de l'image de quai](../04-outbound/assignation-image-quai.md)
+> (LIM-94, stages virtuels `X_EXP` côté expédition).

 ### Règles d'assignation

- Le quai et l'image de quai sont réservés dès la sélection
- Un quai partiellement occupé peut être réutilisé (gestion manuelle de la
-  place restante)
- ~~Blocage si flux différent (ex : expédition)~~ — supprimé
- Si aucun quai disponible → l'opérateur conserve `PARKING` et attend une
-  libération
+- Le quai et l'image de quai (faux stage) sont réservés dès la sélection
+- Un quai / une image de quai partiellement occupé peut être réutilisé
+  (gestion manuelle de la place restante)
+- ~~Blocage si flux différent (ex : expédition)~~ - supprimé
+- Si aucune image de quai disponible → l'opérateur conserve `PARKING` et attend
+  une libération
 - Modification possible a posteriori

 ### Tableau d'occupation des quais
@@ -124,24 +173,67 @@ réceptions, tournées et OS associés avec les plaques correspondantes :
 Ce tableau est aussi disponible dans le `VAssistReceptionAssignDock` (step 1
 utilise l'entité `CST_DockStationsWorkloadForView` au lieu de `Station`).

-## Étape 3 — Affichage chauffeur (LIM-63)
+## Étape 3 - Affichage chauffeur (LIM-63)

-Un écran d'affichage extérieur (WS / dialogue EasyWMS) montre aux chauffeurs
-sur le parking les quais assignés avec les plaques d'immatriculation.
+> **Statut Jira (16/07/2026)** : En cours de test client (pré-production).
+> Revue de code validée le 27/03/2026 (Nicolas Chabanis).
+
+Une **station de travail dédiée** (`CST_Workstation_Docks`) affiche, sur un écran
+extérieur au parking, les quais assignés avec les plaques d'immatriculation des
+camions. La vue ouvre automatiquement un workflow qui récupère les quais et
+appelle un dialogue d'affichage EasyBuilder. But : indiquer aux chauffeurs où
+attendre / se garer.

 ### Spécifications

- Afficher uniquement les quais avec des réceptions ou OS associés
- Prévoir l'affichage de **6 quais + le parking** sans scroll
+- Afficher uniquement les quais ayant des réceptions ou OS associés
+- Prévoir l'affichage de **6 quais principaux + le parking** (placé en haut)
+  sans avoir à scroller
 - Afficher les plaques (champ "Camion" / Document)
+- Les plaques sont récupérées via la query `CST_DockStationsWorkload_ForView`
+  (mutualisée avec LIM-62)
+
+### Implémentation technique (LIM-63)
+
+| Élément AD | Type | Rôle |
+|-----------|------|------|
+| `CST_Workstation_Docks_DisplayDocksInformation` | Dialog | Récupère la liste des quais et l'affiche ; place les 6 quais principaux + Parking en haut |
+| `CST_Workstation_Dock` | Workflow | Récupère tous les quais (code + OE/OS assignés), filtre les quais 1 à 7 (`Take(7)`), les ordonne par numéro, puis appelle le dialogue |
+| `CST_Workstation_Docks` | ViewGroup + View | Vue de la station de travail ; ouvre le workflow par défaut |
+| `RealStationWF.CST_LicencePlates` | Champ (Record) | Nouveau champ stockant les plaques (préféré à un CustomAttribute - décision de revue de code) |
+| `CST_Workstation_Docks` | Ressource i18n | FR « Quais » / EN « Docks » |
+| MenuItem `PanelMode = true` | Menu | Entrée d'accès ouvrant la vue en mode panneau |

 > **Référence technique** : dialogue EasyBuilder, cf. [documentation
 > Mecalux](https://msscc.mecalux.com/documentation/Development/master/ES/map_working_easybuilder/user_manual/dialogs/index.md)

-## Étape 4 — Déclaration image de quai via TRF (LIM-64)
+## Étape 4 - Déclaration image de quai (LIM-64 V1 → LIM-96 V2)
+
+> **Statut Jira (17/07/2026)** : LIM-64 (déclaration image de quai **V1**)
+> est **clôturé / annulé** (revue de code validée le 02/04/2026), repris par
+> [LIM-96 - Déclaration image de quai V2](https://easywmsfrance.atlassian.net/browse/LIM-96)
+> (**En cours de test client / préprod**, revue de code validée le 25/06/2026).
+> Le contenu ci-dessous reflète la **V2**. Évolutions majeures V2 vs V1 :
+> sélection / réservation de l'image de quai déplacée côté **SmartUI (web)** et
+> non plus dans le TRF ; nouvel **écran de déclaration des ordres d'entrée**
+> (rattachement de chaque emplacement occupé à un OE → `CstAtt13`) ; nouvel
+> **écran de validation du collage des étiquettes** (pose `CstAtt12 = true`,
+> qui conditionne la prise en charge par le job AGV LIM-71) ; bouton de
+> réimpression dans la confirmation d'étiquetage.

 Après déchargement physique, le cariste déclare les palettes via un menu TRF
-dédié **Réceptions > Image de quai**.
+dédié **Réceptions > Image de quai**. En V2, la sélection de l'image de quai
+elle-même se fait côté **SmartUI** (vue d'assignation), le TRF se limitant à
+confirmer l'image de quai puis à dérouler la déclaration.
+
+> [CUSTOM] **Sélection image de quai côté SmartUI (V2, Vincent Charvet 17/06)** :
+> l'image de quai est réservée depuis SmartUI (routes dock → stage virtuel
+> ajoutées au layout, dialogues `CST_DockStageReception_SelectStage` /
+> `CST_DockStageReception_ConfirmStage`, vue `VAssistReceptionAssignDock` avec
+> conditions sur les stages proposés). Pour les types **Production** et **Pile
+> de palette**, on reprend le fonctionnement antérieur : choisir directement
+> l'image de quai, sans passer par la recherche d'une réception puis la
+> confirmation de l'image associée (Arthur, 17/06).

 ### Règle de déchargement physique

@@ -149,14 +241,23 @@ Le cariste doit décharger en commençant par l'emplacement le **plus éloigné
 du quai** en suivant un ordre précis. Cela permet d'identifier les
 emplacements occupés pour les AGV.

-### Workflow 7 écrans
+### Workflow d'écrans (V2)

 Le parcours d'écrans dépend du type de réception :

- **Production** : écrans 1, 3, 4, 5, 7
- **Autres** (fournisseur, intersite, retours) : écrans 1, 2, 3, 4, 5, 6, 7
+- **Production / Pile de palette** : type → image de quai → nombre →
+  sous-emplacement → déclaration OE → validation
+- **Autres** (fournisseur, intersite, retours) : type → réception →
+  confirmation image de quai → nombre → sous-emplacement → big-bag →
+  déclaration OE → validation → **validation du collage des étiquettes**

-#### Écran 1 — Type de réception
+> Les deux écrans **Déclaration des ordres d'entrée** et **Validation du
+> collage des étiquettes** sont des ajouts V2 (voir ci-dessous). La
+> numérotation ci-dessous suit l'ordre logique de la V1 ; le WF réel
+> (`CST_Reception_DockStage_UI`) applique l'ordre V2 : image de quai
+> d'abord, puis nombre, puis sous-emplacement.
+
+#### Écran 1 - Type de réception

 Choix parmi :

@@ -166,13 +267,13 @@ Choix parmi :

 Échap : retour menu.

-#### Écran 2 — Sélection de la réception
+#### Écran 2 - Sélection de la réception

 Uniquement si type = **Autres**. L'opérateur choisit la réception concernée.

 Échap : retour écran 1.

-#### Écran 3 — Nombre de palettes
+#### Écran 3 - Nombre de palettes

 Prompt : « Nombre de palettes de la réception »

@@ -183,7 +284,7 @@ Validation :

 Message d'erreur explicatif si invalide. Échap : retour écran 2.

-#### Écran 4 — Choix image de quai (poumon)
+#### Écran 4 - Choix image de quai (poumon)

 Le workflow liste tous les poumons liés aux quais (réception + expédition)
 puis filtre :
@@ -195,12 +296,12 @@ puis filtre :
  dernier conteneur

 > **Double check** : au moment du choix effectif, les vérifications sont
-> refaites — entre l'affichage de la liste et la sélection, la réalité a pu
+> refaites - entre l'affichage de la liste et la sélection, la réalité a pu
 > changer.

 Échap : retour écran 3.

-#### Écran 5 — Sous-emplacement de départ
+#### Écran 5 - Sous-emplacement de départ

 Prompt : « Sous-emplacement de la première palette de la réception »

@@ -216,7 +317,7 @@ position 5 est occupée.

 Échap : retour écran 4.

-#### Écran 6 — Présence de big-bags
+#### Écran 6 - Présence de big-bags

 Uniquement si type = **Autres**.

@@ -226,7 +327,32 @@ Boutons OUI / NON. L'information est conservée pour la suite du flux.

 Échap : retour écran 4.

-#### Écran 7 — Validation et création
+#### Écran - Déclaration des ordres d'entrée (V2)
+
+> Ajout V2 (LIM-96). Rattache chaque palette (emplacement occupé) à son
+> **ordre d'entrée** → pose le `CstAtt13` (« Ordre d'entrée ») sur le
+> support, **dès l'image de quai** (et non plus seulement au PK).
+
+> **Ordre d'exécution** : côté implémentation, les conteneurs sont
+> **déjà créés** quand cet écran s'affiche (l'écran scanne des palettes
+> existantes pour vérifier leur appartenance à la réception). La création
+> décrite à l'écran 7 ci-dessous intervient donc **en amont** de la
+> déclaration OE dans le WF réel.
+
+Pour chaque OE de la réception, l'opérateur sélectionne les emplacements
+concernés :
+
+- La liste ne propose que les **emplacements portant une palette de la
+  réception en cours**
+- Boucle sur un dialogue avec un **compteur** de conteneurs qui
+  s'incrémente, et un bouton **« Ordre suivant »** pour passer à l'OE
+  suivant
+- À chaque scan, le WMS vérifie le conteneur sur l'emplacement (qui vient
+  d'être créé) et qu'il correspond bien à la réception en cours
+- Si le conteneur a **déjà été sélectionné**, l'opérateur en est informé ;
+  une confirmation permet de **corriger** une erreur de saisie antérieure
+
+#### Écran 7 - Validation et création

 Récapitulatif affiché :

@@ -242,7 +368,7 @@ Récapitulatif affiché :
   sous-emplacements consécutifs à partir de la position de départ
 2. **Séquence spéciale** : 18 caractères commençant par `8`
   (ex : `800000000000000001`, `800000000000000002`, etc.)
-   — cf. [LIM-14](https://easywmsfrance.atlassian.net/browse/LIM-14)
+   - cf. [LIM-14](https://easywmsfrance.atlassian.net/browse/LIM-14)
 3. **Impression étiquettes** : uniquement si type = **Autres**, une étiquette
   par palette déclarée (format LIM-65)

@@ -252,10 +378,145 @@ Récapitulatif affiché :
 > devenu indisponible entre l'écran 5 et la validation, un message d'erreur
 > est affiché. Idem si la réception sélectionnée a été supprimée entre-temps.

+> **Séquence** : le préfixe de la séquence 18 caractères a été corrigé de
+> `800000` à `800` en revue de code (cf. [LIM-14](https://easywmsfrance.atlassian.net/browse/LIM-14)).
+
+#### Écran - Validation du collage des étiquettes (V2)
+
+> Ajout V2 (LIM-96), affiché après impression pour les réceptions de type
+> **Autres**.
+
+Dialogue : « Confirmez-vous avoir collé toutes les étiquettes ? Oui
+entraînera la récupération des palettes par les AGV » avec un bouton
+**Oui** et un bouton de **réimpression** (`CST_Reception_DockStage_ConfirmLabels`).
+
+À la confirmation (Oui) :
+
+- Le `CstAtt12` (« Conteneur étiqueté ») de **toutes les palettes
+  virtuelles** de la réception est mis à `true` - **y compris** les
+  palettes qui n'ont pas besoin d'étiquette (Production / Pile)
+- Ce flag conditionne la prise en charge par le **job AGV
+  [LIM-71](https://easywmsfrance.atlassian.net/browse/LIM-71)** : les
+  palettes ne sont **déplacées que si `CstAtt12 = true`** (« on ne bouge
+  pas les palettes s'il n'y a pas d'étiquettes »)
+
+> ⚠️ **À réconcilier avec LIM-71** : la page
+> [Job réception production](../05-agv/job-reception-production.md) indique
+> que la condition `CstAtt12` avait été **retirée** du job (palettes
+> production / piles sans étiquette). LIM-96 réintroduit un contrôle
+> `CstAtt12 = true` comme **gate de prise AGV** en le posant pour *toutes*
+> les palettes à cet écran. Confirmer la logique effective côté job LIM-71
+> (voir [Questions ouvertes](../08-transverse/questions-ouvertes.md)).
+
+### Attributs de support renseignés
+
+Chaque palette virtuelle créée porte des CustomAttributes exploités en aval,
+affichés dans la vue des supports (`ContainerVList`) :
+
+| Attribut | Contenu | Libellé vue support |
+|----------|---------|---------------------|
+| `CustomAttribute1` | Réception big-bag | Reception big-bag [CST 1] |
+| `CustomAttribute4` | Réception ASN | Reception ASN [CST 4] |
+| `CustomAttribute8` | Code de la réception | Reception [CST 8] |
+| `CustomAttribute13` | Code de l'ordre d'entrée (posé à l'écran déclaration OE, V2) | Ordre d'entrée [CST 13] |
+| `CustomAttribute12` | Conteneur étiqueté (posé à `true` à l'écran collage étiquettes, V2) | - |
+
+Le `CstAtt08` (code réception) sert notamment à compter les palettes déjà
+déclarées pour une réception. Le `CstAtt13` (ordre d'entrée) est désormais
+posé **dès l'image de quai** (écran déclaration OE), et non plus seulement
+au PK. La vue `ContainerVList` affiche les CstAtt 1, 4, 8 et 13.
+
+> **Distinction big-bag (confirmée V2)** : le `CstAtt01` du support virtuel
+> (« Réception big-bag ») est le flag **au niveau réception** saisi à l'écran
+> big-bag de la déclaration image de quai. Le flag big-bag **par support**
+> (posé au poste de travail réception) est porté par le `CstAtt02` (cf.
+> glossaire). Les deux coexistent : réception vs support.
+
+### Compteur de palettes déjà déclarées
+
+L'écran de données de réception affiche le **nombre de supports déjà déclarés**
+pour la réception en cours, à côté du « Nombre de supports prévus ». Ce nombre
+est calculé en comptant les conteneurs dont le `CustomAttribute8` = code de la
+réception (query `CST_Reception_NumDeclaredContainers`).
+
+### Réimpression d'étiquette
+
+Un bouton de **réimpression** est disponible depuis la vue des supports
+(`ContainerVList`). Il n'est visible que pour un **support fictif** (code
+commençant par `800`) et **actif** (`IsActive`). Une seule impression regroupe
+toutes les étiquettes demandées. Un message d'erreur est levé si aucune
+imprimante n'est configurée.
+
+### Mode « Pile de palettes » (palettes bois)
+
+Un mode de réception **pile de palettes** a été ajouté (Justine, 16/04/2026) :
+le stock créé utilise un produit dédié de type `PALETTES BOIS`, récupéré via la
+query `CST_GetPileProduct`.
+
+### KPI - conteneurs par type de réception (LIM-102)
+
+> Statut : préprod, revue de code validée le 03/06/2026 (Maxime Halgand),
+> commit [`5a7d213d48`](https://msscode.mecalux.com/Proyectos_SW/EASYWMS_11351_LIMAGRAIN/commit/5a7d213d48bcfa4aa78cca511ce172cb226e9883).
+
+Pour tracer le **nombre de conteneurs créés par type de réception**, chaque
+conteneur créé par le process de réception custom (LIM-96) génère une
+transaction **`CON.CREATE.RECEP`** (catalogue :
+[Paramètres projet](../07-admin/parametres-projet.md#transactions-customs)).
+
+| Champ | Contenu |
+|-------|---------|
+| `TransactionTypeCode` | `CON.CREATE.RECEP` |
+| `LocationCode` | Emplacement du conteneur |
+| `ContainerCode` | Code conteneur |
+| `Document1` | **Type de réception** (dimension du KPI) |
+| `IdOrig` | Id du conteneur |
+
+Le `Document1` prend l'une des valeurs suivantes :
+
+- `PALETTE BOIS` (mode pile de palettes) ;
+- `PRODUCTION` ;
+- pour une réception de type **AUTRES** : le `InboundClassCode` de la réception.
+
+Le WF `CST_Reception_DockStage_UI` récupère le `InboundClassCode` de la
+réception, et `CST_Reception_DockStage_CreateContainers_PR` crée la transaction.
+
+### Implémentation technique (LIM-64 V1 → LIM-96 V2)
+
+| Élément AD | Type | Rôle |
+|-----------|------|------|
+| `CST_Reception_DockStage_UI` | Workflow | Process principal : ordre V2 (image de quai → nombre → sous-emplacement), déclaration OE, confirmation collage ; gère le mode pile de palettes ; récupère le `InboundClassCode` de la réception pour le KPI (LIM-102) |
+| `CST_Reception_DockStage_CreateContainers_PR` | Workflow | Création des conteneurs (code via séquence) ; crée la transaction `CON.CREATE.RECEP` avec `Document1` = type de réception (KPI, LIM-102) |
+| `CST_Reception_DockStage_PrintLabels` | Workflow | Impression des étiquettes des conteneurs créés (V2) |
+| `CST_DockStageReception_SelectStage` | Dialog | Sélection de l'image de quai (renommé depuis `CST_DockStageReception_GetStage`, V2) |
+| `CST_DockStageReception_ConfirmStage` | Dialog | Confirmation de l'image de quai sélectionnée (V2) |
+| `CST_DockStageReception_BigBag` | Dialog | Sélection présence big-bag |
+| `CST_DockStageReception_Validation` | Dialog | Récapitulatif et validation |
+| `CST_Reception_DockStage_ConfirmLabels` | Dialog | Confirmation du collage des étiquettes + bouton réimpression (V2) |
+| `CST_DockStageStations_WithoutAssignation` | Query | Poumons disponibles (renommé depuis `CST_DockStageStations_WithoutOutbound`, supprimée ; ajout de conditions sur réceptions / OS / routes assignés). Ne renvoie que les **stages physiques**, pas les stages virtuels d'expédition |
+| `CST_Receptions_PendingAndReceiving_WithDockStageAssigned` | Query | Clone de `Receptions_PendingAndReceiving` avec condition sur le quai et le stage associé (V2) |
+| `CST_Reception_NumDeclaredContainers` | Query | Nombre de conteneurs d'une réception (via `CstAtt08`) |
+| `CST_GetPileProduct` | Query | Produit `PALETTES BOIS` (mode pile de palettes) |
+| `StageWF.CST_GreatestOccupiedPosition` | Champ (Record) | Position X la plus haute occupée sur l'image de quai |
+| `CST_RPT_DOCKSTAGERECEPTION_VIRTUAL_CONTAINER_LABEL` | Report | Étiquette support virtuel (impression multiple simultanée) |
+| `ContainerVList` | View | Bouton réimpression + colonnes CstAtt 1, 4, 8, 13 |
+| `VAssistReceptionAssignDock` / `VAssistOutboundOrderAssignDock` / `VAssistRouteAssignDock` | Vue | Conditions sur les stages proposés lors de l'assignation SmartUI (V2) |
+| Routes dock → stage virtuel | Layout | Ajoutées pour l'assignation de l'image de quai côté SmartUI (V2) |
+
+Ressources i18n V2 : `CST_Reception_DockStage_ConfirmPrinting`,
+`CST_Reception_DockStage_NoInboundOrder`, `CST_View_InboundOrder`
+(« Ordre d'entrée [CST 13] »), `CST_InboundOrder_Asociated_1`,
+`CST_InboundOrderSelection_End`, `CST_NextOrder`.
+
+Commit V2 : [`1b2570b164`](https://msscode.mecalux.com/Proyectos_SW/EASYWMS_11351_LIMAGRAIN/commit/1b2570b16429102b93d1f1d860f6fa807ee5ede8)
+(migration sélection image de quai vers SmartUI).
+
 ## Étiquette support image de quai (LIM-65)

-Format **A5 paysage**. Imprimée pour chaque palette de type "Autres"
-(pas pour la production).
+> **Statut Jira (16/07/2026)** : En cours de test client (pré-production).
+> Revue de code validée le 25/06/2026.
+
+Format **A5 paysage**. Imprimée pour chaque palette d'une réception qui n'est
+**pas de type PRODUCTION** (impression déclenchée par le workflow de LIM-96).

 | Champ | Contenu |
 |-------|---------|
@@ -263,7 +524,29 @@ Format **A5 paysage**. Imprimée pour chaque palette de type "Autres"
 | RECEPTION | Code de la réception |
 | DATE | Date d'impression |
 | EMPL. | Sous-emplacement du poumon |
-| QR Code | Code du support |
+| OE | Code de l'ordre d'entrée (ajouté 06/2026 - en texte sous la réception) |
+| QR Code | Code support + code OE au format GS1 |
+
+### QR Code GS1
+
+Le QR Code encode deux données au format GS1 :
+
+- AI `00` → code du support (SSCC)
+- AI `91` → code de l'ordre d'entrée
+
+Exemple : `#00800000000000000001#91804565206`
+
+Ce label GS1 est réutilisé dans le **flux retour fournisseur** : le scan permet
+de récupérer à la fois le support et l'OE.
+
+### Implémentation technique (LIM-65)
+
+| Élément AD | Type | Rôle |
+|-----------|------|------|
+| `CST_RPT_DOCKSTAGERECEPTION_VIRTUAL_CONTAINER_LABEL` | Report | Étiquette support virtuel - ajout du code OE + QR Code (support + OE) |
+| `ParsedContainerLabelWF` | Record | Ajout du champ code d'ordre d'entrée |
+| `ParseContainerLabel` | Workflow | Parse de l'identifiant GS1 `#91` → code OE |
+| `CST_Reception_Return_ATH214_CheckData_UI` | Workflow | Parse container sur le dialog du code OE (scan QR) - flux retour |

 ## Implémentation technique (AD customs)

@@ -283,9 +566,16 @@ Format **A5 paysage**. Imprimée pour chaque palette de type "Autres"

 | Vue | Modification |
 |-----|-------------|
-| `ReceptionVList` | ViewDetailPanel `CST_Docks_Workload` (Column Span = 2) — occupation quais |
-| `VAssistCreateReceptionOE` | Exception steps 2 et 3 — blocage classes OE différentes |
-| `VAssistReceptionAssignDock` | Step 1 : entité `CST_DockStationsWorkloadForView` remplace `Station` |
+| `ReceptionVList` | ViewDetailPanel `CST_Docks_Workload` (Column Span = 2) - occupation quais |
+| `VAssistCreateReceptionOE` | Exception steps 2 et 3 - blocage classes OE différentes |
+| `VAssistCreateReceptionOEFromReceptions` | Mêmes conditions sur les classes d'OE - blocage à la création de réception depuis la vue des ordres d'entrées (LIM-97) |
+| `VAssistReceptionAssignDock` | Step 1 : entité `CST_DockStationsWorkloadForView` remplace `Station` ; assignation du quai réel + du faux stage (image de quai en unité) |
+
+### Élément AD - faux stages (LIM-97)
+
+| Élément AD | Type | Rôle |
+|-----------|------|------|
+| Faux stages `A` à `K` | Station fictive | Une par image de quai ; sélectionnable comme unité à l'assignation SmartUI (voir [Mécanisme faux stage / vrai stage](#mécanisme-faux-stage--vrai-stage-v2)). Nouveau, à formaliser dans l'AD |

 ### Ressources i18n

@@ -293,24 +583,30 @@ Format **A5 paysage**. Imprimée pour chaque palette de type "Autres"
 |------|----|----|
 | `CST_Reception_MultiClassError` | Impossible de créer une réception avec des ordres d'entrée ayant des classes de préavis de réception différentes | Can't create reception with inbound orders with different inbound order class |
 | `CST_Prop_Reception_Document` | Camion | Truck |
-| `CST_Prop_Station_Workload` | Assignations / Camions | Assignations / Trucks |
+| `CST_ViewField_VAssistantCreateReceptionOE_Truck` | #KEY#[CST_Prop_Reception_Document, PARAMS[]] | #KEY#[CST_Prop_Reception_Document, PARAMS[]] |
+| `CST_Prop_Station_Workload` | Réceptions / Camions | Receptions / Trucks |
 | `CST_Reception_DockWorkload_Panel_Title` | Occupation des quais | Docks workload |

 > **Note** : toutes les ressources custom sont préfixées `CST_` (convention
 > Mecalux France validée lors de la revue de code).

+> **Divergence de libellé (LIM-97 §8.4)** : `CST_Prop_Station_Workload` a été
+> commentée « Assignations / Camions » (Vincent, 05/03) puis « Réceptions /
+> Camions » en revue de code (Nicolas, 06/03) - valeur retenue par défaut,
+> alignée sur le tableau d'occupation ci-dessus. À confirmer.
+
 ### Revue de code

- **05/03/2026** — Vincent Charvet : implémentation initiale
+- **05/03/2026** - Vincent Charvet : implémentation initiale
  ([`1d2acc3e6e`](https://msscode.mecalux.com/Proyectos_SW/EASYWMS_11351_LIMAGRAIN/commit/1d2acc3e6efef09df3e2a760574e35afd30ca166))
- **06/03/2026** — Nicolas Chabanis : revue non valide (préfixes ressources,
+- **06/03/2026** - Nicolas Chabanis : revue non valide (préfixes ressources,
  commentaire `//Custom end` manquant, Column Span, titre colonne)
- **09/03/2026** — Nicolas Chabanis : **revue validée**
+- **09/03/2026** - Nicolas Chabanis : **revue validée**

 ## Points d'attention

 - La plaque du camion n'est **pas obligatoire** à la création de la réception
-  — elle peut être renseignée après coup (confirmé 09/03/2026)
+  - elle peut être renseignée après coup (confirmé 09/03/2026)
 - Le déchargement doit respecter l'ordre : emplacement le plus éloigné
  d'abord, sinon les AGV ne peuvent pas identifier correctement les positions
  occupées
@@ -320,29 +616,60 @@ Format **A5 paysage**. Imprimée pour chaque palette de type "Autres"
 - Le double-check de disponibilité du poumon au moment du choix est
  **critique** pour éviter les collisions entre opérateurs simultanés
 - Les séquences de supports virtuels commencent par `8` et font 18 caractères
-  — ne pas confondre avec les séquences SSCC standard
+  - ne pas confondre avec les séquences SSCC standard
+- **V2 (LIM-97)** : la tâche générée vise le **faux stage**, pas un emplacement
+  réel du poumon ; un custom (fin d'ordre au PS) doit rediriger la destination
+  vers le bon emplacement du vrai stage, et la **route vers le quai
+  d'expédition** doit être préservée pour le chargement camion
+- **V2 (LIM-97)** : une **27e palette** ne tient pas sur l'image de quai
+  (capacité 26) ni dans le camion ; sans traitement, le process plante
+- **V2 (LIM-97)** : la **dépose AGV** sur des positions serrées de l'image de
+  quai peut se bloquer si l'ordre de dépose n'est pas respecté (un AGV en
+  position 26 avant un AGV en position 23)

 ## Questions ouvertes

- [ ] Gestion TRF si AGV pas prêts au démarrage — lié aussi à la déclaration
+- ❓ Gestion TRF si AGV pas prêts au démarrage - lié aussi à la déclaration
  image de quai (@Théo)
- [ ] Position étiquette image de quai (devant/côté palette) — à valider
+- ❓ Position étiquette image de quai (devant/côté palette) - à valider
  avec le client (@Justine)
- [ ] Faut-il rendre la saisie du camion (plaque) obligatoire pour garantir
+- ❓ Faut-il rendre la saisie du camion (plaque) obligatoire pour garantir
  la cohérence de l'affichage chauffeur ? (@Justine)
+- Routage de la tâche faux stage → emplacement du vrai stage → quai
+  d'expédition (LIM-97 §8.1) : proposition = custom sur la fin d'ordre au PS
+  qui redirige la destination, logique différenciée par `locationType` (buffer
+  vs DockStage). Risque de rollback en boucle (mouvement généré à la fin
+  d'ordre au PS) ; cadencement AGV à reconfirmer avec Still (@Vincent / @Still)
+- Débordement au-delà de 26 palettes sur l'image de quai (27e palette,
+  LIM-97 §8.2) : à arbitrer (ne pas générer la tâche tant qu'aucune place ne
+  se libère, ou maintenir la palette en zone tampon ASRS) (@Justine)
+- Ordonnancement de la dépose AGV sur l'image de quai (positions serrées,
+  LIM-97 §8.3) : dépose sans position précise (l'AGV choisit l'emplacement
+  libre le plus proche puis le remonte au WMS) ou respect strict de l'ordre
+  des STOP (LIM-88) ; à valider en réunion technique dédiée (@Théo / @Still)

 ## Historique des modifications

 | Date | Auteur | Modification |
 |------|--------|-------------|
 | 2026-05-06 | Arthur | Création initiale depuis LIM-62, LIM-63, LIM-64, LIM-65 |
+| 2026-07-16 | Arthur | Mise à jour statut LIM-62 : V1 clôturée/annulée, validée fonctionnellement (Justine 27/05), suite en LIM-97 (V2) |
+| 2026-07-16 | Arthur | LIM-63 : ajout implémentation technique (station `CST_Workstation_Docks`, workflow, dialog, champ `CST_LicencePlates`) + statut pré-production |
+| 2026-07-16 | Arthur | LIM-64 : statut V1 annulée → LIM-96 (V2) ; ajout attributs support (CstAtt01/04/08), compteur palettes déclarées, réimpression, mode pile de palettes, éléments AD |
+| 2026-07-16 | Arthur | LIM-65 : ajout champ OE sur l'étiquette + QR Code GS1 (AI 00 support / AI 91 OE) réutilisé flux retour fournisseur, éléments AD parsing ; statut pré-production |
+| 2026-07-17 | Arthur | Intégration LIM-96 V2 (préprod, revue de code validée 25/06) : étape 4 réécrite (statut V1→V2), sélection image de quai côté SmartUI (dialogues `CST_DockStageReception_SelectStage`/`ConfirmStage`, `VAssistReceptionAssignDock`, routes dock→stage virtuel), écran **Déclaration des OE** (CstAtt13 posé dès l'image de quai), écran **Validation collage étiquettes** (CstAtt12=true, gate job LIM-71 + caveat réconciliation), workflow d'écrans V2, attributs support (+CstAtt12/CstAtt13), table AD V2 (query renommée `CST_DockStageStations_WithoutAssignation`, clone `CST_Receptions_PendingAndReceiving_WithDockStageAssigned`, WF `CST_Reception_DockStage_PrintLabels`, ressources, commit `1b2570b164`), distinction big-bag CstAtt01/CstAtt02 confirmée ; front matter sources/last_updated |
+| 2026-07-20 | Arthur | Intégration LIM-97 (Gestion camions V2, préprod, validé Vincent 02/07) : étape 2 réécrite (assignation quai + image de quai, **mécanisme faux stage A-K / vrai stage**, effet de bord routage) ; ajout vue `VAssistCreateReceptionOEFromReceptions` + ressource `CST_ViewField_VAssistantCreateReceptionOE_Truck` + Élément AD faux stages A-K ; libellé `CST_Prop_Station_Workload` corrigé (Réceptions / Camions + caveat §8.4) ; 3 points d'attention V2 (débordement 27e palette, ordonnancement dépose AGV, routage à préserver) ; 3 questions ouvertes (routage §8.1, débordement §8.2, ordonnancement §8.3) ; front matter sources/last_updated |
+| 2026-07-20 | Arthur | Intégration LIM-102 (KPI conteneurs par type de réception, préprod, revue validée 03/06) : nouvelle sous-section KPI (transaction `CON.CREATE.RECEP`, `Document1` = type de réception : PALETTE BOIS / PRODUCTION / InboundClassCode) ; enrichissement des WF `CST_Reception_DockStage_UI` (récupération InboundClassCode) et `CST_Reception_DockStage_CreateContainers_PR` (création transaction) ; jira_refs +LIM-102 |

 ## Références

 | Source | Type | Date |
 |--------|------|------|
-| [LIM-62](https://easywmsfrance.atlassian.net/browse/LIM-62) | Ticket Jira | 18/02/2026 |
-| [LIM-63](https://easywmsfrance.atlassian.net/browse/LIM-63) | Ticket Jira | 2026 |
-| [LIM-64](https://easywmsfrance.atlassian.net/browse/LIM-64) | Ticket Jira | 2026 |
-| [LIM-65](https://easywmsfrance.atlassian.net/browse/LIM-65) | Ticket Jira | 2026 |
+| [LIM-62](https://easywmsfrance.atlassian.net/browse/LIM-62) | Ticket Jira (V1 - Annulé, suite LIM-97) | 18/02/2026 |
+| [LIM-97](https://easywmsfrance.atlassian.net/browse/LIM-97) | Ticket Jira (Gestion camions V2 - préprod, validé Vincent 02/07/2026, faux stages A-K, commit `1d2acc3e6e`) | 2026 |
+| [LIM-63](https://easywmsfrance.atlassian.net/browse/LIM-63) | Ticket Jira (affichage chauffeurs - pré-production) | 2026 |
+| [LIM-64](https://easywmsfrance.atlassian.net/browse/LIM-64) | Ticket Jira (V1 - Annulé, suite LIM-96) | 18/02/2026 |
+| [LIM-96](https://easywmsfrance.atlassian.net/browse/LIM-96) | Ticket Jira (déclaration image de quai V2 - préprod, revue de code validée 25/06, commit `1b2570b164`) | 2026-06 → 07 |
+| [LIM-65](https://easywmsfrance.atlassian.net/browse/LIM-65) | Ticket Jira (étiquette support - pré-production) | 2026 |
+| [LIM-102](https://easywmsfrance.atlassian.net/browse/LIM-102) | Ticket Jira (KPI conteneurs par type de réception - préprod, revue validée 03/06, commit `5a7d213d48`) | 2026 |
 | [LIM-14](https://easywmsfrance.atlassian.net/browse/LIM-14) | Ticket Jira (séquences supports) | 2026 |
@@ -1,18 +1,18 @@
 ---
-title: "Réception fournisseur — Production et extérieures/intersites"
+title: "Réception fournisseur - Production et extérieures/intersites"
 tags: [inbound, réception, production, ASN, ROR, PIE, clôture, REF, ROF]
 status: draft
 standard_ref: concepts/reception.md
-jira_refs: [LIM-67, LIM-73]
+jira_refs: [LIM-67, LIM-68, LIM-71, LIM-73, LIM-93]
 confluence_refs: []
-sources: [FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5.docx, "Réception - LIMAGRAIN - DEV - Confluence.md", LIM-67_Postes_Travail_Reception.md, "LIM-73 - LOT1.3 [RECEPTION] Fermetures, REF et gestion retours.md"]
-last_updated: 2026-05-12
+sources: [FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5.docx, "Réception - LIMAGRAIN - DEV - Confluence.md", LIM-67_Postes_Travail_Reception.md, "Jira LIM-67 (relecture commentaires 2026-07-16)", "LIM-73 - LOT1.3 [RECEPTION] Fermetures, REF et gestion retours.md", "Jira LIM-73 (revue de code validée 2026-06-02, relecture 2026-07-17)"]
+last_updated: 2026-07-17
 author: Arthur
 ---

-# Réception fournisseur — Production et extérieures/intersites
+# Réception fournisseur - Production et extérieures/intersites

-> **Résumé** : deux flux de réception distincts chez Limagrain — production
+> **Résumé** : deux flux de réception distincts chez Limagrain - production
 > (directe ASRS via ASN) et extérieures/intersites (passage poste de travail
 > via ROR). Le déchargement camion est une étape commune.

@@ -29,7 +29,7 @@ Limagrain gère 3 types de réception. Cette page couvre les deux premiers :
 Le troisième type (retours client) est couvert dans
 [Réception retour](reception-retour.md).

-## Étape commune — Arrivée et déclaration du camion
+## Étape commune - Arrivée et déclaration du camion

 > **Page dédiée** : le flux complet d'arrivée camion, d'assignation de quai,
 > d'affichage chauffeur et de déclaration image de quai via TRF est documenté
@@ -42,7 +42,7 @@ Le troisième type (retours client) est couvert dans
   « Ordre d'entrée > Réceptions » (SmartUI)
 2. Saisie de la **plaque d'immatriculation** et de la **destination** :
   « PARKING » par défaut (quai fictif d'attente) ou quai réel si disponible
-3. Sélection des OE (ordres d'entrée) concernés — chaque OE est flagué
+3. Sélection des OE (ordres d'entrée) concernés - chaque OE est flagué
   via un CstAtt
 4. Agent consulte la disponibilité des quais via un graphique dans la vue
   des réceptions et assigne un quai réel
@@ -50,7 +50,7 @@ Le troisième type (retours client) est couvert dans

 **Contraintes d'assignation image de quai :**

- Quai et image de quai **réservés** dès la sélection — réutilisation possible
+- Quai et image de quai **réservés** dès la sélection - réutilisation possible
  si place restante (gestion manuelle)
 - Blocage si flux différent (ex : expédition en cours sur ce quai)
 - Blocage si l'image de quai a des supports associés à un OS (expédition)
@@ -78,7 +78,7 @@ Menu TRF custom : Réception > Images de quai > Déclaration
 3. Saisie du nombre de palettes + emplacement de départ
 4. Association à la réception (auto pour Production via CstAtt « ASN »,
   sélection manuelle de l'OE pour les autres)
-5. Prompt big-bag (Oui/Non) — sauté pour Production
+5. Prompt big-bag (Oui/Non) - sauté pour Production
 6. Écran de validation
 7. Création des supports dans le WMS

@@ -105,7 +105,7 @@ Menu TRF custom : Réception > Images de quai > Déclaration

 ---

-## Flux 1 — Réception depuis la production
+## Flux 1 - Réception depuis la production

 ### Flux physique

@@ -164,7 +164,7 @@ Batch possible : jusqu'à **500 conteneurs par message ASN**.
 - Le tracking s'effectue avec le support virtuel sur le premier convoyeur

 **Destination** : entrée production (convoyeur vers ASRS). L'AGV dépose
-sur un **buffer d'entrée** (type POUMON MINILOAD AD) — jamais directement
+sur un **buffer d'entrée** (type POUMON MINILOAD AD) - jamais directement
 sur le PIE.

 **Suppression du support virtuel :**
@@ -178,7 +178,7 @@ sur le PIE.

 En cas de blocage long terme sur l'entrée production :

- **Solution standard** : système de routes avec distances — route
+- **Solution standard** : système de routes avec distances - route
  principale distance 1, routes secondaires distance 2
 - On ferme le PIE de production → le WMS redirige automatiquement vers
  les autres entrées disponibles
@@ -205,11 +205,11 @@ détail des contrôles PIE et la répartition du poids.
 **PIE OK :**

 - [CUSTOM] Aucun message ASO généré
- [CUSTOM] Vérification poids — tolérance par type article, verrou
+- [CUSTOM] Vérification poids - tolérance par type article, verrou
  « Réception » sur le **support** si écart > seuil
 - Mise à jour CstAtt01 de la ligne de stock (poids unitaire calculé)
 - [CUSTOM] Si type article ZSIZ → message ajustement stock vers SAP
-  via WSC (poids réel HU) — voir
+  via WSC (poids réel HU) - voir
  [Contrôle qualité réception](controle-qualite-reception.md) pour
  la gestion du timing avec le REF
 - Stratégie de rangement appliquée
@@ -217,7 +217,7 @@ détail des contrôles PIE et la répartition du poids.

 **PIE NOK :**

- Rejet standard — plus besoin d'étiquette spécifique
+- Rejet standard - plus besoin d'étiquette spécifique
 - Palette dirigée automatiquement vers un **poumon au sol** (zone de
  rejet)
 - **Notification SmartUI** envoyée aux opérateurs
@@ -230,7 +230,7 @@ détail des contrôles PIE et la répartition du poids.

 ---

-## Flux 2 — Réceptions extérieures / transferts intersites
+## Flux 2 - Réceptions extérieures / transferts intersites

 ### Flux physique (extérieur)

@@ -278,31 +278,51 @@ Message **ROR** de SAP → EasyWMS :
 - Tolérance quantité : **0 %** pour intersites (palettes déjà
  identifiées), paramétrable **par ligne ROR** pour extérieures
  (uniquement en dépassement %)
- `IsSingleReceipt = true` — le WMS ne gère pas de reliquats
+- `IsSingleReceipt = true` - le WMS ne gère pas de reliquats
  automatiques. Si réception incomplète, SAP crée une nouvelle
  livraison
 - `InboundType = 0` (Standard) pour les deux sous-types

 | Élément SAP | Correspondance EasyWMS | Remarque |
 |-------------|------------------------|----------|
-| Commande d'achat | — | Peut être cadencée en plusieurs livraisons |
+| Commande d'achat | - | Peut être cadencée en plusieurs livraisons |
 | Livraison | 1 ROR | Un ROR = une livraison |
 | Camion | N livraisons | Un camion peut contenir plusieurs livraisons |

 > Les transferts intersites : le site émetteur est considéré comme un
 > fournisseur dans EasyWMS.

-### 2) [CUSTOM] Gestion des SSCC
+### 2) [CUSTOM] Gestion des SSCC et codes conteneurs du ROR
+
+Deux cas selon que le ROR fournit ou non des codes conteneurs
+(`LineList>ContainerCode`) :
+
+**a) Le ROR fournit des codes conteneurs attendus** (livraison Limagrain
+avec supports identifiés)
+
+- Avant la création du support, un écran analyse si l'ordre d'entrée
+  associé à la palette scannée contient des **numéros de supports
+  attendus** dans ses lignes
+- Si oui : l'opérateur doit **scanner le code support "LIMAGRAIN"**
+  (un bouton **Liste** affiche les codes attendus au cas où l'étiquette
+  serait illisible)
+- Au scan, vérification que le code fait partie de la liste des codes
+  attendus, sinon message d'erreur
+- Le code conteneur retenu est celui du ROR ; le code de l'ordre
+  d'entrée du conteneur est conservé dans le **CstAtt13** du support
+- Réf. commentaires LIM-67 des 19-23/06/2026 (livré préprod)
+
+**b) Le ROR ne fournit aucun code conteneur** (fournisseur/intersite
+classique)

- Les numéros SSCC **ne sont pas envoyés** dans le ROR
-  (`LineList>ContainerCode`)
 - Le SSCC est récupéré au moment du **scan RFID** en réception
 - Si SSCC présent sur la palette → conservation lors de la réédition
  RFID
- Si SSCC absent → création d'un nouveau SSCC et ré-étiquetage
+- Si SSCC absent → **création d'un nouveau SSCC** et ré-étiquetage

-> Raison : éviter la complexification du process si l'étiquette est
-> endommagée.
+> Règle : un SSCC n'est généré que si le ROR ne fournit **aucun** code
+> support dans ses lignes. Raison : éviter la complexification du process
+> si l'étiquette est endommagée.

 ### 3) [CUSTOM] Déplacement vers poste de travail

@@ -325,36 +345,66 @@ que possible. Si multi-référence à l'arrivée :
  (non géré par le WMS)
 - Tri de marchandise pour constituer des conteneurs mono-ref

-> Le process de constitution mono-référence est **standard** — pas de
+> Le process de constitution mono-référence est **standard** - pas de
 > développement spécifique.

+#### [CUSTOM] Tables de préparation et poste de picking adjacent
+
+Le développement gère **6 tables de préparation** pour les réceptions
+(commentaire LIM-67 du 30/04/2026). La station de réception est couplée
+à un **poste de picking adjacent** (voir paramètre `PK_ADJACENT`) :
+
+- avant l'ouverture d'un poste de picking, vérification que le poste
+  **adjacent** n'utilise pas déjà les tables de préparation (sinon
+  blocage avec message « Impossible d'ouvrir le poste de travail.
+  Utilisation des tables de préparation par le poste adjacent ») ;
+- les palettes **liées** au poste adjacent restent utilisables sans
+  forcer leur déplacement vers le poste en cours d'utilisation ;
+- le conteneur créé porte le code du poste de picking lié dans son
+  `CstAtt06`.
+
 ### 5) [CUSTOM] Traitement au poste de travail

-Ref. [LIM-67](https://easywmsfrance.atlassian.net/browse/LIM-67) — en
-attente CDP.
+Ref. [LIM-67](https://easywmsfrance.atlassian.net/browse/LIM-67) - revue
+de code validée le 29/06/2026, **livré en préprod** le 09/07/2026
+(en cours de test client).

 Les opérateurs utilisent le mode **Tâches automatiques** sur PC. Le
 code de réception est récupéré automatiquement via le `CstAtt08` du
 conteneur présent sur le poste.

 **Affichage fournisseur** : sur **tous les écrans** du process,
-afficher `"Fournisseur: CODE - NOM"`.
+afficher `"Fournisseur: CODE - NOM"`. Le nom est porté par le champ
+`CST_SupplierName` du record `ReceptionWF` (pas par le `SupplierCode`,
+pour éviter les bugs d'usage ultérieur).

-#### a) Confirmation de création support (Big Bag)
+#### a) Scan du conteneur virtuel et création du support réel (Big Bag)

-Si le conteneur scanné est un **conteneur virtuel** de réception, un
-écran de confirmation crée le nouveau support « réel ». Sur cet écran :
+Le process démarre par le **scan du conteneur virtuel** posé sur le
+poste (créé à la déclaration image de quai). Ce scan :
+
+- récupère la **réception associée** via le `CstAtt08` du conteneur
+  virtuel ;
+- **génère automatiquement** un nouveau code de conteneur (généré dans
+  EasyWMS, plus saisi par l'opérateur) ;
+- après le paramétrage Big Bag et filmage, **supprime le conteneur
+  virtuel** et crée le nouveau conteneur réel **sur le même
+  emplacement** ;
+- reporte le `CstAtt08` sur le nouveau conteneur pour **conserver la
+  réception** si l'opérateur quitte avant la fin.
+
+Sur l'écran de confirmation de création du support réel :

 - Ligne `"BIG BAG : NON"` (état initial)
 - Bouton **"BIG BAG ON"** → toggle vers `"BIG BAG : OUI"` / **"BIG BAG
  OFF"**
 - Valeur `true`/`false` stockée dans **CstAtt02** du support
- Impression automatique d'une **étiquette RFID** dès confirmation —
+- Impression automatique d'une **étiquette RFID** dès confirmation -
  voir [Étiquette RFID](etiquette-rfid.md) (LIM-68)

 #### b) Menu principal du poste

-Écran central avec 5 actions — les informations du support actuel sont
+Écran central avec 6 actions - les informations du support actuel sont
 toujours affichées à droite. Après chaque action, retour à ce menu.

 | Action | Description |
@@ -362,6 +412,7 @@ toujours affichées à droite. Après chaque action, retour à ce menu.
 | **Ajouter stock** | Sélection article, lot, quantité (écrans standard). Afficher quantité attendue + UdM sans pré-remplir le prompt. Statut de stock affiché mais **non modifiable** (boutons masqués). Écrans date fin de statut et commentaire **skippés**. Pour l'anoxie : set **CstAtt03** du support à `true` |
 | **Nouveau support** | Scan emplacement, confirmation de création (retour à l'étape a). Le nouveau conteneur devient le support actif |
 | **Changer de support** | Scan du code support à sélectionner comme support actif |
+| **Retirer support** | Suppression d'un conteneur du poste. Si le support contient du stock déclaré, un message d'avertissement demande confirmation avant suppression (ajouté au commentaire LIM-67 du 30/04/2026) |
 | **Imprimer étiquette** | Réimpression de l'étiquette RFID (voir [Étiquette RFID](etiquette-rfid.md)) |
 | **Terminer** | Vérification fermeture + filmage + évacuation (voir ci-dessous) |

@@ -393,8 +444,20 @@ transport AGV du poste de travail vers la table d'entrée.
 | CstAtt02 | Flag Big Bag (`true`/`false`) | Écran confirmation support |
 | CstAtt03 | Flag anoxie (`true`) | Action « Ajouter stock » |
 | CstAtt05 | Programme de filmage (`0`, `A`, `B`…) | Action « Terminer » |
+| CstAtt06 | Code du poste de picking lié au conteneur (LIM-67, 30/04/2026) - conflit levé : LIM-71 a abandonné son marquage CstAtt06 ; usage confirmé par LIM-70 et le job de régénération LIM-71 | Création du conteneur au poste |
 | CstAtt08 | Code de réception | Déclaration image de quai |
 | CstAtt10 | Flag support traité (`true`) | Fin de traitement |
+| CstAtt13 | Code de l'ordre d'entrée du conteneur (quand le ROR fournit un code support attendu) | Sélection du code conteneur du ROR |
+
+#### Validation des attributs logistiques (optimisation → LIM-93)
+
+Demande d'optimisation portée par
+[LIM-93](https://easywmsfrance.atlassian.net/browse/LIM-93) : les
+attributs logistiques sont **validés automatiquement** s'ils sont bien
+renseignés dans le ROR ; s'il en manque un, il est demandé à
+l'opérateur. Si le ROR possède plusieurs lignes avec le **même lot SAP**
+mais des attributs logistiques différents, ils sont aussi demandés
+(EasyWMS ne peut pas deviner la ligne concernée à la réception).

 ### 6) Déplacement AGV → table d'entrée et filmage

@@ -412,7 +475,7 @@ mêmes contrôles PIE). Voir

 **Différence en cas de rejet PIE** : la palette est dirigée vers un
 **poumon au sol** avec **notification SmartUI** (ancienne approche de
-renvoi au poste de travail d'origine abandonnée — risque de blocage
+renvoi au poste de travail d'origine abandonnée - risque de blocage
 AGV/table/poste). CstAtt du support flagué avec le poste de travail
 d'origine.

@@ -420,7 +483,7 @@ d'origine.

 ## Clôture des réceptions (extérieures/intersites)

-Ref. [LIM-73](https://easywmsfrance.atlassian.net/browse/LIM-73) — LOT
+Ref. [LIM-73](https://easywmsfrance.atlassian.net/browse/LIM-73) - LOT
 1.3.

 La clôture concerne uniquement les flux passant par un poste de travail
@@ -434,11 +497,13 @@ livraison (donc nouvel OE).

 ### Paramétrage

- `IsSingleReceipt = true` — une seule réception par OE, pas de
+- `IsSingleReceipt = true` - une seule réception par OE, pas de
  reliquats WMS
- `AutoCloseReception = true` — le WMS clôture automatiquement la
-  réception quand les conditions custom sont remplies (§ Déclenchement)
- `AutoCloseInboundOrder = true` — à la clôture de la réception, chaque
+- `AutoCloseReception = true` - le WMS clôture automatiquement la
+  réception quand les conditions custom sont remplies (§ Déclenchement).
+  Valeur confirmée `true` ; le tableau [LIM-14](../07-admin/parametres-projet.md)
+  affiche encore `false` (à corriger côté ticket)
+- `AutoCloseInboundOrder = true` - à la clôture de la réception, chaque
  OE complété à 100 % ou dans la tolérance est auto-clôturé (ROF
  envoyé) et auto-archivé (absent de la vue). Les OE en écart hors
  tolérance restent ouverts
@@ -452,8 +517,8 @@ livraison (donc nouvel OE).

 ### Déclenchement de l'auto-close (LIM-73 §1.1)

-L'auto-close de la réception se déclenche — et le bouton « Fermer
-réception » n'est visible — que si les deux conditions suivantes sont
+L'auto-close de la réception se déclenche - et le bouton « Fermer
+réception » n'est visible - que si les deux conditions suivantes sont
 **simultanément** remplies :

 1. **Aucune palette fictive** ayant `CstAtt08 = <code de la réception>`
@@ -473,12 +538,12 @@ puis fermer l'ordre d'entrée ».

 Le workflow standard de clôture est modifié pour deux comportements :

-**Partie A — Condition retours** : si la réception est de type retour
+**Partie A - Condition retours** : si la réception est de type retour
 client, la clôture et le REF sont différés jusqu'au rangement ASRS
-complet. Voir [Réception retour — Clôture](reception-retour.md) pour le
+complet. Voir [Réception retour - Clôture](reception-retour.md) pour le
 détail (CstAtt11, CstAtt01 réception, statut « Clôture en cours »).

-**Partie B — Pose CstAtt01 OE hors tolérance** : à la clôture effective,
+**Partie B - Pose CstAtt01 OE hors tolérance** : à la clôture effective,
 pour chaque **ligne article hors tolérance** (en plus ou en moins) :

 1. Rechercher le **premier OE** (FirstOrDefault) parmi les OE associés
@@ -486,9 +551,16 @@ pour chaque **ligne article hors tolérance** (en plus ou en moins) :
 2. Poser `CstAtt01 = true` sur cet OE

 > En pratique un combo code article/lot n'est jamais partagé entre
-> plusieurs OE d'une même réception — le FirstOrDefault est
+> plusieurs OE d'une même réception - le FirstOrDefault est
 > déterministe.

+**Contrôle de tolérance (custom)** : dans le standard la tolérance ne
+sert que pour l'excès ; ici elle est vérifiée **dans les deux sens**
+(quantité reçue inférieure ou supérieure à l'attendu). Le pourcentage
+`ReceiveMorePercent` provient de la **valeur de la ligne du ROR**, et à
+défaut de la **valeur du profil de réception de l'article**
+(WF `Reception_CheckIfAllReceptionLinesAreCompleted_PR`).
+
 Les OE flaggés ne se clôturent pas automatiquement (ROF bloqué) et
 s'affichent en rouge dans la vue (voir § Clôture des OE ci-dessous).

@@ -499,18 +571,19 @@ Un seul REF est envoyé par réception (pas de REF progressif, car

 - Numéros de conteneurs réceptionnés
 - Lignes de stocks associées
- [CUSTOM] **Zone de stockage** (récupérée depuis le code emplacement
-  du support) :
+- [CUSTOM] **Zone de stockage** dans le champ **`LneStockCstAtt01`**
+  (récupérée depuis le code emplacement du support, GNA
+  `REF01Observer.boo`) :
  - Fournisseur / intersite : si un support se trouve hors de l'ASRS
    au moment du REF → valeur **"NON RANGEE"**
  - Retour client : ce cas ne se produit pas (REF conditionné au
-    rangement complet — voir [Réception retour](reception-retour.md))
+    rangement complet - voir [Réception retour](reception-retour.md))
 - [CUSTOM] Attributs stock remontés : code produit SAP, code
  propriétaire réel, description courte, pays de destination, lot SAP

 **LOC** : envoyé sur delta de 5 min (palette créée/déplacée/supprimée).
 Le LOC ne prend pas en compte les palettes liées à une réception non
-fermée (standard dans le WSC forké — développement dédié
+fermée (standard dans le WSC forké - développement dédié
 [LIM-76](https://easywmsfrance.atlassian.net/browse/LIM-76)).

 ### Clôture des ordres d'entrée (OE) (LIM-73 §2)
@@ -519,7 +592,7 @@ fermée (standard dans le WSC forké — développement dédié
 |--------------|---------|-----|------------------|
 | Reçu = attendu | Auto-close | Envoi auto | Auto-archivé → absent |
 | Écart dans la tolérance | Auto-close (custom) | Envoi auto | Auto-archivé → absent |
-| Écart hors tolérance (`CstAtt01 OE = true`) | Manuelle par non-opérateur | Envoyé manuellement | **Rouge** — bouton restreint |
+| Écart hors tolérance (`CstAtt01 OE = true`) | Manuelle par non-opérateur | Envoyé manuellement | **Rouge** - bouton restreint |

 **Visibilité du bouton « Clôturer l'OE »** :

@@ -532,9 +605,35 @@ fermée (standard dans le WSC forké — développement dédié
 Le manager régularise dans SAP (envoi éventuel d'un nouveau ROR) puis
 clôture manuellement l'OE → ROF envoyé.

+### [CUSTOM] Éléments techniques (revue de code validée 2026-06-02)
+
+Implémentation définitive issue de la revue de code LIM-73. Éléments
+clés au-delà de `Reception_Close_PR_V2` (§ ci-dessus) :
+
+| Élément | Type | Rôle |
+|---------|------|------|
+| `InboundOrder_AutoCloseInboundOrder_PR_V2` | WF | Ne clôture pas l'OE si `CstAtt01 OE = true` (blocage ROF hors tolérance). Résout la question « modifier le WF existant vs en créer un » : c'est le V2 existant qui est adapté |
+| `Container_MovedEventHandler_Warehouse_PR` | WF | Pose `CstAtt11 = true` sur le conteneur quand la tâche de rangement se termine en APS (retour) |
+| `ReceiptLine_AutoClose_PR_V2` | WF | Auto-close des **lignes de réception désactivé** (causait des problèmes avec le process de réception au poste ; la clôture est gérée par le process ci-dessus) |
+| `Reception_CheckReceiveMore_UI` | WF | Ne bloque plus l'excédent au poste : le client peut recevoir autant qu'il veut (l'écart est traité à la clôture via `CstAtt01 OE`) |
+| `Reception_CheckIfAllReceptionLinesAreCompleted_PR` | WF | Vérifie la tolérance sur chaque ligne dans les deux sens ; source `ReceiveMorePercent` = ligne ROR ou profil article |
+| `InboundOrder_UpdateStatus_By_Reception_ChangedStatus_PR_V2` | WF | Un OE partiellement reçu **et** `CstAtt01 = true` est considéré comme clôturé |
+| `WorkStation_Reception_Supplier_UI` | WF/UI | Activité « Close Reception » après avoir informé l'opérateur que le manager devra clôturer l'OE manuellement |
+| `CST_View_RecOrder_ToleranceError` | Ressource | Message d'avertissement hors tolérance affiché à la fermeture (FR/EN) |
+| `REF01Observer.boo` | GNA | Zone de stockage du support dans `LneStockCstAtt01` (« NON RANGEE » si hors ASRS) |
+
+> **Revue de code (points corrigés)** : test de nullité de
+> `CST_InboundOrder` après la query `CST_GetInboundOrder`
+> (`InboundOrder_AutoCloseInboundOrder_PR_V2`) et test de nullité après
+> les `FirstOrDefault` dans `REF01Observer.boo`.
+
 ### Réception excédentaire (> % autorisé)

-Le WMS bloque. Solutions possibles :
+> ⚠️ Depuis LIM-73, `Reception_CheckReceiveMore_UI` **ne bloque plus**
+> l'opérateur sur un excédent : le client peut réceptionner autant qu'il
+> veut. L'excès est traité à la clôture (flag `CstAtt01 OE`, affichage
+> rouge, régularisation SAP). Les solutions ci-dessous restent valables
+> côté SAP pour régulariser l'attendu.

 | Solution | Description |
 |----------|-------------|
@@ -560,7 +659,7 @@ notification SmartUI (ancienne approche de renvoi au PK abandonnée).
 ⚠️ Le process de constitution mono-référence est **standard** (pas de
 développement spécifique).

-⚠️ Filmage : transmis à Galileo via custom data (CstAtt05) — uniquement
+⚠️ Filmage : transmis à Galileo via custom data (CstAtt05) - uniquement
 si PIE OK. Paramètre SmartUI `FILMAGES` définit la liste des programmes.

 ⚠️ `AutoCloseReception = true` mais la clôture effective dépend des
@@ -572,27 +671,35 @@ poids ITM pour tous les calculs suivants.

 ## Questions ouvertes

- [x] Programme de filmage exact — documenté, 8 programmes A→H,
+- [x] ~~Programme de filmage exact~~ - documenté, 8 programmes A→H,
  paramètre SmartUI `FILMAGES` (LIM-67)
- [ ] Gestion TRF si AGV pas prêts au démarrage (@Théo)
- [ ] Utilisation du ROC (confirmation de réception) — point interne
+- ❓ Gestion TRF si AGV pas prêts au démarrage (@Théo)
+- ❓ Utilisation du ROC (confirmation de réception) - point interne
  Limagrain (@Justine)
- [ ] Création fournisseurs/clients à la volée dans EasyWMS —
+- ❓ Création fournisseurs/clients à la volée dans EasyWMS -
  faisabilité technique (@Nicolas)
- [ ] Vérifier fonctionnement ExceedPercentageAllowed vs profil de
+- ❓ Vérifier fonctionnement ExceedPercentageAllowed vs profil de
  réception (@Nicolas)
- [ ] Choix fournisseur imprimantes RFID — exiger compatibilité
+- ❓ Choix fournisseur imprimantes RFID - exiger compatibilité
  ZPL (@Théo)
- [ ] Position étiquette image de quai (devant/côté) — à valider
+- ❓ Position étiquette image de quai (devant/côté) - à valider
  avec le client (@Justine)
- [ ] Poids variable — vérifier si le standard gère la capture de
+- ❓ Poids variable - vérifier si le standard gère la capture de
  poids (@Nicolas)
- [ ] Surplus non réceptionné hors tolérance — quelle solution pour
+- ❓ Surplus non réceptionné hors tolérance - quelle solution pour
  les palettes impossibles à réceptionner ? (@Justine)
- [ ] Palette refusée PIE mais non supprimée — comment gérer le
+- ❓ Palette refusée PIE mais non supprimée - comment gérer le
  support qui reste en base ? (@Nicolas) (LIM-73)
- [ ] WF clôture OE : faut-il modifier le WF existant ou en créer
-  un nouveau pour la condition CstAtt01 ? (@Fabien) (LIM-73)
+- [x] ~~WF clôture OE : faut-il modifier le WF existant ou en créer
+  un nouveau pour la condition CstAtt01 ? (@Fabien) (LIM-73)~~ →
+  **Résolu** (revue de code validée 2026-06-02) : le WF existant
+  `InboundOrder_AutoCloseInboundOrder_PR_V2` est adapté pour ne pas
+  clôturer l'OE si `CstAtt01 = true` (pas de nouveau WF)
+- ~~Conflit d'usage `CstAtt06` (support) : LIM-71 marqueur de destination
+  vs LIM-67 code du poste de picking~~ → **Résolu** : LIM-71 a abandonné
+  son marquage `CstAtt06` (destination via stratégies de rangement).
+  `CstAtt06` = uniquement code du PK lié (LIM-67), confirmé par LIM-70 et
+  le job de régénération réception→PK (LIM-71).

 ## Historique des modifications

@@ -603,6 +710,9 @@ poids ITM pour tous les calculs suivants.
 | 2026-05-12 | Arthur | Réécriture section traitement poste travail (LIM-67) : menu 5 actions, CstAtt02/03/05/08/10, filmage FILMAGES |
 | 2026-05-12 | Arthur | Réécriture section clôture (LIM-73) : AutoCloseReception=true, Reception_Close_PR_V2, REF custom, clôture OE 3 cas |
 | 2026-05-13 | Arthur | Restauration sections tronquées (points d'attention, questions, historique, références) |
+| 2026-07-16 | Arthur | Relecture commentaires LIM-67 (revue de code, livré préprod 09/07) : scan conteneur virtuel + code auto-généré, gestion codes conteneurs ROR / support LIMAGRAIN (CstAtt13), 6 tables préparation + poste adjacent (CstAtt06), action « Retirer support », optimisation attributs logistiques → LIM-93, conflit CstAtt06 signalé |
+| 2026-07-17 | Arthur | Conflit CstAtt06 résolu (LIM-71 a abandonné son marquage) : note tableau CstAtt et question ouverte mises à jour |
+| 2026-07-17 | Arthur | Relecture commentaires + revue de code LIM-73 (validée 02/06, préprod) : section « Éléments techniques » (WF définitifs), champ REF `LneStockCstAtt01`, source tolérance (ligne ROR / profil article), excédent non bloquant (`Reception_CheckReceiveMore_UI`), question WF clôture OE résolue (`InboundOrder_AutoCloseInboundOrder_PR_V2`) |

 ## Références

@@ -610,5 +720,6 @@ poids ITM pour tous les calculs suivants.
 |--------|------|------|
 | FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5 | Analyse fonctionnelle | 28/11/2025 |
 | Réception - LIMAGRAIN - DEV - Confluence | Page ateliers DEV | 2026 |
-| [LIM-67](https://easywmsfrance.atlassian.net/browse/LIM-67) | Ticket Jira (postes travail) | 2026 |
-| [LIM-73](https://easywmsfrance.atlassian.net/browse/LIM-73) | Ticket Jira (clôture/REF) | 2026 |
+| [LIM-67](https://easywmsfrance.atlassian.net/browse/LIM-67) | Ticket Jira (postes travail) - relecture commentaires + revue de code | 2026-07-16 |
+| [LIM-73](https://easywmsfrance.atlassian.net/browse/LIM-73) | Ticket Jira (clôture/REF) - revue de code validée, préprod | 2026-06-02 |
+| [LIM-93](https://easywmsfrance.atlassian.net/browse/LIM-93) | Ticket Jira (optimisation attributs logistiques) | 2026 |
@@ -3,10 +3,10 @@ title: "Réception retour commandes clients"
 tags: [inbound, réception, retour, client, API, lot]
 status: draft
 standard_ref: concepts/reception.md
-jira_refs: [LIM-72, LIM-67, LIM-68, LIM-66, LIM-64, LIM-70, LIM-73]
+jira_refs: [LIM-93, LIM-72, LIM-67, LIM-68, LIM-66, LIM-64, LIM-70, LIM-73, LIM-90]
 confluence_refs: []
-sources: [FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5.docx, "Réception - LIMAGRAIN - DEV - Confluence.md", "LIM-72 LOT1.3 [RETOUR] Flux complet PK.md", "LIM-73 - LOT1.3 [RECEPTION] Fermetures, REF et gestion retours.md", "recap_session_LIM-72_13-05-2026.md"]
-last_updated: 2026-05-13
+sources: [FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5.docx, "Réception - LIMAGRAIN - DEV - Confluence.md", "LIM-72 LOT1.3 [RETOUR] Flux complet PK.md", "LIM-73 - LOT1.3 [RECEPTION] Fermetures, REF et gestion retours.md", "Jira LIM-93 (V2, préprod, revue de code en cours 2026-07-17)", "Jira LIM-73 (revue de code validée 2026-06-02, relecture 2026-07-17)", "Jira LIM-90 (revue de code terminée 2026-06-03)", "recap_session_LIM-72_13-05-2026.md"]
+last_updated: 2026-07-17
 author: Arthur
 ---

@@ -19,16 +19,30 @@ author: Arthur
 > **Standard EasyWMS** : → voir [Reception](../../concepts/reception.md)
 > Ce qui suit documente les **spécificités Limagrain** par rapport au standard.

+> ⚠️ **V1 annulé → V2 (LIM-93) intégré** : le ticket
+> [LIM-72](https://easywmsfrance.atlassian.net/browse/LIM-72) « Flux complet
+> PK V1 » est **Annulé(e)**. Le traitement retour au PK est repris et livré
+> par [LIM-93](https://easywmsfrance.atlassian.net/browse/LIM-93) (V2,
+> **En cours de test client / préprod**). Le contenu ci-dessous reflète la
+> version définitive V2 (description + revue de code, relecture
+> 2026-07-17). Différences majeures V2 vs V1 : appel ATH214
+> **systématique** (plus de branche « lot connu »), champ `ZDEPLOY`
+> confirmé, nouveaux champs `ET_BATCH`, sélection du statut de stock en
+> **étape dédiée** avant la quantité (statut fictif « Stock conforme »),
+> étiquette = **RFID LIM-68 enrichie** (A5 Zebra, pas de rapport séparé),
+> rejet PIE **renvoyé au PK** pour recomptage (placeholder, solution
+> technique à définir).
+
 ## Contexte projet

 Les retours client suivent un flux similaire aux réceptions extérieures
 (passage poste de travail obligatoire) mais avec des particularités :

- `InboundType = 1` (Return) — vs 0 (Standard) pour les autres flux
+- `InboundType = 1` (Return) - vs 0 (Standard) pour les autres flux
 - Création de lignes autorisée (article non attendu possible)
 - Tolérance illimitée : profil de réception par défaut configuré en
  « illimité » sur tous les articles
- `ReceiveLessAllowed = true` — réception partielle toujours autorisée
+- `ReceiveLessAllowed = true` - réception partielle toujours autorisée
 - Interrogation API SAP pour valider le lot officiel
 - `AccountCode` = code client SAP (le client doit exister dans EasyWMS)

@@ -38,12 +52,12 @@ Les retours client suivent un flux similaire aux réceptions extérieures
 |-------|-------------|--------|
 | 1 | Déclaration sur l'image de quai | [LIM-64](https://easywmsfrance.atlassian.net/browse/LIM-64) |
 | 2 | Déplacement AGV → poste de travail | [LIM-70](https://easywmsfrance.atlassian.net/browse/LIM-70) |
-| 3 | **Traitement au poste de travail** | [LIM-72](https://easywmsfrance.atlassian.net/browse/LIM-72) |
-| 4 | Déplacement AGV → table d'entrée (+ filmage si demandé) | — |
+| 3 | **Traitement au poste de travail** | [LIM-72](https://easywmsfrance.atlassian.net/browse/LIM-72) (V1 annulé) → [LIM-93](https://easywmsfrance.atlassian.net/browse/LIM-93) (V2) |
+| 4 | Déplacement AGV → table d'entrée (+ filmage si demandé) | - |
 | 5 | Passage PIE | [LIM-66](https://easywmsfrance.atlassian.net/browse/LIM-66) |
-| 6 | Stockage ou rejet | — |
-| 7 | Clôture de la réception | — |
-| 8 | Libération quai / image de quai | — |
+| 6 | Stockage ou rejet | - |
+| 7 | Clôture de la réception | - |
+| 8 | Libération quai / image de quai | - |

 Voir [Réception fournisseur](reception-fournisseur.md) pour le détail
 du déchargement camion et des déclarations initiales
@@ -57,17 +71,24 @@ Message ROR de SAP (type ORDRSP) avec :
 - Numéro de réception
 - Articles / Lots / Quantités attendues
 - Codes articles **génériques** (codes uniques avec nomenclature
-  précise, pas réutilisables — assure la traçabilité)
+  précise, pas réutilisables - assure la traçabilité)

 **Différence clé** : cette réception **autorise la création de lignes**.
 Limagrain peut recevoir un article non présent dans le ROR initial.
 Un article inconnu de la base EasyWMS = ROR refusé. Un article connu
 mais non prévu dans le retour = accepté (tolérance illimitée).

-## [CUSTOM] Identification lot — Interrogation API SAP
+## [CUSTOM] Identification lot - Interrogation API SAP

-Lors du scan du lot officiel sur le poste de travail, le WMS vérifie
-d'abord si le lot est connu localement. Si oui, pas d'appel API. Sinon :
+Lors du scan du lot officiel sur le poste de travail, le WMS appelle
+**systématiquement** l'API SAP ATH214, que le lot soit déjà connu en
+base ou non.
+
+> **Changement V2 (confirmation Vincent Goyet, 13/05)** : l'appel ATH214
+> est désormais systématique. Il n'y a plus de branche « lot connu → pas
+> d'appel ». La vérification « vendu par Limagrain » (flag `ZDEPLOY`)
+> passe toujours par SAP. Cela ferme le trou fonctionnel A4 (lots connus
+> non re-vérifiés).

 ### Rappel : structure des articles chez Limagrain

@@ -85,24 +106,26 @@ SAP d'envoyer la fiche article complète.

 ```mermaid
 flowchart TD
-    A[Scan / saisie lot officiel] --> B{Lot officiel connu du WMS ?<br/>= alias article existant ?}
-    B -- Oui --> C{Vendu par Limagrain ?}
-    B -- Non --> D[Appel API SAP]
-    D --> E[Écran attente<br/>refresh 5s / timeout 1 min]
-    E --> F{ITM reçu via API WMS ?}
-    F -- Oui --> C
+    A[Scan / saisie lot officiel] --> D[Appel API SAP ATH214<br/>SYSTÉMATIQUE<br/>IV_BATCH_OFF + IV_RETURN]
+    D --> R{EV_RETURN = X ?}
+    R -- Non --> Z[Erreur SAP<br/>afficher ET_RETURN]
+    R -- Oui --> C{Au moins un<br/>ZDEPLOY = X ?}
+    C -- Non --> K[Erreur : lot non vendu<br/>par Limagrain]
+    C -- Oui --> B{Article déjà en base ?<br/>= alias existant ?}
+    B -- Non --> E[SAP pousse l'ITM<br/>via ATH002/ITM01<br/>Écran attente refresh 5s / timeout 1 min]
+    E --> F{Alias trouvé en base ?}
    F -- Non / Timeout --> G{Tentative < 5 ?}
    G -- Oui --> H[Bouton Réessayer]
    H --> D
    G -- Non --> I[Erreur finale :<br/>contacter responsable]
-    C -- Oui --> J{Plusieurs articles ?}
-    C -- Non --> K[Erreur : lot non vendu<br/>par Limagrain]
+    F -- Oui --> J
+    B -- Oui --> J{Plusieurs lots<br/>ZDEPLOY = X ?}
    J -- Non --> L[Sélection automatique<br/>→ déclaration contenu]
-    J -- Oui --> M[Dialogue choix article<br/>par pays d'origine]
+    J -- Oui --> M[Dialogue choix lot SAP<br/>Variété - Trt commercial - Destination code]
    M --> L
 ```

-### Appel API SAP — Vérification du lot officiel (ATH214)
+### Appel API SAP - Vérification du lot officiel (ATH214)

 L'appel API REST est fait **directement depuis le workflow** (pas via
 GNA). Il sert à notifier SAP que le WMS a besoin de la fiche article.
@@ -176,7 +199,7 @@ GET /http/ATHInboundMessage
 | `IV_BATCH_OFF` | CHAR 30 | Lot officiel scanné sur le sac |
 | `IV_RETURN` | CHAR 10 | Numéro du document de retour (code OE) |

-> ⚠️ **Méthode HTTP** : `GET` avec body JSON — spécifique SAP CPI.
+> ⚠️ **Méthode HTTP** : `GET` avec body JSON - spécifique SAP CPI.
 > Header `Connection: keep-alive` requis.

 **Payload de réponse :**
@@ -190,7 +213,12 @@ GET /http/ATHInboundMessage
      "MATNR": "000000000000020955",
      "CHARG": "2023293649",
      "BATCH_OFF": "F0964D002488",
-      "EV_DEPLOY": "X"
+      "DESCRIPTION": "Tournesol variété XYZ",
+      "DESTINATION": "FR",
+      "OWNER": "LFS",
+      "ZDEPLOY": "X",
+      "VAR_DESC": "LG50459 SX",
+      "COM_TRT_DESC": "Korit"
    }
  ]
 }
@@ -203,7 +231,12 @@ GET /http/ATHInboundMessage
 | `ET_BATCH[].MATNR` | CHAR 40 | Code lot WMS = product code SAP |
 | `ET_BATCH[].CHARG` | CHAR 10 | Code article WMS = lot SAP |
 | `ET_BATCH[].BATCH_OFF` | CHAR 30 | Lot officiel |
-| `ET_BATCH[].EV_DEPLOY` | CHAR 1 | `"X"` = déployé/vendu, `""` = non |
+| `ET_BATCH[].DESCRIPTION` | CHAR 40 | Description article SAP |
+| `ET_BATCH[].DESTINATION` | CHAR 18 | Pays de destination |
+| `ET_BATCH[].OWNER` | CHAR 10 | Propriétaire Limagrain |
+| `ET_BATCH[].ZDEPLOY` | CHAR 1 | `"X"` = déployé/vendu, `""` = non |
+| `ET_BATCH[].VAR_DESC` | - | Variété (ajout Justine 08/07) |
+| `ET_BATCH[].COM_TRT_DESC` | - | Traitement commercial (ajout Justine 08/07) |

 > ⚠️ **Mapping inversé CHARG / MATNR** : contrairement à la
 > nomenclature SAP standard, `MATNR` (Material Number) porte ici le
@@ -211,14 +244,16 @@ GET /http/ATHInboundMessage
 > **code article WMS** (= lot SAP). Ce mapping est confirmé par Michael
 > Chaudier et Vincent Goyet (avril 2026).

-> ⚠️ **À confirmer** : le nom du champ de déploiement est ambigu dans
-> les échanges — `EV_DEPLOY` ou `ZDEPLOY` ? En attente de clarification
-> (question A2 dans
-> [Questions ouvertes](../08-transverse/questions-ouvertes.md)).
+**Traitement de la réponse (V2) :**

-Si `EV_RETURN = "X"`, on récupère dans `ET_BATCH` tous les
-`BATCH_OFF` dont `EV_DEPLOY = "X"` — ce sont les lots autorisés
-pour l'opérateur.
+1. Si `EV_RETURN = ""` → afficher le message d'erreur de `ET_RETURN`
+   à l'opérateur
+2. Si `EV_RETURN = "X"` → filtrer `ET_BATCH` pour ne garder que les
+   entrées avec `ZDEPLOY = "X"` (lots déployés/vendus)
+3. Si aucune entrée `ZDEPLOY = "X"` → erreur « le lot n'a pas été vendu
+   par Limagrain »
+4. Sinon → vérifier l'existence des articles en base (voir écran
+   d'attente ITM), puis sélection automatique ou dialogue multi-lot

 ### Écran d'attente pendant la réception de l'ITM

@@ -240,20 +275,30 @@ l'ITM. Pendant cette attente :
 ### Choix du code lot (multi-résultat)

 Si l'API a renvoyé **plusieurs résultats** dans `ET_BATCH` (plusieurs
-`BATCH_OFF` avec `EV_DEPLOY = "X"`), un dialogue de sélection est
-affiché avec la liste des codes lots disponibles. L'opérateur en choisit
-un (filtrage par pays d'origine).
+entrées avec `ZDEPLOY = "X"`), le dialogue `CST_EtBatchSelector` est
+affiché avec la liste des lots SAP disponibles. L'opérateur en choisit un.

-Si un **seul résultat** → sélection automatique, pas de dialogue.
+**Format d'affichage d'une ligne (revu Justine, 08/07)** :

-**Pourquoi le choix article ?** Un lot SAP peut être associé à plusieurs
-articles (dépend du pays d'origine). L'opérateur doit choisir l'article
-physiquement présent sur la palette.
+```text
+VAR_DESC - COM_TRT_DESC - DESTINATION (MATNR)
+```
+
+soit `Variété - Traitement commercial - Pays destination (product code)`.
+Ce format remplace l'affichage d'origine `CHARG / BATCH_OFF / DESCRIPTION
+/ DESTINATION / OWNER`.
+
+Si un **seul résultat** `ZDEPLOY = "X"` → sélection automatique, pas de
+dialogue.
+
+**Pourquoi le choix article ?** Un lot officiel peut correspondre à
+plusieurs lots SAP (dépend notamment de la destination). L'opérateur doit
+choisir le lot physiquement présent sur la palette.

 **Gestion dans le REF :** le code générique envoyé dans le ROR est
 remplacé par le vrai code lot dans le REF (custom).

-## Déclaration au poste de travail (LIM-72)
+## Déclaration au poste de travail (LIM-93)

 Le traitement au PK reprend les mêmes étapes que le flux fournisseur
 ([LIM-67](https://easywmsfrance.atlassian.net/browse/LIM-67)) avec des
@@ -263,28 +308,74 @@ différences :
 | # | Étape | Différence vs fournisseur (LIM-67) |
 |---|-------|------------------------------------|
 | 1 | Sélection de la réception | Affichage "**Client: CODE - NOM**" (au lieu de "Fournisseur") sur tous les écrans |
-| 2 | Big bag (CstAtt02) | Identique — toggle ON/OFF |
-| 3 | Scan lot officiel + vérification | **+ Vérification API SAP** (voir section ci-dessus) |
-| 4 | Déclaration quantité | Identique — affichage qté attendue + UdM, prompt non pré-rempli |
-| 4bis | Flag big-bag (bouton custom) | Identique (CstAtt02) |
-| 5 | Statut de stock | **Modifiable** — boutons visibles (masqués dans LIM-67) |
-| 6 | Flag "À anoxier" | Identique (CstAtt03 = true) |
-| 7 | Programme de filmage | Identique (paramètre FILMAGES → CstAtt05) |
-| 8 | Impression étiquette RFID | Identique ([LIM-68](https://easywmsfrance.atlassian.net/browse/LIM-68)) |
-| 9 | Validation → évacuation AGV | Identique |
+| 2 | Big bag (CstAtt02) | Identique - toggle ON/OFF |
+| 3 | Scan lot officiel + vérification | **+ Vérification API SAP systématique** (voir section ci-dessus) |
+| 4 | Statut de stock | **Étape dédiée AVANT la quantité** (V2) - dialogue avec statut fictif « Stock conforme » en tête (voir ci-dessous) |
+| 5 | Déclaration quantité | Identique - affichage qté attendue + UdM, prompt non pré-rempli. Bouton statut supprimé (ESC renvoie au dialogue statut) |
+| 5bis | Flag big-bag (bouton custom) | Identique (CstAtt02) |
+| 6 | Attributs logistiques | **Auto-validés si présents/uniques dans le ROR**, sinon demandés (voir ci-dessous) |
+| 7 | Flag "À anoxier" | Identique (CstAtt03 = true) |
+| 8 | Programme de filmage | Identique (paramètre FILMAGES → CstAtt05) |
+| 9 | Impression étiquette RFID | **Enrichie** - RFID [LIM-68](https://easywmsfrance.atlassian.net/browse/LIM-68) + code produit / lots SAP / lot officiel, format A5 Zebra (voir ci-dessous) |
+| 10 | Validation → évacuation AGV | Identique |

-### Statut de stock — Modifiable
+### Statut de stock - Modifiable, en étape dédiée (V2)

 Contrairement au flux fournisseur (LIM-67) où le statut de stock est
-verrouillé (boutons masqués), dans le flux retour client :
+verrouillé (boutons masqués), dans le flux retour client l'opérateur
+peut **choisir** le statut. Le choix se fait désormais dans une **étape
+dédiée, avant la saisie de la quantité** (et non plus via un bouton sur
+l'écran quantité).

- Les **boutons de changement de statut sont visibles** et fonctionnels
- L'opérateur peut modifier le statut (ex : Conforme, Sac sale,
-  Non conforme, etc.)
+- Un dialogue liste les statuts autorisés en retour
+  (query `CST_StockStatus_AllowedForReturn`, CstAtt1 = applicable en
+  réception)
+- En **position 0** de la liste : un statut fictif « **Stock
+  conforme** » qui, s'il est choisi, **n'applique aucun statut**
+  (paramètre `RECEPTION_CONFORM_STOCK_STATUS`). Cela permet à
+  « n'avoir aucun statut » d'être un vrai choix explicite (demande
+  client 09/06)
+- Le bouton « statut » de l'écran quantité est **supprimé** ; la touche
+  **ESC** depuis l'écran quantité **renvoie au dialogue des statuts**
 - Les écrans de **date de fin de statut** et **commentaire** suivent
  le comportement standard (non skippés contrairement au fournisseur)
+- Un message d'avertissement s'affiche si « Stock conforme » est
+  sélectionné pour une ligne qui ne demande pas de statut
 - [CUSTOM] Statuts spécifiques retour : **F9** (sacs sales), **B6**
-  (non conforme) — assignables uniquement dans ce processus
+  (non conforme) - assignables uniquement dans ce processus.
+  Catalogue complet des 8 statuts et remontée REF : voir
+  [Statuts de stock retour et remontée REF (LIM-90)](#statuts-de-stock-retour-et-remontée-ref-lim-90)
+
+### Attributs logistiques - Auto-validation (V2)
+
+Les attributs logistiques (lot officiel, etc.) sont **validés
+automatiquement** s'ils sont renseignés dans le ROR **et uniques** pour
+l'article. Sinon :
+
+- Un attribut manquant → **demandé à l'opérateur**
+- Le ROR possède **plusieurs lignes avec le même lot SAP mais des
+  attributs logistiques différents** → l'attribut est demandé
+  (EasyWMS ne peut pas deviner à quelle ligne la réception se rattache)
+
+### Étiquette RFID enrichie (V2)
+
+Il n'y a **pas de rapport d'étiquette stock séparé**. L'étiquette
+imprimée automatiquement après validation du filmage est l'**étiquette
+HU/RFID de [LIM-68](https://easywmsfrance.atlassian.net/browse/LIM-68)**,
+enrichie de champs supplémentaires. Elle est glissée entre les sacs de
+la palette.
+
+Champs ajoutés (en plus du contenu standard LIM-68) :
+
+- Code produit (`MATNR` / product code SAP)
+- Lot SAP (`CHARG` / code article WMS)
+- Lot officiel (`BATCH_OFF` / alias)
+
+Format : **A5 Zebra** (pas A6). Imprimante : **dédiée au PK**.
+
+> **Impact LIM-68** : la tâche
+> [LIM-68](https://easywmsfrance.atlassian.net/browse/LIM-68) devra
+> intégrer ces champs supplémentaires et le format A5 Zebra.

 ### Tolérance illimitée

@@ -295,7 +386,7 @@ verrouillé (boutons masqués), dans le flux retour client :
  manuellement)

 > Le prompt type de poste (3 ou 6 TP) prévu initialement est
-> **abandonné** — remplacé par un message d'avertissement si le poste
+> **abandonné** - remplacé par un message d'avertissement si le poste
 > adjacent est déjà ouvert (voir
 > [Stations picking](../03-picking/stations-picking.md)).

@@ -315,18 +406,40 @@ prorata, mêmes contrôles). Voir

 **Différences pour les retours client :**

- Verrou si écart poids : **« Écart inventaire »** (vs « Réception »
-  pour les autres flux) — verrou posé sur le **support** (pas sur
+- Verrou si écart poids : **« ECART RETOUR »** (vs « HORS TOLERANCE »
+  pour les autres flux) - verrou posé sur le **support** (pas sur
  le stock)
 - Action requise en cas d'écart : **recomptage du nombre de sacs**
- Rejet PIE : dirigé vers **poumon au sol** + notification SmartUI
-  (ancienne approche de renvoi au PK abandonnée)

-## Clôture — Spécificités retour client (LIM-73)
+### Flux de rejet PIE (⚠️ placeholder V2 - solution technique à définir)
+
+> **Changement V2 (confirmation Leila Chajjaoui, 13/05)** : le client
+> souhaite que les palettes retour rejetées au PIE (verrou ECART RETOUR)
+> **retournent au PK pour recomptage immédiat**. L'approche V1 (poumon de
+> rejet au sol + notification SmartUI) **ne correspond pas** au besoin et
+> est abandonnée.
+
+Points à résoudre avant implémentation :
+
+- Routage AGV retour **PIE → PK** : comment EasyS gère-t-il le renvoi
+  vers un PK ?
+- Relance du workflow de déclaration sur la même palette : peut-on
+  ré-ouvrir la palette au PK sans perdre les données déjà déclarées, ou
+  faut-il repartir de zéro ?
+- Gestion du verrou ECART RETOUR : levé automatiquement au retour au PK,
+  ou levé manuellement par le responsable ?
+- Impact sur la clôture : une palette en boucle PIE ↔ PK bloque-t-elle
+  indéfiniment la clôture ?
+
+Cette section sera complétée une fois la solution technique définie
+(question B2 dans
+[Questions ouvertes](../08-transverse/questions-ouvertes.md)).
+
+## Clôture - Spécificités retour client (LIM-73)

 Le mécanisme général de clôture (déclenchement auto-close, tolérance par
 ligne, CstAtt01 OE hors tolérance, clôture OE) est documenté dans
-[Réception fournisseur — Clôture](reception-fournisseur.md). Cette
+[Réception fournisseur - Clôture](reception-fournisseur.md). Cette
 section décrit le **delta retour client** : le REF est conditionné au
 rangement ASRS complet.

@@ -341,9 +454,10 @@ Pour les autres types de réception (fournisseur / intersite), le REF est
 émis à la clôture de la réception, quelle que soit la position des
 supports.

-### CstAtt11 — Marqueur de rangement ASRS
+### CstAtt11 - Marqueur de rangement ASRS

-À chaque fin de tâche de rangement dans l'ASRS :
+À chaque fin de tâche de rangement dans l'ASRS
+(WF `Container_MovedEventHandler_Warehouse_PR`, sur fin de tâche APS) :

 - Vérifier si le support provient d'une réception de type **retour**
 - Si oui → `CstAtt11 = true` sur le support
@@ -367,7 +481,7 @@ Dans la vue des réceptions, le statut visuel est piloté par le
 Pour les réceptions non-retour, CstAtt01 de la réception n'est pas
 utilisé (affichage standard).

-### Adaptation Reception_Close_PR_V2 — Partie A (retours)
+### Adaptation Reception_Close_PR_V2 - Partie A (retours)

 - **Si non-retour** → clôture immédiate, génération REF (standard)
 - **Si retour** :
@@ -391,57 +505,177 @@ en ASRS → la valeur sera toujours une zone réelle (jamais "NON RANGEE").

 | CstAtt | Entité | Rôle |
 |--------|--------|------|
-| CstAtt08 | Palette fictive | Code réception — détecte l'absence de palettes fictives restantes (§ auto-close) |
-| CstAtt10 | Palette réelle au PK | `true` pendant traitement PK — détecte qu'aucune palette n'est en cours de traitement |
-| CstAtt11 | Palette réelle | `true` quand rangée en ASRS — condition de clôture retour |
+| CstAtt08 | Palette fictive | Code réception - détecte l'absence de palettes fictives restantes (§ auto-close) |
+| CstAtt10 | Palette réelle au PK | `true` pendant traitement PK - détecte qu'aucune palette n'est en cours de traitement |
+| CstAtt11 | Palette réelle | `true` quand rangée en ASRS - condition de clôture retour |
 | CstAtt01 | Réception | `true` = clôture en attente de rangement ASRS (affichage jaune) |

-## État du développement LIM-72
+### [CUSTOM] Détection du mode retour (revue de code validée 2026-06-02)

-### Implémenté (commit 8401f5456d, 28/04/2026)
+Éléments techniques propres au flux retour issus de la revue de code
+LIM-73 (le socle clôture / tolérance est dans
+[Réception fournisseur](reception-fournisseur.md#custom-éléments-techniques-revue-de-code-validée-2026-06-02)) :

- Entité `CST_StockStatus` : CstAtt 1 applicable en retour, CstAtt 2 =
-  ZLOG, CstAtt 3 = ZINCO
- Query `CST_StockStatus_AllowedForReturn` : filtre statuts autorisés
- Workflow `CST_Return_Stock_GetStatus_UI` : sélection statut simplifié
- Workflow `Reception_FilterLinesByProductAndContainer_UI_V1` : retrait
-  filtre quantité (tolérance illimitée)
- Dialog `CST_GetProductQuantity_Prompt` : option SelectStatus ajoutée
+| Élément | Type | Rôle |
+|---------|------|------|
+| `CST_Reception_GetReceptionFromContainer` | WF | Si aucune réception trouvée pour le conteneur, recherche un **retour** au code correspondant ; si trouvé → `returnMode = true` |
+| `Reception_Supplier_ChooseReception_UI` | WF/UI | Ajout du paramètre formel `CST_ReturnMode` |
+| `WorkStation_Reception_Supplier_UI` | WF/UI | Ajout de l'attribut `CST_ReturnMode` |
+| `WorkStation_Reception_Supplier_ConfirmReceivedStock_UI` | WF/UI | Si retour → création du stock via une **commande différente** |
+| `CST_View_WaitForFullPutaway` | Ressource | Libellé du statut « Clôture en cours » : FR « En attente de rangement [CST 1] », EN « Waiting for full putaway [CST 1] » |

-### Reste à développer
+## Statuts de stock retour et remontée REF (LIM-90)

- Appel API SAP ATH214 + gestion token OAuth 2.0
- Écran d'attente ITM (polling alias 5s, timeout 1 min, 5 tentatives)
- Dialogue choix multi-lot (quand ET_BATCH contient plusieurs articles)
- Impression étiquette stock retour client (rapport custom à créer)
- Configuration flux de rejet PIE retours (verrou ECART RETOUR,
-  destination, notification)
+> **Statut** : préprod / test client. Revue de code terminée (03/06,
+> après une première itération NOK 02/06 : commentaires `// Custom`
+> manquants sur `REF01.boo` / `REF01Observer.boo`).
+
+Custom du message REF + GNA pour remonter à SAP le **statut de stock**
+(codes SAP ZLOG/ZINCO) et le **lot officiel** lors des réceptions retour
+client. Réutilise la détermination retour/fournisseur de
+[LIM-89](../06-erp-interface/gna-sap-cpi.md) : les balises ZLOG/ZINCO ne
+sont posées que si la réception est de **type retour**.
+
+Le STC étant désactivé (décision 30/04), le REF est le seul canal de
+remontée des statuts pour les retours.
+
+### Catalogue des 8 statuts (master data)
+
+`F2` (« Conforme sac propre ») = **absence de statut** dans le WMS : rien
+à créer. SAP interprète l'absence de statut comme F2 (ZLOG `0002` /
+ZINCO `0001`).
+
+| Libellé statut WMS | ZLOG (CstAtt2) | ZINCO (CstAtt3) | Bloque picking | Bloque shipping |
+|---|---|---|---|---|
+| (F9) Conforme sac sale | 0002 | 0091 | Non | Non |
+| (B6) Non conforme - Sacs ouverts | 0001 | 0002 | Oui | Oui |
+| (B6) Non conforme - Lot de l'année précédente | 0001 | 0003 | Oui | Oui |
+| (B6) Non conforme - Certificat absent | 0001 | 0004 | Oui | Oui |
+| (B6) Non conforme - Anomalie couture | 0001 | 0005 | Oui | Oui |
+| (B6) Non conforme - Article externe - Hors LMG | 0001 | 0006 | Oui | Oui |
+| (B6) Non conforme - Article non prévu | 0001 | 0007 | Oui | Oui |
+| (B6) Non conforme - Sac ouvert / endommagé | 0001 | 0008 | Oui | Oui |
+
+> ⚠️ Les blocages picking/shipping par statut sont **à confirmer avec
+> le client** (proposition ci-dessus : F9 ne bloque rien, tous les B6
+> bloquent picking et shipping).
+
+### Balises REF ajoutées (par ligne de stock)
+
+| Balise | Contenu | Cas F2 (sans statut) |
+|---|---|---|
+| `LneStockStatus` | Libellé du statut (ex. « (B6) Non conforme - Sacs ouverts ») | vide |
+| `LneStockZLOG` | Valeur CstAtt2 du statut | vide |
+| `LneStockZINCO` | Valeur CstAtt3 du statut | vide |
+| `LneStockOfficialLot` | Alias de l'article WMS = lot officiel SAP (1er alias dont la valeur diffère du code article), ajouté sous `LneItemCode` | vide/absent si pas d'alias |
+
+### Implémentation GNA (revue de code)
+
+| Fichier | Rôle |
+|---|---|
+| `REF01.boo` | Ajout du header du message REF (nouvelles données) |
+| `REF01Observer.boo` | Cœur : récupère l'alias selon le code produit ; récupère les CstAtt du statut de stock et les pose **uniquement si la réception est de type retour** |
+| `REF01.xsd` | Structure du message REF avec les données custom |
+
+Entité `CST_StockStatus` (déjà cataloguée, CstAtt2 = ZLOG, CstAtt3 =
+ZINCO) : voir [AD Customs](../07-admin/ad-customs.md).
+
+> Un REF **non-retour** (fournisseur / intersite) ne porte pas de
+> ZLOG/ZINCO ; le lot officiel reste présent si l'article a un alias.
+
+> Prérequis : le REF retour est conditionné au **rangement ASRS complet**
+> (LIM-73, CstAtt11).
+
+## [CUSTOM] Éléments techniques (LIM-93, revue de code)
+
+> **Statut** : LIM-93 « En cours de test client (préprod) ». Le socle
+> statut de stock a une revue de code validée (26/06) ; la partie API
+> ATH214 est en cours de revue (voir caveat plus bas).
+
+### Statut de stock - sélection en étape dédiée
+
+Implémentation (commits `5b36a4c5a3` 11/06, `55f8ced13f` 12/06 ; revue
+de code validée 26/06) :
+
+| Élément | Type | Rôle |
+|---------|------|------|
+| `CST_StockStatus` | Entité | CstAtt1 = applicable en réception, CstAtt2 = ZLOG, CstAtt3 = ZINCO |
+| `CST_StockStatus_AllowedForReturn` | Query | Statuts sélectionnables en réception retour (CstAtt1) |
+| `CST_StockStatus_ForView` | Query | Query de la vue `StockStatusVList` |
+| `StockStatusVList` | Vue | Affichage des CstAtt 1, 2 et 3 |
+| `CST_Return_Stock_GetStatus_UI` | WF | Clone simplifié de `Stock_GetStatus_UI` pour le retour ; ajoute le statut fictif « Stock conforme » en tête (paramètre `RECEPTION_CONFORM_STOCK_STATUS`) |
+| `Reception_GetQuantityAndUom_UI` | WF | Suppression du bouton de sélection de statut sur l'écran quantité |
+| `WorkStation_Reception_Supplier_UI` | WF | Déplacement de la sélection du statut **avant** la quantité |
+| `Reception_FilterLinesByProductAndContainer_UI_V1` | WF | Retrait du filtre qui exclut les lignes déjà réceptionnées → autorise la réception en excès (tolérance illimitée) |
+| `Reception_Supplier_CheckReceptionStatus_UI_V1` | WF | Autorise la création de ligne pour les réceptions de type retour |
+| `CST_GetProductQuantity_Prompt` | Dialog | Suppression de l'option de sélection de statut |
+| `RECEPTION_CONFORM_STOCK_STATUS` | Paramètre | Nom du statut fictif « Stock conforme » |
+
+### API ATH214 - vérification lot
+
+Implémentation (commit `d33037da72` 25/05 ; champs VAR_DESC/COM_TRT_DESC
+`fa5f2f863d` 08/07 ; auto-validation attributs `02364f440f` 07/07) :
+
+| Élément | Type | Rôle |
+|---------|------|------|
+| `CST_Reception_Return_ATH214_Request_UI` | WF | Gère la requête ATH214 vers SAP CPI et renvoie la liste `ET_BATCH` |
+| `CST_Reception_Return_ATH214_CheckData_UI` | WF | Process réception classe « Retour » : demande le code OE et la sélection du lot parmi ceux renvoyés par SAP |
+| `CST_Reception_Return_ATH214_CheckData_Product_UI` | WF | Vérifie l'existence du produit en base et gère l'attente de l'ITM (ATH002) |
+| `CaptureProductLotAttributeForReception_UI` | WF | Réutilise le lot sélectionné dans `CST_Reception_Return_ATH214_CheckData_UI` |
+| `GetReceptionProductByIA` | WF | En classe « Retour », permet de sélectionner un article/alias qui n'existe pas encore |
+| `CST_EtBatch` | Record | Modèle de données d'une entrée `ET_BATCH` (+ champs VarDesc, ComTrtDesc) |
+| `CST_EtBatchList` | List | Liste de `CST_EtBatch` |
+| `CST_EtBatchSelector` | Dialog | Sélecteur multi-lot (`VAR_DESC - COM_TRT_DESC - DESTINATION (MATNR)`) |
+| `CST_Reception_Return_API_TimeoutOption` | Dialog | Options en cas d'échec de communication selon le nombre de timeouts |
+| `CST_LogWebServiceCommunication` | Toggle | Active le logging de la communication API ATH214 |
+
+Ressources principales : `CST_Reception_Return_API_SelectLot`,
+`..._Error`, `..._MultiLot`, `..._NoDeployedLot`, `..._Timeout`,
+`..._TimeoutExceededTry_1`, `..._WaitingResponse`,
+`CST_Reception_Return_Prompt_InboundOrderCode`,
+`CST_Reception_Return_API_LotSelectionColumnHeader`.
+
+> ⚠️ **Caveat revue de code (Maxime Halgand 16/07 → Vincent Charvet
+> 17/07)** : sur `CST_Reception_Return_ATH214_Request_UI`, l'appel est
+> lancé en tâche `async` (`Task.Factory.StartNew`) pour afficher les
+> écrans sans attendre ; `callResult` est mis à jour dans la tâche. Le
+> timeout vient du `HttpClient` (100 s par défaut, soit ~200 s max :
+> token + data). **Seul cas de boucle infinie résiduel** : si
+> `LogManager.GetLogger` lève une exception (hors try/catch),
+> `callResult` n'est jamais mis à jour → à corriger avant validation.

 ## Points d'attention

-⚠️ Le paramètre `SAP_LOT_VERIFY_URL` doit pointer vers l'endpoint CPI
-unique `/http/ATHInboundMessage`, pas vers `/api/v1/lot/verify`.
+⚠️ Endpoint CPI unique `/http/ATHInboundMessage` avec `MessageType =
+"ATH214"` dans l'enveloppe JSON. Les paramètres V1 `SAP_LOT_VERIFY_*`
+sont **remplacés** par `SAP_CPI_TOKEN_URL`, `SAP_CPI_ENDPOINT_URL`,
+`SAP_ATH214_TIMEOUT` (60 s), `SAP_ATH214_MAX_RETRIES` (5),
+`SAP_ATH214_REFRESH_INTERVAL` (5000 ms) - voir
+[Paramètres projet](../07-admin/parametres-projet.md).

-⚠️ Le `MessageType` doit être `"ATH214"` dans l'enveloppe JSON.
-
-⚠️ Pour les lots **déjà connus** en base WMS, le flag "déployé" n'est
-pas vérifié dans le design actuel — trou fonctionnel identifié (question
-A4 dans [Questions ouvertes](../08-transverse/questions-ouvertes.md)).
+⚠️ La vérification « déployé » (`ZDEPLOY`) des lots **déjà connus** en
+base est désormais assurée par l'appel ATH214 **systématique** (V2). Le
+trou fonctionnel A4 est fermé.

 ## Questions ouvertes

- [ ] Champs manquants ET_BATCH : description article, pays destination,
-  propriétaire (@Vincent Goyet) — A1
- [ ] Nom final champ déploiement : EV_DEPLOY ou ZDEPLOY ?
-  (@Vincent Goyet) — A2
- [ ] Délai ATH214 → push ITM dimensionnement polling
-  (@Vincent Goyet) — A3
- [ ] Vérification "déployé" pour lots déjà connus sans ATH214
-  (@Vincent Goyet) — A4
- [ ] Étiquette stock retour : format, champs, imprimante
-  (@Leila / @Antoine) — B1
- [ ] Flux rejet PIE retour : destination, notification, actions
-  (@Leila / @Antoine) — B2
+- [x] ~~Champs manquants ET_BATCH : description article, pays destination,
+  propriétaire - A1~~ → Résolu : `DESCRIPTION`, `DESTINATION`, `OWNER`
+  ajoutés, plus `VAR_DESC` (variété) et `COM_TRT_DESC` (traitement
+  commercial)
+- [x] ~~Nom final champ déploiement : EV_DEPLOY ou ZDEPLOY ? - A2~~ →
+  Résolu : `ZDEPLOY` (confirmé V2)
+- [x] ~~Délai ATH214 → push ITM dimensionnement polling - A3~~ → Résolu :
+  polling 5000 ms, timeout 60 s, 5 tentatives (paramétrés)
+- [x] ~~Vérification "déployé" pour lots déjà connus sans ATH214 - A4~~ →
+  Résolu : appel ATH214 systématique
+- [x] ~~Étiquette stock retour : format, champs, imprimante - B1~~ →
+  Résolu : pas de rapport séparé, RFID LIM-68 enrichie (A5 Zebra,
+  imprimante dédiée PK)
+- Flux rejet PIE retour (B2) : le client veut un **renvoi au PK pour
+  recomptage** (approche poumon abandonnée). Routage AGV PIE → PK, relance
+  du workflow sur la même palette, levée du verrou ECART RETOUR, impact
+  clôture - **solution technique à définir** (@Leila / @Antoine)

 ## Historique des modifications

@@ -452,15 +686,22 @@ A4 dans [Questions ouvertes](../08-transverse/questions-ouvertes.md)).
 | 2026-05-12 | Arthur | Intégration LIM-72 (process complet 8 étapes, API SAP, CstAtt) |
 | 2026-05-12 | Arthur | Intégration LIM-73 (clôture retour, CstAtt11, REF conditionné) |
 | 2026-05-13 | Arthur | Correction API : endpoint CPI unique + ATH214, auth OAuth 2.0, mapping CHARG/MATNR, état dev, questions ouvertes |
+| 2026-07-17 | Arthur | LIM-72 confirmé Annulé(e) (V1) → repris par LIM-93 (V2) : notes de supersession ajoutées (résumé, table process, état dev) ; contenu V1 conservé comme référence à valider. Détail définitif différé à la relecture de LIM-93 |
+| 2026-07-17 | Arthur | Relecture revue de code LIM-73 (validée 02/06, préprod) : sous-section « Détection du mode retour » (WF returnMode, `Container_MovedEventHandler_Warehouse_PR` pour CstAtt11, ressource `CST_View_WaitForFullPutaway`) |
+| 2026-07-17 | Arthur | Intégration LIM-90 (revue de code terminée 03/06, préprod) : section « Statuts de stock retour et remontée REF » (catalogue 8 statuts ZLOG/ZINCO + blocage picking/shipping, F2 = absence de statut, balises `LneStockStatus`/`LneStockZLOG`/`LneStockZINCO`/`LneStockOfficialLot`, GNA `REF01.boo`/`REF01Observer.boo`/`REF01.xsd`, réutilise détermination retour LIM-89) |
+| 2026-07-17 | Arthur | Intégration LIM-93 V2 (préprod, revue de code en cours) : appel ATH214 **systématique** (résout A4), champs `ET_BATCH` `DESCRIPTION`/`DESTINATION`/`OWNER`/`ZDEPLOY`/`VAR_DESC`/`COM_TRT_DESC` (résout A1/A2), dialogue multi-lot reformaté, statut de stock en **étape dédiée** + statut fictif « Stock conforme » (`RECEPTION_CONFORM_STOCK_STATUS`), auto-validation attributs logistiques, **étiquette RFID enrichie** A5 Zebra (résout B1, impact LIM-68), rejet PIE **renvoi au PK** placeholder (B2), section « Éléments techniques » (WF/dialogs/records ATH214 + caveat boucle infinie), verrou PIE renommé « ECART RETOUR » |

 ## Références

 | Source | Type | Date |
 |--------|------|------|
-| Jira LIM-72 | Ticket | 2025 |
-| Jira LIM-73 | Ticket | 2025 |
+| [LIM-72](https://easywmsfrance.atlassian.net/browse/LIM-72) | Ticket Jira (V1, Annulé) | 2026 |
+| [LIM-93](https://easywmsfrance.atlassian.net/browse/LIM-93) | Ticket Jira (V2 - description + revue de code, préprod) | 2026-07-17 |
+| Commits LIM-93 : `d33037da72` (API ATH214), `5b36a4c5a3` / `55f8ced13f` (statut de stock), `02364f440f` (auto-validation attributs), `fa5f2f863d` (VAR_DESC/COM_TRT_DESC) | Git | 2026-05/07 |
+| [LIM-73](https://easywmsfrance.atlassian.net/browse/LIM-73) | Ticket Jira (clôture/REF retour) - revue de code validée, préprod | 2026-06-02 |
+| [LIM-90](https://easywmsfrance.atlassian.net/browse/LIM-90) | Ticket Jira (statuts ZLOG/ZINCO + lot officiel) - revue de code terminée, préprod | 2026-06-03 |
 | Jira LIM-14 | Ticket (CstAtt) | 2025 |
 | Athenzat SAP-CPI Webservices Documentation v1.0 | PDF | 2026-04-24 |
 | Mail Michael Chaudier ↔ Vincent Goyet | Échange | 2026-04-07/10 |
 | Mail Justine ↔ Leila ↔ Vincent Goyet ↔ Maxime Tourrette | Échange | 2026-04-24/29 |
-| recap_session_LIM-72_13-05-2026.md | Récap session | 2026-05-13 |
+| recap_session_LIM-72_13-05-2026.md | Récap session | 2026-05-13 |