lint(standard): corrections completes mode standard
- Em dashes: 1712 remplaces par tirets simples (86 fichiers + _index.md, en-tete section Limagrain conserve) - Checklists: 24 '- [ ]' -> '- ☐' (3 pages operations, plus de todos Obsidian) - Ancres: 33 reparees (slugs GitHub + ancres HTML <a id> reconnues), 1 reciblee (manuel de reten) - related: tenseflow -> tense-flow, pie -> mechanical-elements, group.md retire (doublon shipping) - Registre: compteur global 122 -> 131 pages - Rapport racine _lint_report.md mis a jour (scan v2 + re-scan final: 0 anomalie) - Aucun fichier limagrain/ modifie (cloisonnement)
This commit is contained in:
@@ -24,9 +24,9 @@ last_compiled: "2026-04-10"
|
||||
|
||||
EasyWMS uses two related but distinct entities for commercial master data: **Owner** and **Account**.
|
||||
|
||||
- An **Owner** is the entity that owns the stock in the warehouse (a sales company, the organization itself, or — in 3PL contexts — an external client). Every stock record has an owner. Owners can mix stock with each other only when mixing is explicitly enabled.
|
||||
- An **Owner** is the entity that owns the stock in the warehouse (a sales company, the organization itself, or - in 3PL contexts - an external client). Every stock record has an owner. Owners can mix stock with each other only when mixing is explicitly enabled.
|
||||
|
||||
- An **Account** is a delivery point / customer of the warehouse — the entity to which a shipping order's stock is destined. Accounts represent end-customers or delivery addresses; they are referenced on outbound orders to control carrier preferences, label formats, and FEFO rules.
|
||||
- An **Account** is a delivery point / customer of the warehouse - the entity to which a shipping order's stock is destined. Accounts represent end-customers or delivery addresses; they are referenced on outbound orders to control carrier preferences, label formats, and FEFO rules.
|
||||
|
||||
The two are distinct: an owner holds inventory rights; an account receives shipments. A single owner can have many accounts (multiple delivery points). In 3PL deployments with Owner Extensions enabled, every receipt order, shipping order, and master data entity must be assigned to an owner.
|
||||
|
||||
@@ -45,7 +45,7 @@ The two are distinct: an owner holds inventory rights; an account receives shipm
|
||||
### Owner mixing rules
|
||||
By default, new owners are created with mixing **disabled**. Mixing can be enabled per owner. Additionally, specific owner exclusions can be added (preventing mixing with specific other owners). Mixing checks apply to: items, item types, item families, logistic attributes, and owners simultaneously.
|
||||
|
||||
In **automatic warehouses**, mixing restrictions are hard-enforced — the system will not allow a container to be stored if mixing rules are violated. In **manual warehouses**, operators can override mixing warnings.
|
||||
In **automatic warehouses**, mixing restrictions are hard-enforced - the system will not allow a container to be stored if mixing rules are violated. In **manual warehouses**, operators can override mixing warnings.
|
||||
|
||||
---
|
||||
|
||||
@@ -84,10 +84,10 @@ In **automatic warehouses**, mixing restrictions are hard-enforced — the syste
|
||||
|
||||
## Related
|
||||
|
||||
- [[stock]] — every stock record has an owner; owner mixing rules determine co-location eligibility
|
||||
- [[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
|
||||
- [[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
|
||||
|
||||
@@ -92,9 +92,9 @@ When the Multi-Carrier module is active, a **Delivery** combines carrier + consi
|
||||
|
||||
## Related
|
||||
|
||||
- [[shipping]] — shipping orders reference carriers; routes and loads assign containers to carriers
|
||||
- [[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
|
||||
- [[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
|
||||
|
||||
@@ -24,8 +24,8 @@ last_compiled: "2026-04-10"
|
||||
**Consolidation** in EasyWMS is the process of moving stock from multiple partially-full containers into a single destination container, eliminating peaks and optimizing space usage in the warehouse. It is designed to run during **periods of inactivity**, interfering minimally with active warehouse operations.
|
||||
|
||||
Two types of consolidation exist:
|
||||
1. **Stock consolidation (warehouse)** — covered here. Compacts incomplete containers in storage to reduce the number of occupied locations.
|
||||
2. **Shipping consolidation** — reorganizes prepared stock for outbound orders (see [shipping](../concepts/shipping.md)). Not covered here.
|
||||
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.
|
||||
|
||||
@@ -137,9 +137,9 @@ Containers arrive sequenced at the PK:
|
||||
| Capacity exceeded at destination | Line adjusted; source remains non-empty |
|
||||
|
||||
**Transactions:**
|
||||
- `CON.MOVE` — container location changes (warehouse → PK → warehouse)
|
||||
- `STK.MOVE` — stock moved from source to destination container
|
||||
- `CON.SEND.L&F` — if empty source container is sent to Lost & Found
|
||||
- `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)
|
||||
|
||||
@@ -192,8 +192,8 @@ For consolidation to work correctly:
|
||||
|
||||
## 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
|
||||
- [[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
|
||||
|
||||
+46
-46
@@ -36,9 +36,9 @@ last_compiled: "2026-04-17"
|
||||
|
||||
## Overview
|
||||
|
||||
A **LPN** (License Plate Number) is the fundamental unit of physical storage in EasyWMS — a box, pallet, or any other container that holds stock. Every unit of stock in the warehouse lives inside a LPN; the LPN is what moves, what gets located, locked, picked, and shipped. In identification contexts, the LPN is always labeled (Code 128 or GS1-128) and its code uniquely identifies it system-wide.
|
||||
A **LPN** (License Plate Number) is the fundamental unit of physical storage in EasyWMS - a box, pallet, or any other container that holds stock. Every unit of stock in the warehouse lives inside a LPN; the LPN is what moves, what gets located, locked, picked, and shipped. In identification contexts, the LPN is always labeled (Code 128 or GS1-128) and its code uniquely identifies it system-wide.
|
||||
|
||||
The LPN is the bridge between the physical world (a pallet on a rack) and the logical world (stock records, tasks, orders). EasyWMS tracks every LPN's location, weight, status, contents, and relationships (stacked, matched, client-linked) in real time. All WMS movements — reception, putaway, picking, replenishment, shipping — are expressed as operations on LPNs.
|
||||
The LPN is the bridge between the physical world (a pallet on a rack) and the logical world (stock records, tasks, orders). EasyWMS tracks every LPN's location, weight, status, contents, and relationships (stacked, matched, client-linked) in real time. All WMS movements - reception, putaway, picking, replenishment, shipping - are expressed as operations on LPNs.
|
||||
|
||||
The term "container" in EasyWMS source documentation is synonymous with LPN. The entity name in the Application Dictionary is **Container**; the UI and documentation use both terms interchangeably.
|
||||
|
||||
@@ -52,9 +52,9 @@ The term "container" in EasyWMS source documentation is synonymous with LPN. The
|
||||
| **Type** | Physical LPN type (e.g. EuroPallet, American pallet, box). Defines dimensional and weight constraints. Configured in EasyS. |
|
||||
| **Location** | Current warehouse location where the LPN is stored. |
|
||||
| **Height** | Measured in mm. Set by: PLC/SCA gauge at PIE station, user input during reception, ASN pre-notification, or manual screen edit. Includes the max height of any LPN stacked on top. |
|
||||
| **Occupation percentage** | % of LPN capacity used by its stock. Not calculated automatically by EasyWMS — editable from the LPN view or set by the user. |
|
||||
| **Occupation percentage** | % of LPN capacity used by its stock. Not calculated automatically by EasyWMS - editable from the LPN view or set by the user. |
|
||||
| **Is client LPN** | Boolean. `true` if the LPN's stock is assigned to a shipping order (outbound). Drives picking, shipping, and consolidation logic. |
|
||||
| **Division type** | Internal partition configuration (see [Division Types](#division-types)). Only supported in automatic warehouses. LPNs with divisions only accept entry and picking tasks — shipping tasks are invalid. Content must be fully picked out before division LPN is used for shipping. |
|
||||
| **Division type** | Internal partition configuration (see [Division Types](#division-types)). Only supported in automatic warehouses. LPNs with divisions only accept entry and picking tasks - shipping tasks are invalid. Content must be fully picked out before division LPN is used for shipping. |
|
||||
| **Status** | Current lifecycle state (see [Lifecycle & Statuses](#lifecycle--statuses)). |
|
||||
|
||||
### Weight Properties
|
||||
@@ -89,7 +89,7 @@ LPN types define the physical characteristics of an empty LPN. Configured in the
|
||||
| Maximum weight | kg | Max safe weight when loaded |
|
||||
| Collapse | mm | Max width deviation due to load collapse. Effective width = Width + 2 × Collapse. |
|
||||
|
||||
The collapse parameter matters for automatic warehouse location sizing — the system checks effective width when searching for a putaway location.
|
||||
The collapse parameter matters for automatic warehouse location sizing - the system checks effective width when searching for a putaway location.
|
||||
|
||||
**UI path:** EasyS tool (not EasyWMS web UI).
|
||||
|
||||
@@ -258,7 +258,7 @@ Non-pre-notified stock arriving from a supplier in containers with multiple item
|
||||
| **Receipt and putaway** | Stock received on equipment; location search runs immediately for putaway. |
|
||||
| **Receipt on stage** | Stock registered in a stage; putaway done later by another operator or batch. |
|
||||
|
||||
A third variant: **exclusive reserve** — stock can be reserved for a specific shipping order at receipt time (configured via ROR message from ERP, see [erp-interface.md](../concepts/erp-interface.md)). The `CONFIRM_EXCLUSIVE_RESERVE_ASSIGNMENT` parameter controls whether the user must manually select the shipping order when multiple compatible orders exist.
|
||||
A third variant: **exclusive reserve** - stock can be reserved for a specific shipping order at receipt time (configured via ROR message from ERP, see [erp-interface.md](../concepts/erp-interface.md)). The `CONFIRM_EXCLUSIVE_RESERVE_ASSIGNMENT` parameter controls whether the user must manually select the shipping order when multiple compatible orders exist.
|
||||
|
||||
**ERP message sent at end of receipt:** `REF`
|
||||
**Transactions:** `CON.RECEP` (per container), `STK.RECEP` (per stock line)
|
||||
@@ -274,7 +274,7 @@ Unplanned, non-pre-notified stock with no entry order. A receipt is auto-created
|
||||
|
||||
### Partitioned Container Receipt
|
||||
|
||||
Both supplier and blind modes support receiving containers with internal partitions. Destination must always be an **automatic warehouse** — containers must be transported to a PIE or picking station after reception.
|
||||
Both supplier and blind modes support receiving containers with internal partitions. Destination must always be an **automatic warehouse** - containers must be transported to a PIE or picking station after reception.
|
||||
|
||||
---
|
||||
|
||||
@@ -291,19 +291,19 @@ Available actions on LPNs (full list from web UI):
|
||||
| LPN type modification | Change the LPN type. Only for **empty** LPNs. | PC |
|
||||
| Division type modification | Change division type. Only for **empty** LPNs. | PC |
|
||||
| Delete division | Remove division from LPN. Only for **empty** LPNs. | PC |
|
||||
| Location change | Change LPN's recorded location. Does NOT create a movement task — only updates the data record. Treated as [manual movement](../concepts/manual-movements.md). In open APS FIFO channels, only accessible locations shown. | PC / RFT |
|
||||
| Location change | Change LPN's recorded location. Does NOT create a movement task - only updates the data record. Treated as [manual movement](../concepts/manual-movements.md). In open APS FIFO channels, only accessible locations shown. | PC / RFT |
|
||||
| Send to Lost & Found | Send LPN to virtual L&F location when physical location unknown. In APS FIFO, only accessible or last LPN in channel. Stacked LPN: entire partial block (selected LPN + children) goes to L&F. | PC |
|
||||
| Relocation (automatic warehouses) | Change physical location via system-directed move: Automatic (putaway strategies), To an aisle (putaway strategies in selected aisle), To a location (no strategies, physical compatibility only), To a level (putaway strategies in selected level). | PC |
|
||||
| Mark as full / not full | Flag LPN as full so replenishment at PK conveyor skips it. Manual additions still possible. | PC |
|
||||
| Mark division as full / not full | Same as above for a specific division within a LPN. | PC |
|
||||
| Shipping order unassignment | Unlink LPN from its shipping order. Works for mapped, prepared, or loaded LPN. No movement task created — operator is responsible for physical move. | PC |
|
||||
| Shipping order unassignment | Unlink LPN from its shipping order. Works for mapped, prepared, or loaded LPN. No movement task created - operator is responsible for physical move. | PC |
|
||||
| Extraction request to PK conveyor | Request extraction from a station to a Picking conveyor for an action outside the system. | PC |
|
||||
| Request empty LPN to PK | Request empty LPN(s) of specific type/divisions to be sent to a Picking conveyor. | PC |
|
||||
| Extraction request to PS conveyor | Request extraction to an Outbound conveyor (PS). | PC |
|
||||
| Request empty LPN to PS | Extract empty LPN to Outbound conveyor (often to fill outside PK, e.g., for reception). | PC |
|
||||
| Set depth coordinate | APS3D only — manually set depth coordinate for a LPN in an APS location. Superadmin only. | PC |
|
||||
| Set depth coordinate | APS3D only - manually set depth coordinate for a LPN in an APS location. Superadmin only. | PC |
|
||||
| Manual compacting | APS/APSFIFO: compact LPN when free positions exist in front. | PC |
|
||||
| Exchange LPN | APS3D only — swap a LPN in channel for one outside; must be same type. Superadmin only. | PC |
|
||||
| Exchange LPN | APS3D only - swap a LPN in channel for one outside; must be same type. Superadmin only. | PC |
|
||||
| Consulting equipment LPNs (My LPNs) | View all LPNs on own equipment: code, type, status, stock lines (item, qty, UoM, logistic attributes). Can unload or reject LPNs from this view. | RFT |
|
||||
| Putaway search location trace | Report of last location search for this LPN. Shows strategies applied, excluded aisles, routes with issues, reserve percentages, stock line details. Superadmin sees full technical trace. | PC |
|
||||
| Stack / Match LPNs | Group LPNs vertically (stack) or horizontally (match). | RFT |
|
||||
@@ -322,7 +322,7 @@ EasyWMS interprets the following **GS1 Application Identifiers (AI)** on existin
|
||||
|
||||
| AI | Meaning |
|
||||
|---|---|
|
||||
| (00) | SSCC — Serial Shipping Container Code |
|
||||
| (00) | SSCC - Serial Shipping Container Code |
|
||||
| (01) | GTIN grouping code / DUN14 |
|
||||
| (02) | EAN |
|
||||
| (10) | Lot number |
|
||||
@@ -343,7 +343,7 @@ Procedure:
|
||||
2. Fill in the desired **prefix**
|
||||
3. **Save**
|
||||
|
||||
Existing LPN codes are not rewritten — only containers generated after the change use the new prefix.
|
||||
Existing LPN codes are not rewritten - only containers generated after the change use the new prefix.
|
||||
|
||||
---
|
||||
|
||||
@@ -373,20 +373,20 @@ All container events generate transactions recorded in EasyWMS audit trail:
|
||||
|---|---|---|
|
||||
| `CON.ASN.001` | Container received for an ASN advance notice order | → `ASO` |
|
||||
| `CON.CNL.ASN` | Pre-notified container deleted or rejected | → `ASK` |
|
||||
| `CON.COC` | Client container closed at Preparation Zone (MP) | — |
|
||||
| `CON.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.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 | — |
|
||||
| `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).
|
||||
|
||||
@@ -412,7 +412,7 @@ LPN-related ERP messages (all documented in [concepts/erp-interface.md](../conce
|
||||
|
||||
| Path | Description |
|
||||
|---|---|
|
||||
| `Warehouse > LPN` | Main LPN management view — all operations |
|
||||
| `Warehouse > LPN` | Main LPN management view - all operations |
|
||||
| `Workstations > Picking` | LPN view from picking workstation perspective |
|
||||
| `Masters > Lock types` → "LPN lock types" | Manage lock type definitions |
|
||||
| `Masters > Division LPN types` | Manage division type definitions |
|
||||
@@ -453,7 +453,7 @@ LPN-related ERP messages (all documented in [concepts/erp-interface.md](../conce
|
||||
|
||||
**Cannot modify LPN type or division:**
|
||||
- Symptom: Type/division change rejected.
|
||||
- Cause: LPN is not empty — contains stock.
|
||||
- Cause: LPN is not empty - contains stock.
|
||||
- Solution: Move or pick out all stock first, then change the type.
|
||||
|
||||
**Putaway location not found for stacked LPN:**
|
||||
@@ -470,21 +470,21 @@ LPN-related ERP messages (all documented in [concepts/erp-interface.md](../conce
|
||||
|
||||
## Related
|
||||
|
||||
- [concepts/location.md](../concepts/location.md) — Locations where LPNs are stored; capacity, FIFO, dynamic, APS types
|
||||
- [concepts/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
|
||||
- [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
|
||||
|
||||
+24
-24
@@ -49,9 +49,9 @@ last_compiled: "2026-04-17"
|
||||
A **count** (also called inventory or stock take) in EasyWMS is a formal process for verifying that the physical stock in the warehouse matches the quantities recorded in the system. When discrepancies are found, the system adjusts its records accordingly and notifies the ERP.
|
||||
|
||||
EasyWMS supports three fundamental counting approaches:
|
||||
- **Guided counts** — a count order is created (from the WMS interface or by ERP messaging), tasks are generated, and operators follow those tasks with their RFT.
|
||||
- **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.
|
||||
- **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).
|
||||
|
||||
@@ -73,8 +73,8 @@ A single count order can mix lines of different types.
|
||||
|
||||
| Method | Who initiates | Order required | Auto-adjusts |
|
||||
|---|---|---|---|
|
||||
| **Guided count — from WMS interface** | Warehouse manager (PC) | Yes | No (ERP notified via STV per diff) |
|
||||
| **Guided count — from ERP (COR message)** | ERP | Yes | No (ERP notified via COF at close) |
|
||||
| **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 |
|
||||
@@ -128,7 +128,7 @@ Closing can be **automatic** (`AUTOCLOSE_COUNT_ORDERS` parameter) or manual. Ord
|
||||
|
||||
---
|
||||
|
||||
## Guided Count — Execution
|
||||
## Guided Count - Execution
|
||||
|
||||
### Task Generation at Release
|
||||
|
||||
@@ -145,14 +145,14 @@ Locations configured as "does not allow inventory" in EasyS are skipped. Locks o
|
||||
### Blind vs. Informed Mode
|
||||
|
||||
For **location count** lines, the **Is Informed** flag (FR : `Est renseigné`) determines the counting mode:
|
||||
- **Blind count** — operator enters quantities without seeing current system values (default). Operator must enter item, quantity, logistic attributes from scratch.
|
||||
- **Informed count** — system shows current recorded stock; operator adjusts as needed.
|
||||
- **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.
|
||||
**Per-line setting.** `Est renseigné` is a **per-line** toggle, not a per-order toggle - within the same count order, some lines (e.g. the picking aisles) can be `Informed` while others (e.g. the reserve) stay blind.
|
||||
|
||||
> If the `Est renseigné` column is missing from the count-line grid : select a line and click **"Visibilité"**. If it is still hidden, the grid's visibility condition must be relaxed — edit the `CountOrderLineVList` view and comment out (`/* … */`) the visibility condition, forcing it to `true`.
|
||||
> If the `Est renseigné` column is missing from the count-line grid : select a line and click **"Visibilité"**. If it is still hidden, the grid's visibility condition must be relaxed - edit the `CountOrderLineVList` view and comment out (`/* … */`) the visibility condition, forcing it to `true`.
|
||||
|
||||
### Counting items with serial numbers
|
||||
|
||||
@@ -163,7 +163,7 @@ When an item is counted on an attribute unique per piece (a serial number) :
|
||||
3. Click **"Terminé"** when every piece has a serial.
|
||||
4. Enter the next item of the location, or click **"Fin"** if the location is done.
|
||||
|
||||
The WMS then reports that the original (no-serial) item line was not found — click **"Introuvable"** : this removes the no-serial stock line and creates the new serialized stock lines in its place.
|
||||
The WMS then reports that the original (no-serial) item line was not found - click **"Introuvable"** : this removes the no-serial stock line and creates the new serialized stock lines in its place.
|
||||
|
||||
### Count in Automatic Warehouse (Workstation)
|
||||
|
||||
@@ -186,12 +186,12 @@ For picking locations with labeled partitions assigned per item (dedicated picki
|
||||
- Reassign partitions to items during the count
|
||||
|
||||
Parameters:
|
||||
- `UNLOAD_CREATE_PRODUCT_LOCATION` — when active, auto-creates PDL assignment for a newly counted item
|
||||
- `ALLOW_DYNAMIC_UNASSIGNED_PARTITION` — allows dynamically unassigning empty partitions during count
|
||||
- `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)
|
||||
## Physical Count (RF - No Order Required)
|
||||
|
||||
The **Physical Count** is a fast, location-by-location blind count initiated directly from the RFT. No count order is needed.
|
||||
|
||||
@@ -250,9 +250,9 @@ Count orders generated by cycle count **cannot be re-released after cancellation
|
||||
|
||||
### Iteration States
|
||||
|
||||
- **On progress** — active iteration running
|
||||
- **Finished** — iteration end date passed (transitions next day)
|
||||
- **Canceled** — manually terminated early
|
||||
- **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.
|
||||
|
||||
@@ -332,15 +332,15 @@ For counts **not** created by the ERP (manual WMS counts, physical counts, cycle
|
||||
| Count line shows conflict icon (no inventory allowed) | Location not flagged for inventory in EasyS | Fix location config in EasyS or delete the line |
|
||||
| COF message not sent after close | Count originated from COR and has pending adjustments (double validation) | Validate or cancel all pending adjustments |
|
||||
| Cycle count generates uneven task distribution | Volatile stock levels change mid-iteration (especially item schedules) | Expected behavior; adjust schedule parameters if needed |
|
||||
| Cannot re-release a cycle count after cancel | By design — cycle count orders are non-re-releasable | Create a new manual count for the affected locations |
|
||||
| Cannot re-release a cycle count after cancel | By design - cycle count orders are non-re-releasable | Create a new manual count for the affected locations |
|
||||
|
||||
---
|
||||
|
||||
## Related
|
||||
|
||||
- [[stock-adjustment]] — Count discrepancies trigger STK.ADJ adjustments; double validation applies to both
|
||||
- [[stock]] — 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
|
||||
- [[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
|
||||
|
||||
@@ -4,7 +4,7 @@ type: concept
|
||||
sources:
|
||||
- areas/crossdocking/crossdocking_manual/index.md
|
||||
- areas/crossdocking/crossdocking_manual/crossdocking_warehouse.md
|
||||
- areas/crossdocking/crossdocking_manual/crossdocking_opportunity.md (404 — sourced from index.md description)
|
||||
- areas/crossdocking/crossdocking_manual/crossdocking_opportunity.md (404 - sourced from index.md description)
|
||||
- areas/putaway/putaway_admin/index.md (Group by SO/Route strategy type)
|
||||
- sources/archives/06_Gestion_cross_docking.md
|
||||
related:
|
||||
@@ -38,8 +38,8 @@ Both types apply to containers, stacked containers, carts, and loose stock recei
|
||||
When an operator is about to putaway received stock/containers, EasyWMS checks if any unreleased or in-preparation shipping order needs that stock. If yes, instead of going to bulk storage, the stock is directed straight to the dock, stage, or buffer associated with the shipping order.
|
||||
|
||||
The process triggers at two moments:
|
||||
1. **After receipt into equipment** — operator is ready to putaway what was received
|
||||
2. **When preparing to putaway from a reception stage** — stock received in a staging area is evaluated for direct transfer
|
||||
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
|
||||
|
||||
@@ -73,7 +73,7 @@ For **cutting stock items** in non-consolidating conversions:
|
||||
|
||||
### Concept (Warehouse)
|
||||
|
||||
If opportunity crossdocking is not possible (no shipping order needing immediate routing, or the stock quantity exceeds a single order's need), EasyWMS evaluates **crossdocking to warehouse**: the stock is placed in dedicated **crossdocking locations** near the shipping area. When the shipping order is eventually released, these crossdocking locations are consulted first during stock assignment — ensuring minimum travel distance for shipping.
|
||||
If opportunity crossdocking is not possible (no shipping order needing immediate routing, or the stock quantity exceeds a single order's need), EasyWMS evaluates **crossdocking to warehouse**: the stock is placed in dedicated **crossdocking locations** near the shipping area. When the shipping order is eventually released, these crossdocking locations are consulted first during stock assignment - ensuring minimum travel distance for shipping.
|
||||
|
||||
The stock is not yet assigned to any shipping order during the crossdocking-to-warehouse placement. The link to the order happens at release time.
|
||||
|
||||
@@ -94,7 +94,7 @@ For crossdocking to warehouse to execute:
|
||||
### Process Flow (Warehouse)
|
||||
|
||||
1. Operator is about to putaway received container/stock
|
||||
2. EasyWMS first tries opportunity crossdocking (direct to dock) — if not possible:
|
||||
2. EasyWMS first tries opportunity crossdocking (direct to dock) - if not possible:
|
||||
3. EasyWMS evaluates crossdocking to warehouse:
|
||||
a. Identifies candidate shipping orders meeting criteria
|
||||
b. Checks if existing crossdocking locations already have sufficient stock
|
||||
@@ -189,7 +189,7 @@ No special location or strategy configuration required. The system automatically
|
||||
3. **Putaway strategies**: create and enable at least one strategy with "Is crossdocking" = true, including destination rules targeting the crossdocking locations
|
||||
4. **Stock assignment**: ensure the stock assignment strategy consults crossdocking locations first when the shipping order is released (these locations are consulted preferentially automatically)
|
||||
|
||||
### Mecalux France — EasyS / SmartUI Setup Notes
|
||||
### Mecalux France - EasyS / SmartUI Setup Notes
|
||||
|
||||
Additional setup steps consolidated from Mecalux France practice (in addition to the items above) :
|
||||
|
||||
@@ -203,16 +203,16 @@ Additional setup steps consolidated from Mecalux France practice (in addition to
|
||||
1. On eligible items, enable **Cross-docking** in the advanced data tab.
|
||||
2. Create the crossdocking putaway strategy **in sequence position 1** so it runs before the other putaway strategies.
|
||||
|
||||
**Criteria tab** : enable crossdocking. ⚠️ Without any additional criterion, **all items** will be treated as crossdocking at reception — always add conditions on the state of the pending outbound orders (e.g. status "En attente") to avoid this.
|
||||
**Criteria tab** : enable crossdocking. ⚠️ Without any additional criterion, **all items** will be treated as crossdocking at reception - always add conditions on the state of the pending outbound orders (e.g. status "En attente") to avoid this.
|
||||
|
||||
**Rules tab** : set `Zone` to the crossdocking zone created in EasyS.
|
||||
|
||||
### Mecalux France — Known Behavior Notes
|
||||
### Mecalux France - Known Behavior Notes
|
||||
|
||||
- **Reception must be done on the RFT** : the reception buffer does not trigger crossdocking evaluation. If reception is performed on the buffer, crossdocking is bypassed silently.
|
||||
- **Buffer over dock for direct XD** : when the outbound order has an assigned buffer, direct (opportunity) crossdocking routes stock to the *buffer* rather than the dock — useful for a subsequent packing step.
|
||||
- **Buffer over dock for direct XD** : when the outbound order has an assigned buffer, direct (opportunity) crossdocking routes stock to the *buffer* rather than the dock - useful for a subsequent packing step.
|
||||
- **Crossdocking overrides reserve** : if a crossdocking location exists, the WMS redirects to it even if reserve stock is already available.
|
||||
- **No label is printed** in standard direct (opportunity) crossdocking, even for a full pallet — plan for a custom label flow if the customer requires one.
|
||||
- **No label is printed** in standard direct (opportunity) crossdocking, even for a full pallet - plan for a custom label flow if the customer requires one.
|
||||
|
||||
## Common Errors
|
||||
|
||||
@@ -222,7 +222,7 @@ Additional setup steps consolidated from Mecalux France practice (in addition to
|
||||
|
||||
**Stock placed in crossdocking location but not prioritized at release:** Stock assignment strategy doesn't prioritize crossdocking locations over normal storage. Check the stock assignment strategy configuration to ensure crossdocking location preferences are applied.
|
||||
|
||||
**Crossdocking location fills up, remainder goes to standard storage:** This is normal behavior — the crossdocking process places only what fits. The remainder follows standard putaway. No error; just an expected split.
|
||||
**Crossdocking location fills up, remainder goes to standard storage:** This is normal behavior - the crossdocking process places only what fits. The remainder follows standard putaway. No error; just an expected split.
|
||||
|
||||
**Shipping order candidate filtered out unexpectedly:** The crossdocking strategy has filters on order status, priority, or days until release/load that exclude the order. Review the "Is crossdocking" strategy's filter settings.
|
||||
|
||||
@@ -232,18 +232,18 @@ Additional setup steps consolidated from Mecalux France practice (in addition to
|
||||
|
||||
| Interface | Path |
|
||||
|---|---|
|
||||
| Web — crossdocking putaway strategies | "Configuration" → "Putaway strategies" (filter by "Is crossdocking") |
|
||||
| Web — 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 |
|
||||
| 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
|
||||
- [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
|
||||
|
||||
@@ -34,7 +34,7 @@ last_compiled: "2026-04-10"
|
||||
|
||||
Cutting stock is a specialization of item management for items that are **measured and cut to order** rather than picked in discrete unit quantities. Examples: rope, electric cable, chain, flexible pipe (hose), fabric rolls, wire. These items exist as continuous rolls or coils and can only be shipped in specific lengths.
|
||||
|
||||
Cutting stock is an **exclusively manual warehouse feature** — not supported in automated or semi-automated warehouses.
|
||||
Cutting stock is an **exclusively manual warehouse feature** - not supported in automated or semi-automated warehouses.
|
||||
|
||||
By definition: **a cutting item is any item with an assigned cutting profile.** The profile defines how the item behaves: whether it requires a cutting station, how it's labeled, and how its stock consolidation works.
|
||||
|
||||
@@ -44,11 +44,11 @@ By definition: **a cutting item is any item with an assigned cutting profile.**
|
||||
|
||||
The defining characteristic of cutting stock is that its **base UoM conversion does NOT consolidate**. This means:
|
||||
|
||||
- Multiple stock lines of identical qualities (same item, lot, status, logistic attributes) can coexist in the same location/container as **separate records** — they are never merged.
|
||||
- Multiple stock lines of identical qualities (same item, lot, status, logistic attributes) can coexist in the same location/container as **separate records** - they are never merged.
|
||||
- Each stretch is an individual record with its own quantity (length).
|
||||
- This enables precise tracking of available stretch lengths.
|
||||
|
||||
**Practical implication:** If you have three 30m rolls of the same cable in the same location, you have three separate stock records (30m, 30m, 30m) — not one 90m record.
|
||||
**Practical implication:** If you have three 30m rolls of the same cable in the same location, you have three separate stock records (30m, 30m, 30m) - not one 90m record.
|
||||
|
||||
### Base UoM Rule
|
||||
|
||||
@@ -150,7 +150,7 @@ Cutting station can be locked via "Stations" view to prevent new stock assignmen
|
||||
- Routes: station ↔ stages, station ↔ equipment, station ↔ warehouse, stages ↔ docks/stages/consolidation
|
||||
- Associated stages: routes to cutting station, other stages of same station, stages of stations cutting same profile, equipment, warehouse, docks/stages/consolidation
|
||||
|
||||
**Label recommendations at cutting stations:** Print labels for cutting station code, station location code, receiving stage location code, shipping stage location code — operators confirm these codes continuously during cutting.
|
||||
**Label recommendations at cutting stations:** Print labels for cutting station code, station location code, receiving stage location code, shipping stage location code - operators confirm these codes continuously during cutting.
|
||||
|
||||
## Reception of Cutting Stock
|
||||
|
||||
@@ -202,7 +202,7 @@ Station (integrated) items can be included in shipping orders, order groups, and
|
||||
|
||||
**Return to warehouse:** Operator can return stock without pending assignments from station to warehouse at any time.
|
||||
|
||||
**Note:** Once a cutting stock line has tasks in "In Process" or "Finished" status, quantity cannot be changed — but line can always be canceled.
|
||||
**Note:** Once a cutting stock line has tasks in "In Process" or "Finished" status, quantity cannot be changed - but line can always be canceled.
|
||||
|
||||
### Delegated Cutting in Station
|
||||
|
||||
@@ -232,7 +232,7 @@ Because cutting requires tools and cannot be performed everywhere, it is **not p
|
||||
|
||||
### Enter Quantity Mode
|
||||
|
||||
Cutting stock is indivisible — you cannot pick one unit at a time to confirm total. Therefore:
|
||||
Cutting stock is indivisible - you cannot pick one unit at a time to confirm total. Therefore:
|
||||
- **"Enter quantity mode" must be set to "Manually"** in the item's shipping profile
|
||||
- The total length is confirmed in one step at the moment of cutting
|
||||
|
||||
@@ -250,7 +250,7 @@ Counting cutting stock (in non-consolidating conversions) differs from standard
|
||||
|
||||
2. **Assign user status during counting:** Set status before entering a stretch; status persists for subsequent stretches until changed or removed. Can be assigned/unassigned to any stretch in the list.
|
||||
|
||||
3. **Modify counted lines:** Delete any stretch (not edit quantity — deletion only). "Stretches" action lists all counted stretches. "Empty List" action clears all. Lines with user status are shown in list.
|
||||
3. **Modify counted lines:** Delete any stretch (not edit quantity - deletion only). "Stretches" action lists all counted stretches. "Empty List" action clears all. Lines with user status are shown in list.
|
||||
|
||||
**Informed count mode:** For locations where exact roll lengths are unknown. Verifies bulk presence only. Allows comparison and adjustment by operator.
|
||||
|
||||
@@ -273,8 +273,8 @@ See [[quality-control]] for full details. Cutting stock has specific lock behavi
|
||||
See [[manual-movements]] for full details. Specific cutting stock rules:
|
||||
|
||||
- Cutting stock moves require **exact stretch length confirmation**
|
||||
- Moving cutting stock is only allowed as a whole stretch — partial moves of a stretch are not supported (the indivisibility rule)
|
||||
- If move requires cutting to reduce length, that is not permitted via manual movement — must go through the picking/cutting process
|
||||
- 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
|
||||
|
||||
@@ -285,7 +285,7 @@ Cutting outside storage locations is not permitted. However, **opportunity cross
|
||||
See [[stock-adjustment]] for full details. Cutting-specific behavior:
|
||||
|
||||
- Adjustments apply to individual stretch records
|
||||
- Labels can be printed for cutting stock from the "Location adjustment" RFT process — only if the cutting profile has "Label source stock" active
|
||||
- Labels can be printed for cutting stock from the "Location adjustment" RFT process - only if the cutting profile has "Label source stock" active
|
||||
- Transactions: STK.ADJ
|
||||
|
||||
## Parameters
|
||||
@@ -327,14 +327,14 @@ See [[stock-adjustment]] for full details. Cutting-specific behavior:
|
||||
|
||||
## Related
|
||||
|
||||
- [[product-item]] — Cutting profile is configured on the item master; base UoM rules apply
|
||||
- [[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
|
||||
- [[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
|
||||
|
||||
@@ -62,7 +62,7 @@ For each rotation strategy, destination rules specify where to move candidate co
|
||||
|---|---|
|
||||
| Same aisle | Move within the same aisle; skip if no valid location in aisle |
|
||||
| Specific aisle | Move to a designated automatic aisle; skip if no valid location |
|
||||
| Storage zones | One or more target zones (mandatory — at least one required) |
|
||||
| Storage zones | One or more target zones (mandatory - at least one required) |
|
||||
| Priority | Task priority for defragmentation tasks of this ABC+zone combination |
|
||||
|
||||
**Location search uses putaway strategies** in configured sequence order.
|
||||
@@ -78,7 +78,7 @@ For each rotation strategy, destination rules specify where to move candidate co
|
||||
|
||||
Shipping strategies pre-position containers assigned to upcoming orders near the warehouse exit, speeding up the shipping preparation process.
|
||||
|
||||
### Strategy Criteria — Shipping (Order / Container Selection)
|
||||
### Strategy Criteria - Shipping (Order / Container Selection)
|
||||
|
||||
| Criterion | Description |
|
||||
|---|---|
|
||||
@@ -93,7 +93,7 @@ Shipping strategies pre-position containers assigned to upcoming orders near the
|
||||
|
||||
> If orders don't have all stock assigned yet, the stock assignment process runs first.
|
||||
|
||||
### Strategy Rules — Shipping (Destination Selection)
|
||||
### Strategy Rules - Shipping (Destination Selection)
|
||||
|
||||
| Rule | Description |
|
||||
|---|---|
|
||||
@@ -193,9 +193,9 @@ Planners enable **unattended, scheduled** defragmentation. Both rotation and shi
|
||||
|
||||
## Related
|
||||
|
||||
- [[location]] — Defragmentation moves containers between locations; rotation strategies use storage zones; only automatic aisles are valid
|
||||
- [[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
|
||||
- [[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
|
||||
|
||||
@@ -82,7 +82,7 @@ All messages have a **version** suffix when multiple variants exist (e.g., ROR01
|
||||
| KIT | Kit | ERP → WMS | Create/update kit definitions |
|
||||
| LCK | Lock Type | ERP → WMS | Lock type master data |
|
||||
|
||||
#### ITM — Image fields
|
||||
#### ITM - Image fields
|
||||
|
||||
The `ITM01` message can optionally convey the article's picture. Two modes:
|
||||
|
||||
@@ -91,13 +91,13 @@ The `ITM01` message can optionally convey the article's picture. Two modes:
|
||||
| **Local file** | `<ItmPicture>nom-fichier.jpg</ItmPicture>` | File resolved against the folder pointed to by `UserImagesURI` in the WMS `appsettings.json`. Typical value : `C:/MLX/Data/Pictures/`. |
|
||||
| **URL** | `<ItmPictureUrl>https://…/photo.jpg</ItmPictureUrl>` | Fetched by the WMS when the client uses the display; `ItmPicture` takes precedence if both are present. |
|
||||
|
||||
> Requires read access on the `UserImagesURI` share from the WMS service account. The image is not uploaded via the ITM file — only the filename / URL is stamped on the item record.
|
||||
> Requires read access on the `UserImagesURI` share from the WMS service account. The image is not uploaded via the ITM file - only the filename / URL is stamped on the item record.
|
||||
|
||||
---
|
||||
|
||||
### Inbound / Receipt Messages
|
||||
|
||||
#### ROR — Receipt Order (ERP → WMS)
|
||||
#### ROR - Receipt Order (ERP → WMS)
|
||||
|
||||
The primary message for creating inbound orders.
|
||||
|
||||
@@ -124,11 +124,11 @@ The primary message for creating inbound orders.
|
||||
- Order code must be unique for new orders
|
||||
- Lines support optional `transactional` group to control failure behavior
|
||||
- Can create/modify/cancel lines individually after creation
|
||||
- Triggers [ROC](#roc--receipt-order-status-change-wms--erp) status change notifications
|
||||
- Triggers [ROC](#roc---receipt-order-status-change-wms--erp) status change notifications
|
||||
|
||||
---
|
||||
|
||||
#### ASN — Advanced Shipping Notice (ERP → WMS)
|
||||
#### ASN - Advanced Shipping Notice (ERP → WMS)
|
||||
|
||||
Pre-notifies WMS of containers en route to the warehouse.
|
||||
|
||||
@@ -151,12 +151,12 @@ Pre-notifies WMS of containers en route to the warehouse.
|
||||
|
||||
**Notes:**
|
||||
- Creates pending stock at ASN virtual location
|
||||
- If container is received: triggers [ASO](#aso--advanced-shipping-notice-ok-wms--erp) response
|
||||
- If container is rejected or deleted: triggers [ASK](#ask--advanced-shipping-notice-ko-wms--erp) response
|
||||
- If container is received: triggers [ASO](#aso---advanced-shipping-notice-ok-wms--erp) response
|
||||
- If container is rejected or deleted: triggers [ASK](#ask---advanced-shipping-notice-ko-wms--erp) response
|
||||
|
||||
---
|
||||
|
||||
#### SRN — Stock Replenish Notice (ERP → WMS)
|
||||
#### SRN - Stock Replenish Notice (ERP → WMS)
|
||||
|
||||
Pre-notifies WMS of loose stock for automatic warehouse replenishment.
|
||||
|
||||
@@ -178,7 +178,7 @@ Pre-notifies WMS of loose stock for automatic warehouse replenishment.
|
||||
|
||||
---
|
||||
|
||||
#### ROC — Receipt Order Status Change (WMS → ERP)
|
||||
#### ROC - Receipt Order Status Change (WMS → ERP)
|
||||
|
||||
Notifies ERP of receipt order status transitions.
|
||||
|
||||
@@ -195,13 +195,13 @@ Notifies ERP of receipt order status transitions.
|
||||
|
||||
---
|
||||
|
||||
#### ROF — Receipt Order Finalization (WMS → ERP)
|
||||
#### ROF - Receipt Order Finalization (WMS → ERP)
|
||||
|
||||
Notifies ERP that a receipt order has been closed or canceled, with received quantities.
|
||||
|
||||
**Versions:**
|
||||
- `ROF01`: Standard finalization
|
||||
- `ROF02`: Extended with detailed line-level quantities — **the version generated when closing an inbound order sourced from a `Transfer` shipping order** (two-warehouse flow). For standard supplier receipts, ROF01 is emitted.
|
||||
- `ROF02`: Extended with detailed line-level quantities - **the version generated when closing an inbound order sourced from a `Transfer` shipping order** (two-warehouse flow). For standard supplier receipts, ROF01 is emitted.
|
||||
|
||||
**Key fields:**
|
||||
| Field | Description |
|
||||
@@ -219,7 +219,7 @@ Notifies ERP that a receipt order has been closed or canceled, with received qua
|
||||
|
||||
---
|
||||
|
||||
#### REF — Receipt Finalization (WMS → ERP)
|
||||
#### REF - Receipt Finalization (WMS → ERP)
|
||||
|
||||
Notifies ERP that a **receipt** (physical receiving event) has been closed.
|
||||
|
||||
@@ -247,7 +247,7 @@ Notifies ERP that a **receipt** (physical receiving event) has been closed.
|
||||
|
||||
---
|
||||
|
||||
#### ASO — Advanced Shipping Notice OK (WMS → ERP)
|
||||
#### ASO - Advanced Shipping Notice OK (WMS → ERP)
|
||||
|
||||
Confirms that a pre-notified container has been successfully received.
|
||||
|
||||
@@ -262,11 +262,11 @@ Confirms that a pre-notified container has been successfully received.
|
||||
| ReceiptCode | Receipt document |
|
||||
| ReceivedDate | Reception timestamp |
|
||||
|
||||
> **DirectTransfer trigger** — when the expedition of a `<DirectTransfer>` shipping order is closed at the origin warehouse, EasyWMS automatically generates an `ASO01` message targeting the destination warehouse, creating the incoming ASN container(s). The ASO carries the container and its stock but **no reference to the originating `SorCode` / DirectTransfer header**. See [concepts/order-outbound.md](order-outbound.md#asn--directtransfer-flow).
|
||||
> **DirectTransfer trigger** - when the expedition of a `<DirectTransfer>` shipping order is closed at the origin warehouse, EasyWMS automatically generates an `ASO01` message targeting the destination warehouse, creating the incoming ASN container(s). The ASO carries the container and its stock but **no reference to the originating `SorCode` / DirectTransfer header**. See [concepts/order-outbound.md](order-outbound.md#asn---directtransfer-flow).
|
||||
|
||||
---
|
||||
|
||||
#### ASK — Advanced Shipping Notice KO (WMS → ERP)
|
||||
#### ASK - Advanced Shipping Notice KO (WMS → ERP)
|
||||
|
||||
Notifies ERP that a pre-notified container has been rejected or deleted.
|
||||
|
||||
@@ -280,11 +280,11 @@ Notifies ERP that a pre-notified container has been rejected or deleted.
|
||||
|
||||
**Triggered by:** `CON.CNL.ASN` transaction
|
||||
|
||||
> **DirectTransfer trigger** — deleting an ASN container of a DirectTransfer flow from SmartUI (`Entrepôt → Conteneurs ASN → Supprimer`) generates an `ASK01` to the ERP. As with the ASO, the message contains no reference to the upstream shipping order.
|
||||
> **DirectTransfer trigger** - deleting an ASN container of a DirectTransfer flow from SmartUI (`Entrepôt → Conteneurs ASN → Supprimer`) generates an `ASK01` to the ERP. As with the ASO, the message contains no reference to the upstream shipping order.
|
||||
|
||||
---
|
||||
|
||||
#### SRO — Stock Replenish OK (WMS → ERP)
|
||||
#### SRO - Stock Replenish OK (WMS → ERP)
|
||||
|
||||
Confirms that pre-notified loose stock has been used for automatic warehouse replenishment.
|
||||
|
||||
@@ -292,7 +292,7 @@ Confirms that pre-notified loose stock has been used for automatic warehouse rep
|
||||
|
||||
---
|
||||
|
||||
#### SRK — Stock Replenish KO (WMS → ERP)
|
||||
#### SRK - Stock Replenish KO (WMS → ERP)
|
||||
|
||||
Notifies that pre-notified loose stock has been canceled (not used for replenishment).
|
||||
|
||||
@@ -302,7 +302,7 @@ Notifies that pre-notified loose stock has been canceled (not used for replenish
|
||||
|
||||
### Outbound / Shipping Messages
|
||||
|
||||
#### SOR — Shipping Order (ERP → WMS)
|
||||
#### SOR - Shipping Order (ERP → WMS)
|
||||
|
||||
The primary message for creating outbound orders.
|
||||
|
||||
@@ -341,13 +341,13 @@ The primary message for creating outbound orders.
|
||||
| SOR02: PrpContTypeRequired | Required client container type |
|
||||
| SOR02: VASCode | VAS template |
|
||||
|
||||
**`SorType = DirectTransfer`** — inter-warehouse transfer; closing the expedition at origin emits an automatic `ASO01` on destination, pre-creating the ASN container (see [ASO](#aso--advanced-shipping-notice-ok-wms--erp) and [concepts/order-outbound.md](order-outbound.md#asn--directtransfer-flow)).
|
||||
**`SorType = DirectTransfer`** - inter-warehouse transfer; closing the expedition at origin emits an automatic `ASO01` on destination, pre-creating the ASN container (see [ASO](#aso---advanced-shipping-notice-ok-wms--erp) and [concepts/order-outbound.md](order-outbound.md#asn---directtransfer-flow)).
|
||||
|
||||
**`SorType = Transfer`** — inter-warehouse transfer variant where destination generates **a full inbound order** on expedition close (as opposed to DirectTransfer which only pre-notifies via ASN). The destination ROR carries the source SOR reference ; on close, destination emits a `ROF02` carrying the line-level quantities, which the origin warehouse uses to reconcile. See [concepts/order-outbound.md](order-outbound.md#transfer-two-warehouse-flow).
|
||||
**`SorType = Transfer`** - inter-warehouse transfer variant where destination generates **a full inbound order** on expedition close (as opposed to DirectTransfer which only pre-notifies via ASN). The destination ROR carries the source SOR reference ; on close, destination emits a `ROF02` carrying the line-level quantities, which the origin warehouse uses to reconcile. See [concepts/order-outbound.md](order-outbound.md#transfer---two-warehouse-flow-inbound-order-created).
|
||||
|
||||
---
|
||||
|
||||
#### SOC — Shipping Order Status Change (WMS → ERP)
|
||||
#### SOC - Shipping Order Status Change (WMS → ERP)
|
||||
|
||||
Notifies ERP of shipping order status transitions.
|
||||
|
||||
@@ -357,7 +357,7 @@ Notifies ERP of shipping order status transitions.
|
||||
|
||||
---
|
||||
|
||||
#### SOF — Shipping Order Finalization (WMS → ERP)
|
||||
#### SOF - Shipping Order Finalization (WMS → ERP)
|
||||
|
||||
Notifies ERP that a shipping order has been closed or canceled with shipped quantities.
|
||||
|
||||
@@ -379,11 +379,11 @@ Notifies ERP that a shipping order has been closed or canceled with shipped quan
|
||||
|
||||
---
|
||||
|
||||
#### DlvShareDeliveries — Merge outbound orders (ERP → WMS)
|
||||
#### DlvShareDeliveries - Merge outbound orders (ERP → WMS)
|
||||
|
||||
XML message used by the **Multi-Carrier / Deliveries module** to request that two or more outbound orders be prepared together (merged). A merged group shares client containers, carrier call, and closure.
|
||||
|
||||
**Eligibility** — all orders in the request must match on:
|
||||
**Eligibility** - all orders in the request must match on:
|
||||
|
||||
- Same account
|
||||
- Same site (warehouse)
|
||||
@@ -397,13 +397,13 @@ When `ALLOW_MERGE_DIFFERENT_ACCOUNT = true` is set, the "same account" rule is r
|
||||
- Stock assignment is executed across the merged scope (not per-order)
|
||||
- Client containers can carry lines from any order in the group
|
||||
- Order closure is triggered when the last line of the last order in the group is picked / when the carrier call returns
|
||||
- SOF is still emitted per source SOR — only preparation is shared
|
||||
- SOF is still emitted per source SOR - only preparation is shared
|
||||
|
||||
See [concepts/order-outbound.md](order-outbound.md#merge-order-fusion) for operator flows and limitations.
|
||||
|
||||
---
|
||||
|
||||
#### LOF — Load Finalization (WMS → ERP)
|
||||
#### LOF - Load Finalization (WMS → ERP)
|
||||
|
||||
Notifies ERP that a truck load has been closed (truck loaded and sealed).
|
||||
|
||||
@@ -421,7 +421,7 @@ Notifies ERP that a truck load has been closed (truck loaded and sealed).
|
||||
|
||||
---
|
||||
|
||||
#### WOR — Work Order (ERP → WMS)
|
||||
#### WOR - Work Order (ERP → WMS)
|
||||
|
||||
Creates kit assembly or other work orders.
|
||||
|
||||
@@ -429,7 +429,7 @@ Creates kit assembly or other work orders.
|
||||
|
||||
---
|
||||
|
||||
#### WOF — Work Order Finalization (WMS → ERP)
|
||||
#### WOF - Work Order Finalization (WMS → ERP)
|
||||
|
||||
Notifies ERP that a work order (kit assembly, etc.) has been closed or canceled.
|
||||
|
||||
@@ -437,7 +437,7 @@ Notifies ERP that a work order (kit assembly, etc.) has been closed or canceled.
|
||||
|
||||
---
|
||||
|
||||
#### RUT — Route (ERP → WMS)
|
||||
#### RUT - Route (ERP → WMS)
|
||||
|
||||
Creates or updates carrier routes.
|
||||
|
||||
@@ -453,7 +453,7 @@ Creates or updates carrier routes.
|
||||
|
||||
### Count Messages
|
||||
|
||||
#### COR — Count Order Request (ERP → WMS)
|
||||
#### COR - Count Order Request (ERP → WMS)
|
||||
|
||||
Requests WMS to create a physical count.
|
||||
|
||||
@@ -476,7 +476,7 @@ Requests WMS to create a physical count.
|
||||
|
||||
---
|
||||
|
||||
#### COF — Count Order Finalization (WMS → ERP)
|
||||
#### COF - Count Order Finalization (WMS → ERP)
|
||||
|
||||
Reports count results when a WMS-received count (from COR) is closed or canceled.
|
||||
|
||||
@@ -501,7 +501,7 @@ Reports count results when a WMS-received count (from COR) is closed or canceled
|
||||
|
||||
### Request Messages
|
||||
|
||||
#### STR — Stock Status Change Request (ERP → WMS)
|
||||
#### STR - Stock Status Change Request (ERP → WMS)
|
||||
|
||||
Requests WMS to apply or remove a quality lock on stock.
|
||||
|
||||
@@ -523,15 +523,15 @@ Requests WMS to apply or remove a quality lock on stock.
|
||||
| OwnerCode | Owner |
|
||||
| FltAttLot | Lot filter |
|
||||
| StaCode | Status code to apply |
|
||||
| StaUsrEnd | Lock expiry (UTC) — optional |
|
||||
| StaUsrEnd | Lock expiry (UTC) - optional |
|
||||
| StaUsrEmpty | Status to remove (for unlock) |
|
||||
| StaRecEmpty | Reception status to remove |
|
||||
|
||||
**Response:** [STC](#stc--stock-status-change-wms--erp) message per affected stock line
|
||||
**Response:** [STC](#stc---stock-status-change-wms--erp) message per affected stock line
|
||||
|
||||
---
|
||||
|
||||
#### SCR — Stock Count Request (ERP → WMS)
|
||||
#### SCR - Stock Count Request (ERP → WMS)
|
||||
|
||||
Requests WMS to report current stock for an item or lot.
|
||||
|
||||
@@ -544,11 +544,11 @@ Requests WMS to report current stock for an item or lot.
|
||||
| OwnerCode | Owner |
|
||||
| LotCode | Lot (optional) |
|
||||
|
||||
**Response:** [WSC](#wsc--warehouse-stock-count-wms--erp) message
|
||||
**Response:** [WSC](#wsc---warehouse-stock-count-wms--erp) message
|
||||
|
||||
---
|
||||
|
||||
#### CMC — Container Movement Confirmation (ERP → WMS)
|
||||
#### CMC - Container Movement Confirmation (ERP → WMS)
|
||||
|
||||
Notifies WMS of a container's destination after removal from outbound conveyor, when movements are managed by an external system.
|
||||
|
||||
@@ -563,7 +563,7 @@ Notifies WMS of a container's destination after removal from outbound conveyor,
|
||||
|
||||
### Notification Messages (WMS → ERP)
|
||||
|
||||
#### STV — Stock Variation (WMS → ERP)
|
||||
#### STV - Stock Variation (WMS → ERP)
|
||||
|
||||
Reports any stock quantity change (increase, decrease, creation, deletion, UoM change, logistic attribute change).
|
||||
|
||||
@@ -588,7 +588,7 @@ Reports any stock quantity change (increase, decrease, creation, deletion, UoM c
|
||||
|
||||
---
|
||||
|
||||
#### STC — Stock Status Change (WMS → ERP)
|
||||
#### STC - Stock Status Change (WMS → ERP)
|
||||
|
||||
Reports every stock quality status change (lock or unlock).
|
||||
|
||||
@@ -611,7 +611,7 @@ Reports every stock quality status change (lock or unlock).
|
||||
|
||||
---
|
||||
|
||||
#### WSC — Warehouse Stock Count (WMS → ERP)
|
||||
#### WSC - Warehouse Stock Count (WMS → ERP)
|
||||
|
||||
Response to SCR stock contrast request. Reports current stock quantities.
|
||||
|
||||
@@ -630,7 +630,7 @@ Response to SCR stock contrast request. Reports current stock quantities.
|
||||
|
||||
---
|
||||
|
||||
#### KST — Kit Assembled (WMS → ERP)
|
||||
#### KST - Kit Assembled (WMS → ERP)
|
||||
|
||||
Notifies ERP that kit stock has been assembled.
|
||||
|
||||
@@ -649,7 +649,7 @@ Notifies ERP that kit stock has been assembled.
|
||||
|
||||
---
|
||||
|
||||
#### UNK — Kit Disassembled (WMS → ERP)
|
||||
#### UNK - Kit Disassembled (WMS → ERP)
|
||||
|
||||
Notifies ERP that kit stock has been disassembled.
|
||||
|
||||
@@ -657,7 +657,7 @@ Notifies ERP that kit stock has been disassembled.
|
||||
|
||||
---
|
||||
|
||||
#### COS — Container Shipped to PS (WMS → ERP)
|
||||
#### COS - Container Shipped to PS (WMS → ERP)
|
||||
|
||||
Notifies ERP that a client container has been sent to the outbound conveyor (PS/Sortation).
|
||||
|
||||
@@ -675,7 +675,7 @@ Notifies ERP that a client container has been sent to the outbound conveyor (PS/
|
||||
|
||||
---
|
||||
|
||||
#### COC — Container Closed in MP (WMS → ERP)
|
||||
#### COC - Container Closed in MP (WMS → ERP)
|
||||
|
||||
Notifies ERP that a client container has been closed in a Preparation Zone (MP).
|
||||
|
||||
@@ -685,7 +685,7 @@ Notifies ERP that a client container has been closed in a Preparation Zone (MP).
|
||||
|
||||
---
|
||||
|
||||
#### ERR — Error (WMS → ERP)
|
||||
#### ERR - Error (WMS → ERP)
|
||||
|
||||
Sent when WMS cannot process an incoming ERP message. Contains the original message reference and error description.
|
||||
|
||||
@@ -714,7 +714,7 @@ ERP Response Queue ──→ ERP
|
||||
|
||||
### Transaction Post-processing
|
||||
|
||||
Many WMS transactions are marked **"Post-processed: yes"** — meaning after the internal transaction is written, a background post-processor generates the corresponding ERP message:
|
||||
Many WMS transactions are marked **"Post-processed: yes"** - meaning after the internal transaction is written, a background post-processor generates the corresponding ERP message:
|
||||
|
||||
| Transaction | Generated Message |
|
||||
|------------|-----------------|
|
||||
@@ -756,7 +756,7 @@ Beyond the core catalog, optional modules add their own ERP messages:
|
||||
| Kits | UNK | WMS → ERP | Kit manually disassembled (manual work orders) |
|
||||
| Store Fulfillment | TOR01 | ERP → WMS | Transfer order between stores/sub-warehouses |
|
||||
| Store Fulfillment | TOF01 | WMS → ERP | Transfer order finalized |
|
||||
| Store Fulfillment | TPV01 | ERP → WMS | POS sale notification — decrements store stock |
|
||||
| Store Fulfillment | TPV01 | ERP → WMS | POS sale notification - decrements store stock |
|
||||
| VAS | VAS01 | ERP → WMS | Create/update VAS templates, activities, and instructions |
|
||||
| VAS | SOR02 VASCode | ERP → WMS | VAS template reference per line in shipping order |
|
||||
| VAS | SOF (VAS field) | WMS → ERP | VAS model used + quantity returned per shipped line |
|
||||
@@ -784,13 +784,13 @@ Beyond the core catalog, optional modules add their own ERP messages:
|
||||
|
||||
## Related
|
||||
|
||||
- [Inbound Order](order-inbound.md) — Receipt order lifecycle and ROR/ROC/ROF details
|
||||
- [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
|
||||
- [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
|
||||
|
||||
+23
-23
@@ -27,12 +27,12 @@ A **kit** is an article resulting from the assembly of several component article
|
||||
ERP integration sends kit definitions via the **KIT** message. Individual components must already exist as items in the WMS.
|
||||
|
||||
A kit record consists of:
|
||||
- **Kit code** — the item code of the assembled article
|
||||
- **Component 1..N** — each component's item code + required quantity
|
||||
- **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.
|
||||
> ⚠️ **Profile requirement** - an article can only be configured as a kit if its logistic profile carries the **`Version`** logistic attribute. Otherwise the activation fails with a profile-mismatch error and the item must be reassigned to a profile that has `Version` and a reception control method.
|
||||
|
||||
## Creating a kit article (SmartUI)
|
||||
|
||||
@@ -52,7 +52,7 @@ Add components with **"Ajouter composant"** : item, quantity, main component.
|
||||
|
||||
### 1. Kit without assembly (no mounting)
|
||||
|
||||
The kit article has **assembled = NO**. When a shipping order requests a kit, the WMS splits picking into separate tasks — one per component — without any physical assembly step. The kit is "assembled" implicitly by delivering all components.
|
||||
The kit article has **assembled = NO**. When a shipping order requests a kit, the WMS splits picking into separate tasks - one per component - without any physical assembly step. The kit is "assembled" implicitly by delivering all components.
|
||||
|
||||
**Example**: A "Garden Set" kit containing 1 table + 4 chairs: picking generates two tasks (table pick, chairs pick). The final delivery is the two components together.
|
||||
|
||||
@@ -60,11 +60,11 @@ The kit article has **assembled = NO**. When a shipping order requests a kit, th
|
||||
|
||||
The kit article has **assembled = YES**. A physical work order is required: components are picked and brought to an assembly zone, the kit is built, and the resulting kit item is added to stock.
|
||||
|
||||
**Sub-type — on-demand assembly** (`assembled = YES`, `assembly_on_demand = YES`): the assembly can be triggered by a shipping order when kit stock is zero, without a pre-existing work order. Used when the ERP can create work orders autonomously.
|
||||
**Sub-type - on-demand assembly** (`assembled = YES`, `assembly_on_demand = YES`): the assembly can be triggered by a shipping order when kit stock is zero, without a pre-existing work order. Used when the ERP can create work orders autonomously.
|
||||
|
||||
**Sub-type — ERP-driven assembly** (`assembled = YES`, `assembly_on_demand = NO`): the assembly is only triggered by a Work Order (WOR) from the ERP or a manually created order. No automatic kit fabrication request is generated when stock is insufficient.
|
||||
**Sub-type - ERP-driven assembly** (`assembled = YES`, `assembly_on_demand = NO`): the assembly is only triggered by a Work Order (WOR) from the ERP or a manually created order. No automatic kit fabrication request is generated when stock is insufficient.
|
||||
|
||||
### SAGE 100C Connector — Nomenclature types
|
||||
### SAGE 100C Connector - Nomenclature types
|
||||
|
||||
When integrated with SAGE 100C, EasyWMS maps SAGE nomenclature types to kit configurations:
|
||||
|
||||
@@ -97,7 +97,7 @@ ERP sends WOR → WMS creates work order
|
||||
3. All components arrive at the assembly zone
|
||||
4. Operator scans and confirms assembly on TRF
|
||||
5. Component stock automatically decremented; kit stock created
|
||||
6. Kit returned to storage — available for shipping orders
|
||||
6. Kit returned to storage - available for shipping orders
|
||||
7. `WOF` sent to ERP at work order close or cancellation (only if originated from ERP)
|
||||
8. If work order was created manually: `KST` sent to ERP to notify consumed and created stock
|
||||
|
||||
@@ -119,22 +119,22 @@ ERP sends WOR (disassembly) → WMS creates work order
|
||||
2. WMS generates picking tasks for kit items to assembly zone
|
||||
3. Operator disassembles kits at the zone
|
||||
4. Kit stock decremented; each component's stock incremented
|
||||
5. Components returned to storage — available for picking
|
||||
5. Components returned to storage - available for picking
|
||||
6. `WOF` sent to ERP at close/cancellation (only if ERP-originated)
|
||||
7. If manual: `UNK` sent to ERP to notify consumed (kits) and created (components) stock
|
||||
|
||||
---
|
||||
|
||||
## Work Order Lifecycle — Creation, Modification, Cancellation
|
||||
## Work Order Lifecycle - Creation, Modification, Cancellation
|
||||
|
||||
### Creation modes
|
||||
|
||||
| Mode | Description |
|
||||
|---|---|
|
||||
| **From ERP** | `WOR` file — Work Order created with status **En attente** ; `WOF` sent at close/cancel |
|
||||
| **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 |
|
||||
| **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
|
||||
|
||||
@@ -151,8 +151,8 @@ When a WO is released, the WMS checks available stock in the kit zone. If insuff
|
||||
|
||||
## Closing a Work Order
|
||||
|
||||
- **Automatic** — once every requested kit has been assembled / disassembled.
|
||||
- **Manual** — allowed at any time as long as **at least one** kit has been processed.
|
||||
- **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
|
||||
@@ -171,8 +171,8 @@ When a WO is released, the WMS checks available stock in the kit zone. If insuff
|
||||
- Multiple components per kit; each component has item code + required quantity
|
||||
- Stock consumed at assembly is tracked per lot/batch for traceability purposes
|
||||
- Kit articles can have their own logistic profiles (reception, shipping, putaway) like any item
|
||||
- **No automatic re-order**: WMS never requests fabrication when kit stock is insufficient — this is always a manual or ERP-driven action
|
||||
- Component stock shortage at kit assembly time does not block the work order — operator must resolve
|
||||
- **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
|
||||
|
||||
---
|
||||
@@ -222,8 +222,8 @@ When a WO is released, the WMS checks available stock in the kit zone. If insuff
|
||||
|
||||
## Related
|
||||
|
||||
- [[product-item]] — Kit articles and components are both standard items with logistic profiles
|
||||
- [[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
|
||||
- [[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
|
||||
|
||||
+23
-23
@@ -49,7 +49,7 @@ Three GS1-128 container label types:
|
||||
|
||||
1. **SSCC label** (standard container label): Contains container code and is used for generic container identification. Barcode encodes the SSCC.
|
||||
|
||||
2. **GS1-128 mono-reference label** (for single-item containers): Dual barcode — upper for item, lower for container. Used when container has stock of only one item.
|
||||
2. **GS1-128 mono-reference label** (for single-item containers): Dual barcode - upper for item, lower for container. Used when container has stock of only one item.
|
||||
|
||||
3. **GS1-128 multi-reference label** (for multi-item containers or serialized items): For containers with multiple item stock lines or serial-number-controlled items.
|
||||
|
||||
@@ -57,8 +57,8 @@ Three GS1-128 container label types:
|
||||
|
||||
| AI | Content | Structure |
|
||||
|----|---------|-----------|
|
||||
| **00** | SSCC (container serial code) | n18 — always present |
|
||||
| **02** | Item alias (GTIN) | n14 — always present |
|
||||
| **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 |
|
||||
@@ -73,8 +73,8 @@ Lot (AI 10), if present, always appears in the lower barcode next to the SSCC.
|
||||
|--------|-----|------|
|
||||
| Generate from Easy WMS UI | Planner/admin | Pre-reception (select number of containers + copies per container) |
|
||||
| Generate from RF terminal | Operator | Pre-reception (select format, count, printer) |
|
||||
| Print GS1-128 in supplier receipt | Operator (RF) | During supplier receiving — for non-existing containers |
|
||||
| Print GS1-128 in blind receipt | Operator (RF) | During blind receiving — must be enabled by parameter |
|
||||
| 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).
|
||||
|
||||
@@ -110,13 +110,13 @@ Labels for individual stock items. Two formats: Code 128 and GS1-128.
|
||||
**GS1-128 item labels:**
|
||||
- Can be printed from receipt lines (pending/partially received) or from the Stock view (post-reception)
|
||||
- Number of labels entered by user
|
||||
- Format: A6 horizontal (148 × 105 mm) — label printer
|
||||
- Format: A6 horizontal (148 × 105 mm) - label printer
|
||||
|
||||
**GS1-128 Item Application Identifiers (AI):**
|
||||
|
||||
| AI | Content | Structure |
|
||||
|----|---------|-----------|
|
||||
| **01** | GTIN (item code) | n14 — always present |
|
||||
| **01** | GTIN (item code) | n14 - always present |
|
||||
| 10 | Lot number | an..20 |
|
||||
| 11 | Manufacturing date | n6 |
|
||||
| 15 | Best-before date | n6 |
|
||||
@@ -157,9 +157,9 @@ Specialized label for cutting stock in non-consolidating UoM conversions. Used t
|
||||
|
||||
**When labels are generated:** A cutting stock label is only printed for stock in non-consolidating UoM. Three triggers:
|
||||
|
||||
1. **During picking/cutting process** — if cutting profile has "Label cutting stock" or "Label source stock" flag active
|
||||
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
|
||||
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)
|
||||
@@ -202,7 +202,7 @@ An alternative to standard receiving processes that allows reading all barcode d
|
||||
| Mono-reference containers | Single-item containers |
|
||||
| Identical mono-reference containers | Batch of identical single-item containers |
|
||||
|
||||
**Process:** System reads all labels on the item/container until user presses "Done" or max reads is reached. If any data is unreadable, system asks for manual entry (except container code in mono-reference flows — requested at end if not read). Operator can press "Skip" at start to fall back to manual reception.
|
||||
**Process:** System reads all labels on the item/container until user presses "Done" or max reads is reached. If any data is unreadable, system asks for manual entry (except container code in mono-reference flows - requested at end if not read). Operator can press "Skip" at start to fall back to manual reception.
|
||||
|
||||
During multi-reading: type and height of container can be selected; stock statuses can be entered.
|
||||
|
||||
@@ -262,7 +262,7 @@ This section consolidates **every known trigger** for each document/label, inclu
|
||||
|---|---|
|
||||
| Menu **Entrepôt → Support** → select → *Imprimer étiquette* | Manual |
|
||||
| Menu **Entrepôt → Stock** → select line → *Imprimer étiquettes de support* | Manual |
|
||||
| ROR01 tag `<EnableLabelPrinting>` (boolean) | Auto — mono-reference container uses `DEFAUT_RECEPTION_LABEL_CONTAINER_REPORT_NAME` with `NUM_COPIES_RECEPTION_LABEL` copies; multi-reference uses `DEFAULT_RECEPTION_LABEL_MULTIREFERENCE_CONTAINER_REPORT_NAME` |
|
||||
| ROR01 tag `<EnableLabelPrinting>` (boolean) | Auto - mono-reference container uses `DEFAUT_RECEPTION_LABEL_CONTAINER_REPORT_NAME` with `NUM_COPIES_RECEPTION_LABEL` copies; multi-reference uses `DEFAULT_RECEPTION_LABEL_MULTIREFERENCE_CONTAINER_REPORT_NAME` |
|
||||
|
||||
### Client container label (shipping)
|
||||
|
||||
@@ -271,9 +271,9 @@ This section consolidates **every known trigger** for each document/label, inclu
|
||||
| SOR01 tag `<PrpContLabels>` | Auto-print at buffer/dock drop |
|
||||
| SmartUI **"Document printings"** on the buffer/POUMON → *Impression automatique de l'étiquette du support du client* | Auto (requires printer assigned) |
|
||||
| Menu **Entrepôt → Supports** → select a client container → *Imprimer étiquettes clients* | Manual |
|
||||
| Report selected by parameter `CLIENT_CONTAINER_LABEL_REPORT` | — |
|
||||
| Report selected by parameter `CLIENT_CONTAINER_LABEL_REPORT` | - |
|
||||
|
||||
### Packing list — per container ("Liste de conditionnement par support")
|
||||
### Packing list - per container ("Liste de conditionnement par support")
|
||||
|
||||
| Trigger | Notes |
|
||||
|---|---|
|
||||
@@ -281,9 +281,9 @@ This section consolidates **every known trigger** for each document/label, inclu
|
||||
| Menu **Sorties → Ordres de sortie** → select order → *Imprimer rapport → Liste de conditionnement (par support)* | Manual |
|
||||
| Menu **Entrepôt → Supports** → select → *Imprimer la liste de colisage* | Manual |
|
||||
| SOR02 tag `<DlvPrintDocumentation>` (boolean, Multi-Carrier module only) | Auto |
|
||||
| Report selected by parameter `CLIENT_CONTAINER_PACKING_REPORT` | — |
|
||||
| Report selected by parameter `CLIENT_CONTAINER_PACKING_REPORT` | - |
|
||||
|
||||
### Packing list — per item ("Liste de conditionnement par article")
|
||||
### Packing list - per item ("Liste de conditionnement par article")
|
||||
|
||||
| Trigger | Notes |
|
||||
|---|---|
|
||||
@@ -294,7 +294,7 @@ This section consolidates **every known trigger** for each document/label, inclu
|
||||
|
||||
| Trigger | Notes |
|
||||
|---|---|
|
||||
| ROR01 tag `<EnablePrintingItemLabel>` (boolean) | Auto — report name from `DEFAULT_RECEPTION_LABEL_ITEM_REPORT_NAME` |
|
||||
| ROR01 tag `<EnablePrintingItemLabel>` (boolean) | Auto - report name from `DEFAULT_RECEPTION_LABEL_ITEM_REPORT_NAME` |
|
||||
| Menu **Données principales → Articles** → select → *Imprimer étiquette* | Manual |
|
||||
|
||||
### Delivery note ("BL")
|
||||
@@ -379,9 +379,9 @@ All label-related parameters consolidated:
|
||||
|
||||
## Related
|
||||
|
||||
- [[container]] — Container types, LPN management, SSCC codes
|
||||
- [[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
|
||||
- [[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
|
||||
|
||||
+15
-15
@@ -30,7 +30,7 @@ last_compiled: "2026-04-17"
|
||||
|
||||
A location is any physical or virtual space capable of storing loose stock and/or containers within the warehouse. Locations are the fundamental spatial unit of Easy WMS: every piece of stock must have a location, every container must be placed in a location, and every movement task has a source and destination location.
|
||||
|
||||
Locations sit within a hierarchical spatial model: Organization → Warehouse (Site) → Zone → Aisle → Side → Column/Row. This hierarchy determines how putaway strategies are applied, how routes are calculated, and how work zones restrict equipment access. The configuration of each location — its type, storage mode, capacity, and logics — determines which processes can use it and how the system manages stock within it.
|
||||
Locations sit within a hierarchical spatial model: Organization → Warehouse (Site) → Zone → Aisle → Side → Column/Row. This hierarchy determines how putaway strategies are applied, how routes are calculated, and how work zones restrict equipment access. The configuration of each location - its type, storage mode, capacity, and logics - determines which processes can use it and how the system manages stock within it.
|
||||
|
||||
Locations are created and configured by implementers using the EasyS or Easy Assistant configuration tools. End users cannot create or delete physical locations; they can only manage stock within them and perform administrative operations such as locking, relabeling, or changing work zones.
|
||||
|
||||
@@ -80,10 +80,10 @@ In conventional rack and APS locations, if a container physically cannot be depo
|
||||
|
||||
When two sub-warehouses cannot share equipment (e.g., only high-reach forklift accesses a mezzanine, but it is barred from the ground-floor picking area), an **intermediate Buffer location** lets two different equipment types hand stock off to each other.
|
||||
|
||||
**Pattern** — `Sub-warehouse B reserve → Transit buffer → Sub-warehouse A picking`:
|
||||
**Pattern** - `Sub-warehouse B reserve → Transit buffer → Sub-warehouse A picking`:
|
||||
|
||||
- EasyS element of type **"Transport"** with aisles configured.
|
||||
- Its sub-location (double-click the transport element) is the actual buffer location. **EasyS creates it as type `Automatic` — it must be changed manually to type `Buffer`**, otherwise the RFT rejects the container scan with "le support n'existe pas".
|
||||
- Its sub-location (double-click the transport element) is the actual buffer location. **EasyS creates it as type `Automatic` - it must be changed manually to type `Buffer`**, otherwise the RFT rejects the container scan with "le support n'existe pas".
|
||||
- The transport sub-warehouse must be reachable by both equipment groups.
|
||||
|
||||
**Routing**:
|
||||
@@ -95,14 +95,14 @@ When two sub-warehouses cannot share equipment (e.g., only high-reach forklift a
|
||||
| Equipment group PICKING | Both sub-warehouses |
|
||||
| Equipment group RESERVE | Sub-warehouse B only |
|
||||
|
||||
Routes default to transport type `Galileo` — manually flip them to `RF` for a manual warehouse.
|
||||
Routes default to transport type `Galileo` - manually flip them to `RF` for a manual warehouse.
|
||||
|
||||
**Flow at runtime**:
|
||||
1. Replenishment task created from reserve (B) to picking location (A).
|
||||
2. RESERVE equipment (e.g., `CACES06`) takes the task → drops container on the transit Buffer.
|
||||
3. PICKING equipment (e.g., `PIK01`) picks the task in **Tâches → Tâches de réapprovisionnement** → drops stock at the picking destination.
|
||||
|
||||
See [concepts/replenishment.md](replenishment.md#inter-sub-warehouse-replenishment-via-intermediate-buffer) for the matching replenishment flow.
|
||||
See [concepts/replenishment.md](replenishment.md#inter-sub-warehouse-replenishment-via-an-intermediate-buffer) for the matching replenishment flow.
|
||||
|
||||
## Location coding
|
||||
|
||||
@@ -164,7 +164,7 @@ Key attributes visible in the "Locations" view:
|
||||
| Sub-warehouse | Sub-warehouse this location belongs to |
|
||||
| Coordinates | Aisle, side, X, Y, depth, stackability |
|
||||
| Maximum weight | kg capacity |
|
||||
| Height | m — used for container height compatibility checks |
|
||||
| Height | m - used for container height compatibility checks |
|
||||
| Last count date | When this location was last physically counted |
|
||||
| Full (manually marked) | Location excluded from putaway search; cleared when stock is added manually |
|
||||
| Crossdocking location | Flag for crossdocking eligibility |
|
||||
@@ -252,12 +252,12 @@ From the "Locations" view, users can modify (PC only):
|
||||
|
||||
## Related
|
||||
|
||||
- [[container]] — stored in locations; location type determines container compatibility and position tracking
|
||||
- [[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
|
||||
- [[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
|
||||
|
||||
@@ -20,13 +20,13 @@ last_compiled: "2026-04-10"
|
||||
- Stock or a container was physically moved without informing EasyWMS first, or
|
||||
- Stock or a container appeared in a location different from the one recorded in the system
|
||||
|
||||
This is a corrective, out-of-band mechanism — it does not create picking or replenishment tasks, but directly updates the stock/container records in the system to match physical reality.
|
||||
This is a corrective, out-of-band mechanism - it does not create picking or replenishment tasks, but directly updates the stock/container records in the system to match physical reality.
|
||||
|
||||
Manual movements are available from **both manual and automatic warehouses** (at a picking conveyor for automatic).
|
||||
|
||||
All manual movements generate `STK.MOVE` transactions (and `CON.MOVE` for container moves).
|
||||
|
||||
> **Important:** Manual movements do **not** create guided tasks — they directly apply the relocation. For planned container movements, use task-based processes (putaway, replenishment, etc.).
|
||||
> **Important:** Manual movements do **not** create guided tasks - they directly apply the relocation. For planned container movements, use task-based processes (putaway, replenishment, etc.).
|
||||
|
||||
---
|
||||
|
||||
@@ -72,7 +72,7 @@ All manual movements generate `STK.MOVE` transactions (and `CON.MOVE` for contai
|
||||
|
||||
**Valid in both manual and automatic warehouses.** At a picking conveyor, valid as long as neither source nor destination container/stock has active replenishment, picking, or counting tasks.
|
||||
|
||||
**Special case — virtual Movement location:** Stock can be moved between containers even when one container is at a PK station and in the "Movement" virtual location (i.e., in transit).
|
||||
**Special case - virtual Movement location:** Stock can be moved between containers even when one container is at a PK station and in the "Movement" virtual location (i.e., in transit).
|
||||
|
||||
**Movement of client stock** is allowed when there is a matching shipping order.
|
||||
|
||||
@@ -156,7 +156,7 @@ Cutting stock (non-consolidating UoM) has special behavior due to its indivisibl
|
||||
4. The label "Maximum quantity" shows the longest stretch at the location
|
||||
5. Operator can use "List Stock" action to see and select all stretches; "All" action loads all stretches
|
||||
|
||||
**Key rule:** Cutting stock can only be moved **entire stretch by entire stretch** — no partial moves.
|
||||
**Key rule:** Cutting stock can only be moved **entire stretch by entire stretch** - no partial moves.
|
||||
|
||||
**Interface:**
|
||||
- RFT: `Utilities > Manual Move`
|
||||
@@ -168,7 +168,7 @@ Cutting stock (non-consolidating UoM) has special behavior due to its indivisibl
|
||||
**When:** Loose stock in one or more partitions of a picking location was recorded in a different partition.
|
||||
|
||||
**Restrictions:**
|
||||
- Cannot know the total quantity in a partition — if a partition becomes empty, the operator must explicitly mark it
|
||||
- Cannot know the total quantity in a partition - if a partition becomes empty, the operator must explicitly mark it
|
||||
- Cannot move a partition itself, only the stock within it
|
||||
- Cannot change to a partition in another warehouse
|
||||
|
||||
@@ -190,11 +190,11 @@ Cutting stock (non-consolidating UoM) has special behavior due to its indivisibl
|
||||
|
||||
## Business Rules
|
||||
|
||||
- Manual movements do **not** generate guided tasks — they directly update records.
|
||||
- Manual movements do **not** generate guided tasks - they directly update records.
|
||||
- All moves are **within the same warehouse**. Cross-warehouse moves are not supported.
|
||||
- ASN containers (pre-notified, not yet received) **cannot be moved** by manual movement.
|
||||
- Client stock (assigned to a shipping order) can only move to another client container with a matching shipping order.
|
||||
- Locks blocking movement prompt operator confirmation — the move **can still proceed** at the operator's discretion.
|
||||
- Locks blocking movement prompt operator confirmation - the move **can still proceed** at the operator's discretion.
|
||||
- For cutting stock with multiple stretches of non-consolidating UoM, **only one stretch can be moved at a time**.
|
||||
- Moving a container with replenishment assignments cancels those assignments and triggers task decrement/cancellation on affected picking tasks.
|
||||
|
||||
@@ -224,8 +224,8 @@ Cutting stock (non-consolidating UoM) has special behavior due to its indivisibl
|
||||
|
||||
## Related
|
||||
|
||||
- [[container]] — Container moves update CON.MOVE; moving a container with replenishment assignments cascades to task cancellation
|
||||
- [[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
|
||||
- [[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
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: "Mechanical Elements — Acronyms, Conveyors, Station Codes"
|
||||
title: "Mechanical Elements - Acronyms, Conveyors, Station Codes"
|
||||
type: concept
|
||||
sources:
|
||||
- sources/archives/Acronymes_elements_mecaniques.md
|
||||
@@ -18,7 +18,7 @@ related:
|
||||
last_compiled: "2026-04-17"
|
||||
---
|
||||
|
||||
# Mechanical Elements — Acronyms, Conveyors, Station Codes
|
||||
# Mechanical Elements - Acronyms, Conveyors, Station Codes
|
||||
|
||||
## Overview
|
||||
|
||||
@@ -37,12 +37,12 @@ All Mecalux mechanical acronyms are in Spanish; the translation matters because
|
||||
| **APS200** | Pallet Shuttle Automático (supercondensadores) | Automatic Pallet Shuttle (SUPERCAP) |
|
||||
| **ATC** | Abatible Transportador de Cadenas | Lift-up gate Chain Conveyor |
|
||||
| **CT** | Carro Transferidor | Transfer Car |
|
||||
| **2ECDF** | — | Double Telescopic Fork with Combined Belts |
|
||||
| **ECDF** | — | Telescopic Fork (belt, double) |
|
||||
| **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) |
|
||||
| **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 |
|
||||
@@ -77,18 +77,18 @@ Conveyor type drives whether EasyWMS can reliably track a container on the conve
|
||||
| Type | Capacity | WMS tracking |
|
||||
|------|----------|--------------|
|
||||
| **LRA** (Buffering roller) | 1 container | Tracking moves LRA → LRA on each hop; container can be **stopped** on an LRA |
|
||||
| **LRC** (Continuous roller) | multiple containers | Containers advance until the end sensor trips — **tracking is generally lost** on LRC |
|
||||
| **LRC** (Continuous roller) | multiple containers | Containers advance until the end sensor trips - **tracking is generally lost** on LRC |
|
||||
| **LRAB** (Scale roller) | 1 container | Acts like LRA, with an integrated scale (weight verification) |
|
||||
| **LTM** (Cross transfer) | 1 container | 90° change of direction; on multidirectional tables set `routing options = 1` for each feeder conveyor |
|
||||
| **LRD** (Diverting outlet) | — | Oblique outlet — splits flow off a main line |
|
||||
| **LRI** (Angle induction) | — | Oblique inlet — merges flow onto a main line |
|
||||
| **LRD** (Diverting outlet) | - | Oblique outlet - splits flow off a main line |
|
||||
| **LRI** (Angle induction) | - | Oblique inlet - merges flow onto a main line |
|
||||
| **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 |
|
||||
| **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
|
||||
## 3. Station codes - FR / ES / EN matrix
|
||||
|
||||
Station codes are shared by EasyWMS and GALILEO. Each station is uniquely identified by the couple **(Type, Number)**. Keep this table as the source of truth when cross-referencing documentation between regions.
|
||||
|
||||
@@ -125,20 +125,20 @@ Machine code reading rules for miniloads:
|
||||
|
||||
- **ML** = Miniload
|
||||
- **B** (after ML) = **Bicolumn** (absence of B = single column) → e.g. `ML-100` (single), `MLB-100Q` (bi)
|
||||
- **EPSF** = Extracteur Pelle Simple Fond — **1 charge** per extraction cycle (pelle = shovel, single depth)
|
||||
- **EPDF** = Extracteur Pelle Double Fond — **1 charge**, double-depth rack
|
||||
- **ECDF** = Extracteur Courroie Double Fond — **2 charges** per extraction cycle (courroie = belt, double depth)
|
||||
- **EPSF** = Extracteur Pelle Simple Fond - **1 charge** per extraction cycle (pelle = shovel, single depth)
|
||||
- **EPDF** = Extracteur Pelle Double Fond - **1 charge**, double-depth rack
|
||||
- **ECDF** = Extracteur Courroie Double Fond - **2 charges** per extraction cycle (courroie = belt, double depth)
|
||||
|
||||
**Rule of thumb:**
|
||||
- "Pelle" (shovel) extractors handle **one charge** at a time
|
||||
- "Courroie" (belt) extractors can handle **two charges** at a time — they drive the logic for channel filling and double-depth putaway
|
||||
- "Courroie" (belt) extractors can handle **two charges** at a time - they drive the logic for channel filling and double-depth putaway
|
||||
|
||||
The miniload model (from the installation layout) dictates the entry/outbound table configuration in EasyS (see [Galileo Simulation](../operations/galileo-simulation.md)).
|
||||
|
||||
## Related
|
||||
|
||||
- [Stations & Routes](stations.md) — full WMS station catalogue
|
||||
- [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`
|
||||
- [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)
|
||||
|
||||
@@ -36,7 +36,7 @@ last_compiled: "2026-04-10"
|
||||
|
||||
A **receipt order** (also called inbound order) is the WMS document that tracks expected incoming stock. It represents a list of items or containers expected to arrive at the warehouse, serving as the basis for the reception process. Receipt orders allow the warehouse to plan dock resources, validate quantities, and close the loop with the ERP upon receipt.
|
||||
|
||||
Most receipt orders originate in the ERP (purchase orders to suppliers, customer return orders, transfer orders from other warehouses) and arrive via messaging. Easy WMS also allows manual creation of receipt orders directly in the UI. Receipt orders are optional — stock can be received without one (blind reception) — but they enable quantity control, automatic label printing, and ERP reconciliation.
|
||||
Most receipt orders originate in the ERP (purchase orders to suppliers, customer return orders, transfer orders from other warehouses) and arrive via messaging. Easy WMS also allows manual creation of receipt orders directly in the UI. Receipt orders are optional - stock can be received without one (blind reception) - but they enable quantity control, automatic label printing, and ERP reconciliation.
|
||||
|
||||
The receipt order is distinct from the **receipt** (the actual WMS event of receiving stock physically). One receipt order can be fulfilled by one or more receipts; one receipt can be associated with one or more receipt orders.
|
||||
|
||||
@@ -47,7 +47,7 @@ Receipt orders (and their associated receipts) are categorized by type, which co
|
||||
| Type | Description | Typical origin |
|
||||
|---|---|---|
|
||||
| **Supplier** | Stock arriving from a vendor. Lines specify items, expected quantities, and UoM. Stock may arrive in any presentation (pack, box, etc.) regardless of the line's UoM. Logistic attributes and quality status can optionally be pre-set by the ERP. | ERP purchase order (PO) |
|
||||
| **Return** | Customer returns — damaged or surplus stock. Similar line structure to Supplier type. | ERP return authorization |
|
||||
| **Return** | Customer returns - damaged or surplus stock. Similar line structure to Supplier type. | ERP return authorization |
|
||||
| **Transfer** | Stock transferred from another warehouse in the same organization. Stock always arrives in containers, which are pre-notified as ASN containers at the destination. Lines specify containers, items, and quantities. | ERP transfer order; automatic when source shipping order closes (Transfer type) |
|
||||
|
||||
Receipt orders also have a **class** for additional personalization of the reception process (custom flow variants, label types, etc.). Classes do not change the type logic but allow further differentiation.
|
||||
@@ -81,7 +81,7 @@ Each line identifies the expected item/container and quantity:
|
||||
| **Line number** | Unique line identifier within the order |
|
||||
| **Status** | Line status (mirrors order status progression) |
|
||||
| **Container** | Expected or received container code (Transfer type or ASN) |
|
||||
| **Item** | Item code expected; alternatively, a presentation alias (GTIN/EAN) can be used — in this case, only stock of that EAN presentation is received against this line |
|
||||
| **Item** | Item code expected; alternatively, a presentation alias (GTIN/EAN) can be used - in this case, only stock of that EAN presentation is received against this line |
|
||||
| **Owner** | Owner of the expected stock |
|
||||
| **Quantity** | Expected quantity |
|
||||
| **UoM** | Unit of measure (usually base UoM; can be a presentation if packaging is known) |
|
||||
@@ -130,7 +130,7 @@ Each line identifies the expected item/container and quantity:
|
||||
|
||||
### Messages: ERP → WMS
|
||||
|
||||
#### ROR — Receipt Order Request
|
||||
#### ROR - Receipt Order Request
|
||||
|
||||
Creates, modifies, or cancels receipt orders.
|
||||
|
||||
@@ -155,7 +155,7 @@ Key ROR fields:
|
||||
- Line `LneStockStatus`: forced receiving status for stock on this line
|
||||
- Line reserves (`LneStkRsvSORCode` / `LneStkRsvAccCode`): pre-allocate received stock to a specific outbound order or account
|
||||
|
||||
#### ASN — Advanced Shipping Notice
|
||||
#### ASN - Advanced Shipping Notice
|
||||
|
||||
Pre-notifies containers expected at the warehouse. Containers are created in the virtual ASN location.
|
||||
|
||||
@@ -176,11 +176,11 @@ ASN key fields: `ContainerCode`, `ContainerType`, `ReceiptOrderCode`, `NumExpect
|
||||
|
||||
### Messages: WMS → ERP
|
||||
|
||||
#### ROC — Receipt Order status Change
|
||||
#### ROC - Receipt Order status Change
|
||||
|
||||
Sent by WMS when an order changes status. Fields: `RorCode`, `Status` (Waiting / ReceptionPending / Receiving / PartiallyReceived / Complete / Expired / Canceled), `UpdateDate` (UTC timestamp).
|
||||
|
||||
#### ROF — Receipt Order Finalization
|
||||
#### ROF - Receipt Order Finalization
|
||||
|
||||
Sent when an order is closed or canceled. Two versions:
|
||||
- **ROF01**: includes receipt data + order data + stock received. Sent on order close/cancel AND on receipt close (even if receipt has no order).
|
||||
@@ -188,11 +188,11 @@ Sent when an order is closed or canceled. Two versions:
|
||||
|
||||
ROF01/ROF02 key fields per line: `LneItemCode`, `LneOwnerCode`, `LneQtyExpected`, `LneQtyReceived`, `LneQtyFree`, `LneQtyUoMCode`.
|
||||
|
||||
#### ASO — ASN receipt confirmation (WMS → ERP)
|
||||
#### ASO - ASN receipt confirmation (WMS → ERP)
|
||||
|
||||
Sent when an ASN pre-notified container is physically received. Confirms item, owner, quantity, and optionally the receiving status (`LneStaStatus`). Variants mirror ASN variants (stacked, matched on dummy, with divisions).
|
||||
|
||||
#### STR — Stock lock/unlock request (ERP → WMS)
|
||||
#### STR - Stock lock/unlock request (ERP → WMS)
|
||||
|
||||
Although STR is a request (not a receipt order message), it is closely related to inbound quality control. The ERP requests Easy WMS to apply or remove a user status on stock (e.g., lock a lot for quality reasons):
|
||||
- `Operation S`: add user status (lock) with optional quarantine end date
|
||||
@@ -241,11 +241,11 @@ WMS responds with one or more **STC** messages confirming the modified stock.
|
||||
|
||||
## Related
|
||||
|
||||
- [[reception]] — the physical reception process that fulfills receipt orders; dock/PIE/ASN reception modes all reference receipt orders
|
||||
- [[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
|
||||
- [[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
|
||||
|
||||
@@ -44,7 +44,7 @@ last_compiled: "2026-04-17"
|
||||
|
||||
A **shipping order** (outbound order) is the WMS document that drives the outbound fulfillment process. It is a list of items or containers that need to be shipped from the warehouse. Shipping orders represent customer sales orders, returns to suppliers, inter-warehouse transfers, and internal sub-warehouse replenishments.
|
||||
|
||||
Shipping orders are the primary driver of picking, consolidation, and truck loading operations. They arrive from the ERP via SOR messages in the vast majority of cases. Manual creation is possible for special cases (ERP unavailable, one-off requests). Every outbound activity in the WMS — from stock assignment to task generation to carrier document printing — traces back to a shipping order.
|
||||
Shipping orders are the primary driver of picking, consolidation, and truck loading operations. They arrive from the ERP via SOR messages in the vast majority of cases. Manual creation is possible for special cases (ERP unavailable, one-off requests). Every outbound activity in the WMS - from stock assignment to task generation to carrier document printing - traces back to a shipping order.
|
||||
|
||||
A shipping order consists of a **header** (common attributes) and **lines** (specific items/containers with quantities). The lifecycle spans from creation through preparation, consolidation, and final closure with ERP notification.
|
||||
|
||||
@@ -56,8 +56,8 @@ The type determines the destination, the process, and how Easy WMS handles the s
|
||||
|---|---|---|
|
||||
| **Client** | Ship stock to a customer (sales order) | External; carrier delivery |
|
||||
| **Return** | Return stock to a supplier | External; supplier |
|
||||
| **Transfer** | Transfer to another warehouse in the organization. When closed, creates an inbound order at destination + ASN containers (same stacked structure as loaded). See [Transfer flow](#transfer--two-warehouse-flow-inbound-order-created). | Another warehouse |
|
||||
| **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) |
|
||||
| **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 |
|
||||
@@ -135,7 +135,7 @@ Shipping orders also have a **class** for additional process customization (diff
|
||||
[Force close with stock failures] → CLOSED (partial)
|
||||
↓
|
||||
ARCHIVED
|
||||
|
||||
|
||||
[Any time before CLOSED]
|
||||
→ CANCELED (no stock shipped)
|
||||
```
|
||||
@@ -160,7 +160,7 @@ Shipping orders also have a **class** for additional process customization (diff
|
||||
- Orders **cannot mix lines** from different owners when the Owner Extension module is installed.
|
||||
- **Priority** affects task sequencing across all active orders: urgent orders get their picking tasks executed first, at the cost of more picking rounds.
|
||||
- **Critical lines** (`LneTrmCritical`): if the line cannot be fully assigned, no stock is prepared for that line (the rest of the order is unaffected).
|
||||
- **Required lines to ship** (`LneTrmRequired`): if the required line cannot be fully shipped, the entire order blocks — nothing is prepared.
|
||||
- **Required lines to ship** (`LneTrmRequired`): if the required line cannot be fully shipped, the entire order blocks - nothing is prepared.
|
||||
- **Stock assignment** respects the configured stock assignment strategy (logic to minimize movements, maximize container use, minimize lots, etc.).
|
||||
- **Excess shipping** (`LneQtyAllowExcess`): if exact quantity is impossible due to containerized stock, the system may over-allocate and then returns surplus.
|
||||
- **Substitute items**: used when the ordered item is short. The substitution mode (partial/all-or-nothing) is defined in the item's shipping profile; explicit alternatives in the SOR override the profile.
|
||||
@@ -173,11 +173,11 @@ Shipping orders also have a **class** for additional process customization (diff
|
||||
|
||||
### Messages: ERP → WMS
|
||||
|
||||
#### SOR — Shipping Order Request
|
||||
#### SOR - Shipping Order Request
|
||||
|
||||
Creates, modifies, or cancels shipping orders. Two versions:
|
||||
- **SOR01**: standard shipping orders
|
||||
- **SOR02**: prepackaging — ERP specifies number/type of packages, stock per package, working mode (strict/non-strict). Also used with VAS (Value Added Services) module.
|
||||
- **SOR02**: prepackaging - ERP specifies number/type of packages, stock per package, working mode (strict/non-strict). Also used with VAS (Value Added Services) module.
|
||||
|
||||
| Operation | Fields |
|
||||
|---|---|
|
||||
@@ -185,7 +185,7 @@ Creates, modifies, or cancels shipping orders. Two versions:
|
||||
| `U` (update) | Modify header (priority, etc.) or individual lines |
|
||||
| `D` (cancel) | Cancel the entire order |
|
||||
| Line `C` | Create new line with `LneItemCode`, `LneContCode`, `LneQtyOrder`, `LneQtyUoMCode`, `LneAttributes` |
|
||||
| Line `U` | Modify line (qty, UoM, attributes — restrictions apply if stock already prepared/shipped) |
|
||||
| Line `U` | Modify line (qty, UoM, attributes - restrictions apply if stock already prepared/shipped) |
|
||||
| Line `D` | Cancel specific line |
|
||||
|
||||
Key SOR fields:
|
||||
@@ -208,7 +208,7 @@ Key SOR fields:
|
||||
|
||||
### Messages: WMS → ERP
|
||||
|
||||
#### SOC — Shipping Order status Change
|
||||
#### SOC - Shipping Order status Change
|
||||
|
||||
Sent on every status transition of a shipping order.
|
||||
|
||||
@@ -224,13 +224,13 @@ Sent on every status transition of a shipping order.
|
||||
|
||||
Note: Grouped/fused orders do not report status changes for the grouped order or its components during grouped preparation.
|
||||
|
||||
#### SOF — Shipping Order Finalization
|
||||
#### SOF - Shipping Order Finalization
|
||||
|
||||
Sent when an order is closed or canceled.
|
||||
|
||||
Two versions:
|
||||
- **SOF01**: full data — includes MultiCarrier delivery info, VAS details, all lines. Sent at every partial close (with close number) and at final close/cancel.
|
||||
- **SOF02**: modular — excludes MultiCarrier and VAS data. Created when communications became modular so each application manages its own messages.
|
||||
- **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)
|
||||
@@ -241,7 +241,7 @@ Key fields:
|
||||
|
||||
If order is forced to close without shipping any stock, no line data is sent. If canceled, no line data is sent.
|
||||
|
||||
#### LOF — Load Finalization
|
||||
#### LOF - Load Finalization
|
||||
|
||||
Sent when a load is finalized (truck loading complete). References shipping orders in the load.
|
||||
|
||||
@@ -288,13 +288,13 @@ Sent when a load is finalized (truck loading complete). References shipping orde
|
||||
| Print documentation | Delivery note, packing list, differences report |
|
||||
| Archive | After closure |
|
||||
|
||||
## ASN — DirectTransfer flow
|
||||
## ASN - DirectTransfer flow
|
||||
|
||||
A `<DirectTransfer>` order (`<SorType>` in `SOR02`) requires **at least two warehouses** in the WMS. It ships stock from a source warehouse to a destination warehouse **without generating any inbound order or receipt at destination** — only ASN containers.
|
||||
A `<DirectTransfer>` order (`<SorType>` in `SOR02`) requires **at least two warehouses** in the WMS. It ships stock from a source warehouse to a destination warehouse **without generating any inbound order or receipt at destination** - only ASN containers.
|
||||
|
||||
**Preparation** — identical to a standard client order. After the outbound order closes on the source warehouse, the shipped containers automatically appear on the destination warehouse's **`Asn`** location (visible in SmartUI via `Entrepôt → Conteneurs ASN`).
|
||||
**Preparation** - identical to a standard client order. After the outbound order closes on the source warehouse, the shipped containers automatically appear on the destination warehouse's **`Asn`** location (visible in SmartUI via `Entrepôt → Conteneurs ASN`).
|
||||
|
||||
**Receiving an ASN container (destination warehouse)** — RFT menu `Réception → Préavis` of the destination warehouse :
|
||||
**Receiving an ASN container (destination warehouse)** - RFT menu `Réception → Préavis` of the destination warehouse :
|
||||
|
||||
1. Receive onto the buffer or the equipment.
|
||||
2. Scan the container (no other validation required).
|
||||
@@ -302,11 +302,11 @@ A `<DirectTransfer>` order (`<SorType>` in `SOR02`) requires **at least two ware
|
||||
|
||||
> By design, the direct transfer **skips re-inspection** of the merchandise at the destination.
|
||||
|
||||
**Deleting / rejecting an ASN container** (container not arrived or not conforming) — SmartUI `Entrepôt → Conteneurs ASN` → select the container → **Supprimer**. This generates an **ASK01** file.
|
||||
**Deleting / rejecting an ASN container** (container not arrived or not conforming) - SmartUI `Entrepôt → Conteneurs ASN` → select the container → **Supprimer**. This generates an **ASK01** file.
|
||||
|
||||
> ⚠️ Both `ASO01` and `ASK01` files **carry no reference to the origin transfer order**. The ERP itself must reconcile every ASO/ASK container against the originating `DirectTransfer` shipping order to confirm or invalidate the completeness of the transfer.
|
||||
|
||||
## Transfer — two-warehouse flow (inbound order created)
|
||||
## Transfer - two-warehouse flow (inbound order created)
|
||||
|
||||
A `<Transfer>`-type order (`<SorType>` in `SOR02`) also requires **at least two warehouses** in the WMS. Unlike `<DirectTransfer>`, closing the outbound at source **automatically creates an inbound order at destination** with the same code as the source order. Containers arrive on the `Asn` location of the destination warehouse.
|
||||
|
||||
@@ -324,24 +324,24 @@ Destination-warehouse settings:
|
||||
- `AutoCreateReceptionFromRecorder = true` → reception auto-created on first container scan.
|
||||
- `AutoCloseInboundOrder = true` → closing the reception auto-closes the inbound order and emits `ROF02`.
|
||||
|
||||
> ⚠️ `ASO01` and `ASK01` still carry **no transfer-header info**. For `<Transfer>` flows the ERP **must** consume `ROF02` — which contains the full list of received containers.
|
||||
> ⚠️ `ASO01` and `ASK01` still carry **no transfer-header info**. For `<Transfer>` flows the ERP **must** consume `ROF02` - which contains the full list of received containers.
|
||||
|
||||
See [Reception](reception.md#transfer--two-warehouse-asn-flow-with-receipt) for the receiving procedure.
|
||||
See [Reception](reception.md#transfer---two-warehouse-asn-flow-with-receipt) for the receiving procedure.
|
||||
|
||||
## Merge (order fusion)
|
||||
|
||||
Merging consolidates multiple **outbound orders** into one preparation, so picking/packing/loading happens in a single pass. Merge applies to outbound orders — **not** to deliveries (a delivery is the *result* of a merge, not an input).
|
||||
Merging consolidates multiple **outbound orders** into one preparation, so picking/packing/loading happens in a single pass. Merge applies to outbound orders - **not** to deliveries (a delivery is the *result* of a merge, not an input).
|
||||
|
||||
### Eligibility
|
||||
|
||||
**Required** — every candidate order must match on:
|
||||
**Required** - every candidate order must match on:
|
||||
- Complete `<ShippingAddress>` (every sub-tag)
|
||||
- Complete `<DeliveryAddress>` + `<DeliveryContact>`
|
||||
- Same order type (Client, Transfer, …)
|
||||
- Status `Waiting`
|
||||
- Identical `ExtraData`
|
||||
|
||||
**Disqualifying** — an order cannot be merged if it is already:
|
||||
**Disqualifying** - an order cannot be merged if it is already:
|
||||
- In another merge
|
||||
- In a group
|
||||
- In a wave
|
||||
@@ -367,7 +367,7 @@ The merged order owns its own code, status and shipping date and is treated as a
|
||||
</Delivery>
|
||||
```
|
||||
|
||||
Parameter: **`ALLOW_MERGE_DIFFERENT_ACCOUNT`** — if set, allows merging orders from different customer accounts.
|
||||
Parameter: **`ALLOW_MERGE_DIFFERENT_ACCOUNT`** - if set, allows merging orders from different customer accounts.
|
||||
|
||||
> ⚠️ **No automatic merge is shipped in standard.** Default is manual. Any automation is a custom scope.
|
||||
|
||||
@@ -415,12 +415,12 @@ The WMS uses the shipping-profile **substitution mode** (Partiel / Substitution
|
||||
|
||||
## Related
|
||||
|
||||
- [[shipping]] — the physical shipping process (consolidation, truck loading, PS groups, auto shipping) that fulfills outbound orders
|
||||
- [[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)
|
||||
- [[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)
|
||||
|
||||
@@ -28,7 +28,7 @@ last_compiled: "2026-04-10"
|
||||
|
||||
## Overview
|
||||
|
||||
Parameters control system behavior at the warehouse level. They allow the same Easy WMS software to behave differently across warehouses of the same organization without code changes. Every process — reception, picking, counting, replenishment — has parameters that tune its behavior.
|
||||
Parameters control system behavior at the warehouse level. They allow the same Easy WMS software to behave differently across warehouses of the same organization without code changes. Every process - reception, picking, counting, replenishment - has parameters that tune its behavior.
|
||||
|
||||
Parameters are defined at the **organization level** but can be **customized per warehouse**. A warehouse-level value overrides the organization default.
|
||||
|
||||
@@ -301,11 +301,11 @@ Parameters mentioned in other wiki pages:
|
||||
|
||||
## Related
|
||||
|
||||
- [[reception]] — ALLOW_CREATE_RECEPTION, RECEPTION_ASN_*, AutoCloseReception, label printing params
|
||||
- [[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
|
||||
- [[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
|
||||
|
||||
+43
-43
@@ -117,7 +117,7 @@ The ordering logic lives in the code activity **"Order stock when none location
|
||||
|
||||
When a line allows excess shipping, EasyWMS first tries to assign the exact quantity. If all strategies are exhausted without fulfilling the line completely, the first stock discarded by the last strategy is assigned as excess. Excess is minimized by unassigning the last-assigned stock. The "strict shipping logic on excess" flag prevents excess assignment from using better-logic stock over what was already being shipped.
|
||||
|
||||
## Picking Modes — Manual Warehouse
|
||||
## Picking Modes - Manual Warehouse
|
||||
|
||||
Manual warehouse picking is RFT-driven, following the **picking path** (optimal route minimizing operator travel). The path starts at the picking start point and ends at the shipping area.
|
||||
|
||||
@@ -135,7 +135,7 @@ Manual warehouse picking is RFT-driven, following the **picking path** (optimal
|
||||
| **Voice picking** | Operator receives spoken instructions, confirms by voice; both hands free for handling | RFT + headset |
|
||||
| **Advanced picking** | Picks client containers before dock/stage assigned; containers placed on shelf until assignment | RFT |
|
||||
|
||||
**Cutting stock picking** (rope, cable, chain — indivisible lengths):
|
||||
**Cutting stock picking** (rope, cable, chain - indivisible lengths):
|
||||
- Requires a physical cut before picking
|
||||
- Two models: **integrated cut** (cut performed at the location) or **delegated cut** (cut performed at a dedicated cutting station)
|
||||
- Cutting stations can have dedicated equipment and procedures for item-specific cutting complexity
|
||||
@@ -155,27 +155,27 @@ Manual warehouse picking is RFT-driven, following the **picking path** (optimal
|
||||
**Flow (RFT):**
|
||||
1. Enter the **outbound code** (a default is proposed)
|
||||
2. Choose the **shipping dock**
|
||||
3. Add lines — **item + quantity** — repeat per line
|
||||
4. **Release** the order — creates the outbound, its lines, and the picking tasks in SmartUI (can take time for large orders)
|
||||
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.
|
||||
- **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)).
|
||||
Entry workflow: `EasyWMS.ManualPicking_ByItem_UI` (cf. [RF Menu reference](../architecture/rf-menu.md#4-shipping-orders---sharedmenu_shippingorders)).
|
||||
|
||||
### Location Carts (chariots à emplacement) for Multi-Order Picking
|
||||
|
||||
Location carts let one operator prepare **several orders at once without creating one client container per order**. The WMS maps cart divisions (column × row) to orders automatically.
|
||||
|
||||
- **Usable only in multi-order picking modes** — groups of orders and waves
|
||||
- **Usable only in multi-order picking modes** - groups of orders and waves
|
||||
- Removes the need for a secondary *"TRF à emplacement"* configuration in many layouts
|
||||
- After picking, the cart is dropped directly onto the packing station
|
||||
|
||||
**Setup — SmartUI:**
|
||||
**Setup - SmartUI:**
|
||||
|
||||
1. **Create division types** — define the number and codes of cart slots (tested up to 20×20). The WMS temporarily labels slots `Section{sequence}`; the name entered guides the operator during picking.
|
||||
1. **Create division types** - define the number and codes of cart slots (tested up to 20×20). The WMS temporarily labels slots `Section{sequence}`; the name entered guides the operator during picking.
|
||||
2. **Create the cart** (tab **"Carts"**):
|
||||
|
||||
| Field | Description |
|
||||
@@ -184,14 +184,14 @@ Location carts let one operator prepare **several orders at once without creatin
|
||||
| Storage location | **Mandatory** |
|
||||
| Division type | If empty → the cart behaves as one slot |
|
||||
|
||||
Cart statuses : **Open** (available), **Closed** (stock in progress — not yet packed).
|
||||
Cart statuses : **Open** (available), **Closed** (stock in progress - not yet packed).
|
||||
|
||||
**Picking with a cart (RFT):**
|
||||
- At wave/group start, the RFT proposes to use a cart — scan its code.
|
||||
- At wave/group start, the RFT proposes to use a cart - scan its code.
|
||||
- On the first drop, the WMS asks which slot (division) to use; subsequent tasks for the same order are auto-routed to the same slot.
|
||||
- Column **"Division"** shows `CartCode_SectionCode`.
|
||||
|
||||
**Edge case — closed cart with no free slot:** the RFT reports no task available and flips the cart back to **Open**. To unload: **"Fermer"** on the task list → RFT menu **Rangement → Stock de chariots** → either "Ranger le chariot entièrement" (no redirection to packing) or "Décharger en mode stock libre".
|
||||
**Edge case - closed cart with no free slot:** the RFT reports no task available and flips the cart back to **Open**. To unload: **"Fermer"** on the task list → RFT menu **Rangement → Stock de chariots** → either "Ranger le chariot entièrement" (no redirection to packing) or "Décharger en mode stock libre".
|
||||
|
||||
**Packing:** scan the cart code → WMS indicates divisions → scan the division to pack (or list divisions with stock). Standard packing runs with `CartCode_SectionCode` as origin.
|
||||
|
||||
@@ -211,7 +211,7 @@ Paper picking is used when RF coverage is missing, when a customer wants a print
|
||||
6. Back at the station, click **Confirmer le lot** and **scan the batch number** on the printed sheet :
|
||||
- If the order is complete → scan the batch number a second time to close the preparation.
|
||||
- Otherwise → scan the incomplete tasks one by one and enter the actual picked quantity.
|
||||
7. Scan the batch number one last time to mark the preparation done — the order transitions to **"Prepared"** and stock is transferred to the staging buffer / dock.
|
||||
7. Scan the batch number one last time to mark the preparation done - the order transitions to **"Prepared"** and stock is transferred to the staging buffer / dock.
|
||||
|
||||
### Picking Incidences (Manual Warehouse)
|
||||
|
||||
@@ -219,9 +219,9 @@ During picking, issues are recorded when containers are not where expected or ex
|
||||
- **Mark to review**: creates a lock and count on the container/location; does not interrupt the current process; lock removed when count completes
|
||||
- **Stock adjustment**: ERP is notified of any inventory corrections via messenger service
|
||||
|
||||
**Wait for replenishment**: configurable behavior — system can auto-trigger replenishment tasks when a picking location is empty to complete the pick.
|
||||
**Wait for replenishment**: configurable behavior - system can auto-trigger replenishment tasks when a picking location is empty to complete the pick.
|
||||
|
||||
By default, when an outbound order is released and no picking location has stock (but stock exists in replenishment sources), picking tasks are created on empty PDLs — these are **silently skipped at execution time** if the PDL is still empty when the operator reaches it. Three global parameters relax this default :
|
||||
By default, when an outbound order is released and no picking location has stock (but stock exists in replenishment sources), picking tasks are created on empty PDLs - these are **silently skipped at execution time** if the PDL is still empty when the operator reaches it. Three global parameters relax this default :
|
||||
|
||||
| Parameter | Effect | Key workflow(s) |
|
||||
|---|---|---|
|
||||
@@ -242,7 +242,7 @@ Operator flow for the third parameter :
|
||||
|
||||
**Excess reduction**: if multiple tasks exist for the same item and one is over-picked, the remaining tasks are reduced by the excess amount (or canceled if already satisfied).
|
||||
|
||||
## Picking — Automatic Warehouse (Picking Conveyor / PK)
|
||||
## Picking - Automatic Warehouse (Picking Conveyor / PK)
|
||||
|
||||
In automatic warehouses, picking is goods-to-person. The TMS extracts containers from storage and brings them to a **picking conveyor (PK)** station. One PK can serve multiple **preparation zones (MP)**; each MP is a physical table where the operator deposits picked stock into client containers.
|
||||
|
||||
@@ -259,14 +259,14 @@ Configuration of picking + preparation pairs (robotics-specific, from EasyS + Sm
|
||||
- **Virtual** route → consolidation zone
|
||||
- **Max concurrent orders** (SmartUI): **Menu → Control → Workstations** → select PK → set the value. Must **equal the number of preparation tables** linked to the PK
|
||||
- **MP assignment mode** (SmartUI): **Menu → Control → Workstations** → select MP(s) → **Modify assignment mode**
|
||||
- **Automatic** — WMS assigns the next order to a table
|
||||
- **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
|
||||
- **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
|
||||
3. Launch an order - assigns PK + generates `pickingContainer` tasks
|
||||
|
||||
For detailed bring-up in simulation and the "Store container" + "Liberate" test flow, see [Galileo Simulation](../operations/galileo-simulation.md).
|
||||
|
||||
@@ -322,7 +322,7 @@ After all picking tasks for a shipping order are completed at the PK:
|
||||
- Physical PK pushbutton is pressed to signal completion
|
||||
- TMS generates movement tasks to return the source container to its storage location or to a rejection station
|
||||
|
||||
## Picking — Pick and Pack Mode
|
||||
## Picking - Pick and Pack Mode
|
||||
|
||||
In Pick and Pack warehouses, operators pick stock directly into the final shipping carton (client container). Two integration levels:
|
||||
|
||||
@@ -359,7 +359,7 @@ The picking path is the optimal traversal order of locations for picking tasks.
|
||||
|
||||
The picking path starts at the **picking start point** (configured per sub-warehouse or warehouse) and ends at the shipping area. The path selects the next closest task, but overall path optimality depends on warehouse layout.
|
||||
|
||||
## Order Planning — Waves, Groups, and Shipment Templates
|
||||
## Order Planning - Waves, Groups, and Shipment Templates
|
||||
|
||||
### Order priorities
|
||||
|
||||
@@ -367,11 +367,11 @@ Each shipping order carries a priority that determines task sequence:
|
||||
|
||||
| Priority | Relative urgency |
|
||||
|----------|-----------------|
|
||||
| **Urgent** | Highest — processed first in all queues |
|
||||
| **Urgent** | Highest - processed first in all queues |
|
||||
| **High** | Above normal |
|
||||
| **Normal** | Default |
|
||||
| **Low** | Below normal |
|
||||
| **Very Low** | Lowest — processed last |
|
||||
| **Very Low** | Lowest - processed last |
|
||||
|
||||
Priorities are set per order (from the ERP or manually) and apply across all picking and shipping task generation.
|
||||
|
||||
@@ -418,7 +418,7 @@ Shipment templates automate wave and group creation by applying a set of selecti
|
||||
|
||||
### Order fusion
|
||||
|
||||
**Fusion** merges multiple shipping orders from the same client/destination into a single preparation batch. This is a **manual-only** operation — EasyWMS does not auto-fuse orders.
|
||||
**Fusion** merges multiple shipping orders from the same client/destination into a single preparation batch. This is a **manual-only** operation - EasyWMS does not auto-fuse orders.
|
||||
|
||||
Conditions for fusion:
|
||||
- Same client (account)
|
||||
@@ -458,23 +458,23 @@ After fusion, the combined order is prepared as a single batch, reducing travel
|
||||
|
||||
| Interface | Path |
|
||||
|---|---|
|
||||
| RFT — picking (manual warehouse) | Menu "Picking" → task mode selection |
|
||||
| RFT — picking 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" |
|
||||
| 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
|
||||
- [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
|
||||
|
||||
@@ -31,7 +31,7 @@ A prepackaging strategy has the following fields:
|
||||
|---|---|---|
|
||||
| **Code** | free text | Strategy name |
|
||||
| **Type de commande** | Fusion / Ordre de départ sans envoi / Vague | Which outbound grouping this strategy applies to |
|
||||
| **Processus** | Emballage / Préparation | When it is applied — at packing station or during picking |
|
||||
| **Processus** | Emballage / Préparation | When it is applied - at packing station or during picking |
|
||||
| **Type de précolisage** | Calculé par EasyWMS / Calculé par l'opérateur / Calculé par l'ERP | Who computes the container split |
|
||||
| **Mode de travail** | Strict / Pas strict | Strict = operator cannot deviate from the plan ; non-strict = operator can override |
|
||||
| **Logique de pré emballage** | Nombre minimum de colis / Volume minimum | "Fewest parcels" picks the largest container possible ; "Minimum volume" picks the smallest container possible |
|
||||
@@ -46,7 +46,7 @@ For `Calculé par EasyWMS` to work:
|
||||
|
||||
1. **Container types** must be configured in EasyS and associated to equipments.
|
||||
2. **Item dimensions and weight** must be populated (in conversions).
|
||||
3. **Mixing restrictions** between items must be defined — by item, by family, or by type.
|
||||
3. **Mixing restrictions** between items must be defined - by item, by family, or by type.
|
||||
|
||||
## Calculation by ERP (SOR02)
|
||||
|
||||
@@ -75,11 +75,11 @@ When `Calculé par l'ERP`, the outbound order message carries a `<PrepackagingCo
|
||||
```
|
||||
|
||||
Keys in this block:
|
||||
- `PrepackagingProcess` — `Picking` or `Packing`
|
||||
- `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
|
||||
- `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)
|
||||
|
||||
@@ -90,7 +90,7 @@ Confirmed working vs. known-broken combinations:
|
||||
| Ordre de départ / Strict / Nombre minimum / poids normal | 1 carton L |
|
||||
| Ordre de départ / Strict / Nombre minimum / poids > seuil | Carton L (poids reste < 20 kg) |
|
||||
| Ordre de départ / Strict / Nombre minimum / famille non mélangeable | Articles répartis dans colis différents ✅ |
|
||||
| Ordre de départ / Strict / Nombre minimum / **type** non mélangeable | ❌ **non fonctionnel** — articles mélangés malgré la restriction |
|
||||
| Ordre de départ / Strict / Nombre minimum / **type** non mélangeable | ❌ **non fonctionnel** - articles mélangés malgré la restriction |
|
||||
| Ordre de départ / Strict / Volume minimum | 3 conteneurs différents |
|
||||
| Vague / Strict / Volume minimum | Calcul réalisé par commande |
|
||||
| **Calcul par l'opérateur** | ❌ **non fonctionnel** |
|
||||
@@ -101,7 +101,7 @@ Confirmed working vs. known-broken combinations:
|
||||
|
||||
**The strategy has no effect even though it is saved** : it was not activated. Re-open the strategy and toggle activation.
|
||||
|
||||
**`Calcul par EasyWMS` produces no containers** : item dimensions/weight missing, or no container type is associated to the equipment — both are prerequisites.
|
||||
**`Calcul par EasyWMS` produces no containers** : item dimensions/weight missing, or no container type is associated to the equipment - both are prerequisites.
|
||||
|
||||
**`Type de commande = Ordre de départ sans envoi`** : applies to the simple single-order case ; for waves or fusions, pick the corresponding `Type de commande`, otherwise the strategy is ignored for those grouping types.
|
||||
|
||||
@@ -109,7 +109,7 @@ Confirmed working vs. known-broken combinations:
|
||||
|
||||
## Related
|
||||
|
||||
- [Shipping](shipping.md) — the surrounding outbound process ; prepackaging is one step of it
|
||||
- [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
|
||||
- [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
|
||||
|
||||
@@ -48,7 +48,7 @@ last_compiled: "2026-04-17"
|
||||
|
||||
## Overview
|
||||
|
||||
An **item** is the primary static master data element in Easy WMS. It represents each distinct product that an organization manages in its warehouse. Almost every WMS behavior — reception, putaway, picking, shipping, counting, replenishment — is governed by item configuration.
|
||||
An **item** is the primary static master data element in Easy WMS. It represents each distinct product that an organization manages in its warehouse. Almost every WMS behavior - reception, putaway, picking, shipping, counting, replenishment - is governed by item configuration.
|
||||
|
||||
A critical distinction: the **item** is the master definition (SKU, attributes, rules), while **stock** is the physical instance of that item (a quantity of that item in a specific location/container with specific logistic attributes). The same item code can have stock across many locations simultaneously. Multiple owners can also hold stock of the same item code.
|
||||
|
||||
@@ -72,9 +72,9 @@ Item families define mixing restrictions for **client containers** (containers b
|
||||
Use case: prevent mixing refrigerated and ambient items in the same outbound parcel.
|
||||
|
||||
When the **Multi-Carrier module** is active, item families also carry a **packaging method** that controls how the carrier call is generated:
|
||||
- `Scan all items` — operator scans each item into a parcel
|
||||
- `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)
|
||||
- `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).
|
||||
|
||||
@@ -87,7 +87,7 @@ The ABC classification indicates the rotation/activity level of an item relative
|
||||
|
||||
Used in slotting optimization and putaway strategy rules to position items strategically.
|
||||
|
||||
**Operating principles.** The higher the class's movement threshold, the more important it is (A > B > C). Articles with the most movements are classified in the highest class. **Thresholds represent cumulative movement share** — an A article = top 50%, a B = top 80% (50+30), etc.
|
||||
**Operating principles.** The higher the class's movement threshold, the more important it is (A > B > C). Articles with the most movements are classified in the highest class. **Thresholds represent cumulative movement share** - an A article = top 50%, a B = top 80% (50+30), etc.
|
||||
|
||||
When an article straddles two classes, the `Type de calcul` chosen at evaluation decides :
|
||||
|
||||
@@ -103,16 +103,16 @@ When an article straddles two classes, the `Type de calcul` chosen at evaluation
|
||||
|
||||
**First assignment.** On first setup, every article is set to the **lowest rotation class**. This should be done in the article-base import ; when a new article is later created, this field must be populated manually.
|
||||
|
||||
**ABC evaluation (runtime)** — `Tableaux de Bord → Evaluation ABC` (recent versions). Parameters :
|
||||
- **Date** — `Start-end date` or `By number of day`
|
||||
- **Mouvements** — task types to include (at least one required)
|
||||
- **Type de calcul** — `Inclusive` or `Exclusive`
|
||||
**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).
|
||||
- **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.
|
||||
@@ -121,7 +121,7 @@ The classification can be edited inline from the evaluation grid.
|
||||
|
||||
## Units of Measure (UoM)
|
||||
|
||||
Every item must have a **base UoM** — the reference unit for all conversions. All stock quantities are stored and reported in the base UoM.
|
||||
Every item must have a **base UoM** - the reference unit for all conversions. All stock quantities are stored and reported in the base UoM.
|
||||
|
||||
Additional **conversions and presentations** (EAN/GTIN presentations) define the commercial packaging:
|
||||
- Each conversion specifies the quantity of base UoM it contains (e.g., BOX12 = 12 units)
|
||||
@@ -160,13 +160,13 @@ Logistic attributes are characteristics that condition the logistic behavior of
|
||||
|
||||
### Creating a logistic attribute without a capture mode
|
||||
|
||||
By default, every logistic attribute requires a capture mode (manual, scan, etc.). In some custom flows the attribute must be **auto-generated by code** (e.g., serial number generated server-side) and therefore must exist **without** any capture mode — otherwise SmartUI / RFT will always prompt the operator.
|
||||
By default, every logistic attribute requires a capture mode (manual, scan, etc.). In some custom flows the attribute must be **auto-generated by code** (e.g., serial number generated server-side) and therefore must exist **without** any capture mode - otherwise SmartUI / RFT will always prompt the operator.
|
||||
|
||||
> ⚠️ Once configured this way, the attribute value can no longer be edited from SmartUI or RFT without a custom — the only writer is the custom code that creates the stock.
|
||||
> ⚠️ Once configured this way, the attribute value can no longer be edited from SmartUI or RFT without a custom - the only writer is the custom code that creates the stock.
|
||||
|
||||
**Procedure** (requires Admin role + Run Command access):
|
||||
|
||||
1. **Create the logistic profile** and add the attribute of the desired type. The capture mode is mandatory at creation — set it to `Manual` (it will be deleted in step 4).
|
||||
1. **Create the logistic profile** and add the attribute of the desired type. The capture mode is mandatory at creation - set it to `Manual` (it will be deleted in step 4).
|
||||
2. **Collect the identifiers** with a Run Query on the reading context:
|
||||
```csharp
|
||||
Context.LogisticAttributes.Select(la => new {
|
||||
@@ -197,7 +197,7 @@ By default, every logistic attribute requires a capture mode (manual, scan, etc.
|
||||
|
||||
## Profiles
|
||||
|
||||
Profiles define item behavior in each WMS process. They allow bulk configuration — many items can share the same profile.
|
||||
Profiles define item behavior in each WMS process. They allow bulk configuration - many items can share the same profile.
|
||||
|
||||
| Profile | Required | Purpose |
|
||||
|---|---|---|
|
||||
@@ -306,14 +306,14 @@ In `SOR01` / `SOR02`, on the relevant `<Line>` elements :
|
||||
</LneTerms>
|
||||
```
|
||||
|
||||
### 2. Shipping profile — substitution mode
|
||||
### 2. Shipping profile - substitution mode
|
||||
|
||||
Every item involved in the substitution must carry a shipping profile (`Données principales → Détails d'articles → Profils d'expédition`). The mode (X = requested item, Y = substitute) is :
|
||||
|
||||
| Mode | Behavior |
|
||||
|---|---|
|
||||
| **Partiel** | Sums X + Y to reach the requested quantity. X is prioritized. |
|
||||
| **Substitution** | Picks X **or** Y exclusively — whichever quantity is closest to the requested one. |
|
||||
| **Substitution** | Picks X **or** Y exclusively - whichever quantity is closest to the requested one. |
|
||||
| **Tout ou rien** | If X + Y cannot reach the requested quantity, picks **only X** regardless of its quantity. |
|
||||
|
||||
> ⚠️ For components of **non-assembled kits**, the mode **must be `Partiel`**.
|
||||
@@ -334,7 +334,7 @@ In `Données principales → Articles`, select the **item to be replaced**, clic
|
||||
|---|---|
|
||||
| Only X picked | `<LneDIsAlternative>false</LneDIsAlternative>` |
|
||||
| X + Y picked | Two `<LneDetail>` blocks : one with `LneDIsAlternative=false` (X), one with `LneDIsAlternative=true` (Y) |
|
||||
| Only Y picked | Single `<LneDetail>` with `LneDIsAlternative=true` — `<LneItemCode>` still contains **X** (the requested item) |
|
||||
| Only Y picked | Single `<LneDetail>` with `LneDIsAlternative=true` - `<LneItemCode>` still contains **X** (the requested item) |
|
||||
|
||||
## Labeling
|
||||
|
||||
@@ -420,16 +420,16 @@ Key parameters:
|
||||
|
||||
## Related
|
||||
|
||||
- [[stock]] — stock is the physical instance of an item; stock lines carry item code, owner, logistic attributes
|
||||
- [[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
|
||||
- [[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
|
||||
|
||||
+50
-50
@@ -52,10 +52,10 @@ The putaway strategy engine is the core of location search. Two complementary st
|
||||
|
||||
Each strategy (both types) is composed of four elements:
|
||||
|
||||
1. **Criterion** — Conditions that the container or stock must satisfy for the strategy to be a candidate (source, container type, stock properties, item classification, etc.)
|
||||
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.)
|
||||
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.
|
||||
|
||||
@@ -63,33 +63,33 @@ Strategies are sequenced: if criteria for strategy N are not met, strategy N+1 i
|
||||
|
||||
The web UI exposes the strategy engine through two tabs : **Critères** and **Règles**.
|
||||
|
||||
**Sequence management.** Strategies are ordered by **sequence number** — lower = higher priority. The list view exposes **"Augmenter séquence"** / **"Diminuer séquence"** buttons to adjust priorities. The **last-sequence strategy must be a catch-all** (any item, any available location), otherwise the engine may exhaust the list and return no proposal to the operator.
|
||||
**Sequence management.** Strategies are ordered by **sequence number** - lower = higher priority. The list view exposes **"Augmenter séquence"** / **"Diminuer séquence"** buttons to adjust priorities. The **last-sequence strategy must be a catch-all** (any item, any available location), otherwise the engine may exhaust the list and return no proposal to the operator.
|
||||
|
||||
**Onglet Critères** — "Rechercher un emplacement pour" offers :
|
||||
**Onglet Critères** - "Rechercher un emplacement pour" offers :
|
||||
|
||||
| Option | Description |
|
||||
|---|---|
|
||||
| Conteneur client | Client (outbound) containers only |
|
||||
| Conteneur vide | Empty containers |
|
||||
| Profil de stockage | Only items with the specified putaway profile — ⚠️ *if an item has a profile, only profile-matching strategies apply to it* |
|
||||
| Profil de stockage | Only items with the specified putaway profile - ⚠️ *if an item has a profile, only profile-matching strategies apply to it* |
|
||||
| Conteneur ou stock | Loose stock or any container |
|
||||
|
||||
The **"Stock libre"** checkbox restricts the strategy to loose stock (containers excluded). Below, a **Stock** section filters on : stock status, supplier, ABC rotation, item type, owner, hazard codes. The **Station d'origine** block is used for robotic installations.
|
||||
|
||||
**Onglet Règles — "Rechercher un emplacement"** exposes two UI-specific controls not named in the pipeline above :
|
||||
**Onglet Règles - "Rechercher un emplacement"** exposes two UI-specific controls not named in the pipeline above :
|
||||
|
||||
| Parameter | Values |
|
||||
|---|---|
|
||||
| **Mode de stockage** | N'importe quel / Conteneur uniquement / Stock Libre uniquement |
|
||||
| **Valable si** | Emplacement vide ou avec stock / Avec stock uniquement / Canal vide uniquement / Canal avec stock uniquement |
|
||||
|
||||
Remaining rule fields match *Stage 6* above (rack type, specific location, X/Y coordinates, side 0=gauche/1=droite, height min/max, max weight, **Article assigné** — PDL-like assigned-location search, type/aisle, zone, min/max temperature, entrepôt annexe).
|
||||
Remaining rule fields match *Stage 6* above (rack type, specific location, X/Y coordinates, side 0=gauche/1=droite, height min/max, max weight, **Article assigné** - PDL-like assigned-location search, type/aisle, zone, min/max temperature, entrepôt annexe).
|
||||
|
||||
> Crossdocking locations live in the crossdocking sub-warehouse : if the strategy leaves `entrepôt annexe` empty, the engine considers both the main and the crossdocking sub-warehouses.
|
||||
|
||||
**Onglet Règles — "Appliquer restrictions"** checkboxes : `Appliquer restrictions`, `Articles combinés`, `Mélanger des conversions`, `Combiner attributs logistiques`, `Utiliser jours de mélange`, `Mélanger types de conteneurs`, `Rangement partiel de stock`.
|
||||
**Onglet Règles - "Appliquer restrictions"** checkboxes : `Appliquer restrictions`, `Articles combinés`, `Mélanger des conversions`, `Combiner attributs logistiques`, `Utiliser jours de mélange`, `Mélanger types de conteneurs`, `Rangement partiel de stock`.
|
||||
|
||||
**Onglet Règles — "Order locations"** mirrors *Stage 7* sorting. Recommended default for manual warehouses : `Coord X ASC` (seq 1), `Coord Y ASC` (seq 2).
|
||||
**Onglet Règles - "Order locations"** mirrors *Stage 7* sorting. Recommended default for manual warehouses : `Coord X ASC` (seq 1), `Coord Y ASC` (seq 2).
|
||||
|
||||
### Activation, Deactivation, and Editing
|
||||
|
||||
@@ -104,7 +104,7 @@ A strategy takes effect only after explicit **activation**. To modify an existin
|
||||
|
||||
## Location Search Pipeline (Putaway Strategies)
|
||||
|
||||
### Stage 1 — Filter valid strategies by criteria
|
||||
### Stage 1 - Filter valid strategies by criteria
|
||||
|
||||
EasyWMS filters all enabled strategies for the warehouse against five criterion groups:
|
||||
|
||||
@@ -121,7 +121,7 @@ EasyWMS filters all enabled strategies for the warehouse against five criterion
|
||||
|
||||
**Stock criteria:** supplier, status (inbound/outbound), expired stock flag.
|
||||
|
||||
### Stage 2 — Obtain valid aisles
|
||||
### Stage 2 - Obtain valid aisles
|
||||
|
||||
EasyWMS selects accessible aisles reachable by route from the container/stock's current location (direct or indirect routes). For **automatic aisles**, aisles that have exceeded the configured percentage of free locations for relocation are excluded to prevent blocking outbound movements.
|
||||
|
||||
@@ -129,7 +129,7 @@ Occupancy calculation differs by location structure:
|
||||
- **APS (depth control):** counts valid depths per container type vs. occupied depths
|
||||
- **Rack (position control):** counts valid positions per container type vs. occupied positions (considering mask blocking even for unoccupied positions that have tasks)
|
||||
|
||||
### Stage 3 — Aisle balancing (automatic warehouses, containers only)
|
||||
### Stage 3 - Aisle balancing (automatic warehouses, containers only)
|
||||
|
||||
When enabled via parameter `BALANCE_AISLE`, EasyWMS balances load across valid aisles using the formula:
|
||||
|
||||
@@ -141,7 +141,7 @@ Default weights: X=5, Y=1, Z=7 (configurable with expiry date). The aisle with t
|
||||
|
||||
For multi-reference containers, the item with the largest quantity (base UoM) is used for balancing.
|
||||
|
||||
### Stage 4 — Apply restrictions
|
||||
### Stage 4 - Apply restrictions
|
||||
|
||||
Location restrictions (configured globally, independent of strategies) discard candidate locations where two incompatible items/item-types would be co-located. Restrictions are applied only when the strategy rule has "Use restrictions" checked.
|
||||
|
||||
@@ -156,7 +156,7 @@ Location restrictions (configured globally, independent of strategies) discard c
|
||||
|
||||
Restrictions can be scoped to a specific sub-warehouse. They must be enabled and referenced in the strategy to take effect.
|
||||
|
||||
### Stage 5 — Filter valid locations (physical/logical checks)
|
||||
### Stage 5 - Filter valid locations (physical/logical checks)
|
||||
|
||||
From remaining candidates, EasyWMS applies a hard validity checklist:
|
||||
|
||||
@@ -169,7 +169,7 @@ From remaining candidates, EasyWMS applies a hard validity checklist:
|
||||
|
||||
Route validity is also checked: there must be a station route from the container/stock's current station to the candidate location's station. For equipment-based searches, maximum reachable height and work area access are additionally validated.
|
||||
|
||||
### Stage 6 — Apply strategy rule filters
|
||||
### Stage 6 - Apply strategy rule filters
|
||||
|
||||
The strategy rule further filters candidate locations by:
|
||||
|
||||
@@ -194,7 +194,7 @@ The strategy rule further filters candidate locations by:
|
||||
|
||||
Empty locations are always valid regardless of mixing configuration.
|
||||
|
||||
### Stage 7 — Sort locations by preferences
|
||||
### Stage 7 - Sort locations by preferences
|
||||
|
||||
Valid locations are sorted according to the strategy's configured preferences (in priority order):
|
||||
|
||||
@@ -214,7 +214,7 @@ Valid locations are sorted according to the strategy's configured preferences (i
|
||||
| Proximity relocation | Move to closest location (same-aisle relocations only) |
|
||||
| APS3D level ↑↓ | APS3D aisle level (if APS3D module installed) |
|
||||
|
||||
### Stage 8 — Select optimal location and create task
|
||||
### Stage 8 - Select optimal location and create task
|
||||
|
||||
EasyWMS selects the top-ranked location and creates a **Location task** to move the container/stock there. For traced containers, the task targets the base container of the trace hierarchy.
|
||||
|
||||
@@ -247,24 +247,24 @@ Channel strategies group equivalent containers (same type + height + stock refer
|
||||
|
||||
### Channel strategy configuration (SmartUI)
|
||||
|
||||
Channel filling strategies are set up under `Configuration → Stratégies de remplissage de canaux`. Unlike standard putaway strategies, **channel strategies are not sequenced** — the WMS picks the first eligible strategy in the list. Because of this, criteria must be narrow enough to distinguish between strategies.
|
||||
Channel filling strategies are set up under `Configuration → Stratégies de remplissage de canaux`. Unlike standard putaway strategies, **channel strategies are not sequenced** - the WMS picks the first eligible strategy in the list. Because of this, criteria must be narrow enough to distinguish between strategies.
|
||||
|
||||
**EasyS prerequisite.** Racks must be typed as `APS`, `Push Back`, `Dynamic Push Back`, or `Multi-Compact`. Without one of these rack types, the `EmptyChannels_ForContainer` query returns nothing and channel search returns empty. Each location must also declare a **number of authorized containers** — the WMS uses this to compute channel capacity.
|
||||
**EasyS prerequisite.** Racks must be typed as `APS`, `Push Back`, `Dynamic Push Back`, or `Multi-Compact`. Without one of these rack types, the `EmptyChannels_ForContainer` query returns nothing and channel search returns empty. Each location must also declare a **number of authorized containers** - the WMS uses this to compute channel capacity.
|
||||
|
||||
**Two mandatory criteria fields:**
|
||||
|
||||
| Field | Purpose |
|
||||
|---|---|
|
||||
| **Postes sources à considérer** | Source stations from which a container becomes eligible. If the equipment's current station is not in this list, the strategy does not apply — even if the container otherwise matches. |
|
||||
| **Postes sources à considérer** | Source stations from which a container becomes eligible. If the equipment's current station is not in this list, the strategy does not apply - even if the container otherwise matches. |
|
||||
| **Stations à considérer pour les supports candidats** | Buffer stations used to count containers to be placed. Example: if only `RECEPTION` is listed, the WMS searches other eligible containers at `RECEPTION` and looks for a channel with enough capacity to hold them all. |
|
||||
|
||||
**Rule fields** filter destination candidates: storage zones (prioritised), putaway preferences, min/max location height, total weight of candidate containers, **Utiliser l'équilibrage des allées** (boolean — reuses the aisle balance configured on standard putaway strategies).
|
||||
**Rule fields** filter destination candidates: storage zones (prioritised), putaway preferences, min/max location height, total weight of candidate containers, **Utiliser l'équilibrage des allées** (boolean - reuses the aisle balance configured on standard putaway strategies).
|
||||
|
||||
**Reservation timeout.** The **Paramétrage du temps de réservation** field sets the maximum reservation lifetime; expired reservations are dropped automatically.
|
||||
|
||||
**Reservation view.** `Entrepôt → Réservations` shows, per reservation: originating strategy, destination location, item, owner, **remaining containers** on the reservation, PLC height type.
|
||||
|
||||
> ⚠️ Reservations are created **at putaway time only** — there is no background job reserving channels based on existing stock. A candidate container triggers the search and reserves a channel for itself + all buffer peers at that moment.
|
||||
> ⚠️ Reservations are created **at putaway time only** - there is no background job reserving channels based on existing stock. A candidate container triggers the search and reserves a channel for itself + all buffer peers at that moment.
|
||||
|
||||
## Putaway Flow by Object Type
|
||||
|
||||
@@ -293,7 +293,7 @@ Similar flow to container putaway, but:
|
||||
|
||||
### Cutting Stock Putaway (RFT)
|
||||
|
||||
Cutting stock (items sold/stored by length/stretch) requires total-quantity handling — stretches cannot be split. Three modes:
|
||||
Cutting stock (items sold/stored by length/stretch) requires total-quantity handling - stretches cannot be split. Three modes:
|
||||
1. **Select then locate**: choose the stretch, confirm/enter destination
|
||||
2. **Guided unload**: system proposes destination for each stretch in sequence
|
||||
3. **Manual unload**: enter destination to unload all equipment stock at once
|
||||
@@ -358,8 +358,8 @@ Strategy coverage expected per rack type (Mecalux France defaults):
|
||||
|
||||
**Double-depth racks:**
|
||||
- Ascending height + Rotation + Stock balancing
|
||||
- Avoid product mixing — causes relocations during picking
|
||||
- Avoid logistic-attribute / quantity mixing — depends on shipping logic
|
||||
- Avoid product mixing - causes relocations during picking
|
||||
- Avoid logistic-attribute / quantity mixing - depends on shipping logic
|
||||
|
||||
**>2-depth (APS) channels:**
|
||||
- Ascending height + Rotation + Balancing
|
||||
@@ -369,16 +369,16 @@ Strategy coverage expected per rack type (Mecalux France defaults):
|
||||
|
||||
### Empty-location headroom
|
||||
|
||||
**Standard value: 5%** empty locations — required for relocation work and flow variation absorption. Lower values starve the relocation and defragmentation jobs.
|
||||
**Standard value: 5%** empty locations - required for relocation work and flow variation absorption. Lower values starve the relocation and defragmentation jobs.
|
||||
|
||||
### Double-depth layout patterns (EasyS)
|
||||
|
||||
Two rack configurations for double-depth (TK / miniload):
|
||||
|
||||
- **Case #1** (most common at Mecalux France) — best for **mono-product supports**: rotation zones split by front / rear face (several supports with the same article live in the TK)
|
||||
- **Case #2** — best for **multi-product supports**: reduces picking-time relocations without pre-emptive defragmentation (an item never lives in two supports at once)
|
||||
- **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.
|
||||
Choose the pattern **before** running rotation class setup - switching costs a full re-slotting.
|
||||
|
||||
## Parameters
|
||||
|
||||
@@ -393,35 +393,35 @@ Choose the pattern **before** running rotation class setup — switching costs a
|
||||
|
||||
**No valid location found (automatic warehouse):** Rejection task generated. Container goes to rejection station. Common causes: all aisles at relocation % limit, no route between current station and any candidate location, weight exceeded everywhere.
|
||||
|
||||
**Aisle balancing blocks putaway:** Aisle is chosen by balance formula but has no valid location (e.g., full or incompatible). System does not fall back to other aisles for that strategy — next strategy in sequence is tried instead. Ensure next strategy has adequate coverage.
|
||||
**Aisle balancing blocks putaway:** Aisle is chosen by balance formula but has no valid location (e.g., full or incompatible). System does not fall back to other aisles for that strategy - next strategy in sequence is tried instead. Ensure next strategy has adequate coverage.
|
||||
|
||||
**Container stuck in equipment:** Container loaded on equipment but operator ended session without locating. Container remains in equipment indefinitely. Resolve via manual relocation from the equipment management view.
|
||||
|
||||
**Picking dedicated location not proposed:** Item has no PDL created yet, or PDL is for different logistic attributes. Either create a PDL for the correct attributes, or ensure strategy sequence 1 (assigned location) handles this item.
|
||||
|
||||
**Cutting stock putaway fails validation:** Operator entered partial quantity instead of full stretch quantity. Cutting stock requires total-quantity entry — reject partial entries at the RFT.
|
||||
**Cutting stock putaway fails validation:** Operator entered partial quantity instead of full stretch quantity. Cutting stock requires total-quantity entry - reject partial entries at the RFT.
|
||||
|
||||
## Interface Paths
|
||||
|
||||
| Interface | Path |
|
||||
|---|---|
|
||||
| RFT — container/loose stock putaway | Menu "Putaway" → "Containers/Loose stock" or "Containers" |
|
||||
| RFT — 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" |
|
||||
| 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
|
||||
- [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
|
||||
|
||||
@@ -30,7 +30,7 @@ EasyWMS controls stock quality from reception through shipping. Statuses can be
|
||||
- **In the warehouse** (web interface, RFT, or ERP message)
|
||||
- At **shipping** (to require or prefer stock in a specific status for a shipping order line)
|
||||
|
||||
> **Important:** The _Expired_ state is **not** a stock status — stock expires automatically when logistic attribute dates (expiry date, best before date, end of life) are reached.
|
||||
> **Important:** The _Expired_ state is **not** a stock status - stock expires automatically when logistic attribute dates (expiry date, best before date, end of life) are reached.
|
||||
|
||||
---
|
||||
|
||||
@@ -48,8 +48,8 @@ Each stock status is configured to block or allow specific operations:
|
||||
| Internal use (manufacturing) | Yes |
|
||||
|
||||
A single stock record can have two simultaneous statuses:
|
||||
- **Receiving status** — set at reception time (from profile, order line, or operator)
|
||||
- **User status** — applied manually by an operator, manager, or via ERP message
|
||||
- **Receiving status** - set at reception time (from profile, order line, or operator)
|
||||
- **User status** - applied manually by an operator, manager, or via ERP message
|
||||
|
||||
---
|
||||
|
||||
@@ -187,7 +187,7 @@ Both partial and total locks can be performed from **RFT** or **ERP** (STR messa
|
||||
|---|---|
|
||||
| `CST.STK` | Stock status applied or removed (when reception is closed) |
|
||||
|
||||
Note: `CST.STK` is **not** generated if the reception is still open — changes are visible in the interface but not audited until reception closes.
|
||||
Note: `CST.STK` is **not** generated if the reception is still open - changes are visible in the interface but not audited until reception closes.
|
||||
|
||||
---
|
||||
|
||||
@@ -206,8 +206,8 @@ STC is only sent when the **reception is closed**. For stock from open reception
|
||||
|
||||
- A stock can have both a **receiving status** (set at reception) and a **user status** (set manually) simultaneously.
|
||||
- When a lock is applied, EasyWMS immediately checks all active tasks and assignments using that stock and adapts them (cancels or decrements) based on the operations the lock blocks.
|
||||
- Expired stock (`_Expired_` state) is handled by the logistic attributes expiry system — not the quality lock system.
|
||||
- Only locations that allow inventory can have their stock counted. Quality locks do not change this — but locks that prevent counting block task generation.
|
||||
- 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.
|
||||
|
||||
---
|
||||
@@ -253,10 +253,10 @@ STC is only sent when the **reception is closed**. For stock from open reception
|
||||
|
||||
## Related
|
||||
|
||||
- [[stock]] — Quality locks are stored as stock status fields; stock must have no movement-blocking lock to be picked, replenished, or shipped
|
||||
- [[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
|
||||
- [[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
|
||||
|
||||
+27
-27
@@ -34,7 +34,7 @@ last_compiled: "2026-04-17"
|
||||
|
||||
Reception is the process by which stock physically arrives at the warehouse and is formally registered in EasyWMS. Until a receipt is completed and closed, the arrived stock does not exist for any other WMS process (picking, replenishment, shipping). Reception is therefore the entry gate between the physical world and the logical warehouse state.
|
||||
|
||||
EasyWMS supports five distinct reception entry points — each suited to a different physical configuration and information context: **Dock** (manual, RFT-driven), **ASN** (pre-notified containers), **PIE** (automated sensor gate), **PK** (picking conveyor), and **Returns** (customer returns). All share the same fundamental structure: a **Receipt** groups received stock lines, and optionally links to a **Receipt Order** (planned) or generates one ad hoc (blind).
|
||||
EasyWMS supports five distinct reception entry points - each suited to a different physical configuration and information context: **Dock** (manual, RFT-driven), **ASN** (pre-notified containers), **PIE** (automated sensor gate), **PK** (picking conveyor), and **Returns** (customer returns). All share the same fundamental structure: a **Receipt** groups received stock lines, and optionally links to a **Receipt Order** (planned) or generates one ad hoc (blind).
|
||||
|
||||
The reception output is always a REF message to the ERP confirming what was received, and an ASO message (for pre-notified containers) or similar notification per entry point.
|
||||
|
||||
@@ -121,7 +121,7 @@ Supports **exclusive reserve** at receipt time: stock received can be pre-reserv
|
||||
|
||||
Unplanned stock with no prior notification or entry order.
|
||||
|
||||
- A receipt is automatically created (and closed at end) — transparent to the user.
|
||||
- A receipt is automatically created (and closed at end) - transparent to the user.
|
||||
- The receipt cannot be created or edited from the WMS UI.
|
||||
- Supports: multi-reference LPN, single-SKU LPN (labeled/unlabeled/identical), loose stock, cutting stock.
|
||||
- Communicates to ERP via `REF` after blind receipt close.
|
||||
@@ -133,8 +133,8 @@ Unplanned stock with no prior notification or entry order.
|
||||
Customer-returned stock coming back to the warehouse.
|
||||
|
||||
- Can be linked to a receipt order (if created from the web) or not (if created from RFT).
|
||||
- If created from RFT: no lines initially — lines are added as stock is received.
|
||||
- Date logistic attributes (expiry, shelf life) are captured but **not validated** — expired stock may be returned and must be managed after receipt.
|
||||
- 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`
|
||||
|
||||
@@ -180,14 +180,14 @@ Used when the ERP has pre-notified containers via `ASN` message before they phys
|
||||
- Web: `Warehouse > ASN LPN`, `Receiving > Receipt orders`
|
||||
- RFT: `Receipts > Notices`
|
||||
|
||||
#### DirectTransfer — inter-warehouse ASN flow
|
||||
#### DirectTransfer - inter-warehouse ASN flow
|
||||
|
||||
When the source order is a `<DirectTransfer>` shipment (cf. [concepts/order-outbound.md](../concepts/order-outbound.md#asn--directtransfer-flow)), closing the expedition at origin triggers an automatic `ASO01` message on the destination warehouse, pre-creating the incoming ASN container(s). The operator then receives them via RFT menu **Réception → Préavis** just like any other ASN container.
|
||||
When the source order is a `<DirectTransfer>` shipment (cf. [concepts/order-outbound.md](../concepts/order-outbound.md#asn---directtransfer-flow)), closing the expedition at origin triggers an automatic `ASO01` message on the destination warehouse, pre-creating the incoming ASN container(s). The operator then receives them via RFT menu **Réception → Préavis** just like any other ASN container.
|
||||
|
||||
- Container deletion from SmartUI (`Entrepôt → Conteneurs ASN → Supprimer`) triggers an `ASK01` back to the ERP.
|
||||
- ⚠️ The ASO/ASK messages carry **no reference to the originating shipping order or DirectTransfer header** — only the container and its stock.
|
||||
- ⚠️ The ASO/ASK messages carry **no reference to the originating shipping order or DirectTransfer header** - only the container and its stock.
|
||||
|
||||
#### Transfer — two-warehouse ASN flow (with receipt)
|
||||
#### Transfer - two-warehouse ASN flow (with receipt)
|
||||
|
||||
Unlike `<DirectTransfer>` (which bypasses reception at destination), a `<Transfer>`-type shipping order (`SorType = Transfer` in SOR02) **automatically creates an inbound order at destination** when expedition is confirmed at source. The destination ASN containers live on an `Asn` location in the destination warehouse.
|
||||
|
||||
@@ -200,7 +200,7 @@ Operator flow: RFT menu **Réception → Préavis** (of the destination warehous
|
||||
|
||||
**ERP messages generated:**
|
||||
- `ASO01` at each container reception
|
||||
- `ROF02` at inbound order closure (contains **all** received containers — the authoritative record for Transfer receptions)
|
||||
- `ROF02` at inbound order closure (contains **all** received containers - the authoritative record for Transfer receptions)
|
||||
- `ASK01` when closing a partially-received inbound order (to drop non-arrived containers)
|
||||
|
||||
> ⚠️ Neither `ASO01` nor `ASK01` carries the transfer header info. For `<Transfer>` flows the ERP **must** consume `ROF02`.
|
||||
@@ -269,7 +269,7 @@ Receipts can be closed **manually** or **automatically**.
|
||||
|
||||
### Manual Closing
|
||||
|
||||
- Done from web interface or RFT at any time — full quantity not required.
|
||||
- Done from web interface or RFT at any time - full quantity not required.
|
||||
- If linked to receipt orders and all ordered stock received → receipt order = _Completed_; else = _Partially received_.
|
||||
- Stock allocation across identical order lines follows: least expected qty first → oldest creation date → excess to first line allowing it.
|
||||
- Process: `Reception_Close_PR_V2`
|
||||
@@ -317,7 +317,7 @@ Receipts can be closed **manually** or **automatically**.
|
||||
| `ASN` | ERP → WMS | Pre-notifies containers and their stock |
|
||||
| `ASO` | WMS → ERP | Confirms receipt of a pre-notified container |
|
||||
| `ASK` | WMS → ERP | Confirms rejection of a pre-notified container |
|
||||
| `REF` | WMS → ERP | Receipt close confirmation — lists all received stock |
|
||||
| `REF` | WMS → ERP | Receipt close confirmation - lists all received stock |
|
||||
| `ROF` | WMS → ERP | Receipt order close confirmation |
|
||||
| `STV` | WMS → ERP | Stock adjustment in pre-notified container during review |
|
||||
|
||||
@@ -342,7 +342,7 @@ See [concepts/labels.md](../concepts/labels.md) for complete label reference.
|
||||
- Cause: Order code unknown or not yet created.
|
||||
- Solution: Enable `ALLOW_CREATE_RECEPTION` to create a new receipt; or have the ERP send the `ROR` message first.
|
||||
|
||||
**ASN container rejected at PIE — order doesn't exist:**
|
||||
**ASN container rejected at PIE - order doesn't exist:**
|
||||
- Cause: Receipt order referenced in ASN message not yet in WMS.
|
||||
- Solution: If `USE_EXCLUSIVE_RESERVE_STRICT_MODE` is inactive, container can still be received; reserve is formalized later. If active, resolve order absence first.
|
||||
|
||||
@@ -350,7 +350,7 @@ See [concepts/labels.md](../concepts/labels.md) for complete label reference.
|
||||
- Cause: Receipt still has uncommitted lines or allows excess reception.
|
||||
- Solution: Close manually, or verify `AutoCloseReception` is active and no line allows over-receipt.
|
||||
|
||||
**Quantity discrepancy at PIE — container sent to reconditioning:**
|
||||
**Quantity discrepancy at PIE - container sent to reconditioning:**
|
||||
- Cause: ASN pre-notified stock quantity doesn't match received stock and receipt order doesn't allow excess.
|
||||
- Solution: Correct the discrepancy at the reconditioning station and retry.
|
||||
|
||||
@@ -360,13 +360,13 @@ See [concepts/labels.md](../concepts/labels.md) for complete label reference.
|
||||
|
||||
**Return receipt rejected for expired stock:**
|
||||
- Cause: `RECEPTION_NUM_DAYS_PRODUCTION_DATE_MARGIN` check triggered.
|
||||
- Note: Date logistic attributes are captured but expiry is **not blocked** during returns — check parameter configuration.
|
||||
- Note: Date logistic attributes are captured but expiry is **not blocked** during returns - check parameter configuration.
|
||||
|
||||
---
|
||||
|
||||
## Reception Split Strategy (Mecalux France pattern)
|
||||
|
||||
Deployed at **ROUJE** and **NEUT** — documented from NEUT (blind reception, supplier + customer return, loose stock on equipment). When the item has a picking dedicated location (PDL), incoming stock is split at reception between two buffers so PDLs are filled to capacity directly and the overflow lands in reserve.
|
||||
Deployed at **ROUJE** and **NEUT** - documented from NEUT (blind reception, supplier + customer return, loose stock on equipment). When the item has a picking dedicated location (PDL), incoming stock is split at reception between two buffers so PDLs are filled to capacity directly and the overflow lands in reserve.
|
||||
|
||||
**Flow:**
|
||||
|
||||
@@ -396,7 +396,7 @@ Deployed at **ROUJE** and **NEUT** — documented from NEUT (blind reception, su
|
||||
| 3 | PICKING buffer | Dedicated picking locations | Item assigned, destination zone = PICKING |
|
||||
| 4 | RESERVE buffer | Pallet rack locations | Destination zone = PALETTE |
|
||||
|
||||
**Split logic (custom workflow) — rules applied after stock reception:**
|
||||
**Split logic (custom workflow) - rules applied after stock reception:**
|
||||
|
||||
| Situation | Action |
|
||||
|---|---|
|
||||
@@ -408,8 +408,8 @@ Deployed at **ROUJE** and **NEUT** — documented from NEUT (blind reception, su
|
||||
> ⚠️ Stock dropped on the RESERVE buffer **must** be on a container (existing LPN or a newly generated code).
|
||||
|
||||
**Customs required:**
|
||||
- `Equipment_Unload_ProductUnloadOnContainer_UI` — hide the free-drop button when `location.code == "RESERVE"`
|
||||
- `Equipment_Unload_ProductUnloadAllStockOnContainer_UI` — idem
|
||||
- `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).
|
||||
@@ -435,12 +435,12 @@ Reference implementation: [NEUT-58](https://easywmsfrance.atlassian.net/browse/N
|
||||
|
||||
## Related
|
||||
|
||||
- [concepts/container.md](../concepts/container.md) — LPN structure, statuses, ASN pre-notification
|
||||
- [concepts/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
|
||||
- [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
|
||||
|
||||
@@ -26,13 +26,13 @@ last_compiled: "2026-04-17"
|
||||
|
||||
## Overview
|
||||
|
||||
Replenishment is the process of moving stock from bulk storage locations to **picking dedicated locations (PDL)** to ensure that operators always have stock available to fulfill shipping orders without going to the main rack. It is a supporting process that feeds the picking operation — without replenishment, picking dedicated locations would run dry and order preparation would stall.
|
||||
Replenishment is the process of moving stock from bulk storage locations to **picking dedicated locations (PDL)** to ensure that operators always have stock available to fulfill shipping orders without going to the main rack. It is a supporting process that feeds the picking operation - without replenishment, picking dedicated locations would run dry and order preparation would stall.
|
||||
|
||||
A **picking dedicated location (PDL)** is a location permanently or dynamically assigned to one item (sometimes one item per partition). PDLs are configured with a minimum (replenishment threshold) and maximum (capacity). When stock in the PDL drops below the minimum, the replenishment system detects the shortage and generates a replenishment task to refill from a source location.
|
||||
|
||||
Replenishment in EasyWMS operates at two levels:
|
||||
1. **PDL replenishment** — refilling picking dedicated locations from bulk storage
|
||||
2. **Sub-warehouse replenishment** — moving stock from one sub-warehouse to another to balance inventory
|
||||
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)
|
||||
|
||||
@@ -45,15 +45,15 @@ A PDL is a location with an item assignment that designates it as the primary pi
|
||||
| **Location** | Must have: allow item assignment, allow picking, allow replenish, allow putaway |
|
||||
| **Item** | One item recommended per PDL (multiple items allowed but not typical) |
|
||||
| **Owner** | Owner of the item |
|
||||
| **Replenishment mode** | Container (move whole container) or Stock (move loose stock) — cannot mix both |
|
||||
| **Replenishment mode** | Container (move whole container) or Stock (move loose stock) - cannot mix both |
|
||||
| **Conversion** | Unit of measure in which replenishment level and capacity are expressed |
|
||||
| **Logistic attributes** | Specific batch, color, quality, etc. — PDL will be replenished with matching stock only |
|
||||
| **Logistic attributes** | Specific batch, color, quality, etc. - PDL will be replenished with matching stock only |
|
||||
| **Maximum lots** | Limit how many different lots can be present in the PDL simultaneously |
|
||||
| **Expired stock flag** | PDL can be configured to receive only expired stock |
|
||||
| **Days of life** | Replenish with stock whose shelf life ≥ (detection date + days of life) |
|
||||
| **Stock status** | Restrict to stock in a specific status |
|
||||
|
||||
**For stock-mode PDLs — threshold types:**
|
||||
**For stock-mode PDLs - threshold types:**
|
||||
|
||||
| Threshold type | Description | Notes |
|
||||
|---------------|-------------|-------|
|
||||
@@ -68,15 +68,15 @@ A PDL is a location with an item assignment that designates it as the primary pi
|
||||
- **Maximum containers**: capacity ceiling
|
||||
- **Replenishment level %** (if max = 1): percentage of full-container quantity below which replenishment is triggered; allows exceeding the full quantity to absorb the incoming container's excess stock
|
||||
|
||||
### PDL — EasyS / SmartUI Configuration
|
||||
### PDL - EasyS / SmartUI Configuration
|
||||
|
||||
**EasyS — Location setup**, check :
|
||||
**EasyS - Location setup**, check :
|
||||
|
||||
- `Allow product location`
|
||||
- `Allow replenish at source`
|
||||
- `Allow picking`
|
||||
|
||||
**SmartUI — `Entrepôt → Emplacements consacrés au picking`** :
|
||||
**SmartUI - `Entrepôt → Emplacements consacrés au picking`** :
|
||||
|
||||
- Enter the **replenishment level** (minimum threshold)
|
||||
- Enter the **maximum capacity**
|
||||
@@ -84,13 +84,13 @@ A PDL is a location with an item assignment that designates it as the primary pi
|
||||
- Enter a **Texte personnalisé** (custom label)
|
||||
- Print the PDL barcodes
|
||||
|
||||
> 💡 Labels display as `Code emplacement [Label]` (e.g. `B-1-4 [Clavier M]`). With many PDLs this is hard to scan through — Mecalux France standard is to **prefix labels with an ordered code** (e.g. `B-1-4 [01 Clavier M]`, `B-1-4 [02 Clavier L]`...) so the operator can sort them visually.
|
||||
> 💡 Labels display as `Code emplacement [Label]` (e.g. `B-1-4 [Clavier M]`). With many PDLs this is hard to scan through - Mecalux France standard is to **prefix labels with an ordered code** (e.g. `B-1-4 [01 Clavier M]`, `B-1-4 [02 Clavier L]`...) so the operator can sort them visually.
|
||||
|
||||
> ⚠️ **Known limitations** documented by Mecalux France (2022 tests) :
|
||||
> - The **destination is not displayed** when the WMS generates putaway tasks towards a PDL.
|
||||
> - **Maximum capacity is not strictly enforced** at putaway — cases of 26 units put away in a capacity-15 PDL have been observed. Rely on replenishment threshold + periodic count rather than `max capacity` as a hard limit.
|
||||
> - **Maximum capacity is not strictly enforced** at putaway - cases of 26 units put away in a capacity-15 PDL have been observed. Rely on replenishment threshold + periodic count rather than `max capacity` as a hard limit.
|
||||
>
|
||||
> Positive : **minimum-threshold replenishment works correctly** — a task is generated to top the PDL back up to its maximum once the minimum is crossed.
|
||||
> Positive : **minimum-threshold replenishment works correctly** - a task is generated to top the PDL back up to its maximum once the minimum is crossed.
|
||||
|
||||
### PDL Creation Methods
|
||||
|
||||
@@ -99,16 +99,16 @@ A PDL is a location with an item assignment that designates it as the primary pi
|
||||
| Web interface | Warehouse manager manually creates PDL assignments |
|
||||
| RFT during putaway | Operator assigns item to location while unloading (if `UNLOAD_CREATE_PRODUCT_LOCATION` enabled) |
|
||||
| RFT during counting | Item assigned during stock count (if `UNLOAD_CREATE_PRODUCT_LOCATION` and `REPLENISH_LEVEL_PERCENT_PRODUCT_LOCATION` enabled) |
|
||||
| RFT — "Assign item to loc." | Dedicated menu option in Utilities |
|
||||
| RFT - "Assign item to loc." | Dedicated menu option in Utilities |
|
||||
| Automatically (dynamic replenishment) | System creates PDL on-the-fly for items in active shipping orders |
|
||||
|
||||
### PDL Partitions
|
||||
|
||||
A single physical location can be subdivided into **partitions** — labeled divisions each assigned to a different item. This enables high-density picking areas (drawers, shelves divided by bins).
|
||||
A single physical location can be subdivided into **partitions** - labeled divisions each assigned to a different item. This enables high-density picking areas (drawers, shelves divided by bins).
|
||||
|
||||
Key partition rules:
|
||||
- Each partition is identified by a unique QR label (code unique within the location)
|
||||
- A partition is NOT a separate location — stock belongs to the location; the partition identifies which item occupies which physical space
|
||||
- A partition is NOT a separate location - stock belongs to the location; the partition identifies which item occupies which physical space
|
||||
- One partition can be shared across multiple items; one item can use multiple partitions
|
||||
- A partition can be marked **full** to prevent further putaway to that partition
|
||||
- **Maximum partitions per item**: configurable limit to prevent one item from monopolizing a location's partitions
|
||||
@@ -133,7 +133,7 @@ Mecalux France uses three shortcut names that map to the strategy types below:
|
||||
|
||||
| FR label | Type below | Trigger | Typical usage |
|
||||
|---|---|---|---|
|
||||
| **"Routine"** | Stockout (automatic) | `TryToReplenishProductLocations` job every 1–2 min | Default — refill PDL when stock drops under the minimum |
|
||||
| **"Routine"** | Stockout (automatic) | `TryToReplenishProductLocations` job every 1–2 min | Default - refill PDL when stock drops under the minimum |
|
||||
| **"Conclure"** | Particular demand (top-off) | RFT menu **Réapprovisionnement** or SmartUI "Réapprovisionner maintenant" on the PDL view | Operator-triggered, high-priority replenishment |
|
||||
| **"Exiger"** | Shipping demand (dynamic) | Order released with dynamic replenishment, or static flag `<EnableReplenishment>` on ROR | Create PDLs on the fly for items in released orders; also tops up when stock ≥ min but < order need |
|
||||
|
||||
@@ -142,14 +142,14 @@ Mecalux France uses three shortcut names that map to the strategy types below:
|
||||
- Reserve (source) locations: `Allow replenish at source`
|
||||
|
||||
**SmartUI configuration checklist (routine, conclure, exiger):**
|
||||
1. `Entrepôt → Gestion des emplacements picking` — create PDL assignments, set **min threshold** (per container: tick "Réapprovisionnement de conteneur", or in base UoM) and **max capacity**
|
||||
1. `Entrepôt → Gestion des emplacements picking` - create PDL assignments, set **min threshold** (per container: tick "Réapprovisionnement de conteneur", or in base UoM) and **max capacity**
|
||||
2. Activate automatic replenishment on the PDL (for routine)
|
||||
3. `Configuration → Stratégie de réapprovisionnement` — create the strategy; pick filters (item, owner, item type, sub-warehouse, destination zone) and a **Mode efficacité** (see table below)
|
||||
3. `Configuration → Stratégie de réapprovisionnement` - create the strategy; pick filters (item, owner, item type, sub-warehouse, destination zone) and a **Mode efficacité** (see table below)
|
||||
4. **Activate** the strategy (to edit it later, deactivate first)
|
||||
5. `Configuration → Processus` — ensure `TryToReplenishProductLocations` is enabled and runs on a 1–2 min cycle
|
||||
5. `Configuration → Processus` - ensure `TryToReplenishProductLocations` is enabled and runs on a 1–2 min cycle
|
||||
6. Confirm source stock is eligible (no blocking status, no location lock, not already assigned to shipping)
|
||||
|
||||
### Efficiency mode — SmartUI values
|
||||
### Efficiency mode - SmartUI values
|
||||
|
||||
| FR field | Behaviour |
|
||||
|---|---|
|
||||
@@ -228,7 +228,7 @@ Strategies are sequenced to determine which sub-warehouses are replenished first
|
||||
|
||||
### 4b. Priority Location Replenishment
|
||||
|
||||
A fifth strategy type refills **priority locations** — locations associated with a PDL from which the PDL is replenished. This allows a two-tier system: primary storage → priority location → PDL.
|
||||
A fifth strategy type refills **priority locations** - locations associated with a PDL from which the PDL is replenished. This allows a two-tier system: primary storage → priority location → PDL.
|
||||
|
||||
## Efficiency Modes
|
||||
|
||||
@@ -280,7 +280,7 @@ Dynamic replenishment runs periodically (or on manual trigger) and follows this
|
||||
|
||||
## Dynamic Picking Emptying Tasks (Vidage)
|
||||
|
||||
Dynamic PDLs created by the shipping demand strategy are temporary — they exist only for the duration of the order they were created for. Once the order is shipped, the dynamic PDL may still contain leftover stock that should be returned to bulk storage.
|
||||
Dynamic PDLs created by the shipping demand strategy are temporary - they exist only for the duration of the order they were created for. Once the order is shipped, the dynamic PDL may still contain leftover stock that should be returned to bulk storage.
|
||||
|
||||
**Emptying tasks (vidage)** are generated automatically on a schedule to clear unused dynamic picking locations:
|
||||
- The system identifies dynamic PDLs whose associated shipping orders are complete (shipped or cancelled)
|
||||
@@ -326,21 +326,21 @@ When a single equipment cannot traverse from the reserve sub-warehouse to the pi
|
||||
|
||||
### Typical setup
|
||||
|
||||
- **Sub-warehouse A** (`WHST_ANCIEN_BAT`) — PDLs to replenish
|
||||
- **Sub-warehouse B** (`WHST_TOUR`) — high reserves
|
||||
- **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 |
|
||||
| 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.
|
||||
> ⚠️ Routes are created by default with the **"Galileo"** transport - switch them to **"RF"** manually.
|
||||
|
||||
### Flow
|
||||
|
||||
@@ -348,7 +348,7 @@ When a single equipment cannot traverse from the reserve sub-warehouse to the pi
|
||||
2. The reserve equipment (e.g. `CACES06`) picks up the support and drops it on the **intermediate Buffer location**
|
||||
3. The picking equipment (e.g. `PIK01`) picks up the task from **Tâches → Tâches de réapprovisionnement** and drops the stock on the destination PDL
|
||||
|
||||
> Troubleshooting — "support n'existe pas" when scanning the buffer location: verify that the transit sub-location is of type **"Buffer"** (not "Automatic").
|
||||
> Troubleshooting - "support n'existe pas" when scanning the buffer location: verify that the transit sub-location is of type **"Buffer"** (not "Automatic").
|
||||
|
||||
Upstream MSSCC documentation: `replenishments/intermediate_stations.md` and `EasyS/configurations/IntermediateET/index.md`.
|
||||
|
||||
@@ -380,23 +380,23 @@ In automatic warehouses, the picking conveyor (PK) generates demand that drives
|
||||
|
||||
| Interface | Path |
|
||||
|---|---|
|
||||
| Web — replenishment strategies | "Configuration" → "Replenishment strategies" |
|
||||
| Web — 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 |
|
||||
| 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
|
||||
- [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
|
||||
|
||||
+43
-43
@@ -47,7 +47,7 @@ last_compiled: "2026-04-17"
|
||||
|
||||
## Overview
|
||||
|
||||
Shipping is the end-to-end process of fulfilling customer orders: from order receipt through stock assignment, preparation (picking or container shipping), consolidation, truck loading, and closure. EasyWMS represents outbound work through **shipping orders** — the central document linking customer demand to warehouse operations.
|
||||
Shipping is the end-to-end process of fulfilling customer orders: from order receipt through stock assignment, preparation (picking or container shipping), consolidation, truck loading, and closure. EasyWMS represents outbound work through **shipping orders** - the central document linking customer demand to warehouse operations.
|
||||
|
||||
Shipping orders typically arrive from the ERP via `SOR` messages but can be created manually from the web interface. For the canonical shipping order lifecycle and all statuses (Waiting, Reserved, Released, In Preparation, Paused, Closed/Archived, etc.) see [Outbound Order](order-outbound.md).
|
||||
|
||||
@@ -119,7 +119,7 @@ Release can be:
|
||||
|
||||
**ERP message sent:** `SOC` (order status change)
|
||||
**Transaction recorded:** `OUT.CST`
|
||||
**Parameter:** `MAX_AUTORELEASED_OUTBOUNDORDERS` — maximum orders auto-released simultaneously
|
||||
**Parameter:** `MAX_AUTORELEASED_OUTBOUNDORDERS` - maximum orders auto-released simultaneously
|
||||
|
||||
### Release by Sub-warehouse
|
||||
|
||||
@@ -140,7 +140,7 @@ Multiple shipping orders are picked together (same picking path). After picking,
|
||||
|
||||
### Fusions
|
||||
|
||||
Multiple shipping orders are shipped together without ungrouping — typically for orders going to the same customer. Picked stock can be placed in shared containers without redistribution.
|
||||
Multiple shipping orders are shipped together without ungrouping - typically for orders going to the same customer. Picked stock can be placed in shared containers without redistribution.
|
||||
|
||||
### Waves
|
||||
|
||||
@@ -177,17 +177,17 @@ A stock-assignment strategy and/or a prepackaging strategy can be attached to th
|
||||
|
||||
**Per-type tabs** :
|
||||
- **Picking d'ordres groupés** : grouping criteria (carrier, mono-ligne, mono-unité, critère personnalisé), group size (max orders / lines / volume), filters (stock rangé, crossdocking, UdM, critère perso), ungrouping (UAP + packing buffer), minimum conditions (min qty, min orders).
|
||||
- **Vague de picking** : carrier + critère perso ; max orders, volume, UdM, min orders. Checkbox **"Generate tasks on release"** — if set, tasks are created when the wave is released ; otherwise at operator pickup time.
|
||||
- **Vague de picking** : carrier + critère perso ; max orders, volume, UdM, min orders. Checkbox **"Generate tasks on release"** - if set, tasks are created when the wave is released ; otherwise at operator pickup time.
|
||||
- **Picking d'ordre** : for single-order templates. Filters on UdM + critère perso only.
|
||||
|
||||
**Scheduler.** Templates can run between two hours on selected weekdays, with a configurable interval in minutes. Two daily windows (e.g. 9–10h and 15–16h) require **duplicating** the template.
|
||||
|
||||
**Criteria** are mandatory (at least one per template). Each criterion rejects orders that don't match — two tabs are available :
|
||||
**Criteria** are mandatory (at least one per template). Each criterion rejects orders that don't match - two tabs are available :
|
||||
|
||||
- **Ordre d'expédition** : Code, Description, Type (`Customer`, `Transfer`, `DirectTransfer`, `Fabrication`, `Manuel`, `Retour`…), Class, Owner, Mono-ligne, Mono-unité, Follow sequence, Auto-release, Carrier, Transport type, N hours before release/loading, N hours late, Country/City/Postal code.
|
||||
- **Ligne d'ordre d'expédition** : item type, item family, danger, stackability, voluminous, single parcel.
|
||||
|
||||
**Critère personnalisé — LINQ syntax** :
|
||||
**Critère personnalisé - LINQ syntax** :
|
||||
|
||||
```csharp
|
||||
// Criterion on the outbound order itself (ex: orders imported with source = "WEB")
|
||||
@@ -227,10 +227,10 @@ Typical need: order prepared from multiple origins (manual + automatic aisles, d
|
||||
3. Empty source containers are deleted if configured; task cancellation follows
|
||||
|
||||
**Transactions:**
|
||||
- `CON.CREATE` — new consolidation container created
|
||||
- `STK.MOVE` — stock moved from source to destination
|
||||
- `CON.DELETE` — empty source container deleted
|
||||
- `TSK.CANCEL` — tasks for deleted container canceled
|
||||
- `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.
|
||||
|
||||
@@ -262,7 +262,7 @@ When route sequencing is planned by a TMS, the ERP sends a **`RUT` file** instea
|
||||
|
||||
Operational flow :
|
||||
|
||||
1. **Integrate the RUT file.** Orders appear in the orders view but must be handled from the **routes view** — releasing them individually is not the nominal path.
|
||||
1. **Integrate the RUT file.** Orders appear in the orders view but must be handled from the **routes view** - releasing them individually is not the nominal path.
|
||||
2. **Launch the route** → each order is auto-released with its stock assignment.
|
||||
3. **Prepare the orders** in any convenient internal order.
|
||||
4. **Create a truck load** and attach it to the route. A template can create the load automatically at route release.
|
||||
@@ -300,14 +300,14 @@ Loads represent a physical transport vehicle (truck, van) that will carry one or
|
||||
|
||||
### Multi-zone Loading (Virtual Dock)
|
||||
|
||||
Warehouses with multiple storage/preparation areas can use a **virtual dock** — a common dock reference for all zones. Carriers collect stock from different physical zones, but all are referenced to the same virtual dock for tracking purposes.
|
||||
Warehouses with multiple storage/preparation areas can use a **virtual dock** - a common dock reference for all zones. Carriers collect stock from different physical zones, but all are referenced to the same virtual dock for tracking purposes.
|
||||
|
||||
### Truck Loading — SmartUI configuration reference (Mecalux France)
|
||||
### Truck Loading - SmartUI configuration reference (Mecalux France)
|
||||
|
||||
Standard EasyWMS exposes two truck-loading modes at dock level :
|
||||
|
||||
- **No buffer** — order auto-ships as soon as it lands on the dock
|
||||
- **Buffer + dock** — an intermediate control step validates pallets against the load before shipment
|
||||
- **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):**
|
||||
|
||||
@@ -316,12 +316,12 @@ Standard EasyWMS exposes two truck-loading modes at dock level :
|
||||
| **Automatic (planned)** | Load created at order release; strict container control (scanning a container from another order raises an error) |
|
||||
| **Non planifié** | Load created at release; **no container control** |
|
||||
| **Manuel (planned)** | Load created manually; strict container control |
|
||||
| RFT — manual, no control | Created from RFT; no container control (indicative only) |
|
||||
| RFT — from a route | Load tied to an existing route |
|
||||
| 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:**
|
||||
**SmartUI - Configuration → Chargements:**
|
||||
|
||||
| Option | Effect |
|
||||
|---|---|
|
||||
@@ -332,24 +332,24 @@ EasyS minimum: **one buffer + one dock** per dock used. The buffer can be carrie
|
||||
| Quantity validation | Same semantics as picking |
|
||||
| **Allow load of all stock** | Adds a RFT button to load all free stock in one action |
|
||||
|
||||
**RFT — create a load from the floor:** `Ordres de sortie → Chargement camion → Charger les conteneurs → Nouveau`. To **disable** this path, set every order-type mode to something other than "Non planifiée". As soon as one type is "Non planifiée", operators can create loads from RFT.
|
||||
**RFT - create a load from the floor:** `Ordres de sortie → Chargement camion → Charger les conteneurs → Nouveau`. To **disable** this path, set every order-type mode to something other than "Non planifiée". As soon as one type is "Non planifiée", operators can create loads from RFT.
|
||||
|
||||
**RFT — execute a load (`EasyWMS.TruckLoad_GetLoads_UI`):**
|
||||
**RFT - execute a load (`EasyWMS.TruckLoad_GetLoads_UI`):**
|
||||
|
||||
1. `Ordres de sortie → Chargement camion → Charger les conteneurs`
|
||||
2. Filter by dock/buffer or by load
|
||||
3. Select the load (status `Ready to load` if the whole order is prepared)
|
||||
4. Scan pallets — button **"Conteneur"** lists remaining containers ; **"Effectuer"** closes the load even if pallets are missing
|
||||
4. Scan pallets - button **"Conteneur"** lists remaining containers ; **"Effectuer"** closes the load even if pallets are missing
|
||||
|
||||
> ℹ️ During loading the load status reads **"Loading"** (red on RFT).
|
||||
|
||||
**Delivery-note printing at load close:** when the BL is configured to print on order close, **closing the truck load triggers the print** — including for a partial close. On a two-step load (remainder), the BL is printed at each close and always covers **all shipped lines of the order**.
|
||||
**Delivery-note printing at load close:** when the BL is configured to print on order close, **closing the truck load triggers the print** - including for a partial close. On a two-step load (remainder), the BL is printed at each close and always covers **all shipped lines of the order**.
|
||||
|
||||
**Truck unloading (RFT):** menu `Décharger les conteneurs` → scan the container → scan the drop-off location (default: the end-of-preparation buffer).
|
||||
|
||||
### Order Merge vs Load
|
||||
|
||||
Truck loading handles **loads** — merging happens **before** load creation on the shipping orders themselves. A merged order behaves as a single order when assigning a load, but ERP traceability remains per-original-order (see [Outbound Order → Merge](order-outbound.md#merge-order-fusion)).
|
||||
Truck loading handles **loads** - merging happens **before** load creation on the shipping orders themselves. A merged order behaves as a single order when assigning a load, but ERP traceability remains per-original-order (see [Outbound Order → Merge](order-outbound.md#merge-order-fusion)).
|
||||
|
||||
## Truck Loading (RFT Process)
|
||||
|
||||
@@ -378,7 +378,7 @@ Operators at the dock register each item loaded using the RFT:
|
||||
- Auto-close: last item loaded triggers close process (seal registration, report collection)
|
||||
- Partial close: configured to allow closing without all units loaded
|
||||
|
||||
## PS Groups (Automatic Warehouse — Outbound Conveyors)
|
||||
## PS Groups (Automatic Warehouse - Outbound Conveyors)
|
||||
|
||||
PS (Pallet Shuttle or outbound conveyor) groups are logical groupings of outbound conveyors in automatic warehouses. Each group configures which PS stations belong to it and how they are filled (criteria for which PS station gets the next container).
|
||||
|
||||
@@ -451,25 +451,25 @@ Multiple shipping orders can be merged into the same client container if they me
|
||||
|
||||
| Interface | Path |
|
||||
|---|---|
|
||||
| Web — shipping orders | Menu "Shippings" → "Shipping orders" |
|
||||
| Web — 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" |
|
||||
| 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
|
||||
- [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
|
||||
|
||||
+27
-27
@@ -72,16 +72,16 @@ Easy WMS defines 37+ standard station types. Types are identified by a numeric c
|
||||
|
||||
| Code | Type | Name | Description |
|
||||
|------|------|------|-------------|
|
||||
| 0 | ALM | Warehouse | Set of storage locations (shelves, ground locations, any storage element). Not connected to TMS — no machine communication. Involved in: location (destination), extraction (source), transfer (source+destination). Can be configured to allow/deny inbounds or outbounds independently. |
|
||||
| 0 | ALM | Warehouse | Set of storage locations (shelves, ground locations, any storage element). Not connected to TMS - no machine communication. Involved in: location (destination), extraction (source), transfer (source+destination). Can be configured to allow/deny inbounds or outbounds independently. |
|
||||
|
||||
### Inbound / Conveyor Stations (AS/RS)
|
||||
|
||||
| Code | Type | Name | Description |
|
||||
|------|------|------|-------------|
|
||||
| 3 | PIE | Pallet Check Unit | Dimensional + identification control of containers. TMS sends height, weight, status, and label data to Easy WMS. Easy WMS validates and routes: correct → warehouse; wrong → REAC/RECH. All stations with a gauge arch or scale must be configured as PIE. PIE events evaluate flags: 65536=correct, 256=barcode error, 512=recovered container, 1024/66560=correct+empty, 3=holes+studs, 4=overheight, 8–64=overhangs, 128=weight excess. |
|
||||
| 9 | ME | Aisle Inbound Conveyor | Interchange point with AS/RS (TRASLO). Final optimization before container enters the machine. Checks stacker crane characteristics (number of extractors, conveyors). If container arrives at ME with both putaway and picking tasks, putaway is cancelled and container goes to picking. Final location decision point — refines but doesn't replace initial search. Required in all automatic warehouses with stacker cranes. |
|
||||
| 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. |
|
||||
| 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. |
|
||||
@@ -91,15 +91,15 @@ Easy WMS defines 37+ standard station types. Types are identified by a numeric c
|
||||
|
||||
| Code | Type | Name | Description |
|
||||
|------|------|------|-------------|
|
||||
| 1 | TRASLO | AS/RS | Automated Storage/Retrieval System — the crane or machine. Bidirectional: loads from ME (inbound), unloads into MS (outbound). Communication via protocol (Galileo IV supports loading event + location release simultaneously). |
|
||||
| 1 | TRASLO | AS/RS | Automated Storage/Retrieval System - the crane or machine. Bidirectional: loads from ME (inbound), unloads into MS (outbound). Communication via protocol (Galileo IV supports loading event + location release simultaneously). |
|
||||
|
||||
### Picking Stations
|
||||
|
||||
| Code | Type | Name | Description |
|
||||
|------|------|------|-------------|
|
||||
| 2 | PK | Picking Conveyor | Managed from the "Picking" view. Operator is guided: what to pick, how much, where to put it. Supports multiple locations per station (multiple containers simultaneously). Operations: direct picking, container/item count, replenishments. Can have associated RECH reject station. Empty container removal requires location configured for empty container handling. |
|
||||
| 4 | PS | Outbound Conveyor | Final point of automatic transport — container leaves the warehouse. Management cycle of Easy WMS ends here (no more tasks). May have a display panel showing operator where to carry the container. Location types: Dynamic (Easy WMS tracks container depth) or Automatic (Easy WMS knows only which container is on PS, not which follows). |
|
||||
| 16 | MP | Preparation Zone | Zone for order preparation — used in semi-automatic picking operations. |
|
||||
| 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. |
|
||||
@@ -112,19 +112,19 @@ Easy WMS defines 37+ standard station types. Types are identified by a numeric c
|
||||
| Code | Type | Name | Description |
|
||||
|------|------|------|-------------|
|
||||
| 5 | REAC | Reconditioning | Destination for containers that fail PIE validation but can be corrected and re-injected into the flow. |
|
||||
| 7 | RECH | Rejects | Destination for definitively rejected containers — not reintegrable. |
|
||||
| 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. |
|
||||
| 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. |
|
||||
| 42 | RETENTION | Retention | Retention station - holds containers that require manual review or authorization before continuing their route. |
|
||||
| 43 | DESK | Desk | Desk station for administrative or manual operations. |
|
||||
| 55 | ECB | Empty Containers Buffer | Buffer specifically for empty containers waiting to be stacked or reused. |
|
||||
| 58 | ETQ | Labeller | Labeling machine station — container passes through and is automatically labeled. |
|
||||
| 58 | ETQ | Labeller | Labeling machine station - container passes through and is automatically labeled. |
|
||||
|
||||
### Dock & Stage Stations
|
||||
|
||||
| Code | Type | Name | Description |
|
||||
|------|------|------|-------------|
|
||||
| 33 | Stage | Stage (Shipping/Receiving) | Floor area for temporary stock storage, typically near docks. Receiving stages: for stock pending putaway. Shipping stages: for client containers awaiting truck load. One of each can be set as default. Locations are DockStage type — Easy WMS does not control exact container position. Capacity = 0 means unlimited. Cannot be used for putaway; cannot generate tasks from stage (only from warehouse-type locations). |
|
||||
| 33 | Stage | Stage (Shipping/Receiving) | Floor area for temporary stock storage, typically near docks. Receiving stages: for stock pending putaway. Shipping stages: for client containers awaiting truck load. One of each can be set as default. Locations are DockStage type - Easy WMS does not control exact container position. Capacity = 0 means unlimited. Cannot be used for putaway; cannot generate tasks from stage (only from warehouse-type locations). |
|
||||
| 33 | PKS | Packing Station | Packing station for packaging operations (shares type code 33 with Stage). |
|
||||
| 34 | Dock | Dock | Point of receipt or shipping. Types: inbound dock, outbound dock, or combined. At least one must be configured. Locations are DockStage type. No exact position tracking. Route must exist (even indirect) from container location to dock for task generation. Multiple locations per dock supported. |
|
||||
|
||||
@@ -133,7 +133,7 @@ Easy WMS defines 37+ standard station types. Types are identified by a numeric c
|
||||
| Code | Type | Name | Description |
|
||||
|------|------|------|-------------|
|
||||
| 38 | Kit | Kits Assembly | Station for assembling kit items. |
|
||||
| 57 | CONVEYOR | Conveyor (eCommerce) | Conveyor station for eCommerce operations — container-based order consolidation. |
|
||||
| 57 | CONVEYOR | Conveyor (eCommerce) | Conveyor station for eCommerce operations - container-based order consolidation. |
|
||||
| 59 | VAS | VAS Conveyor | Conveyor station for executing Value Added Services. |
|
||||
| 61 | Cutting | Cutting Station | Station where cutting stock is cut in integrated or delegated picking processes. Composed of a receiving stage and a shipping stage (configurable: 1 shared stage, 2 dedicated stages, or shared stages across multiple cutting stations). Can be locked via "Stations" view to prevent stock assignment. |
|
||||
| 65 | AGV | AGV Station | AGV robot station. |
|
||||
@@ -146,7 +146,7 @@ A single physical station can have more than one role, enabling context-sensitiv
|
||||
|
||||
**PIE with multiple roles:** A PIE station configured as a rejection or reconditioning station simultaneously. The workstation view updates to show the appropriate interface (PIE vs RECH/REAC) based on the container's task. Configuration: arrange both stations in EasyS, create PIE→RECH/REAC route, add RECH/REAC as Error Entity for PIE. Then assign role in SmartUI "Stations" view via "Assign new role".
|
||||
|
||||
**PK with multiple roles:** PK station acting also as a reject station. When a container is rejected at PIE, the target reject station is the PK that originally handled the container — enabling workload balance and operator accountability. No SmartUI role assignment needed. Configuration: arrange PK+RECH in EasyS, create route, add RECH as Error Entity for PK. Special case: if no dedicated reject station exists, PK itself can be the PIE's error entity.
|
||||
**PK with multiple roles:** PK station acting also as a reject station. When a container is rejected at PIE, the target reject station is the PK that originally handled the container - enabling workload balance and operator accountability. No SmartUI role assignment needed. Configuration: arrange PK+RECH in EasyS, create route, add RECH as Error Entity for PK. Special case: if no dedicated reject station exists, PK itself can be the PIE's error entity.
|
||||
|
||||
## Station Code Translation (FR / ES / EN)
|
||||
|
||||
@@ -169,7 +169,7 @@ Mecalux teams work across three languages; the same station can appear in logs a
|
||||
|
||||
## Station Capacity Semantics (GALILEO view)
|
||||
|
||||
Station capacity has a **different meaning** on PK and PS than on other stations — this trips up Gateway log analysis.
|
||||
Station capacity has a **different meaning** on PK and PS than on other stations - this trips up Gateway log analysis.
|
||||
|
||||
| Layer | Generic station (conveyor/TK) | PK and PS |
|
||||
|-------|-------------------------------|-----------|
|
||||
@@ -181,7 +181,7 @@ Worked example (PK): 1 physical slot + 4 in transit on intermediate conveyors +
|
||||
|
||||
## Route configuration in EasyS (robotics)
|
||||
|
||||
In robotics installations, **every** movement between automated stations requires a route in EasyS. A single task (e.g. `PIE → Miniload`) can generate **N movements** (4 is typical) — the WMS creates one task, the routing table allows each hop.
|
||||
In robotics installations, **every** movement between automated stations requires a route in EasyS. A single task (e.g. `PIE → Miniload`) can generate **N movements** (4 is typical) - the WMS creates one task, the routing table allows each hop.
|
||||
|
||||
> If no path exists, EasyWMS creates a **reject task** toward the configured reject station.
|
||||
|
||||
@@ -195,7 +195,7 @@ EasyS route types (cross-reference with Manager table below):
|
||||
| **Manual** | Operator action triggered by a WMS task |
|
||||
| **Virtual** | Instantaneous automatic movement (e.g. output → consolidation) |
|
||||
|
||||
**Reject routes** (in red) are special: they give the **task destination** (not the movement destination). Different `IdentError` reasons can target different reject destinations — see [IdentErrorType](https://msscc.mecalux.com/documentation/Development/master/ES/apis/easywms/Domain/IdentErrorType.md).
|
||||
**Reject routes** (in red) are special: they give the **task destination** (not the movement destination). Different `IdentError` reasons can target different reject destinations - see [IdentErrorType](https://msscc.mecalux.com/documentation/Development/master/ES/apis/easywms/Domain/IdentErrorType.md).
|
||||
|
||||
For the protocol layer and message exchange (Search / End / Event / station updates), see [GALILEO Integration](../architecture/galileo-integration.md). For bring-up and simulation, see [Galileo Simulation](../operations/galileo-simulation.md).
|
||||
|
||||
@@ -210,7 +210,7 @@ Easy WMS generates tasks based on configured routes. Before generating a task, i
|
||||
1. That a route exists between source and destination.
|
||||
2. That the route is **active** (all stations in route are not locked).
|
||||
|
||||
Exception: shipping full containers via dock — only checks that a route exists, not whether it's active.
|
||||
Exception: shipping full containers via dock - only checks that a route exists, not whether it's active.
|
||||
|
||||
If the shortest active route is blocked, Easy WMS immediately tries an alternative route.
|
||||
|
||||
@@ -218,7 +218,7 @@ If the shortest active route is blocked, Easy WMS immediately tries an alternati
|
||||
|
||||
### Route Managers (Executors)
|
||||
|
||||
Each simple route requires a declared manager — the type of element that will execute tasks on that route:
|
||||
Each simple route requires a declared manager - the type of element that will execute tasks on that route:
|
||||
|
||||
| Manager | Executor |
|
||||
|---------|----------|
|
||||
@@ -226,7 +226,7 @@ Each simple route requires a declared manager — the type of element that will
|
||||
| Monorail | Monorail system |
|
||||
| RF | Operator with RFT (radio frequency terminal) |
|
||||
| Voice | Operator with voice terminal |
|
||||
| Virtual | Automatic — task auto-completes when container arrives at source station, no physical action |
|
||||
| Virtual | Automatic - task auto-completes when container arrives at source station, no physical action |
|
||||
| PTL | Pick-to-Light system |
|
||||
| External | External system (AGV, vertical warehouse, ERP, etc.) |
|
||||
| APS3D Fleet Manager | APS3D cart system |
|
||||
@@ -278,10 +278,10 @@ Docks and stages are created in **EasyS** (or **Warehouse Designer**), not in Sm
|
||||
|
||||
## Related
|
||||
|
||||
- [[location]] — Location types associated with each station (DockStage, buffer, conventional)
|
||||
- [[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
|
||||
- [[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
|
||||
|
||||
@@ -36,9 +36,9 @@ last_compiled: "2026-04-17"
|
||||
A **stock adjustment** is any manual modification to a stock record's quantity, unit of measure (UoM), or logistic attributes that corrects a discrepancy between the physical reality and the WMS records. Every adjustment requires a **reason** for traceability.
|
||||
|
||||
Adjustments can be made from three interfaces:
|
||||
- **RF terminal (RFT)** — field operators correcting detected errors
|
||||
- **SmartUI (PC web)** — manager-level adjustments from the web interface
|
||||
- **Workstation / picking conveyor** — adjustments at an automatic warehouse PK station
|
||||
- **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).
|
||||
|
||||
@@ -146,13 +146,13 @@ Every adjustment requires a **reason code** selected from the master. Reasons ar
|
||||
### RF Terminal Adjustments
|
||||
|
||||
Available options from `RFT > Utilities`:
|
||||
- **Increase item** — quantity increase
|
||||
- **Decrease item** — quantity decrease
|
||||
- **Location adjustment** — full adjustment (qty + UoM + AL + status)
|
||||
- **Manual Movement** — move stock/container (see [manual-movements](../concepts/manual-movements.md))
|
||||
- **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
|
||||
- **Adjust in picking location with partitions** - reading a partition label sets both location and item
|
||||
- **Adjustment during count** (in-count adjustments reported separately)
|
||||
|
||||
### SmartUI (Web) Adjustments
|
||||
@@ -211,7 +211,7 @@ A manager must then approve or cancel via `Warehouse > Stock adjustments`:
|
||||
**On adjustment (immediate):**
|
||||
- EasyWMS sends **STV** (stock variation) to ERP for each affected stock line
|
||||
|
||||
**Exception — open reception:**
|
||||
**Exception - open reception:**
|
||||
- If adjusted stock belongs to a still-open reception, changes are reflected in the WMS interface but **no STV is sent** until reception closes
|
||||
|
||||
**Double validation:**
|
||||
@@ -225,7 +225,7 @@ A manager must then approve or cancel via `Warehouse > Stock adjustments`:
|
||||
- Adjusting stock with active tasks triggers automatic task cancellation or decrement, then re-release of affected order lines.
|
||||
- Adjustment at quantity = 0 in a container: the container is **removed** or **left empty** depending on the location's "remove empty container" configuration.
|
||||
- ASN containers (pre-notified, not yet received) cannot be adjusted.
|
||||
- Client stock (already prepared/loaded for a shipping order) has special handling — it can be adjusted but incompatibility with the order line triggers unassignment.
|
||||
- Client stock (already prepared/loaded for a shipping order) has special handling - it can be adjusted but incompatibility with the order line triggers unassignment.
|
||||
- For multi-reception stock, the operator selects which specific reception's stock is being adjusted.
|
||||
- Cutting stock (non-consolidating UoM) can only be adjusted in whole stretch quantities; partial cutting requires the cutting process.
|
||||
|
||||
@@ -241,13 +241,13 @@ A manager must then approve or cancel via `Warehouse > Stock adjustments`:
|
||||
|
||||
Double validation is activated per item via its **count profile** (field: double validation flag in `inventory_management/double_validation/items/count_profile.md`).
|
||||
|
||||
### Count Profile — validation modes (WMS ≥ 2023-02-22)
|
||||
### Count Profile - validation modes (WMS ≥ 2023-02-22)
|
||||
|
||||
A **Count Profile** (`Configuration → Count Profiles`) decides whether stock adjustments for an item go straight through or wait for supervisor approval.
|
||||
|
||||
| Mode | Effect |
|
||||
|---|---|
|
||||
| **Never** | No validation required — STV is sent immediately |
|
||||
| **Never** | No validation required - STV is sent immediately |
|
||||
| **Always** | Every adjustment is held as `Pending` |
|
||||
| **According to tolerance** | Held as `Pending` **only if** the adjustment exceeds the configured tolerance |
|
||||
|
||||
@@ -260,7 +260,7 @@ A **Count Profile** (`Configuration → Count Profiles`) decides whether stock a
|
||||
| Maximum positive adjust | Absolute increase allowed without validation (base UoM) |
|
||||
| Maximum negative adjust | Absolute decrease allowed without validation (base UoM) |
|
||||
|
||||
> ℹ️ Count Profiles cannot yet be created via ITM — master data only in SmartUI.
|
||||
> ℹ️ Count Profiles cannot yet be created via ITM - master data only in SmartUI.
|
||||
|
||||
Attach the profile to an item by editing the item and selecting its Count Profile.
|
||||
|
||||
@@ -270,7 +270,7 @@ Attach the profile to an item by editing the item and selecting its Count Profil
|
||||
|
||||
- **Rights:** group `SuperAdmin` or `Administrateur` (Manager/Operator not allowed by default).
|
||||
- **Group rights do not disable validation.** Even a SuperAdmin creating the adjustment from RFT still triggers the SmartUI validation step if the item has a Count Profile requiring it.
|
||||
- Default view shows only `Pending` — enable the history filter to see validated/rejected past adjustments.
|
||||
- Default view shows only `Pending` - enable the history filter to see validated/rejected past adjustments.
|
||||
- Row colours : **green** = validated / no profile / profile "Never" / below tolerance; **red** = rejected.
|
||||
|
||||
**Cancel behaviour:**
|
||||
@@ -279,9 +279,9 @@ Attach the profile to an item by editing the item and selecting its Count Profil
|
||||
|
||||
### French UI labels reminder
|
||||
|
||||
- **Pending** — no transaction, no ERP communication (stock change *is already applied* in the WMS, only ERP sync is held)
|
||||
- **Validé** — STV sent to ERP
|
||||
- **Annulé** — stock delta reverted in WMS; no transaction, no ERP message
|
||||
- **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.
|
||||
|
||||
@@ -295,7 +295,7 @@ Attach the profile to an item by editing the item and selecting its Count Profil
|
||||
| `RFT > Utilities > Decrease item` | RFT |
|
||||
| `RFT > Utilities > Location adjustment` | RFT |
|
||||
| `Workstations > Picking > Others > Stock Adjustment` | PC |
|
||||
| `Warehouse > Stock` (SmartUI — logistic attributes) | PC |
|
||||
| `Warehouse > Stock` (SmartUI - logistic attributes) | PC |
|
||||
| `Warehouse > Stock adjustments` (double validation review) | PC |
|
||||
| `Masters > Adjustment reasons` | PC |
|
||||
|
||||
@@ -316,11 +316,11 @@ Attach the profile to an item by editing the item and selecting its Count Profil
|
||||
|
||||
## Related
|
||||
|
||||
- [[stock]] — Adjustment modifies stock records; STV and STK.ADJ are core stock transactions
|
||||
- [[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
|
||||
- [[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
|
||||
|
||||
@@ -12,7 +12,7 @@ related:
|
||||
- concepts/crossdocking.md
|
||||
- concepts/cutting-stock.md
|
||||
- concepts/task.md
|
||||
- modules/tenseflow.md
|
||||
- concepts/tense-flow.md
|
||||
last_compiled: "2026-04-17"
|
||||
---
|
||||
|
||||
@@ -22,7 +22,7 @@ last_compiled: "2026-04-17"
|
||||
|
||||
**Stock assignment** is the engine that binds concrete stock to outbound work. Given an outbound order line (and its `OutboundOrderLineDetails`), it decides **which stock lines** will fulfil the demand and **what type of task** will be created to physically move them (picking, container shipping, replenishment, virtual picking).
|
||||
|
||||
Every line detail is assigned independently — a line can have several details either because the requested item is a **non-assembled kit** (one detail per component) or because **alternative items** have been configured (if the main item is short, the WMS adds an extra detail with the substitute item and zeroes the main item's quantity).
|
||||
Every line detail is assigned independently - a line can have several details either because the requested item is a **non-assembled kit** (one detail per component) or because **alternative items** have been configured (if the main item is short, the WMS adds an extra detail with the substitute item and zeroes the main item's quantity).
|
||||
|
||||
The assignment engine is a chain of workflows all prefixed `StockAssignProcess_*`. The main entry point is `StockAssignProcess_AssignOutboundLine_PR`, which loops over the line's details through `StockAssignProcess_AssignOutboundOrderLineDetails_PR`.
|
||||
|
||||
@@ -38,16 +38,16 @@ Loads the outbound line detail, locks it for the assignment run, and reads the m
|
||||
|
||||
Workflow: `StockAssignProcess_GetAvailableStockForOutboundOrderLineDetails_PR`
|
||||
|
||||
Calls the query **`Stocks_AssignableForProductOutboundOrderLineDetailsAndStockAssignStrategy`**. Additional filters on assignable stock (e.g., custom-attribute filtering, reservations, supplier constraints) are added as extra `where` clauses on this query — once they are in place, SmartUI surfaces them under the **"Trace d'assignations de stock"** button for auditability.
|
||||
Calls the query **`Stocks_AssignableForProductOutboundOrderLineDetailsAndStockAssignStrategy`**. Additional filters on assignable stock (e.g., custom-attribute filtering, reservations, supplier constraints) are added as extra `where` clauses on this query - once they are in place, SmartUI surfaces them under the **"Trace d'assignations de stock"** button for auditability.
|
||||
|
||||
### 3. Apply assignment strategy
|
||||
|
||||
Two branches:
|
||||
|
||||
- **Kits, manufacturing orders, TenseFlow** — the WMS prioritises stock already sitting in the dedicated consumption zone (assembly zone, production supply zone, TenseFlow supply zone) through `StockAssignProcess_CalculateByAssignmentManufacturingAndKits_PR`. This avoids pulling stock across zones when an in-zone alternative exists.
|
||||
- **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).
|
||||
- **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`.
|
||||
|
||||
@@ -55,15 +55,15 @@ The candidate list is narrowed and finally validated by `StockAssignProcess_Vali
|
||||
|
||||
Two sibling workflows:
|
||||
|
||||
- `StockAssignProcess_CreateAssignments_PR` — writes the assignment rows (visible in SmartUI under **Allocations de stock**).
|
||||
- `Outbound_StockAssignCreateOrderLineDetailsTasks_PR` — translates each assignment into a task of the appropriate type (see below).
|
||||
- `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. |
|
||||
| **ReplenishmentAssignment** | The candidate location permits replenishment but the on-hand quantity is insufficient. The engine creates a **picking task and a parallel replenishment task** - covers both static (PDL-driven) and dynamic replenishment scenarios. |
|
||||
| **ShippingContainer** | The full container (mono-reference) is needed and the location allows container shipping. A container-shipping task is created instead of a picking task. |
|
||||
| **PickingContainer** | Specific to **TenseFlow**. A `BufferReplenishment` task is created first, moving the container to the supply zone ; during virtual picking, virtual picking tasks are generated against the buffered stock. |
|
||||
|
||||
@@ -71,15 +71,15 @@ Two sibling workflows:
|
||||
|
||||
### Kits
|
||||
|
||||
If **any component** of a non-assembled kit cannot be assigned, **no component is assigned** — the engine rolls back and leaves the line short so the operator does not start half-kits. The matching behaviour for assembled kits (ready-made component) is standard.
|
||||
If **any component** of a non-assembled kit cannot be assigned, **no component is assigned** - the engine rolls back and leaves the line short so the operator does not start half-kits. The matching behaviour for assembled kits (ready-made component) is standard.
|
||||
|
||||
### Crossdocking
|
||||
|
||||
When the item allows crossdocking, an inbound expected to arrive shortly will block the engine from re-assigning the outbound line to existing stock — it will wait for the crossdocking candidate. Customers who do not want this behaviour comment out the crossdocking branch in the stock search query.
|
||||
When the item allows crossdocking, an inbound expected to arrive shortly will block the engine from re-assigning the outbound line to existing stock - it will wait for the crossdocking candidate. Customers who do not want this behaviour comment out the crossdocking branch in the stock search query.
|
||||
|
||||
### Alternatives
|
||||
|
||||
When the main item cannot cover the line quantity, the engine inserts a new detail with the alternative item and sets the main item's remaining quantity to zero. The alternative detail goes through the same pipeline — it may itself fall back to another alternative if further shortage occurs.
|
||||
When the main item cannot cover the line quantity, the engine inserts a new detail with the alternative item and sets the main item's remaining quantity to zero. The alternative detail goes through the same pipeline - it may itself fall back to another alternative if further shortage occurs.
|
||||
|
||||
## Customisation points
|
||||
|
||||
@@ -87,31 +87,31 @@ When the main item cannot cover the line quantity, the engine inserts a new deta
|
||||
|---|---|
|
||||
| Expose more line-detail fields to the engine | Extend `Select` in `StockAssignProcess_GetLockAndUpdateDetail_PR` |
|
||||
| Filter candidate stock on a new criterion | Add `where` clauses in `Stocks_AssignableForProductOutboundOrderLineDetailsAndStockAssignStrategy` (visible in SmartUI "Trace d'assignations de stock") |
|
||||
| Generate **only picking tasks** (e.g., for waves — wave mode only consumes picking tasks) | Modify `StockAssignProcess_GetStockToAssignForStrategy_PR` ; if the WMS version has the assignment-merge feature, also modify `Outbound_CreatePickingLocationsTasks_PR` |
|
||||
| Generate **only picking tasks** (e.g., for waves - wave mode only consumes picking tasks) | Modify `StockAssignProcess_GetStockToAssignForStrategy_PR` ; if the WMS version has the assignment-merge feature, also modify `Outbound_CreatePickingLocationsTasks_PR` |
|
||||
| Disable crossdocking blocking | Comment out the crossdocking predicate in the stock search query |
|
||||
|
||||
## Observability
|
||||
|
||||
- **SmartUI → Allocations de stock** — shows which stock line is reserved for which outbound line detail, with the assignment type.
|
||||
- **"Trace d'assignations de stock"** button — exposes the extra filters added to `Stocks_AssignableForProductOutboundOrderLineDetailsAndStockAssignStrategy` so support can see why a candidate was rejected.
|
||||
- **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 |
|
||||
| Kit line assigned with some components but not all | Should not happen - rollback rule is absolute. Check if components were split across two details by an alternative cascade |
|
||||
| Expected replenishment-plus-picking not generated | Picking location does not actually permit replenishment, or all candidate reserves are locked |
|
||||
| Container shipping task created when picking was expected | Line quantity equals full container quantity **and** location allows container shipping — disable the container-shipping branch on the location if not desired |
|
||||
| Container shipping task created when picking was expected | Line quantity equals full container quantity **and** location allows container shipping - disable the container-shipping branch on the location if not desired |
|
||||
|
||||
## Related
|
||||
|
||||
- [[stock]] — the data model assignment writes against
|
||||
- [[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
|
||||
- [[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
|
||||
|
||||
+19
-19
@@ -39,11 +39,11 @@ last_compiled: "2026-04-17"
|
||||
|
||||
## Overview
|
||||
|
||||
A **stock record** (stock line) is the physical instance of an item in the warehouse at a specific moment — a quantity of a particular item, owned by a specific owner, in a specific location or container, with specific logistic attributes and status. It is distinct from the item master: the item defines what the product is; the stock defines how much of it exists, where, and in what state.
|
||||
A **stock record** (stock line) is the physical instance of an item in the warehouse at a specific moment - a quantity of a particular item, owned by a specific owner, in a specific location or container, with specific logistic attributes and status. It is distinct from the item master: the item defines what the product is; the stock defines how much of it exists, where, and in what state.
|
||||
|
||||
Stock is created when goods are received, consumed when goods are shipped, and transformed (split, merged, adjusted) throughout warehouse operations. The WMS maintains an exact, real-time view of all stock across every location and container in the warehouse. All WMS processes (putaway strategies, stock assignment for outbound orders, replenishment, counting) operate against stock records.
|
||||
|
||||
A single item in the warehouse can have many stock lines — one per unique combination of container, logistic attributes, and status. For example, the same SKU in three different lot numbers stored in two locations will produce at least 6 separate stock lines.
|
||||
A single item in the warehouse can have many stock lines - one per unique combination of container, logistic attributes, and status. For example, the same SKU in three different lot numbers stored in two locations will produce at least 6 separate stock lines.
|
||||
|
||||
## Types
|
||||
|
||||
@@ -53,7 +53,7 @@ Stock is classified by its storage context and status:
|
||||
|
||||
- **Containerized stock**: stock inside a container (LPN). The container holds the stock and can be moved as a unit. The stock line references both the container and the location of the container.
|
||||
- **Loose stock**: stock directly in a location, not in a container. Common in conventional manual locations with picking dedicated partitions.
|
||||
- **Client stock**: stock that has been prepared (picked) for a specific outbound order, now in a client (outbound) container. Special rules apply — quantity, UoM, and logistic attributes cannot be adjusted like regular stock.
|
||||
- **Client stock**: stock that has been prepared (picked) for a specific outbound order, now in a client (outbound) container. Special rules apply - quantity, UoM, and logistic attributes cannot be adjusted like regular stock.
|
||||
- **ASN stock**: stock pre-notified by the ERP but not yet physically received. Located in the virtual ASN location. Cannot be adjusted.
|
||||
|
||||
### By status
|
||||
@@ -62,7 +62,7 @@ Stock carries up to three parallel status dimensions:
|
||||
|
||||
| Status type | Description | Set by |
|
||||
|---|---|---|
|
||||
| **System status** | Internal WMS status (e.g., normal, reserved, assigned) | Automatic — driven by stock assignment and task creation |
|
||||
| **System status** | Internal WMS status (e.g., normal, reserved, assigned) | Automatic - driven by stock assignment and task creation |
|
||||
| **User status** | Quality or business-driven lock (e.g., "Quarantine", "Hold") | Manually by user, or via ERP STR message. Has optional end date. |
|
||||
| **Receiving status** | Quality control status set during reception | At reception, automatically based on receipt order configuration |
|
||||
|
||||
@@ -192,7 +192,7 @@ Stock adjustments allow operators to correct discrepancies between the WMS recor
|
||||
> **WSC / SCR**: To get the complete stock image, the ERP sends an **SCR** request and EasyWMS responds with a **WSC** file. This can be:
|
||||
> - Grouped by item (one line per item/owner/status)
|
||||
> - Detailed (with location and container)
|
||||
> - The WSC does NOT discriminate "available to sell" — use stock status filtering for that.
|
||||
> - The WSC does NOT discriminate "available to sell" - use stock status filtering for that.
|
||||
> - Stock at 0 can optionally be included (configurable).
|
||||
> - Can be sent on-demand or on a scheduled basis (once/day or at intervals).
|
||||
|
||||
@@ -211,7 +211,7 @@ EasyWMS supports a **double validation** mechanism for stock adjustments. When a
|
||||
Configuration (per item, in **inventory profile**):
|
||||
| Setting | Behavior |
|
||||
|---------|---------|
|
||||
| **Never** | No double validation — adjustments applied immediately |
|
||||
| **Never** | No double validation - adjustments applied immediately |
|
||||
| **Always** | All adjustments require manager validation |
|
||||
| **By tolerance** | Requires validation only if delta exceeds a configured threshold (absolute value or %) |
|
||||
|
||||
@@ -271,7 +271,7 @@ The grouped stock reports provide aggregate views of stock without the per-line
|
||||
|---|---|---|
|
||||
| Cannot adjust ASN stock | Stock is in pre-notified container not yet received | Receive the container first via the reception process |
|
||||
| Cannot adjust client stock | Stock is prepared for a shipping order in a client container | Un-prepare the stock via shipping management, then adjust |
|
||||
| Adjustment fails — reason required | No adjustment reason selected | Create reasons in Masters; select one before adjusting |
|
||||
| Adjustment fails - reason required | No adjustment reason selected | Create reasons in Masters; select one before adjusting |
|
||||
| Stock not visible in view | Stock in virtual location (ASN, Lost_Found) or filtered out | Remove filters; check virtual locations explicitly |
|
||||
| Stock in lock not assignable | User or receiving status prevents shipping | Release the lock (manually or via STR from ERP); or add required status to SOR line |
|
||||
| Quantity jumps after decrease | Other stock from the same item was consolidated | Separate stock lines if needed; use "From multiple receptions" selection |
|
||||
@@ -279,15 +279,15 @@ The grouped stock reports provide aggregate views of stock without the per-line
|
||||
|
||||
## Related
|
||||
|
||||
- [[container]] — stock is either containerized (in an LPN) or loose; container locks and type affect stock eligibility
|
||||
- [[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
|
||||
- [[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
|
||||
|
||||
@@ -19,7 +19,7 @@ last_compiled: "2026-04-10"
|
||||
|
||||
## Overview
|
||||
|
||||
A **supplier** is a company or entity that supplies stock to the warehouse. Suppliers are referenced on receipt orders (inbound) and return orders (outbound). Every inbound flow — whether a standard delivery, ASN-based reception, or stock return — traces back to a supplier.
|
||||
A **supplier** is a company or entity that supplies stock to the warehouse. Suppliers are referenced on receipt orders (inbound) and return orders (outbound). Every inbound flow - whether a standard delivery, ASN-based reception, or stock return - traces back to a supplier.
|
||||
|
||||
Suppliers are master data entities managed in WMS (or synced from ERP via SUP message). When the Owner Extensions module is active, each supplier must be assigned to an owner.
|
||||
|
||||
@@ -68,8 +68,8 @@ Suppliers are master data entities managed in WMS (or synced from ERP via SUP me
|
||||
|
||||
## Related
|
||||
|
||||
- [[reception]] — dock reception references the supplier; supplier container and loose stock reception modes exist
|
||||
- [[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
|
||||
- [[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
|
||||
|
||||
+18
-18
@@ -85,17 +85,17 @@ In **automatic warehouses**, tasks are executed by automated systems (AS/RS, AGV
|
||||
↓
|
||||
Task CREATED (pending movement generation)
|
||||
↓
|
||||
PENDING — waiting for movement to be generated
|
||||
PENDING - waiting for movement to be generated
|
||||
↓
|
||||
GENERATED — movement created, no operator/machine assigned yet
|
||||
GENERATED - movement created, no operator/machine assigned yet
|
||||
↓
|
||||
IN PROCESS — currently being executed
|
||||
IN PROCESS - currently being executed
|
||||
↓
|
||||
FINISHED — task completed successfully
|
||||
|
||||
FINISHED - task completed successfully
|
||||
|
||||
(at any point from Generated or In Process)
|
||||
↓
|
||||
CANCELED — task stopped by user action
|
||||
CANCELED - task stopped by user action
|
||||
```
|
||||
|
||||
### Status transitions
|
||||
@@ -110,7 +110,7 @@ In **automatic warehouses**, tasks are executed by automated systems (AS/RS, AGV
|
||||
|
||||
## Tasks and movements
|
||||
|
||||
The task defines **from where to where** (source station → destination station). The actual path may pass through multiple intermediate stations. Easy WMS decomposes the task into **movements** — each movement covers one segment (one station to the next).
|
||||
The task defines **from where to where** (source station → destination station). The actual path may pass through multiple intermediate stations. Easy WMS decomposes the task into **movements** - each movement covers one segment (one station to the next).
|
||||
|
||||
Each segment has a configured **manager** (who/what executes it):
|
||||
- **RF**: human operator with radio frequency terminal
|
||||
@@ -133,7 +133,7 @@ Movement release (reset In Execution → Pending) is available for resolving inc
|
||||
## Business rules
|
||||
|
||||
- **Cannot manually complete** picking, counting, replenishment (stock replenishment type), kit assembly, or consolidation tasks. These must be completed through their respective processes.
|
||||
- **Task assignment** to user or equipment respects work zone restrictions — if the equipment cannot access the required work zone or aisle, the task will not be executable.
|
||||
- **Task assignment** to user or equipment respects work zone restrictions - if the equipment cannot access the required work zone or aisle, the task will not be executable.
|
||||
- **Equipment incompatibility**: equipment that cannot transport the container type specified in the task is ineligible.
|
||||
- **Priority** drives task sequencing within a process queue (lower number = higher priority; values: Very Low, Low, Normal, High, Urgent).
|
||||
- **Task cancellation**: container stays where the operator reports it (user must indicate the location, including position for rack locations or depth for channel locations).
|
||||
@@ -152,7 +152,7 @@ For manual warehouse RF execution, the priority ordering is:
|
||||
|
||||
**Shipping tasks:** Round number → Priority → Empty channel → Stackability → Distance → Creation date
|
||||
|
||||
**Wave picking:** Priority (of the wave/orders assigned) → Route path (right and left sides, low to high — no second rounds)
|
||||
**Wave picking:** Priority (of the wave/orders assigned) → Route path (right and left sides, low to high - no second rounds)
|
||||
|
||||
**Order picking (RF):** For task selection: assigned to user/equipment first → Priority → Release date. For task execution: same as automatic tasks.
|
||||
|
||||
@@ -201,16 +201,16 @@ Transactions are generated by the underlying process (not by semi-automatic mode
|
||||
| Task created but not assignable | Equipment type incompatible with container type in task | Assign different equipment; check equipment container type configuration |
|
||||
| Task cannot be manually completed | Task type is picking, counting, stock replenishment, kit assembly, or consolidation | Complete via the appropriate process screen (picking station, count screen, etc.) |
|
||||
| Movement stuck In Execution | Automatic system malfunction or communication failure | Use Movement Release to reset to Pending; investigate automation incident |
|
||||
| Canceled task — container not found | Operator reported wrong location at cancellation | Run a count or check Last Known Location; resolve via Lost & Found if needed |
|
||||
| Canceled task - container not found | Operator reported wrong location at cancellation | Run a count or check Last Known Location; resolve via Lost & Found if needed |
|
||||
| Task not generated after process trigger | Work zone restriction prevents any available equipment from executing | Check work zone configuration and available equipment |
|
||||
|
||||
## Related
|
||||
|
||||
- [[location]] — tasks always have a source and destination location; location type (rack, compact, etc.) determines coordinate precision in tasks
|
||||
- [[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
|
||||
- [[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
|
||||
|
||||
+12
-12
@@ -16,12 +16,12 @@ last_compiled: "2026-04-17"
|
||||
|
||||
## Overview
|
||||
|
||||
Tense Flow (FR : *flux tendu*) enables picking directly from one or more source supports — typically to prepare an outbound order **straight from reception** without first putting the stock away. The stock never hits a "normal" storage location : it is replenished to a dedicated buffer (FR : *poumon PREPARATION*) and consumed from there virtually.
|
||||
Tense Flow (FR : *flux tendu*) enables picking directly from one or more source supports - typically to prepare an outbound order **straight from reception** without first putting the stock away. The stock never hits a "normal" storage location : it is replenished to a dedicated buffer (FR : *poumon PREPARATION*) and consumed from there virtually.
|
||||
|
||||
The flow combines:
|
||||
1. A **tense-flow element** + an associated **buffer stage** (typically named `PREPARATION`).
|
||||
2. A **replenishment task** from the source location(s) to the buffer, triggered at order release.
|
||||
3. **Virtual picking** on the RF terminal — the operator scans the source support + the newly created client container and declares the picked quantity.
|
||||
3. **Virtual picking** on the RF terminal - the operator scans the source support + the newly created client container and declares the picked quantity.
|
||||
4. A closing step that transfers the client containers to the shipping buffer.
|
||||
|
||||
## EasyS Configuration
|
||||
@@ -31,7 +31,7 @@ The flow combines:
|
||||
3. Associate the tense-flow element to the buffer as a `Delivery Stage`.
|
||||
4. Configure the source locations (buffers and racks) with the option **"Allow origin of replenishement of tense flow"** set to true, otherwise the replenishment task generated at "Lancer en flux tendu" will find no candidate origins.
|
||||
|
||||
> ⚠️ Tense Flow always creates a replenishment task *towards the buffer first* — the source locations must be eligible as tense-flow origins, not only as normal-flow origins.
|
||||
> ⚠️ Tense Flow always creates a replenishment task *towards the buffer first* - the source locations must be eligible as tense-flow origins, not only as normal-flow origins.
|
||||
|
||||
## Functional Flow
|
||||
|
||||
@@ -48,7 +48,7 @@ RFT menu : **Tâches → Tâches à flux tendu**. Execute the task to move stock
|
||||
RFT menu : **Ordres de sortie → Picking virtuel**.
|
||||
|
||||
1. Scan the **source support** (the pallet / container now at the buffer).
|
||||
2. Create a **new client container** — use the **"Générer SSCC"** button to assign a fresh SSCC.
|
||||
2. Create a **new client container** - use the **"Générer SSCC"** button to assign a fresh SSCC.
|
||||
3. Scan the new container or the destination location.
|
||||
4. Enter the item + picked quantity (and any logistic attributes).
|
||||
|
||||
@@ -60,16 +60,16 @@ Once all the client containers are filled, transfer them to the `EXPEDITION` buf
|
||||
|
||||
## Common Errors
|
||||
|
||||
**"Lancer en flux tendu" creates no replenishment task** : either the outbound order is not released yet, or the source locations are not marked as `Allow origin of replenishement of tense flow`. Tense Flow replenishment uses a separate eligibility flag from the standard replenishment — enable it on the candidate origins.
|
||||
**"Lancer en flux tendu" creates no replenishment task** : either the outbound order is not released yet, or the source locations are not marked as `Allow origin of replenishement of tense flow`. Tense Flow replenishment uses a separate eligibility flag from the standard replenishment - enable it on the candidate origins.
|
||||
|
||||
**Virtual picking screen rejects the source scan** : the stock is not on the `PREPARATION` buffer yet — the replenishment task must be executed first.
|
||||
**Virtual picking screen rejects the source scan** : the stock is not on the `PREPARATION` buffer yet - the replenishment task must be executed first.
|
||||
|
||||
**Remaining stock is not proposed for putaway** : the tense-flow element is not associated to the buffer as a `Delivery Stage` — re-check EasyS step 3.
|
||||
**Remaining stock is not proposed for putaway** : the tense-flow element is not associated to the buffer as a `Delivery Stage` - re-check EasyS step 3.
|
||||
|
||||
## Related
|
||||
|
||||
- [Picking](picking.md) — tense flow is a special picking mode that bypasses storage
|
||||
- [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
|
||||
- [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
|
||||
|
||||
@@ -23,7 +23,7 @@ last_compiled: "2026-04-17"
|
||||
|
||||
## Overview
|
||||
|
||||
Easy WMS records every significant state change as a **Transaction** — an immutable audit log entry. Transactions serve two purposes:
|
||||
Easy WMS records every significant state change as a **Transaction** - an immutable audit log entry. Transactions serve two purposes:
|
||||
1. **Audit trail**: Who did what, when, and on which objects
|
||||
2. **ERP integration trigger**: "Post-processed" transactions generate ERP messages (see [ERP Interface](erp-interface.md))
|
||||
|
||||
@@ -54,7 +54,7 @@ The **Post-processed** flag indicates whether the transaction triggers an ERP me
|
||||
|
||||
### Regeneration from SmartUI
|
||||
|
||||
The Transactions view gives an end-to-end snapshot of every action done by the WMS. When a transaction is in status **`Envoyé`** (sent) or **`Génération d'erreur`** (generation error), SmartUI allows **regenerating the ERP file** directly — any modification made to the associated BOO code since the original send will be applied to the regenerated message. This is the standard lever used to recover from a post-processing hiccup or a fixed BOO without having to provoke the functional trigger a second time.
|
||||
The Transactions view gives an end-to-end snapshot of every action done by the WMS. When a transaction is in status **`Envoyé`** (sent) or **`Génération d'erreur`** (generation error), SmartUI allows **regenerating the ERP file** directly - any modification made to the associated BOO code since the original send will be applied to the regenerated message. This is the standard lever used to recover from a post-processing hiccup or a fixed BOO without having to provoke the functional trigger a second time.
|
||||
|
||||
## Transaction Catalog
|
||||
|
||||
@@ -64,20 +64,20 @@ The Transactions view gives an end-to-end snapshot of every action done by the W
|
||||
|------|---------------|-------------|-------------|
|
||||
| `CON.ASN.001` | Yes | Container received for ASN order | ASO |
|
||||
| `CON.CNL.ASN` | Yes | Pre-notified container rejected/deleted | ASK |
|
||||
| `CON.COC` | No | Client container closed in Preparation Zone (MP) | — |
|
||||
| `CON.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.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 | — |
|
||||
| `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
|
||||
@@ -90,9 +90,9 @@ The Transactions view gives an end-to-end snapshot of every action done by the W
|
||||
|
||||
| Code | Post-processed | Description | ERP Message |
|
||||
|------|---------------|-------------|-------------|
|
||||
| `COU.CLS` | No | Count closed | — |
|
||||
| `COU.CNL` | No | Count canceled | — |
|
||||
| `COU.CST` | No | Count status changed | — |
|
||||
| `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:**
|
||||
@@ -106,26 +106,26 @@ The Transactions view gives an end-to-end snapshot of every action done by the W
|
||||
| Code | Post-processed | Description | ERP Message |
|
||||
|------|---------------|-------------|-------------|
|
||||
| `STK.ADJ` | Yes | Stock quantity adjusted (SmartUI/RF/workstation) | STV |
|
||||
| `STK.ASN` | No | Stock created in ASN container (pre-notified) | — |
|
||||
| `STK.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.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.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.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 | — |
|
||||
| `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
|
||||
@@ -161,8 +161,8 @@ The Transactions view gives an end-to-end snapshot of every action done by the W
|
||||
| Code | Post-processed | Description | ERP Message |
|
||||
|------|---------------|-------------|-------------|
|
||||
| `REC.CLS` | Yes | Receipt manually or auto-closed (with stock) | REF |
|
||||
| `REC.CNL` | No | Receipt manually canceled | — |
|
||||
| `REC.CST` | No | Receipt status changed (Pending → Receiving) | — |
|
||||
| `REC.CNL` | No | Receipt manually canceled | - |
|
||||
| `REC.CST` | No | Receipt status changed (Pending → Receiving) | - |
|
||||
|
||||
---
|
||||
|
||||
@@ -173,8 +173,8 @@ The Transactions view gives an end-to-end snapshot of every action done by the W
|
||||
| `OUT.CLS` | Yes | Shipping order closed/force-closed | SOF |
|
||||
| `OUT.CNL` | Yes | Shipping order canceled | SOF |
|
||||
| `OUT.CST` | Yes | Shipping order status changed | SOC |
|
||||
| `OUT.GRP` | No | Shipping order added to group/fusion | — |
|
||||
| `OUT.UNG` | No | Shipping order removed from group/fusion | — |
|
||||
| `OUT.GRP` | No | Shipping order added to group/fusion | - |
|
||||
| `OUT.UNG` | No | Shipping order removed from group/fusion | - |
|
||||
|
||||
---
|
||||
|
||||
@@ -182,11 +182,11 @@ The Transactions view gives an end-to-end snapshot of every action done by the W
|
||||
|
||||
| Code | Post-processed | Description | ERP Message |
|
||||
|------|---------------|-------------|-------------|
|
||||
| `ROU.CLS` | No | Route closed | — |
|
||||
| `ROU.CNL` | No | Route canceled | — |
|
||||
| `ROU.CST` | No | Route status changed | — |
|
||||
| `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 | — |
|
||||
| `LOAD.CST` | No | Load paused or reactivated | - |
|
||||
|
||||
---
|
||||
|
||||
@@ -213,7 +213,7 @@ The Transactions view gives an end-to-end snapshot of every action done by the W
|
||||
|------|---------------|-------------|-------------|
|
||||
| `WOR.CLS.001` | Yes | Work order (kits/manufacturing) closed | WOF |
|
||||
| `WOR.CNL.001` | Yes | Work order canceled | WOF |
|
||||
| `WOR.CST.001` | No | Work order status changed | — |
|
||||
| `WOR.CST.001` | No | Work order status changed | - |
|
||||
|
||||
---
|
||||
|
||||
@@ -259,7 +259,7 @@ The Transactions view gives an end-to-end snapshot of every action done by the W
|
||||
|
||||
| Code | Post-processed | Description | ERP Message |
|
||||
|------|---------------|-------------|-------------|
|
||||
| `SCR.DET` | No | Stock contrast detail (intermediate) | — |
|
||||
| `SCR.DET` | No | Stock contrast detail (intermediate) | - |
|
||||
| `SCR.REQ` | Yes | Stock contrast requested | WSC |
|
||||
| `STOCKSYNC.ASKED` | Yes | Full warehouse stock sync to ERP requested | WSC |
|
||||
|
||||
@@ -275,7 +275,7 @@ The Transactions view gives an end-to-end snapshot of every action done by the W
|
||||
|
||||
## Notification Events
|
||||
|
||||
Notification Events are operational alerts that fire when specific conditions arise. They are distinct from transactions — they do not generate ERP messages, but they can trigger SCEM subscriptions (email, SMS, web alerts).
|
||||
Notification Events are operational alerts that fire when specific conditions arise. They are distinct from transactions - they do not generate ERP messages, but they can trigger SCEM subscriptions (email, SMS, web alerts).
|
||||
|
||||
See [Supply Chain Event Management](../modules/supply-chain-event.md) for subscription management.
|
||||
|
||||
@@ -345,13 +345,13 @@ Additional notification events are defined by optional modules:
|
||||
|
||||
## Related
|
||||
|
||||
- [ERP Interface](erp-interface.md) — ERP messages triggered by post-processed transactions
|
||||
- [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
|
||||
- [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
|
||||
|
||||
@@ -61,7 +61,7 @@ Defines the physical dimensions of containers used in the warehouse. The contain
|
||||
| Gauge | Maximum deviation in width due to cargo slump (mm). Effective width = empty width + 2× gauge |
|
||||
| Shippable as package | Can be shipped directly in eCommerce process |
|
||||
|
||||
**Container relationships:** Each container type can declare interior container types — a maximum number of smaller containers that fit inside (nesting/palletizing rules). Relationships are added, deleted, or edited independently.
|
||||
**Container relationships:** Each container type can declare interior container types - a maximum number of smaller containers that fit inside (nesting/palletizing rules). Relationships are added, deleted, or edited independently.
|
||||
|
||||
**Deletion:** Cannot delete a container type in use by any location. System shows total locations affected + breakdown by warehouse before allowing deletion.
|
||||
|
||||
@@ -139,7 +139,7 @@ Editing an equipment type can cause incompatibilities in location searches or or
|
||||
|
||||
### Equipment
|
||||
|
||||
A physical means of transporting containers through the warehouse — operators with carts, forklifts, manual handling devices, etc. Equipment is associated with tasks: putaway, replenishment, picking, shipping.
|
||||
A physical means of transporting containers through the warehouse - operators with carts, forklifts, manual handling devices, etc. Equipment is associated with tasks: putaway, replenishment, picking, shipping.
|
||||
|
||||
**Attributes:**
|
||||
|
||||
@@ -241,7 +241,7 @@ Full three-dimensional representation of the warehouse:
|
||||
| Feature | Description |
|
||||
|---------|-------------|
|
||||
| General status | Locked aisles (inbound/outbound/both), AS/RS PK work modes, PIE and route status, MP preparation zones |
|
||||
| Station status | Click any station: capacity, occupation %, work mode, etc. — varies by station type |
|
||||
| Station status | Click any station: capacity, occupation %, work mode, etc. - varies by station type |
|
||||
| Shelf status | Click any shelf: free/occupied/blocked locations summary |
|
||||
| Container search | Find a specific container (LPN) by code |
|
||||
| Item search | Locate all stock of a specific item across the warehouse |
|
||||
@@ -300,8 +300,8 @@ Visual activity intensity map overlaid on 2D view:
|
||||
|
||||
## Related
|
||||
|
||||
- [[location]] — Rack types and storage zones directly configure location properties
|
||||
- [[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
|
||||
- [[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
|
||||
|
||||
+15
-15
@@ -9,7 +9,7 @@ related:
|
||||
- concepts/product-item.md
|
||||
- concepts/reception.md
|
||||
- concepts/stations.md
|
||||
- modules/pie.md
|
||||
- concepts/mechanical-elements.md
|
||||
last_compiled: "2026-04-17"
|
||||
---
|
||||
|
||||
@@ -17,7 +17,7 @@ last_compiled: "2026-04-17"
|
||||
|
||||
## Overview
|
||||
|
||||
EasyWMS tracks **five distinct weight fields** on every container and **two weight fields** on every stock line. These fields support reception sanity checks, detection of shrinkage or miscounts at the PIE (weighing station), and variable-weight items (e.g., meat, fish, fruit sold by the kilo). Understanding which field is updated by which event — and which one the shipping / reporting logic reads — is critical: the French UI term *"poids théorique"* is ambiguous (it can mean either of two different fields).
|
||||
EasyWMS tracks **five distinct weight fields** on every container and **two weight fields** on every stock line. These fields support reception sanity checks, detection of shrinkage or miscounts at the PIE (weighing station), and variable-weight items (e.g., meat, fish, fruit sold by the kilo). Understanding which field is updated by which event - and which one the shipping / reporting logic reads - is critical: the French UI term *"poids théorique"* is ambiguous (it can mean either of two different fields).
|
||||
|
||||
## Container-level weight fields
|
||||
|
||||
@@ -31,7 +31,7 @@ Five fields, each with a distinct trigger and formula.
|
||||
| **Real Weight** | Poids réel | `max(Calculated Weight, Theoretical Scale Weight)` | Recomputed automatically when its inputs change |
|
||||
| **Theoretical Scale Weight** | Poids théorique (balance) | Scale Weight − adjustments | Set after PIE pass, then updated by adjustments |
|
||||
|
||||
> ⚠️ **Translation trap** — *"Poids théorique"* in French maps to **two different fields** in English:
|
||||
> ⚠️ **Translation trap** - *"Poids théorique"* in French maps to **two different fields** in English:
|
||||
> - **Poids théorique (article)** = `Theoretical Weight` (from the item master)
|
||||
> - **Poids théorique (balance)** = `Theoretical Scale Weight` (from the scale, minus adjustments)
|
||||
>
|
||||
@@ -54,13 +54,13 @@ On each stock line (`Stock` record):
|
||||
| **Poids (kg)** | Real weight of the line |
|
||||
| **Poids théorique (kg)** | Theoretical weight of the line, from the item master |
|
||||
|
||||
Stock-line weights are updated on stock adjustments, weighings, and custom processes **only when the item is configured as variable-weight**. The PIE does **not** update stock-line weights directly — it updates container-level fields only.
|
||||
Stock-line weights are updated on stock adjustments, weighings, and custom processes **only when the item is configured as variable-weight**. The PIE does **not** update stock-line weights directly - it updates container-level fields only.
|
||||
|
||||
## Behavior at stock creation
|
||||
|
||||
- **Real weight of the stock (line)** starts at `0` — it is only populated by a PIE pass, a `StockAdjust` on a variable-weight item, or a custom.
|
||||
- **Real weight of the stock (line)** starts at `0` - it is only populated by a PIE pass, a `StockAdjust` on a variable-weight item, or a custom.
|
||||
- **Theoretical weight of the stock (line)** is computed immediately from the item master.
|
||||
- **Container tare weight** (pallet type weight in EasyS) is **frozen at container creation** — changing the tare in EasyS later **does not propagate** to existing containers. Only newly created containers pick up the new tare.
|
||||
- **Container tare weight** (pallet type weight in EasyS) is **frozen at container creation** - changing the tare in EasyS later **does not propagate** to existing containers. Only newly created containers pick up the new tare.
|
||||
|
||||
## PIE pass
|
||||
|
||||
@@ -97,11 +97,11 @@ The workflow **`Stock_CheckWeightToCreateStockInContainer_UI`** runs at stock cr
|
||||
- Compares the entered weight against the item master.
|
||||
- If the item is variable-weight and the tolerance is exceeded, it **raises an RFT alert** (does not reject).
|
||||
|
||||
> Reject-rather-than-alert behaviour at the PIE requires a custom workflow — see *Open questions* below.
|
||||
> Reject-rather-than-alert behaviour at the PIE requires a custom workflow - see *Open questions* below.
|
||||
|
||||
## Worked examples
|
||||
|
||||
### Fixed-weight item — 25 kg pallet, item weighs 250 kg
|
||||
### Fixed-weight item - 25 kg pallet, item weighs 250 kg
|
||||
|
||||
| Step | Calculated | Scale | Theoretical (item) | Real | Theoretical Scale |
|
||||
|---|---|---|---|---|---|
|
||||
@@ -114,9 +114,9 @@ The workflow **`Stock_CheckWeightToCreateStockInContainer_UI`** runs at stock cr
|
||||
|---|---|---|---|---|---|
|
||||
| New pallet | 280 | 280 | 274 | 274 | 280 |
|
||||
|
||||
> Theoretical (item) = 250 (goods) + 24 (new pallet tare). The older pallet keeps 275 — confirming that the container tare is frozen at creation.
|
||||
> Theoretical (item) = 250 (goods) + 24 (new pallet tare). The older pallet keeps 275 - confirming that the container tare is frozen at creation.
|
||||
|
||||
### Variable-weight item — 10 bags, 100 kg declared
|
||||
### Variable-weight item - 10 bags, 100 kg declared
|
||||
|
||||
| Step | Calculated | Scale | Theoretical (item) | Real | Theoretical Scale |
|
||||
|---|---|---|---|---|---|
|
||||
@@ -134,8 +134,8 @@ The workflow **`Stock_CheckWeightToCreateStockInContainer_UI`** runs at stock cr
|
||||
|
||||
## Related
|
||||
|
||||
- [[container]] — all five weight fields are attributes of the container ; see "SSCC and weights" on the container page
|
||||
- [[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
|
||||
- [[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
|
||||
|
||||
Reference in New Issue
Block a user