lint(standard): corrections completes mode standard

- Em dashes: 1712 remplaces par tirets simples (86 fichiers + _index.md, en-tete section Limagrain conserve) - Checklists: 24 '- [ ]' -> '- ☐' (3 pages operations, plus de todos Obsidian) - Ancres: 33 reparees (slugs GitHub + ancres HTML <a id> reconnues), 1 reciblee (manuel de reten) - related: tenseflow -> tense-flow, pie -> mechanical-elements, group.md retire (doublon shipping) - Registre: compteur global 122 -> 131 pages - Rapport racine _lint_report.md mis a jour (scan v2 + re-scan final: 0 anomalie) - Aucun fichier limagrain/ modifie (cloisonnement)
2026-07-20 13:01:21 +02:00
parent 7496aafe64
commit 9ce6ae37be
88 changed files with 1769 additions and 1871 deletions
@@ -17,7 +17,7 @@ last_compiled: "2026-04-10"

 ## 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.
+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.

@@ -70,8 +70,8 @@ The 3PL manager creates specific user groups per 3PL client. Users in these grou

 ## 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
+- [[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
@@ -1,5 +1,5 @@
 ---
-title: "AGV — Automated Guided Vehicles"
+title: "AGV - Automated Guided Vehicles"
 type: module
 sources:
  - areas/agvs/index.md
@@ -38,7 +38,7 @@ related:
 last_compiled: "2026-05-15"
 ---

-# AGV — Automated Guided Vehicles
+# AGV - Automated Guided Vehicles

 ## Overview

@@ -46,7 +46,7 @@ An Automated Guided Vehicle (AGV) is a warehouse transport machine similar to a

 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.
+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

@@ -134,7 +134,7 @@ Easy WMS and the AGV system exchange messages via **database tables** (not REST
 | `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 |
+| `10` | AGV → WMS | Unload confirmed - order complete |
 | `255` | AGV → WMS | Order canceled by AGV |

 ### AGV station attributes
@@ -155,7 +155,7 @@ Easy WMS and the AGV system exchange messages via **database tables** (not REST
 | 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 |
+| Priority | Execution priority - most urgent tasks dispatched first |
 | Previous task | Chained task dependency |

 ## Configuration
@@ -167,14 +167,14 @@ Easy WMS and the AGV system exchange messages via **database tables** (not REST
   - 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
+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)
+### Monitoring (PC - AGVs menu)

 | View | Purpose |
 |------|---------|
@@ -277,9 +277,9 @@ For the complete installation procedure, see [AGV Installation Guide](../operati

 ## 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
+- [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
@@ -19,7 +19,7 @@ last_compiled: "2026-04-10"

 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.
+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

@@ -105,9 +105,9 @@ When the system cannot determine exact depth for origin or destination, an opera

 ## 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`
+- [[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`
@@ -29,7 +29,7 @@ The Automation Dashboard module (sourced from the `faults_management` area) prov

 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/`.
+**Note**: The `areas/automation_dashboard/` folder returns 404 - the Automation Dashboard functionality is implemented in `areas/faults_management/`.

 ## Key capabilities

@@ -122,11 +122,11 @@ Faults most often seen on miniload installations. Use this table to triage befor
 | **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.
+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)):
+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)
@@ -135,9 +135,9 @@ Standard Automation Dashboard reports delivered by Mecalux (documents on [Conflu

 ## 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
+- [[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
@@ -59,7 +59,7 @@ The 3PL Billing module identifies, quantifies, records, and consolidates data fr

 Rules are organized in three groups by concept:

-#### Group 1 — Storage
+#### Group 1 - Storage
 Quantifies articles in stock at a given moment (snapshot-based):
 | Sub-type | What is counted |
 |----------|----------------|
@@ -69,7 +69,7 @@ Quantifies articles in stock at a given moment (snapshot-based):
 | 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
+#### Group 2 - Handling
 Quantifies dynamic processes applied to stock (flow-based):
 | Sub-type | What is counted |
 |----------|----------------|
@@ -82,7 +82,7 @@ Quantifies dynamic processes applied to stock (flow-based):

 Operations covered: inbound receipts, outbound shipments, loads, routes, counts, kit assemblies.

-#### Group 3 — Transaction
+#### Group 3 - Transaction
 Custom rules based on specific WMS transaction types:
 | Parameter | Description | Required? |
 |-----------|-------------|----------|
@@ -93,7 +93,7 @@ Custom rules based on specific WMS transaction types:

 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 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.

@@ -155,11 +155,11 @@ When enabled on a contract, generated bills must be manually reviewed and approv
 ### 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
+- **Cannot change valuation (on/off) after a contract has been active** - must clone and disable old

 ## Operations

-### Bill management (PC — Billing menu)
+### Bill management (PC - Billing menu)

 | View | Content |
 |------|---------|
@@ -207,9 +207,9 @@ Notification channels: **email**, **SMS**, or **SmartUI contextual notification*

 ## 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
+- [[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
@@ -2,7 +2,7 @@
 title: "Client-Specific Rules"
 type: module
 sources:
-  - areas/client_specific_rules/index.md  # 404 — source unavailable
+  - areas/client_specific_rules/index.md  # 404 - source unavailable
 related:
  - modules/directives.md
  - modules/owner-extensions.md
@@ -18,7 +18,7 @@ last_compiled: "2026-04-10"

 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.
+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

@@ -32,6 +32,6 @@ Client-specific rules in EasyWMS are implemented through two mechanisms:

 ## 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
+- [[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
@@ -85,7 +85,7 @@ All cobot incidents are resolved at the manual picking station:

 ## 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
+- [[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
@@ -72,7 +72,7 @@ Any user can create personal dashboards. Publishing makes a dashboard available

 ## Configuration

-### Metric group management (PC — Data Analytics menu)
+### 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
@@ -103,7 +103,7 @@ When the Slotting module is installed, the warehouse 2D map enables a **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
+- [[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
@@ -28,8 +28,8 @@ last_compiled: "2026-04-10"
 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
+- **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.

@@ -85,13 +85,13 @@ Rules applied to stock based on the **account** (end customer receiving the good
 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
+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:
+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
@@ -100,9 +100,9 @@ Directives operate automatically — once configured, they apply silently to all

 ## 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
+- [[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
@@ -44,13 +44,13 @@ Easy DOM is a Distributed Order Management platform that orchestrates the supply

 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.
+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)
+- 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
@@ -150,7 +150,7 @@ Available for orders in _Pending_ status (no assigned stock). Step-by-step:
 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
+5. Confirm - shipping orders created

 If stock becomes unavailable during the wizard (concurrent assignment), the order is released with _Incomplete_ or _Assignment error_ status.

@@ -165,7 +165,7 @@ Reorchestration priority criteria:
 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.
+**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).

@@ -175,7 +175,7 @@ If no single node can ship the complete order, DOM can assign parts to multiple

 ## Inbound: Purchase Order Management

-DOM does not orchestrate inbound — it records and distributes purchase orders to nodes based on order line data.
+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
@@ -190,7 +190,7 @@ ERP sends POR → DOM creates purchase order

 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).
+**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

@@ -203,7 +203,7 @@ ERP/manual creates replenishment order
 → Replenishment order closes
 ```

-Automatic replenishment by safety stock breakage is **not currently supported** — replenishment orders must be created manually or by ERP.
+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.

@@ -263,10 +263,10 @@ Per node:

 ## 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
+- [[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
@@ -85,8 +85,8 @@ Supplier → Reception → eCommerce Classification

 ## 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
+- [[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
@@ -22,7 +22,7 @@ last_compiled: "2026-04-10"

 ## 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.
+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.

@@ -95,8 +95,8 @@ When automatic warehouse machines (conveyors, sorters, AGVs, APS3D carts) encoun

 ## 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
+- [[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
@@ -63,7 +63,7 @@ Process → Work (one execution of a process by an operator at a specific time)

 **Work detail adjustment**: Time additions applied to an activity execution based on configurable conditions.

-### Measured processes (standard set — not customizable without development)
+### Measured processes (standard set - not customizable without development)

 | Category | Processes |
 |----------|-----------|
@@ -115,7 +115,7 @@ After initial configuration, a **time-taking start-up** procedure is required:

 ## Operations

-### Admin dashboards (PC — Labor Management menu)
+### Admin dashboards (PC - Labor Management menu)

 | View | Content |
 |------|---------|
@@ -130,7 +130,7 @@ After initial configuration, a **time-taking start-up** procedure is required:
 - 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.
+Each work records the warehouse configuration at execution time - changes to target times or adjustments do not retroactively affect recorded works.

 ## Errors & troubleshooting

@@ -143,8 +143,8 @@ Each work records the warehouse configuration at execution time — changes to t

 ## 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
+- [[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
@@ -96,13 +96,13 @@ Each production station is configured with either **automatic** or **manual** co

 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.
+**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
+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:
@@ -136,7 +136,7 @@ ERP sends MOR01 (or manager creates manually)

 > **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)
+### 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
@@ -173,7 +173,7 @@ During MO closing, the operator can declare that certain MPs were **rebuts** (de
 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
+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.
@@ -193,8 +193,8 @@ When finished goods use raw materials from **multiple lots or containers**, Easy

 ## 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
+- [[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
@@ -23,7 +23,7 @@ The module completes the end-to-end eCommerce cycle: marketplace order → WMS s

 - 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)
+- 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
@@ -57,6 +57,6 @@ The module completes the end-to-end eCommerce cycle: marketplace order → WMS s

 ## 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
+- [[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
@@ -83,7 +83,7 @@ If a Movirack is executing a movement and it must be stopped, the "Abort order"

 ## 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
+- [[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
@@ -37,7 +37,7 @@ last_compiled: "2026-04-26"

 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.
+**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.

@@ -63,7 +63,7 @@ The module supports multiple carriers simultaneously, enabling a single warehous

 **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.
+**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.

@@ -156,7 +156,7 @@ For each carrier to be used for packaging:
 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)
+   - Stage station (mandatory - one stage per carrier or shared)
   - Label report / Load manifest report
   - Weight capture flag
   - Tracking number sequence and workflow names
@@ -222,9 +222,9 @@ When `PACKAGING_VERIFY_TRACKING` is enabled and multiple users share a station,

 ## 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
+- [[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
@@ -80,8 +80,8 @@ Owner Extensions is installed as an intermediate module during WMS deployment (n

 ## 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
+- [[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
@@ -66,7 +66,7 @@ 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)
+- 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)

@@ -84,7 +84,7 @@ Each PS hardware model is registered as a **pallet shuttle type** with:
 | 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.
+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)
@@ -146,8 +146,8 @@ Search criteria (all must be met):
 - 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
+- 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.

@@ -189,13 +189,13 @@ Task canceled; location marked with "For AGV" lock type; user notified. No conta
 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
+- **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
+- [[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
@@ -54,32 +54,32 @@ Key benefits: reduced picking travel distances, balanced workloads, better space
 1. Demand analysis → 2. Item rotation list → 3. Slotting recommendations → 4. Selection → 5. Movement generation → 6. Execution
 ```

-**Step 1 — Demand analysis**:
+**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**:
+**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**:
+**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**:
+**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**:
+**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**:
+**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
@@ -103,13 +103,13 @@ Daily profit = (Distance_current_location - Distance_slotting_location) × (SLOT
 | 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 |
+| `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.
@@ -135,8 +135,8 @@ When the Slotting module is installed, the warehouse 2D map (Warehouse Designer)

 ## 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
+- [[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
@@ -48,7 +48,7 @@ EasyWMS receives a **TPV01** message from the ERP (or POS connector) each time a
 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.
+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

@@ -117,8 +117,8 @@ Managers can view real-time stock per store from the WMS interface. The view sho

 ## 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
+- [[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
@@ -19,7 +19,7 @@ last_compiled: "2026-04-10"

 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.
+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

@@ -96,6 +96,6 @@ Any Easy WMS user can send an internal message to another user. The recipient se

 ## 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
+- [[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
@@ -1,5 +1,5 @@
 ---
-title: "VAS — Value Added Services"
+title: "VAS - Value Added Services"
 type: module
 sources:
  - areas/vas/index.md
@@ -20,11 +20,11 @@ related:
 last_compiled: "2026-04-10"
 ---

-# VAS — Value Added Services
+# 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.
+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.

@@ -104,8 +104,8 @@ The SOR (Shipping Order Request) message supports a `VASCode` field that specifi

 ## 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
+- [[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
@@ -29,7 +29,7 @@ last_compiled: "2026-04-10"

 ## 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 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.

@@ -151,8 +151,8 @@ Interactive calendar showing all dock appointments, filtered by dock, date range

 ## 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
+- [[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