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

lint(standard): corrections completes mode standard

Browse Source 
- Em dashes: 1712 remplaces par tirets simples (86 fichiers + _index.md,
  en-tete section Limagrain conserve)
- Checklists: 24 '- [ ]' -> '- ☐' (3 pages operations, plus de todos Obsidian)
- Ancres: 33 reparees (slugs GitHub + ancres HTML <a id> reconnues),
  1 reciblee (manuel de reten)
- related: tenseflow -> tense-flow, pie -> mechanical-elements,
  group.md retire (doublon shipping)
- Registre: compteur global 122 -> 131 pages
- Rapport racine _lint_report.md mis a jour (scan v2 + re-scan final: 0 anomalie)
- Aucun fichier limagrain/ modifie (cloisonnement)
This commit is contained in:
Arthur
2026-07-20 13:01:21 +02:00
parent 7496aafe64
commit 9ce6ae37be
88 changed files with 1769 additions and 1871 deletions
Download Patch File Download Diff File Expand all files Collapse all files
wiki/concepts/order-outbound.md
+34 -34
View File
@@ -44,7 +44,7 @@ last_compiled: "2026-04-17"
A **shipping order** (outbound order) is the WMS document that drives the outbound fulfillment process. It is a list of items or containers that need to be shipped from the warehouse. Shipping orders represent customer sales orders, returns to suppliers, inter-warehouse transfers, and internal sub-warehouse replenishments.
Shipping orders are the primary driver of picking, consolidation, and truck loading operations. They arrive from the ERP via SOR messages in the vast majority of cases. Manual creation is possible for special cases (ERP unavailable, one-off requests). Every outbound activity in the WMS — from stock assignment to task generation to carrier document printing — traces back to a shipping order.
Shipping orders are the primary driver of picking, consolidation, and truck loading operations. They arrive from the ERP via SOR messages in the vast majority of cases. Manual creation is possible for special cases (ERP unavailable, one-off requests). Every outbound activity in the WMS - from stock assignment to task generation to carrier document printing - traces back to a shipping order.
A shipping order consists of a **header** (common attributes) and **lines** (specific items/containers with quantities). The lifecycle spans from creation through preparation, consolidation, and final closure with ERP notification.
@@ -56,8 +56,8 @@ The type determines the destination, the process, and how Easy WMS handles the s
|---|---|---|
| **Client** | Ship stock to a customer (sales order) | External; carrier delivery |
| **Return** | Return stock to a supplier | External; supplier |
| **Transfer** | Transfer to another warehouse in the organization. When closed, creates an inbound order at destination + ASN containers (same stacked structure as loaded). See [Transfer flow](#transfer--two-warehouse-flow-inbound-order-created). | Another warehouse |
| **Direct transfer** | Same as Transfer but destination doesn't need to receive — see [ASN — DirectTransfer flow](#asn--directtransfer-flow) below. ASN containers created at destination. Can transfer to the same warehouse. | Another warehouse (no receipt) |
| **Transfer** | Transfer to another warehouse in the organization. When closed, creates an inbound order at destination + ASN containers (same stacked structure as loaded). See [Transfer flow](#transfer---two-warehouse-flow-inbound-order-created). | Another warehouse |
| **Direct transfer** | Same as Transfer but destination doesn't need to receive - see [ASN - DirectTransfer flow](#asn---directtransfer-flow) below. ASN containers created at destination. Can transfer to the same warehouse. | Another warehouse (no receipt) |
| **Manual** | Created and prepared directly at RF terminal | Manual picking process |
| **Kits assembly/unassembly** | Supply kit components for assembly or collect kits for disassembly when work order released | Assembly/disassembly station |
| **Desk** | Created from a desk operation | Desk output |
@@ -135,7 +135,7 @@ Shipping orders also have a **class** for additional process customization (diff
[Force close with stock failures] → CLOSED (partial)
↓
ARCHIVED
[Any time before CLOSED]
→ CANCELED (no stock shipped)
```
@@ -160,7 +160,7 @@ Shipping orders also have a **class** for additional process customization (diff
- Orders **cannot mix lines** from different owners when the Owner Extension module is installed.
- **Priority** affects task sequencing across all active orders: urgent orders get their picking tasks executed first, at the cost of more picking rounds.
- **Critical lines** (`LneTrmCritical`): if the line cannot be fully assigned, no stock is prepared for that line (the rest of the order is unaffected).
- **Required lines to ship** (`LneTrmRequired`): if the required line cannot be fully shipped, the entire order blocks — nothing is prepared.
- **Required lines to ship** (`LneTrmRequired`): if the required line cannot be fully shipped, the entire order blocks - nothing is prepared.
- **Stock assignment** respects the configured stock assignment strategy (logic to minimize movements, maximize container use, minimize lots, etc.).
- **Excess shipping** (`LneQtyAllowExcess`): if exact quantity is impossible due to containerized stock, the system may over-allocate and then returns surplus.
- **Substitute items**: used when the ordered item is short. The substitution mode (partial/all-or-nothing) is defined in the item's shipping profile; explicit alternatives in the SOR override the profile.
@@ -173,11 +173,11 @@ Shipping orders also have a **class** for additional process customization (diff
### Messages: ERP → WMS
#### SOR — Shipping Order Request
#### SOR - Shipping Order Request
Creates, modifies, or cancels shipping orders. Two versions:
- **SOR01**: standard shipping orders
- **SOR02**: prepackaging — ERP specifies number/type of packages, stock per package, working mode (strict/non-strict). Also used with VAS (Value Added Services) module.
- **SOR02**: prepackaging - ERP specifies number/type of packages, stock per package, working mode (strict/non-strict). Also used with VAS (Value Added Services) module.
| Operation | Fields |
|---|---|
@@ -185,7 +185,7 @@ Creates, modifies, or cancels shipping orders. Two versions:
| `U` (update) | Modify header (priority, etc.) or individual lines |
| `D` (cancel) | Cancel the entire order |
| Line `C` | Create new line with `LneItemCode`, `LneContCode`, `LneQtyOrder`, `LneQtyUoMCode`, `LneAttributes` |
| Line `U` | Modify line (qty, UoM, attributes — restrictions apply if stock already prepared/shipped) |
| Line `U` | Modify line (qty, UoM, attributes - restrictions apply if stock already prepared/shipped) |
| Line `D` | Cancel specific line |
Key SOR fields:
@@ -208,7 +208,7 @@ Key SOR fields:
### Messages: WMS → ERP
#### SOC — Shipping Order status Change
#### SOC - Shipping Order status Change
Sent on every status transition of a shipping order.
@@ -224,13 +224,13 @@ Sent on every status transition of a shipping order.
Note: Grouped/fused orders do not report status changes for the grouped order or its components during grouped preparation.
#### SOF — Shipping Order Finalization
#### SOF - Shipping Order Finalization
Sent when an order is closed or canceled.
Two versions:
- **SOF01**: full data — includes MultiCarrier delivery info, VAS details, all lines. Sent at every partial close (with close number) and at final close/cancel.
- **SOF02**: modular — excludes MultiCarrier and VAS data. Created when communications became modular so each application manages its own messages.
- **SOF01**: full data - includes MultiCarrier delivery info, VAS details, all lines. Sent at every partial close (with close number) and at final close/cancel.
- **SOF02**: modular - excludes MultiCarrier and VAS data. Created when communications became modular so each application manages its own messages.
Key fields:
- `SorCode`, `Status` (Closed / Canceled)
@@ -241,7 +241,7 @@ Key fields:
If order is forced to close without shipping any stock, no line data is sent. If canceled, no line data is sent.
#### LOF — Load Finalization
#### LOF - Load Finalization
Sent when a load is finalized (truck loading complete). References shipping orders in the load.
@@ -288,13 +288,13 @@ Sent when a load is finalized (truck loading complete). References shipping orde
| Print documentation | Delivery note, packing list, differences report |
| Archive | After closure |
## ASN — DirectTransfer flow
## ASN - DirectTransfer flow
A `<DirectTransfer>` order (`<SorType>` in `SOR02`) requires **at least two warehouses** in the WMS. It ships stock from a source warehouse to a destination warehouse **without generating any inbound order or receipt at destination** — only ASN containers.
A `<DirectTransfer>` order (`<SorType>` in `SOR02`) requires **at least two warehouses** in the WMS. It ships stock from a source warehouse to a destination warehouse **without generating any inbound order or receipt at destination** - only ASN containers.
**Preparation** — identical to a standard client order. After the outbound order closes on the source warehouse, the shipped containers automatically appear on the destination warehouse's **`Asn`** location (visible in SmartUI via `Entrepôt → Conteneurs ASN`).
**Preparation** - identical to a standard client order. After the outbound order closes on the source warehouse, the shipped containers automatically appear on the destination warehouse's **`Asn`** location (visible in SmartUI via `Entrepôt → Conteneurs ASN`).
**Receiving an ASN container (destination warehouse)** — RFT menu `Réception → Préavis` of the destination warehouse :
**Receiving an ASN container (destination warehouse)** - RFT menu `Réception → Préavis` of the destination warehouse :
1. Receive onto the buffer or the equipment.
2. Scan the container (no other validation required).
@@ -302,11 +302,11 @@ A `<DirectTransfer>` order (`<SorType>` in `SOR02`) requires **at least two ware
> By design, the direct transfer **skips re-inspection** of the merchandise at the destination.
**Deleting / rejecting an ASN container** (container not arrived or not conforming) — SmartUI `Entrepôt → Conteneurs ASN` → select the container → **Supprimer**. This generates an **ASK01** file.
**Deleting / rejecting an ASN container** (container not arrived or not conforming) - SmartUI `Entrepôt → Conteneurs ASN` → select the container → **Supprimer**. This generates an **ASK01** file.
> ⚠️ Both `ASO01` and `ASK01` files **carry no reference to the origin transfer order**. The ERP itself must reconcile every ASO/ASK container against the originating `DirectTransfer` shipping order to confirm or invalidate the completeness of the transfer.
## Transfer — two-warehouse flow (inbound order created)
## Transfer - two-warehouse flow (inbound order created)
A `<Transfer>`-type order (`<SorType>` in `SOR02`) also requires **at least two warehouses** in the WMS. Unlike `<DirectTransfer>`, closing the outbound at source **automatically creates an inbound order at destination** with the same code as the source order. Containers arrive on the `Asn` location of the destination warehouse.
@@ -324,24 +324,24 @@ Destination-warehouse settings:
- `AutoCreateReceptionFromRecorder = true` → reception auto-created on first container scan.
- `AutoCloseInboundOrder = true` → closing the reception auto-closes the inbound order and emits `ROF02`.
> ⚠️ `ASO01` and `ASK01` still carry **no transfer-header info**. For `<Transfer>` flows the ERP **must** consume `ROF02` — which contains the full list of received containers.
> ⚠️ `ASO01` and `ASK01` still carry **no transfer-header info**. For `<Transfer>` flows the ERP **must** consume `ROF02` - which contains the full list of received containers.
See [Reception](reception.md#transfer--two-warehouse-asn-flow-with-receipt) for the receiving procedure.
See [Reception](reception.md#transfer---two-warehouse-asn-flow-with-receipt) for the receiving procedure.
## Merge (order fusion)
Merging consolidates multiple **outbound orders** into one preparation, so picking/packing/loading happens in a single pass. Merge applies to outbound orders — **not** to deliveries (a delivery is the *result* of a merge, not an input).
Merging consolidates multiple **outbound orders** into one preparation, so picking/packing/loading happens in a single pass. Merge applies to outbound orders - **not** to deliveries (a delivery is the *result* of a merge, not an input).
### Eligibility
**Required** — every candidate order must match on:
**Required** - every candidate order must match on:
- Complete `<ShippingAddress>` (every sub-tag)
- Complete `<DeliveryAddress>` + `<DeliveryContact>`
- Same order type (Client, Transfer, …)
- Status `Waiting`
- Identical `ExtraData`
**Disqualifying** — an order cannot be merged if it is already:
**Disqualifying** - an order cannot be merged if it is already:
- In another merge
- In a group
- In a wave
@@ -367,7 +367,7 @@ The merged order owns its own code, status and shipping date and is treated as a
</Delivery>
```
Parameter: **`ALLOW_MERGE_DIFFERENT_ACCOUNT`** — if set, allows merging orders from different customer accounts.
Parameter: **`ALLOW_MERGE_DIFFERENT_ACCOUNT`** - if set, allows merging orders from different customer accounts.
> ⚠️ **No automatic merge is shipped in standard.** Default is manual. Any automation is a custom scope.
@@ -415,12 +415,12 @@ The WMS uses the shipping-profile **substitution mode** (Partiel / Substitution
## Related
- [[shipping]] — the physical shipping process (consolidation, truck loading, PS groups, auto shipping) that fulfills outbound orders
- [[picking]] — picking processes execute tasks generated when outbound orders are released; waves/groups/fusions batch multiple orders
- [[stock]] — stock assignment links specific stock lines to order lines; reserves block stock for specific orders
- [[container]] — client containers hold prepared stock; container type requirements configurable per order/line
- [[task]] — release generates Picking and Shipping tasks; task priority driven by order priority
- [[replenishment]] — `EnableReplenishment` flag on SOR triggers automatic PDL replenishment when released
- [[order-inbound]] — Transfer-type outbound orders create receipt orders at destination + ASN pre-notifications
- [[crossdocking]] — ASN containers with exclusive reserves for outbound orders enable direct crossdocking on receipt
- [[erp-interface]] — SOR (in), SOC (out), SOF (out), LOF (out), WOF (out), RUT (in for routes), SCR/WSC (stock contrast)
- [[shipping]] - the physical shipping process (consolidation, truck loading, PS groups, auto shipping) that fulfills outbound orders
- [[picking]] - picking processes execute tasks generated when outbound orders are released; waves/groups/fusions batch multiple orders
- [[stock]] - stock assignment links specific stock lines to order lines; reserves block stock for specific orders
- [[container]] - client containers hold prepared stock; container type requirements configurable per order/line
- [[task]] - release generates Picking and Shipping tasks; task priority driven by order priority
- [[replenishment]] - `EnableReplenishment` flag on SOR triggers automatic PDL replenishment when released
- [[order-inbound]] - Transfer-type outbound orders create receipt orders at destination + ASN pre-notifications
- [[crossdocking]] - ASN containers with exclusive reserves for outbound orders enable direct crossdocking on receipt
- [[erp-interface]] - SOR (in), SOC (out), SOF (out), LOF (out), WOF (out), RUT (in for routes), SCR/WSC (stock contrast)