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

màj wiki avec retour MES lot-5 AD

Browse Source
This commit is contained in:
Arthur Ria
2026-05-20 09:41:27 +02:00
commit 23eb3f3c84
4106 changed files with 469381 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
wiki_old_13-05-2026/CLAUDE.md
+431
View File
@@ -0,0 +1,431 @@
# CLAUDE.md — Wiki EasyWMS Limagrain (Cowork)
## Mission
Tu maintiens un **wiki projet Limagrain en Markdown** dans le sous-dossier `limagrain/`, au sein d'un dépôt qui contient aussi le **wiki standard EasyWMS** (dossiers `architecture/`, `concepts/`, `modules/`, `operations/`, `glossary.md`). Le wiki standard est également accessible via le MCP server `wms-wiki`.
Le wiki Limagrain ne documente que le **delta projet** : customs, configurations, décisions, flux spécifiques. Chaque page renvoie vers la page standard correspondante quand un concept générique existe.
**Règle d'or** : ne jamais modifier les fichiers du wiki standard. Le dossier `limagrain/` est le seul périmètre d'écriture pour le contenu projet.
---
## Arborescence
```
wiki-ameliorator-v2_x-Limagrain/ ← racine du dépôt
│
├── CLAUDE.md ← CE FICHIER
│
├── ── WIKI STANDARD (lecture seule) ──
├── architecture/ ← 6 pages standard
├── concepts/ ← 35 pages standard
├── modules/ ← 24 pages standard
├── operations/ ← 19 pages standard
├── glossary.md ← glossaire standard
├── _index.md ← index global (standard + Limagrain)
├── _lint_report.md
├── _log.md
│
├── ── SOURCES (inbox) ──
├── sources/ ← déposer ici les ressources à intégrer
│ └── archives/ ← ressources déjà traitées
│
├── ── JOURNAL ──
├── consume.log ← journal de consommation (append-only)
│
└── ── WIKI LIMAGRAIN (écriture) ──
limagrain/
├── README.md ← index + table des matières du wiki Limagrain
├── glossaire-limagrain.md ← termes et acronymes spécifiques projet
│
├── 01-inbound/
│ ├── _index.md
│ ├── reception-fournisseur.md
│ ├── reception-retour.md
│ ├── controle-qualite-reception.md
│ └── flux-erp-inbound.md
│
├── 02-stockage/
│ ├── _index.md
│ ├── asrs-miniload.md
│ ├── galileo-config.md
│ ├── putaway-strategies.md
│ ├── zones-stockage.md
│ └── defragmentation.md
│
├── 03-picking/
│ ├── _index.md
│ ├── picking-combinatoire.md
│ ├── stations-picking.md
│ ├── waves-groupes.md
│ └── replenishment.md
│
├── 04-outbound/
│ ├── _index.md
│ ├── flux-expedition.md
│ ├── shipping-orders.md
│ ├── consolidation-chargement.md
│ └── flux-erp-outbound.md
│
├── 05-agv/
│ ├── _index.md
│ ├── still-igo-integration.md
│ ├── agv-stations-routes.md
│ └── agv-troubleshooting.md
│
├── 06-erp-interface/
│ ├── _index.md
│ ├── messages-reference.md
│ ├── mapping-erp-wms.md
│ └── interface-monitoring.md
│
├── 07-admin/
│ ├── _index.md
│ ├── utilisateurs-groupes.md
│ ├── parametres-projet.md
│ └── ad-customs.md
│
├── 08-transverse/
│ ├── _index.md
│ ├── jira-tickets-cles.md
│ ├── decisions-architecture.md
│ ├── questions-ouvertes.md
│ └── historique-projet.md
│
└── assets/
```
L'arborescence `limagrain/` ci-dessus est le **squelette initial**. Tu peux créer de nouvelles pages ou sous-dossiers si le contenu le justifie — respecte les conventions ci-dessous et mets à jour `limagrain/README.md` en conséquence.
---
## Workflow de consommation
Quand Arthur te demande d'intégrer des ressources ou quand tu détectes des fichiers dans `sources/` :
### Étape 1 — Inventaire
Lis le contenu de `sources/` (ignore `archives/`) et liste les fichiers présents. Pour chaque fichier, identifie :
- Le type (Confluence export, note Obsidian, mail, Excel, PDF, Word, capture d'écran)
- Le domaine fonctionnel probable (inbound, stockage, picking, outbound, AGV, ERP, admin, transverse)
- Les infos clés à extraire
Présente ce résumé à Arthur avant de commencer l'intégration.
### Étape 2 — Rédaction / Mise à jour
Pour chaque ressource :
1. **Vérifie le standard** : consulte d'abord la page correspondante dans le wiki standard local (`concepts/`, `modules/`, etc.) ET/OU appelle `wms-wiki:search_wiki` ou `wms-wiki:get_wiki_page` via MCP pour compléter
2. **Identifie la page cible** dans `limagrain/` (existante ou à créer)
3. **Rédige ou mets à jour** la page en respectant le template (voir plus bas)
4. **Cross-référence** : ajoute des liens vers les autres pages du wiki Limagrain si pertinent
5. **Mets à jour `limagrain/glossaire-limagrain.md`** si de nouveaux termes apparaissent
6. **Mets à jour `limagrain/README.md`** si de nouvelles pages sont créées
### Étape 3 — Log et archivage
Après intégration de chaque fichier :
1. **Ajoute une entrée** dans `consume.log` à la racine (format ci-dessous)
2. **Déplace le fichier** de `sources/` vers `sources/archives/`
### Étape 4 — Compte rendu
Après chaque session d'intégration, résume à Arthur :
- Fichiers consommés
- Pages créées ou modifiées
- Nouvelles cross-références
- Questions ouvertes identifiées
- Termes ajoutés au glossaire
---
## Format du `consume.log`
Fichier append-only à la racine du dépôt. Chaque session est datée, chaque fichier a une entrée.
```
## [2026-05-05] session-001
- **Fichier** : `CR_reunion_picking_2026-04-15.pdf`
**Type** : CR réunion
**Action** : Mis à jour `limagrain/03-picking/picking-combinatoire.md` (ajout section CstAtt handshake)
**Cross-refs** : Lien ajouté depuis `limagrain/04-outbound/flux-expedition.md`
**Questions** : "Valeur par défaut CstAtt quand lot inconnu ?" → ajouté dans `limagrain/08-transverse/questions-ouvertes.md`
- **Fichier** : `Mapping_ERP_Limagrain_v2.xlsx`
**Type** : Excel mapping
**Action** : Créé `limagrain/06-erp-interface/mapping-erp-wms.md`
**Cross-refs** : Liens depuis `limagrain/01-inbound/flux-erp-inbound.md` et `limagrain/04-outbound/flux-erp-outbound.md`
**Questions** : aucune
```
---
## Template de page wiki
Chaque fichier `.md` dans `limagrain/` doit suivre cette structure :
```markdown
---
title: "Titre de la page"
tags: [domaine, sous-domaine, concept]
status: draft | review | validated
standard_ref: concepts/reception.md
jira_refs: [LIM-70, LIM-75]
confluence_refs: []
sources: []
last_updated: 2026-05-05
author: Arthur
---
# Titre de la page
> **Résumé** : 1-2 phrases décrivant le sujet et pourquoi c'est spécifique Limagrain.
> **Standard EasyWMS** : → voir [Nom page standard](../../concepts/page.md)
> Ce qui suit documente les **spécificités Limagrain** par rapport au standard.
## Contexte projet
Pourquoi ce sujet est spécifique chez Limagrain. Quel besoin métier.
## Configuration / Implémentation
Détails techniques : paramètres, valeurs, éléments AD customs.
## Flux fonctionnel
Description du flux. Utiliser un diagramme Mermaid si pertinent :
​```mermaid
sequenceDiagram
participant ERP
participant WMS
ERP->>WMS: SOR01
WMS->>WMS: Stock assignment
WMS-->>ERP: SOF01
​```
## Points d'attention
⚠️ Particularités, pièges connus, bugs rencontrés, workarounds.
## Questions ouvertes
- [ ] Question 1 (@Théo)
- [ ] Question 2 (@Michael)
## Historique des modifications
| Date | Auteur | Modification |
|------|--------|-------------|
| 2026-05-05 | Arthur | Création initiale |
## Références
| Source | Type | Date |
|--------|------|------|
| Jira LIM-70 | Ticket | 2025-xx-xx |
| "Titre page" Confluence | Page | 2025-xx-xx |
| CR réunion picking | PDF | 2026-04-15 |
```
---
## Template `_index.md` (sommaire de section)
```markdown
---
title: "Inbound — Vue d'ensemble"
tags: [inbound, index]
status: draft
last_updated: 2026-05-05
---
# Inbound — Vue d'ensemble
> **Périmètre** : réception fournisseur, retours, contrôle qualité à réception, messages ERP inbound.
> **Standard EasyWMS** : voir [Reception](../../concepts/reception.md), [Order Inbound](../../concepts/order-inbound.md)
## Pages de cette section
- [Réception fournisseur](reception-fournisseur.md)
- [Réception retour](reception-retour.md)
- [Contrôle qualité réception](controle-qualite-reception.md)
- [Flux ERP inbound](flux-erp-inbound.md)
## Vue synthétique du flux inbound Limagrain
(Diagramme Mermaid du flux global de la section — à compléter)
```
---
## Liens entre wikis
### Depuis une page Limagrain → page standard (même dépôt)
Chemins relatifs remontant au-dessus de `limagrain/` :
```markdown
→ voir [Reception standard](../../concepts/reception.md)
→ voir [Picking standard](../../concepts/picking.md)
→ voir [Galileo Integration](../../architecture/galileo-integration.md)
```
### Depuis une page Limagrain → autre page Limagrain
Chemins relatifs au sein de `limagrain/` :
```markdown
Voir aussi [Flux expédition](../04-outbound/flux-expedition.md)
Voir aussi [Glossaire Limagrain](../glossaire-limagrain.md)
```
### Vers Jira
```markdown
[LIM-70](https://easywmsfrance.atlassian.net/browse/LIM-70)
```
---
## Conventions strictes
### Nommage
- Fichiers : **kebab-case**, pas d'accents, `.md` → `picking-combinatoire.md`
- Dossiers dans `limagrain/` : numérotés `01-` à `08-` + kebab-case
- Assets : `{section}-{description}.{ext}` → `03-picking-schema-stations.png`
### Markdown lint
Règles à respecter (compatible markdownlint) :
- Headings ATX (`#`) uniquement, pas de saut de niveau (h1 → h3 interdit)
- Pas de trailing spaces
- Pas de lignes vides multiples (max 1)
- Line length ≤ 120 caractères (souple pour tableaux et liens)
- Listes entourées de lignes vides
- Premier élément du fichier = front matter `---` puis heading H1
- Pas de headings dupliqués dans un même fichier
- Liens relatifs entre pages (pas de chemins absolus)
### Langue
- **Français** pour la rédaction
- Termes techniques WMS en anglais acceptés (putaway, picking, stock assignment, etc.)
- Noms de messages ERP en majuscules : SOR, SOF, ASN, RUT, LOF
- Noms d'entités AD en anglais PascalCase : OutboundOrder, ContainerStock, etc.
---
## Contexte projet Limagrain
### Équipe
| Personne | Rôle |
|----------|------|
| Arthur | Chef de projet technique - Intégrateur WMS / liaison client-dev, auteur du wiki |
| Nicolas Chabanis | Responsable développement |
| Théo | Chef de projet général - pilote tout le projet |
| Michael | Directeur des opérations - Pilote Arthur |
| Fabien Mogade | Développeur |
| Fares Zaroui | Développeur |
| Justine Beutin | Chef de projet fonctionnelle - Pilote le planning et principale interlocutrice avec Limagrain |
### Périmètre fonctionnel (par priorité)
1. **Réception / Inbound** — modes de réception, ASN, SSCC/LPN, mono-référence
2. **Stockage / ASRS / Galileo** — miniload, transstockeurs, stations, routes
3. **Picking / Préparation** — picking combinatoire (CR V3.0, 4-job, CstAtt), stations
4. **Expédition / Outbound** — flux SOR → RUT → SOF → LOF, chargement
5. **Intégration AGV / Still** — iGo API, DB protocol, transport lifecycle
6. **Intégration ERP** — catalogue messages, mapping champs
7. **Administration** — RBAC, groupes, paramètres, éléments AD customs
### Glossaire initial (termes spécifiques Limagrain)
| Terme | Signification |
|-------|--------------|
| CstAtt | Custom Attribute — handshake dans le picking combinatoire |
| CR V3.0 | Change Request version 3.0 — architecture 4 jobs picking combinatoire |
| SOR | Shipping Order Request — message ERP entrant, crée un ordre d'expédition |
| RUT | Route — message ERP entrant, définit une tournée transporteur |
| SOF | Shipping Order Fulfilled — message ERP sortant, ordre expédié |
| LOF | Load Order Fulfilled — message ERP sortant, chargement camion terminé |
| ASN | Advanced Shipping Notice — pré-avis de réception avec contenu connu |
| PIE | Station de pesée automatique |
| PDL | Picking Dedicated Location — emplacement dédié picking |
| ASRS | Automatic Storage and Retrieval System — stockage automatique |
| TK | Transstockeur (miniload) |
| TMS | Transport Management System (Galileo chez Mecalux) |
| AD | Application Dictionary — framework métadonnées EasyWMS |
### Jira
- **Projet** : Limagrain (préfixe `LIM-`)
- **Cloud ID** : `d79e5957-a82c-4b8f-bd19-d553ef331c42`
- **URL base** : `https://easywmsfrance.atlassian.net`
### MCP tools disponibles
| Serveur | Usage |
|---------|-------|
| `wms-wiki:*` | Wiki standard EasyWMS — search, get_page, get_glossary_term, list_sections, get_related_pages |
| `wms:*` | Données WMS live — queries LINQ, entities, workflows, AD, metadata |
| `Atlassian:*` | Jira + Confluence — recherche JQL/CQL, lecture tickets/pages |
**Utilise `wms-wiki` systématiquement** pour vérifier les concepts standard avant de rédiger.
**Utilise `Atlassian` avec le cloudId ci-dessus** pour rechercher tickets ou pages Confluence référencés.
**Consulte aussi les pages standard locales** (`concepts/`, `modules/`, etc.) quand elles sont plus complètes que le MCP.
---
## Règles impératives
1. **Ne jamais modifier le contenu standard** — les dossiers `architecture/`, `concepts/`, `modules/`, `operations/`, `glossary.md` sont en lecture seule. **Exception unique** : le fichier `_index.md` racine peut être modifié pour y ajouter/mettre à jour la section Limagrain (voir règle 10)
2. **Jamais de duplication du standard** — si le standard couvre un concept, renvoie vers lui et ne documente que le delta Limagrain
3. **Toujours sourcer** — chaque information vient d'une source identifiable. Cite-la dans le front matter `sources` et le tableau Références
4. **Marquer les incertitudes** — `> ⚠️ À confirmer` ou `- [ ] Question (@personne)`, reporter dans `limagrain/08-transverse/questions-ouvertes.md`
5. **Log obligatoire** — chaque fichier consommé → entrée dans `consume.log` AVANT archivage
6. **Archivage obligatoire** — après intégration, déplacer le fichier de `sources/` vers `sources/archives/`
7. **Cross-référencer** — quand une page mentionne un concept couvert ailleurs dans le wiki Limagrain, ajouter un lien
8. **Granularité** — un fichier = un sujet. Découper si > 300 lignes
9. **README.md à jour** — toute création/suppression de page dans `limagrain/` doit y être reflétée
10. **`_index.md` racine à jour (MCP discovery)** — le fichier `_index.md` à la racine est le registre utilisé par le MCP server `wms-wiki` pour découvrir les pages. Quand une page est créée ou supprimée dans `limagrain/`, ajouter/retirer son entrée dans `_index.md` sous une section dédiée `## Limagrain — Projet`. Le format doit suivre exactement le même pattern que les sections existantes (Concepts, Modules, Architecture, Operations) :
```markdown
## Limagrain — Projet (XX pages)
### Réception fournisseur
- **Path:** limagrain/01-inbound/reception-fournisseur.md
- **Type:** limagrain
- Résumé court de la page (1-2 lignes tirées du front matter ou du bloc Résumé).
### Picking combinatoire
- **Path:** limagrain/03-picking/picking-combinatoire.md
- **Type:** limagrain
- Architecture 4 jobs, CstAtt handshake, CR V3.0.
```
Ne jamais modifier les sections standard existantes (Concepts, Modules, Architecture, Operations) dans `_index.md`. Seule la section `## Limagrain — Projet` est modifiable.
---
## Démarrage
Si le dossier `limagrain/` n'existe pas encore :
1. Crée `limagrain/` et toutes ses sous-sections (`01-inbound/` à `08-transverse/`, `assets/`)
2. Crée `consume.log` à la racine (vide, avec juste un header `# Journal de consommation`)
3. Crée les `_index.md` pour chaque section (contenu minimal, statut `draft`)
4. Crée `limagrain/README.md` avec la table des matières
5. Crée `limagrain/glossaire-limagrain.md` avec le tableau du glossaire initial ci-dessus
6. Attends qu'Arthur dépose des ressources dans `sources/` ou donne des instructions
wiki_old_13-05-2026/_index.md
+343
View File
@@ -0,0 +1,343 @@
# Wiki EasyWMS — Index
Total : 122 pages
## Concepts (33 pages)
### Batch 1 — Core Entities
- [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
- [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
- [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
- [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
- [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)
- [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
- [Carrier](concepts/carrier.md) — Base carrier + Extended carrier (Multi-Carrier module); delivery entity, tracking, packaging modes, CAR ERP message
### Batch 2 — Core Flows
- [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
- [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
- [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)
### 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)
- [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
- [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
- [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
- [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)
- [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
- [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
- [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
### 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)
## Modules (24 pages)
### Batch 5 — Modules
- [AGV](modules/agv.md) — Automated Guided Vehicles: communication protocol (phases 00/03/04/06/08/10/255), error categories, RFT fallback, lock types
- [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
- [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
- [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
- [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
- [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
- [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
- [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
- [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
- [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
- [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)
- [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
- [Client-Specific Rules](modules/client-specific-rules.md) — Source unavailable (404); concept maps to Directives module
## Architecture (6 pages)
### 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
- [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
- [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
### 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
## 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
- [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 (19 pages)
### 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)
- [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
### 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)
- [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 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
- [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
### 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
- [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
- [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
- [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)
- [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
- [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
## 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
## Limagrain — Projet (40 pages)
### 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).
### 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
- **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
- **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
- **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.
### 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
- **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.
### Zones de stockage Limagrain
- **Path:** limagrain/02-stockage/zones-stockage.md
- **Type:** limagrain
- 3 zones de stockage dans l'ASRS : anoxie, stockage principal, défragmentation client.
### Stratégies de rangement Limagrain
- **Path:** limagrain/02-stockage/putaway-strategies.md
- **Type:** limagrain
- 5 stratégies de rangement distinctes selon la typologie de la palette.
### 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
- **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
- **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.
### 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.
### 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.
### Stations et postes de travail Limagrain
- **Path:** limagrain/03-picking/stations-picking.md
- **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
- **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
- **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.
### Séquençage des tâches de picking TK → PS
- **Path:** limagrain/03-picking/sequencage-tk-ps.md
- **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
- **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.
### Placement des palettes PS → PK (choix de table)
- **Path:** limagrain/03-picking/placement-ps-pk.md
- **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é
- **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
- **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
- **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.
### Quais, poumons et chargement
- **Path:** limagrain/04-outbound/consolidation-chargement.md
- **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é
- **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
- **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
- **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
- **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
- **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)
- **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.
### Intégration GNA → SAP-CPI
- **Path:** limagrain/06-erp-interface/gna-sap-cpi.md
- **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
- **Path:** limagrain/07-admin/utilisateurs-groupes.md
- **Type:** limagrain
- Définition des 3 groupes d'utilisateurs Limagrain et leurs permissions respectives.
### Contacts projet Limagrain
- **Path:** limagrain/07-admin/contacts-projet.md
- **Type:** limagrain
- Annuaire complet des intervenants du projet Limagrain (client, intégrateur, partenaires).
### AD Customs — Éléments personnalisés
- **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.
### 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
- **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
- **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
- **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.
### 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.
### Glossaire Limagrain
- **Path:** limagrain/glossaire-limagrain.md
- **Type:** limagrain
- Termes et acronymes spécifiques au projet Limagrain, complémentaires au glossaire standard EasyWMS.
wiki_old_13-05-2026/_lint_report.md
+155
View File
@@ -0,0 +1,155 @@
---
title: "Wiki Health / Lint Report"
type: meta
generated: "2026-05-12"
scope: "134 pages (84 standard + 45 limagrain + 5 racine)"
---
# Rapport de lint complet — Wiki EasyWMS + Limagrain
**Date** : 2026-05-12
**Total fichiers analysés** : 134 (84 standard, 45 limagrain, 5 racine)
**Fichiers avec problèmes** : 95 (dont 81 uniquement LINE-LENGTH)
**Total problèmes** : 1820
## Résumé global par règle
| Règle | Total | Standard | Limagrain | Racine | Sévérité |
|-------|-------|----------|-----------|--------|----------|
| LINE-LENGTH (>120 car.) | 1761 | 1251 | 487 | 23 | Info |
| BROKEN-LINK | 33 | 0 | 21 | 12 | Erreur |
| 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)
Corrections sur le wiki **Limagrain uniquement** (le standard est en lecture seule) :
| Catégorie | Avant | Après | Action |
|-----------|-------|-------|--------|
| BLANK-LINES | 105 | 0 | Nettoyé sur 45 fichiers |
| BROKEN-LINK (vers standard) | 15 | 0 | Liens corrigés vers les bons fichiers |
| DUPLICATE-HEADING | 8 | 0 | Headings désambiguïsés |
| TRAILING-SPACE | 1 | 0 | Nettoyé |
| README.md tronqué | 1 | 0 | Fichier réécrit |
| **Total corrigé** | **130** | **0** | |
---
## Wiki standard — 15 problèmes (hors LINE-LENGTH)
> Le wiki standard est en **lecture seule** — ces problèmes sont documentés
> mais non corrigés.
### DUPLICATE-HEADING (5)
| 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
wiki_old_13-05-2026/_log.md
+823
View File
@@ -0,0 +1,823 @@
# Wiki EasyWMS — Compilation Log
(Les entrées les plus récentes en haut)
## 2026-04-17 — Batch 12: Robotique & intégration GALILEO (20 sources)
Sources ingérées (documentation interne robotique Mecalux France) couvrant : présentation GALILEO (rôle, architecture, SCADA), protocole WMS↔GALILEO (3 types de messages Event/Search/End + updates station/route), communication Easy↔Galileo via Gateway port 3000, fondamentaux de la robotique EasyWMS (stations, tâches, commandes, rangement automatique, double-profondeur), acronymes des éléments mécaniques (ES→EN), terminologie des convoyeurs (LRA/LRC/LBC/LRL/LTM/LRD/LRI + comportement tracking), catalogue TK (ML/MLB/EPSF/EPDF/ECDF), codes de stations (FR/ES/EN), configuration EasyS, configuration SmartUI (stations/routes), tests miniload Gateway, organisation projet robotique (équipe, DTR, planning), planning installation miniload, DTR configuration réseau, documents de référence, comprendre les logs Gateway (klogg, patterns), erreurs et défauts GALILEO (codes 1116/1201/1291, EndErrorCode 0-7), changer adresse WMS dans GALILEO, plan de tests stations, Automation Dashboard :
- `sources/Acronymes_elements_mecaniques.md`
- `sources/Automation_Dashboard.md`
- `sources/Bases_fonctionnement_robotique_EasyWMS.md`
- `sources/Catalogue_TK.md`
- `sources/Changer_adresse_WMS_dans_GALILEO.md`
- `sources/Codes_de_station.md`
- `sources/Communication_Easy_Galileo.md`
- `sources/Communication_WMS_GALILEO.md`
- `sources/Comprendre_logs_Gateway.md`
- `sources/Configuration_EasyS.md`
- `sources/Configuration_SmartUI.md`
- `sources/Convoyeur_terminologie.md`
- `sources/DTR_configuration_reseau_materiel.md`
- `sources/Documents_utiles.md`
- `sources/Erreurs_Defauts_GALILEO.md`
- `sources/Organisation_projet_Robotique.md`
- `sources/Plan_tests_stations.md`
- `sources/Planning_Installation_Miniload.md`
- `sources/Presentation_GALILEO.md`
- `sources/Tests_Miniload_Gateway.md`
Toutes archivées dans `sources/archives/` après ingestion.
### New pages created (5)
- `architecture/galileo-integration.md` — CREATED (Gateway topology port 3000, protocole 3 messages Event/Search/End, capacité stations PK/PS vs TK, workflows `Galileo_*EventHandler_PR`, commande `GalileoMovTrackingCreateCommand`, virtual location `Mov`, SCADA vs GALILEO vs WMS)
- `concepts/mechanical-elements.md` — CREATED (table acronymes ES→EN ~30 éléments, matrice codes stations FR/ES/EN 24 lignes, comportement tracking convoyeurs LRA/LRC/LBC/LRL/LTM/LRD/LRI, nomenclature miniload ML/MLB/EPSF/EPDF/ECDF)
- `operations/galileo-simulation.md` — CREATED (install Gateway, MainObject.config tenantCode/TokenUser/PasswordEncrypt, firewall port 3000, config EasyS rack/aisle/PLC types, config SmartUI stations/routes, TE/TS Logical X=991, LTM routing, PK setup, routes MP-extraction + MP-reject, injection PIE event, extraction manuelle 3 façons, Manual Action + Liberate, requête LINQ de synchro StationRoutes)
- `operations/galileo-troubleshooting.md` — CREATED (chemin log Gateway `C:\ProgramData\Mecalux\EasyWMS Gateway 2015\Logs\AllLog.log`, structure station/route updates, patterns klogg `DataInfo.+_CodeSupport_`, table EndErrorCode 0-7 avec résolution, procédure 4 étapes pour EndErrorCode=4, faults 1116/1201/1291, adresse WMS Confluence, checklist pré-escalade)
- `operations/robotics-project-lifecycle.md` — CREATED (parties prenantes chef de chantier / chef de projet IT / responsable électricité / responsable de projet, DTR, planning, documents de référence, tests stations avec requête LINQ d'audit, routes "full" CME→TE, PKE→PK, ET→PS, checklist pre go-live)
### Existing pages updated (6)
- `concepts/stations.md` — UPDATED (sources robotique : section Station Code Translation FR/ES/EN, Station Capacity Semantics PK/PS per-route vs autres per-station, Route configuration in EasyS)
- `concepts/putaway.md` — UPDATED (`Bases_fonctionnement_robotique_EasyWMS.md`, `Configuration_EasyS.md` : section "Putaway in an automatic warehouse (end-to-end)" 9 étapes, "Putaway logic by rack depth" single/double/>2-depth + marge emplacements vides 5% + double-depth Case #1/#2)
- `concepts/picking.md` — UPDATED (`Bases_fonctionnement_robotique_EasyWMS.md`, `Configuration_EasyS.md`, `Configuration_SmartUI.md`, `Tests_Miniload_Gateway.md` : sous-section "PK / MP setup and assignment mode" — workstation setup, types de route MP, max concurrent orders, assignment mode Automatic/Manual, 3 façons de déclencher l'extraction)
- `modules/automation-dashboard.md` — UPDATED (`Automation_Dashboard.md`, `Erreurs_Defauts_GALILEO.md` : table fault codes 1116/1201/1291, section Reference reports → Confluence)
- `architecture/overview.md` — UPDATED (`Presentation_GALILEO.md`, `Communication_WMS_GALILEO.md` : sous-section "Automation control system (TMS)" sous Warehouse Types — GALILEO vs EasyS + Gateway port 3000)
- `glossary.md` — UPDATED (nombreux termes robotiques ajoutés — voir ci-dessous)
### Glossary
- `glossary.md` — UPDATED avec termes robotiques ajoutés sur toutes les lettres : AP/APC/APR, APS200, ATC, Automatic Aisle (A) ; CME station (C) ; DeleteEmptyContainers, DTR (D) ; EasyS expanded, EasyWMS Gateway, End (message), EndErrorCode, Empileur, EMS, ECB, Event (message), ETQ (E) ; Galileo expanded, Galileo workflows, GalileoMovTrackingCreateCommand (G) ; IdentError, IMS (I) ; ME/TE, MS/TS, MP/TP, Miniload, Mov (virtual location), Manual Action, MT/MTB (M) ; PIE robotics view, PKE, PLC Container Type / PLC Height Type, Port 3000 (P) ; Reject route, Responsable de projet (robotics), Route (GALILEO) (R) ; SCADA, Search (GALILEO), SGA, Station update / Route update (S) ; TK (Transstockeur), TMS disambiguation (robotique vs carrier), Tracking (GALILEO) (T).
### Index
- `_index.md` — UPDATED (total 85 → 90 pages ; Concepts 32 → 33 (+mechanical-elements) ; Architecture 5 → 6 (+galileo-integration) ; Operations 16 → 19 (+galileo-simulation, galileo-troubleshooting, robotics-project-lifecycle) ; new "Batch 12 — Robotics & GALILEO Integration" section listée).
---
## 2026-04-17 — Batch 11: Fonctionnelles Mecalux France (16 sources)
Sources ingérées (Confluence EasyWMS France + menu RF) couvrant : ASN Transfer (ROF02), stratégies de réapprovisionnement (Routine/Conclure/Exiger + efficacité), validation des ajustements de stock (Count Profile), chargement camion SmartUI, déclencheurs d'impressions (BL, étiquettes, BL/feuille de route), process d'assignation de stock (`StockAssignProcess_*`), stratégies de remplissage de canaux, chariots à emplacement, changement de séquence SSCC via EasyS, création d'attribut logistique sans mode de capture, split marchandise réception (NEUT/ROUJE), réapprovisionnement inter-sous-entrepôts via zone intermédiaire, picking manuel (`ManualPicking_ByItem_UI`), fusion/merge de commandes (`DlvShareDeliveries`, `ALLOW_MERGE_DIFFERENT_ACCOUNT`), les 5 poids support + poids variable, et mapping complet des menus RFT :
- `sources/19_ASN_Transfer.md`
- `sources/20_Strategies_reapprovisionnement.md`
- `sources/21_Validation_ajustements_stock.md`
- `sources/22_Chargement_camion.md`
- `sources/23_Declencheurs_impressions.md`
- `sources/24_Process_assignation_stock.md`
- `sources/25_Strategie_remplissage_canaux.md`
- `sources/26_Utilisation_chariots_emplacement.md`
- `sources/27_Modification_sequence_SSCC.md`
- `sources/28_Creation_attribut_logistique_sans_capture.md`
- `sources/29_Split_marchandise_reception.md`
- `sources/30_Reapprovisionnement_2_sous_entrepots_zone_intermediaire.md`
- `sources/31_Picking_Manuel.md`
- `sources/32_Fusion_commandes_Merge.md`
- `sources/33_Les_poids.md`
- `sources/menu_rf_easywms.md`
Toutes archivées dans `sources/archives/` après ingestion.
### New pages created (3)
- `concepts/stock-assignment.md` — CREATED (source 24 — `StockAssignProcess_*` engine, 4 assignment types, customisation hooks)
- `concepts/weights.md` — CREATED (source 33 — 5 container weight fields, PIE behaviour, variable-weight items, worked examples)
- `architecture/rf-menu.md` — CREATED (menu_rf_easywms — 12 RFT menus mapped to entry workflows with `RFMenu_*`/`SharedMenu_*` codes)
### Existing pages updated (11)
- `concepts/reception.md` — UPDATED (sources 19, 29 : Transfer two-warehouse ASN flow, NEUT/ROUJE split strategy with 4 putaway strategies)
- `concepts/order-outbound.md` — UPDATED (sources 19, 32 : Transfer flow section with DirectTransfer comparison, Merge/Fusion section with eligibility, config, limitations)
- `concepts/replenishment.md` — UPDATED (sources 20, 30 : Routine/Conclure/Exiger SmartUI mapping, efficiency modes table, inter-sub-warehouse replenishment via transit Buffer, duplicate heading fix)
- `concepts/picking.md` — UPDATED (sources 26, 31 : Manual Picking flow + 3PL/Carrier conflicts, Location Carts with divisions and SmartUI setup)
- `concepts/shipping.md` — UPDATED (sources 22, 32 : Truck Loading SmartUI reference, Merge vs Load distinction)
- `concepts/stock-adjustment.md` — UPDATED (source 21 : Count Profile validation modes Never/Always/According to tolerance, tolerance parameters, SuperAdmin/Admin rights, French UI labels)
- `concepts/count.md` — UPDATED (source 21 frontmatter only)
- `concepts/container.md` — UPDATED (sources 27, 33 : SSCC prefix change procedure via EasyS, cross-ref to weights page)
- `concepts/product-item.md` — UPDATED (sources 28, 33 : "Creating a logistic attribute without a capture mode" section with Run Command procedure)
- `concepts/putaway.md` — UPDATED (source 25 : Channel strategy SmartUI configuration, mandatory criteria fields, reservation view)
- `concepts/labels.md` — UPDATED (source 23 : full Document & Label Printing Triggers reference — 10 document types with manual / XML-flag / event triggers)
- `concepts/stock.md` — UPDATED (source 24 : cross-ref to new stock-assignment page)
- `concepts/erp-interface.md` — UPDATED (sources 19, 32 : ROF02 note for Transfer, Transfer vs DirectTransfer SorType distinction, DlvShareDeliveries Merge message)
- `concepts/location.md` — UPDATED (source 30 : Transit buffer between sub-warehouses — Transport element pattern, Buffer type correction, routing)
### Glossary
- `glossary.md` — UPDATED with new terms: `ALLOW_MERGE_DIFFERENT_ACCOUNT`, Calculated Weight, Channel filling strategy, Conclure, Count Profile validation mode, Division (location cart), DlvShareDeliveries, Exiger, Fusion/Merge synonym, Location cart, LogisticAttributeCreateLogisticCaptureCommand, Manual Picking, NEUT/ROUJE pattern, Poids (five fields), Real Weight, ROF02 disambiguation, Routine, Scale Weight, SSCC prefix change, Stock assignment, `StockAssignProcess_*` workflows, Theoretical Scale Weight, Theoretical Weight, Transit buffer, Transfer (SorType), Variable weight.
### Index
- `_index.md` — UPDATED (total 82 → 85 pages ; Concepts 30 → 32 ; Architecture 4 → 5 ; new pages listed).
---
## 2026-04-17 — Batch 10: Fonctionnelles Mecalux France (18 sources)
Sources ingérées (Confluence EasyWMS France — lot fonctionnel couvrant stratégies de rangement, vidage de bacs, réapprovisionnement pendant picking, pré-colisage, picking dédié, cross-docking, gerbabilité, image article, modèles d'expédition, transactions, préparation papier, articles alternatifs, kits, comptage, classification ABC, flux tendu, tournées, ASN DirectTransfer) :
- `sources/01_Strategies_rangement_fonctionnement.md`
- `sources/02_Strategie_assignation_vidage_bacs.md`
- `sources/03_Reapprovisionnement_lors_picking.md`
- `sources/04_Gestion_preemballage_precolisage.md`
- `sources/05_Gestion_picking_dedie.md`
- `sources/06_Gestion_cross_docking.md`
- `sources/07_Gestion_gerbabilite.md`
- `sources/08_Ajouter_image_fiche_article_ITM01.md`
- `sources/09_Modeles_expedition.md`
- `sources/10_Transactions.md`
- `sources/11_Preparation_papier.md`
- `sources/12_Articles_alternatifs.md`
- `sources/13_Gestion_KIT.md`
- `sources/14_Processus_inventaire.md`
- `sources/15_Configuration_ABC.md`
- `sources/16_Tense_Flow.md`
- `sources/17_Fonctionnement_routes_tournees.md`
- `sources/18_ASN_DirectTransfer.md`
Toutes archivées dans `sources/archives/` après ingestion.
### New pages created (2)
- CREATED `concepts/prepackaging.md` (source 04) — Stratégie de prépackaging (Préemballage/Précolisage) ; configuration au niveau type d'ordre d'expédition ; bloc XML `<PrpPackagingConfiguration>` dans SOR02 ; comportements testés par type ; différences avec VAS
- CREATED `concepts/tense-flow.md` (source 16) — Configuration zone Flux Tendu dans EasyS ; flux fonctionnel en 4 étapes (lancement → exécution picking → picking virtuel → fin de flux) ; différences avec le cross-docking opportuniste
### Existing pages updated (12)
- UPDATED `concepts/putaway.md` (source 01) — Workflow de configuration SmartUI : gestion de la séquence, onglet Critères, onglet Règles (Mode de stockage, Valable si, cases à cocher de restriction, Order locations) + activation / désactivation / édition
- UPDATED `concepts/picking.md` (sources 02, 03, 11) — Mode efficacité **Vidage de bacs** (3 workflows principaux) ; table détaillée des 3 paramètres `PICKING_ALLOW_*` pour l'attente de réapprovisionnement + flux opérateur ; procédure complète **Paper Picking** (7 étapes) ; ajout des 3 paramètres dans le tableau Parameters ; cross-ref vers tense-flow
- UPDATED `concepts/shipping.md` (sources 09, 17) — Gestion des **modèles d'expédition** : champs de base, onglets par type d'ordre, Scheduler, onglet Critères, exemples LINQ ; section **fichier RUT (routes TMS)** en 5 étapes ; cross-ref vers prepackaging
- UPDATED `concepts/crossdocking.md` (source 06) — Notes d'installation EasyS/SmartUI Mecalux France (configuration du rack, zone Cross docking, priorité de stratégie position 1, avertissement sur les critères) + comportements connus (réception uniquement RFT, buffer-over-dock, XD override de réserve, pas d'impression d'étiquette)
- UPDATED `concepts/replenishment.md` (source 05) — Configuration **PDL** EasyS/SmartUI : cases EasyS (Allow product location, Allow replenish at source, Allow picking), champs SmartUI, tip formatage étiquette, limitations connues (destination non affichée, max pas appliqué, min fonctionne)
- UPDATED `concepts/count.md` (source 14) — Clarification Blind vs Informed : le flag FR `Est renseigné` est positionné par ligne dans SmartUI + workaround `CountOrderLineVList` ; procédure **comptage d'articles à numéros de série** (4 étapes)
- UPDATED `concepts/product-item.md` (sources 07, 08, 12, 15) — **Classification ABC** : principes de fonctionnement, Inclusive/Exclusive, règles de paramétrage, première assignation, paramètres d'évaluation, interprétation des lignes rouge/verte, notification SAC ; gerbabilité 0-10 (`ITM01 <Stack>`) ; image article (local vs URL) ; section **Articles de remplacement / Substituts** : flag SOR `<LneTrmAlternative>`, 3 modes de profil d'expédition (Partiel/Substitution/Tout ou rien), table des substituts, matrice SOF `LneDIsAlternative`
- UPDATED `concepts/kits.md` (source 13) — Pré-requis profil Version ; procédure SmartUI de création ; cycle de vie **WO** : 4 modes de création (ERP / SmartUI / RFT / Automatique), modifications autorisées par statut ; approvisionnement zone kit + clôture du WO + gestion de la pénurie (comparaison Montage sur demande OUI/NON)
- UPDATED `concepts/transactions.md` (source 10) — Section **Regeneration from SmartUI** : depuis SmartUI Interface > Communications, statuts `Envoyé` ou `Génération d'erreur` permettent de régénérer le fichier ERP (les modifications BOO sont appliquées à la régénération)
- UPDATED `concepts/order-outbound.md` (sources 12, 18) — Type `Direct transfer` cross-référencé ; section **ASN — DirectTransfer flow** (préparation, RFT menu Réception > Préavis, génération ASO01, suppression SmartUI → ASK01, avertissement absence d'info d'origine) ; section **Articles alternatifs** (flag SOR XML)
- UPDATED `concepts/reception.md` (source 18) — Sous-section **DirectTransfer — inter-warehouse ASN flow** dans la section ASN Reception : réception via RFT menu Réception > Préavis, cross-ref vers order-outbound
- UPDATED `concepts/erp-interface.md` (sources 08, 18) — Section **ITM — Image fields** (modes `<ItmPicture>` local vs `<ItmPictureUrl>` + setting `UserImagesURI`) ; triggers DirectTransfer dans ASO et ASK ; mention `SorType = DirectTransfer` dans SOR
### Glossary updated
- UPDATED `glossary.md` — 14 nouveaux termes : **ABC Inclusive / Exclusive**, **DirectTransfer**, **Est renseigné (Count)**, **Flux tendu**, **Gerbabilité (Stackability)**, **LneTrmAlternative**, **LneDIsAlternative**, **Montage sur demande**, **Prepackaging (Préemballage/Précolisage)**, **SAC**, **Substitute item**, **Tense flow** (étendu avec référence explicite), **Tournée (Route/RUT)**, **UserImagesURI**, **Vidage de bacs (Bin Emptying)**
### Index
- UPDATED `_index.md` — Total pages 80 → 82 ; section Concepts 28 → 30 (ajout prepackaging + tense-flow)
---
## 2026-04-17 — Batch 9: Dev Workflow Tooling, Reviews & Project Lifecycle (Mecalux France, 9 sources)
Sources ingérées (Confluence EasyWMS France — second lot post-déploiement, couvrant l'outillage SSH/réseau, l'export uGNA, le cycle de vie Git par phase de projet, le déploiement en test, et les revues code/fonctionnel/documentation) :
- `sources/Configuration_cle_SSH_MSSCODE_Sourcetree.md` — v2 (28/01/2026)
- `sources/Routage_vers_les_VM.md` — v7 (11/08/2023)
- `sources/Export_donnees_uGNA.md` — v5 (18/10/2023)
- `sources/Gestion_du_GIT.md` — v1 (27/02/2024)
- `sources/Deployer_application_en_test.md` — v1 (20/12/2022)
- `sources/Revue_Code.md` — v10 (08/01/2026)
- `sources/Revue_Fonctionnel.md` — v2 (27/02/2024)
- `sources/Revue_Documentation.md` — v3 (04/03/2024)
- `sources/Retirer_popup_connexion.md` — v1 (20/12/2022) — **page Confluence vide** : aucune page wiki créée, source archivée pour ne pas être retraitée
### New pages created (6)
- CREATED `operations/ssh-keys-setup.md` (source: Configuration_cle_SSH_MSSCODE_Sourcetree)
- Génération clé SSH ed25519 via Git Bash (`ssh-keygen -t ed25519 -C ...`), passphrase obligatoire et non modifiable
- Enregistrement sur MSSCODE + **vérification renforcée** par signature SSH (jeton unique non copiable depuis la doc — toujours utiliser celui fourni en direct)
- Configuration Sourcetree : OpenSSH + désigner la clé privée
- **Cloner via SSH** (et non HTTPS) sinon Sourcetree continue à demander les identifiants MSSCODE
- Common errors : `Permission denied (publickey)`, mot de passe oublié → régénération obligatoire
- CREATED `operations/vm-network-routing.md` (source: Routage_vers_les_VM)
- Tableau NAT Hyper-V : ports externes PC (8080/4430/33890/15210/4450 + n°2 pour 2e VM) ↔ ports internes VM (80/443/3389/1521/445)
- Accès local (depuis VM) : `localhost:4430` ou `https://<nom_vm>/smartui/`
- Accès distant (depuis autre PC) : IP du PC hôte + port externe (`192.168.x.x:4430`, `:33890` pour RDP)
- VPN Mecalux : `vpn-europa@mecalux.com:4443` ou `vpn-europa4@mecalux.com:443` pour délégations Europe
- Conflit ZAPP/Zscaler APP → désinstaller + reboot ; sinon ticket `No Hyper-V NAT connectivity` à `it@mecalux.com`
- Commandes utiles : `Get-NetAdapter`, `Get-NetNatStaticMapping`
- CREATED `operations/ugna-data-export.md` (source: Export_donnees_uGNA)
- Procédure : CMD admin (pas PowerShell) + `uGNAConsole.exe -Z:<41 entités>`
- Liste exhaustive des 41 entités exportées, regroupées par domaine (Owners/Items/Suppliers/Profils/Stratégies/Stations/Locks/Configurations diverses)
- XML générés dans `Mecalux\uGNA\Export` → à copier vers `..\test` du Git du projet → commit + push
- **Prérequis** : VM à jour vis-à-vis du Git (sinon risque d'export de données supprimées)
- Erreur de droits sur `Program Files (x86)\Mecalux\uGNA` → propriétés sécurité, ajouter Contrôle total
- CREATED `operations/git-branch-lifecycle.md` (source: Gestion_du_GIT)
- Stratégie Git **par phase de projet** (orthogonal à git-workflow qui couvre la mécanique opérationnelle quotidienne)
- 5 phases couvertes : Développement initial → Avant MEP → Hypercare → TLM → TMA
- Acteurs définis : Dev / Dev Principal / CdP / Support / TMA
- Règle bloquante : Support refuse le passage TLM si `develop` est encore présente
- Branches `hotfix` (Support) / `release` (TMA) : 2 cas Support (modifs longues vs directes en prod), 7 étapes TMA pour gérer une `release`
- **Communication bi-directionnelle Support↔TMA** sur chaque livraison (sinon conflits massifs ou régressions)
- Schéma ASCII du cycle de vie + common errors
- CREATED `operations/deploy-test-application.md` (source: Deployer_application_en_test)
- Procédure 7 étapes pour livrer un lot de dev aux CdP sur la **VM de test partagée** (distincte des VM de dev)
- Convention de nommage du tag : `<TRIGRAMME_PROJET>-V<NUMERO>` (identique à deployment-specific-commit)
- Étapes : tag sur `develop` (push tag obligatoire) → checkpoint "Deploy 0" → déploiement via `deploy_repository.ps1` → réinstallation GNA si modifs BOO → printer service + licence → validation VM → transition Jira "Prêt à tester" avec **tag obligatoire**
- Justification du tag (vs déploiement direct de `develop`) : version reproductible, garantie sans bug postérieur, démo client safe
- Cross-références fortes avec deployment-existing-app, gna-services-license, vm-installation, vm-network-routing
- CREATED `operations/code-review-process.md` (sources: Revue_Code + Revue_Fonctionnel + Revue_Documentation — 3 sources fusionnées en 1 page)
- **Section 1 — Revue Code** : OutboundLines vs OutboundOrderLines (writing), kits sans assemblage (`OutboundOrderOutboundOrderLineDetails` = composants, `OutboundLines` = kit), `ProductConversion` peut être null, blocs `//StartCustom`/`//EndCustom`, préfixe `CST_` (3 questions : visible client / nommage modifiable / élément haut niveau), nommage viewfields/SmartUI/attributs/paramètres workflow/dialogues/requêtes, `ProcessContext.EnterAction`/`EscapeAction` (pas de string en dur), `FirstOrDefault()` sécurisé
- **Section 2 — Revue Fonctionnelle** : exécution cas de test Jira (ou cas standard), test `Échap` sur dialogues
- **Section 3 — Revue Documentation** : Jira commentée, vérification Git (historique → détection modifs hors périmètre causée par custom app importée à un autre niveau de branche), Reten Markdown (3 cas : process modifié → chapitre process / non-process → tableau fin / custom attributes → section "1.2 General custom elements")
- Décision : 1 seule page combinée (et non 3 pages séparées) car les 3 revues forment un workflow unifié pré-merge
### Pages updated (7)
- UPDATED `operations/git-workflow.md` — frontmatter `related:` enrichi (+git-branch-lifecycle, +ssh-keys-setup, +ugna-data-export, +code-review-process) ; lien interne vers `ugna-data-export.md` au lieu de la doc Confluence externe ; section Related étoffée
- UPDATED `operations/development-methodology.md` — frontmatter `related:` enrichi (+git-branch-lifecycle, +git-workflow, +code-review-process, +deploy-test-application)
- UPDATED `operations/vm-installation.md` — frontmatter `related:` enrichi (+vm-network-routing, +deploy-test-application)
- UPDATED `operations/custom-application-management.md` — frontmatter `related:` enrichi (+code-review-process)
- UPDATED `operations/gna-services-license.md` — frontmatter `related:` enrichi (+ugna-data-export, +deploy-test-application)
- UPDATED `operations/deployment-existing-app.md` — frontmatter `related:` enrichi (+deploy-test-application)
- UPDATED `glossary.md` — ajout de **15 nouveaux termes** (CdP, CST_, EnterAction/EscapeAction, Hypercare, MEP, MSSCODE, NAT, OutboundLines vs OutboundOrderLines, ProductConversion, Reten, TLM, TMA, Trigramme projet, uGNA/uGNAConsole, VPN Mecalux, ZAPP/Zscaler) ; `last_compiled` 2026-04-10 → 2026-04-17
- UPDATED `_index.md` — total 74 → 80 pages ; ajout section "Batch 9 — Dev Workflow Tooling, Reviews & Project Lifecycle (Mecalux France)" sous Operations (6 pages) ; en-tête "Operations (10 pages)" → "Operations (16 pages)"
### Source non ingérée
- `sources/Retirer_popup_connexion.md` — la page Confluence est vide (`Cette page ne contient pas encore de contenu sur Confluence`). Aucune information à ingérer. Source archivée dans `sources/archives/` pour ne pas être retraitée. Les pop-up de connexion SmartUI restent référencées comme cas de bord dans `operations/git-workflow.md` (sans procédure dédiée).
### Rationale
Ce batch complète **par le bas** la chaîne de déploiement déjà couverte par le batch 8 :
```
Batch 8 (cycle VM/projet) Batch 9 (outillage + gouvernance)
───────────────────────── ────────────────────────────────
vm-installation ←─→ vm-network-routing
ssh-keys-setup
first-deployment
deployment-existing-app ←─→ deploy-test-application (cas spécifique)
deployment-specific-commit
custom-application-management ←─→ code-review-process
git-workflow ←─→ git-branch-lifecycle (gouvernance par phase)
ugna-data-export (étape pré-commit explicitée)
gna-services-license
```
Les 6 nouvelles pages se positionnent comme **outils transverses** (SSH, NAT/VPN, uGNA) ou **gouvernance haut niveau** (cycle de vie projet, code review) — orthogonales aux procédures techniques du Batch 8 mais étroitement cross-référencées. Aucune modification du domaine produit (concepts/modules/architecture).
**Choix de fusion** : les 3 sources Revue_* sont consolidées dans une seule page car elles forment un workflow unifié (revue avant `Finish Feature`) et restent compactes individuellement. Le glossaire centralise les termes transverses (TLM, TMA, MEP, Hypercare, Reten, CdP, MSSCODE, NAT, ZAPP) qui apparaissent dans plusieurs des nouvelles pages.
## 2026-04-17 — Batch: Deployment Workflow Ingestion (Mecalux France, 7 sources)
Sources ingérées (Confluence EasyWMS France — documentation interne sur l'installation de VM et le cycle de déploiement projet) :
- `sources/Installation_VM_Hyper-V.md` — v30 (02/12/2025)
- `sources/Valider_sa_machine_virtuelle.md` — v7 (14/02/2023)
- `sources/Premier_deploiement.md` — v39 (07/08/2025)
- `sources/Deploiement_application_existante.md` — v20 (04/07/2024)
- `sources/Deploiement_VM_commit_specifique.md` — v3 (09/06/2023)
- `sources/Gestion_custom_application.md` — v12 (20/12/2022)
- `sources/Gestion_versions_projet_GIT.md` — v27 (22/08/2025)
- `sources/Installation_Services_Licence_WMS.md` — v19 (15/04/2025)
Note : le fichier `sources/files.zip` n'est pas ingéré (archive binaire non textuelle).
### New pages created (7)
- CREATED `operations/vm-installation.md` (sources: Installation_VM_Hyper-V + Valider_sa_machine_virtuelle)
- Combine création VM Hyper-V + validation post-déploiement (deux procédures complémentaires)
- Procédure complète : récupération template `TEMPLATE_INTEGRATION_[DB]` (Oracle On-Premise / PostgreSQL SaaS), création VM Génération 2 (RAM 4→6 Go, 4 CPU, InternoNAT/VMs), config réseau IPv4 10.255.255.2 + 4 DNS Mecalux + suffixe `mecalux.com`, renommage (≤15 caractères Oracle, MAJ `tnsnames.ora`/`listener.ora` avant reboot), installation Git, point de contrôle "Deploy 0"
- Validation : MongoDB démarré, IIS Browse sur AD/ApplicationService/EasySTS/SmartUI/SmartUIServices, fallback `localhost/smartui` dans navigateur VM, `defaultURL` vide dans `SmartUI\script\config.js` pour accès PC hôte, `EnableLegacyRFMode` 2e checkbox pour consoleRF
- CREATED `operations/first-deployment.md` (source: Premier_deploiement)
- Premier déploiement d'un projet neuf (exécuté une seule fois par projet)
- `DeployConfig.yaml` détaillé : TenantName/TenantCode, DBEngine (Oracle/PostgreSQL/SQLServer/MySQL), MAPSeed (versions mapdeploy), License (PRO/ADVANCE/ENTERPRISE), Warehouse (layout_config/*.cfg2014), Data (test/), StandardApplications (miroir `<ExtraApps Use="Yes">`), EnabledModules (miroir `<Modules>` sans EasyWMS + ToggleService pour versions ≥24.xx), Users
- Procédure script unifié : `deploy_repository.ps1 <Projet> [Branche]` ; fallback anciens scripts `deploy.ps1 (1. Complete / 2. Load)` + `Commands\commands.ps1`
- Étape 8 OBLIGATOIRE : Tenants.xml → `providerName="InMemory"` + `iisreset` ; astuce Notepad++ regex multi-tenant
- Création custom app initiale + renseignement de `Customs:` dans DeployConfig (étape 10)
- CREATED `operations/deployment-existing-app.md` (source: Deploiement_application_existante)
- Redéploiement d'un projet existant (nouveau dev, changement de branche, mise à jour)
- Procédure script unifié (same as first-deployment mais sans création de custom app)
- Étape Tenants.xml InMemory OBLIGATOIRE à chaque redéploiement (fichier régénéré)
- Version minimale supportée par `deploy_repository.ps1` : 21.1.19.2
- CREATED `operations/deployment-specific-commit.md` (source: Deploiement_VM_commit_specifique)
- Déployer sur un commit figé : tag Git + branche dédiée + deploy par branche
- Convention de nommage : `<PREFIXE_JIRA>-V<NUMERO>` (ex: SPEN-V1/SPEN-V2)
- Procédure SourceTree : Fetch "all tags" → clic droit Tag → push tag → clic droit Branch → push branch → `deploy_repository.ps1 <Projet> <Branche>`
- Cas d'usage : reproduction de bug, démo stable, tests de régression, hotfix candidate
- CREATED `operations/custom-application-management.md` (source: Gestion_custom_application)
- Création EasyBuilder : Option A (depuis FRANCE_OPERATIONS_TOOLS, ex: Module transporteur) / Option B (vierge avec dépendance EasyWMS)
- Import : delete app existante → `Import and save application from text` depuis `..\source\NomApplication`
- Export : **vider dossier destination + être sur branche de tâche + aucun Check-out** → `Export application to text`
- Fichiers séparés en plusieurs pour un même élément (workflow + C# + DESIGN) — tout stager
- Règles coexistence multi-devs : export en fin de tâche, import après merge dans develop
- CREATED `operations/git-workflow.md` (source: Gestion_versions_projet_GIT)
- Procédure Git Flow CLI + SourceTree pour projets EasyWMS France
- `git flow init -d` avec préfixes standards (feature/bugfix/release/hotfix/support)
- `git flow feature start/finish -r` (rebase obligatoire), gestion conflits (`git add` + `git rebase --continue` / SourceTree stage + Continue Rebase sans re-commit + re-clôture sans cocher "Rebase")
- Règle absolue : commit + push TOUS LES SOIRS (perte/vol/casse PC)
- Pré-requis avant commit : export custom app + export uGNA (si params/config modifiés) + `GNAGetDataForGit.ps1` (si BOO modifiés)
- Tableau des types de branches Git Flow avec préfixes, source, destination, objet
- Pop-up SmartUI post-déploiement référencée
- CREATED `operations/gna-services-license.md` (source: Installation_Services_Licence_WMS)
- GNA — Sauvegarde GIT : `GNAGetDataForGit.ps1` depuis `InstallApplications` (`C:\deploy\Prof.Serv.Deploy\InstallApplications` en automatique) ; export XSD_Source only (jamais XSD composé → évite duplications) ; exemple composition SOF02 (EasyWMS + Deliveries + VAS) ; chemins `responses.xml` à ajuster (`C:\ProgramData\…` → `C:\Program Files\…` avec nouveau deploy) ; destination GIT `\services\GNA`
- GNA — Réinstallation : `InstallApplication.zip` → fusion avec `\services\GNA` GIT → `responses.xml` + URL `FromGIT` → `GNA.zip` (Config/Scripts/TaskDefinitions/XSD) → `DeployCommsApps.ps1 complete`
- Label Printer : lien Confluence dédié (non reproduit)
- Licence WMS : export depuis `https://<VM>/EasySTS/License` → demande aux chefs d'équipe / directeur technique / support espagnol → import via "Submit license" pour dépasser les 7 jours par défaut
### Pages updated (1)
- UPDATED `_index.md` — total 67 → 74 pages ; ajout section "Batch 8 — Deployment Workflow (Mecalux France)" sous Operations (7 pages) ; en-tête "Operations (3 pages)" → "Operations (10 pages)"
### Rationale
Les 7 sources forment une chaîne cohérente qui couvre le **cycle de vie VM/projet côté développeur Mecalux France** :
```
VM Installation → First Deployment → (development) → Git Workflow → Custom App Management
↓
Deploy Existing / Deploy Specific Commit
↓
GNA Services & License
```
Ce cycle est **orthogonal au produit EasyWMS lui-même** (concepts/modules/architecture qui décrivent le WMS côté fonctionnel et technique). Il s'inscrit dans la même catégorie opérationnelle que le précédent ingest `development-methodology.md` (stratégie de branches), qui reste la "vue d'ensemble" — les 7 nouvelles pages sont les procédures concrètes qui l'instancient.
Les cross-références ont été construites pour refléter la séquence temporelle typique : `vm-installation` → `first-deployment` → `git-workflow` + `custom-application-management` → `deployment-existing-app` (au quotidien) / `deployment-specific-commit` (cas particulier) / `gna-services-license` (à chaque modif BOO).
Aucune page concept/module/architecture existante n'a été modifiée — le domaine couvert ne touche pas au produit mais au processus de déploiement.
## 2026-04-17 — Ingest: sources/Présentation_méthode_de_développement.md
Source ingested: `sources/Présentation_méthode_de_développement.md` — Confluence EasyWMS France (v8, 29/12/2023). Document interne Mecalux France décrivant la méthode de développement des custom applications EasyWMS : stratégie de branches GIT, phases dev/test/post-production, gestion du manuel de reten.
### New pages created (1)
- CREATED `operations/development-methodology.md`
- Nouveau thème : méthodologie de développement des custom apps (non couvert dans le wiki existant)
- Stratégie de branches GIT : `master` (production), `développement` (intégration), branches individuelles par développeur, `post-production` (correctifs post-MEP)
- Phase de développement : 1 machine + 1 branche GIT par dev, redéploiement custom app après merge/rebase, manuel de reten en Markdown
- Phase de tests : déploiement sur serveur de test dédié, testeurs n'ont pas besoin de monter de machine locale, 2 options de correction de bugs
- Post-production : master = état de production courant, branche `post-production` créée après MEP et mergée **uniquement avant la MEP suivante** pour éviter d'écraser master
- Schéma ASCII du flux de branches + règles pratiques + common errors
### Pages updated (1)
- UPDATED `_index.md` — total 66 → 67 pages; nouvelle entrée `operations/development-methodology.md` dans section Operations (Batch 7)
### Rationale
Le document source n'a aucune intersection avec les pages concepts/modules/architecture existantes (qui décrivent le produit EasyWMS lui-même). Il traite du **processus de développement interne** Mecalux France pour les extensions custom — thème orthogonal au reste du wiki, d'où création d'une page dédiée dans `operations/` (cohérent avec `configuration-guide.md` qui traite de l'opérationnel de déploiement).
## 2026-04-26 — Batch: Functional Analysis Ingestion (custom/analyse_fonctionnelle.md)
Source ingested: `wiki-full/custom/analyse_fonctionnelle.md.md` — 68,757 tokens, French-language functional analysis template (Mecalux client implementation document covering the full EasyWMS feature set with concrete operational detail).
### New pages created (1)
- CREATED `concepts/kits.md` (sources: analyse_fonctionnelle.md + erp-interface cross-reference)
- First compilation of this concept (was in schema.yaml but never compiled)
- Kit types: without assembly, with ERP-driven assembly, with on-demand assembly; SAGE 100C mapping (Fabrication/Commercial/Linked nomenclatures)
- Assembly lifecycle: WOR → pick tasks → KST.CON + STK.KIT transactions → WOF (if ERP-originated)
- Disassembly lifecycle: WOR → UNK.CON + STK.UNKIT → WOF (if ERP-originated)
- Quartering type: 1 raw material → multiple finished goods selections
- Common errors + related pages
### Pages updated (12)
- UPDATED `concepts/stock.md`
- Added UoM to stock line uniqueness key (Item + Owner + Location + Container + Logistic attributes + **Status + UoM**)
- Added explanatory note with example (same SKU in 2 lots = 2 stock lines)
- Added STV delta note: quantity in STV = what changed (delta), not remaining stock; ERP must accumulate or use SCR/WSC
- Added WSC/SCR usage detail: grouped vs detailed, include-zeros option, on-demand or scheduled
- Added Double validation section: Pending→Validated/Cancelled; never/always/by-tolerance per item (inventory profile)
- Added user status detail: 9 actions configurable per status (picking/replenishment/inventory/reception/internal consumption/shipping/collection/movement/reservation)
- Added STC01 trigger: auto-sent on any user status change
- UPDATED `concepts/product-item.md`
- Added profile examples tables (logistic: PROFIL_SIMPLE/DLC/LOT/SN; reception: PROFIL_SIMPLE/QUALITE; shipping: PROFIL_FIFO_MANU/SCAN/FEFO)
- Added to item attributes: free fields (up to 20), minimum stock alert threshold, picking alert message
- Added Multi-Carrier packaging method to item families section (scan all / choose count / always 1 parcel; most restrictive wins)
- Added "Item base management (lifecycle)" section: ERP deactivation → WMS deletion flow, WMS can only delete if no active stock/tasks, performance degradation warning
- Added SAC01 to ERP integration table + ABC rotation recalculation details (whole warehouse or zone, configurable period, indicative result, trigger SAC01 after manual apply)
- Added kits cross-reference to Related section
- UPDATED `concepts/erp-interface.md`
- Fixed bug: MOF direction was listed as "ERP → WMS" → corrected to "WMS → ERP" (manufacturing order finalization)
- Added Manufacturing messages: RCP01/RCP02 (recipe management), MOR01 (production orders), MOF (WMS→ERP finished goods), FGP (WMS→MES)
- Added Kit messages: WOR/WOF/KST/UNK with correct directions and triggers
- Added Store Fulfillment messages: TOR01 (ERP→WMS), TOF01 (WMS→ERP), TPV01 (ERP→WMS POS)
- Added VAS messages: VAS01 (ERP→WMS), SOR02 VASCode field, SOF VAS field
- Added Slotting: SAC01 (WMS→ERP ABC rotation suggestion)
- Added detail paragraphs for SAC01, TPV01, TOR01/TOF01
- UPDATED `modules/manufacturing.md`
- Expanded production line definition: supply buffer zone + production buffer zone; only 1 active MO per station
- Added raw materials, finished goods, additives entity definitions
- Added "Consumption mode" section: automatic (FEFO, additives) vs manual (operator declares each MP); TRF manual process steps
- Expanded manufacturing profile: 3 settings (lot generation process, days before expiry, days before DLUO)
- Added MO lifecycle flow diagram (ERP→Pending→Released→supply tasks→operator supply→PF declaration→consumption→close→MOF)
- Added damaged finished goods section (PF not created; MP still consumed; quantity still counted)
- Added rebuts (scrap) at MO closing: count as consumed; visible post-close
- Added MO closing TRF process (6 steps; if actual MP < declared: excess MPs returned; can't declare more PF than already declared)
- Added traceability detail (MP lot → PF lot; quality event tracking)
- Added recipe management via SmartUI (Masters → Manufacturing)
- UPDATED `modules/billing-3pl.md`
- Expanded billing rules from simple 2-type description to full 3-group structure:
- Group 1 (Storage): 5 sub-types (container/location/UoM/weight/volume) — snapshot-based counting
- Group 2 (Handling): 6 sub-types (container/work orders/order lines/weight/UoM/volume) — flow-based counting; operations covered (inbound/outbound/loads/routes/counts/kits)
- Group 3 (Transaction): custom rules with transaction type + owner param + quantity param + operation type (Increment/Decrement/Variable)
- Added "Billing notifications" section: 6 event types (bill sent auto, bill pending validation, bill corrected, bill cancelled, contract expired, contract about to expire)
- Added notification channels: email, SMS, SmartUI contextual notification
- UPDATED `architecture/security.md`
- Added QR Code login section: anonymized data (cannot derive username/password from lost code); reprinting invalidates previous code; incompatible with SSO
- Added SSO section: SAML V2.0 only (no other SSO protocol); available on PC and TRF; SSO disables all other login methods for that user; SSO and QR Code mutually exclusive
- UPDATED `architecture/overview.md`
- Updated DB options: Oracle 19c / SQL Server 2019 / MySQL 8.0.14+ / PostgreSQL 14+ (not just Oracle or PostgreSQL)
- Added on-premise hardware specs table: DB server (4-core @3GHz, 32GB, 600+50GB) and App server (same CPU/RAM, 200GB)
- Added SaaS tiers table: 3 tiers on Azure; Basic = 2-core/7GB/10users/200orders-per-day; Standard/Advanced contact Mecalux
- UPDATED `concepts/picking.md`
- Added order priorities section: Urgent/High/Normal/Low/Very Low
- Added order quantity states section: Assigned/Prepared/Loaded/Shipped (4 stages of order execution visibility)
- Added shipment templates section: 15+ selection criteria (carrier/client/owner/destination/order type/class/typology/stock check/item type/family/danger/crossdocking/ungrouping zone/packing zone/custom); scheduling (time-based or on-demand); priority ordering within template
- Added order fusion section: manual-only; same client + destination required; reversible before picking
- UPDATED `concepts/replenishment.md`
- Expanded PDL threshold types: 3 types (pieces/container count/% of full container); notes on when each requires container-count knowledge
- Added "Dynamic Picking Emptying Tasks (Vidage)" section: automatic clearing of dynamic PDLs after order completion; relocation tasks generated on schedule; putaway engine determines destination; prevents stranded stock
- UPDATED `modules/multi-carrier.md`
- Added "Supported Carriers" section: 18+ carriers (STEF/XPO/Kuehne+Nagel/MRW/Nacex/DB Schenker/SEUR/Geodis/FedEx-TNT/DPD/Chronopost/Colissimo/DHL/UPS/GLS/Mondial Relay/Delivengo/BPOST/Custom)
- Added online vs offline modes distinction
- Added "Packing methods" section: 3 methods (scan all items/choose parcel count/always 1 parcel); precedence rule (most restrictive wins); configurable at warehouse/family/client/owner levels
- UPDATED `modules/store-fulfillment.md`
- Added ERP integration table: TOR01 (ERP→WMS transfer order), TOF01 (WMS→ERP finalization), TPV01 (ERP→WMS POS sale/return)
- Rewrote POS integration flow to include TPV01 message and real-time decrement detail
- Added "Real-time store stock view" section: current stock, in-transit stock, TPV01 history
### Index & log
- UPDATED `wiki/_index.md` — total updated from 65 to 66 pages; added kits.md entry; updated module descriptions for billing-3pl, manufacturing, multi-carrier, store-fulfillment; added kits to product-item entry
## 2026-04-10 — Health Check & Lint (full wiki audit)
- CREATED `wiki/_lint_report.md` — comprehensive health check of all 65 pages
- 14 orphan pages identified (cobot, movirack, slotting, labor-management most critical)
- 23 one-way links found (dom↔orders, slotting↔location most impactful)
- 4 content contradictions found (1 critical, 2 high, 1 low)
- 9 missing concept pages identified (wave, kit, sub-warehouse = tier 1 priority)
- 7 glossary gaps documented
- FIXED `concepts/shipping.md` — Critical: rewrote ERP Integration table (ASO→SOR, SCO→SOF/SOF02, ROF→removed, STV→LOF); fixed Overview to reference SOR and link to order-outbound.md for canonical lifecycle
- FIXED `modules/pallet-shuttle.md` — PS charge station type corrected from "RECH/REAC" to "66 (PSCharge)"
- FIXED `operations/configuration-guide.md` — same PS charge station type correction
- FIXED `modules/slotting.md` — source path typo `areas/slottingting/` → `areas/slotting/`
## 2026-04-10 — Batch 7: Operations & Finition (8 pages + lint)
- CREATED `operations/troubleshooting.md` (sources: all 56 previously compiled wiki pages — Common Errors sections synthesized)
- Organized by symptom category (14 sections): Inbound/Reception, Putaway, LPN/Container, Stock & Inventory, Picking, Shipping, Replenishment, Count/Stock Adjustment, Quality Control & Locks, Tasks & Automation, AGV & Pallet Shuttle (full error code table 1001–2503), ERP Integration, System/Infrastructure, Master Data & Configuration
- Total: ~80 error entries with cause + solution; cross-references to Parameters, ERP Interface, Transactions, Security, Architecture pages
- CREATED `operations/configuration-guide.md` (sources: configurations/ folder 10 files + parameters.md + architecture/overview.md)
- Sections: Pre-deployment checklist (IIS/DB/WIFI/EasyS), Warehouse Layout (EasyS sections 1.1–1.4: zones/location types/stations/equipment), Master Data, Reception (PIE/dock/returns config + parameters table), Putaway (strategy sequence/restrictions/PDL/intermediate stations), Picking (PTL config/workstation/waves), Replenishment (strategy types/dynamic/drawer locations), Count (location prereqs/lock types/cycle count/double validation), Crossdocking (3-step config), Quality Control (stock statuses/unlock job/receiving status), ERP Integration (message pairs/integration pool/API keys), Module-specific (Multi-Carrier/SCEM/Yard Management/LMS/3PL Billing/AGV/Slotting), Security (roles/station roles/owner isolation), Parameter reference summary
- CREATED `wiki/glossary.md` (sources: all 56 compiled wiki pages — terms extracted)
- ~120 entries alphabetically organized: A-Z
- Covers: product names (EasyS/SmartUI/PIE/PDL/LPN/SSCC/EAN/GTIN/GS1-128), abbreviations (AGV/PS/APS/SCEM/DOM/LMS/VAS/3PL/PTL/XD/RFT/IIS), AD element types (Command/Query/Entity/View/Dialog/Event/Workflow), ERP message codes (all ~30 codes), transaction prefixes (CON.*/STK.*/TSK.*/COU.*/INO.*/OUT.*/ROU.*/LOAD.*), key Mecalux terms (Galileo/Fleet Manager/EasyS/tense flow/golden zone/etc.)
- Includes ERP Message Quick Reference table (all ~30 messages)
- Includes Transaction Code Quick Reference table (all prefixes)
- CREATED `concepts/account-owner.md` (sources: areas/inventory_management/masters/accounts.md + owners.md + mixing_owners.md)
- Lint fix: page was in schema.yaml but never compiled
- Sections: Owner vs Account distinction, owner attributes (code/mixing/user group), account attributes (strict FEFO/preferred carrier/client labels), owner mixing rules (manual vs automatic warehouse), ERP messages (OWN/ACC)
- CREATED `concepts/supplier.md` (sources: areas/inventory_management/masters/suppliers.md + supplier_types.md)
- Lint fix: page was in schema.yaml but never compiled
- Sections: Main attributes, use cases (inbound/receipt/returns), ERP message (SUP), interface paths
- CREATED `concepts/carrier.md` (sources: areas/multi_carrier_shipping/multicarrier_admin/views/view_extended_carriers.md + packing_printing.md)
- Lint fix: page was in schema.yaml but never compiled
- Sections: Base carrier attributes, extended carrier attributes (full field table from source), carrier selection (manual/auto/preferred), Delivery entity relationship, ERP messages (CAR/RUT)
- UPDATED `modules/directives.md` — added cross-reference to [[client-specific-rules]] to resolve orphan status
- UPDATED `wiki/_index.md` — total updated from 56 to 65 pages (added Batch 7: 8 pages + glossary)
### Batch 7 — LINT Report
**Broken [[bracket]] links:** None (all resolved).
**Broken markdown links (../path.md):** None.
**Orphan pages (no inbound links):**
- `modules/client-specific-rules` — intentional stub (404 source); now linked from `modules/directives.md`. Acceptable.
**Schema pages not compiled (fixed in this batch):**
- ~~concepts/account-owner.md~~ → CREATED
- ~~concepts/carrier.md~~ → CREATED
- ~~concepts/supplier.md~~ → CREATED
**Operations pages:** Fully compiled — troubleshooting.md + configuration-guide.md.
**Missing concept pages (mentioned in wiki but no dedicated page — lower priority):**
- `concepts/kits.md` — Kit assembly mentioned in task.md, erp-interface.md; schema has `areas/kits/` as source folder
- `concepts/erp-parameters.md` — ERP-specific parameters not fully covered in main parameters page
- `concepts/tense-flow.md` — Tense flow configuration use case (raw source exists: configurations/tense_flow_configuration01.md)
**_index.md completeness:** All 65 pages listed and described. ✓
## 2026-04-10 — Batch 6: Architecture & Integration (8 pages)
- CREATED `architecture/overview.md` (sources: architecture/saas/hardware/license all 404 — compiled from cross-source knowledge)
- Sections: On-premise stack (IIS/ASP.NET Core/Oracle/PostgreSQL), IIS application pools (Main/Background Jobs/Integration), SaaS vs on-premise differences (VPN requirements, Amazon SaaS certification), 3 API families (AD API/QueryExecute/CommandExecute), multi-site model, warehouse types (manual/automatic/mixed), background job table (TryToReplenish/Delete_StockStatusJob/AGV/PSService/SlottingJob/MetricGatherer/CycleCount/Defrag), hardware requirements (RF terminals/scales/label printers/automatic warehouse PLCs), license model (modular), common errors table
- CREATED `architecture/security.md` (sources: security/index.md 404 — compiled from cross-source knowledge)
- Sections: Role hierarchy (SuperAdmin/Administrator/Manager/Operator/RF Operator/Viewer/3PL Client/SCEM Admin), authentication mechanisms (SmartUI/RF/API/SSO), authorization model (menu access + command-level + data scope), station roles, container lock types table (Inbound/Outbound/Movement/Blocking), audit trail via transactions, quality locks (receiving status vs user status), network/infrastructure security (HTTPS/WIFI/VLAN/VPN), parameters affecting security, common errors
- CREATED `architecture/application-dictionary.md` (sources: cross-source AD knowledge + ERP.md + TransactionTypes.md)
- Sections: AD overview (~38,765 elements), 7 element types fully documented:
- Commands: executable operations → CommandExecute API, permission-controlled
- Queries: LINQ-based data retrieval → QueryExecute API
- Entities: core data objects with CRUD (25 key entities listed)
- Views: read-only projections (ViewContainers/ViewStocks/ViewTasksOpen/etc.)
- Dialogs: multi-step operator flows (ReceptionDialog/PickingDialog/CountDialog)
- Events: state transition triggers → ERP messages / SCEM / Workflows
- Workflows: orchestrated process sequences (Putaway/StockAssignment/Replenishment/Defrag/CountClose)
- Background Jobs table (8 jobs with triggers), Parameters, naming conventions (Command/Query/Entity/View/Dialog/Event/Parameter/Transaction/ERP naming patterns), extension points
- CREATED `architecture/entities-map.md` (sources: synthesized from all Batch 1-5 compiled pages)
- Sections: Core entity hierarchy tree (Org→Site→Zones→Aisles→Locations→Containers→Stock), primary relationship tables (Location→Container→Stock, Orders→Stock→Task, Container lifecycle), detailed attribute schemas for Container/Location/Stock/Task/ReceiptOrder/ShippingOrder/Count, master data entities (Item/Owner/Supplier/Account/Carrier), operational entities (Route/Load/PDL/ConsolidationProcess/DefragmentationPlanner), module entity extensions (AGV/Multi-Carrier/3PL Billing/DOM), referential constraints table, transaction-entity mapping table, ERP integration touch points per entity table
- CREATED `concepts/erp-interface.md` (sources: 35 ERP source files across masters/receipts/shipping/counts/replenishment/requests/notifications)
- Complete message catalog organized by category:
- Masters (8 messages): ITM/ITC/OWN/CAR/ACC/SUP/KIT/LCK
- Inbound (10 messages): ROR/ASN/SRN → ROC/ROF/REF/ASO/ASK/SRO/SRK
- Outbound (7 messages): SOR(SOR01/SOR02)/RUT/WOR → SOC/SOF/LOF/WOF
- Counts (2 messages): COR → COF
- Requests (3 messages): STR/SCR/CMC
- Notifications (7 messages): STV/STC/WSC/KST/UNK/COS/COC + ERR
- Per-message: key fields table, use cases, versions, triggering transactions
- Post-processing pipeline table (21 transaction → ERP message mappings)
- Module-specific messages table (Manufacturing/DOM/Yard/VAS)
- CREATED `concepts/transactions.md` (sources: areas/TransactionTypes.md + areas/notificationevents.md)
- Complete transaction catalog (~60+ codes) organized by entity prefix:
- CON.* (14 types): container movements, reception, shipping, VAS, L&F
- COU.* (4 types): count lifecycle
- STK.* (18 types): stock movements, adjustments, picking, replenishment, kit assembly, VAS
- CST.STK (1): quality status change
- INO.* (3): receipt order lifecycle
- REC.* (3): receipt document lifecycle
- OUT.* (5): shipping order lifecycle
- ROU.*/LOAD.* (6): route and load lifecycle
- TSK.* (7): task lifecycle + automatic warehouse errors
- WOR.*/KOU.* (4): work order lifecycle
- LCK.*/ULK.* (2): container locks
- DEL.*/DESK.*/SCR.*/SAC.* (6): misc (packaging, desk orders, stock contrast, ABC)
- Per transaction: post-processed flag, description, ERP message triggered, key data fields
- Notification Events catalog (25 core WMS events): code, severity, notification group, description
- Module notification events table (AGV/PS/SCEM/Slotting/Billing/DOM)
- Subscription scope table
- UPDATED `wiki/_index.md` — Added Architecture section (4 pages) + 2 concept pages; total updated from 48 to 56 pages
## 2026-04-10 — Batch 5: Modules (24 pages)
- CREATED `modules/agv.md` (sources: 24 pages from areas/agvs/)
- Sections: communication protocol phases (00/03/04/06/08/10/255), load types (0=Container, 1=Pallet Shuttle), error categories (configuration/execution/communication), RFT fallback mode, notification events table, AGV lock type
- CREATED `modules/pallet-shuttle.md` (sources: 25 pages from areas/pallet_shuttle/)
- Sections: PSService architecture (centralizes tablet-PS communication), simple vs multi-shuttle modes, LIFO/FIFO channel access, deposit/extraction/compaction operations, AGV-PS search algorithm, battery management parameters (PS_MAX_MINUTES_BATTERY_FULL_LOAD=300, PS_MIN_MINUTES_BATTERY_LOAD=90), background jobs table
- CREATED `modules/multi-carrier.md` (sources: 25 pages from areas/multi_carrier_shipping/)
- Sections: Delivery entity (carrier+consignee), extended carrier attributes, delivery status lifecycle, packaging station source/destination config, carrier dock confirmation modes (AUTO/MANUAL/UNLOAD), automatic carrier selection criteria, carrier label printing
- CREATED `modules/ecommerce.md` (sources: 2 pages from areas/ecommerce/)
- Sections: JIT reception flow (single-unit→packing, multi-unit→ungrouping, no-order→storage), 4 parameters (ECOMMERCE_RECEPTION_ALLOW_AUTOSELECTION, ALLOW_MULTIQUANTITY, RETURN_ALLOW_AUTOSELECTION, MAX_SECONDS_TO_CONFIRM)
- CREATED `modules/marketplaces.md` (sources: 3 pages from areas/marketplaces/)
- Sections: supported platforms (Prestashop/eBay/Amazon), Amazon SaaS + Android 10 requirement, OUT.CREATE transaction, marketplace configuration
- CREATED `modules/slotting.md` (sources: 11 pages from areas/slotting/)
- Sections: rotation analysis modes (historical/current/external file), golden zone concept, PDL-based vs all-picking-location recommendations, profit formula (daily_profit = (move_cost - stay_cost) × daily_rotation), 7+ parameters, continuous slotting background job
- CREATED `modules/labor-management.md` (sources: 11 pages from areas/labor_management/)
- Sections: Process→Activity→Work→Work Detail hierarchy, target time calculation (layout dimensions + equipment speed), 5 vertical behavior modes (no tolerance, allowed tolerance, fixed, flexible, ultra-flexible), 16 measured processes table, per-warehouse config requirement, RFT countdown display
- CREATED `modules/billing-3pl.md` (sources: 14 pages from areas/billing/)
- Sections: Contract→Rule→Planner lifecycle, standard vs custom rules, tiered pricing example, valuation fields, pre-validation workflow, compensation for credits, Owner Extensions prerequisite
- CREATED `modules/3pl-portal.md` (sources: 2 pages from areas/tpl_portal/)
- Sections: Owner-filtered access model, available WMS views per portal user, KPI types, notification setup, Owner Extensions prerequisite
- CREATED `modules/yard-management.md` (sources: 12 pages from areas/yard_management/)
- Sections: Appointment lifecycle (Pending→Waiting→Pending dock decision→In process→Pending check-out→Finished), 10-step initial configuration, dock compatibility rules, checkpoint attributes, weight control, parking lots, auxiliary appointments, ERP/TMS integration
- CREATED `modules/vas.md` (sources: 9 pages from areas/vas/)
- Sections: Template→Activity→Instructions hierarchy, VAS profiles (item/family/type), VAS at shipping station vs packing station, ERP SOR VASCode field, screen printing and container plastic use case examples
- CREATED `modules/manufacturing.md` (sources: 5 pages from areas/manufacturing/)
- Sections: RCP01 (manufacturing) vs RCP02 (quartering) recipe types, MOR01 production orders, MOF/FGP ERP messages, STK.MAN.PRODUCTION and MAN.FM.DAMAGE transactions, NegativeStock user status, component management
- CREATED `modules/store-fulfillment.md` (sources: 1 page from areas/store_fulfillment/)
- Sections: Star network topology constraint, POS integration (store sends orders), 3 replenishment modes (manual/automatic/min-max), no desk stations restriction, pending receipt visibility
- CREATED `modules/supply-chain-event.md` (sources: 3 pages from areas/supply_chain_event_management/)
- Sections: Event subscription model (single/delegated/3PL client), notification channels (web/email/SMS), Notification_GNAImportError code, alarm lifecycle (Active/Resolved/Expired), escalation chains, SCEM admin role
- CREATED `modules/movirack.md` (sources: 3 pages from areas/movirack/)
- Sections: Mobile racking system, 5 work modes (Manual/Auto/Timing/Autoparking/Autopicking), 4 aisle opening modes (with task/without task/manual/multi-aisle), reset/abort operations, tablet workstation interface
- CREATED `modules/cobot.md` (sources: 1 page from areas/cobot/)
- Sections: Robotic arm + suction cup tools + security elements, HPKS-R integration, item eligibility configuration, always paired with manual station for incidents, conveyor assignment rules
- CREATED `modules/aps3d.md` (sources: 1 page from areas/aps3d/)
- Sections: Fleet Manager controller architecture, APS vs APSFIFO locations, 5-stage order flow, 4 defragmentation modes (channel compaction/cross-channel/rotation/shipping), aisle balancing, depth confirmation, error management
- CREATED `modules/data-analytics.md` (sources: 1 page from areas/data_analytics/)
- Sections: Metric groups (consolidated hourly vs real-time minutes), metric gatherer background service, widget categories (50+ types), dashboard publishing model, standard dashboards table (WMS/LMS/APS3D), alarm configuration, multi-device support
- CREATED `modules/automation-dashboard.md` (sources: 6 pages from areas/faults_management/)
- Note: areas/automation_dashboard/ returns 404 — actual content in areas/faults_management/
- Sections: Fault recording (machine/start/end/description/causes/suggestions), manual action recording, fault reports table (8 types), action reports table (5 types), external WMS history, fault resolution workflow
- CREATED `modules/dom.md` (sources: 23 pages from areas/DOM/ — 138 total source files)
- Sections: Node types (POI/POF/Store), stock levels (org/node/line), ERP messaging table (POR/ROC/SOR/SOC/SOF/DOF/ACK/NCR), 5-stage orchestration engine (region→carrier→stock→capacity→strategies), order release prioritization, manual orchestration wizard, reorchestration criteria, order splitting, inbound purchase order flow, inter-node replenishment, configuration sequence
- CREATED `modules/faults-management.md` (sources: 6 pages from areas/faults_management/)
- Note: same source area as automation-dashboard; module is the backend implementation of the Automation Dashboard UI
- Sections: Cross-reference to automation-dashboard page; fault/action data model; report types table; resolution workflow
- CREATED `modules/directives.md` (sources: 10 pages from areas/directives/)
- Sections: Owner directives (document format/language, custom workflows), account directives (required/preferred container type, max weight/height/layers, min shelf life, max lot count, shipping logic), scope and precedence rules, configuration steps
- CREATED `modules/owner-extensions.md` (sources: 1 page from areas/ownerextensions/)
- Sections: Mandatory owner on receipt/shipping orders, 8 owner-isolated master entities (companies/account types/accounts/supplier types/suppliers/item types/item families), code concatenation with owner, exceptions (groups/fusions, inter-warehouse replenishments)
- CREATED `modules/client-specific-rules.md` (sources: 1 page — 404 error)
- Note: Source area returns 404; created stub explaining the concept maps to the Directives module
- UPDATED `wiki/_index.md` — Added Modules section (24 pages); total updated from 24 to 48 pages
## 2026-04-10 — Batch 4: Layout & Configuration
- CREATED `concepts/stations.md` (sources: 39 pages)
- Station index: index.md (route types, managers, incidences)
- Station types: alm.md, pie.md, pk.md, et.md, dock.md, stage.md, mu.md, me.md, ms.md, workzone.md, decision.md, ps.md, reac.md, rech.md, consolidation.md, etq.md, conveyor.md, vas.md, tenseFlow.md, lift.md, packaging_station.md, pscharge.md, kit.md, retention.md, desk.md, pcs.md, pb.md, ecb.md, cme.md, apl.md, lanz.md, mp.md, pke.md, traslo.md, fleet_manager.md, notask.md, disabledroute.md, stationloaded.md, stationfault.md
- Station management: inventory_management/stations/roles.md, views/view_dock_stage.md
- Sections: Full station type table (37+ types with type codes, descriptions, operative details), multi-role stations (PIE/PK+RECH/REAC), routes (simple vs composed), route managers (Galileo/RF/Voice/Virtual/PTL/External/Fleet Manager), route incidences (5 types), dock/stage configuration from SmartUI (actions, work mode, printer assignment)
- CREATED `concepts/warehouse-designer.md` (sources: 19 pages)
- Masters: container_type.md, rack_type.md, workstation.md
- Zones: storage_zones.md, working_zones.md, subwarehouses.md
- Equipment: equipment_type.md, equipment.md, equipment_restriction.md, equipment_restriction_by_quantity.md, equipment_restriction_by_incompatibility.md
- Layout: layout_shelves.md, layout_docks.md, layout_stages.md
- General: wd_delete_action.md
- Activity: change_log.md, transfer_list.md, transfer_comparison.md
- Warehouse map: inventory_management/warehouse_map/index.md
- Sections: Web Configurator overview, all master types (container/rack/workstation), zone types (storage/work/subwarehouse), equipment management (types/instances/restrictions by quantity and incompatibility), layout editing (shelves/docks/stages), deletion rules, change log + transfer history + comparison, Warehouse Map 3D view (station status, search, zone visualization), 2D view (location status, bulk operations, heat map)
- CREATED `concepts/parameters.md` (sources: 8 parameter files)
- Primary: areas/parameters.md (80+ core WMS parameters)
- Modules: inventory_management/parameters.md, slotting/parameters.md, ecommerce/parameters.md, pallet_shuttle/agv_ps/parameters.md, aps3d/parameters.md, multi_carrier_shipping/parameters.md
- Note: areas/areasparameters.md and areas/shipping/parameters.md were 404 — not included
- Sections: Parameter system architecture (system vs custom, organization vs warehouse scope), all core parameters organized by process (reception/labels/container/picking/shipping/stock/replenishment/defragmentation/voice), all module parameters (Slotting/eCommerce/AGV-PS/APS3D/Multi-Carrier), cross-reference table linking parameters to other wiki pages
- CREATED `concepts/cutting-stock.md` (sources: 12 pages)
- Item config: cutting_item.md, cutting_profile.md, cutting_stock_assignation.md, cutting_stock_label.md
- Picking: cutting_station.md, cutting_stock_integrated.md, cutting_stock_delegate.md, cutting_excess.md
- Reception: blind_cutting_stock.md, supplier_cutting_stock.md
- Count: count_cutting_stock.md
- Sections: Non-consolidation rule and base UoM rule, cutting profile (6 attributes), first-time setup (6 steps), assignment strategies (continuous/segmented/minimum with examples), cutting station configuration (type 61, EasyS routes, stage options), reception processes (blind/supplier/receipt-and-putaway), integrated vs delegated cutting picking (3-phase process, differences), cutting excess + shipping profile config, counting stretches (3 modes + informed count), quality lock behavior, parameters (CUTTING_PRINTER)
- CREATED `concepts/labels.md` (sources: 6 pages)
- Primary: labels_containers.md, labels_items.md, cutting_stock_label.md, print_stock_label.md, multilabel_recep.md
- Note: labels_LPN.md was 404 — content obtained from labels_containers.md
- Sections: Container label types (SSCC, GS1-128 mono/multi-reference) with format table and Application Identifiers, item labels (Code128 and GS1-128) with AI table, cutting stock labels (A6 only, printer priority, profile flags), client container auto-labels, multi-reading process (4 modes), RF label printing (8 printable objects), automatic print triggers, all parameters consolidated
- UPDATED `concepts/picking.md` — added backlinks to cutting-stock.md and stations.md
- UPDATED `concepts/shipping.md` — added backlinks to cutting-stock.md and stations.md
- UPDATED `concepts/stock-adjustment.md` — added backlinks to cutting-stock.md and labels.md
- UPDATED `concepts/quality-control.md` — added backlink to cutting-stock.md
- UPDATED `wiki/_index.md` — total now 24 pages (added Batch 4: 5 pages)
## 2026-04-10 — Batch 3: Inventory Operations
- CREATED `concepts/count.md` (sources: 26 pages)
- Primary: counts_admin/count.md, count_type.md, count_create.md, count_release.md, count_close.md, count_cancel.md
- Physical: count_physical.md, count_location.md, count_lpn.md, count_item.md, Partitions_Count.md
- Workstation: counts_workstation/index.md, count_pk_location.md, count_pk_lpn.md, count_pk_item.md
- Cycle count: cycle_count/index.md, cycle_count_schedule.md, cycle_count_generation.md
- ERP: counts_erp/index.md (SCR/WSC stock contrast)
- Sections: 3 count types (item/container/location), 4 creation methods (WMS/ERP/physical/cycle), full lifecycle (Disabled→Releasing→In Process→Closed/Canceled), task generation rules per warehouse type, blind vs informed mode, partition counts, automatic warehouse workstation, cycle count schedule/iteration/generation logic, ERP messages (COR/COF/SCR/WSC), double validation interaction, transactions (COU.CST/TSK.COU/STK.ADJ/COU.END/COU.CLS/COU.CNL), all parameters
- CREATED `concepts/stock-adjustment.md` (sources: 16 pages)
- Primary: stock_adjustment.md, quantity_adjust.md, udm_adjust.md, al_adjust.md, reasons.md
- Interfaces: stock_adjustment_RF.md, stock_adjustment_SmartUI.md, stock_adjustment_Workstation.md
- Double validation: double_validation/activate.md, adjust_register.md, pending_adjust_actions.md
- Sections: 5 adjustment types (qty+/qty−/full location/UoM/logistic attributes), side effects on tasks and assignments per type, adjustment reasons (5 capture processes), double validation (Pending→Confirmed/Canceled with reversal wizard), RF/SmartUI/Workstation interface details, ASN/client stock restrictions, cutting stock specifics, transactions (STK.ADJ/STK.MOVE), ERP STV messaging rules
- CREATED `concepts/consolidation.md` (sources: 6 pages)
- Primary: consolidation/index.md, consolidation_admin/consolidation_process_creation.md, consolidation_automatic/index.md
- Detail: 2loc_PK_consolidation.md, ManualMP_PK_consolidation.md, Buffer_consolidation.md
- Sections: Process→Orders→Lines→Tasks architecture, 3 supported use cases (manual/auto single-ref/auto multi-ref), process configuration (definition + filtering criteria + allow mixing + destination station), process lifecycle (Standby→Released→Paused/Canceled), 3 automatic warehouse modes (PK 2-loc, manual MP, buffer), operator incident handling, configuration requirements (full quantity, station modes), transactions (CON.MOVE/STK.MOVE/CON.SEND.L&F)
- CREATED `concepts/defragmentation.md` (sources: 4 pages)
- Primary: defragmentation/index.md, defrag_admin/index.md, defrag_rotation.md, defrag_shipping.md
- Sections: 2 strategy types (rotation by ABC class / shipping by order assignment), rotation strategy criteria (8 criteria) + destination rules, shipping strategy criteria (8 criteria) + destination rules, APS optimal channel selection, defragmentation planners (type/schedule/duration/frequency), manual vs automatic execution, parameters (MAX_DEFRAG_TASKS/MAX_OPTIMIZATION_DEFRAG_CHANNEL/MAX_DEFRAG_ATTEMPT), automatic warehouse only
- CREATED `concepts/quality-control.md` (sources: 7 pages)
- Primary: quality_control/index.md, quality_lock_web.md, quality_lock_trf.md, quality_lock_erp.md, quality_unlock.md, quality_automatic_unlock.md, cut_stock_lock.md
- Sections: Stock status concept (2 status types: receiving vs user), 6 lockable operations, 3 reception lock mechanisms, lock from web/RF/ERP (3 scope levels: location/container/item), task/assignment side effects on lock, unlock from web/RF/ERP, automatic time-based unlock (job Delete_StockStatusJob_PR every 15 min), required/preferred status at shipping, cutting stock partial/total lock (split behavior), ERP messages (STR/STC), transaction (CST.STK)
- CREATED `concepts/manual-movements.md` (sources: 1 page)
- Primary: inventory_management/manual_movements/manual_movements.md
- Sections: 8 move types (location→location, location→container, container→container, container→container with divisions, division→division, move container, cutting stock, partitions), restrictions per type (ASN, cross-warehouse, client stock, lock confirmation), replenishment assignment cancellation on container move, cutting stock indivisibility rules (exact stretch length required, one stretch at a time), partition-specific restrictions, transactions (STK.MOVE/CON.MOVE), interface paths (RFT/Workstation)
- UPDATED `concepts/container.md` — added backlinks to consolidation.md and quality-control.md
- UPDATED `concepts/putaway.md` — added backlink to defragmentation.md
- UPDATED `wiki/_index.md` — total now 19 pages (added Batch 3: 6 pages)
## 2026-04-10 — Batch 1: Core Entities (completion)
- CREATED `concepts/location.md` (sources: 8 pages)
- Primary: layout/location_types/location_types.md, inventory_management/locations/locations.md, location_lock_types.md, locations_features.md
- Sections: Virtual locations (ASN/Lost_Found/Mov), 13 physical types (conventional/compact/APS/APSFIFO/dynamic/pushback/cantilever/buffer/dock/equipment/conveyor), storage modes, storage logics (12 flags), lock types (8 operations), location coding (ASXY), label formats, all operations from Locations view, common errors
- CREATED `concepts/product-item.md` (sources: 20 pages)
- Primary: items/index.md, items/logistic_attributes.md, items/profiles.md, items/types.md, items/uom.md, items/uom_base.md
- Also: alias.md, families.md, substitutes.md, weight.md, mix_items.md, min_and_max.md, abc_classification.md, subwarehouse_classification.md
- Sections: Item vs stock distinction, types, families, ABC classification, UoM and conversions, all logistic attributes (lot/expiry/best-before/production/days of life/serial/quality/size/color/version/etc.), 7 profiles, all 30+ item attributes, labeling, ITM ERP message
- CREATED `concepts/stock.md` (sources: 16 pages)
- Primary: view_stocks.md, stock_adjustment.md, grouped_stock.md
- Also: stock_adjustment_RF.md, stock_adjustment_Workstation.md, quantity_adjust.md, udm_adjust.md, al_adjust.md, reasons.md
- Sections: Stock record structure (all fields), 4 storage contexts, 3 status dimensions, lifecycle, 5 adjustment types (quantity+/-/location/PDL partition/PK conveyor), adjustment rules and task interactions, grouped reports (5 views), STV communications, STK.ADJ transactions
- CREATED `concepts/task.md` (sources: 7 pages)
- Primary: tasks/index.md, tasks/tasks.md, tasks/automatic_tasks.md, tasks/movements.md, tasks/semiautomatic_tasks.md
- Sections: Full task/process type table (28 combinations), lifecycle (Pending/Generated/In Process/Finished/Canceled), task→movement decomposition with compound routes, execution order criteria (RF priority, empty channel, stackability, route, date), semi-automatic mode, all PC operations, common errors
- CREATED `concepts/order-inbound.md` (sources: 16 pages)
- Primary: receipt_orders.md, receipt_order_type.md, ERP/receipts/ror.md, roc.md, rof.md, asn.md, aso.md, str.md
- Sections: 3 order types (supplier/return/transfer), header + line structure, 7 lifecycle statuses, all ERP messages (ROR with all variants, ASN with 8 variants, ROC status notifications, ROF01/ROF02, ASO with variants, STR lock/unlock), parameters, operations, common errors
- CREATED `concepts/order-outbound.md` (sources: 18 pages)
- Primary: shipping_order.md, shipping_order_type.md, shipping_admin/index.md, shipping_orders_monitorize.md, ERP/shipping/sor.md, soc.md, sof.md
- Sections: 8 order types, header + line structure (all fields including critical/required lines, logistic attribute filters, max lots), full lifecycle with status/actions table, all business rules (critical/required lines, excess, substitutes, expired stock, reserve), SOR01/SOR02, SOC all statuses, SOF01/SOF02 with partial close logic, LOF, all PC operations, common errors
- UPDATED `concepts/putaway.md` — added cross-refs to task.md and product-item.md
- UPDATED `concepts/picking.md` — added cross-refs to task.md, order-outbound.md, location.md
- UPDATED `concepts/shipping.md` — added cross-refs to order-outbound.md, task.md
- UPDATED `concepts/replenishment.md` — added cross-refs to task.md, location.md
- UPDATED `concepts/crossdocking.md` — added cross-refs to order-inbound.md, order-outbound.md
- UPDATED `wiki/_index.md` — total now 13 pages (Batch 1: 7 pages + Batch 2: 6 pages)
## 2026-04-10 — Batch 2: Core Flows
- CREATED `concepts/reception.md` (sources: 10 pages)
- Primary: reception_dock.md, receipt_order.md, receipt.md, asncontainers.md, blind_container.md, supplier_container.md, returns.md
- Automatic: pie_auto.md, pie_semi_auto.md, pk/index.md
- Sections: Receipt document structure, 5 reception modes (dock/supplier, blind, returns, ASN, PIE, PK), closing, 16 parameters, 7 ERP messages, labels, errors, UI paths
- CREATED `concepts/putaway.md` (sources: 5 pages)
- Primary: putaway_process.md, putaway_apply_strategies.md, putaway_admin/index.md, putaway_configuration01.md
- Sections: Strategy architecture (channel filling vs location), 8-stage pipeline (criteria→aisles→balancing→restrictions→validity→rule filters→sort→select), automatic station triggers (PIE/MU/TRL/ALM), PDL integration, parameters, errors, UI paths
- CREATED `concepts/picking.md` (sources: 8 pages)
- Primary: shipping_manual/index.md, shipping_auto/index.md, shipping_auto/direct_picking.md, shipping_auto/grouped_picking.md, pick_and_pass/index.md, shipping_admin/stock_assign.md
- Sections: Stock assignment (strategies, priorities, excess), manual warehouse modes (10 modes), automatic warehouse picking (direct 7-phase, grouped, negative), Pick and Pack, cutting stock, path design, transactions, errors, UI paths
- CREATED `concepts/shipping.md` (sources: 10 pages)
- Primary: shipping_admin/index.md, order_release.md, shipping_admin/stock_assign.md, shipping_truck_load/index.md, shipping_consolidation/shipping_consolidation_onstation.md
- Sections: Shipping order lifecycle (7 statuses), management operations, release process, grouping (waves/groups/fusions/templates), prepackaging, consolidation, routes, loads, truck loading (containers/stock/packages), PS groups, ERP messages, transactions, errors, UI paths
- CREATED `concepts/replenishment.md` (sources: 6 pages)
- Primary: replenishment_strategies.md, picking_locations.md, efficiency_mode.md, dynamic.md, automatic_replenish.md
- Sections: PDL concept and attributes, PDL partitions, PDL release on empty, 4 strategy types (top-off, shipping demand, stockout, sub-warehouse), 3 efficiency modes, stock eligibility, dynamic replenishment process, automatic job (TryToReplenishProductLocations), cutting stock, errors, UI paths
- CREATED `concepts/crossdocking.md` (sources: 3 pages)
- Primary: crossdocking_manual/index.md, crossdocking_manual/crossdocking_warehouse.md
- Note: crossdocking_opportunity.md was 404; content sourced from index.md description
- Sections: Opportunity XD (direct to dock, eligibility, process), XD to warehouse (conditions, XD locations, XD strategies, coverage check), decision tree, comparison table, configuration requirements, errors, UI paths
- UPDATED `wiki/_index.md` — total now 7 pages (Batch 1: 1 page + Batch 2: 6 pages)
## 2026-04-10 — Batch 1: Core Entities — Container (LPN)
- CREATED `concepts/container.md` (sources: 13 pages)
- Primary: containers.md, container_types.md, container_lock_types.md, division_types.md
- Stacking/matching: stacked_containers.md, stack_match_containers.md, unstack_unmatch_containers.md
- Reception: supplier_container.md, blind_container.md, asncontainers.md
- Report: Putaway_search_location_trace.md
- Transactions: TransactionTypes.md (CON.* section)
- view_containers.md: 404 (scrape error — skipped)
- Sections: Overview, Attributes, Weight, Types, Lifecycle, Stacking/Matching, Locks, Reception, Operations, Labeling, Parameters, Transactions, ERP Integration, UI paths, Common errors, Related
wiki_old_13-05-2026/architecture/application-dictionary.md
+249
View File
@@ -0,0 +1,249 @@
---
title: "Application Dictionary (AD)"
type: architecture
sources:
- CLAUDE.md context (AD API knowledge)
- areas/ERP.md
- areas/TransactionTypes.md
- Cross-source knowledge from all batches
related:
- architecture/overview.md
- architecture/entities-map.md
- concepts/erp-interface.md
- concepts/transactions.md
last_compiled: "2026-04-10"
---
# Application Dictionary (AD)
## Overview
The **Application Dictionary (AD)** is the core metadata framework of Easy WMS. Rather than hardcoding business logic, the system defines all operations, data structures, and UI elements as configurable AD elements stored in the database. This makes Easy WMS highly customizable: partners and customers can extend or modify behavior without touching application code.
The AD contains approximately **38,765 elements** spanning Commands, Queries, Dialogs, Views, Entities, Events, Workflows, and more. Every UI action, every RF terminal screen, and every API call is backed by one or more AD elements.
## AD Element Types
### Commands
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
- `ReleaseShippingOrder` — release a shipping order for picking
- `AdjustStock` — perform a quantity adjustment
- `CreateCount` — create a physical count order
- `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.
### Queries
Queries represent **data retrieval operations** using a LINQ-style expression engine.
- Mapped to `GET /api/queries/{queryName}` or `POST /api/queries/execute` (dynamic)
- Support filtering, sorting, pagination
- Can reference any View or Entity
- Examples:
- `GetStockByLocation` — fetch stock for a location
- `GetOpenShippingOrders` — fetch all non-closed shipping orders
- `GetContainerContents` — fetch stock lines in a container
- `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.
Each Entity has:
- A schema (fields, types, constraints)
- CRUD operations accessible via `GET/POST/PUT/DELETE /api/entities/{entityName}`
- Relations to other Entities
- Business rules enforced on create/update/delete
Key Entities (from all compiled batches):
| Entity | Description |
|--------|-------------|
| `Container` | LPN with type, weight, status, lock, location |
| `Location` | Physical or virtual storage position |
| `Stock` | Stock line: item + qty + UoM + logistic attributes + container + location |
| `Item` (Product) | SKU master with types, families, UoM, profiles |
| `ReceiptOrder` | Inbound order (supplier/return/transfer) |
| `Receipt` | Physical receiving event linked to receipt orders |
| `ShippingOrder` | Outbound order (customer/transfer/return) |
| `Task` | Movement task with type, origin, destination, status |
| `Count` | Inventory count order with lines and status |
| `Route` | Carrier route with loads and departure schedule |
| `Load` | Truck load linked to a route |
| `Station` | Warehouse station configuration |
| `Owner` | Stock owner (for 3PL multi-tenancy) |
| `Account` | Customer/delivery account |
| `Supplier` | Vendor master |
| `Carrier` | Shipping carrier master |
| `Delivery` | Multi-Carrier delivery (carrier + consignee) |
| `ContainerType` | LPN type definition |
| `ItemType` / `ItemFamily` | Item classification hierarchy |
| `UoM` | Unit of Measure with conversions |
| `Zone` | Storage or working zone |
| `SubWarehouse` | Logical sub-division of warehouse |
| `Equipment` | Warehouse equipment (forklift, RFT, conveyor) |
| `UserStatus` | Stock quality status definition |
| `VASTemplate` | Value Added Services template |
| `Kit` | Kit definition with components |
| `Appointment` | Yard Management appointment |
| `Slot` | Slotting recommendation |
| `LaborActivity` | LMS activity record |
| `BillingContract` | 3PL billing contract |
| `DOMNode` | Distributed Order Management node |
### Views
Views are **read-only projections** of one or more Entities, optimized for display and reporting.
- Accessible via `GET /api/views/{viewName}` or QueryExecute
- Often join multiple entities (e.g., stock + container + location + item)
- May include computed columns and aggregations
- Back all SmartUI list screens and RF terminal display screens
- Examples:
- `ViewContainers` — containers with location and status
- `ViewStocks` — stock lines with full context
- `ViewTasksOpen` — open tasks with assignment info
- `ViewShippingOrdersMonitor` — order monitoring dashboard
- `ViewGroupedStock` — aggregated stock by item/owner
### Dialogs
Dialogs are **multi-step interactive flows** that guide an operator through a complex operation.
- Used primarily in RF terminals and workstation screens
- Each Dialog has **steps** (screens), each advancing the flow
- 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)
- `PickingDialog` — guided picking (scan location → confirm quantity → scan destination)
- `CountDialog` — count guided flow (scan location → count items → confirm)
- `ShippingConsolidationDialog` — consolidation at shipping station
Dialogs encapsulate the complete operator interaction sequence for a process, invoking Commands internally at each confirmation step.
### Events
Events are **system notifications** that fire when certain state transitions occur.
- Triggered automatically by Commands (not by users directly)
- Can invoke Workflows, send notifications (SCEM), or trigger ERP messages
- Examples:
- `OnShippingOrderClosed` → triggers SOF ERP message + SOC status change notification
- `OnReceiptOrderStatusChange` → triggers ROC ERP message
- `OnStockExpired` → fires `EasyWMS_StockExpired` notification event
- `OnContainerReceived` → triggers ASO ERP message (if ASN container)
- `OnTaskGenerated` → notifies AGV controller (automatic warehouse)
Events decouple the triggering action from downstream reactions, enabling clean extension without modifying core logic.
### Workflows
Workflows are **orchestrated sequences** of Commands, conditional logic, and state transitions.
- 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)
- `StockAssignmentWorkflow` — evaluate assignment strategies → assign to shipping order lines
- `ReplenishmentWorkflow` — check PDL levels → select strategy → generate tasks
- `DefragmentationWorkflow` — evaluate rotation/shipping criteria → generate movement tasks
- `CountCloseWorkflow` — close count → compute differences → generate STK.ADJ transactions → send COF to ERP
### Background Jobs
Background Jobs are **scheduled or continuous Workflows** that run autonomously:
| Job | Trigger | Workflow Invoked |
|-----|---------|-----------------|
| `TryToReplenishProductLocations` | Continuous | ReplenishmentWorkflow |
| `Delete_StockStatusJob_PR` | Every 15 min | QualityUnlockWorkflow |
| `CycleCountGenerationJob` | Per schedule | CountGenerationWorkflow |
| `DefragmentationPlannerJob` | Per schedule | DefragmentationWorkflow |
| `SlottingAnalysisJob` | Configurable | SlottingWorkflow |
| `MetricGathererJob` | Configurable | DataAnalyticsWorkflow |
| `AGVCommunicationJob` | Continuous | AGVProtocolWorkflow |
| `PSServiceJob` | Continuous | PalletShuttleWorkflow |
### Parameters
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)
- Read by Commands, Workflows, and Background Jobs at runtime
- See [Parameters](../concepts/parameters.md) for the full compiled catalog
## AD API Access Patterns
### Reading data (QueryExecute)
```http
POST /api/queryexecute
{
"query": "Stock.Where(s => s.LocationCode == 'A0101' && s.ItemCode == 'SKU001')",
"site": "WH01"
}
```
### Executing a command
```http
POST /api/commandexecute
{
"command": "ReleaseShippingOrder",
"parameters": {
"ShippingOrderCode": "SO-20260410-001",
"Site": "WH01"
}
}
```
### Reading an entity
```http
GET /api/entities/ShippingOrder/SO-20260410-001?site=WH01
```
## AD Element Naming Conventions
Based on patterns observed across documentation:
- **Commands**: PascalCase verb-noun (`ReceiveContainer`, `ReleaseOrder`, `AdjustStock`)
- **Queries**: `Get` + PascalCase noun (`GetStockByLocation`, `GetOpenTasks`)
- **Entities**: PascalCase noun (`Container`, `Stock`, `ShippingOrder`)
- **Views**: `View` + PascalCase noun (`ViewContainers`, `ViewStocks`)
- **Dialogs**: Context + `Dialog` suffix (`ReceptionDialog`, `PickingDialog`)
- **Events**: `On` + PascalCase noun+verb (`OnShippingOrderClosed`)
- **Parameters**: `SCREAMING_SNAKE_CASE` (`MAX_DEFRAG_TASKS`, `ECOMMERCE_RECEPTION_ALLOW_AUTOSELECTION`)
- **Transactions**: `ENTITY.VERB` dot notation (`CON.MOVE`, `STK.ADJ`, `OUT.CLS`)
- **ERP Messages**: 3-letter uppercase code (`SOR`, `ROC`, `STR`)
## Extension Points
The AD can be extended by Mecalux partners:
1. **Custom Commands**: Add new business operations
2. **Custom Views**: Expose new data projections
3. **Custom Workflows**: Override or extend default process logic
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.
## Related
- [Overview](overview.md) — System architecture and deployment
- [Entities Map](entities-map.md) — Visual map of entity relationships
- [Transactions](../concepts/transactions.md) — Transaction audit trail (generated by Commands)
- [ERP Interface](../concepts/erp-interface.md) — ERP messages (triggered by Events)
- [Parameters](../concepts/parameters.md) — System parameter catalog
wiki_old_13-05-2026/architecture/entities-map.md
+466
View File
@@ -0,0 +1,466 @@
---
title: "Entities Relationship Map"
type: architecture
sources:
- Synthesized from all Batch 1-5 compiled wiki pages
- areas/TransactionTypes.md
- areas/ERP.md
- All ERP message files
- All concept and module pages
related:
- architecture/application-dictionary.md
- architecture/overview.md
- concepts/container.md
- concepts/location.md
- concepts/stock.md
- concepts/product-item.md
- concepts/task.md
- concepts/order-inbound.md
- concepts/order-outbound.md
- concepts/erp-interface.md
last_compiled: "2026-04-10"
---
# Entities Relationship Map
## 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.
## Core Entity Hierarchy
```
Organization
└── Site (Warehouse)
├── Zones (Storage / Working)
│ └── Aisles
│ └── Racks / Shelves
│ └── Locations ──────────────── contains ──→ Containers
│ └── Stock lines
├── SubWarehouses
│ └── Locations (scoped)
├── Stations (Dock / PIE / PK / PS / MU / ME / etc.)
│ └── Routes (Simple / Composed)
│ └── Route Managers (Galileo / RF / Voice / PTL / External)
├── Equipment (Forklifts / AGVs / Conveyors)
└── Users
└── Roles → Station Roles
```
## Primary Entity Relationships
### Location → Container → Stock
The fundamental storage chain:
```
Location (1) ←── stored_at ──── (N) Container
Container (1) ←── held_in ──── (N) Stock
Stock (N) ──── is_of_type ────→ (1) Item
Stock (N) ──── owned_by ───────→ (1) Owner
```
| Relationship | Cardinality | Notes |
|-------------|-------------|-------|
| Location → Container | 1:N | One location can hold multiple containers (stacking) |
| Container → Stock | 1:N | One container can hold multiple stock lines |
| Container → Container | 1:N | Stacked containers; outer container holds inner |
| Stock → Item | N:1 | Multiple stock lines for same item (different lot/location) |
| Stock → UoM | N:1 | Each stock line has one UoM |
| Stock → Owner | N:1 | Stock belongs to one owner |
### Orders → Stock → Task
The fulfillment chain:
```
ReceiptOrder (1) ←── fulfilled_via ──── (N) Receipt
Receipt (1) ─────── creates ──────────→ (N) Container (received containers)
Receipt (1) ─────── creates ──────────→ (N) Stock (loose stock)
ReceiptOrder (1) ←── associated ──── (N) Container (ASN pre-notified)
ShippingOrder (1) ←── assigned_from ── (N) Stock (reservations)
ShippingOrder (1) ─── generates ──────→ (N) Task (picking tasks)
Task (1) ────────────── moves ─────────→ (N) Container
Task (1) ────────────── moves ─────────→ (N) Stock
Task (N) ─────────────── assigned_to ──→ (1) User / Equipment
```
### Container Lifecycle Relationships
```
Container ──── received_at ─────→ Location (Dock/PIE/PK/ASN)
Container ──── moved_to ─────────→ Location (via putaway Task)
Container ──── picked_from ──────→ Location (via picking Task)
Container ──── shipped_to ───────→ Location (Dock/Stage)
Container ──── loaded_on ────────→ Load (truck loading)
Container ──── consolidated_into → Container (client container)
Container ──── stacked_on ───────→ Container (stacking)
Container ──── locked_by ────────→ ContainerLock (N lock types)
```
## Detailed Entity Attribute Map
### Container
```
Container {
Code* → unique LPN identifier
TypeCode → ContainerType (dimension, weight capacity)
Weight → actual weight
Status → Received / In Transit / Located / Shipped / Deleted
LocationCode → current Location (nullable if in transit)
OwnerCode → Owner (nullable)
ReceiptCode → source Receipt (if received via reception)
ASNCode → advance shipping notice code (if pre-notified)
Locks[] → active ContainerLock list
StackedOn → parent Container (if stacked)
Divisions[] → cutting stock divisions (if applicable)
}
```
### Location
```
Location {
Code* → ASXY format (Aisle+Section+X+Y) or virtual code
Type → Conventional/Compact/APS/APSFIFO/Dynamic/Pushback/
Cantilever/Buffer/Dock/Equipment/Conveyor/Virtual
ZoneCode → storage Zone
SubWarehouseCode→ SubWarehouse (optional scoping)
StorageMode → Single container / Multi-container / Loose stock
StorageLogic → 12 flags (fifo/lifo/fefo/stack/mix items/mix lots/etc.)
Locks[] → active LocationLock list (8 operation types)
Capacity → weight/height/container count limits
Features[] → compatibility flags for putaway restrictions
IsPickingDedicated → boolean (PDL flag)
VirtualType → ASN / LostFound / Mov (if virtual)
}
```
### Stock
```
Stock {
ItemCode* → Item
UoMCode* → Unit of Measure
Quantity* → current quantity
ContainerCode → Container (nullable for loose stock)
LocationCode → Location
OwnerCode → Owner
ReceivingStatus → quality status set at reception (clear/locked)
UserStatus → quality status set by user/ERP (0..N statuses)
LogisticAttributes {
Lot, SerialNumber, ExpiryDate, BestBefore, ProductionDate,
DaysOfLife, Color, Size, Version, Weight, ... (item-specific)
}
ReservedQty → quantity reserved for ShippingOrder lines
AssignedQty → quantity assigned to Tasks
}
```
### Task
```
Task {
Number* → unique task ID
ProcessType → Putaway/Picking/Shipping/Replenishment/Count/
Movement/Consolidation/etc.
Status → Pending/Generated/InProcess/Finished/Canceled
ContainerCode → Container being moved (nullable)
LocationFrom → source Location
LocationTo → destination Location
ShippingOrderCode → linked ShippingOrder (if picking/shipping task)
CountCode → linked Count (if count task)
AssignedUser → User assigned to execute
AssignedEquipment → Equipment (AGV, forklift)
Priority → Urgent/High/Normal/Low/VeryLow
Route → Route/Station path for automatic warehouse
Movements[] → decomposed Movement steps (compound routes)
}
```
### Receipt Order (Inbound Order)
```
ReceiptOrder {
Code* → unique order code
Type → Supplier/Return/Transfer
Status → Created/Waiting/Pending/Receiving/PartiallyReceived/
Received/Closed/Canceled
SupplierCode → Supplier (if type=Supplier)
Lines[] {
Number, ItemCode, ExpectedQty, ReceivedQty, FreeQty, UoMCode
}
Receipts[] → linked Receipts (physical receiving events)
Containers[] → ASN pre-notified Containers
ERP_Source → ROR message code (if from ERP)
}
```
### Shipping Order (Outbound Order)
```
ShippingOrder {
Code* → unique order code
Type → Customer/Return/Transfer/DirectTransfer/
Replenishment/Kit/Desk/Work
Status → Created/Released/InPreparation/StockFailure/
Paused/Prepared/Closed/Canceled
Priority → Urgent/High/Normal/Low/VeryLow
AccountCode → Account (delivery destination)
DockCode → assigned dock (optional)
RouteCode → Route assignment (optional)
GroupCode → wave/group (optional)
Lines[] {
Number, ItemCode, ContainerCode, OrderedQty, PreparedQty,
ShippedQty, UoMCode, LogisticAttributes, MaxLots,
Flags: Critical/Required/Excess/Substitutes
}
Prepackaging → prepackaging config (SOR02 only)
VASCode → VAS template reference (optional)
ERP_Source → SOR message code
}
```
### Count
```
Count {
Code* → unique count code
Type → Location/Item/Container
Status → Disabled/Releasing/InProcess/Closed/Canceled
Priority → count priority
Lines[] {
Number, Scope: {ItemCode/ContainerCode/LocationFrom-To/Aisle},
IsInformed, IsBlind
}
Tasks[] → count Tasks generated
ERP_Source → COR message code (if ERP-initiated)
}
```
## Master Data Entities
```
Item {
Code*, OwnerCode, Description, ShortDescription
TypeCode → ItemType
FamilyCode → ItemFamily
ABCClass → A/B/C classification
Profiles: LogisticProfile, ReceptionProfile, PutawayProfile,
ShippingProfile, CuttingProfile
UoMBase, Conversions[], Aliases[]
LogisticAttributes: {lot, serial, expiry, bestBefore, days_of_life,
production, color, size, version, quality, weight}
MinQty, MaxQty (per SubWarehouse via ItemClassification)
IsKit, IsSubstitute, IsCuttingStock
}
Owner {
Code*, Description
(with Owner Extensions: isolated master data scope)
}
Supplier {
Code*, Description, OwnerCode
}
Account {
Code*, Description, OwnerCode, AccountType
MixingRules → item/lot mixing restrictions
}
Carrier {
Code*, Description
Services[] → carrier service levels
(with Multi-Carrier: extended delivery configuration)
}
```
## Operational Entities
### Routes and Loads
```
Route {
Code*, Description, CarrierCode
DockCode → departure dock
DepartureTime
Status → Open/Closed/Canceled
Loads[] → truck Loads
ShippingOrders[] → assigned orders
}
Load {
Code*, RouteCode
Status → Open/InLoading/Closed
Seal → seal number
Containers[] → loaded containers
Stocks[] → loaded loose stock
}
```
### Putaway and Replenishment
```
PutawayStrategy {
Criteria[] → filter rules (item type, family, ABC, weight, etc.)
LocationRules[] → destination preference rules
AisleBalancing → boolean
ChannelFilling → boolean (prefer filling partial channels)
}
PDL (PickingDedicatedLocation) {
LocationCode, ItemCode, UoMCode
MinQty, MaxQty, ReplenishQty
PartitionType → fixed/flexible
EfficiencyMode → efficient/complete/none
}
```
### Consolidation and Defragmentation
```
ConsolidationProcess {
Code*, Definition, Criteria
AllowMixing → boolean
DestinationStation
Status → Standby/Released/Paused/Canceled
Orders[] → consolidation orders
}
DefragmentationPlanner {
Type → Rotation/Shipping
Schedule, Duration, Frequency
Status → Active/Inactive
}
```
## Module-Specific Entity Extensions
### AGV
```
AGVOrder {
ContainerCode, LoadType (0=Container/1=PalletShuttle)
PhaseCode → communication phase (00/03/04/06/08/10/255)
OriginLocation, DestinationLocation
ErrorCode, ErrorDescription
}
```
### Multi-Carrier
```
Delivery {
CarrierCode, ConsigneeCode
Status → Pending/Confirmed/Shipped/Delivered
TrackingNumber
Packages[]
ShippingOrderCode
}
```
### 3PL Billing
```
BillingContract {
OwnerCode, Description
Rules[] → BillingRule
Planners[] → BillingPlanner
}
BillingRule {
Type → Standard/Custom
ValuationFields[], TieredPricing[]
}
```
### DOM
```
DOMNode {
Code*, Type → POI/POF/Store
RegionCode
StockLevels → Organization/Node/Line
}
DOMOrder {
Code*, Type → Purchase/Sales/Replenishment
SourceNode, DestinationNode
OrchestrationStage → Region/Carrier/Stock/Capacity/Strategy
}
```
## Key Referential Constraints
| Constraint | Description |
|-----------|-------------|
| Item cannot be deleted with active stock | Item delete requires zero stock across all locations |
| Location cannot be deleted if occupied | Must empty location first |
| ReceiptOrder cannot be deleted if has receipts | Must cancel or close first |
| ShippingOrder cannot be modified if closed/canceled | Immutable after close |
| Task cannot be canceled if InProcess | Must be released by operator first |
| Container lock blocks most operations | Check active locks before operations |
| Stock with active UserStatus blocks shipping | Unless order specifically requests that status |
## Transaction-Entity Mapping
Every entity state change generates a Transaction. Key mappings:
| Transaction | Entity Changed |
|------------|---------------|
| `CON.LOCATE` | Container → Location (putaway) |
| `CON.MOVE` | Container → Location (manual move) |
| `CON.SHIPPED` | Container → Status=Shipped |
| `CON.RECEP` | Container → Created at receipt |
| `STK.RECEP` | Stock → Created at receipt |
| `STK.LOCATE` | Stock → Location (via putaway) |
| `STK.MOVE` | Stock → Location (manual) |
| `STK.PICKING` | Stock → Quantity decreased (picking) |
| `STK.ADJ` | Stock → Quantity adjusted |
| `STK.SHIPPED` | Stock → Status=Shipped |
| `INO.CST` | ReceiptOrder → Status changed |
| `INO.CLS` | ReceiptOrder → Status=Closed |
| `OUT.CST` | ShippingOrder → Status changed |
| `OUT.CLS` | ShippingOrder → Status=Closed |
| `COU.CST` | Count → Status changed |
| `COU.END` | Count → Status=Closed/Canceled |
| `TSK.LOC.001` | Task → Status=Finished (putaway) |
| `TSK.SHIP` | Task → Status=Finished (shipping) |
## ERP Integration Touch Points
Each entity has ERP messages that create, update, or receive data:
| Entity | ERP In (ERP→WMS) | ERP Out (WMS→ERP) |
|--------|-----------------|------------------|
| Item | ITM | — |
| Owner | OWN | — |
| Supplier | SUP | — |
| Account | ACC | — |
| Carrier | CAR | — |
| Kit | KIT | KST (assemble), UNK (disassemble) |
| ItemClassification | ITC | — |
| ReceiptOrder | ROR | ROC (status), ROF (close) |
| Container (ASN) | ASN | ASO (received), ASK (rejected) |
| 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) |
| AutoWarehouse replenishment | SRN | SRO (done), SRK (canceled) |
| Container on conveyor | CMC | COS (shipped to PS), COC (closed in MP) |
## Related
- [Application Dictionary](application-dictionary.md) — AD element types: Commands, Queries, Entities
- [Container](../concepts/container.md) — Container entity deep-dive
- [Location](../concepts/location.md) — Location entity deep-dive
- [Stock](../concepts/stock.md) — Stock entity deep-dive
- [Product / Item](../concepts/product-item.md) — Item entity deep-dive
- [Task](../concepts/task.md) — Task entity lifecycle
- [Inbound Order](../concepts/order-inbound.md) — Receipt order entity
- [Outbound Order](../concepts/order-outbound.md) — Shipping order entity
- [Transactions](../concepts/transactions.md) — Full transaction audit trail
- [ERP Interface](../concepts/erp-interface.md) — ERP message catalog
wiki_old_13-05-2026/architecture/galileo-integration.md
+334
View File
@@ -0,0 +1,334 @@
---
title: "GALILEO Integration (TMS ↔ EasyWMS)"
type: architecture
sources:
- sources/archives/Presentation_GALILEO.md
- sources/archives/Communication_WMS_GALILEO.md
- sources/archives/Communication_Easy_Galileo.md
- sources/archives/Bases_fonctionnement_robotique_EasyWMS.md
- sources/archives/Documents_utiles.md
related:
- concepts/stations.md
- concepts/mechanical-elements.md
- concepts/task.md
- concepts/location.md
- operations/galileo-simulation.md
- operations/galileo-troubleshooting.md
- operations/robotics-project-lifecycle.md
- modules/automation-dashboard.md
last_compiled: "2026-04-17"
---
# GALILEO Integration (TMS ↔ EasyWMS)
## 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.
Two parallel automation controllers exist in the Mecalux ecosystem:
- **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))
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
- [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
- [IdentErrorType](https://msscc.mecalux.com/documentation/Development/master/ES/apis/easywms/Domain/IdentErrorType.md) — rejection reason codes
## EasyWMS Gateway Service
Windows service that runs on the WMS server and brokers all communication with GALILEO / EasyS.
- **Download**: https://msscc.mecalux.com/documentation/documentation/master/EN/docs_downloads/services/gateway.md
- **Install path**: `C:\Program Files\Mecalux\EasyWMS Gateway 2015`
- **Config file**: `C:\ProgramData\Mecalux\EasyWMS Gateway 2015\Config\MainObject.config`
- **Log file**: `C:\ProgramData\Mecalux\EasyWMS Gateway 2015\Logs\AllLog.log`
- **Service name**: `EasyWMSGateway2015`
- **Port used by GALILEO/EasyS**: TCP 3000 (must be open inbound/outbound on the WMS host)
Config keys (MainObject.config):
- `tenantCode` = tenant of the target WMS
- `TokenUser` = authentication (prefer over `ClientUser`)
- Passwords must be encoded via `PasswordEncrypt.exe` in the install folder
Installation and bring-up procedure: see [Galileo Simulation & Test Setup](../operations/galileo-simulation.md).
## Tasks vs Movements
EasyWMS expresses transport work at two granularities:
- **Task** = end-to-end transfer order for a container (e.g. `PIE → Miniload Location A-12-3`)
- **Movement** = single conveyor-to-conveyor hop inside a task; a single task typically spawns **N movements** (a `PIE → Miniload` task commonly resolves to 4 movements)
A movement can only be generated if a **route** exists in EasyS between its origin station and the next station. If no path exists, EasyWMS generates a **reject task** toward the configured reject station.
### Task lifecycle (robotics view)
| Status | Description |
|--------|-------------|
| **En attente** / Pending | Not yet transmitted to GALILEO, no tracking |
| **Générée** / Generated | Next movement generated but not yet transmitted |
| **En cours** / In progress | Tracking picked up by GALILEO; container placed on virtual location **Mov** |
| **Terminée** / Completed | Container reached the final task destination |
| **Annulée** / Cancelled | Cancelled before reaching destination |
**Mov** is the virtual system location used to hold a container while it's physically travelling between stations. See [Location](../concepts/location.md) and [Task](../concepts/task.md).
## 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).
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).
### Route types (EasyS)
| Type | Description |
|------|-------------|
| **Galileo** | Movement that requires calls to the Gateway (physical conveyor moves) |
| **Manual** | Movement that requires an operator action in response to a WMS task |
| **Virtual** | Automatic, instantaneous virtual stock movement (e.g. output → consolidation zone) |
### Routes that MUST report "full" to EasyWMS
GALILEO must be able to report these routes as **full** (status `3`) so the WMS can recirculate / pause:
| Source type | Destination type |
|-------------|------------------|
| CME | TE (or ME) |
| PKE | PK |
| ET | PS |
Sometimes `ETPSxx → PSxx` must be reported to sequence shipping.
### Route status values
| Value | Meaning |
|-------|---------|
| `0` | No communication |
| `1` | Available / in service |
| `2` | Electromechanical fault |
| `3` | Full (and in service) |
## Three Communication Types (initiated by GALILEO)
**All communication is GALILEO → Gateway → EasyWMS.** The WMS never pushes unsolicited commands; it only responds. Three message types drive the workflow plus two status update streams.
### 1. Event (log → `Event`)
Declaration of container presence at a meaningful point. Primary sources:
- **PIE**: reports a new container with label read + gauge data — EasyWMS decides conformity
- **TK**: announces presence
- **Picking confirmation**: operator has finished a picking task
**PIE event fields:**
| Field | Description |
|-------|-------------|
| Code | Container barcode read |
| Weight | Weighed value |
| Dimensions | Physical measurements |
| Container type | PLC Container Type code (starts at 1, defined in PLC Types menu) |
| Height type | PLC Height Type code (starts at 1) |
| Flags | Bitwise gauge check result |
| Event type | Event-specific code (e.g. `9` = reject) |
PIE flag values (bitwise):
| Flag | Meaning |
|------|---------|
| `65536` | Container OK — no error |
| `256` | Barcode error |
| `512` | Recovered container |
| `1024` / `66560` | Correct + empty |
| `3` | Holes + studs detected |
| `4` | Overheight |
| `8` – `64` | Overhangs |
| `128` | Weight excess |
**Two PIE processes depending on container origin:**
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
**PIE insert modes (set from EasyWMS → Control → Stations):**
- **Normal (known containers)** — reject anything the ASN doesn't recognize
- **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
**Workflow triggered:** `Galileo_PIEEventHandler_PR`
To enable instance tracking on PIE events: activate the process `<NomPIE>_<NomEntrepot>_GalileoPIE` in ApplicationService.
### 2. Search (log → `Search`)
GALILEO asks EasyWMS "what should I do with this container?" or "give me a next task". Triggered when:
1. A container arrives at a station and GALILEO needs the next hop
2. A TK/Miniload is idle and polls in a loop (hundreds per second)
**Search content:** tracking number, container code, station (type + number).
**Search response content:** destination station info. Capacity semantics differ by station type:
- **Conveyors / TK**: capacity = number of simultaneous trackings the station can manage
- **PK and PS**: capacity = max containers on the station **plus** all containers in movement toward it
**Station capacity vs route capacity vs WMS logical capacity** (worked example):
| Layer | Typical value for a PK |
|-------|------------------------|
| 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 |
**Response state codes:**
| Code | Meaning | Used by |
|------|---------|---------|
| `83` | **S** = Servicio (in service) | Conveyors |
| `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.
**Workflow triggered:** `Galileo_SearchCreatedEventHandler_PR`. Routed by station type inside the process.
**Command used to transmit the order to GALILEO:** `GalileoMovTrackingCreateCommand` (preferred over `GalileoMovTrackingCreateChangingTargetCommand`). Effects:
- Gateway translates the command into a GALILEO frame
- 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.
### 3. End (log → `End0`, `End1`, …)
Signals that GALILEO has finished the current movement. EasyWMS advances to the next movement of the task (or closes the task).
**End error codes:**
| Code | Meaning | Consequence |
|------|---------|-------------|
| `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 |
| `7` | Gauge error | Relocation / reject |
**Workflow triggered:** `Galileo_EndCreatedEventHandler_PR`
## Station and Route Status Updates
Sent **every 1–3 seconds** by GALILEO (or immediately on change of state / load).
### Station update (log → `Update station`)
| Field | Meaning |
|-------|---------|
| StationType | Station type code |
| StationNumber | Station number |
| Status | `0` = unavailable (fault, manual mode, safety); `1` = available |
| 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 |
> ⚠️ The Loaded semantic is inverted between sources: historical GALILEO docs use `1 = free` / `0 = loaded`, while Comprendre_logs_Gateway lists the same values (`1` = libre, `0` = chargé). Always cross-check the log with the current Gateway protocol version.
**Function exposed by GALILEO:**
```
SetStationStatus(Type, Numéro, Status, Présence, Capacité, Occupation, Allée)
```
### Route update (log → `Update route`)
| Field | Meaning |
|-------|---------|
| StationTypeSource / StationNumberSource | Origin station |
| StationTypeDestination / StationNumberDestination | Destination station |
| Status | `0`/`1`/`2`/`3` — see Route status values above |
| CurrentCount | Trackings currently between the two stations |
**Function exposed by GALILEO:**
```
SetRouteStatus(TypeOrigine, NuméroOrigine, TypeDestination, NuméroDestination, Etat)
```
## End-to-End Example — Container Arriving at PIE
```
1. PIE reads label + gauges → Event (Galileo_PIEEventHandler_PR)
then Search (Galileo_SearchCreatedEventHandler_PR)
2. EasyWMS sends next movement → container placed on Mov virtual location
movement status → In progress
3. Container reaches next station → End (Galileo_EndCreatedEventHandler_PR)
4. If on a conveyor → new Search
If on a TK inbound table (TE) → TK polls Search in loop
5. If shipping conveyor (PS) → container leaves the installation
If picking conveyor (PK) → operator confirms pick → Event → Search
```
## Sequential Machine Model (Grafcet)
Every automation element is a sequential machine (grafcet) with discrete steps and transitions. Typical conveyor sequence:
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
5. Release upstream conveyor
6. Request output toward downstream conveyor
7. Return to rest
This model is visible from the GALILEO SCADA: double-click a machine → **Graph** tab shows the current grafcet step; **Variables** shows live PLC memory.
## Application Dictionary Entry Points
Core workflows:
| Workflow | Trigger | Purpose |
|----------|---------|---------|
| `Galileo_PIEEventHandler_PR` | PIE event | Inbound identification + decision |
| `Galileo_SearchCreatedEventHandler_PR` | Search request | Next-hop routing and task delivery |
| `Galileo_EndCreatedEventHandler_PR` | End notification | Advance movement, handle error codes |
Core commands:
- `GalileoMovTrackingCreateCommand` — push an order frame to GALILEO (preferred)
- `GalileoMovTrackingCreateChangingTargetCommand` — variant that changes target mid-transport (avoid unless strictly necessary)
See [Application Dictionary](application-dictionary.md) for naming conventions and extension points.
## SCADA & Tracking
The GALILEO SCADA (visualization tool) displays machines, trackings and faults in real time.
- **Default credentials**: `mecalux / robmec`
- **Tracking editor** (double-click a machine):
- *Show tracking* — the order in execution
- *End order* — force-tell EasyWMS that the pallet has reached destination (manual override)
- *Machine state* — what GALILEO is currently reporting to EasyWMS
- **Advanced tab (unlock icon + password):**
- *Variables* — live variables; booleans can be forced
- *Graph* — current grafcet step
- **Edit buttons:**
- *Edit tracking* — origin, destination, height, type… (click "Edit" first)
- *Delete tracking* — remove tracking from the machine
- *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
- [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
- [Task](../concepts/task.md) · [Location](../concepts/location.md)
wiki_old_13-05-2026/architecture/overview.md
+199
View File
@@ -0,0 +1,199 @@
---
title: "System Architecture Overview"
type: architecture
sources:
- 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)
- areas/ERP.md
- areas/parameters.md
- CLAUDE.md context
- custom/analyse_fonctionnelle.md
- sources/archives/Presentation_GALILEO.md
- sources/archives/Communication_WMS_GALILEO.md
related:
- architecture/security.md
- architecture/application-dictionary.md
- architecture/entities-map.md
- architecture/galileo-integration.md
- concepts/erp-interface.md
- concepts/mechanical-elements.md
last_compiled: "2026-04-17"
---
# System Architecture Overview
## Overview
Easy WMS is a Warehouse Management System developed by Mecalux. It is a multi-layer web application running on Windows servers (IIS), backed by a relational database (Oracle, SQL Server, MySQL, or PostgreSQL), accessed via a SmartUI web interface, RF terminals (RFT), and mobile apps.
The system follows an **Application Dictionary (AD)** architecture where most business logic is defined as configurable metadata (entities, commands, workflows) rather than hardcoded logic, enabling extensive customization without code changes.
Easy WMS is available in two deployment models:
- **SaaS (cloud-hosted by Mecalux)**: Multi-tenant, managed infrastructure, Amazon SaaS environment (required for some modules like Amazon Marketplace)
- **On-Premise**: Installed on customer or partner-managed Windows VMs; customer controls updates, backup, and networking
## Deployment Stack
### On-Premise Deployment
| Layer | Technology |
|-------|-----------|
| OS | Windows Server |
| Web Server | IIS (Internet Information Services) |
| Application Runtime | ASP.NET Core (ASPNETCORE_ENVIRONMENT variable for dev/prod) |
| Database | Oracle 19c / SQL Server 2019 / MySQL 8.0.14+ / PostgreSQL 14+ |
| Cache | Redis (session and application cache) |
| Message Queue | Internal background job system (no external broker documented) |
| Equipment Integration | TCP/IP sockets for AGV/PLC, WIFI for Pallet Shuttle tablets |
| Print Server | Local or network label printers (Zebra-type) |
### Application Pools (IIS)
Easy WMS uses multiple IIS application pools to isolate services:
- **Main WMS pool**: Core WMS logic, UI, API endpoints
- **Background Jobs pool**: Asynchronous processing (replenishment, defragmentation, AGV, label prints)
- **Integration pool**: ERP message processing (inbound/outbound queue)
Each pool runs as a separate Windows process with its own identity and recycling schedule.
### SaaS Deployment
In SaaS mode, Mecalux hosts all infrastructure. Key differences:
- Customer accesses via browser only; no local server management
- Updates are applied by Mecalux on a managed schedule
- Some integrations (ERP, label printers, RF equipment) require VPN tunnels or local agents
- Amazon SaaS is a specific certification required for Amazon Marketplace connector (Android 10 device requirement applies)
## API Architecture
Easy WMS exposes three REST API families:
### Application Dictionary API (AD API)
The primary programmatic interface. All AD elements (Commands, Queries, Dialogs, Views, Entities) are accessible via:
```
POST /api/commands/{commandName} → Execute a Command
GET /api/queries/{queryName} → Execute a Query (LINQ-based)
GET /api/entities/{entityName} → CRUD on an Entity
POST /api/dialogs/{dialogName}/steps → Advance a Dialog flow
```
### QueryExecute (LINQ API)
Allows dynamic data retrieval using LINQ-style expressions against any exposed View or Entity. Used for reporting, dashboards, and integration reads.
### CommandExecute API
Used to trigger business operations (receive stock, release orders, assign tasks, etc.) mapped to AD Commands.
### ERP Integration API
Asynchronous message exchange via structured XML/JSON messages over REST or file-based queues. See [ERP Interface](../concepts/erp-interface.md) for the full message catalog.
## Multi-Site and Multi-Warehouse
- A single EasyWMS installation can manage multiple **Sites** (physical warehouses)
- Each site has its own **parameters**, **locations**, **users**, and **equipment**
- Inter-site transfers are managed via transfer orders (SOR type = Transfer)
- The **DOM module** extends this to multi-node distributed order management
## Warehouse Types
Two fundamental warehouse types drive most architectural decisions:
| Type | Description | Key Constraint |
|------|-------------|----------------|
| **Manual warehouse** | Human operators pick using RF or paper; locations accessed directly | No location sequencing required |
| **Automatic warehouse** | Conveyor/shuttle/AGV system; WMS controls machine movements via control system | All movements must go through task queue; no direct access |
Mixed warehouses (some automatic aisles, some manual) are supported. The warehouse type determines which task flows, counting modes, defragmentation strategies, and station types are available.
### Automation control system (TMS)
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).
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).
## Background Job System
Easy WMS relies heavily on background jobs for asynchronous processing:
| Job Name | Frequency | Purpose |
|----------|-----------|---------|
| TryToReplenishProductLocations | Continuous | Automatic replenishment of PDL locations |
| Delete_StockStatusJob_PR | Every 15 min | Remove expired stock quality locks |
| AGV communication jobs | Continuous | Phase protocol exchange with AGV controllers |
| PSService | Continuous | Pallet Shuttle tablet communication |
| Continuous Slotting | Configurable | Ongoing slotting recommendations |
| Metric Gatherer | Configurable | Data Analytics KPI collection |
| Cycle Count Generation | Per schedule | Create cycle count batches |
| Defragmentation Planner | Per schedule | Execute defragmentation strategies |
## Hardware Requirements
### On-premise minimum server specifications
| Server role | CPU | RAM | Storage |
|-------------|-----|-----|---------|
| **Database server** | 4-core @ ≥ 3 GHz | 32 GB | 600 GB (data) + 50 GB (OS) |
| **Application server** | 4-core @ ≥ 3 GHz | 32 GB | 200 GB (logs + app) |
Both servers run Windows Server. For small warehouses the DB and App roles can be on the same machine (specifications must still be met).
### Client and peripheral hardware
- **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)
- **Scales**: PIE stations can have integrated scales for container weight validation
- **Mobile Devices**: Android 10+ required for Amazon SaaS Marketplace integration
### SaaS tiers (Azure-hosted by Mecalux)
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) | — | — | — |
| **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.
## License Model
Easy WMS licenses are modular:
- **Base WMS**: Core inbound/outbound/inventory functionality
- **Module licenses**: Each additional module (AGV, Pallet Shuttle, Multi-Carrier, Slotting, LMS, 3PL Billing, DOM, etc.) requires a separate license
- **User licenses**: Typically per concurrent user or per named user
- **Site licenses**: Some modules require per-site activation
## Parameters and Configuration
System behavior is governed by two layers of parameters:
1. **Organization-level parameters**: Apply globally across all warehouses
2. **Warehouse-level parameters**: Override organization defaults for a specific site
Key system parameters are documented at `areas/parameters.md`. Each functional module has its own parameter set. See [Parameters](../concepts/parameters.md) for the full compiled reference.
## Common Errors
| Symptom | Likely Cause |
|---------|-------------|
| IIS application pool stopped | Background job crash or unhandled exception; check Windows Event Log |
| ERP messages not processed | Integration pool stopped or message queue backlog; check integration logs |
| RF terminal cannot connect | WIFI network issue or IIS binding misconfiguration |
| "Development environment" error in browser | ASPNETCORE_ENVIRONMENT set to Development in production; should be Production |
| Automatic warehouse tasks not generating | Background job (replenishment/defragmentation planner) not running |
## Related
- [Application Dictionary](application-dictionary.md) — AD structure: Commands, Queries, Entities, Workflows
- [Security](security.md) — User roles, authentication, audit
- [Entities Map](entities-map.md) — Data model and entity relationships
- [ERP Interface](../concepts/erp-interface.md) — All ERP messages and integration protocols
- [Parameters](../concepts/parameters.md) — System configuration parameters
- [AGV](../modules/agv.md) — Automatic warehouse AGV protocol
- [Pallet Shuttle](../modules/pallet-shuttle.md) — PS system architecture
- [APS3D](../modules/aps3d.md) — Fleet Manager controller
wiki_old_13-05-2026/architecture/rf-menu.md
+246
View File
@@ -0,0 +1,246 @@
---
title: "RF Terminal Menu Map"
type: architecture
sources:
- sources/archives/menu_rf_easywms.md
related:
- architecture/application-dictionary.md
- concepts/task.md
- concepts/reception.md
- concepts/putaway.md
- concepts/picking.md
- concepts/replenishment.md
- concepts/count.md
- concepts/shipping.md
- concepts/kits.md
- concepts/quality-control.md
- concepts/container.md
- concepts/group.md
- modules/multi-carrier.md
last_compiled: "2026-04-17"
---
# RF Terminal Menu Map
## Overview
The handheld RF terminal (`consolerf`) surfaces every operator flow through a fixed **12-menu hierarchy**. Each menu entry is bound to a **workflow** identified by its fully-qualified name (`<Namespace>.<WorkflowCode>`). Understanding this mapping matters for four reasons:
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.
All workflow codes belong to the `EasyWMS` namespace unless otherwise noted (`Deliveries` for the Multi-Carrier module).
## 1. Tasks — `RFMenu_Task`
| Menu entry | Workflow |
|---|---|
| Automatic task | `EasyWMS.Task_AutomaticAssignment_PR` |
| Semi-automatic task | `EasyWMS.Task_SemiautomaticAssignment_UI` |
| Putaway task | `EasyWMS.Putaway_GetPutawayTaskFromMenu_UI` |
| Picking task | `EasyWMS.Outbound_ObtainPickingTask_PR_V2` |
| Shipping task | `EasyWMS.Expedition_ExecuteShipping_FromMenu_PR` |
| Replenishment task | `EasyWMS.Replenishment_GetReplenishTasksFromMenu_PR` |
| Count task | `EasyWMS.Count_GetTasksFromMenu_PR` |
| Empty locations task | `EasyWMS.DynamicProductLocation_EmptyLocation_UI` |
| Movement task | `EasyWMS.Movement_Tasks_FromMenu_UI` |
| PS Group shipping tasks | `EasyWMS.PsGroup_ExpeditionTasks_UI` |
| TenseFlow task | `EasyWMS.TenseFlow_ExecuteBufferReplenishment_FromMenu_UI` |
| Consolidation task | `EasyWMS.Consolidation_AutomaticTasks_FromMenu_UI` |
| Cutting task | `EasyWMS.CutInStation_Main_UI` |
## 2. Receptions — `SharedMenu_Receptions`
### Blind reception — `RFMenu_BlindReception`
| Menu entry | Workflow |
|---|---|
| Loose stock or in container | `EasyWMS.BlindReception_UI` |
| Mono-reference | `EasyWMS.BlindReception_Monoreference_Containers_UI` |
| Identical mono-reference | `EasyWMS.BlindReception_Monoreference_Identical_Containers_UI` |
### Suppliers — `RFMenu_Providers`
| Menu entry | Workflow |
|---|---|
| Loose stock or multi-reference | `EasyWMS.Reception_Supplier_LooseStockOrMultireference_UI` |
| Mono-reference | `EasyWMS.Reception_Supplier_Monoreference_Containers_UI` |
| Identical mono-reference | `EasyWMS.Reception_Supplier_Monoreference_Identical_Containers_UI` |
### Other receptions
| Menu entry | Workflow |
|---|---|
| Return reception | `EasyWMS.Reception_Return_UI` |
| Advance notice reception | `EasyWMS.AdvanceNotice_Reception_UI` |
| Generate labels | `EasyWMS.PrintLabels_MultireferenceContainerLabels_UI` |
## 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`
| Menu entry | Workflow |
|---|---|
| Order picking | `EasyWMS.Expedition_OrderPicking_UI` |
| Manual picking | `EasyWMS.ManualPicking_ByItem_UI` |
| Wave picking | `EasyWMS.WorkWave_ExecuteTask_UI` |
| Virtual picking | `EasyWMS.VirtualPicking_MainFromRF_UI` |
| Packing | `EasyWMS.Expedition_PackingInLocation_UI` |
| Paper confirmation | `EasyWMS.Picking_ConfirmPickingPaper_UI` |
| Manual preparation | `EasyWMS.Expedition_ManualPreparation_UI` |
### PTL Picking — `RFMenu_PickingPTLs`
| Menu entry | Workflow |
|---|---|
| PTLs | `EasyWMS.PTLsPickingPreparation_OrderAssignment_SelectMode_UI` |
| Enter zone | `EasyWMS.PTLsPickingPreparation_EnterZone_UI` |
| Exit zone | `EasyWMS.PTLsPickingPreparation_ExitZone_UI` |
| Unload | `EasyWMS.PTLsPickingPreparation_ManualUnload_UI` |
| Equipment status | `EasyWMS.PTLsPickingPreparation_ManualEquipmentInfo_UI` |
| Manual preparation | `EasyWMS.PTLsPickingPreparation_ManualPreparation_UI` |
### Truck loading — `RFMenu_TruckLoad`
| Menu entry | Workflow |
|---|---|
| Container load | `EasyWMS.TruckLoad_GetLoads_UI` |
| Container unload | `EasyWMS.UnloadContainer_UI_v1` |
| Stock load | `EasyWMS.StockTruckLoad_GetLoads_UI` |
| Parcel load | `Deliveries.Dlv_TruckLoad_GetLoads_UI` |
### Undo preparation — `RFMenu_UndoPreparation`
| Menu entry | Workflow |
|---|---|
| Undo preparation | `EasyWMS.UndoPreparation_Main_PR` |
| Undo excess | `EasyWMS.UndoExcess_Main_PR` |
## 5. Replenishment — `RFMenu_Replenishment`
| Menu entry | Workflow |
|---|---|
| By location | `EasyWMS.Replenishment_GetReplenishLocations_UI` |
| By aisle | `EasyWMS.Replenishment_GetProductLocationsListByAisle_UI` |
| By warehouse | `EasyWMS.Replenishment_GetAllProductLocationsByWarehouse_UI` |
| By outbound order | `EasyWMS.Replenishment_GenerateTasksByOutboundOrder_UI` |
## 6. Counts — `SharedMenu_Counts`
| Menu entry | Workflow |
|---|---|
| Select a count | `EasyWMS.Count_SelectCount_UI` |
| Physical count | `EasyWMS.Count_StockOnPhysicalLocation_UI` |
| Informed count | `EasyWMS.Count_StockOnPhysicalLocation_Informed_UI` |
## 7. Kits — `RFMenu_Kits`
| Menu entry | Workflow |
|---|---|
| Component request | `EasyWMS.KitAssembly_CreateWorkOrder_UI` |
| Assemble | `EasyWMS.KitAssembly_UI` |
| Disassemble | `EasyWMS.KitDisassembly_UI` |
## 8. Quality — `RFMenu_Quality`
| Menu entry | Workflow |
|---|---|
| Lock by item | `EasyWMS.Quality_LockByProduct_UI` |
| Lock by container/location | `EasyWMS.Quality_LockByLocationOrContainer_UI` |
| Unlock by item | `EasyWMS.Quality_UnlockByProduct_UI` |
| Unlock by container/location | `EasyWMS.Quality_UnlockByLocationOrContainer_UI` |
## 9. Groups — `RFMenu_Groups`
| Menu entry | Workflow |
|---|---|
| Ungroup orders | `EasyWMS.Ungroup_Outboundorders_UI` |
| Ungroup PTL | `EasyWMS.Ungroup_PTL_UI` |
| Extraction | `EasyWMS.Extraction_Regular_UI` |
| Incident extraction | `EasyWMS.Extraction_Incidents_UI` |
| Extraction without pack | `EasyWMS.Extraction_WithoutPack_UI` |
| Change location | `EasyWMS.Ungroup_ChangeLocation_UI` |
## 10. Utilities — `RFMenu_Utilities`
| Menu entry | Workflow |
|---|---|
| Show item | `EasyWMS.Utils_ShowProduct` |
| Show container | `EasyWMS.Utils_ShowContainer` |
| Show location | `EasyWMS.Utils_ShowRealLocation` |
| Print labels | `EasyWMS.PrintLabels_MenuOptions_UI` |
| Increase stock | `EasyWMS.Utils_IncreaseProduct` |
| Decrease stock | `EasyWMS.Utils_DecreaseProduct` |
| Location adjustment | `EasyWMS.AdjustStock_UI` |
| Scrap | `EasyWMS.Tool_Scrap` |
| My stock | `EasyWMS.Equipment_CheckStock_UI` |
| My containers | `EasyWMS.Equipment_My_Containers_UI_V1` |
| Product location | `EasyWMS.ProductLocation_Create_UI` |
| Manual movement | `EasyWMS.ManualMovement_Main_UI` |
| Change compact mode | `EasyWMS.DriveInLocations_SetCompactStorageMode_UI` |
| Compact drive-in aisle | `EasyWMS.DriveInLocation_Compact_UI` |
| Show rejections | `EasyWMS.Utils_ShowRejections_UI` |
| Manual consolidation | `EasyWMS.Utils_ManualConsolidation_UI` |
| Buffer consolidation | `EasyWMS.Utils_Consolidation_BufferStationProcess_UI` |
| Show cart | `EasyWMS.Utils_ShowCart_UI` |
| My cart | `EasyWMS.Equipment_MyCart_UI` |
### Remount / Unremount containers — `RFMenu_RemountUnRemountContainers`
| Menu entry | Workflow |
|---|---|
| Remount containers | `EasyWMS.Container_RemountContainers_UI` |
| Match containers | `EasyWMS.Container_MatchContainers_UI` |
| Unremount container | `EasyWMS.Container_UnremountContainer_UI` |
| Unremount all containers | `EasyWMS.Container_UnremountAllContainers_UI` |
## 11. Pick and Pass — `Menu_PickAndPass`
| Menu entry | Workflow |
|---|---|
| Receptions | `EasyWMS.PickAndPass_Reception_Main_UI` |
| Close containers | `EasyWMS.PickAndPass_CloseContainer_FromMenu_UI` |
| Putaway | `EasyWMS.PickAndPass_Putaway_Main_UI` |
| Picking | `EasyWMS.PickAndPass_Picking_Main_PR` |
| Automatic task | `EasyWMS.PickAndPass_AutomaticAssignment_Main_UI` |
## 12. Packaging — `Menu_Packaging` *(Multi-Carrier module)*
| Menu entry | Workflow |
|---|---|
| Packaging | `Deliveries.Dlv_Packaging_Process_FromRF_UI` |
| Carrier verification | `Deliveries.Dlv_Packaging_Verification_CarrierVerification_UI` |
| Change carrier | `Deliveries.Dlv_Packaging_ChangeCarrier_FromRF_UI` |
| Show parcel | `Deliveries.Dlv_Utils_ShowPackage` |
| Move parcel | `Deliveries.Dlv_PackageManualMovement_PR` |
| Bulk load | `Deliveries.Dlv_BulkLoad_UI` |
### Reprint tracking number — `ReprintTrackingNumber_RFMenu`
| Menu entry | Workflow |
|---|---|
| Last unlabelled delivery | `Deliveries.Dlv_Packaging_ReprintTrackingNumber_LastUnlabelledDelivery_FromRF_UI` |
| Labelled delivery | `Deliveries.Dlv_Packaging_ReprintTrackingNumber_LabelledDelivery_UI` |
## Related
- [[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
- [[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
- [[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)
- [[count]] — menu 6 physical-count workflows
- [[shipping]] — menu 4 packing + undo-preparation close the shipping loop on the RFT
- [[kits]] — menu 7 assembly / disassembly
- [[quality-control]] — menu 8 lock / unlock
- [[group]] — menu 9 group and extraction flows
- [[container]] — `Utilities → Remount/Unremount` flows manipulate the container tree
- [[multi-carrier]] — menu 12 only appears when the Multi-Carrier (`Deliveries`) module is enabled
wiki_old_13-05-2026/architecture/security.md
+170
View File
@@ -0,0 +1,170 @@
---
title: "Security"
type: architecture
sources:
- areas/security/index.md (404 — compiled from cross-source knowledge)
- areas/parameters.md
- areas/inventory_management/stations/roles.md
- modules cross-source knowledge
- custom/analyse_fonctionnelle.md
related:
- architecture/overview.md
- architecture/application-dictionary.md
- modules/billing-3pl.md
- modules/3pl-portal.md
- modules/owner-extensions.md
last_compiled: "2026-04-26"
---
# Security
## Overview
Easy WMS security is built around a role-based access control (RBAC) model layered over a multi-tenant site architecture. Each user belongs to one or more **roles** that grant access to specific UI areas, commands, and data scopes. Security operates at three levels: authentication (who you are), authorization (what you can do), and data isolation (what data you can see).
## User Roles
Easy WMS defines a role hierarchy with increasing privileges:
| Role | Scope | Capabilities |
|------|-------|-------------|
| **SuperAdmin** | Organization (all sites) | Full access including user management, system parameters, all modules |
| **Administrator** | Organization or per-site | Most functional areas; may be scoped to one warehouse |
| **Manager** | Per-site | Operational supervision; can release orders, manage counts, view reports |
| **Operator** | Per-site | Execute daily operations: picking, receiving, counting, shipping |
| **RF Operator** | RF terminal only | Subset of Operator; limited to terminal flows |
| **Viewer / Read-only** | Per-site | Read-only access to views and reports |
| **3PL Client** | Owner-scoped | Only sees data for their owner; requires 3PL Portal module |
| **SCEM Admin** | Cross-site | Manages Supply Chain Event subscriptions and notification routing |
Custom roles can be defined in the AD to grant fine-grained access to specific Commands, Views, and Dialogs.
## Authentication
### Standard login
- **Web (SmartUI)**: Username/password authentication; session managed via encrypted cookie
- **RF Terminals**: Username/password entered at terminal login screen; sessions can be configured to time out after inactivity
- **API (ERP Integration)**: API key or service account credentials; configured per integration endpoint
Password policies (minimum length, complexity, expiry) are configurable in system parameters.
### QR Code login (RF terminals)
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
- **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)
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
- **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
## Authorization Model
Authorization is evaluated at two levels:
### Menu / UI Access
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.
### Data Scope (Owner Isolation)
When the **Owner Extensions** module is active, data is isolated by owner:
- Receipt orders, shipping orders, and master data (items, suppliers, accounts) carry an owner code
- Users assigned to a specific owner can only see and act on that owner's data
- 3PL Portal users have this isolation enforced automatically
- See [Owner Extensions](../modules/owner-extensions.md) for details
## Station Roles
Beyond system roles, operators are assigned to **station roles** that determine which warehouse stations they can work at. Station roles are configured per station type:
- An operator with "Receiving" role can work at Dock and PIE stations
- An operator with "Picking" role can work at PK/PS/ME stations
- An operator can hold multiple station roles simultaneously
Station role assignment is done in the Warehouse Designer or via the Stations administration view.
## Audit Trail
Every significant operation in Easy WMS generates a **Transaction** record:
- Who performed the operation (user)
- When (timestamp)
- What (transaction type code, e.g., STK.ADJ, CON.MOVE)
- On which objects (container, location, item, order)
- From which equipment (RFT, workstation IP)
Transactions are immutable and cannot be deleted. They form the complete audit trail for stock movements, adjustments, order processing, and user actions. See [Transactions](../concepts/transactions.md) for the full transaction type catalog.
## Quality Locks (Stock Security)
Quality Control uses a two-tier lock system to prevent unauthorized stock movements:
- **Receiving status**: Set automatically during reception; cleared when stock passes QC
- **User status**: Set manually or via ERP STR message; cleared manually or via time-based unlock
Stock with an active lock cannot be assigned to shipping orders or moved by standard tasks. This provides a safety mechanism to prevent inadvertent shipment of quarantined stock. See [Quality Control](../concepts/quality-control.md) for details.
## Container Locks
Containers can be locked with specific lock types that prevent certain operations:
| Lock Type | Blocked Operation |
|-----------|------------------|
| Inbound lock | Container cannot receive new stock |
| Outbound lock | Container cannot be picked or shipped |
| Movement lock | Container cannot be moved to another location |
| Blocking lock | All operations blocked |
Container lock events generate `LCK.CON.001` and `ULK.CON.001` transactions.
## Network and Infrastructure Security
- **IIS Application Pools**: Run under dedicated service accounts with minimal OS privileges
- **Database**: Separate credentials per application pool; principle of least privilege
- **API Keys**: ERP integration uses API keys per connection; keys are rotated per customer policy
- **HTTPS**: All SmartUI and API traffic encrypted via TLS; HTTP redirects to HTTPS enforced
- **RF WIFI**: RF terminals communicate over WPA2/WPA3 encrypted WIFI networks
- **AGV Communication**: AGV systems communicate over dedicated network segments (VLAN isolation recommended)
- **VPN**: SaaS deployments require VPN tunnels for on-premise ERP integration and printer connectivity
## Notification Security
The SCEM (Supply Chain Event Management) module allows subscribing to operational events. Subscriptions are scoped by role:
- **SuperAdmin/Administrators/Managers**: Can subscribe to any event type
- **3PL clients**: Can only subscribe to events related to their owner
- Notification channels (email, SMS, web) are configured per subscription
## Parameters Affecting Security
| Parameter | Effect |
|-----------|--------|
| `SESSION_TIMEOUT_MINUTES` | RF and web session inactivity timeout |
| `PASSWORD_MIN_LENGTH` | Minimum password length |
| `MAX_LOGIN_ATTEMPTS` | Account lockout threshold |
| `AUDIT_LOG_RETENTION_DAYS` | How long transaction logs are kept |
## Common Errors
| Symptom | Cause | Solution |
|---------|-------|---------|
| User cannot access a menu | Role missing required permission | Add the menu item to the user's role in AD configuration |
| RF terminal login rejected | User has no station role at that station type | Assign appropriate station role |
| ERP API calls return 401 | API key expired or invalid | Regenerate API key in integration configuration |
| Stock cannot be assigned (locked) | User or receiving status active | Check Quality Control view; unlock if appropriate |
| 3PL client sees other owners' data | Owner Extensions not configured | Enable Owner Extensions module and assign owner to user |
## Related
- [Overview](overview.md) — System architecture and deployment model
- [Application Dictionary](application-dictionary.md) — Role and permission configuration via AD
- [Transactions](../concepts/transactions.md) — Audit trail for all operations
- [Quality Control](../concepts/quality-control.md) — Stock lock system
- [Owner Extensions](../modules/owner-extensions.md) — Multi-owner data isolation
- [3PL Portal](../modules/3pl-portal.md) — External client access model
- [Supply Chain Event Management](../modules/supply-chain-event.md) — Notification subscriptions
wiki_old_13-05-2026/concepts/account-owner.md
+93
View File
@@ -0,0 +1,93 @@
---
title: "Account / Owner"
type: concept
sources:
- areas/inventory_management/masters/accounts.md
- areas/inventory_management/owners.md
- areas/inventory_management/mixing_owners.md
- areas/inventory_management/views/view_accounts.md
- areas/inventory_management/views/view_owners.md
related:
- concepts/stock.md
- concepts/order-outbound.md
- concepts/order-inbound.md
- modules/billing-3pl.md
- modules/3pl-portal.md
- modules/owner-extensions.md
- concepts/erp-interface.md
last_compiled: "2026-04-10"
---
# Account / Owner
## Overview
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 **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.
---
## Owner Attributes
| Property | Description |
|----------|-------------|
| Code | Unique identifier (prefixes all owned master data when Owner Extensions active) |
| Description | Descriptive text |
| Allow mixing | Whether this owner's stock can be mixed with other owners' stock in the same location |
| User group | User group with permission to work with this owner (required for 3PL Portal) |
| Address / Contact | Owner address and contact data |
### 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.
---
## Account Attributes
| Property | Description |
|----------|-------------|
| Name | Unique name |
| Type | Account type (configurable) |
| Owner | Mandatory when Owner Extensions module is active |
| Company | Company the account belongs to |
| Preferred carrier | Informational only |
| Client label report | Custom label format printed on dock unload for this account's client containers |
| Client delivery note report | Custom delivery note printed on dock unload |
| Use strict FEFO | Forces strict FEFO (first-expired-first-out) stock assignment for this account's orders; orders using this flag cannot be grouped/batched with other orders |
---
## ERP Integration
| Message | Direction | Description |
|---------|-----------|-------------|
| OWN | ERP→WMS | Create/update owner master data |
| ACC | ERP→WMS | Create/update account master data |
---
## Interface
| Path | Equipment | Description |
|------|-----------|-------------|
| `Masters > Third party > Owners` | PC | View and manage owners |
| `Masters > Third party > Accounts` | PC | View and manage accounts |
---
## Related
- [[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-inbound]] — receipt orders reference owners when Owner Extensions is active
- [[owner-extensions]] — prerequisite module for mandatory owner assignment; enables per-owner data isolation
- [[billing-3pl]] — 3PL billing contracts are created per owner
- [[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
wiki_old_13-05-2026/concepts/carrier.md
+100
View File
@@ -0,0 +1,100 @@
---
title: "Carrier"
type: concept
sources:
- areas/multi_carrier_shipping/multicarrier_admin/views/view_extended_carriers.md
- areas/multi_carrier_shipping/multicarrier_admin/views/view_deliveries.md
- areas/multi_carrier_shipping/multicarrier_admin/packing_supported_services.md
- areas/multi_carrier_shipping/multicarrier_admin/packing_printing.md
related:
- concepts/shipping.md
- concepts/order-outbound.md
- concepts/labels.md
- modules/multi-carrier.md
- concepts/erp-interface.md
- modules/yard-management.md
last_compiled: "2026-04-10"
---
# Carrier
## Overview
A **carrier** in EasyWMS is the transport company that delivers outbound shipments to accounts. At the basic level, the carrier is a master data entity with a code and preferred assignment on shipping orders. When the **Multi-Carrier Shipping module** is active, carriers become **extended carriers** with a full set of integration attributes (label formats, tracking code generation, packaging workflows, staging docks, etc.).
---
## Base Carrier Attributes
| Property | Description |
|----------|-------------|
| Code | Unique identifier |
| Name | Descriptive name |
| Account (preferred) | Optional preferred carrier for an account (informational) |
---
## Extended Carrier Attributes (Multi-Carrier module)
| Property | Description |
|----------|-------------|
| Client code | Account code assigned by the carrier to the organization (provided by carrier) |
| Stage | Mandatory stage station for loading this carrier's packages |
| Carrier type | Carrier implementation type (standard known carrier or custom/personalized) |
| Print label | Whether carrier label (tracking barcode) is printed during packaging |
| Label report | Report implementing the carrier's label format (auto-filled for standard carriers) |
| Print delivery note | Whether delivery note is printed per package |
| Cargo manifest report | Report for cargo manifests (auto-filled for standard carriers) |
| Weight capture | Whether package weight must be captured during packaging |
| Ship containers | Whether containers can be shipped directly (vs. individual packages only) |
| Packaging mode | Preferred packaging mode: ONE_PACKAGE / CHOOSE_NUM_PACKAGES / CAPTURE_STOCK |
| Files directory | Server directory for tracking code calculation files (custom carriers only) |
| Additional data | Carrier-specific configuration (provided by carrier) |
| Sequence code | Sequence for tracking code generation (when required by carrier) |
| Work process (tracking code) | Workflow for tracking code calculation (custom carriers only) |
| Waiting time to cancel delivery | Minimum minutes before a delivery can be canceled (carrier-specific) |
---
## Carrier Selection
Carriers are assigned to shipping orders:
- **Manual assignment**: via SOR ERP message (carrier field on order).
- **Automatic selection**: Multi-Carrier auto-selection rules match order attributes (destination, weight, dimensions) to eligible carriers.
- **Account preferred carrier**: informational default, not enforced automatically.
---
## Delivery Entity
When the Multi-Carrier module is active, a **Delivery** combines carrier + consignee (account address) for a specific shipment. Deliveries hold the tracking number, delivery note, package list, and carrier label. One shipping order can produce multiple deliveries (e.g., when `DlvShareDeliveries` is set on the SOR). See [Multi-Carrier](../modules/multi-carrier.md).
---
## ERP Integration
| Message | Direction | Description |
|---------|-----------|-------------|
| CAR | ERP→WMS | Create/update carrier master data |
| RUT | ERP→WMS | Create/update route definitions (used with carriers for truck loading) |
---
## Interface
| Path | Equipment | Description |
|------|-----------|-------------|
| `Masters > Carriers` | PC | View and manage base carriers |
| `Multi-Carrier > Extended carriers` | PC | Extended carrier attributes (Multi-Carrier module) |
| `Multi-Carrier > Deliveries` | PC | View deliveries per carrier |
---
## Related
- [[shipping]] — shipping orders reference carriers; routes and loads assign containers to carriers
- [[order-outbound]] — SOR message can include carrier assignment; carrier determines delivery structure
- [[labels]] — carrier labels (tracking barcodes) printed during Multi-Carrier packaging
- [[multi-carrier]] — full carrier integration: packaging stations, tracking, delivery lifecycle
- [[yard-management]] — carrier appointments at yard checkpoints and docks
- [[erp-interface]] — CAR message syncs carrier master; RUT message sends route data
wiki_old_13-05-2026/concepts/consolidation.md
+199
View File
@@ -0,0 +1,199 @@
---
title: "Consolidation"
type: concept
sources:
- areas/consolidation/index.md
- areas/consolidation/consolidation_admin/consolidation_process_creation.md
- areas/consolidation/consolidation_automatic/index.md
- areas/consolidation/consolidation_automatic/2loc_PK_consolidation.md
- areas/consolidation/consolidation_automatic/ManualMP_PK_consolidation.md
- areas/consolidation/consolidation_automatic/Buffer_consolidation.md
related:
- concepts/container.md
- concepts/location.md
- concepts/stock.md
- concepts/task.md
- concepts/shipping.md
last_compiled: "2026-04-10"
---
# Consolidation
## Overview
**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.
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.
---
## Supported Use Cases
| Use case | Warehouse type | Container type |
|---|---|---|
| Single-reference container (one item), manual warehouse | Manual | Container with "full quantity" configured per item/container type |
| Single-reference container (one item), automatic warehouse | Automatic | Container with "full quantity" configured per item/container type |
| Multi-reference container with business areas, automatic warehouse | Automatic | "Full quantity" configured per business area type/container type |
> Stock of different item presentations is **never mixed** in a single consolidation order.
---
## Architecture: Process → Orders → Tasks
```
Consolidation Process (criteria, priority, destination station)
│
▼ [Release]
Consolidation Orders (N orders = N destination containers)
│
├── Destination consolidation task (1 per destination container)
└── Source consolidation tasks (1 per source container)
```
**Consolidation process:** A filter definition created by a user specifying which containers are candidates and where consolidation should happen.
**Consolidation order:** Groups source containers (to be emptied) → destination container (to receive all stock). One order = one destination.
**Consolidation order lines:** Each line represents one source container.
---
## Process Configuration
When creating a consolidation process, the user specifies:
### Process Definition
| Field | Description |
|---|---|
| Code | Unique process identifier |
| Priority | Determines task priority for this process's orders |
| Maximum duration | When exceeded, no new consolidation orders are generated |
| Maximum number of orders | Stops generating new orders when this total is reached |
| Maximum simultaneous orders | Controls how many active orders exist at once; new ones created as old ones finish |
### Filtering Criteria
| Filter | Description |
|---|---|
| Item | Restrict to a specific item |
| Item type | Restrict by item type |
| Hazard | Filter by hazard classification |
| ABC classification | Filter by ABC rotation class |
| Owner | Filter by stock owner |
| Supplier | Filter by supplier |
| Max occupation % | Skip containers whose fill % exceeds this threshold |
> Regardless of item filter, each consolidation order is always for the same item **and** conversion (UoM). Different item presentations are never consolidated together.
### Allow Mixing
Logistic attributes that can be mixed within the same item (e.g., different lots in the same container).
### Destination Station
The picking conveyor or buffer where consolidation will physically occur.
---
## Process Lifecycle
```
Standby (created)
│
▼ [Release]
Released ← EasyWMS evaluates and generates orders
│
│ [Pause]
▼
Paused ← can be re-released
│
▼ [Cancel]
Canceled ← all associated orders, lines, and tasks canceled
```
A process can only be released from **Standby** or **Paused** status.
---
## Consolidation in Automatic Warehouses
For automatic warehouses, consolidation is a guided, task-driven process. Containers must be extracted to a picking station.
### Consolidation at Picking Conveyor (2 Locations)
Containers arrive sequenced at the PK:
1. **Destination container** arrives first and occupies one PK location
2. **Source containers** arrive one by one at the second PK location
3. Operator confirms source → destination transfer at the workstation
**Issues the operator can report:**
| Issue | Result |
|---|---|
| Incorrect quantity in origin | Stock adjustment on source container; if less than expected, consolidation line also adjusted |
| Item not found in origin | Consolidation order line canceled |
| Item not found at destination | Entire consolidation order canceled |
| Capacity exceeded at destination | Line adjusted; source remains non-empty |
**Transactions:**
- `CON.MOVE` — container location changes (warehouse → PK → warehouse)
- `STK.MOVE` — stock moved from source to destination container
- `CON.SEND.L&F` — if empty source container is sent to Lost & Found
### Consolidation at Picking Conveyor with Manual Preparation Zones (MP)
1. All source containers arrive first at the PK and stock is extracted to MP tables
2. Destination container arrives last; all MP stock dumped onto it
3. Mixing of different items within the same MP table is **not allowed**
### Consolidation at Buffer
1. All source containers arrive at the buffer station first
2. Destination container arrives last
3. Stock movement between containers is **not guided** (no task confirmation) once containers are out of the warehouse
Hardware: PC + RFT (buffer consolidation supports both)
---
## Configuration Requirements
For consolidation to work correctly:
1. **Full quantity must be configured** per container type, item, and unit of measure
2. If the warehouse uses divisions: full quantity per **business area type**, container type, item, and UoM
3. If consolidating at a picking station with preparation zones: allocation mode must be set to **Automatic**
4. Picking station working mode must be **All Modes** or **Consolidation Only**
---
## Interface
| Path | Equipment |
|---|---|
| `Consolidation > Consolidation processes` | PC |
| `Consolidation > Consolidation orders` | PC |
| `Consolidation > Consolidation order lines` | PC |
| `Warehouse > Tasks` (task monitoring) | PC |
| `Workstations > Picking` (execution at PK) | PC |
---
## Common Errors
| Symptom | Cause | Solution |
|---|---|---|
| No consolidation orders generated after release | Full quantity not configured for item/container type | Configure "full quantity" in item/container type master |
| Consolidation orders generated but no tasks | PK station not in "All Modes" or "Consolidation Only" | Update picking station working mode config |
| Process stuck at maximum simultaneous orders | All slots occupied; waiting for existing orders to finish | Wait for current orders to complete or cancel stale ones |
| Source container not empty after consolidation | Stock in another division or incident reported | Create return-to-warehouse task manually if needed |
---
## Related
- [[container]] — Consolidation moves stock between containers; source containers are emptied, destination receives all stock
- [[location]] — Consolidation frees up locations by eliminating partial containers
- [[stock]] — STK.MOVE transactions update stock records during consolidation
- [[task]] — Consolidation generates source/destination task pairs; priority set by process priority
- [[shipping]] — Shipping consolidation (distinct concept) reorganizes prepared stock for outbound orders
wiki_old_13-05-2026/concepts/container.md
+490
View File
@@ -0,0 +1,490 @@
---
title: "Container (LPN)"
type: concept
sources:
- areas/inventory_management/containers.md
- areas/inventory_management/containers/container_types.md
- areas/inventory_management/containers/container_lock_types.md
- areas/inventory_management/containers/division_types.md
- areas/inventory_management/containers/my_containers.md
- areas/inventory_management/containers/stacked_containers.md
- areas/inventory_management/containers/stack_match_containers.md
- areas/inventory_management/containers/unstack_unmatch_containers.md
- areas/inventory_management/containers/reports/Putaway_search_location_trace.md
- areas/inventory_management/asncontainers.md
- areas/receptions/reception_dock/supplier_container.md
- areas/receptions/reception_dock/blind_container.md
- areas/TransactionTypes.md
- sources/archives/27_Modification_sequence_SSCC.md
- sources/archives/33_Les_poids.md
related:
- concepts/location.md
- concepts/stock.md
- concepts/reception.md
- concepts/putaway.md
- concepts/shipping.md
- concepts/task.md
- concepts/order-inbound.md
- concepts/order-outbound.md
- concepts/labels.md
- concepts/transactions.md
- concepts/erp-interface.md
last_compiled: "2026-04-17"
---
# Container (LPN)
## 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.
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.
---
## Main Attributes
| Property | Description |
|---|---|
| **Code** | Unique identifier. Usually an **SSCC** (18 numeric digits per GS1 standard). Characters `&`, `<`, `>`, `` ` `` are not allowed. Validated against GS1 format if `LPN_CHECK_CODE_GS1LABEL` is active. Can be checked for uniqueness vs. station codes, locations, and item aliases via `CONTAINER_CHECK_CODE_REPEATED_FOR_LABELS`. |
| **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. |
| **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. |
| **Status** | Current lifecycle state (see [Lifecycle & Statuses](#lifecycle--statuses)). |
### Weight Properties
EasyWMS maintains five weight values per LPN. Only **Calculated weight** is applied to capacity restrictions (location max weight, equipment max weight).
| Weight Property | Description |
|---|---|
| **Theoretical weight** | Computed: sum of stock line theoretical weights + LPN type empty weight. |
| **Real weight** | Theoretical weight of this LPN + sum of theoretical weights of all stacked LPNs on top. |
| **Scale weight** | Reported by WMS after LPN passes a scale (SCA), or entered manually by a user. |
| **Theoretical scale weight** | Scale weight corrected each time stock quantity changes (recalculated from stock theoretical weight). |
| **Calculated weight** | `max(Real weight, Theoretical scale weight)`. This is the value used for all weight-based restrictions. |
> 📖 For variable-weight items, PIE passage behaviour, and the complete formula walk-through see [Weights](weights.md). Note: the internal "Real weight" field in the Container entity is `max(Calculated, Theoretical Scale)` whereas the definition above (used for stacking capacity checks) aggregates stacked containers. Both are documented side-by-side in [Weights](weights.md).
---
## Types
### LPN Types
LPN types define the physical characteristics of an empty LPN. Configured in the **EasyS** tool, not in the WMS UI.
| Attribute | Unit | Description |
|---|---|---|
| Length | mm | Bottom length of the LPN |
| Width | mm | Width of the empty LPN |
| Height (empty) | mm | Height when the LPN is out of stock |
| Maximum height | mm | Max height the LPN can reach when loaded with stock |
| Weight (empty) | kg | Weight of the empty LPN |
| 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.
**UI path:** EasyS tool (not EasyWMS web UI).
### Division Types
Storage LPNs can have **internal partitions** (divisions). Used to optimize space and organize stock by item within a single physical LPN. Only supported in **automatic warehouses**.
| Attribute | Description |
|---|---|
| Name | Unique identifier for the division type |
| Description | Free text |
| Columns | Number of column partitions |
| Rows | Number of row partitions |
| Section | Section assignment within the division |
Rules:
- LPNs with divisions only allow entry and picking tasks. Shipping tasks are not valid.
- Contents must be picked out before the LPN can be considered empty.
- Division type can only be modified or removed from an **empty** LPN.
**UI path (web):** `Masters > Division LPN types`
### Client vs. Non-Client LPN
A critical distinction throughout EasyWMS:
- **Non-client LPN**: Holds stock available for general warehouse use (putaway, replenishment, picking source).
- **Client LPN**: Stock has been assigned to a shipping order. The LPN is "committed" to a specific outbound flow. Stacking/matching rules differ between client and non-client LPNs.
---
## Lifecycle & Statuses
LPN status tracks the full journey from pre-notification through shipment:
```
[ERP pre-notifies ASN]
↓
PENDING RECEIPT ← LPN in virtual ASN location, not yet physically received
↓
[Reception process]
↓
AVAILABLE ← LPN in warehouse, free to use for any process
↓
[Picking/consolidation starts]
↓
IN PREPARATION ← LPN being received, client LPN being prepared, or in consolidation
↓
[Picking complete]
↓
PREPARED ← Client LPN picked but not yet ready for loading
↓
[Moved to shipping stage]
↓
READY FOR SHIPPING ← Client LPN in shipping stage awaiting truck load
↓
[Truck loading]
↓
LOADED ← Included in a load but not yet departed
↓
[Truck departs]
↓
SHIPPED ← LPN has left the warehouse
```
**Note**: The "In preparation" status also covers LPNs currently on equipment during any movement task.
---
## Stacking and Matching
EasyWMS supports two forms of LPN grouping to reduce storage and transport costs:
| Relationship | Axis | Description |
|---|---|---|
| **Stacking** | Vertical | LPNs stacked on top of each other. A hierarchy is established: base LPN → stacked LPN(s). |
| **Matching** | Horizontal | LPNs aligned side by side. Uses a **slave/dummy LPN** as the logical container. |
### Stacking Rules
- LPNs must all be client type OR all non-client type.
- If client LPNs, they must all be for the same shipping order or for different orders on the same route stop.
- If a shipping order specifies a required LPN type, only client LPNs of that type can be stacked.
- Stacking relationships between LPN types must be configured in **EasyS** (how many LPNs of type X can stack on type Y).
- Supported location types for stack/match: Shelves (conventional/rack), Buffer, Stage, Dock, Lost & Found.
### End Location for Stacking
| LPN type | Location type | Behavior |
|---|---|---|
| Client LPN | Floor (buffer/stage/dock) | End location not requested; stays at base LPN location |
| Non-client LPN | Floor (buffer/stage/dock) | Controlled by `ASK_FINAL_STACK_LOCATION` parameter |
| Any | Shelves / virtual | Operator must always specify end location |
### Matching (Slave LPN)
Slave/dummy LPN configuration at equipment level:
- **With slave**: always uses a slave LPN
- **No slave**: never uses a slave LPN
- **Ask slave** (default): asks the operator each time
### Unstacking
- Cannot unstack base LPN from locations with FIFO configuration or rack type (when different LPN types are above).
- `UNSTACK_ON_STAGE` parameter: if `true`, forces unstacking to happen at a stage (both unstacked and remaining set land at the stage).
- **Undo all**: breaks all stacking/matching relationships in a set at once; all LPNs are placed loose in a buffer location.
---
## Lock Types
Locks restrict what operations can be performed on a LPN. Multiple locks can be applied simultaneously unless a lock is marked **Exclusive** (in which case it cannot coexist with other locks).
### Lock Properties
| Property | Description |
|---|---|
| Description | Text describing the physical reason (e.g., "broken wood", "stock misplaced") |
| Exclusive | If enabled, no other lock type can be active at the same time |
| Allow picking | If active, picking is allowed |
| Allow shipping | If active, shipping is allowed |
| Allow putaway | If active, putaway is allowed |
| Allow counting | If active, counting is allowed |
| Allow moving | If active, physical movement is allowed |
| Allow replenishment | If active, replenishment is allowed |
| Allow reserving | If active, stock reservation is allowed |
| Allow internal consumption | If active, LPN can be consumed in manufacturing |
### Cascade Effects When Locking
When a lock is applied that restricts a specific operation, EasyWMS automatically cascades the impact to in-progress tasks:
**Lock does not allow replenishment:**
- All replenishment source assignments for this LPN's stock are canceled.
- Picking tasks that used this stock as their assigned source are decremented (if they had other stock) or canceled (if this was the only stock).
- Released lines are re-released for new assignment.
**Lock does not allow picking:**
- All replenishment source assignments are canceled (stock unavailable for picking).
- Picking tasks using this LPN's stock are decremented or canceled.
- Affected lines are re-released.
**Lock does not allow moving:**
- If LPN is in a dynamic or pushback location, locks automatically propagate to LPNs behind it.
- Auto-unassignment of affected client LPNs.
- Affected tasks canceled; lines re-released.
**UI path (web):** `Masters > Lock types` → View "LPN lock types"
---
## Reception of Containers
### ASN Pre-notified Containers
LPNs pre-notified by the ERP via ASN message arrive in **Pending receipt** status and appear in the virtual **ASN location**. They are listed in the "ASN LPN" view until physically received.
**UI path (web):** `Warehouse > ASN LPN`
**UI path (RFT):** `Receipts > Notices`
### Supplier Multi-reference Container Receipt
Non-pre-notified stock arriving from a supplier in containers with multiple items. Two modes:
| Mode | Description |
|---|---|
| **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.
**ERP message sent at end of receipt:** `REF`
**Transactions:** `CON.RECEP` (per container), `STK.RECEP` (per stock line)
**UI path (RFT):** `Receipts > Supplier > Loose stock/multi-reference`
### Blind Container Receipt
Unplanned, non-pre-notified stock with no entry order. A receipt is auto-created at the start and closed at end. The receipt cannot be manually created or edited in the WMS UI.
**ERP message sent:** `REF`
**Transactions:** `CON.RECEP` (per container), `STK.RECEP` (per stock line)
**UI path (RFT):** `Receipts > Blind > Loose stock/multi-reference`
### 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.
---
## Operations
Available actions on LPNs (full list from web UI):
| Operation | Description | Equipment |
|---|---|---|
| LPN register | Register a LPN found at a location not known to the system. Specify code, location, type, height, weight, divisions. Some locations require position (rack) or depth (dynamic/compact/APS). | PC |
| Stock register in LPN | Add stock to a newly registered or unknown LPN. Requires item, owner, quantity, UoM. Treated as stock adjustment (reason required). | PC |
| Delete LPN | Remove LPN. If not empty, deletes all stock (stock adjustment, reason required). ASN LPN can only be deleted if not linked to a receipt order. | PC |
| Lock / Unlock | Apply or remove a lock type. Requires lock type selection; end date and comment optional. | PC |
| 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 |
| 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 |
| 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 |
| 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 |
| 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 |
| Unstack / Unmatch LPNs | Dissolve a stacking or matching relationship. | RFT |
| Label printing | Print/reprint LPN label (Code 128 or GS1-128). | PC / RFT + Labeller |
| Pre-printed label generation | Print blank LPN code labels for use in reception/creation processes. Follows UCC config and LPN sequence. | PC / RFT + Labeller |
| Client LPN label printing | Print client label for prepared client LPNs. Shows: LPN code, account, shipping order, current date. | PC / RFT + Labeller |
| Delivery note printing | Print packing slip for prepared or shipped client LPN. Shows: LPN code, shipping order, recipient name/address, carrier, stock detail (item, qty, UoM, weight, logistic attributes). | PC / RFT + Printer |
| View rejects | Consult reject reasons for LPNs at a station. | RFT |
---
## Labeling & Identification
EasyWMS interprets the following **GS1 Application Identifiers (AI)** on existing LPN labels:
| AI | Meaning |
|---|---|
| (00) | SSCC — Serial Shipping Container Code |
| (01) | GTIN grouping code / DUN14 |
| (02) | EAN |
| (10) | Lot number |
| (11) | Manufacturing date |
| (15) | Preferred consumption date |
| (17) | Expiry date |
| (21) | Serial number |
| (37) | Quantity |
**AI 02 special behavior:** When receiving items with an item-to-container-type conversion (complete quantity rule) labeled with GS1-128, using AI 02 forces the user to manually enter the received quantity rather than auto-completing the container.
### Changing the SSCC prefix
The SSCC prefix used for containers generated by the WMS (picking, and reception if the toolkit is enabled) is set **in EasyS**, not in SmartUI. Typically required when a customer mandates GS1-compliant codes.
Procedure:
1. In EasyS, **double-click** the warehouse name
2. Fill in the desired **prefix**
3. **Save**
Existing LPN codes are not rewritten — only containers generated after the change use the new prefix.
---
## Parameters
| Parameter | Effect |
|---|---|
| `ASK_FINAL_STACK_LOCATION` | If `true`, asks for the end stacking location when stacking non-client LPNs in floor locations (buffer/stage/dock). |
| `UNSTACK_ON_STAGE` | If `true`, requires moving the entire LPN set to a stage before unstacking. |
| `ALLOW_CREATE_RECEPTION` | If active, operators can create a receipt from the RFT if none found. |
| `CREATE_ALIAS_ON_RECEPTION` | If active, operators can declare a scanned code as an alias for an expected item at receipt time. |
| `RECEPTION_DEFAULT_CONTAINER_TYPE` | Default LPN type suggested during reception. If not set, operator must select each time. |
| `RECEPTION_DEFAULT_HEIGHT_TYPE` | Default height type suggested during reception. If not set, operator must select each time. |
| `RECEPTION_NUM_DAYS_PRODUCTION_DATE_MARGIN` | Days of margin added to today's date for future production date validation at receipt. |
| `CONFIRM_EXCLUSIVE_RESERVE_ASSIGNMENT` | If active, operator must manually select the shipping order/route when multiple exclusive reserves are compatible at receipt. |
| `CONTAINER_LABEL_DEFAULT_FORMAT` | Default label format (content, not size) for LPN labels printed by EasyWMS. |
| `CONTAINER_CHECK_CODE_REPEATED_FOR_LABELS` | If active, validates that LPN codes are not duplicated across stations, locations, and item aliases. |
| `LPN_CHECK_CODE_GS1LABEL` | If active, enforces GS1 standard (18 digits + check digit) for LPN codes. |
---
## Transactions (CON.*)
All container events generate transactions recorded in EasyWMS audit trail:
| Transaction | Process | ERP Message |
|---|---|---|
| `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.COS.001` | Container extracted to Outbound Conveyor (PS) | — |
| `CON.CREATE` | Container created manually, from view, for picking, or during count | — |
| `CON.DELETE` | Container deleted (from L&F or after count) | — |
| `CON.LOAD` | Container loaded during truck loading | — |
| `CON.LOCATE` | Container moved to storage location via putaway 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.RECEP` | Container received (supplier, return, or blind reception) | — |
| `CON.SEND.L&F` | Container sent to Lost & Found | — |
| `CON.SHIPPED` | Container shipped (shipping order closed) | — |
| `CON.SHIPPING` | Shipping task confirmed (container assigned to destination) | — |
| `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).
---
## ERP Integration
LPN-related ERP messages (all documented in [concepts/erp-interface.md](../concepts/erp-interface.md)):
| Message | Direction | Trigger |
|---|---|---|
| **ASN** | ERP → WMS | Pre-notification of LPNs arriving (creates ASN LPNs in Pending status) |
| **ROR** | ERP → WMS | Receipt order with exclusive stock reserve request |
| **REF** | WMS → ERP | Stock receipt confirmation (sent at end of supplier or blind container receipt) |
| **ASO** | WMS → ERP | Confirmation that an ASN or PIE container has been received |
| **ASK** | WMS → ERP | Deletion or rejection of a pre-notified ASN container |
---
## Interface Paths
### Web (PC)
| Path | Description |
|---|---|
| `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 |
| `Warehouse > ASN LPN` | View pre-notified (pending) LPNs |
### RFT (Radio Frequency Terminal)
| Path | Description |
|---|---|
| `Receipts > Supplier > Loose stock/multi-reference` | Supplier multi-reference container receipt |
| `Receipts > Blind > Loose stock/multi-reference` | Blind container receipt |
| `Receipts > Notices` | View ASN pre-notified LPNs |
| `Utilities > My LPNs` | View LPNs loaded on own equipment |
| `Utilities > Manual movement` | Manual LPN location change |
| `Utilities > Labels printing` | Print LPN labels |
| `Utilities > Stack/Unstack` | Stack and unstack operations |
| `Utilities > View rejects` | View reject reasons at current station |
| `Control > Manual equipments` | Match LPN from equipment management |
---
## Common Errors
**LPN not found at expected location:**
- Symptom: Physical LPN present but system shows different location.
- Cause: Manual move not recorded, or system error during task.
- Solution: Use "Location change" (PC) to correct the record. Treat as manual movement (no task required). If location unknown, send to Lost & Found.
**Cannot unstack base LPN:**
- Symptom: Unstack operation rejected.
- Cause: Location has FIFO configuration, or different LPN types are stacked above the base.
- Solution: Move the set to a stage first (enable `UNSTACK_ON_STAGE`), or use "Undo all" to break the entire hierarchy at once.
**Lock prevents task execution:**
- Symptom: Task canceled unexpectedly after LPN lock applied.
- Cause: Lock type disallows picking, replenishment, or moving. Cascade effect automatically cancels in-flight tasks.
- Solution: Check lock type configuration. Unlock the LPN if the reason is resolved, or process via alternative stock.
**Cannot modify LPN type or division:**
- Symptom: Type/division change rejected.
- 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:**
- Symptom: Location search returns no result for stacked set.
- Cause: Effective width (width + 2 × collapse) exceeds available location dimensions, or no valid strategy applies to the stack configuration.
- Solution: Check the "Putaway search location trace" report for the LPN (requires PC). Review excluded aisles and strategy details.
**ASN LPN cannot be deleted:**
- Symptom: Delete operation rejected for an ASN LPN.
- Cause: The ASN LPN is linked to a receipt order (ROR).
- Solution: Cancel or disassociate the receipt order first, or use the rejection flow (`CON.CNL.ASN` → `ASK` message to ERP).
---
## Related
- [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/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/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/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/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/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/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
- [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/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
wiki_old_13-05-2026/concepts/count.md
+346
View File
@@ -0,0 +1,346 @@
---
title: "Count / Inventory"
type: concept
sources:
- areas/counts/index.md
- areas/counts/counts_admin/count.md
- areas/counts/counts_admin/count_type.md
- areas/counts/counts_admin/count_create.md
- areas/counts/counts_admin/count_release.md
- areas/counts/counts_admin/count_close.md
- areas/counts/counts_admin/count_cancel.md
- areas/counts/counts_admin/count_orders_monitorize.md
- areas/counts/counts_admin/count_assign_pk.md
- areas/counts/counts_admin/location_count_type.md
- areas/counts/counts_physical/count_physical.md
- areas/counts/counts_physical/count_location.md
- areas/counts/counts_physical/count_lpn.md
- areas/counts/counts_physical/count_item.md
- areas/counts/counts_physical/Partitions_Count.md
- areas/counts/counts_physical/informed_count.md
- areas/counts/counts_physical/count_cutting_stock.md
- areas/counts/counts_workstation/index.md
- areas/counts/counts_workstation/count_pk_location.md
- areas/counts/counts_workstation/count_pk_lpn.md
- areas/counts/counts_workstation/count_pk_item.md
- areas/counts/cycle_count/index.md
- areas/counts/cycle_count/cycle_count_schedule.md
- areas/counts/cycle_count/cycle_count_generation.md
- areas/counts/counts_erp/index.md
- areas/counts/views/view_count.md
- areas/counts/views/view_count_line.md
- areas/counts/views/view_cycle_count_schedule.md
- sources/archives/14_Processus_inventaire.md
- sources/archives/21_Validation_ajustements_stock.md
related:
- concepts/location.md
- concepts/stock.md
- concepts/container.md
- concepts/product-item.md
- concepts/stock-adjustment.md
- concepts/task.md
last_compiled: "2026-04-17"
---
# Count / Inventory
## Overview
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.
- **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.
Counts can be performed in manual warehouses (operators walk to locations) and automatic warehouses (containers are extracted to a picking conveyor / workstation).
---
## Types of Count
### Count Types (per line)
| Count type | Scope | Use when |
|---|---|---|
| **Item count** | All stock of a specific item across the warehouse | Targeted SKU audit; can filter by logistic attribute |
| **Container count (LPN)** | One specific container and all its stock | Spot check of a known LPN |
| **Location count** | All stock and containers in a range of locations | Large-scale area inventory |
A single count order can mix lines of different types.
### Creation Methods
| 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 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 |
---
## Lifecycle
### Guided Count Order Lifecycle
```
Disabled (Inactive)
│
▼ [Release]
Releasing ← tasks being generated
│
▼ (tasks ready)
In Process ← operators executing tasks
│ │
│ [all tasks done] │ [Cancel]
▼ ▼
Closed Cancelling → Canceled
(or Force Close)
```
**Status transitions:**
| Status | Description |
|---|---|
| **Disabled** | Order created, not yet released |
| **Releasing** | Release triggered; tasks being generated |
| **In Process** | All tasks generated; operators executing |
| **Closed** | All tasks complete (or Force Close used) |
| **Canceled** | Pending tasks canceled; completed counts kept |
Closing can be **automatic** (`AUTOCLOSE_COUNT_ORDERS` parameter) or manual. Orders with conflicting lines (item with no stock, location that doesn't allow inventory) can only be closed with **Force Close**.
### Transactions
| Transaction | Trigger |
|---|---|
| `COU.CST` | Count order released |
| `TSK.COU` | Count task completed |
| `STK.ADJ` | Stock adjusted as result of count |
| `CON.CREATE` | Container created during count |
| `CON.DELETE` | Container removed during count |
| `COU.END.` | Count order closed (ERP-originated via COR) |
| `COU.CLS.` | Count order closed (WMS-originated) |
| `COU.CNL` | Count order canceled |
| `TSK.CANCEL` | Count task canceled |
| `ADJ.STK` | Physical count adjustment |
---
## Guided Count — Execution
### Task Generation at Release
When a count order is released, EasyWMS generates count tasks based on line type and warehouse type:
- **Manual warehouse, location line** → location count tasks (one per location in range)
- **Manual warehouse, container line** → container count tasks (regardless of aisle type)
- **Manual warehouse, item line** → item count tasks (one per location where item has stock)
- **Automatic warehouse, any line** → container count tasks (containers extracted to PK)
- **Picking location with partitions + dedicated PDL** → item count tasks (one per assigned partition)
Locations configured as "does not allow inventory" in EasyS are skipped. Locks on locations, containers, or stock that prevent counting are also respected.
### 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.
- **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.
> 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
When an item is counted on an attribute unique per piece (a serial number) :
1. The WMS asks for a serial number → enter the first one (e.g. `A`).
2. The screen **loops on itself** once per piece of the item → enter a different serial for each piece (e.g. `B`, `C`…).
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.
### Count in Automatic Warehouse (Workstation)
For automatic warehouses, a **picking conveyor (PK) must be assigned** to the count before release. EasyWMS then extracts all containers to be counted to that PK. Operators count at the PC workstation.
Supported use cases at workstation:
- Counting containers from a location range
- Counting specific containers
- Counting stock of a specific item
- Counting owner stock (effectively item count for all items of one owner)
If the PK is equipped with a laser (HPKS pick-term tray), it illuminates the division/location being counted. Cutting stock counts are **not** supported in automatic warehouses.
### Partition Counts
For picking locations with labeled partitions assigned per item (dedicated picking locations), a special partition count mode is available from the RFT. The operator can:
- Count an entire location with partitions (all partitions sequentially)
- Count a single partition
- Count in blind or informed mode
- Reassign partitions to items during the count
Parameters:
- `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
---
## 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.
**Process:** Operator navigates to `Counts > Physical Count` on the RFT, scans a location or container, and enters all stock data from scratch. Any differences are applied immediately.
**What can be done:**
- Create new stock lines
- Modify existing stock lines (quantity, UoM, status, logistic attributes)
- Delete stock lines
- Create or delete containers
**Restrictions:** Only locations that allow inventory (per EasyS config) can be physically counted.
**Communications:** Any adjustment generates STV (stock variation) and STC (status change) messages to ERP.
---
## Cycle Count (Rolling Inventory)
Cycle counting avoids full warehouse shutdowns by spreading counting tasks across many days.
### Architecture
```
Count Schedule (config: scope + timing)
│
▼ generates
Count Iteration (active period of N days)
│
▼ daily job generates
Count Orders + Tasks (distributed evenly across iteration days)
```
### Schedule Configuration
A **Count Schedule** defines:
- **Location filtering**: area, aisle, location range
- **Item filtering**: owner, ABC class, family, type, count profile
- **Count mode**: blind or informed (location-type schedules only)
- **Iteration duration**: how many days each iteration lasts
- **Iteration period**: how many days between iterations (≥ duration)
- **Next iteration start date**: allows staggering multiple schedules
- **Days of week**: which days tasks are generated
> If item filtering is set → item count tasks generated. If no item filter → location count tasks generated.
### Generation Logic
The job `CycleCount_GenerateIterationsForEnabledSchedulesJob_PR` runs daily and:
1. Calculates total tasks still needed for the iteration
2. Divides by remaining days to distribute evenly
3. Sorts locations by aisle/side/X/Y coordinates
4. Creates a count order with the day's lines and immediately releases it
Count orders generated by cycle count **cannot be re-released after cancellation**.
### Iteration States
- **On progress** — active iteration running
- **Finished** — iteration end date passed (transitions next day)
- **Canceled** — manually terminated early
Schedules can be **enabled/disabled**. A schedule with an active iteration cannot be disabled.
---
## ERP Integration
### ERP-Requested Count (COR → COF)
The ERP can request a warehouse count via the **COR** (Count Order Request) message. EasyWMS creates a count order in Disabled status. After release and execution, the **COF** (Count Order Finished) message is sent at close, reporting all stock per location counted.
> If double validation (pending adjustments) is active, the COF is delayed until all pending adjustments are validated or canceled.
### Stock Contrast (SCR → WSC)
Separate from counts, the ERP can request a full stock snapshot without generating counting tasks. This uses the **SCR** (Stock Contrast Request) message; EasyWMS responds immediately with **WSC** (Warehouse Stock Contrast), listing all current stock matching the filters.
Available as:
- Punctual request from SmartUI (immediate response)
- Scheduled automatic request (configurable periodicity ≥ 1 hour; job `StockCountRequest_GetScheduledCount_Job` at 10-minute polling)
**Transactions:** `SCR.REQ.` + `SCR.DET.`
### Stock Variation Notification (STV)
For counts **not** created by the ERP (manual WMS counts, physical counts, cycle counts), stock adjustments during counting are reported line by line via **STV** messages rather than COF.
---
## Business Rules
- Locations with the "does not allow inventory" flag (EasyS config) are never counted.
- Locks (at location, container, or stock level) that prevent counting block task generation for the locked element.
- In automatic warehouses, **no moving containers** should exist when a count order is released (containers in transit won't receive tasks).
- Item count lines where the item has no stock in the warehouse generate **no tasks** and appear as conflicting lines (shown with a conflict icon).
- Canceling a count cancels pending tasks; already-counted stock **is not reverted**.
- Double validation (per item's count profile) can hold count adjustments in **Pending** status until a manager validates or cancels them.
---
## Configuration
| Parameter | Description |
|---|---|
| `AUTOCLOSE_COUNT_ORDERS` | Auto-close count orders when all tasks complete |
| `MAX_NUM_LABELS_TO_READ` | Enable multi-label GS1-128 reading at start of count flow |
| `ALLOW_ZONE_SELECTION_FOR_TASKS` | Show zone filter button on RFT (aisle/sub-warehouse/work zone) |
| `UNLOAD_CREATE_PRODUCT_LOCATION` | Auto-create PDL assignment for counted item in partitioned location |
| `REPLENISH_LEVEL_PERCENT_PRODUCT_LOCATION` | Replenishment level % used when auto-creating PDL from count |
| `ALLOW_DYNAMIC_UNASSIGNED_PARTITION` | Allow dynamic unassignment of empty partitions during count |
---
## Interface
| Path | Equipment |
|---|---|
| `Counts > Counts` (order list) | PC |
| `Counts > Count lines` | PC |
| `Counts > Cycle count iterations` | PC |
| `Warehouse > Stock` → "Punctual stock contrast request" | PC |
| `Warehouse > Stock` → "Create/Edit stock contrast schedule" | PC |
| `Configuration > Parameters` → `AUTOCLOSE_COUNT_ORDERS` | PC |
| `Configuration > Jobs` → `Delete_StockStatusJob_PR` | PC |
| RFT: `Counts > Physical Count` | RFT |
| RFT: `Tasks > Automatic tasks` or `Count tasks` | RFT |
| RFT: `Counts > Select count` (manual count selection) | RFT |
---
## Common Errors
| Symptom | Cause | Solution |
|---|---|---|
| Count order stuck in "Releasing" | Automatic warehouse: moving containers exist at release time | Wait for all containers to reach a location, then release |
| Count line shows conflict icon (no stock) | Item count line requested for item with zero stock in warehouse | Use Force Close to finalize order; review item master |
| 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 |
---
## Related
- [[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
- [[location]] — Location "allows inventory" flag governs whether counting tasks are generated
- [[container]] — Container count type counts an LPN and all its stock
- [[product-item]] — Item count type; count profile on item controls double validation
- [[task]] — Count tasks (TSK.COU) follow the standard task lifecycle
wiki_old_13-05-2026/concepts/crossdocking.md
+249
View File
@@ -0,0 +1,249 @@
---
title: "Crossdocking"
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/putaway/putaway_admin/index.md (Group by SO/Route strategy type)
- sources/archives/06_Gestion_cross_docking.md
related:
- concepts/reception.md
- concepts/putaway.md
- concepts/shipping.md
- concepts/container.md
- concepts/stock.md
last_compiled: "2026-04-17"
---
# Crossdocking
## Overview
Crossdocking is a warehouse flow optimization technique where received stock bypasses or minimizes time in bulk storage by being moved directly or nearly directly to the shipping area. Instead of the standard flow (receive → putaway → pick → ship), crossdocking shortens or eliminates the storage step.
EasyWMS supports two distinct crossdocking types in manual warehouses:
| Type | Description | Stock assignment timing |
|---|---|---|
| **Opportunity crossdocking** | Stock goes directly to a shipping dock/stage/staging area after reception | Assigned immediately upon receipt |
| **Crossdocking to warehouse** | Stock goes to dedicated crossdocking locations near shipping area | Assigned when the shipping order is later released |
Both types apply to containers, stacked containers, carts, and loose stock received at equipment. Automatic warehouses follow the same logic for location search but the TMS executes the physical movement.
## Opportunity Crossdocking
### Concept
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
2. **When preparing to putaway from a reception stage** — stock received in a staging area is evaluated for direct transfer
### Conditions and Eligibility
For opportunity crossdocking to apply to a shipping order line:
- The line orders **only per container** OR **only per item** (not mixed requirements)
- The line is **not marked as critical** or **required to ship**
- If the shipping order is **sequenced** (by line or by route with stops): crossdocking only applies if the container is for the line or stop currently being shipped or a prior one
For stock reserved in a reserve:
- If the stock has an active exclusive reserve → it is assigned to the order with that reserve (not freely routed)
For **cutting stock items** in non-consolidating conversions:
- Crossdocking is supported, but the decision process applies stock restrictions specific to cutting items (must handle total-quantity stretches)
### Process Flow
1. Operator receives stock/container at equipment
2. Operator initiates putaway
3. EasyWMS evaluates: is there a shipping order that needs this stock?
4. If **yes** → task destination is set to the dock/stage/buffer of the shipping order → crossdocking task generated
5. If **no** → standard putaway process continues (channel filling strategies, then location strategies)
6. Operator follows RFT instructions to the assigned destination (same UX as standard putaway)
### Output
- A putaway task with destination = dock/stage/buffer of the matched shipping order
- Stock is assigned to the shipping order at the time of crossdocking
- No storage location is used
## Crossdocking to Warehouse
### 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.
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.
### Conditions and Eligibility (Warehouse)
For crossdocking to warehouse to execute:
1. **Item must allow crossdocking**: item attribute "Allow crossdocking" must be enabled
2. **Crossdocking locations must exist**: locations must be configured with storage logic "Allows Crossdocking" AND must be reachable from the equipment by route, height, and work zone
3. **Crossdocking putaway strategies must exist**: at least one enabled putaway strategy flagged as "Is crossdocking"
4. **Valid shipping orders must be candidates**: a shipping order/line is a candidate for crossdocking if:
- Order and lines are not closed, canceled, or in creation state
- If the line orders a specific container: all items in that container have "Allow crossdocking" enabled
- The line has pending quantity to assign (shipped + prepared + assigned < ordered quantity)
- The strategy filters are satisfied: order status, priority, minimum days until release date or planned loading date (if configured)
5. **Insufficient stock in existing crossdocking locations**: if there is already sufficient stock in crossdocking locations to cover the pending need, no additional crossdocking is performed
### Process Flow (Warehouse)
1. Operator is about to putaway received container/stock
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
c. If insufficient stock and candidates exist → runs crossdocking putaway strategy
d. Strategy finds a valid crossdocking location
4. If a crossdocking location is found:
- Task is generated with process type = **Crossdocking**, task type = **Putaway**
- Task destination = crossdocking location
5. If no crossdocking location is found → search the rest of the warehouse using standard putaway strategies
6. If only part of the stock qualifies for crossdocking → remainder is located via standard putaway
7. Operator follows RFT instructions (same UX as standard putaway)
In automated warehouses: same logic applies; TMS executes the physical movement.
### Crossdocking Locations
A crossdocking location is configured with storage logic property **"Allows Crossdocking"** = true. These locations are typically positioned near shipping docks and staging areas to minimize the travel distance from storage to loading.
When a shipping order is released, the stock assignment engine consults crossdocking locations **preferentially** before other storage locations. This prioritization ensures that pre-positioned crossdocking stock is consumed first.
### Crossdocking Putaway Strategies
Crossdocking to warehouse requires at least one putaway strategy enabled with the **"Is crossdocking"** flag. These strategies define:
- Source station criteria (where the crossdocking flow originates)
- Destination rules (which crossdocking locations are valid)
- Filters on shipping order properties (status, priority, days until release/load date)
- Sorting preferences for selecting the optimal crossdocking location
The strategy can filter by:
- Shipping order priority
- Shipping order status
- Days until shipping order release
- Days until shipping order planned loading date
### Stock Coverage Check
EasyWMS only routes stock to crossdocking locations if the pending demand is not yet covered. The check compares:
- Pending quantity for shipping order lines (ordered − shipped − prepared − assigned)
- Existing stock at crossdocking locations for the same item
If crossdocking locations already hold enough stock for all pending orders → no crossdocking task is generated → standard putaway proceeds.
## Crossdocking Decision Tree
```
Putaway triggered (after reception)
│
▼
Opportunity crossdocking eligible?
(SO needs stock, not critical, not sequenced out of order)
│
┌──────┴──────┐
YES NO
│ │
▼ ▼
Move to dock Crossdocking to warehouse possible?
/stage/buffer (item allows XD, XD locations exist, XD strategy enabled,
Task: XD SO candidates exist, insufficient stock in XD locations)
│
┌──────┴──────┐
YES NO
│ │
▼ ▼
Move to XD Standard putaway
location (channel filling → location strategies)
Task: XD
Putaway
```
## Comparison: Opportunity vs. To-Warehouse
| Dimension | Opportunity Crossdocking | Crossdocking to Warehouse |
|---|---|---|
| Stock assignment | Immediate (at reception) | At shipping order release |
| Destination | Dock / Stage / Buffer | Crossdocking location (near dock) |
| Shipping order state required | In-preparation or partially released | Any non-closed/canceled state |
| Requires XD strategy | No | Yes ("Is crossdocking" flag) |
| Requires XD locations | No | Yes ("Allows Crossdocking" logic) |
| Requires item "Allow XD" | No | Yes |
| Operator flow change | None (same UX as putaway) | None (same UX as putaway) |
## Configuration Requirements
### For Opportunity Crossdocking
No special location or strategy configuration required. The system automatically evaluates all received stock against pending shipping orders during the putaway initiation phase.
### For Crossdocking to Warehouse
1. **Items**: set "Allow crossdocking" = true on each eligible item
2. **Locations**: configure storage logic "Allows Crossdocking" = true on designated crossdocking locations (near docks/stages)
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
Additional setup steps consolidated from Mecalux France practice (in addition to the items above) :
**EasyS :**
1. Create a dedicated rack for the crossdocking locations.
2. Check **Is Crossdocking location = true** on the rack.
3. Attach the locations to a **Warehouse zone of type `Cross docking`**.
4. Configure the workingZones to include the crossdocking and/or unload processes.
**SmartUI :**
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.
**Rules tab** : set `Zone` to the crossdocking zone created in EasyS.
### 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.
- **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.
## Common Errors
**Opportunity crossdocking not triggering despite matching order:** The shipping order line is marked as critical or required-to-ship, or the line type mixes container and item requirements (both are required). Remove the critical/required flags or create separate lines.
**Crossdocking to warehouse not executing:** Item does not have "Allow crossdocking" enabled, or no crossdocking putaway strategy exists/is enabled, or crossdocking locations exist but are not reachable from the reception equipment by route. Check all three configuration elements.
**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.
**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.
**Cutting stock crossdocking creates wrong stretch quantities:** Cutting stock requires total-quantity handling; partial stretches cannot be crossdocked. Ensure the full stretch length matches the shipping order's demand exactly, or split orders to match available stretches.
## Interface Paths
| Interface | Path |
|---|---|
| Web — crossdocking putaway strategies | "Configuration" → "Putaway strategies" (filter by "Is crossdocking") |
| Web — item "Allow crossdocking" | "Inventory" → "Items" → item → settings |
| 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 (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
- [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
- [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
- [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
wiki_old_13-05-2026/concepts/cutting-stock.md
+340
View File
@@ -0,0 +1,340 @@
---
title: "Cutting Stock"
type: concept
sources:
- areas/inventory_management/items/cutting_item.md
- areas/inventory_management/items/cutting_profile.md
- areas/inventory_management/items/cutting_stock_label.md
- areas/inventory_management/items/cutting_stock_assignation.md
- areas/shipping/shipping_picking_manual/cutting_station.md
- areas/shipping/shipping_picking_manual/cutting_stock_integrated.md
- areas/shipping/shipping_picking_manual/cutting_stock_delegate.md
- areas/shipping/shipping_picking_manual/cutting_excess.md
- areas/receptions/reception_dock/blind_cutting_stock.md
- areas/receptions/reception_dock/supplier_cutting_stock.md
- areas/counts/counts_physical/count_cutting_stock.md
related:
- concepts/product-item.md
- concepts/reception.md
- concepts/picking.md
- concepts/shipping.md
- concepts/stock-adjustment.md
- concepts/count.md
- concepts/quality-control.md
- concepts/manual-movements.md
- concepts/stations.md
- concepts/labels.md
- concepts/parameters.md
last_compiled: "2026-04-10"
---
# Cutting Stock
## Overview
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.
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.
## Core Concepts
### The Non-Consolidation Rule
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.
- 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.
### Base UoM Rule
**The base UoM of a cutting item must be the smallest unit in which the item is allowed to be cut (no decimals supported).** For example: if the minimum cut is 1 meter, the base UoM is meters with integer precision.
### Non-Consolidating Conversions
A UoM conversion (presentation) on a cutting item can be marked as **"Do not consolidate"** independently. When active:
- Multiple stock lines of the same conversion coexist without merging
- The item follows all cutting-stock rules for that conversion
- All conversions except the base must be of type *presentation* with the **"Allow splitting"** flag active (to enable partial-length cutting)
## Cutting Profile
The cutting profile is what transforms a regular item into a cutting item. It defines behavior for the entire lifecycle.
**Cutting profile attributes:**
| Field | Description |
|-------|-------------|
| Code | Unique profile identifier |
| Description | Free text |
| Default | If flagged, automatically assigned to new items |
| Labeling source stock | Generate label for the roll from which stock was cut |
| Labeling cut stock | Generate label for the cut portion |
| Cutting in station | False = cut on the shelf; True = cut at a designated cutting station |
| Mode of picking process | When "Cutting in station": `Integrated` (same operator does supply + cut + pick) or `Delegated` (separate operators for each step) |
| Associated cutting stations | Which cutting station(s) this profile can be processed at |
**Multiple cutting profiles can share a cutting station.** However, sharing stages between stations is only advised when both stations cut the same cutting profiles.
**ERP creation:** Cutting profiles can be created (not modified or deleted) from ERP via the ITM message.
**Interface:** View "Cutting profiles" in menu "Masters > Item details".
## Configuration Steps (First-Time Setup)
1. Create a **cutting profile** (define labeling, station/shelf mode, associated stations)
2. Assign cutting profile to the **item** (makes it a cutting item)
3. Configure item as **non-consolidating conversion** (flag "Do not consolidate" on relevant UoM conversions)
4. Set **stock assignment strategies** (minimum and maximum shipping quantity fields on item master)
5. Configure **shipping profile** for the item (excess percentage + enter quantity mode = "Manually")
6. If cutting in station: configure **cutting stations** in EasyS (stages, routes, station type 61)
## Stock Assignment Strategies
Two parameters on the item master control how stock is assigned to shipping order lines. Only applies to non-consolidating conversions.
### Continuous Stretches (Maximum Quantity set)
Set **"Maximum shipping quantity per line"** = length of the longest roll presentation (in base UoM).
- Requested length ≤ maximum → assigned in one single stretch (guaranteed)
- Requested length > maximum → assigned as X complete rolls (= maximum) + one continuous stretch for remainder
*Example: Max = 100m, required = 125m → assign 1 full roll + 25m stretch*
### Segmented Stretches (Maximum Quantity empty)
No maximum set. System tries to supply with as few stretches as possible, but **no guarantee of a single continuous stretch**.
*Example: Stock = 30m+30m+30m, required = 70m → assign 30m + 30m + 10m cut from third roll*
### Minimum Cutting Quantity
The **"Minimum shipping quantity"** field sets the minimum length to cut. Any requirement below this minimum is automatically rounded up.
*Example: Min = 10m, required = 5m → assign 10m stretch*
**Exception 1 (with maximum):** If maximum is set and surplus < minimum, also rounds up.
*Max = 100m, Min = 10m, required = 105m → assign 100m roll + 10m stretch*
**Exception 2 (no minimum stock available):** If minimum is set but no stock line has length ≥ minimum → assign the group of stretches closest to minimum, **without cutting**.
*Min = 10m, required = 9m, stock = 3m+4m+8m → assign 8m+3m=11m, no cut*
For exception 2: the shipping profile's "Excess Pick Percentage" must be empty.
**Note:** For cutting in station, stock in cutting station stages is prioritized over warehouse stock.
## Cutting Stations (Type 61)
Cutting stations are where cutting-in-station processes are executed. A cutting station consists of:
- **Receiving stage:** Holds rolls assigned for cutting
- **Shipping stage:** Holds cut portions ready for shipping or return to warehouse
**Configuration options:**
| Configuration | Use Case |
|--------------|----------|
| Single stage (receive + ship) | Item cut multiple times per day, rarely returned to warehouse |
| Two dedicated stages per station | Item cut a few times per month, returned to warehouse after each cut |
| Two shared stages across multiple stations | Multiple nearby stations cut the same profiles |
Cutting station can be locked via "Stations" view to prevent new stock assignments.
**Required EasyS configuration:**
- Station type 61 (Cutting)
- Single buffer location per station, storage mode = stock, allow picking
- 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.
## Reception of Cutting Stock
### Blind Reception (Loose Stock)
Process for receiving multiple rolls of different or identical lengths in non-consolidating conversions.
**Use cases:**
- **Variable-length rolls:** Receive one roll at a time, each with its own length record. Repeat as needed.
- **Multiple identical rolls (Multi):** "Multi" action creates multiple records of the same length simultaneously.
- **Edit or delete rolls:** View and modify all lines created for an item + conversion in the receipt; edit quantity or delete lines.
- **Receipt and putaway:** When receiving loose cutting stock in equipment, can immediately putaway. Must confirm exact length of each roll for unloading confirmation.
**Transactions:** STK.RECEP (per stock line), CON.RECEP (per container if applicable)
**ERP Communication:** REF message sent at receipt close
### Supplier Receipt in Stage
Receive cutting stock rolls at a receiving stage. Stocks in non-consolidating conversions are recorded individually (not summed). Supports individual roll reading and "Multi" for same-length batches.
**Interface:** RF menu "Receipts > Supplier" → "Loose stock/Multi-reference"
### Receipt-and-Putaway Specifics
Due to non-consolidation, when selecting a stretch to unload and confirming unloading, the **exact length of each roll must be confirmed**. This is stricter than regular container unloading.
## Picking and Cutting Processes
### Shelf-Based Cutting (cutting_in_station = False)
The operator cuts directly at the shelf location. The picking process is the same as standard picking with the difference that:
- The exact length to cut is confirmed manually
- "Enter quantity mode" must be set to "Manually" in the item's shipping profile
- System never allows picking less than ordered; overpicking is controlled by "Picking excess percentage" in shipping profile (0 = no excess; blank/100 = excess allowed)
### Integrated Cutting in Station
**Same operator** does supply, cut, and pick as a single workflow within the normal picking process.
**Three-phase process:**
1. **Supply:** If stock is not at the cutting station's stages → system guides operator to pick the roll from warehouse and bring it to the receiving stage. Operator can also pre-supply manually via Manual Movement.
2. **Cutting:** At the cutting station, operator cuts the required length. System guides confirmation.
3. **Labeling:** If cutting profile has labeling flags → labels are printed for cut stock and/or source roll.
Station (integrated) items can be included in shipping orders, order groups, and waves.
**Monitoring:** Supervisors can monitor line and order status from web interface.
**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.
### Delegated Cutting in Station
**Separate operators** handle supply, cutting, and shipping as independent process steps.
**Multi-phase workflow:**
1. **Supply:** Operator brings assigned rolls from warehouse to cutting station receiving stage (via picking order RFT or automatic tasks). Manual supply also supported via Manual Movement.
2. **Cutting:** Dedicated cutting operator executes cut at station, adds labels, identifies which stretch to cut first (can view cutting tasks accumulated per item with priority list).
3. **Shipping/Palletization:** Operator takes cut stock to destination (dock/stage/consolidation). If the roll itself is a shipping container, it can be palletized.
**Not supported in groupings or waves** (unlike integrated mode).
**Return to warehouse:** Unassigned stock can be returned to warehouse at any time.
## Cutting Excess and Shipping Profile
Two critical shipping profile settings for cutting items:
### Overpicking Configuration
| Setting | Shipping Profile Config | Effect |
|---------|------------------------|--------|
| Allow overpicking | "Picking excess %" = null or 100 | Over-picked stock not flagged as excess at shipping |
| Disallow overpicking | "Picking excess %" = 0 | Exact quantity required; any excess raises error |
Because cutting requires tools and cannot be performed everywhere, it is **not possible to undo preparation or remove excess** except by cancellation.
### Enter Quantity Mode
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
This is mandatory for correct cutting stock behavior.
## Counting Cutting Stock
Counting cutting stock (in non-consolidating conversions) differs from standard counting. Only supported in **manual warehouses**.
"Stretch" = any non-consolidating cut-off stock record in UoM.
**Three counting use cases:**
1. **Count multiple stretches continuously:** After entering item + UoM, operator reads stretches continuously without re-entering item code. "Done" saves all records. "Stretches" action shows running count list.
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.
**Informed count mode:** For locations where exact roll lengths are unknown. Verifies bulk presence only. Allows comparison and adjustment by operator.
**Transactions:** ADJ.STK (stock adjustment), CON.CREATE, CON.DELETE
**ERP:** STV (stock variation), STC (status change). If count created from ERP COR → response via COF.
## Quality Control Lock
See [[quality-control]] for full details. Cutting stock has specific lock behaviors:
- **Partial lock:** Lock a specific stretch (individual stock record)
- **Total lock:** Lock entire coil/roll
- When locked stock is split by a cut: lock propagates to cut portion
- Lock from RF terminal or ERP
- ERP messages: STR (status lock/unlock), STC (status change notification)
## Manual Movements
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)
- If move requires cutting to reduce length, that is not permitted via manual movement — must go through the picking/cutting process
## Crossdocking Interaction
Cutting outside storage locations is not permitted. However, **opportunity crossdocking is possible** for cutting items in non-consolidated conversions, depending on the cutting item configuration. The crossdocking process must be explicitly enabled and configured per item.
## Stock Adjustment for Cutting Stock
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
- Transactions: STK.ADJ
## Parameters
| Parameter | Default | Description |
|-----------|---------|-------------|
| CUTTING_PRINTER | (blank) | Default printer for cutting stock labels during picking. See [[parameters]]. |
## Interface
| Process | Interface | Equipment |
|---------|-----------|-----------|
| Configure cutting profiles | Masters > Item details > "Cutting profiles" | PC |
| Configure cutting items | Masters > Items | PC |
| Configure conversions (non-consolidating) | Masters > Conversions | PC |
| Configure cutting assignments | Masters > Items | PC |
| Configure shipping profile | Masters > Item details > Shipping profile | PC |
| Blind cutting stock receipt | Receipts > Blind > Loose stock/Multi-reference | RFT |
| Supplier cutting stock receipt | Receipts > Supplier > Loose stock/Multi-reference | RFT |
| Cutting stock picking (shelf) | Picking orders | RFT |
| Integrated cutting in station | Picking orders (same as standard picking) | RFT / Label printer |
| Delegated cutting supply | Shipping orders > Picking order OR Tasks > Automatic mode | RFT |
| Delegated cutting execution | Cutting menu > Cutting | RFT |
| Cutting stock count | Counts > Physical count / Guided count | RFT |
| Print cutting label from stock view | Warehouse > Stock > "Print cutting label" action | PC |
| Print label from location adjustment | Utilities > Location adjustment | RFT |
| Monitor station orders | Shipping orders view | PC |
## Common Errors
| Error | Cause | Solution |
|-------|-------|----------|
| Cannot change quantity on cutting line | Task is In Process or Finished | Cancel the line instead; excess cannot be undone |
| "Minimum cutting quantity" not respected | Shipping profile "Excess Pick %" has a value | Clear the Excess Pick % field when using minimum cutting quantity |
| Stock not assigned as single stretch | Maximum quantity not set in item master | Set "Maximum shipping quantity per line" to longest roll length |
| Delegated cutting line not included in wave | Delegated items not supported in waves/groups | Use only integrated mode for order groups and waves |
| Labels not printing during cutting | Cutting profile lacks labeling flags | Check "Labeling cut stock" and "Labeling source stock" flags in cutting profile |
| Count treats cutting stock like regular stock | Item UoM not flagged "Do not consolidate" | Ensure non-consolidating flag is active on relevant UoM conversion |
## Related
- [[product-item]] — Cutting profile is configured on the item master; base UoM rules apply
- [[reception]] — Cutting stock has specialized receipt processes (blind, supplier)
- [[picking]] — Integrated and delegated cutting processes are extensions of picking
- [[shipping]] — Shipping profile configuration is mandatory for correct excess handling
- [[stock-adjustment]] — Label printing from location adjustment; STK.ADJ transactions
- [[count]] — Counting stretches has unique UI and process rules
- [[quality-control]] — Cutting stock locks (partial/total); STC/STR messages
- [[manual-movements]] — Moving whole stretches; indivisibility enforced
- [[stations]] — Cutting station (type 61) configuration and associated stages
- [[labels]] — Cutting stock label format (A6), print triggers, printer priority
- [[parameters]] — CUTTING_PRINTER parameter
wiki_old_13-05-2026/concepts/defragmentation.md
+201
View File
@@ -0,0 +1,201 @@
---
title: "Defragmentation"
type: concept
sources:
- areas/defragmentation/index.md
- areas/defragmentation/defrag_admin/index.md
- areas/defragmentation/defrag_admin/defrag_rotation.md
- areas/defragmentation/defrag_admin/defrag_shipping.md
related:
- concepts/location.md
- concepts/container.md
- concepts/stock.md
- concepts/task.md
- concepts/order-outbound.md
- concepts/putaway.md
last_compiled: "2026-04-10"
---
# Defragmentation
## Overview
**Defragmentation** in EasyWMS reorganizes containers in automatic warehouses to optimize the placement of stock, either based on ABC rotation classification or based on upcoming shipping. It is an **automatic warehouse-only** feature that generates movement tasks to be executed during **periods of inactivity**, minimizing interference with active operations.
Two types of defragmentation exist:
| Type | Purpose | Criteria |
|---|---|---|
| **Rotation defragmentation** | Move containers to their optimal ABC storage zone | Item's ABC classification vs. current storage zone |
| **Shipping defragmentation** | Move containers close to exit in preparation for dispatch | Assignment to a shipping order or route |
Both types are configured via **strategies** and can be run manually or automatically via **planners**.
---
## Rotation Optimization Strategies
Rotation strategies reposition containers to storage zones that match their ABC classification. For example, moving all A-class containers currently stored in zone B to zone A.
### Strategy Criteria (Source Selection)
A rotation strategy defines which containers are candidates to be moved:
| Criterion | Description |
|---|---|
| ABC classification | Required. Containers with this ABC class are candidates |
| Storage zone | Required. The source zone from which to extract candidates |
| Number of containers | Cap on total containers processed by the strategy |
| Number of references in container | Mono-reference only, multi-reference only, or both; for mono-reference: complete/peak/both |
| Container type | Optional filter; if not set, all container types are valid |
| Location date | Only containers placed after a specific date |
| Assigned containers | Whether containers assigned to picking or shipping are candidates |
| Source aisle | Specific automatic aisle to draw from (optional) |
| Location range | X/Y coordinate range within the source aisle |
| Location sorting | Order in which source locations are evaluated (free positions ASC/DESC, X/Y ASC/DESC) |
### Strategy Rules (Destination Selection)
For each rotation strategy, destination rules specify where to move candidate containers:
| Rule | Description |
|---|---|
| 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) |
| Priority | Task priority for defragmentation tasks of this ABC+zone combination |
**Location search uses putaway strategies** in configured sequence order.
### Execution
- **Manual:** Select strategy in `Defragmentation > Rotation optimization strategies` → "Apply strategy now"
- **Automatic:** Via a defragmentation planner that fires on schedule
---
## Shipping Optimization Strategies
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)
| Criterion | Description |
|---|---|
| Number of orders | Cap on orders processed |
| Assignment type | Picking Only / Shipping Only / Picking & Shipping |
| Order type | Routes or Shipping orders |
| Shipping order type | Customer (specific account), Return (specific supplier), Transfer |
| Order status | Creating / Waiting / Released (optionally include Paused) |
| Destination | Orders must have **no destination** assigned (no packing, stage, or dock) |
| Sequence number | Use container sequence to fill channels in reverse shipping order |
| Candidate sort | Priority: auto-release date ASC, priority ASC, creation date ASC, lines ASC/DESC |
> If orders don't have all stock assigned yet, the stock assignment process runs first.
### Strategy Rules — Shipping (Destination Selection)
| Rule | Description |
|---|---|
| Same aisle | Move within the same aisle (minimum distance configurable) |
| Specific aisle | Move to a designated automatic aisle |
| Storage zone | One optional target zone (strictly enforced if set) |
| Location range | X/Y coordinate range within the aisle |
| Location sorting | X/Y coordinates ASC/DESC with sequence priority |
**APS warehouses:** EasyWMS finds the optimal channel by capacity and height to guarantee maximum channel occupancy and correct shipping sequence.
### Execution (Shipping)
- **Manual:** Select strategy in `Defragmentation > Shipping optimization strategies` → "Apply now"
- **Automatic:** Via a defragmentation planner
---
## Defragmentation Planners
Planners enable **unattended, scheduled** defragmentation. Both rotation and shipping strategies can be scheduled.
### Planner Configuration
| Field | Description |
|---|---|
| Type | Shippings / Rotation / All |
| Number of executions | Run strategies once in the window, or loop until time ends |
| Active date range | Start date (mandatory) + optional end date |
| Execution time | Start time and end time of the defragmentation window |
| Execution duration | How long (hours + minutes) the planner runs |
| Execution frequency | Days of the week (for non-daily planners) |
### Planner Actions
- **Manual trigger:** "Defragment now" button in `Defragmentation > Defragmentation planners`
- **Automatic:** Job runs at scheduled time and applies enabled strategies in sequence
- **Stop:** "Stop defragmentation" cancels all pending defragmentation tasks
---
## Operative Details
### Rotation Defragmentation Process
1. EasyWMS identifies containers meeting strategy criteria (not already defragmentation candidates, in locations with automatic unloading aisles)
2. For APS locations: skips containers with deposit/extraction errors, location locks, or container locks in lower depths
3. For rack locations: skips on matching-mask errors and locks at any depth
4. Applies putaway strategies to find valid destination location
5. Creates movement tasks with configured defragmentation priority
6. Tasks execute during inactivity periods
### Shipping Defragmentation Process
1. EasyWMS identifies shipping orders/routes meeting criteria (status: Creating/Waiting/Released, no destination assigned)
2. Applies sort criteria; ties broken by ascending creation date and code
3. Runs stock assignment for orders without full assignments
4. Identifies all assigned containers and linked customer containers
5. Sorts containers in reverse shipping sequence (for sequenced orders) to fill channels optimally
6. Applies destination rules to find valid locations
7. Creates movement tasks
---
## Configuration Parameters
| Parameter | Description | Applies to |
|---|---|---|
| `MAX_DEFRAG_TASKS` | Max simultaneous defragmentation tasks per automatic aisle | Both |
| `MAX_OPTIMIZATION_DEFRAG_CHANNEL` | Max channels being defragmented simultaneously per aisle; 0 = no limit (only MAX_DEFRAG_TASKS applies) | Both |
| `MAX_DEFRAG_ATTEMPT` | Max attempts to find a valid location for shipping defragmentation; after this, container is no longer a candidate | Shipping |
---
## Interface
| Path | Equipment |
|---|---|
| `Defragmentation > Rotation optimization strategies` | PC |
| `Defragmentation > Shipping optimization strategies` | PC |
| `Defragmentation > Defragmentation planners` | PC |
| `Warehouse > Tasks` (monitoring defrag tasks) | PC |
---
## Common Errors
| Symptom | Cause | Solution |
|---|---|---|
| No defragmentation tasks generated | No valid destination location found | Check zone configuration in strategies; verify putaway strategies are defined |
| Container skipped by rotation strategy | Container has lock preventing movement, or is in an error state (APS deposit/extraction error) | Resolve location/container locks first |
| Shipping defragmentation container never moved | `MAX_DEFRAG_ATTEMPT` reached without finding valid location | Review shipping strategy destination rules; check zone availability |
| Defragmentation runs during active operations | Planner window overlaps with peak activity | Adjust planner execution time to off-peak hours |
| Tasks not generated for APS location | Lower-depth containers block movement | Resolve APS channel issues first |
---
## Related
- [[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
- [[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
- [[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
wiki_old_13-05-2026/concepts/erp-interface.md
+796
View File
@@ -0,0 +1,796 @@
---
title: "ERP Interface"
type: concept
sources:
- areas/ERP.md
- areas/ERP/masters/itm.md
- areas/ERP/masters/itc.md
- areas/ERP/masters/kit.md
- areas/ERP/masters/sup.md
- areas/ERP/masters/acc.md
- areas/ERP/masters/own.md
- areas/ERP/masters/car.md
- areas/ERP/masters/lck.md
- areas/ERP/receipts/ror.md
- areas/ERP/receipts/asn.md
- areas/ERP/receipts/aso.md
- areas/ERP/receipts/ask.md
- areas/ERP/receipts/roc.md
- areas/ERP/receipts/rof.md
- areas/ERP/receipts/ref.md
- areas/ERP/requests/str.md
- areas/ERP/requests/scr.md
- areas/ERP/requests/cmc.md
- areas/ERP/shipping/sor.md
- areas/ERP/shipping/soc.md
- areas/ERP/shipping/sof.md
- areas/ERP/shipping/lof.md
- areas/ERP/shipping/wor.md
- areas/ERP/shipping/wof.md
- areas/ERP/shipping/rut.md
- areas/ERP/counts/cor.md
- areas/ERP/counts/cof.md
- areas/ERP/replenishment/srn.md
- areas/ERP/replenishment/sro.md
- areas/ERP/replenishment/srk.md
- areas/ERP/notifications/stv.md
- areas/ERP/notifications/stc.md
- areas/ERP/notifications/wsc.md
- areas/ERP/notifications/kst.md
- areas/ERP/notifications/unk.md
- areas/ERP/notifications/cos.md
- areas/ERP/notifications/coc.md
- sources/archives/08_Ajouter_image_fiche_article_ITM01.md
- sources/archives/18_ASN_DirectTransfer.md
- sources/archives/19_ASN_Transfer.md
- sources/archives/32_Fusion_commandes_Merge.md
related:
- concepts/order-inbound.md
- concepts/order-outbound.md
- concepts/stock.md
- concepts/product-item.md
- concepts/count.md
- concepts/quality-control.md
- concepts/transactions.md
- architecture/entities-map.md
last_compiled: "2026-04-17"
---
# ERP Interface
## Overview
The ERP Interface is the integration layer between Easy WMS and the customer's ERP system (SAP, Oracle, Microsoft Dynamics, or any custom ERP). Communication is asynchronous, message-based, using a structured 3-letter code naming convention. Messages flow in both directions:
- **ERP → WMS**: Master data synchronization, order creation, requests
- **WMS → ERP**: Status notifications, order finalizations, stock events
All messages have a **version** suffix when multiple variants exist (e.g., ROR01, SOR01, SOR02). The **Operation** field in each message specifies the action: `C` (Create), `U` (Update), `S` (Upsert), `D` (Delete).
## Complete Message Catalog
### Master Data Messages (ERP → WMS)
| Code | Name | Direction | Description |
|------|------|-----------|-------------|
| ITM | Item | ERP → WMS | Create/update/delete items (SKU master) |
| ITC | Item Classification | ERP → WMS | Min/max stock levels per sub-warehouse |
| OWN | Owner | ERP → WMS | Create/update owners (3PL tenants) |
| CAR | Carrier | ERP → WMS | Create/update carriers |
| ACC | Account | ERP → WMS | Create/update customer accounts |
| SUP | Supplier | ERP → WMS | Create/update suppliers |
| KIT | Kit | ERP → WMS | Create/update kit definitions |
| LCK | Lock Type | ERP → WMS | Lock type master data |
#### ITM — Image fields
The `ITM01` message can optionally convey the article's picture. Two modes:
| Mode | Field | Behaviour |
|---|---|---|
| **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.
---
### Inbound / Receipt Messages
#### ROR — Receipt Order (ERP → WMS)
The primary message for creating inbound orders.
**Versions:**
- `ROR01` (default): Supplier receipt orders, return orders, transfer orders
**Key fields:**
| Field | Description |
|-------|-------------|
| Operation | C/S/U/D |
| Site | Warehouse code |
| RorCode | Receipt order code (unique) |
| RorType | Supplier / Return / Transfer |
| SupplierCode | Supplier (Supplier type only) |
| Document | Delivery note number (optional) |
| Lines[].LneNumber | Line number |
| Lines[].LneItemCode | Item to receive |
| Lines[].LneQtyExpected | Expected quantity |
| Lines[].LneQtyFree | Free-of-charge quantity |
| Lines[].LneQtyUoMCode | Unit of measure |
| Lines[].transactional | If true: fail entire order if one line fails |
**Notes:**
- 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
---
#### ASN — Advanced Shipping Notice (ERP → WMS)
Pre-notifies WMS of containers en route to the warehouse.
**Versions:**
- `ASN01`: Basic container pre-notification
- `ASN02–ASN08`: Extended variants for cutting stock, quality status, loose stock, etc.
**Key fields:**
| Field | Description |
|-------|-------------|
| Operation | C/D |
| Site | Warehouse code |
| ContainerCode | Container LPN |
| ContainerTypeCode | Container type |
| ReceiptOrderCode | Associated receipt order (optional) |
| Lines[].ItemCode | Item in container |
| Lines[].Quantity | Quantity |
| Lines[].UoMCode | Unit of measure |
| Lines[].LogisticAttributes | Lot, expiry, serial, etc. |
**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 rejected or deleted: triggers [ASK](#ask--advanced-shipping-notice-ko-wms--erp) response
---
#### SRN — Stock Replenish Notice (ERP → WMS)
Pre-notifies WMS of loose stock for automatic warehouse replenishment.
**Key fields:**
| Field | Description |
|-------|-------------|
| Site | Warehouse code |
| Operation | Operation code |
| ItemCode | Item to replenish |
| OwnerCode | Owner |
| Quantity | Quantity |
| UoMCode | Unit of measure |
| Status | Stock status group |
| Attributes | Logistic attributes |
| RepQuePickingStationCode | Target picking conveyor (optional, triggers auto replenishment order) |
| RepQuePriority | Priority (Urgent/High/Normal/Low/VeryLow) |
| RepQueReplenishMode | Replenishment mode |
| RepQueEfficiencyMode | Efficiency mode |
---
#### ROC — Receipt Order Status Change (WMS → ERP)
Notifies ERP of receipt order status transitions.
**Statuses reported:** Waiting, Pending, Receiving, PartiallyReceived, Received, Closed, Canceled
**Key fields:**
| Field | Description |
|-------|-------------|
| Site | Warehouse code |
| RorCode | Receipt order code |
| Status | New status |
**Triggered by:** `INO.CST` transaction
---
#### 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.
**Key fields:**
| Field | Description |
|-------|-------------|
| Site | Warehouse code |
| RorCode | Receipt order code |
| Status | Closed / Canceled |
| Lines[].LneNumber | Line number |
| Lines[].LneItemCode | Item |
| Lines[].LneQtyExpected | Expected quantity |
| Lines[].LneQtyReceived | Received quantity |
| Lines[].LneQtyUoMCode | Unit of measure |
**Triggered by:** `INO.CLS` / `INO.CNL` transactions
---
#### REF — Receipt Finalization (WMS → ERP)
Notifies ERP that a **receipt** (physical receiving event) has been closed.
**Notes:**
- Sent only when a receipt with actual received stock is closed
- Sent for blind receipts (no associated receipt order)
- Includes detailed line-level stock received data
**Key fields:**
| Field | Description |
|-------|-------------|
| Site | Warehouse code |
| ReceiptCode | Receipt code |
| Status | Closed |
| RecDatContainers | Number of containers received |
| RecDatDate | Arrival/closure date |
| Lines[].LneItemCode | Item received |
| Lines[].LneQtyReceived | Received quantity |
| Lines[].LneStockItemCode | Actual received item (may differ from ordered) |
| Lines[].LneStockQty | Stock quantity |
| Lines[].LneStockWeight | Weight |
| Lines[].LneStockRecDate | Receipt timestamp |
**Triggered by:** `REC.CLS` transaction
---
#### ASO — Advanced Shipping Notice OK (WMS → ERP)
Confirms that a pre-notified container has been successfully received.
**Triggered by:** `CON.ASN.001` transaction (ASN container received) or `CON.PIE` (container entered via PIE)
**Key fields:**
| Field | Description |
|-------|-------------|
| Site | Warehouse code |
| ContainerCode | Received container |
| ReceiptOrderCode | Associated receipt order |
| 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).
---
#### ASK — Advanced Shipping Notice KO (WMS → ERP)
Notifies ERP that a pre-notified container has been rejected or deleted.
**Key fields:**
| Field | Description |
|-------|-------------|
| Site | Warehouse code |
| ContainerCode | Rejected container |
| ReceiptOrderCode | Receipt order (optional) |
| CancelDate | Rejection timestamp |
**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.
---
#### SRO — Stock Replenish OK (WMS → ERP)
Confirms that pre-notified loose stock has been used for automatic warehouse replenishment.
**Triggered by:** `STK.REP.001` transaction
---
#### SRK — Stock Replenish KO (WMS → ERP)
Notifies that pre-notified loose stock has been canceled (not used for replenishment).
**Triggered by:** `STK.REP.CNL` transaction
---
### Outbound / Shipping Messages
#### SOR — Shipping Order (ERP → WMS)
The primary message for creating outbound orders.
**Versions:**
- `SOR01`: Standard shipping order (items/containers)
- `SOR02`: Prepackaging (specifies package count/type per line; VAS integration)
**Key fields:**
| Field | Description |
|-------|-------------|
| Operation | S (new/upsert) / U (update) / D (cancel) |
| Site | Warehouse code |
| SorCode | Shipping order code (unique) |
| SorType | Customer / Return / Transfer / DirectTransfer |
| Priority | Urgent/High/Normal/Low/VeryLow |
| EnableReplenishment | Enable auto replenishment for this order |
| PrpPackingLocation | Consolidation location code |
| PlnAssignedDock | Pre-assigned dock |
| Lines[].LneNumber | Line number |
| Lines[].LneItemCode | Item (or alias) |
| Lines[].LneContCode | Container (optional) |
| Lines[].LneQtyOrder | Ordered quantity |
| Lines[].LneQtyUoMCode | Presentation |
| Lines[].LneAttributes | Logistic attribute filters (lot, expiry, etc.) |
| Lines[].LneTrmCritical | Critical line flag (all or nothing) |
| Lines[].LneTrmRequired | Required line flag (conditional preparation) |
| Lines[].LneMaxLots | Maximum number of lots |
| Lines[].LneQtyAllowExcess | Allow over-allocation |
| Lines[].LneTrmAlternative | Use configured substitutes |
| Lines[].LneAltItmCode | Explicit substitute item |
| Lines[].LneTrmStaReq | Required stock status |
| Lines[].LneTrmStaRejC | Rejected stock status |
| Lines[].LneTrmStaPref | Preferred stock status |
| Lines[].LneQtyReserve | Stock reserve quantity |
| Lines[].ShipExpiredStock | Ship only expired stock |
| 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 = 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).
---
#### SOC — Shipping Order Status Change (WMS → ERP)
Notifies ERP of shipping order status transitions.
**Statuses reported:** Release, StockFailure, InPreparation, Paused, Stopped, Prepared, Completed, Canceled
**Triggered by:** `OUT.CST` transaction
---
#### SOF — Shipping Order Finalization (WMS → ERP)
Notifies ERP that a shipping order has been closed or canceled with shipped quantities.
**Versions:**
- `SOF01`: Full close
- `SOF02`: Partial close (with remaining quantities)
**Key fields:**
| Field | Description |
|-------|-------------|
| SorCode | Shipping order code |
| Status | Closed / Canceled |
| ClosingNumber | Closing sequence number |
| Lines[].LneNumber | Line number |
| Lines[].LneQtyShipped | Shipped quantity |
| Lines[].LneQtyUoMCode | Unit of measure |
**Triggered by:** `OUT.CLS` / `OUT.CNL` transactions
---
#### 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:
- Same account
- Same site (warehouse)
- Same route or delivery address
- Same carrier
When `ALLOW_MERGE_DIFFERENT_ACCOUNT = true` is set, the "same account" rule is relaxed (cross-account merges become possible).
**Effect on orders:**
- 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
See [concepts/order-outbound.md](order-outbound.md#merge-order-fusion) for operator flows and limitations.
---
#### LOF — Load Finalization (WMS → ERP)
Notifies ERP that a truck load has been closed (truck loaded and sealed).
**Key fields:**
| Field | Description |
|-------|-------------|
| Site | Warehouse code |
| LoadCode | Load code |
| RouteCode | Route code |
| Seal | Seal number |
| ClosureDate | Closure timestamp |
| ShippingOrders[] | Orders included in load |
**Triggered by:** `LOAD.CLS` transaction
---
#### WOR — Work Order (ERP → WMS)
Creates kit assembly or other work orders.
**Used for:** Kit assembly, quartering (cutting), or other manufactured outputs
---
#### WOF — Work Order Finalization (WMS → ERP)
Notifies ERP that a work order (kit assembly, etc.) has been closed or canceled.
**Triggered by:** `WOR.CLS.001` / `WOR.CNL.001` transactions
---
#### RUT — Route (ERP → WMS)
Creates or updates carrier routes.
**Key fields:**
| Field | Description |
|-------|-------------|
| RouteCode | Route code |
| CarrierCode | Carrier |
| DockCode | Departure dock |
| DepartureTime | Scheduled departure |
---
### Count Messages
#### COR — Count Order Request (ERP → WMS)
Requests WMS to create a physical count.
**Supported scope types:**
- Item count (by item + owner)
- Location count (by location range or aisle)
- Container count (by LPN)
**Key fields:**
| Field | Description |
|-------|-------------|
| Site | Warehouse code |
| CountCode | Count code |
| Priority | Count priority |
| Lines[].ItemCode | Item (item count) |
| Lines[].Aisle | Aisle (aisle count) |
| Lines[].CntCode | Container LPN (container count) |
| Lines[].LocationFrom/To | Location range (location count) |
| Lines[].IsInformed | Blind (false) or informed (true) count |
---
#### COF — Count Order Finalization (WMS → ERP)
Reports count results when a WMS-received count (from COR) is closed or canceled.
**Note:** Only sent for ERP-initiated counts, not WMS-initiated counts.
**Key fields:**
| Field | Description |
|-------|-------------|
| Status | Closed / Canceled |
| Site | Warehouse code |
| CountCode | Count code |
| Lines[].ItemCode | Counted item |
| Lines[].Quantity | Counted quantity |
| Lines[].UomCode | Unit of measure |
| Lines[].LogisticAttributes | Lot, serial, etc. |
| Lines[].StockStatus | Receiving and user statuses |
| (empty location) LocationEmpty=1 | Indicates empty location |
**Triggered by:** `COU.END` transaction
---
### Request Messages
#### STR — Stock Status Change Request (ERP → WMS)
Requests WMS to apply or remove a quality lock on stock.
**Operations:**
- `S` (Add): Lock stock with a user status
- `D` (Remove): Remove user or receiving status
**Filter options:** Item, Owner, Container, Lot (logistic attributes)
**Lock types:**
- Time-limited lock: `StaUsrEnd` field with UTC expiry datetime
- Permanent lock: No end date, must be manually released
**Key fields:**
| Field | Description |
|-------|-------------|
| Operation | S (lock) / D (unlock) |
| ItemCode | Item to lock |
| OwnerCode | Owner |
| FltAttLot | Lot filter |
| StaCode | Status code to apply |
| 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
---
#### SCR — Stock Count Request (ERP → WMS)
Requests WMS to report current stock for an item or lot.
**Key fields:**
| Field | Description |
|-------|-------------|
| Site | Warehouse code |
| MassiveCount | true=grouped by item / false=per container |
| ItemCode | Item |
| OwnerCode | Owner |
| LotCode | Lot (optional) |
**Response:** [WSC](#wsc--warehouse-stock-count-wms--erp) message
---
#### 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.
**Key fields:**
| Field | Description |
|-------|-------------|
| Site | Warehouse code |
| ContainerCode | Container |
| Destination | Destination location code |
---
### Notification Messages (WMS → ERP)
#### STV — Stock Variation (WMS → ERP)
Reports any stock quantity change (increase, decrease, creation, deletion, UoM change, logistic attribute change).
**Operations:** C (creation/increase), D (deletion/decrease)
**Key fields:**
| Field | Description |
|-------|-------------|
| Operation | C or D |
| Site | Warehouse code |
| ItemCode | Item |
| OwnerCode | Owner |
| QuantityVar | Changed quantity (in base UoM) |
| UoMCode | Unit of measure (if UoM change) |
| FilterAttributes | Old logistic attributes (for attribute changes) |
| Attributes | New logistic attributes (for attribute changes) |
| ReasonCode | Adjustment reason (if configured) |
**Also sent for:** Presentation breakage (UoM split during picking), replenishment splits
**Triggered by:** `STK.ADJ` transaction
---
#### STC — Stock Status Change (WMS → ERP)
Reports every stock quality status change (lock or unlock).
**Can be triggered by:** STR request from ERP, manual user action (RF or SmartUI), automatic time-based unlock
**Key fields:**
| Field | Description |
|-------|-------------|
| ItemCode | Item |
| OwnerCode | Owner |
| Quantity | Stock quantity |
| UomCode | Unit of measure |
| FltAttLot | Lot |
| ContainerCode | Container (if applicable) |
| StaUsrCode | New user status (lock case) |
| StaUsrEnd | Expiry date (for time-limited locks) |
| StaUsrEmpty | true (unlock case) |
**Triggered by:** `CST.STK` transaction
---
#### WSC — Warehouse Stock Count (WMS → ERP)
Response to SCR stock contrast request. Reports current stock quantities.
**Key fields:**
| Field | Description |
|-------|-------------|
| Site | Warehouse code |
| WSCDate | Date of stock check |
| ItemCode | Item |
| OwnerCode | Owner |
| Quantity | Current stock quantity |
| UomCode | Unit of measure |
| LotCode | Lot (if lot-level contrast requested) |
**Triggered by:** `SCR.REQ` transaction
---
#### KST — Kit Assembled (WMS → ERP)
Notifies ERP that kit stock has been assembled.
**Key fields:**
| Field | Description |
|-------|-------------|
| Site | Warehouse code |
| WorkOrderCode | Work order code (if applicable) |
| KitItemCode | Assembled kit item |
| KitQuantity | Kit quantity |
| KitVersion | Kit version |
| CompItemCode | Component item |
| CompQty | Component quantity used |
**Triggered by:** `STK.KIT.MOUNT` transaction
---
#### UNK — Kit Disassembled (WMS → ERP)
Notifies ERP that kit stock has been disassembled.
**Triggered by:** `STK.KIT.UMOUNT` transaction
---
#### COS — Container Shipped to PS (WMS → ERP)
Notifies ERP that a client container has been sent to the outbound conveyor (PS/Sortation).
**Key fields:**
| Field | Description |
|-------|-------------|
| Site | Warehouse code |
| StationCode | Station where container ended |
| LocationCode | Location |
| ContainerCode | Container |
| StationToCode | Destination station (if task-based move) |
| ClosedDate | Closing timestamp (UTC) |
**Triggered by:** `CON.COS.001` transaction
---
#### COC — Container Closed in MP (WMS → ERP)
Notifies ERP that a client container has been closed in a Preparation Zone (MP).
**Key fields:** Same structure as COS
**Triggered by:** `CON.COC` transaction
---
#### ERR — Error (WMS → ERP)
Sent when WMS cannot process an incoming ERP message. Contains the original message reference and error description.
---
## Message Operation Codes
| Code | Meaning |
|------|---------|
| `C` | Create (new record) |
| `S` | Upsert (create or update) |
| `U` | Update (existing record only) |
| `D` | Delete or cancel |
## Integration Architecture
### Message Flow
```
ERP ──[async message]──→ WMS Integration Queue
WMS Integration Queue ──→ WMS Core (processes message)
WMS Core ──[transaction]──→ Post-processor
Post-processor ──[async message]──→ ERP Response Queue
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:
| Transaction | Generated Message |
|------------|-----------------|
| `CON.ASN.001` | ASO |
| `CON.CNL.ASN` | ASK |
| `CON.PIE` | ASO |
| `INO.CST` | ROC |
| `INO.CLS` | ROF |
| `INO.CNL` | ROF |
| `REC.CLS` | REF |
| `OUT.CST` | SOC |
| `OUT.CLS` | SOF |
| `OUT.CNL` | SOF |
| `LOAD.CLS` | LOF |
| `WOR.CLS.001` | WOF |
| `WOR.CNL.001` | WOF |
| `COU.END` | COF |
| `STK.ADJ` | STV |
| `CST.STK` | STC |
| `STK.REP.001` | SRO |
| `STK.REP.CNL` | SRK |
| `SCR.REQ` | WSC |
| `STK.KIT.MOUNT` | KST |
| `STK.KIT.UMOUNT` | UNK |
### Module-Specific ERP Messages
Beyond the core catalog, optional modules add their own ERP messages:
| Module | Message | Direction | Description |
|--------|---------|-----------|-------------|
| Manufacturing | RCP01/RCP02 | ERP → WMS | Recipe (BOM) create/update/delete |
| Manufacturing | MOR01 | ERP → WMS | Manufacturing production order create/update/delete |
| Manufacturing | MOF | WMS → ERP | Manufacturing order finalization (closed or cancelled) |
| Manufacturing | FGP | WMS → MES | Finished goods produced notification (MES integration) |
| Kits | WOR | ERP → WMS | Work order for kit assembly or disassembly |
| Kits | WOF | WMS → ERP | Work order finalized (ERP-originated orders only) |
| Kits | KST | WMS → ERP | Kit manually assembled (manual work orders) |
| 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 |
| 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 |
| Slotting | SAC01 | WMS → ERP | ABC rotation classification suggestion (sent after manual recalculation) |
| DOM | POR/ROC/SOR/SOC/SOF/DOF/ACK/NCR | Both | Multi-node orchestration |
| Yard Management | Appointment sync | Both | ERP/TMS appointment exchange |
| Counting | SCR/WSC | Both | Stock contrast |
**SAC01 detail**: sent manually from SmartUI after running the ABC rotation analysis in the WMS. Contains item code + suggested ABC class. The ERP uses this to update item classification. Only sent when the WMS operator explicitly triggers it (not automatic).
**TPV01 detail**: sent by POS (point of sale) system when a store sale occurs. EasyWMS decrements the corresponding store sub-warehouse stock in real time, providing a live stock view per store. Requires Store Fulfillment module.
**TOR01/TOF01**: used by the Store Fulfillment module to manage inter-store replenishment. TOR01 creates the transfer order from ERP; TOF01 is returned when the transfer is complete.
## Common Errors
| Symptom | Cause | Solution |
|---------|-------|---------|
| ROR creates order but lines fail | `transactional` group not set, line validation error | Check item/UoM existence; review partial creation log |
| ASN container arrives but no ASO sent | Post-processor not running | Check integration pool and post-processor service |
| SOR rejected: item not found | Item not yet synced via ITM | Send ITM first, then SOR |
| STR applies lock but no STC received | Stock matching filters returned zero results | Verify item/owner/lot combination exists |
| SOF never received | Shipping order not yet closed in WMS | Check order status; may be in Prepared status awaiting manual close |
| COR count created but COF never sent | Count was created from UI (not ERP-initiated) | COF only sent for ERP-initiated counts |
## Related
- [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
- [Quality Control](quality-control.md) — Stock lock/unlock and STR/STC messages
- [Count](count.md) — Physical counts and COR/COF messages
- [Stock](stock.md) — Stock adjustments and STV messages
- [Transactions](transactions.md) — Internal transactions that trigger ERP messages
- [Entities Map](../architecture/entities-map.md) — ERP integration touch points per entity
- [Replenishment](replenishment.md) — Automatic warehouse replenishment and SRN/SRO/SRK
- [Manufacturing](../modules/manufacturing.md) — MOF/FGP production messages
- [DOM](../modules/dom.md) — Distributed order management messages
wiki_old_13-05-2026/concepts/kits.md
+229
View File
@@ -0,0 +1,229 @@
---
title: "Kits"
type: concept
sources:
- areas/ERP/masters/kit.md
- areas/ERP/shipping/wor.md
- areas/ERP/shipping/wof.md
- areas/ERP/notifications/kst.md
- areas/ERP/notifications/unk.md
- custom/analyse_fonctionnelle.md
- sources/archives/13_Gestion_KIT.md
related:
- concepts/product-item.md
- concepts/stock.md
- concepts/order-outbound.md
- concepts/erp-interface.md
- modules/manufacturing.md
last_compiled: "2026-04-17"
---
# Kits
## Overview
A **kit** is an article resulting from the assembly of several component articles. In Easy WMS, kits represent pre-assembled or on-demand assembled products that allow fulfilling a single order line by collecting multiple component items. The kit concept is distinct from the [[manufacturing]] module (which handles raw material → finished goods); kits operate at the finished goods + components level.
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
- **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.
## Creating a kit article (SmartUI)
From `Données Principales → Kit` :
1. Kit article + owner.
2. Kit **version** (must be a value permitted by the logistic profile).
3. Base unit of measure.
4. Assembled or not.
5. If assembled : on-demand assembly allowed ?
Add components with **"Ajouter composant"** : item, quantity, main component.
---
## Types
### 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.
**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.
### 2. Kit with assembly (mounting required)
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 — 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
When integrated with SAGE 100C, EasyWMS maps SAGE nomenclature types to kit configurations:
| SAGE type | EasyWMS config | Notes |
|-----------|---------------|-------|
| **Fabrication** | assembled=YES, on_demand=NO | Can be inventoried; can appear in PO; requires MO from SAGE |
| **Commercial/Composed** | assembled=NO, on_demand=NO | Cannot be inventoried; cannot appear in PO; **no kit stock in WMS** |
| **Linked article** | Imported as simple item | Handled as two independent items in WMS |
> **Warning**: For Commercial/Composed kits, no WMS stock of the kit article should exist. SAGE tracks only components.
---
## Lifecycle
### Kit Assembly (Kitting)
```
ERP sends WOR → WMS creates work order
→ WMS generates picking tasks for each component
→ Operator picks components to assembly zone
→ Assembly confirmed (components consumed, kit created in stock)
→ WMS sends WOF to ERP (only if WOR came from ERP)
→ If manual/manual WO: WMS sends KST to ERP
```
**Detailed process (TRF)**:
1. ERP sends `WOR` (or manager creates order manually in WMS)
2. WMS generates picking tasks for each component to the assembly zone
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
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
> **Warning**: If component stock is insufficient, EasyWMS does NOT automatically request kit fabrication.
### Kit Disassembly (De-kitting)
```
ERP sends WOR (disassembly) → WMS creates work order
→ WMS generates picking tasks to bring kits to assembly zone
→ Operator disassembles kits
→ Kit stock decremented, component stocks incremented
→ WMS sends WOF to ERP (if WOR from ERP)
→ If manual: WMS sends UNK to ERP
```
**Detailed process**:
1. ERP sends `WOR` (disassembly type) or manager creates manually
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
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
### Creation modes
| Mode | Description |
|---|---|
| **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 (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 |
### Modifications allowed, by status
| Status | Allowed modifications |
|---|---|
| En attente | Every field |
| Libéré | Quantity + priority only |
| En cours (≥ 1 kit assembled) | Quantity (must remain ≥ already assembled) + priority |
| Annulation | Only if **no** kit has been assembled yet |
## Supply & Assembly/Disassembly
When a WO is released, the WMS checks available stock in the kit zone. If insufficient, a **supply (replenishment) order is automatically created and released** to feed the zone.
## Closing a Work Order
- **Automatic** — once every requested kit has been assembled / disassembled.
- **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
| | **On-demand assembly = YES** | **On-demand assembly = NO** |
|---|---|---|
| WO creation | Automatic | Manual |
| Shortage detection | Automatic + WO created | Manual lookup via the Outbound Orders view |
| Reaction time | Immediate on order integration | Depends on how often the view is reviewed |
> ⚠️ Without `Montage sur demande`, EasyWMS emits **no automatic alert** (no notification, no email). It is the client's responsibility to regularly review the Outbound Orders view to detect kit shortages.
## Business rules
- A kit article cannot have stock in WMS if it is a "Commercial/Composed" type (no stock tracking in ERP → sync impossible)
- 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
- 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
---
## ERP Integration
| Message | Direction | Trigger | Content |
|---------|-----------|---------|---------|
| `KIT` | ERP → WMS | Kit master data create/update/delete | Kit code + component list |
| `WOR` | ERP → WMS | Create/update work order (assembly or disassembly) | Recipe/kit, quantity, production zone, priority |
| `WOF` | WMS → ERP | Work order closed or cancelled (ERP-originated only) | Stocks consumed and created |
| `KST` | WMS → ERP | Manual kit assembly (work order created in WMS, not ERP) | Notifies consumed components + created kit stock |
| `UNK` | WMS → ERP | Manual kit disassembly (work order created in WMS) | Notifies consumed kits + created component stock |
### Key distinctions
- `WOF` is sent **only** when the work order originated from the ERP (not manual orders)
- `KST` is sent for **manual assemblies** or manually created work orders
- `UNK` is sent for **manual disassemblies** or manually created disassembly work orders
- For ERP-originated orders: WOF covers the close/cancel notification regardless of quantities
---
## Configuration
| Field | Description |
|-------|-------------|
| **assembled** | YES = physical assembly required; NO = pick components only |
| **assembly_on_demand** | YES = auto-create assembly when kit ordered without stock; NO = WOR required |
| **Component items** | Must exist in WMS item master before kit creation |
| **Kit item** | Must have its own item record with full logistic profiles |
**Interface**: Kit management is under `Masters > Kits` in SmartUI.
---
## Common errors
| Error | Cause | Resolution |
|-------|-------|-----------|
| Kit stock out of sync with ERP | Kit is Commercial/Composed type but WMS has kit stock | Delete WMS kit stock; this type must not be tracked in WMS |
| WOF not sent to ERP | Work order was created manually in WMS | WOF only sent for ERP-originated WOR; for manual orders use KST/UNK |
| Component picking tasks not generated | Component items don't exist in WMS / insufficient component stock | Verify component item masters; receive component stock first |
| Kit not available for shipping orders | Kit requires assembly (assembled=YES) but no WOR created | Create work order manually or wait for ERP WOR |
---
## Related
- [[product-item]] — Kit articles and components are both standard items with logistic profiles
- [[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
- [[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
wiki_old_13-05-2026/concepts/labels.md
+387
View File
@@ -0,0 +1,387 @@
---
title: "Labels & Printing"
type: concept
sources:
- areas/receptions/reception_admin/labels_containers.md
- areas/receptions/reception_admin/labels_items.md
- areas/inventory_management/items/cutting_stock_label.md
- areas/inventory_management/stock/print_stock_label.md
- areas/receptions/reception_dock/multilabel_recep.md
- sources/archives/23_Declencheurs_impressions.md
related:
- concepts/container.md
- concepts/product-item.md
- concepts/reception.md
- concepts/cutting-stock.md
- concepts/stations.md
- concepts/parameters.md
last_compiled: "2026-04-17"
---
# Labels & Printing
## Overview
Easy WMS provides label printing capabilities for multiple warehouse objects: containers (LPN), items/stock, cutting stock, locations, equipment, docks/stages, aisles, and carriers. Labels use either the **Code 128** standard or the **GS1-128** standard (structured barcodes with Application Identifiers).
Printing occurs at multiple touchpoints in the workflow: during reception, during picking, from the stock view, from the RF terminal, and automatically when containers arrive at configured stages or docks.
## Label Types
### Container Labels (LPN Labels)
Labels for containers/pallets identified by an SSCC (Serial Shipping Container Code). Generated before or during reception to pre-label containers for receiving.
**Standard formats:**
| Format | Dimensions | Labels/Sheet | Paper |
|--------|-----------|--------------|-------|
| 1x-A6 | 105 × 148 mm | 1 | A6 labeler |
| 20x(105x29) | 105 × 29 mm | 20 | A4 |
| 2x(175x135) | 175 × 135 mm | 2 | A4 |
| 33x(75x25) | 75 × 25 mm | 33 | A4 |
| 4x(105x148) | 105 × 148 mm | 4 | A4 |
| 1xA5 (GS1-128) | 148 × 210 mm | 1 | A5 labeler |
**GS1-128 Container Label Variants:**
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.
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.
**GS1-128 Mono-Reference Application Identifiers (AI):**
| AI | Content | Structure |
|----|---------|-----------|
| **00** | SSCC (container serial code) | n18 — always present |
| **02** | Item alias (GTIN) | n14 — always present |
| 10 | Lot number | an..20 |
| 11 | Manufacturing date | n6 |
| 15 | Best-before date | n6 |
| 17 | Expiration date | n6 |
| 37 | Quantity | n..8 |
Lot (AI 10), if present, always appears in the lower barcode next to the SSCC.
**Container label generation use cases:**
| Method | Who | When |
|--------|-----|------|
| 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 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).
**Parameters (container labels):**
| Parameter | Default | Description |
|-----------|---------|-------------|
| NUM_COPIES_RECEPTION_LABEL | 1 | Copies per container during reception |
| RECEPTION_MAX_NUM_CONTAINER_LABELS_TO_PRINT | 1000 | Security limit: max copies per generation |
| DEFAULT_RECEPTION_LABEL_CONTAINER_REPORT_NAME | STD_RPT_CONTAINER_LABEL_GS1_128 | Default report for mono and multi-reference container labels in reception |
| CONTAINER_LABEL_DEFAULT_FORMAT | (blank) | Default format: `1x-A6`, `1x-GS1-128`, `20x(105x29)-A4`, `2x(175x135)-A4`, `33x(75x25)-A4`, `4x(105x148)-A4` |
| ALLOW_PRINT_LABEL_CONTAINER_QUESTION_BLIND_RECEPTION | False | In blind reception: ask user if they want to print GS1 container labels |
### Item / Stock Labels
Labels for individual stock items. Two formats: Code 128 and GS1-128.
**Code 128 item labels:**
- Printed for receipt lines that are *pending to receive* or *partially received*
- Labels per line = remaining quantity to receive
- Content: item code + short description
**Code 128 formats:**
| Format | Dimensions | Labels/Sheet | Paper |
|--------|-----------|--------------|-------|
| 1x-A6 | 105 × 148 mm | 1 | A6 labeler |
| 20x(105x29) | 105 × 29 mm | 20 | A4 |
| 2x(175x135) | 175 × 135 mm | 2 | A4 |
| 33x(75x25) | 75 × 25 mm | 33 | A4 |
| 4x(148x105) | 148 × 105 mm | 4 | A4 |
**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
**GS1-128 Item Application Identifiers (AI):**
| AI | Content | Structure |
|----|---------|-----------|
| **01** | GTIN (item code) | n14 — always present |
| 10 | Lot number | an..20 |
| 11 | Manufacturing date | n6 |
| 15 | Best-before date | n6 |
| 17 | Expiration date | n6 |
| 21 | Serial number | an..20 |
Upper barcode = item + lot/serial. Lower barcode = dates (production, best-before, expiration in that order).
**Requirements for GS1-128 item labels:** Item must have a GTIN code (alias) following GS1-128 specification (14 digits).
To print item labels during reception (RF or workstation), it must be **enabled at receipt level** (from the receipts view, or via the ROR message field for all receipts from a given receipt order).
**Item label generation use cases:**
| Method | Who | When |
|--------|-----|------|
| Print from receipt lines (PC) | Admin | From "Receipt lines" view for pending items |
| Print from Stock view (PC) | Admin | "Print labels" action in Stock view |
| Print GS1-128 in supplier receipt (RF) | Operator | During supplier receiving |
| Print GS1-128 in blind receipt (RF) | Operator | During blind receiving |
| Print GS1-128 at workstation receipt | Operator | During workstation receiving |
**Parameters (item labels):**
| Parameter | Default | Description |
|-----------|---------|-------------|
| PRODUCT_LABEL_DEFAULT_FORMAT | (blank) | Default format: `A6`, `105x29`, `175x135`, `105x148`, `75x25` |
| DEFAULT_RECEPTION_LABEL_ITEM_REPORT_NAME | STD_RPT_STOCK_LABEL_GS1_128 | Default report for item labels in reception |
| ALLOW_PRINT_LABEL_ITEM_QUESTION_BLIND_RECEPTION | False | In blind receipt: ask user if they want to print GS1 item labels |
### Cutting Stock Labels
Specialized label for cutting stock in non-consolidating UoM conversions. Used to track individual stretches through the warehouse.
**Label content:** Item code, quantity/length, UoM, logistic attributes (lot, caliber, quality, production method, origin, post-production treatment, date of manufacture, version, color).
**Physical design:** Label can be attached to the side of a roll (flat application) or wrap around a stretch (embrace application). Supported format: **A6 only**.
**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
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
**Printer priority order (highest to lowest):**
1. Printer associated with the cutting station (for cutting station stock)
2. Printer associated with the equipment
3. Printer defined in CUTTING_PRINTER parameter
4. Free choice of label printer in warehouse
**Parameters (cutting stock labels):**
| Parameter | Default | Description |
|-----------|---------|-------------|
| CUTTING_PRINTER | (blank) | Default printer for cutting stock labels during picking |
**Cutting profile flags that control label generation:**
- "Labeling source stock" → generate label for the roll from which stock was cut
- "Labeling cut stock" → generate label for the cut portion
### Client Container Labels
Automatically printed when a picking container is unloaded into a stage that has a printer configured.
**Content:** Stock list (items, quantities, UoM, logistic attributes), shipping order code, recipient name/address, carrier code, container code.
**Parameter:** CLIENT_CONTAINER_LABEL_REPORT (default: STD_RPT_CLIENT_CONTAINER_LABEL_15)
**Packing list:** CLIENT_CONTAINER_PACKING_REPORT (auto-print packing list when container downloaded to configured stage)
## Multi-Reading of Labels at Reception
An alternative to standard receiving processes that allows reading all barcode data from GS1-128 labeled stock/containers in bulk.
**Applicable to:** Any reception type (supplier, blind, return) when GS1-128 labeled stock arrives.
**Four modes:**
| Mode | Use Case |
|------|----------|
| Loose stock | Receive unexpected loose stock (receipt/return/blind) |
| Multi-reference containers | Multi-item containers or return containers |
| 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.
During multi-reading: type and height of container can be selected; stock statuses can be entered.
**Parameters:**
| Parameter | Default | Description |
|-----------|---------|-------------|
| MAX_NUM_LABELS_TO_READ | 1 | Max barcode readings per item/container. 1 = multi-reading disabled. Min: 1, Max: 30 |
| ALLOW_CREATE_RECEPTION | False | If no receipt found, allow creation of a new receipt from RF (starts without lines; adds stock as received) |
**Transactions:** CON.RECEP (per container), STK.RECEP (per stock line)
**ERP:** REF message at receipt close
## RF Terminal Label Printing
From the RF terminal, operators can print labels on-demand via "Label printing" in the "Utilities" menu. Used for replacement of lost or damaged labels.
**Printable objects from RF:**
| Object | Details |
|--------|---------|
| Location label | Print for a specific location; format adapted to props, beams, or individual locations |
| Container label | Existing container; Code 128 or GS1-128 |
| Delivery note | For prepared or dispatched client containers; includes: shipping order code, recipient name/address, carrier, container code, stock detail (item/quantity/UoM/weight/logistic attributes per line) |
| Equipment label | Equipment code |
| Item label | From item master (no stock required at equipment) |
| Dock/stage label | One or multiple labels for docks/stages; select all or specific ones |
| Aisle label | Aisle code |
| Carrier label | Carrier code from carriers master |
**Configuration:** For each print operation, must specify: labeling machine or printer, print format, number of copies.
## Automatic Label Printing
Some printing happens automatically without explicit operator action:
| Trigger | Label | Configuration |
|---------|-------|---------------|
| Container arrives at dock/stage with configured printer | Client container label | CLIENT_CONTAINER_LABEL_REPORT parameter + printer assigned to dock/stage |
| Shipping order closed | Delivery note | OUTBOUND_ORDER_PACKINGLIST_AUTOPRINT = True + printer + report name parameters |
| ETQ (Labeller) station | Labels applied by labeling machine | Station type 58 in EasyS; no WMS action required |
## Document & Label Printing Triggers (Full Reference)
This section consolidates **every known trigger** for each document/label, including the manual menu path, the XML tag (if any) that auto-triggers it from the ERP, and the parameter that selects the report name. A trigger is either **manual** (menu click), **automatic on XML flag** (ERP → WMS), or **automatic on warehouse event** (drop to buffer/dock/stage, order close, etc.).
### Receipt report ("Bon de réception")
| Trigger | Notes |
|---|---|
| Menu **Réceptions → Réception** → select → *Imprimer rapport → Stock reçu* | Manual only |
### Container label (pre / during reception)
| Trigger | Notes |
|---|---|
| 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` |
### Client container label (shipping)
| Trigger | Notes |
|---|---|
| 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` | — |
### Packing list — per container ("Liste de conditionnement par support")
| Trigger | Notes |
|---|---|
| SmartUI **"Document printings"** on POUMON → *Impression automatique de la liste de colisage* | Auto |
| 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` | — |
### Packing list — per item ("Liste de conditionnement par article")
| Trigger | Notes |
|---|---|
| Parameter `OUTBOUND_ORDER_PACKINGLIST_AUTOPRINT = true` → prints on outbound order close | Auto. Uses `OUTBOUND_ORDER_PACKINGLIST_DEFAULT_PRINTER`, `OUTBOUND_ORDER_PACKINGLIST_NUM_COPIES`, `OUTBOUND_ORDER_PACKINGLIST_REPORT_NAME` |
| Menu **Sorties → Ordres de sortie** → select → *Imprimer rapport → Liste de conditionnement (par article)* | Manual |
### Item label
| Trigger | Notes |
|---|---|
| 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")
| Trigger | Notes |
|---|---|
| Menu **Sorties → Ordres de sortie** → select → *Imprimer rapport → Note de livraison* | Manual |
| Multi-Carrier module : **Livraisons → Transporteurs/Agences** → *Imprimer bon de livraison* | Auto at parcel close, after carrier API call |
> ⚠️ **No standard auto-print of BL without the Multi-Carrier module.** Common workaround : set the BL report name into `OUTBOUND_ORDER_PACKINGLIST_REPORT_NAME` (normally used for item-level packing list) so that the order-close auto-print triggers the BL.
### Carrier label *(Multi-Carrier module only)*
| Trigger | Notes |
|---|---|
| SOR02 tag `<DlvPrintLabel>` (boolean) | Auto |
| Menu **Livraisons → Transporteurs/Agences** → *Imprimer étiquette* | Auto at parcel close |
| Menu **Livraisons → Colis** → *Imprimer étiquette du colis* | Manual |
### Transport sheet / waybill ("Feuille de route")
| Trigger | Notes |
|---|---|
| Menu **Configuration → Chargement** → fields *Nombre d'exemplaires* + *Document de transport* (report name) | Configuration only |
| Menu **Sorties → Chargements camion** → select → *Feuille de transport* | Manual |
### Packing list diff report
| Trigger | Notes |
|---|---|
| Menu **Sorties → Ordres de sortie** → select → *Imprimer rapport → Différence de liste de conditionnement* | Manual |
### Location label
| Trigger | Notes |
|---|---|
| Menu **Entrepôt → Emplacements** → select one → *Imprimer étiquette* | Manual, single location |
| Menu **Entrepôt → Emplacements** → no selection → *Imprimer intervalle d'emplacements* | Manual, range |
## Interface Summary
| Label Type | PC Interface | RF Interface |
|------------|-------------|--------------|
| Container labels (pre-reception) | Warehouse > Containers > "Generate labels" | Receipts > "Generate labels" menu option |
| Item labels (during reception) | Receiving > Receipt lines | Receipts > Supplier or Blind |
| Container labels (during reception) | Receiving > Receipts > "Enable label printing" | Receipts > Supplier or Blind |
| GS1-128 item or container labels | Receiving > Receipt lines | Receipts > Supplier or Blind |
| Cutting stock labels | Warehouse > Stock > "Print cutting label" | Utilities > Location adjustment (source label only) |
| Any label (replacement) | N/A | Utilities > Label printing |
| Location labels | Warehouse Map (2D view) > Print labels | Utilities > Label printing |
| Dock/stage labels | Control > Docks and stages > "Print labels" action | Utilities > Label printing |
## Parameters Reference
All label-related parameters consolidated:
| Parameter | Default | Topic |
|-----------|---------|-------|
| CONTAINER_LABEL_DEFAULT_FORMAT | (blank) | Container label format |
| DEFAULT_RECEPTION_LABEL_CONTAINER_REPORT_NAME | STD_RPT_CONTAINER_LABEL_GS1_128 | Container label report |
| NUM_COPIES_RECEPTION_LABEL | 1 | Copies per container |
| RECEPTION_MAX_NUM_CONTAINER_LABELS_TO_PRINT | 1000 | Max container labels per generation |
| ALLOW_PRINT_LABEL_CONTAINER_QUESTION_BLIND_RECEPTION | False | Ask to print container labels in blind reception |
| PRODUCT_LABEL_DEFAULT_FORMAT | (blank) | Item label format |
| DEFAULT_RECEPTION_LABEL_ITEM_REPORT_NAME | STD_RPT_STOCK_LABEL_GS1_128 | Item label report |
| ALLOW_PRINT_LABEL_ITEM_QUESTION_BLIND_RECEPTION | False | Ask to print item labels in blind reception |
| MAX_NUM_LABELS_TO_READ | 1 | Multi-reading max reads per item/container |
| CUTTING_PRINTER | (blank) | Default printer for cutting labels |
| CLIENT_CONTAINER_LABEL_REPORT | STD_RPT_CLIENT_CONTAINER_LABEL_15 | Client container auto-label report |
| CLIENT_CONTAINER_PACKING_REPORT | (blank) | Packing list auto-print report |
## Common Errors
| Error | Cause | Solution |
|-------|-------|----------|
| GS1-128 container label cannot be printed | Container code is not a 14-digit GTIN | Ensure container uses a GTIN-compliant alias |
| Item GS1-128 label not printing | Item has no GS1 alias | Add a GTIN-format alias to the item master |
| Too many label copies blocked | RECEPTION_MAX_NUM_CONTAINER_LABELS_TO_PRINT reached | Raise security limit parameter if legitimate need |
| Cutting label not printing during picking | Cutting profile labeling flags not active | Enable "Labeling cut stock" / "Labeling source stock" in cutting profile |
| Label printed at wrong printer | Printer not configured on stage/dock or equipment | Assign printer via "Assign Printers" wizard on dock/stage, or check equipment printer config |
| Multi-reading fails for specific items | Data unreadable + item has mandatory fields without defaults | Pre-configure default container type, height type; item must have GTIN alias |
## Related
- [[container]] — Container types, LPN management, SSCC codes
- [[product-item]] — Item master, GTIN aliases, logistic attributes shown on 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
- [[stations]] — ETQ (type 58) labeller station, dock/stage printer configuration
- [[parameters]] — All label parameters listed above
wiki_old_13-05-2026/concepts/location.md
+263
View File
@@ -0,0 +1,263 @@
---
title: "Location"
type: concept
sources:
- areas/layout/index.md
- areas/layout/organization.md
- areas/layout/site.md
- areas/layout/location_types/location_types.md
- areas/inventory_management/locations/locations.md
- areas/inventory_management/locations/location_lock_types.md
- areas/inventory_management/locations/locations_features.md
- areas/inventory_management/locations/reports/Locations_errors_traceability.md
- sources/archives/30_Reapprovisionnement_2_sous_entrepots_zone_intermediaire.md
related:
- concepts/container.md
- concepts/stock.md
- concepts/putaway.md
- concepts/replenishment.md
- concepts/count.md
- concepts/defragmentation.md
- concepts/task.md
- concepts/crossdocking.md
- concepts/stations.md
last_compiled: "2026-04-17"
---
# Location
## Overview
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 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.
## Types
### Virtual locations
Virtual locations are automatically created by the WMS configurators and cannot be modified or deleted. They have infinite capacity and no physical constraints. Virtual locations are exclusively used with containers (never loose stock in standard processes).
| Virtual location | Purpose |
|---|---|
| **ASN** | Pre-notified containers awaiting physical receipt. When ERP sends an ASN message, the container is placed here until it arrives at the dock. |
| **Lost_Found** | Containers that are physically lost or whose system location mismatches the physical reality. Operators or the system can send containers here manually. |
| **Mov** | Containers currently in transit through an automatic warehouse (moving on conveyors or AS/RS). |
### Physical location types
Physical locations have concrete capacity, dimension, and storage logic constraints. The type determines the storage strategy and what the system controls.
| Location type | Stores | System controls | Behavior |
|---|---|---|---|
| **Conventional rack (uncontrolled)** | Containers + loose stock | Height, weight, capacity | Direct unit access; no position tracking within location |
| **Conventional rack** | Containers | Height, weight, capacity, position (X/Y) | Direct unit access; full position tracking; supports depth management (automatic warehouses) |
| **Compact mono (Drive-In)** | Containers | Height, weight, capacity, depth | LIFO; one item type per channel; high-density storage |
| **Compact multi (Drive-In)** | Containers | Height, weight, capacity, depth | LIFO; different items per height; used with Pallet Shuttle systems |
| **APS (Automatic Pallet Shuttle)** | Containers | Height, weight, capacity, depth | LIFO only; exclusive to automatic warehouses; satellite cart on AS/RS |
| **APSFIFO** | Containers | Height, weight, capacity, depth | FIFO by default (load one side, unload other); can be closed to LIFO; exclusive to automatic warehouses |
| **Dynamic (gravity)** | Containers | Height, weight, capacity, depth | FIFO; rollers on inclined rails; one item per height; separate load/unload aisles |
| **Pushback** | Containers | Height, weight, capacity, depth | LIFO; containers push back when loaded, fall forward on extract |
| **Cantilever** | Containers + loose stock | Weight, capacity | For long/irregular loads (pipes, profiles, sheets) |
| **Buffer** | Containers + loose stock | Capacity | Intermediate staging; not for final storage; floor-level |
| **Dock** | Containers + loose stock | Capacity | Receipt/shipping docks (3 subtypes: receipt, shipping, or both) |
| **Equipment** | Containers + loose stock | Capacity | On-board or handheld locations (forklifts, carts); includes picking slots for multi-order preparation |
| **Conveyor** | Containers + loose stock | Capacity | E-Commerce module only; transports stock from receive point to carrier dock |
#### Compact sub-types: Pallet Shuttle and APS
The **Pallet Shuttle** is a semi-autonomous cart introduced into a compact channel. It moves containers to the first free position using LIFO or FIFO (configurable when empty). Controlled via WiFi.
The **APS** is a satellite cart integral to the AS/RS stacker crane. It is fully automated, managed by Easy WMS, and exclusively LIFO (or FIFO for APSFIFO).
#### Conventional rack: putaway and extraction errors
In conventional rack and APS locations, if a container physically cannot be deposited or extracted, the system marks a **putaway error** or **extraction error** at the specific position. Affected positions are excluded from future location searches. Errors are cleared manually from the Locations view.
#### Transit buffer between sub-warehouses
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`:
- 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".
- The transport sub-warehouse must be reachable by both equipment groups.
**Routing**:
| Route from | Route to |
|---|---|
| Transport element | Sub-warehouse A (picking) |
| Both equipment groups | Transport element |
| 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.
**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.
## Location coding
Physical locations are coded as: **A** (Aisle) **S** (Side) **X** (Column) **Y** (Row).
Example: `3izq0205` = Aisle 3, left side, column 02, row 05.
Labeling formats depend on rack type:
- **Upright labels**: for compact, cantilever, dynamic, pushback; placed on uprights showing all heights for a column
- **Beam labels**: for conventional, dynamic, pushback; placed on beam at level 1 showing all heights
- **Location labels**: for rack and picking locations; one label per cell
Labels are printed in A4 format from the "Locations" screen or the RF terminal Utilities menu.
## Storage modes
Each physical location has a **storage mode** defining what it can hold:
| Mode | Containers | Loose stock |
|---|---|---|
| Container | Yes | No |
| Stock | No | Yes |
| Container and stock | Yes | Yes (simultaneously) |
| Container or stock | Yes | Yes (but not simultaneously) |
Mode changes are restricted by location type: Rack, APS, and Drive-In locations have fixed modes.
## Storage logics (per location)
Location behavior is governed by logics configured on each location. These control which processes can use the location:
| Logic | Effect |
|---|---|
| Allow putaway | Location is valid for putaway location search |
| Allow replenishment (target) | Valid as destination for replenishment |
| Allow replenishment source | Valid as source stock for automatic replenishment |
| Allow replenishment origin (tense flow) | Valid as replenishment source for tense flow buffer |
| Allow shipping | Stock here is eligible for stock assignment for outbound orders |
| Allow count | Stock here is valid for automatic count processes |
| Allow assignment of item to location | Can be configured as a picking dedicated location (PDL) |
| Allow mixing of container types | Multiple container types can coexist in this location |
| Allow empty containers | Empty containers can be stored here |
| Is crossdocking location | Used to store stock expected to ship soon; included in XD location search |
| Delete empty containers | On/Off/Ask: controls whether empty containers are auto-deleted after extraction |
## Location attributes
Key attributes visible in the "Locations" view:
| Attribute | Description |
|---|---|
| Storage mode | Container / Stock / Container and stock / Container or stock |
| Type | Location type (conventional, compact, buffer, dock, etc.) |
| Rack type | Rack configuration for rack-type locations |
| Work zone | Restricts which equipment can access this location |
| Storage zone | Groups locations for putaway strategy targeting |
| Control digit | Short code for location confirmation (voice/RF terminals) |
| Station | Station this location belongs to (if any) |
| 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 |
| 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 |
| Picking dedicated location | Flag indicating item assignment (PDL) |
| Compact location data | Behavior (LIFO/FIFO), loading sequence, initial FIFO flag |
| Allowed containers quantity | Per-container-type limits (APS locations only) |
| Errors traceability | Link to putaway/extraction error history (rack + APS only) |
## Business rules
- The system will not propose a location that is marked as **full** for automatic putaway.
- **Putaway errors** and **extraction errors** on rack/APS locations exclude those positions from the location search until manually cleared.
- Locking a location propagates immediately to active reserves, assignments, and tasks, potentially canceling or re-releasing them depending on lock type.
- In **compact mono** locations, all containers in the channel must have the same item and logistic attributes.
- In **APS** locations, capacity changes require the location and all sibling locations to be empty.
- **FIFO/LIFO** behavior of pallet shuttle locations can only be changed when the location is empty.
- Container **compaction** on FIFO shuttle locations moves containers toward the unload aisle, freeing space on the load side.
- Stock in a location with an extraction error may not be assignable for shipping; the system will search for alternative stock if a picking task fails.
## Configuration
### Location locks
Lock types are created in `Masters > Lock types`. Each lock type defines which operations remain allowed:
| Lock operation | Effect when disallowed |
|---|---|
| Allow picking | Picking tasks cannot be created for stock here |
| Allow shipping | Stock is excluded from assignment for outbound orders |
| Allow putaway | Location excluded from putaway search |
| Allow counting | Location excluded from count processes |
| Allow moving | No movement tasks for this location |
| Allow replenishment | Replenishment assignments cancelled; picking tasks adjusted |
| Allow reserving | Existing reserves recalculated (priority to highest-priority orders) |
| Allow internal consumption | Manufacturing consumption blocked |
Lock types can be **exclusive** (only one lock at a time) or cumulative (multiple locks allowed). A lock end date is optional; locks can be cleared manually via the Unlock action.
### Storage logic changes
From the "Locations" view, users can modify (PC only):
- Change shipping logic (allow shipping, allow count, allow putaway, picking dedicated, crossdocking flags)
- Change container behavior (allow empty, allow mix types, delete empty)
- Change storage mode (with constraints based on type and current stock)
- Change work zone / storage zone
- Change rack type (requires empty location)
- Change allowed containers quantity (APS only, when empty)
## Interface
**UI path:** "Locations" view in the **"Warehouse"** menu (PC)
**RF terminal:** Label printing via **"Utilities"** menu
### Operations available in the Locations view
| Operation | Hardware | Notes |
|---|---|---|
| Label printing | PC + printer | Range selection; format by label position (beam/upright/location) |
| Container creation | PC | Manually register a physically present container not in WMS |
| Loose stock creation | PC | Creates stock line; treated as stock adjustment |
| Lock / Unlock | PC | Select lock type, optional end date and comment |
| Work zone / Storage zone change | PC | Expands/restricts equipment access |
| Send to Lost & Found | PC | System shows containers in location; physical is empty |
| Extract to PK conveyor | PC | Move containers to picking conveyor |
| Extract to PS (outbound conveyor) | PC | Move containers to outbound conveyor |
| Relocation | PC | Automatic / to aisle / to specific location |
| Mark full / Unmark full | PC | Manual full flag (non-rack locations only) |
| Correct deposit/extraction error | PC | Rack/APS locations only |
| Change FIFO/LIFO behavior | PC or RFT | Empty compact locations with FIFO config only |
| Compacting | PC or RFT | FIFO compact locations with containers stored |
| Item-to-location assignment | PC | Set PDL for a specific item (manual warehouse) |
| Location errors trace | PC | Report of putaway/extraction errors by date range |
## Common errors
| Symptom | Cause | Solution |
|---|---|---|
| Location not offered in putaway | Location is full, locked for putaway, wrong storage zone, or type/capacity mismatch | Check full flag, lock types, storage zone configuration, and container type compatibility |
| Extraction error persists | Container could not be extracted (obstruction); system stops offering this position | Physically resolve obstruction, then use "Correct extraction error" in Locations view |
| Stock shows in WMS but location is physically empty | Container was moved without system update | Use "Send to Lost & Found" to reconcile; investigate transaction history |
| Cannot change FIFO/LIFO | Location is not empty | Empty the location completely first |
| Lock not recalculating reserves | Lock type has "Allow reserving" enabled | Only locks with "Allow reserving" disabled trigger reserve recalculation |
| Cannot change storage mode to Stock | Location has container tasks pending | Cancel or complete tasks first |
## Related
- [[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
- [[putaway]] — putaway strategies target specific locations via zone/type/logic filters
- [[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
- [[defragmentation]] — defragmentation moves stock between locations to consolidate and optimize space
- [[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
- [[stations]] — stations group locations into functional zones for routing and process assignment
wiki_old_13-05-2026/concepts/manual-movements.md
+231
View File
@@ -0,0 +1,231 @@
---
title: "Manual Movements"
type: concept
sources:
- areas/inventory_management/manual_movements/manual_movements.md
related:
- concepts/location.md
- concepts/container.md
- concepts/task.md
- concepts/stock.md
- concepts/stock-adjustment.md
last_compiled: "2026-04-10"
---
# Manual Movements
## Overview
**Manual Movements** allow an operator to inform EasyWMS of the **correct location of a container or stock** when:
- 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.
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.).
---
## Types of Manual Movements
### 1. Moving Stock from One Location to Another
**When:** Loose stock (not in a container) was found in a different location than recorded.
**Restrictions:**
- Cannot move to a location in a different warehouse
- If the stock has locks blocking movement, the operator is prompted to confirm
- Cutting stock (non-consolidating UoM): all stretches at the location must be moved individually and in full; partial moves not allowed if multiple cutting records exist
**Transaction:** `STK.MOVE`
**Interface:**
- RFT: `Utilities > Manual Movement`
---
### 2. Moving Stock from a Location into a Container
**When:** Loose stock recorded at a location was actually placed on a container.
**Restrictions:**
- Cannot move to a container in a different warehouse
- Locks blocking movement prompt confirmation
- Cannot move to/from an ASN container (pre-notified, not yet received)
- Cannot move client stock to a non-client container (or vice versa)
- Cutting stock: same indivisibility restrictions as above
**Transaction:** `STK.MOVE`
**Interface:**
- RFT: `Utilities > Manual Movement`
---
### 3. Moving Stock Between Containers
**When:** Stock was found in a different container than recorded.
**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).
**Movement of client stock** is allowed when there is a matching shipping order.
**Restrictions:**
- Cannot move to a container in a different warehouse
- Cannot move to/from ASN containers
- Cannot move client stock to non-client container (or vice versa)
- Cutting stock: same indivisibility restrictions
**Transaction:** `STK.MOVE`
**Interface:**
- RFT: `Utilities > Manual Movement`
- Workstation: `Workstations > Picking > Others > Move Stock`
---
### 4. Moving Stock Between Containers with Divisions
**When:** Stock was in a division of one container at a PK station and was moved to a division of another container.
**Automatic warehouse only** (picking conveyor). Valid if source/destination stock/container has no active replenishment, picking, or counting tasks.
Client stock movement allowed when matching shipping order exists.
Cutting stock indivisibility restrictions apply.
**Transaction:** `STK.MOVE`
**Interface:**
- Workstation: `Workstations > Picking > Others > Move Stock`
---
### 5. Moving Stock Between Divisions (Same Container)
**When:** Stock within a container with divisions at a PK station was moved from one division to another within the same container.
**Automatic warehouse only** (picking conveyor).
Cutting stock indivisibility restrictions apply.
**Transaction:** `STK.MOVE`
**Interface:**
- Workstation: `Workstations > Picking > Others > Move Stock`
---
### 6. Moving a Container
**When:** A container was found at a different location than recorded in EasyWMS.
EasyWMS updates the container's location record.
**If the container has replenishment assignments:**
- Replenishment source assignments are **canceled**
- Picking tasks that depended on that stock are decremented or canceled (if all assigned stock was in the moved container)
- Affected order lines are re-released for stock re-assignment
**Restrictions:**
- Cannot move an ASN container (pre-notified, not yet received)
- Cannot move to a location in a different warehouse
- If container has movement-blocking locks, operator is prompted to confirm
**Transactions:** `STK.MOVE` + `CON.MOVE`
**Interface:**
- RFT: `Utilities > Manual Movement`
---
### 7. Moving Cutting Stock
Cutting stock (non-consolidating UoM) has special behavior due to its indivisible nature.
**Process:**
1. Operator scans source container/location and item
2. Must enter the **exact length** to move (must match an existing stretch exactly)
3. If the entered length doesn't match any stretch, an error is shown
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.
**Interface:**
- RFT: `Utilities > Manual Move`
---
### 8. Moving Stock from Partitions
**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 move a partition itself, only the stock within it
- Cannot change to a partition in another warehouse
**Transaction:** `STK.MOVE`
**Interface:**
- RFT: `Utilities > Manual Move`
---
## Transactions Summary
| Transaction | Trigger |
|---|---|
| `STK.MOVE` | Any stock location change (all move types) |
| `CON.MOVE` | Container location change (move container type) |
---
## Business Rules
- 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.
- 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.
---
## Interface
| Path | Equipment |
|---|---|
| `RFT > Utilities > Manual Movement` | RFT |
| `Workstations > Picking > Others > Move Stock` | PC (automatic warehouse) |
| `RFT > Utilities > Manual Move` (cutting stock, partitions) | RFT |
---
## Common Errors
| Symptom | Cause | Solution |
|---|---|---|
| "Different warehouse" error | Attempting to move to a container/location in another warehouse | Keep moves within the same warehouse |
| Cannot move ASN container | Container is pre-notified but not yet received | Complete or cancel the reception first |
| Cutting stock length not found | Entered quantity does not match any stretch exactly | Use "List Stock" to see all stretches and select the exact one |
| Picking tasks unexpectedly canceled after container move | Container had replenishment source assignments | Expected behavior; affected lines are re-released for reassignment |
| Cannot move client stock | Target container is not a client container for the same order | Move to a matching client container or complete the shipping process |
---
## Related
- [[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
- [[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
- [[stock-adjustment]] — Complement to manual movements: adjustments correct quantity/UoM/attributes; manual movements correct location
wiki_old_13-05-2026/concepts/mechanical-elements.md
+144
View File
@@ -0,0 +1,144 @@
---
title: "Mechanical Elements — Acronyms, Conveyors, Station Codes"
type: concept
sources:
- sources/archives/Acronymes_elements_mecaniques.md
- sources/archives/Convoyeur_terminologie.md
- sources/archives/Catalogue_TK.md
- sources/archives/Codes_de_station.md
related:
- concepts/stations.md
- architecture/galileo-integration.md
- operations/galileo-simulation.md
- operations/galileo-troubleshooting.md
- modules/pallet-shuttle.md
- modules/aps3d.md
- modules/movirack.md
- modules/agv.md
last_compiled: "2026-04-17"
---
# Mechanical Elements — Acronyms, Conveyors, Station Codes
## Overview
Reference page for the physical hardware vocabulary used in automated Mecalux installations: machine acronyms (ES / EN), conveyor types and their WMS tracking behaviour, miniload (TK) nomenclature, and the station-code matrix across French, Spanish and English. This page is the cross-walk between shop-floor labels and the station types registered in EasyWMS.
## 1. Machine & equipment acronyms (ES → EN)
All Mecalux mechanical acronyms are in Spanish; the translation matters because GALILEO logs, vendor drawings and EasyS labels mix languages.
| Acronym | Español | English |
|---------|---------|---------|
| **AP** | Apilador de Paletas Vacías | Empty Pallet Stacker |
| **APC** | Apilador de Paletas de Cadenas | Chain Pallet Stacker |
| **APR** | Apilador de Paletas de Rodillos | Roller Pallet Stacker |
| **APS** | Carro Satélite Automático / Pallet Shuttle Automático | Automatic Pallet Shuttle |
| **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 |
| **ECDF** | — | Telescopic Fork (belt, double) |
| **EMS** | Sistema electrovía aérea | Overhead Electric Monorail |
| **EP** | Elevador Paletas | Pallet Lift |
| **EPDF** | — | Telescopic Fork (double 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 |
| **LRAB** | Transportador de Rodillos de Acúmulo con Báscula | Scale Roller Conveyor (with weigh-bridge) |
| **LRC** | Transportador de Rodillos recto Continuo | Continuous Roller Conveyor |
| **LRD** | Transportador de Rodillos Oblicuo de salida | Diverting (outlet) Roller Conveyor |
| **LRI** | Transportador de Rodillos Oblicuo de inducción | Angle Induction Roller Conveyor |
| **LRL** | Transportador de Rodillos Libres | Free Roller Conveyor (gravity) |
| **LTM** | Transportador Mixto | Box Transfer / Cross transfer (90°) |
| **LZ** | Lanzadera | Shuttle car |
| **ML-50** | Transelevador Monocolumna (1 caja ≤ 50 kg) | Single-Mast Boxes Stacker Crane |
| **ML-100** | Transelevador Monocolumna (1 caja ≤ 100 kg) | Single-Mast Boxes Stacker Crane |
| **MLB-100Q** | Transelevador Bicolumna (4 cajas ≤ 50 kg) | Double-Mast Boxes Stacker Crane |
| **MT** | Transelevador Monocolumna (paletas) | Single-Mast Pallet Stacker Crane |
| **MTB** | Transelevador Bicolumna (paletas) | Double-Mast Pallet Stacker Crane |
| **PSS** | Pallet Shuttle Semiautomático | Semi-Automatic Pallet Shuttle |
| **PTL** | Pick to Light / Put to Light | Pick-to-Light / Put-to-Light |
| **SGA** | Sistema Gestión Almacenes | WMS |
| **STL** | Sistema de Transporte Ligero | Miniload (light transport system) |
| **STP** | Sistema de Transporte Pesado | Automated Warehouse / Pallet stacker cranes |
| **TC** | Transportador de Cadenas | Chain Conveyor |
| **TG** | Transportador Giratorio | Turntable Conveyor |
| **TM** | Transportador Mixto | Cross Transfer (rollers + chains) |
| **TR-15** | Transportador de Rodillos (europaleta) | Roller Conveyor (Euro pallet) |
> The complete list (~100 acronyms including station codes CME/PIE/PK/PS…) lives on [Confluence](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000652529673). Cross-reference with section 3 (Station codes) below.
## 2. Conveyor terminology & WMS tracking behaviour
Conveyor type drives whether EasyWMS can reliably track a container on the conveyor, and therefore how it should be modelled in EasyS.
| 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 |
| **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 |
| **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) |
| 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
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.
| Type | Code FR | Description FR | Code ES | Code EN | Description EN |
|------|---------|----------------|---------|---------|----------------|
| 0 | MAG | Magasin | ALM | AIS | Aisle |
| 1 | ML / TK | Miniload / Transstockeur | TRASLO | STC | Stacker crane |
| 2 | PK | Poste de picking | PK | PK | Picking station |
| 3 | PIE | Poste d'identification d'entrées | PIE | EIP | Entry Identification Post |
| 4 | PS | Poste de sortie | PS | SC | Shipping Conveyor |
| 5 | REAC | Poste de reconditionnement | REAC | REAC | Reconditioning station |
| 7 | REJ | Poste de rejet | RECH | REJ | Rejection post |
| 9 | TE / ME | Table d'entrée au magasin | ME | IC | Input Conveyor |
| 10 | TS / MS | Table de sortie du magasin | MS | OC | Output Conveyor |
| 11 | MU | Table de recherche d'emplacement | MU | MU | Location Conveyor |
| 13 | EMP / APL | Empileur | APL | STK | Stacker |
| 14 | NAV / LANZ | Navette | LANZ | SHU | Shuttle |
| 16 | TP / MP | Table de préparation | MP | MP | Picking Preparation Station |
| 18 | PKE | Poste d'entrée au PK | PKE | PKE | Picking Entry Post |
| 20 | ET | Station de transit | ET | TS | Transit Station |
| 21 | CME | Poste de contrôle de table d'entrée | CME | ICS | Input Control Station |
| 42 | RET | Poste de rétention de conteneurs | RET | RET | Container Retention Post |
| 53 | PCS | Poste de contrôle de séquençage | PCS | SCP | Sequencing Control Point |
| 54 | PB | Buffer de proximité | PB | PB | Proximity Buffer |
| 55 | ECB | Buffer de conteneurs vides | ECB | ECB | Empty Container Buffer |
| 58 | ETQ | Étiqueteuse | ETQ | ETQ | Labeller |
| 62 | LIFT | Élévateur | LIFT | LIFT | Lift |
> The full station catalogue (all 37+ types including Dock/Stage/Kit/Cutting/AGV/Workzone/Decision…) lives in [Stations & Routes](stations.md).
## 4. Miniload nomenclature (TK / ML)
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)
- **EPDF** = Extracteur Pelle Double Fond — **1 charge**, double-depth rack
- **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
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
- [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 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)
wiki_old_13-05-2026/concepts/order-inbound.md
+251
View File
@@ -0,0 +1,251 @@
---
title: "Inbound Order (Receipt Order)"
type: concept
sources:
- areas/receptions/reception_admin/receipt_orders.md
- areas/receptions/reception_admin/receipt_order_type.md
- areas/receptions/reception_admin/receipt_order_class.md
- areas/receptions/reception_admin/receipt_order_supervise.md
- areas/receptions/reception_admin/receipt_order_supervise.md
- areas/receptions/reception_admin/views/view_receipt_order.md
- areas/receptions/reception_admin/views/view_receipt_order_lines.md
- areas/receptions/reception_admin/unload_receipt.md
- areas/ERP/receipts/ror.md
- areas/ERP/receipts/roc.md
- areas/ERP/receipts/rof.md
- areas/ERP/receipts/asn.md
- areas/ERP/receipts/aso.md
- areas/ERP/receipts/ref.md
- areas/ERP/requests/str.md
- areas/inbounds/index.md
related:
- concepts/reception.md
- concepts/container.md
- concepts/product-item.md
- concepts/stock.md
- concepts/putaway.md
- concepts/order-outbound.md
- concepts/crossdocking.md
- concepts/erp-interface.md
last_compiled: "2026-04-10"
---
# Inbound Order (Receipt Order)
## Overview
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.
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.
## Types
Receipt orders (and their associated receipts) are categorized by type, which conditions how they are processed:
| 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 |
| **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.
## Structure
### Order header
| Field | Description |
|---|---|
| **Code** | Unique inbound order code |
| **Status** | Current lifecycle status (see Lifecycle section) |
| **Type** | Supplier / Return / Transfer |
| **Class** | Optional sub-classification of the order |
| **Owner** | Owner of the stock (mandatory when Owner Extension / Billing / 3PL Portal module installed) |
| **Document** | Delivery note or reference document from supplier/carrier |
| **Supplier** | Supplier code (Supplier type only) |
| **Account** | Customer account code (Return type only) |
| **Source** | Source warehouse code (Transfer type only) |
| **Allow lines auto-creation** | If enabled, unexpected items received against this order are accepted and added as new lines |
| **Enable container label printing** | All receipts from this order will automatically print GS1-128 container labels during receipt |
| **Enable stock label printing** | All receipts from this order will automatically print GS1-128 item labels during receipt |
| **Single receipt** | Only one receipt is auto-created for this order (use when all stock arrives in one delivery). Requires `AutoCreateReceptionFromRecOrder` parameter active. |
### Order lines
Each line identifies the expected item/container and quantity:
| Field | Description |
|---|---|
| **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 |
| **Owner** | Owner of the expected stock |
| **Quantity** | Expected quantity |
| **UoM** | Unit of measure (usually base UoM; can be a presentation if packaging is known) |
| **Logistic attributes** | Pre-set lot, expiration date, etc. (unusual; typically captured at physical reception) |
| **Stock status** | Quality status that will be automatically applied to received stock (receiving status) |
| **Number of ERP parcels** | Informational parcel code from ERP; used to reconcile which packages were received |
| **Excess percentage** (`LneTrmExceedPerc`) | Maximum percentage above expected quantity that can be received on this line |
## Lifecycle
```
[ERP sends ROR or manual creation]
↓
WAITING
(order created; no receipt started)
↓
[First receipt created] → RECEPTION PENDING
↓
[First stock physically received] → RECEIVING
↓
[Some lines complete, others not] → PARTIALLY RECEIVED
↓
[All lines fully received] → COMPLETE
↓
[Manually or automatically closed] → CLOSED
↓
[No activity within validity period] → EXPIRED
[Canceled before any receipt] → CANCELED
```
**ERP is notified** of every status transition via **ROC** message.
**Closing** can happen:
- Automatically when all lines are fully received and the `AutoCloseInboundOrder` parameter is active
- Manually from the Receipt orders view
- Forced close even with partial receipt
**Cancellation** is only allowed when no stock has been received (status: Waiting or Reception Pending).
**Modifications** allowed while in Waiting or Reception Pending:
- Add new lines
- Edit expected quantity (up or down; down to received qty completes the line)
- Edit UoM (only if no stock received on that line)
## ERP integration
### Messages: ERP → WMS
#### ROR — Receipt Order Request
Creates, modifies, or cancels receipt orders.
| Operation | Description |
|---|---|
| `C` / `S` | Create new receipt order (header + lines) |
| `U` | Update existing order (add/modify lines, edit quantities) |
| `D` (standard) | Cancel receipt order (only if nothing received) |
| `D` + `CloseReceiptOrder=True` | Close completed/partially received order |
Key ROR fields:
- `RorCode`: unique order code
- `RorType`: Supplier / Return / Transfer
- `SupplierCode` / `AccountCode`: for Supplier or Return types
- `Document`: delivery note reference
- `RecDatDate`, `RecDatDockR`, `RecDatContainers`: estimated arrival date, dock, and container count (informational)
- `EnableLabelPrinting`: auto-print container labels during receipt
- `EnablePrintingItemLabel`: auto-print item labels during receipt
- `AllowAutoCreateLines`: accept unexpected stock
- `SingleReceipt`: one receipt per order
- Line `LneTrmExceedPerc`: over-receive tolerance percentage
- 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
Pre-notifies containers expected at the warehouse. Containers are created in the virtual ASN location.
| Variant | Description |
|---|---|
| With receipt order | Pre-notified container linked to a ROR |
| Without receipt order | Pre-notified container only (blind ASN) |
| Stacked (lifted) containers | Hierarchy of stacked containers pre-notified together |
| Matched containers on dummy | Matched group based on virtual slave container (dummy, no weight) |
| Matched on labeled slave | Slave container is labeled (has code) |
| Matched on non-labeled slave | Slave container has no code; stock linked to inner containers |
| With divisions | Container with division type and per-division stock lines |
| With exclusive reserve for outbound order | Pre-notified container's stock reserved for specific SOR on receipt |
| With exclusive reserve for route | Pre-notified container's stock reserved for a route stop |
| With reserve and expiry deadline | Reserve creation deadline if order/route doesn't exist at receipt time |
ASN key fields: `ContainerCode`, `ContainerType`, `ReceiptOrderCode`, `NumExpectedContainers`, `ExpectedOutboundOrderCode` / `ExpectedRouteCode`
### Messages: WMS → ERP
#### 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
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).
- **ROF02**: order data and stock only. Receipt closings sent separately via REF message. Use ROF02 in installations with frequent grouped receipts (one receipt associated with multiple orders).
ROF01/ROF02 key fields per line: `LneItemCode`, `LneOwnerCode`, `LneQtyExpected`, `LneQtyReceived`, `LneQtyFree`, `LneQtyUoMCode`.
#### 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)
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
- `Operation D`: remove user status (unlock by lot or by receiving status)
WMS responds with one or more **STC** messages confirming the modified stock.
## Parameters
| Parameter | Effect |
|---|---|
| `AutoCreateReceptionFromRecOrder` | If active, a receipt is automatically created when a ROR is received. Combined with `SingleReceipt`, creates exactly one receipt per order. |
| `AutoCloseInboundOrder` | If active, the order automatically closes when all lines are fully received |
## Interface
| Function | Hardware | Menu path |
|---|---|---|
| Receipt orders view | PC | Receiving → Receipt orders |
| Receipt order lines view | PC | Receiving → Receipt order lines |
| Manual creation | PC | Receiving → Receipt orders → New |
| Supervision | PC | Receiving → Receipt orders → Supervise |
### Available operations
| Operation | Conditions |
|---|---|
| Create manual receipt order | Any time; complete creation before receipts can start |
| Add lines to existing order | Order must not be Completed, Closed, or Archived |
| Edit expected quantity | Order in Waiting or Reception Pending; if stock received, quantity ≥ received qty |
| Edit UoM on line | Order in Waiting or Reception Pending; no stock received on line |
| Close receipt order | Stock already received; status Complete/Partially received/Reception pending with no active receipt |
| Cancel receipt order | No stock received; status Waiting or Reception Pending |
## Common errors
| Symptom | Cause | Solution |
|---|---|---|
| Receipt order cannot be canceled | Stock already received against it | Close the order instead; cancel remaining unreceived quantities |
| Unexpected stock received but not accepted | `Allow lines auto-creation` not enabled on order | Enable the flag on the order header, or create the missing line manually before reception |
| Over-receive blocked | `LneTrmExceedPerc` = 0 or not set | Request ERP to update the line with a tolerance percentage; or adjust quantity manually |
| ROC not sent | WMS-ERP integration configuration issue | Check ERP communication settings and ROC message configuration |
| Transfer receipt order has no ASN | Source warehouse did not close shipping order (Transfer type) | Verify source warehouse has closed the transfer shipping order; ASN is created automatically |
| ASN reserve not created at receipt | Expected outbound order did not exist and deadline passed | Check `ExpectedReserveValidDate`; re-create reserve manually on the outbound order |
| Order stuck in Receiving | Receipts associated to the order are still open | Close or finalize all associated receipts first |
## Related
- [[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
- [[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
- [[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
- [[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
wiki_old_13-05-2026/concepts/order-outbound.md
+426
View File
@@ -0,0 +1,426 @@
---
title: "Outbound Order (Shipping Order)"
type: concept
sources:
- areas/shipping/shipping_admin/shipping_order.md
- areas/shipping/shipping_admin/shipping_order_type.md
- areas/shipping/shipping_admin/shipping_order_class.md
- areas/shipping/shipping_admin/index.md
- areas/shipping/shipping_admin/shipping_orders_monitorize.md
- areas/shipping/shipping_admin/shipping_order_creation.md
- areas/shipping/shipping_admin/shipping_order_cancel.md
- areas/shipping/shipping_admin/shipping_orders_close.md
- areas/shipping/shipping_admin/stock_assign.md
- areas/shipping/shipping_admin/stock_reserve.md
- areas/shipping/shipping_admin/order_release.md
- areas/shipping/shipping_admin/sequencing.md
- areas/ERP/shipping/sor.md
- areas/ERP/shipping/soc.md
- areas/ERP/shipping/sof.md
- areas/ERP/shipping/soc.md
- areas/ERP/shipping/lof.md
- areas/ERP/shipping/wof.md
- areas/ERP/shipping/sor.md
- sources/archives/12_Articles_alternatifs.md
- sources/archives/18_ASN_DirectTransfer.md
- sources/archives/19_ASN_Transfer.md
- sources/archives/32_Fusion_commandes_Merge.md
related:
- concepts/shipping.md
- concepts/picking.md
- concepts/stock.md
- concepts/container.md
- concepts/task.md
- concepts/replenishment.md
- concepts/order-inbound.md
- concepts/crossdocking.md
- concepts/erp-interface.md
last_compiled: "2026-04-17"
---
# Outbound Order (Shipping Order)
## Overview
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.
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.
## Types
The type determines the destination, the process, and how Easy WMS handles the stock:
| Type | Description | Stock destination |
|---|---|---|
| **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 |
| **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 |
| **Transfer between sub-warehouses** | Maintain configured stock levels in a sub-warehouse | Internal sub-warehouse |
Shipping orders also have a **class** for additional process customization (different consolidation behaviors, label types, document formats).
## Structure
### Order header
| Field | Description |
|---|---|
| **Priority** | Preparation priority: Urgent / High / Normal / Low / Very Low. Lower number = higher priority. Determines task sequence and equipment assignment order. |
| **Type** | Client / Return / Transfer / Direct Transfer / Manual / Kits / Desk / Transfer between sub-warehouses |
| **Class** | Optional sub-classification for process customization |
| **Owner** | Owner of the stock (mandatory with Owner Extension / Billing / 3PL Portal modules) |
| **Account / Supplier / Destination warehouse** | Attribute varies by type: account for Client, supplier for Return, warehouse for Transfer |
| **Document** | Delivery note or reference number |
| **Staging location** | Consolidation location where picked stock is assembled before shipment; for grouped orders, this is where ungrouping and distribution occurs |
| **Ship expired stock** | If true, only expired stock is eligible for this order; lines with undated items will never complete |
| **Follow sequence** | Enforces line-number order during shipping for ordered delivery note verification |
| **Preparation state** | Visual indicator of progress (reserved, stock failures, assigned, tasks pending/running, ready to load, loaded, shipped) |
| **% completed** | Percentage of ordered quantity prepared and loaded |
| **Transport** | Carrier + transport type (informational) |
| **Route** | Route code and stop number |
| **Delivery address** | Customer delivery address (printed on delivery note and transport document) |
| **Planning** | Release/shipping/loading dates; planned dock; number of packages |
| **Preparation** | Consolidation station; container types for packages; label/packing-list print settings |
### Order lines
| Field | Description |
|---|---|
| **Line number** | Unique within the order; used for sequenced shipping |
| **Item + Owner** | Identifies the SKU to ship |
| **Container** | Request specific container; if combined with item, forces stock from that container |
| **Required quantity + UoM** | Quantity in specified presentation. If `LneQtyUoMRequired = 1`, only that presentation is accepted. |
| **Preferred presentation** (`LneTrmPrefUoMCode`) | As much as possible shipped in this presentation; fall back to others if insufficient |
| **Stock status preferences** | Preferred/required/rejected status; preferred container type |
| **Critical line** (`LneTrmCritical`) | All-or-nothing: this line must be completely prepared or nothing on this line is prepared |
| **Required line to ship** (`LneTrmRequired`) | If this line cannot be fully shipped, nothing in the entire order is prepared |
| **Allow excess** (`LneQtyAllowExcess`) | Allow shipping more than requested if exact quantity cannot be allocated |
| **Alternative items** | Substitute items when stock fails (mode from shipping profile, or explicit via `LneAltItmCode`) |
| **Logistic attributes** | Request stock with specific lot, serial, expiry date, quality, color, caliber, etc. |
| **Max lots** (`LneMaxLots`) | Maximum number of distinct lots across all stock assigned to this line |
| **Days of life** | Minimum days of life required on stock assigned to this line |
| **Expire date after** (`LneAttExpDate`) | Only stock expiring after this date is eligible |
| **Client codes** | Customer item code and line code (informational; for delivery documents) |
| **Costs** | Line cost and currency (informational) |
## Lifecycle
```
[ERP sends SOR or manual creation]
↓
CREATING
(manual creation in progress)
↓
WAITING
(ready; no preparation started)
↓
[Optional: stock reserved] → RESERVED
↓
[Order released] → RELEASED
(stock assigned; tasks generated)
↓
[First task executed] → WORKING / IN PREPARATION
↓
[Paused by user] → PAUSED (assigned stock held)
[Stopped by user] → STOPPED / WAITING (assigned stock released)
↓
[All stock prepared + loaded] → AUTO-CLOSE → CLOSED
[Partial close triggered] → partial SOF sent → remains active
[Force close with stock failures] → CLOSED (partial)
↓
ARCHIVED
[Any time before CLOSED]
→ CANCELED (no stock shipped)
```
**SOC messages** are sent by WMS to ERP on every status transition.
### Status details
| Status | Available operations |
|---|---|
| **Creating** | End creation, Close, Change priority, Group, Fuse, Route association |
| **Waiting** | Reserve, Assign, Release, Cancel, Close (partial), Force close, Change priority, Group, Fuse, Paper pick, Assign to equipment/dock |
| **Reserved** | Reserve, Assign, Release, Cancel, Close, Force close, Cancel reserve |
| **Released** | Re-release, Pause, Stop, Cancel, Close, Force close, Change priority |
| **Working** | Pause, Stop, Cancel, Close, Force close, Change priority |
| **Paused** | Release (restart), Stop, Cancel, Close |
| **Stopped/Waiting** | Release (restart), Cancel |
| **Closed** | Archive |
## Business rules
- 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.
- **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.
- **Expired stock**: orders normally exclude expired stock. If `ShipExpiredStock = True`, only expired stock is used. Lines on items without expiry dates cannot be prepared in this mode.
- **Reserve recalculation** on stock lock: if locked stock had reserves, the system re-prioritizes reserves for the highest-priority orders that reserved earliest.
- Orders stopped via Pause retain their assigned stock; orders stopped via Stop release their assigned stock.
- **Partial closes**: a SOF message is sent for each partial close. Each SOF includes only the lines closed in that partial. The order remains active after a partial close.
## ERP integration
### Messages: ERP → WMS
#### 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.
| Operation | Fields |
|---|---|
| `S` (create) | `SorCode`, `Priority`, `SorType`, `Site`, `EnableReplenishment`, `PrpPackingLocation`, `PlnAssignedDock` |
| `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 `D` | Cancel specific line |
Key SOR fields:
- `SorType`: Customer / Return / Transfer / DirectTransfer
- `Priority`: Urgent / High / Normal / Low / VeryLow
- `EnableReplenishment`: triggers automatic replenishment of PDLs for items in the order
- `LneTrmRequired`: required-to-ship line flag
- `LneTrmCritical`: critical line flag
- `LneQtyAllowExcess`: allow over-allocation
- `LneQtyUoMRequired`: presentation is required (not just preferred)
- `LneTrmPrefUoMCode`: preferred presentation
- `LneMaxLots`: maximum lot count for this line
- `LneTrmAlternative`: activate substitute items from master
- `LneAltItmCode` + `LneAltItmQttyFrom` + `LneAltItmQttyTo`: explicit alternative item and ratio
- `LneQtyReserve`: quantity to pre-reserve for this line
- `ShipExpiredStock`: ship only expired stock
- `LneTrmStaReq` / `LneTrmStaRejC` / `LneTrmStaPref`: required/rejected/preferred stock status
- `LneAttExpDate`: minimum expiration date for assigned stock
- `PrpContTypeRequired`: required client container type (SOR02)
### Messages: WMS → ERP
#### SOC — Shipping Order status Change
Sent on every status transition of a shipping order.
| Status reported | Trigger |
|---|---|
| `Release` | Order released for preparation |
| `StockFailure` | Stock cannot be fully assigned to one or more lines |
| `Working` | First task executed; preparation has begun |
| `Waiting` / `Secured` | Order stopped (stock may or may not be released) |
| `Paused` | Order paused |
| `Closed` | Order closed (fully or partially) |
| `Canceled` | Order canceled |
Note: Grouped/fused orders do not report status changes for the grouped order or its components during grouped preparation.
#### 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.
- **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)
- `ClosingNum`: closing sequence number (for partial closes)
- `PrpContainers`: containers shipped in this closing
- Per line: `LneDItemCode`, `LneDQtyShipped`, `LneDQtyUoMCode`, `LneDClientContCode`, `LneDAttributesLine`
- VAS fields (SOF01 only): `LneVASsTemplate`, `LneVASsPreparedQuantity`, `LneVASsComment`
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
Sent when a load is finalized (truck loading complete). References shipping orders in the load.
## Parameters
| Parameter | Effect |
|---|---|
| `AutoCloseOutboundOrder` | Automatically closes a shipping order when all ordered quantities are prepared and loaded |
| `EnableReplenishment` (per SOR or order) | Triggers automatic replenishment of PDLs for items in the order when released |
## Interface
| Function | Hardware | Menu path |
|---|---|---|
| Shipping orders view | PC | Shipping → Shipping orders |
| Shipping order lines view | PC | Shipping → Shipping order lines |
| Manual creation | PC | Shipping → Shipping orders → New |
| Monitoring | PC | Shipping → Shipping orders (status column + preparation state) |
| Waves / Groups / Fusions management | PC | Shipping → Waves / Groups |
| Routes management | PC | Shipping → Routes |
| Loads management | PC | Shipping → Loads |
| Paper pick | PC + Printer; RFT or CB reader to confirm | Shipping → Shipping orders → Paper pick |
### Available operations from Shipping orders view
| Operation | Notes |
|---|---|
| Create shipping order | Manual; complete creation before any actions |
| Reserve stock | Pre-reserve specific stock or as much as possible |
| Assign stock | Run stock assignment (selects specific stock; unassigns previous if re-run) |
| Release | Triggers assignment + task generation; ERP notified via SOC |
| Release by sub-warehouse | Partial release per sub-warehouse |
| Pause | Retains assigned stock; pauses task generation |
| Stop | Releases assigned stock; ERP notified |
| Cancel | Remove order entirely; all prepared stock unassigned |
| Close | Confirm shipped quantities; send SOF to ERP |
| Force close | Close with stock failures (partial shipment) |
| Change priority | Update at any active status |
| Assign to equipment | Restrict picking preparation to specific equipment |
| Assign dock/stage | Set shipping dock or staging area |
| Increase/decrease line quantity | With restrictions if stock already prepared/shipped |
| Cancel line | All statuses while order active |
| Stop lines | Release stock from individual lines |
| Print documentation | Delivery note, packing list, differences report |
| Archive | After closure |
## 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.
**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 :
1. Receive onto the buffer or the equipment.
2. Scan the container (no other validation required).
3. An **ASO01** file is generated automatically.
> 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.
> ⚠️ 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)
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.
**Key differences vs `<DirectTransfer>`:**
| Aspect | `<Transfer>` | `<DirectTransfer>` |
|---|---|---|
| Inbound order at destination | **Yes** (auto-created) | No |
| Receipt mandatory at destination | Yes | No |
| Authoritative ERP message | **`ROF02`** (at inbound close) | `ASO01` per container |
| Deletion feedback | `ASK01` on partial-close of inbound order | `ASK01` on container deletion |
| Re-inspection of goods | Possible at destination | Skipped by design |
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.
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).
### Eligibility
**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:
- In another merge
- In a group
- In a wave
- Assigned to a route
### Process
| Step | Action | Initiator |
|---|---|---|
| 1 | Create orders targeting the same address | ERP/client |
| 2 | Trigger the **"Fusion"** action | Operator (or auto if customised) |
| 3 | Prepare stock (picking, packing, loading) | Operator |
| 4 | Close the merged order → packages produced | Operator |
| 5 | Delivery generated | System |
The merged order owns its own code, status and shipping date and is treated as any standard order. **ERP traceability stays individualised per source order** (each original SOR produces its own SOC/SOF lineage).
### Configuration
```xml
<Delivery>
<DlvShareDeliveries>true</DlvShareDeliveries>
</Delivery>
```
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.
### Limitations & anomalies
- Merge is possible only from `Waiting`.
- Once picking has started, merge cannot be undone.
- Returns and SAV are treated individually.
| Anomaly | Standard behaviour |
|---|---|
| Partial stock-out | Merge flips to **`Postponed`** until full availability |
| Cancel before picking | Order can be removed from the merge |
| Cancel during picking | Manual intervention required |
| Cancel after packaging | Un-pack, then re-process |
| Address change | Order must be excluded from the merge |
| Carrier error | Stock blocked in the packing zone; status fixed manually |
Client responsibilities: consistency of SOR addresses / ExtraData, `DlvShareDeliveries` config, business rules for which orders to merge, anomaly handling.
## Alternative Items (SOR flag + SOF feedback)
At order line level, the SOR(01|02) can enable the substitute-item feature :
```xml
<LneTerms>
<LneTrmAlternative>true</LneTrmAlternative>
</LneTerms>
```
The WMS uses the shipping-profile **substitution mode** (Partiel / Substitution / Tout ou rien) + the article-level "Ajouter Alternatif" table to decide what gets picked. The SOF then reports the outcome via the `<LneDIsAlternative>` flag on each `<LneDetail>` (see [Product / Item](product-item.md#alternative--substitute-items) for the full matrix).
## Common errors
| Symptom | Cause | Solution |
|---|---|---|
| Order stuck in Released (no tasks created) | All required items missing from PDLs; no stock assignable | Check stock assignment results; trigger replenishment or manual stock movement |
| Stock failure on line | Insufficient stock for the requested item/attributes | Check stock levels; review lot/status restrictions in SOR line; consider substitute items |
| Cannot modify line (UoM or attributes) | Stock already prepared or shipped for this line | Only quantity can be reduced; attributes locked once prepared |
| SOF not sent | WMS-ERP integration issue or order closed without ERP connection | Check communication configuration; retry closing via forced resend if available |
| Order cannot be canceled | Stock already prepared (tasks completed) | Undo preparation (un-prepare from consolidation or truck loading view), then cancel |
| Required-to-ship line prevents all preparation | Required line has stock failure | Resolve stock failure on required line; or remove the required-to-ship flag (if ERP allows) |
| Excess stock prepared on line | Over-allocation due to containerized/indivisible stock | Use the "Return excess" operation before closing, or configure `LneQtyAllowExcess = 0` |
| Route not found | Route code in SOR does not exist in WMS | Create or sync route in Easy WMS; check RUT message from ERP |
## Related
- [[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
- [[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
- [[task]] — release generates Picking and Shipping tasks; task priority driven by order priority
- [[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
- [[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)
wiki_old_13-05-2026/concepts/parameters.md
+311
View File
@@ -0,0 +1,311 @@
---
title: "System Parameters"
type: concept
sources:
- areas/parameters.md
- areas/inventory_management/parameters.md
- areas/slotting/parameters.md
- areas/ecommerce/parameters.md
- areas/pallet_shuttle/agv_ps/parameters.md
- areas/aps3d/parameters.md
- areas/multi_carrier_shipping/parameters.md
- areas/store_fulfillment/parameters.md
related:
- concepts/container.md
- concepts/reception.md
- concepts/picking.md
- concepts/shipping.md
- concepts/count.md
- concepts/stock-adjustment.md
- concepts/defragmentation.md
- concepts/replenishment.md
- concepts/cutting-stock.md
- concepts/labels.md
last_compiled: "2026-04-10"
---
# System Parameters
## 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 are defined at the **organization level** but can be **customized per warehouse**. A warehouse-level value overrides the organization default.
Two categories:
- **System parameters**: Created automatically by the system. Cannot be deleted. User sets warehouse-level value.
- **Custom parameters**: Created by implementers from the web interface. Can be created, modified, and deleted. Used for custom behaviors.
## Parameter Attributes
| Field | Description |
|-------|-------------|
| Code | Unique parameter identifier |
| Of the system | True = system-created; False = custom |
| Default value | Developer-assigned baseline (all warehouses start with this) |
| Has custom value | Whether any warehouse has overridden the default |
| Class | Process category (where it's used) |
| Scope | Web or RF |
| Type | Data type (Boolean, Text, Integer, Decimal, Enum) |
| Minimum / Maximum value | Bounds for numeric parameters |
| Possible values | Enum list of allowed values (restricts user input) |
| Custom values by warehouse | Per-warehouse override values |
**Interface:** View "Parameters" in the menu "Configuration" (PC).
---
## Core Easy WMS Parameters
All parameters below are from the main Easy WMS parameter set (areas/parameters.md) unless otherwise noted.
### Reception Parameters
| Parameter | Default | Description |
|-----------|---------|-------------|
| ALLOW_CREATE_RECEPTION | False | During reception, allow creation of receipts on-the-fly if operator can't find an existing one. Creates a receipt without lines; stock is added as received. |
| ALLOW_DIFFERENT_QTTY_RECEPTION_COMPLETE_CONTAINER | False | For containers with same item but variable quantity (e.g., UoM = kg), allows user to select whether received quantity is variable or fixed. |
| AutoCreateReceptionFromRecOrder | False | Automatically create a receipt when a receipt order arrives from ERP. |
| AutoCloseReception | False | Auto-close a receipt when all expected stock has been received. |
| AutoArchiveClosedReception | False | Auto-archive a receipt when it is closed. |
| MAX_RECEPTIONS_TO_CLOSE_JOB | 5 | Maximum number of receptions to close per job execution in the auto-close process. |
| RECEPTION_DEFAULT_CONTAINER_TYPE | Manual | Default container type in receptions (except single-reference, which uses receipt profile). |
| RECEPTION_DEFAULT_HEIGHT_TYPE | Manual | Default container height type. If empty, user must always select. |
| RECEPTION_FORBID_MOVE_FROM_ASN | False | Whether rejecting a pre-notified container from RFT should move it from ASN virtual location. If False, ASK message not sent to ERP. |
| RECEPTION_ALLOW_RECEIVE_NOT_PRODUCED_STOCK | 0 | Number of days to add to receipt date to accept a production date as valid. |
| RECEPTION_NUM_DAYS_PRODUCTION_DATE_MARGIN | 0 | Days to add to receipt date to accept a production date as valid. |
| RECEPTION_ASN_CONFIRM_ALL_STACK_CONTAINERS | False | On ASN receptions of stacked containers: ask confirmation from all containers in hierarchy (except dummies and slaves). |
| RECEPTION_ASN_SHOW_CONFIRMATION_DIALOG | False | In pre-notified container reception: offer possibility to modify stock of a container. |
| RECEPTION_MAX_NUM_CONTAINER_LABELS_TO_PRINT | 1000 | Maximum container labels printable per receipt (security limit). See also [[labels]]. |
| NUM_COPIES_RECEPTION_LABEL | 1 | Number of label copies per container during receipt. |
| CREATE_ALIAS_ON_RECEPTION | False | Allow creation of item aliases during reception. Operator can indicate a read code is an alias of an expected item. |
| USE_EXCLUSIVE_RESERVE_STRICT_MODE | False | True: reject pre-notified containers whose exclusive reservation targets don't exist in system. False: receive anyway. |
| CONFIRM_EXCLUSIVE_RESERVE_ASSIGNMENT | (blank) | True: reception operator chooses exclusive reserve target when multiple possible. False: system auto-assigns. |
| SET_COMPLETE_QUANTITY | False | Allow user to set complete container quantity during reception (for variable-quantity UoM containers). |
| RECEPTION_ASN_CONFIRM_ALL_STACK_CONTAINERS | False | In ASN reception of stacked containers: ask confirmation from all hierarchy except dummies/slaves. |
| MAX_NUMBER_DAYS_ADJUSTMENT_RECEIVED_STOCK | 3 | Max days after receipt date during which received stock can be modified. (Min: 0, Max: 7) |
### Label / Printing Parameters
| Parameter | Default | Description |
|-----------|---------|-------------|
| DEFAULT_RECEPTION_LABEL_CONTAINER_REPORT_NAME | STD_RPT_CONTAINER_LABEL_GS1_128 | Report name printed for mono and multi-reference containers in reception. See [[labels]]. |
| DEFAULT_RECEPTION_LABEL_ITEM_REPORT_NAME | STD_RPT_STOCK_LABEL_GS1_128 | Report name printed for items in reception. See [[labels]]. |
| CONTAINER_LABEL_DEFAULT_FORMAT | (blank) | Default container label format: `1x-A6`, `1x-GS1-128`, `20x(105x29)-A4`, `2x(175x135)-A4`, `33x(75x25)-A4`, `4x(105x148)-A4`. |
| PRODUCT_LABEL_DEFAULT_FORMAT | (blank) | Default item label format: `A6`, `105x29`, `175x135`, `105x148`, `75x25`. |
| CLIENT_CONTAINER_LABEL_REPORT | STD_RPT_CLIENT_CONTAINER_LABEL_15 | Container label format auto-printed when picking container is unloaded into a stage with configured printer. |
| CLIENT_CONTAINER_PACKING_REPORT | (blank) | Report for auto-printing client container packing list when downloaded to a configured stage. |
| CUTTING_PRINTER | (blank) | Default printer for cutting stock labels during picking. See [[cutting-stock]]. |
| ALLOW_PRINT_LABEL_CONTAINER_QUESTION_BLIND_RECEPTION | False | In blind reception: ask user if they want to print GS1 labels for received containers. |
| ALLOW_PRINT_LABEL_ITEM_QUESTION_BLIND_RECEPTION | False | In blind receipt: ask user if they want to print GS1 labels for received items. |
| MAX_NUM_LABELS_TO_READ | 1 | Max barcode readings per loose stock or container (multi-reading). Value 1 = disabled. Min: 1, Max: 30. |
### Container / LPN Parameters
| Parameter | Default | Description |
|-----------|---------|-------------|
| CONTAINER_CHECK_CODE_GS1LABEL | False | Validate SSCC code conforms to GS1 standard (18 digits with check digit) on container create/edit. |
| CONTAINER_CHECK_CODE_REPEATED_FOR_LABELS | True | Validate container code is unique across stations, locations, and item aliases on create/edit. |
| ASK_FINAL_STACK_LOCATION | True | In container stacking: ask user for final location of new container block. If not confirmed, block stays at base container's location. Only for non-client containers in ground locations. |
| UNSTACK_ON_STAGE | False | In unstacking: always unstack in a stage (True), or unstack at initial stacked container location if allowed (False). |
### Picking Parameters
| Parameter | Default | Description |
|-----------|---------|-------------|
| CONFIRM_PICKING_EXCESS | False | Ask operator to confirm when picking more than ordered quantity. |
| RF_PICKING_CONFIRM_LOCATION | True | RF picking: require operator to scan location label to confirm they're at the correct picking location. |
| ALLOW_CONFIRMATION_ON_PLACEMENT | False | Ask picking operator to confirm the location/container of their equipment where they deposit collected items. |
| EMPTY_PICKING_LOCATION_QUESTION | False | Ask operator at last picking task if the location/container is empty (assists inventory). |
| EMPTY_PICKING_LOCATION_STOCK_ADJUST | False | If EMPTY_PICKING_LOCATION_QUESTION is active: allow stock adjustment when location/container is empty. If False: mark for review only. |
| FILTER_BEFORE_PICKING_IN_ORDER_PICKING | False | In Order Picking: show shipping order code filter before listing tasks. Partial code match supported; multiple nested filters. |
| WORKWAVES_ALLOW_SELECTION | False | True: display available waves for operator to select (ordered by user/equipment assignment, urgency, release date). False: system proposes most-priority wave automatically. |
| PICKING_ALLOW_STARTING_DECISION_ON_WAIT_FOR_REPLENISHMENT | False | Allow RF operator to start picking preparation even if they may need to wait for replenishment. |
| PICKING_ALLOW_UNLOADING_ON_LOCATION_ON_WAIT_FOR_REPLENISHMENT | False | Allow RF operator to place unloading container in stage/dock if they only have tasks waiting for replenishment. |
| PICKING_ALLOW_WAITING_ON_LOCATION_ON_WAIT_FOR_REPLENISHMENT | False | RF pickers instructed to wait at picking location when out of stock (vs skip and continue). |
| PICKANDPASS_ALLOW_READ_DIFFERENT_CONTAINER | False | Pick-and-Pass: allow operator to scan a container other than the one proposed by the system. |
| PTL_AUTOMATIC_CONTAINER_UNLOAD | False | PTL warehouses: auto-unload container when confirming order destination in PTL. |
| PTL_WORKING_MODE | PickToLight | PTL mode: `PickToLight` (racks only have PTLs) or `PutToLight` (racks and equipment both have PTLs). |
| ALLOW_ZONE_SELECTION_FOR_TASKS | False | Allow RF filtering of tasks by zone (aisle, sub-warehouse, or work zone) before starting. |
| EQUIPMENT_PICKING_LOCATIONS_MODE | Manual | Picking location assignment mode: `Manual` (user decides), `Prompt` (auto with confirmation), `Auto` (auto without confirmation). |
| PAPERPICK_AUTO_PRINTER | (blank) | Printer for automatic paper picking sheet printing. |
| PAPERPICK_REPORT | STD_RPT_OUTBOUNDORDER_PAPER_TASK | Report name for paper picking sheet. |
| PREPARE_PAPER_PICK_BY_DEFAULT | False | Mark new shipping orders as "prepare on paper" by default. |
| BATCH_PREFIXCODE | Batch | Batch code prefix for paper-based preparation. |
| Sorder_Num_Equipments | 1 | Number of equipment teams that can work simultaneously on the same shipping order per work zone. (Min: 1) |
| OUTBOUND_ORDER_SPLITTING_IF_NOT_FULLY_COBOT | False | With Cobot module: allow same order lines to be split between manual and Cobot picking stations. |
### Shipping / Order Management Parameters
| Parameter | Default | Description |
|-----------|---------|-------------|
| ALLOW_CHANGE_LOCATION_ON_UNGROUP | False | Ungrouping process: allow user to change location assigned to stock of the shipping order being ungrouped. |
| ALLOW_CHANGE_LOCATION_ON_UNLOAD | False | Allow unloading loose stock to a different location than the one designated. |
| ALLOW_CHANGE_ROUTE_STOPS | False | Allow modifying the stop of a shipping order in a route without removing it from the route. |
| ALLOW_MERGE_DIFFERENT_ACCOUNT | False | Allow fusing orders with different accounts. Note: orders with Strict FEFO accounts cannot be grouped. |
| ALLOW_MULTI_UNIT_UNGRUOUP | False | Allow multi-unit ungrouping. |
| AUTO_MERGE_ORDERS | False | Auto-merge orders sharing the same delivery address. |
| AutoCloseLoadedOutboundOrders | False | Auto-close orders when the full prepared quantity is at the assigned dock or shipped. |
| AUTOCLOSE_LOADED_ROUTES | False | Auto-close routes when the full quantity of all composing orders is at the assigned dock. |
| AutoArchiveClosedOutboundOrders | False | Auto-archive shipping orders once closed. |
| AUTOARCHIVE_CLOSED_ROUTES | False | Auto-archive closed routes. |
| ArchiveClosedInboundOrder | False | Auto-archive receipt orders when closed. |
| AutoCloseInboundOrder | False | Auto-close receipt order when all associated receipts are closed. |
| MAX_AUTORELEASED_OUTBOUNDORDERS | 0 | Max orders in Released or In Preparation status; if exceeded, auto-release stops. |
| MAX_AUTORELEASED_ROUTES | 0 | Max routes releasable simultaneously. |
| MaxTimeForMaximizingShipping | 20 | Max time in milliseconds to search container combinations for maximizing shipping. |
| OUTBOUND_ORDER_BLIND_VERIFICATION | False | Hide stock information from user during shipping order stock check (packaging process). |
| OUTBOUND_ORDER_PACKINGLIST_AUTOPRINT | False | Auto-print delivery note when a shipping order is closed. |
| OUTBOUND_ORDER_PACKINGLIST_DEFAULT_PRINTER | (blank) | Printer name for auto delivery note printing. |
| OUTBOUND_ORDER_PACKINGLIST_NUM_COPIES | 1 | Number of copies for auto delivery note printing. |
| OUTBOUND_ORDER_PACKINGLIST_REPORT_NAME | STD_RPT_OUTBOUNDORDER_BYITEM | Report type for auto delivery note. |
| MANUAL_OUTBOUND_ORDER_PREFIX | MAN | Prefix for manual order code (combined with counter). |
| AUTOPRINT_DESK_ORDER_DELIVERY_NOTE | False | Auto-print desk order delivery note. |
| RF_ASSIGN_PACKORBUFFERORDOCK | False | Auto-assign stage or dock to shipping orders with no destination when containers are unloaded there. |
| RF_SHIP_CHECK_DOCK | False | Require user to scan dock location during truck load/unload per container/package/loose stock line. |
| UNGROUPED_OUTBOUND_ORDERS_SAME_USER_EXTRACTION | False | After ungrouping at an ungrouping station, same user automatically performs extraction without re-selecting in UI. |
| UNLOAD_CREATE_PRODUCT_LOCATION | True | When placing in a picking-dedicated location: create a dedicated picking location. Container → max=1, min=0; Stock → min=0, max=quantity. |
### Stock / Inventory Parameters
| Parameter | Default | Description |
|-----------|---------|-------------|
| BALANCE_AISLE | False | Enable aisle balancing in the putaway location search process. |
| NUM_EVENTS_PER_PARTIAL_COMMIT | 20 | Events confirmed per block in the event confirmation process. Affects performance with large volumes. (Min: 1) |
| REASSIGN_STOCK_VIA_SUBSCRIPTIONS | True | True: stock reassignment via event subscriptions. False: via periodic job. |
| MAX_ORDERS_STOCK_FAILURE_JOB | 10 | Maximum outbound orders reassigned per execution of the periodic stock reassignment job. |
### Replenishment Parameters
| Parameter | Default | Description |
|-----------|---------|-------------|
| MAX_GROUPS_PROCESSED_DYNAMIC_REPLENISH_JOB | 100 | Max item groups for which dynamic picking locations and replenishment tasks are generated per job run. See [[replenishment]]. |
| MAX_REPLENISHED_PL_ROUTINE_JOB | 100 | Max product locations for which replenishment tasks are created per job run. (Min: 0) |
| REPLENISH_LEVEL_PERCENT_PRODUCT_LOCATION | 20 | When counting, if previous parameter active: creates picking dedicated location with quantity = counted stock × this percentage. (Min: 0, Max: 100) |
| OPTIMIZE_DYNAMIC_PL_USE | False | During dynamic picking, once empty locations exhausted: allow creating item assignments in locations already having other picking dedicated items. |
| CONFIRM_REPLENISH_EXCESS | False | Ask operator confirmation when replenishing more than expected quantity. |
### Defragmentation Parameters
| Parameter | Default | Description |
|-----------|---------|-------------|
| MAX_DEFRAG_TASKS | 10 | Maximum defragmentation tasks in execution per aisle simultaneously. See [[defragmentation]]. |
| MAX_OPTIMIZATION_DEFRAG_CHANNEL | 3 | Maximum channels to defrag simultaneously per aisle. 0 = only MAX_DEFRAG_TASKS is used. |
| MAX_DEFRAG_ATTEMPT | 5 | Maximum attempts to defragment a container for shipping. |
### Voice Parameters
| Parameter | Default | Description |
|-----------|---------|-------------|
| VP_MultipleValuesSegregatedLocationCodeConfirmation | 1 | Location identification in voice processes: 1=system requests location code, 2=single sentence with aisle/side/column/row, 3=confirmation at each stage of the route. |
| VP_PartialReadingContainerCode | 0 | Voice: identify containers by last n digits (right to left). 0=full code. If multiple containers share last n digits, full code is requested. |
| VP_PartialReadingOrderCode | 0 | Voice: identify shipping orders by first n (negative) or last n (positive) digits. 0=full code. Range: -10 to 10. |
### Return Reception Parameter
| Parameter | Default | Description |
|-----------|---------|-------------|
| RETURN_RECEPTION_PREFIX | RET | Prefix for return type receipt codes. |
---
## Module Parameters
### Slotting Module Parameters
| Parameter | Default | Description |
|-----------|---------|-------------|
| SLOTTING_ANALYSYS_DEMAND | 50% | Minimum % of days in analyzed period item must have been sold to recommend repositioning. Options: 25%/50%/75%. |
| SLOTTING_AUTO_AREA_TYPE | False | Continuous slotting execution level: full warehouse, sub-warehouse, or zone. |
| SLOTTING_AUTO_AREA_CODE | False | False: single recommendation for whole warehouse. True: separate recommendation per zone/sub-warehouse. |
| SLOTTING_AUTO_DAYS | 30 | Days of demand history used for continuous slotting recommendation. (Min: 1) |
| SLOTTING_AUTO_COVERAGE_DAYS | 7 | Coverage days to cover demand through continuous slotting. |
| SLOTTING_AUTO_DOCK | (blank) | Shipping dock for continuous slotting measurements. |
| SLOTTING_AUTO_LOCATIONS | DedicatedPicking | Scope of continuous slotting: `Picking` (all picking locations) or `DedicatedPicking` (dedicated only). |
| SLOTTING_AUTO_MIN_PROFIT | (blank) | Minimum estimated benefit for continuous slotting to trigger notification. (Min: 0) |
| SLOTTING_BUFFER_LOCATION | (blank) | Buffer location used for slotting process. Set by "Select buffer" action in Slotting view. |
| SLOTTING_CONTAINER_REPLENISH | False | Replenish with containers whenever possible (vs. stock). |
| SLOTTING_COST_HOUR | 20 | Operator cost per hour for slotting process cost calculations. (Min: 0) |
| SLOTTING_GOLDEN_ZONE | 1.5 | Maximum height (m) for golden zone priority picking locations. (Min: 0) |
| SLOTTING_MAX_PL_PER_ITEM | 1 | Maximum picking dedicated locations per item. (Min: 1) |
| SLOTTING_REPLENISH_LEVEL | 0 | Replenishment capacity % of picking dedicated locations. (Min: 0, Max: 100) |
| SLOTTING_VELOCITY | 5 | Average equipment speed in m/s (or ft/s) for slotting calculations. (Min: 0) |
| SLOTTING_AUTO_COMMIT_DELETE | 1000 | Lines in memory during file analysis. Recommendations: small org (≤15K lines) = 1000; medium (≤100K) = 15000; large = 100000. |
### eCommerce Module Parameters
| Parameter | Default | Description |
|-----------|---------|-------------|
| ECOMMERCE_RECEPTION_ALLOW_AUTOSELECTION | False | Auto-select the best receipt for each item received (vs. manual selection). |
| ECOMMERCE_RECEPTION_ALLOW_MULTIQUANTITY | False | Allow receiving more than one unit of an item at a time. |
| ECOMMERCE_RETURN_ALLOW_AUTOSELECTION | False | Auto-select best return for each item received. |
| ECOMMERCE_RECEPTION_MAX_SECONDS_TO_CONFIRM | 30 | Max seconds after entering an item before operator must confirm cart/container/conveyor destination. Prevents multi-operator conflicts. (Min: 1, Max: 3600) |
### AGV / Pallet Shuttle Module Parameters
| Parameter | Default | Description |
|-----------|---------|-------------|
| PS_MAX_MINUTES_BATTERY_FULL_LOAD | 300 | Minutes since PS charging started for system to consider battery at 100%. (Min: 0) |
| PS_MIN_MINUTES_BATTERY_LOAD | 90 | Minimum minutes charging before system considers PS has sufficient charge to operate. (Min: 0) |
### APS3D Module Parameters
| Parameter | Default | Description |
|-----------|---------|-------------|
| APS3D_LOCATION_SHARE | False | Allow more than one APS3D to access the same channel simultaneously. |
| APS3D_AISLE_OFFSET | 0 | Aisle limit offset for container coordinate calculations (decimal). |
| APS3D_CONTAINERS_GAP | 0 | Distance between containers in the same APS channel (same for all container types). |
| APS3D_SHUTTLE_WIDTH | 0 | Width of an APS3D shuttle (decimal). |
| APS3D_WALL_OFFSET | 0 | Wall (closure) limit offset for container coordinate calculations (decimal). |
| APS3D_CHARGE_STATION_OFFSET | 0 | Charge station limit offset for container elevation calculation when charge station is at location. |
| APS3D_MAX_COMPAQ_CHANNELS | 3 | Maximum channels with simultaneous compaction tasks. |
| APS3D_MAX_DEFRAG_CHANNELS | 3 | Maximum channels with simultaneous defragmentation tasks. |
### Multi-Carrier Shipping Module Parameters
| Parameter | Default | Description |
|-----------|---------|-------------|
| ALLOW_REJECT_AND_UNDO_PACKAGES | False | Allow package preparation rejection or undo in truck load process. |
| AUTO_MERGE_ORDERS | False | Auto-merge shipping orders sharing the same delivery address. |
| OUTBOUND_ORDER_BLIND_VERIFICATION | INFORMED VERIFICATION | Packaging verification mode: `BLIND VERIFICATION` (operator reads items until done, then comparison) or `INFORMED VERIFICATION` (each item compared as read, list always available). Single-unit orders always confirm the item. |
| PACKAGING_ALLOW_MIX_CARRIER | (blank) | Allow mixing packages from different carriers in the same container during manual package movement. |
| PACKAGING_AUTO_CLOSE_DELIVERY | True | Auto-close deliveries vs. manual closure. |
| PACKAGING_AUTO_MOVE_PACKAGES | True | During package unloading: auto-move directly to carrier container if open one exists (no destination confirmation). |
| PACKAGING_CARRIER_MODE | MANUAL | Carrier dock confirmation: `AUTO` (auto-move to carrier dock), `MANUAL` (user confirms carrier code), `UNLOAD` (user indicates location, then Carrier Verification process confirms destination). |
| PACKAGING_CONFIRM_LABEL | True | Confirm tracking code on carrier labels of packages. |
| PACKAGING_MAX_NUM_PACKAGES_ERR | (blank) | Max packages in packaging process before error generated. |
| PACKAGING_MAX_NUM_PACKAGES_WARN | (blank) | Max packages before confirmation requested. (Min: 1) |
| PACKAGING_MODE | CHOOSE_NUM_PACKAGES | Packaging confirmation mode: `ONE_PACKAGE` (all delivery stock in 1 package), `CHOOSE_NUM_PACKAGES` (user specifies number), `CAPTURE_STOCK` (user identifies stock per package). |
| PACKAGING_PRINT_LABEL_CLOSED_PACKAGE | True | For incomplete delivery packaging: ask operator to close package and print label, or keep open and postpone printing. |
---
## Cross-Reference: Parameters by Wiki Page
Parameters mentioned in other wiki pages:
| Parameter | Referenced In |
|-----------|--------------|
| MAX_DEFRAG_TASKS, MAX_OPTIMIZATION_DEFRAG_CHANNEL, MAX_DEFRAG_ATTEMPT | [[defragmentation]] |
| MAX_GROUPS_PROCESSED_DYNAMIC_REPLENISH_JOB, MAX_REPLENISHED_PL_ROUTINE_JOB, REPLENISH_LEVEL_PERCENT_PRODUCT_LOCATION | [[replenishment]] |
| CUTTING_PRINTER | [[cutting-stock]], [[labels]] |
| DEFAULT_RECEPTION_LABEL_CONTAINER_REPORT_NAME, DEFAULT_RECEPTION_LABEL_ITEM_REPORT_NAME, PRODUCT_LABEL_DEFAULT_FORMAT, CONTAINER_LABEL_DEFAULT_FORMAT, NUM_COPIES_RECEPTION_LABEL, RECEPTION_MAX_NUM_CONTAINER_LABELS_TO_PRINT, ALLOW_PRINT_LABEL_* | [[labels]], [[reception]] |
| AutoCloseReception, AutoCreateReceptionFromRecOrder, RECEPTION_* | [[reception]], [[order-inbound]] |
| WORKWAVES_ALLOW_SELECTION, PTL_WORKING_MODE, PAPERPICK_REPORT, Sorder_Num_Equipments | [[picking]] |
| OUTBOUND_ORDER_PACKINGLIST_*, AUTO_MERGE_ORDERS, AUTOCLOSE_LOADED_ROUTES | [[shipping]], [[order-outbound]] |
| PS_MAX_MINUTES_BATTERY_FULL_LOAD, PS_MIN_MINUTES_BATTERY_LOAD | modules/pallet-shuttle |
| APS3D_* | modules/aps3d |
| SLOTTING_* | modules/slotting |
| ECOMMERCE_* | modules/ecommerce |
| PACKAGING_*, ALLOW_REJECT_AND_UNDO_PACKAGES | modules/multi-carrier |
## Related
- [[reception]] — ALLOW_CREATE_RECEPTION, RECEPTION_ASN_*, AutoCloseReception, label printing params
- [[picking]] — WORKWAVES_ALLOW_SELECTION, PTL_WORKING_MODE, FILTER_BEFORE_PICKING, RF_PICKING_CONFIRM_LOCATION
- [[shipping]] — OUTBOUND_ORDER_PACKINGLIST_*, AUTO_MERGE_ORDERS, AutoCloseLoadedOutboundOrders
- [[replenishment]] — MAX_GROUPS_PROCESSED_DYNAMIC_REPLENISH_JOB, REPLENISH_LEVEL_PERCENT
- [[defragmentation]] — MAX_DEFRAG_TASKS, MAX_OPTIMIZATION_DEFRAG_CHANNEL
- [[cutting-stock]] — CUTTING_PRINTER
- [[labels]] — All label format and printer parameters
- [[count]] — REPLENISH_LEVEL_PERCENT_PRODUCT_LOCATION, NUM_EVENTS_PER_PARTIAL_COMMIT
wiki_old_13-05-2026/concepts/picking.md
+480
View File
@@ -0,0 +1,480 @@
---
title: "Picking"
type: concept
sources:
- areas/shipping/shipping_manual/index.md
- areas/shipping/shipping_auto/index.md
- areas/shipping/shipping_auto/direct_picking.md
- areas/shipping/shipping_auto/grouped_picking.md
- areas/shipping/shipping_auto/negative_picking.md
- areas/shipping/shipping_manual/picking_tasks.md
- areas/shipping/shipping_manual/picking_order.md
- areas/shipping/shipping_manual/wave_picking.md
- areas/shipping/shipping_manual/picking_ptls.md
- areas/shipping/shipping_manual/index_cutting_stock.md
- areas/shipping/shipping_manual/paper_pick.md
- areas/shipping/pick_and_pass/index.md
- areas/shipping/pick_and_pack/index.md
- areas/shipping/shipping_admin/stock_assign.md
- areas/shipping/shipping_admin/stock_assign_strategies.md
- areas/shipping/shipping_admin/waves_creation.md
- areas/shipping/shipping_picking_manual/picking_cutting_stock.md
- areas/shipping/shipping_picking_manual/cutting_stock_delegate.md
- areas/shipping/shipping_picking_manual/cutting_stock_integrated.md
- custom/analyse_fonctionnelle.md
- sources/archives/02_Strategie_assignation_vidage_bacs.md
- sources/archives/03_Reapprovisionnement_lors_picking.md
- sources/archives/11_Preparation_papier.md
- sources/archives/26_Utilisation_chariots_emplacement.md
- sources/archives/31_Picking_Manuel.md
- sources/archives/Bases_fonctionnement_robotique_EasyWMS.md
- sources/archives/Configuration_EasyS.md
- sources/archives/Configuration_SmartUI.md
- sources/archives/Tests_Miniload_Gateway.md
related:
- concepts/shipping.md
- concepts/replenishment.md
- concepts/container.md
- concepts/stock.md
- concepts/reception.md
- architecture/galileo-integration.md
- operations/galileo-simulation.md
last_compiled: "2026-04-17"
---
# Picking
## Overview
Picking is the process of extracting stock from warehouse locations to fulfill shipping orders. In EasyWMS, picking encompasses: finding assignable stock (stock assignment), planning task execution (waves/groups), executing physical extraction (RFT, voice, PTL, paper, or automatic conveyor), and delivering picked stock to the shipping dock or staging area.
Picking occurs in two warehouse types:
- **Manual warehouse**: operators with RFT/voice/PTL/paper follow a picking path through aisle locations
- **Automatic warehouse**: containers are extracted by the TMS and brought to a picking conveyor (PK station) where operators pick stock from them into client containers on preparation zones (MP)
Both environments share the same underlying stock assignment logic. The execution layer is different: manual warehouse operators go to the stock; automatic warehouse stock comes to the operator (goods-to-person).
## Stock Assignment
Before any picking task can be generated, EasyWMS must assign specific stock to shipping order lines through the **stock assignment** process.
### Stock Eligibility Conditions
Stock is only assignable if:
- Item, status, UoM, and logistic attributes match the order line requirements
- Stock is in the same warehouse as the shipping order
- Stock state allows moving + picking/shipping (or replenishment origin if it has a picking dedicated location)
- No active count task on the location or container
- Not already part of an in-process replenishment task (unless certain conditions apply)
- Location/station allows picking/shipping; aisle not locked; no extraction errors at current or previous depths
- Not already assigned to another line or prepared for another order
- Exclusive reserves are respected (reserved stock is shipped first; additional stock assigned for any shortage)
### Assignment Strategies
Stock assignment strategies are sequenced and filter/sort eligible stock according to criteria:
| Strategy | Description |
|---|---|
| Efficiency: minimize movements before logic | Prioritize stock that can be fulfilled in fewest movements (prefer single-location assignments over multi-location) |
| Efficiency: empty locations before logic | Prioritize stock that would leave locations empty (maximize space recovery) |
| Logic before efficiency (empty) | Respect item shipping logic (FEFO, FIFO, LIFO) first; use empty-location efficiency as tiebreaker |
| Logic before efficiency (min movements) | Respect shipping logic first; use minimize-movements efficiency as tiebreaker |
| Ship only complete containers | Only assign full containers (matching container type + conversion); use picking for remainder |
| Maximize shipping | Find combination of containers that covers ordered quantity as closely as possible; pick remainder |
| Assign containers in movement | (Automatic warehouses) Assign stock from containers currently moving toward a PK station |
| By sub-warehouse + presentation | Multiple strategies per sub-warehouse/UoM combination (e.g., boxes from sub-WH A, loose units from sub-WH B) |
| By threshold | Switch sub-warehouse based on ordered quantity exceeding a threshold |
| Strict FEFO | Do not ship stock with an earlier expiration than already-shipped stock for the same item+account |
**Priorities** (applied before the main criterion):
- Prioritize shipping tasks over picking (minimize picking at cost of logistics order)
- Prioritize containers in movement (maximize automatic warehouse cycles)
- Prioritize complete containers for picking (empty "peaks" before starting new containers)
- Prioritize picking dedicated locations (always pick from PDL first)
- Prioritize general storage locations (prefer storage locations over PDL to avoid triggering replenishment)
Strategies can be configured globally for the warehouse or per item (via the item's **shipping profile**), which overrides the global strategy for that item.
### "Vidage de bacs" Efficiency Mode
Mecalux France has documented an efficiency mode dedicated to **emptying bins / locations** (FR : *vidage de bacs*), configured via `Configuration → Stratégies d'Assignation de Stock` :
- **Mode d'efficacité** : `Vidage de bacs`
- **Logique d'efficacité** : `Après l'efficacité`
Runtime workflows involved :
| Workflow | Role |
|---|---|
| `StockAssignProcess_CalculateOutboundLogicAndEfficiency_PR` | Chooses between logic-first and efficiency-first branches |
| `StockAssignProcess_CalculateEfficiencyMode_PR` | Executes the workflow matching the selected efficiency mode |
| `StockAssignProcess_CalculateEfficiencyModeToEmpty_PR` | Orders available stock by priority-to-empty according to the configured parameters ; stock is then consumed one record at a time until the requested quantity is reached |
The ordering logic lives in the code activity **"Order stock when none location is emptied"**.
### Assignment by Excess
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
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.
| Mode | Description | Hardware |
|---|---|---|
| **Automatic tasks** | System instructs operator to pick highest-priority order tasks following picking route; loads equipment to capacity | RFT |
| **Picking tasks** | Operator executes only picking tasks, ordered by priority then release date | RFT |
| **Shipping tasks** | Operator executes only shipping tasks (full container moves) | RFT |
| **Order picking** | Operator selects specific orders to prepare; executes shipping tasks for selected orders in priority order along picking path | RFT |
| **Manual preparation** | Operator manually selects the order and the containers to ship | RFT |
| **Manual picking** | Operator creates an ad hoc picking order at the terminal (item + quantity); system releases it and operator executes it immediately | RFT |
| **Wave picking** | Operator prepares orders released in waves; at each return to warehouse, new orders are assigned up to equipment capacity | RFT |
| **Paper picking** | Operator receives printed picking lists, annotates issues; results entered later via PC or RFT (see "Paper Picking Workflow" below) | PC/RFT + printer |
| **Pick-to-light (PTL)** | Operator enters preparation area; PTL devices illuminate to indicate quantity per location | PC/RFT/PTL |
| **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):
- 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
**Pick and Pass** (warehouses with automatic conveyors): goods-to-person model for loose stock. Sub-warehouses receive LPNs via automated transport; operators at workzone stations perform picking then release LPN back to transport. Decision stations route LPNs to correct sub-warehouse by reading pending tasks.
**Pick and Pack**: picking and packaging happen simultaneously; operators pick directly into final shipping cartons. Prepackaging modes available (see [Shipping](shipping.md) for details).
**Desk orders**: stock order from an in-warehouse retail desk; operators pick and deliver directly to desk for on-site customer sale.
**Zone filtering**: operators can filter tasks to a specific aisle, sub-warehouse, or work zone.
### Manual Picking (create order at RFT)
"Picking Manuel" lets the operator create an outbound order directly from the RFT when there is no upstream ERP push. Useful for desk sales, emergency replenishments, or one-off internal moves.
**Flow (RFT):**
1. Enter the **outbound code** (a default is proposed)
2. Choose the **shipping dock**
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)
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`.
- **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)).
### 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
- 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:**
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 |
|---|---|
| Code | Scanned during picking and packing |
| Storage location | **Mandatory** |
| Division type | If empty → the cart behaves as one slot |
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.
- 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".
**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.
### Paper Picking Workflow
Paper picking is used when RF coverage is missing, when a customer wants a printed bon de préparation, or as a fallback mode.
**Prerequisites.** Grant the users three rights via `Permissions des groupes d'utilisateurs → Web → Sorties/Ordres de Sortie` : **Préparer avec FR**, **Générer lot**, **Imprimer préparation de commande papier**.
**Standard flow.**
1. **Release the outbound order** (normal release).
2. Click **"Préparer Préparation de commande papier"**.
3. Check that a **staging buffer or dock is assigned** to the order, then click **Generate batch** (*Générer un lot de préparation*).
4. Print the bon de préparation via **"Imprimer préparation de commande papier"**.
5. The picker performs picking on paper, annotating differences.
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.
### Picking Incidences (Manual Warehouse)
During picking, issues are recorded when containers are not where expected or extraction is blocked:
- **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.
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) |
|---|---|---|
| `PICKING_ALLOW_WAITING_ON_LOCATION_ON_WAIT_FOR_REPLENISHMENT` | Operator is warned "Possible wait for replenish" and can choose to replenish themselves, adjust stock, or skip | `ExecutePicking_WaitForReplenishment_UI` |
| `PICKING_ALLOW_STARTING_DECISION_ON_WAIT_FOR_REPLENISHMENT` | Operator can **refuse** an outbound order that contains tasks waiting for replenishment (from the picking-tasks menu) | `Outbound_ObtainPickingTask_ExecuteTask_UI_v1` → `ExecutePicking_IncreaseReplenishPriorityAndGetIfCanDoTask_PR` → `Helper_ParameterAsBoolean_PR` → `Outbound_ObtainPickingTask_ConfirmWaitForReplenish_UI` |
| `PICKING_ALLOW_UNLOADING_ON_LOCATION_ON_WAIT_FOR_REPLENISHMENT` | Operator can **store** the client container instead of depositing it at the destination when tasks remain blocked on replenishment | `Expedition_FinishExpedition_GetShowStoreButton_PR` (checks parameter + container full + remaining picking tasks) |
Operator flow for the third parameter :
1. After doing all pickable tasks, press **Finir** (`ExecutePicking_SelectOriginLocation_UI`)
2. The deposit screen appears (`Expedition_FinishExpedition_ShowLocationToUnload_UI`)
3. Press **Stocker** (`Equipment_Unload_ContainerUnloadOnUnknownLocation_UI_V2`)
4. When the order is resumed later, the stored client container can be reused (`Outbound_SelectContainerToCreate_UI`)
**Undo preparation**: unassigns a specific stock line from the order it was prepared for (returns stock to assignable pool).
**Undo excesses**: guided removal of over-picked stock from shipping orders (due to quantity changes or line cancellations after preparation).
**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)
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.
The PK station must be assigned to the shipping order along with at least one preparation zone. Multiple MPs per PK allow parallel order preparation.
### PK / MP setup and assignment mode
Configuration of picking + preparation pairs (robotics-specific, from EasyS + SmartUI):
- **Picking station** (EasyS): add a conveyor with role **Picking**, create a **Workstation** to drive it from SmartUI, define routes (where stock can arrive from, where it leaves to)
- **Preparation tables** (EasyS routes):
- **Manual** route from picking table → preparation tables
- **Galileo** route from preparation tables → output table
- **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
- **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
**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
For detailed bring-up in simulation and the "Store container" + "Liberate" test flow, see [Galileo Simulation](../operations/galileo-simulation.md).
### Direct Picking (Phase by Phase)
1. **Confirm container on conveyor**: operator scans SSCC of arriving container (or auto-confirmed if configured). Tasks are sorted: in-process → round number → negative picking → consolidation at origin → creation date → task number.
2. **Confirm preparation zone + destination container**: system assigns MP to the order. If no container exists on the MP, operator creates one (scan or auto-generate SSCC). If no MP is accessible, system selects dock/stage/consolidation station as destination.
3. **Confirm item + logistic attributes**: operator scans item (or auto-confirmed). System checks family restrictions and filters logistic attributes as required.
4. **Enter picked quantity**: operator enters quantity (or confirms with barcode scan, one-scan-one-unit, or one-scan-N-units). PTL illuminates at the MP with required quantity. Decimal quantities handled in two-pass confirmation on PTL.
5. **Enter picking weight** (if item has weight control): mandatory step; checks min/max weight per presentation.
6. **Confirm destination**: operator confirms the MP (only if MP is the destination; auto-confirmed if one container on zone and auto-confirm enabled).
7. **Close client container**: system checks if container should be closed (no more tasks for the order at this PK). Closure is mandatory when remaining tasks have lower stackability or MP is automatic. PTL function button can trigger closure. On closure: container label + packing list printed if configured.
**Alternative actions at any phase:**
- Remove from conveyor → container to Lost & Found, tasks canceled
- Return → postpone, move container to nearest PIE or MU (reject station if none)
- Skip task (if multiple tasks on container)
- Select another destination MP
- Close client container early
- Stock not found → delete from container (adjustment), decide next action
- Insufficient stock → adjust actual quantity
- Check to review → set review lock, continue
### Grouped Picking (Automatic Warehouse)
Grouped picking replaces individual picking when multiple shipping orders share stock from the same source container. Instead of making N individual passes, the operator picks the total needed quantity once and distributes it across N preparation zones, each illuminated by a PTL.
**Conditions for grouped picking:**
- PK configured to allow grouped picking
- Original task has a single-location preparation zone
- PK has exactly one PTL-equipped location (PTL + controller both enabled)
- Item has no logistic attribute capture or weight capture requirements
- Compatible tasks: same stock requirements, PK assigned, single-location MP with PTL, no existing stock from a different order on the MP
Grouped picking is incompatible with: automatic quantity confirmation, barcode scanning mode, automatic destination confirmation.
**Grouped picking phases:**
1. Confirm container on conveyor (same as direct)
2. Create picking containers on each compatible MP
3. Confirm item + logistic attributes; system deselects tasks for which there is insufficient stock
4. PTLs illuminate simultaneously on all compatible MPs → operator picks total, distributes to each zone by pressing PTL
5. Close containers as each is completed
### Negative Picking
When a container is over-stocked relative to what is needed for the current task (e.g., container holds 50 units but task only needs 10), negative picking extracts the **excess** and places it in a new container that is returned to the warehouse. This corrects the container's stock to match what the task required.
### Container Closure and Return
After all picking tasks for a shipping order are completed at the PK:
- PK is unassigned from the order
- Operator confirms container disposition (return to warehouse or remove)
- 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
In Pick and Pack warehouses, operators pick stock directly into the final shipping carton (client container). Two integration levels:
| Mode | Description |
|---|---|
| **Without prepackaging** | Operator picks item by item into shipping carton at location |
| **With prepackaging (individual orders)** | System calculates optimal carton allocation before picking; operator receives pre-defined container labels |
| **With prepackaging (grouped orders)** | Same, but for multiple orders picked simultaneously |
| **Single parcel** | One-item, one-carton picking; minimal steps |
| **Different presentations** | System handles mixed UoM in the same carton |
| **Mixed scenario (SP + consolidation)** | Single-parcel orders consolidated into shared shipping containers |
Prepackaging calculation:
- Uses item dimensions + carton types to determine optimal packing
- Can come from ERP (prepackaged by supplier) or calculated by EasyWMS
- User-driven prepackaging: operator selects container type interactively
## Stock Assignment Transactions and Events
| Event | Transaction |
|---|---|
| Picking task executed | `STK.PICKING` |
| New client container created at MP | `CON.CREATE` |
| Client container closed | `CON.COC` |
| Container movement to dock/stage (virtual route) | `CON.MOVE`, `STK.MOVE`, `CON.LOAD`, `STK.LOAD` |
## Picking Path Design
The picking path is the optimal traversal order of locations for picking tasks. Path efficiency depends on:
- **Warehouse design**: single bi-directional aisle vs. zigzag (in-out separate aisles)
- **Narrow aisles**: one direction, pick both sides crossing the aisle
- **Wide aisles**: two-way with each side directed differently; each shelf projects to nearest aisle
- **Sub-warehouse local paths**: Pick and Pass allows per-sub-warehouse picking paths
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 priorities
Each shipping order carries a priority that determines task sequence:
| Priority | Relative urgency |
|----------|-----------------|
| **Urgent** | Highest — processed first in all queues |
| **High** | Above normal |
| **Normal** | Default |
| **Low** | Below normal |
| **Very Low** | Lowest — processed last |
Priorities are set per order (from the ERP or manually) and apply across all picking and shipping task generation.
### Order quantity states
Each shipping order line tracks quantities at four execution stages:
| Quantity type | Meaning |
|---------------|---------|
| **Assigned** | Stock selected and reserved from inventory (assignment done, not yet picked) |
| **Prepared** | Stock physically picked and placed in client container (pick task complete) |
| **Loaded** | Stock loaded onto truck or placed at dock (load task complete) |
| **Shipped** | Order confirmed dispatched; stock decremented from WMS |
These stages allow visibility into order execution progress and enable exception detection (e.g., prepared > loaded means dock delay).
### Shipment templates (modèles d'expédition)
Shipment templates automate wave and group creation by applying a set of selection criteria on a schedule. Instead of manually creating a wave each time, a template runs automatically (or is triggered manually) and selects matching orders into a wave or group.
**Selection criteria (15+ configurable per template):**
| Category | Criteria |
|----------|---------|
| Carrier | Carrier code |
| Client | Client/account code |
| Owner | Owner code (3PL multi-owner) |
| Destination | Delivery address or region |
| Order type | Order type code |
| Order class | Order class (commercial category) |
| Order typology | Order typology (operational subtype) |
| Stock check | Include/exclude orders with unresolved stock shortages |
| Item type | Orders containing items of a specific type |
| Item family | Orders containing items of a specific family |
| Danger flag | Orders with/without hazardous items |
| Crossdocking | Orders eligible for crossdocking |
| Ungrouping zone | Target ungrouping zone |
| Packing zone | Target packing zone |
| Custom fields | Free-text fields on the order |
**Scheduling**: templates can be configured to run on a time-based schedule (e.g., daily at 14:00) or executed manually on demand. Each execution creates one wave or group from all matching orders at that moment.
**Priority within template**: orders selected by the template are ordered by their individual priority field.
### 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.
Conditions for fusion:
- Same client (account)
- Same delivery destination
After fusion, the combined order is prepared as a single batch, reducing travel distance. The fusion can be reversed (split) if needed before picking starts.
## Parameters
| Parameter | Description | Default |
|---|---|---|
| `ALLOW_CONFIRMATION_ON_PLACEMENT` | At picking destination, operator confirms the container/dock is correct | Disabled |
| `EMPTY_PICKING_LOCATION_QUESTION` | At last picking task from a location/container, system asks if it is empty (supports inventory) | Disabled |
| `EMPTY_PICKING_LOCATION_STOCK_ADJUST` | If EMPTY_PICKING_LOCATION_QUESTION active: if yes, perform stock adjustment; if no, mark for review | true |
| `PICKANDPASS_ALLOW_READ_DIFFERENT_CONTAINER` | Pick and Pass: allow operator to read an LPN different from the one proposed | Disabled |
| `PICKING_ALLOW_WAITING_ON_LOCATION_ON_WAIT_FOR_REPLENISHMENT` | Operator can decide between self-replenishing, stock-adjusting, or skipping when the PDL is empty (see "Picking Incidences") | Disabled |
| `PICKING_ALLOW_STARTING_DECISION_ON_WAIT_FOR_REPLENISHMENT` | Operator can refuse an outbound order that contains tasks waiting for replenishment | Disabled |
| `PICKING_ALLOW_UNLOADING_ON_LOCATION_ON_WAIT_FOR_REPLENISHMENT` | Operator can store the client container instead of going to the destination when picks are still blocked on replenishment | Disabled |
## Common Errors
**No stock assigned (order line stays incomplete):** All assignment strategies exhausted without finding eligible stock. Check: stock states allow picking, no counting tasks on locations, picking dedicated location configured for item if replenishment-origin stock, no extraction errors at locations.
**Picking task not proposed by system:** Stock was assigned but the picking location has a lock preventing picking, or the aisle is blocked. Resolve the lock/block or trigger a location reassignment.
**PTL not illuminating:** PK not configured for PTL, PTL device or controller disabled, or MP has more than one container when auto-destination is expected. Check workstation configuration and PTL device status.
**Grouped picking reverts to individual:** One of the compatibility conditions failed (e.g., logistic attribute capture required, MP has stock from a different order). Check PK configuration and MP state.
**Excess over-picking:** An operator picked more than requested. System reduces remaining tasks for same item by the excess amount. If the order doesn't allow excess, an error is thrown; operator must undo excess.
**Cutting stock cut is wrong length:** Cutting stock requires exact-quantity handling. If the cut produces a wrong length, the operator must register an incidence and recut; the old stretch must be re-entered into inventory with correct quantity.
**Container full before order complete:** Client container runs out of capacity mid-picking. Operator uses "close container" action → a new client container is created for the remaining tasks. Both containers go to the dock for the same order.
## Interface Paths
| Interface | Path |
|---|---|
| RFT — picking (manual warehouse) | Menu "Picking" → task mode selection |
| RFT — picking conveyor (automatic warehouse) | Workstation "Picking" view |
| Web — stock assignment strategies | "Configuration" → "Stock assignment strategies" |
| Web — shipping order + stock assign | "Shipping" → "Shipping orders" → order → "Stock assign" |
| Web — workstations (PK config) | "Control" → "Workstations" |
| Web — docks and stages | "Control" → "Docks and stages" |
## Related
- [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
- [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
- [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
- [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
- [[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
- [Tense Flow](tense-flow.md) — tense-flow picking bypasses storage : pick directly from a source support into a client container via the `PREPARATION` buffer
wiki_old_13-05-2026/concepts/prepackaging.md
+115
View File
@@ -0,0 +1,115 @@
---
title: "Prepackaging (Pré-emballage / Précolisage)"
type: concept
sources:
- areas/shipping/shipping_admin/prepackaging_config.md
- areas/shipping/shipping_admin/prepackaging_erp.md
- sources/archives/04_Gestion_preemballage_precolisage.md
related:
- concepts/shipping.md
- concepts/order-outbound.md
- concepts/container.md
- concepts/erp-interface.md
last_compiled: "2026-04-17"
---
# Prepackaging (Pré-emballage / Précolisage)
## Overview
Prepackaging (FR : *pré-emballage* ou *précolisage*) calculates the number and type of client containers required to fulfill a shipping order **before preparation starts**, with the goal of optimizing container usage (minimize parcels, or maximize filling) and guiding operators/packers on the target packing layout.
Two views drive prepackaging:
- **Configuration → Stratégie de préemballage** : strategy definition
- **Ordre de sortie → Lignes de pré emballage** : per-order view of the containers the strategy produced
## Strategy Configuration
A prepackaging strategy has the following fields:
| Field | Values | Description |
|---|---|---|
| **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 |
| **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 |
> ⚠️ The strategy must be **activated** after configuration, otherwise it is ignored.
**Container types** are associated from EasyS (either reusing existing container types or creating new ones dedicated to prepackaging).
## Prerequisites (when EasyWMS computes the plan)
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.
## Calculation by ERP (SOR02)
When `Calculé par l'ERP`, the outbound order message carries a `<PrepackagingConfiguration>` block inside `SOR02`, including the pre-computed container(s) and the per-line quantities to pack in each.
```xml
<PrepackagingConfiguration>
<Operation>S</Operation>
<PrepackagingProcess>Picking</PrepackagingProcess>
<PrepackagingWorkingMode>Strict</PrepackagingWorkingMode>
<PrepackagingContainers transactional="true" complete="false">
<PrepackagingContainer>
<Operation>S</Operation>
<PrepOrderContainer>0203214687</PrepOrderContainer>
<PrepContainerType>CartonS</PrepContainerType>
<PrepackagingLines>
<PrepackagingLine>
<Operation>S</Operation>
<OrderLineNumber>1</OrderLineNumber>
<Quantity>2</Quantity>
</PrepackagingLine>
</PrepackagingLines>
</PrepackagingContainer>
</PrepackagingContainers>
</PrepackagingConfiguration>
```
Keys in this block:
- `PrepackagingProcess` — `Picking` or `Packing`
- `PrepackagingWorkingMode` — `Strict` / `NotStrict`
- `PrepOrderContainer` — client container SSCC that must be used
- `PrepContainerType` — container-type code (must exist in EasyWMS)
- `PrepackagingLines.PrepackagingLine` — quantity per outbound line that belongs in this container
## Tested Behavior (Mecalux France, 2022)
Confirmed working vs. known-broken combinations:
| Combination | Behavior |
|---|---|
| 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 / Volume minimum | 3 conteneurs différents |
| Vague / Strict / Volume minimum | Calcul réalisé par commande |
| **Calcul par l'opérateur** | ❌ **non fonctionnel** |
> Keep in mind these limitations when scoping a project : for "type non mélangeable" or "Calcul par l'opérateur", a Jira / support escalation is needed before promising the behavior to a customer.
## Common Errors
**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.
**`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.
**ERP-computed prepackaging ignored** : check that `PrepackagingProcess` and `PrepackagingWorkingMode` are both valid values and that `PrepContainerType` exists as a container type in the WMS ; otherwise the whole `PrepackagingConfiguration` block is rejected silently on SOR02 integration.
## Related
- [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
- [Container (LPN)](container.md) — container types and SSCCs referenced by prepackaging
- [ERP Interface](erp-interface.md) — full field tables for SOR02
wiki_old_13-05-2026/concepts/product-item.md
+435
View File
@@ -0,0 +1,435 @@
---
title: "Product / Item"
type: concept
sources:
- areas/inventory_management/items/index.md
- areas/inventory_management/items/types.md
- areas/inventory_management/items/uom.md
- areas/inventory_management/items/uom_base.md
- areas/inventory_management/items/logistic_attributes.md
- areas/inventory_management/items/profiles.md
- areas/inventory_management/items/families.md
- areas/inventory_management/items/alias.md
- areas/inventory_management/items/conversions_presentations.md
- areas/inventory_management/items/logistic_profile.md
- areas/inventory_management/items/reception_profile.md
- areas/inventory_management/items/putaway_profile.md
- areas/inventory_management/items/shipping_profile.md
- areas/inventory_management/items/abc_classification.md
- areas/inventory_management/items/substitutes.md
- areas/inventory_management/items/weight.md
- areas/inventory_management/items/mix_items.md
- areas/inventory_management/items/min_and_max.md
- areas/inventory_management/items/subwarehouse_classification.md
- areas/inventory_management/items/views/view_items.md
- sources/archives/07_Gestion_gerbabilite.md
- sources/archives/08_Ajouter_image_fiche_article_ITM01.md
- sources/archives/12_Articles_alternatifs.md
- sources/archives/15_Configuration_ABC.md
- sources/archives/28_Creation_attribut_logistique_sans_capture.md
- sources/archives/33_Les_poids.md
related:
- concepts/stock.md
- concepts/container.md
- concepts/reception.md
- concepts/putaway.md
- concepts/picking.md
- concepts/shipping.md
- concepts/count.md
- concepts/order-inbound.md
- concepts/order-outbound.md
- concepts/cutting-stock.md
- concepts/labels.md
- concepts/erp-interface.md
last_compiled: "2026-04-17"
---
# Product / Item
## 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.
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.
Items are managed primarily through the ERP (via ITM messages) or directly in the "Masters" section of the WMS interface. Every item must have at minimum a base unit of measure, a reception profile, and a shipping profile.
## Types
### Item types (storage mixing control)
Item types define mixing restrictions at the **storage** level (locations, containers, container divisions). When item types are configured, each type specifies whether it can mix with other types and which types are explicitly excluded.
- Item types **do not** affect reception or shipping
- With location partitions, the partition limit applies to the individual item, not to its type
Use case: prevent storing hazardous chemicals in the same location as food items.
### Item families (client container mixing control)
Item families define mixing restrictions for **client containers** (containers being prepared for outbound shipping orders). Unlike types, families have no effect on storage locations.
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
- `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)
The most restrictive method in an order takes precedence (Scan > Choose > 1 parcel).
### ABC Classification
The ABC classification indicates the rotation/activity level of an item relative to others:
- **A**: High rotation (fast-movers)
- **B**: Medium rotation
- **C**: Low rotation (slow-movers)
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.
When an article straddles two classes, the `Type de calcul` chosen at evaluation decides :
| Mode | Behavior on overlap |
|---|---|
| **Inclusive** | Keeps the **higher** class |
| **Exclusive** | Keeps the **lower** class |
**ABC class setup.** `Données Principales → Détails d'articles → Classement ABC` :
- The higher the **minimum movement %**, the stronger the rotation represented.
- No duplicate percentages.
- The sum of all class percentages **must not exceed 100**.
**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 :
- **Date** — `Start-end date` or `By number of day`
- **Mouvements** — task types to include (at least one required)
- **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).
- **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.
**ERP notification.** A dedicated button ships the list of misclassified articles to the ERP via the `SAC` file. To activate : `Configuration → Types de transaction` → search `SAC.SEND.001` → enable notification on insertion + post-processing.
## 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.
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)
- Each presentation has an EAN code (barcode for scanning at reception/picking)
- A conversion can be **virtual** (reference only; no actual stock in that UoM)
- Quantities can be decimal or less than 1 (e.g., fabrics measured by the meter)
The optional system toggle `ProductConversionQuantityMustBeGreatherThanOne` controls whether conversions can be smaller than the base UoM.
UoMs have an optional 2-character **abbreviation** used on PTL (pick-to-light) displays.
ERP integration: UoM creation (but not change or deletion) via ITM message.
**Alias** is an additional item code (e.g., EAN, customer code) for identification. An alias on a presentation represents the GTIN/barcode for that packaging. Easy WMS supports GS1 and HIBC label standards.
## Logistic attributes
Logistic attributes are characteristics that condition the logistic behavior of stock. They are defined in the **logistic profile** and associated with an item. The **Allow mixing** property per attribute controls whether stock with different values of the same attribute can be stored together.
| Logistic attribute | Description | Typical configuration |
|---|---|---|
| **Lot** | Groups of units produced under identical conditions (batch) | Mandatory on receipt; optional mixing allowed or not; max lots per line configurable in SOR |
| **Expiration date** | Date after which stock is unusable | Mandatory on receipt; drives FEFO shipping logic |
| **Best-before date** | Date after which stock loses some quality | Similar to expiration date |
| **Production date** | Date stock was manufactured | Optional; used with days-of-life calculations |
| **Days of life** | Number of days stock is usable; system generates shelf life expiration date | Configured as mandatory on receipt; shipping calculates eligibility: current date + required days ≤ end-of-life date |
| **Serial number** | Unique alphanumeric ID per unit | Captured at picking, ungrouping, or packaging; optionally at putaway |
| **Quality** | Qualitative characteristic (e.g., Grade A/B) | Mandatory or optional on receipt; mixing restrictions configurable |
| **Size/Caliber** | Dimensional size of stock units | Mandatory or optional; value list configurable (e.g., small/medium/large) |
| **Color** | Stock color | Value list configurable |
| **Version** | Version/revision number; mandatory for kit items | |
| **Production method** | Manufacturing process used | |
| **Post-production treatment** | Processing after manufacturing | |
**Mixing days** refinement: for date-controlled items, specifies the maximum difference in days between mixed stock dates (expiry, shelf-life, or production depending on shipping logic).
### 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.
> ⚠️ 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).
2. **Collect the identifiers** with a Run Query on the reading context:
```csharp
Context.LogisticAttributes.Select(la => new {
la.Name,
la.Id,
la.LogisticProfileId,
la.LogisticProfileCode,
})
```
Note the `LogisticAttributeId` and `LogisticProfileId` of the attribute just created.
3. **Generate a new GUID** via a scalar Run Query on the writing context (check **"Is scalar"**):
```csharp
Guid.NewGuid()
```
4. **Run Command** `LogisticAttributeCreateLogisticCaptureCommand` with:
| Field | Value |
|---|---|
| `CaptureMode` | `2` |
| `CaptureProcess` | `2` |
| `LogisticAttributeId` | ID from step 2 |
| `LogisticCaptureId` | GUID from step 3 |
| `ProfileId` | Profile ID from step 2 |
5. **Delete the initial `Manual` capture mode** from the logistic profile. The attribute now has only the empty (auto) capture mode.
**Validation.** In the logistic profile edit view, the attribute line appears with an **empty capture mode**. Confirms configuration is correct.
## Profiles
Profiles define item behavior in each WMS process. They allow bulk configuration — many items can share the same profile.
| Profile | Required | Purpose |
|---|---|---|
| **Logistic profile** | Optional | Defines which logistic attributes the item has and their mixing rules |
| **Reception profile** | **Mandatory** | Controls behavior during inbound: label printing, weight capture, logistic attribute prompts, etc. |
| **Putaway profile** | Optional | Links to putaway strategies and location rules for this item |
| **Shipping profile** | **Mandatory** | Controls behavior during outbound: weight capture, substitute item mode, consolidation rules, etc. |
| **Manufacturing profile** | Optional | Governs automatic logistic attribute generation for finished goods in manufacturing |
| **Count profile** | Optional | Defines behavior during physical counts |
| **Cutting profile** | Optional | Marks item as a cutting stock item; defines consolidation behavior and label requirements during cut picking |
### Profile configuration examples
**Logistic profile examples**:
| Profile name | Logistic attributes tracked |
|---|---|
| `PROFIL_SIMPLE` | No special attributes (no lot, no expiry) |
| `PROFIL_DLC` | DLC (use-by date) + optional lot; shipping uses FEFO |
| `PROFIL_LOT` | Lot number only |
| `PROFIL_SN` | Serial number (unit-level traceability) |
**Reception profile examples**:
| Profile name | Key settings |
|---|---|
| `PROFIL_SIMPLE` | No quality block; quantity entry mode = scan + manual; 0% tolerance; expired stock: configurable |
| `PROFIL_QUALITE` | Block with QUALITE status until manual release; standard scan + quantity |
**Shipping profile examples**:
| Profile name | Key settings |
|---|---|
| `PROFIL_FIFO_MANU` | FIFO shipping logic; 0% picking excess; manual quantity validation |
| `PROFIL_FIFO_SCAN` | FIFO logic; 0% picking excess; 1 scan validates quantity |
| `PROFIL_FEFO` | FEFO logic (First Expired First Out); used for perishables |
## Item attributes (full reference)
| Attribute | Description |
|---|---|
| **Owner** | Company owning this item's stock; multiple owners can hold same item code |
| **Description** | Full description (displayed in web UI) |
| **Short description** | Abbreviated description (≤ defined length; used on RFT and workstation) |
| **Handling description** | Instructions shown to operator at reception |
| **Base UoM** | Reference unit for all conversions |
| **Alias** | Additional codes (EAN, customer codes, GTINs per presentation) |
| **Conversions & presentations** | UoM equivalences with EAN per packaging |
| **Profiles** | Logistic / Reception / Putaway / Shipping / Manufacturing / Count / Cutting |
| **Logistic attributes** | Characteristics controlling stock traceability (see above) |
| **Stackability (Gerbabilité)** | Numeric value **0–10** controlling picking order and pallet-layer order in client containers. Low value = solid → picked **first**, placed at the **bottom** of the pallet. High value = fragile → picked **last**, placed **on top**. Populated via the `<Stack>` tag in `ITM01`. When all picked items share the same stackability, the default picking path is used instead. |
| **Allow mix** | Whether different items can coexist in same location/container/division |
| **ABC Classification** | Rotation level (A/B/C); used in putaway strategies |
| **Sub-warehouse classification** | Min/max stock quantity per sub-warehouse |
| **Image** | Product image (displayed during eCommerce reception at workstation). Set via the `<ImageName>` tag in `ITM01`. See "Item Image (ITM01)" below for local vs. URL-hosted options. |
| **Hazard** | Marks item as hazardous material; used in putaway strategy restrictions |
| **Stock labeled** | Whether item has a barcode label; if yes, auto-fills alias during picking |
| **Substitute items** | Alternative items used when stock of this item is insufficient; each substitute has an equivalence ratio |
| **Weight** | Fixed weight or min/max range (for variable-weight items like cutting stock); used for weight tolerance at reception and weight-capture enforcement in logistic profile |
| **Item types** | Storage mixing groups |
| **Item families** | Client container mixing groups |
| **Is bulky** | eCommerce: bulky items go directly to storage area, not to standard reception processing |
| **Min quantity for shipping** | Minimum shippable length/quantity (cutting items only) |
| **Max quantity for shipping by line** | Maximum length/quantity per line (cutting items only) |
| **Warning in picking message** | Free-text message shown to operator during picking of this item |
| **Min temperature** | Minimum storage temperature; used in putaway to filter compatible locations |
| **Max temperature** | Maximum storage temperature; used in putaway to filter compatible locations |
| **Is packaging** | Marks item as a packaging material (informational only) |
| **Allow crossdocking** | Whether stock of this item can be used for crossdocking |
| **Conversion for picking** | Default UoM suggested during picking (when no alias scanned and no SOR preference) |
| **Max partitions per item** | Maximum number of partitions assignable to this item in a picking location |
| **Free fields (1–20)** | Up to 20 configurable free-text fields for custom data (e.g., brand, color code, fiscal code). Field labels are defined at the warehouse level. Useful for information that doesn't map to standard fields. |
| **Minimum stock** | Minimum stock level threshold; when available (unprepared) stock falls below this, managers can receive alerts. Does not automatically trigger replenishment. |
| **Picking alert message** | Free-text message displayed to operator when a picking task starts for this item (e.g., "Also take the battery"). Used for handling instructions. |
## Item Image (ITM01)
Two delivery paths for item pictures populated through `<ImageName>` :
**Local file.** By default, the WMS looks for images in :
```
C:\inetpub\wwwroot\SmartUIServices\Imagenes\EasyWMS
```
`<ImageName>` must contain **only the filename** (with `.jpg` / `.png` extension) :
```xml
<ImageName>GINI.png</ImageName>
```
**Remote URL.** Edit `C:\inetpub\wwwroot\SmartUIServices\appsettings.json` and set the **fixed URL prefix** in `"UserImagesURI"`. In `ITM01`, `<ImageName>` still contains only the filename :
- `UserImagesURI` = `https://pim.example.com/media/`
- `<ImageName>` = `879507f2_R26_0203_BLK_1.jpg`
- Effective URL resolved by the WMS : `https://pim.example.com/media/879507f2_R26_0203_BLK_1.jpg`
## Alternative / Substitute Items
When an item is out of stock, the WMS can pick a replacement item depending on its configuration. Setup requires three elements and an optional ERP flag :
### 1. SOR flag (ERP allows substitution)
In `SOR01` / `SOR02`, on the relevant `<Line>` elements :
```xml
<LneTerms>
<LneTrmAlternative>true</LneTrmAlternative>
</LneTerms>
```
### 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. |
| **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`**.
### 3. Substitute item table
In `Données principales → Articles`, select the **item to be replaced**, click **"Ajouter Alternatif"** and fill :
1. Base item.
2. Trigger quantity (from what quantity onwards the replacement applies / by how many at a time).
3. Substitute item.
4. Quantity of the substitute used to replace the trigger quantity defined in (2).
5. Activation period (leave blank = ad vitam).
### 4. SOF feedback
| Case | SOF payload |
|---|---|
| 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) |
## Labeling
Easy WMS generates item labels in CODE128B format. The label includes at minimum the item code; optionally the short description (up to 36 characters in standard format).
Supported label sizes:
| Format | Labels per A4 sheet |
|---|---|
| A6 | Printed by labeller |
| 175×135 mm | 2 per A4 |
| 148×105 mm | 6 per A4 |
| 105×29 mm | 20 per A4 |
| 75×25 mm | 33 per A4 |
**Cutting item labels** have a special design: item code + length/quantity + UoM + logistic attributes. Format: A6 for labeller only.
Labels are printed from the web UI ("Items" view) or from the RFT ("Utilities → Label printing").
## Item base management (lifecycle)
The WMS item base grows over time as ERP sends new items (seasonal articles, per-reception creation, etc.). Without active cleanup, the item base can become very large and slow WMS search performance.
**Key principle**: the WMS should mirror the ERP's active article status.
- When the ERP **deactivates** an article, it should send a deletion signal to the WMS (via ITM with deletion flag).
- Most ERPs do not physically delete articles, only deactivate them. The WMS deletion should be triggered at that point.
- If the ERP **reactivates** an article, it must resend the ITM creation file.
- **WMS can only delete an item if no active stock or tasks reference it.**
> **Warning**: If the ERP cannot manage item lifecycle signaling and item volume is high, a custom cleanup strategy must be designed to prevent WMS performance degradation.
## ERP integration
| Message | Direction | Purpose |
|---|---|---|
| **ITM** | ERP → WMS | Create or update item master data (code, description, UoMs, profiles, logistic attributes) |
| **SAC01** | WMS → ERP | ABC rotation classification suggestion. Sent manually after rotation recalculation in WMS; ERP can update item classification with this data. |
Note: ITM creates UoMs but cannot change or delete them. Item changes via ITM require careful management to avoid disrupting active stock or tasks.
**ABC rotation recalculation** can be done:
- For the whole warehouse or a specific storage zone
- Over a configurable period (days or date range)
- As many times as desired; thresholds for A/B/C classes are user-configurable
- Result is indicative when ERP is the master; operator can manually apply the suggested class to the item, then trigger SAC01 to sync the ERP
## Configuration
Key parameters:
- `ProductConversionQuantityMustBeGreatherThanOne` (toggle): controls whether conversions < base UoM are allowed
- `MAX_NUM_LABELS_TO_READ` (parameter): enables multi-reference label reading during reception, counting, and stock adjustment
- Putaway strategies in **putaway profile** can filter by ABC classification, hazard, temperature, logistic attributes
- **Substitutes** mode is configured in the shipping profile (partial substitution, all-or-nothing, etc.)
## Interface
| Function | Hardware | Menu path |
|---|---|---|
| Item master management | PC | Masters → Items |
| Logistic profiles | PC | Masters → Item details → Logistic profiles |
| Reception profiles | PC | Masters → Item details → Reception profiles |
| Putaway profiles | PC | Masters → Item details → Putaway profiles |
| Shipping profiles | PC | Masters → Item details → Shipping profiles |
| Manufacturing profiles | PC | Masters → Item details |
| Count profiles | PC | Masters → Item details → Count profiles |
| Cutting profiles | PC | Masters → Item details → Cutting profiles |
| Units of Measure | PC | Masters → Item details → Units of measure |
| Item types | PC | Masters → Item details → Item types |
| Item families | PC | Masters → Item details → (families view) |
| ABC Classification | PC | Masters → Item details |
| Label printing | RFT | Utilities → Label printing |
## Common errors
| Symptom | Cause | Solution |
|---|---|---|
| Item cannot be received | No reception profile assigned | Assign a reception profile before creating receipts |
| Item not appearing in stock assignment | No shipping profile, or shipping profile excludes this stock status | Verify shipping profile; check required/rejected status flags on SOR line |
| Mixing error at reception | Logistic profile "Allow mixing" set to No for a logistic attribute, and two values are present in the container | Receive items in separate containers or enable mixing in logistic profile |
| Putaway profile not applied | Item has no putaway profile; system uses default warehouse strategy | Assign a putaway profile with appropriate strategies |
| Substitute not used in assignment | Substitutes not configured in shipping profile, or not enabled in SOR line (`LneTrmAlternative`) | Check shipping profile substitution mode and enable in order if needed |
| Days of life validation fails | Stock end-of-life date < current date + required days in SOR line | Ship with other stock, or ship expired stock explicitly if allowed |
| Picking message not shown | Warning message not populated on item master | Set the "Warning in picking message" field on the item |
## Related
- [[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
- [[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
- [[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
- [[count]] — count profile defines item counting behavior (ABC-driven cycle counts)
- [[order-inbound]] — ROR lines reference items by code or presentation alias
- [[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
- [[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
- [[kits]] — kit articles and component articles are both standard items; kit assembly consumes component stock
wiki_old_13-05-2026/concepts/putaway.md
+427
View File
@@ -0,0 +1,427 @@
---
title: "Putaway"
type: concept
sources:
- areas/putaway/putaway_admin/putaway_process.md
- areas/putaway/putaway_admin/putaway_apply_strategies.md
- areas/putaway/putaway_admin/index.md
- areas/putaway/putaway_admin/location_putaway_restrictions_example.md
- areas/putaway/configurations/putaway_configuration01.md
- areas/putaway/configurations/putaway_configuration02.md
- areas/putaway/configurations/pdl_partition.md
- areas/putaway/configurations/can_rack.md
- areas/putaway/putaway_manual_wrh/optimization_location_channels.md
- sources/archives/01_Strategies_rangement_fonctionnement.md
- sources/archives/25_Strategie_remplissage_canaux.md
- sources/archives/Bases_fonctionnement_robotique_EasyWMS.md
- sources/archives/Configuration_EasyS.md
related:
- concepts/container.md
- concepts/reception.md
- concepts/replenishment.md
- concepts/location.md
- concepts/stock.md
- architecture/galileo-integration.md
- operations/galileo-simulation.md
last_compiled: "2026-04-17"
---
# Putaway
## Overview
Putaway is the process of finding an optimal storage location for containers, loose stock, or cutting stock after reception or internal movement. EasyWMS drives putaway through a strategy engine that evaluates criteria, restrictions, and sorting preferences to propose the best destination location.
Putaway applies to two warehouse environments: **manual warehouses** where RFT operators physically move goods with equipment (forklifts, hand trucks), and **automatic warehouses** where the Transport Management System (TMS) physically executes location tasks in response to EasyWMS instructions. In both cases, the strategy engine is the same; only the execution layer differs.
Valid objects for putaway:
- Containers without movement/location blocks
- Stock not in a state that prevents moving or locating
- Stock not assigned to a shipping order (client stock cannot be putaway)
## Strategy Architecture
The putaway strategy engine is the core of location search. Two complementary strategy types exist:
| Strategy type | Scope | Priority |
|---|---|---|
| **Channel filling strategies** | APS, compact, PalletShuttle, dynamic, pushback locations with depth control | Applied first |
| **Location strategies** | All location types | Applied if no channel strategy found or yields no result |
### Strategy Components
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.)
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
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.
### SmartUI Configuration Workflow (Configuration → Stratégies de stockage)
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.
**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* |
| 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 :
| 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).
> 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 — "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
A strategy takes effect only after explicit **activation**. To modify an existing strategy :
1. `Configuration → Stratégies de stockage`
2. **Deactivate** the target strategy
3. Select it → **Éditer**
4. Apply changes → **Save** → **Reactivate**
> Editing an active strategy is blocked by the UI ; attempting to save without the deactivate step is the most common cause of "ma modification n'a pas pris en compte".
## Location Search Pipeline (Putaway Strategies)
### Stage 1 — Filter valid strategies by criteria
EasyWMS filters all enabled strategies for the warehouse against five criterion groups:
**Strategy criteria (type):**
- Container (non-client / client / empty)
- Stock (loose)
- Group by SO/Route (ASN pre-notified containers with expected shipping order or route+stop)
**Source station criteria:** strategy applies only if the container/stock is currently at a location associated with the configured station type or station.
**Container criteria:** container type, lock type, PLC height type, container weight range.
**Item criteria:** hazardous, owner, item type, ABC classification, temperature. For multi-reference containers, the dominant item (highest quantity in base UoM) determines these attributes.
**Stock criteria:** supplier, status (inbound/outbound), expired stock flag.
### 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.
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)
When enabled via parameter `BALANCE_AISLE`, EasyWMS balances load across valid aisles using the formula:
```
Load = (containers in aisle with same item × 5) + (total containers in aisle × 1) + (tasks destined to aisle × 7)
```
Default weights: X=5, Y=1, Z=7 (configurable with expiry date). The aisle with the lowest load score is selected. If multiple aisles tie, the lowest aisle number wins. Once an aisle is chosen, only its locations proceed to the next stage. If no valid location is found in that aisle, the next strategy in sequence is evaluated.
For multi-reference containers, the item with the largest quantity (base UoM) is used for balancing.
### 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.
| Restriction type | Scope |
|---|---|
| Do not locate in same zone | Items/item-types cannot share a zone |
| Do not locate in same aisle | Items/item-types cannot share an aisle |
| Do not locate in same sub-warehouse | Items/item-types cannot share a sub-warehouse location |
| Do not fit on higher heights | Item A cannot be placed above item B in same column |
| Do not putaway adjacent | Items/item-types cannot be in adjacent locations |
| Minimum distance | Minimum meters required between items/item-types |
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)
From remaining candidates, EasyWMS applies a hard validity checklist:
- Location logic allows putaway
- Location not marked full
- No lock preventing putaway
- Station in READY state, not locked, allows inbounds, not over relocation % limit
- For **containers**: storage type allows containers; container type/capacity fits; container height fits; volume available; weight within limit; assigned item matches (if any); valid unloading aisle
- For **loose stock**: storage type allows stock; volume available; weight within limit; assigned item matches (if any); no owner mixing, no item mixing, no item-type mixing, no logistic-attribute mixing if configured
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
The strategy rule further filters candidate locations by:
| Rule scope | Configurable conditions |
|---|---|
| Destination location | Storage mode, Valid-if situation (empty/with stock/empty channel…), rack type, location type, X/Y coordinates, side, specific location, height range, column weight, assigned item |
| Destination aisle | Aisle ID, automatic/manual, aisle with assigned item |
| Destination zone | Zone ID |
| Temperature | Min/max temperature, or use item's temperature range |
| Destination sub-warehouse | Sub-warehouse, max containers, stock quantity, max inventory % |
| Mixing restrictions | Mix items, mix conversions, mix logistic attributes, use mixing days, mix container types, partial stock location, apply restrictions |
**Mixing rules summary:**
| Mix item | Mix logistic attr | Logistic profile mix | Valid locations |
|---|---|---|---|
| NO | NO | any | Empty + same item + same logistic attrs |
| NO | YES | mix:NO | Empty + same item + same logistic attrs |
| NO | YES | mix:YES | Empty + same item + any logistic attrs |
| YES | N/A | mix:NO | Empty + any item/attrs (unless item-pair has specific restriction) |
| YES | N/A | mix:YES | Empty + any item/attrs |
Empty locations are always valid regardless of mixing configuration.
### Stage 7 — Sort locations by preferences
Valid locations are sorted according to the strategy's configured preferences (in priority order):
| Preference | Description |
|---|---|
| Distance to header ↑↓ | Distance from aisle header (automatic warehouses) |
| Volume ↑↓ | Unoccupied volume (loose stock with volume-configured items) |
| Aisle side ↑↓ | Left or right side of aisle |
| Free positions ↑↓ | Occupancy level (mainly for drive-in) |
| X coordinate ↑↓ | Physical X coordinate |
| Y coordinate ↑↓ | Physical Y coordinate |
| Depth ↑↓ | Depth position within rack channel |
| Height ↑↓ | Physical height |
| Same container type | Prioritize locations already holding same container type |
| Same item stock | Prioritize locations already holding same item (loose stock only) |
| Distance to assigned location | Fill picking dedicated location column first, then adjacent |
| 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
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.
**If no valid location is found:**
- Manual warehouse: operator is prompted to manually specify a destination
- Automatic warehouse: a **Rejection task** is generated to move the container to the configured rejection station (if none configured, container stays at current location)
## Channel Filling Strategies
Channel filling strategies are exclusive to container putaway in depth-controlled locations (APS, compact, PalletShuttle, dynamic, pushback). They are evaluated **before** standard location strategies.
**Channel definition:**
- Rack locations: same logical X coordinate (based on container type)
- APS/compact/PalletShuttle/dynamic/pushback: the location itself is the channel
Channel strategies group equivalent containers (same type + height + stock reference, or same ASN shipping order/route+stop) and try to fill existing channels before opening new ones. The sequencing logic:
1. Filter all enabled strategies meeting criteria
2. For the first strategy in sequence, try to find channels for all sets of equivalent containers
3. If all sets are placed → apply strategy, create reservations
4. If any set fails → no reservations created, try next strategy
5. If all strategies exhausted → fall through to location strategies
**Channel reservation:** each reservation has a configurable maximum time. After that time, unreserved containers lose their channel reservation.
**APS FIFO channel closure options:**
- Do not close
- Close at reservation creation
- Close at reservation end
- Close at reservation end only if channel is full (optionally auto-open when main location empties)
### 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.
**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. |
| **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).
**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.
## Putaway Flow by Object Type
### Container Putaway (RFT)
1. Operator scans container location or container ID on the RFT
2. System validates: container is in the scanned location, no conflicting tasks, no ASN pending receipt
3. Equipment check: container type can be loaded, capacity not exceeded, weight within limit
4. Container is computer-loaded onto equipment; source location released, equipment occupied
5. Operator selects container to locate → strategy engine searches for location
6. System proposes destination; operator confirms or enters alternative (valid if: warehouse match, storage allowed, not locked, allows containers, weight OK)
7. For Conventional Rack with multiple positions: logical position is requested
8. Optional: create picking dedicated location at destination (if `UNLOAD_CREATE_PRODUCT_LOCATION` enabled, location allows assigned location + picking, location is empty, container is not empty/multi-reference)
9. Container unloaded: equipment and final location weights/capacities updated; masks and depths updated per location type
Multiple containers on equipment: operator can locate all in one search (following picking route) or one at a time. Unlocated containers remain on equipment.
### Stock Putaway (RFT)
Similar flow to container putaway, but:
- Stock can be inside a container or loose on a location
- Equipment check: weight only (no container type check)
- Destination validation: location allows stock and/or containers, weight OK
- Pre-generated label for picking dedicated locations: valid if label has no PDL assigned, or PDL is for correct stock type / empty with no replenishment tasks
- If location only allows containers and has a single container: stock is stored inside that container
### Cutting Stock Putaway (RFT)
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
### Automatic Station Putaway
Location search is triggered automatically when a container arrives at these station types:
| Station | Trigger | Special behavior |
|---|---|---|
| **PIE** (pallet identification entry) | TMS event: container arrived at PIE | Channel filling first, then location strategies |
| **Putaway conveyor (MU)** | TMS end-of-order received | Only if container has no existing putaway task |
| **Other automatic stations** (excluding warehouse, shuttles, picking, stackers, empty buffers) | TMS end-of-order received | Only if container has no associated task |
| **AS/RS (TRL)** | TMS deposit error | Search for new location in same aisle; also handles multi-load special cases |
| **Warehouse station (ALM)** | Container at lower depth blocks extraction | Search for alternate location in same aisle; or operator manual relocation request |
TMS physically executes the movement after EasyWMS creates the location task.
## Putaway Profiles
Items can have a **putaway profile** assigned. Strategies can be linked to specific profiles, allowing different location logic for different product categories. Strategies without a profile assignment apply to items without a profile (excluding gap-fill and cross-reference strategies).
## Picking Dedicated Location Integration
When a warehouse uses picking dedicated locations (PDLs), the recommended putaway strategy sequence is:
| Sequence | Goal | Key rule setting |
|---|---|---|
| 1 | Replenish PDL directly | "Assigned location" enabled |
| 2 | Store near PDL (in same aisle) | "Aisle with assigned location" enabled; sort by "Distance to assigned location" |
| 3 (optional, containers only) | Store in PDL priority locations | "Assigned location" enabled for priority location type |
For loose stock replenishment into PDL containers, the **minimum percentage received to create new container** rule determines whether to fill an existing container (if received quantity ≤ threshold) or open a new container (if received quantity > threshold).
Capacity calculation at PDL:
- **Container PDL**: containers + tasks destined to PDL; only matching item/logistic-attr containers counted if multi-reference
- **Stock PDL**: stock quantity + tasks quantity; only matching item/logistic-attr stock counted if mixed
## Putaway in an automatic warehouse (end-to-end)
The strategy engine is shared with manual warehouses, but the execution path differs. Container arrival at an automatic entry station triggers:
1. TMS (GALILEO) sends an event to EasyWMS announcing the container arrival
2. EasyWMS checks the container doesn't already have a putaway task
3. Engine gathers valid putaway strategies for this context
4. Strategies are applied in sequence to find a candidate location
5. On hit → task created + sent to TMS; on miss → channel reservation / reject / wait for manual action
6. TMS executes the physical move
7. On deposit error (`EndErrorCode=1`) → new search in the same aisle, then in others
8. On successful deposit → WMS state updated + temporary reservations released
For the protocol layer (Search, End, codes), see [GALILEO Integration](../architecture/galileo-integration.md).
## Putaway logic by rack depth
Strategy coverage expected per rack type (Mecalux France defaults):
**Single-depth racks:**
- Ascending height (smallest possible location)
- Rotation (zone matching the item's rotation class)
- Stock balancing (by container count, same-product supports, in-transit supports)
**Double-depth racks:**
- Ascending height + Rotation + Stock balancing
- Avoid product mixing — causes relocations during picking
- Avoid logistic-attribute / quantity mixing — depends on shipping logic
**>2-depth (APS) channels:**
- Ascending height + Rotation + Balancing
- **Forbid** product mixing (causes massive relocation)
- Avoid attribute mixing when possible (use "mix days" parameter for close-by dates)
- **Channel reservation**: EasyWMS analyses pending ASNs to pick the right tube length (e.g. 6 vs 10 deep)
### Empty-location headroom
**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 #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.
## Parameters
| Parameter | Description | Default |
|---|---|---|
| `BALANCE_AISLE` | Enable aisle load balancing formula in automatic warehouse location search | Disabled |
| `UNLOAD_CREATE_PRODUCT_LOCATION` | Automatically create picking dedicated location when placing container at valid location | Disabled |
## Common Errors
**No valid location found (manual warehouse):** All strategies exhausted; no location meets criteria + restrictions + rules. Operator must manually assign a destination. Check: strategy sequence coverage, restrictions not too restrictive, locations not marked full or locked.
**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.
**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.
## Interface Paths
| Interface | Path |
|---|---|
| RFT — container/loose stock putaway | Menu "Putaway" → "Containers/Loose stock" or "Containers" |
| RFT — stock putaway | Menu "Location" → "Containers/Loose stock" or "Stocks" |
| Web — putaway strategies | "Configuration" → "Putaway strategies" |
| Web — aisle balancing | "Putaway strategies" → "Configuration" → "Aisle Balance" |
| Web — restrictions | "Configuration" → "Restrictions" |
| Web — channel filling strategies | "Configuration" → "Stratégies de remplissage de canaux" |
| 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
- [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
- [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
- [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
- [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
- [Defragmentation](defragmentation.md) — rotation defragmentation reuses putaway strategies to relocate containers to their optimal ABC zone
wiki_old_13-05-2026/concepts/quality-control.md
+262
View File
@@ -0,0 +1,262 @@
---
title: "Quality Control"
type: concept
sources:
- areas/inventory_management/quality_control/index.md
- areas/inventory_management/quality_control/quality_lock_web.md
- areas/inventory_management/quality_control/quality_lock_trf.md
- areas/inventory_management/quality_control/quality_lock_erp.md
- areas/inventory_management/quality_control/quality_unlock.md
- areas/inventory_management/quality_control/quality_automatic_unlock.md
- areas/inventory_management/quality_control/cut_stock_lock.md
related:
- concepts/stock.md
- concepts/container.md
- concepts/reception.md
- concepts/order-outbound.md
- concepts/product-item.md
- concepts/stock-adjustment.md
last_compiled: "2026-04-10"
---
# Quality Control
## Overview
**Quality Control** in EasyWMS manages the usability of stock throughout its lifecycle in the warehouse. It operates via a **stock status** (also called a **stock lock**) system: each status can block specific warehouse operations on the affected stock, preventing it from being picked, moved, replenished, or shipped until the quality issue is resolved.
EasyWMS controls stock quality from reception through shipping. Statuses can be applied:
- At **reception** (via reception profile, inbound order line, or operator action)
- **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.
---
## Stock Status (Quality Lock) Concept
Each stock status is configured to block or allow specific operations:
| Operation | Can be blocked |
|---|---|
| Putaway | Yes |
| Move | Yes |
| Picking | Yes |
| Replenishment | Yes |
| Shipping | Yes |
| 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)
- **User status** — applied manually by an operator, manager, or via ERP message
---
## Types of Stock Status Application
### Reception Status (Inbound Lock)
Three mechanisms can apply a status at reception time:
| Mechanism | Who | Priority |
|---|---|---|
| Item receiving profile | System (automatic) | Base |
| Inbound order line / receiving order line | ERP/planner | Overrides profile if different |
| Operator at reception (RFT) | Operator | Applied as user status (in addition to receiving status) |
Both a receiving status and a user status can coexist on the same stock. The operator-set status is the user status.
At reception close, the ERP is notified of stock status via the STC message (stock status change).
---
## Locking Stock in the Warehouse
### Lock from Web Interface (SmartUI)
From `Warehouse > Stock` or `Warehouse > Received stock`:
- Lock can apply to stock from open receptions or stock without reception origin
- Optional: end date/time for the lock
- Optional: comment
If no end date is set, the lock remains until manually removed by a user or ERP.
**Effects of lock on active operations:**
- If lock **blocks replenishment**: replenishment source assignments canceled → picking tasks decremented or canceled → affected lines re-released
- If lock **blocks picking**: replenishment source assignments canceled → picking tasks decremented or canceled → lines re-released
### Lock from RF Terminal (RFT)
Via `RFT > Quality > Lock by location / Lock by container / Lock by item`:
| Lock scope | Granularity |
|---|---|
| By location | All stock in location, or stock of specific item/logistic attribute/quantity |
| By container | All stock in container, or specific item/attribute/quantity |
| By item | All stock of the item in warehouse, or filtered to specific locations/attributes |
Optional: end date/time and comment (same as web).
Same side effects on tasks and assignments as web interface lock.
### Lock from ERP (STR Message)
The ERP sends an **STR** (stock status request) message to request a lock. The lock can:
- Specify any combination of location, item, logistic attribute, container
- Include an optional end date/time and comment
EasyWMS responds with **STC** messages for each locked stock line (provided reception is closed).
In the SmartUI, ERP-applied locks appear as a user status.
---
## Unlocking Stock
### Manual Unlock (Web)
From `Warehouse > Stock` view: select stock lines and remove status. STV-style notification via STC to ERP.
### Manual Unlock (RFT)
Via `RFT > Quality > Unlock by location / Unlock by container / Unlock by item`:
- Unlock all stock at a scope, or partial (specific item, attribute, quantity)
- **Receiving status** can be unlocked (not just user status)
- Communications: STC sent to ERP when reception is closed
### Unlock from ERP (STR Message)
The ERP sends an **STR** message to unlock specific stock. EasyWMS:
1. Removes the user status (or receiving status) from the matching stock
2. Sends **STC** confirmation messages to ERP (provided reception is closed)
The ERP can unlock both user-set locks and receiving-status locks.
### Automatic Unlock (Time-Based)
When a lock has an **end date/time**, EasyWMS automatically removes the status when the date expires.
The job `Delete_StockStatusJob_PR` runs every **15 minutes** and checks for expired locks.
> **Warning:** Locks with durations shorter than 15 minutes cannot be reliably enforced. If sub-15-minute locking is needed, the job periodicity must be changed.
After automatic removal, EasyWMS sends STC to ERP (provided reception is closed).
---
## Quality at Shipping
Shipping order lines can specify a **required** or **preferred** stock status for the assigned stock:
| Mode | Behavior |
|---|---|
| Required status | EasyWMS assigns only stock in the specified status (even if that status blocks picking/shipping) |
| Preferred status | EasyWMS preferably assigns stock with that status; uses other status stock if insufficient |
---
## Cutting Stock Locks
Cutting stock (items with non-consolidating UoM conversions) has special lock behavior due to the **indivisible** nature of coil/roll stretches.
### Partial Lock (Problem at Beginning of Coil)
When only part of a coil has a quality problem:
1. Operator identifies the problematic length and locks it
2. System **splits the stock line into two** (locked portion + clean portion)
3. Operator physically cuts the locked length
4. Optionally, operator relocates the locked/cut stock to another location
5. Picking continues from the unaffected stretch
### Total Lock (Entire Coil)
When the entire coil is defective:
1. Operator selects the entire length and locks it
2. Stock line remains unified (no split)
3. When lock is removed, stock line remains unified
Both partial and total locks can be performed from **RFT** or **ERP** (STR message).
---
## Transactions
| Transaction | Trigger |
|---|---|
| `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.
---
## ERP Integration
| Message | Direction | Purpose |
|---|---|---|
| STR | ERP → WMS | Request stock lock or unlock |
| STC | WMS → ERP | Notify stock status change (per locked/unlocked stock line) |
STC is only sent when the **reception is closed**. For stock from open receptions, changes are visible in the WMS but no ERP notification is generated until close.
---
## Business Rules
- 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.
- 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.
---
## Configuration
| Setting | Location | Description |
|---|---|---|
| Stock statuses master | System master data | Define each status name and which operations it blocks |
| Item receiving profile | Item master → Receiving profile | Auto-set receiving status + duration at reception |
| `Delete_StockStatusJob_PR` | `Configuration > Jobs` | Controls automatic unlock job (default: 15 min) |
---
## Interface
| Path | Equipment |
|---|---|
| `Warehouse > Stock` → lock/unlock actions | PC |
| `Warehouse > Received stock` → lock actions | PC |
| `RFT > Quality > Lock by location` | RFT |
| `RFT > Quality > Lock by container` | RFT |
| `RFT > Quality > Lock by item` | RFT |
| `RFT > Quality > Unlock by location` | RFT |
| `RFT > Quality > Unlock by container` | RFT |
| `RFT > Quality > Unlock by item` | RFT |
| `Configuration > Jobs` | PC |
---
## Common Errors
| Symptom | Cause | Solution |
|---|---|---|
| STC message not sent to ERP after lock | Reception still open | Close the reception; STC will be sent at that point |
| Automatic unlock not happening | Job `Delete_StockStatusJob_PR` disabled or slow | Check job status in `Configuration > Jobs`; verify it runs every 15 min |
| Picking tasks not canceled after lock | Lock does not have "blocks picking" configured | Check stock status master configuration for the applied status |
| Cannot unlock stock from RFT | Operator lacks "Quality" menu access | Check role permissions |
| Cutting stock split not happening after partial lock | Non-consolidating UoM not configured for the item | Verify cutting item configuration; check UoM consolidation flag |
| STC generated without lock set | Reception was already closed at the time of the lock request | Expected behavior; open receptions suppress STC |
---
## Related
- [[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
- [[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
- [[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
- [[cutting-stock]] — Cutting stock has partial/total lock behavior; lock can propagate to cut portions
wiki_old_13-05-2026/concepts/reception.md
+446
View File
@@ -0,0 +1,446 @@
---
title: "Reception"
type: concept
sources:
- areas/receptions/index.md
- areas/receptions/reception_dock/index.md
- areas/receptions/reception_dock/supplier_container.md
- areas/receptions/reception_dock/blind_container.md
- areas/receptions/reception_dock/return.md
- areas/receptions/reception_asn/asn.md
- areas/receptions/reception_pie/pie_recep_point.md
- areas/receptions/reception_pk/pk_recep_point.md
- areas/receptions/reception_admin/receipt_orders.md
- areas/receptions/reception_admin/receipt_close.md
- sources/archives/18_ASN_DirectTransfer.md
- sources/archives/19_ASN_Transfer.md
- sources/archives/29_Split_marchandise_reception.md
related:
- concepts/container.md
- concepts/order-inbound.md
- concepts/putaway.md
- concepts/stock.md
- concepts/product-item.md
- concepts/quality-control.md
- concepts/erp-interface.md
- concepts/transactions.md
- concepts/labels.md
last_compiled: "2026-04-17"
---
# Reception
## Overview
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).
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.
---
## Receipt Document Structure
### Receipt
A receipt is a document that groups all the stock received in a physical delivery. It can be linked to one or more receipt orders, or created standalone (blind/return).
| Property | Description |
|---|---|
| Code | Auto-generated or user-defined |
| Status | Created → In progress → Closing → Closed |
| Receipt order(s) | One or more inbound orders this receipt covers |
| Lines | One line per unique (item, UoM, logistic attributes, status) combination received |
A receipt is created:
- Automatically when the first container of a receipt order is received (if `AutoCreateReceptionFromRecOrder` active)
- Manually by the user from the web interface or RFT (if `ALLOW_CREATE_RECEPTION` active)
- Automatically and transparently by PIE for blind entries
### Receipt Order
A receipt order represents planned incoming stock from the ERP. Received via `ROR` message.
**Header attributes:**
| Property | Description |
|---|---|
| Code | Inbound order code |
| Status | Created → Partially received → Completed → Closed |
| Type | Supplier / Return / Transfer |
| Class | Functional classification (affects logistics treatment) |
| Owner | Mandatory if Owner Extension module installed |
| Supplier | For supplier-type orders |
| Account | For return-type orders |
| Source | Source warehouse for transfer-type |
| Allow lines auto-creation | Whether unexpected items can be received against this order |
| Enable container label printing | Print GS1-128 container labels during receipt |
| Enable stock label printing | Print GS1-128 item labels during receipt |
| Single receipt | Only one receipt auto-created for this order |
**Line attributes:** Item code, UoM, quantity, logistic attributes, stock status, container (optional), number of ERP parcels.
At close of receipt: `REF` sent to ERP. At close of receipt order: `ROF` sent to ERP.
---
## Reception Modes
### 1. Dock Reception (Manual / RFT)
Used for stock arriving physically at a warehouse dock. Operators use an RFT to receive stock.
#### Supply Reception (Supplier)
Stock arriving from a supplier against a receipt or receipt order.
| Sub-mode | Description |
|---|---|
| Multi-SKU LPN (multi-reference) | LPN contains multiple different items. Putaway on equipment or in a stage. |
| Single-SKU LPN (non-identical) | LPN with one item, labeled or not. Supports logistic attribute capture and status. |
| Single-SKU LPN (identical) | All LPNs contain same item and logistic attributes; can receive variable qty. |
| Loose stock | Stock received without a container, placed directly in a stage. |
| Cutting stock | Special flow for indivisible/measured stock (rope, cable, etc.). |
Two putaway modes for all sub-modes:
- **Receipt and putaway**: Stock received on equipment → immediate location search.
- **Receipt on stage**: Stock registered in a stage → putaway done later.
Supports **exclusive reserve** at receipt time: stock received can be pre-reserved for a specific shipping order or route (via `ROR` with reserve). The `CONFIRM_EXCLUSIVE_RESERVE_ASSIGNMENT` parameter controls whether the user must manually select the order when multiple compatible orders exist.
**ERP messages:**
- Receives: `ROR` (receipt order), optional `ASN`
- Sends: `REF` at close
**Transactions:** `CON.RECEP` per container, `STK.RECEP` per stock line.
**RFT path:** `Receipts > Supplier > Loose stock/multi-reference`
#### Blind Reception
Unplanned stock with no prior notification or entry order.
- 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.
**RFT path:** `Receipts > Blind`
#### Returns Reception
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.
- 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`
**ERP messages:** `REF` at close.
**RFT path:** `Receipts > Return`
---
### 2. ASN Reception (Pre-notified Containers)
Used when the ERP has pre-notified containers via `ASN` message before they physically arrive. The containers exist in the virtual **ASN location** with status _Pending receipt_ until physically received.
**Variants:**
| Variant | Description |
|---|---|
| With receipt order | Container explicitly linked to an existing receipt order |
| Without receipt order | Pre-notified but no receipt order; received without receipt association |
| Stacked containers | Hierarchy of stacked/matched containers; `RECEPTION_ASN_CONFIRM_ALL_STACK_CONTAINERS` controls whether all must be confirmed |
| Direct warehouse transfer (same org, near) | Containers transferred without truck; receipt order not created |
| Indirect warehouse transfer (same org, distant) | Transfer needs truck; receipt order created at destination |
| Two simultaneous receipts (same order) | Stock arrives in two trucks; operator creates separate receipts |
| Multiple identical lines | Order lines with same stock merged; quantities split at receipt close |
| Sequential channel storage | Containers for same shipping order/route stored together via channel-fill strategy |
| Dummy containers | ERP notifies quantity without SSCC; dummies created, updated at PIE |
| Exclusive reserve (ASN) | Entire container reserved for one shipping order |
| Exclusive reserve (ROR) | Partial stock reserved for one or more orders |
| Without stock information | Container pre-notified without stock content; exclusive reserve mandatory |
**Stock review at receipt (ASN):**
- `RECEPTION_ASN_SHOW_CONFIRMATION_DIALOG`: if active, user can review/adjust/reject container stock before confirming receipt.
- On rejection: `RECEPTION_FORBID_MOVE_FROM_ASN` controls whether container stays in ASN (true) or moves to Lost&Found and sends `ASK` (false).
**Strict mode for exclusive reserves:**
- `USE_EXCLUSIVE_RESERVE_STRICT_MODE`: if active, receipt blocked when shipping order/route referenced in reserve doesn't exist.
**ERP messages:**
- Receives: `ASN` (pre-notification)
- Sends: `ASO` on receipt, `ASK` on rejection, `REF` on receipt close, `ROF` on order close
**Transactions:** `CON.CREATE` + `STK.CREATE` when ASN received, `CON.ASN.001` + `STK.ASN` at receipt, `CON.MOVE` + `STK.MOVE` for location change, `CON.DELETE` + `CON.CNL.ASN` on rejection.
**UI paths:**
- Web: `Warehouse > ASN LPN`, `Receiving > Receipt orders`
- RFT: `Receipts > Notices`
#### 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.
- 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.
#### 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.
| Setting (destination warehouse) | Effect |
|---|---|
| `AutoCreateReceptionFromRecorder = true` | A reception is created automatically when the first container is read. Otherwise the operator creates it manually. |
| `AutoCloseInboundOrder = true` | Closing the reception auto-closes the inbound order and generates `ROF02`. |
Operator flow: RFT menu **Réception → Préavis** (of the destination warehouse) → scan each container → close.
**ERP messages generated:**
- `ASO01` at each container reception
- `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`.
Used in production at RAUD: transfers from hub LRM to spoke sites (MOR, LAM, …).
---
### 3. PIE Reception (Automated Entry Station)
The **PIE** (Pallet Identification Entry) is an automated gate station for automatic warehouses. It reads LPN labels automatically via scanner, validates dimensions/weight/condition, and routes containers into the warehouse or to a rejection/reconditioning station.
**Modes:**
- **Automatic PIE**: reads labels automatically; on error, diverts to rejection.
- **Semi-automatic PIE**: operator scans label manually when auto-read fails; container waits at station.
**PIE reception variants:**
| Variant | Description |
|---|---|
| Blind (unknown) container | Container not pre-notified; PIE auto-creates blind receipt transparently; closed at end. |
| Pre-notified, without receipt order | `ASN`-notified container, no linked receipt order; `ASO` sent at receipt. |
| Pre-notified, with receipt order | Container linked to receipt/order; ALLOW_CREATE_RECEPTION controls auto-creation; `REF`+`ROF` sent at close. |
| Exclusive reserve | Container with reserved stock; `USE_EXCLUSIVE_RESERVE_STRICT_MODE` controls behavior when order doesn't exist. |
| Without stock info | No stock in `ASN`; exclusive reserve required; routed via inbound conveyors. |
| Half pallets | Two half-pallets on a base pallet; slave/dummy container created; `Use slave container` setting in PIE config. |
**Rejection/Reconditioning routing:**
- If container has issues (dimensional, labeling): diverted to rejection or reconditioning station.
- At reconditioning, operator resolves issue and retries.
- Container considered **received** (ASO sent) if issue is dimensional/physical.
- Container **rejected** (receipt not possible) if receipt order data is missing or incompatible.
**Configuration:**
- PIE working mode: Automatic / Semi-automatic
- Auto container creation: enabled in EasyS or via `Stations` view action "Allow create container"
- Number of labels: max barcodes per GS1 label
- Avoid moving from ASN: per-station toggle
**ERP messages:** `REF` (blind close), `ASO` (pre-notified receipt), `ASK` (rejection)
**Transactions:** `CON.CREATE` + `STK.CREATE` (blind), `CON.ASN.001` + `STK.ASN` (pre-notified receipt), `CON.MOVE` + `STK.MOVE` (location change)
**UI path:** `Control > Stations` (web)
---
### 4. PK Reception (Picking Conveyor)
Pre-notified containers received via a **Picking Conveyor (PK)** workstation in automated warehouses.
- Container code scanned from workstation → container introduced into warehouse via inbound conveyors.
- Variants: with or without receipt order, stacked/matched, with/without divisions.
- If receipt order linked but doesn't exist: operator offered choice to continue (as no-order receipt) or leave container in ASN.
- `ALLOW_CREATE_RECEPTION`: controls auto-receipt creation from PK.
- `AutoCloseReception` / `AutoCloseInboundOrder`: control auto-closing.
**ERP messages:** `ASO` at receipt, `ASK` on rejection, `REF`+`ROF` at close.
**UI path:** `Picking` workstation → `Enter containers`
---
## Receipt Closing
Receipts can be closed **manually** or **automatically**.
### Manual Closing
- 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`
### Automatic Closing
- Triggered when all expected stock has been received and no excess allowed.
- Parameter: `AutoCloseReception`
- Same allocation logic as manual.
**Communications at close:** `REF` to ERP.
**Transactions:** `REC.CLS` (receipt close), `INO.CST` (receipt order close, if linked).
---
## Parameters
| Parameter | Effect |
|---|---|
| `ALLOW_CREATE_RECEPTION` | Allows creating a receipt from RFT/PIE/PK if none found |
| `AutoCreateReceptionFromRecOrder` | Auto-creates receipt when receipt order stock still pending |
| `AutoCloseReception` | Auto-closes receipt when all expected stock received |
| `AutoCloseInboundOrder` | Auto-closes receipt order when receipt closed (valid status required) |
| `RECEPTION_ASN_SHOW_CONFIRMATION_DIALOG` | Show stock review/adjust/reject dialog after reading ASN container |
| `RECEPTION_FORBID_MOVE_FROM_ASN` | If true, rejected ASN container stays in ASN; if false, moves to L&F |
| `RECEPTION_ASN_CONFIRM_ALL_STACK_CONTAINERS` | All containers in a stacked hierarchy must be confirmed |
| `USE_EXCLUSIVE_RESERVE_STRICT_MODE` | Blocks receipt if reserve's shipping order doesn't exist |
| `CONFIRM_EXCLUSIVE_RESERVE_ASSIGNMENT` | User must manually select shipping order for exclusive reserve when multiple compatible |
| `CREATE_ALIAS_ON_RECEPTION` | Allows declaring a scanned code as an item alias at receipt |
| `RECEPTION_DEFAULT_CONTAINER_TYPE` | Default LPN type suggested at receipt |
| `RECEPTION_DEFAULT_HEIGHT_TYPE` | Default height type suggested at receipt |
| `RECEPTION_NUM_DAYS_PRODUCTION_DATE_MARGIN` | Future production date margin allowed at receipt |
| `RETURN_RECEPTION_PREFIX` | Custom prefix for return receipt codes |
| `SKIP_RF_CONFIRMATION_MESSAGES` | Hides receipt/order close confirmation messages on RF |
| `MAX_RECEPTIONS_TO_CLOSE_JOB` | Max receipts in _closing_ status selected per job run |
| `NUM_EVENTS_PER_PARTIAL_COMMIT` | Events confirmed per block in closing process |
---
## ERP Integration
| Message | Direction | Trigger |
|---|---|---|
| `ROR` | ERP → WMS | Creates/updates receipt orders (Receipt Order Request) |
| `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 |
| `ROF` | WMS → ERP | Receipt order close confirmation |
| `STV` | WMS → ERP | Stock adjustment in pre-notified container during review |
For full message definitions see [concepts/erp-interface.md](../concepts/erp-interface.md).
---
## Labels at Reception
- **LPN labels**: GS1-128 labels can be printed for containers at receipt; label format controlled by `CONTAINER_LABEL_DEFAULT_FORMAT`.
- **Item labels**: Printed for items not labeled at origin; enabled via receipt order `Enable stock label printing`.
- **Multi-label reading**: When containers always arrive labeled in GS1-128, multi-reading mode allows scanning labels in any order.
- **Label reprint**: Available from RFT if a label is damaged or content changes.
See [concepts/labels.md](../concepts/labels.md) for complete label reference.
---
## Common Errors
**Receipt order not found from RFT:**
- 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:**
- 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.
**Receipt auto-close does not trigger:**
- 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:**
- 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.
**Multiple lines created for same item at receipt close:**
- Cause: Exclusive reserve splits stock lines into reserved and unreserved portions.
- Expected behavior; each line has distinct reserve linkage.
**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.
---
## 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.
**Flow:**
1. Stock received on equipment in loose mode
2. WMS computes the quantity needed to reach PDL capacity
3. That quantity is dropped onto the **PICKING buffer**
4. The remainder is dropped onto the **RESERVE buffer**
5. Downstream, a second operator puts away: PICKING buffer → PDLs ; RESERVE buffer → rack locations
**Buffer configuration:**
| Buffer | Storage mode | Storage zone | Work zone | Sub-warehouse |
|---|---|---|---|---|
| PICKING | Loose stock | RECEPTION | RECEPTION | PICKING |
| RESERVE | **Container + stock** (⚠️ *not* "Container only", else never proposed) | RECEPTION | RECEPTION | RESERVE |
> ⚠️ For projects with group-preparation flows, ungrouping stations and wall locations must **not** belong to the PICKING sub-warehouse.
> Equipment of type RECEPTION must only have access to the RECEPTION work zone, and vice versa.
> Routes must be explicitly created for both buffers (equipment group + station).
**Putaway strategies required (4):**
| # | From | To | Key criteria/rules |
|---|---|---|---|
| 1 | Reception equipment (code `REC_*`) | PICKING buffer | Destination zone = PICKING, location with assigned item (not full), partial putaway allowed |
| 2 | Reception equipment (type RECEPTION) | RESERVE buffer | Destination zone = RESERVE |
| 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:**
| Situation | Action |
|---|---|
| No PDL for the item | Drop on RESERVE |
| PDL exists and is not full | Drop on PICKING the exact quantity to reach capacity; drop the rest on RESERVE |
| PDL exists and is full | Drop on RESERVE |
| Replenishment task already in progress toward that PDL | Drop on RESERVE |
> ⚠️ 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_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).
---
## Interface Paths
| Path | Equipment | Description |
|---|---|---|
| `Receiving > Receipt orders` | PC | Manage receipt orders |
| `Receiving > Receipt order lines` | PC | Manage receipt order lines |
| `Receiving > Receipts` | PC | View and close receipts |
| `Warehouse > ASN LPN` | PC | View pre-notified (pending) containers |
| `Control > Stations` | PC | PIE station management |
| `Receipts > Supplier` | RFT | Supplier reception (dock) |
| `Receipts > Blind` | RFT | Blind reception (dock) |
| `Receipts > Return` | RFT | Return reception |
| `Receipts > Notices` | RFT | ASN pre-notified containers |
| `Picking workstation > Enter containers` | Workstation | PK reception |
---
## Related
- [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/putaway.md](../concepts/putaway.md) — What happens after stock is received
- [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/quality-control.md](../concepts/quality-control.md) — Incoming stock quality locks
- [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/transactions.md](../concepts/transactions.md) — CON.RECEP, STK.RECEP, CON.ASN.001, REC.CLS
wiki_old_13-05-2026/concepts/replenishment.md
+402
View File
@@ -0,0 +1,402 @@
---
title: "Replenishment"
type: concept
sources:
- areas/replenishments/replenishment_admin/replenishment_strategies.md
- areas/replenishments/replenishment_admin/picking_locations.md
- areas/replenishments/replenishment_admin/efficiency_mode.md
- areas/replenishments/replenishment_admin/dynamic.md
- areas/replenishments/replenishment_admin/automatic_replenish.md
- areas/replenishments/replenishment_admin/conditions.md
- areas/replenishments/replenishment_pk/index.md
- areas/putaway/configurations/putaway_configuration01.md
- custom/analyse_fonctionnelle.md
- sources/archives/05_Gestion_picking_dedie.md
- sources/archives/20_Strategies_reapprovisionnement.md
- sources/archives/30_Reapprovisionnement_2_sous_entrepots_zone_intermediaire.md
related:
- concepts/picking.md
- concepts/putaway.md
- concepts/stock.md
- concepts/container.md
last_compiled: "2026-04-17"
---
# Replenishment
## 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.
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
2. **Sub-warehouse replenishment** — moving stock from one sub-warehouse to another to balance inventory
## Picking Dedicated Locations (PDL)
### PDL Concept
A PDL is a location with an item assignment that designates it as the primary picking source for that item. Key properties:
| Property | Description |
|---|---|
| **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 |
| **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 |
| **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:**
| Threshold type | Description | Notes |
|---------------|-------------|-------|
| **Pieces (quantity)** | Replenish when stock drops below N units (in conversion UoM or base UoM) | Simplest mode; no container-count knowledge required |
| **Container count** | Replenish when number of containers in the PDL drops below N | Requires the PDL to track container presence |
| **% of full container** | Replenish when stock falls below X% of a full container's standard quantity | Requires conversion definition (UoM × container conversion = full quantity); allows absorbing incoming container excess |
- **Capacity**: maximum stock quantity allowed at the PDL
**For container-mode PDLs:**
- **Minimum containers**: replenish when container count drops below this
- **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
**EasyS — Location setup**, check :
- `Allow product location`
- `Allow replenish at source`
- `Allow picking`
**SmartUI — `Entrepôt → Emplacements consacrés au picking`** :
- Enter the **replenishment level** (minimum threshold)
- Enter the **maximum capacity**
- Check **Étiquetté** (mandatory)
- 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.
> ⚠️ **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.
>
> 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
| Method | Trigger |
|---|---|
| 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 |
| 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).
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
- 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
Partition labels can be printed for a range of locations with optional text (item code, UoM, logistic attributes, or custom text).
### PDL Release on Empty
When enabled, a PDL is released (item assignment removed) when the location becomes empty:
- **Automatic replenishment mode**: PDL is only released if no valid replenishment stock remains in the entire warehouse
- **Manual replenishment mode**: PDL is released immediately when empty (no automatic tasks to prevent it)
Use case: seasonal warehouses where item rotation is planned.
## Replenishment Strategies
Replenishment tasks are generated based on enabled **replenishment strategies**. Four strategy types exist.
### SmartUI / French terminology mapping
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 |
| **"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 |
**EasyS location setup (common to all three):**
- Picking locations to replenish: `Allow picking` + `Allow product location` + `Allow replenish`
- 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**
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)
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
6. Confirm source stock is eligible (no blocking status, no location lock, not already assigned to shipping)
### Efficiency mode — SmartUI values
| FR field | Behaviour |
|---|---|
| **Efficacité** | Minimise the number of tasks needed to reach capacity |
| **Emplacement le plus proche** | Pick the available source closest to the PDL |
| **À vider** | Pick the source that will empty the reserve location (limited value when replenishing by container) |
### 1. Top-off (Particular Demand)
**Trigger:** Manual request from RFT or web interface for specific location(s) or aisles.
Used when an operator notices a PDL is running low and requests immediate replenishment before the stockout strategy would have fired, or for ad-hoc needs.
| Configuration | Description |
|---|---|
| Efficiency mode | Efficiency / To empty / Nearest location |
| Logic | Before efficiency / After efficiency |
| Particularized for | Filter by item, owner, item type, destination sub-warehouse, destination zone |
| Stock selection | Restrict origin to specific sub-warehouse or zone |
### 2. Shipping Demand (Dynamic)
**Trigger:** Shipping order that has "dynamic replenishment" enabled, or manual/ERP request for specific orders. Also triggerable from RFT filtered by release date or load date.
System checks pending shipping orders to determine what items and quantities are needed. It then:
1. Finds existing PDLs for the requested items and checks if they have enough stock
2. If insufficient → creates replenishment tasks to fill existing PDLs
3. If no PDL exists → searches for empty candidate locations with automatic item assignment mode + allow picking + allow replenish → creates **dynamic PDLs** with capacity = quantity needed for pending orders
Dynamic PDLs are adjusted in subsequent runs (capacity updated as orders are created or canceled). Fixed PDLs are never modified by dynamic replenishment.
**Item configuration required:** item shipping profile must have "dynamic replenishment" active.
**ERP trigger:** `SOR` message requests replenishment for specific shipping orders.
| Configuration | Description |
|---|---|
| Efficiency mode | Efficiency / To empty / Nearest location |
| Logic | Before efficiency / After efficiency |
| Particularized for | Item, owner, item type, putaway profile, destination sub-warehouse/zone, use item temperature |
| Stock selection | Restrict origin to specific sub-warehouse or zone |
### 3. Stockout (Automatic)
**Trigger:** Automatic background job `TryToReplenishProductLocations` runs every minute.
When stock at a PDL drops below its replenishment level, the job generates replenishment tasks automatically without any manual intervention.
| Configuration | Description |
|---|---|
| Efficiency mode | Efficiency / To empty / Nearest location |
| Logic | Before efficiency / After efficiency |
| Particularized for | Item, owner, item type, destination sub-warehouse/zone |
| Stock selection | Restrict origin to specific sub-warehouse or zone |
**PDL must have "Enable replenishment" activated** in the Picking Dedicated Locations view.
**Parameter `MAX_REPLENISHED_PL_ROUTINE_JOB`:** Maximum PDLs processed per job run (0 = unlimited). Controls processing complexity; default frequency of every minute ensures adequate throughput.
### 4. Sub-warehouse Replenishment
**Trigger:** Manual request (all items in need, or selected items).
Used when the warehouse has multiple sub-warehouses and stock must be moved between them to maintain minimum levels in each.
Strategies are sequenced to determine which sub-warehouses are replenished first.
| Configuration | Description |
|---|---|
| Destination sub-warehouse | Target sub-warehouse for the stock |
| Destination station | Destination station in target sub-warehouse |
| Efficiency mode | To empty / Least movements (different modes than PDL replenishment) |
| Logic | Before efficiency / After efficiency |
**Limitation:** does not support cutting stock in non-consolidating UoM conversions.
### 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.
## Efficiency Modes
Efficiency mode determines which source stock is selected for the replenishment task.
**For PDL replenishment:**
| Mode | Logic |
|---|---|
| **Efficiency** | Select sources that have at least the quantity needed; among ties, apply outbound logic; tiebreak by quantity (highest to lowest) |
| **To empty** | Select sources that will be completely emptied by the replenishment task; among ties, apply outbound logic; tiebreak by quantity (lowest to highest) |
| **Nearest location** | Select sources closest to the PDL by physical distance; from those with enough stock |
**For sub-warehouse replenishment:**
| Mode | Logic |
|---|---|
| **To empty** | Same as above |
| **Least movements** | Minimize number of picking tasks; select sources with the requested quantity or largest available; among ties, apply outbound logic; tiebreak by quantity (highest to lowest) |
**Logic position:** "Before efficiency" applies outbound logic (FEFO, FIFO, LIFO) as the primary sort criterion; "After efficiency" applies it only to break ties after the efficiency criterion.
## Stock Eligibility for Replenishment
Stock is valid for replenishment if:
- Belongs to the same item (and optional owner, item type) as the PDL
- Has a status that allows moving and replenishing
- Not in a location with an active counting task
- Not part of an in-process replenishment or picking task (unless certain conditions allow it)
- Location and aisle allow replenishment at source; no extraction errors; no movement locks
- Logistic attributes match PDL configuration (batch, dates, status)
- If PDL is configured for a specific stock status, only stock in that status is eligible
## Dynamic Replenishment Process Detail
Dynamic replenishment runs periodically (or on manual trigger) and follows this flow:
1. **Get shipping orders** with dynamic replenishment enabled
2. **Identify items and quantities** required across all such orders
3. **Check fixed PDLs** for each item: is there enough stock?
4. **For items with insufficient PDL stock:**
- Check if there is valid replenishment source stock
- If yes: generate replenishment tasks to fill fixed PDLs to capacity
5. **For items with no PDL at all (or fixed PDL at capacity):**
- Find empty candidate locations (allow item assignment, automatic assignment mode, allow picking, allow replenish)
- Create a **dynamic PDL** with capacity = quantity needed for pending orders
- Generate replenishment tasks for the dynamic PDL
6. On next run: adjust dynamic PDL capacity if demand has changed
## 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.
**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)
- A **container relocation task** (or stock relocation) is generated to move the remaining stock from the dynamic PDL back to a valid bulk storage location
- The putaway engine determines the destination using the item's putaway strategy
- Once emptied, the dynamic PDL assignment is removed and the location becomes available for reassignment
**Configuration**: the emptying job frequency is configurable per warehouse. It can be run at off-peak times (e.g., at night or between shifts) to avoid contention with active picking.
This mechanism prevents dynamic PDLs from accumulating as "orphan" locations with stranded stock.
## Automatic Replenishment (Stockout) Process Detail
Background job `TryToReplenishProductLocations` (every minute):
1. For each PDL with automatic replenishment enabled
2. Check current stock quantity against replenishment level
3. If below threshold:
- Find valid source stock (applying efficiency mode and logic)
- Generate replenishment task: move stock from source to PDL up to PDL capacity
4. Respect `MAX_REPLENISHED_PL_ROUTINE_JOB` limit per run
## Cutting Stock Replenishment
Cutting stock (rope, cable, chain) requires special handling:
- Can only be picked from coil shelf locations (picking dedicated location for cutting loose stock)
- For **shipping demand strategy**: replenishment tasks are only generated when: no pending tasks exist for the reel in the PDL AND there is still unassigned stock to fulfill orders
- Exception: if a stockout strategy is also active AND stock is at/below replenishment level → generate replenishment regardless of task state
- Not supported for sub-warehouse replenishment in non-consolidating UoM conversions
## Replenishment from Putaway
When placing a container or stock into a location, the putaway engine checks if the destination location is a PDL for the item being placed:
- Strategy 1 (sequence 1): place directly into the PDL if capacity allows
- Strategy 2 (sequence 2): place in storage near the PDL (sort by "Distance to assigned location")
- The system can automatically create a PDL at the putaway destination (parameter `UNLOAD_CREATE_PRODUCT_LOCATION`)
See [Putaway](putaway.md) for the full strategy pipeline.
## Inter-sub-warehouse Replenishment via an Intermediate Buffer
When a single equipment cannot traverse from the reserve sub-warehouse to the picking sub-warehouse (safety rules, certification, aisle geometry), a **Transit transport element** acts as an intermediate drop point: one equipment drops the pallet on the buffer, another picks it up and finishes the replenishment.
### Typical setup
- **Sub-warehouse A** (`WHST_ANCIEN_BAT`) — PDLs to replenish
- **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 |
| 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.
### Flow
1. Replenishment is triggered → a task is generated from the reserve to the PDL
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").
Upstream MSSCC documentation: `replenishments/intermediate_stations.md` and `EasyS/configurations/IntermediateET/index.md`.
## Replenishment in Automatic Warehouses (PK)
In automatic warehouses, the picking conveyor (PK) generates demand that drives replenishment. When a container at the PK runs out of stock for a task:
1. Operator signals "wait for replenishment" or the system detects PDL is empty
2. EasyWMS checks if another container with the same item can be extracted from the automatic warehouse
3. If yes: a task is generated to bring the replenishment container to the PK
4. PK operations pause until replenishment arrives (configurable)
## Common Errors
**Replenishment task not generated for empty PDL:** PDL has "automatic replenishment" not enabled, or no stockout strategy is enabled, or no valid source stock found. Enable replenishment on the PDL; check source location availability and status.
**Dynamic PDL created with wrong capacity:** Shipping order was created/canceled between job runs. Capacity is recalculated on next run and adjusted. No manual intervention needed if system is running correctly.
**Replenishment task generated but not executed:** Replenishment source has a lock, or the aisle is blocked, or no route exists between source and PDL. Resolve the lock/block; check route configuration.
**PDL not proposed for picking despite having stock:** Stock assignment strategy doesn't have "Prioritize picking dedicated locations" enabled, or the PDL's logistic attributes don't match the shipping order line. Check strategy priorities and PDL configuration.
**Stock mixing conflict at PDL:** During replenishment unload, system warns of logistic attribute conflict (e.g., different batches). System does NOT block the task (to avoid deadlock situations), but operator must decide whether to proceed. If mixing is not desired, configure PDL with specific logistic attributes.
**PDL released unexpectedly:** "Delete when empty" is enabled but warehouse still needs the item. Disable "Delete when empty" for year-round items; use it only for seasonal items.
**Cutting stock replenishment not triggered:** Pending tasks exist for the reel in the PDL location, which blocks demand-strategy replenishment. Wait for tasks to complete, or use a stockout strategy as well to override the task-pending check.
## Interface Paths
| Interface | Path |
|---|---|
| Web — replenishment strategies | "Configuration" → "Replenishment strategies" |
| Web — sub-WH replenishment strategies | "Configuration" → "Replenishment strategies between sub-warehouses" |
| Web — picking dedicated locations | "Warehouse" → "Picking dedicated locations" |
| Web — enable/disable automatic replenishment | "Warehouse" → "Picking dedicated locations" → "Enable replenishments" |
| Web — delete when empty | "Warehouse" → "Picking dedicated locations" → "Delete when empty" |
| Web — label printing | "Warehouse" → "Picking dedicated locations" → label action |
| Web — shipping demand replenishment | "Shipping" → "Shipping orders" → "Enable replenishment" |
| RFT — particular demand replenishment | Menu "Replenishment" → specific location/aisle |
| RFT — shipping order demand | Menu "Replenishment" → "For shipping orders" |
| RFT — assign item to location | Menu "Utilities" → "Assign item to loc." |
| 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
- [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
- [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
- [Location](location.md) — PDLs are locations with item assignment; "Allow replenishment source/target" logics control eligibility
wiki_old_13-05-2026/concepts/shipping.md
+475
View File
@@ -0,0 +1,475 @@
---
title: "Shipping"
type: concept
sources:
- areas/shipping/shipping_admin/index.md
- areas/shipping/shipping_admin/order_release.md
- areas/shipping/shipping_admin/shipping_order.md
- areas/shipping/shipping_admin/shipping_order_creation.md
- areas/shipping/shipping_admin/stock_assign.md
- areas/shipping/shipping_admin/stock_assign_strategies.md
- areas/shipping/shipping_admin/waves_creation.md
- areas/shipping/shipping_admin/groups_creation.md
- areas/shipping/shipping_admin/load.md
- areas/shipping/shipping_admin/loads_manualcreation.md
- areas/shipping/shipping_admin/loads_close.md
- areas/shipping/shipping_admin/route.md
- areas/shipping/shipping_admin/prepackaging_config.md
- areas/shipping/shipping_admin/prepackaging_erp.md
- areas/shipping/shipping_admin/buffer_dock_assignment.md
- areas/shipping/shipping_admin/pk_mp_assignment.md
- areas/shipping/shipping_admin/ps_groups_config.md
- areas/shipping/shipping_admin/shipping_order_mixing.md
- areas/shipping/shipping_admin/sequencing.md
- areas/shipping/shipping_truck_load/index.md
- areas/shipping/shipping_truck_load/truckload_containers.md
- areas/shipping/shipping_truck_load/truckload_stock.md
- areas/shipping/shipping_truck_load/truckload_packages.md
- areas/shipping/shipping_truck_load/virtual_dock.md
- areas/shipping/shipping_consolidation/shipping_consolidation_onstation.md
- areas/shipping/shipping_auto/container_closure.md
- areas/shipping/shipping_admin/inventory_after_picking.md
- areas/shipping/parameters.md
- sources/archives/09_Modeles_expedition.md
- sources/archives/17_Fonctionnement_routes_tournees.md
- sources/archives/22_Chargement_camion.md
- sources/archives/32_Fusion_commandes_Merge.md
related:
- concepts/picking.md
- concepts/replenishment.md
- concepts/container.md
- concepts/crossdocking.md
- concepts/reception.md
last_compiled: "2026-04-17"
---
# Shipping
## 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 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).
## Shipping Order
A shipping order (SO) represents a customer's purchase order, a supplier return, or an inter-warehouse transfer. It contains:
- Header: customer, carrier, dock, stage, consolidation location, load, route, wave/group, priority, dates
- Lines: item, UoM, requested quantity, logistic attributes (batch, expiration, etc.), required/rejected statuses, required container type
### Shipping Order Types
| Type | Description |
|---|---|
| Standard | Normal outbound order for a customer |
| Return to supplier | Stock returned outbound to a supplier |
| Transfer | Inter-warehouse stock transfer |
| Desk order | Stock requested from a retail desk inside the warehouse |
### Shipping Order Lifecycle
| Status | Meaning |
|---|---|
| **Created** | Order received/created; no stock assigned yet |
| **Released** | Stock assigned; tasks generated for preparation |
| **In preparation** | Active picking/shipping tasks being executed |
| **Prepared** | All lines prepared; stock at dock/stage waiting for loading |
| **Loaded** | Stock loaded onto transport |
| **Closed** | ERP notified of shipped quantities; documentation issued |
| **Archived** | Historical record; no further modifications allowed |
### Order Management Operations
| Operation | Description |
|---|---|
| Create (manual) | Manually create from web interface (rare; for ERP downtime or special requests) |
| Edit lines | Increase/decrease/cancel lines during preparation (ERP changes if received from ERP) |
| Assign stock | Manually trigger stock assignment before release |
| Reserve stock | Pre-reserve specific stock or maximum available for an order or account |
| Assign dock/stage | Manually assign shipping dock or staging area |
| Assign PK/MP (automatic WH) | Assign picking conveyor + preparation zone for automatic warehouse picking |
| Assign PS group | Assign outbound conveyor group for automatic warehouse shipping |
| Stop | Freeze order at a configurable point; prevents further modifications |
| Pause | Temporarily halt preparation; assigned stock retained |
| Restart | Resume paused order; tasks generated to continue with held stock |
| Cancel | Cancel order (if not fully prepared); stock released; ERP notified |
| Close | Finalize partially-prepared order; confirm shipped quantities to ERP |
| Archive | Move to historical records |
| Mix orders | Configure strategies to mix different orders in same client container |
## Order Release
Releasing an order is the trigger that moves it from "Created" to "In Preparation":
1. **Assign stock**: system selects specific stock for each line (see [Picking](picking.md) for assignment strategy details)
2. **Assign PK/MP** (automatic warehouses): if auto-assignment configured, picking conveyors and preparation zones are allocated
3. **Generate tasks**:
- Picking tasks for all lines with stock in picking locations
- Shipping tasks (full container moves) for stock in locations that allow shipping
- If dock/stage assigned: loading tasks to move prepared stock to dock/stage
Tasks are created in parallel as stock is assigned, following line number order, except when:
- Some lines are marked **critical** or **required for shipping** (inter-line dependencies)
- **Negative picking** conditions are met (excess must be extracted before picking)
- **Sequencing** rules require specific task ordering
Release can be:
- **Manual**: warehouse manager selects orders in web UI
- **Automatic**: order has auto-release date/time set, or is triggered by a **shipping template**
**ERP message sent:** `SOC` (order status change)
**Transaction recorded:** `OUT.CST`
**Parameter:** `MAX_AUTORELEASED_OUTBOUNDORDERS` — maximum orders auto-released simultaneously
### Release by Sub-warehouse
For warehouses with multiple sub-warehouses, orders can be released sub-warehouse by sub-warehouse. Each sub-warehouse release generates tasks only for its stock. ERP is notified of each sub-warehouse release.
## Grouping Strategies (Waves, Groups, Fusions)
Grouping shipping orders reduces operator travel by combining multiple orders into a single picking round.
### Groups
Multiple shipping orders are picked together (same picking path). After picking, stock is **ungrouped** at an ungrouping station (UAP) to separate each order's stock into its own containers.
- Manual or automatic creation (via shipping templates)
- Include/exclude orders after creation
- Close and archive when last order is ungrouped
- Cancel: prepared stock released; orders must be re-prepared separately
### 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.
### Waves
Each wave fills operators' equipment to maximum capacity. Orders in a wave can be included fully or partially (by lines). Waves can be:
- **Grouped** (stock ungrouped at UAP after picking)
- **Ungrouped** (stock distributed directly on equipment during picking)
Special case: if all wave orders are "Single Units" with the same destination, ungrouping station is bypassed.
Operators select which wave to execute (from released waves). Wave closes automatically when all included orders are archived.
### Shipping Templates
Automation mechanism that selects orders matching configured criteria and:
- Creates groups, fusions, or waves automatically
- Assigns ungrouping station
- Releases the grouping
Templates are defined from `Configuration → Modèle d'expédition` and follow a **sequence-number priority** (lower = higher priority, identical to putaway strategies).
**Common base fields (every template type)** :
| Field | Description |
|---|---|
| Code | Template code |
| Prefix | Group/wave name prefix |
| Priorité | Priority of the created wave/group |
| Mode d'assignement | Auto release / manual release |
| Nb max de groupes créés | Cap on active groups/waves |
| Nb max de groupes libérés | Cap on groups/waves in preparation |
| Trié par | Order in which orders are consumed (recommended : creation date ASC) |
A stock-assignment strategy and/or a prepackaging strategy can be attached to the template.
**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.
- **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 :
- **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** :
```csharp
// Criterion on the outbound order itself (ex: orders imported with source = "WEB")
o.Source == "WEB"
// Criterion on an outbound order line
l.Item.ItemType.Code == "FROID"
```
## Prepackaging
Prepackaging calculates the number and type of client containers (cartons, pallets) needed to ship an order before picking begins, maximizing container utilization.
| Prepackaging source | Description |
|---|---|
| **Calculated by EasyWMS** | System uses item dimensions + available container formats to compute optimal packing |
| **Calculated by ERP** | ERP sends container count/type via messaging before release |
| **Calculated by operator** | Operator manually enters container count (for small warehouses) |
**When prepackaging is applied:**
- **During picking**: system guides operator on which container to use for each item as picking progresses
- **During consolidation**: at a packaging stage/consolidation station, system guides stock redistribution into computed containers
## Consolidation
Consolidation redistributes prepared stock from multiple source containers (or loose stock) into final shipping packages, optimizing the number of outbound containers.
Typical need: order prepared from multiple origins (manual + automatic aisles, different work areas), resulting in many partial containers. Consolidation combines them.
**Setup:** consolidation station (buffer-type location) must be assigned to the shipping order **before release**. After release, any picked/shipped containers are sent to the consolidation station automatically.
> Detailed prepackaging mechanics, tested behaviors, and the SOR02 `<PrepackagingConfiguration>` structure are covered in [Prepackaging](prepackaging.md).
**Process (at conveyor):**
1. Operator at consolidation station scans source container SSCC
2. System guides transfer of stock into destination container(s)
3. Empty source containers are deleted if configured; task cancellation follows
**Transactions:**
- `CON.CREATE` — new consolidation container created
- `STK.MOVE` — stock moved from source to destination
- `CON.DELETE` — empty source container deleted
- `TSK.CANCEL` — tasks for deleted container canceled
HPKS (laser pick-term tray) illuminates the destination division for easy identification.
## Routes
Routes group shipping orders when containers must be **loaded in stop sequence** so they can be unloaded at each delivery stop without rearranging.
Route structure: Route → Stops → Shipping orders per stop
Route management operations:
| Operation | Description |
|---|---|
| Create | Manual or from ERP messaging |
| Assign dock/stage | Set staging area and loading dock |
| Release | Begin preparation of all included orders; ERP notified |
| Monitor | Track progress; pause/stop/change priority |
| Include/exclude orders | Add or remove orders during preparation |
| Modify stops | Change stop numbers / order sequence |
| Pause/Resume | Pause route; ERP notified of paused orders |
| Stop/Restart | Stop route; ERP notified; restart resumes with held stock |
| Close/Archive | Close after last stop loaded; print transport documents |
| Cancel | Cancel route; decide if included orders continue as separate SOs |
**Important:** route loading must respect stop order. RFT warns operator if container is loaded in wrong sequence.
### RUT File (TMS-driven Routes)
When route sequencing is planned by a TMS, the ERP sends a **`RUT` file** instead of individual `SOR` messages. The RUT carries a route header plus all the constituent orders, each tagged with its **stop number**. The loading discipline is **inverse to stop number** : the container destined for the *last* customer is loaded *first*, so unloading proceeds naturally stop after stop.
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.
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.
- ⚠️ The load must have a **dock** before truck loading can start.
5. **RFT truck loading.** Scan containers in the expected sequence (`n_max` → `n_max-1` → … → `1`). Scanning a container with the wrong stop number prompts a warning asking whether to proceed anyway.
> 💡 Custom idea repeatedly requested by customers : display the next expected container on the RFT so the operator can target it directly on the staging area.
## Loads
Loads represent a physical transport vehicle (truck, van) that will carry one or more shipping orders or one route.
| Load type | Description |
|---|---|
| **Planned** | Created in advance; specific orders assigned; only assigned containers/stock can be loaded |
| **Unplanned** | Created "on the fly" at loading time from RFT; orders must allow unplanned loading |
| **Route loads** | One route per load; containers must be loaded in stop sequence |
### Load Lifecycle
1. Create load (manual or auto on order release)
2. Assign dock
3. Assign orders/routes
4. Load containers/stock/packages (via RFT)
5. Close load → ERP notified, transport documents printed
**Load operations:**
- Monitor (detect incidents, check progress)
- Pause / Resume loading
- Unload container/stock (if loading error)
- Undo preparation (release stock back to warehouse)
- Remove excesses (if order quantities changed after preparation)
- Partial close (close without all containers loaded, if configured)
- Auto-close (triggered automatically when last container/package is loaded)
### 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.
### 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
- **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):**
| Mode | Description |
|---|---|
| **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 — 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:**
| Option | Effect |
|---|---|
| Truck plate number | Mandatory / Not required / Optional |
| Seal number | Mandatory / Not required / Optional |
| **Auto-close** | Close on last container loaded → stock exit + order close |
| **Partial close** | Allow closing with uncharged containers; a **remainder load** is auto-created (codes suffixed `_2`, `_3`, …) |
| 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 — 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
> ℹ️ 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**.
**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 (RFT Process)
Operators at the dock register each item loaded using the RFT:
### Containers
- **Planned**: load only containers from assigned orders
- **Unplanned**: create load on the fly; scan any container
- **Route**: enforce stop-order loading; system alerts if wrong sequence
- **Stacked containers**: load stacked units to maximize truck height utilization
- **Direct to dock**: containers automatically considered loaded when they arrive at dock (no explicit RFT scan)
### Stock (loose stock)
- Similar to containers but for non-containerized stock
- Cannot be used for routes (routes require container-level tracking)
- Direct to dock variant supported
### Packages (Multi-Carrier)
- Packages (parcels with carrier labels) are scanned for loading
- Carrier must match load's carrier assignment
- Packages can be in containers; containers with packages are loadable as a unit
- If carrier allows: undo preparation, reject package
**Common loading events:**
- Excess detection: if order was reduced after preparation, operator is guided to remove surplus before/during loading
- 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 (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).
- One PS group can be assigned per shipping order/route
- Manual or auto assignment
- Containers arriving at PS conveyors are shipped (manually or automatically)
- PS group shipping flow: containers arrive at configured PS stations → shipped in configured order
## Inventory After Picking
At the end of picking (last task from a location/container), EasyWMS can ask operators to verify if the location/container is now empty, enabling continuous inventory. Configurable behavior:
- If operator says empty: stock adjustment (reduces inventory to zero)
- If operator says not empty: location/container marked for review (count triggered)
## Shipping Order Mixing
Multiple shipping orders can be merged into the same client container if they meet configured mixing strategy conditions (e.g., same customer, same carrier, same delivery date range). Mixing strategies define the compatibility criteria.
## ERP Integration
| Message | Direction | Trigger |
|---|---|---|
| `SOR` (inbound) | ERP → WMS | Shipping order creation/update from ERP |
| `SOC` (outbound) | WMS → ERP | Order release; status change (stock assignment) |
| `SOF` / `SOF02` (outbound) | WMS → ERP | Order fulfilled / partial fulfillment with differences |
| `LOF` (outbound) | WMS → ERP | Load closed; transport details sent to ERP |
> See [ERP Interface](erp-interface.md) for full field tables and variants (SOR01/SOR02, SOF01/SOF02).
## Transactions
| Transaction | Trigger |
|---|---|
| `OUT.CST` | Shipping order release |
| `STK.PICKING` | Picking task executed |
| `STK.SHIP` | Shipping task (full container extracted) |
| `CON.LOAD` | Container loaded onto transport |
| `STK.LOAD` | Loose stock loaded onto transport |
| `CON.CREATE` | New client/consolidation container created |
| `CON.COC` | Client container closed |
| `STK.MOVE` | Stock moved (consolidation) |
| `CON.DELETE` | Empty container deleted |
## Parameters
| Parameter | Description |
|---|---|
| `MAX_AUTORELEASED_OUTBOUNDORDERS` | Maximum shipping orders auto-released at the same time |
| `ALLOW_CONFIRMATION_ON_PLACEMENT` | Operator confirms destination container at picking deposit |
| `EMPTY_PICKING_LOCATION_QUESTION` | Ask if location/container is empty after last pick |
| `EMPTY_PICKING_LOCATION_STOCK_ADJUST` | If empty confirmed: adjust stock (true) or mark for review (false) |
## Common Errors
**Order stays in "Created" after release attempt:** Stock assignment failed for all lines (no eligible stock). Check: stock statuses allow picking, locations not locked, no active count tasks, picking dedicated locations configured if needed.
**Tasks generated but no operator picks up:** Tasks assigned to specific equipment that isn't active, or operator logged into wrong zone/sub-warehouse. Check equipment assignment on the order; clear if not needed.
**Route containers loaded in wrong order:** Operator ignored system warnings or system route stop not correctly configured. Route stop numbers must be in reverse delivery sequence (last stop loaded first) for efficient unloading.
**Consolidation station not receiving containers:** Consolidation station assigned after order release. Must be assigned before release for existing prepared containers to be re-routed. Only new container movements will go to the station post-assignment.
**Load closed without all containers:** Partial close was triggered or configured. ERP receives load-close notification; missing containers must be tracked manually or re-assigned to a new load.
**Order mixing containers rejected:** Two orders cannot mix due to mixing strategy conditions (different customer, incompatible logistic attributes). Check mixing strategy criteria and adjust or create a different strategy for these order types.
**PS group not releasing containers to outbound:** PS group not assigned to the order, or all PS stations in the group are locked. Assign PS group or unlock stations.
## Interface Paths
| Interface | Path |
|---|---|
| Web — shipping orders | Menu "Shippings" → "Shipping orders" |
| Web — routes | Menu "Shippings" → "Routes" |
| Web — loads | Menu "Shippings" → "Loads" |
| Web — waves | Menu "Shippings" → "Waves" |
| Web — groups/fusions | Menu "Shippings" → "Groups" |
| Web — shipping templates | Menu "Configuration" → "Shipping templates" |
| Web — PS groups | Menu "Control" → "PS groups" |
| RFT — truck loading | Menu "Shipping" → "Load truck" |
| RFT — consolidation | Menu "Shipping orders" → "Packaging" |
## Related
- [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
- [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
- [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
- [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)
- [[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
wiki_old_13-05-2026/concepts/stations.md
+287
View File
@@ -0,0 +1,287 @@
---
title: "Stations & Routes"
type: concept
sources:
- areas/layout/stations/index.md
- areas/layout/stations/alm.md
- areas/layout/stations/pie.md
- areas/layout/stations/pk.md
- areas/layout/stations/et.md
- areas/layout/stations/dock.md
- areas/layout/stations/stage.md
- areas/layout/stations/mu.md
- areas/layout/stations/me.md
- areas/layout/stations/ms.md
- areas/layout/stations/workzone.md
- areas/layout/stations/decision.md
- areas/layout/stations/ps.md
- areas/layout/stations/reac.md
- areas/layout/stations/rech.md
- areas/layout/stations/consolidation.md
- areas/layout/stations/etq.md
- areas/layout/stations/conveyor.md
- areas/layout/stations/vas.md
- areas/layout/stations/tenseFlow.md
- areas/layout/stations/lift.md
- areas/layout/stations/packaging_station.md
- areas/layout/stations/pscharge.md
- areas/layout/stations/fleet_manager.md
- areas/layout/stations/notask.md
- areas/layout/stations/disabledroute.md
- areas/layout/stations/stationloaded.md
- areas/layout/stations/stationfault.md
- areas/inventory_management/stations/roles.md
- areas/inventory_management/stations/views/view_dock_stage.md
- sources/archives/Codes_de_station.md
- sources/archives/Acronymes_elements_mecaniques.md
- sources/archives/Presentation_GALILEO.md
- sources/archives/Communication_Easy_Galileo.md
- sources/archives/Configuration_EasyS.md
related:
- concepts/location.md
- concepts/task.md
- concepts/picking.md
- concepts/reception.md
- concepts/shipping.md
- concepts/putaway.md
- concepts/warehouse-designer.md
- concepts/mechanical-elements.md
- architecture/galileo-integration.md
- operations/galileo-simulation.md
last_compiled: "2026-04-17"
---
# Stations & Routes
## Overview
Stations are the structural **start and end points of all container movement** in the warehouse. In automatic warehouses, they form the basic interconnection layer between Easy WMS and the Transport Management System (TMS). Every task generated by the system is a movement from a source station to a destination station along a defined route.
A critical design principle: **minimize the number of stations**. More stations means more communication nodes, more possible delays, and higher risk of bottlenecks. Create only what is strictly necessary for optimal container flow.
Each station has:
- A **type** (determines behavior and process)
- A **capacity** (max containers simultaneously heading to that station)
- An optional **process type** (restricts which task types pass through it)
## Station Types Reference
Easy WMS defines 37+ standard station types. Types are identified by a numeric code.
### Storage Stations
| 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. |
### 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. |
| 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. |
| 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. |
| 62 | Lift | Lift | Lift station for multi-level operations (APS3D carts change level through this). |
### AS/RS Machine
| 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). |
### 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). |
| 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. |
| 60 | TenseFlow | Tense Flow | Station for tense-flow operations (continuous uninterrupted picking flow). |
| 63 | Decision (DS) | Decision Station (Pick and Pass) | PopUp element at intersection of main transport and sub-warehouse routes. Analyzes: is container a client container? Is it full? Does it have pending tasks in this sub-warehouse? Does it have putaway tasks here? On failed read: reject task to error entity station. Location containers without approach task access first station of transport route. Client containers without approach task: flow generates approach task to destination sub-warehouse. |
| 64 | Workzone (WS) | Workzone Station (Pick and Pass) | Automatic buffer element at entry of each sub-warehouse. Worker picks up/drops off containers. Required for picking start points per sub-warehouse. Has "Sequence" parameter for logical ordering along transport flow. Locking prevents approach tasks from being created (blocks sub-warehouse access). |
### Control / Maintenance Stations
| 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. |
| 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. |
| 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. |
### 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 | 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. |
### Special / Module Stations
| 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. |
| 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. |
| 66 | PS Charge | PS Charge | Pallet Shuttle charging station. |
| 0 | Fleet Manager | APS3D Fleet Manager | Manages carts (APS3D) across all aisles and levels. Periodically requests tasks from Easy WMS, assigns to carts, informs of completion. Configuration: code, station number (unique per type+warehouse), sub-warehouse, work mode (Input/Output/Combined/Disabled), sequence level (Stricted). Behavior similar to AS/RS type. |
## Multi-Role Stations
A single physical station can have more than one role, enabling context-sensitive behavior:
**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.
## Station Code Translation (FR / ES / EN)
Mecalux teams work across three languages; the same station can appear in logs and documentation under different codes. Canonical cross-reference (see [Mechanical Elements](mechanical-elements.md) for the full table including acronyms):
| Type | Code FR | Code ES | Code EN | Description (FR) |
|------|---------|---------|---------|------------------|
| 0 | MAG | ALM | AIS | Magasin |
| 1 | ML / TK | TRASLO | STC | Miniload / Transstockeur |
| 2 | PK | PK | PK | Poste de picking |
| 3 | PIE | PIE | EIP | Poste d'identification d'entrées |
| 4 | PS | PS | SC | Poste de sortie |
| 9 | TE | ME | IC | Table d'entrée |
| 10 | TS | MS | OC | Table de sortie |
| 11 | MU | MU | MU | Table de recherche d'emplacement |
| 16 | TP | MP | MP | Table de préparation |
| 18 | PKE | PKE | PKE | Poste d'entrée au PK |
| 20 | ET | ET | TS | Station de transit |
| 21 | CME | CME | ICS | Contrôle d'entrée au magasin |
## 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.
| Layer | Generic station (conveyor/TK) | PK and PS |
|-------|-------------------------------|-----------|
| Physical capacity | Containers that fit on the physical station | Containers that fit on the physical station |
| Route capacity | Containers in transit on upstream conveyors | Containers in transit on upstream conveyors |
| WMS capacity | Same as physical | **Physical + transit + every task whose destination is this station** |
Worked example (PK): 1 physical slot + 4 in transit on intermediate conveyors + all pending tasks targeting PK = 15 is the value that appears in the WMS capacity.
## 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.
> If no path exists, EasyWMS creates a **reject task** toward the configured reject station.
Route inventory: **Menu → Control → Itineraries between stations**.
EasyS route types (cross-reference with Manager table below):
| EasyS type | Use case |
|------------|----------|
| **Galileo** | Requires Gateway calls (physical hop) |
| **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).
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).
## Routes
A **route** defines the path between two stations. Route types:
- **Simple route**: Direct A → B with no intermediate stations. Known by both Easy WMS and TMS.
- **Composed route**: A → B → C → ... → N, built from multiple simple routes. Known only by Easy WMS (TMS handles individual simple routes). Result: task = composed movement; movement = simple route.
Easy WMS generates tasks based on configured routes. Before generating a task, it checks:
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.
If the shortest active route is blocked, Easy WMS immediately tries an alternative route.
**Route distance:** Can be configured in EasyS. Easy WMS prefers shortest path.
### Route Managers (Executors)
Each simple route requires a declared manager — the type of element that will execute tasks on that route:
| Manager | Executor |
|---------|----------|
| Galileo | Automatic element (conveyor, machine) |
| 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 |
| PTL | Pick-to-Light system |
| External | External system (AGV, vertical warehouse, ERP, etc.) |
| APS3D Fleet Manager | APS3D cart system |
## Route Incidences
| Incidence | Description | Resolution |
|-----------|-------------|------------|
| Container without task at station | Container arrives at a station in an automatic warehouse when its task was cancelled | Manual intervention: reassign or send to staging |
| Disabled route | A route has been disabled | Enable route or create alternative route |
| Destination station loaded | Destination station has containers on it exceeding capacity | Wait or redirect |
| Destination station in default | Destination station is down/faulted | Repair station, activate alternative route |
| Destination/intermediate station locked | A station on the route is locked | Unlock station or activate alternative route |
## Dock & Stage Configuration (SmartUI)
Docks and stages are created in **EasyS** (or **Warehouse Designer**), not in SmartUI. SmartUI provides read/edit/action access.
**Dock/Stage attributes:** Code, abbreviation (used for PTL picking destination display), description, station type, warehouse, by-default for receipts/shipping, capacity, work mode (receipts/shipping/both), lock status.
**Actions available:**
- Lock / Unlock
- Set as default for receipts or shipping (removes previous default if set)
- Set capacity (wizard)
- Set work mode
- Set abbreviation (for PTL display)
- Print labels (format + copies)
- Assign printer (report printer and/or label printer, or "Do not print")
- Audit
**Work mode** values: Receipts, Shipping, Both.
## Interface
- **Stations configuration:** "Stations" view in the "Control" menu (PC)
- **Routes between stations:** "Routes between stations" in the "Control" menu (PC)
- **Docks and stages master:** "Docks and stages master" in the "Control" menu (PC)
- **Station status (3D map):** Warehouse Map → click station → view capacity, occupation, work mode
## Common Errors
| Error | Cause | Solution |
|-------|-------|----------|
| No task generated for container | No active route from source to destination | Check route exists and all intermediate stations are unlocked |
| Container stuck at MS with "With conflict" flag | Downstream route blocked (MS can't generate movement) | Identify and resolve the blocked station/route; system auto-recovers |
| PIE rejecting all containers | Incorrect flag configuration or gauge mismatch | Verify PIE event flags, check container dimensions vs gauge arch tolerance |
| Container sent to Lost & Found at ET | Two containers at same automatic ET location simultaneously | Check TMS event ordering, ensure only one container per automatic ET location |
| MU not finding location | No putaway strategy active for container/item | Verify putaway strategy configuration; ensure route from MU to warehouse exists |
## Related
- [[location]] — Location types associated with each station (DockStage, buffer, conventional)
- [[task]] — Every movement is a task; tasks decompose into simple route movements
- [[warehouse-designer]] — Stations are created in EasyS/Warehouse Designer, transferred to SmartUI
- [[picking]] — PK, MP, Workzone, Decision, PKE, TenseFlow, Consolidation all support picking
- [[reception]] — Dock, Stage, PIE stations are central to receiving workflows
- [[shipping]] — Dock, Stage, PS, Consolidation stations support outbound flow
- [[putaway]] — PIE triggers location search; MU refines it closer to warehouse
wiki_old_13-05-2026/concepts/stock-adjustment.md
+326
View File
@@ -0,0 +1,326 @@
---
title: "Stock Adjustment"
type: concept
sources:
- areas/inventory_management/stock_adjustment/stock_adjustment.md
- areas/inventory_management/stock_adjustment/quantity_adjust.md
- areas/inventory_management/stock_adjustment/udm_adjust.md
- areas/inventory_management/stock_adjustment/al_adjust.md
- areas/inventory_management/stock_adjustment/reasons.md
- areas/inventory_management/stock_adjustment/stock_adjustment_RF.md
- areas/inventory_management/stock_adjustment/stock_adjustment_SmartUI.md
- areas/inventory_management/stock_adjustment/stock_adjustment_Workstation.md
- areas/inventory_management/stock_adjustment/stock_adjustment_entity.md
- areas/inventory_management/stock_adjustment/stock_adjustment_in_RFCount.md
- areas/inventory_management/stock_adjustment/stock_adjustment_in_WorkStationCount.md
- areas/inventory_management/stock_adjustment.md
- areas/inventory_management/double_validation/activate.md
- areas/inventory_management/double_validation/adjust_register.md
- areas/inventory_management/double_validation/pending_adjust_actions.md
- areas/inventory_management/double_validation.md
- sources/archives/21_Validation_ajustements_stock.md
related:
- concepts/stock.md
- concepts/count.md
- concepts/location.md
- concepts/container.md
- concepts/product-item.md
- concepts/quality-control.md
last_compiled: "2026-04-17"
---
# Stock Adjustment
## Overview
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
- **SmartUI (PC web)** — manager-level adjustments from the web interface
- **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).
A **Double Validation** option can hold adjustments in a **Pending** state, requiring a supervisor to approve or cancel them before any transaction or ERP message is generated.
---
## Types of Adjustment
### 1. Quantity Increase (`+`)
Increases the quantity of a stock line in a container or location.
**Restrictions:**
- Not allowed on ASN (pre-notified, not yet received) containers
- Not allowed on client stock containers
- Cannot exceed the "complete quantity" defined for the presentation
**Side effects on tasks:**
- Putaway tasks for the stock → canceled (location search re-runs with new weight)
- Picking/shipping tasks not in execution → canceled, stock unassigned, line re-released
- Shipping tasks in execution → quantities adjusted in-flight
- Replenishment assignments → checked and adjusted
### 2. Quantity Decrease (`−`)
Decreases the quantity of a stock line in a container or location.
**Restrictions:**
- Not allowed on ASN containers
- Not allowed on client containers
- When decreasing to 0: container removed or left empty depending on location config
**Side effects on tasks and assignments:**
- Picking assignments (not in execution): canceled newest-first, lines re-released
- Shipping assignments: canceled, line re-released
- Replenishment source assignments: adjusted, tasks decremented/canceled
- Stock reserves: priority given to highest-priority orders placed earliest
**Multi-reception stock:** When adjusted stock originates from multiple receptions, the operator must select which reception the adjustment applies to.
### 3. Location / Full Adjustment (Quantity + UoM + Logistic Attributes + Status)
The most comprehensive adjustment type. Allows changing any field on a stock line:
- Quantity (up or down)
- Unit of measure
- User status (assign, change, remove)
- Logistic attributes (lot, expiry, serial, etc.)
Can also:
- **Create** new stock lines
- **Delete** existing stock lines
When deleting all stock from a container, the container is removed or left empty depending on location configuration.
Available from: RFT (`Utilities > Location adjustment`), SmartUI, Workstation.
### 4. Unit of Measure Adjustment (UoM)
Changes the unit of measure of a stock line. EasyWMS treats this as a delete + recreate.
**Side effects:**
- Shipping assignments requiring the old UoM → EasyWMS searches for substitute stock
- Client stock with new UoM incompatible with order line → stock unassigned
- Replenishment assignments requiring the old UoM → substitute stock searched
**Communications:** STV sent to ERP.
### 5. Logistic Attributes Adjustment (AL)
Changes one or more logistic attributes of a stock line (lot, expiry date, serial number, etc.).
EasyWMS deletes the old stock record and recreates it with new attributes.
**Side effects:**
- Shipping assignments requiring old attributes → substitute stock searched
- Replenishment assignments requiring old attributes → substitute stock searched
- Client stock with new attributes incompatible with order line → stock unassigned
**Communications:** STV sent to ERP.
---
## Adjustment Reasons
Every adjustment requires a **reason code** selected from the master. Reasons are configured in `Masters > Adjustment reasons`.
| Field | Description |
|---|---|
| Description | Human-readable label |
| Sequence | Priority; some processes (PTL picking) auto-select the lowest-sequence reason |
| Requires comment | Whether a free-text comment is mandatory |
| ERP code | Code used by ERP-initiated adjustments |
| Capture process | Which processes may use this reason |
**Capture processes** (only one reason allowed per order for Count and Presentation Breakage):
| Process | Description |
|---|---|
| Adjustment | Manual adjustments from any interface |
| Count | Adjustments generated by counting processes |
| Picking | Adjustments made during picking |
| Scrap | Adjustments during scrap process |
| Presentation breakage | When opening a presentation to pick a smaller UoM |
---
## Interface-Specific Details
### RF Terminal Adjustments
Available options from `RFT > Utilities`:
- **Increase item** — quantity increase
- **Decrease item** — quantity decrease
- **Location adjustment** — full adjustment (qty + UoM + AL + status)
- **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
- **Adjustment during count** (in-count adjustments reported separately)
### SmartUI (Web) Adjustments
From `Warehouse > Stock` view, managers can:
- Apply logistic attribute adjustments to multiple stock lines
- Apply status changes (also covered under quality control)
- View the adjustment history
### Workstation (Picking Conveyor) Adjustments
At the PK station (`Workstations > Picking > Others > Stock Adjustment`), operators can adjust containers currently at the conveyor. Supports full adjustment (qty + UoM + status + AL) and line create/delete.
Useful for correcting discrepancies discovered during picking or consolidation.
---
## Double Validation (Pending Adjustments)
When **double validation** is enabled for an item (via item's count profile), adjustments on that item's stock are placed in **Pending** status instead of being applied immediately.
In Pending status:
- The stock change **is applied** to the warehouse inventory
- The `STK.ADJ` transaction is **not** generated
- The STV message to ERP is **not** sent
A manager must then approve or cancel via `Warehouse > Stock adjustments`:
### Validating a Pending Adjustment
- Marks the change as confirmed
- Generates `STK.ADJ` transaction
- Sends STV to ERP
- Status → **Confirmed**
### Canceling a Pending Adjustment
- **Reverses** the stock change (re-generates deleted stock or removes created stock)
- No transaction generated, no STV sent
- Status → **Canceled**
- If reversal requires moving stock to a different location → `STK.MOVE` transaction generated
> **Important:** Canceling an adjustment reverses the delta, not the exact original state. If other processes moved the stock between adjustment and cancellation, a wizard prompts for compatible stock selection.
---
## Transactions
| Transaction | Trigger |
|---|---|
| `STK.ADJ` | Stock quantity, UoM, or AL adjustment confirmed |
| `STK.MOVE` | Generated when canceling a pending adjustment that restores stock to a different location |
---
## ERP Integration
**On adjustment (immediate):**
- EasyWMS sends **STV** (stock variation) to ERP for each affected stock line
**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:**
- STV is only sent when the pending adjustment is **validated** by a manager
---
## Business Rules
- Every adjustment (except physical count auto-adjustments) **requires a reason**.
- 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.
- 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.
---
## Configuration
| Parameter | Description |
|---|---|
| `MAX_NUM_LABELS_TO_READ` | Enable multi-GS1-128 label reading in adjustment flow (also governs receipts, counts) |
| `UNLOAD_CREATE_PRODUCT_LOCATION` | Auto-create/update PDL when adjusting in partitioned picking location |
| `REPLENISH_LEVEL_PERCENT_PRODUCT_LOCATION` | Replenishment level % for auto-created PDL |
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)
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 |
| **Always** | Every adjustment is held as `Pending` |
| **According to tolerance** | Held as `Pending` **only if** the adjustment exceeds the configured tolerance |
**Tolerance parameters:**
| Parameter | Description |
|---|---|
| Maximum positive percentage variance | % increase allowed without validation |
| Maximum negative percentage variance | % decrease allowed without validation |
| 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.
Attach the profile to an item by editing the item and selecting its Count Profile.
### Validation in the stock-adjustments view
`Warehouse → Stock adjustments` → select a `Pending` line → **Validate** or **Cancel**.
- **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.
- Row colours : **green** = validated / no profile / profile "Never" / below tolerance; **red** = rejected.
**Cancel behaviour:**
- Negative variance → WMS proposes to restore the removed stock to its origin (or a chosen location)
- Positive variance → WMS asks from which location to remove the surplus
### French UI labels reminder
- **Pending** — no transaction, no ERP communication (stock change *is already applied* in the WMS, only ERP sync is held)
- **Validé** — STV sent to ERP
- **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.
---
## Interface
| Path | Equipment |
|---|---|
| `RFT > Utilities > Increase item` | RFT |
| `RFT > Utilities > Decrease item` | RFT |
| `RFT > Utilities > Location adjustment` | RFT |
| `Workstations > Picking > Others > Stock Adjustment` | PC |
| `Warehouse > Stock` (SmartUI — logistic attributes) | PC |
| `Warehouse > Stock adjustments` (double validation review) | PC |
| `Masters > Adjustment reasons` | PC |
---
## Common Errors
| Symptom | Cause | Solution |
|---|---|---|
| No adjustment reasons visible on RFT | No adjustment reasons configured for the "Adjustment" capture process | Add reasons in `Masters > Adjustment reasons` |
| STV not sent to ERP after adjustment | Stock belongs to an open reception | Close the reception; STV will be sent at that point |
| Adjustment applies but no `STK.ADJ` transaction | Double validation active for item; adjustment is Pending | Manager must validate in `Warehouse > Stock adjustments` |
| Cannot adjust ASN container | Container is pre-notified, not yet received | Complete or cancel the reception first |
| Cannot decrease below zero | System prevents negative stock | Verify if stock is in the expected location; run a count |
| Pending adjustment cancel wizard shows no compatible stock | Stock has already been shipped or moved elsewhere | Manually create a compensating stock entry in a suitable location |
---
## Related
- [[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
- [[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
- [[product-item]] — Count profile on item controls double validation activation
- [[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)
- [[labels]] — Labels can be printed for cutting stock during location adjustment process
wiki_old_13-05-2026/concepts/stock-assignment.md
+117
View File
@@ -0,0 +1,117 @@
---
title: "Stock Assignment"
type: concept
sources:
- sources/archives/24_Process_assignation_stock.md
related:
- concepts/stock.md
- concepts/order-outbound.md
- concepts/picking.md
- concepts/replenishment.md
- concepts/kits.md
- concepts/crossdocking.md
- concepts/cutting-stock.md
- concepts/task.md
- modules/tenseflow.md
last_compiled: "2026-04-17"
---
# Stock Assignment
## Overview
**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).
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`.
## Engine pipeline
### 1. Fetch and lock the detail
Workflow: `StockAssignProcess_GetLockAndUpdateDetail_PR`
Loads the outbound line detail, locks it for the assignment run, and reads the minimum data needed for stock search. To expose additional detail fields to downstream steps, extend the `Select` of the query in this workflow.
### 2. Search candidate stock
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.
### 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.
- **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).
- `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`.
### 4. Persist assignments and build tasks
Two sibling workflows:
- `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).
## 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. |
| **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. |
## Interactions with other features
### 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.
### 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.
### 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.
## Customisation points
| Need | Workflow / query to touch |
|---|---|
| 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` |
| 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.
- **"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 |
| 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 |
## Related
- [[stock]] — the data model assignment writes against
- [[order-outbound]] — outbound lines and their `OutboundOrderLineDetails` are the inputs of the engine
- [[picking]] — most assignment outputs are consumed as picking tasks
- [[replenishment]] — `ReplenishmentAssignment` type materialises the replenishment-plus-picking pairing
- [[kits]] — kit handling special case (all-or-nothing rollback, dedicated assembly-zone preference)
- [[crossdocking]] — assignment waits for inbound crossdocking candidates unless disabled
- [[cutting-stock]] — cutting items use the same pipeline with cut-specific post-processing
- [[task]] — tasks are the tangible output of each assignment
- [[tenseflow]] — the PickingContainer assignment type is the TenseFlow-specific path
wiki_old_13-05-2026/concepts/stock.md
+293
View File
@@ -0,0 +1,293 @@
---
title: "Stock"
type: concept
sources:
- areas/inventory_management/views/view_stocks.md
- areas/inventory_management/stock_adjustment/stock_adjustment.md
- areas/inventory_management/stock_adjustment/reasons.md
- areas/inventory_management/stock_adjustment/quantity_adjust.md
- areas/inventory_management/stock_adjustment/udm_adjust.md
- areas/inventory_management/stock_adjustment/al_adjust.md
- areas/inventory_management/stock_adjustment/stock_adjustment_RF.md
- areas/inventory_management/stock_adjustment/stock_adjustment_SmartUI.md
- areas/inventory_management/stock_adjustment/stock_adjustment_Workstation.md
- areas/inventory_management/stock_adjustment/stock_adjustment_entity.md
- areas/inventory_management/stock/print_stock_label.md
- areas/reports/grouped_stock/grouped_stock.md
- areas/reports/grouped_stock/grouped_stock_item.md
- areas/reports/grouped_stock/grouped_stock_date_lot.md
- areas/reports/grouped_stock/grouped_stock_subwarehouse.md
- sources/archives/24_Process_assignation_stock.md
related:
- concepts/container.md
- concepts/location.md
- concepts/product-item.md
- concepts/reception.md
- concepts/putaway.md
- concepts/picking.md
- concepts/shipping.md
- concepts/count.md
- concepts/stock-adjustment.md
- concepts/stock-assignment.md
- concepts/order-outbound.md
- concepts/task.md
- concepts/erp-interface.md
last_compiled: "2026-04-17"
---
# Stock
## 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.
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.
## Types
Stock is classified by its storage context and status:
### By storage context
- **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.
- **ASN stock**: stock pre-notified by the ERP but not yet physically received. Located in the virtual ASN location. Cannot be adjusted.
### By status
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 |
| **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 |
User status and receiving status are independent; both can exist simultaneously on the same stock line.
**User status** is modifiable at any time from SmartUI or via the RFT QUALITY menu, without limit. It is useful for marking defective or quarantined goods.
**Receiving status** is set only during reception (from the reception profile). It can only be removed (not re-applied) from PC or RFT. Removed status cannot be reinstated except through a new reception.
For each user or receiving status, the following actions can be **allowed or forbidden** on affected stock:
- Picking (order preparation)
- Replenishment
- Inventory / counting
- Reception
- Internal consumption
- Shipping (dispatch)
- Collection
- Movement (relocation)
- Reservation
When a user status is added/changed/removed on a stock line, the **STC01** message is automatically generated and sent to the ERP.
**Next to expire** and **Expired** flags are computed fields. "Next to expire" marks stock approaching expiry even before the actual expiry date. "Expired" marks stock past its expiration date. Expired stock can still be shipped if the SOR line explicitly requests it.
## Stock record structure
Each stock line is identified by a unique combination of: **Item + Owner + Location (+ Container if containerized) + Logistic attributes + Status + UoM**.
> If any of these elements differs between two physical goods, a separate stock line is created. For example, the same article in two different lot numbers at the same location generates two stock lines. Two goods with different UoMs (e.g., 1 bottle vs 1 pack of 6 bottles) at the same location are also separate lines.
| Field | Description |
|---|---|
| **Item** | Item code |
| **Owner** | Owner of this stock (for 3PL or multi-owner warehouses) |
| **Warehouse** | Warehouse site (visible if 3PL module installed) |
| **Quantity** | Amount in base UoM |
| **UoM** | Base unit of measure |
| **Short description** | Item short description |
| **Location** | Physical or virtual location holding this stock |
| **Container** | Container code (if containerized) |
| **Container type** | Type of the container |
| **Complete container** | Whether the container is marked as "complete" |
| **Container locks** | Number of active locks on the container |
| **Load** | Load code associated to this stock (for truck loading) |
| **Delivery code** | Delivery associated to this stock (Multi-Carrier module) |
| **Supplier** | Supplier code from the receipt |
| **Theoretical weight** | Calculated weight based on item weight configuration |
| **Status** | System status |
| **User status** | User-set status (with end date and comment) |
| **Receiving status** | Status from reception quality process (with end date) |
| **Lot** | Lot number |
| **Expiration date** | Date after which stock is unusable |
| **Best-before date** | Date after which stock is suboptimal |
| **Production date** | Date of manufacture |
| **Days of life** | Remaining usable days |
| **Quality** | Quality attribute value |
| **Color** | Color attribute |
| **Caliber** | Size/caliber attribute |
| **Origin** | Origin attribute |
| **Version** | Version attribute |
| **Production method** | Production method attribute |
| **Post-production treatment** | Post-production treatment attribute |
## Lifecycle
```
[Reception] → Stock CREATED (in container or loose in location)
↓
[Putaway] → Stock LOCATED (moved to storage location)
↓
[Stock assignment] → Stock RESERVED or ASSIGNED (for outbound order)
↓
[Picking] → Stock PREPARED (in client container, staging area)
↓
[Consolidation/Loading] → Stock LOADED (on truck/dock)
↓
[Order close] → Stock CONSUMED (quantity decremented to 0; record removed)
```
Stock can also be **adjusted** at any point (quantity, UoM, logistic attributes, status), **counted** (verified against physical reality), **consolidated** (merged), **defragmented** (moved to optimize space), and **locked** (user/receiving status changed).
Stock adjustments generate **STK.ADJ** transactions and trigger **STV** messages to the ERP.
## Business rules
- Stock is **never modified directly** by a user action other than through a defined process (reception, adjustment, shipping, etc.). The stock view allows adjustments, but each has constraints and requires a reason.
- Stock in a **quality lock** (user status or receiving status that disallows shipping) is excluded from stock assignment for outbound orders, unless the SOR line explicitly requests that specific status.
- **Reserve recalculation** occurs when stock is locked or adjusted: if a reserve is broken, priority is given to the highest-priority orders that reserved earliest.
- Stock in **ASN** state (pre-notified) cannot be adjusted or decreased.
- Adjustments to **client stock** (prepared for an order) are more restricted: only certain changes allowed; others require that the container is not in prepared state.
- When stock is decreased to 0 in a container, the container is either deleted or left empty depending on the location's "Delete empty containers" configuration.
- A stock line with tasks cannot be freely modified: existing tasks are adjusted or canceled, and lines are re-released for re-assignment.
- **Multiple receptions**: when stock originates from multiple receipts consolidated at the same location/container, a decrease or adjustment must identify which receipt it applies to.
## Stock adjustment
Stock adjustments allow operators to correct discrepancies between the WMS record and physical reality.
### Types of adjustments
| Adjustment type | What changes | Interface |
|---|---|---|
| **Quantity increase** | Adds to existing stock quantity | PC / RFT ("Utilities → Increase item") |
| **Quantity decrease** | Subtracts from existing stock quantity | PC / RFT ("Utilities → Decrease item") |
| **Location adjustment** | Full edit: quantity + UoM + user status + logistic attributes; can create/delete lines | PC / RFT ("Utilities → Location adjustment") |
| **Picking location adjustment** | In PDL with labeled partitions: quick adjustment by reading partition label; can create/change partition assignments | RFT |
| **Picking conveyor adjustment** | Same as location adjustment but for containers at PK conveyors in auto warehouse | Workstation ("Workstation → Picking → Others → Stock Adjustment") |
### Rules for adjustments
- All adjustments require an **adjustment reason** (from the reasons master). One reason can cover multiple adjustments in a session.
- When quantity is adjusted and stock has:
- **Putaway tasks**: task is canceled so location search is recalculated with new weight/characteristics
- **Picking/shipping tasks (not in execution)**: assignment canceled; line re-released
- **Picking/shipping tasks (in execution)**: task quantities adjusted; line re-released for deficit
- **Replenishment source assignments**: assignments adjusted; picking tasks at PDL adjusted or canceled
- **Reserve priority**: on decrease, the most recently assigned reserves are preferentially canceled; oldest are preserved
- Cutting stock adjustments can optionally trigger cutting stock label printing (if cutting profile has "Label source stock" active)
### Communications
- Adjustment generates: **STV** message (ERP notification of stock value change)
- Transaction recorded: **STK.ADJ**
> **STV important note**: The quantity in the STV message is the **delta** (quantity that changed), not the remaining quantity in the warehouse. For example, if 10 units were deleted, STV sends -10, not the new total. The ERP must accumulate deltas or use SCR/WSC for a full stock image.
> **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.
> - Stock at 0 can optionally be included (configurable).
> - Can be sent on-demand or on a scheduled basis (once/day or at intervals).
### Adjustment reasons
Reasons are configured in `Masters > Adjustment reasons`. Each reason can optionally require a comment. Reasons are referenced in audit trails and ERP communications.
### Double validation
EasyWMS supports a **double validation** mechanism for stock adjustments. When active, an adjustment stays in "Pending" status until a manager validates or cancels it.
- **Pending**: adjustment entered but not yet applied. No STK.ADJ transaction; no STV sent to ERP.
- **Validated**: manager approves → adjustment is applied, transaction and STV generated.
- **Cancelled**: manager rejects → stock is restored, no transaction or ERP notification.
Configuration (per item, in **inventory profile**):
| Setting | Behavior |
|---------|---------|
| **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 %) |
Pending adjustments are visible in the Adjustments view with status "Pending". They do not affect stock available for picking.
## Stock status operations (from the Stocks view)
| Operation | Description | Visibility |
|---|---|---|
| **Audit** | View stock audit trail (all movements and changes) | Single record |
| **Adjust** | Open adjustment dialog for this stock line | Single record |
| **Status** | Change user status of this stock | Single record |
| **Container** | Mark container as complete / lock / change location | Single record (containerized stock) |
| **Relocate container** | Automatic relocation / to location / to aisle or level | Single or multiple records |
| **Print container label** | Print LPN label for this stock's container | Single record |
| **Delete** | Delete stock line (with adjustment reason) | Single record |
| **New** | Create new stock line in a container/location | No records selected |
| **Forward traceability lock** | Lock all downstream stock derived from this lot/reception | No records selected |
| **Stock contrast** | Request WMS to send current stock snapshot to ERP (triggers WSC) | No records selected |
| **Print list / Export list** | Print or export filtered stock lines | No records selected |
## Grouped stock reports
The grouped stock reports provide aggregate views of stock without the per-line detail of the Stock view:
| Report | Grouped by | Use case |
|---|---|---|
| **By item** | Item code | Total stock per SKU across warehouse |
| **By date and lot** | Item + date + lot | Traceability and FEFO management |
| **By presentation** | Item + presentation (UoM) | Commercial stock view |
| **By presentation, date and lot** | Item + presentation + date + lot | Detailed expiry tracking |
| **By sub-warehouse and zone** | Sub-warehouse + zone | Area-level stock overview |
## Parameters
| Parameter | Effect |
|---|---|
| `MAX_NUM_LABELS_TO_READ` | Enables multi-reference label reading during stock adjustment (also applies to reception and counts) |
| `UNLOAD_CREATE_PRODUCT_LOCATION` | Auto-creates/updates picking dedicated location assignments during PDL adjustment |
| `REPLENISH_LEVEL_PERCENT_PRODUCT_LOCATION` | Level threshold calculation for PDL replenishment triggered by adjustment |
## Interface
| Function | Hardware | Menu path |
|---|---|---|
| Stock lines view | PC | Inventory (or Warehouse) → Stock |
| Quantity increase | RFT | Utilities → Increase item |
| Quantity decrease | RFT | Utilities → Decrease item |
| Location adjustment | RFT | Utilities → Location adjustment |
| Picking conveyor adjustment | Workstation | Workstation → Picking → Others → Stock Adjustment |
| Grouped stock reports | PC | Reports → Grouped stock |
| Stock contrast (send WSC) | PC | From Stock view → Stock contrast button |
## Common errors
| Symptom | Cause | Solution |
|---|---|---|
| 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 |
| 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 |
| STV not sent to ERP | Integration configuration issue | Check ERP integration settings; verify STV message is enabled |
## Related
- [[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
- [[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
- [[picking]] — stock is assigned and picked for outbound orders; picking consumes stock quantity
- [[shipping]] — shipping closes orders and removes stock from the warehouse
- [[count]] — counts verify the accuracy of stock records; discrepancies trigger adjustments
- [[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)
- [[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
- [[erp-interface]] — STV message reports stock changes; SCR/WSC for stock contrasts; STR for status locks
wiki_old_13-05-2026/concepts/supplier.md
+75
View File
@@ -0,0 +1,75 @@
---
title: "Supplier"
type: concept
sources:
- areas/inventory_management/masters/suppliers.md
- areas/inventory_management/masters/supplier_types.md
- areas/receptions/reception_dock/supplier_container.md
- areas/receptions/reception_dock/supplier_loose.md
related:
- concepts/reception.md
- concepts/order-inbound.md
- concepts/product-item.md
- modules/owner-extensions.md
- concepts/erp-interface.md
last_compiled: "2026-04-10"
---
# Supplier
## 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.
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.
---
## Main Attributes
| Property | Description |
|----------|-------------|
| Name | Unique identifier |
| Owner | Mandatory when Owner Extensions module is active; supplier is isolated to that owner's data scope |
| Type | Supplier type (configurable category) |
| Preferred carrier | Informational only; used for logistics reference |
| Delivery terms | Standard delivery terms for this supplier's inbound shipments |
| Verify items | If active, items from this supplier must be verified on first reception (eCommerce module) |
| Source address / contact | Origin address and contact for inbound shipments |
| Address for returns / contact | Return address and contact for supplier return orders |
---
## Use Cases
| Use Case | Description |
|----------|-------------|
| Inbound orders | Receipt orders must reference a supplier (the entity supplying the incoming stock) |
| Receipts | Receipts optionally indicate the supplier of the received stock |
| Returns | Return orders (supplier returns) reference the supplier receiving the returned stock |
---
## ERP Integration
| Message | Direction | Description |
|---------|-----------|-------------|
| SUP | ERP→WMS | Create/update supplier master data |
---
## Interface
| Path | Equipment | Description |
|------|-----------|-------------|
| `Masters > Suppliers` | PC | View and manage suppliers |
---
## Related
- [[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
- [[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
- [[erp-interface]] — SUP message syncs supplier master from ERP
wiki_old_13-05-2026/concepts/task.md
+216
View File
@@ -0,0 +1,216 @@
---
title: "Task"
type: concept
sources:
- areas/tasks/index.md
- areas/tasks/tasks.md
- areas/tasks/automatic_tasks.md
- areas/tasks/movements.md
- areas/tasks/semiautomatic_tasks.md
- areas/tasks/automatic_tasks_manual_warehouse.md
- areas/tasks/picking_tasks_manual_warehouse.md
- areas/tasks/ERP/counts/cor.md
related:
- concepts/location.md
- concepts/container.md
- concepts/stock.md
- concepts/putaway.md
- concepts/picking.md
- concepts/shipping.md
- concepts/replenishment.md
- concepts/count.md
last_compiled: "2026-04-10"
---
# Task
## Overview
A task is the fundamental unit of guided work in Easy WMS. It represents a physical movement to be performed within the warehouse: moving a container or loose stock from a source location/station to a destination location/station. Tasks are how the WMS communicates to operators (or automated systems) exactly what physical action to perform and in what order.
Tasks abstract the complexity of warehouse routing: the system handles compound routes, work zone restrictions, and equipment capabilities automatically. An operator on an RFT simply receives a task and executes it; they don't need to know which intermediate stations are involved. The same model applies to automatic warehouses, where tasks drive the AS/RS, AGVs, and conveyors.
Every significant warehouse process generates tasks: putaway, picking, shipping, replenishment, counts, crossdocking, kitting, defragmentation, and more. A task is always associated with a process type and a task type, which together define the exact operation required and which operators/equipment can execute it.
## Types
### Classification: Process type × Task type
Easy WMS distinguishes **process type** (the business process this task belongs to) from **task type** (the physical operation the operator/machine performs). The same task type (e.g., "Picking") can appear under different process types (e.g., Picking, Kitting, Replenishment, Dekitting).
| Process type | Task type | Description |
|---|---|---|
| **Putaway** | Putaway | Manual warehouse: deposit container or loose stock at storage location |
| **Putaway** | Approach | Automatic warehouse (Pick & Pass): move containers with putaway tasks in P&P sub-warehouses |
| **Putaway** | Movement | Extract empty containers to PS; extract non-empty containers to PS |
| **Picking** | Picking | Direct picking: RF/voice terminal (manual) or at picking conveyor (automatic) |
| **Picking** | Negative picking | Automatic warehouses only: negative pick at PK conveyor |
| **Picking** | Approach | Automatic warehouse (Pick & Pass): move containers with picking tasks |
| **Picking** | Cut | Cut-to-location: cut specified length from roll/coil; leave remainder at location |
| **Picking** | CutSupply | Move roll/coil to cutting station for controlled cutting |
| **Crossdocking** | Shipping | Move crossdocked stock to buffer location |
| **Crossdocking** | Loading | Move crossdocked stock directly to dock |
| **Crossdocking** | Putaway | Move crossdocked stock to warehouse storage location |
| **Crossdocking** | Replenishment to buffer | Replenish tense flow buffer from crossdocked stock |
| **Count** | Location count | Physical count of all stock in a location (manual warehouses) |
| **Count** | Container count | Physical count of a container's contents (manual and automatic) |
| **Count** | Item count | Physical count of a specific item across locations (manual and automatic) |
| **Replenishment** | Container replenishment | Move container to picking dedicated location (PDL); also for empty container stacking |
| **Replenishment** | Stock replenishment | Move loose stock to PDL |
| **Replenishment** | Picking | Replenishment between sub-warehouses (picking task variant) |
| **Replenishment** | Shipping | Replenishment between sub-warehouses (shipping task variant) |
| **Shipping** | Shipping | Move container to buffer, consolidation station, or packaging location |
| **Shipping** | Loading | Move container to dock for truck loading |
| **Kitting** | Picking | Pick kit component stock for assembly |
| **Kitting** | Shipping | Move container to kit assembly conveyor/station |
| **Dekitting** | Picking | Pick a kit for disassembly |
| **Dekitting** | Shipping | Move container to assembly station for disassembly |
| **Movement** | Movement | Generic moves: container/stock relocation, stacker management, PK picking, cart distribution, container reallocation |
| **Reject** | Reject | Container rejection to designated location |
| **Defragmentation** | Movement | Move stock/containers to consolidate and optimize space |
| **Defragmentation** | Shipping | Move defragmented stock toward shipping |
| **Picking locations emptying** | Movement | Empty dynamic picking locations |
| **Production** | Production | Manufacturing module: supply tasks for production lines |
### Automatic warehouse vs. manual warehouse tasks
In **manual warehouses**, tasks are executed by operators using RFTs, voice terminals, or workstations. The physical movement is performed by a human using forklifts or on foot.
In **automatic warehouses**, tasks are executed by automated systems (AS/RS, AGVs, conveyors). The object must always be a container (never loose stock directly, as stock needs a container to move through the automated system). Container tasks include precise X/Y coordinates within rack locations.
## Lifecycle
```
[Process event occurs]
↓
Task CREATED (pending movement generation)
↓
PENDING — waiting for movement to be generated
↓
GENERATED — movement created, no operator/machine assigned yet
↓
IN PROCESS — currently being executed
↓
FINISHED — task completed successfully
(at any point from Generated or In Process)
↓
CANCELED — task stopped by user action
```
### Status transitions
| Status | Description |
|---|---|
| **Pending** | Task created but movement not yet generated. System is calculating route or waiting for conditions. |
| **Generated** | Movement(s) created and ready for execution. Appears in operator queues. |
| **In Process** | Operator/equipment has started the task. Stock or container is being moved. |
| **Finished** | Task completed. Stock/container is at destination location. |
| **Canceled** | Task stopped. Container/stock remains where the operator reports leaving it. |
## 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).
Each segment has a configured **manager** (who/what executes it):
- **RF**: human operator with radio frequency terminal
- **Galileo** (or equivalent): automated system (AS/RS, conveyor controller)
- **Voice**: voice-directed operator
- **Workstation**: pick-to-light / workstation operator
**Example**: A task moves a container from Station A to Station B via C, D, and E:
- A→C: Galileo (AS/RS)
- C→D: RF (operator)
- D→E: Galileo
- E→B: RF (operator)
This creates 4 movements. Each completes before the next begins. The task is complete when the container reaches B.
**Movement statuses**: Pending → In Execution
Movement release (reset In Execution → Pending) is available for resolving incidents, especially in automatic warehouses.
## 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.
- **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).
- **Equipment release**: allowed only when task is in Generated state (processed quantity = 0, no containers moved).
- **Count tasks** cannot have their equipment released.
## Configuration
### Task execution order
For manual warehouse RF execution, the priority ordering is:
**Automatic tasks (general):** Round number → Priority → Empty channel → Stackability → Distance (picking route) → Aisle side (right first) → Height (low to high) → Creation date
**Picking tasks:** Round number → Priority → Empty channel → Stackability → Picking route → Aisle side → Height → Creation date
**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)
**Order picking (RF):** For task selection: assigned to user/equipment first → Priority → Release date. For task execution: same as automatic tasks.
### Semi-automatic mode
Allows tasks to be initiated by reading a container or location with stock, rather than receiving an explicit task assignment. Available task types: shipping, replenishment, putaway, movement, rejection.
**Flow:**
1. Operator reads container or location with loose stock
2. WMS shows summary of the best pending task (location, item if stock task, task type, destination, container to load)
3. Operator clicks Start → task assigned → enters standard task flow
4. WMS may propose additional tasks en route to optimize movements
Transactions are generated by the underlying process (not by semi-automatic mode itself).
**UI:** "Semi-automatic mode" from the "Tasks" menu (RFT).
## Interface
| Function | Hardware | Menu path |
|---|---|---|
| Tasks management and monitoring | PC | Warehouse → Tasks |
| Movement management | PC | Control → Movements |
| Automatic task distribution | PC | Warehouse → Tasks |
| Semi-automatic mode | RFT | Tasks → Semi-automatic mode |
| Manual task execution | RFT | Tasks → (process-specific options) |
### Available operations from Tasks view (PC)
| Operation | Restrictions |
|---|---|
| Manual task end | Not allowed for: picking, counting, stock replenishment, kit assembly, consolidation |
| Task cancellation | Container stays at location reported by user |
| Assign task to user | Respects work zone restrictions |
| Assign task to equipment | Respects type/zone/aisle restrictions |
| Unassign user | Only if task not yet in execution |
| Unassign equipment | Only if task not yet in execution |
| Priority change | Very Low / Low / Normal / High / Urgent |
| Equipment release | Only if In Process with zero processed quantity and no moved containers; not for count tasks |
## Common errors
| Symptom | Cause | Solution |
|---|---|---|
| Task stuck in Generated | Assigned equipment offline or cannot access work zone | Release equipment; reassign to available equipment or leave unassigned |
| 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 |
| 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
- [[container]] — most automatic warehouse tasks move containers; task references container code and type
- [[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
- [[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
- [[replenishment]] — replenishment generates Container replenishment or Stock replenishment tasks to PDLs
- [[count]] — count processes generate Location count, Container count, or Item count tasks
wiki_old_13-05-2026/concepts/tense-flow.md
+75
View File
@@ -0,0 +1,75 @@
---
title: "Tense Flow (Flux tendu)"
type: concept
sources:
- sources/archives/16_Tense_Flow.md
related:
- concepts/picking.md
- concepts/replenishment.md
- concepts/reception.md
- concepts/order-outbound.md
- concepts/stations.md
last_compiled: "2026-04-17"
---
# Tense Flow (Flux tendu)
## 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.
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.
4. A closing step that transfers the client containers to the shipping buffer.
## EasyS Configuration
1. Add a **Tense Flow** element + an associated **buffer** (e.g. `PREPARATION`).
2. Associate the tense-flow element to an aisle (`Count`, `Load`, `Pick`, `Put`, `Unload`).
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.
## Functional Flow
### 1. Launch in tense flow (SmartUI)
On a released outbound order, click **"Lancer en flux tendu"**. The order transitions to **"Assigned"** and a replenishment task to the `PREPARATION` buffer is created automatically.
### 2. Execute the replenishment (RFT)
RFT menu : **Tâches → Tâches à flux tendu**. Execute the task to move stock from the source location to the buffer.
### 3. Virtual picking (RFT)
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.
3. Scan the new container or the destination location.
4. Enter the item + picked quantity (and any logistic attributes).
The system then offers to put the remaining stock away using the standard putaway strategies.
### 4. End of tense flow
Once all the client containers are filled, transfer them to the `EXPEDITION` buffer (the task is created automatically), then continue the order normally (truck loading, prepackaging, or transfer to the shipping dock).
## 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.
**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.
## Related
- [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
- [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
- [Stations & Routes](stations.md) — tense-flow buffer and element are configured alongside standard stations
wiki_old_13-05-2026/concepts/transactions.md
+357
View File
@@ -0,0 +1,357 @@
---
title: "Transactions & Notification Events"
type: concept
sources:
- areas/TransactionTypes.md
- areas/notificationevents.md
- areas/ERP.md
- Cross-source knowledge from all batches
- sources/archives/10_Transactions.md
related:
- concepts/erp-interface.md
- concepts/stock.md
- concepts/container.md
- concepts/order-inbound.md
- concepts/order-outbound.md
- concepts/count.md
- architecture/application-dictionary.md
- architecture/security.md
last_compiled: "2026-04-17"
---
# Transactions & Notification Events
## Overview
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))
Separately, **Notification Events** are operational alerts that fire when conditions of interest occur (stock low, order failed, etc.). These drive the SCEM subscription system.
## Transaction Structure
Every transaction record contains:
| Field | Description |
|-------|-------------|
| TransactionCode | Type code (e.g., `CON.MOVE`, `STK.ADJ`) |
| Version | Transaction version (e.g., `001`) |
| Site | Warehouse where it occurred |
| User | User who triggered it |
| Timestamp | When it occurred |
| Equipment | RF terminal or workstation IP (if applicable) |
| ContainerCode | Container involved (if applicable) |
| LocationCode | Source location |
| LocationTo | Destination location (if applicable) |
| TaskNumber | Task that caused it (if applicable) |
| Document1/2 | Related document codes (order, container type, etc.) |
| DocumentLine1 | Related line number |
| Item, Quantity, UoM | Stock details (if applicable) |
| LogAtt | Logistic attributes (if applicable) |
The **Post-processed** flag indicates whether the transaction triggers an ERP message.
### 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.
## Transaction Catalog
### Container Transactions (CON.*)
| Code | Post-processed | Description | ERP Message |
|------|---------------|-------------|-------------|
| `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.COS.001` | No | Container entered outbound conveyor (PS) | — |
| `CON.CREATE` | No | Container created (manual, picking, or count) | — |
| `CON.DELETE` | No | Container deleted (L&F or after count) | — |
| `CON.LOAD` | No | Container loaded during truck loading | — |
| `CON.LOCATE` | No | Container moved to storage via putaway task | — |
| `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.RECEP` | No | Container received in any reception process | — |
| `CON.SEND.L&F` | No | Container sent to Lost & Found | — |
| `CON.SHIPPED` | No | Container status changed to Shipped (order close) | — |
| `CON.SHIPPING` | No | Shipping task confirmed for container | — |
| `CON.VASDONE` | No | VAS template applied to container | — |
**Key data fields by transaction:**
- `CON.ASN.001`: ContainerCode, LocationCode, Document1=ReceiptCode, Document2=ContainerTypeCode
- `CON.MOVE`: ContainerCode, LocationCode (from), LocationTo, Equipment, TaskNumber, Document1=ShippingOrder
- `CON.LOAD`: ContainerCode, LocationCode, LocationTo, Equipment, TaskNumber, Document1=ShippingOrder
---
### Count Transactions (COU.*)
| Code | Post-processed | Description | ERP Message |
|------|---------------|-------------|-------------|
| `COU.CLS` | No | Count closed | — |
| `COU.CNL` | No | Count canceled | — |
| `COU.CST` | No | Count status changed | — |
| `COU.END` | Yes | Count closed/canceled (ERP-initiated count) | COF |
**Notes:**
- `COU.END` only fires for counts created by ERP via COR message
- `COU.CST` tracks all intermediate status changes (Disabled → Releasing → In Process)
---
### Stock Transactions (STK.*)
| 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.CREATE` | No | Stock created manually or from ASN loose stock | — |
| `STK.DELETE` | No | Stock line deleted (fused stock split) | — |
| `STK.KIT.COMP` | No | Stock consumed for kit assembly | — |
| `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.LOCATE` | No | Stock moved to storage via putaway task | — |
| `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.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.SEND.L&F` | No | Stock sent to Lost & Found | — |
| `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.VASDONE` | No | VAS template applied to stock | — |
**Key data fields by transaction:**
- `STK.ADJ`: LocationCode, ContainerCode, Quantity, TaskNumber
- `STK.PICKING`: ProductCode, UoMCode, Quantity, LogAtt, ContainerCode (source), ContainerTo (destination), LocationCode, LocationTo, TaskNumber, Document1=ShippingOrder
- `STK.MOVE`: ContainerCode, LocationCode, LocationTo, Equipment, TaskNumber, Item, Quantity, UoM, StockStatus, LogAtt
---
### Stock Status Change Transaction
| Code | Post-processed | Description | ERP Message |
|------|---------------|-------------|-------------|
| `CST.STK` | Yes | Stock status changed (quality lock/unlock) | STC |
**Key data fields:**
- LocationCode, ContainerCode, Quantity, StockLogisticAttributes
- PreviousUserDefinedStatusCode, PreviousReceptionDefaultStatusCode
---
### Receipt Order Transactions (INO.*)
| Code | Post-processed | Description | ERP Message |
|------|---------------|-------------|-------------|
| `INO.CLS` | Yes | Receipt order manually or auto-closed | ROF |
| `INO.CNL` | Yes | Receipt order canceled | ROF |
| `INO.CST` | Yes | Receipt order status changed | ROC |
---
### Receipt Transactions (REC.*)
| Code | Post-processed | Description | ERP Message |
|------|---------------|-------------|-------------|
| `REC.CLS` | Yes | Receipt manually or auto-closed (with stock) | REF |
| `REC.CNL` | No | Receipt manually canceled | — |
| `REC.CST` | No | Receipt status changed (Pending → Receiving) | — |
---
### Shipping Order Transactions (OUT.*)
| Code | Post-processed | Description | ERP Message |
|------|---------------|-------------|-------------|
| `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.UNG` | No | Shipping order removed from group/fusion | — |
---
### Route, Load Transactions (ROU.*, LOAD.*)
| Code | Post-processed | Description | ERP Message |
|------|---------------|-------------|-------------|
| `ROU.CLS` | No | Route closed | — |
| `ROU.CNL` | No | Route canceled | — |
| `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 | — |
---
### Task Transactions (TSK.*)
| Code | Post-processed | Description |
|------|---------------|-------------|
| `TSK.CANCEL` | No | Task canceled from Tasks view |
| `TSK.COU` | No | Count task finished |
| `TSK.ERR.EXTRACT` | No | Shipping task execution error (auto warehouse) |
| `TSK.ERR.PUTAWAY` | No | Putaway task execution error (auto warehouse) |
| `TSK.LOC.001` | No | Putaway task confirmed |
| `TSK.REP.001` | No | Replenishment task confirmed |
| `TSK.SHIP` | No | Shipping task confirmed |
**Key data fields (automatic warehouse tasks):**
- ContainerCode, LocationCode, Depth (channel depth), X, Y (position), TaskNumber
---
### Work Order Transactions (WOR.*)
| Code | Post-processed | Description | ERP Message |
|------|---------------|-------------|-------------|
| `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 | — |
---
### Kit Order Transaction (KOU.*)
| Code | Post-processed | Description |
|------|---------------|-------------|
| `KOU.CLS.001` | No | Kit assembly shipping order closed |
---
### Container Lock Transactions (LCK.*, ULK.*)
| Code | Post-processed | Description |
|------|---------------|-------------|
| `LCK.CON.001` | No | Container lock applied |
| `ULK.CON.001` | No | Container lock removed |
**Key data fields:**
- ContainerCode, LocationCode, Document1=LockTypeCode, Document2=LockEndDate
---
### Packaging Transaction (DEL.*)
| Code | Post-processed | Description |
|------|---------------|-------------|
| `DEL.PACKAGE` | Yes | Shipping and deleting of Multi-Carrier package |
---
### Desk Order Transactions (DESK.*)
| Code | Post-processed | Description |
|------|---------------|-------------|
| `DESK.CLS` | No | Desk order closed |
| `DESK.CNL` | No | Desk order canceled |
| `DESK.CST` | No | Desk order status changed |
---
### Stock Contrast Transactions (SCR.*, STOCKSYNC.*)
| Code | Post-processed | Description | ERP Message |
|------|---------------|-------------|-------------|
| `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 |
---
### ABC Analysis Transaction (SAC.*)
| Code | Post-processed | Description |
|------|---------------|-------------|
| `SAC.SEND` | No | ABC analysis communicated to ERP |
---
## 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).
See [Supply Chain Event Management](../modules/supply-chain-event.md) for subscription management.
### Core WMS Notification Events
| Code | Severity | Notification Group | Description |
|------|----------|--------------------|-------------|
| `EasyWMS_AisleBlockInputs` | Information | Aisles control | An aisle has been disabled for inbounds |
| `EasyWMS_AisleBlockOutputs` | Information | Aisles control | An aisle has been disabled for shipping |
| `EasyWMS_AisleLock` | Information | Aisles control | An aisle has been locked |
| `EasyWMS_ExtractionError` | Information | Aisles control, Locations management | Control system reports container extraction error |
| `EasyWMS_ContainerRejected` | Information | Containers | Container has been rejected at a station |
| `EasyWMS_EmptyPickingLocation` | Information | Replenishments | Dynamic picking locations must be emptied for order demand |
| `EasyWMS_IncompleteAccountReserveInboundOrder` | Information | Receipt, Shipping orders | Inbound account reserve incomplete (stock failure at receipt) |
| `EasyWMS_IncompleteAssignmentOutboundOrder` | Information | Shipping orders | Shipping order has a stock failure (cannot fully assign) |
| `EasyWMS_IncompleteOutboundOrderReserveInboundOrder` | Information | Receipt, Shipping orders | Inbound reserve for shipping order incomplete |
| `EasyWMS_OutboundLineModifiedWithInvalidPreparedStock` | Warning | Shipping orders | Prepared stock exceeds modified line quantity; must remove excess |
| `EasyWMS_OutboundOrderClosedWithoutAllInboundReserves` | Information | Shipping orders | Order closed with unshipped inbound reserves |
| `EasyWMS_OutboundOrderIssue` | Warning | Shipping orders | Issue created on shipping order |
| `EasyWMS_OutboundOrderWithExcess` | Information | Shipping orders | Order shipped with excess stock on a line |
| `EasyWMS_PutawayError` | Information | Locations management, Aisles control | Control system error on container deposit |
| `EasyWMS_RelocateError` | Information | Relocation error | Cannot relocate container to extract deeper one |
| `EasyWMS_StockExpired` | Warning | Stock | New expired stock detected in warehouse |
| `EasyWMS_StockForwardTraceabilityLockCompleted` | Information | Stock | Traceability lock process completed for item |
| `EasyWMS_StockForwardTraceabilityLockStarted` | Information | Stock | Traceability lock process started for item |
| `EasyWMS_StockNextToExpire` | Warning | Stock | Stock approaching expiry (below days-of-life threshold) |
| `EasyWMS_StockOfProductBelowMinimum` | Warning | Stock | Item stock quantity below configured minimum |
| `EasyWMS_StockOfProductConversionBelowMinimum` | Warning | Stock | Item presentation (UoM) stock below minimum |
| `EasyWMS_StockReserveNotAssignable` | Information | Locations management, Shipping orders | Reserved stock in non-assignable location |
| `EasyWMS_PieScalesToleranceExeededForContainer` | Information | Containers | Container weight exceeds PIE scale tolerance |
| `EasyWMS_InboundOrderReceived` | Information | Receipt | Receipt order fully received |
| `EasyWMS_OutboundOrderShipped` | Information | Shipping orders | Shipping order fully shipped |
| `EasyWMS_OutboundOrderPrepackagingCalculationFailed` | Warning | Shipping orders | Cannot calculate prepackaging for order |
| `EasyWMS_MixingOfItemsNotAllowed` | Warning | Locations management, Stock | Items with mix restrictions have been mixed |
### Module Notification Events
Additional notification events are defined by optional modules:
| Module | Event Code | Description |
|--------|-----------|-------------|
| AGV | (module-specific) | AGV communication errors, task failures |
| Pallet Shuttle | (module-specific) | Battery warnings, PS faults |
| SCEM | `Notification_GNAImportError` | SCEM notification import failure |
| Slotting | (module-specific) | New slotting recommendations available |
| Billing | (module-specific) | Billing validation events |
| DOM | (module-specific) | Orchestration failures, stock shortfalls |
### Subscription Scope
| Who Can Subscribe | Events Available |
|------------------|-----------------|
| SuperAdmin | All events in all warehouses |
| Administrator | All events in assigned warehouses |
| Manager | All events in assigned warehouses |
| 3PL Client | Events scoped to their owner only |
## Common Errors
| Symptom | Cause | Solution |
|---------|-------|---------|
| ERP not receiving SOF after order close | Post-processor not running or stuck | Restart integration pool; check post-processing queue |
| Duplicate STV messages | STK.ADJ fired multiple times | Check for duplicate adjustment operations; review concurrent requests |
| Notification event not firing | SCEM subscription not configured | Set up subscription via Supply Chain Event Management admin |
| Transaction not found in audit log | Query limited to wrong site/date | Expand search filters; transactions are per-site |
| `EasyWMS_StockNextToExpire` not triggering | Days-of-life threshold not configured on item logistic profile | Set `DaysToAlert` on item's logistic profile |
## Related
- [ERP Interface](erp-interface.md) — ERP messages triggered by post-processed transactions
- [Stock](stock.md) — STK.ADJ, STK.MOVE, STK.PICKING
- [Container](container.md) — CON.* transactions
- [Inbound Order](order-inbound.md) — INO.CST, INO.CLS → ROC, ROF
- [Outbound Order](order-outbound.md) — OUT.CST, OUT.CLS → SOC, SOF
- [Count](count.md) — COU.END → COF
- [Quality Control](quality-control.md) — CST.STK → STC
- [Application Dictionary](../architecture/application-dictionary.md) — Commands and Events that generate transactions
- [Security](../architecture/security.md) — Transactions as audit trail
- [Supply Chain Event Management](../modules/supply-chain-event.md) — Notification event subscriptions
wiki_old_13-05-2026/concepts/warehouse-designer.md
+307
View File
@@ -0,0 +1,307 @@
---
title: "Warehouse Designer (Web Configurator)"
type: concept
sources:
- areas/layout/warehouse_designer/index.md
- areas/layout/warehouse_designer/masters/container_type.md
- areas/layout/warehouse_designer/masters/rack_type.md
- areas/layout/warehouse_designer/masters/workstation.md
- areas/layout/warehouse_designer/zones/storage_zones.md
- areas/layout/warehouse_designer/zones/working_zones.md
- areas/layout/warehouse_designer/zones/subwarehouses.md
- areas/layout/warehouse_designer/equipments/equipment_type.md
- areas/layout/warehouse_designer/equipments/equipment.md
- areas/layout/warehouse_designer/equipments/equipment_restriction.md
- areas/layout/warehouse_designer/equipments/equipment_restriction_by_quantity.md
- areas/layout/warehouse_designer/equipments/equipment_restriction_by_incompatibility.md
- areas/layout/warehouse_designer/layout/layout_shelves.md
- areas/layout/warehouse_designer/layout/layout_docks.md
- areas/layout/warehouse_designer/layout/layout_stages.md
- areas/layout/warehouse_designer/general/wd_delete_action.md
- areas/layout/warehouse_designer/activity/change_log.md
- areas/layout/warehouse_designer/activity/transfer_list.md
- areas/layout/warehouse_designer/activity/transfer_comparison.md
- areas/inventory_management/warehouse_map/index.md
related:
- concepts/location.md
- concepts/stations.md
- concepts/container.md
- concepts/putaway.md
- concepts/replenishment.md
last_compiled: "2026-04-10"
---
# Warehouse Designer (Web Configurator)
## Overview
The **Web Warehouse Configurator** is a MAP (Mecalux Application Platform) application included in Easy WMS that allows warehouse configuration changes to be made **autonomously from the web browser**, without requiring access to the EasyS desktop configuration tool for all operations. It is the primary tool for managing the logical structure of the warehouse: zones, equipment, and physical layout elements.
This tool is complemented by the **Warehouse Map**, a separate view providing 3D and 2D visual representations of the warehouse with real-time status and stock location capabilities.
The key distinction: **EasyS** (a separate application) creates the physical station layout and routes; the **Web Configurator** manages masters, zones, equipment, and fine-tunes the layout from the browser. Changes made in EasyS are transferred to Easy WMS via **data transfer** (synchronization step).
## Masters
### Container Types
Defines the physical dimensions of containers used in the warehouse. The container type conditions shelf configuration, location compatibility, and equipment restrictions.
**Attributes:**
| Field | Description |
|-------|-------------|
| Code | Unique identifier |
| Description | Free text |
| Width (L) | Distance perpendicular to shelf entrance (mm) |
| Height (H) | Maximum container height when empty (mm) |
| Depth (D) | Distance parallel to shelf entrance (mm) |
| Weight | Empty container weight |
| Maximum weight | Weight limit for stock inside the container |
| 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.
**Deletion:** Cannot delete a container type in use by any location. System shows total locations affected + breakdown by warehouse before allowing deletion.
### Rack Types
Defines how container types fit into locations (alveoli). Rack types set the **volumetric constraints** of a location: dimensions and maximum weight. They determine how many containers of each type fit at a location.
Note: In conventional manual locations, the maximum containers per type is configured directly per location, not via rack types.
**Attributes:**
| Field | Description |
|-------|-------------|
| Code | Unique identifier |
| Width | Perpendicular to shelf entrance (mm) |
| Height | Maximum height supported (includes container + stock) |
| Depth | Parallel to shelf entrance (mm) |
| Maximum weight | Maximum load weight the location can support |
Editing a rack type can generate incompatibility with existing locations already assigned to that rack type.
### Workstations
Automatic stations with picking role or PTL controller require an associated workstation.
**Attributes:** Code, description, serial number, computer type (RF / PC / Server).
## Zones
### Storage Zones
Logical groupings of locations, typically matching item rotation zones (e.g., ABC classification zones, temperature zones).
**Attributes:** Code, description, Temperature. Temperature-controlled stock is directed to matching temperature zones.
**Operations from Warehouse Map (2D view):** Change storage zone of selected locations by shelf and depth.
### Work Zones
Define which equipment types are allowed to work in a zone, which processes and task types they can execute, and relative process priorities within the zone.
**Attributes:** Code, description. Equipment type relationships define: which equipment types are allowed, which processes/tasks they can perform, and priority ordering.
Work zones enable fine-grained control of operator/equipment allocation: restricting forklifts to certain aisles, prioritizing replenishment over shipping in a zone, etc.
### Subwarehouses
Logical areas that group locations within the warehouse. Used for:
- Putaway strategy configuration (alongside storage zones)
- Pick-and-pass sub-warehouse routing (each sub-warehouse has a Workzone station)
- Equipment zone assignment
- ABC/sub-warehouse item classification
**Default subwarehouse:** Every configuration includes a default subwarehouse. It cannot be deleted or modified. All stations added without explicit sub-warehouse assignment use the default.
**Attributes:** Code, description, Temperature (same temperature-control logic as storage zones).
## Equipments
### Equipment Types
Define the physical characteristics and capabilities of a type of equipment. Easy WMS uses these to control where equipment can work and determine speed calculations.
**Attributes:**
| Field | Description |
|-------|-------------|
| Code | Unique identifier |
| Maximum height | Maximum reachable height (mm) |
| Maximum weight | Maximum load weight |
| Maximum containers | Simultaneous container capacity |
| Can move | Restrict to transportation only (vs tasks that require stock handling) |
Editing an equipment type can cause incompatibilities in location searches or order preparation due to changed constraints.
### 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.
**Attributes:**
| Field | Description |
|-------|-------------|
| Code | Unique identifier |
| Equipment type | Parent type defining characteristics |
| Equipment group | Group of related equipment (e.g., same aisle team) |
| Empty containers | How the equipment handles empty containers (return to ECB, stack, etc.) |
| Extra locations | One or more locations associated with the equipment, used for picking tasks |
**Station management from Equipment view:**
- Assign aisles and processes to the equipment's stations
- Set default reception/shipping station for this equipment
**Extra locations:** Default and non-editable storage mode = Stock. Used for picking tasks in manual warehouse where the operator collects stock into a cart location.
### Equipment Restrictions
Rules that limit equipment access to aisles or work areas. Two types:
**Quantity restrictions:** Define the maximum number of simultaneous equipment (of a type or total) allowed in a given zone or aisle. Prevents congestion.
**Incompatibility restrictions:** Define which equipment types cannot operate in the same zone simultaneously. Prevents conflicts (e.g., a wide forklift cannot operate in the same aisle as a narrow stock picker at the same time).
## Layout Management
### Shelves
Shelves (storage racks) can be modified from the Web Configurator by row or column as the minimum unit:
- **Clone rows/columns:** Add capacity without full EasyS round-trip
- **Delete rows/columns:** Remove capacity
- **Edit location properties:** Modify characteristics of all locations in a row or column simultaneously (rack type, storage mode, allowed container types, etc.)
Shelf stations themselves are created in EasyS; the Web Configurator allows post-creation adjustments.
### Docks
Dock configuration from the Web Configurator:
- **Default dock assignment:** Set a dock as the default for shipping orders (auto-assigned on order creation)
- **Default dock for receipts:** Set a dock as the default for receipt orders
- **Aisle/process assignment:** Assign which process (loading, unloading, counting, picking, location) is designated to each aisle of the dock
- **Modification of aisle/process assignment:** Delete existing assignment first, then create a new one (direct modification not supported)
### Stages
Stage configuration from the Web Configurator:
- **Default stage for shipping/receipt orders:** Auto-assigned on order creation
- **Aisle/process assignment:** Same as docks (loading, unloading, counting, picking, location)
- **Extra locations:** Add or delete locations within the stage
## Change Log & Transfer Management
### Change Log
The Web Configurator tracks all configuration modifications with full audit trail. The change log enables:
- Comparison between any two configuration transfers
- Element-by-element difference display (created, modified, deleted)
- PDF export of change comparison report
**Change log fields:** Export date, time, description, number of changes, user, origin (EasyS / Web Configurator / EasyAssistant).
### Transfer List (History)
Complete chronological history of all configuration transfers. Each transfer records: date/time, description, number of modifications, user, origin system.
**Operations:**
- **Revert changes:** Restore a previous warehouse configuration state
- **Filter/search:** By export date and description (up to 3 criteria)
### Transfer Comparison
Side-by-side comparison of two configuration transfers. Shows which elements were created, modified, or deleted between the two states. Direction matters: comparing left (newer) to right (older) shows "new" = exists in left but not in right.
**Export:** PDF report with all differences.
## Deletion Rules
The Web Configurator enforces safe deletion:
1. If the element to be deleted has relationships that can be disassociated without error → warning displayed, but deletion allowed
2. If the element is in active use that cannot be cleanly unlinked (e.g., rack type assigned to active locations) → deletion blocked
Error message shows: total locations affected (broken down by warehouse) + configuration codes affected grouped by station.
Deletions take effect across all warehouses sharing the element if the element is shared organization-wide.
## Warehouse Map
A separate visualization tool in Easy WMS (distinct from the Web Configurator) providing real-time warehouse status and stock search.
### 3D View
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 |
| 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 |
| Location search | Find a specific location by code |
| Storage zones visualization | Color-coded display of defined storage zones |
| Working zones visualization | Color-coded display of working zones |
| Saved viewpoints | Save and retrieve camera focus positions for frequently needed views |
### 2D View
Depth-by-depth rack view for detailed location inspection and bulk operations:
| Feature | Description |
|---------|-------------|
| Location status | Blocks, container count, picking dedicated locations, reservation indicators per alveolus |
| Location label printing | Select range of locations → print labels (format + quantity) |
| Work zone change | Change work zone for selected locations (shelf + depth) in bulk |
| Storage zone change | Change storage zone for selected locations (shelf + depth) in bulk |
| Container/stock creation | Register containers or loose stock at a selected location |
| Container movement | Request extraction to PK, PS, or relocation |
| Stock adjustment | Adjust loose stock at selected location and depth |
| Search | Container / item / location search within the selected shelf and depth |
**Location status legend:**
- Putaway error indicator
- Extraction error indicator
- Inbound reserve indicator
- Outbound reserve indicator
### 2D Heat Map (Slotting module required)
Visual activity intensity map overlaid on 2D view:
- Filter by: areas displayed (locations/docks/stages), task types (all or specific), time range
- Click location: see number and type of tasks for that period
- Configurable color ranges: define custom thresholds and colors
- Use case: identify hotspots, detect inefficiencies, plan product relocation, compare periods
## Interface
| View | Menu Path | Equipment |
|------|-----------|-----------|
| Web Warehouse Configurator | "Configuration" menu or direct MAP app URL | PC |
| Warehouse Map (3D/2D) | "Warehouse" menu → Warehouse Map | PC |
| Change Log | Within Web Configurator | PC |
## Common Errors
| Error | Cause | Solution |
|-------|-------|----------|
| Cannot delete container type | Container type in use by active locations | Identify and reassign affected locations first |
| Cannot delete rack type | Rack type assigned to active locations | Remove rack type from all locations or delete locations first |
| Equipment type edit causes search errors | Changed height/weight constraints conflict with existing putaway strategies | Review and update putaway strategies and work zones |
| Transfer comparison shows unexpected deletions | Configuration reverted to older state | Verify transfer direction (left=newer vs right=older) before interpreting results |
| Stage configuration changes not reflected in WMS | Changes made in EasyS not transferred | Run data transfer from EasyS to Easy WMS |
## Related
- [[location]] — Rack types and storage zones directly configure location properties
- [[stations]] — Stations created in EasyS; Warehouse Designer edits docks/stages/shelves post-transfer
- [[container]] — Container types define dimensions used in warehouse design
- [[putaway]] — Storage zones and subwarehouses configure putaway strategy targeting
- [[replenishment]] — Work zones define equipment eligibility for replenishment tasks
wiki_old_13-05-2026/concepts/weights.md
+141
View File
@@ -0,0 +1,141 @@
---
title: "Weights"
type: concept
sources:
- sources/archives/33_Les_poids.md
related:
- concepts/container.md
- concepts/stock.md
- concepts/product-item.md
- concepts/reception.md
- concepts/stations.md
- modules/pie.md
last_compiled: "2026-04-17"
---
# Weights
## 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).
## Container-level weight fields
Five fields, each with a distinct trigger and formula.
| WMS field | French label | Definition | Updated when |
|---|---|---|---|
| **Calculated Weight** | Poids calculé | Theoretical (item) weight − adjustments | On every stock movement (picking, transfer, adjustment) |
| **Scale Weight** | Poids balance | Raw gross weight measured at the PIE | **PIE pass only** |
| **Theoretical Weight** | Poids théorique (article) | (unit weight × quantity) + container tare weight | At creation and on every adjustment |
| **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:
> - **Poids théorique (article)** = `Theoretical Weight` (from the item master)
> - **Poids théorique (balance)** = `Theoretical Scale Weight` (from the scale, minus adjustments)
>
> Reports and customs must specify which one they are reading.
### Formulas
- **Theoretical Weight** = *unit weight on item master × quantity + container tare (from EasyS)*
- **Scale Weight** = *gross weighed value at the PIE*
- **Calculated Weight** = *Theoretical Weight − cumulative adjustments (picking, transfers…)*
- **Theoretical Scale Weight** = *Scale Weight − cumulative adjustments*
- **Real Weight** = `max(Calculated Weight, Theoretical Scale Weight)`
## Stock-line weight fields
On each stock line (`Stock` record):
| Field | Description |
|---|---|
| **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.
## 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.
- **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.
## PIE pass
When a container passes the PIE:
1. The scale measures the gross weight (goods + pallet).
2. **Scale Weight** ← measured value.
3. **Theoretical Scale Weight** ← Scale Weight − existing adjustments.
4. **Real Weight** ← `max(Calculated Weight, Theoretical Scale Weight)`.
> The PIE writes only the container-level fields. Line-level weights are not updated by the PIE directly ; if needed, they are recomputed by the custom that drives the PIE reaction (e.g., proportional distribution).
## Variable-weight items
### Enabling variable weight
The **"Poids variable"** (Variable weight) option lives on the **logistic profile** of the item. When it is on, indicating the stock's weight at creation becomes **mandatory**.
### "Poids moyen" option (average weight from receipt)
When both of the following are true, the WMS pre-fills the stock weight at reception from the receipt line:
- **Poids moyen** is enabled on the logistic profile.
- The expected stock-line weight is carried in the ROR's logistic attributes (e.g., `"Weight": 20`).
### StockAdjust limitation
`StockAdjust` **cannot modify the weight of a stock line** if the item is not configured as variable-weight on its logistic profile. Use a weighing flow or a custom if non-variable items need weight corrections.
## Weight check on stock entry
The workflow **`Stock_CheckWeightToCreateStockInContainer_UI`** runs at stock creation:
- 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.
## Worked examples
### Fixed-weight item — 25 kg pallet, item weighs 250 kg
| Step | Calculated | Scale | Theoretical (item) | Real | Theoretical Scale |
|---|---|---|---|---|---|
| Creation | 275 | 0 | 275 | 275 | 0 |
| PIE pass (280 kg) | 280 | 280 | 275 | 275 | 280 |
### Same item, new pallet created after EasyS tare change (25 → 24 kg)
| Step | Calculated | Scale | Theoretical (item) | Real | Theoretical Scale |
|---|---|---|---|---|---|
| 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.
### Variable-weight item — 10 bags, 100 kg declared
| Step | Calculated | Scale | Theoretical (item) | Real | Theoretical Scale |
|---|---|---|---|---|---|
| Creation | 124 | 0 | 124 | 124 | 0 |
| PIE pass (107 kg) | 107 | 107 | 124 | 124 | 107 |
> The PIE updates Scale Weight and Calculated Weight at the container level. The stock lines inside the container are **not** auto-recalculated unless a custom redistributes the measured value.
## Open questions
| # | Subject | Status |
|---|---|---|
| 1 | A rejection workflow at PIE (same check as `Stock_CheckWeightToCreateStockInContainer_UI` but blocking rather than alerting) | To confirm |
| 2 | The "pesé − tare théorique support (MCH)" formula produces an *estimated net weight* that is not persisted as a field | To investigate |
## Related
- [[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
- [[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
- [[stations]] — PIE station type drives scale-weight capture
wiki_old_13-05-2026/consume.log
+309
View File
@@ -0,0 +1,309 @@
# Journal de consommation
## [2026-05-05] session-001
- **Fichier** : `FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5.docx`
**Type** : Analyse fonctionnelle (document de base signé 28/11/2025)
**Actions** :
- Créé `limagrain/01-inbound/reception-fournisseur.md` (réception production + extérieure)
- Créé `limagrain/01-inbound/reception-retour.md` (retours client, API lot SAP)
- Créé `limagrain/01-inbound/controle-qualite-reception.md` (PIE, tolérances, verrous)
- Créé `limagrain/01-inbound/flux-erp-inbound.md` (messages ITM, ASN, ROR, API, REF, ROF, LOC)
- Créé `limagrain/02-stockage/asrs-miniload.md` (4 allées, racks, nomenclature)
- Créé `limagrain/02-stockage/zones-stockage.md` (3 zones avec coordonnées)
- Créé `limagrain/02-stockage/putaway-strategies.md` (5 stratégies par type palette)
- Créé `limagrain/02-stockage/galileo-config.md` (architecture IT, composants, PIE)
- Créé `limagrain/02-stockage/defragmentation.md` (zone client, planning)
- Créé `limagrain/02-stockage/processus-anoxie.md` (TK01, flag, relocalisation)
- Créé `limagrain/02-stockage/palettes-vides.md` (piles, réapprovisionnement)
- Créé `limagrain/03-picking/picking-combinatoire.md` (ordonnancement, picking négatif)
- Créé `limagrain/03-picking/stations-picking.md` (3 îlots, 6 postes, modes)
- Créé `limagrain/03-picking/consolidation-regroupement.md` (vue, ordonnancement, MOV)
- Créé `limagrain/03-picking/echantillonnage.md` (inventaire, prélèvement 200g)
- Créé `limagrain/04-outbound/shipping-orders.md` (4 types OS, libération, assignation)
- Créé `limagrain/04-outbound/flux-expedition.md` (8 étapes, MII, recert, messagerie)
- Créé `limagrain/04-outbound/consolidation-chargement.md` (6 quais, 11 poumons)
- Créé `limagrain/04-outbound/flux-erp-outbound.md` (RUT, SOR, SOF, LOF, PCK, MOV)
- Créé `limagrain/06-erp-interface/messages-reference.md` (catalogue 21 messages)
- Créé `limagrain/06-erp-interface/mapping-erp-wms.md` (CHG, statuts, STR)
- Créé `limagrain/07-admin/utilisateurs-groupes.md` (3 groupes, permissions)
- Créé `limagrain/08-transverse/questions-ouvertes.md` (toutes questions identifiées)
- Mis à jour tous les `_index.md` avec diagrammes Mermaid
- Mis à jour `limagrain/README.md` (table des matières complète)
- Mis à jour `limagrain/glossaire-limagrain.md` (+5 termes : SCR, WSC, COR, F9, B6)
**Cross-refs** : liens croisés entre toutes les pages (inbound↔outbound, picking↔ERP, stockage↔expédition)
**Questions** : 22 questions ouvertes centralisées dans `limagrain/08-transverse/questions-ouvertes.md`
## [2026-05-05] session-002
- **Fichier** : `Données principales + stock - LIMAGRAIN - DEV - Confluence.md`
**Type** : Export page Confluence (ateliers interfaçage 05/01 → 23/02/2026)
**Action** : Créé `limagrain/06-erp-interface/donnees-principales.md` (architecture Lot SAP = Article WMS, mapping ITM 18+ champs, attributs logistiques stock, profils, poids, paramètres interface)
**Cross-refs** : Lien ajouté depuis `limagrain/06-erp-interface/mapping-erp-wms.md`
**Questions** : CstAtt10 Stage à ajouter, création stock via attributs logistiques à tester, impact suppression CstAtt stock → ajoutés dans `limagrain/08-transverse/questions-ouvertes.md`
## [2026-05-05] session-003
- **Fichier** : `Réception - LIMAGRAIN - DEV - Confluence.md`
**Type** : Export page Confluence (ateliers DEV réception 2026)
**Actions** :
- Mis à jour `limagrain/01-inbound/reception-fournisseur.md` (supports virtuels séquence 8000, containerMovedEvent, redirection routes/distances, SSCC handling, constitution mono-ref standard, rejet poumon au sol + notification SmartUI, IsSingleReceipt, AutoCloseReception=false, REF à la clôture manuelle, zone de stockage dans REF, mécanisme blocage ROF via CstAtt, réception excédentaire, filmage via custom data Galileo)
- Mis à jour `limagrain/01-inbound/reception-retour.md` (InboundType=1, tolérance illimitée, ReceiveLessAllowed=true, codes génériques uniques, API lot SAP timeout/retry détaillé, choix article multi-produit, verrou "Écart inventaire", prompt type poste abandonné)
- Mis à jour `limagrain/01-inbound/controle-qualite-reception.md` (contrôles PIE détaillés, répartition poids au prorata avec formules ratio, multi-ref seuil = plus petit poids unitaire, verrou sur support pas stock, notification SmartUI, CstAtt01 poids unitaire, ZSIZ via WSC avec timing REF et flag LOC, ASO/ASK désactivés production)
- Mis à jour `limagrain/02-stockage/palettes-vides.md` (article "PILE DE 10 PALETTES", emplacement picking dédié pour réappro auto, WfAction bouton, 2 piles par îlot)
- Mis à jour `limagrain/03-picking/stations-picking.md` (mode esclave abandonné → avertissement simple, job transverse d'assignation tâches, modes via vassist avec séquence/priorité, paramètres SmartUI, 2 piles/îlot)
- Mis à jour `limagrain/08-transverse/questions-ouvertes.md` (+10 questions : TRF sans AGV, position étiquette, ROC, fournisseurs à la volée, ExceedPercentageAllowed, imprimantes ZPL, surplus hors tolérance, poids variable, erreurs API SAP)
- Mis à jour `limagrain/glossaire-limagrain.md` (+5 termes : DESADV, ORDRSP, vassist, WfAction, ZPL)
**Cross-refs** : Liens croisés palettes-vides ↔ stations-picking, reception-retour → stations-picking, reception-fournisseur → controle-qualite-reception
**Questions** : 10 nouvelles questions ouvertes centralisées dans `limagrain/08-transverse/questions-ouvertes.md`
## [2026-05-05] session-004
- **Fichier** : `Expédition - LIMAGRAIN - DEV - Confluence.md`
**Type** : Export page Confluence (ateliers DEV expédition 2026)
**Actions** :
- Mis à jour `limagrain/04-outbound/shipping-orders.md` (5 types OS avec destination, FIFO 24h confirmé, pas de FEFO, économie mouvement prioritaire, custom défrag détaillé, conso OF avec AllowAssignStockExcess et strat mono-ref, messagerie carton avec emplacements par transporteur)
- Mis à jour `limagrain/04-outbound/flux-expedition.md` (réécriture complète : 12 étapes au lieu de 8, étiqueteuse automatique détaillée avec CstAtt/PLC height type/multi-étiquettes/pannes, cadencement des tâches, recertification en 11 étapes avec 3 mini-customs, messagerie carton avec Pick&Pack vs custom, consommation OF Production détaillée, gestion litiges sac endommagé, 3 modes opératoires Full AGV/Mixte/Full TRF)
- Mis à jour `limagrain/04-outbound/consolidation-chargement.md` (QUAI_TEMPORAIRE, assignation détaillée, messagerie carton emplacement par transporteur, problème dépose AGV sur image de quai, confirmation prise/dépose AGV)
- Mis à jour `limagrain/04-outbound/flux-erp-outbound.md` (MOV annulé, LOC détaillé toutes les 5 min avec structure JSON, synthèse communications ERP outbound)
- Mis à jour `limagrain/03-picking/picking-combinatoire.md` (gerbabilité/stack via StackerCrane_SortTasks_PR, algorithme répartition TP, verrou HORS TOLERANCE détaillé, arrivée palettes 3 TP, MOV annulé, filmage CstData)
- Mis à jour `limagrain/03-picking/stations-picking.md` (cross-ref flux expédition, picking WS vs RF, contrainte Big-Bag)
- Mis à jour `limagrain/06-erp-interface/messages-reference.md` (MOV annulé, LOC détaillé avec fréquence/structure/flag client)
- Mis à jour `limagrain/08-transverse/questions-ouvertes.md` (+11 questions expédition, 2 fermées, 9 points tranchés depuis ateliers DEV)
- Mis à jour `limagrain/glossaire-limagrain.md` (+9 termes : QUAI_TEMPORAIRE, QUAI_RECERTIF, CstData, STOP, isCritical, isRequired, AllowAssignStockExcess, OnStockAdjust, StackerCrane_SortTasks_PR)
**Cross-refs** : Liens croisés shipping-orders ↔ flux-expedition, flux-expedition → stations-picking, flux-expedition → consolidation-chargement, picking-combinatoire → flux-erp-outbound, stations-picking → flux-expedition, consolidation-chargement → AGV
**Questions** : 11 nouvelles questions ouvertes, 2 anciennes fermées, 9 points tranchés — centralisés dans `limagrain/08-transverse/questions-ouvertes.md`
## [2026-05-06] session-005
- **Fichier** : `CR CONSOLIDES REU ERP LIMAGRAIN V1 - CR.md`
**Type** : CR consolidé ateliers interfaçage ERP (7 ateliers, janv.→fév. 2026)
**Actions** :
- Mis à jour `limagrain/06-erp-interface/messages-reference.md` (refonte tableau : séparation entrants/sortants, ajout statuts, détail STV/STR/COR/COF/WSC/STC, flux supprimés consolidés, diagrammes flux mis à jour)
- Mis à jour `limagrain/06-erp-interface/donnees-principales.md` (champs non utilisés ITM, conversions, types supports, Z-Bags)
- Mis à jour `limagrain/06-erp-interface/mapping-erp-wms.md` (section STR détaillée : règles acceptation, interaction GNA, monitoring)
- Mis à jour `limagrain/01-inbound/flux-erp-inbound.md` (ASN 1 par palette + attributs logistiques, ROR InboundType + tolérances + SingleReceipt, REF clôture manuelle + contrainte rangement, ROF rôle + reliquats)
- Mis à jour `limagrain/04-outbound/shipping-orders.md` (classifications OutboundClassCode, paramètres ERP, ruptures production, quai recertification)
- Mis à jour `limagrain/04-outbound/flux-erp-outbound.md` (SOF phase 2 + statuts + contenu, LOF structure conteneurs IsSlave, PCK remplacé)
- Mis à jour `limagrain/08-transverse/questions-ouvertes.md` (+13 questions ERP consolidées)
- Mis à jour `limagrain/glossaire-limagrain.md` (+13 termes : COF, SSCC, GS1, CPI, Z-Bag, SingleReceipt, AutoReleaseDate, TransactionalLineList, CompleteSorList, ERPReasonCode, OutboundClassCode, IsSlave, QUAI_RECERTIFICATION)
**Cross-refs** : messages-reference → loc-message-periodique, messages-reference → mapping-erp-wms, flux-erp-inbound → flux-erp-outbound
**Questions** : 13 nouvelles questions ERP ajoutées dans `limagrain/08-transverse/questions-ouvertes.md`
- **Fichier** : `LOC - Etat des lieux V2.md`
**Type** : Spécification technique complète (réunion 30/04/2026)
**Action** : Créé `limagrain/06-erp-interface/loc-message-periodique.md` (spec complète : format JSON, 6 codes ACTION détaillés, zones VLPLA/NLPLA, désactivation STV+STC, fork WSC, transactions sources, picking/transferts, assignation client, retours compléments, 9 points ouverts)
**Cross-refs** : Lien depuis `limagrain/06-erp-interface/messages-reference.md`, lien depuis `limagrain/04-outbound/flux-erp-outbound.md`
**Questions** : 9 points ouverts LOC intégrés (code action assignation, zones, effets de bord STV/STC, horodatage)
- **Fichier** : `Filmage.md`
**Type** : Note courte (liste programmes)
**Action** : Mis à jour `limagrain/04-outbound/flux-expedition.md` (ajout tableau 8 programmes filmage A→H)
**Cross-refs** : aucune
**Questions** : Question ouverte "Programme de filmage exact" fermée dans `limagrain/08-transverse/questions-ouvertes.md`
- **Fichier** : `Liste de contacts.md`
**Type** : Annuaire projet
**Action** : Créé `limagrain/07-admin/contacts-projet.md` (Limagrain 12 pers., externes 2, Delaware 1, Still 3, Mecalux 21)
**Cross-refs** : aucune
**Questions** : aucune
## [2026-05-06] session-006
- **Fichier** : `LIM-62_gestion-camions.md`
**Type** : Export ticket Jira (LIM-62) avec commentaires de revue de code
**Action** : Créé `limagrain/01-inbound/gestion-camions.md` (arrivée camion, annonce, assignation quai, tableau occupation, contrôle classes OE, implémentation AD customs, revue de code validée)
**Cross-refs** : Lien ajouté depuis `limagrain/01-inbound/reception-fournisseur.md`, lien depuis `limagrain/01-inbound/_index.md`
**Questions** : "Faut-il rendre la plaque obligatoire ?" → ajouté dans `limagrain/08-transverse/questions-ouvertes.md`
- **Fichier** : `LIM-63_64_65.md`
**Type** : Export Jira consolidé (3 tickets : LIM-63, LIM-64, LIM-65)
**Action** : Intégré dans `limagrain/01-inbound/gestion-camions.md` (affichage chauffeur WS, workflow TRF 7 écrans déclaration image de quai, étiquette support A5 paysage, palettes virtuelles PALETTE_US séquence 8xxx, capacité poumon 26 emplacements, double-check disponibilité)
**Cross-refs** : Liens vers LIM-14 (séquences supports), vers reception-fournisseur.md, vers consolidation-chargement.md
**Questions** : aucune nouvelle (questions existantes complétées)
## [2026-05-12] session-007
- **Fichier** : `LIM-66_Passage_PIE.md`
**Type** : Ticket Jira (LIM-66, en revue de code)
**Action** : Mis à jour `limagrain/01-inbound/controle-qualite-reception.md` (verrous HORS TOLERANCE / ECART RETOUR avec comportement post-PIE, mise à jour CstAtt01 poids unitaire mesuré avec formule, priorité CstAtt01 sur poids ITM, tableau verrous par flux détaillé)
**Cross-refs** : Lien LIM-66 dans les références
**Questions** : aucune nouvelle
- **Fichier** : `LIM-67_Postes_Travail_Reception.md`
**Type** : Ticket Jira (LIM-67, en attente CDP)
**Action** : Mis à jour `limagrain/01-inbound/reception-fournisseur.md` (réécriture complète section 5 "Traitement au poste de travail" : menu principal 5 actions, confirmation Big Bag CstAtt02, anoxie CstAtt03, filmage CstAtt05 via paramètre FILMAGES, vérification fermeture réception CstAtt08/CstAtt10, tableau récap CstAtt support)
**Cross-refs** : Lien vers etiquette-rfid.md (LIM-68), question filmage fermée
**Questions** : question "Programme de filmage" fermée dans reception-fournisseur.md (défini par LIM-67)
- **Fichier** : `LIM-68_Etiquette_RFID.md`
**Type** : Ticket Jira (LIM-68, attente déploiement)
**Action** : Créé `limagrain/01-inbound/etiquette-rfid.md` (format A5, 12 champs étiquette, QR Code GS1 avec 5 AI, encodage RFID via commandes ZPL détaillées)
**Cross-refs** : Lien depuis reception-fournisseur.md (étapes a et menu "Imprimer étiquette")
**Questions** : aucune nouvelle
## [2026-05-12] session-008
- **Fichier** : `LIM-69 - LOT1.3 Modes de travail des PK.md`
**Type** : Ticket Jira (LIM-69, LOT 1.3)
**Action** : Mis à jour `limagrain/03-picking/stations-picking.md` (réécriture section "Modes de fonctionnement" → "Modes de travail" : vassist manager config modes/priorité, paramètres MODES_PKxx/PK_ADJACENT, mode tâche automatique, avertissement poste adjacent, fermeture poste. Renvoi job vers page dédiée)
**Cross-refs** : Lien vers job-assignation-pk.md (LIM-70)
**Questions** : aucune nouvelle
- **Fichier** : `LIM-70 LOT1.3 [AGV][JOB] MEGA JOB - assignation d'ordre par priorité de process par PK.md`
**Type** : Ticket Jira (LIM-70, LOT 1.3)
**Action** : Créé `limagrain/03-picking/job-assignation-pk.md` (Mega Job chef d'orchestre : éligibilité PK 4 conditions, lecture MODES_PKxx, exécution sous-WF par priorité, gestion Big-Bag PK_BIGBAG, sous-WF LIM-74/LIM-75)
**Cross-refs** : Lien depuis stations-picking.md, lien vers LIM-74/LIM-75
**Questions** : 3 questions (fréquence Mega Job, sous-WF regroupement/échantillonnage, interaction PK_BIGBAG et modes) → ajoutées dans `limagrain/08-transverse/questions-ouvertes.md`
- **Fichier** : `LIM-71 LOT1.2 RECEPTION PRODUCTION AGV Job de création des tâches images de quai ASRS.md`
**Type** : Ticket Jira (LIM-71, LOT 1.2)
**Action** : Créé `limagrain/05-agv/job-reception-production.md` (job périodique 30s, éligibilité support : séquence 8000*, CstAtt04="ASN", CstAtt06 vide, pas de tâche active, double sécurité anti-doublon, stratégie rangement Est/Ouest, redirection PIE saturé, paramètre DESTINATION_PRODUCTION)
**Cross-refs** : Lien depuis 05-agv/_index.md, liens vers LIM-64/LIM-66, lien vers job-assignation-pk.md
**Questions** : 2 questions (redirection multi-PIE config EasyS, CstAtt06 encore nécessaire) → ajoutées dans `limagrain/08-transverse/questions-ouvertes.md`
- **Fichier** : `LIM-72 LOT1.3 [RETOUR] Flux complet PK.md`
**Type** : Ticket Jira (LIM-72, LOT 1.3)
**Action** : Mis à jour `limagrain/01-inbound/reception-retour.md` (process complet 8 étapes, API SAP détaillée : payload POST /api/v1/lot/verify + réponse EV_RETURN/ET_BATCH/EV_DEPLOY, séquence d'échange WMS↔SAP, écran attente avec refresh 5s/timeout 1min/5 tentatives, choix article multi-résultat, déclaration PK en 9 étapes avec comparatif LIM-67, statut stock modifiable, tolérance illimitée, paramètres SAP_LOT_VERIFY_*)
**Cross-refs** : Liens vers LIM-64/66/67/68/70, lien vers donnees-principales.md, lien vers stations-picking.md
**Questions** : 4 nouvelles questions (URL SAP, EV_DEPLOY, token SAP, product code manquant), 1 fermée (format API SAP) → `limagrain/08-transverse/questions-ouvertes.md`
## [2026-05-12] session-009
- **Fichier** : `LIM-73 - LOT1.3 [RECEPTION] Fermetures, REF et gestion retours.md`
**Type** : Ticket Jira (LIM-73, LOT 1.3)
**Actions** :
- Mis à jour `limagrain/01-inbound/reception-fournisseur.md` (réécriture complète section clôture : AutoCloseReception=true, conditions auto-close CstAtt08/CstAtt10 WS vs vue, Reception_Close_PR_V2 partie B tolérance par ligne + CstAtt01 OE hors tolérance, contenu REF custom zone stockage + "NON RANGEE", clôture OE tableau 3 cas, bouton restreint non-opérateur, impact LOC via LIM-76)
- Mis à jour `limagrain/01-inbound/reception-retour.md` (ajout section complète clôture retour : REF conditionné rangement ASRS, CstAtt11 support, CstAtt01 réception statut "Clôture en cours" jaune, Reception_Close_PR_V2 partie A event replay, cas palette refusée PIE, récap 5 CstAtt clôture)
- Mis à jour `limagrain/08-transverse/questions-ouvertes.md` (+3 questions : palette refusée PIE non supprimée, WF clôture OE à modifier, LOC custom LIM-76)
- Mis à jour `limagrain/glossaire-limagrain.md` (+9 termes : CstAtt11 support, CstAtt01 réception, CstAtt01 OE, AutoCloseReception, AutoCloseInboundOrder, Reception_Close_PR_V2, NON RANGEE, Mini Job)
**Cross-refs** : reception-fournisseur ↔ reception-retour (clôture), reception-retour → LIM-76
**Questions** : 3 nouvelles questions (palette refusée PIE, WF clôture OE, LOC custom LIM-76)
- **Fichier** : `LIM-74 LOT1.3 [AGV][JOB] MINI JOB - images de quai poste de travail (PK).md`
**Type** : Ticket Jira (LIM-74, LOT 1.3)
**Action** : Créé `limagrain/05-agv/job-reception-pk.md` (Mini Job images de quai → PK : recherche réception éligible FIFO, filtre big-bag CstAtt01 + PK_BIGBAG, assignation CstAtt06 = code PK sur tous supports, création tâches "en attente" vers PK, paramètre PK_BIGBAG)
- Mis à jour `limagrain/03-picking/job-assignation-pk.md` (correction tableau sous-WF : LIM-74 = réception PK, LIM-75 = à écrire)
- Mis à jour `limagrain/05-agv/_index.md` (ajout lien job-reception-pk.md)
- Mis à jour `limagrain/README.md` (ajout entrée job-reception-pk.md)
- Mis à jour `_index.md` racine (ajout entrée MCP discovery, compteur 32 pages)
**Cross-refs** : Lien depuis 05-agv/_index.md, lien vers job-assignation-pk.md (Mega Job), lien vers job-reception-production.md
**Questions** : aucune
- **Fichier** : `LIM-75 LOT1.2 [AGV][JOB] MINI JOB - PS poste de travail (PK).md`
**Type** : Ticket Jira (LIM-75, LOT 1.2)
**Action** : Aucune — fichier quasi vide ("Tâche à écrire"), archivé sans intégration
**Cross-refs** : aucune
**Questions** : aucune
## [2026-05-12] session-010
- **Fichier** : `LIM-76 LOT1.2 [GNA] Message LOC.md`
**Type** : Ticket Jira (LIM-76, LOT 1.2 — spécification technique complète + 25 cas de tests)
**Action** : Mis à jour `limagrain/06-erp-interface/loc-message-periodique.md` (refonte complète : architecture technique GNA/BOO détaillée, ACTION=P confirmé avec VBELN/POSNR, IV_LGNUM corrigé WF02, format JSON finalisé 12 champs, règles de remplissage par action, 7 transactions WMS sources, zones SAP ASRS1-4/ASRS34/PICKING/QUAI avec table de correspondance, contraintes de longueur, 18 critères d'acceptation, 25+ cas de tests structurés)
**Cross-refs** : Lien vers gna-sap-cpi.md (transport), lien depuis messages-reference.md (section LOC mise à jour)
**Questions** : 3 points ouverts (palette chargée avant cycle LOC, HU multi-lignes CT-112, transactions supplémentaires STK.SCR) + 2 anciennes fermées (LOC custom LIM-76, STV création stock) → `limagrain/08-transverse/questions-ouvertes.md`
- **Fichier** : `LIM-89 GNA Mise en place de la communication API EasyWMS SAP CPI.md`
**Type** : Ticket Jira (LIM-89 — spécification intégration middleware)
**Action** : Créé `limagrain/06-erp-interface/gna-sap-cpi.md` (OAuth 2.0 client_credentials avec cache token disque, endpoint unique /http/ATHInboundMessage, table correspondance MessageType→MessageSAP 5 codes ATH, détermination conditionnelle REF via CstAtt20/InboundOrderType dans REF01Observer, retry backoff exponentiel 2-4-8-16s, 6 clés config CPI_*, 3 fichiers impactés, 12 cas de tests)
**Cross-refs** : Lien depuis loc-message-periodique.md, lien depuis messages-reference.md, lien depuis _index.md section ERP
**Questions** : 2 nouvelles (file d'attente persistante après 4 retries, chiffrement secret OAuth) → `limagrain/08-transverse/questions-ouvertes.md`
## [2026-05-12] session-011
- **Fichier** : `LIM-80 LOT2.1 2 Mini Job Assignation des postes PK aux commandes.md`
**Type** : Ticket Jira (LIM-80, LOT 2.1)
**Action** : Mis à jour `limagrain/03-picking/job-assignation-pk.md` (ajout sous-WF assignation commandes : éligibilité PK 4 critères, commandes Messagerie prioritaires avec affinité transporteur/PK via PK_TRANSPORTEUR_MESSAGERIE, commandes standard par tournée/numéro d'arrêt, diagramme Mermaid)
**Cross-refs** : Lien LIM-80 dans tableau sous-WF et références
**Questions** : aucune nouvelle
- **Fichier** : `LIM-82 LOT2.2 [PICKING] Ordonnancement des tâches de picking PS PK.md`
**Type** : Ticket Jira (LIM-82, LOT 2.2)
**Action** : Mis à jour `limagrain/03-picking/picking-combinatoire.md` (ajout section ordonnancement PS→PK : picking négatif prioritaire 1 palette table centre, picking classique 2 palettes tables latérales, SSCC/RFID nouvelle palette après picking négatif, cadencement buffers ES_X, cas d'exemple 10 tâches, lien séquençage TK→PS)
**Cross-refs** : Lien vers sequencage-tk-ps.md
**Questions** : aucune nouvelle
- **Fichier** : `LIM-84 LOT2.2 [PICKING] Séquençage des tâches de picking TK PS.md`
**Type** : Ticket Jira (LIM-84, LOT 2.2)
**Action** : Créé `limagrain/03-picking/sequencage-tk-ps.md` (4 solutions envisagées, solution 4 retenue : événementielle TaskCreatedEvent + OutboundOrderReleasedEvent, verrouillage OS.CstAtt pour blocage stacker_crane, algorithme séquençage picking négatif prioritaire, capacité buffer MAX_NB_BUFFER_PK=3, lien LIM-61)
**Cross-refs** : Lien depuis picking-combinatoire.md, lien depuis _index.md picking, ajout dans README.md et _index.md racine (34 pages)
**Questions** : 2 nouvelles (erreur process → OS bloqué CstAtt=false, contention événements multi-OS) → `limagrain/08-transverse/questions-ouvertes.md`
## [2026-05-12] session-012
- **Fichier** : `LIM-85 LOT2.1 Configuration stratégies defragmentation du stock client par tournée.md`
**Type** : Ticket Jira (LIM-85, LOT 2.1 — note courte, ticket chapeau)
**Action** : Aucune page dédiée — contenu intégré dans `limagrain/02-stockage/defragmentation.md` via LIM-87
**Cross-refs** : aucune
**Questions** : aucune
- **Fichier** : `LIM-87 LOT2.1 [TOURNÉES] Défragmentation client - quai non assigné ATTENTE_CLIENT CT-13.md`
**Type** : Ticket Jira (LIM-87, LOT 2.1 — spécification technique complète + 16 cas de tests)
**Action** : Mis à jour `limagrain/02-stockage/defragmentation.md` (refonte : ajout contexte problème modes standard, custom défrag client par tournée quand quai non assigné, mécanisme filtre éligibilité tout-ou-rien au niveau RUT, règle d'éligibilité pseudocode, ordonnancement par STOP inversé dans canal, MAX_DEFRAG_ATTEMPT, 16 cas de tests nominaux/limites/dégradés)
**Cross-refs** : Lien vers sequencage-shipping-stop.md, lien depuis flux-expedition.md (étape 4)
**Questions** : 2 nouvelles (rupture stock CT-13 option A/B, MAX_DEFRAG_ATTEMPT scope) → `limagrain/08-transverse/questions-ouvertes.md`
- **Fichier** : `LIM-88 LOT2.1 [TOURNÉES] Séquençage des tâches de shipping par STOP - quai assigné.md`
**Type** : Ticket Jira (LIM-88, LOT 2.1 — spécification technique complète + 15 cas de tests)
**Action** : Créé `limagrain/04-outbound/sequencage-shipping-stop.md` (custom complémentaire à LIM-87 : override WF tri stacker crane multi-TK pattern Bardinet, règle STOP max→STOP 1 avec blocage cascade, retour PF systématique vers ASRS crossdock OFF, gestion stock reassign, 15 cas de tests nominaux/limites/multi-tournées/dégradés)
**Cross-refs** : Lien depuis defragmentation.md, lien depuis flux-expedition.md (étape 4), lien depuis _index.md outbound, ajout dans README.md et _index.md racine (35 pages)
**Questions** : 2 nouvelles (retour PF rangement standard à confirmer en recette CT-08, bascule quai CT-13) → `limagrain/08-transverse/questions-ouvertes.md`
## [2026-05-12] session-013
- **Fichier** : `REU PICKING SEQUENCAGE 11-05-2026 - Analyse comparative notes + AF + devops.md`
**Type** : CR réunion + analyse comparative (3 sources : DevOps #64854, AF §6.4.8, réunion 11/05/2026)
**Actions** :
- Mis à jour `limagrain/03-picking/sequencage-tk-ps.md` (ajout section arbitrage contradictions, changelog V1.1, décisions tranchées)
- Mis à jour `limagrain/03-picking/picking-combinatoire.md` (TC supprimé, picking négatif 2 conditions cumulatives 55% + 7 kg, pro rata Bag/pal, poids max 1 250 kg, questions fermées)
**Cross-refs** : picking-combinatoire → sequencage-tk-ps (arbitrage)
**Questions** : 2 fermées dans picking-combinatoire.md (process sans picking négatif, traitement commercial). 1 fermée dans questions-ouvertes.md (architecture picking V1.5/V3.0)
- **Fichier** : `Logique combinatoire picking - TK vers PS - V1.1.md`
**Type** : Spécification technique algorithme (V1.1, 11/05/2026)
**Action** : Refonte complète `limagrain/03-picking/sequencage-tk-ps.md` (algo complet : process principal, contraintes amont C1/C2, 5 critères de tri, écriture séquences Line.CstAtt avec ex-aequo, détermination picking négatif, cas particuliers recalcul/relance, paramètres WMS V1.1, points non traités)
**Cross-refs** : Lien vers placement-ps-pk.md (algo aval), lien depuis picking-combinatoire.md
**Questions** : aucune nouvelle
- **Fichier** : `Logique combinatoire picking - PS vers PK - V1.0.md`
**Type** : Spécification technique algorithme (V1.0, 27/04/2026)
**Action** : Créé `limagrain/03-picking/placement-ps-pk.md` (algo choix de table : contrainte adjacence 3 tables, picking négatif 2 tables, picking direct adjacence PF, ping-pong, recentrage AGV, buffers ES MAX_PRELOAD_PAR_PK, évacuation prioritaire, palettes multi-commandes, priorité inter-PK via MODES_PKxx)
**Cross-refs** : Lien depuis sequencage-tk-ps.md, lien depuis picking-combinatoire.md, lien depuis _index.md picking, ajout dans README.md et _index.md racine (36 pages)
**Questions** : aucune
## [2026-05-12] session-014
- **Fichier** : `CR technique - iGO STILL - fonctionnement et flux API + correspondance avec le module AGV EasyWMS Opus 4.7 v1.md`
**Type** : CR technique / analyse d'intégration (2026-04-28, sources : PACS 2.3 spec, iGO easy spec, IT requirements, datasheet EXV, FAQ STILL)
**Actions** :
- Créé `limagrain/05-agv/still-igo-integration.md` (page majeure : vue d'ensemble iGO/PACS/E'tricc, stack technique MyMA, véhicule EXV CB iGo, modèle 8 ressources API, inventaire 22+ endpoints REST, cycle de vie Transport 14 états, mapping complet EasyWMS↔iGO concepts/champs/états/erreurs/verbes, architecture cible 4 composants Gateway+Pool IIS C#, pompe sortante OUTPUTQUEUE→API, webhook receiver callbacks→AGE/AGS, pattern de boot, logique annulation, comparaison Gateways historiques Galileo/Rocla, workflows EasyWMS inchangés, FAQ STILL 11 réponses contractuelles, points encore ouverts, capacités nouvelles suspend/resume/pose/battery)
- Créé `limagrain/05-agv/agv-stations-routes.md` (mapping topologique EasyWMS↔iGO : Station/Location/Group/Vehicle, configuration MyMA vs EasyS, décision tardive Groups, reproduction CanPick/CanDrop, gestion verrous)
- Mis à jour `limagrain/05-agv/_index.md` (diagramme Mermaid flux AGV complété, note architecture communication)
- Mis à jour `limagrain/08-transverse/questions-ouvertes.md` (1 fermée : "Interface AGV document à intégrer", +6 nouvelles : fréquence vehicle/event, customMetaData taille/ré-émission, Location API GET only, Pallet Shuttle iGO, multi-warehouse)
- Mis à jour `limagrain/glossaire-limagrain.md` (+18 termes : iGO easy, PACS, E'tricc, MyMA, EXV CB iGo, Transport, Load, LoadType, Location, Group, transportHostId, X-API-Key, Gateway iGO, AGV_OUTPUTQUEUE, AGV_INPUTQUEUE, AGV_EAG, AGV_AGE, AGV_AGS)
- Mis à jour `_index.md` racine (ajout 2 entrées MCP discovery, compteur 39 pages)
**Cross-refs** : still-igo-integration ↔ agv-stations-routes, _index.md AGV → still-igo-integration, questions-ouvertes → still-igo-integration + agv-stations-routes
**Questions** : 6 nouvelles questions ouvertes AGV/iGO centralisées dans `limagrain/08-transverse/questions-ouvertes.md`
## [2026-05-13] session-015
- **Fichier** : `wiki-update-poids-PIE-tolerance.md`
**Type** : Note de mise à jour wiki (validation client Justine BEUTIN / Olivier, mai 2026)
**Action** : Mis à jour `limagrain/01-inbound/controle-qualite-reception.md` (7 modifications : scope priorité CstAtt01 élargi à tous les calculs PIE, ajout tableau poids de référence pour seuil tolérance avec conséquence passages successifs, correction condition blocage mono-ref vers "poids unitaire de référence", correction multi-ref avec précision CstAtt01/ITM par ligne, ajout point d'attention recalibrage, question tolérance fermée, historique mis à jour)
**Cross-refs** : aucune nouvelle
**Questions** : 1 fermée ("Valeurs exactes des tolérances par type article" → seuil dynamique CstAtt01 > ITM, validé client)
## [2026-05-13] session-016
- **Fichier** : `recap_session_LIM-72_13-05-2026.md`
**Type** : Récap/état des lieux technique (session analyse v2 LIM-72, sources : Jira LIM-72/64/14, doc SAP-CPI v1.0, mails avril 2026)
**Actions** :
- Mis à jour `limagrain/01-inbound/reception-retour.md` (correction API : endpoint CPI unique + MessageType ATH214, auth OAuth 2.0 détaillée, payload req/resp avec types CHAR, mapping inversé CHARG/MATNR documenté, séquence d'échange via CPI, état du dev LIM-72, table CstAtt clôture complétée, 6 questions ouvertes + points d'attention)
- Mis à jour `limagrain/06-erp-interface/gna-sap-cpi.md` (cartographie complète 12 interfaces Athenzat ATH002→ATH202, URLs environnement TEST, note ATH214 hors GNA)
- Créé `limagrain/07-admin/ad-customs.md` (table CstAtt Container 1-11 depuis LIM-14, proposition CstAtt12 code OE, CstAtt Réception/OE/Stock/OS)
- Mis à jour `limagrain/08-transverse/questions-ouvertes.md` (2 fermées : URL API + token SAP ; +6 nouvelles : A1 BLOQUANT champs ET_BATCH, A2 EV_DEPLOY/ZDEPLOY, A3 délai ATH214→ITM, A4 lots déjà connus, B1 étiquette retour, B2 flux rejet PIE ; +1 point suspendu : CstAtt12 OE)
- Mis à jour `limagrain/glossaire-limagrain.md` (+19 termes : ATH002/103A/108/103B/102BOM/111/302/214/215/217/201/202, IV_LGNUM, IV_BATCH_OFF, IV_RETURN, MATNR, CHARG, ItemAlias, CstAtt12)
- Corrigé fichier tronqué `reception-retour.md` (table CstAtt clôture) et `questions-ouvertes.md` (section exclusions)
**Cross-refs** : reception-retour → gna-sap-cpi (architecture CPI), gna-sap-cpi → reception-retour (ATH214 hors GNA), ad-customs → reception-retour + reception-fournisseur + donnees-principales + sequencage-tk-ps, questions-ouvertes → reception-retour + controle-qualite-reception + ad-customs
**Questions** : 6 nouvelles questions (A1-A4 techniques SAP, B1-B2 fonctionnelles client) + 1 point suspendu (CstAtt12), 2 anciennes fermées (URL API, token SAP)
wiki_old_13-05-2026/glossary.md
+968
View File
@@ -0,0 +1,968 @@
---
title: "Glossary — EasyWMS / Mecalux"
type: glossary
sources:
- wiki/concepts/container.md
- wiki/concepts/location.md
- wiki/concepts/stock.md
- wiki/concepts/task.md
- wiki/concepts/reception.md
- wiki/concepts/putaway.md
- wiki/concepts/picking.md
- wiki/concepts/shipping.md
- wiki/concepts/replenishment.md
- wiki/concepts/order-inbound.md
- wiki/concepts/order-outbound.md
- wiki/concepts/product-item.md
- wiki/concepts/erp-interface.md
- wiki/concepts/transactions.md
- wiki/concepts/parameters.md
- wiki/concepts/count.md
- wiki/concepts/cutting-stock.md
- wiki/concepts/labels.md
- wiki/concepts/stations.md
- wiki/architecture/application-dictionary.md
- wiki/architecture/overview.md
- wiki/modules/agv.md
- wiki/modules/pallet-shuttle.md
- wiki/modules/multi-carrier.md
- wiki/modules/slotting.md
- wiki/modules/labor-management.md
- wiki/modules/dom.md
- sources/archives/02_Strategie_assignation_vidage_bacs.md
- sources/archives/04_Gestion_preemballage_precolisage.md
- sources/archives/07_Gestion_gerbabilite.md
- sources/archives/08_Ajouter_image_fiche_article_ITM01.md
- sources/archives/12_Articles_alternatifs.md
- sources/archives/13_Gestion_KIT.md
- sources/archives/14_Processus_inventaire.md
- sources/archives/15_Configuration_ABC.md
- sources/archives/16_Tense_Flow.md
- sources/archives/17_Fonctionnement_routes_tournees.md
- sources/archives/18_ASN_DirectTransfer.md
- sources/archives/19_ASN_Transfer.md
- sources/archives/20_Strategies_reapprovisionnement.md
- sources/archives/21_Validation_ajustements_stock.md
- sources/archives/22_Chargement_camion.md
- sources/archives/23_Declencheurs_impressions.md
- sources/archives/24_Process_assignation_stock.md
- sources/archives/25_Strategie_remplissage_canaux.md
- sources/archives/26_Utilisation_chariots_emplacement.md
- sources/archives/27_Modification_sequence_SSCC.md
- sources/archives/28_Creation_attribut_logistique_sans_capture.md
- sources/archives/29_Split_marchandise_reception.md
- sources/archives/30_Reapprovisionnement_2_sous_entrepots_zone_intermediaire.md
- sources/archives/31_Picking_Manuel.md
- sources/archives/32_Fusion_commandes_Merge.md
- sources/archives/33_Les_poids.md
- sources/archives/menu_rf_easywms.md
- sources/archives/Presentation_GALILEO.md
- sources/archives/Communication_WMS_GALILEO.md
- sources/archives/Communication_Easy_Galileo.md
- sources/archives/Bases_fonctionnement_robotique_EasyWMS.md
- sources/archives/Acronymes_elements_mecaniques.md
- sources/archives/Codes_de_station.md
- sources/archives/Catalogue_TK.md
- sources/archives/Convoyeur_terminologie.md
- sources/archives/Configuration_EasyS.md
- sources/archives/Configuration_SmartUI.md
- sources/archives/Tests_Miniload_Gateway.md
- sources/archives/Comprendre_logs_Gateway.md
- sources/archives/Erreurs_Defauts_GALILEO.md
- sources/archives/Plan_tests_stations.md
- sources/archives/Documents_utiles.md
- sources/archives/Organisation_projet_Robotique.md
- sources/archives/Planning_Installation_Miniload.md
- sources/archives/DTR_configuration_reseau_materiel.md
- sources/archives/Automation_Dashboard.md
- sources/archives/Changer_adresse_WMS_dans_GALILEO.md
related:
- architecture/application-dictionary.md
- architecture/galileo-integration.md
- concepts/erp-interface.md
- concepts/transactions.md
- concepts/parameters.md
- concepts/mechanical-elements.md
last_compiled: "2026-04-17"
---
# 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.
---
## A
**ABC classification**
Item classification by velocity/value. A = high rotation (near pick face), B = medium, C = low. Used by putaway strategies to assign storage zones and by cycle count schedules to set count frequency. See [Product / Item](concepts/product-item.md).
**ABC Inclusive / Exclusive**
Two operating modes of the ABC analysis. **Inclusive** = all items appear in the result even if they have no movement (zero-rotation items classified C). **Exclusive** = only items that had at least one movement in the analysis window are classified; others keep their current class. See [Product / Item](concepts/product-item.md#abc-classification).
**AD (Application Dictionary)**
The metadata layer that defines every executable element in EasyWMS: Commands, Queries, Entities, Views, Dialogs, Events, Workflows, Background Jobs, and Parameters. Approximately 38,765 elements. All UI screens and API calls are backed by AD elements. See [Application Dictionary](architecture/application-dictionary.md).
**AGV (Automated Guided Vehicle)**
Self-navigating forklift or carrier used in automatic warehouses. Communicates with EasyWMS via a 10-phase protocol (phases 00–255). Also transports Pallet Shuttle carts. See [AGV](modules/agv.md).
**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)**
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).
**APS200**
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).
**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).
**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).
**APSFIFO**
APS location type with strict FIFO access mode. Containers enter and exit from the same end; oldest container is always at the front. Distinct from standard APS (LIFO/random access). See [Location](concepts/location.md).
**AS/RS (Automated Storage and Retrieval System)**
Generic term for the automatic warehouse machinery (AGVs, conveyors, lifts, Pallet Shuttles) that moves containers without human operators. EasyWMS coordinates AS/RS movements via AGV tasks and the Fleet Manager.
**ASK (ASN Rejection Confirmation)**
Outbound ERP message. Sent when a pre-notified ASN container is rejected at the WMS (container cancelled, CON.CNL.ASN transaction). Informs ERP that the ASN was not received. See [ERP Interface](concepts/erp-interface.md).
**ASN (Advanced Shipping Notice)**
Inbound ERP message (ASN). Pre-notifies the WMS that specific containers with known contents will arrive. Creates pre-notified containers in the ASN virtual location. Multiple variants (ASN01–ASN08) for different use cases. See [ERP Interface](concepts/erp-interface.md) and [Order Inbound](concepts/order-inbound.md).
**ALLOW_MERGE_DIFFERENT_ACCOUNT**
Parameter of the Multi-Carrier / Deliveries module. When `true`, the `DlvShareDeliveries` merge message accepts outbound orders from **different accounts** in the same merge group. Default is `false`. See [Order Outbound](concepts/order-outbound.md#merge-order-fusion).
**ASO (ASN Open Confirmation)**
Outbound ERP message. Confirms to ERP that an ASN container has been received and put away; includes final location. See [ERP Interface](concepts/erp-interface.md).
**Auto-direct picking**
Automatic warehouse picking mode where the system generates picking tasks without operator intervention; containers move via conveyors and AGVs to the workstation. See [Picking](concepts/picking.md).
---
## B
**Background Job**
A scheduled server-side process running in the Background Jobs IIS pool. Examples: `TryToReplenishProductLocations`, `Delete_StockStatusJob_PR`, `CycleCountJob`, `DefragmentationPlanner`, `SlottingJob`, `AGVService`, `PSService`, `MetricGatherer`. See [Application Dictionary](architecture/application-dictionary.md) and [System Architecture](architecture/overview.md).
**BOM (Bill of Materials)**
List of components required to produce a finished good. Used by the Manufacturing module (RCP01 recipe type). See [Manufacturing](modules/manufacturing.md).
**Buffer station**
Station with a buffer-type location used as a transit zone. Common role for ET (transit) stations and consolidation areas. See [Stations](concepts/stations.md).
---
## C
**Calculated Weight (Poids calculé)**
Container weight field derived as *Theoretical Weight − adjustments* (picks, transfers, etc.). Updated on every stock movement. See [Weights](concepts/weights.md).
**Channel filling strategy**
Putaway strategy variant applied **before** standard location strategies, used for APS, compact, Pallet Shuttle, dynamic, and push-back locations. Has no sequence (first eligible wins) and requires two mandatory criteria: source stations and candidate-container stations. See [Putaway](concepts/putaway.md#channel-filling-strategies).
**Client container (Client LPN)**
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.
**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).
**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).
**Count Profile validation mode**
Setting on the item's count profile that decides whether a count discrepancy needs manual validation. Three values: **Never** (discrepancy applied automatically), **Always** (every discrepancy requires SuperAdmin/Admin validation), **According to tolerance** (validation only if the quantity or value deviation exceeds a configured threshold). See [Stock Adjustment](concepts/stock-adjustment.md) and [Count](concepts/count.md).
**Cobot**
Collaborative robot (robotic arm with suction cup) integrated with HPKS-R for picking tasks. Always paired with a manual operator station to handle exceptions. See [Cobot](modules/cobot.md).
**COF (Count Order Fulfilled)**
Outbound ERP message. Sent when a count order is closed. Contains the final count results and any adjustments made. See [ERP Interface](concepts/erp-interface.md) and [Count](concepts/count.md).
**CommandExecute API**
One of three EasyWMS API families. Used to invoke AD Command elements that change system state: `POST /api/commands/{commandName}`. See [Application Dictionary](architecture/application-dictionary.md).
**CON.* transactions**
Transaction prefix for container-level events. Key types: `CON.RECEP` (reception), `CON.PUT` (putaway), `CON.MOVE` (movement), `CON.SHIP` (shipping), `CON.VASDONE` (VAS completed), `CON.CNL.ASN` (ASN rejection). See [Transactions](concepts/transactions.md).
**Container**
See **LPN**.
**Container lock type**
A named restriction applied to a container that blocks specific operations (picking, replenishment, movement, shipping). Multiple locks can be applied simultaneously unless one is **Exclusive**. Configured in `Masters > Lock Types > Container Lock Types`. See [Container](concepts/container.md) and [Quality Control](concepts/quality-control.md).
**COR (Count Order Request)**
Inbound ERP message. Asks the WMS to create a count order for specified items, locations, or stock. Response: COF. See [ERP Interface](concepts/erp-interface.md).
**COU.* transactions**
Transaction prefix for count lifecycle events: `COU.CST` (count started), `COU.END` (count ended), `COU.CLS` (count closed), `COU.CNL` (count canceled). See [Transactions](concepts/transactions.md).
**Crossdocking (XD)**
Process of routing inbound stock directly to outbound orders without storage. Two types: **opportunity crossdocking** (direct to dock) and **crossdocking to warehouse** (dedicated XD locations). See [Crossdocking](concepts/crossdocking.md).
**CST.STK**
Transaction code for a stock status change (quality lock applied or removed). See [Transactions](concepts/transactions.md).
**Cutting stock**
Items sold or stored by linear measure (length/stretch). Non-consolidating UoM. Requires a cutting profile and special handling throughout reception, picking, shipping, and counting. See [Cutting Stock](concepts/cutting-stock.md).
**CdP (Chef de Projet)**
Project Manager (Mecalux France). Owns the `master` branch and the merges `develop`→`master` at MEP and post-Hypercare. Refuses TLM hand-off if `develop` still exists. See [Git Branch Lifecycle](operations/git-branch-lifecycle.md).
**CST_ (custom prefix)**
Naming prefix mandatory on every custom AD element added or modified by a developer in a custom application. Exceptions: elements visible to the client (e.g. SmartUI parameters) and sub-elements of an already-prefixed top-level element (e.g. activities inside a `CST_` workflow). Verified during code review. See [Code Review Process](operations/code-review-process.md).
---
## D
**Decision station (type 63)**
Automatic conveyor element that routes containers to different destinations based on WMS logic (e.g., putaway vs. rejection, different staging zones). See [Stations](concepts/stations.md).
**Defragmentation**
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).
**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).
**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).
**DlvShareDeliveries**
Multi-Carrier XML message used to **merge** (fuse) several outbound orders into a single preparation group. The merged orders share stock assignment, client containers, and carrier call. Eligibility rules: same account, same site, same route/address, same carrier (the account rule is lifted by `ALLOW_MERGE_DIFFERENT_ACCOUNT`). See [Order Outbound](concepts/order-outbound.md#merge-order-fusion) and [ERP Interface](concepts/erp-interface.md).
**Delivery (Multi-Carrier)**
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).
**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).
**Double validation**
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).
**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).
**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).
**EAN (European Article Number)**
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).
**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-).
**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).
**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).
**ECB (Empty Container Buffer)**
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).
**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).
**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).
**Entity (AD)**
An AD element type representing a core data object. Has CRUD operations via the API (`GET/POST/PUT/DELETE /api/entities/{entityName}`). Examples: Container, Location, Item, ShippingOrder, ReceiptOrder. See [Application Dictionary](architecture/application-dictionary.md).
**Equipment**
In EasyWMS, an equipment is a physical device (forklift, hand truck, conveyor segment, AGV, Pallet Shuttle cart) managed by the system. Equipment has a type, work zone permissions, container type compatibility, and optional PTL controller. See [Warehouse Designer](concepts/warehouse-designer.md).
**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)**
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)**
An AD element type representing a state-transition trigger. Fired when a transaction occurs; can trigger ERP messages (STV, ROF, SOF), SCEM notifications, or start Workflows. See [Application Dictionary](architecture/application-dictionary.md).
**EnterAction / EscapeAction (ProcessContext)**
Workflow variables used to detect a user pressing `Entrée` or `Échap` after a dialog. Code review enforces their use instead of hard-coded "Enter"/"Escape" string constants. See [Code Review Process](operations/code-review-process.md).
---
## F
**Flux tendu**
See **Tense flow**. French term for the warehouse mode where inbound stock is immediately routed to active outbound orders. Configured in EasyS on the target zone; reception kicks off virtual picking on the tense-flow orders. See [Tense Flow](concepts/tense-flow.md).
**FEFO (First Expired, First Out)**
Shipping logic where stock with the earliest expiry date is picked first. Configured as a location storage logic and/or shipping order requirement. See [Location](concepts/location.md).
**FIFO (First In, First Out)**
Shipping/storage logic where the oldest stock (by receipt date) is consumed first. Used in location configuration and compact channel settings. See [Location](concepts/location.md).
**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**
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).
---
## G
**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).
**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).
**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).
**Gerbabilité (Stackability)**
Numeric attribute (0–10) on an item's logistic profile expressing how many containers of that item can be stacked on top of each other. Transmitted via `ITM01` field `<Stack>`. `0` = not stackable; `10` = maximum stacking. Checked by putaway strategies and channel storage logic. See [Product / Item](concepts/product-item.md).
**GNAImportError (Notification_GNAImportError)**
SCEM notification event triggered when an ERP message fails to import (parse error or missing data). Critical event to subscribe to for all deployments. See [Supply Chain Event Management](modules/supply-chain-event.md).
**GS1-128**
Barcode format based on Code 128, augmented with Application Identifiers (AI). Standard format for EasyWMS LPN labels (SSCC) and item labels. See [Labels](concepts/labels.md).
**GTIN (Global Trade Item Number)**
GS1 identifier for a product at a specific packaging level (item, case, pallet). Encoded in AI(02) in GS1-128 barcodes. See [Labels](concepts/labels.md).
---
## H
**HPKS-R**
Mecalux cobot integration protocol. The Cobot module connects robotic picking arms to EasyWMS via the HPKS-R interface. See [Cobot](modules/cobot.md).
**Hypercare**
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).
**IMS (Sistema electrovía invertida)**
Inverted Electric Monorail — floor-based inverted monorail variant of EMS. See [Mechanical Elements](concepts/mechanical-elements.md).
---
## I
**IIS (Internet Information Services)**
Microsoft web server hosting EasyWMS. Requires three application pools: Main (web UI + API), Background Jobs (scheduled tasks), Integration (ERP message processing). See [System Architecture](architecture/overview.md).
**INO.* transactions**
Transaction prefix for receipt order lifecycle: `INO.CREATE` (order created), `INO.OPEN` (order opened), `INO.CLS` (order closed). See [Transactions](concepts/transactions.md).
**IS crossdocking (Is crossdocking strategy)**
A putaway strategy variant. When this flag is active, the strategy routes stock to dedicated crossdocking locations rather than standard storage. See [Crossdocking](concepts/crossdocking.md).
**ITM (Item Master)**
Inbound ERP message. Creates or updates item master data in EasyWMS. Also `ITC` for item catalog. See [ERP Interface](concepts/erp-interface.md).
---
## K
**KIT / Kit assembly**
Process of assembling finished kits from component items. Managed via the Kits module. ERP message `KIT` sends kit structure. Task type: Kit assembly. See [ERP Interface](concepts/erp-interface.md).
**KPI (Key Performance Indicator)**
Performance metrics tracked in the Data Analytics module or displayed on the 3PL Client Portal. Examples: lines picked per hour, receiving accuracy, order cycle time. See [Data Analytics](modules/data-analytics.md) and [3PL Portal](modules/3pl-portal.md).
---
## 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).
**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).
**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).
**LneDIsAlternative**
Field in the `SOF` shipping-order feedback, at line level. `true` if the shipped stock is a substitute of the originally-requested item. Paired with the substitute item code. See [Product / Item](concepts/product-item.md#alternative--substitute-items).
**L&F (Lost & Found)**
Virtual location used to park containers with unknown or unresolvable physical location. Stock in L&F is visible but excluded from normal operations until reconciled. Transaction: `CON.SEND.L&F`. See [Container](concepts/container.md).
**Labor Management (LMS)**
EasyWMS module that measures operator productivity by comparing actual task times to calculated target times (based on layout dimensions and equipment speed). See [Labor Management](modules/labor-management.md).
**LIFO (Last In, First Out)**
Storage access mode for compact channels (Pallet Shuttle, mobile racking). The most recently inserted container is extracted first. See [Pallet Shuttle](modules/pallet-shuttle.md) and [Location](concepts/location.md).
**LMS**
See **Labor Management**.
**Load (truck load)**
A grouping of containers/routes assigned to a specific truck or vehicle. Created from one or more routes. Truck loading task sequence is determined by route stop numbers (reverse delivery order). See [Shipping](concepts/shipping.md).
**Location lock type**
A named restriction applied to a location that blocks specific operations (putaway, picking, replenishment, count, movement). Configured in `Masters > Lock Types > Location Lock Types`. See [Location](concepts/location.md) and [Security](architecture/security.md).
**LOF (Load Order Fulfilled)**
Outbound ERP message. Sent when a truck load is closed (all containers loaded). See [ERP Interface](concepts/erp-interface.md).
**LPN (License Plate Number)**
The fundamental unit of physical storage in EasyWMS. A box, pallet, or any container that holds stock. Identified by a unique code (usually SSCC). Synonymous with "container" in the WMS. The AD entity name is `Container`. See [Container](concepts/container.md).
---
## M
**Manual Picking (`ManualPicking_ByItem_UI`)**
RFT flow where the operator creates the outbound order on the spot by scanning items, then picks them without a pre-existing SOR. Incompatible with 3PL billing (orders without accounts not billed) and with carrier modules (orders without carrier metadata not shippable as parcels). Menu path: *Ordres d'expédition → Picking manuel*. See [Picking](concepts/picking.md).
**Manual movement**
A stock or container relocation performed without generating a task. Eight move types: location↔location, location↔container, container↔container, container+divisions, division↔division, move container, cutting stock, and partitions. See [Manual Movements](concepts/manual-movements.md).
**ME station (Multi-Exit)**
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).
**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).
**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).
**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).
**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).
**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).
**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).
**MECALUX**
Spanish manufacturer and developer of EasyWMS and EasyS. Headquarters in Barcelona. Also manufactures automated warehouse equipment (racks, Pallet Shuttle carts, moviracks).
**MEP (Mise En Production)**
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.
**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).
**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).
**MP station**
Container or equipment used in grouped/automatic picking. Has extra locations (slots) where individual stock units are accumulated before being directed to their destination. See [Stations](concepts/stations.md) and [Picking](concepts/picking.md).
**MS station (Multi-Stock)**
Automatic warehouse station type for multi-reference stock movements. See [Stations](concepts/stations.md).
**MU station (Multi-Unit)**
Automatic warehouse station type handling multiple simultaneous container flows. See [Stations](concepts/stations.md).
**Multi-Carrier Shipping module**
EasyWMS add-on for carrier integration. Manages deliveries (carrier + consignee), packing at packaging stations, tracking numbers, carrier labels, and carrier selection rules. See [Multi-Carrier](modules/multi-carrier.md).
---
## 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).
**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).
**NegativeStock user status**
Special stock status used in the Manufacturing module to represent component stock consumed in production before the finished good is confirmed. See [Manufacturing](modules/manufacturing.md).
**Notification event**
A named event in the SCEM module that users can subscribe to. Associated with a severity (Info/Warning/Error) and a notification group. Examples: AGV errors (group: AGV), stock failure (group: WMS), ERP import error (group: GNA). See [Transactions](concepts/transactions.md) and [Supply Chain Event Management](modules/supply-chain-event.md).
**NAT (Network Address Translation)**
Routing layer set up between the Hyper-V host PC and the dev VM (commutateur InternoNAT). Maps external host ports (8080, 4430, 33890, 15210, 4450) to internal VM ports (80, 443, 3389, 1521, 445) so applicative ports remain free on the host. See [VM Network Routing](operations/vm-network-routing.md).
---
## O
**Order orchestration (DOM)**
The 5-stage engine in the DOM module that assigns sales orders to the optimal fulfillment node: (1) Geographic region, (2) Carrier availability, (3) Stock availability, (4) Node capacity, (5) Business strategies. See [DOM](modules/dom.md).
**OUT.* transactions**
Transaction prefix for shipping order lifecycle: `OUT.CREATE` (order created), `OUT.OPEN` (order released), `OUT.PICK` (picking started), `OUT.PREP` (preparation completed), `OUT.SHIP` (shipped). See [Transactions](concepts/transactions.md).
**Owner**
In 3PL contexts, an entity that owns the inventory stored in the warehouse (a client of the 3PL). Owner extensions enforce data isolation across all master data and orders. See [Account / Owner](concepts/account-owner.md) and [Owner Extensions](modules/owner-extensions.md).
**OutboundLines vs OutboundOrderLines**
Two distinct properties on writing-side queries against shipping orders. Use `OutboundLines` to avoid the "Le nombre de ligne d'ordre d'expédition ne peut pas être négatif" error when a line is cancelled. With kits without assembly: `OutboundLines` returns only the kit; `OutboundOrderOutboundOrderLineDetails` returns all components. See [Code Review Process](operations/code-review-process.md).
---
## P
**Prepackaging (Préemballage / Précolisage)**
Configuration that drives **how** pickers group picked stock into client containers during shipping preparation. The strategy is set at the shipping order type level; the ERP can also supply the package count and type via `SOR02` `<PrpPackagingConfiguration>`. Distinguishes from VAS (which acts after picking). See [Prepackaging](concepts/prepackaging.md).
**Parameter**
A named configuration value that controls a specific WMS behavior. Stored in the AD. Organized at organization level (global) or warehouse level (per-facility). See [Parameters](concepts/parameters.md).
**Partition (PDL partition)**
A sub-division of a picking dedicated location assigned to a specific item and logistic attributes. Used for fine-grained allocation of shared shelf space (drawers, boxes). See [Replenishment](concepts/replenishment.md).
**Partition (count)**
A sub-division of a location for the purpose of counting. Items are assigned to specific physical positions within a location. See [Count](concepts/count.md).
**PDL (Picking Dedicated Location)**
A warehouse location (or partition of a location) permanently assigned to a specific item (and optionally logistic attributes) for first-level picking. PDLs have min/max stock levels and trigger replenishment automatically. See [Replenishment](concepts/replenishment.md).
**Pick and Pack**
Picking mode where the operator picks directly into the final shipping box, eliminating a separate packing step. See [Picking](concepts/picking.md).
**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)**
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)**
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)**
Hardware controller for automated warehouse machinery (conveyors, lifts, sorters). EasyWMS communicates with PLCs for AS/RS coordination.
**PLC Container Type / PLC Height Type**
Two fields configured in EasyS under **PLC Types** that translate WMS container codes and heights into the numeric identifiers the PLC/controller expects. On miniload installations the two types are usually **tied** (container type implies height). Required before GALILEO can route containers. See [Galileo Simulation](operations/galileo-simulation.md).
**Port 3000**
TCP port used by the **EasyWMS Gateway** to listen for GALILEO / EasyS connections. Must be opened in the Windows firewall (e.g. `New-NetFirewallRule -DisplayName "EasyWMS Gateway 3000" -LocalPort 3000 -Protocol TCP -Action Allow`). See [Galileo Simulation](operations/galileo-simulation.md).
**Post-processing (ERP message)**
The mechanism by which EasyWMS transactions trigger outbound ERP messages. A transaction (e.g., `REC.CLS`) is marked as "post-processed" when the associated ERP message (e.g., `ROF`) has been queued for sending. See [ERP Interface](concepts/erp-interface.md) and [Transactions](concepts/transactions.md).
**POS (Point of Sale)**
Terminal at a retail store. In the Store Fulfillment module, POS systems at remote stores send outbound orders to the central warehouse. See [Store Fulfillment](modules/store-fulfillment.md).
**PS (Pallet Shuttle)**
A motorized cart that operates inside compact rack channels (deep-lane), depositing and extracting pallets autonomously. Controlled by the PSService background job via WIFI. See [Pallet Shuttle](modules/pallet-shuttle.md).
**PSService**
Background job that centralizes communication between EasyWMS and all Pallet Shuttle carts via WIFI/tablet. Manages deposit/extraction/compaction commands and battery status. See [Pallet Shuttle](modules/pallet-shuttle.md).
**PTL (Pick To Light / Put To Light)**
Illuminated display devices mounted at picking locations. Guide operators during batch picking: devices light up in assigned colors showing quantity to pick (Pick To Light) or quantity to drop at equipment slot (Put To Light). Requires PTL Service and PTL controller per device group. See [Picking](concepts/picking.md) and [Configuration Guide](operations/configuration-guide.md).
**Put To Light**
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).
---
## 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).
**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).
**QueryExecute API**
One of three EasyWMS API families. Executes LINQ-based queries against Views or Entities: `POST /api/queries/execute`. Supports filtering, sorting, and pagination. See [Application Dictionary](architecture/application-dictionary.md).
---
## R
**RCP01 / RCP02 (Recipe types)**
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).
**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).
**Receipt order**
See **Inbound Order**.
**RECH station (Recharge)**
Pallet Shuttle charging station. PS carts are deposited here to charge their battery. See [Stations](concepts/stations.md).
**Reject route / MP-reject**
A physical route configured in EasyS that ends on a **Manual Exit (TM / MT)** serving as the warehouse's "reject bin" for PIE-level refusals. Used to extract unknown / unmeasured / weight-rejected containers. See [Galileo Simulation](operations/galileo-simulation.md).
**Responsable de projet (Robotics)**
Senior project manager at Mecalux who arbitrates scope and priorities across the chef de chantier, chef de projet IT and responsable électricité during a robotics installation. See [Robotics Project Lifecycle](operations/robotics-project-lifecycle.md).
**Route (GALILEO)**
A physical path between two stations in the TMS (GALILEO / EasyS). Distinct from a WMS logical route: on EasyWMS side, a station is linked to a route via `StationRoutes`. The station + route pair drives capacity semantics: PK/PS routes carry capacity; miniload TK stations carry capacity. See [Stations](concepts/stations.md), [GALILEO Integration](architecture/galileo-integration.md) and [Galileo Simulation](operations/galileo-simulation.md).
**REF (Receipt Error Feedback)**
Outbound ERP message. Sent when a reception error occurs (e.g., ASN quantity mismatch, unknown container). Informs ERP of the discrepancy. See [ERP Interface](concepts/erp-interface.md).
**Relocation percentage**
A putaway strategy configuration value. When an aisle's occupancy exceeds this percentage, the putaway engine stops assigning new containers to that aisle (for that strategy). See [Putaway](concepts/putaway.md).
**Reten (Manuel de retention)**
Project handover/retention manual maintained as Markdown in the project Git repository (`docs/`). Documents every custom modification: process changes go in process chapters (Entries, Exits, Picking…), other custom elements go in end-of-reten tables, custom attributes go in section "1.2 General custom elements". Mandatory deliverable, validated by documentation review. See [Code Review Process](operations/code-review-process.md) and [Development Methodology](operations/development-methodology.md).
**RFT (Radio Frequency Terminal)**
Handheld or vehicle-mounted barcode scanning terminal used by warehouse operators for guided tasks (receiving, picking, putaway, counting). Runs EasyWMS RF application via WIFI.
**ROC (Receipt Order Confirmation)**
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).
**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).
**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).
**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).
**ROU.* / LOAD.* transactions**
Transaction prefix for route and load lifecycle events: `ROU.CREATE`, `ROU.CLS`, `LOAD.CREATE`, `LOAD.CLS`. See [Transactions](concepts/transactions.md).
**RUT (Route Update)**
Inbound ERP message. Creates or updates a shipping route in EasyWMS. See [ERP Interface](concepts/erp-interface.md).
---
## 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).
**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).
**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).
**Search (GALILEO message)**
One of the three GALILEO-initiated message types (the others: **Event** and **End**). A **Search** asks EasyWMS where a specific container should go next (routing decision). Handled by `Galileo_SearchCreatedEventHandler_PR`. The response carries a target station and, optionally, a container update. See [GALILEO Integration](architecture/galileo-integration.md).
**SCR (Stock Contrast Request)**
Inbound ERP message. Requests a stock comparison between ERP and WMS for specified items/locations. WMS responds with `WSC`. See [ERP Interface](concepts/erp-interface.md).
**Shipping order**
See **Outbound Order**.
**SKU (Stock Keeping Unit)**
A unique identifier for an item at a specific packaging level. In EasyWMS, the item code is the primary SKU; aliases can provide additional codes for scanning and ERP integration.
**Slotting module**
EasyWMS add-on that analyzes item rotation data and recommends optimal picking location assignments. Uses a profit formula to calculate the value of moving each item. See [Slotting](modules/slotting.md).
**SGA (Sistema de Gestión de Almacenes)**
Spanish acronym for WMS. Used interchangeably with WMS in Mecalux Spain-originated documentation.
**SmartUI**
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).
**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).
**SOF (Shipping Order Fulfilled)**
Outbound ERP message. Sent when a shipping order is fully shipped. Two variants: `SOF01` (fully fulfilled) and `SOF02` (partially fulfilled / backorder). See [ERP Interface](concepts/erp-interface.md).
**SOR (Shipping Order Request)**
Inbound ERP message. Creates a shipping order in EasyWMS. Two variants: `SOR01` (standard) and `SOR02` (with VAS instructions). See [ERP Interface](concepts/erp-interface.md).
**SRK / SRN / SRO (Supplier Return messages)**
ERP message family for supplier return flows: `SRN` (return notification inbound), `SRO` (return order confirmation outbound), `SRK` (return fulfilled outbound). See [ERP Interface](concepts/erp-interface.md).
**Scale Weight (Poids balance)**
Raw gross weight of a container measured at the **PIE** (Punto de Introducción de Entrada). Updated on PIE pass only. Feeds Theoretical Scale Weight and Real Weight. See [Weights](concepts/weights.md).
**SSCC (Serial Shipping Container Code)**
GS1-standard 18-digit numeric identifier for a logistics unit (LPN). The default LPN code format in EasyWMS. Encoded in GS1-128 barcode as AI(00). See [Labels](concepts/labels.md) and [Container](concepts/container.md).
**STK.* transactions**
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).
**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).
**StockAssignProcess_\* workflows**
Family of workflows making up the stock assignment engine: `AssignOutboundLine_PR`, `AssignOutboundOrderLineDetails_PR`, `GetLockAndUpdateDetail_PR`, `GetAvailableStockForOutboundOrderLineDetails_PR`, `CalculateByAssignmentManufacturingAndKits_PR`, `CalculateEfficiencyMode_PR`, `ValidateStockList_PR`, `CreateAssignments_PR`, `GetStockToAssignForStrategy_PR`. The standard extension hooks (query filters, custom strategies) live here. See [Stock Assignment](concepts/stock-assignment.md).
**STC (Stock Change)**
Outbound ERP message. Sent when a stock quality status changes (lock applied or removed). Transaction: `CST.STK`. See [ERP Interface](concepts/erp-interface.md).
**STR (Stock Status Request)**
Inbound ERP message. ERP requests the WMS to apply or remove a quality lock on stock. Response: STC (at reception close) or immediate STC (for closed receptions). See [ERP Interface](concepts/erp-interface.md).
**STV (Stock Variation)**
Outbound ERP message. Sent when stock quantity changes (adjustment, replenishment, picking, shipping). The primary stock synchronization message. See [ERP Interface](concepts/erp-interface.md).
**Substitute item**
Alternative item that may replace the primary item on an outbound order line when stock is insufficient. Configured on the primary item's master ("Articles de remplacement" table). Enabled per line via `<LneTerms><LneTrmAlternative>true</LneTrmAlternative>`. The shipping profile defines the behaviour (Partiel / Substitution / Tout ou rien). SOF feedback uses `LneDIsAlternative`. See [Product / Item](concepts/product-item.md#alternative--substitute-items).
**Sub-warehouse**
A logical partition of a warehouse with independent stock management rules. Items can have a "sub-warehouse classification" that controls which sub-warehouse they are stored in. Replenishment between sub-warehouses is a distinct strategy type. See [Product / Item](concepts/product-item.md) and [Replenishment](concepts/replenishment.md).
---
## T
**Theoretical Scale Weight (Poids théorique balance)**
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).
**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).
**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).
**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).
**Tense flow (Flux tendu)**
A warehouse configuration where all received stock is immediately directed to active outbound orders via virtual picking, without intermediate storage. Configured on the target zone in EasyS; reception triggers picking on the tense-flow orders. Distinct from opportunity crossdocking: tense flow is zone-driven, not container-driven. See [Tense Flow](concepts/tense-flow.md).
**Tournée (Route / RUT)**
French term for a carrier route. Integrated from a TMS via the `RUT` inbound ERP message (route code, carrier, dock, departure time, stops). Shipping orders reference the route to consolidate truck loading. See [Shipping](concepts/shipping.md#rut-file-tms-driven-routes) and [ERP Interface](concepts/erp-interface.md).
**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)**
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).
**Transaction**
An immutable record of a state change in EasyWMS. Every WMS operation generates one or more transaction records. Transactions drive ERP messages (via post-processing). Transaction codes follow a `PREFIX.ACTION` pattern. See [Transactions](concepts/transactions.md).
**TSK.* transactions**
Transaction prefix for task lifecycle: `TSK.CREATE` (task created), `TSK.ASS` (assigned), `TSK.INI` (started), `TSK.FIN` (finished), `TSK.CNL` (canceled), `TSK.COU` (count task), `TSK.ERR.EXTR` / `TSK.ERR.PUT` (automatic warehouse errors). See [Transactions](concepts/transactions.md).
**TryToReplenishProductLocations**
Background job that automatically triggers replenishment for PDLs below their minimum stock level. Recommended schedule: every 5–15 minutes. See [Replenishment](concepts/replenishment.md).
**TLM (Tierce Maintenance)**
Project life-cycle phase after Hypercare: ownership of the project transfers from the dev team to the **Support team**. Support refuses TLM hand-off if the Git repository still contains a `develop` branch. Support handles urgent fixes via `hotfix` branches off `master`. See [Git Branch Lifecycle](operations/git-branch-lifecycle.md).
**TMA (Tierce Maintenance Applicative)**
Continuous maintenance team that delivers complementary "offers" via `release` branches (one per offer). Must merge `master` → `release` whenever Support delivers a `hotfix`, and merge `release` → `master` after delivering an offer. See [Git Branch Lifecycle](operations/git-branch-lifecycle.md).
**Trigramme projet**
3-letter project prefix used in Jira issue keys (`<TRIGRAMME>-NNN`) and in deployment Git tags (`<TRIGRAMME>-V<N>`, e.g. `LMD-V1`, `SPEN-V3`). See [Deploy Test Application](operations/deploy-test-application.md) and [Deploy Specific Commit](operations/deployment-specific-commit.md).
---
## U
**UoM (Unit of Measure)**
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).
**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).
---
## V
**Variable weight (Poids variable)**
Option on the logistic profile of an item. When enabled, the stock weight must be provided at creation (manual or from ROR via the "Poids moyen" option). `StockAdjust` can modify line weights only for variable-weight items. See [Weights](concepts/weights.md) and [Product / Item](concepts/product-item.md).
**Vidage de bacs (Bin Emptying)**
Picking efficiency mode ("empty first") that, when the last unit of an item is picked, marks the source location as empty so replenishment can start immediately rather than waiting for the next pick cycle. Driven by workflows `StockAssignProcess_CalculateEfficiencyModeToEmpty_PR` and variants. See [Picking](concepts/picking.md#vidage-de-bacs-efficiency-mode).
**VAS (Value Added Services)**
Module for performing additional operations on stock (screen printing, container wrapping, labeling, kitting) within the warehouse. VAS activities are organized in templates with steps. See [VAS](modules/vas.md).
**View (AD)**
An AD element type representing a read-only data projection. Used for all list screens in SmartUI and RF terminal displays. Often joins multiple entities. Examples: `ViewContainers`, `ViewStocks`, `ViewTasksOpen`, `ViewDockStage`. See [Application Dictionary](architecture/application-dictionary.md).
**Voice picking**
Picking mode guided by voice prompts through a headset. Controlled by `VOICE_ENABLED` parameter and requires voice middleware configuration. See [Picking](concepts/picking.md).
**VPN Mecalux (Europe / Europe 4)**
Two SSL VPN gateways used by European delegations (except Gijón) to access the Mecalux network: `vpn-europa@mecalux.com:4443` (Europe) and `vpn-europa4@mecalux.com:443` (Europe 4). See [VM Network Routing](operations/vm-network-routing.md).
---
## W
**Wave**
A batch of shipping orders grouped together for joint picking. All orders in a wave are released simultaneously; operators pick for multiple orders in a single pass through the warehouse. See [Shipping](concepts/shipping.md) and [Picking](concepts/picking.md).
**WMS (Warehouse Management System)**
EasyWMS is Mecalux's WMS product.
**WOF (Work Order Fulfilled)**
Outbound ERP message. Sent when a manufacturing work order is completed (finished good produced). See [ERP Interface](concepts/erp-interface.md).
**Workflow (AD)**
An AD element type representing an orchestrated sequence of Commands, Queries, and sub-Workflows. Examples: `PutawayWorkflow`, `StockAssignmentWorkflow`, `ReplenishmentWorkflow`, `DefragmentationWorkflow`, `CountCloseWorkflow`. See [Application Dictionary](architecture/application-dictionary.md).
**WOR (Work Order Request)**
Inbound ERP message for manufacturing work orders. Triggers the production process in EasyWMS. See [ERP Interface](concepts/erp-interface.md).
**WSC (Warehouse Stock Confirmation)**
Outbound ERP message. Response to SCR (Stock Contrast Request); sends current WMS stock quantities to ERP for reconciliation. See [ERP Interface](concepts/erp-interface.md).
---
## X
**XD**
Abbreviation for crossdocking. Used in strategy names and configuration fields (e.g., "Is XD location", "XD strategy"). See [Crossdocking](concepts/crossdocking.md).
---
## Y
**Yard Management module**
EasyWMS add-on for managing vehicle arrivals and departures. Manages appointments, checkpoints, parking lots, dock assignments, and vehicle check-in/check-out. See [Yard Management](modules/yard-management.md).
---
## Z
**Zone**
A logical grouping of aisles within a warehouse. Two types: **storage zones** (group storage aisles by product type or environment) and **working zones** (group work areas by equipment permissions and process types). See [Location](concepts/location.md) and [Warehouse Designer](concepts/warehouse-designer.md).
**ZAPP / Zscaler APP**
Security agent that conflicts with Hyper-V NAT and breaks VPN connectivity to the Mecalux network. If installed on the developer's physical machine, it must be uninstalled and the machine rebooted; otherwise open a ticket `No Hyper-V NAT connectivity` to `it@mecalux.com`. See [VM Network Routing](operations/vm-network-routing.md).
---
## ERP Message Quick Reference
| Code | Direction | Description |
|------|-----------|-------------|
| ITM / ITC | ERP→WMS | Item / item catalog master |
| OWN | ERP→WMS | Owner master |
| CAR | ERP→WMS | Carrier master |
| ACC | ERP→WMS | Account master |
| SUP | ERP→WMS | Supplier master |
| KIT | ERP→WMS | Kit structure |
| LCK | ERP→WMS | Lock master |
| ROR | ERP→WMS | Receipt order request |
| ASN | ERP→WMS | ASN pre-notification |
| SRN | ERP→WMS | Supplier return notification |
| SOR | ERP→WMS | Shipping order request |
| RUT | ERP→WMS | Route definition |
| WOR | ERP→WMS | Work order (manufacturing) |
| COR | ERP→WMS | Count order request |
| STR | ERP→WMS | Stock status request (quality lock) |
| SCR | ERP→WMS | Stock contrast request |
| CMC | ERP→WMS | Container movement command |
| ROC | WMS→ERP | Receipt order confirmation |
| ROF | WMS→ERP | Receipt order fulfilled |
| ASO / ASK | WMS→ERP | ASN confirmation / ASN rejection |
| SRO / SRK | WMS→ERP | Return confirmation / fulfilled |
| REF | WMS→ERP | Receipt error feedback |
| SOC | WMS→ERP | Shipping order confirmation |
| SOF | WMS→ERP | Shipping order fulfilled |
| LOF | WMS→ERP | Load (truck) fulfilled |
| WOF | WMS→ERP | Work order fulfilled |
| COF | WMS→ERP | Count order fulfilled |
| STV | WMS→ERP | Stock variation (quantity change) |
| STC | WMS→ERP | Stock change (quality status) |
| WSC | WMS→ERP | Warehouse stock confirmation |
---
## Transaction Code Quick Reference
| Prefix | Entity | Examples |
|--------|--------|---------|
| CON.* | Container | RECEP, PUT, MOVE, SHIP, VASDONE, CNL.ASN, SEND.L&F |
| STK.* | Stock | RECEP, MOVE, ADJ, PICK, SHIP, REP, MAN.PRODUCTION |
| CST.STK | Stock status | Quality lock change |
| INO.* | Receipt order | CREATE, OPEN, CLS |
| REC.* | Receipt document | CREATE, OPEN, CLS |
| OUT.* | Shipping order | CREATE, OPEN, PICK, PREP, SHIP |
| ROU.* / LOAD.* | Route / Load | CREATE, CLS |
| TSK.* | Task | CREATE, ASS, INI, FIN, CNL, COU, ERR.EXTR, ERR.PUT |
| COU.* | Count | CST, END, CLS, CNL |
| WOR.* / KOU.* | Work order / Kit | CREATE, FIN, CLS |
Full reference: [Transactions](concepts/transactions.md).
wiki_old_13-05-2026/limagrain/.fuse_hidden000000670000002c
+166
View File
@@ -0,0 +1,166 @@
---
title: "Glossaire Limagrain"
tags: [glossaire, limagrain, référence]
status: draft
last_updated: 2026-05-12
author: Arthur
---
# Glossaire Limagrain
> **Résumé** : termes et acronymes spécifiques au projet Limagrain, complémentaires
> au [glossaire standard EasyWMS](../glossary.md).
| Terme | Signification |
|-------|---------------|
| CstAtt | Custom Attribute — handshake dans le picking combinatoire |
| CR V3.0 | Change Request version 3.0 — architecture 4 jobs picking combinatoire |
| SOR | Shipping Order Request — message ERP entrant, crée un ordre d'expédition |
| RUT | Route — message ERP entrant, définit une tournée transporteur |
| SOF | Shipping Order Fulfilled — message ERP sortant, ordre expédié |
| LOF | Load Order Fulfilled — message ERP sortant, chargement camion terminé |
| ASN | Advanced Shipping Notice — pré-avis de réception avec contenu connu |
| PIE | Station de pesée automatique |
| PDL | Picking Dedicated Location — emplacement dédié picking |
| ASRS | Automatic Storage and Retrieval System — stockage automatique |
| TK | Transstockeur (miniload) |
| TMS | Transport Management System (Galileo chez Mecalux) |
| AD | Application Dictionary — framework métadonnées EasyWMS |
| HU | Handling Unit — palette identifiée par un numéro unique (étiquette RFID) |
| ROR | Reception Order Request — message ERP entrant, crée un ordre de réception |
| ROF | Reception Order Fulfilled — message ERP sortant, ordre de réception clôturé |
| REF | Reception Fulfilled — message ERP sortant, réception individuelle finalisée |
| ITM | Item Master — message ERP entrant, synchronisation des articles/lots |
| STV | Stock Variation — message WMS sortant, notification de variation de stock |
| STR | Stock Request — message ERP entrant, demande changement statut/propriétaire/article |
| STC | Stock Confirmation — message WMS sortant, confirmation changement statut |
| PCK | Passage Conteneur Client — message WMS sortant [CUSTOM], info passage en conteneur client |
| LOC | Location — message WMS sortant [CUSTOM], info emplacement de stockage |
| MOV | Movement — message WMS sortant [CUSTOM], info déplacement stock entre palettes |
| CHG | Change — message ERP entrant [CUSTOM], changement article ou propriétaire |
| ERR | Error — message WMS sortant, erreur d'importation de message |
| MAG01 | Magasin automatique Limagrain — 4 allées TK |
| NIMP15 | Type palette vide — US 100×120 conforme ISPM15 |
| FERT | Produit fini (type article SAP) |
| ZSIZ | Semi-fini calibré (type article SAP) — déclenche ajustement poids au PIE |
| NAV | Navette — convoyeur de transfert entre zones |
| TE | Table d'Entrée — station d'entrée vers l'ASRS |
| TS | Table de Sortie — station de sortie depuis l'ASRS |
| ET | Table intermédiaire (Estación de Transferencia) |
| REAC | Poste de reconditionnement |
| TP | Table de Préparation — emplacement sur un îlot de travail |
| PK | Poste de travail (Picking station) |
| L&F | Lost & Found — emplacement virtuel pour conteneurs perdus |
| GNA | Generic Network Adapter — service communication ERP ↔ EasyWMS |
| SCR | Stock Count Request — message ERP entrant, demande image de stock |
| WSC | Warehouse Stock Confirmation — message WMS sortant, confirmation image de stock |
| COR | Count Order Request — message ERP entrant, demande d'inventaire |
| F9 | Statut de stock « Sacs sales » — applicable au retour client |
| B6 | Statut de stock « Non conforme » — applicable au retour client |
| WF02 | Code site Limagrain dans l'interface ERP |
| PROFIL_STANDARD | Profil logistique articles classiques (code produit + propriétaire + description + destination) |
| PROFIL_PALETTE | Profil logistique palettes bois vides |
| ItemCode | Champ EasyWMS contenant le code lot SAP (= clé article WMS) |
| Bag/Pal | Nombre de sacs par palette (= ContainerQty dans ITM) |
| DESADV | Type message SAP pour livraison fournisseur/intersite (utilisé dans ROR) |
| ORDRSP | Type message SAP pour retour client (utilisé dans ROR) |
| vassist | Virtual assistant — outil SmartUI pour configurer les modes de postes de travail |
| WfAction | Workflow Action — bouton custom dans la workstation (ex. réappro palettes vides) |
| ZPL | Zebra Programming Language — format requis pour imprimantes étiquettes RFID |
| QUAI_TEMPORAIRE | Quai fictif par défaut assigné aux OS, accessible par toutes les images de quai |
| QUAI_RECERTIF | Quai virtuel destination des palettes en recertification (route via PK) |
| CstData | Custom Data — données transmises à Galileo (ex: programme filmage, commande impression) |
| STOP | Numéro d'arrêt dans une tournée RUT — ordonnance le chargement (inverse de l'ordre de livraison) |
| isCritical | Flag SOR.Line — rend une ligne obligatoire pour l'expédition |
| isRequired | Flag SOR.Line — rend une ligne obligatoire pour l'expédition |
| AllowAssignStockExcess | Flag SOR.Line — autorise l'assignation même si le stock dépasse la demande |
| OnStockAdjust | Workflow WMS qui recalcule l'assignation après ajustement de stock au picking |
| StackerCrane_SortTasks_PR | Workflow de tri des tâches de picking par gerbabilité (stack) |
| COF | Count Order Fulfilled — message WMS sortant, confirmation échantillonnage |
| SSCC | Serial Shipping Container Code — identifiant unique palette (étiquette GS1) |
| GS1 | Organisation de normalisation — fournit les plages SSCC |
| CPI | Canal Point d'Intégration SAP — middleware traitement messages (volumétrie WSC) |
| Z-Bag | Sacs vides (emballage) — stockés en ASRS pour livraison client uniquement |
| SingleReceipt | Paramètre ROR : true = pas de reliquat WMS (une seule réception par ordre) |
| AutoReleaseDate | Date de libération automatique d'un SOR/RUT (PlannedShippingDate - 48h) |
| TransactionalLineList | Flag SOR : true = tout ou rien (refus total si une ligne est en erreur) |
| CompleteSorList | Flag RUT : true = SOR absents de la mise à jour sont supprimés |
| ERPReasonCode | Code motif ERP (ex: ZSC1) transmis dans les messages de variation stock |
| OutboundClassCode | Classification du type de sortie : PRODUCTION, RECERTIFICATION, CLIENT |
| IsSlave | Flag conteneur LOF : true = palette support (pas le stock directement) |
| QUAI_RECERTIFICATION | Quai fictif assigné aux SOR de recertification dans le message ERP |
| PARKING | Emplacement fictif d'attente camion — quai par défaut avant assignation réelle |
| CST_DockStationsWorkloadForView | Entité custom affichant l'occupation des quais (réceptions + tournées + plaques) |
| InboundClassCode | Code de classe de préavis de réception — contrôle de cohérence à la création réception |
| PALETTE_US | Type de support virtuel créé lors de la déclaration image de quai |
| HORS TOLERANCE | Verrou support posé au PIE si écart de poids détecté (hors retour) — palette admise en ASRS |
| ECART RETOUR | Verrou support posé au PIE si écart de poids sur un retour client — palette rejetée |
| FILMAGES | Paramètre WMS contenant la liste des programmes de filmage (`code;libellé|…`) |
| CstAtt02 (support) | Flag Big Bag sur le support (`true`/`false`) — set au poste de travail réception |
| CstAtt03 (support) | Flag anoxie sur le support (`true`) — set au poste de travail réception |
| CstAtt05 (support) | Programme de filmage (`0`, `A`, `B`…) — set au poste de travail réception |
| AI (GS1) | Application Identifier — préfixe numérique dans un QR Code GS1 identifiant le type de donnée |
| MODES_PKxx | Paramètre SmartUI définissant les modes autorisés + priorité pour un PK (`MODE;PRIO\|…`) |
| PK_ADJACENT | Paramètre SmartUI listant les paires de postes adjacents (`PK01;PK02\|…`) |
| PK_BIGBAG | Paramètre définissant quels PK autorisent les big-bags (P5, P6 avec palan) |
| Mega Job | Job unique « chef d'orchestre » des assignations de tâches vers les PK ([LIM-70](https://easywmsfrance.atlassian.net/browse/LIM-70)) |
| DESTINATION_PRODUCTION | Paramètre du job LIM-71 — code du buffer d'entrée production pour les tâches AGV |
| CstAtt04 (support) | Type de réception du support : "ASN" = production, sinon = fournisseur/intersite/retour |
| CstAtt06 (support) | Marqueur de traitement du job LIM-71 — contient la destination après traitement |
| SAP_LOT_VERIFY_URL | URL de l'endpoint API SAP pour la vérification des lots retour client |
| EV_RETURN | Champ réponse API SAP : "X" = lot valide |
| ET_BATCH | Tableau réponse API SAP : lots autorisés avec MATNR, CHARG, BATCH_OFF, EV_DEPLOY |
| EV_DEPLOY | Champ ET_BATCH : "X" = lot autorisé pour la réception retour |
| CstAtt11 (support) | Marqueur de rangement ASRS pour retour client — `true` une fois le support rangé, jamais remis à false |
| CstAtt01 (réception) | Flag clôture retour en cours — `true` = en attente de rangement ASRS complet |
| CstAtt01 (OE) | Flag hors tolérance — `true` = bloque auto-close OE et ROF, affichage rouge |
| AutoCloseReception | Paramètre WMS : `true` = clôture auto de la réception quand conditions custom remplies |
| AutoCloseInboundOrder | Paramètre WMS : `true` = auto-clôture OE à 100 % ou dans tolérance (ROF envoyé) |
| Reception_Close_PR_V2 | Workflow custom de clôture de réception — gère condition retour (A) et tolérance par ligne (B) |
| NON RANGEE | Valeur zone de stockage dans le REF pour supports non encore rangés en ASRS (fournisseur/intersite uniquement) |
| Mini Job | Sous-workflow du Mega Job — exécute l'assignation effective pour un type de tâche |
| LOC.SEND | Transaction custom WMS déclenchée par le job LOC — signal au GNA pour générer le message LOC |
| BOO (script) | Script Boo exécuté par le GNA — contient la logique métier d'agrégation et formatage des messages |
| SAP-CPI | SAP Cloud Platform Integration — middleware cloud SAP réceptionnant les messages WMS via API REST |
| ATHInboundMessage | Endpoint unique SAP-CPI recevant tous les messages WMS (`/http/ATHInboundMessage`) |
| MessageSAP | Code de routage CPI (ATH201=LOC, ATH202=LOF, ATH214=batch, ATH215=REF Supplier, ATH217=REF Return) |
| CstAtt20 (REF) | Type de préavis de réception (Supplier/Return) — set par REF01Observer pour routage CPI |
| CPI_AUTH_URL | Clé config GNA — URL du serveur d'authentification OAuth SAP |
| CPI_ENDPOINT_URL | Clé config GNA — endpoint unique SAP-CPI |
| VBELN | Code livraison sortante SAP — champ LOC pour ACTION=P (= SorCode côté WMS) |
| POSNR | Ligne de livraison sortante SAP — champ LOC pour ACTION=P |
| ASRS1..4 / ASRS34 | Codes zones SAP correspondant aux TK1-4 pour le message LOC |
| PK_TRANSPORTEUR_MESSAGERIE | Paramètre par transporteur — contient le code PK assigné aux commandes Messagerie de ce transporteur |
| MAX_NB_BUFFER_PK | Paramètre de capacité buffer par PK (valeur par défaut : 3) |
| ES_X | Zone d'attente (buffer) devant les postes de sortie — stockage temporaire des palettes en attente de séquençage |
| TaskCreatedEvent | Événement WMS déclenché à la création d'une tâche — utilisé pour le séquençage TK→PS |
| OutboundOrderReleasedEvent | Événement WMS déclenché au (re)lancement d'un OS — utilisé pour le séquençage TK→PS |
| PC | Palette Complète — palette d'expédition sans besoin de picking |
| PP | Palette de Picking — palette mère qui part au PK pour prélèvement |
| PF | Palette Fille — palette sortie du picking, retour ASRS |
| Défrag client custom | Custom LIM-87 : défrag shipping par tournée quand quai non assigné — éligibilité tout-ou-rien au niveau RUT |
| Stacker crane tri multi-TK | Custom LIM-88 : override WF tri stacker crane pour analyser les STOP sur tous les TK (pattern Bardinet) |
| Line.CstAtt | Numéro de séquence (entier) sur chaque tâche de picking — définit l'ordre de sortie ASRS. Ex-aequo possibles |
| OS.CstAtt | Flag booléen sur l'OS : `false` = séquences non calculées (stacker_crane bloqué), `true` = prêt |
| CONTROLE_TRAITEMENT_COMMERCIAL | Paramètre WMS : `false` = pas de séparation par traitement commercial sur les palettes filles (désactivé V1.1) |
| Bag/pal (pro rata) | Méthode de calcul de remplissage palette : chaque sac = 1/Bag_pal de son lot. Additif, gère les multi-lots |
| MAX_PRELOAD_PAR_PK | Nombre max de palettes pré-chargées en buffer ES par PK (défaut : 3) |
| SEUIL_RECENTRAGE_PF | Nombre min de PICKING_DIRECT restants pour déclencher un recentrage AGV de la PF au centre |
| Ping-pong | Optimisation picking : alternance des palettes sources entre TABLE_GAUCHE et TABLE_DROITE quand la PF est au centre |
## Historique des modifications
| Date | Auteur | Modification |
|------|--------|--------------|
| 2026-05-05 | Arthur | Création initiale avec glossaire de base |
| 2026-05-05 | Arthur | Ajout DESADV, ORDRSP, vassist, WfAction, ZPL |
| 2026-05-05 | Arthur | Ajout QUAI_TEMPORAIRE, QUAI_RECERTIF, CstData, STOP, isCritical, isRequired, AllowAssignStockExcess, OnStockAdjust, StackerCrane_SortTasks_PR |
| 2026-05-06 | Arthur | Ajout COF, SSCC, GS1, CPI, Z-Bag, SingleReceipt, AutoReleaseDate, TransactionalLineList, CompleteSorList, ERPReasonCode, OutboundClassCode, IsSlave, QUAI_RECERTIFICATION (CR consolidé) |
| 2026-05-06 | Arthur | Ajout PARKING, CST_DockStationsWorkloadForView, InboundClassCode, PALETTE_US (LIM-62/63/64/65) |
| 2026-05-12 | Arthur | Ajout HORS TOLERANCE, ECART RETOUR, FILMAGES, CstAtt02/03/05 support, AI GS1 (LIM-66/67/68) |
| 2026-05-12 | Arthur | Ajout MODES_PKxx, PK_ADJACENT, PK_BIGBAG, Mega Job, DESTINATION_PRODUCTION, CstAtt04/06 support, SAP_LOT_VERIFY_URL, EV_RETURN, ET_BATCH, EV_DEPLOY (LIM-69/70/71/72) |
| 2026-05-12 | Arthur | Ajout CstAtt11 support, CstAtt01 réception/OE, AutoCloseReception, AutoCloseInboundOrder, Reception_Close_PR_V2, NON RANGEE, Mini Job (LIM-73/74) |
| 2026-05-12 | Arthur | Ajout LOC.SEND, BOO, SAP-CPI, ATHInboundMessage, MessageSAP, CstAtt20 REF, CPI_AUTH_URL, CPI_ENDPOINT_URL, VBELN, POSNR, ASRS1..4/ASRS34 (LIM-76/89) |
| 2026-05-12 | Arthur | Ajout PK_TRANSPORTEUR_MESSAGERIE, MAX_NB_BUFFER_PK, ES_X, TaskCreatedEvent, OutboundOrderReleasedEvent (LIM-80/82/84) |
| 2026-05-12 | Arthur | Ajout PC, PP, PF, Défrag client custom, Stacker crane tri multi-TK (LIM-85/87/88) |
| 2026-05-12 | Arthur | Ajout Line.CstAtt, OS.CstAtt, CONTROLE_TRAITEMENT_COMMERCIAL, Bag/pal pro rata, MAX_PRELOAD_PAR_PK, SEUIL_RECENTRAGE_PF, Ping-pong (specs V1.0/V1.1 + réu. 11/05) |
wiki_old_13-05-2026/limagrain/.fuse_hidden000000690000002d
+96
View File
@@ -0,0 +1,96 @@
---
title: "Wiki Limagrain — Table des matières"
tags: [index, limagrain]
status: draft
last_updated: 2026-05-12
---
# 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
> [wiki standard](../_index.md).
## Sections
### 01 — Inbound
- [Vue d'ensemble](01-inbound/_index.md)
- [Gestion des camions](01-inbound/gestion-camions.md)
- [Réception fournisseur](01-inbound/reception-fournisseur.md)
- [Réception retour](01-inbound/reception-retour.md)
- [Contrôle qualité réception](01-inbound/controle-qualite-reception.md)
- [Étiquette RFID](01-inbound/etiquette-rfid.md)
- [Flux ERP inbound](01-inbound/flux-erp-inbound.md)
### 02 — Stockage
- [Vue d'ensemble](02-stockage/_index.md)
- [ASRS / Miniload](02-stockage/asrs-miniload.md)
- [Configuration Galileo](02-stockage/galileo-config.md)
- [Stratégies de putaway](02-stockage/putaway-strategies.md)
- [Zones de stockage](02-stockage/zones-stockage.md)
- [Défragmentation](02-stockage/defragmentation.md)
- [Processus d'anoxie](02-stockage/processus-anoxie.md)
- [Gestion des palettes vides](02-stockage/palettes-vides.md)
### 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)
- [Placement PS → PK (choix de table)](03-picking/placement-ps-pk.md)
- [Waves et groupes](03-picking/waves-groupes.md)
- [Replenishment](03-picking/replenishment.md)
- [Consolidation / Regroupement](03-picking/consolidation-regroupement.md)
- [Échantillonnage](03-picking/echantillonnage.md)
### 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)
- [Consolidation et chargement](04-outbound/consolidation-chargement.md)
- [Flux ERP outbound](04-outbound/flux-erp-outbound.md)
### 05 — AGV
- [Vue d'ensemble](05-agv/_index.md)
- [Intégration Still iGo](05-agv/still-igo-integration.md)
- [Stations et routes AGV](05-agv/agv-stations-routes.md)
- [Job réception production → ASRS](05-agv/job-reception-production.md)
- [Job réception fournisseur/retour → PK](05-agv/job-reception-pk.md)
- [Troubleshooting AGV](05-agv/agv-troubleshooting.md)
### 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)
- [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
- [Vue d'ensemble](07-admin/_index.md)
- [Utilisateurs et groupes](07-admin/utilisateurs-groupes.md)
- [Paramètres projet](07-admin/parametres-projet.md)
- [AD Customs](07-admin/ad-customs.md)
- [Contacts projet](07-admin/contacts-projet.md)
### 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
- [Glossaire Limagrain](glossaire-limagrain.md)
wiki_old_13-05-2026/limagrain/01-inbound/.fuse_hidden0000001100000001
+239
View File
@@ -0,0 +1,239 @@
---
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]
confluence_refs: []
sources: [FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5.docx, "Réception - LIMAGRAIN - DEV - Confluence.md", LIM-66_Passage_PIE.md]
last_updated: 2026-05-12
author: Arthur
---
# 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
> et mise à jour du poids unitaire.
> **Standard EasyWMS** : → voir [GALILEO Integration](../../architecture/galileo-integration.md)
> Ce qui suit documente les **spécificités Limagrain** par rapport au standard.
## Contexte projet
Chez Limagrain, chaque passage au PIE déclenche une vérification de poids
qui sert d'**inventaire permanent** par pesée. Ce mécanisme s'applique à
**tous les processus** (réception production, extérieure, retour, picking,
regroupement, échantillonnage).
## Contrôles au PIE
Le PIE effectue les contrôles suivants :
| Contrôle | Critère de validation |
|----------|----------------------|
| Étiquette RFID | Connue (détectable) |
| Hauteur | ≤ 1900 mm |
| Largeur | ≤ 1100 mm |
| Longueur | ≤ 1300 mm |
| 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é
> 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
```
Poids lignes de stock = Poids total mesuré − Poids théorique support (PALETTE_US)
```
### É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.
**Source du poids théorique (par ordre de priorité)** : ancienne pesée
(champ « Poids » de la ligne de stock), puis poids conversion ITM
(champ « Poids théorique » de la ligne de stock).
**Formules :**
```
Ratio = Poids théorique de la ligne / Poids théorique total de toutes les lignes
Poids réel de la ligne = Poids lignes de stock × Ratio
```
**Exemple :** 5 lignes d'article A (ITM = 2 kg), 1 ligne d'article B
(ITM = 40 kg). Poids théorique total = (5 × 2) + (1 × 40) = 50 kg.
Poids mesuré au PIE = 60 kg (hors palette bois).
| Article | Poids théorique | Ratio | Poids réel calculé |
|---------|-----------------|-------|---------------------|
| A (× 5) | 2 kg (ITM) | 20 % | 2,4 kg par ligne |
| B (× 1) | 40 kg (ITM) | 80 % | 48 kg |
| **Total** | 50 kg | 100 % | **60 kg** |
### Étape 3 — Mise à jour du poids unitaire (CstAtt01)
Le **CstAtt01** de chaque ligne de stock est mis à jour avec le poids
unitaire mesuré :
```
Poids unitaire mesuré = Poids réel de la ligne / Quantité de la ligne
```
| Donnée | Champ WMS |
|--------|-----------|
| Poids unitaire mesuré | **CstAtt01** de la ligne de stock |
| Poids réel pesé (total) | Champ standard « poids balance » du support |
| Poids réel de la ligne | Champ « Poids réel » de la ligne de stock |
> **Priorité CstAtt01** : si CstAtt01 a déjà une valeur (pesée
> précédente), c'est ce poids unitaire qui est utilisé dans les calculs
> de ratio à l'étape 2 — à la place du poids théorique ITM.
> **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
> article reste inchangé. Raison : le poids varie en fonction de la
> production (début/fin de prod), chaque pesée est unique.
> Le poids est quand même appliqué et recalculé, même en cas de
> blocage (verrou).
## Vérification de la tolérance et blocage
Ref. [LIM-66](https://easywmsfrance.atlassian.net/browse/LIM-66) — en
revue de code.
### [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 l'article) → blocage via verrou sur le **support** (pas sur
le stock) + alerte SmartUI.
### [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** comme seuil d'alerte. Si
l'écart total ≥ poids du plus petit article → blocage + alerte.
### Verrous appliqués
Deux verrous possibles selon le flux :
| Verrou | Flux | Comportement post-PIE |
|--------|------|----------------------|
| **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
- Création d'une **notification SmartUI** via le circuit classique de
notifications basé sur un event (pas d'event custom)
- 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
### Comportement selon le flux (détail)
| Processus | Verrou appliqué | Action |
|-----------|-----------------|--------|
| Réception production | HORS TOLERANCE | Stockage ASRS avec verrou |
| Réception extérieure/intersite | HORS TOLERANCE | Stockage ASRS avec verrou |
| Retour client (InboundType=1) | ECART RETOUR | Rejet (pas de stockage ASRS) |
| Picking | HORS TOLERANCE | Stockage avec verrou, recomptage sur poste |
| Regroupement | HORS TOLERANCE | Stockage avec verrou, recomptage sur poste |
| Échantillonnage | HORS TOLERANCE | Stockage avec verrou, recomptage sur poste |
Dans tous les cas, le poids est quand même appliqué et recalculé.
### [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
le poids réel de la HU, **indépendamment de la tolérance**.
**Gestion du timing avec le REF :**
- **Problématique** : au moment du PIE, l'ERP ne connaît peut-être
pas encore la palette (REF pas encore envoyé)
- **Solution** : chaque palette présente dans un REF est flaguée dans
le WMS. Si palette connue de l'ERP → transaction d'écart de poids
immédiate. Si palette inconnue → flag de l'écart, puis à l'envoi du
REF, un event déclenche la transaction
- Le flag d'écart de poids est inclus dans le fichier **LOC** envoyé
à SAP
## Gestion des verrous
### Consultation
Vue « Entrepôt → Verrous conteneur » :
- Verrou appliqué par conteneur
- Date d'application
- Possibilité de débloquer (lever le verrou)
### Impact sur l'expédition
Un verrou empêchant l'expédition bloque l'assignation du stock à un ordre
de sortie. Le verrou « Réception » déclenche un **recomptage obligatoire**
avant tout processus suivant (picking, regroupement, échantillonnage).
### [CUSTOM] Dérogation poids
Pour les processus de **regroupement** et **échantillonnage**, si la palette
a un excédent de poids non corrigeable, l'opérateur peut depuis son poste
de travail **autoriser** la palette à passer le PIE même si hors tolérance.
## Post-traitements
- Réception production : **ASO et ASK désactivés**
- Les messages post-PIE ne sont pas générés pour le flux production
## Points d'attention
⚠️ 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.
⚠️ 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
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.
## Questions ouvertes
- [ ] Valeurs exactes des tolérances par type article (@Justine)
- [ ] Valeur du poids palette bois fixe (PALETTE_US) (@Théo)
- [ ] Poids variable — vérifier si le standard gère la capture de
poids avec poids moyen activé (@Nicolas)
## Historique des modifications
| Date | Auteur | Modification |
|------|--------|--------------|
| 2026-05-05 | Arthur | Création initiale depuis AF V1.5 |
| 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 |
## Références
| Source | Type | Date |
|--------|------|------|
| 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 |
wiki_old_13-05-2026/limagrain/01-inbound/.fuse_hidden0000001300000002
+128
View File
@@ -0,0 +1,128 @@
---
title: "Étiquette support RFID — Format mono-référence"
tags: [inbound, outbound, RFID, étiquette, ZPL, GS1, support]
status: draft
standard_ref: concepts/reception.md
jira_refs: [LIM-68]
confluence_refs: []
sources: [LIM-68_Etiquette_RFID.md]
last_updated: 2026-05-12
author: Arthur
---
# Étiquette support RFID — Format mono-référence
> **Résumé** : étiquette A5 imprimée lors de la réception
> fournisseur/intersite, contenant les informations du support (code,
> article, lot, GTIN) avec un QR Code GS1 et un encodage RFID via ZPL.
> **Standard EasyWMS** : → voir [Reception](../../concepts/reception.md)
> Ce qui suit documente les **spécificités Limagrain** par rapport au
> standard.
## Contexte projet
Le client Limagrain souhaite un rapport d'étiquette personnalisé pour
ses HU (supports) dans le flux de réception fournisseur/intersite.
L'étiquette est imprimée automatiquement à la confirmation de création
du conteneur sur le poste de travail (voir
[Réception fournisseur](reception-fournisseur.md) — étape 5a). Elle
peut aussi être réimprimée depuis le menu principal du poste (action
« Imprimer étiquette »).
Ref. [LIM-68](https://easywmsfrance.atlassian.net/browse/LIM-68) —
attente déploiement pour test.
## Format A5 — Contenu de l'étiquette
| N | Champ | Source WMS | Remarque |
|---|-------|-----------|----------|
| — | Quantité | Quantité + UdM | En haut de l'étiquette |
| 1 | Code support (court) | 6 derniers chiffres du code support | **En gras** |
| 2 | Code-barres | Code 128 du code support au format GS1 | |
| 3 | Code support (complet) | Code support avec préfixe `(00)` | |
| 4 | Espèce (Specie) | `ITM.CstAtt01` | |
| 5 | Traitement commercial | `ITM.Family.Description` | |
| 6 | Variety print on bag | Tel quel | |
| 7 | — | `ITM.CstAtt03` | |
| 8 | Lot officiel (Official Batch) | Premier Alias de l'article | |
| 9 | Lot interne (Internal Batch) | `ITM.Code` | = Lot SAP |
| 10 | Code GTIN | `ITM.CstAtt05` | |
| 11 | Date | — | Vide (date non connue de l'ERP) |
| 12 | QR Code GS1 | Voir section ci-dessous | |
## QR Code GS1
Le QR Code GS1 encode les identifiants suivants :
| AI (Application Identifier) | Contenu | Source |
|------------------------------|---------|--------|
| `00` | Numéro HU (code support) | Code support WMS |
| `01` | Code GTIN | `ITM.CstAtt05` |
| `10` | Lot officiel | Premier Alias de l'article |
| `21` | Lot SAP | `ITM.Code` |
| `37` | Quantité | Quantité déclarée |
> La date de production (AI `11`) a été **supprimée** du QR Code.
## Encodage RFID (ZPL)
L'impression de l'étiquette combine l'impression physique (texte,
codes-barres) et l'encodage de la puce RFID intégrée, le tout via
des commandes **ZPL** (Zebra Programming Language).
### Structure de base
```zpl
^XA
; --- Encodage RFID ---
^RFW,H^FD<données>^FS
; --- Contenu imprimé ---
^FO50,50^ADN,36,20^FD<texte affiché>^FS
^XZ
```
### Commandes ZPL utilisées
| Commande | Rôle |
|----------|------|
| `^XA` / `^XZ` | Début et fin du bloc ZPL |
| `^MMT` | Active le mode RFID sur l'imprimante |
| `^RS8,,,1` | Timeout RFID = 8, 1 retry en cas d'échec d'encodage |
| `^RFW,A,0,5,3` | Écriture RFID en ASCII, depuis le bloc 0, sur 5 blocs (20 octets), en banque User (3) |
| `^FD…^FS` | Donnée à encoder (18 caractères max) |
### Exemple concret
```zpl
^XA
^MMT
^RS8,,,1
^RFW,A,0,5,3^FDSupport123456789012^FS
^FO30,20^A0N,30,25^FDRapport de support^FS
^XZ
```
## Points d'attention
- L'imprimante doit être **compatible ZPL** avec encodage RFID
(contrainte fournisseur à valider — voir question ouverte dans
[Réception fournisseur](reception-fournisseur.md))
- Le code support encodé en RFID fait **18 caractères** (5 blocs de
4 octets = 20 octets en banque User 3)
- L'étiquette est au format **A5 paysage**
- La date (champ 11) est volontairement vide car non connue de l'ERP
au moment de la réception
## Historique des modifications
| Date | Auteur | Modification |
|------|--------|--------------|
| 2026-05-12 | Arthur | Création initiale depuis LIM-68 |
## Références
| Source | Type | Date |
|--------|------|------|
| [LIM-68](https://easywmsfrance.atlassian.net/browse/LIM-68) | Ticket Jira | 2026 |
wiki_old_13-05-2026/limagrain/01-inbound/.fuse_hidden0000001500000003
+195
View File
@@ -0,0 +1,195 @@
---
title: "Flux ERP inbound — Messages réception"
tags: [inbound, ERP, ASN, ROR, ROF, REF, ITM, interface]
status: draft
standard_ref: architecture/erp-integration.md
jira_refs: []
confluence_refs: []
sources: [FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5.docx, "CR CONSOLIDES REU ERP LIMAGRAIN V1 - CR.md"]
last_updated: 2026-05-06
author: Arthur
---
# 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.
> **Standard EasyWMS** : → voir [ERP Integration](../../architecture/erp-integration.md)
> Ce qui suit documente les **spécificités Limagrain** par rapport au standard.
## Contexte projet
La communication ERP se fait via **XML + Webservice** entre SAP EWM et
EasyWMS (service GNA). Tous les messages de réception sont documentés ici.
Pour les messages d'expédition, voir
[Flux ERP outbound](../04-outbound/flux-erp-outbound.md).
## Messages entrants (SAP → EasyWMS)
### ITM — Item Master
| Champ | Description |
|-------|-------------|
| Direction | ERP → WMS |
| Déclencheur | Création/modification article dans SAP |
| Contenu | Code lot SAP, description, propriétaire, UdM, poids brut, conversions, profils, type conteneur, quantité complète, type article (FERT/ZSIZ) |
| [CUSTOM] | Espèce, génération, marque, variété, traitement commercial, packing unit, code GTIN, semences essais, size, field production area |
> ⚠️ 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
| 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) |
| 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 |
**Attributs logistiques dans les lignes ASN** :
| Attribut logistique | Champ SAP | Usage |
|---------------------|-----------|-------|
| LotCode | Code produit SAP | Différencie produits pour même lot SAP |
| Color | Propriétaire réel SAP | ≠ "MECALUX" technique |
| Source | Description produit | Désignation courte SAP |
| Size | Destination (Pays) | Peut changer |
**Statuts de stock** : gérés dès l'ASN. Si stock OK : ne PAS envoyer de
statut (champ vide ou absent du JSON).
**Champs NON utilisés** : DivisionType, ReceiptOrderCode, IsSlave,
Height/Volume (recalculé au pesage PIE), dates fabrication/expiration,
numéro de série.
### ROR — Reception Order Request
| Champ | Description |
|-------|-------------|
| Direction | ERP → WMS |
| Déclencheur | Planification réception dans SAP (extérieures, intersites, retours) |
| Contenu | Numéro de réception, articles, lots SAP, quantités (unités de vente) |
| Structure | 1 ROR = 1 livraison SAP (un camion peut contenir plusieurs livraisons) |
**Types de réception (InboundType)** :
| InboundType | Usage | AccountCode/SupplierCode | Tolérance |
|-------------|-------|--------------------------|-----------|
| 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) |
**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
RFID en réception).
### [CUSTOM] API Lot SAP (retours clients uniquement)
| Champ | Description |
|-------|-------------|
| Direction | WMS → ERP (requête) puis ERP → WMS (réponse) |
| Déclencheur | Scan lot officiel inconnu sur poste de travail |
| Requête | Lot officiel |
| Réponse OK | Lot SAP, articles possibles, descriptions, destinations + déclenchement ITM |
| Réponse NOK | Message erreur ("lot n'existe pas" ou "lot non vendu") |
## Messages sortants (EasyWMS → SAP)
### REF — Reception Fulfilled
| Champ | Description |
|-------|-------------|
| Direction | WMS → ERP |
| Déclencheur | **Clôture manuelle** de la réception (action opérateur) |
| Contenu | Conteneurs réceptionnés, lignes de stock, [CUSTOM] zone de stockage pour chaque palette, 4 attributs logistiques + lot SAP |
| Structure | Un seul REF par réception (pas de progressif, car SingleReceipt=true). Le ReceiptCode (en-tête) = code réception WMS. Le code de l'ordre d'entrée est au niveau de la **ligne** (`LneRecOrdersPotential`) |
| 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
| Champ | Description |
|-------|-------------|
| Direction | WMS → ERP |
| Déclencheur | Validation/clôture de l'ordre d'entrée |
| Rôle | Récapitulatif de l'ensemble des stocks reçus. Signale à l'ERP que l'ordre est fermé (même partiellement). Sans ROF, l'ERP ne clôturerait jamais la commande d'achat |
| 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
| Champ | Description |
|-------|-------------|
| Direction | WMS → ERP |
| Déclencheur | Palette stockée dans l'ASRS (rangement effectif) |
| 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
```mermaid
sequenceDiagram
participant SAP
participant WMS as EasyWMS
participant GAL as Galileo/PIE
SAP->>WMS: ITM (article/lot)
Note over SAP,WMS: En amont
SAP->>WMS: ASN (pré-notif HU)
Note over SAP,WMS: À l'expédition source
GAL->>WMS: Event PIE (RFID + poids)
WMS->>WMS: Contrôle poids + rangement
WMS->>GAL: Tâche stockage
GAL->>WMS: End (palette stockée)
WMS->>SAP: LOC (emplacement)
```
## Diagramme de séquence — Réception extérieure
```mermaid
sequenceDiagram
participant SAP
participant WMS as EasyWMS
participant PK as Poste travail
participant GAL as Galileo/PIE
SAP->>WMS: ROR (ordre réception)
WMS->>PK: Palette sur poste
PK->>WMS: Déclaration contenu
WMS->>GAL: Tâche évacuation → PIE
GAL->>WMS: Event PIE
WMS->>WMS: Contrôle + rangement
GAL->>WMS: End (stockée)
WMS->>SAP: LOC
PK->>WMS: Clôture réception
WMS->>SAP: REF (avec emplacements)
WMS->>SAP: ROF
```
## Points d'attention
⚠️ 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
Limagrain pour traçabilité emplacement dans SAP.
⚠️ Les modifications dans les master data ne doivent **pas** être faites
directement dans EasyWMS (risque d'écrasement par prochain ITM).
## Historique des modifications
| 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 |
## Références
| Source | Type | Date |
|--------|------|------|
| 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 |
wiki_old_13-05-2026/limagrain/01-inbound/.fuse_hidden0000001700000004
+348
View File
@@ -0,0 +1,348 @@
---
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]
confluence_refs: []
sources: [LIM-62_gestion-camions.md, LIM-63_64_65.md]
last_updated: 2026-05-06
author: Arthur
---
# 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
> l'annonce camion, l'assignation de quai, l'affichage chauffeur, le workflow
> TRF de déclaration et l'impression d'étiquettes support.
> **Standard EasyWMS** : → voir [Reception](../../concepts/reception.md)
> Ce qui suit documente les **spécificités Limagrain** par rapport au standard.
> Le standard prévoit la création manuelle de réceptions et leur association à
> des ordres d'entrée ; Limagrain ajoute une couche de gestion physique des
> camions (plaque, quai, affichage chauffeur) et un workflow TRF dédié pour la
> déclaration des palettes sur les images de quai.
## Contexte projet
Chez Limagrain, le flux de réception commence **avant** le déchargement : un
agent de quai annonce le camion, lui assigne un quai, et les chauffeurs sont
orientés via un affichage extérieur. Après déchargement physique, un cariste
déclare les palettes sur l'image de quai via un workflow TRF dédié. Ce n'est
qu'après cette déclaration que les AGV viennent récupérer les palettes.
Ce processus est commun à tous les types de réception (production, extérieure,
retour). Les flux spécifiques de chaque type sont documentés dans les pages
dédiées : [Réception fournisseur](reception-fournisseur.md),
[Réception retour](reception-retour.md).
## Flux fonctionnel global
```mermaid
sequenceDiagram
participant CH as Chauffeur
participant AQ as Agent de quai
participant SM as SmartUI
participant AFF as Affichage extérieur
participant CAR as Cariste (TRF)
participant WMS as EasyWMS
participant AGV as AGV
CH->>AQ: Annonce arrivée camion
AQ->>SM: Crée réception + saisie plaque
SM->>SM: Vérifie classes OE identiques
AQ->>SM: Assigne quai (ou PARKING)
SM->>AFF: Mise à jour affichage (WS)
AFF->>CH: Plaque + quai assigné
CH->>CH: Se gare au quai indiqué
CH->>CAR: Déchargement physique
Note over CAR: Décharge depuis l'emplacement<br/>le plus éloigné du quai
CAR->>CAR: TRF > Réceptions > Image de quai
CAR->>WMS: Déclare nb palettes, poumon, position
WMS->>WMS: Crée palettes virtuelles PALETTE_US
WMS-->>CAR: Impression étiquettes (si type Autre)
AGV->>AGV: Récupère palettes sur image de quai
```
## É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
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
- **Ordres d'entrée** : sélection des OE du camion
### Contrôle de classe
> **Règle** : il est interdit de créer une réception mélangeant des OE de
> classes de préavis de réception différentes (`InboundClassCode`).
Si l'utilisateur sélectionne des OE de classes différentes, un message
d'erreur bloque la création :
> *"Impossible de créer une réception avec des ordres d'entrée ayant des
> classes de préavis de réception différentes"*
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)
L'agent consulte les disponibilités via le **tableau d'occupation des quais**
(ViewDetailPanel dans la vue `ReceptionVList`). Il sélectionne la réception et
assigne un quai réel.
### Règles d'assignation
- Le quai et l'image de quai sont réservés dès la sélection
- Un quai partiellement occupé peut être réutilisé (gestion manuelle de la
place restante)
- ~~Blocage si flux différent (ex : expédition)~~ — supprimé
- Si aucun quai disponible → l'opérateur conserve `PARKING` et attend une
libération
- Modification possible a posteriori
### Tableau d'occupation des quais
Le panneau `CST_Docks_Workload` (Column Span = 2) affiche pour chaque quai les
réceptions, tournées et OS associés avec les plaques correspondantes :
| Quai | Réceptions / Camions |
|------|----------------------|
| PARKING | [18-02-26_001 - ES-116-NA] ; [18-02-26-002 - GS-920-XJ] |
| QUAI_01 | |
| QUAI_02 | [18-02-26_006 - DJ-100-XD] |
| ... | |
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)
Un écran d'affichage extérieur (WS / dialogue EasyWMS) montre aux chauffeurs
sur le parking les quais assignés avec les plaques d'immatriculation.
### Spécifications
- Afficher uniquement les quais avec des réceptions ou OS associés
- Prévoir l'affichage de **6 quais + le parking** sans scroll
- Afficher les plaques (champ "Camion" / Document)
> **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)
Après déchargement physique, le cariste déclare les palettes via un menu TRF
dédié **Réceptions > Image de quai**.
### Règle de déchargement physique
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
Le parcours d'écrans dépend du type de réception :
- **Production** : écrans 1, 3, 4, 5, 7
- **Autres** (fournisseur, intersite, retours) : écrans 1, 2, 3, 4, 5, 6, 7
#### Écran 1 — Type de réception
Choix parmi :
- Production
- Autres (fournisseur, intersite, retours, etc.)
- Pile de palette
Échap : retour menu.
#### É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
Prompt : « Nombre de palettes de la réception »
Validation :
- Nombre entre 1 et 26 inclus
- Somme des supports déjà présents sur le poumon + nombre saisi ≤ 26
Message d'erreur explicatif si invalide. Échap : retour écran 2.
#### Écran 4 — Choix image de quai (poumon)
Le workflow liste tous les poumons liés aux quais (réception + expédition)
puis filtre :
- Exclure les poumons ayant des supports clients (liés à des OS) ou des
tâches de shipping en destination
- Exclure les poumons pleins (supports = capacité)
- Exclure les poumons sans assez d'emplacements libres consécutifs après le
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
> changer.
Échap : retour écran 3.
#### Écran 5 — Sous-emplacement de départ
Prompt : « Sous-emplacement de la première palette de la réception »
Validation :
- Nombre valide
- L'emplacement de départ et tous les suivants (pour atteindre le nombre de
palettes déclaré) doivent être **vides**
Exemple : si des palettes d'une autre réception occupent la position 5, et
qu'on déclare 5 palettes à partir de la position 3, c'est rejeté car la
position 5 est occupée.
Échap : retour écran 4.
#### Écran 6 — Présence de big-bags
Uniquement si type = **Autres**.
Prompt : « Présence d'un big-bag parmi les palettes de la réception ? »
Boutons OUI / NON. L'information est conservée pour la suite du flux.
Échap : retour écran 4.
#### Écran 7 — Validation et création
Récapitulatif affiché :
- Image de quai
- Type de réception
- Nombre de palettes
- Sous-emplacement de départ
- Présence de big-bags (si applicable)
À la validation :
1. **Création des palettes virtuelles** : type `PALETTE_US`, réparties sur les
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)
3. **Impression étiquettes** : uniquement si type = **Autres**, une étiquette
par palette déclarée (format LIM-65)
Échap : retour écran 5. Après validation : retour écran 2.
> **Validation de sécurité** : si le poumon ou la position de départ est
> 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.
## Étiquette support image de quai (LIM-65)
Format **A5 paysage**. Imprimée pour chaque palette de type "Autres"
(pas pour la production).
| Champ | Contenu |
|-------|---------|
| CODE | Code du support (séquence 8xxx) |
| RECEPTION | Code de la réception |
| DATE | Date d'impression |
| EMPL. | Sous-emplacement du poumon |
| QR Code | Code du support |
## Implémentation technique (AD customs)
### Entités
| Entité | Usage |
|--------|-------|
| `CST_DockStationsWorkloadForView` | Affichage occupation des quais dans les vues réception |
### Queries
| Query | Entité cible |
|-------|-------------|
| `CST_DockStationsWorkload_ForView` | `CST_DockStationsWorkloadForView` |
### Vues modifiées
| Vue | Modification |
|-----|-------------|
| `ReceptionVList` | ViewDetailPanel `CST_Docks_Workload` (Column Span = 2) — occupation quais |
| `VAssistCreateReceptionOE` | Exception steps 2 et 3 — blocage classes OE différentes |
| `VAssistReceptionAssignDock` | Step 1 : entité `CST_DockStationsWorkloadForView` remplace `Station` |
### Ressources i18n
| Code | FR | EN |
|------|----|----|
| `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_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).
### Revue de code
- **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,
commentaire `//Custom end` manquant, Column Span, titre colonne)
- **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)
- 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
- La capacité maximale d'un poumon est de **26 emplacements**
- Les palettes de type "Production" ne génèrent **pas** d'étiquettes au TRF
(elles arrivent déjà étiquetées via ASN)
- 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
## Questions ouvertes
- [ ] 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
avec le client (@Justine)
- [ ] Faut-il rendre la saisie du camion (plaque) obligatoire pour garantir
la cohérence de l'affichage chauffeur ? (@Justine)
## Historique des modifications
| Date | Auteur | Modification |
|------|--------|-------------|
| 2026-05-06 | Arthur | Création initiale depuis LIM-62, LIM-63, LIM-64, LIM-65 |
## Références
| Source | Type | Date |
|--------|------|------|
| [LIM-62](https://easywmsfrance.atlassian.net/browse/LIM-62) | Ticket Jira | 18/02/2026 |
| [LIM-63](https://easywmsfrance.atlassian.net/browse/LIM-63) | Ticket Jira | 2026 |
| [LIM-64](https://easywmsfrance.atlassian.net/browse/LIM-64) | Ticket Jira | 2026 |
| [LIM-65](https://easywmsfrance.atlassian.net/browse/LIM-65) | Ticket Jira | 2026 |
| [LIM-14](https://easywmsfrance.atlassian.net/browse/LIM-14) | Ticket Jira (séquences supports) | 2026 |
wiki_old_13-05-2026/limagrain/01-inbound/.fuse_hidden0000001900000005
+601
View File
@@ -0,0 +1,601 @@
---
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]
confluence_refs: []
sources: [FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5.docx, "Réception - LIMAGRAIN - DEV - Confluence.md", LIM-67_Postes_Travail_Reception.md, "LIM-73 - LOT1.3 [RECEPTION] Fermetures, REF et gestion retours.md"]
last_updated: 2026-05-12
author: Arthur
---
# Réception fournisseur — Production et extérieures/intersites
> **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.
> **Standard EasyWMS** : → voir [Reception](../../concepts/reception.md)
> Ce qui suit documente les **spécificités Limagrain** par rapport au standard.
## Contexte projet
Limagrain gère 3 types de réception. Cette page couvre les deux premiers :
1. **Réception depuis la production** (flux majoritaire)
2. **Réceptions extérieures / transferts intersites**
Le troisième type (retours client) est couvert dans
[Réception retour](reception-retour.md).
## É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é
> en détail dans [Gestion des camions](gestion-camions.md) (LIM-62/63/64/65).
> Ce qui suit est un résumé.
### [CUSTOM] Réservation image de quai
1. Camion arrive → agent de quai crée une **réception** dans la vue
« 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é
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
5. [CUSTOM] Écran parking (via WS) affiche plaque + n° quai pour le chauffeur
**Contraintes d'assignation image de quai :**
- 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)
ou inversement
- Si aucun quai disponible → attente de libération
- Il faut empêcher de créer une réception avec des OE de **classes de
préavis différentes** (message d'erreur bloquant)
Voir aussi [Quais et poumons](../04-outbound/consolidation-chargement.md).
### Déchargement physique
- Cariste décharge palettes depuis emplacement **le plus éloigné du quai**
- Permet d'identifier précisément les emplacements occupés pour les AGV
### [CUSTOM] Déclaration sur l'image de quai
Menu TRF custom : Réception > Images de quai > Déclaration
**Séquence commune :**
1. Scan de l'image de quai
2. Choix du type de réception (Production / Fournisseur / Retour client /
Palettes vides)
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
6. Écran de validation
7. Création des supports dans le WMS
**Pour les réceptions extérieures/retours client :**
- Impression d'une **étiquette par support** à coller sur la palette
(ROR.Code + date + « À réceptionner » + code support + empl. image de quai)
- Vérification capacité image de quai
### Création tâches de mouvement AGV
- EasyWMS indique **point de prise** et **point de dépose** uniquement
- Sens prise/dépose géré par le gestionnaire de flotte AGV (iGo)
- Pour réceptions nécessitant un poste : assignation automatique selon
contraintes déclarées (mode, big-bag, distance la plus courte)
- Assignation manuelle également possible
- Si aucun poste disponible → tâche en attente
### Libérations
- **Image de quai** : libérée **automatiquement** quand il n'y a plus
de palettes dessus (vérification via supports présents)
- **Quai** : libéré **manuellement** par l'agent au départ du véhicule
---
## Flux 1 — Réception depuis la production
### Flux physique
```mermaid
sequenceDiagram
participant Cariste
participant Quai/Poumon
participant AGV
participant Buffer
participant PIE_01
participant ASRS
Cariste->>Quai/Poumon: Déchargement
Note over Quai/Poumon: Supports virtuels créés
AGV->>Buffer: Transport support virtuel
Buffer->>PIE_01: Convoyeur entrée production
Note over PIE_01: Suppression support virtuel (containerMovedEvent)
PIE_01->>PIE_01: Déplacement palette ASN + contrôles
alt PIE OK
PIE_01->>ASRS: Stockage (stratégie rangement)
else PIE NOK
PIE_01->>Cariste: Rejet → poumon au sol + notification
end
```
### Résumé du processus
1. Déclaration sur l'image de quai (voir étape commune ci-dessus)
2. Déplacement AGV → entrée production (via supports virtuels)
3. Passage PIE (suppression support virtuel + validation palette ASN)
4. Stockage ou rejet
5. Libération quai / image de quai
### 1) [CUSTOM] Pré-notification ASN
Message **ASN** descendu de SAP **avant** l'arrivée physique (expédition
depuis l'ancien magasin). Contenu :
- Numéro unique HU
- Article / Lot SAP
- [CUSTOM] Propriétaire Limagrain
- Statut de stock
- Quantité (unités de vente)
Batch possible : jusqu'à **500 conteneurs par message ASN**.
> Les palettes sont étiquetées RFID en sortie de production (hors EasyWMS).
> L'étiquette est collée sur la housse.
### 2) [CUSTOM] Supports virtuels et déplacement AGV
**Principe des supports virtuels :**
- Création de supports « virtuels » identiques à de vrais supports mais
avec une **séquence différente (8000)** pour les identifier
- La flotte AGV déplace la palette fictive jusqu'au PIE
- 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 le PIE.
**Suppression du support virtuel :**
- Basée sur le fonctionnement standard des routes AGV
- Surveillance des **containerMovedEvent**
- Filtre : type palette ASN + destination type PIE → suppression du
support virtuel (séquence 8000)
### [CUSTOM] Redirection si entrée production saturée
En cas de blocage long terme sur l'entrée production :
- **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
- **Élément à bloquer** : le PIE (pas un élément physiquement plus
proche de l'entrée)
> Pour les tests sans AGV : utilisation de **routes virtuelles** en
> configuration easyS qui téléportent automatiquement les palettes.
### 3) Passage au PIE et création palette ASN
**Séquence au PIE :**
1. Fin d'ordre AGV au PIE → suppression du support virtuel
(via containerMovedEvent)
2. Déplacement de la palette depuis l'emplacement « ASN » au PIE
3. Le ratio poids s'effectue au niveau de l'article
Contrôles : dimensions (1300×1100×1900), poids (≤1250 kg), état palette,
RFID connue (ASN). Voir
[Contrôle qualité réception](controle-qualite-reception.md) pour le
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
« 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
[Contrôle qualité réception](controle-qualite-reception.md) pour
la gestion du timing avec le REF
- Stratégie de rangement appliquée
- Réservation canal optimale selon nb palettes ASN restantes
**PIE NOK :**
- 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
- Opérateur se rend physiquement à la zone de rejet pour corriger
- Si non corrigeable : bouton custom édite étiquette « NON CONFORME,
RENVOI » et crée une tâche vers un poumon dédié
- [CUSTOM] Aucun message ASK généré
- [CUSTOM] CstAtt du support flagué avec « Prod » (pas de poste de
travail d'origine)
---
## Flux 2 — Réceptions extérieures / transferts intersites
### Flux physique
```mermaid
sequenceDiagram
participant Cariste
participant Quai/Poumon
participant AGV
participant Poste PK
participant Filmeuse
participant PIE_02/03
participant ASRS
Cariste->>Quai/Poumon: Déchargement
AGV->>Poste PK: Transport vers poste de travail
Poste PK->>Poste PK: Traitement réception
AGV->>Filmeuse: Évacuation (filmage si demandé)
Filmeuse->>PIE_02/03: Table d'entrée
PIE_02/03->>PIE_02/03: Contrôles
alt PIE OK
PIE_02/03->>ASRS: Stockage
else PIE NOK
PIE_02/03->>Poste PK: Rejet → poumon au sol + notification
end
```
### Résumé du processus
1. Déclaration sur l'image de quai
2. Déplacement AGV → poste de travail
3. Traitement au poste de travail (constitution mono-ref + déclaration)
4. Déplacement AGV → table d'entrée (+ filmage si demandé)
5. Passage PIE
6. Stockage ou rejet
7. Clôture de la réception
8. Libération quai / image de quai
### 1) Notification ROR
Message **ROR** de SAP → EasyWMS :
- Numéro de réception (1 ROR = 1 livraison SAP, un camion peut
contenir N livraisons)
- Articles / Lots SAP / Quantités (en unités de vente)
- Pas de création de lignes autorisée
- 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
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 |
| 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
- 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
> Raison : éviter la complexification du process si l'étiquette est
> endommagée.
### 3) [CUSTOM] Déplacement vers poste de travail
Assignation automatique du poste selon :
1. Non bloqué
2. En service
3. Mode autorise la réception
4. Capacité compatible avec la déclaration
5. Distance la plus courte
Assignation manuelle aussi possible. Si aucun poste disponible → attente.
### 4) Constitution palettes mono référence
Les palettes à destination ASRS doivent être **mono référence** autant
que possible. Si multi-référence à l'arrivée :
- Opérateur dispose manuellement une palette vide sur une TP
(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
> développement spécifique.
### 5) [CUSTOM] Traitement au poste de travail
Ref. [LIM-67](https://easywmsfrance.atlassian.net/browse/LIM-67) — en
attente CDP.
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"`.
#### a) Confirmation de création support (Big Bag)
Si le conteneur scanné est un **conteneur virtuel** de réception, un
écran de confirmation crée le nouveau support « réel ». Sur cet écran :
- 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 —
voir [Étiquette RFID](etiquette-rfid.md) (LIM-68)
#### b) Menu principal du poste
Écran central avec 5 actions — les informations du support actuel sont
toujours affichées à droite. Après chaque action, retour à ce menu.
| Action | Description |
|--------|-------------|
| **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 |
| **Imprimer étiquette** | Réimpression de l'étiquette RFID (voir [Étiquette RFID](etiquette-rfid.md)) |
| **Terminer** | Vérification fermeture + filmage + évacuation (voir ci-dessous) |
#### c) Action « Terminer »
**Vérification fermeture réception** : si le conteneur actuel est le
**dernier** de la réception (nombre de conteneurs virtuels avec
`CstAtt08 = codeRecep` + conteneurs avec `CstAtt08 = codeRecep` et
`CstAtt10 = true`), proposer la fermeture de la réception avec
uniquement l'option confirmer.
**Sélection du programme de filmage** : dialogue avec liste issue du
paramètre **"FILMAGES"** :
```
Valeur par défaut : 0;Pas de filmage|A;Programme 1|B;Programme 2|C;Programme 3
```
La valeur choisie (`0`, `A`, `B`, `C`…) est stockée dans le
**CstAtt05** du support et transmise à Galileo en custom data.
Après validation, une **tâche d'évacuation** est générée pour le
transport AGV du poste de travail vers la table d'entrée.
#### Résumé des CstAtt support (poste de travail)
| CstAtt | Contenu | Set par |
|--------|---------|---------|
| 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 » |
| CstAtt08 | Code de réception | Déclaration image de quai |
| CstAtt10 | Flag support traité (`true`) | Fin de traitement |
### 6) Déplacement AGV → table d'entrée et filmage
- L'AGV déplace le conteneur vers la table d'entrée
- **Gestion du filmage** : le programme de filmage est transmis à
Galileo via custom data au moment du passage. Si le PIE dit NOK →
pas de filmage (custom data non transmis). Le filmage ne se fait que
si le PIE valide la palette
### 7) Passage PIE
Identique au flux production (mêmes formules de répartition poids,
mêmes contrôles PIE). Voir
[Contrôle qualité réception](controle-qualite-reception.md).
**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
AGV/table/poste). CstAtt du support flagué avec le poste de travail
d'origine.
---
## Clôture des réceptions (extérieures/intersites)
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
(extérieures, intersites, retours client). La réception production (ASN)
n'est pas concernée (pas de clôture manuelle).
**Relation réception ↔ OE** : une réception peut servir **plusieurs
OE**, mais un OE est servi par **une seule réception**. Si la réception
associée à un OE est incomplète, SAP gère le reliquat via une nouvelle
livraison (donc nouvel OE).
### Paramétrage
- `IsSingleReceipt = true` — une seule réception par OE, pas de
reliquats WMS
- `AutoCloseReception = true` — le WMS clôture automatiquement la
réception quand les conditions custom sont remplies (§ Déclenchement)
- `AutoCloseInboundOrder = true` — à la clôture de la réception, chaque
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
### Deux niveaux de clôture
| Niveau | Description | Message ERP |
|--------|-------------|-------------|
| Réception | Clôture d'une livraison physique | REF |
| Ordre d'entrée (OE) | Clôture de la commande complète | ROF |
### Déclenchement de l'auto-close (LIM-73 §1.1)
L'auto-close de la réception se déclenche — et le bouton « Fermer
réception » n'est visible — que si les deux conditions suivantes sont
**simultanément** remplies :
1. **Aucune palette fictive** ayant `CstAtt08 = <code de la réception>`
n'est présente (plus de palettes à venir de l'image de quai)
2. **ET** :
- **Si Workstation** : au plus **1** palette réelle au PK avec
`CstAtt10 = true` (la dernière en cours)
- **Si Vue Réception** : **aucune** palette réelle au PK avec
`CstAtt10 = true`
Si au moins une ligne est **hors tolérance**, un message d'avertissement
s'affiche : « La réception a été clôturée mais les quantités reçues sont
hors tolérance, voir avec le manager pour réguler les quantités attendues
puis fermer l'ordre d'entrée ».
### [CUSTOM] Adaptation Reception_Close_PR_V2 (LIM-73 §1.3)
Le workflow standard de clôture est modifié pour deux comportements :
**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
détail (CstAtt11, CstAtt01 réception, statut « Clôture en cours »).
**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
contenant ce combo code article / lot
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
> déterministe.
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).
### Contenu du REF (custom)
Un seul REF est envoyé par réception (pas de REF progressif, car
`IsSingleReceipt = true`). Contenu :
- Numéros de conteneurs réceptionnés
- Lignes de stocks associées
- [CUSTOM] **Zone de stockage** (récupérée depuis le code emplacement
du support) :
- 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))
- [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é
[LIM-76](https://easywmsfrance.atlassian.net/browse/LIM-76)).
### Clôture des ordres d'entrée (OE) (LIM-73 §2)
| Situation OE | Clôture | ROF | Affichage vue OE |
|--------------|---------|-----|------------------|
| 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 |
**Visibilité du bouton « Clôturer l'OE »** :
- OE sans écart ou dans la tolérance : accessible à tous (standard),
mais auto-archivé donc invisible
- OE hors tolérance (CstAtt01 OE = true, **rouge**) : bouton visible
**uniquement pour les profils non-opérateurs** (admin, manager, chef
d'équipe). Masqué pour les opérateurs standards
Le manager régularise dans SAP (envoi éventuel d'un nouveau ROR) puis
clôture manuellement l'OE → ROF envoyé.
### Réception excédentaire (> % autorisé)
Le WMS bloque. Solutions possibles :
| Solution | Description |
|----------|-------------|
| Modifier la commande | Message ROR UPSERT depuis SAP |
| Réception aveugle | Sans lien fournisseur (nécessite gestion REF BLIND) |
| Nouvelle commande | Créer une nouvelle commande d'achat pour le reliquat |
## Points d'attention
⚠️ En cas de blocage long terme sur l'entrée production, le WMS
redirige automatiquement vers les autres entrées via le système de
routes avec distances (fermeture du PIE de production).
⚠️ Les palettes issues de réceptions extérieures/intersites reçoivent
**automatiquement** le flag « A anoxier ».
⚠️ L'impression étiquettes réception au déchargement n'est possible que
pour les réceptions extérieures et retours clients (pas production).
⚠️ Les rejets PIE sont dirigés vers un **poumon au sol** avec
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 — uniquement si PIE OK.
## Questions ouvertes
- [x] Programme de filmage — interface définie dans LIM-67 : paramètre
FILMAGES avec format `code;libellé|…`, stocké dans CstAtt05
- [ ] Gestion TRF si AGV pas prêts au démarrage (@Théo)
- [ ] Utilisation du ROC (confirmation de réception) — point interne
Limagrain (@Justine)
- [ ] Création fournisseurs/clients à la volée dans EasyWMS —
faisabilité technique (@Nicolas)
- [ ] Vérifier fonctionnement ExceedPercentageAllowed vs profil de
réception (@Nicolas)
- [ ] Choix fournisseur imprimantes RFID — exiger compatibilité
ZPL (@Théo)
- [ ] 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 (@Nicolas)
- [ ] Surplus non réceptionné hors tolérance — quelle solution pour
les palettes impossibles à réceptionner ? (@Justine)
## Historique des modifications
| Date | Auteur | Modification |
|------|--------|--------------|
| 2026-05-05 | Arthur | Création initiale depuis AF V1.5 |
| 2026-05-05 | Arthur | Enrichissement depuis ateliers DEV Confluence |
| 2026-05-12 | Arthur | LIM-67 : workflow complet poste de travail, Big Bag CstAtt02, anoxie CstAtt03, filmage CstAtt05/FILMAGES, fermeture réception |
| 2026-05-12 | Arthur | LIM-73 : réécriture complète section clôture — AutoCloseReception=true, conditions CstAtt08/CstAtt10, Reception_Close_PR_V2 (tolérance par ligne, CstAtt01 OE hors tolérance), REF custom (zone stockage / "NON RANGEE"), clôture OE (tableau 3 cas, bouton restreint non-opérateur), impact LOC (LIM-76) |
## Références
| Source | Type | Date |
|--------|------|------|
| 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 | 2026 |
| [LIM-73](https://easywmsfrance.atlassian.net/browse/LIM-73) | Ticket Jira (clôture REF/ROF) | 2026 |
wiki_old_13-05-2026/limagrain/01-inbound/.fuse_hidden0000001b00000006
+400
View File
@@ -0,0 +1,400 @@
---
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]
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"]
last_updated: 2026-05-12
author: Arthur
---
# Réception retour commandes clients
> **Résumé** : processus spécifique de réception des retours client, avec
> interrogation API SAP pour validation lot, et déclaration enrichie sur
> poste de travail.
> **Standard EasyWMS** : → voir [Reception](../../concepts/reception.md)
> Ce qui suit documente les **spécificités Limagrain** par rapport au standard.
## 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
- 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
- Interrogation API SAP pour valider le lot officiel
- `AccountCode` = code client SAP (le client doit exister dans EasyWMS)
## Process complet de réception retour client
| Étape | Description | Ticket |
|-------|-------------|--------|
| 1 | Déclaration sur l'image de quai | [LIM-64](https://easywmsfrance.atlassian.net/browse/LIM-64) |
| 2 | Déplacement AGV → poste de travail | [LIM-70](https://easywmsfrance.atlassian.net/browse/LIM-70) |
| 3 | **Traitement au poste de travail** | [LIM-72](https://easywmsfrance.atlassian.net/browse/LIM-72) |
| 4 | Déplacement AGV → table d'entrée (+ filmage si demandé) | — |
| 5 | Passage PIE | [LIM-66](https://easywmsfrance.atlassian.net/browse/LIM-66) |
| 6 | Stockage ou rejet | — |
| 7 | Clôture de la réception | — |
| 8 | Libération quai / image de quai | — |
Voir [Réception fournisseur](reception-fournisseur.md) pour le détail
du déchargement camion et des déclarations initiales
([LIM-67](https://easywmsfrance.atlassian.net/browse/LIM-67) pour le
flux fournisseur au PK).
## Notification ROR
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é)
**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
Lors du scan du lot officiel sur le poste de travail, le WMS vérifie
d'abord si le lot est connu localement. Si oui, pas d'appel API. Sinon :
### Rappel : structure des articles chez Limagrain
Chez Limagrain, le **code article WMS = lot SAP** (cf.
[Données principales](../06-erp-interface/donnees-principales.md)).
Chaque lot SAP est descendu via le fichier **ITM** (fiche article
complète), et le code produit est un attribut stocké en CstAtt du stock.
Le **lot officiel** est l'alias de l'article dans le WMS.
Quand le lot est "inconnu du WMS", cela signifie qu'**aucun article
(ITM) n'existe avec ce lot officiel comme alias**. Il faut demander à
SAP d'envoyer la fiche article complète.
### Logique de vérification
```mermaid
flowchart TD
A[Scan / saisie lot officiel] --> B{Lot officiel connu du WMS ?<br/>= alias article existant ?}
B -- Oui --> C{Vendu par Limagrain ?}
B -- Non --> D[Appel API SAP]
D --> E[Écran attente<br/>refresh 5s / timeout 1 min]
E --> F{ITM reçu via API WMS ?}
F -- Oui --> C
F -- Non / Timeout --> G{Tentative < 5 ?}
G -- Oui --> H[Bouton Réessayer]
H --> D
G -- Non --> I[Erreur finale :<br/>contacter responsable]
C -- Oui --> J{Plusieurs articles ?}
C -- Non --> K[Erreur : lot non vendu<br/>par Limagrain]
J -- Non --> L[Sélection automatique<br/>→ déclaration contenu]
J -- Oui --> M[Dialogue choix article<br/>par pays d'origine]
M --> L
```
### Appel API SAP — Vérification du lot officiel
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.
**Séquence d'échange :**
```mermaid
sequenceDiagram
participant WF as WMS (workflow)
participant SAP
WF->>SAP: POST /api/v1/lot/verify
Note over WF,SAP: Payload : IV_LGNUM, IV_BATCH_OFF,<br/>IV_RETURN
SAP-->>WF: Réponse JSON (EV_RETURN, ET_BATCH)
alt EV_RETURN = "X" (OK)
SAP->>WF: POST ApplicationService/ITM
Note over SAP,WF: Fiche article complète :<br/>lot SAP = code article,<br/>lot officiel = alias
WF->>WF: Vérif : product code existe en base ?
alt OK
WF->>WF: Continuer
else Absent
WF->>WF: Proposer réessayer
end
else EV_RETURN ≠ "X" (NOK)
WF->>WF: Erreur immédiate
end
```
**Payload de requête :**
```json
POST /api/v1/lot/verify
{
"IV_LGNUM": "WF02",
"IV_MATNR": "",
"IV_CHARG": "",
"IV_BATCH_OFF": "<lot officiel à vérifier>",
"IV_RETURN": "<code du retour client (OE)>"
}
```
- `IV_LGNUM` : toujours "WF02"
- `IV_BATCH_OFF` : numéro de lot officiel scanné
- `IV_RETURN` : code du retour client (ordre d'entrée)
- Les autres champs restent vides
**Payload de réponse (champs clés) :**
| Champ | Description |
|-------|-------------|
| `EV_RETURN` | "X" = lot valide, sinon invalide |
| `ET_RETURN[]` | Tableau de messages (TYPE, MESSAGE, etc.) |
| `ET_BATCH[]` | Lots autorisés : `MATNR` (code article SAP), `CHARG` (lot SAP), `BATCH_OFF` (lot officiel), `EV_DEPLOY` ("X" = autorisé) |
Si `EV_RETURN = "X"`, on récupère dans `ET_BATCH` tous les
`BATCH_OFF` dont `EV_DEPLOY = "X"` — ce sont les lots autorisés
pour l'opérateur.
### Écran d'attente pendant la réception de l'ITM
Après l'appel API, SAP appelle directement l'API du WMS pour pousser
l'ITM. Pendant cette attente :
- **Message** : "Vérification du lot en cours..."
- **Refresh automatique** toutes les 5 secondes : le WMS vérifie si
un **alias correspondant au lot officiel** existe en base
- **Bouton "Réessayer"** visible (relance un nouvel appel API)
- **Timeout** : 1 minute maximum par tentative
- **Nombre maximum de tentatives** : 5
| Tentative | Comportement en cas de timeout |
|-----------|-------------------------------|
| 1 à 4 | Message "Erreur de communication avec SAP. Réessayer ?" + bouton Réessayer |
| 5 | Message final "Impossible de contacter SAP après 5 tentatives. Veuillez contacter votre responsable." + bouton Annuler → retour au scan lot |
### Choix du code lot (multi-résultat)
Si l'API a renvoyé **plusieurs résultats** dans `ET_BATCH` (plusieurs
`BATCH_OFF` avec `EV_DEPLOY = "X"`), un dialogue de sélection est
affiché avec la liste des codes lots disponibles. L'opérateur en choisit
un (filtrage par pays d'origine).
Si un **seul résultat** → sélection automatique, pas de dialogue.
**Pourquoi le choix article ?** Un lot SAP peut être associé à plusieurs
articles (dépend du pays d'origine). L'opérateur doit choisir l'article
physiquement présent sur la palette.
**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)
Le traitement au PK reprend les mêmes étapes que le flux fournisseur
([LIM-67](https://easywmsfrance.atlassian.net/browse/LIM-67)) avec des
adaptations. Le tableau ci-dessous récapitule chaque étape et ses
différences :
| # | Étape | Différence vs fournisseur (LIM-67) |
|---|-------|------------------------------------|
| 1 | Sélection de la réception | Affichage "**Client: CODE - NOM**" (au lieu de "Fournisseur") sur tous les écrans |
| 2 | Big bag (CstAtt02) | Identique — toggle ON/OFF |
| 3 | Scan lot officiel + vérification | **+ Vérification API SAP** (voir section ci-dessus) |
| 4 | Déclaration quantité | Identique — affichage qté attendue + UdM, prompt non pré-rempli |
| 4bis | Flag big-bag (bouton custom) | Identique (CstAtt02) |
| 5 | Statut de stock | **Modifiable** — boutons visibles (masqués dans LIM-67) |
| 6 | Flag "À anoxier" | Identique (CstAtt03 = true) |
| 7 | Programme de filmage | Identique (paramètre FILMAGES → CstAtt05) |
| 8 | Impression étiquette RFID | Identique ([LIM-68](https://easywmsfrance.atlassian.net/browse/LIM-68)) |
| 9 | Validation → évacuation AGV | Identique |
### Statut de stock — Modifiable
Contrairement au flux fournisseur (LIM-67) où le statut de stock est
verrouillé (boutons masqués), dans le flux retour client :
- Les **boutons de changement de statut sont visibles** et fonctionnels
- L'opérateur peut modifier le statut (ex : Conforme, Sac sale,
Non conforme, etc.)
- Les écrans de **date de fin de statut** et **commentaire** suivent
le comportement standard (non skippés contrairement au fournisseur)
- [CUSTOM] Statuts spécifiques retour : **F9** (sacs sales), **B6**
(non conforme) — assignables uniquement dans ce processus
### Tolérance illimitée
- **Article non prévu** dans le retour → accepté (création de ligne
autorisée)
- **Quantité supérieure** au prévu → acceptée
- **Quantité inférieure** au prévu → acceptée (réception fermée
manuellement)
> Le prompt type de poste (3 ou 6 TP) prévu initialement est
> **abandonné** — remplacé par un message d'avertissement si le poste
> adjacent est déjà ouvert (voir
> [Stations picking](../03-picking/stations-picking.md)).
## Constitution palettes mono référence
Obligation de constituer des palettes **mono référence** avant stockage.
Si la palette retour est multi-ref :
- Opérateur appelle une palette vide sur une TP disponible
- Tri de marchandise
## Calcul poids et passage PIE
Identique aux réceptions extérieures (mêmes formules de répartition
prorata, mêmes contrôles). Voir
[Contrôle qualité réception](controle-qualite-reception.md).
**Différences pour les retours client :**
- Verrou si écart poids : **« Écart inventaire »** (vs « Réception »
pour les autres flux) — verrou posé sur le **support** (pas sur
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)
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
section décrit le **delta retour client** : le REF est conditionné au
rangement ASRS complet.
### Contexte métier
Pour les retours clients, le REF influe sur la **facturation SAP**. Il
ne doit être envoyé que lorsque **tous les supports** de la réception
sont rangés dans l'ASRS (et ont passé l'ensemble des contrôles,
notamment PIE).
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
À chaque fin de tâche de rangement dans l'ASRS :
- Vérifier si le support provient d'une réception de type **retour**
- Si oui → `CstAtt11 = true` sur le support
- Sinon → aucune action
Le CstAtt11 est posé une fois et n'est **jamais remis à false**, même si
le support ressort ensuite de l'ASRS (picking). Cela garantit que la
condition de clôture reste satisfaisable même si une palette a déjà été
expédiée entre-temps.
### Statut « Clôture en cours »
Dans la vue des réceptions, le statut visuel est piloté par le
`CstAtt01 de la réception` (posé par Reception_Close_PR_V2) :
| CstAtt01 réception | État | Affichage |
|---------------------|------|-----------|
| null / vide | En attente | Standard |
| true | Clôture en attente de rangement ASRS complet | **« Clôture en cours »**, ligne en **jaune** |
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)
- **Si non-retour** → clôture immédiate, génération REF (standard)
- **Si retour** :
- Vérifier que **tous les supports** ont `CstAtt11 = true`
- **Oui** → `CstAtt01 réception = false`, fermer la réception,
générer REF
- **Non** → ne pas fermer, `CstAtt01 réception = true` (statut
« Clôture en cours »). Le WF est rejoué à chaque event
_task finished_ sur un support de la réception
> Si une palette est refusée au PIE puis retirée du retour (ROR), le
> client doit la **supprimer du WMS**, sinon la clôture ne sera jamais
> effectuée.
### Zone de stockage dans le REF
Pour les retours, le REF n'est émis qu'une fois tous les supports rangés
en ASRS → la valeur sera toujours une zone réelle (jamais "NON RANGEE").
### Récapitulatif CstAtt clôture retour
| CstAtt | Entité | Rôle |
|--------|--------|------|
| CstAtt08 | Palette fictive | Code réception — détecte l'absence de palettes fictives restantes (§ auto-close) |
| CstAtt10 | Palette réelle au PK | `true` pendant traitement PK — détecte qu'aucune palette n'est en cours |
| CstAtt11 | Support (palette réelle) | `true` quand le support retour a fini son rangement ASRS — **introduit par LIM-73** |
| CstAtt01 | Réception (retour uniquement) | `true` = clôture en attente de rangement complet — **introduit par LIM-73** |
| CstAtt01 | OE (ordre d'entrée) | `true` = hors tolérance, bloque auto-close et ROF — **introduit par LIM-73** |
## Points d'attention
⚠️ Le changement de statut de stock (F9, B6) n'est autorisé sur poste de
travail **que** dans le processus retour client.
⚠️ Un commentaire est associé au statut et remonté dans le message
d'interface ERP.
⚠️ Les palettes retour reçoivent automatiquement le flag « A anoxier »
(risque contamination).
⚠️ L'API lot SAP est une interrogation synchrone — timeout 1 min,
refresh 5s, 5 essais max avant erreur finale.
⚠️ Les codes articles génériques du ROR doivent être **uniques** (pas
réutilisables) pour assurer la traçabilité.
## Paramètres spécifiques retour client
Les paramètres existants de LIM-67 sont réutilisés (FILMAGES, etc.).
Paramètres additionnels pour l'API SAP :
| Paramètre | Description | Valeur par défaut |
|-----------|-------------|-------------------|
| SAP_LOT_VERIFY_URL | URL de l'endpoint API SAP pour la vérification des lots | _(à définir)_ |
| SAP_LOT_VERIFY_TIMEOUT | Timeout d'un appel API SAP (en secondes) | 60 |
| SAP_LOT_VERIFY_MAX_RETRIES | Nombre maximum de tentatives | 5 |
| SAP_LOT_VERIFY_REFRESH | Intervalle de refresh écran d'attente (en secondes) | 5 |
## Questions ouvertes
- [x] ~~Format exact du message API lot SAP (requête/réponse)~~ — documenté
via LIM-72 (payload POST /api/v1/lot/verify + réponse ET_BATCH)
- [ ] URL exacte de l'endpoint SAP (SAP_LOT_VERIFY_URL) à définir
(@Fabien)
- [ ] Vérification "vendu par Limagrain" : est-ce le champ EV_DEPLOY
dans ET_BATCH ou un autre champ de la réponse ? (@Fabien)
- [ ] Gestion du token SAP : récupération avant chaque appel ou clé
privée ? Mécanisme à préciser (@Fabien)
- [ ] Cas du product code manquant en base après réponse OK :
combien de temps attendre avant de proposer Réessayer ? (@Fabien)
## Historique des modifications
| Date | Auteur | Modification |
|------|--------|--------------|
| 2026-05-05 | Arthur | Création initiale depuis AF V1.5 |
| 2026-05-05 | Arthur | Enrichissement depuis ateliers DEV Confluence |
| 2026-05-12 | Arthur | Flux complet PK retour (LIM-72) : process 8 étapes, API SAP détaillée (payload, séquence, écran attente, retry), statut stock modifiable, tolérance illimitée, paramètres SAP_LOT_VERIFY_*, choix article multi-résultat |
| 2026-05-12 | Arthur | LIM-73 : clôture retour client — REF conditionné au rangement ASRS complet (CstAtt11), statut « Clôture en cours » (CstAtt01 réception, jaune), Reception_Close_PR_V2 partie A (event replay), CstAtt01 OE hors tolérance, récap CstAtt clôture |
## Références
| Source | Type | Date |
|--------|------|------|
| FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5 | Analyse fonctionnelle | 28/11/2025 |
| Réception - LIMAGRAIN - DEV - Confluence | Page ateliers DEV | 2026 |
| [LIM-72](https://easywmsfrance.atlassian.net/browse/LIM-72) | Ticket Jira | 2026 |
| [LIM-67](https://easywmsfrance.atlassian.net/browse/LIM-67) | Ticket Jira (flux fournisseur PK) | 2026 |
| [LIM-68](https://easywmsfrance.atlassian.net/browse/LIM-68) | Ticket Jira (étiquette RFID) | 2026 |
| [LIM-73](https://easywmsfrance.atlassian.net/browse/LIM-73) | Ticket Jira (clôture REF/ROF retours) | 2026 |
wiki_old_13-05-2026/limagrain/01-inbound/.fuse_hidden0000001d00000007
+60
View File
@@ -0,0 +1,60 @@
---
title: "Inbound — Vue d'ensemble"
tags: [inbound, index]
status: draft
last_updated: 2026-05-12
---
# Inbound — Vue d'ensemble
> **Périmètre** : réception fournisseur, retours, contrôle qualité à réception,
> messages ERP inbound.
> **Standard EasyWMS** : voir [Reception](../../concepts/reception.md),
> [Order Inbound](../../concepts/order-inbound.md)
## Pages de cette section
- [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
- [Flux ERP inbound](flux-erp-inbound.md)
## Vue synthétique du flux inbound Limagrain
```mermaid
flowchart TD
CAM[Camion arrive] --> PARK[Quai Parking]
PARK --> QUAI[Assignation quai + image]
QUAI --> DECH[Déchargement sur poumon]
DECH --> DECL{Déclaration type}
DECL -->|Production| PROD[AGV → Entrée quais PIE_01]
DECL -->|Extérieure/Retour| EXT[AGV → Poste de travail]
DECL -->|Palettes vides| VIDE[AGV → Entrée quais PIE_01]
PROD --> PIE1[PIE_01 contrôle]
VIDE --> PIE1
EXT --> PK[Traitement sur poste PK]
PK --> AGV2[AGV → Entrée postes PIE_02/03]
AGV2 --> PIE2[PIE_02/03 contrôle]
PIE1 -->|OK| ASRS[Stockage ASRS]
PIE1 -->|NOK| REJ1[Rejet / Reconditionnement]
PIE2 -->|OK| ASRS
PIE2 -->|NOK| REJ2[Rejet → Poste d'origine]
ASRS --> LOC[Message LOC → SAP]
PK --> REF[Clôture → REF + ROF → SAP]
```
## 3 types de réception
| Type | Message ERP | Passage poste | Entrée PIE |
|------|-------------|---------------|------------|
| Production | ASN | Non | PIE_01 (côté quais) |
| Extérieure / Intersite | ROR | Oui | PIE_02/03 (côté postes) |
| Retour client | ROR + API lot | Oui | PIE_02/03 (côté postes) |
wiki_old_13-05-2026/limagrain/01-inbound/_index.md
+60
View File
@@ -0,0 +1,60 @@
---
title: "Inbound — Vue d'ensemble"
tags: [inbound, index]
status: draft
last_updated: 2026-05-12
---
# Inbound — Vue d'ensemble
> **Périmètre** : réception fournisseur, retours, contrôle qualité à réception,
> messages ERP inbound.
> **Standard EasyWMS** : voir [Reception](../../concepts/reception.md),
> [Order Inbound](../../concepts/order-inbound.md)
## Pages de cette section
- [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
- [Flux ERP inbound](flux-erp-inbound.md)
## Vue synthétique du flux inbound Limagrain
```mermaid
flowchart TD
CAM[Camion arrive] --> PARK[Quai Parking]
PARK --> QUAI[Assignation quai + image]
QUAI --> DECH[Déchargement sur poumon]
DECH --> DECL{Déclaration type}
DECL -->|Production| PROD[AGV → Entrée quais PIE_01]
DECL -->|Extérieure/Retour| EXT[AGV → Poste de travail]
DECL -->|Palettes vides| VIDE[AGV → Entrée quais PIE_01]
PROD --> PIE1[PIE_01 contrôle]
VIDE --> PIE1
EXT --> PK[Traitement sur poste PK]
PK --> AGV2[AGV → Entrée postes PIE_02/03]
AGV2 --> PIE2[PIE_02/03 contrôle]
PIE1 -->|OK| ASRS[Stockage ASRS]
PIE1 -->|NOK| REJ1[Rejet / Reconditionnement]
PIE2 -->|OK| ASRS
PIE2 -->|NOK| REJ2[Rejet → Poste d'origine]
ASRS --> LOC[Message LOC → SAP]
PK --> REF[Clôture → REF + ROF → SAP]
```
## 3 types de réception
| Type | Message ERP | Passage poste | Entrée PIE |
|------|-------------|---------------|------------|
| Production | ASN | Non | PIE_01 (côté quais) |
| Extérieure / Intersite | ROR | Oui | PIE_02/03 (côté postes) |
| Retour client | ROR + API lot | Oui | PIE_02/03 (côté postes) |
wiki_old_13-05-2026/limagrain/01-inbound/controle-qualite-reception.md
+268
View File
@@ -0,0 +1,268 @@
---
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]
confluence_refs: []
sources: [FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5.docx, "Réception - LIMAGRAIN - DEV - Confluence.md", LIM-66_Passage_PIE.md, wiki-update-poids-PIE-tolerance.md]
last_updated: 2026-05-13
author: Arthur
---
# 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
> et mise à jour du poids unitaire.
> **Standard EasyWMS** : → voir [GALILEO Integration](../../architecture/galileo-integration.md)
> Ce qui suit documente les **spécificités Limagrain** par rapport au standard.
## Contexte projet
Chez Limagrain, chaque passage au PIE déclenche une vérification de poids
qui sert d'**inventaire permanent** par pesée. Ce mécanisme s'applique à
**tous les processus** (réception production, extérieure, retour, picking,
regroupement, échantillonnage).
## Contrôles au PIE
Le PIE effectue les contrôles suivants :
| Contrôle | Critère de validation |
|----------|----------------------|
| Étiquette RFID | Connue (détectable) |
| Hauteur | ≤ 1900 mm |
| Largeur | ≤ 1100 mm |
| Longueur | ≤ 1300 mm |
| 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é
> 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
```
Poids lignes de stock = Poids total mesuré − Poids théorique support (PALETTE_US)
```
### É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.
**Source du poids théorique (par ordre de priorité)** : ancienne pesée
(champ « Poids » de la ligne de stock), puis poids conversion ITM
(champ « Poids théorique » de la ligne de stock).
**Formules :**
```
Ratio = Poids théorique de la ligne / Poids théorique total de toutes les lignes
Poids réel de la ligne = Poids lignes de stock × Ratio
```
**Exemple :** 5 lignes d'article A (ITM = 2 kg), 1 ligne d'article B
(ITM = 40 kg). Poids théorique total = (5 × 2) + (1 × 40) = 50 kg.
Poids mesuré au PIE = 60 kg (hors palette bois).
| Article | Poids théorique | Ratio | Poids réel calculé |
|---------|-----------------|-------|---------------------|
| A (× 5) | 2 kg (ITM) | 20 % | 2,4 kg par ligne |
| B (× 1) | 40 kg (ITM) | 80 % | 48 kg |
| **Total** | 50 kg | 100 % | **60 kg** |
### Étape 3 — Mise à jour du poids unitaire (CstAtt01)
Le **CstAtt01** de chaque ligne de stock est mis à jour avec le poids
unitaire mesuré :
```
Poids unitaire mesuré = Poids réel de la ligne / Quantité de la ligne
```
| Donnée | Champ WMS |
|--------|-----------|
| Poids unitaire mesuré | **CstAtt01** de la ligne de stock |
| Poids réel pesé (total) | Champ standard « poids balance » du support |
| Poids réel de la ligne | Champ « Poids réel » de la ligne de stock |
> **Priorité CstAtt01** : si CstAtt01 a déjà une valeur (pesée
> précédente), c'est ce poids unitaire qui est utilisé comme référence
> pour **tous les calculs du passage PIE** — ratio (étape 2) **et**
> seuil de tolérance (vérification ci-dessous) — à la place du poids
> théorique ITM.
> **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
> article reste inchangé. Raison : le poids varie en fonction de la
> production (début/fin de prod), chaque pesée est unique.
> Le poids est quand même appliqué et recalculé, même en cas de
> blocage (verrou).
## Vérification de la tolérance et blocage
Ref. [LIM-66](https://easywmsfrance.atlassian.net/browse/LIM-66) — en
revue de code.
### Poids de référence pour le seuil de tolérance
Le "poids unitaire de l'article" utilisé comme seuil de tolérance suit
la même règle de priorité que le ratio :
| Situation | Poids de référence utilisé |
|-----------|---------------------------|
| CstAtt01 renseigné (pesée précédente) | **CstAtt01** (poids unitaire mesuré) |
| CstAtt01 vide (premier passage PIE) | **Poids ITM** (conversion article) |
**Conséquence sur les passages successifs** : après un premier passage
PIE qui recalibre le poids unitaire (ex. ITM = 10 kg, mesuré = 30 kg),
le seuil de tolérance au passage suivant sera basé sur 30 kg (CstAtt01).
Un écart de 20 kg (2 unités au poids ITM d'origine) ne déclenchera pas
de blocage car il reste inférieur à 1 unité au poids recalibré (30 kg).
> Validé par le client (échange Justine BEUTIN / Olivier, mai 2026).
### [CUSTOM] Palettes mono-référence
**Condition de blocage** : si l'écart de poids correspond à un écart
d'une ligne de stock (article manquant ou en trop → écart ≥ poids
unitaire de référence, cf. tableau ci-dessus) → blocage via verrou sur
le **support** (pas sur le stock) + alerte SmartUI.
### [CUSTOM] Palettes multi-références — seuil d'alerte
Pour les palettes contenant plusieurs articles différents, le système
utilise le **plus petit poids unitaire de référence** (CstAtt01 si
renseigné, sinon ITM, par ligne) comme seuil d'alerte. Si l'écart
total ≥ ce plus petit poids → blocage + alerte.
### Verrous appliqués
Deux verrous possibles selon le flux :
| Verrou | Flux | Comportement post-PIE |
|--------|------|----------------------|
| **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
- Création d'une **notification SmartUI** via le circuit classique de
notifications basé sur un event (pas d'event custom)
- 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
### Comportement selon le flux (détail)
| Processus | Verrou appliqué | Action |
|-----------|-----------------|--------|
| Réception production | HORS TOLERANCE | Stockage ASRS avec verrou |
| Réception extérieure/intersite | HORS TOLERANCE | Stockage ASRS avec verrou |
| Retour client (InboundType=1) | ECART RETOUR | Rejet (pas de stockage ASRS) |
| Picking | HORS TOLERANCE | Stockage avec verrou, recomptage sur poste |
| Regroupement | HORS TOLERANCE | Stockage avec verrou, recomptage sur poste |
| Échantillonnage | HORS TOLERANCE | Stockage avec verrou, recomptage sur poste |
Dans tous les cas, le poids est quand même appliqué et recalculé.
### [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
le poids réel de la HU, **indépendamment de la tolérance**.
**Gestion du timing avec le REF :**
- **Problématique** : au moment du PIE, l'ERP ne connaît peut-être
pas encore la palette (REF pas encore envoyé)
- **Solution** : chaque palette présente dans un REF est flaguée dans
le WMS. Si palette connue de l'ERP → transaction d'écart de poids
immédiate. Si palette inconnue → flag de l'écart, puis à l'envoi du
REF, un event déclenche la transaction
- Le flag d'écart de poids est inclus dans le fichier **LOC** envoyé
à SAP
## Gestion des verrous
### Consultation
Vue « Entrepôt → Verrous conteneur » :
- Verrou appliqué par conteneur
- Date d'application
- Possibilité de débloquer (lever le verrou)
### Impact sur l'expédition
Un verrou empêchant l'expédition bloque l'assignation du stock à un ordre
de sortie. Le verrou « Réception » déclenche un **recomptage obligatoire**
avant tout processus suivant (picking, regroupement, échantillonnage).
### [CUSTOM] Dérogation poids
Pour les processus de **regroupement** et **échantillonnage**, si la palette
a un excédent de poids non corrigeable, l'opérateur peut depuis son poste
de travail **autoriser** la palette à passer le PIE même si hors tolérance.
## Post-traitements
- Réception production : **ASO et ASK désactivés**
- Les messages post-PIE ne sont pas générés pour le flux production
## Points d'attention
⚠️ 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.
⚠️ 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
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.
⚠️ Après un passage PIE qui recalibre fortement le poids (ex. ITM
10 kg → CstAtt01 30 kg), le seuil de tolérance au passage suivant
est proportionnellement plus large. C'est le comportement attendu :
chaque pesée fait foi pour la suivante.
## Questions ouvertes
- [x] Tolérances : le seuil est dynamique (CstAtt01 > ITM), validé par
le client (mai 2026). Pas de valeur fixe par type article.
- [ ] Valeur du poids palette bois fixe (PALETTE_US) (@Théo)
- [ ] Poids variable — vérifier si le standard gère la capture de
poids avec poids moyen activé (@Nicolas)
## Historique des modifications
| Date | Auteur | Modification |
|------|--------|--------------|
| 2026-05-05 | Arthur | Création initiale depuis AF V1.5 |
| 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) |
## Références
| Source | Type | Date |
|--------|------|------|
| FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5 | Analyse fonctionnelle | 28/11/2025 |
| Réception - LIMAGRAIN - DEV - Confluence | Page ateliers DEV | 2026 |
| [LIM-66](https://easywmsfrance.atlassian.net/browse/LIM-66) | Ticket Jira | 2026 |
| Échange Justine BEUTIN / Olivier (Limagrain) | Validation client | mai 2026 |
wiki_old_13-05-2026/limagrain/01-inbound/etiquette-rfid.md
+128
View File
@@ -0,0 +1,128 @@
---
title: "Étiquette support RFID — Format mono-référence"
tags: [inbound, outbound, RFID, étiquette, ZPL, GS1, support]
status: draft
standard_ref: concepts/reception.md
jira_refs: [LIM-68]
confluence_refs: []
sources: [LIM-68_Etiquette_RFID.md]
last_updated: 2026-05-12
author: Arthur
---
# Étiquette support RFID — Format mono-référence
> **Résumé** : étiquette A5 imprimée lors de la réception
> fournisseur/intersite, contenant les informations du support (code,
> article, lot, GTIN) avec un QR Code GS1 et un encodage RFID via ZPL.
> **Standard EasyWMS** : → voir [Reception](../../concepts/reception.md)
> Ce qui suit documente les **spécificités Limagrain** par rapport au
> standard.
## Contexte projet
Le client Limagrain souhaite un rapport d'étiquette personnalisé pour
ses HU (supports) dans le flux de réception fournisseur/intersite.
L'étiquette est imprimée automatiquement à la confirmation de création
du conteneur sur le poste de travail (voir
[Réception fournisseur](reception-fournisseur.md) — étape 5a). Elle
peut aussi être réimprimée depuis le menu principal du poste (action
« Imprimer étiquette »).
Ref. [LIM-68](https://easywmsfrance.atlassian.net/browse/LIM-68) —
attente déploiement pour test.
## Format A5 — Contenu de l'étiquette
| N | Champ | Source WMS | Remarque |
|---|-------|-----------|----------|
| — | Quantité | Quantité + UdM | En haut de l'étiquette |
| 1 | Code support (court) | 6 derniers chiffres du code support | **En gras** |
| 2 | Code-barres | Code 128 du code support au format GS1 | |
| 3 | Code support (complet) | Code support avec préfixe `(00)` | |
| 4 | Espèce (Specie) | `ITM.CstAtt01` | |
| 5 | Traitement commercial | `ITM.Family.Description` | |
| 6 | Variety print on bag | Tel quel | |
| 7 | — | `ITM.CstAtt03` | |
| 8 | Lot officiel (Official Batch) | Premier Alias de l'article | |
| 9 | Lot interne (Internal Batch) | `ITM.Code` | = Lot SAP |
| 10 | Code GTIN | `ITM.CstAtt05` | |
| 11 | Date | — | Vide (date non connue de l'ERP) |
| 12 | QR Code GS1 | Voir section ci-dessous | |
## QR Code GS1
Le QR Code GS1 encode les identifiants suivants :
| AI (Application Identifier) | Contenu | Source |
|------------------------------|---------|--------|
| `00` | Numéro HU (code support) | Code support WMS |
| `01` | Code GTIN | `ITM.CstAtt05` |
| `10` | Lot officiel | Premier Alias de l'article |
| `21` | Lot SAP | `ITM.Code` |
| `37` | Quantité | Quantité déclarée |
> La date de production (AI `11`) a été **supprimée** du QR Code.
## Encodage RFID (ZPL)
L'impression de l'étiquette combine l'impression physique (texte,
codes-barres) et l'encodage de la puce RFID intégrée, le tout via
des commandes **ZPL** (Zebra Programming Language).
### Structure de base
```zpl
^XA
; --- Encodage RFID ---
^RFW,H^FD<données>^FS
; --- Contenu imprimé ---
^FO50,50^ADN,36,20^FD<texte affiché>^FS
^XZ
```
### Commandes ZPL utilisées
| Commande | Rôle |
|----------|------|
| `^XA` / `^XZ` | Début et fin du bloc ZPL |
| `^MMT` | Active le mode RFID sur l'imprimante |
| `^RS8,,,1` | Timeout RFID = 8, 1 retry en cas d'échec d'encodage |
| `^RFW,A,0,5,3` | Écriture RFID en ASCII, depuis le bloc 0, sur 5 blocs (20 octets), en banque User (3) |
| `^FD…^FS` | Donnée à encoder (18 caractères max) |
### Exemple concret
```zpl
^XA
^MMT
^RS8,,,1
^RFW,A,0,5,3^FDSupport123456789012^FS
^FO30,20^A0N,30,25^FDRapport de support^FS
^XZ
```
## Points d'attention
- L'imprimante doit être **compatible ZPL** avec encodage RFID
(contrainte fournisseur à valider — voir question ouverte dans
[Réception fournisseur](reception-fournisseur.md))
- Le code support encodé en RFID fait **18 caractères** (5 blocs de
4 octets = 20 octets en banque User 3)
- L'étiquette est au format **A5 paysage**
- La date (champ 11) est volontairement vide car non connue de l'ERP
au moment de la réception
## Historique des modifications
| Date | Auteur | Modification |
|------|--------|--------------|
| 2026-05-12 | Arthur | Création initiale depuis LIM-68 |
## Références
| Source | Type | Date |
|--------|------|------|
| [LIM-68](https://easywmsfrance.atlassian.net/browse/LIM-68) | Ticket Jira | 2026 |
wiki_old_13-05-2026/limagrain/01-inbound/flux-erp-inbound.md
+195
View File
@@ -0,0 +1,195 @@
---
title: "Flux ERP inbound — Messages réception"
tags: [inbound, ERP, ASN, ROR, ROF, REF, ITM, interface]
status: draft
standard_ref: architecture/erp-integration.md
jira_refs: []
confluence_refs: []
sources: [FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5.docx, "CR CONSOLIDES REU ERP LIMAGRAIN V1 - CR.md"]
last_updated: 2026-05-06
author: Arthur
---
# 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.
> **Standard EasyWMS** : → voir [ERP Integration](../../concepts/erp-interface.md)
> Ce qui suit documente les **spécificités Limagrain** par rapport au standard.
## Contexte projet
La communication ERP se fait via **XML + Webservice** entre SAP EWM et
EasyWMS (service GNA). Tous les messages de réception sont documentés ici.
Pour les messages d'expédition, voir
[Flux ERP outbound](../04-outbound/flux-erp-outbound.md).
## Messages entrants (SAP → EasyWMS)
### ITM — Item Master
| Champ | Description |
|-------|-------------|
| Direction | ERP → WMS |
| Déclencheur | Création/modification article dans SAP |
| Contenu | Code lot SAP, description, propriétaire, UdM, poids brut, conversions, profils, type conteneur, quantité complète, type article (FERT/ZSIZ) |
| [CUSTOM] | Espèce, génération, marque, variété, traitement commercial, packing unit, code GTIN, semences essais, size, field production area |
> ⚠️ 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
| 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) |
| 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 |
**Attributs logistiques dans les lignes ASN** :
| Attribut logistique | Champ SAP | Usage |
|---------------------|-----------|-------|
| LotCode | Code produit SAP | Différencie produits pour même lot SAP |
| Color | Propriétaire réel SAP | ≠ "MECALUX" technique |
| Source | Description produit | Désignation courte SAP |
| Size | Destination (Pays) | Peut changer |
**Statuts de stock** : gérés dès l'ASN. Si stock OK : ne PAS envoyer de
statut (champ vide ou absent du JSON).
**Champs NON utilisés** : DivisionType, ReceiptOrderCode, IsSlave,
Height/Volume (recalculé au pesage PIE), dates fabrication/expiration,
numéro de série.
### ROR — Reception Order Request
| Champ | Description |
|-------|-------------|
| Direction | ERP → WMS |
| Déclencheur | Planification réception dans SAP (extérieures, intersites, retours) |
| Contenu | Numéro de réception, articles, lots SAP, quantités (unités de vente) |
| Structure | 1 ROR = 1 livraison SAP (un camion peut contenir plusieurs livraisons) |
**Types de réception (InboundType)** :
| InboundType | Usage | AccountCode/SupplierCode | Tolérance |
|-------------|-------|--------------------------|-----------|
| 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) |
**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
RFID en réception).
### [CUSTOM] API Lot SAP (retours clients uniquement)
| Champ | Description |
|-------|-------------|
| Direction | WMS → ERP (requête) puis ERP → WMS (réponse) |
| Déclencheur | Scan lot officiel inconnu sur poste de travail |
| Requête | Lot officiel |
| Réponse OK | Lot SAP, articles possibles, descriptions, destinations + déclenchement ITM |
| Réponse NOK | Message erreur ("lot n'existe pas" ou "lot non vendu") |
## Messages sortants (EasyWMS → SAP)
### REF — Reception Fulfilled
| Champ | Description |
|-------|-------------|
| Direction | WMS → ERP |
| Déclencheur | **Clôture manuelle** de la réception (action opérateur) |
| Contenu | Conteneurs réceptionnés, lignes de stock, [CUSTOM] zone de stockage pour chaque palette, 4 attributs logistiques + lot SAP |
| Structure | Un seul REF par réception (pas de progressif, car SingleReceipt=true). Le ReceiptCode (en-tête) = code réception WMS. Le code de l'ordre d'entrée est au niveau de la **ligne** (`LneRecOrdersPotential`) |
| 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
| Champ | Description |
|-------|-------------|
| Direction | WMS → ERP |
| Déclencheur | Validation/clôture de l'ordre d'entrée |
| Rôle | Récapitulatif de l'ensemble des stocks reçus. Signale à l'ERP que l'ordre est fermé (même partiellement). Sans ROF, l'ERP ne clôturerait jamais la commande d'achat |
| 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
| Champ | Description |
|-------|-------------|
| Direction | WMS → ERP |
| Déclencheur | Palette stockée dans l'ASRS (rangement effectif) |
| 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
```mermaid
sequenceDiagram
participant SAP
participant WMS as EasyWMS
participant GAL as Galileo/PIE
SAP->>WMS: ITM (article/lot)
Note over SAP,WMS: En amont
SAP->>WMS: ASN (pré-notif HU)
Note over SAP,WMS: À l'expédition source
GAL->>WMS: Event PIE (RFID + poids)
WMS->>WMS: Contrôle poids + rangement
WMS->>GAL: Tâche stockage
GAL->>WMS: End (palette stockée)
WMS->>SAP: LOC (emplacement)
```
## Diagramme de séquence — Réception extérieure
```mermaid
sequenceDiagram
participant SAP
participant WMS as EasyWMS
participant PK as Poste travail
participant GAL as Galileo/PIE
SAP->>WMS: ROR (ordre réception)
WMS->>PK: Palette sur poste
PK->>WMS: Déclaration contenu
WMS->>GAL: Tâche évacuation → PIE
GAL->>WMS: Event PIE
WMS->>WMS: Contrôle + rangement
GAL->>WMS: End (stockée)
WMS->>SAP: LOC
PK->>WMS: Clôture réception
WMS->>SAP: REF (avec emplacements)
WMS->>SAP: ROF
```
## Points d'attention
⚠️ 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
Limagrain pour traçabilité emplacement dans SAP.
⚠️ Les modifications dans les master data ne doivent **pas** être faites
directement dans EasyWMS (risque d'écrasement par prochain ITM).
## Historique des modifications
| 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 |
## Références
| Source | Type | Date |
|--------|------|------|
| 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 |
wiki_old_13-05-2026/limagrain/01-inbound/gestion-camions.md
+348
View File
@@ -0,0 +1,348 @@
---
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]
confluence_refs: []
sources: [LIM-62_gestion-camions.md, LIM-63_64_65.md]
last_updated: 2026-05-06
author: Arthur
---
# 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
> l'annonce camion, l'assignation de quai, l'affichage chauffeur, le workflow
> TRF de déclaration et l'impression d'étiquettes support.
> **Standard EasyWMS** : → voir [Reception](../../concepts/reception.md)
> Ce qui suit documente les **spécificités Limagrain** par rapport au standard.
> Le standard prévoit la création manuelle de réceptions et leur association à
> des ordres d'entrée ; Limagrain ajoute une couche de gestion physique des
> camions (plaque, quai, affichage chauffeur) et un workflow TRF dédié pour la
> déclaration des palettes sur les images de quai.
## Contexte projet
Chez Limagrain, le flux de réception commence **avant** le déchargement : un
agent de quai annonce le camion, lui assigne un quai, et les chauffeurs sont
orientés via un affichage extérieur. Après déchargement physique, un cariste
déclare les palettes sur l'image de quai via un workflow TRF dédié. Ce n'est
qu'après cette déclaration que les AGV viennent récupérer les palettes.
Ce processus est commun à tous les types de réception (production, extérieure,
retour). Les flux spécifiques de chaque type sont documentés dans les pages
dédiées : [Réception fournisseur](reception-fournisseur.md),
[Réception retour](reception-retour.md).
## Flux fonctionnel global
```mermaid
sequenceDiagram
participant CH as Chauffeur
participant AQ as Agent de quai
participant SM as SmartUI
participant AFF as Affichage extérieur
participant CAR as Cariste (TRF)
participant WMS as EasyWMS
participant AGV as AGV
CH->>AQ: Annonce arrivée camion
AQ->>SM: Crée réception + saisie plaque
SM->>SM: Vérifie classes OE identiques
AQ->>SM: Assigne quai (ou PARKING)
SM->>AFF: Mise à jour affichage (WS)
AFF->>CH: Plaque + quai assigné
CH->>CH: Se gare au quai indiqué
CH->>CAR: Déchargement physique
Note over CAR: Décharge depuis l'emplacement<br/>le plus éloigné du quai
CAR->>CAR: TRF > Réceptions > Image de quai
CAR->>WMS: Déclare nb palettes, poumon, position
WMS->>WMS: Crée palettes virtuelles PALETTE_US
WMS-->>CAR: Impression étiquettes (si type Autre)
AGV->>AGV: Récupère palettes sur image de quai
```
## É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
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
- **Ordres d'entrée** : sélection des OE du camion
### Contrôle de classe
> **Règle** : il est interdit de créer une réception mélangeant des OE de
> classes de préavis de réception différentes (`InboundClassCode`).
Si l'utilisateur sélectionne des OE de classes différentes, un message
d'erreur bloque la création :
> *"Impossible de créer une réception avec des ordres d'entrée ayant des
> classes de préavis de réception différentes"*
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)
L'agent consulte les disponibilités via le **tableau d'occupation des quais**
(ViewDetailPanel dans la vue `ReceptionVList`). Il sélectionne la réception et
assigne un quai réel.
### Règles d'assignation
- Le quai et l'image de quai sont réservés dès la sélection
- Un quai partiellement occupé peut être réutilisé (gestion manuelle de la
place restante)
- ~~Blocage si flux différent (ex : expédition)~~ — supprimé
- Si aucun quai disponible → l'opérateur conserve `PARKING` et attend une
libération
- Modification possible a posteriori
### Tableau d'occupation des quais
Le panneau `CST_Docks_Workload` (Column Span = 2) affiche pour chaque quai les
réceptions, tournées et OS associés avec les plaques correspondantes :
| Quai | Réceptions / Camions |
|------|----------------------|
| PARKING | [18-02-26_001 - ES-116-NA] ; [18-02-26-002 - GS-920-XJ] |
| QUAI_01 | |
| QUAI_02 | [18-02-26_006 - DJ-100-XD] |
| ... | |
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)
Un écran d'affichage extérieur (WS / dialogue EasyWMS) montre aux chauffeurs
sur le parking les quais assignés avec les plaques d'immatriculation.
### Spécifications
- Afficher uniquement les quais avec des réceptions ou OS associés
- Prévoir l'affichage de **6 quais + le parking** sans scroll
- Afficher les plaques (champ "Camion" / Document)
> **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)
Après déchargement physique, le cariste déclare les palettes via un menu TRF
dédié **Réceptions > Image de quai**.
### Règle de déchargement physique
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
Le parcours d'écrans dépend du type de réception :
- **Production** : écrans 1, 3, 4, 5, 7
- **Autres** (fournisseur, intersite, retours) : écrans 1, 2, 3, 4, 5, 6, 7
#### Écran 1 — Type de réception
Choix parmi :
- Production
- Autres (fournisseur, intersite, retours, etc.)
- Pile de palette
Échap : retour menu.
#### É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
Prompt : « Nombre de palettes de la réception »
Validation :
- Nombre entre 1 et 26 inclus
- Somme des supports déjà présents sur le poumon + nombre saisi ≤ 26
Message d'erreur explicatif si invalide. Échap : retour écran 2.
#### Écran 4 — Choix image de quai (poumon)
Le workflow liste tous les poumons liés aux quais (réception + expédition)
puis filtre :
- Exclure les poumons ayant des supports clients (liés à des OS) ou des
tâches de shipping en destination
- Exclure les poumons pleins (supports = capacité)
- Exclure les poumons sans assez d'emplacements libres consécutifs après le
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
> changer.
Échap : retour écran 3.
#### Écran 5 — Sous-emplacement de départ
Prompt : « Sous-emplacement de la première palette de la réception »
Validation :
- Nombre valide
- L'emplacement de départ et tous les suivants (pour atteindre le nombre de
palettes déclaré) doivent être **vides**
Exemple : si des palettes d'une autre réception occupent la position 5, et
qu'on déclare 5 palettes à partir de la position 3, c'est rejeté car la
position 5 est occupée.
Échap : retour écran 4.
#### Écran 6 — Présence de big-bags
Uniquement si type = **Autres**.
Prompt : « Présence d'un big-bag parmi les palettes de la réception ? »
Boutons OUI / NON. L'information est conservée pour la suite du flux.
Échap : retour écran 4.
#### Écran 7 — Validation et création
Récapitulatif affiché :
- Image de quai
- Type de réception
- Nombre de palettes
- Sous-emplacement de départ
- Présence de big-bags (si applicable)
À la validation :
1. **Création des palettes virtuelles** : type `PALETTE_US`, réparties sur les
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)
3. **Impression étiquettes** : uniquement si type = **Autres**, une étiquette
par palette déclarée (format LIM-65)
Échap : retour écran 5. Après validation : retour écran 2.
> **Validation de sécurité** : si le poumon ou la position de départ est
> 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.
## Étiquette support image de quai (LIM-65)
Format **A5 paysage**. Imprimée pour chaque palette de type "Autres"
(pas pour la production).
| Champ | Contenu |
|-------|---------|
| CODE | Code du support (séquence 8xxx) |
| RECEPTION | Code de la réception |
| DATE | Date d'impression |
| EMPL. | Sous-emplacement du poumon |
| QR Code | Code du support |
## Implémentation technique (AD customs)
### Entités
| Entité | Usage |
|--------|-------|
| `CST_DockStationsWorkloadForView` | Affichage occupation des quais dans les vues réception |
### Queries
| Query | Entité cible |
|-------|-------------|
| `CST_DockStationsWorkload_ForView` | `CST_DockStationsWorkloadForView` |
### Vues modifiées
| Vue | Modification |
|-----|-------------|
| `ReceptionVList` | ViewDetailPanel `CST_Docks_Workload` (Column Span = 2) — occupation quais |
| `VAssistCreateReceptionOE` | Exception steps 2 et 3 — blocage classes OE différentes |
| `VAssistReceptionAssignDock` | Step 1 : entité `CST_DockStationsWorkloadForView` remplace `Station` |
### Ressources i18n
| Code | FR | EN |
|------|----|----|
| `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_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).
### Revue de code
- **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,
commentaire `//Custom end` manquant, Column Span, titre colonne)
- **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)
- 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
- La capacité maximale d'un poumon est de **26 emplacements**
- Les palettes de type "Production" ne génèrent **pas** d'étiquettes au TRF
(elles arrivent déjà étiquetées via ASN)
- 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
## Questions ouvertes
- [ ] 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
avec le client (@Justine)
- [ ] Faut-il rendre la saisie du camion (plaque) obligatoire pour garantir
la cohérence de l'affichage chauffeur ? (@Justine)
## Historique des modifications
| Date | Auteur | Modification |
|------|--------|-------------|
| 2026-05-06 | Arthur | Création initiale depuis LIM-62, LIM-63, LIM-64, LIM-65 |
## Références
| Source | Type | Date |
|--------|------|------|
| [LIM-62](https://easywmsfrance.atlassian.net/browse/LIM-62) | Ticket Jira | 18/02/2026 |
| [LIM-63](https://easywmsfrance.atlassian.net/browse/LIM-63) | Ticket Jira | 2026 |
| [LIM-64](https://easywmsfrance.atlassian.net/browse/LIM-64) | Ticket Jira | 2026 |
| [LIM-65](https://easywmsfrance.atlassian.net/browse/LIM-65) | Ticket Jira | 2026 |
| [LIM-14](https://easywmsfrance.atlassian.net/browse/LIM-14) | Ticket Jira (séquences supports) | 2026 |
wiki_old_13-05-2026/limagrain/01-inbound/reception-fournisseur.md
+545
View File
@@ -0,0 +1,545 @@
---
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]
confluence_refs: []
sources: [FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5.docx, "Réception - LIMAGRAIN - DEV - Confluence.md", LIM-67_Postes_Travail_Reception.md, "LIM-73 - LOT1.3 [RECEPTION] Fermetures, REF et gestion retours.md"]
last_updated: 2026-05-12
author: Arthur
---
# Réception fournisseur — Production et extérieures/intersites
> **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.
> **Standard EasyWMS** : → voir [Reception](../../concepts/reception.md)
> Ce qui suit documente les **spécificités Limagrain** par rapport au standard.
## Contexte projet
Limagrain gère 3 types de réception. Cette page couvre les deux premiers :
1. **Réception depuis la production** (flux majoritaire)
2. **Réceptions extérieures / transferts intersites**
Le troisième type (retours client) est couvert dans
[Réception retour](reception-retour.md).
## É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é
> en détail dans [Gestion des camions](gestion-camions.md) (LIM-62/63/64/65).
> Ce qui suit est un résumé.
### [CUSTOM] Réservation image de quai
1. Camion arrive → agent de quai crée une **réception** dans la vue
« 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é
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
5. [CUSTOM] Écran parking (via WS) affiche plaque + n° quai pour le chauffeur
**Contraintes d'assignation image de quai :**
- 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)
ou inversement
- Si aucun quai disponible → attente de libération
- Il faut empêcher de créer une réception avec des OE de **classes de
préavis différentes** (message d'erreur bloquant)
Voir aussi [Quais et poumons](../04-outbound/consolidation-chargement.md).
### Déchargement physique
- Cariste décharge palettes depuis emplacement **le plus éloigné du quai**
- Permet d'identifier précisément les emplacements occupés pour les AGV
### [CUSTOM] Déclaration sur l'image de quai
Menu TRF custom : Réception > Images de quai > Déclaration
**Séquence commune :**
1. Scan de l'image de quai
2. Choix du type de réception (Production / Fournisseur / Retour client /
Palettes vides)
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
6. Écran de validation
7. Création des supports dans le WMS
**Pour les réceptions extérieures/retours client :**
- Impression d'une **étiquette par support** à coller sur la palette
(ROR.Code + date + « À réceptionner » + code support + empl. image de quai)
- Vérification capacité image de quai
### Création tâches de mouvement AGV
- EasyWMS indique **point de prise** et **point de dépose** uniquement
- Sens prise/dépose géré par le gestionnaire de flotte AGV (iGo)
- Pour réceptions nécessitant un poste : assignation automatique selon
contraintes déclarées (mode, big-bag, distance la plus courte)
- Assignation manuelle également possible
- Si aucun poste disponible → tâche en attente
### Libérations
- **Image de quai** : libérée **automatiquement** quand il n'y a plus
de palettes dessus (vérification via supports présents)
- **Quai** : libéré **manuellement** par l'agent au départ du véhicule
---
## Flux 1 — Réception depuis la production
### Flux physique
```mermaid
sequenceDiagram
participant Cariste
participant Quai/Poumon
participant AGV
participant Buffer
participant PIE_01
participant ASRS
Cariste->>Quai/Poumon: Déchargement
Note over Quai/Poumon: Supports virtuels créés
AGV->>Buffer: Transport support virtuel
Buffer->>PIE_01: Convoyeur entrée production
Note over PIE_01: Suppression support virtuel (containerMovedEvent)
PIE_01->>PIE_01: Déplacement palette ASN + contrôles
alt PIE OK
PIE_01->>ASRS: Stockage (stratégie rangement)
else PIE NOK
PIE_01->>Cariste: Rejet → poumon au sol + notification
end
```
### Résumé du processus
1. Déclaration sur l'image de quai (voir étape commune ci-dessus)
2. Déplacement AGV → entrée production (via supports virtuels)
3. Passage PIE (suppression support virtuel + validation palette ASN)
4. Stockage ou rejet
5. Libération quai / image de quai
### 1) [CUSTOM] Pré-notification ASN
Message **ASN** descendu de SAP **avant** l'arrivée physique (expédition
depuis l'ancien magasin). Contenu :
- Numéro unique HU
- Article / Lot SAP
- [CUSTOM] Propriétaire Limagrain
- Statut de stock
- Quantité (unités de vente)
Batch possible : jusqu'à **500 conteneurs par message ASN**.
> Les palettes sont étiquetées RFID en sortie de production (hors EasyWMS).
> L'étiquette est collée sur la housse.
### 2) [CUSTOM] Supports virtuels et déplacement AGV
**Principe des supports virtuels :**
- Création de supports « virtuels » identiques à de vrais supports mais
avec une **séquence différente (8000)** pour les identifier
- La flotte AGV déplace la palette fictive jusqu'au PIE
- 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 le PIE.
**Suppression du support virtuel :**
- Basée sur le fonctionnement standard des routes AGV
- Surveillance des **containerMovedEvent**
- Filtre : type palette ASN + destination type PIE → suppression du
support virtuel (séquence 8000)
### [CUSTOM] Redirection si entrée production saturée
En cas de blocage long terme sur l'entrée production :
- **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
- **Élément à bloquer** : le PIE (pas un élément physiquement plus
proche de l'entrée)
> Pour les tests sans AGV : utilisation de **routes virtuelles** en
> configuration easyS qui téléportent automatiquement les palettes.
### 3) Passage au PIE et création palette ASN
**Séquence au PIE :**
1. Fin d'ordre AGV au PIE → suppression du support virtuel
(via containerMovedEvent)
2. Déplacement de la palette depuis l'emplacement « ASN » au PIE
3. Le ratio poids s'effectue au niveau de l'article
Contrôles : dimensions (1300×1100×1900), poids (≤1250 kg), état palette,
RFID connue (ASN). Voir
[Contrôle qualité réception](controle-qualite-reception.md) pour le
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
« 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
[Contrôle qualité réception](controle-qualite-reception.md) pour
la gestion du timing avec le REF
- Stratégie de rangement appliquée
- Réservation canal optimale selon nb palettes ASN restantes
**PIE NOK :**
- 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
- Opérateur se rend physiquement à la zone de rejet pour corriger
- Si non corrigeable : bouton custom édite étiquette « NON CONFORME,
RENVOI » et crée une tâche vers un poumon dédié
- [CUSTOM] Aucun message ASK généré
- [CUSTOM] CstAtt du support flagué avec « Prod » (pas de poste de
travail d'origine)
---
## Flux 2 — Réceptions extérieures / transferts intersites
### Flux physique (extérieur)
```mermaid
sequenceDiagram
participant Cariste
participant Quai/Poumon
participant AGV
participant Poste PK
participant Filmeuse
participant PIE_02/03
participant ASRS
Cariste->>Quai/Poumon: Déchargement
AGV->>Poste PK: Transport vers poste de travail
Poste PK->>Poste PK: Traitement réception
AGV->>Filmeuse: Évacuation (filmage si demandé)
Filmeuse->>PIE_02/03: Table d'entrée
PIE_02/03->>PIE_02/03: Contrôles
alt PIE OK
PIE_02/03->>ASRS: Stockage
else PIE NOK
PIE_02/03->>Poste PK: Rejet → poumon au sol + notification
end
```
### Résumé du processus (extérieur)
1. Déclaration sur l'image de quai
2. Déplacement AGV → poste de travail
3. Traitement au poste de travail (constitution mono-ref + déclaration)
4. Déplacement AGV → table d'entrée (+ filmage si demandé)
5. Passage PIE
6. Stockage ou rejet
7. Clôture de la réception
8. Libération quai / image de quai
### 1) Notification ROR
Message **ROR** de SAP → EasyWMS :
- Numéro de réception (1 ROR = 1 livraison SAP, un camion peut
contenir N livraisons)
- Articles / Lots SAP / Quantités (en unités de vente)
- Pas de création de lignes autorisée
- 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
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 |
| 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
- 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
> Raison : éviter la complexification du process si l'étiquette est
> endommagée.
### 3) [CUSTOM] Déplacement vers poste de travail
Assignation automatique du poste selon :
1. Non bloqué
2. En service
3. Mode autorise la réception
4. Capacité compatible avec la déclaration
5. Distance la plus courte
Assignation manuelle aussi possible. Si aucun poste disponible → attente.
### 4) Constitution palettes mono référence
Les palettes à destination ASRS doivent être **mono référence** autant
que possible. Si multi-référence à l'arrivée :
- Opérateur dispose manuellement une palette vide sur une TP
(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
> développement spécifique.
### 5) [CUSTOM] Traitement au poste de travail
Ref. [LIM-67](https://easywmsfrance.atlassian.net/browse/LIM-67) — en
attente CDP.
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"`.
#### a) Confirmation de création support (Big Bag)
Si le conteneur scanné est un **conteneur virtuel** de réception, un
écran de confirmation crée le nouveau support « réel ». Sur cet écran :
- 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 —
voir [Étiquette RFID](etiquette-rfid.md) (LIM-68)
#### b) Menu principal du poste
Écran central avec 5 actions — les informations du support actuel sont
toujours affichées à droite. Après chaque action, retour à ce menu.
| Action | Description |
|--------|-------------|
| **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 |
| **Imprimer étiquette** | Réimpression de l'étiquette RFID (voir [Étiquette RFID](etiquette-rfid.md)) |
| **Terminer** | Vérification fermeture + filmage + évacuation (voir ci-dessous) |
#### c) Action « Terminer »
**Vérification fermeture réception** : si le conteneur actuel est le
**dernier** de la réception (nombre de conteneurs virtuels avec
`CstAtt08 = codeRecep` + conteneurs avec `CstAtt08 = codeRecep` et
`CstAtt10 = true`), proposer la fermeture de la réception avec
uniquement l'option confirmer.
**Sélection du programme de filmage** : dialogue avec liste issue du
paramètre **"FILMAGES"** :
```
Valeur par défaut : 0;Pas de filmage|A;Programme 1|B;Programme 2|C;Programme 3
```
La valeur choisie (`0`, `A`, `B`, `C`…) est stockée dans le
**CstAtt05** du support et transmise à Galileo en custom data.
Après validation, une **tâche d'évacuation** est générée pour le
transport AGV du poste de travail vers la table d'entrée.
#### Résumé des CstAtt support (poste de travail)
| CstAtt | Contenu | Set par |
|--------|---------|---------|
| 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 » |
| CstAtt08 | Code de réception | Déclaration image de quai |
| CstAtt10 | Flag support traité (`true`) | Fin de traitement |
### 6) Déplacement AGV → table d'entrée et filmage
- L'AGV déplace le conteneur vers la table d'entrée
- **Gestion du filmage** : le programme de filmage est transmis à
Galileo via custom data au moment du passage. Si le PIE dit NOK →
pas de filmage (custom data non transmis). Le filmage ne se fait que
si le PIE valide la palette
### 7) Passage PIE
Identique au flux production (mêmes formules de répartition poids,
mêmes contrôles PIE). Voir
[Contrôle qualité réception](controle-qualite-reception.md).
**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
AGV/table/poste). CstAtt du support flagué avec le poste de travail
d'origine.
---
## Clôture des réceptions (extérieures/intersites)
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
(extérieures, intersites, retours client). La réception production (ASN)
n'est pas concernée (pas de clôture manuelle).
**Relation réception ↔ OE** : une réception peut servir **plusieurs
OE**, mais un OE est servi par **une seule réception**. Si la réception
associée à un OE est incomplète, SAP gère le reliquat via une nouvelle
livraison (donc nouvel OE).
### Paramétrage
- `IsSingleReceipt = true` — une seule réception par OE, pas de
reliquats WMS
- `AutoCloseReception = true` — le WMS clôture automatiquement la
réception quand les conditions custom sont remplies (§ Déclenchement)
- `AutoCloseInboundOrder = true` — à la clôture de la réception, chaque
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
### Deux niveaux de clôture
| Niveau | Description | Message ERP |
|--------|-------------|-------------|
| Réception | Clôture d'une livraison physique | REF |
| Ordre d'entrée (OE) | Clôture de la commande complète | ROF |
### Déclenchement de l'auto-close (LIM-73 §1.1)
L'auto-close de la réception se déclenche — et le bouton « Fermer
réception » n'est visible — que si les deux conditions suivantes sont
**simultanément** remplies :
1. **Aucune palette fictive** ayant `CstAtt08 = <code de la réception>`
n'est présente (plus de palettes à venir de l'image de quai)
2. **ET** :
- **Si Workstation** : au plus **1** palette réelle au PK avec
`CstAtt10 = true` (la dernière en cours)
- **Si Vue Réception** : **aucune** palette réelle au PK avec
`CstAtt10 = true`
Si au moins une ligne est **hors tolérance**, un message d'avertissement
s'affiche : « La réception a été clôturée mais les quantités reçues sont
hors tolérance, voir avec le manager pour réguler les quantités attendues
puis fermer l'ordre d'entrée ».
### [CUSTOM] Adaptation Reception_Close_PR_V2 (LIM-73 §1.3)
Le workflow standard de clôture est modifié pour deux comportements :
**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
détail (CstAtt11, CstAtt01 réception, statut « Clôture en cours »).
**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
contenant ce combo code article / lot
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
> déterministe.
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).
### Contenu du REF (custom)
Un seul REF est envoyé par réception (pas de REF progressif, car
`IsSingleReceipt = true`). Contenu :
- Numéros de conteneurs réceptionnés
- Lignes de stocks associées
- [CUSTOM] **Zone de stockage** (récupérée depuis le code emplacement
du support) :
- 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))
- [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é
[LIM-76](https://easywmsfrance.atlassian.net/browse/LIM-76)).
### Clôture des ordres d'entrée (OE) (LIM-73 §2)
| Situation OE | Clôture | ROF | Affichage vue OE |
|--------------|---------|-----|------------------|
| 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 |
**Visibilité du bouton « Clôturer l'OE »** :
- OE sans écart ou dans la tolérance : accessible à tous (standard),
mais auto-archivé donc invisible
- OE hors tolérance (CstAtt01 OE = true, **rouge**) : bouton visible
**uniquement pour les profils non-opérateurs** (admin, manager, chef
d'équipe). Masqué pour les opérateurs standards
Le manager régularise dans SAP (envoi éventuel d'un nouveau ROR) puis
clôture manuellement l'OE → ROF envoyé.
### Réception excédentaire (> % autorisé)
Le WMS bloque. Solutions possibles :
| Solution | Description |
|----------|-------------|
| Modifier la commande | Message ROR UPSERT depuis SAP |
| Réception aveugle | Sans lien fournisseur (nécessite gestion REF BLIND) |
| Nouvelle commande | Créer une nouvelle commande d'achat pour le reliquat |
## Points d'att
wiki_old_13-05-2026/limagrain/01-inbound/reception-retour.md
+466
View File
@@ -0,0 +1,466 @@
---
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]
confluence_refs: []
sources: [FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5.docx, "Réception - LIMAGRAIN - DEV - Confluence.md", "LIM-72 LOT1.3 [RETOUR] Flux complet PK.md", "LIM-73 - LOT1.3 [RECEPTION] Fermetures, REF et gestion retours.md", "recap_session_LIM-72_13-05-2026.md"]
last_updated: 2026-05-13
author: Arthur
---
# Réception retour commandes clients
> **Résumé** : processus spécifique de réception des retours client, avec
> interrogation API SAP pour validation lot, et déclaration enrichie sur
> poste de travail.
> **Standard EasyWMS** : → voir [Reception](../../concepts/reception.md)
> Ce qui suit documente les **spécificités Limagrain** par rapport au standard.
## 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
- 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
- Interrogation API SAP pour valider le lot officiel
- `AccountCode` = code client SAP (le client doit exister dans EasyWMS)
## Process complet de réception retour client
| Étape | Description | Ticket |
|-------|-------------|--------|
| 1 | Déclaration sur l'image de quai | [LIM-64](https://easywmsfrance.atlassian.net/browse/LIM-64) |
| 2 | Déplacement AGV → poste de travail | [LIM-70](https://easywmsfrance.atlassian.net/browse/LIM-70) |
| 3 | **Traitement au poste de travail** | [LIM-72](https://easywmsfrance.atlassian.net/browse/LIM-72) |
| 4 | Déplacement AGV → table d'entrée (+ filmage si demandé) | — |
| 5 | Passage PIE | [LIM-66](https://easywmsfrance.atlassian.net/browse/LIM-66) |
| 6 | Stockage ou rejet | — |
| 7 | Clôture de la réception | — |
| 8 | Libération quai / image de quai | — |
Voir [Réception fournisseur](reception-fournisseur.md) pour le détail
du déchargement camion et des déclarations initiales
([LIM-67](https://easywmsfrance.atlassian.net/browse/LIM-67) pour le
flux fournisseur au PK).
## Notification ROR
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é)
**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
Lors du scan du lot officiel sur le poste de travail, le WMS vérifie
d'abord si le lot est connu localement. Si oui, pas d'appel API. Sinon :
### Rappel : structure des articles chez Limagrain
Chez Limagrain, le **code article WMS = lot SAP** (cf.
[Données principales](../06-erp-interface/donnees-principales.md)).
Chaque lot SAP est descendu via le fichier **ITM** (fiche article
complète), et le code produit est un attribut stocké en CstAtt du stock.
Le **lot officiel** est l'alias de l'article dans le WMS.
Quand le lot est "inconnu du WMS", cela signifie qu'**aucun article
(ITM) n'existe avec ce lot officiel comme alias**. Il faut demander à
SAP d'envoyer la fiche article complète.
### Logique de vérification
```mermaid
flowchart TD
A[Scan / saisie lot officiel] --> B{Lot officiel connu du WMS ?<br/>= alias article existant ?}
B -- Oui --> C{Vendu par Limagrain ?}
B -- Non --> D[Appel API SAP]
D --> E[Écran attente<br/>refresh 5s / timeout 1 min]
E --> F{ITM reçu via API WMS ?}
F -- Oui --> C
F -- Non / Timeout --> G{Tentative < 5 ?}
G -- Oui --> H[Bouton Réessayer]
H --> D
G -- Non --> I[Erreur finale :<br/>contacter responsable]
C -- Oui --> J{Plusieurs articles ?}
C -- Non --> K[Erreur : lot non vendu<br/>par Limagrain]
J -- Non --> L[Sélection automatique<br/>→ déclaration contenu]
J -- Oui --> M[Dialogue choix article<br/>par pays d'origine]
M --> L
```
### 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.
> **Architecture CPI** : tous les flux WMS → SAP passent par un
> **endpoint unique** SAP CPI, différencié par le champ `MessageType`
> dans l'enveloppe JSON. Le flux retour utilise `MessageType = "ATH214"`.
> Voir [Intégration GNA → SAP-CPI](../06-erp-interface/gna-sap-cpi.md)
> pour le détail de l'architecture et de l'authentification OAuth 2.0.
**Séquence d'échange :**
```mermaid
sequenceDiagram
participant WF as WMS (workflow)
participant CPI as SAP CPI
participant SAP as SAP ECC
WF->>CPI: GET /http/ATHInboundMessage<br/>MessageType: ATH214
Note over WF,CPI: Auth: OAuth 2.0 Bearer token<br/>Body: { MessageType, data }
CPI->>SAP: Z_IATH214 (check batch)
SAP-->>CPI: Réponse (EV_RETURN, ET_BATCH)
CPI-->>WF: Réponse JSON
alt EV_RETURN = "X" (OK)
SAP->>CPI: ATH002 (push ITM automatique)
CPI->>WF: POST ApplicationService/ITM
Note over CPI,WF: Fiche article complète :<br/>lot SAP = code article,<br/>lot officiel = alias
WF->>WF: Poll alias en base (5s)
alt Alias trouvé
WF->>WF: Continuer
else Timeout 1 min
WF->>WF: Proposer réessayer
end
else EV_RETURN ≠ "X" (NOK)
WF->>WF: Erreur immédiate
end
```
**Authentification OAuth 2.0 :**
- Grant type : `client_credentials`
- Token endpoint TEST :
`https://vilm-cpi-test-73ltxp48.authentication.eu30.hana.ondemand.com/oauth/token`
- Token endpoint PROD : à définir
- Body : `x-www-form-urlencoded` avec `grant_type`, `client_id`,
`client_secret`
- Le token est envoyé en header `Authorization: Bearer <token>`
- Expiration gérée côté WMS (cache + renouvellement)
**Payload de requête :**
```json
GET /http/ATHInboundMessage
{
"MessageType": "ATH214",
"data": {
"IV_LGNUM": "WF02",
"IV_MATNR": "",
"IV_CHARG": "",
"IV_BATCH_OFF": "<lot officiel scanné>",
"IV_RETURN": "<code OE retour>"
}
}
```
| Champ | Type | Description |
|-------|------|-------------|
| `IV_LGNUM` | CHAR 4 | Toujours `"WF02"` |
| `IV_MATNR` | CHAR 40 | OPTIONNEL - code lot WMS (= product code SAP) |
| `IV_CHARG` | CHAR 10 | OPTIONNEL - code article WMS (= lot SAP) |
| `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.
> Header `Connection: keep-alive` requis.
**Payload de réponse :**
```json
{
"EV_RETURN": "X",
"ET_RETURN": [ { "TYPE": "...", "MESSAGE": "..." } ],
"ET_BATCH": [
{
"MATNR": "000000000000020955",
"CHARG": "2023293649",
"BATCH_OFF": "F0964D002488",
"EV_DEPLOY": "X"
}
]
}
```
| Champ | Type | Description |
|-------|------|-------------|
| `EV_RETURN` | CHAR 1 | `"X"` = aucune erreur, vide = erreur |
| `ET_RETURN[]` | Table | Messages d'erreur ou de succès SAP |
| `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 |
> ⚠️ **Mapping inversé CHARG / MATNR** : contrairement à la
> nomenclature SAP standard, `MATNR` (Material Number) porte ici le
> **product code** (= code lot WMS), et `CHARG` (Charge/Batch) porte le
> **code article WMS** (= lot SAP). Ce mapping est confirmé par Michael
> Chaudier et Vincent Goyet (avril 2026).
> ⚠️ **À confirmer** : le nom du champ de déploiement est ambigu dans
> les échanges — `EV_DEPLOY` ou `ZDEPLOY` ? En attente de clarification
> (question A2 dans
> [Questions ouvertes](../08-transverse/questions-ouvertes.md)).
Si `EV_RETURN = "X"`, on récupère dans `ET_BATCH` tous les
`BATCH_OFF` dont `EV_DEPLOY = "X"` — ce sont les lots autorisés
pour l'opérateur.
### Écran d'attente pendant la réception de l'ITM
Après l'appel API, SAP appelle directement l'API du WMS pour pousser
l'ITM. Pendant cette attente :
- **Message** : "Vérification du lot en cours..."
- **Refresh automatique** toutes les 5 secondes : le WMS vérifie si
un **alias correspondant au lot officiel** existe en base
- **Bouton "Réessayer"** visible (relance un nouvel appel API)
- **Timeout** : 1 minute maximum par tentative
- **Nombre maximum de tentatives** : 5
| Tentative | Comportement en cas de timeout |
|-----------|-------------------------------|
| 1 à 4 | Message "Erreur de communication avec SAP. Réessayer ?" + bouton Réessayer |
| 5 | Message final "Impossible de contacter SAP après 5 tentatives. Veuillez contacter votre responsable." + bouton Annuler → retour au scan lot |
### Choix du code lot (multi-résultat)
Si l'API a renvoyé **plusieurs résultats** dans `ET_BATCH` (plusieurs
`BATCH_OFF` avec `EV_DEPLOY = "X"`), un dialogue de sélection est
affiché avec la liste des codes lots disponibles. L'opérateur en choisit
un (filtrage par pays d'origine).
Si un **seul résultat** → sélection automatique, pas de dialogue.
**Pourquoi le choix article ?** Un lot SAP peut être associé à plusieurs
articles (dépend du pays d'origine). L'opérateur doit choisir l'article
physiquement présent sur la palette.
**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)
Le traitement au PK reprend les mêmes étapes que le flux fournisseur
([LIM-67](https://easywmsfrance.atlassian.net/browse/LIM-67)) avec des
adaptations. Le tableau ci-dessous récapitule chaque étape et ses
différences :
| # | Étape | Différence vs fournisseur (LIM-67) |
|---|-------|------------------------------------|
| 1 | Sélection de la réception | Affichage "**Client: CODE - NOM**" (au lieu de "Fournisseur") sur tous les écrans |
| 2 | Big bag (CstAtt02) | Identique — toggle ON/OFF |
| 3 | Scan lot officiel + vérification | **+ Vérification API SAP** (voir section ci-dessus) |
| 4 | Déclaration quantité | Identique — affichage qté attendue + UdM, prompt non pré-rempli |
| 4bis | Flag big-bag (bouton custom) | Identique (CstAtt02) |
| 5 | Statut de stock | **Modifiable** — boutons visibles (masqués dans LIM-67) |
| 6 | Flag "À anoxier" | Identique (CstAtt03 = true) |
| 7 | Programme de filmage | Identique (paramètre FILMAGES → CstAtt05) |
| 8 | Impression étiquette RFID | Identique ([LIM-68](https://easywmsfrance.atlassian.net/browse/LIM-68)) |
| 9 | Validation → évacuation AGV | Identique |
### Statut de stock — Modifiable
Contrairement au flux fournisseur (LIM-67) où le statut de stock est
verrouillé (boutons masqués), dans le flux retour client :
- Les **boutons de changement de statut sont visibles** et fonctionnels
- L'opérateur peut modifier le statut (ex : Conforme, Sac sale,
Non conforme, etc.)
- Les écrans de **date de fin de statut** et **commentaire** suivent
le comportement standard (non skippés contrairement au fournisseur)
- [CUSTOM] Statuts spécifiques retour : **F9** (sacs sales), **B6**
(non conforme) — assignables uniquement dans ce processus
### Tolérance illimitée
- **Article non prévu** dans le retour → accepté (création de ligne
autorisée)
- **Quantité supérieure** au prévu → acceptée
- **Quantité inférieure** au prévu → acceptée (réception fermée
manuellement)
> Le prompt type de poste (3 ou 6 TP) prévu initialement est
> **abandonné** — remplacé par un message d'avertissement si le poste
> adjacent est déjà ouvert (voir
> [Stations picking](../03-picking/stations-picking.md)).
## Constitution palettes mono référence
Obligation de constituer des palettes **mono référence** avant stockage.
Si la palette retour est multi-ref :
- Opérateur appelle une palette vide sur une TP disponible
- Tri de marchandise
## Calcul poids et passage PIE
Identique aux réceptions extérieures (mêmes formules de répartition
prorata, mêmes contrôles). Voir
[Contrôle qualité réception](controle-qualite-reception.md).
**Différences pour les retours client :**
- Verrou si écart poids : **« Écart inventaire »** (vs « Réception »
pour les autres flux) — verrou posé sur le **support** (pas sur
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)
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
section décrit le **delta retour client** : le REF est conditionné au
rangement ASRS complet.
### Contexte métier
Pour les retours clients, le REF influe sur la **facturation SAP**. Il
ne doit être envoyé que lorsque **tous les supports** de la réception
sont rangés dans l'ASRS (et ont passé l'ensemble des contrôles,
notamment PIE).
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
À chaque fin de tâche de rangement dans l'ASRS :
- Vérifier si le support provient d'une réception de type **retour**
- Si oui → `CstAtt11 = true` sur le support
- Sinon → aucune action
Le CstAtt11 est posé une fois et n'est **jamais remis à false**, même si
le support ressort ensuite de l'ASRS (picking). Cela garantit que la
condition de clôture reste satisfaisable même si une palette a déjà été
expédiée entre-temps.
### Statut « Clôture en cours »
Dans la vue des réceptions, le statut visuel est piloté par le
`CstAtt01 de la réception` (posé par Reception_Close_PR_V2) :
| CstAtt01 réception | État | Affichage |
|---------------------|------|-----------|
| null / vide | En attente | Standard |
| true | Clôture en attente de rangement ASRS complet | **« Clôture en cours »**, ligne en **jaune** |
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)
- **Si non-retour** → clôture immédiate, génération REF (standard)
- **Si retour** :
- Vérifier que **tous les supports** ont `CstAtt11 = true`
- **Oui** → `CstAtt01 réception = false`, fermer la réception,
générer REF
- **Non** → ne pas fermer, `CstAtt01 réception = true` (statut
« Clôture en cours »). Le WF est rejoué à chaque event
_task finished_ sur un support de la réception
> Si une palette est refusée au PIE puis retirée du retour (ROR), le
> client doit la **supprimer du WMS**, sinon la clôture ne sera jamais
> effectuée.
### Zone de stockage dans le REF
Pour les retours, le REF n'est émis qu'une fois tous les supports rangés
en ASRS → la valeur sera toujours une zone réelle (jamais "NON RANGEE").
### Récapitulatif CstAtt clôture retour
| CstAtt | Entité | Rôle |
|--------|--------|------|
| CstAtt08 | Palette fictive | Code réception — détecte l'absence de palettes fictives restantes (§ auto-close) |
| CstAtt10 | Palette réelle au PK | `true` pendant traitement PK — détecte qu'aucune palette n'est en cours de traitement |
| CstAtt11 | Palette réelle | `true` quand rangée en ASRS — condition de clôture retour |
| CstAtt01 | Réception | `true` = clôture en attente de rangement ASRS (affichage jaune) |
## État du développement LIM-72
### Implémenté (commit 8401f5456d, 28/04/2026)
- Entité `CST_StockStatus` : CstAtt 1 applicable en retour, CstAtt 2 =
ZLOG, CstAtt 3 = ZINCO
- Query `CST_StockStatus_AllowedForReturn` : filtre statuts autorisés
- Workflow `CST_Return_Stock_GetStatus_UI` : sélection statut simplifié
- Workflow `Reception_FilterLinesByProductAndContainer_UI_V1` : retrait
filtre quantité (tolérance illimitée)
- Dialog `CST_GetProductQuantity_Prompt` : option SelectStatus ajoutée
### Reste à développer
- Appel API SAP ATH214 + gestion token OAuth 2.0
- Écran d'attente ITM (polling alias 5s, timeout 1 min, 5 tentatives)
- Dialogue choix multi-lot (quand ET_BATCH contient plusieurs articles)
- Impression étiquette stock retour client (rapport custom à créer)
- Configuration flux de rejet PIE retours (verrou ECART RETOUR,
destination, notification)
## Points d'attention
⚠️ Le paramètre `SAP_LOT_VERIFY_URL` doit pointer vers l'endpoint CPI
unique `/http/ATHInboundMessage`, pas vers `/api/v1/lot/verify`.
⚠️ Le `MessageType` doit être `"ATH214"` dans l'enveloppe JSON.
⚠️ Pour les lots **déjà connus** en base WMS, le flag "déployé" n'est
pas vérifié dans le design actuel — trou fonctionnel identifié (question
A4 dans [Questions ouvertes](../08-transverse/questions-ouvertes.md)).
## Questions ouvertes
- [ ] Champs manquants ET_BATCH : description article, pays destination,
propriétaire (@Vincent Goyet) — A1
- [ ] Nom final champ déploiement : EV_DEPLOY ou ZDEPLOY ?
(@Vincent Goyet) — A2
- [ ] Délai ATH214 → push ITM dimensionnement polling
(@Vincent Goyet) — A3
- [ ] Vérification "déployé" pour lots déjà connus sans ATH214
(@Vincent Goyet) — A4
- [ ] Étiquette stock retour : format, champs, imprimante
(@Leila / @Antoine) — B1
- [ ] Flux rejet PIE retour : destination, notification, actions
(@Leila / @Antoine) — B2
## Historique des modifications
| Date | Auteur | Modification |
|------|--------|-------------|
| 2026-05-05 | Arthur | Création initiale depuis AF V1.5 |
| 2026-05-05 | Arthur | Enrichissement depuis ateliers DEV réception |
| 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 |
## Références
| Source | Type | Date |
|--------|------|------|
| Jira LIM-72 | Ticket | 2025 |
| Jira LIM-73 | Ticket | 2025 |
| 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 |
wiki_old_13-05-2026/limagrain/02-stockage/.fuse_hidden0000001f00000008
+107
View File
@@ -0,0 +1,107 @@
---
title: "ASRS — Entrepôt automatique Limagrain"
tags: [stockage, ASRS, transstockeur, racks, emplacements]
status: draft
standard_ref: architecture/galileo-integration.md
jira_refs: []
confluence_refs: []
sources: [FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5.docx]
last_updated: 2026-05-05
author: Arthur
---
# ASRS — Entrepôt automatique Limagrain
> **Résumé** : description de l'installation automatique Limagrain : 4 allées
> de transstockeurs, racks multi-profondeur, nomenclature des emplacements,
> types de conteneurs et dimensions.
> **Standard EasyWMS** : → voir [GALILEO Integration](../../architecture/galileo-integration.md),
> [Location](../../concepts/location.md)
> Ce qui suit documente les **spécificités Limagrain** par rapport au standard.
## Contexte projet
Limagrain dispose d'un magasin automatique **MAG01** composé de 4 allées de
transstockeurs gérées par EasyWMS. L'entrepôt stocke essentiellement des
graines (sacs, big-bags) sur palettes US.
## Organisation EasyWMS
| Code | Description |
|------|-------------|
| **LM** | Organisation LIMAGRAIN |
| **MAG01** | Magasin automatique — 4 allées |
## Racks et capacités
| Type rack | X Initial | X Final | Y Initial | Y Final | Hauteur (mm) | Palette |
|-----------|-----------|---------|-----------|---------|--------------|---------|
| RACK01 | 1 | 69 | 1 | 1 | 1150 | US (1000×1200) |
| RACK02 | 1 | 69 | 2 | 8 | 1950 | US (1000×1200) |
| RACK03 | 1 | 69 | 9 | 10 | 2250 | US (1000×1200) |
## Nomenclature des emplacements
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 |
| 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, ...) |
**Exemple** : `00100300721` = allée 1, colonne 3, hauteur 7, côté droit,
profondeur 1.
> Un emplacement EasyWMS correspond à un **canal complet** de rangement de
> palettes (multi-profondeur).
## Type de conteneur unique
| Type | Largeur (mm) | Longueur (mm) | Hauteur (mm) | Poids max (kg) |
|------|--------------|---------------|--------------|----------------|
| 1 — Palette US | 1000 | 1200 | 800 à 1900 | 1250 |
## Contrôles au PIE
Au passage PIE, Galileo vérifie :
- Dimensions max : 1300 × 1100 × 1900 mm
- Poids max : 1250 kg
- État de la palette bois
- Lecture étiquette RFID (code barre / QR)
Si un critère n'est pas respecté → rejet vers poste de reconditionnement
ou poste de travail d'origine.
## Exceptions de stockage
Le convoyeur de sortie **TS01** dans l'allée TK_01 occupe physiquement des
emplacements rack. Canaux indisponibles :
- X=21, Y=1
- X=21, Y=2
- X=22, Y=1
## Points d'attention
⚠️ Un seul type de conteneur (palette US) simplifie les stratégies mais
les hauteurs variables (800–1900 mm) impactent le choix du rack (RACK01/02/03).
⚠️ La hauteur PLC déterminée au PIE pilote le choix du niveau de stockage
(Y=1 pour ≤1150, Y=2-8 pour ≤1950, Y=9-10 pour ≤2250).
## Historique des modifications
| Date | Auteur | Modification |
|------|--------|--------------|
| 2026-05-05 | Arthur | Création initiale depuis AF V1.5 |
## Références
| Source | Type | Date |
|--------|------|------|
| FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5 | Analyse fonctionnelle | 28/11/2025 |
wiki_old_13-05-2026/limagrain/02-stockage/.fuse_hidden0000002100000009
+234
View File
@@ -0,0 +1,234 @@
---
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
author: Arthur
---
# 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.
> Inclut un **custom majeur** de défragmentation par tournée (RUT) avec
> ordonnancement par numéro de STOP, déclenché uniquement quand toutes
> les palettes sont prêtes et qu'aucun quai n'est assigné.
> **Standard EasyWMS** : → voir [Defragmentation](../../concepts/defragmentation.md)
> Ce qui suit documente les **spécificités Limagrain** par rapport au
> standard.
## Contexte projet
La défragmentation est un processus standard des entrepôts automatisés.
Chez Limagrain, elle sert à préparer les routes (expéditions) en
déplaçant les conteneurs vers la zone de défragmentation client
(TK02-04, rangées 60-69).
La défragmentation shipping standard propose trois modes d'assignation
(Picking Only, Shipping Only, Picking & Shipping) mais **aucun ne
répond au besoin Limagrain** :
| Mode standard | Comportement | Problème |
|---------------|-------------|----------|
| 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 | — |
**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
sorte que les palettes sortent du canal dans le bon ordre lors du
chargement camion (STOP max chargé en premier → déchargé en dernier).
Deux cas se présentent selon l'assignation du quai :
| Situation | Custom | Page |
|-----------|--------|------|
| Quai **non assigné** au RUT | Défrag custom décrite ci-dessous | Cette page |
| Quai **déjà assigné** au RUT | Override du WF stacker crane | → voir [Séquençage shipping par STOP](../04-outbound/sequencage-shipping-stop.md) |
## Principe général
Les conteneurs assignés à une expédition sont relocalisés dans la zone
de défragmentation client **en avance**, généralement la nuit ou pendant
les périodes de moindre charge. Cela permet une sortie rapide le jour
de l'expédition.
## Caractéristiques
- **Priorité** : basse (s'exécute en arrière-plan)
- **Planification** : horaires configurables par Limagrain
- **Zone cible** : zone défragmentation client (TK02, 03, 04 —
rangées 60-69, profondeurs 2-10)
- **Déclencheur** : stratégie de défragmentation shipping (mode
Shipping, type d'ordre Tournée) avec filtre custom
## Configuration du planning
Limagrain peut modifier les horaires de façon autonome :
1. Menu « Configuration » → « Défragmentation » → « Planning de
défragmentation »
2. Bouton « Ajouter » → paramétrer les horaires/planning souhaités
3. Activer la défragmentation via le bouton « Activer »
## Prérequis
Pour que EasyWMS puisse défragmenter les conteneurs vers la zone client,
il doit exister au moins une **stratégie de défragmentation shipping**
configurée en mode Shipping et type d'ordre Tournée.
## Lien avec l'expédition
La défragmentation est l'étape 4 du flux d'expédition (voir
[Flux expédition](../04-outbound/flux-expedition.md)) :
1. OS reçu et libéré → stock assigné
2. Palettes complètes → défragmentation vers zone client
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)
### Objectif
Déclencher la défragmentation client d'une tournée **uniquement lorsque
toutes ses palettes de tous ses OS sont prêtes à partir vers l'image de
quai**, c'est-à-dire :
- Les palettes complètes (PC) sont dans l'ASRS
- Les palettes ayant nécessité un picking sont revenues dans l'ASRS
après prélèvement (palettes filles PF retournées)
- **Aucun quai n'est encore associé à la tournée** (sinon le flux
shipping standard avec ordonnancement par STOP prend le relais —
voir [Séquençage shipping par STOP](../04-outbound/sequencage-shipping-stop.md))
La condition « toutes les palettes terminées » s'évalue **au niveau de
la tournée** (RUT) : c'est du « tout-ou-rien ».
### Mécanisme
Le custom utilise le **job de défragmentation client standard** avec
une stratégie en mode Shipping et type d'ordre Tournée. Un **filtre
custom au niveau de la sélection des candidats** 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.
### Règle d'éligibilité
```
POUR CHAQUE RUT candidat à la défrag shipping
(standard : exclut les RUT avec quai assigné) :
POUR CHAQUE OS du RUT :
SI l'OS a des lignes picking non terminées → EXCLURE le RUT
SI au moins une palette complète assignée n'est pas dans l'ASRS
→ EXCLURE le RUT
SI aucune exclusion → ÉLIGIBLE
SINON → reste candidat pour le prochain passage du job
```
> **Point clé** : l'éligibilité est « tout-ou-rien » au niveau tournée.
> Tant qu'un seul OS du RUT n'a pas toutes ses palettes prêtes, aucune
> défrag n'est lancée pour le RUT.
### Ordonnancement dans le canal
Les tâches de défrag sont générées avec un tri par **numéro de STOP**
inversé : les palettes du STOP max entrent dans le canal en premier,
celles du STOP 1 en dernier. Ainsi, à la sortie du canal, l'ordre
est respecté (STOP 1 sort en premier).
La décision prise est de ranger **une tournée par canal** (ou plusieurs
canaux si nécessaire) et non un STOP par canal.
### Paramétrage
- **MAX_DEFRAG_ATTEMPT** : nombre max de tentatives par support pour
trouver un emplacement de destination. Le compteur ne s'incrémente
que si le WMS a cherché un emplacement et n'en a pas trouvé. Si le
filtre custom exclut la tournée avant la recherche de destination,
le compteur reste à 0.
> ⚠️ Point ouvert : vérifier si MAX_DEFRAG_ATTEMPT impacte uniquement
> la défrag par rotation ou aussi la défrag client.
### Cas de test
#### Cas nominaux
| CT | Préconditions | Résultat attendu |
|----|--------------|------------------|
| CT-01 | RUT mono-OS, 3 PC dans l'ASRS, aucun quai | Éligible. 3 tâches défrag, tri par séquence STOP |
| CT-02 | RUT mono-OS, 2 PP pickées → 2 PF revenues ASRS, aucun quai | Éligible. 2 tâches défrag pour les PF |
| CT-03 | RUT mono-OS mixte : 2 PC + 1 PF revenue, aucun quai | Éligible. 3 tâches défrag |
| CT-04 | RUT multi-OS (STOP 1, 2, 3), 2 PC chacun, aucun quai | Éligible. 6 tâches, STOP 3 entre en premier dans le canal |
| CT-05 | RUT multi-OS mixte, tous prêts, aucun quai | Éligible en un seul passage |
#### Cas limites
| CT | Préconditions | Résultat attendu |
|----|--------------|------------------|
| CT-06 | RUT 2 OS : SOR1 prêt, SOR2 a 1 PF non revenue | **NON éligible** — un OS bloque tout le RUT |
| CT-07 | RUT multi-OS, 1 PF en transit AGV vers ASRS | **NON éligible** tant que PF pas physiquement stockée dans un emplacement ASRS |
| CT-08 | RUT prêt mais quai déjà assigné | **NON éligible** pour le custom défrag. Flux shipping standard prend le relais |
| CT-09 | RUT 1 SOR, 3 lignes picking : 2 PF revenues, 1 PP au PK | **NON éligible** — on attend la totalité |
#### Cas dégradés
| CT | Préconditions | Résultat attendu |
|----|--------------|------------------|
| CT-11 | AGV HS pendant retour PF → ASRS | **NON éligible** tant que PF pas dans l'ASRS. Redevient éligible après remise en route |
| CT-12 | PP en litige, stock réassigné sur PP' | Éligible quand toutes les palettes (y compris réassignations) sont dans l'ASRS |
| CT-13 | Rupture de stock sur un OS de la tournée | **À trancher** — voir point ouvert ci-dessous |
| CT-14 | Bouton « Problème » au picking, OnStockAdjust recalcule | Si stock suffisant : PF revient, RUT éligible. Si réassignation : attente nouvelle PF' |
| CT-15 | RUT libéré, aucune tâche picking jamais générée | **À trancher** — non éligible par défaut |
| CT-16 | Nouveau SOR ajouté à un RUT déjà éligible | **Redevient NON éligible** jusqu'à ce que le nouveau SOR soit terminé |
## Pause et reprise
Le processus peut être mis en pause et repris ultérieurement en cas de
reprise d'activité (par exemple si l'activité reprend la nuit).
## Points d'attention
⚠️ 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
en cas de défaut sur les transstockeurs (non obligatoire).
⚠️ L'avancée des tâches est consultable sur la vue des tâches.
⚠️ Le filtre custom n'incrémente pas MAX_DEFRAG_ATTEMPT quand il
exclut un RUT — le compteur ne démarre que lors d'une recherche
effective de destination.
## Questions ouvertes
- [ ] Comportement en cas de **rupture de stock** sur un OS de la
tournée (CT-13) : option A (RUT reste non éligible, attend un
nouveau SOR sans les lignes concernées) ou option B (défrag lancée
sur les palettes disponibles) ? (@Justine — à vérifier avec client)
→ voir [Questions ouvertes](../08-transverse/questions-ouvertes.md)
- [ ] **MAX_DEFRAG_ATTEMPT** : impacte-t-il uniquement la défrag par
rotation ou aussi la défrag client ? (@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-05-12 | Arthur | Ajout custom défrag client par tournée (LIM-85/LIM-87) : mécanisme, éligibilité, cas de test, points ouverts |
## 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 | 2026 |
| [LIM-87](https://easywmsfrance.atlassian.net/browse/LIM-87) | Ticket Jira | 2026 |
wiki_old_13-05-2026/limagrain/02-stockage/.fuse_hidden000000230000000a
+143
View File
@@ -0,0 +1,143 @@
---
title: "Configuration Galileo — Limagrain"
tags: [stockage, galileo, TMS, architecture, IT]
status: draft
standard_ref: architecture/galileo-integration.md
jira_refs: []
confluence_refs: []
sources: [FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5.docx]
last_updated: 2026-05-05
author: Arthur
---
# Configuration Galileo — Limagrain
> **Résumé** : architecture logicielle IT de l'installation Limagrain et
> spécificités de la configuration Galileo (TMS).
> **Standard EasyWMS** : → voir [GALILEO Integration](../../architecture/galileo-integration.md),
> [System Architecture](../../architecture/overview.md)
> Ce qui suit documente les **spécificités Limagrain** par rapport au standard.
## Contexte projet
EasyWMS gère l'entrepôt automatique Limagrain avec une base Oracle. Le TMS
Galileo contrôle les 4 transstockeurs, les convoyeurs, navettes et stations
PIE. Les AGV sont gérés par un fournisseur tiers (non Galileo).
## Architecture logicielle
```mermaid
graph TD
SAP[SAP EWM] -->|XML / Webservice| GNA[EasyWMS GNA]
GNA --> EWMS[EasyWMS Serveur]
EWMS --> BBDD[(Oracle DB)]
EWMS --> GW[EasyWMS Gateway]
GW -->|TCP 3000| GAL[Galileo TMS]
GAL --> TK[Transstockeurs x4]
GAL --> CONV[Convoyeurs]
GAL --> NAV[Navettes]
GAL --> PIE[Stations PIE x3]
EWMS --> LP[Label Printer Service]
EWMS --> WEB[Application Web EasyWMS]
EWMS --> PC[Application PC EasyWMS]
WEB --> TRF[Terminaux RF]
AGV[AGV - Fournisseur tiers] -.->|Interface séparée| EWMS
```
### Composants serveur EasyWMS
| Composant | Rôle |
|-----------|------|
| Application serveur EasyWMS | Services de logique et gestion |
| Oracle DB | Base de données |
| EasyWMS GNA | Communication ERP (SAP) via XML/Webservice |
| EasyWMS Gateway | Communication Galileo (protocole frames TCP) |
| EasyWMS Label Printer | Impression étiquettes et documents |
### Communication ERP
- **Protocole** : XML + Webservice
- **ERP** : SAP EWM
- **Direction** : bidirectionnelle (voir [Messages ERP](../06-erp-interface/messages-reference.md))
## Stations PIE — Configuration spécifique
3 stations PIE installées :
| Station | Côté | Usage principal |
|---------|------|----------------|
| PIE_01 | Quais (production) | Réception production directe |
| PIE_02 | Postes de travail | Réception ext./retours après traitement |
| PIE_03 | Postes de travail | Idem PIE_02 |
### Mode d'insertion PIE
- **Mode normal** (known containers) : rejet si RFID inconnue
- [CUSTOM] Pas de message ASO au passage PIE
- [CUSTOM] Vérification poids avec tolérances par type article
- [CUSTOM] Mise à jour du « Poids de l'unité » du conteneur à chaque passage
### Contrôle au PIE
| Contrôle | Valeur limite |
|----------|---------------|
| Dimensions max | 1300 × 1100 × 1900 mm |
| Poids max | 1250 kg |
| État palette bois | Correct (visuel Galileo) |
| Lecture RFID | Obligatoire — doit être connue (ASN) |
## Flux physiques dans l'entrepôt
Les flux sont majoritairement réalisés par des **AGV** (fournisseur tiers).
EasyWMS communique les points de prise et de dépose ; le sens de prise/dépose
est géré par le fournisseur AGV.
Deux entrées dans l'ASRS :
| Entrée | Côté | Usage |
|--------|------|-------|
| Entrée production | Quais (PIE_01) | Palettes production, palettes vides |
| Entrée postes de travail | Postes (PIE_02/03) | Palettes après traitement en poste |
> En cas de blocage long terme sur une entrée, un bouton permet de
> rediriger les flux vers l'autre entrée.
## Rétention des données
| Entité | Durée standard | Souhait Limagrain |
|--------|----------------|-------------------|
| Transactions | 6 mois | 2 ans |
| Movements | 6 mois | 2 ans |
| Outbound Orders | 1 an | 2 ans |
| Inbound Orders | 1 an | 2 ans |
| Tasks | 1 an | 2 ans |
| Stock adjustments | 1 an | 2 ans |
> ⚠️ Mecalux doit étudier l'impact de la rétention 2 ans sur les prérequis
> serveurs pour éviter saturation DB et lenteurs.
## Points d'attention
⚠️ Les interfaces AGV sont définies dans un document annexe séparé et
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.
## Questions ouvertes
- [ ] Impact rétention 2 ans sur les performances Oracle (@Nicolas)
- [ ] 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 |
## Références
| Source | Type | Date |
|--------|------|------|
| FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5 | Analyse fonctionnelle | 28/11/2025 |
wiki_old_13-05-2026/limagrain/02-stockage/.fuse_hidden000000250000000b
+124
View File
@@ -0,0 +1,124 @@
---
title: "Gestion des palettes vides"
tags: [stockage, palettes-vides, réapprovisionnement, expédition]
status: draft
standard_ref: concepts/container-management.md
jira_refs: []
confluence_refs: []
sources: [FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5.docx, "Réception - LIMAGRAIN - DEV - Confluence.md"]
last_updated: 2026-05-05
author: Arthur
---
# Gestion des palettes vides
> **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-management.md)
> Ce qui suit documente les **spécificités Limagrain** par rapport au standard.
## 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
façon unitaire.
## Typologie
- Dimensions : US (1000 × 1200 mm)
- Type unique : NIMP15
- Stockage : piles de **10 palettes vides**
## Réception
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é —
contrainte de hauteur). Aucun scan demandé. Pas de passage par poste
de travail. Destination : stockage direct dans l'ASRS.
> **Remarque** : en cas de blocage long terme sur l'entrée quai, un bouton
> permet de rediriger manuellement les palettes vers l'entrée « Postes de
> travail ».
## Stockage
### Dans l'ASRS
- Priorité : allées 2, 3 et 4 (TK02-04)
- 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
- Consultation : vue des stocks avec filtre sur l'article « palettes vides »
### Au niveau des postes de travail
- **2 piles par îlot de travail** (et non par poste individuel)
- Création d'un **emplacement picking dédié** pour chaque emplacement
physique accueillant les stocks de palettes vides (permet le
réapprovisionnement automatique sur seuil)
## Réapprovisionnement
### Sur poste de travail
- Chaque poste est équipé d'une aide à la manutention (prise palette
sur la pile → dépose sur table de préparation)
- Action **manuelle**, non pilotée par EasyWMS
- En cas de regroupement : l'opérateur peut reposer une palette vide
sur la pile
> ⚠️ La pile doit être parfaitement remontée pour passer le contrôle
> gabarit au PIE.
[CUSTOM] Quand la pile est vide :
- **Bouton WfAction** dans la workstation pour demander le
réapprovisionnement
- L'opérateur choisit la pile à réapprovisionner parmi une liste
(paramètre par PK avec noms des emplacements)
- Quand l'emplacement devient vide (via bouton WfAction) →
réapprovisionnement automatique déclenché
- Bouton inverse pour renvoyer une pile au stockage
### Sur le poumon
- Réapprovisionnement **automatique** des 2 emplacements poumon quand
un emplacement est vidé (tâche depuis ASRS)
## Expédition
Les piles de palettes vides peuvent être expédiées :
1. Création **manuelle** d'un ordre de sortie
2. Renseigner la destination : table de préparation (poste) OU image de quai
3. Une fois expédiées → sorties des stocks EasyWMS
## Points d'attention
⚠️ 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
sur l'article spécifique des palettes vides.
⚠️ La pile doit être correctement empilée pour ne pas être rejetée
au PIE (contrôle gabarit).
## Historique des modifications
| Date | Auteur | Modification |
|------|--------|--------------|
| 2026-05-05 | Arthur | Création initiale depuis AF V1.5 |
| 2026-05-05 | Arthur | Enrichissement : emplacement picking dédié, 2 piles/îlot, WfAction |
## Références
| Source | Type | Date |
|--------|------|------|
| FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5 | Analyse fonctionnelle | 28/11/2025 |
| Réception - LIMAGRAIN - DEV - Confluence | Page ateliers DEV | 2026 |
wiki_old_13-05-2026/limagrain/02-stockage/.fuse_hidden000000270000000c
+154
View File
@@ -0,0 +1,154 @@
---
title: "Processus d'anoxie — TK01"
tags: [stockage, anoxie, TK01, flag, custom, processus]
status: draft
standard_ref: concepts/warehouse-processes.md
jira_refs: []
confluence_refs: []
sources: [FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5.docx]
last_updated: 2026-05-05
author: Arthur
---
# 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.
> **Standard EasyWMS** : → voir [Warehouse Processes](../../concepts/warehouse-processes.md)
> Ce qui suit documente les **spécificités Limagrain** par rapport au standard.
## Contexte projet
L'anoxie consiste à baisser le niveau d'oxygène dans l'allée 1 (TK01)
pour éliminer d'éventuels nuisibles dans les semences. Ce processus est
spécifique au domaine des semences et n'existe pas dans le standard EasyWMS.
## Caractéristiques
- **Localisation** : allée 1 uniquement (TK01)
- **Durée** : 3 à 4 semaines en moyenne
- **Fréquence** : 2 fois par an
- **Déclenchement** : manuel
- **Impact** : allée et stock bloqués pendant toute la durée
En dehors des périodes d'anoxie, la zone est utilisée pour du stockage
normal en priorisant les palettes à anoxier. Chaque compartiment a un
taux d'oxygène contrôlé.
## [CUSTOM] Flag « A anoxier »
### Attribution automatique
Tous les stocks des palettes issues des processus suivants reçoivent
automatiquement le flag « A anoxier » car elles présentent des risques
de contamination :
- Réceptions extérieures / intersites
- Retours client
Condition : la palette doit passer par un poste de travail.
### Attribution manuelle
Il est également possible d'assigner le flag manuellement sur des stocks
spécifiques depuis la vue des stocks.
### Retrait du flag
- **Automatique** : à la fin du processus d'anoxie (bouton « Fin d'anoxie »)
- **Manuel** : par un utilisateur, qui devra saisir une date de dernière
anoxie
## 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
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 »
## Processus complet
```mermaid
flowchart TD
START[Décision lancer anoxie] --> SEL1[1. Sélection palettes à évacuer de TK01]
SEL1 --> RELOC1[Relocalisation vers TK02-04]
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]
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
- 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
- Sélection manuelle des palettes avec flag « A anoxier »
- Relocalisation vers TK01 dans la mesure des emplacements disponibles
[CUSTOM] Les étapes 1 et 2 peuvent être **automatisées** afin de créer
automatiquement les tâches de relocalisation.
### É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
- [CUSTOM] Bouton « Fin d'anoxie » qui :
- Met à jour la date de dernière anoxie
- Supprime automatiquement le flag « A anoxier » pour chaque ligne
de stock présente dans l'allée
- Déblocage manuel de l'allée 01
## Suivi et rapports
- Extraction de la vue des stocks avec filtres « A anoxier » et
« date de dernière anoxie » pour établir le rapport souhaité
- L'avancée des tâches de relocalisation est consultable sur la vue
des tâches
## Lien avec les stratégies de rangement
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).
## Points d'attention
⚠️ La relocalisation peut prendre un temps significatif selon les
quantités sélectionnées.
⚠️ MECALUX conseille d'avoir une personne sur site lors du lancement
de la défragmentation/relocalisation en cas de défaut sur les
transstockeurs (non obligatoire).
⚠️ Le processus d'anoxie peut être mis en pause et repris ultérieurement
en cas de reprise d'activité.
## Questions ouvertes
- [ ] Automatisation étapes 1 et 2 — développement custom validé ? (@Nicolas)
- [ ] Interface du bouton « Fin d'anoxie » — écran dédié ou menu existant ? (@Fabien)
## Historique des modifications
| Date | Auteur | Modification |
|------|--------|--------------|
| 2026-05-05 | Arthur | Création initiale depuis AF V1.5 |
## Références
| Source | Type | Date |
|--------|------|------|
| FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5 | Analyse fonctionnelle | 28/11/2025 |
wiki_old_13-05-2026/limagrain/02-stockage/.fuse_hidden000000290000000d
+113
View File
@@ -0,0 +1,113 @@
---
title: "Stratégies de rangement Limagrain"
tags: [stockage, putaway, stratégie, rangement, canaux]
status: draft
standard_ref: concepts/putaway.md
jira_refs: []
confluence_refs: []
sources: [FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5.docx]
last_updated: 2026-05-05
author: Arthur
---
# Stratégies de rangement Limagrain
> **Résumé** : 5 stratégies de rangement distinctes selon la typologie de la
> palette, avec des règles de sélection de canal et d'allée spécifiques.
> **Standard EasyWMS** : → voir [Putaway](../../concepts/putaway.md)
> Ce qui suit documente les **spécificités Limagrain** par rapport au standard.
## 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
sur la nature fonctionnelle de la palette.
## 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) |
| 2 | TK01 — canal vide |
| 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 »
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 |
| 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 »
| Priorité | Règle |
|----------|-------|
| 1 | Canal incomplet mixte |
| 2 | Canal vide |
| 3 | Canal incomplet (tout) |
| 4 | REJET |
## 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 |
| 2 | Canal vide — zone défragmentation client |
| 3 | PAS DE MOUVEMENT (palette reste en place) |
## Stratégie 5 — Piles de palettes vides
Article type « Palette » (NIMP15).
| Priorité | Règle |
|----------|-------|
| 1 | Canal incomplet le plus proche de l'entrée avec piles de palettes vides |
| 2 | Canal vide le plus proche de l'entrée (hors TK01) |
| 3 | Canal incomplet (tout) |
| 4 | REJET |
## Critères transverses
- **Réservation de canal** : le nombre de palettes en ASN non encore reçues
détermine la capacité optimale du canal à réserver (stratégie 2)
- **Équilibrage inter-allées** : pour les palettes mono lot, EasyWMS répartit
le stock entre allées différentes quand un canal plein existe déjà
- **Hauteur** : la hauteur de la première palette au PIE détermine le type
de rack compatible (RACK01 ≤1150, RACK02 ≤1950, RACK03 ≤2250)
## Points d'attention
⚠️ Si aucun emplacement n'est trouvé → palette rejetée vers le poste de
rejet configuré (sauf stratégie 4 où la palette reste sur place).
⚠️ Les palettes d'expédition ne sont déplacées en zone défragmentation
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.
## Historique des modifications
| Date | Auteur | Modification |
|------|--------|--------------|
| 2026-05-05 | Arthur | Création initiale depuis AF V1.5 |
## Références
| Source | Type | Date |
|--------|------|------|
| FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5 | Analyse fonctionnelle | 28/11/2025 |
wiki_old_13-05-2026/limagrain/02-stockage/.fuse_hidden0000002b0000000e
+85
View File
@@ -0,0 +1,85 @@
---
title: "Zones de stockage Limagrain"
tags: [stockage, zones, anoxie, défragmentation, ASRS]
status: draft
standard_ref: concepts/putaway.md
jira_refs: []
confluence_refs: []
sources: [FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5.docx]
last_updated: 2026-05-05
author: Arthur
---
# Zones de stockage Limagrain
> **Résumé** : Limagrain dispose de 3 zones de stockage dans l'ASRS, chacune
> avec un rôle spécifique : anoxie, stockage principal, défragmentation client.
> **Standard EasyWMS** : → voir [Putaway](../../concepts/putaway.md),
> [Location](../../concepts/location.md)
> Ce qui suit documente les **spécificités Limagrain** par rapport au standard.
## Contexte projet
L'entrepôt automatique Limagrain comporte **4 allées** (TK_01 à TK_04). Les
zones de stockage ont été définies pour répondre à deux besoins métier :
1. **Anoxie** : traitement insecticide par réduction d'oxygène sur TK_01
2. **Défragmentation client** : pré-positionnement des palettes assignées à
une route avant expédition (optimise les temps de sortie)
## Configuration des zones
| Zone | Transstockeur | X initial | X final | Y initial | Y final |
|------|---------------|-----------|---------|-----------|---------|
| Zone Anoxie | TK_01 | 1 | 69 | 1 | 10 |
| Zone Principale | TK_02, 03 & 04 | 1 | 59 | 1 | 10 |
| Zone Principale (ext.) | TK_02, 03 & 04 | 60 | 69 | 1 | 1 |
| Zone Défragmentation client | TK_02, 03 & 04 | 60 | 69 | 2 | 10 |
> ⚠️ Cette répartition peut être modifiée par un administrateur Limagrain
> selon les besoins opérationnels.
## Comportement par zone
### Zone Anoxie (TK_01)
- 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](../../limagrain/08-transverse/decisions-architecture.md)
### Zone Principale (TK_02, 03 & 04)
- Stockage général : articles et piles de palettes vides
- Pas de distinction de classe de rotation (pas d'ABC)
- Stratégie de répartition inter-allées pour équilibrer la charge
### Zone Défragmentation client (TK_02, 03 & 04, X=60-69, Y=2-10)
- Palettes assignées à un ordre de sortie (post stock assignment)
- Regroupement par route/stop pour optimiser le séquencement à l'expédition
- Les palettes y sont déplacées automatiquement après libération de l'OS
## Points d'attention
⚠️ Les piles de palettes vides sont stockées en priorité dans les allées
02, 03 & 04, au plus proche des entrées/sorties (canaux bas en X).
⚠️ Le convoyeur de sortie TS01 dans TK_01 crée une **exception de stockage** :
pas de canaux en X=21/Y=1, X=21/Y=2, X=22/Y=1.
⚠️ Taux minimum de 5% d'emplacements libres recommandé par Mecalux pour
la défragmentation et les relocalisations.
## Historique des modifications
| Date | Auteur | Modification |
|------|--------|--------------|
| 2026-05-05 | Arthur | Création initiale depuis AF V1.5 |
## Références
| Source | Type | Date |
|--------|------|------|
| FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5 | Analyse fonctionnelle | 28/11/2025 |
wiki_old_13-05-2026/limagrain/02-stockage/.fuse_hidden0000002d0000000f
+48
View File
@@ -0,0 +1,48 @@
---
title: "Stockage — Vue d'ensemble"
tags: [stockage, asrs, galileo, index]
status: draft
last_updated: 2026-05-05
---
# Stockage — Vue d'ensemble
> **Périmètre** : miniload, transstockeurs, stations Galileo, stratégies de
> putaway, zones de stockage, défragmentation.
> **Standard EasyWMS** : voir [Storage](../../concepts/storage.md),
> [Galileo Integration](../../architecture/galileo-integration.md)
## Pages de cette section
- [ASRS / Miniload](asrs-miniload.md)
- [Configuration Galileo](galileo-config.md)
- [Stratégies de putaway](putaway-strategies.md)
- [Zones de stockage](zones-stockage.md)
- [Défragmentation](defragmentation.md)
- [Processus d'anoxie](processus-anoxie.md)
- [Gestion des palettes vides](palettes-vides.md)
## Vue synthétique du stockage Limagrain
```mermaid
graph LR
subgraph ASRS MAG01
TK1[TK_01<br/>Zone Anoxie]
TK2[TK_02]
TK3[TK_03]
TK4[TK_04]
end
subgraph Zones
ZA[Zone Anoxie<br/>TK01 X1-69 Y1-10]
ZP[Zone Principale<br/>TK02-04 X1-59 Y1-10<br/>+ X60-69 Y1]
ZD[Zone Défrag. Client<br/>TK02-04 X60-69 Y2-10]
end
TK1 --- ZA
TK2 --- ZP
TK3 --- ZP
TK4 --- ZP
TK2 --- ZD
TK3 --- ZD
TK4 --- ZD
```
wiki_old_13-05-2026/limagrain/02-stockage/_index.md
+48
View File
@@ -0,0 +1,48 @@
---
title: "Stockage — Vue d'ensemble"
tags: [stockage, asrs, galileo, index]
status: draft
last_updated: 2026-05-05
---
# Stockage — Vue d'ensemble
> **Périmètre** : miniload, transstockeurs, stations Galileo, stratégies de
> putaway, zones de stockage, défragmentation.
> **Standard EasyWMS** : voir [Storage](../../concepts/stock.md),
> [Galileo Integration](../../architecture/galileo-integration.md)
## Pages de cette section
- [ASRS / Miniload](asrs-miniload.md)
- [Configuration Galileo](galileo-config.md)
- [Stratégies de putaway](putaway-strategies.md)
- [Zones de stockage](zones-stockage.md)
- [Défragmentation](defragmentation.md)
- [Processus d'anoxie](processus-anoxie.md)
- [Gestion des palettes vides](palettes-vides.md)
## Vue synthétique du stockage Limagrain
```mermaid
graph LR
subgraph ASRS MAG01
TK1[TK_01<br/>Zone Anoxie]
TK2[TK_02]
TK3[TK_03]
TK4[TK_04]
end
subgraph Zones
ZA[Zone Anoxie<br/>TK01 X1-69 Y1-10]
ZP[Zone Principale<br/>TK02-04 X1-59 Y1-10<br/>+ X60-69 Y1]
ZD[Zone Défrag. Client<br/>TK02-04 X60-69 Y2-10]
end
TK1 --- ZA
TK2 --- ZP
TK3 --- ZP
TK4 --- ZP
TK2 --- ZD
TK3 --- ZD
TK4 --- ZD
```
wiki_old_13-05-2026/limagrain/02-stockage/asrs-miniload.md
+107
View File
@@ -0,0 +1,107 @@
---
title: "ASRS — Entrepôt automatique Limagrain"
tags: [stockage, ASRS, transstockeur, racks, emplacements]
status: draft
standard_ref: architecture/galileo-integration.md
jira_refs: []
confluence_refs: []
sources: [FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5.docx]
last_updated: 2026-05-05
author: Arthur
---
# ASRS — Entrepôt automatique Limagrain
> **Résumé** : description de l'installation automatique Limagrain : 4 allées
> de transstockeurs, racks multi-profondeur, nomenclature des emplacements,
> types de conteneurs et dimensions.
> **Standard EasyWMS** : → voir [GALILEO Integration](../../architecture/galileo-integration.md),
> [Location](../../concepts/location.md)
> Ce qui suit documente les **spécificités Limagrain** par rapport au standard.
## Contexte projet
Limagrain dispose d'un magasin automatique **MAG01** composé de 4 allées de
transstockeurs gérées par EasyWMS. L'entrepôt stocke essentiellement des
graines (sacs, big-bags) sur palettes US.
## Organisation EasyWMS
| Code | Description |
|------|-------------|
| **LM** | Organisation LIMAGRAIN |
| **MAG01** | Magasin automatique — 4 allées |
## Racks et capacités
| Type rack | X Initial | X Final | Y Initial | Y Final | Hauteur (mm) | Palette |
|-----------|-----------|---------|-----------|---------|--------------|---------|
| RACK01 | 1 | 69 | 1 | 1 | 1150 | US (1000×1200) |
| RACK02 | 1 | 69 | 2 | 8 | 1950 | US (1000×1200) |
| RACK03 | 1 | 69 | 9 | 10 | 2250 | US (1000×1200) |
## Nomenclature des emplacements
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 |
| 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, ...) |
**Exemple** : `00100300721` = allée 1, colonne 3, hauteur 7, côté droit,
profondeur 1.
> Un emplacement EasyWMS correspond à un **canal complet** de rangement de
> palettes (multi-profondeur).
## Type de conteneur unique
| Type | Largeur (mm) | Longueur (mm) | Hauteur (mm) | Poids max (kg) |
|------|--------------|---------------|--------------|----------------|
| 1 — Palette US | 1000 | 1200 | 800 à 1900 | 1250 |
## Contrôles au PIE
Au passage PIE, Galileo vérifie :
- Dimensions max : 1300 × 1100 × 1900 mm
- Poids max : 1250 kg
- État de la palette bois
- Lecture étiquette RFID (code barre / QR)
Si un critère n'est pas respecté → rejet vers poste de reconditionnement
ou poste de travail d'origine.
## Exceptions de stockage
Le convoyeur de sortie **TS01** dans l'allée TK_01 occupe physiquement des
emplacements rack. Canaux indisponibles :
- X=21, Y=1
- X=21, Y=2
- X=22, Y=1
## Points d'attention
⚠️ Un seul type de conteneur (palette US) simplifie les stratégies mais
les hauteurs variables (800–1900 mm) impactent le choix du rack (RACK01/02/03).
⚠️ La hauteur PLC déterminée au PIE pilote le choix du niveau de stockage
(Y=1 pour ≤1150, Y=2-8 pour ≤1950, Y=9-10 pour ≤2250).
## Historique des modifications
| Date | Auteur | Modification |
|------|--------|--------------|
| 2026-05-05 | Arthur | Création initiale depuis AF V1.5 |
## Références
| Source | Type | Date |
|--------|------|------|
| FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5 | Analyse fonctionnelle | 28/11/2025 |
wiki_old_13-05-2026/limagrain/02-stockage/defragmentation.md
+66
View File
@@ -0,0 +1,66 @@
---
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
author: Arthur
---
# 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.
> Inclut un **custom majeur** de défragmentation par tournée (RUT) avec
> ordonnancement par numéro de STOP, déclenché uniquement quand toutes
> les palettes sont prêtes et qu'aucun quai n'est assigné.
> **Standard EasyWMS** : → voir [Defragmentation](../../concepts/defragmentation.md)
> Ce qui suit documente les **spécificités Limagrain** par rapport au
> standard.
## Contexte projet
La défragmentation est un processus standard des entrepôts automatisés.
Chez Limagrain, elle sert à préparer les routes (expéditions) en
déplaçant les conteneurs vers la zone de défragmentation client
(TK02-04, rangées 60-69).
La défragmentation shipping standard propose trois modes d'assignation
(Picking Only, Shipping Only, Picking & Shipping) mais **aucun ne
répond au besoin Limagrain** :
| Mode standard | Comportement | Problème |
|---------------|-------------|----------|
| 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 | — |
**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
sorte que les palettes sortent du canal dans le bon ordre lors du
chargement camion (STOP max chargé en premier → déchargé en dernier).
Deux cas se présentent selon l'assignation du quai :
| Situation | Custom | Page |
|-----------|--------|------|
| Quai **non assigné** au RUT | Défrag custom décrite ci-dessous | Cette page |
| Quai **déjà assigné** au RUT | Override du WF stacker crane | → voir [Séquençage shipping par STOP](../04-outbound/sequencage-shipping-stop.md) |
## Principe général
Les conteneurs assignés à une expédition sont relocalisés dans la zone
de défragmentation client **en avance**, généralement la nuit ou pendant
les périodes de moindre charge. Cela permet une sortie rapide le jour
de l'expédition.
## Caractéristiques
- **Priorité** : basse (s'exécute en arrière-plan)
- **Planification** : horaires configurables par Limagrain
- **Zone cible** : zone défragmentation client (TK02, 03, 04 —
rangées 6
wiki_old_13-05-2026/limagrain/02-stockage/galileo-config.md
+143
View File
@@ -0,0 +1,143 @@
---
title: "Configuration Galileo — Limagrain"
tags: [stockage, galileo, TMS, architecture, IT]
status: draft
standard_ref: architecture/galileo-integration.md
jira_refs: []
confluence_refs: []
sources: [FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5.docx]
last_updated: 2026-05-05
author: Arthur
---
# Configuration Galileo — Limagrain
> **Résumé** : architecture logicielle IT de l'installation Limagrain et
> spécificités de la configuration Galileo (TMS).
> **Standard EasyWMS** : → voir [GALILEO Integration](../../architecture/galileo-integration.md),
> [System Architecture](../../architecture/overview.md)
> Ce qui suit documente les **spécificités Limagrain** par rapport au standard.
## Contexte projet
EasyWMS gère l'entrepôt automatique Limagrain avec une base Oracle. Le TMS
Galileo contrôle les 4 transstockeurs, les convoyeurs, navettes et stations
PIE. Les AGV sont gérés par un fournisseur tiers (non Galileo).
## Architecture logicielle
```mermaid
graph TD
SAP[SAP EWM] -->|XML / Webservice| GNA[EasyWMS GNA]
GNA --> EWMS[EasyWMS Serveur]
EWMS --> BBDD[(Oracle DB)]
EWMS --> GW[EasyWMS Gateway]
GW -->|TCP 3000| GAL[Galileo TMS]
GAL --> TK[Transstockeurs x4]
GAL --> CONV[Convoyeurs]
GAL --> NAV[Navettes]
GAL --> PIE[Stations PIE x3]
EWMS --> LP[Label Printer Service]
EWMS --> WEB[Application Web EasyWMS]
EWMS --> PC[Application PC EasyWMS]
WEB --> TRF[Terminaux RF]
AGV[AGV - Fournisseur tiers] -.->|Interface séparée| EWMS
```
### Composants serveur EasyWMS
| Composant | Rôle |
|-----------|------|
| Application serveur EasyWMS | Services de logique et gestion |
| Oracle DB | Base de données |
| EasyWMS GNA | Communication ERP (SAP) via XML/Webservice |
| EasyWMS Gateway | Communication Galileo (protocole frames TCP) |
| EasyWMS Label Printer | Impression étiquettes et documents |
### Communication ERP
- **Protocole** : XML + Webservice
- **ERP** : SAP EWM
- **Direction** : bidirectionnelle (voir [Messages ERP](../06-erp-interface/messages-reference.md))
## Stations PIE — Configuration spécifique
3 stations PIE installées :
| Station | Côté | Usage principal |
|---------|------|----------------|
| PIE_01 | Quais (production) | Réception production directe |
| PIE_02 | Postes de travail | Réception ext./retours après traitement |
| PIE_03 | Postes de travail | Idem PIE_02 |
### Mode d'insertion PIE
- **Mode normal** (known containers) : rejet si RFID inconnue
- [CUSTOM] Pas de message ASO au passage PIE
- [CUSTOM] Vérification poids avec tolérances par type article
- [CUSTOM] Mise à jour du « Poids de l'unité » du conteneur à chaque passage
### Contrôle au PIE
| Contrôle | Valeur limite |
|----------|---------------|
| Dimensions max | 1300 × 1100 × 1900 mm |
| Poids max | 1250 kg |
| État palette bois | Correct (visuel Galileo) |
| Lecture RFID | Obligatoire — doit être connue (ASN) |
## Flux physiques dans l'entrepôt
Les flux sont majoritairement réalisés par des **AGV** (fournisseur tiers).
EasyWMS communique les points de prise et de dépose ; le sens de prise/dépose
est géré par le fournisseur AGV.
Deux entrées dans l'ASRS :
| Entrée | Côté | Usage |
|--------|------|-------|
| Entrée production | Quais (PIE_01) | Palettes production, palettes vides |
| Entrée postes de travail | Postes (PIE_02/03) | Palettes après traitement en poste |
> En cas de blocage long terme sur une entrée, un bouton permet de
> rediriger les flux vers l'autre entrée.
## Rétention des données
| Entité | Durée standard | Souhait Limagrain |
|--------|----------------|-------------------|
| Transactions | 6 mois | 2 ans |
| Movements | 6 mois | 2 ans |
| Outbound Orders | 1 an | 2 ans |
| Inbound Orders | 1 an | 2 ans |
| Tasks | 1 an | 2 ans |
| Stock adjustments | 1 an | 2 ans |
> ⚠️ Mecalux doit étudier l'impact de la rétention 2 ans sur les prérequis
> serveurs pour éviter saturation DB et lenteurs.
## Points d'attention
⚠️ Les interfaces AGV sont définies dans un document annexe séparé et
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.
## Questions ouvertes
- [ ] Impact rétention 2 ans sur les performances Oracle (@Nicolas)
- [ ] 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 |
## Références
| Source | Type | Date |
|--------|------|------|
| FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5 | Analyse fonctionnelle | 28/11/2025 |
wiki_old_13-05-2026/limagrain/02-stockage/palettes-vides.md
+124
View File
@@ -0,0 +1,124 @@
---
title: "Gestion des palettes vides"
tags: [stockage, palettes-vides, réapprovisionnement, expédition]
status: draft
standard_ref: concepts/container-management.md
jira_refs: []
confluence_refs: []
sources: [FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5.docx, "Réception - LIMAGRAIN - DEV - Confluence.md"]
last_updated: 2026-05-05
author: Arthur
---
# Gestion des palettes vides
> **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)
> Ce qui suit documente les **spécificités Limagrain** par rapport au standard.
## 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
façon unitaire.
## Typologie
- Dimensions : US (1000 × 1200 mm)
- Type unique : NIMP15
- Stockage : piles de **10 palettes vides**
## Réception
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é —
contrainte de hauteur). Aucun scan demandé. Pas de passage par poste
de travail. Destination : stockage direct dans l'ASRS.
> **Remarque** : en cas de blocage long terme sur l'entrée quai, un bouton
> permet de rediriger manuellement les palettes vers l'entrée « Postes de
> travail ».
## Stockage
### Dans l'ASRS
- Priorité : allées 2, 3 et 4 (TK02-04)
- 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
- Consultation : vue des stocks avec filtre sur l'article « palettes vides »
### Au niveau des postes de travail
- **2 piles par îlot de travail** (et non par poste individuel)
- Création d'un **emplacement picking dédié** pour chaque emplacement
physique accueillant les stocks de palettes vides (permet le
réapprovisionnement automatique sur seuil)
## Réapprovisionnement
### Sur poste de travail
- Chaque poste est équipé d'une aide à la manutention (prise palette
sur la pile → dépose sur table de préparation)
- Action **manuelle**, non pilotée par EasyWMS
- En cas de regroupement : l'opérateur peut reposer une palette vide
sur la pile
> ⚠️ La pile doit être parfaitement remontée pour passer le contrôle
> gabarit au PIE.
[CUSTOM] Quand la pile est vide :
- **Bouton WfAction** dans la workstation pour demander le
réapprovisionnement
- L'opérateur choisit la pile à réapprovisionner parmi une liste
(paramètre par PK avec noms des emplacements)
- Quand l'emplacement devient vide (via bouton WfAction) →
réapprovisionnement automatique déclenché
- Bouton inverse pour renvoyer une pile au stockage
### Sur le poumon
- Réapprovisionnement **automatique** des 2 emplacements poumon quand
un emplacement est vidé (tâche depuis ASRS)
## Expédition
Les piles de palettes vides peuvent être expédiées :
1. Création **manuelle** d'un ordre de sortie
2. Renseigner la destination : table de préparation (poste) OU image de quai
3. Une fois expédiées → sorties des stocks EasyWMS
## Points d'attention
⚠️ 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
sur l'article spécifique des palettes vides.
⚠️ La pile doit être correctement empilée pour ne pas être rejetée
au PIE (contrôle gabarit).
## Historique des modifications
| Date | Auteur | Modification |
|------|--------|--------------|
| 2026-05-05 | Arthur | Création initiale depuis AF V1.5 |
| 2026-05-05 | Arthur | Enrichissement : emplacement picking dédié, 2 piles/îlot, WfAction |
## Références
| Source | Type | Date |
|--------|------|------|
| FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5 | Analyse fonctionnelle | 28/11/2025 |
| Réception - LIMAGRAIN - DEV - Confluence | Page ateliers DEV | 2026 |
wiki_old_13-05-2026/limagrain/02-stockage/processus-anoxie.md
+154
View File
@@ -0,0 +1,154 @@
---
title: "Processus d'anoxie — TK01"
tags: [stockage, anoxie, TK01, flag, custom, processus]
status: draft
standard_ref: concepts/warehouse-processes.md
jira_refs: []
confluence_refs: []
sources: [FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5.docx]
last_updated: 2026-05-05
author: Arthur
---
# 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.
> **Standard EasyWMS** : → voir [Warehouse Processes](../../concepts/putaway.md)
> Ce qui suit documente les **spécificités Limagrain** par rapport au standard.
## Contexte projet
L'anoxie consiste à baisser le niveau d'oxygène dans l'allée 1 (TK01)
pour éliminer d'éventuels nuisibles dans les semences. Ce processus est
spécifique au domaine des semences et n'existe pas dans le standard EasyWMS.
## Caractéristiques
- **Localisation** : allée 1 uniquement (TK01)
- **Durée** : 3 à 4 semaines en moyenne
- **Fréquence** : 2 fois par an
- **Déclenchement** : manuel
- **Impact** : allée et stock bloqués pendant toute la durée
En dehors des périodes d'anoxie, la zone est utilisée pour du stockage
normal en priorisant les palettes à anoxier. Chaque compartiment a un
taux d'oxygène contrôlé.
## [CUSTOM] Flag « A anoxier »
### Attribution automatique
Tous les stocks des palettes issues des processus suivants reçoivent
automatiquement le flag « A anoxier » car elles présentent des risques
de contamination :
- Réceptions extérieures / intersites
- Retours client
Condition : la palette doit passer par un poste de travail.
### Attribution manuelle
Il est également possible d'assigner le flag manuellement sur des stocks
spécifiques depuis la vue des stocks.
### Retrait du flag
- **Automatique** : à la fin du processus d'anoxie (bouton « Fin d'anoxie »)
- **Manuel** : par un utilisateur, qui devra saisir une date de dernière
anoxie
## 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
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 »
## Processus complet
```mermaid
flowchart TD
START[Décision lancer anoxie] --> SEL1[1. Sélection palettes à évacuer de TK01]
SEL1 --> RELOC1[Relocalisation vers TK02-04]
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]
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
- 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
- Sélection manuelle des palettes avec flag « A anoxier »
- Relocalisation vers TK01 dans la mesure des emplacements disponibles
[CUSTOM] Les étapes 1 et 2 peuvent être **automatisées** afin de créer
automatiquement les tâches de relocalisation.
### É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
- [CUSTOM] Bouton « Fin d'anoxie » qui :
- Met à jour la date de dernière anoxie
- Supprime automatiquement le flag « A anoxier » pour chaque ligne
de stock présente dans l'allée
- Déblocage manuel de l'allée 01
## Suivi et rapports
- Extraction de la vue des stocks avec filtres « A anoxier » et
« date de dernière anoxie » pour établir le rapport souhaité
- L'avancée des tâches de relocalisation est consultable sur la vue
des tâches
## Lien avec les stratégies de rangement
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).
## Points d'attention
⚠️ La relocalisation peut prendre un temps significatif selon les
quantités sélectionnées.
⚠️ MECALUX conseille d'avoir une personne sur site lors du lancement
de la défragmentation/relocalisation en cas de défaut sur les
transstockeurs (non obligatoire).
⚠️ Le processus d'anoxie peut être mis en pause et repris ultérieurement
en cas de reprise d'activité.
## Questions ouvertes
- [ ] Automatisation étapes 1 et 2 — développement custom validé ? (@Nicolas)
- [ ] Interface du bouton « Fin d'anoxie » — écran dédié ou menu existant ? (@Fabien)
## Historique des modifications
| Date | Auteur | Modification |
|------|--------|--------------|
| 2026-05-05 | Arthur | Création initiale depuis AF V1.5 |
## Références
| Source | Type | Date |
|--------|------|------|
| FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5 | Analyse fonctionnelle | 28/11/2025 |
wiki_old_13-05-2026/limagrain/02-stockage/putaway-strategies.md
+113
View File
@@ -0,0 +1,113 @@
---
title: "Stratégies de rangement Limagrain"
tags: [stockage, putaway, stratégie, rangement, canaux]
status: draft
standard_ref: concepts/putaway.md
jira_refs: []
confluence_refs: []
sources: [FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5.docx]
last_updated: 2026-05-05
author: Arthur
---
# Stratégies de rangement Limagrain
> **Résumé** : 5 stratégies de rangement distinctes selon la typologie de la
> palette, avec des règles de sélection de canal et d'allée spécifiques.
> **Standard EasyWMS** : → voir [Putaway](../../concepts/putaway.md)
> Ce qui suit documente les **spécificités Limagrain** par rapport au standard.
## 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
sur la nature fonctionnelle de la palette.
## 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) |
| 2 | TK01 — canal vide |
| 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 »
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 |
| 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 »
| Priorité | Règle |
|----------|-------|
| 1 | Canal incomplet mixte |
| 2 | Canal vide |
| 3 | Canal incomplet (tout) |
| 4 | REJET |
## 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 |
| 2 | Canal vide — zone défragmentation client |
| 3 | PAS DE MOUVEMENT (palette reste en place) |
## Stratégie 5 — Piles de palettes vides
Article type « Palette » (NIMP15).
| Priorité | Règle |
|----------|-------|
| 1 | Canal incomplet le plus proche de l'entrée avec piles de palettes vides |
| 2 | Canal vide le plus proche de l'entrée (hors TK01) |
| 3 | Canal incomplet (tout) |
| 4 | REJET |
## Critères transverses
- **Réservation de canal** : le nombre de palettes en ASN non encore reçues
détermine la capacité optimale du canal à réserver (stratégie 2)
- **Équilibrage inter-allées** : pour les palettes mono lot, EasyWMS répartit
le stock entre allées différentes quand un canal plein existe déjà
- **Hauteur** : la hauteur de la première palette au PIE détermine le type
de rack compatible (RACK01 ≤1150, RACK02 ≤1950, RACK03 ≤2250)
## Points d'attention
⚠️ Si aucun emplacement n'est trouvé → palette rejetée vers le poste de
rejet configuré (sauf stratégie 4 où la palette reste sur place).
⚠️ Les palettes d'expédition ne sont déplacées en zone défragmentation
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.
## Historique des modifications
| Date | Auteur | Modification |
|------|--------|--------------|
| 2026-05-05 | Arthur | Création initiale depuis AF V1.5 |
## Références
| Source | Type | Date |
|--------|------|------|
| FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5 | Analyse fonctionnelle | 28/11/2025 |
wiki_old_13-05-2026/limagrain/02-stockage/zones-stockage.md
+85
View File
@@ -0,0 +1,85 @@
---
title: "Zones de stockage Limagrain"
tags: [stockage, zones, anoxie, défragmentation, ASRS]
status: draft
standard_ref: concepts/putaway.md
jira_refs: []
confluence_refs: []
sources: [FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5.docx]
last_updated: 2026-05-05
author: Arthur
---
# Zones de stockage Limagrain
> **Résumé** : Limagrain dispose de 3 zones de stockage dans l'ASRS, chacune
> avec un rôle spécifique : anoxie, stockage principal, défragmentation client.
> **Standard EasyWMS** : → voir [Putaway](../../concepts/putaway.md),
> [Location](../../concepts/location.md)
> Ce qui suit documente les **spécificités Limagrain** par rapport au standard.
## Contexte projet
L'entrepôt automatique Limagrain comporte **4 allées** (TK_01 à TK_04). Les
zones de stockage ont été définies pour répondre à deux besoins métier :
1. **Anoxie** : traitement insecticide par réduction d'oxygène sur TK_01
2. **Défragmentation client** : pré-positionnement des palettes assignées à
une route avant expédition (optimise les temps de sortie)
## Configuration des zones
| Zone | Transstockeur | X initial | X final | Y initial | Y final |
|------|---------------|-----------|---------|-----------|---------|
| Zone Anoxie | TK_01 | 1 | 69 | 1 | 10 |
| Zone Principale | TK_02, 03 & 04 | 1 | 59 | 1 | 10 |
| Zone Principale (ext.) | TK_02, 03 & 04 | 60 | 69 | 1 | 1 |
| Zone Défragmentation client | TK_02, 03 & 04 | 60 | 69 | 2 | 10 |
> ⚠️ Cette répartition peut être modifiée par un administrateur Limagrain
> selon les besoins opérationnels.
## Comportement par zone
### Zone Anoxie (TK_01)
- 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)
### Zone Principale (TK_02, 03 & 04)
- Stockage général : articles et piles de palettes vides
- Pas de distinction de classe de rotation (pas d'ABC)
- Stratégie de répartition inter-allées pour équilibrer la charge
### Zone Défragmentation client (TK_02, 03 & 04, X=60-69, Y=2-10)
- Palettes assignées à un ordre de sortie (post stock assignment)
- Regroupement par route/stop pour optimiser le séquencement à l'expédition
- Les palettes y sont déplacées automatiquement après libération de l'OS
## Points d'attention
⚠️ Les piles de palettes vides sont stockées en priorité dans les allées
02, 03 & 04, au plus proche des entrées/sorties (canaux bas en X).
⚠️ Le convoyeur de sortie TS01 dans TK_01 crée une **exception de stockage** :
pas de canaux en X=21/Y=1, X=21/Y=2, X=22/Y=1.
⚠️ Taux minimum de 5% d'emplacements libres recommandé par Mecalux pour
la défragmentation et les relocalisations.
## Historique des modifications
| Date | Auteur | Modification |
|------|--------|--------------|
| 2026-05-05 | Arthur | Création initiale depuis AF V1.5 |
## Références
| Source | Type | Date |
|--------|------|------|
| FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5 | Analyse fonctionnelle | 28/11/2025 |
wiki_old_13-05-2026/limagrain/03-picking/.fuse_hidden0000002f00000010
+148
View File
@@ -0,0 +1,148 @@
---
title: "Consolidation (regroupement) — Processus sur poste"
tags: [picking, regroupement, consolidation, MOV, poste, custom]
status: draft
standard_ref: concepts/picking.md
jira_refs: []
confluence_refs: []
sources: [FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5.docx]
last_updated: 2026-05-05
author: Arthur
---
# 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.
> **Standard EasyWMS** : → voir [Picking](../../concepts/picking.md)
> Ce qui suit documente les **spécificités Limagrain** par rapport au standard.
## Contexte projet
Le regroupement permet de vider des palettes partiellement remplies en
déplaçant leur stock vers d'autres palettes contenant le même stock.
L'objectif est de libérer des emplacements dans l'ASRS.
## Critères de consolidation
Le regroupement est proposé quand deux palettes ou plus partagent :
- Article
- Lot SAP
- Propriétaire
- Statut de stock
- Flag anoxie
## [CUSTOM] Vue de proposition de regroupement
Une vue spécifique est développée pour Limagrain. Elle présente :
- Les palettes candidates au regroupement
- Le gain potentiel en nombre de palettes
**Règle** : le regroupement n'est proposé que s'il permet de gagner au
moins 1 palette. Exemple : Bag/Pal = 75, si palette H1 = 73 et H2 = 5
→ pas de regroupement (73 + 5 = 78 > 75, pas de gain).
L'opérateur sélectionne un ou plusieurs ordres de regroupement depuis
cette vue.
## Processus complet
```mermaid
flowchart TD
VUE[Vue proposition regroupement] --> SELECT[Sélection ordres]
SELECT --> ASSIGN[Assignation poste automatique]
ASSIGN --> TACHE[Création tâches mouvement]
TACHE --> ORD[Ordonnancement palettes au poste]
ORD --> VERROU{Verrou « Réception » ?}
VERROU -->|Oui| RECOUNT[Recomptage]
VERROU -->|Non| PICK[Déplacement sacs]
RECOUNT --> PICK
PICK --> VIDE{Palette vidée ?}
VIDE -->|Oui| DEGAGE[Dégagement palette vide]
VIDE -->|Non| PICK
DEGAGE --> EVAC[Évacuation palette stock]
EVAC --> FILM[Choix filmage]
FILM --> PIE[Passage PIE]
PIE --> STOCK[Stockage ASRS]
```
## Assignation poste de travail
- Assignation **automatique** quand un ordre est lancé
- [CUSTOM] Si le lot a un Bag/Pal ≤ 2 → considéré « big-bag » →
seul le **poste P6** (équipé d'un palan) est assignable
- Un big-bag ne peut être consolidé que sur un autre big-bag
- Si P6 n'est pas en mode regroupement → tâche en attente
- Si aucun poste disponible → ordre en attente de libération
## [CUSTOM] Ordonnancement des palettes au poste
Une fois l'ordre lancé et le poste assigné, les palettes arrivent dans
cet ordre :
1. **Minimum de mouvements palette** (moins de déplacements physiques)
2. **Minimum de mouvements sac** (moins de manipulations)
3. **Palette complète** (en priorité la palette destinataire)
## Exécution sur poste
1. [CUSTOM] Si verrou « Réception » → recomptage avant regroupement
2. Les sacs de la palette à éliminer sont déplacés vers la palette
destinataire
3. Quand la palette est vidée → dégagement de la table de préparation
4. Évacuation de la palette avec stock restant via bouton EasyWMS
5. [CUSTOM] Choix filmage depuis vue spécifique (programme à définir)
6. [CUSTOM] Message **MOV** à chaque déplacement de stock :
- Palette d'origine
- Palette de destination
- Nouvelle palette ? (Oui/Non)
- Quantité + caractéristiques (article, lot SAP, ...)
## Passage PIE post-regroupement
Contrôle identique aux autres processus :
- Dimensions max : 1300 × 1100 × 1900 mm
- Poids max : 1250 kg
- État palette bois correct
- Étiquette RFID connue
[CUSTOM] Calcul poids de référence :
```
Poids réf = Σ (Poids_unité_ligne_i × quantité_ligne_i) + poids_palette_bois
```
Vérification avec tolérance par type d'article (voir
[Contrôle qualité réception](../01-inbound/controle-qualite-reception.md)).
## Points d'attention
⚠️ 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
simultanément pendant le regroupement.
⚠️ Un big-bag ne peut être consolidé que sur un autre big-bag (contrainte
physique + système).
## Questions ouvertes
- [ ] Programme de filmage exact pour le regroupement (@Théo)
- [ ] Interface opérateur vue regroupement — maquette validée ? (@Fabien)
## Historique des modifications
| Date | Auteur | Modification |
|------|--------|--------------|
| 2026-05-05 | Arthur | Création initiale depuis AF V1.5 |
## Références
| Source | Type | Date |
|--------|------|------|
| FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5 | Analyse fonctionnelle | 28/11/2025 |
wiki_old_13-05-2026/limagrain/03-picking/.fuse_hidden0000003100000011
+145
View File
@@ -0,0 +1,145 @@
---
title: "Échantillonnage — Processus de contrôle qualité"
tags: [picking, échantillonnage, inventaire, qualité, poste, custom]
status: draft
standard_ref: concepts/inventory.md
jira_refs: []
confluence_refs: []
sources: [FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5.docx]
last_updated: 2026-05-05
author: Arthur
---
# É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.
> **Standard EasyWMS** : → voir [Inventory](../../concepts/inventory.md)
> Ce qui suit documente les **spécificités Limagrain** par rapport au standard.
## Contexte projet
L'échantillonnage sert au contrôle qualité sur une partie des lots
produits. Il consiste à prélever environ 200 grammes dans une partie du
stock sélectionné. Le prélèvement est ensuite analysé pour valider la
qualité du produit fini.
Dans EasyWMS, ce processus est assimilé à un **inventaire** (ordre
d'inventaire).
## Création de l'ordre d'échantillonnage
Deux modes de création :
| Mode | Origine | Détail |
|------|---------|--------|
| Interface ERP | Message de l'ERP (COR) | Spécifie un lot à inventorier |
| Manuel | Interface EasyWMS | Choix d'un lot par l'opérateur |
[CUSTOM] Un champ texte est disponible pour donner des **consignes**
rattachées à l'ordre d'inventaire.
## [CUSTOM] Assignation du stock
L'assignation diffère selon le mode de création :
### Création par interface ERP
- Maximum **4 palettes** échantillonnées :
- Si stock global < 4 → toutes les palettes
- 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
### Création manuelle
- Nombre de palettes choisi par l'opérateur
## Assignation poste de travail
- Automatique, à condition que le poste soit ouvert et autorise le
mode « échantillonnage »
- 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
```mermaid
flowchart TD
ORDRE[Ordre échantillonnage] --> ASSIGN[Assignation stock]
ASSIGN --> POSTE[Assignation poste auto]
POSTE --> TACHE[Tâches mouvement créées]
TACHE --> ARRIVE[Palette arrive sur TP]
ARRIVE --> VERROU{Verrou « Réception » ?}
VERROU -->|Oui| RECOUNT[Recomptage]
VERROU -->|Non| PRELEV[Prélèvement ~200g]
RECOUNT --> PRELEV
PRELEV --> ETIQ[Impression étiquette échantillonnage]
ETIQ --> SCOTCH[Scotch sac ouvert]
SCOTCH --> FILM[Choix filmage]
FILM --> EVAC[Évacuation → PIE → stockage]
EVAC --> NEXT{Palette suivante ?}
NEXT -->|Oui| ARRIVE
NEXT -->|Non| FIN[Fin ordre]
```
Les 3 tables de préparation peuvent être occupées simultanément.
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
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**
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)
9. Évacuer la palette vers le stockage
## Passage PIE post-échantillonnage
Contrôle identique aux autres processus :
- Dimensions max : 1300 × 1100 × 1900 mm
- Poids max : 1250 kg
- Étiquette RFID connue
- État palette bois correct
[CUSTOM] Poids de référence recalculé + vérification avec tolérance
(voir [Contrôle qualité réception](../01-inbound/controle-qualite-reception.md)).
Si PIE NOK → rejet vers poste d'origine. Possibilité de forcer le
passage en cas d'excédent de poids non corrigeable.
## Points d'attention
⚠️ L'échantillonnage est un processus d'**inventaire** dans EasyWMS,
pas un processus de picking — important pour le paramétrage des modes
de poste.
⚠️ Les palettes avec verrou « Production » (écart poids) sont traitées
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).
## Questions ouvertes
- [ ] Le prélèvement de 200g est-il déduit du stock ou négligé ? (@Nicolas)
- [ ] Programme de filmage exact (@Théo)
- [ ] Format de l'étiquette d'échantillonnage — validé ? (@Justine)
## Historique des modifications
| Date | Auteur | Modification |
|------|--------|--------------|
| 2026-05-05 | Arthur | Création initiale depuis AF V1.5 |
## Références
| Source | Type | Date |
|--------|------|------|
| FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5 | Analyse fonctionnelle | 28/11/2025 |
wiki_old_13-05-2026/limagrain/03-picking/.fuse_hidden0000003300000012
+211
View File
@@ -0,0 +1,211 @@
---
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]
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"]
last_updated: 2026-05-12
author: Arthur
---
# 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
> modes autorisés et leur priorité. Évite la concurrence entre
> mini-jobs indépendants.
> **Standard EasyWMS** : → voir [Picking](../../concepts/picking.md),
> [Stations & Routes](../../concepts/stations.md)
> Ce qui suit documente les **spécificités Limagrain** par rapport au
> standard.
## Contexte projet
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
orchestration centralisée, ces flux se feraient concurrence.
Le Mega Job est un **job unique** avec une entête qui analyse l'ensemble
des supports concernés et, selon leur emplacement d'origine et leurs
caractéristiques, délègue à des **sous-workflows** dédiés.
## Éligibilité d'un PK
Pour qu'un poste soit éligible à une nouvelle assignation, **toutes** les
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
- **Le poste est ouvert** (mode actif)
- **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.
## Logique principale
```mermaid
flowchart TD
A[Début du job] --> B[Lister les PK ouverts]
B --> C{PK éligible ?}
C -- Non --> D[PK suivant]
C -- Oui --> E[Lire MODES_PKxx]
E --> F{Paramètre existe et non vide ?}
F -- Non --> D
F -- Oui --> G[Trier les modes par priorité]
G --> H[Exécuter sous-WF du mode priorité 1]
H --> I{Tâche assignée ?}
I -- Oui --> D
I -- Non --> J[Exécuter sous-WF du mode priorité 2]
J --> K{Tâche assignée ?}
K -- Oui --> D
K -- Non --> L[... mode suivant ...]
L --> D
D --> M{Autres PK ?}
M -- Oui --> C
M -- Non --> N[Fin du job]
```
Pour chaque PK éligible :
1. Le WMS récupère le paramètre `MODES_PKxx` (x = numéro du poste)
2. Les modes sont triés par priorité croissante
3. Le sous-workflow du mode de priorité la plus haute est exécuté
4. Si le sous-WF a assigné une tâche → passage au PK suivant
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
## Gestion des Big-Bags
Le paramètre `PK_BIGBAG` définit quels PK autorisent la présence de
big-bags (physiquement : P5 et P6 avec palan).
- Les ordres contenant des supports big-bag sont **interdits** sur les
PK qui ne les autorisent pas
- Ces ordres sont **prioritaires** (en respectant le séquençage des
process en première priorité) sur les PK qui les autorisent
## Sous-workflows
Le Mega Job délègue la création effective des tâches à des sous-workflows
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 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 |
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)
Ce sous-workflow est appelé par le Mega Job quand le mode **Picking** est
actif sur un PK. Il assigne un ordre de sortie (commande) au poste.
### Éligibilité du PK pour une commande
Le PK peut recevoir une commande si **toutes** les conditions sont
remplies :
- Le PK **autorise la préparation de commande** (mode Picking actif)
- 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
```mermaid
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)
Les commandes de **classe Messagerie** sont expédiées le jour même et
sont donc **prioritaires** sur les autres commandes.
**Affinité transporteur ↔ PK** : une fois qu'un PK est choisi pour une
commande Messagerie, **toutes les commandes Messagerie du même
transporteur** doivent être assignées au même PK. Le mécanisme repose
sur un paramètre par transporteur :
- `PK_TRANSPORTEUR_MESSAGERIE` : contient le code du PK assigné
- Si le paramètre contient une valeur correspondant au PK analysé →
assigner la prochaine commande Messagerie de ce transporteur
- Si la valeur correspond à un **autre PK** → ignorer toutes les
Messagerie de ce transporteur pour ce PK
- Si le PK a le paramètre mais qu'**aucune commande** Messagerie de ce
transporteur n'est trouvable → **vider le paramètre**
- Si le paramètre contient le nom du PK → le PK ne peut assigner **que**
des Messagerie de ce transporteur (exclusivité tant que le
paramètre est actif)
#### Autres commandes (standard)
Le processus standard est utilisé : assignation d'une commande à une
table de préparation et un PK, en respectant l'ordre de la **tournée**
(numéro d'arrêt croissant — plus petit numéro d'arrêt en premier).
## Paramètres
| Paramètre | Description | Valeur par défaut |
|-----------|-------------|-------------------|
| MODES_PKxx | Modes autorisés + priorité pour le PK xx (un par PK, renseigné via la vassist — voir [Stations picking](stations-picking.md)) | _(vide)_ |
| PK_BIGBAG | PK autorisant les big-bags | _(à définir — P5, P6)_ |
| PK_TRANSPORTEUR_MESSAGERIE | Code PK assigné au transporteur Messagerie en cours (un paramètre par transporteur) | _(vide)_ |
## Points d'attention
> **À reprendre par @Michael** : l'entête du job doit checker tous les
> PK en attente de tâche, vérifier leurs modes autorisés et la séquence
> de priorité pour entrer dans le sous-WF nécessaire.
- Le job standard `Task_GenerateMovementJob_PR` gère le passage
"en attente" → "créé" ; le Mega Job ne remplace pas ce mécanisme
mais crée les tâches en amont
- Un PK fermé n'est jamais éligible — le job le vérifie dès la première
condition
## Questions ouvertes
- [ ] Fréquence d'exécution du Mega Job à définir (@Michael)
- [ ] Sous-WF pour regroupement, échantillonnage : tickets à créer ?
- [ ] Interaction entre PK_BIGBAG et les modes : si P5 est en mode
regroupement, accepte-t-il quand même les big-bags en réception ?
## Historique des modifications
| Date | Auteur | Modification |
|------|--------|--------------|
| 2026-05-12 | Arthur | Création initiale depuis LIM-70 |
| 2026-05-12 | Arthur | Ajout sous-WF assignation commandes (LIM-80) |
## Références
| Source | Type | Date |
|--------|------|------|
| [LIM-70](https://easywmsfrance.atlassian.net/browse/LIM-70) | Ticket Jira | 2026 |
| [LIM-74](https://easywmsfrance.atlassian.net/browse/LIM-74) | Ticket Jira | 2026 |
| [LIM-75](https://easywmsfrance.atlassian.net/browse/LIM-75) | Ticket Jira | 2026 |
| [LIM-69](https://easywmsfrance.atlassian.net/browse/LIM-69) | Ticket Jira (modes PK) | 2026 |
| [LIM-80](https://easywmsfrance.atlassian.net/browse/LIM-80) | Ticket Jira (assignation commandes PK) | 2026 |
wiki_old_13-05-2026/limagrain/03-picking/.fuse_hidden0000003500000013
+307
View File
@@ -0,0 +1,307 @@
---
title: "Picking sur poste de travail — Expédition client"
tags: [picking, poste, expédition, ordonnancement, MOV, PCK]
status: draft
standard_ref: concepts/picking.md
jira_refs: [LIM-82]
confluence_refs: []
sources: [FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5.docx, "Expédition - LIMAGRAIN - DEV - Confluence.md", "LIM-82 LOT2.2 [PICKING] Ordonnancement des tâches de picking PS PK.md", "REU PICKING SEQUENCAGE 11-05-2026 - Analyse comparative notes + AF + devops.md"]
last_updated: 2026-05-12
author: Arthur
---
# 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
> négatif et contraintes physiques.
> **Standard EasyWMS** : → voir [Picking](../../concepts/picking.md)
> Ce qui suit documente les **spécificités Limagrain** par rapport au standard.
## Contexte projet
Le picking chez Limagrain se fait sur les postes de travail automatisés
(pas de picking mobile en allée). Les palettes source et les palettes
de préparation sont acheminées par AGV sur les tables de préparation (TP).
> **Note** : cette page décrit le picking tel que défini dans l'AF V1.5.
> Le projet a depuis évolué vers un modèle « picking combinatoire »
> (CR V3.0, 4 jobs, CstAtt) qui sera documenté séparément.
## Déclenchement
Le picking est déclenché pour les commandes client (RUT type « Client »)
quand des palettes incomplètes sont nécessaires (la quantité demandée
ne correspond pas à des palettes complètes).
Prérequis : un **poste de travail assigné** (auto ou manuellement).
## [CUSTOM] Ordonnancement des palettes au poste
Une fois le poste assigné, les palettes arrivent dans cet ordre :
### Tri par espèce et gerbabilité
1. **Espèce Maïs** toujours en premier (pas la variété mais l'espèce)
2. Puis espèce avec la **plus grande quantité** dans la commande
3. Si égalité → **article/lot le plus lourd** en base de palette
**Mapping Espèce → stack (gerbabilité)** : le maïs = stack 0 (le plus
lourd/stable, donc en base). [CUSTOM] Gestion en **async sur l'ITM** pour
calculer la gerbabilité automatiquement à la création de l'article. Tri
des tâches de picking dans le workflow `StackerCrane_SortTasks_PR`.
### ~~Séparation par traitement commercial~~ SUPPRIMÉ (réu. 11/05/2026)
~~Pas de mélange entre articles avec traitement et sans traitement
sur une même palette fille.~~
**Décision** : `CONTROLE_TRAITEMENT_COMMERCIAL = false`. L'entrepôt
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)
> pour le détail de l'analyse comparative.
## [CUSTOM] Règle du picking négatif
**Deux conditions cumulatives** (réu. 11/05/2026) :
1. La quantité à prélever dépasse le **seuil fiche article** (défaut
55%, paramétrable par article via "Complete quantity percent excess
for negative picking")
2. Le **poids unitaire du sac ≥ 7 kg** (raison : instabilité palette si
gros sacs ramenés sur petits sacs)
Si les deux conditions sont remplies → **picking négatif** : au lieu de
déplacer les sacs à expédier, déplacer les sacs qui **retourneront en
stock** (moins de mouvements physiques).
Si l'une des deux conditions n'est pas remplie → picking direct
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).
## [CUSTOM] Calcul équivalent palette (pro rata Bag/pal)
Pour déterminer si une palette est « pleine », calcul en **pro rata
Bag/pal** (réu. 11/05/2026, remplace la logique DevOps "Bag/pal max") :
```
Équivalent palette d'un sac = 1 ÷ Bag/Pal de son lot
```
Le calcul est additif et gère nativement des lots avec des Bag/pal
différents sur une même palette :
```
Exemple :
15 sacs lot Bag/pal 20 + 10 sacs lot Bag/pal 75
= 15/20 + 10/75
= 0,75 + 0,133
= 88,3% → il reste ~12% de place
```
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
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
pas la tâche en cours)
- Si plus assez de stock → réassignation ailleurs + retrait verrou
## [CUSTOM] Algorithme de répartition des palettes sur les TP
Logique combinatoire complète gérant tous les cas :
- Picking négatif et enchaînement de pickings négatifs
- Ordonnancement par espèce
- Terminer une palette pleine avant d'en entamer une autre
- Cadencement des buffers devant les postes de picking
- Pas de mélange de traitement commercial (via famille d'article)
- **Contrainte** : l'opérateur ne doit **pas déplacer de sacs 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. Quand la palette de
prélèvement est vidée, l'opérateur la remet manuellement sur une pile
de palettes vides à proximité.
> Prévoir un process sans picking négatif pour les cas où c'est rarement
> utilisé (ou monter le seuil, ex : 70% au lieu de 50%).
## Processus de préparation
### Arrivée des palettes (toujours un poste 3 TP)
- Première palette au **centre** si picking négatif proposé, sinon sur
un côté
- Si une palette est sur un côté et qu'on propose du picking négatif →
prévenir l'opérateur de déplacer la palette au centre
- La palette client revient **toujours** au centre
- Pas de prépa sur 6 TP en simultané
### Picking
1. Palette source arrive sur une TP
2. Palette destination (vide ou en cours) sur une autre TP
3. Opérateur prélève les sacs (ou sacs retour si picking négatif)
4. ~~[CUSTOM] Message MOV envoyé à SAP~~ **ANNULÉ** (décision client)
5. Avant évacuation : choix filmage (CstData transmis à Galileo).
Possibilité de choisir « pas de filmage ».
6. Évacuation palette → PIE → contrôle poids → stockage/expédition
## [CUSTOM] Ordonnancement des tâches PS → PK (LIM-82)
Détail du cadencement des palettes depuis les postes de sortie (PS)
vers les postes de picking (PK). Toutes les tâches de picking se font
sur les tables élévatrices des PK.
### Règles de priorité
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
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
À chaque tâche de picking négatif :
- Un **nouveau code SSCC** est généré pour la palette où l'excédent de
stock est déposé
- Une **étiquette RFID** est imprimée pour cette nouvelle palette
- La palette de picking négatif va toujours au **centre** du PK
### Cadencement des buffers
Les palettes non encore nécessaires au PK sont dirigées vers les
**zones d'attente** (buffers ES_X) s'il y a de la place disponible. Le
WMS **privilégie la sortie des palettes de picking négatif** vers les
buffers.
À chaque palette arrivant au PS, celui-ci vérifie s'il existe d'autres
tâches du même OS avec une **séquence plus faible** :
- Si oui → palette envoyée au **buffer ES_X** (attente)
- Si non → palette envoyée directement au **PK**
### Cas d'exemple — 10 tâches (3 négatif, 7 classique)
1. Le WMS envoie **2 palettes** vers le PK : 1 picking négatif + 1
picking classique
2. Les **8 autres** palettes sont dirigées vers les zones d'attente
(priorité aux palettes de picking négatif)
3. L'opérateur réalise le picking négatif → impression étiquette
SSCC/RFID pour la nouvelle palette
4. L'opérateur réalise le picking classique → stock déposé sur la
palette du milieu
5. Si la palette client n'est pas pleine → le WMS apporte une nouvelle
palette de picking classique
6. L'opérateur déclare la palette client **pleine** → le WMS apporte la
2ᵉ palette de picking négatif
7. Si le picking classique précédent est **en cours** (tâche partielle)
→ pas de nouvelle palette classique. Sinon → 2ᵉ palette classique
envoyée au PK
Voir aussi [Séquençage TK → PS](sequencage-tk-ps.md) pour le
mécanisme amont de tri des tâches entre les transstockeurs et les
postes de sortie, et [Placement PS → PK](placement-ps-pk.md) pour
l'algorithme de choix de table (ping-pong, buffers, évacuation).
## Information passage conteneur client
Le passage en conteneur client est visible dans le **LOC** envoyé
toutes les 5 minutes à SAP (flag « client » = true). Voir
[Flux ERP outbound](../04-outbound/flux-erp-outbound.md#communication-erp--loc--détails).
## Étiquetage
### Cas standard (non MII ou MII mono lot)
- 1 étiquette RFID pour la palette physique bois
### Cas MII multi lots
- 1 étiquette HU RFID pour la palette physique (HU mère)
- 1 étiquette HU sans RFID par ligne de stock (HU fille / intercalaire)
- Impression auto à chaque nouvelle palette (RFID) et à chaque article
(intercalaire)
- Basé sur la **classe de commande**
## Contraintes opérateur (hors EasyWMS)
Règles non gérées par le système mais à respecter :
1. Palette ne doit pas excéder **1,90 m** (sinon rejet PIE)
2. Palette ne doit pas excéder **1 250 kg** (sinon rejet PIE, AF fait foi)
3. Pas de gerbage de palette
4. Disposition d'intercalaires entre couches
## Calcul poids de référence (post-picking)
Pour les palettes multi-lignes de stock :
```
Poids réf = Σ (Poids_unité_ligne_i × quantité_ligne_i) + poids_palette_bois
```
Contrôle PIE identique aux autres processus (voir
[Contrôle qualité réception](../01-inbound/controle-qualite-reception.md)).
## Points d'attention
⚠️ Le picking négatif (seuil 55% ET poids ≥ 7 kg) est une règle métier
custom — les deux conditions sont cumulatives (réu. 11/05/2026).
⚠️ L'ordonnancement espèce → quantité → poids est géré par EasyWMS
(pas un choix opérateur).
⚠️ Le message MOV est **ANNULÉ** (décision réunion client).
⚠️ Le verrou HORS TOLERANCE déclenche un recomptage mais ne casse pas
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.
## Questions ouvertes
- [x] ~~Programme de filmage exact~~ → 8 programmes documentés (A→H)
- [ ] Gestion du picking négatif dans l'interface opérateur (@Nicolas)
- [x] ~~Process sans picking négatif — seuil à 70% au lieu de 50%~~ →
Tranché : seuil paramétrable par article (défaut 55%) + condition
poids ≥ 7 kg (réu. 11/05/2026)
- [x] ~~Traitement commercial — séparation palette~~ → Supprimé
(`CONTROLE_TRAITEMENT_COMMERCIAL = false`, réu. 11/05/2026)
## Historique des modifications
| Date | Auteur | Modification |
|------|--------|--------------|
| 2026-05-05 | Arthur | Création initiale depuis AF V1.5 |
| 2026-05-05 | Arthur | Gerbabilité/stack, algo répartition TP, verrou HORS TOLERANCE, MOV annulé, arrivée palettes 3 TP, filmage CstData |
| 2026-05-12 | Arthur | Ajout ordonnancement PS→PK (LIM-82) : priorité picking négatif, cadencement buffers, cas d'exemple, lien séquençage TK→PS |
| 2026-05-12 | Arthur | MAJ réunion 11/05 : picking négatif 2 conditions cumulatives (55% + 7 kg), TC supprimé, pro rata Bag/pal, poids max 1 250 kg, questions fermées |
## Références
| Source | Type | Date |
|--------|------|------|
| 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](https://easywmsfrance.atlassian.net/browse/LIM-82) | Ticket Jira (ordonnancement PS→PK) | 2026 |
| REU PICKING SEQUENCAGE 11-05-2026 | CR réunion + analyse comparative | 11/05/2026 |
wiki_old_13-05-2026/limagrain/03-picking/.fuse_hidden0000003700000014
+323
View File
@@ -0,0 +1,323 @@
---
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: []
confluence_refs: []
sources: ["Logique combinatoire picking - PS vers PK - V1.0.md"]
last_updated: 2026-05-12
author: Arthur
---
# Placement des palettes PS → PK (choix de table)
> **Résumé** : algorithme exécuté par le WMS lorsqu'une palette source
> arrive au poste de sortie (PS). Il décide sur quelle table du PK la
> poser, ou la redirige vers un buffer ES. Ce process s'exécute **en
> aval** du [séquençage TK → PS](sequencage-tk-ps.md) : les palettes
> arrivent au PS déjà triées.
> **Standard EasyWMS** : → voir [Picking](../../concepts/picking.md)
> Ce qui suit documente les **spécificités Limagrain** par rapport au
> standard.
## Contexte projet
Chaque PK dispose de **3 tables** soumises à une contrainte d'adjacence
stricte :
```
TABLE_GAUCHE ←→ TABLE_CENTRE ←→ TABLE_DROITE
✅ adjacentes ✅ adjacentes
TABLE_GAUCHE ←————————————————→ TABLE_DROITE
❌ INTERDIT
```
Règles de mouvement :
- Le stock est **toujours sur une palette**, jamais posé directement sur
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** —
seul l'AGV peut déplacer une palette (arrivée, évacuation, recentrage)
- **TABLE_CENTRE** est le pivot : seule table adjacente aux deux autres
## Déclenchement
L'algorithme est appelé **à chaque arrivée physique d'une palette au
PS**. Le PS interroge le WMS qui retourne une réponse parmi :
- **TABLE_GAUCHE**, **TABLE_CENTRE** ou **TABLE_DROITE** → la palette
est envoyée sur cette table
- **Buffer ESx** → aucune table n'est disponible, la palette est
redirigée vers un emplacement buffer
- **Attente** → ni table ni buffer disponible, la palette reste au PS
## Entrées de l'algorithme
| Donnée | Source |
|--------|--------|
| Tâche courante : palette source, article, quantité, type de picking (NÉGATIF / DIRECT), `Line.CstAtt` (séquence) | Tâche associée à la palette |
| État des 3 tables du PK : VIDE, PALETTE_FILLE_ACTIVE, PALETTE_FILLE_EN_ATTENTE, PALETTE_SOURCE_EN_PICKING, PALETTE_SOURCE_EN_ATTENTE, EN_ATTENTE_EVACUATION | État temps réel du PK |
| Tâches suivantes de l'OS (triées par `Line.CstAtt` croissant) | OS en base |
| Buffers ES disponibles : parmi ES1–ES16, ceux non occupés ni ciblés | État temps réel des buffers |
| Nombre de buffers déjà affectés à ce PK vs `MAX_PRELOAD_PAR_PK` (défaut : 3) | Compteur par PK |
## Décision niveau 1 : table du PK ou buffer ?
```
FONCTION décider_destination(palette, PK) :
table_cible ← choisir_table(palette, PK)
SI table_cible ≠ NULL :
RETOURNER table_cible
// Aucune table disponible → tenter un buffer
SI nb_buffers_affectés(PK) < MAX_PRELOAD_PAR_PK :
buffer ← premier ES libre
SI buffer existe :
RETOURNER buffer
// Ni table ni buffer disponible
RETOURNER ATTENTE
```
## Décision niveau 2 : choix de la table
Le choix dépend du **type de picking** de la tâche associée.
### Cas PICKING_NÉGATIF
En picking négatif, la palette source arrive sur une table, l'opérateur
retire l'excédent sur une palette posée sur une **table adjacente**,
puis échange d'étiquettes. La palette a besoin de **2 tables** : une
pour elle, une adjacente libre pour l'excédent.
```
FONCTION choisir_table_picking_négatif(PK) :
// Priorité 1 : centre + un côté libre
SI TABLE_CENTRE == VIDE ET (TABLE_GAUCHE == VIDE
OU TABLE_DROITE == VIDE) :
RETOURNER TABLE_CENTRE
// Priorité 2 : côté + centre libre
SI (TABLE_GAUCHE == VIDE OU TABLE_DROITE == VIDE)
ET TABLE_CENTRE == VIDE :
RETOURNER côté vide
// Priorité 3 : centre libre + un côté libérable
SI TABLE_CENTRE == VIDE ET un côté est libérable :
évacuer(côté libérable)
RETOURNER TABLE_CENTRE
// Priorité 4 : un côté libre + centre libérable
SI un côté == VIDE ET TABLE_CENTRE est libérable :
évacuer(TABLE_CENTRE)
RETOURNER côté vide
// Dernier recours : évacuation forcée
évacuer_table_prioritaire(PK)
RETOURNER choisir_table_picking_négatif(PK) // rappel
```
### Cas PICKING_DIRECT
La palette source doit être posée sur une table **adjacente à la
palette fille active**. Le choix se fait en fonction de l'emplacement
de la palette fille.
```
FONCTION choisir_table_picking_direct(tâche, PK) :
// Étape 1 : localiser la palette fille compatible
table_fille ← localiser_palette_fille(tâche, PK)
SI table_fille == NULL :
table_fille ← choisir_table_nouvelle_palette_fille(PK)
// Étape 2 : choisir une table adjacente
tables_adj ← tables_adjacentes(table_fille)
// Prio A : palette source déjà sur une adjacente
// (multi-tâches même palette)
POUR chaque t DANS tables_adj :
SI t contient tâche.PALETTE_SOURCE :
RETOURNER t
// Prio B : adjacente VIDE
// Si 2 adjacentes libres (PF au centre) → ping-pong
adjacentes_vides ← [t POUR t DANS tables_adj SI t == VIDE]
SI len(adjacentes_vides) == 2 :
RETOURNER choisir_côté_ping_pong(PK)
SI len(adjacentes_vides) == 1 :
RETOURNER adjacentes_vides[0]
// Prio C : adjacente en cours d'évacuation (AGV en route)
POUR chaque t DANS tables_adj :
SI t == EN_ATTENTE_EVACUATION :
RETOURNER t
// Prio D : forcer l'évacuation d'une adjacente
t_à_libérer ← choisir_table_à_évacuer(tables_adj)
évacuer(t_à_libérer)
RETOURNER t_à_libérer
```
### Localisation de la palette fille compatible
```
FONCTION localiser_palette_fille(tâche, PK) :
// Parmi les PF actives
POUR chaque table :
SI table.état == PALETTE_FILLE_ACTIVE :
RETOURNER table
// Note : CONTROLE_TRAITEMENT_COMMERCIAL = false,
// donc pas de filtre TC
// Puis parmi les PF en attente
POUR chaque table :
SI table.état == PALETTE_FILLE_EN_ATTENTE :
RETOURNER table
RETOURNER NULL
```
### Choix de table pour une nouvelle palette fille
```
FONCTION choisir_table_nouvelle_palette_fille(PK) :
// TABLE_CENTRE = pivot → maximise la flexibilité
SI TABLE_CENTRE == VIDE : RETOURNER TABLE_CENTRE
SI TABLE_GAUCHE == VIDE : RETOURNER TABLE_GAUCHE
SI TABLE_DROITE == VIDE : RETOURNER TABLE_DROITE
// Aucune table vide → forcer une évacuation
évacuer_table_prioritaire(PK)
RETOURNER choisir_table_nouvelle_palette_fille(PK)
```
## Optimisation ping-pong
Le ping-pong est l'optimisation principale pour le débit. Il n'est
possible que lorsque la **palette fille est au centre** : les palettes
sources alternent alors entre TABLE_GAUCHE et TABLE_DROITE, de sorte
que la palette suivante est déjà en place quand l'opérateur termine.
```
FONCTION choisir_côté_ping_pong(PK) :
SI TABLE_GAUCHE.état ∈ {PALETTE_SOURCE_EN_PICKING,
PALETTE_SOURCE_EN_ATTENTE} :
RETOURNER TABLE_DROITE
SI TABLE_DROITE.état ∈ {PALETTE_SOURCE_EN_PICKING,
PALETTE_SOURCE_EN_ATTENTE} :
RETOURNER TABLE_GAUCHE
// Aucun côté occupé → choix arbitraire
RETOURNER TABLE_GAUCHE
```
**Recentrage** : si la palette fille est sur un côté (issue d'un
picking négatif), le ping-pong est impossible. Si le nombre de
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é
Lorsqu'aucune table n'est libre et qu'il faut en libérer une :
```
FONCTION évacuer_table_prioritaire(PK) :
// 1. Palette vide → retrait manuel (pas d'AGV)
// 2. Table déjà en attente d'évacuation → attendre AGV
// 3. Palette source en attente, non réutilisée par
// la prochaine tâche → AGV vers buffer/ASRS
// 4. Palette fille en attente → AGV vers image de quai
// 5. Palette source en attente (même si réutilisée)
// → AGV vers buffer ES
```
## Gestion des buffers ES → PK
Quand une table se libère au PK, le WMS choisit parmi les palettes en
buffer affectées à ce PK :
- Tri par `Line.CstAtt` **croissant** (plus petit = plus prioritaire)
- La première palette compatible avec la table libérée est envoyée
**Règle critique** : l'ordre de sortie des buffers est dicté par
`Line.CstAtt`, **pas** par l'ordre d'arrivée physique en buffer.
## Palettes multi-commandes
Une palette source peut être assignée à plusieurs OS.
Après picking de la commande en cours :
- Si la palette a encore des tâches pour d'autres OS → marquée
`MULTI_COMMANDE`, envoyée vers un buffer ES libre
- Elle reste en buffer jusqu'au lancement de l'OS suivant
- Une palette multi-commande au PK ou en mouvement compte comme une
place buffer occupée dans le calcul de `MAX_PRELOAD_PAR_PK`
## Priorité d'accès aux buffers entre PK
Lorsque les buffers ES sont saturés, la priorité est définie par la
séquence du mode "Picking" dans `MODES_PKxx`
(voir [Modes de travail PK](stations-picking.md)) :
- Séquence 1 = priorité la plus haute
- Quand un buffer se libère → affecté en priorité au PK avec la
séquence la plus basse parmi ceux qui ont des palettes en attente
## Paramètres WMS
| Paramètre | Description | Défaut |
|-----------|-------------|--------|
| `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) | — |
| `PK_BIGBAG` | Autorise ou non les big-bags par PK (LIM-70) | — |
## Points d'attention
⚠️ La contrainte d'adjacence est **physique** : l'opérateur ne peut pas
déplacer de sacs entre TABLE_GAUCHE et TABLE_DROITE directement.
⚠️ Le picking négatif nécessite 2 tables (palette source + adjacente
pour l'excédent), ce qui complique la gestion des cas saturés.
⚠️ Le recentrage de la palette fille (AGV) n'est déclenché que si
suffisamment de tâches de picking direct restent (≥ SEUIL_RECENTRAGE_PF).
⚠️ L'ordre de sortie des buffers suit `Line.CstAtt`, pas l'ordre FIFO
d'entrée en buffer.
## Questions ouvertes
(Aucune identifiée — algorithme V1.0 complet)
## Historique des modifications
| Date | Auteur | Modification |
|------|--------|--------------|
| 2026-05-12 | Arthur | Création depuis spec "Logique combinatoire picking - PS vers PK - V1.0" |
## Références
| Source | Type | Date |
|--------|------|------|
| Logique combinatoire picking - PS vers PK - V1.0 | Spécification technique | 27/04/2026 |
| [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 |
wiki_old_13-05-2026/limagrain/03-picking/.fuse_hidden0000003900000015
+471
View File
@@ -0,0 +1,471 @@
---
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]
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"]
last_updated: 2026-05-12
author: Arthur
---
# Séquençage des tâches de picking TK → PS
> **Résumé** : algorithme événementiel qui ordonne les tâches de picking
> depuis les transstockeurs (TK) vers les postes de sortie (PS). Il
> écrit les numéros de séquence `Line.CstAtt` sur chaque tâche et
> contrôle le flag `OS.CstAtt` pour autoriser le stacker_crane.
> **Standard EasyWMS** : → voir [Picking](../../concepts/picking.md)
> Ce qui suit documente les **spécificités Limagrain** par rapport au
> standard.
## Contexte projet
Le séquençage TK → PS est critique pour garantir que les palettes
arrivent aux postes de picking dans le bon ordre. L'algorithme
s'exécute **en amont** de l'algorithme de
[placement PS → PK](placement-ps-pk.md) : les palettes arrivent au PS
**déjà triées**.
Quatre solutions ont été envisagées avant de retenir une approche
événementielle (solution 4).
## Historique des solutions envisagées
### Solution 1 — Process isolé sur finalisation des tâches d'OS
Déclenchement à la finalisation de la création des tâches d'un 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 suite
à des imprévus dans le WMS.
### Solution 2 — Calcul dans le workflow stacker_crane
Intégration du tri directement dans les WF
`Galileo_StackerCraneSearch_PR` / `StackerCrane_SortTasks_PR`, avec
recalcul complet du pool de tâches à chaque exécution. Supprimerait le
besoin de `OS.Line.CstAtt` et `OS.CstAtt`.
**Problème** : complexité élevée (requêtes LINQ imbriquées sur les
tâches multi-OS).
### Solution 3 — Solution 1 transformée en job
Reprise du process de la solution 1 sous forme de job planifié, en
excluant les tâches de picking en cours.
**Problème** : pas assez réactif par rapport à la cadence de recherche
d'ordre des TK.
### Solution 4 — Process événementiel (retenue)
Reprise de la solution 1 déclenchée sur deux événements, avec
mécanisme de verrouillage `OS.CstAtt` pour bloquer le stacker_crane
pendant le séquençage.
**Avantages** : simple à développer, isolée et découplée du reste,
flexible et réactive.
## Changelog V1.1 (11/05/2026)
Modifications issues de la réunion Arthur + Justine (Mecalux) — Olivier
(Limagrain), croisées avec l'AF §6.4.8 et le DevOps #64854 :
- **Hiérarchie des règles** : nouvel ordre de priorité validé.
La complétude palette et l'anti-split de lignes de stock sont des
contraintes amont prioritaires sur les règles de tri
- **Picking négatif** : ajout condition cumulative poids ≥ 7 kg
- **Traitement commercial** : critère de regroupement par TC
**supprimé** (`CONTROLE_TRAITEMENT_COMMERCIAL = false`). Pas de bio
sur cet entrepôt
- **Calcul de remplissage** : méthode pro rata Bag/pal validée,
remplace la logique DevOps "Bag/pal max"
- **Poids max palette** : 1 250 kg (l'AF fait foi, corrige les 1 200 kg
du DevOps)
- **Règles confirmées** : mélange d'espèces OK, pas de gerbage,
hauteur max 1,90 m, séparateurs inter-lots hors WMS
> Voir la section [Arbitrage des contradictions](#arbitrage-des-contradictions-reu-11052026)
> pour le détail des décisions.
## Déclenchement
L'algorithme est déclenché sur **deux événements** :
### TaskCreatedEvent
Une nouvelle tâche de picking vient d'être créée (par le MINI JOB
Picking LIM-75, ou suite à une réassignation de stock).
```
SI événement.type == TaskCreatedEvent :
SI tâche.type == PICKING ET tâche.OS.statut == Released :
traiter_séquençage(tâche.OS)
```
### OutboundOrderReleasedEvent
Un OS passe au statut Released (première mise en service ou relance
après un arrêt).
```
SI événement.type == OutboundOrderReleasedEvent :
traiter_séquençage(OS)
```
## Process principal
```
FONCTION traiter_séquençage(OS) :
// ─── Étape 1 : verrouiller l'OS ───
OS.CstAtt ← false
// ─── Étape 2 : récupérer les tâches ───
toutes_tâches ← récupérer_tâches_picking(OS)
// ─── Étape 3 : filtrer ───
tâches_à_séquencer ← [t POUR t DANS toutes_tâches
SI t.statut == EN_ATTENTE]
SI tâches_à_séquencer est vide :
OS.CstAtt ← true
RETOURNER
// ─── Étape 4 : trier ───
tâches_triées ← trier_tâches(tâches_à_séquencer)
// ─── Étape 5 : écrire les séquences ───
écrire_séquences(tâches_triées)
// ─── Étape 6 : libérer l'OS ───
OS.CstAtt ← true
```
```mermaid
sequenceDiagram
participant EVT as Événement (TaskCreated / OS Released)
participant SEQ as Process séquençage
participant SC as Stacker Crane
EVT->>SEQ: Déclenche
SEQ->>SEQ: OS.CstAtt = false
Note over SC: Bloqué — ne prend pas<br/>de tâche de cet OS
SEQ->>SEQ: Récupère tâches en attente
SEQ->>SEQ: Applique tri + écrit séquences
SEQ->>SEQ: OS.CstAtt = true
Note over SC: Débloqué — reprend<br/>les tâches séquencées
```
## Contraintes amont (constitution des palettes filles)
Ces contraintes orientent le regroupement des lignes sur les palettes
filles **avant** le tri. L'algorithme de séquençage doit les respecter :
l'ordre de sortie doit être compatible avec la constitution de palettes
conformes à ces règles.
### C1. Palettes les plus complètes possible
Objectif premier — optimisation transport. Seuil de remplissage ~95%.
**Calcul : pro rata Bag/pal.** Chaque sac consomme `1/Bag_pal` de son
lot. Le calcul est additif et gère nativement des lots avec des Bag/pal
différents sur une même palette.
```
Exemple :
16 sacs d'un lot Bag/pal 20 + 7 sacs d'un lot Bag/pal 50
= 16/20 + 7/50
= 0,80 + 0,14
= 94%
```
Regrouper les lots de même Bag/pal sur une même palette fille facilite
la complétude.
> Cette méthode remplace la logique DevOps #64854 de "prendre le
> Bag/pal max entre lots". Le pro rata est plus précis et ne nécessite
> pas de Bag/pal de référence unique.
### C2. Ne pas splitter les lignes de stock
Éviter de répartir les sacs d'une même ligne de stock sur plusieurs
palettes. **Prioritaire sur les règles de tri** : si respecter
"Maïs first" implique de splitter une ligne, on regroupe la ligne
complète quitte à décaler le maïs.
### Autres contraintes palette
| Contrainte | Valeur | Source |
|------------|--------|--------|
| Poids max palette | **1 250 kg** | AF (corrige 1 200 kg du DevOps) |
| Hauteur max palette | 1,90 m | AF — rejet au PIE si dépassement |
| Gerbage | Interdit | — |
| Mélange d'espèces | Autorisé sur une même palette fille | — |
| Différenciation de marque | Aucune dans une même expédition | — |
| Séparateurs (intercalaires) | Règle opérateur, hors WMS | — |
## Règles de tri (séquençage des sorties ASRS)
Les tâches de picking d'un même OS sont triées selon les critères
suivants, **par ordre de priorité décroissante** :
### Critère 1 — Picking négatif en premier
Les tâches de type PICKING_NÉGATIF passent **avant** les tâches de type
PICKING_DIRECT. Prioritaire sur toutes les règles suivantes, y compris
Maïs first : si une tâche négatif concerne du tournesol, elle passe
avant une tâche maïs classique.
Condition cumulative pour la détermination NÉGATIF / DIRECT (cf.
[détermination picking négatif](#détermination-picking-négatif)) :
pourcentage quantité > seuil fiche article (défaut 55%) **ET** poids
unitaire sac ≥ 7 kg. En dessous de 7 kg, pas de picking négatif.
```
tri_1(tâche) → 0 si PICKING_NÉGATIF, 1 si PICKING_DIRECT
```
### Critère 2 — Espèce Maïs en premier
Les tâches portant sur l'espèce **Maïs** passent avant les autres
espèces. Le maïs est lourd/stable, il constitue la base de la palette
fille.
```
tri_2(tâche) → 0 si espèce == MAÏS, 1 sinon
```
### ~~Critère 3 (V1.0) — Traitement commercial~~ SUPPRIMÉ V1.1
`CONTROLE_TRAITEMENT_COMMERCIAL = false`. L'entrepôt ne fait pas de
bio. Paramètre réactivable si besoin futur.
### Critère 3 — Espèce la plus volumineuse
Les tâches sont regroupées par espèce, et l'espèce ayant la **plus
grande quantité totale de sacs** dans l'OS passe en premier. Commencer
par l'espèce la plus volumineuse permet de constituer rapidement la
base de la palette fille.
```
tri_3(tâche) → -quantité_totale_espèce(tâche.espèce, OS)
```
### Critère 4 — Article/lot le plus lourd en base
À espèce égale, les tâches portant sur les articles/lots **les plus
lourds** passent en premier. Corollaire : les semences essais, très
légères, se retrouvent naturellement en haut de palette.
```
tri_4(tâche) → -tâche.article.poids
```
### Critère 5 — Regroupement par palette source
Toutes les tâches portant sur la **même palette source** sont
consécutives. L'opérateur enchaîne toutes les tâches d'une palette
source avant de la libérer.
```
tri_5(tâche) → tâche.PALETTE_SOURCE.identifiant
```
### Récapitulatif du tri multi-critères (V1.1)
```
FONCTION trier_tâches(tâches) :
RETOURNER tâches.trier_par(
(1) type_picking ASC // NÉGATIF (0) avant DIRECT (1)
(2) espèce_maïs ASC // MAÏS (0) avant autres (1)
(3) quantité_espèce DESC // espèce la + volumineuse
(4) poids_article DESC // article le + lourd
(5) palette_source // regroupement par palette
)
```
## Écriture des séquences (Line.CstAtt)
### Règle des ex-aequo
Quand deux tâches consécutives sont **interchangeables** (l'ordre entre
elles n'a aucun impact fonctionnel), elles reçoivent le **même numéro
de séquence**. Cela laisse de la flexibilité au stacker_crane pour
optimiser son débit.
### Critères d'interchangeabilité
Deux tâches A et B sont interchangeables si :
- Elles portent sur la **même palette source**, **OU**
- Elles portent sur des **palettes sources différentes** mais tous les
critères de tri sont identiques : même type de picking, même espèce,
même quantité espèce, même poids article
### Algorithme d'écriture
```
FONCTION écrire_séquences(tâches_triées) :
séquence_actuelle ← max(Line.CstAtt des tâches en cours) + 1
SI aucune tâche en cours :
séquence_actuelle ← 1
POUR i DE 0 À len(tâches_triées) - 1 :
tâche ← tâches_triées[i]
tâche.Line.CstAtt ← séquence_actuelle
SI i < len(tâches_triées) - 1 :
tâche_suivante ← tâches_triées[i + 1]
SI interchangeables(tâche, tâche_suivante) :
CONTINUER
SINON :
séquence_actuelle ← séquence_actuelle + 1
```
### Exemple
```
Commande avec 5 tâches, après tri :
Tâche 1 : Palette A, Maïs, 500kg → séq 1
Tâche 2 : Palette B, Maïs, 500kg → séq 1 (interchangeable)
Tâche 3 : Palette C, Maïs, 500kg → séq 1 (interchangeable)
Tâche 4 : Palette D, Blé, 300kg → séq 2 (espèce différente)
Tâche 5 : Palette E, Blé, 300kg → séq 2 (interchangeable)
Résultat Line.CstAtt : [1, 1, 1, 2, 2]
Le stacker_crane peut sortir A, B, C dans n'importe quel ordre,
puis D ou E dans n'importe quel ordre.
```
## Comportement du stacker_crane après séquençage
Le stacker_crane **ignore** les tâches dont `OS.CstAtt == false`,
consomme celles dont `OS.CstAtt == true` par `Line.CstAtt` croissant,
et entre tâches à séquence égale il optimise librement (proximité ASRS,
charge TK). Il crée les tâches de mouvement TK → PS.
Les palettes arrivent ensuite au PS, où l'algorithme de
[placement PS → PK](placement-ps-pk.md) décide sur quelle table les
poser.
## Détermination picking négatif
Le type de picking (NÉGATIF ou DIRECT) est déterminé **par tâche** au
moment de la création des tâches par le MINI JOB Picking (LIM-75) :
```
SI quantité_à_prélever > seuil_article × quantité_palette_source
ET article unique dans la palette source
ET pas d'attribut logistique à capturer
ET poids_unitaire_sac ≥ 7 kg
ALORS → PICKING_NÉGATIF
SINON → PICKING_DIRECT
```
Le seuil % reste paramétrable par fiche article (champ "Complete
quantity percent excess for negative picking", défaut : 55%).
La détermination se fait **en amont** (MINI JOB Picking, LIM-75), avant
l'algorithme de séquençage. L'algorithme de séquençage lit ce type mais
ne le calcule pas.
## Cas particuliers
### Recalcul suite à une nouvelle tâche (réassignation de stock)
Si une tâche est créée après que l'OS a déjà été séquencé, le
`TaskCreatedEvent` déclenche un recalcul : verrouillage, re-tri des
tâches en attente uniquement (en commençant après le dernier numéro des
tâches en cours), puis libération.
### Relance d'un OS arrêté
Si un OS est arrêté puis relancé (`OutboundOrderReleasedEvent`), le
même process s'applique. Les tâches en cours conservent leur séquence,
les tâches en attente sont re-séquencées.
## Arbitrage des contradictions (réu. 11/05/2026)
Analyse comparative de 3 sources (DevOps #64854, AF §6.4.8, réunion
11/05/2026 Arthur + Justine + Olivier). **Tous les points sont résolus.**
| Sujet | DevOps | AF | Réunion (fait foi) |
|-------|--------|----|--------------------|
| Traitement commercial | À creuser | Séparation stricte | **Supprimé** (`CONTROLE_TRAITEMENT_COMMERCIAL = false`) |
| Seuil picking négatif | Pas de seuil explicite | > 50% | **Deux conditions cumulatives** : % seuil fiche article (défaut 55%) ET poids sac ≥ 7 kg |
| Poids max palette | 1 200 kg | 1 250 kg | **1 250 kg** (AF fait foi) |
| Picking négatif vs Maïs first | Pas de hiérarchie | Maïs en tête, négatif séparé | **Picking négatif prioritaire** (confirmé Olivier) |
| Semences essais en haut | Oui (dédié) | Non mentionné | **Couvert par règle du plus lourd en base** (essais = légères → haut) |
| Lots même Bag/pal | Prioriser regroupement | — | **Retenu** (WF palettes complètes) |
| Différenciation marque | Aucune | — | **Confirmé** |
| Calcul Bag/pal multi-lots | "Prendre le Bag/pal max" | Équivalent palette | **Pro rata** (chaque sac = 1/Bag_pal de son lot) |
## Paramètres WMS
| Paramètre | Description | Défaut | Statut V1.1 |
|-----------|-------------|--------|-------------|
| `CONTROLE_TRAITEMENT_COMMERCIAL` | Regroupement par TC dans le tri | ~~true~~ | **false** — désactivé |
| Seuil picking négatif (fiche article) | "Complete quantity percent excess for negative picking" | 55% | Inchangé |
| Poids min picking négatif | Poids unitaire sac minimum pour autoriser le picking négatif | **7 kg** | **Nouveau V1.1** |
| Seuil remplissage palette | Taux cible remplissage palette fille | **~95%** | **Nouveau V1.1** |
| Poids max palette | Poids maximum palette fille | **1 250 kg** | Corrigé (était 1 200 kg) |
| `OS.CstAtt` | Flag verrouillage OS pendant séquençage (true = stacker_crane autorisé) | true | Inchangé |
| `MAX_NB_BUFFER_PK` | Nombre de buffers disponibles par PK | 3 | Inchangé |
## Points d'attention
⚠️ Le custom LIM-61 (vérification capacité buffer) doit être modifié
pour prendre en compte les palettes multi-PK.
⚠️ Le verrouillage `OS.CstAtt` est temporaire (durée du séquençage) —
en cas d'erreur du process, l'OS risque de rester bloqué.
⚠️ Les tâches **en cours** sont exclues du séquençage — seules les
tâches en attente sont réordonnées.
⚠️ La condition poids ≥ 7 kg pour le picking négatif est ajoutée pour
éviter l'instabilité palette (gros sacs ramenés sur petits sacs).
## Points non traités (hors scope)
- Affichage opérateur au PK (combien de sacs ajouter, possibilité de
dévier de la consigne) — à traiter une fois les fondations posées
- Picking négatif < 7 kg en option (avantage opérationnel sans
obligation) — nécessite discussion élargie
- Messagerie carton (moins prioritaire, navette du lendemain, zone
angle Est) — en attente de précisions
- Verrou réception → recomptage avant picking (mentionné dans l'AF
uniquement, non reconfirmé)
## Questions ouvertes
- [ ] Comportement en cas d'erreur du process de séquençage — OS reste
bloqué avec CstAtt = false ? (@Nicolas)
- [ ] Impact sur les performances si beaucoup d'OS sont Released
simultanément — risque de contention sur les événements ? (@Fabien)
## Historique des modifications
| Date | Auteur | Modification |
|------|--------|--------------|
| 2026-05-12 | Arthur | Création initiale depuis LIM-84 |
| 2026-05-12 | Arthur | Refonte complète : intégration spec V1.1 (algo complet, contraintes amont, 5 critères tri, écriture séquences, ex-aequo, cas particuliers) + arbitrage contradictions réunion 11/05/2026 |
## Références
| Source | Type | Date |
|--------|------|------|
| [LIM-84](https://easywmsfrance.atlassian.net/browse/LIM-84) | Ticket Jira | 2026 |
| [LIM-61](https://easywmsfrance.atlassian.net/browse/LIM-61) | Ticket Jira (custom capacité buffer) | 2026 |
| Logique combinatoire picking - TK vers PS - V1.1 | Spécification technique | 11/05/2026 |
| REU PICKING SEQUENCAGE 11-05-2026 | CR réunion + analyse comparative | 11/05/2026 |
| DevOps #64854 | Note historique | — |
| AF §6.4.8 | Analyse fonctionnelle V1.5 | 28/11/2025 |
wiki_old_13-05-2026/limagrain/03-picking/.fuse_hidden0000003b00000016
+301
View File
@@ -0,0 +1,301 @@
---
title: "Stations et postes de travail Limagrain"
tags: [picking, stations, postes, ilots, buffer]
status: draft
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
author: Arthur
---
# Stations et postes de travail Limagrain
> **Résumé** : description des stations de l'entrepôt automatique, des
> postes de travail polyvalents (3 îlots × 2 postes) et des buffers associés.
> **Standard EasyWMS** : → voir [Stations & Routes](../../concepts/stations.md),
> [Mechanical Elements](../../concepts/mechanical-elements.md)
> Ce qui suit documente les **spécificités Limagrain** par rapport au standard.
## Contexte projet
Chez Limagrain, les postes de travail sont **polyvalents** et multi-processus.
L'ensemble des opérations (réception, picking, regroupement, échantillonnage,
re-certification) se fait sur les mêmes postes physiques, configurables
dynamiquement.
## Cartographie des stations
### Zone entrée production / sortie expéditions
| Station | Description |
|---------|-------------|
| PIE_01 | Poste d'identification 01 (côté quais) |
| NAV_01 | Navette 01 |
### Zone entrée/sortie postes de travail
| Station | Description |
|---------|-------------|
| PIE_02 | Poste d'identification 02 |
| PIE_03 | Poste d'identification 03 |
| REAC_01 | Poste de reconditionnement 01 |
| NAV_02 | Navette 02 |
| ET_21, ET_22 | Tables intermédiaires |
### Zone stockage côté postes de travail
| Station | Description |
|---------|-------------|
| ET_23 à ET_28 | Tables intermédiaires 23 à 28 |
| TE_01 à TE_04 | Tables d'entrée 01 à 04 |
| TS_01 à TS_04 | Tables de sortie 01 à 04 |
### Zone stockage côté quais
| Station | Description |
|---------|-------------|
| ET_11 à ET_15 | Tables intermédiaires 11 à 15 |
| TE/TS_01 à TE/TS_04 | Tables mixtes entrée/sortie 01 à 04 |
### Zone postes de travail
| Station | Description |
|---------|-------------|
| P1 à P6 | Postes de travail 01 à 06 |
| TP11 à TP63 | Tables de préparation 11 à 63 |
## Postes de travail — Architecture physique
### 3 îlots de 2 postes
Physiquement, il y a **3 îlots**, chacun composé de **6 tables de préparation
(TP)**. Chaque îlot peut être configuré de 2 façons :
1. **Mode scindé** : 2 postes individuels × 3 TP chacun (mode par défaut)
2. ~~**Mode global** : 1 poste × 6 TP (mode « esclave »)~~ **ABANDONNÉ**
> **MISE À JOUR** : le mode esclave (6 TP) est abandonné au profit d'un
> simple **message d'avertissement**. Si le poste adjacent est déjà
> ouvert → « Attention, le poste PVx est déjà ouvert. Voulez-vous quand
> même ouvrir ? ». L'opérateur peut confirmer ou annuler. Pas de blocage
> technique, juste un avertissement.
>
> **Justification** : les opérateurs sont physiquement à ~2 mètres l'un
> de l'autre et peuvent se coordonner verbalement. Les AGV ont des
> capteurs de sécurité et demandent l'autorisation de dépose. Trop de cas
> complexes à gérer avec un mode esclave custom. L'AGV amène toujours la
> palette au centre du PV actif.
>
> **Développement** : message d'avertissement à l'ouverture du poste,
> vérification si le poste conjoint est déjà ouvert (via support présent
> ou poste en mode réception), workflow action sur le end process pour
> fermer le poste.
### Numérotation
```
Îlot 1 : P1 (TP11, TP12, TP13) | P2 (TP21, TP22, TP23)
Îlot 2 : P3 (TP31, TP32, TP33) | P4 (TP41, TP42, TP43)
Îlot 3 : P5 (TP51, TP52, TP53) | P6 (TP61, TP62, TP63)
```
### Spécificités P5 & P6
Les postes **P5 et P6** sont équipés d'un **palan** pour la manipulation
de big-bags. Toute opération impliquant un big-bag (bag/pal ≤ 2) doit
être traitée sur P5 ou P6.
**Picking** : WS PK picking rob en priorité, process RF comme fallback
(plus robuste pour picking négatif, multi-tables). Le process de réception
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)
pour les règles détaillées (arrivée palettes 3 TP, algorithme répartition,
ordonnancement par gerbabilité).
### Modes de travail — Configuration et fonctionnement
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
ouvre le poste et le WMS gère automatiquement le process en fonction de
la palette qui arrive.
#### Modes disponibles
| Mode | Correspondance EasyWMS |
|------|------------------------|
| Picking | Picking |
| Réception | Réception |
| Regroupement | Consolidation |
| Échantillonnage | Inventaire |
| Re certification | Picking |
> ~~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)
Dans la vue des postes de travail, un **bouton d'action "Choix modes de
travail"** est disponible à la sélection d'un ou plusieurs PK. Ce bouton
ouvre une **vassist** qui permet de :
- **Cocher/décocher les modes autorisés** parmi les 5 modes ci-dessus
- **Définir la priorité** de chaque mode coché via un champ numérique
(séquence)
**Règles de validation** à la soumission :
- Chaque mode coché doit avoir une priorité renseignée
- Un mode non coché ne doit pas avoir de priorité
- Au moins un mode doit être coché (pour bloquer un PK, utiliser le
bouton standard dédié)
**Stockage** : la configuration est enregistrée dans un **paramètre
SmartUI dédié par PK** au format :
```
MODES_PK01 = "RECEPTION;1|PICKING;2|CONSOLIDATION;3"
MODES_PK02 = "RECEPTION;1"
```
Chaque entrée : `MODE;PRIORITÉ` séparés par `|`.
Cette configuration est utilisée par le
[Mega Job d'assignation](job-assignation-pk.md)
([LIM-70](https://easywmsfrance.atlassian.net/browse/LIM-70)) pour
déterminer si un PK est éligible à recevoir des tâches d'un flux donné
et dans quel ordre de priorité.
#### Ouverture du poste par l'opérateur (SmartUI)
L'opérateur accède à **Poste de travail > Station de picking**.
L'interface affiche un **bouton "Fermer le poste"** toujours visible.
Par défaut, le poste fonctionne en **tâche automatique** : le WMS
choisit le bon process en fonction de la palette qui arrive ou qui est
déjà sur le PK. L'opérateur n'a pas à sélectionner manuellement un mode.
#### Avertissement poste adjacent
À chaque ouverture d'un PK, le WMS vérifie si le **poste adjacent** est
déjà ouvert (en mode actif). Le mapping des paires est défini dans le
paramètre `PK_ADJACENT`.
**Si le poste adjacent est actif** → message d'avertissement (y compris
en mode tâche automatique) :
> "Attention, le poste [CODE_PK_ADJACENT] est déjà ouvert.
> Voulez-vous quand même ouvrir ?"
- Bouton **Confirmer** : le PK s'ouvre normalement
- Bouton **Annuler** : le PK reste inactif
**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.
#### Fermeture du poste
Le bouton **"Fermer le poste"** est toujours visible quel que soit l'état.
Au clic :
- Le PK est remis en mode **inactif** (aucun mode actif)
- Le PK redevient éligible pour une nouvelle assignation par le
[Mega Job](job-assignation-pk.md) (sous réserve qu'il n'ait plus de
tâches actives)
#### Paramètres modes de travail
| Paramètre | Description | Valeur par défaut | Exemple |
|-----------|-------------|-------------------|---------|
| 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` |
### Équipement par poste
- 1 poste léger EasyWMS dupliqué sur 2 écrans
- 1 imprimante Zebra (étiquettes HU RFID)
- 1 imprimante A4 (étiquettes A4)
- 1 douchette multi-format (RFID, QR Code, code à barres)
## [CUSTOM] Mega Job d'assignation des tâches aux postes
→ Voir page dédiée : **[Job d'assignation PK](job-assignation-pk.md)**
([LIM-70](https://easywmsfrance.atlassian.net/browse/LIM-70))
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,
regroupement, échantillonnage, re certification).
## Buffer postes de travail
16 emplacements palettes au sol le long de l'allée TK_01 :
| Nb emplacements | Usage |
|-----------------|-------|
| 14 | Avance pour les processus en cours |
| 2 | Piles de palettes vides |
> ⚠️ 2 emplacements supplémentaires pour palettes rejetées en attente de
> libération d'un poste de travail.
### [CUSTOM] Buffer configurable
Les emplacements du buffer sont **interchangeables** : un champ « type de
fonctionnement » peut être modifié quand l'emplacement est vide.
### [CUSTOM] Bouton d'évacuation
Un bouton spécifique sur l'écran EasyWMS permet d'évacuer automatiquement
une palette du buffer vers le convoyeur d'entrée pour stockage.
## Piles de palettes vides par poste
- **2 piles par îlot de travail** (et non par poste individuel)
- 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 —
l'opérateur choisit la pile à réapprovisionner parmi une liste
Voir [Palettes vides](../02-stockage/palettes-vides.md) pour le détail.
## Points d'attention
⚠️ Un poste fermé ne peut pas être assigné à un processus.
⚠️ L'assignation automatique du poste optimise la distance la plus courte.
⚠️ Si une TP est HS, elle peut être bloquée individuellement sans impacter
le reste du poste.
⚠️ L'entrée côté postes de travail et l'entrée côté quais sont
interchangeables manuellement en cas de blocage long terme (bouton de
redirection).
## Questions ouvertes
- [ ] Détail de la gestion des tables de préparation bloquées (@Nicolas)
## Historique des modifications
| Date | Auteur | Modification |
|------|--------|--------------|
| 2026-05-05 | Arthur | Création initiale depuis AF V1.5 |
| 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) |
## Références
| Source | Type | Date |
|--------|------|------|
| 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 |
wiki_old_13-05-2026/limagrain/03-picking/.fuse_hidden0000003d00000017
+50
View File
@@ -0,0 +1,50 @@
---
title: "Picking — Vue d'ensemble"
tags: [picking, combinatoire, stations, index]
status: draft
last_updated: 2026-05-12
---
# 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.
> **Standard EasyWMS** : voir [Picking](../../concepts/picking.md)
## Pages de cette section
- [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)
- [Placement PS → PK (choix de table)](placement-ps-pk.md)
- [Consolidation / Regroupement](consolidation-regroupement.md)
- [Échantillonnage](echantillonnage.md)
## Vue synthétique du picking Limagrain
```mermaid
flowchart TD
OS[OS libéré + stock assigné] --> SEQ[Séquençage TK → PS]
SEQ --> TRI["Tri : négatif > maïs > volume > poids"]
TRI --> PS[Palette arrive au PS]
PS --> PLACE[Placement PS → PK]
PLACE --> TABLE{Table ou buffer ?}
TABLE -->|Table libre| PICK[Prélèvement au PK]
TABLE -->|Buffer ES| WAIT[Attente buffer]
WAIT --> PICK
PICK --> NEG{"Picking négatif ?\n(% > 55% ET ≥ 7 kg)"}
NEG -->|Oui| PNEG[Picking négatif]
NEG -->|Non| PPOS[Picking direct]
PNEG --> FILM[Choix filmage]
PPOS --> FILM
FILM --> PIE[Passage PIE]
PIE --> DEFRAG[Zone défrag client]
```
> **Note** : le picking AF V1.5 a depuis évolué vers le modèle
> « picking combinatoire » CR V3.0 (4 jobs, CstAtt). Les pages de cette
> section couvrent les deux versions.
wiki_old_13-05-2026/limagrain/03-picking/_index.md
+46
View File
@@ -0,0 +1,46 @@
---
title: "Picking — Vue d'ensemble"
tags: [picking, combinatoire, stations, index]
status: draft
last_updated: 2026-05-12
---
# 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.
> **Standard EasyWMS** : voir [Picking](../../concepts/picking.md)
## Pages de cette section
- [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)
- [Placement PS → PK (choix de table)](placement-ps-pk.md)
- [Consolidation / Regroupement](consolidation-regroupement.md)
- [Échantillonnage](echantillonnage.md)
## Vue synthétique du picking Limagrain
```mermaid
flowchart TD
OS[OS libéré + stock assigné] --> SEQ[Séquençage TK → PS]
SEQ --> TRI["Tri : négatif > maïs > volume > poids"]
TRI --> PS[Palette arrive au PS]
PS --> PLACE[Placement PS → PK]
PLACE --> TABLE{Table ou buffer ?}
TABLE -->|Table libre| PICK[Prélèvement au PK]
TABLE -->|Buffer ES| WAIT[Attente buffer]
WAIT --> PICK
PICK --> NEG{"Picking négatif ?\n(% > 55% ET ≥ 7 kg)"}
NEG -->|Oui| PNEG[Picking négatif]
NEG -->|Non| PPOS[Picking direct]
PNEG --> FILM[Choix filmage]
PPOS --> FILM
FILM --> PIE[Passage PIE]
wiki_old_13-05-2026/limagrain/03-picking/consolidation-regroupement.md
+148
View File
@@ -0,0 +1,148 @@
---
title: "Consolidation (regroupement) — Processus sur poste"
tags: [picking, regroupement, consolidation, MOV, poste, custom]
status: draft
standard_ref: concepts/picking.md
jira_refs: []
confluence_refs: []
sources: [FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5.docx]
last_updated: 2026-05-05
author: Arthur
---
# 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.
> **Standard EasyWMS** : → voir [Picking](../../concepts/picking.md)
> Ce qui suit documente les **spécificités Limagrain** par rapport au standard.
## Contexte projet
Le regroupement permet de vider des palettes partiellement remplies en
déplaçant leur stock vers d'autres palettes contenant le même stock.
L'objectif est de libérer des emplacements dans l'ASRS.
## Critères de consolidation
Le regroupement est proposé quand deux palettes ou plus partagent :
- Article
- Lot SAP
- Propriétaire
- Statut de stock
- Flag anoxie
## [CUSTOM] Vue de proposition de regroupement
Une vue spécifique est développée pour Limagrain. Elle présente :
- Les palettes candidates au regroupement
- Le gain potentiel en nombre de palettes
**Règle** : le regroupement n'est proposé que s'il permet de gagner au
moins 1 palette. Exemple : Bag/Pal = 75, si palette H1 = 73 et H2 = 5
→ pas de regroupement (73 + 5 = 78 > 75, pas de gain).
L'opérateur sélectionne un ou plusieurs ordres de regroupement depuis
cette vue.
## Processus complet
```mermaid
flowchart TD
VUE[Vue proposition regroupement] --> SELECT[Sélection ordres]
SELECT --> ASSIGN[Assignation poste automatique]
ASSIGN --> TACHE[Création tâches mouvement]
TACHE --> ORD[Ordonnancement palettes au poste]
ORD --> VERROU{Verrou « Réception » ?}
VERROU -->|Oui| RECOUNT[Recomptage]
VERROU -->|Non| PICK[Déplacement sacs]
RECOUNT --> PICK
PICK --> VIDE{Palette vidée ?}
VIDE -->|Oui| DEGAGE[Dégagement palette vide]
VIDE -->|Non| PICK
DEGAGE --> EVAC[Évacuation palette stock]
EVAC --> FILM[Choix filmage]
FILM --> PIE[Passage PIE]
PIE --> STOCK[Stockage ASRS]
```
## Assignation poste de travail
- Assignation **automatique** quand un ordre est lancé
- [CUSTOM] Si le lot a un Bag/Pal ≤ 2 → considéré « big-bag » →
seul le **poste P6** (équipé d'un palan) est assignable
- Un big-bag ne peut être consolidé que sur un autre big-bag
- Si P6 n'est pas en mode regroupement → tâche en attente
- Si aucun poste disponible → ordre en attente de libération
## [CUSTOM] Ordonnancement des palettes au poste
Une fois l'ordre lancé et le poste assigné, les palettes arrivent dans
cet ordre :
1. **Minimum de mouvements palette** (moins de déplacements physiques)
2. **Minimum de mouvements sac** (moins de manipulations)
3. **Palette complète** (en priorité la palette destinataire)
## Exécution sur poste
1. [CUSTOM] Si verrou « Réception » → recomptage avant regroupement
2. Les sacs de la palette à éliminer sont déplacés vers la palette
destinataire
3. Quand la palette est vidée → dégagement de la table de préparation
4. Évacuation de la palette avec stock restant via bouton EasyWMS
5. [CUSTOM] Choix filmage depuis vue spécifique (programme à définir)
6. [CUSTOM] Message **MOV** à chaque déplacement de stock :
- Palette d'origine
- Palette de destination
- Nouvelle palette ? (Oui/Non)
- Quantité + caractéristiques (article, lot SAP, ...)
## Passage PIE post-regroupement
Contrôle identique aux autres processus :
- Dimensions max : 1300 × 1100 × 1900 mm
- Poids max : 1250 kg
- État palette bois correct
- Étiquette RFID connue
[CUSTOM] Calcul poids de référence :
```
Poids réf = Σ (Poids_unité_ligne_i × quantité_ligne_i) + poids_palette_bois
```
Vérification avec tolérance par type d'article (voir
[Contrôle qualité réception](../01-inbound/controle-qualite-reception.md)).
## Points d'attention
⚠️ 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
simultanément pendant le regroupement.
⚠️ Un big-bag ne peut être consolidé que sur un autre big-bag (contrainte
physique + système).
## Questions ouvertes
- [ ] Programme de filmage exact pour le regroupement (@Théo)
- [ ] Interface opérateur vue regroupement — maquette validée ? (@Fabien)
## Historique des modifications
| Date | Auteur | Modification |
|------|--------|--------------|
| 2026-05-05 | Arthur | Création initiale depuis AF V1.5 |
## Références
| Source | Type | Date |
|--------|------|------|
| FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5 | Analyse fonctionnelle | 28/11/2025 |
wiki_old_13-05-2026/limagrain/03-picking/echantillonnage.md
+145
View File
@@ -0,0 +1,145 @@
---
title: "Échantillonnage — Processus de contrôle qualité"
tags: [picking, échantillonnage, inventaire, qualité, poste, custom]
status: draft
standard_ref: concepts/inventory.md
jira_refs: []
confluence_refs: []
sources: [FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5.docx]
last_updated: 2026-05-05
author: Arthur
---
# É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.
> **Standard EasyWMS** : → voir [Inventory](../../concepts/count.md)
> Ce qui suit documente les **spécificités Limagrain** par rapport au standard.
## Contexte projet
L'échantillonnage sert au contrôle qualité sur une partie des lots
produits. Il consiste à prélever environ 200 grammes dans une partie du
stock sélectionné. Le prélèvement est ensuite analysé pour valider la
qualité du produit fini.
Dans EasyWMS, ce processus est assimilé à un **inventaire** (ordre
d'inventaire).
## Création de l'ordre d'échantillonnage
Deux modes de création :
| Mode | Origine | Détail |
|------|---------|--------|
| Interface ERP | Message de l'ERP (COR) | Spécifie un lot à inventorier |
| Manuel | Interface EasyWMS | Choix d'un lot par l'opérateur |
[CUSTOM] Un champ texte est disponible pour donner des **consignes**
rattachées à l'ordre d'inventaire.
## [CUSTOM] Assignation du stock
L'assignation diffère selon le mode de création :
### Création par interface ERP
- Maximum **4 palettes** échantillonnées :
- Si stock global < 4 → toutes les palettes
- 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
### Création manuelle
- Nombre de palettes choisi par l'opérateur
## Assignation poste de travail
- Automatique, à condition que le poste soit ouvert et autorise le
mode « échantillonnage »
- 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
```mermaid
flowchart TD
ORDRE[Ordre échantillonnage] --> ASSIGN[Assignation stock]
ASSIGN --> POSTE[Assignation poste auto]
POSTE --> TACHE[Tâches mouvement créées]
TACHE --> ARRIVE[Palette arrive sur TP]
ARRIVE --> VERROU{Verrou « Réception » ?}
VERROU -->|Oui| RECOUNT[Recomptage]
VERROU -->|Non| PRELEV[Prélèvement ~200g]
RECOUNT --> PRELEV
PRELEV --> ETIQ[Impression étiquette échantillonnage]
ETIQ --> SCOTCH[Scotch sac ouvert]
SCOTCH --> FILM[Choix filmage]
FILM --> EVAC[Évacuation → PIE → stockage]
EVAC --> NEXT{Palette suivante ?}
NEXT -->|Oui| ARRIVE
NEXT -->|Non| FIN[Fin ordre]
```
Les 3 tables de préparation peuvent être occupées simultanément.
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
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**
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)
9. Évacuer la palette vers le stockage
## Passage PIE post-échantillonnage
Contrôle identique aux autres processus :
- Dimensions max : 1300 × 1100 × 1900 mm
- Poids max : 1250 kg
- Étiquette RFID connue
- État palette bois correct
[CUSTOM] Poids de référence recalculé + vérification avec tolérance
(voir [Contrôle qualité réception](../01-inbound/controle-qualite-reception.md)).
Si PIE NOK → rejet vers poste d'origine. Possibilité de forcer le
passage en cas d'excédent de poids non corrigeable.
## Points d'attention
⚠️ L'échantillonnage est un processus d'**inventaire** dans EasyWMS,
pas un processus de picking — important pour le paramétrage des modes
de poste.
⚠️ Les palettes avec verrou « Production » (écart poids) sont traitées
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).
## Questions ouvertes
- [ ] Le prélèvement de 200g est-il déduit du stock ou négligé ? (@Nicolas)
- [ ] Programme de filmage exact (@Théo)
- [ ] Format de l'étiquette d'échantillonnage — validé ? (@Justine)
## Historique des modifications
| Date | Auteur | Modification |
|------|--------|--------------|
| 2026-05-05 | Arthur | Création initiale depuis AF V1.5 |
## Références
| Source | Type | Date |
|--------|------|------|
| FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5 | Analyse fonctionnelle | 28/11/2025 |
wiki_old_13-05-2026/limagrain/03-picking/job-assignation-pk.md
+145
View File
@@ -0,0 +1,145 @@
---
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]
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"]
last_updated: 2026-05-12
author: Arthur
---
# 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
> modes autorisés et leur priorité. Évite la concurrence entre
> mini-jobs indépendants.
> **Standard EasyWMS** : → voir [Picking](../../concepts/picking.md),
> [Stations & Routes](../../concepts/stations.md)
> Ce qui suit documente les **spécificités Limagrain** par rapport au
> standard.
## Contexte projet
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
orchestration centralisée, ces flux se feraient concurrence.
Le Mega Job est un **job unique** avec une entête qui analyse l'ensemble
des supports concernés et, selon leur emplacement d'origine et leurs
caractéristiques, délègue à des **sous-workflows** dédiés.
## Éligibilité d'un PK
Pour qu'un poste soit éligible à une nouvelle assignation, **toutes** les
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
- **Le poste est ouvert** (mode actif)
- **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.
## Logique principale
```mermaid
flowchart TD
A[Début du job] --> B[Lister les PK ouverts]
B --> C{PK éligible ?}
C -- Non --> D[PK suivant]
C -- Oui --> E[Lire MODES_PKxx]
E --> F{Paramètre existe et non vide ?}
F -- Non --> D
F -- Oui --> G[Trier les modes par priorité]
G --> H[Exécuter sous-WF du mode priorité 1]
H --> I{Tâche assignée ?}
I -- Oui --> D
I -- Non --> J[Exécuter sous-WF du mode priorité 2]
J --> K{Tâche assignée ?}
K -- Oui --> D
K -- Non --> L[... mode suivant ...]
L --> D
D --> M{Autres PK ?}
M -- Oui --> C
M -- Non --> N[Fin du job]
```
Pour chaque PK éligible :
1. Le WMS récupère le paramètre `MODES_PKxx` (x = numéro du poste)
2. Les modes sont triés par priorité croissante
3. Le sous-workflow du mode de priorité la plus haute est exécuté
4. Si le sous-WF a assigné une tâche → passage au PK suivant
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
## Gestion des Big-Bags
Le paramètre `PK_BIGBAG` définit quels PK autorisent la présence de
big-bags (physiquement : P5 et P6 avec palan).
- Les ordres contenant des supports big-bag sont **interdits** sur les
PK qui ne les autorisent pas
- Ces ordres sont **prioritaires** (en respectant le séquençage des
process en première priorité) sur les PK qui les autorisent
## Sous-workflows
Le Mega Job délègue la création effective des tâches à des sous-workflows
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 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 |
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)
Ce sous-workflow est appelé par le Mega Job quand le mode **Picking** est
actif sur un PK. Il assigne un ordre de sortie (commande) au poste.
### Éligibilité du PK pour une commande
Le PK peut recevoir une commande si **toutes** les conditions sont
remplies :
- Le PK **autorise la préparation de commande** (mode Picking actif)
- 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
```mermaid
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)
Les commandes de **classe Messagerie** sont expédiées le jour même et
sont donc **prioritaires**
wiki_old_13-05-2026/limagrain/03-picking/picking-combinatoire.md
+192
View File
@@ -0,0 +1,192 @@
---
title: "Picking sur poste de travail — Expédition client"
tags: [picking, poste, expédition, ordonnancement, MOV, PCK]
status: draft
standard_ref: concepts/picking.md
jira_refs: [LIM-82]
confluence_refs: []
sources: [FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5.docx, "Expédition - LIMAGRAIN - DEV - Confluence.md", "LIM-82 LOT2.2 [PICKING] Ordonnancement des tâches de picking PS PK.md", "REU PICKING SEQUENCAGE 11-05-2026 - Analyse comparative notes + AF + devops.md"]
last_updated: 2026-05-12
author: Arthur
---
# 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
> négatif et contraintes physiques.
> **Standard EasyWMS** : → voir [Picking](../../concepts/picking.md)
> Ce qui suit documente les **spécificités Limagrain** par rapport au standard.
## Contexte projet
Le picking chez Limagrain se fait sur les postes de travail automatisés
(pas de picking mobile en allée). Les palettes source et les palettes
de préparation sont acheminées par AGV sur les tables de préparation (TP).
> **Note** : cette page décrit le picking tel que défini dans l'AF V1.5.
> Le projet a depuis évolué vers un modèle « picking combinatoire »
> (CR V3.0, 4 jobs, CstAtt) qui sera documenté séparément.
## Déclenchement
Le picking est déclenché pour les commandes client (RUT type « Client »)
quand des palettes incomplètes sont nécessaires (la quantité demandée
ne correspond pas à des palettes complètes).
Prérequis : un **poste de travail assigné** (auto ou manuellement).
## [CUSTOM] Ordonnancement des palettes au poste
Une fois le poste assigné, les palettes arrivent dans cet ordre :
### Tri par espèce et gerbabilité
1. **Espèce Maïs** toujours en premier (pas la variété mais l'espèce)
2. Puis espèce avec la **plus grande quantité** dans la commande
3. Si égalité → **article/lot le plus lourd** en base de palette
**Mapping Espèce → stack (gerbabilité)** : le maïs = stack 0 (le plus
lourd/stable, donc en base). [CUSTOM] Gestion en **async sur l'ITM** pour
calculer la gerbabilité automatiquement à la création de l'article. Tri
des tâches de picking dans le workflow `StackerCrane_SortTasks_PR`.
### ~~Séparation par traitement commercial~~ SUPPRIMÉ (réu. 11/05/2026)
~~Pas de mélange entre articles avec traitement et sans traitement
sur une même palette fille.~~
**Décision** : `CONTROLE_TRAITEMENT_COMMERCIAL = false`. L'entrepôt
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)
> pour le détail de l'analyse comparative.
## [CUSTOM] Règle du picking négatif
**Deux conditions cumulatives** (réu. 11/05/2026) :
1. La quantité à prélever dépasse le **seuil fiche article** (défaut
55%, paramétrable par article via "Complete quantity percent excess
for negative picking")
2. Le **poids unitaire du sac ≥ 7 kg** (raison : instabilité palette si
gros sacs ramenés sur petits sacs)
Si les deux conditions sont remplies → **picking négatif** : au lieu de
déplacer les sacs à expédier, déplacer les sacs qui **retourneront en
stock** (moins de mouvements physiques).
Si l'une des deux conditions n'est pas remplie → picking direct
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).
## [CUSTOM] Calcul équivalent palette (pro rata Bag/pal)
Pour déterminer si une palette est « pleine », calcul en **pro rata
Bag/pal** (réu. 11/05/2026, remplace la logique DevOps "Bag/pal max") :
```
Équivalent palette d'un sac = 1 ÷ Bag/Pal de son lot
```
Le calcul est additif et gère nativement des lots avec des Bag/pal
différents sur une même palette :
```
Exemple :
15 sacs lot Bag/pal 20 + 10 sacs lot Bag/pal 75
= 15/20 + 10/75
= 0,75 + 0,133
= 88,3% → il reste ~12% de place
```
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
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
pas la tâche en cours)
- Si plus assez de stock → réassignation ailleurs + retrait verrou
## [CUSTOM] Algorithme de répartition des palettes sur les TP
Logique combinatoire complète gérant tous les cas :
- Picking négatif et enchaînement de pickings négatifs
- Ordonnancement par espèce
- Terminer une palette pleine avant d'en entamer une autre
- Cadencement des buffers devant les postes de picking
- Pas de mélange de traitement commercial (via famille d'article)
- **Contrainte** : l'opérateur ne doit **pas déplacer de sacs 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. Quand la palette de
prélèvement est vidée, l'opérateur la remet manuellement sur une pile
de palettes vides à proximité.
> Prévoir un process sans picking négatif pour les cas où c'est rarement
> utilisé (ou monter le seuil, ex : 70% au lieu de 50%).
## Processus de préparation
### Arrivée des palettes (toujours un poste 3 TP)
- Première palette au **centre** si picking négatif proposé, sinon sur
un côté
- Si une palette est sur un côté et qu'on propose du picking négatif →
prévenir l'opérateur de déplacer la palette au centre
- La palette client revient **toujours** au centre
- Pas de prépa sur 6 TP en simultané
### Picking
1. Palette source arrive sur une TP
2. Palette destination (vide ou en cours) sur une autre TP
3. Opérateur prélève les sacs (ou sacs retour si picking négatif)
4. ~~[CUSTOM] Message MOV envoyé à SAP~~ **ANNULÉ** (décision client)
5. Avant évacuation : choix filmage (CstData transmis à Galileo).
Possibilité de choisir « pas de filmage ».
6. Évacuation palette → PIE → contrôle poids → stockage/expédition
## [CUSTOM] Ordonnancement des tâches PS → PK (LIM-82)
Détail du cadencement des palettes depuis les postes de sortie (PS)
vers les postes de picking (PK). Toutes les tâches de picking se font
sur les tables élévatrices des PK.
### Règles de priorité
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
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
À chaque tâche de picking négatif :
- Un **nouveau code SSCC** est généré pour la palette où l'excédent de
stock est déposé
- Une **étiquette RFID** est imprimée pour cette nouvelle palette
- La palette de picking négatif va toujours au **centre** du PK
### Cadencement des buffers
Les palettes non encore nécessaires au PK sont dirigées vers les
**zones d'attente** (buffers ES_X) s
wiki_old_13-05-2026/limagrain/03-picking/placement-ps-pk.md
+323
View File
@@ -0,0 +1,323 @@
---
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: []
confluence_refs: []
sources: ["Logique combinatoire picking - PS vers PK - V1.0.md"]
last_updated: 2026-05-12
author: Arthur
---
# Placement des palettes PS → PK (choix de table)
> **Résumé** : algorithme exécuté par le WMS lorsqu'une palette source
> arrive au poste de sortie (PS). Il décide sur quelle table du PK la
> poser, ou la redirige vers un buffer ES. Ce process s'exécute **en
> aval** du [séquençage TK → PS](sequencage-tk-ps.md) : les palettes
> arrivent au PS déjà triées.
> **Standard EasyWMS** : → voir [Picking](../../concepts/picking.md)
> Ce qui suit documente les **spécificités Limagrain** par rapport au
> standard.
## Contexte projet
Chaque PK dispose de **3 tables** soumises à une contrainte d'adjacence
stricte :
```
TABLE_GAUCHE ←→ TABLE_CENTRE ←→ TABLE_DROITE
✅ adjacentes ✅ adjacentes
TABLE_GAUCHE ←————————————————→ TABLE_DROITE
❌ INTERDIT
```
Règles de mouvement :
- Le stock est **toujours sur une palette**, jamais posé directement sur
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** —
seul l'AGV peut déplacer une palette (arrivée, évacuation, recentrage)
- **TABLE_CENTRE** est le pivot : seule table adjacente aux deux autres
## Déclenchement
L'algorithme est appelé **à chaque arrivée physique d'une palette au
PS**. Le PS interroge le WMS qui retourne une réponse parmi :
- **TABLE_GAUCHE**, **TABLE_CENTRE** ou **TABLE_DROITE** → la palette
est envoyée sur cette table
- **Buffer ESx** → aucune table n'est disponible, la palette est
redirigée vers un emplacement buffer
- **Attente** → ni table ni buffer disponible, la palette reste au PS
## Entrées de l'algorithme
| Donnée | Source |
|--------|--------|
| Tâche courante : palette source, article, quantité, type de picking (NÉGATIF / DIRECT), `Line.CstAtt` (séquence) | Tâche associée à la palette |
| État des 3 tables du PK : VIDE, PALETTE_FILLE_ACTIVE, PALETTE_FILLE_EN_ATTENTE, PALETTE_SOURCE_EN_PICKING, PALETTE_SOURCE_EN_ATTENTE, EN_ATTENTE_EVACUATION | État temps réel du PK |
| Tâches suivantes de l'OS (triées par `Line.CstAtt` croissant) | OS en base |
| Buffers ES disponibles : parmi ES1–ES16, ceux non occupés ni ciblés | État temps réel des buffers |
| Nombre de buffers déjà affectés à ce PK vs `MAX_PRELOAD_PAR_PK` (défaut : 3) | Compteur par PK |
## Décision niveau 1 : table du PK ou buffer ?
```
FONCTION décider_destination(palette, PK) :
table_cible ← choisir_table(palette, PK)
SI table_cible ≠ NULL :
RETOURNER table_cible
// Aucune table disponible → tenter un buffer
SI nb_buffers_affectés(PK) < MAX_PRELOAD_PAR_PK :
buffer ← premier ES libre
SI buffer existe :
RETOURNER buffer
// Ni table ni buffer disponible
RETOURNER ATTENTE
```
## Décision niveau 2 : choix de la table
Le choix dépend du **type de picking** de la tâche associée.
### Cas PICKING_NÉGATIF
En picking négatif, la palette source arrive sur une table, l'opérateur
retire l'excédent sur une palette posée sur une **table adjacente**,
puis échange d'étiquettes. La palette a besoin de **2 tables** : une
pour elle, une adjacente libre pour l'excédent.
```
FONCTION choisir_table_picking_négatif(PK) :
// Priorité 1 : centre + un côté libre
SI TABLE_CENTRE == VIDE ET (TABLE_GAUCHE == VIDE
OU TABLE_DROITE == VIDE) :
RETOURNER TABLE_CENTRE
// Priorité 2 : côté + centre libre
SI (TABLE_GAUCHE == VIDE OU TABLE_DROITE == VIDE)
ET TABLE_CENTRE == VIDE :
RETOURNER côté vide
// Priorité 3 : centre libre + un côté libérable
SI TABLE_CENTRE == VIDE ET un côté est libérable :
évacuer(côté libérable)
RETOURNER TABLE_CENTRE
// Priorité 4 : un côté libre + centre libérable
SI un côté == VIDE ET TABLE_CENTRE est libérable :
évacuer(TABLE_CENTRE)
RETOURNER côté vide
// Dernier recours : évacuation forcée
évacuer_table_prioritaire(PK)
RETOURNER choisir_table_picking_négatif(PK) // rappel
```
### Cas PICKING_DIRECT
La palette source doit être posée sur une table **adjacente à la
palette fille active**. Le choix se fait en fonction de l'emplacement
de la palette fille.
```
FONCTION choisir_table_picking_direct(tâche, PK) :
// Étape 1 : localiser la palette fille compatible
table_fille ← localiser_palette_fille(tâche, PK)
SI table_fille == NULL :
table_fille ← choisir_table_nouvelle_palette_fille(PK)
// Étape 2 : choisir une table adjacente
tables_adj ← tables_adjacentes(table_fille)
// Prio A : palette source déjà sur une adjacente
// (multi-tâches même palette)
POUR chaque t DANS tables_adj :
SI t contient tâche.PALETTE_SOURCE :
RETOURNER t
// Prio B : adjacente VIDE
// Si 2 adjacentes libres (PF au centre) → ping-pong
adjacentes_vides ← [t POUR t DANS tables_adj SI t == VIDE]
SI len(adjacentes_vides) == 2 :
RETOURNER choisir_côté_ping_pong(PK)
SI len(adjacentes_vides) == 1 :
RETOURNER adjacentes_vides[0]
// Prio C : adjacente en cours d'évacuation (AGV en route)
POUR chaque t DANS tables_adj :
SI t == EN_ATTENTE_EVACUATION :
RETOURNER t
// Prio D : forcer l'évacuation d'une adjacente
t_à_libérer ← choisir_table_à_évacuer(tables_adj)
évacuer(t_à_libérer)
RETOURNER t_à_libérer
```
### Localisation de la palette fille compatible
```
FONCTION localiser_palette_fille(tâche, PK) :
// Parmi les PF actives
POUR chaque table :
SI table.état == PALETTE_FILLE_ACTIVE :
RETOURNER table
// Note : CONTROLE_TRAITEMENT_COMMERCIAL = false,
// donc pas de filtre TC
// Puis parmi les PF en attente
POUR chaque table :
SI table.état == PALETTE_FILLE_EN_ATTENTE :
RETOURNER table
RETOURNER NULL
```
### Choix de table pour une nouvelle palette fille
```
FONCTION choisir_table_nouvelle_palette_fille(PK) :
// TABLE_CENTRE = pivot → maximise la flexibilité
SI TABLE_CENTRE == VIDE : RETOURNER TABLE_CENTRE
SI TABLE_GAUCHE == VIDE : RETOURNER TABLE_GAUCHE
SI TABLE_DROITE == VIDE : RETOURNER TABLE_DROITE
// Aucune table vide → forcer une évacuation
évacuer_table_prioritaire(PK)
RETOURNER choisir_table_nouvelle_palette_fille(PK)
```
## Optimisation ping-pong
Le ping-pong est l'optimisation principale pour le débit. Il n'est
possible que lorsque la **palette fille est au centre** : les palettes
sources alternent alors entre TABLE_GAUCHE et TABLE_DROITE, de sorte
que la palette suivante est déjà en place quand l'opérateur termine.
```
FONCTION choisir_côté_ping_pong(PK) :
SI TABLE_GAUCHE.état ∈ {PALETTE_SOURCE_EN_PICKING,
PALETTE_SOURCE_EN_ATTENTE} :
RETOURNER TABLE_DROITE
SI TABLE_DROITE.état ∈ {PALETTE_SOURCE_EN_PICKING,
PALETTE_SOURCE_EN_ATTENTE} :
RETOURNER TABLE_GAUCHE
// Aucun côté occupé → choix arbitraire
RETOURNER TABLE_GAUCHE
```
**Recentrage** : si la palette fille est sur un côté (issue d'un
picking négatif), le ping-pong est impossible. Si le nombre de
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é
Lorsqu'aucune table n'est libre et qu'il faut en libérer une :
```
FONCTION évacuer_table_prioritaire(PK) :
// 1. Palette vide → retrait manuel (pas d'AGV)
// 2. Table déjà en attente d'évacuation → attendre AGV
// 3. Palette source en attente, non réutilisée par
// la prochaine tâche → AGV vers buffer/ASRS
// 4. Palette fille en attente → AGV vers image de quai
// 5. Palette source en attente (même si réutilisée)
// → AGV vers buffer ES
```
## Gestion des buffers ES → PK
Quand une table se libère au PK, le WMS choisit parmi les palettes en
buffer affectées à ce PK :
- Tri par `Line.CstAtt` **croissant** (plus petit = plus prioritaire)
- La première palette compatible avec la table libérée est envoyée
**Règle critique** : l'ordre de sortie des buffers est dicté par
`Line.CstAtt`, **pas** par l'ordre d'arrivée physique en buffer.
## Palettes multi-commandes
Une palette source peut être assignée à plusieurs OS.
Après picking de la commande en cours :
- Si la palette a encore des tâches pour d'autres OS → marquée
`MULTI_COMMANDE`, envoyée vers un buffer ES libre
- Elle reste en buffer jusqu'au lancement de l'OS suivant
- Une palette multi-commande au PK ou en mouvement compte comme une
place buffer occupée dans le calcul de `MAX_PRELOAD_PAR_PK`
## Priorité d'accès aux buffers entre PK
Lorsque les buffers ES sont saturés, la priorité est définie par la
séquence du mode "Picking" dans `MODES_PKxx`
(voir [Modes de travail PK](stations-picking.md)) :
- Séquence 1 = priorité la plus haute
- Quand un buffer se libère → affecté en priorité au PK avec la
séquence la plus basse parmi ceux qui ont des palettes en attente
## Paramètres WMS
| Paramètre | Description | Défaut |
|-----------|-------------|--------|
| `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) | — |
| `PK_BIGBAG` | Autorise ou non les big-bags par PK (LIM-70) | — |
## Points d'attention
⚠️ La contrainte d'adjacence est **physique** : l'opérateur ne peut pas
déplacer de sacs entre TABLE_GAUCHE et TABLE_DROITE directement.
⚠️ Le picking négatif nécessite 2 tables (palette source + adjacente
pour l'excédent), ce qui complique la gestion des cas saturés.
⚠️ Le recentrage de la palette fille (AGV) n'est déclenché que si
suffisamment de tâches de picking direct restent (≥ SEUIL_RECENTRAGE_PF).
⚠️ L'ordre de sortie des buffers suit `Line.CstAtt`, pas l'ordre FIFO
d'entrée en buffer.
## Questions ouvertes
(Aucune identifiée — algorithme V1.0 complet)
## Historique des modifications
| Date | Auteur | Modification |
|------|--------|--------------|
| 2026-05-12 | Arthur | Création depuis spec "Logique combinatoire picking - PS vers PK - V1.0" |
## Références
| Source | Type | Date |
|--------|------|------|
| Logique combinatoire picking - PS vers PK - V1.0 | Spécification technique | 27/04/2026 |
| [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 |
wiki_old_13-05-2026/limagrain/03-picking/sequencage-tk-ps-historique.md
+98
View File
@@ -0,0 +1,98 @@
---
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
author: Arthur
---
# 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).
> 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
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
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
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 1 déclenchée sur `TaskCreatedEvent` et
`OutboundOrderReleasedEvent`, avec verrouillage `OS.CstAtt`.
**Avantages** : simple, découplée, réactive.
## Arbitrage des contradictions (réu. 11/05/2026)
Analyse comparative : DevOps #64854 (le plus ancien), AF §6.4.8
(intermédiaire), réunion 11/05/2026 Arthur + Justine + Olivier
(fait foi). **Tous les points sont résolus.**
| Sujet | DevOps | AF | Réunion (fait foi) |
|-------|--------|----|--------------------|
| Traitement commercial | À creuser | Séparation stricte | **Supprimé** (`false`) |
| Seuil picking négatif | Pas de seuil | > 50% | **55% ET poids ≥ 7 kg** |
| 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** |
| Différenciation marque | Aucune | — | **Confirmé** |
| Calcul Bag/pal | "Prendre le max" | Équivalent palette | **Pro rata** |
## Changelog V1.1 (11/05/2026)
- Hiérarchie des règles : complétude palette et anti-split
prioritaires sur le tri
- Picking négatif : condition cumulative poids ≥ 7 kg ajoutée
- TC **supprimé** (`CONTROLE_TRAITEMENT_COMMERCIAL = false`)
- Calcul remplissage : pro rata Bag/pal (remplace "Bag/pal max")
- Poids max palette : 1 250 kg (corrige 1 200 kg du DevOps)
- Confirmé : mélange espèces OK, pas de gerbage, 1,90 m max
## Points non traités (hors scope réunion)
- Affichage opérateur au PK (consignes, déviation possible)
- Picking négatif < 7 kg en option
- Messagerie carton (navette du lendemain, zone angle Est)
- Verrou réception → recomptage avant picking (AF uniquement)
## Historique des modifications
| Date | Auteur | Modification |
|------|--------|--------------|
| 2026-05-12 | Arthur | Création — extraction depuis sequencage-tk-ps.md |
## Références
| Source | Type | Date |
|--------|------|------|
| [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 | — |
| AF §6.4.8 | Analyse fonctionnelle V1.5 | 28/11/2025 |
wiki_old_13-05-2026/limagrain/03-picking/sequencage-tk-ps.md
+155
View File
@@ -0,0 +1,155 @@
---
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]
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"]
last_updated: 2026-05-12
author: Arthur
---
# Séquençage des tâches de picking TK → PS
> **Résumé** : algorithme événementiel (V1.1) qui ordonne les tâches
> de picking depuis les transstockeurs (TK) vers les postes de sortie
> (PS). Il écrit les numéros de séquence `Line.CstAtt` sur chaque
> tâche et contrôle le flag `OS.CstAtt` pour autoriser le
> stacker_crane.
> **Standard EasyWMS** : → voir [Picking](../../concepts/picking.md)
## Déclenchement
L'algorithme est déclenché sur **deux événements** :
- **TaskCreatedEvent** — nouvelle tâche de picking créée (MINI JOB
LIM-75 ou réassignation). Condition : tâche type PICKING et OS
statut Released
- **OutboundOrderReleasedEvent** — OS passe en Released (lancement
ou relance après arrêt)
## Process principal
1. `OS.CstAtt ← false` (verrouille le stacker_crane)
2. Récupérer toutes les tâches de picking de l'OS
3. Filtrer : tâches **en attente** uniquement (en cours = intouchables)
4. Trier selon les 5 critères ci-dessous
5. Écrire les séquences `Line.CstAtt`
6. `OS.CstAtt ← true` (déverrouille le stacker_crane)
## Contraintes amont (constitution palettes filles)
**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
règles de tri. Regrouper la ligne complète quitte à décaler le maïs.
| Contrainte | Valeur |
|------------|--------|
| Poids max palette | **1 250 kg** |
| Hauteur max | 1,90 m |
| Gerbage | Interdit |
| Mélange espèces | Autorisé |
| Traitement commercial | **Désactivé** (V1.1) |
## Les 5 critères de tri (V1.1)
```
tâches.trier_par(
(1) type_picking ASC // NÉGATIF (0) avant DIRECT (1)
(2) espèce_maïs ASC // MAÏS (0) avant autres (1)
(3) quantité_espèce DESC // espèce la + volumineuse
(4) poids_article DESC // article le + lourd en base
(5) palette_source // regroupement par palette
)
```
### 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
Le maïs est lourd/stable → base de palette fille.
### 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
Les semences essais (légères) se retrouvent naturellement en haut.
### Critère 5 — Regroupement par palette source
L'opérateur enchaîne toutes les tâches d'une palette avant de la
libérer.
## Écriture des séquences (Line.CstAtt)
Deux tâches **interchangeables** reçoivent le **même numéro** de
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)
```
SI quantité_à_prélever > seuil_article × quantité_palette_source
ET article unique dans la palette source
ET pas d'attribut logistique à capturer
ET poids_unitaire_sac ≥ 7 kg
ALORS → PICKING_NÉGATIF
SINON → PICKING_DIRECT
```
## Paramètres WMS
| Paramètre | Défaut | Note V1.1 |
|-----------|--------|-----------|
| `CONTROLE_TRAITEMENT_COMMERCIAL` | **false** | Désactivé |
| Seuil picking négatif (fiche article) | 55% | Inchangé |
| Poids min picking négatif | **7 kg** | Nouveau |
| Seuil remplissage palette | **~95%** | Nouveau |
| Poids max palette | **1 250 kg** | Corrigé |
| `MAX_NB_BUFFER_PK` | 3 | Inchangé |
## Points d'attention
⚠️ Le custom LIM-61 (capacité buffer) doit gérer les palettes
multi-PK.
⚠️ En cas d'erreur du process, l'OS reste bloqué (CstAtt = false).
⚠️ Condition poids ≥ 7 kg : évite l'instabilité palette (gros sacs
ramenés sur petits sacs).
## Liens
- [Placement PS → PK](placement-ps-pk.md) — algorithme aval
- [Picking combinatoire](picking-combinatoire.md) — vue d'ensemble
- [Historique et arbitrage](sequencage-tk-ps-historique.md) —
solutions envisagées + arbitrage contradictions réunion 11/05/2026
## Historique des modifications
| Date | Auteur | Modification |
|------|--------|--------------|
| 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 |
## Références
| Source | Type | Date |
|--------|------|------|
| [LIM-84](https://easywmsfrance.atlassian.net/browse/LIM-84) | Ticket Jira | 2026 |
| [LIM-61](https://easywmsfrance.atlassian.net/browse/LIM-61) | Ticket Jira | 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 |
wiki_old_13-05-2026/limagrain/03-picking/stations-picking.md
+301
View File
@@ -0,0 +1,301 @@
---
title: "Stations et postes de travail Limagrain"
tags: [picking, stations, postes, ilots, buffer]
status: draft
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
author: Arthur
---
# Stations et postes de travail Limagrain
> **Résumé** : description des stations de l'entrepôt automatique, des
> postes de travail polyvalents (3 îlots × 2 postes) et des buffers associés.
> **Standard EasyWMS** : → voir [Stations & Routes](../../concepts/stations.md),
> [Mechanical Elements](../../concepts/mechanical-elements.md)
> Ce qui suit documente les **spécificités Limagrain** par rapport au standard.
## Contexte projet
Chez Limagrain, les postes de travail sont **polyvalents** et multi-processus.
L'ensemble des opérations (réception, picking, regroupement, échantillonnage,
re-certification) se fait sur les mêmes postes physiques, configurables
dynamiquement.
## Cartographie des stations
### Zone entrée production / sortie expéditions
| Station | Description |
|---------|-------------|
| PIE_01 | Poste d'identification 01 (côté quais) |
| NAV_01 | Navette 01 |
### Zone entrée/sortie postes de travail
| Station | Description |
|---------|-------------|
| PIE_02 | Poste d'identification 02 |
| PIE_03 | Poste d'identification 03 |
| REAC_01 | Poste de reconditionnement 01 |
| NAV_02 | Navette 02 |
| ET_21, ET_22 | Tables intermédiaires |
### Zone stockage côté postes de travail
| Station | Description |
|---------|-------------|
| ET_23 à ET_28 | Tables intermédiaires 23 à 28 |
| TE_01 à TE_04 | Tables d'entrée 01 à 04 |
| TS_01 à TS_04 | Tables de sortie 01 à 04 |
### Zone stockage côté quais
| Station | Description |
|---------|-------------|
| ET_11 à ET_15 | Tables intermédiaires 11 à 15 |
| TE/TS_01 à TE/TS_04 | Tables mixtes entrée/sortie 01 à 04 |
### Zone postes de travail
| Station | Description |
|---------|-------------|
| P1 à P6 | Postes de travail 01 à 06 |
| TP11 à TP63 | Tables de préparation 11 à 63 |
## Postes de travail — Architecture physique
### 3 îlots de 2 postes
Physiquement, il y a **3 îlots**, chacun composé de **6 tables de préparation
(TP)**. Chaque îlot peut être configuré de 2 façons :
1. **Mode scindé** : 2 postes individuels × 3 TP chacun (mode par défaut)
2. ~~**Mode global** : 1 poste × 6 TP (mode « esclave »)~~ **ABANDONNÉ**
> **MISE À JOUR** : le mode esclave (6 TP) est abandonné au profit d'un
> simple **message d'avertissement**. Si le poste adjacent est déjà
> ouvert → « Attention, le poste PVx est déjà ouvert. Voulez-vous quand
> même ouvrir ? ». L'opérateur peut confirmer ou annuler. Pas de blocage
> technique, juste un avertissement.
>
> **Justification** : les opérateurs sont physiquement à ~2 mètres l'un
> de l'autre et peuvent se coordonner verbalement. Les AGV ont des
> capteurs de sécurité et demandent l'autorisation de dépose. Trop de cas
> complexes à gérer avec un mode esclave custom. L'AGV amène toujours la
> palette au centre du PV actif.
>
> **Développement** : message d'avertissement à l'ouverture du poste,
> vérification si le poste conjoint est déjà ouvert (via support présent
> ou poste en mode réception), workflow action sur le end process pour
> fermer le poste.
### Numérotation
```
Îlot 1 : P1 (TP11, TP12, TP13) | P2 (TP21, TP22, TP23)
Îlot 2 : P3 (TP31, TP32, TP33) | P4 (TP41, TP42, TP43)
Îlot 3 : P5 (TP51, TP52, TP53) | P6 (TP61, TP62, TP63)
```
### Spécificités P5 & P6
Les postes **P5 et P6** sont équipés d'un **palan** pour la manipulation
de big-bags. Toute opération impliquant un big-bag (bag/pal ≤ 2) doit
être traitée sur P5 ou P6.
**Picking** : WS PK picking rob en priorité, process RF comme fallback
(plus robuste pour picking négatif, multi-tables). Le process de réception
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)
pour les règles détaillées (arrivée palettes 3 TP, algorithme répartition,
ordonnancement par gerbabilité).
### Modes de travail — Configuration et fonctionnement
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
ouvre le poste et le WMS gère automatiquement le process en fonction de
la palette qui arrive.
#### Modes disponibles
| Mode | Correspondance EasyWMS |
|------|------------------------|
| Picking | Picking |
| Réception | Réception |
| Regroupement | Consolidation |
| Échantillonnage | Inventaire |
| Re certification | Picking |
> ~~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)
Dans la vue des postes de travail, un **bouton d'action "Choix modes de
travail"** est disponible à la sélection d'un ou plusieurs PK. Ce bouton
ouvre une **vassist** qui permet de :
- **Cocher/décocher les modes autorisés** parmi les 5 modes ci-dessus
- **Définir la priorité** de chaque mode coché via un champ numérique
(séquence)
**Règles de validation** à la soumission :
- Chaque mode coché doit avoir une priorité renseignée
- Un mode non coché ne doit pas avoir de priorité
- Au moins un mode doit être coché (pour bloquer un PK, utiliser le
bouton standard dédié)
**Stockage** : la configuration est enregistrée dans un **paramètre
SmartUI dédié par PK** au format :
```
MODES_PK01 = "RECEPTION;1|PICKING;2|CONSOLIDATION;3"
MODES_PK02 = "RECEPTION;1"
```
Chaque entrée : `MODE;PRIORITÉ` séparés par `|`.
Cette configuration est utilisée par le
[Mega Job d'assignation](job-assignation-pk.md)
([LIM-70](https://easywmsfrance.atlassian.net/browse/LIM-70)) pour
déterminer si un PK est éligible à recevoir des tâches d'un flux donné
et dans quel ordre de priorité.
#### Ouverture du poste par l'opérateur (SmartUI)
L'opérateur accède à **Poste de travail > Station de picking**.
L'interface affiche un **bouton "Fermer le poste"** toujours visible.
Par défaut, le poste fonctionne en **tâche automatique** : le WMS
choisit le bon process en fonction de la palette qui arrive ou qui est
déjà sur le PK. L'opérateur n'a pas à sélectionner manuellement un mode.
#### Avertissement poste adjacent
À chaque ouverture d'un PK, le WMS vérifie si le **poste adjacent** est
déjà ouvert (en mode actif). Le mapping des paires est défini dans le
paramètre `PK_ADJACENT`.
**Si le poste adjacent est actif** → message d'avertissement (y compris
en mode tâche automatique) :
> "Attention, le poste [CODE_PK_ADJACENT] est déjà ouvert.
> Voulez-vous quand même ouvrir ?"
- Bouton **Confirmer** : le PK s'ouvre normalement
- Bouton **Annuler** : le PK reste inactif
**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.
#### Fermeture du poste
Le bouton **"Fermer le poste"** est toujours visible quel que soit l'état.
Au clic :
- Le PK est remis en mode **inactif** (aucun mode actif)
- Le PK redevient éligible pour une nouvelle assignation par le
[Mega Job](job-assignation-pk.md) (sous réserve qu'il n'ait plus de
tâches actives)
#### Paramètres modes de travail
| Paramètre | Description | Valeur par défaut | Exemple |
|-----------|-------------|-------------------|---------|
| 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` |
### Équipement par poste
- 1 poste léger EasyWMS dupliqué sur 2 écrans
- 1 imprimante Zebra (étiquettes HU RFID)
- 1 imprimante A4 (étiquettes A4)
- 1 douchette multi-format (RFID, QR Code, code à barres)
## [CUSTOM] Mega Job d'assignation des tâches aux postes
→ Voir page dédiée : **[Job d'assignation PK](job-assignation-pk.md)**
([LIM-70](https://easywmsfrance.atlassian.net/browse/LIM-70))
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,
regroupement, échantillonnage, re certification).
## Buffer postes de travail
16 emplacements palettes au sol le long de l'allée TK_01 :
| Nb emplacements | Usage |
|-----------------|-------|
| 14 | Avance pour les processus en cours |
| 2 | Piles de palettes vides |
> ⚠️ 2 emplacements supplémentaires pour palettes rejetées en attente de
> libération d'un poste de travail.
### [CUSTOM] Buffer configurable
Les emplacements du buffer sont **interchangeables** : un champ « type de
fonctionnement » peut être modifié quand l'emplacement est vide.
### [CUSTOM] Bouton d'évacuation
Un bouton spécifique sur l'écran EasyWMS permet d'évacuer automatiquement
une palette du buffer vers le convoyeur d'entrée pour stockage.
## Piles de palettes vides par poste
- **2 piles par îlot de travail** (et non par poste individuel)
- 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 —
l'opérateur choisit la pile à réapprovisionner parmi une liste
Voir [Palettes vides](../02-stockage/palettes-vides.md) pour le détail.
## Points d'attention
⚠️ Un poste fermé ne peut pas être assigné à un processus.
⚠️ L'assignation automatique du poste optimise la distance la plus courte.
⚠️ Si une TP est HS, elle peut être bloquée individuellement sans impacter
le reste du poste.
⚠️ L'entrée côté postes de travail et l'entrée côté quais sont
interchangeables manuellement en cas de blocage long terme (bouton de
redirection).
## Questions ouvertes
- [ ] Détail de la gestion des tables de préparation bloquées (@Nicolas)
## Historique des modifications
| Date | Auteur | Modification |
|------|--------|--------------|
| 2026-05-05 | Arthur | Création initiale depuis AF V1.5 |
| 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) |
## Références
| Source | Type | Date |
|--------|------|------|
| 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 |
wiki_old_13-05-2026/limagrain/04-outbound/.fuse_hidden0000003f00000018
+184
View File
@@ -0,0 +1,184 @@
---
title: "Quais, poumons et chargement"
tags: [outbound, quais, poumons, chargement, AGV, étiqueteuse]
status: draft
standard_ref: concepts/shipping.md
jira_refs: []
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
author: Arthur
---
# Quais, poumons et chargement
> **Résumé** : description physique et logique des quais, poumons (images
> de quai) et du processus de chargement/déchargement chez Limagrain.
> **Standard EasyWMS** : → voir [Shipping](../../concepts/shipping.md)
> Ce qui suit documente les **spécificités Limagrain** par rapport au standard.
## Contexte projet
Limagrain dispose de 6 quais physiques et 11 poumons (images de quai). Les
quais sont utilisés à la fois pour la réception et l'expédition, avec un
paramétrage du mode de fonctionnement.
## Configuration physique
### 6 quais
Modes de fonctionnement configurables par quai :
- Réception uniquement
- Expédition uniquement
- Les deux
### 11 poumons (images de 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.
La cohérence des assignations est de la responsabilité de Limagrain.
### [CUSTOM] Quai fictif « Parking »
À l'arrivée d'un camion, un agent de quai peut lui assigner un quai fictif
**« Parking »** en attendant qu'un quai réel soit affecté. Cela permet
d'identifier les camions en attente.
[CUSTOM] Une fois quai + image de quai sélectionnés, un écran parking affiche
« Plaque d'immatriculation + N° de quai » pour le chauffeur.
## Règles d'assignation
### Réception
- L'assignation quai + image de quai est **manuelle**
- [CUSTOM] Une fois sélectionnés, quai et image de quai sont **réservés**
(indisponibles pour une autre assignation)
- Si l'image de quai est pleine, une autre doit être assignée manuellement
- [CUSTOM] Libération automatique de l'image de quai quand toutes les
tâches AGV sont exécutées
- Libération manuelle du quai quand le véhicule est parti
### Expédition
**Par défaut** : un quai « QUAI_TEMPORAIRE » est assigné, accessible par
toutes les images de quai (poumon d'expédition). Il suffit d'assigner un
poumon pour lancer la livraison.
**À la libération de la commande** :
- Le stock va jusqu'à l'image de quai (poumon exp)
- Le vrai quai est précisé ultérieurement (pour affichage chauffeur)
- Association commande ↔ quai pour le chargement camion
- Association camion ↔ quai dans une vue dédiée
**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é**.
**Libération** :
- Image de quai : **automatique** à la dernière palette chargée
- Quai : **manuel** au départ du camion
## Disposition et sens de déchargement
L'opérateur décharge en commençant par l'emplacement **le plus éloigné du
quai** pour :
- Éviter le manque de place si plus de palettes que prévu
- Identifier précisément les emplacements occupés pour les AGV
Exemple pour 5 palettes :
```
Quai ← [vide][vide][vide][vide][vide][vide][vide][vide][5][4][3][2][1]
```
## Contraintes physiques
⚠️ La disposition des poumons **ne permet pas la circulation AGV entre les
poumons**. Impact sur les processus de chargement/déchargement.
⚠️ Le marquage au sol et le nombre de palettes par poumon doivent être
respectés par les caristes pour les prises/déposes AGV.
## Blocage quai/poumon
| Élément bloqué | Conséquence |
|----------------|-------------|
| 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
- 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
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
emplacement au sol spécifique est réservé (à définir).
⚠️ Possibilité de modifier quai/image de quai a posteriori manuellement
si les contraintes d'exploitation l'imposent.
## Problème de dépose AGV sur image de quai
Si plusieurs tâches en parallèle pour déposer sur la même image de quai
avec destinations précises (ex : emplacement 26 et 23), et qu'un AGV
dépose en 26 avant 23, celui du 23 est bloqué (pas de recul possible,
emplacements serrés).
**Solutions identifiées** :
1. Demander à déposer sur **l'image de quai** (sans position précise) et
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
> ⚠️ À valider avec Still lors d'une réunion technique dédiée.
## Confirmation prise/dépose AGV
Quand l'AGV prend une palette (sortie TK, sortie buffer, sortie PK), il
doit **informer le WMS** que la palette est sur l'AGV (emplacement =
`AGV_00X`), et non plus sur la dernière station ou en Mov.
**Raison** : sans cette confirmation, la capacité de la station reste
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
aussi le **début de mission** (prise palette).
Les AGV déposent les palettes sur le poumon en respectant l'**ordre des
arrêts (STOP)** pour la livraison.
## Questions ouvertes
- [ ] Emplacement au sol exact par transporteur pour messagerie carton (@Théo)
- [ ] Validation réunion technique Still pour le problème dépose AGV
sur image de quai (@Théo)
## Historique des modifications
| Date | Auteur | Modification |
|------|--------|--------------|
| 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 |
## Références
| Source | Type | Date |
|--------|------|------|
| FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5 | Analyse fonctionnelle | 28/11/2025 |
| Expédition - LIMAGRAIN - DEV - Confluence | Page ateliers DEV | 2026 |
wiki_old_13-05-2026/limagrain/04-outbound/.fuse_hidden0000004100000019
+226
View File
@@ -0,0 +1,226 @@
---
title: "Flux ERP outbound — Messages expédition"
tags: [outbound, ERP, SOR, RUT, SOF, LOF, PCK, MOV, interface]
status: draft
standard_ref: architecture/erp-integration.md
jira_refs: []
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"]
last_updated: 2026-05-06
author: Arthur
---
# 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.
> **Standard EasyWMS** : → voir [ERP Integration](../../architecture/erp-integration.md)
> Ce qui suit documente les **spécificités Limagrain** par rapport au standard.
## Contexte projet
La communication ERP expédition utilise XML + Webservice (SAP EWM ↔ GNA).
Pour les messages de réception, voir
[Flux ERP inbound](../01-inbound/flux-erp-inbound.md).
## Messages entrants (SAP → EasyWMS)
### RUT — Route
| Champ | Description |
|-------|-------------|
| Direction | ERP → WMS |
| Déclencheur | Planification expédition camion |
| 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
| Champ | Description |
|-------|-------------|
| Direction | ERP → WMS |
| Déclencheur | Création commande de sortie dans SAP |
| 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) |
## Messages sortants (EasyWMS → SAP)
### SOF — Shipping Order Fulfilled
| Champ | Description |
|-------|-------------|
| Direction | WMS → ERP |
| Déclencheur | Automatiquement (commande préparée à 100%) ou manuellement (clic opérateur). Envoi multiple possible en cas d'expédition partielle |
| Statut | 🟡 Phase 2 possible. Démarrage possible sans SOF, activation ultérieure. Utile potentiellement pour déclencher la création de HU dans MII |
| Contenu clé | SorCode, Status (Closed/Cancelled), LneContCode (HU), LneItemCode, ShippedQuantity, attributs logistiques |
**Statuts SOF** :
- **Closed** = stock réellement expédié, supprimé du WMS
- **Cancelled** = commande annulée, ShippedQuantity = 0 sur les lignes non
expédiées
### LOF — Load Order Fulfilled
| Champ | Description |
|-------|-------------|
| Direction | WMS → ERP |
| Déclencheur | Chargement camion terminé |
| Contenu | État des lieux du chargement réel. Ne contient **que les HU effectivement chargées** (pas de ligne à 0 ni d'alerte pour les non chargées). Peut regrouper plusieurs SOR/commandes |
**Articulation LOF / SOF** :
| Message | Contenu | Granularité |
|---------|---------|-------------|
| SOF | Ce qui a été expédié par commande | Par ordre de sortie |
| LOF | HU réellement chargées dans un camion | Par chargement |
**Structure des conteneurs dans le LOF** : arborescence imbriquée :
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
| Champ | Description |
|-------|-------------|
| Direction | WMS → ERP |
| 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É
> **ANNULÉ** — décision réunion client, jugé inutile.
| Champ | Description |
|-------|-------------|
| Direction | WMS → ERP |
| 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
### Principe retenu
Un fichier JSON unique envoyé **toutes les 5 minutes** contenant toutes
les palettes ayant eu un mouvement, les palettes nouvellement créées, et
les palettes supprimées.
### Structure du message
Chaque palette inclut :
- **Flag de type** : Mouvement / Création / Suppression
- **Nouvelle position** (zone de stockage)
- **Quantité** actuelle
- **Code** de la palette
- **Client flag** true / false
Le delta de 5 minutes se base sur le **dernier mouvement** pour détecter
les mouvements (et non une autre date).
> **Usage outbound** : le passage en conteneur client est visible dans le
> LOC (client flag = true), ce qui remplace le besoin d'un message dédié
> à chaque passage.
## Synthèse des communications ERP outbound
| Événement | Mode de communication |
|-----------|----------------------|
| Passage en conteneur client | LOC (toutes les 5 min) |
| ~~Déplacement stock picking~~ | ~~MOV~~ **ANNULÉ** |
| Clôture ordre de sortie | SOF |
| Chargement camion terminé | LOF |
| Réception palette re-certifiée | ASN (depuis MII) |
## Diagramme de séquence — Expédition client complète
```mermaid
sequenceDiagram
participant SAP
participant WMS as EasyWMS
participant PK as Poste travail
participant GAL as Galileo
participant QUAI as Quai/Poumon
SAP->>WMS: RUT (image camion + SOR)
WMS->>WMS: Libération auto (date atteinte)
WMS->>WMS: Assignation stock
Note over WMS: Palettes complètes → défrag
Note over WMS: Palettes picking → attente poste
WMS->>PK: Assignation poste + palettes picking
PK->>WMS: Picking terminé
Note over WMS: LOC toutes les 5 min (client flag)
WMS->>GAL: Tâches défrag → zone client
WMS->>WMS: Assignation poumon
WMS->>GAL: Tâches sortie + CstData étiqueteuse
GAL->>QUAI: Palettes déposées (ordre STOP)
QUAI->>WMS: Scan étiquette (chargement)
WMS->>SAP: SOF (OS clôturé)
WMS->>SAP: LOF (camion chargé)
```
## Diagramme de séquence — Consommation OF avec recertification
```mermaid
sequenceDiagram
participant SAP
participant WMS as EasyWMS
participant PK as Poste travail
SAP->>WMS: SOR (type Recert)
WMS->>WMS: Libération + assignation
WMS->>PK: Palette au poste
PK->>WMS: HU supprimée
WMS->>SAP: SOF
Note over SAP: Nouvelle HU créée hors WMS
SAP->>WMS: ASN (nouvelle palette)
WMS->>WMS: Réception + stockage
```
## Tableau récapitulatif des messages
| Message | Direction | Standard/Custom | Processus | Statut |
|---------|-----------|-----------------|-----------|--------|
| RUT | ERP → WMS | Standard | Expédition client, messagerie | ✅ Actif |
| SOR | ERP → WMS | Standard | Consommation OF, recert | ✅ Actif |
| SOF | WMS → ERP | Standard | Tous (clôture OS) | 🟡 Phase 2 |
| LOF | WMS → ERP | Standard | Chargement terminé | ✅ Actif |
| LOC | WMS → ERP | [CUSTOM] | Toutes les 5 min (mouvements, créations, suppressions) | ✅ Actif |
| PCK | WMS → ERP | [CUSTOM] | Client, OF hors recert, messagerie | ⚠️ **REMPLACÉ** par LOC |
| MOV | WMS → ERP | [CUSTOM] | ~~Picking, regroupement~~ | ⚠️ **ANNULÉ** |
## Points d'attention
⚠️ 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.
⚠️ Pour la recertification, le SOF est envoyé **avant** la réception
de la nouvelle HU (séquence SOF → ASN).
⚠️ Le LOC est envoyé toutes les 5 minutes avec un delta basé sur le
dernier mouvement. Le passage en conteneur client y est visible via
le flag « client ».
## Historique des modifications
| Date | Auteur | Modification |
|------|--------|--------------|
| 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é |
## Références
| Source | Type | Date |
|--------|------|------|
| 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 |
wiki_old_13-05-2026/limagrain/04-outbound/.fuse_hidden000000430000001a
+495
View File
@@ -0,0 +1,495 @@
---
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: []
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
author: Arthur
---
# 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
> spécifiques (re-certification, messagerie carton, consommation OF, litiges).
> **Standard EasyWMS** : → voir [Shipping](../../concepts/shipping.md)
> Ce qui suit documente les **spécificités Limagrain** par rapport au standard.
## Contexte projet
Le processus d'expédition est composé de 12 étapes. Les palettes passent
par une zone de défragmentation client dans l'ASRS avant d'être sorties
vers les poumons. Un custom clé gère l'ordonnancement : la défragmentation
ne se déclenche que quand toutes les palettes de picking sont terminées.
## Processus global
```mermaid
flowchart TD
SOR["1. Réception SOR/RUT"] --> LIB["2. Libération auto/manuelle"]
LIB --> ASSIGN["3. Assignation stock"]
ASSIGN --> GEN["4. Génération tâches"]
GEN -->|Picking requis| PK["5. Assignation poste travail"]
GEN -->|Palettes complètes| DEFRAG["CUSTOM: Défrag → zone client"]
PK --> PICK["6. Préparation au poste"]
PICK --> CADENCE["7. Cadencement tâches"]
CADENCE --> POUMON["8. Assignation poumon/quai"]
DEFRAG --> POUMON
POUMON --> SORT["9. Déplacement + étiquetage auto"]
SORT --> AGV["AGV → dépose poumon"]
AGV --> CHARG["10. Chargement camion"]
CHARG --> SOF["11. Clôture → SOF + LOF"]
SOF --> LIBRE["12. Libération quai/poumon"]
```
## Étapes détaillées
### 1. Réception de l'ordre de sortie
L'ERP envoie une commande d'expédition vers EasyWMS : un **SOR** (commande
de sortie) ou un **RUT** (image camion pouvant contenir plusieurs SOR
ordonnancés par n° de STOP). Voir [Ordres de sortie](shipping-orders.md).
### 2. Libération de l'ordre de sortie
| Mode | Description |
|------|-------------|
| Automatique | Date/heure de libération définie dans le SOR/RUT (mode principal). Par défaut `PlannedShippingDate - 48h`. |
| Manuelle | Depuis l'écran des ordres de sortie dans EasyWMS |
### 3. Assignation du 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).
### 4. Génération des tâches
| 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 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.
>
> **Deux customs complémentaires** gèrent l'ordonnancement par STOP :
> quai non assigné → [Défragmentation custom](../02-stockage/defragmentation.md),
> quai assigné → [Séquençage shipping par STOP](sequencage-shipping-stop.md).
> **Note** : l'information du passage en conteneur client est disponible
> dans le LOC envoyé périodiquement à SAP.
### 5. Assignation du poste de travail
Assignation **automatique** depuis EasyWMS. Modes possibles par poste :
Picking, Réception, Regroupement, Échantillonnage, Recertification, Tous.
**Contrainte** : seuls les postes **P5 et P6** (équipés palan) peuvent
être assignés pour les processus comportant au moins une palette Big-Bag.
**Priorité** : WS PK picking rob en priorité, et si trop limité, utiliser
le **process RF** comme fallback (plus robuste pour picking négatif,
multi-tables, etc.). Le process de réception est déjà plugué au mode
Automatic tasks de la WS (custom) → même mode pour le picking.
Voir [Stations picking](../03-picking/stations-picking.md).
### 6. Préparation au poste de travail
#### Arrivée des palettes (toujours un poste 3 TP)
- Première palette au **centre** si picking négatif proposé, sinon sur un côté
- Si une palette est sur un côté et qu'on propose du picking négatif →
prévenir l'opérateur de déplacer la palette au centre
- La palette client revient **toujours** au centre
- Pas de prépa sur 6 TP en simultané
#### Ordonnancement des prélèvements
1. **Espèce Maïs** toujours en premier (pas la variété)
2. Puis espèce avec la **plus grande quantité** dans la commande
3. Si égalité : **article/lot le plus lourd** en base de palette
**Mapping Espèce → stack (gerbabilité)** : maïs = stack 0 (le plus
lourd/stable, en base). [CUSTOM] Gestion en async sur l'ITM pour calculer
la gerbabilité automatiquement à la création de l'article. Tri via
workflow `StackerCrane_SortTasks_PR`.
#### Règles de picking
| Règle | Détail |
|-------|--------|
| Picking négatif | Si quantité à prélever > 50% → déplacer les sacs qui restent |
| Pas de mélange traitement commercial | Articles avec/sans traitement sur palettes filles séparées (via famille d'article) |
| 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
[CUSTOM] Logique combinatoire complète gérant : picking négatif et
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).
**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
manuellement sur pile quand vidée.
#### Étiquetage au picking
**Palettes MII et multi-lots** : 1 étiquette HU RFID pour la palette
physique (HU mère) + 1 étiquette HU sans RFID par ligne de stock
(HU fille / intercalaire). Impression auto à chaque nouvelle palette
(RFID) et à chaque article (intercalaire).
**Autres palettes** : 1 étiquette HU RFID uniquement. Basé sur la
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.
#### Filmage
Avant chaque évacuation, l'opérateur choisit le programme de filmage
(CstData transmis à Galileo). Possibilité de choisir « pas de filmage ».
**Programmes de filmage disponibles** :
| Code | Espèce | Contenant | Mode |
|------|--------|-----------|------|
| A | Tournesol | Sacs | Complet |
| B | Tournesol | Sacs | Réduit |
| C | Tournesol | Big Bag | Complet |
| D | Tournesol | Big Bag | Réduit |
| E | Maïs & Blé | Sacs | Complet |
| F | Maïs & Blé | Sacs | Réduit |
| G | Maïs & Blé | Big Bag | Complet |
| H | Maïs & Blé | Big Bag | Réduit |
Voir [Picking combinatoire](../03-picking/picking-combinatoire.md) pour
les détails du processus de préparation.
### 7. Cadencement des tâches
Séquence pour une commande « classique » :
1. Lancement de la commande (quelques heures/jours avant la prépa réelle)
2. Les tâches de shipping **ne se déclenchent pas** tant que le poumon/quai
n'est pas assigné
3. Les palettes deviennent « client » → information dans le LOC
4. Si la commande n'a pas de poumon assigné, ou si TK dispo (tâche prio
très basse), l'ASRS déplace les palettes de shipping vers une **zone
tampon** du magasin proche des sorties (via défrag en tâche de fond)
5. Si un PK est dispo, les tâches de picking se génèrent → palettes
vont aux PK
6. À chaque palette pickée et terminée :
- Selon classe de commande → retour TK ou non
- Si retour ASRS : tâche AGV (PK → Entrée TK)
- Si messagerie : tâche vers le poumon d'expédition choisi manuellement
- Si aucun poumon choisi → prompt
7. La palette de picking **re-rentre dans le TK directement au bon
endroit** (zone client) avec si possible canal dédié à la route. Pas
de stockage temporaire puis défrag la nuit.
8. Assignation du poumon → génération des tâches de shipping
### 8. Assignation quai / poumon
**Par défaut** : un quai « QUAI_TEMPORAIRE » est assigné, accessible par
toutes les images de quai. Simplement assigner un poumon pour lancer la
livraison.
**À la libération** : le stock va jusqu'à l'image de quai (poumon exp).
Le vrai quai est précisé ultérieurement (affichage chauffeur). Association
commande ↔ quai pour le chargement, camion ↔ quai dans une vue dédiée.
**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é.
Voir [Quais et poumons](consolidation-chargement.md).
### 9. Déplacement et étiquetage automatique
Palettes sortent de la zone défrag → poste de sortie ASRS.
**Étiqueteuse automatique** : deux étiqueteuses au niveau des 2 postes de
sortie TK.
Voir la section [Étiqueteuse automatique](#étiqueteuse-automatique)
ci-dessous pour le fonctionnement détaillé.
Ordonnancement des palettes sur le poumon par **n° STOP** (ordre de
livraison). Les AGV déposent en respectant l'ordre des arrêts.
### 10. Chargement camion
Le chargement camion est créé par le RUT.
1. Vérification que la palette a été étiquetée automatiquement. Si échec :
impression manuelle via imprimante sur les quais.
2. Scan de l'étiquette pour confirmer la prise en charge
3. Dépose de la palette dans le camion
4. Palette suivante jusqu'à fin de chargement
**Fermeture auto** si chargement complet : possibilité de lancer un
CloseCommand sur l'OS pour expédier ce qui est chargé.
### 11. Clôture de l'ordre de sortie
- **Automatique** lorsque tous les conteneurs sont chargés
- Messages **SOF + LOF** envoyés vers SAP
Dans un SOF, les lignes sans quantité expédiée **n'apparaissent pas**
(pas de ligne à 0).
Si un premier chargement est clôturé partiellement → vérifier si un
deuxième chargement est recréé automatiquement pour le reliquat.
> ⚠️ À paramétrer et tester : comportement du reliquat chargement
> camion, notamment avec fichier RUT.
- Le LOF représente l'image exacte du camion (palettes physiquement
chargées)
- Si une commande est expédiée sur 2 camions → 2 LOF distincts
- X SOF par commande si expédition partielle
### 12. Libération quai / image de quai
| Élément | Mode de libération |
|---------|-------------------|
| Image de quai | **Automatique** — dernière palette chargée |
| Quai | **Manuel** — départ du camion |
## Étiqueteuse automatique
### Principe
Deux étiqueteuses au niveau des deux postes de sortie TK, pouvant imprimer
une ou plusieurs étiquettes selon le processus.
### Étiquetage au picking
100% des palettes passant par le picking sont étiquetées (étiquette
d'expédition) directement au PK. Un `CstAtt` est positionné à `true` sur
la palette pour indiquer qu'elle a déjà été étiquetée.
### Comportement à la sortie TK
L'étiqueteuse **n'imprime pas** si :
- `CstAtt` = `true` (palette déjà étiquetée au picking)
- OU hauteur palette trop faible (PLC height type = 1)
L'étiqueteuse **imprime** si :
- `CstAtt` = `false` ET PLC height type ≠ 1
- Si impression réussie → `CstAtt` passe à `true`
- Si impression échouée → `CstAtt` passe à `error`
### Mode dégradé — Chargement camion
Si l'opérateur scanne une palette sans étiquette (`CstAtt` = `false` ou
`error`, PLC height type ≠ 1) au chargement camion → impression
automatique sur une imprimante proche du quai.
### Communication Galileo
On envoie un **custom data** à Galileo (pas de changement de
destination/route). Galileo, en recevant le custom data avec le bon
tracking de palette, arrête les rouleaux et lance l'impression. Un seul
chemin — l'arrêt est piloté par le custom data.
### Multi-étiquettes (2 étiquettes)
2 rapports différents → **2 docs de 1 page** (= 2 demandes d'impression
simultanées). L'étiqueteuse articulée colle à 2 endroits différents sur
la palette (positions à définir avec Théo).
### Gestion des pannes
- Imprimante en échec → erreur envoyée à Galileo → Galileo met en
**défaut la ET (station)** correspondante
- Si une des deux étiqueteuses est HS → Galileo reroute automatiquement
vers l'autre poste de sortie
- [CUSTOM Galileo] Communication HS imprimante → mise en défaut ET à
documenter dans le document TMS
## Flux spécifiques
### Re-certification
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
administrative**.
**Pré-requis** : le PK doit être passé en **mode recertif** (par le
manager), ce qui bloque le PK pour les autres types de tâches.
**Flux détaillé :**
1. L'ERP envoie un SOR de type « Recertification »
2. Le WMS crée une tâche vers QUAI_RECERTIF. La route passe par le PK
(seul chemin possible)
3. L'AGV amène la palette au PK assigné
4. [CUSTOM] **Event à l'arrivée sur le PK** : on stocke le code du PK
(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 :
- 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
la capacité correcte et empêcher le WMS d'envoyer de nouvelles
palettes sur un PK physiquement occupé)
7. L'ERP reçoit le SOF → mise à jour avec son MII en interne
8. L'opérateur recertifie physiquement la palette, ré-étiquette (hors WMS)
9. L'ERP renvoie un **ASN** avec la nouvelle identité palette
10. [CUSTOM] L'opérateur scanne la palette recertifiée au PK → le WMS
propose de choisir la table (prompt position PK). La palette passe
de ASN au bon emplacement PK. La **palette vide est supprimée**
automatiquement.
11. L'opérateur appuie sur « Ranger support » → AGV vient la chercher →
passage au PIE de réception (standard)
> ⚠️ **Risque** : si l'ASN n'est pas encore arrivé au moment du scan →
> erreur, réessayer plus tard.
> ⚠️ **3 mini-customs identifiés** : event de stockage CstAtt + event
> de fermeture/création palette vide + suppression palette vide au scan ASN.
### Messagerie carton
**Solution recommandée** : **Pick and Pack** (module transporteur). Plus
simple, pas de colisage séparé, impression étiquette directe. **Nécessite
le module transporteur.** Plan B : fusion des lignes comme alternative.
**Sans module transporteur** : custom le picking PK avec un mode
« messagerie carton » :
1. Commandes descendues dans un RUT de type « Messagerie carton » (classe
d'expédition)
2. Tous les OS préparés en simultané sur un seul poste de travail
3. Tri par transporteur (l'opérateur ne peut déposer que sur une seule
palette). Via modèle d'expédition à créer avec le client.
4. Impression étiquette colis à la première tâche de picking
(SOR.Code, SOR.Account, SOR.Delivery, SSCC colis 128)
5. Consolidation sur palette unique
6. Prélèvement dans un carton (support identifié) puis sur palette
7. Indicateur à l'opérateur quand un carton ne recevra plus de stock →
fermer le carton
8. Bouton « Palette pleine » sur la WS :
- Impression SSCC
- Collage par l'opérateur
- Prompt du code
- Remontage des supports « colis » sur la palette
9. Fermeture auto aussi possible si palette n'attend plus de stock
10. AGV récupère la palette vers le quai
**Assignation poumon** : [CUSTOM] à l'import du SOR, vérification combo
shipping class code + transporteur → si OK, poumon associé automatiquement.
L'idée retenue est de **ne pas** utiliser d'image de quai classique (sinon
perte de 25 places) mais un **emplacement au sol par transporteur**
(ex: emplacement « Colissimo », « Chronopost »).
> ⚠️ Custom à prévoir pour que la fermeture fonctionne dans le cas d'un
> support non client possédant des supports clients.
### Consommation OF hors recertification
**Prérequis** :
- `AllowAssignStockExcess` à `true` dans la SOR.Line
- Modèle d'expédition avec une stratégie d'assignation de stock
- [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
- Pas de passage par un poste de travail
Pour les SOR de classe Production, les ruptures de stock ne bloquent pas
l'expédition. Le client utilise `isCritical` / `isRequired` au niveau
SOR.Line si besoin.
### Gestion des litiges (sac endommagé)
1. La palette arrive au PK
2. Problème constaté par l'opérateur sur un stock à picker :
- Bouton « Problème » → « Modif quantité »
- 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) :
- **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
au sol buffer litige** (à valider avec le client)
4. Retour au flux classique
## Modes opératoires
Tous les process doivent être pensés en **3 modes** :
| Mode | Description |
|------|-------------|
| Full AGV | Fonctionnement nominal |
| Mixte | AGV + caristes (cas probable en montée en charge) |
| Full TRF (caristes) | Mode dégradé sans AGV |
Le module AGV standard permet la finalisation manuelle (simulation AGV).
4 TRF disponibles sur site. Réunion dédiée à planifier pour les modes
dégradés.
## Points d'attention
⚠️ L'ordonnancement des palettes sur le poumon respecte le n° STOP.
⚠️ Le custom de défragmentation est le développement clé : il attend que
toutes les palettes de picking soient terminées avant de lancer les relocs.
⚠️ La clôture est automatique pour les OS complets mais **manuelle** en
cas d'expédition partielle.
⚠️ Le message MOV est **annulé** (décision réunion client).
⚠️ Les 3 modes opératoires (Full AGV / Mixte / Full TRF) doivent être
documentés pour chaque process.
## Questions ouvertes
- [ ] Ordonnancement des palettes dans le canal du poumon d'expé du
magasin automatique — géré par le WMS ou naturellement via l'ordre
de stockage ? (@Nicolas)
- [ ] Fermeture auto OS si chargement complet — standard ou custom ?
(@Nicolas)
- [ ] Comportement du reliquat chargement camion avec fichier RUT —
à paramétrer et tester (@Fabien)
- [ ] Positions des 2 étiquettes articulées sur la palette (@Théo)
- [ ] Custom Galileo : communication HS imprimante → mise en défaut ET
— à documenter dans le TMS (@Théo)
- [ ] 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
| Date | Auteur | Modification |
|------|--------|--------------|
| 2026-05-05 | Arthur | Création initiale depuis AF V1.5 |
| 2026-05-05 | Arthur | Réécriture complète : 12 étapes, étiqueteuse auto détaillée, recertif 11 étapes, messagerie carton, conso OF, litiges, modes opératoires, MOV annulé |
## Références
| Source | Type | Date |
|--------|------|------|
| FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5 | Analyse fonctionnelle | 28/11/2025 |
| Expédition - LIMAGRAIN - DEV - Confluence | Page ateliers DEV | 2026 |
wiki_old_13-05-2026/limagrain/04-outbound/.fuse_hidden000000450000001b
+220
View File
@@ -0,0 +1,220 @@
---
title: "Séquençage shipping par STOP — Quai assigné"
tags: [outbound, expédition, shipping, tournée, STOP, stacker-crane, custom, AGV]
status: draft
standard_ref: concepts/shipping.md
jira_refs: [LIM-88]
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"]
last_updated: 2026-05-12
author: Arthur
---
# 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
> l'ordre inverse des STOP. Un custom override le WF de tri du stacker
> crane pour analyser la séquence STOP sur **tous les TK** (vision
> globale de la tournée) au lieu d'un seul TK.
> **Standard EasyWMS** : → voir [Shipping](../../concepts/shipping.md),
> [Defragmentation](../../concepts/defragmentation.md)
> Ce qui suit documente les **spécificités Limagrain** par rapport au
> standard.
## Contexte projet
Ce custom est le **cas complémentaire** de la
[défragmentation client par tournée](../02-stockage/defragmentation.md)
(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
(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.
Le picking peut encore être en cours sur certaines lignes. On ne veut
pas :
- Qu'une palette complète du STOP 1 parte vers l'image de quai alors
que des palettes des STOP supérieurs ne sont pas encore prêtes
- Qu'une palette fille (PF) sortant du PK aille en cross-dock direct
vers l'image de quai si son STOP n'est pas encore « éligible »
## Approche initiale abandonnée
> 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
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
jobs).
## Solution retenue
### Comportement attendu
#### 1. Génération des tâches shipping (standard)
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
TK après picking.
#### 2. Ordonnancement d'exécution (custom stacker crane)
Le WF de tri des tâches du stacker crane applique la règle STOP
max → STOP 1 avec blocage si un STOP supérieur a des palettes
manquantes :
- Si toutes les palettes du STOP N+1 (et au-delà) sont déjà sorties
de l'ASRS → les palettes du STOP N deviennent éligibles
- Si un STOP supérieur a encore des palettes non prêtes (picking en
cours) → les STOP inférieurs sont **bloqués** en attente
- Dès qu'une palette manquante devient prête (PF rangée dans un TK)
→ sa tâche de shipping est créée et le stacker crane reprend le
déroulé dans l'ordre
#### 3. Retour palette fille du PK (standard attendu)
La PF doit **retourner dans l'ASRS** et ne pas cross-docker vers
l'image de quai. Ce comportement repose sur le WF standard qui génère
la tâche shipping depuis la TP du PK : s'il y a un quai assigné mais
pas de route disponible vers l'image de quai, il crée une tâche de
rangement (start rangement support client). Crossdock OFF pour que la
palette rentre bien dans l'ASRS.
> ⚠️ **À confirmer en recette** : vérifier que le standard crée bien
> une tâche de rangement quand pas de route vers l'image de quai.
> Sinon → prévoir un custom de secours.
### Ce qui est custom
- **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.
### Ce qui reste standard
- Génération des tâches de shipping
- Mécanique de routage TP PK → ASRS (pas de crossdock)
- Gestion du stock reassign après déclaration problème au picking :
si pas de stock trouvé → palettes suivantes du STOP envoyées ;
si nouveau stock trouvé → récupère le séquençage
## Flux fonctionnel
```mermaid
sequenceDiagram
participant SAP as SAP
participant WMS as EasyWMS
participant TK as Stacker Crane
participant PK as Poste Picking
participant IQ as Image de Quai
SAP->>WMS: RUT avec STOP 1, 2, 3
WMS->>WMS: Libération + assignation stock
Note over WMS: Quai déjà assigné
WMS->>TK: Tâches shipping (PC prêtes)
Note over TK: CUSTOM: tri multi-TK par STOP
TK->>IQ: Palettes STOP 3 (max)
Note over TK: STOP 2 bloqué si PF au PK
PK->>TK: PF revenue ASRS (rangement)
TK->>IQ: Palette PF STOP 2
TK->>IQ: Palettes STOP 2 (reste)
TK->>IQ: Palettes STOP 1
```
## Cas de test
### Légende
- **PC** = palette complète (pas de picking nécessaire)
- **PP** = palette de picking (palette mère qui part au PK)
- **PF** = palette fille (sortie du picking, retour ASRS)
### Cas nominaux
| CT | Préconditions | Résultat attendu |
|----|--------------|------------------|
| 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 |
### Cas limites (cœur du custom)
| CT | Préconditions | Résultat attendu |
|----|--------------|------------------|
| CT-04 | STOP 3 = 1 PP au PK. STOP 2 et 1 prêts. Quai assigné | Tâches STOP 1 et 2 générées mais **non exécutées**. Aucune palette ne part |
| CT-05 | Suite CT-04 : PF STOP 3 revient dans ASRS | Tâche shipping PF créée → STOP 3 part → STOP 2 débloqué → STOP 1 débloqué |
| CT-06 | 5 STOP. STOP 5 et 4 prêts. STOP 3 = 1 PP au PK. STOP 2 et 1 prêts | STOP 5 et 4 partent. STOP 2 et 1 **bloqués** par STOP 3. Déblocage en cascade après retour PF STOP 3 |
| CT-07 | STOP 3 = 4 palettes dont 1 PP au PK. STOP 2 et 1 prêts | 3 PC du STOP 3 partent. STOP 2 et 1 **bloqués** tant que la 4e palette du STOP 3 (PF) n'est pas sortie |
### Retour PF du PK
| CT | Préconditions | Résultat attendu |
|----|--------------|------------------|
| CT-08 | PF arrive à la TP sortie PK, quai assigné | Tâche de **rangement ASRS** créée. Crossdock OFF. Jamais de cross-dock direct vers image de quai |
### Multi-tournées
| CT | Préconditions | Résultat attendu |
|----|--------------|------------------|
| 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 |
### Stock reassign au picking
| CT | Préconditions | Résultat attendu |
|----|--------------|------------------|
| CT-14 | Problème déclaré, stock reassign échoue | Palette ignorée par stacker crane, STOP suivants envoyés |
| CT-15 | Problème déclaré, stock reassign trouve nouvelle palette | Nouvelle palette récupère le STOP, séquençage non impacté |
## Points d'attention
⚠️ 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
par le custom — les palettes déjà à l'image de quai de l'ancien quai
sont à traiter manuellement.
## Questions ouvertes
- [ ] 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
comportement attendu pour les palettes déjà à l'ancien quai.
(@Justine)
→ voir [Questions ouvertes](../08-transverse/questions-ouvertes.md)
## Historique des modifications
| Date | Auteur | Modification |
|------|--------|--------------|
| 2026-05-12 | Arthur | Création initiale depuis LIM-88 |
## Références
| Source | Type | Date |
|--------|------|------|
| [LIM-88](https://easywmsfrance.atlassian.net/browse/LIM-88) | Ticket Jira | 2026 |
| Expédition - LIMAGRAIN - DEV | Page Confluence | 2026 |
| Projet Bardinet | Pattern custom stacker crane multi-TK | — |

Some files were not shown because too many files have changed in this diff Show More