lint(standard): corrections completes mode standard

- Em dashes: 1712 remplaces par tirets simples (86 fichiers + _index.md, en-tete section Limagrain conserve) - Checklists: 24 '- [ ]' -> '- ☐' (3 pages operations, plus de todos Obsidian) - Ancres: 33 reparees (slugs GitHub + ancres HTML <a id> reconnues), 1 reciblee (manuel de reten) - related: tenseflow -> tense-flow, pie -> mechanical-elements, group.md retire (doublon shipping) - Registre: compteur global 122 -> 131 pages - Rapport racine _lint_report.md mis a jour (scan v2 + re-scan final: 0 anomalie) - Aucun fichier limagrain/ modifie (cloisonnement)
lint(limagrain): corrections completes Phase 1+2
2026-07-20 13:01:21 +02:00 · 2026-07-20 12:56:42 +02:00
146 changed files with 8226 additions and 3894 deletions
@@ -1,182 +1,182 @@
-# Wiki EasyWMS — Index
+# Wiki EasyWMS - Index
-Total : 122 pages
+Total : 131 pages (85 standard + 46 Limagrain)
 ## Concepts (33 pages)
-### Batch 1 — Core Entities
+### Batch 1 - Core Entities
- [Container (LPN)](concepts/container.md) — LPN types, lifecycle statuses, locks, stacking/matching, reception, operations, transactions
+- [Container (LPN)](concepts/container.md) - LPN types, lifecycle statuses, locks, stacking/matching, reception, operations, transactions
- [Location](concepts/location.md) — Physical/virtual types (rack, compact, APS, buffer, dock), storage modes, logics, lock types, operations
+- [Location](concepts/location.md) - Physical/virtual types (rack, compact, APS, buffer, dock), storage modes, logics, lock types, operations
- [Product / Item](concepts/product-item.md) — SKU master, UoM, logistic attributes (lot, expiry, serial), profiles (reception/putaway/shipping), types, families, labels, lifecycle management
+- [Product / Item](concepts/product-item.md) - SKU master, UoM, logistic attributes (lot, expiry, serial), profiles (reception/putaway/shipping), types, families, labels, lifecycle management
- [Kits](concepts/kits.md) — Kit types (without/with assembly), assembly/disassembly lifecycle, WOR/WOF/KST/UNK ERP messages, quartering, traceability
+- [Kits](concepts/kits.md) - Kit types (without/with assembly), assembly/disassembly lifecycle, WOR/WOF/KST/UNK ERP messages, quartering, traceability
- [Stock](concepts/stock.md) — Stock records, status (user/receiving/system), adjustments (quantity/UoM/logistic attributes), grouped reports
+- [Stock](concepts/stock.md) - Stock records, status (user/receiving/system), adjustments (quantity/UoM/logistic attributes), grouped reports
- [Stock Assignment](concepts/stock-assignment.md) — `StockAssignProcess_*` engine that binds stock to outbound lines ; pipeline (fetch/lock → search → strategy → create tasks), assignment types (PickingLocations / Replenishment / ShippingContainer / PickingContainer), kit + crossdocking + alternatives behaviour, customisation points
+- [Stock Assignment](concepts/stock-assignment.md) - `StockAssignProcess_*` engine that binds stock to outbound lines ; pipeline (fetch/lock → search → strategy → create tasks), assignment types (PickingLocations / Replenishment / ShippingContainer / PickingContainer), kit + crossdocking + alternatives behaviour, customisation points
- [Weights](concepts/weights.md) — Five container-level weight fields (Calculated / Scale / Theoretical / Real / Theoretical Scale), formulas, PIE behaviour, variable-weight items, `Stock_CheckWeightToCreateStockInContainer_UI`, StockAdjust limits
+- [Weights](concepts/weights.md) - Five container-level weight fields (Calculated / Scale / Theoretical / Real / Theoretical Scale), formulas, PIE behaviour, variable-weight items, `Stock_CheckWeightToCreateStockInContainer_UI`, StockAdjust limits
- [Task](concepts/task.md) — Task and process types (putaway/picking/shipping/replenishment/count/movement), lifecycle, movements, semi-automatic mode
+- [Task](concepts/task.md) - Task and process types (putaway/picking/shipping/replenishment/count/movement), lifecycle, movements, semi-automatic mode
- [Inbound Order](concepts/order-inbound.md) — Receipt orders (supplier/return/transfer), lifecycle, ERP messages (ROR/ASN/ROC/ROF/ASO/STR)
+- [Inbound Order](concepts/order-inbound.md) - Receipt orders (supplier/return/transfer), lifecycle, ERP messages (ROR/ASN/ROC/ROF/ASO/STR)
- [Outbound Order](concepts/order-outbound.md) — Shipping orders (client/return/transfer), lifecycle, stock assignment, ERP messages (SOR/SOC/SOF/LOF)
+- [Outbound Order](concepts/order-outbound.md) - Shipping orders (client/return/transfer), lifecycle, stock assignment, ERP messages (SOR/SOC/SOF/LOF)
- [Account / Owner](concepts/account-owner.md) — Owner (stock ownership, 3PL client) vs. Account (delivery point); mixing rules; OWN/ACC ERP messages
+- [Account / Owner](concepts/account-owner.md) - Owner (stock ownership, 3PL client) vs. Account (delivery point); mixing rules; OWN/ACC ERP messages
- [Supplier](concepts/supplier.md) — Supplier master data, attributes, use cases (receipts/returns), SUP ERP message
+- [Supplier](concepts/supplier.md) - Supplier master data, attributes, use cases (receipts/returns), SUP ERP message
- [Carrier](concepts/carrier.md) — Base carrier + Extended carrier (Multi-Carrier module); delivery entity, tracking, packaging modes, CAR ERP message
+- [Carrier](concepts/carrier.md) - Base carrier + Extended carrier (Multi-Carrier module); delivery entity, tracking, packaging modes, CAR ERP message
-### Batch 2 — Core Flows
+### Batch 2 - Core Flows
- [Reception](concepts/reception.md) — Receipt document structure, reception modes (dock, ASN, PIE, PK, returns), closing, ERP messages
+- [Reception](concepts/reception.md) - Receipt document structure, reception modes (dock, ASN, PIE, PK, returns), closing, ERP messages
- [Putaway](concepts/putaway.md) — Strategy engine pipeline, channel filling, aisle balancing, restrictions, sorting preferences, automatic station triggers
+- [Putaway](concepts/putaway.md) - Strategy engine pipeline, channel filling, aisle balancing, restrictions, sorting preferences, automatic station triggers
- [Picking](concepts/picking.md) — Stock assignment strategies, manual warehouse modes (automatic tasks, waves, PTL, voice, paper), automatic warehouse (direct, grouped, negative picking), Pick and Pack
+- [Picking](concepts/picking.md) - Stock assignment strategies, manual warehouse modes (automatic tasks, waves, PTL, voice, paper), automatic warehouse (direct, grouped, negative picking), Pick and Pack
- [Shipping](concepts/shipping.md) — Shipping order lifecycle, release, waves/groups/fusions, prepackaging, consolidation, routes, loads, truck loading, PS groups
+- [Shipping](concepts/shipping.md) - Shipping order lifecycle, release, waves/groups/fusions, prepackaging, consolidation, routes, loads, truck loading, PS groups
- [Replenishment](concepts/replenishment.md) — PDL management, strategy types (top-off, shipping demand, stockout, sub-warehouse), efficiency modes, dynamic replenishment, automatic job
+- [Replenishment](concepts/replenishment.md) - PDL management, strategy types (top-off, shipping demand, stockout, sub-warehouse), efficiency modes, dynamic replenishment, automatic job
- [Crossdocking](concepts/crossdocking.md) — Opportunity crossdocking (direct to dock), crossdocking to warehouse (dedicated XD locations, IS crossdocking strategies)
+- [Crossdocking](concepts/crossdocking.md) - Opportunity crossdocking (direct to dock), crossdocking to warehouse (dedicated XD locations, IS crossdocking strategies)
-### Batch 3 — Inventory Operations
+### Batch 3 - Inventory Operations
- [Count / Inventory](concepts/count.md) — Guided counts (location/item/container), physical count (RF), cycle count (rolling schedule), workstation count (automatic warehouse), ERP messages (COR/COF/SCR/WSC)
+- [Count / Inventory](concepts/count.md) - Guided counts (location/item/container), physical count (RF), cycle count (rolling schedule), workstation count (automatic warehouse), ERP messages (COR/COF/SCR/WSC)
- [Stock Adjustment](concepts/stock-adjustment.md) — Quantity/UoM/logistic attribute adjustments, adjustment reasons, double validation (pending/confirmed/canceled), RF/SmartUI/Workstation interfaces
+- [Stock Adjustment](concepts/stock-adjustment.md) - Quantity/UoM/logistic attribute adjustments, adjustment reasons, double validation (pending/confirmed/canceled), RF/SmartUI/Workstation interfaces
- [Consolidation](concepts/consolidation.md) — Container stock consolidation process: process→orders→tasks, filtering criteria, automatic warehouse (PK 2-loc, manual MP, buffer), configuration requirements
+- [Consolidation](concepts/consolidation.md) - Container stock consolidation process: process→orders→tasks, filtering criteria, automatic warehouse (PK 2-loc, manual MP, buffer), configuration requirements
- [Defragmentation](concepts/defragmentation.md) — Automatic warehouse only: rotation optimization (ABC class → storage zone), shipping optimization (pre-position for dispatch), planners, MAX_DEFRAG_TASKS
+- [Defragmentation](concepts/defragmentation.md) - Automatic warehouse only: rotation optimization (ABC class → storage zone), shipping optimization (pre-position for dispatch), planners, MAX_DEFRAG_TASKS
- [Quality Control](concepts/quality-control.md) — Stock lock/unlock system: receiving status vs user status, lock from web/RF/ERP, automatic time-based unlock, cutting stock locks, STC/STR messages
+- [Quality Control](concepts/quality-control.md) - Stock lock/unlock system: receiving status vs user status, lock from web/RF/ERP, automatic time-based unlock, cutting stock locks, STC/STR messages
- [Manual Movements](concepts/manual-movements.md) — Corrective stock/container relocations: 8 move types (location↔location, location↔container, container↔container, divisions, container move, cutting stock, partitions)
+- [Manual Movements](concepts/manual-movements.md) - Corrective stock/container relocations: 8 move types (location↔location, location↔container, container↔container, divisions, container move, cutting stock, partitions)
-### Batch 4 — Layout & Configuration
+### Batch 4 - Layout & Configuration
- [Stations & Routes](concepts/stations.md) — All 37+ station types (ALM/PIE/PK/PS/ME/MS/MU/ET/Dock/Stage/Cutting/Decision/Workzone/…), routes, managers, incidences, dock/stage configuration
+- [Stations & Routes](concepts/stations.md) - All 37+ station types (ALM/PIE/PK/PS/ME/MS/MU/ET/Dock/Stage/Cutting/Decision/Workzone/…), routes, managers, incidences, dock/stage configuration
- [Warehouse Designer](concepts/warehouse-designer.md) — Web Configurator (container types, rack types, zones, sub-warehouses, equipment, shelves, docks, stages, change log, transfer history), Warehouse Map (3D/2D, heat map)
+- [Warehouse Designer](concepts/warehouse-designer.md) - Web Configurator (container types, rack types, zones, sub-warehouses, equipment, shelves, docks, stages, change log, transfer history), Warehouse Map (3D/2D, heat map)
- [Parameters](concepts/parameters.md) — All system parameters: Easy WMS core + Slotting + eCommerce + AGV/PS + APS3D + Multi-Carrier Shipping modules; cross-reference table by topic
+- [Parameters](concepts/parameters.md) - All system parameters: Easy WMS core + Slotting + eCommerce + AGV/PS + APS3D + Multi-Carrier Shipping modules; cross-reference table by topic
- [Cutting Stock](concepts/cutting-stock.md) — Non-consolidating UoM, cutting profiles, shelf/station picking (integrated/delegated), stock assignment strategies (continuous/segmented/minimum), reception, counting, labels
+- [Cutting Stock](concepts/cutting-stock.md) - Non-consolidating UoM, cutting profiles, shelf/station picking (integrated/delegated), stock assignment strategies (continuous/segmented/minimum), reception, counting, labels
- [Labels & Printing](concepts/labels.md) — Container labels (SSCC/GS1-128), item labels (Code128/GS1-128), cutting stock labels (A6), client container labels, RF label printing, multi-reading, auto-print triggers
+- [Labels & Printing](concepts/labels.md) - Container labels (SSCC/GS1-128), item labels (Code128/GS1-128), cutting stock labels (A6), client container labels, RF label printing, multi-reading, auto-print triggers
-### Batch 10 — Fonctionnelles Mecalux France
+### Batch 10 - Fonctionnelles Mecalux France
- [Prepackaging (Préemballage / Précolisage)](concepts/prepackaging.md) — Strategy configuration at shipping order type level; `SOR02 <PrpPackagingConfiguration>` block; comparison with VAS; tested behaviour table; common errors
+- [Prepackaging (Préemballage / Précolisage)](concepts/prepackaging.md) - Strategy configuration at shipping order type level; `SOR02 <PrpPackagingConfiguration>` block; comparison with VAS; tested behaviour table; common errors
- [Tense Flow (Flux Tendu)](concepts/tense-flow.md) — EasyS zone configuration; 4-step functional flow (launch → execution → virtual picking → end); distinction from opportunity crossdocking; common errors
+- [Tense Flow (Flux Tendu)](concepts/tense-flow.md) - EasyS zone configuration; 4-step functional flow (launch → execution → virtual picking → end); distinction from opportunity crossdocking; common errors
-### Batch 12 — Robotics & GALILEO (Concepts)
+### Batch 12 - Robotics & GALILEO (Concepts)
- [Mechanical Elements (Acronymes & Codes)](concepts/mechanical-elements.md) — ES→EN acronym table (~30 elements : AP/APC/APR/APS/ATC/CT/ECDF/EMS/EP/LBC/LRA/LRC/LRD/LRI/LRL/LTM/LZ/ML/MLB/MT/MTB/PSS/PTL/SGA/STL/STP/TC/TG/TM/TR), FR/ES/EN station code matrix (24 rows), conveyor tracking behaviour, miniload nomenclature (ML/MLB/EPSF/EPDF/ECDF)
+- [Mechanical Elements (Acronymes & Codes)](concepts/mechanical-elements.md) - ES→EN acronym table (~30 elements : AP/APC/APR/APS/ATC/CT/ECDF/EMS/EP/LBC/LRA/LRC/LRD/LRI/LRL/LTM/LZ/ML/MLB/MT/MTB/PSS/PTL/SGA/STL/STP/TC/TG/TM/TR), FR/ES/EN station code matrix (24 rows), conveyor tracking behaviour, miniload nomenclature (ML/MLB/EPSF/EPDF/ECDF)
 ## Modules (24 pages)
-### Batch 5 — Modules
+### Batch 5 - Modules
- [AGV](modules/agv.md) — Automated Guided Vehicles: 4-component architecture (WMS→Gateway→PostgreSQL→fleet manager), 5 exchange tables, communication protocol (phases 00/03/04/06/08/10/255), fleet manager integration (standard SQL + REST/middleware pattern), error categories, RFT fallback, lock types, prerequisites
+- [AGV](modules/agv.md) - Automated Guided Vehicles: 4-component architecture (WMS→Gateway→PostgreSQL→fleet manager), 5 exchange tables, communication protocol (phases 00/03/04/06/08/10/255), fleet manager integration (standard SQL + REST/middleware pattern), error categories, RFT fallback, lock types, prerequisites
- [Pallet Shuttle](modules/pallet-shuttle.md) — WIFI-controlled compact channel cart: PSService, simple/multi modes, LIFO/FIFO, deposit/extraction/compaction, AGV-PS search, battery management
+- [Pallet Shuttle](modules/pallet-shuttle.md) - WIFI-controlled compact channel cart: PSService, simple/multi modes, LIFO/FIFO, deposit/extraction/compaction, AGV-PS search, battery management
- [Multi-Carrier Shipping](modules/multi-carrier.md) — Delivery entity (carrier+consignee), 18 supported carriers (DHL/UPS/TNT/GLS/Colissimo/…), packing methods (scan all/choose count/always 1), carrier label printing, tracking numbers, delivery status lifecycle, automatic carrier selection
+- [Multi-Carrier Shipping](modules/multi-carrier.md) - Delivery entity (carrier+consignee), 18 supported carriers (DHL/UPS/TNT/GLS/Colissimo/…), packing methods (scan all/choose count/always 1), carrier label printing, tracking numbers, delivery status lifecycle, automatic carrier selection
- [eCommerce](modules/ecommerce.md) — JIT reception flow: single-unit→packing, multi-unit→ungrouping, no-order→storage; 4 key parameters
+- [eCommerce](modules/ecommerce.md) - JIT reception flow: single-unit→packing, multi-unit→ungrouping, no-order→storage; 4 key parameters
- [Marketplaces](modules/marketplaces.md) — Prestashop/eBay/Amazon connectors; Amazon SaaS requirement; OUT.CREATE transaction
+- [Marketplaces](modules/marketplaces.md) - Prestashop/eBay/Amazon connectors; Amazon SaaS requirement; OUT.CREATE transaction
- [Slotting](modules/slotting.md) — Item rotation analysis (historical/current/external), golden zone, PDL-based recommendations, daily profit calculation, 7+ parameters
+- [Slotting](modules/slotting.md) - Item rotation analysis (historical/current/external), golden zone, PDL-based recommendations, daily profit calculation, 7+ parameters
- [Labor Management](modules/labor-management.md) — Process→Activity→Work→Work Detail hierarchy; target time from layout+equipment; 16 measured processes; per-warehouse config
+- [Labor Management](modules/labor-management.md) - Process→Activity→Work→Work Detail hierarchy; target time from layout+equipment; 16 measured processes; per-warehouse config
- [3PL Billing](modules/billing-3pl.md) — Contract→Rule→Planner hierarchy; 3 rule groups (Storage/Handling/Transaction); tiered pricing; pre-validation; 6 notification events; Owner Extensions prerequisite
+- [3PL Billing](modules/billing-3pl.md) - Contract→Rule→Planner hierarchy; 3 rule groups (Storage/Handling/Transaction); tiered pricing; pre-validation; 6 notification events; Owner Extensions prerequisite
- [3PL Portal](modules/3pl-portal.md) — Owner-filtered access for external 3PL clients; notification setup; KPI visibility; requires Owner Extensions
+- [3PL Portal](modules/3pl-portal.md) - Owner-filtered access for external 3PL clients; notification setup; KPI visibility; requires Owner Extensions
- [Yard Management](modules/yard-management.md) — Appointment lifecycle (Pending→Finished); checkpoints, parking lots, dock assignment, ERP/TMS integration
+- [Yard Management](modules/yard-management.md) - Appointment lifecycle (Pending→Finished); checkpoints, parking lots, dock assignment, ERP/TMS integration
- [VAS](modules/vas.md) — Template→Activity→Instructions hierarchy; VAS profiles; ERP SOR VASCode field; shipping and packing station integration
+- [VAS](modules/vas.md) - Template→Activity→Instructions hierarchy; VAS profiles; ERP SOR VASCode field; shipping and packing station integration
- [Manufacturing](modules/manufacturing.md) — RCP01/RCP02 recipes, MOR01 production orders; MOF/FGP ERP messages; supply/production buffers; auto/manual consumption modes; additives; rebuts; NegativeStock
+- [Manufacturing](modules/manufacturing.md) - RCP01/RCP02 recipes, MOR01 production orders; MOF/FGP ERP messages; supply/production buffers; auto/manual consumption modes; additives; rebuts; NegativeStock
- [Store Fulfillment](modules/store-fulfillment.md) — Star topology (central warehouse → remote stores); TPV01 real-time POS sales; TOR01/TOF01 transfer orders; min/max replenishment; no desk stations
+- [Store Fulfillment](modules/store-fulfillment.md) - Star topology (central warehouse → remote stores); TPV01 real-time POS sales; TOR01/TOF01 transfer orders; min/max replenishment; no desk stations
- [Supply Chain Event Management](modules/supply-chain-event.md) — Event subscription system; multi-channel (web/email/SMS); GNA notification; escalation; 3PL client subscriptions
+- [Supply Chain Event Management](modules/supply-chain-event.md) - Event subscription system; multi-channel (web/email/SMS); GNA notification; escalation; 3PL client subscriptions
- [Movirack](modules/movirack.md) — Mobile racking on motorized bases; aisle opening modes (with task/without task/manual/multi-aisle); 5 work modes
+- [Movirack](modules/movirack.md) - Mobile racking on motorized bases; aisle opening modes (with task/without task/manual/multi-aisle); 5 work modes
- [Cobot](modules/cobot.md) — Collaborative robot picking arm; suction cup tools; HPKS-R integration; always paired with manual station
+- [Cobot](modules/cobot.md) - Collaborative robot picking arm; suction cup tools; HPKS-R integration; always paired with manual station
- [APS3D](modules/aps3d.md) — 3D automated shuttle system; Fleet Manager controller; APS/APSFIFO locations; lifts; defragmentation modes
+- [APS3D](modules/aps3d.md) - 3D automated shuttle system; Fleet Manager controller; APS/APSFIFO locations; lifts; defragmentation modes
- [Data Analytics](modules/data-analytics.md) — Metric groups (consolidated/real-time) → Widgets → Dashboards; standard dashboards for WMS/LMS/APS3D; alarms
+- [Data Analytics](modules/data-analytics.md) - Metric groups (consolidated/real-time) → Widgets → Dashboards; standard dashboards for WMS/LMS/APS3D; alarms
- [Automation Dashboard](modules/automation-dashboard.md) — Machine fault and manual action tracking for automatic warehouse equipment; fault reports; availability metrics
+- [Automation Dashboard](modules/automation-dashboard.md) - Machine fault and manual action tracking for automatic warehouse equipment; fault reports; availability metrics
- [DOM (Distributed Order Management)](modules/dom.md) — Multi-node orchestration: 5-stage engine (region→carrier→stock→capacity→strategies); purchase/sales/replenishment orders; ERP messaging
+- [DOM (Distributed Order Management)](modules/dom.md) - Multi-node orchestration: 5-stage engine (region→carrier→stock→capacity→strategies); purchase/sales/replenishment orders; ERP messaging
- [Faults Management](modules/faults-management.md) — Backend of Automation Dashboard: fault records, manual action logs, availability reports (see automation-dashboard)
+- [Faults Management](modules/faults-management.md) - Backend of Automation Dashboard: fault records, manual action logs, availability reports (see automation-dashboard)
- [Directives](modules/directives.md) — Owner directives (workflow, documents) and account directives (container type, weight/height, shelf life, lot count, shipping logic)
+- [Directives](modules/directives.md) - Owner directives (workflow, documents) and account directives (container type, weight/height, shelf life, lot count, shipping logic)
- [Owner Extensions](modules/owner-extensions.md) — Prerequisite for Billing + 3PL Portal; adds mandatory owner to orders and 8 master data types
+- [Owner Extensions](modules/owner-extensions.md) - Prerequisite for Billing + 3PL Portal; adds mandatory owner to orders and 8 master data types
- [Client-Specific Rules](modules/client-specific-rules.md) — Source unavailable (404); concept maps to Directives module
+- [Client-Specific Rules](modules/client-specific-rules.md) - Source unavailable (404); concept maps to Directives module
 ## Architecture (6 pages)
-### Batch 6 — Architecture & Integration
+### Batch 6 - Architecture & Integration
- [System Architecture Overview](architecture/overview.md) — IIS/ASP.NET Core stack, SaaS vs on-premise, API families (AD/QueryExecute/CommandExecute/ERP), background jobs, warehouse types, hardware
+- [System Architecture Overview](architecture/overview.md) - IIS/ASP.NET Core stack, SaaS vs on-premise, API families (AD/QueryExecute/CommandExecute/ERP), background jobs, warehouse types, hardware
- [Security](architecture/security.md) — Role hierarchy (SuperAdmin→Operator→3PL Client), authentication, authorization, owner isolation, station roles, container locks, audit trail
+- [Security](architecture/security.md) - Role hierarchy (SuperAdmin→Operator→3PL Client), authentication, authorization, owner isolation, station roles, container locks, audit trail
- [Application Dictionary](architecture/application-dictionary.md) — AD element types: Commands (operations), Queries (LINQ), Entities (data model), Views (projections), Dialogs (multi-step flows), Events (triggers), Workflows (orchestration), Background Jobs, Parameters; naming conventions; extension points
+- [Application Dictionary](architecture/application-dictionary.md) - AD element types: Commands (operations), Queries (LINQ), Entities (data model), Views (projections), Dialogs (multi-step flows), Events (triggers), Workflows (orchestration), Background Jobs, Parameters; naming conventions; extension points
- [Entities Relationship Map](architecture/entities-map.md) — Complete entity model: Container→Location→Stock chain, order-to-task fulfillment chain, all entity attributes, module extensions (AGV/Multi-Carrier/3PL/DOM), referential constraints, transaction-entity mapping, ERP integration touch points per entity
+- [Entities Relationship Map](architecture/entities-map.md) - Complete entity model: Container→Location→Stock chain, order-to-task fulfillment chain, all entity attributes, module extensions (AGV/Multi-Carrier/3PL/DOM), referential constraints, transaction-entity mapping, ERP integration touch points per entity
- [RF Terminal Menu Map](architecture/rf-menu.md) — Full mapping of the 12 RFT menus (Tasks / Receptions / Putaway / Shipping orders / Replenishment / Counts / Kits / Quality / Groups / Utilities / Pick-and-Pass / Packaging) to their entry workflows ; `RFMenu_*` / `SharedMenu_*` codes for rights and customisation
+- [RF Terminal Menu Map](architecture/rf-menu.md) - Full mapping of the 12 RFT menus (Tasks / Receptions / Putaway / Shipping orders / Replenishment / Counts / Kits / Quality / Groups / Utilities / Pick-and-Pass / Packaging) to their entry workflows ; `RFMenu_*` / `SharedMenu_*` codes for rights and customisation
-### Batch 12 — Robotics & GALILEO (Architecture)
+### Batch 12 - Robotics & GALILEO (Architecture)
- [GALILEO Integration](architecture/galileo-integration.md) — WMS ↔ GALILEO/EasyS protocol via EasyWMS Gateway (TCP 3000); three message types (Event / Search / End); station & route update streams; station capacity semantics (PK/PS per-route vs miniload TK per-station); handler workflows (`Galileo_PIEEventHandler_PR`, `Galileo_SearchCreatedEventHandler_PR`, `Galileo_EndCreatedEventHandler_PR`); `GalileoMovTrackingCreateCommand`; virtual location `Mov`; SCADA vs GALILEO vs WMS layering
+- [GALILEO Integration](architecture/galileo-integration.md) - WMS ↔ GALILEO/EasyS protocol via EasyWMS Gateway (TCP 3000); three message types (Event / Search / End); station & route update streams; station capacity semantics (PK/PS per-route vs miniload TK per-station); handler workflows (`Galileo_PIEEventHandler_PR`, `Galileo_SearchCreatedEventHandler_PR`, `Galileo_EndCreatedEventHandler_PR`); `GalileoMovTrackingCreateCommand`; virtual location `Mov`; SCADA vs GALILEO vs WMS layering
-## Concepts — Integration (Batch 6 additions)
+## Concepts - Integration (Batch 6 additions)
- [ERP Interface](concepts/erp-interface.md) — Complete ERP message catalog: Masters (ITM/ITC/OWN/CAR/ACC/SUP/KIT), Inbound (ROR/ASN/SRN/ROC/ROF/REF/ASO/ASK/SRO/SRK), Outbound (SOR/SOC/SOF/LOF/WOR/WOF/RUT), Counts (COR/COF), Requests (STR/SCR/CMC), Notifications (STV/STC/WSC/KST/UNK/COS/COC), post-processing pipeline
+- [ERP Interface](concepts/erp-interface.md) - Complete ERP message catalog: Masters (ITM/ITC/OWN/CAR/ACC/SUP/KIT), Inbound (ROR/ASN/SRN/ROC/ROF/REF/ASO/ASK/SRO/SRK), Outbound (SOR/SOC/SOF/LOF/WOR/WOF/RUT), Counts (COR/COF), Requests (STR/SCR/CMC), Notifications (STV/STC/WSC/KST/UNK/COS/COC), post-processing pipeline
- [Transactions & Notification Events](concepts/transactions.md) — All 60+ transaction type codes (CON.*/STK.*/INO.*/OUT.*/COU.*/TSK.*/etc.), post-processing flags, ERP message triggers; 25+ SCEM notification events with severity and subscription scope
+- [Transactions & Notification Events](concepts/transactions.md) - All 60+ transaction type codes (CON.*/STK.*/INO.*/OUT.*/COU.*/TSK.*/etc.), post-processing flags, ERP message triggers; 25+ SCEM notification events with severity and subscription scope
 ## Operations (20 pages)
-### Batch 7 — Operations & Finition
+### Batch 7 - Operations & Finition
- [Troubleshooting Guide](operations/troubleshooting.md) — All common errors organized by symptom category (inbound, putaway, stock, picking, shipping, replenishment, count, quality, tasks/automation, ERP integration, system, master data)
+- [Troubleshooting Guide](operations/troubleshooting.md) - All common errors organized by symptom category (inbound, putaway, stock, picking, shipping, replenishment, count, quality, tasks/automation, ERP integration, system, master data)
- [Configuration Guide](operations/configuration-guide.md) — Deployment configuration guide in dependency order: infrastructure, EasyS layout, master data, reception, putaway, picking, replenishment, count, crossdocking, quality control, ERP integration, module-specific config, security
+- [Configuration Guide](operations/configuration-guide.md) - Deployment configuration guide in dependency order: infrastructure, EasyS layout, master data, reception, putaway, picking, replenishment, count, crossdocking, quality control, ERP integration, module-specific config, security
- [Development Methodology (Custom Apps)](operations/development-methodology.md) — Méthode de développement Mecalux France pour custom apps : stratégie de branches GIT (master/développement/post-production), phases dev/test/post-prod, manuel de reten en Markdown, redéploiement custom app
+- [Development Methodology (Custom Apps)](operations/development-methodology.md) - Méthode de développement Mecalux France pour custom apps : stratégie de branches GIT (master/développement/post-production), phases dev/test/post-prod, manuel de reten en Markdown, redéploiement custom app
-### Batch 8 — Deployment Workflow (Mecalux France)
+### Batch 8 - Deployment Workflow (Mecalux France)
- [VM Installation (Hyper-V) & Validation](operations/vm-installation.md) — Création VM Hyper-V depuis template (`TEMPLATE_INTEGRATION_[DB]`), config réseau (InternoNAT/VMs, DNS Mecalux), renommage + Oracle tnsnames/listener, point de contrôle "Deploy 0", validation (MongoDB/IIS/SmartUI/consoleRF)
+- [VM Installation (Hyper-V) & Validation](operations/vm-installation.md) - Création VM Hyper-V depuis template (`TEMPLATE_INTEGRATION_[DB]`), config réseau (InternoNAT/VMs, DNS Mecalux), renommage + Oracle tnsnames/listener, point de contrôle "Deploy 0", validation (MongoDB/IIS/SmartUI/consoleRF)
- [First Deployment (New Project)](operations/first-deployment.md) — Initialisation d'un projet neuf : `DeployConfig.yaml` (TenantName/DBEngine/MAPSeed/License/Warehouse/Data/StandardApplications/EnabledModules/Customs/Users), `deploy_repository.ps1`, Tenants.xml → InMemory (obligatoire), création initiale custom app, ToggleService pour versions 24.xx
+- [First Deployment (New Project)](operations/first-deployment.md) - Initialisation d'un projet neuf : `DeployConfig.yaml` (TenantName/DBEngine/MAPSeed/License/Warehouse/Data/StandardApplications/EnabledModules/Customs/Users), `deploy_repository.ps1`, Tenants.xml → InMemory (obligatoire), création initiale custom app, ToggleService pour versions 24.xx
- [Deploy Existing Application](operations/deployment-existing-app.md) — Redéploiement d'un projet déjà initialisé (nouveau dev, changement de branche, mise à jour) ; script unifié `deploy_repository.ps1 <Projet> [Branche]` ; étape Tenants.xml InMemory obligatoire à chaque déploiement
+- [Deploy Existing Application](operations/deployment-existing-app.md) - Redéploiement d'un projet déjà initialisé (nouveau dev, changement de branche, mise à jour) ; script unifié `deploy_repository.ps1 <Projet> [Branche]` ; étape Tenants.xml InMemory obligatoire à chaque déploiement
- [Deploy Specific Commit](operations/deployment-specific-commit.md) — Figer un commit via tag GIT (convention `<PREFIXE_JIRA>-V<N>`) + branche dédiée, déploiement par `deploy_repository.ps1 <Projet> <Branche>` ; utile pour reproduction de bugs, démos stables, tests de régression
+- [Deploy Specific Commit](operations/deployment-specific-commit.md) - Figer un commit via tag GIT (convention `<PREFIXE_JIRA>-V<N>`) + branche dédiée, déploiement par `deploy_repository.ps1 <Projet> <Branche>` ; utile pour reproduction de bugs, démos stables, tests de régression
- [Custom Application Management](operations/custom-application-management.md) — EasyBuilder : création (depuis FRANCE_OPERATIONS_TOOLS ou vierge avec dépendance EasyWMS), import (`Import and save application from text`), export (`Export application to text`) ; règles de coexistence multi-devs ; Check-out bloque l'export
+- [Custom Application Management](operations/custom-application-management.md) - EasyBuilder : création (depuis FRANCE_OPERATIONS_TOOLS ou vierge avec dépendance EasyWMS), import (`Import and save application from text`), export (`Export application to text`) ; règles de coexistence multi-devs ; Check-out bloque l'export
- [Git Workflow (Git Flow)](operations/git-workflow.md) — Procédure opérationnelle Git Flow (CLI + SourceTree) : `git flow init`, `git flow feature start/finish -r`, gestion des conflits de rebase, commit/push quotidien obligatoire ; couvre les pré-requis d'export (custom app + uGNA + GNA) avant commit
+- [Git Workflow (Git Flow)](operations/git-workflow.md) - Procédure opérationnelle Git Flow (CLI + SourceTree) : `git flow init`, `git flow feature start/finish -r`, gestion des conflits de rebase, commit/push quotidien obligatoire ; couvre les pré-requis d'export (custom app + uGNA + GNA) avant commit
- [GNA, Services & License Installation](operations/gna-services-license.md) — Sauvegarde GIT de la config GNA (`GNAGetDataForGit.ps1`, dossier `\services\GNA`, composition XSD multi-modules), réinstallation GNA (DeployCommsApps.ps1 "complete"), Label Printer (lien Confluence), licence WMS (demande + import via `EasySTS/License`) pour dépasser les 7 jours par défaut
+- [GNA, Services & License Installation](operations/gna-services-license.md) - Sauvegarde GIT de la config GNA (`GNAGetDataForGit.ps1`, dossier `\services\GNA`, composition XSD multi-modules), réinstallation GNA (DeployCommsApps.ps1 "complete"), Label Printer (lien Confluence), licence WMS (demande + import via `EasySTS/License`) pour dépasser les 7 jours par défaut
-### Batch 9 — Dev Workflow Tooling, Reviews & Project Lifecycle (Mecalux France)
+### Batch 9 - Dev Workflow Tooling, Reviews & Project Lifecycle (Mecalux France)
- [SSH Keys Setup (MSSCODE & Sourcetree)](operations/ssh-keys-setup.md) — Génération clé SSH ed25519 (`ssh-keygen` dans Git Bash), enregistrement sur MSSCODE avec vérification renforcée (signature SSH), configuration de Sourcetree (OpenSSH + clé privée), clonage SSH obligatoire
+- [SSH Keys Setup (MSSCODE & Sourcetree)](operations/ssh-keys-setup.md) - Génération clé SSH ed25519 (`ssh-keygen` dans Git Bash), enregistrement sur MSSCODE avec vérification renforcée (signature SSH), configuration de Sourcetree (OpenSSH + clé privée), clonage SSH obligatoire
- [VM Network Routing (NAT, Localhost, IP, VPN)](operations/vm-network-routing.md) — Tableau NAT Hyper-V (HTTP/HTTPS/RDP/Oracle/SMB ports externes vs internes VM), accès local via `localhost`, accès distant via IP du PC hôte, passerelles VPN Mecalux Europe / Europe 4, conflit ZAPP/Zscaler
+- [VM Network Routing (NAT, Localhost, IP, VPN)](operations/vm-network-routing.md) - Tableau NAT Hyper-V (HTTP/HTTPS/RDP/Oracle/SMB ports externes vs internes VM), accès local via `localhost`, accès distant via IP du PC hôte, passerelles VPN Mecalux Europe / Europe 4, conflit ZAPP/Zscaler
- [uGNA Data Export (WMS Configuration → Git)](operations/ugna-data-export.md) — Export config WMS (41 entités : owner/account/parameter/profils/strategies/stations/locks/etc.) via `uGNAConsole.exe -Z:` depuis CMD admin, dépose des XML dans `..\test` du Git, erreur droits + correction
+- [uGNA Data Export (WMS Configuration → Git)](operations/ugna-data-export.md) - Export config WMS (41 entités : owner/account/parameter/profils/strategies/stations/locks/etc.) via `uGNAConsole.exe -Z:` depuis CMD admin, dépose des XML dans `..\test` du Git, erreur droits + correction
- [Git Branch Lifecycle (Project Phases)](operations/git-branch-lifecycle.md) — Gouvernance Git par phase de projet et par acteur (Dev / CdP / Support / TMA) : développement initial (feature), avant MEP (merge `develop`→`master` + suppression `develop`), Hypercare, refus TLM si `develop` existe, branches `hotfix` Support, branches `release` TMA, communication bi-directionnelle Support↔TMA
+- [Git Branch Lifecycle (Project Phases)](operations/git-branch-lifecycle.md) - Gouvernance Git par phase de projet et par acteur (Dev / CdP / Support / TMA) : développement initial (feature), avant MEP (merge `develop`→`master` + suppression `develop`), Hypercare, refus TLM si `develop` existe, branches `hotfix` Support, branches `release` TMA, communication bi-directionnelle Support↔TMA
- [Deploy Test Application (Tag → Test VM)](operations/deploy-test-application.md) — Procédure 7 étapes : création tag `<TRIGRAMME>-V<N>` sur `develop`, checkpoint "Deploy 0" sur VM de test, redéploiement via `deploy_repository.ps1`, réinstallation GNA, printer service + licence, validation VM, transition Jira "Prêt à tester" avec tag obligatoire
+- [Deploy Test Application (Tag → Test VM)](operations/deploy-test-application.md) - Procédure 7 étapes : création tag `<TRIGRAMME>-V<N>` sur `develop`, checkpoint "Deploy 0" sur VM de test, redéploiement via `deploy_repository.ps1`, réinstallation GNA, printer service + licence, validation VM, transition Jira "Prêt à tester" avec tag obligatoire
- [Code Review Process (Code, Functional, Documentation)](operations/code-review-process.md) — Trois revues avant merge : Code (OutboundLines vs OutboundOrderLines, kits sans assemblage, ProductConversion null, préfixe `CST_`, nommage viewfields/SmartUI/attributs/dialogues, `ProcessContext.EnterAction`/`EscapeAction`, `FirstOrDefault` sécurisé), Fonctionnel (cas Jira + Échap dialogues), Documentation (Jira commentée, Git, Reten Markdown)
+- [Code Review Process (Code, Functional, Documentation)](operations/code-review-process.md) - Trois revues avant merge : Code (OutboundLines vs OutboundOrderLines, kits sans assemblage, ProductConversion null, préfixe `CST_`, nommage viewfields/SmartUI/attributs/dialogues, `ProcessContext.EnterAction`/`EscapeAction`, `FirstOrDefault` sécurisé), Fonctionnel (cas Jira + Échap dialogues), Documentation (Jira commentée, Git, Reten Markdown)
-### Batch 12 — Robotics & GALILEO (Operations)
+### Batch 12 - Robotics & GALILEO (Operations)
- [GALILEO Simulation (EasyS bring-up)](operations/galileo-simulation.md) — Install EasyWMS Gateway + MainObject.config (tenantCode/TokenUser/PasswordEncrypt), firewall port 3000, EasyS warehouse/aisle/rack/PLC Types config, SmartUI stations & routes preparation, TE/TS Logical X=991, LTM routing, PK + MP-extraction + MP-reject routes, PIE event injection procedure, 3 container extraction methods, Manual Action + Liberate flow, station sync LINQ query
+- [GALILEO Simulation (EasyS bring-up)](operations/galileo-simulation.md) - Install EasyWMS Gateway + MainObject.config (tenantCode/TokenUser/PasswordEncrypt), firewall port 3000, EasyS warehouse/aisle/rack/PLC Types config, SmartUI stations & routes preparation, TE/TS Logical X=991, LTM routing, PK + MP-extraction + MP-reject routes, PIE event injection procedure, 3 container extraction methods, Manual Action + Liberate flow, station sync LINQ query
- [GALILEO Troubleshooting (Log Analysis & Fault Triage)](operations/galileo-troubleshooting.md) — Gateway log path `C:\ProgramData\Mecalux\EasyWMS Gateway 2015\Logs\AllLog.log`, station/route update fields, klogg search patterns, End error codes table (0/1/2/4/7), 4-step resolution for `EndErrorCode=4` (config mismatch), fault codes 1116/1201/1291, WMS address change pointer to Confluence, pre-escalation checklist
+- [GALILEO Troubleshooting (Log Analysis & Fault Triage)](operations/galileo-troubleshooting.md) - Gateway log path `C:\ProgramData\Mecalux\EasyWMS Gateway 2015\Logs\AllLog.log`, station/route update fields, klogg search patterns, End error codes table (0/1/2/4/7), 4-step resolution for `EndErrorCode=4` (config mismatch), fault codes 1116/1201/1291, WMS address change pointer to Confluence, pre-escalation checklist
- [Robotics Project Lifecycle](operations/robotics-project-lifecycle.md) — Stakeholders (chef de chantier, chef de projet IT, responsable électricité, responsable de projet), DTR doc, planning references, reference documentation table, station test milestone with LINQ audit query, "full" routes (CME→TE, PKE→PK, ET→PS), pre-go-live checklist
+- [Robotics Project Lifecycle](operations/robotics-project-lifecycle.md) - Stakeholders (chef de chantier, chef de projet IT, responsable électricité, responsable de projet), DTR doc, planning references, reference documentation table, station test milestone with LINQ audit query, "full" routes (CME→TE, PKE→PK, ET→PS), pre-go-live checklist
-### Batch 13 — AGV Installation
+### Batch 13 - AGV Installation
- [AGV Module — Installation Guide](operations/agv-installation.md) — Step-by-step installation of the AGV module: PostgreSQL setup, ODBC driver & System DSN (PostgreSQL35W), Gateway AGV service configuration, Oracle DBLink via dg4odbc (tnsnames.ora, listener.ora, initPostgreSQL35W.ora), synonyms on db_read, module deploy via response.xml; comprehensive troubleshooting section covering DSN case sensitivity, tnsnames indentation, listener ORACLE_HOME placeholder, PostgreSQL 18+ port change, double AGVConfig crash, Oracle case-sensitivity with double quotes
+- [AGV Module - Installation Guide](operations/agv-installation.md) - Step-by-step installation of the AGV module: PostgreSQL setup, ODBC driver & System DSN (PostgreSQL35W), Gateway AGV service configuration, Oracle DBLink via dg4odbc (tnsnames.ora, listener.ora, initPostgreSQL35W.ora), synonyms on db_read, module deploy via response.xml; comprehensive troubleshooting section covering DSN case sensitivity, tnsnames indentation, listener ORACLE_HOME placeholder, PostgreSQL 18+ port change, double AGVConfig crash, Oracle case-sensitivity with double quotes
 ## Glossary (1 page)
- [Glossary](glossary.md) — All Mecalux/EasyWMS-specific terms: product names (EasyS, SmartUI, PIE, PDL, LPN, SSCC), abbreviations (AGV, PS, APS, SCEM, DOM, LMS, VAS, 3PL, PTL), AD element names, ERP message codes (ROR/SOR/ASN/SOF/etc.), transaction prefixes (CON.*/STK.*/TSK.*/etc.), key field names
+- [Glossary](glossary.md) - All Mecalux/EasyWMS-specific terms: product names (EasyS, SmartUI, PIE, PDL, LPN, SSCC), abbreviations (AGV, PS, APS, SCEM, DOM, LMS, VAS, 3PL, PTL), AD element names, ERP message codes (ROR/SOR/ASN/SOF/etc.), transaction prefixes (CON.*/STK.*/TSK.*/etc.), key field names
-## Limagrain — Projet (41 pages)
+## Limagrain — Projet (46 pages)
-### Réception fournisseur — Production et extérieures/intersites
+### Réception fournisseur - Production et extérieures/intersites
 - **Path:** limagrain/01-inbound/reception-fournisseur.md
 - **Type:** limagrain
- Deux flux de réception distincts — production (directe ASRS via ASN) et extérieures/intersites (passage poste de travail via ROR).
+- Deux flux de réception distincts - production (directe ASRS via ASN) et extérieures/intersites (passage poste de travail via ROR).
 ### Réception retour commandes clients
 - **Path:** limagrain/01-inbound/reception-retour.md
 - **Type:** limagrain
 - Processus spécifique de réception des retours client, avec interrogation API SAP pour validation lot.
-### Contrôle qualité réception — Vérification poids PIE
+### Contrôle qualité réception - Vérification poids PIE
 - **Path:** limagrain/01-inbound/controle-qualite-reception.md
 - **Type:** limagrain
 - Mécanisme [CUSTOM] de contrôle de poids au passage PIE avec calcul de tolérance par type article et application automatique de verrous.
-### Flux ERP inbound — Messages réception
+### Flux ERP inbound - Messages réception
 - **Path:** limagrain/01-inbound/flux-erp-inbound.md
 - **Type:** limagrain
 - Catalogue des messages ERP liés aux processus de réception chez Limagrain.
-### Étiquette support RFID — Format mono-référence
+### Étiquette support RFID - Mono-référence & Multiréférence
 - **Path:** limagrain/01-inbound/etiquette-rfid.md
 - **Type:** limagrain
- Étiquette A5 imprimée en réception fournisseur/intersite : 12 champs, QR Code GS1 (5 AI), encodage RFID via ZPL.
+- Étiquette support (HU) imprimée/encodée RFID via ZPL en réception et à l'étiqueteuse auto : rapport mono-référence (A5, QR GS1) et multiréférence (SSCC seul), WF CST_PrintRFIDLabel, évolution encodage 7 bits EPC en attente.
-### Gestion des camions — Arrivée, quais et déclaration image de quai
+### Gestion des camions - Arrivée, quais et déclaration image de quai
 - **Path:** limagrain/01-inbound/gestion-camions.md
 - **Type:** limagrain
 - Flux complet depuis l'arrivée physique d'un camion jusqu'à la déclaration des palettes sur une image de quai.
-### ASRS — Entrepôt automatique Limagrain
+### ASRS - Entrepôt automatique Limagrain
 - **Path:** limagrain/02-stockage/asrs-miniload.md
 - **Type:** limagrain
 - 4 allées de transstockeurs, racks multi-profondeur, nomenclature des emplacements, types de conteneurs et dimensions.
@@ -191,17 +191,17 @@ Total : 122 pages
 - **Type:** limagrain
 - 5 stratégies de rangement distinctes selon la typologie de la palette.
-### Configuration Galileo — Limagrain
+### Configuration Galileo - Limagrain
 - **Path:** limagrain/02-stockage/galileo-config.md
 - **Type:** limagrain
 - Architecture logicielle IT de l'installation et spécificités de la configuration Galileo (TMS).
-### Processus d'anoxie — TK01
+### Processus d'anoxie - TK01
 - **Path:** limagrain/02-stockage/processus-anoxie.md
 - **Type:** limagrain
 - Processus [CUSTOM] de traitement par anoxie dans l'allée 1, incluant le flag « A anoxier », la relocalisation et le blocage d'allée.
-### Défragmentation — Zone client et ordonnancement par tournée
+### Défragmentation - Zone client et ordonnancement par tournée
 - **Path:** limagrain/02-stockage/defragmentation.md
 - **Type:** limagrain
 - Processus de défragmentation pour préparer les palettes d'expédition vers la zone client ASRS. Custom LIM-87 : défrag par tournée quand quai non assigné, éligibilité tout-ou-rien au niveau RUT, ordonnancement par STOP.
@@ -209,9 +209,14 @@ Total : 122 pages
 ### Gestion des palettes vides
 - **Path:** limagrain/02-stockage/palettes-vides.md
 - **Type:** limagrain
- Gestion des piles de palettes vides dans EasyWMS — réception, stockage, réapprovisionnement des postes et expédition.
+- Gestion des piles de palettes vides dans EasyWMS - réception, stockage, réapprovisionnement des postes et expédition.
-### Picking sur poste de travail — Expédition client
+### Flux de rejet PIE - Renvoi au poste d'origine
 - **Path:** limagrain/02-stockage/rejet-pie.md
 - **Type:** limagrain
 - Logique custom de rejet au PIE (dimension, poids, étiquette, palette bois) : le WMS calcule la destination et renvoie la palette au poste de travail d'origine (CstAtt06), pose un verrou porteur de la cause, gère la correction/ré-injection et REJ01. Paramètre PK_REJET_PROD. LIM-114.
 ### Picking sur poste de travail - Expédition client
 - **Path:** limagrain/03-picking/picking-combinatoire.md
 - **Type:** limagrain
 - Processus [CUSTOM] de picking sur poste de travail pour les commandes client, avec ordonnancement par espèce et picking négatif.
@@ -221,12 +226,12 @@ Total : 122 pages
 - **Type:** limagrain
 - Stations de l'entrepôt automatique, postes de travail polyvalents (3 îlots × 2 postes) et buffers associés.
-### Consolidation (regroupement) — Processus sur poste
+### Consolidation (regroupement) - Processus sur poste
 - **Path:** limagrain/03-picking/consolidation-regroupement.md
 - **Type:** limagrain
 - Processus [CUSTOM] de consolidation de palettes incomplètes partageant les mêmes critères de stock.
-### Mega Job — Assignation des tâches aux PK
+### Mega Job - Assignation des tâches aux PK
 - **Path:** limagrain/03-picking/job-assignation-pk.md
 - **Type:** limagrain
 - Job unique « chef d'orchestre » des tâches de mouvement vers les PK. Éligibilité, modes autorisés (MODES_PKxx), sous-workflows LIM-74/LIM-75, gestion Big-Bag.
@@ -236,7 +241,7 @@ Total : 122 pages
 - **Type:** limagrain
 - Algorithme événementiel V1.1 ordonnant les sorties ASRS : 5 critères de tri (négatif > maïs > volume > poids > palette source), contraintes amont (complétude palette pro rata Bag/pal, anti-split), écriture séquences Line.CstAtt avec ex-aequo, verrouillage OS.CstAtt, arbitrage contradictions réunion 11/05/2026.
-### Séquençage TK → PS — Historique et arbitrage
+### Séquençage TK → PS - Historique et arbitrage
 - **Path:** limagrain/03-picking/sequencage-tk-ps-historique.md
 - **Type:** limagrain
 - Historique des 4 solutions envisagées pour le séquençage. Arbitrage des contradictions entre DevOps #64854, AF §6.4.8 et réunion 11/05/2026. Changelog V1.1.
@@ -246,17 +251,27 @@ Total : 122 pages
 - **Type:** limagrain
 - Algorithme de choix de table au PK pour chaque palette arrivant au PS. 3 tables avec contrainte d'adjacence, picking négatif (2 tables), picking direct (ping-pong), buffers ES, évacuation prioritaire, palettes multi-commandes, priorité inter-PK.
-### Échantillonnage — Processus de contrôle qualité
+### Process de picking au poste de travail (PK)
 - **Path:** limagrain/03-picking/process-picking-pk.md
 - **Type:** limagrain
 - Workflow opérateur au PK (dernière étape de la chaîne picking) : picking direct/négatif, verrou HORS TOLERANCE et recomptage, étiquetage MII (SSCC virtuel sur Stock CstAtt2 + flag CstAtt14), filmage CstAtt05, évacuation ASRS, cas 100 % → shipping. Custom sur `WorkStation_Picking_Default`. En revue de code.
 ### Recertification - Workstation au poste de picking
 - **Path:** limagrain/03-picking/recertification.md
 - **Type:** limagrain
 - Process de recertification au PK (mode Tâches automatiques, LIM-105) : scan ancienne palette → nouvelle étiquette → vérification ASN (polling SAP_ATH111_*) → échange conteneur (charge quai + déplace ASN au PK) → filmage. WF `CST_Recertification_PickingStationProcess_UI`, param `RECERTIFICATION_CODE_CLASSE`.
 ### Échantillonnage - Processus de contrôle qualité
 - **Path:** limagrain/03-picking/echantillonnage.md
 - **Type:** limagrain
 - Processus [CUSTOM] d'échantillonnage pour contrôle qualité, assimilé à un inventaire, avec prélèvement sur poste de travail.
-### Flux expédition — Processus complet
+### Flux expédition - Processus complet
 - **Path:** limagrain/04-outbound/flux-expedition.md
 - **Type:** limagrain
 - Processus d'expédition de bout en bout en 12 étapes, de la réception de l'OS jusqu'à la libération du quai.
-### Ordres de sortie — Types et libération
+### Ordres de sortie - Types et libération
 - **Path:** limagrain/04-outbound/shipping-orders.md
 - **Type:** limagrain
 - 4 types d'ordres de sortie avec des comportements de libération, d'assignation et de préparation distincts.
@@ -266,32 +281,37 @@ Total : 122 pages
 - **Type:** limagrain
 - Description physique et logique des quais, poumons (images de quai) et du processus de chargement/déchargement.
-### Séquençage shipping par STOP — Quai assigné
+### Séquençage shipping par STOP - Quai assigné
 - **Path:** limagrain/04-outbound/sequencage-shipping-stop.md
 - **Type:** limagrain
 - Custom LIM-88 : quand quai déjà assigné, override WF tri stacker crane multi-TK (pattern Bardinet) pour ordonnancer la sortie ASRS par n° de STOP. Retour PF systématique vers ASRS (crossdock OFF).
-### Flux ERP outbound — Messages expédition
+### Assignation automatique de l'image de quai (OS/Tournée)
 - **Path:** limagrain/04-outbound/assignation-image-quai.md
 - **Type:** limagrain
 - Job LIM-94 `CST_AssignDockStage` (30 s) : assigne une image de quai aux OS/Routes éligibles via un stage virtuel `X_EXP`. Conditions d'éligibilité (libéré, picking revenu TK, H-3 expédition) et d'assignabilité, placement PS X max, désassignation à l'arrêt.
 ### Flux ERP outbound - Messages expédition
 - **Path:** limagrain/04-outbound/flux-erp-outbound.md
 - **Type:** limagrain
 - Catalogue des messages ERP liés aux processus d'expédition chez Limagrain.
-### Catalogue des messages ERP — Référence complète
+### Catalogue des messages ERP - Référence complète
 - **Path:** limagrain/06-erp-interface/messages-reference.md
 - **Type:** limagrain
 - Tableau de référence de tous les messages d'interface entre SAP EWM et EasyWMS, classés par domaine fonctionnel.
-### Données principales et stock — Mapping ITM et attributs
+### Données principales et stock - Mapping ITM et attributs
 - **Path:** limagrain/06-erp-interface/donnees-principales.md
 - **Type:** limagrain
 - Architecture retenue pour la gestion des articles et du stock, mapping du message ITM, attributs logistiques, profils et gestion des poids.
-### Mapping ERP-WMS — Changement article et propriétaire
+### Mapping ERP-WMS - Changement article et propriétaire
 - **Path:** limagrain/06-erp-interface/mapping-erp-wms.md
 - **Type:** limagrain
 - Processus [CUSTOM] de changement d'article et de propriétaire en cours de vie du stock, via message CHG.
-### LOC — Message périodique (spécification complète)
+### LOC - Message périodique (spécification complète)
 - **Path:** limagrain/06-erp-interface/loc-message-periodique.md
 - **Type:** limagrain
 - Message custom LOC envoyé du WMS vers SAP toutes les 5 minutes, contenant le delta des HU modifiées. Remplace PCK, MOVE, STV et STC. 7 codes ACTION (B/U/R/S/T/C/P), architecture Job→GNA→BOO→SAP-CPI.
@@ -301,7 +321,7 @@ Total : 122 pages
 - **Type:** limagrain
 - Communication GNA vers SAP-CPI : OAuth 2.0 client_credentials, endpoint unique ATHInboundMessage, routage MessageType→MessageSAP, retry backoff.
-### Utilisateurs et groupes — Permissions EasyWMS
+### Utilisateurs et groupes - Permissions EasyWMS
 - **Path:** limagrain/07-admin/utilisateurs-groupes.md
 - **Type:** limagrain
 - Définition des 3 groupes d'utilisateurs Limagrain et leurs permissions respectives.
@@ -311,37 +331,42 @@ Total : 122 pages
 - **Type:** limagrain
 - Annuaire complet des intervenants du projet Limagrain (client, intégrateur, partenaires).
-### AD Customs — Éléments personnalisés
+### AD Customs - Custom Attributes
 - **Path:** limagrain/07-admin/ad-customs.md
 - **Type:** limagrain
- Inventaire centralisé des Custom Attributes (CstAtt Container 1-12, Réception, OE, Stock, OS) et éléments AD personnalisés du projet Limagrain.
+- Catalogue CstAtt par entité (Article, Support 1-14, Stock, OE, Réception, Ligne inventaire, Stratégies rangement, Status stock, Tâche, OS), aligné sur le référentiel LIM-14.
-### Job AGV — Réception production vers ASRS
+### Paramètres projet - Séquences, toggles, jobs et paramètres WMS
 - **Path:** limagrain/07-admin/parametres-projet.md
 - **Type:** limagrain
 - Référentiel LIM-14 : séquences, toggles, transactions customs, paramètres standards + customs, jobs périodiques (fréquences, WF).
 ### Job AGV - Réception production vers ASRS
 - **Path:** limagrain/05-agv/job-reception-production.md
 - **Type:** limagrain
 - Job périodique (30s) créant les tâches AGV de déplacement image de quai → buffer entrée production. Éligibilité : séquence 8000*, CstAtt04="ASN", anti-doublon.
-### Mini Job — Images de quai vers PK
+### Mini Job - Images de quai vers PK
 - **Path:** limagrain/05-agv/job-reception-pk.md
 - **Type:** limagrain
 - Sous-workflow du Mega Job orchestrant l'envoi des palettes depuis les images de quai vers les PK. Filtre big-bag, FIFO, assignation CstAtt06, création tâches "en attente".
-### Intégration Still iGo — API PACS et architecture
+### Intégration Still iGo - API PACS et architecture
 - **Path:** limagrain/05-agv/still-igo-integration.md
 - **Type:** limagrain
 - Documentation complète de l'intégration du fleet manager iGO easy (STILL/KION) avec EasyWMS : API REST PACS 2.3, cycle de vie des transports, mapping module AGV standard, architecture cible à 4 composants (Gateway + Pool IIS C#), FAQ STILL contractuelles.
-### Stations et routes AGV — Topologie iGO
+### Stations et routes AGV - Topologie iGO
 - **Path:** limagrain/05-agv/agv-stations-routes.md
 - **Type:** limagrain
 - Correspondance entre stations/routes EasyWMS et concepts Location/Group/Vehicle iGO. Configuration MyMA vs EasyS, décision tardive, verrous.
-### Troubleshooting AGV — Contraintes terrain
+### Troubleshooting AGV - Contraintes terrain
 - **Path:** limagrain/05-agv/agv-troubleshooting.md
 - **Type:** limagrain
 - Problèmes physiques identifiés lors de la visite terrain Still/Mecalux du 29/05/2026 : avaloirs, déport Zone Est/Ouest, SAS7, poste de rejet. Actions correctives Mecalux et Still.
-### Questions ouvertes — Suivi projet
+### Questions ouvertes - Suivi projet
 - **Path:** limagrain/08-transverse/questions-ouvertes.md
 - **Type:** limagrain
 - Centralisation de toutes les questions ouvertes identifiées lors de l'intégration.
@@ -1,155 +1,54 @@
 ---
 title: "Wiki Health / Lint Report"
 type: meta
-generated: "2026-05-12"
+generated: "2026-07-20"
-scope: "134 pages (84 standard + 45 limagrain + 5 racine)"
+scope: "86 fichiers standard (architecture, concepts, modules, operations, glossary, _index)"
 ---
-# Rapport de lint complet — Wiki EasyWMS + Limagrain
+# Rapport de lint - Wiki standard EasyWMS
-**Date** : 2026-05-12
+**Date** : 2026-07-20 (remplace le rapport du 2026-05-12)
-**Total fichiers analysés** : 134 (84 standard, 45 limagrain, 5 racine)
+**Périmètre** : wiki standard uniquement. Le lint Limagrain du même jour est
-**Fichiers avec problèmes** : 95 (dont 81 uniquement LINE-LENGTH)
+documenté dans [limagrain/_lint_report.md](limagrain/_lint_report.md).
 **Total problèmes** : 1820
-## Résumé global par règle
+## Scan initial (scanner v2)
-| Règle | Total | Standard | Limagrain | Racine | Sévérité |
+Scanner corrigé par rapport aux passes précédentes : slug GitHub + ancres HTML
-|-------|-------|----------|-----------|--------|----------|
+`<a id="…">`, pipes échappés dans les tableaux, tracking des lignes vides
-| LINE-LENGTH (>120 car.) | 1761 | 1251 | 487 | 23 | Info |
+autour des blocs de code. 34 des 53 ancres signalées par le premier scan
-| BROKEN-LINK | 33 | 0 | 21 | 12 | Erreur |
+étaient des faux positifs de l'ancien algorithme.
 | DUPLICATE-HEADING | 13 | 5 | 0 | 8 | Warning |
 | TRAILING-SPACE | 6 | 6 | 0 | 0 | Info |
 | MULTI-H1 | 4 | 3 | 0 | 1 | Warning |
 | FRONTMATTER-MISSING | 3 | 0 | 0 | 3 | Erreur |
-## Actions correctives appliquées (session 2026-05-12)
+| Catégorie | Bloquant | Mineur | Cosmétique | Total |
 |-----------|----------|--------|------------|-------|
 | Front matter | 0 | 3 | 0 | 3 |
 | Markdown / structure | 0 | 0 | 86 | 86 |
 | Conventions (em dash, checklists) | 0 | 24 | 86 | 110 |
 | Liens et ancres | 0 | 19 | 0 | 19 |
 | Registre _index.md | 0 | 1 | 0 | 1 |
 | Glossaire (doublons) | 0 | 0 | 0 | 0 |
 | **Total** | **0** | **47** | **172** | **219** |
-Corrections sur le wiki **Limagrain uniquement** (le standard est en lecture seule) :
+## Corrections appliquées (session 2026-07-20, mode standard)
-| Catégorie | Avant | Après | Action |
+| Correction | Détail |
-|-----------|-------|-------|--------|
+|------------|--------|
-| BLANK-LINES | 105 | 0 | Nettoyé sur 45 fichiers |
+| Em dashes | 1712 « — » remplacés par « - » (86 fichiers + sections standard de `_index.md` ; l'en-tête `## Limagrain — Projet` conservé, format prescrit) |
-| BROKEN-LINK (vers standard) | 15 | 0 | Liens corrigés vers les bons fichiers |
+| Checklists | 24 « `- [ ]` » convertis en « `- ☐` » (galileo-troubleshooting, git-workflow, robotics-project-lifecycle) - visuel checklist conservé sans créer de todos Obsidian |
-| DUPLICATE-HEADING | 8 | 0 | Headings désambiguïsés |
+| Ancres | 33 réparées (recalcul des slugs après conversion em dash + headings renommés). 2 fausses réparations annulées : `#import` et `#export` étaient valides via ancres HTML `<a id>` |
-| TRAILING-SPACE | 1 | 0 | Nettoyé |
+| Ancre irrésoluble | `code-review-process.md` : `#manuel-de-reten` reciblé vers `#1-phase-de-développement` (section contenant le passage sur le manuel de reten) |
-| README.md tronqué | 1 | 0 | Fichier réécrit |
+| related | `stock-assignment.md` : `modules/tenseflow.md` → `concepts/tense-flow.md` ; `weights.md` : `modules/pie.md` → `concepts/mechanical-elements.md` ; `rf-menu.md` : `concepts/group.md` retiré (shipping.md déjà présent) |
-| **Total corrigé** | **130** | **0** | |
+| Registre | Compteur global corrigé : `Total : 131 pages (85 standard + 46 Limagrain)` |
 | Trailing | 2 lignes nettoyées |
---
+Vérification croisée : aucune ancre du wiki Limagrain ne pointait vers un
 heading standard modifié - aucun fichier `limagrain/` touché durant cette
 session (cloisonnement respecté).
-## Wiki standard — 15 problèmes (hors LINE-LENGTH)
+## Re-scan final (2026-07-20)
-> Le wiki standard est en **lecture seule** — ces problèmes sont documentés
+**0 anomalie** : aucun lien cassé, aucune ancre morte (headings + ancres HTML),
-> mais non corrigés.
+aucun em dash, aucune checklist `- [ ]`, aucun trailing space, `related`
 valides, registre complet (85/85 pages standard référencées).
-### DUPLICATE-HEADING (5)
+Résiduel connu non corrigé : lignes > 120 caractères (prose et front matter),
-
+tolérées par la règle « souple pour tableaux et liens ».
 | Fichier | Heading dupliqué |
 |---------|-----------------|
 | `concepts/crossdocking.md` | `Concept`, `Conditions and Eligibility`, `Process Flow` |
 | `concepts/defragmentation.md` | `Strategy Rules (Destination Selection)`, `Execution` |
 ### TRAILING-SPACE (6)
 | Fichier | Lignes |
 |---------|--------|
 | `concepts/cutting-stock.md` | L167, L256 |
 | `concepts/labels.md` | L186, L215 |
 | `concepts/stock-adjustment.md` | L150 |
 | `concepts/warehouse-designer.md` | L210 |
 ### MULTI-H1 (3)
 | Fichier | Nb H1 |
 |---------|-------|
 | `operations/deployment-existing-app.md` | 3 |
 | `operations/first-deployment.md` | 3 |
 | `operations/git-workflow.md` | 9 |
 ### DUPLICATE-HEADING — operations
 | Fichier | Heading |
 |---------|---------|
 | `operations/custom-application-management.md` | `Procédure` |
 ### LINE-LENGTH
 1251 occurrences sur l'ensemble des 84 pages standard. La plupart sont
 des paragraphes longs non wrappés, typiques d'un wiki généré.
 ---
 ## Wiki Limagrain — 21 problèmes résiduels
 Tous des **BROKEN-LINK vers des pages du squelette non encore créées**.
 Aucun autre type de problème.
 ### Pages du squelette manquantes (11)
 | Page | Section | Référencée depuis |
 |------|---------|-------------------|
 | `03-picking/waves-groupes.md` | Picking | README, _index.md |
 | `03-picking/replenishment.md` | Picking | README, _index.md |
 | `05-agv/still-igo-integration.md` | AGV | README, _index.md |
 | `05-agv/agv-stations-routes.md` | AGV | README, _index.md |
 | `05-agv/agv-troubleshooting.md` | AGV | README, _index.md |
 | `06-erp-interface/interface-monitoring.md` | ERP | README, _index.md |
 | `07-admin/parametres-projet.md` | Admin | README, _index.md |
 | `07-admin/ad-customs.md` | Admin | README, _index.md |
 | `08-transverse/jira-tickets-cles.md` | Transverse | README, _index.md |
 | `08-transverse/decisions-architecture.md` | Transverse | README, _index.md, zones-stockage.md |
 | `08-transverse/historique-projet.md` | Transverse | README, _index.md |
 ---
 ## Fichiers racine — 23 problèmes (hors LINE-LENGTH)
 > Ces fichiers sont des méta-fichiers du dépôt.
 ### `CLAUDE.md`
 - **FRONTMATTER-MISSING** : normal (fichier d'instructions, pas une page wiki)
 - **MULTI-H1** (3) : structure multi-section attendue
 - **BROKEN-LINK** (12) : liens d'exemple dans les templates, pas des
  liens réels vers des pages
 ### `_index.md`
 - **FRONTMATTER-MISSING** : fichier MCP discovery, format spécifique
 - **DUPLICATE-HEADING** (2) : `Batch 12 — Robotics & GALILEO Integration`
  apparaît 2 fois — doublon probable à nettoyer
 ### `_log.md`
 - **FRONTMATTER-MISSING** : journal technique, format libre
 - **DUPLICATE-HEADING** (5) : `Index`, `Rationale` (x2),
  `Pages updated (1)`, `New pages created (1)` — structure répétitive
  du log, pas un problème fonctionnel
 ---
 ## Statistiques du wiki Limagrain
 | Métrique | Valeur |
 |----------|--------|
 | Pages rédigées (avec contenu) | 34 |
 | Pages squelette (à créer) | 11 |
 | Sections actives | 8 |
 | Sessions d'intégration | 13 |
 | Fichiers sources consommés | 22 |
 ## Règles vérifiées
 - Front matter présent et complet (title, tags, status, last_updated)
 - Status valide (draft, review, validated)
 - Headings ATX uniquement, pas de saut de niveau
 - Pas de heading H1 multiple
 - Pas de headings dupliqués dans un même fichier
 - Pas de lignes vides multiples consécutives
 - Pas de trailing spaces
 - Line length <= 120 caractères (souple pour tableaux/liens)
 - Liens internes relatifs (pas de chemins absolus)
 - Liens internes .md vérifiés (fichier cible existe)
 - Toutes les pages référencées dans README.md
 - Nommage kebab-case des fichiers
@@ -26,18 +26,18 @@ The AD contains approximately **38,765 elements** spanning Commands, Queries, Di
 ### Commands
-Commands represent **executable operations** — actions that change system state.
+Commands represent **executable operations** - actions that change system state.
 - Mapped to `POST /api/commands/{commandName}` in the API
 - Have input parameters (validated before execution) and return a result
 - May trigger Transactions (audit records) and Events
 - May invoke sub-commands or start Workflows
 - Examples:
-  - `ReceiveContainer` — receive a container at a dock station
+  - `ReceiveContainer` - receive a container at a dock station
-  - `ReleaseShippingOrder` — release a shipping order for picking
+  - `ReleaseShippingOrder` - release a shipping order for picking
-  - `AdjustStock` — perform a quantity adjustment
+  - `AdjustStock` - perform a quantity adjustment
-  - `CreateCount` — create a physical count order
+  - `CreateCount` - create a physical count order
-  - `AssignTask` — assign a task to an operator
+  - `AssignTask` - assign a task to an operator
 Commands are permission-controlled: each command is associated with one or more AD roles. A user can only execute commands their role permits.
@@ -49,16 +49,16 @@ Queries represent **data retrieval operations** using a LINQ-style expression en
 - Support filtering, sorting, pagination
 - Can reference any View or Entity
 - Examples:
-  - `GetStockByLocation` — fetch stock for a location
+  - `GetStockByLocation` - fetch stock for a location
-  - `GetOpenShippingOrders` — fetch all non-closed shipping orders
+  - `GetOpenShippingOrders` - fetch all non-closed shipping orders
-  - `GetContainerContents` — fetch stock lines in a container
+  - `GetContainerContents` - fetch stock lines in a container
-  - `GetTasksByStatus` — fetch tasks matching a status
+  - `GetTasksByStatus` - fetch tasks matching a status
 The **QueryExecute API** allows ad-hoc LINQ queries without pre-defining a named Query element.
 ### Entities
-Entities are the **core data objects** of the system — the persistent domain model.
+Entities are the **core data objects** of the system - the persistent domain model.
 Each Entity has:
 - A schema (fields, types, constraints)
@@ -111,11 +111,11 @@ Views are **read-only projections** of one or more Entities, optimized for displ
 - May include computed columns and aggregations
 - Back all SmartUI list screens and RF terminal display screens
 - Examples:
-  - `ViewContainers` — containers with location and status
+  - `ViewContainers` - containers with location and status
-  - `ViewStocks` — stock lines with full context
+  - `ViewStocks` - stock lines with full context
-  - `ViewTasksOpen` — open tasks with assignment info
+  - `ViewTasksOpen` - open tasks with assignment info
-  - `ViewShippingOrdersMonitor` — order monitoring dashboard
+  - `ViewShippingOrdersMonitor` - order monitoring dashboard
-  - `ViewGroupedStock` — aggregated stock by item/owner
+  - `ViewGroupedStock` - aggregated stock by item/owner
 ### Dialogs
@@ -126,10 +126,10 @@ Dialogs are **multi-step interactive flows** that guide an operator through a co
 - State is maintained server-side between steps
 - API: `POST /api/dialogs/{dialogName}/start`, then `POST /api/dialogs/{sessionId}/step`
 - Examples:
-  - `ReceptionDialog` — multi-step reception flow (select order → scan container → enter quantities → confirm)
+  - `ReceptionDialog` - multi-step reception flow (select order → scan container → enter quantities → confirm)
-  - `PickingDialog` — guided picking (scan location → confirm quantity → scan destination)
+  - `PickingDialog` - guided picking (scan location → confirm quantity → scan destination)
-  - `CountDialog` — count guided flow (scan location → count items → confirm)
+  - `CountDialog` - count guided flow (scan location → count items → confirm)
-  - `ShippingConsolidationDialog` — consolidation at shipping station
+  - `ShippingConsolidationDialog` - consolidation at shipping station
 Dialogs encapsulate the complete operator interaction sequence for a process, invoking Commands internally at each confirmation step.
@@ -155,11 +155,11 @@ Workflows are **orchestrated sequences** of Commands, conditional logic, and sta
 - Used for complex multi-step processes: reception, putaway strategy evaluation, replenishment logic
 - Can be synchronous (blocking) or asynchronous (background)
 - Examples:
-  - `PutawayWorkflow` — 8-stage pipeline (criteria → aisles → balancing → restrictions → validity → rules → sort → select)
+  - `PutawayWorkflow` - 8-stage pipeline (criteria → aisles → balancing → restrictions → validity → rules → sort → select)
-  - `StockAssignmentWorkflow` — evaluate assignment strategies → assign to shipping order lines
+  - `StockAssignmentWorkflow` - evaluate assignment strategies → assign to shipping order lines
-  - `ReplenishmentWorkflow` — check PDL levels → select strategy → generate tasks
+  - `ReplenishmentWorkflow` - check PDL levels → select strategy → generate tasks
-  - `DefragmentationWorkflow` — evaluate rotation/shipping criteria → generate movement tasks
+  - `DefragmentationWorkflow` - evaluate rotation/shipping criteria → generate movement tasks
-  - `CountCloseWorkflow` — close count → compute differences → generate STK.ADJ transactions → send COF to ERP
+  - `CountCloseWorkflow` - close count → compute differences → generate STK.ADJ transactions → send COF to ERP
 ### Background Jobs
@@ -178,7 +178,7 @@ Background Jobs are **scheduled or continuous Workflows** that run autonomously:
 ### Parameters
-AD Parameters are the **configuration knobs** of the system — named key-value pairs that alter behavior without code changes.
+AD Parameters are the **configuration knobs** of the system - named key-value pairs that alter behavior without code changes.
 - Scope: Organization or Warehouse
 - Accessible via the Parameters view in SmartUI (Inventory > Parameters)
@@ -238,12 +238,12 @@ The AD can be extended by Mecalux partners:
 4. **Custom Parameters**: Add module-specific configuration
 5. **Custom Events**: React to standard system events with custom logic
-This extensibility model is used by all optional modules (AGV, Slotting, 3PL Billing, DOM, etc.) — each module adds its own AD elements without modifying core elements.
+This extensibility model is used by all optional modules (AGV, Slotting, 3PL Billing, DOM, etc.) - each module adds its own AD elements without modifying core elements.
 ## Related
- [Overview](overview.md) — System architecture and deployment
+- [Overview](overview.md) - System architecture and deployment
- [Entities Map](entities-map.md) — Visual map of entity relationships
+- [Entities Map](entities-map.md) - Visual map of entity relationships
- [Transactions](../concepts/transactions.md) — Transaction audit trail (generated by Commands)
+- [Transactions](../concepts/transactions.md) - Transaction audit trail (generated by Commands)
- [ERP Interface](../concepts/erp-interface.md) — ERP messages (triggered by Events)
+- [ERP Interface](../concepts/erp-interface.md) - ERP messages (triggered by Events)
- [Parameters](../concepts/parameters.md) — System parameter catalog
+- [Parameters](../concepts/parameters.md) - System parameter catalog
@@ -25,7 +25,7 @@ last_compiled: "2026-04-10"
 ## Overview
-This page provides the complete entity relationship model of Easy WMS, synthesized from all documented behavior across Batches 1–5. It shows the core entities, their key attributes, and how they relate to one another — forming the mental model needed to interpret WMS data.
+This page provides the complete entity relationship model of Easy WMS, synthesized from all documented behavior across Batches 1–5. It shows the core entities, their key attributes, and how they relate to one another - forming the mental model needed to interpret WMS data.
 ## Core Entity Hierarchy
@@ -436,16 +436,16 @@ Each entity has ERP messages that create, update, or receive data:
 | Entity | ERP In (ERP→WMS) | ERP Out (WMS→ERP) |
 |--------|-----------------|------------------|
-| Item | ITM | — |
+| Item | ITM | - |
-| Owner | OWN | — |
+| Owner | OWN | - |
-| Supplier | SUP | — |
+| Supplier | SUP | - |
-| Account | ACC | — |
+| Account | ACC | - |
-| Carrier | CAR | — |
+| Carrier | CAR | - |
 | Kit | KIT | KST (assemble), UNK (disassemble) |
-| ItemClassification | ITC | — |
+| ItemClassification | ITC | - |
 | ReceiptOrder | ROR | ROC (status), ROF (close) |
 | Container (ASN) | ASN | ASO (received), ASK (rejected) |
-| Receipt | — | REF (closed) |
+| Receipt | - | REF (closed) |
 | ShippingOrder | SOR, RUT, WOR | SOC (status), SOF (close), LOF (load close), WOF (work order close) |
 | Count | COR | COF (finalized) |
 | Stock | STR (lock), SCR (contrast) | STV (variation), STC (status change), WSC (contrast response) |
@@ -454,13 +454,13 @@ Each entity has ERP messages that create, update, or receive data:
 ## Related
- [Application Dictionary](application-dictionary.md) — AD element types: Commands, Queries, Entities
+- [Application Dictionary](application-dictionary.md) - AD element types: Commands, Queries, Entities
- [Container](../concepts/container.md) — Container entity deep-dive
+- [Container](../concepts/container.md) - Container entity deep-dive
- [Location](../concepts/location.md) — Location entity deep-dive
+- [Location](../concepts/location.md) - Location entity deep-dive
- [Stock](../concepts/stock.md) — Stock entity deep-dive
+- [Stock](../concepts/stock.md) - Stock entity deep-dive
- [Product / Item](../concepts/product-item.md) — Item entity deep-dive
+- [Product / Item](../concepts/product-item.md) - Item entity deep-dive
- [Task](../concepts/task.md) — Task entity lifecycle
+- [Task](../concepts/task.md) - Task entity lifecycle
- [Inbound Order](../concepts/order-inbound.md) — Receipt order entity
+- [Inbound Order](../concepts/order-inbound.md) - Receipt order entity
- [Outbound Order](../concepts/order-outbound.md) — Shipping order entity
+- [Outbound Order](../concepts/order-outbound.md) - Shipping order entity
- [Transactions](../concepts/transactions.md) — Full transaction audit trail
+- [Transactions](../concepts/transactions.md) - Full transaction audit trail
- [ERP Interface](../concepts/erp-interface.md) — ERP message catalog
+- [ERP Interface](../concepts/erp-interface.md) - ERP message catalog
@@ -23,20 +23,20 @@ last_compiled: "2026-04-17"
 ## Overview
-**GALILEO** is the Mecalux **Transport Management System (TMS)** — the automation layer that physically controls conveyors, stacker cranes (TK / Miniload), shuttles, AGVs, lifts and all other mechanized equipment. EasyWMS holds all the business intelligence (stock, strategies, orders); **GALILEO has no predictive vision** — it requests work from EasyWMS and executes it.
+**GALILEO** is the Mecalux **Transport Management System (TMS)** - the automation layer that physically controls conveyors, stacker cranes (TK / Miniload), shuttles, AGVs, lifts and all other mechanized equipment. EasyWMS holds all the business intelligence (stock, strategies, orders); **GALILEO has no predictive vision** - it requests work from EasyWMS and executes it.
 Two parallel automation controllers exist in the Mecalux ecosystem:
- **GALILEO** — classic PLC-driven TMS, deployed on production sites
+- **GALILEO** - classic PLC-driven TMS, deployed on production sites
- **EasyS** — 3D simulation environment that speaks the same protocol as GALILEO; used for development, demos and pre-site validation (see [Galileo Simulation](../operations/galileo-simulation.md))
+- **EasyS** - 3D simulation environment that speaks the same protocol as GALILEO; used for development, demos and pre-site validation (see [Galileo Simulation](../operations/galileo-simulation.md))
-Both dialogue with EasyWMS through the **EasyWMS Gateway** Windows service — a translator between GALILEO's low-level frame protocol and the EasyWMS API.
+Both dialogue with EasyWMS through the **EasyWMS Gateway** Windows service - a translator between GALILEO's low-level frame protocol and the EasyWMS API.
 Reference documents:
- [Control_Communications_Interface_EN_GB.pdf](https://msscc.mecalux.com/documentation/Automation/master/ES/Documents/GalileoAWS/Control_Communications_Interface_EN_GB.pdf) — all station types, event types, PIE flags
+- [Control_Communications_Interface_EN_GB.pdf](https://msscc.mecalux.com/documentation/Automation/master/ES/Documents/GalileoAWS/Control_Communications_Interface_EN_GB.pdf) - all station types, event types, PIE flags
- [EasyWMSGateway_ControlInterface_EN.pdf](https://msscc.mecalux.com/documentation/documentation/master/ES/docs_downloads/services/docs/EasyWMSGateway_ControlInterface_EN.pdf) — frame structure (low-level)
+- [EasyWMSGateway_ControlInterface_EN.pdf](https://msscc.mecalux.com/documentation/documentation/master/ES/docs_downloads/services/docs/EasyWMSGateway_ControlInterface_EN.pdf) - frame structure (low-level)
- [Stations index](https://msscc.mecalux.com/documentation/documentation/master/EN/areas/layout/stations/index.md) — station-specific behaviour
+- [Stations index](https://msscc.mecalux.com/documentation/documentation/master/EN/areas/layout/stations/index.md) - station-specific behaviour
- [IdentErrorType](https://msscc.mecalux.com/documentation/Development/master/ES/apis/easywms/Domain/IdentErrorType.md) — rejection reason codes
+- [IdentErrorType](https://msscc.mecalux.com/documentation/Development/master/ES/apis/easywms/Domain/IdentErrorType.md) - rejection reason codes
 ## EasyWMS Gateway Service
@@ -79,7 +79,7 @@ A movement can only be generated if a **route** exists in EasyS between its orig
 ## Stations & Routes (from GALILEO's perspective)
-Stations are the start/end points of every movement. A station is uniquely identified by the couple **(StationType, StationNumber)** — this pair must be identical in EasyS and in GALILEO; any drift causes `EndErrorCode=4` errors (see Troubleshooting).
+Stations are the start/end points of every movement. A station is uniquely identified by the couple **(StationType, StationNumber)** - this pair must be identical in EasyS and in GALILEO; any drift causes `EndErrorCode=4` errors (see Troubleshooting).
 For the full reference of station codes (FR/ES/EN), acronyms (ALM/TK/PK/PIE/PS/ME/MS/PKE/CME/ET/MU/REAC/RECH/…) and roles, see [Mechanical Elements](../concepts/mechanical-elements.md) and [Stations & Routes](../concepts/stations.md).
@@ -120,7 +120,7 @@ Sometimes `ETPSxx → PSxx` must be reported to sequence shipping.
 Declaration of container presence at a meaningful point. Primary sources:
- **PIE**: reports a new container with label read + gauge data — EasyWMS decides conformity
+- **PIE**: reports a new container with label read + gauge data - EasyWMS decides conformity
 - **TK**: announces presence
 - **Picking confirmation**: operator has finished a picking task
@@ -140,7 +140,7 @@ PIE flag values (bitwise):
 | Flag | Meaning |
 |------|---------|
-| `65536` | Container OK — no error |
+| `65536` | Container OK - no error |
 | `256` | Barcode error |
 | `512` | Recovered container |
 | `1024` / `66560` | Correct + empty |
@@ -151,14 +151,14 @@ PIE flag values (bitwise):
 **Two PIE processes depending on container origin:**
-1. **New container** — GALILEO reads the label and sends type/height; EasyWMS verifies conformity and decides destination
+1. **New container** - GALILEO reads the label and sends type/height; EasyWMS verifies conformity and decides destination
-2. **Known container returning** — EasyWMS pre-sends a movement toward PIE; GALILEO verifies types match, without re-reading the label
+2. **Known container returning** - EasyWMS pre-sends a movement toward PIE; GALILEO verifies types match, without re-reading the label
 **PIE insert modes (set from EasyWMS → Control → Stations):**
- **Normal (known containers)** — reject anything the ASN doesn't recognize
+- **Normal (known containers)** - reject anything the ASN doesn't recognize
- **Empty container creation** — create supports from the data GALILEO sends (code, weight, height type…)
+- **Empty container creation** - create supports from the data GALILEO sends (code, weight, height type…)
- **Pallet pile creation** — operator activates "insert pallet piles" on the GALILEO console; GALILEO sends events with `Transport Number = 10`; item code + qty per pile must be defined in EasyWMS
+- **Pallet pile creation** - operator activates "insert pallet piles" on the GALILEO console; GALILEO sends events with `Transport Number = 10`; item code + qty per pile must be defined in EasyWMS
 **Workflow triggered:** `Galileo_PIEEventHandler_PR`
@@ -184,7 +184,7 @@ GALILEO asks EasyWMS "what should I do with this container?" or "give me a next
 |-------|------------------------|
 | Physical station PK | 1 container on the conveyor |
 | Route to PK | 4 containers in transit on intermediate conveyors |
-| WMS PK capacity | 15 — physical + transit + every task whose destination is PK |
+| WMS PK capacity | 15 - physical + transit + every task whose destination is PK |
 **Response state codes:**
@@ -194,7 +194,7 @@ GALILEO asks EasyWMS "what should I do with this container?" or "give me a next
 | `70` | **F** = Fallo (fault) | TK |
 | `69` | **E** = Error | TK |
-**X actual / Y actual** — only meaningful for TK; the current crane position is sent so EasyWMS can optimise task ordering.
+**X actual / Y actual** - only meaningful for TK; the current crane position is sent so EasyWMS can optimise task ordering.
 **Workflow triggered:** `Galileo_SearchCreatedEventHandler_PR`. Routed by station type inside the process.
@@ -204,7 +204,7 @@ GALILEO asks EasyWMS "what should I do with this container?" or "give me a next
 - Movement transitions from **Generated** → **In progress**
 - Container is virtually relocated to **Mov**
-> ⚠️ GALILEO can emit dozens of Search per second per station. **Do not enable workflow instance tracking on Search events carelessly** — scope it to the process and keep trace TTL very short, otherwise the trace tables explode.
+> ⚠️ GALILEO can emit dozens of Search per second per station. **Do not enable workflow instance tracking on Search events carelessly** - scope it to the process and keep trace TTL very short, otherwise the trace tables explode.
 ### 3. End (log → `End0`, `End1`, …)
@@ -217,7 +217,7 @@ Signals that GALILEO has finished the current movement. EasyWMS advances to the
 | `0` | Movement completed | Next movement generated |
 | `1` | Deposit error | Error mask + relocation / reject |
 | `2` | Extraction error | Error mask + relocation / reject |
-| `4` | Inconsistent order | WMS/GALILEO configuration mismatch — see troubleshooting |
+| `4` | Inconsistent order | WMS/GALILEO configuration mismatch - see troubleshooting |
 | `7` | Gauge error | Relocation / reject |
 **Workflow triggered:** `Galileo_EndCreatedEventHandler_PR`
@@ -233,7 +233,7 @@ Sent **every 1–3 seconds** by GALILEO (or immediately on change of state / loa
 | StationType | Station type code |
 | StationNumber | Station number |
 | Status | `0` = unavailable (fault, manual mode, safety); `1` = available |
-| Loaded | `0` = occupied; `1` = free — **note the inversion** |
+| Loaded | `0` = occupied; `1` = free - **note the inversion** |
 | Capacity | Max containers |
 | CurrentCount | Current GALILEO trackings on the station |
 | Aisle | Aisle number associated with the station |
@@ -251,7 +251,7 @@ SetStationStatus(Type, Numéro, Status, Présence, Capacité, Occupation, Allée
 |-------|---------|
 | StationTypeSource / StationNumberSource | Origin station |
 | StationTypeDestination / StationNumberDestination | Destination station |
-| Status | `0`/`1`/`2`/`3` — see Route status values above |
+| Status | `0`/`1`/`2`/`3` - see Route status values above |
 | CurrentCount | Trackings currently between the two stations |
 **Function exposed by GALILEO:**
@@ -259,7 +259,7 @@ SetStationStatus(Type, Numéro, Status, Présence, Capacité, Occupation, Allée
 SetRouteStatus(TypeOrigine, NuméroOrigine, TypeDestination, NuméroDestination, Etat)
 ```
-## End-to-End Example — Container Arriving at PIE
+## End-to-End Example - Container Arriving at PIE
 ```
 1. PIE reads label + gauges            → Event (Galileo_PIEEventHandler_PR)
@@ -277,7 +277,7 @@ SetRouteStatus(TypeOrigine, NuméroOrigine, TypeDestination, NuméroDestination,
 Every automation element is a sequential machine (grafcet) with discrete steps and transitions. Typical conveyor sequence:
-1. Rest — ready to receive
+1. Rest - ready to receive
 2. Request output from upstream conveyor
 3. Verify conditions (no presence, no tracking…)
 4. Copy tracking + physical transfer + (if station) notify WMS
@@ -299,8 +299,8 @@ Core workflows:
 Core commands:
- `GalileoMovTrackingCreateCommand` — push an order frame to GALILEO (preferred)
+- `GalileoMovTrackingCreateCommand` - push an order frame to GALILEO (preferred)
- `GalileoMovTrackingCreateChangingTargetCommand` — variant that changes target mid-transport (avoid unless strictly necessary)
+- `GalileoMovTrackingCreateChangingTargetCommand` - variant that changes target mid-transport (avoid unless strictly necessary)
 See [Application Dictionary](application-dictionary.md) for naming conventions and extension points.
@@ -310,25 +310,25 @@ The GALILEO SCADA (visualization tool) displays machines, trackings and faults i
 - **Default credentials**: `mecalux / robmec`
 - **Tracking editor** (double-click a machine):
-  - *Show tracking* — the order in execution
+  - *Show tracking* - the order in execution
-  - *End order* — force-tell EasyWMS that the pallet has reached destination (manual override)
+  - *End order* - force-tell EasyWMS that the pallet has reached destination (manual override)
-  - *Machine state* — what GALILEO is currently reporting to EasyWMS
+  - *Machine state* - what GALILEO is currently reporting to EasyWMS
 - **Advanced tab (unlock icon + password):**
-  - *Variables* — live variables; booleans can be forced
+  - *Variables* - live variables; booleans can be forced
-  - *Graph* — current grafcet step
+  - *Graph* - current grafcet step
 - **Edit buttons:**
-  - *Edit tracking* — origin, destination, height, type… (click "Edit" first)
+  - *Edit tracking* - origin, destination, height, type… (click "Edit" first)
-  - *Delete tracking* — remove tracking from the machine
+  - *Delete tracking* - remove tracking from the machine
-  - *Reset* — jump the grafcet to a specific step
+  - *Reset* - jump the grafcet to a specific step
 Manual tracking edits are a last-resort diagnostic / recovery tool.
 ## Related
 - [Mechanical Elements (acronyms, conveyors, station codes)](../concepts/mechanical-elements.md)
- [Stations & Routes](../concepts/stations.md) — full station catalogue from the WMS side
+- [Stations & Routes](../concepts/stations.md) - full station catalogue from the WMS side
 - [Galileo Simulation & Test Setup](../operations/galileo-simulation.md)
 - [Galileo Troubleshooting (Logs, Faults)](../operations/galileo-troubleshooting.md)
 - [Robotics Project Lifecycle](../operations/robotics-project-lifecycle.md)
- [Automation Dashboard](../modules/automation-dashboard.md) — fault monitoring UI
+- [Automation Dashboard](../modules/automation-dashboard.md) - fault monitoring UI
 - [Task](../concepts/task.md) · [Location](../concepts/location.md)
@@ -2,7 +2,7 @@
 title: "System Architecture Overview"
 type: architecture
 sources:
-  - areas/architecture/index.md (404 — compiled from cross-source knowledge)
+  - areas/architecture/index.md (404 - compiled from cross-source knowledge)
  - areas/saas/index.md (404)
  - areas/hardware/index.md (404)
  - areas/license/index.md (404)
@@ -111,7 +111,7 @@ Mixed warehouses (some automatic aisles, some manual) are supported. The warehou
 Automatic warehouses depend on a **Transport Management System (TMS)** that physically drives conveyors, stacker cranes, miniloads, shuttles and lifts. In Mecalux installations the TMS is **GALILEO** (production) or **EasyS** (3D simulation for development / demos). Both dialog with EasyWMS through the **EasyWMS Gateway** Windows service over TCP port 3000.
-Principle: **EasyWMS holds all business intelligence** (stock, strategies, orders); **GALILEO has no predictive vision** — it only requests orders and executes them. Three GALILEO-initiated message types drive the flow (Event / Search / End) plus two status update streams (station / route).
+Principle: **EasyWMS holds all business intelligence** (stock, strategies, orders); **GALILEO has no predictive vision** - it only requests orders and executes them. Three GALILEO-initiated message types drive the flow (Event / Search / End) plus two status update streams (station / route).
 Full protocol, workflows (`Galileo_PIEEventHandler_PR`, `Galileo_SearchCreatedEventHandler_PR`, `Galileo_EndCreatedEventHandler_PR`) and command catalogue: [GALILEO Integration](galileo-integration.md). Bring-up and simulation: [Galileo Simulation](../operations/galileo-simulation.md). Troubleshooting: [Galileo Troubleshooting](../operations/galileo-troubleshooting.md).
@@ -145,7 +145,7 @@ Both servers run Windows Server. For small warehouses the DB and App roles can b
 - **Client (SmartUI)**: Modern web browser (Chrome/Edge); tablet or desktop PC
 - **RF Terminals (RFT)**: Dedicated warehouse scanners running Windows CE or Android; connect via WIFI
 - **Label Printers**: Zebra-type thermal printers; connected via network or USB
- **Automatic Warehouse**: Requires PLC/control system interface (proprietary per vendor — AGV, Pallet Shuttle, APS3D each use their own protocol)
+- **Automatic Warehouse**: Requires PLC/control system interface (proprietary per vendor - AGV, Pallet Shuttle, APS3D each use their own protocol)
 - **Scales**: PIE stations can have integrated scales for container weight validation
 - **Mobile Devices**: Android 10+ required for Amazon SaaS Marketplace integration
@@ -156,8 +156,8 @@ EasyWMS SaaS runs on Azure and is available in three subscription tiers:
 | Tier | vCPUs | RAM | Max concurrent users | Max orders/day |
 |------|-------|-----|---------------------|----------------|
 | **Basic** | 2 | 7 GB | 10 | 200 |
-| **Standard** | (contact Mecalux) | — | — | — |
+| **Standard** | (contact Mecalux) | - | - | - |
-| **Advanced** | (contact Mecalux) | — | — | — |
+| **Advanced** | (contact Mecalux) | - | - | - |
 All SaaS tiers: Mecalux manages infrastructure, updates, backup. ERP integration and printers require VPN tunnel or local agents. Some integrations (Amazon Marketplace) require Android 10+ devices.
@@ -189,11 +189,11 @@ Key system parameters are documented at `areas/parameters.md`. Each functional m
 ## Related
- [Application Dictionary](application-dictionary.md) — AD structure: Commands, Queries, Entities, Workflows
+- [Application Dictionary](application-dictionary.md) - AD structure: Commands, Queries, Entities, Workflows
- [Security](security.md) — User roles, authentication, audit
+- [Security](security.md) - User roles, authentication, audit
- [Entities Map](entities-map.md) — Data model and entity relationships
+- [Entities Map](entities-map.md) - Data model and entity relationships
- [ERP Interface](../concepts/erp-interface.md) — All ERP messages and integration protocols
+- [ERP Interface](../concepts/erp-interface.md) - All ERP messages and integration protocols
- [Parameters](../concepts/parameters.md) — System configuration parameters
+- [Parameters](../concepts/parameters.md) - System configuration parameters
- [AGV](../modules/agv.md) — Automatic warehouse AGV protocol
+- [AGV](../modules/agv.md) - Automatic warehouse AGV protocol
- [Pallet Shuttle](../modules/pallet-shuttle.md) — PS system architecture
+- [Pallet Shuttle](../modules/pallet-shuttle.md) - PS system architecture
- [APS3D](../modules/aps3d.md) — Fleet Manager controller
+- [APS3D](../modules/aps3d.md) - Fleet Manager controller
@@ -15,7 +15,6 @@ related:
  - concepts/kits.md
  - concepts/quality-control.md
  - concepts/container.md
  - concepts/group.md
  - modules/multi-carrier.md
 last_compiled: "2026-04-17"
 ---
@@ -29,11 +28,11 @@ The handheld RF terminal (`consolerf`) surfaces every operator flow through a fi
 1. **Customisation.** Overriding a menu entry means cloning the workflow, adjusting it, and pointing the menu at the new version through an Application Dictionary override.
 2. **Debugging.** When an operator reports "the RFT froze on screen X", locating the workflow that owns screen X is the shortest path to reading the logs.
 3. **Rights management.** Menu entries are granted per user/role ; this page lists the menu codes (`RFMenu_*`, `SharedMenu_*`) that configuration screens expect.
-4. **Training / acceptance.** Change management documents refer to workflow names — the table below is the cross-reference.
+4. **Training / acceptance.** Change management documents refer to workflow names - the table below is the cross-reference.
 All workflow codes belong to the `EasyWMS` namespace unless otherwise noted (`Deliveries` for the Multi-Carrier module).
-## 1. Tasks — `RFMenu_Task`
+## 1. Tasks - `RFMenu_Task`
 | Menu entry | Workflow |
 |---|---|
@@ -51,9 +50,9 @@ All workflow codes belong to the `EasyWMS` namespace unless otherwise noted (`De
 | Consolidation task | `EasyWMS.Consolidation_AutomaticTasks_FromMenu_UI` |
 | Cutting task | `EasyWMS.CutInStation_Main_UI` |
-## 2. Receptions — `SharedMenu_Receptions`
+## 2. Receptions - `SharedMenu_Receptions`
-### Blind reception — `RFMenu_BlindReception`
+### Blind reception - `RFMenu_BlindReception`
 | Menu entry | Workflow |
 |---|---|
@@ -61,7 +60,7 @@ All workflow codes belong to the `EasyWMS` namespace unless otherwise noted (`De
 | Mono-reference | `EasyWMS.BlindReception_Monoreference_Containers_UI` |
 | Identical mono-reference | `EasyWMS.BlindReception_Monoreference_Identical_Containers_UI` |
-### Suppliers — `RFMenu_Providers`
+### Suppliers - `RFMenu_Providers`
 | Menu entry | Workflow |
 |---|---|
@@ -77,14 +76,14 @@ All workflow codes belong to the `EasyWMS` namespace unless otherwise noted (`De
 | Advance notice reception | `EasyWMS.AdvanceNotice_Reception_UI` |
 | Generate labels | `EasyWMS.PrintLabels_MultireferenceContainerLabels_UI` |
-## 3. Putaway — `RFMenu_Putaway`
+## 3. Putaway - `RFMenu_Putaway`
 | Menu entry | Workflow |
 |---|---|
 | Containers or loose stock | `EasyWMS.Equipment_LoadStock_UI` |
 | Shared containers | `EasyWMS.Equipment_LoadContainer_UI` |
-## 4. Shipping orders — `SharedMenu_ShippingOrders`
+## 4. Shipping orders - `SharedMenu_ShippingOrders`
 | Menu entry | Workflow |
 |---|---|
@@ -96,7 +95,7 @@ All workflow codes belong to the `EasyWMS` namespace unless otherwise noted (`De
 | Paper confirmation | `EasyWMS.Picking_ConfirmPickingPaper_UI` |
 | Manual preparation | `EasyWMS.Expedition_ManualPreparation_UI` |
-### PTL Picking — `RFMenu_PickingPTLs`
+### PTL Picking - `RFMenu_PickingPTLs`
 | Menu entry | Workflow |
 |---|---|
@@ -107,7 +106,7 @@ All workflow codes belong to the `EasyWMS` namespace unless otherwise noted (`De
 | Equipment status | `EasyWMS.PTLsPickingPreparation_ManualEquipmentInfo_UI` |
 | Manual preparation | `EasyWMS.PTLsPickingPreparation_ManualPreparation_UI` |
-### Truck loading — `RFMenu_TruckLoad`
+### Truck loading - `RFMenu_TruckLoad`
 | Menu entry | Workflow |
 |---|---|
@@ -116,14 +115,14 @@ All workflow codes belong to the `EasyWMS` namespace unless otherwise noted (`De
 | Stock load | `EasyWMS.StockTruckLoad_GetLoads_UI` |
 | Parcel load | `Deliveries.Dlv_TruckLoad_GetLoads_UI` |
-### Undo preparation — `RFMenu_UndoPreparation`
+### Undo preparation - `RFMenu_UndoPreparation`
 | Menu entry | Workflow |
 |---|---|
 | Undo preparation | `EasyWMS.UndoPreparation_Main_PR` |
 | Undo excess | `EasyWMS.UndoExcess_Main_PR` |
-## 5. Replenishment — `RFMenu_Replenishment`
+## 5. Replenishment - `RFMenu_Replenishment`
 | Menu entry | Workflow |
 |---|---|
@@ -132,7 +131,7 @@ All workflow codes belong to the `EasyWMS` namespace unless otherwise noted (`De
 | By warehouse | `EasyWMS.Replenishment_GetAllProductLocationsByWarehouse_UI` |
 | By outbound order | `EasyWMS.Replenishment_GenerateTasksByOutboundOrder_UI` |
-## 6. Counts — `SharedMenu_Counts`
+## 6. Counts - `SharedMenu_Counts`
 | Menu entry | Workflow |
 |---|---|
@@ -140,7 +139,7 @@ All workflow codes belong to the `EasyWMS` namespace unless otherwise noted (`De
 | Physical count | `EasyWMS.Count_StockOnPhysicalLocation_UI` |
 | Informed count | `EasyWMS.Count_StockOnPhysicalLocation_Informed_UI` |
-## 7. Kits — `RFMenu_Kits`
+## 7. Kits - `RFMenu_Kits`
 | Menu entry | Workflow |
 |---|---|
@@ -148,7 +147,7 @@ All workflow codes belong to the `EasyWMS` namespace unless otherwise noted (`De
 | Assemble | `EasyWMS.KitAssembly_UI` |
 | Disassemble | `EasyWMS.KitDisassembly_UI` |
-## 8. Quality — `RFMenu_Quality`
+## 8. Quality - `RFMenu_Quality`
 | Menu entry | Workflow |
 |---|---|
@@ -157,7 +156,7 @@ All workflow codes belong to the `EasyWMS` namespace unless otherwise noted (`De
 | Unlock by item | `EasyWMS.Quality_UnlockByProduct_UI` |
 | Unlock by container/location | `EasyWMS.Quality_UnlockByLocationOrContainer_UI` |
-## 9. Groups — `RFMenu_Groups`
+## 9. Groups - `RFMenu_Groups`
 | Menu entry | Workflow |
 |---|---|
@@ -168,7 +167,7 @@ All workflow codes belong to the `EasyWMS` namespace unless otherwise noted (`De
 | Extraction without pack | `EasyWMS.Extraction_WithoutPack_UI` |
 | Change location | `EasyWMS.Ungroup_ChangeLocation_UI` |
-## 10. Utilities — `RFMenu_Utilities`
+## 10. Utilities - `RFMenu_Utilities`
 | Menu entry | Workflow |
 |---|---|
@@ -192,7 +191,7 @@ All workflow codes belong to the `EasyWMS` namespace unless otherwise noted (`De
 | Show cart | `EasyWMS.Utils_ShowCart_UI` |
 | My cart | `EasyWMS.Equipment_MyCart_UI` |
-### Remount / Unremount containers — `RFMenu_RemountUnRemountContainers`
+### Remount / Unremount containers - `RFMenu_RemountUnRemountContainers`
 | Menu entry | Workflow |
 |---|---|
@@ -201,7 +200,7 @@ All workflow codes belong to the `EasyWMS` namespace unless otherwise noted (`De
 | Unremount container | `EasyWMS.Container_UnremountContainer_UI` |
 | Unremount all containers | `EasyWMS.Container_UnremountAllContainers_UI` |
-## 11. Pick and Pass — `Menu_PickAndPass`
+## 11. Pick and Pass - `Menu_PickAndPass`
 | Menu entry | Workflow |
 |---|---|
@@ -211,7 +210,7 @@ All workflow codes belong to the `EasyWMS` namespace unless otherwise noted (`De
 | Picking | `EasyWMS.PickAndPass_Picking_Main_PR` |
 | Automatic task | `EasyWMS.PickAndPass_AutomaticAssignment_Main_UI` |
-## 12. Packaging — `Menu_Packaging` *(Multi-Carrier module)*
+## 12. Packaging - `Menu_Packaging` *(Multi-Carrier module)*
 | Menu entry | Workflow |
 |---|---|
@@ -222,7 +221,7 @@ All workflow codes belong to the `EasyWMS` namespace unless otherwise noted (`De
 | Move parcel | `Deliveries.Dlv_PackageManualMovement_PR` |
 | Bulk load | `Deliveries.Dlv_BulkLoad_UI` |
-### Reprint tracking number — `ReprintTrackingNumber_RFMenu`
+### Reprint tracking number - `ReprintTrackingNumber_RFMenu`
 | Menu entry | Workflow |
 |---|---|
@@ -231,16 +230,16 @@ All workflow codes belong to the `EasyWMS` namespace unless otherwise noted (`De
 ## Related
- [[application-dictionary]] — the Application Dictionary holds the Workflow entities referenced above ; overriding a menu entry is an AD operation
+- [[application-dictionary]] - the Application Dictionary holds the Workflow entities referenced above ; overriding a menu entry is an AD operation
- [[task]] — Tasks (menu 1) are the main RFT entry point in most deployments
+- [[task]] - Tasks (menu 1) are the main RFT entry point in most deployments
- [[reception]] — workflows under menu 2 drive the reception flows (Supplier, Blind, Return, ASN, Workstation)
+- [[reception]] - workflows under menu 2 drive the reception flows (Supplier, Blind, Return, ASN, Workstation)
- [[putaway]] — menu 3 and the automatic-assignment path in menu 1
+- [[putaway]] - menu 3 and the automatic-assignment path in menu 1
- [[picking]] — menu 4 covers all picking flavours (standard, manual, wave, virtual, PTL)
+- [[picking]] - menu 4 covers all picking flavours (standard, manual, wave, virtual, PTL)
- [[replenishment]] — menu 5 covers the four replenishment scopes (location, aisle, warehouse, by-order)
+- [[replenishment]] - menu 5 covers the four replenishment scopes (location, aisle, warehouse, by-order)
- [[count]] — menu 6 physical-count workflows
+- [[count]] - menu 6 physical-count workflows
- [[shipping]] — menu 4 packing + undo-preparation close the shipping loop on the RFT
+- [[shipping]] - menu 4 packing + undo-preparation close the shipping loop on the RFT
- [[kits]] — menu 7 assembly / disassembly
+- [[kits]] - menu 7 assembly / disassembly
- [[quality-control]] — menu 8 lock / unlock
+- [[quality-control]] - menu 8 lock / unlock
- [[group]] — menu 9 group and extraction flows
+- [[group]] - menu 9 group and extraction flows
- [[container]] — `Utilities → Remount/Unremount` flows manipulate the container tree
+- [[container]] - `Utilities → Remount/Unremount` flows manipulate the container tree
- [[multi-carrier]] — menu 12 only appears when the Multi-Carrier (`Deliveries`) module is enabled
+- [[multi-carrier]] - menu 12 only appears when the Multi-Carrier (`Deliveries`) module is enabled
@@ -2,7 +2,7 @@
 title: "Security"
 type: architecture
 sources:
-  - areas/security/index.md (404 — compiled from cross-source knowledge)
+  - areas/security/index.md (404 - compiled from cross-source knowledge)
  - areas/parameters.md
  - areas/inventory_management/stations/roles.md
  - modules cross-source knowledge
@@ -52,8 +52,8 @@ Password policies (minimum length, complexity, expiry) are configurable in syste
 Operators can log in to RF terminals by scanning a personal QR Code instead of typing their credentials:
- The QR Code contains **anonymized data** — a third party who finds a lost QR Code cannot derive the operator's username or password from it
+- The QR Code contains **anonymized data** - a third party who finds a lost QR Code cannot derive the operator's username or password from it
- **Each reprint invalidates the previous QR Code** — there is no revocation mechanism other than reprinting
+- **Each reprint invalidates the previous QR Code** - there is no revocation mechanism other than reprinting
 - QR Code login is **incompatible with SSO**: a user configured for SSO cannot use QR Code login
 ### SSO (Single Sign-On)
@@ -61,7 +61,7 @@ Operators can log in to RF terminals by scanning a personal QR Code instead of t
 EasyWMS supports SSO using the **SAML V2.0 protocol**. No other SSO protocol is supported.
 - SSO is available on both the **PC (SmartUI)** and **RF terminal** interfaces
- When SSO is enabled for a user account, EasyWMS will **not accept any other login method** for that user — standard username/password login is disabled
+- When SSO is enabled for a user account, EasyWMS will **not accept any other login method** for that user - standard username/password login is disabled
 - **SSO and QR Code are mutually exclusive**: enabling SSO on a user account prevents them from using QR Code login
 - Configuration requires setting up the SAML identity provider (IDP) in EasyWMS system parameters and mapping EasyWMS roles to IDP groups
@@ -73,7 +73,7 @@ Authorization is evaluated at two levels:
 Each Role grants access to specific navigation areas. A user who cannot access a menu item cannot reach the underlying Commands or Views from the UI.
 ### Command-Level Access
-Individual AD Commands can be restricted to specific roles. This is enforced server-side — even if a user constructs an API call directly, the command execution checks the caller's role.
+Individual AD Commands can be restricted to specific roles. This is enforced server-side - even if a user constructs an API call directly, the command execution checks the caller's role.
 ### Data Scope (Owner Isolation)
 When the **Owner Extensions** module is active, data is isolated by owner:
@@ -161,10 +161,10 @@ The SCEM (Supply Chain Event Management) module allows subscribing to operationa
 ## Related
- [Overview](overview.md) — System architecture and deployment model
+- [Overview](overview.md) - System architecture and deployment model
- [Application Dictionary](application-dictionary.md) — Role and permission configuration via AD
+- [Application Dictionary](application-dictionary.md) - Role and permission configuration via AD
- [Transactions](../concepts/transactions.md) — Audit trail for all operations
+- [Transactions](../concepts/transactions.md) - Audit trail for all operations
- [Quality Control](../concepts/quality-control.md) — Stock lock system
+- [Quality Control](../concepts/quality-control.md) - Stock lock system
- [Owner Extensions](../modules/owner-extensions.md) — Multi-owner data isolation
+- [Owner Extensions](../modules/owner-extensions.md) - Multi-owner data isolation
- [3PL Portal](../modules/3pl-portal.md) — External client access model
+- [3PL Portal](../modules/3pl-portal.md) - External client access model
- [Supply Chain Event Management](../modules/supply-chain-event.md) — Notification subscriptions
+- [Supply Chain Event Management](../modules/supply-chain-event.md) - Notification subscriptions
@@ -24,9 +24,9 @@ last_compiled: "2026-04-10"
 EasyWMS uses two related but distinct entities for commercial master data: **Owner** and **Account**.
- An **Owner** is the entity that owns the stock in the warehouse (a sales company, the organization itself, or — in 3PL contexts — an external client). Every stock record has an owner. Owners can mix stock with each other only when mixing is explicitly enabled.
+- An **Owner** is the entity that owns the stock in the warehouse (a sales company, the organization itself, or - in 3PL contexts - an external client). Every stock record has an owner. Owners can mix stock with each other only when mixing is explicitly enabled.
- An **Account** is a delivery point / customer of the warehouse — the entity to which a shipping order's stock is destined. Accounts represent end-customers or delivery addresses; they are referenced on outbound orders to control carrier preferences, label formats, and FEFO rules.
+- An **Account** is a delivery point / customer of the warehouse - the entity to which a shipping order's stock is destined. Accounts represent end-customers or delivery addresses; they are referenced on outbound orders to control carrier preferences, label formats, and FEFO rules.
 The two are distinct: an owner holds inventory rights; an account receives shipments. A single owner can have many accounts (multiple delivery points). In 3PL deployments with Owner Extensions enabled, every receipt order, shipping order, and master data entity must be assigned to an owner.
@@ -45,7 +45,7 @@ The two are distinct: an owner holds inventory rights; an account receives shipm
 ### Owner mixing rules
 By default, new owners are created with mixing **disabled**. Mixing can be enabled per owner. Additionally, specific owner exclusions can be added (preventing mixing with specific other owners). Mixing checks apply to: items, item types, item families, logistic attributes, and owners simultaneously.
-In **automatic warehouses**, mixing restrictions are hard-enforced — the system will not allow a container to be stored if mixing rules are violated. In **manual warehouses**, operators can override mixing warnings.
+In **automatic warehouses**, mixing restrictions are hard-enforced - the system will not allow a container to be stored if mixing rules are violated. In **manual warehouses**, operators can override mixing warnings.
 ---
@@ -84,10 +84,10 @@ In **automatic warehouses**, mixing restrictions are hard-enforced — the syste
 ## Related
- [[stock]] — every stock record has an owner; owner mixing rules determine co-location eligibility
+- [[stock]] - every stock record has an owner; owner mixing rules determine co-location eligibility
- [[order-outbound]] — shipping orders reference accounts (delivery destination) and can reference owner
+- [[order-outbound]] - shipping orders reference accounts (delivery destination) and can reference owner
- [[order-inbound]] — receipt orders reference owners when Owner Extensions is active
+- [[order-inbound]] - receipt orders reference owners when Owner Extensions is active
- [[owner-extensions]] — prerequisite module for mandatory owner assignment; enables per-owner data isolation
+- [[owner-extensions]] - prerequisite module for mandatory owner assignment; enables per-owner data isolation
- [[billing-3pl]] — 3PL billing contracts are created per owner
+- [[billing-3pl]] - 3PL billing contracts are created per owner
- [[3pl-portal]] — 3PL portal access is filtered per owner; user group assignment controls visibility
+- [[3pl-portal]] - 3PL portal access is filtered per owner; user group assignment controls visibility
- [[erp-interface]] — OWN and ACC messages manage owner/account master data from ERP
+- [[erp-interface]] - OWN and ACC messages manage owner/account master data from ERP
@@ -92,9 +92,9 @@ When the Multi-Carrier module is active, a **Delivery** combines carrier + consi
 ## Related
- [[shipping]] — shipping orders reference carriers; routes and loads assign containers to carriers
+- [[shipping]] - shipping orders reference carriers; routes and loads assign containers to carriers
- [[order-outbound]] — SOR message can include carrier assignment; carrier determines delivery structure
+- [[order-outbound]] - SOR message can include carrier assignment; carrier determines delivery structure
- [[labels]] — carrier labels (tracking barcodes) printed during Multi-Carrier packaging
+- [[labels]] - carrier labels (tracking barcodes) printed during Multi-Carrier packaging
- [[multi-carrier]] — full carrier integration: packaging stations, tracking, delivery lifecycle
+- [[multi-carrier]] - full carrier integration: packaging stations, tracking, delivery lifecycle
- [[yard-management]] — carrier appointments at yard checkpoints and docks
+- [[yard-management]] - carrier appointments at yard checkpoints and docks
- [[erp-interface]] — CAR message syncs carrier master; RUT message sends route data
+- [[erp-interface]] - CAR message syncs carrier master; RUT message sends route data
@@ -24,8 +24,8 @@ last_compiled: "2026-04-10"
 **Consolidation** in EasyWMS is the process of moving stock from multiple partially-full containers into a single destination container, eliminating peaks and optimizing space usage in the warehouse. It is designed to run during **periods of inactivity**, interfering minimally with active warehouse operations.
 Two types of consolidation exist:
-1. **Stock consolidation (warehouse)** — covered here. Compacts incomplete containers in storage to reduce the number of occupied locations.
+1. **Stock consolidation (warehouse)** - covered here. Compacts incomplete containers in storage to reduce the number of occupied locations.
-2. **Shipping consolidation** — reorganizes prepared stock for outbound orders (see [shipping](../concepts/shipping.md)). Not covered here.
+2. **Shipping consolidation** - reorganizes prepared stock for outbound orders (see [shipping](../concepts/shipping.md)). Not covered here.
 Stock consolidation applies to both **manual** and **automatic** warehouses.
@@ -137,9 +137,9 @@ Containers arrive sequenced at the PK:
 | Capacity exceeded at destination | Line adjusted; source remains non-empty |
 **Transactions:**
- `CON.MOVE` — container location changes (warehouse → PK → warehouse)
+- `CON.MOVE` - container location changes (warehouse → PK → warehouse)
- `STK.MOVE` — stock moved from source to destination container
+- `STK.MOVE` - stock moved from source to destination container
- `CON.SEND.L&F` — if empty source container is sent to Lost & Found
+- `CON.SEND.L&F` - if empty source container is sent to Lost & Found
 ### Consolidation at Picking Conveyor with Manual Preparation Zones (MP)
@@ -192,8 +192,8 @@ For consolidation to work correctly:
 ## Related
- [[container]] — Consolidation moves stock between containers; source containers are emptied, destination receives all stock
+- [[container]] - Consolidation moves stock between containers; source containers are emptied, destination receives all stock
- [[location]] — Consolidation frees up locations by eliminating partial containers
+- [[location]] - Consolidation frees up locations by eliminating partial containers
- [[stock]] — STK.MOVE transactions update stock records during consolidation
+- [[stock]] - STK.MOVE transactions update stock records during consolidation
- [[task]] — Consolidation generates source/destination task pairs; priority set by process priority
+- [[task]] - Consolidation generates source/destination task pairs; priority set by process priority
- [[shipping]] — Shipping consolidation (distinct concept) reorganizes prepared stock for outbound orders
+- [[shipping]] - Shipping consolidation (distinct concept) reorganizes prepared stock for outbound orders
@@ -36,9 +36,9 @@ last_compiled: "2026-04-17"
 ## Overview
-A **LPN** (License Plate Number) is the fundamental unit of physical storage in EasyWMS — a box, pallet, or any other container that holds stock. Every unit of stock in the warehouse lives inside a LPN; the LPN is what moves, what gets located, locked, picked, and shipped. In identification contexts, the LPN is always labeled (Code 128 or GS1-128) and its code uniquely identifies it system-wide.
+A **LPN** (License Plate Number) is the fundamental unit of physical storage in EasyWMS - a box, pallet, or any other container that holds stock. Every unit of stock in the warehouse lives inside a LPN; the LPN is what moves, what gets located, locked, picked, and shipped. In identification contexts, the LPN is always labeled (Code 128 or GS1-128) and its code uniquely identifies it system-wide.
-The LPN is the bridge between the physical world (a pallet on a rack) and the logical world (stock records, tasks, orders). EasyWMS tracks every LPN's location, weight, status, contents, and relationships (stacked, matched, client-linked) in real time. All WMS movements — reception, putaway, picking, replenishment, shipping — are expressed as operations on LPNs.
+The LPN is the bridge between the physical world (a pallet on a rack) and the logical world (stock records, tasks, orders). EasyWMS tracks every LPN's location, weight, status, contents, and relationships (stacked, matched, client-linked) in real time. All WMS movements - reception, putaway, picking, replenishment, shipping - are expressed as operations on LPNs.
 The term "container" in EasyWMS source documentation is synonymous with LPN. The entity name in the Application Dictionary is **Container**; the UI and documentation use both terms interchangeably.
@@ -52,9 +52,9 @@ The term "container" in EasyWMS source documentation is synonymous with LPN. The
 | **Type** | Physical LPN type (e.g. EuroPallet, American pallet, box). Defines dimensional and weight constraints. Configured in EasyS. |
 | **Location** | Current warehouse location where the LPN is stored. |
 | **Height** | Measured in mm. Set by: PLC/SCA gauge at PIE station, user input during reception, ASN pre-notification, or manual screen edit. Includes the max height of any LPN stacked on top. |
-| **Occupation percentage** | % of LPN capacity used by its stock. Not calculated automatically by EasyWMS — editable from the LPN view or set by the user. |
+| **Occupation percentage** | % of LPN capacity used by its stock. Not calculated automatically by EasyWMS - editable from the LPN view or set by the user. |
 | **Is client LPN** | Boolean. `true` if the LPN's stock is assigned to a shipping order (outbound). Drives picking, shipping, and consolidation logic. |
-| **Division type** | Internal partition configuration (see [Division Types](#division-types)). Only supported in automatic warehouses. LPNs with divisions only accept entry and picking tasks — shipping tasks are invalid. Content must be fully picked out before division LPN is used for shipping. |
+| **Division type** | Internal partition configuration (see [Division Types](#division-types)). Only supported in automatic warehouses. LPNs with divisions only accept entry and picking tasks - shipping tasks are invalid. Content must be fully picked out before division LPN is used for shipping. |
 | **Status** | Current lifecycle state (see [Lifecycle & Statuses](#lifecycle--statuses)). |
 ### Weight Properties
@@ -89,7 +89,7 @@ LPN types define the physical characteristics of an empty LPN. Configured in the
 | Maximum weight | kg | Max safe weight when loaded |
 | Collapse | mm | Max width deviation due to load collapse. Effective width = Width + 2 × Collapse. |
-The collapse parameter matters for automatic warehouse location sizing — the system checks effective width when searching for a putaway location.
+The collapse parameter matters for automatic warehouse location sizing - the system checks effective width when searching for a putaway location.
 **UI path:** EasyS tool (not EasyWMS web UI).
@@ -258,7 +258,7 @@ Non-pre-notified stock arriving from a supplier in containers with multiple item
 | **Receipt and putaway** | Stock received on equipment; location search runs immediately for putaway. |
 | **Receipt on stage** | Stock registered in a stage; putaway done later by another operator or batch. |
-A third variant: **exclusive reserve** — stock can be reserved for a specific shipping order at receipt time (configured via ROR message from ERP, see [erp-interface.md](../concepts/erp-interface.md)). The `CONFIRM_EXCLUSIVE_RESERVE_ASSIGNMENT` parameter controls whether the user must manually select the shipping order when multiple compatible orders exist.
+A third variant: **exclusive reserve** - stock can be reserved for a specific shipping order at receipt time (configured via ROR message from ERP, see [erp-interface.md](../concepts/erp-interface.md)). The `CONFIRM_EXCLUSIVE_RESERVE_ASSIGNMENT` parameter controls whether the user must manually select the shipping order when multiple compatible orders exist.
 **ERP message sent at end of receipt:** `REF`
 **Transactions:** `CON.RECEP` (per container), `STK.RECEP` (per stock line)
@@ -274,7 +274,7 @@ Unplanned, non-pre-notified stock with no entry order. A receipt is auto-created
 ### Partitioned Container Receipt
-Both supplier and blind modes support receiving containers with internal partitions. Destination must always be an **automatic warehouse** — containers must be transported to a PIE or picking station after reception.
+Both supplier and blind modes support receiving containers with internal partitions. Destination must always be an **automatic warehouse** - containers must be transported to a PIE or picking station after reception.
 ---
@@ -291,19 +291,19 @@ Available actions on LPNs (full list from web UI):
 | LPN type modification | Change the LPN type. Only for **empty** LPNs. | PC |
 | Division type modification | Change division type. Only for **empty** LPNs. | PC |
 | Delete division | Remove division from LPN. Only for **empty** LPNs. | PC |
-| Location change | Change LPN's recorded location. Does NOT create a movement task — only updates the data record. Treated as [manual movement](../concepts/manual-movements.md). In open APS FIFO channels, only accessible locations shown. | PC / RFT |
+| Location change | Change LPN's recorded location. Does NOT create a movement task - only updates the data record. Treated as [manual movement](../concepts/manual-movements.md). In open APS FIFO channels, only accessible locations shown. | PC / RFT |
 | Send to Lost & Found | Send LPN to virtual L&F location when physical location unknown. In APS FIFO, only accessible or last LPN in channel. Stacked LPN: entire partial block (selected LPN + children) goes to L&F. | PC |
 | Relocation (automatic warehouses) | Change physical location via system-directed move: Automatic (putaway strategies), To an aisle (putaway strategies in selected aisle), To a location (no strategies, physical compatibility only), To a level (putaway strategies in selected level). | PC |
 | Mark as full / not full | Flag LPN as full so replenishment at PK conveyor skips it. Manual additions still possible. | PC |
 | Mark division as full / not full | Same as above for a specific division within a LPN. | PC |
-| Shipping order unassignment | Unlink LPN from its shipping order. Works for mapped, prepared, or loaded LPN. No movement task created — operator is responsible for physical move. | PC |
+| Shipping order unassignment | Unlink LPN from its shipping order. Works for mapped, prepared, or loaded LPN. No movement task created - operator is responsible for physical move. | PC |
 | Extraction request to PK conveyor | Request extraction from a station to a Picking conveyor for an action outside the system. | PC |
 | Request empty LPN to PK | Request empty LPN(s) of specific type/divisions to be sent to a Picking conveyor. | PC |
 | Extraction request to PS conveyor | Request extraction to an Outbound conveyor (PS). | PC |
 | Request empty LPN to PS | Extract empty LPN to Outbound conveyor (often to fill outside PK, e.g., for reception). | PC |
-| Set depth coordinate | APS3D only — manually set depth coordinate for a LPN in an APS location. Superadmin only. | PC |
+| Set depth coordinate | APS3D only - manually set depth coordinate for a LPN in an APS location. Superadmin only. | PC |
 | Manual compacting | APS/APSFIFO: compact LPN when free positions exist in front. | PC |
-| Exchange LPN | APS3D only — swap a LPN in channel for one outside; must be same type. Superadmin only. | PC |
+| Exchange LPN | APS3D only - swap a LPN in channel for one outside; must be same type. Superadmin only. | PC |
 | Consulting equipment LPNs (My LPNs) | View all LPNs on own equipment: code, type, status, stock lines (item, qty, UoM, logistic attributes). Can unload or reject LPNs from this view. | RFT |
 | Putaway search location trace | Report of last location search for this LPN. Shows strategies applied, excluded aisles, routes with issues, reserve percentages, stock line details. Superadmin sees full technical trace. | PC |
 | Stack / Match LPNs | Group LPNs vertically (stack) or horizontally (match). | RFT |
@@ -322,7 +322,7 @@ EasyWMS interprets the following **GS1 Application Identifiers (AI)** on existin
 | AI | Meaning |
 |---|---|
-| (00) | SSCC — Serial Shipping Container Code |
+| (00) | SSCC - Serial Shipping Container Code |
 | (01) | GTIN grouping code / DUN14 |
 | (02) | EAN |
 | (10) | Lot number |
@@ -343,7 +343,7 @@ Procedure:
 2. Fill in the desired **prefix**
 3. **Save**
-Existing LPN codes are not rewritten — only containers generated after the change use the new prefix.
+Existing LPN codes are not rewritten - only containers generated after the change use the new prefix.
 ---
@@ -373,20 +373,20 @@ All container events generate transactions recorded in EasyWMS audit trail:
 |---|---|---|
 | `CON.ASN.001` | Container received for an ASN advance notice order | → `ASO` |
 | `CON.CNL.ASN` | Pre-notified container deleted or rejected | → `ASK` |
-| `CON.COC` | Client container closed at Preparation Zone (MP) | — |
+| `CON.COC` | Client container closed at Preparation Zone (MP) | - |
-| `CON.COS.001` | Container extracted to Outbound Conveyor (PS) | — |
+| `CON.COS.001` | Container extracted to Outbound Conveyor (PS) | - |
-| `CON.CREATE` | Container created manually, from view, for picking, or during count | — |
+| `CON.CREATE` | Container created manually, from view, for picking, or during count | - |
-| `CON.DELETE` | Container deleted (from L&F or after count) | — |
+| `CON.DELETE` | Container deleted (from L&F or after count) | - |
-| `CON.LOAD` | Container loaded during truck loading | — |
+| `CON.LOAD` | Container loaded during truck loading | - |
-| `CON.LOCATE` | Container moved to storage location via putaway task | — |
+| `CON.LOCATE` | Container moved to storage location via putaway task | - |
-| `CON.MOVE` | Container moved without putaway task (or to destination with task) | — |
+| `CON.MOVE` | Container moved without putaway task (or to destination with task) | - |
 | `CON.PIE` | Container entered via PIE station | → `ASO` |
-| `CON.PRINT` | Packing list printed with client container label | — |
+| `CON.PRINT` | Packing list printed with client container label | - |
-| `CON.RECEP` | Container received (supplier, return, or blind reception) | — |
+| `CON.RECEP` | Container received (supplier, return, or blind reception) | - |
-| `CON.SEND.L&F` | Container sent to Lost & Found | — |
+| `CON.SEND.L&F` | Container sent to Lost & Found | - |
-| `CON.SHIPPED` | Container shipped (shipping order closed) | — |
+| `CON.SHIPPED` | Container shipped (shipping order closed) | - |
-| `CON.SHIPPING` | Shipping task confirmed (container assigned to destination) | — |
+| `CON.SHIPPING` | Shipping task confirmed (container assigned to destination) | - |
-| `CON.VASDONE` | VAS (Value Added Service) executed on container | — |
+| `CON.VASDONE` | VAS (Value Added Service) executed on container | - |
 For detailed transaction data fields (Site, User, ContainerCode, LocationCode, etc.), see [concepts/transactions.md](../concepts/transactions.md).
@@ -412,7 +412,7 @@ LPN-related ERP messages (all documented in [concepts/erp-interface.md](../conce
 | Path | Description |
 |---|---|
-| `Warehouse > LPN` | Main LPN management view — all operations |
+| `Warehouse > LPN` | Main LPN management view - all operations |
 | `Workstations > Picking` | LPN view from picking workstation perspective |
 | `Masters > Lock types` → "LPN lock types" | Manage lock type definitions |
 | `Masters > Division LPN types` | Manage division type definitions |
@@ -453,7 +453,7 @@ LPN-related ERP messages (all documented in [concepts/erp-interface.md](../conce
 **Cannot modify LPN type or division:**
 - Symptom: Type/division change rejected.
- Cause: LPN is not empty — contains stock.
+- Cause: LPN is not empty - contains stock.
 - Solution: Move or pick out all stock first, then change the type.
 **Putaway location not found for stacked LPN:**
@@ -470,21 +470,21 @@ LPN-related ERP messages (all documented in [concepts/erp-interface.md](../conce
 ## Related
- [concepts/location.md](../concepts/location.md) — Locations where LPNs are stored; capacity, FIFO, dynamic, APS types
+- [concepts/location.md](../concepts/location.md) - Locations where LPNs are stored; capacity, FIFO, dynamic, APS types
- [concepts/stock.md](../concepts/stock.md) — Stock lines that reside inside LPNs; adjustments, reserves
+- [concepts/stock.md](../concepts/stock.md) - Stock lines that reside inside LPNs; adjustments, reserves
- [concepts/reception.md](../concepts/reception.md) — All reception modes; how LPNs are created and registered
+- [concepts/reception.md](../concepts/reception.md) - All reception modes; how LPNs are created and registered
- [concepts/putaway.md](../concepts/putaway.md) — Strategies that assign LPNs to storage locations
+- [concepts/putaway.md](../concepts/putaway.md) - Strategies that assign LPNs to storage locations
- [concepts/task.md](../concepts/task.md) — Tasks drive LPN movements (putaway, picking, replenishment, shipping)
+- [concepts/task.md](../concepts/task.md) - Tasks drive LPN movements (putaway, picking, replenishment, shipping)
- [concepts/shipping.md](../concepts/shipping.md) — Client LPN lifecycle through picking, consolidation, loading, shipping
+- [concepts/shipping.md](../concepts/shipping.md) - Client LPN lifecycle through picking, consolidation, loading, shipping
- [concepts/order-inbound.md](../concepts/order-inbound.md) — Inbound orders (ASN, receipt orders) that pre-notify LPNs
+- [concepts/order-inbound.md](../concepts/order-inbound.md) - Inbound orders (ASN, receipt orders) that pre-notify LPNs
- [concepts/order-outbound.md](../concepts/order-outbound.md) — Shipping orders that client LPNs are assigned to
+- [concepts/order-outbound.md](../concepts/order-outbound.md) - Shipping orders that client LPNs are assigned to
- [concepts/labels.md](../concepts/labels.md) — LPN label formats, GS1-128, printing configuration
+- [concepts/labels.md](../concepts/labels.md) - LPN label formats, GS1-128, printing configuration
- [concepts/manual-movements.md](../concepts/manual-movements.md) — Manual location changes for LPNs
+- [concepts/manual-movements.md](../concepts/manual-movements.md) - Manual location changes for LPNs
- [concepts/consolidation.md](../concepts/consolidation.md) — Container consolidation: stock from multiple partial LPNs merged into one destination container
+- [concepts/consolidation.md](../concepts/consolidation.md) - Container consolidation: stock from multiple partial LPNs merged into one destination container
- [concepts/quality-control.md](../concepts/quality-control.md) — Quality locks applied to stock inside LPNs; lock-by-container scope
+- [concepts/quality-control.md](../concepts/quality-control.md) - Quality locks applied to stock inside LPNs; lock-by-container scope
- [concepts/transactions.md](../concepts/transactions.md) — Full CON.* and STK.* transaction reference
+- [concepts/transactions.md](../concepts/transactions.md) - Full CON.* and STK.* transaction reference
- [concepts/erp-interface.md](../concepts/erp-interface.md) — ASN, ROR, REF, ASO, ASK message definitions
+- [concepts/erp-interface.md](../concepts/erp-interface.md) - ASN, ROR, REF, ASO, ASK message definitions
- [modules/agv.md](../modules/agv.md) — AGV equipment that transports LPNs in automated warehouses
+- [modules/agv.md](../modules/agv.md) - AGV equipment that transports LPNs in automated warehouses
- [modules/pallet-shuttle.md](../modules/pallet-shuttle.md) — Pallet shuttle system managing compact LPN storage
+- [modules/pallet-shuttle.md](../modules/pallet-shuttle.md) - Pallet shuttle system managing compact LPN storage
- [modules/vas.md](../modules/vas.md) — Value Added Services applied to LPNs (`CON.VASDONE`)
+- [modules/vas.md](../modules/vas.md) - Value Added Services applied to LPNs (`CON.VASDONE`)
- [modules/aps3d.md](../modules/aps3d.md) — 3D APS storage: depth coordinates, compacting, LPN exchange
+- [modules/aps3d.md](../modules/aps3d.md) - 3D APS storage: depth coordinates, compacting, LPN exchange
@@ -49,9 +49,9 @@ last_compiled: "2026-04-17"
 A **count** (also called inventory or stock take) in EasyWMS is a formal process for verifying that the physical stock in the warehouse matches the quantities recorded in the system. When discrepancies are found, the system adjusts its records accordingly and notifies the ERP.
 EasyWMS supports three fundamental counting approaches:
- **Guided counts** — a count order is created (from the WMS interface or by ERP messaging), tasks are generated, and operators follow those tasks with their RFT.
+- **Guided counts** - a count order is created (from the WMS interface or by ERP messaging), tasks are generated, and operators follow those tasks with their RFT.
- **Physical count** — an unguided, operator-initiated blind count of a specific location directly from the RFT, without a prior order.
+- **Physical count** - an unguided, operator-initiated blind count of a specific location directly from the RFT, without a prior order.
- **Cycle count** — automated rolling inventory that divides counting across many days, integrating inventory into daily warehouse operations without shutting down the warehouse.
+- **Cycle count** - automated rolling inventory that divides counting across many days, integrating inventory into daily warehouse operations without shutting down the warehouse.
 Counts can be performed in manual warehouses (operators walk to locations) and automatic warehouses (containers are extracted to a picking conveyor / workstation).
@@ -73,8 +73,8 @@ A single count order can mix lines of different types.
 | Method | Who initiates | Order required | Auto-adjusts |
 |---|---|---|---|
-| **Guided count — from WMS interface** | Warehouse manager (PC) | Yes | No (ERP notified via STV per diff) |
+| **Guided count - from WMS interface** | Warehouse manager (PC) | Yes | No (ERP notified via STV per diff) |
-| **Guided count — from ERP (COR message)** | ERP | Yes | No (ERP notified via COF at close) |
+| **Guided count - from ERP (COR message)** | ERP | Yes | No (ERP notified via COF at close) |
 | **Physical count (RF)** | Operator from RFT | No | Yes (immediate) |
 | **Cycle count** | Scheduler job | Auto-generated | No (ERP notified via STV) |
 | **Automatic warehouse count** | Manager assigns PK | Yes | No |
@@ -128,7 +128,7 @@ Closing can be **automatic** (`AUTOCLOSE_COUNT_ORDERS` parameter) or manual. Ord
 ---
-## Guided Count — Execution
+## Guided Count - Execution
 ### Task Generation at Release
@@ -145,14 +145,14 @@ Locations configured as "does not allow inventory" in EasyS are skipped. Locks o
 ### Blind vs. Informed Mode
 For **location count** lines, the **Is Informed** flag (FR : `Est renseigné`) determines the counting mode:
- **Blind count** — operator enters quantities without seeing current system values (default). Operator must enter item, quantity, logistic attributes from scratch.
+- **Blind count** - operator enters quantities without seeing current system values (default). Operator must enter item, quantity, logistic attributes from scratch.
- **Informed count** — system shows current recorded stock; operator adjusts as needed.
+- **Informed count** - system shows current recorded stock; operator adjusts as needed.
 Item counts and container counts are always blind.
-**Per-line setting.** `Est renseigné` is a **per-line** toggle, not a per-order toggle — within the same count order, some lines (e.g. the picking aisles) can be `Informed` while others (e.g. the reserve) stay blind.
+**Per-line setting.** `Est renseigné` is a **per-line** toggle, not a per-order toggle - within the same count order, some lines (e.g. the picking aisles) can be `Informed` while others (e.g. the reserve) stay blind.
-> If the `Est renseigné` column is missing from the count-line grid : select a line and click **"Visibilité"**. If it is still hidden, the grid's visibility condition must be relaxed — edit the `CountOrderLineVList` view and comment out (`/* … */`) the visibility condition, forcing it to `true`.
+> If the `Est renseigné` column is missing from the count-line grid : select a line and click **"Visibilité"**. If it is still hidden, the grid's visibility condition must be relaxed - edit the `CountOrderLineVList` view and comment out (`/* … */`) the visibility condition, forcing it to `true`.
 ### Counting items with serial numbers
@@ -163,7 +163,7 @@ When an item is counted on an attribute unique per piece (a serial number) :
 3. Click **"Terminé"** when every piece has a serial.
 4. Enter the next item of the location, or click **"Fin"** if the location is done.
-The WMS then reports that the original (no-serial) item line was not found — click **"Introuvable"** : this removes the no-serial stock line and creates the new serialized stock lines in its place.
+The WMS then reports that the original (no-serial) item line was not found - click **"Introuvable"** : this removes the no-serial stock line and creates the new serialized stock lines in its place.
 ### Count in Automatic Warehouse (Workstation)
@@ -186,12 +186,12 @@ For picking locations with labeled partitions assigned per item (dedicated picki
 - Reassign partitions to items during the count
 Parameters:
- `UNLOAD_CREATE_PRODUCT_LOCATION` — when active, auto-creates PDL assignment for a newly counted item
+- `UNLOAD_CREATE_PRODUCT_LOCATION` - when active, auto-creates PDL assignment for a newly counted item
- `ALLOW_DYNAMIC_UNASSIGNED_PARTITION` — allows dynamically unassigning empty partitions during count
+- `ALLOW_DYNAMIC_UNASSIGNED_PARTITION` - allows dynamically unassigning empty partitions during count
 ---
-## Physical Count (RF — No Order Required)
+## Physical Count (RF - No Order Required)
 The **Physical Count** is a fast, location-by-location blind count initiated directly from the RFT. No count order is needed.
@@ -250,9 +250,9 @@ Count orders generated by cycle count **cannot be re-released after cancellation
 ### Iteration States
- **On progress** — active iteration running
+- **On progress** - active iteration running
- **Finished** — iteration end date passed (transitions next day)
+- **Finished** - iteration end date passed (transitions next day)
- **Canceled** — manually terminated early
+- **Canceled** - manually terminated early
 Schedules can be **enabled/disabled**. A schedule with an active iteration cannot be disabled.
@@ -332,15 +332,15 @@ For counts **not** created by the ERP (manual WMS counts, physical counts, cycle
 | Count line shows conflict icon (no inventory allowed) | Location not flagged for inventory in EasyS | Fix location config in EasyS or delete the line |
 | COF message not sent after close | Count originated from COR and has pending adjustments (double validation) | Validate or cancel all pending adjustments |
 | Cycle count generates uneven task distribution | Volatile stock levels change mid-iteration (especially item schedules) | Expected behavior; adjust schedule parameters if needed |
-| Cannot re-release a cycle count after cancel | By design — cycle count orders are non-re-releasable | Create a new manual count for the affected locations |
+| Cannot re-release a cycle count after cancel | By design - cycle count orders are non-re-releasable | Create a new manual count for the affected locations |
 ---
 ## Related
- [[stock-adjustment]] — Count discrepancies trigger STK.ADJ adjustments; double validation applies to both
+- [[stock-adjustment]] - Count discrepancies trigger STK.ADJ adjustments; double validation applies to both
- [[stock]] — Count validates and corrects stock records; see STV/STK.ADJ transactions
+- [[stock]] - Count validates and corrects stock records; see STV/STK.ADJ transactions
- [[location]] — Location "allows inventory" flag governs whether counting tasks are generated
+- [[location]] - Location "allows inventory" flag governs whether counting tasks are generated
- [[container]] — Container count type counts an LPN and all its stock
+- [[container]] - Container count type counts an LPN and all its stock
- [[product-item]] — Item count type; count profile on item controls double validation
+- [[product-item]] - Item count type; count profile on item controls double validation
- [[task]] — Count tasks (TSK.COU) follow the standard task lifecycle
+- [[task]] - Count tasks (TSK.COU) follow the standard task lifecycle
@@ -4,7 +4,7 @@ type: concept
 sources:
  - areas/crossdocking/crossdocking_manual/index.md
  - areas/crossdocking/crossdocking_manual/crossdocking_warehouse.md
-  - areas/crossdocking/crossdocking_manual/crossdocking_opportunity.md (404 — sourced from index.md description)
+  - areas/crossdocking/crossdocking_manual/crossdocking_opportunity.md (404 - sourced from index.md description)
  - areas/putaway/putaway_admin/index.md (Group by SO/Route strategy type)
  - sources/archives/06_Gestion_cross_docking.md
 related:
@@ -38,8 +38,8 @@ Both types apply to containers, stacked containers, carts, and loose stock recei
 When an operator is about to putaway received stock/containers, EasyWMS checks if any unreleased or in-preparation shipping order needs that stock. If yes, instead of going to bulk storage, the stock is directed straight to the dock, stage, or buffer associated with the shipping order.
 The process triggers at two moments:
-1. **After receipt into equipment** — operator is ready to putaway what was received
+1. **After receipt into equipment** - operator is ready to putaway what was received
-2. **When preparing to putaway from a reception stage** — stock received in a staging area is evaluated for direct transfer
+2. **When preparing to putaway from a reception stage** - stock received in a staging area is evaluated for direct transfer
 ### Conditions and Eligibility
@@ -73,7 +73,7 @@ For **cutting stock items** in non-consolidating conversions:
 ### Concept (Warehouse)
-If opportunity crossdocking is not possible (no shipping order needing immediate routing, or the stock quantity exceeds a single order's need), EasyWMS evaluates **crossdocking to warehouse**: the stock is placed in dedicated **crossdocking locations** near the shipping area. When the shipping order is eventually released, these crossdocking locations are consulted first during stock assignment — ensuring minimum travel distance for shipping.
+If opportunity crossdocking is not possible (no shipping order needing immediate routing, or the stock quantity exceeds a single order's need), EasyWMS evaluates **crossdocking to warehouse**: the stock is placed in dedicated **crossdocking locations** near the shipping area. When the shipping order is eventually released, these crossdocking locations are consulted first during stock assignment - ensuring minimum travel distance for shipping.
 The stock is not yet assigned to any shipping order during the crossdocking-to-warehouse placement. The link to the order happens at release time.
@@ -94,7 +94,7 @@ For crossdocking to warehouse to execute:
 ### Process Flow (Warehouse)
 1. Operator is about to putaway received container/stock
-2. EasyWMS first tries opportunity crossdocking (direct to dock) — if not possible:
+2. EasyWMS first tries opportunity crossdocking (direct to dock) - if not possible:
 3. EasyWMS evaluates crossdocking to warehouse:
   a. Identifies candidate shipping orders meeting criteria
   b. Checks if existing crossdocking locations already have sufficient stock
@@ -189,7 +189,7 @@ No special location or strategy configuration required. The system automatically
 3. **Putaway strategies**: create and enable at least one strategy with "Is crossdocking" = true, including destination rules targeting the crossdocking locations
 4. **Stock assignment**: ensure the stock assignment strategy consults crossdocking locations first when the shipping order is released (these locations are consulted preferentially automatically)
-### Mecalux France — EasyS / SmartUI Setup Notes
+### Mecalux France - EasyS / SmartUI Setup Notes
 Additional setup steps consolidated from Mecalux France practice (in addition to the items above) :
@@ -203,16 +203,16 @@ Additional setup steps consolidated from Mecalux France practice (in addition to
 1. On eligible items, enable **Cross-docking** in the advanced data tab.
 2. Create the crossdocking putaway strategy **in sequence position 1** so it runs before the other putaway strategies.
-**Criteria tab** : enable crossdocking. ⚠️ Without any additional criterion, **all items** will be treated as crossdocking at reception — always add conditions on the state of the pending outbound orders (e.g. status "En attente") to avoid this.
+**Criteria tab** : enable crossdocking. ⚠️ Without any additional criterion, **all items** will be treated as crossdocking at reception - always add conditions on the state of the pending outbound orders (e.g. status "En attente") to avoid this.
 **Rules tab** : set `Zone` to the crossdocking zone created in EasyS.
-### Mecalux France — Known Behavior Notes
+### Mecalux France - Known Behavior Notes
 - **Reception must be done on the RFT** : the reception buffer does not trigger crossdocking evaluation. If reception is performed on the buffer, crossdocking is bypassed silently.
- **Buffer over dock for direct XD** : when the outbound order has an assigned buffer, direct (opportunity) crossdocking routes stock to the *buffer* rather than the dock — useful for a subsequent packing step.
+- **Buffer over dock for direct XD** : when the outbound order has an assigned buffer, direct (opportunity) crossdocking routes stock to the *buffer* rather than the dock - useful for a subsequent packing step.
 - **Crossdocking overrides reserve** : if a crossdocking location exists, the WMS redirects to it even if reserve stock is already available.
- **No label is printed** in standard direct (opportunity) crossdocking, even for a full pallet — plan for a custom label flow if the customer requires one.
+- **No label is printed** in standard direct (opportunity) crossdocking, even for a full pallet - plan for a custom label flow if the customer requires one.
 ## Common Errors
@@ -222,7 +222,7 @@ Additional setup steps consolidated from Mecalux France practice (in addition to
 **Stock placed in crossdocking location but not prioritized at release:** Stock assignment strategy doesn't prioritize crossdocking locations over normal storage. Check the stock assignment strategy configuration to ensure crossdocking location preferences are applied.
-**Crossdocking location fills up, remainder goes to standard storage:** This is normal behavior — the crossdocking process places only what fits. The remainder follows standard putaway. No error; just an expected split.
+**Crossdocking location fills up, remainder goes to standard storage:** This is normal behavior - the crossdocking process places only what fits. The remainder follows standard putaway. No error; just an expected split.
 **Shipping order candidate filtered out unexpectedly:** The crossdocking strategy has filters on order status, priority, or days until release/load that exclude the order. Review the "Is crossdocking" strategy's filter settings.
@@ -232,18 +232,18 @@ Additional setup steps consolidated from Mecalux France practice (in addition to
 | Interface | Path |
 |---|---|
-| Web — crossdocking putaway strategies | "Configuration" → "Putaway strategies" (filter by "Is crossdocking") |
+| Web - crossdocking putaway strategies | "Configuration" → "Putaway strategies" (filter by "Is crossdocking") |
-| Web — item "Allow crossdocking" | "Inventory" → "Items" → item → settings |
+| Web - item "Allow crossdocking" | "Inventory" → "Items" → item → settings |
-| Web — location storage logic | "Warehouse" → "Locations" → location → "Change storage location logic" |
+| Web - location storage logic | "Warehouse" → "Locations" → location → "Change storage location logic" |
-| RFT — putaway flow (opportunity XD) | Normal putaway flow; system routes to dock/stage automatically |
+| RFT - putaway flow (opportunity XD) | Normal putaway flow; system routes to dock/stage automatically |
-| RFT — putaway flow (XD to warehouse) | Normal putaway flow; system routes to XD location automatically |
+| RFT - putaway flow (XD to warehouse) | Normal putaway flow; system routes to XD location automatically |
 ## Related
- [Reception](reception.md) — crossdocking is triggered during the putaway phase following reception
+- [Reception](reception.md) - crossdocking is triggered during the putaway phase following reception
- [Putaway](putaway.md) — crossdocking uses the putaway strategy engine; "Is crossdocking" strategies are a subtype of putaway strategies
+- [Putaway](putaway.md) - crossdocking uses the putaway strategy engine; "Is crossdocking" strategies are a subtype of putaway strategies
- [Shipping](shipping.md) — crossdocking locations feed stock assignment at order release; opportunity crossdocking routes directly to shipping docks
+- [Shipping](shipping.md) - crossdocking locations feed stock assignment at order release; opportunity crossdocking routes directly to shipping docks
- [Container (LPN)](container.md) — containers are the primary unit being crossdocked; stacked containers and multi-reference containers have specific rules
+- [Container (LPN)](container.md) - containers are the primary unit being crossdocked; stacked containers and multi-reference containers have specific rules
- [Stock](stock.md) — stock status and logistic attributes affect crossdocking eligibility
+- [Stock](stock.md) - stock status and logistic attributes affect crossdocking eligibility
- [Inbound Order](order-inbound.md) — ASN containers can carry exclusive reserves for specific outbound orders, enabling crossdocking on receipt
+- [Inbound Order](order-inbound.md) - ASN containers can carry exclusive reserves for specific outbound orders, enabling crossdocking on receipt
- [Outbound Order](order-outbound.md) — SOR lines with crossdocking-eligible items become crossdocking candidates; order priority drives XD selection
+- [Outbound Order](order-outbound.md) - SOR lines with crossdocking-eligible items become crossdocking candidates; order priority drives XD selection
@@ -34,7 +34,7 @@ last_compiled: "2026-04-10"
 Cutting stock is a specialization of item management for items that are **measured and cut to order** rather than picked in discrete unit quantities. Examples: rope, electric cable, chain, flexible pipe (hose), fabric rolls, wire. These items exist as continuous rolls or coils and can only be shipped in specific lengths.
-Cutting stock is an **exclusively manual warehouse feature** — not supported in automated or semi-automated warehouses.
+Cutting stock is an **exclusively manual warehouse feature** - not supported in automated or semi-automated warehouses.
 By definition: **a cutting item is any item with an assigned cutting profile.** The profile defines how the item behaves: whether it requires a cutting station, how it's labeled, and how its stock consolidation works.
@@ -44,11 +44,11 @@ By definition: **a cutting item is any item with an assigned cutting profile.**
 The defining characteristic of cutting stock is that its **base UoM conversion does NOT consolidate**. This means:
- Multiple stock lines of identical qualities (same item, lot, status, logistic attributes) can coexist in the same location/container as **separate records** — they are never merged.
+- Multiple stock lines of identical qualities (same item, lot, status, logistic attributes) can coexist in the same location/container as **separate records** - they are never merged.
 - Each stretch is an individual record with its own quantity (length).
 - This enables precise tracking of available stretch lengths.
-**Practical implication:** If you have three 30m rolls of the same cable in the same location, you have three separate stock records (30m, 30m, 30m) — not one 90m record.
+**Practical implication:** If you have three 30m rolls of the same cable in the same location, you have three separate stock records (30m, 30m, 30m) - not one 90m record.
 ### Base UoM Rule
@@ -150,7 +150,7 @@ Cutting station can be locked via "Stations" view to prevent new stock assignmen
 - Routes: station ↔ stages, station ↔ equipment, station ↔ warehouse, stages ↔ docks/stages/consolidation
 - Associated stages: routes to cutting station, other stages of same station, stages of stations cutting same profile, equipment, warehouse, docks/stages/consolidation
-**Label recommendations at cutting stations:** Print labels for cutting station code, station location code, receiving stage location code, shipping stage location code — operators confirm these codes continuously during cutting.
+**Label recommendations at cutting stations:** Print labels for cutting station code, station location code, receiving stage location code, shipping stage location code - operators confirm these codes continuously during cutting.
 ## Reception of Cutting Stock
@@ -202,7 +202,7 @@ Station (integrated) items can be included in shipping orders, order groups, and
 **Return to warehouse:** Operator can return stock without pending assignments from station to warehouse at any time.
-**Note:** Once a cutting stock line has tasks in "In Process" or "Finished" status, quantity cannot be changed — but line can always be canceled.
+**Note:** Once a cutting stock line has tasks in "In Process" or "Finished" status, quantity cannot be changed - but line can always be canceled.
 ### Delegated Cutting in Station
@@ -232,7 +232,7 @@ Because cutting requires tools and cannot be performed everywhere, it is **not p
 ### Enter Quantity Mode
-Cutting stock is indivisible — you cannot pick one unit at a time to confirm total. Therefore:
+Cutting stock is indivisible - you cannot pick one unit at a time to confirm total. Therefore:
 - **"Enter quantity mode" must be set to "Manually"** in the item's shipping profile
 - The total length is confirmed in one step at the moment of cutting
@@ -250,7 +250,7 @@ Counting cutting stock (in non-consolidating conversions) differs from standard
 2. **Assign user status during counting:** Set status before entering a stretch; status persists for subsequent stretches until changed or removed. Can be assigned/unassigned to any stretch in the list.
-3. **Modify counted lines:** Delete any stretch (not edit quantity — deletion only). "Stretches" action lists all counted stretches. "Empty List" action clears all. Lines with user status are shown in list.
+3. **Modify counted lines:** Delete any stretch (not edit quantity - deletion only). "Stretches" action lists all counted stretches. "Empty List" action clears all. Lines with user status are shown in list.
 **Informed count mode:** For locations where exact roll lengths are unknown. Verifies bulk presence only. Allows comparison and adjustment by operator.
@@ -273,8 +273,8 @@ See [[quality-control]] for full details. Cutting stock has specific lock behavi
 See [[manual-movements]] for full details. Specific cutting stock rules:
 - Cutting stock moves require **exact stretch length confirmation**
- Moving cutting stock is only allowed as a whole stretch — partial moves of a stretch are not supported (the indivisibility rule)
+- Moving cutting stock is only allowed as a whole stretch - partial moves of a stretch are not supported (the indivisibility rule)
- If move requires cutting to reduce length, that is not permitted via manual movement — must go through the picking/cutting process
+- If move requires cutting to reduce length, that is not permitted via manual movement - must go through the picking/cutting process
 ## Crossdocking Interaction
@@ -285,7 +285,7 @@ Cutting outside storage locations is not permitted. However, **opportunity cross
 See [[stock-adjustment]] for full details. Cutting-specific behavior:
 - Adjustments apply to individual stretch records
- Labels can be printed for cutting stock from the "Location adjustment" RFT process — only if the cutting profile has "Label source stock" active
+- Labels can be printed for cutting stock from the "Location adjustment" RFT process - only if the cutting profile has "Label source stock" active
 - Transactions: STK.ADJ
 ## Parameters
@@ -327,14 +327,14 @@ See [[stock-adjustment]] for full details. Cutting-specific behavior:
 ## Related
- [[product-item]] — Cutting profile is configured on the item master; base UoM rules apply
+- [[product-item]] - Cutting profile is configured on the item master; base UoM rules apply
- [[reception]] — Cutting stock has specialized receipt processes (blind, supplier)
+- [[reception]] - Cutting stock has specialized receipt processes (blind, supplier)
- [[picking]] — Integrated and delegated cutting processes are extensions of picking
+- [[picking]] - Integrated and delegated cutting processes are extensions of picking
- [[shipping]] — Shipping profile configuration is mandatory for correct excess handling
+- [[shipping]] - Shipping profile configuration is mandatory for correct excess handling
- [[stock-adjustment]] — Label printing from location adjustment; STK.ADJ transactions
+- [[stock-adjustment]] - Label printing from location adjustment; STK.ADJ transactions
- [[count]] — Counting stretches has unique UI and process rules
+- [[count]] - Counting stretches has unique UI and process rules
- [[quality-control]] — Cutting stock locks (partial/total); STC/STR messages
+- [[quality-control]] - Cutting stock locks (partial/total); STC/STR messages
- [[manual-movements]] — Moving whole stretches; indivisibility enforced
+- [[manual-movements]] - Moving whole stretches; indivisibility enforced
- [[stations]] — Cutting station (type 61) configuration and associated stages
+- [[stations]] - Cutting station (type 61) configuration and associated stages
- [[labels]] — Cutting stock label format (A6), print triggers, printer priority
+- [[labels]] - Cutting stock label format (A6), print triggers, printer priority
- [[parameters]] — CUTTING_PRINTER parameter
+- [[parameters]] - CUTTING_PRINTER parameter
@@ -62,7 +62,7 @@ For each rotation strategy, destination rules specify where to move candidate co
 |---|---|
 | Same aisle | Move within the same aisle; skip if no valid location in aisle |
 | Specific aisle | Move to a designated automatic aisle; skip if no valid location |
-| Storage zones | One or more target zones (mandatory — at least one required) |
+| Storage zones | One or more target zones (mandatory - at least one required) |
 | Priority | Task priority for defragmentation tasks of this ABC+zone combination |
 **Location search uses putaway strategies** in configured sequence order.
@@ -78,7 +78,7 @@ For each rotation strategy, destination rules specify where to move candidate co
 Shipping strategies pre-position containers assigned to upcoming orders near the warehouse exit, speeding up the shipping preparation process.
-### Strategy Criteria — Shipping (Order / Container Selection)
+### Strategy Criteria - Shipping (Order / Container Selection)
 | Criterion | Description |
 |---|---|
@@ -93,7 +93,7 @@ Shipping strategies pre-position containers assigned to upcoming orders near the
 > If orders don't have all stock assigned yet, the stock assignment process runs first.
-### Strategy Rules — Shipping (Destination Selection)
+### Strategy Rules - Shipping (Destination Selection)
 | Rule | Description |
 |---|---|
@@ -193,9 +193,9 @@ Planners enable **unattended, scheduled** defragmentation. Both rotation and shi
 ## Related
- [[location]] — Defragmentation moves containers between locations; rotation strategies use storage zones; only automatic aisles are valid
+- [[location]] - Defragmentation moves containers between locations; rotation strategies use storage zones; only automatic aisles are valid
- [[container]] — Containers are the unit of movement; ABC classification, type, and references-per-container govern candidate selection
+- [[container]] - Containers are the unit of movement; ABC classification, type, and references-per-container govern candidate selection
- [[stock]] — Stock records follow container movements; STK.MOVE and CON.MOVE transactions generated
+- [[stock]] - Stock records follow container movements; STK.MOVE and CON.MOVE transactions generated
- [[task]] — Defragmentation generates movement tasks executed during inactivity; `MAX_DEFRAG_TASKS` limits concurrency
+- [[task]] - Defragmentation generates movement tasks executed during inactivity; `MAX_DEFRAG_TASKS` limits concurrency
- [[order-outbound]] — Shipping defragmentation is triggered by outbound orders; status must be Creating/Waiting/Released
+- [[order-outbound]] - Shipping defragmentation is triggered by outbound orders; status must be Creating/Waiting/Released
- [[putaway]] — Rotation defragmentation uses putaway strategies to find destination locations
+- [[putaway]] - Rotation defragmentation uses putaway strategies to find destination locations
@@ -82,7 +82,7 @@ All messages have a **version** suffix when multiple variants exist (e.g., ROR01
 | KIT | Kit | ERP → WMS | Create/update kit definitions |
 | LCK | Lock Type | ERP → WMS | Lock type master data |
-#### ITM — Image fields
+#### ITM - Image fields
 The `ITM01` message can optionally convey the article's picture. Two modes:
@@ -91,13 +91,13 @@ The `ITM01` message can optionally convey the article's picture. Two modes:
 | **Local file** | `<ItmPicture>nom-fichier.jpg</ItmPicture>` | File resolved against the folder pointed to by `UserImagesURI` in the WMS `appsettings.json`. Typical value : `C:/MLX/Data/Pictures/`. |
 | **URL** | `<ItmPictureUrl>https://…/photo.jpg</ItmPictureUrl>` | Fetched by the WMS when the client uses the display; `ItmPicture` takes precedence if both are present. |
-> Requires read access on the `UserImagesURI` share from the WMS service account. The image is not uploaded via the ITM file — only the filename / URL is stamped on the item record.
+> Requires read access on the `UserImagesURI` share from the WMS service account. The image is not uploaded via the ITM file - only the filename / URL is stamped on the item record.
 ---
 ### Inbound / Receipt Messages
-#### ROR — Receipt Order (ERP → WMS)
+#### ROR - Receipt Order (ERP → WMS)
 The primary message for creating inbound orders.
@@ -124,11 +124,11 @@ The primary message for creating inbound orders.
 - Order code must be unique for new orders
 - Lines support optional `transactional` group to control failure behavior
 - Can create/modify/cancel lines individually after creation
- Triggers [ROC](#roc--receipt-order-status-change-wms--erp) status change notifications
+- Triggers [ROC](#roc---receipt-order-status-change-wms--erp) status change notifications
 ---
-#### ASN — Advanced Shipping Notice (ERP → WMS)
+#### ASN - Advanced Shipping Notice (ERP → WMS)
 Pre-notifies WMS of containers en route to the warehouse.
@@ -151,12 +151,12 @@ Pre-notifies WMS of containers en route to the warehouse.
 **Notes:**
 - Creates pending stock at ASN virtual location
- If container is received: triggers [ASO](#aso--advanced-shipping-notice-ok-wms--erp) response
+- If container is received: triggers [ASO](#aso---advanced-shipping-notice-ok-wms--erp) response
- If container is rejected or deleted: triggers [ASK](#ask--advanced-shipping-notice-ko-wms--erp) response
+- If container is rejected or deleted: triggers [ASK](#ask---advanced-shipping-notice-ko-wms--erp) response
 ---
-#### SRN — Stock Replenish Notice (ERP → WMS)
+#### SRN - Stock Replenish Notice (ERP → WMS)
 Pre-notifies WMS of loose stock for automatic warehouse replenishment.
@@ -178,7 +178,7 @@ Pre-notifies WMS of loose stock for automatic warehouse replenishment.
 ---
-#### ROC — Receipt Order Status Change (WMS → ERP)
+#### ROC - Receipt Order Status Change (WMS → ERP)
 Notifies ERP of receipt order status transitions.
@@ -195,13 +195,13 @@ Notifies ERP of receipt order status transitions.
 ---
-#### ROF — Receipt Order Finalization (WMS → ERP)
+#### ROF - Receipt Order Finalization (WMS → ERP)
 Notifies ERP that a receipt order has been closed or canceled, with received quantities.
 **Versions:**
 - `ROF01`: Standard finalization
- `ROF02`: Extended with detailed line-level quantities — **the version generated when closing an inbound order sourced from a `Transfer` shipping order** (two-warehouse flow). For standard supplier receipts, ROF01 is emitted.
+- `ROF02`: Extended with detailed line-level quantities - **the version generated when closing an inbound order sourced from a `Transfer` shipping order** (two-warehouse flow). For standard supplier receipts, ROF01 is emitted.
 **Key fields:**
 | Field | Description |
@@ -219,7 +219,7 @@ Notifies ERP that a receipt order has been closed or canceled, with received qua
 ---
-#### REF — Receipt Finalization (WMS → ERP)
+#### REF - Receipt Finalization (WMS → ERP)
 Notifies ERP that a **receipt** (physical receiving event) has been closed.
@@ -247,7 +247,7 @@ Notifies ERP that a **receipt** (physical receiving event) has been closed.
 ---
-#### ASO — Advanced Shipping Notice OK (WMS → ERP)
+#### ASO - Advanced Shipping Notice OK (WMS → ERP)
 Confirms that a pre-notified container has been successfully received.
@@ -262,11 +262,11 @@ Confirms that a pre-notified container has been successfully received.
 | ReceiptCode | Receipt document |
 | ReceivedDate | Reception timestamp |
-> **DirectTransfer trigger** — when the expedition of a `<DirectTransfer>` shipping order is closed at the origin warehouse, EasyWMS automatically generates an `ASO01` message targeting the destination warehouse, creating the incoming ASN container(s). The ASO carries the container and its stock but **no reference to the originating `SorCode` / DirectTransfer header**. See [concepts/order-outbound.md](order-outbound.md#asn--directtransfer-flow).
+> **DirectTransfer trigger** - when the expedition of a `<DirectTransfer>` shipping order is closed at the origin warehouse, EasyWMS automatically generates an `ASO01` message targeting the destination warehouse, creating the incoming ASN container(s). The ASO carries the container and its stock but **no reference to the originating `SorCode` / DirectTransfer header**. See [concepts/order-outbound.md](order-outbound.md#asn---directtransfer-flow).
 ---
-#### ASK — Advanced Shipping Notice KO (WMS → ERP)
+#### ASK - Advanced Shipping Notice KO (WMS → ERP)
 Notifies ERP that a pre-notified container has been rejected or deleted.
@@ -280,11 +280,11 @@ Notifies ERP that a pre-notified container has been rejected or deleted.
 **Triggered by:** `CON.CNL.ASN` transaction
-> **DirectTransfer trigger** — deleting an ASN container of a DirectTransfer flow from SmartUI (`Entrepôt → Conteneurs ASN → Supprimer`) generates an `ASK01` to the ERP. As with the ASO, the message contains no reference to the upstream shipping order.
+> **DirectTransfer trigger** - deleting an ASN container of a DirectTransfer flow from SmartUI (`Entrepôt → Conteneurs ASN → Supprimer`) generates an `ASK01` to the ERP. As with the ASO, the message contains no reference to the upstream shipping order.
 ---
-#### SRO — Stock Replenish OK (WMS → ERP)
+#### SRO - Stock Replenish OK (WMS → ERP)
 Confirms that pre-notified loose stock has been used for automatic warehouse replenishment.
@@ -292,7 +292,7 @@ Confirms that pre-notified loose stock has been used for automatic warehouse rep
 ---
-#### SRK — Stock Replenish KO (WMS → ERP)
+#### SRK - Stock Replenish KO (WMS → ERP)
 Notifies that pre-notified loose stock has been canceled (not used for replenishment).
@@ -302,7 +302,7 @@ Notifies that pre-notified loose stock has been canceled (not used for replenish
 ### Outbound / Shipping Messages
-#### SOR — Shipping Order (ERP → WMS)
+#### SOR - Shipping Order (ERP → WMS)
 The primary message for creating outbound orders.
@@ -341,13 +341,13 @@ The primary message for creating outbound orders.
 | SOR02: PrpContTypeRequired | Required client container type |
 | SOR02: VASCode | VAS template |
-**`SorType = DirectTransfer`** — inter-warehouse transfer; closing the expedition at origin emits an automatic `ASO01` on destination, pre-creating the ASN container (see [ASO](#aso--advanced-shipping-notice-ok-wms--erp) and [concepts/order-outbound.md](order-outbound.md#asn--directtransfer-flow)).
+**`SorType = DirectTransfer`** - inter-warehouse transfer; closing the expedition at origin emits an automatic `ASO01` on destination, pre-creating the ASN container (see [ASO](#aso---advanced-shipping-notice-ok-wms--erp) and [concepts/order-outbound.md](order-outbound.md#asn---directtransfer-flow)).
-**`SorType = Transfer`** — inter-warehouse transfer variant where destination generates **a full inbound order** on expedition close (as opposed to DirectTransfer which only pre-notifies via ASN). The destination ROR carries the source SOR reference ; on close, destination emits a `ROF02` carrying the line-level quantities, which the origin warehouse uses to reconcile. See [concepts/order-outbound.md](order-outbound.md#transfer-two-warehouse-flow).
+**`SorType = Transfer`** - inter-warehouse transfer variant where destination generates **a full inbound order** on expedition close (as opposed to DirectTransfer which only pre-notifies via ASN). The destination ROR carries the source SOR reference ; on close, destination emits a `ROF02` carrying the line-level quantities, which the origin warehouse uses to reconcile. See [concepts/order-outbound.md](order-outbound.md#transfer---two-warehouse-flow-inbound-order-created).
 ---
-#### SOC — Shipping Order Status Change (WMS → ERP)
+#### SOC - Shipping Order Status Change (WMS → ERP)
 Notifies ERP of shipping order status transitions.
@@ -357,7 +357,7 @@ Notifies ERP of shipping order status transitions.
 ---
-#### SOF — Shipping Order Finalization (WMS → ERP)
+#### SOF - Shipping Order Finalization (WMS → ERP)
 Notifies ERP that a shipping order has been closed or canceled with shipped quantities.
@@ -379,11 +379,11 @@ Notifies ERP that a shipping order has been closed or canceled with shipped quan
 ---
-#### DlvShareDeliveries — Merge outbound orders (ERP → WMS)
+#### DlvShareDeliveries - Merge outbound orders (ERP → WMS)
 XML message used by the **Multi-Carrier / Deliveries module** to request that two or more outbound orders be prepared together (merged). A merged group shares client containers, carrier call, and closure.
-**Eligibility** — all orders in the request must match on:
+**Eligibility** - all orders in the request must match on:
 - Same account
 - Same site (warehouse)
@@ -397,13 +397,13 @@ When `ALLOW_MERGE_DIFFERENT_ACCOUNT = true` is set, the "same account" rule is r
 - Stock assignment is executed across the merged scope (not per-order)
 - Client containers can carry lines from any order in the group
 - Order closure is triggered when the last line of the last order in the group is picked / when the carrier call returns
- SOF is still emitted per source SOR — only preparation is shared
+- SOF is still emitted per source SOR - only preparation is shared
 See [concepts/order-outbound.md](order-outbound.md#merge-order-fusion) for operator flows and limitations.
 ---
-#### LOF — Load Finalization (WMS → ERP)
+#### LOF - Load Finalization (WMS → ERP)
 Notifies ERP that a truck load has been closed (truck loaded and sealed).
@@ -421,7 +421,7 @@ Notifies ERP that a truck load has been closed (truck loaded and sealed).
 ---
-#### WOR — Work Order (ERP → WMS)
+#### WOR - Work Order (ERP → WMS)
 Creates kit assembly or other work orders.
@@ -429,7 +429,7 @@ Creates kit assembly or other work orders.
 ---
-#### WOF — Work Order Finalization (WMS → ERP)
+#### WOF - Work Order Finalization (WMS → ERP)
 Notifies ERP that a work order (kit assembly, etc.) has been closed or canceled.
@@ -437,7 +437,7 @@ Notifies ERP that a work order (kit assembly, etc.) has been closed or canceled.
 ---
-#### RUT — Route (ERP → WMS)
+#### RUT - Route (ERP → WMS)
 Creates or updates carrier routes.
@@ -453,7 +453,7 @@ Creates or updates carrier routes.
 ### Count Messages
-#### COR — Count Order Request (ERP → WMS)
+#### COR - Count Order Request (ERP → WMS)
 Requests WMS to create a physical count.
@@ -476,7 +476,7 @@ Requests WMS to create a physical count.
 ---
-#### COF — Count Order Finalization (WMS → ERP)
+#### COF - Count Order Finalization (WMS → ERP)
 Reports count results when a WMS-received count (from COR) is closed or canceled.
@@ -501,7 +501,7 @@ Reports count results when a WMS-received count (from COR) is closed or canceled
 ### Request Messages
-#### STR — Stock Status Change Request (ERP → WMS)
+#### STR - Stock Status Change Request (ERP → WMS)
 Requests WMS to apply or remove a quality lock on stock.
@@ -523,15 +523,15 @@ Requests WMS to apply or remove a quality lock on stock.
 | OwnerCode | Owner |
 | FltAttLot | Lot filter |
 | StaCode | Status code to apply |
-| StaUsrEnd | Lock expiry (UTC) — optional |
+| StaUsrEnd | Lock expiry (UTC) - optional |
 | StaUsrEmpty | Status to remove (for unlock) |
 | StaRecEmpty | Reception status to remove |
-**Response:** [STC](#stc--stock-status-change-wms--erp) message per affected stock line
+**Response:** [STC](#stc---stock-status-change-wms--erp) message per affected stock line
 ---
-#### SCR — Stock Count Request (ERP → WMS)
+#### SCR - Stock Count Request (ERP → WMS)
 Requests WMS to report current stock for an item or lot.
@@ -544,11 +544,11 @@ Requests WMS to report current stock for an item or lot.
 | OwnerCode | Owner |
 | LotCode | Lot (optional) |
-**Response:** [WSC](#wsc--warehouse-stock-count-wms--erp) message
+**Response:** [WSC](#wsc---warehouse-stock-count-wms--erp) message
 ---
-#### CMC — Container Movement Confirmation (ERP → WMS)
+#### CMC - Container Movement Confirmation (ERP → WMS)
 Notifies WMS of a container's destination after removal from outbound conveyor, when movements are managed by an external system.
@@ -563,7 +563,7 @@ Notifies WMS of a container's destination after removal from outbound conveyor,
 ### Notification Messages (WMS → ERP)
-#### STV — Stock Variation (WMS → ERP)
+#### STV - Stock Variation (WMS → ERP)
 Reports any stock quantity change (increase, decrease, creation, deletion, UoM change, logistic attribute change).
@@ -588,7 +588,7 @@ Reports any stock quantity change (increase, decrease, creation, deletion, UoM c
 ---
-#### STC — Stock Status Change (WMS → ERP)
+#### STC - Stock Status Change (WMS → ERP)
 Reports every stock quality status change (lock or unlock).
@@ -611,7 +611,7 @@ Reports every stock quality status change (lock or unlock).
 ---
-#### WSC — Warehouse Stock Count (WMS → ERP)
+#### WSC - Warehouse Stock Count (WMS → ERP)
 Response to SCR stock contrast request. Reports current stock quantities.
@@ -630,7 +630,7 @@ Response to SCR stock contrast request. Reports current stock quantities.
 ---
-#### KST — Kit Assembled (WMS → ERP)
+#### KST - Kit Assembled (WMS → ERP)
 Notifies ERP that kit stock has been assembled.
@@ -649,7 +649,7 @@ Notifies ERP that kit stock has been assembled.
 ---
-#### UNK — Kit Disassembled (WMS → ERP)
+#### UNK - Kit Disassembled (WMS → ERP)
 Notifies ERP that kit stock has been disassembled.
@@ -657,7 +657,7 @@ Notifies ERP that kit stock has been disassembled.
 ---
-#### COS — Container Shipped to PS (WMS → ERP)
+#### COS - Container Shipped to PS (WMS → ERP)
 Notifies ERP that a client container has been sent to the outbound conveyor (PS/Sortation).
@@ -675,7 +675,7 @@ Notifies ERP that a client container has been sent to the outbound conveyor (PS/
 ---
-#### COC — Container Closed in MP (WMS → ERP)
+#### COC - Container Closed in MP (WMS → ERP)
 Notifies ERP that a client container has been closed in a Preparation Zone (MP).
@@ -685,7 +685,7 @@ Notifies ERP that a client container has been closed in a Preparation Zone (MP).
 ---
-#### ERR — Error (WMS → ERP)
+#### ERR - Error (WMS → ERP)
 Sent when WMS cannot process an incoming ERP message. Contains the original message reference and error description.
@@ -714,7 +714,7 @@ ERP Response Queue ──→ ERP
 ### Transaction Post-processing
-Many WMS transactions are marked **"Post-processed: yes"** — meaning after the internal transaction is written, a background post-processor generates the corresponding ERP message:
+Many WMS transactions are marked **"Post-processed: yes"** - meaning after the internal transaction is written, a background post-processor generates the corresponding ERP message:
 | Transaction | Generated Message |
 |------------|-----------------|
@@ -756,7 +756,7 @@ Beyond the core catalog, optional modules add their own ERP messages:
 | Kits | UNK | WMS → ERP | Kit manually disassembled (manual work orders) |
 | Store Fulfillment | TOR01 | ERP → WMS | Transfer order between stores/sub-warehouses |
 | Store Fulfillment | TOF01 | WMS → ERP | Transfer order finalized |
-| Store Fulfillment | TPV01 | ERP → WMS | POS sale notification — decrements store stock |
+| Store Fulfillment | TPV01 | ERP → WMS | POS sale notification - decrements store stock |
 | VAS | VAS01 | ERP → WMS | Create/update VAS templates, activities, and instructions |
 | VAS | SOR02 VASCode | ERP → WMS | VAS template reference per line in shipping order |
 | VAS | SOF (VAS field) | WMS → ERP | VAS model used + quantity returned per shipped line |
@@ -784,13 +784,13 @@ Beyond the core catalog, optional modules add their own ERP messages:
 ## Related
- [Inbound Order](order-inbound.md) — Receipt order lifecycle and ROR/ROC/ROF details
+- [Inbound Order](order-inbound.md) - Receipt order lifecycle and ROR/ROC/ROF details
- [Outbound Order](order-outbound.md) — Shipping order lifecycle and SOR/SOC/SOF details
+- [Outbound Order](order-outbound.md) - Shipping order lifecycle and SOR/SOC/SOF details
- [Quality Control](quality-control.md) — Stock lock/unlock and STR/STC messages
+- [Quality Control](quality-control.md) - Stock lock/unlock and STR/STC messages
- [Count](count.md) — Physical counts and COR/COF messages
+- [Count](count.md) - Physical counts and COR/COF messages
- [Stock](stock.md) — Stock adjustments and STV messages
+- [Stock](stock.md) - Stock adjustments and STV messages
- [Transactions](transactions.md) — Internal transactions that trigger ERP messages
+- [Transactions](transactions.md) - Internal transactions that trigger ERP messages
- [Entities Map](../architecture/entities-map.md) — ERP integration touch points per entity
+- [Entities Map](../architecture/entities-map.md) - ERP integration touch points per entity
- [Replenishment](replenishment.md) — Automatic warehouse replenishment and SRN/SRO/SRK
+- [Replenishment](replenishment.md) - Automatic warehouse replenishment and SRN/SRO/SRK
- [Manufacturing](../modules/manufacturing.md) — MOF/FGP production messages
+- [Manufacturing](../modules/manufacturing.md) - MOF/FGP production messages
- [DOM](../modules/dom.md) — Distributed order management messages
+- [DOM](../modules/dom.md) - Distributed order management messages
@@ -27,12 +27,12 @@ A **kit** is an article resulting from the assembly of several component article
 ERP integration sends kit definitions via the **KIT** message. Individual components must already exist as items in the WMS.
 A kit record consists of:
- **Kit code** — the item code of the assembled article
+- **Kit code** - the item code of the assembled article
- **Component 1..N** — each component's item code + required quantity
+- **Component 1..N** - each component's item code + required quantity
 Kits can be configured with or without physical assembly.
-> ⚠️ **Profile requirement** — an article can only be configured as a kit if its logistic profile carries the **`Version`** logistic attribute. Otherwise the activation fails with a profile-mismatch error and the item must be reassigned to a profile that has `Version` and a reception control method.
+> ⚠️ **Profile requirement** - an article can only be configured as a kit if its logistic profile carries the **`Version`** logistic attribute. Otherwise the activation fails with a profile-mismatch error and the item must be reassigned to a profile that has `Version` and a reception control method.
 ## Creating a kit article (SmartUI)
@@ -52,7 +52,7 @@ Add components with **"Ajouter composant"** : item, quantity, main component.
 ### 1. Kit without assembly (no mounting)
-The kit article has **assembled = NO**. When a shipping order requests a kit, the WMS splits picking into separate tasks — one per component — without any physical assembly step. The kit is "assembled" implicitly by delivering all components.
+The kit article has **assembled = NO**. When a shipping order requests a kit, the WMS splits picking into separate tasks - one per component - without any physical assembly step. The kit is "assembled" implicitly by delivering all components.
 **Example**: A "Garden Set" kit containing 1 table + 4 chairs: picking generates two tasks (table pick, chairs pick). The final delivery is the two components together.
@@ -60,11 +60,11 @@ The kit article has **assembled = NO**. When a shipping order requests a kit, th
 The kit article has **assembled = YES**. A physical work order is required: components are picked and brought to an assembly zone, the kit is built, and the resulting kit item is added to stock.
-**Sub-type — on-demand assembly** (`assembled = YES`, `assembly_on_demand = YES`): the assembly can be triggered by a shipping order when kit stock is zero, without a pre-existing work order. Used when the ERP can create work orders autonomously.
+**Sub-type - on-demand assembly** (`assembled = YES`, `assembly_on_demand = YES`): the assembly can be triggered by a shipping order when kit stock is zero, without a pre-existing work order. Used when the ERP can create work orders autonomously.
-**Sub-type — ERP-driven assembly** (`assembled = YES`, `assembly_on_demand = NO`): the assembly is only triggered by a Work Order (WOR) from the ERP or a manually created order. No automatic kit fabrication request is generated when stock is insufficient.
+**Sub-type - ERP-driven assembly** (`assembled = YES`, `assembly_on_demand = NO`): the assembly is only triggered by a Work Order (WOR) from the ERP or a manually created order. No automatic kit fabrication request is generated when stock is insufficient.
-### SAGE 100C Connector — Nomenclature types
+### SAGE 100C Connector - Nomenclature types
 When integrated with SAGE 100C, EasyWMS maps SAGE nomenclature types to kit configurations:
@@ -97,7 +97,7 @@ ERP sends WOR → WMS creates work order
 3. All components arrive at the assembly zone
 4. Operator scans and confirms assembly on TRF
 5. Component stock automatically decremented; kit stock created
-6. Kit returned to storage — available for shipping orders
+6. Kit returned to storage - available for shipping orders
 7. `WOF` sent to ERP at work order close or cancellation (only if originated from ERP)
 8. If work order was created manually: `KST` sent to ERP to notify consumed and created stock
@@ -119,22 +119,22 @@ ERP sends WOR (disassembly) → WMS creates work order
 2. WMS generates picking tasks for kit items to assembly zone
 3. Operator disassembles kits at the zone
 4. Kit stock decremented; each component's stock incremented
-5. Components returned to storage — available for picking
+5. Components returned to storage - available for picking
 6. `WOF` sent to ERP at close/cancellation (only if ERP-originated)
 7. If manual: `UNK` sent to ERP to notify consumed (kits) and created (components) stock
 ---
-## Work Order Lifecycle — Creation, Modification, Cancellation
+## Work Order Lifecycle - Creation, Modification, Cancellation
 ### Creation modes
 | Mode | Description |
 |---|---|
-| **From ERP** | `WOR` file — Work Order created with status **En attente** ; `WOF` sent at close/cancel |
+| **From ERP** | `WOR` file - Work Order created with status **En attente** ; `WOF` sent at close/cancel |
-| **Manual (SmartUI)** | Menu `Ordres de travail → Ordres de travail` — `KST` sent at close |
+| **Manual (SmartUI)** | Menu `Ordres de travail → Ordres de travail` - `KST` sent at close |
-| **Manual (RFT)** | Menu `Kits → Demande de composants` — WO created **and released automatically**. ⚠️ **No ERP feedback** — neither `KST` nor `WOF` is generated |
+| **Manual (RFT)** | Menu `Kits → Demande de composants` - WO created **and released automatically**. ⚠️ **No ERP feedback** - neither `KST` nor `WOF` is generated |
-| **Automatic** | Requires `Montage sur demande = OUI` — triggered at integration of an outbound order containing a kit shortage |
+| **Automatic** | Requires `Montage sur demande = OUI` - triggered at integration of an outbound order containing a kit shortage |
 ### Modifications allowed, by status
@@ -151,8 +151,8 @@ When a WO is released, the WMS checks available stock in the kit zone. If insuff
 ## Closing a Work Order
- **Automatic** — once every requested kit has been assembled / disassembled.
+- **Automatic** - once every requested kit has been assembled / disassembled.
- **Manual** — allowed at any time as long as **at least one** kit has been processed.
+- **Manual** - allowed at any time as long as **at least one** kit has been processed.
 - On close : `WOF` is sent to the ERP (for ERP-originated and SmartUI-manual WOs ; not for RFT-manual).
 ## Kit Shortage Handling
@@ -171,8 +171,8 @@ When a WO is released, the WMS checks available stock in the kit zone. If insuff
 - Multiple components per kit; each component has item code + required quantity
 - Stock consumed at assembly is tracked per lot/batch for traceability purposes
 - Kit articles can have their own logistic profiles (reception, shipping, putaway) like any item
- **No automatic re-order**: WMS never requests fabrication when kit stock is insufficient — this is always a manual or ERP-driven action
+- **No automatic re-order**: WMS never requests fabrication when kit stock is insufficient - this is always a manual or ERP-driven action
- Component stock shortage at kit assembly time does not block the work order — operator must resolve
+- Component stock shortage at kit assembly time does not block the work order - operator must resolve
 - For kits with `assembled = YES`, a work order (WOR) is mandatory before assembly can begin in the WMS
 ---
@@ -222,8 +222,8 @@ When a WO is released, the WMS checks available stock in the kit zone. If insuff
 ## Related
- [[product-item]] — Kit articles and components are both standard items with logistic profiles
+- [[product-item]] - Kit articles and components are both standard items with logistic profiles
- [[stock]] — Component stock is consumed; kit stock is created at assembly
+- [[stock]] - Component stock is consumed; kit stock is created at assembly
- [[order-outbound]] — Outbound orders trigger component picks (no assembly) or reference assembled kit stock
+- [[order-outbound]] - Outbound orders trigger component picks (no assembly) or reference assembled kit stock
- [[erp-interface]] — KIT, WOR, WOF, KST, UNK are the ERP messages for kit management
+- [[erp-interface]] - KIT, WOR, WOF, KST, UNK are the ERP messages for kit management
- [[manufacturing]] — Similar concept but for raw material → finished goods transformation; manufacturing module handles additives, production stations, and automated consumption
+- [[manufacturing]] - Similar concept but for raw material → finished goods transformation; manufacturing module handles additives, production stations, and automated consumption
@@ -49,7 +49,7 @@ Three GS1-128 container label types:
 1. **SSCC label** (standard container label): Contains container code and is used for generic container identification. Barcode encodes the SSCC.
-2. **GS1-128 mono-reference label** (for single-item containers): Dual barcode — upper for item, lower for container. Used when container has stock of only one item.
+2. **GS1-128 mono-reference label** (for single-item containers): Dual barcode - upper for item, lower for container. Used when container has stock of only one item.
 3. **GS1-128 multi-reference label** (for multi-item containers or serialized items): For containers with multiple item stock lines or serial-number-controlled items.
@@ -57,8 +57,8 @@ Three GS1-128 container label types:
 | AI | Content | Structure |
 |----|---------|-----------|
-| **00** | SSCC (container serial code) | n18 — always present |
+| **00** | SSCC (container serial code) | n18 - always present |
-| **02** | Item alias (GTIN) | n14 — always present |
+| **02** | Item alias (GTIN) | n14 - always present |
 | 10 | Lot number | an..20 |
 | 11 | Manufacturing date | n6 |
 | 15 | Best-before date | n6 |
@@ -73,8 +73,8 @@ Lot (AI 10), if present, always appears in the lower barcode next to the SSCC.
 |--------|-----|------|
 | Generate from Easy WMS UI | Planner/admin | Pre-reception (select number of containers + copies per container) |
 | Generate from RF terminal | Operator | Pre-reception (select format, count, printer) |
-| Print GS1-128 in supplier receipt | Operator (RF) | During supplier receiving — for non-existing containers |
+| Print GS1-128 in supplier receipt | Operator (RF) | During supplier receiving - for non-existing containers |
-| Print GS1-128 in blind receipt | Operator (RF) | During blind receiving — must be enabled by parameter |
+| Print GS1-128 in blind receipt | Operator (RF) | During blind receiving - must be enabled by parameter |
 **Special case for supplier receipt:** If the receipt was created from a receipt order that specified the container code (ROR message), the label prints with that ROR-specified code. The container GTIN in the ROR must follow GS1-128 spec (14 digits).
@@ -110,13 +110,13 @@ Labels for individual stock items. Two formats: Code 128 and GS1-128.
 **GS1-128 item labels:**
 - Can be printed from receipt lines (pending/partially received) or from the Stock view (post-reception)
 - Number of labels entered by user
- Format: A6 horizontal (148 × 105 mm) — label printer
+- Format: A6 horizontal (148 × 105 mm) - label printer
 **GS1-128 Item Application Identifiers (AI):**
 | AI | Content | Structure |
 |----|---------|-----------|
-| **01** | GTIN (item code) | n14 — always present |
+| **01** | GTIN (item code) | n14 - always present |
 | 10 | Lot number | an..20 |
 | 11 | Manufacturing date | n6 |
 | 15 | Best-before date | n6 |
@@ -157,9 +157,9 @@ Specialized label for cutting stock in non-consolidating UoM conversions. Used t
 **When labels are generated:** A cutting stock label is only printed for stock in non-consolidating UoM. Three triggers:
-1. **During picking/cutting process** — if cutting profile has "Label cutting stock" or "Label source stock" flag active
+1. **During picking/cutting process** - if cutting profile has "Label cutting stock" or "Label source stock" flag active
-2. **From Stock view (PC)** — "Print cutting label" action on a stock record (non-consolidating UoM)
+2. **From Stock view (PC)** - "Print cutting label" action on a stock record (non-consolidating UoM)
-3. **From RF Location adjustment (Utilities menu)** — only if cutting profile has "Label source stock" active
+3. **From RF Location adjustment (Utilities menu)** - only if cutting profile has "Label source stock" active
 **Printer priority order (highest to lowest):**
 1. Printer associated with the cutting station (for cutting station stock)
@@ -202,7 +202,7 @@ An alternative to standard receiving processes that allows reading all barcode d
 | Mono-reference containers | Single-item containers |
 | Identical mono-reference containers | Batch of identical single-item containers |
-**Process:** System reads all labels on the item/container until user presses "Done" or max reads is reached. If any data is unreadable, system asks for manual entry (except container code in mono-reference flows — requested at end if not read). Operator can press "Skip" at start to fall back to manual reception.
+**Process:** System reads all labels on the item/container until user presses "Done" or max reads is reached. If any data is unreadable, system asks for manual entry (except container code in mono-reference flows - requested at end if not read). Operator can press "Skip" at start to fall back to manual reception.
 During multi-reading: type and height of container can be selected; stock statuses can be entered.
@@ -262,7 +262,7 @@ This section consolidates **every known trigger** for each document/label, inclu
 |---|---|
 | Menu **Entrepôt → Support** → select → *Imprimer étiquette* | Manual |
 | Menu **Entrepôt → Stock** → select line → *Imprimer étiquettes de support* | Manual |
-| ROR01 tag `<EnableLabelPrinting>` (boolean) | Auto — mono-reference container uses `DEFAUT_RECEPTION_LABEL_CONTAINER_REPORT_NAME` with `NUM_COPIES_RECEPTION_LABEL` copies; multi-reference uses `DEFAULT_RECEPTION_LABEL_MULTIREFERENCE_CONTAINER_REPORT_NAME` |
+| ROR01 tag `<EnableLabelPrinting>` (boolean) | Auto - mono-reference container uses `DEFAUT_RECEPTION_LABEL_CONTAINER_REPORT_NAME` with `NUM_COPIES_RECEPTION_LABEL` copies; multi-reference uses `DEFAULT_RECEPTION_LABEL_MULTIREFERENCE_CONTAINER_REPORT_NAME` |
 ### Client container label (shipping)
@@ -271,9 +271,9 @@ This section consolidates **every known trigger** for each document/label, inclu
 | SOR01 tag `<PrpContLabels>` | Auto-print at buffer/dock drop |
 | SmartUI **"Document printings"** on the buffer/POUMON → *Impression automatique de l'étiquette du support du client* | Auto (requires printer assigned) |
 | Menu **Entrepôt → Supports** → select a client container → *Imprimer étiquettes clients* | Manual |
-| Report selected by parameter `CLIENT_CONTAINER_LABEL_REPORT` | — |
+| Report selected by parameter `CLIENT_CONTAINER_LABEL_REPORT` | - |
-### Packing list — per container ("Liste de conditionnement par support")
+### Packing list - per container ("Liste de conditionnement par support")
 | Trigger | Notes |
 |---|---|
@@ -281,9 +281,9 @@ This section consolidates **every known trigger** for each document/label, inclu
 | Menu **Sorties → Ordres de sortie** → select order → *Imprimer rapport → Liste de conditionnement (par support)* | Manual |
 | Menu **Entrepôt → Supports** → select → *Imprimer la liste de colisage* | Manual |
 | SOR02 tag `<DlvPrintDocumentation>` (boolean, Multi-Carrier module only) | Auto |
-| Report selected by parameter `CLIENT_CONTAINER_PACKING_REPORT` | — |
+| Report selected by parameter `CLIENT_CONTAINER_PACKING_REPORT` | - |
-### Packing list — per item ("Liste de conditionnement par article")
+### Packing list - per item ("Liste de conditionnement par article")
 | Trigger | Notes |
 |---|---|
@@ -294,7 +294,7 @@ This section consolidates **every known trigger** for each document/label, inclu
 | Trigger | Notes |
 |---|---|
-| ROR01 tag `<EnablePrintingItemLabel>` (boolean) | Auto — report name from `DEFAULT_RECEPTION_LABEL_ITEM_REPORT_NAME` |
+| ROR01 tag `<EnablePrintingItemLabel>` (boolean) | Auto - report name from `DEFAULT_RECEPTION_LABEL_ITEM_REPORT_NAME` |
 | Menu **Données principales → Articles** → select → *Imprimer étiquette* | Manual |
 ### Delivery note ("BL")
@@ -379,9 +379,9 @@ All label-related parameters consolidated:
 ## Related
- [[container]] — Container types, LPN management, SSCC codes
+- [[container]] - Container types, LPN management, SSCC codes
- [[product-item]] — Item master, GTIN aliases, logistic attributes shown on labels
+- [[product-item]] - Item master, GTIN aliases, logistic attributes shown on labels
- [[reception]] — All label printing at reception time; ROR message enables item labels
+- [[reception]] - All label printing at reception time; ROR message enables item labels
- [[cutting-stock]] — Cutting stock label specifics: A6 format, source/cut flags, printer priority
+- [[cutting-stock]] - Cutting stock label specifics: A6 format, source/cut flags, printer priority
- [[stations]] — ETQ (type 58) labeller station, dock/stage printer configuration
+- [[stations]] - ETQ (type 58) labeller station, dock/stage printer configuration
- [[parameters]] — All label parameters listed above
+- [[parameters]] - All label parameters listed above
@@ -30,7 +30,7 @@ last_compiled: "2026-04-17"
 A location is any physical or virtual space capable of storing loose stock and/or containers within the warehouse. Locations are the fundamental spatial unit of Easy WMS: every piece of stock must have a location, every container must be placed in a location, and every movement task has a source and destination location.
-Locations sit within a hierarchical spatial model: Organization → Warehouse (Site) → Zone → Aisle → Side → Column/Row. This hierarchy determines how putaway strategies are applied, how routes are calculated, and how work zones restrict equipment access. The configuration of each location — its type, storage mode, capacity, and logics — determines which processes can use it and how the system manages stock within it.
+Locations sit within a hierarchical spatial model: Organization → Warehouse (Site) → Zone → Aisle → Side → Column/Row. This hierarchy determines how putaway strategies are applied, how routes are calculated, and how work zones restrict equipment access. The configuration of each location - its type, storage mode, capacity, and logics - determines which processes can use it and how the system manages stock within it.
 Locations are created and configured by implementers using the EasyS or Easy Assistant configuration tools. End users cannot create or delete physical locations; they can only manage stock within them and perform administrative operations such as locking, relabeling, or changing work zones.
@@ -80,10 +80,10 @@ In conventional rack and APS locations, if a container physically cannot be depo
 When two sub-warehouses cannot share equipment (e.g., only high-reach forklift accesses a mezzanine, but it is barred from the ground-floor picking area), an **intermediate Buffer location** lets two different equipment types hand stock off to each other.
-**Pattern** — `Sub-warehouse B reserve → Transit buffer → Sub-warehouse A picking`:
+**Pattern** - `Sub-warehouse B reserve → Transit buffer → Sub-warehouse A picking`:
 - EasyS element of type **"Transport"** with aisles configured.
- Its sub-location (double-click the transport element) is the actual buffer location. **EasyS creates it as type `Automatic` — it must be changed manually to type `Buffer`**, otherwise the RFT rejects the container scan with "le support n'existe pas".
+- Its sub-location (double-click the transport element) is the actual buffer location. **EasyS creates it as type `Automatic` - it must be changed manually to type `Buffer`**, otherwise the RFT rejects the container scan with "le support n'existe pas".
 - The transport sub-warehouse must be reachable by both equipment groups.
 **Routing**:
@@ -95,14 +95,14 @@ When two sub-warehouses cannot share equipment (e.g., only high-reach forklift a
 | Equipment group PICKING | Both sub-warehouses |
 | Equipment group RESERVE | Sub-warehouse B only |
-Routes default to transport type `Galileo` — manually flip them to `RF` for a manual warehouse.
+Routes default to transport type `Galileo` - manually flip them to `RF` for a manual warehouse.
 **Flow at runtime**:
 1. Replenishment task created from reserve (B) to picking location (A).
 2. RESERVE equipment (e.g., `CACES06`) takes the task → drops container on the transit Buffer.
 3. PICKING equipment (e.g., `PIK01`) picks the task in **Tâches → Tâches de réapprovisionnement** → drops stock at the picking destination.
-See [concepts/replenishment.md](replenishment.md#inter-sub-warehouse-replenishment-via-intermediate-buffer) for the matching replenishment flow.
+See [concepts/replenishment.md](replenishment.md#inter-sub-warehouse-replenishment-via-an-intermediate-buffer) for the matching replenishment flow.
 ## Location coding
@@ -164,7 +164,7 @@ Key attributes visible in the "Locations" view:
 | Sub-warehouse | Sub-warehouse this location belongs to |
 | Coordinates | Aisle, side, X, Y, depth, stackability |
 | Maximum weight | kg capacity |
-| Height | m — used for container height compatibility checks |
+| Height | m - used for container height compatibility checks |
 | Last count date | When this location was last physically counted |
 | Full (manually marked) | Location excluded from putaway search; cleared when stock is added manually |
 | Crossdocking location | Flag for crossdocking eligibility |
@@ -252,12 +252,12 @@ From the "Locations" view, users can modify (PC only):
 ## Related
- [[container]] — stored in locations; location type determines container compatibility and position tracking
+- [[container]] - stored in locations; location type determines container compatibility and position tracking
- [[stock]] — stock records are always linked to a location; location logics determine stock eligibility for picking/shipping/replenishment
+- [[stock]] - stock records are always linked to a location; location logics determine stock eligibility for picking/shipping/replenishment
- [[putaway]] — putaway strategies target specific locations via zone/type/logic filters
+- [[putaway]] - putaway strategies target specific locations via zone/type/logic filters
- [[replenishment]] — PDLs are locations with item assignment; replenishment source/target logics control eligibility
+- [[replenishment]] - PDLs are locations with item assignment; replenishment source/target logics control eligibility
- [[count]] — count processes filter on "Allow count" logic; count partition assignments link items to location positions
+- [[count]] - count processes filter on "Allow count" logic; count partition assignments link items to location positions
- [[defragmentation]] — defragmentation moves stock between locations to consolidate and optimize space
+- [[defragmentation]] - defragmentation moves stock between locations to consolidate and optimize space
- [[task]] — all movement tasks have source/destination locations; location type determines coordinate reporting
+- [[task]] - all movement tasks have source/destination locations; location type determines coordinate reporting
- [[crossdocking]] — crossdocking locations flagged with "Is crossdocking" are reserved for near-term outbound stock
+- [[crossdocking]] - crossdocking locations flagged with "Is crossdocking" are reserved for near-term outbound stock
- [[stations]] — stations group locations into functional zones for routing and process assignment
+- [[stations]] - stations group locations into functional zones for routing and process assignment
@@ -20,13 +20,13 @@ last_compiled: "2026-04-10"
 - Stock or a container was physically moved without informing EasyWMS first, or
 - Stock or a container appeared in a location different from the one recorded in the system
-This is a corrective, out-of-band mechanism — it does not create picking or replenishment tasks, but directly updates the stock/container records in the system to match physical reality.
+This is a corrective, out-of-band mechanism - it does not create picking or replenishment tasks, but directly updates the stock/container records in the system to match physical reality.
 Manual movements are available from **both manual and automatic warehouses** (at a picking conveyor for automatic).
 All manual movements generate `STK.MOVE` transactions (and `CON.MOVE` for container moves).
-> **Important:** Manual movements do **not** create guided tasks — they directly apply the relocation. For planned container movements, use task-based processes (putaway, replenishment, etc.).
+> **Important:** Manual movements do **not** create guided tasks - they directly apply the relocation. For planned container movements, use task-based processes (putaway, replenishment, etc.).
 ---
@@ -72,7 +72,7 @@ All manual movements generate `STK.MOVE` transactions (and `CON.MOVE` for contai
 **Valid in both manual and automatic warehouses.** At a picking conveyor, valid as long as neither source nor destination container/stock has active replenishment, picking, or counting tasks.
-**Special case — virtual Movement location:** Stock can be moved between containers even when one container is at a PK station and in the "Movement" virtual location (i.e., in transit).
+**Special case - virtual Movement location:** Stock can be moved between containers even when one container is at a PK station and in the "Movement" virtual location (i.e., in transit).
 **Movement of client stock** is allowed when there is a matching shipping order.
@@ -156,7 +156,7 @@ Cutting stock (non-consolidating UoM) has special behavior due to its indivisibl
 4. The label "Maximum quantity" shows the longest stretch at the location
 5. Operator can use "List Stock" action to see and select all stretches; "All" action loads all stretches
-**Key rule:** Cutting stock can only be moved **entire stretch by entire stretch** — no partial moves.
+**Key rule:** Cutting stock can only be moved **entire stretch by entire stretch** - no partial moves.
 **Interface:**
 - RFT: `Utilities > Manual Move`
@@ -168,7 +168,7 @@ Cutting stock (non-consolidating UoM) has special behavior due to its indivisibl
 **When:** Loose stock in one or more partitions of a picking location was recorded in a different partition.
 **Restrictions:**
- Cannot know the total quantity in a partition — if a partition becomes empty, the operator must explicitly mark it
+- Cannot know the total quantity in a partition - if a partition becomes empty, the operator must explicitly mark it
 - Cannot move a partition itself, only the stock within it
 - Cannot change to a partition in another warehouse
@@ -190,11 +190,11 @@ Cutting stock (non-consolidating UoM) has special behavior due to its indivisibl
 ## Business Rules
- Manual movements do **not** generate guided tasks — they directly update records.
+- Manual movements do **not** generate guided tasks - they directly update records.
 - All moves are **within the same warehouse**. Cross-warehouse moves are not supported.
 - ASN containers (pre-notified, not yet received) **cannot be moved** by manual movement.
 - Client stock (assigned to a shipping order) can only move to another client container with a matching shipping order.
- Locks blocking movement prompt operator confirmation — the move **can still proceed** at the operator's discretion.
+- Locks blocking movement prompt operator confirmation - the move **can still proceed** at the operator's discretion.
 - For cutting stock with multiple stretches of non-consolidating UoM, **only one stretch can be moved at a time**.
 - Moving a container with replenishment assignments cancels those assignments and triggers task decrement/cancellation on affected picking tasks.
@@ -224,8 +224,8 @@ Cutting stock (non-consolidating UoM) has special behavior due to its indivisibl
 ## Related
- [[container]] — Container moves update CON.MOVE; moving a container with replenishment assignments cascades to task cancellation
+- [[container]] - Container moves update CON.MOVE; moving a container with replenishment assignments cascades to task cancellation
- [[location]] — All moves are within a single warehouse; virtual locations (Movement) are valid endpoints for container moves in transit
+- [[location]] - All moves are within a single warehouse; virtual locations (Movement) are valid endpoints for container moves in transit
- [[stock]] — STK.MOVE transactions update all stock records; manual movements are the corrective path when physical and system records diverge
+- [[stock]] - STK.MOVE transactions update all stock records; manual movements are the corrective path when physical and system records diverge
- [[task]] — Manual movements can cancel/decrement picking/replenishment tasks; they do not create guided tasks themselves
+- [[task]] - Manual movements can cancel/decrement picking/replenishment tasks; they do not create guided tasks themselves
- [[stock-adjustment]] — Complement to manual movements: adjustments correct quantity/UoM/attributes; manual movements correct location
+- [[stock-adjustment]] - Complement to manual movements: adjustments correct quantity/UoM/attributes; manual movements correct location
@@ -1,5 +1,5 @@
 ---
-title: "Mechanical Elements — Acronyms, Conveyors, Station Codes"
+title: "Mechanical Elements - Acronyms, Conveyors, Station Codes"
 type: concept
 sources:
  - sources/archives/Acronymes_elements_mecaniques.md
@@ -18,7 +18,7 @@ related:
 last_compiled: "2026-04-17"
 ---
-# Mechanical Elements — Acronyms, Conveyors, Station Codes
+# Mechanical Elements - Acronyms, Conveyors, Station Codes
 ## Overview
@@ -37,12 +37,12 @@ All Mecalux mechanical acronyms are in Spanish; the translation matters because
 | **APS200** | Pallet Shuttle Automático (supercondensadores) | Automatic Pallet Shuttle (SUPERCAP) |
 | **ATC** | Abatible Transportador de Cadenas | Lift-up gate Chain Conveyor |
 | **CT** | Carro Transferidor | Transfer Car |
-| **2ECDF** | — | Double Telescopic Fork with Combined Belts |
+| **2ECDF** | - | Double Telescopic Fork with Combined Belts |
-| **ECDF** | — | Telescopic Fork (belt, double) |
+| **ECDF** | - | Telescopic Fork (belt, double) |
 | **EMS** | Sistema electrovía aérea | Overhead Electric Monorail |
 | **EP** | Elevador Paletas | Pallet Lift |
-| **EPDF** | — | Telescopic Fork (double fond) |
+| **EPDF** | - | Telescopic Fork (double fond) |
-| **EPSF** | — | Telescopic Fork (simple fond) |
+| **EPSF** | - | Telescopic Fork (simple fond) |
 | **IMS** | Sistema electrovía invertida | Inverted Electric Monorail |
 | **LBC** | Transportador de Banda recto Continuo | Continuous Belt Conveyor |
 | **LRA** | Transportador de Rodillos de Acúmulo | Buffering Roller Conveyor |
@@ -77,18 +77,18 @@ Conveyor type drives whether EasyWMS can reliably track a container on the conve
 | Type | Capacity | WMS tracking |
 |------|----------|--------------|
 | **LRA** (Buffering roller) | 1 container | Tracking moves LRA → LRA on each hop; container can be **stopped** on an LRA |
-| **LRC** (Continuous roller) | multiple containers | Containers advance until the end sensor trips — **tracking is generally lost** on LRC |
+| **LRC** (Continuous roller) | multiple containers | Containers advance until the end sensor trips - **tracking is generally lost** on LRC |
 | **LRAB** (Scale roller) | 1 container | Acts like LRA, with an integrated scale (weight verification) |
 | **LTM** (Cross transfer) | 1 container | 90° change of direction; on multidirectional tables set `routing options = 1` for each feeder conveyor |
-| **LRD** (Diverting outlet) | — | Oblique outlet — splits flow off a main line |
+| **LRD** (Diverting outlet) | - | Oblique outlet - splits flow off a main line |
-| **LRI** (Angle induction) | — | Oblique inlet — merges flow onto a main line |
+| **LRI** (Angle induction) | - | Oblique inlet - merges flow onto a main line |
 | **LBC** (Belt conveyor) | multiple containers | **Tracking lost** when a container passes a belt conveyor |
-| **LRL** (Free roller / gravity) | — | **No tracking** on LRL; WMS treats the position as a **buffer** (typically with an outbound station upstream) |
+| **LRL** (Free roller / gravity) | - | **No tracking** on LRL; WMS treats the position as a **buffer** (typically with an outbound station upstream) |
-| Pedestrian passage | — | Elevated walkway — not a conveyor; no container flow |
+| Pedestrian passage | - | Elevated walkway - not a conveyor; no container flow |
 **Practical consequence:** LBC and LRL segments behave as "blind" zones. If a PS (shipping conveyor) outputs onto an LRL, WMS closes the tracking at the PS and considers the container parked in a buffer.
-## 3. Station codes — FR / ES / EN matrix
+## 3. Station codes - FR / ES / EN matrix
 Station codes are shared by EasyWMS and GALILEO. Each station is uniquely identified by the couple **(Type, Number)**. Keep this table as the source of truth when cross-referencing documentation between regions.
@@ -125,20 +125,20 @@ Machine code reading rules for miniloads:
 - **ML** = Miniload
 - **B** (after ML) = **Bicolumn** (absence of B = single column) → e.g. `ML-100` (single), `MLB-100Q` (bi)
- **EPSF** = Extracteur Pelle Simple Fond — **1 charge** per extraction cycle (pelle = shovel, single depth)
+- **EPSF** = Extracteur Pelle Simple Fond - **1 charge** per extraction cycle (pelle = shovel, single depth)
- **EPDF** = Extracteur Pelle Double Fond — **1 charge**, double-depth rack
+- **EPDF** = Extracteur Pelle Double Fond - **1 charge**, double-depth rack
- **ECDF** = Extracteur Courroie Double Fond — **2 charges** per extraction cycle (courroie = belt, double depth)
+- **ECDF** = Extracteur Courroie Double Fond - **2 charges** per extraction cycle (courroie = belt, double depth)
 **Rule of thumb:**
 - "Pelle" (shovel) extractors handle **one charge** at a time
- "Courroie" (belt) extractors can handle **two charges** at a time — they drive the logic for channel filling and double-depth putaway
+- "Courroie" (belt) extractors can handle **two charges** at a time - they drive the logic for channel filling and double-depth putaway
 The miniload model (from the installation layout) dictates the entry/outbound table configuration in EasyS (see [Galileo Simulation](../operations/galileo-simulation.md)).
 ## Related
- [Stations & Routes](stations.md) — full WMS station catalogue
+- [Stations & Routes](stations.md) - full WMS station catalogue
- [GALILEO Integration](../architecture/galileo-integration.md) — how station codes feed the protocol
+- [GALILEO Integration](../architecture/galileo-integration.md) - how station codes feed the protocol
- [Galileo Simulation & Test Setup](../operations/galileo-simulation.md) — PLC Types, rack configuration, routes
+- [Galileo Simulation & Test Setup](../operations/galileo-simulation.md) - PLC Types, rack configuration, routes
- [Galileo Troubleshooting](../operations/galileo-troubleshooting.md) — cross-check station codes when debugging `EndErrorCode=4`
+- [Galileo Troubleshooting](../operations/galileo-troubleshooting.md) - cross-check station codes when debugging `EndErrorCode=4`
 - [Pallet Shuttle](../modules/pallet-shuttle.md) · [APS3D](../modules/aps3d.md) · [Movirack](../modules/movirack.md) · [AGV](../modules/agv.md)
@@ -36,7 +36,7 @@ last_compiled: "2026-04-10"
 A **receipt order** (also called inbound order) is the WMS document that tracks expected incoming stock. It represents a list of items or containers expected to arrive at the warehouse, serving as the basis for the reception process. Receipt orders allow the warehouse to plan dock resources, validate quantities, and close the loop with the ERP upon receipt.
-Most receipt orders originate in the ERP (purchase orders to suppliers, customer return orders, transfer orders from other warehouses) and arrive via messaging. Easy WMS also allows manual creation of receipt orders directly in the UI. Receipt orders are optional — stock can be received without one (blind reception) — but they enable quantity control, automatic label printing, and ERP reconciliation.
+Most receipt orders originate in the ERP (purchase orders to suppliers, customer return orders, transfer orders from other warehouses) and arrive via messaging. Easy WMS also allows manual creation of receipt orders directly in the UI. Receipt orders are optional - stock can be received without one (blind reception) - but they enable quantity control, automatic label printing, and ERP reconciliation.
 The receipt order is distinct from the **receipt** (the actual WMS event of receiving stock physically). One receipt order can be fulfilled by one or more receipts; one receipt can be associated with one or more receipt orders.
@@ -47,7 +47,7 @@ Receipt orders (and their associated receipts) are categorized by type, which co
 | Type | Description | Typical origin |
 |---|---|---|
 | **Supplier** | Stock arriving from a vendor. Lines specify items, expected quantities, and UoM. Stock may arrive in any presentation (pack, box, etc.) regardless of the line's UoM. Logistic attributes and quality status can optionally be pre-set by the ERP. | ERP purchase order (PO) |
-| **Return** | Customer returns — damaged or surplus stock. Similar line structure to Supplier type. | ERP return authorization |
+| **Return** | Customer returns - damaged or surplus stock. Similar line structure to Supplier type. | ERP return authorization |
 | **Transfer** | Stock transferred from another warehouse in the same organization. Stock always arrives in containers, which are pre-notified as ASN containers at the destination. Lines specify containers, items, and quantities. | ERP transfer order; automatic when source shipping order closes (Transfer type) |
 Receipt orders also have a **class** for additional personalization of the reception process (custom flow variants, label types, etc.). Classes do not change the type logic but allow further differentiation.
@@ -81,7 +81,7 @@ Each line identifies the expected item/container and quantity:
 | **Line number** | Unique line identifier within the order |
 | **Status** | Line status (mirrors order status progression) |
 | **Container** | Expected or received container code (Transfer type or ASN) |
-| **Item** | Item code expected; alternatively, a presentation alias (GTIN/EAN) can be used — in this case, only stock of that EAN presentation is received against this line |
+| **Item** | Item code expected; alternatively, a presentation alias (GTIN/EAN) can be used - in this case, only stock of that EAN presentation is received against this line |
 | **Owner** | Owner of the expected stock |
 | **Quantity** | Expected quantity |
 | **UoM** | Unit of measure (usually base UoM; can be a presentation if packaging is known) |
@@ -130,7 +130,7 @@ Each line identifies the expected item/container and quantity:
 ### Messages: ERP → WMS
-#### ROR — Receipt Order Request
+#### ROR - Receipt Order Request
 Creates, modifies, or cancels receipt orders.
@@ -155,7 +155,7 @@ Key ROR fields:
 - Line `LneStockStatus`: forced receiving status for stock on this line
 - Line reserves (`LneStkRsvSORCode` / `LneStkRsvAccCode`): pre-allocate received stock to a specific outbound order or account
-#### ASN — Advanced Shipping Notice
+#### ASN - Advanced Shipping Notice
 Pre-notifies containers expected at the warehouse. Containers are created in the virtual ASN location.
@@ -176,11 +176,11 @@ ASN key fields: `ContainerCode`, `ContainerType`, `ReceiptOrderCode`, `NumExpect
 ### Messages: WMS → ERP
-#### ROC — Receipt Order status Change
+#### ROC - Receipt Order status Change
 Sent by WMS when an order changes status. Fields: `RorCode`, `Status` (Waiting / ReceptionPending / Receiving / PartiallyReceived / Complete / Expired / Canceled), `UpdateDate` (UTC timestamp).
-#### ROF — Receipt Order Finalization
+#### ROF - Receipt Order Finalization
 Sent when an order is closed or canceled. Two versions:
 - **ROF01**: includes receipt data + order data + stock received. Sent on order close/cancel AND on receipt close (even if receipt has no order).
@@ -188,11 +188,11 @@ Sent when an order is closed or canceled. Two versions:
 ROF01/ROF02 key fields per line: `LneItemCode`, `LneOwnerCode`, `LneQtyExpected`, `LneQtyReceived`, `LneQtyFree`, `LneQtyUoMCode`.
-#### ASO — ASN receipt confirmation (WMS → ERP)
+#### ASO - ASN receipt confirmation (WMS → ERP)
 Sent when an ASN pre-notified container is physically received. Confirms item, owner, quantity, and optionally the receiving status (`LneStaStatus`). Variants mirror ASN variants (stacked, matched on dummy, with divisions).
-#### STR — Stock lock/unlock request (ERP → WMS)
+#### STR - Stock lock/unlock request (ERP → WMS)
 Although STR is a request (not a receipt order message), it is closely related to inbound quality control. The ERP requests Easy WMS to apply or remove a user status on stock (e.g., lock a lot for quality reasons):
 - `Operation S`: add user status (lock) with optional quarantine end date
@@ -241,11 +241,11 @@ WMS responds with one or more **STC** messages confirming the modified stock.
 ## Related
- [[reception]] — the physical reception process that fulfills receipt orders; dock/PIE/ASN reception modes all reference receipt orders
+- [[reception]] - the physical reception process that fulfills receipt orders; dock/PIE/ASN reception modes all reference receipt orders
- [[container]] — ASN pre-notifies containers; Transfer-type receipt orders always involve containers
+- [[container]] - ASN pre-notifies containers; Transfer-type receipt orders always involve containers
- [[product-item]] — receipt order lines reference items by code or alias; reception profile governs behavior
+- [[product-item]] - receipt order lines reference items by code or alias; reception profile governs behavior
- [[stock]] — receipt creates stock; receiving status from ROR line is applied to created stock
+- [[stock]] - receipt creates stock; receiving status from ROR line is applied to created stock
- [[putaway]] — after reception, putaway tasks move stock from dock to storage; receipt order type affects putaway strategy eligibility
+- [[putaway]] - after reception, putaway tasks move stock from dock to storage; receipt order type affects putaway strategy eligibility
- [[order-outbound]] — receipt orders can include reserves for outbound orders (cross-dock scenario); transfer orders create an outbound order at source
+- [[order-outbound]] - receipt orders can include reserves for outbound orders (cross-dock scenario); transfer orders create an outbound order at source
- [[crossdocking]] — ASN containers with exclusive reserves enable direct crossdocking on receipt
+- [[crossdocking]] - ASN containers with exclusive reserves enable direct crossdocking on receipt
- [[erp-interface]] — ROR (in), ASN (in), ROC (out), ROF (out), ASO (out), STR (in), STC (out) messages
+- [[erp-interface]] - ROR (in), ASN (in), ROC (out), ROF (out), ASO (out), STR (in), STC (out) messages
@@ -44,7 +44,7 @@ last_compiled: "2026-04-17"
 A **shipping order** (outbound order) is the WMS document that drives the outbound fulfillment process. It is a list of items or containers that need to be shipped from the warehouse. Shipping orders represent customer sales orders, returns to suppliers, inter-warehouse transfers, and internal sub-warehouse replenishments.
-Shipping orders are the primary driver of picking, consolidation, and truck loading operations. They arrive from the ERP via SOR messages in the vast majority of cases. Manual creation is possible for special cases (ERP unavailable, one-off requests). Every outbound activity in the WMS — from stock assignment to task generation to carrier document printing — traces back to a shipping order.
+Shipping orders are the primary driver of picking, consolidation, and truck loading operations. They arrive from the ERP via SOR messages in the vast majority of cases. Manual creation is possible for special cases (ERP unavailable, one-off requests). Every outbound activity in the WMS - from stock assignment to task generation to carrier document printing - traces back to a shipping order.
 A shipping order consists of a **header** (common attributes) and **lines** (specific items/containers with quantities). The lifecycle spans from creation through preparation, consolidation, and final closure with ERP notification.
@@ -56,8 +56,8 @@ The type determines the destination, the process, and how Easy WMS handles the s
 |---|---|---|
 | **Client** | Ship stock to a customer (sales order) | External; carrier delivery |
 | **Return** | Return stock to a supplier | External; supplier |
-| **Transfer** | Transfer to another warehouse in the organization. When closed, creates an inbound order at destination + ASN containers (same stacked structure as loaded). See [Transfer flow](#transfer--two-warehouse-flow-inbound-order-created). | Another warehouse |
+| **Transfer** | Transfer to another warehouse in the organization. When closed, creates an inbound order at destination + ASN containers (same stacked structure as loaded). See [Transfer flow](#transfer---two-warehouse-flow-inbound-order-created). | Another warehouse |
-| **Direct transfer** | Same as Transfer but destination doesn't need to receive — see [ASN — DirectTransfer flow](#asn--directtransfer-flow) below. ASN containers created at destination. Can transfer to the same warehouse. | Another warehouse (no receipt) |
+| **Direct transfer** | Same as Transfer but destination doesn't need to receive - see [ASN - DirectTransfer flow](#asn---directtransfer-flow) below. ASN containers created at destination. Can transfer to the same warehouse. | Another warehouse (no receipt) |
 | **Manual** | Created and prepared directly at RF terminal | Manual picking process |
 | **Kits assembly/unassembly** | Supply kit components for assembly or collect kits for disassembly when work order released | Assembly/disassembly station |
 | **Desk** | Created from a desk operation | Desk output |
@@ -135,7 +135,7 @@ Shipping orders also have a **class** for additional process customization (diff
 [Force close with stock failures] → CLOSED (partial)
              ↓
          ARCHIVED
-          
+
 [Any time before CLOSED]
    → CANCELED (no stock shipped)
 ```
@@ -160,7 +160,7 @@ Shipping orders also have a **class** for additional process customization (diff
 - Orders **cannot mix lines** from different owners when the Owner Extension module is installed.
 - **Priority** affects task sequencing across all active orders: urgent orders get their picking tasks executed first, at the cost of more picking rounds.
 - **Critical lines** (`LneTrmCritical`): if the line cannot be fully assigned, no stock is prepared for that line (the rest of the order is unaffected).
- **Required lines to ship** (`LneTrmRequired`): if the required line cannot be fully shipped, the entire order blocks — nothing is prepared.
+- **Required lines to ship** (`LneTrmRequired`): if the required line cannot be fully shipped, the entire order blocks - nothing is prepared.
 - **Stock assignment** respects the configured stock assignment strategy (logic to minimize movements, maximize container use, minimize lots, etc.).
 - **Excess shipping** (`LneQtyAllowExcess`): if exact quantity is impossible due to containerized stock, the system may over-allocate and then returns surplus.
 - **Substitute items**: used when the ordered item is short. The substitution mode (partial/all-or-nothing) is defined in the item's shipping profile; explicit alternatives in the SOR override the profile.
@@ -173,11 +173,11 @@ Shipping orders also have a **class** for additional process customization (diff
 ### Messages: ERP → WMS
-#### SOR — Shipping Order Request
+#### SOR - Shipping Order Request
 Creates, modifies, or cancels shipping orders. Two versions:
 - **SOR01**: standard shipping orders
- **SOR02**: prepackaging — ERP specifies number/type of packages, stock per package, working mode (strict/non-strict). Also used with VAS (Value Added Services) module.
+- **SOR02**: prepackaging - ERP specifies number/type of packages, stock per package, working mode (strict/non-strict). Also used with VAS (Value Added Services) module.
 | Operation | Fields |
 |---|---|
@@ -185,7 +185,7 @@ Creates, modifies, or cancels shipping orders. Two versions:
 | `U` (update) | Modify header (priority, etc.) or individual lines |
 | `D` (cancel) | Cancel the entire order |
 | Line `C` | Create new line with `LneItemCode`, `LneContCode`, `LneQtyOrder`, `LneQtyUoMCode`, `LneAttributes` |
-| Line `U` | Modify line (qty, UoM, attributes — restrictions apply if stock already prepared/shipped) |
+| Line `U` | Modify line (qty, UoM, attributes - restrictions apply if stock already prepared/shipped) |
 | Line `D` | Cancel specific line |
 Key SOR fields:
@@ -208,7 +208,7 @@ Key SOR fields:
 ### Messages: WMS → ERP
-#### SOC — Shipping Order status Change
+#### SOC - Shipping Order status Change
 Sent on every status transition of a shipping order.
@@ -224,13 +224,13 @@ Sent on every status transition of a shipping order.
 Note: Grouped/fused orders do not report status changes for the grouped order or its components during grouped preparation.
-#### SOF — Shipping Order Finalization
+#### SOF - Shipping Order Finalization
 Sent when an order is closed or canceled.
 Two versions:
- **SOF01**: full data — includes MultiCarrier delivery info, VAS details, all lines. Sent at every partial close (with close number) and at final close/cancel.
+- **SOF01**: full data - includes MultiCarrier delivery info, VAS details, all lines. Sent at every partial close (with close number) and at final close/cancel.
- **SOF02**: modular — excludes MultiCarrier and VAS data. Created when communications became modular so each application manages its own messages.
+- **SOF02**: modular - excludes MultiCarrier and VAS data. Created when communications became modular so each application manages its own messages.
 Key fields:
 - `SorCode`, `Status` (Closed / Canceled)
@@ -241,7 +241,7 @@ Key fields:
 If order is forced to close without shipping any stock, no line data is sent. If canceled, no line data is sent.
-#### LOF — Load Finalization
+#### LOF - Load Finalization
 Sent when a load is finalized (truck loading complete). References shipping orders in the load.
@@ -288,13 +288,13 @@ Sent when a load is finalized (truck loading complete). References shipping orde
 | Print documentation | Delivery note, packing list, differences report |
 | Archive | After closure |
-## ASN — DirectTransfer flow
+## ASN - DirectTransfer flow
-A `<DirectTransfer>` order (`<SorType>` in `SOR02`) requires **at least two warehouses** in the WMS. It ships stock from a source warehouse to a destination warehouse **without generating any inbound order or receipt at destination** — only ASN containers.
+A `<DirectTransfer>` order (`<SorType>` in `SOR02`) requires **at least two warehouses** in the WMS. It ships stock from a source warehouse to a destination warehouse **without generating any inbound order or receipt at destination** - only ASN containers.
-**Preparation** — identical to a standard client order. After the outbound order closes on the source warehouse, the shipped containers automatically appear on the destination warehouse's **`Asn`** location (visible in SmartUI via `Entrepôt → Conteneurs ASN`).
+**Preparation** - identical to a standard client order. After the outbound order closes on the source warehouse, the shipped containers automatically appear on the destination warehouse's **`Asn`** location (visible in SmartUI via `Entrepôt → Conteneurs ASN`).
-**Receiving an ASN container (destination warehouse)** — RFT menu `Réception → Préavis` of the destination warehouse :
+**Receiving an ASN container (destination warehouse)** - RFT menu `Réception → Préavis` of the destination warehouse :
 1. Receive onto the buffer or the equipment.
 2. Scan the container (no other validation required).
@@ -302,11 +302,11 @@ A `<DirectTransfer>` order (`<SorType>` in `SOR02`) requires **at least two ware
 > By design, the direct transfer **skips re-inspection** of the merchandise at the destination.
-**Deleting / rejecting an ASN container** (container not arrived or not conforming) — SmartUI `Entrepôt → Conteneurs ASN` → select the container → **Supprimer**. This generates an **ASK01** file.
+**Deleting / rejecting an ASN container** (container not arrived or not conforming) - SmartUI `Entrepôt → Conteneurs ASN` → select the container → **Supprimer**. This generates an **ASK01** file.
 > ⚠️ Both `ASO01` and `ASK01` files **carry no reference to the origin transfer order**. The ERP itself must reconcile every ASO/ASK container against the originating `DirectTransfer` shipping order to confirm or invalidate the completeness of the transfer.
-## Transfer — two-warehouse flow (inbound order created)
+## Transfer - two-warehouse flow (inbound order created)
 A `<Transfer>`-type order (`<SorType>` in `SOR02`) also requires **at least two warehouses** in the WMS. Unlike `<DirectTransfer>`, closing the outbound at source **automatically creates an inbound order at destination** with the same code as the source order. Containers arrive on the `Asn` location of the destination warehouse.
@@ -324,24 +324,24 @@ Destination-warehouse settings:
 - `AutoCreateReceptionFromRecorder = true` → reception auto-created on first container scan.
 - `AutoCloseInboundOrder = true` → closing the reception auto-closes the inbound order and emits `ROF02`.
-> ⚠️ `ASO01` and `ASK01` still carry **no transfer-header info**. For `<Transfer>` flows the ERP **must** consume `ROF02` — which contains the full list of received containers.
+> ⚠️ `ASO01` and `ASK01` still carry **no transfer-header info**. For `<Transfer>` flows the ERP **must** consume `ROF02` - which contains the full list of received containers.
-See [Reception](reception.md#transfer--two-warehouse-asn-flow-with-receipt) for the receiving procedure.
+See [Reception](reception.md#transfer---two-warehouse-asn-flow-with-receipt) for the receiving procedure.
 ## Merge (order fusion)
-Merging consolidates multiple **outbound orders** into one preparation, so picking/packing/loading happens in a single pass. Merge applies to outbound orders — **not** to deliveries (a delivery is the *result* of a merge, not an input).
+Merging consolidates multiple **outbound orders** into one preparation, so picking/packing/loading happens in a single pass. Merge applies to outbound orders - **not** to deliveries (a delivery is the *result* of a merge, not an input).
 ### Eligibility
-**Required** — every candidate order must match on:
+**Required** - every candidate order must match on:
 - Complete `<ShippingAddress>` (every sub-tag)
 - Complete `<DeliveryAddress>` + `<DeliveryContact>`
 - Same order type (Client, Transfer, …)
 - Status `Waiting`
 - Identical `ExtraData`
-**Disqualifying** — an order cannot be merged if it is already:
+**Disqualifying** - an order cannot be merged if it is already:
 - In another merge
 - In a group
 - In a wave
@@ -367,7 +367,7 @@ The merged order owns its own code, status and shipping date and is treated as a
 </Delivery>
 ```
-Parameter: **`ALLOW_MERGE_DIFFERENT_ACCOUNT`** — if set, allows merging orders from different customer accounts.
+Parameter: **`ALLOW_MERGE_DIFFERENT_ACCOUNT`** - if set, allows merging orders from different customer accounts.
 > ⚠️ **No automatic merge is shipped in standard.** Default is manual. Any automation is a custom scope.
@@ -415,12 +415,12 @@ The WMS uses the shipping-profile **substitution mode** (Partiel / Substitution
 ## Related
- [[shipping]] — the physical shipping process (consolidation, truck loading, PS groups, auto shipping) that fulfills outbound orders
+- [[shipping]] - the physical shipping process (consolidation, truck loading, PS groups, auto shipping) that fulfills outbound orders
- [[picking]] — picking processes execute tasks generated when outbound orders are released; waves/groups/fusions batch multiple orders
+- [[picking]] - picking processes execute tasks generated when outbound orders are released; waves/groups/fusions batch multiple orders
- [[stock]] — stock assignment links specific stock lines to order lines; reserves block stock for specific orders
+- [[stock]] - stock assignment links specific stock lines to order lines; reserves block stock for specific orders
- [[container]] — client containers hold prepared stock; container type requirements configurable per order/line
+- [[container]] - client containers hold prepared stock; container type requirements configurable per order/line
- [[task]] — release generates Picking and Shipping tasks; task priority driven by order priority
+- [[task]] - release generates Picking and Shipping tasks; task priority driven by order priority
- [[replenishment]] — `EnableReplenishment` flag on SOR triggers automatic PDL replenishment when released
+- [[replenishment]] - `EnableReplenishment` flag on SOR triggers automatic PDL replenishment when released
- [[order-inbound]] — Transfer-type outbound orders create receipt orders at destination + ASN pre-notifications
+- [[order-inbound]] - Transfer-type outbound orders create receipt orders at destination + ASN pre-notifications
- [[crossdocking]] — ASN containers with exclusive reserves for outbound orders enable direct crossdocking on receipt
+- [[crossdocking]] - ASN containers with exclusive reserves for outbound orders enable direct crossdocking on receipt
- [[erp-interface]] — SOR (in), SOC (out), SOF (out), LOF (out), WOF (out), RUT (in for routes), SCR/WSC (stock contrast)
+- [[erp-interface]] - SOR (in), SOC (out), SOF (out), LOF (out), WOF (out), RUT (in for routes), SCR/WSC (stock contrast)
@@ -28,7 +28,7 @@ last_compiled: "2026-04-10"
 ## Overview
-Parameters control system behavior at the warehouse level. They allow the same Easy WMS software to behave differently across warehouses of the same organization without code changes. Every process — reception, picking, counting, replenishment — has parameters that tune its behavior.
+Parameters control system behavior at the warehouse level. They allow the same Easy WMS software to behave differently across warehouses of the same organization without code changes. Every process - reception, picking, counting, replenishment - has parameters that tune its behavior.
 Parameters are defined at the **organization level** but can be **customized per warehouse**. A warehouse-level value overrides the organization default.
@@ -301,11 +301,11 @@ Parameters mentioned in other wiki pages:
 ## Related
- [[reception]] — ALLOW_CREATE_RECEPTION, RECEPTION_ASN_*, AutoCloseReception, label printing params
+- [[reception]] - ALLOW_CREATE_RECEPTION, RECEPTION_ASN_*, AutoCloseReception, label printing params
- [[picking]] — WORKWAVES_ALLOW_SELECTION, PTL_WORKING_MODE, FILTER_BEFORE_PICKING, RF_PICKING_CONFIRM_LOCATION
+- [[picking]] - WORKWAVES_ALLOW_SELECTION, PTL_WORKING_MODE, FILTER_BEFORE_PICKING, RF_PICKING_CONFIRM_LOCATION
- [[shipping]] — OUTBOUND_ORDER_PACKINGLIST_*, AUTO_MERGE_ORDERS, AutoCloseLoadedOutboundOrders
+- [[shipping]] - OUTBOUND_ORDER_PACKINGLIST_*, AUTO_MERGE_ORDERS, AutoCloseLoadedOutboundOrders
- [[replenishment]] — MAX_GROUPS_PROCESSED_DYNAMIC_REPLENISH_JOB, REPLENISH_LEVEL_PERCENT
+- [[replenishment]] - MAX_GROUPS_PROCESSED_DYNAMIC_REPLENISH_JOB, REPLENISH_LEVEL_PERCENT
- [[defragmentation]] — MAX_DEFRAG_TASKS, MAX_OPTIMIZATION_DEFRAG_CHANNEL
+- [[defragmentation]] - MAX_DEFRAG_TASKS, MAX_OPTIMIZATION_DEFRAG_CHANNEL
- [[cutting-stock]] — CUTTING_PRINTER
+- [[cutting-stock]] - CUTTING_PRINTER
- [[labels]] — All label format and printer parameters
+- [[labels]] - All label format and printer parameters
- [[count]] — REPLENISH_LEVEL_PERCENT_PRODUCT_LOCATION, NUM_EVENTS_PER_PARTIAL_COMMIT
+- [[count]] - REPLENISH_LEVEL_PERCENT_PRODUCT_LOCATION, NUM_EVENTS_PER_PARTIAL_COMMIT
@@ -117,7 +117,7 @@ The ordering logic lives in the code activity **"Order stock when none location
 When a line allows excess shipping, EasyWMS first tries to assign the exact quantity. If all strategies are exhausted without fulfilling the line completely, the first stock discarded by the last strategy is assigned as excess. Excess is minimized by unassigning the last-assigned stock. The "strict shipping logic on excess" flag prevents excess assignment from using better-logic stock over what was already being shipped.
-## Picking Modes — Manual Warehouse
+## Picking Modes - Manual Warehouse
 Manual warehouse picking is RFT-driven, following the **picking path** (optimal route minimizing operator travel). The path starts at the picking start point and ends at the shipping area.
@@ -135,7 +135,7 @@ Manual warehouse picking is RFT-driven, following the **picking path** (optimal
 | **Voice picking** | Operator receives spoken instructions, confirms by voice; both hands free for handling | RFT + headset |
 | **Advanced picking** | Picks client containers before dock/stage assigned; containers placed on shelf until assignment | RFT |
-**Cutting stock picking** (rope, cable, chain — indivisible lengths):
+**Cutting stock picking** (rope, cable, chain - indivisible lengths):
 - Requires a physical cut before picking
 - Two models: **integrated cut** (cut performed at the location) or **delegated cut** (cut performed at a dedicated cutting station)
 - Cutting stations can have dedicated equipment and procedures for item-specific cutting complexity
@@ -155,27 +155,27 @@ Manual warehouse picking is RFT-driven, following the **picking path** (optimal
 **Flow (RFT):**
 1. Enter the **outbound code** (a default is proposed)
 2. Choose the **shipping dock**
-3. Add lines — **item + quantity** — repeat per line
+3. Add lines - **item + quantity** - repeat per line
-4. **Release** the order — creates the outbound, its lines, and the picking tasks in SmartUI (can take time for large orders)
+4. **Release** the order - creates the outbound, its lines, and the picking tasks in SmartUI (can take time for large orders)
 5. The RFT is redirected into the **standard picking loop**
 **Module interactions:**
- **3PL module** — SOC and SOF use different document codes (the owner is appended to the SOF only). Example: SOC `MAN0000000000000000010`, SOF `MAN0000000000000000010-CECOA`.
+- **3PL module** - SOC and SOF use different document codes (the owner is appended to the SOF only). Example: SOC `MAN0000000000000000010`, SOF `MAN0000000000000000010-CECOA`.
- **Carrier module** — manual picking does **not** expose a carrier field, which can block downstream carrier processing. If the module is enforced, expect a post-release manual intervention.
+- **Carrier module** - manual picking does **not** expose a carrier field, which can block downstream carrier processing. If the module is enforced, expect a post-release manual intervention.
-Entry workflow: `EasyWMS.ManualPicking_ByItem_UI` (cf. [RF Menu reference](../architecture/rf-menu.md#4-ordres-dexpédition-sharedmenu_shippingorders)).
+Entry workflow: `EasyWMS.ManualPicking_ByItem_UI` (cf. [RF Menu reference](../architecture/rf-menu.md#4-shipping-orders---sharedmenu_shippingorders)).
 ### Location Carts (chariots à emplacement) for Multi-Order Picking
 Location carts let one operator prepare **several orders at once without creating one client container per order**. The WMS maps cart divisions (column × row) to orders automatically.
- **Usable only in multi-order picking modes** — groups of orders and waves
+- **Usable only in multi-order picking modes** - groups of orders and waves
 - Removes the need for a secondary *"TRF à emplacement"* configuration in many layouts
 - After picking, the cart is dropped directly onto the packing station
-**Setup — SmartUI:**
+**Setup - SmartUI:**
-1. **Create division types** — define the number and codes of cart slots (tested up to 20×20). The WMS temporarily labels slots `Section{sequence}`; the name entered guides the operator during picking.
+1. **Create division types** - define the number and codes of cart slots (tested up to 20×20). The WMS temporarily labels slots `Section{sequence}`; the name entered guides the operator during picking.
 2. **Create the cart** (tab **"Carts"**):
 | Field | Description |
@@ -184,14 +184,14 @@ Location carts let one operator prepare **several orders at once without creatin
 | Storage location | **Mandatory** |
 | Division type | If empty → the cart behaves as one slot |
-Cart statuses : **Open** (available), **Closed** (stock in progress — not yet packed).
+Cart statuses : **Open** (available), **Closed** (stock in progress - not yet packed).
 **Picking with a cart (RFT):**
- At wave/group start, the RFT proposes to use a cart — scan its code.
+- At wave/group start, the RFT proposes to use a cart - scan its code.
 - On the first drop, the WMS asks which slot (division) to use; subsequent tasks for the same order are auto-routed to the same slot.
 - Column **"Division"** shows `CartCode_SectionCode`.
-**Edge case — closed cart with no free slot:** the RFT reports no task available and flips the cart back to **Open**. To unload: **"Fermer"** on the task list → RFT menu **Rangement → Stock de chariots** → either "Ranger le chariot entièrement" (no redirection to packing) or "Décharger en mode stock libre".
+**Edge case - closed cart with no free slot:** the RFT reports no task available and flips the cart back to **Open**. To unload: **"Fermer"** on the task list → RFT menu **Rangement → Stock de chariots** → either "Ranger le chariot entièrement" (no redirection to packing) or "Décharger en mode stock libre".
 **Packing:** scan the cart code → WMS indicates divisions → scan the division to pack (or list divisions with stock). Standard packing runs with `CartCode_SectionCode` as origin.
@@ -211,7 +211,7 @@ Paper picking is used when RF coverage is missing, when a customer wants a print
 6. Back at the station, click **Confirmer le lot** and **scan the batch number** on the printed sheet :
   - If the order is complete → scan the batch number a second time to close the preparation.
   - Otherwise → scan the incomplete tasks one by one and enter the actual picked quantity.
-7. Scan the batch number one last time to mark the preparation done — the order transitions to **"Prepared"** and stock is transferred to the staging buffer / dock.
+7. Scan the batch number one last time to mark the preparation done - the order transitions to **"Prepared"** and stock is transferred to the staging buffer / dock.
 ### Picking Incidences (Manual Warehouse)
@@ -219,9 +219,9 @@ During picking, issues are recorded when containers are not where expected or ex
 - **Mark to review**: creates a lock and count on the container/location; does not interrupt the current process; lock removed when count completes
 - **Stock adjustment**: ERP is notified of any inventory corrections via messenger service
-**Wait for replenishment**: configurable behavior — system can auto-trigger replenishment tasks when a picking location is empty to complete the pick.
+**Wait for replenishment**: configurable behavior - system can auto-trigger replenishment tasks when a picking location is empty to complete the pick.
-By default, when an outbound order is released and no picking location has stock (but stock exists in replenishment sources), picking tasks are created on empty PDLs — these are **silently skipped at execution time** if the PDL is still empty when the operator reaches it. Three global parameters relax this default :
+By default, when an outbound order is released and no picking location has stock (but stock exists in replenishment sources), picking tasks are created on empty PDLs - these are **silently skipped at execution time** if the PDL is still empty when the operator reaches it. Three global parameters relax this default :
 | Parameter | Effect | Key workflow(s) |
 |---|---|---|
@@ -242,7 +242,7 @@ Operator flow for the third parameter :
 **Excess reduction**: if multiple tasks exist for the same item and one is over-picked, the remaining tasks are reduced by the excess amount (or canceled if already satisfied).
-## Picking — Automatic Warehouse (Picking Conveyor / PK)
+## Picking - Automatic Warehouse (Picking Conveyor / PK)
 In automatic warehouses, picking is goods-to-person. The TMS extracts containers from storage and brings them to a **picking conveyor (PK)** station. One PK can serve multiple **preparation zones (MP)**; each MP is a physical table where the operator deposits picked stock into client containers.
@@ -259,14 +259,14 @@ Configuration of picking + preparation pairs (robotics-specific, from EasyS + Sm
  - **Virtual** route → consolidation zone
 - **Max concurrent orders** (SmartUI): **Menu → Control → Workstations** → select PK → set the value. Must **equal the number of preparation tables** linked to the PK
 - **MP assignment mode** (SmartUI): **Menu → Control → Workstations** → select MP(s) → **Modify assignment mode**
-  - **Automatic** — WMS assigns the next order to a table
+  - **Automatic** - WMS assigns the next order to a table
-  - **Manual** — operator assigns via **Menu → Control → Picking-station assignment**. ⚠️ In manual mode, **tasks do not generate until the order is assigned**
+  - **Manual** - operator assigns via **Menu → Control → Picking-station assignment**. ⚠️ In manual mode, **tasks do not generate until the order is assigned**
- **Route requirement**: the MP must have a route to the shipping dock of the order — otherwise tasks won't generate
+- **Route requirement**: the MP must have a route to the shipping dock of the order - otherwise tasks won't generate
 **Three ways to trigger container extraction from the miniload:**
 1. Demand the container from the picking workstation (specific support, empty supports, or specific item)
 2. Request empty containers
-3. Launch an order — assigns PK + generates `pickingContainer` tasks
+3. Launch an order - assigns PK + generates `pickingContainer` tasks
 For detailed bring-up in simulation and the "Store container" + "Liberate" test flow, see [Galileo Simulation](../operations/galileo-simulation.md).
@@ -322,7 +322,7 @@ After all picking tasks for a shipping order are completed at the PK:
 - Physical PK pushbutton is pressed to signal completion
 - TMS generates movement tasks to return the source container to its storage location or to a rejection station
-## Picking — Pick and Pack Mode
+## Picking - Pick and Pack Mode
 In Pick and Pack warehouses, operators pick stock directly into the final shipping carton (client container). Two integration levels:
@@ -359,7 +359,7 @@ The picking path is the optimal traversal order of locations for picking tasks.
 The picking path starts at the **picking start point** (configured per sub-warehouse or warehouse) and ends at the shipping area. The path selects the next closest task, but overall path optimality depends on warehouse layout.
-## Order Planning — Waves, Groups, and Shipment Templates
+## Order Planning - Waves, Groups, and Shipment Templates
 ### Order priorities
@@ -367,11 +367,11 @@ Each shipping order carries a priority that determines task sequence:
 | Priority | Relative urgency |
 |----------|-----------------|
-| **Urgent** | Highest — processed first in all queues |
+| **Urgent** | Highest - processed first in all queues |
 | **High** | Above normal |
 | **Normal** | Default |
 | **Low** | Below normal |
-| **Very Low** | Lowest — processed last |
+| **Very Low** | Lowest - processed last |
 Priorities are set per order (from the ERP or manually) and apply across all picking and shipping task generation.
@@ -418,7 +418,7 @@ Shipment templates automate wave and group creation by applying a set of selecti
 ### Order fusion
-**Fusion** merges multiple shipping orders from the same client/destination into a single preparation batch. This is a **manual-only** operation — EasyWMS does not auto-fuse orders.
+**Fusion** merges multiple shipping orders from the same client/destination into a single preparation batch. This is a **manual-only** operation - EasyWMS does not auto-fuse orders.
 Conditions for fusion:
 - Same client (account)
@@ -458,23 +458,23 @@ After fusion, the combined order is prepared as a single batch, reducing travel
 | Interface | Path |
 |---|---|
-| RFT — picking (manual warehouse) | Menu "Picking" → task mode selection |
+| RFT - picking (manual warehouse) | Menu "Picking" → task mode selection |
-| RFT — picking conveyor (automatic warehouse) | Workstation "Picking" view |
+| RFT - picking conveyor (automatic warehouse) | Workstation "Picking" view |
-| Web — stock assignment strategies | "Configuration" → "Stock assignment strategies" |
+| Web - stock assignment strategies | "Configuration" → "Stock assignment strategies" |
-| Web — shipping order + stock assign | "Shipping" → "Shipping orders" → order → "Stock assign" |
+| Web - shipping order + stock assign | "Shipping" → "Shipping orders" → order → "Stock assign" |
-| Web — workstations (PK config) | "Control" → "Workstations" |
+| Web - workstations (PK config) | "Control" → "Workstations" |
-| Web — docks and stages | "Control" → "Docks and stages" |
+| Web - docks and stages | "Control" → "Docks and stages" |
 ## Related
- [Shipping](shipping.md) — picking is part of the shipping process; picking leads to truck loading
+- [Shipping](shipping.md) - picking is part of the shipping process; picking leads to truck loading
- [Replenishment](replenishment.md) — picking from dedicated locations triggers replenishment when stock runs out
+- [Replenishment](replenishment.md) - picking from dedicated locations triggers replenishment when stock runs out
- [Container (LPN)](container.md) — client containers are created during picking; source containers are extracted from storage
+- [Container (LPN)](container.md) - client containers are created during picking; source containers are extracted from storage
- [Stock](stock.md) — stock assignment determines which specific stock unit is picked
+- [Stock](stock.md) - stock assignment determines which specific stock unit is picked
- [Reception](reception.md) — received goods enter inventory and become eligible for stock assignment
+- [Reception](reception.md) - received goods enter inventory and become eligible for stock assignment
- [Task](task.md) — picking generates Picking tasks; negative picking and cut picking are specific task types
+- [Task](task.md) - picking generates Picking tasks; negative picking and cut picking are specific task types
- [Outbound Order](order-outbound.md) — shipping orders are the source of picking demand; order priority drives task sequence
+- [Outbound Order](order-outbound.md) - shipping orders are the source of picking demand; order priority drives task sequence
- [Location](location.md) — picking dedicated locations (PDLs) are the primary source for picking; location logics control eligibility
+- [Location](location.md) - picking dedicated locations (PDLs) are the primary source for picking; location logics control eligibility
- [[cutting-stock]] — cutting stock picking (shelf, integrated station, delegated station) are specialized picking modes
+- [[cutting-stock]] - cutting stock picking (shelf, integrated station, delegated station) are specialized picking modes
- [[stations]] — PK (type 2), MP (type 16), Workzone (type 64), Decision (type 63), Cutting Station (type 61) all support picking
+- [[stations]] - PK (type 2), MP (type 16), Workzone (type 64), Decision (type 63), Cutting Station (type 61) all support picking
- [Tense Flow](tense-flow.md) — tense-flow picking bypasses storage : pick directly from a source support into a client container via the `PREPARATION` buffer
+- [Tense Flow](tense-flow.md) - tense-flow picking bypasses storage : pick directly from a source support into a client container via the `PREPARATION` buffer
@@ -31,7 +31,7 @@ A prepackaging strategy has the following fields:
 |---|---|---|
 | **Code** | free text | Strategy name |
 | **Type de commande** | Fusion / Ordre de départ sans envoi / Vague | Which outbound grouping this strategy applies to |
-| **Processus** | Emballage / Préparation | When it is applied — at packing station or during picking |
+| **Processus** | Emballage / Préparation | When it is applied - at packing station or during picking |
 | **Type de précolisage** | Calculé par EasyWMS / Calculé par l'opérateur / Calculé par l'ERP | Who computes the container split |
 | **Mode de travail** | Strict / Pas strict | Strict = operator cannot deviate from the plan ; non-strict = operator can override |
 | **Logique de pré emballage** | Nombre minimum de colis / Volume minimum | "Fewest parcels" picks the largest container possible ; "Minimum volume" picks the smallest container possible |
@@ -46,7 +46,7 @@ For `Calculé par EasyWMS` to work:
 1. **Container types** must be configured in EasyS and associated to equipments.
 2. **Item dimensions and weight** must be populated (in conversions).
-3. **Mixing restrictions** between items must be defined — by item, by family, or by type.
+3. **Mixing restrictions** between items must be defined - by item, by family, or by type.
 ## Calculation by ERP (SOR02)
@@ -75,11 +75,11 @@ When `Calculé par l'ERP`, the outbound order message carries a `<PrepackagingCo
 ```
 Keys in this block:
- `PrepackagingProcess` — `Picking` or `Packing`
+- `PrepackagingProcess` - `Picking` or `Packing`
- `PrepackagingWorkingMode` — `Strict` / `NotStrict`
+- `PrepackagingWorkingMode` - `Strict` / `NotStrict`
- `PrepOrderContainer` — client container SSCC that must be used
+- `PrepOrderContainer` - client container SSCC that must be used
- `PrepContainerType` — container-type code (must exist in EasyWMS)
+- `PrepContainerType` - container-type code (must exist in EasyWMS)
- `PrepackagingLines.PrepackagingLine` — quantity per outbound line that belongs in this container
+- `PrepackagingLines.PrepackagingLine` - quantity per outbound line that belongs in this container
 ## Tested Behavior (Mecalux France, 2022)
@@ -90,7 +90,7 @@ Confirmed working vs. known-broken combinations:
 | Ordre de départ / Strict / Nombre minimum / poids normal | 1 carton L |
 | Ordre de départ / Strict / Nombre minimum / poids > seuil | Carton L (poids reste < 20 kg) |
 | Ordre de départ / Strict / Nombre minimum / famille non mélangeable | Articles répartis dans colis différents ✅ |
-| Ordre de départ / Strict / Nombre minimum / **type** non mélangeable | ❌ **non fonctionnel** — articles mélangés malgré la restriction |
+| Ordre de départ / Strict / Nombre minimum / **type** non mélangeable | ❌ **non fonctionnel** - articles mélangés malgré la restriction |
 | Ordre de départ / Strict / Volume minimum | 3 conteneurs différents |
 | Vague / Strict / Volume minimum | Calcul réalisé par commande |
 | **Calcul par l'opérateur** | ❌ **non fonctionnel** |
@@ -101,7 +101,7 @@ Confirmed working vs. known-broken combinations:
 **The strategy has no effect even though it is saved** : it was not activated. Re-open the strategy and toggle activation.
-**`Calcul par EasyWMS` produces no containers** : item dimensions/weight missing, or no container type is associated to the equipment — both are prerequisites.
+**`Calcul par EasyWMS` produces no containers** : item dimensions/weight missing, or no container type is associated to the equipment - both are prerequisites.
 **`Type de commande = Ordre de départ sans envoi`** : applies to the simple single-order case ; for waves or fusions, pick the corresponding `Type de commande`, otherwise the strategy is ignored for those grouping types.
@@ -109,7 +109,7 @@ Confirmed working vs. known-broken combinations:
 ## Related
- [Shipping](shipping.md) — the surrounding outbound process ; prepackaging is one step of it
+- [Shipping](shipping.md) - the surrounding outbound process ; prepackaging is one step of it
- [Outbound Order](order-outbound.md) — SOR02 carries `PrepackagingConfiguration` ; SOF carries the actually used containers
+- [Outbound Order](order-outbound.md) - SOR02 carries `PrepackagingConfiguration` ; SOF carries the actually used containers
- [Container (LPN)](container.md) — container types and SSCCs referenced by prepackaging
+- [Container (LPN)](container.md) - container types and SSCCs referenced by prepackaging
- [ERP Interface](erp-interface.md) — full field tables for SOR02
+- [ERP Interface](erp-interface.md) - full field tables for SOR02
@@ -48,7 +48,7 @@ last_compiled: "2026-04-17"
 ## Overview
-An **item** is the primary static master data element in Easy WMS. It represents each distinct product that an organization manages in its warehouse. Almost every WMS behavior — reception, putaway, picking, shipping, counting, replenishment — is governed by item configuration.
+An **item** is the primary static master data element in Easy WMS. It represents each distinct product that an organization manages in its warehouse. Almost every WMS behavior - reception, putaway, picking, shipping, counting, replenishment - is governed by item configuration.
 A critical distinction: the **item** is the master definition (SKU, attributes, rules), while **stock** is the physical instance of that item (a quantity of that item in a specific location/container with specific logistic attributes). The same item code can have stock across many locations simultaneously. Multiple owners can also hold stock of the same item code.
@@ -72,9 +72,9 @@ Item families define mixing restrictions for **client containers** (containers b
 Use case: prevent mixing refrigerated and ambient items in the same outbound parcel.
 When the **Multi-Carrier module** is active, item families also carry a **packaging method** that controls how the carrier call is generated:
- `Scan all items` — operator scans each item into a parcel
+- `Scan all items` - operator scans each item into a parcel
- `Choose parcel count` — operator declares how many parcels; system moves all stock into parcel 1 (no automatic weight)
+- `Choose parcel count` - operator declares how many parcels; system moves all stock into parcel 1 (no automatic weight)
- `1 parcel always` — no operator input; system assumes single-parcel shipment (for high-volume B2C)
+- `1 parcel always` - no operator input; system assumes single-parcel shipment (for high-volume B2C)
 The most restrictive method in an order takes precedence (Scan > Choose > 1 parcel).
@@ -87,7 +87,7 @@ The ABC classification indicates the rotation/activity level of an item relative
 Used in slotting optimization and putaway strategy rules to position items strategically.
-**Operating principles.** The higher the class's movement threshold, the more important it is (A > B > C). Articles with the most movements are classified in the highest class. **Thresholds represent cumulative movement share** — an A article = top 50%, a B = top 80% (50+30), etc.
+**Operating principles.** The higher the class's movement threshold, the more important it is (A > B > C). Articles with the most movements are classified in the highest class. **Thresholds represent cumulative movement share** - an A article = top 50%, a B = top 80% (50+30), etc.
 When an article straddles two classes, the `Type de calcul` chosen at evaluation decides :
@@ -103,16 +103,16 @@ When an article straddles two classes, the `Type de calcul` chosen at evaluation
 **First assignment.** On first setup, every article is set to the **lowest rotation class**. This should be done in the article-base import ; when a new article is later created, this field must be populated manually.
-**ABC evaluation (runtime)** — `Tableaux de Bord → Evaluation ABC` (recent versions). Parameters :
+**ABC evaluation (runtime)** - `Tableaux de Bord → Evaluation ABC` (recent versions). Parameters :
- **Date** — `Start-end date` or `By number of day`
+- **Date** - `Start-end date` or `By number of day`
- **Mouvements** — task types to include (at least one required)
+- **Mouvements** - task types to include (at least one required)
- **Type de calcul** — `Inclusive` or `Exclusive`
+- **Type de calcul** - `Inclusive` or `Exclusive`
 Execute then **refresh the grid** to see the results. Results persist until the next evaluation.
 **Reading the result grid :**
- **Red lines** — article is **over-rated** vs. the evaluation (its stored class is more important than measured activity).
+- **Red lines** - article is **over-rated** vs. the evaluation (its stored class is more important than measured activity).
- **Green lines** — article is **under-rated** (measured activity higher than stored class).
+- **Green lines** - article is **under-rated** (measured activity higher than stored class).
 - Conforming articles are not listed.
 The classification can be edited inline from the evaluation grid.
@@ -121,7 +121,7 @@ The classification can be edited inline from the evaluation grid.
 ## Units of Measure (UoM)
-Every item must have a **base UoM** — the reference unit for all conversions. All stock quantities are stored and reported in the base UoM.
+Every item must have a **base UoM** - the reference unit for all conversions. All stock quantities are stored and reported in the base UoM.
 Additional **conversions and presentations** (EAN/GTIN presentations) define the commercial packaging:
 - Each conversion specifies the quantity of base UoM it contains (e.g., BOX12 = 12 units)
@@ -160,13 +160,13 @@ Logistic attributes are characteristics that condition the logistic behavior of
 ### Creating a logistic attribute without a capture mode
-By default, every logistic attribute requires a capture mode (manual, scan, etc.). In some custom flows the attribute must be **auto-generated by code** (e.g., serial number generated server-side) and therefore must exist **without** any capture mode — otherwise SmartUI / RFT will always prompt the operator.
+By default, every logistic attribute requires a capture mode (manual, scan, etc.). In some custom flows the attribute must be **auto-generated by code** (e.g., serial number generated server-side) and therefore must exist **without** any capture mode - otherwise SmartUI / RFT will always prompt the operator.
-> ⚠️ Once configured this way, the attribute value can no longer be edited from SmartUI or RFT without a custom — the only writer is the custom code that creates the stock.
+> ⚠️ Once configured this way, the attribute value can no longer be edited from SmartUI or RFT without a custom - the only writer is the custom code that creates the stock.
 **Procedure** (requires Admin role + Run Command access):
-1. **Create the logistic profile** and add the attribute of the desired type. The capture mode is mandatory at creation — set it to `Manual` (it will be deleted in step 4).
+1. **Create the logistic profile** and add the attribute of the desired type. The capture mode is mandatory at creation - set it to `Manual` (it will be deleted in step 4).
 2. **Collect the identifiers** with a Run Query on the reading context:
    ```csharp
    Context.LogisticAttributes.Select(la => new {
@@ -197,7 +197,7 @@ By default, every logistic attribute requires a capture mode (manual, scan, etc.
 ## Profiles
-Profiles define item behavior in each WMS process. They allow bulk configuration — many items can share the same profile.
+Profiles define item behavior in each WMS process. They allow bulk configuration - many items can share the same profile.
 | Profile | Required | Purpose |
 |---|---|---|
@@ -306,14 +306,14 @@ In `SOR01` / `SOR02`, on the relevant `<Line>` elements :
 </LneTerms>
 ```
-### 2. Shipping profile — substitution mode
+### 2. Shipping profile - substitution mode
 Every item involved in the substitution must carry a shipping profile (`Données principales → Détails d'articles → Profils d'expédition`). The mode (X = requested item, Y = substitute) is :
 | Mode | Behavior |
 |---|---|
 | **Partiel** | Sums X + Y to reach the requested quantity. X is prioritized. |
-| **Substitution** | Picks X **or** Y exclusively — whichever quantity is closest to the requested one. |
+| **Substitution** | Picks X **or** Y exclusively - whichever quantity is closest to the requested one. |
 | **Tout ou rien** | If X + Y cannot reach the requested quantity, picks **only X** regardless of its quantity. |
 > ⚠️ For components of **non-assembled kits**, the mode **must be `Partiel`**.
@@ -334,7 +334,7 @@ In `Données principales → Articles`, select the **item to be replaced**, clic
 |---|---|
 | Only X picked | `<LneDIsAlternative>false</LneDIsAlternative>` |
 | X + Y picked | Two `<LneDetail>` blocks : one with `LneDIsAlternative=false` (X), one with `LneDIsAlternative=true` (Y) |
-| Only Y picked | Single `<LneDetail>` with `LneDIsAlternative=true` — `<LneItemCode>` still contains **X** (the requested item) |
+| Only Y picked | Single `<LneDetail>` with `LneDIsAlternative=true` - `<LneItemCode>` still contains **X** (the requested item) |
 ## Labeling
@@ -420,16 +420,16 @@ Key parameters:
 ## Related
- [[stock]] — stock is the physical instance of an item; stock lines carry item code, owner, logistic attributes
+- [[stock]] - stock is the physical instance of an item; stock lines carry item code, owner, logistic attributes
- [[container]] — containers hold item stock; item stackability controls order of picking into client containers
+- [[container]] - containers hold item stock; item stackability controls order of picking into client containers
- [[reception]] — reception profile drives behavior at inbound; logistic attributes captured during receipt
+- [[reception]] - reception profile drives behavior at inbound; logistic attributes captured during receipt
- [[putaway]] — putaway profile defines strategies for this item; temperature/hazard/ABC attributes feed strategy filters
+- [[putaway]] - putaway profile defines strategies for this item; temperature/hazard/ABC attributes feed strategy filters
- [[picking]] — shipping profile and logistic attributes drive picking behavior; substitutes used on stock failure
+- [[picking]] - shipping profile and logistic attributes drive picking behavior; substitutes used on stock failure
- [[shipping]] — shipping profile mandatory; families control client container mixing; substitutes activated on shortage
+- [[shipping]] - shipping profile mandatory; families control client container mixing; substitutes activated on shortage
- [[count]] — count profile defines item counting behavior (ABC-driven cycle counts)
+- [[count]] - count profile defines item counting behavior (ABC-driven cycle counts)
- [[order-inbound]] — ROR lines reference items by code or presentation alias
+- [[order-inbound]] - ROR lines reference items by code or presentation alias
- [[order-outbound]] — SOR lines reference items; logistic attribute filtering drives stock assignment
+- [[order-outbound]] - SOR lines reference items; logistic attribute filtering drives stock assignment
- [[cutting-stock]] — cutting profile marks item as cut item; enables min/max quantities and cut label printing
+- [[cutting-stock]] - cutting profile marks item as cut item; enables min/max quantities and cut label printing
- [[labels]] — item labels printed at reception, from stock view, and from RFT utilities
+- [[labels]] - item labels printed at reception, from stock view, and from RFT utilities
- [[erp-interface]] — ITM message manages item master from ERP; SAC01 sends ABC classification back to ERP
+- [[erp-interface]] - ITM message manages item master from ERP; SAC01 sends ABC classification back to ERP
- [[kits]] — kit articles and component articles are both standard items; kit assembly consumes component stock
+- [[kits]] - kit articles and component articles are both standard items; kit assembly consumes component stock
@@ -52,10 +52,10 @@ The putaway strategy engine is the core of location search. Two complementary st
 Each strategy (both types) is composed of four elements:
-1. **Criterion** — Conditions that the container or stock must satisfy for the strategy to be a candidate (source, container type, stock properties, item classification, etc.)
+1. **Criterion** - Conditions that the container or stock must satisfy for the strategy to be a candidate (source, container type, stock properties, item classification, etc.)
-2. **Rule** — Conditions that the destination location must satisfy (location type, zone, aisle, height, mixing restrictions, etc.)
+2. **Rule** - Conditions that the destination location must satisfy (location type, zone, aisle, height, mixing restrictions, etc.)
-3. **Restrictions** — Mixing constraints that determine which combinations of items/attributes/owners are allowed in the same location or channel
+3. **Restrictions** - Mixing constraints that determine which combinations of items/attributes/owners are allowed in the same location or channel
-4. **Sorting** — Preference ordering of valid locations (by distance, coordinates, fill level, item affinity, etc.)
+4. **Sorting** - Preference ordering of valid locations (by distance, coordinates, fill level, item affinity, etc.)
 Strategies are sequenced: if criteria for strategy N are not met, strategy N+1 is evaluated. The sequence continues until a location is found or all strategies are exhausted.
@@ -63,33 +63,33 @@ Strategies are sequenced: if criteria for strategy N are not met, strategy N+1 i
 The web UI exposes the strategy engine through two tabs : **Critères** and **Règles**.
-**Sequence management.** Strategies are ordered by **sequence number** — lower = higher priority. The list view exposes **"Augmenter séquence"** / **"Diminuer séquence"** buttons to adjust priorities. The **last-sequence strategy must be a catch-all** (any item, any available location), otherwise the engine may exhaust the list and return no proposal to the operator.
+**Sequence management.** Strategies are ordered by **sequence number** - lower = higher priority. The list view exposes **"Augmenter séquence"** / **"Diminuer séquence"** buttons to adjust priorities. The **last-sequence strategy must be a catch-all** (any item, any available location), otherwise the engine may exhaust the list and return no proposal to the operator.
-**Onglet Critères** — "Rechercher un emplacement pour" offers :
+**Onglet Critères** - "Rechercher un emplacement pour" offers :
 | Option | Description |
 |---|---|
 | Conteneur client | Client (outbound) containers only |
 | Conteneur vide | Empty containers |
-| Profil de stockage | Only items with the specified putaway profile — ⚠️ *if an item has a profile, only profile-matching strategies apply to it* |
+| Profil de stockage | Only items with the specified putaway profile - ⚠️ *if an item has a profile, only profile-matching strategies apply to it* |
 | Conteneur ou stock | Loose stock or any container |
 The **"Stock libre"** checkbox restricts the strategy to loose stock (containers excluded). Below, a **Stock** section filters on : stock status, supplier, ABC rotation, item type, owner, hazard codes. The **Station d'origine** block is used for robotic installations.
-**Onglet Règles — "Rechercher un emplacement"** exposes two UI-specific controls not named in the pipeline above :
+**Onglet Règles - "Rechercher un emplacement"** exposes two UI-specific controls not named in the pipeline above :
 | Parameter | Values |
 |---|---|
 | **Mode de stockage** | N'importe quel / Conteneur uniquement / Stock Libre uniquement |
 | **Valable si** | Emplacement vide ou avec stock / Avec stock uniquement / Canal vide uniquement / Canal avec stock uniquement |
-Remaining rule fields match *Stage 6* above (rack type, specific location, X/Y coordinates, side 0=gauche/1=droite, height min/max, max weight, **Article assigné** — PDL-like assigned-location search, type/aisle, zone, min/max temperature, entrepôt annexe).
+Remaining rule fields match *Stage 6* above (rack type, specific location, X/Y coordinates, side 0=gauche/1=droite, height min/max, max weight, **Article assigné** - PDL-like assigned-location search, type/aisle, zone, min/max temperature, entrepôt annexe).
 > Crossdocking locations live in the crossdocking sub-warehouse : if the strategy leaves `entrepôt annexe` empty, the engine considers both the main and the crossdocking sub-warehouses.
-**Onglet Règles — "Appliquer restrictions"** checkboxes : `Appliquer restrictions`, `Articles combinés`, `Mélanger des conversions`, `Combiner attributs logistiques`, `Utiliser jours de mélange`, `Mélanger types de conteneurs`, `Rangement partiel de stock`.
+**Onglet Règles - "Appliquer restrictions"** checkboxes : `Appliquer restrictions`, `Articles combinés`, `Mélanger des conversions`, `Combiner attributs logistiques`, `Utiliser jours de mélange`, `Mélanger types de conteneurs`, `Rangement partiel de stock`.
-**Onglet Règles — "Order locations"** mirrors *Stage 7* sorting. Recommended default for manual warehouses : `Coord X ASC` (seq 1), `Coord Y ASC` (seq 2).
+**Onglet Règles - "Order locations"** mirrors *Stage 7* sorting. Recommended default for manual warehouses : `Coord X ASC` (seq 1), `Coord Y ASC` (seq 2).
 ### Activation, Deactivation, and Editing
@@ -104,7 +104,7 @@ A strategy takes effect only after explicit **activation**. To modify an existin
 ## Location Search Pipeline (Putaway Strategies)
-### Stage 1 — Filter valid strategies by criteria
+### Stage 1 - Filter valid strategies by criteria
 EasyWMS filters all enabled strategies for the warehouse against five criterion groups:
@@ -121,7 +121,7 @@ EasyWMS filters all enabled strategies for the warehouse against five criterion
 **Stock criteria:** supplier, status (inbound/outbound), expired stock flag.
-### Stage 2 — Obtain valid aisles
+### Stage 2 - Obtain valid aisles
 EasyWMS selects accessible aisles reachable by route from the container/stock's current location (direct or indirect routes). For **automatic aisles**, aisles that have exceeded the configured percentage of free locations for relocation are excluded to prevent blocking outbound movements.
@@ -129,7 +129,7 @@ Occupancy calculation differs by location structure:
 - **APS (depth control):** counts valid depths per container type vs. occupied depths
 - **Rack (position control):** counts valid positions per container type vs. occupied positions (considering mask blocking even for unoccupied positions that have tasks)
-### Stage 3 — Aisle balancing (automatic warehouses, containers only)
+### Stage 3 - Aisle balancing (automatic warehouses, containers only)
 When enabled via parameter `BALANCE_AISLE`, EasyWMS balances load across valid aisles using the formula:
@@ -141,7 +141,7 @@ Default weights: X=5, Y=1, Z=7 (configurable with expiry date). The aisle with t
 For multi-reference containers, the item with the largest quantity (base UoM) is used for balancing.
-### Stage 4 — Apply restrictions
+### Stage 4 - Apply restrictions
 Location restrictions (configured globally, independent of strategies) discard candidate locations where two incompatible items/item-types would be co-located. Restrictions are applied only when the strategy rule has "Use restrictions" checked.
@@ -156,7 +156,7 @@ Location restrictions (configured globally, independent of strategies) discard c
 Restrictions can be scoped to a specific sub-warehouse. They must be enabled and referenced in the strategy to take effect.
-### Stage 5 — Filter valid locations (physical/logical checks)
+### Stage 5 - Filter valid locations (physical/logical checks)
 From remaining candidates, EasyWMS applies a hard validity checklist:
@@ -169,7 +169,7 @@ From remaining candidates, EasyWMS applies a hard validity checklist:
 Route validity is also checked: there must be a station route from the container/stock's current station to the candidate location's station. For equipment-based searches, maximum reachable height and work area access are additionally validated.
-### Stage 6 — Apply strategy rule filters
+### Stage 6 - Apply strategy rule filters
 The strategy rule further filters candidate locations by:
@@ -194,7 +194,7 @@ The strategy rule further filters candidate locations by:
 Empty locations are always valid regardless of mixing configuration.
-### Stage 7 — Sort locations by preferences
+### Stage 7 - Sort locations by preferences
 Valid locations are sorted according to the strategy's configured preferences (in priority order):
@@ -214,7 +214,7 @@ Valid locations are sorted according to the strategy's configured preferences (i
 | Proximity relocation | Move to closest location (same-aisle relocations only) |
 | APS3D level ↑↓ | APS3D aisle level (if APS3D module installed) |
-### Stage 8 — Select optimal location and create task
+### Stage 8 - Select optimal location and create task
 EasyWMS selects the top-ranked location and creates a **Location task** to move the container/stock there. For traced containers, the task targets the base container of the trace hierarchy.
@@ -247,24 +247,24 @@ Channel strategies group equivalent containers (same type + height + stock refer
 ### Channel strategy configuration (SmartUI)
-Channel filling strategies are set up under `Configuration → Stratégies de remplissage de canaux`. Unlike standard putaway strategies, **channel strategies are not sequenced** — the WMS picks the first eligible strategy in the list. Because of this, criteria must be narrow enough to distinguish between strategies.
+Channel filling strategies are set up under `Configuration → Stratégies de remplissage de canaux`. Unlike standard putaway strategies, **channel strategies are not sequenced** - the WMS picks the first eligible strategy in the list. Because of this, criteria must be narrow enough to distinguish between strategies.
-**EasyS prerequisite.** Racks must be typed as `APS`, `Push Back`, `Dynamic Push Back`, or `Multi-Compact`. Without one of these rack types, the `EmptyChannels_ForContainer` query returns nothing and channel search returns empty. Each location must also declare a **number of authorized containers** — the WMS uses this to compute channel capacity.
+**EasyS prerequisite.** Racks must be typed as `APS`, `Push Back`, `Dynamic Push Back`, or `Multi-Compact`. Without one of these rack types, the `EmptyChannels_ForContainer` query returns nothing and channel search returns empty. Each location must also declare a **number of authorized containers** - the WMS uses this to compute channel capacity.
 **Two mandatory criteria fields:**
 | Field | Purpose |
 |---|---|
-| **Postes sources à considérer** | Source stations from which a container becomes eligible. If the equipment's current station is not in this list, the strategy does not apply — even if the container otherwise matches. |
+| **Postes sources à considérer** | Source stations from which a container becomes eligible. If the equipment's current station is not in this list, the strategy does not apply - even if the container otherwise matches. |
 | **Stations à considérer pour les supports candidats** | Buffer stations used to count containers to be placed. Example: if only `RECEPTION` is listed, the WMS searches other eligible containers at `RECEPTION` and looks for a channel with enough capacity to hold them all. |
-**Rule fields** filter destination candidates: storage zones (prioritised), putaway preferences, min/max location height, total weight of candidate containers, **Utiliser l'équilibrage des allées** (boolean — reuses the aisle balance configured on standard putaway strategies).
+**Rule fields** filter destination candidates: storage zones (prioritised), putaway preferences, min/max location height, total weight of candidate containers, **Utiliser l'équilibrage des allées** (boolean - reuses the aisle balance configured on standard putaway strategies).
 **Reservation timeout.** The **Paramétrage du temps de réservation** field sets the maximum reservation lifetime; expired reservations are dropped automatically.
 **Reservation view.** `Entrepôt → Réservations` shows, per reservation: originating strategy, destination location, item, owner, **remaining containers** on the reservation, PLC height type.
-> ⚠️ Reservations are created **at putaway time only** — there is no background job reserving channels based on existing stock. A candidate container triggers the search and reserves a channel for itself + all buffer peers at that moment.
+> ⚠️ Reservations are created **at putaway time only** - there is no background job reserving channels based on existing stock. A candidate container triggers the search and reserves a channel for itself + all buffer peers at that moment.
 ## Putaway Flow by Object Type
@@ -293,7 +293,7 @@ Similar flow to container putaway, but:
 ### Cutting Stock Putaway (RFT)
-Cutting stock (items sold/stored by length/stretch) requires total-quantity handling — stretches cannot be split. Three modes:
+Cutting stock (items sold/stored by length/stretch) requires total-quantity handling - stretches cannot be split. Three modes:
 1. **Select then locate**: choose the stretch, confirm/enter destination
 2. **Guided unload**: system proposes destination for each stretch in sequence
 3. **Manual unload**: enter destination to unload all equipment stock at once
@@ -358,8 +358,8 @@ Strategy coverage expected per rack type (Mecalux France defaults):
 **Double-depth racks:**
 - Ascending height + Rotation + Stock balancing
- Avoid product mixing — causes relocations during picking
+- Avoid product mixing - causes relocations during picking
- Avoid logistic-attribute / quantity mixing — depends on shipping logic
+- Avoid logistic-attribute / quantity mixing - depends on shipping logic
 **>2-depth (APS) channels:**
 - Ascending height + Rotation + Balancing
@@ -369,16 +369,16 @@ Strategy coverage expected per rack type (Mecalux France defaults):
 ### Empty-location headroom
-**Standard value: 5%** empty locations — required for relocation work and flow variation absorption. Lower values starve the relocation and defragmentation jobs.
+**Standard value: 5%** empty locations - required for relocation work and flow variation absorption. Lower values starve the relocation and defragmentation jobs.
 ### Double-depth layout patterns (EasyS)
 Two rack configurations for double-depth (TK / miniload):
- **Case #1** (most common at Mecalux France) — best for **mono-product supports**: rotation zones split by front / rear face (several supports with the same article live in the TK)
+- **Case #1** (most common at Mecalux France) - best for **mono-product supports**: rotation zones split by front / rear face (several supports with the same article live in the TK)
- **Case #2** — best for **multi-product supports**: reduces picking-time relocations without pre-emptive defragmentation (an item never lives in two supports at once)
+- **Case #2** - best for **multi-product supports**: reduces picking-time relocations without pre-emptive defragmentation (an item never lives in two supports at once)
-Choose the pattern **before** running rotation class setup — switching costs a full re-slotting.
+Choose the pattern **before** running rotation class setup - switching costs a full re-slotting.
 ## Parameters
@@ -393,35 +393,35 @@ Choose the pattern **before** running rotation class setup — switching costs a
 **No valid location found (automatic warehouse):** Rejection task generated. Container goes to rejection station. Common causes: all aisles at relocation % limit, no route between current station and any candidate location, weight exceeded everywhere.
-**Aisle balancing blocks putaway:** Aisle is chosen by balance formula but has no valid location (e.g., full or incompatible). System does not fall back to other aisles for that strategy — next strategy in sequence is tried instead. Ensure next strategy has adequate coverage.
+**Aisle balancing blocks putaway:** Aisle is chosen by balance formula but has no valid location (e.g., full or incompatible). System does not fall back to other aisles for that strategy - next strategy in sequence is tried instead. Ensure next strategy has adequate coverage.
 **Container stuck in equipment:** Container loaded on equipment but operator ended session without locating. Container remains in equipment indefinitely. Resolve via manual relocation from the equipment management view.
 **Picking dedicated location not proposed:** Item has no PDL created yet, or PDL is for different logistic attributes. Either create a PDL for the correct attributes, or ensure strategy sequence 1 (assigned location) handles this item.
-**Cutting stock putaway fails validation:** Operator entered partial quantity instead of full stretch quantity. Cutting stock requires total-quantity entry — reject partial entries at the RFT.
+**Cutting stock putaway fails validation:** Operator entered partial quantity instead of full stretch quantity. Cutting stock requires total-quantity entry - reject partial entries at the RFT.
 ## Interface Paths
 | Interface | Path |
 |---|---|
-| RFT — container/loose stock putaway | Menu "Putaway" → "Containers/Loose stock" or "Containers" |
+| RFT - container/loose stock putaway | Menu "Putaway" → "Containers/Loose stock" or "Containers" |
-| RFT — stock putaway | Menu "Location" → "Containers/Loose stock" or "Stocks" |
+| RFT - stock putaway | Menu "Location" → "Containers/Loose stock" or "Stocks" |
-| Web — putaway strategies | "Configuration" → "Putaway strategies" |
+| Web - putaway strategies | "Configuration" → "Putaway strategies" |
-| Web — aisle balancing | "Putaway strategies" → "Configuration" → "Aisle Balance" |
+| Web - aisle balancing | "Putaway strategies" → "Configuration" → "Aisle Balance" |
-| Web — restrictions | "Configuration" → "Restrictions" |
+| Web - restrictions | "Configuration" → "Restrictions" |
-| Web — channel filling strategies | "Configuration" → "Stratégies de remplissage de canaux" |
+| Web - channel filling strategies | "Configuration" → "Stratégies de remplissage de canaux" |
-| Web — channel reservations | "Entrepôt" → "Réservations" |
+| Web - channel reservations | "Entrepôt" → "Réservations" |
 ## Related
- [Container (LPN)](container.md) — the primary object being putaway; types, lock types, and weights are key strategy criteria
+- [Container (LPN)](container.md) - the primary object being putaway; types, lock types, and weights are key strategy criteria
- [Reception](reception.md) — putaway typically follows reception; containers can be placed directly from reception
+- [Reception](reception.md) - putaway typically follows reception; containers can be placed directly from reception
- [Replenishment](replenishment.md) — replenishment reuses the putaway strategy engine to move stock to picking dedicated locations
+- [Replenishment](replenishment.md) - replenishment reuses the putaway strategy engine to move stock to picking dedicated locations
- [Location](location.md) — location types (rack, APS, compact, dynamic, pushback) determine which strategy type applies
+- [Location](location.md) - location types (rack, APS, compact, dynamic, pushback) determine which strategy type applies
- [Stock](stock.md) — stock status and logistic attributes are criteria and restrictions in putaway strategies
+- [Stock](stock.md) - stock status and logistic attributes are criteria and restrictions in putaway strategies
- [GALILEO Integration](../architecture/galileo-integration.md) — how TMS drives physical execution of putaway tasks
+- [GALILEO Integration](../architecture/galileo-integration.md) - how TMS drives physical execution of putaway tasks
- [Galileo Simulation](../operations/galileo-simulation.md) — EasyS setup for double-depth racks, PLC Types, reject routes
+- [Galileo Simulation](../operations/galileo-simulation.md) - EasyS setup for double-depth racks, PLC Types, reject routes
- [Task](task.md) — putaway generates Putaway tasks; automatic warehouse also uses Approach tasks for Pick & Pass
+- [Task](task.md) - putaway generates Putaway tasks; automatic warehouse also uses Approach tasks for Pick & Pass
- [Product / Item](product-item.md) — putaway profile on the item links strategies; hazard, temperature, and ABC classification feed strategy criteria
+- [Product / Item](product-item.md) - putaway profile on the item links strategies; hazard, temperature, and ABC classification feed strategy criteria
- [Defragmentation](defragmentation.md) — rotation defragmentation reuses putaway strategies to relocate containers to their optimal ABC zone
+- [Defragmentation](defragmentation.md) - rotation defragmentation reuses putaway strategies to relocate containers to their optimal ABC zone
@@ -30,7 +30,7 @@ EasyWMS controls stock quality from reception through shipping. Statuses can be
 - **In the warehouse** (web interface, RFT, or ERP message)
 - At **shipping** (to require or prefer stock in a specific status for a shipping order line)
-> **Important:** The _Expired_ state is **not** a stock status — stock expires automatically when logistic attribute dates (expiry date, best before date, end of life) are reached.
+> **Important:** The _Expired_ state is **not** a stock status - stock expires automatically when logistic attribute dates (expiry date, best before date, end of life) are reached.
 ---
@@ -48,8 +48,8 @@ Each stock status is configured to block or allow specific operations:
 | Internal use (manufacturing) | Yes |
 A single stock record can have two simultaneous statuses:
- **Receiving status** — set at reception time (from profile, order line, or operator)
+- **Receiving status** - set at reception time (from profile, order line, or operator)
- **User status** — applied manually by an operator, manager, or via ERP message
+- **User status** - applied manually by an operator, manager, or via ERP message
 ---
@@ -187,7 +187,7 @@ Both partial and total locks can be performed from **RFT** or **ERP** (STR messa
 |---|---|
 | `CST.STK` | Stock status applied or removed (when reception is closed) |
-Note: `CST.STK` is **not** generated if the reception is still open — changes are visible in the interface but not audited until reception closes.
+Note: `CST.STK` is **not** generated if the reception is still open - changes are visible in the interface but not audited until reception closes.
 ---
@@ -206,8 +206,8 @@ STC is only sent when the **reception is closed**. For stock from open reception
 - A stock can have both a **receiving status** (set at reception) and a **user status** (set manually) simultaneously.
 - When a lock is applied, EasyWMS immediately checks all active tasks and assignments using that stock and adapts them (cancels or decrements) based on the operations the lock blocks.
- Expired stock (`_Expired_` state) is handled by the logistic attributes expiry system — not the quality lock system.
+- Expired stock (`_Expired_` state) is handled by the logistic attributes expiry system - not the quality lock system.
- Only locations that allow inventory can have their stock counted. Quality locks do not change this — but locks that prevent counting block task generation.
+- Only locations that allow inventory can have their stock counted. Quality locks do not change this - but locks that prevent counting block task generation.
 - The 15-minute job for automatic unlock means that very short-duration locks (< 15 min) are not reliably supported.
 ---
@@ -253,10 +253,10 @@ STC is only sent when the **reception is closed**. For stock from open reception
 ## Related
- [[stock]] — Quality locks are stored as stock status fields; stock must have no movement-blocking lock to be picked, replenished, or shipped
+- [[stock]] - Quality locks are stored as stock status fields; stock must have no movement-blocking lock to be picked, replenished, or shipped
- [[container]] — Locks can be applied at container granularity; all stock in a container can be locked in one operation
+- [[container]] - Locks can be applied at container granularity; all stock in a container can be locked in one operation
- [[reception]] — Receiving status is applied at reception time via profile, order line, or operator; STC sent at close
+- [[reception]] - Receiving status is applied at reception time via profile, order line, or operator; STC sent at close
- [[order-outbound]] — Shipping order lines can specify required/preferred stock status for assignment
+- [[order-outbound]] - Shipping order lines can specify required/preferred stock status for assignment
- [[product-item]] — Item receiving profile defines automatic lock status and duration at inbound
+- [[product-item]] - Item receiving profile defines automatic lock status and duration at inbound
- [[stock-adjustment]] — Both quality control and stock adjustment use STC/STK.ADJ transactions; quality locks affect task/assignment eligibility
+- [[stock-adjustment]] - Both quality control and stock adjustment use STC/STK.ADJ transactions; quality locks affect task/assignment eligibility
- [[cutting-stock]] — Cutting stock has partial/total lock behavior; lock can propagate to cut portions
+- [[cutting-stock]] - Cutting stock has partial/total lock behavior; lock can propagate to cut portions
@@ -34,7 +34,7 @@ last_compiled: "2026-04-17"
 Reception is the process by which stock physically arrives at the warehouse and is formally registered in EasyWMS. Until a receipt is completed and closed, the arrived stock does not exist for any other WMS process (picking, replenishment, shipping). Reception is therefore the entry gate between the physical world and the logical warehouse state.
-EasyWMS supports five distinct reception entry points — each suited to a different physical configuration and information context: **Dock** (manual, RFT-driven), **ASN** (pre-notified containers), **PIE** (automated sensor gate), **PK** (picking conveyor), and **Returns** (customer returns). All share the same fundamental structure: a **Receipt** groups received stock lines, and optionally links to a **Receipt Order** (planned) or generates one ad hoc (blind).
+EasyWMS supports five distinct reception entry points - each suited to a different physical configuration and information context: **Dock** (manual, RFT-driven), **ASN** (pre-notified containers), **PIE** (automated sensor gate), **PK** (picking conveyor), and **Returns** (customer returns). All share the same fundamental structure: a **Receipt** groups received stock lines, and optionally links to a **Receipt Order** (planned) or generates one ad hoc (blind).
 The reception output is always a REF message to the ERP confirming what was received, and an ASO message (for pre-notified containers) or similar notification per entry point.
@@ -121,7 +121,7 @@ Supports **exclusive reserve** at receipt time: stock received can be pre-reserv
 Unplanned stock with no prior notification or entry order.
- A receipt is automatically created (and closed at end) — transparent to the user.
+- A receipt is automatically created (and closed at end) - transparent to the user.
 - The receipt cannot be created or edited from the WMS UI.
 - Supports: multi-reference LPN, single-SKU LPN (labeled/unlabeled/identical), loose stock, cutting stock.
 - Communicates to ERP via `REF` after blind receipt close.
@@ -133,8 +133,8 @@ Unplanned stock with no prior notification or entry order.
 Customer-returned stock coming back to the warehouse.
 - Can be linked to a receipt order (if created from the web) or not (if created from RFT).
- If created from RFT: no lines initially — lines are added as stock is received.
+- If created from RFT: no lines initially - lines are added as stock is received.
- Date logistic attributes (expiry, shelf life) are captured but **not validated** — expired stock may be returned and must be managed after receipt.
+- Date logistic attributes (expiry, shelf life) are captured but **not validated** - expired stock may be returned and must be managed after receipt.
 - Supports: containers, loose stock, cutting stock, exclusive reserves.
 - Custom code prefix configurable: `RETURN_RECEPTION_PREFIX`
@@ -180,14 +180,14 @@ Used when the ERP has pre-notified containers via `ASN` message before they phys
 - Web: `Warehouse > ASN LPN`, `Receiving > Receipt orders`
 - RFT: `Receipts > Notices`
-#### DirectTransfer — inter-warehouse ASN flow
+#### DirectTransfer - inter-warehouse ASN flow
-When the source order is a `<DirectTransfer>` shipment (cf. [concepts/order-outbound.md](../concepts/order-outbound.md#asn--directtransfer-flow)), closing the expedition at origin triggers an automatic `ASO01` message on the destination warehouse, pre-creating the incoming ASN container(s). The operator then receives them via RFT menu **Réception → Préavis** just like any other ASN container.
+When the source order is a `<DirectTransfer>` shipment (cf. [concepts/order-outbound.md](../concepts/order-outbound.md#asn---directtransfer-flow)), closing the expedition at origin triggers an automatic `ASO01` message on the destination warehouse, pre-creating the incoming ASN container(s). The operator then receives them via RFT menu **Réception → Préavis** just like any other ASN container.
 - Container deletion from SmartUI (`Entrepôt → Conteneurs ASN → Supprimer`) triggers an `ASK01` back to the ERP.
- ⚠️ The ASO/ASK messages carry **no reference to the originating shipping order or DirectTransfer header** — only the container and its stock.
+- ⚠️ The ASO/ASK messages carry **no reference to the originating shipping order or DirectTransfer header** - only the container and its stock.
-#### Transfer — two-warehouse ASN flow (with receipt)
+#### Transfer - two-warehouse ASN flow (with receipt)
 Unlike `<DirectTransfer>` (which bypasses reception at destination), a `<Transfer>`-type shipping order (`SorType = Transfer` in SOR02) **automatically creates an inbound order at destination** when expedition is confirmed at source. The destination ASN containers live on an `Asn` location in the destination warehouse.
@@ -200,7 +200,7 @@ Operator flow: RFT menu **Réception → Préavis** (of the destination warehous
 **ERP messages generated:**
 - `ASO01` at each container reception
- `ROF02` at inbound order closure (contains **all** received containers — the authoritative record for Transfer receptions)
+- `ROF02` at inbound order closure (contains **all** received containers - the authoritative record for Transfer receptions)
 - `ASK01` when closing a partially-received inbound order (to drop non-arrived containers)
 > ⚠️ Neither `ASO01` nor `ASK01` carries the transfer header info. For `<Transfer>` flows the ERP **must** consume `ROF02`.
@@ -269,7 +269,7 @@ Receipts can be closed **manually** or **automatically**.
 ### Manual Closing
- Done from web interface or RFT at any time — full quantity not required.
+- Done from web interface or RFT at any time - full quantity not required.
 - If linked to receipt orders and all ordered stock received → receipt order = _Completed_; else = _Partially received_.
 - Stock allocation across identical order lines follows: least expected qty first → oldest creation date → excess to first line allowing it.
 - Process: `Reception_Close_PR_V2`
@@ -317,7 +317,7 @@ Receipts can be closed **manually** or **automatically**.
 | `ASN` | ERP → WMS | Pre-notifies containers and their stock |
 | `ASO` | WMS → ERP | Confirms receipt of a pre-notified container |
 | `ASK` | WMS → ERP | Confirms rejection of a pre-notified container |
-| `REF` | WMS → ERP | Receipt close confirmation — lists all received stock |
+| `REF` | WMS → ERP | Receipt close confirmation - lists all received stock |
 | `ROF` | WMS → ERP | Receipt order close confirmation |
 | `STV` | WMS → ERP | Stock adjustment in pre-notified container during review |
@@ -342,7 +342,7 @@ See [concepts/labels.md](../concepts/labels.md) for complete label reference.
 - Cause: Order code unknown or not yet created.
 - Solution: Enable `ALLOW_CREATE_RECEPTION` to create a new receipt; or have the ERP send the `ROR` message first.
-**ASN container rejected at PIE — order doesn't exist:**
+**ASN container rejected at PIE - order doesn't exist:**
 - Cause: Receipt order referenced in ASN message not yet in WMS.
 - Solution: If `USE_EXCLUSIVE_RESERVE_STRICT_MODE` is inactive, container can still be received; reserve is formalized later. If active, resolve order absence first.
@@ -350,7 +350,7 @@ See [concepts/labels.md](../concepts/labels.md) for complete label reference.
 - Cause: Receipt still has uncommitted lines or allows excess reception.
 - Solution: Close manually, or verify `AutoCloseReception` is active and no line allows over-receipt.
-**Quantity discrepancy at PIE — container sent to reconditioning:**
+**Quantity discrepancy at PIE - container sent to reconditioning:**
 - Cause: ASN pre-notified stock quantity doesn't match received stock and receipt order doesn't allow excess.
 - Solution: Correct the discrepancy at the reconditioning station and retry.
@@ -360,13 +360,13 @@ See [concepts/labels.md](../concepts/labels.md) for complete label reference.
 **Return receipt rejected for expired stock:**
 - Cause: `RECEPTION_NUM_DAYS_PRODUCTION_DATE_MARGIN` check triggered.
- Note: Date logistic attributes are captured but expiry is **not blocked** during returns — check parameter configuration.
+- Note: Date logistic attributes are captured but expiry is **not blocked** during returns - check parameter configuration.
 ---
 ## Reception Split Strategy (Mecalux France pattern)
-Deployed at **ROUJE** and **NEUT** — documented from NEUT (blind reception, supplier + customer return, loose stock on equipment). When the item has a picking dedicated location (PDL), incoming stock is split at reception between two buffers so PDLs are filled to capacity directly and the overflow lands in reserve.
+Deployed at **ROUJE** and **NEUT** - documented from NEUT (blind reception, supplier + customer return, loose stock on equipment). When the item has a picking dedicated location (PDL), incoming stock is split at reception between two buffers so PDLs are filled to capacity directly and the overflow lands in reserve.
 **Flow:**
@@ -396,7 +396,7 @@ Deployed at **ROUJE** and **NEUT** — documented from NEUT (blind reception, su
 | 3 | PICKING buffer | Dedicated picking locations | Item assigned, destination zone = PICKING |
 | 4 | RESERVE buffer | Pallet rack locations | Destination zone = PALETTE |
-**Split logic (custom workflow) — rules applied after stock reception:**
+**Split logic (custom workflow) - rules applied after stock reception:**
 | Situation | Action |
 |---|---|
@@ -408,8 +408,8 @@ Deployed at **ROUJE** and **NEUT** — documented from NEUT (blind reception, su
 > ⚠️ Stock dropped on the RESERVE buffer **must** be on a container (existing LPN or a newly generated code).
 **Customs required:**
- `Equipment_Unload_ProductUnloadOnContainer_UI` — hide the free-drop button when `location.code == "RESERVE"`
+- `Equipment_Unload_ProductUnloadOnContainer_UI` - hide the free-drop button when `location.code == "RESERVE"`
- `Equipment_Unload_ProductUnloadAllStockOnContainer_UI` — idem
+- `Equipment_Unload_ProductUnloadAllStockOnContainer_UI` - idem
 - Custom workflow after reception that computes the split and generates two drop tasks
 Reference implementation: [NEUT-58](https://easywmsfrance.atlassian.net/browse/NEUT-58).
@@ -435,12 +435,12 @@ Reference implementation: [NEUT-58](https://easywmsfrance.atlassian.net/browse/N
 ## Related
- [concepts/container.md](../concepts/container.md) — LPN structure, statuses, ASN pre-notification
+- [concepts/container.md](../concepts/container.md) - LPN structure, statuses, ASN pre-notification
- [concepts/order-inbound.md](../concepts/order-inbound.md) — Receipt orders (ROR message), inbound lifecycle
+- [concepts/order-inbound.md](../concepts/order-inbound.md) - Receipt orders (ROR message), inbound lifecycle
- [concepts/putaway.md](../concepts/putaway.md) — What happens after stock is received
+- [concepts/putaway.md](../concepts/putaway.md) - What happens after stock is received
- [concepts/stock.md](../concepts/stock.md) — Stock records created during reception
+- [concepts/stock.md](../concepts/stock.md) - Stock records created during reception
- [concepts/product-item.md](../concepts/product-item.md) — Item reception profiles, logistic attributes captured at receipt
+- [concepts/product-item.md](../concepts/product-item.md) - Item reception profiles, logistic attributes captured at receipt
- [concepts/quality-control.md](../concepts/quality-control.md) — Incoming stock quality locks
+- [concepts/quality-control.md](../concepts/quality-control.md) - Incoming stock quality locks
- [concepts/labels.md](../concepts/labels.md) — LPN and item labels at reception
+- [concepts/labels.md](../concepts/labels.md) - LPN and item labels at reception
- [concepts/erp-interface.md](../concepts/erp-interface.md) — ROR, ASN, ASO, ASK, REF, ROF message definitions
+- [concepts/erp-interface.md](../concepts/erp-interface.md) - ROR, ASN, ASO, ASK, REF, ROF message definitions
- [concepts/transactions.md](../concepts/transactions.md) — CON.RECEP, STK.RECEP, CON.ASN.001, REC.CLS
+- [concepts/transactions.md](../concepts/transactions.md) - CON.RECEP, STK.RECEP, CON.ASN.001, REC.CLS
@@ -26,13 +26,13 @@ last_compiled: "2026-04-17"
 ## Overview
-Replenishment is the process of moving stock from bulk storage locations to **picking dedicated locations (PDL)** to ensure that operators always have stock available to fulfill shipping orders without going to the main rack. It is a supporting process that feeds the picking operation — without replenishment, picking dedicated locations would run dry and order preparation would stall.
+Replenishment is the process of moving stock from bulk storage locations to **picking dedicated locations (PDL)** to ensure that operators always have stock available to fulfill shipping orders without going to the main rack. It is a supporting process that feeds the picking operation - without replenishment, picking dedicated locations would run dry and order preparation would stall.
 A **picking dedicated location (PDL)** is a location permanently or dynamically assigned to one item (sometimes one item per partition). PDLs are configured with a minimum (replenishment threshold) and maximum (capacity). When stock in the PDL drops below the minimum, the replenishment system detects the shortage and generates a replenishment task to refill from a source location.
 Replenishment in EasyWMS operates at two levels:
-1. **PDL replenishment** — refilling picking dedicated locations from bulk storage
+1. **PDL replenishment** - refilling picking dedicated locations from bulk storage
-2. **Sub-warehouse replenishment** — moving stock from one sub-warehouse to another to balance inventory
+2. **Sub-warehouse replenishment** - moving stock from one sub-warehouse to another to balance inventory
 ## Picking Dedicated Locations (PDL)
@@ -45,15 +45,15 @@ A PDL is a location with an item assignment that designates it as the primary pi
 | **Location** | Must have: allow item assignment, allow picking, allow replenish, allow putaway |
 | **Item** | One item recommended per PDL (multiple items allowed but not typical) |
 | **Owner** | Owner of the item |
-| **Replenishment mode** | Container (move whole container) or Stock (move loose stock) — cannot mix both |
+| **Replenishment mode** | Container (move whole container) or Stock (move loose stock) - cannot mix both |
 | **Conversion** | Unit of measure in which replenishment level and capacity are expressed |
-| **Logistic attributes** | Specific batch, color, quality, etc. — PDL will be replenished with matching stock only |
+| **Logistic attributes** | Specific batch, color, quality, etc. - PDL will be replenished with matching stock only |
 | **Maximum lots** | Limit how many different lots can be present in the PDL simultaneously |
 | **Expired stock flag** | PDL can be configured to receive only expired stock |
 | **Days of life** | Replenish with stock whose shelf life ≥ (detection date + days of life) |
 | **Stock status** | Restrict to stock in a specific status |
-**For stock-mode PDLs — threshold types:**
+**For stock-mode PDLs - threshold types:**
 | Threshold type | Description | Notes |
 |---------------|-------------|-------|
@@ -68,15 +68,15 @@ A PDL is a location with an item assignment that designates it as the primary pi
 - **Maximum containers**: capacity ceiling
 - **Replenishment level %** (if max = 1): percentage of full-container quantity below which replenishment is triggered; allows exceeding the full quantity to absorb the incoming container's excess stock
-### PDL — EasyS / SmartUI Configuration
+### PDL - EasyS / SmartUI Configuration
-**EasyS — Location setup**, check :
+**EasyS - Location setup**, check :
 - `Allow product location`
 - `Allow replenish at source`
 - `Allow picking`
-**SmartUI — `Entrepôt → Emplacements consacrés au picking`** :
+**SmartUI - `Entrepôt → Emplacements consacrés au picking`** :
 - Enter the **replenishment level** (minimum threshold)
 - Enter the **maximum capacity**
@@ -84,13 +84,13 @@ A PDL is a location with an item assignment that designates it as the primary pi
 - Enter a **Texte personnalisé** (custom label)
 - Print the PDL barcodes
-> 💡 Labels display as `Code emplacement [Label]` (e.g. `B-1-4 [Clavier M]`). With many PDLs this is hard to scan through — Mecalux France standard is to **prefix labels with an ordered code** (e.g. `B-1-4 [01 Clavier M]`, `B-1-4 [02 Clavier L]`...) so the operator can sort them visually.
+> 💡 Labels display as `Code emplacement [Label]` (e.g. `B-1-4 [Clavier M]`). With many PDLs this is hard to scan through - Mecalux France standard is to **prefix labels with an ordered code** (e.g. `B-1-4 [01 Clavier M]`, `B-1-4 [02 Clavier L]`...) so the operator can sort them visually.
 > ⚠️ **Known limitations** documented by Mecalux France (2022 tests) :
 > - The **destination is not displayed** when the WMS generates putaway tasks towards a PDL.
-> - **Maximum capacity is not strictly enforced** at putaway — cases of 26 units put away in a capacity-15 PDL have been observed. Rely on replenishment threshold + periodic count rather than `max capacity` as a hard limit.
+> - **Maximum capacity is not strictly enforced** at putaway - cases of 26 units put away in a capacity-15 PDL have been observed. Rely on replenishment threshold + periodic count rather than `max capacity` as a hard limit.
 >
-> Positive : **minimum-threshold replenishment works correctly** — a task is generated to top the PDL back up to its maximum once the minimum is crossed.
+> Positive : **minimum-threshold replenishment works correctly** - a task is generated to top the PDL back up to its maximum once the minimum is crossed.
 ### PDL Creation Methods
@@ -99,16 +99,16 @@ A PDL is a location with an item assignment that designates it as the primary pi
 | Web interface | Warehouse manager manually creates PDL assignments |
 | RFT during putaway | Operator assigns item to location while unloading (if `UNLOAD_CREATE_PRODUCT_LOCATION` enabled) |
 | RFT during counting | Item assigned during stock count (if `UNLOAD_CREATE_PRODUCT_LOCATION` and `REPLENISH_LEVEL_PERCENT_PRODUCT_LOCATION` enabled) |
-| RFT — "Assign item to loc." | Dedicated menu option in Utilities |
+| RFT - "Assign item to loc." | Dedicated menu option in Utilities |
 | Automatically (dynamic replenishment) | System creates PDL on-the-fly for items in active shipping orders |
 ### PDL Partitions
-A single physical location can be subdivided into **partitions** — labeled divisions each assigned to a different item. This enables high-density picking areas (drawers, shelves divided by bins).
+A single physical location can be subdivided into **partitions** - labeled divisions each assigned to a different item. This enables high-density picking areas (drawers, shelves divided by bins).
 Key partition rules:
 - Each partition is identified by a unique QR label (code unique within the location)
- A partition is NOT a separate location — stock belongs to the location; the partition identifies which item occupies which physical space
+- A partition is NOT a separate location - stock belongs to the location; the partition identifies which item occupies which physical space
 - One partition can be shared across multiple items; one item can use multiple partitions
 - A partition can be marked **full** to prevent further putaway to that partition
 - **Maximum partitions per item**: configurable limit to prevent one item from monopolizing a location's partitions
@@ -133,7 +133,7 @@ Mecalux France uses three shortcut names that map to the strategy types below:
 | FR label | Type below | Trigger | Typical usage |
 |---|---|---|---|
-| **"Routine"** | Stockout (automatic) | `TryToReplenishProductLocations` job every 1–2 min | Default — refill PDL when stock drops under the minimum |
+| **"Routine"** | Stockout (automatic) | `TryToReplenishProductLocations` job every 1–2 min | Default - refill PDL when stock drops under the minimum |
 | **"Conclure"** | Particular demand (top-off) | RFT menu **Réapprovisionnement** or SmartUI "Réapprovisionner maintenant" on the PDL view | Operator-triggered, high-priority replenishment |
 | **"Exiger"** | Shipping demand (dynamic) | Order released with dynamic replenishment, or static flag `<EnableReplenishment>` on ROR | Create PDLs on the fly for items in released orders; also tops up when stock ≥ min but < order need |
@@ -142,14 +142,14 @@ Mecalux France uses three shortcut names that map to the strategy types below:
 - Reserve (source) locations: `Allow replenish at source`
 **SmartUI configuration checklist (routine, conclure, exiger):**
-1. `Entrepôt → Gestion des emplacements picking` — create PDL assignments, set **min threshold** (per container: tick "Réapprovisionnement de conteneur", or in base UoM) and **max capacity**
+1. `Entrepôt → Gestion des emplacements picking` - create PDL assignments, set **min threshold** (per container: tick "Réapprovisionnement de conteneur", or in base UoM) and **max capacity**
 2. Activate automatic replenishment on the PDL (for routine)
-3. `Configuration → Stratégie de réapprovisionnement` — create the strategy; pick filters (item, owner, item type, sub-warehouse, destination zone) and a **Mode efficacité** (see table below)
+3. `Configuration → Stratégie de réapprovisionnement` - create the strategy; pick filters (item, owner, item type, sub-warehouse, destination zone) and a **Mode efficacité** (see table below)
 4. **Activate** the strategy (to edit it later, deactivate first)
-5. `Configuration → Processus` — ensure `TryToReplenishProductLocations` is enabled and runs on a 1–2 min cycle
+5. `Configuration → Processus` - ensure `TryToReplenishProductLocations` is enabled and runs on a 1–2 min cycle
 6. Confirm source stock is eligible (no blocking status, no location lock, not already assigned to shipping)
-### Efficiency mode — SmartUI values
+### Efficiency mode - SmartUI values
 | FR field | Behaviour |
 |---|---|
@@ -228,7 +228,7 @@ Strategies are sequenced to determine which sub-warehouses are replenished first
 ### 4b. Priority Location Replenishment
-A fifth strategy type refills **priority locations** — locations associated with a PDL from which the PDL is replenished. This allows a two-tier system: primary storage → priority location → PDL.
+A fifth strategy type refills **priority locations** - locations associated with a PDL from which the PDL is replenished. This allows a two-tier system: primary storage → priority location → PDL.
 ## Efficiency Modes
@@ -280,7 +280,7 @@ Dynamic replenishment runs periodically (or on manual trigger) and follows this
 ## Dynamic Picking Emptying Tasks (Vidage)
-Dynamic PDLs created by the shipping demand strategy are temporary — they exist only for the duration of the order they were created for. Once the order is shipped, the dynamic PDL may still contain leftover stock that should be returned to bulk storage.
+Dynamic PDLs created by the shipping demand strategy are temporary - they exist only for the duration of the order they were created for. Once the order is shipped, the dynamic PDL may still contain leftover stock that should be returned to bulk storage.
 **Emptying tasks (vidage)** are generated automatically on a schedule to clear unused dynamic picking locations:
 - The system identifies dynamic PDLs whose associated shipping orders are complete (shipped or cancelled)
@@ -326,21 +326,21 @@ When a single equipment cannot traverse from the reserve sub-warehouse to the pi
 ### Typical setup
- **Sub-warehouse A** (`WHST_ANCIEN_BAT`) — PDLs to replenish
+- **Sub-warehouse A** (`WHST_ANCIEN_BAT`) - PDLs to replenish
- **Sub-warehouse B** (`WHST_TOUR`) — high reserves
+- **Sub-warehouse B** (`WHST_TOUR`) - high reserves
 - Equipment `CACES06` (only one certified for height) is **forbidden** in sub-warehouse A
 ### Key configuration points
 | Element | Requirement |
 |---|---|
-| Automation element | Type **"Transport"** — mandatory even in 100% manual warehouses |
+| Automation element | Type **"Transport"** - mandatory even in 100% manual warehouses |
-| Transport sub-location | Type **"Buffer"** (⚠️ defaults to "Automatic" when created — change manually); sub-warehouse accessible from both equipment types |
+| Transport sub-location | Type **"Buffer"** (⚠️ defaults to "Automatic" when created - change manually); sub-warehouse accessible from both equipment types |
 | Equipment types | `PICKING` (access work zones of picking + both sub-warehouses) and `RESERVE` (access reserve work zone + sub-WH B only) |
 | Equipment groups | Two groups, one per equipment type |
 | Routes | Transport → sub-WH A ; each group → Transport ; `EqGroup PICKING` → both sub-warehouses ; `EqGroup RESERVE` → sub-WH B only |
-> ⚠️ Routes are created by default with the **"Galileo"** transport — switch them to **"RF"** manually.
+> ⚠️ Routes are created by default with the **"Galileo"** transport - switch them to **"RF"** manually.
 ### Flow
@@ -348,7 +348,7 @@ When a single equipment cannot traverse from the reserve sub-warehouse to the pi
 2. The reserve equipment (e.g. `CACES06`) picks up the support and drops it on the **intermediate Buffer location**
 3. The picking equipment (e.g. `PIK01`) picks up the task from **Tâches → Tâches de réapprovisionnement** and drops the stock on the destination PDL
-> Troubleshooting — "support n'existe pas" when scanning the buffer location: verify that the transit sub-location is of type **"Buffer"** (not "Automatic").
+> Troubleshooting - "support n'existe pas" when scanning the buffer location: verify that the transit sub-location is of type **"Buffer"** (not "Automatic").
 Upstream MSSCC documentation: `replenishments/intermediate_stations.md` and `EasyS/configurations/IntermediateET/index.md`.
@@ -380,23 +380,23 @@ In automatic warehouses, the picking conveyor (PK) generates demand that drives
 | Interface | Path |
 |---|---|
-| Web — replenishment strategies | "Configuration" → "Replenishment strategies" |
+| Web - replenishment strategies | "Configuration" → "Replenishment strategies" |
-| Web — sub-WH replenishment strategies | "Configuration" → "Replenishment strategies between sub-warehouses" |
+| Web - sub-WH replenishment strategies | "Configuration" → "Replenishment strategies between sub-warehouses" |
-| Web — picking dedicated locations | "Warehouse" → "Picking dedicated locations" |
+| Web - picking dedicated locations | "Warehouse" → "Picking dedicated locations" |
-| Web — enable/disable automatic replenishment | "Warehouse" → "Picking dedicated locations" → "Enable replenishments" |
+| Web - enable/disable automatic replenishment | "Warehouse" → "Picking dedicated locations" → "Enable replenishments" |
-| Web — delete when empty | "Warehouse" → "Picking dedicated locations" → "Delete when empty" |
+| Web - delete when empty | "Warehouse" → "Picking dedicated locations" → "Delete when empty" |
-| Web — label printing | "Warehouse" → "Picking dedicated locations" → label action |
+| Web - label printing | "Warehouse" → "Picking dedicated locations" → label action |
-| Web — shipping demand replenishment | "Shipping" → "Shipping orders" → "Enable replenishment" |
+| Web - shipping demand replenishment | "Shipping" → "Shipping orders" → "Enable replenishment" |
-| RFT — particular demand replenishment | Menu "Replenishment" → specific location/aisle |
+| RFT - particular demand replenishment | Menu "Replenishment" → specific location/aisle |
-| RFT — shipping order demand | Menu "Replenishment" → "For shipping orders" |
+| RFT - shipping order demand | Menu "Replenishment" → "For shipping orders" |
-| RFT — assign item to location | Menu "Utilities" → "Assign item to loc." |
+| RFT - assign item to location | Menu "Utilities" → "Assign item to loc." |
-| Web — automatic job | "Control" → "Jobs" → TryToReplenishProductLocations |
+| Web - automatic job | "Control" → "Jobs" → TryToReplenishProductLocations |
 ## Related
- [Picking](picking.md) — replenishment feeds PDLs that picking tasks consume; PDL stock assignment depends on replenishment being current
+- [Picking](picking.md) - replenishment feeds PDLs that picking tasks consume; PDL stock assignment depends on replenishment being current
- [Putaway](putaway.md) — putaway engine checks PDLs first and can auto-create PDL assignments during container placement
+- [Putaway](putaway.md) - putaway engine checks PDLs first and can auto-create PDL assignments during container placement
- [Stock](stock.md) — stock status and logistic attributes are key criteria for replenishment eligibility
+- [Stock](stock.md) - stock status and logistic attributes are key criteria for replenishment eligibility
- [Container (LPN)](container.md) — container-mode PDLs replenish by moving whole containers; source containers must allow replenishment
+- [Container (LPN)](container.md) - container-mode PDLs replenish by moving whole containers; source containers must allow replenishment
- [Task](task.md) — replenishment generates Container replenishment or Stock replenishment tasks; also Picking tasks for inter-sub-warehouse replenishment
+- [Task](task.md) - replenishment generates Container replenishment or Stock replenishment tasks; also Picking tasks for inter-sub-warehouse replenishment
- [Location](location.md) — PDLs are locations with item assignment; "Allow replenishment source/target" logics control eligibility
+- [Location](location.md) - PDLs are locations with item assignment; "Allow replenishment source/target" logics control eligibility
@@ -47,7 +47,7 @@ last_compiled: "2026-04-17"
 ## Overview
-Shipping is the end-to-end process of fulfilling customer orders: from order receipt through stock assignment, preparation (picking or container shipping), consolidation, truck loading, and closure. EasyWMS represents outbound work through **shipping orders** — the central document linking customer demand to warehouse operations.
+Shipping is the end-to-end process of fulfilling customer orders: from order receipt through stock assignment, preparation (picking or container shipping), consolidation, truck loading, and closure. EasyWMS represents outbound work through **shipping orders** - the central document linking customer demand to warehouse operations.
 Shipping orders typically arrive from the ERP via `SOR` messages but can be created manually from the web interface. For the canonical shipping order lifecycle and all statuses (Waiting, Reserved, Released, In Preparation, Paused, Closed/Archived, etc.) see [Outbound Order](order-outbound.md).
@@ -119,7 +119,7 @@ Release can be:
 **ERP message sent:** `SOC` (order status change)
 **Transaction recorded:** `OUT.CST`
-**Parameter:** `MAX_AUTORELEASED_OUTBOUNDORDERS` — maximum orders auto-released simultaneously
+**Parameter:** `MAX_AUTORELEASED_OUTBOUNDORDERS` - maximum orders auto-released simultaneously
 ### Release by Sub-warehouse
@@ -140,7 +140,7 @@ Multiple shipping orders are picked together (same picking path). After picking,
 ### Fusions
-Multiple shipping orders are shipped together without ungrouping — typically for orders going to the same customer. Picked stock can be placed in shared containers without redistribution.
+Multiple shipping orders are shipped together without ungrouping - typically for orders going to the same customer. Picked stock can be placed in shared containers without redistribution.
 ### Waves
@@ -177,17 +177,17 @@ A stock-assignment strategy and/or a prepackaging strategy can be attached to th
 **Per-type tabs** :
 - **Picking d'ordres groupés** : grouping criteria (carrier, mono-ligne, mono-unité, critère personnalisé), group size (max orders / lines / volume), filters (stock rangé, crossdocking, UdM, critère perso), ungrouping (UAP + packing buffer), minimum conditions (min qty, min orders).
- **Vague de picking** : carrier + critère perso ; max orders, volume, UdM, min orders. Checkbox **"Generate tasks on release"** — if set, tasks are created when the wave is released ; otherwise at operator pickup time.
+- **Vague de picking** : carrier + critère perso ; max orders, volume, UdM, min orders. Checkbox **"Generate tasks on release"** - if set, tasks are created when the wave is released ; otherwise at operator pickup time.
 - **Picking d'ordre** : for single-order templates. Filters on UdM + critère perso only.
 **Scheduler.** Templates can run between two hours on selected weekdays, with a configurable interval in minutes. Two daily windows (e.g. 9–10h and 15–16h) require **duplicating** the template.
-**Criteria** are mandatory (at least one per template). Each criterion rejects orders that don't match — two tabs are available :
+**Criteria** are mandatory (at least one per template). Each criterion rejects orders that don't match - two tabs are available :
 - **Ordre d'expédition** : Code, Description, Type (`Customer`, `Transfer`, `DirectTransfer`, `Fabrication`, `Manuel`, `Retour`…), Class, Owner, Mono-ligne, Mono-unité, Follow sequence, Auto-release, Carrier, Transport type, N hours before release/loading, N hours late, Country/City/Postal code.
 - **Ligne d'ordre d'expédition** : item type, item family, danger, stackability, voluminous, single parcel.
-**Critère personnalisé — LINQ syntax** :
+**Critère personnalisé - LINQ syntax** :
 ```csharp
 // Criterion on the outbound order itself (ex: orders imported with source = "WEB")
@@ -227,10 +227,10 @@ Typical need: order prepared from multiple origins (manual + automatic aisles, d
 3. Empty source containers are deleted if configured; task cancellation follows
 **Transactions:**
- `CON.CREATE` — new consolidation container created
+- `CON.CREATE` - new consolidation container created
- `STK.MOVE` — stock moved from source to destination
+- `STK.MOVE` - stock moved from source to destination
- `CON.DELETE` — empty source container deleted
+- `CON.DELETE` - empty source container deleted
- `TSK.CANCEL` — tasks for deleted container canceled
+- `TSK.CANCEL` - tasks for deleted container canceled
 HPKS (laser pick-term tray) illuminates the destination division for easy identification.
@@ -262,7 +262,7 @@ When route sequencing is planned by a TMS, the ERP sends a **`RUT` file** instea
 Operational flow :
-1. **Integrate the RUT file.** Orders appear in the orders view but must be handled from the **routes view** — releasing them individually is not the nominal path.
+1. **Integrate the RUT file.** Orders appear in the orders view but must be handled from the **routes view** - releasing them individually is not the nominal path.
 2. **Launch the route** → each order is auto-released with its stock assignment.
 3. **Prepare the orders** in any convenient internal order.
 4. **Create a truck load** and attach it to the route. A template can create the load automatically at route release.
@@ -300,14 +300,14 @@ Loads represent a physical transport vehicle (truck, van) that will carry one or
 ### Multi-zone Loading (Virtual Dock)
-Warehouses with multiple storage/preparation areas can use a **virtual dock** — a common dock reference for all zones. Carriers collect stock from different physical zones, but all are referenced to the same virtual dock for tracking purposes.
+Warehouses with multiple storage/preparation areas can use a **virtual dock** - a common dock reference for all zones. Carriers collect stock from different physical zones, but all are referenced to the same virtual dock for tracking purposes.
-### Truck Loading — SmartUI configuration reference (Mecalux France)
+### Truck Loading - SmartUI configuration reference (Mecalux France)
 Standard EasyWMS exposes two truck-loading modes at dock level :
- **No buffer** — order auto-ships as soon as it lands on the dock
+- **No buffer** - order auto-ships as soon as it lands on the dock
- **Buffer + dock** — an intermediate control step validates pallets against the load before shipment
+- **Buffer + dock** - an intermediate control step validates pallets against the load before shipment
 **Load creation modes (per order type: unitary, route, group, merged, wave, by carrier):**
@@ -316,12 +316,12 @@ Standard EasyWMS exposes two truck-loading modes at dock level :
 | **Automatic (planned)** | Load created at order release; strict container control (scanning a container from another order raises an error) |
 | **Non planifié** | Load created at release; **no container control** |
 | **Manuel (planned)** | Load created manually; strict container control |
-| RFT — manual, no control | Created from RFT; no container control (indicative only) |
+| RFT - manual, no control | Created from RFT; no container control (indicative only) |
-| RFT — from a route | Load tied to an existing route |
+| RFT - from a route | Load tied to an existing route |
 EasyS minimum: **one buffer + one dock** per dock used. The buffer can be carried in `<PrpPackingLocation>` on SOR02, or assigned manually via SmartUI **Ordres de sortie → "Assigner quai/poumon"**.
-**SmartUI — Configuration → Chargements:**
+**SmartUI - Configuration → Chargements:**
 | Option | Effect |
 |---|---|
@@ -332,24 +332,24 @@ EasyS minimum: **one buffer + one dock** per dock used. The buffer can be carrie
 | Quantity validation | Same semantics as picking |
 | **Allow load of all stock** | Adds a RFT button to load all free stock in one action |
-**RFT — create a load from the floor:** `Ordres de sortie → Chargement camion → Charger les conteneurs → Nouveau`. To **disable** this path, set every order-type mode to something other than "Non planifiée". As soon as one type is "Non planifiée", operators can create loads from RFT.
+**RFT - create a load from the floor:** `Ordres de sortie → Chargement camion → Charger les conteneurs → Nouveau`. To **disable** this path, set every order-type mode to something other than "Non planifiée". As soon as one type is "Non planifiée", operators can create loads from RFT.
-**RFT — execute a load (`EasyWMS.TruckLoad_GetLoads_UI`):**
+**RFT - execute a load (`EasyWMS.TruckLoad_GetLoads_UI`):**
 1. `Ordres de sortie → Chargement camion → Charger les conteneurs`
 2. Filter by dock/buffer or by load
 3. Select the load (status `Ready to load` if the whole order is prepared)
-4. Scan pallets — button **"Conteneur"** lists remaining containers ; **"Effectuer"** closes the load even if pallets are missing
+4. Scan pallets - button **"Conteneur"** lists remaining containers ; **"Effectuer"** closes the load even if pallets are missing
 > ℹ️ During loading the load status reads **"Loading"** (red on RFT).
-**Delivery-note printing at load close:** when the BL is configured to print on order close, **closing the truck load triggers the print** — including for a partial close. On a two-step load (remainder), the BL is printed at each close and always covers **all shipped lines of the order**.
+**Delivery-note printing at load close:** when the BL is configured to print on order close, **closing the truck load triggers the print** - including for a partial close. On a two-step load (remainder), the BL is printed at each close and always covers **all shipped lines of the order**.
 **Truck unloading (RFT):** menu `Décharger les conteneurs` → scan the container → scan the drop-off location (default: the end-of-preparation buffer).
 ### Order Merge vs Load
-Truck loading handles **loads** — merging happens **before** load creation on the shipping orders themselves. A merged order behaves as a single order when assigning a load, but ERP traceability remains per-original-order (see [Outbound Order → Merge](order-outbound.md#merge-order-fusion)).
+Truck loading handles **loads** - merging happens **before** load creation on the shipping orders themselves. A merged order behaves as a single order when assigning a load, but ERP traceability remains per-original-order (see [Outbound Order → Merge](order-outbound.md#merge-order-fusion)).
 ## Truck Loading (RFT Process)
@@ -378,7 +378,7 @@ Operators at the dock register each item loaded using the RFT:
 - Auto-close: last item loaded triggers close process (seal registration, report collection)
 - Partial close: configured to allow closing without all units loaded
-## PS Groups (Automatic Warehouse — Outbound Conveyors)
+## PS Groups (Automatic Warehouse - Outbound Conveyors)
 PS (Pallet Shuttle or outbound conveyor) groups are logical groupings of outbound conveyors in automatic warehouses. Each group configures which PS stations belong to it and how they are filled (criteria for which PS station gets the next container).
@@ -451,25 +451,25 @@ Multiple shipping orders can be merged into the same client container if they me
 | Interface | Path |
 |---|---|
-| Web — shipping orders | Menu "Shippings" → "Shipping orders" |
+| Web - shipping orders | Menu "Shippings" → "Shipping orders" |
-| Web — routes | Menu "Shippings" → "Routes" |
+| Web - routes | Menu "Shippings" → "Routes" |
-| Web — loads | Menu "Shippings" → "Loads" |
+| Web - loads | Menu "Shippings" → "Loads" |
-| Web — waves | Menu "Shippings" → "Waves" |
+| Web - waves | Menu "Shippings" → "Waves" |
-| Web — groups/fusions | Menu "Shippings" → "Groups" |
+| Web - groups/fusions | Menu "Shippings" → "Groups" |
-| Web — shipping templates | Menu "Configuration" → "Shipping templates" |
+| Web - shipping templates | Menu "Configuration" → "Shipping templates" |
-| Web — PS groups | Menu "Control" → "PS groups" |
+| Web - PS groups | Menu "Control" → "PS groups" |
-| RFT — truck loading | Menu "Shipping" → "Load truck" |
+| RFT - truck loading | Menu "Shipping" → "Load truck" |
-| RFT — consolidation | Menu "Shipping orders" → "Packaging" |
+| RFT - consolidation | Menu "Shipping orders" → "Packaging" |
 ## Related
- [Picking](picking.md) — picking is the core preparation activity within the shipping process
+- [Picking](picking.md) - picking is the core preparation activity within the shipping process
- [Replenishment](replenishment.md) — picking dedicated locations are replenished when stock runs out during order preparation
+- [Replenishment](replenishment.md) - picking dedicated locations are replenished when stock runs out during order preparation
- [Container (LPN)](container.md) — containers are the main unit tracked through shipping, loading, and delivery
+- [Container (LPN)](container.md) - containers are the main unit tracked through shipping, loading, and delivery
- [Crossdocking](crossdocking.md) — some shipping orders can bypass storage through crossdocking
+- [Crossdocking](crossdocking.md) - some shipping orders can bypass storage through crossdocking
- [Reception](reception.md) — inbound stock feeds the inventory that shipping orders consume
+- [Reception](reception.md) - inbound stock feeds the inventory that shipping orders consume
- [Outbound Order](order-outbound.md) — shipping orders (SOR/SOF/SOC) drive the entire shipping process; order type determines destination and process
+- [Outbound Order](order-outbound.md) - shipping orders (SOR/SOF/SOC) drive the entire shipping process; order type determines destination and process
- [Task](task.md) — shipping generates Shipping and Loading tasks; task priority inherits from order priority
+- [Task](task.md) - shipping generates Shipping and Loading tasks; task priority inherits from order priority
- [[cutting-stock]] — cutting stock has special shipping profile requirements (excess %, enter quantity mode = Manually)
+- [[cutting-stock]] - cutting stock has special shipping profile requirements (excess %, enter quantity mode = Manually)
- [[stations]] — Dock (type 34), Stage (type 33), PS (type 4), Consolidation (type 17) stations are central to shipping
+- [[stations]] - Dock (type 34), Stage (type 33), PS (type 4), Consolidation (type 17) stations are central to shipping
- [Prepackaging](prepackaging.md) — dedicated page for prepackaging strategy configuration, ERP (SOR02) payload, and tested behaviors
+- [Prepackaging](prepackaging.md) - dedicated page for prepackaging strategy configuration, ERP (SOR02) payload, and tested behaviors
@@ -72,16 +72,16 @@ Easy WMS defines 37+ standard station types. Types are identified by a numeric c
 | Code | Type | Name | Description |
 |------|------|------|-------------|
-| 0 | ALM | Warehouse | Set of storage locations (shelves, ground locations, any storage element). Not connected to TMS — no machine communication. Involved in: location (destination), extraction (source), transfer (source+destination). Can be configured to allow/deny inbounds or outbounds independently. |
+| 0 | ALM | Warehouse | Set of storage locations (shelves, ground locations, any storage element). Not connected to TMS - no machine communication. Involved in: location (destination), extraction (source), transfer (source+destination). Can be configured to allow/deny inbounds or outbounds independently. |
 ### Inbound / Conveyor Stations (AS/RS)
 | Code | Type | Name | Description |
 |------|------|------|-------------|
 | 3 | PIE | Pallet Check Unit | Dimensional + identification control of containers. TMS sends height, weight, status, and label data to Easy WMS. Easy WMS validates and routes: correct → warehouse; wrong → REAC/RECH. All stations with a gauge arch or scale must be configured as PIE. PIE events evaluate flags: 65536=correct, 256=barcode error, 512=recovered container, 1024/66560=correct+empty, 3=holes+studs, 4=overheight, 8–64=overhangs, 128=weight excess. |
-| 9 | ME | Aisle Inbound Conveyor | Interchange point with AS/RS (TRASLO). Final optimization before container enters the machine. Checks stacker crane characteristics (number of extractors, conveyors). If container arrives at ME with both putaway and picking tasks, putaway is cancelled and container goes to picking. Final location decision point — refines but doesn't replace initial search. Required in all automatic warehouses with stacker cranes. |
+| 9 | ME | Aisle Inbound Conveyor | Interchange point with AS/RS (TRASLO). Final optimization before container enters the machine. Checks stacker crane characteristics (number of extractors, conveyors). If container arrives at ME with both putaway and picking tasks, putaway is cancelled and container goes to picking. Final location decision point - refines but doesn't replace initial search. Required in all automatic warehouses with stacker cranes. |
-| 10 | MS | Outbound Conveyor | AS/RS unload point — where the machine unloads an extracted container onto the conveyor. Not mandatory (in Galileo IV the location is freed at AS/RS loading), but recommended for additional control, ring saturation prevention, and movement statistics. Taskless containers (order cancelled) return to vault. |
+| 10 | MS | Outbound Conveyor | AS/RS unload point - where the machine unloads an extracted container onto the conveyor. Not mandatory (in Galileo IV the location is freed at AS/RS loading), but recommended for additional control, ring saturation prevention, and movement statistics. Taskless containers (order cancelled) return to vault. |
-| 11 | MU | Putaway Conveyor | Searches for a putaway location by applying configured strategies. Only acts on containers without tasks or containers whose destination task points to this station. Useful when PIE is far from the warehouse — PIE skips location search, MU refines it just before warehouse entry. If problem generating movement: movement generated with origin=destination, flagged "With conflict"; cleared when possible. |
+| 11 | MU | Putaway Conveyor | Searches for a putaway location by applying configured strategies. Only acts on containers without tasks or containers whose destination task points to this station. Useful when PIE is far from the warehouse - PIE skips location search, MU refines it just before warehouse entry. If problem generating movement: movement generated with origin=destination, flagged "With conflict"; cleared when possible. |
 | 13 | APL | Stacker / Unstacker | Handles stacking and unstacking operations for empty containers. |
 | 14 | LANZ | Shuttle | Shuttle station for Pallet Shuttle operations. |
 | 18 | PKE | PK Inbound Conveyor | Entry to the picking inbound conveyor. |
@@ -91,15 +91,15 @@ Easy WMS defines 37+ standard station types. Types are identified by a numeric c
 | Code | Type | Name | Description |
 |------|------|------|-------------|
-| 1 | TRASLO | AS/RS | Automated Storage/Retrieval System — the crane or machine. Bidirectional: loads from ME (inbound), unloads into MS (outbound). Communication via protocol (Galileo IV supports loading event + location release simultaneously). |
+| 1 | TRASLO | AS/RS | Automated Storage/Retrieval System - the crane or machine. Bidirectional: loads from ME (inbound), unloads into MS (outbound). Communication via protocol (Galileo IV supports loading event + location release simultaneously). |
 ### Picking Stations
 | Code | Type | Name | Description |
 |------|------|------|-------------|
 | 2 | PK | Picking Conveyor | Managed from the "Picking" view. Operator is guided: what to pick, how much, where to put it. Supports multiple locations per station (multiple containers simultaneously). Operations: direct picking, container/item count, replenishments. Can have associated RECH reject station. Empty container removal requires location configured for empty container handling. |
-| 4 | PS | Outbound Conveyor | Final point of automatic transport — container leaves the warehouse. Management cycle of Easy WMS ends here (no more tasks). May have a display panel showing operator where to carry the container. Location types: Dynamic (Easy WMS tracks container depth) or Automatic (Easy WMS knows only which container is on PS, not which follows). |
+| 4 | PS | Outbound Conveyor | Final point of automatic transport - container leaves the warehouse. Management cycle of Easy WMS ends here (no more tasks). May have a display panel showing operator where to carry the container. Location types: Dynamic (Easy WMS tracks container depth) or Automatic (Easy WMS knows only which container is on PS, not which follows). |
-| 16 | MP | Preparation Zone | Zone for order preparation — used in semi-automatic picking operations. |
+| 16 | MP | Preparation Zone | Zone for order preparation - used in semi-automatic picking operations. |
 | 17 | Consolidation | Consolidation Station | Consolidation station for grouping picked stock by shipping order. |
 | 53 | PCS | Sequencing Control Point | Point where order sequencing is controlled in the transport flow. |
 | 54 | PB | Proximity Buffer | Buffer near a picking station to temporarily hold containers. |
@@ -112,19 +112,19 @@ Easy WMS defines 37+ standard station types. Types are identified by a numeric c
 | Code | Type | Name | Description |
 |------|------|------|-------------|
 | 5 | REAC | Reconditioning | Destination for containers that fail PIE validation but can be corrected and re-injected into the flow. |
-| 7 | RECH | Rejects | Destination for definitively rejected containers — not reintegrable. |
+| 7 | RECH | Rejects | Destination for definitively rejected containers - not reintegrable. |
-| 20 | ET | Transit Station | Intermediate station inserted in routes to break task flow. Does not perform any WMS management — designed for flexibility and external system integration (robotic arm, labeling machine, vertical warehouse, etc.). For automatic locations: only one container at a time (new arrival sends previous to Lost & Found). For non-automatic (buffer) locations: multiple containers allowed. TMS must always report aisle=1 in station update. |
+| 20 | ET | Transit Station | Intermediate station inserted in routes to break task flow. Does not perform any WMS management - designed for flexibility and external system integration (robotic arm, labeling machine, vertical warehouse, etc.). For automatic locations: only one container at a time (new arrival sends previous to Lost & Found). For non-automatic (buffer) locations: multiple containers allowed. TMS must always report aisle=1 in station update. |
 | 21 | CME | Inbound Control Station | Control point for inbound conveyors. |
-| 42 | RETENTION | Retention | Retention station — holds containers that require manual review or authorization before continuing their route. |
+| 42 | RETENTION | Retention | Retention station - holds containers that require manual review or authorization before continuing their route. |
 | 43 | DESK | Desk | Desk station for administrative or manual operations. |
 | 55 | ECB | Empty Containers Buffer | Buffer specifically for empty containers waiting to be stacked or reused. |
-| 58 | ETQ | Labeller | Labeling machine station — container passes through and is automatically labeled. |
+| 58 | ETQ | Labeller | Labeling machine station - container passes through and is automatically labeled. |
 ### Dock & Stage Stations
 | Code | Type | Name | Description |
 |------|------|------|-------------|
-| 33 | Stage | Stage (Shipping/Receiving) | Floor area for temporary stock storage, typically near docks. Receiving stages: for stock pending putaway. Shipping stages: for client containers awaiting truck load. One of each can be set as default. Locations are DockStage type — Easy WMS does not control exact container position. Capacity = 0 means unlimited. Cannot be used for putaway; cannot generate tasks from stage (only from warehouse-type locations). |
+| 33 | Stage | Stage (Shipping/Receiving) | Floor area for temporary stock storage, typically near docks. Receiving stages: for stock pending putaway. Shipping stages: for client containers awaiting truck load. One of each can be set as default. Locations are DockStage type - Easy WMS does not control exact container position. Capacity = 0 means unlimited. Cannot be used for putaway; cannot generate tasks from stage (only from warehouse-type locations). |
 | 33 | PKS | Packing Station | Packing station for packaging operations (shares type code 33 with Stage). |
 | 34 | Dock | Dock | Point of receipt or shipping. Types: inbound dock, outbound dock, or combined. At least one must be configured. Locations are DockStage type. No exact position tracking. Route must exist (even indirect) from container location to dock for task generation. Multiple locations per dock supported. |
@@ -133,7 +133,7 @@ Easy WMS defines 37+ standard station types. Types are identified by a numeric c
 | Code | Type | Name | Description |
 |------|------|------|-------------|
 | 38 | Kit | Kits Assembly | Station for assembling kit items. |
-| 57 | CONVEYOR | Conveyor (eCommerce) | Conveyor station for eCommerce operations — container-based order consolidation. |
+| 57 | CONVEYOR | Conveyor (eCommerce) | Conveyor station for eCommerce operations - container-based order consolidation. |
 | 59 | VAS | VAS Conveyor | Conveyor station for executing Value Added Services. |
 | 61 | Cutting | Cutting Station | Station where cutting stock is cut in integrated or delegated picking processes. Composed of a receiving stage and a shipping stage (configurable: 1 shared stage, 2 dedicated stages, or shared stages across multiple cutting stations). Can be locked via "Stations" view to prevent stock assignment. |
 | 65 | AGV | AGV Station | AGV robot station. |
@@ -146,7 +146,7 @@ A single physical station can have more than one role, enabling context-sensitiv
 **PIE with multiple roles:** A PIE station configured as a rejection or reconditioning station simultaneously. The workstation view updates to show the appropriate interface (PIE vs RECH/REAC) based on the container's task. Configuration: arrange both stations in EasyS, create PIE→RECH/REAC route, add RECH/REAC as Error Entity for PIE. Then assign role in SmartUI "Stations" view via "Assign new role".
-**PK with multiple roles:** PK station acting also as a reject station. When a container is rejected at PIE, the target reject station is the PK that originally handled the container — enabling workload balance and operator accountability. No SmartUI role assignment needed. Configuration: arrange PK+RECH in EasyS, create route, add RECH as Error Entity for PK. Special case: if no dedicated reject station exists, PK itself can be the PIE's error entity.
+**PK with multiple roles:** PK station acting also as a reject station. When a container is rejected at PIE, the target reject station is the PK that originally handled the container - enabling workload balance and operator accountability. No SmartUI role assignment needed. Configuration: arrange PK+RECH in EasyS, create route, add RECH as Error Entity for PK. Special case: if no dedicated reject station exists, PK itself can be the PIE's error entity.
 ## Station Code Translation (FR / ES / EN)
@@ -169,7 +169,7 @@ Mecalux teams work across three languages; the same station can appear in logs a
 ## Station Capacity Semantics (GALILEO view)
-Station capacity has a **different meaning** on PK and PS than on other stations — this trips up Gateway log analysis.
+Station capacity has a **different meaning** on PK and PS than on other stations - this trips up Gateway log analysis.
 | Layer | Generic station (conveyor/TK) | PK and PS |
 |-------|-------------------------------|-----------|
@@ -181,7 +181,7 @@ Worked example (PK): 1 physical slot + 4 in transit on intermediate conveyors +
 ## Route configuration in EasyS (robotics)
-In robotics installations, **every** movement between automated stations requires a route in EasyS. A single task (e.g. `PIE → Miniload`) can generate **N movements** (4 is typical) — the WMS creates one task, the routing table allows each hop.
+In robotics installations, **every** movement between automated stations requires a route in EasyS. A single task (e.g. `PIE → Miniload`) can generate **N movements** (4 is typical) - the WMS creates one task, the routing table allows each hop.
 > If no path exists, EasyWMS creates a **reject task** toward the configured reject station.
@@ -195,7 +195,7 @@ EasyS route types (cross-reference with Manager table below):
 | **Manual** | Operator action triggered by a WMS task |
 | **Virtual** | Instantaneous automatic movement (e.g. output → consolidation) |
-**Reject routes** (in red) are special: they give the **task destination** (not the movement destination). Different `IdentError` reasons can target different reject destinations — see [IdentErrorType](https://msscc.mecalux.com/documentation/Development/master/ES/apis/easywms/Domain/IdentErrorType.md).
+**Reject routes** (in red) are special: they give the **task destination** (not the movement destination). Different `IdentError` reasons can target different reject destinations - see [IdentErrorType](https://msscc.mecalux.com/documentation/Development/master/ES/apis/easywms/Domain/IdentErrorType.md).
 For the protocol layer and message exchange (Search / End / Event / station updates), see [GALILEO Integration](../architecture/galileo-integration.md). For bring-up and simulation, see [Galileo Simulation](../operations/galileo-simulation.md).
@@ -210,7 +210,7 @@ Easy WMS generates tasks based on configured routes. Before generating a task, i
 1. That a route exists between source and destination.
 2. That the route is **active** (all stations in route are not locked).
-Exception: shipping full containers via dock — only checks that a route exists, not whether it's active.
+Exception: shipping full containers via dock - only checks that a route exists, not whether it's active.
 If the shortest active route is blocked, Easy WMS immediately tries an alternative route.
@@ -218,7 +218,7 @@ If the shortest active route is blocked, Easy WMS immediately tries an alternati
 ### Route Managers (Executors)
-Each simple route requires a declared manager — the type of element that will execute tasks on that route:
+Each simple route requires a declared manager - the type of element that will execute tasks on that route:
 | Manager | Executor |
 |---------|----------|
@@ -226,7 +226,7 @@ Each simple route requires a declared manager — the type of element that will
 | Monorail | Monorail system |
 | RF | Operator with RFT (radio frequency terminal) |
 | Voice | Operator with voice terminal |
-| Virtual | Automatic — task auto-completes when container arrives at source station, no physical action |
+| Virtual | Automatic - task auto-completes when container arrives at source station, no physical action |
 | PTL | Pick-to-Light system |
 | External | External system (AGV, vertical warehouse, ERP, etc.) |
 | APS3D Fleet Manager | APS3D cart system |
@@ -278,10 +278,10 @@ Docks and stages are created in **EasyS** (or **Warehouse Designer**), not in Sm
 ## Related
- [[location]] — Location types associated with each station (DockStage, buffer, conventional)
+- [[location]] - Location types associated with each station (DockStage, buffer, conventional)
- [[task]] — Every movement is a task; tasks decompose into simple route movements
+- [[task]] - Every movement is a task; tasks decompose into simple route movements
- [[warehouse-designer]] — Stations are created in EasyS/Warehouse Designer, transferred to SmartUI
+- [[warehouse-designer]] - Stations are created in EasyS/Warehouse Designer, transferred to SmartUI
- [[picking]] — PK, MP, Workzone, Decision, PKE, TenseFlow, Consolidation all support picking
+- [[picking]] - PK, MP, Workzone, Decision, PKE, TenseFlow, Consolidation all support picking
- [[reception]] — Dock, Stage, PIE stations are central to receiving workflows
+- [[reception]] - Dock, Stage, PIE stations are central to receiving workflows
- [[shipping]] — Dock, Stage, PS, Consolidation stations support outbound flow
+- [[shipping]] - Dock, Stage, PS, Consolidation stations support outbound flow
- [[putaway]] — PIE triggers location search; MU refines it closer to warehouse
+- [[putaway]] - PIE triggers location search; MU refines it closer to warehouse
@@ -36,9 +36,9 @@ last_compiled: "2026-04-17"
 A **stock adjustment** is any manual modification to a stock record's quantity, unit of measure (UoM), or logistic attributes that corrects a discrepancy between the physical reality and the WMS records. Every adjustment requires a **reason** for traceability.
 Adjustments can be made from three interfaces:
- **RF terminal (RFT)** — field operators correcting detected errors
+- **RF terminal (RFT)** - field operators correcting detected errors
- **SmartUI (PC web)** — manager-level adjustments from the web interface
+- **SmartUI (PC web)** - manager-level adjustments from the web interface
- **Workstation / picking conveyor** — adjustments at an automatic warehouse PK station
+- **Workstation / picking conveyor** - adjustments at an automatic warehouse PK station
 EasyWMS always notifies the ERP of stock changes via **STV** (stock variation) messages, unless the stock originates from a still-open reception (in which case the change is reflected in the interface but no STV is sent until reception closes).
@@ -146,13 +146,13 @@ Every adjustment requires a **reason code** selected from the master. Reasons ar
 ### RF Terminal Adjustments
 Available options from `RFT > Utilities`:
- **Increase item** — quantity increase
+- **Increase item** - quantity increase
- **Decrease item** — quantity decrease
+- **Decrease item** - quantity decrease
- **Location adjustment** — full adjustment (qty + UoM + AL + status)
+- **Location adjustment** - full adjustment (qty + UoM + AL + status)
- **Manual Movement** — move stock/container (see [manual-movements](../concepts/manual-movements.md))
+- **Manual Movement** - move stock/container (see [manual-movements](../concepts/manual-movements.md))
 RFT also supports:
- **Adjust in picking location with partitions** — reading a partition label sets both location and item
+- **Adjust in picking location with partitions** - reading a partition label sets both location and item
 - **Adjustment during count** (in-count adjustments reported separately)
 ### SmartUI (Web) Adjustments
@@ -211,7 +211,7 @@ A manager must then approve or cancel via `Warehouse > Stock adjustments`:
 **On adjustment (immediate):**
 - EasyWMS sends **STV** (stock variation) to ERP for each affected stock line
-**Exception — open reception:**
+**Exception - open reception:**
 - If adjusted stock belongs to a still-open reception, changes are reflected in the WMS interface but **no STV is sent** until reception closes
 **Double validation:**
@@ -225,7 +225,7 @@ A manager must then approve or cancel via `Warehouse > Stock adjustments`:
 - Adjusting stock with active tasks triggers automatic task cancellation or decrement, then re-release of affected order lines.
 - Adjustment at quantity = 0 in a container: the container is **removed** or **left empty** depending on the location's "remove empty container" configuration.
 - ASN containers (pre-notified, not yet received) cannot be adjusted.
- Client stock (already prepared/loaded for a shipping order) has special handling — it can be adjusted but incompatibility with the order line triggers unassignment.
+- Client stock (already prepared/loaded for a shipping order) has special handling - it can be adjusted but incompatibility with the order line triggers unassignment.
 - For multi-reception stock, the operator selects which specific reception's stock is being adjusted.
 - Cutting stock (non-consolidating UoM) can only be adjusted in whole stretch quantities; partial cutting requires the cutting process.
@@ -241,13 +241,13 @@ A manager must then approve or cancel via `Warehouse > Stock adjustments`:
 Double validation is activated per item via its **count profile** (field: double validation flag in `inventory_management/double_validation/items/count_profile.md`).
-### Count Profile — validation modes (WMS ≥ 2023-02-22)
+### Count Profile - validation modes (WMS ≥ 2023-02-22)
 A **Count Profile** (`Configuration → Count Profiles`) decides whether stock adjustments for an item go straight through or wait for supervisor approval.
 | Mode | Effect |
 |---|---|
-| **Never** | No validation required — STV is sent immediately |
+| **Never** | No validation required - STV is sent immediately |
 | **Always** | Every adjustment is held as `Pending` |
 | **According to tolerance** | Held as `Pending` **only if** the adjustment exceeds the configured tolerance |
@@ -260,7 +260,7 @@ A **Count Profile** (`Configuration → Count Profiles`) decides whether stock a
 | Maximum positive adjust | Absolute increase allowed without validation (base UoM) |
 | Maximum negative adjust | Absolute decrease allowed without validation (base UoM) |
-> ℹ️ Count Profiles cannot yet be created via ITM — master data only in SmartUI.
+> ℹ️ Count Profiles cannot yet be created via ITM - master data only in SmartUI.
 Attach the profile to an item by editing the item and selecting its Count Profile.
@@ -270,7 +270,7 @@ Attach the profile to an item by editing the item and selecting its Count Profil
 - **Rights:** group `SuperAdmin` or `Administrateur` (Manager/Operator not allowed by default).
 - **Group rights do not disable validation.** Even a SuperAdmin creating the adjustment from RFT still triggers the SmartUI validation step if the item has a Count Profile requiring it.
- Default view shows only `Pending` — enable the history filter to see validated/rejected past adjustments.
+- Default view shows only `Pending` - enable the history filter to see validated/rejected past adjustments.
 - Row colours : **green** = validated / no profile / profile "Never" / below tolerance; **red** = rejected.
 **Cancel behaviour:**
@@ -279,9 +279,9 @@ Attach the profile to an item by editing the item and selecting its Count Profil
 ### French UI labels reminder
- **Pending** — no transaction, no ERP communication (stock change *is already applied* in the WMS, only ERP sync is held)
+- **Pending** - no transaction, no ERP communication (stock change *is already applied* in the WMS, only ERP sync is held)
- **Validé** — STV sent to ERP
+- **Validé** - STV sent to ERP
- **Annulé** — stock delta reverted in WMS; no transaction, no ERP message
+- **Annulé** - stock delta reverted in WMS; no transaction, no ERP message
 > ⚠️ Validation only gates the **ERP communication**. The physical stock delta is already reflected in the warehouse whatever the validation outcome.
@@ -295,7 +295,7 @@ Attach the profile to an item by editing the item and selecting its Count Profil
 | `RFT > Utilities > Decrease item` | RFT |
 | `RFT > Utilities > Location adjustment` | RFT |
 | `Workstations > Picking > Others > Stock Adjustment` | PC |
-| `Warehouse > Stock` (SmartUI — logistic attributes) | PC |
+| `Warehouse > Stock` (SmartUI - logistic attributes) | PC |
 | `Warehouse > Stock adjustments` (double validation review) | PC |
 | `Masters > Adjustment reasons` | PC |
@@ -316,11 +316,11 @@ Attach the profile to an item by editing the item and selecting its Count Profil
 ## Related
- [[stock]] — Adjustment modifies stock records; STV and STK.ADJ are core stock transactions
+- [[stock]] - Adjustment modifies stock records; STV and STK.ADJ are core stock transactions
- [[count]] — Counts generate adjustments; double validation applies to count-triggered adjustments too
+- [[count]] - Counts generate adjustments; double validation applies to count-triggered adjustments too
- [[quality-control]] — Quality locks affect picking/replenishment eligibility; separate from adjustments but share CST.STK vs STK.ADJ transactions
+- [[quality-control]] - Quality locks affect picking/replenishment eligibility; separate from adjustments but share CST.STK vs STK.ADJ transactions
- [[location]] — Adjustment behavior (empty container removed vs. kept) depends on location config
+- [[location]] - Adjustment behavior (empty container removed vs. kept) depends on location config
- [[product-item]] — Count profile on item controls double validation activation
+- [[product-item]] - Count profile on item controls double validation activation
- [[container]] — Adjustments to container stock trigger task/assignment re-evaluation
+- [[container]] - Adjustments to container stock trigger task/assignment re-evaluation
- [[cutting-stock]] — Cutting stock adjustments follow indivisibility rules; label printing from location adjustment (source label only)
+- [[cutting-stock]] - Cutting stock adjustments follow indivisibility rules; label printing from location adjustment (source label only)
- [[labels]] — Labels can be printed for cutting stock during location adjustment process
+- [[labels]] - Labels can be printed for cutting stock during location adjustment process
@@ -12,7 +12,7 @@ related:
  - concepts/crossdocking.md
  - concepts/cutting-stock.md
  - concepts/task.md
-  - modules/tenseflow.md
+  - concepts/tense-flow.md
 last_compiled: "2026-04-17"
 ---
@@ -22,7 +22,7 @@ last_compiled: "2026-04-17"
 **Stock assignment** is the engine that binds concrete stock to outbound work. Given an outbound order line (and its `OutboundOrderLineDetails`), it decides **which stock lines** will fulfil the demand and **what type of task** will be created to physically move them (picking, container shipping, replenishment, virtual picking).
-Every line detail is assigned independently — a line can have several details either because the requested item is a **non-assembled kit** (one detail per component) or because **alternative items** have been configured (if the main item is short, the WMS adds an extra detail with the substitute item and zeroes the main item's quantity).
+Every line detail is assigned independently - a line can have several details either because the requested item is a **non-assembled kit** (one detail per component) or because **alternative items** have been configured (if the main item is short, the WMS adds an extra detail with the substitute item and zeroes the main item's quantity).
 The assignment engine is a chain of workflows all prefixed `StockAssignProcess_*`. The main entry point is `StockAssignProcess_AssignOutboundLine_PR`, which loops over the line's details through `StockAssignProcess_AssignOutboundOrderLineDetails_PR`.
@@ -38,16 +38,16 @@ Loads the outbound line detail, locks it for the assignment run, and reads the m
 Workflow: `StockAssignProcess_GetAvailableStockForOutboundOrderLineDetails_PR`
-Calls the query **`Stocks_AssignableForProductOutboundOrderLineDetailsAndStockAssignStrategy`**. Additional filters on assignable stock (e.g., custom-attribute filtering, reservations, supplier constraints) are added as extra `where` clauses on this query — once they are in place, SmartUI surfaces them under the **"Trace d'assignations de stock"** button for auditability.
+Calls the query **`Stocks_AssignableForProductOutboundOrderLineDetailsAndStockAssignStrategy`**. Additional filters on assignable stock (e.g., custom-attribute filtering, reservations, supplier constraints) are added as extra `where` clauses on this query - once they are in place, SmartUI surfaces them under the **"Trace d'assignations de stock"** button for auditability.
 ### 3. Apply assignment strategy
 Two branches:
- **Kits, manufacturing orders, TenseFlow** — the WMS prioritises stock already sitting in the dedicated consumption zone (assembly zone, production supply zone, TenseFlow supply zone) through `StockAssignProcess_CalculateByAssignmentManufacturingAndKits_PR`. This avoids pulling stock across zones when an in-zone alternative exists.
+- **Kits, manufacturing orders, TenseFlow** - the WMS prioritises stock already sitting in the dedicated consumption zone (assembly zone, production supply zone, TenseFlow supply zone) through `StockAssignProcess_CalculateByAssignmentManufacturingAndKits_PR`. This avoids pulling stock across zones when an in-zone alternative exists.
- **Standard details** — applies the outbound priorities (preferred status, preferred UoM…) and then:
+- **Standard details** - applies the outbound priorities (preferred status, preferred UoM…) and then:
-    - `Stocks_ApplyOutboundLogic_PR` — applies the shipping logic of the item (FIFO, FEFO, LIFO, custom).
+    - `Stocks_ApplyOutboundLogic_PR` - applies the shipping logic of the item (FIFO, FEFO, LIFO, custom).
-    - `StockAssignProcess_CalculateEfficiencyMode_PR` — applies the efficiency mode (see [concepts/replenishment.md](replenishment.md#efficiency-modes) and the outbound efficiency settings on the shipping profile).
+    - `StockAssignProcess_CalculateEfficiencyMode_PR` - applies the efficiency mode (see [concepts/replenishment.md](replenishment.md#efficiency-modes) and the outbound efficiency settings on the shipping profile).
 The candidate list is narrowed and finally validated by `StockAssignProcess_ValidateStockList_PR`.
@@ -55,15 +55,15 @@ The candidate list is narrowed and finally validated by `StockAssignProcess_Vali
 Two sibling workflows:
- `StockAssignProcess_CreateAssignments_PR` — writes the assignment rows (visible in SmartUI under **Allocations de stock**).
+- `StockAssignProcess_CreateAssignments_PR` - writes the assignment rows (visible in SmartUI under **Allocations de stock**).
- `Outbound_StockAssignCreateOrderLineDetailsTasks_PR` — translates each assignment into a task of the appropriate type (see below).
+- `Outbound_StockAssignCreateOrderLineDetailsTasks_PR` - translates each assignment into a task of the appropriate type (see below).
 ## Assignment types
 | Type | Description |
 |---|---|
 | **PickingLocations** | Classical picking task on a location flagged as picking. The stock is already at a pickable place. |
-| **ReplenishmentAssignment** | The candidate location permits replenishment but the on-hand quantity is insufficient. The engine creates a **picking task and a parallel replenishment task** — covers both static (PDL-driven) and dynamic replenishment scenarios. |
+| **ReplenishmentAssignment** | The candidate location permits replenishment but the on-hand quantity is insufficient. The engine creates a **picking task and a parallel replenishment task** - covers both static (PDL-driven) and dynamic replenishment scenarios. |
 | **ShippingContainer** | The full container (mono-reference) is needed and the location allows container shipping. A container-shipping task is created instead of a picking task. |
 | **PickingContainer** | Specific to **TenseFlow**. A `BufferReplenishment` task is created first, moving the container to the supply zone ; during virtual picking, virtual picking tasks are generated against the buffered stock. |
@@ -71,15 +71,15 @@ Two sibling workflows:
 ### Kits
-If **any component** of a non-assembled kit cannot be assigned, **no component is assigned** — the engine rolls back and leaves the line short so the operator does not start half-kits. The matching behaviour for assembled kits (ready-made component) is standard.
+If **any component** of a non-assembled kit cannot be assigned, **no component is assigned** - the engine rolls back and leaves the line short so the operator does not start half-kits. The matching behaviour for assembled kits (ready-made component) is standard.
 ### Crossdocking
-When the item allows crossdocking, an inbound expected to arrive shortly will block the engine from re-assigning the outbound line to existing stock — it will wait for the crossdocking candidate. Customers who do not want this behaviour comment out the crossdocking branch in the stock search query.
+When the item allows crossdocking, an inbound expected to arrive shortly will block the engine from re-assigning the outbound line to existing stock - it will wait for the crossdocking candidate. Customers who do not want this behaviour comment out the crossdocking branch in the stock search query.
 ### Alternatives
-When the main item cannot cover the line quantity, the engine inserts a new detail with the alternative item and sets the main item's remaining quantity to zero. The alternative detail goes through the same pipeline — it may itself fall back to another alternative if further shortage occurs.
+When the main item cannot cover the line quantity, the engine inserts a new detail with the alternative item and sets the main item's remaining quantity to zero. The alternative detail goes through the same pipeline - it may itself fall back to another alternative if further shortage occurs.
 ## Customisation points
@@ -87,31 +87,31 @@ When the main item cannot cover the line quantity, the engine inserts a new deta
 |---|---|
 | Expose more line-detail fields to the engine | Extend `Select` in `StockAssignProcess_GetLockAndUpdateDetail_PR` |
 | Filter candidate stock on a new criterion | Add `where` clauses in `Stocks_AssignableForProductOutboundOrderLineDetailsAndStockAssignStrategy` (visible in SmartUI "Trace d'assignations de stock") |
-| Generate **only picking tasks** (e.g., for waves — wave mode only consumes picking tasks) | Modify `StockAssignProcess_GetStockToAssignForStrategy_PR` ; if the WMS version has the assignment-merge feature, also modify `Outbound_CreatePickingLocationsTasks_PR` |
+| Generate **only picking tasks** (e.g., for waves - wave mode only consumes picking tasks) | Modify `StockAssignProcess_GetStockToAssignForStrategy_PR` ; if the WMS version has the assignment-merge feature, also modify `Outbound_CreatePickingLocationsTasks_PR` |
 | Disable crossdocking blocking | Comment out the crossdocking predicate in the stock search query |
 ## Observability
- **SmartUI → Allocations de stock** — shows which stock line is reserved for which outbound line detail, with the assignment type.
+- **SmartUI → Allocations de stock** - shows which stock line is reserved for which outbound line detail, with the assignment type.
- **"Trace d'assignations de stock"** button — exposes the extra filters added to `Stocks_AssignableForProductOutboundOrderLineDetailsAndStockAssignStrategy` so support can see why a candidate was rejected.
+- **"Trace d'assignations de stock"** button - exposes the extra filters added to `Stocks_AssignableForProductOutboundOrderLineDetailsAndStockAssignStrategy` so support can see why a candidate was rejected.
 ## Common issues
 | Symptom | Likely cause |
 |---|---|
 | Outbound line stays in `StockFailure` despite visible stock | Filter on the assignment query (custom clause), preferred status rejecting everything, or logistic attribute mismatch |
-| Kit line assigned with some components but not all | Should not happen — rollback rule is absolute. Check if components were split across two details by an alternative cascade |
+| Kit line assigned with some components but not all | Should not happen - rollback rule is absolute. Check if components were split across two details by an alternative cascade |
 | Expected replenishment-plus-picking not generated | Picking location does not actually permit replenishment, or all candidate reserves are locked |
-| Container shipping task created when picking was expected | Line quantity equals full container quantity **and** location allows container shipping — disable the container-shipping branch on the location if not desired |
+| Container shipping task created when picking was expected | Line quantity equals full container quantity **and** location allows container shipping - disable the container-shipping branch on the location if not desired |
 ## Related
- [[stock]] — the data model assignment writes against
+- [[stock]] - the data model assignment writes against
- [[order-outbound]] — outbound lines and their `OutboundOrderLineDetails` are the inputs of the engine
+- [[order-outbound]] - outbound lines and their `OutboundOrderLineDetails` are the inputs of the engine
- [[picking]] — most assignment outputs are consumed as picking tasks
+- [[picking]] - most assignment outputs are consumed as picking tasks
- [[replenishment]] — `ReplenishmentAssignment` type materialises the replenishment-plus-picking pairing
+- [[replenishment]] - `ReplenishmentAssignment` type materialises the replenishment-plus-picking pairing
- [[kits]] — kit handling special case (all-or-nothing rollback, dedicated assembly-zone preference)
+- [[kits]] - kit handling special case (all-or-nothing rollback, dedicated assembly-zone preference)
- [[crossdocking]] — assignment waits for inbound crossdocking candidates unless disabled
+- [[crossdocking]] - assignment waits for inbound crossdocking candidates unless disabled
- [[cutting-stock]] — cutting items use the same pipeline with cut-specific post-processing
+- [[cutting-stock]] - cutting items use the same pipeline with cut-specific post-processing
- [[task]] — tasks are the tangible output of each assignment
+- [[task]] - tasks are the tangible output of each assignment
- [[tenseflow]] — the PickingContainer assignment type is the TenseFlow-specific path
+- [[tenseflow]] - the PickingContainer assignment type is the TenseFlow-specific path
@@ -39,11 +39,11 @@ last_compiled: "2026-04-17"
 ## Overview
-A **stock record** (stock line) is the physical instance of an item in the warehouse at a specific moment — a quantity of a particular item, owned by a specific owner, in a specific location or container, with specific logistic attributes and status. It is distinct from the item master: the item defines what the product is; the stock defines how much of it exists, where, and in what state.
+A **stock record** (stock line) is the physical instance of an item in the warehouse at a specific moment - a quantity of a particular item, owned by a specific owner, in a specific location or container, with specific logistic attributes and status. It is distinct from the item master: the item defines what the product is; the stock defines how much of it exists, where, and in what state.
 Stock is created when goods are received, consumed when goods are shipped, and transformed (split, merged, adjusted) throughout warehouse operations. The WMS maintains an exact, real-time view of all stock across every location and container in the warehouse. All WMS processes (putaway strategies, stock assignment for outbound orders, replenishment, counting) operate against stock records.
-A single item in the warehouse can have many stock lines — one per unique combination of container, logistic attributes, and status. For example, the same SKU in three different lot numbers stored in two locations will produce at least 6 separate stock lines.
+A single item in the warehouse can have many stock lines - one per unique combination of container, logistic attributes, and status. For example, the same SKU in three different lot numbers stored in two locations will produce at least 6 separate stock lines.
 ## Types
@@ -53,7 +53,7 @@ Stock is classified by its storage context and status:
 - **Containerized stock**: stock inside a container (LPN). The container holds the stock and can be moved as a unit. The stock line references both the container and the location of the container.
 - **Loose stock**: stock directly in a location, not in a container. Common in conventional manual locations with picking dedicated partitions.
- **Client stock**: stock that has been prepared (picked) for a specific outbound order, now in a client (outbound) container. Special rules apply — quantity, UoM, and logistic attributes cannot be adjusted like regular stock.
+- **Client stock**: stock that has been prepared (picked) for a specific outbound order, now in a client (outbound) container. Special rules apply - quantity, UoM, and logistic attributes cannot be adjusted like regular stock.
 - **ASN stock**: stock pre-notified by the ERP but not yet physically received. Located in the virtual ASN location. Cannot be adjusted.
 ### By status
@@ -62,7 +62,7 @@ Stock carries up to three parallel status dimensions:
 | Status type | Description | Set by |
 |---|---|---|
-| **System status** | Internal WMS status (e.g., normal, reserved, assigned) | Automatic — driven by stock assignment and task creation |
+| **System status** | Internal WMS status (e.g., normal, reserved, assigned) | Automatic - driven by stock assignment and task creation |
 | **User status** | Quality or business-driven lock (e.g., "Quarantine", "Hold") | Manually by user, or via ERP STR message. Has optional end date. |
 | **Receiving status** | Quality control status set during reception | At reception, automatically based on receipt order configuration |
@@ -192,7 +192,7 @@ Stock adjustments allow operators to correct discrepancies between the WMS recor
 > **WSC / SCR**: To get the complete stock image, the ERP sends an **SCR** request and EasyWMS responds with a **WSC** file. This can be:
 > - Grouped by item (one line per item/owner/status)
 > - Detailed (with location and container)
-> - The WSC does NOT discriminate "available to sell" — use stock status filtering for that.
+> - The WSC does NOT discriminate "available to sell" - use stock status filtering for that.
 > - Stock at 0 can optionally be included (configurable).
 > - Can be sent on-demand or on a scheduled basis (once/day or at intervals).
@@ -211,7 +211,7 @@ EasyWMS supports a **double validation** mechanism for stock adjustments. When a
 Configuration (per item, in **inventory profile**):
 | Setting | Behavior |
 |---------|---------|
-| **Never** | No double validation — adjustments applied immediately |
+| **Never** | No double validation - adjustments applied immediately |
 | **Always** | All adjustments require manager validation |
 | **By tolerance** | Requires validation only if delta exceeds a configured threshold (absolute value or %) |
@@ -271,7 +271,7 @@ The grouped stock reports provide aggregate views of stock without the per-line
 |---|---|---|
 | Cannot adjust ASN stock | Stock is in pre-notified container not yet received | Receive the container first via the reception process |
 | Cannot adjust client stock | Stock is prepared for a shipping order in a client container | Un-prepare the stock via shipping management, then adjust |
-| Adjustment fails — reason required | No adjustment reason selected | Create reasons in Masters; select one before adjusting |
+| Adjustment fails - reason required | No adjustment reason selected | Create reasons in Masters; select one before adjusting |
 | Stock not visible in view | Stock in virtual location (ASN, Lost_Found) or filtered out | Remove filters; check virtual locations explicitly |
 | Stock in lock not assignable | User or receiving status prevents shipping | Release the lock (manually or via STR from ERP); or add required status to SOR line |
 | Quantity jumps after decrease | Other stock from the same item was consolidated | Separate stock lines if needed; use "From multiple receptions" selection |
@@ -279,15 +279,15 @@ The grouped stock reports provide aggregate views of stock without the per-line
 ## Related
- [[container]] — stock is either containerized (in an LPN) or loose; container locks and type affect stock eligibility
+- [[container]] - stock is either containerized (in an LPN) or loose; container locks and type affect stock eligibility
- [[location]] — every stock record has a location; location logics (allow shipping, allow replenishment) determine eligibility
+- [[location]] - every stock record has a location; location logics (allow shipping, allow replenishment) determine eligibility
- [[product-item]] — item defines the static attributes; stock is the physical quantity with runtime attributes
+- [[product-item]] - item defines the static attributes; stock is the physical quantity with runtime attributes
- [[reception]] — stock is created during the reception process; receiving status can be set at receipt
+- [[reception]] - stock is created during the reception process; receiving status can be set at receipt
- [[picking]] — stock is assigned and picked for outbound orders; picking consumes stock quantity
+- [[picking]] - stock is assigned and picked for outbound orders; picking consumes stock quantity
- [[shipping]] — shipping closes orders and removes stock from the warehouse
+- [[shipping]] - shipping closes orders and removes stock from the warehouse
- [[count]] — counts verify the accuracy of stock records; discrepancies trigger adjustments
+- [[count]] - counts verify the accuracy of stock records; discrepancies trigger adjustments
- [[stock-adjustment]] — detailed adjustment procedures (quantity, UoM, logistic attributes)
+- [[stock-adjustment]] - detailed adjustment procedures (quantity, UoM, logistic attributes)
- [[stock-assignment]] — the allocation engine that binds stock lines to outbound order line details (`StockAssignProcess_*` workflows, assignment types, customisation points)
+- [[stock-assignment]] - the allocation engine that binds stock lines to outbound order line details (`StockAssignProcess_*` workflows, assignment types, customisation points)
- [[order-outbound]] — stock assignment links specific stock lines to SOR lines; reserves and assignments
+- [[order-outbound]] - stock assignment links specific stock lines to SOR lines; reserves and assignments
- [[task]] — tasks move stock between locations; running tasks block certain stock adjustments
+- [[task]] - tasks move stock between locations; running tasks block certain stock adjustments
- [[erp-interface]] — STV message reports stock changes; SCR/WSC for stock contrasts; STR for status locks
+- [[erp-interface]] - STV message reports stock changes; SCR/WSC for stock contrasts; STR for status locks
@@ -19,7 +19,7 @@ last_compiled: "2026-04-10"
 ## Overview
-A **supplier** is a company or entity that supplies stock to the warehouse. Suppliers are referenced on receipt orders (inbound) and return orders (outbound). Every inbound flow — whether a standard delivery, ASN-based reception, or stock return — traces back to a supplier.
+A **supplier** is a company or entity that supplies stock to the warehouse. Suppliers are referenced on receipt orders (inbound) and return orders (outbound). Every inbound flow - whether a standard delivery, ASN-based reception, or stock return - traces back to a supplier.
 Suppliers are master data entities managed in WMS (or synced from ERP via SUP message). When the Owner Extensions module is active, each supplier must be assigned to an owner.
@@ -68,8 +68,8 @@ Suppliers are master data entities managed in WMS (or synced from ERP via SUP me
 ## Related
- [[reception]] — dock reception references the supplier; supplier container and loose stock reception modes exist
+- [[reception]] - dock reception references the supplier; supplier container and loose stock reception modes exist
- [[order-inbound]] — receipt orders (ROR) reference the supplying entity; returns indicate the supplier destination
+- [[order-inbound]] - receipt orders (ROR) reference the supplying entity; returns indicate the supplier destination
- [[product-item]] — items can be received only from suppliers linked via receipt orders
+- [[product-item]] - items can be received only from suppliers linked via receipt orders
- [[owner-extensions]] — when active, suppliers must be assigned to an owner; supplier code is prefixed with owner code
+- [[owner-extensions]] - when active, suppliers must be assigned to an owner; supplier code is prefixed with owner code
- [[erp-interface]] — SUP message syncs supplier master from ERP
+- [[erp-interface]] - SUP message syncs supplier master from ERP
@@ -85,17 +85,17 @@ In **automatic warehouses**, tasks are executed by automated systems (AS/RS, AGV
        ↓
   Task CREATED (pending movement generation)
        ↓
-   PENDING — waiting for movement to be generated
+   PENDING - waiting for movement to be generated
        ↓
-   GENERATED — movement created, no operator/machine assigned yet
+   GENERATED - movement created, no operator/machine assigned yet
        ↓
-   IN PROCESS — currently being executed
+   IN PROCESS - currently being executed
        ↓
-   FINISHED — task completed successfully
+   FINISHED - task completed successfully
-   
+
   (at any point from Generated or In Process)
        ↓
-   CANCELED — task stopped by user action
+   CANCELED - task stopped by user action
 ```
 ### Status transitions
@@ -110,7 +110,7 @@ In **automatic warehouses**, tasks are executed by automated systems (AS/RS, AGV
 ## Tasks and movements
-The task defines **from where to where** (source station → destination station). The actual path may pass through multiple intermediate stations. Easy WMS decomposes the task into **movements** — each movement covers one segment (one station to the next).
+The task defines **from where to where** (source station → destination station). The actual path may pass through multiple intermediate stations. Easy WMS decomposes the task into **movements** - each movement covers one segment (one station to the next).
 Each segment has a configured **manager** (who/what executes it):
 - **RF**: human operator with radio frequency terminal
@@ -133,7 +133,7 @@ Movement release (reset In Execution → Pending) is available for resolving inc
 ## Business rules
 - **Cannot manually complete** picking, counting, replenishment (stock replenishment type), kit assembly, or consolidation tasks. These must be completed through their respective processes.
- **Task assignment** to user or equipment respects work zone restrictions — if the equipment cannot access the required work zone or aisle, the task will not be executable.
+- **Task assignment** to user or equipment respects work zone restrictions - if the equipment cannot access the required work zone or aisle, the task will not be executable.
 - **Equipment incompatibility**: equipment that cannot transport the container type specified in the task is ineligible.
 - **Priority** drives task sequencing within a process queue (lower number = higher priority; values: Very Low, Low, Normal, High, Urgent).
 - **Task cancellation**: container stays where the operator reports it (user must indicate the location, including position for rack locations or depth for channel locations).
@@ -152,7 +152,7 @@ For manual warehouse RF execution, the priority ordering is:
 **Shipping tasks:** Round number → Priority → Empty channel → Stackability → Distance → Creation date
-**Wave picking:** Priority (of the wave/orders assigned) → Route path (right and left sides, low to high — no second rounds)
+**Wave picking:** Priority (of the wave/orders assigned) → Route path (right and left sides, low to high - no second rounds)
 **Order picking (RF):** For task selection: assigned to user/equipment first → Priority → Release date. For task execution: same as automatic tasks.
@@ -201,16 +201,16 @@ Transactions are generated by the underlying process (not by semi-automatic mode
 | Task created but not assignable | Equipment type incompatible with container type in task | Assign different equipment; check equipment container type configuration |
 | Task cannot be manually completed | Task type is picking, counting, stock replenishment, kit assembly, or consolidation | Complete via the appropriate process screen (picking station, count screen, etc.) |
 | Movement stuck In Execution | Automatic system malfunction or communication failure | Use Movement Release to reset to Pending; investigate automation incident |
-| Canceled task — container not found | Operator reported wrong location at cancellation | Run a count or check Last Known Location; resolve via Lost & Found if needed |
+| Canceled task - container not found | Operator reported wrong location at cancellation | Run a count or check Last Known Location; resolve via Lost & Found if needed |
 | Task not generated after process trigger | Work zone restriction prevents any available equipment from executing | Check work zone configuration and available equipment |
 ## Related
- [[location]] — tasks always have a source and destination location; location type (rack, compact, etc.) determines coordinate precision in tasks
+- [[location]] - tasks always have a source and destination location; location type (rack, compact, etc.) determines coordinate precision in tasks
- [[container]] — most automatic warehouse tasks move containers; task references container code and type
+- [[container]] - most automatic warehouse tasks move containers; task references container code and type
- [[stock]] — stock tasks (picking, replenishment) specify item, quantity, and logistic attributes
+- [[stock]] - stock tasks (picking, replenishment) specify item, quantity, and logistic attributes
- [[putaway]] — putaway process generates Putaway tasks; PIE/MU/TRL/ALM stations trigger automatic task creation
+- [[putaway]] - putaway process generates Putaway tasks; PIE/MU/TRL/ALM stations trigger automatic task creation
- [[picking]] — picking process generates Picking tasks; wave/group picking generates batches of tasks
+- [[picking]] - picking process generates Picking tasks; wave/group picking generates batches of tasks
- [[shipping]] — shipping process generates Shipping and Loading tasks for consolidation and dock delivery
+- [[shipping]] - shipping process generates Shipping and Loading tasks for consolidation and dock delivery
- [[replenishment]] — replenishment generates Container replenishment or Stock replenishment tasks to PDLs
+- [[replenishment]] - replenishment generates Container replenishment or Stock replenishment tasks to PDLs
- [[count]] — count processes generate Location count, Container count, or Item count tasks
+- [[count]] - count processes generate Location count, Container count, or Item count tasks
@@ -16,12 +16,12 @@ last_compiled: "2026-04-17"
 ## Overview
-Tense Flow (FR : *flux tendu*) enables picking directly from one or more source supports — typically to prepare an outbound order **straight from reception** without first putting the stock away. The stock never hits a "normal" storage location : it is replenished to a dedicated buffer (FR : *poumon PREPARATION*) and consumed from there virtually.
+Tense Flow (FR : *flux tendu*) enables picking directly from one or more source supports - typically to prepare an outbound order **straight from reception** without first putting the stock away. The stock never hits a "normal" storage location : it is replenished to a dedicated buffer (FR : *poumon PREPARATION*) and consumed from there virtually.
 The flow combines:
 1. A **tense-flow element** + an associated **buffer stage** (typically named `PREPARATION`).
 2. A **replenishment task** from the source location(s) to the buffer, triggered at order release.
-3. **Virtual picking** on the RF terminal — the operator scans the source support + the newly created client container and declares the picked quantity.
+3. **Virtual picking** on the RF terminal - the operator scans the source support + the newly created client container and declares the picked quantity.
 4. A closing step that transfers the client containers to the shipping buffer.
 ## EasyS Configuration
@@ -31,7 +31,7 @@ The flow combines:
 3. Associate the tense-flow element to the buffer as a `Delivery Stage`.
 4. Configure the source locations (buffers and racks) with the option **"Allow origin of replenishement of tense flow"** set to true, otherwise the replenishment task generated at "Lancer en flux tendu" will find no candidate origins.
-> ⚠️ Tense Flow always creates a replenishment task *towards the buffer first* — the source locations must be eligible as tense-flow origins, not only as normal-flow origins.
+> ⚠️ Tense Flow always creates a replenishment task *towards the buffer first* - the source locations must be eligible as tense-flow origins, not only as normal-flow origins.
 ## Functional Flow
@@ -48,7 +48,7 @@ RFT menu : **Tâches → Tâches à flux tendu**. Execute the task to move stock
 RFT menu : **Ordres de sortie → Picking virtuel**.
 1. Scan the **source support** (the pallet / container now at the buffer).
-2. Create a **new client container** — use the **"Générer SSCC"** button to assign a fresh SSCC.
+2. Create a **new client container** - use the **"Générer SSCC"** button to assign a fresh SSCC.
 3. Scan the new container or the destination location.
 4. Enter the item + picked quantity (and any logistic attributes).
@@ -60,16 +60,16 @@ Once all the client containers are filled, transfer them to the `EXPEDITION` buf
 ## Common Errors
-**"Lancer en flux tendu" creates no replenishment task** : either the outbound order is not released yet, or the source locations are not marked as `Allow origin of replenishement of tense flow`. Tense Flow replenishment uses a separate eligibility flag from the standard replenishment — enable it on the candidate origins.
+**"Lancer en flux tendu" creates no replenishment task** : either the outbound order is not released yet, or the source locations are not marked as `Allow origin of replenishement of tense flow`. Tense Flow replenishment uses a separate eligibility flag from the standard replenishment - enable it on the candidate origins.
-**Virtual picking screen rejects the source scan** : the stock is not on the `PREPARATION` buffer yet — the replenishment task must be executed first.
+**Virtual picking screen rejects the source scan** : the stock is not on the `PREPARATION` buffer yet - the replenishment task must be executed first.
-**Remaining stock is not proposed for putaway** : the tense-flow element is not associated to the buffer as a `Delivery Stage` — re-check EasyS step 3.
+**Remaining stock is not proposed for putaway** : the tense-flow element is not associated to the buffer as a `Delivery Stage` - re-check EasyS step 3.
 ## Related
- [Picking](picking.md) — tense flow is a special picking mode that bypasses storage
+- [Picking](picking.md) - tense flow is a special picking mode that bypasses storage
- [Replenishment](replenishment.md) — tense flow generates an upstream replenishment task with its own eligibility flag
+- [Replenishment](replenishment.md) - tense flow generates an upstream replenishment task with its own eligibility flag
- [Reception](reception.md) — tense flow is commonly used to ship freshly received stock without storing it first
+- [Reception](reception.md) - tense flow is commonly used to ship freshly received stock without storing it first
- [Outbound Order](order-outbound.md) — tense flow is triggered on a released outbound order
+- [Outbound Order](order-outbound.md) - tense flow is triggered on a released outbound order
- [Stations & Routes](stations.md) — tense-flow buffer and element are configured alongside standard stations
+- [Stations & Routes](stations.md) - tense-flow buffer and element are configured alongside standard stations
@@ -23,7 +23,7 @@ last_compiled: "2026-04-17"
 ## Overview
-Easy WMS records every significant state change as a **Transaction** — an immutable audit log entry. Transactions serve two purposes:
+Easy WMS records every significant state change as a **Transaction** - an immutable audit log entry. Transactions serve two purposes:
 1. **Audit trail**: Who did what, when, and on which objects
 2. **ERP integration trigger**: "Post-processed" transactions generate ERP messages (see [ERP Interface](erp-interface.md))
@@ -54,7 +54,7 @@ The **Post-processed** flag indicates whether the transaction triggers an ERP me
 ### Regeneration from SmartUI
-The Transactions view gives an end-to-end snapshot of every action done by the WMS. When a transaction is in status **`Envoyé`** (sent) or **`Génération d'erreur`** (generation error), SmartUI allows **regenerating the ERP file** directly — any modification made to the associated BOO code since the original send will be applied to the regenerated message. This is the standard lever used to recover from a post-processing hiccup or a fixed BOO without having to provoke the functional trigger a second time.
+The Transactions view gives an end-to-end snapshot of every action done by the WMS. When a transaction is in status **`Envoyé`** (sent) or **`Génération d'erreur`** (generation error), SmartUI allows **regenerating the ERP file** directly - any modification made to the associated BOO code since the original send will be applied to the regenerated message. This is the standard lever used to recover from a post-processing hiccup or a fixed BOO without having to provoke the functional trigger a second time.
 ## Transaction Catalog
@@ -64,20 +64,20 @@ The Transactions view gives an end-to-end snapshot of every action done by the W
 |------|---------------|-------------|-------------|
 | `CON.ASN.001` | Yes | Container received for ASN order | ASO |
 | `CON.CNL.ASN` | Yes | Pre-notified container rejected/deleted | ASK |
-| `CON.COC` | No | Client container closed in Preparation Zone (MP) | — |
+| `CON.COC` | No | Client container closed in Preparation Zone (MP) | - |
-| `CON.COS.001` | No | Container entered outbound conveyor (PS) | — |
+| `CON.COS.001` | No | Container entered outbound conveyor (PS) | - |
-| `CON.CREATE` | No | Container created (manual, picking, or count) | — |
+| `CON.CREATE` | No | Container created (manual, picking, or count) | - |
-| `CON.DELETE` | No | Container deleted (L&F or after count) | — |
+| `CON.DELETE` | No | Container deleted (L&F or after count) | - |
-| `CON.LOAD` | No | Container loaded during truck loading | — |
+| `CON.LOAD` | No | Container loaded during truck loading | - |
-| `CON.LOCATE` | No | Container moved to storage via putaway task | — |
+| `CON.LOCATE` | No | Container moved to storage via putaway task | - |
-| `CON.MOVE` | No | Container moved without putaway task (or from L&F) | — |
+| `CON.MOVE` | No | Container moved without putaway task (or from L&F) | - |
 | `CON.PIE` | Yes | Container entered via PIE station | ASO |
-| `CON.PRINT` | No | Packing list + client container label print trigger | — |
+| `CON.PRINT` | No | Packing list + client container label print trigger | - |
-| `CON.RECEP` | No | Container received in any reception process | — |
+| `CON.RECEP` | No | Container received in any reception process | - |
-| `CON.SEND.L&F` | No | Container sent to Lost & Found | — |
+| `CON.SEND.L&F` | No | Container sent to Lost & Found | - |
-| `CON.SHIPPED` | No | Container status changed to Shipped (order close) | — |
+| `CON.SHIPPED` | No | Container status changed to Shipped (order close) | - |
-| `CON.SHIPPING` | No | Shipping task confirmed for container | — |
+| `CON.SHIPPING` | No | Shipping task confirmed for container | - |
-| `CON.VASDONE` | No | VAS template applied to container | — |
+| `CON.VASDONE` | No | VAS template applied to container | - |
 **Key data fields by transaction:**
 - `CON.ASN.001`: ContainerCode, LocationCode, Document1=ReceiptCode, Document2=ContainerTypeCode
@@ -90,9 +90,9 @@ The Transactions view gives an end-to-end snapshot of every action done by the W
 | Code | Post-processed | Description | ERP Message |
 |------|---------------|-------------|-------------|
-| `COU.CLS` | No | Count closed | — |
+| `COU.CLS` | No | Count closed | - |
-| `COU.CNL` | No | Count canceled | — |
+| `COU.CNL` | No | Count canceled | - |
-| `COU.CST` | No | Count status changed | — |
+| `COU.CST` | No | Count status changed | - |
 | `COU.END` | Yes | Count closed/canceled (ERP-initiated count) | COF |
 **Notes:**
@@ -106,26 +106,26 @@ The Transactions view gives an end-to-end snapshot of every action done by the W
 | Code | Post-processed | Description | ERP Message |
 |------|---------------|-------------|-------------|
 | `STK.ADJ` | Yes | Stock quantity adjusted (SmartUI/RF/workstation) | STV |
-| `STK.ASN` | No | Stock created in ASN container (pre-notified) | — |
+| `STK.ASN` | No | Stock created in ASN container (pre-notified) | - |
-| `STK.CREATE` | No | Stock created manually or from ASN loose stock | — |
+| `STK.CREATE` | No | Stock created manually or from ASN loose stock | - |
-| `STK.DELETE` | No | Stock line deleted (fused stock split) | — |
+| `STK.DELETE` | No | Stock line deleted (fused stock split) | - |
-| `STK.KIT.COMP` | No | Stock consumed for kit assembly | — |
+| `STK.KIT.COMP` | No | Stock consumed for kit assembly | - |
-| `STK.KIT.UCOMP` | No | Stock obtained from kit disassembly | — |
+| `STK.KIT.UCOMP` | No | Stock obtained from kit disassembly | - |
 | `STK.KIT.MOUNT` | Yes | Kit assembled | KST |
 | `STK.KIT.UMOUNT` | Yes | Kit disassembled | UNK |
-| `STK.LOAD` | No | Stock moved during truck loading | — |
+| `STK.LOAD` | No | Stock moved during truck loading | - |
-| `STK.LOCATE` | No | Stock moved to storage via putaway task | — |
+| `STK.LOCATE` | No | Stock moved to storage via putaway task | - |
-| `STK.MOVE` | No | Stock moved manually (or inside container after CON.MOVE) | — |
+| `STK.MOVE` | No | Stock moved manually (or inside container after CON.MOVE) | - |
-| `STK.PICKING` | No | Picking confirmed (stock moved from source to picking container) | — |
+| `STK.PICKING` | No | Picking confirmed (stock moved from source to picking container) | - |
-| `STK.RECEP` | No | Stock created during reception (supplier/return/blind) | — |
+| `STK.RECEP` | No | Stock created during reception (supplier/return/blind) | - |
 | `STK.REP.001` | Yes | Pre-notified loose stock replenished (auto warehouse) | SRO |
 | `STK.REP.CNL` | Yes | Pre-notified loose stock canceled (auto warehouse) | SRK |
-| `STK.SCR` | No | Stock scrapped from RF terminal | — |
+| `STK.SCR` | No | Stock scrapped from RF terminal | - |
-| `STK.SEND.L&F` | No | Stock sent to Lost & Found | — |
+| `STK.SEND.L&F` | No | Stock sent to Lost & Found | - |
-| `STK.SHIPPED` | No | Stock shipped (container status = Shipped) | — |
+| `STK.SHIPPED` | No | Stock shipped (container status = Shipped) | - |
 | `STK.SPLIT` | Yes | Stock UoM broken down (picking or workstation split) | STV (split) |
-| `STK.UMERGE` | No | Fused stock line split/un-merged | — |
+| `STK.UMERGE` | No | Fused stock line split/un-merged | - |
-| `STK.VASDONE` | No | VAS template applied to stock | — |
+| `STK.VASDONE` | No | VAS template applied to stock | - |
 **Key data fields by transaction:**
 - `STK.ADJ`: LocationCode, ContainerCode, Quantity, TaskNumber
@@ -161,8 +161,8 @@ The Transactions view gives an end-to-end snapshot of every action done by the W
 | Code | Post-processed | Description | ERP Message |
 |------|---------------|-------------|-------------|
 | `REC.CLS` | Yes | Receipt manually or auto-closed (with stock) | REF |
-| `REC.CNL` | No | Receipt manually canceled | — |
+| `REC.CNL` | No | Receipt manually canceled | - |
-| `REC.CST` | No | Receipt status changed (Pending → Receiving) | — |
+| `REC.CST` | No | Receipt status changed (Pending → Receiving) | - |
 ---
@@ -173,8 +173,8 @@ The Transactions view gives an end-to-end snapshot of every action done by the W
 | `OUT.CLS` | Yes | Shipping order closed/force-closed | SOF |
 | `OUT.CNL` | Yes | Shipping order canceled | SOF |
 | `OUT.CST` | Yes | Shipping order status changed | SOC |
-| `OUT.GRP` | No | Shipping order added to group/fusion | — |
+| `OUT.GRP` | No | Shipping order added to group/fusion | - |
-| `OUT.UNG` | No | Shipping order removed from group/fusion | — |
+| `OUT.UNG` | No | Shipping order removed from group/fusion | - |
 ---
@@ -182,11 +182,11 @@ The Transactions view gives an end-to-end snapshot of every action done by the W
 | Code | Post-processed | Description | ERP Message |
 |------|---------------|-------------|-------------|
-| `ROU.CLS` | No | Route closed | — |
+| `ROU.CLS` | No | Route closed | - |
-| `ROU.CNL` | No | Route canceled | — |
+| `ROU.CNL` | No | Route canceled | - |
-| `ROU.CST` | No | Route status changed | — |
+| `ROU.CST` | No | Route status changed | - |
 | `LOAD.CLS` | Yes | Load closed (manual or auto on route close) | LOF |
-| `LOAD.CST` | No | Load paused or reactivated | — |
+| `LOAD.CST` | No | Load paused or reactivated | - |
 ---
@@ -213,7 +213,7 @@ The Transactions view gives an end-to-end snapshot of every action done by the W
 |------|---------------|-------------|-------------|
 | `WOR.CLS.001` | Yes | Work order (kits/manufacturing) closed | WOF |
 | `WOR.CNL.001` | Yes | Work order canceled | WOF |
-| `WOR.CST.001` | No | Work order status changed | — |
+| `WOR.CST.001` | No | Work order status changed | - |
 ---
@@ -259,7 +259,7 @@ The Transactions view gives an end-to-end snapshot of every action done by the W
 | Code | Post-processed | Description | ERP Message |
 |------|---------------|-------------|-------------|
-| `SCR.DET` | No | Stock contrast detail (intermediate) | — |
+| `SCR.DET` | No | Stock contrast detail (intermediate) | - |
 | `SCR.REQ` | Yes | Stock contrast requested | WSC |
 | `STOCKSYNC.ASKED` | Yes | Full warehouse stock sync to ERP requested | WSC |
@@ -275,7 +275,7 @@ The Transactions view gives an end-to-end snapshot of every action done by the W
 ## Notification Events
-Notification Events are operational alerts that fire when specific conditions arise. They are distinct from transactions — they do not generate ERP messages, but they can trigger SCEM subscriptions (email, SMS, web alerts).
+Notification Events are operational alerts that fire when specific conditions arise. They are distinct from transactions - they do not generate ERP messages, but they can trigger SCEM subscriptions (email, SMS, web alerts).
 See [Supply Chain Event Management](../modules/supply-chain-event.md) for subscription management.
@@ -345,13 +345,13 @@ Additional notification events are defined by optional modules:
 ## Related
- [ERP Interface](erp-interface.md) — ERP messages triggered by post-processed transactions
+- [ERP Interface](erp-interface.md) - ERP messages triggered by post-processed transactions
- [Stock](stock.md) — STK.ADJ, STK.MOVE, STK.PICKING
+- [Stock](stock.md) - STK.ADJ, STK.MOVE, STK.PICKING
- [Container](container.md) — CON.* transactions
+- [Container](container.md) - CON.* transactions
- [Inbound Order](order-inbound.md) — INO.CST, INO.CLS → ROC, ROF
+- [Inbound Order](order-inbound.md) - INO.CST, INO.CLS → ROC, ROF
- [Outbound Order](order-outbound.md) — OUT.CST, OUT.CLS → SOC, SOF
+- [Outbound Order](order-outbound.md) - OUT.CST, OUT.CLS → SOC, SOF
- [Count](count.md) — COU.END → COF
+- [Count](count.md) - COU.END → COF
- [Quality Control](quality-control.md) — CST.STK → STC
+- [Quality Control](quality-control.md) - CST.STK → STC
- [Application Dictionary](../architecture/application-dictionary.md) — Commands and Events that generate transactions
+- [Application Dictionary](../architecture/application-dictionary.md) - Commands and Events that generate transactions
- [Security](../architecture/security.md) — Transactions as audit trail
+- [Security](../architecture/security.md) - Transactions as audit trail
- [Supply Chain Event Management](../modules/supply-chain-event.md) — Notification event subscriptions
+- [Supply Chain Event Management](../modules/supply-chain-event.md) - Notification event subscriptions
@@ -61,7 +61,7 @@ Defines the physical dimensions of containers used in the warehouse. The contain
 | Gauge | Maximum deviation in width due to cargo slump (mm). Effective width = empty width + 2× gauge |
 | Shippable as package | Can be shipped directly in eCommerce process |
-**Container relationships:** Each container type can declare interior container types — a maximum number of smaller containers that fit inside (nesting/palletizing rules). Relationships are added, deleted, or edited independently.
+**Container relationships:** Each container type can declare interior container types - a maximum number of smaller containers that fit inside (nesting/palletizing rules). Relationships are added, deleted, or edited independently.
 **Deletion:** Cannot delete a container type in use by any location. System shows total locations affected + breakdown by warehouse before allowing deletion.
@@ -139,7 +139,7 @@ Editing an equipment type can cause incompatibilities in location searches or or
 ### Equipment
-A physical means of transporting containers through the warehouse — operators with carts, forklifts, manual handling devices, etc. Equipment is associated with tasks: putaway, replenishment, picking, shipping.
+A physical means of transporting containers through the warehouse - operators with carts, forklifts, manual handling devices, etc. Equipment is associated with tasks: putaway, replenishment, picking, shipping.
 **Attributes:**
@@ -241,7 +241,7 @@ Full three-dimensional representation of the warehouse:
 | Feature | Description |
 |---------|-------------|
 | General status | Locked aisles (inbound/outbound/both), AS/RS PK work modes, PIE and route status, MP preparation zones |
-| Station status | Click any station: capacity, occupation %, work mode, etc. — varies by station type |
+| Station status | Click any station: capacity, occupation %, work mode, etc. - varies by station type |
 | Shelf status | Click any shelf: free/occupied/blocked locations summary |
 | Container search | Find a specific container (LPN) by code |
 | Item search | Locate all stock of a specific item across the warehouse |
@@ -300,8 +300,8 @@ Visual activity intensity map overlaid on 2D view:
 ## Related
- [[location]] — Rack types and storage zones directly configure location properties
+- [[location]] - Rack types and storage zones directly configure location properties
- [[stations]] — Stations created in EasyS; Warehouse Designer edits docks/stages/shelves post-transfer
+- [[stations]] - Stations created in EasyS; Warehouse Designer edits docks/stages/shelves post-transfer
- [[container]] — Container types define dimensions used in warehouse design
+- [[container]] - Container types define dimensions used in warehouse design
- [[putaway]] — Storage zones and subwarehouses configure putaway strategy targeting
+- [[putaway]] - Storage zones and subwarehouses configure putaway strategy targeting
- [[replenishment]] — Work zones define equipment eligibility for replenishment tasks
+- [[replenishment]] - Work zones define equipment eligibility for replenishment tasks
@@ -9,7 +9,7 @@ related:
  - concepts/product-item.md
  - concepts/reception.md
  - concepts/stations.md
-  - modules/pie.md
+  - concepts/mechanical-elements.md
 last_compiled: "2026-04-17"
 ---
@@ -17,7 +17,7 @@ last_compiled: "2026-04-17"
 ## Overview
-EasyWMS tracks **five distinct weight fields** on every container and **two weight fields** on every stock line. These fields support reception sanity checks, detection of shrinkage or miscounts at the PIE (weighing station), and variable-weight items (e.g., meat, fish, fruit sold by the kilo). Understanding which field is updated by which event — and which one the shipping / reporting logic reads — is critical: the French UI term *"poids théorique"* is ambiguous (it can mean either of two different fields).
+EasyWMS tracks **five distinct weight fields** on every container and **two weight fields** on every stock line. These fields support reception sanity checks, detection of shrinkage or miscounts at the PIE (weighing station), and variable-weight items (e.g., meat, fish, fruit sold by the kilo). Understanding which field is updated by which event - and which one the shipping / reporting logic reads - is critical: the French UI term *"poids théorique"* is ambiguous (it can mean either of two different fields).
 ## Container-level weight fields
@@ -31,7 +31,7 @@ Five fields, each with a distinct trigger and formula.
 | **Real Weight** | Poids réel | `max(Calculated Weight, Theoretical Scale Weight)` | Recomputed automatically when its inputs change |
 | **Theoretical Scale Weight** | Poids théorique (balance) | Scale Weight − adjustments | Set after PIE pass, then updated by adjustments |
-> ⚠️ **Translation trap** — *"Poids théorique"* in French maps to **two different fields** in English:
+> ⚠️ **Translation trap** - *"Poids théorique"* in French maps to **two different fields** in English:
 > - **Poids théorique (article)** = `Theoretical Weight` (from the item master)
 > - **Poids théorique (balance)** = `Theoretical Scale Weight` (from the scale, minus adjustments)
 >
@@ -54,13 +54,13 @@ On each stock line (`Stock` record):
 | **Poids (kg)** | Real weight of the line |
 | **Poids théorique (kg)** | Theoretical weight of the line, from the item master |
-Stock-line weights are updated on stock adjustments, weighings, and custom processes **only when the item is configured as variable-weight**. The PIE does **not** update stock-line weights directly — it updates container-level fields only.
+Stock-line weights are updated on stock adjustments, weighings, and custom processes **only when the item is configured as variable-weight**. The PIE does **not** update stock-line weights directly - it updates container-level fields only.
 ## Behavior at stock creation
- **Real weight of the stock (line)** starts at `0` — it is only populated by a PIE pass, a `StockAdjust` on a variable-weight item, or a custom.
+- **Real weight of the stock (line)** starts at `0` - it is only populated by a PIE pass, a `StockAdjust` on a variable-weight item, or a custom.
 - **Theoretical weight of the stock (line)** is computed immediately from the item master.
- **Container tare weight** (pallet type weight in EasyS) is **frozen at container creation** — changing the tare in EasyS later **does not propagate** to existing containers. Only newly created containers pick up the new tare.
+- **Container tare weight** (pallet type weight in EasyS) is **frozen at container creation** - changing the tare in EasyS later **does not propagate** to existing containers. Only newly created containers pick up the new tare.
 ## PIE pass
@@ -97,11 +97,11 @@ The workflow **`Stock_CheckWeightToCreateStockInContainer_UI`** runs at stock cr
 - Compares the entered weight against the item master.
 - If the item is variable-weight and the tolerance is exceeded, it **raises an RFT alert** (does not reject).
-> Reject-rather-than-alert behaviour at the PIE requires a custom workflow — see *Open questions* below.
+> Reject-rather-than-alert behaviour at the PIE requires a custom workflow - see *Open questions* below.
 ## Worked examples
-### Fixed-weight item — 25 kg pallet, item weighs 250 kg
+### Fixed-weight item - 25 kg pallet, item weighs 250 kg
 | Step | Calculated | Scale | Theoretical (item) | Real | Theoretical Scale |
 |---|---|---|---|---|---|
@@ -114,9 +114,9 @@ The workflow **`Stock_CheckWeightToCreateStockInContainer_UI`** runs at stock cr
 |---|---|---|---|---|---|
 | New pallet | 280 | 280 | 274 | 274 | 280 |
-> Theoretical (item) = 250 (goods) + 24 (new pallet tare). The older pallet keeps 275 — confirming that the container tare is frozen at creation.
+> Theoretical (item) = 250 (goods) + 24 (new pallet tare). The older pallet keeps 275 - confirming that the container tare is frozen at creation.
-### Variable-weight item — 10 bags, 100 kg declared
+### Variable-weight item - 10 bags, 100 kg declared
 | Step | Calculated | Scale | Theoretical (item) | Real | Theoretical Scale |
 |---|---|---|---|---|---|
@@ -134,8 +134,8 @@ The workflow **`Stock_CheckWeightToCreateStockInContainer_UI`** runs at stock cr
 ## Related
- [[container]] — all five weight fields are attributes of the container ; see "SSCC and weights" on the container page
+- [[container]] - all five weight fields are attributes of the container ; see "SSCC and weights" on the container page
- [[stock]] — the two stock-line fields, updated for variable-weight items
+- [[stock]] - the two stock-line fields, updated for variable-weight items
- [[product-item]] — logistic profile carries the variable-weight and "Poids moyen" flags, item master holds unit weight
+- [[product-item]] - logistic profile carries the variable-weight and "Poids moyen" flags, item master holds unit weight
- [[reception]] — receipt line can carry the expected weight used by "Poids moyen" at stock creation
+- [[reception]] - receipt line can carry the expected weight used by "Poids moyen" at stock creation
- [[stations]] — PIE station type drives scale-weight capture
+- [[stations]] - PIE station type drives scale-weight capture
@@ -347,3 +347,305 @@
  - Mis à jour `_index.md` (ajout entrée operations/agv-installation.md dans Batch 13, mise à jour description modules/agv.md, compteur Operations 19→20)
  - Mis à jour `glossary.md` (ajout termes : DBLink, dg4odbc, Gateway AGV)
  **Questions** : aucune
 ## [2026-07-16] session-019 (mode: limagrain)
 > Source : lecture directe des tickets Jira LOT (pas de fichier déposé dans `sources/`).
 - **Fichier** : `Jira LIM-62` (lecture directe)
  **Type** : Ticket Jira — #LOT 1.1 [RECEPTION] Gestion camions V1
  **Action** : Mis à jour `limagrain/01-inbound/gestion-camions.md` (statut : LIM-62 V1 clôturée/annulée, validée fonctionnellement par Justine le 27/05, suite en LIM-97 V2 ; ajout note statut, ligne historique, ligne Références LIM-97, front matter jira_refs + last_updated)
  **Cross-refs** : gestion-camions.md → LIM-97 (référence successeur V2)
  **Questions** : aucune nouvelle (contenu V1 déjà documenté ; évolutions V2 à traiter via LIM-97)
 - **Fichier** : `Jira LIM-63` (lecture directe)
  **Type** : Ticket Jira — #LOT 1.1 [RECEPTION + EXPEDITION] Affichage chauffeurs
  **Action** : Enrichi `limagrain/01-inbound/gestion-camions.md` (Étape 3 : statut pré-production, précision station de travail dédiée, tableau implémentation technique — dialog `CST_Workstation_Docks_DisplayDocksInformation`, workflow `CST_Workstation_Dock`, vue/viewgroup `CST_Workstation_Docks`, champ `RealStationWF.CST_LicencePlates`, ressource, MenuItem PanelMode)
  **Cross-refs** : réutilisation query `CST_DockStationsWorkload_ForView` (LIM-62)
  **Questions** : aucune nouvelle
 - **Fichier** : `Jira LIM-64` (lecture directe)
  **Type** : Ticket Jira — #LOT 1.1 [RECEPTION] TRF Déclaration image de quai V1
  **Action** : Enrichi `limagrain/01-inbound/gestion-camions.md` (Étape 4 : statut V1 annulée → LIM-96 V2 + modifs fonctionnelles planifiées V2 ; ajout attributs support CstAtt01/04/08, compteur palettes déclarées, réimpression étiquette 800*, mode pile de palettes PALETTES BOIS, tableau éléments AD — dialogs/workflows/queries/report/view ; caveat big-bag CstAtt01 vs CstAtt02) ; mis à jour `glossaire-limagrain.md` (ajout CstAtt08 support, précision CstAtt12 reporté LIM-96)
  **Cross-refs** : LIM-96 (V2), LIM-14 (séquence 800), LIM-71 (CstAtt04)
  **Questions** : distinction big-bag CstAtt01 (label LIM-64) vs CstAtt02 (flag poste de travail) → à confirmer en LIM-96
 - **Fichier** : `Jira LIM-65` (lecture directe)
  **Type** : Ticket Jira — #LOT 1.1 [RECEPTION] Etiquette support image de quai
  **Action** : Enrichi `limagrain/01-inbound/gestion-camions.md` (section Étiquette : statut pré-production, ajout champ OE, QR Code GS1 AI 00 support + AI 91 OE avec exemple, réutilisation flux retour fournisseur, tableau éléments AD — report, record ParsedContainerLabelWF, workflows ParseContainerLabel + CST_Reception_Return_ATH214_CheckData_UI)
  **Cross-refs** : LIM-96 (impression), flux retour fournisseur
  **Questions** : aucune nouvelle (AI GS1 déjà au glossaire)
 - **Fichier** : `Jira LIM-66` (lecture directe)
  **Type** : Ticket Jira — #LOT 1.3 [ENTREE/SORTIE] Passage PIE - poids et verrous
  **Action** : Corrigé `limagrain/01-inbound/controle-qualite-reception.md` — REVERSAL majeur : seuil de tolérance revenu au poids ITM théorique (abandon de l'approche CstAtt01 dynamique, décision 19/06/2026) ; CstAtt01 conservé pour répartition prorata uniquement ; notification SmartUI abandonnée → redirection erreur poids standard (PIE_EventHandler_CheckToleranceWeight_PR) ; ajout section éléments AD (CST_PIE_ApplyWeightRules_PR, CST_StockView, CST_Stocks_ForView, StockVList) ; statut pré-production ; questions ouvertes reformulées (résolu tolérance, ouvert STV) ; rejet ECART RETOUR → LIM-114. Mis à jour `glossaire-limagrain.md` (ajout CstAtt01 ligne de stock)
  **Cross-refs** : LIM-114 (flux rejet PIE)
  **Questions** : STV envoyé ou non lors de l'ajustement de poids (@Vincent) — reporté dans questions ouvertes de la page
 ## [2026-07-16] session-020 (mode: limagrain)
 > Source : lecture directe des tickets Jira LOT (pas de fichier déposé dans `sources/`).
 - **Fichier** : `Jira LIM-67` (lecture directe, 29 commentaires inclus)
  **Type** : Ticket Jira - #LOT 1.3 [RECEPTION] Postes de travail - Flux fournisseurs/intersites
  **Action** : Enrichi `limagrain/01-inbound/reception-fournisseur.md` depuis la relecture des commentaires (revue de code validée 29/06, livré préprod 09/07) : section 5 démarre par scan conteneur virtuel + code conteneur auto-généré + report CstAtt08 ; §2 SSCC refondue (codes conteneurs attendus du ROR / scan support LIMAGRAIN + bouton Liste / CstAtt13, SSCC uniquement si aucun code ROR) ; sous-section 6 tables de préparation + poste de picking adjacent (blocage ouverture, palettes liées, CstAtt06) ; ajout action menu « Retirer support » (DeleteContainer) ; sous-section validation attributs logistiques → LIM-93 ; tableau CstAtt complété (CstAtt06, CstAtt13) ; champ CST_SupplierName ReceptionWF ; front matter (jira_refs LIM-68/93, last_updated), Historique, Références. Mis à jour `limagrain/glossaire-limagrain.md` (CstAtt10, CstAtt13, caveat conflit CstAtt06). Mis à jour `limagrain/08-transverse/questions-ouvertes.md` (conflit CstAtt06 LIM-67 vs LIM-71).
  **Cross-refs** : LIM-68 (étiquette RFID), LIM-93 (attributs logistiques), LIM-71 (conflit CstAtt06)
  **Questions** : conflit d'usage CstAtt06 support (LIM-67 poste de picking lié vs LIM-71 destination job) → reporté dans questions-ouvertes.md et glossaire
 ## [2026-07-17] session-021 (mode: limagrain)
 > Source : lecture directe des tickets Jira LOT (pas de fichier déposé dans `sources/`).
 - **Fichier** : `Jira LIM-68` (lecture directe, 9 commentaires inclus)
  **Type** : Ticket Jira - #LOT 1.3 [RECEPTION/EXPEDITION] Étiquette support RFID - Monoréférence & Multiref
  **Action** : Enrichi `limagrain/01-inbound/etiquette-rfid.md` depuis la relecture des commentaires (revue de code validée 24/03/2026) : renommage page (mono + multiréférence), double flux (réception + étiqueteuse auto expédition), ajout rapport multiréférence (SSCC seul), variante mono-ref avec quantité pour étiqueteuse auto, section Implémentation (WF CST_PrintRFIDLabel, Reception_PrintContainerLabels_UI, Container_MovedEvent_PR_V1, Container_MovedEventHandler_Labeler_PR, ressource CST_PrintInfo_2, imprimante virtuelle ZPL, code 18 car.), encodage actuel marqué « ASCII 8 bits User », nouvelle section évolution encodage 7 bits banque EPC (décision 06/07/2026, en attente client + spec Bartender) : puce Impinj M830, packing C#, lecture CIPAM, discriminant longueur hexa, mot PC, perma-lock, séquencement ; front matter (standard_ref labels.md, last_updated), Historique, Références. Mis à jour `_index.md` (résumé section). Mis à jour `glossaire-limagrain.md` (EPC, CIPAM, Bartender, CST_PrintRFIDLabel, Mot PC). Cross-ref ajoutée dans `04-outbound/flux-expedition.md` (étiqueteuse auto → page RFID).
  **Cross-refs** : flux-expedition.md (étiqueteuse auto), reception-fournisseur.md (déjà en place), concepts/labels.md + stations.md (standard)
  **Questions** : validation client encodage 7 bits EPC, spec packing Bartender/Eliatys, seuil longueur hexa legacy (JBR/SVA), tests ZT421 + perma-lock → reportées dans questions-ouvertes.md
 - **Fichier** : `Jira LIM-69` (lecture directe, 6 commentaires inclus)
  **Type** : Ticket Jira - #LOT 1.3 Modes de travail des PK
  **Action** : Enrichi `limagrain/03-picking/stations-picking.md` (description déjà intégrée le 12/05) depuis la relecture des commentaires (revue de code validée 31/03, statut pré-production) : ajout section Éléments AD (entité CST_PkStationWorkMode, queries CST_PkStationWorkMode_ForView + CST_PickingStation_Adjacent, vues CST_VAssistAssignWorkMode + PkMpVList, WF WorkStation_Picking_OpenCloseStation_UI param CST_AdjacentPickingStation, ressources FR/EN dont CST_Picking_ConfirmOpenWithAdjacent_1) ; note statut pré-production + historique revue de code (préfixe CST_ manquant, suffixe _1) ; note reversal sur les contraintes de priorité (séquence continue / doublon / trou abandonnées → entiers libres) ; question Justine (ordre croissant priorités) en questions ouvertes ; front matter last_updated, Historique, Références. Mis à jour `glossaire-limagrain.md` (CST_PkStationWorkMode).
  **Cross-refs** : job-assignation-pk.md (Mega Job LIM-70, déjà en place)
  **Questions** : affichage priorités en ordre croissant dans la vassist (Justine, 20/05) → reporté dans la page
 - **Fichier** : `Jira LIM-70` (lecture directe, 7 commentaires inclus)
  **Type** : Ticket Jira - #LOT 1.3 [AGV][JOB] MEGA JOB - assignation d'ordre par priorité de process par PK
  **Action** : Enrichi `limagrain/03-picking/job-assignation-pk.md` (description déjà intégrée le 12/05) depuis la relecture des commentaires (2 revues de code validées 03/04 puis 29/06, statut préprod) : ajout section Éléments AD (job+WF CST_PickingStationAssignment_Job intervalle 5s, query CST_PickingStations_AvailableForAssignation, query CST_AnyOutboundOrderReleasingStatus) ; nouvelle sous-section « Condition de sortie globale - OS en Releasing » (motif : release non ordonné) ; ajout condition d'éligibilité CstAtt06 (conteneur de réception assigné au PK, contrôle 26/06) + note reliant au conflit CstAtt06 (LIM-67) ; note statut/revues de code ; résolution de la question ouverte fréquence (5s) ; front matter last_updated, Historique, Références. Mis à jour `glossaire-limagrain.md` (CST_PickingStationAssignment_Job, Releasing OS).
  **Cross-refs** : stations-picking.md (modes LIM-69), questions-ouvertes.md (conflit CstAtt06), sous-WF LIM-74/75/80 (déjà en place)
  **Questions** : aucune nouvelle (fréquence résolue) ; le contrôle CstAtt06 conforte l'usage réception vs le conflit LIM-71 déjà tracé
 - **Fichier** : `Jira LIM-71` (lecture directe, 18 commentaires inclus)
  **Type** : Ticket Jira - #LOT 1.2 [RECEPTION][PRODUCTION][AGV] Job de création des tâches images de quai > ASRS
  **Action** : Réécrit `limagrain/05-agv/job-reception-production.md` depuis la relecture des commentaires (statut préprod, 3 revues de code validées 27/03, 28/04, 01/07) : REVERSAL abandon du marquage CstAtt06 (anti-doublon = absence de tâche active, permet régénération après annulation) ; destination désormais via stratégies de rangement (DESTINATION_PRODUCTION obsolète) ; ajout gestion piles de palettes vides (code PAL) ; REVERSAL condition CstAtt12 (essayée puis retirée pour production/piles - pas d'étiquette) ; section Éléments AD (job CST_StoreProductionContainer_Job 30s, query CST_AvailableProductionContainers, vue LocationPutawayStrategyVList avec stages, WF Galileo_PIEEventHandler_PR) ; section job de régénération CST_Reception_RegenerateTask_Job (15s, query CST_ReceptionContainers_WithoutTasksToPK, flux réception fournisseur→PK) ; éligibilité DockStage ; questions résolues ; front matter, Historique, Références. RÉSOLUTION conflit CstAtt06 (LIM-71 n'utilise plus CstAtt06) propagée : `glossaire-limagrain.md` (CstAtt06, DESTINATION_PRODUCTION obsolète), `01-inbound/reception-fournisseur.md` (note tableau CstAtt + question ouverte + front matter/historique), `08-transverse/questions-ouvertes.md` (2 questions résolues + historique).
  **Cross-refs** : reception-fournisseur.md (LIM-67, CstAtt06/08), job-assignation-pk.md (LIM-70), LIM-64 (image quai), LIM-66 (PIE), LIM-96 (étiquetage)
  **Questions** : conflit CstAtt06 résolu ; reste ouvert : redirection multi-poumons/multi-PIE (config EasyS) → dans la page
 - **Fichier** : `Jira LIM-72` (lecture directe, 3 commentaires inclus)
  **Type** : Ticket Jira - #LOT 1.3 [RETOUR] Flux complet PK V1 - Annulée
  **Action** : Ticket confirmé **Annulé(e)** (V1), explicitement repris par LIM-93 (V2). Intégration légère selon pattern V1/V2 : pas de duplication du détail. `limagrain/01-inbound/reception-retour.md` - ajout note de supersession (bloc résumé, table process étape 3, section « État du développement LIM-72 (V1 annulé → LIM-93) »), jira_refs (ajout LIM-93), last_updated, Historique, Références (LIM-72 V1 Annulé + LIM-93 V2). Contenu V1 conservé comme référence à valider. `limagrain/05-agv/job-reception-pk.md` - cross-ref étape 3 annotée V1→LIM-93. Détail définitif différé à la relecture de LIM-93.
  **Cross-refs** : LIM-93 (reprise V2), reception-retour.md, job-reception-pk.md
  **Questions** : aucune nouvelle ; détail retour PK à relire sur LIM-93
 - **Fichier** : `Jira LIM-73` (lecture directe, 16 commentaires inclus)
  **Type** : Ticket Jira - #LOT 1.3 [RECEPTION] Fermetures, REF et gestion retours
  **Action** : Enrichi `limagrain/01-inbound/reception-fournisseur.md` (description déjà intégrée le 12/05) depuis la relecture des commentaires (revue de code validée 02/06, statut préprod/test client) : nouvelle section « Éléments techniques » (WF définitifs `InboundOrder_AutoCloseInboundOrder_PR_V2`, `Container_MovedEventHandler_Warehouse_PR`, `ReceiptLine_AutoClose_PR_V2` désactivé, `Reception_CheckReceiveMore_UI` non bloquant, `Reception_CheckIfAllReceptionLinesAreCompleted_PR`, `InboundOrder_UpdateStatus_By_Reception_ChangedStatus_PR_V2`, `WorkStation_Reception_Supplier_UI`, ressource `CST_View_RecOrder_ToleranceError`, GNA `REF01Observer.boo`) ; champ REF zone de stockage = `LneStockCstAtt01` ; source tolérance = ligne ROR ou profil article + contrôle bidirectionnel ; excédent non bloquant ; points revue de code (tests de nullité) ; RÉSOLUTION question WF clôture OE (V2 existant adapté, pas de nouveau WF) ; front matter sources/last_updated, Historique, Références. Enrichi `limagrain/01-inbound/reception-retour.md` : sous-section « Détection du mode retour » (`CST_Reception_GetReceptionFromContainer` returnMode, `Reception_Supplier_ChooseReception_UI`, `WorkStation_Reception_Supplier_ConfirmReceivedStock_UI`, ressource `CST_View_WaitForFullPutaway`), WF `Container_MovedEventHandler_Warehouse_PR` nommé pour CstAtt11 ; front matter/Historique/Références. Résolu la question WF clôture OE dans `08-transverse/questions-ouvertes.md`.
  **Cross-refs** : reception-retour.md (clôture retour, CstAtt11), ad-customs.md (CstAtt11/CstAtt01 réception/OE), LIM-66 (notifications PIE), LIM-76 (LOC)
  **Questions** : question WF clôture OE résolue ; reste ouvert : palette refusée PIE non supprimée (blocage clôture REF retour, @Justine)
 - **Fichier** : `Jira LIM-14` (lecture directe, 3 commentaires inclus)
  **Type** : Ticket Jira - Custom Attributes, Séquences, Jobs et Paramètres WMS (référentiel maître, statut En cours)
  **Action** : Réécrit `limagrain/07-admin/ad-customs.md` en catalogue CstAtt complet aligné sur LIM-14 : ajout entités Article (10), Stock (2), Ligne d'ordre d'inventaire (1), Stratégies de rangement (1), Status de stock (3), Tâche (4) ; Support étendu à 14 (RÉALIGNEMENT : ad-customs était désync — 12 = Conteneur étiqueté/LIM-71, 13 = Ordre d'entrée/LIM-96, 14 = Palette étiquetée au PK/LIM-91 ; l'ancienne réservation « 13 = Étiquetée au PK » était obsolète et déjà corrigée en 13 = Ordre d'entrée dans reception-fournisseur.md + glossaire) ; front matter (jira_refs, sources, last_updated), Historique, Références. Créé `limagrain/07-admin/parametres-projet.md` (page déjà liée dans README) : séquences (800/PAL), toggles, paramètres standards (IsSingleReceipt, AutoCloseReception), transactions customs (CON.CREATE.RECEP, LOC.SEND), paramètres customs (~20 dont FILMAGES, MODES_PK, PK_ADJACENT/BIGBAG, SAP_CPI/ATH214/ATH111, LOC_ZONE_MAPPING, EXPEDITION_CLASSE_*), jobs (5, avec WF et fréquences). Réconcilié : `_index.md` racine (résumé ad-customs, ajout entrée parametres-projet, compteur 41→42), `glossaire-limagrain.md` (CstAtt12 corrigé = Conteneur étiqueté, ajout CstAtt14, note LIM-96 sur CstAtt13), `08-transverse/questions-ouvertes.md` (PS association OE→CstAtt13, discordance AutoCloseReception), `01-inbound/reception-fournisseur.md` (caveat AutoCloseReception LIM-14=false).
  **Cross-refs** : parametres-projet.md ↔ ad-customs.md, reception-fournisseur.md (AutoCloseReception), reception-retour.md (CST_StockStatus), toutes tâches source (LIM-64/66/67/69/70/71/73/74/76/84/91/93/96/105/107)
  **Questions** : discordance AutoCloseReception (true LIM-73 vs false LIM-14) ; type CstAtt01 Ligne d'inventaire (Booléen en LIM-14 mais donnée = nombre) ; PK_BIGBAG dupliqué en LIM-14 (LIM-70 + LIM-74)
 - **Fichier** : `Jira LIM-74` (lecture directe, 2 commentaires inclus)
  **Type** : Ticket Jira - #LOT 1.3 [AGV][JOB] MINI JOB - images de quai > poste de travail (PK)
  **Action** : Enrichi `limagrain/05-agv/job-reception-pk.md` (description déjà intégrée le 12/05) depuis la relecture des commentaires (revue de code validée 07/04, statut préprod, commit 24067c85fc) : nouvelle section « Éléments techniques » (query `CST_Reception_BestPendingAssignment_ForPK`, WF `CST_PickingStationAssignment_Reception_PR` appelé par le Mega Job, `CST_PickingStationAssignment_Job` modifié pour PK_BIGBAG, vue `ContainerVList` +CustomAttribute6, ressource `CST_Container_CustomAttribute6` = PK Assigné/Assigned PK) ; front matter sources/last_updated, Historique, Références. La suppression du filtre CstAtt04 (production sans réception associée) était déjà reflétée.
  **Cross-refs** : job-assignation-pk.md (Mega Job LIM-70), reception-fournisseur.md (CstAtt06/08), ad-customs.md (CstAtt06), LIM-60 (sous-emplacement auto)
  **Questions** : aucune nouvelle ; AutoCloseReception confirmé true par Arthur (discordance LIM-14 résolue → à corriger côté ticket)
 - **Fichier** : `Jira LIM-75` (lecture directe, 1 commentaire inclus)
  **Type** : Ticket Jira - #LOT 1.2 [AGV][JOB] MINI JOB - PS > poste de travail (PK) - Annulé
  **Action** : Ticket confirmé **Annulé(e)**, explicitement repris par LIM-82 (« Annulée, suite ici »). Intégration légère (pattern V1/V2, pas de détail dupliqué) : `03-picking/job-assignation-pk.md` - table des sous-workflows annotée (LIM-75 annulé → LIM-82), jira_refs (+LIM-82), Historique, Références (LIM-75 Annulé + LIM-82 reprise). `03-picking/sequencage-tk-ps.md` - références MINI JOB LIM-75 (déclenchement TaskCreatedEvent + section picking négatif) annotées → LIM-82. `03-picking/stations-picking.md` - mention sous-WF annotée. Détail du Mini Job PS → PK différé à la relecture de LIM-82.
  **Cross-refs** : LIM-82 (reprise V2), job-assignation-pk.md (Mega Job LIM-70), sequencage-tk-ps.md (picking négatif)
  **Questions** : aucune ; détail PS → PK à relire sur LIM-82
 - **Fichier** : `Jira LIM-76` (lecture directe, 19 commentaires inclus)
  **Type** : Ticket Jira - #LOT 1.2 [GNA] Message LOC (statut : En revue de code, plusieurs livraisons préprod)
  **Action** : Enrichi `limagrain/06-erp-interface/loc-message-periodique.md` (spec déjà intégrée le 12/05) depuis la relecture des commentaires : nouvelle section « Implémentation GNA » (job `CST_SendLOCTransaction` 5 min → WF `CST_SendLOC` → transaction `LOC.SEND` ; scripts GNA CommonExportWebApi/EasyWMSExportMessages/EasyWMSWebApiObserver/LOC01/WriteLOC01/LOC01Observer.boo + LOC01.xsd ; paramètre LOC_ZONE_MAPPING ; motif NO_CHANGES + évolution « pas de transaction en erreur si rien à envoyer ») ; décision réception non fermée (modifs pré-REF non rejouées, point Nicolas 02/06 assumé par le client) ; sous-section picking négatif (CON.CREATE + STK.PICKING.NEG self + 2× CHB.LAB, problème de corrélation source↔destination, analyse en cours) ; retours revue de code/client (action S champs vides + doublons 08/07, détail stocks S, WF02 hardcodé, BuildZoneMapping inutilisée, null ref B6, cache) ; questions ouvertes (picking négatif, action S) ; front matter sources/last_updated, Historique, Références. Job LOC déjà présent dans parametres-projet.md (LIM-14).
  **Cross-refs** : parametres-projet.md (job CST_SendLOCTransaction, LOC_ZONE_MAPPING), reception-fournisseur.md (filtre réception non fermée / REF), sequencage-tk-ps.md (picking négatif), gna-sap-cpi.md (POST API SAP)
  **Questions** : picking négatif (corrélation source/destination) ; action S (détail stocks + doublons) ; re-revue de code à faire (statut ticket non validé)
 - **Fichier** : `Jira LIM-80` (lecture directe, 6 commentaires inclus)
  **Type** : Ticket Jira - #LOT 2.1 [Mini Job] Assignation des OS aux PK (statut : en cours de test client / préprod)
  **Action** : Refonte de la section « Mini Job - Assignation commandes aux PK (LIM-80) » dans `limagrain/03-picking/job-assignation-pk.md` depuis la relecture des commentaires (revue de code validée 26/06/2026) : suppression de la logique Messagerie `PK_TRANSPORTEUR_MESSAGERIE` et du tri par tournée/numéro d'arrêt (spec initiale superseded) ; ajout statut préprod ; éligibilité PK déléguée au Mega Job (renvoi) ; OS concernés (Release + stock/picking, hors `OutboundClassCode == RECERTIFICATION`) ; PK déjà choisi par le Mega Job (pas de recalcul routage) ; nouvelle section critères de tri (arbitrage Justine 19/06 : priorité OS → tâches de shipping → date de libération, avec note sur le premier jet 05/06 priorité → nb conteneurs → date) ; note priorité Messagerie gérée par SAP via SOR (pas de custom, param abandonné) ; section Création des tâches de picking (→ LIM-84) ; section Éléments AD (WF `CST_PickingStationAssignment_Picking_PR`, query `CST_OutboundOrder_BestPendingAssignment_ForPK`, note enrichissement `CST_PickingStationAssignment_Job`) ; section 8 subscriptions désactivées ; MAJ point d'attention Messagerie ; front matter last_updated, Historique, Références (6 commentaires, préprod). Ajout question priorité Messagerie SAP/SOR dans `08-transverse/questions-ouvertes.md` (section Picking + Historique) et sur la page.
  **Cross-refs** : job-assignation-pk.md (Mega Job LIM-70, éligibilité PK), LIM-84 (séquençage TK → PS, tâches de picking), LIM-82 (Mini Job PS → PK), questions-ouvertes.md (Messagerie SAP)
  **Questions** : confirmer côté client que SAP gère la priorité des Messagerie dans le SOR (abandon `PK_TRANSPORTEUR_MESSAGERIE`) → reportée dans questions-ouvertes.md
 - **Fichier** : `Jira LIM-82` (lecture directe, 5 commentaires inclus)
  **Type** : Ticket Jira - #LOT 2.2 [PICKING] Ordonnancement des tâches de picking PS > PK (statut : Attente déploiement pour test / préprod, reprise de LIM-75 annulé)
  **Action** : Enrichi `limagrain/03-picking/placement-ps-pk.md` (algorithme V1.0 déjà intégré le 12/05) depuis la relecture des commentaires (livré préprod 25/06, revue de code validée 03/07 après itération NOK 02/07) : ajout note statut + positionnement chaîne (LIM-80 → LIM-84 → LIM-82 → LIM-91) ; nouvelle section « Implémentation définitive (LIM-82) » (record TaskWF +CstAtt3 ; WF `CST_ChooseDestinationFromPS`, `Container_MovedEventHandler_PS_PR` déclencheur, `Container_MovedEventHandler_ET_PR` + `_MS_PR` gating shuttle CstAtt3=True après navette/TS_12 ; job `CST_Job_CheckPSBufferContainers` ; queries `CST_Picking_GetSiblingTasks`, `CST_GetTasksWaitingOnPSAndBufffer`, `CST_GetStationRoutes_ToDisable`) ; gate de séquence critère B (sibling tasks du même OS avec Line.CstAtt inférieur → buffer, correction revue de code route→OS pour éviter faux blocage 2 OS/route sur 2 PK) ; écarts V1.0 (abandon états `EN_ATTENTE_EVACUATION` + réactivation PF ; critères négatif C / direct D ; SEUIL_RECENTRAGE_PF + CONTROLE_TRAITEMENT_COMMERCIAL à confirmer) ; front matter (jira_refs +LIM-84/91, sources, last_updated), Historique, Références (LIM-82/84/75/91). Ajout attribution LIM-82 sur CstAtt Tâche 03 dans `07-admin/ad-customs.md` (front matter jira_refs, Historique, Références). Ajout 2 questions LIM-82 dans `08-transverse/questions-ouvertes.md` (big-bag sans PK dispo, mécanismes V1.0 + TaskType LIM-75).
  **Cross-refs** : placement-ps-pk.md ↔ sequencage-tk-ps.md (Line.CstAtt LIM-84), ad-customs.md (CstAtt Tâche 03 navette), job-assignation-pk.md (LIM-80 assignation), LIM-91 (opérateur PK), LIM-75 (Annulé → LIM-82)
  **Questions** : big-bag sans PK PK_BIGBAG disponible ; SEUIL_RECENTRAGE_PF / CONTROLE_TRAITEMENT_COMMERCIAL réellement implémentés ? ; où est écrit le TaskType picking négatif (LIM-75 annulé) → reportées dans questions-ouvertes.md
 - **Fichier** : `Jira LIM-84` (lecture directe, 5 commentaires inclus)
  **Type** : Ticket Jira - #LOT 2.2 [PICKING] Séquençage des tâches de picking TK > PS (statut : Attente déploiement pour test / préprod)
  **Action** : Enrichi `limagrain/03-picking/sequencage-tk-ps.md` (algo V1.1 déjà intégré le 12/05) depuis la relecture des commentaires (revue de code validée 02/07, après NOK 29/06 + corrections 01/07) : ajout note statut ; refonte section « Déclenchement » (implémentation réelle = séquençage pendant l'assignation de stock via `Outbound_StockAssignProcess_PR` / `OutboundOrder_StockReassign_PR` + subscription `CST_PKAssigned_ReleaseOrder` → `CST_OutboundOrder_PKAssigned_ReleaseOrder_PR`, par job ; remplace le TaskCreatedEvent de la note de conception) ; MAJ conditions picking négatif (mono-lot, autorisé même avec attributs logistiques, poids ≥ 7 kg custom, 2 checks % standard) + ajout param NegativeMinCompletePercent 25% ; nouvelle section « Implémentation définitive » (WF `CST_PickingTasksSequencing_PR` = constitution palettes finales + numéro de séquence ; records `CST_PickingPalletList`/`CST_PickingStockList` ; queries `CST_PickingStocksToSequence_ByOutboundOrder` / `CST_Tasks_ForView` / `CST_Tasks_PendingOutboundForStackerCrane` ; vue `TaskVList` +CstAtt1 ; points confirmés recalcul / repart de 0 / inter-OS interdit) ; front matter (jira_refs +LIM-80/82, sources, last_updated), Historique, Références. CstAtt Tâche 01 (séquence) et OS (verrou) déjà présents dans ad-customs.md.
  **Cross-refs** : sequencage-tk-ps.md ↔ placement-ps-pk.md (Line.CstAtt consommé LIM-82), job-assignation-pk.md (LIM-80 release/assign OS), ad-customs.md (CstAtt Tâche 01 séquence + OS verrou), sequencage-tk-ps-historique.md (solutions envisagées)
  **Questions** : aucune nouvelle (questions description résolues dans le ticket : recalcul partiel confirmé, concurrence inter-OS interdite, timeout verrou négligeable, base % négatif confirmée 20/05)
 - **Fichier** : `Jira LIM-85` (lecture directe, 1 commentaire inclus)
  **Type** : Ticket Jira - #LOT 2.1 Configuration stratégies défragmentation du stock client par tournée (statut : En cours de test client / préprod)
  **Action** : Ticket léger (suivi de config, description minimale : « mettre en place ces stratégies » suite atelier 02/04 ; commentaire « Stratégie importée sur Git » 23/04/2026). Enrichi `limagrain/02-stockage/defragmentation.md` (déjà rattachée à LIM-85/LIM-87) : ajout section « [CONFIG] Stratégies de défragmentation client par tournée (LIM-85) » distinguant la configuration des stratégies (mode Shipping / type d'ordre Tournée, zone client TK02-04 rangées 60-69) du custom d'éligibilité par tournée (LIM-87) ; note statut préprod + import Git 23/04 ; front matter last_updated, Historique, Références.
  **Cross-refs** : defragmentation.md (LIM-87 custom quai non assigné), sequencage-shipping-stop.md (quai assigné), flux-expedition.md (étape 4 défrag)
  **Questions** : aucune nouvelle
 - **Fichier** : `Jira LIM-87` (lecture directe, 5 commentaires inclus)
  **Type** : Ticket Jira - #LOT 2.1 [TOURNÉES] Défragmentation client - quai non assigné #ATTENTE_CLIENT (CT-13) (statut : En cours de test client / préprod)
  **Action** : Enrichi `limagrain/02-stockage/defragmentation.md` (custom + 16 cas de tests déjà intégrés le 12/05) depuis la relecture des commentaires (revue de code validée 28/04, après NOK 24/04 + correction 27/04) : ajout note statut sur la section [CUSTOM] LIM-87 ; ajout de la query définitive `OutboundDefragContainers_PendingByWarehouseExcludedIds` (standard modifiée : ne retient un conteneur que si sa tournée/OS n'a plus de picking en cours ; exclut conteneurs de picking restants + conteneurs pas encore rangés `LocationType != Aps` ; bug de nommage paramètre `c` Any/Where corrigé 27/04) ; RÉSOLUTION MAX_DEFRAG_ATTEMPT (uniquement défrag par rotation, pas expédition/client) dans la section dédiée + question page + question centrale ; CT-13 précisé (commande incomplète → pas de défrag, proche option A, arbitrage client à confirmer) ; Historique, Références. Résolu la question MAX_DEFRAG_ATTEMPT dans `08-transverse/questions-ouvertes.md` (+ annotation CT-13 + Historique).
  **Cross-refs** : defragmentation.md (LIM-85 config, sequencage-shipping-stop.md quai assigné LIM-88), questions-ouvertes.md (MAX_DEFRAG résolu, CT-13), flux-expedition.md (étape 4 défrag)
  **Questions** : CT-13 rupture (option A/B) reste ouverte côté client (@Justine) ; MAX_DEFRAG_ATTEMPT résolu
 - **Fichier** : `Jira LIM-88` (lecture directe, 5 commentaires inclus)
  **Type** : Ticket Jira - #LOT 2.1 [TOURNÉES] Séquençage des tâches de shipping par STOP - quai assigné (statut : En cours de test client / préprod)
  **Action** : Enrichi `limagrain/04-outbound/sequencage-shipping-stop.md` (description déjà intégrée le 12/05) depuis la relecture des commentaires (revue de code validée 02/06) : nouvelle section « Implémentation définitive » (query `CST_Tasks_PendingOutboundForStackerCrane` = clone de `Tasks_PendingOutboundForStackerCrane`, filtre tâches shipping + conteneurs picking/shipping/client d'un STOP supérieur, contrôle station DockStage ; WF `StackerCrane_GetOutboundPendingTasks_PR` utilise la query custom + log ; WF `Outbound_CreateShippingOrLoadTasksToDockOrStage_PR` empêche la création de tâche de chargement sans stage associé à l'OS, sinon blocage AGV aux PS, commit `0aec1c3b` ; règle de filtrage = seules les sorties d'expédition sont bloquées, les sorties picking restent autorisées pour le prélèvement anticipé) ; statut préprod ; CT-13 résolu (quai non modifiable après libération RUT) dans le tableau, Points d'attention et Questions ouvertes de la page ; front matter (status review, sources, last_updated), Historique, Références. Résolu la question CT-13 dans `08-transverse/questions-ouvertes.md` (+ Historique).
  **Cross-refs** : defragmentation.md (LIM-87 quai non assigné, cas complémentaire), sequencage-tk-ps.md (query `CST_Tasks_PendingOutboundForStackerCrane` partagée LIM-84), flux-expedition.md (étape shipping), questions-ouvertes.md (CT-13 résolu)
  **Questions** : CT-13 résolu ; reste ouvert : retour PF vers ASRS (CT-08) à confirmer en recette (@Nicolas)
 - **Fichier** : `Jira LIM-89` (lecture directe, 3 commentaires inclus)
  **Type** : Ticket Jira - #LOT 1.1 [GNA] Mise en place de la communication API EasyWMS > SAP CPI (statut : En cours de test client / préprod)
  **Action** : Enrichi `limagrain/06-erp-interface/gna-sap-cpi.md` (déjà intégré le 12-13/05) depuis la relecture des commentaires (revue de code validée 21/05) : ajout structure du script `CommonExportWebApi.boo` (`CheckConnection()` auth retry 4×, `SendWebApiMessage` retry 5×, `CpiTokenResponse`, `CpiTokenCache`, templates Mecalux inchangés) ; distinction retry auth (4 tentatives 2/4/8s) vs envoi (5 tentatives 2/4/8/16s) ; **CORRECTION du sens de mapping REF** : `REF Retour → ATH215`, `REF Supplier → ATH217`, `ROF → ATH217` (la page inversait 215/217 ; corrigé dans les 2 tables + cartographie + cas de tests, aligné sur la table intégrateur ERP + implémentation) ; type REF résolu via `ReceiptCode` (query `Context.Receptions`) dans `CommonExportWebApi.boo` — REVERSAL de l'approche `REF01Observer`/`CstAtt20` (non retenue, fichier retiré des impacts) ; secret OAuth **chiffré via `PasswordEncrypt.exe`** (corrige « en clair » ; question résolue) ; statut review ; front matter, Historique, Références. Propagé la correction 215/217 dans `glossaire-limagrain.md` (MessageSAP + ATH215/ATH217). Résolu la question secret OAuth dans `08-transverse/questions-ouvertes.md` (+ file d'attente 4→5 retries, Historique).
  **Cross-refs** : reception-retour.md (ATH214 flux retour, inchangé), loc-message-periodique.md (LOC→ATH201), messages-reference.md (REF/ROF/LOF), glossaire-limagrain.md (codes ATH), questions-ouvertes.md (secret résolu)
  **Questions** : file d'attente persistante après 5 retries (@Nicolas) reste ouverte ; **à re-vérifier côté doc Tourrette** : le sens 215/217 corrigé contredit la version antérieure de la page (caveat posé)
 - **Fichier** : `Jira LIM-90` (lecture directe, 5 commentaires inclus)
  **Type** : Ticket Jira - #LOT 1.3 [REF] Statuts de stock retour client - ZLOG/ZINCO et lot officiel (statut : En cours de test client / préprod)
  **Action** : Ajout section « Statuts de stock retour et remontée REF (LIM-90) » dans `limagrain/01-inbound/reception-retour.md` depuis la relecture des commentaires (revue de code terminée 03/06 après NOK 02/06 = commentaires `// Custom` manquants) : catalogue des 8 statuts master data (F9 + 7 motifs B6, ZLOG/ZINCO, blocage picking/shipping à confirmer client), F2 = absence de statut (SAP → ZLOG 0002/ZINCO 0001), balises REF `LneStockStatus`/`LneStockZLOG`/`LneStockZINCO`/`LneStockOfficialLot` (alias article = lot officiel), implémentation GNA `REF01.boo` (header) + `REF01Observer.boo` (alias + CstAtt statut si type retour) + `REF01.xsd`, réutilise la détermination retour/fournisseur de LIM-89 ; cross-ref depuis la sous-section « Statut de stock - Modifiable » ; front matter (jira_refs +LIM-90, sources, last_updated), Historique, Références. Enrichi `07-admin/ad-customs.md` (renvoi catalogue LIM-90 sous la table CstAtt Status de stock). **Correction** `06-erp-interface/mapping-erp-wms.md` : STC désactivé → statuts retour remontés via REF (ZLOG/ZINCO), phrase + diagramme Mermaid corrigés, front matter/Historique/Références, 2 questions statuts résolues. `glossaire-limagrain.md` : ajout F2, enrichissement F9/B6 (codes ZLOG/ZINCO), ajout ZLOG et ZINCO. Résolu 2 questions statuts de stock dans `08-transverse/questions-ouvertes.md`.
  **Cross-refs** : reception-retour.md ↔ ad-customs.md (CST_StockStatus CstAtt2/3), reception-retour.md → gna-sap-cpi.md (LIM-89 type retour), mapping-erp-wms.md (STC désactivé → REF), loc-message-periodique.md (B6 hors retour via LOC), glossaire-limagrain.md (F2/F9/B6/ZLOG/ZINCO)
  **Questions** : blocages picking/shipping par statut à confirmer avec le client (@Justine) ; 2 questions « liste statuts / commentaires » résolues
 - **Fichier** : `Jira LIM-91` (lecture directe, 7 commentaires inclus)
  **Type** : Ticket Jira - #LOT 2.2 [PICKING] Process de picking sur le poste de travail PK (statut : **En revue de code**, assignée Maxime Halgand)
  **Action** : **Nouvelle page** `limagrain/03-picking/process-picking-pk.md` (dernière étape de la chaîne picking LIM-80→84→82→91). Contenu depuis la description + technical implementation (Maxime 16/07) + revue de code (Vincent 17/07) : architecture poste (3 tables/adjacence, big-bags hors PK, mode tâches auto), picking direct, picking négatif (table centre, SSCC excédent, conditions ≥7kg + % évaluées en amont LIM-75), verrou HORS TOLERANCE + recomptage (`CST_Count_Picking_UI`), étiquetage MII (SSCC virtuel sur Stock CstAtt2, intercalaires sans RFID + HU mère RFID, flag CstAtt14, réutilise rapports LIM-68), filmage CstAtt05 → Galileo (toujours proposé), évacuation/retour ASRS direct + LOC ACTION=P/T, cas 100 % → tâche de shipping (décision Vincent 02/07 + solution « Expédier uniquement conteneur complet »), modes AGV/Mixte/TRF ; section Implémentation (WF/dialogs/vues/ressources) ; corrections revue de code 17/07 en attente (double impression `CST_PrintLabel`, boucle SSCC vide, CustomAttribute1 non mappé/poids, écrans picking négatif) ; optim Justine 16/07 (écran filmage vs stockage support, PIE02 pour palette client) ; décisions CstAtt13→CstAtt14 (01/07), MOV annulé. Réconcilié : `_index.md` racine (ajout entrée, compteur 42→43), `README.md` (section picking), `03-picking/placement-ps-pk.md` (lien chaîne vers la page locale), `07-admin/ad-customs.md` (renvoi CstAtt14 → page), `08-transverse/questions-ouvertes.md` (3 questions LIM-91 + Historique).
  **Cross-refs** : placement-ps-pk.md / sequencage-tk-ps.md / job-assignation-pk.md (chaîne), ad-customs.md (CstAtt14 support + CstAtt2 stock SSCC MII), loc-message-periodique.md (ACTION=P/T), etiquette-rfid.md (LIM-68 rapports), controle-qualite-reception.md (verrou HORS TOLERANCE LIM-66)
  **Questions** : ticket **en revue de code** (corrections en attente) ; ouvertes : choix poumon messagerie, ergonomie recomptage, format étiquette intercalaire → questions-ouvertes.md
 - **Fichier** : `Jira LIM-92` (lecture directe, 7 commentaires inclus)
  **Type** : Ticket Jira - #LOT 2.2 [RESSOURCES] Renommage code article et attributs logistiques (statut : Attente déploiement pour test)
  **Action** : Ajout section « Renommage des ressources EasyWMS (LIM-92) » dans `limagrain/06-erp-interface/donnees-principales.md` (qui documentait déjà le détournement des champs standard) : table des ressources renommées (Shared_Product = Code lot SAP, Shared_Lote = Code produit SAP, Shared_Colour = Propriétaire SAP, Shared_Source = Description courte SAP, Shared_Size = Pays destination, Prop_Product_ProductFamilyCode = Traitement commercial, Menu_ItemFamilies = Traitements commerciaux, Articulos/Menu_Items = Lots SAP) ; ressources complémentaires Shared_Calibre (Pays destination, retour 04/06), Shared_Códigodelote (Code produit SAP, retour 30/06), 4 messages `StockAssign_TraceStockDoesNotMeet*` (Colour/LotCode/Size/Source) avec caveat « poussés par erreur sur branche LOT2.2 » ; mise à jour du caveat balises API (renvoi section) ; front matter (jira_refs, sources, last_updated), Historique, Références. Ajout terme « Traitement commercial (TC) » dans `glossaire-limagrain.md`.
  **Cross-refs** : donnees-principales.md (mapping ITM Family = Traitement commercial, attributs logistiques Lot/Color/Source/Size), glossaire-limagrain.md (Traitement commercial)
  **Questions** : aucune nouvelle (ticket de renommage) ; caveat branche LOT2.2 à surveiller au déploiement
 - **Fichier** : `Jira LIM-93` (lecture directe, 15 commentaires inclus)
  **Type** : Ticket Jira - #LOT 1.3 [RETOUR] Flux PK Complet V2 (statut : En cours de test client / préprod, revue de code en cours)
  **Action** : Intégration du détail définitif V2 dans `limagrain/01-inbound/reception-retour.md` (reprise de LIM-72 V1 annulé, notes de supersession déjà posées) depuis la description V2 + les 15 commentaires (implémentation Vincent Charvet, revues de code Maxime Halgand) : note de supersession réécrite (V2 intégrée, différences majeures listées) ; appel ATH214 rendu **systématique** (intro + flowchart Mermaid refaits, filtre ZDEPLOY, plus de branche « lot connu ») ; payload réponse enrichi (`DESCRIPTION`/`DESTINATION`/`OWNER`/`ZDEPLOY`/`VAR_DESC`/`COM_TRT_DESC`, traitement en 4 étapes) ; caveat EV_DEPLOY/ZDEPLOY retiré (ZDEPLOY confirmé) ; dialogue multi-lot reformaté (`VAR_DESC - COM_TRT_DESC - DESTINATION (MATNR)`) ; table déclaration PK renumérotée (statut de stock en **étape dédiée avant la quantité**, RFID enrichie) ; nouvelles sous-sections « Statut de stock modifiable en étape dédiée » (statut fictif « Stock conforme » / `RECEPTION_CONFORM_STOCK_STATUS`, bouton statut retiré, ESC), « Attributs logistiques auto-validation », « Étiquette RFID enrichie » (A5 Zebra, impact LIM-68) ; section PIE : verrou renommé **« ECART RETOUR »**, rejet PIE = **renvoi au PK pour recomptage** (placeholder, poumon abandonné) ; remplacement de « État du développement LIM-72 » par section **« Éléments techniques (LIM-93, revue de code) »** (WF/dialogs/records/toggles statut de stock + API ATH214, commits, caveat boucle infinie `LogManager.GetLogger` hors try/catch signalé 16-17/07) ; Points d'attention (params V1 `SAP_LOT_VERIFY_*` → `SAP_CPI_*`/`SAP_ATH214_*`, A4 fermé) ; front matter sources, Historique, Références (LIM-93 + commits). Réconcilié : `07-admin/parametres-projet.md` (ajout `RECEPTION_CONFORM_STOCK_STATUS`), `glossaire-limagrain.md` (ET_BATCH enrichi, EV_DEPLOY→ZDEPLOY, ajout VAR_DESC/COM_TRT_DESC/RECEPTION_CONFORM_STOCK_STATUS, SAP_LOT_VERIFY_URL marqué obsolète), `08-transverse/questions-ouvertes.md` (A1/A2/A3/A4/B1 résolues, B2 mise à jour = renvoi PK à définir).
  **Cross-refs** : reception-retour.md ↔ parametres-projet.md (SAP_ATH214_*/RECEPTION_CONFORM_STOCK_STATUS), gna-sap-cpi.md (OAuth CPI/ATH214), etiquette-rfid.md (LIM-68 enrichie A5), ad-customs.md (CST_StockStatus), job-reception-pk.md (étape 3, déjà annotée LIM-93), questions-ouvertes.md (A1-B2)
  **Questions** : B2 rejet PIE = renvoi au PK pour recomptage (solution technique à définir : routage AGV PIE→PK, relance workflow, levée verrou ECART RETOUR, impact clôture) ; caveat revue de code ATH214 (boucle infinie si LogManager lève hors try/catch) à corriger avant validation
 - **Fichier** : `Jira LIM-94` (lecture directe, 7 commentaires inclus)
  **Type** : Ticket Jira - #LOT 2.1 [JOB][EXPEDITION] Assignation automatique de l'image de quai OS/Tournée (statut : En cours de test client / préprod)
  **Action** : **Nouvelle page** `limagrain/04-outbound/assignation-image-quai.md` depuis la description + les 7 commentaires (implémentation Vincent Charvet, revue de code Maxime Halgand) : stages virtuels `X_EXP` (A_EXP/B_EXP..., capacité 26 / 1 emplacement, seul type assignable OS/Route, image de quai = seule ayant une route vers le stage) ; job `CST_AssignDockStage` → WF `CST_Job_AssignStage` (30 s), récupère OS (hors route) + Routes, exclut Recertification, priorise priorité puis date de libération, boucle d'assignation ; conditions d'éligibilité OS/Route (libéré, palettes picking revenues TK, H-3 date d'expédition prévue - correction 05/06 date d'expédition et non chargement, picking terminé = pas de conteneur picking + client en APS) ; conditions d'assignabilité stage (query `CST_DockStage_GetAvailableStageToAssign` : stage virtuel non verrouillé/sans tâche/sans conteneur/sans autre OS-Route-réception + image de quai physique non verrouillée/sans conteneur/sans tâche) ; génération mouvements PS (`Container_MovedEventHandler_PS_PR` : destination = 1er emplacement libre X max de l'image de quai) ; désassignation à l'arrêt OS/Route (`CST_OutboundOrderUnassignStage_PR`/`CST_RouteUnassignStage_PR` + souscriptions async `CST_OutboundOrderStopped_UnassignStage`/`CST_RouteStopped_UnassignStage`, motif = éviter réservation caduque) ; VAssist restreintes (`VAssistOutboundOrderAssignDock`/`VAssistRouteAssignDock`) ; section Éléments techniques + commits `f0536cce0c`/`e3889b8003`/`5de1618104` ; front matter, Historique, Références. Réconcilié : `_index.md` racine (nouvelle entrée, compteur **43→44**), `README.md` + `04-outbound/_index.md` (ajout page), `07-admin/parametres-projet.md` (job `CST_AssignDockStage` rattaché LIM-94), `04-outbound/consolidation-chargement.md` (renvois assignation auto + placement PS X max, front matter jira_refs/last_updated/Historique), `04-outbound/sequencage-shipping-stop.md` (cross-ref LIM-94 = stage dont dépend le garde-fou de chargement, jira_refs, Historique), `glossaire-limagrain.md` (Stage virtuel X_EXP, CST_AssignDockStage), `08-transverse/questions-ouvertes.md` (question TBD réception assignée).
  **Cross-refs** : sequencage-shipping-stop.md (LIM-88 garde-fou `Outbound_CreateShippingOrLoadTasksToDockOrStage_PR`), consolidation-chargement.md (assignation manuelle automatisée + dépose AGV), parametres-projet.md (job), glossaire-limagrain.md (X_EXP)
  **Questions** : condition « image de quai sans réception assignée » marquée TBD dans la description → reportée dans questions-ouvertes.md (@Justine)
 - **Fichier** : `Jira LIM-95` (lecture directe, 2 commentaires inclus)
  **Type** : Ticket Jira - #LOT 2.1 [JOB] génération des mouvements depuis les buffers (statut : **Annulé(e)**)
  **Action** : Ticket confirmé **Annulé(e)**, modifications mergées dans LIM-82 (commentaire Maxime Halgand 26/06 ; Arthur suggérait garder ou merger avec LIM-84). Intégration légère (pattern V1/V2, pas de duplication) dans `limagrain/03-picking/placement-ps-pk.md` (page LIM-82) : note de supersession dans le bloc chaîne (LIM-95 Annulé → mergé LIM-82) ; rattachement des 2 demandes du ticket : (1) « ne pas générer le mouvement si une autre tâche de l'OS a une séquence `Task.CstAtt01` plus faible » = déjà couvert par la **Gate de séquence (critère B)** (`CST_Picking_GetSiblingTasks`, `Line.CstAtt`=`Task.CstAtt01`) - note ajoutée ; (2) **capacité TP** à contrôler en plus du PK, sans capteurs de présence Galileo - note [CUSTOM] ajoutée sous « Décision niveau 1 » ; jira_refs (+LIM-95), sources, Historique, Références (LIM-95 Annulé → mergé LIM-82). Pas de nouvelle page.
  **Cross-refs** : placement-ps-pk.md (Gate de séquence LIM-84/LIM-82, capacité TP), ad-customs.md (CstAtt Tâche 01 = séquence picking), sequencage-tk-ps.md (Line.CstAtt)
  **Questions** : aucune nouvelle (ticket Annulé, contenu déjà couvert par LIM-82)
 - **Fichier** : `Jira LIM-96` (lecture directe, 6 commentaires inclus)
  **Type** : Ticket Jira - #LOT 1.1 [RECEPTION] TRF Déclaration image de quai V2 (Amélioration, statut : En cours de test client / préprod, revue de code validée 25/06)
  **Action** : Intégration V2 (reprise de LIM-64 V1 annulé) dans `limagrain/01-inbound/gestion-camions.md` (étape 4, page propriétaire de la déclaration image de quai) depuis la description + 6 commentaires (implémentation Maxime Halgand / Vincent Charvet) : statut étape 4 réécrit (V1→V2 préprod) ; **sélection de l'image de quai déplacée côté SmartUI** (routes dock→stage virtuel au layout, dialogues `CST_DockStageReception_SelectStage`/`ConfirmStage`, vue `VAssistReceptionAssignDock` ; Production/Pile = choix direct image de quai, Arthur 17/06) ; workflow d'écrans V2 (image de quai d'abord, puis nombre, puis sous-emplacement) ; **nouvel écran Déclaration des OE** (scan/sélection des emplacements par OE, compteur + bouton Ordre suivant, vérif conteneur/réception/doublon → pose `CstAtt13` dès l'image de quai) ; **nouvel écran Validation collage étiquettes** (`CST_Reception_DockStage_ConfirmLabels` + réimpression → `CstAtt12=true` sur toutes les palettes, gate du job AGV LIM-71) ; table attributs support (+CstAtt12/CstAtt13, ContainerVList CstAtt 1/4/8/13) ; table AD V2 (query `CST_DockStageStations_WithoutOutbound` supprimée → renommée `CST_DockStageStations_WithoutAssignation` + conditions ; clone `CST_Receptions_PendingAndReceiving_WithDockStageAssigned` ; WF `CST_Reception_DockStage_PrintLabels` ; ressources i18n ; commit `1b2570b164`) ; distinction big-bag CstAtt01 (réception) vs CstAtt02 (support) confirmée ; front matter sources/last_updated, Historique, Références. Réconcilié : `07-admin/ad-customs.md` (notes CstAtt13 = posé dès l'image de quai ; CstAtt12 = gate job LIM-71 + caveat, Historique), `glossaire-limagrain.md` (CstAtt12/CstAtt13 mis à jour), `08-transverse/questions-ouvertes.md` (question PS OE dès l'image de quai **résolue** + nouvelle question CstAtt12/LIM-71 à réconcilier). Pas de nouvelle page.
  **Cross-refs** : gestion-camions.md (LIM-64/65/96), ad-customs.md (CstAtt12/13), reception-fournisseur.md (déclaration image de quai résumé), job-reception-production.md (LIM-71 gate CstAtt12), etiquette LIM-65, LIM-14 (séquence 800)
  **Questions** : **caveat CstAtt12** — LIM-96 pose CstAtt12=true comme gate LIM-71 alors que la page LIM-71 indiquait la condition retirée → à réconcilier (@Vincent/@Maxime) ; question PS (OE dès l'image de quai) résolue
 ## [2026-07-20] session-022 (mode: limagrain)
 > Source : lecture directe des tickets Jira LOT (pas de fichier déposé dans `sources/`).
 - **Fichier** : `Jira LIM-97` (lecture directe, 2 commentaires inclus)
  **Type** : Ticket Jira - #LOT 1.1 [RECEPTION] Gestion camions V2 (Amélioration, statut : En cours de test client / préprod, validé Vincent Charvet 02/07)
  **Action** : Intégration du détail définitif V2 (reprise de LIM-62 V1 annulé, notes de supersession déjà posées étapes 1-2) dans `limagrain/01-inbound/gestion-camions.md` : étape 2 réécrite en « Assignation du quai ET de l'image de quai » avec le **mécanisme faux stage / vrai stage** (faux stages A à K = stations fictives sélectionnables comme unité, une par image de quai ; vrai stage = poumon physique 26 emplacements avec route vers quai d'expédition ; motif : pas de commande standard pour assigner une station en Stage, sinon 286 sous-emplacements affichés) ; effet de bord routage faux stage→emplacement vrai stage→quai d'expédition (custom fin d'ordre PS) ; note de supersession réécrite (V2 intégrée, statut préprod) ; ajout vue `VAssistCreateReceptionOEFromReceptions` (contrôle classes OE) + ressource `CST_ViewField_VAssistantCreateReceptionOE_Truck` + Élément AD faux stages A-K ; libellé `CST_Prop_Station_Workload` corrigé (Réceptions / Camions + caveat divergence §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, Historique, Références (statut préprod, commit `1d2acc3e6e`). Réconcilié : `glossaire-limagrain.md` (ajout Faux stage A-K + Vrai stage, last_updated), `08-transverse/questions-ouvertes.md` (2 questions LIM-97 + annotation plaque §8.5 + Historique + sources).
  **Cross-refs** : gestion-camions.md ↔ assignation-image-quai.md (LIM-94 stages X_EXP expédition), sequencage-shipping-stop.md (LIM-88 STOP), glossaire-limagrain.md (faux/vrai stage), questions-ouvertes.md (routage, débordement)
  **Questions** : routage faux stage→vrai stage→quai d'expédition (§8.1, custom fin d'ordre PS, cadencement AGV Still) ; débordement 27e palette (§8.2, @Justine) ; ordonnancement dépose AGV image de quai (§8.3, réunion Still, déjà tracé côté Expédition)
 - **Fichier** : `Jira LIM-102` (lecture directe, 2 commentaires inclus)
  **Type** : Ticket Jira - #LOT 1.1 [RECEPTION] KPI Nombre de conteneur par type de réception (Tâche, statut : En cours de test client / préprod, revue de code validée 03/06)
  **Action** : Intégration KPI dans `limagrain/01-inbound/gestion-camions.md` (page propriétaire de la déclaration image de quai, où les conteneurs sont créés) : nouvelle sous-section « KPI - conteneurs par type de réception (LIM-102) » (transaction `CON.CREATE.RECEP` créée à chaque conteneur du process de réception LIM-96 ; table des champs TransactionTypeCode/LocationCode/ContainerCode/`Document1`/IdOrig ; `Document1` = type de réception : PALETTE BOIS / PRODUCTION / `InboundClassCode` pour type AUTRES) ; enrichissement des 2 WF dans la table AD (`CST_Reception_DockStage_UI` récupère l'InboundClassCode, `CST_Reception_DockStage_CreateContainers_PR` crée la transaction) ; front matter jira_refs +LIM-102, Historique, Références (commit `5a7d213d48`). Réconcilié : `07-admin/parametres-projet.md` (enrichissement ligne transaction `CON.CREATE.RECEP` avec Document1 = type de réception + cross-ref, jira_refs/sources/last_updated, Historique, Références).
  **Cross-refs** : gestion-camions.md ↔ parametres-projet.md (transaction CON.CREATE.RECEP), LIM-96 (création conteneurs déclaration image de quai)
  **Questions** : aucune nouvelle (ticket KPI, revue de code validée)
 - **Fichier** : `Jira LIM-103` (lecture directe, 7 commentaires inclus)
  **Type** : Ticket Jira - #LOT 3 [AGV] Corrections bugs standard du module AGV (Tâche, statut : En cours de test client / préprod, revue de code à faire, assignée Vincent Charvet)
  **Action** : Intégration dans `limagrain/05-agv/still-igo-integration.md` (page maître intégration AGV/iGO) : nouvelle section « Corrections des bugs du module AGV standard (LIM-103) » depuis les 7 commentaires (Vincent Charvet / Arthur / Michael Chaudier) - 2 queries standard corrigées (`Equipment_AgvTask_GetTask_ByWorkingZone_UI` null exception, `Equipment_AgvTask_LoadEquipment_UI` paramètre erroné) ; **dispatch d'events cassé** par la transformation Gateway `EventType = phase + 100` (ex 104→204 ≠ natif → silent fail dans `ProcessEvents_PR`, fix = patch -100 dans « Check parameters ») ; **bug majeur `canPick`/`canDrop` jamais assignés** dans `ProcessEvent_LoadPermission_PR`/`ProcessEvent_UnloadPermission_PR` (DecisionActivity toujours No → sous-WF jamais appelé ; fix = condition `!agvTask.CanPick`/`!agvTask.CanDrop` ; synthèse des 4 WF) ; **events 106/110 non gérés** (fix temporaire Michael : chargement/déchargement support dans `ProcessEvents_PR`) ; **refus de mission iGo** (Arthur : annulation tâche AGV + transition sequence 0) ; `Container_MovedEventHandler_PS_PR` = mouvement PS→PK première position libre (commit `9fa84a83e2`, base spécialisée ensuite par LIM-82/LIM-94). Réserve ajoutée sur le tableau « workflows inchangés » (ligne `ProcessEvents_PR` passée à Modifié). Front matter jira_refs/sources/last_updated, Historique, Références.
  **Cross-refs** : still-igo-integration.md ↔ placement-ps-pk.md (LIM-82 spécialisation PS→PK par type de tâche) + assignation-image-quai.md (LIM-94 position X max), galileo-config.md (module AGV)
  **Questions** : aucune nouvelle formalisée ; caveat = revue de code LIM-103 non encore réalisée (@Vincent) ; fix events 106/110 « temporaire à documenter » désormais documenté
 - **Fichier** : `Jira LIM-104` (lecture directe, 2 commentaires inclus)
  **Type** : Ticket Jira - #LOT 3 [AGV] Refuser l'annulation/suppression d'une Task quand le support est déjà sur un AGV (Nouvelle fonctionnalité, statut : En cours de test client / préprod, revue de code validée 23/06)
  **Action** : Intégration dans `limagrain/05-agv/still-igo-integration.md` : nouvelle sous-section « Refus WMS de l'annulation quand le support est sur un AGV (LIM-104) » sous « Logique d'annulation côté middleware » depuis la description + technical implementation (Maxime Halgand 04/06) : problème de désynchronisation (Task supprimée avant qu'iGo refuse l'annulation `>= Retrieved` → `ProcessEvents_PR` bloqué sur garde « CST Task exists = false » → notif refus AGE 255/1009 perdue + support figé sur AGE 110) ; solution = souscription **preview** sur la commande delete/cancel (critère `Container.StationType == Agv`, repli `LocationCode` AGV_) ; table AD (subscriptions `CST_TaskCancel_CheckAgv`/`CST_TaskDelete_CheckAgv`, WF `CST_CancelTask_CheckForAgv`, ressource `CST_CancelTask_NotPossible_2`) ; 2 cas de test (refus après pickup / autorisé avant pickup R4). Cross-ref ajoutée depuis le point d'attention « Annulation après chargement impossible ». Front matter jira_refs +LIM-104/sources, Historique, Références.
  **Cross-refs** : still-igo-integration.md (LIM-103 ProcessEvents_PR, logique d'annulation middleware, FAQ #6 cancel après Retrieved)
  **Questions** : aucune nouvelle (revue de code validée)
 - **Fichier** : `Jira LIM-105` (lecture directe, 11 commentaires inclus)
  **Type** : Ticket Jira - #LOT 2.1 [RECERTIFICATION] Workstation recertification (Tâche, statut : Attente déploiement pour test, revue de code validée 17/07)
  **Action** : **Nouvelle page** `limagrain/03-picking/recertification.md` depuis la description + 11 commentaires (implémentation Vincent Charvet, revues Maxime Halgand, demandes Justine) : process workstation au PK en mode « Tâches automatiques » - 4 étapes (scan ancienne palette → nouvelle étiquette SSCC → vérification ASN via polling `SAP_ATH111_REFRESH_INTERVAL`/`TIMEOUT`/`MAX_RETRIES` → échange conteneur : ancien chargé au quai + ASN déplacé à la position PK) + étape 5 filmage (ajout 01/07) ; assignation quai auto (classe RECERTIFICATION) ; suppression des valeurs hard codées → paramètre `RECERTIFICATION_CODE_CLASSE` (01/07) ; ajout code OS sur l'écran (Justine 08/07, commit db4194c50e) ; table AD (WF `CST_Recertification_PickingStationProcess_UI`, `Task_AutomaticPicking_UI`, `Workstation_Picking_Default`, `Outbound_AutomaticLoadProcess_PR`, `Outbound_CreateShippingContainersTasks_PR`, `CST_JobAssignStage`, `Container_MovedEventHandler_PK_PR` ; query `CST_AsnContainer_ByCode` + 4 queries recertif ; dialog `CST_Recertification_ScanLabelPrompt` ; 6 ressources ; commits 8b4debc3da/3119445ff1/db4194c50e) ; question ouverte message déclencheur ASN (SOF par palette vs message custom). Réconcilié : `_index.md` racine (nouvelle entrée + entrée process-picking-pk manquante, compteur **44→45**), `README.md` + `03-picking/_index.md` (ajout recertification + process-picking-pk), `07-admin/parametres-projet.md` (ajout `RECERTIFICATION_CODE_CLASSE`, Historique, Références LIM-105 ; SAP_ATH111_* déjà présents), `04-outbound/flux-expedition.md` (renvoi section Re-certification → nouvelle page, jira_refs/sources/last_updated/Historique), `glossaire-limagrain.md` (RECERTIFICATION_CODE_CLASSE).
  **Cross-refs** : recertification.md ↔ flux-expedition.md (flux outbound Re-certification), assignation-image-quai.md (LIM-94 quai auto recertif), job-assignation-pk.md (OS RECERTIFICATION exclus assignation picking), stations-picking.md (mode Tâches automatiques), parametres-projet.md (SAP_ATH111_*/RECERTIFICATION_CODE_CLASSE)
  **Questions** : message déclenchant l'envoi de l'ASN par SAP (SOF par palette = OS mono-palette qui ralentit, ou message custom) → dans la page (@Vincent/@Justine) ; à retester suite customs LIM-110
 - **Fichier** : `Jira LIM-106` (lecture directe, 3 commentaires inclus)
  **Type** : Ticket Jira - #LOT 2.1 [RECERTIFICATION] MINI-JOB Assignation au PK et création des tâches (Tâche, statut : Attente déploiement pour test, livré préprod 03/06, revue de code Maxime 29/06)
  **Action** : Intégration dans `limagrain/03-picking/job-assignation-pk.md` (page maître des mini jobs du Mega Job) : nouvelle section « Mini Job - Assignation recertification aux PK (LIM-106) » depuis la description + 3 commentaires (implémentation Vincent Charvet, corrections Maxime Halgand) - pendant du mini job picking LIM-80 mais pour les OS de classe RECERTIFICATION (que LIM-80 exclut) ; assignation triée priorité OS → date de libération (query `CST_OutboundOrder_Recertification_BestPendingAssignment_ForPK`) ; création des tâches d'acheminement (interception du process d'expédition `Outbound_CreateShippingContainersTasks_PR` → redirection `CST_Outbound_Recertification_CreateShippingContainersTasks_PR` → tâches de mouvement conteneurs d'expédition → PK ; à l'arrivée `Container_MovedEventHandler_PK_PR` crée la tâche de chargement au quai recertification) ; flag tâche `CstAtt02` = recertification (déplacé du 01, Maxime 26/06) + `ProcessType="recertification"` (`Container_MovedEvent_PR_V1`) ; annulation sur `ShippingContainerDeletedEvent` (souscription `CST_ShippingContainerDeleted_CancelRecertificationTask` → `CST_Container_CancelRecertificationTasks`) ; garde-fous Maxime 29/06 (pas de tâche si conteneur a déjà une tâche ou sur AGV ; blocage si pas de quai assigné à l'OS RECERTIFICATION) ; table AD (11 éléments : WF/queries/subscription/vue TaskVList/ressource) ; ligne ajoutée à la table des sous-workflows ; front matter jira_refs +LIM-106/sources/last_updated, Historique, Références (commits 35214806ca/b268e62a70). Réconcilié : `03-picking/recertification.md` (renvoi amont vers le mini job d'acheminement au PK, jira_refs +LIM-106, Historique, Références), `07-admin/ad-customs.md` (attribution LIM-106 au CstAtt Tâche 02 + note déplacement 01→02, Historique, Références).
  **Cross-refs** : job-assignation-pk.md ↔ recertification.md (workstation au PK), job-assignation-pk.md (LIM-80 exclusion recertif de l'assignation picking), ad-customs.md (CstAtt Tâche 02 recertification)
  **Questions** : aucune nouvelle (garde-fous et flag CstAtt tranchés en revue de code)
 - **Fichier** : `Jira LIM-107` (lecture directe, 3 commentaires inclus)
  **Type** : Ticket Jira - #LOT 2.1 [EXPEDITION][INVENTAIRE] Etiquettes (Tâche, statut : En revue de code, assignée Maxime Halgand)
  **Action** : Intégration du contenu des étiquettes d'expédition/échantillonnage par type depuis la description + 3 commentaires (question Arthur 02/07, arbitrage Justine 02/07, implémentation Vincent 07/07). Réparti sur 2 pages propriétaires : `04-outbound/flux-expedition.md` (nouvelle sous-section « Contenu des étiquettes d'expédition par type » sous Étiqueteuse automatique : format A5 ; Client/Production sur étiqueteuses automatiques, Échantillonnage sur étiqueteuses poste via flux COR/COF ; contenu étiquette Client 4 champs [tournée/OS/transporteur/adresse] + Production 3 champs [OS/128/SOR.Document] ; params EXPEDITION_CLASSE_CLIENT/PRODUCTION ; reports CST_RPT_OUTBOUND_CLIENT/PRODUCTION/ECHANTILLONAGE ; vues CST_VSearchPrintShipping*ContainerLabel + 2 boutons ContainerVList impression manuelle ; ressources i18n ; commit 10b0bc52fe) et `03-picking/echantillonnage.md` (nouvelle section « Étiquette d'échantillonnage » : format A5, 12 champs [ITM.CstAtt01/03/07/08/10, famille, ProductCode ligne inventaire, attribut taille stock, `_ / _` manuel, premier alias, COR.Code + 128], report CST_RPT_ECHANTILLONAGE, imprimé sur étiqueteuse poste via COR/COF ; **question format d'étiquette résolue** : A5). Réconcilié : `07-admin/parametres-projet.md` (params EXPEDITION_CLASSE_* déjà présents depuis LIM-14 → usage confirmé LIM-107, Historique + Références). Pas de nouvelle page.
  **Cross-refs** : flux-expedition.md ↔ echantillonnage.md (étiquette échantillonnage COR/COF), flux-expedition.md ↔ parametres-projet.md (EXPEDITION_CLASSE_CLIENT/PRODUCTION), etiquette-rfid.md (étiqueteuse automatique)
  **Questions** : format d'étiquette échantillonnage **résolu** (A5, LIM-107) ; aucune nouvelle
 - **Fichier** : `Jira LIM-108` (lecture directe, 2 commentaires inclus)
  **Type** : Ticket Jira - #LOT 1.2 [SIMULATION] Set un poids aux palettes qui passent au PIE (Tâche, statut : En cours de test client / pré-production, non assignée)
  **Action** : Intégration dans `limagrain/01-inbound/controle-qualite-reception.md` (page maître PIE/poids) : nouvelle section « [SIMULATION] Poids théorique en l'absence de poids Galileo (LIM-108) » depuis la description + 2 commentaires (implémentation Vincent 10/06, fix Maxime 18/06) - mode temporaire de simulation : quand la palette n'est pas créée au PIE (simple passage station), l'event Galileo ne descend pas toujours le poids → repli sur le poids théorique du conteneur ; gouverné par le toggle `CST_SimulatePIEScale` ; WF `PIE_EventHandler_CheckInvalidWeightWithScale_PR` (substitution) ajouté à la table AD ; note correction `CST_PIE_ApplyWeightRules_PR` (changement de version, Maxime 18/06) ; point d'attention « mode temporaire à ne pas laisser actif » ; front matter jira_refs +LIM-108/sources/last_updated, Historique, Références. Réconcilié : `07-admin/parametres-projet.md` (ajout toggle `CST_SimulatePIEScale` dans la table Toggles + cross-ref, jira_refs +LIM-108, Historique, Références). Pas de nouvelle page.
  **Cross-refs** : controle-qualite-reception.md ↔ parametres-projet.md (toggle CST_SimulatePIEScale)
  **Questions** : aucune nouvelle (mode simulation temporaire, implémentation et fix tranchés en revue de code)
 - **Fichier** : `Jira LIM-109` (lecture directe, 2 commentaires inclus)
  **Type** : Ticket Jira - #LOT 2.1 [EXPEDITION] Interdire les lignes d'OS sans lot (Tâche, statut : Attente déploiement pour test, revue de code validée Maxime 29/06)
  **Action** : Intégration dans `limagrain/04-outbound/shipping-orders.md` (page maître des ordres de sortie) : nouvelle section « [CUSTOM] Lot obligatoire sur les lignes d'OS (LIM-109) » depuis la description + 2 commentaires (implémentation Vincent 29/06, revue validée Maxime 29/06) - interdiction de créer un OS / une ligne d'OS si l'attribut logistique lot n'est pas renseigné ; subscription en Preview `CST_OutboundOrderLineCreated_CheckLotRequired_PRE` → WF `CST_OutboundOrderLineCreated_CheckLotRequired_PRE_PR` (exception si lot vide), ressource `CST_OutboundOrderLineCreation_MissingLot` ; refus total via `TransactionalLineList=true` ; renvoi vers Assignation de stock (lot = critère) et Paramètres ERP ; table AD ; front matter jira_refs +LIM-109/sources/last_updated, Historique, Références (commit 6ea0af3256). Pas de nouvelle page.
  **Cross-refs** : shipping-orders.md interne (Assignation de stock ↔ lot obligatoire, Paramètres ERP TransactionalLineList)
  **Questions** : aucune nouvelle (revue de code validée)
 - **Fichier** : `Jira LIM-110` (lecture directe, 3 commentaires inclus)
  **Type** : Ticket Jira - #LOT 2.1 [RECERTIFICATION] Quai Recertification & Stratégie d'assignation de stock (Tâche, statut : En cours de test client / pré-production, revue de code validée Maxime 03/07)
  **Action** : Intégration dans `limagrain/04-outbound/shipping-orders.md` (page maître OS, propriétaire des sections Quai recertification + Assignation de stock) : refonte de la section « Quai recertification » depuis la description + 3 commentaires (implémentation Vincent 01/07, revue Maxime 03/07, ajout édition OS Vincent 09/07) - assignation AUTOMATIQUE du quai `QUAI_RECERTIFICATION` (param `RECERTIFICATION_CODE_QUAI`) à la création (`OutboundOrder_OutboundOrderCreatedEventHandler_PR`) ET à l'édition d'un OS auquel on ajoute la classe RECERTIFICATION ; blocage du changement manuel (boutons masqués dans `OutboundOrderVList`) ; évolution vs V1 (avant renseigné dans le SOR) ; note exclusion LIM-94 (X_EXP exclut recertif). Nouvelle sous-section « Stratégie d'assignation de stock RECERTIFICATION » : stratégie « supports complets uniquement » toujours désactivée mais FORCÉE pour les OS recertif (`StockAssignProcess_GetStockAssignStrategies_PR`), `AllowPick=false` (`StockAssignProcess_GetStockToAssignForStrategy_PR`), balise `[XXX]` dans le code de la stratégie (XXX = `RECERTIFICATION_CODE_QUAI`), query `CST_StockAssignStrategyV2_Recertification` ; table AD ; caveat param QUAI vs CLASSE. Front matter jira_refs +LIM-110/sources/last_updated, Historique, Références (commits 716988832c, 56d524eb34, 435b4f5e89). Réconcilié : `03-picking/recertification.md` (correction du renvoi quai auto → shipping-orders.md/LIM-110 au lieu de LIM-94, note « à retester » précisée, jira_refs +LIM-110, Historique, Références), `07-admin/parametres-projet.md` (ajout param `RECERTIFICATION_CODE_QUAI`, jira_refs/Historique/Références), `glossaire-limagrain.md` (QUAI_RECERTIFICATION redéfini auto WMS + ajout RECERTIFICATION_CODE_QUAI), `08-transverse/questions-ouvertes.md` (question relation QUAI vs CLASSE + Historique). Pas de nouvelle page.
  **Cross-refs** : shipping-orders.md ↔ recertification.md (quai auto recertif) ↔ assignation-image-quai.md (LIM-94 exclut recertif) ↔ parametres-projet.md (RECERTIFICATION_CODE_QUAI) ↔ glossaire (QUAI_RECERTIFICATION) ↔ questions-ouvertes.md
  **Questions** : relation `RECERTIFICATION_CODE_QUAI` (identifie aussi les OS recertif + balise stratégie) vs `RECERTIFICATION_CODE_CLASSE` (LIM-105, déjà l'identifiant de classe) → à clarifier (@Vincent), tracé dans questions-ouvertes.md
 ## [2026-07-20] session-023 (mode: limagrain)
 > Source : lecture directe des tickets Jira LOT (pas de fichier déposé dans `sources/`).
 - **Fichier** : `Jira LIM-111` (lecture directe, aucun commentaire)
  **Type** : Ticket Jira - #LOT 2.1 Étiqueteuse automatique - intégration Galileo (Tâche, statut : Ouvert, assignée Vincent Charvet)
  **Action** : Intégration dans `limagrain/04-outbound/flux-expedition.md` (page propriétaire de la section Étiqueteuse automatique) - formalisation du **mécanisme d'intégration Galileo** depuis la description (pas de commentaire) : bandeau de statut (mécanisme Galileo = LIM-111 Ouvert, contenu = LIM-107, pose flag PK = LIM-91) ; « Principe » enrichi (noms de stations `LBLM_01`/`LBLM_02` de type **ET**, uniquement pour les supports ASRS → image de quai directs, positionnement dans la chaîne sortie TK) ; **refonte « Comportement à la sortie TK »** en logique **2 étiquettes distinctes** (tableau : étiquette d'expédition LIM-107 imprimée dans tous les cas sauf palette trop basse PLC Height Type 1, indépendante du flag ; étiquette de picking HU RFID LIM-68 conditionnée par `CstAtt14` = false/vide + hauteur OK) + cas d'usage 2e étiquette (palette complète ASRS jamais passée au picking) + MAJ flag true/error ; **« Communication Galileo »** enrichie (subscription `MovementCreated` → si destination LBLM, MAJ CustomData de la tâche avec le nombre d'étiquettes → informe le bras articulé du nombre de positions ; à la fin d'ordre = palette arrivée → `printerCommand` ; contenu envoyé à l'imprimante via `printerService` ; même principe que le filmage CstAtt05) ; `CstAtt14` nommé explicitement ; front matter jira_refs +LIM-111/sources/last_updated, Historique ; 2 questions ouvertes (remontée erreur impression, palette à l'arrêt). Réconcilié : `07-admin/ad-customs.md` (note CstAtt14 précisée - 3 valeurs, lu/mis à jour à l'étiqueteuse de sortie LIM-111, conditionne uniquement la ré-impression étiquette picking LIM-68 pas l'expédition LIM-107, réservé LIM-14 ; table CstAtt14 → LIM-91 / 111 ; jira_refs +LIM-106/LIM-111 ; Historique, Références), `08-transverse/questions-ouvertes.md` (2 questions LIM-111 en Expédition/Outbound + sources + Historique). Pas de nouvelle page.
  **Cross-refs** : flux-expedition.md ↔ ad-customs.md (CstAtt14 étiquetage) ↔ etiquette-rfid.md (étiquette HU RFID LIM-68) ↔ sequencage-shipping-stop.md (ordre STOP en sortie TK) ↔ questions-ouvertes.md ; renvoi LIM-107 (contenu) et LIM-91 (pose flag PK)
  **Questions** : mécanisme de remontée d'une erreur d'impression par les automates au WMS - nécessaire pour le mode dégradé TRF (@Vincent) ; palette à l'arrêt en cas de problème d'impression - intervention opérateur + procédure de redémarrage (@Théo/@Vincent). Tracées dans questions-ouvertes.md
 - **Fichier** : `Jira LIM-112` (lecture directe, 1 commentaire inclus)
  **Type** : Ticket Jira - #LOT 3 [INVENTAIRE][ECHANTILLONNAGE] Process d'échantillonnage sur poste de travail (Tâche, statut : Ouvert, assignée Vincent Charvet)
  **Action** : Enrichissement de `limagrain/03-picking/echantillonnage.md` (page propriétaire du process) depuis la description + 1 commentaire (Arthur 02/07 : mail client pour consignes) - bandeau statut LIM-112 (flux complet COR→COF, contenu étiquette = LIM-107) ; section Création de l'ordre enrichie (priorité 3 basse, consignes = CstAtt02, **table de mapping COR SAP→WMS** : Code/Description ECHANTILLONNAGE/Priority 3/CstAtt01 nb palettes toujours 4/CstAtt02 consignes/ProductCode-LotCode **inversés**/Color-Source-Size) ; Assignation du stock refondue (max = CstAtt01 palettes, verrou Production prioritaire, prérequis palette [allée non bloquée/rangée/non client/sans tâche], OrderByDesc [bloquée puis moins profonde], éditabilité CstAtt01 en manuel tant qu'inventaire non lancé, **règle transverse** : stock en échantillonnage indisponible pour les OS) ; Assignation poste (orchestration via Mega Job PK LIM-70 + sous-workflow dédié à développer, PK autorisant big-bag) ; séquence opérateur (recomptage à dev standalone, étape « valider la ligne d'inventaire », évacuation AGV poste→table d'entrée→PIE filmée ou non) ; **nouvelle section « Clôture et émission du COF »** (CountCode/Status Closed-Cancelled/UpdateDate, traitement SAP hors périmètre) ; point d'attention big-bag ; question 200g **résolue** (négligé) ; 2 nouvelles questions (consignes CstAtt01 vs 02, dépendance CstAtt10 Stage) ; front matter jira_refs +LIM-112/sources/tags cor,cof, Historique, Références. Réconcilié : `07-admin/ad-customs.md` (table CstAtt Ligne d'ordre d'inventaire : ajout CstAtt02 consignes + attribution LIM-112 au CstAtt01 + note usage/caveat, jira_refs +LIM-112, Historique, Références), `08-transverse/questions-ouvertes.md` (annotation dépendance CstAtt10 Stage + question consignes CstAtt01/02 + sources + Historique). Pas de nouvelle page.
  **Cross-refs** : echantillonnage.md ↔ ad-customs.md (CstAtt Ligne d'ordre d'inventaire 01/02) ↔ job-assignation-pk.md (Mega Job PK LIM-70) ↔ flux-expedition.md (étiquette échantillonnage LIM-107) ↔ controle-qualite-reception.md (PIE/poids) ↔ questions-ouvertes.md ; glossaire COR/COF déjà présents
  **Questions** : consignes de l'ordre d'inventaire portées sur CstAtt02 (mapping) vs CstAtt01 (commentaire ticket) → mail client (@Arthur) ; dépendance CstAtt10 (Stage) côté ITM requis pour l'étiquette d'échantillonnage, à vérifier préprod (@Nicolas). Tracées dans questions-ouvertes.md
 - **Fichier** : `Jira LIM-113` (lecture directe, 2 commentaires inclus)
  **Type** : Ticket Jira - #LOT 3 Flux API CHG (Changements support) (Tâche, statut : En cours - revue fonctionnelle uniquement, dévs non démarrés en attente validation client, assignée Vincent Charvet)
  **Action** : Refonte complète de la section CHG dans `limagrain/06-erp-interface/mapping-erp-wms.md` (page propriétaire du CHG) depuis la description + 2 commentaires (Arthur 06/07 : revue fonctionnelle seule ; Vincent 07/07 : comment identifier la ligne de stock) - objectif/contexte (SAP modifie une ligne de stock sans mouvement physique, cas bascule de propriétaire en clôture fiscale FR10→FR02, va à l'encontre de la règle d'or, encadré : refus si HU/lignes engagées) ; mécanisme `StartWorkflowCommand` → WF custom `CST_CHG_WF` sur CustomApplication, identité complète de la HU ; **table des 9 champs JSON** (containerCode/ContainerTypeCode/productCode/Quantity/UnitOfMeasureCode/LotCode/Color=propriétaire/Source=description/Size=destination) ; **statut de stock EXCLU** (passe par STR, 2 appels distincts) ; **logique WF en 5 étapes** (récup HU + ID ligne, contrôle « libre de tout flux » façon ADB-117 appliqué à la HU/lignes, refus tout ou rien avec motif table/flux, idempotence, application + 200) ; acquittement **200/500** (throw exception = seul canal de message d'erreur, un refus métier remonte en 500) ; notification interne WMS en cas de refus ; volumétrie clôtures (~1000 lignes, un tiers du stock sur 2 jours, messages unitaires, sync/async à valider Mecalux) ; cible 90/10 ; diagramme de séquence CHG refondu ; points d'attention (200/500, statut exclu, tout ou rien) ; front matter jira_refs +LIM-113/sources/tags/last_updated, Historique, Références (+ADB-117, DevOps 88942). Réconcilié : `06-erp-interface/messages-reference.md` (refonte entrée catalogue CHG + point d'attention 500 + question « format CHG » résolue, jira_refs +LIM-113, Historique), `08-transverse/questions-ouvertes.md` (2 questions CHG résolues [format, acquittement] + 3 nouvelles [ID ligne @Vincent, sync/async, liste exhaustive tables] + sources + Historique). Pas de nouvelle page (CHG enrichi dans sa page propriétaire). Glossaire CHG déjà présent.
  **Cross-refs** : mapping-erp-wms.md ↔ messages-reference.md (catalogue CHG) ↔ donnees-principales.md (attributs logistiques Color/Source/Size/Lot) ↔ questions-ouvertes.md ; STR (statut de stock, appel séparé)
  **Questions** : identification de la ligne de stock concernée dans la HU (@Vincent) ; traitement synchrone/asynchrone pour la volumétrie (@Nicolas/Mecalux) ; liste exhaustive des tables où une HU/ligne est référencée (action dev). Tracées dans questions-ouvertes.md
 - **Fichier** : `Jira LIM-114` (lecture directe, aucun commentaire)
  **Type** : Ticket Jira - #LOT 3 [REJET] Flux de rejet PIE - Renvoi au poste d'origine (Tâche, statut : Ouvert, non assignée, « rédaction en cours » côté ticket)
  **Action** : **Nouvelle page** `limagrain/02-stockage/rejet-pie.md` depuis la description (pas de commentaire) - flux custom de rejet au PIE (causes dimension/poids/étiquette/palette bois) avec **renvoi au poste de travail d'origine** (revirement client vs approche poumon au sol + SmartUI de LIM-66) ; principe « le WMS répond la destination » (pas de reprise des routes EasyS) ; topologie EST/OUEST (production entrée EST directe, réception/picking via PK OUEST, bascule OUEST si PE01 fermé) ; **algorithme de destination** (lire CstAtt06 poste d'origine → candidat, contrainte big-bag CstAtt02/PK_BIGBAG, dispo poste, sinon PK_REJET_PROD si CstAtt06 vide [production CstAtt04=ASN], sinon fallback first-available, verrou « REJET PIE » porteur de la cause) ; affichage de la cause au poste (pas de SmartUI, dépendance Mecalux pour le type d'erreur PIE) ; correction/ré-injection via « Stocker support » standard + re-contrôle PIE, **pas de garde-fou anti-boucle**, palette bois non réparable → REJ01 ; prérequis report CstAtt06 sur le support réel (LIM-67 réception, LIM-91 picking) ; nouveau paramètre PK_REJET_PROD ; 27 cas de test résumés par famille ; 4 points ouverts. Réconcilié : `01-inbound/controle-qualite-reception.md` (renvoi du rejet ECART RETOUR / rejet PIE toutes causes → nouvelle page), `07-admin/ad-customs.md` (note usage rejet CstAtt06 + jira_refs/Historique/Références LIM-114), `07-admin/parametres-projet.md` (ajout param PK_REJET_PROD + jira_refs/Historique/Références LIM-114), `08-transverse/questions-ouvertes.md` (annotation B2 LIM-93 + 4 points ouverts LIM-114 + sources + Historique), `_index.md` racine (nouvelle entrée, compteur **45→46**), `README.md` + `02-stockage/_index.md` (ajout lien rejet-pie). Glossaire : REJ01/PK_REJET_PROD définis inline dans la page / params.
  **Cross-refs** : rejet-pie.md ↔ controle-qualite-reception.md (PIE/LIM-66) ↔ ad-customs.md (CstAtt06/02/04) ↔ parametres-projet.md (PK_REJET_PROD/PK_BIGBAG/PIE_ENTRY_PK) ↔ job-assignation-pk.md (dispo poste LIM-70/74) ↔ questions-ouvertes.md (B2 LIM-93)
  **Questions** : transmission de la cause de rejet EasyS/Galileo→WMS (@Mecalux) ; poste physique PK_REJET_PROD côté EST + joignabilité si PE01 fermé (layout) ; comportement si aucun poste disponible ; disponibilité imprimante au poste (cause étiquette). Tracées dans questions-ouvertes.md
 - **Fichier** : `Jira LIM-115` (lecture directe, aucun commentaire)
  **Type** : Ticket Jira - #LOT 3 Transmettre le programme de filmage à la filmeuse (Tâche, statut : Ouvert, assignée Vincent Charvet)
  **Action** : Intégration dans `limagrain/02-stockage/galileo-config.md` (page propriétaire Galileo/PIE/filmeuse) : nouvelle section « Transmission du programme de filmage à la filmeuse (LIM-115) » depuis la description (pas de commentaire) - objectif (transmettre auto le programme de filmage à Galileo quand une palette quitte un PIE vers l'ASRS, sans action opérateur ; même principe custom data que l'étiqueteuse LIM-111, la tâche ne produit pas le programme mais le transmet) ; chaîne fonctionnelle (choix opérateur → CstAtt05 → évacuation AGV → filmeuse puis PIE → ASRS ; règle « on ne filme que si PIE OK » structurellement satisfaite) ; mécanisme en tableau (subscription `MovementCreated` légère, filtre station source = paramètre PIE concernés, lecture support→CstAtt05, force CstData=0 si vide/pas de filmage/**destination rejet**, écriture idempotente CustomData de la tâche parente, pas de collision étiqueteuse = type de tâche différent, lecture Galileo via `GalileoMovTrackingCreateCommand` Generated→Running) ; périmètre (déclencheur PIE_02 en paramètre, tous flux entrant ASRS via poste d'identification zone travail = réception ext/intersite/retour picking/recertif ; hors PIE_01 production, PIE_03 pas de filmeuse, pose CstAtt05 = LIM-67, mécanique physique filmeuse) ; **caveat réconciliation** PIE_03 (galileo-config dit « idem PIE_02 » pour l'insertion, mais pas de filmeuse) ; front matter jira_refs +LIM-115/sources/tags/last_updated, Historique, Références. Réconcilié : `07-admin/parametres-projet.md` (ajout param `PIE_FILMAGE` nom à confirmer + cross-ref, jira_refs +LIM-115, Historique, Références), `07-admin/ad-customs.md` (note CstAtt05 usage transmission LIM-115 + caveat type int vs code alphanumérique, table 05 → LIM-67 / 115, jira_refs +LIM-115, Historique, Références), `04-outbound/flux-expedition.md` (§Filmage : CstAtt05 + cross-ref mécanisme LIM-115). Pas de nouvelle page.
  **Cross-refs** : galileo-config.md ↔ ad-customs.md (CstAtt05) ↔ parametres-projet.md (PIE_FILMAGE/FILMAGES) ↔ flux-expedition.md (§Filmage picking) ↔ flux-expedition.md §Communication Galileo (LIM-111, même principe custom data) ; LIM-67 (pose CstAtt05)
  **Questions** : aucune nouvelle formalisée (périmètre validé) ; caveat = réconciliation PIE_03 (pas de filmeuse) et type CstAtt05 (int vs alphanumérique) notés dans les pages
 - **Fichier** : `Jira LIM-116` (lecture directe, 3 commentaires inclus)
  **Type** : Ticket Jira - #LOT 3 Mouvements manuels depuis la station de picking (Tâche, statut : Attente déploiement pour test, assignée Vincent Charvet)
  **Action** : Intégration dans `limagrain/03-picking/process-picking-pk.md` (page propriétaire du process opérateur PK) depuis la description + 3 commentaires (Vincent 15/07 éléments modifiés ; Maxime 17/07 revue validée ProcessContext `Container_CloseClientContainerOnMP_PR` ; Maxime 17/07 fix temporaire MP → PE) - nouvelle section « Mouvements manuels du poste (appeler / renvoyer) » : filmage sur action « Stocker support » (`Return_ContainerFromPKStation_UI`, réutilise la sélection LIM-67 `CST_Workstation_Wrapping_UI`), filmage sur renvoi automatique quand le conteneur n'a plus de tâches (`Task_AutomaticPicking_UI`), sélection du PIE de retour via `ProcessContext` (`Container_MoveToStationTypeCodeListOrReject` + `Container_CloseClientContainerOnMP_PR`, PIE_ENTRY_PK/PIE02, même WF de destination que le rejet PIE LIM-114), capacité des buffers PK → PK (`Task_GenerateMovement_PR_V2`) ; optim Justine 16/07 (écran filmage sur Stocker support + PIE02) marquée **livrée par LIM-116**, reste distinction visuelle mère/client à confirmer ; caveat correction temporaire MP → PE (retirée après gestion complète MP → PK) ; front matter jira_refs +LIM-116/LIM-67/sources/last_updated, Historique, Références (commit LOT3 e79f385242). Réconcilié : `03-picking/placement-ps-pk.md` (note capacité buffers PK → PK `Task_GenerateMovement_PR_V2` + renvoi vers mouvements manuels, jira_refs +LIM-116, Historique, Références). Pas de nouvelle page (delta dans les pages propriétaires). Pas de nouveau CstAtt ni paramètre (réutilise CstAtt05 filmage LIM-67 et PIE_ENTRY_PK).
  **Cross-refs** : process-picking-pk.md ↔ placement-ps-pk.md (buffers PK → PK) ↔ reception-fournisseur.md (LIM-67 sélection filmage) ↔ rejet-pie.md (WF destination `Container_MoveToStationTypeCodeListOrReject`, PIE_ENTRY_PK) ↔ parametres-projet.md (PIE_ENTRY_PK/FILMAGES)
  **Questions** : aucune nouvelle formalisée ; caveats = distinction visuelle écran filmage mère vs client (optim Justine, à confirmer) et fix temporaire MP → PE (à retirer après MP → PK) notés dans process-picking-pk.md
 - **Fichier** : `Jira LIM-117` (lecture directe, aucun commentaire)
  **Type** : Ticket Jira - #LOT 2.1 [RUT] Mapping auto des adresses des SOR des tournées (Tâche, statut : Ouvert, assignée Vincent Charvet)
  **Action** : Intégration dans `limagrain/04-outbound/flux-erp-outbound.md` (page propriétaire des messages RUT/SOR) depuis la description (pas de commentaire) - nouvelle section « [CUSTOM] Adresse de livraison des SOR de tournée (LIM-117) » : en standard le SOR porte l'adresse de livraison mais la liste de SOR d'un RUT (`RouteErpCommand`) ne l'expose pas ; SAP transmet l'adresse dans le `CustomAttribute` de chaque SOR (table Attribute1-7 = code postal/site/rue/commune/région/pays/téléphone-commentaire, libellés déduits de l'exemple SAP `RUT-2026-000451_BIS`, à confirmer), post-subscription WMS de mapping vers l'OS **à développer** ; point d'attention ; ajout des sections Historique + Références (absentes) ; front matter jira_refs +LIM-117/sources/tags/last_updated. Réconcilié : `06-erp-interface/messages-reference.md` (note « Adresse de livraison » sur le flux RUT + renvoi vers flux-erp-outbound.md, jira_refs +LIM-117, Historique). Pas de nouvelle page. Pas de nouveau CstAtt d'entité WMS (CustomAttribute du message SOR côté SAP) ni de paramètre.
  **Cross-refs** : flux-erp-outbound.md (RUT/SOR) ↔ messages-reference.md (catalogue RUT) ; cible OS = shipping-orders.md
  **Questions** : aucune nouvelle formalisée ; caveat = libellés des Attribute1-7 déduits de l'exemple SAP (à confirmer) et post-subscription WMS restant à développer (LIM-117 Ouvert), notés dans flux-erp-outbound.md
@@ -1,5 +1,5 @@
 ---
-title: "Glossary — EasyWMS / Mecalux"
+title: "Glossary - EasyWMS / Mecalux"
 type: glossary
 sources:
  - wiki/concepts/container.md
@@ -86,7 +86,7 @@ related:
 last_compiled: "2026-04-17"
 ---
-# Glossary — EasyWMS / Mecalux
+# Glossary - EasyWMS / Mecalux
 All terms specific to EasyWMS (by Mecalux), including product names, abbreviations, AD element names, ERP message codes, and field names. General WMS/logistics terms are included only when EasyWMS usage differs from industry standard.
@@ -109,8 +109,8 @@ Self-navigating forklift or carrier used in automatic warehouses. Communicates w
 **AI (Application Identifier)**
 GS1 prefix code embedded in a barcode to identify the type of data that follows. Examples: AI(00) = SSCC, AI(02) = GTIN, AI(10) = lot, AI(17) = expiry date.
-**ALM station (Almacén — Storage)**
+**ALM station (Almacén - Storage)**
-Station type used as a pure storage entry/exit point. Containers are deposited at ALM stations for AS/RS retrieval to racks. In the FR/EN translation matrix: ALM (ES) = MAG (FR) = AIS (EN). See [Mechanical Elements — Station codes](concepts/mechanical-elements.md#3-station-codes--fr--es--en-matrix).
+Station type used as a pure storage entry/exit point. Containers are deposited at ALM stations for AS/RS retrieval to racks. In the FR/EN translation matrix: ALM (ES) = MAG (FR) = AIS (EN). See [Mechanical Elements - Station codes](concepts/mechanical-elements.md#3-station-codes---fr--es--en-matrix).
 **AP / APC / APR (Apilador de Paletas)**
 Pallet stacker machines. **AP** = Empty Pallet Stacker, **APC** = Chain Pallet Stacker, **APR** = Roller Pallet Stacker. See [Mechanical Elements](concepts/mechanical-elements.md#1-machine--equipment-acronyms-es--en).
@@ -119,10 +119,10 @@ Pallet stacker machines. **AP** = Empty Pallet Stacker, **APC** = Chain Pallet S
 Automatic Pallet Shuttle variant using supercapacitors (SUPERCAP) instead of batteries. Faster charge cycles, shorter standalone runtime. See [Mechanical Elements](concepts/mechanical-elements.md).
 **ATC (Abatible Transportador de Cadenas)**
-Lift-up gate Chain Conveyor — chain conveyor with a retractable gate for pedestrian passage. See [Mechanical Elements](concepts/mechanical-elements.md).
+Lift-up gate Chain Conveyor - chain conveyor with a retractable gate for pedestrian passage. See [Mechanical Elements](concepts/mechanical-elements.md).
 **Automatic Aisle**
-EasyS station element representing a stacker crane (TK) or Miniload. Linked to a rack; all locations inside the rack are reachable only through this aisle. See [Galileo Simulation — §3.4](operations/galileo-simulation.md#34-automatic-aisle-tk--miniload).
+EasyS station element representing a stacker crane (TK) or Miniload. Linked to a rack; all locations inside the rack are reachable only through this aisle. See [Galileo Simulation - §3.4](operations/galileo-simulation.md#34-automatic-aisle-tk--miniload).
 **APS (Automated Pallet Shuttle)**
 3D compact storage system managed by the APS3D module. Locations tagged as APS or APSFIFO. The Fleet Manager controller coordinates lifts, shuttles, and conveyors. See [APS3D](modules/aps3d.md).
@@ -175,13 +175,13 @@ Putaway strategy variant applied **before** standard location strategies, used f
 A container whose stock is assigned to a specific shipping order. The `Is client LPN` flag is true. Client containers are created during picking and track the prepared stock from pick face to shipping dock. See [Container](concepts/container.md).
 **Client stock**
-Stock that is inside a client container — i.e., stock that has been prepared for a specific outbound order. Cannot be adjusted without first un-preparing the shipment.
+Stock that is inside a client container - i.e., stock that has been prepared for a specific outbound order. Cannot be adjusted without first un-preparing the shipment.
 **CMC (Container Movement Confirmation)**
 Inbound ERP request message. Asks the WMS to move a container between locations. Generates a Manual Movement task. See [ERP Interface](concepts/erp-interface.md).
 **CME station (Control Miniload Entrée)**
-Control station at the entry of a Miniload/TK. If the downstream TE is full, CME recirculates the container to avoid collision. Must report a "route full" status (3) when saturated — see [Stations](concepts/stations.md#route-configuration-in-easys-robotics) and [Galileo Integration](architecture/galileo-integration.md).
+Control station at the entry of a Miniload/TK. If the downstream TE is full, CME recirculates the container to avoid collision. Must report a "route full" status (3) when saturated - see [Stations](concepts/stations.md#route-configuration-in-easys-robotics) and [Galileo Integration](architecture/galileo-integration.md).
 **Conclure (replenishment)**
 French SmartUI label for the **Top-off / Particular Demand** replenishment strategy. Pre-brings stock based on reserved outbound orders on the picking locations. See [Replenishment](concepts/replenishment.md).
@@ -245,10 +245,10 @@ Automatic conveyor element that routes containers to different destinations base
 Process of moving containers between locations to optimize space and picking efficiency. Two strategies: **rotation** (by ABC class) and **shipping** (pre-position for orders). Automatic warehouse only. See [Defragmentation](concepts/defragmentation.md).
 **Division (location cart)**
-A subdivision of a **Location cart** used for wave / group picking. Each division is identified and can be tied to a specific order or wave, so one cart holds several concurrent pickings without mixing stock. See [Picking](concepts/picking.md#location-carts-chariots-à-emplacement).
+A subdivision of a **Location cart** used for wave / group picking. Each division is identified and can be tied to a specific order or wave, so one cart holds several concurrent pickings without mixing stock. See [Picking](concepts/picking.md#location-carts-chariots-à-emplacement-for-multi-order-picking).
 **DirectTransfer**
-Value of the `<SorType>` field in the `SOR(01|02)` shipping order message, used for inter-warehouse transfers. Closing the expedition at origin automatically generates an `ASO01` on destination, pre-creating the incoming ASN container. Deleting the container from SmartUI triggers `ASK01`. Both messages carry **no reference to the source shipping order**. See [Order Outbound](concepts/order-outbound.md#asn--directtransfer-flow) and [Reception](concepts/reception.md#directtransfer--inter-warehouse-asn-flow).
+Value of the `<SorType>` field in the `SOR(01|02)` shipping order message, used for inter-warehouse transfers. Closing the expedition at origin automatically generates an `ASO01` on destination, pre-creating the incoming ASN container. Deleting the container from SmartUI triggers `ASK01`. Both messages carry **no reference to the source shipping order**. See [Order Outbound](concepts/order-outbound.md#asn---directtransfer-flow) and [Reception](concepts/reception.md#directtransfer---inter-warehouse-asn-flow).
 **Delete_StockStatusJob_PR**
 Background job. Automatically removes time-expired stock quality locks. Runs every 15 minutes by default. See [Quality Control](concepts/quality-control.md).
@@ -260,7 +260,7 @@ Multi-Carrier XML message used to **merge** (fuse) several outbound orders into
 Entity combining a carrier + consignee for a shipment. Holds tracking number, delivery note, and carrier label. Created when a shipping order is packaged at a Multi-Carrier station. See [Multi-Carrier](modules/multi-carrier.md).
 **Dialog (AD)**
-An AD element type representing a multi-step operator flow — typically a wizard or guided process on the RF terminal or SmartUI. Examples: `ReceptionDialog`, `PickingDialog`, `CountDialog`. Each step is a form with specific validations. See [Application Dictionary](architecture/application-dictionary.md).
+An AD element type representing a multi-step operator flow - typically a wizard or guided process on the RF terminal or SmartUI. Examples: `ReceptionDialog`, `PickingDialog`, `CountDialog`. Each step is a form with specific validations. See [Application Dictionary](architecture/application-dictionary.md).
 **DOM (Distributed Order Management)**
 EasyWMS module for multi-node warehouse networks. Orchestrates sales orders across nodes using a 5-stage engine (region → carrier → stock → capacity → strategies). See [DOM](modules/dom.md).
@@ -269,17 +269,17 @@ EasyWMS module for multi-node warehouse networks. Orchestrates sales orders acro
 Inventory control process where count discrepancies or adjustments require a second approval by a supervisor/manager before being committed to stock. Controlled via item count profile and `DOUBLE_VALIDATION_ACTIVE` parameter. See [Stock Adjustment](concepts/stock-adjustment.md) and [Count](concepts/count.md).
 **DeleteEmptyContainers**
-Station/location parameter that decides what happens to empty supports. Robotics default for automated locations: **Not Delete**. Picking stations (PK) may use `Delete` or `Ask` when operators physically remove empty containers. See [Galileo Simulation — §3.1](operations/galileo-simulation.md#31-location--container-settings).
+Station/location parameter that decides what happens to empty supports. Robotics default for automated locations: **Not Delete**. Picking stations (PK) may use `Delete` or `Ask` when operators physically remove empty containers. See [Galileo Simulation - §3.1](operations/galileo-simulation.md#31-location--container-settings).
 **DTR (Document Technique de Référence)**
-Reference document listing all technical elements for a robotics project (hardware, IPs, services, accounts) and the responsibility split between Mecalux and the client. Template on [Confluence](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000562515980). See [Robotics Project Lifecycle — §2](operations/robotics-project-lifecycle.md#2-dtr--document-technique-de-référence).
+Reference document listing all technical elements for a robotics project (hardware, IPs, services, accounts) and the responsibility split between Mecalux and the client. Template on [Confluence](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000562515980). See [Robotics Project Lifecycle - §2](operations/robotics-project-lifecycle.md#2-dtr---document-technique-de-référence).
 ---
 ## E
 **Exiger (replenishment)**
-French SmartUI label for the **Dynamic / On-Demand** replenishment strategy — replenishment triggered when picking consumption empties a picking location, regardless of threshold. See [Replenishment](concepts/replenishment.md).
+French SmartUI label for the **Dynamic / On-Demand** replenishment strategy - replenishment triggered when picking consumption empties a picking location, regardless of threshold. See [Replenishment](concepts/replenishment.md).
 **Est renseigné (Count)**
 SmartUI flag on a Count Order Line (`CountOrderLineVList`) that controls whether the line is **informed** (expected quantity visible to operator) or **blind** (hidden). Historical ERP sends it via COR `IsInformed`; SmartUI can toggle it per line afterwards. See [Count](concepts/count.md#blind-vs-informed-mode).
@@ -288,31 +288,31 @@ SmartUI flag on a Count Order Line (`CountOrderLineVList`) that controls whether
 Barcode standard for item identification. EAN-13 is the most common; used on item labels and for carton identification. Related to GS1/GTIN standards. See [Labels](concepts/labels.md).
 **EasyS**
-Mecalux's layout configuration tool for EasyWMS, and **3D robotics simulator** that speaks the same protocol as GALILEO. Used to: (1) define physical warehouse topology — aisles, racks, locations, stations, equipment groups, routes; (2) run a full simulation with an EasyWMS Gateway for development and demos (port 3000, Start → Simulation 3D, PIE injection via PIE Info tab). Shared demo VM at Mecalux France: ALL on LYOITSW02 (`10.58.10.75`). See [Galileo Simulation](operations/galileo-simulation.md).
+Mecalux's layout configuration tool for EasyWMS, and **3D robotics simulator** that speaks the same protocol as GALILEO. Used to: (1) define physical warehouse topology - aisles, racks, locations, stations, equipment groups, routes; (2) run a full simulation with an EasyWMS Gateway for development and demos (port 3000, Start → Simulation 3D, PIE injection via PIE Info tab). Shared demo VM at Mecalux France: ALL on LYOITSW02 (`10.58.10.75`). See [Galileo Simulation](operations/galileo-simulation.md).
 **EasyWMS Gateway**
 Windows service (`EasyWMSGateway2015`) that brokers all communication between EasyWMS and the automation layer (GALILEO in production, EasyS in simulation). Installed at `C:\Program Files\Mecalux\EasyWMS Gateway 2015`; config at `C:\ProgramData\Mecalux\EasyWMS Gateway 2015\Config\MainObject.config` (tenantCode + TokenUser); logs at `C:\ProgramData\Mecalux\EasyWMS Gateway 2015\Logs\AllLog.log`; uses TCP port 3000. See [Galileo Integration](architecture/galileo-integration.md).
 **End (GALILEO message)**
-GALILEO-to-WMS message that signals a movement has completed. Carries an `EndErrorCode` (0 = OK, 1 = deposit error, 2 = extraction error, 4 = inconsistent order — config mismatch, 7 = gauge error). Processed by `Galileo_EndCreatedEventHandler_PR`. See [Galileo Integration — End](architecture/galileo-integration.md#3-end-log--end0-end1-).
+GALILEO-to-WMS message that signals a movement has completed. Carries an `EndErrorCode` (0 = OK, 1 = deposit error, 2 = extraction error, 4 = inconsistent order - config mismatch, 7 = gauge error). Processed by `Galileo_EndCreatedEventHandler_PR`. See [Galileo Integration - End](architecture/galileo-integration.md#3-end-log--end0-end1-).
 **EndErrorCode**
-Numeric code attached to a GALILEO End message. Value `4` is the most common diagnostic — indicates a configuration drift between EasyWMS and GALILEO (missing location, wrong allowed container type, X/Y out of range, impossible crossing). See [Galileo Troubleshooting — §3.1](operations/galileo-troubleshooting.md#31-enderrorcode--4-most-frequent).
+Numeric code attached to a GALILEO End message. Value `4` is the most common diagnostic - indicates a configuration drift between EasyWMS and GALILEO (missing location, wrong allowed container type, X/Y out of range, impossible crossing). See [Galileo Troubleshooting - §3.1](operations/galileo-troubleshooting.md#31-enderrorcode--4-most-frequent).
 **Empileur (EMP / APL)**
 Pallet stacker station (code 13). See [Stations](concepts/stations.md) and [Mechanical Elements](concepts/mechanical-elements.md).
 **EMS (Sistema electrovía aérea)**
-Overhead Electric Monorail — suspended pallet transport system. See [Mechanical Elements](concepts/mechanical-elements.md).
+Overhead Electric Monorail - suspended pallet transport system. See [Mechanical Elements](concepts/mechanical-elements.md).
 **ECB (Empty Container Buffer)**
-Station type 55 — buffer specifically for empty containers waiting to be stacked or reused. See [Stations](concepts/stations.md).
+Station type 55 - buffer specifically for empty containers waiting to be stacked or reused. See [Stations](concepts/stations.md).
 **Event (GALILEO message)**
-GALILEO-to-WMS message declaring container presence at a checkpoint. Primary source is the PIE (barcode + gauge + weight). Content varies by station; flags `65536`=OK, `256`=barcode error, `512`=recovered, `1024`/`66560`=empty OK, `4`=overheight. Processed by `Galileo_PIEEventHandler_PR`. See [Galileo Integration — Event](architecture/galileo-integration.md#1-event-log--event).
+GALILEO-to-WMS message declaring container presence at a checkpoint. Primary source is the PIE (barcode + gauge + weight). Content varies by station; flags `65536`=OK, `256`=barcode error, `512`=recovered, `1024`/`66560`=empty OK, `4`=overheight. Processed by `Galileo_PIEEventHandler_PR`. See [Galileo Integration - Event](architecture/galileo-integration.md#1-event-log--event).
 **ETQ (Étiqueteuse)**
-Labeller station type 58 — an automatic labelling machine through which a container passes to receive a printed label. See [Stations](concepts/stations.md).
+Labeller station type 58 - an automatic labelling machine through which a container passes to receive a printed label. See [Stations](concepts/stations.md).
 **eCommerce module**
 EasyWMS add-on module for e-commerce fulfillment. JIT reception flow: single-unit orders go to packing, multi-unit to ungrouping, no-order stock to storage. See [eCommerce](modules/ecommerce.md).
@@ -326,7 +326,7 @@ In EasyWMS, an equipment is a physical device (forklift, hand truck, conveyor se
 **ERP Interface**
 The set of standardized messages exchanged between EasyWMS and the customer's ERP system (SAP, Oracle, etc.). Three-letter codes identify each message type (ROR, SOR, ASN, ROF, SOF, etc.). See [ERP Interface](concepts/erp-interface.md).
-**ET station (Estación de Tránsito — Transit)**
+**ET station (Estación de Tránsito - Transit)**
 Station type used as an intermediate buffer between two zones that cannot directly route to each other. A conveyor element in EasyS; appears in the "Automatic elements" group. Required for multi-zone replenishment flows. See [Stations](concepts/stations.md).
 **Event (AD)**
@@ -351,7 +351,7 @@ Shipping/storage logic where the oldest stock (by receipt date) is consumed firs
 **Fleet Manager**
 Controller software/hardware that coordinates APS3D shuttle movements, lifts, and conveyors. Communicates with EasyWMS via the Fleet Manager protocol. See [APS3D](modules/aps3d.md) and [Stations](concepts/stations.md).
-**Fusion (order fusion) — synonym Merge**
+**Fusion (order fusion) - synonym Merge**
 Grouping of two or more shipping orders into a single picking wave for joint preparation. Orders in a fusion share picking tasks. See [Shipping](concepts/shipping.md).
 ---
@@ -362,10 +362,10 @@ Grouping of two or more shipping orders into a single picking wave for joint pre
 Windows service provided by Mecalux that bridges Easy WMS workflows and the PostgreSQL exchange tables used by the AGV module. Serializes AGV tasks into `agv_outputqueue` / `agv_eag`, reads fleet manager responses from `agv_inputqueue` / `agv_age` / `agv_ags`. Polls at configurable intervals (default 1 second). Creates all PostgreSQL tables and sequences on first startup. Config file: `C:\ProgramData\Mecalux\EasyWMS GatewayAGV 2015\`. See [AGV](modules/agv.md) and [AGV Installation Guide](operations/agv-installation.md).
 **Galileo**
-Mecalux's production **Transport Management System (TMS)** — the automation layer that drives conveyors, stacker cranes (TK/Miniload), shuttles, AGVs and lifts. Has **no predictive vision**; only requests orders from EasyWMS and executes them. Also used inside EasyS as the label of the conveyor route type (opposed to Manual / Virtual) — a "Galileo" route is a physical hop that requires Gateway communication. See [Galileo Integration](architecture/galileo-integration.md) and [Stations](concepts/stations.md).
+Mecalux's production **Transport Management System (TMS)** - the automation layer that drives conveyors, stacker cranes (TK/Miniload), shuttles, AGVs and lifts. Has **no predictive vision**; only requests orders from EasyWMS and executes them. Also used inside EasyS as the label of the conveyor route type (opposed to Manual / Virtual) - a "Galileo" route is a physical hop that requires Gateway communication. See [Galileo Integration](architecture/galileo-integration.md) and [Stations](concepts/stations.md).
 **Galileo_PIEEventHandler_PR / Galileo_SearchCreatedEventHandler_PR / Galileo_EndCreatedEventHandler_PR**
-The three core workflows consuming GALILEO messages: PIE events (inbound identification), Search requests (next-hop routing — can fire dozens per second, do not activate instance tracing carelessly), and End notifications (movement complete / error). See [Galileo Integration — AD entry points](architecture/galileo-integration.md#application-dictionary-entry-points).
+The three core workflows consuming GALILEO messages: PIE events (inbound identification), Search requests (next-hop routing - can fire dozens per second, do not activate instance tracing carelessly), and End notifications (movement complete / error). See [Galileo Integration - AD entry points](architecture/galileo-integration.md#application-dictionary-entry-points).
 **GalileoMovTrackingCreateCommand**
 Preferred AD command for pushing a movement order to GALILEO (over the deprecated `GalileoMovTrackingCreateChangingTargetCommand`). Transition: movement `Generated` → `In progress`, container placed on virtual location **Mov**. See [Galileo Integration](architecture/galileo-integration.md).
@@ -393,10 +393,10 @@ Mecalux cobot integration protocol. The Cobot module connects robotic picking ar
 Period immediately after MEP (go-live) during which the dev team handles bug fixes on the `develop` branch. Ends when the project is transferred to the Support team (TLM). See [Git Branch Lifecycle](operations/git-branch-lifecycle.md).
 **IdentError / IdentErrorType**
-Enum of rejection reason codes (PIE barcode unreadable, overheight, overhang, overweight, no ASN match…). Different IdentErrors can route containers to different reject destinations using **reject routes** (displayed in red in EasyS). Reference: [IdentErrorType doc](https://msscc.mecalux.com/documentation/Development/master/ES/apis/easywms/Domain/IdentErrorType.md). See [Galileo Simulation — §3.11](operations/galileo-simulation.md#311-reject-configuration).
+Enum of rejection reason codes (PIE barcode unreadable, overheight, overhang, overweight, no ASN match…). Different IdentErrors can route containers to different reject destinations using **reject routes** (displayed in red in EasyS). Reference: [IdentErrorType doc](https://msscc.mecalux.com/documentation/Development/master/ES/apis/easywms/Domain/IdentErrorType.md). See [Galileo Simulation - §3.11](operations/galileo-simulation.md#311-reject-configuration).
 **IMS (Sistema electrovía invertida)**
-Inverted Electric Monorail — floor-based inverted monorail variant of EMS. See [Mechanical Elements](concepts/mechanical-elements.md).
+Inverted Electric Monorail - floor-based inverted monorail variant of EMS. See [Mechanical Elements](concepts/mechanical-elements.md).
 ---
@@ -429,10 +429,10 @@ Performance metrics tracked in the Data Analytics module or displayed on the 3PL
 ## L
 **Location cart (chariot à emplacement)**
-Mobile cart divided into numbered **divisions**, used at the RFT for wave and group picking so a single operator prepares multiple orders in one pass without mixing stock. Requires specific SmartUI configuration (cart type, division count, assignment to work area). See [Picking](concepts/picking.md#location-carts-chariots-à-emplacement).
+Mobile cart divided into numbered **divisions**, used at the RFT for wave and group picking so a single operator prepares multiple orders in one pass without mixing stock. Requires specific SmartUI configuration (cart type, division count, assignment to work area). See [Picking](concepts/picking.md#location-carts-chariots-à-emplacement-for-multi-order-picking).
 **LogisticAttributeCreateLogisticCaptureCommand**
-Run Command that adds a **capture mode** to an existing logistic attribute. Used with `CaptureMode = 2` and `CaptureProcess = 2` to create an attribute with **no capture mode** — that is, one auto-generated by custom code rather than prompted on the RFT/SmartUI. See [Product / Item](concepts/product-item.md#creating-a-logistic-attribute-without-a-capture-mode).
+Run Command that adds a **capture mode** to an existing logistic attribute. Used with `CaptureMode = 2` and `CaptureProcess = 2` to create an attribute with **no capture mode** - that is, one auto-generated by custom code rather than prompted on the RFT/SmartUI. See [Product / Item](concepts/product-item.md#creating-a-logistic-attribute-without-a-capture-mode).
 **LneTrmAlternative**
 Sub-field of `<LneTerms>` in `SOR(01|02)`. Boolean flag enabling the **substitute item** feature at line level. When `true`, the WMS may ship the configured substitute items (see shipping profile mode: Partiel / Substitution / Tout ou rien) if the primary item has insufficient stock. Returned in `SOF` alongside `LneDIsAlternative` to flag the actual substitute used. See [Product / Item](concepts/product-item.md#alternative--substitute-items) and [Order Outbound](concepts/order-outbound.md#alternative-items-sor-flag--sof-feedback).
@@ -478,22 +478,22 @@ A stock or container relocation performed without generating a task. Eight move
 Automatic warehouse station where containers exit the system onto multiple possible conveyor lanes. See [Stations](concepts/stations.md).
 **ME / TE (Aisle Inbound Conveyor / Table d'entrée)**
-Station type 9 — the conveyor at the entry of a TK/Miniload. Can hold multiple containers (layout uses Positions + Stack); configure `Logical X = 991` except for tables embedded in the rack. FR: TE, ES: ME, EN: Input Conveyor (IC). See [Stations](concepts/stations.md) and [Galileo Simulation — §3.8](operations/galileo-simulation.md#38-entry--outbound-tables-te--ts-on-the-tk).
+Station type 9 - the conveyor at the entry of a TK/Miniload. Can hold multiple containers (layout uses Positions + Stack); configure `Logical X = 991` except for tables embedded in the rack. FR: TE, ES: ME, EN: Input Conveyor (IC). See [Stations](concepts/stations.md) and [Galileo Simulation - §3.8](operations/galileo-simulation.md#38-entry--outbound-tables-te--ts-on-the-tk).
 **MS / TS (Outbound Conveyor / Table de sortie)**
-Station type 10 — the outbound conveyor of a TK/Miniload. Shares the Positions + Stack configuration pattern with ME/TE. FR: TS, ES: MS, EN: Output Conveyor (OC). See [Stations](concepts/stations.md).
+Station type 10 - the outbound conveyor of a TK/Miniload. Shares the Positions + Stack configuration pattern with ME/TE. FR: TS, ES: MS, EN: Output Conveyor (OC). See [Stations](concepts/stations.md).
 **MP / TP (Preparation Zone / Table de préparation)**
-Station type 16. Preparation tables linked to a picking station (PK) where operators deposit picked stock. Routes: **Manual** PK → MP, **Galileo** MP → outbound table, **Virtual** MP → consolidation. Assignment mode (Automatic / Manual) set via **Menu → Control → Workstations**. In manual mode, tasks do not generate until the outbound order is assigned to a table. See [Picking — PK/MP setup](concepts/picking.md#pk--mp-setup-and-assignment-mode).
+Station type 16. Preparation tables linked to a picking station (PK) where operators deposit picked stock. Routes: **Manual** PK → MP, **Galileo** MP → outbound table, **Virtual** MP → consolidation. Assignment mode (Automatic / Manual) set via **Menu → Control → Workstations**. In manual mode, tasks do not generate until the outbound order is assigned to a table. See [Picking - PK/MP setup](concepts/picking.md#pk--mp-setup-and-assignment-mode).
 **Miniload (ML / STL / TK)**
-Light-load automated stacker crane used for bins/cases (typically ≤ 50–100 kg per load). Nomenclature: `ML` = Miniload, `B` (post-ML) = Bicolumn, `EPSF` = pelle simple fond (1 charge), `EPDF` = pelle double fond (1 charge, double-depth rack), `ECDF` = courroie double fond (2 charges). Each model drives the TE/TS table configuration in EasyS. See [Mechanical Elements — §4](concepts/mechanical-elements.md#4-miniload-nomenclature-tk--ml).
+Light-load automated stacker crane used for bins/cases (typically ≤ 50–100 kg per load). Nomenclature: `ML` = Miniload, `B` (post-ML) = Bicolumn, `EPSF` = pelle simple fond (1 charge), `EPDF` = pelle double fond (1 charge, double-depth rack), `ECDF` = courroie double fond (2 charges). Each model drives the TE/TS table configuration in EasyS. See [Mechanical Elements - §4](concepts/mechanical-elements.md#4-miniload-nomenclature-tk--ml).
 **Mov (virtual location)**
-System virtual location that temporarily holds a container while it is physically travelling between two stations. Set on movement transition `Generated` → `In progress`; cleared on End with `EndErrorCode=0`. See [Galileo Integration — Task lifecycle](architecture/galileo-integration.md#tasks-vs-movements).
+System virtual location that temporarily holds a container while it is physically travelling between two stations. Set on movement transition `Generated` → `In progress`; cleared on End with `EndErrorCode=0`. See [Galileo Integration - Task lifecycle](architecture/galileo-integration.md#tasks-vs-movements).
 **Manual Action (EasyS)**
-Test-mode checkbox on a picking station in EasyS. When ticked, the container **does not leave automatically** after picking confirmation — the operator must click **Liberate** to release it. Essential for stepping through flows during simulation. See [Galileo Simulation — §7](operations/galileo-simulation.md#7-extract-a-container-from-the-miniload).
+Test-mode checkbox on a picking station in EasyS. When ticked, the container **does not leave automatically** after picking confirmation - the operator must click **Liberate** to release it. Essential for stepping through flows during simulation. See [Galileo Simulation - §7](operations/galileo-simulation.md#7-extract-a-container-from-the-miniload).
 **MT / MTB (Transelevador de paletas)**
 Monocolumn (MT) and Bicolumn (MTB) pallet stacker cranes. Heavy-duty variants of the miniload used for Euro-pallets. See [Mechanical Elements](concepts/mechanical-elements.md).
@@ -505,13 +505,13 @@ Spanish manufacturer and developer of EasyWMS and EasyS. Headquarters in Barcelo
 Go-live event for a project. Pivot moment of [Git Branch Lifecycle](operations/git-branch-lifecycle.md): before MEP the CdP merges `develop`→`master` and deletes `develop`; Hypercare follows on a freshly-recreated `develop`.
 **MSSCODE**
-Internal Mecalux Gitea instance hosting all project repositories. Authentication via SSH key (ed25519) — see [SSH Keys Setup](operations/ssh-keys-setup.md). Cloning via SSH (not HTTPS) is mandatory once the SSH key is configured in Sourcetree.
+Internal Mecalux Gitea instance hosting all project repositories. Authentication via SSH key (ed25519) - see [SSH Keys Setup](operations/ssh-keys-setup.md). Cloning via SSH (not HTTPS) is mandatory once the SSH key is configured in Sourcetree.
 **MOR01 (Manufacturing Order)**
 Inbound ERP message for manufacturing production orders. Triggers stock consumption of components and creation of finished goods. See [Manufacturing](modules/manufacturing.md).
 **Montage sur demande**
-Kit configuration flag (French: "on-demand assembly"). When `YES`, the WMS auto-creates an assembly work order at the integration of an outbound order containing a kit shortage. When `NO`, kit fabrication is only triggered by a manual or ERP-originated WOR — the WMS emits no automatic alert. See [Kits](concepts/kits.md#kit-shortage-handling).
+Kit configuration flag (French: "on-demand assembly"). When `YES`, the WMS auto-creates an assembly work order at the integration of an outbound order containing a kit shortage. When `NO`, kit fabrication is only triggered by a manual or ERP-originated WOR - the WMS emits no automatic alert. See [Kits](concepts/kits.md#kit-shortage-handling).
 **Movirack**
 Mecalux mobile racking system where rack bays slide laterally to open aisles on demand. Five work modes: Manual, Auto, Timing, Autoparking, Autopicking. See [Movirack](modules/movirack.md).
@@ -533,7 +533,7 @@ EasyWMS add-on for carrier integration. Manages deliveries (carrier + consignee)
 ## N
 **NEUT / ROUJE pattern (Split reception)**
-Mecalux France reception split convention. Incoming stock is split between two complementary buffers at reception to enforce picking-vs-reserve separation : `NEUT` (neutral / picking-ready) and `ROUJE` (customs-held / reserve). Combines with four putaway strategies (direct-to-picking, picking + reserve, reserve only, customs-hold). See [Reception](concepts/reception.md#reception-split-strategy).
+Mecalux France reception split convention. Incoming stock is split between two complementary buffers at reception to enforce picking-vs-reserve separation : `NEUT` (neutral / picking-ready) and `ROUJE` (customs-held / reserve). Combines with four putaway strategies (direct-to-picking, picking + reserve, reserve only, customs-hold). See [Reception](concepts/reception.md#reception-split-strategy-mecalux-france-pattern).
 **Negative picking**
 Automatic warehouse picking mode where an empty container is sent to a storage channel; the AS/RS picks the desired stock from the channel into the empty container. Used in LIFO channels. See [Picking](concepts/picking.md).
@@ -588,13 +588,13 @@ Picking mode where the operator picks directly into the final shipping box, elim
 **Pick and Pass**
 Picking mode where multiple operators each pick one zone; the client container passes from operator to operator along a conveyor or route until all lines are complete. See [Picking](concepts/picking.md).
-**PIE station (Punto de Introducción de Entrada — Automatic Inbound Point)**
+**PIE station (Punto de Introducción de Entrada - Automatic Inbound Point)**
 The entry point of an automated warehouse. Validates dimensions, weight, and identity of incoming containers. Routes valid containers inward; rejects non-conforming containers to a rejection station. On the GALILEO side, the PIE is seen as a standalone station whose events trigger the `Galileo_PIEEventHandler_PR` workflow on EasyWMS. See [Stations](concepts/stations.md), [GALILEO Integration](architecture/galileo-integration.md) and [Reception](concepts/reception.md).
 **PK conveyor / PK station (Picking conveyor)**
 A picking workstation on the conveyor system. Operators work at a PC; containers arrive on the conveyor and are processed (picked, received, consolidated, counted) before continuing on the conveyor. PK station capacity is given per-route (unlike miniload TKs which give capacity per-station). See [Stations](concepts/stations.md) and [GALILEO Integration](architecture/galileo-integration.md).
-**PKE station (Punto de Extracción de Salida — Picking Extraction Point)**
+**PKE station (Punto de Extracción de Salida - Picking Extraction Point)**
 Extraction point *from* a picking workstation, used on a "full" PK→PKE route for robotics simulation tests. Pairs with an ME (Manual Entry) target. See [Galileo Simulation](operations/galileo-simulation.md) and [Robotics Project Lifecycle](operations/robotics-project-lifecycle.md).
 **PLC (Programmable Logic Controller)**
@@ -625,14 +625,14 @@ Illuminated display devices mounted at picking locations. Guide operators during
 See **PTL**. Variant of PTL picking where devices are mounted on both shelves and equipment. See [Configuration Guide](operations/configuration-guide.md).
 **ProductConversion (OutboundLine)**
-Optional attribute of a shipping order line — can be `null` when the order specifies a container code but no item (e.g. a request for a specific support without product). Code review enforces a null-check. See [Code Review Process](operations/code-review-process.md).
+Optional attribute of a shipping order line - can be `null` when the order specifies a container code but no item (e.g. a request for a specific support without product). Code review enforces a null-check. See [Code Review Process](operations/code-review-process.md).
 ---
 ## Q
 **Poids balance / Poids calculé / Poids réel / Poids théorique (article) / Poids théorique (balance)**
-The five container-level weight fields tracked by the WMS. *"Poids théorique"* is ambiguous in French — always disambiguate between **article** (from item master) and **balance** (from scale minus adjustments). See [Weights](concepts/weights.md).
+The five container-level weight fields tracked by the WMS. *"Poids théorique"* is ambiguous in French - always disambiguate between **article** (from item master) and **balance** (from scale minus adjustments). See [Weights](concepts/weights.md).
 **Quality lock**
 A stock status applied to specific stock to block one or more operations (picking, replenishment, shipping, counting). Two subtypes: **receiving status** (applied at reception) and **user status** (applied manually or via ERP). See [Quality Control](concepts/quality-control.md).
@@ -648,7 +648,7 @@ One of three EasyWMS API families. Executes LINQ-based queries against Views or
 Manufacturing module recipe types: `RCP01` = standard manufacturing recipe (components → finished good); `RCP02` = quartering recipe (split one item into portions). See [Manufacturing](modules/manufacturing.md).
 **REAC station (Reactivation)**
-Pallet Shuttle charging station variant — reactivates/charges a PS cart. See [Stations](concepts/stations.md).
+Pallet Shuttle charging station variant - reactivates/charges a PS cart. See [Stations](concepts/stations.md).
 **Receipt**
 A WMS document that records the physical receipt of stock (containers and/or loose stock) within a reception session. Multiple receipts can be created against the same receipt order. Receipt is distinct from receipt order. See [Reception](concepts/reception.md).
@@ -684,13 +684,13 @@ Handheld or vehicle-mounted barcode scanning terminal used by warehouse operator
 Outbound ERP message. Sent when a receipt order changes status (opened, partially received, closed). See [ERP Interface](concepts/erp-interface.md).
 **Real Weight (Poids réel)**
-Container weight field computed as `max(Calculated Weight, Theoretical Scale Weight)`. Acts as the "best known" weight — theoretical when no PIE pass has occurred, scale-derived once it has. Reported on shipping documents. See [Weights](concepts/weights.md).
+Container weight field computed as `max(Calculated Weight, Theoretical Scale Weight)`. Acts as the "best known" weight - theoretical when no PIE pass has occurred, scale-derived once it has. Reported on shipping documents. See [Weights](concepts/weights.md).
 **ROF (Receipt Order Fulfilled)**
-Outbound ERP message. Sent when a receipt order is fully fulfilled (all lines received). Two variants: `ROF01` (standard) and `ROF02` (extended line-level detail — used when the inbound order was generated from a `Transfer` shipping order in the two-warehouse flow, and for returns). See [ERP Interface](concepts/erp-interface.md).
+Outbound ERP message. Sent when a receipt order is fully fulfilled (all lines received). Two variants: `ROF01` (standard) and `ROF02` (extended line-level detail - used when the inbound order was generated from a `Transfer` shipping order in the two-warehouse flow, and for returns). See [ERP Interface](concepts/erp-interface.md).
 **Routine (replenishment)**
-French SmartUI label for the **Stockout / threshold-based** replenishment strategy — triggers when the picking location drops below its configured minimum. See [Replenishment](concepts/replenishment.md).
+French SmartUI label for the **Stockout / threshold-based** replenishment strategy - triggers when the picking location drops below its configured minimum. See [Replenishment](concepts/replenishment.md).
 **ROR (Receipt Order Request)**
 Inbound ERP message. Creates a receipt order in EasyWMS. Multiple variants for supplier receipts, ASN pre-notifications, returns, and transfers. See [ERP Interface](concepts/erp-interface.md).
@@ -706,13 +706,13 @@ Inbound ERP message. Creates or updates a shipping route in EasyWMS. See [ERP In
 ## S
 **SAC (Stock Analysis Classification)**
-Outbound ERP message (`SAC01`) sent manually from SmartUI after running the ABC rotation analysis. Carries item code + suggested ABC class. The ERP uses it to update item classification. Not automatic — the WMS operator must explicitly trigger it. See [ERP Interface](concepts/erp-interface.md#module-specific-erp-messages).
+Outbound ERP message (`SAC01`) sent manually from SmartUI after running the ABC rotation analysis. Carries item code + suggested ABC class. The ERP uses it to update item classification. Not automatic - the WMS operator must explicitly trigger it. See [ERP Interface](concepts/erp-interface.md#module-specific-erp-messages).
 **SaaS (Software as a Service)**
 Cloud-hosted deployment of EasyWMS on Amazon infrastructure. Includes VPN requirements, SaaS-specific API endpoints, and Amazon SaaS certification for mobile apps (Android 10 requirement for Marketplaces). See [System Architecture](architecture/overview.md).
 **SCADA (Supervisory Control And Data Acquisition)**
-Supervision UI layer of the automation installation. In Mecalux robotics, SCADA is distinct from both GALILEO (TMS logic) and EasyWMS (business logic) — it shows the physical machine state to operators and maintenance teams. See [GALILEO Integration](architecture/galileo-integration.md).
+Supervision UI layer of the automation installation. In Mecalux robotics, SCADA is distinct from both GALILEO (TMS logic) and EasyWMS (business logic) - it shows the physical machine state to operators and maintenance teams. See [GALILEO Integration](architecture/galileo-integration.md).
 **SCEM (Supply Chain Event Management)**
 EasyWMS module for real-time event notification. Users subscribe to notification events and receive alerts via web, email, or SMS. See [Supply Chain Event Management](modules/supply-chain-event.md).
@@ -739,7 +739,7 @@ Spanish acronym for WMS. Used interchangeably with WMS in Mecalux Spain-originat
 EasyWMS's web-based user interface (browser). Used by supervisors and managers for administration, monitoring, and configuration. Distinct from RFT (handheld terminal) screens. See [System Architecture](architecture/overview.md).
 **Station update / Route update (GALILEO)**
-Two status streams GALILEO pushes to EasyWMS roughly every 1–3 seconds. They carry real-time physical state (station busy/free, route status, movement progress) and are written in the Gateway log. Not `Event` messages — they do not trigger workflows, only update state. See [GALILEO Integration](architecture/galileo-integration.md) and [Galileo Troubleshooting](operations/galileo-troubleshooting.md).
+Two status streams GALILEO pushes to EasyWMS roughly every 1–3 seconds. They carry real-time physical state (station busy/free, route status, movement progress) and are written in the Gateway log. Not `Event` messages - they do not trigger workflows, only update state. See [GALILEO Integration](architecture/galileo-integration.md) and [Galileo Troubleshooting](operations/galileo-troubleshooting.md).
 **SOC (Shipping Order Confirmation)**
 Outbound ERP message. Sent when a shipping order changes status (released, prepared, in progress, completed). See [ERP Interface](concepts/erp-interface.md).
@@ -763,7 +763,7 @@ GS1-standard 18-digit numeric identifier for a logistics unit (LPN). The default
 Transaction prefix for stock-level events. Key types: `STK.RECEP` (received), `STK.MOVE` (moved), `STK.ADJ` (adjusted), `STK.PICK` (picked), `STK.SHIP` (shipped), `STK.REP` (replenished), `STK.MAN.PRODUCTION` (manufacturing). See [Transactions](concepts/transactions.md).
 **SSCC prefix (change)**
-Changing the SSCC prefix sequence is done in **EasyS** (the configurator). Open the warehouse, **double-click the warehouse name** to expose the SSCC/numbering panel, adjust the prefix and/or sequence number, save. Has no effect on already-created containers. See [Container](concepts/container.md#changing-the-sscc-sequence-prefix).
+Changing the SSCC prefix sequence is done in **EasyS** (the configurator). Open the warehouse, **double-click the warehouse name** to expose the SSCC/numbering panel, adjust the prefix and/or sequence number, save. Has no effect on already-created containers. See [Container](concepts/container.md#changing-the-sscc-prefix).
 **Stock assignment**
 The allocation engine that decides which concrete stock lines fulfil each outbound order line detail, and which task type (picking, shipping, replenishment, virtual picking) will be created. Built around the `StockAssignProcess_*` workflows. See [Stock Assignment](concepts/stock-assignment.md).
@@ -794,13 +794,13 @@ A logical partition of a warehouse with independent stock management rules. Item
 Container weight field computed as *Scale Weight − adjustments*. Initialised after the first PIE pass, then adjusted by subsequent stock moves. Input to Real Weight. See [Weights](concepts/weights.md).
 **Theoretical Weight (Poids théorique article)**
-Container weight field computed as *item-master unit weight × quantity + container tare*. Set at creation and on every adjustment. Note : the container tare is **frozen at creation** — changing the pallet-type weight in EasyS does not propagate. See [Weights](concepts/weights.md).
+Container weight field computed as *item-master unit weight × quantity + container tare*. Set at creation and on every adjustment. Note : the container tare is **frozen at creation** - changing the pallet-type weight in EasyS does not propagate. See [Weights](concepts/weights.md).
 **Transit buffer (intermediate buffer)**
-EasyS element of type **Transport** whose sub-location is a **Buffer** (not Automatic) used to bridge two sub-warehouses served by different equipment groups. Pattern: reserve-equipment drops on the buffer, picking-equipment picks up. Critical detail: the sub-location is created as `Automatic` by default and must be manually changed to `Buffer`. See [Location](concepts/location.md#transit-buffer-between-sub-warehouses) and [Replenishment](concepts/replenishment.md#inter-sub-warehouse-replenishment-via-intermediate-buffer).
+EasyS element of type **Transport** whose sub-location is a **Buffer** (not Automatic) used to bridge two sub-warehouses served by different equipment groups. Pattern: reserve-equipment drops on the buffer, picking-equipment picks up. Critical detail: the sub-location is created as `Automatic` by default and must be manually changed to `Buffer`. See [Location](concepts/location.md#transit-buffer-between-sub-warehouses) and [Replenishment](concepts/replenishment.md#inter-sub-warehouse-replenishment-via-an-intermediate-buffer).
 **Transfer (SorType)**
-Shipping order type for inter-warehouse transfers with a **reciprocal inbound order** at the destination. Unlike `DirectTransfer` (which only raises an ASN via ASO), `Transfer` creates a full ROR at destination carrying the source SOR reference ; the destination ROF02 (on close) reconciles the source. See [Order Outbound](concepts/order-outbound.md#transfer-two-warehouse-flow) and [ERP Interface](concepts/erp-interface.md).
+Shipping order type for inter-warehouse transfers with a **reciprocal inbound order** at the destination. Unlike `DirectTransfer` (which only raises an ASN via ASO), `Transfer` creates a full ROR at destination carrying the source SOR reference ; the destination ROF02 (on close) reconciles the source. See [Order Outbound](concepts/order-outbound.md#transfer---two-warehouse-flow-inbound-order-created) and [ERP Interface](concepts/erp-interface.md).
 **Task**
 The atomic unit of work in EasyWMS. A task represents a single movement (container or stock from location A to location B). Tasks belong to a process (putaway, picking, replenishment, count, etc.) and follow a lifecycle: Pending → Generated → In Process → Finished/Canceled. See [Task](concepts/task.md).
@@ -814,8 +814,8 @@ French term for a carrier route. Integrated from a TMS via the `RUT` inbound ERP
 **TK (Transstockeur / Stacker crane)**
 Spanish/French term for a stacker crane serving a single miniload aisle. In GALILEO stations, a TK is seen as one station per miniload (capacity = number of container slots held on its forks). Opposite: a TKB is a bicolumn (double) miniload. See [Mechanical Elements](concepts/mechanical-elements.md) and [Stations](concepts/stations.md).
-**TMS (Transport Management System — two meanings)**
+**TMS (Transport Management System - two meanings)**
-Two distinct usages in EasyWMS docs: (1) **Robotics TMS**: GALILEO (production) or EasyS (simulator), which physically drives conveyors, stacker cranes and shuttles — see [GALILEO Integration](architecture/galileo-integration.md). (2) **Carrier TMS**: external carrier-booking software, integrates via Yard Management and Multi-Carrier.
+Two distinct usages in EasyWMS docs: (1) **Robotics TMS**: GALILEO (production) or EasyS (simulator), which physically drives conveyors, stacker cranes and shuttles - see [GALILEO Integration](architecture/galileo-integration.md). (2) **Carrier TMS**: external carrier-booking software, integrates via Yard Management and Multi-Carrier.
 **Tracking (GALILEO)**
 On the GALILEO side, a "tracking" is the live movement object (container + target station + progress). EasyWMS creates a tracking via the `GalileoMovTrackingCreateCommand` when it decides where a container should go; the tracking closes when GALILEO sends back an **End** message. Distinct from a WMS **task**, which may span multiple trackings. See [GALILEO Integration](architecture/galileo-integration.md).
@@ -847,7 +847,7 @@ Continuous maintenance team that delivers complementary "offers" via `release` b
 The measurement unit for an item (piece, kilogram, liter, meter, etc.). EasyWMS supports multiple UoMs per item with conversion factors. The base UoM is used for all internal calculations; presentation UoMs are used at reception and picking. See [Product / Item](concepts/product-item.md).
 **UserImagesURI**
-Setting in the WMS `appsettings.json` that specifies the filesystem folder resolved for item pictures transmitted via `ITM01 <ItmPicture>filename.jpg</ItmPicture>`. Typical value: `C:/MLX/Data/Pictures/`. The WMS service account must have read access. See [ERP Interface](concepts/erp-interface.md#itm--image-fields).
+Setting in the WMS `appsettings.json` that specifies the filesystem folder resolved for item pictures transmitted via `ITM01 <ItmPicture>filename.jpg</ItmPicture>`. Typical value: `C:/MLX/Data/Pictures/`. The WMS service account must have read access. See [ERP Interface](concepts/erp-interface.md#itm---image-fields).
 **uGNA / uGNAConsole**
 Mecalux command-line utility (`C:\Program Files (x86)\Mecalux\uGNA\uGNAConsole.exe`) used to export the WMS configuration / master data / parameters to XML files (option `-Z:<entities>`). Output is committed to the project Git in `..\test`. Distinct from the GNA service (interfacing layer). See [uGNA Data Export](operations/ugna-data-export.md) and [GNA, Services & License](operations/gna-services-license.md).
@@ -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]
+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-05-13
+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
+> **Priorité CstAtt01 (répartition uniquement)** : si CstAtt01 a déjà une
-> précédente), c'est ce poids unitaire qui est utilisé comme référence
+> valeur (pesée précédente), c'est ce poids unitaire qui est utilisé pour
-> pour **tous les calculs du passage PIE** — ratio (étape 2) **et**
+> la **répartition au prorata** (étape 2), à la place du poids ITM.
-> seuil de tolérance (vérification ci-dessous) — à la place du poids
+>
-> théorique 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
+Ref. [LIM-66](https://easywmsfrance.atlassian.net/browse/LIM-66) - **en
-revue de code.
+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
+> ⚠️ **Décision finale (19/06/2026)** : le seuil de tolérance utilise
-la même règle de priorité que le ratio :
+> **toujours le poids unitaire ITM théorique** (conversion article), quel
 > que soit l'état de CstAtt01.
-| Situation | Poids de référence utilisé |
+| Situation | Poids de référence pour le seuil |
-|-----------|---------------------------|
+|-----------|----------------------------------|
-| CstAtt01 renseigné (pesée précédente) | **CstAtt01** (poids unitaire mesuré) |
+| Premier passage PIE **et** passages suivants | **Poids ITM** (conversion article) |
 | CstAtt01 vide (premier passage PIE) | **Poids ITM** (conversion article) |
-**Conséquence sur les passages successifs** : après un premier passage
+**Historique de la décision** : une première approche (mai 2026, validée
-PIE qui recalibre le poids unitaire (ex. ITM = 10 kg, mesuré = 30 kg),
+client) prévoyait un seuil **dynamique** basé sur CstAtt01 (dernier poids
-le seuil de tolérance au passage suivant sera basé sur 30 kg (CstAtt01).
+mesuré) si renseigné, sinon ITM. Elle a été **abandonnée le 19/06/2026** :
-Un écart de 20 kg (2 unités au poids ITM d'origine) ne déclenchera pas
+si une pesée très erronée fixe un CstAtt01 aberrant, comparer les pesées
-de blocage car il reste inférieur à 1 unité au poids recalibré (30 kg).
+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
+unitaire **ITM** de l'article) → blocage via verrou sur le **support**
-le **support** (pas sur le stock) + alerte SmartUI.
+(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
+utilise le **plus petit poids unitaire ITM** parmi toutes les lignes de
-renseigné, sinon ITM, par ligne) comme seuil d'alerte. Si l'écart
+stock comme seuil d'alerte. Si l'écart total ≥ ce plus petit poids →
-total ≥ ce plus petit poids → blocage + alerte.
+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
+- La notification SmartUI custom envisagée initialement a été
-  notifications basé sur un event (pas d'event custom)
+  **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
+⚠️ Le seuil de tolérance est basé sur le poids **ITM théorique** (fixe),
-10 kg → CstAtt01 30 kg), le seuil de tolérance au passage suivant
+pas sur CstAtt01 (décision 19/06/2026). CstAtt01 sert uniquement à la
-est proportionnellement plus large. C'est le comportement attendu :
+répartition au prorata et à l'inventaire par pesée, et n'influence plus
-chaque pesée fait foi pour la suivante.
+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
+- **Résolu (19/06/2026)** - Tolérances : le seuil est finalement basé sur
-  le client (mai 2026). Pas de valeur fixe par type article.
+  le poids **ITM théorique** (fixe). L'approche dynamique CstAtt01 > ITM
- [ ] Valeur du poids palette bois fixe (PALETTE_US) (@Théo)
+  (validée client mai 2026) a été abandonnée.
- [ ] Poids variable — vérifier si le standard gère la capture de
+- **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 |
+| [LIM-66](https://easywmsfrance.atlassian.net/browse/LIM-66) | Ticket Jira (PIE poids/verrous - pré-production) | 2026 |
-| Échange Justine BEUTIN / Olivier (Limagrain) | Validation client | mai 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"
+title: "Étiquette support RFID - Mono-référence & Multiréférence"
-tags: [inbound, outbound, RFID, étiquette, ZPL, GS1, support]
+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]
+sources: ["Jira LIM-68 (lecture directe)", "CR réunion évolution encodage RFID 2026-07-06"]
-last_updated: 2026-05-12
+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
+> **Résumé** : étiquette support (HU) imprimée et encodée RFID via ZPL,
-> fournisseur/intersite, contenant les informations du support (code,
+> dans deux flux - réception fournisseur/intersite et étiqueteuse
-> article, lot, GTIN) avec un QR Code GS1 et un encodage RFID via ZPL.
+> 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
+Le client Limagrain veut un rapport d'étiquette personnalisé pour ses HU
-ses HU (supports) dans le flux de réception fournisseur/intersite.
+(supports). L'étiquette est produite dans deux flux :
 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 »).
-Ref. [LIM-68](https://easywmsfrance.atlassian.net/browse/LIM-68) —
+- **Réception fournisseur/intersite** : impression automatique à la
-attente déploiement pour test.
+  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,
+Pour une palette multiréférence (contenu hétérogène), le rapport se limite à
-codes-barres) et l'encodage de la puce RFID intégrée, le tout via
+**imprimer et encoder le code SSCC** du support - aucun détail article/lot.
-des commandes **ZPL** (Zebra Programming Language).
+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
+- L'imprimante doit être **compatible ZPL** avec encodage RFID (choix
-  (contrainte fournisseur à valider — voir question ouverte dans
+  fournisseur à valider - voir
-  [Réception fournisseur](reception-fournisseur.md))
+  [questions ouvertes](../08-transverse/questions-ouvertes.md))
- Le code support encodé en RFID fait **18 caractères** (5 blocs de
+- Code conteneur RFID = **18 caractères** (limite dure du nouvel encodage
-  4 octets = 20 octets en banque User 3)
+  7 bits : 18 × 7 = 126 bits ≤ 128)
- L'étiquette est au format **A5 paysage**
+- Étiquette mono-référence au format **A5 paysage** ; date (champ 11)
- La date (champ 11) est volontairement vide car non connue de l'ERP
+  volontairement vide (non connue de l'ERP en réception)
-  au moment de la 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]
+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-05-06
+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
+(ViewDetailPanel dans la vue `ReceptionVList`). Il sélectionne la réception,
-assigne un quai réel.
+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
+- Le quai et l'image de quai (faux stage) sont réservés dès la sélection
- Un quai partiellement occupé peut être réutilisé (gestion manuelle de la
+- Un quai / une image de quai partiellement occupé peut être réutilisé
-  place restante)
+  (gestion manuelle de la place restante)
- ~~Blocage si flux différent (ex : expédition)~~ — supprimé
+- ~~Blocage si flux différent (ex : expédition)~~ - supprimé
- Si aucun quai disponible → l'opérateur conserve `PARKING` et attend une
+- Si aucune image de quai disponible → l'opérateur conserve `PARKING` et attend
-  libération
+  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
+> **Statut Jira (16/07/2026)** : En cours de test client (pré-production).
-sur le parking les quais assignés avec les plaques d'immatriculation.
+> 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
+- Afficher uniquement les quais ayant des réceptions ou OS associés
- Prévoir l'affichage de **6 quais + le parking** sans scroll
+- 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
+- **Production / Pile de palette** : type → image de quai → nombre →
- **Autres** (fournisseur, intersite, retours) : écrans 1, 2, 3, 4, 5, 6, 7
+  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"
+> **Statut Jira (16/07/2026)** : En cours de test client (pré-production).
-(pas pour la 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 |
+| `ReceptionVList` | ViewDetailPanel `CST_Docks_Workload` (Column Span = 2) - occupation quais |
-| `VAssistCreateReceptionOE` | Exception steps 2 et 3 — blocage classes OE différentes |
+| `VAssistCreateReceptionOE` | Exception steps 2 et 3 - blocage classes OE différentes |
-| `VAssistReceptionAssignDock` | Step 1 : entité `CST_DockStationsWorkloadForView` remplace `Station` |
+| `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-62](https://easywmsfrance.atlassian.net/browse/LIM-62) | Ticket Jira (V1 - Annulé, suite LIM-97) | 18/02/2026 |
-| [LIM-63](https://easywmsfrance.atlassian.net/browse/LIM-63) | Ticket Jira | 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-64](https://easywmsfrance.atlassian.net/browse/LIM-64) | Ticket Jira | 2026 |
+| [LIM-63](https://easywmsfrance.atlassian.net/browse/LIM-63) | Ticket Jira (affichage chauffeurs - pré-production) | 2026 |
-| [LIM-65](https://easywmsfrance.atlassian.net/browse/LIM-65) | Ticket Jira | 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"]
+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-05-12
+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
+> Règle : un SSCC n'est généré que si le ROR ne fournit **aucun** code
-> endommagée.
+> 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
+Ref. [LIM-67](https://easywmsfrance.atlassian.net/browse/LIM-67) - revue
-attente CDP.
+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
+Le process démarre par le **scan du conteneur virtuel** posé sur le
-écran de confirmation crée le nouveau support « réel ». Sur cet écran :
+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
+- `AutoCloseReception = true` - le WMS clôture automatiquement la
-  réception quand les conditions custom sont remplies (§ Déclenchement)
+  réception quand les conditions custom sont remplies (§ Déclenchement).
- `AutoCloseInboundOrder = true` — à la clôture de la réception, chaque
+  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
+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
+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
+- [CUSTOM] **Zone de stockage** dans le champ **`LneStockCstAtt01`**
-  du support) :
+  (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)
+- ❓ Gestion TRF si AGV pas prêts au démarrage (@Théo)
- [ ] Utilisation du ROC (confirmation de réception) — point interne
+- ❓ 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
+- [x] ~~WF clôture OE : faut-il modifier le WF existant ou en créer
-  un nouveau pour la condition CstAtt01 ? (@Fabien) (LIM-73)
+  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-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) | 2026 |
+| [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"]
+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-05-13
+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) |
+| 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é) | — |
+| 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 | — |
+| 6 | Stockage ou rejet | - |
-| 7 | Clôture de la réception | — |
+| 7 | Clôture de la réception | - |
-| 8 | Libération quai / image de quai | — |
+| 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
+Lors du scan du lot officiel sur le poste de travail, le WMS appelle
-d'abord si le lot est connu localement. Si oui, pas d'appel API. Sinon :
+**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 ?}
+    A[Scan / saisie lot officiel] --> D[Appel API SAP ATH214<br/>SYSTÉMATIQUE<br/>IV_BATCH_OFF + IV_RETURN]
-    B -- Oui --> C{Vendu par Limagrain ?}
+    D --> R{EV_RETURN = X ?}
-    B -- Non --> D[Appel API SAP]
+    R -- Non --> Z[Erreur SAP<br/>afficher ET_RETURN]
-    D --> E[Écran attente<br/>refresh 5s / timeout 1 min]
+    R -- Oui --> C{Au moins un<br/>ZDEPLOY = X ?}
-    E --> F{ITM reçu via API WMS ?}
+    C -- Non --> K[Erreur : lot non vendu<br/>par Limagrain]
-    F -- Oui --> C
+    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 ?}
+    F -- Oui --> J
-    C -- Non --> K[Erreur : lot non vendu<br/>par Limagrain]
+    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
+**Traitement de la réponse (V2) :**
 > les échanges — `EV_DEPLOY` ou `ZDEPLOY` ? En attente de clarification
 > (question A2 dans
 > [Questions ouvertes](../08-transverse/questions-ouvertes.md)).
-Si `EV_RETURN = "X"`, on récupère dans `ET_BATCH` tous les
+1. Si `EV_RETURN = ""` → afficher le message d'erreur de `ET_RETURN`
-`BATCH_OFF` dont `EV_DEPLOY = "X"` — ce sont les lots autorisés
+   à l'opérateur
-pour 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
+entrées avec `ZDEPLOY = "X"`), le dialogue `CST_EtBatchSelector` est
-affiché avec la liste des codes lots disponibles. L'opérateur en choisit
+affiché avec la liste des lots SAP disponibles. L'opérateur en choisit un.
 un (filtrage par pays d'origine).
-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
+```text
-articles (dépend du pays d'origine). L'opérateur doit choisir l'article
+VAR_DESC - COM_TRT_DESC - DESTINATION (MATNR)
-physiquement présent sur la palette.
+```
 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 |
+| 2 | Big bag (CstAtt02) | Identique - toggle ON/OFF |
-| 3 | Scan lot officiel + vérification | **+ Vérification API SAP** (voir section ci-dessus) |
+| 3 | Scan lot officiel + vérification | **+ Vérification API SAP systématique** (voir section ci-dessus) |
-| 4 | Déclaration quantité | Identique — affichage qté attendue + UdM, prompt non pré-rempli |
+| 4 | Statut de stock | **Étape dédiée AVANT la quantité** (V2) - dialogue avec statut fictif « Stock conforme » en tête (voir ci-dessous) |
-| 4bis | Flag big-bag (bouton custom) | Identique (CstAtt02) |
+| 5 | Déclaration quantité | Identique - affichage qté attendue + UdM, prompt non pré-rempli. Bouton statut supprimé (ESC renvoie au dialogue statut) |
-| 5 | Statut de stock | **Modifiable** — boutons visibles (masqués dans LIM-67) |
+| 5bis | Flag big-bag (bouton custom) | Identique (CstAtt02) |
-| 6 | Flag "À anoxier" | Identique (CstAtt03 = true) |
+| 6 | Attributs logistiques | **Auto-validés si présents/uniques dans le ROR**, sinon demandés (voir ci-dessous) |
-| 7 | Programme de filmage | Identique (paramètre FILMAGES → CstAtt05) |
+| 7 | Flag "À anoxier" | Identique (CstAtt03 = true) |
-| 8 | Impression étiquette RFID | Identique ([LIM-68](https://easywmsfrance.atlassian.net/browse/LIM-68)) |
+| 8 | Programme de filmage | Identique (paramètre FILMAGES → CstAtt05) |
-| 9 | Validation → évacuation AGV | Identique |
+| 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
+- Un dialogue liste les statuts autorisés en retour
- L'opérateur peut modifier le statut (ex : Conforme, Sac sale,
+  (query `CST_StockStatus_AllowedForReturn`, CstAtt1 = applicable en
-  Non conforme, etc.)
+  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 »
+- Verrou si écart poids : **« ECART RETOUR »** (vs « HORS TOLERANCE »
-  pour les autres flux) — verrou posé sur le **support** (pas sur
+  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) |
+| 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 |
+| 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 |
+| 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 =
+| Élément | Type | Rôle |
-  ZLOG, CstAtt 3 = ZINCO
+|---------|------|------|
- Query `CST_StockStatus_AllowedForReturn` : filtre statuts autorisés
+| `CST_Reception_GetReceptionFromContainer` | WF | Si aucune réception trouvée pour le conteneur, recherche un **retour** au code correspondant ; si trouvé → `returnMode = true` |
- Workflow `CST_Return_Stock_GetStatus_UI` : sélection statut simplifié
+| `Reception_Supplier_ChooseReception_UI` | WF/UI | Ajout du paramètre formel `CST_ReturnMode` |
- Workflow `Reception_FilterLinesByProductAndContainer_UI_V1` : retrait
+| `WorkStation_Reception_Supplier_UI` | WF/UI | Ajout de l'attribut `CST_ReturnMode` |
-  filtre quantité (tolérance illimitée)
+| `WorkStation_Reception_Supplier_ConfirmReceivedStock_UI` | WF/UI | Si retour → création du stock via une **commande différente** |
- Dialog `CST_GetProductQuantity_Prompt` : option SelectStatus ajoutée
+| `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
+> **Statut** : préprod / test client. Revue de code terminée (03/06,
- Écran d'attente ITM (polling alias 5s, timeout 1 min, 5 tentatives)
+> après une première itération NOK 02/06 : commentaires `// Custom`
- Dialogue choix multi-lot (quand ET_BATCH contient plusieurs articles)
+> manquants sur `REF01.boo` / `REF01Observer.boo`).
- Impression étiquette stock retour client (rapport custom à créer)
+
- Configuration flux de rejet PIE retours (verrou ECART RETOUR,
+Custom du message REF + GNA pour remonter à SAP le **statut de stock**
-  destination, notification)
+(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
+⚠️ Endpoint CPI unique `/http/ATHInboundMessage` avec `MessageType =
-unique `/http/ATHInboundMessage`, pas vers `/api/v1/lot/verify`.
+"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.
+⚠️ 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
-⚠️ Pour les lots **déjà connus** en base WMS, le flag "déployé" n'est
+trou fonctionnel A4 est fermé.
 pas vérifié dans le design actuel — trou fonctionnel identifié (question
 A4 dans [Questions ouvertes](../08-transverse/questions-ouvertes.md)).
 ## Questions ouvertes
- [ ] Champs manquants ET_BATCH : description article, pays destination,
+- [x] ~~Champs manquants ET_BATCH : description article, pays destination,
-  propriétaire (@Vincent Goyet) — A1
+  propriétaire - A1~~ → Résolu : `DESCRIPTION`, `DESTINATION`, `OWNER`
- [ ] Nom final champ déploiement : EV_DEPLOY ou ZDEPLOY ?
+  ajoutés, plus `VAR_DESC` (variété) et `COM_TRT_DESC` (traitement
-  (@Vincent Goyet) — A2
+  commercial)
- [ ] Délai ATH214 → push ITM dimensionnement polling
+- [x] ~~Nom final champ déploiement : EV_DEPLOY ou ZDEPLOY ? - A2~~ →
-  (@Vincent Goyet) — A3
+  Résolu : `ZDEPLOY` (confirmé V2)
- [ ] Vérification "déployé" pour lots déjà connus sans ATH214
+- [x] ~~Délai ATH214 → push ITM dimensionnement polling - A3~~ → Résolu :
-  (@Vincent Goyet) — A4
+  polling 5000 ms, timeout 60 s, 5 tentatives (paramétrés)
- [ ] Étiquette stock retour : format, champs, imprimante
+- [x] ~~Vérification "déployé" pour lots déjà connus sans ATH214 - A4~~ →
-  (@Leila / @Antoine) — B1
+  Résolu : appel ATH214 systématique
- [ ] Flux rejet PIE retour : destination, notification, actions
+- [x] ~~Étiquette stock retour : format, champs, imprimante - B1~~ →
-  (@Leila / @Antoine) — B2
+  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 |
+| [LIM-72](https://easywmsfrance.atlassian.net/browse/LIM-72) | Ticket Jira (V1, Annulé) | 2026 |
-| Jira LIM-73 | Ticket | 2025 |
+| [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 |
@@ -1,11 +1,11 @@
 ---
-title: "Stockage — Vue d'ensemble"
+title: "Stockage - Vue d'ensemble"
 tags: [stockage, asrs, galileo, index]
 status: draft
 last_updated: 2026-05-05
 ---
-# Stockage — Vue d'ensemble
+# Stockage - Vue d'ensemble
 > **Périmètre** : miniload, transstockeurs, stations Galileo, stratégies de
 > putaway, zones de stockage, défragmentation.
@@ -22,6 +22,7 @@ last_updated: 2026-05-05
 - [Défragmentation](defragmentation.md)
 - [Processus d'anoxie](processus-anoxie.md)
 - [Gestion des palettes vides](palettes-vides.md)
 - [Flux de rejet PIE](rejet-pie.md)
 ## Vue synthétique du stockage Limagrain
@@ -1,5 +1,5 @@
 ---
-title: "ASRS — Entrepôt automatique Limagrain"
+title: "ASRS - Entrepôt automatique Limagrain"
 tags: [stockage, ASRS, transstockeur, racks, emplacements]
 status: draft
 standard_ref: architecture/galileo-integration.md
@@ -10,7 +10,7 @@ last_updated: 2026-05-05
 author: Arthur
 ---
-# ASRS — Entrepôt automatique Limagrain
+# ASRS - Entrepôt automatique Limagrain
 > **Résumé** : description de l'installation automatique Limagrain : 4 allées
 > de transstockeurs, racks multi-profondeur, nomenclature des emplacements,
@@ -31,7 +31,7 @@ graines (sacs, big-bags) sur palettes US.
 | Code | Description |
 |------|-------------|
 | **LM** | Organisation LIMAGRAIN |
-| **MAG01** | Magasin automatique — 4 allées |
+| **MAG01** | Magasin automatique - 4 allées |
 ## Racks et capacités
@@ -48,8 +48,8 @@ Format : **AAAXXXYYYS(D)**
 | Code | Nb caractères | Description |
 |------|---------------|-------------|
 | AAA | 3 | Nom de l'allée (001–004) |
-| XXX | 3 | Coordonnée X — travée le long de l'allée |
+| XXX | 3 | Coordonnée X - travée le long de l'allée |
-| YYY | 3 | Coordonnée Y — hauteur dans la travée |
+| YYY | 3 | Coordonnée Y - hauteur dans la travée |
 | S | 1 | Côté de l'allée (1 = gauche, 2 = droite) |
 | D | 1 | Profondeur (1 = premier, 2 = second, ...) |
@@ -63,7 +63,7 @@ profondeur 1.
 | Type | Largeur (mm) | Longueur (mm) | Hauteur (mm) | Poids max (kg) |
 |------|--------------|---------------|--------------|----------------|
-| 1 — Palette US | 1000 | 1200 | 800 à 1900 | 1250 |
+| 1 - Palette US | 1000 | 1200 | 800 à 1900 | 1250 |
 ## Contrôles au PIE
@@ -1,16 +1,16 @@
 ---
-title: "Défragmentation — Zone client et ordonnancement par tournée"
+title: "Défragmentation - Zone client et ordonnancement par tournée"
 tags: [stockage, défragmentation, expédition, zone-client, planning, tournée, STOP, custom]
 status: draft
 standard_ref: concepts/defragmentation.md
 jira_refs: [LIM-85, LIM-87]
 confluence_refs: []
 sources: [FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5.docx, "LIM-85 LOT2.1 Configuration stratégies defragmentation du stock client par tournée.md", "LIM-87 LOT2.1 [TOURNÉES] Défragmentation client - quai non assigné ATTENTE_CLIENT CT-13.md"]
-last_updated: 2026-05-12
+last_updated: 2026-07-17
 author: Arthur
 ---
-# Défragmentation — Zone client et ordonnancement par tournée
+# Défragmentation - Zone client et ordonnancement par tournée
 > **Résumé** : processus de défragmentation pour préparer les palettes
 > d'expédition vers la zone de défragmentation client dans l'ASRS.
@@ -37,7 +37,7 @@ répond au besoin Limagrain** :
 |---------------|-------------|----------|
 | Shipping Only | Défrag uniquement les palettes complètes | Les palettes de picking ne sont pas repositionnées → ordonnancement STOP faux dans le canal |
 | Picking & Shipping | Défrag toutes les palettes (y compris celles à picker) | Les palettes sortent pour être défragmentées alors qu'elles doivent d'abord passer au PK → casse l'ordonnancement |
-| Picking Only | Non applicable au besoin | — |
+| Picking Only | Non applicable au besoin | - |
 **Contrainte métier** : le stock doit être rangé dans le canal
 d'expédition ASRS dans l'**ordre inverse des STOP** de la tournée, de
@@ -62,7 +62,7 @@ de l'expédition.
 - **Priorité** : basse (s'exécute en arrière-plan)
 - **Planification** : horaires configurables par Limagrain
- **Zone cible** : zone défragmentation client (TK02, 03, 04 —
+- **Zone cible** : zone défragmentation client (TK02, 03, 04 -
  rangées 60-69, profondeurs 2-10)
 - **Déclencheur** : stratégie de défragmentation par rotation (standard)
  + custom défrag client par tournée (ci-dessous)
@@ -88,7 +88,29 @@ La défragmentation est l'étape 4 du flux d'expédition (voir
 3. Palettes picking → poste de travail d'abord, puis zone client
 4. Depuis zone client → sortie vers poumon le jour J
-## [CUSTOM] Défrag client par tournée — Quai non assigné (LIM-87)
+## [CONFIG] Stratégies de défragmentation client par tournée (LIM-85)
 > **Statut (LIM-85)** : **en cours de test client (pré-production)**.
 > Stratégies importées sur Git le 23/04/2026 (suite à l'atelier du 2 avril).
 > Ticket de suivi - peu de contenu technique, il sert à tracer la
 > configuration.
 Ce ticket couvre la **configuration des stratégies de défragmentation** du
 stock client par tournée : définition des stratégies (mode Shipping, type
 d'ordre Tournée) et de la zone cible ASRS (zone client TK02-04, rangées
 60-69). Ces stratégies sont le socle sur lequel s'appuie le custom
 d'éligibilité par tournée ci-dessous (LIM-87).
 La logique custom (filtre « toutes les palettes du RUT prêtes »,
 ordonnancement inverse des STOP, quai non assigné) relève de
 [LIM-87](https://easywmsfrance.atlassian.net/browse/LIM-87).
 ## [CUSTOM] Défrag client par tournée - Quai non assigné (LIM-87)
 > **Statut (LIM-87)** : **en cours de test client (pré-production)**. Revue
 > de code validée le **28/04/2026** (après un NOK le 24/04 : bug de nommage
 > de paramètre `c` réutilisé entre le `Any` et le `Where` de la query,
 > corrigé le 27/04).
 ### Objectif
@@ -114,6 +136,14 @@ de la tournée** (RUT), pas de l'OS individuel.
  qui exclut de l'éligibilité toute tournée dont au moins une palette
  (d'au moins un OS) n'est pas encore prête dans l'ASRS
 La sélection des candidats passe par la query standard
 `OutboundDefragContainers_PendingByWarehouseExcludedIds`, **modifiée en
 custom** : elle ne retient un conteneur que si sa tournée (ou son OS) n'a
 **plus de picking en cours**. Elle exclut donc les conteneurs de picking
 restants **et** les conteneurs pas encore rangés dans l'ASRS (encore en
 mouvement, `LocationType != Aps`). S'il en existe au moins un, aucun
 conteneur de cet ordre n'est retenu pour la défrag.
 ### Règle d'éligibilité (pseudocode)
 ```
@@ -140,7 +170,8 @@ du **STOP 1** en dernier. Ainsi les palettes sortent dans le bon ordre
 lors du chargement camion (STOP 1 chargé en premier).
 Le rangement se fait dans un canal (ou plusieurs canaux) par tournée
-— pas un canal par STOP.
+
 - pas un canal par STOP.
 ### Paramètre MAX_DEFRAG_ATTEMPT
@@ -154,6 +185,10 @@ un emplacement de destination et n'en a pas trouvé. Si le filtre
 custom exclut la tournée avant même de chercher une destination,
 aucune tentative n'est décomptée.
 > **Résolu (LIM-87, 23/04/2026)** : `MAX_DEFRAG_ATTEMPT` ne concerne que la
 > défrag **par rotation**, **pas** la défrag d'expédition/client. Le custom
 > de défrag client par tournée n'est donc **pas** plafonné par ce compteur.
 ## Cas de tests (LIM-87)
 Légende : PC = palette complète, PP = palette de picking (mère),
@@ -175,7 +210,7 @@ PF = palette fille (sortie du picking, retour ASRS).
 |----|-------------|---------------|------------------|
 | 06 | PP partie, PF pas encore revenue | 2 SOR, SOR1 prêt, SOR2 avec PF pas revenue | **NON éligible** (un OS bloque tout le RUT) |
 | 07 | PF encore sur AGV (en mouvement) | Multi-OS, 1 PF en transit AGV | **NON éligible** tant que PF pas dans ASRS |
-| 08 | Quai déjà assigné à la tournée | Toutes palettes prêtes, quai assigné | **NON éligible** pour custom défrag — flux standard prend le relais |
+| 08 | Quai déjà assigné à la tournée | Toutes palettes prêtes, quai assigné | **NON éligible** pour custom défrag - flux standard prend le relais |
 | 09 | Picking partiel sur un OS | 1 SOR, 3 lignes picking, 2 PF revenues, 1 PP au PK | **NON éligible** (on attend la totalité) |
 ### Cas dégradés
@@ -184,7 +219,7 @@ PF = palette fille (sortie du picking, retour ASRS).
 |----|-------------|---------------|------------------|
 | 11 | AGV HS pendant retour PF | PF bloquée sur PK/buffer | **NON éligible** jusqu'à rangement ASRS |
 | 12 | Support sous révision | PP → buffer litige, stock réassigné sur PP' | Éligible quand toutes les palettes (réassignations incluses) dans ASRS |
-| 13 | Rupture de stock (ATTENTE CLIENT) | SOR1 prêt, SOR2 avec 1 ligne en rupture | **À trancher** : option A (RUT bloqué) ou option B (défrag partielle) |
+| 13 | Rupture de stock (ATTENTE CLIENT) | SOR1 prêt, SOR2 avec 1 ligne en rupture | Implémentation : commande incomplète → **pas de défrag** (proche option A). Arbitrage client à confirmer (option A vs B) |
 | 14 | Modification quantité (bouton Problème) | OnStockAdjust recalcule | Si stock suffisant → PF revient, RUT éligible. Si réassignation → attendre PP'/PF' |
 | 15 | RUT libéré, aucune PP partie (figé) | Pas de PK disponible | **NON éligible** (picking pas déclenché ≠ prêt). Pas de MAX_DEFRAG_ATTEMPT |
 | 16 | Ajout SOR à un RUT déjà éligible | Nouveau SOR avec lignes picking non traitées | **Redevient NON éligible** jusqu'à fin du nouveau SOR |
@@ -196,7 +231,7 @@ exemple si l'activité reprend la nuit).
 ## Points d'attention
-⚠️ Les tâches de défragmentation ont une priorité **basse** — elles ne
+⚠️ Les tâches de défragmentation ont une priorité **basse** - elles ne
 perturbent pas l'activité normale mais peuvent être longues.
 ⚠️ MECALUX conseille une présence sur site lors de la défragmentation
@@ -209,10 +244,13 @@ non prêt bloque toute la défrag du RUT.
 ## Questions ouvertes
- [ ] Rupture de stock CT-13 : option A (RUT bloqué tant que rupture
+- ❓ Rupture de stock CT-13 : option A (RUT bloqué tant que rupture
  non résolue) ou option B (défrag sur les palettes dispo) ? (@Justine)
- [ ] MAX_DEFRAG_ATTEMPT : scope défrag client seul ou aussi défrag par
+  Implémentation actuelle : commande incomplète → pas de défrag (proche
-  rotation ? Impact sur la valeur à configurer (@Nicolas)
+  option A), à confirmer client
 - [x] ~~MAX_DEFRAG_ATTEMPT : scope défrag client seul ou aussi défrag par
  rotation ?~~ → Résolu (LIM-87) : uniquement la défrag par rotation, pas
  la défrag d'expédition
 ## Historique des modifications
@@ -221,11 +259,13 @@ non prêt bloque toute la défrag du RUT.
 | 2026-05-05 | Arthur | Création initiale depuis AF V1.5 |
 | 2026-05-12 | Arthur | Refonte : ajout custom défrag client par tournée (LIM-87), mécanisme filtre éligibilité, ordonnancement STOP, 16 cas de tests |
 | 2026-05-13 | Arthur | Restauration contenu tronqué (caractéristiques, config, custom, cas de tests, points d'attention) |
 | 2026-07-17 | Arthur | Relecture LIM-85 (lecture directe, 1 commentaire) : ajout section « [CONFIG] Stratégies de défragmentation (LIM-85) » distinguant la config des stratégies (LIM-85, préprod, import Git 23/04) du custom d'éligibilité par tournée (LIM-87) ; statut + Références |
 | 2026-07-17 | Arthur | Relecture revue de code LIM-87 (préprod, validée 28/04) : ajout statut + query `OutboundDefragContainers_PendingByWarehouseExcludedIds` (filtre custom picking restant + conteneurs pas en Aps ; bug nommage paramètre corrigé 27/04) ; résolution MAX_DEFRAG_ATTEMPT (uniquement défrag rotation, pas expédition) ; CT-13 précisé (commande incomplète → pas de défrag, proche option A) |
 ## Références
 | Source | Type | Date |
 |--------|------|------|
 | FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5 | Analyse fonctionnelle | 28/11/2025 |
-| [LIM-85](https://easywmsfrance.atlassian.net/browse/LIM-85) | Ticket Jira (stratégies défrag) | 2026 |
+| [LIM-85](https://easywmsfrance.atlassian.net/browse/LIM-85) | Ticket Jira (config stratégies défrag, préprod, import Git 23/04) | 2026 |
-| [LIM-87](https://easywmsfrance.atlassian.net/browse/LIM-87) | Ticket Jira (défrag client quai non assigné) | 2026 |
+| [LIM-87](https://easywmsfrance.atlassian.net/browse/LIM-87) | Ticket Jira (défrag client quai non assigné, 5 commentaires, préprod) | 2026-04 |
@@ -1,16 +1,16 @@
 ---
-title: "Configuration Galileo — Limagrain"
+title: "Configuration Galileo - Limagrain"
-tags: [stockage, galileo, TMS, architecture, IT]
+tags: [stockage, galileo, TMS, architecture, IT, filmage, PIE]
 status: draft
 standard_ref: architecture/galileo-integration.md
-jira_refs: []
+jira_refs: [LIM-115]
 confluence_refs: []
-sources: [FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5.docx]
+sources: [FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5.docx, "Jira LIM-115 (lecture directe 2026-07-20)"]
-last_updated: 2026-05-05
+last_updated: 2026-07-20
 author: Arthur
 ---
-# Configuration Galileo — Limagrain
+# Configuration Galileo - Limagrain
 > **Résumé** : architecture logicielle IT de l'installation Limagrain et
 > spécificités de la configuration Galileo (TMS).
@@ -61,7 +61,7 @@ graph TD
 - **ERP** : SAP EWM
 - **Direction** : bidirectionnelle (voir [Messages ERP](../06-erp-interface/messages-reference.md))
-## Stations PIE — Configuration spécifique
+## Stations PIE - Configuration spécifique
 3 stations PIE installées :
@@ -85,7 +85,7 @@ graph TD
 | Dimensions max | 1300 × 1100 × 1900 mm |
 | Poids max | 1250 kg |
 | État palette bois | Correct (visuel Galileo) |
-| Lecture RFID | Obligatoire — doit être connue (ASN) |
+| Lecture RFID | Obligatoire - doit être connue (ASN) |
 ## Flux physiques dans l'entrepôt
@@ -103,6 +103,58 @@ Deux entrées dans l'ASRS :
 > En cas de blocage long terme sur une entrée, un bouton permet de
 > rediriger les flux vers l'autre entrée.
 ## Transmission du programme de filmage à la filmeuse (LIM-115)
 > **Statut (LIM-115)** : Ouvert. Cette tâche **transmet** le programme de
 > filmage à Galileo ; elle ne le **produit** pas (choix opérateur au poste,
 > stocké dans `CstAtt05`, voir LIM-67).
 **Objectif** : quand une palette quitte un poste d'identification (PIE) pour
 entrer dans l'ASRS, le WMS transmet automatiquement à Galileo le programme de
 filmage choisi par l'opérateur, sans action supplémentaire. Même principe que
 l'étiqueteuse automatique (custom data, pas de changement de route - voir
 [Flux expédition - Communication Galileo](../04-outbound/flux-expedition.md#communication-galileo-lim-111)).
 ### Chaîne fonctionnelle
 L'opérateur choisit le programme au poste (action « Terminer » en réception,
 ou avant évacuation en picking) → valeur dans `CstAtt05` → tâche d'évacuation
 AGV vers la table d'entrée → passage **filmeuse** puis PIE → stockage ASRS. La
 règle « on ne filme que si le PIE valide la palette » est **structurellement**
 satisfaite : un mouvement de source PIE vers la table d'entrée (et non vers le
 poumon de rejet) n'existe que si le PIE a dit OK.
 ### Mécanisme
 | Étape | Détail |
 |-------|--------|
 | Abonnement | Subscription custom sur l'event **`MovementCreated`** (modèle des `Galileo_*EventHandler_PR`), appelant un WF qui gère le CstData. Handler **léger** (event fréquent). |
 | Filtre source | Récupérer la station **source** du mouvement (StationType + StationNumber) ; la comparer au paramètre des PIE concernés. Si absente → sortie immédiate. |
 | Lecture programme | Depuis le mouvement → remonter au **support (Container)** → lire `CstAtt05`. Si vide ou = code « pas de filmage » (`0`) → forcer CstData à `0`. Si **destination = rejet** (type de tâche) → forcer CstData à `0`. |
 | Écriture CustomData | Écrire dans le **CustomData de la tâche** parente. **Idempotent** (une tâche peut générer plusieurs mouvements). Pas de collision avec l'étiqueteuse : c'est un **type de tâche différent** (une même tâche n'est jamais à la fois filmage et étiquetage). |
 | Transmission Galileo | Aucune commande spécifique : Galileo lit le CustomData à la transmission du mouvement (`GalileoMovTrackingCreateCommand`, transition Generated → In progress) et pilote la filmeuse. |
 Séquence : Easy crée le mouvement en `Generated` → Galileo fait une recherche
 d'ordre → Easy répond via `GalileoMovTrackingCreateCommand` (infos mouvement +
 tâche liée) → le mouvement passe en `Running`.
 ### Périmètre
 - **Stations déclenchantes** : **PIE_02**, définies dans un **paramètre** (pas
  de code en dur) pour absorber une évolution de topologie.
 - **Flux couverts** : **tous les flux entrant vers l'ASRS** via un poste
  d'identification zone travail (réception extérieure/intersite, retour picking
  vers ASRS, recertification, etc.). Mécanisme **générique** : teste uniquement
  la station source + la présence d'un programme sur le support.
 - **Hors périmètre** : PIE_01 (entrée production, non filmée), PIE_03 (pas de
  filmeuse après ce PIE), la pose de `CstAtt05` (LIM-67) et la mécanique
  physique de la filmeuse (Galileo/TMS).
 > ⚠️ Réconciliation : le tableau des stations PIE ci-dessus indique
 > « PIE_03 = idem PIE_02 ». Pour le **filmage**, LIM-115 exclut PIE_03 (pas de
 > filmeuse en aval). L'identité PIE_02/PIE_03 vaut pour le **mode d'insertion**,
 > pas pour la filmeuse.
 ## Rétention des données
 | Entité | Durée standard | Souhait Limagrain |
@@ -123,21 +175,23 @@ Deux entrées dans l'ASRS :
 peuvent impacter les flux fonctionnels.
 ⚠️ La banderoleuse (filmeuse) est située avant le PIE côté postes de
-travail — un contrôle capacité filmeuse est fait en amont du PIE.
+travail - un contrôle capacité filmeuse est fait en amont du PIE.
 ## Questions ouvertes
- [ ] Impact rétention 2 ans sur les performances Oracle (@Nicolas)
+- ❓ Impact rétention 2 ans sur les performances Oracle (@Nicolas)
- [ ] Fournisseur AGV définitif et protocole d'interface (@Théo)
+- ❓ Fournisseur AGV définitif et protocole d'interface (@Théo)
 ## Historique des modifications
 | Date | Auteur | Modification |
 |------|--------|--------------|
 | 2026-05-05 | Arthur | Création initiale depuis AF V1.5 |
 | 2026-07-20 | Arthur | LIM-115 (lecture directe, Ouvert) : nouvelle section « Transmission du programme de filmage à la filmeuse » (subscription MovementCreated, filtre station source PIE_02 via paramètre, lecture CstAtt05, force CstData=0 si vide/pas de filmage/destination rejet, écriture idempotente CustomData tâche, lecture Galileo via GalileoMovTrackingCreateCommand ; périmètre tous flux entrant ASRS via PIE_02, hors PIE_01/PIE_03) + caveat réconciliation PIE_03 (pas de filmeuse) ; front matter jira_refs/sources/tags/last_updated |
 ## Références
 | Source | Type | Date |
 |--------|------|------|
 | FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5 | Analyse fonctionnelle | 28/11/2025 |
 | [LIM-115](https://easywmsfrance.atlassian.net/browse/LIM-115) | Ticket Jira (transmission du programme de filmage à Galileo/filmeuse) | 2026 |
@@ -2,7 +2,7 @@
 title: "Gestion des palettes vides"
 tags: [stockage, palettes-vides, réapprovisionnement, expédition]
 status: draft
-standard_ref: concepts/container-management.md
+standard_ref: concepts/container.md
 jira_refs: []
 confluence_refs: []
 sources: [FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5.docx, "Réception - LIMAGRAIN - DEV - Confluence.md"]
@@ -12,7 +12,7 @@ author: Arthur
 # Gestion des palettes vides
-> **Résumé** : gestion des piles de palettes vides dans EasyWMS —
+> **Résumé** : gestion des piles de palettes vides dans EasyWMS -
 > réception, stockage, réapprovisionnement des postes et expédition.
 > **Standard EasyWMS** : → voir [Container Management](../../concepts/container.md)
@@ -21,7 +21,7 @@ author: Arthur
 ## Contexte projet
 Les palettes vides sont intégrées dans le périmètre EasyWMS. Leur gestion
-est faite **uniquement en pile** — aucune palette vide n'est traitée de
+est faite **uniquement en pile** - aucune palette vide n'est traitée de
 façon unitaire.
 ## Typologie
@@ -36,7 +36,7 @@ Les piles de palettes vides sont réceptionnées au niveau des quais.
 Type de réception : **Réception palettes vides**. L'article est nommé
 « PILE DE 10 PALETTES ».
-**Règles** : toujours reçu par paquet de 10 palettes (sinon refusé —
+**Règles** : toujours reçu par paquet de 10 palettes (sinon refusé -
 contrainte de hauteur). Aucun scan demandé. Pas de passage par poste
 de travail. Destination : stockage direct dans l'ASRS.
@@ -52,7 +52,7 @@ de travail. Destination : stockage direct dans l'ASRS.
 - Position : au plus proche de l'entrée/sortie pour réapprovisionner
  rapidement les postes
 - Stratégie de rangement : voir
-  [Stratégies de rangement](putaway-strategies.md) — type 5
+  [Stratégies de rangement](putaway-strategies.md) - type 5
 - Consultation : vue des stocks avec filtre sur l'article « palettes vides »
 ### Au niveau des postes de travail
@@ -100,7 +100,7 @@ Les piles de palettes vides peuvent être expédiées :
 ## Points d'attention
-⚠️ Gestion uniquement en pile (jamais unitaire) — simplifie le suivi
+⚠️ Gestion uniquement en pile (jamais unitaire) - simplifie le suivi
 mais impose des manipulations par lot de 10.
 ⚠️ Le nombre de piles en stock est visible en filtrant la vue des stocks
@@ -1,8 +1,8 @@
 ---
-title: "Processus d'anoxie — TK01"
+title: "Processus d'anoxie - TK01"
 tags: [stockage, anoxie, TK01, flag, custom, processus]
 status: draft
-standard_ref: concepts/warehouse-processes.md
+standard_ref: concepts/quality-control.md
 jira_refs: []
 confluence_refs: []
 sources: [FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5.docx]
@@ -10,7 +10,7 @@ last_updated: 2026-05-05
 author: Arthur
 ---
-# Processus d'anoxie — TK01
+# Processus d'anoxie - TK01
 > **Résumé** : processus [CUSTOM] de traitement par anoxie dans l'allée 1,
 > incluant le flag « A anoxier », la relocalisation et le blocage d'allée.
@@ -63,7 +63,7 @@ spécifiques depuis la vue des stocks.
 ## Cas particuliers
 - Des stocks d'une même référence (article-lot) peuvent posséder des dates
-  de dernière anoxie différentes — ces stocks ne sont pas physiquement
+  de dernière anoxie différentes - ces stocks ne sont pas physiquement
  différenciables
 - Si une palette contient du stock « mixte » dont certaines lignes ont le
  flag et d'autres pas → toutes les lignes sont considérées « A anoxier »
@@ -77,20 +77,20 @@ flowchart TD
    RELOC1 --> SEL2[2. Sélection palettes à anoxier]
    SEL2 --> RELOC2[Relocalisation vers TK01]
    RELOC2 --> BLOCK[3. Blocage manuel allée 01]
-    BLOCK --> WAIT[Anoxie en cours — 3 à 4 semaines]
+    BLOCK --> WAIT[Anoxie en cours - 3 à 4 semaines]
    WAIT --> FIN[4. Bouton « Fin d'anoxie »]
    FIN --> UPDATE[MAJ date dernière anoxie + suppression flag]
    UPDATE --> DEBLOCK[Déblocage manuel allée 01]
 ```
-### Étape 1 — Évacuation des palettes non concernées
+### Étape 1 - Évacuation des palettes non concernées
 - Sélection manuelle depuis la vue des conteneurs (filtre sur flag
  « A anoxier »)
 - Relocalisation vers une autre allée (en masse, voir déplacement
  de conteneurs)
-### Étape 2 — Relocalisation des palettes à anoxier
+### Étape 2 - Relocalisation des palettes à anoxier
 - Sélection manuelle des palettes avec flag « A anoxier »
 - Relocalisation vers TK01 dans la mesure des emplacements disponibles
@@ -98,12 +98,12 @@ flowchart TD
 [CUSTOM] Les étapes 1 et 2 peuvent être **automatisées** afin de créer
 automatiquement les tâches de relocalisation.
-### Étape 3 — Blocage
+### Étape 3 - Blocage
 - Blocage **manuel** de l'allée 01 sur EasyWMS
 - Le stock et l'allée deviennent indisponibles
-### Étape 4 — Fin d'anoxie
+### Étape 4 - Fin d'anoxie
 - [CUSTOM] Bouton « Fin d'anoxie » qui :
  - Met à jour la date de dernière anoxie
@@ -122,7 +122,7 @@ automatiquement les tâches de relocalisation.
 Les palettes avec flag « A anoxier » ont une stratégie de rangement
 dédiée qui priorise TK01 (voir
-[Stratégies de rangement](putaway-strategies.md) — type 1).
+[Stratégies de rangement](putaway-strategies.md) - type 1).
 ## Points d'attention
@@ -138,8 +138,8 @@ en cas de reprise d'activité.
 ## Questions ouvertes
- [ ] Automatisation étapes 1 et 2 — développement custom validé ? (@Nicolas)
+- ❓ Automatisation étapes 1 et 2 - développement custom validé ? (@Nicolas)
- [ ] Interface du bouton « Fin d'anoxie » — écran dédié ou menu existant ? (@Fabien)
+- ❓ Interface du bouton « Fin d'anoxie » - écran dédié ou menu existant ? (@Fabien)
 ## Historique des modifications
@@ -21,36 +21,36 @@ author: Arthur
 ## Contexte projet
 Le premier filtre appliqué aux palettes détermine la stratégie de rangement.
-Limagrain n'utilise pas de classes de rotation ABC — la répartition se fait
+Limagrain n'utilise pas de classes de rotation ABC - la répartition se fait
 sur la nature fonctionnelle de la palette.
-## Stratégie 1 — Palettes avec flag « A Anoxier » (mono ou multi lot)
+## Stratégie 1 - Palettes avec flag « A Anoxier » (mono ou multi lot)
 Objectif : stocker en priorité dans TK_01 (zone anoxie).
 | Priorité | Règle |
 |----------|-------|
-| 1 | TK01 — canal incomplet, même lot SAP + mêmes attributs logistiques (article, propriétaire, statut) |
+| 1 | TK01 - canal incomplet, même lot SAP + mêmes attributs logistiques (article, propriétaire, statut) |
-| 2 | TK01 — canal vide |
+| 2 | TK01 - canal vide |
-| 3 | TK01 — canal incomplet avec autre référence |
+| 3 | TK01 - canal incomplet avec autre référence |
 | 4 | Appliquer la stratégie sans flag « A Anoxier » (stratégie 2 ou 3) |
 | 5 | REJET |
-## Stratégie 2 — Palettes mono lot sans flag « A Anoxier »
+## Stratégie 2 - Palettes mono lot sans flag « A Anoxier »
 Objectif : optimiser le taux de remplissage et répartir le stock entre allées.
 | Priorité | Règle |
 |----------|-------|
 | 1 | Canal incomplet même lot SAP + mêmes attributs logistiques |
-| 2 | Canal le plus adapté dans un TK qui n'a **pas** de stock équivalent (répartition inter-allées) — taille optimale vs nb palettes ASN restantes |
+| 2 | Canal le plus adapté dans un TK qui n'a **pas** de stock équivalent (répartition inter-allées) - taille optimale vs nb palettes ASN restantes |
 | 3 | Canal le plus adapté aux nb palettes ASN restantes (toute allée) |
 | 4 | REJET |
 **Sélection du canal** : canal le plus grand possible qui sera rempli
 complètement, ou canal qui laissera le moins de positions vides.
-## Stratégie 3 — Palettes multi lot sans flag « A Anoxier »
+## Stratégie 3 - Palettes multi lot sans flag « A Anoxier »
 | Priorité | Règle |
 |----------|-------|
@@ -59,17 +59,17 @@ complètement, ou canal qui laissera le moins de positions vides.
 | 3 | Canal incomplet (tout) |
 | 4 | REJET |
-## Stratégie 4 — Palettes d'expédition (mono ou multi lot)
+## Stratégie 4 - Palettes d'expédition (mono ou multi lot)
 Objectif : stocker dans la zone défragmentation client, regroupées par route.
 | Priorité | Règle |
 |----------|-------|
-| 1 | Canal incomplet avec palettes de la même route — zone défragmentation client |
+| 1 | Canal incomplet avec palettes de la même route - zone défragmentation client |
-| 2 | Canal vide — zone défragmentation client |
+| 2 | Canal vide - zone défragmentation client |
 | 3 | PAS DE MOUVEMENT (palette reste en place) |
-## Stratégie 5 — Piles de palettes vides
+## Stratégie 5 - Piles de palettes vides
 Article type « Palette » (NIMP15).
@@ -98,7 +98,7 @@ rejet configuré (sauf stratégie 4 où la palette reste sur place).
 qu'après assignation de stock (post-libération de l'OS).
 ⚠️ La stratégie 1 (anoxie) utilise un fallback vers les stratégies 2/3
-si TK_01 est plein — important en période hors-anoxie.
+si TK_01 est plein - important en période hors-anoxie.
 ## Historique des modifications
@@ -0,0 +1,255 @@
 ---
 title: "Flux de rejet PIE - Renvoi au poste d'origine"
 tags: [stockage, rejet, PIE, poste, big-bag, production, custom, agv]
 status: draft
 standard_ref: concepts/reception.md
 jira_refs: [LIM-114]
 confluence_refs: []
 related:
  - limagrain/01-inbound/controle-qualite-reception.md
  - limagrain/07-admin/ad-customs.md
  - limagrain/07-admin/parametres-projet.md
 sources: ["Jira LIM-114 (lecture directe 2026-07-20)"]
 last_updated: 2026-07-20
 author: Arthur
 ---
 # Flux de rejet PIE - Renvoi au poste d'origine
 > **Résumé** : logique [CUSTOM] qui, lorsqu'une palette est rejetée au PIE
 > avant stockage ASRS, calcule et renvoie au WMS la destination de la palette
 > (renvoi au **poste de travail d'origine**), y pose un verrou porteur de la
 > cause, et gère la correction puis la ré-injection.
 > **Standard EasyWMS** : → voir [Reception](../../concepts/reception.md) et le
 > [Contrôle qualité à réception (PIE)](../01-inbound/controle-qualite-reception.md)
 > (contrôles PIE, LIM-66). Ce qui suit documente la **spécificité Limagrain**
 > du rejet.
 > **Statut (LIM-114)** : Ouvert, non assignée, **rédaction en cours** côté
 > ticket. Contenu susceptible d'évoluer.
 ## Contexte projet
 Le passage au **PIE** (voir
 [Contrôle qualité à réception](../01-inbound/controle-qualite-reception.md),
 LIM-66) contrôle chaque support avant stockage dans l'ASRS. Si un contrôle
 échoue, la palette est **rejetée** et ne rentre pas dans l'ASRS.
 Causes de rejet fonctionnelles attendues : **dimension**, **poids**,
 **étiquette (RFID non lue)**, **palette bois**.
 ### Revirement client
 Cette tâche **remplace** l'approche « poumon au sol + notification SmartUI »
 (esquissée dans LIM-66, Confluence « Réception » §3.2). Le client confirme
 vouloir le **renvoi de la palette rejetée vers le poste de travail où elle a
 été précédemment traitée**, malgré la charge AGV supplémentaire.
 Risque assumé (justification initiale de l'abandon) : renvoyer au poste
 d'origine mobilise l'AGV et le poste, avec un risque de blocage table/poste et
 une perte de temps. **Accepté par le client.** La mise à jour Confluence sera
 faite en fin de projet ; pas de modification de LIM-66 (uniquement un lien).
 ## Principe - le WMS répond la destination
 Les routes de rejet **EasyS** amènent la palette rejetée jusqu'à un poste de
 sortie (PS). Une fois au PS, la **recherche d'ordre** déclenche l'interrogation
 du WMS par Galileo : **c'est le WMS qui répond la destination**. Il n'y a donc
 pas de conflit avec les routes EasyS existantes et **pas de reprise de routes**
 à demander à Mecalux.
 Cette tâche porte uniquement sur la **logique WMS** (calcul de destination),
 le report du poste d'origine (`CstAtt06`) sur le support réel, et un nouveau
 paramètre `PK_REJET_PROD`.
 ## Topologie EST / OUEST
 - Les palettes de **production** entrent obligatoirement par l'**entrée EST**
  (image de quai → PIE, sans poste de travail). Exception standard : si le
  `PE01` (EST) est fermé, tout le flux (y compris production) bascule côté
  **OUEST** via les routes EasyS existantes.
 - Les palettes de **réception** (fournisseur / intersite / retour) et les
  palettes **sources de picking** passent par un poste de travail (PK) côté
  OUEST, qui devient leur **poste d'origine**.
 Le WMS est **agnostique du côté** : EasyS achemine le rejet vers le PS local
 (EST ou OUEST), et le WMS répond la destination à partir des attributs du
 support.
 ## Détermination de la destination de rejet
 Au moment de la recherche d'ordre sur le support rejeté arrivé au PS, le WMS
 calcule la destination :
 ```
 1. Lire CstAtt06 (Code du PK assigné = poste d'origine) du support.
 2. SI CstAtt06 renseigné (poste d'origine connu) :        // réception, picking
     candidat = poste CstAtt06
     SI big-bag (CstAtt02 = true) ET candidat ∉ PK_BIGBAG : candidat = INVALIDE
     SI candidat non disponible (fermé / mode incompatible / saturé) : candidat = INVALIDE
     SI candidat VALIDE : destination = candidat
     SINON : destination = fallback (étape 4)
 3. SINON (CstAtt06 vide) :                                 // production (CstAtt04 = ASN) ou origine inconnue
     destination = PK_REJET_PROD
     SI PK_REJET_PROD non disponible : destination = fallback (étape 4)
 4. FALLBACK : premier poste ouvert et disponible (first-available),
     compatible big-bag si CstAtt02 = true.
     SI big-bag ET aucun poste PK_BIGBAG disponible :
         LOG erreur + la palette attend sur le PS (pas de destination)
 5. Poser un verrou "REJET PIE" sur le support, portant la cause du rejet.
 6. Répondre la destination à Galileo.
 ```
 Notes :
 - Le routage vers la destination est **automatique** (convoyeurs PE/PS/PIE
  sans opérateur), notamment pour les palettes de production qui partent
  directement vers `PK_REJET_PROD`.
 - La sélection d'un poste « disponible » réutilise la logique de disponibilité
  de l'assignation des postes (mode actif, saturation), voir
  [Mini jobs d'assignation au PK](../03-picking/job-assignation-pk.md)
  (LIM-70 / LIM-74).
 - « Origine inconnue » (`CstAtt06` vide sur un support non production) est
  traitée comme production → `PK_REJET_PROD` (filet de sécurité).
 ## Affichage de la cause au poste
 Le support arrive au poste avec le verrou « REJET PIE ». À l'arrivée / au scan
 du support, le WMS **affiche la cause du rejet** (dimension, poids, étiquette,
 palette bois) portée par le verrou. **Pas de notification SmartUI** (aligné
 avec l'abandon des notifications de LIM-66) : l'information est portée par le
 verrou et visible au scan.
 > ⚠️ **Dépendance Mecalux à confirmer** : pour afficher la cause, EasyS/Galileo
 > doit transmettre au WMS le **type d'erreur PIE** au moment du rejet. À
 > défaut, le WMS n'affichera que « REJET PIE » sans le détail de la cause.
 ## Correction et ré-injection
 L'opérateur traite la palette au poste selon la cause :
 | Cause | Action opérateur |
 |-------|------------------|
 | Étiquette | Réétiquetage (impression au poste) |
 | Dimension / poids | Correction physique (reconditionnement, retrait/ajout) |
 | Palette bois réparable | Repalettisation |
 | Palette bois **non réparable** | Déclaration « non réparable » → mouvement vers **REJ01** |
 **REJ01** = sortie de rejet dur côté OUEST. Elle évite d'abîmer la navette
 avec des palettes portant des flags non conformes ; la palette ne repart pas
 vers l'ASRS.
 Après correction, l'opérateur utilise l'option **standard « Stocker support »**
 (aucun dév custom) : le support repart vers l'ASRS via le PIE (`PIE_ENTRY_PK`)
 et **repasse le contrôle PIE nominal**.
 - Contrôle PIE **OK** → rangement ASRS, le verrou « REJET PIE » est **levé**.
 - Contrôle PIE **échoue à nouveau** → nouveau rejet, retour au poste d'origine.
  **Pas de garde-fou anti-boucle** : tant qu'il y a un rejet, on renvoie au
  poste d'origine (comportement stable et identique à chaque cycle).
 ## Prérequis - report du poste d'origine (CstAtt06)
 Le `CstAtt06` « Code du PK assigné » (Support, String, créé en LIM-70)
 matérialise le poste d'origine. Il est posé sur le support **fictif** de
 l'image de quai par LIM-70/LIM-74, mais le support **réel** qui passe au PIE
 ne l'hérite pas automatiquement. Il faut donc le **reporter** :
 - **Réception (LIM-67)** : à la création du support réel au poste, renseigner
  `CstAtt06` = code du PK courant.
 - **Picking (LIM-91)** : sur la palette source traitée au poste de picking,
  renseigner `CstAtt06` = code du PK picking (pour qu'un rejet au ré-stockage
  revienne au bon poste).
 - **Production** : pas de poste d'origine. `CstAtt06` reste **vide** ; le
  support est identifié production via `CstAtt04` = ASN. Destination =
  `PK_REJET_PROD`.
 ## Paramètres et attributs
 Nouveau paramètre (à déclarer dans LIM-14) :
 | Paramètre | Description | Défaut |
 |-----------|-------------|--------|
 | `PK_REJET_PROD` | Poste de rejet des palettes sans poste d'origine (production). À câbler physiquement côté EST (ex. `PS01`). | (à définir) |
 Paramètres existants réutilisés : `PK_BIGBAG` (postes compatibles big-bag),
 `PIE_ENTRY_PK` (PIE de ré-insertion après poste), `MODES_PKxx` (modes actifs).
 Voir [Paramètres projet](../07-admin/parametres-projet.md).
 Attributs utilisés (Support - voir [AD Customs](../07-admin/ad-customs.md#cstatt-support-container--palette)) :
 | Attribut | Rôle dans le rejet |
 |----------|--------------------|
 | `CstAtt06` | Poste d'origine. Lu pour déterminer la destination. |
 | `CstAtt02` | Big-bag. Contraint la destination aux postes de `PK_BIGBAG`. |
 | `CstAtt04` | ASN (production). Identifie les palettes sans poste d'origine. |
 ## Cas de test
 27 cas de test définis dans le ticket, regroupés par famille :
 - **Destination réception / picking** (CT 1-4) : renvoi au poste `CstAtt06` ;
  chaque cause (dimension, poids, étiquette, palette bois) route au poste
  d'origine avec sa cause dans le verrou.
 - **Destination production** (CT 5-7) : `CstAtt04` = ASN + `CstAtt06` vide →
  `PK_REJET_PROD` (routage auto sans opérateur) ; fallback si indisponible ;
  origine inconnue traitée comme production.
 - **Big-bag** (CT 8-11) : poste d'origine compatible `PK_BIGBAG` ; origine
  incompatible → fallback big-bag ; aucun poste compatible → log + attente PS ;
  non big-bag sans contrainte.
 - **Poste d'origine indisponible** (CT 12-14) : poste fermé/saturé → fallback
  first-available ; aucun poste dispo → attente PS (à confirmer).
 - **Affichage cause** (CT 15-17) : cause visible au scan ; pas de SmartUI ;
  « REJET PIE » générique si cause non transmise par EasyS.
 - **Correction / ré-injection** (CT 18-21) : « Stocker support » standard →
  re-contrôle PIE ; re-rejet → retour poste sans garde-fou ; boucle stable ;
  aucun écran custom.
 - **Palette bois non réparable** (CT 22-23) : déclaration → REJ01 ; réparable
  → ré-injection normale.
 - **Prérequis CstAtt06** (CT 24-27) : report réception (LIM-67), pose picking
  (LIM-91), production sans `CstAtt06`, support réel sans report → traité
  comme origine inconnue (`PK_REJET_PROD`).
 ## Points d'attention
 ⚠️ **Pas de garde-fou anti-boucle** : une palette qui échoue plusieurs fois
 au PIE revient à chaque fois au poste d'origine. Aucune sortie litige
 automatique.
 ⚠️ Le renvoi au poste d'origine mobilise l'AGV et le poste (risque de blocage
 table/poste). Choix assumé par le client.
 ⚠️ Tâches liées à modifier : **LIM-67** (report `CstAtt06` sur support réel),
 **LIM-91** (pose `CstAtt06` sur palette source picking), **LIM-14**
 (déclaration `PK_REJET_PROD`), **LIM-66** (ajout d'un lien, sans modification).
 ## Questions ouvertes
 - Transmission de la cause de rejet (type d'erreur PIE) d'EasyS/Galileo vers
  le WMS - conditionne l'affichage de la cause (@Mecalux)
 - Poste physique `PK_REJET_PROD` côté EST (ex. `PS01`) et sa joignabilité si
  `PE01` fermé (bascule OUEST) - à valider layout
 - Comportement si aucun poste disponible (attente sur PS vs autre) - à confirmer
 - Disponibilité de l'imprimante d'étiquette au poste d'origine (cause
  étiquette) - à valider
 ## Historique des modifications
 | Date | Auteur | Modification |
 |------|--------|--------------|
 | 2026-07-20 | Arthur | Création depuis LIM-114 (lecture directe, Ouvert, rédaction en cours) : flux de rejet PIE avec renvoi au poste d'origine, algorithme de destination, topologie EST/OUEST, affichage de la cause, correction/ré-injection + REJ01, report CstAtt06, paramètre PK_REJET_PROD, 27 cas de test résumés |
 ## Références
 | Source | Type | Date |
 |--------|------|------|
 | [LIM-114](https://easywmsfrance.atlassian.net/browse/LIM-114) | Ticket Jira (flux de rejet PIE, rédaction en cours) | 2026 |
 | [LIM-66](https://easywmsfrance.atlassian.net/browse/LIM-66) | Ticket Jira (contrôles PIE, approche poumon abandonnée) | 2026 |
 | [LIM-70](https://easywmsfrance.atlassian.net/browse/LIM-70) / [LIM-74](https://easywmsfrance.atlassian.net/browse/LIM-74) | Tickets Jira (CstAtt06, disponibilité poste, PK_BIGBAG) | 2026 |
@@ -47,7 +47,7 @@ zones de stockage ont été définies pour répondre à deux besoins métier :
 - Réservée **en priorité** aux palettes avec le flag « A anoxier »
 - Hors période d'anoxie, utilisée comme stockage normal (priorité anoxie)
 - Durant l'anoxie (3-4 semaines, 2x/an) : allée + stock bloqués
- Voir [Processus d'anoxie](../08-transverse/decisions-architecture.md)
+- Voir [Processus d'anoxie](processus-anoxie.md)
 ### Zone Principale (TK_02, 03 & 04)
@@ -1,11 +1,11 @@
 ---
-title: "Picking — Vue d'ensemble"
+title: "Picking - Vue d'ensemble"
 tags: [picking, combinatoire, stations, index]
 status: draft
-last_updated: 2026-05-13
+last_updated: 2026-07-20
 ---
-# Picking — Vue d'ensemble
+# Picking - Vue d'ensemble
 > **Périmètre** : picking combinatoire (CR V3.0, 4-job, CstAtt), stations de
 > picking, job d'assignation PK, waves et groupes, replenishment.
@@ -17,23 +17,23 @@ last_updated: 2026-05-13
 - [Picking combinatoire](picking-combinatoire.md)
 - [Stations de picking](stations-picking.md)
 - [Job d'assignation PK (Mega Job)](job-assignation-pk.md)
 - [Waves et groupes](waves-groupes.md)
 - [Replenishment](replenishment.md)
 - [Séquençage TK → PS](sequencage-tk-ps.md)
- [Séquençage TK → PS — Historique et arbitrage](sequencage-tk-ps-historique.md)
+- [Séquençage TK → PS - Historique et arbitrage](sequencage-tk-ps-historique.md)
 - [Placement PS → PK (choix de table)](placement-ps-pk.md)
 - [Consolidation / Regroupement](consolidation-regroupement.md)
 - [Échantillonnage](echantillonnage.md)
 - [Process de picking au poste de travail (PK)](process-picking-pk.md)
 - [Recertification - Workstation au poste de picking](recertification.md)
-## Chaîne picking — Ordre des traitements
+## Chaîne picking - Ordre des traitements
 L'ordre réel de la chaîne picking est le suivant :
-1. **LIM-80** — [Assignation PK](job-assignation-pk.md) : quelle commande
+1. **LIM-80** - [Assignation PK](job-assignation-pk.md) : quelle commande
   sur quel poste → déclenche la génération des tâches de picking
-2. **LIM-84** — [Séquençage TK → PS](sequencage-tk-ps.md) : ordonne les
+2. **LIM-84** - [Séquençage TK → PS](sequencage-tk-ps.md) : ordonne les
   sorties des TK vers les PS
-3. **LIM-82** — [Placement PS → PK](placement-ps-pk.md) : la palette
+3. **LIM-82** - [Placement PS → PK](placement-ps-pk.md) : la palette
   arrivant au PS va sur quelle table du PK
 4. Workflow opérateur au PK (picking effectif)
@@ -55,4 +55,5 @@ flowchart TD
    PNEG --> FILM[Choix filmage]
    PPOS --> FILM
    FILM --> PIE[Passage PIE]
- 
+    PIE --> DEFRAG[Zone défrag client]
 ```
@@ -1,5 +1,5 @@
 ---
-title: "Consolidation (regroupement) — Processus sur poste"
+title: "Consolidation (regroupement) - Processus sur poste"
 tags: [picking, regroupement, consolidation, MOV, poste, custom]
 status: draft
 standard_ref: concepts/picking.md
@@ -10,7 +10,7 @@ last_updated: 2026-05-05
 author: Arthur
 ---
-# Consolidation (regroupement) — Processus sur poste
+# Consolidation (regroupement) - Processus sur poste
 > **Résumé** : processus [CUSTOM] de consolidation de palettes incomplètes
 > partageant les mêmes critères de stock, sur poste de travail.
@@ -121,7 +121,7 @@ Vérification avec tolérance par type d'article (voir
 ## Points d'attention
-⚠️ Le message MOV est envoyé à chaque mouvement unitaire — volumétrie
+⚠️ Le message MOV est envoyé à chaque mouvement unitaire - volumétrie
 potentiellement élevée pour un regroupement complexe.
 ⚠️ Les 3 tables de préparation d'un même poste peuvent être occupées
@@ -132,8 +132,8 @@ physique + système).
 ## Questions ouvertes
- [ ] Programme de filmage exact pour le regroupement (@Théo)
+- ❓ Programme de filmage exact pour le regroupement (@Théo)
- [ ] Interface opérateur vue regroupement — maquette validée ? (@Fabien)
+- ❓ Interface opérateur vue regroupement - maquette validée ? (@Fabien)
 ## Historique des modifications
@@ -1,16 +1,16 @@
 ---
-title: "Échantillonnage — Processus de contrôle qualité"
+title: "Échantillonnage - Processus de contrôle qualité"
-tags: [picking, échantillonnage, inventaire, qualité, poste, custom]
+tags: [picking, échantillonnage, inventaire, qualité, poste, custom, cor, cof]
 status: draft
-standard_ref: concepts/inventory.md
+standard_ref: concepts/count.md
-jira_refs: []
+jira_refs: [LIM-107, LIM-112]
 confluence_refs: []
-sources: [FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5.docx]
+sources: [FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5.docx, "Jira LIM-107 (lecture directe 2026-07-20)", "Jira LIM-112 (lecture directe 2026-07-20)"]
-last_updated: 2026-05-05
+last_updated: 2026-07-20
 author: Arthur
 ---
-# Échantillonnage — Processus de contrôle qualité
+# Échantillonnage - Processus de contrôle qualité
 > **Résumé** : processus [CUSTOM] d'échantillonnage pour contrôle qualité,
 > assimilé à un inventaire dans EasyWMS, avec prélèvement sur poste de travail.
@@ -18,6 +18,11 @@ author: Arthur
 > **Standard EasyWMS** : → voir [Inventory](../../concepts/count.md)
 > Ce qui suit documente les **spécificités Limagrain** par rapport au standard.
 > **Statut (LIM-112)** : Ouvert. Cette page décrit le **flux complet**
 > (message COR → ordre d'inventaire → assignation stock/poste → process
 > opérateur → COF). Le **contenu de l'étiquette** relève de LIM-107 (cette
 > tâche ne fait que déclencher l'impression au poste).
 ## Contexte projet
 L'échantillonnage sert au contrôle qualité sur une partie des lots
@@ -34,11 +39,30 @@ Deux modes de création :
 | Mode | Origine | Détail |
 |------|---------|--------|
-| Interface ERP | Message de l'ERP (COR) | Spécifie un lot à inventorier |
+| Interface ERP | Message **COR** | Spécifie un lot à échantillonner |
 | Manuel | Interface EasyWMS | Choix d'un lot par l'opérateur |
-[CUSTOM] Un champ texte est disponible pour donner des **consignes**
+L'ordre d'inventaire est créé avec une **priorité 3 (basse)**.
-rattachées à l'ordre d'inventaire.
+
 [CUSTOM] Un champ texte libre est disponible pour des **consignes**
 rattachées à l'ordre (porté par `CstAtt02` de la ligne d'inventaire - voir
 [AD Customs](../07-admin/ad-customs.md#cstatt-ligne-dordre-dinventaire)).
 ### Mapping du message COR (SAP → WMS)
 | Balise | Valeur |
 |--------|--------|
 | `Code` | Numéro du lot d'inspection SAP |
 | `Description` | `ECHANTILLONNAGE` (déclencheur de création de l'ordre) |
 | `Priority` | 3 (basse) |
 | `CstAtt01` | Nombre de palettes à inventorier (toujours 4 d'après SAP) |
 | `CstAtt02` | Texte libre de consignes rattaché à l'ordre |
 | `ProductCode` | Code **lot** SAP |
 | `LotCode` | Code **produit** SAP |
 | `Color` / `Source` / `Size` | Propriétaire réel SAP / Description produit / Destination (pays) |
 > ⚠️ Mapping **inversé** `ProductCode` / `LotCode` : côté SAP,
 > `ProductCode` porte le code **lot** et `LotCode` le code **produit**.
 ## [CUSTOM] Assignation du stock
@@ -46,22 +70,36 @@ L'assignation diffère selon le mode de création :
 ### Création par interface ERP
- Maximum **4 palettes** échantillonnées :
+- Maximum **`CstAtt01` palettes** échantillonnées (valeur du COR, toujours
-  - Si stock global < 4 → toutes les palettes
+  4 d'après SAP) ; moins si le stock total n'atteint pas `CstAtt01`.
  - Si stock global ≥ 4 → 4 palettes sélectionnées
 - [CUSTOM] Les palettes avec un verrou d'écart de poids (« Production »)
-  sont **prioritaires** pour permettre une vérification simultanée
+  sont **prioritaires** (vérification simultanée au recomptage).
 - **Prérequis** de chaque palette assignée : allée non bloquée, palette
  rangée, non client, aucune tâche associée au support.
 - **Ordre de sélection** (`OrderByDesc`) : palette bloquée d'abord, puis
  par profondeur (la **moins profonde** en premier).
 ### Création manuelle
- Nombre de palettes choisi par l'opérateur
+- Nombre de palettes choisi par l'opérateur (input custom). `CstAtt01` est
  saisissable/éditable après la création de l'inventaire manuel, mais
  **plus une fois l'inventaire lancé**.
 > **Règle transverse** : un article en cours d'échantillonnage **n'est plus
 > disponible** pour les ordres de sortie (comportement standard d'un
 > inventaire).
 ## Assignation poste de travail
 - Automatique, à condition que le poste soit ouvert et autorise le
-  mode « échantillonnage »
+  mode « échantillonnage » (= mode **Inventaire** EasyWMS).
- Si aucun poste paramétré en mode échantillonnage → tâches en attente
+- L'orchestration passe par le **Mega Job d'assignation PK** (LIM-70), qui
- Une fois le poste assigné → création des tâches de mouvement
+  appelle un sous-workflow dédié (développé dans LIM-112) pour trouver et
  assigner le bon PK. Si le support est un **Big-bag**, sélection d'un PK
  qui l'autorise. Voir
  [Mini jobs d'assignation au PK](job-assignation-pk.md).
 - Si aucun poste paramétré en mode échantillonnage → tâches en attente.
 - Une fois le poste assigné → création des tâches de mouvement.
 ## Processus sur poste de travail
@@ -90,14 +128,45 @@ Le processus est démarré et effectué sur **une seule palette à la fois**.
 ### Séquence opérateur
 1. [CUSTOM] Si verrou « Réception » → recomptage avant échantillonnage
   (à développer en **standalone**, car réutilisé dans plusieurs process)
 2. Prendre une pochette d'échantillonnage vide (hors EasyWMS)
 3. Effectuer un prélèvement dans un des sacs (~200g, hors EasyWMS)
 4. Déposer le prélèvement dans la pochette (hors EasyWMS)
-5. Éditer et imprimer une **étiquette d'échantillonnage**
+5. Éditer et imprimer une **étiquette d'échantillonnage** (LIM-107)
 6. Coller l'étiquette sur la pochette (hors EasyWMS)
 7. Scotcher le sac ouvert sur la palette (hors EasyWMS)
-8. [CUSTOM] Choix filmage depuis vue spécifique (programme à définir)
+8. [CUSTOM] Choix du programme de filmage depuis une vue spécifique
-9. Évacuer la palette vers le stockage
+9. **Valider la ligne d'inventaire**
 10. Évacuer la palette vers le stockage : l'AGV déplace le conteneur du
    poste vers la table d'entrée ; la palette est filmée ou non avant de
    passer le PIE
 ## Étiquette d'échantillonnage (LIM-107)
 > **Statut (LIM-107)** : en revue de code.
 L'étiquette d'échantillonnage (étape 5 ci-dessus) est imprimée au **format
 A5** sur l'**étiqueteuse du poste de travail** (et non sur les étiqueteuses
 automatiques d'expédition), via le **flux inventaire COR/COF** (report
 `CST_RPT_ECHANTILLONAGE`). Voir aussi
 [Flux expédition - Étiquettes par type](../04-outbound/flux-expedition.md#contenu-des-étiquettes-dexpédition-par-type-lim-107).
 Contenu de l'étiquette :
 | # | Champ |
 |---|-------|
 | 1 | `ITM.CstAtt01` |
 | 2 | `ITM.CstAtt03` |
 | 3 | `ITM.CstAtt07` |
 | 4 | `ITM.CstAtt08` |
 | 5 | `ITM` - Famille de l'article |
 | 6 | `ProductCode` de la ligne d'inventaire |
 | 7 | `ITM.CstAtt10` |
 | 8 | `Stock` - Attribut taille |
 | 9 | « `_ / _` » laissé vide (complété au stylo par l'opérateur) |
 | 10 | `ITM` - Premier alias différent du code article |
 | 11 | `COR.Code` encodé en 128 |
 | 12 | `COR.Code` |
 ## Passage PIE post-échantillonnage
@@ -114,10 +183,23 @@ Contrôle identique aux autres processus :
 Si PIE NOK → rejet vers poste d'origine. Possibilité de forcer le
 passage en cas d'excédent de poids non corrigeable.
 ## Clôture et émission du COF (LIM-112)
 À la clôture de l'ordre d'inventaire (ou en cas d'**annulation**), le WMS
 émet le message **COF** (WMS → SAP) :
 | Balise | Description |
 |--------|-------------|
 | `CountCode` | Numéro du lot d'inspection |
 | `Status` | `Closed` (effectué) ou `Cancelled` (annulé) |
 | `UpdateDate` | Date/heure du changement d'état |
 Le traitement du COF côté SAP est **hors périmètre** (équipes IT Limagrain).
 ## Points d'attention
 ⚠️ L'échantillonnage est un processus d'**inventaire** dans EasyWMS,
-pas un processus de picking — important pour le paramétrage des modes
+pas un processus de picking - important pour le paramétrage des modes
 de poste.
 ⚠️ Les palettes avec verrou « Production » (écart poids) sont traitées
@@ -126,20 +208,33 @@ en priorité pour optimiser le recomptage.
 ⚠️ La quantité prélevée (~200g) n'est pas déduite du stock dans EasyWMS
 (négligeable par rapport au poids total).
 ⚠️ Des **big-bags** peuvent être présents dans ce process (LIM-112) → le
 poste assigné doit autoriser les big-bags.
 ## Questions ouvertes
- [ ] Le prélèvement de 200g est-il déduit du stock ou négligé ? (@Nicolas)
+- [x] ~~Le prélèvement de 200g est-il déduit du stock ou négligé ? (@Nicolas)~~ → **Résolu** (LIM-112) : négligé, non déduit du stock
- [ ] Programme de filmage exact (@Théo)
+- ❓ Programme de filmage exact (@Théo)
- [ ] Format de l'étiquette d'échantillonnage — validé ? (@Justine)
+- [x] ~~Format de l'étiquette d'échantillonnage - validé ? (@Justine)~~ → Résolu (LIM-107) : format **A5**, contenu défini (12 champs), report `CST_RPT_ECHANTILLONAGE`, imprimé sur l'étiqueteuse du poste de travail
 - Consignes d'échantillonnage : le mapping COR porte les consignes sur
  `CstAtt02`, mais le commentaire du ticket évoque `CstAtt01` → point à
  confirmer avec le client (mail à faire, @Arthur)
 - Dépendance `CstAtt10` (Stage) côté ITM : requis pour l'étiquette
  d'échantillonnage (LIM-107) ; à vérifier en préprod (@Nicolas) → voir
  [Questions ouvertes](../08-transverse/questions-ouvertes.md)
 ## Historique des modifications
 | Date | Auteur | Modification |
 |------|--------|--------------|
 | 2026-05-05 | Arthur | Création initiale depuis AF V1.5 |
 | 2026-07-20 | Arthur | LIM-107 (lecture directe) : section « Étiquette d'échantillonnage » (format A5, 12 champs, report `CST_RPT_ECHANTILLONAGE`, impression étiqueteuse poste via flux COR/COF) ; question format d'étiquette résolue ; front matter jira_refs/sources/last_updated |
 | 2026-07-20 | Arthur | LIM-112 (lecture directe, Ouvert) : flux complet - mapping COR (Code/Description/Priority 3/CstAtt01 nb pal/CstAtt02 consignes/ProductCode-LotCode inversés/Color-Source-Size) ; assignation stock refondue (CstAtt01, prérequis palette, OrderByDesc bloquée puis profondeur, éditabilité CstAtt01 manuel) ; règle transverse indisponibilité stock ; orchestration Mega Job PK LIM-70 + sous-workflow + big-bag ; séquence opérateur (recomptage standalone, validation ligne inventaire, AGV→table entrée→PIE) ; nouvelle section « Clôture et émission du COF » ; big-bag confirmé ; 200g non déduit résolu ; 2 questions ouvertes (consignes CstAtt01/02, dépendance CstAtt10 Stage) ; front matter jira_refs +LIM-112/sources/tags |
 ## Références
 | Source | Type | Date |
 |--------|------|------|
 | FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5 | Analyse fonctionnelle | 28/11/2025 |
 | [LIM-107](https://easywmsfrance.atlassian.net/browse/LIM-107) | Ticket Jira (étiquettes expédition/échantillonnage, en revue de code) | 2026 |
 | [LIM-112](https://easywmsfrance.atlassian.net/browse/LIM-112) | Ticket Jira (process échantillonnage complet COR→COF, Ouvert) | 2026 |
@@ -1,16 +1,16 @@
 ---
-title: "Mega Job — Assignation des tâches aux PK"
+title: "Mega Job - Assignation des tâches aux PK"
 tags: [picking, job, assignation, agv, workflow]
 status: draft
 standard_ref: concepts/picking.md
-jira_refs: [LIM-70, LIM-74, LIM-75, LIM-80]
+jira_refs: [LIM-70, LIM-74, LIM-75, LIM-80, LIM-82, LIM-106]
 confluence_refs: []
-sources: ["LIM-70 LOT1.3 [AGV][JOB] MEGA JOB - assignation d'ordre par priorité de process par PK.md", "LIM-80 LOT2.1 2 Mini Job Assignation des postes PK aux commandes.md"]
+sources: ["LIM-70 LOT1.3 [AGV][JOB] MEGA JOB - assignation d'ordre par priorité de process par PK.md", "LIM-80 LOT2.1 2 Mini Job Assignation des postes PK aux commandes.md", "Jira LIM-106 (lecture directe 2026-07-20)"]
-last_updated: 2026-05-12
+last_updated: 2026-07-20
 author: Arthur
 ---
-# Mega Job — Assignation des tâches aux PK
+# Mega Job - Assignation des tâches aux PK
 > **Résumé** : job unique « chef d'orchestre » qui analyse les postes de
 > travail éligibles et leur assigne des tâches de mouvement selon les
@@ -24,6 +24,11 @@ author: Arthur
 ## Contexte projet
 > **Statut (LIM-70)** : dev terminé, **en préprod / attente déploiement pour
 > test**. Deux revues de code validées : la première le 03/04/2026, la
 > seconde le 29/06/2026 après ajout de la condition « OS en Releasing » et du
 > contrôle `CstAtt06` sur l'éligibilité.
 Chez Limagrain, les postes de travail (PK) sont polyvalents : réception,
 picking, regroupement, échantillonnage, re certification. Plusieurs
 flux différents génèrent des tâches de mouvement vers les PK. Sans
@@ -41,14 +46,36 @@ conditions suivantes doivent être remplies :
 - **Aucun ordre de sortie** assigné au PK (écran Menu > Contrôle >
  Affectation des postes de prélèvements)
 - **Aucune tâche de mouvement** ayant pour destination ce PK
- **Aucune palette** présente sur un des sous-emplacements du PK
+- **Aucune palette** présente sur un des sous-emplacements du PK (table de
  préparation associée comprise)
 - **Aucun conteneur de réception assigné au PK via son `CstAtt06`** (le
  `CstAtt06` porte le code du picking lié à un conteneur de réception) -
  contrôle ajouté le 26/06/2026
 - **Le poste est ouvert** (mode actif)
- **Le paramètre MODES_PKxx existe et n'est pas vide** — sinon le PK
+- **Le paramètre MODES_PKxx existe et n'est pas vide** - sinon le PK
  est ignoré
 Si un PK ne remplit pas ces conditions, le job le saute et passe au
 suivant.
 > Le contrôle `CstAtt06` confirme l'usage de cet attribut côté réception
 > (conteneur ↔ poste de picking lié, cf. LIM-67) - voir le point de conflit
 > d'usage dans [questions ouvertes](../08-transverse/questions-ouvertes.md).
 ### Condition de sortie globale - OS en Releasing
 Avant toute assignation, le job vérifie qu'**aucun ordre de sortie (OS)
 n'est au statut `Releasing`** (query `CST_AnyOutboundOrderReleasingStatus`).
 Si au moins un OS est en Releasing → le job **sort immédiatement** sans
 essayer aucun mode (réception, picking, recertif…).
 **Motif** : lors de la libération d'un lot de commandes, le WMS les libère
 dans un ordre quelconque (pas forcément par priorité). Assigner pendant le
 release risquerait de placer une commande peu prioritaire au détriment d'une
 commande plus prioritaire libérée quelques secondes plus tard - ou de lancer
 une réception sur un PK en priorité picking.
 ## Logique principale
 ```mermaid
@@ -82,6 +109,14 @@ Pour chaque PK éligible :
 5. Sinon → exécution du sous-WF du mode suivant dans l'ordre de priorité
 6. Si aucun sous-WF n'a rien assigné → le PK reste en attente
 ## Éléments AD (LIM-70)
 | Élément AD | Type | Rôle |
 |------------|------|------|
 | `CST_PickingStationAssignment_Job` | Workflow + Job | Job orchestrateur : vérifie les modes autorisés des PK et tente d'assigner un ordre selon les priorités définies pour la station (LIM-69). **Intervalle : 5 secondes**. |
 | `CST_PickingStations_AvailableForAssignation` | Query | Récupère les PK disponibles pour une nouvelle assignation : poste ouvert, sans conteneur ni tâche vers sa position (ni sa table de préparation), sans ordre assigné, et sans conteneur de réception assigné via `CstAtt06`. |
 | `CST_AnyOutboundOrderReleasingStatus` | Query | Indique s'il existe au moins un OS au statut `Releasing` → condition de sortie globale du job. |
 ## Gestion des Big-Bags
 Le paramètre `PK_BIGBAG` définit quels PK autorisent la présence de
@@ -100,91 +135,211 @@ spécialisés :
 | Sous-WF | Ticket | Process | Page wiki |
 |---------|--------|---------|-----------|
 | Mini Job images de quai → PK | [LIM-74](https://easywmsfrance.atlassian.net/browse/LIM-74) | Réception fournisseur / intersite / retour client (depuis images de quai) | [Job réception PK](../05-agv/job-reception-pk.md) |
-| Mini Job PS → PK | [LIM-75](https://easywmsfrance.atlassian.net/browse/LIM-75) | _(tâche à écrire)_ | — |
+| Mini Job PS → PK | ~~[LIM-75](https://easywmsfrance.atlassian.net/browse/LIM-75)~~ **Annulé** → [LIM-82](https://easywmsfrance.atlassian.net/browse/LIM-82) | PS (picking station) → PK. Détail reporté à LIM-82 | _(à écrire sur LIM-82)_ |
 | Mini Job assignation commandes → PK | [LIM-80](https://easywmsfrance.atlassian.net/browse/LIM-80) | Assignation des ordres de sortie (commandes) aux PK pour picking | Voir section ci-dessous |
 | Mini Job assignation recertification → PK | [LIM-106](https://easywmsfrance.atlassian.net/browse/LIM-106) | Assignation des OS de classe RECERTIFICATION aux PK + création des tâches d'acheminement (conteneurs d'expédition → PK) et de chargement au quai recertification | Voir section ci-dessous |
 Chaque sous-workflow retourne une information au WF principal indiquant
 s'il a assigné quelque chose ou non.
-## Mini Job — Assignation commandes aux PK (LIM-80)
+## Mini Job - Assignation commandes aux PK (LIM-80)
-Ce sous-workflow est appelé par le Mega Job quand le mode **Picking** est
+> **Statut (LIM-80)** : dev terminé, **en cours de test client
-actif sur un PK. Il assigne un ordre de sortie (commande) au poste.
+> (pré-production)**. Revue de code validée le **26/06/2026**.
-### Éligibilité du PK pour une commande
+Ce sous-workflow est le **mode Picking** du Mega Job. Il est appelé quand le
 mode Picking est actif sur un PK éligible et assigne un **ordre de sortie
 (OS)** au poste.
-Le PK peut recevoir une commande si **toutes** les conditions sont
+En standard EasyWMS, l'assignation des commandes aux PK est gérée par le
-remplies :
+workflow `OutboundOrder_AssignPKMP_ByWarehouse_WF`, déclenché par des
 subscriptions événementielles (ouverture de station, changement de mode de
 travail, etc.). Chez Limagrain ce déclenchement événementiel est
 **désactivé** (8 subscriptions passées en `Disabled`, cf. tableau plus
 bas) : c'est le Mega Job qui orchestre l'assignation lorsqu'un PK est
 éligible en mode Picking.
- Le PK **autorise la préparation de commande** (mode Picking actif)
+### Éligibilité du PK
 - Le PK **n'a pas de commande déjà assignée**
 - Le PK **est vide** (aucune palette présente)
 - Le PK **n'a aucune tâche en direction de celui-ci**
-### Choix de la commande
+L'éligibilité du PK est **entièrement vérifiée par le Mega Job** (cf.
 section [Éligibilité d'un PK](#éligibilité-dun-pk) ci-dessus) avant l'appel
 de ce mini job. Le mini job ne refait pas ces contrôles : il reçoit un PK
 déjà qualifié en mode Picking.
-```mermaid
+### OS concernés
 flowchart TD
    A[PK éligible en mode Picking] --> B{Commande Messagerie\ndisponible ?}
    B -- Oui --> C{PK_TRANSPORTEUR_MESSAGERIE\ncontient une valeur ?}
    C -- Non --> D[Assigner 1ère Messagerie\net enregistrer PK dans param]
    C -- Oui --> E{Valeur = ce PK ?}
    E -- Oui --> F[Assigner prochaine Messagerie\ndu même transporteur]
    F --> G{Commande trouvée ?}
    G -- Non --> H[Vider le paramètre]
    E -- Non --> I[Ignorer les Messagerie\nde ce transporteur]
    I --> J[Chercher autre commande]
    B -- Non --> J
    H --> J
    J --> K[Assignation standard\npar tournée / numéro d'arrêt]
 ```
-#### Commandes Messagerie (prioritaires)
+Tous les OS au statut `Release` ayant du stock assigné avec du picking à
 réaliser sont concernés, quel que soit leur type (commande client,
 messagerie palette, messagerie carton), **sauf la recertification**
 (`OutboundClassCode == RECERTIFICATION`).
-Les commandes de **classe Messagerie** sont expédiées le jour même et
+Le PK ayant déjà été choisi par le Mega Job, le mini job assigne l'OS sur
-sont donc **prioritaires** sur les commandes standard.
+**ce PK** (contrairement au standard, pas de recalcul de routage ni de
 choix de PK).
-Une fois un PK choisi pour une commande Messagerie, **toutes les
+### Choix de la commande - critères de tri
 commandes Messagerie du même transporteur** doivent être assignées au
 même PK. Pour cela, un paramètre par transporteur est créé :
 `PK_TRANSPORTEUR_MESSAGERIE`.
-Règles :
+L'OS le mieux assignable est sélectionné par la query
 `CST_OutboundOrder_BestPendingAssignment_ForPK` (OS `Released`, hors classe
 `RECERTIFICATION`, sans assignation existante, disposant de supports de
 picking). Les OS candidats sont triés dans cet ordre (**arbitrage Justine
 du 19/06/2026**) :
- À l'assignation d'une commande Messagerie au PK, le nom du PK est
+1. **Priorité de l'OS** - définie par l'ERP dans le SOR/RUT
-  enregistré dans le paramètre
+2. **Tâches de shipping** - un OS déjà en cours de shipping passe en
- Si le paramètre contient le nom de ce PK → assigner **uniquement**
+   priorité, pour finir la commande en cours
-  des commandes Messagerie du même transporteur. Si aucune n'est
+3. **Date de libération** - la plus ancienne en premier
  trouvée → vider le paramètre
 - Si le paramètre contient un autre PK → ignorer toutes les commandes
  Messagerie de ce transporteur pour ce PK
-#### Commandes standard
+> Le premier jet (revue de code du 05/06/2026) triait par priorité →
 > nombre de conteneurs de picking (décroissant) → date de libération. Le
 > tri a été revu le 19/06/2026 : le critère « OS déjà en cours de shipping »
 > remonte au-dessus du nombre de conteneurs, pour ne pas laisser une
 > commande à moitié préparée.
-Le processus standard est utilisé pour assigner une commande à une
+> **Priorité Messagerie** : il n'y a **pas** de priorisation custom côté WMS
-table de préparation et un PK. Les commandes d'une même tournée sont
+> pour les commandes Messagerie. C'est SAP qui gère leur priorité en amont
-préparées en respectant le **numéro d'arrêt** (plus petit numéro
+> via la priorité du SOR (une Messagerie à expédier le jour même reçoit une
-d'arrêt en premier).
+> priorité plus haute). Le paramètre `PK_TRANSPORTEUR_MESSAGERIE` envisagé
 > initialement n'a **pas** été implémenté.
 > ⚠️ À confirmer côté client (cf.
 > [questions ouvertes](../08-transverse/questions-ouvertes.md)).
 ### Création des tâches de picking
 Après l'assignation, les tâches de picking sont créées (sortie des palettes
 source du TK vers le PS/PK). Elles alimentent le séquençage TK → PS
 ([LIM-84](https://easywmsfrance.atlassian.net/browse/LIM-84)).
 ### Éléments AD (LIM-80)
 | Élément AD | Type | Rôle |
 |------------|------|------|
 | `CST_PickingStationAssignment_Picking_PR` | Workflow | Mode Picking du Mega Job : récupère le meilleur OS assignable et crée l'assignation PK. |
 | `CST_OutboundOrder_BestPendingAssignment_ForPK` | Query | Meilleur OS assignable (Released, hors RECERTIFICATION, sans assignation, avec supports de picking), trié priorité → tâches de shipping → date de libération. |
 > Le workflow orchestrateur `CST_PickingStationAssignment_Job` (déjà décrit
 > dans [Éléments AD (LIM-70)](#éléments-ad-lim-70)) a été enrichi de l'appel
 > de ce mini job d'assignation picking.
 ### Subscriptions désactivées
 Le déclenchement événementiel standard de
 `OutboundOrder_AssignPKMP_ByWarehouse_WF` est neutralisé (le Mega Job prend
 le relai). Les 8 subscriptions suivantes sont passées en `Disabled` :
 | Subscription | Event |
 |---|---|
 | `PickingStationOpenedStationEvent_OutboundOrder_AssignPKMP_ByWarehouse` | Ouverture d'un PK |
 | `PickingStationChangeWorkModeEvent_OutboundOrder_AssignPKMP_ByWarehouse` | Changement mode de travail PK |
 | `PickingStationChangedMaxOutboundOrdersEvent_OutboundOrder_AssignPKMP_ByWarehouse` | Changement max OS sur PK |
 | `MpStationChangeWorkModeEvent_OutboundOrder_AssignPKMP_ByWarehouse` | Changement mode de travail MP |
 | `MpStationAssignedModeEvent_OutboundOrder_AssignPKMP_ByWarehouse_WF` | Mode assigné à MP |
 | `DockStationChangeWorkModeEvent_OutboundOrder_AssignPKMP_ByWarehouse` | Changement mode de travail Dock |
 | `OrderAssignDeletedEvent` | Suppression d'une assignation de PK |
 | `OutboundOrderAssignedRouteEvent_OutboundOrder_AssingPKMP_ByWarehouse` | Assignation d'un OS à une route |
 ## Mini Job - Assignation recertification aux PK (LIM-106)
 > **Statut (LIM-106)** : dev terminé, **en attente de déploiement pour test**
 > (livré en préprod le 03/06/2026). Revue de code Maxime le 29/06/2026
 > (ajustements ci-dessous).
 Ce sous-workflow est le **mode Recertification** du Mega Job. Il est le
 pendant du mini job picking ([LIM-80](https://easywmsfrance.atlassian.net/browse/LIM-80)),
 mais pour les OS de classe **RECERTIFICATION** - que LIM-80 exclut
 justement de l'assignation picking standard. Le process de poste associé
 est décrit dans [Recertification - Workstation au PK](recertification.md).
 ### Assignation du PK
 Le meilleur OS recertification en attente est sélectionné par la query
 `CST_OutboundOrder_Recertification_BestPendingAssignment_ForPK` et assigné
 au PK éligible. Les candidats sont triés dans cet ordre :
 1. **Priorité de l'OS**
 2. **Date de libération** - la plus ancienne en premier
 ### Création des tâches
 Les palettes à acheminer au poste sont des **conteneurs d'expédition**. Le
 process de création des tâches d'expédition standard est donc intercepté :
 `Outbound_CreateShippingContainersTasks_PR` filtre les OS de classe
 RECERTIFICATION et redirige vers le sous-WF custom
 `CST_Outbound_Recertification_CreateShippingContainersTasks_PR`, qui
 récupère le PK assigné à l'OS et crée les **tâches de mouvement** des
 conteneurs vers ce PK.
 À l'arrivée du conteneur au PK (`Container_MovedEventHandler_PK_PR`), une
 **tâche de chargement vers le quai de recertification** est créée. La tâche
 de mouvement est marquée `ProcessType = "recertification"`
 (`Container_MovedEvent_PR_V1`) et porte le flag **`CstAtt02` = Recertification**
 (affiché « Recertification » dans la vue des tâches `TaskVList`) - voir
 [Catalogue AD customs - CstAtt Tâche](../07-admin/ad-customs.md#cstatt-tâche-task).
 > **CstAtt de recertification : 01 → 02.** Le premier jet (revue Vincent
 > 03/06) posait le flag sur le `CstAtt01` de la tâche ; il a été **déplacé
 > sur le `CstAtt02`** (Maxime 26/06/2026), le `CstAtt01` étant réservé au
 > numéro de séquence picking (LIM-84).
 ### Annulation des tâches
 Si le conteneur d'expédition est supprimé (`ShippingContainerDeletedEvent`),
 la souscription `CST_ShippingContainerDeleted_CancelRecertificationTask`
 appelle `CST_Container_CancelRecertificationTasks` qui **annule les tâches
 de mouvement** de recertification associées au conteneur.
 ### Garde-fous (revue Maxime 29/06/2026)
 - **Pas de tâche générée** si le conteneur porte déjà une tâche, ou si le
  support est **sur l'AGV**.
 - **Blocage de la génération** de tâche si **aucun quai n'est assigné** à
  l'OS de type RECERTIFICATION (erreur dans l'ordre de sortie).
 ### Éléments AD (LIM-106)
 | Élément AD | Type | Rôle |
 |------------|------|------|
 | `CST_PickingStationAssignment_Recertification_PR` | Workflow | Mode Recertification du Mega Job : sélectionne le meilleur OS recertification en attente et crée l'assignation PK. |
 | `CST_Outbound_Recertification_CreateShippingContainersTasks_PR` | Workflow | Récupère le PK assigné à l'OS et crée les tâches de mouvement des conteneurs d'expédition vers le PK. |
 | `Outbound_CreateShippingContainersTasks_PR` | Workflow | Modifié : filtre les OS de classe RECERTIFICATION et redirige vers le sous-WF custom de création de tâches. |
 | `Outbound_GetOutboundOrderShippingContainersAndPsGroup_PR` | Workflow | Modifié : remonte le code de classe et la priorité de l'OS. |
 | `Container_MovedEvent_PR_V1` | Workflow | Modifié : positionne `ProcessType = "recertification"` sur la tâche si l'OS est de classe recertification. |
 | `Container_MovedEventHandler_PK_PR` | Workflow | Modifié : crée une tâche de chargement vers le quai de recertification quand un conteneur termine une tâche de mouvement d'un OS recertification. |
 | `CST_Container_CancelRecertificationTasks` | Workflow | Récupère et annule les tâches de recertification d'un conteneur (appelé par la souscription). |
 | `CST_OutboundOrder_Recertification_BestPendingAssignment_ForPK` | Query | Meilleur OS recertification assignable à un PK (tri priorité → date de libération). |
 | `CST_OutboundOrderLineDetails_ByRecertificationContainer` | Query | Détails de ligne d'OS pour un conteneur d'un OS recertification. |
 | `CST_RecertificationTasks_ByContainer` | Query | Tâches de recertification associées à un conteneur. |
 | `CST_ShippingContainerDeleted_CancelRecertificationTask` | Subscription | Sur `ShippingContainerDeletedEvent`, appelle `CST_Container_CancelRecertificationTasks`. |
 | `TaskVList` | Vue | Ajout du `CstAtt02` (flag « tâche de recertification »). |
 | `CST_Task_CustomAttribute1` | Ressource i18n | Libellé FR/EN « Recertification » de la colonne CstAtt tâche. |
 ## Points d'attention
 ⚠️ Le Mega Job est le chef d'orchestre du picking : il distribue le
 travail aux PK en fonction des modes configurés par PK.
-⚠️ Les commandes Messagerie sont prioritaires et ont une affinité
+⚠️ Priorité Messagerie gérée par SAP via la priorité du SOR - pas de
-transporteur/PK via `PK_TRANSPORTEUR_MESSAGERIE`.
+custom WMS (`PK_TRANSPORTEUR_MESSAGERIE` non implémenté).
-⚠️ L'éligibilité PK vérifie 4 conditions (mode autorisé, pas de
+⚠️ L'éligibilité PK vérifie plusieurs conditions (poste ouvert, pas de
-commande, vide, pas de tâche en cours).
+commande, vide, pas de tâche en cours, pas de conteneur réception lié via
 `CstAtt06`, `MODES_PKxx` non vide).
 ⚠️ Le job **sort globalement** si au moins un OS est en `Releasing` (pas
 d'assignation pendant une libération de commandes).
 ## Questions ouvertes
- [ ] Fréquence du Mega Job — toutes les N secondes ou événementiel ?
+- ~~Fréquence du Mega Job - toutes les N secondes ou événementiel ?~~
-  (@Nicolas)
+  → **Résolu (LIM-70)** : job périodique, intervalle **5 secondes**.
- [ ] Sous-WF regroupement et échantillonnage — quand les documenter ?
+- ❓ Sous-WF regroupement et échantillonnage - quand les documenter ?
  (@Arthur)
- [ ] Interaction PK_BIGBAG et modes de travail — un PK en mode
+- ❓ Interaction PK_BIGBAG et modes de travail - un PK en mode
  Big-Bag peut-il aussi traiter du picking normal ? (@Nicolas)
 - Confirmer côté client que SAP gère la priorité des commandes Messagerie
  dans le SOR - `PK_TRANSPORTEUR_MESSAGERIE` abandonné (LIM-80)
  (@Arthur → Nicolas/Olivier) → voir
  [questions ouvertes](../08-transverse/questions-ouvertes.md)
 ## Historique des modifications
@@ -193,11 +348,18 @@ commande, vide, pas de tâche en cours).
 | 2026-05-12 | Arthur | Création initiale depuis LIM-70 (Mega Job) |
 | 2026-05-12 | Arthur | Ajout sous-WF assignation commandes (LIM-80) : Messagerie prioritaire, affinité transporteur/PK |
 | 2026-05-13 | Arthur | Restauration sections tronquées (Messagerie détail, commandes standard, points d'attention, questions, historique, références) |
 | 2026-07-17 | Arthur | Relecture commentaires LIM-70 : section Éléments AD (CST_PickingStationAssignment_Job intervalle 5s, CST_PickingStations_AvailableForAssignation, CST_AnyOutboundOrderReleasingStatus), condition de sortie globale « OS en Releasing », contrôle éligibilité CstAtt06, statut préprod + 2 revues de code, résolution question fréquence (5s) |
 | 2026-07-17 | Arthur | LIM-75 (Mini Job PS → PK) confirmé Annulé → repris par LIM-82 : table sous-workflows annotée |
 | 2026-07-17 | Arthur | Relecture revue de code LIM-80 (préprod, validée 26/06) : refonte section mini job assignation (query `CST_OutboundOrder_BestPendingAssignment_ForPK`, WF `CST_PickingStationAssignment_Picking_PR`, 8 subscriptions désactivées, OS hors RECERTIFICATION) ; tri final priorité → tâches de shipping → date de libération (arbitrage Justine 19/06) ; abandon `PK_TRANSPORTEUR_MESSAGERIE`, priorité Messagerie gérée par SAP/SOR |
 | 2026-07-20 | Arthur | LIM-106 (lecture directe, attente déploiement test) : nouvelle section « Mini Job assignation recertification aux PK » (assignation OS RECERTIFICATION triée priorité → date de libération, création tâches de mouvement conteneurs d'expédition → PK + tâche chargement quai recertification, annulation sur suppression conteneur, garde-fous Maxime 29/06, flag CstAtt02 tâche déplacé du 01) ; ligne ajoutée à la table des sous-workflows |
 ## Références
 | Source | Type | Date |
 |--------|------|------|
-| [LIM-70](https://easywmsfrance.atlassian.net/browse/LIM-70) | Ticket Jira (Mega Job) | 2026 |
+| [LIM-70](https://easywmsfrance.atlassian.net/browse/LIM-70) | Ticket Jira (Mega Job, 7 commentaires) | 2026-04 → 2026-06 |
-| [LIM-80](https://easywmsfrance.atlassian.net/browse/LIM-80) | Ticket Jira (assignation commandes) | 2026 |
+| [LIM-80](https://easywmsfrance.atlassian.net/browse/LIM-80) | Ticket Jira (assignation OS aux PK, 6 commentaires, préprod) | 2026-06 |
-| [LIM-74](https://easywmsfrance.atlassian.net/browse/LIM-74) | Ticket Jira (Mini Job réception PK) | 2026 |
+| [LIM-74](https://easywmsfrance.atlassian.net/browse/LIM-74) | Ticket Jira (Mini Job réception PK) | 2026 |
 | [LIM-75](https://easywmsfrance.atlassian.net/browse/LIM-75) | Ticket Jira (Mini Job PS → PK, **Annulé** → LIM-82) | 2026 |
 | [LIM-82](https://easywmsfrance.atlassian.net/browse/LIM-82) | Ticket Jira (Mini Job PS → PK, reprise) | 2026 |
 | [LIM-106](https://easywmsfrance.atlassian.net/browse/LIM-106) | Ticket Jira (Mini Job assignation recertification aux PK, 3 commentaires, attente déploiement test) | 2026-06 |
@@ -1,5 +1,5 @@
 ---
-title: "Picking sur poste de travail — Expédition client"
+title: "Picking sur poste de travail - Expédition client"
 tags: [picking, poste, expédition, ordonnancement, MOV, PCK]
 status: draft
 standard_ref: concepts/picking.md
@@ -10,7 +10,7 @@ last_updated: 2026-05-13
 author: Arthur
 ---
-# Picking sur poste de travail — Expédition client
+# Picking sur poste de travail - Expédition client
 > **Résumé** : processus [CUSTOM] de picking sur poste de travail pour
 > les commandes client, avec ordonnancement par espèce, règles de picking
@@ -61,7 +61,7 @@ sur une même palette fille.~~
 Limagrain ne fait pas de bio, pas de raison de maintenir cette
 contrainte. Paramètre réactivable si besoin futur.
-> Voir [Séquençage TK → PS — Arbitrage](sequencage-tk-ps.md#arbitrage-des-contradictions-reu-11052026)
+> Voir [Séquençage TK → PS - Arbitrage](sequencage-tk-ps-historique.md#arbitrage-des-contradictions-réu-11052026)
 > pour le détail de l'analyse comparative.
 ## [CUSTOM] Règle du picking négatif
@@ -83,7 +83,7 @@ classique.
 > Le picking négatif est **prioritaire sur Maïs first** et toutes les
 > autres règles de tri (confirmé par Olivier, réu. 11/05/2026).
-> Voir [Séquençage TK → PS](sequencage-tk-ps.md#critère-1--picking-négatif-en-premier).
+> Voir [Séquençage TK → PS](sequencage-tk-ps.md#critère-1---picking-négatif-en-premier).
 ## [CUSTOM] Calcul équivalent palette (pro rata Bag/pal)
@@ -109,13 +109,13 @@ Seuil cible : **~95%** de remplissage (marge de sécurité).
 Poids max palette : **1 250 kg** (AF fait foi, corrige 1 200 kg du
 DevOps).
-## [CUSTOM] Verrou « HORS TOLERANCE » — Recomptage
+## [CUSTOM] Verrou « HORS TOLERANCE » - Recomptage
 Si la palette source porte le verrou « HORS TOLERANCE » → recomptage
 demandé avant le picking (inventaire).
 - Si stock restant suffisant après inventaire → assignation maintenue
-  (workflow `OnStockAdjust` recalcule uniquement si nécessaire — ne casse
+  (workflow `OnStockAdjust` recalcule uniquement si nécessaire - ne casse
  pas la tâche en cours)
 - Si plus assez de stock → réassignation ailleurs + retrait verrou
@@ -168,16 +168,16 @@ sur les tables élévatrices des PK.
 ### Règles de priorité
-1. **Picking négatif toujours en premier** — une seule palette à la fois
+1. **Picking négatif toujours en premier** - une seule palette à la fois
   pour ce process, toujours déposée sur la **table du centre**
-2. **Picking classique ensuite** — jusqu'à **2 palettes simultanées** au
+2. **Picking classique ensuite** - jusqu'à **2 palettes simultanées** au
   PK, déposées sur les **tables latérales**
 3. Le WMS peut envoyer **1 palette picking négatif + 1 palette picking
   classique** en même temps (pour compléter la palette post-picking
   négatif)
 4. Le nombre de palettes de prélèvement au PK ne dépasse **jamais 2**
-### Picking négatif — Détail
+### Picking négatif - Détail
 À chaque tâche de picking négatif :
@@ -240,7 +240,7 @@ Contrôle PIE identique aux autres processus (voir
 ## Points d'attention
 ⚠️ Le picking négatif (seuil 55% + poids ≥ 7 kg, deux conditions
-cumulatives) est une règle métier intégrée dans EasyWMS — c'est un
+cumulatives) est une règle métier intégrée dans EasyWMS - c'est un
 développement custom.
 ⚠️ Le traitement commercial est **désactivé**
@@ -255,17 +255,17 @@ développement custom.
 l'assignation si le stock restant est suffisant.
 ⚠️ L'algorithme de répartition TP est le « gros morceau » custom du
-picking — gestion combinatoire de tous les cas.
+picking - gestion combinatoire de tous les cas.
 ## Questions ouvertes
- [x] Programme de filmage exact — documenté, 8 programmes A→H
+- [x] ~~Programme de filmage exact~~ - documenté, 8 programmes A→H
  (voir [Flux expédition](../04-outbound/flux-expedition.md#filmage))
- [x] Process sans picking négatif / seuil — confirmé 55% + poids ≥ 7 kg
+- [x] ~~Process sans picking négatif / seuil~~ - confirmé 55% + poids ≥ 7 kg
  (réu. 11/05/2026)
- [x] Traitement commercial — supprimé
+- [x] ~~Traitement commercial~~ - supprimé
  (`CONTROLE_TRAITEMENT_COMMERCIAL = false`, réu. 11/05/2026)
- [ ] Gestion du picking négatif dans l'interface opérateur (@Nicolas)
+- ❓ Gestion du picking négatif dans l'interface opérateur (@Nicolas)
 ## Historique des modifications
@@ -284,4 +284,4 @@ picking — gestion combinatoire de tous les cas.
 | FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5 | Analyse fonctionnelle | 28/11/2025 |
 | Expédition - LIMAGRAIN - DEV - Confluence | Page ateliers DEV | 2026 |
 | LIM-82 LOT2.2 | Ticket Jira (ordonnancement PS → PK) | 2026 |
-| REU PICKING SEQUENCAGE 11-05-2026 | CR réunion + analyse comparative | 11/05/2026 |
+| REU PICKING SEQUENCAGE 11-05-2026 | CR réunion + analyse comparative | 11/05/2026 |
@@ -3,10 +3,10 @@ title: "Placement des palettes PS → PK (choix de table)"
 tags: [picking, placement, table, buffer, ping-pong, algorithme]
 status: draft
 standard_ref: concepts/picking.md
-jira_refs: [LIM-82]
+jira_refs: [LIM-82, LIM-84, LIM-91, LIM-95, LIM-116]
 confluence_refs: []
-sources: ["Logique combinatoire picking - PS vers PK - V1.0.md"]
+sources: ["Logique combinatoire picking - PS vers PK - V1.0.md", "Jira LIM-82 (commentaires revue de code)", "Jira LIM-95 (Annulé, mergé dans LIM-82)", "Jira LIM-116 (capacité buffers PK → PK)"]
-last_updated: 2026-05-12
+last_updated: 2026-07-20
 author: Arthur
 ---
@@ -22,6 +22,27 @@ author: Arthur
 > Ce qui suit documente les **spécificités Limagrain** par rapport au
 > standard.
 > **Statut (LIM-82)** : dev terminé, **en attente de déploiement pour
 > test**. Livré en préprod le 25/06/2026, revue de code validée le
 > **03/07/2026** (après une itération NOK le 02/07). Ce ticket est la
 > reprise de [LIM-75](https://easywmsfrance.atlassian.net/browse/LIM-75)
 > (V1 annulé). Positionnement dans la chaîne :
 > [LIM-80](https://easywmsfrance.atlassian.net/browse/LIM-80) assignation →
 > [LIM-84](https://easywmsfrance.atlassian.net/browse/LIM-84) séquençage
 > TK → PS → **LIM-82 placement PS → PK** →
 > [Process picking au PK (LIM-91)](process-picking-pk.md).
 > ⚠️ **LIM-95 (Annulé) mergé ici** : le ticket
 > [LIM-95](https://easywmsfrance.atlassian.net/browse/LIM-95)
 > « [JOB] génération des mouvements depuis les buffers » est
 > **Annulé(e)** ; ses modifications ont été intégrées à **LIM-82**
 > (commentaire Maxime Halgand, 26/06). Ses deux demandes sont couvertes
 > ici : (1) ne pas générer le mouvement d'une palette si une autre tâche
 > du même OS a une séquence prioritaire → voir
 > [Gate de séquence (critère B)](#gate-de-séquence-critère-b) ; (2)
 > contrôler la capacité de la **TP** (sous-emplacement) en plus de celle
 > du PK → voir la note ci-dessous.
 ## Contexte projet
 Chaque PK dispose de **3 tables** soumises à une contrainte d'adjacence
@@ -31,7 +52,7 @@ stricte :
 TABLE_GAUCHE ←→ TABLE_CENTRE ←→ TABLE_DROITE
     ✅ adjacentes       ✅ adjacentes
-TABLE_GAUCHE ←————————————————→ TABLE_DROITE
+TABLE_GAUCHE ←----------------→ TABLE_DROITE
                 ❌ INTERDIT
 ```
@@ -41,7 +62,7 @@ Règles de mouvement :
  la table
 - L'opérateur peut déplacer du **stock** (sacs, colis) d'une palette à
  une autre **uniquement entre deux tables adjacentes**
- Il est **interdit de déplacer une palette d'une table à une autre** —
+- Il est **interdit de déplacer une palette d'une table à une autre** -
  ni par l'opérateur, ni par l'AGV. Une palette arrive sur une table
  et ne peut que repartir (évacuation)
 - **TABLE_CENTRE** est le pivot : seule table adjacente aux deux autres
@@ -87,6 +108,12 @@ FONCTION décider_destination(palette, PK) :
    RETOURNER ATTENTE
 ```
 > [CUSTOM] **Capacité TP (LIM-95)** : dans tous les flux qui vérifient la
 > capacité du PK, la capacité de la **TP** (sous-emplacement de la table)
 > doit aussi être contrôlée. Attention : **aucun capteur de présence
 > n'est relié à Galileo** - la capacité est donc suivie logiquement par
 > le WMS, pas par un signal physique.
 ## Décision niveau 2 : choix de la table
 Le choix dépend du **type de picking** de la tâche associée.
@@ -232,7 +259,7 @@ PICKING_DIRECT restants ≥ `SEUIL_RECENTRAGE_PF` (défaut : 3), le WMS
 peut déclencher un mouvement AGV pour recentrer la PF sur
 TABLE_CENTRE.
-## Évacuation des tables — Priorité
+## Évacuation des tables - Priorité
 Lorsqu'aucune table n'est libre et qu'il faut en libérer une :
@@ -259,6 +286,13 @@ buffer affectées à ce PK :
 **Règle critique** : l'ordre de sortie des buffers est dicté par
 `Line.CstAtt`, **pas** par l'ordre d'arrivée physique en buffer.
 > [CUSTOM] **Capacité buffers PK → PK (LIM-116)** : la génération de
 > mouvement depuis le picking (`Task_GenerateMovement_PR_V2`) contrôle la
 > capacité des buffers lorsqu'une palette va d'un poste de picking à un
 > autre. Les mouvements manuels du poste (appeler / renvoyer, filmage au
 > retour) sont détaillés dans
 > [Process picking au PK](process-picking-pk.md#mouvements-manuels-du-poste-appeler--renvoyer---lim-116).
 ## Palettes multi-commandes
 Une palette source peut être assignée à plusieurs OS.
@@ -288,11 +322,91 @@ séquence du mode "Picking" dans `MODES_PKxx`
 | `MAX_PRELOAD_PAR_PK` | Nombre max de palettes pré-chargées en buffer ES par PK | 3 |
 | `SEUIL_RECENTRAGE_PF` | Nombre min de PICKING_DIRECT restants pour recentrer la PF au centre | 3 |
 | `CONTROLE_TRAITEMENT_COMMERCIAL` | Séparer ou non les articles par TC sur les palettes filles | `false` (V1.1) |
-| `MODES_PKxx` | Modes autorisés + priorité par PK (LIM-69) | — |
+| `MODES_PKxx` | Modes autorisés + priorité par PK (LIM-69) | - |
-| `PK_BIGBAG` | Autorise ou non les big-bags par PK (LIM-70) | — |
+| `PK_BIGBAG` | Autorise ou non les big-bags par PK (LIM-70) | - |
 ## Implémentation définitive (LIM-82)
 > Cette section reflète le **code livré et validé** (revue de code du
 > 03/07/2026). Elle prime sur l'algorithme V1.0 ci-dessus en cas d'écart -
 > ce dernier reste documenté comme référence de conception.
 ### Records et workflows
 | Élément AD | Type | Rôle |
 |------------|------|------|
 | `TaskWF` | Record | Ajout d'un CstAtt de tâche (dont `CstAtt3`, flag « palette passée au shuttle »). |
 | `CST_ChooseDestinationFromPS` | Workflow | Décision principale : table de picking (avec choix de la position), buffer ES si aucune place, ou attente au PS s'il n'y a plus de place (selon `MAX_PRELOAD_PAR_PK`). |
 | `Container_MovedEventHandler_PS_PR` | Workflow | À l'arrivée d'une palette de tâche picking au PS, appelle `CST_ChooseDestinationFromPS`. |
 | `Container_MovedEventHandler_ET_PR` | Workflow | Passe `CstAtt3` de la tâche à `True` **après** que la palette a quitté le shuttle, pour autoriser la sortie des palettes suivantes du TK. |
 | `Container_MovedEventHandler_MS_PR` | Workflow | Idem : passe `CstAtt3` à `True` quand une palette atteint `TS_12` (sortie du `TK_01`, qui ne passe pas par le shuttle). |
 | `CST_Job_CheckPSBufferContainers` | Job | Ré-évalue les palettes en attente au PS et en buffer : quand une place picking se libère, envoie la bonne palette au picking. |
 ### Queries
 | Query | Rôle |
 |-------|------|
 | `CST_Picking_GetSiblingTasks` | Récupère les tâches de picking du même **ordre de sortie** (OS). |
 | `CST_GetTasksWaitingOnPSAndBufffer` | Récupère toutes les tâches sans mouvement présentes sur un PS ou un buffer (en attente de picking ou de stage). |
 | `CST_GetStationRoutes_ToDisable` | Récupère les routes à désactiver pour le mouvement PS : route PS → PK, et routes PS → buffer plein. |
 ### Gate de séquence (critère B)
 Avant toute pose sur une table, le WMS vérifie via
 `CST_Picking_GetSiblingTasks` s'il existe une autre palette du **même OS**
 avec un `Line.CstAtt` (séquence, écrit par
 [LIM-84](https://easywmsfrance.atlassian.net/browse/LIM-84)) **inférieur**
 encore à traiter en amont (buffer / shuttle). Si oui, la palette qui arrive
 n'est **pas** posée sur une table : elle part en buffer ES (ou en attente si
 buffer indisponible).
 > Cette règle correspond à la 1re demande de
 > [LIM-95](https://easywmsfrance.atlassian.net/browse/LIM-95) (Annulé,
 > mergé ici) : « le job traite chaque tâche une par une ; si une autre
 > tâche de l'OS a une séquence prioritaire (`Task.CstAtt01` plus faible),
 > ne pas générer le mouvement ». `Task.CstAtt01` et `Line.CstAtt`
 > désignent la même **séquence de picking** (voir
 > [ad-customs](../07-admin/ad-customs.md), CstAtt Tâche 01).
 > ⚠️ **Correction revue de code (02→03/07)** : le contrôle portait
 > initialement sur les tâches de la **route** ; il a été ramené au périmètre
 > de l'**OS**. Vérifier sur la route provoquait un faux blocage quand deux OS
 > d'une même route étaient préparés simultanément sur deux PK différents.
 ### Gating shuttle (CstAtt3)
 Le shuttle est le goulot d'ordonnancement entre le TK et les PS. Le flag
 `CstAtt3` de la tâche est mis à `True` une fois la palette sortie du shuttle
 (handler `ET`) ou arrivée à `TS_12` pour le `TK_01` qui ne passe pas par le
 shuttle (handler `MS`). Ce flag conditionne la sortie des palettes suivantes
 du TK, garantissant l'ordre de passage (cf.
 [ad-customs](../07-admin/ad-customs.md) CstAtt Tâche 03).
 ### Écarts avec l'algorithme V1.0
 - Les états `EN_ATTENTE_EVACUATION` et la « réactivation » d'une
  `PALETTE_FILLE_EN_ATTENTE` sont **abandonnés** dans LIM-82 (barrés dans la
  description du ticket). Les priorités V1.0 qui s'y réfèrent (ex. cas
  picking direct « adjacente en cours d'évacuation ») ne sont donc plus
  applicables.
 - Picking négatif (critère C) : `TABLE_CENTRE` libre **ET** au moins une
  table de côté adjacente libre → palette source sur `TABLE_CENTRE` ; sinon
  buffer ES. Une seule palette négative à la fois par PK.
 - Picking direct (critère D) : table de côté libre **adjacente** à la
  `PALETTE_FILLE_ACTIVE` ; en cas de double disponibilité, `TABLE_GAUCHE`
  prioritaire sur `TABLE_DROITE` ; sinon buffer ES.
 - Les mécanismes `SEUIL_RECENTRAGE_PF` (recentrage AGV) et
  `CONTROLE_TRAITEMENT_COMMERCIAL` proviennent de la spec V1.0 et ne
  figurent pas dans les critères validés de LIM-82.
  → ⚠️ À confirmer côté implémentation.
 ## Points d'attention
 ⚠️ L'implémentation livrée (LIM-82) prime sur l'algorithme V1.0 ci-dessus :
 voir [Implémentation définitive (LIM-82)](#implémentation-définitive-lim-82)
 (états `EN_ATTENTE_EVACUATION` / réactivation abandonnés, gate de séquence
 OS, gating shuttle `CstAtt3`).
 ⚠️ La contrainte d'adjacence est **physique** : l'opérateur ne peut pas
 déplacer de sacs entre TABLE_GAUCHE et TABLE_DROITE directement.
@@ -307,7 +421,15 @@ d'entrée en buffer.
 ## Questions ouvertes
-(Aucune identifiée — algorithme V1.0 complet)
+- Big-bag : comportement attendu si une palette big-bag arrive et qu'aucun
  PK `PK_BIGBAG` autorisé n'est disponible (attente dédiée, refus, autre
  file) ? (question ouverte LIM-82)
 - Confirmer si les mécanismes V1.0 `SEUIL_RECENTRAGE_PF` (recentrage AGV) et
  `CONTROLE_TRAITEMENT_COMMERCIAL` sont réellement implémentés (absents des
  critères validés LIM-82).
 - LIM-75 est cité comme pré-requis « Mini Job picking négatif » (évaluation
  du `TaskType` OrdinaryPicking/NegativePicking) alors qu'il est confirmé
  Annulé → LIM-82 : clarifier où le `TaskType` est réellement écrit.
 ## Historique des modifications
@@ -315,11 +437,20 @@ d'entrée en buffer.
 |------|--------|--------------|
 | 2026-05-12 | Arthur | Création depuis spec "Logique combinatoire picking - PS vers PK - V1.0" |
 | 2026-05-13 | Arthur | Correction règle déplacement palette (jamais déplacée, ni AGV ni opérateur), ajout jira_ref LIM-82 |
 | 2026-07-17 | Arthur | Relecture revue de code LIM-82 (préprod, validée 03/07) : ajout section « Implémentation définitive » (WF `CST_ChooseDestinationFromPS`, `Container_MovedEventHandler_PS/ET/MS_PR`, job `CST_Job_CheckPSBufferContainers`, queries `CST_Picking_GetSiblingTasks` / `CST_GetTasksWaitingOnPSAndBufffer` / `CST_GetStationRoutes_ToDisable`) ; gate de séquence OS (correction route → OS) ; gating shuttle `CstAtt3` ; abandon états `EN_ATTENTE_EVACUATION` + réactivation PF ; statut préprod ; questions big-bag / recentrage / TaskType LIM-75 |
 | 2026-07-17 | Arthur | LIM-95 confirmé Annulé(e) → mergé dans LIM-82 (pattern V1/V2, pas de duplication) : note de supersession (chaîne), rattachement des 2 demandes (gate de séquence `Task.CstAtt01`=`Line.CstAtt` ; note capacité TP + absence capteurs Galileo), jira_refs/sources/Références |
 | 2026-07-20 | Arthur | Note capacité buffers PK → PK (LIM-116, `Task_GenerateMovement_PR_V2`) + renvoi vers les mouvements manuels du poste (process-picking-pk.md) ; jira_refs +LIM-116, sources, last_updated, Références |
 ## Références
 | Source | Type | Date |
 |--------|------|------|
 | Logique combinatoire picking - PS vers PK - V1.0 | Spécification technique | 27/04/2026 |
 | [LIM-82](https://easywmsfrance.atlassian.net/browse/LIM-82) | Ticket Jira (placement PS → PK, 5 commentaires, préprod) | 2026-06 → 07 |
 | [LIM-84](https://easywmsfrance.atlassian.net/browse/LIM-84) | Ticket Jira (séquençage TK → PS, écrit `Line.CstAtt`) | 2026 |
 | [LIM-75](https://easywmsfrance.atlassian.net/browse/LIM-75) | Ticket Jira (picking négatif TaskType, **Annulé** → LIM-82) | 2026 |
 | [LIM-95](https://easywmsfrance.atlassian.net/browse/LIM-95) | Ticket Jira ([JOB] mouvements depuis buffers, **Annulé** → mergé LIM-82) | 2026 |
 | [LIM-91](https://easywmsfrance.atlassian.net/browse/LIM-91) | Ticket Jira (workflow opérateur au PK) | 2026 |
 | [LIM-116](https://easywmsfrance.atlassian.net/browse/LIM-116) | Ticket Jira (LOT 3, mouvements manuels station picking - capacité buffers PK → PK `Task_GenerateMovement_PR_V2`) | 2026-07 |
 | [LIM-69](https://easywmsfrance.atlassian.net/browse/LIM-69) | Ticket Jira (modes PK) | 2026 |
 | [LIM-70](https://easywmsfrance.atlassian.net/browse/LIM-70) | Ticket Jira (Mega Job) | 2026 |
@@ -0,0 +1,326 @@
 ---
 title: "Process de picking au poste de travail (PK)"
 tags: [picking, PK, opérateur, étiquetage, filmage, picking-négatif, MII, custom]
 status: draft
 standard_ref: concepts/picking.md
 jira_refs: [LIM-91, LIM-80, LIM-84, LIM-82, LIM-75, LIM-66, LIM-76, LIM-68, LIM-67, LIM-116]
 confluence_refs: []
 sources: ["Jira LIM-91 (lecture directe, en revue de code)", "Jira LIM-116 (lecture directe, revue de code)"]
 last_updated: 2026-07-20
 author: Arthur
 ---
 # Process de picking au poste de travail (PK)
 > **Résumé** : workflow opérateur de picking au poste de travail (PK).
 > L'opérateur prélève les sacs d'une palette source vers une palette
 > fille (client), gère l'étiquetage (RFID + intercalaires MII), le
 > filmage et l'évacuation. Dernière étape de la chaîne picking.
 > **Standard EasyWMS** : → voir [Picking](../../concepts/picking.md)
 > Le WF standard `WorkStation_Picking_Default` sert de socle ; toute la
 > logique Limagrain est construite en custom par-dessus.
 > **Statut (LIM-91)** : **En revue de code** (assignée Maxime Halgand).
 > Implémentation livrée le 16/07, revue de code du 17/07 avec plusieurs
 > corrections en attente (voir Points d'attention). Le contenu ci-dessous
 > reflète l'implémentation en cours, à reconfirmer à la validation.
 ## Positionnement dans la chaîne picking
 Ce ticket est l'étape finale de la chaîne :
 - [LIM-80](job-assignation-pk.md) assignation OS → PK (génère les tâches)
 - [LIM-84](sequencage-tk-ps.md) séquençage TK → PS (écrit `Line.CstAtt`)
 - [LIM-82](placement-ps-pk.md) placement PS → PK (choix de table, buffers)
 - **LIM-91 (cette page)** : picking effectif au PK → étiquetage → filmage
  → évacuation
 Le périmètre commence à la **détection de la palette source sur une
 table du PK** et se termine à l'**évacuation de la palette fille**.
 Hors périmètre (couvert ailleurs) : tri/séquençage (LIM-84), placement et
 ping-pong (LIM-82), assignation PK (LIM-80), conditions de déclenchement
 du picking négatif (LIM-75).
 ## Architecture du poste
 Le picking se fait toujours sur **un seul poste = 3 tables (TP)** ;
 jamais sur les 6 TP d'un îlot en même temps. Contrainte d'adjacence :
 `TABLE_GAUCHE ←→ TABLE_CENTRE ←→ TABLE_DROITE` (gauche et droite **non**
 adjacentes). Détail dans [Placement PS → PK](placement-ps-pk.md).
 - Une palette ne se déplace **jamais** d'une table à une autre (ni
  opérateur, ni AGV) : elle arrive sur une table et n'en repart que pour
  évacuation.
 - Les **big-bags ne transitent jamais par les PK** : expédiés en palettes
  complètes via le flux shipping direct. Seuls les sacs sont prélevés.
 - Équipement par poste : 1 poste léger EasyWMS sur 2 écrans, 1 imprimante
  Zebra (HU RFID), 1 imprimante A4, 1 douchette multi-format.
 Le process démarre en mode **Tâches automatiques** sur PC (même mode que
 la réception).
 ## Spécifications fonctionnelles
 ### Picking direct
 Cas standard : l'opérateur prélève les sacs de la palette source (déjà
 sur une table adjacente à la palette fille) et les dépose sur la palette
 fille, confirme, puis la source est évacuée (retour ASRS si stock
 restant) ou mise en attente si d'autres tâches l'utilisent. Le ping-pong
 gauche/droite est géré par LIM-82.
 Palette **multi-commandes** : si la source a encore des tâches pour
 d'autres OS, elle est marquée `MULTI_COMMANDE` et envoyée vers un buffer
 ES (LIM-82).
 ### Picking négatif
 Optimisation physique : au lieu de déplacer les N sacs à expédier,
 l'opérateur déplace les sacs **qui restent** (moins nombreux) vers une
 autre palette. Toujours sur la **table du centre**, une seule palette en
 picking négatif à la fois. Un nouveau SSCC est généré pour la palette
 d'excédent (retour ASRS) et une étiquette RFID lui est imprimée.
 Les **conditions de déclenchement** sont évaluées en amont (LIM-75 /
 LIM-84), pas dans ce workflow : `QttyNegPick.PickingPercent` (défaut 50),
 `QttyNegPick.MinCompletePercent` (défaut 55) et poids unitaire du sac
 ≥ 7 kg. Le dispatcher standard route selon le `TaskType` déjà déterminé
 (pas de custom ici). La fusion standard neg+ord sur la même ligne de
 commande est déjà gérée par EasyWMS.
 ### Verrou HORS TOLERANCE et recomptage
 Si une palette source porte le verrou « HORS TOLERANCE » (posé au PIE,
 [LIM-66](../01-inbound/controle-qualite-reception.md)), un **recomptage
 obligatoire** est déclenché avant le picking :
 - Stock suffisant après inventaire → assignation maintenue, picking
  continue, verrou retiré sur la palette comptée.
 - Stock insuffisant → réassignation sur une autre palette + retrait du
  verrou.
 Palette `MULTI_COMMANDE` revenant pour un autre OS : **pas besoin de
 recompter** (le premier recomptage fait foi).
 ### Étiquetage au picking
 Dépend de la **classe de commande**, détectée via le RUT
 (`OutboundType = 0`, `AccountCode = MII`, `OutboundClassCode = MII`).
 - **MII / multi-lots** : 1 étiquette HU **RFID** (palette mère physique,
  à chaque nouvelle palette) + 1 étiquette HU **sans RFID** (intercalaire
  / palette fille, à chaque nouvelle ligne de stock flaggée). Pas de HU
  imbriquée : le **SSCC virtuel** de la palette fille est porté par le
  `CstAtt2` de la **ligne de stock** (ressource `SSCC MII [CST 2]`).
 - **Non-MII (ou MII mono-lot)** : une seule étiquette HU RFID, pas
  d'intercalaire.
 Les rapports d'étiquette réutilisent ceux de
 [LIM-68](../01-inbound/etiquette-rfid.md) (mono/multiref RFID, monoref
 sans RFID pour l'intercalaire).
 **Flag `CstAtt14` Container** (`true` après étiquetage au PK) consommé en
 aval par l'**étiqueteuse automatique au poste de sortie TK** :
 `true` → n'imprime pas ; `false` → imprime puis passe à `true` ;
 `error` → échec impression. Voir [AD Customs](../07-admin/ad-customs.md).
 > **Messagerie carton (phase 1)** : aucun traitement spécifique. Les
 > supports suivent le flux client déjà en place et retournent à l'ASRS
 > (pas d'emplacement au sol, pas de SSCC colis, pas de poumon
 > transporteur).
 ### Filmage avant évacuation
 Avant chaque évacuation de palette fille, l'opérateur choisit le
 programme de filmage via un prompt. Valeur stockée dans le **`CstAtt05`
 Container** et transmise en custom data à Galileo (TMS), qui arrête les
 rouleaux et lance le programme. Choix **obligatoire** (« 0 - pas de
 filmage » possible), **toujours proposé** à l'opérateur (pas de
 pré-sélection par espèce/contenant).
 Programmes : `0` (pas de filmage), `A-H` selon espèce (Tournesol /
 Maïs & Blé) × contenant (Sacs / Big Bag) × mode (Complet / Réduit).
 Détail dans [Stations picking](stations-picking.md).
 ### Évacuation et retour ASRS
 - **Palette fille** : tâche AGV PK → Entrée TK, replacement **direct** en
  zone client / défragmentation de l'ASRS (pas de stockage temporaire).
  Le passage en « conteneur client » est remonté à SAP via le **LOC**
  (`ACTION=P`, delta 5 min, [LIM-76](../06-erp-interface/loc-message-periodique.md)).
 - **Palette source** : retour ASRS si stock restant ; si vidée, remise
  manuelle sur la pile de palettes vides (pas de tâche AGV).
 - Les transferts inter-HU au picking génèrent des lignes `ACTION=T` dans
  le LOC.
 > L'opérateur ne déplace **jamais** de sacs d'une TP à une autre (sacs de
 > 25 à 50 kg). Garanti par le placement LIM-82.
 ### Mouvements manuels du poste (appeler / renvoyer) - LIM-116
 Les actions standard « **Appeler** » (faire venir un conteneur au poste)
 et « **Renvoyer conteneur** » sont customisées au PK pour tenir compte
 des **AGV** et du besoin de **filmage** des palettes (LIM-116, LOT 3).
 - **Renvoi manuel - bouton « Stocker support »** : avant le calcul de la
  destination, l'opérateur choisit le **programme de filmage** (même
  sélection que [LIM-67](../01-inbound/reception-fournisseur.md), WF
  `CST_Workstation_Wrapping_UI`). WF modifié : `Return_ContainerFromPKStation_UI`.
 - **Renvoi automatique (plus de tâches)** : dans le process tâche
  automatique du poste, quand le conteneur est renvoyé parce qu'il n'a
  **plus de tâches**, la sélection du **programme de filmage** est demandée
  de la même manière. WF modifié : `Task_AutomaticPicking_UI`.
 - **Destination du retour (PIE de filmage)** : le retour d'une palette
  depuis le PK passe par le **custom de sélection du PIE** (PIE de
  ré-insertion `PIE_ENTRY_PK`, défaut PIE02, pour que la palette soit
  filmée). Une valeur a été ajoutée au `ProcessContext` de
  `Container_MoveToStationTypeCodeListOrReject` (et de
  `Container_CloseClientContainerOnMP_PR`) pour piloter ce choix - même WF
  de destination que le [rejet PIE](../02-stockage/rejet-pie.md).
 - **Capacité des buffers PK → PK** : la génération de mouvement depuis le
  picking (`Task_GenerateMovement_PR_V2`) gère la capacité des buffers
  quand une palette va d'un poste de picking à un autre (cf. buffers ES,
  [Placement PS → PK](placement-ps-pk.md)).
 ### Cas 100 % : tâche de shipping, pas de picking
 Quand la quantité assignée sur une palette source correspond à **100 % de
 son stock**, on génère une **tâche de shipping** (pas de picking) :
 inutile de déplacer tous les sacs pour rebaptiser la palette
 (décision Vincent Charvet, 02/07). Solution testée : activer « Expédier
 uniquement conteneur complet » ; en dessous de la valeur « palette
 pleine » de la conversion de support, le WMS tente le picking négatif si
 les critères sont réunis, sinon la palette est reprise par le calcul
 global d'optimisation du volume.
 ### Modes opératoires
 Fonctionne en **Full AGV**, **Mixte** (AGV + caristes) et **Full TRF**
 (4 caristes, mode dégradé, finalisation manuelle du module AGV). Le
 workflow opérateur au PK est **identique** quel que soit le mode ; seul
 le transport physique change.
 ## Implémentation (revue de code en cours)
 Custom construit au-dessus du framework standard `WorkStation_Picking_Default`
 → `Task_Automatic_PickingProcessType_UI` → `Expedition_Picking_UI_V1`.
 ### Workflows
 | Workflow | Modification |
 |---|---|
 | `Task_AutomaticPicking_SelectTask_PR` | Si verrou « HORS TOLERANCE » → appelle `CST_Count_Picking_UI` (inventaire), puis relit les données du conteneur pour décider si la tâche de picking reste possible |
 | `CST_Count_Picking_UI` | Compte chaque ligne de stock, affiche les infos utiles au client, message de confirmation avant ajustement ; corrige le process de retour |
 | `Task_AutomaticPicking_UI` | Appelle `CST_Container_Picking_Options` (bouton « Retour » si stock, « Retirer » si vide) |
 | `Expedition_Picking_GetInitialParameters_PR` | Ajout de `OutboundClassCode` à la query |
 | `Expedition_Picking_ExecutePicking_UI` | Commandes MII : pose un code conteneur virtuel sur chaque ligne de stock, sauvé dans `CstAtt2` de stock, imprime l'étiquette correspondante |
 | `Expedition_Picking_Finish_UI` | Appelle le WF de filmage (wrapping) à la fermeture du conteneur client |
 | `Expedition_Picking_RequestProduct_UI_V1` | Dialog `CST_Picking_AutoReadQuantity_Prompt_V1` + paramètre poids produit |
 | `Expedition_Picking_AutoreadQuantity_UI_V2` | Dialog `CST_Picking_ManualReadQuantity_Prompt_V2` + paramètre poids produit |
 | `Container_MoveContainerListToLostAndFound` | Si conteneur vide → suppression au lieu d'envoi en Lost & Found |
 | `PickingStation_RemoveOrReturnContainer_UI` | Appelle `CST_Container_Picking_Options` (option « Retirer » seule, conteneurs vides) |
 | `PrintLabels_PrintSSCCList_PR` | Appelle le WF custom `CST_PrintRFIDLabel` |
 | `PrintLabels_AutoPrintOnCloseClientContainer_PR` | Récupère l'imprimante et appelle `CST_PrintRFIDLabel` |
 ### Dialogs
 | Dialog | Rôle |
 |---|---|
 | `CST_Count_Picking_GetQuantity` | Demande à l'opérateur de compter le stock de la palette |
 | `CST_Container_Picking_Options` | Clone de `Container_Picking_Options` + paramètre bouton retour |
 | `CST_Picking_ManualReadQuantity_Prompt_V2` | Clone + poids produit mesuré |
 | `CST_Picking_AutoReadQuantity_Prompt_V1` | Clone + poids produit mesuré |
 ### Vues et ressources
 - Vue `StockVList` : ajout de `CstAtt2` (SSCC MII).
 - Ressources : `CST_Stock_CustomAttribute2` (« SSCC MII [CST 2] »),
  `CST_MeasuredProductWeight_Prompt`, `CST_Alias_Prompt` (« Code lot
  officiel »), `Product_Prompt` (« Code lot SAP »), `Shared_Alias`,
  `Source_Prompt` (« Description courte SAP »),
  `CST_Container_RemoveQuestion_1`, `CST_Container_StoreQuestion_1`.
 ## CstAtt impliqués
 | CstAtt | Entité | Donnée |
 |---|---|---|
 | `CstAtt05` | Container | Programme de filmage (0, A-H), transmis à Galileo |
 | `CstAtt06` | Container | Code PK assigné |
 | `CstAtt14` | Container | Flag étiquetage PK (`true`/`false`/`error`) - LIM-91 |
 | `CstAtt02` | Stock (StockLine) | SSCC virtuel palette MII - LIM-91 |
 > `CstAtt14` a remplacé `CstAtt13` pour l'étiquetage (CstAtt13 déjà
 > utilisé pour le code OE) - décision 01/07. Voir
 > [AD Customs](../07-admin/ad-customs.md).
 ## Communication ERP
 | Message | Direction | Déclencheur |
 |---|---|---|
 | ~~MOV~~ | ~~WMS → SAP~~ | **Annulé** (jugé inutile, décision client) |
 | LOC (`ACTION=P`) | WMS → SAP | Passage en conteneur client (delta 5 min) |
 | LOC (`ACTION=T`) | WMS → SAP | Transfert inter-HU au picking (delta 5 min) |
 ## Points d'attention
 ⚠️ **Revue de code en cours (17/07)** - corrections en attente :
 - `PrintLabels_PrintSSCCList_PR` : arrêter la boucle si un SSCC est vide
  (transition depuis « Set current SSCC »).
 - `PrintLabels_AutoPrintOnCloseClientContainer_PR` : la transaction
  `CON.PRINT` puis l'appel à `CST_PrintLabel` provoquent une **double
  impression**.
 - `Expedition_Picking_RequestProduct_UI_V1` / `AutoreadQuantity_UI_V2` :
  `CustomAttribute1` non mappé, poids produit non affiché.
 - En **picking négatif**, les écrans sont différents (pas de poids
  produit) - à harmoniser.
 ⚠️ **Demande d'optimisation (Justine, 16/07)** à intégrer :
 - Remplacer l'écran « Stocker support » de la palette mère par un écran
  de filmage, et distinguer clairement (texte + couleur) l'écran de
  filmage palette mère vs palette client.
 - La palette client doit passer par **PIE02** et non PIE01 (pour pouvoir
  être filmée).
 > → Le filmage sur « Stocker support » et le passage par le PIE de retour
 > (`PIE_ENTRY_PK`, PIE02) sont **livrés dans LIM-116** (voir
 > [Mouvements manuels du poste](#mouvements-manuels-du-poste-appeler--renvoyer---lim-116)).
 > Reste à confirmer la distinction visuelle (texte + couleur) mère vs client.
 ⚠️ **Correction temporaire (17/07, LIM-116)** : un fix a été posé sur le
 mouvement `MP → PE` ; il sera **retiré** une fois la gestion complète des
 mouvements `MP → PK` en place.
 ⚠️ L'impression de l'étiquette standard à la fermeture du conteneur
 client a été retirée (elle s'ajoutait à tort à l'étiquette custom).
 ## Questions ouvertes
 - Messagerie - choix du poumon : afficher uniquement les poumons
  compatibles avec le transporteur, ou tous ? Ou retour ASRS pour le flux
  classique ? (@Justine)
 - Recomptage HORS TOLERANCE : dialog retenu = `CST_Count_Picking_GetQuantity`
  (custom) ; confirmer l'ergonomie finale avec le client (@Justine)
 - Étiquetage intercalaire (HU fille sans RFID, MII/multi-lots) : format
  et rapport Zebra à créer (tâche à écrire par Arthur avec modèle rapport)
 ## Historique des modifications
 | Date | Auteur | Modification |
 |------|--------|--------------|
 | 2026-07-17 | Arthur | Création depuis LIM-91 (lecture directe, en revue de code) : workflow opérateur PK, picking direct/négatif, HORS TOLERANCE, étiquetage MII (Stock CstAtt2 SSCC + CstAtt14), filmage CstAtt05, évacuation, cas 100 % → shipping, implémentation (WF/dialogs/vues/ressources), corrections revue de code 17/07 + optim Justine |
 | 2026-07-20 | Arthur | Ajout LIM-116 (LOT 3, lecture directe + revue de code) : nouvelle section « Mouvements manuels du poste (appeler / renvoyer) » - filmage sur « Stocker support » (`Return_ContainerFromPKStation_UI`) et sur renvoi automatique sans tâches (`Task_AutomaticPicking_UI`), sélection PIE de retour via `ProcessContext` (`Container_MoveToStationTypeCodeListOrReject` + `Container_CloseClientContainerOnMP_PR`, PIE_ENTRY_PK/PIE02), capacité buffers PK → PK (`Task_GenerateMovement_PR_V2`) ; optim Justine 16/07 marquée livrée par LIM-116 ; caveat fix temporaire MP → PE ; jira_refs +LIM-116/LIM-67, sources, last_updated |
 ## Références
 | Source | Type | Date |
 |--------|------|------|
 | [LIM-91](https://easywmsfrance.atlassian.net/browse/LIM-91) | Ticket Jira (en revue de code) | 2026 |
 | Revue de code LIM-91 (M. Halgand, V. Charvet) | Implémentation + revue | 2026-07-16/17 |
 | [LIM-80](https://easywmsfrance.atlassian.net/browse/LIM-80) / [LIM-84](https://easywmsfrance.atlassian.net/browse/LIM-84) / [LIM-82](https://easywmsfrance.atlassian.net/browse/LIM-82) | Chaîne picking amont | 2026 |
 | [LIM-116](https://easywmsfrance.atlassian.net/browse/LIM-116) | Ticket Jira (LOT 3, mouvements manuels station picking - filmage retour + capacité buffers, attente déploiement test) | 2026-07 |
 | Revue de code LIM-116 (V. Charvet, M. Halgand) | Implémentation + revue (commit LOT3 e79f385242) | 2026-07-15/17 |
 | [LIM-67](https://easywmsfrance.atlassian.net/browse/LIM-67) | Ticket Jira (sélection programme filmage `CST_Workstation_Wrapping_UI`) | 2026 |
@@ -0,0 +1,195 @@
 ---
 title: "Recertification - Workstation au poste de picking"
 tags: [picking, recertification, workstation, ASN, MII, SmartUI, outbound]
 status: review
 standard_ref: concepts/shipping.md
 jira_refs: [LIM-105, LIM-106, LIM-110]
 confluence_refs: []
 sources: ["Jira LIM-105 (lecture directe 2026-07-20)", "Jira LIM-106 (lecture directe 2026-07-20)", "Jira LIM-110 (lecture directe 2026-07-20)"]
 last_updated: 2026-07-20
 author: Arthur
 ---
 # Recertification - Workstation au poste de picking
 > **Résumé** : process de recertification exécuté au **poste de picking** en
 > mode « Tâches automatiques ». L'opérateur échange une palette existante
 > contre une nouvelle identité (nouvelle HU / ASN) sans déplacer physiquement
 > le stock, avec vérification de l'ASN auprès de SAP.
 > **Standard EasyWMS** : → voir [Shipping](../../concepts/shipping.md) et
 > [Picking](../../concepts/picking.md).
 > Ce qui suit documente les **spécificités Limagrain** (LIM-105). Le contexte
 > outbound de la recertification (SOR Recertification, quai, route via PK) est
 > décrit dans [Flux expédition - Re-certification](../04-outbound/flux-expedition.md#re-certification).
 ## Contexte projet
 La recertification consiste à **ré-étiqueter** une palette complète pour lui
 donner une nouvelle identité, sans picking ni déplacement physique du stock :
 c'est une **sortie administrative** suivie d'une **réception administrative**
 (nouvelle HU en ASN). Un ordre de sortie de classe **RECERTIFICATION** est
 descendu, contenant les quantités à recertifier (équivalentes à des supports
 complets sans picking).
 Le quai est **assigné automatiquement** quand la classe de l'OS est
 Recertification (`QUAI_RECERTIFICATION`, param `RECERTIFICATION_CODE_QUAI`,
 LIM-110), avec blocage du changement manuel du quai - voir
 [Quai recertification](../04-outbound/shipping-orders.md#quai-recertification).
 Ce mécanisme est **distinct** du job d'assignation des images de quai X_EXP
 (LIM-94), qui exclut la classe Recertification.
 Les palettes sont acheminées vers un poste de picking où l'opérateur effectue
 des actions **hors WMS** (dont l'impression d'une nouvelle étiquette), puis
 scanne la nouvelle étiquette pour déclencher l'échange de conteneur.
 Le process est **intégré au flux « Tâches automatiques »** du poste de picking
 (même mode que le picking et la réception - voir
 [Stations de picking](stations-picking.md)). À l'arrivée au poste, les palettes
 portent une **tâche de chargement** vers le quai de recertification.
 > **Amont - acheminement au PK ([LIM-106](https://easywmsfrance.atlassian.net/browse/LIM-106))** :
 > l'assignation du PK et la création des tâches d'acheminement (mouvement des
 > conteneurs d'expédition vers le PK, puis chargement au quai de recertification)
 > sont assurées par un **mini job dédié du Mega Job**, pendant du mini job
 > picking (LIM-80). Voir
 > [Mini Job - Assignation recertification aux PK](job-assignation-pk.md#mini-job---assignation-recertification-aux-pk-lim-106).
 ## Flux fonctionnel
 ```mermaid
 sequenceDiagram
    participant OP as Opérateur (PK)
    participant WMS as EasyWMS
    participant SAP as SAP
    OP->>WMS: Scan ancienne palette
    WMS->>SAP: Demande d'un nouvel ASN pour la palette
    OP->>OP: Recertifie + ré-étiquette (hors WMS)
    OP->>WMS: Scan de la nouvelle étiquette (SSCC)
    WMS->>WMS: Attente ASN (polling ATH111)
    alt ASN reçu
        WMS->>WMS: Charge l'ancien conteneur au quai + déplace l'ASN au PK
        WMS->>WMS: Filmage (emballage)
    else Timeout / max retries
        WMS-->>OP: Message d'erreur (réessai ou fin de process)
    end
 ```
 ## Étapes détaillées
 ### Étape 1 - Scan de l'ancienne palette
 Le code palette est scanné. Un message (à définir, voir Questions ouvertes) est
 généré pour signaler à SAP le **besoin d'un nouvel ASN** pour cette palette.
 ### Étape 2 - Scan de la nouvelle étiquette
 Le nouveau code palette (SSCC) est scanné (dialogue
 `CST_Recertification_ScanLabelPrompt`, qui affiche le code et l'emplacement du
 conteneur courant).
 ### Étape 3 - Vérification de l'ASN
 Un écran d'attente vérifie qu'un **ASN existe** pour le nouveau code conteneur
 scanné (query `CST_AsnContainer_ByCode`) :
 - intervalle entre deux vérifications : paramètre `SAP_ATH111_REFRESH_INTERVAL` ;
 - timeout : `SAP_ATH111_TIMEOUT` → message d'erreur avec **option de relance**
  d'un cycle d'attente ;
 - nombre maximum d'essais : `SAP_ATH111_MAX_RETRIES` → message d'erreur mettant
  **fin au process**.
 ### Étape 4 - Échange des conteneurs
 Une fois l'ASN existant : l'**ancien conteneur est chargé sur le quai**
 (validation de la tâche de chargement) et le **conteneur en ASN est déplacé à
 la position de l'ancienne palette** (au PK).
 ### Étape 5 - Filmage (emballage)
 Un sous-processus de **filmage** est déclenché en fin de process (ajout
 LIM-105, 01/07/2026), avec gestion des erreurs.
 ## Paramètres
 | Paramètre | Rôle | Défaut |
 |-----------|------|--------|
 | `SAP_ATH111_REFRESH_INTERVAL` | Intervalle de polling de l'existence de l'ASN (ms) | `500` |
 | `SAP_ATH111_TIMEOUT` | Timeout d'attente de l'ASN (s) | `60` |
 | `SAP_ATH111_MAX_RETRIES` | Nombre maximum de tentatives | `5` |
 | `RECERTIFICATION_CODE_CLASSE` | Code de la classe d'OS recertification (remplace les valeurs hard codées) | - |
 Voir [Paramètres projet](../07-admin/parametres-projet.md).
 ## Implémentation technique
 | Élément AD | Type | Rôle |
 |-----------|------|------|
 | `CST_Recertification_PickingStationProcess_UI` | Workflow | Process principal : prompt nouveau SSCC, vérification ASN, gestion attente / timeout, échange des conteneurs, filmage |
 | `Task_AutomaticPicking_UI` | Workflow | Redirige vers le process de recertification en mode « Tâches automatiques » du PK |
 | `Workstation_Picking_Default` | Workflow | Prend en compte la tâche de chargement pour afficher le nombre de tâches en attente du conteneur au PK ; affichage du **code OS** (Justine 08/07) |
 | `Outbound_AutomaticLoadProcess_PR` | Workflow | Ne crée **pas** automatiquement le chargement camion pour les OS de classe RECERTIFICATION (`RECERTIFICATION_CODE_CLASSE`) |
 | `Outbound_CreateShippingContainersTasks_PR` | Workflow | Utilise `RECERTIFICATION_CODE_CLASSE` |
 | `CST_JobAssignStage` | Workflow | Ajout du paramètre `warehouseCode` dans la query modifiée |
 | `Container_MovedEventHandler_PK_PR` | Workflow | Ajout du paramètre `warehouseCode` dans la query modifiée |
 | `CST_AsnContainer_ByCode` | Query | Conteneur en emplacement ASN par code |
 | `CST_GetOutboundOrderAndRoutes_ToAssignStage` | Query | Utilise `RECERTIFICATION_CODE_CLASSE` |
 | `CST_OutboundOrderLineDetails_ByRecertificationContainer` | Query | Utilise `RECERTIFICATION_CODE_CLASSE` |
 | `CST_OutboundOrder_BestPendingAssignment_ForPK` | Query | Utilise `RECERTIFICATION_CODE_CLASSE` (exclusion recertif de l'assignation PK) |
 | `CST_OutboundOrder_Recertification_BestPendingAssignment_ForPK` | Query | Utilise `RECERTIFICATION_CODE_CLASSE` |
 | `CST_Recertification_ScanLabelPrompt` | Dialog | Prompt nouveau SSCC ; affiche code + emplacement du conteneur courant |
 Ressources i18n : `CST_Recertification_SSCCPrompt` (« Scanner la nouvelle
 étiquette »), `CST_Recertification_CheckingAsn` (« Récupération des
 informations... »), `CST_Recertification_Timeout` (« Erreur de communication
 avec SAP. Réessayer ? »), `CST_Recertification_TimeoutExceededTry_1`
 (« Impossible de contacter SAP après {0} tentatives... »),
 `CST_RecertificationWorkstation_Header` (« Recertification »),
 `CST_Recertification_Error` (erreur en cours de process).
 Commits : [`8b4debc3da`](https://msscode.mecalux.com/Proyectos_SW/EASYWMS_11351_LIMAGRAIN/commit/8b4debc3daf22e59979f5c5949526796d7256a6f)
 (process initial), [`3119445ff1`](https://msscode.mecalux.com/Proyectos_SW/EASYWMS_11351_LIMAGRAIN/commit/3119445ff1e3bfce3979e5678b3b80255ddefbae)
 (filmage + suppression valeurs hard codées),
 [`db4194c50e`](https://msscode.mecalux.com/Proyectos_SW/EASYWMS_11351_LIMAGRAIN/commit/db4194c50e0cc54716c90fb804f65b33084889c2)
 (code OS sur la workstation).
 ## Points d'attention
 - Le process est en **mode « Tâches automatiques »** du PK ; le PK doit être
  passé en **mode recertif** par le manager (bloque le poste pour les autres
  types de tâches). Voir [Job d'assignation PK](job-assignation-pk.md) : les OS
  RECERTIFICATION sont exclus de l'assignation picking standard.
 - Les **valeurs hard codées** d'identification des OS de classe recertification
  ont été supprimées au profit du paramètre `RECERTIFICATION_CODE_CLASSE`
  (01/07/2026).
 - À **retester** suite aux customs de
  [LIM-110](https://easywmsfrance.atlassian.net/browse/LIM-110) (quai
  recertification auto + stratégie d'assignation de stock, désormais
  documentés dans [Quai recertification](../04-outbound/shipping-orders.md#quai-recertification)).
  Retest côté process workstation encore à faire (note Arthur 30/06/2026).
 - Risque connu : si l'**ASN n'est pas encore arrivé** au scan, l'écran
  d'attente boucle jusqu'au timeout / max retries.
 ## Questions ouvertes
 - Message déclenchant l'envoi de l'ASN par SAP à l'étape 1 : l'AF évoque un
  **SOF par palette**. Deux options envisagées (LIM-105, Vincent 02/06/2026) :
  soit imposer des **OS de recertification à une seule palette** (ralentit
  l'acheminement, 1 palette par poste), soit créer un **message custom** avec
  les informations nécessaires à SAP pour créer le nouvel ASN. À trancher
  (@Vincent / @Justine).
 ## Historique des modifications
 | Date | Auteur | Modification |
 |------|--------|-------------|
 | 2026-07-20 | Arthur | Création depuis LIM-105 (lecture directe) : process workstation recertification au PK, 4 étapes + filmage, paramètres SAP_ATH111_* et RECERTIFICATION_CODE_CLASSE, éléments AD (WF / queries / dialog / ressources), question ouverte message ASN |
 | 2026-07-20 | Arthur | LIM-106 (lecture directe) : renvoi amont vers le mini job d'assignation recertification + acheminement au PK (détaillé dans job-assignation-pk.md) |
 | 2026-07-20 | Arthur | LIM-110 (lecture directe) : correction du renvoi quai auto (mécanisme QUAI_RECERTIFICATION/RECERTIFICATION_CODE_QUAI vers shipping-orders.md, distinct de LIM-94) ; note « à retester » précisée ; jira_refs +LIM-110 |
 ## Références
 | Source | Type | Date |
 |--------|------|------|
 | [LIM-105](https://easywmsfrance.atlassian.net/browse/LIM-105) | Ticket Jira (workstation recertification - attente déploiement test, revue validée 17/07) | 2026 |
 | [LIM-106](https://easywmsfrance.atlassian.net/browse/LIM-106) | Ticket Jira (mini job assignation recertification au PK + acheminement) | 2026 |
 | [LIM-110](https://easywmsfrance.atlassian.net/browse/LIM-110) | Ticket Jira (quai recertification auto + stratégie assignation stock ; customs à retester) | 2026 |
@@ -1,47 +1,50 @@
 ---
-title: "Séquençage TK → PS — Historique et arbitrage"
+title: "Séquençage TK → PS - Historique et arbitrage"
 tags: [picking, séquençage, historique, décision]
 status: draft
 standard_ref: concepts/picking.md
 jira_refs: [LIM-84]
 confluence_refs: []
 sources: ["LIM-84 LOT2.2 [PICKING] Séquençage des tâches de picking TK PS.md", "REU PICKING SEQUENCAGE 11-05-2026 - Analyse comparative notes + AF + devops.md"]
-last_updated: 2026-05-12
+last_updated: 2026-07-20
 author: Arthur
 ---
-# Séquençage TK → PS — Historique et arbitrage
+# Séquençage TK → PS - Historique et arbitrage
 > **Résumé** : historique des solutions envisagées pour le séquençage
 > TK → PS, et arbitrage des contradictions entre les 3 sources
 > (DevOps #64854, AF §6.4.8, réunion 11/05/2026).
 > **Standard EasyWMS** : → voir [Picking standard](../../concepts/picking.md)
 > Ce qui suit documente les **spécificités Limagrain** par rapport au standard.
 > Pour l'algorithme retenu, voir
 > [Séquençage TK → PS](sequencage-tk-ps.md).
 ## Solutions envisagées
-### Solution 1 — Process isolé sur finalisation des tâches d'OS
+### Solution 1 - Process isolé sur finalisation des tâches d'OS
 Séquençage via `OS.Line.CstAtt`, marquage OS traité via
 `OS.CstAtt = true`.
 **Problème** : pas assez dynamique en cas de recréation de tâches.
-### Solution 2 — Calcul dans le workflow stacker_crane
+### Solution 2 - Calcul dans le workflow stacker_crane
 Intégration dans `Galileo_StackerCraneSearch_PR` /
 `StackerCrane_SortTasks_PR`, recalcul complet à chaque exécution.
 **Problème** : complexité élevée (requêtes LINQ imbriquées multi-OS).
-### Solution 3 — Solution 1 transformée en job
+### Solution 3 - Solution 1 transformée en job
 Job planifié, excluant les tâches en cours.
 **Problème** : pas assez réactif par rapport à la cadence des TK.
-### Solution 4 — Process événementiel (retenue)
+### Solution 4 - Process événementiel (retenue)
 Solution 1 déclenchée sur `TaskCreatedEvent` et
 `OutboundOrderReleasedEvent`, avec verrouillage `OS.CstAtt`.
@@ -61,8 +64,8 @@ Analyse comparative : DevOps #64854 (le plus ancien), AF §6.4.8
 | Poids max palette | 1 200 kg | 1 250 kg | **1 250 kg** (AF) |
 | Négatif vs Maïs first | Pas de hiérarchie | Maïs en tête | **Négatif prioritaire** |
 | Semences essais | Dédié en haut | Non mentionné | **Couvert par poids** |
-| Lots même Bag/pal | Prioriser | — | **Retenu** |
+| Lots même Bag/pal | Prioriser | - | **Retenu** |
-| Différenciation marque | Aucune | — | **Confirmé** |
+| Différenciation marque | Aucune | - | **Confirmé** |
 | Calcul Bag/pal | "Prendre le max" | Équivalent palette | **Pro rata** |
 ## Changelog V1.1 (11/05/2026)
@@ -86,7 +89,7 @@ Analyse comparative : DevOps #64854 (le plus ancien), AF §6.4.8
 | Date | Auteur | Modification |
 |------|--------|--------------|
-| 2026-05-12 | Arthur | Création — extraction depuis sequencage-tk-ps.md |
+| 2026-05-12 | Arthur | Création - extraction depuis sequencage-tk-ps.md |
 ## Références
@@ -94,5 +97,5 @@ Analyse comparative : DevOps #64854 (le plus ancien), AF §6.4.8
 |--------|------|------|
 | [LIM-84](https://easywmsfrance.atlassian.net/browse/LIM-84) | Ticket Jira | 2026 |
 | REU PICKING SEQUENCAGE 11-05-2026 | CR réunion | 11/05/2026 |
-| DevOps #64854 | Note historique | — |
+| DevOps #64854 | Note historique | - |
 | AF §6.4.8 | Analyse fonctionnelle V1.5 | 28/11/2025 |
@@ -3,10 +3,10 @@ title: "Séquençage des tâches de picking TK → PS"
 tags: [picking, séquençage, transstockeur, événement, workflow, algorithme]
 status: draft
 standard_ref: concepts/picking.md
-jira_refs: [LIM-84, LIM-61]
+jira_refs: [LIM-84, LIM-61, LIM-80, LIM-82]
 confluence_refs: []
-sources: ["LIM-84 LOT2.2 [PICKING] Séquençage des tâches de picking TK PS.md", "Logique combinatoire picking - TK vers PS - V1.1.md", "REU PICKING SEQUENCAGE 11-05-2026 - Analyse comparative notes + AF + devops.md"]
+sources: ["LIM-84 LOT2.2 [PICKING] Séquençage des tâches de picking TK PS.md", "Logique combinatoire picking - TK vers PS - V1.1.md", "REU PICKING SEQUENCAGE 11-05-2026 - Analyse comparative notes + AF + devops.md", "Jira LIM-84 (commentaires revue de code)"]
-last_updated: 2026-05-12
+last_updated: 2026-07-17
 author: Arthur
 ---
@@ -20,15 +20,31 @@ author: Arthur
 > **Standard EasyWMS** : → voir [Picking](../../concepts/picking.md)
 > **Statut (LIM-84)** : dev terminé, **en attente de déploiement pour
 > test**. Revue de code validée le **02/07/2026** (après une itération NOK
 > le 29/06 et corrections le 01/07).
 ## Déclenchement
-L'algorithme est déclenché sur **deux événements** :
+> **Implémentation définitive (revue de code 02/07/2026)** : le séquençage
 > est réalisé **pendant l'assignation de stock**, et non sur
 > `TaskCreatedEvent` comme le proposait la note de conception (Solution 4,
 > voir [historique](sequencage-tk-ps-historique.md)).
- **TaskCreatedEvent** — nouvelle tâche de picking créée (MINI JOB
+Le workflow de séquençage `CST_PickingTasksSequencing_PR` est appelé par les
-  LIM-75 ou réassignation). Condition : tâche type PICKING et OS
+workflows d'assignation de stock :
-  statut Released
+
- **OutboundOrderReleasedEvent** — OS passe en Released (lancement
+- `Outbound_StockAssignProcess_PR` - assignation de stock (à la libération
-  ou relance après arrêt)
+  de l'OS)
 - `OutboundOrder_StockReassign_PR` - réassignation de stock (imprévu,
  blocage, relance)
 La **libération de l'OS** est déclenchée par la subscription
 `CST_PKAssigned_ReleaseOrder` (WF
 `CST_OutboundOrder_PKAssigned_ReleaseOrder_PR`) lorsqu'un PK est assigné à
 l'OS ([LIM-80](https://easywmsfrance.atlassian.net/browse/LIM-80)), ce qui
 déclenche l'assignation de stock. L'assignation/réassignation se fait **par
 job** (les subscriptions standard sont désactivées, cf. LIM-80).
 ## Process principal
@@ -41,11 +57,11 @@ L'algorithme est déclenché sur **deux événements** :
 ## Contraintes amont (constitution palettes filles)
-**C1. Palettes les plus complètes possible** — seuil ~95%. Calcul en
+**C1. Palettes les plus complètes possible** - seuil ~95%. Calcul en
 pro rata Bag/pal : chaque sac = `1/Bag_pal` de son lot. Additif,
 gère nativement les multi-lots.
-**C2. Ne pas splitter les lignes de stock** — prioritaire sur les
+**C2. Ne pas splitter les lignes de stock** - prioritaire sur les
 règles de tri. Regrouper la ligne complète quitte à décaler le maïs.
 | Contrainte | Valeur |
@@ -68,25 +84,25 @@ tâches.trier_par(
 )
 ```
-### Critère 1 — Picking négatif en premier
+### Critère 1 - Picking négatif en premier
 Prioritaire sur tout, y compris Maïs first. Condition cumulative
 (V1.1) : % quantité > seuil fiche article (défaut 55%) **ET** poids
 unitaire sac ≥ 7 kg.
-### Critère 2 — Espèce Maïs en premier
+### Critère 2 - Espèce Maïs en premier
 Le maïs est lourd/stable → base de palette fille.
-### Critère 3 — Espèce la plus volumineuse
+### Critère 3 - Espèce la plus volumineuse
 Espèce avec la plus grande quantité totale de sacs dans l'OS.
-### Critère 4 — Article le plus lourd en base
+### Critère 4 - Article le plus lourd en base
 Les semences essais (légères) se retrouvent naturellement en haut.
-### Critère 5 — Regroupement par palette source
+### Critère 5 - Regroupement par palette source
 L'opérateur enchaîne toutes les tâches d'une palette avant de la
 libérer.
@@ -98,28 +114,94 @@ séquence (ex-aequo), laissant au stacker_crane la liberté
 d'optimiser. Interchangeables si : même palette source, OU tous les
 critères de tri identiques.
-## Détermination picking négatif (MINI JOB LIM-75)
+## Détermination picking négatif
 > Le `TaskType` (OrdinaryPicking / NegativePicking) est déterminé à la
 > création des tâches. Conditions **définitives** (revue de code LIM-84) :
 ```
-SI quantité_à_prélever > seuil_article × quantité_palette_source
+SI  % à prélever ≥ NegativePickingPercent (55% du stock actuel de la source)
-   ET article unique dans la palette source
+ET  remplissage source ≥ NegativeMinCompletePercent (25% de la capacité pleine)
-   ET pas d'attribut logistique à capturer
+ET  palette source mono-lot
-   ET poids_unitaire_sac ≥ 7 kg
+ET  poids_unitaire_sac ≥ 7 kg          // check custom Limagrain
 ALORS → PICKING_NÉGATIF
 SINON → PICKING_DIRECT
 ```
 - Le picking négatif est désormais **autorisé même si des attributs
  logistiques sont précisés dans la commande** (levée d'une restriction
  initiale).
 - Les 2 conditions de pourcentage sont **standard EasyWMS**
  (`Outbound_CreatePickingContainerTasksNegative_CheckPercents_PR_V1`) ;
  seul le check de poids (≥ 7 kg) est custom
  (`Outbound_CreatePickingContainerTasksNegative_PR_V1` récupère le lot et
  le poids de l'article).
 ## Paramètres WMS
 | Paramètre | Défaut | Note V1.1 |
 |-----------|--------|-----------|
 | `CONTROLE_TRAITEMENT_COMMERCIAL` | **false** | Désactivé |
-| Seuil picking négatif (fiche article) | 55% | Inchangé |
+| `NegativePickingPercent` (% à prélever du stock actuel) | 55% | Standard |
-| Poids min picking négatif | **7 kg** | Nouveau |
+| `NegativeMinCompletePercent` (% remplissage min source) | 25% | Standard, capacité pleine |
 | Poids min picking négatif | **7 kg** | Custom Limagrain |
 | Seuil remplissage palette | **~95%** | Nouveau |
 | Poids max palette | **1 250 kg** | Corrigé |
 | `MAX_NB_BUFFER_PK` | 3 | Inchangé |
 ## Implémentation définitive (LIM-84)
 > Reflète le **code livré et validé** (revue de code du 02/07/2026, après
 > une itération NOK le 29/06 et corrections le 01/07). Prime sur les notes
 > de conception ci-dessus en cas d'écart.
 Le séquençage ne se contente pas de trier : `CST_PickingTasksSequencing_PR`
 calcule d'abord la **composition des palettes finales** (quels stocks vont
 sur quelle palette fille, via les records `CST_PickingPalletList` /
 `CST_PickingStockList`), puis écrit le numéro de séquence (`CstAtt1` de la
 tâche) sur chaque tâche. Le stacker crane consomme ensuite les tâches via
 `CST_Tasks_PendingOutboundForStackerCrane`, en respectant le verrou
 `OS.CstAtt` et l'ordre `Line.CstAtt` croissant.
 ### Workflows
 | Workflow | Rôle |
 |----------|------|
 | `CST_PickingTasksSequencing_PR` | Calcule la constitution des palettes finales pour les tâches de picking d'un OS selon les critères actifs, puis écrit le numéro de séquence sur chaque tâche. |
 | `CST_OutboundOrder_PKAssigned_ReleaseOrder_PR` | Libère l'OS (appelé par la subscription `CST_PKAssigned_ReleaseOrder`). |
 | `Outbound_StockAssignProcess_PR` | Assignation de stock - appelle le séquençage. |
 | `OutboundOrder_StockReassign_PR` | Réassignation de stock - appelle le séquençage. |
 | `NegativePicking_CheckAllowsNegativePickingTask_PR` | Conditions picking négatif : palette source **mono-lot** ; négatif autorisé **même si** des attributs logistiques sont précisés dans la commande. |
 | `Outbound_CreatePickingContainerTasksNegative_PR_V1` | Récupère le lot du stock et le poids de l'article. |
 | `Outbound_CreatePickingContainerTasksNegative_CheckPercents_PR_V1` | Ajoute la condition de poids unitaire min (≥ 7 kg) aux 2 checks % standard. |
 ### Records / Lists
 | Élément | Rôle |
 |---------|------|
 | `CST_PickingPalletList` | Palette construite au picking (caractéristiques physiques + stocks), pour le calcul de constitution des palettes finales. |
 | `CST_PickingStockList` | Stock à prélever au picking et sa tâche, pour le calcul de constitution. |
 ### Queries et vue
 | Élément | Rôle |
 |---------|------|
 | `CST_PickingStocksToSequence_ByOutboundOrder` | Stocks à prélever d'un OS qui ne font pas déjà partie du séquençage. |
 | `CST_Tasks_ForView` | Format du `CstAtt1` (numéro de séquence). |
 | `CST_Tasks_PendingOutboundForStackerCrane` | Tâches en attente pour le stacker crane (corrigée le 29/06 pour les tâches de mouvement - test recertification). |
 | `TaskVList` (vue) | Ajout de `CstAtt1` : le numéro de séquence est visible dans la vue des tâches. |
 ### Points confirmés en revue de code
 - **Recalcul** : les tâches déjà en cours conservent leur séquence ; seules
  les tâches en attente sont re-séquencées.
 - **Réassignation après épuisement** : si une réassignation de stock survient
  alors que toutes les tâches précédentes sont faites, le séquençage repart
  de 0. L'info de séquence sert **uniquement** à l'ordonnancement.
 - **Concurrence inter-OS** : plusieurs OS simultanés sur un même PK est
  **interdit** ; chaque OS a son propre pool de tâches et son propre verrou
  `OS.CstAtt`.
 ## Points d'attention
 ⚠️ Le custom LIM-61 (capacité buffer) doit gérer les palettes
@@ -132,9 +214,9 @@ ramenés sur petits sacs).
 ## Liens
- [Placement PS → PK](placement-ps-pk.md) — algorithme aval
+- [Placement PS → PK](placement-ps-pk.md) - algorithme aval
- [Picking combinatoire](picking-combinatoire.md) — vue d'ensemble
+- [Picking combinatoire](picking-combinatoire.md) - vue d'ensemble
- [Historique et arbitrage](sequencage-tk-ps-historique.md) —
+- [Historique et arbitrage](sequencage-tk-ps-historique.md) -
  solutions envisagées + arbitrage contradictions réunion 11/05/2026
 ## Historique des modifications
@@ -144,12 +226,15 @@ ramenés sur petits sacs).
 | 2026-05-12 | Arthur | Création initiale depuis LIM-84 |
 | 2026-05-12 | Arthur | Refonte V1.1 : algo complet, 5 critères, contraintes amont, arbitrage réunion 11/05 |
 | 2026-05-12 | Arthur | Découpage : historique solutions + arbitrage → page dédiée |
 | 2026-07-17 | Arthur | Relecture revue de code LIM-84 (préprod, validée 02/07) : nouvelle section « Implémentation définitive » (WF `CST_PickingTasksSequencing_PR` = constitution palettes + séquence, records `CST_PickingPalletList`/`CST_PickingStockList`, queries `CST_PickingStocksToSequence_ByOutboundOrder` / `CST_Tasks_ForView` / `CST_Tasks_PendingOutboundForStackerCrane`, vue `TaskVList` +CstAtt1) ; déclenchement réel = pendant l'assignation de stock (`Outbound_StockAssignProcess_PR` / `OutboundOrder_StockReassign_PR`) + subscription `CST_PKAssigned_ReleaseOrder`, et non `TaskCreatedEvent` ; conditions picking négatif définitives (mono-lot, autorisé même avec attributs logistiques, poids ≥ 7 kg) + ajout NegativeMinCompletePercent 25% ; points confirmés (recalcul, repart de 0, inter-OS interdit) ; statut préprod |
 ## Références
 | Source | Type | Date |
 |--------|------|------|
-| [LIM-84](https://easywmsfrance.atlassian.net/browse/LIM-84) | Ticket Jira | 2026 |
+| [LIM-84](https://easywmsfrance.atlassian.net/browse/LIM-84) | Ticket Jira (séquençage, 5 commentaires, préprod) | 2026-06 → 07 |
-| [LIM-61](https://easywmsfrance.atlassian.net/browse/LIM-61) | Ticket Jira | 2026 |
+| [LIM-61](https://easywmsfrance.atlassian.net/browse/LIM-61) | Ticket Jira (capacité PK/buffer) | 2026 |
 | [LIM-80](https://easywmsfrance.atlassian.net/browse/LIM-80) | Ticket Jira (assignation PK, release OS) | 2026 |
 | [LIM-82](https://easywmsfrance.atlassian.net/browse/LIM-82) | Ticket Jira (placement PS → PK, consomme Line.CstAtt) | 2026 |
 | Logique combinatoire picking - TK vers PS - V1.1 | Spec technique | 11/05/2026 |
 | REU PICKING SEQUENCAGE 11-05-2026 | CR réunion | 11/05/2026 |
@@ -6,7 +6,7 @@ standard_ref: concepts/stations.md
 jira_refs: [LIM-69, LIM-70]
 confluence_refs: []
 sources: [FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5.docx, "Réception - LIMAGRAIN - DEV - Confluence.md", "Expédition - LIMAGRAIN - DEV - Confluence.md", "LIM-69 - LOT1.3 Modes de travail des PK.md"]
-last_updated: 2026-05-12
+last_updated: 2026-07-17
 author: Arthur
 ---
@@ -67,7 +67,7 @@ dynamiquement.
 | P1 à P6 | Postes de travail 01 à 06 |
 | TP11 à TP63 | Tables de préparation 11 à 63 |
-## Postes de travail — Architecture physique
+## Postes de travail - Architecture physique
 ### 3 îlots de 2 postes
@@ -113,11 +113,18 @@ de big-bags. Toute opération impliquant un big-bag (bag/pal ≤ 2) doit
 est déjà plugué au mode Automatic tasks (custom) → même mode pour le
 picking et la recertification.
-Voir [Flux expédition — Préparation](../04-outbound/flux-expedition.md#6-préparation-au-poste-de-travail)
+Voir [Flux expédition - Préparation](../04-outbound/flux-expedition.md#6-préparation-au-poste-de-travail)
 pour les règles détaillées (arrivée palettes 3 TP, algorithme répartition,
 ordonnancement par gerbabilité).
-### Modes de travail — Configuration et fonctionnement
+### Modes de travail - Configuration et fonctionnement
 > **Statut (LIM-69)** : revue de code validée le 31/03/2026, livré en
 > **pré-production** (test client). Une première revue (26/03) avait été
 > rejetée : préfixe `CST_` manquant sur le paramètre
 > `AdjacentPickingStation` → `CST_AdjacentPickingStation`, et suffixe `_1`
 > à ajouter sur la ressource paramétrée `CST_Picking_ConfirmOpenWithAdjacent`
 > → `CST_Picking_ConfirmOpenWithAdjacent_1`.
 Chaque poste est **polyvalent** et peut être utilisé pour différents flux.
 Le manager configure les modes autorisés et leur priorité ; l'opérateur
@@ -134,7 +141,7 @@ la palette qui arrive.
 | Échantillonnage | Inventaire |
 | Re certification | Picking |
-> ~~Mode esclave (3 ou 6 tables)~~ **ABANDONNÉ** — remplacé par un simple
+> ~~Mode esclave (3 ou 6 tables)~~ **ABANDONNÉ** - remplacé par un simple
 > message d'avertissement poste adjacent (voir section dédiée ci-dessous).
 #### Configuration par le manager (vassist SmartUI)
@@ -154,6 +161,14 @@ ouvre une **vassist** qui permet de :
 - Au moins un mode doit être coché (pour bloquer un PK, utiliser le
  bouton standard dédié)
 > **Reversal** : les contraintes initialement prévues sur les priorités
 > (séquence continue à partir de 1, pas de doublon, pas de trou) ont été
 > **abandonnées**. Les priorités sont de simples entiers libres ; seuls
 > subsistent les contrôles ci-dessus. Deux ressources d'erreur portent la
 > validation : `CST_VAssistantAssignWorkMode_Error_NoMode` (aucun mode
 > coché) et `CST_VAssistantAssignWorkMode_Error_ParamNotFound` (paramètre
 > système manquant).
 **Stockage** : la configuration est enregistrée dans un **paramètre
 SmartUI dédié par PK** au format :
@@ -194,7 +209,7 @@ en mode tâche automatique) :
 - Bouton **Confirmer** : le PK s'ouvre normalement
 - Bouton **Annuler** : le PK reste inactif
-**Pas de blocage technique** — uniquement informatif. Les opérateurs sont
+**Pas de blocage technique** - uniquement informatif. Les opérateurs sont
 physiquement à ~2 mètres et peuvent se coordonner verbalement. Les AGV
 ont des capteurs de sécurité et demandent l'autorisation de dépose.
@@ -215,6 +230,26 @@ Au clic :
 | MODES_PKxx | Modes autorisés + priorité pour le PK xx (un par PK, via vassist) | _(vide)_ | `RECEPTION;1\|PICKING;2` |
 | PK_ADJACENT | Paires de postes adjacents | _(vide)_ | `PK01;PK02\|PK03;PK04` |
 #### Éléments AD (LIM-69)
 | Élément AD | Type | Rôle |
 |------------|------|------|
 | `CST_PkStationWorkMode` | Entité | Contient le mode et la priorité - sert à afficher les modes configurés dans `PkMpVList` |
 | `CST_PkStationWorkMode_ForView` | Query | Récupère les modes autorisés (paramètre `MODES_PKxx`) pour toutes les stations de picking |
 | `CST_PickingStation_Adjacent` | Query | Récupère la station adjacente configurée dans `PK_ADJACENT` |
 | `CST_VAssistAssignWorkMode` | Vue (vassist) | Assistant de choix des modes autorisés et de leur priorité sur un PK |
 | `PkMpVList` | Vue | Ajout du bouton « Choix modes de travail » ; bouton d'ouverture modifié pour contrôler le statut du poste adjacent et demander confirmation |
 | `WorkStation_Picking_OpenCloseStation_UI` | Workflow | Contrôle le statut du poste adjacent et demande confirmation s'il est ouvert (paramètre `CST_AdjacentPickingStation`) |
 **Ressources** (FR / EN) : `CST_Prop_WorkMode_Mode` (Mode de travail / Working
 mode), `CST_Prop_WorkMode_Priority` (Priorité / Priority),
 `CST_PkMpVList_WorkModes` (Modes de travail / Working modes),
 `CST_VAssistantAssignWorkMode_Title` (Choix modes de travail / Working modes
 selection), libellés des 5 modes
 (`CST_VAssistantAssignWorkMode_Reception|Picking|Consolidation|Count|Certification`),
 et `CST_Picking_ConfirmOpenWithAdjacent_1` (message d'avertissement poste
 adjacent).
 ### Équipement par poste
 - 1 poste léger EasyWMS dupliqué sur 2 écrans
@@ -229,7 +264,7 @@ Au clic :
 Job unique « chef d'orchestre » qui vérifie les modes de travail pour
 chaque PK et orchestre l'envoi de tâches via des sous-workflows dédiés
-(LIM-74, LIM-75). Transverse à tous les flux (réception, picking,
+(LIM-74, LIM-75 annulé → LIM-82). Transverse à tous les flux (réception, picking,
 regroupement, échantillonnage, re certification).
 ## Buffer postes de travail
@@ -260,7 +295,7 @@ une palette du buffer vers le convoyeur d'entrée pour stockage.
 - Emplacement picking dédié pour réapprovisionnement automatique sur
  seuil
 - Aide à la manutention sur chaque poste pour prendre/poser des palettes
- [CUSTOM] Bouton WfAction pour demander ou renvoyer une pile —
+- [CUSTOM] Bouton WfAction pour demander ou renvoyer une pile -
  l'opérateur choisit la pile à réapprovisionner parmi une liste
 Voir [Palettes vides](../02-stockage/palettes-vides.md) pour le détail.
@@ -280,7 +315,9 @@ redirection).
 ## Questions ouvertes
- [ ] Détail de la gestion des tables de préparation bloquées (@Nicolas)
+- ❓ Détail de la gestion des tables de préparation bloquées (@Nicolas)
 - Affichage des priorités de modes dans un ordre croissant dans la vassist -
  demandé par Justine (20/05/2026), non tranché (LIM-69).
 ## Historique des modifications
@@ -290,6 +327,7 @@ redirection).
 | 2026-05-05 | Arthur | Mode esclave abandonné, job transverse, vassist modes, 2 piles/îlot |
 | 2026-05-05 | Arthur | Cross-ref flux expédition, picking WS vs RF, contrainte Big-Bag |
 | 2026-05-12 | Arthur | Détail modes de travail (LIM-69) : vassist manager, paramètres MODES_PKxx/PK_ADJACENT, tâche automatique, avertissement adjacent, fermeture poste. Renvoi job vers page dédiée (LIM-70) |
 | 2026-07-17 | Arthur | Relecture commentaires LIM-69 : ajout éléments AD (CST_PkStationWorkMode, queries, vassist, WF OpenCloseStation, ressources), statut pré-production + historique revue de code (préfixe CST_, suffixe _1), reversal contraintes de priorité (entiers libres), question ordre croissant (Justine) |
 ## Références
@@ -298,4 +336,4 @@ redirection).
 | FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5 | Analyse fonctionnelle | 28/11/2025 |
 | Réception - LIMAGRAIN - DEV - Confluence | Page ateliers DEV | 2026 |
 | Expédition - LIMAGRAIN - DEV - Confluence | Page ateliers DEV | 2026 |
-| [LIM-69](https://easywmsfrance.atlassian.net/browse/LIM-69) | Ticket Jira | 2026 |
+| [LIM-69](https://easywmsfrance.atlassian.net/browse/LIM-69) | Ticket Jira (6 commentaires) | 2026-03 → 2026-06 |
@@ -1,11 +1,11 @@
 ---
-title: "Outbound — Vue d'ensemble"
+title: "Outbound - Vue d'ensemble"
 tags: [outbound, expédition, shipping, index]
 status: draft
 last_updated: 2026-05-05
 ---
-# Outbound — Vue d'ensemble
+# Outbound - Vue d'ensemble
 > **Périmètre** : flux SOR → RUT → SOF → LOF, consolidation, chargement,
 > messages ERP outbound.
@@ -18,6 +18,7 @@ last_updated: 2026-05-05
 - [Flux expédition](flux-expedition.md)
 - [Shipping Orders](shipping-orders.md)
 - [Séquençage shipping par STOP](sequencage-shipping-stop.md)
 - [Assignation automatique de l'image de quai](assignation-image-quai.md)
 - [Consolidation et chargement](consolidation-chargement.md)
 - [Flux ERP outbound](flux-erp-outbound.md)
@@ -44,4 +45,4 @@ flowchart LR
 | Commande client | RUT « Client » | Oui (partiel) | Poumon → camion |
 | Conso OF hors recert | SOR « Production » | Non | Poumon → production |
 | Conso OF avec recert | SOR « Recert » | Passage poste | Restockage |
-| Messagerie carton | RUT « Messagerie » | Oui | Emplacement sol |
+| Messagerie carton | RUT « Messagerie » | Oui | Emplacement sol |
@@ -0,0 +1,207 @@
 ---
 title: "Assignation automatique de l'image de quai (OS/Tournée)"
 tags: [outbound, expédition, image-quai, stage, job, assignation, AGV]
 status: review
 standard_ref: concepts/shipping.md
 jira_refs: [LIM-94, LIM-88]
 confluence_refs: ["Expédition - LIMAGRAIN - DEV"]
 sources: ["Jira LIM-94 (lecture directe, 7 commentaires, revue de code)"]
 last_updated: 2026-07-17
 author: Arthur
 ---
 # Assignation automatique de l'image de quai (OS/Tournée)
 > **Résumé** : job périodique qui assigne automatiquement une image de
 > quai (poumon d'expédition) aux ordres de sortie (OS) et tournées (RUT)
 > éligibles, via un « faux » stage `X_EXP`. Automatise ce qui était une
 > assignation manuelle et fournit le stage dont dépend le séquençage
 > shipping (LIM-88).
 > **Standard EasyWMS** : → voir [Shipping](../../concepts/shipping.md)
 > Ce qui suit documente les **spécificités Limagrain** par rapport au
 > standard.
 ## Contexte projet
 Par défaut, l'assignation quai + image de quai pour l'expédition est
 **manuelle** (voir
 [Quais, poumons et chargement](consolidation-chargement.md)). LIM-94
 automatise l'assignation de l'**image de quai** aux OS et tournées.
 Ce job est **en amont** du
 [séquençage shipping par STOP (LIM-88)](sequencage-shipping-stop.md) :
 le garde-fou `Outbound_CreateShippingOrLoadTasksToDockOrStage_PR` de
 LIM-88 refuse de créer une tâche de chargement tant qu'aucun stage
 (image de quai) n'est associé à l'OS. LIM-94 fournit cette association.
 ## Stages virtuels `X_EXP`
 Un OS ou une Route ne peut être assigné qu'à un **« faux » stage** nommé
 `X_EXP`, où `X` = code de l'image de quai (`A_EXP` pour l'image de quai
 A). Ce sont les **seuls stages assignables** à un OS/Route.
 - **Layout** : ajout des stages `A_EXP`, `B_EXP`, ... avec une
  **capacité de 26** mais **un seul emplacement**
 - **Pourquoi un stage virtuel à 1 emplacement ?** L'assignation doit
  porter sur un **emplacement** et non une station. Sans ce stage
  virtuel, il faudrait choisir une position précise (1 parmi 26) de
  l'image de quai
 - **Identification de l'image de quai associée à un stage** : c'est la
  **seule image de quai ayant une route vers ce stage** (ex : la seule
  route vers `A_EXP` part de l'image de quai A)
 ## Job `CST_AssignDockStage`
 Job `CST_AssignDockStage` → WF `CST_Job_AssignStage`, exécuté **toutes
 les 30 secondes**.
 Le job récupère les Routes et les OS (OS **hors route**, en excluant les
 OS de classe **Recertification**) et tente d'assigner une image de quai :
 1. Vérifie via `CST_GetOutboundOrderAndRoutes_ToAssignStage` s'il existe
   des ordres à assigner
 2. Si oui, cherche les stages disponibles via
   `CST_DockStage_GetAvailableStageToAssign`
 3. Boucle simple : assigne les ordres un par un jusqu'à épuisement des
   ordres ou des stages disponibles
 4. La commande d'assignation diffère selon le type (Route ou OS)
 **Priorisation** : par **priorité**, puis par **date de libération**.
 ### Conditions d'éligibilité de l'OS / Route
 - **Libéré**
 - **Toutes les palettes de picking sont revenues dans le TK** (même
  principe que la tâche d'ordonnancement TK)
 - Date actuelle à **H-3 de la date d'expédition prévue**
 > La query contrôle en pratique : OS Released, non déjà assigné à un
 > stage, date d'expédition prévue < 3 h, picking terminé (aucun
 > conteneur picking + tous les conteneurs client en APS). Correction
 > revue de code (05/06) : utiliser la **date d'expédition prévue** (et
 > non la date de chargement prévue) pour les OS.
 ### Conditions d'assignabilité du stage
 Un stage n'est assignable pour expédition que si le **stage virtuel**
 `X_EXP` **et** l'**image de quai physique** associée sont libres.
 **Stage virtuel `X_EXP`** :
 - Non verrouillé
 - Aucune tâche vers lui
 - Aucun conteneur dessus
 - Aucun autre OS, Route **ou réception** assigné
 **Image de quai physique** (identifiée par la route qui va vers le
 stage virtuel) :
 - Non verrouillée
 - Aucun conteneur dessus
 - Aucune tâche vers elle
 Ces contrôles sont portés par la query
 `CST_DockStage_GetAvailableStageToAssign`.
 ## Génération des mouvements (PS → image de quai)
 Le placement final vers l'image de quai est calculé au **poste de sortie
 (PS)**, pas à l'assignation du stage. Quand un conteneur arrive au PS, le
 WF `Container_MovedEventHandler_PS_PR` :
 1. Récupère l'image de quai correspondant au stage assigné (la seule
   image de quai ayant une route vers ce stage)
 2. Change la destination de la tâche vers le **premier emplacement libre
   calculé** de l'image de quai : l'emplacement avec le **X le plus
   grand** n'ayant ni conteneur ni conteneur en mouvement
 > Ce calcul « X le plus grand d'abord » rejoint le sens de dépose décrit
 > dans [Quais, poumons et chargement](consolidation-chargement.md)
 > (décharger en commençant par l'emplacement le plus éloigné du quai) et
 > limite le problème de dépose AGV sur emplacements serrés.
 ## Désassignation à l'arrêt de l'OS / Route
 Quand un OS (ou une Route) ayant une image de quai associée est
 **stoppé** (repasse au statut « En attente »), l'association est
 **supprimée**.
 **Pourquoi ?** Sans cela, l'association peut devenir caduque : ex. image
 B choisie, puis 2 jours plus tard, après re-libération, l'image B est
 entre-temps réservée par une réception, ce qui pose problème.
 - WF `CST_OutboundOrderUnassignStage_PR` : désassigne le stage de l'OS
  s'il y en a un **et** que l'OS n'est pas inclus dans une route
 - WF `CST_RouteUnassignStage_PR` : désassigne le stage de la route
 - Souscription async `CST_OutboundOrderStopped_UnassignStage` sur
  l'événement `OutboundOrderSetStoppingOperationEvent`
 - Souscription async `CST_RouteStopped_UnassignStage` sur l'événement
  `RouteStoppedEvent`
 > Correction revue de code (05/06) : ces WF vérifient l'**image de quai**
 > et non le quai de chargement.
 ## Assignation manuelle (VAssist)
 L'assignation manuelle reste possible : les vues
 `VAssistOutboundOrderAssignDock` et `VAssistRouteAssignDock` sont
 restreintes pour n'afficher que les `DockStage` disponibles, selon les
 **mêmes critères** que `CST_DockStage_GetAvailableStageToAssign`.
 ## [CUSTOM] Éléments techniques (revue de code)
 > **Statut** : LIM-94 « En cours de test client (préprod) ». Revue de
 > code réalisée (Maxime Halgand, Vincent Charvet).
 | Élément | Type | Rôle |
 |---|---|---|
 | Stages `A_EXP`, `B_EXP`, ... | Layout | Stage virtuel par image de quai (capacité 26, 1 emplacement) |
 | `CST_DockStage_GetAvailableStageToAssign` | Query | Liste des stages virtuels assignables (contrôle virtuel + image de quai physique) |
 | `CST_GetOutboundOrderAndRoutes_ToAssignStage` | Query | Liste unifiée (Id + Description) des OS et Routes éligibles, pour un tri indépendant du type ; exclut la classe Recertification |
 | `CST_Job_AssignStage` | WF | Boucle d'assignation, appelée toutes les 30 s |
 | `CST_AssignDockStage` | Job | Appelle `CST_Job_AssignStage` toutes les 30 s |
 | `Container_MovedEventHandler_PS_PR` | WF | Fin d'ordre au PS : redirige la tâche vers le 1er emplacement libre (X max) de l'image de quai du stage |
 | `CST_OutboundOrderUnassignStage_PR` | WF | Désassigne le stage d'un OS stoppé (hors route) |
 | `CST_RouteUnassignStage_PR` | WF | Désassigne le stage d'une route stoppée |
 | `CST_OutboundOrderStopped_UnassignStage` | Souscription | Async sur `OutboundOrderSetStoppingOperationEvent` |
 | `CST_RouteStopped_UnassignStage` | Souscription | Async sur `RouteStoppedEvent` |
 | `VAssistOutboundOrderAssignDock` / `VAssistRouteAssignDock` | Vue | Assignation manuelle restreinte aux stages disponibles |
 Commits : `f0536cce0c` (stages virtuels + redirection PS + vues),
 `e3889b8003` (fix quai désassigné au passage du job + optim query),
 `5de1618104` (désassignation à l'arrêt OS/Route).
 ## Points d'attention
 ⚠️ Le garde-fou LIM-88
 (`Outbound_CreateShippingOrLoadTasksToDockOrStage_PR`) dépend de
 l'association de stage posée ici : sans stage assigné, pas de tâche de
 chargement, les palettes bloquent aux PS.
 ⚠️ La désassignation à l'arrêt évite les réservations caduques d'image
 de quai (conflit possible avec une réception qui réserverait entre-temps
 la même image).
 ## Questions ouvertes
 - Condition « l'image de quai n'a aucune réception assignée » : marquée
  **TBD** dans la description initiale. La query intègre bien un contrôle
  « aucune réception assignée » sur le stage virtuel ; confirmer le
  périmètre exact (@Justine)
  → voir [Questions ouvertes](../08-transverse/questions-ouvertes.md)
 ## Historique des modifications
 | Date | Auteur | Modification |
 |------|--------|--------------|
 | 2026-07-17 | Arthur | Création depuis LIM-94 (lecture directe + revue de code) : stages virtuels `X_EXP`, job `CST_AssignDockStage`/`CST_Job_AssignStage` (30 s), conditions d'éligibilité OS/Route et d'assignabilité stage, redirection PS `Container_MovedEventHandler_PS_PR` (X max), désassignation à l'arrêt (WF + souscriptions), VAssist restreintes, éléments techniques + commits |
 ## Références
 | Source | Type | Date |
 |--------|------|------|
 | [LIM-94](https://easywmsfrance.atlassian.net/browse/LIM-94) | Ticket Jira (statut préprod / test client) | 2026-07-17 |
 | [LIM-88](https://easywmsfrance.atlassian.net/browse/LIM-88) | Ticket Jira (séquençage shipping, dépend du stage) | 2026 |
 | Revue de code LIM-94 (M. Halgand, V. Charvet) | Commits `f0536cce0c` / `e3889b8003` / `5de1618104` | 2026-05/06 |
 | Expédition - LIMAGRAIN - DEV | Page Confluence | 2026 |
@@ -3,10 +3,10 @@ title: "Quais, poumons et chargement"
 tags: [outbound, quais, poumons, chargement, AGV, étiqueteuse]
 status: draft
 standard_ref: concepts/shipping.md
-jira_refs: []
+jira_refs: [LIM-94]
 confluence_refs: ["Expédition - LIMAGRAIN - DEV"]
 sources: [FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5.docx, "Expédition - LIMAGRAIN - DEV - Confluence.md"]
-last_updated: 2026-05-05
+last_updated: 2026-07-17
 author: Arthur
 ---
@@ -39,7 +39,7 @@ Modes de fonctionnement configurables par quai :
 Chaque poumon est composé de **26 emplacements palettes au sol**, répartis en
 2 colonnes de 13 emplacements numérotés.
-Toutes les combinaisons quai/poumon sont possibles — aucune restriction.
+Toutes les combinaisons quai/poumon sont possibles - aucune restriction.
 La cohérence des assignations est de la responsabilité de Limagrain.
 ### [CUSTOM] Quai fictif « Parking »
@@ -79,6 +79,11 @@ poumon pour lancer la livraison.
 **Dès qu'un poumon est assigné** : les tâches de mouvement vers ce poumon
 sont générées, **même si aucun quai n'est encore assigné**.
 > [CUSTOM] Depuis LIM-94, l'assignation de l'**image de quai** aux OS et
 > tournées peut être **automatique** (job périodique via un stage virtuel
 > `X_EXP`), en plus de l'assignation manuelle. Voir
 > [Assignation automatique de l'image de quai](assignation-image-quai.md).
 **Libération** :
 - Image de quai : **automatique** à la dernière palette chargée
@@ -113,18 +118,18 @@ respectés par les caristes pour les prises/déposes AGV.
 | Quai bloqué | Plus assignable → assigner un autre quai manuellement |
 | Poumon bloqué | Plus assignable → assigner un autre poumon. Palettes déjà présentes traitées normalement, les suivantes réorientées |
-### Cas particulier — Messagerie carton
+### Cas particulier - Messagerie carton
 - Pas d'image de quai assignée
 - **Emplacement au sol dédié** par transporteur (ex: « Colissimo »,
-  « Chronopost ») — ne pas utiliser d'image de quai classique pour ne
+  « Chronopost ») - ne pas utiliser d'image de quai classique pour ne
  pas perdre 25 places
 - [CUSTOM] À l'import du SOR, vérification combo shipping class code +
  transporteur → poumon associé automatiquement
 ## Points d'attention
-⚠️ Le process de messagerie carton n'utilise pas d'image de quai — un
+⚠️ Le process de messagerie carton n'utilise pas d'image de quai - un
 emplacement au sol spécifique est réservé (à définir).
 ⚠️ Possibilité de modifier quai/image de quai a posteriori manuellement
@@ -143,10 +148,15 @@ emplacements serrés).
   laisser l'AGV (iGO/Still) choisir l'emplacement disponible le plus
   proche, puis remonter l'emplacement exact au WMS
 2. OU imposer à Still de **respecter l'ordre des STOP** tel que sorti par
-   le WMS — c'est Still qui est responsable de l'ordonnancement
+   le WMS - c'est Still qui est responsable de l'ordonnancement
 > ⚠️ À valider avec Still lors d'une réunion technique dédiée.
 > [CUSTOM] LIM-94 atténue ce problème côté WMS : le placement final est
 > calculé au PS (`Container_MovedEventHandler_PS_PR`) vers le premier
 > emplacement libre à **X le plus grand** de l'image de quai. Voir
 > [Assignation automatique de l'image de quai](assignation-image-quai.md).
 ## Confirmation prise/dépose AGV
 Quand l'AGV prend une palette (sortie TK, sortie buffer, sortie PK), il
@@ -157,7 +167,7 @@ doit **informer le WMS** que la palette est sur l'AGV (emplacement =
 incorrecte (occupée informatiquement alors que physiquement vide), ce qui
 bloque les flux suivants.
-Confirmation de dépose (fin de mission) déjà prévue par Still — il faut
+Confirmation de dépose (fin de mission) déjà prévue par Still - il faut
 aussi le **début de mission** (prise palette).
 Les AGV déposent les palettes sur le poumon en respectant l'**ordre des
@@ -165,8 +175,8 @@ arrêts (STOP)** pour la livraison.
 ## Questions ouvertes
- [ ] Emplacement au sol exact par transporteur pour messagerie carton (@Théo)
+- ❓ Emplacement au sol exact par transporteur pour messagerie carton (@Théo)
- [ ] Validation réunion technique Still pour le problème dépose AGV
+- ❓ Validation réunion technique Still pour le problème dépose AGV
  sur image de quai (@Théo)
 ## Historique des modifications
@@ -175,6 +185,7 @@ arrêts (STOP)** pour la livraison.
 |------|--------|--------------|
 | 2026-05-05 | Arthur | Création initiale depuis AF V1.5 |
 | 2026-05-05 | Arthur | QUAI_TEMPORAIRE, messagerie carton, problème dépose AGV, confirmation prise/dépose |
 | 2026-07-17 | Arthur | Renvois vers la nouvelle page LIM-94 (assignation auto image de quai via stage `X_EXP` ; placement PS X max) dans « Règles d'assignation » et « Problème de dépose AGV » ; front matter jira_refs/last_updated |
 ## Références
@@ -1,16 +1,16 @@
 ---
-title: "Flux ERP outbound — Messages expédition"
+title: "Flux ERP outbound - Messages expédition"
-tags: [outbound, ERP, SOR, RUT, SOF, LOF, PCK, MOV, interface]
+tags: [outbound, ERP, SOR, RUT, SOF, LOF, PCK, MOV, interface, adresse, tournee]
 status: draft
-standard_ref: architecture/erp-integration.md
+standard_ref: concepts/erp-interface.md
-jira_refs: []
+jira_refs: [LIM-117]
 confluence_refs: []
-sources: [FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5.docx, "Expédition - LIMAGRAIN - DEV - Confluence.md", "CR CONSOLIDES REU ERP LIMAGRAIN V1 - CR.md"]
+sources: [FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5.docx, "Expédition - LIMAGRAIN - DEV - Confluence.md", "CR CONSOLIDES REU ERP LIMAGRAIN V1 - CR.md", "Jira LIM-117 (lecture directe)"]
-last_updated: 2026-05-06
+last_updated: 2026-07-20
 author: Arthur
 ---
-# Flux ERP outbound — Messages expédition
+# Flux ERP outbound - Messages expédition
 > **Résumé** : catalogue des messages ERP liés aux processus d'expédition
 > chez Limagrain, avec direction, déclencheur et contenu principal.
@@ -26,7 +26,7 @@ Pour les messages de réception, voir
 ## Messages entrants (SAP → EasyWMS)
-### RUT — Route
+### RUT - Route
 | Champ | Description |
 |-------|-------------|
@@ -35,7 +35,7 @@ Pour les messages de réception, voir
 | Contenu | Image camion (tournée), 1+ ordres de sortie (SOR), date/heure libération, n° stops |
 | Types | « Client » (commandes client + messagerie palette), « Messagerie » (messagerie carton) |
-### SOR — Shipping Order Request
+### SOR - Shipping Order Request
 | Champ | Description |
 |-------|-------------|
@@ -44,9 +44,35 @@ Pour les messages de réception, voir
 | Contenu | Lignes de stock (article/lot SAP, propriétaire Limagrain, statut de stock, quantité), priorité, date/heure libération |
 | Types | « Production » (consommation OF hors recert), « Recert » (consommation OF avec recert) |
 ### [CUSTOM] Adresse de livraison des SOR de tournée (LIM-117)
 En standard, le SOR porte des champs d'adresse de livraison, mais la
 **liste de SOR d'un RUT** (`RouteErpCommand`) ne les expose pas. SAP
 transmet donc l'adresse dans le bloc **`CustomAttribute` de chaque SOR**
 du RUT. Un **post-subscription** WMS (à développer) lit ces attributs et
 les mappe sur l'**ordre de sortie (OS)** correspondant.
 | CstAtt du SOR | Contenu (déduit de l'exemple SAP) | Exemple |
 |---|---|---|
 | `Attribute1` | Code postal | `63720` |
 | `Attribute2` | Site / lieu-dit | `Biopôle Clermont-Limagne` |
 | `Attribute3` | Rue | `Rue Henri Mondor` |
 | `Attribute4` | Commune | `SAINT-BEAUZIRE` |
 | `Attribute5` | Région | `AUVERGNE-RHONE-ALPES` |
 | `Attribute6` | Pays | `FR` |
 | `Attribute7` | Téléphone / commentaire | `0415400300 ou commentaire` |
 Les attributs sont portés au niveau de chaque SOR de la `SorList`, quel
 que soit le type (l'exemple SAP `RUT-2026-000451_BIS` concerne un SOR
 `AccountCode = PRODUCTION`).
 > ⚠️ Statut LIM-117 **Ouvert** : mapping validé côté SAP (exemple fourni),
 > le post-subscription WMS reste **à développer**. Les libellés de champs
 > ci-dessus sont déduits des valeurs de l'exemple - à confirmer avec SAP.
 ## Messages sortants (EasyWMS → SAP)
-### SOF — Shipping Order Fulfilled
+### SOF - Shipping Order Fulfilled
 | Champ | Description |
 |-------|-------------|
@@ -61,7 +87,7 @@ Pour les messages de réception, voir
 - **Cancelled** = commande annulée, ShippedQuantity = 0 sur les lignes non
  expédiées
-### LOF — Load Order Fulfilled
+### LOF - Load Order Fulfilled
 | Champ | Description |
 |-------|-------------|
@@ -81,18 +107,18 @@ Palette support (IsSlave=TRUE) → Palette fille (IsSlave=FALSE) → Lignes
 de stock avec attributs logistiques. Cas des supports remontés M2I :
 Palette US (IsSlave=TRUE) → Séparateur 1 → Séparateur 2.
-### [CUSTOM] PCK — Passage Conteneur Client
+### [CUSTOM] PCK - Passage Conteneur Client
 | Champ | Description |
 |-------|-------------|
 | Direction | WMS → ERP |
-| Déclencheur | Stock préparé — passage en conteneur client EasyWMS |
+| Déclencheur | Stock préparé - passage en conteneur client EasyWMS |
 | Contenu | Information passage conteneur client |
 | Envoyé pour | Commande client, consommation OF hors recert, messagerie carton |
-### ~~[CUSTOM] MOV — Movement~~ ANNULÉ
+### ~~[CUSTOM] MOV - Movement~~ ANNULÉ
-> **ANNULÉ** — décision réunion client, jugé inutile.
+> **ANNULÉ** - décision réunion client, jugé inutile.
 | Champ | Description |
 |-------|-------------|
@@ -100,7 +126,7 @@ Palette US (IsSlave=TRUE) → Séparateur 1 → Séparateur 2.
 | Déclencheur | ~~Déplacement de stock entre palettes (picking, regroupement)~~ |
 | Contenu | ~~Palette d'origine, palette de destination, nouvelle palette (Oui/Non), quantité + caractéristiques~~ |
-## Communication ERP : LOC — Détails
+## Communication ERP : LOC - Détails
 ### Principe retenu
@@ -135,7 +161,7 @@ les mouvements (et non une autre date).
 | Chargement camion terminé | LOF |
 | Réception palette re-certifiée | ASN (depuis MII) |
-## Diagramme de séquence — Expédition client complète
+## Diagramme de séquence - Expédition client complète
 ```mermaid
 sequenceDiagram
@@ -164,7 +190,7 @@ sequenceDiagram
    WMS->>SAP: LOF (camion chargé)
 ```
-## Diagramme de séquence — Consommation OF avec recertification
+## Diagramme de séquence - Consommation OF avec recertification
 ```mermaid
 sequenceDiagram
@@ -196,12 +222,16 @@ sequenceDiagram
 ## Points d'attention
-⚠️ Le message MOV est **ANNULÉ** (décision réunion client — jugé inutile).
+⚠️ Le message MOV est **ANNULÉ** (décision réunion client - jugé inutile).
 ⚠️ Le SOF est automatique quand tous les conteneurs sont chargés.
 En cas d'expédition partielle, la clôture (et le SOF) est manuelle.
 Les lignes sans quantité expédiée n'apparaissent pas dans le SOF.
 ⚠️ **Adresse de livraison (LIM-117)** : non exposée dans la liste de SOR
 d'un RUT ; transmise par SAP dans le `CustomAttribute` de chaque SOR et
 mappée sur l'OS par un post-subscription WMS à développer.
 ⚠️ Pour la recertification, le SOF est envoyé **avant** la réception
 de la nouvelle HU (séquence SOF → ASN).
@@ -215,7 +245,8 @@ le flag « client ».
 |------|--------|--------------|
 | 2026-05-05 | Arthur | Création initiale depuis AF V1.5 |
 | 2026-05-05 | Arthur | MOV annulé, LOC détaillé (5 min, delta, structure), synthèse communications |
-| 2026-05-06 | Arthur | Enrichissement SOF (phase 2, statuts, contenu), LOF (structure conteneurs, articulation SOF/LOF), PCK remplacé par LOC — depuis CR consolidé |
+| 2026-05-06 | Arthur | Enrichissement SOF (phase 2, statuts, contenu), LOF (structure conteneurs, articulation SOF/LOF), PCK remplacé par LOC - depuis CR consolidé |
 | 2026-07-20 | Arthur | Ajout LIM-117 (LOT 2.1, lecture directe, Ouvert) : section « Adresse de livraison des SOR de tournée » (`CustomAttribute` Attribute1-7 des SOR du RUT, post-subscription WMS de mapping vers l'OS à développer) ; point d'attention ; front matter jira_refs/sources/tags/last_updated |
 ## Références
@@ -224,3 +255,4 @@ le flag « client ».
 | FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5 | Analyse fonctionnelle | 28/11/2025 |
 | Expédition - LIMAGRAIN - DEV - Confluence | Page ateliers DEV | 2026 |
 | CR CONSOLIDES REU ERP LIMAGRAIN V1 | CR ateliers interfaçage | 23/02/2026 |
 | [LIM-117](https://easywmsfrance.atlassian.net/browse/LIM-117) | Ticket Jira (LOT 2.1, mapping adresse SOR de tournée, Ouvert) | 2026-07 |
@@ -1,16 +1,16 @@
 ---
-title: "Flux expédition — Processus complet"
+title: "Flux expédition - Processus complet"
 tags: [outbound, expédition, défragmentation, étiquetage, chargement, recertification, messagerie, litiges, AGV]
 status: draft
 standard_ref: concepts/shipping.md
-jira_refs: []
+jira_refs: [LIM-105, LIM-107, LIM-111]
 confluence_refs: ["Expédition - LIMAGRAIN - DEV"]
-sources: [FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5.docx, "Expédition - LIMAGRAIN - DEV - Confluence.md"]
+sources: [FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5.docx, "Expédition - LIMAGRAIN - DEV - Confluence.md", "Jira LIM-105 (lecture directe 2026-07-20)", "Jira LIM-107 (lecture directe 2026-07-20)", "Jira LIM-111 (lecture directe 2026-07-20)"]
-last_updated: 2026-05-13
+last_updated: 2026-07-20
 author: Arthur
 ---
-# Flux expédition — Processus complet
+# Flux expédition - Processus complet
 > **Résumé** : processus d'expédition de bout en bout en 12 étapes, de la
 > réception de l'OS jusqu'à la libération du quai, incluant les flux
@@ -63,7 +63,7 @@ ordonnancés par n° de STOP). Voir [Ordres de sortie](shipping-orders.md).
 ### 3. Assignation du stock
-Voir [Ordres de sortie — Assignation](shipping-orders.md#assignation-de-stock)
+Voir [Ordres de sortie - Assignation](shipping-orders.md#assignation-de-stock)
 pour les stratégies détaillées (FIFO 24h, économie de mouvement, pas de
 FEFO, max palettes complètes).
@@ -71,12 +71,12 @@ FEFO, max palettes complètes).
 | Type de palette | Action |
 |-----------------|--------|
-| Palettes complètes / picking terminées | [CUSTOM] Tâche de défragmentation (reloc) vers zone d'expédition ASRS. Ne se déclenche que si **toutes** les palettes clientes sont « terminées » et qu'aucun quai n'est associé à l'OS. Voir [Défragmentation custom](../02-stockage/defragmentation.md#custom-défrag-client-par-tournée--quai-non-assigné-lim-87). |
+| Palettes complètes / picking terminées | [CUSTOM] Tâche de défragmentation (reloc) vers zone d'expédition ASRS. Ne se déclenche que si **toutes** les palettes clientes sont « terminées » et qu'aucun quai n'est associé à l'OS. Voir [Défragmentation custom](../02-stockage/defragmentation.md#custom-défrag-client-par-tournée---quai-non-assigné-lim-87). |
 | Palettes picking | Aucune tâche tant qu'un poste de travail n'est pas assigné |
 > **Règle générale** : on n'envoie aucune palette sur l'image de quai tant
 > que le picking n'est pas terminé (et que les palettes sont revenues à
-> l'ASRS) — sauf si le stop précédent est fini.
+> l'ASRS) - sauf si le stop précédent est fini.
 >
 > **Deux customs complémentaires** gèrent l'ordonnancement par STOP :
 > quai non assigné → [Défragmentation custom](../02-stockage/defragmentation.md),
@@ -126,7 +126,7 @@ workflow `StackerCrane_SortTasks_PR`.
 | Règle | Détail |
 |-------|--------|
 | Picking négatif | **Deux conditions cumulatives** (réu. 11/05/2026) : seuil fiche article (défaut **55%**, pas 50%) ET poids unitaire sac **≥ 7 kg**. Si l'une des deux n'est pas remplie → picking direct classique. Voir [Picking combinatoire](../03-picking/picking-combinatoire.md#custom-règle-du-picking-négatif). |
-| ~~Traitement commercial~~ | ~~Articles avec/sans traitement sur palettes filles séparées~~ — **SUPPRIMÉ** (réu. 11/05/2026, `CONTROLE_TRAITEMENT_COMMERCIAL = false`). L'entrepôt ne fait pas de bio. |
+| ~~Traitement commercial~~ | ~~Articles avec/sans traitement sur palettes filles séparées~~ - **SUPPRIMÉ** (réu. 11/05/2026, `CONTROLE_TRAITEMENT_COMMERCIAL = false`). L'entrepôt ne fait pas de bio. |
 | Verrou « HORS TOLERANCE » | Si présent → recomptage avant picking. Si stock restant suffisant après inventaire → assignation maintenue. Sinon → réassignation ailleurs + retrait verrou. |
 #### Algorithme de répartition des palettes sur les TP
@@ -135,7 +135,7 @@ workflow `StackerCrane_SortTasks_PR`.
 enchaînements, ordonnancement par espèce, terminer une palette pleine
 avant d'en entamer une autre, cadencement des buffers, pas de mélange
 traitement commercial, contrainte opérateur (pas de déplacement de sacs
-d'une table à l'autre — sacs lourds).
+d'une table à l'autre - sacs lourds).
 **Table du milieu** : toujours occupée soit par une palette de picking
 négatif, soit par une palette vide de dépôt. Palette vide remise
@@ -154,12 +154,16 @@ classe de commande.
 #### Message MOV
 ~~À chaque déplacement de stock durant le picking, un message MOV est
-envoyé à SAP.~~ **ANNULÉ** — vu en réunion client, jugé inutile.
+envoyé à SAP.~~ **ANNULÉ** - vu en réunion client, jugé inutile.
 #### Filmage
 Avant chaque évacuation, l'opérateur choisit le programme de filmage
-(CstData transmis à Galileo). Possibilité de choisir « pas de filmage ».
+(stocké dans `CstAtt05`, transmis à Galileo). Possibilité de choisir « pas
 de filmage ». Le mécanisme de transmission (event `MovementCreated` sur
 source PIE_02 → CustomData de la tâche) est décrit dans
 [Configuration Galileo - Transmission du filmage](../02-stockage/galileo-config.md#transmission-du-programme-de-filmage-à-la-filmeuse-lim-115)
 (LIM-115).
 **Programmes de filmage disponibles** :
@@ -264,47 +268,90 @@ deuxième chargement est recréé automatiquement pour le reliquat.
 | Élément | Mode de libération |
 |---------|-------------------|
-| Image de quai | **Automatique** — dernière palette chargée |
+| Image de quai | **Automatique** - dernière palette chargée |
-| Quai | **Manuel** — départ du camion |
+| Quai | **Manuel** - départ du camion |
 ## Étiqueteuse automatique
 > **Statut** : le **mécanisme d'intégration Galileo** est spécifié dans
 > **LIM-111** (Ouvert) ; le **contenu des rapports** relève de **LIM-107** ;
 > la **pose initiale du flag `CstAtt14` au PK** relève de **LIM-91**. Cette
 > section documente le fonctionnement au poste de sortie TK.
 ### Principe
-Deux étiqueteuses au niveau des deux postes de sortie TK, pouvant imprimer
+Deux étiqueteuses automatiques, **LBLM_01** et **LBLM_02** (stations de type
-une ou plusieurs étiquettes selon le processus.
+**ET**), équipent les deux postes de sortie de l'ASRS, sur les convoyeurs
 allant vers les images de quai. Elles servent **uniquement** aux supports
 qui sortent de l'ASRS pour aller **directement sur une image de quai** dans
 un flux d'expédition. Elles peuvent poser une ou deux étiquettes selon le
 processus. Le WMS envoie un *print command* avec l'un des rapports (mono ou
 multiréférence) - voir
 [Étiquette support RFID](../01-inbound/etiquette-rfid.md).
 Positionnement dans la chaîne : sortie TK (ordonnancée par n° STOP, voir
 [Séquençage shipping par STOP](sequencage-shipping-stop.md)) → table de
 sortie TK → **étiqueteuse ET** → poste de sortie PS → AGV Still → image de
 quai → chargement camion.
 ### Étiquetage au picking (étiqueteuse auto)
-100% des palettes passant par le picking sont étiquetées (étiquette
+100% des palettes passant par le picking sont étiquetées (étiquette de
-d'expédition) directement au PK. Un `CstAtt` est positionné à `true` sur
+picking HU RFID) directement au PK. Le flag `CstAtt14` est positionné à
-la palette pour indiquer qu'elle a déjà été étiquetée.
+`true` sur la palette (LIM-91) pour indiquer qu'elle a déjà été étiquetée.
-### Comportement à la sortie TK
+### Comportement à la sortie TK - décision d'impression (LIM-111)
-L'étiqueteuse **n'imprime pas** si :
+Deux étiquettes **distinctes** peuvent être posées, avec des règles
 **séparées**. Le flag **`CstAtt14`** (Container, String - voir
 [AD Customs](../07-admin/ad-customs.md#cstatt-support-container--palette)) ne conditionne
 que la **2e** (étiquette de picking), pas l'étiquette d'expédition.
- `CstAtt` = `true` (palette déjà étiquetée au picking)
+| Étiquette | Rapport | Condition d'impression |
- OU hauteur palette trop faible (PLC height type = 1)
+|-----------|---------|------------------------|
 | Expédition (client / production) | LIM-107 | **Toujours**, sauf palette trop basse (PLC Height Type = 1). Indépendante de `CstAtt14`. |
 | Picking (HU RFID mono/multiréférence) | LIM-68 | Uniquement si `CstAtt14` = `false`/vide **et** PLC Height Type ≠ 1. Non imprimée si `CstAtt14` = `true` (déjà étiquetée au PK) ou palette trop basse. |
-L'étiqueteuse **imprime** si :
+**Cas d'usage de la 2e étiquette** : une palette complète sortie
 directement de l'ASRS vers l'image de quai **sans passer par un poste de
 picking** n'a pas ses étiquettes HU RFID → `CstAtt14` vide → l'étiqueteuse
 les pose (monoref ou multiref RFID selon le nombre de lignes de stock).
- `CstAtt` = `false` ET PLC height type ≠ 1
+**Mise à jour du flag** après passage à l'étiqueteuse :
 - Si impression réussie → `CstAtt` passe à `true`
 - Si impression échouée → `CstAtt` passe à `error`
-### Mode dégradé — Chargement camion
+- Impression OK → `CstAtt14` passe à `true`
 - Impression échouée → `CstAtt14` passe à `error` (voir Gestion des pannes)
-Si l'opérateur scanne une palette sans étiquette (`CstAtt` = `false` ou
+> ⚠️ La condition « PLC Height Type ≠ 1 » sur l'étiquette d'expédition
-`error`, PLC height type ≠ 1) au chargement camion → impression
+> reste **à vérifier** avec le fournisseur (LIM-111 §4.2).
 automatique sur une imprimante proche du quai.
-### Communication Galileo
+### Mode dégradé - Chargement camion
-On envoie un **custom data** à Galileo (pas de changement de
+Si l'opérateur scanne une palette sans étiquette (`CstAtt14` = `false` ou
-destination/route). Galileo, en recevant le custom data avec le bon
+`error`, PLC height type ≠ 1) au chargement camion → le WMS propose de
-tracking de palette, arrête les rouleaux et lance l'impression. Un seul
+réimprimer le rapport d'expédition (LIM-107), avec prompt du code
-chemin — l'arrêt est piloté par le custom data.
+imprimante. Réimpression via imprimante proche du quai (menu TRF dédié).
 ### Communication Galileo (LIM-111)
 Pilotage **par custom data**, sans changement de destination ni de route
 (un seul chemin physique). Même principe que le filmage (CstAtt05 → custom
 data, voir LIM-91).
 Points d'insertion :
 - **Subscription sur l'event `MovementCreated`** : si la destination est
  une étiqueteuse (`LBLM_01`/`LBLM_02`), le WMS met à jour le **CustomData
  de la tâche** avec le **nombre d'étiquettes** à imprimer. Ce nombre est
  essentiel : il indique au **bras articulé** s'il y a une ou deux
  positions de collage.
 - Galileo, en recevant le custom data avec le bon tracking de palette,
  **arrête les rouleaux**.
 - À la **fin d'ordre** (event = palette arrivée à l'étiqueteuse), le WMS
  lance le **`printerCommand`**. Le contenu du rapport est envoyé
  directement à l'imprimante par EasyWMS via le **`printerService`**.
 - Galileo gère l'impression et le **collage**, puis la **relance des
  rouleaux**.
 ### Multi-étiquettes (2 étiquettes)
@@ -321,10 +368,68 @@ la palette (positions à définir avec Théo).
 - [CUSTOM Galileo] Communication HS imprimante → mise en défaut ET à
  documenter dans le document TMS
 ### Contenu des étiquettes d'expédition par type (LIM-107)
 > **Statut (LIM-107)** : en revue de code.
 Dès qu'une palette sort de l'installation pour expédition, un rapport est
 imprimé **selon le type d'expédition** (classe de l'OS). Format **A5**. Le
 type est déterminé par la classe de l'OS via les paramètres
 `EXPEDITION_CLASSE_CLIENT` / `EXPEDITION_CLASSE_PRODUCTION` (voir
 [Paramètres projet](../07-admin/parametres-projet.md)).
 Où l'étiquette est imprimée (arbitrage Justine 02/07/2026) :
 - **Client** et **Production** → sur les **étiqueteuses automatiques**
  d'expédition (sortie TK).
 - **Échantillonnage** → sur les **étiqueteuses des postes de travail**, via
  le flux inventaire COR/COF. Contenu détaillé dans
  [Échantillonnage - Étiquette d'échantillonnage](../03-picking/echantillonnage.md#étiquette-déchantillonnage-lim-107).
 Étiquette **CLIENT** (report `CST_RPT_OUTBOUND_CLIENT`) :
 | # | Champ |
 |---|-------|
 | 1 | Code de la tournée |
 | 2 | Code de l'OS |
 | 3 | Code du transporteur de l'OS |
 | 4 | Adresse de livraison de l'OS |
 Étiquette **PRODUCTION** (report `CST_RPT_OUTBOUND_PRODUCTION`) :
 | # | Champ |
 |---|-------|
 | 1 | Code de l'OS |
 | 2 | Code-barre 128 du code de l'OS |
 | 3 | `SOR.Document` |
 Une **impression manuelle** est aussi disponible depuis la vue conteneurs
 (`ContainerVList`) via deux boutons (« Imprimer étiquette d'expédition
 client / production »), affichés sous condition que le conteneur soit un
 conteneur client ou d'expédition de la bonne classe d'OS.
 | Élément AD | Type | Rôle |
 |------------|------|------|
 | `EXPEDITION_CLASSE_CLIENT` / `EXPEDITION_CLASSE_PRODUCTION` | Paramètre | Classe d'OS identifiant le type d'expédition (client / production). |
 | `CST_RPT_OUTBOUND_CLIENT` | Report | Étiquette d'expédition client. |
 | `CST_RPT_OUTBOUND_PRODUCTION` | Report | Étiquette d'expédition production. |
 | `CST_RPT_ECHANTILLONAGE` | Report | Étiquette d'échantillonnage (voir [Échantillonnage](../03-picking/echantillonnage.md)). |
 | `CST_VSearchPrintShippingClientContainerLabel` | Vue | Génération de l'étiquette d'expédition client. |
 | `CST_VSearchPrintShippingProductionContainerLabel` | Vue | Génération de l'étiquette d'expédition production. |
 | `ContainerVList` | Vue | Ajout des 2 boutons de génération d'étiquette (sous condition de classe d'OS). |
 | `CST_ContainerVList_Action_PrintShippingClientLabel` / `...ProductionLabel` | Ressource i18n | Libellés des boutons d'impression. |
 | `CST_ShippingClientContainerLabel` (client + production) | Ressource i18n | Libellés « Générer étiquette expédition client / production ». |
 ## Flux spécifiques
 ### Re-certification
 > **Workstation LIM-105** : le **process opérateur détaillé au poste de
 > picking** (scan ancienne/nouvelle étiquette, vérification ASN via
 > `SAP_ATH111_*`, échange de conteneur, filmage, éléments AD) est documenté
 > dans [Recertification - Workstation au poste de picking](../03-picking/recertification.md).
 > La section ci-dessous décrit le **flux outbound** de bout en bout.
 La re-certification consiste à ré-étiqueter une palette existante pour
 lui donner une nouvelle identité (nouvelle HU) sans déplacer physiquement
 le stock. C'est une **sortie administrative** suivie d'une **réception
@@ -343,7 +448,7 @@ manager), ce qui bloque le PK pour les autres types de tâches.
   (ex: PK02) dans un CstAtt de la palette
 5. **Route virtuelle** : la palette est déplacée informatiquement du PK
   vers QUAI_RECERTIF
-6. [CUSTOM] **Event sur le déplacement vers QUAI_RECERTIF** — 3 actions :
+6. [CUSTOM] **Event sur le déplacement vers QUAI_RECERTIF** - 3 actions :
   - Récupération du CstAtt (code PK d'origine)
   - Fermeture de la commande → expédition du stock → génération du SOF
   - Création d'une **palette vide** sur le PK d'origine (pour maintenir
@@ -426,7 +531,7 @@ SOR.Line si besoin.
   - S'il reste du stock dispo : assignation maintenue (workflow
     `OnStockAdjust` recalcule uniquement si nécessaire)
   - Si plus assez de stock → réassignation ailleurs
-3. Autre problème — le support n'est pas ok (90% du stock a un problème) :
+3. Autre problème - le support n'est pas ok (90% du stock a un problème) :
   - **Verrou de support** interdisant le picking (bouton « mettre sous
     révision » en standard, à configurer)
   - Tâche créée pour que l'AGV dépose la palette sur un **emplacement
@@ -464,20 +569,26 @@ documentés pour chaque process.
 ## Questions ouvertes
- [ ] Ordonnancement des palettes dans le canal du poumon d'expé du
+- ❓ Ordonnancement des palettes dans le canal du poumon d'expé du
-  magasin automatique — géré par le WMS ou naturellement via l'ordre
+  magasin automatique - géré par le WMS ou naturellement via l'ordre
  de stockage ? (@Nicolas)
- [ ] Fermeture auto OS si chargement complet — standard ou custom ?
+- ❓ Fermeture auto OS si chargement complet - standard ou custom ?
  (@Nicolas)
- [ ] Comportement du reliquat chargement camion avec fichier RUT —
+- ❓ Comportement du reliquat chargement camion avec fichier RUT -
  à paramétrer et tester (@Fabien)
- [ ] Positions des 2 étiquettes articulées sur la palette (@Théo)
+- ❓ Positions des 2 étiquettes articulées sur la palette (@Théo)
- [ ] Custom Galileo : communication HS imprimante → mise en défaut ET
+- ❓ Custom Galileo : communication HS imprimante → mise en défaut ET
-  — à documenter dans le TMS (@Théo)
+  - à documenter dans le TMS (@Théo)
- [ ] Combien de commandes messagerie en parallèle sur un poste ? (@Justine)
+- Étiqueteuse auto (LIM-111) : mécanisme de remontée d'une erreur
- [ ] Emplacement au sol buffer litige — localisation exacte (@Théo)
+  d'impression par les automates au WMS à définir - nécessaire pour que
- [ ] Emplacement au sol messagerie carton par transporteur (@Théo)
+  le mode dégradé TRF sache si l'impression a réussi (@Vincent)
- [ ] Réunion technique avec Still pour valider le problème de dépose
+- Étiqueteuse auto (LIM-111) : palette à l'arrêt en cas de problème
  d'impression - intervention opérateur (laquelle ?) et procédure de
  redémarrage de la palette à définir (@Théo / @Vincent)
 - ❓ Combien de commandes messagerie en parallèle sur un poste ? (@Justine)
 - ❓ Emplacement au sol buffer litige - localisation exacte (@Théo)
 - ❓ Emplacement au sol messagerie carton par transporteur (@Théo)
 - ❓ Réunion technique avec Still pour valider le problème de dépose
  AGV sur image de quai (@Théo)
 ## Historique des modifications
@@ -486,4 +597,18 @@ documentés pour chaque process.
 |------|--------|--------------|
 | 2026-05-05 | Arthur | Création initiale depuis AF V1.5 |
 | 2026-05-05 | Arthur | Réécriture complète depuis ateliers DEV expédition |
-| 2026-05-13 | Arthur | Correction seuil picking négatif 50% → 55% + poids ≥ 7 kg, suppression règle traitement commercial |
+| 2026-05-13 | Arthur | Correction seuil picking négatif 50% → 55% + poids ≥ 7 kg, suppression règle traitement commercial |
 | 2026-07-20 | Arthur | Renvoi vers la nouvelle page [Recertification workstation](../03-picking/recertification.md) (LIM-105) depuis la section Re-certification ; front matter jira_refs/sources/last_updated |
 | 2026-07-20 | Arthur | LIM-107 (lecture directe, en revue de code) : sous-section « Contenu des étiquettes d'expédition par type » sous Étiqueteuse automatique (format A5 ; Client/Production sur étiqueteuses auto, Échantillonnage sur poste via COR/COF ; contenu étiquettes Client 4 champs + Production 3 champs ; params EXPEDITION_CLASSE_CLIENT/PRODUCTION ; reports/vues/ContainerVList/ressources ; impression manuelle via 2 boutons ContainerVList) ; front matter jira_refs +LIM-107/sources |
 | 2026-07-20 | Arthur | LIM-111 (lecture directe, Ouvert) : formalisation de l'intégration Galileo de l'étiqueteuse (noms de stations LBLM_01/LBLM_02 type ET ; refonte « Comportement à la sortie TK » en logique 2 étiquettes distinctes - expédition LIM-107 toujours sauf palette basse, picking LIM-68 conditionnée par CstAtt14 ; mécanisme Galileo subscription MovementCreated → CustomData nombre d'étiquettes → printerCommand/printerService ; CstAtt14 nommé) ; front matter jira_refs +LIM-111/sources ; 2 questions ouvertes (remontée erreur impression, palette à l'arrêt) |
 | 2026-07-20 | Arthur | Lint : ajout section Références ; correction ancres et liens |
 ## Références
 | Source | Type | Date |
 |--------|------|------|
 | FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5 | AF (docx) | 2026 |
 | "Expédition - LIMAGRAIN - DEV" Confluence | Page | 2026 |
 | [LIM-105](https://easywmsfrance.atlassian.net/browse/LIM-105) | Ticket Jira (lecture directe) | 2026-07-20 |
 | [LIM-107](https://easywmsfrance.atlassian.net/browse/LIM-107) | Ticket Jira (lecture directe) | 2026-07-20 |
 | [LIM-111](https://easywmsfrance.atlassian.net/browse/LIM-111) | Ticket Jira (lecture directe) | 2026-07-20 |
@@ -1,16 +1,16 @@
 ---
-title: "Séquençage shipping par STOP — Quai assigné"
+title: "Séquençage shipping par STOP - Quai assigné"
 tags: [outbound, expédition, shipping, tournée, STOP, stacker-crane, custom, AGV]
-status: draft
+status: review
 standard_ref: concepts/shipping.md
-jira_refs: [LIM-88]
+jira_refs: [LIM-88, LIM-94]
 confluence_refs: ["Expédition - LIMAGRAIN - DEV"]
-sources: ["LIM-88 LOT2.1 [TOURNÉES] Séquençage des tâches de shipping par STOP - quai assigné.md"]
+sources: ["LIM-88 LOT2.1 [TOURNÉES] Séquençage des tâches de shipping par STOP - quai assigné.md", "Jira LIM-88 (lecture directe, revue de code)"]
-last_updated: 2026-05-12
+last_updated: 2026-07-17
 author: Arthur
 ---
-# Séquençage shipping par STOP — Quai assigné
+# Séquençage shipping par STOP - Quai assigné
 > **Résumé** : quand un quai est déjà assigné à une tournée (RUT),
 > les palettes doivent sortir de l'ASRS vers l'image de quai dans
@@ -30,9 +30,12 @@ Ce custom est le **cas complémentaire** de la
 (LIM-87) qui traite le cas « quai non assigné ».
 Ici, le quai est **déjà assigné au RUT** quand la tournée est libérée
-(ou assigné avant la fin du picking, ou après). Dans ce cas, LIM-87
+(ou assigné avant la fin du picking, ou après). L'assignation de l'image
-(défrag custom) ne s'applique pas : c'est le **flux shipping standard**
+de quai peut être manuelle ou **automatique** via le job LIM-94 (voir
-qui prend le relais pour envoyer les palettes vers l'image de quai.
+[Assignation automatique de l'image de quai](assignation-image-quai.md)).
 Dans ce cas, LIM-87 (défrag custom) ne s'applique pas : c'est le **flux
 shipping standard** qui prend le relais pour envoyer les palettes vers
 l'image de quai.
 Il faut néanmoins respecter la règle métier d'ordonnancement par n° de
 STOP (ordre inverse : STOP max → STOP 1) pour que les palettes soient
 posées sur l'image de quai dans le bon ordre de chargement camion.
@@ -50,7 +53,7 @@ pas :
 > Custom imaginé au départ : bloquer la génération des tâches de
 > shipping tant que tout le picking n'est pas terminé.
-Trop restrictif — on ne profiterait pas du temps pendant lequel les
+Trop restrictif - on ne profiterait pas du temps pendant lequel les
 palettes complètes pourraient déjà être pré-positionnées sur l'image
 de quai dans l'ordre. Par ailleurs, bloquer la génération de tâche est
 complexe car de nombreux process la déclenchent (pas uniquement des
@@ -65,7 +68,7 @@ jobs).
 Dès que le quai est assigné, toutes les palettes prêtes (complètes
 dans l'ASRS + palettes filles revenues de picking) ont leur tâche de
 shipping générée par le standard. Une palette non encore pickée n'a
-pas de tâche — sa tâche sera créée au moment où elle rentrera dans un
+pas de tâche - sa tâche sera créée au moment où elle rentrera dans un
 TK après picking.
 #### 2. Ordonnancement d'exécution (custom stacker crane)
@@ -99,7 +102,7 @@ palette rentre bien dans l'ASRS.
 - **Le tri du stacker crane doit considérer les palettes sur tous les
  TK** (pas uniquement celles dans un TK unique comme en standard).
-  Pattern déjà réalisé sur le **projet Bardinet** — à reprendre.
+  Pattern déjà réalisé sur le **projet Bardinet** - à reprendre.
 ### Ce qui reste standard
@@ -109,6 +112,40 @@ palette rentre bien dans l'ASRS.
  si pas de stock trouvé → palettes suivantes du STOP envoyées ;
  si nouveau stock trouvé → récupère le séquençage
 ## Implémentation définitive (revue de code validée 2026-06-02)
 > **Statut** : En cours de test client (pré-production). Revue de code
 > et tests validés. Deux revues successives : le tri multi-TK (Maxime
 > Halgand) puis un garde-fou complémentaire sur la génération des
 > tâches de chargement (Vincent Charvet).
 Le custom se limite à une **query clonée** et deux **workflows**
 overridés. Aucune génération de tâche custom : le standard crée les
 tâches shipping au fil de l'eau, le custom n'intervient qu'au **tri**
 et pose un garde-fou sur la génération des tâches de chargement AGV.
 ### Query
 | Élément | Rôle |
 |---|---|
 | `CST_Tasks_PendingOutboundForStackerCrane` | Cœur du custom. Clone de `Tasks_PendingOutboundForStackerCrane`. Filtre pour récupérer toutes les tâches shipping, conteneurs picking, conteneurs shipping et conteneurs client d'un **numéro de STOP supérieur**, et vérifier s'ils sont **tous en station image de quai (DockStage)** ou non |
 ### Workflows
 | Workflow | Modification |
 |---|---|
 | `StackerCrane_GetOutboundPendingTasks_PR` | Utilise la query custom au lieu de la standard. Ajoute un log pour conserver les informations de recherche |
 | `Outbound_CreateShippingOrLoadTasksToDockOrStage_PR` | Empêche la création d'une tâche de chargement s'il n'y a **pas de stage (image de quai) associé à l'OS**. Sans ce garde-fou, les palettes bloquent aux PS car les AGV n'ont pas de destination pour effectuer le mouvement (commit `0aec1c3b`). Le stage est posé par [LIM-94](assignation-image-quai.md) |
 ### Règle de filtrage
 Le filtre ne bloque que les **sorties d'expédition** : une palette d'un
 STOP donné ne sort vers l'image de quai que si tous les STOP supérieurs
 sont déjà arrivés en station DockStage. En revanche, les **sorties de
 palettes picking restent toujours autorisées** pour permettre le
 prélèvement anticipé : le picking n'est jamais bloqué par le
 séquençage.
 ## Flux fonctionnel
 ```mermaid
@@ -149,7 +186,7 @@ sequenceDiagram
 |----|--------------|------------------|
 | CT-01 | RUT mono-STOP, 3 PC dans ASRS, quai assigné | 3 tâches shipping, palettes partent vers image de quai |
 | CT-02 | RUT multi-STOP (1, 2, 3), 2 PC chacun, quai assigné | 6 tâches. Stacker crane exécute STOP 3, puis 2, puis 1 |
-| CT-03 | RUT multi-STOP, picking terminé avant libération, toutes PF revenues | Identique à CT-02 — PF ou PC, même logique |
+| CT-03 | RUT multi-STOP, picking terminé avant libération, toutes PF revenues | Identique à CT-02 - PF ou PC, même logique |
 ### Cas limites (cœur du custom)
@@ -173,7 +210,7 @@ sequenceDiagram
 | CT-09 | 2 RUT en parallèle, quais distincts | Ordonnancement indépendant par RUT. Pas de fuite de tri |
 | CT-11 | RUT A avec quai, RUT B sans quai | RUT A traité par ce custom. RUT B relève de LIM-87 (défrag). Vérifier absence d'interférence |
 | CT-12 | SOR ajouté à un RUT en cours d'exécution | Nouvelles palettes s'insèrent dans l'ordre STOP. Si picking nécessaire → PF reviendront à l'ASRS |
-| CT-13 | Bascule de quai en cours de tournée | **À définir en recette.** Tâches restantes regénérées vers nouveau quai. Palettes déjà à l'ancien quai → traitement manuel |
+| CT-13 | Bascule de quai en cours de tournée | **Scénario exclu** : on ne peut pas changer le quai une fois la RUT libérée (contrainte WMS, note dev revue de code). Une rebascule relève d'une opération manuelle exceptionnelle, hors périmètre custom |
 ### Stock reassign au picking
@@ -184,25 +221,31 @@ sequenceDiagram
 ## Points d'attention
-⚠️ Le custom de tri multi-TK reprend un **pattern Bardinet** — ne pas
+⚠️ Le custom de tri multi-TK reprend un **pattern Bardinet** - ne pas
 réinventer le mécanisme.
 ⚠️ Le retour systématique des PF vers l'ASRS (pas de crossdock) est
 le comportement standard attendu mais **doit être validé en recette**.
-⚠️ La bascule de quai en cours de tournée (CT-13) n'est pas couverte
+⚠️ La bascule de quai en cours de tournée (CT-13) est **impossible** :
-par le custom — les palettes déjà à l'image de quai de l'ancien quai
+le quai ne peut pas être changé une fois la RUT libérée. Une rebascule
-sont à traiter manuellement.
+serait une opération manuelle exceptionnelle, hors périmètre custom.
 ⚠️ Les tâches de chargement ne doivent jamais être générées sans image
 de quai associée à l'OS, sinon les palettes bloquent aux PS (les AGV
 n'ont pas de destination). Garde-fou porté par
 `Outbound_CreateShippingOrLoadTasksToDockOrStage_PR`.
 ## Questions ouvertes
- [ ] Retour PF vers ASRS (CT-08) : confirmer que le standard crée
+- ❓ Retour PF vers ASRS (CT-08) : confirmer que le standard crée
  bien une tâche de rangement quand pas de route vers l'image de quai.
  Sinon custom de secours nécessaire. (@Nicolas)
  → voir [Questions ouvertes](../08-transverse/questions-ouvertes.md)
- [ ] Bascule de quai en cours de tournée (CT-13) : définir le
+- [x] ~~Bascule de quai en cours de tournée (CT-13) : définir le
-  comportement attendu pour les palettes déjà à l'ancien quai.
+  comportement attendu pour les palettes déjà à l'ancien quai.~~
-  (@Justine)
+  → **Résolu** (note dev, revue de code) : on ne peut pas changer le
  quai une fois la RUT libérée. Scénario exclu du custom.
  → voir [Questions ouvertes](../08-transverse/questions-ouvertes.md)
 ## Historique des modifications
@@ -210,11 +253,14 @@ sont à traiter manuellement.
 | Date | Auteur | Modification |
 |------|--------|--------------|
 | 2026-05-12 | Arthur | Création initiale depuis LIM-88 |
 | 2026-07-17 | Arthur | Ajout implémentation définitive (revue de code 02/06 : query `CST_Tasks_PendingOutboundForStackerCrane`, WF `StackerCrane_GetOutboundPendingTasks_PR` + `Outbound_CreateShippingOrLoadTasksToDockOrStage_PR`, règle picking toujours autorisé) ; statut préprod ; résolution CT-13 (quai non modifiable après libération RUT) |
 | 2026-07-17 | Arthur | Cross-ref LIM-94 (assignation auto de l'image de quai / stage `X_EXP` dont dépend le garde-fou de chargement) ; jira_refs +LIM-94 |
 ## Références
 | Source | Type | Date |
 |--------|------|------|
-| [LIM-88](https://easywmsfrance.atlassian.net/browse/LIM-88) | Ticket Jira | 2026 |
+| [LIM-88](https://easywmsfrance.atlassian.net/browse/LIM-88) | Ticket Jira (statut préprod / test client) | 2026 |
 | Revue de code LIM-88 (M. Halgand, V. Charvet, N. Chabanis) | Revue de code validée, commit `0aec1c3b` | 2026-06-02 |
 | Expédition - LIMAGRAIN - DEV | Page Confluence | 2026 |
-| Projet Bardinet | Pattern custom stacker crane multi-TK | — |
+| Projet Bardinet | Pattern custom stacker crane multi-TK | - |
@@ -1,16 +1,16 @@
 ---
-title: "Ordres de sortie — Types et libération"
+title: "Ordres de sortie - Types et libération"
 tags: [outbound, OS, SOR, RUT, libération, assignation, FIFO, LOC]
 status: draft
 standard_ref: concepts/order-outbound.md
-jira_refs: []
+jira_refs: [LIM-109, LIM-110]
 confluence_refs: ["Expédition - LIMAGRAIN - DEV"]
-sources: [FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5.docx, "Expédition - LIMAGRAIN - DEV - Confluence.md", "CR CONSOLIDES REU ERP LIMAGRAIN V1 - CR.md"]
+sources: [FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5.docx, "Expédition - LIMAGRAIN - DEV - Confluence.md", "CR CONSOLIDES REU ERP LIMAGRAIN V1 - CR.md", "Jira LIM-109 (lecture directe 2026-07-20)", "Jira LIM-110 (lecture directe 2026-07-20)"]
-last_updated: 2026-05-06
+last_updated: 2026-07-20
 author: Arthur
 ---
-# Ordres de sortie — Types et libération
+# Ordres de sortie - Types et libération
 > **Résumé** : 4 types d'ordres de sortie chez Limagrain, avec des
 > comportements de libération, d'assignation et de préparation distincts.
@@ -51,6 +51,29 @@ re-certification. Le message d'entrée diffère selon le type.
 - Chaque OS peut avoir plusieurs **lignes** (article + quantité)
 - Chaque palette est étiquetée et ordonnancée par **n° STOP**
 ## [CUSTOM] Lot obligatoire sur les lignes d'OS (LIM-109)
 > **Statut (LIM-109)** : dev terminé, en attente de déploiement pour test.
 > Revue de code validée (Maxime, 29/06/2026).
 La création d'un ordre de sortie ou d'une **ligne d'OS** est **interdite si
 l'attribut logistique lot n'est pas renseigné**. Le lot est indispensable à
 l'assignation de stock (critère « article/lot SAP », voir
 [Assignation de stock](#assignation-de-stock)) : une ligne sans lot ne
 pourrait jamais être servie.
 Le contrôle est posé par une **subscription en Preview** sur l'event de
 création de ligne d'OS, qui lève une **exception** si le lot est vide. Combiné
 à `TransactionalLineList = true` (voir
 [Paramètres ERP](#paramètres-erp-des-sorrut)), le refus est **total** : tout
 l'import de l'OS est rejeté.
 | Élément AD | Type | Rôle |
 |------------|------|------|
 | `CST_OutboundOrderLineCreated_CheckLotRequired_PRE` | Subscription | En **Preview** sur l'event de création de ligne d'OS ; appelle le WF de contrôle. |
 | `CST_OutboundOrderLineCreated_CheckLotRequired_PRE_PR` | Workflow | Lève une exception si le lot n'est pas renseigné sur la ligne. |
 | `CST_OutboundOrderLineCreation_MissingLot` | Ressource i18n | Message d'erreur « lot manquant ». |
 ## Paramètres ERP des SOR/RUT
 | Paramètre | Valeur | Commentaire |
@@ -62,7 +85,7 @@ re-certification. Le message d'entrée diffère selon le type.
 | CompleteSorList (RUT) | true | SOR absents de la RUT = supprimés |
 | AllowAssignStockExcess | true | Palettes pleines, jamais de picking partiel |
 | Limite d'annulation | Statut "Chargé" | Avant = OK, après = refusé |
-| IgnoreNulls (RUT) | false | — |
+| IgnoreNulls (RUT) | false | - |
 ## Gestion des ruptures SOR Production
@@ -76,9 +99,63 @@ manuel.
 ## Quai recertification
-Pour les SOR de type recertification :
+> **Statut (LIM-110)** : en cours de test client (pré-production). Revue de
-`AssignedDockStationCode = "QUAI_RECERTIFICATION"` (quai fictif, renseigné
+> code validée (Maxime, 03/07/2026).
-par Limagrain dans le SOR).
+
 Le quai de recertification (`QUAI_RECERTIFICATION`, code porté par le
 paramètre `RECERTIFICATION_CODE_QUAI`) est **assigné automatiquement** par le
 WMS :
 - à la **création** d'un OS de classe RECERTIFICATION
  (`OutboundOrder_OutboundOrderCreatedEventHandler_PR`) ;
 - à l'**édition** d'un OS auquel on ajoute la classe RECERTIFICATION (ajout
  Vincent 09/07/2026).
 Ce quai est **réservé à ce process**. Le **changement manuel** du quai
 (assignation ou dé-assignation) est **empêché** : les boutons correspondants
 sont masqués dans la vue `OutboundOrderVList` pour les OS de recertification.
 > **Évolution vs V1** : le quai fictif `QUAI_RECERTIFICATION` était auparavant
 > renseigné par Limagrain **dans le SOR**. Il est désormais posé
 > **automatiquement** par le WMS (LIM-110).
 Ce quai n'est **pas** géré par le job d'assignation des images de quai X_EXP
 (LIM-94), qui **exclut** la classe Recertification (voir
 [Assignation image de quai](assignation-image-quai.md)).
 ### Stratégie d'assignation de stock RECERTIFICATION (LIM-110)
 Une stratégie d'assignation de stock spécifique, **« expédition uniquement des
 supports complets »**, est forcée pour les OS de classe RECERTIFICATION :
 - La stratégie (code `RECERTIFICATION`) est **toujours désactivée** en
  configuration : elle n'est jamais choisie par le mécanisme standard.
 - Lors de l'assignation de stock d'un OS de recertification, le choix est
  **forcé** sur cette stratégie
  (`StockAssignProcess_GetStockAssignStrategies_PR`).
 - Le flag `AllowPick` est **forcé à `false`**
  (`StockAssignProcess_GetStockToAssignForStrategy_PR`) : supports complets
  uniquement, pas de picking.
 - La stratégie est identifiée par une **balise `[XXX]`** dans son code, avec
  `XXX = RECERTIFICATION_CODE_QUAI` ; la query
  `CST_StockAssignStrategyV2_Recertification` récupère les stratégies portant
  ce tag.
 > ⚠️ La description du ticket indique que `RECERTIFICATION_CODE_QUAI` sert
 > aussi à **identifier les OS de classe recertification** ; à relier au
 > paramètre `RECERTIFICATION_CODE_CLASSE` (LIM-105) qui porte déjà ce rôle -
 > voir [questions ouvertes](../08-transverse/questions-ouvertes.md).
 | Élément AD | Type | Rôle |
 |------------|------|------|
 | `OutboundOrder_OutboundOrderCreatedEventHandler_PR` | Workflow | À la création d'un OS de recertification, assigne automatiquement le quai (paramètre `RECERTIFICATION_CODE_QUAI`). |
 | `StockAssignProcess_GetStockAssignStrategies_PR` | Workflow | Filtre les stratégies d'assignation de stock à appliquer pour les OS de recertification. |
 | `StockAssignProcess_GetLockAndUpdateDetail_PR` | Workflow | Récupère l'`OutboundClassCode`. |
 | `StockAssignProcess_GetStockToAssignForStrategy_PR` | Workflow | Force `AllowPick = false` pour les ordres de recertification. |
 | `OutboundOrderVList` | Vue | Masque les boutons d'assignation / dé-assignation de quai pour les OS de recertification. |
 | `CST_StockAssignStrategyV2_Recertification` | Query | Récupère les stratégies dont le code contient le tag `[code classe recertification]`. |
 | `OutboundOrder_CreatedEvent` | Subscription | Ajout du paramètre `OutboundClassCode`. |
 | `RECERTIFICATION_CODE_QUAI` | Paramètre | Code du quai recertification / balise `[XXX]` de la stratégie. Voir [Paramètres projet](../07-admin/parametres-projet.md). |
 ## Libération
@@ -125,12 +202,12 @@ Filtres appliqués :
 Dans l'ordre de priorité :
 1. **Article/lot SAP + attributs logistiques** spécifiés dans le SOR/RUT
-2. **Économie de mouvement** (minimum de mouvements) — **prioritaire**
+2. **Économie de mouvement** (minimum de mouvements) - **prioritaire**
 3. **FIFO sur 24h** : standard confirmé. Les palettes reçues le même jour
   ont le même FIFO (heures/minutes ignorées), ce qui permet de prendre
   la palette la plus accessible dans un canal. Pas de FIFO strict
   infra-journalier.
-4. **Pas de FEFO** — la proposition initiale de faire du FEFO sur du stock
+4. **Pas de FEFO** - la proposition initiale de faire du FEFO sur du stock
   sans DLC est **abandonnée**. Il n'y a pas de date d'expiration sur les
   produits. Le FIFO journalier est retenu.
 5. **Maximum palettes complètes** puis palettes incomplètes (avec picking)
@@ -169,7 +246,7 @@ Dans l'ordre de priorité :
 - [CUSTOM] Stratégie d'assignation excluant les supports multi-lignes
  (= mono-ref uniquement). Combiné avec AllowAssignStockExcess → shipping
  sans picking.
- Stock assigné directement déposé sur l'image de quai — aucun passage
+- Stock assigné directement déposé sur l'image de quai - aucun passage
  poste de travail
 - Ruptures de stock ne bloquent pas l'expédition. Le client utilise
  `isCritical` / `isRequired` au niveau SOR.Line si besoin.
@@ -179,7 +256,7 @@ Dans l'ordre de priorité :
 - Stock assigné mais **aucune tâche** tant que poste de travail non assigné
 - Le PK doit être passé en **mode recertif** (par le manager)
- Flux détaillé en 11 étapes — voir
+- Flux détaillé en 11 étapes - voir
  [Re-certification](flux-expedition.md#re-certification)
 ### Messagerie carton
@@ -188,7 +265,7 @@ Dans l'ordre de priorité :
 - Tous les OS de la RUT préparés **simultanément** sur un seul poste
 - Tri par transporteur (l'opérateur ne dépose que sur une seule palette)
 - Consolidation sur palette unique avec supports carton identifiés
- Pas d'image de quai — emplacement au sol dédié par transporteur
+- Pas d'image de quai - emplacement au sol dédié par transporteur
 - [CUSTOM] À l'import du SOR, vérification combo shipping class code +
  transporteur → si OK, poumon associé automatiquement
 - Voir [Messagerie carton](flux-expedition.md#messagerie-carton)
@@ -211,11 +288,11 @@ Possible depuis EasyWMS avec choix de destination :
 ## Points d'attention
-⚠️ La libération automatique est le mode principal — la date est dans le
+⚠️ La libération automatique est le mode principal - la date est dans le
 message ERP.
 ⚠️ L'assignation spécifie **toujours** les 4 critères (article, lot SAP,
-propriétaire, statut) — pas d'assignation « ouverte ».
+propriétaire, statut) - pas d'assignation « ouverte ».
 ⚠️ Le FIFO est à la **journée** (palettes du même jour = même rang FIFO),
 avec l'**économie de mouvement** prioritaire sur le FIFO. Pas de FEFO.
@@ -224,7 +301,7 @@ avec l'**économie de mouvement** prioritaire sur le FIFO. Pas de FEFO.
 possible **un canal dédié par route/STOP**.
 ⚠️ Le custom de défragmentation attend que toutes les palettes de picking
-soient terminées et retournées dans l'ASRS avant de lancer les relocs —
+soient terminées et retournées dans l'ASRS avant de lancer les relocs -
 c'est le développement clé du flux outbound.
 ## Historique des modifications
@@ -234,6 +311,8 @@ c'est le développement clé du flux outbound.
 | 2026-05-05 | Arthur | Création initiale depuis AF V1.5 |
 | 2026-05-05 | Arthur | Enrichissement : 5 types OS, FIFO 24h, pas de FEFO, custom défrag, conso OF détaillé, messagerie carton |
 | 2026-05-06 | Arthur | Ajout classifications, paramètres ERP, ruptures production, quai recertif (CR consolidé) |
 | 2026-07-20 | Arthur | LIM-109 (lecture directe, attente déploiement test, revue validée 29/06) : section [CUSTOM] Lot obligatoire sur les lignes d'OS (subscription Preview `CST_OutboundOrderLineCreated_CheckLotRequired_PRE` → WF exception si lot vide, ressource `CST_OutboundOrderLineCreation_MissingLot`, refus total via TransactionalLineList) ; front matter jira_refs/sources/last_updated |
 | 2026-07-20 | Arthur | LIM-110 (lecture directe, pré-production, revue validée 03/07) : refonte section Quai recertification (assignation auto du quai à la création ET à l'édition d'un OS recertif, blocage du changement manuel via OutboundOrderVList, param `RECERTIFICATION_CODE_QUAI`, évolution vs V1 renseigné dans le SOR, exclusion LIM-94) + sous-section Stratégie d'assignation de stock RECERTIFICATION (supports complets uniquement, forcée, toujours désactivée, AllowPick=false, tag `[XXX]`, query `CST_StockAssignStrategyV2_Recertification`) ; table AD ; caveat param QUAI vs CLASSE |
 ## Références
@@ -242,3 +321,5 @@ c'est le développement clé du flux outbound.
 | FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5 | Analyse fonctionnelle | 28/11/2025 |
 | Expédition - LIMAGRAIN - DEV - Confluence | Page ateliers DEV | 2026 |
 | CR CONSOLIDES REU ERP LIMAGRAIN V1 | CR ateliers interfaçage | 23/02/2026 |
 | [LIM-109](https://easywmsfrance.atlassian.net/browse/LIM-109) | Ticket Jira (interdire lignes d'OS sans lot - attente déploiement test) | 2026 |
 | [LIM-110](https://easywmsfrance.atlassian.net/browse/LIM-110) | Ticket Jira (quai recertification auto + stratégie assignation stock - pré-production) | 2026 |
@@ -1,11 +1,11 @@
 ---
-title: "AGV — Vue d'ensemble"
+title: "AGV - Vue d'ensemble"
 tags: [agv, still, igo, index]
 status: draft
 last_updated: 2026-05-12
 ---
-# AGV — Vue d'ensemble
+# AGV - Vue d'ensemble
 > **Périmètre** : intégration Still iGo, stations et routes AGV,
 > jobs AGV spécifiques, troubleshooting.
@@ -1,5 +1,5 @@
 ---
-title: "Stations et routes AGV — Topologie iGO"
+title: "Stations et routes AGV - Topologie iGO"
 tags: [agv, still, igo, stations, routes, topologie, location, group]
 status: draft
 standard_ref: concepts/stations.md
@@ -10,7 +10,7 @@ last_updated: 2026-05-12
 author: Arthur
 ---
-# Stations et routes AGV — Topologie iGO
+# Stations et routes AGV - Topologie iGO
 > **Résumé** : correspondance entre les stations/routes EasyWMS et les
 > concepts Location/Group/Vehicle d'iGO. Configuration dans MyMA vs
@@ -25,14 +25,14 @@ author: Arthur
 Chez Limagrain, les AGV Still (EXV CB iGo) circulent entre les images
 de quai, les PIE, les postes de picking (PK) et les zones de stockage.
 La topologie physique (positions, trajets) est gérée **entièrement
-dans iGO** (MyMA / iGO designer) — EasyWMS ne connaît que les points
+dans iGO** (MyMA / iGO designer) - EasyWMS ne connaît que les points
 de départ et d'arrivée.
 ## Mapping topologique EasyWMS ↔ iGO
 | Concept EasyWMS | Concept iGO | Notes |
 |----------------|-------------|-------|
-| Station (type 65 — AGV) | **Vehicle** | Le véhicule physique lui-même |
+| Station (type 65 - AGV) | **Vehicle** | Le véhicule physique lui-même |
 | Location (`IRealLocation`) | **Location** | Point physique avec `possibleActions` |
 | Route entre stations | _(pas d'équivalent)_ | iGO gère le routage en interne |
 | WorkingZone | **Group** | Ensemble de Locations (décision tardive) |
@@ -61,14 +61,14 @@ Restent dans EasyS :
 - Création du warehouse station lié à l'AGV equipment group
 - Déclaration des AGV dans le groupe
 - Routes EasyWMS **entre stations WMS** (type "External" pour les
-  segments AGV — le manager d'exécution est "External")
+  segments AGV - le manager d'exécution est "External")
 > ⚠️ Pas d'équivalent aux "Routes between stations" de type Galileo
 > pour iGO. Les routes EasyS servent uniquement à valider l'existence
-> d'un chemin logique côté WMS avant de créer la tâche AGV — la
+> d'un chemin logique côté WMS avant de créer la tâche AGV - la
 > trajectoire physique est résolue par iGO.
-## Décision tardive — utilisation des Groups
+## Décision tardive - utilisation des Groups
 Cas d'utilisation chez Limagrain :
@@ -87,7 +87,7 @@ Cas d'utilisation chez Limagrain :
 |---------|-----|
 | `LocationLockType` avec flag "For AGV" | `Location.isEnabled = false` |
 | Lock typé (par erreur extraction, putaway, etc.) | Un seul flag binaire côté iGO |
-| Lock posé automatiquement par les workflows | À gérer côté WMS uniquement — iGO ne pose pas de lock |
+| Lock posé automatiquement par les workflows | À gérer côté WMS uniquement - iGO ne pose pas de lock |
 > ⚠️ iGO n'a pas de granularité dans les types de verrous. La
 > traduction entre les codes erreur EasyWMS (1001-2700) et le flag
@@ -104,12 +104,12 @@ ces champs EasyWMS (obligatoires en FIFO compact) sont portés par la
 Location côté iGO, pas par le transport.
 ⚠️ **Modification des Locations via API** : l'API iGO n'expose que
-`GET /api/locations` — pas de `POST`/`PUT`. Toute modification de
+`GET /api/locations` - pas de `POST`/`PUT`. Toute modification de
 topologie passe par MyMA manuellement.
 ## Questions ouvertes
- [ ] Création/modification de Location via API iGO — actuellement
+- ❓ Création/modification de Location via API iGO - actuellement
  en lecture seule, à clarifier avec STILL (@Arthur)
 ## Historique des modifications
@@ -123,5 +123,5 @@ topologie passe par MyMA manuellement.
 | Source | Type | Date |
 |--------|------|------|
 | CR technique iGO STILL v1 | CR technique | 2026-04-28 |
-| [Stations & Routes standard](../../concepts/stations.md) | Wiki standard | — |
+| [Stations & Routes standard](../../concepts/stations.md) | Wiki standard | - |
-| [AGV module standard](../../modules/agv.md) | Wiki standard | — |
+| [AGV module standard](../../modules/agv.md) | Wiki standard | - |
@@ -1,5 +1,5 @@
 ---
-title: "Troubleshooting AGV — Contraintes terrain"
+title: "Troubleshooting AGV - Contraintes terrain"
 tags: [agv, still, igo, terrain, convoyeurs, troubleshooting]
 status: draft
 standard_ref: operations/troubleshooting.md
@@ -119,11 +119,11 @@ nécessaire pour manoeuvrer.
 ## Questions ouvertes
- [ ] Confirmation par Still de l'espace max palette/convoyeur ~45 mm
+- ❓ Confirmation par Still de l'espace max palette/convoyeur ~45 mm
  (@Théo)
- [ ] Mesure réelle SAS7 à effectuer lors de l'implantation
+- ❓ Mesure réelle SAS7 à effectuer lors de l'implantation
  (@Abdennaim)
- [ ] Solution Still pour augmenter la distance mât/bord palette :
+- ❓ Solution Still pour augmenter la distance mât/bord palette :
  quel impact sur les specs AGV (capacité, hauteur de levée) ?
  (@Cyprien Allard / Still)
@@ -1,16 +1,16 @@
 ---
-title: "Mini Job — Images de quai vers poste de travail (PK)"
+title: "Mini Job - Images de quai vers poste de travail (PK)"
 tags: [agv, job, réception, pk, mini-job, big-bag]
 status: draft
 standard_ref: architecture/galileo-integration.md
 jira_refs: [LIM-74, LIM-70, LIM-60]
 confluence_refs: []
-sources: ["LIM-74 LOT1.3 [AGV][JOB] MINI JOB - images de quai poste de travail (PK).md"]
+sources: ["LIM-74 LOT1.3 [AGV][JOB] MINI JOB - images de quai poste de travail (PK).md", "Jira LIM-74 (revue de code validée 2026-04-07, relecture 2026-07-17)"]
-last_updated: 2026-05-12
+last_updated: 2026-07-17
 author: Arthur
 ---
-# Mini Job — Images de quai vers poste de travail (PK)
+# Mini Job - Images de quai vers poste de travail (PK)
 > **Résumé** : sous-workflow du [Mega Job](../03-picking/job-assignation-pk.md)
 > qui orchestre l'envoi des palettes depuis les images de quai vers les
@@ -38,7 +38,7 @@ pas dans ce sous-workflow.
 > Ce job ne concerne **pas** les réceptions de type Production. Celles-ci
 > sont envoyées directement vers le PIE de l'ASRS via des supports
-> virtuels — voir
+> virtuels - voir
 > [Job réception production](job-reception-production.md) (LIM-71).
 ### Process complet de réception
@@ -47,12 +47,12 @@ pas dans ce sous-workflow.
 |---|-------|--------|
 | 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-74 (cette page)** |
-| 3 | Traitement au poste de travail | [LIM-67](https://easywmsfrance.atlassian.net/browse/LIM-67) / [LIM-72](https://easywmsfrance.atlassian.net/browse/LIM-72) |
+| 3 | Traitement au poste de travail | [LIM-67](https://easywmsfrance.atlassian.net/browse/LIM-67) / [LIM-72](https://easywmsfrance.atlassian.net/browse/LIM-72) (V1 annulé → [LIM-93](https://easywmsfrance.atlassian.net/browse/LIM-93)) |
-| 4 | Déplacement AGV → table d'entrée (+ filmage) | — |
+| 4 | Déplacement AGV → table d'entrée (+ filmage) | - |
 | 5 | Passage PIE | [LIM-66](https://easywmsfrance.atlassian.net/browse/LIM-66) |
-| 6 | Stockage ou rejet | — |
+| 6 | Stockage ou rejet | - |
 | 7 | Clôture de la réception | [LIM-73](https://easywmsfrance.atlassian.net/browse/LIM-73) |
-| 8 | Libération quai / image de quai | — |
+| 8 | Libération quai / image de quai | - |
 ## Logique principale
@@ -123,10 +123,22 @@ module AGV/GNA envoie les tâches à la flotte iGo.
 |-----------|-------------|-------------------|
 | PK_BIGBAG | Liste des PK compatibles big-bag (séparés par `;`) | _(vide)_ |
 ## [CUSTOM] Éléments techniques (revue de code validée 2026-04-07)
 Implémentation définitive (commit `24067c85fc`, statut préprod) :
 | Élément | Type | Rôle |
 |---------|------|------|
 | `CST_Reception_BestPendingAssignment_ForPK` | Query | Sélection de la réception à assigner (supports fictifs 8000*, CstAtt06 vide, filtre big-bag, tri big-bag puis FIFO) |
 | `CST_PickingStationAssignment_Reception_PR` | WF | Génère les tâches pour la réception sélectionnée et assigne les conteneurs au PK. Appelé par le Mega Job [LIM-70](../03-picking/job-assignation-pk.md) |
 | `CST_PickingStationAssignment_Job` | WF (Mega Job) | Modifié : gestion du paramètre `PK_BIGBAG` + appel de `CST_PickingStationAssignment_Reception_PR` |
 | `ContainerVList` | Vue | Ajout de la colonne CustomAttribute6 (PK assigné) |
 | `CST_Container_CustomAttribute6` | Ressource | FR « PK Assigné » / EN « Assigned PK » |
 ## Points d'attention
 ⚠️ Un PK compatible big-bag (`PK_BIGBAG`) peut aussi traiter des
-réceptions sans big-bag — le filtre ne s'applique que dans le sens
+réceptions sans big-bag - le filtre ne s'applique que dans le sens
 "big-bag vers PK non compatible".
 ⚠️ Toutes les palettes d'une même réception vont vers le **même PK** en
@@ -148,11 +160,12 @@ _(aucune question ouverte identifiée dans cette tâche)_
 | Date | Auteur | Modification |
 |------|--------|--------------|
 | 2026-05-12 | Arthur | Création initiale depuis LIM-74 |
 | 2026-07-17 | Arthur | Relecture revue de code LIM-74 (validée 07/04, préprod) : section « Éléments techniques » (query `CST_Reception_BestPendingAssignment_ForPK`, WF `CST_PickingStationAssignment_Reception_PR`, Mega Job modifié, vue ContainerVList, ressource `CST_Container_CustomAttribute6`) |
 ## Références
 | Source | Type | Date |
 |--------|------|------|
-| [LIM-74](https://easywmsfrance.atlassian.net/browse/LIM-74) | Ticket Jira | 2026 |
+| [LIM-74](https://easywmsfrance.atlassian.net/browse/LIM-74) | Ticket Jira (Mini Job réception PK) - revue de code validée, préprod | 2026-04-07 |
 | [LIM-70](https://easywmsfrance.atlassian.net/browse/LIM-70) | Ticket Jira (Mega Job) | 2026 |
 | [LIM-60](https://easywmsfrance.atlassian.net/browse/LIM-60) | Ticket Jira (sous-emplacement auto) | 2026 |
@@ -1,21 +1,21 @@
 ---
-title: "Job AGV — Réception production vers ASRS"
+title: "Job AGV - Réception production vers ASRS"
 tags: [agv, job, reception, production, asrs, pie]
 status: draft
 standard_ref: architecture/galileo-integration.md
 jira_refs: [LIM-71, LIM-64, LIM-66]
 confluence_refs: []
 sources: ["LIM-71 LOT1.2 RECEPTION PRODUCTION AGV Job de création des tâches images de quai  ASRS.md"]
-last_updated: 2026-05-12
+last_updated: 2026-07-17
 author: Arthur
 ---
-# Job AGV — Réception production vers ASRS
+# Job AGV - Réception production vers ASRS
 > **Résumé** : job périodique (30 s) qui crée les tâches de déplacement
-> AGV depuis les images de quai vers le buffer d'entrée production
+> AGV depuis les images de quai vers le PIE de l'ASRS, via les stratégies
-> (alimentant le PIE de l'ASRS). Concerne uniquement les réceptions
+> de rangement. Concerne les réceptions production (CstAtt04 = "ASN") et
-> production (CstAtt04 = "ASN").
+> les piles de palettes vides (code `PAL`).
 > **Standard EasyWMS** : → voir
 > [Galileo Integration](../../architecture/galileo-integration.md),
@@ -25,6 +25,12 @@ author: Arthur
 ## Contexte projet
 > **Statut (LIM-71)** : en préprod (test client). Revues de code validées
 > le 27/03/2026, le 28/04/2026 (ajout piles de palettes) et le 01/07/2026
 > (ajout job de régénération). Deux tentatives ont été **annulées en cours
 > de dev** : le marquage `CstAtt06` (abandonné, cf. plus bas) et la condition
 > `CstAtt12` sur les conteneurs production (non requise : pas d'étiquette).
 Dans le flux de réception production, les palettes arrivent de la
 production (ou de l'ancien magasin) et vont **directement dans l'ASRS**
 sans passer par un poste de travail. Elles sont déchargées par un
@@ -72,39 +78,82 @@ sequenceDiagram
 ## Logique d'éligibilité
-Le job parcourt tous les supports positionnés sur des images de quai.
+Le job parcourt tous les conteneurs positionnés sur des **stages d'image de
-Un support est éligible si **toutes** les conditions suivantes sont
+quai** (`LocationType.DockStage`). Un conteneur est éligible si **toutes**
-réunies :
+les conditions suivantes sont réunies :
 | Condition | Détail |
 |-----------|--------|
-| Séquence 8000* | Support fictif créé lors de la déclaration image de quai ([LIM-64](https://easywmsfrance.atlassian.net/browse/LIM-64)) |
+| Emplacement = DockStage | Conteneur posé sur un stage d'image de quai |
 | Code `8000*` **ou** `PAL*` | Support fictif production (séq. 8000, [LIM-64](https://easywmsfrance.atlassian.net/browse/LIM-64)) **ou** pile de palettes vides (`PAL`) |
 | CstAtt04 = "ASN" | Support de type production |
-| CstAtt06 vide | Pas encore traité par ce job |
+| Aucune tâche active | `!c.Tasks.Any()` - aucun ordre de mouvement rattaché au conteneur |
 | Aucune tâche active | Statuts actifs = Bloqué, Créé, En attente, En attente d'annulation, En cours. Statuts historiques (ignorés) = Annulé, Terminé |
-La double vérification CstAtt06 + absence de tâche active est une
+> **Reversal marquage CstAtt06** : la logique initiale prévoyait de marquer
-**sécurité anti-doublon**.
+> `CstAtt06` = destination pour éviter les doublons. Décidé en interne
 > (19/03/2026) de **ne pas l'implémenter** : l'absence de tâche active suffit
 > comme anti-doublon, et ne pas marquer `CstAtt06` permet de **regénérer** une
 > tâche de rangement au prochain cycle si la précédente a été annulée. Ce job
 > **n'utilise donc pas** `CstAtt06`.
 >
 > **Reversal condition CstAtt12** : une condition `CstAtt12 = true` (étiquette
 > posée) a été ajoutée puis **retirée** pour la production et les piles de
 > palettes - ces conteneurs n'ont pas d'étiquette. `CstAtt12` ne conditionne
 > que les réceptions **fournisseur** vers les PK.
-## Traitement d'un support éligible
+## Traitement d'un conteneur éligible
-### Marquage
+Pour chaque conteneur récupéré, le job effectue une **recherche
-
+d'emplacement** basée sur les **stratégies de rangement** configurées, puis
-Le job positionne `CstAtt06` = valeur du paramètre
+génère la tâche de rangement si un emplacement est trouvé.
 `DESTINATION_PRODUCTION` (ex : "ENTREE_PRODUCTION").
 ### Création de la tâche
 | Champ | Valeur |
 |-------|--------|
-| Origine | Sous-emplacement de l'image de quai |
+| Origine | Stage de l'image de quai |
-| Destination | Déterminée par la **stratégie de rangement** configurée (MU d'entrée Est ou Ouest, Est par défaut) |
+| Destination | Déterminée par la **stratégie de rangement** (PIE_01 / PIE_02, entrée Est ou Ouest, **Est par défaut**) |
 | Statut initial | "En attente" |
 Les stratégies sont importées et configurées via la vue standard
 `LocationPutawayStrategyVList`, modifiée pour autoriser les **stages** comme
 station d'origine (type Stage, ou un stage précis). Les stratégies vont des
 stages vers PIE_01 / PIE_02 en « fin de séquence ».
 Le passage "en attente" → "créé" est géré par le WMS standard
 (`Task_GenerateMovementJob_PR`). Le module AGV / GNA écoute ce
 changement et envoie les tâches à la flotte iGo.
 ### Éléments AD (LIM-71)
 | Élément AD | Type | Rôle |
 |------------|------|------|
 | `CST_StoreProductionContainer_Job` | Workflow + Job (30 s) | Récupère les conteneurs via la query, cherche un emplacement pour chacun et génère la tâche de rangement si trouvé |
 | `CST_AvailableProductionContainers` | Query | Récupère les conteneurs candidats : sur DockStage, `CstAtt04 = "ASN"`, code `8000*` ou `PAL*`, sans tâche active |
 | `LocationPutawayStrategyVList` | Vue | Ajout des stages dans la liste des stations d'origine (sélection type Stage ou stage précis) |
 | `Galileo_PIEEventHandler_PR` | Workflow | Ignore l'erreur de lecture d'étiquette au PIE quand il s'agit d'une pile de palettes |
 ## Piles de palettes vides
 Le job gère aussi le rangement des **piles de palettes vides** (conteneurs
 dont le code commence par `PAL`). Elles suivent le même mécanisme
 (query + stratégie de rangement + tâche AGV). Au PIE, l'erreur de lecture
 d'étiquette est ignorée pour ces piles (`Galileo_PIEEventHandler_PR`).
 ## Job de régénération des tâches réception → PK
 En complément (ajouté sous LIM-71, revue de code OK 01/07/2026), un job
 distinct **régénère** les tâches manquantes pour les conteneurs de réception
 **fournisseur** qui ont un PK assigné mais aucune tâche.
 | Élément AD | Type | Rôle |
 |------------|------|------|
 | `CST_Reception_RegenerateTask_Job` | Workflow + Job (15 s) | Crée une tâche pour les conteneurs de réception (`CstAtt08`) avec un PK assigné (`CstAtt06`) posés sur une image de quai sans tâche. Vérifie que la station de picking est trouvée |
 | `CST_ReceptionContainers_WithoutTasksToPK` | Query | Récupère ces conteneurs de réception sans tâche vers leur PK |
 > Ce job de régénération relève du flux **réception fournisseur → PK**
 > (cf. [Réception fournisseur](../01-inbound/reception-fournisseur.md),
 > LIM-67 / LIM-74) et non de la réception production. Il confirme l'usage de
 > `CstAtt06` = code du PK assigné côté réception fournisseur.
 ## Redirection si PIE saturé
 Gérée en **standard** par le système de routes et distances configuré
@@ -124,37 +173,39 @@ destination ; c'est le WMS qui reroute si nécessaire.
 | Paramètre | Description | Valeur par défaut |
 |-----------|-------------|-------------------|
-| DESTINATION_PRODUCTION | Code du buffer d'entrée production (destination des tâches AGV) | ENTREE_PRODUCTION |
+| ~~DESTINATION_PRODUCTION~~ | ~~Code du buffer d'entrée production~~ - **obsolète** : la destination est désormais déterminée par les stratégies de rangement, plus par ce paramètre | ~~ENTREE_PRODUCTION~~ |
 ## Points d'attention
 - Un support non ASN (fournisseur, intersite, retour) sur une image
-  de quai est **ignoré** — il est géré par le
+  de quai est **ignoré** - il est géré par le
  [Mega Job](../03-picking/job-assignation-pk.md) (LIM-70)
- Le marquage CstAtt06 a été simplifié en cours de développement
+- Ce job **n'utilise pas** `CstAtt06` (marquage abandonné) : l'anti-doublon
-  (certains cas de tests marqués "Plus utilisé") — la vérification
+  repose uniquement sur l'absence de tâche active, ce qui permet la
-  par absence de tâche active reste la sécurité principale
+  régénération après annulation
- La stratégie de rangement détermine l'entrée Est/Ouest ; le
+- La stratégie de rangement détermine l'entrée Est/Ouest (Est par défaut) ;
-  paramètre DESTINATION_PRODUCTION n'est plus directement utilisé
+  le paramètre `DESTINATION_PRODUCTION` est **obsolète**
-  comme destination de tâche
+- Les piles de palettes vides (`PAL*`) sont traitées par le même job ;
  l'erreur de lecture d'étiquette au PIE est ignorée pour ces piles
 ## Questions ouvertes
- [ ] Redirection multi-poumons / multi-PIE : config EasyS prête ?
+- ❓ Redirection multi-poumons / multi-PIE : config EasyS prête ?
  (@Nicolas)
- [ ] CstAtt06 encore nécessaire comme marqueur si la vérification
+- ~~CstAtt06 encore nécessaire comme marqueur ?~~ → **Résolu (LIM-71)** :
-  par tâche active suffit ? (@Fabien)
+  marquage CstAtt06 abandonné, l'absence de tâche active suffit.
 ## Historique des modifications
 | Date | Auteur | Modification |
 |------|--------|--------------|
 | 2026-05-12 | Arthur | Création initiale depuis LIM-71 |
 | 2026-07-17 | Arthur | Relecture 18 commentaires : abandon marquage CstAtt06 (anti-doublon = tâche active), destination via stratégies de rangement (DESTINATION_PRODUCTION obsolète), gestion piles de palettes (PAL), reversal CstAtt12 (non requis production), éléments AD (CST_StoreProductionContainer_Job, CST_AvailableProductionContainers, LocationPutawayStrategyVList, Galileo_PIEEventHandler_PR), job régénération CST_Reception_RegenerateTask_Job, statut préprod + 3 revues de code |
 ## Références
 | Source | Type | Date |
 |--------|------|------|
-| [LIM-71](https://easywmsfrance.atlassian.net/browse/LIM-71) | Ticket Jira | 2026 |
+| [LIM-71](https://easywmsfrance.atlassian.net/browse/LIM-71) | Ticket Jira (18 commentaires) | 2026-03 → 2026-07 |
 | [LIM-64](https://easywmsfrance.atlassian.net/browse/LIM-64) | Ticket Jira (déclaration image quai) | 2026 |
-| [LIM-66](https://easywmsfrance.atlassian.net/browse/LIM-66) | Ticket Jira (passage PIE) | 2026 |
+| [LIM-66](https://easywmsfrance.atlassian.net/browse/LIM-66) | Ticket Jira (passage PIE) | 2026 |
@@ -1,16 +1,16 @@
 ---
-title: "Intégration Still iGo — API PACS et architecture"
+title: "Intégration Still iGo - API PACS et architecture"
 tags: [agv, still, igo, pacs, api, integration, architecture]
 status: draft
 standard_ref: modules/agv.md
-jira_refs: []
+jira_refs: [LIM-103, LIM-104]
 confluence_refs: []
-sources: ["CR technique - iGO STILL - fonctionnement et flux API + correspondance avec le module AGV EasyWMS Opus 4.7 v1.md"]
+sources: ["CR technique - iGO STILL - fonctionnement et flux API + correspondance avec le module AGV EasyWMS Opus 4.7 v1.md", "Jira LIM-103 (lecture directe 2026-07-20)", "Jira LIM-104 (lecture directe 2026-07-20)"]
-last_updated: 2026-05-12
+last_updated: 2026-07-20
 author: Arthur
 ---
-# Intégration Still iGo — API PACS et architecture
+# Intégration Still iGo - API PACS et architecture
 > **Résumé** : documentation complète de l'intégration du fleet manager
 > **iGO easy** (STILL / KION Group) avec EasyWMS chez Limagrain.
@@ -18,20 +18,20 @@ author: Arthur
 > avec le module AGV standard, l'architecture cible à 4 composants et
 > les réponses FAQ STILL contractuelles.
-> **Standard EasyWMS** : → voir [AGV — Automated Guided Vehicles](../../modules/agv.md)
+> **Standard EasyWMS** : → voir [AGV - Automated Guided Vehicles](../../modules/agv.md)
 > Le standard communique par **tables d'échange DB** (EAG/AGE/AGS).
 > Chez Limagrain, iGO easy remplace le protocole historique par une
-> **API REST HTTPS** — un middleware (pool IIS C#) assure la traduction.
+> **API REST HTTPS** - un middleware (pool IIS C#) assure la traduction.
 ## Contexte projet
 Limagrain utilise des AGV **Still EXV CB iGo** (gerbeurs électriques
 automatisés) pour les transports internes entre images de quai, PIE,
 postes de picking et zones de stockage. Le fleet manager est
-**iGO easy** (variante simplifiée de PACS — Productized Automated
+**iGO easy** (variante simplifiée de PACS - Productized Automated
 Concept Solutions), motorisé par le moteur interne **E'tricc**.
-La communication est **100 % REST HTTPS** (port 7002, TLS 1.2) — pas
+La communication est **100 % REST HTTPS** (port 7002, TLS 1.2) - pas
 de PLC ni de tables d'échange SQL directes entre WMS et iGO. Le modèle
 est **pull + push** : le WMS pousse les ordres (`POST /transports`),
 iGO pousse les changements d'état via webhook (callback POST vers une
@@ -63,14 +63,14 @@ flowchart LR
 Concepts clés :
 - Pas de notion de routes/segments côté WMS : iGO ne demande qu'une
-  `sourceLocation` et une `destinationLocation` — la trajectoire
+  `sourceLocation` et une `destinationLocation` - la trajectoire
  physique est gérée par iGO en interne.
 - **Décision tardive** (Group / decision point) : si la destination
  exacte est inconnue à la création, on donne un `destinationGroupId`.
  iGO place le transport en `RequestDestination` et interroge le WMS
  quand l'AGV arrive au point de décision.
- **Load** = container EasyWMS — passé directement dans le payload de
+- **Load** = container EasyWMS - passé directement dans le payload de
-  création du transport (pas de `POST /api/loads` préalable — FAQ #5).
+  création du transport (pas de `POST /api/loads` préalable - FAQ #5).
 ## Stack technique iGO (MyMA)
@@ -92,9 +92,9 @@ Concepts clés :
 | API Host (HTTPS REST) | **7002** |
 | Postgres | 5432 |
-## Véhicule — Still EXV CB iGo
+## Véhicule - Still EXV CB iGo
-Gerbeur électrique automatisé (EXV = Elektro-Vertikal) — se déplace
+Gerbeur électrique automatisé (EXV = Elektro-Vertikal) - se déplace
 sur ses propres roues et lève la charge avec le mât. Pas de couloir
 mécanique ni de canal compact.
@@ -118,7 +118,7 @@ L'API PACS 2.3 expose **8 ressources** :
 | **LoadType** | `ContainerType` | Catalogue de types de charge |
 | **Location** | `Location` (`IRealLocation`) | Point physique du warehouse |
 | **Group** | `WorkingZone` | Ensemble de locations (décision tardive) |
-| **System** | — | État global + abonnements |
+| **System** | - | État global + abonnements |
 ### Champs clés du Transport
@@ -130,7 +130,7 @@ L'API PACS 2.3 expose **8 ressources** :
 | `destinationLocationId` / `destinationGroupId` | string | `UnloadLocation` |
 | `load` | Load | Container (`PalletId`, type, dimensions) |
 | `priority` | int 0-10 | Priority 0-4 (conversion inversée) |
-| `suspended` | bool | (pas d'équivalent — `false` par défaut) |
+| `suspended` | bool | (pas d'équivalent - `false` par défaut) |
 | `customMetaData` | dict | `HasTopper`, `PalletType`, etc. |
 | `status` | enum | `AgvStatus` (mapping § ci-dessous) |
@@ -183,7 +183,7 @@ Tous sur `https://[IP]:7002/api/...` avec header `X-API-Key`.
 | GET | `/api/system` | Status global + subscriptions |
 | GET | `/api/groups` / `/{id}` | Lecture des groupes |
 | GET | `/api/loads` / `/{id}` | Lecture des loads |
-| POST | `/api/loads` | Créer une load (non recommandé — FAQ #5) |
+| POST | `/api/loads` | Créer une load (non recommandé - FAQ #5) |
 | GET | `/api/locations` / `/{id}` | Lecture des locations |
 | GET | `/api/load-types` | Catalogue des types |
@@ -222,7 +222,7 @@ flowchart TD
 États terminaux : **Finished**, **Cancelled**, **Aborted**.
-> ⚠️ Le statut `New` est un état interne instantané d'iGO — il
+> ⚠️ Le statut `New` est un état interne instantané d'iGO - il
 > n'apparaît jamais dans les callbacks. Le premier état observable est
 > `Requested` (FAQ #4).
@@ -230,17 +230,17 @@ flowchart TD
 | iGO Transport.status | Phase AGV EasyWMS | AgvStatus | Notes |
 |---------------------|-------------------|-----------|-------|
-| Requested | — | (après POST) | Premier état observable |
+| Requested | - | (après POST) | Premier état observable |
 | Pending | 100 (Order accepted) | `Sent` | En file d'attente iGO |
 | Assigned | 103 (Vehicle assigned) | (Sent) | ⚠️ Pas de Vehicle.id dans le payload (FAQ #1) |
 | RequestSource | 104 (Load permission) | `PendingToBeLoad` | Uniquement en mode Group |
-| Retrieving | — | (Sent) | AGV en route / chargement |
+| Retrieving | - | (Sent) | AGV en route / chargement |
 | Retrieved | 106 (Load confirmed) | (Sent) | **Vehicle.id disponible ici** (FAQ #1) |
 | RequestDestination | 108 (Unload permission) | `PendingToBeUnload` | Uniquement en mode Group |
-| Storing | — | — | AGV en dépose |
+| Storing | - | - | AGV en dépose |
 | Stored / Finished | 110 (Unload confirmed) | (purge) | Transport terminé |
 | Cancelled | 255 | (Cancelled) | Annulé |
-| Aborted | 255 | (Cancelled) | Erreur irrécupérable — aucun code d'erreur dans le payload (FAQ #2) |
+| Aborted | 255 | (Cancelled) | Erreur irrécupérable - aucun code d'erreur dans le payload (FAQ #2) |
 ### Différence sémantique majeure : CanPick / CanDrop
@@ -258,13 +258,13 @@ l'usage de Groups** (même mono-location) là où EasyWMS aurait
 | EasyWMS | iGO | Suggestion |
 |---------|-----|------------|
-| 0 — Urgent | 10 — Highest | mapping direct |
+| 0 - Urgent | 10 - Highest | mapping direct |
-| 1 — High | 8 | |
+| 1 - High | 8 | |
-| 2 — Normal | 5 | |
+| 2 - Normal | 5 | |
-| 3 — Low | 3 | |
+| 3 - Low | 3 | |
-| 4 — VeryLow | 1 | |
+| 4 - VeryLow | 1 | |
-## Flux nominal — création et exécution
+## Flux nominal - création et exécution
 ```mermaid
 sequenceDiagram
@@ -322,14 +322,14 @@ intervenir manuellement.
 ### Authentification
-**`X-API-Key`** (confirmé par STILL — FAQ #8). Le header
+**`X-API-Key`** (confirmé par STILL - FAQ #8). Le header
 `Authorization: Bearer` mentionné dans certaines parties de la doc
 PACS est obsolète. La clé est fixe, fournie par le PM STILL, stockée
 chiffrée dans la config du middleware.
 ### TLS
-HTTPS avec TLS 1.2. Certificats **auto-signés** côté iGO — le WMS
+HTTPS avec TLS 1.2. Certificats **auto-signés** côté iGO - le WMS
 doit les truster explicitement (import dans le keystore).
 ### Modèle d'abonnement
@@ -372,7 +372,7 @@ déduplication = `transport.id + status` (FAQ #9).
 | Auth load | EAG `Update` (CanPick=true) | `POST /final-source` |
 | Auth unload | EAG `Update` (CanDrop=true) | `POST /final-destination` |
-## Architecture cible — Pattern à 4 composants
+## Architecture cible - Pattern à 4 composants
 ### Principe directeur
@@ -401,7 +401,7 @@ flowchart LR
      AGS[(AGV_AGS)]
    end
-    subgraph Pool["Pool IIS C# .NET 8 — À DÉVELOPPER"]
+    subgraph Pool["Pool IIS C# .NET 8 - À DÉVELOPPER"]
      Pump[Pompe sortante<br/>poll OUTPUTQUEUE → API iGO]
      Hook[Webhook receiver<br/>callbacks iGO → tables]
    end
@@ -420,7 +420,7 @@ flowchart LR
    Hook --> IQ & AGE & AGS
 ```
-### Composants existants — RIEN à modifier
+### Composants existants - RIEN à modifier
 | Composant | Rôle | Statut |
 |-----------|------|--------|
@@ -429,7 +429,7 @@ flowchart LR
 | Tables AGV_* (5) | Base intermédiaire | ✅ Existantes |
 | Vues SmartUI AGV | Monitoring opérateur | ✅ Existantes |
-### Middleware pool IIS — seul livrable nouveau
+### Middleware pool IIS - seul livrable nouveau
 | Aspect | Description |
 |--------|-------------|
@@ -452,18 +452,18 @@ Controller ASP.NET Core exposant deux endpoints HTTPS. À réception :
 insert dans `AGV_INPUTQUEUE` → insert dans `AGV_AGE` ou `AGV_AGS`
 avec le mapping Status → EventType/Flags (cf. tableau ci-dessous).
 Horodatage `DateTime.UtcNow` à la réception (iGO ne fournit pas de
-timestamp — FAQ #3).
+timestamp - FAQ #3).
 ### Mapping Status iGO → (EventType, Flags) AGE
 | iGO Transport.status | EventType | Flags | Notes |
 |---------------------|-----------|-------|-------|
 | Pending | 100 | 0 | Order accepted |
-| Assigned | 103 | 0 | Vehicle assigned — `StationNumber=null` (FAQ #1) |
+| Assigned | 103 | 0 | Vehicle assigned - `StationNumber=null` (FAQ #1) |
-| Retrieved | 106 | 0 | Load confirmed — `Vehicle.id` disponible ici |
+| Retrieved | 106 | 0 | Load confirmed - `Vehicle.id` disponible ici |
 | Stored / Finished | 110 | 0 | Unload confirmed |
 | Cancelled | 255 | 0 | Annulé |
-| Aborted | — | 2003/2004 | À enrichir via `GET /api/vehicles/{id}` (FAQ #2) |
+| Aborted | - | 2003/2004 | À enrichir via `GET /api/vehicles/{id}` (FAQ #2) |
 ### Pattern de boot du middleware
@@ -471,7 +471,7 @@ timestamp — FAQ #3).
 1. Vérifier la base intermédiaire accessible
 2. Vérifier l'API iGO : `GET /api/system`
-3. Vérifier les subscriptions actives — (re)créer si absentes
+3. Vérifier les subscriptions actives - (re)créer si absentes
 4. Réconcilier les transports : `GET /api/transports` vs
   `AGV_OUTPUTQUEUE` non acquittées → générer les lignes AGE manquantes
 5. Démarrer le polling sortant
@@ -487,6 +487,46 @@ le status iGO courant :
  fallback (attendre Finished + tâche retour, ou RFT)
 - **Cancelled / Aborted / Finished** → no-op (déjà terminal)
 ### Refus WMS de l'annulation quand le support est sur un AGV (LIM-104)
 > **Statut** : préprod ; revue de code validée le 23/06/2026 (Vincent Charvet).
 **Problème** (découvert aux tests STILL) : si on annule / supprime une Task
 AGV alors que le support est **déjà pris par l'AGV** (transport iGO
 `>= Retrieved`), iGO **refuse** l'annulation et termine physiquement la
 mission - mais le WMS a déjà **supprimé la Task** au moment de la demande.
 `ProcessEvents_PR` s'arrête alors sur sa garde `CST Get Task` (« CST Task
 exists » = false) pour toutes les AGE suivantes :
 - l'AGE `255/1009` ne déclenche jamais `ProcessError1009` → **notification
  opérateur du refus perdue** ;
 - l'AGE `110` (Unload confirmed) ne déclenche jamais `ContainerMove` →
  **support figé sur l'AGV**.
 **Solution** : souscription **preview** sur la commande de suppression /
 annulation de Task. Avant exécution :
 1. récupérer le support (container) associé à la Task ;
 2. vérifier s'il est sur un AGV - critère retenu `Container.StationType ==
   Agv` (équivalent métier de « palette physiquement sur l'AGV » = iGO
   `>= Retrieved` ; repli possible : `LocationCode` commençant par `AGV_`) ;
 3. si **sur AGV** → **refuser** la commande (exception) avec message
   opérateur explicite. La Task reste vivante, l'AGV termine sa mission, le
   support est livré à destination ;
 4. sinon (support encore à la source ou déjà déposé) → laisser la commande
   s'exécuter normalement.
 | Élément AD | Type | Rôle |
 |-----------|------|------|
 | `CST_TaskCancel_CheckAgv` | Subscription | Appelle le WF à l'**annulation** d'une tâche |
 | `CST_TaskDelete_CheckAgv` | Subscription | Appelle le WF à la **suppression** d'une tâche |
 | `CST_CancelTask_CheckForAgv` | Workflow | Récupère la tâche annulée / supprimée ; si le conteneur est sur un emplacement AGV, lève une erreur (numéro de tâche + code conteneur) |
 | `CST_CancelTask_NotPossible_2` | Ressource | FR « Impossible de supprimer la tâche {0} car le conteneur {1} est sur un AGV » / EN « Cannot delete task {0} because container {1} is on AGV » |
 Cas de test : (1) annulation **après** pickup (`>= Retrieved`) → refusée,
 support livré, Task `Finished` ; (2) annulation **avant** pickup
 (`< Retrieved`) → acceptée, EAG `D`, middleware POST cancel iGO `204`.
 ### Comparaison avec les Gateways historiques
 | Aspect | EasyWMSGateway2015 (Galileo) | GatewayRocla2015 | Pool IIS iGO |
@@ -501,24 +541,116 @@ le status iGO courant :
 > (ancienne architecture monolithique). Développement **from scratch**
 > sur ASP.NET Core .NET 8 recommandé.
-## Workflows EasyWMS — impact iGO
+## Workflows EasyWMS - impact iGO
 Avec le pattern Gateway iGO + tables AGV_*, **aucun workflow EasyWMS
 ni la Gateway AGV Mecalux n'a besoin d'être modifié**. La spécificité
 iGO est entièrement encapsulée dans le middleware.
 > ⚠️ **Réserve (LIM-103, préprod)** : ce tableau reflète l'**hypothèse de
 > conception**. À l'implémentation, plusieurs **bugs du module AGV standard
 > Mecalux** ont dû être corrigés (dispatch d'events cassé par la
 > transformation Gateway `phase + 100`, attributs `canPick`/`canDrop`
 > jamais assignés, events 106/110 non gérés, refus de mission iGo). Détail :
 > [Corrections des bugs du module AGV standard (LIM-103)](#corrections-des-bugs-du-module-agv-standard-lim-103).
 | Workflow | Comportement avec Gateway iGO |
 |----------|-------------------------------|
-| `MovementCreatedEventHandler_PR` | ✅ Inchangé — déclencheur |
+| `MovementCreatedEventHandler_PR` | ✅ Inchangé - déclencheur |
 | `AgvTask_CreateTaskFromMovement_PR` | ✅ Inchangé |
-| `SerializeAgvTasks_PR` | ✅ Inchangé — écrit EAG, le middleware lit et POST |
+| `SerializeAgvTasks_PR` | ✅ Inchangé - écrit EAG, le middleware lit et POST |
-| `ProcessEvents_PR` + `ProcessEvent_*_PR` | ✅ Inchangé — poll AGE comme d'habitude |
+| `ProcessEvents_PR` + `ProcessEvent_*_PR` | ⚠️ **Modifié (LIM-103)** - patch dispatch `phase+100`, gestion events 106/110, refus mission, fix `canPick`/`canDrop` |
-| `ProcessErrors_PR` | ✅ Inchangé — réagit aux Flags dans AGE |
+| `ProcessErrors_PR` | ✅ Inchangé - réagit aux Flags dans AGE |
-| `Agvtask_CanPick/CanDrop_PendingToBeSent_PR` | ✅ Inchangé — écrit EAG, le middleware appelle `/final-source` ou `/final-destination` |
+| `Agvtask_CanPick/CanDrop_PendingToBeSent_PR` | ✅ Inchangé - écrit EAG, le middleware appelle `/final-source` ou `/final-destination` |
-| `TaskCanceledEventHandler_PR` | ✅ Inchangé — écrit EAG Delete, le middleware gère |
+| `TaskCanceledEventHandler_PR` | ✅ Inchangé - écrit EAG Delete, le middleware gère |
-| Workflows RFT | ✅ Inchangés — fallback préservé |
+| Workflows RFT | ✅ Inchangés - fallback préservé |
-## FAQ STILL — réponses contractuelles
+## Corrections des bugs du module AGV standard (LIM-103)
 > **Statut** : préprod ; revue de code à faire (@Vincent, 30/06/2026),
 > assignée Vincent Charvet. Ticket regroupant les corrections nécessaires
 > pour faire fonctionner le module AGV standard sur ce projet.
 ### Queries standard corrigées
 - `Equipment_AgvTask_GetTask_ByWorkingZone_UI` : correction d'une null
  exception sur query standard.
 - `Equipment_AgvTask_LoadEquipment_UI` : correction d'un paramètre erroné
  sur query standard.
 ### Dispatch d'events cassé par la transformation Gateway `phase + 100`
 Bug de cohérence Mecalux entre la Gateway et le module AGV. Le record
 `agvEvent` reçu par `ProcessEvents_PR` est un `GalileoEventCreatedWF` dont
 le champ `EventType` (Integer) porte la valeur **SIMO** de la Gateway,
 alors que la DecisionActivity « Event type » de `ProcessEvents_PR` dispatche
 sur les **valeurs natives** 100 / 103 / 104 / 108.
 Chaîne du bug :
 - le middleware écrit `phase = 104` dans `agv_age.phase` ;
 - la Gateway lit la ligne et pose `EventType = phase + 100 = 204`
  (avec `Extension[PHASE] = 104`) ;
 - `ProcessEvents_PR` reçoit `EventType = 204` ≠ 100/103/104/108 → **default
  silencieux** → workflow Completed sans side-effect (silent fail).
 Fix : patch de l'activité « Check parameters » de `ProcessEvents_PR`
 (soustraction de 100 pour retrouver la valeur native).
 ### `canPick` / `canDrop` jamais assignés (LoadPermission / UnloadPermission)
 Bug majeur du standard : dans `ProcessEvent_LoadPermission_PR`, l'attribut
 interne `canPick` (InitialValue vide) n'est **jamais assigné**. La
 DecisionActivity « Can pick? » prend donc toujours la branche `Otherwise No`
 → End, et le sous-workflow `Agvtask_CanPick_PendingToBeSent_PR` (qui pose
 `CanPick = true`) n'est **jamais appelé**. Même défaut dans
 `ProcessEvent_UnloadPermission_PR` (attribut `canDrop`).
 | Workflow | État | Logique |
 |----------|------|---------|
 | `ProcessEvents_PR` | OK (après patch -100) | Dispatch sur `EventType == 100/103/104/108` |
 | `Agvtask_CanPick_PendingToBeSent_PR` | OK | `CanPick = true` hardcodé, fait le flip |
 | `SetAgvStatus_PR` | OK | `if CanPick && CanDrop → Sent ; elif CanPick → PendingToBeUnload ; else → PendingToBeLoad` |
 | `ProcessEvent_LoadPermission_PR` / `ProcessEvent_UnloadPermission_PR` | BUGGÉ | `canPick` / `canDrop` jamais assigné → branche No systématique |
 Fix : remplacer l'expression de la condition `Yes` de la DecisionActivity
 par `!agvTask.CanPick` (resp. `!agvTask.CanDrop`), qui teste directement la
 propriété de l'`AgvTask` récupérée par « Get AGV task ». En l'état, le
 standard Mecalux est **inutilisable** pour le flow LoadPermission /
 UnloadPermission.
 ### Events 106 / 110 non gérés (fix temporaire)
 Le standard ne gère pas les events **106** (déplacer le support sur l'AGV)
 et **110** (déplacer le support de l'AGV vers son emplacement de
 destination). Fix temporaire (Michael Chaudier, 29/05) : `ProcessEvents_PR`
 gère désormais les events 106 (confirmation load) et 110 (confirmation
 unload), avec ajout des commandes de déplacement du support - chargement
 sur l'AGV à l'event 106, déchargement à la destination de la tâche à
 l'event 110.
 ### Refus de mission iGo
 Ajout (Arthur, 01/06) d'une condition dans `ProcessEvents_PR` pour gérer le
 refus de mission par iGo → **annulation de la tâche AGV** ; la transition
 « sequence 0 » est modifiée pour ne pas catcher cette erreur (non gérée par
 le sous-workflow) tant qu'aucun flag d'erreur n'est levé.
 ### Génération du mouvement PS → position PK
 `Container_MovedEventHandler_PS_PR` modifié (Vincent, 02/06, commit
 [`9fa84a83e2`](https://msscode.mecalux.com/Proyectos_SW/EASYWMS_11351_LIMAGRAIN/commit/9fa84a83e2dfeaa8a4bde22b10a7e2318658bfbb))
 pour générer le mouvement des PS vers la bonne position du PK (**première
 position libre**). Logique conservée pour la recertification et
 l'échantillonnage.
 > Ce même handler est ensuite spécialisé : redirection selon le **type de
 > tâche** au picking (voir [Placement PS → PK](../03-picking/placement-ps-pk.md),
 > LIM-82) et placement à la **position X max** de l'image de quai à
 > l'expédition (voir [Assignation automatique de l'image de quai](../04-outbound/assignation-image-quai.md),
 > LIM-94). LIM-103 en pose la base (première position libre).
 ## FAQ STILL - réponses contractuelles
 Réponses obtenues de STILL en avril 2026. Valeur contractuelle.
@@ -552,16 +684,18 @@ Réponses obtenues de STILL en avril 2026. Valeur contractuelle.
 ⚠️ **CanPick/CanDrop** : pour reproduire le standard EasyWMS, forcer
 l'usage de Groups même mono-location.
-⚠️ **Priorité inversée** : EasyWMS 0=Urgent, iGO 10=Max — conversion
+⚠️ **Priorité inversée** : EasyWMS 0=Urgent, iGO 10=Max - conversion
 à coder dans le middleware.
-⚠️ **Pas de routing exposé** : iGO gère ses routes en interne — pas
+⚠️ **Pas de routing exposé** : iGO gère ses routes en interne - pas
 d'équivalent à "Routes between stations" en EasyS, pas d'erreur
 "Disabled route" côté iGO.
 ⚠️ **Annulation après chargement impossible** : la logique
 `AgvTask_SetCancelledTask_PR` qui déclenche la recherche de relocation
-après chargement n'a plus de sens dans le mapping iGO.
+après chargement n'a plus de sens dans le mapping iGO. Le WMS **refuse
 désormais l'annulation en amont** via la souscription preview LIM-104 (voir
 [Refus WMS de l'annulation…](#refus-wms-de-lannulation-quand-le-support-est-sur-un-agv-lim-104)).
 ⚠️ **Tests de charge webhook à mener** : simuler Gateway iGO down
 pendant 30s / 1min / 5min pour observer le comportement réel d'iGO
@@ -575,16 +709,16 @@ pendant 30s / 1min / 5min pour observer le comportement réel d'iGO
 ## Questions ouvertes
- [ ] Fréquence des callbacks `vehicle/event` pour les mises à jour de
+- ❓ Fréquence des callbacks `vehicle/event` pour les mises à jour de
-  position — risque de flood (@Nicolas)
+  position - risque de flood (@Nicolas)
- [ ] Taille max et caractères autorisés dans `customMetaData` (@STILL)
+- ❓ Taille max et caractères autorisés dans `customMetaData` (@STILL)
- [ ] Les `customMetaData` sont-elles ré-émises dans les callbacks
+- ❓ Les `customMetaData` sont-elles ré-émises dans les callbacks
  transport ? (@STILL)
- [ ] Création/modification de Location via API iGO — limité à GET
+- ❓ Création/modification de Location via API iGO - limité à GET
  pour l'instant (@STILL)
- [ ] Gestion Pallet Shuttle via iGO (LoadType = 1) — hors scope
+- ❓ Gestion Pallet Shuttle via iGO (LoadType = 1) - hors scope
  actuel ? (@Théo)
- [ ] Multi-warehouse : iGO suppose un seul site — impact si extension
+- ❓ Multi-warehouse : iGO suppose un seul site - impact si extension
  future ? (@Michael)
 ## Historique des modifications
@@ -592,12 +726,16 @@ pendant 30s / 1min / 5min pour observer le comportement réel d'iGO
 | Date | Auteur | Modification |
 |------|--------|-------------|
 | 2026-05-12 | Arthur | Création initiale depuis CR technique iGO STILL |
 | 2026-07-20 | Arthur | Intégration LIM-103 (corrections bugs module AGV standard, préprod, revue de code à faire) : nouvelle section (2 queries standard corrigées, dispatch d'events cassé par `phase+100`, `canPick`/`canDrop` jamais assignés dans LoadPermission/UnloadPermission, events 106/110 non gérés, refus de mission iGo, `Container_MovedEventHandler_PS_PR` première position libre) ; réserve ajoutée sur le tableau « workflows inchangés » (ligne `ProcessEvents_PR` = Modifié) ; front matter jira_refs/sources/last_updated |
 | 2026-07-20 | Arthur | Intégration LIM-104 (refus WMS annulation/suppression Task si support sur AGV, préprod, revue validée 23/06) : sous-section sous « Logique d'annulation » (désync task supprimée avant refus iGo, souscription preview, critère `Container.StationType == Agv`, table AD `CST_TaskCancel_CheckAgv`/`CST_TaskDelete_CheckAgv`/`CST_CancelTask_CheckForAgv`/`CST_CancelTask_NotPossible_2`, cas de test) ; cross-ref depuis le point d'attention « Annulation après chargement impossible » ; jira_refs +LIM-104 |
 ## Références
 | Source | Type | Date |
 |--------|------|------|
-| CR technique iGO STILL — fonctionnement et flux API v1 | CR technique | 2026-04-28 |
+| CR technique iGO STILL - fonctionnement et flux API v1 | CR technique | 2026-04-28 |
 | [LIM-103](https://easywmsfrance.atlassian.net/browse/LIM-103) | Ticket Jira (corrections bugs module AGV standard - préprod, revue à faire, commit `9fa84a83e2`) | 2026 |
 | [LIM-104](https://easywmsfrance.atlassian.net/browse/LIM-104) | Ticket Jira (refus annulation Task si support sur AGV - préprod, revue validée 23/06) | 2026 |
 | 2510_PACS-2.3-Host-Interface-Technical-Specifications | Spec API STILL | 2025-10 |
 | iGo easy 2.3 - Host Interface Specifications | Spec API STILL | 2025 |
 | IT requirements R1 20250929 | Spec infra STILL | 2025-09-29 |
@@ -1,11 +1,11 @@
 ---
-title: "Interface ERP — Vue d'ensemble"
+title: "Interface ERP - Vue d'ensemble"
 tags: [erp, interface, messages, index]
 status: draft
-last_updated: 2026-05-05
+last_updated: 2026-07-20
 ---
-# Interface ERP — Vue d'ensemble
+# Interface ERP - Vue d'ensemble
 > **Périmètre** : catalogue de messages ERP (SOR, RUT, SOF, LOF, ASN),
 > mapping champs ERP↔WMS, monitoring de l'interface.
@@ -16,10 +16,9 @@ last_updated: 2026-05-05
 - [Référence messages](messages-reference.md)
 - [Données principales et stock](donnees-principales.md)
- [LOC — Message périodique](loc-message-periodique.md)
+- [LOC - Message périodique](loc-message-periodique.md)
 - [Intégration GNA → SAP-CPI](gna-sap-cpi.md)
 - [Mapping ERP-WMS](mapping-erp-wms.md)
 - [Monitoring interface](interface-monitoring.md)
 ## Vue synthétique de l'interface ERP Limagrain
@@ -1,16 +1,16 @@
 ---
-title: "Données principales et stock — Mapping ITM et attributs"
+title: "Données principales et stock - Mapping ITM et attributs"
 tags: [ERP, ITM, article, stock, attributs-logistiques, lot-SAP, mapping, CstAtt]
 status: draft
-standard_ref: architecture/erp-integration.md
+standard_ref: concepts/erp-interface.md
-jira_refs: []
+jira_refs: [LIM-92]
 confluence_refs: ["Données principales + stock - LIMAGRAIN - DEV"]
-sources: ["Données principales + stock - LIMAGRAIN - DEV - Confluence.md", "CR CONSOLIDES REU ERP LIMAGRAIN V1 - CR.md"]
+sources: ["Données principales + stock - LIMAGRAIN - DEV - Confluence.md", "CR CONSOLIDES REU ERP LIMAGRAIN V1 - CR.md", "Jira LIM-92 (lecture directe, attente déploiement test)"]
-last_updated: 2026-05-06
+last_updated: 2026-07-17
 author: Arthur
 ---
-# Données principales et stock — Mapping ITM et attributs
+# Données principales et stock - Mapping ITM et attributs
 > **Résumé** : architecture retenue pour la gestion des articles et du stock
 > dans EasyWMS chez Limagrain, mapping du message ITM, attributs logistiques,
@@ -36,8 +36,8 @@ différents (ex. : changement de destination).
 | Relation | Type | Statut |
 |----------|------|--------|
 | Lot SAP ↔ Lot Officiel | 1 pour 1 | ✅ Validé par Limagrain |
-| Code article WMS = Code lot SAP | — | ✅ Validé |
+| Code article WMS = Code lot SAP | - | ✅ Validé |
-| Code produit SAP = Attribut logistique du stock | — | ✅ Validé |
+| Code produit SAP = Attribut logistique du stock | - | ✅ Validé |
 ### Côté SAP
@@ -68,24 +68,24 @@ Un même produit peut exister en BAG et en KG = codes articles WMS différents.
 |---------------|-----------|----------|
 | ItemCode | Code lot SAP | Clé principale |
 | Alias | Lot officiel | Relation 1:1, scannable |
-| OwnerCode | — | Constante "MECALUX" (technique) |
+| OwnerCode | - | Constante "MECALUX" (technique) |
 | Description | Description longue | Affichage PC |
 | AltDescription | Description courte (MAKTL) | Affichage mobile, < 65 car. |
 | Type | FERT / ZSIZ / etc. | + description du type |
-| Family | Traitement commercial | Ex : "20 : R - Cruiser OSR" — pas de séparation familles en préparation |
+| Family | Traitement commercial | Ex : "20 : R - Cruiser OSR" - pas de séparation familles en préparation |
 | BaseUoM | BAG ou KG | Selon type d'article |
 | Weight | Poids brut du sac | Poids unitaire théorique |
 | ContainerQty | Nb sacs par palette | Palette pleine standard (= Bag/Pal) |
 | ContainerType | Palette | Un seul type de palette |
-| CstAtt02 | Espèce | Ex : M = Maïs, S = Tournesol — pour ordonnancement picking |
+| CstAtt02 | Espèce | Ex : M = Maïs, S = Tournesol - pour ordonnancement picking |
 | CstAtt03 | Génération | Génération article rattachée au lot SAP |
 | CstAtt04 | Variété | Ex : "LG50465" |
 | CstAtt05 | Big bag | True / False |
 | CstAtt06 | GTIN | Ne peut être un alias car non unique |
 | CstAtt07 | Semences essais | True / False |
-| CstAtt08 | Size (calibre) | — |
+| CstAtt08 | Size (calibre) | - |
-| CstAtt09 | Field production area | — |
+| CstAtt09 | Field production area | - |
-| CstAtt10 | Stage | ⚠️ À ajouter — requis pour étiquette échantillon |
+| CstAtt10 | Stage | ⚠️ À ajouter - requis pour étiquette échantillon |
 | Conversion.Principale.CstAtt01 | Poids unitaire article | Poids théorique ERP |
 ## Profils logistiques
@@ -110,12 +110,47 @@ Un même produit peut exister en BAG et en KG = codes articles WMS différents.
 | Size | Taille | Pays de destination | Peut changer en cours de vie du stock |
 > ⚠️ Les noms de balises API (Color, Size…) ne correspondent pas aux données
-> métier. Le renommage d'affichage est géré dans le WMS.
+> métier. Le renommage d'affichage est géré dans le WMS (voir
 > [Renommage des ressources EasyWMS (LIM-92)](#renommage-des-ressources-easywms-lim-92)).
 > **Point à tester** : en réception, la création du stock via les attributs
-> logistiques doit être validée (approche standard ou custom — à confirmer
+> logistiques doit être validée (approche standard ou custom - à confirmer
 > par les tests).
 ## Renommage des ressources EasyWMS (LIM-92)
 > **Statut** : dev terminé, en **attente de déploiement pour test**.
 Les champs standard EasyWMS (code article, famille, attributs logistiques)
 sont **détournés** pour porter les concepts SAP de Limagrain. LIM-92
 renomme les **ressources globales** d'affichage en conséquence (le nom
 métier remplace le libellé standard partout dans l'UI).
 | Champ standard | Ressource | FR (nouveau) | EN (nouveau) |
 |---|---|---|---|
 | Article (product code) | `Shared_Product` | Code lot SAP | SAP batch code |
 | Menu article | `Articulos`, `Menu_Items` | Lots SAP | SAP batchs |
 | Famille article | `Prop_Product_ProductFamilyCode` | Traitement commercial | Commercial processing |
 | Menu famille | `Menu_ItemFamilies` | Traitements commerciaux | Commercial processings |
 | Attr. Lot | `Shared_Lote` | Code produit SAP | SAP product code |
 | Attr. Couleur | `Shared_Colour` | Propriétaire SAP | SAP owner |
 | Attr. Origine / Source | `Shared_Source` | Description courte SAP | SAP short description |
 | Attr. Taille | `Shared_Size` | Pays destination | Destination country |
 **Ressources complémentaires** touchées au fil des retours de recette :
 - `Shared_Calibre` : corrigée pour afficher « Pays destination » (manquait
  à l'ajustement de stock, retour 04/06).
 - `Shared_Códigodelote` : passée à « Code produit SAP » (retour 30/06).
 - Messages d'erreur d'assignation de stock alignés sur les nouveaux
  libellés : `StockAssign_TraceStockDoesNotMeetColour`,
  `StockAssign_TraceStockDoesNotMeetLotCode`,
  `StockAssign_TraceStockDoesNotMeetSize`,
  `StockAssign_TraceStockDoesNotMeetSource`.
 > ⚠️ Les 4 ressources `StockAssign_TraceStockDoesNotMeet*` ont été poussées
 > par erreur sur la branche LOT2.2 (à surveiller au déploiement).
 ## Gestion des codes clients / fournisseurs
 La base client/fournisseur SAP **n'est pas interfacée** avec le WMS.
@@ -126,14 +161,14 @@ Les codes sont gérés via des constantes + champ texte libre :
 | ROR Fournisseur | SupplierCode = "FOURNISSEUR" | Code fournisseur SAP + libellé |
 | ROR Retour client | AccountCode = "CLIENT" | Code client SAP + libellé |
 | SOR / RUT Client | AccountCode = "CLIENT" | Code client SAP + libellé |
-| SOR Production | AccountCode = "PRODUCTION" | — |
+| SOR Production | AccountCode = "PRODUCTION" | - |
 ## Gestion des poids
 | Situation | Comportement ERP |
 |-----------|-----------------|
-| Article en BAG (UdM ≠ KG) | L'ERP ne s'intéresse qu'à la quantité de sacs — les écarts de poids sont ignorés |
+| Article en BAG (UdM ≠ KG) | L'ERP ne s'intéresse qu'à la quantité de sacs - les écarts de poids sont ignorés |
-| Article en KG | Seule la quantité en KG intéresse l'ERP — si le poids change (balance), le WMS modifie la quantité |
+| Article en KG | Seule la quantité en KG intéresse l'ERP - si le poids change (balance), le WMS modifie la quantité |
 Le poids théorique de la ligne de stock (quantité × poids unitaire, hors
 poids palette) est transmis via l'attribut logistique `Weight`.
@@ -185,28 +220,28 @@ fonctionnellement.
 ## Points d'attention
-⚠️ Le CstAtt10 (Stage) est **à ajouter** — il est requis pour l'étiquette
+⚠️ Le CstAtt10 (Stage) est **à ajouter** - il est requis pour l'étiquette
 d'échantillonnage.
 ⚠️ Les noms de balises API stock (Color, Size, Source) sont détournés de
-leur usage standard — ne pas confondre avec les concepts habituels.
+leur usage standard - ne pas confondre avec les concepts habituels.
 ⚠️ Les CstAtt au niveau du stock ont été supprimés (décision 11/02/2026)
-au profit des attributs logistiques standards — vérifier l'impact sur les
+au profit des attributs logistiques standards - vérifier l'impact sur les
 développements en cours.
 ⚠️ Le mode Complete = true signifie que chaque ITM contient la fiche
-complète (pas de delta) — attention à la volumétrie.
+complète (pas de delta) - attention à la volumétrie.
 ⚠️ La base client/fournisseur n'est pas interfacée : le code est descendu
 dans chaque message ROR/SOR/RUT, pas maintenu en master data.
 ## Questions ouvertes
- [ ] CstAtt10 Stage — quand sera-t-il ajouté au mapping ITM ? (@Nicolas)
+- ❓ CstAtt10 Stage - quand sera-t-il ajouté au mapping ITM ? (@Nicolas)
- [ ] Création stock via attributs logistiques en réception — standard ou
+- ❓ Création stock via attributs logistiques en réception - standard ou
  custom ? À valider par tests (@Fabien)
- [ ] Impact suppression CstAtt stock sur les développements existants (@Nicolas)
+- ❓ Impact suppression CstAtt stock sur les développements existants (@Nicolas)
 ## Historique des modifications
@@ -214,6 +249,7 @@ dans chaque message ROR/SOR/RUT, pas maintenu en master data.
 |------|--------|--------------|
 | 2026-05-05 | Arthur | Création initiale depuis page Confluence DEV |
 | 2026-05-06 | Arthur | Ajout champs non utilisés, conversions, types supports, Z-Bags (CR consolidé) |
 | 2026-07-17 | Arthur | LIM-92 (attente déploiement test) : section « Renommage des ressources EasyWMS » (table ressources → libellés SAP : Shared_Product/Lote/Colour/Source/Size, Prop_Product_ProductFamilyCode, Menu_Items/ItemFamilies, Articulos ; ressources complémentaires Shared_Calibre/Códigodelote + 4 StockAssign_TraceStockDoesNotMeet*, caveat branche LOT2.2) |
 ## Références
@@ -223,3 +259,4 @@ dans chaque message ROR/SOR/RUT, pas maintenu en master data.
 | Ateliers interfaçage EasyWMS/SAP | Ateliers | 05/01 → 23/02/2026 |
 | Notes complémentaires 11/02/2026 | Note | 11/02/2026 |
 | CR CONSOLIDES REU ERP LIMAGRAIN V1 | CR ateliers | 23/02/2026 |
 | [LIM-92](https://easywmsfrance.atlassian.net/browse/LIM-92) | Ticket Jira (renommage ressources) - attente déploiement test | 2026 |
@@ -1,14 +1,16 @@
 ---
 title: "Intégration GNA → SAP-CPI"
 tags: [ERP, GNA, SAP-CPI, OAuth, middleware, API, BOO]
-status: draft
+status: review
-standard_ref: architecture/erp-integration.md
+standard_ref: concepts/erp-interface.md
 jira_refs: [LIM-89]
 confluence_refs: []
 sources:
  - "LIM-89 GNA Mise en place de la communication API EasyWMS SAP CPI.md"
  - "recap_session_LIM-72_13-05-2026.md"
-last_updated: 2026-05-13
+  - "Jira LIM-89 (lecture directe, revue de code validée 2026-05-21)"
 last_updated: 2026-07-17
 author: Arthur
 ---
@@ -24,7 +26,7 @@ author: Arthur
 > (OAuth password grant). Chez Limagrain, la cible est **SAP-CPI** avec
 > un mécanisme spécifique.
-> Voir aussi : [LOC — Message périodique](loc-message-periodique.md),
+> Voir aussi : [LOC - Message périodique](loc-message-periodique.md),
 > [Référence messages](messages-reference.md),
 > [Mapping ERP-WMS](mapping-erp-wms.md)
@@ -47,6 +49,16 @@ Le script `CommonExportWebApi.boo` est le point d'entrée pour tous les
 exports WMS → SAP-CPI. Il gère l'authentification, le formatage et
 l'envoi des messages.
 Structure (revue de code LIM-89) :
 | Élément | Rôle |
 |---|---|
 | `CheckConnection()` | Authentification OAuth 2.0 client_credentials. Retry backoff exponentiel **4 tentatives (2s/4s/8s)**. Token persisté en JSON sur disque, gestion d'expiration (marge 60s). Arrêt immédiat sur 401 |
 | `SendWebApiMessage` | Envoi POST vers l'endpoint unique. Détermination du `MessageSAP` puis construction du body. Retry backoff **5 tentatives (2s/4s/8s/16s)**. Token relu depuis le cache à chaque envoi |
 | `CpiTokenResponse` | Désérialisation de la réponse OAuth (`access_token`, `token_type`, `expires_in`) |
 | `CpiTokenCache` | Cache token JSON sur disque (`AccessToken`, `ExpiresAtUtc`) |
 | `ReadWebApiFile`, `GenerateWebApiError`, `RegisterObservers` | Inchangés (template Mecalux standard) |
 ### Flux de communication
 ```mermaid
@@ -86,7 +98,7 @@ sequenceDiagram
 4. À chaque envoi, le GNA vérifie le cache : si le token est encore valide,
   il le réutilise ; sinon il en demande un nouveau
-## Envoi des messages — Format du body
+## Envoi des messages - Format du body
 Pour chaque message WMS exporté, le GNA envoie un POST vers l'endpoint
 unique SAP-CPI `/http/ATHInboundMessage` avec le body JSON suivant :
@@ -109,29 +121,44 @@ le préfixe du MessageType WMS (3 premiers caractères) et le code SAP-CPI :
 | Code CPI | Équivalent WMS | Description |
 |----------|----------------|-------------|
-| ATH214 | Check flux retour (batch) | Vérification lot retour client |
+| ATH214 | Check flux retour (BAPI) | Vérification lot retour client |
-| ATH215 | REF (type = Supplier) | Finalisation réception fournisseur |
+| ATH215 | REF (type = Retour) | Finalisation réception retour |
-| ATH217 | REF (type = Return) | Finalisation réception retour |
+| ATH217 | REF (type = Supplier) **ou ROF** | Finalisation réception fournisseur / clôture OE |
 | ATH201 | LOC | Message périodique delta mouvements |
 | ATH202 | LOF | Finalisation chargement |
 > ⚠️ **Correction (revue de code LIM-89, 2026-05-21)** : le sens
 > `REF Retour → ATH215` / `REF Supplier → ATH217` retenu ici est celui
 > de la table de l'intégrateur ERP et de l'implémentation. Une version
 > antérieure de cette page inversait les deux codes. `ROF` est mappé sur
 > `ATH217` (et non `ATH215` comme le suggérait la description initiale).
 > ⚠️ Si un type de message n'a pas de correspondance dans la table, un
 > **warning** est logué et le champ MessageSAP n'est pas inclus dans le
 > body.
 ### Détermination conditionnelle du MessageSAP pour REF
-Le message REF peut être routé vers **ATH215** (Supplier) ou **ATH217**
+Le message REF est routé vers **ATH215** (type Retour) ou **ATH217**
-(Return) selon le type de préavis de réception (InboundOrder) lié :
+(type Supplier) selon le type de préavis de réception lié.
-1. Le **REF01Observer.boo** récupère le type de préavis via une requête
+**Implémentation définitive (revue de code)** : la détermination se fait
-   LINQ sur `Context.RecLineInboundOrderLines` → `Context.InboundOrders`
+**dans `CommonExportWebApi.boo`** (bloc `SendWebApiMessage`), via une
-2. Le type est transmis dans le champ `RecCustomAttributes.CstAtt20` du
+requête LINQ sur `Context.Receptions` en utilisant le `ReceiptCode`
-   message REF01
+extrait du payload JSON. Le préfixe 3 caractères du `MessageType`
-3. Le script `CommonExportWebApi.boo` lit `CstAtt20` dans le payload JSON
+(`REF01` → `REF`) sert au lookup dans le dictionnaire `messageSapMap` ;
-   pour déterminer le `MessageSAP` :
+pour REF, la logique conditionnelle sur le type de préavis choisit
-   - Type Supplier → `ATH215`
+ATH215 (Retour) ou ATH217 (Supplier).
-   - Type Return → `ATH217`
+
 - Type Retour → `ATH215`
 - Type Supplier → `ATH217`
 > **Note (reversal)** : la conception initiale prévoyait de porter le
 > type via `RecCustomAttributes.CstAtt20` écrit par le `REF01Observer.boo`
 > (requête sur `Context.RecLineInboundOrderLines` → `Context.InboundOrders`).
 > Cette approche a été **abandonnée** : le type est désormais résolu
 > directement dans `CommonExportWebApi.boo` via le `ReceiptCode`
 > (`Context.Receptions`). `REF01Observer.boo` n'est donc pas modifié.
 ## Cartographie complète des interfaces Athenzat
@@ -155,8 +182,8 @@ Source : doc CPI Maxime Tourrette (24/04/2026) + mail S15 Justine.
 | Code ATH | Type Easy | Type SAP | Description |
 |----------|-----------|----------|-------------|
 | ATH214 | Z_IATH214 | Z_IAT214 | Check Batch (vérification lot retour) |
-| ATH215 | REF | Z_IAT215 | Bon de réception fournisseur |
+| ATH215 | REF (Retour) | Z_IAT215 | Bon de réception retour |
-| ATH217 | REF | Z_IAT217 | Bon de réception retour |
+| ATH217 | REF (Supplier) / ROF | Z_IAT217 | Bon de réception fournisseur / clôture OE |
 | ATH201 | LOC / STV | Z_IAT201 | Mouvement stock (rangement ASRS, mvt HU, prep mix, customer flag, stock adjust) |
 | ATH202 | LOF | Z_IAT202 | Chargement (Loading / Goods Issue) |
@@ -167,13 +194,14 @@ Source : doc CPI Maxime Tourrette (24/04/2026) + mail S15 Justine.
 > **Note** : le flux ATH214 est le seul appelé **directement depuis un
 > workflow** (pas via GNA/BOO). Voir [Réception retour](../01-inbound/reception-retour.md).
-## Gestion des erreurs — Retry avec backoff
+## Gestion des erreurs - Retry avec backoff
 | Situation | Comportement |
 |-----------|-------------|
-| HTTP 200 | Succès — message envoyé |
+| HTTP 200 | Succès - message envoyé |
-| HTTP 401 | **Échec immédiat** — token invalide, pas de retry |
+| HTTP 401 | **Échec immédiat** - token invalide, pas de retry |
-| Autre erreur HTTP | **Retry backoff exponentiel** : 2s → 4s → 8s → 16s |
+| Autre erreur HTTP (auth) | **Retry backoff** : 4 tentatives (2s → 4s → 8s) |
 | Autre erreur HTTP (envoi message) | **Retry backoff** : 5 tentatives (2s → 4s → 8s → 16s) |
 ## Configuration requise
@@ -184,7 +212,7 @@ Six clés `CPI_*` à ajouter dans `CommonAppSettings.config`
 |-----|-------------|
 | CPI_AUTH_URL | URL du serveur d'authentification SAP OAuth |
 | CPI_CLIENT_ID | Identifiant OAuth |
-| CPI_CLIENT_SECRET | Secret OAuth (en clair dans le config) |
+| CPI_CLIENT_SECRET | Secret OAuth (**chiffré via `PasswordEncrypt.exe`**) |
 | CPI_ENDPOINT_URL | Endpoint unique SAP-CPI (`/http/ATHInboundMessage`) |
 | CPI_TOKEN_PATH | Chemin du fichier cache token sur disque |
 | CPI_TIMEOUT | Timeout HTTP en secondes (auth + messages) |
@@ -201,9 +229,9 @@ Six clés `CPI_*` à ajouter dans `CommonAppSettings.config`
 | Fichier | Modification |
 |---------|-------------|
-| `Scripts2015/CommonExportWebApi.boo` | Script principal d'export WMS → SAP-CPI |
+| `Scripts2015/CommonExportWebApi.boo` | Script principal d'export WMS → SAP-CPI (auth, MessageSAP, envoi) |
-| `Scripts2015/EasyWMS/XML/REF01/REF01Observer.boo` | Ajout requête InboundOrderType + écriture CstAtt20 |
+| `Configuration/LIMAGRAI2512/CommonAppSettings.config` | Ajout des 6 clés CPI_* (secret chiffré) |
-| `Configuration/LIMAGRAI2512/CommonAppSettings.config` | Ajout des 6 clés CPI_* |
+| ~~`Scripts2015/EasyWMS/XML/REF01/REF01Observer.boo`~~ | Prévu initialement (CstAtt20) - **non retenu** : type REF résolu via `ReceiptCode` dans `CommonExportWebApi.boo` |
 ## Logging
@@ -215,39 +243,39 @@ est logué en **format indenté** pour faciliter le debug.
 ## Cas de tests
- [ ] Le GNA compile sans erreur
+- ❓ Le GNA compile sans erreur
- [ ] L'authentification OAuth client_credentials fonctionne (HTTP 200)
+- ❓ L'authentification OAuth client_credentials fonctionne (HTTP 200)
- [ ] Le token est mis en cache sur disque et réutilisé tant qu'il est
+- ❓ Le token est mis en cache sur disque et réutilisé tant qu'il est
  valide
- [ ] Les messages WMS sont envoyés en POST avec le bon format JSON
+- ❓ Les messages WMS sont envoyés en POST avec le bon format JSON
- [ ] Le champ MessageSAP est présent avec la bonne valeur selon le type
+- ❓ Le champ MessageSAP est présent avec la bonne valeur selon le type
- [ ] REF type Supplier → MessageSAP = ATH215
+- ❓ REF type Retour → MessageSAP = ATH215
- [ ] REF type Return → MessageSAP = ATH217
+- ❓ REF type Supplier → MessageSAP = ATH217
- [ ] CstAtt20 renseigné dans le message REF01 par le REF01Observer
+- ❓ REF type résolu via `ReceiptCode` (query `Context.Receptions`)
- [ ] Warning logué si MessageType sans correspondance
+- ❓ Warning logué si MessageType sans correspondance
- [ ] Retry backoff fonctionne (hors 401)
+- ❓ Retry backoff fonctionne (hors 401)
- [ ] Logs détaillés et lisibles (JSON indenté, token masqué)
+- ❓ Logs détaillés et lisibles (JSON indenté, token masqué)
- [ ] HTTP 401 → échec immédiat sans retry
+- ❓ HTTP 401 → échec immédiat sans retry
 ## Points d'attention
-⚠️ Le **secret OAuth est en clair** dans le fichier de configuration —
+✅ Le **secret OAuth est chiffré** via `PasswordEncrypt.exe` dans le
-accès au fichier à restreindre.
+fichier de configuration (résout la question initiale du secret en clair).
 ⚠️ La marge de 60 secondes sur l'expiration du token évite les races
 conditions mais peut générer des re-authentifications prématurées sous
 forte charge.
-⚠️ Le backoff exponentiel plafonne à 16 secondes — si SAP-CPI est
+⚠️ Le backoff exponentiel plafonne à 16 secondes - si SAP-CPI est
 durablement indisponible, les messages seront perdus (pas de file
 d'attente persistante).
 ## Questions ouvertes
- [ ] Faut-il implémenter une file d'attente persistante pour les
+- ❓ Faut-il implémenter une file d'attente persistante pour les
-  messages en échec après 4 retries ? (@Nicolas)
+  messages en échec après 5 retries ? (@Nicolas)
- [ ] Le secret OAuth doit-il être chiffré dans le config ?
+- [x] ~~Le secret OAuth doit-il être chiffré dans le config ?~~
-  (@Fabien)
+  → **Résolu** (revue de code) : oui, chiffré via `PasswordEncrypt.exe`
 ## Historique des modifications
@@ -255,11 +283,14 @@ d'attente persistante).
 |------|--------|--------------|
 | 2026-05-12 | Arthur | Création depuis LIM-89 |
 | 2026-05-13 | Arthur | Ajout cartographie ATH complète, URLs TEST, note ATH214 hors GNA |
 | 2026-07-17 | Arthur | Delta revue de code : structure du script (CheckConnection/SendWebApiMessage/CpiTokenCache), retry auth 4 vs envoi 5, secret chiffré PasswordEncrypt.exe (question résolue) ; **correction du sens REF Retour→ATH215 / Supplier→ATH217 + ROF→ATH217** ; type REF résolu via ReceiptCode (REF01Observer/CstAtt20 abandonné) ; statut préprod |
 ## Références
 | Source | Type | Date |
 |--------|------|------|
-| [LIM-89](https://easywmsfrance.atlassian.net/browse/LIM-89) | Ticket Jira | 2026 |
+| [LIM-89](https://easywmsfrance.atlassian.net/browse/LIM-89) | Ticket Jira (statut préprod / test client) | 2026 |
 | Revue de code LIM-89 (Arthur, N. Chabanis) | Revue de code validée | 2026-05-21 |
 | Table de correspondance intégrateur ERP | Commentaire LIM-89 | 2026-05-11 |
 | Athenzat SAP-CPI Webservices Documentation v1.0 | PDF (Maxime Tourrette) | 2026-04-24 |
 | Mail Justine S15 | Cartographie interfaces | 2026-04 |
@@ -1,19 +1,21 @@
 ---
-title: "LOC — Message périodique (spécification complète)"
+title: "LOC - Message périodique (spécification complète)"
 tags: [ERP, LOC, custom, delta, mouvement, stock, JSON, SAP, GNA]
 status: draft
-standard_ref: architecture/erp-integration.md
+standard_ref: concepts/erp-interface.md
 jira_refs: [LIM-76]
 confluence_refs: []
 sources:
  - "LOC - Etat des lieux V2.md"
  - "CR CONSOLIDES REU ERP LIMAGRAIN V1 - CR.md"
  - "LIM-76 LOT1.2 [GNA] Message LOC.md"
-last_updated: 2026-05-12
+  - "Jira LIM-76 (relecture commentaires 2026-07-17, revue de code en cours)"
 last_updated: 2026-07-17
 author: Arthur
 ---
-# LOC — Message périodique (spécification complète)
+# LOC - Message périodique (spécification complète)
 > **Résumé** : spécification du message custom LOC, envoyé du WMS vers SAP
 > toutes les 5 minutes via le GNA, contenant le delta des HU modifiées.
@@ -21,7 +23,7 @@ author: Arthur
 > canal** de notification des mouvements de stock vers SAP.
 > **Standard EasyWMS** : → voir [ERP Integration](../../concepts/erp-interface.md)
-> Ce message est un **[CUSTOM]** — il n'existe pas dans le standard EasyWMS.
+> Ce message est un **[CUSTOM]** - il n'existe pas dans le standard EasyWMS.
 > Voir aussi : [Référence messages](messages-reference.md),
 > [Flux ERP outbound](../04-outbound/flux-erp-outbound.md),
@@ -52,9 +54,9 @@ JSON spécifique attendu par SAP.
 ### Décisions structurantes
- **STV désactivé** (post-processing coupé) — le LOC devient le **seul canal**
+- **STV désactivé** (post-processing coupé) - le LOC devient le **seul canal**
  de notification des mouvements de stock vers SAP
- **STC désactivé** — les changements de statut hors retour sont limités au
+- **STC désactivé** - les changements de statut hors retour sont limités au
  B6 (blocage logistique) et sont couverts par le LOC (action R/U).
  Les statuts des retours sont remontés dans le REF
@@ -72,7 +74,7 @@ Script BOO (requêtes WMS + agrégation + formatage JSON) → POST API SAP
 1. Un **Job** s'exécute toutes les 5 minutes
 2. Ce job appelle un **Workflow custom** dont le seul rôle est de **créer
   une transaction custom** `LOC.SEND`
-3. Le Workflow et la transaction ne portent aucune logique métier côté WMS —
+3. Le Workflow et la transaction ne portent aucune logique métier côté WMS -
   toute la logique est dans le GNA
 ### Côté GNA
@@ -96,7 +98,7 @@ Script BOO (requêtes WMS + agrégation + formatage JSON) → POST API SAP
 4. Générer le JSON et envoyer
 5. **Si aucune transaction pertinente sur le delta → pas d'envoi de LOC**
-## Couverture fonctionnelle — 7 codes ACTION
+## Couverture fonctionnelle - 7 codes ACTION
 | Code | Signification | Déclencheur |
 |------|---------------|-------------|
@@ -120,7 +122,7 @@ préalable doivent apparaître dans le LOC.
 | Réf. | Champ | Type | Description |
 |------|-------|------|-------------|
-| 1 | IV_LGNUM | CHAR 4 | Numéro d'entrepôt (valeur fixe : `"WF02"`) — config EasyS |
+| 1 | IV_LGNUM | CHAR 4 | Numéro d'entrepôt (valeur fixe : `"WF02"`) - config EasyS |
 | 2 | IV_TREATMENT_ID | CHAR 24 | Horodatage de génération du LOC |
 ### Structure JSON
@@ -148,22 +150,22 @@ préalable doivent apparaître dans le LOC.
 }
 ```
-### Table IT_CREATE — Champs (1:n)
+### Table IT_CREATE - Champs (1:n)
 | Réf. | Champ | Type | Description |
 |------|-------|------|-------------|
-| 1 | MATNR | CHAR 40 | Code produit SAP — vide si action B ou P |
+| 1 | MATNR | CHAR 40 | Code produit SAP - vide si action B ou P |
-| 2 | BATCHID | CHAR 10 | Code lot SAP — vide si action B ou P |
+| 2 | BATCHID | CHAR 10 | Code lot SAP - vide si action B ou P |
 | 3 | ACTION | CHAR 1 | Code action : B, U, R, S, T, C, P |
-| 4 | ANFME | NUM 13.3 | Quantité (absolue ou transférée selon action) — vide si B, U/R, P |
+| 4 | ANFME | NUM 13.3 | Quantité (absolue ou transférée selon action) - vide si B, U/R, P |
-| 5 | ALTME | CHAR 3 | Unité de mesure (BAG, KG) — vide si action B ou P |
+| 5 | ALTME | CHAR 3 | Unité de mesure (BAG, KG) - vide si action B ou P |
 | 6 | VLPLA | CHAR 18 | Zone de stockage origine |
 | 7 | NLPLA | CHAR 18 | Zone de stockage destination |
-| 8 | VLENR | CHAR 20 | Code HU (palette) source — SSCC |
+| 8 | VLENR | CHAR 20 | Code HU (palette) source - SSCC |
-| 9 | NLENR | CHAR 20 | Code HU (palette) destination — SSCC |
+| 9 | NLENR | CHAR 20 | Code HU (palette) destination - SSCC |
-| 10 | REASON | CHAR 4 | Code raison scrap — uniquement pour action S (ZSC1) |
+| 10 | REASON | CHAR 4 | Code raison scrap - uniquement pour action S (ZSC1) |
-| 11 | VBELN | — | Code livraison sortante SAP — uniquement pour action P |
+| 11 | VBELN | - | Code livraison sortante SAP - uniquement pour action P |
-| 12 | POSNR | — | Ligne de livraison sortante SAP — uniquement pour action P |
+| 12 | POSNR | - | Ligne de livraison sortante SAP - uniquement pour action P |
 ### Données stock/container à récupérer par ligne LOC
@@ -200,7 +202,7 @@ Pour chaque HU identifiée dans les transactions du delta :
 ### ACTION = B (Déplacement bin-to-bin)
 Déplacement de HU d'une zone à une autre. **Pas de quantité, pas de code
-article, pas de lot** — seuls les champs zone et support sont renseignés.
+article, pas de lot** - seuls les champs zone et support sont renseignés.
 Le contenu de la HU n'est pas rediscuté.
 ### ACTION = U / R (Déblocage / Blocage statut)
@@ -229,7 +231,7 @@ ACTION=T dans le même LOC, dans l'ordre chronologique.
 **Création de palette au picking** : si le SSCC en NLENR est inconnu de
 SAP, SAP crée automatiquement la HU (type palette standard). Le LOC ne
-crée que la structure palette — le stock est transféré depuis une palette
+crée que la structure palette - le stock est transféré depuis une palette
 source connue.
 ### ACTION = C (Correction de quantité)
@@ -291,7 +293,7 @@ IV_TREATMENT_ID = horodatage du moment de **génération du LOC** (pas
 l'heure de chaque transaction individuelle). Toutes les lignes d'un
 même LOC partagent le même horodatage.
-Format : `YYYYMMDD` — limité à 24 caractères (CHAR 24).
+Format : `YYYYMMDD` - limité à 24 caractères (CHAR 24).
 ## Ordre des lignes
@@ -345,16 +347,16 @@ procéder à la désactivation.
 3. Le JSON est envoyé en POST à l'endpoint SAP
 4. Les 7 codes ACTION (B, U, R, S, T, C, P) sont correctement générés
 5. ACTION=B : ANFME, ALTME, MATNR, BATCHID, NLENR, REASON, VBELN, POSNR
-   vides — seuls VLPLA, NLPLA et VLENR renseignés
+   vides - seuls VLPLA, NLPLA et VLENR renseignés
-6. ACTION=U/R : MATNR, BATCHID, ALTME, VLPLA, VLENR renseignés —
+6. ACTION=U/R : MATNR, BATCHID, ALTME, VLPLA, VLENR renseignés -
   ANFME, NLPLA, NLENR, REASON, VBELN, POSNR vides
-7. ACTION=S : REASON=ZSC1 — MATNR, BATCHID, ANFME, ALTME, VLPLA, VLENR
+7. ACTION=S : REASON=ZSC1 - MATNR, BATCHID, ANFME, ALTME, VLPLA, VLENR
-   renseignés — NLPLA, NLENR, VBELN, POSNR vides
+   renseignés - NLPLA, NLENR, VBELN, POSNR vides
-8. ACTION=T : VLENR et NLENR dans la même ligne — ANFME = qté transférée
+8. ACTION=T : VLENR et NLENR dans la même ligne - ANFME = qté transférée
-   (pas un solde) — REASON, VBELN, POSNR vides
+   (pas un solde) - REASON, VBELN, POSNR vides
-9. ACTION=C : ANFME = quantité absolue (pas un delta) — NLPLA, NLENR,
+9. ACTION=C : ANFME = quantité absolue (pas un delta) - NLPLA, NLENR,
   REASON, VBELN, POSNR vides
-10. ACTION=P : VLENR, NLPLA (image de quai), VBELN, POSNR renseignés —
+10. ACTION=P : VLENR, NLPLA (image de quai), VBELN, POSNR renseignés -
    MATNR, BATCHID, ANFME, ALTME, VLPLA, NLENR, REASON vides
 11. Palettes liées à une réception non fermée (pas de REF envoyé) exclues
 12. Lignes dans IT_CREATE dans l'ordre chronologique des transactions WMS
@@ -376,7 +378,7 @@ procéder à la désactivation.
 | CT-02 | 2,3 | GNA détecte LOC.SEND et génère JSON | JSON conforme + POST HTTP 200 |
 | CT-03 | 14 | Aucune transaction sur le delta | Aucun POST vers SAP |
-### ACTION=B — Déplacement
+### ACTION=B - Déplacement
 | CT | CA | Description | Résultat attendu |
 |----|-----|-------------|------------------|
@@ -384,7 +386,7 @@ procéder à la désactivation.
 | CT-11 | 4,5 | Déplacement via CON.LOCATE | Idem CT-10 |
 | CT-12 | 4,5 | STK.MOVE sans changement HU (ContainerTo=ContainerCode) | ACTION=B (pas T) |
-### ACTION=U/R — Blocage / Déblocage
+### ACTION=U/R - Blocage / Déblocage
 | CT | CA | Description | Résultat attendu |
 |----|-----|-------------|------------------|
@@ -392,14 +394,14 @@ procéder à la désactivation.
 | CT-21 | 4,6 | Déblocage HU via CST.STK (← B6) | ACTION=U |
 | CT-22 | 6 | Changement statut hors B6 (hors retour) | Aucune ligne dans le LOC |
-### ACTION=S — Suppression / Scrap
+### ACTION=S - Suppression / Scrap
 | CT | CA | Description | Résultat attendu |
 |----|-----|-------------|------------------|
 | CT-30 | 4,7 | CON.DELETE sur une HU | ACTION=S, REASON=ZSC1, qté et champs stock renseignés |
 | CT-31 | 7 | Plusieurs suppressions | Chaque ligne S a REASON=ZSC1 uniquement |
-### ACTION=T — Transfert inter-HU
+### ACTION=T - Transfert inter-HU
 | CT | CA | Description | Résultat attendu |
 |----|-----|-------------|------------------|
@@ -409,14 +411,14 @@ procéder à la désactivation.
 | CT-43 | 18 | Picking vers SSCC inconnu SAP | Ligne T générée, LOC ne bloque pas |
 | CT-44 | 8 | Transfert via table de travail | 2 lignes distinctes (pas de fusion) |
-### ACTION=C — Correction de quantité
+### ACTION=C - Correction de quantité
 | CT | CA | Description | Résultat attendu |
 |----|-----|-------------|------------------|
 | CT-50 | 4,9 | STK.ADJ (ajustement) | ACTION=C, ANFME = qté absolue après ajustement |
 | CT-51 | 9 | Vérification REASON vide | REASON vide pour action C |
-### ACTION=P — Assignation client
+### ACTION=P - Assignation client
 | CT | CA | Description | Résultat attendu |
 |----|-----|-------------|------------------|
@@ -447,11 +449,67 @@ procéder à la désactivation.
 | CT-101 | 16 | CST.STK après désactivation STC | Pas de STC, LOC contient ACTION=R |
 | CT-110 | 4,12 | Plusieurs actions dans le même delta | 4 lignes, 4 actions, ordre chronologique |
 | CT-111 | 2 | IV_LGNUM | Toujours "WF02" |
-| CT-112 | — | HU multi-lignes de stock | Plusieurs entrées dans IT_CREATE |
+| CT-112 | - | HU multi-lignes de stock | Plusieurs entrées dans IT_CREATE |
 ## [CUSTOM] Implémentation GNA (statut : en revue de code, préprod)
 Statut ticket au 2026-07-17 : **En revue de code** (plusieurs livraisons
 préprod, revue Vincent Charvet en cours). Éléments issus de la relecture
 des commentaires :
 | Élément | Type | Rôle |
 |---------|------|------|
 | `CST_SendLOCTransaction` | Job | Toutes les 5 min, appelle `CST_SendLOC` |
 | `CST_SendLOC` | WF | Crée la transaction `LOC.SEND` (aucune logique métier) |
 | `LOC.SEND` | TransactionType | Déclenche la génération du LOC |
 | `LOC_ZONE_MAPPING` | Paramètre | Correspondance zones TK → zones client (voir [Paramètres projet](../07-admin/parametres-projet.md)) |
 | `CommonExportWebApi.boo` | Script GNA | Structure LOC selon le template client |
 | `EasyWMSExportMessages.boo` | Script GNA | Appelle `WriteLOC01` sur réception de `LOC.SEND` |
 | `EasyWMSWebApiObserver.boo` | Script GNA | Ajoute le type de message `LOC01` |
 | `LOC01.boo` | Script GNA | En-tête du message |
 | `WriteLOC01.boo` | Script GNA | Génère le message ; si rien n'a changé → transaction en erreur motif `NO_CHANGES` (évolution demandée : ne plus générer de transaction en erreur si rien à envoyer) |
 | `LOC01Observer.boo` | Script GNA | Cœur : récupère la dernière `LOC.SEND`, prend les transactions depuis (CON.MOVE, CON.LOCATE, STK.MOVE, STK.ADJ, CST.STK, STK.PICKING, CON.DELETE), détermine l'`ACTION` |
 | `LOC01.xsd` | Schéma | Structure du message LOC |
 **Décision réception non fermée** : on n'envoie pas de LOC pour un
 conteneur pas encore présent dans l'ERP (SAP les crée à partir du REF).
 Conséquence assumée par le client (soulevée par Nicolas le 02/06) : les
 modifications intervenues sur la palette **avant** l'envoi du REF ne sont
 pas rejouées après coup (filtrage par date/heure de traitement).
 ### Picking négatif (en cours - point délicat)
 Le picking négatif génère la séquence de transactions suivante :
 - `CON.CREATE` : nouveau conteneur sur une TP
 - `STK.PICKING.NEG` : déplacement de l'excédent vers la nouvelle palette,
  origine = destination = conteneur d'origine (picking sur lui-même),
  quantité = quantité demandée dans l'OS
 - 2× `CHB.LAB` : échange des labels des deux palettes (nouveau → origine,
  puis l'inverse)
 **Problème** : avec CON.CREATE + STK.PICKING.NEG seuls, on n'a pas la
 corrélation entre conteneur source et destination. `CHB.LAB` pourrait
 faire le lien, mais le swap des labels intervient **après** le picking -
 si le LOC part entre les deux étapes, l'information ne peut pas être
 regroupée. Analyse en cours (LOC01Observer mis à jour le 03/07 ; pistes
 de réflexion partagées par Arthur).
 ### Retours revue de code / client (à traiter)
 - **Retour client (08/07)** : certains LOC non intégrables côté SAP -
  action S avec les autres champs vides ; doublons (même info plusieurs
  fois). Corrections appliquées 09/07 puis 17/07.
 - **Revue de code (10/07, Vincent Charvet)** : détail des stocks manquant
  sur action S ; valeur `WF02` codée en dur ; fonction `BuildZoneMapping`
  jamais utilisée (éviterait de parser `LOC_ZONE_MAPPING` par emplacement) ;
  null ref potentielles sur la comparaison au statut B6 ; optimiser le
  cache (une query par type de donnée). Changements appliqués 17/07,
  re-revue à faire.
 ## Points d'attention
-⚠️ **STV et STC désactivés** — vérifier qu'aucun autre process métier ne
+⚠️ **STV et STC désactivés** - vérifier qu'aucun autre process métier ne
 dépend d'eux (middleware GNA, reporting).
 ⚠️ Le filtrage GNA des STV avec motif "STR" devient caduc si le STV est
@@ -465,17 +523,23 @@ pas fermée (pas de REF envoyé).
 ⚠️ Les quantités sont des valeurs **absolues** sauf pour ACTION=S (quantité
 supprimée) et ACTION=T (quantité transférée).
-⚠️ IV_LGNUM = `"WF02"` (pas "WL02" — corrigé depuis spec V2).
+⚠️ IV_LGNUM = `"WF02"` (pas "WL02" - corrigé depuis spec V2).
 ## Questions ouvertes
- [ ] Cas palette déposée sur image de quai → chargée → OS fermé →
+- ❓ Cas palette déposée sur image de quai → chargée → OS fermé →
  LOF/SOF envoyé avant le LOC : la HU ne sera pas mentionnée dans le LOC
  (@Limagrain)
- [ ] HU multi-lignes de stock : comportement exact à confirmer (CT-112)
+- ❓ HU multi-lignes de stock : comportement exact à confirmer (CT-112)
  (@Fabien)
- [ ] Vérifier si d'autres transactions WMS sont utiles pour le LOC
+- ❓ Vérifier si d'autres transactions WMS sont utiles pour le LOC
  (ex. STK.SCR) (@Fabien)
 - Picking négatif : corrélation conteneur source ↔ destination
  indisponible via CON.CREATE + STK.PICKING.NEG ; le swap `CHB.LAB`
  intervient après le picking. Solution en cours d'analyse
  (@Maxime / @Vincent)
 - LOC action S : compléter le détail des stocks ; éliminer les doublons
  (retour client 08/07, corrections en cours) (@Maxime)
 ## Historique des modifications
@@ -483,12 +547,13 @@ supprimée) et ACTION=T (quantité transférée).
 |------|--------|--------------|
 | 2026-05-06 | Arthur | Création depuis spec LOC V2 (réunion 30/04/2026) |
 | 2026-05-12 | Arthur | Refonte complète depuis LIM-76 : architecture technique GNA/BOO, ACTION=P confirmé avec VBELN/POSNR, IV_LGNUM corrigé WF02, zones SAP détaillées, contraintes de longueur, 25+ cas de tests, critères d'acceptation |
 | 2026-07-17 | Arthur | Relecture commentaires LIM-76 (statut en revue de code, préprod) : section « Implémentation GNA » (job/WF/transaction, scripts .boo, LOC01.xsd, LOC_ZONE_MAPPING, motif NO_CHANGES), décision réception non fermée (modifs pré-REF non rejouées), sous-section picking négatif (CON.CREATE + STK.PICKING.NEG + CHB.LAB, problème de corrélation), retours revue de code / client (action S, doublons, WF02 hardcodé, BuildZoneMapping, cache) |
 ## Références
 | Source | Type | Date |
 |--------|------|------|
-| [LIM-76](https://easywmsfrance.atlassian.net/browse/LIM-76) | Ticket Jira (LOT 1.2) | 2026 |
+| [LIM-76](https://easywmsfrance.atlassian.net/browse/LIM-76) | Ticket Jira (LOT 1.2) - en revue de code, préprod | 2026-07-17 |
 | LOC - Etat des lieux V2 | Spécification technique | 30/04/2026 |
 | CR CONSOLIDES REU ERP LIMAGRAIN V1 | CR ateliers interfaçage | 23/02/2026 |
 | Réunion LOC 30/04/2026 | Réunion Arthur + Justine + Nicolas | 30/04/2026 |
@@ -1,16 +1,16 @@
 ---
-title: "Mapping ERP-WMS — Changement article et propriétaire"
+title: "Mapping ERP-WMS - Changement article et propriétaire"
-tags: [ERP, mapping, CHG, STR, article, propriétaire, custom]
+tags: [ERP, mapping, CHG, STR, article, propriétaire, custom, cst-chg-wf, api]
 status: draft
-standard_ref: architecture/erp-integration.md
+standard_ref: concepts/erp-interface.md
-jira_refs: []
+jira_refs: [LIM-90, LIM-113]
 confluence_refs: []
-sources: [FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5.docx, "CR CONSOLIDES REU ERP LIMAGRAIN V1 - CR.md"]
+sources: [FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5.docx, "CR CONSOLIDES REU ERP LIMAGRAIN V1 - CR.md", "Jira LIM-90 (revue de code terminée 2026-06-03)", "Jira LIM-113 (lecture directe 2026-07-20)"]
-last_updated: 2026-05-06
+last_updated: 2026-07-20
 author: Arthur
 ---
-# Mapping ERP-WMS — Changement article et propriétaire
+# Mapping ERP-WMS - Changement article et propriétaire
 > **Résumé** : processus [CUSTOM] de changement d'article et de propriétaire
 > en cours de vie du stock, via message CHG.
@@ -30,7 +30,7 @@ sont notifiés par un message CHG descendant de SAP vers EasyWMS.
 Le message standard STR (Stock Transfer Request) est aussi utilisé pour
 les demandes de changement de statut de stock.
-## Message STR — Demande de Changement de Stock
+## Message STR - Demande de Changement de Stock
 ### Cas d'usage
@@ -59,26 +59,113 @@ Limagrain mettra en place un **monitoring des erreurs** STR pour les cas
 de refus. Les refus sont attendus en fonctionnement normal (palette en
 cours de préparation au moment du STR).
-## Message CHG — Changement article / propriétaire
+## Message CHG - Changement article / propriétaire (LIM-113)
-### Contenu du message
+> **Statut (LIM-113)** : En cours - revue fonctionnelle uniquement ; dévs non
 > démarrés, en attente de validation technique client (Arthur 06/07).
-| Champ | Description | Modifié si |
+### Objectif et contexte
 |-------|-------------|------------|
 | Numéro de HU | Identifiant palette | Toujours présent |
 | Lot Officiel | Lot de référence | Toujours présent |
 | Code nouvel article | Nouveau code article | Changement article |
 | Description nouvel article | Libellé | Changement article |
 | Destination | Nouvelle destination | Changement article |
 | Propriétaire Limagrain | Nouveau propriétaire | Changement propriétaire |
-### Contrainte d'exécution
+SAP demande au WMS de modifier une **ligne de stock existante** (code
 article, propriétaire, destination et attributs logistiques induits) **sans
 mouvement physique** de la palette. Cas principal : **bascule de propriétaire**
 lors des clôtures fiscales (ex. `FR10` → `FR02`, deux sociétés juridiques
 distinctes), où tout ou partie du stock d'une société est vendu à l'autre par
 une opération purement comptable/légale.
-Le changement ne peut avoir lieu **que si le stock n'est pas assigné à
+Ce flux va **à l'encontre de la règle d'or** (le WMS est maître de l'état
-un processus** (picking, expédition, regroupement, etc.).
+physique du stock ; toute variation est normalement initiée par le WMS). Le
 CHG demande au WMS de subir un ordre sur son propre stock. Il est donc
 **encadré** : le WMS ne modifie le stock que si la HU **et** ses lignes de
 stock ne sont engagées dans **aucun** processus, sinon il **refuse**.
-Si le stock est assigné → le message CHG génère un message **ERR** pour
+### Mécanisme d'appel
-informer SAP que le changement est impossible.
+
 SAP appelle la commande `StartWorkflowCommand`
 (`Mecalux.ITSW.Application.CommonApplication.Commands.StartWorkflowCommand`)
 sur `CustomApplication`, `ProcessName = CST_CHG_WF` (WF custom à développer de
 zéro). SAP envoie **l'identité complète de la palette** : toutes les valeurs
 cibles, pas seulement les champs modifiés, pas de couple ancienne/nouvelle
 valeur.
 ### Champs modifiables (JSON reçu)
 | Attribut (JSON) | Sémantique | Exemple |
 |-----------------|-----------|---------|
 | `containerCode` | Code HU (clé primaire) | `036607231001292781` |
 | `ContainerTypeCode` | Type de support | `PALETTE_US` |
 | `productCode` | Code article | `2025078581` |
 | `Quantity` | Quantité | `1.000` |
 | `UnitOfMeasureCode` | Unité de mesure | `BAG` |
 | `LotCode` | Lot (code produit SAP) | `000000000000384823` |
 | `Color` | Propriétaire SAP | `FR10` |
 | `Source` | Description courte SAP | `SC04-FERT-B 400KG-BE-NEU` |
 | `Size` | Pays de destination | `BE` |
 > **Statut de stock explicitement EXCLU du CHG.** Le changement de statut
 > passe par le flux **STR standard** (voir ci-dessus), inchangé. Le WF
 > `CST_CHG_WF` **ignore** le champ statut même s'il est présent dans le JSON.
 >
 > ⚠️ Pour changer **à la fois** un attribut **et** le statut d'une même HU :
 > **deux appels API distincts** (CHG puis STR). Risque assumé : l'un peut
 > passer et l'autre échouer (travail à moitié fait) → le client gère le rejeu
 > de l'appel en erreur.
 ### Logique du workflow `CST_CHG_WF`
 1. **Récupération HU + identification de la ligne** : clé = `containerCode` ;
   lister toutes les lignes de stock de la HU ; identifier la bonne ligne en
   comparant les attributs reçus (une HU peut porter plusieurs lignes). HU
   inexistante ou aucune ligne correspondante → refus (message explicite).
 2. **Vérification « HU et lignes libres de tout flux »** : reprendre la
   logique de **ADB-117** (batterie de `Count()` sur les tables métier), mais
   appliquée au **code support et aux lignes de stock** (pas à l'article).
   Différence majeure : ADB-117 supprimait du stock ; ici on ne supprime rien.
   Si la HU ou une ligne est présente dans **autre chose** que les tables
   Stocks / Support → **refus**. Tables à contrôler (liste **indicative**,
   exhaustivité à établir par le dev) : ProductLocations / lignes réservées ou
   assignées, Tasks, OutboundOrders(Lines), Receptions(Lines),
   InboundOrders(Lines), chargements camion, tournées, vagues, workorders,
   inventaires (lignes), livraisons, colis, ajustements de stock.
 3. **Refus tout ou rien** : si **une seule** ligne (ou la HU) est engagée →
   refus **intégral** du CHG. Le message précise **quelle ligne** et **dans
   quelle(s) table(s)/flux** elle est engagée.
 4. **Idempotence** : comparer champ par champ les valeurs cibles aux valeurs
   actuelles. Si **toutes** déjà en place → **OK (200)** sans rien tenter ;
   sinon appliquer les champs qui diffèrent.
 5. **Application** : si HU + ligne libres → appliquer les nouvelles valeurs
   (article, propriétaire, destination, attributs logistiques) et renvoyer
   **200**.
 ### Acquittement API et notification
 - **Succès** → WF terminé normalement → API **200**.
 - **Échec (refus métier ou erreur)** → **throw d'une exception HTTP 500** avec
  le message d'erreur complet.
 > ⚠️ **Contrainte technique built-in** : le seul moyen de renvoyer un message
 > d'erreur exploitable sur ce type d'appel `StartWorkflowCommand` est de
 > **throw une exception (500)**. Il n'existe pas d'acquittement négatif propre
 > (200 + payload de refus). Un CHG refusé pour raison métier normale (palette
 > dans un flux) remonte donc techniquement comme un **500** : SAP doit
 > l'interpréter comme un **refus métier** (pas un plantage), lire le message,
 > débloquer, puis rejouer. À communiquer à Limagrain.
 En complément, le WMS génère une **notification interne** en cas de refus,
 pour traitement manuel par un gestionnaire formé (paramétrage standard + léger
 custom potentiel ; mécanisme de notifications/alertes standard à vérifier en
 doc Confluence).
 ### Volumétrie et cible fonctionnelle
 - Pas de flux régulier de faible volume mais des **vagues** liées aux clôtures :
  jusqu'à ~1000 lignes d'un coup, jusqu'à **un tiers du stock** sur 2 jours.
  Limagrain envoie des **messages unitaires** (ex. 1000 appels plutôt qu'un
  message groupé). **À valider (Mecalux)** : traitement **synchrone ou
  asynchrone / arrière-plan** pour tenir la charge sans bloquer les flux 24/7.
 - Cible : ~**90 %** des changements passent s'ils sont envoyés au bon moment ;
  ~**10 %** (palette dans un flux) → refus + correction manuelle par un
  gestionnaire. Pas de sur-automatisation initiale.
 ## Statut de stock
@@ -88,11 +175,16 @@ informer SAP que le changement est impossible.
 travail **uniquement** lors du processus de **retour commandes clients**,
 pour appliquer :
- **F9** — Sacs sales
+- **F9** - Sacs sales
- **B6** — Non conforme
+- **B6** - Non conforme
-Un commentaire est associé au statut et remonté dans le message d'interface
+Un commentaire est associé au statut.
-(STC) pour informer l'ERP.
+
 > ⚠️ **Mise à jour (LIM-90)** : le **STC est désactivé** (décision 30/04).
 > Pour les retours client, les statuts sont remontés dans le **REF** via
 > les balises ZLOG/ZINCO (codes SAP). Hors retour, seul le B6 remonte,
 > via le **LOC** (action R/U). Catalogue des 8 statuts + balises REF :
 > voir [Réception retour](../01-inbound/reception-retour.md#statuts-de-stock-retour-et-remontée-ref-lim-90).
 ### Attributs du statut de stock
@@ -112,23 +204,25 @@ Limagrain peut créer ses propres statuts de stock :
 - Menu « Données principales » → « Types de verrous » → « Statut de stock »
 - Bouton « Nouveau » → remplir les champs requis
-## Diagramme de séquence — Changement article
+## Diagramme de séquence - Changement article
 ```mermaid
 sequenceDiagram
    participant SAP
-    participant WMS as EasyWMS
+    participant WMS as EasyWMS (CST_CHG_WF)
-    SAP->>WMS: CHG (nouveau code article, description, destination)
+    SAP->>WMS: StartWorkflowCommand CST_CHG_WF (identité complète HU)
-    alt Stock non assigné
+    WMS->>WMS: Récupère HU + identifie la ligne de stock
-        WMS->>WMS: MAJ article sur les lignes de stock
+    alt HU et lignes libres de tout flux
-        Note over WMS: Pas de confirmation retour
+        WMS->>WMS: Applique article/propriétaire/destination (idempotent)
-    else Stock assigné à un processus
+        WMS-->>SAP: 200 (OK)
-        WMS->>SAP: ERR (changement impossible)
+    else HU/ligne engagée dans un flux, ou HU/ligne introuvable
        WMS->>WMS: Notification interne (gestionnaire)
        WMS-->>SAP: throw exception 500 (motif + table/flux)
    end
 ```
-## Diagramme de séquence — Changement statut (retour client)
+## Diagramme de séquence - Changement statut (retour client)
 ```mermaid
 sequenceDiagram
@@ -138,13 +232,25 @@ sequenceDiagram
    OP->>WMS: Changement statut (F9 ou B6) + commentaire
    WMS->>WMS: MAJ statut ligne de stock
-    WMS->>SAP: STC (notification changement statut)
+    WMS->>SAP: REF avec ZLOG/ZINCO à la clôture (LIM-90)
 ```
 > ⚠️ Diagramme mis à jour (LIM-90) : la remontée se fait via le **REF**
 > (balises ZLOG/ZINCO) à la clôture de la réception retour, **pas via
 > STC** (désactivé).
 ## Points d'attention
-⚠️ Le CHG ne renvoie pas de confirmation positive — seule l'erreur (ERR)
+⚠️ Le CHG renvoie **200** en cas de succès et **500** (throw exception) en
-est remontée si le changement échoue.
+cas de refus métier ou d'erreur. Le 500 n'est **pas** un plantage mais peut
 être un refus attendu (palette engagée dans un flux) - SAP doit lire le
 message pour savoir quoi débloquer avant de rejouer (LIM-113).
 ⚠️ Le **statut de stock est exclu du CHG** : il passe par le STR. Changer un
 attribut **et** le statut = **deux appels** distincts (CHG puis STR).
 ⚠️ Refus **tout ou rien** : une seule ligne engagée bloque l'intégralité du
 CHG sur la HU.
 ⚠️ Le changement de statut sur poste est limité au processus retour client
 (pas en picking ni en regroupement).
@@ -154,9 +260,21 @@ changement de statut initiées par SAP.
 ## Questions ouvertes
- [ ] Liste exhaustive des statuts de stock Limagrain prévus au démarrage (@Justine)
+- [x] ~~Liste exhaustive des statuts de stock Limagrain prévus au démarrage~~
- [ ] Liste des commentaires par statut — validée ? (@Justine)
+  → **Résolu** (LIM-90) : 8 statuts retour (F9 + 7 motifs B6), F2 = absence.
- [ ] CHG envoie-t-il un acquittement positif ou juste ERR en cas d'échec ? (@Nicolas)
+  → voir [Réception retour](../01-inbound/reception-retour.md#statuts-de-stock-retour-et-remontée-ref-lim-90)
 - [x] ~~Liste des commentaires par statut - validée ?~~ → **Résolu** (LIM-90) :
  libellés/motifs définis (ZINCO 0002-0008). Blocages à confirmer client.
 - [x] ~~CHG envoie-t-il un acquittement positif ou juste ERR en cas d'échec ? (@Nicolas)~~ → **Résolu** (LIM-113) : **200** en succès, **500** (throw exception) en refus/erreur ; pas d'acquittement négatif propre, le 500 véhicule le motif
 - Identification de la ligne de stock concernée dans la HU (une HU peut
  porter plusieurs lignes) : critère de comparaison des attributs reçus à
  préciser (@Vincent, commentaire 07/07)
 - Traitement **synchrone ou asynchrone / arrière-plan** des appels CHG pour
  tenir la volumétrie des clôtures (~1000 lignes) sans bloquer les flux 24/7
  (@Nicolas / Mecalux)
 - Liste **exhaustive** des tables/entités où une HU ou une ligne de stock
  peut être référencée/verrouillée (au-delà de la liste indicative ADB-117) -
  action développeur
 ## Historique des modifications
@@ -164,6 +282,8 @@ changement de statut initiées par SAP.
 |------|--------|--------------|
 | 2026-05-05 | Arthur | Création initiale depuis AF V1.5 |
 | 2026-05-06 | Arthur | Ajout section STR détaillée (CR consolidé ERP) |
 | 2026-07-17 | Arthur | LIM-90 : STC désactivé → remontée statuts retour via REF (ZLOG/ZINCO), diagramme corrigé, 2 questions statuts résolues (renvoi catalogue réception-retour) |
 | 2026-07-20 | Arthur | LIM-113 (lecture directe, En cours) : refonte complète de la section CHG - objectif/contexte (bascule propriétaire clôture fiscale FR10→FR02, règle d'or), mécanisme `StartWorkflowCommand`/`CST_CHG_WF` (identité complète), table des 9 champs JSON, statut exclu (STR séparé, 2 appels), logique WF en 5 étapes (récup HU + ID ligne, contrôle libre de flux façon ADB-117 sur HU/lignes, refus tout ou rien avec motif, idempotence, application), acquittement 200/500 (throw), notification interne, volumétrie clôtures ~1000 lignes + sync/async, cible 90/10 ; diagramme séquence CHG refondu ; points d'attention (200/500, statut exclu, tout ou rien) ; 1 question résolue (acquittement) + 3 nouvelles (ID ligne @Vincent, sync/async, liste exhaustive tables) ; front matter jira_refs +LIM-113/sources/tags/last_updated |
 ## Références
@@ -171,3 +291,7 @@ changement de statut initiées par SAP.
 |--------|------|------|
 | FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5 | Analyse fonctionnelle | 28/11/2025 |
 | CR CONSOLIDES REU ERP LIMAGRAIN V1 | CR ateliers interfaçage | 23/02/2026 |
 | [LIM-90](https://easywmsfrance.atlassian.net/browse/LIM-90) | Ticket Jira (statuts ZLOG/ZINCO) - revue de code terminée, préprod | 2026-06-03 |
 | [LIM-113](https://easywmsfrance.atlassian.net/browse/LIM-113) | Ticket Jira (flux API CHG, `CST_CHG_WF`) - En cours, revue fonctionnelle | 2026 |
 | ADB-117 | DevOps Athenza (logique `Count()` sur tables métier, réf. de reprise) | - |
 | DevOps 88942 | Work item Athenza (bsd-limagrain) | - |
@@ -1,16 +1,16 @@
 ---
-title: "Catalogue des messages ERP — Référence complète"
+title: "Catalogue des messages ERP - Référence complète"
 tags: [ERP, messages, interface, SAP, catalogue, ITM, ASN, ROR, ROF, REF, SOR, RUT, SOF, LOF, PCK, MOV, STV, STR, STC, SCR, WSC, COR, COF, LOC, ERR, CHG]
 status: draft
-standard_ref: architecture/erp-integration.md
+standard_ref: concepts/erp-interface.md
-jira_refs: []
+jira_refs: [LIM-113, LIM-117]
 confluence_refs: []
-sources: [FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5.docx, "Expédition - LIMAGRAIN - DEV - Confluence.md", "CR CONSOLIDES REU ERP LIMAGRAIN V1 - CR.md"]
+sources: [FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5.docx, "Expédition - LIMAGRAIN - DEV - Confluence.md", "CR CONSOLIDES REU ERP LIMAGRAIN V1 - CR.md", "Jira LIM-113 (lecture directe 2026-07-20)"]
-last_updated: 2026-05-06
+last_updated: 2026-07-20
 author: Arthur
 ---
-# Catalogue des messages ERP — Référence complète
+# Catalogue des messages ERP - Référence complète
 > **Résumé** : tableau de référence de tous les messages d'interface entre
 > SAP EWM et EasyWMS chez Limagrain, classés par domaine fonctionnel.
@@ -76,21 +76,21 @@ message.
 ## Messages custom détaillés
-### PCK — Passage Conteneur Client
+### PCK - Passage Conteneur Client
 - **Déclencheur** : stock préparé, passage en conteneur client EasyWMS
 - **Contenu** : information passage conteneur client
 - **Envoyé pour** : commande client, consommation OF hors recert, messagerie
 - **Voir** : [Flux ERP outbound](../04-outbound/flux-erp-outbound.md)
-### ~~MOV — Movement~~ ANNULÉ
+### ~~MOV - Movement~~ ANNULÉ
-> **ANNULÉ** — décision réunion client, jugé inutile.
+> **ANNULÉ** - décision réunion client, jugé inutile.
 - ~~**Déclencheur** : déplacement de stock entre palettes~~
 - ~~**Contenu** : palette d'origine, palette de destination, quantité~~
-### LOC — Message périodique (détaillé)
+### LOC - Message périodique (détaillé)
 - **Déclencheur** : Job toutes les 5 min → WF → transaction `LOC.SEND` → GNA
  (script BOO) → POST SAP-CPI
@@ -100,13 +100,13 @@ message.
 - **Quantités** : valeurs absolues (pas des écarts) sauf ACTION=S et T
 - **Exclusion** : palettes dont la réception n'est pas fermée (pas de REF)
 - **Approche technique** : fork du WSC avec filtre temporel sur CreationDate
- **Transport** : via GNA → SAP-CPI (OAuth 2.0 client_credentials) —
+- **Transport** : via GNA → SAP-CPI (OAuth 2.0 client_credentials) -
  code CPI : **ATH201**
 - **Voir** : [Spécification complète LOC](loc-message-periodique.md),
  [Intégration GNA → SAP-CPI](gna-sap-cpi.md),
  [Flux ERP outbound](../04-outbound/flux-erp-outbound.md)
-### STV — Variation de Stock (⚠️ DÉSACTIVÉ)
+### STV - Variation de Stock (⚠️ DÉSACTIVÉ)
 > ⚠️ **Décision 30/04/2026** : le STV est désactivé (post-processing coupé).
 > Le LOC devient le seul canal de notification des mouvements de stock vers SAP.
@@ -133,10 +133,10 @@ message.
  type "création de stock" (l'ERP n'autorise pas la création de stock par ce
  biais aujourd'hui)
 - **Raison désactivation** : Limagrain préfère des quantités absolues (LOC)
-  plutôt que des écarts +/- (STV) — si un message se perd, l'écart est
+  plutôt que des écarts +/- (STV) - si un message se perd, l'écart est
  définitivement perdu
-### STR — Demande de Changement de Stock
+### STR - Demande de Changement de Stock
 - **Direction** : ERP → WMS
 - **Cas d'usage** : changement de code article (produit SAP + description),
@@ -151,7 +151,7 @@ message.
  les cas de refus
 - **Voir** : [Mapping ERP-WMS](mapping-erp-wms.md)
-### COR — Demande d'Échantillonnage
+### COR - Demande d'Échantillonnage
 - **Direction** : ERP → WMS
 - **Usage** : **uniquement** pour les demandes d'échantillonnage (pas pour les
@@ -173,7 +173,7 @@ message.
  pour les ordres de sortie
 - **Voir** : [Échantillonnage](../03-picking/echantillonnage.md)
-### COF — Confirmation d'Échantillonnage
+### COF - Confirmation d'Échantillonnage
 - **Direction** : WMS → ERP
 - **Mapping** :
@@ -187,7 +187,7 @@ message.
 - **Point ouvert** : Limagrain doit confirmer si le COF sera traité côté ERP.
  Si non traité, risque de demandes en double.
-### WSC — Image de Stock Journalière
+### WSC - Image de Stock Journalière
 - **Direction** : WMS → ERP
 - **Rôle** : image de stock complète pour vérification de cohérence. Contient
@@ -199,21 +199,28 @@ message.
  fichier (volumétrie potentiellement élevée pour CPI)
 - **Déclenchement** : transaction `SCR.REQ` ou `STOCKSYNC.ASKED`
-### STC — Notification Changement de Statut (⚠️ DÉSACTIVÉ)
+### STC - Notification Changement de Statut (⚠️ DÉSACTIVÉ)
 > ⚠️ **Décision 30/04/2026** : le STC est désactivé. Les changements de statut
 > hors retour sont limités au B6 (blocage logistique standard) et sont couverts
 > par le LOC (action R/U). Les statuts des retours sont remontés dans le REF.
-### CHG — Changement article / propriétaire
+### CHG - Changement article / propriétaire (LIM-113)
- **Déclencheur** : modification article ou propriétaire dans SAP
+- **Déclencheur** : modification article / propriétaire / destination dans SAP
- **Contenu** : numéro de HU, lot officiel, code nouvel article, description,
+  (cas principal : bascule de propriétaire en clôture fiscale, ex. FR10→FR02),
-  destination, propriétaire Limagrain
+  sans mouvement physique de la palette
- **Contrainte** : le stock ne doit pas être assigné à un processus (sinon ERR)
+- **Mécanisme** : `StartWorkflowCommand` → WF custom `CST_CHG_WF` sur
- **Voir** : [Mapping ERP-WMS](mapping-erp-wms.md)
+  `CustomApplication` ; SAP envoie l'identité complète de la HU (9 champs :
  containerCode, ContainerTypeCode, productCode, Quantity, UnitOfMeasureCode,
  LotCode, Color=propriétaire, Source=description, Size=destination)
 - **Contrainte** : modification seulement si la HU et ses lignes ne sont
  engagées dans **aucun** flux (refus tout ou rien). **Statut de stock exclu**
  (passe par STR, appel séparé)
 - **Acquittement** : **200** en succès, **500** (throw exception) en refus/erreur
 - **Voir** : [Mapping ERP-WMS](mapping-erp-wms.md#message-chg---changement-article--propriétaire-lim-113)
-### API Lot SAP — Retours clients
+### API Lot SAP - Retours clients
 - **Déclencheur** : lot officiel inconnu lors d'un retour client
 - **Contenu (demande)** : lot officiel à vérifier
@@ -247,6 +254,11 @@ SAP → RUT → EasyWMS → (picking + chargement) → LOC (delta 5 min) → SAP
                                              → SOF → SAP (phase 2)
 ```
 > **Adresse de livraison (LIM-117)** : la liste de SOR d'un RUT n'expose pas
 > les champs d'adresse standard ; SAP la transmet dans le `CustomAttribute`
 > (Attribute1-7) de chaque SOR, mappé sur l'OS par un post-subscription WMS.
 > Détail : [Flux ERP outbound - Adresse de livraison](../04-outbound/flux-erp-outbound.md#custom-adresse-de-livraison-des-sor-de-tournée-lim-117).
 ### Consommation OF (SOR)
 ```
@@ -275,34 +287,35 @@ SAP → STR → EasyWMS → (MAJ stock) → LOC (delta 5 min) → SAP
 ## Points d'attention
-⚠️ **STV et STC désactivés** (décision 30/04/2026) — le LOC est le seul canal
+⚠️ **STV et STC désactivés** (décision 30/04/2026) - le LOC est le seul canal
 de notification des mouvements de stock vers SAP.
-⚠️ Le message CHG est rejeté (ERR) si le stock est assigné à un processus
+⚠️ Le message CHG (WF `CST_CHG_WF`) est **refusé** si la HU ou une de ses
-en cours.
+lignes est engagée dans un flux : refus **tout ou rien**, remonté en **500**
 (throw exception) avec le motif - pas un plantage mais un refus métier (LIM-113).
-⚠️ MOV, PCK sont **supprimés/remplacés** — le LOC couvre tous ces besoins.
+⚠️ MOV, PCK sont **supprimés/remplacés** - le LOC couvre tous ces besoins.
-⚠️ L'ASN envoie 1 palette par message (pas d'agrégation — permet suppression
+⚠️ L'ASN envoie 1 palette par message (pas d'agrégation - permet suppression
 individuelle en cas d'annulation).
 ⚠️ Le STR est refusé si la palette est assignée "client" ou en préparation.
 Le middleware GNA filtre les STV avec motif "STR" pour éviter les doublons
 (caduc si STV globalement désactivé).
-⚠️ Le COF n'est utile que si SAP le traite — sinon risque de demandes
+⚠️ Le COF n'est utile que si SAP le traite - sinon risque de demandes
 d'échantillonnage en double.
 ## Questions ouvertes
- [ ] Détail champ par champ de chaque message — document séparé à intégrer (@Arthur)
+- ❓ Détail champ par champ de chaque message - document séparé à intégrer (@Arthur)
- [ ] Format exact du message CHG (@Nicolas)
+- [x] ~~Format exact du message CHG (@Nicolas)~~ → **Résolu** (LIM-113) : `StartWorkflowCommand` / `CST_CHG_WF`, 9 champs JSON (voir [Mapping ERP-WMS](mapping-erp-wms.md#message-chg---changement-article--propriétaire-lim-113))
- [ ] Confirmer si le COF sera traité côté ERP (@Limagrain)
+- ❓ Confirmer si le COF sera traité côté ERP (@Limagrain)
- [ ] Vérifier capacité de traitement du WSC quotidien — volumétrie (@Limagrain)
+- ❓ Vérifier capacité de traitement du WSC quotidien - volumétrie (@Limagrain)
- [ ] Confirmer retour fournisseur : SOR simple ou RUT ? (@Limagrain)
+- ❓ Confirmer retour fournisseur : SOR simple ou RUT ? (@Limagrain)
- [ ] Effets de bord désactivation STV — lister toutes les transactions
+- ❓ Effets de bord désactivation STV - lister toutes les transactions
  STK.ADJ et vérifier couverture LOC (@Mecalux)
- [ ] Effets de bord désactivation STC — idem pour CST.STK (@Mecalux)
+- ❓ Effets de bord désactivation STC - idem pour CST.STK (@Mecalux)
 ## Historique des modifications
@@ -311,6 +324,8 @@ d'échantillonnage en double.
 | 2026-05-05 | Arthur | Création initiale depuis AF V1.5 |
 | 2026-05-05 | Arthur | MOV annulé, LOC détaillé (5 min, delta, structure JSON, flag client) |
 | 2026-05-06 | Arthur | Enrichissement complet depuis CR consolidé ERP (STV, STR, COR/COF, WSC, flux supprimés, désactivation STV/STC) |
 | 2026-07-20 | Arthur | LIM-113 : refonte entrée CHG (mécanisme `StartWorkflowCommand`/`CST_CHG_WF`, 9 champs, refus tout ou rien, statut exclu, acquittement 200/500) ; point d'attention CHG mis à jour ; question « format CHG » résolue ; front matter jira_refs/sources/last_updated |
 | 2026-07-20 | Arthur | LIM-117 (LOT 2.1, Ouvert) : note « Adresse de livraison » sur le flux RUT (adresse dans `CustomAttribute` des SOR, mapping post-subscription vers l'OS) + renvoi vers flux-erp-outbound.md ; jira_refs +LIM-117 |
 ## Références
@@ -1,11 +1,11 @@
 ---
-title: "Administration — Vue d'ensemble"
+title: "Administration - Vue d'ensemble"
 tags: [admin, rbac, ad, index]
 status: draft
 last_updated: 2026-05-05
 ---
-# Administration — Vue d'ensemble
+# Administration - Vue d'ensemble
 > **Périmètre** : gestion utilisateurs et groupes, paramètres projet,
 > éléments AD customs.
@@ -1,116 +1,239 @@
 ---
-title: "AD Customs — Éléments personnalisés"
+title: "AD Customs - Custom Attributes"
-tags: [admin, AD, customs, CstAtt, Container]
+tags: [admin, AD, customs, CstAtt, référentiel]
 status: draft
-standard_ref: concepts/application-dictionary.md
+standard_ref: architecture/application-dictionary.md
-jira_refs: [LIM-14]
+jira_refs: [LIM-14, LIM-64, LIM-66, LIM-67, LIM-70, LIM-71, LIM-73, LIM-76, LIM-82, LIM-84, LIM-91, LIM-96, LIM-106, LIM-111, LIM-112, LIM-114, LIM-115]
 confluence_refs: []
-sources: ["recap_session_LIM-72_13-05-2026.md"]
+sources: ["Jira LIM-14 (lecture directe 2026-07-17)", "recap_session_LIM-72_13-05-2026.md"]
-last_updated: 2026-05-13
+last_updated: 2026-07-17
 author: Arthur
 ---
-# AD Customs — Éléments personnalisés
+# AD Customs - Custom Attributes
-> **Résumé** : inventaire des Custom Attributes (CstAtt) et éléments AD
+> **Résumé** : inventaire centralisé des Custom Attributes (CstAtt) par
-> personnalisés pour le projet Limagrain. Référence centralisée pour le
+> entité pour le projet Limagrain. Référentiel maître =
-> développement et la maintenance.
+> [LIM-14](https://easywmsfrance.atlassian.net/browse/LIM-14).
 > **Standard EasyWMS** : → voir
-> [Application Dictionary](../../concepts/application-dictionary.md)
+> [Application Dictionary](../../architecture/application-dictionary.md)
 > Ce qui suit documente les **personnalisations Limagrain**.
 > **Séquences, toggles, jobs et paramètres** : voir
 > [Paramètres projet](parametres-projet.md).
 ## Contexte projet
-Le projet Limagrain utilise de nombreux CstAtt sur les entités
+Le projet Limagrain utilise de nombreux CstAtt sur les entités Article,
-Container, Réception, Stock et OE pour piloter les flux customs
+Support (Container), Stock, Ordre d'entrée, Réception, Tâche, etc. pour
-(réception, picking, clôture, etc.). Cette page centralise le mapping
+piloter les flux customs (réception, picking, clôture, anoxie,
-complet pour éviter les conflits et faciliter la maintenance.
+recertification). Cette page reflète le catalogue [LIM-14](https://easywmsfrance.atlassian.net/browse/LIM-14)
 et sert de référence unique pour éviter les conflits d'allocation.
-## CstAtt Container (support / palette)
+## CstAtt Article
-Source : [LIM-14](https://easywmsfrance.atlassian.net/browse/LIM-14)
+Attributs descendus de SAP sur la fiche article. Affichage dans la vue
 des articles **corrigé le 2026-05-18** (colonnes / types).
-| CstAtt | Donnée | Type | Tâche | Statut |
+| CstAtt | Donnée | Type |
-|--------|--------|------|-------|--------|
+|--------|--------|------|
-| 01 | Big-bag potentiel (réception contient big-bag) | bool | LIM-64 | Utilisé |
+| 01 | Espèce | string |
-| 02 | Contient big-bag | bool | LIM-67 | Utilisé |
+| 02 | Génération | string |
-| 03 | À anoxier | bool | LIM-67 | Utilisé |
+| 03 | Variété | string |
-| 04 | Support ASN | bool | LIM-64 | Utilisé |
+| 04 | Big-Bag | bool |
-| 05 | Programme de filmage | int | LIM-67 | Utilisé |
+| 05 | GTIN | string |
-| 06 | Code PK assigné | string | LIM-70 | Utilisé |
+| 06 | Semence essais | string |
-| 07 | Date fin d'anoxie | datetime | — | Utilisé |
+| 07 | Calibre | string |
-| 08 | Code réception (conteneur virtuel) | string | — | Utilisé |
+| 08 | Zone de production au champ | string |
-| 09 | CERTIFICATION (fausse palette) | string | — | Utilisé |
+| 09 | Marque | string |
-| 10 | Réception en cours au PK | bool | — | Utilisé |
+| 10 | Stage | string |
 | 11 | Rangé ASRS après réception | bool | LIM-73 | Utilisé |
 | 12 | **Proposé** : code OE associé | string | LIM-64 (évol.) | Libre |
 | 13 | Étiquetée au PK | bool | LIM-XX | À réserver |
 | 14-20 | — | — | — | **Libres** |
-> **Proposition CstAtt12** : stocker le code OE (association palette ↔
+## CstAtt Support (Container / palette)
 > ordre d'entrée) dès l'image de quai. Permettrait de pré-remplir la
 > sélection de réception au PK (LIM-72) et d'optimiser le routage AGV
 > (LIM-70). Impact planning à évaluer — reporté après réponses aux
 > questions ouvertes.
-> **CstAtt13 — Étiquetée au PK** : flag utilisé par l'étiqueteuse
+| CstAtt | Donnée | Type | Tâche | Affiché (vue support) |
-> automatique au poste de sortie TK pour éviter une ré-impression.
+|--------|--------|------|-------|-----------------------|
-> Valeurs : `true` = déjà étiquetée au PK (l'étiqueteuse auto
+| 01 | Palette dans une réception contenant ≥ 1 big-bag | bool | LIM-64 | « Big-bag potentiel » |
-> n'imprime pas), `false` = pas encore étiquetée, `error` = impression
+| 02 | Palette contenant un big-bag | bool | LIM-67 | « Big-bag » |
-> échouée. Vérifier avec LIM-14 qu'il n'y a pas de conflit avec le
+| 03 | À anoxier | bool | LIM-67 | « A anoxier » |
-> CstAtt12 proposé.
+| 04 | Support ASN | bool | LIM-64 | « ASN » |
 | 05 | Programme de filmage | int | LIM-67 / 115 | « Filmage » |
 | 06 | Code du PK assigné | string | LIM-70 | « PK assigné » |
 | 07 | Date de fin d'anoxie | datetime | - | « Dernière anoxie » |
 | 08 | Code de la réception (conteneur virtuel) | string | - | Vue support |
 | 09 | CERTIFICATION (fausse palette pour certification) | string | - | - |
 | 10 | En cours de réception au PK | bool | - | « Réception en cours » |
 | 11 | Rangé ASRS après réception | bool | LIM-73 | « Rangé ASRS » |
 | 12 | Conteneur étiqueté | bool | LIM-71 | - |
 | 13 | Ordre d'entrée (code OE du conteneur) | string | LIM-96 | « Ordre d'entrée » |
 | 14 | Palette étiquetée au PK | string | LIM-91 / 111 | - |
-## CstAtt Réception
+> **CstAtt05** - Programme de filmage. Posé au poste par LIM-67 (choix
 > opérateur : `0`/`A`…`H` selon le paramètre `FILMAGES`). **Lu et transmis à
 > Galileo par LIM-115** (recopié dans le CustomData de la tâche à la création
 > d'un mouvement de source PIE_02 → pilotage de la filmeuse ; forcé à `0` si
 > vide, « pas de filmage », ou destination de rejet). Voir
 > [Configuration Galileo - Transmission du filmage](../02-stockage/galileo-config.md#transmission-du-programme-de-filmage-à-la-filmeuse-lim-115).
 > ⚠️ LIM-14/LIM-67 typent `int` alors que les codes sont alphanumériques
 > (`0`, `A`…) - à confirmer (probable `string`).
-| CstAtt | Donnée | Type | Tâche |
+> **CstAtt06** - Code du PK assigné (LIM-70). Conflit d'usage historique
-|--------|--------|------|-------|
+> avec LIM-71 **résolu** : LIM-71 a abandonné son marquage CstAtt06
-| 01 | Flag clôture en cours (retours) | bool | LIM-73 |
+> (destination désormais via stratégies de rangement). CstAtt06 = code du
 > PK lié uniquement.
 > **Usage rejet PIE (LIM-114)** : lu comme **poste d'origine** pour renvoyer
 > une palette rejetée au PIE. Doit être **reporté sur le support réel** (posé
 > au PK par LIM-67 en réception, par LIM-91 sur la palette source picking) ;
 > s'il est vide, le support est traité comme production → `PK_REJET_PROD`.
 > Voir [Flux de rejet PIE](../02-stockage/rejet-pie.md).
-Voir [Réception retour — Clôture](../01-inbound/reception-retour.md)
+> **CstAtt12** - Conteneur étiqueté. En **LIM-96 V2**, il est posé à
-pour le détail du mécanisme.
+> `true` à l'écran « validation du collage des étiquettes » (déclaration
 > image de quai) pour **toutes** les palettes de la réception, y compris
 > celles sans étiquette (production / piles). Il conditionne la prise en
 > charge par le job AGV **LIM-71** (déplacement uniquement si
 > `CstAtt12 = true`).
 > ⚠️ À réconcilier avec la
 > [page LIM-71](../05-agv/job-reception-production.md) qui indiquait que
 > la condition `CstAtt12` avait été retirée du job (voir
 > [Questions ouvertes](../08-transverse/questions-ouvertes.md)).
-## CstAtt OE (InboundOrder)
+> **CstAtt13** - Code de l'ordre d'entrée du conteneur. Posé **dès
 > l'image de quai** par l'écran « déclaration des OE » de
 > [LIM-96 V2](../01-inbound/gestion-camions.md) (rattachement de chaque
 > emplacement occupé à son OE), en plus du renseignement au PK par le flux
 > LIM-67. LIM-14 le rattache à LIM-96. Voir
 > [Gestion des camions](../01-inbound/gestion-camions.md) et
 > [Réception fournisseur](../01-inbound/reception-fournisseur.md).
-| CstAtt | Donnée | Type | Tâche |
+> **CstAtt14** - Palette étiquetée au PK. String à **3 valeurs**
-|--------|--------|------|-------|
+> (`true` / `false`|vide / `error`). Posé au PK (LIM-91), **lu et mis à
-| 01 | Hors tolérance (au moins 1 ligne OE hors tolérance) | bool | LIM-73 |
+> jour à l'étiqueteuse automatique de sortie TK** (LIM-111 : `true` si
-
+> impression OK, `error` si échec). Il ne conditionne que la
-Voir [Réception fournisseur — Clôture](../01-inbound/reception-fournisseur.md).
+> **ré-impression de l'étiquette de picking** (HU RFID, LIM-68) :
 > `true` ⇒ pas de ré-impression. L'**étiquette d'expédition** (LIM-107)
 > s'imprime dans tous les cas (sauf palette trop basse), indépendamment de
 > ce flag. Réservé dans LIM-14.
 > Voir [Process picking au PK](../03-picking/process-picking-pk.md) et
 > [Flux expédition - Étiqueteuse automatique](../04-outbound/flux-expedition.md#étiqueteuse-automatique).
 ## CstAtt Stock (StockLine)
-Les CstAtt stock portent principalement les attributs logistiques
+| CstAtt | Donnée | Type | Tâche | Affiché |
-descendus de SAP. Voir
+|--------|--------|------|-------|---------|
-[Données principales](../06-erp-interface/donnees-principales.md)
+| 01 | Poids unitaire produit recalculé | décimal | LIM-66 | Vue stock |
-pour le mapping détaillé.
+| 02 | SSCC virtuelle palette MII | string | LIM-91 | Vue stock |
 Les autres attributs logistiques descendus de SAP sont détaillés dans
 [Données principales](../06-erp-interface/donnees-principales.md).
 ## CstAtt Ordre d'entrée (InboundOrder)
 | CstAtt | Donnée | Type | Tâche | Affiché |
 |--------|--------|------|-------|---------|
 | 01 | Hors tolérance (≥ 1 ligne OE hors tolérance) | bool | LIM-73 | Vue OE - « Hors tolérance » |
 Voir [Réception fournisseur - Clôture](../01-inbound/reception-fournisseur.md).
 ## CstAtt Réception
 | CstAtt | Donnée | Type | Tâche | Affiché |
 |--------|--------|------|-------|---------|
 | 01 | Réception retour entièrement rangée ASRS (flag « clôture en cours ») | bool | LIM-73 | Vue réceptions - « Rangé ASRS » |
 Voir [Réception retour - Clôture](../01-inbound/reception-retour.md).
 ## CstAtt Ligne d'ordre d'inventaire
 | CstAtt | Donnée | Type | Tâche | Affiché |
 |--------|--------|------|-------|---------|
 | 01 | Nombre de palettes à échantillonner | int | LIM-112 | Vue ordres d'inventaire, modifiable |
 | 02 | Consignes (texte libre rattaché à l'ordre) | string | LIM-112 | Vue ordres d'inventaire |
 > LIM-14 indique le type « Booléen » pour le CstAtt01 alors que la donnée
 > est un nombre modifiable - à confirmer (probable `int`). LIM-112 confirme
 > l'usage : `CstAtt01` = nombre de palettes à échantillonner (valeur du COR,
 > toujours 4 d'après SAP ; éditable en création manuelle tant que
 > l'inventaire n'est pas lancé), `CstAtt02` = consignes.
 > ⚠️ Le commentaire du ticket LIM-112 évoque les consignes sur `CstAtt01` :
 > à confirmer avec le client (voir
 > [Échantillonnage](../03-picking/echantillonnage.md#questions-ouvertes)).
 ## CstAtt Stratégies de rangement
 | CstAtt | Donnée | Type | Tâche | Affiché |
 |--------|--------|------|-------|---------|
 | 01 | Anoxie | bool | - | Vue stratégies de rangement - « Anoxie » |
 ## CstAtt Status de stock
 | CstAtt | Donnée | Type | Tâche | Affiché |
 |--------|--------|------|-------|---------|
 | 01 | Applicable en réception type retour | bool | - | « Applicable en réception » |
 | 02 | ZLOG (code SAP) | texte | - | « ZLOG » |
 | 03 | ZINCO (code SAP) | texte | - | « ZINCO » |
 Utilisés par l'entité `CST_StockStatus`. Catalogue des 8 statuts retour
 (F9 + 7 motifs B6, F2 = absence de statut) et remontée REF ZLOG/ZINCO
 définis en LIM-90 : voir
 [Réception retour](../01-inbound/reception-retour.md#statuts-de-stock-retour-et-remontée-ref-lim-90).
 ## CstAtt Tâche (Task)
 | CstAtt | Donnée | Type | Tâche | Affiché |
 |--------|--------|------|-------|---------|
 | 01 | Numéro de séquence picking | int | LIM-84 | - |
 | 02 | Tâche créée pour le process de recertification | bool | LIM-106 | Vue des tâches - « Recertification » |
 | 03 | Conteneur de picking a passé la navette | bool | LIM-84 / LIM-82 | - |
 | 04 | Code support fille picking négatif | string | LIM-76 | - |
 ## CstAtt OS (OutboundOrder / ShippingOrder)
 | CstAtt | Donnée | Type | Tâche |
 |--------|--------|------|-------|
-| CstAtt | Verrou séquençage TK (blocage stacker crane) | bool | LIM-84 |
+| - | Verrou séquençage TK (blocage stacker crane) | bool | LIM-84 |
-Voir [Séquençage TK → PS](../03-picking/sequencage-tk-ps.md).
+> Non listé explicitement dans LIM-14 ; le séquençage picking figure sous
 > CstAtt Tâche (01/03, LIM-84). Voir
 > [Séquençage TK → PS](../03-picking/sequencage-tk-ps.md).
 ## Points d'attention
-⚠️ Les CstAtt Container 14-20 sont libres. Tout nouvel usage doit être
+⚠️ Le référentiel maître est [LIM-14](https://easywmsfrance.atlassian.net/browse/LIM-14).
-documenté ici et dans LIM-14.
+Tout nouvel usage de CstAtt doit y être déclaré **avant** d'être
 documenté ici.
-⚠️ Le CstAtt11 Container est posé une seule fois (rangement ASRS) et
+⚠️ Le CstAtt11 Support est posé une seule fois (rangement ASRS) et n'est
-n'est jamais remis à false, même si le support ressort ensuite.
+jamais remis à false, même si le support ressort ensuite.
 ⚠️ Renumérotation Support 12/13/14 : l'ancienne allocation (13 =
 « Étiquetée au PK ») est obsolète. Depuis LIM-14 : 12 = Conteneur
 étiqueté, 13 = Ordre d'entrée, 14 = Palette étiquetée au PK.
 ## Historique des modifications
 | Date | Auteur | Modification |
 |------|--------|-------------|
-| 2026-05-13 | Arthur | Création avec table CstAtt Container complète depuis LIM-14 |
+| 2026-05-13 | Arthur | Création avec table CstAtt Container depuis LIM-14 |
 | 2026-05-13 | Arthur | Réservation CstAtt13 Container pour flag étiquetage PK |
 | 2026-07-17 | Arthur | Réalignement complet sur LIM-14 (lecture directe) : ajout entités Article, Stock, Ligne inventaire, Stratégies rangement, Status stock, Tâche ; Support étendu à 14 (12 = Conteneur étiqueté, 13 = Ordre d'entrée, 14 = Palette étiquetée au PK) ; renvoi séquences/jobs/paramètres → parametres-projet.md |
 | 2026-07-17 | Arthur | LIM-96 V2 : note CstAtt12 (posé `true` à l'écran collage étiquettes, gate job LIM-71 + caveat réconciliation) et CstAtt13 (posé dès l'image de quai via l'écran déclaration OE, en plus du PK) |
 | 2026-07-17 | Arthur | CstAtt Tâche 03 (passage navette) : ajout attribution LIM-82 (flag posé par les handlers `Container_MovedEventHandler_ET/MS_PR`) |
 | 2026-07-20 | Arthur | CstAtt Tâche 02 (recertification) : attribution LIM-106 (flag posé sur les tâches de mouvement recertification). Note : déplacé du CstAtt01 vers 02 (Maxime 26/06), le 01 étant la séquence picking LIM-84 |
 | 2026-07-20 | Arthur | CstAtt14 Support : précisions LIM-111 (lu/mis à jour à l'étiqueteuse de sortie TK, 3 valeurs, conditionne uniquement la ré-impression de l'étiquette de picking LIM-68, pas l'étiquette d'expédition LIM-107 ; réservé LIM-14) + attribution LIM-91 / 111 dans la table |
 | 2026-07-20 | Arthur | CstAtt Ligne d'ordre d'inventaire : ajout CstAtt02 (consignes, LIM-112) + attribution LIM-112 au CstAtt01 (nb palettes à échantillonner) + note usage LIM-112 (caveat commentaire consignes CstAtt01 vs 02) |
 | 2026-07-20 | Arthur | CstAtt06 Support : note usage rejet PIE (LIM-114 - poste d'origine lu pour la destination de rejet, reporté sur le support réel par LIM-67/LIM-91) ; jira_refs +LIM-114 |
 | 2026-07-20 | Arthur | CstAtt05 Support : note usage LIM-115 (transmis à Galileo/filmeuse via CustomData de tâche sur mouvement source PIE_02, forcé 0 si vide/pas de filmage/rejet) + caveat type int vs code alphanumérique ; table 05 → LIM-67 / 115 ; jira_refs +LIM-115 |
 ## Références
 | Source | Type | Date |
 |--------|------|------|
-| [LIM-14](https://easywmsfrance.atlassian.net/browse/LIM-14) | Ticket Jira | 2025 |
+| [LIM-14](https://easywmsfrance.atlassian.net/browse/LIM-14) | Ticket Jira (référentiel CstAtt/séquences/jobs/paramètres) | 2026 |
 | [LIM-82](https://easywmsfrance.atlassian.net/browse/LIM-82) | Ticket Jira (placement PS → PK, pose CstAtt Tâche 03) | 2026 |
 | [LIM-106](https://easywmsfrance.atlassian.net/browse/LIM-106) | Ticket Jira (assignation recertification, pose CstAtt Tâche 02) | 2026 |
 | [LIM-111](https://easywmsfrance.atlassian.net/browse/LIM-111) | Ticket Jira (étiqueteuse auto, lecture/MAJ CstAtt14 à la sortie TK) | 2026 |
 | [LIM-112](https://easywmsfrance.atlassian.net/browse/LIM-112) | Ticket Jira (échantillonnage, CstAtt01/02 ligne d'ordre d'inventaire) | 2026 |
 | [LIM-114](https://easywmsfrance.atlassian.net/browse/LIM-114) | Ticket Jira (rejet PIE, CstAtt06 = poste d'origine) | 2026 |
 | [LIM-115](https://easywmsfrance.atlassian.net/browse/LIM-115) | Ticket Jira (transmission filmage, CstAtt05 → Galileo) | 2026 |
 | recap_session_LIM-72_13-05-2026.md | Récap session | 2026-05-13 |
@@ -2,10 +2,11 @@
 title: "Contacts projet Limagrain"
 tags: [admin, contacts, équipe, annuaire]
 status: draft
 standard_ref: null
 jira_refs: []
 confluence_refs: []
 sources: ["Liste de contacts.md"]
-last_updated: 2026-05-06
+last_updated: 2026-07-20
 author: Arthur
 ---
@@ -24,7 +25,7 @@ author: Arthur
 | Jean-Baptiste ROUVET | jean-baptiste.rouvet@limagrain.com | CDP OT |
 | Thierry CHANNEBOUX | thierry.channeboux@limagrain.com | CPG |
 | Nicolas SANCHEZ | nicolas.sanchez@limagrain.com | Expert IT |
-| Alexandre COUTURIER | alexandre.couturier@limagrain.com | — |
+| Alexandre COUTURIER | alexandre.couturier@limagrain.com | - |
 | Leila CHAJJAOUI | leila.chajjaoui@limagrain.com | Experte IT (équipe Nicolas SANCHEZ) |
 | Maxime TOURRETTE | maxime.tourrette@limagrain.com | Développeur IT Expert |
 | Anne-Marie LARIVAILLE | anne-marie.larivaille@limagrain.com | Experte processus métier logistique |
@@ -35,7 +36,7 @@ author: Arthur
 | Nom | Mail | Poste |
 |-----|------|-------|
-| Brice FOLIO | ext-brice.folio@limagrain.com | — |
+| Brice FOLIO | ext-brice.folio@limagrain.com | - |
 | Cyril MALLET | ext-cyril.mallet@limagrain.com | Responsable Infra (gestion VM) |
 ## Delaware (Middleware SAP)
@@ -49,7 +50,7 @@ author: Arthur
 | Nom | Mail | Poste |
 |-----|------|-------|
 | Yann RODRIGUES | Yann.RODRIGUES@still.fr | Ingénieur commercial |
-| — | broumegoux@ceres-solutions.com | Responsable chantier (Bâtiment) |
+| - | broumegoux@ceres-solutions.com | Responsable chantier (Bâtiment) |
 | Vincent DOITEAU | vincent.doiteau@kiongroup.com | Expert technique AGV |
 ## Mecalux
@@ -59,7 +60,7 @@ author: Arthur
 | Justine BEUTIN | DP WMS |
 | Mallaury MELGAR | CPG |
 | Théo LE PAIH | CPG |
-| Abdallah BOUALLAG | — |
+| Abdallah BOUALLAG | - |
 | Hedi ABDELKRIM | Resp. Automatisme |
 | Robert Bryan BRAVO BALSECA | Technique ROB Espagne |
 | Gilles MAILLET | Dir. ROB |
@@ -0,0 +1,135 @@
 ---
 title: "Paramètres projet - Séquences, toggles, jobs et paramètres WMS"
 tags: [admin, paramètres, séquences, jobs, toggles, transactions]
 status: draft
 standard_ref: architecture/application-dictionary.md
 jira_refs: [LIM-14, LIM-64, LIM-67, LIM-69, LIM-70, LIM-71, LIM-73, LIM-74, LIM-76, LIM-93, LIM-102, LIM-105, LIM-107, LIM-108, LIM-110, LIM-114, LIM-115]
 confluence_refs: []
 sources: ["Jira LIM-14 (lecture directe 2026-07-17)", "Jira LIM-102 (lecture directe 2026-07-20)", "Jira LIM-114 (lecture directe 2026-07-20)", "Jira LIM-115 (lecture directe 2026-07-20)"]
 last_updated: 2026-07-20
 author: Arthur
 ---
 # Paramètres projet - Séquences, toggles, jobs et paramètres WMS
 > **Résumé** : référentiel des séquences, toggles, transactions customs,
 > paramètres (standards et customs) et jobs périodiques du projet
 > Limagrain. Source maître =
 > [LIM-14](https://easywmsfrance.atlassian.net/browse/LIM-14).
 > **Standard EasyWMS** : → voir
 > [Application Dictionary](../../architecture/application-dictionary.md) et
 > [Parameters](../../concepts/parameters.md)
 > Ce qui suit documente les **spécificités Limagrain** par rapport au standard.
 > **Custom Attributes** : voir [AD Customs](ad-customs.md).
 ## Séquences
 | Code | Préfixe | Cache | Min | Max | Tâche | Info |
 |------|---------|-------|-----|-----|-------|------|
 | 800000 | 800 | 200 | 1 | 999 999 999 999 999 | LIM-64 | Supports virtuels images de quai |
 | Pile | PAL | 200 | 1 | 999 999 999 999 999 | LIM-64 | Supports pile de palettes |
 ## Toggles
 | Nom du toggle | État |
 |---------------|------|
 | `AllowExceedMaxNumContainersInBufferLocation` | Désactivé |
 | `CST_LogWebServiceCommunication` | Non précisé |
 | `CST_SimulatePIEScale` | [SIMULATION] Actif en pré-production (LIM-108) - repli sur le poids théorique quand l'event PIE ne porte pas de poids. Voir [Contrôle qualité réception](../01-inbound/controle-qualite-reception.md#simulation-poids-théorique-en-labsence-de-poids-galileo-lim-108) |
 ## Paramètres standards
 | Paramètre | Description | Valeur |
 |-----------|-------------|--------|
 | `IsSingleReceipt` | Une seule réception par OE (pas de reliquat WMS) | `true` |
 | `AutoCloseReception` | Clôture automatique de la réception | `true` |
 > **Note** : valeur `true` confirmée par Arthur (2026-07-17). Le tableau
 > LIM-14 affiche encore `false` - **à corriger côté ticket**. La clôture
 > effective reste conditionnée par le custom `Reception_Close_PR_V2`. Voir
 > [Réception fournisseur - Clôture](../01-inbound/reception-fournisseur.md).
 ## Transactions customs
 | Code | Description | Post-traitement |
 |------|-------------|-----------------|
 | `CON.CREATE.RECEP` | Conteneur créé par le process de réception (LIM-96). `Document1` = type de réception (KPI par type, LIM-102 - voir [Gestion des camions](../01-inbound/gestion-camions.md#kpi---conteneurs-par-type-de-réception-lim-102)) | Non |
 | `LOC.SEND` | Message LOC envoyé toutes les 5 minutes | Oui |
 ## Paramètres customs
 | Code | Info | Valeur par défaut | Tâche |
 |------|------|-------------------|-------|
 | `FILMAGES` | Programmes de filmage | - | LIM-67 |
 | `MODES_PK01` … `MODES_PK06` | Modes de travail actifs du PK avec séquence (ex. `RECEPTION;1\|PICKING;2\|CONSOLIDATION;3`) | - | LIM-69 |
 | `PK_ADJACENT` | Paires de postes adjacents | - | LIM-69 |
 | `PK_BIGBAG` | Liste des PK compatibles big-bag (séparés par `;`) | - | LIM-70 / LIM-74 |
 | ~~`DESTINATION_PRODUCTION`~~ | ~~Code du buffer d'entrée production (destination des tâches AGV)~~ **obsolète** | ~~`ENTREE_PRODUCTION`~~ | LIM-71 |
 | `RECEPTION_POSITION_CONTAINER_PK` | Position (X) destination préférée des conteneurs de réception au PK | `2` | - |
 | `RECERTIFICATION_POSITION_CONTAINER_PK` | Position (X) destination préférée des conteneurs de recertification au PK | `2` | - |
 | `PIE_ENTRY_PK` | N° du PIE pour réinsérer les palettes après passage PK | `2` | LIM-67 |
 | `PK_REJET_PROD` | Poste de rejet des palettes **sans poste d'origine** (production) au rejet PIE. À câbler côté EST (ex. `PS01`) - voir [Flux de rejet PIE](../02-stockage/rejet-pie.md) | (à définir) | LIM-114 |
 | `PIE_FILMAGE` (nom à confirmer) | Stations sources déclenchant la transmission du programme de filmage à Galileo (rejet du code en dur) - voir [Configuration Galileo](../02-stockage/galileo-config.md#transmission-du-programme-de-filmage-à-la-filmeuse-lim-115) | `PIE_02` | LIM-115 |
 | `LOC_ZONE_MAPPING` | Zones de correspondance Easy ↔ SAP pour les TK | `[TK03-04:ASRS34][TK01:ASRS1][TK02:ASRS2][TK03:ASRS3][TK04:ASRS4]` | LIM-76 |
 | `EXPEDITION_CLASSE_CLIENT` | Code de la classe d'OS pour le type client | `CLIENT` | LIM-107 |
 | `EXPEDITION_CLASSE_PRODUCTION` | Code de la classe d'OS pour le type production | `PRODUCTION` | LIM-107 |
 | `SAP_CPI_ENDPOINT_URL` | URL de l'endpoint inbound SAP CPI | (à définir) | LIM-93 |
 | `SAP_CPI_TOKEN_URL` | URL du token endpoint OAuth 2.0 SAP CPI | - | LIM-93 |
 | `SAP_ATH214_TIMEOUT` | Timeout d'attente de l'ITM après appel ATH214 (s) | `60` | LIM-93 |
 | `SAP_ATH214_MAX_RETRIES` | Nombre maximum de tentatives ATH214 | `5` | LIM-93 |
 | `SAP_ATH214_REFRESH_INTERVAL` | Intervalle de polling de l'alias en base (ms) | `5000` | LIM-93 |
 | `RECEPTION_CONFORM_STOCK_STATUS` | Nom du statut de stock fictif « Stock conforme » (position 0 du dialogue statut, n'applique aucun statut) | - | LIM-93 |
 | `SAP_ATH111_TIMEOUT` | Timeout d'attente de l'ASN (process recertification, s) | `60` | LIM-105 |
 | `SAP_ATH111_MAX_RETRIES` | Nombre maximum de tentatives d'attente de l'ASN (recertification) | `5` | LIM-105 |
 | `SAP_ATH111_REFRESH_INTERVAL` | Intervalle de polling de l'existence de l'ASN (recertification, ms) | `500` | LIM-105 |
 | `RECERTIFICATION_CODE_CLASSE` | Code de la classe d'OS recertification (remplace les valeurs hard codées d'identification) | - | LIM-105 |
 | `RECERTIFICATION_CODE_QUAI` | Code du quai recertification (`QUAI_RECERTIFICATION`) assigné automatiquement aux OS recertification ; sert aussi de balise `[XXX]` dans le code de la stratégie d'assignation de stock RECERTIFICATION | - | LIM-110 |
 ## Jobs
 | Code | Workflow | Description | Fréquence | Tâche |
 |------|----------|-------------|-----------|-------|
 | `CST_PickingStationAssignmentJob` | `CST_PickingStationAssignment_Job` | Assignation des ordres par priorité de process aux PK | 5 s | LIM-70 |
 | `CST_StoreProductionContainer` | `CST_StoreProductionContainer_Job` | Génère les tâches de rangement des conteneurs sur images de quai | 30 s | LIM-71 |
 | `CST_SendLOCTransaction` | `CST_SendLOC` | Envoie la transaction `SEND.LOC` | 5 min | LIM-76 |
 | `CST_AssignDockStage` | `CST_Job_AssignStage` | Assigne les images de quai (stages `X_EXP`) aux OS et tournées éligibles | 30 s | LIM-94 |
 | `CST_Reception_RegenerateTask_Job` | `CST_Reception_RegenerateTask_Job` | Régénère les tâches vers les PK pour les palettes de réception sur stages sans tâches | 15 s | LIM-71 |
 ## Points d'attention
 ⚠️ Le référentiel maître est [LIM-14](https://easywmsfrance.atlassian.net/browse/LIM-14).
 Tout nouveau paramètre / job / séquence doit y être déclaré.
 ⚠️ `PK_BIGBAG` apparaît deux fois dans LIM-14 (rattaché à LIM-70 puis
 LIM-74) - même paramètre, à dédoublonner côté ticket.
 ⚠️ `DESTINATION_PRODUCTION` est **obsolète** (LIM-71 : destination via
 stratégies de rangement).
 ## Historique des modifications
 | Date | Auteur | Modification |
 |------|--------|-------------|
 | 2026-07-17 | Arthur | Création depuis LIM-14 (lecture directe) : séquences, toggles, paramètres standards + customs, transactions customs, jobs |
 | 2026-07-20 | Arthur | Enrichissement transaction `CON.CREATE.RECEP` : `Document1` = type de réception (KPI par type, LIM-102) + cross-ref gestion-camions ; jira_refs/sources/last_updated |
 | 2026-07-20 | Arthur | Ajout paramètre `RECERTIFICATION_CODE_CLASSE` (LIM-105, remplace les valeurs hard codées d'identification des OS recertification) |
 | 2026-07-20 | Arthur | Usage confirmé des params `EXPEDITION_CLASSE_CLIENT`/`EXPEDITION_CLASSE_PRODUCTION` (LIM-107, routage du type d'étiquette d'expédition) ; ajout Références LIM-107 |
 | 2026-07-20 | Arthur | Ajout toggle `CST_SimulatePIEScale` (LIM-108, mode simulation poids PIE) + cross-ref contrôle qualité réception ; Références LIM-108 |
 | 2026-07-20 | Arthur | Ajout paramètre `RECERTIFICATION_CODE_QUAI` (LIM-110, code quai recertif auto + balise stratégie assignation stock) ; jira_refs +LIM-110, Références |
 | 2026-07-20 | Arthur | Ajout paramètre `PK_REJET_PROD` (LIM-114, poste de rejet des palettes production sans poste d'origine au rejet PIE) + cross-ref rejet-pie ; jira_refs +LIM-114, Références |
 | 2026-07-20 | Arthur | Ajout paramètre `PIE_FILMAGE` (nom à confirmer, LIM-115, stations sources déclenchant la transmission du programme de filmage à Galileo) + cross-ref galileo-config ; jira_refs +LIM-115, Références |
 ## Références
 | Source | Type | Date |
 |--------|------|------|
 | [LIM-14](https://easywmsfrance.atlassian.net/browse/LIM-14) | Ticket Jira (référentiel séquences/jobs/paramètres) | 2026 |
 | [LIM-102](https://easywmsfrance.atlassian.net/browse/LIM-102) | Ticket Jira (KPI conteneurs par type de réception - CON.CREATE.RECEP) | 2026 |
 | [LIM-105](https://easywmsfrance.atlassian.net/browse/LIM-105) | Ticket Jira (workstation recertification - SAP_ATH111_*, RECERTIFICATION_CODE_CLASSE) | 2026 |
 | [LIM-107](https://easywmsfrance.atlassian.net/browse/LIM-107) | Ticket Jira (étiquettes expédition - EXPEDITION_CLASSE_CLIENT/PRODUCTION) | 2026 |
 | [LIM-108](https://easywmsfrance.atlassian.net/browse/LIM-108) | Ticket Jira (simulation poids PIE - toggle CST_SimulatePIEScale) | 2026 |
 | [LIM-110](https://easywmsfrance.atlassian.net/browse/LIM-110) | Ticket Jira (quai recertification auto - RECERTIFICATION_CODE_QUAI) | 2026 |
 | [LIM-114](https://easywmsfrance.atlassian.net/browse/LIM-114) | Ticket Jira (rejet PIE - PK_REJET_PROD) | 2026 |
 | [LIM-115](https://easywmsfrance.atlassian.net/browse/LIM-115) | Ticket Jira (transmission filmage - stations PIE déclenchantes) | 2026 |
@@ -1,21 +1,18 @@
 ---
-title: "Transverse — Vue d'ensemble"
+title: "Transverse - Vue d'ensemble"
 tags: [transverse, jira, architecture, index]
 status: draft
-last_updated: 2026-05-05
+last_updated: 2026-07-20
 ---
-# Transverse — Vue d'ensemble
+# Transverse - Vue d'ensemble
 > **Périmètre** : tickets Jira clés, décisions d'architecture, questions ouvertes,
 > historique du projet.
 ## Pages de cette section
 - [Tickets Jira clés](jira-tickets-cles.md)
 - [Décisions architecture](decisions-architecture.md)
 - [Questions ouvertes](questions-ouvertes.md)
 - [Historique projet](historique-projet.md)
 ## Vue synthétique
@@ -1,44 +1,66 @@
 ---
-title: "Questions ouvertes — Suivi projet"
+title: "Questions ouvertes - Suivi projet"
 tags: [transverse, questions, suivi, à-confirmer]
 status: draft
 standard_ref: null
 jira_refs: []
 confluence_refs: []
-sources: [FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5.docx, "Réception - LIMAGRAIN - DEV - Confluence.md", "Expédition - LIMAGRAIN - DEV - Confluence.md", "CR CONSOLIDES REU ERP LIMAGRAIN V1 - CR.md", LIM-62_gestion-camions.md, LIM-63_64_65.md, "LIM-69 - LOT1.3 Modes de travail des PK.md", "LIM-70 LOT1.3 [AGV][JOB] MEGA JOB.md", "LIM-71 LOT1.2 RECEPTION PRODUCTION AGV.md", "LIM-72 LOT1.3 [RETOUR] Flux complet PK.md", "LIM-73 - LOT1.3 [RECEPTION] Fermetures, REF et gestion retours.md", "LIM-76 LOT1.2 [GNA] Message LOC.md", "LIM-89 GNA Mise en place de la communication API EasyWMS SAP CPI.md", "LIM-85 LOT2.1 Configuration stratégies defragmentation.md", "LIM-87 LOT2.1 Défragmentation client quai non assigné.md", "LIM-88 LOT2.1 Séquençage shipping par STOP.md", "REU PICKING SEQUENCAGE 11-05-2026 - Analyse comparative notes + AF + devops.md", "CR technique - iGO STILL - fonctionnement et flux API v1.md", "recap_session_LIM-72_13-05-2026.md", "reu_still_sur_site.pdf"]
+sources: [FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5.docx, "Réception - LIMAGRAIN - DEV - Confluence.md", "Expédition - LIMAGRAIN - DEV - Confluence.md", "CR CONSOLIDES REU ERP LIMAGRAIN V1 - CR.md", LIM-62_gestion-camions.md, LIM-63_64_65.md, "LIM-69 - LOT1.3 Modes de travail des PK.md", "LIM-70 LOT1.3 [AGV][JOB] MEGA JOB.md", "LIM-71 LOT1.2 RECEPTION PRODUCTION AGV.md", "LIM-72 LOT1.3 [RETOUR] Flux complet PK.md", "LIM-73 - LOT1.3 [RECEPTION] Fermetures, REF et gestion retours.md", "LIM-76 LOT1.2 [GNA] Message LOC.md", "LIM-89 GNA Mise en place de la communication API EasyWMS SAP CPI.md", "LIM-85 LOT2.1 Configuration stratégies defragmentation.md", "LIM-87 LOT2.1 Défragmentation client quai non assigné.md", "LIM-88 LOT2.1 Séquençage shipping par STOP.md", "REU PICKING SEQUENCAGE 11-05-2026 - Analyse comparative notes + AF + devops.md", "CR technique - iGO STILL - fonctionnement et flux API v1.md", "recap_session_LIM-72_13-05-2026.md", "reu_still_sur_site.pdf", "Jira LIM-97 (lecture directe)", "Jira LIM-111 (lecture directe)", "Jira LIM-112 (lecture directe)", "Jira LIM-113 (lecture directe)", "Jira LIM-114 (lecture directe)"]
-last_updated: 2026-05-13
+last_updated: 2026-07-20
 author: Arthur
 ---
-# Questions ouvertes — Suivi projet
+# Questions ouvertes - Suivi projet
 > **Résumé** : centralisation de toutes les questions ouvertes identifiées
 > lors de l'intégration de l'AF V1.5 dans le wiki projet.
 ## Réception / Inbound
- [ ] Processus de blocage long terme entrée quai — quand est-il utilisé
+- ❓ Processus de blocage long terme entrée quai - quand est-il utilisé
  concrètement ? (@Théo)
- [ ] Notifications agent de quai à l'arrivée du camion — supprimées dans
+- ❓ Notifications agent de quai à l'arrivée du camion - supprimées dans
  AF V1.5, à confirmer exclusion définitive (@Justine)
- [ ] Assignation borne / quai — supprimée dans AF V1.5, à confirmer (@Justine)
+- ❓ Assignation borne / quai - supprimée dans AF V1.5, à confirmer (@Justine)
- [ ] Gestion TRF si AGV pas prêts au démarrage (@Théo)
+- ❓ Gestion TRF si AGV pas prêts au démarrage (@Théo)
- [ ] Position étiquette image de quai (devant/côté palette) — à
+- ❓ Position étiquette image de quai (devant/côté palette) - à
  valider avec le client (@Justine)
- [ ] Utilisation du ROC (confirmation de réception) — point interne
+- ❓ 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)
- [ ] Surplus non réceptionné hors tolérance — quelle solution pour
+- Évolution encodage RFID (LIM-68) - validation client du passage à un
  encodage **7 bits en banque EPC** (attente réponse au mail d'Arthur) ;
  bloque le dev.
  → voir [Étiquette support RFID](../01-inbound/etiquette-rfid.md)
 - Évolution encodage RFID (LIM-68) - réception de la **spec de packing
  Bartender** (Eliatys), prérequis avant tout codage.
 - Évolution encodage RFID (LIM-68) - seuil exact de longueur hexa pour
  discriminer les puces legacy des nouvelles (échantillons legacy - action
  JBR/SVA).
 - Évolution encodage RFID (LIM-68) - tests physiques écriture/lecture sur
  ZT421 + impact du perma-lock.
 - ❓ Surplus non réceptionné hors tolérance - quelle solution pour
  palettes impossibles à réceptionner ? (@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 ? Actuellement non obligatoire
-  (LIM-62, 09/03/2026). (@Justine)
+  (LIM-62 / LIM-97 §8.5, 09/03/2026, à reconfirmer avec le CDP). (@Justine)
  → voir [Gestion des camions](../01-inbound/gestion-camions.md)
- [ ] Poids variable — vérifier si le standard gère la capture de
+- Routage faux stage → emplacement du vrai stage → quai d'expédition
  (LIM-97 §8.1, gestion camions V2) : custom sur la fin d'ordre au PS pour
  rediriger la destination, différenciation par `locationType` ; risque de
  rollback en boucle, cadencement AGV à reconfirmer (@Vincent / @Still)
  → voir [Gestion des camions](../01-inbound/gestion-camions.md)
 - Débordement au-delà de 26 palettes sur l'image de quai (27e palette,
  LIM-97 §8.2) : ne tient pas dans un camion, solution à arbitrer - ne pas
  générer la tâche tant qu'aucune place ne se libère, ou maintien en tampon
  ASRS (@Justine)
  → voir [Gestion des camions](../01-inbound/gestion-camions.md)
 - ❓ Poids variable - vérifier si le standard gère la capture de
  poids avec poids moyen activé (@Nicolas)
 - [x] ~~Détail des cas d'erreur API SAP flux retour client~~ → Documenté
  via LIM-72 : payload requête/réponse, séquence d'échange, timeout/retry
@@ -49,110 +71,192 @@ author: Arthur
 - [x] ~~Gestion du token SAP~~ → OAuth 2.0 client_credentials, cache
  token sur disque, gestion expiration côté WMS
  → voir [Intégration GNA → SAP-CPI](../06-erp-interface/gna-sap-cpi.md)
- [ ] **[A1 BLOQUANT]** Champs manquants dans ET_BATCH (réponse ATH214) :
+- [x] ~~**[A1 BLOQUANT]** Champs manquants dans ET_BATCH (réponse ATH214) :
-  description article, pays de destination, propriétaire Limagrain — sans
+  description article, pays de destination, propriétaire Limagrain~~ →
-  ces champs, le dialogue de choix multi-lot ne fonctionne pas
+  Résolu (LIM-93 V2) : `DESCRIPTION`, `DESTINATION`, `OWNER` ajoutés, plus
-  (@Vincent Goyet / @Pierre Gaudy — mail 13/05/2026)
+  `VAR_DESC` (variété) et `COM_TRT_DESC` (traitement commercial, ajout
  Justine 08/07)
  → voir [Réception retour](../01-inbound/reception-retour.md)
- [ ] **[A2]** Nom final du champ de déploiement : `EV_DEPLOY` ou
+- [x] ~~**[A2]** Nom final du champ de déploiement : `EV_DEPLOY` ou
-  `ZDEPLOY` ? Ambigu dans les échanges (@Vincent Goyet — mail 13/05/2026)
+  `ZDEPLOY` ?~~ → Résolu (LIM-93 V2) : `ZDEPLOY`
  → voir [Réception retour](../01-inbound/reception-retour.md)
- [ ] **[A3]** Délai typique entre réponse ATH214 et push ITM via ATH002 :
+- [x] ~~**[A3]** Délai typique entre réponse ATH214 et push ITM via ATH002 :
-  dimensionnement du polling 5s / timeout 1 min
+  dimensionnement du polling 5s / timeout 1 min~~ → Résolu (LIM-93 V2) :
-  (@Vincent Goyet — mail 13/05/2026)
+  polling `SAP_ATH214_REFRESH_INTERVAL` 5000 ms, `SAP_ATH214_TIMEOUT` 60 s,
- [ ] **[A4 IMPORTANT]** Vérification "déployé" pour les lots déjà connus
+  `SAP_ATH214_MAX_RETRIES` 5
-  en base WMS (pas d'appel ATH214) : info disponible dans l'ITM ou appel
+- [x] ~~**[A4 IMPORTANT]** Vérification "déployé" pour les lots déjà connus
-  systématique nécessaire ? Trou fonctionnel dans le design actuel
+  en base WMS (pas d'appel ATH214) : trou fonctionnel~~ → Résolu (LIM-93
-  (@Vincent Goyet — mail 13/05/2026)
+  V2) : appel ATH214 **systématique** à chaque scan de lot officiel
  → voir [Réception retour](../01-inbound/reception-retour.md)
- [ ] **[B1]** Étiquette stock retour client : en complément de la RFID ?
+- [x] ~~**[B1]** Étiquette stock retour client : en complément de la RFID ?
-  Quels champs ? Format A6 ? Imprimante dédiée ?
+  Quels champs ? Format A6 ? Imprimante dédiée ?~~ → Résolu (LIM-93 V2) :
-  (@Leila / @Antoine — mail 13/05/2026)
+  pas de rapport séparé, **RFID LIM-68 enrichie** (code produit + lots SAP
- [ ] **[B2 IMPORTANT]** Flux de rejet PIE retour client : destination
+  + lot officiel), format **A5 Zebra**, imprimante dédiée PK (impact
-  exacte, notifications, actions opérateur, notification SAP,
+  LIM-68)
-  suppression palette (@Leila / @Antoine — mail 13/05/2026)
+- ❓ **[B2 IMPORTANT]** Flux de rejet PIE retour client : le client veut
-  → voir [Contrôle qualité réception](../01-inbound/controle-qualite-reception.md)
+  un **renvoi au PK pour recomptage immédiat** (approche poumon abandonnée,
- [ ] **[PS — reporté]** Association palette ↔ OE dès l'image de quai
+  LIM-93 V2). Points ouverts : routage AGV PIE → PK, relance du workflow de
-  via CstAtt12 Container — faisable techniquement (modification LIM-64),
+  déclaration sur la même palette, levée du verrou ECART RETOUR (auto ou
-  impact planning à évaluer, reporté après réponses A1-B2
+  manuelle), impact sur la clôture (@Leila / @Antoine)
-  → voir [AD Customs](../07-admin/ad-customs.md)
+  → voir [Réception retour](../01-inbound/reception-retour.md)
- [ ] Retour client — palette refusée au PIE non supprimée : comment
+  - **MAJ (LIM-114)** : le **flux général** de rejet PIE → poste d'origine
  est désormais défini (le WMS répond la destination) dans
  [Flux de rejet PIE](../02-stockage/rejet-pie.md). Restent ouverts les points
  **spécifiques retour client** : relance du workflow de déclaration sur la
  même palette, levée du verrou ECART RETOUR (auto/manuelle), impact clôture
 - Rejet PIE (LIM-114) - transmission de la **cause de rejet** (type d'erreur
  PIE) d'EasyS/Galileo vers le WMS : conditionne l'affichage de la cause au
  poste (à défaut, « REJET PIE » générique) (@Mecalux)
  → voir [Flux de rejet PIE](../02-stockage/rejet-pie.md)
 - Rejet PIE (LIM-114) - poste physique `PK_REJET_PROD` côté EST (ex. `PS01`)
  et sa joignabilité si `PE01` fermé (bascule OUEST) : à valider layout
 - Rejet PIE (LIM-114) - comportement si **aucun poste disponible** (attente
  sur le PS vs autre) : à confirmer
 - Rejet PIE (LIM-114) - disponibilité de l'imprimante d'étiquette au poste
  d'origine (cause étiquette) : à valider
 - [x] ~~**[PS]** Association palette ↔ OE **dès l'image de quai** -
  faisable techniquement (modification LIM-64), le code OE (`CstAtt13`)
  était posé au PK ; à poser plus tôt (image de quai)~~ → Résolu
  (LIM-96 V2) : écran « déclaration des ordres d'entrée » à la déclaration
  image de quai, qui rattache chaque emplacement occupé à son OE et pose
  `CstAtt13` sur le support
  → voir [Gestion des camions](../01-inbound/gestion-camions.md)
 - Réception (LIM-96 / LIM-71) - `CstAtt12` : LIM-96 V2 pose `CstAtt12 =
  true` pour toutes les palettes à l'écran de collage des étiquettes et
  conditionne la prise AGV du job LIM-71 à ce flag, alors que la page
  LIM-71 indiquait que la condition `CstAtt12` avait été **retirée** du
  job. Confirmer la logique effective côté job (@Vincent / @Maxime)
  → voir [Job réception production](../05-agv/job-reception-production.md)
 - ❓ Retour client - palette refusée au PIE non supprimée : comment
  gérer si le client oublie de la retirer du WMS ? Clôture REF bloquée
  indéfiniment (LIM-73 §1.3.1) (@Justine)
- [ ] WF de clôture OE à modifier pour bloquer l'auto-close quand
+- [x] ~~WF de clôture OE à modifier pour bloquer l'auto-close quand
-  CstAtt01 OE = true — ticket dédié à créer ? (LIM-73 §1.3.2)
+  CstAtt01 OE = true - ticket dédié à créer ? (LIM-73 §1.3.2)
-  (@Nicolas)
+  (@Nicolas)~~ → **Résolu** (revue de code LIM-73 validée 2026-06-02) :
  WF existant `InboundOrder_AutoCloseInboundOrder_PR_V2` adapté, pas de
  ticket dédié
  → voir [Réception fournisseur](../01-inbound/reception-fournisseur.md#custom-éléments-techniques-revue-de-code-validée-2026-06-02)
 - [x] ~~LOC custom (LIM-76) : développement hors scope LIM-73~~ →
  Spécifié dans LIM-76 : filtre d'exclusion REF non envoyé documenté
  → voir [LOC message périodique](../06-erp-interface/loc-message-periodique.md)
 - [x] ~~Discordance `AutoCloseReception` : `true` dans l'analyse LIM-73,
  `false` dans le référentiel LIM-14~~ → **Résolu** (Arthur, 2026-07-17) :
  `AutoCloseReception = true`. Le tableau LIM-14 affiche `false`, à
  corriger côté ticket
  → voir [Paramètres projet](../07-admin/parametres-projet.md)
 ## Stockage / ASRS
- [ ] Défragmentation custom (LIM-87) — **rupture de stock** sur un OS
+- ❓ Défragmentation custom (LIM-87) - **rupture de stock** sur un OS
  de la tournée (CT-13) : option A (RUT non éligible, attente nouveau
  SOR) ou option B (défrag sur palettes disponibles) ?
-  (@Justine — vérifier avec le client)
+  (@Justine - vérifier avec le client). Implémentation actuelle :
  commande incomplète → pas de défrag (proche option A)
  → voir [Défragmentation](../02-stockage/defragmentation.md)
- [ ] Défragmentation custom (LIM-87) — **MAX_DEFRAG_ATTEMPT** :
+- [x] ~~Défragmentation custom (LIM-87) - **MAX_DEFRAG_ATTEMPT** :
  impacte-t-il uniquement la défrag par rotation ou aussi la défrag
-  client ? (@Nicolas)
+  client ?~~ → Résolu (LIM-87) : uniquement la défrag par rotation, pas
  la défrag d'expédition/client
  → voir [Défragmentation](../02-stockage/defragmentation.md)
- [ ] Automatisation des étapes 1 et 2 du processus d'anoxie — développement
+- ❓ Automatisation des étapes 1 et 2 du processus d'anoxie - développement
  custom validé ? (@Nicolas)
- [ ] Interface du bouton « Fin d'anoxie » — écran dédié ou menu existant ? (@Fabien)
+- ❓ Interface du bouton « Fin d'anoxie » - écran dédié ou menu existant ? (@Fabien)
- [ ] Nombre exact de piles de palettes vides en tampon au sol (@Théo)
+- ❓ Nombre exact de piles de palettes vides en tampon au sol (@Théo)
 ## Picking / Préparation
- [ ] Fréquence d'exécution du Mega Job d'assignation PK — à définir
+- ❓ Fréquence d'exécution du Mega Job d'assignation PK - à définir
  (@Michael) → voir [Job assignation PK](../03-picking/job-assignation-pk.md)
- [ ] Sous-WF pour regroupement et échantillonnage : tickets à créer ?
+- ❓ Sous-WF pour regroupement et échantillonnage : tickets à créer ?
  (@Michael) → voir [Job assignation PK](../03-picking/job-assignation-pk.md)
- [ ] Interaction PK_BIGBAG et modes : si P5 est en regroupement,
+- ❓ Interaction PK_BIGBAG et modes : si P5 est en regroupement,
  accepte-t-il les big-bags en réception ? (@Michael)
 - Confirmer côté client que SAP gère la priorité des commandes Messagerie
  dans le SOR (pas de custom WMS) - le paramètre `PK_TRANSPORTEUR_MESSAGERIE`
  envisagé pour LIM-80 a été abandonné (@Arthur → Nicolas/Olivier)
  → voir [Job assignation PK](../03-picking/job-assignation-pk.md)
 - Placement PS → PK (LIM-82) : comportement attendu si une palette big-bag
  arrive et qu'aucun PK `PK_BIGBAG` autorisé n'est disponible (attente
  dédiée, refus, autre file) ? (@Justine)
  → voir [Placement PS → PK](../03-picking/placement-ps-pk.md)
 - Placement PS → PK (LIM-82) : confirmer si les mécanismes V1.0
  `SEUIL_RECENTRAGE_PF` et `CONTROLE_TRAITEMENT_COMMERCIAL` sont réellement
  implémentés (absents des critères validés) et où est écrit le `TaskType`
  picking négatif (LIM-75 annulé) (@Arthur)
  → voir [Placement PS → PK](../03-picking/placement-ps-pk.md)
 - [x] ~~Lien entre picking AF V1.5 et CR V3.0 picking combinatoire~~ →
  Architecture clarifiée : specs V1.0/V1.1 + arbitrage réu. 11/05/2026
  → voir [Séquençage TK → PS](../03-picking/sequencage-tk-ps.md) et
  [Placement PS → PK](../03-picking/placement-ps-pk.md)
 - [x] ~~Programme de filmage exact~~ → 8 programmes documentés (A→H : Tournesol/Maïs&Blé × Sacs/BigBag × Complet/Réduit)
- [ ] Gestion du picking négatif dans l'interface opérateur (@Nicolas)
+- ❓ Gestion du picking négatif dans l'interface opérateur (@Nicolas)
- [ ] Interface opérateur vue regroupement — maquette validée ? (@Fabien)
+- ❓ Interface opérateur vue regroupement - maquette validée ? (@Fabien)
- [ ] Format de l'étiquette d'échantillonnage — validé ? (@Justine)
+- ❓ Format de l'étiquette d'échantillonnage - validé ? (@Justine)
- [ ] Le prélèvement de 200g en échantillonnage est-il déduit du stock
+- ❓ Le prélèvement de 200g en échantillonnage est-il déduit du stock
  ou négligé ? (@Nicolas)
- [ ] Séquençage TK→PS (LIM-84) : comportement si erreur du process —
+- ❓ Séquençage TK→PS (LIM-84) : comportement si erreur du process -
  OS reste bloqué avec CstAtt = false ? (@Nicolas)
  → voir [Séquençage TK → PS](../03-picking/sequencage-tk-ps.md)
- [ ] Séquençage TK→PS (LIM-84) : impact perf si beaucoup d'OS Released
+- ❓ Séquençage TK→PS (LIM-84) : impact perf si beaucoup d'OS Released
-  simultanément — contention sur les événements ? (@Fabien)
+  simultanément - contention sur les événements ? (@Fabien)
  → voir [Séquençage TK → PS](../03-picking/sequencage-tk-ps.md)
 - Process picking PK (LIM-91) : choix du poumon messagerie (poumons
  compatibles transporteur vs tous, ou retour ASRS flux classique) (@Justine)
  → voir [Process picking au PK](../03-picking/process-picking-pk.md)
 - Process picking PK (LIM-91) : ergonomie finale de l'écran de recomptage
  HORS TOLERANCE (dialog custom `CST_Count_Picking_GetQuantity`) (@Justine)
  → voir [Process picking au PK](../03-picking/process-picking-pk.md)
 - Process picking PK (LIM-91) : format des étiquettes intercalaires (HU
  fille sans RFID, MII/multi-lots), rapport Zebra à créer (@Arthur)
  → voir [Process picking au PK](../03-picking/process-picking-pk.md)
 ## Expédition / Outbound
- [ ] Ordonnancement des palettes dans le canal du poumon d'expédition
+- ❓ Ordonnancement des palettes dans le canal du poumon d'expédition
-  ASRS — géré par le WMS ou naturellement via l'ordre de stockage ? (@Nicolas)
+  ASRS - géré par le WMS ou naturellement via l'ordre de stockage ? (@Nicolas)
- [ ] Fermeture auto OS si chargement complet — standard ou custom ? (@Nicolas)
+- ❓ Fermeture auto OS si chargement complet - standard ou custom ? (@Nicolas)
- [ ] Comportement du reliquat chargement camion avec fichier RUT —
+- ❓ Comportement du reliquat chargement camion avec fichier RUT -
  à paramétrer et tester (@Fabien)
- [ ] Positions des 2 étiquettes articulées sur la palette (@Théo)
+- ❓ Positions des 2 étiquettes articulées sur la palette (@Théo)
- [ ] Custom Galileo : communication HS imprimante → mise en défaut ET
+- ❓ Custom Galileo : communication HS imprimante → mise en défaut ET
-  — à documenter dans le TMS (@Théo)
+  - à documenter dans le TMS (@Théo)
- [ ] Combien de commandes messagerie carton en parallèle sur un poste ? (@Justine)
+- ❓ Combien de commandes messagerie carton en parallèle sur un poste ? (@Justine)
- [ ] Emplacement au sol buffer litige — localisation exacte (@Théo)
+- ❓ Emplacement au sol buffer litige - localisation exacte (@Théo)
- [ ] Emplacement au sol messagerie carton par transporteur (@Théo)
+- ❓ Emplacement au sol messagerie carton par transporteur (@Théo)
- [ ] Réunion technique Still pour le problème dépose AGV sur image de
+- ❓ Réunion technique Still pour le problème dépose AGV sur image de
  quai (@Théo)
- [ ] Custom fermeture messagerie pour support non client avec supports
+- ❓ Custom fermeture messagerie pour support non client avec supports
  clients (@Nicolas)
- [ ] Clôture manuelle en cas d'expédition partielle — workflow opérateur
+- ❓ Clôture manuelle en cas d'expédition partielle - workflow opérateur
  détaillé (@Justine)
- [ ] Séquençage shipping STOP (LIM-88) — retour PF vers ASRS (CT-08) :
+- ❓ Séquençage shipping STOP (LIM-88) - retour PF vers ASRS (CT-08) :
  confirmer que le standard crée bien une tâche de rangement quand pas
  de route vers l'image de quai. Sinon custom de secours. (@Nicolas)
  → voir [Séquençage shipping par STOP](../04-outbound/sequencage-shipping-stop.md)
- [ ] Séquençage shipping STOP (LIM-88) — bascule de quai en cours de
+- Assignation auto image de quai (LIM-94) - condition « l'image de quai
  n'a aucune réception assignée » marquée **TBD** dans la description ;
  confirmer le périmètre exact du contrôle réception dans
  `CST_DockStage_GetAvailableStageToAssign` (@Justine)
  → voir [Assignation automatique de l'image de quai](../04-outbound/assignation-image-quai.md)
 - Recertification (LIM-110) - relation entre `RECERTIFICATION_CODE_QUAI`
  (décrit comme identifiant aussi les OS recertif + balise `[XXX]` de la
  stratégie) et `RECERTIFICATION_CODE_CLASSE` (LIM-105, déjà l'identifiant
  de la classe recertif) : même valeur, ou deux paramètres distincts à
  clarifier ? (@Vincent)
  → voir [Quai recertification](../04-outbound/shipping-orders.md#quai-recertification)
 - Étiqueteuse automatique (LIM-111) - mécanisme de remontée d'une erreur
  d'impression par les automates au WMS à définir : nécessaire pour que le
  mode dégradé TRF (ré-impression au quai) sache si l'impression a réussi.
  On ne reçoit pas l'info « étiquette bien imprimée ». (@Vincent)
  → voir [Flux expédition - Étiqueteuse automatique](../04-outbound/flux-expedition.md#étiqueteuse-automatique)
 - Étiqueteuse automatique (LIM-111) - palette à l'arrêt en cas de problème
  d'impression : intervention opérateur (laquelle ?) et procédure de
  redémarrage de la palette à définir. (@Théo / @Vincent)
 - [x] ~~Séquençage shipping STOP (LIM-88) - bascule de quai en cours de
  tournée (CT-13) : définir le comportement attendu pour les palettes
-  déjà à l'ancien quai. (@Justine)
+  déjà à l'ancien quai.~~ → **Résolu** (note dev, revue de code LIM-88) :
  on ne peut pas changer le quai une fois la RUT libérée ; scénario exclu
  du custom, rebascule = opération manuelle exceptionnelle
  → voir [Séquençage shipping par STOP](../04-outbound/sequencage-shipping-stop.md)
 - [x] ~~Processus exact de remplacement sac endommagé~~ → Flux litige
  documenté : bouton Problème + verrou support + buffer litige
@@ -161,118 +265,149 @@ author: Arthur
 ## ERP / Interfaces
- [ ] Détail champ par champ de chaque message — document « Liste Interfaces
+- ❓ Détail champ par champ de chaque message - document « Liste Interfaces
  LIMAGRAIN » à intégrer (@Arthur)
- [ ] Format exact du message CHG (@Nicolas)
+- [x] ~~Format exact du message CHG (@Nicolas)~~ → **Résolu** (LIM-113) :
- [ ] CHG envoie-t-il un acquittement positif ou juste ERR en cas
+  `StartWorkflowCommand` / WF custom `CST_CHG_WF`, 9 champs JSON (identité
-  d'échec ? (@Nicolas)
+  complète HU), statut de stock exclu → voir
- [ ] Liste exhaustive des statuts de stock prévus au démarrage (@Justine)
+  [Mapping ERP-WMS](../06-erp-interface/mapping-erp-wms.md#message-chg---changement-article--propriétaire-lim-113)
- [ ] Liste des commentaires par statut de stock — validée ? (@Justine)
+- [x] ~~CHG envoie-t-il un acquittement positif ou juste ERR en cas
- [ ] CstAtt10 (Stage) — quand sera-t-il ajouté au mapping ITM ? (@Nicolas)
+  d'échec ? (@Nicolas)~~ → **Résolu** (LIM-113) : **200** en succès, **500**
- [ ] Création stock via attributs logistiques en réception — standard ou
+  (throw exception) en refus/erreur ; pas d'acquittement négatif propre, le
  500 porte le motif
 - Flux CHG (LIM-113) - identification de la ligne de stock concernée dans la
  HU (plusieurs lignes possibles) : critère de comparaison des attributs reçus
  à préciser (@Vincent)
 - Flux CHG (LIM-113) - traitement **synchrone ou asynchrone / arrière-plan**
  des appels pour tenir la volumétrie des clôtures (~1000 lignes) sans bloquer
  les flux 24/7 (@Nicolas / Mecalux)
 - Flux CHG (LIM-113) - liste **exhaustive** des tables/entités où une HU ou
  une ligne de stock peut être référencée/verrouillée (au-delà de la liste
  indicative ADB-117) : action développeur
 - [x] ~~Liste exhaustive des statuts de stock prévus au démarrage~~ →
  **Résolu** (LIM-90) : 8 statuts retour créés en master data (F9 + 7
  motifs B6), F2 = absence de statut. Hors retour, seul le B6 (via LOC).
  → voir [Réception retour](../01-inbound/reception-retour.md#statuts-de-stock-retour-et-remontée-ref-lim-90)
 - [x] ~~Liste des commentaires par statut de stock - validée ?~~ →
  **Résolu** (LIM-90) : chaque statut porte son libellé/motif (ZINCO
  0002-0008 pour les 7 B6). Blocages picking/shipping à confirmer client.
 - ❓ CstAtt10 (Stage) - quand sera-t-il ajouté au mapping ITM ? (@Nicolas)
  - dépendance **LIM-112** : requis pour l'étiquette d'échantillonnage
  (LIM-107), à vérifier en préprod
  → voir [Échantillonnage](../03-picking/echantillonnage.md)
 - Échantillonnage (LIM-112) - consignes de l'ordre d'inventaire : le mapping
  COR les porte sur `CstAtt02`, mais le commentaire du ticket évoque
  `CstAtt01`. À confirmer avec le client (mail à faire, @Arthur)
  → voir [Échantillonnage](../03-picking/echantillonnage.md)
 - ❓ Création stock via attributs logistiques en réception - standard ou
  custom ? À valider par tests (@Fabien)
- [ ] Impact suppression CstAtt stock sur les développements existants (@Nicolas)
+- ❓ Impact suppression CstAtt stock sur les développements existants (@Nicolas)
 - [x] ~~Gestion STV type "création de stock"~~ → STV désactivé, remplacé
  par le LOC (ACTION=C pour corrections, ACTION=T pour transferts)
  → voir [LOC message périodique](../06-erp-interface/loc-message-periodique.md)
- [ ] StopNumber (RUT) : vérifier que SAP envoie un numéro d'arrêt de
+- ❓ StopNumber (RUT) : vérifier que SAP envoie un numéro d'arrêt de
  livraison et pas de chargement (@Limagrain)
- [ ] Numéro de ligne SOF/LOF : confirmer le nombre de caractères du numéro
+- ❓ Numéro de ligne SOF/LOF : confirmer le nombre de caractères du numéro
  de ligne SAP (padLeft "0") (@Limagrain)
- [ ] Confirmer si le COF sera traité côté ERP — risque demandes en
+- ❓ Confirmer si le COF sera traité côté ERP - risque demandes en
  double (@Limagrain)
- [ ] Confirmer la règle de mélange des marques sur palette (@Limagrain)
+- ❓ Confirmer la règle de mélange des marques sur palette (@Limagrain)
- [ ] Fournir la plage GS1 SSCC (@Limagrain)
+- ❓ Fournir la plage GS1 SSCC (@Limagrain)
- [ ] Planifier un atelier étiquettes avec Antoine (@Limagrain / @Mecalux)
+- ❓ Planifier un atelier étiquettes avec Antoine (@Limagrain / @Mecalux)
- [ ] Confirmer le stockage des Z-Bags dans l'ASRS (format palettes
+- ❓ Confirmer le stockage des Z-Bags dans l'ASRS (format palettes
  respecté ?) (@Limagrain / @Mecalux)
- [ ] Vérifier capacité de traitement du WSC quotidien —
+- ❓ Vérifier capacité de traitement du WSC quotidien -
  volumétrie (@Limagrain)
- [ ] LOC — Cas palette sur image de quai puis chargée avant le prochain
+- ❓ LOC - Cas palette sur image de quai puis chargée avant le prochain
  cycle LOC : la HU ne sera pas mentionnée dans le LOC (LIM-76 point #3)
  (@Limagrain) → voir [LOC message périodique](../06-erp-interface/loc-message-periodique.md)
- [ ] LOC — HU multi-lignes de stock (2 articles/lots) : comportement
+- ❓ LOC - HU multi-lignes de stock (2 articles/lots) : comportement
  exact à confirmer (LIM-76 CT-112) (@Fabien)
  → voir [LOC message périodique](../06-erp-interface/loc-message-periodique.md)
- [ ] LOC — Vérifier si d'autres transactions WMS sont utiles
+- ❓ LOC - Vérifier si d'autres transactions WMS sont utiles
  (ex. STK.SCR) (@Fabien)
  → voir [LOC message périodique](../06-erp-interface/loc-message-periodique.md)
- [ ] GNA SAP-CPI — File d'attente persistante pour messages en échec
+- ❓ GNA SAP-CPI - File d'attente persistante pour messages en échec
-  après 4 retries ? (@Nicolas)
+  après 5 retries ? (@Nicolas)
  → voir [Intégration GNA → SAP-CPI](../06-erp-interface/gna-sap-cpi.md)
- [ ] GNA SAP-CPI — Secret OAuth doit-il être chiffré dans le config ?
+- [x] ~~GNA SAP-CPI - Secret OAuth doit-il être chiffré dans le config ?~~
-  (@Fabien)
+  → **Résolu** (LIM-89, revue de code) : chiffré via `PasswordEncrypt.exe`
  → voir [Intégration GNA → SAP-CPI](../06-erp-interface/gna-sap-cpi.md)
- [ ] Retour fournisseur : ce flux est-il utilisé ? Si oui, SOR simple ou
+- ❓ Retour fournisseur : ce flux est-il utilisé ? Si oui, SOR simple ou
  RUT ? (@Limagrain)
- [ ] Clarifier comportement lot officiel lors changement de
+- ❓ Clarifier comportement lot officiel lors changement de
  destination (@Limagrain)
- [ ] Vérifier le traitement interne du LOF (absence de ligne = non
+- ❓ Vérifier le traitement interne du LOF (absence de ligne = non
  expédié) (@Limagrain)
- [ ] EstimatedNumCont : vérifier disponibilité dans SAP pour chaque
+- ❓ EstimatedNumCont : vérifier disponibilité dans SAP pour chaque
  commande client (ROR) (@Limagrain)
 ## AGV / Still
- [x] ~~Interface AGV — document séparé à intégrer quand disponible~~ →
+- [x] ~~Interface AGV - document séparé à intégrer quand disponible~~ →
  Intégré via CR technique iGO STILL v1 (2026-04-28)
  → voir [Intégration Still iGo](../05-agv/still-igo-integration.md)
- [ ] Impact fonctionnel des interfaces AGV sur les flux (@Théo)
+- ❓ Impact fonctionnel des interfaces AGV sur les flux (@Théo)
- [ ] Redirection multi-poumons / multi-PIE pour réception production :
+- ❓ Redirection multi-poumons / multi-PIE pour réception production :
  config EasyS prête ? (@Nicolas) → voir
  [Job réception production](../05-agv/job-reception-production.md)
- [ ] CstAtt06 encore nécessaire comme marqueur si la vérification par
+- [x] ~~CstAtt06 encore nécessaire comme marqueur ?~~ → **Résolu (LIM-71)** :
-  tâche active suffit ? (@Fabien) → voir
+  marquage abandonné, l'absence de tâche active suffit.
-  [Job réception production](../05-agv/job-reception-production.md)
+- [x] ~~Conflit d'usage CstAtt06 (support) : LIM-71 marqueur de destination
- [ ] Fréquence des callbacks `vehicle/event` iGO pour les mises à
+  vs LIM-67 code du poste de picking~~ → **Résolu** : LIM-71 a abandonné son
-  jour de position — risque de flood du webhook receiver (@Nicolas)
+  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).
  → voir [Réception fournisseur](../01-inbound/reception-fournisseur.md)
 - ❓ Fréquence des callbacks `vehicle/event` iGO pour les mises à
  jour de position - risque de flood du webhook receiver (@Nicolas)
  → voir [Intégration Still iGo](../05-agv/still-igo-integration.md)
- [ ] Taille max et caractères autorisés dans `customMetaData` iGO
+- ❓ Taille max et caractères autorisés dans `customMetaData` iGO
  (@STILL)
  → voir [Intégration Still iGo](../05-agv/still-igo-integration.md)
- [ ] Les `customMetaData` sont-elles ré-émises dans les callbacks
+- ❓ Les `customMetaData` sont-elles ré-émises dans les callbacks
  transport iGO ? (@STILL)
  → voir [Intégration Still iGo](../05-agv/still-igo-integration.md)
- [ ] Création/modification de Location via API iGO — actuellement
+- ❓ Création/modification de Location via API iGO - actuellement
  GET only (@STILL)
  → voir [Stations et routes AGV](../05-agv/agv-stations-routes.md)
- [ ] Gestion Pallet Shuttle via iGO (LoadType = 1) — hors scope
+- ❓ Gestion Pallet Shuttle via iGO (LoadType = 1) - hors scope
  actuel ? (@Théo)
- [ ] Multi-warehouse iGO : un seul site supposé — impact extension
+- ❓ Multi-warehouse iGO : un seul site supposé - impact extension
  future ? (@Michael)
- [ ] Visite terrain 29/05 — confirmation par Still de l'espace max
+- ❓ Visite terrain 29/05 - confirmation par Still de l'espace max
  palette/convoyeur ~45 mm (@Théo)
  -> voir [Troubleshooting AGV](../05-agv/agv-troubleshooting.md)
- [ ] Visite terrain 29/05 — mesure réelle SAS7 lors de l'implantation
+- ❓ Visite terrain 29/05 - mesure réelle SAS7 lors de l'implantation
  (@Abdennaim)
  -> voir [Troubleshooting AGV](../05-agv/agv-troubleshooting.md)
- [ ] Visite terrain 29/05 — solution Still pour augmenter distance
+- ❓ Visite terrain 29/05 - solution Still pour augmenter distance
  mât/bord palette : quel impact sur les specs AGV ? (@Théo / @Still)
  -> voir [Troubleshooting AGV](../05-agv/agv-troubleshooting.md)
 ## Admin / Transverse
- [ ] Rapports standards — exclus de l'AF V1.5, périmètre à définir (@Justine)
+- ❓ Rapports standards - exclus de l'AF V1.5, périmètre à définir (@Justine)
- [ ] Vues EasyWMS — sauf impact processus fonctionnel, exclus AF V1.5 (@Justine)
+- ❓ Vues EasyWMS - sauf impact processus fonctionnel, exclus AF V1.5 (@Justine)
- [ ] Layout complet (postes de picking inclus) — exclus AF V1.5 (@Théo)
+- ❓ Layout complet (postes de picking inclus) - exclus AF V1.5 (@Théo)
 ## Points fermés (ateliers expédition DEV)
 Les points suivants ont été tranchés lors des ateliers DEV expédition :
- [x] **SOR au numéro de support** → Fermé : jamais au numéro de support
+- [x] ~~**SOR au numéro de support**~~ → Fermé : jamais au numéro de support
- [x] **FEFO sans DLC** → Fermé : abandonné, FIFO journalier retenu
+- [x] ~~**FEFO sans DLC**~~ → Fermé : abandonné, FIFO journalier retenu
- [x] **Message MOV** → Fermé : annulé (inutile)
+- [x] ~~**Message MOV**~~ → Fermé : annulé (inutile)
- [x] **Gestion FIFO canal** → Fermé : FIFO 24h standard, économie de
+- [x] ~~**Gestion FIFO canal**~~ → Fermé : FIFO 24h standard, économie de
  mouvement prioritaire
- [x] **Custom attributes vs attributs logistiques** → Tranché : attributs
+- [x] ~~**Custom attributes vs attributs logistiques**~~ → Tranché : attributs
  logistiques avec masquage écrans inutiles
- [x] **Process litige sac endommagé** → Fermé : flux décrit (bouton
+- [x] ~~**Process litige sac endommagé**~~ → Fermé : flux décrit (bouton
  Problème + verrou support + buffer litige), à confirmer avec client
- [x] **Statut de stock F2 si aucun statut** → Fermé : REDFLAG, pousser
+- [x] ~~**Statut de stock F2 si aucun statut**~~ → Fermé : REDFLAG, pousser
  pour ne pas faire
- [x] **Anoxie : flux automatique** → Fermé : à prévoir si temps disponible
+- [x] ~~**Anoxie : flux automatique**~~ → Fermé : à prévoir si temps disponible
- [x] **Fréquence image de stock (WSC)** → Fermé : à définir (toutes les
+- [x] ~~**Fréquence image de stock (WSC)**~~ → Fermé : à définir (toutes les
  X heures)
 ## Éléments exclus de l'AF V1.5
@@ -293,4 +428,26 @@ Pour mémoire, les éléments suivants sont explicitement exclus du périmètre
 | 2026-05-06 | Arthur | Ajout 13 questions ERP consolidées + LIM-62/63/64/65 |
 | 2026-05-12 | Arthur | Ajout questions LIM-66→76, LIM-80→89, picking séquençage, AGV iGO |
 | 2026-05-13 | Arthur | Fermeture URL API + token SAP, ajout A1-A4 + B1-B2 + PS (récap LIM-72) |
-| 2026-05-13 | Arthur | Ajout 3 questions terrain AGV (visite Still/Mecalux 29/05) |
+| 2026-05-13 | Arthur | Ajout 3 questions terrain AGV (visite Still/Mecalux 29/05) |
 | 2026-07-16 | Arthur | Ajout conflit d'usage CstAtt06 support (LIM-67 vs LIM-71) |
 | 2026-07-17 | Arthur | Ajout 4 questions évolution encodage RFID (LIM-68) ; résolution conflit CstAtt06 + question marqueur (LIM-71 abandon marquage) |
 | 2026-07-17 | Arthur | Ajout question priorité Messagerie SAP/SOR (LIM-80, abandon PK_TRANSPORTEUR_MESSAGERIE) |
 | 2026-07-17 | Arthur | Ajout questions LIM-82 (big-bag sans PK dispo, mécanismes V1.0 SEUIL_RECENTRAGE_PF/CONTROLE_TRAITEMENT_COMMERCIAL, TaskType picking négatif LIM-75) |
 | 2026-07-17 | Arthur | Résolution MAX_DEFRAG_ATTEMPT (LIM-87, uniquement défrag rotation) ; annotation CT-13 (implémentation = pas de défrag si commande incomplète) |
 | 2026-07-17 | Arthur | Résolution CT-13 bascule de quai (LIM-88, revue de code) : quai non modifiable après libération RUT |
 | 2026-07-17 | Arthur | Résolution secret OAuth chiffré (LIM-89, PasswordEncrypt.exe) ; file d'attente 4→5 retries |
 | 2026-07-17 | Arthur | Résolution 2 questions statuts de stock (LIM-90) ; ajout 3 questions ouvertes process picking PK (LIM-91) |
 | 2026-07-20 | Arthur | Ajout 2 questions LIM-97 (routage faux stage §8.1, débordement 27e palette §8.2) ; annotation plaque obligatoire (repris LIM-97 §8.5) |
 | 2026-07-20 | Arthur | Ajout question LIM-110 (relation `RECERTIFICATION_CODE_QUAI` vs `RECERTIFICATION_CODE_CLASSE`) |
 | 2026-07-20 | Arthur | Ajout 2 questions LIM-111 (remontée erreur d'impression étiqueteuse par les automates ; palette à l'arrêt en cas de problème d'impression) |
 | 2026-07-20 | Arthur | LIM-112 : annotation dépendance CstAtt10 (Stage) requis pour l'étiquette d'échantillonnage ; ajout question consignes CstAtt01/02 (mail client) |
 | 2026-07-20 | Arthur | LIM-113 : résolution 2 questions CHG (format = StartWorkflowCommand/CST_CHG_WF ; acquittement 200/500) ; ajout 3 questions (ID ligne de stock dans la HU, sync/async volumétrie, liste exhaustive tables) |
 | 2026-07-20 | Arthur | LIM-114 : annotation B2 (flux général rejet PIE → poste d'origine défini, restent points retour client) ; ajout 4 points ouverts rejet PIE (cause EasyS→WMS, PK_REJET_PROD layout, aucun poste dispo, imprimante poste) |
 | 2026-07-20 | Arthur | Lint : conversion des checklists en « - ❓ », questions résolues barrées, ajout section Références |
 ## Références
 > Page de suivi transverse : les sources sont listées de manière exhaustive
 > dans le champ `sources` du front matter (26 entrées : AF V1.5, pages
 > Confluence, CR de réunions, tickets Jira en lecture directe). Chaque
 > question porte en outre sa référence Jira ou son interlocuteur (@personne).
@@ -1,11 +1,11 @@
 ---
-title: "Wiki Limagrain — Table des matières"
+title: "Wiki Limagrain - Table des matières"
 tags: [index, limagrain]
 status: draft
-last_updated: 2026-05-12
+last_updated: 2026-07-20
 ---
-# Wiki Limagrain — Table des matières
+# Wiki Limagrain - Table des matières
 > **Périmètre** : ce wiki documente les spécificités projet Limagrain par rapport
 > au standard EasyWMS. Pour les concepts génériques, se référer au
@@ -13,7 +13,7 @@ last_updated: 2026-05-12
 ## Sections
-### 01 — Inbound
+### 01 - Inbound
 - [Vue d'ensemble](01-inbound/_index.md)
 - [Gestion des camions](01-inbound/gestion-camions.md)
@@ -23,7 +23,7 @@ last_updated: 2026-05-12
 - [Étiquette RFID](01-inbound/etiquette-rfid.md)
 - [Flux ERP inbound](01-inbound/flux-erp-inbound.md)
-### 02 — Stockage
+### 02 - Stockage
 - [Vue d'ensemble](02-stockage/_index.md)
 - [ASRS / Miniload](02-stockage/asrs-miniload.md)
@@ -33,31 +33,33 @@ last_updated: 2026-05-12
 - [Défragmentation](02-stockage/defragmentation.md)
 - [Processus d'anoxie](02-stockage/processus-anoxie.md)
 - [Gestion des palettes vides](02-stockage/palettes-vides.md)
 - [Flux de rejet PIE](02-stockage/rejet-pie.md)
-### 03 — Picking
+### 03 - Picking
 - [Vue d'ensemble](03-picking/_index.md)
 - [Picking combinatoire](03-picking/picking-combinatoire.md)
 - [Stations de picking](03-picking/stations-picking.md)
 - [Job d'assignation PK (Mega Job)](03-picking/job-assignation-pk.md)
 - [Séquençage TK → PS](03-picking/sequencage-tk-ps.md)
- [Séquençage TK → PS — Historique](03-picking/sequencage-tk-ps-historique.md)
+- [Séquençage TK → PS - Historique](03-picking/sequencage-tk-ps-historique.md)
 - [Placement PS → PK (choix de table)](03-picking/placement-ps-pk.md)
- [Waves et groupes](03-picking/waves-groupes.md)
+- [Process de picking au poste (PK)](03-picking/process-picking-pk.md)
- [Replenishment](03-picking/replenishment.md)
+- [Recertification - Workstation au PK](03-picking/recertification.md)
 - [Consolidation / Regroupement](03-picking/consolidation-regroupement.md)
 - [Échantillonnage](03-picking/echantillonnage.md)
-### 04 — Outbound
+### 04 - Outbound
 - [Vue d'ensemble](04-outbound/_index.md)
 - [Flux expédition](04-outbound/flux-expedition.md)
 - [Shipping Orders](04-outbound/shipping-orders.md)
 - [Séquençage shipping par STOP](04-outbound/sequencage-shipping-stop.md)
 - [Assignation automatique de l'image de quai](04-outbound/assignation-image-quai.md)
 - [Consolidation et chargement](04-outbound/consolidation-chargement.md)
 - [Flux ERP outbound](04-outbound/flux-erp-outbound.md)
-### 05 — AGV
+### 05 - AGV
 - [Vue d'ensemble](05-agv/_index.md)
 - [Intégration Still iGo](05-agv/still-igo-integration.md)
@@ -66,17 +68,16 @@ last_updated: 2026-05-12
 - [Job réception fournisseur/retour → PK](05-agv/job-reception-pk.md)
 - [Troubleshooting AGV](05-agv/agv-troubleshooting.md)
-### 06 — Interface ERP
+### 06 - Interface ERP
 - [Vue d'ensemble](06-erp-interface/_index.md)
 - [Référence messages](06-erp-interface/messages-reference.md)
 - [Données principales et stock](06-erp-interface/donnees-principales.md)
- [LOC — Message périodique](06-erp-interface/loc-message-periodique.md)
+- [LOC - Message périodique](06-erp-interface/loc-message-periodique.md)
 - [Intégration GNA → SAP-CPI](06-erp-interface/gna-sap-cpi.md)
 - [Mapping ERP-WMS](06-erp-interface/mapping-erp-wms.md)
 - [Monitoring interface](06-erp-interface/interface-monitoring.md)
-### 07 — Administration
+### 07 - Administration
 - [Vue d'ensemble](07-admin/_index.md)
 - [Utilisateurs et groupes](07-admin/utilisateurs-groupes.md)
@@ -84,13 +85,10 @@ last_updated: 2026-05-12
 - [AD Customs](07-admin/ad-customs.md)
 - [Contacts projet](07-admin/contacts-projet.md)
-### 08 — Transverse
+### 08 - Transverse
 - [Vue d'ensemble](08-transverse/_index.md)
 - [Tickets Jira clés](08-transverse/jira-tickets-cles.md)
 - [Décisions architecture](08-transverse/decisions-architecture.md)
 - [Questions ouvertes](08-transverse/questions-ouvertes.md)
 - [Historique projet](08-transverse/historique-projet.md)
 ## Ressources
--- a/Show More
+++ b/Show More