màj wiki avec retour MES lot-5 AD

This commit is contained in:
Arthur Ria
2026-05-20 09:41:27 +02:00
commit 23eb3f3c84
4106 changed files with 469381 additions and 0 deletions
+249
View File
@@ -0,0 +1,249 @@
---
title: "Application Dictionary (AD)"
type: architecture
sources:
- CLAUDE.md context (AD API knowledge)
- areas/ERP.md
- areas/TransactionTypes.md
- Cross-source knowledge from all batches
related:
- architecture/overview.md
- architecture/entities-map.md
- concepts/erp-interface.md
- concepts/transactions.md
last_compiled: "2026-04-10"
---
# Application Dictionary (AD)
## Overview
The **Application Dictionary (AD)** is the core metadata framework of Easy WMS. Rather than hardcoding business logic, the system defines all operations, data structures, and UI elements as configurable AD elements stored in the database. This makes Easy WMS highly customizable: partners and customers can extend or modify behavior without touching application code.
The AD contains approximately **38,765 elements** spanning Commands, Queries, Dialogs, Views, Entities, Events, Workflows, and more. Every UI action, every RF terminal screen, and every API call is backed by one or more AD elements.
## AD Element Types
### Commands
Commands represent **executable operations** — actions that change system state.
- Mapped to `POST /api/commands/{commandName}` in the API
- Have input parameters (validated before execution) and return a result
- May trigger Transactions (audit records) and Events
- May invoke sub-commands or start Workflows
- Examples:
- `ReceiveContainer` — receive a container at a dock station
- `ReleaseShippingOrder` — release a shipping order for picking
- `AdjustStock` — perform a quantity adjustment
- `CreateCount` — create a physical count order
- `AssignTask` — assign a task to an operator
Commands are permission-controlled: each command is associated with one or more AD roles. A user can only execute commands their role permits.
### Queries
Queries represent **data retrieval operations** using a LINQ-style expression engine.
- Mapped to `GET /api/queries/{queryName}` or `POST /api/queries/execute` (dynamic)
- Support filtering, sorting, pagination
- Can reference any View or Entity
- Examples:
- `GetStockByLocation` — fetch stock for a location
- `GetOpenShippingOrders` — fetch all non-closed shipping orders
- `GetContainerContents` — fetch stock lines in a container
- `GetTasksByStatus` — fetch tasks matching a status
The **QueryExecute API** allows ad-hoc LINQ queries without pre-defining a named Query element.
### Entities
Entities are the **core data objects** of the system — the persistent domain model.
Each Entity has:
- A schema (fields, types, constraints)
- CRUD operations accessible via `GET/POST/PUT/DELETE /api/entities/{entityName}`
- Relations to other Entities
- Business rules enforced on create/update/delete
Key Entities (from all compiled batches):
| Entity | Description |
|--------|-------------|
| `Container` | LPN with type, weight, status, lock, location |
| `Location` | Physical or virtual storage position |
| `Stock` | Stock line: item + qty + UoM + logistic attributes + container + location |
| `Item` (Product) | SKU master with types, families, UoM, profiles |
| `ReceiptOrder` | Inbound order (supplier/return/transfer) |
| `Receipt` | Physical receiving event linked to receipt orders |
| `ShippingOrder` | Outbound order (customer/transfer/return) |
| `Task` | Movement task with type, origin, destination, status |
| `Count` | Inventory count order with lines and status |
| `Route` | Carrier route with loads and departure schedule |
| `Load` | Truck load linked to a route |
| `Station` | Warehouse station configuration |
| `Owner` | Stock owner (for 3PL multi-tenancy) |
| `Account` | Customer/delivery account |
| `Supplier` | Vendor master |
| `Carrier` | Shipping carrier master |
| `Delivery` | Multi-Carrier delivery (carrier + consignee) |
| `ContainerType` | LPN type definition |
| `ItemType` / `ItemFamily` | Item classification hierarchy |
| `UoM` | Unit of Measure with conversions |
| `Zone` | Storage or working zone |
| `SubWarehouse` | Logical sub-division of warehouse |
| `Equipment` | Warehouse equipment (forklift, RFT, conveyor) |
| `UserStatus` | Stock quality status definition |
| `VASTemplate` | Value Added Services template |
| `Kit` | Kit definition with components |
| `Appointment` | Yard Management appointment |
| `Slot` | Slotting recommendation |
| `LaborActivity` | LMS activity record |
| `BillingContract` | 3PL billing contract |
| `DOMNode` | Distributed Order Management node |
### Views
Views are **read-only projections** of one or more Entities, optimized for display and reporting.
- Accessible via `GET /api/views/{viewName}` or QueryExecute
- Often join multiple entities (e.g., stock + container + location + item)
- May include computed columns and aggregations
- Back all SmartUI list screens and RF terminal display screens
- Examples:
- `ViewContainers` — containers with location and status
- `ViewStocks` — stock lines with full context
- `ViewTasksOpen` — open tasks with assignment info
- `ViewShippingOrdersMonitor` — order monitoring dashboard
- `ViewGroupedStock` — aggregated stock by item/owner
### Dialogs
Dialogs are **multi-step interactive flows** that guide an operator through a complex operation.
- Used primarily in RF terminals and workstation screens
- Each Dialog has **steps** (screens), each advancing the flow
- State is maintained server-side between steps
- API: `POST /api/dialogs/{dialogName}/start`, then `POST /api/dialogs/{sessionId}/step`
- Examples:
- `ReceptionDialog` — multi-step reception flow (select order → scan container → enter quantities → confirm)
- `PickingDialog` — guided picking (scan location → confirm quantity → scan destination)
- `CountDialog` — count guided flow (scan location → count items → confirm)
- `ShippingConsolidationDialog` — consolidation at shipping station
Dialogs encapsulate the complete operator interaction sequence for a process, invoking Commands internally at each confirmation step.
### Events
Events are **system notifications** that fire when certain state transitions occur.
- Triggered automatically by Commands (not by users directly)
- Can invoke Workflows, send notifications (SCEM), or trigger ERP messages
- Examples:
- `OnShippingOrderClosed` → triggers SOF ERP message + SOC status change notification
- `OnReceiptOrderStatusChange` → triggers ROC ERP message
- `OnStockExpired` → fires `EasyWMS_StockExpired` notification event
- `OnContainerReceived` → triggers ASO ERP message (if ASN container)
- `OnTaskGenerated` → notifies AGV controller (automatic warehouse)
Events decouple the triggering action from downstream reactions, enabling clean extension without modifying core logic.
### Workflows
Workflows are **orchestrated sequences** of Commands, conditional logic, and state transitions.
- Used for complex multi-step processes: reception, putaway strategy evaluation, replenishment logic
- Can be synchronous (blocking) or asynchronous (background)
- Examples:
- `PutawayWorkflow` — 8-stage pipeline (criteria → aisles → balancing → restrictions → validity → rules → sort → select)
- `StockAssignmentWorkflow` — evaluate assignment strategies → assign to shipping order lines
- `ReplenishmentWorkflow` — check PDL levels → select strategy → generate tasks
- `DefragmentationWorkflow` — evaluate rotation/shipping criteria → generate movement tasks
- `CountCloseWorkflow` — close count → compute differences → generate STK.ADJ transactions → send COF to ERP
### Background Jobs
Background Jobs are **scheduled or continuous Workflows** that run autonomously:
| Job | Trigger | Workflow Invoked |
|-----|---------|-----------------|
| `TryToReplenishProductLocations` | Continuous | ReplenishmentWorkflow |
| `Delete_StockStatusJob_PR` | Every 15 min | QualityUnlockWorkflow |
| `CycleCountGenerationJob` | Per schedule | CountGenerationWorkflow |
| `DefragmentationPlannerJob` | Per schedule | DefragmentationWorkflow |
| `SlottingAnalysisJob` | Configurable | SlottingWorkflow |
| `MetricGathererJob` | Configurable | DataAnalyticsWorkflow |
| `AGVCommunicationJob` | Continuous | AGVProtocolWorkflow |
| `PSServiceJob` | Continuous | PalletShuttleWorkflow |
### Parameters
AD Parameters are the **configuration knobs** of the system — named key-value pairs that alter behavior without code changes.
- Scope: Organization or Warehouse
- Accessible via the Parameters view in SmartUI (Inventory > Parameters)
- Read by Commands, Workflows, and Background Jobs at runtime
- See [Parameters](../concepts/parameters.md) for the full compiled catalog
## AD API Access Patterns
### Reading data (QueryExecute)
```http
POST /api/queryexecute
{
"query": "Stock.Where(s => s.LocationCode == 'A0101' && s.ItemCode == 'SKU001')",
"site": "WH01"
}
```
### Executing a command
```http
POST /api/commandexecute
{
"command": "ReleaseShippingOrder",
"parameters": {
"ShippingOrderCode": "SO-20260410-001",
"Site": "WH01"
}
}
```
### Reading an entity
```http
GET /api/entities/ShippingOrder/SO-20260410-001?site=WH01
```
## AD Element Naming Conventions
Based on patterns observed across documentation:
- **Commands**: PascalCase verb-noun (`ReceiveContainer`, `ReleaseOrder`, `AdjustStock`)
- **Queries**: `Get` + PascalCase noun (`GetStockByLocation`, `GetOpenTasks`)
- **Entities**: PascalCase noun (`Container`, `Stock`, `ShippingOrder`)
- **Views**: `View` + PascalCase noun (`ViewContainers`, `ViewStocks`)
- **Dialogs**: Context + `Dialog` suffix (`ReceptionDialog`, `PickingDialog`)
- **Events**: `On` + PascalCase noun+verb (`OnShippingOrderClosed`)
- **Parameters**: `SCREAMING_SNAKE_CASE` (`MAX_DEFRAG_TASKS`, `ECOMMERCE_RECEPTION_ALLOW_AUTOSELECTION`)
- **Transactions**: `ENTITY.VERB` dot notation (`CON.MOVE`, `STK.ADJ`, `OUT.CLS`)
- **ERP Messages**: 3-letter uppercase code (`SOR`, `ROC`, `STR`)
## Extension Points
The AD can be extended by Mecalux partners:
1. **Custom Commands**: Add new business operations
2. **Custom Views**: Expose new data projections
3. **Custom Workflows**: Override or extend default process logic
4. **Custom Parameters**: Add module-specific configuration
5. **Custom Events**: React to standard system events with custom logic
This extensibility model is used by all optional modules (AGV, Slotting, 3PL Billing, DOM, etc.) — each module adds its own AD elements without modifying core elements.
## Related
- [Overview](overview.md) — System architecture and deployment
- [Entities Map](entities-map.md) — Visual map of entity relationships
- [Transactions](../concepts/transactions.md) — Transaction audit trail (generated by Commands)
- [ERP Interface](../concepts/erp-interface.md) — ERP messages (triggered by Events)
- [Parameters](../concepts/parameters.md) — System parameter catalog
+466
View File
@@ -0,0 +1,466 @@
---
title: "Entities Relationship Map"
type: architecture
sources:
- Synthesized from all Batch 1-5 compiled wiki pages
- areas/TransactionTypes.md
- areas/ERP.md
- All ERP message files
- All concept and module pages
related:
- architecture/application-dictionary.md
- architecture/overview.md
- concepts/container.md
- concepts/location.md
- concepts/stock.md
- concepts/product-item.md
- concepts/task.md
- concepts/order-inbound.md
- concepts/order-outbound.md
- concepts/erp-interface.md
last_compiled: "2026-04-10"
---
# Entities Relationship Map
## Overview
This page provides the complete entity relationship model of Easy WMS, synthesized from all documented behavior across Batches 15. It shows the core entities, their key attributes, and how they relate to one another — forming the mental model needed to interpret WMS data.
## Core Entity Hierarchy
```
Organization
└── Site (Warehouse)
├── Zones (Storage / Working)
│ └── Aisles
│ └── Racks / Shelves
│ └── Locations ──────────────── contains ──→ Containers
│ └── Stock lines
├── SubWarehouses
│ └── Locations (scoped)
├── Stations (Dock / PIE / PK / PS / MU / ME / etc.)
│ └── Routes (Simple / Composed)
│ └── Route Managers (Galileo / RF / Voice / PTL / External)
├── Equipment (Forklifts / AGVs / Conveyors)
└── Users
└── Roles → Station Roles
```
## Primary Entity Relationships
### Location → Container → Stock
The fundamental storage chain:
```
Location (1) ←── stored_at ──── (N) Container
Container (1) ←── held_in ──── (N) Stock
Stock (N) ──── is_of_type ────→ (1) Item
Stock (N) ──── owned_by ───────→ (1) Owner
```
| Relationship | Cardinality | Notes |
|-------------|-------------|-------|
| Location → Container | 1:N | One location can hold multiple containers (stacking) |
| Container → Stock | 1:N | One container can hold multiple stock lines |
| Container → Container | 1:N | Stacked containers; outer container holds inner |
| Stock → Item | N:1 | Multiple stock lines for same item (different lot/location) |
| Stock → UoM | N:1 | Each stock line has one UoM |
| Stock → Owner | N:1 | Stock belongs to one owner |
### Orders → Stock → Task
The fulfillment chain:
```
ReceiptOrder (1) ←── fulfilled_via ──── (N) Receipt
Receipt (1) ─────── creates ──────────→ (N) Container (received containers)
Receipt (1) ─────── creates ──────────→ (N) Stock (loose stock)
ReceiptOrder (1) ←── associated ──── (N) Container (ASN pre-notified)
ShippingOrder (1) ←── assigned_from ── (N) Stock (reservations)
ShippingOrder (1) ─── generates ──────→ (N) Task (picking tasks)
Task (1) ────────────── moves ─────────→ (N) Container
Task (1) ────────────── moves ─────────→ (N) Stock
Task (N) ─────────────── assigned_to ──→ (1) User / Equipment
```
### Container Lifecycle Relationships
```
Container ──── received_at ─────→ Location (Dock/PIE/PK/ASN)
Container ──── moved_to ─────────→ Location (via putaway Task)
Container ──── picked_from ──────→ Location (via picking Task)
Container ──── shipped_to ───────→ Location (Dock/Stage)
Container ──── loaded_on ────────→ Load (truck loading)
Container ──── consolidated_into → Container (client container)
Container ──── stacked_on ───────→ Container (stacking)
Container ──── locked_by ────────→ ContainerLock (N lock types)
```
## Detailed Entity Attribute Map
### Container
```
Container {
Code* → unique LPN identifier
TypeCode → ContainerType (dimension, weight capacity)
Weight → actual weight
Status → Received / In Transit / Located / Shipped / Deleted
LocationCode → current Location (nullable if in transit)
OwnerCode → Owner (nullable)
ReceiptCode → source Receipt (if received via reception)
ASNCode → advance shipping notice code (if pre-notified)
Locks[] → active ContainerLock list
StackedOn → parent Container (if stacked)
Divisions[] → cutting stock divisions (if applicable)
}
```
### Location
```
Location {
Code* → ASXY format (Aisle+Section+X+Y) or virtual code
Type → Conventional/Compact/APS/APSFIFO/Dynamic/Pushback/
Cantilever/Buffer/Dock/Equipment/Conveyor/Virtual
ZoneCode → storage Zone
SubWarehouseCode→ SubWarehouse (optional scoping)
StorageMode → Single container / Multi-container / Loose stock
StorageLogic → 12 flags (fifo/lifo/fefo/stack/mix items/mix lots/etc.)
Locks[] → active LocationLock list (8 operation types)
Capacity → weight/height/container count limits
Features[] → compatibility flags for putaway restrictions
IsPickingDedicated → boolean (PDL flag)
VirtualType → ASN / LostFound / Mov (if virtual)
}
```
### Stock
```
Stock {
ItemCode* → Item
UoMCode* → Unit of Measure
Quantity* → current quantity
ContainerCode → Container (nullable for loose stock)
LocationCode → Location
OwnerCode → Owner
ReceivingStatus → quality status set at reception (clear/locked)
UserStatus → quality status set by user/ERP (0..N statuses)
LogisticAttributes {
Lot, SerialNumber, ExpiryDate, BestBefore, ProductionDate,
DaysOfLife, Color, Size, Version, Weight, ... (item-specific)
}
ReservedQty → quantity reserved for ShippingOrder lines
AssignedQty → quantity assigned to Tasks
}
```
### Task
```
Task {
Number* → unique task ID
ProcessType → Putaway/Picking/Shipping/Replenishment/Count/
Movement/Consolidation/etc.
Status → Pending/Generated/InProcess/Finished/Canceled
ContainerCode → Container being moved (nullable)
LocationFrom → source Location
LocationTo → destination Location
ShippingOrderCode → linked ShippingOrder (if picking/shipping task)
CountCode → linked Count (if count task)
AssignedUser → User assigned to execute
AssignedEquipment → Equipment (AGV, forklift)
Priority → Urgent/High/Normal/Low/VeryLow
Route → Route/Station path for automatic warehouse
Movements[] → decomposed Movement steps (compound routes)
}
```
### Receipt Order (Inbound Order)
```
ReceiptOrder {
Code* → unique order code
Type → Supplier/Return/Transfer
Status → Created/Waiting/Pending/Receiving/PartiallyReceived/
Received/Closed/Canceled
SupplierCode → Supplier (if type=Supplier)
Lines[] {
Number, ItemCode, ExpectedQty, ReceivedQty, FreeQty, UoMCode
}
Receipts[] → linked Receipts (physical receiving events)
Containers[] → ASN pre-notified Containers
ERP_Source → ROR message code (if from ERP)
}
```
### Shipping Order (Outbound Order)
```
ShippingOrder {
Code* → unique order code
Type → Customer/Return/Transfer/DirectTransfer/
Replenishment/Kit/Desk/Work
Status → Created/Released/InPreparation/StockFailure/
Paused/Prepared/Closed/Canceled
Priority → Urgent/High/Normal/Low/VeryLow
AccountCode → Account (delivery destination)
DockCode → assigned dock (optional)
RouteCode → Route assignment (optional)
GroupCode → wave/group (optional)
Lines[] {
Number, ItemCode, ContainerCode, OrderedQty, PreparedQty,
ShippedQty, UoMCode, LogisticAttributes, MaxLots,
Flags: Critical/Required/Excess/Substitutes
}
Prepackaging → prepackaging config (SOR02 only)
VASCode → VAS template reference (optional)
ERP_Source → SOR message code
}
```
### Count
```
Count {
Code* → unique count code
Type → Location/Item/Container
Status → Disabled/Releasing/InProcess/Closed/Canceled
Priority → count priority
Lines[] {
Number, Scope: {ItemCode/ContainerCode/LocationFrom-To/Aisle},
IsInformed, IsBlind
}
Tasks[] → count Tasks generated
ERP_Source → COR message code (if ERP-initiated)
}
```
## Master Data Entities
```
Item {
Code*, OwnerCode, Description, ShortDescription
TypeCode → ItemType
FamilyCode → ItemFamily
ABCClass → A/B/C classification
Profiles: LogisticProfile, ReceptionProfile, PutawayProfile,
ShippingProfile, CuttingProfile
UoMBase, Conversions[], Aliases[]
LogisticAttributes: {lot, serial, expiry, bestBefore, days_of_life,
production, color, size, version, quality, weight}
MinQty, MaxQty (per SubWarehouse via ItemClassification)
IsKit, IsSubstitute, IsCuttingStock
}
Owner {
Code*, Description
(with Owner Extensions: isolated master data scope)
}
Supplier {
Code*, Description, OwnerCode
}
Account {
Code*, Description, OwnerCode, AccountType
MixingRules → item/lot mixing restrictions
}
Carrier {
Code*, Description
Services[] → carrier service levels
(with Multi-Carrier: extended delivery configuration)
}
```
## Operational Entities
### Routes and Loads
```
Route {
Code*, Description, CarrierCode
DockCode → departure dock
DepartureTime
Status → Open/Closed/Canceled
Loads[] → truck Loads
ShippingOrders[] → assigned orders
}
Load {
Code*, RouteCode
Status → Open/InLoading/Closed
Seal → seal number
Containers[] → loaded containers
Stocks[] → loaded loose stock
}
```
### Putaway and Replenishment
```
PutawayStrategy {
Criteria[] → filter rules (item type, family, ABC, weight, etc.)
LocationRules[] → destination preference rules
AisleBalancing → boolean
ChannelFilling → boolean (prefer filling partial channels)
}
PDL (PickingDedicatedLocation) {
LocationCode, ItemCode, UoMCode
MinQty, MaxQty, ReplenishQty
PartitionType → fixed/flexible
EfficiencyMode → efficient/complete/none
}
```
### Consolidation and Defragmentation
```
ConsolidationProcess {
Code*, Definition, Criteria
AllowMixing → boolean
DestinationStation
Status → Standby/Released/Paused/Canceled
Orders[] → consolidation orders
}
DefragmentationPlanner {
Type → Rotation/Shipping
Schedule, Duration, Frequency
Status → Active/Inactive
}
```
## Module-Specific Entity Extensions
### AGV
```
AGVOrder {
ContainerCode, LoadType (0=Container/1=PalletShuttle)
PhaseCode → communication phase (00/03/04/06/08/10/255)
OriginLocation, DestinationLocation
ErrorCode, ErrorDescription
}
```
### Multi-Carrier
```
Delivery {
CarrierCode, ConsigneeCode
Status → Pending/Confirmed/Shipped/Delivered
TrackingNumber
Packages[]
ShippingOrderCode
}
```
### 3PL Billing
```
BillingContract {
OwnerCode, Description
Rules[] → BillingRule
Planners[] → BillingPlanner
}
BillingRule {
Type → Standard/Custom
ValuationFields[], TieredPricing[]
}
```
### DOM
```
DOMNode {
Code*, Type → POI/POF/Store
RegionCode
StockLevels → Organization/Node/Line
}
DOMOrder {
Code*, Type → Purchase/Sales/Replenishment
SourceNode, DestinationNode
OrchestrationStage → Region/Carrier/Stock/Capacity/Strategy
}
```
## Key Referential Constraints
| Constraint | Description |
|-----------|-------------|
| Item cannot be deleted with active stock | Item delete requires zero stock across all locations |
| Location cannot be deleted if occupied | Must empty location first |
| ReceiptOrder cannot be deleted if has receipts | Must cancel or close first |
| ShippingOrder cannot be modified if closed/canceled | Immutable after close |
| Task cannot be canceled if InProcess | Must be released by operator first |
| Container lock blocks most operations | Check active locks before operations |
| Stock with active UserStatus blocks shipping | Unless order specifically requests that status |
## Transaction-Entity Mapping
Every entity state change generates a Transaction. Key mappings:
| Transaction | Entity Changed |
|------------|---------------|
| `CON.LOCATE` | Container → Location (putaway) |
| `CON.MOVE` | Container → Location (manual move) |
| `CON.SHIPPED` | Container → Status=Shipped |
| `CON.RECEP` | Container → Created at receipt |
| `STK.RECEP` | Stock → Created at receipt |
| `STK.LOCATE` | Stock → Location (via putaway) |
| `STK.MOVE` | Stock → Location (manual) |
| `STK.PICKING` | Stock → Quantity decreased (picking) |
| `STK.ADJ` | Stock → Quantity adjusted |
| `STK.SHIPPED` | Stock → Status=Shipped |
| `INO.CST` | ReceiptOrder → Status changed |
| `INO.CLS` | ReceiptOrder → Status=Closed |
| `OUT.CST` | ShippingOrder → Status changed |
| `OUT.CLS` | ShippingOrder → Status=Closed |
| `COU.CST` | Count → Status changed |
| `COU.END` | Count → Status=Closed/Canceled |
| `TSK.LOC.001` | Task → Status=Finished (putaway) |
| `TSK.SHIP` | Task → Status=Finished (shipping) |
## ERP Integration Touch Points
Each entity has ERP messages that create, update, or receive data:
| Entity | ERP In (ERP→WMS) | ERP Out (WMS→ERP) |
|--------|-----------------|------------------|
| Item | ITM | — |
| Owner | OWN | — |
| Supplier | SUP | — |
| Account | ACC | — |
| Carrier | CAR | — |
| Kit | KIT | KST (assemble), UNK (disassemble) |
| ItemClassification | ITC | — |
| ReceiptOrder | ROR | ROC (status), ROF (close) |
| Container (ASN) | ASN | ASO (received), ASK (rejected) |
| Receipt | — | REF (closed) |
| ShippingOrder | SOR, RUT, WOR | SOC (status), SOF (close), LOF (load close), WOF (work order close) |
| Count | COR | COF (finalized) |
| Stock | STR (lock), SCR (contrast) | STV (variation), STC (status change), WSC (contrast response) |
| AutoWarehouse replenishment | SRN | SRO (done), SRK (canceled) |
| Container on conveyor | CMC | COS (shipped to PS), COC (closed in MP) |
## Related
- [Application Dictionary](application-dictionary.md) — AD element types: Commands, Queries, Entities
- [Container](../concepts/container.md) — Container entity deep-dive
- [Location](../concepts/location.md) — Location entity deep-dive
- [Stock](../concepts/stock.md) — Stock entity deep-dive
- [Product / Item](../concepts/product-item.md) — Item entity deep-dive
- [Task](../concepts/task.md) — Task entity lifecycle
- [Inbound Order](../concepts/order-inbound.md) — Receipt order entity
- [Outbound Order](../concepts/order-outbound.md) — Shipping order entity
- [Transactions](../concepts/transactions.md) — Full transaction audit trail
- [ERP Interface](../concepts/erp-interface.md) — ERP message catalog
+334
View File
@@ -0,0 +1,334 @@
---
title: "GALILEO Integration (TMS ↔ EasyWMS)"
type: architecture
sources:
- sources/archives/Presentation_GALILEO.md
- sources/archives/Communication_WMS_GALILEO.md
- sources/archives/Communication_Easy_Galileo.md
- sources/archives/Bases_fonctionnement_robotique_EasyWMS.md
- sources/archives/Documents_utiles.md
related:
- concepts/stations.md
- concepts/mechanical-elements.md
- concepts/task.md
- concepts/location.md
- operations/galileo-simulation.md
- operations/galileo-troubleshooting.md
- operations/robotics-project-lifecycle.md
- modules/automation-dashboard.md
last_compiled: "2026-04-17"
---
# GALILEO Integration (TMS ↔ EasyWMS)
## Overview
**GALILEO** is the Mecalux **Transport Management System (TMS)** — the automation layer that physically controls conveyors, stacker cranes (TK / Miniload), shuttles, AGVs, lifts and all other mechanized equipment. EasyWMS holds all the business intelligence (stock, strategies, orders); **GALILEO has no predictive vision** — it requests work from EasyWMS and executes it.
Two parallel automation controllers exist in the Mecalux ecosystem:
- **GALILEO** — classic PLC-driven TMS, deployed on production sites
- **EasyS** — 3D simulation environment that speaks the same protocol as GALILEO; used for development, demos and pre-site validation (see [Galileo Simulation](../operations/galileo-simulation.md))
Both dialogue with EasyWMS through the **EasyWMS Gateway** Windows service — a translator between GALILEO's low-level frame protocol and the EasyWMS API.
Reference documents:
- [Control_Communications_Interface_EN_GB.pdf](https://msscc.mecalux.com/documentation/Automation/master/ES/Documents/GalileoAWS/Control_Communications_Interface_EN_GB.pdf) — all station types, event types, PIE flags
- [EasyWMSGateway_ControlInterface_EN.pdf](https://msscc.mecalux.com/documentation/documentation/master/ES/docs_downloads/services/docs/EasyWMSGateway_ControlInterface_EN.pdf) — frame structure (low-level)
- [Stations index](https://msscc.mecalux.com/documentation/documentation/master/EN/areas/layout/stations/index.md) — station-specific behaviour
- [IdentErrorType](https://msscc.mecalux.com/documentation/Development/master/ES/apis/easywms/Domain/IdentErrorType.md) — rejection reason codes
## EasyWMS Gateway Service
Windows service that runs on the WMS server and brokers all communication with GALILEO / EasyS.
- **Download**: https://msscc.mecalux.com/documentation/documentation/master/EN/docs_downloads/services/gateway.md
- **Install path**: `C:\Program Files\Mecalux\EasyWMS Gateway 2015`
- **Config file**: `C:\ProgramData\Mecalux\EasyWMS Gateway 2015\Config\MainObject.config`
- **Log file**: `C:\ProgramData\Mecalux\EasyWMS Gateway 2015\Logs\AllLog.log`
- **Service name**: `EasyWMSGateway2015`
- **Port used by GALILEO/EasyS**: TCP 3000 (must be open inbound/outbound on the WMS host)
Config keys (MainObject.config):
- `tenantCode` = tenant of the target WMS
- `TokenUser` = authentication (prefer over `ClientUser`)
- Passwords must be encoded via `PasswordEncrypt.exe` in the install folder
Installation and bring-up procedure: see [Galileo Simulation & Test Setup](../operations/galileo-simulation.md).
## Tasks vs Movements
EasyWMS expresses transport work at two granularities:
- **Task** = end-to-end transfer order for a container (e.g. `PIE → Miniload Location A-12-3`)
- **Movement** = single conveyor-to-conveyor hop inside a task; a single task typically spawns **N movements** (a `PIE → Miniload` task commonly resolves to 4 movements)
A movement can only be generated if a **route** exists in EasyS between its origin station and the next station. If no path exists, EasyWMS generates a **reject task** toward the configured reject station.
### Task lifecycle (robotics view)
| Status | Description |
|--------|-------------|
| **En attente** / Pending | Not yet transmitted to GALILEO, no tracking |
| **Générée** / Generated | Next movement generated but not yet transmitted |
| **En cours** / In progress | Tracking picked up by GALILEO; container placed on virtual location **Mov** |
| **Terminée** / Completed | Container reached the final task destination |
| **Annulée** / Cancelled | Cancelled before reaching destination |
**Mov** is the virtual system location used to hold a container while it's physically travelling between stations. See [Location](../concepts/location.md) and [Task](../concepts/task.md).
## Stations & Routes (from GALILEO's perspective)
Stations are the start/end points of every movement. A station is uniquely identified by the couple **(StationType, StationNumber)** — this pair must be identical in EasyS and in GALILEO; any drift causes `EndErrorCode=4` errors (see Troubleshooting).
For the full reference of station codes (FR/ES/EN), acronyms (ALM/TK/PK/PIE/PS/ME/MS/PKE/CME/ET/MU/REAC/RECH/…) and roles, see [Mechanical Elements](../concepts/mechanical-elements.md) and [Stations & Routes](../concepts/stations.md).
### Route types (EasyS)
| Type | Description |
|------|-------------|
| **Galileo** | Movement that requires calls to the Gateway (physical conveyor moves) |
| **Manual** | Movement that requires an operator action in response to a WMS task |
| **Virtual** | Automatic, instantaneous virtual stock movement (e.g. output → consolidation zone) |
### Routes that MUST report "full" to EasyWMS
GALILEO must be able to report these routes as **full** (status `3`) so the WMS can recirculate / pause:
| Source type | Destination type |
|-------------|------------------|
| CME | TE (or ME) |
| PKE | PK |
| ET | PS |
Sometimes `ETPSxx → PSxx` must be reported to sequence shipping.
### Route status values
| Value | Meaning |
|-------|---------|
| `0` | No communication |
| `1` | Available / in service |
| `2` | Electromechanical fault |
| `3` | Full (and in service) |
## Three Communication Types (initiated by GALILEO)
**All communication is GALILEO → Gateway → EasyWMS.** The WMS never pushes unsolicited commands; it only responds. Three message types drive the workflow plus two status update streams.
### 1. Event (log → `Event`)
Declaration of container presence at a meaningful point. Primary sources:
- **PIE**: reports a new container with label read + gauge data — EasyWMS decides conformity
- **TK**: announces presence
- **Picking confirmation**: operator has finished a picking task
**PIE event fields:**
| Field | Description |
|-------|-------------|
| Code | Container barcode read |
| Weight | Weighed value |
| Dimensions | Physical measurements |
| Container type | PLC Container Type code (starts at 1, defined in PLC Types menu) |
| Height type | PLC Height Type code (starts at 1) |
| Flags | Bitwise gauge check result |
| Event type | Event-specific code (e.g. `9` = reject) |
PIE flag values (bitwise):
| Flag | Meaning |
|------|---------|
| `65536` | Container OK — no error |
| `256` | Barcode error |
| `512` | Recovered container |
| `1024` / `66560` | Correct + empty |
| `3` | Holes + studs detected |
| `4` | Overheight |
| `8` `64` | Overhangs |
| `128` | Weight excess |
**Two PIE processes depending on container origin:**
1. **New container** — GALILEO reads the label and sends type/height; EasyWMS verifies conformity and decides destination
2. **Known container returning** — EasyWMS pre-sends a movement toward PIE; GALILEO verifies types match, without re-reading the label
**PIE insert modes (set from EasyWMS → Control → Stations):**
- **Normal (known containers)** — reject anything the ASN doesn't recognize
- **Empty container creation** — create supports from the data GALILEO sends (code, weight, height type…)
- **Pallet pile creation** — operator activates "insert pallet piles" on the GALILEO console; GALILEO sends events with `Transport Number = 10`; item code + qty per pile must be defined in EasyWMS
**Workflow triggered:** `Galileo_PIEEventHandler_PR`
To enable instance tracking on PIE events: activate the process `<NomPIE>_<NomEntrepot>_GalileoPIE` in ApplicationService.
### 2. Search (log → `Search`)
GALILEO asks EasyWMS "what should I do with this container?" or "give me a next task". Triggered when:
1. A container arrives at a station and GALILEO needs the next hop
2. A TK/Miniload is idle and polls in a loop (hundreds per second)
**Search content:** tracking number, container code, station (type + number).
**Search response content:** destination station info. Capacity semantics differ by station type:
- **Conveyors / TK**: capacity = number of simultaneous trackings the station can manage
- **PK and PS**: capacity = max containers on the station **plus** all containers in movement toward it
**Station capacity vs route capacity vs WMS logical capacity** (worked example):
| Layer | Typical value for a PK |
|-------|------------------------|
| Physical station PK | 1 container on the conveyor |
| Route to PK | 4 containers in transit on intermediate conveyors |
| WMS PK capacity | 15 — physical + transit + every task whose destination is PK |
**Response state codes:**
| Code | Meaning | Used by |
|------|---------|---------|
| `83` | **S** = Servicio (in service) | Conveyors |
| `70` | **F** = Fallo (fault) | TK |
| `69` | **E** = Error | TK |
**X actual / Y actual** — only meaningful for TK; the current crane position is sent so EasyWMS can optimise task ordering.
**Workflow triggered:** `Galileo_SearchCreatedEventHandler_PR`. Routed by station type inside the process.
**Command used to transmit the order to GALILEO:** `GalileoMovTrackingCreateCommand` (preferred over `GalileoMovTrackingCreateChangingTargetCommand`). Effects:
- Gateway translates the command into a GALILEO frame
- Movement transitions from **Generated****In progress**
- Container is virtually relocated to **Mov**
> ⚠️ GALILEO can emit dozens of Search per second per station. **Do not enable workflow instance tracking on Search events carelessly** — scope it to the process and keep trace TTL very short, otherwise the trace tables explode.
### 3. End (log → `End0`, `End1`, …)
Signals that GALILEO has finished the current movement. EasyWMS advances to the next movement of the task (or closes the task).
**End error codes:**
| Code | Meaning | Consequence |
|------|---------|-------------|
| `0` | Movement completed | Next movement generated |
| `1` | Deposit error | Error mask + relocation / reject |
| `2` | Extraction error | Error mask + relocation / reject |
| `4` | Inconsistent order | WMS/GALILEO configuration mismatch — see troubleshooting |
| `7` | Gauge error | Relocation / reject |
**Workflow triggered:** `Galileo_EndCreatedEventHandler_PR`
## Station and Route Status Updates
Sent **every 13 seconds** by GALILEO (or immediately on change of state / load).
### Station update (log → `Update station`)
| Field | Meaning |
|-------|---------|
| StationType | Station type code |
| StationNumber | Station number |
| Status | `0` = unavailable (fault, manual mode, safety); `1` = available |
| Loaded | `0` = occupied; `1` = free — **note the inversion** |
| Capacity | Max containers |
| CurrentCount | Current GALILEO trackings on the station |
| Aisle | Aisle number associated with the station |
> ⚠️ The Loaded semantic is inverted between sources: historical GALILEO docs use `1 = free` / `0 = loaded`, while Comprendre_logs_Gateway lists the same values (`1` = libre, `0` = chargé). Always cross-check the log with the current Gateway protocol version.
**Function exposed by GALILEO:**
```
SetStationStatus(Type, Numéro, Status, Présence, Capacité, Occupation, Allée)
```
### Route update (log → `Update route`)
| Field | Meaning |
|-------|---------|
| StationTypeSource / StationNumberSource | Origin station |
| StationTypeDestination / StationNumberDestination | Destination station |
| Status | `0`/`1`/`2`/`3` — see Route status values above |
| CurrentCount | Trackings currently between the two stations |
**Function exposed by GALILEO:**
```
SetRouteStatus(TypeOrigine, NuméroOrigine, TypeDestination, NuméroDestination, Etat)
```
## End-to-End Example — Container Arriving at PIE
```
1. PIE reads label + gauges → Event (Galileo_PIEEventHandler_PR)
then Search (Galileo_SearchCreatedEventHandler_PR)
2. EasyWMS sends next movement → container placed on Mov virtual location
movement status → In progress
3. Container reaches next station → End (Galileo_EndCreatedEventHandler_PR)
4. If on a conveyor → new Search
If on a TK inbound table (TE) → TK polls Search in loop
5. If shipping conveyor (PS) → container leaves the installation
If picking conveyor (PK) → operator confirms pick → Event → Search
```
## Sequential Machine Model (Grafcet)
Every automation element is a sequential machine (grafcet) with discrete steps and transitions. Typical conveyor sequence:
1. Rest — ready to receive
2. Request output from upstream conveyor
3. Verify conditions (no presence, no tracking…)
4. Copy tracking + physical transfer + (if station) notify WMS
5. Release upstream conveyor
6. Request output toward downstream conveyor
7. Return to rest
This model is visible from the GALILEO SCADA: double-click a machine → **Graph** tab shows the current grafcet step; **Variables** shows live PLC memory.
## Application Dictionary Entry Points
Core workflows:
| Workflow | Trigger | Purpose |
|----------|---------|---------|
| `Galileo_PIEEventHandler_PR` | PIE event | Inbound identification + decision |
| `Galileo_SearchCreatedEventHandler_PR` | Search request | Next-hop routing and task delivery |
| `Galileo_EndCreatedEventHandler_PR` | End notification | Advance movement, handle error codes |
Core commands:
- `GalileoMovTrackingCreateCommand` — push an order frame to GALILEO (preferred)
- `GalileoMovTrackingCreateChangingTargetCommand` — variant that changes target mid-transport (avoid unless strictly necessary)
See [Application Dictionary](application-dictionary.md) for naming conventions and extension points.
## SCADA & Tracking
The GALILEO SCADA (visualization tool) displays machines, trackings and faults in real time.
- **Default credentials**: `mecalux / robmec`
- **Tracking editor** (double-click a machine):
- *Show tracking* — the order in execution
- *End order* — force-tell EasyWMS that the pallet has reached destination (manual override)
- *Machine state* — what GALILEO is currently reporting to EasyWMS
- **Advanced tab (unlock icon + password):**
- *Variables* — live variables; booleans can be forced
- *Graph* — current grafcet step
- **Edit buttons:**
- *Edit tracking* — origin, destination, height, type… (click "Edit" first)
- *Delete tracking* — remove tracking from the machine
- *Reset* — jump the grafcet to a specific step
Manual tracking edits are a last-resort diagnostic / recovery tool.
## Related
- [Mechanical Elements (acronyms, conveyors, station codes)](../concepts/mechanical-elements.md)
- [Stations & Routes](../concepts/stations.md) — full station catalogue from the WMS side
- [Galileo Simulation & Test Setup](../operations/galileo-simulation.md)
- [Galileo Troubleshooting (Logs, Faults)](../operations/galileo-troubleshooting.md)
- [Robotics Project Lifecycle](../operations/robotics-project-lifecycle.md)
- [Automation Dashboard](../modules/automation-dashboard.md) — fault monitoring UI
- [Task](../concepts/task.md) · [Location](../concepts/location.md)
+199
View File
@@ -0,0 +1,199 @@
---
title: "System Architecture Overview"
type: architecture
sources:
- areas/architecture/index.md (404 — compiled from cross-source knowledge)
- areas/saas/index.md (404)
- areas/hardware/index.md (404)
- areas/license/index.md (404)
- areas/ERP.md
- areas/parameters.md
- CLAUDE.md context
- custom/analyse_fonctionnelle.md
- sources/archives/Presentation_GALILEO.md
- sources/archives/Communication_WMS_GALILEO.md
related:
- architecture/security.md
- architecture/application-dictionary.md
- architecture/entities-map.md
- architecture/galileo-integration.md
- concepts/erp-interface.md
- concepts/mechanical-elements.md
last_compiled: "2026-04-17"
---
# System Architecture Overview
## Overview
Easy WMS is a Warehouse Management System developed by Mecalux. It is a multi-layer web application running on Windows servers (IIS), backed by a relational database (Oracle, SQL Server, MySQL, or PostgreSQL), accessed via a SmartUI web interface, RF terminals (RFT), and mobile apps.
The system follows an **Application Dictionary (AD)** architecture where most business logic is defined as configurable metadata (entities, commands, workflows) rather than hardcoded logic, enabling extensive customization without code changes.
Easy WMS is available in two deployment models:
- **SaaS (cloud-hosted by Mecalux)**: Multi-tenant, managed infrastructure, Amazon SaaS environment (required for some modules like Amazon Marketplace)
- **On-Premise**: Installed on customer or partner-managed Windows VMs; customer controls updates, backup, and networking
## Deployment Stack
### On-Premise Deployment
| Layer | Technology |
|-------|-----------|
| OS | Windows Server |
| Web Server | IIS (Internet Information Services) |
| Application Runtime | ASP.NET Core (ASPNETCORE_ENVIRONMENT variable for dev/prod) |
| Database | Oracle 19c / SQL Server 2019 / MySQL 8.0.14+ / PostgreSQL 14+ |
| Cache | Redis (session and application cache) |
| Message Queue | Internal background job system (no external broker documented) |
| Equipment Integration | TCP/IP sockets for AGV/PLC, WIFI for Pallet Shuttle tablets |
| Print Server | Local or network label printers (Zebra-type) |
### Application Pools (IIS)
Easy WMS uses multiple IIS application pools to isolate services:
- **Main WMS pool**: Core WMS logic, UI, API endpoints
- **Background Jobs pool**: Asynchronous processing (replenishment, defragmentation, AGV, label prints)
- **Integration pool**: ERP message processing (inbound/outbound queue)
Each pool runs as a separate Windows process with its own identity and recycling schedule.
### SaaS Deployment
In SaaS mode, Mecalux hosts all infrastructure. Key differences:
- Customer accesses via browser only; no local server management
- Updates are applied by Mecalux on a managed schedule
- Some integrations (ERP, label printers, RF equipment) require VPN tunnels or local agents
- Amazon SaaS is a specific certification required for Amazon Marketplace connector (Android 10 device requirement applies)
## API Architecture
Easy WMS exposes three REST API families:
### Application Dictionary API (AD API)
The primary programmatic interface. All AD elements (Commands, Queries, Dialogs, Views, Entities) are accessible via:
```
POST /api/commands/{commandName} → Execute a Command
GET /api/queries/{queryName} → Execute a Query (LINQ-based)
GET /api/entities/{entityName} → CRUD on an Entity
POST /api/dialogs/{dialogName}/steps → Advance a Dialog flow
```
### QueryExecute (LINQ API)
Allows dynamic data retrieval using LINQ-style expressions against any exposed View or Entity. Used for reporting, dashboards, and integration reads.
### CommandExecute API
Used to trigger business operations (receive stock, release orders, assign tasks, etc.) mapped to AD Commands.
### ERP Integration API
Asynchronous message exchange via structured XML/JSON messages over REST or file-based queues. See [ERP Interface](../concepts/erp-interface.md) for the full message catalog.
## Multi-Site and Multi-Warehouse
- A single EasyWMS installation can manage multiple **Sites** (physical warehouses)
- Each site has its own **parameters**, **locations**, **users**, and **equipment**
- Inter-site transfers are managed via transfer orders (SOR type = Transfer)
- The **DOM module** extends this to multi-node distributed order management
## Warehouse Types
Two fundamental warehouse types drive most architectural decisions:
| Type | Description | Key Constraint |
|------|-------------|----------------|
| **Manual warehouse** | Human operators pick using RF or paper; locations accessed directly | No location sequencing required |
| **Automatic warehouse** | Conveyor/shuttle/AGV system; WMS controls machine movements via control system | All movements must go through task queue; no direct access |
Mixed warehouses (some automatic aisles, some manual) are supported. The warehouse type determines which task flows, counting modes, defragmentation strategies, and station types are available.
### Automation control system (TMS)
Automatic warehouses depend on a **Transport Management System (TMS)** that physically drives conveyors, stacker cranes, miniloads, shuttles and lifts. In Mecalux installations the TMS is **GALILEO** (production) or **EasyS** (3D simulation for development / demos). Both dialog with EasyWMS through the **EasyWMS Gateway** Windows service over TCP port 3000.
Principle: **EasyWMS holds all business intelligence** (stock, strategies, orders); **GALILEO has no predictive vision** — it only requests orders and executes them. Three GALILEO-initiated message types drive the flow (Event / Search / End) plus two status update streams (station / route).
Full protocol, workflows (`Galileo_PIEEventHandler_PR`, `Galileo_SearchCreatedEventHandler_PR`, `Galileo_EndCreatedEventHandler_PR`) and command catalogue: [GALILEO Integration](galileo-integration.md). Bring-up and simulation: [Galileo Simulation](../operations/galileo-simulation.md). Troubleshooting: [Galileo Troubleshooting](../operations/galileo-troubleshooting.md).
## Background Job System
Easy WMS relies heavily on background jobs for asynchronous processing:
| Job Name | Frequency | Purpose |
|----------|-----------|---------|
| TryToReplenishProductLocations | Continuous | Automatic replenishment of PDL locations |
| Delete_StockStatusJob_PR | Every 15 min | Remove expired stock quality locks |
| AGV communication jobs | Continuous | Phase protocol exchange with AGV controllers |
| PSService | Continuous | Pallet Shuttle tablet communication |
| Continuous Slotting | Configurable | Ongoing slotting recommendations |
| Metric Gatherer | Configurable | Data Analytics KPI collection |
| Cycle Count Generation | Per schedule | Create cycle count batches |
| Defragmentation Planner | Per schedule | Execute defragmentation strategies |
## Hardware Requirements
### On-premise minimum server specifications
| Server role | CPU | RAM | Storage |
|-------------|-----|-----|---------|
| **Database server** | 4-core @ ≥ 3 GHz | 32 GB | 600 GB (data) + 50 GB (OS) |
| **Application server** | 4-core @ ≥ 3 GHz | 32 GB | 200 GB (logs + app) |
Both servers run Windows Server. For small warehouses the DB and App roles can be on the same machine (specifications must still be met).
### Client and peripheral hardware
- **Client (SmartUI)**: Modern web browser (Chrome/Edge); tablet or desktop PC
- **RF Terminals (RFT)**: Dedicated warehouse scanners running Windows CE or Android; connect via WIFI
- **Label Printers**: Zebra-type thermal printers; connected via network or USB
- **Automatic Warehouse**: Requires PLC/control system interface (proprietary per vendor — AGV, Pallet Shuttle, APS3D each use their own protocol)
- **Scales**: PIE stations can have integrated scales for container weight validation
- **Mobile Devices**: Android 10+ required for Amazon SaaS Marketplace integration
### SaaS tiers (Azure-hosted by Mecalux)
EasyWMS SaaS runs on Azure and is available in three subscription tiers:
| Tier | vCPUs | RAM | Max concurrent users | Max orders/day |
|------|-------|-----|---------------------|----------------|
| **Basic** | 2 | 7 GB | 10 | 200 |
| **Standard** | (contact Mecalux) | — | — | — |
| **Advanced** | (contact Mecalux) | — | — | — |
All SaaS tiers: Mecalux manages infrastructure, updates, backup. ERP integration and printers require VPN tunnel or local agents. Some integrations (Amazon Marketplace) require Android 10+ devices.
## License Model
Easy WMS licenses are modular:
- **Base WMS**: Core inbound/outbound/inventory functionality
- **Module licenses**: Each additional module (AGV, Pallet Shuttle, Multi-Carrier, Slotting, LMS, 3PL Billing, DOM, etc.) requires a separate license
- **User licenses**: Typically per concurrent user or per named user
- **Site licenses**: Some modules require per-site activation
## Parameters and Configuration
System behavior is governed by two layers of parameters:
1. **Organization-level parameters**: Apply globally across all warehouses
2. **Warehouse-level parameters**: Override organization defaults for a specific site
Key system parameters are documented at `areas/parameters.md`. Each functional module has its own parameter set. See [Parameters](../concepts/parameters.md) for the full compiled reference.
## Common Errors
| Symptom | Likely Cause |
|---------|-------------|
| IIS application pool stopped | Background job crash or unhandled exception; check Windows Event Log |
| ERP messages not processed | Integration pool stopped or message queue backlog; check integration logs |
| RF terminal cannot connect | WIFI network issue or IIS binding misconfiguration |
| "Development environment" error in browser | ASPNETCORE_ENVIRONMENT set to Development in production; should be Production |
| Automatic warehouse tasks not generating | Background job (replenishment/defragmentation planner) not running |
## Related
- [Application Dictionary](application-dictionary.md) — AD structure: Commands, Queries, Entities, Workflows
- [Security](security.md) — User roles, authentication, audit
- [Entities Map](entities-map.md) — Data model and entity relationships
- [ERP Interface](../concepts/erp-interface.md) — All ERP messages and integration protocols
- [Parameters](../concepts/parameters.md) — System configuration parameters
- [AGV](../modules/agv.md) — Automatic warehouse AGV protocol
- [Pallet Shuttle](../modules/pallet-shuttle.md) — PS system architecture
- [APS3D](../modules/aps3d.md) — Fleet Manager controller
+246
View File
@@ -0,0 +1,246 @@
---
title: "RF Terminal Menu Map"
type: architecture
sources:
- sources/archives/menu_rf_easywms.md
related:
- architecture/application-dictionary.md
- concepts/task.md
- concepts/reception.md
- concepts/putaway.md
- concepts/picking.md
- concepts/replenishment.md
- concepts/count.md
- concepts/shipping.md
- concepts/kits.md
- concepts/quality-control.md
- concepts/container.md
- concepts/group.md
- modules/multi-carrier.md
last_compiled: "2026-04-17"
---
# RF Terminal Menu Map
## Overview
The handheld RF terminal (`consolerf`) surfaces every operator flow through a fixed **12-menu hierarchy**. Each menu entry is bound to a **workflow** identified by its fully-qualified name (`<Namespace>.<WorkflowCode>`). Understanding this mapping matters for four reasons:
1. **Customisation.** Overriding a menu entry means cloning the workflow, adjusting it, and pointing the menu at the new version through an Application Dictionary override.
2. **Debugging.** When an operator reports "the RFT froze on screen X", locating the workflow that owns screen X is the shortest path to reading the logs.
3. **Rights management.** Menu entries are granted per user/role ; this page lists the menu codes (`RFMenu_*`, `SharedMenu_*`) that configuration screens expect.
4. **Training / acceptance.** Change management documents refer to workflow names — the table below is the cross-reference.
All workflow codes belong to the `EasyWMS` namespace unless otherwise noted (`Deliveries` for the Multi-Carrier module).
## 1. Tasks — `RFMenu_Task`
| Menu entry | Workflow |
|---|---|
| Automatic task | `EasyWMS.Task_AutomaticAssignment_PR` |
| Semi-automatic task | `EasyWMS.Task_SemiautomaticAssignment_UI` |
| Putaway task | `EasyWMS.Putaway_GetPutawayTaskFromMenu_UI` |
| Picking task | `EasyWMS.Outbound_ObtainPickingTask_PR_V2` |
| Shipping task | `EasyWMS.Expedition_ExecuteShipping_FromMenu_PR` |
| Replenishment task | `EasyWMS.Replenishment_GetReplenishTasksFromMenu_PR` |
| Count task | `EasyWMS.Count_GetTasksFromMenu_PR` |
| Empty locations task | `EasyWMS.DynamicProductLocation_EmptyLocation_UI` |
| Movement task | `EasyWMS.Movement_Tasks_FromMenu_UI` |
| PS Group shipping tasks | `EasyWMS.PsGroup_ExpeditionTasks_UI` |
| TenseFlow task | `EasyWMS.TenseFlow_ExecuteBufferReplenishment_FromMenu_UI` |
| Consolidation task | `EasyWMS.Consolidation_AutomaticTasks_FromMenu_UI` |
| Cutting task | `EasyWMS.CutInStation_Main_UI` |
## 2. Receptions — `SharedMenu_Receptions`
### Blind reception — `RFMenu_BlindReception`
| Menu entry | Workflow |
|---|---|
| Loose stock or in container | `EasyWMS.BlindReception_UI` |
| Mono-reference | `EasyWMS.BlindReception_Monoreference_Containers_UI` |
| Identical mono-reference | `EasyWMS.BlindReception_Monoreference_Identical_Containers_UI` |
### Suppliers — `RFMenu_Providers`
| Menu entry | Workflow |
|---|---|
| Loose stock or multi-reference | `EasyWMS.Reception_Supplier_LooseStockOrMultireference_UI` |
| Mono-reference | `EasyWMS.Reception_Supplier_Monoreference_Containers_UI` |
| Identical mono-reference | `EasyWMS.Reception_Supplier_Monoreference_Identical_Containers_UI` |
### Other receptions
| Menu entry | Workflow |
|---|---|
| Return reception | `EasyWMS.Reception_Return_UI` |
| Advance notice reception | `EasyWMS.AdvanceNotice_Reception_UI` |
| Generate labels | `EasyWMS.PrintLabels_MultireferenceContainerLabels_UI` |
## 3. Putaway — `RFMenu_Putaway`
| Menu entry | Workflow |
|---|---|
| Containers or loose stock | `EasyWMS.Equipment_LoadStock_UI` |
| Shared containers | `EasyWMS.Equipment_LoadContainer_UI` |
## 4. Shipping orders — `SharedMenu_ShippingOrders`
| Menu entry | Workflow |
|---|---|
| Order picking | `EasyWMS.Expedition_OrderPicking_UI` |
| Manual picking | `EasyWMS.ManualPicking_ByItem_UI` |
| Wave picking | `EasyWMS.WorkWave_ExecuteTask_UI` |
| Virtual picking | `EasyWMS.VirtualPicking_MainFromRF_UI` |
| Packing | `EasyWMS.Expedition_PackingInLocation_UI` |
| Paper confirmation | `EasyWMS.Picking_ConfirmPickingPaper_UI` |
| Manual preparation | `EasyWMS.Expedition_ManualPreparation_UI` |
### PTL Picking — `RFMenu_PickingPTLs`
| Menu entry | Workflow |
|---|---|
| PTLs | `EasyWMS.PTLsPickingPreparation_OrderAssignment_SelectMode_UI` |
| Enter zone | `EasyWMS.PTLsPickingPreparation_EnterZone_UI` |
| Exit zone | `EasyWMS.PTLsPickingPreparation_ExitZone_UI` |
| Unload | `EasyWMS.PTLsPickingPreparation_ManualUnload_UI` |
| Equipment status | `EasyWMS.PTLsPickingPreparation_ManualEquipmentInfo_UI` |
| Manual preparation | `EasyWMS.PTLsPickingPreparation_ManualPreparation_UI` |
### Truck loading — `RFMenu_TruckLoad`
| Menu entry | Workflow |
|---|---|
| Container load | `EasyWMS.TruckLoad_GetLoads_UI` |
| Container unload | `EasyWMS.UnloadContainer_UI_v1` |
| Stock load | `EasyWMS.StockTruckLoad_GetLoads_UI` |
| Parcel load | `Deliveries.Dlv_TruckLoad_GetLoads_UI` |
### Undo preparation — `RFMenu_UndoPreparation`
| Menu entry | Workflow |
|---|---|
| Undo preparation | `EasyWMS.UndoPreparation_Main_PR` |
| Undo excess | `EasyWMS.UndoExcess_Main_PR` |
## 5. Replenishment — `RFMenu_Replenishment`
| Menu entry | Workflow |
|---|---|
| By location | `EasyWMS.Replenishment_GetReplenishLocations_UI` |
| By aisle | `EasyWMS.Replenishment_GetProductLocationsListByAisle_UI` |
| By warehouse | `EasyWMS.Replenishment_GetAllProductLocationsByWarehouse_UI` |
| By outbound order | `EasyWMS.Replenishment_GenerateTasksByOutboundOrder_UI` |
## 6. Counts — `SharedMenu_Counts`
| Menu entry | Workflow |
|---|---|
| Select a count | `EasyWMS.Count_SelectCount_UI` |
| Physical count | `EasyWMS.Count_StockOnPhysicalLocation_UI` |
| Informed count | `EasyWMS.Count_StockOnPhysicalLocation_Informed_UI` |
## 7. Kits — `RFMenu_Kits`
| Menu entry | Workflow |
|---|---|
| Component request | `EasyWMS.KitAssembly_CreateWorkOrder_UI` |
| Assemble | `EasyWMS.KitAssembly_UI` |
| Disassemble | `EasyWMS.KitDisassembly_UI` |
## 8. Quality — `RFMenu_Quality`
| Menu entry | Workflow |
|---|---|
| Lock by item | `EasyWMS.Quality_LockByProduct_UI` |
| Lock by container/location | `EasyWMS.Quality_LockByLocationOrContainer_UI` |
| Unlock by item | `EasyWMS.Quality_UnlockByProduct_UI` |
| Unlock by container/location | `EasyWMS.Quality_UnlockByLocationOrContainer_UI` |
## 9. Groups — `RFMenu_Groups`
| Menu entry | Workflow |
|---|---|
| Ungroup orders | `EasyWMS.Ungroup_Outboundorders_UI` |
| Ungroup PTL | `EasyWMS.Ungroup_PTL_UI` |
| Extraction | `EasyWMS.Extraction_Regular_UI` |
| Incident extraction | `EasyWMS.Extraction_Incidents_UI` |
| Extraction without pack | `EasyWMS.Extraction_WithoutPack_UI` |
| Change location | `EasyWMS.Ungroup_ChangeLocation_UI` |
## 10. Utilities — `RFMenu_Utilities`
| Menu entry | Workflow |
|---|---|
| Show item | `EasyWMS.Utils_ShowProduct` |
| Show container | `EasyWMS.Utils_ShowContainer` |
| Show location | `EasyWMS.Utils_ShowRealLocation` |
| Print labels | `EasyWMS.PrintLabels_MenuOptions_UI` |
| Increase stock | `EasyWMS.Utils_IncreaseProduct` |
| Decrease stock | `EasyWMS.Utils_DecreaseProduct` |
| Location adjustment | `EasyWMS.AdjustStock_UI` |
| Scrap | `EasyWMS.Tool_Scrap` |
| My stock | `EasyWMS.Equipment_CheckStock_UI` |
| My containers | `EasyWMS.Equipment_My_Containers_UI_V1` |
| Product location | `EasyWMS.ProductLocation_Create_UI` |
| Manual movement | `EasyWMS.ManualMovement_Main_UI` |
| Change compact mode | `EasyWMS.DriveInLocations_SetCompactStorageMode_UI` |
| Compact drive-in aisle | `EasyWMS.DriveInLocation_Compact_UI` |
| Show rejections | `EasyWMS.Utils_ShowRejections_UI` |
| Manual consolidation | `EasyWMS.Utils_ManualConsolidation_UI` |
| Buffer consolidation | `EasyWMS.Utils_Consolidation_BufferStationProcess_UI` |
| Show cart | `EasyWMS.Utils_ShowCart_UI` |
| My cart | `EasyWMS.Equipment_MyCart_UI` |
### Remount / Unremount containers — `RFMenu_RemountUnRemountContainers`
| Menu entry | Workflow |
|---|---|
| Remount containers | `EasyWMS.Container_RemountContainers_UI` |
| Match containers | `EasyWMS.Container_MatchContainers_UI` |
| Unremount container | `EasyWMS.Container_UnremountContainer_UI` |
| Unremount all containers | `EasyWMS.Container_UnremountAllContainers_UI` |
## 11. Pick and Pass — `Menu_PickAndPass`
| Menu entry | Workflow |
|---|---|
| Receptions | `EasyWMS.PickAndPass_Reception_Main_UI` |
| Close containers | `EasyWMS.PickAndPass_CloseContainer_FromMenu_UI` |
| Putaway | `EasyWMS.PickAndPass_Putaway_Main_UI` |
| Picking | `EasyWMS.PickAndPass_Picking_Main_PR` |
| Automatic task | `EasyWMS.PickAndPass_AutomaticAssignment_Main_UI` |
## 12. Packaging — `Menu_Packaging` *(Multi-Carrier module)*
| Menu entry | Workflow |
|---|---|
| Packaging | `Deliveries.Dlv_Packaging_Process_FromRF_UI` |
| Carrier verification | `Deliveries.Dlv_Packaging_Verification_CarrierVerification_UI` |
| Change carrier | `Deliveries.Dlv_Packaging_ChangeCarrier_FromRF_UI` |
| Show parcel | `Deliveries.Dlv_Utils_ShowPackage` |
| Move parcel | `Deliveries.Dlv_PackageManualMovement_PR` |
| Bulk load | `Deliveries.Dlv_BulkLoad_UI` |
### Reprint tracking number — `ReprintTrackingNumber_RFMenu`
| Menu entry | Workflow |
|---|---|
| Last unlabelled delivery | `Deliveries.Dlv_Packaging_ReprintTrackingNumber_LastUnlabelledDelivery_FromRF_UI` |
| Labelled delivery | `Deliveries.Dlv_Packaging_ReprintTrackingNumber_LabelledDelivery_UI` |
## Related
- [[application-dictionary]] — the Application Dictionary holds the Workflow entities referenced above ; overriding a menu entry is an AD operation
- [[task]] — Tasks (menu 1) are the main RFT entry point in most deployments
- [[reception]] — workflows under menu 2 drive the reception flows (Supplier, Blind, Return, ASN, Workstation)
- [[putaway]] — menu 3 and the automatic-assignment path in menu 1
- [[picking]] — menu 4 covers all picking flavours (standard, manual, wave, virtual, PTL)
- [[replenishment]] — menu 5 covers the four replenishment scopes (location, aisle, warehouse, by-order)
- [[count]] — menu 6 physical-count workflows
- [[shipping]] — menu 4 packing + undo-preparation close the shipping loop on the RFT
- [[kits]] — menu 7 assembly / disassembly
- [[quality-control]] — menu 8 lock / unlock
- [[group]] — menu 9 group and extraction flows
- [[container]] — `Utilities → Remount/Unremount` flows manipulate the container tree
- [[multi-carrier]] — menu 12 only appears when the Multi-Carrier (`Deliveries`) module is enabled
+170
View File
@@ -0,0 +1,170 @@
---
title: "Security"
type: architecture
sources:
- areas/security/index.md (404 — compiled from cross-source knowledge)
- areas/parameters.md
- areas/inventory_management/stations/roles.md
- modules cross-source knowledge
- custom/analyse_fonctionnelle.md
related:
- architecture/overview.md
- architecture/application-dictionary.md
- modules/billing-3pl.md
- modules/3pl-portal.md
- modules/owner-extensions.md
last_compiled: "2026-04-26"
---
# Security
## Overview
Easy WMS security is built around a role-based access control (RBAC) model layered over a multi-tenant site architecture. Each user belongs to one or more **roles** that grant access to specific UI areas, commands, and data scopes. Security operates at three levels: authentication (who you are), authorization (what you can do), and data isolation (what data you can see).
## User Roles
Easy WMS defines a role hierarchy with increasing privileges:
| Role | Scope | Capabilities |
|------|-------|-------------|
| **SuperAdmin** | Organization (all sites) | Full access including user management, system parameters, all modules |
| **Administrator** | Organization or per-site | Most functional areas; may be scoped to one warehouse |
| **Manager** | Per-site | Operational supervision; can release orders, manage counts, view reports |
| **Operator** | Per-site | Execute daily operations: picking, receiving, counting, shipping |
| **RF Operator** | RF terminal only | Subset of Operator; limited to terminal flows |
| **Viewer / Read-only** | Per-site | Read-only access to views and reports |
| **3PL Client** | Owner-scoped | Only sees data for their owner; requires 3PL Portal module |
| **SCEM Admin** | Cross-site | Manages Supply Chain Event subscriptions and notification routing |
Custom roles can be defined in the AD to grant fine-grained access to specific Commands, Views, and Dialogs.
## Authentication
### Standard login
- **Web (SmartUI)**: Username/password authentication; session managed via encrypted cookie
- **RF Terminals**: Username/password entered at terminal login screen; sessions can be configured to time out after inactivity
- **API (ERP Integration)**: API key or service account credentials; configured per integration endpoint
Password policies (minimum length, complexity, expiry) are configurable in system parameters.
### QR Code login (RF terminals)
Operators can log in to RF terminals by scanning a personal QR Code instead of typing their credentials:
- The QR Code contains **anonymized data** — a third party who finds a lost QR Code cannot derive the operator's username or password from it
- **Each reprint invalidates the previous QR Code** — there is no revocation mechanism other than reprinting
- QR Code login is **incompatible with SSO**: a user configured for SSO cannot use QR Code login
### SSO (Single Sign-On)
EasyWMS supports SSO using the **SAML V2.0 protocol**. No other SSO protocol is supported.
- SSO is available on both the **PC (SmartUI)** and **RF terminal** interfaces
- When SSO is enabled for a user account, EasyWMS will **not accept any other login method** for that user — standard username/password login is disabled
- **SSO and QR Code are mutually exclusive**: enabling SSO on a user account prevents them from using QR Code login
- Configuration requires setting up the SAML identity provider (IDP) in EasyWMS system parameters and mapping EasyWMS roles to IDP groups
## Authorization Model
Authorization is evaluated at two levels:
### Menu / UI Access
Each Role grants access to specific navigation areas. A user who cannot access a menu item cannot reach the underlying Commands or Views from the UI.
### Command-Level Access
Individual AD Commands can be restricted to specific roles. This is enforced server-side — even if a user constructs an API call directly, the command execution checks the caller's role.
### Data Scope (Owner Isolation)
When the **Owner Extensions** module is active, data is isolated by owner:
- Receipt orders, shipping orders, and master data (items, suppliers, accounts) carry an owner code
- Users assigned to a specific owner can only see and act on that owner's data
- 3PL Portal users have this isolation enforced automatically
- See [Owner Extensions](../modules/owner-extensions.md) for details
## Station Roles
Beyond system roles, operators are assigned to **station roles** that determine which warehouse stations they can work at. Station roles are configured per station type:
- An operator with "Receiving" role can work at Dock and PIE stations
- An operator with "Picking" role can work at PK/PS/ME stations
- An operator can hold multiple station roles simultaneously
Station role assignment is done in the Warehouse Designer or via the Stations administration view.
## Audit Trail
Every significant operation in Easy WMS generates a **Transaction** record:
- Who performed the operation (user)
- When (timestamp)
- What (transaction type code, e.g., STK.ADJ, CON.MOVE)
- On which objects (container, location, item, order)
- From which equipment (RFT, workstation IP)
Transactions are immutable and cannot be deleted. They form the complete audit trail for stock movements, adjustments, order processing, and user actions. See [Transactions](../concepts/transactions.md) for the full transaction type catalog.
## Quality Locks (Stock Security)
Quality Control uses a two-tier lock system to prevent unauthorized stock movements:
- **Receiving status**: Set automatically during reception; cleared when stock passes QC
- **User status**: Set manually or via ERP STR message; cleared manually or via time-based unlock
Stock with an active lock cannot be assigned to shipping orders or moved by standard tasks. This provides a safety mechanism to prevent inadvertent shipment of quarantined stock. See [Quality Control](../concepts/quality-control.md) for details.
## Container Locks
Containers can be locked with specific lock types that prevent certain operations:
| Lock Type | Blocked Operation |
|-----------|------------------|
| Inbound lock | Container cannot receive new stock |
| Outbound lock | Container cannot be picked or shipped |
| Movement lock | Container cannot be moved to another location |
| Blocking lock | All operations blocked |
Container lock events generate `LCK.CON.001` and `ULK.CON.001` transactions.
## Network and Infrastructure Security
- **IIS Application Pools**: Run under dedicated service accounts with minimal OS privileges
- **Database**: Separate credentials per application pool; principle of least privilege
- **API Keys**: ERP integration uses API keys per connection; keys are rotated per customer policy
- **HTTPS**: All SmartUI and API traffic encrypted via TLS; HTTP redirects to HTTPS enforced
- **RF WIFI**: RF terminals communicate over WPA2/WPA3 encrypted WIFI networks
- **AGV Communication**: AGV systems communicate over dedicated network segments (VLAN isolation recommended)
- **VPN**: SaaS deployments require VPN tunnels for on-premise ERP integration and printer connectivity
## Notification Security
The SCEM (Supply Chain Event Management) module allows subscribing to operational events. Subscriptions are scoped by role:
- **SuperAdmin/Administrators/Managers**: Can subscribe to any event type
- **3PL clients**: Can only subscribe to events related to their owner
- Notification channels (email, SMS, web) are configured per subscription
## Parameters Affecting Security
| Parameter | Effect |
|-----------|--------|
| `SESSION_TIMEOUT_MINUTES` | RF and web session inactivity timeout |
| `PASSWORD_MIN_LENGTH` | Minimum password length |
| `MAX_LOGIN_ATTEMPTS` | Account lockout threshold |
| `AUDIT_LOG_RETENTION_DAYS` | How long transaction logs are kept |
## Common Errors
| Symptom | Cause | Solution |
|---------|-------|---------|
| User cannot access a menu | Role missing required permission | Add the menu item to the user's role in AD configuration |
| RF terminal login rejected | User has no station role at that station type | Assign appropriate station role |
| ERP API calls return 401 | API key expired or invalid | Regenerate API key in integration configuration |
| Stock cannot be assigned (locked) | User or receiving status active | Check Quality Control view; unlock if appropriate |
| 3PL client sees other owners' data | Owner Extensions not configured | Enable Owner Extensions module and assign owner to user |
## Related
- [Overview](overview.md) — System architecture and deployment model
- [Application Dictionary](application-dictionary.md) — Role and permission configuration via AD
- [Transactions](../concepts/transactions.md) — Audit trail for all operations
- [Quality Control](../concepts/quality-control.md) — Stock lock system
- [Owner Extensions](../modules/owner-extensions.md) — Multi-owner data isolation
- [3PL Portal](../modules/3pl-portal.md) — External client access model
- [Supply Chain Event Management](../modules/supply-chain-event.md) — Notification subscriptions