màj wiki avec retour MES lot-5 AD
This commit is contained in:
Arthur Ria
@@ -0,0 +1,77 @@
|
||||
---
|
||||
title: "3PL Client Portal"
|
||||
type: module
|
||||
sources:
|
||||
- areas/tpl_portal/index.md
|
||||
- areas/tpl_portal/configuration/initial_configuration.md
|
||||
related:
|
||||
- modules/billing-3pl.md
|
||||
- modules/owner-extensions.md
|
||||
- modules/supply-chain-event.md
|
||||
- concepts/account-owner.md
|
||||
- concepts/stock.md
|
||||
last_compiled: "2026-04-10"
|
||||
---
|
||||
|
||||
# 3PL Client Portal
|
||||
|
||||
## Overview
|
||||
|
||||
The 3PL Client Portal module gives external 3PL clients direct, secure, and filtered access to Easy WMS data related to their own stock and operations. Rather than relying on manual data exports from the warehouse operator, each 3PL client logs in and sees only their data — filtered by ownership — in real time.
|
||||
|
||||
**Prerequisite**: The [Owner Extensions](owner-extensions.md) module must be installed, which enforces owner-based data isolation across orders and masters.
|
||||
|
||||
## Key capabilities
|
||||
|
||||
- Filtered access: each 3PL client sees only data for stock they own
|
||||
- Real-time visibility: receipt orders, shipping orders, stock levels, KPIs
|
||||
- Client-initiated actions: create, edit, and delete elements directly in applicable views
|
||||
- Notifications: subscribe to events via email, SMS, or web interface notification
|
||||
- Reports: grouped stock reports and top-received/shipped item reports filtered by owner
|
||||
- KPIs: receipt and shipping order performance (on-time %, stock information)
|
||||
- User group management: each 3PL client has their own user group with controlled access scope
|
||||
|
||||
## Architecture
|
||||
|
||||
### Access model
|
||||
The 3PL manager creates specific user groups per 3PL client. Users in these groups have:
|
||||
- Filtered view of all data (only their owner's records shown)
|
||||
- Selected actions (create/edit/delete where applicable)
|
||||
- Read-only access to sensitive operational data
|
||||
|
||||
### Available data (filtered by owner)
|
||||
- Receipt orders (inbound)
|
||||
- Shipping orders (outbound)
|
||||
- Stock levels (all stock views)
|
||||
- Billing data (via Billing module)
|
||||
- Notification subscriptions
|
||||
|
||||
## Configuration
|
||||
|
||||
### Basic portal access setup
|
||||
1. Install Owner Extensions module
|
||||
2. Create 3PL client organizations as owners in Easy WMS
|
||||
3. Create user groups per 3PL client (Organization > User groups)
|
||||
4. Assign views and actions available to each group
|
||||
5. Create client users and assign to groups
|
||||
6. Configure notifications (Supply Chain Event Management) for client organizations
|
||||
|
||||
### Notification setup
|
||||
3PL client users can subscribe to notifications about their operations through [Supply Chain Event Management](supply-chain-event.md). Notifications sent in the user's configured language (fallback: organization language).
|
||||
|
||||
## Operations
|
||||
|
||||
### Client user interface
|
||||
- Login with 3PL-specific credentials
|
||||
- All views automatically filtered to own stock/orders
|
||||
- Available views depend on group permissions configured by 3PL manager
|
||||
- Reports: Grouped stock, top received/shipped items (owner-filtered)
|
||||
- KPIs: Order completion rates, on-time receipt/shipping percentages
|
||||
|
||||
## Related
|
||||
|
||||
- [[billing-3pl]] — Clients can view their billing data through the portal
|
||||
- [[owner-extensions]] — Prerequisite; enforces data isolation that the portal relies on
|
||||
- [[supply-chain-event]] — Notification infrastructure for sending alerts to 3PL client users
|
||||
- [[account-owner]] — Owner entities are the 3PL clients with portal access
|
||||
- [[stock]] — Stock views available to clients show only their owned stock
|
||||
@@ -0,0 +1,285 @@
|
||||
---
|
||||
title: "AGV — Automated Guided Vehicles"
|
||||
type: module
|
||||
sources:
|
||||
- areas/agvs/index.md
|
||||
- areas/agvs/agv.md
|
||||
- areas/agvs/monitoring/monitoring.md
|
||||
- areas/agvs/monitoring/agv_tasks.md
|
||||
- areas/agvs/monitoring/status_messages.md
|
||||
- areas/agvs/monitoring/cancel_order.md
|
||||
- areas/agvs/monitoring/terminate_order.md
|
||||
- areas/agvs/monitoring/export_messages.md
|
||||
- areas/agvs/monitoring/import_messages.md
|
||||
- areas/agvs/manage_errors/manage_errors.md
|
||||
- areas/agvs/manage_errors/communication_errors.md
|
||||
- areas/agvs/manage_errors/configuration_errors.md
|
||||
- areas/agvs/manage_errors/execution_errors.md
|
||||
- areas/agvs/manage_errors/extraction_error.md
|
||||
- areas/agvs/manage_errors/putaway_error.md
|
||||
- areas/agvs/manage_errors/locktype.md
|
||||
- areas/agvs/manage_errors/trf_movements.md
|
||||
- areas/agvs/configuration/initial_configuration.md
|
||||
- areas/agvs/notificationevents.md
|
||||
- areas/agvs/views/agv_stations_view.md
|
||||
- areas/agvs/views/agv_tasks_view.md
|
||||
- areas/agvs/views/agv_export_view.md
|
||||
- areas/agvs/views/agv_import_view.md
|
||||
- areas/agvs/views/agv_status_view.md
|
||||
- sources/archives/Présentation Module AGV.md
|
||||
- sources/archives/Documentation Module AGV.md
|
||||
related:
|
||||
- modules/pallet-shuttle.md
|
||||
- concepts/task.md
|
||||
- concepts/location.md
|
||||
- concepts/container.md
|
||||
- concepts/stations.md
|
||||
- operations/agv-installation.md
|
||||
last_compiled: "2026-05-15"
|
||||
---
|
||||
|
||||
# AGV — Automated Guided Vehicles
|
||||
|
||||
## Overview
|
||||
|
||||
An Automated Guided Vehicle (AGV) is a warehouse transport machine similar to a forklift truck that moves automatically along pre-planned paths. AGVs integrate with Easy WMS to execute container transport tasks autonomously, eliminating the need for human operators on repetitive movement routes.
|
||||
|
||||
AGVs are created and configured in EasyS or EasyAssistant as station-type elements, assigned to an AGV equipment group. Easy WMS communicates with the AGV system through a database-table-based messaging interface, sending transport orders and receiving execution confirmations. AGVs dramatically improve throughput in automatic warehouses by handling putaway, replenishment, shipping preparation, and cross-location transfers continuously.
|
||||
|
||||
The AGV module also supports [Pallet Shuttle](pallet-shuttle.md) movements — AGVs can transport pallet shuttle carts between compact rack channels, eliminating the need for manual forklift intervention.
|
||||
|
||||
## Key capabilities
|
||||
|
||||
- Autonomous container movements: floor → inbound conveyor (PIE), conveyor → storage, storage → stage/dock, storage → storage, AGV → storage
|
||||
- Pallet shuttle transport: move PS carts between compact rack channels (with electromagnet attachment)
|
||||
- Task prioritization: urgent orders are assigned first; priority can be modified before AGV assignment
|
||||
- RFT fallback: when AGVs are unavailable, operators can execute AGV tasks manually via radio frequency terminal
|
||||
- Order cancellation and relocation: if an order is canceled mid-execution, Easy WMS searches for a valid putaway location for any loaded container
|
||||
- Full message exchange monitoring: export (WMS→AGV) and import (AGV→WMS) message queues are visible and auditable
|
||||
|
||||
## Architecture
|
||||
|
||||
### System components
|
||||
|
||||
The AGV module relies on a four-component architecture where Easy WMS and the fleet manager never communicate directly. All exchanges go through an intermediary PostgreSQL database:
|
||||
|
||||
```
|
||||
┌─────────────────┐
|
||||
│ Easy WMS │ Workflows generate AGV tasks when a movement
|
||||
│ (IIS App + │ traverses a route assigned to an AGV station
|
||||
│ Oracle DB) │ (station type 65, configured in EasyS).
|
||||
└────────┬─────────┘
|
||||
│ AGV workflows
|
||||
▼
|
||||
┌─────────────────┐
|
||||
│ Gateway AGV │ Windows service polling the exchange tables.
|
||||
│ (service) │ Serializes WMS tasks → agv_outputqueue/agv_eag
|
||||
│ │ Reads fleet responses → agv_inputqueue/agv_age/agv_ags
|
||||
└────────┬─────────┘
|
||||
│ DBLink Oracle → PostgreSQL (dg4odbc + ODBC)
|
||||
▼
|
||||
┌─────────────────┐
|
||||
│ PostgreSQL DB │ Intermediary database hosting 5 exchange tables.
|
||||
│ (AGV schema) │ Accessed by WMS via Oracle synonyms and by
|
||||
│ │ the fleet manager directly or via middleware.
|
||||
└────────┬─────────┘
|
||||
│ Direct SQL or middleware adapter
|
||||
▼
|
||||
┌─────────────────┐
|
||||
│ Fleet manager │ External software controlling the physical
|
||||
│ (iGO, Rocla, │ vehicles. Vendor-agnostic: any system that
|
||||
│ MAP, etc.) │ can read/write the 5 tables is compatible.
|
||||
└─────────────────┘
|
||||
```
|
||||
|
||||
The AGV module is **fleet-manager agnostic**. The exchange protocol relies on 5 intermediary tables in PostgreSQL. Any fleet manager able to read and write these tables - directly or through a middleware adapter - can be integrated without modifying Easy WMS workflows, the Gateway, or the monitoring views.
|
||||
|
||||
### Exchange tables
|
||||
|
||||
The intermediary PostgreSQL database contains 5 functional tables plus sequences and a migration tracking table. The Gateway AGV creates them automatically on first startup.
|
||||
|
||||
| Table | Direction | Purpose |
|
||||
|-------|-----------|---------|
|
||||
| `agv_outputqueue` | WMS → Fleet manager | Output queue - transport orders emitted by WMS (create, update, cancel) |
|
||||
| `agv_eag` | WMS → Fleet manager | Order detail - requested operation (Create/Update/Delete) and transport parameters |
|
||||
| `agv_inputqueue` | Fleet manager → WMS | Input queue - responses and events from the fleet manager |
|
||||
| `agv_age` | Fleet manager → WMS | Transport events - phase changes (accepted, vehicle assigned, loaded, unloaded, canceled) |
|
||||
| `agv_ags` | Fleet manager → WMS | Vehicle status events - AGV state (ready, breakdown, charging, low battery) |
|
||||
|
||||
The Gateway AGV writes to `agv_outputqueue` / `agv_eag` and reads `agv_inputqueue` / `agv_age` / `agv_ags`. The fleet manager (or its middleware) does the reverse.
|
||||
|
||||
### Gateway AGV
|
||||
|
||||
The Gateway AGV is a Windows service provided by Mecalux. It bridges the internal Easy WMS workflows with the PostgreSQL exchange tables. Its responsibilities include: serializing AGV tasks created by workflows into `agv_outputqueue` / `agv_eag`, reading inbound events from `agv_inputqueue` / `agv_age` / `agv_ags` and injecting them into the workflow engine, and managing polling cycles (configurable frequency, typically 1 second via `inputCycleDelay` / `outputCycleDelay`).
|
||||
|
||||
Configuration resides in an XML file under `C:\ProgramData\Mecalux\EasyWMS GatewayAGV 2015\`. Key parameters: `connectionString` (PostgreSQL connection), `stationType` (65 for AGV), `stationNumber`, `warehouseNumber`, `commitLimit`, `hoursToExecute`, `daysToSave`. The file must contain exactly one `<AGVConfig>` section - multiple sections cause a startup crash.
|
||||
|
||||
### DBLink Oracle → PostgreSQL
|
||||
|
||||
Easy WMS runs on Oracle. To allow workflows to read and write the PostgreSQL exchange tables, a DBLink is configured using the Oracle component **dg4odbc** (Database Gateway for ODBC). Oracle synonyms are created in the `db_read` schema so that PostgreSQL tables appear as local Oracle tables.
|
||||
|
||||
This DBLink is the most delicate component of the installation - it touches 5 Oracle configuration files (tnsnames.ora, listener.ora, initPostgreSQL35W.ora, the ODBC System DSN, and the CREATE DATABASE LINK statement) and requires strict consistency on names and case sensitivity. See [AGV Installation Guide](../operations/agv-installation.md) for the step-by-step procedure.
|
||||
|
||||
### Communication protocol
|
||||
|
||||
Easy WMS and the AGV system exchange messages via **database tables** (not REST or direct API calls). The standard execution flow for a transport order:
|
||||
|
||||
| Phase | Direction | Meaning |
|
||||
|-------|-----------|---------|
|
||||
| WMS sends order | WMS → AGV | Transport order request created |
|
||||
| `00` | AGV → WMS | Order accepted |
|
||||
| `03` | AGV → WMS | Vehicle assigned |
|
||||
| `04` | AGV → WMS | Load permission request (if `Can Pick` = false) |
|
||||
| WMS sends load auth | WMS → AGV | Load authorization with AGV assignment |
|
||||
| `06` | AGV → WMS | Load confirmed |
|
||||
| `08` | AGV → WMS | Unload permission request (if `Can Drop` = false) |
|
||||
| WMS sends unload auth | WMS → AGV | Unload authorization |
|
||||
| `10` | AGV → WMS | Unload confirmed — order complete |
|
||||
| `255` | AGV → WMS | Order canceled by AGV |
|
||||
|
||||
### AGV station attributes
|
||||
|
||||
| Field | Description |
|
||||
|-------|-------------|
|
||||
| Code | Unique AGV station identifier |
|
||||
| Control status | Current status: available, breakdown, loading, etc. |
|
||||
| Number | Unique per station type per warehouse |
|
||||
| Brand / Model | AGV hardware identification |
|
||||
|
||||
### AGV task attributes (key fields)
|
||||
|
||||
| Field | Description |
|
||||
|-------|-------------|
|
||||
| Task number | WMS-generated unique order number |
|
||||
| Load type | `0` = Container, `1` = Pallet Shuttle |
|
||||
| Load location / Unload location | WMS station code or location |
|
||||
| Can pick / Can drop | Whether AGV system must request load/unload permission from WMS |
|
||||
| Load aisle / Unload aisle | Mandatory in FIFO compact racks; optional in LIFO |
|
||||
| Priority | Execution priority — most urgent tasks dispatched first |
|
||||
| Previous task | Chained task dependency |
|
||||
|
||||
## Configuration
|
||||
|
||||
### Initial setup (minimum required)
|
||||
1. Configure warehouse layout in EasyS or EasyAssistant:
|
||||
- Create a warehouse station linked to an **AGV equipment group**
|
||||
- Add at least one AGV in the group
|
||||
- Configure **routes** from the AGV station to all allowed movement locations
|
||||
2. Valid location types for AGV movements: conventional rack, compact (single/multi), dynamic, pushback, cantilever, stage, dock, PIE (inbound conveyor), ET (deposit/loading conveyor)
|
||||
3. Locations that allow AGV movements must have a **manual loading aisle** configured
|
||||
4. Optionally enable/disable the `Allow loading` and `Allow unloading` flags per location — when disabled, the AGV system requests permission from WMS before proceeding
|
||||
|
||||
### Lock type for AGV errors
|
||||
A dedicated **location lock type** with the **"For AGV"** flag must be created to manage extraction/putaway errors on non-conventional or non-APS storage locations. Only one such lock type can exist per warehouse. Configure from: **Masters > Lock types > Location lock types** via `Mark for AGV` / `Unmark for AGV` actions.
|
||||
|
||||
## Operations
|
||||
|
||||
### Monitoring (PC — AGVs menu)
|
||||
|
||||
| View | Purpose |
|
||||
|------|---------|
|
||||
| AGV Stations | List of registered AGVs with control status |
|
||||
| AGV Tasks | All transport orders with status, priority, load/unload locations |
|
||||
| Export Messages | Messages sent by WMS to AGV system (order creation, update, cancel, auth) |
|
||||
| Import Messages | Messages received from AGV system (phases 00/03/04/06/08/10/255) |
|
||||
| Status Messages | AGV status updates: Ready (green), Failure (red), Waiting (gray), Low battery (yellow), Charging (blue) |
|
||||
|
||||
### Task lifecycle management
|
||||
- **Cancel task**: available in Tasks view (Warehouse menu). Two scenarios: (1) AGV not yet loaded → order removed from queue and AGV system notified; (2) AGV has container loaded → WMS searches for valid putaway location using configured strategies; if none found, user notified for manual action
|
||||
- **Finish task manually**: available when AGV is blocked (e.g., physical obstacle). User confirms the unload location manually.
|
||||
|
||||
### RFT fallback (AGV Movements menu on RFT)
|
||||
When AGVs are unavailable, operators use the "AGV Movements" option on RFT. Tasks can be filtered by zone. Order selection follows picking process: confirm container at load location, confirm unload location. Issue types during RFT execution:
|
||||
- **Loading issues**: Container not found (→ Lost & Found), Mark for review (→ creates count for location)
|
||||
- **Unloading issues**: Mark for review (→ count created, enter alternate unload location), Mark as full (blocks location), Other location (change unload destination)
|
||||
|
||||
## Errors & troubleshooting
|
||||
|
||||
### Error categories
|
||||
|
||||
| Category | Description |
|
||||
|----------|-------------|
|
||||
| Configuration errors | Incorrect load/unload station, duplicate order ID, invalid operation type, unload station modification after phase 03, priority modification after assignment |
|
||||
| Execution errors | Extraction error (no container at pickup), putaway error (destination occupied), container mismatch, no valid relocation found |
|
||||
| Communication errors | Failures sending order (2500), priority update (2501), cancellation (2502), destination change (2503) |
|
||||
|
||||
### Extraction error behavior
|
||||
- **Conventional rack / APS locations**: Task canceled; location marked with "Mark for review" lock type
|
||||
- **Other storage locations**: Task canceled; location marked with "For AGV" lock type
|
||||
- **Non-storage locations (stage/dock)**: Task NOT canceled; AGV held pending manual action; user notified
|
||||
|
||||
### Putaway error behavior
|
||||
- **Conventional rack / APS locations**: WMS searches for a relocation; location marked with "Mark for review" lock type
|
||||
- **Other storage locations**: WMS searches for relocation; location marked with "For AGV" lock type
|
||||
- **Non-storage locations**: AGV held pending manual action; user notified
|
||||
|
||||
### All notification events subscribe under the **AGV** notification group. Severity: Error for all. Subscribable by: SuperAdmin, Administrators, Managers.
|
||||
|
||||
| Code | Error |
|
||||
|------|-------|
|
||||
| 1001 | Incorrect load station |
|
||||
| 1002 | Incorrect unload station |
|
||||
| 1003 | Duplicate transport order |
|
||||
| 1004 | Invalid operation type |
|
||||
| 1010 | Unload station modification error (phase 03+) |
|
||||
| 1011 | Priority modification error (after assignment) |
|
||||
| 1012 | Inactive transport order |
|
||||
| 1013 | Null task number |
|
||||
| 1014 | Inconsistent AGV movement (e.g., unload when not loaded) |
|
||||
| 2003 | Extraction error at non-storage location |
|
||||
| 2004 | Putaway error at non-storage location |
|
||||
| 2005 | Manual cancellation from AGV interface |
|
||||
| 2500–2503 | Communication errors (order/priority/cancel/destination) |
|
||||
|
||||
## Fleet manager integration
|
||||
|
||||
### Standard protocol (direct SQL)
|
||||
|
||||
The default integration method assumes the fleet manager (or a middleware adapter) reads and writes directly in the PostgreSQL exchange tables. This is the simplest approach and requires no additional component beyond the Gateway AGV and the PostgreSQL database.
|
||||
|
||||
### REST-based fleet managers (middleware pattern)
|
||||
|
||||
Some fleet managers do not read/write SQL tables directly and instead expose a REST API. This is the case for **iGO easy** (STILL / KION Group). To integrate such systems without modifying Easy WMS workflows or the Gateway, a **middleware** is inserted between the exchange tables and the fleet manager API:
|
||||
|
||||
```
|
||||
EasyWMS → Gateway AGV → Tables AGV_* → Middleware → Fleet manager REST API
|
||||
← (webhooks) ←
|
||||
```
|
||||
|
||||
The middleware performs two functions: an **outbound pump** (polls `agv_outputqueue`, reads orders from `agv_eag`, translates them into REST calls to the fleet manager API) and a **webhook receiver** (receives callbacks from the fleet manager on transport/vehicle state changes, translates them into rows in `agv_inputqueue` / `agv_age` / `agv_ags`).
|
||||
|
||||
This architecture preserves full compatibility: workflows, Gateway, monitoring views, and RFT fallback all work identically to the standard protocol.
|
||||
|
||||
### Concept mapping (EasyWMS ↔ fleet manager)
|
||||
|
||||
| Easy WMS concept | Typical fleet manager equivalent |
|
||||
|------------------|----------------------------------|
|
||||
| AGV Task (AgvTask) | Transport |
|
||||
| AGV Station (type 65) | Vehicle |
|
||||
| Container / LPN | Load |
|
||||
| Location | Location / Position |
|
||||
| Working zone | Group (enables late-decision routing) |
|
||||
| Load type | LoadType |
|
||||
|
||||
The **Group** concept on the fleet manager side enables "late decision" routing: the WMS creates a transport toward a group of destinations, and the fleet manager requests the final destination when the vehicle reaches a decision point. This reproduces the CanPick/CanDrop authorization phases (04/08) through a different mechanism.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
| Element | Requirement |
|
||||
|---------|-------------|
|
||||
| Easy WMS binaries | Version **18.10.22154.1** minimum |
|
||||
| PostgreSQL | Version >= 14 |
|
||||
| PostgreSQL ODBC driver | psqlodbc x64 |
|
||||
| Oracle | DBLink dg4odbc configured on `db_read` schema |
|
||||
| Network | PostgreSQL port open (5432 default, 5433 if PostgreSQL 18+) |
|
||||
|
||||
For the complete installation procedure, see [AGV Installation Guide](../operations/agv-installation.md).
|
||||
|
||||
## Related
|
||||
|
||||
- [Pallet Shuttle](pallet-shuttle.md) — AGVs transport PS carts between compact rack channels; battery management automated via AGV
|
||||
- [Task](../concepts/task.md) — AGV orders appear as tasks in the warehouse task system
|
||||
- [Location](../concepts/location.md) — Location types compatible with AGV movements; lock types configuration
|
||||
- [Container](../concepts/container.md) — Containers are the primary payload of AGV transport orders
|
||||
- [Stations](../concepts/stations.md) — AGV stations (type code: AGV), routes, fleet manager integration
|
||||
- [AGV Installation Guide](../operations/agv-installation.md) — Step-by-step installation: PostgreSQL, ODBC, DBLink dg4odbc, Gateway, module deploy, troubleshooting
|
||||
@@ -0,0 +1,113 @@
|
||||
---
|
||||
title: "APS3D (Automatic Pallet Shuttle 3D)"
|
||||
type: module
|
||||
sources:
|
||||
- areas/aps3d/index.md
|
||||
related:
|
||||
- modules/agv.md
|
||||
- concepts/location.md
|
||||
- concepts/task.md
|
||||
- concepts/defragmentation.md
|
||||
- concepts/stations.md
|
||||
- concepts/parameters.md
|
||||
last_compiled: "2026-04-10"
|
||||
---
|
||||
|
||||
# APS3D (Automatic Pallet Shuttle 3D)
|
||||
|
||||
## Overview
|
||||
|
||||
APS3D is a fully automated multi-level warehouse system where mobile carts (shuttles) move throughout the warehouse autonomously to handle container movements. Unlike standard Pallet Shuttle (which uses a single cart per channel), APS3D carts can traverse all aisles of a level (loaded or empty, via passage channels) and change levels via lifts.
|
||||
|
||||
The carts are directed by a **Fleet Manager** — a centralized controller that receives orders from Easy WMS, assigns them to specific carts, manages traffic, and reports order completion. Locations are of type **APS** or **APSFIFO** for maximum space utilization.
|
||||
|
||||
## Key capabilities
|
||||
|
||||
- Fully automated 3D container movement: carts traverse horizontal aisles and change levels via lifts
|
||||
- Fleet Manager integration: central controller managing all cart orders and traffic
|
||||
- LIFO and FIFO channel modes (APS and APSFIFO location types)
|
||||
- Multiple operational modes for the Fleet Manager
|
||||
- Order sequencing: configurable sequence levels for multi-level execution
|
||||
- Channel compaction: push containers together within a channel to maximize capacity
|
||||
- Defragmentation: rotation-based and shipping-based defragmentation across channels
|
||||
- Aisle balancing: distribute container load evenly across aisles
|
||||
- Error management: extraction and putaway errors with automated recovery
|
||||
- Order cancellation and container relocation
|
||||
- Pending movement accumulation management
|
||||
- Depth confirmation: operator confirms depth for origin/destination
|
||||
- Passage channel requests: request free channels for aisle changes
|
||||
|
||||
## Architecture
|
||||
|
||||
### System components
|
||||
|
||||
| Component | Description |
|
||||
|-----------|-------------|
|
||||
| APS3D carts | Mobile shuttles that carry containers horizontally through aisles and vertically via lifts |
|
||||
| Fleet Manager | External controller; receives orders from Easy WMS, assigns to carts, manages traffic, reports completion |
|
||||
| Lifts | Allow carts to change warehouse levels |
|
||||
| APS / APSFIFO locations | High-density storage channels for compact 3D storage |
|
||||
| Passage channels | Empty channels used as transit paths for carts changing aisles |
|
||||
|
||||
### Fleet Manager work modes
|
||||
The Fleet Manager can operate in different modes that affect how orders are processed and assigned to carts. Mode changes are initiated from the Easy WMS interface.
|
||||
|
||||
### Order flow
|
||||
1. Easy WMS generates a container movement task (putaway, extraction, replenishment, etc.)
|
||||
2. Easy WMS sends order to Fleet Manager
|
||||
3. Fleet Manager assigns available cart
|
||||
4. Cart executes movement (horizontal + vertical if level change required)
|
||||
5. Fleet Manager reports completion to Easy WMS
|
||||
6. Easy WMS confirms task completion
|
||||
|
||||
### APS vs APSFIFO locations
|
||||
- **APS**: standard compact channel, LIFO access
|
||||
- **APSFIFO**: FIFO channels for first-in-first-out extraction requirements
|
||||
|
||||
## Configuration
|
||||
|
||||
### Prerequisites
|
||||
1. Configure APS/APSFIFO locations in EasyS/EasyAssistant
|
||||
2. Configure Fleet Manager connection (IP, credentials)
|
||||
3. Configure lifts and passage channels
|
||||
4. Set APS3D parameters:
|
||||
|
||||
| Parameter | Description |
|
||||
|-----------|-------------|
|
||||
| (Various) | APS3D has a dedicated parameter section in Easy WMS parameters (areas/aps3d/parameters.md) |
|
||||
|
||||
### Warehouse layout
|
||||
- Each aisle has defined locations (APS or APSFIFO) at each depth
|
||||
- Passage channels designated per level for cart transit
|
||||
- Lift stations defined for level changes
|
||||
|
||||
## Operations
|
||||
|
||||
### Order management
|
||||
All container movements (inbound putaway, outbound extraction, replenishment, internal transfer) are managed through the Fleet Manager. Easy WMS generates tasks → Fleet Manager executes via carts.
|
||||
|
||||
### Defragmentation
|
||||
Three modes specific to APS3D:
|
||||
- **Channel compaction**: pushes containers within a channel toward the extraction end
|
||||
- **Cross-channel defragmentation**: moves containers between channels for optimization
|
||||
- **Rotation defragmentation**: reassigns containers by ABC rotation across channels
|
||||
- **Shipping defragmentation**: pre-positions containers toward extraction for pending shipments
|
||||
|
||||
### Aisle balancing
|
||||
Distributes container inventory evenly across aisles to prevent hotspots and optimize cart utilization.
|
||||
|
||||
### Error management
|
||||
- **Extraction error**: no container at pickup location → task managed per location type (APS: cancel + lock; other: hold pending manual)
|
||||
- **Putaway error**: destination occupied → Easy WMS searches for alternate location; locks original destination
|
||||
|
||||
### Depth confirmation
|
||||
When the system cannot determine exact depth for origin or destination, an operator confirms the channel depth through the web interface before the order proceeds.
|
||||
|
||||
## Related
|
||||
|
||||
- [[agv]] — AGV module handles container transport to/from APS3D entry points; APS3D carts handle internal channel movements
|
||||
- [[location]] — APS and APSFIFO location types are specific to APS3D; standard APS locations also used in manual pallet shuttle
|
||||
- [[task]] — APS3D movements generate WMS tasks managed through Fleet Manager
|
||||
- [[defragmentation]] — APS3D has its own defragmentation strategies (rotation, shipping, cross-channel)
|
||||
- [[stations]] — Fleet Manager is a special station type in the warehouse layout
|
||||
- [[parameters]] — APS3D has a dedicated parameter section including `aps3d/parameters.md`
|
||||
@@ -0,0 +1,143 @@
|
||||
---
|
||||
title: "Automation Dashboard (Faults Management)"
|
||||
type: module
|
||||
sources:
|
||||
- areas/faults_management/index.md
|
||||
- areas/faults_management/faults_faults/faults_reports.md
|
||||
- areas/faults_management/faults_faults/faults_historical_data.md
|
||||
- areas/faults_management/faults_actions/index.md
|
||||
- areas/faults_management/faults_actions/actions_historical_data.md
|
||||
- areas/faults_management/faults_actions/actions_notifications.md
|
||||
- areas/faults_management/faults_actions/actions_reports.md
|
||||
- sources/archives/Automation_Dashboard.md
|
||||
- sources/archives/Erreurs_Defauts_GALILEO.md
|
||||
related:
|
||||
- modules/agv.md
|
||||
- modules/aps3d.md
|
||||
- concepts/task.md
|
||||
- concepts/stations.md
|
||||
- architecture/galileo-integration.md
|
||||
- operations/galileo-troubleshooting.md
|
||||
last_compiled: "2026-04-17"
|
||||
---
|
||||
|
||||
# Automation Dashboard (Faults Management)
|
||||
|
||||
## Overview
|
||||
|
||||
The Automation Dashboard module (sourced from the `faults_management` area) provides supervision and management of faults and manual interventions in automatic warehouse machines. When machines in an automatic warehouse encounter errors, they shut down automatically (for safety) and notify the system of the fault. This module tracks these faults, their resolution, and all manual interventions performed by operators.
|
||||
|
||||
The module ensures complete traceability of machine status and problems, enabling supervisors to respond quickly and maintain audit trails.
|
||||
|
||||
**Note**: The `areas/automation_dashboard/` folder returns 404 — the Automation Dashboard functionality is implemented in `areas/faults_management/`.
|
||||
|
||||
## Key capabilities
|
||||
|
||||
- Automatic fault recording: faults registered automatically with start/end date, affected machine, description, possible causes, and resolution suggestions
|
||||
- Manual action recording: logs all manual interventions (manual moves, data alterations) by user, date, machine, and auxiliary data
|
||||
- External WMS history: centralized view of movement history for automatic warehouses using external WMS (no Easy WMS installed), communicating through Easy WCS
|
||||
- Fault reports: machine ranking, availability metrics, warehouse availability, zone availability, fault frequency analysis
|
||||
- Action reports: top frequent actions by machine, user, general; usage time reports
|
||||
- Notification support: alerts for fault events
|
||||
- Technical information available in Documents and Downloads section
|
||||
|
||||
## Architecture
|
||||
|
||||
### Data tracked
|
||||
|
||||
**Faults**:
|
||||
- Machine affected
|
||||
- Start date/time
|
||||
- End date/time (when fault resolved)
|
||||
- Description of fault
|
||||
- Possible causes
|
||||
- Resolution suggestions
|
||||
|
||||
**Manual actions**:
|
||||
- User performing action
|
||||
- Date/time
|
||||
- Machine affected
|
||||
- Action type (manual movement, task data alteration, etc.)
|
||||
- Auxiliary data (additional context)
|
||||
|
||||
### Report types
|
||||
|
||||
**Fault reports**:
|
||||
| Report | Content |
|
||||
|--------|---------|
|
||||
| Historical data | Full fault log with timeline |
|
||||
| Machine ranking | Machines ranked by fault frequency |
|
||||
| Machine unavailability | Downtime periods per machine |
|
||||
| All machines availability | Overall availability across machines |
|
||||
| Warehouse availability | Combined availability metric for the warehouse |
|
||||
| Zone availability (all/one) | Availability by warehouse zone |
|
||||
| Warehouse fault frequency | Fault rate over time |
|
||||
| Warehouse ranking | Ranking by total downtime impact |
|
||||
|
||||
**Action reports**:
|
||||
| Report | Content |
|
||||
|--------|---------|
|
||||
| Historical data | Full action log with timeline |
|
||||
| Top frequent by machine | Most common actions per machine |
|
||||
| Top frequent by user | Most common actions per operator |
|
||||
| Top frequent (general) | Top actions across all machines and users |
|
||||
| Usage times | Time spent on manual actions per category |
|
||||
|
||||
### Notification events
|
||||
The module triggers notifications for fault events. Subscribable through Supply Chain Event Management by supervisors and managers.
|
||||
|
||||
## Configuration
|
||||
|
||||
### Prerequisites
|
||||
- Automatic warehouse equipment (conveyors, sorters, AGVs, APS3D) with Easy WCS or direct Easy WMS integration
|
||||
- Machine station records in WMS matching physical equipment
|
||||
- User permissions configured for manual intervention actions
|
||||
|
||||
### External WMS integration
|
||||
For automatic warehouses using an external WMS (not Easy WMS) communicating with Easy WCS, the Automation Dashboard can still display movement history centrally by receiving data from Easy WCS.
|
||||
|
||||
## Operations
|
||||
|
||||
### Fault resolution workflow
|
||||
1. Machine encounters error → automatic shutdown
|
||||
2. Easy WCS/WMS receives fault notification → fault record created
|
||||
3. Supervisor receives notification (SCEM)
|
||||
4. Supervisor reviews fault details (description, possible cause, suggestions)
|
||||
5. Authorized user performs manual intervention to resolve cause
|
||||
6. Manual action logged automatically
|
||||
7. Machine re-enabled; fault record updated with end date
|
||||
|
||||
### Supervision view
|
||||
- Real-time fault status per machine
|
||||
- Historical fault log with filtering by date, machine, zone
|
||||
- Drill-down from warehouse → zone → machine → specific fault
|
||||
|
||||
## GALILEO Fault Codes (common)
|
||||
|
||||
Faults most often seen on miniload installations. Use this table to triage before opening an escalation. Full troubleshooting procedure: [Galileo Troubleshooting](../operations/galileo-troubleshooting.md).
|
||||
|
||||
| Code | Name | Typical cause |
|
||||
|------|------|---------------|
|
||||
| **1116** | Incorrect task CU1 | Location locked on GALILEO but not on EasyWMS (or vice versa); location exists in EasyWMS but not in GALILEO; same location has different allowed container types on each side; deposit asked on left rack while container is on right fork |
|
||||
| **1201** | Variator fault X | Variator hardware fault on axis X |
|
||||
| **1291** | Unreferenced SM302 card on the variator | Warning only |
|
||||
|
||||
Fault 1116 is the configuration-drift counterpart of `EndErrorCode=4` seen in Gateway logs — same root cause, different reporting surface.
|
||||
|
||||
## Reference reports
|
||||
|
||||
Standard Automation Dashboard reports delivered by Mecalux (documents on [Confluence — Automation Dashboard](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3001220136988)):
|
||||
|
||||
- Module presentation
|
||||
- Machine availability report (per machine)
|
||||
- Installation availability report (aggregate)
|
||||
- "Galileo fault" report (detail by fault code)
|
||||
|
||||
## Related
|
||||
|
||||
- [[agv]] — AGV machine faults and manual actions are tracked in the Automation Dashboard
|
||||
- [[aps3d]] — APS3D Fleet Manager and cart faults tracked for traceability
|
||||
- [[task]] — Manual task completions and modifications logged as actions
|
||||
- [[stations]] — Machine stations are the physical entities tracked in the dashboard
|
||||
- [GALILEO Integration](../architecture/galileo-integration.md) — protocol layer that produces many of the faults tracked here
|
||||
- [Galileo Troubleshooting](../operations/galileo-troubleshooting.md) — log-level diagnosis
|
||||
@@ -0,0 +1,215 @@
|
||||
---
|
||||
title: "3PL Billing"
|
||||
type: module
|
||||
sources:
|
||||
- areas/billing/index.md
|
||||
- areas/billing/billing_configuration/index.md
|
||||
- areas/billing/billing_configuration/contracts.md
|
||||
- areas/billing/billing_configuration/planners.md
|
||||
- areas/billing/billing_configuration/rules_documentation.md
|
||||
- areas/billing/billing_configuration/rules_handling_container.md
|
||||
- areas/billing/billing_configuration/rules_handling_filters.md
|
||||
- areas/billing/billing_configuration/rules_handling_uom.md
|
||||
- areas/billing/billing_configuration/rules_handling_volume.md
|
||||
- areas/billing/billing_configuration/rules_handling_weight.md
|
||||
- areas/billing/billing_bills/index.md
|
||||
- areas/billing/billing_bills/bills.md
|
||||
- areas/billing/billing_bills/billing_reports.md
|
||||
- areas/3pl_billing/index.md
|
||||
- areas/3pl_client_portal/index.md
|
||||
related:
|
||||
- modules/3pl-portal.md
|
||||
- modules/owner-extensions.md
|
||||
- concepts/account-owner.md
|
||||
- concepts/stock.md
|
||||
- concepts/order-outbound.md
|
||||
- concepts/order-inbound.md
|
||||
last_compiled: "2026-04-26"
|
||||
---
|
||||
|
||||
# 3PL Billing
|
||||
|
||||
## Overview
|
||||
|
||||
The 3PL Billing module identifies, quantifies, records, and consolidates data from logistical activities in the warehouse for billing purposes. It is primarily designed for 3PL (Third-Party Logistics) operators who need to invoice each client (owner) individually based on the warehouse services consumed.
|
||||
|
||||
**Prerequisite**: The [Owner Extensions](owner-extensions.md) module must be installed. This adds the mandatory owner field to receipt and shipping orders and restricts mixing items from different owners in the same order.
|
||||
|
||||
**Scope limitation**: By default, the module only counts data from Easy WMS activities. Activities from other modules (Manufacturing container consumption, Yard Management transport documents) are excluded unless custom rules are configured.
|
||||
|
||||
## Key capabilities
|
||||
|
||||
- Configurable billing rules for all standard logistics activities (storage, handling, inbound, outbound, packing, etc.)
|
||||
- Custom rules based on transactions for non-standard activities
|
||||
- Contract-based billing: one contract per owner, specifying rules + planner + validity period
|
||||
- Economic valuation: optional currency-based pricing with unit costs or percentage (for stock value rules)
|
||||
- Tiered pricing: volume discount/surcharge ranges per rule
|
||||
- Bill generation: periodic automatic or manual; owner-specific bills with full line detail
|
||||
- Pre-validation: optional manual review before automatic bill closure and ERP export
|
||||
- Compensation: manual surcharges or discounts (%) at bill or line level
|
||||
- Notifications: alerts for generation errors, closure events
|
||||
|
||||
## Architecture
|
||||
|
||||
### Core entities
|
||||
|
||||
**Billing rule**: definition of what to count. Two types:
|
||||
- **Standard rules** (automatic): count activities tracked natively by EasyWMS; system counts without user intervention
|
||||
- **Manual rules**: Fixed (flat fee regardless of volume) or Variable (operator-entered quantity); used for activities EasyWMS does not track
|
||||
|
||||
Rules are organized in three groups by concept:
|
||||
|
||||
#### Group 1 — Storage
|
||||
Quantifies articles in stock at a given moment (snapshot-based):
|
||||
| Sub-type | What is counted |
|
||||
|----------|----------------|
|
||||
| Container | Number of containers with owner's stock |
|
||||
| Location | Number of locations with owner's stock |
|
||||
| Unit of measure | Quantity in the chosen UoM |
|
||||
| Weight | Weight of owner's stock (max of balance weight vs. theoretical) |
|
||||
| Volume | Volume of owner's stock (based on item conversion dimensions) |
|
||||
|
||||
#### Group 2 — Handling
|
||||
Quantifies dynamic processes applied to stock (flow-based):
|
||||
| Sub-type | What is counted |
|
||||
|----------|----------------|
|
||||
| Container | Containers involved in the operation |
|
||||
| Work orders | Number of operations (receipts, shipments, loads, routes, counts, kits) |
|
||||
| Work order lines | Number of order lines processed |
|
||||
| Weight | Weight processed in the operations |
|
||||
| Unit of measure | Quantity processed in chosen UoM |
|
||||
| Volume | Volume processed |
|
||||
|
||||
Operations covered: inbound receipts, outbound shipments, loads, routes, counts, kit assemblies.
|
||||
|
||||
#### Group 3 — Transaction
|
||||
Custom rules based on specific WMS transaction types:
|
||||
| Parameter | Description | Required? |
|
||||
|-----------|-------------|----------|
|
||||
| Transaction type | Which WMS transaction triggers the count | Yes |
|
||||
| Owner parameter | Field in the transaction identifying the owner | Yes |
|
||||
| Quantity parameter | Field providing the count value (if absent: quantity = 1 per event) | No |
|
||||
| Operation type | Increment (adds to total), Decrement (subtracts), Variable (sign-based) | Yes |
|
||||
|
||||
Used for non-standard activities not covered by groups 1 or 2.
|
||||
|
||||
**Billing planner**: defines when to generate bills — daily, weekly, monthly, or custom schedule.
|
||||
|
||||
**Billing contract**: ties together an owner + billing rules + planner + validity period + optional economic valuation.
|
||||
|
||||
**Bill**: periodic summary document generated per contract. Contains lines (one per rule) with breakdown detail.
|
||||
|
||||
**Bill line**: total quantification of one rule for the period. Can be drilled down to individual activity records.
|
||||
|
||||
**Compensation**: manual % surcharge or discount applicable at bill level or line level.
|
||||
|
||||
### Contract lifecycle
|
||||
|
||||
```
|
||||
Contract created → Enabled → Bills generated periodically → Lines generated per rule
|
||||
→ Pre-validation (optional) → Closed → ERP export
|
||||
Contract disabled → No new activities recorded; no automatic bill closure
|
||||
```
|
||||
|
||||
### Economic valuation
|
||||
|
||||
When a contract has a currency configured:
|
||||
- Standard rules: Fee (currency/unit) × quantity counted
|
||||
- Stock value rules: Fee (%) × stock value (presentation currency must match contract currency)
|
||||
- Bill totals: Gross price (before compensation) → Subtotal price (after line compensation) → Total price (after bill compensation)
|
||||
|
||||
### Tiered pricing (requires `EnablePriceRanges` toggle)
|
||||
Ranges must be consecutive starting at 1. Last range has no upper limit (acts as catch-all):
|
||||
|
||||
```
|
||||
Range 1: 1–100 units → 10€/unit
|
||||
Range 2: 101–200 units → 8€/unit
|
||||
Range 3: 201+ units → 6€/unit
|
||||
```
|
||||
Bill line displays the **average price** (total gross amount ÷ count) when ranges are used.
|
||||
|
||||
## Configuration
|
||||
|
||||
### Initial setup
|
||||
1. Install Owner Extensions module
|
||||
2. Define owners (3PL clients) in inventory masters
|
||||
3. Create billing rules for each activity category:
|
||||
- Storage rules (container presence, time-based)
|
||||
- Handling rules (inbound, outbound, picking)
|
||||
- Weight/volume/UoM-based rules
|
||||
- Custom transaction-based rules
|
||||
4. Create billing planners (frequency)
|
||||
5. Create contracts: one per owner, assigning applicable rules + planner
|
||||
6. Enable contracts
|
||||
|
||||
### Contract rules configuration
|
||||
For each rule assigned to a contract:
|
||||
- Activity type filter (which operations qualify)
|
||||
- Owner filter (auto-applied from contract)
|
||||
- Economic valuation (fee/unit or fee/% for stock value rules)
|
||||
- Price ranges (optional)
|
||||
|
||||
### Pre-validation
|
||||
When enabled on a contract, generated bills must be manually reviewed and approved before automatic closure. Prevents incorrect bills from being sent to ERP.
|
||||
|
||||
### Contract enable/disable rules
|
||||
- A contract can be enabled/disabled multiple times within its validity period
|
||||
- Disabled contracts: no activity recording for manipulation rules; no automatic bill closure
|
||||
- **Cannot change valuation (on/off) after a contract has been active** — must clone and disable old
|
||||
|
||||
## Operations
|
||||
|
||||
### Bill management (PC — Billing menu)
|
||||
|
||||
| View | Content |
|
||||
|------|---------|
|
||||
| Bills | All generated bills per contract/owner |
|
||||
| Bill lines | Individual rule quantification per bill |
|
||||
| Bill detail lines | Breakdown of each activity counted in a line |
|
||||
| Compensations | All applied discounts/surcharges |
|
||||
| Reports | Detailed and simplified billing reports |
|
||||
|
||||
### Bill status flow
|
||||
1. Bills generated automatically (by planner) or manually
|
||||
2. If pre-validation enabled: bill in "pending validation" state
|
||||
3. Validated → Closed → exported to ERP
|
||||
4. Manual close or forced close available from web interface
|
||||
|
||||
### Compensation actions
|
||||
Available on bills and individual lines:
|
||||
- Apply % discount (negative compensation)
|
||||
- Apply % surcharge (positive compensation)
|
||||
- "Compensated" flag shown on bill and line records
|
||||
|
||||
### Billing notifications
|
||||
|
||||
The system can automatically generate notifications for 6 billing events. Users subscribe per event:
|
||||
|
||||
| Event | Trigger |
|
||||
|-------|---------|
|
||||
| **Bill sent automatically** | A bill has been created, closed, and sent to ERP automatically |
|
||||
| **Bill pending validation** | A bill has been generated and awaits manual approval before closure |
|
||||
| **Bill corrected** | Bill data has been manually corrected after automatic generation |
|
||||
| **Bill cancelled** | A bill has been cancelled; data will not be sent to ERP |
|
||||
| **Contract expired** | The contract's end date has passed; no new bills will be generated |
|
||||
| **Contract about to expire** | The last bill of the contract has been generated; next scheduled date falls outside validity period |
|
||||
|
||||
Notification channels: **email**, **SMS**, or **SmartUI contextual notification**. Channel and timing are configurable per event per subscriber.
|
||||
|
||||
## Errors & troubleshooting
|
||||
|
||||
| Issue | Cause | Resolution |
|
||||
|-------|-------|-----------|
|
||||
| Billing calculation error notification | Stock value rule currency doesn't match contract currency | Ensure all item presentations use same currency as contract |
|
||||
| Contract cannot be enabled | Not all rules have fee configured (when valuation active) | Complete fee configuration for all contract rules |
|
||||
| Bill marked as erroneous | Currency mismatch in stock value calculation | Check presentation currencies; fix contract currency if needed |
|
||||
| Activities not recorded | Contract disabled during activity period | Enable contract before activities occur |
|
||||
|
||||
## Related
|
||||
|
||||
- [[3pl-portal]] — 3PL clients access their billing data and operational KPIs through the client portal
|
||||
- [[owner-extensions]] — Prerequisite module; adds owner enforcement to orders and master data
|
||||
- [[account-owner]] — Owners are the 3PL clients; contracts are created per owner
|
||||
- [[stock]] — Storage-based billing rules measure stock presence and movements
|
||||
- [[order-inbound]] — Inbound handling activities (receipt) counted by billing rules
|
||||
- [[order-outbound]] — Outbound handling activities (shipping, picking) counted by billing rules
|
||||
@@ -0,0 +1,37 @@
|
||||
---
|
||||
title: "Client-Specific Rules"
|
||||
type: module
|
||||
sources:
|
||||
- areas/client_specific_rules/index.md # 404 — source unavailable
|
||||
related:
|
||||
- modules/directives.md
|
||||
- modules/owner-extensions.md
|
||||
- modules/billing-3pl.md
|
||||
last_compiled: "2026-04-10"
|
||||
---
|
||||
|
||||
# Client-Specific Rules
|
||||
|
||||
## Overview
|
||||
|
||||
> **Source unavailable**: The raw source `areas/client_specific_rules/index.md` returns a 404 error. No documentation was available at compilation time.
|
||||
|
||||
Based on context from related modules, "Client-Specific Rules" appears to be either an alternate name or a superset concept for the **[[directives]]** module, which implements client-specific logistics customizations per owner and per account.
|
||||
|
||||
The Directives module documentation (sourced from `areas/directives/`) explicitly uses the title "Client-Specific Rules (_Directives_)" — suggesting these are the same capability.
|
||||
|
||||
## What is covered by this concept
|
||||
|
||||
Client-specific rules in EasyWMS are implemented through two mechanisms:
|
||||
|
||||
1. **Directives** (see [[directives]]): warehouse-level rules applied per owner (3PL client) or per account (end customer). Covers document language, custom workflows, container type requirements, weight/height limits, shelf life minimums, lot count limits, and shipping logic overrides.
|
||||
|
||||
2. **Owner Extensions** (see [[owner-extensions]]): the prerequisite module that enforces owner isolation on orders and master data, enabling per-client rules to be applied without cross-contamination.
|
||||
|
||||
3. **3PL Billing** (see [[billing-3pl]]): contract-based billing rules specific to each 3PL client, defining what activities are billed and at what rate.
|
||||
|
||||
## Related
|
||||
|
||||
- [[directives]] — The primary implementation of client-specific rules in EasyWMS (owner directives and account directives)
|
||||
- [[owner-extensions]] — Prerequisite module enabling owner-level data isolation
|
||||
- [[billing-3pl]] — Client-specific billing rules and contracts
|
||||
@@ -0,0 +1,91 @@
|
||||
---
|
||||
title: "Cobot (Collaborative Robot Picking)"
|
||||
type: module
|
||||
sources:
|
||||
- areas/cobot/index.md
|
||||
related:
|
||||
- concepts/picking.md
|
||||
- concepts/task.md
|
||||
- concepts/stations.md
|
||||
- concepts/container.md
|
||||
last_compiled: "2026-04-10"
|
||||
---
|
||||
|
||||
# Cobot (Collaborative Robot Picking)
|
||||
|
||||
## Overview
|
||||
|
||||
The Cobot module integrates collaborative robotic picking systems (cobots or picking robots) with Easy WMS. A cobot fully automates order picking at designated picking conveyors, maximizing efficiency and productivity for eligible items. Cobot stations always have a corresponding manual picking station nearby for handling incidents and items that cannot be processed robotically.
|
||||
|
||||
The cobot can be incorporated into HPKS (High Performance Picking Station) as HPKS-R, or into any other picking station configuration.
|
||||
|
||||
## Key capabilities
|
||||
|
||||
- Automated picking: robotic arm picks stock from source containers to destination containers
|
||||
- Item eligibility: not all items are suitable for cobot picking; eligibility configured per item with handling conversions
|
||||
- Incident management: items rejected by cobot → routed to adjacent manual picking station for human handling
|
||||
- Conveyor assignment: order picking tasks assigned to cobot conveyors based on line eligibility
|
||||
- Tool management: each cobot has a predefined set of suction cup tools for different item types
|
||||
|
||||
## Architecture
|
||||
|
||||
### Cobot components
|
||||
|
||||
| Component | Description |
|
||||
|-----------|-------------|
|
||||
| Robotic arm | Performs the physical picking movement (source container → destination container) |
|
||||
| Tools (suction cups) | Interchangeable end effectors; each cobot has a predefined set for different item geometries |
|
||||
| Security elements | Sensors ensuring safe operation around humans and equipment |
|
||||
|
||||
### Cobot station design
|
||||
Every cobot station is paired with a **manual picking station**:
|
||||
- Cobot handles eligible items automatically
|
||||
- Manual station handles: items not eligible for cobot, incidents from cobot processing, overflow
|
||||
|
||||
### Picking conveyor assignment
|
||||
Order picking tasks are assigned to cobot conveyors based on:
|
||||
- Whether all order lines are eligible for cobot picking
|
||||
- Item handling conversions configured for cobot use
|
||||
- If a line is ineligible: entire task or that line routes to manual station
|
||||
|
||||
### Item eligibility configuration
|
||||
Per item:
|
||||
- Cobot handling enabled/disabled
|
||||
- Handling conversions (how the cobot grasps/places the item)
|
||||
- Tool assignment (which suction cup tool handles this item)
|
||||
|
||||
## Configuration
|
||||
|
||||
1. Configure picking conveyor as a cobot station (station type, conveyor settings) in EasyS
|
||||
2. Register items eligible for cobot picking with handling conversions
|
||||
3. Configure cobot tools (suction cup set) per cobot unit
|
||||
4. Define cobot picking station assignment rules
|
||||
|
||||
## Operations
|
||||
|
||||
### Automated picking process
|
||||
1. Order released → task assignment evaluates cobot eligibility
|
||||
2. Eligible tasks assigned to cobot conveyor → executed automatically by robotic arm
|
||||
3. Source containers brought to cobot by conveyor system; destination containers filled automatically
|
||||
4. Incidents → items routed to adjacent manual picking station
|
||||
|
||||
### Manual fallback
|
||||
All cobot incidents are resolved at the manual picking station:
|
||||
- Physical issues (item fell, cobot couldn't grasp)
|
||||
- Ineligible items in an otherwise-cobot order
|
||||
- System failures requiring human intervention
|
||||
|
||||
## Errors & troubleshooting
|
||||
|
||||
| Issue | Cause | Resolution |
|
||||
|-------|-------|-----------|
|
||||
| Item not assigned to cobot | Item eligibility not configured | Configure cobot handling conversion for the item |
|
||||
| Cobot incident | Physical issue with item or container | Operator resolves at adjacent manual station |
|
||||
| Conveyor not assigned to cobot tasks | Assignment rules not met | Check line eligibility; verify cobot station configuration |
|
||||
|
||||
## Related
|
||||
|
||||
- [[picking]] — Cobot picking integrates with the standard picking process for automated order fulfillment
|
||||
- [[task]] — Cobot picking tasks are assigned and tracked in the standard WMS task system
|
||||
- [[stations]] — Cobot conveyors are a specific type of picking station in the warehouse layout
|
||||
- [[container]] — Source containers (with items to pick) and destination containers (for picked items) are core to cobot operation
|
||||
@@ -0,0 +1,109 @@
|
||||
---
|
||||
title: "Data Analytics"
|
||||
type: module
|
||||
sources:
|
||||
- areas/data_analytics/index.md
|
||||
related:
|
||||
- modules/labor-management.md
|
||||
- modules/aps3d.md
|
||||
- concepts/transactions.md
|
||||
- concepts/warehouse-designer.md
|
||||
last_compiled: "2026-04-10"
|
||||
---
|
||||
|
||||
# Data Analytics
|
||||
|
||||
## Overview
|
||||
|
||||
The Data Analytics module provides a business intelligence (BI) platform integrated into Easy WMS. It enables users to create custom dashboards with widgets displaying real-time and consolidated warehouse KPIs, share dashboards across teams, and configure metric-driven alarms.
|
||||
|
||||
The module is architected around **metrics groups** (data collection rules), **widgets** (individual visualizations), and **dashboards** (composed views). Standard pre-built dashboards are available for Easy WMS, Labor Management, and APS3D.
|
||||
|
||||
## Key capabilities
|
||||
|
||||
- Real-time and consolidated metric groups (hourly history vs. current snapshot)
|
||||
- Widget library: 50+ widget types covering shipping, receiving, inventory, locations, equipment
|
||||
- Custom dashboard creation: drag-and-drop widget placement, grouping, and filters
|
||||
- Dashboard sharing/publishing: share dashboards to specific user groups or departments
|
||||
- Pre-built dashboards: standard dashboards for logistics best practices (Easy WMS, LMS, APS3D)
|
||||
- Metric group management: enable/disable updates, change schedule
|
||||
- Alarms: configure alerts per widget, delivered in-widget or by email
|
||||
- Multi-device: PC, unattended screens (cyclic display), and mobile phones
|
||||
- Developer extension: metric groups created via EasyBuilder; dashboards created via SmartUI
|
||||
|
||||
## Architecture
|
||||
|
||||
### Data model
|
||||
|
||||
```
|
||||
Metric groups (definition + update script + frequency + purge period)
|
||||
→ Metrics (calculated values)
|
||||
→ Widgets (visualization components)
|
||||
→ Dashboards (composed views)
|
||||
→ Published dashboards (shared with user groups)
|
||||
```
|
||||
|
||||
### Metric group types
|
||||
|
||||
| Type | Update frequency | Data retention |
|
||||
|------|-----------------|----------------|
|
||||
| Consolidated | Hours | Full history (purged after configured period) |
|
||||
| Real-time | Minutes | Only latest value (no history) |
|
||||
|
||||
**Metric gatherer service**: background service that executes update scripts on schedule and handles history purging.
|
||||
|
||||
### Widget categories (by business process)
|
||||
Widgets are classified by:
|
||||
- **Business process**: Shipping, Receiving, Locations, Inventory, Labor, etc.
|
||||
- **Display type**: area chart, curve area, stacked area, 100% stacked, tab, trend tab, ring chart, pie chart, bar chart, stacked bar, line chart, curved line, tree map, dynamic table
|
||||
|
||||
Real-time widgets display current operational status. Consolidated widgets display historical performance trends.
|
||||
|
||||
### Standard dashboards per module
|
||||
|
||||
| Module | Available dashboards |
|
||||
|--------|---------------------|
|
||||
| Easy WMS | Shipping performance, Shipping service level, Shipping statistics, Receiving, Inventory, etc. |
|
||||
| Labor Management | Productivity, efficiency, utilization per operator/team/shift |
|
||||
| APS3D | Shuttle utilization, channel occupancy, order throughput |
|
||||
|
||||
### Publishing model
|
||||
Any user can create personal dashboards. Publishing makes a dashboard available to a specific group of users (appears in their menu). Creators distribute dashboards without others needing to rebuild them.
|
||||
|
||||
## Configuration
|
||||
|
||||
### Metric group management (PC — Data Analytics menu)
|
||||
- View all metric groups with current schedule and enabled status
|
||||
- Enable/disable metric updates per group
|
||||
- Change update schedule
|
||||
- Metric group definitions require EasyBuilder (developer access)
|
||||
|
||||
### Dashboard creation and design
|
||||
1. Access Dashboards view (Data Analytics menu)
|
||||
2. Create new dashboard → enter basic info (name, description)
|
||||
3. Enter design mode: select and arrange widgets from catalog
|
||||
4. Apply filters and configure groupings
|
||||
5. Save and optionally publish to user groups
|
||||
|
||||
### Alarm configuration
|
||||
Per widget:
|
||||
- Set threshold values for KPI breaches
|
||||
- Configure delivery: in-widget alert and/or email
|
||||
- Multiple alarms per widget supported
|
||||
|
||||
## Operations
|
||||
|
||||
### Dashboard display modes
|
||||
- **PC**: standard interactive dashboard with drill-down and filter capabilities
|
||||
- **Unattended screen**: cyclic display of widgets on large monitors (warehouse floor screens)
|
||||
- **Mobile phone**: responsive widget display for managers on the move
|
||||
|
||||
### Slotting heat map (cross-module)
|
||||
When the Slotting module is installed, the warehouse 2D map enables a **location heat map** showing picking activity intensity. This is powered by Data Analytics metrics for activity per location.
|
||||
|
||||
## Related
|
||||
|
||||
- [[labor-management]] — LMS provides the data for Labor Management standard dashboards
|
||||
- [[aps3d]] — APS3D shuttle and channel data available as widgets in Data Analytics
|
||||
- [[transactions]] — Transaction data feeds consolidated metric calculations
|
||||
- [[warehouse-designer]] — Warehouse 2D heat map (Slotting-powered) visible in Warehouse Designer
|
||||
@@ -0,0 +1,108 @@
|
||||
---
|
||||
title: "Directives (Client-Specific Rules)"
|
||||
type: module
|
||||
sources:
|
||||
- areas/directives/index.md
|
||||
- areas/directives/directives_admin/index.md
|
||||
- areas/directives/directives_admin/directives_documents.md
|
||||
- areas/directives/directives_admin/directives_custom_processes.md
|
||||
- areas/directives/directives_admin/directives_required_container_type.md
|
||||
- areas/directives/directives_admin/directives_preferred_container_type.md
|
||||
- areas/directives/directives_admin/directives_client_container_parameters.md
|
||||
- areas/directives/directives_admin/directives_stock_parameters.md
|
||||
- areas/directives/directives_admin/directives_shipping_logic.md
|
||||
- areas/directives/configuration/initial_configuration.md
|
||||
related:
|
||||
- modules/billing-3pl.md
|
||||
- modules/owner-extensions.md
|
||||
- concepts/order-outbound.md
|
||||
- concepts/container.md
|
||||
- concepts/stock.md
|
||||
last_compiled: "2026-04-10"
|
||||
---
|
||||
|
||||
# Directives (Client-Specific Rules)
|
||||
|
||||
## Overview
|
||||
|
||||
The Directives module enables warehouse managers to configure client-specific rules that customize logistics behavior for individual owners (3PL clients) or accounts (end customers) without affecting other clients' stock processing.
|
||||
|
||||
There are two distinct directive types:
|
||||
- **Owner directives**: rules applied to stock belonging to a specific 3PL client organization (owner) — affect workflow and document format/language
|
||||
- **Account directives**: rules applied to stock shipped to a specific customer (account) — affect container selection, stock quality requirements, and shipping logic
|
||||
|
||||
Directives are configured per warehouse and apply to all shipping orders associated with the owner or account after the directive is created. Orders created before the directive are not affected.
|
||||
|
||||
## Key capabilities
|
||||
|
||||
- Per-owner: custom document language/format (labels, packing lists, delivery lists), custom workflow processes
|
||||
- Per-account: required or preferred container type for client containers
|
||||
- Per-account: maximum weight, height, and layer count for client containers
|
||||
- Per-account: minimum shelf life (days of life remaining at time of shipping)
|
||||
- Per-account: maximum number of lots in a shipment
|
||||
- Per-account: shipping logic override (FIFO, FEFO, Best Before Date, production date, LIFO)
|
||||
- Per-account or per-owner: document format and language override
|
||||
|
||||
## Architecture
|
||||
|
||||
### Owner directives
|
||||
|
||||
Rules applied to stock based on the **owner** (3PL client company or sales company):
|
||||
|
||||
| Directive | Description |
|
||||
|-----------|-------------|
|
||||
| Document format and language | Client container labels, packing lists, and delivery lists are printed in the format and language specified. Overrides the warehouse default. |
|
||||
| Custom workflows | Customizes the warehouse workflow for stock processes of a specific 3PL client. Workflows must be developed by Operations staff. Allows per-owner process variations without system-wide changes. |
|
||||
|
||||
### Account directives
|
||||
|
||||
Rules applied to stock based on the **account** (end customer receiving the goods):
|
||||
|
||||
| Directive | Description |
|
||||
|-----------|-------------|
|
||||
| Required container type | All shipping order containers for this account must use exactly this container type (if no container type is specified at the order level). No substitution allowed. |
|
||||
| Preferred container type | Shipping order containers for this account are preferably assigned this container type (if no preference is specified at order level). Can be substituted if unavailable. |
|
||||
| Maximum weight | Client containers for this account cannot exceed this weight. |
|
||||
| Maximum height | Client containers for this account cannot exceed this height. |
|
||||
| Maximum number of layers | Operator is informed of the maximum layers allowed when selecting client containers. |
|
||||
| Minimum shelf life | Stock shipped for this account must have expiration/best-before/end-of-shelf-life date at least N days after the shipping date. Expired stock by this rule is excluded from the shipment. |
|
||||
| Maximum number of lots | Stock shipped for this account must not come from more than N different lots. |
|
||||
| Shipping logic | Stock for this account is picked following a specific logic: FIFO (first in, first out), FEFO (first expiry, first out), Best Before Date, Production date, or LIFO (last in, first out). Overrides the warehouse default shipping logic. |
|
||||
| Document format and language | Labels and shipping documents printed in the specified format and language for this account. |
|
||||
|
||||
### Scope and precedence
|
||||
|
||||
- Directives are configured **per warehouse** centrally in the directives configuration view
|
||||
- They can also be accessed individually from the owner or account master views
|
||||
- If an order already has its own container type or preference specified, the directive does not override it
|
||||
- Multiple directives can be active for the same owner or account (different rule types)
|
||||
- Directives apply only to orders created **after** the directive was set
|
||||
|
||||
## Configuration
|
||||
|
||||
1. Access the Directives configuration view (warehouse management menu)
|
||||
2. Select directive type: Owner or Account
|
||||
3. Select the owner or account to configure
|
||||
4. Choose the specific rule type (document language, container type, shelf life, etc.)
|
||||
5. Set the rule parameters
|
||||
6. Save — directive applies to all future shipping orders for this owner/account
|
||||
|
||||
For custom workflow directives: workflows must be developed and approved by Operations staff before being assignable to an owner directive.
|
||||
|
||||
## Operations
|
||||
|
||||
Directives operate automatically — once configured, they apply silently to all matching shipping orders. Operators see the effects during order processing:
|
||||
- Container selection is constrained or guided by container type directives
|
||||
- Lot selection is limited by lot count directives
|
||||
- Stock eligibility is filtered by shelf life directives
|
||||
- Documents print in the configured language/format
|
||||
- Workflow steps may differ per owner based on custom workflow directives
|
||||
|
||||
## Related
|
||||
|
||||
- [[owner-extensions]] — Owner Extensions adds the owner field to orders; required before owner directives can be applied to specific 3PL clients
|
||||
- [[billing-3pl]] — Billing uses owner identification on orders; directives ensure per-owner processing consistency
|
||||
- [[order-outbound]] — Shipping orders are the primary entity affected by account directives
|
||||
- [[container]] — Container type directives affect client container selection during packing
|
||||
- [[stock]] — Shelf life and lot count directives filter which stock is eligible for shipping to each account
|
||||
- [[client-specific-rules]] — stub module (source unavailable); functionally equivalent to this Directives module
|
||||
@@ -0,0 +1,272 @@
|
||||
---
|
||||
title: "DOM (Distributed Order Management)"
|
||||
type: module
|
||||
sources:
|
||||
- areas/DOM/outbounds/index.md
|
||||
- areas/DOM/outbounds/sales_orders_orchestration_engine.md
|
||||
- areas/DOM/outbounds/outbounds_admin/sales_order.md
|
||||
- areas/DOM/outbounds/outbounds_admin/shipping_order.md
|
||||
- areas/DOM/outbounds/outbounds_admin/sales_order_creation.md
|
||||
- areas/DOM/outbounds/outbounds_admin/sales_order_release.md
|
||||
- areas/DOM/inbounds/index.md
|
||||
- areas/DOM/inbounds/inbounds_admin/purchase_order.md
|
||||
- areas/DOM/inbounds/inbounds_admin/receipt_order.md
|
||||
- areas/DOM/inbounds/expected_stock.md
|
||||
- areas/DOM/replenishments/index.md
|
||||
- areas/DOM/nodes/nodes.md
|
||||
- areas/DOM/nodes/node_classes.md
|
||||
- areas/DOM/nodes/geographic_region.md
|
||||
- areas/DOM/nodes/workload.md
|
||||
- areas/DOM/nodes/nodes_network.md
|
||||
- areas/DOM/nodes/items_catalog.md
|
||||
- areas/DOM/master_data/index.md
|
||||
- areas/DOM/master_data/carriers.md
|
||||
- areas/DOM/master_data/account_types.md
|
||||
- areas/DOM/master_data/geographic_regions.md
|
||||
- areas/DOM/docs_downloads/communications/Interface_Communications_ERP.md
|
||||
- areas/DOM/notificationevents.md
|
||||
related:
|
||||
- modules/multi-carrier.md
|
||||
- modules/yard-management.md
|
||||
- modules/store-fulfillment.md
|
||||
- concepts/order-inbound.md
|
||||
- concepts/order-outbound.md
|
||||
- concepts/stock.md
|
||||
- concepts/replenishment.md
|
||||
last_compiled: "2026-04-10"
|
||||
---
|
||||
|
||||
# DOM (Distributed Order Management)
|
||||
|
||||
## Overview
|
||||
|
||||
Easy DOM is a Distributed Order Management platform that orchestrates the supply chain across multiple warehouse nodes of an organization. Unlike Easy WMS (which manages a single warehouse), DOM manages multi-node logistics: receiving stock from suppliers, routing outbound orders to the optimal fulfillment node, and replenishing inter-node stock.
|
||||
|
||||
DOM centralizes visibility of inventory across the entire organization network and applies configurable orchestration strategies to assign each sales order to the best possible supply point based on proximity, stock availability, carrier availability, and work capacity.
|
||||
|
||||
DOM integrates with the ERP (source of purchase/sales orders) and with each node's WMS (Easy WMS or compatible systems that communicate via standard messaging). It does not execute warehouse operations directly — it delegates to the nodes.
|
||||
|
||||
## Key capabilities
|
||||
|
||||
- Multi-node inventory visibility: stock levels aggregated across all organization nodes (org level, node level, line level)
|
||||
- Outbound orchestration: 5-stage algorithm assigns each sales order to the optimal fulfillment node
|
||||
- Inbound centralization: purchase orders from ERP distributed to nodes as receipt orders (no orchestration — node assignment is direct)
|
||||
- Inter-node replenishment: replenishment orders move stock between nodes to maintain capacity levels
|
||||
- Node network configuration: sourcing relationships, geographic regions, carrier assignments, workload limits
|
||||
- Master data management: owners, items, suppliers, carriers, accounts, account types, geographic regions, kits
|
||||
- ERP messaging integration: bidirectional standard messages (POR/ROC/SOF/etc.) for all order lifecycle events
|
||||
- Manual orchestration wizard: step-by-step stock assignment for orders requiring human intervention
|
||||
- Reorchestration engine: periodic retry for orders with assignment errors as stock conditions change
|
||||
- Notifications: configurable alerts for orchestration errors and order lifecycle events
|
||||
|
||||
## Architecture
|
||||
|
||||
### Node types
|
||||
|
||||
| Role | Types | Description |
|
||||
|------|-------|-------------|
|
||||
| Point of Interaction (POI) | ERP, Office | Source of master data and orders in DOM workflow |
|
||||
| Point of Fulfillment (POF) | Warehouse, 3PL provider | Where orders are prepared and stock is shipped |
|
||||
| Both roles (POI + POF) | Store | Can both create orders and fulfill them |
|
||||
|
||||
**Node attributes**:
|
||||
- Code: matches the WMS _site_ name at the node
|
||||
- Class: groups nodes with similar characteristics (size, item catalog)
|
||||
- Hierarchy level: numerical value limiting sourcing relationships (a node can only be supplied from nodes with ≤ its own level)
|
||||
- Autorelease shipping orders: if enabled, DOM auto-releases shipping orders at the node on the configured date
|
||||
- Node network: defines allowed sourcing relationships between nodes; sets priorities for supply from multiple sources
|
||||
|
||||
### Stock levels
|
||||
|
||||
DOM tracks stock at three levels:
|
||||
| Level | Description |
|
||||
|-------|-------------|
|
||||
| Organization | Total stock across all nodes |
|
||||
| Node | Stock at a specific fulfillment node |
|
||||
| Line | Stock per item/logistic attribute combination at a node |
|
||||
|
||||
Stock pending receipt (pre-notified via purchase orders but not yet physically received) is visible as _receipt pending_ in stock views. Once received, it becomes available for orchestration.
|
||||
|
||||
### ERP messaging interface
|
||||
|
||||
DOM communicates with the ERP and with each node via a standard messaging bus. Key message types:
|
||||
|
||||
| Direction | Code | Description |
|
||||
|-----------|------|-------------|
|
||||
| ERP → DOM | POR | Purchase order request (create/modify) |
|
||||
| DOM → Node | ROC | Receipt order creation (expected inbound) |
|
||||
| ERP → DOM | SOR | Sales order request |
|
||||
| DOM → Node | SOC | Shipping order creation |
|
||||
| Node → DOM | SOF | Shipping order fulfilled (closed) |
|
||||
| DOM → ERP | DOF | Delivery order fulfilled |
|
||||
| DOM → ERP | POC/POF | Purchase order confirmation/fulfillment |
|
||||
| DOM/ERP | ACK | Acknowledgement |
|
||||
| DOM → Node | NCR | Node configuration update |
|
||||
|
||||
## Outbound: Sales Order Orchestration
|
||||
|
||||
### Order lifecycle
|
||||
|
||||
```
|
||||
ERP creates SOR → DOM creates sales order (Pending)
|
||||
→ Release (manual or auto)
|
||||
→ Orchestration engine runs (5 stages)
|
||||
→ Shipping orders created at assigned node(s) (Released)
|
||||
→ Node prepares and ships
|
||||
→ SOF messaging → DOM closes shipping order
|
||||
→ DOM closes sales order → DOF to ERP
|
||||
```
|
||||
|
||||
Sales orders can be stopped (stock freed), rejected (node canceled unilaterally), or canceled (ERP instruction). Archiving follows closing.
|
||||
|
||||
### 5-Stage Orchestration Engine
|
||||
|
||||
| Stage | Description |
|
||||
|-------|-------------|
|
||||
| 1. Geographic region | Delivery address geocoded (lat/long via geolocation service); matched to configured geographic regions (by coordinates, postal code range, or country ISO code) |
|
||||
| 2. Candidate nodes & carriers | Nodes configured to serve the identified region are identified; carriers configured for each node-region combination are checked; carrier can be specified in the order (forces constraint) |
|
||||
| 3. Stock availability | Nodes checked for sufficient available stock per order line; item catalog, quantity available for sale, logistic attributes (lot, serial, expiry, shelf life, version, color, etc.), shipping conditions (required/critical lines) |
|
||||
| 4. Work capacity | Candidate nodes checked for ability to prepare and ship within the committed delivery date; considers working days/hours schedule, existing workload vs. max capacity; prorates available capacity for current-day orders |
|
||||
| 5. Orchestration strategies | Final node selection applies configurable strategy preferences in sequence: total cost → estimated delivery date → region priority → maximum distance; strategies evaluated sequentially until valid candidate found or end-of-sequence reached |
|
||||
|
||||
**Orchestration results**:
|
||||
- **Successful**: optimal node(s) assigned → shipping orders created with auto-release date, estimated ship date, estimated delivery date
|
||||
- **Partial assignment**: stock available for some lines → shipping orders for available quantity; incomplete lines flagged
|
||||
- **Assignment error**: no valid node found → order enters reorchestration queue
|
||||
|
||||
### Order release prioritization
|
||||
|
||||
When multiple orders release simultaneously (autorelease), priority order:
|
||||
1. Autorelease date (orders without a date are last)
|
||||
2. Order priority
|
||||
3. Account type priority (lower sequence = higher priority)
|
||||
4. Commitment date
|
||||
5. Order creation date
|
||||
|
||||
### Manual orchestration wizard
|
||||
|
||||
Available for orders in _Pending_ status (no assigned stock). Step-by-step:
|
||||
1. View order summary and lines
|
||||
2. Select available nodes for each line
|
||||
3. Assign stock quantities per line (partial assignment allowed)
|
||||
4. Review shipping orders to be created (can change ship date or carrier)
|
||||
5. Confirm — shipping orders created
|
||||
|
||||
If stock becomes unavailable during the wizard (concurrent assignment), the order is released with _Incomplete_ or _Assignment error_ status.
|
||||
|
||||
### Reorchestration
|
||||
|
||||
Automatic reorchestration triggers when stock enters the organization (covering orders in assignment error or incomplete state). Also runs periodically to catch non-stock errors (e.g., geolocation API failures).
|
||||
|
||||
Reorchestration priority criteria:
|
||||
1. Order priority
|
||||
2. Account type sequence (lower = higher priority)
|
||||
3. Committed delivery date
|
||||
4. Order release date
|
||||
5. Order creation date
|
||||
|
||||
**Parameter**: `MAX_NUMBER_ORCHESTRATION_ATTEMPS_AFTER_REJECTIONS` — limits how many times an order is reorchestrated after node rejections; notifies when limit is reached.
|
||||
|
||||
Orders exceeding maximum deliveries or whose committed date cannot be met with any reorchestration cannot be automatically reorchestrated and must be manually closed (incomplete).
|
||||
|
||||
### Order splitting
|
||||
|
||||
If no single node can ship the complete order, DOM can assign parts to multiple nodes, creating multiple shipping orders. The maximum number of shipping orders per sales order is configurable. Delivery modes: carrier delivery to client address, or in-store pickup at a store node.
|
||||
|
||||
## Inbound: Purchase Order Management
|
||||
|
||||
DOM does not orchestrate inbound — it records and distributes purchase orders to nodes based on order line data.
|
||||
|
||||
```
|
||||
ERP sends POR → DOM creates purchase order
|
||||
→ Receipt orders created per node (grouped by node + estimated date + carrier)
|
||||
→ Nodes notified (ROC) → nodes plan inbound
|
||||
→ Stock received at node → ROF/SOF messaging → DOM updates received quantities
|
||||
→ Purchase order closed (manual or auto) → POF to ERP
|
||||
→ Archiving (automated by parameter)
|
||||
```
|
||||
|
||||
**Purchase order statuses**: Open → In progress → Closed / Canceled / Rejected (node canceled unilaterally)
|
||||
|
||||
Receipt orders are read-only after creation; they update automatically based on purchase order edits. Receipt orders cannot be manually created.
|
||||
|
||||
**Expected stock**: pre-notified stock visible in stock views as _receipt pending_ — can be used for backordering decision-making but is not available for orchestration assignment (backordering not currently supported).
|
||||
|
||||
## Replenishment: Inter-node Stock Movement
|
||||
|
||||
DOM node replenishment creates replenishment orders to move stock from source nodes to destination nodes when stock levels drop.
|
||||
|
||||
```
|
||||
ERP/manual creates replenishment order
|
||||
→ Release → DOM generates shipping order at source node + receipt order at destination node
|
||||
→ Source ships (SOF) → destination receives (ROF)
|
||||
→ Replenishment order closes
|
||||
```
|
||||
|
||||
Automatic replenishment by safety stock breakage is **not currently supported** — replenishment orders must be created manually or by ERP.
|
||||
|
||||
**Node sourcing relationships** (node network): defines which nodes can supply which other nodes, with priorities when multiple sources exist.
|
||||
|
||||
## Configuration
|
||||
|
||||
### Initial setup sequence
|
||||
1. Define geographic regions (coordinates, postal codes, or country)
|
||||
2. Create nodes (code matching WMS site name, role, type, hierarchy level)
|
||||
3. Configure node workload (working days, hours, max daily order lines, cost per line)
|
||||
4. Configure node-region relationships (which nodes serve which regions, with priority)
|
||||
5. Configure node-carrier relationships per region (carrier, committed delivery time, cost)
|
||||
6. Configure node network (sourcing relationships for replenishment)
|
||||
7. Configure item catalog per node class
|
||||
8. Create master data (owners, accounts, account types, suppliers, carriers)
|
||||
9. Configure orchestration strategies (sequence, criteria, end-of-sequence flags)
|
||||
10. Configure ERP messaging (communications bus, message types per node)
|
||||
|
||||
### Orchestration strategies
|
||||
Multiple strategies can be defined and ordered by sequence number. Each strategy specifies:
|
||||
- Criteria for applicability (order characteristics, delivery destination, transport)
|
||||
- Preference ordering for node selection (cost, delivery date, region priority, distance)
|
||||
- Whether it marks the end of the sequence (stops evaluation if no match found)
|
||||
|
||||
### Node workload configuration
|
||||
Per node:
|
||||
- Working days (days of week)
|
||||
- Start time / end time of working day
|
||||
- Maximum order lines per day (total capacity)
|
||||
- Operational cost per shipping order line (for cost-based strategies)
|
||||
|
||||
## Operations
|
||||
|
||||
### Monitoring views
|
||||
- **Sales orders view**: status, assignment state, traceability log (orchestration result, assigned nodes, strategy used, date)
|
||||
- **Purchase orders view**: receipt progress per node, received vs. expected quantities
|
||||
- **Replenishment orders view**: replenishment progress, source/destination status
|
||||
- **Stock views**: org-level and node-level stock with pending/available breakdown
|
||||
- **Nodes network view**: visual map of node sourcing relationships
|
||||
- **Workload view**: current workload vs. capacity per node per day
|
||||
|
||||
### Delivery modes
|
||||
| Mode | Description |
|
||||
|------|-------------|
|
||||
| Carrier delivery | Standard carrier ships from node to client address |
|
||||
| In-store pickup | Client collects from a store node; no carrier required |
|
||||
|
||||
## Errors & troubleshooting
|
||||
|
||||
| Issue | Cause | Resolution |
|
||||
|-------|-------|-----------|
|
||||
| Assignment error on sales order | No node passes all 5 orchestration stages | Check geographic region config, carrier-node assignments, stock availability, node workload |
|
||||
| Order not reorchestrated after stock receipt | MAX_NUMBER_ORCHESTRATION_ATTEMPS_AFTER_REJECTIONS reached | Manually orchestrate using wizard |
|
||||
| Receipt order not created | Purchase order lines have no valid destination node | Check node configuration and item catalog |
|
||||
| Node rejected shipping order | Node unilaterally canceled (physical constraint, WMS issue) | DOM marks order as rejected; reorchestrate to assign different node |
|
||||
| Geolocation failure | Delivery address not geocodable | Verify address contains valid country ISO code and postal code |
|
||||
| Workload exceeded | Node at capacity for target date | Check node workload configuration; use manual orchestration to force a different date |
|
||||
|
||||
## Related
|
||||
|
||||
- [[order-inbound]] — Receipt orders are the WMS counterpart of DOM purchase orders
|
||||
- [[order-outbound]] — Shipping orders are the WMS counterpart of DOM sales orders
|
||||
- [[stock]] — DOM inventory visibility aggregates WMS stock across all nodes
|
||||
- [[replenishment]] — DOM node replenishment triggers inter-node stock movements
|
||||
- [[multi-carrier]] — Carrier assignments at DOM node level align with Multi-Carrier configuration at WMS level
|
||||
- [[store-fulfillment]] — Store nodes in DOM correspond to Store Fulfillment remote stores
|
||||
- [[yard-management]] — Inbound appointment management at nodes aligns with DOM purchase order arrival notifications
|
||||
@@ -0,0 +1,92 @@
|
||||
---
|
||||
title: "eCommerce"
|
||||
type: module
|
||||
sources:
|
||||
- areas/ecommerce/index.md
|
||||
- areas/ecommerce/parameters.md
|
||||
related:
|
||||
- modules/multi-carrier.md
|
||||
- modules/marketplaces.md
|
||||
- concepts/reception.md
|
||||
- concepts/picking.md
|
||||
- concepts/order-outbound.md
|
||||
last_compiled: "2026-04-10"
|
||||
---
|
||||
|
||||
# eCommerce
|
||||
|
||||
## Overview
|
||||
|
||||
The eCommerce module adds Just-In-Time (JIT) warehouse management capabilities to Easy WMS, designed for warehouses that receive stock and immediately classify it for pending shipping orders rather than storing it. The key innovation is the ability to classify received items at reception time, routing them directly to packing areas when a corresponding outbound order already exists.
|
||||
|
||||
## Key capabilities
|
||||
|
||||
- JIT reception: at goods receipt, items are immediately classified against active grouped shipping orders
|
||||
- Three-way classification of received items:
|
||||
1. **Single-unit orders**: item goes directly to packing area (Multi-Carrier Shipping module)
|
||||
2. **Multi-unit orders** (more than one unit): item routes to sorting/ungrouping area for subsequent packing
|
||||
3. **No matching order**: item is putaway to storage
|
||||
- Grouped order management: orders grouped by waves or groups (same operative for both)
|
||||
- Integration with Multi-Carrier Shipping for final packaging and labeling
|
||||
- Item identification via EAN aliases for unambiguous identification across logistic attribute variants
|
||||
|
||||
## Architecture
|
||||
|
||||
The eCommerce module sits between Reception and Shipping in the WMS flow:
|
||||
|
||||
```
|
||||
Supplier → Reception → eCommerce Classification
|
||||
↓ ↓ ↓
|
||||
Single-unit → Packing Multi-unit → Ungrouping → Packing No order → Storage
|
||||
```
|
||||
|
||||
**Important**: The system does not handle different logistic variables, conversions (without EAN), or user status variations without customization. Using EAN aliases is strongly recommended so each item presentation is uniquely identifiable.
|
||||
|
||||
## Configuration
|
||||
|
||||
### Prerequisites
|
||||
- Multi-Carrier Shipping module installed
|
||||
- Items configured with EAN aliases for unambiguous identification
|
||||
- Grouped shipping orders (waves or groups) released before reception begins
|
||||
|
||||
### Parameters
|
||||
|
||||
| Parameter | Default | Description |
|
||||
|-----------|---------|-------------|
|
||||
| `ECOMMERCE_RECEPTION_ALLOW_AUTOSELECTION` | False | Auto-select the best receipt for each received item (no manual selection required) |
|
||||
| `ECOMMERCE_RECEPTION_ALLOW_MULTIQUANTITY` | False | Allow receiving more than one unit per scan |
|
||||
| `ECOMMERCE_RETURN_ALLOW_AUTOSELECTION` | False | Auto-select the best return receipt for each item |
|
||||
| `ECOMMERCE_RECEPTION_MAX_SECONDS_TO_CONFIRM` | 30 | Maximum seconds after item entry before operator must confirm cart/container/conveyor (useful for concurrent multi-operator reception) |
|
||||
|
||||
## Operations
|
||||
|
||||
### Reception process
|
||||
1. Release grouped shipping orders (waves or groups) before receiving goods
|
||||
2. Operator receives items at dock/reception station
|
||||
3. System classifies each item:
|
||||
- **Single-unit order pending**: route to packing area → Multi-Carrier Shipping packaging
|
||||
- **Multi-unit order pending**: route to sorting/ungrouping zone → later packing
|
||||
- **No pending order**: standard putaway to storage location
|
||||
4. If `ECOMMERCE_RECEPTION_ALLOW_MULTIQUANTITY` = True, operator can receive multiple units per scan
|
||||
5. If `ECOMMERCE_RECEPTION_ALLOW_AUTOSELECTION` = True, system automatically selects receipt without manual choice
|
||||
|
||||
### Post-classification flow
|
||||
- Items arriving at packing area are processed by Multi-Carrier Shipping module (see [[multi-carrier]])
|
||||
- Items arriving at ungrouping zone are sorted and later sent to packing
|
||||
- Items sent to storage follow standard putaway rules
|
||||
|
||||
## Errors & troubleshooting
|
||||
|
||||
| Issue | Cause | Resolution |
|
||||
|-------|-------|-----------|
|
||||
| Items not classified to orders | Orders not released before reception | Release grouped orders first |
|
||||
| Ambiguous item identification | Items lack EAN aliases with logistic attribute variants | Configure EAN aliases per presentation |
|
||||
| Multiple operators receiving same item | No confirmation timeout configured | Set `ECOMMERCE_RECEPTION_MAX_SECONDS_TO_CONFIRM` to appropriate value |
|
||||
|
||||
## Related
|
||||
|
||||
- [[multi-carrier]] — Downstream packaging module for items classified as single-unit or post-ungrouping
|
||||
- [[marketplaces]] — Marketplace connectors generate the eCommerce orders that reception classifies against
|
||||
- [[reception]] — Base reception process; eCommerce adds JIT classification layer
|
||||
- [[picking]] — Multi-unit items go through ungrouping/sorting before packing
|
||||
- [[order-outbound]] — Shipping orders must be grouped and released before eCommerce reception
|
||||
@@ -0,0 +1,102 @@
|
||||
---
|
||||
title: "Faults Management"
|
||||
type: module
|
||||
sources:
|
||||
- areas/faults_management/index.md
|
||||
- areas/faults_management/faults_faults/faults_reports.md
|
||||
- areas/faults_management/faults_faults/faults_historical_data.md
|
||||
- areas/faults_management/faults_actions/index.md
|
||||
- areas/faults_management/faults_actions/actions_historical_data.md
|
||||
- areas/faults_management/faults_actions/actions_notifications.md
|
||||
- areas/faults_management/faults_actions/actions_reports.md
|
||||
related:
|
||||
- modules/automation-dashboard.md
|
||||
- modules/agv.md
|
||||
- modules/aps3d.md
|
||||
- concepts/task.md
|
||||
- concepts/stations.md
|
||||
last_compiled: "2026-04-10"
|
||||
---
|
||||
|
||||
# Faults Management
|
||||
|
||||
## Overview
|
||||
|
||||
The Faults Management module tracks machine faults and manual interventions in automatic warehouse equipment. This is the backend implementation of the **Automation Dashboard** feature — the `areas/faults_management/` area provides the full functionality exposed under the "Automation Dashboard" UI label.
|
||||
|
||||
When automatic warehouse machines (conveyors, sorters, AGVs, APS3D carts) encounter errors, they shut down automatically for safety and notify the system. Faults Management records these events, tracks their resolution, and logs all manual interventions performed by operators during and after fault resolution.
|
||||
|
||||
> **Note**: The schema lists `faults-management` and `automation-dashboard` as separate modules, but they map to the same source area (`areas/faults_management/`). See [[automation-dashboard]] for the full compiled synthesis of this module.
|
||||
|
||||
## Key capabilities
|
||||
|
||||
- Automatic fault recording with start/end timestamps, machine affected, description, causes, and resolution suggestions
|
||||
- Manual action logging: all operator interventions (manual moves, data alterations) by user, machine, date, and auxiliary data
|
||||
- External WMS history: movement history for automatic warehouses using an external WMS communicating through Easy WCS
|
||||
- Fault reports: machine ranking, availability metrics (machine/warehouse/zone), fault frequency
|
||||
- Action reports: top actions by machine/user, usage time reports
|
||||
- Notification support: fault events delivered to supervisors and managers via SCEM
|
||||
|
||||
## Architecture
|
||||
|
||||
### Data tracked
|
||||
|
||||
**Faults**:
|
||||
| Field | Description |
|
||||
|-------|-------------|
|
||||
| Machine | Affected automatic machine |
|
||||
| Start date/time | When the fault occurred |
|
||||
| End date/time | When the fault was resolved |
|
||||
| Description | Fault description |
|
||||
| Possible causes | Diagnostic information |
|
||||
| Resolution suggestions | Recommended corrective actions |
|
||||
|
||||
**Manual actions**:
|
||||
| Field | Description |
|
||||
|-------|-------------|
|
||||
| User | Operator performing the intervention |
|
||||
| Date/time | When the action was performed |
|
||||
| Machine | Affected machine |
|
||||
| Action type | Manual movement, task data alteration, etc. |
|
||||
| Auxiliary data | Additional context |
|
||||
|
||||
### Report types
|
||||
|
||||
**Fault reports**:
|
||||
| Report | Content |
|
||||
|--------|---------|
|
||||
| Historical data | Full fault log with timeline |
|
||||
| Machine ranking | Machines ranked by fault frequency |
|
||||
| Machine unavailability | Downtime periods per machine |
|
||||
| All machines availability | Overall availability across machines |
|
||||
| Warehouse availability | Combined availability metric |
|
||||
| Zone availability (all/one) | Availability by warehouse zone |
|
||||
| Warehouse fault frequency | Fault rate over time |
|
||||
| Warehouse ranking | Ranking by total downtime impact |
|
||||
|
||||
**Action reports**:
|
||||
| Report | Content |
|
||||
|--------|---------|
|
||||
| Historical data | Full action log with timeline |
|
||||
| Top frequent by machine | Most common actions per machine |
|
||||
| Top frequent by user | Most common actions per operator |
|
||||
| Top frequent (general) | Top actions across all machines/users |
|
||||
| Usage times | Time spent on manual actions per category |
|
||||
|
||||
## Fault resolution workflow
|
||||
|
||||
1. Machine encounters error → automatic shutdown
|
||||
2. Easy WCS/WMS receives fault notification → fault record created with start time
|
||||
3. Supervisor receives notification (via SCEM)
|
||||
4. Supervisor reviews fault details (description, possible cause, suggestions)
|
||||
5. Authorized operator performs manual intervention to resolve cause
|
||||
6. Manual action logged automatically
|
||||
7. Machine re-enabled; fault record updated with end date/time
|
||||
|
||||
## Related
|
||||
|
||||
- [[automation-dashboard]] — The Automation Dashboard UI is powered by this module's data
|
||||
- [[agv]] — AGV machine faults and manual interventions tracked here
|
||||
- [[aps3d]] — APS3D Fleet Manager and cart faults tracked for traceability
|
||||
- [[task]] — Manual task completions and modifications logged as actions
|
||||
- [[stations]] — Machine stations are the physical entities tracked in fault records
|
||||
@@ -0,0 +1,150 @@
|
||||
---
|
||||
title: "Labor Management System (LMS)"
|
||||
type: module
|
||||
sources:
|
||||
- areas/labor_management/index.md
|
||||
- areas/labor_management/labor_admin/index.md
|
||||
- areas/labor_management/labor_admin/labor_admin_config.md
|
||||
- areas/labor_management/labor_admin/labor_admin_start.md
|
||||
- areas/labor_management/labor_admin/labor_admin_performance_panel.md
|
||||
- areas/labor_management/labor_admin/labor_admin_rf.md
|
||||
- areas/labor_management/labor_admin/labor_admin_readjust.md
|
||||
- areas/labor_management/labor_admin/labor_view_labor.md
|
||||
- areas/labor_management/labor_admin/labor_view_process.md
|
||||
- areas/labor_management/labor_user/index.md
|
||||
- areas/labor_management/labor_user/labor_user_process.md
|
||||
related:
|
||||
- concepts/task.md
|
||||
- concepts/picking.md
|
||||
- concepts/reception.md
|
||||
- concepts/shipping.md
|
||||
- modules/data-analytics.md
|
||||
last_compiled: "2026-04-10"
|
||||
---
|
||||
|
||||
# Labor Management System (LMS)
|
||||
|
||||
## Overview
|
||||
|
||||
The Labor Management System (LMS) module records detailed execution data for guided warehouse processes, capturing both actual times and calculating target (engineered standard) times. It enables comparison of actual vs. target performance, enabling identification of inefficiencies, data-driven workforce planning, and continuous improvement.
|
||||
|
||||
**Scope**: manual warehouse guided processes only. Automatic warehouse processes are not measured.
|
||||
|
||||
**Multi-site**: LMS configuration (process activation, activity targets, adjustments) is managed **per warehouse** independently within a multi-site organization.
|
||||
|
||||
## Key capabilities
|
||||
|
||||
- Automatic time capture for all guided warehouse processes (reception, putaway, picking, shipping, replenishment, counting, etc.)
|
||||
- Target time calculation based on warehouse layout, equipment configuration, and routing algorithms
|
||||
- Individual and team productivity dashboards
|
||||
- Activity count control panels (working times and task counts per operator)
|
||||
- Optional: real-time countdown display on RFT showing target time for current activity
|
||||
- Department and shift-based grouping of measurements
|
||||
- Time adjustments: per-activity rules that add seconds based on conditions (load weight, units, packages)
|
||||
- Data available for external BI integration
|
||||
|
||||
## Architecture
|
||||
|
||||
### Data model
|
||||
|
||||
```
|
||||
Process → Work (one execution of a process by an operator at a specific time)
|
||||
└→ Work details (individual activity execution times)
|
||||
└→ Work detail adjustments (time adjustments applied to the activity)
|
||||
```
|
||||
|
||||
**Process**: A measurable workflow (e.g., "Picking"). Activated or deactivated per warehouse.
|
||||
|
||||
**Activity**: A step within a process (e.g., "PickingPick", "PickingPut"). Has a standard target time and PFD tolerance.
|
||||
|
||||
**Work**: One complete execution of a process by an operator. Records actual start/end times.
|
||||
|
||||
**Work detail**: Actual times for each activity within a work. Retains warehouse configuration at time of execution.
|
||||
|
||||
**Work detail adjustment**: Time additions applied to an activity execution based on configurable conditions.
|
||||
|
||||
### Measured processes (standard set — not customizable without development)
|
||||
|
||||
| Category | Processes |
|
||||
|----------|-----------|
|
||||
| Inbounds | Supplier receipt, Supplier receipt (identical containers), Blind receipt, Blind receipt (identical containers), Returns receipt, Pre-notified containers receipt |
|
||||
| Putaway | Directed movement, Directed movement (complete containers), Movement with task, Location change (ungrouping) |
|
||||
| Warehouse management | Replenishment of PDLs, Physical count, Count with task |
|
||||
| Shipping | Picking, Shipping, Ungrouping, Ungrouping with PTLs, Truck load, Packaging |
|
||||
|
||||
### Target time calculation
|
||||
The LMS uses the following inputs for travel time calculation:
|
||||
- **Equipment type parameters**: horizontal speed, vertical speed, horizontal/vertical factors (load weight adjustment), acceleration, vertical behavior, aisle direction respect
|
||||
- **Vertical behavior modes**: Return to ground, No return to ground, No return to vectorial ground, Return to ground aisle change, Return to vectorial ground aisle change
|
||||
- **Aisle types**: picking aisles (define routes) + minimum distance aisles (shortcuts; LMS only, no effect on other processes)
|
||||
|
||||
Target time = base movement time (from layout + equipment) + activity-specific adjustments
|
||||
|
||||
## Configuration
|
||||
|
||||
### Prerequisites
|
||||
1. **Warehouse layout**: shelf positions, aisle dimensions, equipment positions in EasyS/EasyAssistant
|
||||
2. **Equipment types**: configure speed, acceleration, vertical behavior per equipment type
|
||||
3. **Aisles**: configure picking aisles and minimum-distance aisles (shortcuts)
|
||||
4. **Users**: assign department and employee number; assign to shifts
|
||||
5. **Shifts**: define number, name, start/end hours, breaks
|
||||
6. **Departments**: define department names
|
||||
|
||||
### LMS-specific configuration
|
||||
|
||||
**Processes** (Processes view, Labor Management > Configuration):
|
||||
- Activate or deactivate each process per warehouse
|
||||
- Cannot add new processes without custom development
|
||||
|
||||
**Activities** (Activities view, Labor Management > Configuration):
|
||||
- Per activity per warehouse: target time (seconds), PFD tolerance (% for personal/fatigue/unforeseen time)
|
||||
- Cannot add new activities without custom development
|
||||
|
||||
**Time adjustments** (Time adjustments view, Labor Management > Configuration):
|
||||
- Filter condition on activity (location, container, carrier, or stock attribute)
|
||||
- Optional filter on stock quantity (UoM + min/max quantity)
|
||||
- Time per unit (seconds × units moved) and time per package (seconds × packages in activity)
|
||||
- Multiple adjustments can apply to same activity execution; each is recorded as a work detail adjustment
|
||||
|
||||
### Start-up calibration
|
||||
After initial configuration, a **time-taking start-up** procedure is required:
|
||||
1. Run the module in parallel with operations to gather actual vs. target data
|
||||
2. Review adjustment panel to identify systematic gaps
|
||||
3. Readjust target times and adjustments to match operational reality
|
||||
4. After any process changes, run the **Reset time capture** procedure to maintain data quality
|
||||
|
||||
## Operations
|
||||
|
||||
### Admin dashboards (PC — Labor Management menu)
|
||||
|
||||
| View | Content |
|
||||
|------|---------|
|
||||
| Performance panel | Team and individual productivity indicators: efficiency (actual/target), utilization, performance trends |
|
||||
| Activity count panel | Working times and task counts per operator |
|
||||
| Works view | Full list of all work executions with times and details |
|
||||
| Configuration adjustment panel | Verify target time calibration by comparing expected vs. actual across sampled works |
|
||||
|
||||
### User views (RFT)
|
||||
- Optional real-time countdown: while executing an activity, the operator's RFT displays the standard target time as a countdown
|
||||
- Enables operators to self-monitor against engineered standards
|
||||
- Configurable per process (on/off per warehouse)
|
||||
|
||||
### Operator data structure
|
||||
Each work records the warehouse configuration at execution time — changes to target times or adjustments do not retroactively affect recorded works.
|
||||
|
||||
## Errors & troubleshooting
|
||||
|
||||
| Issue | Cause | Resolution |
|
||||
|-------|-------|-----------|
|
||||
| Target times significantly off | Layout changes in EasyS not reflected in LMS | Run Reset time capture procedure; recalibrate EasyS layout |
|
||||
| Activities not recorded | Process deactivated | Activate process in Processes configuration view |
|
||||
| Incorrect grouping of data | User department/shift not configured | Configure user organization data in Users view |
|
||||
| Travel time calculation errors | Equipment vertical behavior misconfigured | Review equipment type vertical behavior setting in EasyS |
|
||||
|
||||
## Related
|
||||
|
||||
- [[task]] — LMS measures the actual vs. target execution times of warehouse tasks
|
||||
- [[picking]] — Picking process is one of the most commonly measured LMS processes
|
||||
- [[reception]] — Multiple reception processes (supplier, blind, returns) are measured by LMS
|
||||
- [[shipping]] — Shipping, ungrouping, truck load, and packaging processes measured
|
||||
- [[data-analytics]] — Data Analytics module provides standard LMS dashboards for BI visualization
|
||||
@@ -0,0 +1,200 @@
|
||||
---
|
||||
title: "Manufacturing (WMS for Manufacturing)"
|
||||
type: module
|
||||
sources:
|
||||
- areas/manufacturing/index.md
|
||||
- areas/manufacturing/manufacturing_finished_goods/manufacturing_goods.md
|
||||
- areas/manufacturing/ERP.md
|
||||
- areas/manufacturing/parameters.md
|
||||
- areas/manufacturing/TransactionTypes.md
|
||||
related:
|
||||
- concepts/stock.md
|
||||
- concepts/order-inbound.md
|
||||
- concepts/product-item.md
|
||||
- concepts/erp-interface.md
|
||||
- concepts/reception.md
|
||||
last_compiled: "2026-04-26"
|
||||
---
|
||||
|
||||
# Manufacturing (WMS for Manufacturing)
|
||||
|
||||
## Overview
|
||||
|
||||
The Manufacturing module integrates Easy WMS with production line management, providing supply chain traceability for manufacturing environments. It manages the supply of raw materials to production lines, tracks raw material consumption, and registers finished goods back into WMS stock.
|
||||
|
||||
The module supports ERP communications for recipe and production order management, and optionally integrates with MES (Manufacturing Execution Systems).
|
||||
|
||||
## Key capabilities
|
||||
|
||||
- Recipe management: ERP-driven creation/modification/deletion of production recipes (manufacturing and quartering types)
|
||||
- Manufacturing orders: ERP-driven creation and management of production orders
|
||||
- Raw material supply: tracking of stock consumed by production lines
|
||||
- Finished goods registration: counting and recording of produced items into WMS stock
|
||||
- Quartering recipes: one raw material → multiple finished goods items
|
||||
- Damaged goods handling: marking produced stock as damaged (raw material consumption still recorded)
|
||||
- Traceability: lot tracking for finished goods when multiple lots of raw materials are consumed
|
||||
- Automatic logistic attribute generation (lot, expiry date, shelf life) for finished goods via manufacturing profile
|
||||
- Label printing at finished goods registration (manual or automatic per order configuration)
|
||||
- MES integration: reports finished goods quantities via FGP message
|
||||
|
||||
## Architecture
|
||||
|
||||
### Key entities
|
||||
|
||||
**Recipe**: defines the relationship between raw materials and finished goods. Two types:
|
||||
- **Manufacturing (RCP01/RCP02)**: one or more raw materials → one finished good
|
||||
- **Quartering (RCP02 only)**: one raw material → multiple finished goods (user selects which item to register during production)
|
||||
|
||||
**Manufacturing order (MOR)**: a specific production run referencing a recipe, a production line, priority, and warehouse.
|
||||
|
||||
**Production line (production station)**: a physical station in the warehouse where manufacturing takes place. Each production station is associated with:
|
||||
- **Supply buffer** (poumon d'approvisionnement): the zone where raw materials must be brought before production can start. Raw materials are supplied here via automatic supply tasks when the MO is released.
|
||||
- **Production buffer** (poumon de production): the zone where finished goods are created and placed after declaration.
|
||||
- Only **one manufacturing order can be active at a time** per production station.
|
||||
|
||||
**Raw materials (MP)**: articles consumed at production start. Each recipe defines the MP required and quantities per finished goods unit.
|
||||
|
||||
**Finished goods (PF)**: articles created by the manufacturing process. One recipe produces one finished good type (except quartering recipes which produce multiple).
|
||||
|
||||
**Additives**: raw materials included in the recipe but whose provisioning is NOT managed at MO release time. They are consumed when finished goods are declared (automatic consumption mode only). Examples: water, salt. Their presence is tracked but not provisioned via supply tasks.
|
||||
|
||||
**Finished goods**: container of produced items whose quantity is based on the item's container conversion (full container quantity). Any remainder goes into a partial container.
|
||||
|
||||
### ERP messages
|
||||
|
||||
| Message | Direction | Description |
|
||||
|---------|-----------|-------------|
|
||||
| `RCP01` | ERP → WMS | Manage manufacturing recipes (create/update/delete) |
|
||||
| `RCP02` | ERP → WMS | Manage manufacturing and quartering recipes |
|
||||
| `MOR01` | ERP → WMS | Manage production orders (create/update/delete) |
|
||||
| `MOF` | WMS → ERP | Notify finished goods registration (or marking as damaged) |
|
||||
| `FGP` | WMS → MES | Report quantity of finished goods produced from an order |
|
||||
|
||||
### Transactions
|
||||
|
||||
| Transaction | Trigger |
|
||||
|-------------|---------|
|
||||
| `STK.MAN.PRODUCTION` | Recorded for each stock line produced |
|
||||
| `MAN.FM.DAMAGE` | Recorded for each stock line marked as damaged |
|
||||
|
||||
## Configuration
|
||||
|
||||
### Prerequisites
|
||||
- Production stations configured in EasyS/EasyAssistant with supply buffer + production buffer zones
|
||||
- Routes from raw material storage to production stations
|
||||
- Manufacturing profiles configured on finished good items (for automatic lot/expiry generation)
|
||||
- Recipes (RCP) imported from ERP or created manually before releasing MOs
|
||||
|
||||
### Consumption mode (per production station)
|
||||
|
||||
Each production station is configured with either **automatic** or **manual** consumption:
|
||||
|
||||
| Mode | Behavior |
|
||||
|------|----------|
|
||||
| **Automatic** | Raw materials are consumed automatically each time finished goods are declared, based on recipe ratios. If supply buffer has insufficient stock, the system consumes what is available (no blocking). Additives are consumed in this mode. |
|
||||
| **Manual** | Operator declares each raw material consumed (article + quantity) on the TRF. Can declare a different quantity than the recipe (useful for actual vs. theoretical discrepancy). Additives cannot be declared manually. |
|
||||
|
||||
Both modes can coexist in the same warehouse for different stations.
|
||||
|
||||
**Automatic consumption — FEFO**: when multiple containers of the same raw material are on the supply buffer, the first to expire is consumed first.
|
||||
|
||||
**Manual consumption TRF process**:
|
||||
1. Go to `Consumption` sub-menu
|
||||
2. Select or scan the MO
|
||||
3. Scan each raw material article code + enter quantity consumed (or scan container code to consume all)
|
||||
4. Exit menu — raw materials consumed; MO progress updated
|
||||
|
||||
### Manufacturing profile (on items)
|
||||
Items configured with a manufacturing profile can automatically generate logistic attributes at finished goods registration:
|
||||
- **Lot generation process**: defines the logic for auto-generating lot numbers on PF creation
|
||||
- **Days before expiry**: WMS calculates expiry date = production date + this number of days
|
||||
- **Days before DLUO** (best-before): WMS calculates DLUO = production date + this number of days
|
||||
|
||||
### Key parameter
|
||||
|
||||
| Parameter | Description |
|
||||
|-----------|-------------|
|
||||
| `MANUFACTURING_MANAGE_DISCREPANCY_IN_STOCK_CONSUMPTION` | When True: if insufficient stock available at finished goods creation, system selects from all available stock and marks with `NegativeStock` user status (blocks picking/shipping). Status auto-created if not found. |
|
||||
|
||||
## Operations
|
||||
|
||||
### Manufacturing order lifecycle
|
||||
|
||||
```
|
||||
ERP sends MOR01 (or manager creates manually)
|
||||
→ MO status: Pending
|
||||
→ Manager releases MO (manual action on SmartUI)
|
||||
→ MO status: Released
|
||||
→ WMS auto-generates supply tasks for all raw materials (to supply buffer)
|
||||
→ Operator supplies raw materials to production station buffer
|
||||
→ Operator declares PF production (TRF: Finished Goods sub-menu)
|
||||
→ [Automatic consumption]: WMS auto-consumes MPs proportionally
|
||||
→ [Manual consumption]: Operator declares each MP consumed (TRF: Consumption sub-menu)
|
||||
→ Operator closes MO (TRF: MO Closing sub-menu, or SmartUI)
|
||||
→ MOF sent to ERP
|
||||
```
|
||||
|
||||
> **Warning**: No automatic MO creation on stock shortage. If PF stock is insufficient, someone must manually request an MO or the ERP must send one.
|
||||
|
||||
### Finished goods declaration (TRF — Manufacturing menu)
|
||||
1. Access "Finished Goods" sub-menu on TRF
|
||||
2. Select or scan the MO code (or select from list of Released/InProgress orders)
|
||||
3. For quartering recipes: select which item is being produced
|
||||
4. Enter quantity of PF per container
|
||||
5. For each container: scan container code (pre-printed labels can be used)
|
||||
6. System creates PF stock in production buffer; MO progress updated in real time
|
||||
7. In automatic consumption mode: MPs consumed proportionally at this step
|
||||
8. Optional: print container label (manually via "Label" button, or automatically if order configured)
|
||||
|
||||
### Damaged finished goods
|
||||
If PF declared as damaged:
|
||||
- PF articles are **not created** in WMS stock
|
||||
- MO produced quantity is still updated (counts toward total declared)
|
||||
- In automatic consumption mode: MPs are still consumed normally
|
||||
- Damage information is visible in SmartUI for reporting
|
||||
|
||||
### Rebuts (scrap) at MO closing
|
||||
During MO closing, the operator can declare that certain MPs were **rebuts** (defective/damaged):
|
||||
- Rebuts count as consumed (stock decremented)
|
||||
- MO closing tracks which MPs were actual consumption vs. rebuts
|
||||
- Visible in SmartUI post-closing for analysis
|
||||
|
||||
### MO closing (TRF)
|
||||
1. Access "MO Closing" sub-menu
|
||||
2. Scan or select the MO
|
||||
3. Confirm actual quantities: MP consumed per line + actual PF quantity produced
|
||||
4. If actual MP < declared: system restores excess MPs to supply buffer
|
||||
5. If actual MP > declared or actual PF < declared: no automatic correction (visible in SmartUI)
|
||||
6. Operator cannot declare more PF than already declared (must use PF declaration first)
|
||||
7. MO closes → MOF sent to ERP
|
||||
|
||||
### Raw material consumption (manual mode only)
|
||||
1. Go to `Consumption` sub-menu
|
||||
2. Select or scan the MO
|
||||
3. Scan each raw material code; enter consumed quantity
|
||||
4. Or scan a container code to consume all stock in that container
|
||||
5. Exit sub-menu — MPs consumed; MO progress updated
|
||||
|
||||
### Traceability
|
||||
When finished goods use raw materials from **multiple lots or containers**, EasyWMS records all potential source lots. In case of a quality issue on a raw material lot, all potentially affected PF can be identified. Traceability links MP lot → PF lot.
|
||||
|
||||
### Recipe management
|
||||
- New recipes created via RCP01/RCP02 are automatically enabled
|
||||
- Recipe changes and deletions only possible when no active manufacturing order references the recipe
|
||||
- Recipes can also be created manually in SmartUI (Masters → Manufacturing)
|
||||
|
||||
## Errors & troubleshooting
|
||||
|
||||
| Issue | Cause | Resolution |
|
||||
|-------|-------|-----------|
|
||||
| `NegativeStock` status on finished goods | Insufficient raw material stock at time of production; `MANUFACTURING_MANAGE_DISCREPANCY_IN_STOCK_CONSUMPTION` = True | Verify raw material stock; the NegativeStock status blocks picking/shipping until resolved |
|
||||
| Cannot modify/delete recipe | Active manufacturing order references the recipe | Complete or cancel the manufacturing order first |
|
||||
| MOF message not sent | Communication error with ERP | Check ERP interface configuration; resend manually |
|
||||
|
||||
## Related
|
||||
|
||||
- [[stock]] — Finished goods registration creates stock; raw material consumption decreases stock
|
||||
- [[product-item]] — Items with manufacturing profiles control automatic logistic attribute generation
|
||||
- [[order-inbound]] — Raw material receipts replenish production input stock
|
||||
- [[erp-interface]] — RCP, MOR, MOF, FGP messages are the ERP integration layer for manufacturing
|
||||
- [[reception]] — Raw materials typically enter via standard reception before being supplied to production lines
|
||||
@@ -0,0 +1,62 @@
|
||||
---
|
||||
title: "Marketplaces"
|
||||
type: module
|
||||
sources:
|
||||
- areas/marketplaces/index.md
|
||||
- areas/marketplaces/TransactionTypes.md
|
||||
related:
|
||||
- modules/ecommerce.md
|
||||
- modules/multi-carrier.md
|
||||
- concepts/order-outbound.md
|
||||
last_compiled: "2026-04-10"
|
||||
---
|
||||
|
||||
# Marketplaces
|
||||
|
||||
## Overview
|
||||
|
||||
The Marketplaces module integrates Easy WMS with external marketplace platforms (Prestashop, eBay, Amazon), enabling automated order synchronization. When a customer places an order on a marketplace, the module receives it and creates the corresponding shipping order in Easy WMS, feeding it into the eCommerce and Multi-Carrier Shipping workflows for fulfillment.
|
||||
|
||||
The module completes the end-to-end eCommerce cycle: marketplace order → WMS shipping order → eCommerce JIT reception or picking → Multi-Carrier packaging → carrier delivery.
|
||||
|
||||
## Key capabilities
|
||||
|
||||
- Connector to Prestashop, eBay, and Amazon marketplaces
|
||||
- Automatic creation of shipping orders in Easy WMS from marketplace orders
|
||||
- Transaction tracking (`OUT.CREATE` — records which shipping order was created from which marketplace)
|
||||
- Full cycle coverage when combined with eCommerce and Multi-Carrier Shipping modules
|
||||
|
||||
## Architecture
|
||||
|
||||
### Supported marketplaces
|
||||
|
||||
| Marketplace | Notes |
|
||||
|-------------|-------|
|
||||
| Prestashop | Standard connector |
|
||||
| eBay | Standard connector |
|
||||
| Amazon | **Requires SaaS deployment mode** (Amazon security/certification requirement); RF terminals must run Android 10 (API 29) or higher |
|
||||
|
||||
### Transaction types
|
||||
|
||||
| Transaction | Description |
|
||||
|-------------|-------------|
|
||||
| `OUT.CREATE` | Shipping order created from marketplace. Fields: Site, User, Owner, Document1 (shipping order code), Source (marketplace origin) |
|
||||
|
||||
## Configuration
|
||||
|
||||
### Amazon-specific requirements
|
||||
- Deployment must be in **SaaS mode** (mandatory for Amazon compliance)
|
||||
- RF terminals: Android 10 (API 29) minimum
|
||||
|
||||
### Integration flow
|
||||
1. Configure marketplace connector (credentials, endpoint, sync frequency)
|
||||
2. Map marketplace item codes to WMS item codes (SKU mapping)
|
||||
3. Map marketplace accounts/destinations to WMS accounts/carriers
|
||||
4. Marketplace orders received → `OUT.CREATE` transaction recorded → shipping order created
|
||||
5. Shipping order flows into eCommerce or standard picking + Multi-Carrier packaging
|
||||
|
||||
## Related
|
||||
|
||||
- [[ecommerce]] — eCommerce module handles the JIT reception and classification of stock for marketplace orders
|
||||
- [[multi-carrier]] — Packaging and carrier label generation for marketplace shipments
|
||||
- [[order-outbound]] — Shipping orders are the WMS representation of marketplace orders
|
||||
@@ -0,0 +1,89 @@
|
||||
---
|
||||
title: "Movirack"
|
||||
type: module
|
||||
sources:
|
||||
- areas/movirack/index.md
|
||||
- areas/movirack/movirack.md
|
||||
- areas/movirack/movirack_user/index.md
|
||||
related:
|
||||
- concepts/location.md
|
||||
- concepts/task.md
|
||||
- concepts/picking.md
|
||||
- concepts/stations.md
|
||||
last_compiled: "2026-04-10"
|
||||
---
|
||||
|
||||
# Movirack
|
||||
|
||||
## Overview
|
||||
|
||||
Movirack is a mobile racking system used as a high-density storage solution in manual warehouses. Mobile rack blocks are installed on motorized bases that move laterally on rails, allowing aisles to be opened only when needed. This maximizes storage capacity while maintaining direct access to all pallets.
|
||||
|
||||
The Movirack module integrates WMS task execution with Movirack hardware control via a communications API, enabling operators to work with tasks while simultaneously controlling aisle opening through a workstation tablet.
|
||||
|
||||
## Key capabilities
|
||||
|
||||
- Aisle management integrated with WMS task execution: operators open aisles on-demand during picking, putaway, and loading tasks
|
||||
- Multiple aisle opening modes: with task, without task (manual location selection), and multi-aisle (up to 3 aisles simultaneously)
|
||||
- Task types supported: location (putaway), picking, shipping, and truck loading tasks
|
||||
- Movirack reset: rearms the system after execution or failure
|
||||
- Abort order: stops an in-progress Movirack movement
|
||||
- WMS workstation (tablet, web browser): integrates RF operations and Movirack control in a single interface
|
||||
|
||||
## Architecture
|
||||
|
||||
### Movirack entity attributes
|
||||
|
||||
| Field | Description |
|
||||
|-------|-------------|
|
||||
| Code | Movirack identifier |
|
||||
| Number | Number in warehouse |
|
||||
| IP | Movirack communication IP |
|
||||
| Maximum picking aisles | Max aisles open simultaneously |
|
||||
| Mode | Manual / Auto / Timing / Autoparking / Autopicking |
|
||||
| Status | Ready / Not ready / On process / Failure |
|
||||
| Reset | Whether system is ready for new orders |
|
||||
|
||||
### Communication
|
||||
Easy WMS communicates with Movirack hardware via a **communications API** (orders sent, status received). The WMS workstation tablet acts as the control interface, integrating:
|
||||
- Standard RF warehouse operations (picking, putaway, etc.)
|
||||
- Movirack control commands (open aisle, reset, abort)
|
||||
|
||||
## Configuration
|
||||
|
||||
1. Configure Moviracks in EasyS or EasyAssistant (number, IP, mode)
|
||||
2. Configure routes from Movirack locations to staging/dock areas
|
||||
3. Create Movirack station in warehouse layout
|
||||
4. Configure maximum simultaneous aisles per Movirack
|
||||
|
||||
## Operations
|
||||
|
||||
### Aisle opening modes (Tablet workstation)
|
||||
|
||||
| Mode | Trigger | Process |
|
||||
|------|---------|---------|
|
||||
| Open aisle with task | System assigns task with Movirack origin/destination | Operator presses "open aisle" button when at location |
|
||||
| Open aisle without task | Manual action needed at Movirack location | Operator selects Movirack and aisle to open from guided flow |
|
||||
| Open aisle manually | Any situation (maintenance, pre-opening) | Operator selects Movirack and aisle directly |
|
||||
| Open multi-aisle | Need to open up to 3 aisles | Guided flow to select Movirack + multiple aisles |
|
||||
|
||||
### Reset Movirack
|
||||
After a Movirack executes an order or is in failure state, it must be rearmed before new orders can be sent. The "Reset Movirack" action from the workstation rearms the system.
|
||||
|
||||
### Abort order
|
||||
If a Movirack is executing a movement and it must be stopped, the "Abort order" action from the workstation halts the current movement.
|
||||
|
||||
## Errors & troubleshooting
|
||||
|
||||
| Issue | Cause | Resolution |
|
||||
|-------|-------|-----------|
|
||||
| Movirack status: Not ready | Hardware not initialized or fault condition | Check Movirack hardware; use Reset action |
|
||||
| Movirack status: Failure | Communication or mechanical error | Investigate Movirack hardware; use Reset after resolution |
|
||||
| Cannot send orders | Status not "Ready" | Reset Movirack first |
|
||||
|
||||
## Related
|
||||
|
||||
- [[location]] — Movirack locations are compact storage locations on mobile bases; aisle opening is required for access
|
||||
- [[task]] — Putaway, picking, shipping, and loading tasks can involve Movirack locations
|
||||
- [[picking]] — Picking from Movirack locations requires aisle opening before extraction
|
||||
- [[stations]] — Movirack has its own station type in the warehouse layout
|
||||
@@ -0,0 +1,230 @@
|
||||
---
|
||||
title: "Multi-Carrier Shipping"
|
||||
type: module
|
||||
sources:
|
||||
- areas/multi_carrier_shipping/index.md
|
||||
- areas/multi_carrier_shipping/multicarrier_admin/definitions/carrier_label.md
|
||||
- areas/multi_carrier_shipping/multicarrier_admin/definitions/extended_carrier.md
|
||||
- areas/multi_carrier_shipping/multicarrier_admin/definitions/shipping.md
|
||||
- areas/multi_carrier_shipping/multicarrier_admin/definitions/tracking_number.md
|
||||
- areas/multi_carrier_shipping/multicarrier_admin/packing_automatic_carrier_selection.md
|
||||
- areas/multi_carrier_shipping/multicarrier_admin/packing_printing.md
|
||||
- areas/multi_carrier_shipping/multicarrier_admin/packing_supported_services.md
|
||||
- areas/multi_carrier_shipping/multicarrier_admin/merge_orders.md
|
||||
- areas/multi_carrier_shipping/multicarrier_rf_ws/packing_definitions.md
|
||||
- areas/multi_carrier_shipping/multicarrier_rf_ws/packing_carrier_mode.md
|
||||
- areas/multi_carrier_shipping/multicarrier_rf_ws/packing_client_stock.md
|
||||
- areas/multi_carrier_shipping/multicarrier_rf_ws/packing_cutting_stock_index.md
|
||||
- areas/multi_carrier_shipping/multicarrier_rf_ws/packing_damaged_stock.md
|
||||
- areas/multi_carrier_shipping/multicarrier_rf_ws/packing_issues_management.md
|
||||
- areas/multi_carrier_shipping/multicarrier_rf_ws/packing_postpone.md
|
||||
- areas/multi_carrier_shipping/parameters.md
|
||||
- areas/multi_carrier_shipping/TransactionTypes.md
|
||||
- custom/analyse_fonctionnelle.md
|
||||
related:
|
||||
- concepts/carrier.md
|
||||
- concepts/shipping.md
|
||||
- concepts/order-outbound.md
|
||||
- concepts/labels.md
|
||||
- modules/ecommerce.md
|
||||
- concepts/cutting-stock.md
|
||||
last_compiled: "2026-04-26"
|
||||
---
|
||||
|
||||
# Multi-Carrier Shipping
|
||||
|
||||
## Overview
|
||||
|
||||
The Multi-Carrier Shipping module extends Easy WMS with advanced packaging, carrier integration, and shipment label management. It bridges the gap between warehouse shipping preparation and last-mile carrier handoff, managing the packaging station process from stock consolidation through carrier label printing and dock deposit.
|
||||
|
||||
**Key constraint**: The module is only compatible with ERP communications — deliveries can only be generated through ERP messages (SOR), not created manually from the web interface.
|
||||
|
||||
The module supports multiple carriers simultaneously, enabling a single warehouse to ship with different carriers based on order characteristics (destination, account, weight, dimensions). It integrates tightly with the eCommerce and Marketplaces modules for JIT fulfillment scenarios.
|
||||
|
||||
## Key capabilities
|
||||
|
||||
- Carrier-agnostic packaging: supports major carriers (see supported carriers list below)
|
||||
- Automatic carrier selection based on destination, account, weight, and dimensions
|
||||
- Delivery grouping: multiple shipping orders can share a single delivery (same contact + address + carrier)
|
||||
- Order merging: orders sharing a delivery can be merged for group preparation into one or more packages
|
||||
- Multi-source packing: stock from conveyors, ungrouping stations, locations, and client containers
|
||||
- Weight capture: per-package weighing when required by carrier
|
||||
- Tracking number management: carrier-specific algorithms; verification confirmation workflow
|
||||
- Cutting stock support: packaging, verification, and extraction without packaging for cut items
|
||||
- Damaged stock handling: stock can be marked as damaged during packaging
|
||||
- Client stock support: restricted packing for stock owned by 3PL clients
|
||||
- Postponement: partial delivery closure; reopens automatically when all origins are read
|
||||
|
||||
## Architecture
|
||||
|
||||
### Core entities
|
||||
|
||||
**Delivery**: the carrier-level shipment record. Aggregates one or more shipping orders sharing the same contact, destination address, and carrier. Contains one or more packages.
|
||||
|
||||
**Package**: a physical unit shipped within a delivery. Has a tracking number unique to the carrier.
|
||||
|
||||
**Extended carrier**: carrier definition enriched with Multi-Carrier data — client code, stage station, carrier type, label report, load manifest report, weight capture flag, tracking number sequence, workflow configurations.
|
||||
|
||||
**Carrier label**: physical label attached to each package. Contains sender/recipient addresses and tracking barcode.
|
||||
|
||||
**Tracking number**: unique package identifier calculated using a carrier-specific algorithm (typically from client code + postal codes).
|
||||
|
||||
### Delivery statuses
|
||||
|
||||
| Status | Description |
|
||||
|--------|-------------|
|
||||
| Open | Active packaging in progress |
|
||||
| Closed | Shipped or manually closed (final) |
|
||||
| Canceled | Canceled and deleted (final) |
|
||||
| Pending shipping | Partial close pending or tracking number missing |
|
||||
| Pending cancel | Verification failed; auto-cancel in progress |
|
||||
| Locked by verification error | Verification failed; auto-reopens on success |
|
||||
| Postponed | Incomplete delivery; auto-reopens when all origins read |
|
||||
|
||||
### Packaging station sources (stock origins)
|
||||
|
||||
| Source | Use case |
|
||||
|--------|----------|
|
||||
| Conveyor or cart | Loose stock from single-unit orders |
|
||||
| Ungrouping station | Loose stock from multi-unit orders after ungrouping |
|
||||
| Location or client container | Loose stock from multi-unit orders; stock from single-unit client containers |
|
||||
|
||||
### Package destinations
|
||||
|
||||
| Destination | Use case |
|
||||
|-------------|----------|
|
||||
| Carrier dock | Direct deposit at carrier dock (auto or manual confirmation) |
|
||||
| Conveyor | Packages conveyed to dock; operator confirms arrival |
|
||||
| Packaging station / container | Staged for later transport to dock |
|
||||
|
||||
## Supported Carriers
|
||||
|
||||
EasyWMS Multi-Carrier supports the following carriers natively. Each has its own label algorithm, tracking number format, and optionally a verification web service:
|
||||
|
||||
| Carrier | Notes |
|
||||
|---------|-------|
|
||||
| STEF | French logistics |
|
||||
| XPO Logistics | |
|
||||
| Kuehne+Nagel | |
|
||||
| MRW | Spain |
|
||||
| Nacex | Spain |
|
||||
| DB Schenker | |
|
||||
| SEUR | Spain |
|
||||
| Geodis | |
|
||||
| FedEx / TNT | |
|
||||
| DPD | |
|
||||
| Chronopost | France |
|
||||
| Colissimo | La Poste France |
|
||||
| DHL | |
|
||||
| UPS | |
|
||||
| GLS | |
|
||||
| Mondial Relay | France/Belgium |
|
||||
| Delivengo | La Poste International |
|
||||
| BPOST | Belgium |
|
||||
| **Custom** | Generic template for carriers not in the standard list |
|
||||
|
||||
Carriers operate in two integration modes:
|
||||
- **Online mode**: EasyWMS connects to carrier API in real time for label generation and tracking validation
|
||||
- **Offline mode**: Labels generated locally from pre-loaded tracking number files; no carrier connectivity required at time of packing
|
||||
|
||||
### Packing methods (per item family)
|
||||
|
||||
The packing method is configured at item family level and controls how the carrier label call is generated at the packaging station:
|
||||
|
||||
| Packing method | Behavior | Best for |
|
||||
|----------------|---------|---------|
|
||||
| **Scan all items** | Operator scans each individual item into a parcel one by one; total weight calculated per scan | Default; heterogeneous orders requiring precise parcel contents |
|
||||
| **Choose parcel count** | Operator declares the number of parcels; system moves all stock into parcel 1 automatically (no per-item scan, no automatic weight) | Homogeneous bulk orders |
|
||||
| **Always 1 parcel** | No operator input; system assumes single-parcel shipment and processes automatically | High-volume B2C (eCommerce single-item orders) |
|
||||
|
||||
**Precedence rule**: when a single shipping order contains items from multiple families with different packing methods, the **most restrictive method takes precedence**:
|
||||
`Scan all items` > `Choose parcel count` > `Always 1 parcel`
|
||||
|
||||
The packing method can be overridden at multiple levels:
|
||||
1. Warehouse default
|
||||
2. Item family configuration
|
||||
3. Client (account) configuration
|
||||
4. Owner configuration (3PL)
|
||||
|
||||
Most specific level wins.
|
||||
|
||||
## Configuration
|
||||
|
||||
### Extended carrier setup
|
||||
For each carrier to be used for packaging:
|
||||
1. Register carrier in Easy WMS masters
|
||||
2. Add extended carrier data (Deliveries menu > Extended Carriers):
|
||||
- Carrier type (selects standard carrier template or Custom)
|
||||
- Client code (required for Bpost, MRW, TNT, Nacex, UPS)
|
||||
- Stage station (mandatory — one stage per carrier or shared)
|
||||
- Label report / Load manifest report
|
||||
- Weight capture flag
|
||||
- Tracking number sequence and workflow names
|
||||
- Extra data (carrier-specific connection parameters)
|
||||
3. Verify warehouse sender data in EasyS (address, phone, ISO country code)
|
||||
|
||||
### Automatic carrier selection
|
||||
Configure rules in **Carrier selection configuration** view (Deliveries menu):
|
||||
- Priority-ordered rules: first matching rule wins
|
||||
- Criteria: delivery destination (national/international/any), client account, weight range, dimension ranges
|
||||
- Fallback: if no rule matches, carrier from SOR message is used; if SOR has carrier, it overrides automatic selection
|
||||
|
||||
### Carrier dock confirmation mode (parameter: `PACKAGING_CARRIER_MODE`)
|
||||
- `AUTO`: packages automatically moved to carrier's dock
|
||||
- `MANUAL`: operator confirms carrier code before dock movement
|
||||
- `UNLOAD`: operator indicates intermediate location; second operator moves to dock
|
||||
|
||||
### Packaging station configuration
|
||||
Configured in EasyS; visible and editable in **Packaging stations** view (Deliveries menu). Multiple users can pack simultaneously at the same station; each delivery is locked to one user/station.
|
||||
|
||||
### Key parameters
|
||||
|
||||
| Parameter | Description |
|
||||
|-----------|-------------|
|
||||
| `PACKAGING_CARRIER_MODE` | Carrier dock confirmation mode (AUTO/MANUAL/UNLOAD) |
|
||||
| `PACKAGING_VERIFY_TRACKING` | Force operator to confirm tracking code after printing |
|
||||
|
||||
## Operations
|
||||
|
||||
### Packaging process (RF or PC)
|
||||
1. Select packaging station
|
||||
2. Read stock origin (conveyor, container, location, ungrouping station)
|
||||
3. System creates/assigns delivery and packages
|
||||
4. Weight capture (if configured for carrier)
|
||||
5. Carrier label printed on label printer
|
||||
6. Delivery note printed (if configured)
|
||||
7. Deposit package at destination (dock, conveyor, or staging)
|
||||
|
||||
### Special packaging scenarios
|
||||
|
||||
**Client stock (3PL)**: packaging restricted to stock owned by the correct owner; system enforces owner isolation
|
||||
|
||||
**Cutting stock**: packaging uses cutting station measurement; support for extraction without packaging (pre-measured cuts)
|
||||
|
||||
**Damaged stock**: operator marks stock as damaged during packaging; excluded from shipment
|
||||
|
||||
**Postponement**: if packaging cannot be completed (some origins not yet read), delivery is postponed and auto-reopens when all origins become available
|
||||
|
||||
### Order merging
|
||||
For multiple shipping orders sharing the same delivery (same destination + contact + carrier), the merge operation groups them for joint preparation. Merged orders can be packed into a single package or split across multiple packages. Merge can be triggered manually or via ERP communication.
|
||||
|
||||
### Tracking code verification
|
||||
When `PACKAGING_VERIFY_TRACKING` is enabled and multiple users share a station, operators must confirm the tracking code on each label, ensuring correct delivery-to-package association.
|
||||
|
||||
## Errors & troubleshooting
|
||||
|
||||
| Issue | Cause | Resolution |
|
||||
|-------|-------|-----------|
|
||||
| Cannot create delivery | No carrier assigned to shipping order and no auto-selection rule matches | Assign carrier via SOR message or configure auto-selection rule |
|
||||
| Delivery locked by verification error | Verification web service returned error | Check carrier connectivity; system auto-reopens on successful verification |
|
||||
| Tracking number error | Carrier tracking files missing from server directory | Copy carrier-provided tracking files to configured archives directory |
|
||||
| Load manifest error (TNT) | TNT manifest report not configured | Configure `Load manifest report` in extended carrier setup |
|
||||
|
||||
## Related
|
||||
|
||||
- [[carrier]] — Carrier master data; extended carrier adds Multi-Carrier specific fields
|
||||
- [[shipping]] — Shipping order lifecycle; Multi-Carrier handles the packaging phase after order release
|
||||
- [[order-outbound]] — Delivery created from SOR message data; SOR `DlvShareDeliveries` flag controls order grouping
|
||||
- [[labels]] — Carrier labels (tracking barcode); delivery notes printed during packaging
|
||||
- [[ecommerce]] — eCommerce orders flow directly into Multi-Carrier packaging stations
|
||||
- [[cutting-stock]] — Special cutting stock packaging and extraction-without-packaging process
|
||||
@@ -0,0 +1,87 @@
|
||||
---
|
||||
title: "Owner Extensions"
|
||||
type: module
|
||||
sources:
|
||||
- areas/ownerextensions/index.md
|
||||
related:
|
||||
- modules/billing-3pl.md
|
||||
- modules/3pl-portal.md
|
||||
- modules/directives.md
|
||||
- concepts/order-inbound.md
|
||||
- concepts/order-outbound.md
|
||||
last_compiled: "2026-04-10"
|
||||
---
|
||||
|
||||
# Owner Extensions
|
||||
|
||||
## Overview
|
||||
|
||||
Owner Extensions is a prerequisite intermediate module that must be installed before using the **3PL Portal** and **Billing** modules. It enforces owner-level isolation across orders and master data, making it possible to manage multiple 3PL clients in the same warehouse with complete data separation.
|
||||
|
||||
The module adds a mandatory **owner field** to receipt orders and shipping orders, and enforces that all lines within an order belong to the same owner as the order header. It also adds owner scoping to key master data entities so that the same item, account, or supplier can exist independently per owner.
|
||||
|
||||
## Key capabilities
|
||||
|
||||
- Mandatory owner on receipt orders (inbound)
|
||||
- Mandatory owner on shipping orders (outbound)
|
||||
- Owner-isolated master data for 8 entity types
|
||||
- Code uniqueness per owner (concatenated code = owner + element code)
|
||||
- Foundation for 3PL Portal visibility filtering
|
||||
- Foundation for Billing contract assignment
|
||||
|
||||
## Architecture
|
||||
|
||||
### Owner enforcement on orders
|
||||
|
||||
| Order type | Effect |
|
||||
|------------|--------|
|
||||
| Receipt orders | Owner field becomes mandatory at creation; all lines must belong to the same owner |
|
||||
| Shipping orders | Owner field becomes mandatory at creation; all lines must belong to the same owner |
|
||||
|
||||
The owner requirement enables:
|
||||
- **3PL Portal**: filters all WMS views by the logged-in client's owner, so each 3PL client sees only their own stock, orders, and reports
|
||||
- **Billing**: uniquely identifies which 3PL contract each order and order line belongs to for economic valuation
|
||||
|
||||
### Owner-isolated master data
|
||||
|
||||
The following master data entities gain an owner field, making each record unique per owner:
|
||||
|
||||
| Entity | Notes |
|
||||
|--------|-------|
|
||||
| Companies | Owner-scoped company records |
|
||||
| Account types | Account type classifications per owner |
|
||||
| Accounts | End-customer accounts per owner |
|
||||
| Supplier types | Supplier type classifications per owner |
|
||||
| Suppliers | Supplier records per owner |
|
||||
| Item types | Item type classifications per owner |
|
||||
| Item families | Item family groupings per owner |
|
||||
|
||||
The element code is **concatenated with the owner** to ensure uniqueness. This prevents conflicts when the same item code, account, or supplier exists for multiple 3PL clients.
|
||||
|
||||
ERP integrations that send master data via communications must include the owner in the message so that records are correctly identified and no ambiguity exists when the same element exists across multiple owners.
|
||||
|
||||
### Exceptions (no owner required)
|
||||
|
||||
Two order types are exempt from the mandatory owner constraint:
|
||||
|
||||
| Exception | Reason |
|
||||
|-----------|--------|
|
||||
| Groups and fusions | A group may consolidate orders from multiple owners; requiring a single owner would prevent this use case |
|
||||
| Replenishments between warehouses | Internal warehouse replenishments may cross owner boundaries and do not follow single-owner shipping order logic |
|
||||
|
||||
For these exceptions, if the order code would normally be concatenated with the owner, the concatenation is skipped when the order involves multiple owners.
|
||||
|
||||
## Configuration
|
||||
|
||||
Owner Extensions is installed as an intermediate module during WMS deployment (not configured from the WMS interface). Once installed:
|
||||
1. Existing receipt and shipping order creation flows require owner selection
|
||||
2. Master data forms for the 8 entity types require owner selection
|
||||
3. 3PL Portal and Billing modules become installable
|
||||
|
||||
## Related
|
||||
|
||||
- [[billing-3pl]] — Requires Owner Extensions; uses the owner field on orders to assign lines to the correct billing contract
|
||||
- [[3pl-portal]] — Requires Owner Extensions; uses the owner field to filter all portal views to the logged-in client's owner
|
||||
- [[directives]] — Owner directives apply per-owner customization to shipping processes; Owner Extensions provides the owner field that enables this filtering
|
||||
- [[order-inbound]] — Receipt orders gain mandatory owner field with Owner Extensions installed
|
||||
- [[order-outbound]] — Shipping orders gain mandatory owner field with Owner Extensions installed
|
||||
@@ -0,0 +1,201 @@
|
||||
---
|
||||
title: "Pallet Shuttle"
|
||||
type: module
|
||||
sources:
|
||||
- areas/pallet_shuttle/index.md
|
||||
- areas/pallet_shuttle/ps.md
|
||||
- areas/pallet_shuttle/ps_user.md
|
||||
- areas/pallet_shuttle/agv_ps/index.md
|
||||
- areas/pallet_shuttle/agv_ps/agv_ps_extract.md
|
||||
- areas/pallet_shuttle/agv_ps/agv_ps_search.md
|
||||
- areas/pallet_shuttle/agv_ps/agv_ps_cancel_task.md
|
||||
- areas/pallet_shuttle/agv_ps/agv_ps_errors.md
|
||||
- areas/pallet_shuttle/agv_ps/ps_battery.md
|
||||
- areas/pallet_shuttle/agv_ps/parameters.md
|
||||
- areas/pallet_shuttle/ps_user/index.md
|
||||
- areas/pallet_shuttle/ps_user/ps_deposit.md
|
||||
- areas/pallet_shuttle/ps_user/ps_extraction.md
|
||||
- areas/pallet_shuttle/ps_user/ps_compact_location.md
|
||||
- areas/pallet_shuttle/ps_user/ps_count.md
|
||||
- areas/pallet_shuttle/ps_user/ps_status.md
|
||||
- areas/pallet_shuttle/ps_user/ps_special_func.md
|
||||
- areas/pallet_shuttle/ps_user/ps_configuration.md
|
||||
- areas/pallet_shuttle/ps_app/index.md
|
||||
- areas/pallet_shuttle/ps_app/ps_app_deposit.md
|
||||
- areas/pallet_shuttle/ps_app/ps_app_extraction.md
|
||||
- areas/pallet_shuttle/ps_app/ps_app_compact_location.md
|
||||
- areas/pallet_shuttle/ps_app/ps_app_PSDiagnosis.md
|
||||
- areas/pallet_shuttle/ps_app/ps_app_manual_mode.md
|
||||
- areas/pallet_shuttle/views/pallet_shuttle.md
|
||||
related:
|
||||
- modules/agv.md
|
||||
- concepts/location.md
|
||||
- concepts/container.md
|
||||
- concepts/task.md
|
||||
- concepts/stations.md
|
||||
last_compiled: "2026-04-10"
|
||||
---
|
||||
|
||||
# Pallet Shuttle
|
||||
|
||||
## Overview
|
||||
|
||||
The Pallet Shuttle module integrates motorized container transport carts (pallet shuttles) into Easy WMS warehouse operations. A pallet shuttle is a WIFI-controlled cart that moves autonomously within the deep channels of compact racking systems, transporting containers to and from the channel entrance without requiring a forklift to enter the aisle.
|
||||
|
||||
Each pallet shuttle operates in one of two storage modes:
|
||||
- **LIFO** (Last In First Out): loading and unloading always at the same channel end
|
||||
- **FIFO** (First In First Out): loading from one end, unloading from the other
|
||||
|
||||
The module eliminates the need for forklifts to reach deep positions, dramatically increasing storage density and reducing travel time. Operators control the shuttle via a tablet (SmartUI workstation or native app), while Easy WMS manages the stock movements. When the AGV module is also installed, pallet shuttle transport between channels is automated.
|
||||
|
||||
## Key capabilities
|
||||
|
||||
- Container deposit and extraction in compact rack channels (LIFO and FIFO modes)
|
||||
- Channel compaction (push containers toward front or back for space optimization)
|
||||
- Inventory count directly from the pallet shuttle interface
|
||||
- FIFO mode: automatic inversion detection (cart orientation tracked)
|
||||
- Battery management: automatic dispatch to charging station when low; auto-retrieval when full
|
||||
- AGV integration: automated PS relocation between channels without manual forklift intervention
|
||||
- Multi-site support: same PS can be registered in two different warehouses (for shared PS in multi-site)
|
||||
- Two control interfaces: SmartUI workstation (browser-based) and native tablet app (Windows UWP / iOS / Android)
|
||||
|
||||
## Architecture
|
||||
|
||||
### Pallet shuttle types
|
||||
Each PS hardware model is registered as a **pallet shuttle type** with:
|
||||
- Version (firmware)
|
||||
- Horn (for locating lost carts by sound)
|
||||
- Camera (assists forklift operators with placement)
|
||||
- Electromagnet (attaches to forklift forks for safe transport — required for AGV integration)
|
||||
- Maximum weight and compatible container types
|
||||
- Container type mapping (PS internally uses A, B, C… labels; mapping to WMS container types required)
|
||||
|
||||
### PS attributes
|
||||
|
||||
| Field | Description |
|
||||
|-------|-------------|
|
||||
| Number | Identifies the PS (labeled on the cart) |
|
||||
| IP address (PLC) | Network address for WMS communication |
|
||||
| IP address (camera) | Camera communication address |
|
||||
| Status | Available, faulty, mode, etc. |
|
||||
| Current task | Extraction, deposit, compacting, etc. |
|
||||
| Last known location | Last confirmed location of the cart |
|
||||
| Input aisle | For FIFO channels: the entry aisle code |
|
||||
| Estimated battery charging time (min) | 0–300; empty if not charging |
|
||||
|
||||
### PSService
|
||||
A service called **PSService** centralizes communication between tablets and the physical pallet shuttles. Both the SmartUI workstation app and the native tablet app use this service. **Note**: the two modes are mutually exclusive — the service is configured for either SmartUI or the native app, not both simultaneously.
|
||||
|
||||
### Native app modes
|
||||
- **Simple mode**: tablet → PSService → pallet shuttle (recommended for full WMS integration)
|
||||
- **Multi mode**: tablet communicates directly with PS (no WMS integration of stock movements)
|
||||
|
||||
## Configuration
|
||||
|
||||
1. Configure compact rack locations with appropriate storage mode (LIFO or FIFO) in EasyS/EasyAssistant
|
||||
2. Register pallet shuttle types with container type mappings
|
||||
3. Register individual pallet shuttles (IP, PLC, camera, type)
|
||||
4. Install and configure PSService (see implementation documentation)
|
||||
5. For AGV integration: configure AGV module, create routes between PS locations and AGV stations
|
||||
|
||||
### Key parameters (AGV-PS integration)
|
||||
|
||||
| Parameter | Default | Description |
|
||||
|-----------|---------|-------------|
|
||||
| `PS_MAX_MINUTES_BATTERY_FULL_LOAD` | 300 | Minutes of charging before battery considered 100% |
|
||||
| `PS_MIN_MINUTES_BATTERY_LOAD` | 90 | Minimum minutes charged before PS can be dispatched to tasks |
|
||||
|
||||
## Operations
|
||||
|
||||
### Manual operation (SmartUI workstation or native app)
|
||||
|
||||
**Deposit (putaway)**
|
||||
- **Simple deposit**: one container → placed at deepest available position
|
||||
- **Continuous deposit**: multiple containers sequentially into same channel; PS compacts after each
|
||||
- Putaway strategies must prevent mixing different items in the same channel
|
||||
|
||||
**Extraction**
|
||||
- **Simple extraction**: one container → brought to channel entrance
|
||||
- **Continuous extraction**: sequential extraction of multiple containers
|
||||
- Abort action stops PS immediately and deposits load at current depth
|
||||
|
||||
**Compaction**
|
||||
- **LIFO Compaction to outbound**: pushes all containers toward channel entrance (faster extraction)
|
||||
- **LIFO Compaction to inbound**: pushes all containers to channel back (maximizes entry space)
|
||||
- **FIFO Compaction**: pushes to extraction end (FIFO correctness and capacity maximization)
|
||||
- After physical compaction, operator must register the compaction in WMS to update available space
|
||||
|
||||
**Special functions**
|
||||
- Change last known location (if PS was moved manually)
|
||||
- Send PS to charging station (manual override via "Send PS to charging station" action)
|
||||
- Extract PS from charging station (manual via "Extract PS from charging station" action)
|
||||
|
||||
### AGV-PS integration operations
|
||||
|
||||
**PS search algorithm (when no PS is in a required channel)**
|
||||
Search criteria (all must be met):
|
||||
1. PS is activated and connected
|
||||
2. Mode is automatic
|
||||
3. Not on low battery
|
||||
4. Not linked to active receiving/shipping locations
|
||||
5. Not assigned to equipment
|
||||
6. Not in failure state
|
||||
7. Priority: closest to the target location
|
||||
|
||||
**PS transport flow** (load type = `1`, electromagnet activated at phase 06, deactivated at phase 10):
|
||||
- WMS sends PS transport order
|
||||
- AGV system accepts (00) → assigns AGV (03) → requests load permission (04)
|
||||
- WMS verifies PS is at load location → sends load auth
|
||||
- AGV confirms load (06) — electromagnet activated
|
||||
- AGV confirms unload (10) — electromagnet deactivated, new PS location reported
|
||||
|
||||
**FIFO specifics**: PS can be extracted from either end of channel. System tracks orientation (`inverted signal` field) to ensure correct placement direction.
|
||||
|
||||
**Error flag reset**: When AGV extracts/deposits a PS, error flags (tilt, fault) are reset and checked. If error persists after reset, all tasks for that PS are canceled and user is notified.
|
||||
|
||||
### Background jobs (AGV-PS mode)
|
||||
|
||||
| Job | Interval | Purpose |
|
||||
|-----|----------|---------|
|
||||
| Search waiting AGV tasks | 10s | Send pending tasks to AGV system |
|
||||
| Search fully charged PS | 5min | Extract PS from charging station when needed |
|
||||
| Search low battery PS | 10s | Dispatch low-battery PS to charging station |
|
||||
| Search tasks pending unload | 10s | Retry tasks stuck at unload permission |
|
||||
| Search tasks pending load | 10s | Retry tasks stuck at load permission |
|
||||
| Search channels with first position occupied | 10s | Execute deposit tasks for PS with waiting containers |
|
||||
|
||||
### Battery management
|
||||
|
||||
**Automatic (AGV required)**:
|
||||
- Low battery flag → WMS creates AGV task → PS transported to available charging station → charging time counter starts at 0 and counts to 300 (minutes)
|
||||
- Full charge (300 min, configurable via `PS_MAX_MINUTES_BATTERY_FULL_LOAD`) → AGV task created to extract PS **if** another PS needs the station or there are pending tasks with no other PS available
|
||||
- Minimum charge (`PS_MIN_MINUTES_BATTERY_LOAD` = 90 min) → PS can be extracted early if urgently needed
|
||||
|
||||
**Manual** (web interface, Pallet Shuttles view):
|
||||
- "Send PS to charging station" action (available when PS is not already at a charging station)
|
||||
- "Extract PS from charging station" action (available for PS at charging location)
|
||||
|
||||
## Errors & troubleshooting
|
||||
|
||||
### PS error indicators (AGV context)
|
||||
- **Fault flag**: Caused by multiple reasons. Reset → retry. If flag re-activates: all PS tasks canceled, user notified, PS unavailable for new tasks
|
||||
- **Tilt error**: PS mispositioned in channel. Reset → retry. Same cancellation behavior if persistent
|
||||
- **Low battery**: PS completes current tasks → returns to pickup position → disconnects → awaits AGV dispatch to charging. If no charging station available: user notified
|
||||
|
||||
### Extraction error (AGV picks up PS)
|
||||
Task canceled; location marked with "For AGV" lock type; user notified. No container relocation (PS was the payload, not a container).
|
||||
|
||||
### Putaway error (AGV deposits PS)
|
||||
Task canceled; PS relocated to available location with no pending tasks; location marked with "For AGV" lock type; user notified.
|
||||
|
||||
### Cancellation of AGV-PS tasks
|
||||
- **Task pending (waiting/pending shipping with CREATE action)**: Can be canceled — AGV system not yet involved
|
||||
- **Task in process (any other state)**: Cannot be canceled — movement will complete at destination
|
||||
|
||||
## Related
|
||||
|
||||
- [[agv]] — AGV module handles automated PS transport; all PS movements with AGVs use AGV task infrastructure
|
||||
- [[location]] — Compact rack channels (multi-deep) are the PS's operating environment; LIFO/FIFO mode per location
|
||||
- [[container]] — PS transports containers within channels; simple/continuous deposit and extraction
|
||||
- [[task]] — PS operations generate WMS tasks (putaway, extraction) tracked in the standard task system
|
||||
- [[stations]] — PS charge stations (type 66, PSCharge), PS type station in warehouse layout
|
||||
@@ -0,0 +1,142 @@
|
||||
---
|
||||
title: "Slotting"
|
||||
type: module
|
||||
sources:
|
||||
- areas/slotting/index.md
|
||||
- areas/slotting/slotting_desk/index.md
|
||||
- areas/slotting/slotting_desk/slotting_desk_demand.md
|
||||
- areas/slotting/slotting_desk/slotting_desk_slotting.md
|
||||
- areas/slotting/slotting_desk/slotting_desk_recommendation_picking.md
|
||||
- areas/slotting/slotting_desk/slotting_desk_generate_mov.md
|
||||
- areas/slotting/slotting_desk/slotting_desk_recommendation_job.md
|
||||
- areas/slotting/slotting_warehouse/slotting_warehouse_execute_move.md
|
||||
- areas/slotting/configuration/slotting_configuration.md
|
||||
- areas/slotting/parameters.md
|
||||
- areas/slotting/Jobs.md
|
||||
- areas/slotting/notificationevents.md
|
||||
related:
|
||||
- concepts/picking.md
|
||||
- concepts/replenishment.md
|
||||
- concepts/location.md
|
||||
- concepts/product-item.md
|
||||
- concepts/warehouse-designer.md
|
||||
last_compiled: "2026-04-10"
|
||||
---
|
||||
|
||||
# Slotting
|
||||
|
||||
## Overview
|
||||
|
||||
The Slotting module optimizes the placement of items in picking locations to minimize travel time and maximize space utilization. It analyzes item demand (historical, current, or forecasted), calculates optimal picking locations for each item based on distance from the shipping dock and rotation speed, and generates stock movement tasks to relocate items to their optimal positions.
|
||||
|
||||
Key benefits: reduced picking travel distances, balanced workloads, better space utilization, and data-driven continuous improvement.
|
||||
|
||||
**Scope**: manual warehouses only. Requires picking dedicated locations (PDL) configuration.
|
||||
|
||||
## Key capabilities
|
||||
|
||||
- Three demand analysis modes: historical, current (active orders), and future (external file import)
|
||||
- Item rotation ranking by stop speed (picks per day) and quantity speed
|
||||
- Recommendation algorithms: by PDL (dedicated picking locations) or by all picking locations
|
||||
- Golden zone: prioritizes locations at or below a configured height for ergonomic picking
|
||||
- Sub-warehouse and zone isolation: slotting stays within configured zones
|
||||
- Kit support: breaks down kit components for individual rotation analysis
|
||||
- Grouped picking awareness: wave/group/fusion orders counted accurately in stop calculations
|
||||
- Cost/benefit analysis: daily profit estimate per recommendation based on distance saved and operator cost
|
||||
- Continuous slotting job: automated periodic recommendations with notification when benefit threshold met
|
||||
- Warehouse 2D heat map: (with Slotting installed) displays picking activity intensity per location
|
||||
|
||||
## Architecture
|
||||
|
||||
### Slotting workflow
|
||||
|
||||
```
|
||||
1. Demand analysis → 2. Item rotation list → 3. Slotting recommendations → 4. Selection → 5. Movement generation → 6. Execution
|
||||
```
|
||||
|
||||
**Step 1 — Demand analysis**:
|
||||
- Historical: analyzes shipped orders in a configured time period
|
||||
- Current demand: analyzes active shipping orders (status: waiting, released; excludes grouped and replenishment orders)
|
||||
- External file: analyzes future demand data from user-provided file
|
||||
|
||||
**Step 2 — Item rotation list**:
|
||||
- Each item receives: Stop Speed (median picks/day), Quantity Speed (median units/day), Total quantity, Number of stops
|
||||
- List can be manually edited: add/remove items, adjust speeds
|
||||
|
||||
**Step 3 — Slotting recommendations**:
|
||||
- Two recommendation types:
|
||||
- **PDL only**: uses only existing picking dedicated locations; item assigned to PDL → replenishment manages stock
|
||||
- **All picking locations**: uses any location allowing picking; non-PDL locations get direct move tasks; PDL locations get assignment + replenishment
|
||||
|
||||
**Step 4 — Selection**:
|
||||
- User reviews recommendation list (Slotting view, sorted by daily profit estimate)
|
||||
- Selects items to slotting, discards others
|
||||
- "Allow picking dedicated location" action converts a non-PDL to PDL when executing
|
||||
- Red-highlighted rows = max capacity or max containers = 0 → must manually edit volumetrics before execution
|
||||
|
||||
**Step 5 — Movement generation**:
|
||||
- "Execute slotting" action generates movement tasks
|
||||
- PDL recommendations: new item assigned to PDL; old item unassigned; replenishment levels configured per `SLOTTING_REPLENISH_LEVEL`; slotting movement tasks for currently-in-place stock
|
||||
- Non-PDL recommendations: direct stock movement task from origin to slotting location
|
||||
|
||||
**Step 6 — Execution**:
|
||||
- Slotting tasks coexist with other warehouse tasks (no location blocking required)
|
||||
- Progress visible in Tasks view
|
||||
- Recommended procedure: execute in groups of items → move each group → repeat
|
||||
|
||||
### Daily profit calculation
|
||||
```
|
||||
Daily profit = (Distance_current_location - Distance_slotting_location) × (SLOTTING_VELOCITY × SLOTTING_COST_HOUR)
|
||||
```
|
||||
- Distance measured from location to reference shipping dock
|
||||
- Golden zone bonus: all locations at or below `SLOTTING_GOLDEN_ZONE` height are prioritized before higher locations
|
||||
|
||||
## Configuration
|
||||
|
||||
### Required setup
|
||||
1. Configure warehouse layout (aisles, shelf positions, dock reference) in EasyS/EasyAssistant
|
||||
2. Define picking dedicated locations with item assignments and volumetric data (volume, weight capacity)
|
||||
3. Configure slotting parameters (see below)
|
||||
|
||||
### Key parameters
|
||||
|
||||
| Parameter | Default | Description |
|
||||
|-----------|---------|-------------|
|
||||
| `SLOTTING_GOLDEN_ZONE` | 1.5 m | Maximum height for priority picking locations |
|
||||
| `SLOTTING_VELOCITY` | — | Average equipment speed (km/h) for distance/time calculation |
|
||||
| `SLOTTING_COST_HOUR` | — | Average operator cost per hour (€/h or currency unit) |
|
||||
| `SLOTTING_MAX_PL_PER_ITEM` | — | Maximum PDLs that can be assigned to one item |
|
||||
| `SLOTTING_MIN_PL_PER_ITEM` | — | Minimum PDLs per item |
|
||||
| `SLOTTING_CONTAINER_REPLENISH` | — | Whether replenishment is always by container |
|
||||
| `SLOTTING_REPLENISH_LEVEL` | — | Replenishment capacity configuration for PDLs after slotting |
|
||||
| `SLOTTING_BUFFER_LOCATION` | — | Buffer location code for slotting temporary storage |
|
||||
|
||||
### Continuous slotting job
|
||||
Automatically runs demand analysis and calculates recommendations periodically. If estimated daily benefit exceeds a configured threshold, sends notification to warehouse managers. Parameters control frequency and benefit threshold.
|
||||
|
||||
## Operations
|
||||
|
||||
### UI paths (PC)
|
||||
- **Item Rotation** view (Slotting menu): review and edit item rotation list
|
||||
- **Slotting** view (Slotting menu): review recommendations, select items, execute slotting
|
||||
- **Slotting Analysis** view (Slotting analysis menu): review historical analysis data
|
||||
- **Tasks** view: monitor generated slotting movement tasks
|
||||
|
||||
### Warehouse 2D heat map
|
||||
When the Slotting module is installed, the warehouse 2D map (Warehouse Designer) shows a heat map layer displaying picking activity intensity. Enables visual identification of hotspots and underutilized areas.
|
||||
|
||||
## Errors & troubleshooting
|
||||
|
||||
| Issue | Cause | Resolution |
|
||||
|-------|-------|-----------|
|
||||
| Red rows in Slotting view | Max capacity or max containers = 0 | Edit volumetrics for the location or item manually before executing |
|
||||
| Recommendation shows 0 benefit | Origin and destination location are the same | Already optimally placed; no movement needed |
|
||||
| Slotting tasks blocked | Location locks or stock reservations on origin/destination | Check task queue; slotting coexists but may be queued behind other tasks |
|
||||
|
||||
## Related
|
||||
|
||||
- [[picking]] — Slotting optimizes the locations where picking tasks are executed; PDLs feed replenishment
|
||||
- [[replenishment]] — After slotting, PDLs are managed by replenishment strategies (top-off, demand, etc.)
|
||||
- [[location]] — Picking dedicated locations are the target of slotting; volumetric data on locations required
|
||||
- [[product-item]] — Item rotation speed, ABC classification, and volume data drive slotting recommendations
|
||||
- [[warehouse-designer]] — 2D heat map visualization enabled with Slotting module
|
||||
@@ -0,0 +1,124 @@
|
||||
---
|
||||
title: "Store Fulfillment"
|
||||
type: module
|
||||
sources:
|
||||
- areas/store_fulfillment/index.md
|
||||
- custom/analyse_fonctionnelle.md
|
||||
related:
|
||||
- concepts/order-outbound.md
|
||||
- concepts/order-inbound.md
|
||||
- concepts/stock.md
|
||||
- concepts/replenishment.md
|
||||
- concepts/count.md
|
||||
last_compiled: "2026-04-26"
|
||||
---
|
||||
|
||||
# Store Fulfillment
|
||||
|
||||
## Overview
|
||||
|
||||
The Store Fulfillment module integrates retail store stock management with Easy WMS, enabling a central warehouse to supply one or more physical stores. It handles the full cycle: store stock orders, automatic replenishment, POS integration, store returns to warehouse, and store counting.
|
||||
|
||||
The module is designed for warehouses that simultaneously fulfill B2B/B2C shipments and supply their own retail stores.
|
||||
|
||||
## Key capabilities
|
||||
|
||||
- POS integration (Direct Selling Systems): sales/returns processed at POS automatically update WMS stock
|
||||
- On-demand store orders: stores request specific stock from the warehouse
|
||||
- Manual replenishment: warehouse sends stock to stores based on min/max review
|
||||
- Automatic replenishment: daily job maintains configured min/max stock levels at each store
|
||||
- Store returns: stock returned from stores back to warehouse
|
||||
- Store inventory counts: count existing stock in stores
|
||||
|
||||
## Architecture
|
||||
|
||||
### Layout constraints
|
||||
- **Star structure only**: one central warehouse supplies all remote stores (multi-hub not supported)
|
||||
- **No store-to-store**: direct transfers between stores are not supported
|
||||
- **No desk stations**: use local store stations instead of desk warehouse stations
|
||||
- **Multi-site**: each store is a separate site (warehouse) in the system
|
||||
|
||||
### POS integration flow
|
||||
|
||||
EasyWMS receives a **TPV01** message from the ERP (or POS connector) each time a sale or return is processed at a POS terminal:
|
||||
|
||||
1. Sale or customer return processed at POS terminal
|
||||
2. POS sends transaction to ERP
|
||||
3. ERP forwards a **TPV01** message to EasyWMS
|
||||
4. WMS **immediately decrements store stock** (sale) or increments (return) in real time
|
||||
5. No manual WMS action required for POS-driven stock changes
|
||||
|
||||
The real-time nature of TPV01 means EasyWMS always reflects the current store stock — no end-of-day reconciliation needed for POS transactions.
|
||||
|
||||
### Replenishment flows
|
||||
|
||||
| Mode | Trigger | Process |
|
||||
|------|---------|---------|
|
||||
| On-demand order | Store requests specific items | Creates outbound order from warehouse to store |
|
||||
| Manual replenishment | Warehouse reviews min/max | Operator initiates stock transfer to store |
|
||||
| Automatic replenishment | Daily job checks min/max levels | System generates transfers when stock below minimum |
|
||||
|
||||
### ERP integration (inter-warehouse transfers)
|
||||
|
||||
Store fulfillment transfers between central warehouse and stores can be ERP-driven via two dedicated messages:
|
||||
|
||||
| Message | Direction | Description |
|
||||
|---------|-----------|-------------|
|
||||
| **TOR01** | ERP → WMS | Transfer order: ERP requests a stock transfer from central warehouse to a store (or vice versa). WMS creates the corresponding outbound + inbound orders. |
|
||||
| **TOF01** | WMS → ERP | Transfer order finalization: WMS notifies ERP that the transfer has been completed (goods shipped from warehouse and received at store). |
|
||||
| **TPV01** | ERP → WMS | POS sale/return: decrements (sale) or increments (return) store stock in real time. |
|
||||
|
||||
TOR01/TOF01 follow the standard transfer order lifecycle managed by the Store Fulfillment module. They can also be used for store-to-warehouse returns.
|
||||
|
||||
### Real-time store stock view
|
||||
|
||||
Managers can view real-time stock per store from the WMS interface. The view shows:
|
||||
- Current stock quantity per item per store
|
||||
- Stock in transit (shipped from warehouse but not yet received at store)
|
||||
- History of POS transactions (TPV01 events)
|
||||
|
||||
## Configuration
|
||||
|
||||
### Prerequisites
|
||||
1. Configure star layout: central warehouse + remote store warehouses
|
||||
2. Configure store stations (local, not desk type)
|
||||
3. Set min/max stock levels per item per store
|
||||
4. Integrate POS systems via Store Fulfillment connector
|
||||
|
||||
### Key configuration options
|
||||
|
||||
| Option | Description |
|
||||
|--------|-------------|
|
||||
| Min/max stock levels | Trigger thresholds for automatic and manual replenishment |
|
||||
| POS connector | Integration settings for direct selling system |
|
||||
| Store layout | Local stations, not desk-type stations |
|
||||
|
||||
## Operations
|
||||
|
||||
**Store orders (warehouse perspective)**:
|
||||
1. Receive store order (manual or automated)
|
||||
2. Pick stock at central warehouse
|
||||
3. Ship to store via standard outbound process
|
||||
|
||||
**Store replenishment (automatic)**:
|
||||
- Daily job reviews all stores' stock levels
|
||||
- For items below minimum: generates transfer task to bring stock up to maximum
|
||||
- Executed during off-hours; stores receive stock next operating day
|
||||
|
||||
**Store returns**:
|
||||
- Store operator scans items for return via RFT
|
||||
- Stock transferred back to central warehouse
|
||||
- WMS creates receipt process for returned items
|
||||
|
||||
**Store counts**:
|
||||
- Operator counts store stock via RFT
|
||||
- Count process similar to standard location/item count
|
||||
- Results update store stock records
|
||||
|
||||
## Related
|
||||
|
||||
- [[order-outbound]] — Stock transfers from central warehouse to stores are outbound orders
|
||||
- [[order-inbound]] — Store returns processed as inbound orders
|
||||
- [[stock]] — Store stock maintained as separate WMS stock records per store warehouse
|
||||
- [[replenishment]] — Replenishment logic controls min/max levels and transfer generation
|
||||
- [[count]] — Store counting uses standard WMS count processes adapted for store environment
|
||||
@@ -0,0 +1,101 @@
|
||||
---
|
||||
title: "Supply Chain Event Management (SCEM)"
|
||||
type: module
|
||||
sources:
|
||||
- areas/supply_chain_event_management/index.md
|
||||
- areas/supply_chain_event_management/notificationevents.md
|
||||
- areas/supply_chain_event/index.md
|
||||
- areas/supply_chain_analytics/index.md
|
||||
related:
|
||||
- modules/3pl-portal.md
|
||||
- concepts/transactions.md
|
||||
- concepts/erp-interface.md
|
||||
last_compiled: "2026-04-10"
|
||||
---
|
||||
|
||||
# Supply Chain Event Management (SCEM)
|
||||
|
||||
## Overview
|
||||
|
||||
The Supply Chain Event Management module provides a configurable, real-time event notification system for the warehouse. It monitors warehouse events and alerts users through alarms via email, SMS, or web interface notifications. Users control which events they receive, on what channels, and on what schedule.
|
||||
|
||||
The module is the notification infrastructure underpinning all Easy WMS modules — every notification event in AGV, Pallet Shuttle, Billing, Yard Management, and other modules is delivered through SCEM.
|
||||
|
||||
## Key capabilities
|
||||
|
||||
- Event subscription: users subscribe to specific notification events per warehouse
|
||||
- Multi-channel delivery: web interface notification, email, SMS
|
||||
- Schedule-based notification profiles: different channels for different days/times
|
||||
- Delegated subscription: users can configure notifications on behalf of other users
|
||||
- Automatic system reactions: some events trigger automated system responses
|
||||
- Alarm monitoring: track outstanding alarms until resolved
|
||||
- Event escalation: if no action taken, alarm escalates to next subscriber level
|
||||
- Internal messaging: user-to-user internal messages through WMS interface
|
||||
- 3PL client notifications: subscribe external 3PL client organization users to warehouse events
|
||||
- Message language: notifications sent in the recipient's configured language (fallback: organization language)
|
||||
|
||||
## Architecture
|
||||
|
||||
### Core entities
|
||||
|
||||
**Notification event**: a defined event in the system (e.g., "AGV extraction error", "Billing generation error", "GNA import error"). Each module defines its own notification events.
|
||||
|
||||
**Notification group**: categorization of events (e.g., AGV, Communications, Billing). Users subscribe at the event level.
|
||||
|
||||
**Alarm**: an instance of a notification event that has been triggered. Tracked until resolved.
|
||||
|
||||
**Notification profile**: user-specific configuration of: event, channel (web/email/SMS), schedule (days of week, time ranges).
|
||||
|
||||
### ERP communication error notification (GNA)
|
||||
|
||||
The SCEM module includes a specific notification for ERP message processing failures:
|
||||
|
||||
| Code | Event |
|
||||
|------|-------|
|
||||
| `Notification_GNAImportError` | Error in exchange of information between ERP and WMS. Notifies warehouse, message type, error description, XML file generated, and date. |
|
||||
|
||||
Notification group: Communications. Can subscribe: SuperAdmin, Administrators, Managers.
|
||||
|
||||
### Subscription configuration options
|
||||
|
||||
| Mode | Description |
|
||||
|------|-------------|
|
||||
| Single subscription | User subscribes themselves to events and channels |
|
||||
| Delegated subscription | User A configures notifications for User B (email/SMS channels only) |
|
||||
| 3PL client subscription | Warehouse manager subscribes a 3PL client organization user to warehouse events |
|
||||
|
||||
## Configuration
|
||||
|
||||
### Notification profile setup
|
||||
1. Go to Organization > Notification profiles
|
||||
2. Select user and notification event
|
||||
3. Choose channel(s): web notification, email, SMS
|
||||
4. Set schedule: days and hours when each channel is active
|
||||
5. Optional: set escalation targets if alarm not acknowledged within time limit
|
||||
|
||||
### Common configuration examples (from documentation)
|
||||
- Subscribe to notifications and receive by email
|
||||
- Subscribe to notifications and receive by SMS
|
||||
- Subscribe a 3PL client organization's user to 3PL warehouse notifications
|
||||
- Subscribe to notifications and receive on web
|
||||
- Subscribe other users to receive notifications on web
|
||||
- Notify simultaneously on web and email (always or by schedule)
|
||||
- Filter notifications (select specific events from available set)
|
||||
|
||||
## Operations
|
||||
|
||||
### Alarm lifecycle
|
||||
1. Event occurs in warehouse → alarm generated
|
||||
2. Notification sent to subscribed users on their active channels
|
||||
3. User acknowledges and resolves the underlying issue
|
||||
4. Alarm marked as resolved
|
||||
5. If no action taken within escalation window: alarm escalated to next level subscriber
|
||||
|
||||
### Internal messaging
|
||||
Any Easy WMS user can send an internal message to another user. The recipient sees the message when they next log in. No channel configuration needed for internal messages.
|
||||
|
||||
## Related
|
||||
|
||||
- [[3pl-portal]] — 3PL client users can subscribe to SCEM notifications about their operations
|
||||
- [[transactions]] — Transaction events (STK.ADJ, CON.MOVE, etc.) can trigger SCEM notifications
|
||||
- [[erp-interface]] — GNA import errors (ERP communication failures) are notified via SCEM
|
||||
@@ -0,0 +1,111 @@
|
||||
---
|
||||
title: "VAS — Value Added Services"
|
||||
type: module
|
||||
sources:
|
||||
- areas/vas/index.md
|
||||
- areas/vas/Vas_admin/vas_activities.md
|
||||
- areas/vas/Vas_admin/vas_stations.md
|
||||
- areas/vas/Vas_config/Vas_admin/vas_templates.md
|
||||
- areas/vas/Vas_config/vas_screen_printing.md
|
||||
- areas/vas/Vas_config/vas_profile_stock.md
|
||||
- areas/vas/Vas_config/vas_container_plastic.md
|
||||
- areas/vas/Vas_config/vas_initial_configuration.md
|
||||
- areas/vas/TransactionTypes.md
|
||||
related:
|
||||
- concepts/shipping.md
|
||||
- concepts/order-outbound.md
|
||||
- modules/multi-carrier.md
|
||||
- concepts/stock.md
|
||||
- concepts/container.md
|
||||
last_compiled: "2026-04-10"
|
||||
---
|
||||
|
||||
# VAS — Value Added Services
|
||||
|
||||
## Overview
|
||||
|
||||
The Value Added Services (VAS) module enables the execution of extra value-adding operations on items or containers during the warehouse process — operations that enhance the value, functionality, or utility of goods before shipment. Examples include screen printing, labeling, palletizing, quality verification, and custom packaging.
|
||||
|
||||
VAS integrates natively with the shipping and packing flows, allowing VAS work orders to be created manually, received from ERP, or generated automatically from VAS profiles.
|
||||
|
||||
**Note**: VAS during the reception process (inbound VAS) is documented but **not yet supported** as of current version.
|
||||
|
||||
## Key capabilities
|
||||
|
||||
- VAS templates: define a sequence of activities and instructions for each service type
|
||||
- VAS profiles: automatically generate VAS orders based on stock and order characteristics
|
||||
- Integration points: VAS in shipping process (most common), VAS at packing station (Multi-Carrier Shipping integration)
|
||||
- ERP integration: VAS orders can arrive via SOR message (`VASCode` field) or via direct communication
|
||||
- Per-activity instructions: step-by-step instructions displayed to operators
|
||||
- Station-based execution: VAS operations performed at dedicated VAS stations
|
||||
- RF and web interface: confirmation of VAS activities from both RF terminals and web UI
|
||||
|
||||
## Architecture
|
||||
|
||||
### VAS building blocks
|
||||
|
||||
**VAS station**: a dedicated station configured in EasyS where VAS operations are performed. Multiple stations can be defined.
|
||||
|
||||
**VAS template**: a named sequence of activities, each with ordered instructions. Templates are reusable across multiple orders.
|
||||
|
||||
**VAS activity**: a specific operation step (e.g., "Screen printing", "Ironing", "Labeling"). Each activity has a code, description, and one or more instructions.
|
||||
|
||||
**VAS instructions**: step-by-step operator guidance within an activity (e.g., "Spread the garment well on the table for ironing").
|
||||
|
||||
**VAS order**: the actual work order generated for a shipment or reception, referencing a template and the stock to be processed.
|
||||
|
||||
### VAS in shipping process
|
||||
|
||||
1. Shipping order released
|
||||
2. Stock picked (standard picking process)
|
||||
3. VAS order created (manually from web, or received from ERP via SOR, or auto-generated from profile)
|
||||
4. Operator executes VAS activities at VAS station (RF or web confirmation)
|
||||
5. Standard shipping flow continues (consolidation, truck load, carrier)
|
||||
|
||||
### VAS profiles
|
||||
|
||||
VAS profiles automatically create VAS orders based on:
|
||||
- Whether the order is for shipping or inbound (profile type)
|
||||
- Stock characteristics (item, owner, account)
|
||||
|
||||
This eliminates manual VAS order creation for recurring service requirements.
|
||||
|
||||
## Configuration
|
||||
|
||||
### Initial setup
|
||||
1. Configure VAS stations in EasyS (station type: VAS)
|
||||
2. Configure routes from picking/staging areas to VAS stations
|
||||
3. Create VAS templates with activities and instructions
|
||||
4. (Optional) Create VAS profiles for automatic order generation
|
||||
5. Assign VAS templates to shipping orders (manually, via ERP SOR message, or via profile)
|
||||
|
||||
### VAS station configuration
|
||||
VAS stations are defined in EasyS/EasyAssistant. They require routes from the areas where picked stock arrives. Multiple VAS stations allow parallel processing of VAS orders.
|
||||
|
||||
## Operations
|
||||
|
||||
### Shipping VAS execution
|
||||
1. After stock is picked, operator goes to VAS station
|
||||
2. Select VAS order from RF menu or workstation
|
||||
3. For each activity in the template, operator reads instructions and confirms completion
|
||||
4. All activities confirmed → VAS order closed
|
||||
5. Stock continues to consolidation/shipping
|
||||
|
||||
### Packing station VAS (Multi-Carrier integration)
|
||||
VAS activities can be executed directly at the Multi-Carrier packing station. This allows VAS (e.g., labeling, wrapping) to occur during the packaging process without a separate VAS station visit.
|
||||
|
||||
### ERP integration (SOR message)
|
||||
The SOR (Shipping Order Request) message supports a `VASCode` field that specifies which VAS template to apply to the order. This enables automated VAS order creation for orders arriving from ERP.
|
||||
|
||||
### Use case examples from documentation
|
||||
1. **Screen printing of clothing**: VAS template "Textile personalization" with Activity 1 "Screen printing" (3 instructions) + Activity 2 "Labeling"
|
||||
2. **Client stock with custom profile**: VAS profile auto-generates orders for specific owner stock
|
||||
3. **Full container palletizing (container plastic)**: VAS applied at container level for plastic wrapping
|
||||
|
||||
## Related
|
||||
|
||||
- [[shipping]] — VAS orders are created within the shipping process after picking and before consolidation
|
||||
- [[order-outbound]] — SOR message `VASCode` triggers VAS order creation at order reception
|
||||
- [[multi-carrier]] — VAS can be executed at Multi-Carrier packing stations
|
||||
- [[stock]] — VAS operations may alter stock characteristics (quality status, packaging)
|
||||
- [[container]] — Container-level VAS (e.g., full container palletizing) affects container attributes
|
||||
@@ -0,0 +1,158 @@
|
||||
---
|
||||
title: "Yard Management"
|
||||
type: module
|
||||
sources:
|
||||
- areas/yard_management/index.md
|
||||
- areas/yard_management/yard_appointments/index.md
|
||||
- areas/yard_management/yard_appointments/yard_appointments.md
|
||||
- areas/yard_management/yard_appointments/yard_checkpoints.md
|
||||
- areas/yard_management/configuration/initial_configuration.md
|
||||
- areas/yard_management/ERP.md
|
||||
- areas/yard_management/notificationevents.md
|
||||
- areas/yard_management/views/view_appointments.md
|
||||
- areas/yard_management/views/configuration/view_yards.md
|
||||
- areas/yard_management/views/configuration/view_vehicle_types.md
|
||||
- areas/yard_management/views/configuration/view_commodity_types.md
|
||||
- areas/yard_management/views/configuration/view_components.md
|
||||
- areas/yard_management/views/configuration/view_dock_strategies.md
|
||||
- areas/yard_management/views/configuration/view_routes.md
|
||||
related:
|
||||
- concepts/order-inbound.md
|
||||
- concepts/order-outbound.md
|
||||
- concepts/shipping.md
|
||||
- concepts/reception.md
|
||||
- concepts/stations.md
|
||||
last_compiled: "2026-04-10"
|
||||
---
|
||||
|
||||
# Yard Management
|
||||
|
||||
## Overview
|
||||
|
||||
The Yard Management System (YMS) module monitors and manages vehicle movements in the warehouse yard — from driver check-in through dock assignment to check-out. It provides dock scheduling capabilities that synchronize vehicle flows with warehouse inbound/outbound operations.
|
||||
|
||||
The module reduces wait times, eliminates bottlenecks, optimizes dock utilization, improves on-time performance, and provides security/access control for the yard.
|
||||
|
||||
## Key capabilities
|
||||
|
||||
- Appointment management: pre-scheduled vehicle slots with dock assignment strategies
|
||||
- Check-in / check-out: checkpoint-based vehicle identification and tracking
|
||||
- Dock assignment: rule-based automatic strategies (commodity type, vehicle type, time slot, proximity)
|
||||
- Parking management: waiting area assignment while dock is not ready
|
||||
- ERP/TMS integration: appointments can be created/modified via external messages
|
||||
- Loan phone management: facility phones lent to drivers for in-yard communication (SMS)
|
||||
- Vehicle weight control: scale integration at checkpoints
|
||||
- Visual schedule: interactive calendar view of all dock appointments
|
||||
- Auxiliary appointments: non-logistics events (maintenance, visits) in facility locations
|
||||
|
||||
## Architecture
|
||||
|
||||
### Yard components
|
||||
A **yard** contains:
|
||||
- **Warehouses**: served by the yard (one warehouse can only belong to one yard; all its docks managed through that yard)
|
||||
- **Checkpoints**: entry/exit points where check-in/check-out is performed; each has a work mode (receiving/shipping/both)
|
||||
- **Parking lots**: waiting areas for vehicles before dock assignment
|
||||
- **Docks**: loading/unloading points (configured in EasyS); each dock has commodity type and vehicle type compatibility
|
||||
- **Paths**: defined routes between yard components with distance values (used for dock assignment optimization)
|
||||
|
||||
### Appointment entity
|
||||
|
||||
**Core appointment attributes**:
|
||||
|
||||
| Field | Description |
|
||||
|-------|-------------|
|
||||
| Code | Appointment identifier |
|
||||
| Status | Pending → Waiting → Pending dock decision → In process → Pending check-out → Finished / Canceled |
|
||||
| Priority | Urgent / High / Normal / Low / Very low (affects dock assignment queue) |
|
||||
| Type | Receiving (vehicle enters loaded), Shipping (vehicle enters empty), Auxiliary |
|
||||
| Warehouse | Which warehouse the appointment serves |
|
||||
| Yard | Which yard the vehicle enters |
|
||||
| Planned receiving/shipping dates | Scheduled times |
|
||||
| Real receiving/shipping dates | Actual times (auto-recorded by system) |
|
||||
|
||||
**Work order association**:
|
||||
- **Receiving appointments**: must associate a receipt (status: Reception pending) or inbound order (Waiting/Reception pending/Receiving/Partially received)
|
||||
- **Shipping appointments**: must associate a load (Open/Paused) or outbound order (Waiting/Released/Partially released/Pausing/Secured/Assigned)
|
||||
|
||||
**Vehicle attributes**:
|
||||
- Carrier, plate number, vehicle type, driver(s), driver language (for SMS/notifications in driver's language)
|
||||
- Maximum/receiving/shipping weight (for scale integration)
|
||||
|
||||
### Appointment status flow
|
||||
|
||||
```
|
||||
Pending → Waiting (check-in done, in parking) → Pending dock decision (manual dock review)
|
||||
→ In process (at dock, loading/unloading) → Pending check-out → Finished
|
||||
Pending → Canceled
|
||||
```
|
||||
|
||||
### Dock assignment strategies
|
||||
Configurable rules combining:
|
||||
- Commodity type compatibility
|
||||
- Vehicle type compatibility
|
||||
- Time slot availability
|
||||
- Distance minimization (shortest path from default checkpoint to dock)
|
||||
- Priority-based queue management for waiting vehicles
|
||||
|
||||
## Configuration
|
||||
|
||||
### Initial setup sequence
|
||||
1. Define **yard** (link to all warehouses served)
|
||||
2. Define **checkpoints** (entry/exit points; mark one as default)
|
||||
3. Register **loan phones** (available for drivers; initial location = a checkpoint)
|
||||
4. Define **parking lots** (waiting areas)
|
||||
5. Define **vehicle types** (allowed in this yard)
|
||||
6. Define **commodity types** (types of goods handled; dock compatibility)
|
||||
7. Define **paths** between all yard components (distance values for optimization)
|
||||
8. Configure **dock compatibility** per dock (commodity types + vehicle types)
|
||||
9. Define **dock assignment strategies**
|
||||
10. Define **facility locations and activities** (for auxiliary appointments)
|
||||
|
||||
**Note**: Docks are configured in EasyS or Easy Assistant; routes between yard elements must exist in the warehouse layout.
|
||||
|
||||
### ERP/TMS integration
|
||||
Appointments can be created and modified via ERP or TMS communications. When a work order associated with an appointment is canceled (manually or via ERP), if the vehicle hasn't checked in yet, the appointment is automatically canceled.
|
||||
|
||||
## Operations
|
||||
|
||||
### Appointment creation
|
||||
Manual creation via Appointments view (Yard menu). Required fields vary by appointment type:
|
||||
- Receiving: carrier, vehicle, driver, planned dates, associated receipt or inbound order
|
||||
- Shipping: carrier, vehicle, driver, planned dates, associated load or outbound order
|
||||
- Auxiliary: facility location, activity type
|
||||
|
||||
### Check-in process
|
||||
1. Vehicle arrives at checkpoint
|
||||
2. Checkpoint user verifies vehicle plate and driver data
|
||||
3. Weight recorded (if checkpoint has scale)
|
||||
4. System assigns vehicle to available parking lot
|
||||
5. When dock becomes available (via assignment strategy or manual decision): vehicle directed to dock
|
||||
6. Appointment transitions to "In process"
|
||||
7. Dock association updated automatically if rescheduled
|
||||
|
||||
### Check-out process
|
||||
1. Loading/unloading operation completes (work order finished + vehicle preparation time elapses)
|
||||
2. Appointment transitions to "Pending check-out"
|
||||
3. Checkpoint user confirms vehicle exit
|
||||
4. Exit weight recorded (if scale available)
|
||||
5. Loan phone returned (if issued)
|
||||
6. Appointment status: Finished
|
||||
|
||||
### Visual schedule
|
||||
Interactive calendar showing all dock appointments, filtered by dock, date range, appointment type. Supports drag-and-drop rescheduling and visual conflict detection.
|
||||
|
||||
## Errors & troubleshooting
|
||||
|
||||
| Issue | Cause | Resolution |
|
||||
|-------|-------|-----------|
|
||||
| Cannot assign dock to appointment | Dock not compatible with appointment's commodity or vehicle type | Check dock compatibility configuration; add required compatibility |
|
||||
| Vehicle outside allowed advance/delay window | Vehicle arrived too early or too late for check-in | Adjust allowed advance/delay time in yard configuration |
|
||||
| Appointment auto-canceled | Work order canceled while vehicle not yet checked in | This is correct behavior; create new appointment if needed |
|
||||
|
||||
## Related
|
||||
|
||||
- [[order-inbound]] — Receiving appointments must be linked to receipt or inbound orders
|
||||
- [[order-outbound]] — Shipping appointments must be linked to loads or outbound orders
|
||||
- [[shipping]] — Loads and routes are the work order types for shipping appointments
|
||||
- [[reception]] — Receipts are the work order types for receiving appointments
|
||||
- [[stations]] — Docks are WMS station types; dock/stage configuration in Warehouse Designer
|
||||
Reference in New Issue
Block a user