From 9ce6ae37be08c793547e04e9027dc911e638a911 Mon Sep 17 00:00:00 2001 From: Arthur Date: Mon, 20 Jul 2026 13:01:21 +0200 Subject: [PATCH] lint(standard): corrections completes mode standard MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - 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 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) --- wiki/_index.md | 206 +++++++++--------- wiki/_lint_report.md | 179 ++++----------- wiki/architecture/application-dictionary.md | 64 +++--- wiki/architecture/entities-map.md | 36 +-- wiki/architecture/galileo-integration.md | 72 +++--- wiki/architecture/overview.md | 26 +-- wiki/architecture/rf-menu.md | 67 +++--- wiki/architecture/security.md | 24 +- wiki/concepts/account-owner.md | 20 +- wiki/concepts/carrier.md | 12 +- wiki/concepts/consolidation.md | 20 +- wiki/concepts/container.md | 92 ++++---- wiki/concepts/count.md | 48 ++-- wiki/concepts/crossdocking.md | 46 ++-- wiki/concepts/cutting-stock.md | 42 ++-- wiki/concepts/defragmentation.md | 18 +- wiki/concepts/erp-interface.md | 116 +++++----- wiki/concepts/kits.md | 46 ++-- wiki/concepts/labels.md | 46 ++-- wiki/concepts/location.md | 30 +-- wiki/concepts/manual-movements.md | 24 +- wiki/concepts/mechanical-elements.md | 40 ++-- wiki/concepts/order-inbound.md | 34 +-- wiki/concepts/order-outbound.md | 68 +++--- wiki/concepts/parameters.md | 18 +- wiki/concepts/picking.md | 86 ++++---- wiki/concepts/prepackaging.md | 26 +-- wiki/concepts/product-item.md | 64 +++--- wiki/concepts/putaway.md | 100 ++++----- wiki/concepts/quality-control.md | 26 +-- wiki/concepts/reception.md | 54 ++--- wiki/concepts/replenishment.md | 90 ++++---- wiki/concepts/shipping.md | 86 ++++---- wiki/concepts/stations.md | 54 ++--- wiki/concepts/stock-adjustment.md | 52 ++--- wiki/concepts/stock-assignment.md | 54 ++--- wiki/concepts/stock.md | 38 ++-- wiki/concepts/supplier.md | 12 +- wiki/concepts/task.md | 36 +-- wiki/concepts/tense-flow.md | 24 +- wiki/concepts/transactions.md | 108 ++++----- wiki/concepts/warehouse-designer.md | 16 +- wiki/concepts/weights.md | 30 +-- wiki/glossary.md | 112 +++++----- wiki/modules/3pl-portal.md | 12 +- wiki/modules/agv.md | 26 +-- wiki/modules/aps3d.md | 14 +- wiki/modules/automation-dashboard.md | 18 +- wiki/modules/billing-3pl.md | 24 +- wiki/modules/client-specific-rules.md | 10 +- wiki/modules/cobot.md | 8 +- wiki/modules/data-analytics.md | 10 +- wiki/modules/directives.md | 20 +- wiki/modules/dom.md | 28 +-- wiki/modules/ecommerce.md | 10 +- wiki/modules/faults-management.md | 12 +- wiki/modules/labor-management.md | 16 +- wiki/modules/manufacturing.md | 18 +- wiki/modules/marketplaces.md | 8 +- wiki/modules/movirack.md | 8 +- wiki/modules/multi-carrier.md | 18 +- wiki/modules/owner-extensions.md | 10 +- wiki/modules/pallet-shuttle.md | 22 +- wiki/modules/slotting.md | 36 +-- wiki/modules/store-fulfillment.md | 12 +- wiki/modules/supply-chain-event.md | 8 +- wiki/modules/vas.md | 16 +- wiki/modules/yard-management.md | 12 +- wiki/operations/agv-installation.md | 68 +++--- wiki/operations/code-review-process.md | 28 +-- wiki/operations/configuration-guide.md | 136 ++++++------ .../custom-application-management.md | 22 +- wiki/operations/deploy-test-application.md | 24 +- wiki/operations/deployment-existing-app.md | 32 +-- wiki/operations/deployment-specific-commit.md | 18 +- wiki/operations/development-methodology.md | 18 +- wiki/operations/first-deployment.md | 50 ++--- wiki/operations/galileo-simulation.md | 60 ++--- wiki/operations/galileo-troubleshooting.md | 56 ++--- wiki/operations/git-branch-lifecycle.md | 22 +- wiki/operations/git-workflow.md | 44 ++-- wiki/operations/gna-services-license.md | 38 ++-- wiki/operations/robotics-project-lifecycle.md | 56 ++--- wiki/operations/ssh-keys-setup.md | 12 +- wiki/operations/troubleshooting.md | 58 ++--- wiki/operations/ugna-data-export.md | 20 +- wiki/operations/vm-installation.md | 22 +- wiki/operations/vm-network-routing.md | 18 +- 88 files changed, 1769 insertions(+), 1871 deletions(-) diff --git a/wiki/_index.md b/wiki/_index.md index cdcd237..65e4618 100644 --- a/wiki/_index.md +++ b/wiki/_index.md @@ -1,148 +1,148 @@ -# Wiki EasyWMS — Index +# Wiki EasyWMS - Index -Total : 122 pages +Total : 131 pages (85 standard + 46 Limagrain) ## Concepts (33 pages) -### Batch 1 — Core Entities +### Batch 1 - Core Entities -- [Container (LPN)](concepts/container.md) — LPN types, lifecycle statuses, locks, stacking/matching, reception, operations, transactions -- [Location](concepts/location.md) — Physical/virtual types (rack, compact, APS, buffer, dock), storage modes, logics, lock types, operations -- [Product / Item](concepts/product-item.md) — SKU master, UoM, logistic attributes (lot, expiry, serial), profiles (reception/putaway/shipping), types, families, labels, lifecycle management -- [Kits](concepts/kits.md) — Kit types (without/with assembly), assembly/disassembly lifecycle, WOR/WOF/KST/UNK ERP messages, quartering, traceability -- [Stock](concepts/stock.md) — Stock records, status (user/receiving/system), adjustments (quantity/UoM/logistic attributes), grouped reports -- [Stock Assignment](concepts/stock-assignment.md) — `StockAssignProcess_*` engine that binds stock to outbound lines ; pipeline (fetch/lock → search → strategy → create tasks), assignment types (PickingLocations / Replenishment / ShippingContainer / PickingContainer), kit + crossdocking + alternatives behaviour, customisation points -- [Weights](concepts/weights.md) — Five container-level weight fields (Calculated / Scale / Theoretical / Real / Theoretical Scale), formulas, PIE behaviour, variable-weight items, `Stock_CheckWeightToCreateStockInContainer_UI`, StockAdjust limits -- [Task](concepts/task.md) — Task and process types (putaway/picking/shipping/replenishment/count/movement), lifecycle, movements, semi-automatic mode -- [Inbound Order](concepts/order-inbound.md) — Receipt orders (supplier/return/transfer), lifecycle, ERP messages (ROR/ASN/ROC/ROF/ASO/STR) -- [Outbound Order](concepts/order-outbound.md) — Shipping orders (client/return/transfer), lifecycle, stock assignment, ERP messages (SOR/SOC/SOF/LOF) -- [Account / Owner](concepts/account-owner.md) — Owner (stock ownership, 3PL client) vs. Account (delivery point); mixing rules; OWN/ACC ERP messages -- [Supplier](concepts/supplier.md) — Supplier master data, attributes, use cases (receipts/returns), SUP ERP message -- [Carrier](concepts/carrier.md) — Base carrier + Extended carrier (Multi-Carrier module); delivery entity, tracking, packaging modes, CAR ERP message +- [Container (LPN)](concepts/container.md) - LPN types, lifecycle statuses, locks, stacking/matching, reception, operations, transactions +- [Location](concepts/location.md) - Physical/virtual types (rack, compact, APS, buffer, dock), storage modes, logics, lock types, operations +- [Product / Item](concepts/product-item.md) - SKU master, UoM, logistic attributes (lot, expiry, serial), profiles (reception/putaway/shipping), types, families, labels, lifecycle management +- [Kits](concepts/kits.md) - Kit types (without/with assembly), assembly/disassembly lifecycle, WOR/WOF/KST/UNK ERP messages, quartering, traceability +- [Stock](concepts/stock.md) - Stock records, status (user/receiving/system), adjustments (quantity/UoM/logistic attributes), grouped reports +- [Stock Assignment](concepts/stock-assignment.md) - `StockAssignProcess_*` engine that binds stock to outbound lines ; pipeline (fetch/lock → search → strategy → create tasks), assignment types (PickingLocations / Replenishment / ShippingContainer / PickingContainer), kit + crossdocking + alternatives behaviour, customisation points +- [Weights](concepts/weights.md) - Five container-level weight fields (Calculated / Scale / Theoretical / Real / Theoretical Scale), formulas, PIE behaviour, variable-weight items, `Stock_CheckWeightToCreateStockInContainer_UI`, StockAdjust limits +- [Task](concepts/task.md) - Task and process types (putaway/picking/shipping/replenishment/count/movement), lifecycle, movements, semi-automatic mode +- [Inbound Order](concepts/order-inbound.md) - Receipt orders (supplier/return/transfer), lifecycle, ERP messages (ROR/ASN/ROC/ROF/ASO/STR) +- [Outbound Order](concepts/order-outbound.md) - Shipping orders (client/return/transfer), lifecycle, stock assignment, ERP messages (SOR/SOC/SOF/LOF) +- [Account / Owner](concepts/account-owner.md) - Owner (stock ownership, 3PL client) vs. Account (delivery point); mixing rules; OWN/ACC ERP messages +- [Supplier](concepts/supplier.md) - Supplier master data, attributes, use cases (receipts/returns), SUP ERP message +- [Carrier](concepts/carrier.md) - Base carrier + Extended carrier (Multi-Carrier module); delivery entity, tracking, packaging modes, CAR ERP message -### Batch 2 — Core Flows +### Batch 2 - Core Flows -- [Reception](concepts/reception.md) — Receipt document structure, reception modes (dock, ASN, PIE, PK, returns), closing, ERP messages -- [Putaway](concepts/putaway.md) — Strategy engine pipeline, channel filling, aisle balancing, restrictions, sorting preferences, automatic station triggers -- [Picking](concepts/picking.md) — Stock assignment strategies, manual warehouse modes (automatic tasks, waves, PTL, voice, paper), automatic warehouse (direct, grouped, negative picking), Pick and Pack -- [Shipping](concepts/shipping.md) — Shipping order lifecycle, release, waves/groups/fusions, prepackaging, consolidation, routes, loads, truck loading, PS groups -- [Replenishment](concepts/replenishment.md) — PDL management, strategy types (top-off, shipping demand, stockout, sub-warehouse), efficiency modes, dynamic replenishment, automatic job -- [Crossdocking](concepts/crossdocking.md) — Opportunity crossdocking (direct to dock), crossdocking to warehouse (dedicated XD locations, IS crossdocking strategies) +- [Reception](concepts/reception.md) - Receipt document structure, reception modes (dock, ASN, PIE, PK, returns), closing, ERP messages +- [Putaway](concepts/putaway.md) - Strategy engine pipeline, channel filling, aisle balancing, restrictions, sorting preferences, automatic station triggers +- [Picking](concepts/picking.md) - Stock assignment strategies, manual warehouse modes (automatic tasks, waves, PTL, voice, paper), automatic warehouse (direct, grouped, negative picking), Pick and Pack +- [Shipping](concepts/shipping.md) - Shipping order lifecycle, release, waves/groups/fusions, prepackaging, consolidation, routes, loads, truck loading, PS groups +- [Replenishment](concepts/replenishment.md) - PDL management, strategy types (top-off, shipping demand, stockout, sub-warehouse), efficiency modes, dynamic replenishment, automatic job +- [Crossdocking](concepts/crossdocking.md) - Opportunity crossdocking (direct to dock), crossdocking to warehouse (dedicated XD locations, IS crossdocking strategies) -### Batch 3 — Inventory Operations +### Batch 3 - Inventory Operations -- [Count / Inventory](concepts/count.md) — Guided counts (location/item/container), physical count (RF), cycle count (rolling schedule), workstation count (automatic warehouse), ERP messages (COR/COF/SCR/WSC) -- [Stock Adjustment](concepts/stock-adjustment.md) — Quantity/UoM/logistic attribute adjustments, adjustment reasons, double validation (pending/confirmed/canceled), RF/SmartUI/Workstation interfaces -- [Consolidation](concepts/consolidation.md) — Container stock consolidation process: process→orders→tasks, filtering criteria, automatic warehouse (PK 2-loc, manual MP, buffer), configuration requirements -- [Defragmentation](concepts/defragmentation.md) — Automatic warehouse only: rotation optimization (ABC class → storage zone), shipping optimization (pre-position for dispatch), planners, MAX_DEFRAG_TASKS -- [Quality Control](concepts/quality-control.md) — Stock lock/unlock system: receiving status vs user status, lock from web/RF/ERP, automatic time-based unlock, cutting stock locks, STC/STR messages -- [Manual Movements](concepts/manual-movements.md) — Corrective stock/container relocations: 8 move types (location↔location, location↔container, container↔container, divisions, container move, cutting stock, partitions) +- [Count / Inventory](concepts/count.md) - Guided counts (location/item/container), physical count (RF), cycle count (rolling schedule), workstation count (automatic warehouse), ERP messages (COR/COF/SCR/WSC) +- [Stock Adjustment](concepts/stock-adjustment.md) - Quantity/UoM/logistic attribute adjustments, adjustment reasons, double validation (pending/confirmed/canceled), RF/SmartUI/Workstation interfaces +- [Consolidation](concepts/consolidation.md) - Container stock consolidation process: process→orders→tasks, filtering criteria, automatic warehouse (PK 2-loc, manual MP, buffer), configuration requirements +- [Defragmentation](concepts/defragmentation.md) - Automatic warehouse only: rotation optimization (ABC class → storage zone), shipping optimization (pre-position for dispatch), planners, MAX_DEFRAG_TASKS +- [Quality Control](concepts/quality-control.md) - Stock lock/unlock system: receiving status vs user status, lock from web/RF/ERP, automatic time-based unlock, cutting stock locks, STC/STR messages +- [Manual Movements](concepts/manual-movements.md) - Corrective stock/container relocations: 8 move types (location↔location, location↔container, container↔container, divisions, container move, cutting stock, partitions) -### Batch 4 — Layout & Configuration +### Batch 4 - Layout & Configuration -- [Stations & Routes](concepts/stations.md) — All 37+ station types (ALM/PIE/PK/PS/ME/MS/MU/ET/Dock/Stage/Cutting/Decision/Workzone/…), routes, managers, incidences, dock/stage configuration -- [Warehouse Designer](concepts/warehouse-designer.md) — Web Configurator (container types, rack types, zones, sub-warehouses, equipment, shelves, docks, stages, change log, transfer history), Warehouse Map (3D/2D, heat map) -- [Parameters](concepts/parameters.md) — All system parameters: Easy WMS core + Slotting + eCommerce + AGV/PS + APS3D + Multi-Carrier Shipping modules; cross-reference table by topic -- [Cutting Stock](concepts/cutting-stock.md) — Non-consolidating UoM, cutting profiles, shelf/station picking (integrated/delegated), stock assignment strategies (continuous/segmented/minimum), reception, counting, labels -- [Labels & Printing](concepts/labels.md) — Container labels (SSCC/GS1-128), item labels (Code128/GS1-128), cutting stock labels (A6), client container labels, RF label printing, multi-reading, auto-print triggers +- [Stations & Routes](concepts/stations.md) - All 37+ station types (ALM/PIE/PK/PS/ME/MS/MU/ET/Dock/Stage/Cutting/Decision/Workzone/…), routes, managers, incidences, dock/stage configuration +- [Warehouse Designer](concepts/warehouse-designer.md) - Web Configurator (container types, rack types, zones, sub-warehouses, equipment, shelves, docks, stages, change log, transfer history), Warehouse Map (3D/2D, heat map) +- [Parameters](concepts/parameters.md) - All system parameters: Easy WMS core + Slotting + eCommerce + AGV/PS + APS3D + Multi-Carrier Shipping modules; cross-reference table by topic +- [Cutting Stock](concepts/cutting-stock.md) - Non-consolidating UoM, cutting profiles, shelf/station picking (integrated/delegated), stock assignment strategies (continuous/segmented/minimum), reception, counting, labels +- [Labels & Printing](concepts/labels.md) - Container labels (SSCC/GS1-128), item labels (Code128/GS1-128), cutting stock labels (A6), client container labels, RF label printing, multi-reading, auto-print triggers -### Batch 10 — Fonctionnelles Mecalux France +### Batch 10 - Fonctionnelles Mecalux France -- [Prepackaging (Préemballage / Précolisage)](concepts/prepackaging.md) — Strategy configuration at shipping order type level; `SOR02 ` block; comparison with VAS; tested behaviour table; common errors -- [Tense Flow (Flux Tendu)](concepts/tense-flow.md) — EasyS zone configuration; 4-step functional flow (launch → execution → virtual picking → end); distinction from opportunity crossdocking; common errors +- [Prepackaging (Préemballage / Précolisage)](concepts/prepackaging.md) - Strategy configuration at shipping order type level; `SOR02 ` block; comparison with VAS; tested behaviour table; common errors +- [Tense Flow (Flux Tendu)](concepts/tense-flow.md) - EasyS zone configuration; 4-step functional flow (launch → execution → virtual picking → end); distinction from opportunity crossdocking; common errors -### Batch 12 — Robotics & GALILEO (Concepts) +### Batch 12 - Robotics & GALILEO (Concepts) -- [Mechanical Elements (Acronymes & Codes)](concepts/mechanical-elements.md) — ES→EN acronym table (~30 elements : AP/APC/APR/APS/ATC/CT/ECDF/EMS/EP/LBC/LRA/LRC/LRD/LRI/LRL/LTM/LZ/ML/MLB/MT/MTB/PSS/PTL/SGA/STL/STP/TC/TG/TM/TR), FR/ES/EN station code matrix (24 rows), conveyor tracking behaviour, miniload nomenclature (ML/MLB/EPSF/EPDF/ECDF) +- [Mechanical Elements (Acronymes & Codes)](concepts/mechanical-elements.md) - ES→EN acronym table (~30 elements : AP/APC/APR/APS/ATC/CT/ECDF/EMS/EP/LBC/LRA/LRC/LRD/LRI/LRL/LTM/LZ/ML/MLB/MT/MTB/PSS/PTL/SGA/STL/STP/TC/TG/TM/TR), FR/ES/EN station code matrix (24 rows), conveyor tracking behaviour, miniload nomenclature (ML/MLB/EPSF/EPDF/ECDF) ## Modules (24 pages) -### Batch 5 — Modules +### Batch 5 - Modules -- [AGV](modules/agv.md) — Automated Guided Vehicles: 4-component architecture (WMS→Gateway→PostgreSQL→fleet manager), 5 exchange tables, communication protocol (phases 00/03/04/06/08/10/255), fleet manager integration (standard SQL + REST/middleware pattern), error categories, RFT fallback, lock types, prerequisites -- [Pallet Shuttle](modules/pallet-shuttle.md) — WIFI-controlled compact channel cart: PSService, simple/multi modes, LIFO/FIFO, deposit/extraction/compaction, AGV-PS search, battery management -- [Multi-Carrier Shipping](modules/multi-carrier.md) — Delivery entity (carrier+consignee), 18 supported carriers (DHL/UPS/TNT/GLS/Colissimo/…), packing methods (scan all/choose count/always 1), carrier label printing, tracking numbers, delivery status lifecycle, automatic carrier selection -- [eCommerce](modules/ecommerce.md) — JIT reception flow: single-unit→packing, multi-unit→ungrouping, no-order→storage; 4 key parameters -- [Marketplaces](modules/marketplaces.md) — Prestashop/eBay/Amazon connectors; Amazon SaaS requirement; OUT.CREATE transaction -- [Slotting](modules/slotting.md) — Item rotation analysis (historical/current/external), golden zone, PDL-based recommendations, daily profit calculation, 7+ parameters -- [Labor Management](modules/labor-management.md) — Process→Activity→Work→Work Detail hierarchy; target time from layout+equipment; 16 measured processes; per-warehouse config -- [3PL Billing](modules/billing-3pl.md) — Contract→Rule→Planner hierarchy; 3 rule groups (Storage/Handling/Transaction); tiered pricing; pre-validation; 6 notification events; Owner Extensions prerequisite -- [3PL Portal](modules/3pl-portal.md) — Owner-filtered access for external 3PL clients; notification setup; KPI visibility; requires Owner Extensions -- [Yard Management](modules/yard-management.md) — Appointment lifecycle (Pending→Finished); checkpoints, parking lots, dock assignment, ERP/TMS integration -- [VAS](modules/vas.md) — Template→Activity→Instructions hierarchy; VAS profiles; ERP SOR VASCode field; shipping and packing station integration -- [Manufacturing](modules/manufacturing.md) — RCP01/RCP02 recipes, MOR01 production orders; MOF/FGP ERP messages; supply/production buffers; auto/manual consumption modes; additives; rebuts; NegativeStock -- [Store Fulfillment](modules/store-fulfillment.md) — Star topology (central warehouse → remote stores); TPV01 real-time POS sales; TOR01/TOF01 transfer orders; min/max replenishment; no desk stations -- [Supply Chain Event Management](modules/supply-chain-event.md) — Event subscription system; multi-channel (web/email/SMS); GNA notification; escalation; 3PL client subscriptions -- [Movirack](modules/movirack.md) — Mobile racking on motorized bases; aisle opening modes (with task/without task/manual/multi-aisle); 5 work modes -- [Cobot](modules/cobot.md) — Collaborative robot picking arm; suction cup tools; HPKS-R integration; always paired with manual station -- [APS3D](modules/aps3d.md) — 3D automated shuttle system; Fleet Manager controller; APS/APSFIFO locations; lifts; defragmentation modes -- [Data Analytics](modules/data-analytics.md) — Metric groups (consolidated/real-time) → Widgets → Dashboards; standard dashboards for WMS/LMS/APS3D; alarms -- [Automation Dashboard](modules/automation-dashboard.md) — Machine fault and manual action tracking for automatic warehouse equipment; fault reports; availability metrics -- [DOM (Distributed Order Management)](modules/dom.md) — Multi-node orchestration: 5-stage engine (region→carrier→stock→capacity→strategies); purchase/sales/replenishment orders; ERP messaging -- [Faults Management](modules/faults-management.md) — Backend of Automation Dashboard: fault records, manual action logs, availability reports (see automation-dashboard) -- [Directives](modules/directives.md) — Owner directives (workflow, documents) and account directives (container type, weight/height, shelf life, lot count, shipping logic) -- [Owner Extensions](modules/owner-extensions.md) — Prerequisite for Billing + 3PL Portal; adds mandatory owner to orders and 8 master data types -- [Client-Specific Rules](modules/client-specific-rules.md) — Source unavailable (404); concept maps to Directives module +- [AGV](modules/agv.md) - Automated Guided Vehicles: 4-component architecture (WMS→Gateway→PostgreSQL→fleet manager), 5 exchange tables, communication protocol (phases 00/03/04/06/08/10/255), fleet manager integration (standard SQL + REST/middleware pattern), error categories, RFT fallback, lock types, prerequisites +- [Pallet Shuttle](modules/pallet-shuttle.md) - WIFI-controlled compact channel cart: PSService, simple/multi modes, LIFO/FIFO, deposit/extraction/compaction, AGV-PS search, battery management +- [Multi-Carrier Shipping](modules/multi-carrier.md) - Delivery entity (carrier+consignee), 18 supported carriers (DHL/UPS/TNT/GLS/Colissimo/…), packing methods (scan all/choose count/always 1), carrier label printing, tracking numbers, delivery status lifecycle, automatic carrier selection +- [eCommerce](modules/ecommerce.md) - JIT reception flow: single-unit→packing, multi-unit→ungrouping, no-order→storage; 4 key parameters +- [Marketplaces](modules/marketplaces.md) - Prestashop/eBay/Amazon connectors; Amazon SaaS requirement; OUT.CREATE transaction +- [Slotting](modules/slotting.md) - Item rotation analysis (historical/current/external), golden zone, PDL-based recommendations, daily profit calculation, 7+ parameters +- [Labor Management](modules/labor-management.md) - Process→Activity→Work→Work Detail hierarchy; target time from layout+equipment; 16 measured processes; per-warehouse config +- [3PL Billing](modules/billing-3pl.md) - Contract→Rule→Planner hierarchy; 3 rule groups (Storage/Handling/Transaction); tiered pricing; pre-validation; 6 notification events; Owner Extensions prerequisite +- [3PL Portal](modules/3pl-portal.md) - Owner-filtered access for external 3PL clients; notification setup; KPI visibility; requires Owner Extensions +- [Yard Management](modules/yard-management.md) - Appointment lifecycle (Pending→Finished); checkpoints, parking lots, dock assignment, ERP/TMS integration +- [VAS](modules/vas.md) - Template→Activity→Instructions hierarchy; VAS profiles; ERP SOR VASCode field; shipping and packing station integration +- [Manufacturing](modules/manufacturing.md) - RCP01/RCP02 recipes, MOR01 production orders; MOF/FGP ERP messages; supply/production buffers; auto/manual consumption modes; additives; rebuts; NegativeStock +- [Store Fulfillment](modules/store-fulfillment.md) - Star topology (central warehouse → remote stores); TPV01 real-time POS sales; TOR01/TOF01 transfer orders; min/max replenishment; no desk stations +- [Supply Chain Event Management](modules/supply-chain-event.md) - Event subscription system; multi-channel (web/email/SMS); GNA notification; escalation; 3PL client subscriptions +- [Movirack](modules/movirack.md) - Mobile racking on motorized bases; aisle opening modes (with task/without task/manual/multi-aisle); 5 work modes +- [Cobot](modules/cobot.md) - Collaborative robot picking arm; suction cup tools; HPKS-R integration; always paired with manual station +- [APS3D](modules/aps3d.md) - 3D automated shuttle system; Fleet Manager controller; APS/APSFIFO locations; lifts; defragmentation modes +- [Data Analytics](modules/data-analytics.md) - Metric groups (consolidated/real-time) → Widgets → Dashboards; standard dashboards for WMS/LMS/APS3D; alarms +- [Automation Dashboard](modules/automation-dashboard.md) - Machine fault and manual action tracking for automatic warehouse equipment; fault reports; availability metrics +- [DOM (Distributed Order Management)](modules/dom.md) - Multi-node orchestration: 5-stage engine (region→carrier→stock→capacity→strategies); purchase/sales/replenishment orders; ERP messaging +- [Faults Management](modules/faults-management.md) - Backend of Automation Dashboard: fault records, manual action logs, availability reports (see automation-dashboard) +- [Directives](modules/directives.md) - Owner directives (workflow, documents) and account directives (container type, weight/height, shelf life, lot count, shipping logic) +- [Owner Extensions](modules/owner-extensions.md) - Prerequisite for Billing + 3PL Portal; adds mandatory owner to orders and 8 master data types +- [Client-Specific Rules](modules/client-specific-rules.md) - Source unavailable (404); concept maps to Directives module ## Architecture (6 pages) -### Batch 6 — Architecture & Integration +### Batch 6 - Architecture & Integration -- [System Architecture Overview](architecture/overview.md) — IIS/ASP.NET Core stack, SaaS vs on-premise, API families (AD/QueryExecute/CommandExecute/ERP), background jobs, warehouse types, hardware -- [Security](architecture/security.md) — Role hierarchy (SuperAdmin→Operator→3PL Client), authentication, authorization, owner isolation, station roles, container locks, audit trail -- [Application Dictionary](architecture/application-dictionary.md) — AD element types: Commands (operations), Queries (LINQ), Entities (data model), Views (projections), Dialogs (multi-step flows), Events (triggers), Workflows (orchestration), Background Jobs, Parameters; naming conventions; extension points -- [Entities Relationship Map](architecture/entities-map.md) — Complete entity model: Container→Location→Stock chain, order-to-task fulfillment chain, all entity attributes, module extensions (AGV/Multi-Carrier/3PL/DOM), referential constraints, transaction-entity mapping, ERP integration touch points per entity -- [RF Terminal Menu Map](architecture/rf-menu.md) — Full mapping of the 12 RFT menus (Tasks / Receptions / Putaway / Shipping orders / Replenishment / Counts / Kits / Quality / Groups / Utilities / Pick-and-Pass / Packaging) to their entry workflows ; `RFMenu_*` / `SharedMenu_*` codes for rights and customisation +- [System Architecture Overview](architecture/overview.md) - IIS/ASP.NET Core stack, SaaS vs on-premise, API families (AD/QueryExecute/CommandExecute/ERP), background jobs, warehouse types, hardware +- [Security](architecture/security.md) - Role hierarchy (SuperAdmin→Operator→3PL Client), authentication, authorization, owner isolation, station roles, container locks, audit trail +- [Application Dictionary](architecture/application-dictionary.md) - AD element types: Commands (operations), Queries (LINQ), Entities (data model), Views (projections), Dialogs (multi-step flows), Events (triggers), Workflows (orchestration), Background Jobs, Parameters; naming conventions; extension points +- [Entities Relationship Map](architecture/entities-map.md) - Complete entity model: Container→Location→Stock chain, order-to-task fulfillment chain, all entity attributes, module extensions (AGV/Multi-Carrier/3PL/DOM), referential constraints, transaction-entity mapping, ERP integration touch points per entity +- [RF Terminal Menu Map](architecture/rf-menu.md) - Full mapping of the 12 RFT menus (Tasks / Receptions / Putaway / Shipping orders / Replenishment / Counts / Kits / Quality / Groups / Utilities / Pick-and-Pass / Packaging) to their entry workflows ; `RFMenu_*` / `SharedMenu_*` codes for rights and customisation -### Batch 12 — Robotics & GALILEO (Architecture) +### Batch 12 - Robotics & GALILEO (Architecture) -- [GALILEO Integration](architecture/galileo-integration.md) — WMS ↔ GALILEO/EasyS protocol via EasyWMS Gateway (TCP 3000); three message types (Event / Search / End); station & route update streams; station capacity semantics (PK/PS per-route vs miniload TK per-station); handler workflows (`Galileo_PIEEventHandler_PR`, `Galileo_SearchCreatedEventHandler_PR`, `Galileo_EndCreatedEventHandler_PR`); `GalileoMovTrackingCreateCommand`; virtual location `Mov`; SCADA vs GALILEO vs WMS layering +- [GALILEO Integration](architecture/galileo-integration.md) - WMS ↔ GALILEO/EasyS protocol via EasyWMS Gateway (TCP 3000); three message types (Event / Search / End); station & route update streams; station capacity semantics (PK/PS per-route vs miniload TK per-station); handler workflows (`Galileo_PIEEventHandler_PR`, `Galileo_SearchCreatedEventHandler_PR`, `Galileo_EndCreatedEventHandler_PR`); `GalileoMovTrackingCreateCommand`; virtual location `Mov`; SCADA vs GALILEO vs WMS layering -## Concepts — Integration (Batch 6 additions) +## Concepts - Integration (Batch 6 additions) -- [ERP Interface](concepts/erp-interface.md) — Complete ERP message catalog: Masters (ITM/ITC/OWN/CAR/ACC/SUP/KIT), Inbound (ROR/ASN/SRN/ROC/ROF/REF/ASO/ASK/SRO/SRK), Outbound (SOR/SOC/SOF/LOF/WOR/WOF/RUT), Counts (COR/COF), Requests (STR/SCR/CMC), Notifications (STV/STC/WSC/KST/UNK/COS/COC), post-processing pipeline -- [Transactions & Notification Events](concepts/transactions.md) — All 60+ transaction type codes (CON.*/STK.*/INO.*/OUT.*/COU.*/TSK.*/etc.), post-processing flags, ERP message triggers; 25+ SCEM notification events with severity and subscription scope +- [ERP Interface](concepts/erp-interface.md) - Complete ERP message catalog: Masters (ITM/ITC/OWN/CAR/ACC/SUP/KIT), Inbound (ROR/ASN/SRN/ROC/ROF/REF/ASO/ASK/SRO/SRK), Outbound (SOR/SOC/SOF/LOF/WOR/WOF/RUT), Counts (COR/COF), Requests (STR/SCR/CMC), Notifications (STV/STC/WSC/KST/UNK/COS/COC), post-processing pipeline +- [Transactions & Notification Events](concepts/transactions.md) - All 60+ transaction type codes (CON.*/STK.*/INO.*/OUT.*/COU.*/TSK.*/etc.), post-processing flags, ERP message triggers; 25+ SCEM notification events with severity and subscription scope ## Operations (20 pages) -### Batch 7 — Operations & Finition +### Batch 7 - Operations & Finition -- [Troubleshooting Guide](operations/troubleshooting.md) — All common errors organized by symptom category (inbound, putaway, stock, picking, shipping, replenishment, count, quality, tasks/automation, ERP integration, system, master data) -- [Configuration Guide](operations/configuration-guide.md) — Deployment configuration guide in dependency order: infrastructure, EasyS layout, master data, reception, putaway, picking, replenishment, count, crossdocking, quality control, ERP integration, module-specific config, security -- [Development Methodology (Custom Apps)](operations/development-methodology.md) — Méthode de développement Mecalux France pour custom apps : stratégie de branches GIT (master/développement/post-production), phases dev/test/post-prod, manuel de reten en Markdown, redéploiement custom app +- [Troubleshooting Guide](operations/troubleshooting.md) - All common errors organized by symptom category (inbound, putaway, stock, picking, shipping, replenishment, count, quality, tasks/automation, ERP integration, system, master data) +- [Configuration Guide](operations/configuration-guide.md) - Deployment configuration guide in dependency order: infrastructure, EasyS layout, master data, reception, putaway, picking, replenishment, count, crossdocking, quality control, ERP integration, module-specific config, security +- [Development Methodology (Custom Apps)](operations/development-methodology.md) - Méthode de développement Mecalux France pour custom apps : stratégie de branches GIT (master/développement/post-production), phases dev/test/post-prod, manuel de reten en Markdown, redéploiement custom app -### Batch 8 — Deployment Workflow (Mecalux France) +### Batch 8 - Deployment Workflow (Mecalux France) -- [VM Installation (Hyper-V) & Validation](operations/vm-installation.md) — Création VM Hyper-V depuis template (`TEMPLATE_INTEGRATION_[DB]`), config réseau (InternoNAT/VMs, DNS Mecalux), renommage + Oracle tnsnames/listener, point de contrôle "Deploy 0", validation (MongoDB/IIS/SmartUI/consoleRF) -- [First Deployment (New Project)](operations/first-deployment.md) — Initialisation d'un projet neuf : `DeployConfig.yaml` (TenantName/DBEngine/MAPSeed/License/Warehouse/Data/StandardApplications/EnabledModules/Customs/Users), `deploy_repository.ps1`, Tenants.xml → InMemory (obligatoire), création initiale custom app, ToggleService pour versions 24.xx -- [Deploy Existing Application](operations/deployment-existing-app.md) — Redéploiement d'un projet déjà initialisé (nouveau dev, changement de branche, mise à jour) ; script unifié `deploy_repository.ps1 [Branche]` ; étape Tenants.xml InMemory obligatoire à chaque déploiement -- [Deploy Specific Commit](operations/deployment-specific-commit.md) — Figer un commit via tag GIT (convention `-V`) + branche dédiée, déploiement par `deploy_repository.ps1 ` ; utile pour reproduction de bugs, démos stables, tests de régression -- [Custom Application Management](operations/custom-application-management.md) — EasyBuilder : création (depuis FRANCE_OPERATIONS_TOOLS ou vierge avec dépendance EasyWMS), import (`Import and save application from text`), export (`Export application to text`) ; règles de coexistence multi-devs ; Check-out bloque l'export -- [Git Workflow (Git Flow)](operations/git-workflow.md) — Procédure opérationnelle Git Flow (CLI + SourceTree) : `git flow init`, `git flow feature start/finish -r`, gestion des conflits de rebase, commit/push quotidien obligatoire ; couvre les pré-requis d'export (custom app + uGNA + GNA) avant commit -- [GNA, Services & License Installation](operations/gna-services-license.md) — Sauvegarde GIT de la config GNA (`GNAGetDataForGit.ps1`, dossier `\services\GNA`, composition XSD multi-modules), réinstallation GNA (DeployCommsApps.ps1 "complete"), Label Printer (lien Confluence), licence WMS (demande + import via `EasySTS/License`) pour dépasser les 7 jours par défaut +- [VM Installation (Hyper-V) & Validation](operations/vm-installation.md) - Création VM Hyper-V depuis template (`TEMPLATE_INTEGRATION_[DB]`), config réseau (InternoNAT/VMs, DNS Mecalux), renommage + Oracle tnsnames/listener, point de contrôle "Deploy 0", validation (MongoDB/IIS/SmartUI/consoleRF) +- [First Deployment (New Project)](operations/first-deployment.md) - Initialisation d'un projet neuf : `DeployConfig.yaml` (TenantName/DBEngine/MAPSeed/License/Warehouse/Data/StandardApplications/EnabledModules/Customs/Users), `deploy_repository.ps1`, Tenants.xml → InMemory (obligatoire), création initiale custom app, ToggleService pour versions 24.xx +- [Deploy Existing Application](operations/deployment-existing-app.md) - Redéploiement d'un projet déjà initialisé (nouveau dev, changement de branche, mise à jour) ; script unifié `deploy_repository.ps1 [Branche]` ; étape Tenants.xml InMemory obligatoire à chaque déploiement +- [Deploy Specific Commit](operations/deployment-specific-commit.md) - Figer un commit via tag GIT (convention `-V`) + branche dédiée, déploiement par `deploy_repository.ps1 ` ; utile pour reproduction de bugs, démos stables, tests de régression +- [Custom Application Management](operations/custom-application-management.md) - EasyBuilder : création (depuis FRANCE_OPERATIONS_TOOLS ou vierge avec dépendance EasyWMS), import (`Import and save application from text`), export (`Export application to text`) ; règles de coexistence multi-devs ; Check-out bloque l'export +- [Git Workflow (Git Flow)](operations/git-workflow.md) - Procédure opérationnelle Git Flow (CLI + SourceTree) : `git flow init`, `git flow feature start/finish -r`, gestion des conflits de rebase, commit/push quotidien obligatoire ; couvre les pré-requis d'export (custom app + uGNA + GNA) avant commit +- [GNA, Services & License Installation](operations/gna-services-license.md) - Sauvegarde GIT de la config GNA (`GNAGetDataForGit.ps1`, dossier `\services\GNA`, composition XSD multi-modules), réinstallation GNA (DeployCommsApps.ps1 "complete"), Label Printer (lien Confluence), licence WMS (demande + import via `EasySTS/License`) pour dépasser les 7 jours par défaut -### Batch 9 — Dev Workflow Tooling, Reviews & Project Lifecycle (Mecalux France) +### Batch 9 - Dev Workflow Tooling, Reviews & Project Lifecycle (Mecalux France) -- [SSH Keys Setup (MSSCODE & Sourcetree)](operations/ssh-keys-setup.md) — Génération clé SSH ed25519 (`ssh-keygen` dans Git Bash), enregistrement sur MSSCODE avec vérification renforcée (signature SSH), configuration de Sourcetree (OpenSSH + clé privée), clonage SSH obligatoire -- [VM Network Routing (NAT, Localhost, IP, VPN)](operations/vm-network-routing.md) — Tableau NAT Hyper-V (HTTP/HTTPS/RDP/Oracle/SMB ports externes vs internes VM), accès local via `localhost`, accès distant via IP du PC hôte, passerelles VPN Mecalux Europe / Europe 4, conflit ZAPP/Zscaler -- [uGNA Data Export (WMS Configuration → Git)](operations/ugna-data-export.md) — Export config WMS (41 entités : owner/account/parameter/profils/strategies/stations/locks/etc.) via `uGNAConsole.exe -Z:` depuis CMD admin, dépose des XML dans `..\test` du Git, erreur droits + correction -- [Git Branch Lifecycle (Project Phases)](operations/git-branch-lifecycle.md) — Gouvernance Git par phase de projet et par acteur (Dev / CdP / Support / TMA) : développement initial (feature), avant MEP (merge `develop`→`master` + suppression `develop`), Hypercare, refus TLM si `develop` existe, branches `hotfix` Support, branches `release` TMA, communication bi-directionnelle Support↔TMA -- [Deploy Test Application (Tag → Test VM)](operations/deploy-test-application.md) — Procédure 7 étapes : création tag `-V` sur `develop`, checkpoint "Deploy 0" sur VM de test, redéploiement via `deploy_repository.ps1`, réinstallation GNA, printer service + licence, validation VM, transition Jira "Prêt à tester" avec tag obligatoire -- [Code Review Process (Code, Functional, Documentation)](operations/code-review-process.md) — Trois revues avant merge : Code (OutboundLines vs OutboundOrderLines, kits sans assemblage, ProductConversion null, préfixe `CST_`, nommage viewfields/SmartUI/attributs/dialogues, `ProcessContext.EnterAction`/`EscapeAction`, `FirstOrDefault` sécurisé), Fonctionnel (cas Jira + Échap dialogues), Documentation (Jira commentée, Git, Reten Markdown) +- [SSH Keys Setup (MSSCODE & Sourcetree)](operations/ssh-keys-setup.md) - Génération clé SSH ed25519 (`ssh-keygen` dans Git Bash), enregistrement sur MSSCODE avec vérification renforcée (signature SSH), configuration de Sourcetree (OpenSSH + clé privée), clonage SSH obligatoire +- [VM Network Routing (NAT, Localhost, IP, VPN)](operations/vm-network-routing.md) - Tableau NAT Hyper-V (HTTP/HTTPS/RDP/Oracle/SMB ports externes vs internes VM), accès local via `localhost`, accès distant via IP du PC hôte, passerelles VPN Mecalux Europe / Europe 4, conflit ZAPP/Zscaler +- [uGNA Data Export (WMS Configuration → Git)](operations/ugna-data-export.md) - Export config WMS (41 entités : owner/account/parameter/profils/strategies/stations/locks/etc.) via `uGNAConsole.exe -Z:` depuis CMD admin, dépose des XML dans `..\test` du Git, erreur droits + correction +- [Git Branch Lifecycle (Project Phases)](operations/git-branch-lifecycle.md) - Gouvernance Git par phase de projet et par acteur (Dev / CdP / Support / TMA) : développement initial (feature), avant MEP (merge `develop`→`master` + suppression `develop`), Hypercare, refus TLM si `develop` existe, branches `hotfix` Support, branches `release` TMA, communication bi-directionnelle Support↔TMA +- [Deploy Test Application (Tag → Test VM)](operations/deploy-test-application.md) - Procédure 7 étapes : création tag `-V` sur `develop`, checkpoint "Deploy 0" sur VM de test, redéploiement via `deploy_repository.ps1`, réinstallation GNA, printer service + licence, validation VM, transition Jira "Prêt à tester" avec tag obligatoire +- [Code Review Process (Code, Functional, Documentation)](operations/code-review-process.md) - Trois revues avant merge : Code (OutboundLines vs OutboundOrderLines, kits sans assemblage, ProductConversion null, préfixe `CST_`, nommage viewfields/SmartUI/attributs/dialogues, `ProcessContext.EnterAction`/`EscapeAction`, `FirstOrDefault` sécurisé), Fonctionnel (cas Jira + Échap dialogues), Documentation (Jira commentée, Git, Reten Markdown) -### Batch 12 — Robotics & GALILEO (Operations) +### Batch 12 - Robotics & GALILEO (Operations) -- [GALILEO Simulation (EasyS bring-up)](operations/galileo-simulation.md) — Install EasyWMS Gateway + MainObject.config (tenantCode/TokenUser/PasswordEncrypt), firewall port 3000, EasyS warehouse/aisle/rack/PLC Types config, SmartUI stations & routes preparation, TE/TS Logical X=991, LTM routing, PK + MP-extraction + MP-reject routes, PIE event injection procedure, 3 container extraction methods, Manual Action + Liberate flow, station sync LINQ query -- [GALILEO Troubleshooting (Log Analysis & Fault Triage)](operations/galileo-troubleshooting.md) — Gateway log path `C:\ProgramData\Mecalux\EasyWMS Gateway 2015\Logs\AllLog.log`, station/route update fields, klogg search patterns, End error codes table (0/1/2/4/7), 4-step resolution for `EndErrorCode=4` (config mismatch), fault codes 1116/1201/1291, WMS address change pointer to Confluence, pre-escalation checklist -- [Robotics Project Lifecycle](operations/robotics-project-lifecycle.md) — Stakeholders (chef de chantier, chef de projet IT, responsable électricité, responsable de projet), DTR doc, planning references, reference documentation table, station test milestone with LINQ audit query, "full" routes (CME→TE, PKE→PK, ET→PS), pre-go-live checklist +- [GALILEO Simulation (EasyS bring-up)](operations/galileo-simulation.md) - Install EasyWMS Gateway + MainObject.config (tenantCode/TokenUser/PasswordEncrypt), firewall port 3000, EasyS warehouse/aisle/rack/PLC Types config, SmartUI stations & routes preparation, TE/TS Logical X=991, LTM routing, PK + MP-extraction + MP-reject routes, PIE event injection procedure, 3 container extraction methods, Manual Action + Liberate flow, station sync LINQ query +- [GALILEO Troubleshooting (Log Analysis & Fault Triage)](operations/galileo-troubleshooting.md) - Gateway log path `C:\ProgramData\Mecalux\EasyWMS Gateway 2015\Logs\AllLog.log`, station/route update fields, klogg search patterns, End error codes table (0/1/2/4/7), 4-step resolution for `EndErrorCode=4` (config mismatch), fault codes 1116/1201/1291, WMS address change pointer to Confluence, pre-escalation checklist +- [Robotics Project Lifecycle](operations/robotics-project-lifecycle.md) - Stakeholders (chef de chantier, chef de projet IT, responsable électricité, responsable de projet), DTR doc, planning references, reference documentation table, station test milestone with LINQ audit query, "full" routes (CME→TE, PKE→PK, ET→PS), pre-go-live checklist -### Batch 13 — AGV Installation +### Batch 13 - AGV Installation -- [AGV Module — Installation Guide](operations/agv-installation.md) — Step-by-step installation of the AGV module: PostgreSQL setup, ODBC driver & System DSN (PostgreSQL35W), Gateway AGV service configuration, Oracle DBLink via dg4odbc (tnsnames.ora, listener.ora, initPostgreSQL35W.ora), synonyms on db_read, module deploy via response.xml; comprehensive troubleshooting section covering DSN case sensitivity, tnsnames indentation, listener ORACLE_HOME placeholder, PostgreSQL 18+ port change, double AGVConfig crash, Oracle case-sensitivity with double quotes +- [AGV Module - Installation Guide](operations/agv-installation.md) - Step-by-step installation of the AGV module: PostgreSQL setup, ODBC driver & System DSN (PostgreSQL35W), Gateway AGV service configuration, Oracle DBLink via dg4odbc (tnsnames.ora, listener.ora, initPostgreSQL35W.ora), synonyms on db_read, module deploy via response.xml; comprehensive troubleshooting section covering DSN case sensitivity, tnsnames indentation, listener ORACLE_HOME placeholder, PostgreSQL 18+ port change, double AGVConfig crash, Oracle case-sensitivity with double quotes ## Glossary (1 page) -- [Glossary](glossary.md) — All Mecalux/EasyWMS-specific terms: product names (EasyS, SmartUI, PIE, PDL, LPN, SSCC), abbreviations (AGV, PS, APS, SCEM, DOM, LMS, VAS, 3PL, PTL), AD element names, ERP message codes (ROR/SOR/ASN/SOF/etc.), transaction prefixes (CON.*/STK.*/TSK.*/etc.), key field names +- [Glossary](glossary.md) - All Mecalux/EasyWMS-specific terms: product names (EasyS, SmartUI, PIE, PDL, LPN, SSCC), abbreviations (AGV, PS, APS, SCEM, DOM, LMS, VAS, 3PL, PTL), AD element names, ERP message codes (ROR/SOR/ASN/SOF/etc.), transaction prefixes (CON.*/STK.*/TSK.*/etc.), key field names ## Limagrain — Projet (46 pages) diff --git a/wiki/_lint_report.md b/wiki/_lint_report.md index 35f61b8..ca0b070 100644 --- a/wiki/_lint_report.md +++ b/wiki/_lint_report.md @@ -1,155 +1,54 @@ --- title: "Wiki Health / Lint Report" type: meta -generated: "2026-05-12" -scope: "134 pages (84 standard + 45 limagrain + 5 racine)" +generated: "2026-07-20" +scope: "86 fichiers standard (architecture, concepts, modules, operations, glossary, _index)" --- -# Rapport de lint complet — Wiki EasyWMS + Limagrain +# Rapport de lint - Wiki standard EasyWMS -**Date** : 2026-05-12 -**Total fichiers analysés** : 134 (84 standard, 45 limagrain, 5 racine) -**Fichiers avec problèmes** : 95 (dont 81 uniquement LINE-LENGTH) -**Total problèmes** : 1820 +**Date** : 2026-07-20 (remplace le rapport du 2026-05-12) +**Périmètre** : wiki standard uniquement. Le lint Limagrain du même jour est +documenté dans [limagrain/_lint_report.md](limagrain/_lint_report.md). -## Résumé global par règle +## Scan initial (scanner v2) -| Règle | Total | Standard | Limagrain | Racine | Sévérité | -|-------|-------|----------|-----------|--------|----------| -| LINE-LENGTH (>120 car.) | 1761 | 1251 | 487 | 23 | Info | -| BROKEN-LINK | 33 | 0 | 21 | 12 | Erreur | -| DUPLICATE-HEADING | 13 | 5 | 0 | 8 | Warning | -| TRAILING-SPACE | 6 | 6 | 0 | 0 | Info | -| MULTI-H1 | 4 | 3 | 0 | 1 | Warning | -| FRONTMATTER-MISSING | 3 | 0 | 0 | 3 | Erreur | +Scanner corrigé par rapport aux passes précédentes : slug GitHub + ancres HTML +``, pipes échappés dans les tableaux, tracking des lignes vides +autour des blocs de code. 34 des 53 ancres signalées par le premier scan +étaient des faux positifs de l'ancien algorithme. -## Actions correctives appliquées (session 2026-05-12) +| Catégorie | Bloquant | Mineur | Cosmétique | Total | +|-----------|----------|--------|------------|-------| +| Front matter | 0 | 3 | 0 | 3 | +| Markdown / structure | 0 | 0 | 86 | 86 | +| Conventions (em dash, checklists) | 0 | 24 | 86 | 110 | +| Liens et ancres | 0 | 19 | 0 | 19 | +| Registre _index.md | 0 | 1 | 0 | 1 | +| Glossaire (doublons) | 0 | 0 | 0 | 0 | +| **Total** | **0** | **47** | **172** | **219** | -Corrections sur le wiki **Limagrain uniquement** (le standard est en lecture seule) : +## Corrections appliquées (session 2026-07-20, mode standard) -| Catégorie | Avant | Après | Action | -|-----------|-------|-------|--------| -| BLANK-LINES | 105 | 0 | Nettoyé sur 45 fichiers | -| BROKEN-LINK (vers standard) | 15 | 0 | Liens corrigés vers les bons fichiers | -| DUPLICATE-HEADING | 8 | 0 | Headings désambiguïsés | -| TRAILING-SPACE | 1 | 0 | Nettoyé | -| README.md tronqué | 1 | 0 | Fichier réécrit | -| **Total corrigé** | **130** | **0** | | +| Correction | Détail | +|------------|--------| +| Em dashes | 1712 « — » remplacés par « - » (86 fichiers + sections standard de `_index.md` ; l'en-tête `## Limagrain — Projet` conservé, format prescrit) | +| Checklists | 24 « `- [ ]` » convertis en « `- ☐` » (galileo-troubleshooting, git-workflow, robotics-project-lifecycle) - visuel checklist conservé sans créer de todos Obsidian | +| Ancres | 33 réparées (recalcul des slugs après conversion em dash + headings renommés). 2 fausses réparations annulées : `#import` et `#export` étaient valides via ancres HTML `` | +| Ancre irrésoluble | `code-review-process.md` : `#manuel-de-reten` reciblé vers `#1-phase-de-développement` (section contenant le passage sur le manuel de reten) | +| related | `stock-assignment.md` : `modules/tenseflow.md` → `concepts/tense-flow.md` ; `weights.md` : `modules/pie.md` → `concepts/mechanical-elements.md` ; `rf-menu.md` : `concepts/group.md` retiré (shipping.md déjà présent) | +| Registre | Compteur global corrigé : `Total : 131 pages (85 standard + 46 Limagrain)` | +| Trailing | 2 lignes nettoyées | ---- +Vérification croisée : aucune ancre du wiki Limagrain ne pointait vers un +heading standard modifié - aucun fichier `limagrain/` touché durant cette +session (cloisonnement respecté). -## Wiki standard — 15 problèmes (hors LINE-LENGTH) +## Re-scan final (2026-07-20) -> Le wiki standard est en **lecture seule** — ces problèmes sont documentés -> mais non corrigés. +**0 anomalie** : aucun lien cassé, aucune ancre morte (headings + ancres HTML), +aucun em dash, aucune checklist `- [ ]`, aucun trailing space, `related` +valides, registre complet (85/85 pages standard référencées). -### DUPLICATE-HEADING (5) - -| Fichier | Heading dupliqué | -|---------|-----------------| -| `concepts/crossdocking.md` | `Concept`, `Conditions and Eligibility`, `Process Flow` | -| `concepts/defragmentation.md` | `Strategy Rules (Destination Selection)`, `Execution` | - -### TRAILING-SPACE (6) - -| Fichier | Lignes | -|---------|--------| -| `concepts/cutting-stock.md` | L167, L256 | -| `concepts/labels.md` | L186, L215 | -| `concepts/stock-adjustment.md` | L150 | -| `concepts/warehouse-designer.md` | L210 | - -### MULTI-H1 (3) - -| Fichier | Nb H1 | -|---------|-------| -| `operations/deployment-existing-app.md` | 3 | -| `operations/first-deployment.md` | 3 | -| `operations/git-workflow.md` | 9 | - -### DUPLICATE-HEADING — operations - -| Fichier | Heading | -|---------|---------| -| `operations/custom-application-management.md` | `Procédure` | - -### LINE-LENGTH - -1251 occurrences sur l'ensemble des 84 pages standard. La plupart sont -des paragraphes longs non wrappés, typiques d'un wiki généré. - ---- - -## Wiki Limagrain — 21 problèmes résiduels - -Tous des **BROKEN-LINK vers des pages du squelette non encore créées**. -Aucun autre type de problème. - -### Pages du squelette manquantes (11) - -| Page | Section | Référencée depuis | -|------|---------|-------------------| -| `03-picking/waves-groupes.md` | Picking | README, _index.md | -| `03-picking/replenishment.md` | Picking | README, _index.md | -| `05-agv/still-igo-integration.md` | AGV | README, _index.md | -| `05-agv/agv-stations-routes.md` | AGV | README, _index.md | -| `05-agv/agv-troubleshooting.md` | AGV | README, _index.md | -| `06-erp-interface/interface-monitoring.md` | ERP | README, _index.md | -| `07-admin/parametres-projet.md` | Admin | README, _index.md | -| `07-admin/ad-customs.md` | Admin | README, _index.md | -| `08-transverse/jira-tickets-cles.md` | Transverse | README, _index.md | -| `08-transverse/decisions-architecture.md` | Transverse | README, _index.md, zones-stockage.md | -| `08-transverse/historique-projet.md` | Transverse | README, _index.md | - ---- - -## Fichiers racine — 23 problèmes (hors LINE-LENGTH) - -> Ces fichiers sont des méta-fichiers du dépôt. - -### `CLAUDE.md` - -- **FRONTMATTER-MISSING** : normal (fichier d'instructions, pas une page wiki) -- **MULTI-H1** (3) : structure multi-section attendue -- **BROKEN-LINK** (12) : liens d'exemple dans les templates, pas des - liens réels vers des pages - -### `_index.md` - -- **FRONTMATTER-MISSING** : fichier MCP discovery, format spécifique -- **DUPLICATE-HEADING** (2) : `Batch 12 — Robotics & GALILEO Integration` - apparaît 2 fois — doublon probable à nettoyer - -### `_log.md` - -- **FRONTMATTER-MISSING** : journal technique, format libre -- **DUPLICATE-HEADING** (5) : `Index`, `Rationale` (x2), - `Pages updated (1)`, `New pages created (1)` — structure répétitive - du log, pas un problème fonctionnel - ---- - -## Statistiques du wiki Limagrain - -| Métrique | Valeur | -|----------|--------| -| Pages rédigées (avec contenu) | 34 | -| Pages squelette (à créer) | 11 | -| Sections actives | 8 | -| Sessions d'intégration | 13 | -| Fichiers sources consommés | 22 | - -## Règles vérifiées - -- Front matter présent et complet (title, tags, status, last_updated) -- Status valide (draft, review, validated) -- Headings ATX uniquement, pas de saut de niveau -- Pas de heading H1 multiple -- Pas de headings dupliqués dans un même fichier -- Pas de lignes vides multiples consécutives -- Pas de trailing spaces -- Line length <= 120 caractères (souple pour tableaux/liens) -- Liens internes relatifs (pas de chemins absolus) -- Liens internes .md vérifiés (fichier cible existe) -- Toutes les pages référencées dans README.md -- Nommage kebab-case des fichiers +Résiduel connu non corrigé : lignes > 120 caractères (prose et front matter), +tolérées par la règle « souple pour tableaux et liens ». diff --git a/wiki/architecture/application-dictionary.md b/wiki/architecture/application-dictionary.md index 379aadc..ec73c83 100644 --- a/wiki/architecture/application-dictionary.md +++ b/wiki/architecture/application-dictionary.md @@ -26,18 +26,18 @@ The AD contains approximately **38,765 elements** spanning Commands, Queries, Di ### Commands -Commands represent **executable operations** — actions that change system state. +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 + - `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. @@ -49,16 +49,16 @@ Queries represent **data retrieval operations** using a LINQ-style expression en - 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 + - `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. +Entities are the **core data objects** of the system - the persistent domain model. Each Entity has: - A schema (fields, types, constraints) @@ -111,11 +111,11 @@ Views are **read-only projections** of one or more Entities, optimized for displ - 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 + - `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 @@ -126,10 +126,10 @@ Dialogs are **multi-step interactive flows** that guide an operator through a co - 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 + - `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. @@ -155,11 +155,11 @@ Workflows are **orchestrated sequences** of Commands, conditional logic, and sta - 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 + - `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 @@ -178,7 +178,7 @@ Background Jobs are **scheduled or continuous Workflows** that run autonomously: ### Parameters -AD Parameters are the **configuration knobs** of the system — named key-value pairs that alter behavior without code changes. +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) @@ -238,12 +238,12 @@ The AD can be extended by Mecalux partners: 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. +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 +- [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 diff --git a/wiki/architecture/entities-map.md b/wiki/architecture/entities-map.md index 24cd405..6edc188 100644 --- a/wiki/architecture/entities-map.md +++ b/wiki/architecture/entities-map.md @@ -25,7 +25,7 @@ last_compiled: "2026-04-10" ## Overview -This page provides the complete entity relationship model of Easy WMS, synthesized from all documented behavior across Batches 1–5. It shows the core entities, their key attributes, and how they relate to one another — forming the mental model needed to interpret WMS data. +This page provides the complete entity relationship model of Easy WMS, synthesized from all documented behavior across Batches 1–5. 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 @@ -436,16 +436,16 @@ 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 | — | +| Item | ITM | - | +| Owner | OWN | - | +| Supplier | SUP | - | +| Account | ACC | - | +| Carrier | CAR | - | | Kit | KIT | KST (assemble), UNK (disassemble) | -| ItemClassification | ITC | — | +| ItemClassification | ITC | - | | ReceiptOrder | ROR | ROC (status), ROF (close) | | Container (ASN) | ASN | ASO (received), ASK (rejected) | -| Receipt | — | REF (closed) | +| 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) | @@ -454,13 +454,13 @@ Each entity has ERP messages that create, update, or receive data: ## 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 +- [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 diff --git a/wiki/architecture/galileo-integration.md b/wiki/architecture/galileo-integration.md index 7df5181..8ac67ac 100644 --- a/wiki/architecture/galileo-integration.md +++ b/wiki/architecture/galileo-integration.md @@ -23,20 +23,20 @@ last_compiled: "2026-04-17" ## 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. +**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)) +- **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. +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 +- [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 @@ -79,7 +79,7 @@ A movement can only be generated if a **route** exists in EasyS between its orig ## 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). +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). @@ -120,7 +120,7 @@ Sometimes `ETPSxx → PSxx` must be reported to sequence shipping. Declaration of container presence at a meaningful point. Primary sources: -- **PIE**: reports a new container with label read + gauge data — EasyWMS decides conformity +- **PIE**: reports a new container with label read + gauge data - EasyWMS decides conformity - **TK**: announces presence - **Picking confirmation**: operator has finished a picking task @@ -140,7 +140,7 @@ PIE flag values (bitwise): | Flag | Meaning | |------|---------| -| `65536` | Container OK — no error | +| `65536` | Container OK - no error | | `256` | Barcode error | | `512` | Recovered container | | `1024` / `66560` | Correct + empty | @@ -151,14 +151,14 @@ PIE flag values (bitwise): **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 +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 +- **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` @@ -184,7 +184,7 @@ GALILEO asks EasyWMS "what should I do with this container?" or "give me a next |-------|------------------------| | 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 | +| WMS PK capacity | 15 - physical + transit + every task whose destination is PK | **Response state codes:** @@ -194,7 +194,7 @@ GALILEO asks EasyWMS "what should I do with this container?" or "give me a next | `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. +**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. @@ -204,7 +204,7 @@ GALILEO asks EasyWMS "what should I do with this container?" or "give me a next - 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. +> ⚠️ 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`, …) @@ -217,7 +217,7 @@ Signals that GALILEO has finished the current movement. EasyWMS advances to the | `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 | +| `4` | Inconsistent order | WMS/GALILEO configuration mismatch - see troubleshooting | | `7` | Gauge error | Relocation / reject | **Workflow triggered:** `Galileo_EndCreatedEventHandler_PR` @@ -233,7 +233,7 @@ Sent **every 1–3 seconds** by GALILEO (or immediately on change of state / loa | StationType | Station type code | | StationNumber | Station number | | Status | `0` = unavailable (fault, manual mode, safety); `1` = available | -| Loaded | `0` = occupied; `1` = free — **note the inversion** | +| 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 | @@ -251,7 +251,7 @@ SetStationStatus(Type, Numéro, Status, Présence, Capacité, Occupation, Allée |-------|---------| | StationTypeSource / StationNumberSource | Origin station | | StationTypeDestination / StationNumberDestination | Destination station | -| Status | `0`/`1`/`2`/`3` — see Route status values above | +| Status | `0`/`1`/`2`/`3` - see Route status values above | | CurrentCount | Trackings currently between the two stations | **Function exposed by GALILEO:** @@ -259,7 +259,7 @@ SetStationStatus(Type, Numéro, Status, Présence, Capacité, Occupation, Allée SetRouteStatus(TypeOrigine, NuméroOrigine, TypeDestination, NuméroDestination, Etat) ``` -## End-to-End Example — Container Arriving at PIE +## End-to-End Example - Container Arriving at PIE ``` 1. PIE reads label + gauges → Event (Galileo_PIEEventHandler_PR) @@ -277,7 +277,7 @@ SetRouteStatus(TypeOrigine, NuméroOrigine, TypeDestination, NuméroDestination, Every automation element is a sequential machine (grafcet) with discrete steps and transitions. Typical conveyor sequence: -1. Rest — ready to receive +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 @@ -299,8 +299,8 @@ Core workflows: Core commands: -- `GalileoMovTrackingCreateCommand` — push an order frame to GALILEO (preferred) -- `GalileoMovTrackingCreateChangingTargetCommand` — variant that changes target mid-transport (avoid unless strictly necessary) +- `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. @@ -310,25 +310,25 @@ The GALILEO SCADA (visualization tool) displays machines, trackings and faults i - **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 + - *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 + - *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 + - *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 +- [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 +- [Automation Dashboard](../modules/automation-dashboard.md) - fault monitoring UI - [Task](../concepts/task.md) · [Location](../concepts/location.md) diff --git a/wiki/architecture/overview.md b/wiki/architecture/overview.md index 9e0e33f..5dabe3c 100644 --- a/wiki/architecture/overview.md +++ b/wiki/architecture/overview.md @@ -2,7 +2,7 @@ title: "System Architecture Overview" type: architecture sources: - - areas/architecture/index.md (404 — compiled from cross-source knowledge) + - 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) @@ -111,7 +111,7 @@ Mixed warehouses (some automatic aisles, some manual) are supported. The warehou 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). +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). @@ -145,7 +145,7 @@ Both servers run Windows Server. For small warehouses the DB and App roles can b - **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) +- **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 @@ -156,8 +156,8 @@ 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) | — | — | — | +| **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. @@ -189,11 +189,11 @@ Key system parameters are documented at `areas/parameters.md`. Each functional m ## 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 +- [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 diff --git a/wiki/architecture/rf-menu.md b/wiki/architecture/rf-menu.md index f84e7bc..1b4749f 100644 --- a/wiki/architecture/rf-menu.md +++ b/wiki/architecture/rf-menu.md @@ -15,7 +15,6 @@ related: - concepts/kits.md - concepts/quality-control.md - concepts/container.md - - concepts/group.md - modules/multi-carrier.md last_compiled: "2026-04-17" --- @@ -29,11 +28,11 @@ The handheld RF terminal (`consolerf`) surfaces every operator flow through a fi 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. +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` +## 1. Tasks - `RFMenu_Task` | Menu entry | Workflow | |---|---| @@ -51,9 +50,9 @@ All workflow codes belong to the `EasyWMS` namespace unless otherwise noted (`De | Consolidation task | `EasyWMS.Consolidation_AutomaticTasks_FromMenu_UI` | | Cutting task | `EasyWMS.CutInStation_Main_UI` | -## 2. Receptions — `SharedMenu_Receptions` +## 2. Receptions - `SharedMenu_Receptions` -### Blind reception — `RFMenu_BlindReception` +### Blind reception - `RFMenu_BlindReception` | Menu entry | Workflow | |---|---| @@ -61,7 +60,7 @@ All workflow codes belong to the `EasyWMS` namespace unless otherwise noted (`De | Mono-reference | `EasyWMS.BlindReception_Monoreference_Containers_UI` | | Identical mono-reference | `EasyWMS.BlindReception_Monoreference_Identical_Containers_UI` | -### Suppliers — `RFMenu_Providers` +### Suppliers - `RFMenu_Providers` | Menu entry | Workflow | |---|---| @@ -77,14 +76,14 @@ All workflow codes belong to the `EasyWMS` namespace unless otherwise noted (`De | Advance notice reception | `EasyWMS.AdvanceNotice_Reception_UI` | | Generate labels | `EasyWMS.PrintLabels_MultireferenceContainerLabels_UI` | -## 3. Putaway — `RFMenu_Putaway` +## 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` +## 4. Shipping orders - `SharedMenu_ShippingOrders` | Menu entry | Workflow | |---|---| @@ -96,7 +95,7 @@ All workflow codes belong to the `EasyWMS` namespace unless otherwise noted (`De | Paper confirmation | `EasyWMS.Picking_ConfirmPickingPaper_UI` | | Manual preparation | `EasyWMS.Expedition_ManualPreparation_UI` | -### PTL Picking — `RFMenu_PickingPTLs` +### PTL Picking - `RFMenu_PickingPTLs` | Menu entry | Workflow | |---|---| @@ -107,7 +106,7 @@ All workflow codes belong to the `EasyWMS` namespace unless otherwise noted (`De | Equipment status | `EasyWMS.PTLsPickingPreparation_ManualEquipmentInfo_UI` | | Manual preparation | `EasyWMS.PTLsPickingPreparation_ManualPreparation_UI` | -### Truck loading — `RFMenu_TruckLoad` +### Truck loading - `RFMenu_TruckLoad` | Menu entry | Workflow | |---|---| @@ -116,14 +115,14 @@ All workflow codes belong to the `EasyWMS` namespace unless otherwise noted (`De | Stock load | `EasyWMS.StockTruckLoad_GetLoads_UI` | | Parcel load | `Deliveries.Dlv_TruckLoad_GetLoads_UI` | -### Undo preparation — `RFMenu_UndoPreparation` +### Undo preparation - `RFMenu_UndoPreparation` | Menu entry | Workflow | |---|---| | Undo preparation | `EasyWMS.UndoPreparation_Main_PR` | | Undo excess | `EasyWMS.UndoExcess_Main_PR` | -## 5. Replenishment — `RFMenu_Replenishment` +## 5. Replenishment - `RFMenu_Replenishment` | Menu entry | Workflow | |---|---| @@ -132,7 +131,7 @@ All workflow codes belong to the `EasyWMS` namespace unless otherwise noted (`De | By warehouse | `EasyWMS.Replenishment_GetAllProductLocationsByWarehouse_UI` | | By outbound order | `EasyWMS.Replenishment_GenerateTasksByOutboundOrder_UI` | -## 6. Counts — `SharedMenu_Counts` +## 6. Counts - `SharedMenu_Counts` | Menu entry | Workflow | |---|---| @@ -140,7 +139,7 @@ All workflow codes belong to the `EasyWMS` namespace unless otherwise noted (`De | Physical count | `EasyWMS.Count_StockOnPhysicalLocation_UI` | | Informed count | `EasyWMS.Count_StockOnPhysicalLocation_Informed_UI` | -## 7. Kits — `RFMenu_Kits` +## 7. Kits - `RFMenu_Kits` | Menu entry | Workflow | |---|---| @@ -148,7 +147,7 @@ All workflow codes belong to the `EasyWMS` namespace unless otherwise noted (`De | Assemble | `EasyWMS.KitAssembly_UI` | | Disassemble | `EasyWMS.KitDisassembly_UI` | -## 8. Quality — `RFMenu_Quality` +## 8. Quality - `RFMenu_Quality` | Menu entry | Workflow | |---|---| @@ -157,7 +156,7 @@ All workflow codes belong to the `EasyWMS` namespace unless otherwise noted (`De | Unlock by item | `EasyWMS.Quality_UnlockByProduct_UI` | | Unlock by container/location | `EasyWMS.Quality_UnlockByLocationOrContainer_UI` | -## 9. Groups — `RFMenu_Groups` +## 9. Groups - `RFMenu_Groups` | Menu entry | Workflow | |---|---| @@ -168,7 +167,7 @@ All workflow codes belong to the `EasyWMS` namespace unless otherwise noted (`De | Extraction without pack | `EasyWMS.Extraction_WithoutPack_UI` | | Change location | `EasyWMS.Ungroup_ChangeLocation_UI` | -## 10. Utilities — `RFMenu_Utilities` +## 10. Utilities - `RFMenu_Utilities` | Menu entry | Workflow | |---|---| @@ -192,7 +191,7 @@ All workflow codes belong to the `EasyWMS` namespace unless otherwise noted (`De | Show cart | `EasyWMS.Utils_ShowCart_UI` | | My cart | `EasyWMS.Equipment_MyCart_UI` | -### Remount / Unremount containers — `RFMenu_RemountUnRemountContainers` +### Remount / Unremount containers - `RFMenu_RemountUnRemountContainers` | Menu entry | Workflow | |---|---| @@ -201,7 +200,7 @@ All workflow codes belong to the `EasyWMS` namespace unless otherwise noted (`De | Unremount container | `EasyWMS.Container_UnremountContainer_UI` | | Unremount all containers | `EasyWMS.Container_UnremountAllContainers_UI` | -## 11. Pick and Pass — `Menu_PickAndPass` +## 11. Pick and Pass - `Menu_PickAndPass` | Menu entry | Workflow | |---|---| @@ -211,7 +210,7 @@ All workflow codes belong to the `EasyWMS` namespace unless otherwise noted (`De | Picking | `EasyWMS.PickAndPass_Picking_Main_PR` | | Automatic task | `EasyWMS.PickAndPass_AutomaticAssignment_Main_UI` | -## 12. Packaging — `Menu_Packaging` *(Multi-Carrier module)* +## 12. Packaging - `Menu_Packaging` *(Multi-Carrier module)* | Menu entry | Workflow | |---|---| @@ -222,7 +221,7 @@ All workflow codes belong to the `EasyWMS` namespace unless otherwise noted (`De | Move parcel | `Deliveries.Dlv_PackageManualMovement_PR` | | Bulk load | `Deliveries.Dlv_BulkLoad_UI` | -### Reprint tracking number — `ReprintTrackingNumber_RFMenu` +### Reprint tracking number - `ReprintTrackingNumber_RFMenu` | Menu entry | Workflow | |---|---| @@ -231,16 +230,16 @@ All workflow codes belong to the `EasyWMS` namespace unless otherwise noted (`De ## 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 +- [[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 diff --git a/wiki/architecture/security.md b/wiki/architecture/security.md index 15c7444..8202863 100644 --- a/wiki/architecture/security.md +++ b/wiki/architecture/security.md @@ -2,7 +2,7 @@ title: "Security" type: architecture sources: - - areas/security/index.md (404 — compiled from cross-source knowledge) + - areas/security/index.md (404 - compiled from cross-source knowledge) - areas/parameters.md - areas/inventory_management/stations/roles.md - modules cross-source knowledge @@ -52,8 +52,8 @@ Password policies (minimum length, complexity, expiry) are configurable in syste 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 +- 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) @@ -61,7 +61,7 @@ Operators can log in to RF terminals by scanning a personal QR Code instead of t 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 +- 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 @@ -73,7 +73,7 @@ Authorization is evaluated at two levels: 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. +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: @@ -161,10 +161,10 @@ The SCEM (Supply Chain Event Management) module allows subscribing to operationa ## 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 +- [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 diff --git a/wiki/concepts/account-owner.md b/wiki/concepts/account-owner.md index a98e4ec..2032419 100644 --- a/wiki/concepts/account-owner.md +++ b/wiki/concepts/account-owner.md @@ -24,9 +24,9 @@ last_compiled: "2026-04-10" EasyWMS uses two related but distinct entities for commercial master data: **Owner** and **Account**. -- An **Owner** is the entity that owns the stock in the warehouse (a sales company, the organization itself, or — in 3PL contexts — an external client). Every stock record has an owner. Owners can mix stock with each other only when mixing is explicitly enabled. +- An **Owner** is the entity that owns the stock in the warehouse (a sales company, the organization itself, or - in 3PL contexts - an external client). Every stock record has an owner. Owners can mix stock with each other only when mixing is explicitly enabled. -- An **Account** is a delivery point / customer of the warehouse — the entity to which a shipping order's stock is destined. Accounts represent end-customers or delivery addresses; they are referenced on outbound orders to control carrier preferences, label formats, and FEFO rules. +- An **Account** is a delivery point / customer of the warehouse - the entity to which a shipping order's stock is destined. Accounts represent end-customers or delivery addresses; they are referenced on outbound orders to control carrier preferences, label formats, and FEFO rules. The two are distinct: an owner holds inventory rights; an account receives shipments. A single owner can have many accounts (multiple delivery points). In 3PL deployments with Owner Extensions enabled, every receipt order, shipping order, and master data entity must be assigned to an owner. @@ -45,7 +45,7 @@ The two are distinct: an owner holds inventory rights; an account receives shipm ### Owner mixing rules By default, new owners are created with mixing **disabled**. Mixing can be enabled per owner. Additionally, specific owner exclusions can be added (preventing mixing with specific other owners). Mixing checks apply to: items, item types, item families, logistic attributes, and owners simultaneously. -In **automatic warehouses**, mixing restrictions are hard-enforced — the system will not allow a container to be stored if mixing rules are violated. In **manual warehouses**, operators can override mixing warnings. +In **automatic warehouses**, mixing restrictions are hard-enforced - the system will not allow a container to be stored if mixing rules are violated. In **manual warehouses**, operators can override mixing warnings. --- @@ -84,10 +84,10 @@ In **automatic warehouses**, mixing restrictions are hard-enforced — the syste ## Related -- [[stock]] — every stock record has an owner; owner mixing rules determine co-location eligibility -- [[order-outbound]] — shipping orders reference accounts (delivery destination) and can reference owner -- [[order-inbound]] — receipt orders reference owners when Owner Extensions is active -- [[owner-extensions]] — prerequisite module for mandatory owner assignment; enables per-owner data isolation -- [[billing-3pl]] — 3PL billing contracts are created per owner -- [[3pl-portal]] — 3PL portal access is filtered per owner; user group assignment controls visibility -- [[erp-interface]] — OWN and ACC messages manage owner/account master data from ERP +- [[stock]] - every stock record has an owner; owner mixing rules determine co-location eligibility +- [[order-outbound]] - shipping orders reference accounts (delivery destination) and can reference owner +- [[order-inbound]] - receipt orders reference owners when Owner Extensions is active +- [[owner-extensions]] - prerequisite module for mandatory owner assignment; enables per-owner data isolation +- [[billing-3pl]] - 3PL billing contracts are created per owner +- [[3pl-portal]] - 3PL portal access is filtered per owner; user group assignment controls visibility +- [[erp-interface]] - OWN and ACC messages manage owner/account master data from ERP diff --git a/wiki/concepts/carrier.md b/wiki/concepts/carrier.md index e27d974..98d8051 100644 --- a/wiki/concepts/carrier.md +++ b/wiki/concepts/carrier.md @@ -92,9 +92,9 @@ When the Multi-Carrier module is active, a **Delivery** combines carrier + consi ## Related -- [[shipping]] — shipping orders reference carriers; routes and loads assign containers to carriers -- [[order-outbound]] — SOR message can include carrier assignment; carrier determines delivery structure -- [[labels]] — carrier labels (tracking barcodes) printed during Multi-Carrier packaging -- [[multi-carrier]] — full carrier integration: packaging stations, tracking, delivery lifecycle -- [[yard-management]] — carrier appointments at yard checkpoints and docks -- [[erp-interface]] — CAR message syncs carrier master; RUT message sends route data +- [[shipping]] - shipping orders reference carriers; routes and loads assign containers to carriers +- [[order-outbound]] - SOR message can include carrier assignment; carrier determines delivery structure +- [[labels]] - carrier labels (tracking barcodes) printed during Multi-Carrier packaging +- [[multi-carrier]] - full carrier integration: packaging stations, tracking, delivery lifecycle +- [[yard-management]] - carrier appointments at yard checkpoints and docks +- [[erp-interface]] - CAR message syncs carrier master; RUT message sends route data diff --git a/wiki/concepts/consolidation.md b/wiki/concepts/consolidation.md index 3c111da..6ac28d8 100644 --- a/wiki/concepts/consolidation.md +++ b/wiki/concepts/consolidation.md @@ -24,8 +24,8 @@ last_compiled: "2026-04-10" **Consolidation** in EasyWMS is the process of moving stock from multiple partially-full containers into a single destination container, eliminating peaks and optimizing space usage in the warehouse. It is designed to run during **periods of inactivity**, interfering minimally with active warehouse operations. Two types of consolidation exist: -1. **Stock consolidation (warehouse)** — covered here. Compacts incomplete containers in storage to reduce the number of occupied locations. -2. **Shipping consolidation** — reorganizes prepared stock for outbound orders (see [shipping](../concepts/shipping.md)). Not covered here. +1. **Stock consolidation (warehouse)** - covered here. Compacts incomplete containers in storage to reduce the number of occupied locations. +2. **Shipping consolidation** - reorganizes prepared stock for outbound orders (see [shipping](../concepts/shipping.md)). Not covered here. Stock consolidation applies to both **manual** and **automatic** warehouses. @@ -137,9 +137,9 @@ Containers arrive sequenced at the PK: | Capacity exceeded at destination | Line adjusted; source remains non-empty | **Transactions:** -- `CON.MOVE` — container location changes (warehouse → PK → warehouse) -- `STK.MOVE` — stock moved from source to destination container -- `CON.SEND.L&F` — if empty source container is sent to Lost & Found +- `CON.MOVE` - container location changes (warehouse → PK → warehouse) +- `STK.MOVE` - stock moved from source to destination container +- `CON.SEND.L&F` - if empty source container is sent to Lost & Found ### Consolidation at Picking Conveyor with Manual Preparation Zones (MP) @@ -192,8 +192,8 @@ For consolidation to work correctly: ## Related -- [[container]] — Consolidation moves stock between containers; source containers are emptied, destination receives all stock -- [[location]] — Consolidation frees up locations by eliminating partial containers -- [[stock]] — STK.MOVE transactions update stock records during consolidation -- [[task]] — Consolidation generates source/destination task pairs; priority set by process priority -- [[shipping]] — Shipping consolidation (distinct concept) reorganizes prepared stock for outbound orders +- [[container]] - Consolidation moves stock between containers; source containers are emptied, destination receives all stock +- [[location]] - Consolidation frees up locations by eliminating partial containers +- [[stock]] - STK.MOVE transactions update stock records during consolidation +- [[task]] - Consolidation generates source/destination task pairs; priority set by process priority +- [[shipping]] - Shipping consolidation (distinct concept) reorganizes prepared stock for outbound orders diff --git a/wiki/concepts/container.md b/wiki/concepts/container.md index adf6113..6490323 100644 --- a/wiki/concepts/container.md +++ b/wiki/concepts/container.md @@ -36,9 +36,9 @@ last_compiled: "2026-04-17" ## Overview -A **LPN** (License Plate Number) is the fundamental unit of physical storage in EasyWMS — a box, pallet, or any other container that holds stock. Every unit of stock in the warehouse lives inside a LPN; the LPN is what moves, what gets located, locked, picked, and shipped. In identification contexts, the LPN is always labeled (Code 128 or GS1-128) and its code uniquely identifies it system-wide. +A **LPN** (License Plate Number) is the fundamental unit of physical storage in EasyWMS - a box, pallet, or any other container that holds stock. Every unit of stock in the warehouse lives inside a LPN; the LPN is what moves, what gets located, locked, picked, and shipped. In identification contexts, the LPN is always labeled (Code 128 or GS1-128) and its code uniquely identifies it system-wide. -The LPN is the bridge between the physical world (a pallet on a rack) and the logical world (stock records, tasks, orders). EasyWMS tracks every LPN's location, weight, status, contents, and relationships (stacked, matched, client-linked) in real time. All WMS movements — reception, putaway, picking, replenishment, shipping — are expressed as operations on LPNs. +The LPN is the bridge between the physical world (a pallet on a rack) and the logical world (stock records, tasks, orders). EasyWMS tracks every LPN's location, weight, status, contents, and relationships (stacked, matched, client-linked) in real time. All WMS movements - reception, putaway, picking, replenishment, shipping - are expressed as operations on LPNs. The term "container" in EasyWMS source documentation is synonymous with LPN. The entity name in the Application Dictionary is **Container**; the UI and documentation use both terms interchangeably. @@ -52,9 +52,9 @@ The term "container" in EasyWMS source documentation is synonymous with LPN. The | **Type** | Physical LPN type (e.g. EuroPallet, American pallet, box). Defines dimensional and weight constraints. Configured in EasyS. | | **Location** | Current warehouse location where the LPN is stored. | | **Height** | Measured in mm. Set by: PLC/SCA gauge at PIE station, user input during reception, ASN pre-notification, or manual screen edit. Includes the max height of any LPN stacked on top. | -| **Occupation percentage** | % of LPN capacity used by its stock. Not calculated automatically by EasyWMS — editable from the LPN view or set by the user. | +| **Occupation percentage** | % of LPN capacity used by its stock. Not calculated automatically by EasyWMS - editable from the LPN view or set by the user. | | **Is client LPN** | Boolean. `true` if the LPN's stock is assigned to a shipping order (outbound). Drives picking, shipping, and consolidation logic. | -| **Division type** | Internal partition configuration (see [Division Types](#division-types)). Only supported in automatic warehouses. LPNs with divisions only accept entry and picking tasks — shipping tasks are invalid. Content must be fully picked out before division LPN is used for shipping. | +| **Division type** | Internal partition configuration (see [Division Types](#division-types)). Only supported in automatic warehouses. LPNs with divisions only accept entry and picking tasks - shipping tasks are invalid. Content must be fully picked out before division LPN is used for shipping. | | **Status** | Current lifecycle state (see [Lifecycle & Statuses](#lifecycle--statuses)). | ### Weight Properties @@ -89,7 +89,7 @@ LPN types define the physical characteristics of an empty LPN. Configured in the | Maximum weight | kg | Max safe weight when loaded | | Collapse | mm | Max width deviation due to load collapse. Effective width = Width + 2 × Collapse. | -The collapse parameter matters for automatic warehouse location sizing — the system checks effective width when searching for a putaway location. +The collapse parameter matters for automatic warehouse location sizing - the system checks effective width when searching for a putaway location. **UI path:** EasyS tool (not EasyWMS web UI). @@ -258,7 +258,7 @@ Non-pre-notified stock arriving from a supplier in containers with multiple item | **Receipt and putaway** | Stock received on equipment; location search runs immediately for putaway. | | **Receipt on stage** | Stock registered in a stage; putaway done later by another operator or batch. | -A third variant: **exclusive reserve** — stock can be reserved for a specific shipping order at receipt time (configured via ROR message from ERP, see [erp-interface.md](../concepts/erp-interface.md)). The `CONFIRM_EXCLUSIVE_RESERVE_ASSIGNMENT` parameter controls whether the user must manually select the shipping order when multiple compatible orders exist. +A third variant: **exclusive reserve** - stock can be reserved for a specific shipping order at receipt time (configured via ROR message from ERP, see [erp-interface.md](../concepts/erp-interface.md)). The `CONFIRM_EXCLUSIVE_RESERVE_ASSIGNMENT` parameter controls whether the user must manually select the shipping order when multiple compatible orders exist. **ERP message sent at end of receipt:** `REF` **Transactions:** `CON.RECEP` (per container), `STK.RECEP` (per stock line) @@ -274,7 +274,7 @@ Unplanned, non-pre-notified stock with no entry order. A receipt is auto-created ### Partitioned Container Receipt -Both supplier and blind modes support receiving containers with internal partitions. Destination must always be an **automatic warehouse** — containers must be transported to a PIE or picking station after reception. +Both supplier and blind modes support receiving containers with internal partitions. Destination must always be an **automatic warehouse** - containers must be transported to a PIE or picking station after reception. --- @@ -291,19 +291,19 @@ Available actions on LPNs (full list from web UI): | LPN type modification | Change the LPN type. Only for **empty** LPNs. | PC | | Division type modification | Change division type. Only for **empty** LPNs. | PC | | Delete division | Remove division from LPN. Only for **empty** LPNs. | PC | -| Location change | Change LPN's recorded location. Does NOT create a movement task — only updates the data record. Treated as [manual movement](../concepts/manual-movements.md). In open APS FIFO channels, only accessible locations shown. | PC / RFT | +| Location change | Change LPN's recorded location. Does NOT create a movement task - only updates the data record. Treated as [manual movement](../concepts/manual-movements.md). In open APS FIFO channels, only accessible locations shown. | PC / RFT | | Send to Lost & Found | Send LPN to virtual L&F location when physical location unknown. In APS FIFO, only accessible or last LPN in channel. Stacked LPN: entire partial block (selected LPN + children) goes to L&F. | PC | | Relocation (automatic warehouses) | Change physical location via system-directed move: Automatic (putaway strategies), To an aisle (putaway strategies in selected aisle), To a location (no strategies, physical compatibility only), To a level (putaway strategies in selected level). | PC | | Mark as full / not full | Flag LPN as full so replenishment at PK conveyor skips it. Manual additions still possible. | PC | | Mark division as full / not full | Same as above for a specific division within a LPN. | PC | -| Shipping order unassignment | Unlink LPN from its shipping order. Works for mapped, prepared, or loaded LPN. No movement task created — operator is responsible for physical move. | PC | +| Shipping order unassignment | Unlink LPN from its shipping order. Works for mapped, prepared, or loaded LPN. No movement task created - operator is responsible for physical move. | PC | | Extraction request to PK conveyor | Request extraction from a station to a Picking conveyor for an action outside the system. | PC | | Request empty LPN to PK | Request empty LPN(s) of specific type/divisions to be sent to a Picking conveyor. | PC | | Extraction request to PS conveyor | Request extraction to an Outbound conveyor (PS). | PC | | Request empty LPN to PS | Extract empty LPN to Outbound conveyor (often to fill outside PK, e.g., for reception). | PC | -| Set depth coordinate | APS3D only — manually set depth coordinate for a LPN in an APS location. Superadmin only. | PC | +| Set depth coordinate | APS3D only - manually set depth coordinate for a LPN in an APS location. Superadmin only. | PC | | Manual compacting | APS/APSFIFO: compact LPN when free positions exist in front. | PC | -| Exchange LPN | APS3D only — swap a LPN in channel for one outside; must be same type. Superadmin only. | PC | +| Exchange LPN | APS3D only - swap a LPN in channel for one outside; must be same type. Superadmin only. | PC | | Consulting equipment LPNs (My LPNs) | View all LPNs on own equipment: code, type, status, stock lines (item, qty, UoM, logistic attributes). Can unload or reject LPNs from this view. | RFT | | Putaway search location trace | Report of last location search for this LPN. Shows strategies applied, excluded aisles, routes with issues, reserve percentages, stock line details. Superadmin sees full technical trace. | PC | | Stack / Match LPNs | Group LPNs vertically (stack) or horizontally (match). | RFT | @@ -322,7 +322,7 @@ EasyWMS interprets the following **GS1 Application Identifiers (AI)** on existin | AI | Meaning | |---|---| -| (00) | SSCC — Serial Shipping Container Code | +| (00) | SSCC - Serial Shipping Container Code | | (01) | GTIN grouping code / DUN14 | | (02) | EAN | | (10) | Lot number | @@ -343,7 +343,7 @@ Procedure: 2. Fill in the desired **prefix** 3. **Save** -Existing LPN codes are not rewritten — only containers generated after the change use the new prefix. +Existing LPN codes are not rewritten - only containers generated after the change use the new prefix. --- @@ -373,20 +373,20 @@ All container events generate transactions recorded in EasyWMS audit trail: |---|---|---| | `CON.ASN.001` | Container received for an ASN advance notice order | → `ASO` | | `CON.CNL.ASN` | Pre-notified container deleted or rejected | → `ASK` | -| `CON.COC` | Client container closed at Preparation Zone (MP) | — | -| `CON.COS.001` | Container extracted to Outbound Conveyor (PS) | — | -| `CON.CREATE` | Container created manually, from view, for picking, or during count | — | -| `CON.DELETE` | Container deleted (from L&F or after count) | — | -| `CON.LOAD` | Container loaded during truck loading | — | -| `CON.LOCATE` | Container moved to storage location via putaway task | — | -| `CON.MOVE` | Container moved without putaway task (or to destination with task) | — | +| `CON.COC` | Client container closed at Preparation Zone (MP) | - | +| `CON.COS.001` | Container extracted to Outbound Conveyor (PS) | - | +| `CON.CREATE` | Container created manually, from view, for picking, or during count | - | +| `CON.DELETE` | Container deleted (from L&F or after count) | - | +| `CON.LOAD` | Container loaded during truck loading | - | +| `CON.LOCATE` | Container moved to storage location via putaway task | - | +| `CON.MOVE` | Container moved without putaway task (or to destination with task) | - | | `CON.PIE` | Container entered via PIE station | → `ASO` | -| `CON.PRINT` | Packing list printed with client container label | — | -| `CON.RECEP` | Container received (supplier, return, or blind reception) | — | -| `CON.SEND.L&F` | Container sent to Lost & Found | — | -| `CON.SHIPPED` | Container shipped (shipping order closed) | — | -| `CON.SHIPPING` | Shipping task confirmed (container assigned to destination) | — | -| `CON.VASDONE` | VAS (Value Added Service) executed on container | — | +| `CON.PRINT` | Packing list printed with client container label | - | +| `CON.RECEP` | Container received (supplier, return, or blind reception) | - | +| `CON.SEND.L&F` | Container sent to Lost & Found | - | +| `CON.SHIPPED` | Container shipped (shipping order closed) | - | +| `CON.SHIPPING` | Shipping task confirmed (container assigned to destination) | - | +| `CON.VASDONE` | VAS (Value Added Service) executed on container | - | For detailed transaction data fields (Site, User, ContainerCode, LocationCode, etc.), see [concepts/transactions.md](../concepts/transactions.md). @@ -412,7 +412,7 @@ LPN-related ERP messages (all documented in [concepts/erp-interface.md](../conce | Path | Description | |---|---| -| `Warehouse > LPN` | Main LPN management view — all operations | +| `Warehouse > LPN` | Main LPN management view - all operations | | `Workstations > Picking` | LPN view from picking workstation perspective | | `Masters > Lock types` → "LPN lock types" | Manage lock type definitions | | `Masters > Division LPN types` | Manage division type definitions | @@ -453,7 +453,7 @@ LPN-related ERP messages (all documented in [concepts/erp-interface.md](../conce **Cannot modify LPN type or division:** - Symptom: Type/division change rejected. -- Cause: LPN is not empty — contains stock. +- Cause: LPN is not empty - contains stock. - Solution: Move or pick out all stock first, then change the type. **Putaway location not found for stacked LPN:** @@ -470,21 +470,21 @@ LPN-related ERP messages (all documented in [concepts/erp-interface.md](../conce ## Related -- [concepts/location.md](../concepts/location.md) — Locations where LPNs are stored; capacity, FIFO, dynamic, APS types -- [concepts/stock.md](../concepts/stock.md) — Stock lines that reside inside LPNs; adjustments, reserves -- [concepts/reception.md](../concepts/reception.md) — All reception modes; how LPNs are created and registered -- [concepts/putaway.md](../concepts/putaway.md) — Strategies that assign LPNs to storage locations -- [concepts/task.md](../concepts/task.md) — Tasks drive LPN movements (putaway, picking, replenishment, shipping) -- [concepts/shipping.md](../concepts/shipping.md) — Client LPN lifecycle through picking, consolidation, loading, shipping -- [concepts/order-inbound.md](../concepts/order-inbound.md) — Inbound orders (ASN, receipt orders) that pre-notify LPNs -- [concepts/order-outbound.md](../concepts/order-outbound.md) — Shipping orders that client LPNs are assigned to -- [concepts/labels.md](../concepts/labels.md) — LPN label formats, GS1-128, printing configuration -- [concepts/manual-movements.md](../concepts/manual-movements.md) — Manual location changes for LPNs -- [concepts/consolidation.md](../concepts/consolidation.md) — Container consolidation: stock from multiple partial LPNs merged into one destination container -- [concepts/quality-control.md](../concepts/quality-control.md) — Quality locks applied to stock inside LPNs; lock-by-container scope -- [concepts/transactions.md](../concepts/transactions.md) — Full CON.* and STK.* transaction reference -- [concepts/erp-interface.md](../concepts/erp-interface.md) — ASN, ROR, REF, ASO, ASK message definitions -- [modules/agv.md](../modules/agv.md) — AGV equipment that transports LPNs in automated warehouses -- [modules/pallet-shuttle.md](../modules/pallet-shuttle.md) — Pallet shuttle system managing compact LPN storage -- [modules/vas.md](../modules/vas.md) — Value Added Services applied to LPNs (`CON.VASDONE`) -- [modules/aps3d.md](../modules/aps3d.md) — 3D APS storage: depth coordinates, compacting, LPN exchange +- [concepts/location.md](../concepts/location.md) - Locations where LPNs are stored; capacity, FIFO, dynamic, APS types +- [concepts/stock.md](../concepts/stock.md) - Stock lines that reside inside LPNs; adjustments, reserves +- [concepts/reception.md](../concepts/reception.md) - All reception modes; how LPNs are created and registered +- [concepts/putaway.md](../concepts/putaway.md) - Strategies that assign LPNs to storage locations +- [concepts/task.md](../concepts/task.md) - Tasks drive LPN movements (putaway, picking, replenishment, shipping) +- [concepts/shipping.md](../concepts/shipping.md) - Client LPN lifecycle through picking, consolidation, loading, shipping +- [concepts/order-inbound.md](../concepts/order-inbound.md) - Inbound orders (ASN, receipt orders) that pre-notify LPNs +- [concepts/order-outbound.md](../concepts/order-outbound.md) - Shipping orders that client LPNs are assigned to +- [concepts/labels.md](../concepts/labels.md) - LPN label formats, GS1-128, printing configuration +- [concepts/manual-movements.md](../concepts/manual-movements.md) - Manual location changes for LPNs +- [concepts/consolidation.md](../concepts/consolidation.md) - Container consolidation: stock from multiple partial LPNs merged into one destination container +- [concepts/quality-control.md](../concepts/quality-control.md) - Quality locks applied to stock inside LPNs; lock-by-container scope +- [concepts/transactions.md](../concepts/transactions.md) - Full CON.* and STK.* transaction reference +- [concepts/erp-interface.md](../concepts/erp-interface.md) - ASN, ROR, REF, ASO, ASK message definitions +- [modules/agv.md](../modules/agv.md) - AGV equipment that transports LPNs in automated warehouses +- [modules/pallet-shuttle.md](../modules/pallet-shuttle.md) - Pallet shuttle system managing compact LPN storage +- [modules/vas.md](../modules/vas.md) - Value Added Services applied to LPNs (`CON.VASDONE`) +- [modules/aps3d.md](../modules/aps3d.md) - 3D APS storage: depth coordinates, compacting, LPN exchange diff --git a/wiki/concepts/count.md b/wiki/concepts/count.md index 082bba0..f7705bc 100644 --- a/wiki/concepts/count.md +++ b/wiki/concepts/count.md @@ -49,9 +49,9 @@ last_compiled: "2026-04-17" A **count** (also called inventory or stock take) in EasyWMS is a formal process for verifying that the physical stock in the warehouse matches the quantities recorded in the system. When discrepancies are found, the system adjusts its records accordingly and notifies the ERP. EasyWMS supports three fundamental counting approaches: -- **Guided counts** — a count order is created (from the WMS interface or by ERP messaging), tasks are generated, and operators follow those tasks with their RFT. -- **Physical count** — an unguided, operator-initiated blind count of a specific location directly from the RFT, without a prior order. -- **Cycle count** — automated rolling inventory that divides counting across many days, integrating inventory into daily warehouse operations without shutting down the warehouse. +- **Guided counts** - a count order is created (from the WMS interface or by ERP messaging), tasks are generated, and operators follow those tasks with their RFT. +- **Physical count** - an unguided, operator-initiated blind count of a specific location directly from the RFT, without a prior order. +- **Cycle count** - automated rolling inventory that divides counting across many days, integrating inventory into daily warehouse operations without shutting down the warehouse. Counts can be performed in manual warehouses (operators walk to locations) and automatic warehouses (containers are extracted to a picking conveyor / workstation). @@ -73,8 +73,8 @@ A single count order can mix lines of different types. | Method | Who initiates | Order required | Auto-adjusts | |---|---|---|---| -| **Guided count — from WMS interface** | Warehouse manager (PC) | Yes | No (ERP notified via STV per diff) | -| **Guided count — from ERP (COR message)** | ERP | Yes | No (ERP notified via COF at close) | +| **Guided count - from WMS interface** | Warehouse manager (PC) | Yes | No (ERP notified via STV per diff) | +| **Guided count - from ERP (COR message)** | ERP | Yes | No (ERP notified via COF at close) | | **Physical count (RF)** | Operator from RFT | No | Yes (immediate) | | **Cycle count** | Scheduler job | Auto-generated | No (ERP notified via STV) | | **Automatic warehouse count** | Manager assigns PK | Yes | No | @@ -128,7 +128,7 @@ Closing can be **automatic** (`AUTOCLOSE_COUNT_ORDERS` parameter) or manual. Ord --- -## Guided Count — Execution +## Guided Count - Execution ### Task Generation at Release @@ -145,14 +145,14 @@ Locations configured as "does not allow inventory" in EasyS are skipped. Locks o ### Blind vs. Informed Mode For **location count** lines, the **Is Informed** flag (FR : `Est renseigné`) determines the counting mode: -- **Blind count** — operator enters quantities without seeing current system values (default). Operator must enter item, quantity, logistic attributes from scratch. -- **Informed count** — system shows current recorded stock; operator adjusts as needed. +- **Blind count** - operator enters quantities without seeing current system values (default). Operator must enter item, quantity, logistic attributes from scratch. +- **Informed count** - system shows current recorded stock; operator adjusts as needed. Item counts and container counts are always blind. -**Per-line setting.** `Est renseigné` is a **per-line** toggle, not a per-order toggle — within the same count order, some lines (e.g. the picking aisles) can be `Informed` while others (e.g. the reserve) stay blind. +**Per-line setting.** `Est renseigné` is a **per-line** toggle, not a per-order toggle - within the same count order, some lines (e.g. the picking aisles) can be `Informed` while others (e.g. the reserve) stay blind. -> If the `Est renseigné` column is missing from the count-line grid : select a line and click **"Visibilité"**. If it is still hidden, the grid's visibility condition must be relaxed — edit the `CountOrderLineVList` view and comment out (`/* … */`) the visibility condition, forcing it to `true`. +> If the `Est renseigné` column is missing from the count-line grid : select a line and click **"Visibilité"**. If it is still hidden, the grid's visibility condition must be relaxed - edit the `CountOrderLineVList` view and comment out (`/* … */`) the visibility condition, forcing it to `true`. ### Counting items with serial numbers @@ -163,7 +163,7 @@ When an item is counted on an attribute unique per piece (a serial number) : 3. Click **"Terminé"** when every piece has a serial. 4. Enter the next item of the location, or click **"Fin"** if the location is done. -The WMS then reports that the original (no-serial) item line was not found — click **"Introuvable"** : this removes the no-serial stock line and creates the new serialized stock lines in its place. +The WMS then reports that the original (no-serial) item line was not found - click **"Introuvable"** : this removes the no-serial stock line and creates the new serialized stock lines in its place. ### Count in Automatic Warehouse (Workstation) @@ -186,12 +186,12 @@ For picking locations with labeled partitions assigned per item (dedicated picki - Reassign partitions to items during the count Parameters: -- `UNLOAD_CREATE_PRODUCT_LOCATION` — when active, auto-creates PDL assignment for a newly counted item -- `ALLOW_DYNAMIC_UNASSIGNED_PARTITION` — allows dynamically unassigning empty partitions during count +- `UNLOAD_CREATE_PRODUCT_LOCATION` - when active, auto-creates PDL assignment for a newly counted item +- `ALLOW_DYNAMIC_UNASSIGNED_PARTITION` - allows dynamically unassigning empty partitions during count --- -## Physical Count (RF — No Order Required) +## Physical Count (RF - No Order Required) The **Physical Count** is a fast, location-by-location blind count initiated directly from the RFT. No count order is needed. @@ -250,9 +250,9 @@ Count orders generated by cycle count **cannot be re-released after cancellation ### Iteration States -- **On progress** — active iteration running -- **Finished** — iteration end date passed (transitions next day) -- **Canceled** — manually terminated early +- **On progress** - active iteration running +- **Finished** - iteration end date passed (transitions next day) +- **Canceled** - manually terminated early Schedules can be **enabled/disabled**. A schedule with an active iteration cannot be disabled. @@ -332,15 +332,15 @@ For counts **not** created by the ERP (manual WMS counts, physical counts, cycle | Count line shows conflict icon (no inventory allowed) | Location not flagged for inventory in EasyS | Fix location config in EasyS or delete the line | | COF message not sent after close | Count originated from COR and has pending adjustments (double validation) | Validate or cancel all pending adjustments | | Cycle count generates uneven task distribution | Volatile stock levels change mid-iteration (especially item schedules) | Expected behavior; adjust schedule parameters if needed | -| Cannot re-release a cycle count after cancel | By design — cycle count orders are non-re-releasable | Create a new manual count for the affected locations | +| Cannot re-release a cycle count after cancel | By design - cycle count orders are non-re-releasable | Create a new manual count for the affected locations | --- ## Related -- [[stock-adjustment]] — Count discrepancies trigger STK.ADJ adjustments; double validation applies to both -- [[stock]] — Count validates and corrects stock records; see STV/STK.ADJ transactions -- [[location]] — Location "allows inventory" flag governs whether counting tasks are generated -- [[container]] — Container count type counts an LPN and all its stock -- [[product-item]] — Item count type; count profile on item controls double validation -- [[task]] — Count tasks (TSK.COU) follow the standard task lifecycle +- [[stock-adjustment]] - Count discrepancies trigger STK.ADJ adjustments; double validation applies to both +- [[stock]] - Count validates and corrects stock records; see STV/STK.ADJ transactions +- [[location]] - Location "allows inventory" flag governs whether counting tasks are generated +- [[container]] - Container count type counts an LPN and all its stock +- [[product-item]] - Item count type; count profile on item controls double validation +- [[task]] - Count tasks (TSK.COU) follow the standard task lifecycle diff --git a/wiki/concepts/crossdocking.md b/wiki/concepts/crossdocking.md index 7d3476a..811db8f 100644 --- a/wiki/concepts/crossdocking.md +++ b/wiki/concepts/crossdocking.md @@ -4,7 +4,7 @@ type: concept sources: - areas/crossdocking/crossdocking_manual/index.md - areas/crossdocking/crossdocking_manual/crossdocking_warehouse.md - - areas/crossdocking/crossdocking_manual/crossdocking_opportunity.md (404 — sourced from index.md description) + - areas/crossdocking/crossdocking_manual/crossdocking_opportunity.md (404 - sourced from index.md description) - areas/putaway/putaway_admin/index.md (Group by SO/Route strategy type) - sources/archives/06_Gestion_cross_docking.md related: @@ -38,8 +38,8 @@ Both types apply to containers, stacked containers, carts, and loose stock recei When an operator is about to putaway received stock/containers, EasyWMS checks if any unreleased or in-preparation shipping order needs that stock. If yes, instead of going to bulk storage, the stock is directed straight to the dock, stage, or buffer associated with the shipping order. The process triggers at two moments: -1. **After receipt into equipment** — operator is ready to putaway what was received -2. **When preparing to putaway from a reception stage** — stock received in a staging area is evaluated for direct transfer +1. **After receipt into equipment** - operator is ready to putaway what was received +2. **When preparing to putaway from a reception stage** - stock received in a staging area is evaluated for direct transfer ### Conditions and Eligibility @@ -73,7 +73,7 @@ For **cutting stock items** in non-consolidating conversions: ### Concept (Warehouse) -If opportunity crossdocking is not possible (no shipping order needing immediate routing, or the stock quantity exceeds a single order's need), EasyWMS evaluates **crossdocking to warehouse**: the stock is placed in dedicated **crossdocking locations** near the shipping area. When the shipping order is eventually released, these crossdocking locations are consulted first during stock assignment — ensuring minimum travel distance for shipping. +If opportunity crossdocking is not possible (no shipping order needing immediate routing, or the stock quantity exceeds a single order's need), EasyWMS evaluates **crossdocking to warehouse**: the stock is placed in dedicated **crossdocking locations** near the shipping area. When the shipping order is eventually released, these crossdocking locations are consulted first during stock assignment - ensuring minimum travel distance for shipping. The stock is not yet assigned to any shipping order during the crossdocking-to-warehouse placement. The link to the order happens at release time. @@ -94,7 +94,7 @@ For crossdocking to warehouse to execute: ### Process Flow (Warehouse) 1. Operator is about to putaway received container/stock -2. EasyWMS first tries opportunity crossdocking (direct to dock) — if not possible: +2. EasyWMS first tries opportunity crossdocking (direct to dock) - if not possible: 3. EasyWMS evaluates crossdocking to warehouse: a. Identifies candidate shipping orders meeting criteria b. Checks if existing crossdocking locations already have sufficient stock @@ -189,7 +189,7 @@ No special location or strategy configuration required. The system automatically 3. **Putaway strategies**: create and enable at least one strategy with "Is crossdocking" = true, including destination rules targeting the crossdocking locations 4. **Stock assignment**: ensure the stock assignment strategy consults crossdocking locations first when the shipping order is released (these locations are consulted preferentially automatically) -### Mecalux France — EasyS / SmartUI Setup Notes +### Mecalux France - EasyS / SmartUI Setup Notes Additional setup steps consolidated from Mecalux France practice (in addition to the items above) : @@ -203,16 +203,16 @@ Additional setup steps consolidated from Mecalux France practice (in addition to 1. On eligible items, enable **Cross-docking** in the advanced data tab. 2. Create the crossdocking putaway strategy **in sequence position 1** so it runs before the other putaway strategies. -**Criteria tab** : enable crossdocking. ⚠️ Without any additional criterion, **all items** will be treated as crossdocking at reception — always add conditions on the state of the pending outbound orders (e.g. status "En attente") to avoid this. +**Criteria tab** : enable crossdocking. ⚠️ Without any additional criterion, **all items** will be treated as crossdocking at reception - always add conditions on the state of the pending outbound orders (e.g. status "En attente") to avoid this. **Rules tab** : set `Zone` to the crossdocking zone created in EasyS. -### Mecalux France — Known Behavior Notes +### Mecalux France - Known Behavior Notes - **Reception must be done on the RFT** : the reception buffer does not trigger crossdocking evaluation. If reception is performed on the buffer, crossdocking is bypassed silently. -- **Buffer over dock for direct XD** : when the outbound order has an assigned buffer, direct (opportunity) crossdocking routes stock to the *buffer* rather than the dock — useful for a subsequent packing step. +- **Buffer over dock for direct XD** : when the outbound order has an assigned buffer, direct (opportunity) crossdocking routes stock to the *buffer* rather than the dock - useful for a subsequent packing step. - **Crossdocking overrides reserve** : if a crossdocking location exists, the WMS redirects to it even if reserve stock is already available. -- **No label is printed** in standard direct (opportunity) crossdocking, even for a full pallet — plan for a custom label flow if the customer requires one. +- **No label is printed** in standard direct (opportunity) crossdocking, even for a full pallet - plan for a custom label flow if the customer requires one. ## Common Errors @@ -222,7 +222,7 @@ Additional setup steps consolidated from Mecalux France practice (in addition to **Stock placed in crossdocking location but not prioritized at release:** Stock assignment strategy doesn't prioritize crossdocking locations over normal storage. Check the stock assignment strategy configuration to ensure crossdocking location preferences are applied. -**Crossdocking location fills up, remainder goes to standard storage:** This is normal behavior — the crossdocking process places only what fits. The remainder follows standard putaway. No error; just an expected split. +**Crossdocking location fills up, remainder goes to standard storage:** This is normal behavior - the crossdocking process places only what fits. The remainder follows standard putaway. No error; just an expected split. **Shipping order candidate filtered out unexpectedly:** The crossdocking strategy has filters on order status, priority, or days until release/load that exclude the order. Review the "Is crossdocking" strategy's filter settings. @@ -232,18 +232,18 @@ Additional setup steps consolidated from Mecalux France practice (in addition to | Interface | Path | |---|---| -| Web — crossdocking putaway strategies | "Configuration" → "Putaway strategies" (filter by "Is crossdocking") | -| Web — item "Allow crossdocking" | "Inventory" → "Items" → item → settings | -| Web — location storage logic | "Warehouse" → "Locations" → location → "Change storage location logic" | -| RFT — putaway flow (opportunity XD) | Normal putaway flow; system routes to dock/stage automatically | -| RFT — putaway flow (XD to warehouse) | Normal putaway flow; system routes to XD location automatically | +| Web - crossdocking putaway strategies | "Configuration" → "Putaway strategies" (filter by "Is crossdocking") | +| Web - item "Allow crossdocking" | "Inventory" → "Items" → item → settings | +| Web - location storage logic | "Warehouse" → "Locations" → location → "Change storage location logic" | +| RFT - putaway flow (opportunity XD) | Normal putaway flow; system routes to dock/stage automatically | +| RFT - putaway flow (XD to warehouse) | Normal putaway flow; system routes to XD location automatically | ## Related -- [Reception](reception.md) — crossdocking is triggered during the putaway phase following reception -- [Putaway](putaway.md) — crossdocking uses the putaway strategy engine; "Is crossdocking" strategies are a subtype of putaway strategies -- [Shipping](shipping.md) — crossdocking locations feed stock assignment at order release; opportunity crossdocking routes directly to shipping docks -- [Container (LPN)](container.md) — containers are the primary unit being crossdocked; stacked containers and multi-reference containers have specific rules -- [Stock](stock.md) — stock status and logistic attributes affect crossdocking eligibility -- [Inbound Order](order-inbound.md) — ASN containers can carry exclusive reserves for specific outbound orders, enabling crossdocking on receipt -- [Outbound Order](order-outbound.md) — SOR lines with crossdocking-eligible items become crossdocking candidates; order priority drives XD selection +- [Reception](reception.md) - crossdocking is triggered during the putaway phase following reception +- [Putaway](putaway.md) - crossdocking uses the putaway strategy engine; "Is crossdocking" strategies are a subtype of putaway strategies +- [Shipping](shipping.md) - crossdocking locations feed stock assignment at order release; opportunity crossdocking routes directly to shipping docks +- [Container (LPN)](container.md) - containers are the primary unit being crossdocked; stacked containers and multi-reference containers have specific rules +- [Stock](stock.md) - stock status and logistic attributes affect crossdocking eligibility +- [Inbound Order](order-inbound.md) - ASN containers can carry exclusive reserves for specific outbound orders, enabling crossdocking on receipt +- [Outbound Order](order-outbound.md) - SOR lines with crossdocking-eligible items become crossdocking candidates; order priority drives XD selection diff --git a/wiki/concepts/cutting-stock.md b/wiki/concepts/cutting-stock.md index b754c60..de55cb4 100644 --- a/wiki/concepts/cutting-stock.md +++ b/wiki/concepts/cutting-stock.md @@ -34,7 +34,7 @@ last_compiled: "2026-04-10" Cutting stock is a specialization of item management for items that are **measured and cut to order** rather than picked in discrete unit quantities. Examples: rope, electric cable, chain, flexible pipe (hose), fabric rolls, wire. These items exist as continuous rolls or coils and can only be shipped in specific lengths. -Cutting stock is an **exclusively manual warehouse feature** — not supported in automated or semi-automated warehouses. +Cutting stock is an **exclusively manual warehouse feature** - not supported in automated or semi-automated warehouses. By definition: **a cutting item is any item with an assigned cutting profile.** The profile defines how the item behaves: whether it requires a cutting station, how it's labeled, and how its stock consolidation works. @@ -44,11 +44,11 @@ By definition: **a cutting item is any item with an assigned cutting profile.** The defining characteristic of cutting stock is that its **base UoM conversion does NOT consolidate**. This means: -- Multiple stock lines of identical qualities (same item, lot, status, logistic attributes) can coexist in the same location/container as **separate records** — they are never merged. +- Multiple stock lines of identical qualities (same item, lot, status, logistic attributes) can coexist in the same location/container as **separate records** - they are never merged. - Each stretch is an individual record with its own quantity (length). - This enables precise tracking of available stretch lengths. -**Practical implication:** If you have three 30m rolls of the same cable in the same location, you have three separate stock records (30m, 30m, 30m) — not one 90m record. +**Practical implication:** If you have three 30m rolls of the same cable in the same location, you have three separate stock records (30m, 30m, 30m) - not one 90m record. ### Base UoM Rule @@ -150,7 +150,7 @@ Cutting station can be locked via "Stations" view to prevent new stock assignmen - Routes: station ↔ stages, station ↔ equipment, station ↔ warehouse, stages ↔ docks/stages/consolidation - Associated stages: routes to cutting station, other stages of same station, stages of stations cutting same profile, equipment, warehouse, docks/stages/consolidation -**Label recommendations at cutting stations:** Print labels for cutting station code, station location code, receiving stage location code, shipping stage location code — operators confirm these codes continuously during cutting. +**Label recommendations at cutting stations:** Print labels for cutting station code, station location code, receiving stage location code, shipping stage location code - operators confirm these codes continuously during cutting. ## Reception of Cutting Stock @@ -202,7 +202,7 @@ Station (integrated) items can be included in shipping orders, order groups, and **Return to warehouse:** Operator can return stock without pending assignments from station to warehouse at any time. -**Note:** Once a cutting stock line has tasks in "In Process" or "Finished" status, quantity cannot be changed — but line can always be canceled. +**Note:** Once a cutting stock line has tasks in "In Process" or "Finished" status, quantity cannot be changed - but line can always be canceled. ### Delegated Cutting in Station @@ -232,7 +232,7 @@ Because cutting requires tools and cannot be performed everywhere, it is **not p ### Enter Quantity Mode -Cutting stock is indivisible — you cannot pick one unit at a time to confirm total. Therefore: +Cutting stock is indivisible - you cannot pick one unit at a time to confirm total. Therefore: - **"Enter quantity mode" must be set to "Manually"** in the item's shipping profile - The total length is confirmed in one step at the moment of cutting @@ -250,7 +250,7 @@ Counting cutting stock (in non-consolidating conversions) differs from standard 2. **Assign user status during counting:** Set status before entering a stretch; status persists for subsequent stretches until changed or removed. Can be assigned/unassigned to any stretch in the list. -3. **Modify counted lines:** Delete any stretch (not edit quantity — deletion only). "Stretches" action lists all counted stretches. "Empty List" action clears all. Lines with user status are shown in list. +3. **Modify counted lines:** Delete any stretch (not edit quantity - deletion only). "Stretches" action lists all counted stretches. "Empty List" action clears all. Lines with user status are shown in list. **Informed count mode:** For locations where exact roll lengths are unknown. Verifies bulk presence only. Allows comparison and adjustment by operator. @@ -273,8 +273,8 @@ See [[quality-control]] for full details. Cutting stock has specific lock behavi See [[manual-movements]] for full details. Specific cutting stock rules: - Cutting stock moves require **exact stretch length confirmation** -- Moving cutting stock is only allowed as a whole stretch — partial moves of a stretch are not supported (the indivisibility rule) -- If move requires cutting to reduce length, that is not permitted via manual movement — must go through the picking/cutting process +- Moving cutting stock is only allowed as a whole stretch - partial moves of a stretch are not supported (the indivisibility rule) +- If move requires cutting to reduce length, that is not permitted via manual movement - must go through the picking/cutting process ## Crossdocking Interaction @@ -285,7 +285,7 @@ Cutting outside storage locations is not permitted. However, **opportunity cross See [[stock-adjustment]] for full details. Cutting-specific behavior: - Adjustments apply to individual stretch records -- Labels can be printed for cutting stock from the "Location adjustment" RFT process — only if the cutting profile has "Label source stock" active +- Labels can be printed for cutting stock from the "Location adjustment" RFT process - only if the cutting profile has "Label source stock" active - Transactions: STK.ADJ ## Parameters @@ -327,14 +327,14 @@ See [[stock-adjustment]] for full details. Cutting-specific behavior: ## Related -- [[product-item]] — Cutting profile is configured on the item master; base UoM rules apply -- [[reception]] — Cutting stock has specialized receipt processes (blind, supplier) -- [[picking]] — Integrated and delegated cutting processes are extensions of picking -- [[shipping]] — Shipping profile configuration is mandatory for correct excess handling -- [[stock-adjustment]] — Label printing from location adjustment; STK.ADJ transactions -- [[count]] — Counting stretches has unique UI and process rules -- [[quality-control]] — Cutting stock locks (partial/total); STC/STR messages -- [[manual-movements]] — Moving whole stretches; indivisibility enforced -- [[stations]] — Cutting station (type 61) configuration and associated stages -- [[labels]] — Cutting stock label format (A6), print triggers, printer priority -- [[parameters]] — CUTTING_PRINTER parameter +- [[product-item]] - Cutting profile is configured on the item master; base UoM rules apply +- [[reception]] - Cutting stock has specialized receipt processes (blind, supplier) +- [[picking]] - Integrated and delegated cutting processes are extensions of picking +- [[shipping]] - Shipping profile configuration is mandatory for correct excess handling +- [[stock-adjustment]] - Label printing from location adjustment; STK.ADJ transactions +- [[count]] - Counting stretches has unique UI and process rules +- [[quality-control]] - Cutting stock locks (partial/total); STC/STR messages +- [[manual-movements]] - Moving whole stretches; indivisibility enforced +- [[stations]] - Cutting station (type 61) configuration and associated stages +- [[labels]] - Cutting stock label format (A6), print triggers, printer priority +- [[parameters]] - CUTTING_PRINTER parameter diff --git a/wiki/concepts/defragmentation.md b/wiki/concepts/defragmentation.md index 822345d..8503019 100644 --- a/wiki/concepts/defragmentation.md +++ b/wiki/concepts/defragmentation.md @@ -62,7 +62,7 @@ For each rotation strategy, destination rules specify where to move candidate co |---|---| | Same aisle | Move within the same aisle; skip if no valid location in aisle | | Specific aisle | Move to a designated automatic aisle; skip if no valid location | -| Storage zones | One or more target zones (mandatory — at least one required) | +| Storage zones | One or more target zones (mandatory - at least one required) | | Priority | Task priority for defragmentation tasks of this ABC+zone combination | **Location search uses putaway strategies** in configured sequence order. @@ -78,7 +78,7 @@ For each rotation strategy, destination rules specify where to move candidate co Shipping strategies pre-position containers assigned to upcoming orders near the warehouse exit, speeding up the shipping preparation process. -### Strategy Criteria — Shipping (Order / Container Selection) +### Strategy Criteria - Shipping (Order / Container Selection) | Criterion | Description | |---|---| @@ -93,7 +93,7 @@ Shipping strategies pre-position containers assigned to upcoming orders near the > If orders don't have all stock assigned yet, the stock assignment process runs first. -### Strategy Rules — Shipping (Destination Selection) +### Strategy Rules - Shipping (Destination Selection) | Rule | Description | |---|---| @@ -193,9 +193,9 @@ Planners enable **unattended, scheduled** defragmentation. Both rotation and shi ## Related -- [[location]] — Defragmentation moves containers between locations; rotation strategies use storage zones; only automatic aisles are valid -- [[container]] — Containers are the unit of movement; ABC classification, type, and references-per-container govern candidate selection -- [[stock]] — Stock records follow container movements; STK.MOVE and CON.MOVE transactions generated -- [[task]] — Defragmentation generates movement tasks executed during inactivity; `MAX_DEFRAG_TASKS` limits concurrency -- [[order-outbound]] — Shipping defragmentation is triggered by outbound orders; status must be Creating/Waiting/Released -- [[putaway]] — Rotation defragmentation uses putaway strategies to find destination locations +- [[location]] - Defragmentation moves containers between locations; rotation strategies use storage zones; only automatic aisles are valid +- [[container]] - Containers are the unit of movement; ABC classification, type, and references-per-container govern candidate selection +- [[stock]] - Stock records follow container movements; STK.MOVE and CON.MOVE transactions generated +- [[task]] - Defragmentation generates movement tasks executed during inactivity; `MAX_DEFRAG_TASKS` limits concurrency +- [[order-outbound]] - Shipping defragmentation is triggered by outbound orders; status must be Creating/Waiting/Released +- [[putaway]] - Rotation defragmentation uses putaway strategies to find destination locations diff --git a/wiki/concepts/erp-interface.md b/wiki/concepts/erp-interface.md index 8dac3a2..c348b4d 100644 --- a/wiki/concepts/erp-interface.md +++ b/wiki/concepts/erp-interface.md @@ -82,7 +82,7 @@ All messages have a **version** suffix when multiple variants exist (e.g., ROR01 | KIT | Kit | ERP → WMS | Create/update kit definitions | | LCK | Lock Type | ERP → WMS | Lock type master data | -#### ITM — Image fields +#### ITM - Image fields The `ITM01` message can optionally convey the article's picture. Two modes: @@ -91,13 +91,13 @@ The `ITM01` message can optionally convey the article's picture. Two modes: | **Local file** | `nom-fichier.jpg` | File resolved against the folder pointed to by `UserImagesURI` in the WMS `appsettings.json`. Typical value : `C:/MLX/Data/Pictures/`. | | **URL** | `https://…/photo.jpg` | Fetched by the WMS when the client uses the display; `ItmPicture` takes precedence if both are present. | -> Requires read access on the `UserImagesURI` share from the WMS service account. The image is not uploaded via the ITM file — only the filename / URL is stamped on the item record. +> Requires read access on the `UserImagesURI` share from the WMS service account. The image is not uploaded via the ITM file - only the filename / URL is stamped on the item record. --- ### Inbound / Receipt Messages -#### ROR — Receipt Order (ERP → WMS) +#### ROR - Receipt Order (ERP → WMS) The primary message for creating inbound orders. @@ -124,11 +124,11 @@ The primary message for creating inbound orders. - Order code must be unique for new orders - Lines support optional `transactional` group to control failure behavior - Can create/modify/cancel lines individually after creation -- Triggers [ROC](#roc--receipt-order-status-change-wms--erp) status change notifications +- Triggers [ROC](#roc---receipt-order-status-change-wms--erp) status change notifications --- -#### ASN — Advanced Shipping Notice (ERP → WMS) +#### ASN - Advanced Shipping Notice (ERP → WMS) Pre-notifies WMS of containers en route to the warehouse. @@ -151,12 +151,12 @@ Pre-notifies WMS of containers en route to the warehouse. **Notes:** - Creates pending stock at ASN virtual location -- If container is received: triggers [ASO](#aso--advanced-shipping-notice-ok-wms--erp) response -- If container is rejected or deleted: triggers [ASK](#ask--advanced-shipping-notice-ko-wms--erp) response +- If container is received: triggers [ASO](#aso---advanced-shipping-notice-ok-wms--erp) response +- If container is rejected or deleted: triggers [ASK](#ask---advanced-shipping-notice-ko-wms--erp) response --- -#### SRN — Stock Replenish Notice (ERP → WMS) +#### SRN - Stock Replenish Notice (ERP → WMS) Pre-notifies WMS of loose stock for automatic warehouse replenishment. @@ -178,7 +178,7 @@ Pre-notifies WMS of loose stock for automatic warehouse replenishment. --- -#### ROC — Receipt Order Status Change (WMS → ERP) +#### ROC - Receipt Order Status Change (WMS → ERP) Notifies ERP of receipt order status transitions. @@ -195,13 +195,13 @@ Notifies ERP of receipt order status transitions. --- -#### ROF — Receipt Order Finalization (WMS → ERP) +#### ROF - Receipt Order Finalization (WMS → ERP) Notifies ERP that a receipt order has been closed or canceled, with received quantities. **Versions:** - `ROF01`: Standard finalization -- `ROF02`: Extended with detailed line-level quantities — **the version generated when closing an inbound order sourced from a `Transfer` shipping order** (two-warehouse flow). For standard supplier receipts, ROF01 is emitted. +- `ROF02`: Extended with detailed line-level quantities - **the version generated when closing an inbound order sourced from a `Transfer` shipping order** (two-warehouse flow). For standard supplier receipts, ROF01 is emitted. **Key fields:** | Field | Description | @@ -219,7 +219,7 @@ Notifies ERP that a receipt order has been closed or canceled, with received qua --- -#### REF — Receipt Finalization (WMS → ERP) +#### REF - Receipt Finalization (WMS → ERP) Notifies ERP that a **receipt** (physical receiving event) has been closed. @@ -247,7 +247,7 @@ Notifies ERP that a **receipt** (physical receiving event) has been closed. --- -#### ASO — Advanced Shipping Notice OK (WMS → ERP) +#### ASO - Advanced Shipping Notice OK (WMS → ERP) Confirms that a pre-notified container has been successfully received. @@ -262,11 +262,11 @@ Confirms that a pre-notified container has been successfully received. | ReceiptCode | Receipt document | | ReceivedDate | Reception timestamp | -> **DirectTransfer trigger** — when the expedition of a `` shipping order is closed at the origin warehouse, EasyWMS automatically generates an `ASO01` message targeting the destination warehouse, creating the incoming ASN container(s). The ASO carries the container and its stock but **no reference to the originating `SorCode` / DirectTransfer header**. See [concepts/order-outbound.md](order-outbound.md#asn--directtransfer-flow). +> **DirectTransfer trigger** - when the expedition of a `` shipping order is closed at the origin warehouse, EasyWMS automatically generates an `ASO01` message targeting the destination warehouse, creating the incoming ASN container(s). The ASO carries the container and its stock but **no reference to the originating `SorCode` / DirectTransfer header**. See [concepts/order-outbound.md](order-outbound.md#asn---directtransfer-flow). --- -#### ASK — Advanced Shipping Notice KO (WMS → ERP) +#### ASK - Advanced Shipping Notice KO (WMS → ERP) Notifies ERP that a pre-notified container has been rejected or deleted. @@ -280,11 +280,11 @@ Notifies ERP that a pre-notified container has been rejected or deleted. **Triggered by:** `CON.CNL.ASN` transaction -> **DirectTransfer trigger** — deleting an ASN container of a DirectTransfer flow from SmartUI (`Entrepôt → Conteneurs ASN → Supprimer`) generates an `ASK01` to the ERP. As with the ASO, the message contains no reference to the upstream shipping order. +> **DirectTransfer trigger** - deleting an ASN container of a DirectTransfer flow from SmartUI (`Entrepôt → Conteneurs ASN → Supprimer`) generates an `ASK01` to the ERP. As with the ASO, the message contains no reference to the upstream shipping order. --- -#### SRO — Stock Replenish OK (WMS → ERP) +#### SRO - Stock Replenish OK (WMS → ERP) Confirms that pre-notified loose stock has been used for automatic warehouse replenishment. @@ -292,7 +292,7 @@ Confirms that pre-notified loose stock has been used for automatic warehouse rep --- -#### SRK — Stock Replenish KO (WMS → ERP) +#### SRK - Stock Replenish KO (WMS → ERP) Notifies that pre-notified loose stock has been canceled (not used for replenishment). @@ -302,7 +302,7 @@ Notifies that pre-notified loose stock has been canceled (not used for replenish ### Outbound / Shipping Messages -#### SOR — Shipping Order (ERP → WMS) +#### SOR - Shipping Order (ERP → WMS) The primary message for creating outbound orders. @@ -341,13 +341,13 @@ The primary message for creating outbound orders. | SOR02: PrpContTypeRequired | Required client container type | | SOR02: VASCode | VAS template | -**`SorType = DirectTransfer`** — inter-warehouse transfer; closing the expedition at origin emits an automatic `ASO01` on destination, pre-creating the ASN container (see [ASO](#aso--advanced-shipping-notice-ok-wms--erp) and [concepts/order-outbound.md](order-outbound.md#asn--directtransfer-flow)). +**`SorType = DirectTransfer`** - inter-warehouse transfer; closing the expedition at origin emits an automatic `ASO01` on destination, pre-creating the ASN container (see [ASO](#aso---advanced-shipping-notice-ok-wms--erp) and [concepts/order-outbound.md](order-outbound.md#asn---directtransfer-flow)). -**`SorType = Transfer`** — inter-warehouse transfer variant where destination generates **a full inbound order** on expedition close (as opposed to DirectTransfer which only pre-notifies via ASN). The destination ROR carries the source SOR reference ; on close, destination emits a `ROF02` carrying the line-level quantities, which the origin warehouse uses to reconcile. See [concepts/order-outbound.md](order-outbound.md#transfer-two-warehouse-flow). +**`SorType = Transfer`** - inter-warehouse transfer variant where destination generates **a full inbound order** on expedition close (as opposed to DirectTransfer which only pre-notifies via ASN). The destination ROR carries the source SOR reference ; on close, destination emits a `ROF02` carrying the line-level quantities, which the origin warehouse uses to reconcile. See [concepts/order-outbound.md](order-outbound.md#transfer---two-warehouse-flow-inbound-order-created). --- -#### SOC — Shipping Order Status Change (WMS → ERP) +#### SOC - Shipping Order Status Change (WMS → ERP) Notifies ERP of shipping order status transitions. @@ -357,7 +357,7 @@ Notifies ERP of shipping order status transitions. --- -#### SOF — Shipping Order Finalization (WMS → ERP) +#### SOF - Shipping Order Finalization (WMS → ERP) Notifies ERP that a shipping order has been closed or canceled with shipped quantities. @@ -379,11 +379,11 @@ Notifies ERP that a shipping order has been closed or canceled with shipped quan --- -#### DlvShareDeliveries — Merge outbound orders (ERP → WMS) +#### DlvShareDeliveries - Merge outbound orders (ERP → WMS) XML message used by the **Multi-Carrier / Deliveries module** to request that two or more outbound orders be prepared together (merged). A merged group shares client containers, carrier call, and closure. -**Eligibility** — all orders in the request must match on: +**Eligibility** - all orders in the request must match on: - Same account - Same site (warehouse) @@ -397,13 +397,13 @@ When `ALLOW_MERGE_DIFFERENT_ACCOUNT = true` is set, the "same account" rule is r - Stock assignment is executed across the merged scope (not per-order) - Client containers can carry lines from any order in the group - Order closure is triggered when the last line of the last order in the group is picked / when the carrier call returns -- SOF is still emitted per source SOR — only preparation is shared +- SOF is still emitted per source SOR - only preparation is shared See [concepts/order-outbound.md](order-outbound.md#merge-order-fusion) for operator flows and limitations. --- -#### LOF — Load Finalization (WMS → ERP) +#### LOF - Load Finalization (WMS → ERP) Notifies ERP that a truck load has been closed (truck loaded and sealed). @@ -421,7 +421,7 @@ Notifies ERP that a truck load has been closed (truck loaded and sealed). --- -#### WOR — Work Order (ERP → WMS) +#### WOR - Work Order (ERP → WMS) Creates kit assembly or other work orders. @@ -429,7 +429,7 @@ Creates kit assembly or other work orders. --- -#### WOF — Work Order Finalization (WMS → ERP) +#### WOF - Work Order Finalization (WMS → ERP) Notifies ERP that a work order (kit assembly, etc.) has been closed or canceled. @@ -437,7 +437,7 @@ Notifies ERP that a work order (kit assembly, etc.) has been closed or canceled. --- -#### RUT — Route (ERP → WMS) +#### RUT - Route (ERP → WMS) Creates or updates carrier routes. @@ -453,7 +453,7 @@ Creates or updates carrier routes. ### Count Messages -#### COR — Count Order Request (ERP → WMS) +#### COR - Count Order Request (ERP → WMS) Requests WMS to create a physical count. @@ -476,7 +476,7 @@ Requests WMS to create a physical count. --- -#### COF — Count Order Finalization (WMS → ERP) +#### COF - Count Order Finalization (WMS → ERP) Reports count results when a WMS-received count (from COR) is closed or canceled. @@ -501,7 +501,7 @@ Reports count results when a WMS-received count (from COR) is closed or canceled ### Request Messages -#### STR — Stock Status Change Request (ERP → WMS) +#### STR - Stock Status Change Request (ERP → WMS) Requests WMS to apply or remove a quality lock on stock. @@ -523,15 +523,15 @@ Requests WMS to apply or remove a quality lock on stock. | OwnerCode | Owner | | FltAttLot | Lot filter | | StaCode | Status code to apply | -| StaUsrEnd | Lock expiry (UTC) — optional | +| StaUsrEnd | Lock expiry (UTC) - optional | | StaUsrEmpty | Status to remove (for unlock) | | StaRecEmpty | Reception status to remove | -**Response:** [STC](#stc--stock-status-change-wms--erp) message per affected stock line +**Response:** [STC](#stc---stock-status-change-wms--erp) message per affected stock line --- -#### SCR — Stock Count Request (ERP → WMS) +#### SCR - Stock Count Request (ERP → WMS) Requests WMS to report current stock for an item or lot. @@ -544,11 +544,11 @@ Requests WMS to report current stock for an item or lot. | OwnerCode | Owner | | LotCode | Lot (optional) | -**Response:** [WSC](#wsc--warehouse-stock-count-wms--erp) message +**Response:** [WSC](#wsc---warehouse-stock-count-wms--erp) message --- -#### CMC — Container Movement Confirmation (ERP → WMS) +#### CMC - Container Movement Confirmation (ERP → WMS) Notifies WMS of a container's destination after removal from outbound conveyor, when movements are managed by an external system. @@ -563,7 +563,7 @@ Notifies WMS of a container's destination after removal from outbound conveyor, ### Notification Messages (WMS → ERP) -#### STV — Stock Variation (WMS → ERP) +#### STV - Stock Variation (WMS → ERP) Reports any stock quantity change (increase, decrease, creation, deletion, UoM change, logistic attribute change). @@ -588,7 +588,7 @@ Reports any stock quantity change (increase, decrease, creation, deletion, UoM c --- -#### STC — Stock Status Change (WMS → ERP) +#### STC - Stock Status Change (WMS → ERP) Reports every stock quality status change (lock or unlock). @@ -611,7 +611,7 @@ Reports every stock quality status change (lock or unlock). --- -#### WSC — Warehouse Stock Count (WMS → ERP) +#### WSC - Warehouse Stock Count (WMS → ERP) Response to SCR stock contrast request. Reports current stock quantities. @@ -630,7 +630,7 @@ Response to SCR stock contrast request. Reports current stock quantities. --- -#### KST — Kit Assembled (WMS → ERP) +#### KST - Kit Assembled (WMS → ERP) Notifies ERP that kit stock has been assembled. @@ -649,7 +649,7 @@ Notifies ERP that kit stock has been assembled. --- -#### UNK — Kit Disassembled (WMS → ERP) +#### UNK - Kit Disassembled (WMS → ERP) Notifies ERP that kit stock has been disassembled. @@ -657,7 +657,7 @@ Notifies ERP that kit stock has been disassembled. --- -#### COS — Container Shipped to PS (WMS → ERP) +#### COS - Container Shipped to PS (WMS → ERP) Notifies ERP that a client container has been sent to the outbound conveyor (PS/Sortation). @@ -675,7 +675,7 @@ Notifies ERP that a client container has been sent to the outbound conveyor (PS/ --- -#### COC — Container Closed in MP (WMS → ERP) +#### COC - Container Closed in MP (WMS → ERP) Notifies ERP that a client container has been closed in a Preparation Zone (MP). @@ -685,7 +685,7 @@ Notifies ERP that a client container has been closed in a Preparation Zone (MP). --- -#### ERR — Error (WMS → ERP) +#### ERR - Error (WMS → ERP) Sent when WMS cannot process an incoming ERP message. Contains the original message reference and error description. @@ -714,7 +714,7 @@ ERP Response Queue ──→ ERP ### Transaction Post-processing -Many WMS transactions are marked **"Post-processed: yes"** — meaning after the internal transaction is written, a background post-processor generates the corresponding ERP message: +Many WMS transactions are marked **"Post-processed: yes"** - meaning after the internal transaction is written, a background post-processor generates the corresponding ERP message: | Transaction | Generated Message | |------------|-----------------| @@ -756,7 +756,7 @@ Beyond the core catalog, optional modules add their own ERP messages: | Kits | UNK | WMS → ERP | Kit manually disassembled (manual work orders) | | Store Fulfillment | TOR01 | ERP → WMS | Transfer order between stores/sub-warehouses | | Store Fulfillment | TOF01 | WMS → ERP | Transfer order finalized | -| Store Fulfillment | TPV01 | ERP → WMS | POS sale notification — decrements store stock | +| Store Fulfillment | TPV01 | ERP → WMS | POS sale notification - decrements store stock | | VAS | VAS01 | ERP → WMS | Create/update VAS templates, activities, and instructions | | VAS | SOR02 VASCode | ERP → WMS | VAS template reference per line in shipping order | | VAS | SOF (VAS field) | WMS → ERP | VAS model used + quantity returned per shipped line | @@ -784,13 +784,13 @@ Beyond the core catalog, optional modules add their own ERP messages: ## Related -- [Inbound Order](order-inbound.md) — Receipt order lifecycle and ROR/ROC/ROF details -- [Outbound Order](order-outbound.md) — Shipping order lifecycle and SOR/SOC/SOF details -- [Quality Control](quality-control.md) — Stock lock/unlock and STR/STC messages -- [Count](count.md) — Physical counts and COR/COF messages -- [Stock](stock.md) — Stock adjustments and STV messages -- [Transactions](transactions.md) — Internal transactions that trigger ERP messages -- [Entities Map](../architecture/entities-map.md) — ERP integration touch points per entity -- [Replenishment](replenishment.md) — Automatic warehouse replenishment and SRN/SRO/SRK -- [Manufacturing](../modules/manufacturing.md) — MOF/FGP production messages -- [DOM](../modules/dom.md) — Distributed order management messages +- [Inbound Order](order-inbound.md) - Receipt order lifecycle and ROR/ROC/ROF details +- [Outbound Order](order-outbound.md) - Shipping order lifecycle and SOR/SOC/SOF details +- [Quality Control](quality-control.md) - Stock lock/unlock and STR/STC messages +- [Count](count.md) - Physical counts and COR/COF messages +- [Stock](stock.md) - Stock adjustments and STV messages +- [Transactions](transactions.md) - Internal transactions that trigger ERP messages +- [Entities Map](../architecture/entities-map.md) - ERP integration touch points per entity +- [Replenishment](replenishment.md) - Automatic warehouse replenishment and SRN/SRO/SRK +- [Manufacturing](../modules/manufacturing.md) - MOF/FGP production messages +- [DOM](../modules/dom.md) - Distributed order management messages diff --git a/wiki/concepts/kits.md b/wiki/concepts/kits.md index 15a5e91..9eb1969 100644 --- a/wiki/concepts/kits.md +++ b/wiki/concepts/kits.md @@ -27,12 +27,12 @@ A **kit** is an article resulting from the assembly of several component article ERP integration sends kit definitions via the **KIT** message. Individual components must already exist as items in the WMS. A kit record consists of: -- **Kit code** — the item code of the assembled article -- **Component 1..N** — each component's item code + required quantity +- **Kit code** - the item code of the assembled article +- **Component 1..N** - each component's item code + required quantity Kits can be configured with or without physical assembly. -> ⚠️ **Profile requirement** — an article can only be configured as a kit if its logistic profile carries the **`Version`** logistic attribute. Otherwise the activation fails with a profile-mismatch error and the item must be reassigned to a profile that has `Version` and a reception control method. +> ⚠️ **Profile requirement** - an article can only be configured as a kit if its logistic profile carries the **`Version`** logistic attribute. Otherwise the activation fails with a profile-mismatch error and the item must be reassigned to a profile that has `Version` and a reception control method. ## Creating a kit article (SmartUI) @@ -52,7 +52,7 @@ Add components with **"Ajouter composant"** : item, quantity, main component. ### 1. Kit without assembly (no mounting) -The kit article has **assembled = NO**. When a shipping order requests a kit, the WMS splits picking into separate tasks — one per component — without any physical assembly step. The kit is "assembled" implicitly by delivering all components. +The kit article has **assembled = NO**. When a shipping order requests a kit, the WMS splits picking into separate tasks - one per component - without any physical assembly step. The kit is "assembled" implicitly by delivering all components. **Example**: A "Garden Set" kit containing 1 table + 4 chairs: picking generates two tasks (table pick, chairs pick). The final delivery is the two components together. @@ -60,11 +60,11 @@ The kit article has **assembled = NO**. When a shipping order requests a kit, th The kit article has **assembled = YES**. A physical work order is required: components are picked and brought to an assembly zone, the kit is built, and the resulting kit item is added to stock. -**Sub-type — on-demand assembly** (`assembled = YES`, `assembly_on_demand = YES`): the assembly can be triggered by a shipping order when kit stock is zero, without a pre-existing work order. Used when the ERP can create work orders autonomously. +**Sub-type - on-demand assembly** (`assembled = YES`, `assembly_on_demand = YES`): the assembly can be triggered by a shipping order when kit stock is zero, without a pre-existing work order. Used when the ERP can create work orders autonomously. -**Sub-type — ERP-driven assembly** (`assembled = YES`, `assembly_on_demand = NO`): the assembly is only triggered by a Work Order (WOR) from the ERP or a manually created order. No automatic kit fabrication request is generated when stock is insufficient. +**Sub-type - ERP-driven assembly** (`assembled = YES`, `assembly_on_demand = NO`): the assembly is only triggered by a Work Order (WOR) from the ERP or a manually created order. No automatic kit fabrication request is generated when stock is insufficient. -### SAGE 100C Connector — Nomenclature types +### SAGE 100C Connector - Nomenclature types When integrated with SAGE 100C, EasyWMS maps SAGE nomenclature types to kit configurations: @@ -97,7 +97,7 @@ ERP sends WOR → WMS creates work order 3. All components arrive at the assembly zone 4. Operator scans and confirms assembly on TRF 5. Component stock automatically decremented; kit stock created -6. Kit returned to storage — available for shipping orders +6. Kit returned to storage - available for shipping orders 7. `WOF` sent to ERP at work order close or cancellation (only if originated from ERP) 8. If work order was created manually: `KST` sent to ERP to notify consumed and created stock @@ -119,22 +119,22 @@ ERP sends WOR (disassembly) → WMS creates work order 2. WMS generates picking tasks for kit items to assembly zone 3. Operator disassembles kits at the zone 4. Kit stock decremented; each component's stock incremented -5. Components returned to storage — available for picking +5. Components returned to storage - available for picking 6. `WOF` sent to ERP at close/cancellation (only if ERP-originated) 7. If manual: `UNK` sent to ERP to notify consumed (kits) and created (components) stock --- -## Work Order Lifecycle — Creation, Modification, Cancellation +## Work Order Lifecycle - Creation, Modification, Cancellation ### Creation modes | Mode | Description | |---|---| -| **From ERP** | `WOR` file — Work Order created with status **En attente** ; `WOF` sent at close/cancel | -| **Manual (SmartUI)** | Menu `Ordres de travail → Ordres de travail` — `KST` sent at close | -| **Manual (RFT)** | Menu `Kits → Demande de composants` — WO created **and released automatically**. ⚠️ **No ERP feedback** — neither `KST` nor `WOF` is generated | -| **Automatic** | Requires `Montage sur demande = OUI` — triggered at integration of an outbound order containing a kit shortage | +| **From ERP** | `WOR` file - Work Order created with status **En attente** ; `WOF` sent at close/cancel | +| **Manual (SmartUI)** | Menu `Ordres de travail → Ordres de travail` - `KST` sent at close | +| **Manual (RFT)** | Menu `Kits → Demande de composants` - WO created **and released automatically**. ⚠️ **No ERP feedback** - neither `KST` nor `WOF` is generated | +| **Automatic** | Requires `Montage sur demande = OUI` - triggered at integration of an outbound order containing a kit shortage | ### Modifications allowed, by status @@ -151,8 +151,8 @@ When a WO is released, the WMS checks available stock in the kit zone. If insuff ## Closing a Work Order -- **Automatic** — once every requested kit has been assembled / disassembled. -- **Manual** — allowed at any time as long as **at least one** kit has been processed. +- **Automatic** - once every requested kit has been assembled / disassembled. +- **Manual** - allowed at any time as long as **at least one** kit has been processed. - On close : `WOF` is sent to the ERP (for ERP-originated and SmartUI-manual WOs ; not for RFT-manual). ## Kit Shortage Handling @@ -171,8 +171,8 @@ When a WO is released, the WMS checks available stock in the kit zone. If insuff - Multiple components per kit; each component has item code + required quantity - Stock consumed at assembly is tracked per lot/batch for traceability purposes - Kit articles can have their own logistic profiles (reception, shipping, putaway) like any item -- **No automatic re-order**: WMS never requests fabrication when kit stock is insufficient — this is always a manual or ERP-driven action -- Component stock shortage at kit assembly time does not block the work order — operator must resolve +- **No automatic re-order**: WMS never requests fabrication when kit stock is insufficient - this is always a manual or ERP-driven action +- Component stock shortage at kit assembly time does not block the work order - operator must resolve - For kits with `assembled = YES`, a work order (WOR) is mandatory before assembly can begin in the WMS --- @@ -222,8 +222,8 @@ When a WO is released, the WMS checks available stock in the kit zone. If insuff ## Related -- [[product-item]] — Kit articles and components are both standard items with logistic profiles -- [[stock]] — Component stock is consumed; kit stock is created at assembly -- [[order-outbound]] — Outbound orders trigger component picks (no assembly) or reference assembled kit stock -- [[erp-interface]] — KIT, WOR, WOF, KST, UNK are the ERP messages for kit management -- [[manufacturing]] — Similar concept but for raw material → finished goods transformation; manufacturing module handles additives, production stations, and automated consumption +- [[product-item]] - Kit articles and components are both standard items with logistic profiles +- [[stock]] - Component stock is consumed; kit stock is created at assembly +- [[order-outbound]] - Outbound orders trigger component picks (no assembly) or reference assembled kit stock +- [[erp-interface]] - KIT, WOR, WOF, KST, UNK are the ERP messages for kit management +- [[manufacturing]] - Similar concept but for raw material → finished goods transformation; manufacturing module handles additives, production stations, and automated consumption diff --git a/wiki/concepts/labels.md b/wiki/concepts/labels.md index 033ae82..a36e30d 100644 --- a/wiki/concepts/labels.md +++ b/wiki/concepts/labels.md @@ -49,7 +49,7 @@ Three GS1-128 container label types: 1. **SSCC label** (standard container label): Contains container code and is used for generic container identification. Barcode encodes the SSCC. -2. **GS1-128 mono-reference label** (for single-item containers): Dual barcode — upper for item, lower for container. Used when container has stock of only one item. +2. **GS1-128 mono-reference label** (for single-item containers): Dual barcode - upper for item, lower for container. Used when container has stock of only one item. 3. **GS1-128 multi-reference label** (for multi-item containers or serialized items): For containers with multiple item stock lines or serial-number-controlled items. @@ -57,8 +57,8 @@ Three GS1-128 container label types: | AI | Content | Structure | |----|---------|-----------| -| **00** | SSCC (container serial code) | n18 — always present | -| **02** | Item alias (GTIN) | n14 — always present | +| **00** | SSCC (container serial code) | n18 - always present | +| **02** | Item alias (GTIN) | n14 - always present | | 10 | Lot number | an..20 | | 11 | Manufacturing date | n6 | | 15 | Best-before date | n6 | @@ -73,8 +73,8 @@ Lot (AI 10), if present, always appears in the lower barcode next to the SSCC. |--------|-----|------| | Generate from Easy WMS UI | Planner/admin | Pre-reception (select number of containers + copies per container) | | Generate from RF terminal | Operator | Pre-reception (select format, count, printer) | -| Print GS1-128 in supplier receipt | Operator (RF) | During supplier receiving — for non-existing containers | -| Print GS1-128 in blind receipt | Operator (RF) | During blind receiving — must be enabled by parameter | +| Print GS1-128 in supplier receipt | Operator (RF) | During supplier receiving - for non-existing containers | +| Print GS1-128 in blind receipt | Operator (RF) | During blind receiving - must be enabled by parameter | **Special case for supplier receipt:** If the receipt was created from a receipt order that specified the container code (ROR message), the label prints with that ROR-specified code. The container GTIN in the ROR must follow GS1-128 spec (14 digits). @@ -110,13 +110,13 @@ Labels for individual stock items. Two formats: Code 128 and GS1-128. **GS1-128 item labels:** - Can be printed from receipt lines (pending/partially received) or from the Stock view (post-reception) - Number of labels entered by user -- Format: A6 horizontal (148 × 105 mm) — label printer +- Format: A6 horizontal (148 × 105 mm) - label printer **GS1-128 Item Application Identifiers (AI):** | AI | Content | Structure | |----|---------|-----------| -| **01** | GTIN (item code) | n14 — always present | +| **01** | GTIN (item code) | n14 - always present | | 10 | Lot number | an..20 | | 11 | Manufacturing date | n6 | | 15 | Best-before date | n6 | @@ -157,9 +157,9 @@ Specialized label for cutting stock in non-consolidating UoM conversions. Used t **When labels are generated:** A cutting stock label is only printed for stock in non-consolidating UoM. Three triggers: -1. **During picking/cutting process** — if cutting profile has "Label cutting stock" or "Label source stock" flag active -2. **From Stock view (PC)** — "Print cutting label" action on a stock record (non-consolidating UoM) -3. **From RF Location adjustment (Utilities menu)** — only if cutting profile has "Label source stock" active +1. **During picking/cutting process** - if cutting profile has "Label cutting stock" or "Label source stock" flag active +2. **From Stock view (PC)** - "Print cutting label" action on a stock record (non-consolidating UoM) +3. **From RF Location adjustment (Utilities menu)** - only if cutting profile has "Label source stock" active **Printer priority order (highest to lowest):** 1. Printer associated with the cutting station (for cutting station stock) @@ -202,7 +202,7 @@ An alternative to standard receiving processes that allows reading all barcode d | Mono-reference containers | Single-item containers | | Identical mono-reference containers | Batch of identical single-item containers | -**Process:** System reads all labels on the item/container until user presses "Done" or max reads is reached. If any data is unreadable, system asks for manual entry (except container code in mono-reference flows — requested at end if not read). Operator can press "Skip" at start to fall back to manual reception. +**Process:** System reads all labels on the item/container until user presses "Done" or max reads is reached. If any data is unreadable, system asks for manual entry (except container code in mono-reference flows - requested at end if not read). Operator can press "Skip" at start to fall back to manual reception. During multi-reading: type and height of container can be selected; stock statuses can be entered. @@ -262,7 +262,7 @@ This section consolidates **every known trigger** for each document/label, inclu |---|---| | Menu **Entrepôt → Support** → select → *Imprimer étiquette* | Manual | | Menu **Entrepôt → Stock** → select line → *Imprimer étiquettes de support* | Manual | -| ROR01 tag `` (boolean) | Auto — mono-reference container uses `DEFAUT_RECEPTION_LABEL_CONTAINER_REPORT_NAME` with `NUM_COPIES_RECEPTION_LABEL` copies; multi-reference uses `DEFAULT_RECEPTION_LABEL_MULTIREFERENCE_CONTAINER_REPORT_NAME` | +| ROR01 tag `` (boolean) | Auto - mono-reference container uses `DEFAUT_RECEPTION_LABEL_CONTAINER_REPORT_NAME` with `NUM_COPIES_RECEPTION_LABEL` copies; multi-reference uses `DEFAULT_RECEPTION_LABEL_MULTIREFERENCE_CONTAINER_REPORT_NAME` | ### Client container label (shipping) @@ -271,9 +271,9 @@ This section consolidates **every known trigger** for each document/label, inclu | SOR01 tag `` | Auto-print at buffer/dock drop | | SmartUI **"Document printings"** on the buffer/POUMON → *Impression automatique de l'étiquette du support du client* | Auto (requires printer assigned) | | Menu **Entrepôt → Supports** → select a client container → *Imprimer étiquettes clients* | Manual | -| Report selected by parameter `CLIENT_CONTAINER_LABEL_REPORT` | — | +| Report selected by parameter `CLIENT_CONTAINER_LABEL_REPORT` | - | -### Packing list — per container ("Liste de conditionnement par support") +### Packing list - per container ("Liste de conditionnement par support") | Trigger | Notes | |---|---| @@ -281,9 +281,9 @@ This section consolidates **every known trigger** for each document/label, inclu | Menu **Sorties → Ordres de sortie** → select order → *Imprimer rapport → Liste de conditionnement (par support)* | Manual | | Menu **Entrepôt → Supports** → select → *Imprimer la liste de colisage* | Manual | | SOR02 tag `` (boolean, Multi-Carrier module only) | Auto | -| Report selected by parameter `CLIENT_CONTAINER_PACKING_REPORT` | — | +| Report selected by parameter `CLIENT_CONTAINER_PACKING_REPORT` | - | -### Packing list — per item ("Liste de conditionnement par article") +### Packing list - per item ("Liste de conditionnement par article") | Trigger | Notes | |---|---| @@ -294,7 +294,7 @@ This section consolidates **every known trigger** for each document/label, inclu | Trigger | Notes | |---|---| -| ROR01 tag `` (boolean) | Auto — report name from `DEFAULT_RECEPTION_LABEL_ITEM_REPORT_NAME` | +| ROR01 tag `` (boolean) | Auto - report name from `DEFAULT_RECEPTION_LABEL_ITEM_REPORT_NAME` | | Menu **Données principales → Articles** → select → *Imprimer étiquette* | Manual | ### Delivery note ("BL") @@ -379,9 +379,9 @@ All label-related parameters consolidated: ## Related -- [[container]] — Container types, LPN management, SSCC codes -- [[product-item]] — Item master, GTIN aliases, logistic attributes shown on labels -- [[reception]] — All label printing at reception time; ROR message enables item labels -- [[cutting-stock]] — Cutting stock label specifics: A6 format, source/cut flags, printer priority -- [[stations]] — ETQ (type 58) labeller station, dock/stage printer configuration -- [[parameters]] — All label parameters listed above +- [[container]] - Container types, LPN management, SSCC codes +- [[product-item]] - Item master, GTIN aliases, logistic attributes shown on labels +- [[reception]] - All label printing at reception time; ROR message enables item labels +- [[cutting-stock]] - Cutting stock label specifics: A6 format, source/cut flags, printer priority +- [[stations]] - ETQ (type 58) labeller station, dock/stage printer configuration +- [[parameters]] - All label parameters listed above diff --git a/wiki/concepts/location.md b/wiki/concepts/location.md index 0d52fdd..fc45a3a 100644 --- a/wiki/concepts/location.md +++ b/wiki/concepts/location.md @@ -30,7 +30,7 @@ last_compiled: "2026-04-17" A location is any physical or virtual space capable of storing loose stock and/or containers within the warehouse. Locations are the fundamental spatial unit of Easy WMS: every piece of stock must have a location, every container must be placed in a location, and every movement task has a source and destination location. -Locations sit within a hierarchical spatial model: Organization → Warehouse (Site) → Zone → Aisle → Side → Column/Row. This hierarchy determines how putaway strategies are applied, how routes are calculated, and how work zones restrict equipment access. The configuration of each location — its type, storage mode, capacity, and logics — determines which processes can use it and how the system manages stock within it. +Locations sit within a hierarchical spatial model: Organization → Warehouse (Site) → Zone → Aisle → Side → Column/Row. This hierarchy determines how putaway strategies are applied, how routes are calculated, and how work zones restrict equipment access. The configuration of each location - its type, storage mode, capacity, and logics - determines which processes can use it and how the system manages stock within it. Locations are created and configured by implementers using the EasyS or Easy Assistant configuration tools. End users cannot create or delete physical locations; they can only manage stock within them and perform administrative operations such as locking, relabeling, or changing work zones. @@ -80,10 +80,10 @@ In conventional rack and APS locations, if a container physically cannot be depo When two sub-warehouses cannot share equipment (e.g., only high-reach forklift accesses a mezzanine, but it is barred from the ground-floor picking area), an **intermediate Buffer location** lets two different equipment types hand stock off to each other. -**Pattern** — `Sub-warehouse B reserve → Transit buffer → Sub-warehouse A picking`: +**Pattern** - `Sub-warehouse B reserve → Transit buffer → Sub-warehouse A picking`: - EasyS element of type **"Transport"** with aisles configured. -- Its sub-location (double-click the transport element) is the actual buffer location. **EasyS creates it as type `Automatic` — it must be changed manually to type `Buffer`**, otherwise the RFT rejects the container scan with "le support n'existe pas". +- Its sub-location (double-click the transport element) is the actual buffer location. **EasyS creates it as type `Automatic` - it must be changed manually to type `Buffer`**, otherwise the RFT rejects the container scan with "le support n'existe pas". - The transport sub-warehouse must be reachable by both equipment groups. **Routing**: @@ -95,14 +95,14 @@ When two sub-warehouses cannot share equipment (e.g., only high-reach forklift a | Equipment group PICKING | Both sub-warehouses | | Equipment group RESERVE | Sub-warehouse B only | -Routes default to transport type `Galileo` — manually flip them to `RF` for a manual warehouse. +Routes default to transport type `Galileo` - manually flip them to `RF` for a manual warehouse. **Flow at runtime**: 1. Replenishment task created from reserve (B) to picking location (A). 2. RESERVE equipment (e.g., `CACES06`) takes the task → drops container on the transit Buffer. 3. PICKING equipment (e.g., `PIK01`) picks the task in **Tâches → Tâches de réapprovisionnement** → drops stock at the picking destination. -See [concepts/replenishment.md](replenishment.md#inter-sub-warehouse-replenishment-via-intermediate-buffer) for the matching replenishment flow. +See [concepts/replenishment.md](replenishment.md#inter-sub-warehouse-replenishment-via-an-intermediate-buffer) for the matching replenishment flow. ## Location coding @@ -164,7 +164,7 @@ Key attributes visible in the "Locations" view: | Sub-warehouse | Sub-warehouse this location belongs to | | Coordinates | Aisle, side, X, Y, depth, stackability | | Maximum weight | kg capacity | -| Height | m — used for container height compatibility checks | +| Height | m - used for container height compatibility checks | | Last count date | When this location was last physically counted | | Full (manually marked) | Location excluded from putaway search; cleared when stock is added manually | | Crossdocking location | Flag for crossdocking eligibility | @@ -252,12 +252,12 @@ From the "Locations" view, users can modify (PC only): ## Related -- [[container]] — stored in locations; location type determines container compatibility and position tracking -- [[stock]] — stock records are always linked to a location; location logics determine stock eligibility for picking/shipping/replenishment -- [[putaway]] — putaway strategies target specific locations via zone/type/logic filters -- [[replenishment]] — PDLs are locations with item assignment; replenishment source/target logics control eligibility -- [[count]] — count processes filter on "Allow count" logic; count partition assignments link items to location positions -- [[defragmentation]] — defragmentation moves stock between locations to consolidate and optimize space -- [[task]] — all movement tasks have source/destination locations; location type determines coordinate reporting -- [[crossdocking]] — crossdocking locations flagged with "Is crossdocking" are reserved for near-term outbound stock -- [[stations]] — stations group locations into functional zones for routing and process assignment +- [[container]] - stored in locations; location type determines container compatibility and position tracking +- [[stock]] - stock records are always linked to a location; location logics determine stock eligibility for picking/shipping/replenishment +- [[putaway]] - putaway strategies target specific locations via zone/type/logic filters +- [[replenishment]] - PDLs are locations with item assignment; replenishment source/target logics control eligibility +- [[count]] - count processes filter on "Allow count" logic; count partition assignments link items to location positions +- [[defragmentation]] - defragmentation moves stock between locations to consolidate and optimize space +- [[task]] - all movement tasks have source/destination locations; location type determines coordinate reporting +- [[crossdocking]] - crossdocking locations flagged with "Is crossdocking" are reserved for near-term outbound stock +- [[stations]] - stations group locations into functional zones for routing and process assignment diff --git a/wiki/concepts/manual-movements.md b/wiki/concepts/manual-movements.md index 90ef8c6..12b9dba 100644 --- a/wiki/concepts/manual-movements.md +++ b/wiki/concepts/manual-movements.md @@ -20,13 +20,13 @@ last_compiled: "2026-04-10" - Stock or a container was physically moved without informing EasyWMS first, or - Stock or a container appeared in a location different from the one recorded in the system -This is a corrective, out-of-band mechanism — it does not create picking or replenishment tasks, but directly updates the stock/container records in the system to match physical reality. +This is a corrective, out-of-band mechanism - it does not create picking or replenishment tasks, but directly updates the stock/container records in the system to match physical reality. Manual movements are available from **both manual and automatic warehouses** (at a picking conveyor for automatic). All manual movements generate `STK.MOVE` transactions (and `CON.MOVE` for container moves). -> **Important:** Manual movements do **not** create guided tasks — they directly apply the relocation. For planned container movements, use task-based processes (putaway, replenishment, etc.). +> **Important:** Manual movements do **not** create guided tasks - they directly apply the relocation. For planned container movements, use task-based processes (putaway, replenishment, etc.). --- @@ -72,7 +72,7 @@ All manual movements generate `STK.MOVE` transactions (and `CON.MOVE` for contai **Valid in both manual and automatic warehouses.** At a picking conveyor, valid as long as neither source nor destination container/stock has active replenishment, picking, or counting tasks. -**Special case — virtual Movement location:** Stock can be moved between containers even when one container is at a PK station and in the "Movement" virtual location (i.e., in transit). +**Special case - virtual Movement location:** Stock can be moved between containers even when one container is at a PK station and in the "Movement" virtual location (i.e., in transit). **Movement of client stock** is allowed when there is a matching shipping order. @@ -156,7 +156,7 @@ Cutting stock (non-consolidating UoM) has special behavior due to its indivisibl 4. The label "Maximum quantity" shows the longest stretch at the location 5. Operator can use "List Stock" action to see and select all stretches; "All" action loads all stretches -**Key rule:** Cutting stock can only be moved **entire stretch by entire stretch** — no partial moves. +**Key rule:** Cutting stock can only be moved **entire stretch by entire stretch** - no partial moves. **Interface:** - RFT: `Utilities > Manual Move` @@ -168,7 +168,7 @@ Cutting stock (non-consolidating UoM) has special behavior due to its indivisibl **When:** Loose stock in one or more partitions of a picking location was recorded in a different partition. **Restrictions:** -- Cannot know the total quantity in a partition — if a partition becomes empty, the operator must explicitly mark it +- Cannot know the total quantity in a partition - if a partition becomes empty, the operator must explicitly mark it - Cannot move a partition itself, only the stock within it - Cannot change to a partition in another warehouse @@ -190,11 +190,11 @@ Cutting stock (non-consolidating UoM) has special behavior due to its indivisibl ## Business Rules -- Manual movements do **not** generate guided tasks — they directly update records. +- Manual movements do **not** generate guided tasks - they directly update records. - All moves are **within the same warehouse**. Cross-warehouse moves are not supported. - ASN containers (pre-notified, not yet received) **cannot be moved** by manual movement. - Client stock (assigned to a shipping order) can only move to another client container with a matching shipping order. -- Locks blocking movement prompt operator confirmation — the move **can still proceed** at the operator's discretion. +- Locks blocking movement prompt operator confirmation - the move **can still proceed** at the operator's discretion. - For cutting stock with multiple stretches of non-consolidating UoM, **only one stretch can be moved at a time**. - Moving a container with replenishment assignments cancels those assignments and triggers task decrement/cancellation on affected picking tasks. @@ -224,8 +224,8 @@ Cutting stock (non-consolidating UoM) has special behavior due to its indivisibl ## Related -- [[container]] — Container moves update CON.MOVE; moving a container with replenishment assignments cascades to task cancellation -- [[location]] — All moves are within a single warehouse; virtual locations (Movement) are valid endpoints for container moves in transit -- [[stock]] — STK.MOVE transactions update all stock records; manual movements are the corrective path when physical and system records diverge -- [[task]] — Manual movements can cancel/decrement picking/replenishment tasks; they do not create guided tasks themselves -- [[stock-adjustment]] — Complement to manual movements: adjustments correct quantity/UoM/attributes; manual movements correct location +- [[container]] - Container moves update CON.MOVE; moving a container with replenishment assignments cascades to task cancellation +- [[location]] - All moves are within a single warehouse; virtual locations (Movement) are valid endpoints for container moves in transit +- [[stock]] - STK.MOVE transactions update all stock records; manual movements are the corrective path when physical and system records diverge +- [[task]] - Manual movements can cancel/decrement picking/replenishment tasks; they do not create guided tasks themselves +- [[stock-adjustment]] - Complement to manual movements: adjustments correct quantity/UoM/attributes; manual movements correct location diff --git a/wiki/concepts/mechanical-elements.md b/wiki/concepts/mechanical-elements.md index fe19265..e267a9e 100644 --- a/wiki/concepts/mechanical-elements.md +++ b/wiki/concepts/mechanical-elements.md @@ -1,5 +1,5 @@ --- -title: "Mechanical Elements — Acronyms, Conveyors, Station Codes" +title: "Mechanical Elements - Acronyms, Conveyors, Station Codes" type: concept sources: - sources/archives/Acronymes_elements_mecaniques.md @@ -18,7 +18,7 @@ related: last_compiled: "2026-04-17" --- -# Mechanical Elements — Acronyms, Conveyors, Station Codes +# Mechanical Elements - Acronyms, Conveyors, Station Codes ## Overview @@ -37,12 +37,12 @@ All Mecalux mechanical acronyms are in Spanish; the translation matters because | **APS200** | Pallet Shuttle Automático (supercondensadores) | Automatic Pallet Shuttle (SUPERCAP) | | **ATC** | Abatible Transportador de Cadenas | Lift-up gate Chain Conveyor | | **CT** | Carro Transferidor | Transfer Car | -| **2ECDF** | — | Double Telescopic Fork with Combined Belts | -| **ECDF** | — | Telescopic Fork (belt, double) | +| **2ECDF** | - | Double Telescopic Fork with Combined Belts | +| **ECDF** | - | Telescopic Fork (belt, double) | | **EMS** | Sistema electrovía aérea | Overhead Electric Monorail | | **EP** | Elevador Paletas | Pallet Lift | -| **EPDF** | — | Telescopic Fork (double fond) | -| **EPSF** | — | Telescopic Fork (simple fond) | +| **EPDF** | - | Telescopic Fork (double fond) | +| **EPSF** | - | Telescopic Fork (simple fond) | | **IMS** | Sistema electrovía invertida | Inverted Electric Monorail | | **LBC** | Transportador de Banda recto Continuo | Continuous Belt Conveyor | | **LRA** | Transportador de Rodillos de Acúmulo | Buffering Roller Conveyor | @@ -77,18 +77,18 @@ Conveyor type drives whether EasyWMS can reliably track a container on the conve | Type | Capacity | WMS tracking | |------|----------|--------------| | **LRA** (Buffering roller) | 1 container | Tracking moves LRA → LRA on each hop; container can be **stopped** on an LRA | -| **LRC** (Continuous roller) | multiple containers | Containers advance until the end sensor trips — **tracking is generally lost** on LRC | +| **LRC** (Continuous roller) | multiple containers | Containers advance until the end sensor trips - **tracking is generally lost** on LRC | | **LRAB** (Scale roller) | 1 container | Acts like LRA, with an integrated scale (weight verification) | | **LTM** (Cross transfer) | 1 container | 90° change of direction; on multidirectional tables set `routing options = 1` for each feeder conveyor | -| **LRD** (Diverting outlet) | — | Oblique outlet — splits flow off a main line | -| **LRI** (Angle induction) | — | Oblique inlet — merges flow onto a main line | +| **LRD** (Diverting outlet) | - | Oblique outlet - splits flow off a main line | +| **LRI** (Angle induction) | - | Oblique inlet - merges flow onto a main line | | **LBC** (Belt conveyor) | multiple containers | **Tracking lost** when a container passes a belt conveyor | -| **LRL** (Free roller / gravity) | — | **No tracking** on LRL; WMS treats the position as a **buffer** (typically with an outbound station upstream) | -| Pedestrian passage | — | Elevated walkway — not a conveyor; no container flow | +| **LRL** (Free roller / gravity) | - | **No tracking** on LRL; WMS treats the position as a **buffer** (typically with an outbound station upstream) | +| Pedestrian passage | - | Elevated walkway - not a conveyor; no container flow | **Practical consequence:** LBC and LRL segments behave as "blind" zones. If a PS (shipping conveyor) outputs onto an LRL, WMS closes the tracking at the PS and considers the container parked in a buffer. -## 3. Station codes — FR / ES / EN matrix +## 3. Station codes - FR / ES / EN matrix Station codes are shared by EasyWMS and GALILEO. Each station is uniquely identified by the couple **(Type, Number)**. Keep this table as the source of truth when cross-referencing documentation between regions. @@ -125,20 +125,20 @@ Machine code reading rules for miniloads: - **ML** = Miniload - **B** (after ML) = **Bicolumn** (absence of B = single column) → e.g. `ML-100` (single), `MLB-100Q` (bi) -- **EPSF** = Extracteur Pelle Simple Fond — **1 charge** per extraction cycle (pelle = shovel, single depth) -- **EPDF** = Extracteur Pelle Double Fond — **1 charge**, double-depth rack -- **ECDF** = Extracteur Courroie Double Fond — **2 charges** per extraction cycle (courroie = belt, double depth) +- **EPSF** = Extracteur Pelle Simple Fond - **1 charge** per extraction cycle (pelle = shovel, single depth) +- **EPDF** = Extracteur Pelle Double Fond - **1 charge**, double-depth rack +- **ECDF** = Extracteur Courroie Double Fond - **2 charges** per extraction cycle (courroie = belt, double depth) **Rule of thumb:** - "Pelle" (shovel) extractors handle **one charge** at a time -- "Courroie" (belt) extractors can handle **two charges** at a time — they drive the logic for channel filling and double-depth putaway +- "Courroie" (belt) extractors can handle **two charges** at a time - they drive the logic for channel filling and double-depth putaway The miniload model (from the installation layout) dictates the entry/outbound table configuration in EasyS (see [Galileo Simulation](../operations/galileo-simulation.md)). ## Related -- [Stations & Routes](stations.md) — full WMS station catalogue -- [GALILEO Integration](../architecture/galileo-integration.md) — how station codes feed the protocol -- [Galileo Simulation & Test Setup](../operations/galileo-simulation.md) — PLC Types, rack configuration, routes -- [Galileo Troubleshooting](../operations/galileo-troubleshooting.md) — cross-check station codes when debugging `EndErrorCode=4` +- [Stations & Routes](stations.md) - full WMS station catalogue +- [GALILEO Integration](../architecture/galileo-integration.md) - how station codes feed the protocol +- [Galileo Simulation & Test Setup](../operations/galileo-simulation.md) - PLC Types, rack configuration, routes +- [Galileo Troubleshooting](../operations/galileo-troubleshooting.md) - cross-check station codes when debugging `EndErrorCode=4` - [Pallet Shuttle](../modules/pallet-shuttle.md) · [APS3D](../modules/aps3d.md) · [Movirack](../modules/movirack.md) · [AGV](../modules/agv.md) diff --git a/wiki/concepts/order-inbound.md b/wiki/concepts/order-inbound.md index 751846d..1c02c17 100644 --- a/wiki/concepts/order-inbound.md +++ b/wiki/concepts/order-inbound.md @@ -36,7 +36,7 @@ last_compiled: "2026-04-10" A **receipt order** (also called inbound order) is the WMS document that tracks expected incoming stock. It represents a list of items or containers expected to arrive at the warehouse, serving as the basis for the reception process. Receipt orders allow the warehouse to plan dock resources, validate quantities, and close the loop with the ERP upon receipt. -Most receipt orders originate in the ERP (purchase orders to suppliers, customer return orders, transfer orders from other warehouses) and arrive via messaging. Easy WMS also allows manual creation of receipt orders directly in the UI. Receipt orders are optional — stock can be received without one (blind reception) — but they enable quantity control, automatic label printing, and ERP reconciliation. +Most receipt orders originate in the ERP (purchase orders to suppliers, customer return orders, transfer orders from other warehouses) and arrive via messaging. Easy WMS also allows manual creation of receipt orders directly in the UI. Receipt orders are optional - stock can be received without one (blind reception) - but they enable quantity control, automatic label printing, and ERP reconciliation. The receipt order is distinct from the **receipt** (the actual WMS event of receiving stock physically). One receipt order can be fulfilled by one or more receipts; one receipt can be associated with one or more receipt orders. @@ -47,7 +47,7 @@ Receipt orders (and their associated receipts) are categorized by type, which co | Type | Description | Typical origin | |---|---|---| | **Supplier** | Stock arriving from a vendor. Lines specify items, expected quantities, and UoM. Stock may arrive in any presentation (pack, box, etc.) regardless of the line's UoM. Logistic attributes and quality status can optionally be pre-set by the ERP. | ERP purchase order (PO) | -| **Return** | Customer returns — damaged or surplus stock. Similar line structure to Supplier type. | ERP return authorization | +| **Return** | Customer returns - damaged or surplus stock. Similar line structure to Supplier type. | ERP return authorization | | **Transfer** | Stock transferred from another warehouse in the same organization. Stock always arrives in containers, which are pre-notified as ASN containers at the destination. Lines specify containers, items, and quantities. | ERP transfer order; automatic when source shipping order closes (Transfer type) | Receipt orders also have a **class** for additional personalization of the reception process (custom flow variants, label types, etc.). Classes do not change the type logic but allow further differentiation. @@ -81,7 +81,7 @@ Each line identifies the expected item/container and quantity: | **Line number** | Unique line identifier within the order | | **Status** | Line status (mirrors order status progression) | | **Container** | Expected or received container code (Transfer type or ASN) | -| **Item** | Item code expected; alternatively, a presentation alias (GTIN/EAN) can be used — in this case, only stock of that EAN presentation is received against this line | +| **Item** | Item code expected; alternatively, a presentation alias (GTIN/EAN) can be used - in this case, only stock of that EAN presentation is received against this line | | **Owner** | Owner of the expected stock | | **Quantity** | Expected quantity | | **UoM** | Unit of measure (usually base UoM; can be a presentation if packaging is known) | @@ -130,7 +130,7 @@ Each line identifies the expected item/container and quantity: ### Messages: ERP → WMS -#### ROR — Receipt Order Request +#### ROR - Receipt Order Request Creates, modifies, or cancels receipt orders. @@ -155,7 +155,7 @@ Key ROR fields: - Line `LneStockStatus`: forced receiving status for stock on this line - Line reserves (`LneStkRsvSORCode` / `LneStkRsvAccCode`): pre-allocate received stock to a specific outbound order or account -#### ASN — Advanced Shipping Notice +#### ASN - Advanced Shipping Notice Pre-notifies containers expected at the warehouse. Containers are created in the virtual ASN location. @@ -176,11 +176,11 @@ ASN key fields: `ContainerCode`, `ContainerType`, `ReceiptOrderCode`, `NumExpect ### Messages: WMS → ERP -#### ROC — Receipt Order status Change +#### ROC - Receipt Order status Change Sent by WMS when an order changes status. Fields: `RorCode`, `Status` (Waiting / ReceptionPending / Receiving / PartiallyReceived / Complete / Expired / Canceled), `UpdateDate` (UTC timestamp). -#### ROF — Receipt Order Finalization +#### ROF - Receipt Order Finalization Sent when an order is closed or canceled. Two versions: - **ROF01**: includes receipt data + order data + stock received. Sent on order close/cancel AND on receipt close (even if receipt has no order). @@ -188,11 +188,11 @@ Sent when an order is closed or canceled. Two versions: ROF01/ROF02 key fields per line: `LneItemCode`, `LneOwnerCode`, `LneQtyExpected`, `LneQtyReceived`, `LneQtyFree`, `LneQtyUoMCode`. -#### ASO — ASN receipt confirmation (WMS → ERP) +#### ASO - ASN receipt confirmation (WMS → ERP) Sent when an ASN pre-notified container is physically received. Confirms item, owner, quantity, and optionally the receiving status (`LneStaStatus`). Variants mirror ASN variants (stacked, matched on dummy, with divisions). -#### STR — Stock lock/unlock request (ERP → WMS) +#### STR - Stock lock/unlock request (ERP → WMS) Although STR is a request (not a receipt order message), it is closely related to inbound quality control. The ERP requests Easy WMS to apply or remove a user status on stock (e.g., lock a lot for quality reasons): - `Operation S`: add user status (lock) with optional quarantine end date @@ -241,11 +241,11 @@ WMS responds with one or more **STC** messages confirming the modified stock. ## Related -- [[reception]] — the physical reception process that fulfills receipt orders; dock/PIE/ASN reception modes all reference receipt orders -- [[container]] — ASN pre-notifies containers; Transfer-type receipt orders always involve containers -- [[product-item]] — receipt order lines reference items by code or alias; reception profile governs behavior -- [[stock]] — receipt creates stock; receiving status from ROR line is applied to created stock -- [[putaway]] — after reception, putaway tasks move stock from dock to storage; receipt order type affects putaway strategy eligibility -- [[order-outbound]] — receipt orders can include reserves for outbound orders (cross-dock scenario); transfer orders create an outbound order at source -- [[crossdocking]] — ASN containers with exclusive reserves enable direct crossdocking on receipt -- [[erp-interface]] — ROR (in), ASN (in), ROC (out), ROF (out), ASO (out), STR (in), STC (out) messages +- [[reception]] - the physical reception process that fulfills receipt orders; dock/PIE/ASN reception modes all reference receipt orders +- [[container]] - ASN pre-notifies containers; Transfer-type receipt orders always involve containers +- [[product-item]] - receipt order lines reference items by code or alias; reception profile governs behavior +- [[stock]] - receipt creates stock; receiving status from ROR line is applied to created stock +- [[putaway]] - after reception, putaway tasks move stock from dock to storage; receipt order type affects putaway strategy eligibility +- [[order-outbound]] - receipt orders can include reserves for outbound orders (cross-dock scenario); transfer orders create an outbound order at source +- [[crossdocking]] - ASN containers with exclusive reserves enable direct crossdocking on receipt +- [[erp-interface]] - ROR (in), ASN (in), ROC (out), ROF (out), ASO (out), STR (in), STC (out) messages diff --git a/wiki/concepts/order-outbound.md b/wiki/concepts/order-outbound.md index a7501b7..c59fca8 100644 --- a/wiki/concepts/order-outbound.md +++ b/wiki/concepts/order-outbound.md @@ -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 `` order (`` 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 `` order (`` 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 `` order (`` 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 ``-type order (`` in `SOR02`) also requires **at least two warehouses** in the WMS. Unlike ``, 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 `` flows the ERP **must** consume `ROF02` — which contains the full list of received containers. +> ⚠️ `ASO01` and `ASK01` still carry **no transfer-header info**. For `` 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 `` (every sub-tag) - Complete `` + `` - 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 ``` -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) diff --git a/wiki/concepts/parameters.md b/wiki/concepts/parameters.md index a18ac02..1de3af4 100644 --- a/wiki/concepts/parameters.md +++ b/wiki/concepts/parameters.md @@ -28,7 +28,7 @@ last_compiled: "2026-04-10" ## Overview -Parameters control system behavior at the warehouse level. They allow the same Easy WMS software to behave differently across warehouses of the same organization without code changes. Every process — reception, picking, counting, replenishment — has parameters that tune its behavior. +Parameters control system behavior at the warehouse level. They allow the same Easy WMS software to behave differently across warehouses of the same organization without code changes. Every process - reception, picking, counting, replenishment - has parameters that tune its behavior. Parameters are defined at the **organization level** but can be **customized per warehouse**. A warehouse-level value overrides the organization default. @@ -301,11 +301,11 @@ Parameters mentioned in other wiki pages: ## Related -- [[reception]] — ALLOW_CREATE_RECEPTION, RECEPTION_ASN_*, AutoCloseReception, label printing params -- [[picking]] — WORKWAVES_ALLOW_SELECTION, PTL_WORKING_MODE, FILTER_BEFORE_PICKING, RF_PICKING_CONFIRM_LOCATION -- [[shipping]] — OUTBOUND_ORDER_PACKINGLIST_*, AUTO_MERGE_ORDERS, AutoCloseLoadedOutboundOrders -- [[replenishment]] — MAX_GROUPS_PROCESSED_DYNAMIC_REPLENISH_JOB, REPLENISH_LEVEL_PERCENT -- [[defragmentation]] — MAX_DEFRAG_TASKS, MAX_OPTIMIZATION_DEFRAG_CHANNEL -- [[cutting-stock]] — CUTTING_PRINTER -- [[labels]] — All label format and printer parameters -- [[count]] — REPLENISH_LEVEL_PERCENT_PRODUCT_LOCATION, NUM_EVENTS_PER_PARTIAL_COMMIT +- [[reception]] - ALLOW_CREATE_RECEPTION, RECEPTION_ASN_*, AutoCloseReception, label printing params +- [[picking]] - WORKWAVES_ALLOW_SELECTION, PTL_WORKING_MODE, FILTER_BEFORE_PICKING, RF_PICKING_CONFIRM_LOCATION +- [[shipping]] - OUTBOUND_ORDER_PACKINGLIST_*, AUTO_MERGE_ORDERS, AutoCloseLoadedOutboundOrders +- [[replenishment]] - MAX_GROUPS_PROCESSED_DYNAMIC_REPLENISH_JOB, REPLENISH_LEVEL_PERCENT +- [[defragmentation]] - MAX_DEFRAG_TASKS, MAX_OPTIMIZATION_DEFRAG_CHANNEL +- [[cutting-stock]] - CUTTING_PRINTER +- [[labels]] - All label format and printer parameters +- [[count]] - REPLENISH_LEVEL_PERCENT_PRODUCT_LOCATION, NUM_EVENTS_PER_PARTIAL_COMMIT diff --git a/wiki/concepts/picking.md b/wiki/concepts/picking.md index bead167..e2c6cd4 100644 --- a/wiki/concepts/picking.md +++ b/wiki/concepts/picking.md @@ -117,7 +117,7 @@ The ordering logic lives in the code activity **"Order stock when none location When a line allows excess shipping, EasyWMS first tries to assign the exact quantity. If all strategies are exhausted without fulfilling the line completely, the first stock discarded by the last strategy is assigned as excess. Excess is minimized by unassigning the last-assigned stock. The "strict shipping logic on excess" flag prevents excess assignment from using better-logic stock over what was already being shipped. -## Picking Modes — Manual Warehouse +## Picking Modes - Manual Warehouse Manual warehouse picking is RFT-driven, following the **picking path** (optimal route minimizing operator travel). The path starts at the picking start point and ends at the shipping area. @@ -135,7 +135,7 @@ Manual warehouse picking is RFT-driven, following the **picking path** (optimal | **Voice picking** | Operator receives spoken instructions, confirms by voice; both hands free for handling | RFT + headset | | **Advanced picking** | Picks client containers before dock/stage assigned; containers placed on shelf until assignment | RFT | -**Cutting stock picking** (rope, cable, chain — indivisible lengths): +**Cutting stock picking** (rope, cable, chain - indivisible lengths): - Requires a physical cut before picking - Two models: **integrated cut** (cut performed at the location) or **delegated cut** (cut performed at a dedicated cutting station) - Cutting stations can have dedicated equipment and procedures for item-specific cutting complexity @@ -155,27 +155,27 @@ Manual warehouse picking is RFT-driven, following the **picking path** (optimal **Flow (RFT):** 1. Enter the **outbound code** (a default is proposed) 2. Choose the **shipping dock** -3. Add lines — **item + quantity** — repeat per line -4. **Release** the order — creates the outbound, its lines, and the picking tasks in SmartUI (can take time for large orders) +3. Add lines - **item + quantity** - repeat per line +4. **Release** the order - creates the outbound, its lines, and the picking tasks in SmartUI (can take time for large orders) 5. The RFT is redirected into the **standard picking loop** **Module interactions:** -- **3PL module** — SOC and SOF use different document codes (the owner is appended to the SOF only). Example: SOC `MAN0000000000000000010`, SOF `MAN0000000000000000010-CECOA`. -- **Carrier module** — manual picking does **not** expose a carrier field, which can block downstream carrier processing. If the module is enforced, expect a post-release manual intervention. +- **3PL module** - SOC and SOF use different document codes (the owner is appended to the SOF only). Example: SOC `MAN0000000000000000010`, SOF `MAN0000000000000000010-CECOA`. +- **Carrier module** - manual picking does **not** expose a carrier field, which can block downstream carrier processing. If the module is enforced, expect a post-release manual intervention. -Entry workflow: `EasyWMS.ManualPicking_ByItem_UI` (cf. [RF Menu reference](../architecture/rf-menu.md#4-ordres-dexpédition-sharedmenu_shippingorders)). +Entry workflow: `EasyWMS.ManualPicking_ByItem_UI` (cf. [RF Menu reference](../architecture/rf-menu.md#4-shipping-orders---sharedmenu_shippingorders)). ### Location Carts (chariots à emplacement) for Multi-Order Picking Location carts let one operator prepare **several orders at once without creating one client container per order**. The WMS maps cart divisions (column × row) to orders automatically. -- **Usable only in multi-order picking modes** — groups of orders and waves +- **Usable only in multi-order picking modes** - groups of orders and waves - Removes the need for a secondary *"TRF à emplacement"* configuration in many layouts - After picking, the cart is dropped directly onto the packing station -**Setup — SmartUI:** +**Setup - SmartUI:** -1. **Create division types** — define the number and codes of cart slots (tested up to 20×20). The WMS temporarily labels slots `Section{sequence}`; the name entered guides the operator during picking. +1. **Create division types** - define the number and codes of cart slots (tested up to 20×20). The WMS temporarily labels slots `Section{sequence}`; the name entered guides the operator during picking. 2. **Create the cart** (tab **"Carts"**): | Field | Description | @@ -184,14 +184,14 @@ Location carts let one operator prepare **several orders at once without creatin | Storage location | **Mandatory** | | Division type | If empty → the cart behaves as one slot | -Cart statuses : **Open** (available), **Closed** (stock in progress — not yet packed). +Cart statuses : **Open** (available), **Closed** (stock in progress - not yet packed). **Picking with a cart (RFT):** -- At wave/group start, the RFT proposes to use a cart — scan its code. +- At wave/group start, the RFT proposes to use a cart - scan its code. - On the first drop, the WMS asks which slot (division) to use; subsequent tasks for the same order are auto-routed to the same slot. - Column **"Division"** shows `CartCode_SectionCode`. -**Edge case — closed cart with no free slot:** the RFT reports no task available and flips the cart back to **Open**. To unload: **"Fermer"** on the task list → RFT menu **Rangement → Stock de chariots** → either "Ranger le chariot entièrement" (no redirection to packing) or "Décharger en mode stock libre". +**Edge case - closed cart with no free slot:** the RFT reports no task available and flips the cart back to **Open**. To unload: **"Fermer"** on the task list → RFT menu **Rangement → Stock de chariots** → either "Ranger le chariot entièrement" (no redirection to packing) or "Décharger en mode stock libre". **Packing:** scan the cart code → WMS indicates divisions → scan the division to pack (or list divisions with stock). Standard packing runs with `CartCode_SectionCode` as origin. @@ -211,7 +211,7 @@ Paper picking is used when RF coverage is missing, when a customer wants a print 6. Back at the station, click **Confirmer le lot** and **scan the batch number** on the printed sheet : - If the order is complete → scan the batch number a second time to close the preparation. - Otherwise → scan the incomplete tasks one by one and enter the actual picked quantity. -7. Scan the batch number one last time to mark the preparation done — the order transitions to **"Prepared"** and stock is transferred to the staging buffer / dock. +7. Scan the batch number one last time to mark the preparation done - the order transitions to **"Prepared"** and stock is transferred to the staging buffer / dock. ### Picking Incidences (Manual Warehouse) @@ -219,9 +219,9 @@ During picking, issues are recorded when containers are not where expected or ex - **Mark to review**: creates a lock and count on the container/location; does not interrupt the current process; lock removed when count completes - **Stock adjustment**: ERP is notified of any inventory corrections via messenger service -**Wait for replenishment**: configurable behavior — system can auto-trigger replenishment tasks when a picking location is empty to complete the pick. +**Wait for replenishment**: configurable behavior - system can auto-trigger replenishment tasks when a picking location is empty to complete the pick. -By default, when an outbound order is released and no picking location has stock (but stock exists in replenishment sources), picking tasks are created on empty PDLs — these are **silently skipped at execution time** if the PDL is still empty when the operator reaches it. Three global parameters relax this default : +By default, when an outbound order is released and no picking location has stock (but stock exists in replenishment sources), picking tasks are created on empty PDLs - these are **silently skipped at execution time** if the PDL is still empty when the operator reaches it. Three global parameters relax this default : | Parameter | Effect | Key workflow(s) | |---|---|---| @@ -242,7 +242,7 @@ Operator flow for the third parameter : **Excess reduction**: if multiple tasks exist for the same item and one is over-picked, the remaining tasks are reduced by the excess amount (or canceled if already satisfied). -## Picking — Automatic Warehouse (Picking Conveyor / PK) +## Picking - Automatic Warehouse (Picking Conveyor / PK) In automatic warehouses, picking is goods-to-person. The TMS extracts containers from storage and brings them to a **picking conveyor (PK)** station. One PK can serve multiple **preparation zones (MP)**; each MP is a physical table where the operator deposits picked stock into client containers. @@ -259,14 +259,14 @@ Configuration of picking + preparation pairs (robotics-specific, from EasyS + Sm - **Virtual** route → consolidation zone - **Max concurrent orders** (SmartUI): **Menu → Control → Workstations** → select PK → set the value. Must **equal the number of preparation tables** linked to the PK - **MP assignment mode** (SmartUI): **Menu → Control → Workstations** → select MP(s) → **Modify assignment mode** - - **Automatic** — WMS assigns the next order to a table - - **Manual** — operator assigns via **Menu → Control → Picking-station assignment**. ⚠️ In manual mode, **tasks do not generate until the order is assigned** -- **Route requirement**: the MP must have a route to the shipping dock of the order — otherwise tasks won't generate + - **Automatic** - WMS assigns the next order to a table + - **Manual** - operator assigns via **Menu → Control → Picking-station assignment**. ⚠️ In manual mode, **tasks do not generate until the order is assigned** +- **Route requirement**: the MP must have a route to the shipping dock of the order - otherwise tasks won't generate **Three ways to trigger container extraction from the miniload:** 1. Demand the container from the picking workstation (specific support, empty supports, or specific item) 2. Request empty containers -3. Launch an order — assigns PK + generates `pickingContainer` tasks +3. Launch an order - assigns PK + generates `pickingContainer` tasks For detailed bring-up in simulation and the "Store container" + "Liberate" test flow, see [Galileo Simulation](../operations/galileo-simulation.md). @@ -322,7 +322,7 @@ After all picking tasks for a shipping order are completed at the PK: - Physical PK pushbutton is pressed to signal completion - TMS generates movement tasks to return the source container to its storage location or to a rejection station -## Picking — Pick and Pack Mode +## Picking - Pick and Pack Mode In Pick and Pack warehouses, operators pick stock directly into the final shipping carton (client container). Two integration levels: @@ -359,7 +359,7 @@ The picking path is the optimal traversal order of locations for picking tasks. The picking path starts at the **picking start point** (configured per sub-warehouse or warehouse) and ends at the shipping area. The path selects the next closest task, but overall path optimality depends on warehouse layout. -## Order Planning — Waves, Groups, and Shipment Templates +## Order Planning - Waves, Groups, and Shipment Templates ### Order priorities @@ -367,11 +367,11 @@ Each shipping order carries a priority that determines task sequence: | Priority | Relative urgency | |----------|-----------------| -| **Urgent** | Highest — processed first in all queues | +| **Urgent** | Highest - processed first in all queues | | **High** | Above normal | | **Normal** | Default | | **Low** | Below normal | -| **Very Low** | Lowest — processed last | +| **Very Low** | Lowest - processed last | Priorities are set per order (from the ERP or manually) and apply across all picking and shipping task generation. @@ -418,7 +418,7 @@ Shipment templates automate wave and group creation by applying a set of selecti ### Order fusion -**Fusion** merges multiple shipping orders from the same client/destination into a single preparation batch. This is a **manual-only** operation — EasyWMS does not auto-fuse orders. +**Fusion** merges multiple shipping orders from the same client/destination into a single preparation batch. This is a **manual-only** operation - EasyWMS does not auto-fuse orders. Conditions for fusion: - Same client (account) @@ -458,23 +458,23 @@ After fusion, the combined order is prepared as a single batch, reducing travel | Interface | Path | |---|---| -| RFT — picking (manual warehouse) | Menu "Picking" → task mode selection | -| RFT — picking conveyor (automatic warehouse) | Workstation "Picking" view | -| Web — stock assignment strategies | "Configuration" → "Stock assignment strategies" | -| Web — shipping order + stock assign | "Shipping" → "Shipping orders" → order → "Stock assign" | -| Web — workstations (PK config) | "Control" → "Workstations" | -| Web — docks and stages | "Control" → "Docks and stages" | +| RFT - picking (manual warehouse) | Menu "Picking" → task mode selection | +| RFT - picking conveyor (automatic warehouse) | Workstation "Picking" view | +| Web - stock assignment strategies | "Configuration" → "Stock assignment strategies" | +| Web - shipping order + stock assign | "Shipping" → "Shipping orders" → order → "Stock assign" | +| Web - workstations (PK config) | "Control" → "Workstations" | +| Web - docks and stages | "Control" → "Docks and stages" | ## Related -- [Shipping](shipping.md) — picking is part of the shipping process; picking leads to truck loading -- [Replenishment](replenishment.md) — picking from dedicated locations triggers replenishment when stock runs out -- [Container (LPN)](container.md) — client containers are created during picking; source containers are extracted from storage -- [Stock](stock.md) — stock assignment determines which specific stock unit is picked -- [Reception](reception.md) — received goods enter inventory and become eligible for stock assignment -- [Task](task.md) — picking generates Picking tasks; negative picking and cut picking are specific task types -- [Outbound Order](order-outbound.md) — shipping orders are the source of picking demand; order priority drives task sequence -- [Location](location.md) — picking dedicated locations (PDLs) are the primary source for picking; location logics control eligibility -- [[cutting-stock]] — cutting stock picking (shelf, integrated station, delegated station) are specialized picking modes -- [[stations]] — PK (type 2), MP (type 16), Workzone (type 64), Decision (type 63), Cutting Station (type 61) all support picking -- [Tense Flow](tense-flow.md) — tense-flow picking bypasses storage : pick directly from a source support into a client container via the `PREPARATION` buffer +- [Shipping](shipping.md) - picking is part of the shipping process; picking leads to truck loading +- [Replenishment](replenishment.md) - picking from dedicated locations triggers replenishment when stock runs out +- [Container (LPN)](container.md) - client containers are created during picking; source containers are extracted from storage +- [Stock](stock.md) - stock assignment determines which specific stock unit is picked +- [Reception](reception.md) - received goods enter inventory and become eligible for stock assignment +- [Task](task.md) - picking generates Picking tasks; negative picking and cut picking are specific task types +- [Outbound Order](order-outbound.md) - shipping orders are the source of picking demand; order priority drives task sequence +- [Location](location.md) - picking dedicated locations (PDLs) are the primary source for picking; location logics control eligibility +- [[cutting-stock]] - cutting stock picking (shelf, integrated station, delegated station) are specialized picking modes +- [[stations]] - PK (type 2), MP (type 16), Workzone (type 64), Decision (type 63), Cutting Station (type 61) all support picking +- [Tense Flow](tense-flow.md) - tense-flow picking bypasses storage : pick directly from a source support into a client container via the `PREPARATION` buffer diff --git a/wiki/concepts/prepackaging.md b/wiki/concepts/prepackaging.md index d00bb82..431b115 100644 --- a/wiki/concepts/prepackaging.md +++ b/wiki/concepts/prepackaging.md @@ -31,7 +31,7 @@ A prepackaging strategy has the following fields: |---|---|---| | **Code** | free text | Strategy name | | **Type de commande** | Fusion / Ordre de départ sans envoi / Vague | Which outbound grouping this strategy applies to | -| **Processus** | Emballage / Préparation | When it is applied — at packing station or during picking | +| **Processus** | Emballage / Préparation | When it is applied - at packing station or during picking | | **Type de précolisage** | Calculé par EasyWMS / Calculé par l'opérateur / Calculé par l'ERP | Who computes the container split | | **Mode de travail** | Strict / Pas strict | Strict = operator cannot deviate from the plan ; non-strict = operator can override | | **Logique de pré emballage** | Nombre minimum de colis / Volume minimum | "Fewest parcels" picks the largest container possible ; "Minimum volume" picks the smallest container possible | @@ -46,7 +46,7 @@ For `Calculé par EasyWMS` to work: 1. **Container types** must be configured in EasyS and associated to equipments. 2. **Item dimensions and weight** must be populated (in conversions). -3. **Mixing restrictions** between items must be defined — by item, by family, or by type. +3. **Mixing restrictions** between items must be defined - by item, by family, or by type. ## Calculation by ERP (SOR02) @@ -75,11 +75,11 @@ When `Calculé par l'ERP`, the outbound order message carries a ` seuil | Carton L (poids reste < 20 kg) | | Ordre de départ / Strict / Nombre minimum / famille non mélangeable | Articles répartis dans colis différents ✅ | -| Ordre de départ / Strict / Nombre minimum / **type** non mélangeable | ❌ **non fonctionnel** — articles mélangés malgré la restriction | +| Ordre de départ / Strict / Nombre minimum / **type** non mélangeable | ❌ **non fonctionnel** - articles mélangés malgré la restriction | | Ordre de départ / Strict / Volume minimum | 3 conteneurs différents | | Vague / Strict / Volume minimum | Calcul réalisé par commande | | **Calcul par l'opérateur** | ❌ **non fonctionnel** | @@ -101,7 +101,7 @@ Confirmed working vs. known-broken combinations: **The strategy has no effect even though it is saved** : it was not activated. Re-open the strategy and toggle activation. -**`Calcul par EasyWMS` produces no containers** : item dimensions/weight missing, or no container type is associated to the equipment — both are prerequisites. +**`Calcul par EasyWMS` produces no containers** : item dimensions/weight missing, or no container type is associated to the equipment - both are prerequisites. **`Type de commande = Ordre de départ sans envoi`** : applies to the simple single-order case ; for waves or fusions, pick the corresponding `Type de commande`, otherwise the strategy is ignored for those grouping types. @@ -109,7 +109,7 @@ Confirmed working vs. known-broken combinations: ## Related -- [Shipping](shipping.md) — the surrounding outbound process ; prepackaging is one step of it -- [Outbound Order](order-outbound.md) — SOR02 carries `PrepackagingConfiguration` ; SOF carries the actually used containers -- [Container (LPN)](container.md) — container types and SSCCs referenced by prepackaging -- [ERP Interface](erp-interface.md) — full field tables for SOR02 +- [Shipping](shipping.md) - the surrounding outbound process ; prepackaging is one step of it +- [Outbound Order](order-outbound.md) - SOR02 carries `PrepackagingConfiguration` ; SOF carries the actually used containers +- [Container (LPN)](container.md) - container types and SSCCs referenced by prepackaging +- [ERP Interface](erp-interface.md) - full field tables for SOR02 diff --git a/wiki/concepts/product-item.md b/wiki/concepts/product-item.md index 722b2b7..087d8ee 100644 --- a/wiki/concepts/product-item.md +++ b/wiki/concepts/product-item.md @@ -48,7 +48,7 @@ last_compiled: "2026-04-17" ## Overview -An **item** is the primary static master data element in Easy WMS. It represents each distinct product that an organization manages in its warehouse. Almost every WMS behavior — reception, putaway, picking, shipping, counting, replenishment — is governed by item configuration. +An **item** is the primary static master data element in Easy WMS. It represents each distinct product that an organization manages in its warehouse. Almost every WMS behavior - reception, putaway, picking, shipping, counting, replenishment - is governed by item configuration. A critical distinction: the **item** is the master definition (SKU, attributes, rules), while **stock** is the physical instance of that item (a quantity of that item in a specific location/container with specific logistic attributes). The same item code can have stock across many locations simultaneously. Multiple owners can also hold stock of the same item code. @@ -72,9 +72,9 @@ Item families define mixing restrictions for **client containers** (containers b Use case: prevent mixing refrigerated and ambient items in the same outbound parcel. When the **Multi-Carrier module** is active, item families also carry a **packaging method** that controls how the carrier call is generated: -- `Scan all items` — operator scans each item into a parcel -- `Choose parcel count` — operator declares how many parcels; system moves all stock into parcel 1 (no automatic weight) -- `1 parcel always` — no operator input; system assumes single-parcel shipment (for high-volume B2C) +- `Scan all items` - operator scans each item into a parcel +- `Choose parcel count` - operator declares how many parcels; system moves all stock into parcel 1 (no automatic weight) +- `1 parcel always` - no operator input; system assumes single-parcel shipment (for high-volume B2C) The most restrictive method in an order takes precedence (Scan > Choose > 1 parcel). @@ -87,7 +87,7 @@ The ABC classification indicates the rotation/activity level of an item relative Used in slotting optimization and putaway strategy rules to position items strategically. -**Operating principles.** The higher the class's movement threshold, the more important it is (A > B > C). Articles with the most movements are classified in the highest class. **Thresholds represent cumulative movement share** — an A article = top 50%, a B = top 80% (50+30), etc. +**Operating principles.** The higher the class's movement threshold, the more important it is (A > B > C). Articles with the most movements are classified in the highest class. **Thresholds represent cumulative movement share** - an A article = top 50%, a B = top 80% (50+30), etc. When an article straddles two classes, the `Type de calcul` chosen at evaluation decides : @@ -103,16 +103,16 @@ When an article straddles two classes, the `Type de calcul` chosen at evaluation **First assignment.** On first setup, every article is set to the **lowest rotation class**. This should be done in the article-base import ; when a new article is later created, this field must be populated manually. -**ABC evaluation (runtime)** — `Tableaux de Bord → Evaluation ABC` (recent versions). Parameters : -- **Date** — `Start-end date` or `By number of day` -- **Mouvements** — task types to include (at least one required) -- **Type de calcul** — `Inclusive` or `Exclusive` +**ABC evaluation (runtime)** - `Tableaux de Bord → Evaluation ABC` (recent versions). Parameters : +- **Date** - `Start-end date` or `By number of day` +- **Mouvements** - task types to include (at least one required) +- **Type de calcul** - `Inclusive` or `Exclusive` Execute then **refresh the grid** to see the results. Results persist until the next evaluation. **Reading the result grid :** -- **Red lines** — article is **over-rated** vs. the evaluation (its stored class is more important than measured activity). -- **Green lines** — article is **under-rated** (measured activity higher than stored class). +- **Red lines** - article is **over-rated** vs. the evaluation (its stored class is more important than measured activity). +- **Green lines** - article is **under-rated** (measured activity higher than stored class). - Conforming articles are not listed. The classification can be edited inline from the evaluation grid. @@ -121,7 +121,7 @@ The classification can be edited inline from the evaluation grid. ## Units of Measure (UoM) -Every item must have a **base UoM** — the reference unit for all conversions. All stock quantities are stored and reported in the base UoM. +Every item must have a **base UoM** - the reference unit for all conversions. All stock quantities are stored and reported in the base UoM. Additional **conversions and presentations** (EAN/GTIN presentations) define the commercial packaging: - Each conversion specifies the quantity of base UoM it contains (e.g., BOX12 = 12 units) @@ -160,13 +160,13 @@ Logistic attributes are characteristics that condition the logistic behavior of ### Creating a logistic attribute without a capture mode -By default, every logistic attribute requires a capture mode (manual, scan, etc.). In some custom flows the attribute must be **auto-generated by code** (e.g., serial number generated server-side) and therefore must exist **without** any capture mode — otherwise SmartUI / RFT will always prompt the operator. +By default, every logistic attribute requires a capture mode (manual, scan, etc.). In some custom flows the attribute must be **auto-generated by code** (e.g., serial number generated server-side) and therefore must exist **without** any capture mode - otherwise SmartUI / RFT will always prompt the operator. -> ⚠️ Once configured this way, the attribute value can no longer be edited from SmartUI or RFT without a custom — the only writer is the custom code that creates the stock. +> ⚠️ Once configured this way, the attribute value can no longer be edited from SmartUI or RFT without a custom - the only writer is the custom code that creates the stock. **Procedure** (requires Admin role + Run Command access): -1. **Create the logistic profile** and add the attribute of the desired type. The capture mode is mandatory at creation — set it to `Manual` (it will be deleted in step 4). +1. **Create the logistic profile** and add the attribute of the desired type. The capture mode is mandatory at creation - set it to `Manual` (it will be deleted in step 4). 2. **Collect the identifiers** with a Run Query on the reading context: ```csharp Context.LogisticAttributes.Select(la => new { @@ -197,7 +197,7 @@ By default, every logistic attribute requires a capture mode (manual, scan, etc. ## Profiles -Profiles define item behavior in each WMS process. They allow bulk configuration — many items can share the same profile. +Profiles define item behavior in each WMS process. They allow bulk configuration - many items can share the same profile. | Profile | Required | Purpose | |---|---|---| @@ -306,14 +306,14 @@ In `SOR01` / `SOR02`, on the relevant `` elements : ``` -### 2. Shipping profile — substitution mode +### 2. Shipping profile - substitution mode Every item involved in the substitution must carry a shipping profile (`Données principales → Détails d'articles → Profils d'expédition`). The mode (X = requested item, Y = substitute) is : | Mode | Behavior | |---|---| | **Partiel** | Sums X + Y to reach the requested quantity. X is prioritized. | -| **Substitution** | Picks X **or** Y exclusively — whichever quantity is closest to the requested one. | +| **Substitution** | Picks X **or** Y exclusively - whichever quantity is closest to the requested one. | | **Tout ou rien** | If X + Y cannot reach the requested quantity, picks **only X** regardless of its quantity. | > ⚠️ For components of **non-assembled kits**, the mode **must be `Partiel`**. @@ -334,7 +334,7 @@ In `Données principales → Articles`, select the **item to be replaced**, clic |---|---| | Only X picked | `false` | | X + Y picked | Two `` blocks : one with `LneDIsAlternative=false` (X), one with `LneDIsAlternative=true` (Y) | -| Only Y picked | Single `` with `LneDIsAlternative=true` — `` still contains **X** (the requested item) | +| Only Y picked | Single `` with `LneDIsAlternative=true` - `` still contains **X** (the requested item) | ## Labeling @@ -420,16 +420,16 @@ Key parameters: ## Related -- [[stock]] — stock is the physical instance of an item; stock lines carry item code, owner, logistic attributes -- [[container]] — containers hold item stock; item stackability controls order of picking into client containers -- [[reception]] — reception profile drives behavior at inbound; logistic attributes captured during receipt -- [[putaway]] — putaway profile defines strategies for this item; temperature/hazard/ABC attributes feed strategy filters -- [[picking]] — shipping profile and logistic attributes drive picking behavior; substitutes used on stock failure -- [[shipping]] — shipping profile mandatory; families control client container mixing; substitutes activated on shortage -- [[count]] — count profile defines item counting behavior (ABC-driven cycle counts) -- [[order-inbound]] — ROR lines reference items by code or presentation alias -- [[order-outbound]] — SOR lines reference items; logistic attribute filtering drives stock assignment -- [[cutting-stock]] — cutting profile marks item as cut item; enables min/max quantities and cut label printing -- [[labels]] — item labels printed at reception, from stock view, and from RFT utilities -- [[erp-interface]] — ITM message manages item master from ERP; SAC01 sends ABC classification back to ERP -- [[kits]] — kit articles and component articles are both standard items; kit assembly consumes component stock +- [[stock]] - stock is the physical instance of an item; stock lines carry item code, owner, logistic attributes +- [[container]] - containers hold item stock; item stackability controls order of picking into client containers +- [[reception]] - reception profile drives behavior at inbound; logistic attributes captured during receipt +- [[putaway]] - putaway profile defines strategies for this item; temperature/hazard/ABC attributes feed strategy filters +- [[picking]] - shipping profile and logistic attributes drive picking behavior; substitutes used on stock failure +- [[shipping]] - shipping profile mandatory; families control client container mixing; substitutes activated on shortage +- [[count]] - count profile defines item counting behavior (ABC-driven cycle counts) +- [[order-inbound]] - ROR lines reference items by code or presentation alias +- [[order-outbound]] - SOR lines reference items; logistic attribute filtering drives stock assignment +- [[cutting-stock]] - cutting profile marks item as cut item; enables min/max quantities and cut label printing +- [[labels]] - item labels printed at reception, from stock view, and from RFT utilities +- [[erp-interface]] - ITM message manages item master from ERP; SAC01 sends ABC classification back to ERP +- [[kits]] - kit articles and component articles are both standard items; kit assembly consumes component stock diff --git a/wiki/concepts/putaway.md b/wiki/concepts/putaway.md index e22675f..9b26a74 100644 --- a/wiki/concepts/putaway.md +++ b/wiki/concepts/putaway.md @@ -52,10 +52,10 @@ The putaway strategy engine is the core of location search. Two complementary st Each strategy (both types) is composed of four elements: -1. **Criterion** — Conditions that the container or stock must satisfy for the strategy to be a candidate (source, container type, stock properties, item classification, etc.) -2. **Rule** — Conditions that the destination location must satisfy (location type, zone, aisle, height, mixing restrictions, etc.) -3. **Restrictions** — Mixing constraints that determine which combinations of items/attributes/owners are allowed in the same location or channel -4. **Sorting** — Preference ordering of valid locations (by distance, coordinates, fill level, item affinity, etc.) +1. **Criterion** - Conditions that the container or stock must satisfy for the strategy to be a candidate (source, container type, stock properties, item classification, etc.) +2. **Rule** - Conditions that the destination location must satisfy (location type, zone, aisle, height, mixing restrictions, etc.) +3. **Restrictions** - Mixing constraints that determine which combinations of items/attributes/owners are allowed in the same location or channel +4. **Sorting** - Preference ordering of valid locations (by distance, coordinates, fill level, item affinity, etc.) Strategies are sequenced: if criteria for strategy N are not met, strategy N+1 is evaluated. The sequence continues until a location is found or all strategies are exhausted. @@ -63,33 +63,33 @@ Strategies are sequenced: if criteria for strategy N are not met, strategy N+1 i The web UI exposes the strategy engine through two tabs : **Critères** and **Règles**. -**Sequence management.** Strategies are ordered by **sequence number** — lower = higher priority. The list view exposes **"Augmenter séquence"** / **"Diminuer séquence"** buttons to adjust priorities. The **last-sequence strategy must be a catch-all** (any item, any available location), otherwise the engine may exhaust the list and return no proposal to the operator. +**Sequence management.** Strategies are ordered by **sequence number** - lower = higher priority. The list view exposes **"Augmenter séquence"** / **"Diminuer séquence"** buttons to adjust priorities. The **last-sequence strategy must be a catch-all** (any item, any available location), otherwise the engine may exhaust the list and return no proposal to the operator. -**Onglet Critères** — "Rechercher un emplacement pour" offers : +**Onglet Critères** - "Rechercher un emplacement pour" offers : | Option | Description | |---|---| | Conteneur client | Client (outbound) containers only | | Conteneur vide | Empty containers | -| Profil de stockage | Only items with the specified putaway profile — ⚠️ *if an item has a profile, only profile-matching strategies apply to it* | +| Profil de stockage | Only items with the specified putaway profile - ⚠️ *if an item has a profile, only profile-matching strategies apply to it* | | Conteneur ou stock | Loose stock or any container | The **"Stock libre"** checkbox restricts the strategy to loose stock (containers excluded). Below, a **Stock** section filters on : stock status, supplier, ABC rotation, item type, owner, hazard codes. The **Station d'origine** block is used for robotic installations. -**Onglet Règles — "Rechercher un emplacement"** exposes two UI-specific controls not named in the pipeline above : +**Onglet Règles - "Rechercher un emplacement"** exposes two UI-specific controls not named in the pipeline above : | Parameter | Values | |---|---| | **Mode de stockage** | N'importe quel / Conteneur uniquement / Stock Libre uniquement | | **Valable si** | Emplacement vide ou avec stock / Avec stock uniquement / Canal vide uniquement / Canal avec stock uniquement | -Remaining rule fields match *Stage 6* above (rack type, specific location, X/Y coordinates, side 0=gauche/1=droite, height min/max, max weight, **Article assigné** — PDL-like assigned-location search, type/aisle, zone, min/max temperature, entrepôt annexe). +Remaining rule fields match *Stage 6* above (rack type, specific location, X/Y coordinates, side 0=gauche/1=droite, height min/max, max weight, **Article assigné** - PDL-like assigned-location search, type/aisle, zone, min/max temperature, entrepôt annexe). > Crossdocking locations live in the crossdocking sub-warehouse : if the strategy leaves `entrepôt annexe` empty, the engine considers both the main and the crossdocking sub-warehouses. -**Onglet Règles — "Appliquer restrictions"** checkboxes : `Appliquer restrictions`, `Articles combinés`, `Mélanger des conversions`, `Combiner attributs logistiques`, `Utiliser jours de mélange`, `Mélanger types de conteneurs`, `Rangement partiel de stock`. +**Onglet Règles - "Appliquer restrictions"** checkboxes : `Appliquer restrictions`, `Articles combinés`, `Mélanger des conversions`, `Combiner attributs logistiques`, `Utiliser jours de mélange`, `Mélanger types de conteneurs`, `Rangement partiel de stock`. -**Onglet Règles — "Order locations"** mirrors *Stage 7* sorting. Recommended default for manual warehouses : `Coord X ASC` (seq 1), `Coord Y ASC` (seq 2). +**Onglet Règles - "Order locations"** mirrors *Stage 7* sorting. Recommended default for manual warehouses : `Coord X ASC` (seq 1), `Coord Y ASC` (seq 2). ### Activation, Deactivation, and Editing @@ -104,7 +104,7 @@ A strategy takes effect only after explicit **activation**. To modify an existin ## Location Search Pipeline (Putaway Strategies) -### Stage 1 — Filter valid strategies by criteria +### Stage 1 - Filter valid strategies by criteria EasyWMS filters all enabled strategies for the warehouse against five criterion groups: @@ -121,7 +121,7 @@ EasyWMS filters all enabled strategies for the warehouse against five criterion **Stock criteria:** supplier, status (inbound/outbound), expired stock flag. -### Stage 2 — Obtain valid aisles +### Stage 2 - Obtain valid aisles EasyWMS selects accessible aisles reachable by route from the container/stock's current location (direct or indirect routes). For **automatic aisles**, aisles that have exceeded the configured percentage of free locations for relocation are excluded to prevent blocking outbound movements. @@ -129,7 +129,7 @@ Occupancy calculation differs by location structure: - **APS (depth control):** counts valid depths per container type vs. occupied depths - **Rack (position control):** counts valid positions per container type vs. occupied positions (considering mask blocking even for unoccupied positions that have tasks) -### Stage 3 — Aisle balancing (automatic warehouses, containers only) +### Stage 3 - Aisle balancing (automatic warehouses, containers only) When enabled via parameter `BALANCE_AISLE`, EasyWMS balances load across valid aisles using the formula: @@ -141,7 +141,7 @@ Default weights: X=5, Y=1, Z=7 (configurable with expiry date). The aisle with t For multi-reference containers, the item with the largest quantity (base UoM) is used for balancing. -### Stage 4 — Apply restrictions +### Stage 4 - Apply restrictions Location restrictions (configured globally, independent of strategies) discard candidate locations where two incompatible items/item-types would be co-located. Restrictions are applied only when the strategy rule has "Use restrictions" checked. @@ -156,7 +156,7 @@ Location restrictions (configured globally, independent of strategies) discard c Restrictions can be scoped to a specific sub-warehouse. They must be enabled and referenced in the strategy to take effect. -### Stage 5 — Filter valid locations (physical/logical checks) +### Stage 5 - Filter valid locations (physical/logical checks) From remaining candidates, EasyWMS applies a hard validity checklist: @@ -169,7 +169,7 @@ From remaining candidates, EasyWMS applies a hard validity checklist: Route validity is also checked: there must be a station route from the container/stock's current station to the candidate location's station. For equipment-based searches, maximum reachable height and work area access are additionally validated. -### Stage 6 — Apply strategy rule filters +### Stage 6 - Apply strategy rule filters The strategy rule further filters candidate locations by: @@ -194,7 +194,7 @@ The strategy rule further filters candidate locations by: Empty locations are always valid regardless of mixing configuration. -### Stage 7 — Sort locations by preferences +### Stage 7 - Sort locations by preferences Valid locations are sorted according to the strategy's configured preferences (in priority order): @@ -214,7 +214,7 @@ Valid locations are sorted according to the strategy's configured preferences (i | Proximity relocation | Move to closest location (same-aisle relocations only) | | APS3D level ↑↓ | APS3D aisle level (if APS3D module installed) | -### Stage 8 — Select optimal location and create task +### Stage 8 - Select optimal location and create task EasyWMS selects the top-ranked location and creates a **Location task** to move the container/stock there. For traced containers, the task targets the base container of the trace hierarchy. @@ -247,24 +247,24 @@ Channel strategies group equivalent containers (same type + height + stock refer ### Channel strategy configuration (SmartUI) -Channel filling strategies are set up under `Configuration → Stratégies de remplissage de canaux`. Unlike standard putaway strategies, **channel strategies are not sequenced** — the WMS picks the first eligible strategy in the list. Because of this, criteria must be narrow enough to distinguish between strategies. +Channel filling strategies are set up under `Configuration → Stratégies de remplissage de canaux`. Unlike standard putaway strategies, **channel strategies are not sequenced** - the WMS picks the first eligible strategy in the list. Because of this, criteria must be narrow enough to distinguish between strategies. -**EasyS prerequisite.** Racks must be typed as `APS`, `Push Back`, `Dynamic Push Back`, or `Multi-Compact`. Without one of these rack types, the `EmptyChannels_ForContainer` query returns nothing and channel search returns empty. Each location must also declare a **number of authorized containers** — the WMS uses this to compute channel capacity. +**EasyS prerequisite.** Racks must be typed as `APS`, `Push Back`, `Dynamic Push Back`, or `Multi-Compact`. Without one of these rack types, the `EmptyChannels_ForContainer` query returns nothing and channel search returns empty. Each location must also declare a **number of authorized containers** - the WMS uses this to compute channel capacity. **Two mandatory criteria fields:** | Field | Purpose | |---|---| -| **Postes sources à considérer** | Source stations from which a container becomes eligible. If the equipment's current station is not in this list, the strategy does not apply — even if the container otherwise matches. | +| **Postes sources à considérer** | Source stations from which a container becomes eligible. If the equipment's current station is not in this list, the strategy does not apply - even if the container otherwise matches. | | **Stations à considérer pour les supports candidats** | Buffer stations used to count containers to be placed. Example: if only `RECEPTION` is listed, the WMS searches other eligible containers at `RECEPTION` and looks for a channel with enough capacity to hold them all. | -**Rule fields** filter destination candidates: storage zones (prioritised), putaway preferences, min/max location height, total weight of candidate containers, **Utiliser l'équilibrage des allées** (boolean — reuses the aisle balance configured on standard putaway strategies). +**Rule fields** filter destination candidates: storage zones (prioritised), putaway preferences, min/max location height, total weight of candidate containers, **Utiliser l'équilibrage des allées** (boolean - reuses the aisle balance configured on standard putaway strategies). **Reservation timeout.** The **Paramétrage du temps de réservation** field sets the maximum reservation lifetime; expired reservations are dropped automatically. **Reservation view.** `Entrepôt → Réservations` shows, per reservation: originating strategy, destination location, item, owner, **remaining containers** on the reservation, PLC height type. -> ⚠️ Reservations are created **at putaway time only** — there is no background job reserving channels based on existing stock. A candidate container triggers the search and reserves a channel for itself + all buffer peers at that moment. +> ⚠️ Reservations are created **at putaway time only** - there is no background job reserving channels based on existing stock. A candidate container triggers the search and reserves a channel for itself + all buffer peers at that moment. ## Putaway Flow by Object Type @@ -293,7 +293,7 @@ Similar flow to container putaway, but: ### Cutting Stock Putaway (RFT) -Cutting stock (items sold/stored by length/stretch) requires total-quantity handling — stretches cannot be split. Three modes: +Cutting stock (items sold/stored by length/stretch) requires total-quantity handling - stretches cannot be split. Three modes: 1. **Select then locate**: choose the stretch, confirm/enter destination 2. **Guided unload**: system proposes destination for each stretch in sequence 3. **Manual unload**: enter destination to unload all equipment stock at once @@ -358,8 +358,8 @@ Strategy coverage expected per rack type (Mecalux France defaults): **Double-depth racks:** - Ascending height + Rotation + Stock balancing -- Avoid product mixing — causes relocations during picking -- Avoid logistic-attribute / quantity mixing — depends on shipping logic +- Avoid product mixing - causes relocations during picking +- Avoid logistic-attribute / quantity mixing - depends on shipping logic **>2-depth (APS) channels:** - Ascending height + Rotation + Balancing @@ -369,16 +369,16 @@ Strategy coverage expected per rack type (Mecalux France defaults): ### Empty-location headroom -**Standard value: 5%** empty locations — required for relocation work and flow variation absorption. Lower values starve the relocation and defragmentation jobs. +**Standard value: 5%** empty locations - required for relocation work and flow variation absorption. Lower values starve the relocation and defragmentation jobs. ### Double-depth layout patterns (EasyS) Two rack configurations for double-depth (TK / miniload): -- **Case #1** (most common at Mecalux France) — best for **mono-product supports**: rotation zones split by front / rear face (several supports with the same article live in the TK) -- **Case #2** — best for **multi-product supports**: reduces picking-time relocations without pre-emptive defragmentation (an item never lives in two supports at once) +- **Case #1** (most common at Mecalux France) - best for **mono-product supports**: rotation zones split by front / rear face (several supports with the same article live in the TK) +- **Case #2** - best for **multi-product supports**: reduces picking-time relocations without pre-emptive defragmentation (an item never lives in two supports at once) -Choose the pattern **before** running rotation class setup — switching costs a full re-slotting. +Choose the pattern **before** running rotation class setup - switching costs a full re-slotting. ## Parameters @@ -393,35 +393,35 @@ Choose the pattern **before** running rotation class setup — switching costs a **No valid location found (automatic warehouse):** Rejection task generated. Container goes to rejection station. Common causes: all aisles at relocation % limit, no route between current station and any candidate location, weight exceeded everywhere. -**Aisle balancing blocks putaway:** Aisle is chosen by balance formula but has no valid location (e.g., full or incompatible). System does not fall back to other aisles for that strategy — next strategy in sequence is tried instead. Ensure next strategy has adequate coverage. +**Aisle balancing blocks putaway:** Aisle is chosen by balance formula but has no valid location (e.g., full or incompatible). System does not fall back to other aisles for that strategy - next strategy in sequence is tried instead. Ensure next strategy has adequate coverage. **Container stuck in equipment:** Container loaded on equipment but operator ended session without locating. Container remains in equipment indefinitely. Resolve via manual relocation from the equipment management view. **Picking dedicated location not proposed:** Item has no PDL created yet, or PDL is for different logistic attributes. Either create a PDL for the correct attributes, or ensure strategy sequence 1 (assigned location) handles this item. -**Cutting stock putaway fails validation:** Operator entered partial quantity instead of full stretch quantity. Cutting stock requires total-quantity entry — reject partial entries at the RFT. +**Cutting stock putaway fails validation:** Operator entered partial quantity instead of full stretch quantity. Cutting stock requires total-quantity entry - reject partial entries at the RFT. ## Interface Paths | Interface | Path | |---|---| -| RFT — container/loose stock putaway | Menu "Putaway" → "Containers/Loose stock" or "Containers" | -| RFT — stock putaway | Menu "Location" → "Containers/Loose stock" or "Stocks" | -| Web — putaway strategies | "Configuration" → "Putaway strategies" | -| Web — aisle balancing | "Putaway strategies" → "Configuration" → "Aisle Balance" | -| Web — restrictions | "Configuration" → "Restrictions" | -| Web — channel filling strategies | "Configuration" → "Stratégies de remplissage de canaux" | -| Web — channel reservations | "Entrepôt" → "Réservations" | +| RFT - container/loose stock putaway | Menu "Putaway" → "Containers/Loose stock" or "Containers" | +| RFT - stock putaway | Menu "Location" → "Containers/Loose stock" or "Stocks" | +| Web - putaway strategies | "Configuration" → "Putaway strategies" | +| Web - aisle balancing | "Putaway strategies" → "Configuration" → "Aisle Balance" | +| Web - restrictions | "Configuration" → "Restrictions" | +| Web - channel filling strategies | "Configuration" → "Stratégies de remplissage de canaux" | +| Web - channel reservations | "Entrepôt" → "Réservations" | ## Related -- [Container (LPN)](container.md) — the primary object being putaway; types, lock types, and weights are key strategy criteria -- [Reception](reception.md) — putaway typically follows reception; containers can be placed directly from reception -- [Replenishment](replenishment.md) — replenishment reuses the putaway strategy engine to move stock to picking dedicated locations -- [Location](location.md) — location types (rack, APS, compact, dynamic, pushback) determine which strategy type applies -- [Stock](stock.md) — stock status and logistic attributes are criteria and restrictions in putaway strategies -- [GALILEO Integration](../architecture/galileo-integration.md) — how TMS drives physical execution of putaway tasks -- [Galileo Simulation](../operations/galileo-simulation.md) — EasyS setup for double-depth racks, PLC Types, reject routes -- [Task](task.md) — putaway generates Putaway tasks; automatic warehouse also uses Approach tasks for Pick & Pass -- [Product / Item](product-item.md) — putaway profile on the item links strategies; hazard, temperature, and ABC classification feed strategy criteria -- [Defragmentation](defragmentation.md) — rotation defragmentation reuses putaway strategies to relocate containers to their optimal ABC zone +- [Container (LPN)](container.md) - the primary object being putaway; types, lock types, and weights are key strategy criteria +- [Reception](reception.md) - putaway typically follows reception; containers can be placed directly from reception +- [Replenishment](replenishment.md) - replenishment reuses the putaway strategy engine to move stock to picking dedicated locations +- [Location](location.md) - location types (rack, APS, compact, dynamic, pushback) determine which strategy type applies +- [Stock](stock.md) - stock status and logistic attributes are criteria and restrictions in putaway strategies +- [GALILEO Integration](../architecture/galileo-integration.md) - how TMS drives physical execution of putaway tasks +- [Galileo Simulation](../operations/galileo-simulation.md) - EasyS setup for double-depth racks, PLC Types, reject routes +- [Task](task.md) - putaway generates Putaway tasks; automatic warehouse also uses Approach tasks for Pick & Pass +- [Product / Item](product-item.md) - putaway profile on the item links strategies; hazard, temperature, and ABC classification feed strategy criteria +- [Defragmentation](defragmentation.md) - rotation defragmentation reuses putaway strategies to relocate containers to their optimal ABC zone diff --git a/wiki/concepts/quality-control.md b/wiki/concepts/quality-control.md index b42ff8a..6c6b105 100644 --- a/wiki/concepts/quality-control.md +++ b/wiki/concepts/quality-control.md @@ -30,7 +30,7 @@ EasyWMS controls stock quality from reception through shipping. Statuses can be - **In the warehouse** (web interface, RFT, or ERP message) - At **shipping** (to require or prefer stock in a specific status for a shipping order line) -> **Important:** The _Expired_ state is **not** a stock status — stock expires automatically when logistic attribute dates (expiry date, best before date, end of life) are reached. +> **Important:** The _Expired_ state is **not** a stock status - stock expires automatically when logistic attribute dates (expiry date, best before date, end of life) are reached. --- @@ -48,8 +48,8 @@ Each stock status is configured to block or allow specific operations: | Internal use (manufacturing) | Yes | A single stock record can have two simultaneous statuses: -- **Receiving status** — set at reception time (from profile, order line, or operator) -- **User status** — applied manually by an operator, manager, or via ERP message +- **Receiving status** - set at reception time (from profile, order line, or operator) +- **User status** - applied manually by an operator, manager, or via ERP message --- @@ -187,7 +187,7 @@ Both partial and total locks can be performed from **RFT** or **ERP** (STR messa |---|---| | `CST.STK` | Stock status applied or removed (when reception is closed) | -Note: `CST.STK` is **not** generated if the reception is still open — changes are visible in the interface but not audited until reception closes. +Note: `CST.STK` is **not** generated if the reception is still open - changes are visible in the interface but not audited until reception closes. --- @@ -206,8 +206,8 @@ STC is only sent when the **reception is closed**. For stock from open reception - A stock can have both a **receiving status** (set at reception) and a **user status** (set manually) simultaneously. - When a lock is applied, EasyWMS immediately checks all active tasks and assignments using that stock and adapts them (cancels or decrements) based on the operations the lock blocks. -- Expired stock (`_Expired_` state) is handled by the logistic attributes expiry system — not the quality lock system. -- Only locations that allow inventory can have their stock counted. Quality locks do not change this — but locks that prevent counting block task generation. +- Expired stock (`_Expired_` state) is handled by the logistic attributes expiry system - not the quality lock system. +- Only locations that allow inventory can have their stock counted. Quality locks do not change this - but locks that prevent counting block task generation. - The 15-minute job for automatic unlock means that very short-duration locks (< 15 min) are not reliably supported. --- @@ -253,10 +253,10 @@ STC is only sent when the **reception is closed**. For stock from open reception ## Related -- [[stock]] — Quality locks are stored as stock status fields; stock must have no movement-blocking lock to be picked, replenished, or shipped -- [[container]] — Locks can be applied at container granularity; all stock in a container can be locked in one operation -- [[reception]] — Receiving status is applied at reception time via profile, order line, or operator; STC sent at close -- [[order-outbound]] — Shipping order lines can specify required/preferred stock status for assignment -- [[product-item]] — Item receiving profile defines automatic lock status and duration at inbound -- [[stock-adjustment]] — Both quality control and stock adjustment use STC/STK.ADJ transactions; quality locks affect task/assignment eligibility -- [[cutting-stock]] — Cutting stock has partial/total lock behavior; lock can propagate to cut portions +- [[stock]] - Quality locks are stored as stock status fields; stock must have no movement-blocking lock to be picked, replenished, or shipped +- [[container]] - Locks can be applied at container granularity; all stock in a container can be locked in one operation +- [[reception]] - Receiving status is applied at reception time via profile, order line, or operator; STC sent at close +- [[order-outbound]] - Shipping order lines can specify required/preferred stock status for assignment +- [[product-item]] - Item receiving profile defines automatic lock status and duration at inbound +- [[stock-adjustment]] - Both quality control and stock adjustment use STC/STK.ADJ transactions; quality locks affect task/assignment eligibility +- [[cutting-stock]] - Cutting stock has partial/total lock behavior; lock can propagate to cut portions diff --git a/wiki/concepts/reception.md b/wiki/concepts/reception.md index 4cb9701..00dc586 100644 --- a/wiki/concepts/reception.md +++ b/wiki/concepts/reception.md @@ -34,7 +34,7 @@ last_compiled: "2026-04-17" Reception is the process by which stock physically arrives at the warehouse and is formally registered in EasyWMS. Until a receipt is completed and closed, the arrived stock does not exist for any other WMS process (picking, replenishment, shipping). Reception is therefore the entry gate between the physical world and the logical warehouse state. -EasyWMS supports five distinct reception entry points — each suited to a different physical configuration and information context: **Dock** (manual, RFT-driven), **ASN** (pre-notified containers), **PIE** (automated sensor gate), **PK** (picking conveyor), and **Returns** (customer returns). All share the same fundamental structure: a **Receipt** groups received stock lines, and optionally links to a **Receipt Order** (planned) or generates one ad hoc (blind). +EasyWMS supports five distinct reception entry points - each suited to a different physical configuration and information context: **Dock** (manual, RFT-driven), **ASN** (pre-notified containers), **PIE** (automated sensor gate), **PK** (picking conveyor), and **Returns** (customer returns). All share the same fundamental structure: a **Receipt** groups received stock lines, and optionally links to a **Receipt Order** (planned) or generates one ad hoc (blind). The reception output is always a REF message to the ERP confirming what was received, and an ASO message (for pre-notified containers) or similar notification per entry point. @@ -121,7 +121,7 @@ Supports **exclusive reserve** at receipt time: stock received can be pre-reserv Unplanned stock with no prior notification or entry order. -- A receipt is automatically created (and closed at end) — transparent to the user. +- A receipt is automatically created (and closed at end) - transparent to the user. - The receipt cannot be created or edited from the WMS UI. - Supports: multi-reference LPN, single-SKU LPN (labeled/unlabeled/identical), loose stock, cutting stock. - Communicates to ERP via `REF` after blind receipt close. @@ -133,8 +133,8 @@ Unplanned stock with no prior notification or entry order. Customer-returned stock coming back to the warehouse. - Can be linked to a receipt order (if created from the web) or not (if created from RFT). -- If created from RFT: no lines initially — lines are added as stock is received. -- Date logistic attributes (expiry, shelf life) are captured but **not validated** — expired stock may be returned and must be managed after receipt. +- If created from RFT: no lines initially - lines are added as stock is received. +- Date logistic attributes (expiry, shelf life) are captured but **not validated** - expired stock may be returned and must be managed after receipt. - Supports: containers, loose stock, cutting stock, exclusive reserves. - Custom code prefix configurable: `RETURN_RECEPTION_PREFIX` @@ -180,14 +180,14 @@ Used when the ERP has pre-notified containers via `ASN` message before they phys - Web: `Warehouse > ASN LPN`, `Receiving > Receipt orders` - RFT: `Receipts > Notices` -#### DirectTransfer — inter-warehouse ASN flow +#### DirectTransfer - inter-warehouse ASN flow -When the source order is a `` shipment (cf. [concepts/order-outbound.md](../concepts/order-outbound.md#asn--directtransfer-flow)), closing the expedition at origin triggers an automatic `ASO01` message on the destination warehouse, pre-creating the incoming ASN container(s). The operator then receives them via RFT menu **Réception → Préavis** just like any other ASN container. +When the source order is a `` shipment (cf. [concepts/order-outbound.md](../concepts/order-outbound.md#asn---directtransfer-flow)), closing the expedition at origin triggers an automatic `ASO01` message on the destination warehouse, pre-creating the incoming ASN container(s). The operator then receives them via RFT menu **Réception → Préavis** just like any other ASN container. - Container deletion from SmartUI (`Entrepôt → Conteneurs ASN → Supprimer`) triggers an `ASK01` back to the ERP. -- ⚠️ The ASO/ASK messages carry **no reference to the originating shipping order or DirectTransfer header** — only the container and its stock. +- ⚠️ The ASO/ASK messages carry **no reference to the originating shipping order or DirectTransfer header** - only the container and its stock. -#### Transfer — two-warehouse ASN flow (with receipt) +#### Transfer - two-warehouse ASN flow (with receipt) Unlike `` (which bypasses reception at destination), a ``-type shipping order (`SorType = Transfer` in SOR02) **automatically creates an inbound order at destination** when expedition is confirmed at source. The destination ASN containers live on an `Asn` location in the destination warehouse. @@ -200,7 +200,7 @@ Operator flow: RFT menu **Réception → Préavis** (of the destination warehous **ERP messages generated:** - `ASO01` at each container reception -- `ROF02` at inbound order closure (contains **all** received containers — the authoritative record for Transfer receptions) +- `ROF02` at inbound order closure (contains **all** received containers - the authoritative record for Transfer receptions) - `ASK01` when closing a partially-received inbound order (to drop non-arrived containers) > ⚠️ Neither `ASO01` nor `ASK01` carries the transfer header info. For `` flows the ERP **must** consume `ROF02`. @@ -269,7 +269,7 @@ Receipts can be closed **manually** or **automatically**. ### Manual Closing -- Done from web interface or RFT at any time — full quantity not required. +- Done from web interface or RFT at any time - full quantity not required. - If linked to receipt orders and all ordered stock received → receipt order = _Completed_; else = _Partially received_. - Stock allocation across identical order lines follows: least expected qty first → oldest creation date → excess to first line allowing it. - Process: `Reception_Close_PR_V2` @@ -317,7 +317,7 @@ Receipts can be closed **manually** or **automatically**. | `ASN` | ERP → WMS | Pre-notifies containers and their stock | | `ASO` | WMS → ERP | Confirms receipt of a pre-notified container | | `ASK` | WMS → ERP | Confirms rejection of a pre-notified container | -| `REF` | WMS → ERP | Receipt close confirmation — lists all received stock | +| `REF` | WMS → ERP | Receipt close confirmation - lists all received stock | | `ROF` | WMS → ERP | Receipt order close confirmation | | `STV` | WMS → ERP | Stock adjustment in pre-notified container during review | @@ -342,7 +342,7 @@ See [concepts/labels.md](../concepts/labels.md) for complete label reference. - Cause: Order code unknown or not yet created. - Solution: Enable `ALLOW_CREATE_RECEPTION` to create a new receipt; or have the ERP send the `ROR` message first. -**ASN container rejected at PIE — order doesn't exist:** +**ASN container rejected at PIE - order doesn't exist:** - Cause: Receipt order referenced in ASN message not yet in WMS. - Solution: If `USE_EXCLUSIVE_RESERVE_STRICT_MODE` is inactive, container can still be received; reserve is formalized later. If active, resolve order absence first. @@ -350,7 +350,7 @@ See [concepts/labels.md](../concepts/labels.md) for complete label reference. - Cause: Receipt still has uncommitted lines or allows excess reception. - Solution: Close manually, or verify `AutoCloseReception` is active and no line allows over-receipt. -**Quantity discrepancy at PIE — container sent to reconditioning:** +**Quantity discrepancy at PIE - container sent to reconditioning:** - Cause: ASN pre-notified stock quantity doesn't match received stock and receipt order doesn't allow excess. - Solution: Correct the discrepancy at the reconditioning station and retry. @@ -360,13 +360,13 @@ See [concepts/labels.md](../concepts/labels.md) for complete label reference. **Return receipt rejected for expired stock:** - Cause: `RECEPTION_NUM_DAYS_PRODUCTION_DATE_MARGIN` check triggered. -- Note: Date logistic attributes are captured but expiry is **not blocked** during returns — check parameter configuration. +- Note: Date logistic attributes are captured but expiry is **not blocked** during returns - check parameter configuration. --- ## Reception Split Strategy (Mecalux France pattern) -Deployed at **ROUJE** and **NEUT** — documented from NEUT (blind reception, supplier + customer return, loose stock on equipment). When the item has a picking dedicated location (PDL), incoming stock is split at reception between two buffers so PDLs are filled to capacity directly and the overflow lands in reserve. +Deployed at **ROUJE** and **NEUT** - documented from NEUT (blind reception, supplier + customer return, loose stock on equipment). When the item has a picking dedicated location (PDL), incoming stock is split at reception between two buffers so PDLs are filled to capacity directly and the overflow lands in reserve. **Flow:** @@ -396,7 +396,7 @@ Deployed at **ROUJE** and **NEUT** — documented from NEUT (blind reception, su | 3 | PICKING buffer | Dedicated picking locations | Item assigned, destination zone = PICKING | | 4 | RESERVE buffer | Pallet rack locations | Destination zone = PALETTE | -**Split logic (custom workflow) — rules applied after stock reception:** +**Split logic (custom workflow) - rules applied after stock reception:** | Situation | Action | |---|---| @@ -408,8 +408,8 @@ Deployed at **ROUJE** and **NEUT** — documented from NEUT (blind reception, su > ⚠️ Stock dropped on the RESERVE buffer **must** be on a container (existing LPN or a newly generated code). **Customs required:** -- `Equipment_Unload_ProductUnloadOnContainer_UI` — hide the free-drop button when `location.code == "RESERVE"` -- `Equipment_Unload_ProductUnloadAllStockOnContainer_UI` — idem +- `Equipment_Unload_ProductUnloadOnContainer_UI` - hide the free-drop button when `location.code == "RESERVE"` +- `Equipment_Unload_ProductUnloadAllStockOnContainer_UI` - idem - Custom workflow after reception that computes the split and generates two drop tasks Reference implementation: [NEUT-58](https://easywmsfrance.atlassian.net/browse/NEUT-58). @@ -435,12 +435,12 @@ Reference implementation: [NEUT-58](https://easywmsfrance.atlassian.net/browse/N ## Related -- [concepts/container.md](../concepts/container.md) — LPN structure, statuses, ASN pre-notification -- [concepts/order-inbound.md](../concepts/order-inbound.md) — Receipt orders (ROR message), inbound lifecycle -- [concepts/putaway.md](../concepts/putaway.md) — What happens after stock is received -- [concepts/stock.md](../concepts/stock.md) — Stock records created during reception -- [concepts/product-item.md](../concepts/product-item.md) — Item reception profiles, logistic attributes captured at receipt -- [concepts/quality-control.md](../concepts/quality-control.md) — Incoming stock quality locks -- [concepts/labels.md](../concepts/labels.md) — LPN and item labels at reception -- [concepts/erp-interface.md](../concepts/erp-interface.md) — ROR, ASN, ASO, ASK, REF, ROF message definitions -- [concepts/transactions.md](../concepts/transactions.md) — CON.RECEP, STK.RECEP, CON.ASN.001, REC.CLS +- [concepts/container.md](../concepts/container.md) - LPN structure, statuses, ASN pre-notification +- [concepts/order-inbound.md](../concepts/order-inbound.md) - Receipt orders (ROR message), inbound lifecycle +- [concepts/putaway.md](../concepts/putaway.md) - What happens after stock is received +- [concepts/stock.md](../concepts/stock.md) - Stock records created during reception +- [concepts/product-item.md](../concepts/product-item.md) - Item reception profiles, logistic attributes captured at receipt +- [concepts/quality-control.md](../concepts/quality-control.md) - Incoming stock quality locks +- [concepts/labels.md](../concepts/labels.md) - LPN and item labels at reception +- [concepts/erp-interface.md](../concepts/erp-interface.md) - ROR, ASN, ASO, ASK, REF, ROF message definitions +- [concepts/transactions.md](../concepts/transactions.md) - CON.RECEP, STK.RECEP, CON.ASN.001, REC.CLS diff --git a/wiki/concepts/replenishment.md b/wiki/concepts/replenishment.md index 6b6162a..6f43f5a 100644 --- a/wiki/concepts/replenishment.md +++ b/wiki/concepts/replenishment.md @@ -26,13 +26,13 @@ last_compiled: "2026-04-17" ## Overview -Replenishment is the process of moving stock from bulk storage locations to **picking dedicated locations (PDL)** to ensure that operators always have stock available to fulfill shipping orders without going to the main rack. It is a supporting process that feeds the picking operation — without replenishment, picking dedicated locations would run dry and order preparation would stall. +Replenishment is the process of moving stock from bulk storage locations to **picking dedicated locations (PDL)** to ensure that operators always have stock available to fulfill shipping orders without going to the main rack. It is a supporting process that feeds the picking operation - without replenishment, picking dedicated locations would run dry and order preparation would stall. A **picking dedicated location (PDL)** is a location permanently or dynamically assigned to one item (sometimes one item per partition). PDLs are configured with a minimum (replenishment threshold) and maximum (capacity). When stock in the PDL drops below the minimum, the replenishment system detects the shortage and generates a replenishment task to refill from a source location. Replenishment in EasyWMS operates at two levels: -1. **PDL replenishment** — refilling picking dedicated locations from bulk storage -2. **Sub-warehouse replenishment** — moving stock from one sub-warehouse to another to balance inventory +1. **PDL replenishment** - refilling picking dedicated locations from bulk storage +2. **Sub-warehouse replenishment** - moving stock from one sub-warehouse to another to balance inventory ## Picking Dedicated Locations (PDL) @@ -45,15 +45,15 @@ A PDL is a location with an item assignment that designates it as the primary pi | **Location** | Must have: allow item assignment, allow picking, allow replenish, allow putaway | | **Item** | One item recommended per PDL (multiple items allowed but not typical) | | **Owner** | Owner of the item | -| **Replenishment mode** | Container (move whole container) or Stock (move loose stock) — cannot mix both | +| **Replenishment mode** | Container (move whole container) or Stock (move loose stock) - cannot mix both | | **Conversion** | Unit of measure in which replenishment level and capacity are expressed | -| **Logistic attributes** | Specific batch, color, quality, etc. — PDL will be replenished with matching stock only | +| **Logistic attributes** | Specific batch, color, quality, etc. - PDL will be replenished with matching stock only | | **Maximum lots** | Limit how many different lots can be present in the PDL simultaneously | | **Expired stock flag** | PDL can be configured to receive only expired stock | | **Days of life** | Replenish with stock whose shelf life ≥ (detection date + days of life) | | **Stock status** | Restrict to stock in a specific status | -**For stock-mode PDLs — threshold types:** +**For stock-mode PDLs - threshold types:** | Threshold type | Description | Notes | |---------------|-------------|-------| @@ -68,15 +68,15 @@ A PDL is a location with an item assignment that designates it as the primary pi - **Maximum containers**: capacity ceiling - **Replenishment level %** (if max = 1): percentage of full-container quantity below which replenishment is triggered; allows exceeding the full quantity to absorb the incoming container's excess stock -### PDL — EasyS / SmartUI Configuration +### PDL - EasyS / SmartUI Configuration -**EasyS — Location setup**, check : +**EasyS - Location setup**, check : - `Allow product location` - `Allow replenish at source` - `Allow picking` -**SmartUI — `Entrepôt → Emplacements consacrés au picking`** : +**SmartUI - `Entrepôt → Emplacements consacrés au picking`** : - Enter the **replenishment level** (minimum threshold) - Enter the **maximum capacity** @@ -84,13 +84,13 @@ A PDL is a location with an item assignment that designates it as the primary pi - Enter a **Texte personnalisé** (custom label) - Print the PDL barcodes -> 💡 Labels display as `Code emplacement [Label]` (e.g. `B-1-4 [Clavier M]`). With many PDLs this is hard to scan through — Mecalux France standard is to **prefix labels with an ordered code** (e.g. `B-1-4 [01 Clavier M]`, `B-1-4 [02 Clavier L]`...) so the operator can sort them visually. +> 💡 Labels display as `Code emplacement [Label]` (e.g. `B-1-4 [Clavier M]`). With many PDLs this is hard to scan through - Mecalux France standard is to **prefix labels with an ordered code** (e.g. `B-1-4 [01 Clavier M]`, `B-1-4 [02 Clavier L]`...) so the operator can sort them visually. > ⚠️ **Known limitations** documented by Mecalux France (2022 tests) : > - The **destination is not displayed** when the WMS generates putaway tasks towards a PDL. -> - **Maximum capacity is not strictly enforced** at putaway — cases of 26 units put away in a capacity-15 PDL have been observed. Rely on replenishment threshold + periodic count rather than `max capacity` as a hard limit. +> - **Maximum capacity is not strictly enforced** at putaway - cases of 26 units put away in a capacity-15 PDL have been observed. Rely on replenishment threshold + periodic count rather than `max capacity` as a hard limit. > -> Positive : **minimum-threshold replenishment works correctly** — a task is generated to top the PDL back up to its maximum once the minimum is crossed. +> Positive : **minimum-threshold replenishment works correctly** - a task is generated to top the PDL back up to its maximum once the minimum is crossed. ### PDL Creation Methods @@ -99,16 +99,16 @@ A PDL is a location with an item assignment that designates it as the primary pi | Web interface | Warehouse manager manually creates PDL assignments | | RFT during putaway | Operator assigns item to location while unloading (if `UNLOAD_CREATE_PRODUCT_LOCATION` enabled) | | RFT during counting | Item assigned during stock count (if `UNLOAD_CREATE_PRODUCT_LOCATION` and `REPLENISH_LEVEL_PERCENT_PRODUCT_LOCATION` enabled) | -| RFT — "Assign item to loc." | Dedicated menu option in Utilities | +| RFT - "Assign item to loc." | Dedicated menu option in Utilities | | Automatically (dynamic replenishment) | System creates PDL on-the-fly for items in active shipping orders | ### PDL Partitions -A single physical location can be subdivided into **partitions** — labeled divisions each assigned to a different item. This enables high-density picking areas (drawers, shelves divided by bins). +A single physical location can be subdivided into **partitions** - labeled divisions each assigned to a different item. This enables high-density picking areas (drawers, shelves divided by bins). Key partition rules: - Each partition is identified by a unique QR label (code unique within the location) -- A partition is NOT a separate location — stock belongs to the location; the partition identifies which item occupies which physical space +- A partition is NOT a separate location - stock belongs to the location; the partition identifies which item occupies which physical space - One partition can be shared across multiple items; one item can use multiple partitions - A partition can be marked **full** to prevent further putaway to that partition - **Maximum partitions per item**: configurable limit to prevent one item from monopolizing a location's partitions @@ -133,7 +133,7 @@ Mecalux France uses three shortcut names that map to the strategy types below: | FR label | Type below | Trigger | Typical usage | |---|---|---|---| -| **"Routine"** | Stockout (automatic) | `TryToReplenishProductLocations` job every 1–2 min | Default — refill PDL when stock drops under the minimum | +| **"Routine"** | Stockout (automatic) | `TryToReplenishProductLocations` job every 1–2 min | Default - refill PDL when stock drops under the minimum | | **"Conclure"** | Particular demand (top-off) | RFT menu **Réapprovisionnement** or SmartUI "Réapprovisionner maintenant" on the PDL view | Operator-triggered, high-priority replenishment | | **"Exiger"** | Shipping demand (dynamic) | Order released with dynamic replenishment, or static flag `` on ROR | Create PDLs on the fly for items in released orders; also tops up when stock ≥ min but < order need | @@ -142,14 +142,14 @@ Mecalux France uses three shortcut names that map to the strategy types below: - Reserve (source) locations: `Allow replenish at source` **SmartUI configuration checklist (routine, conclure, exiger):** -1. `Entrepôt → Gestion des emplacements picking` — create PDL assignments, set **min threshold** (per container: tick "Réapprovisionnement de conteneur", or in base UoM) and **max capacity** +1. `Entrepôt → Gestion des emplacements picking` - create PDL assignments, set **min threshold** (per container: tick "Réapprovisionnement de conteneur", or in base UoM) and **max capacity** 2. Activate automatic replenishment on the PDL (for routine) -3. `Configuration → Stratégie de réapprovisionnement` — create the strategy; pick filters (item, owner, item type, sub-warehouse, destination zone) and a **Mode efficacité** (see table below) +3. `Configuration → Stratégie de réapprovisionnement` - create the strategy; pick filters (item, owner, item type, sub-warehouse, destination zone) and a **Mode efficacité** (see table below) 4. **Activate** the strategy (to edit it later, deactivate first) -5. `Configuration → Processus` — ensure `TryToReplenishProductLocations` is enabled and runs on a 1–2 min cycle +5. `Configuration → Processus` - ensure `TryToReplenishProductLocations` is enabled and runs on a 1–2 min cycle 6. Confirm source stock is eligible (no blocking status, no location lock, not already assigned to shipping) -### Efficiency mode — SmartUI values +### Efficiency mode - SmartUI values | FR field | Behaviour | |---|---| @@ -228,7 +228,7 @@ Strategies are sequenced to determine which sub-warehouses are replenished first ### 4b. Priority Location Replenishment -A fifth strategy type refills **priority locations** — locations associated with a PDL from which the PDL is replenished. This allows a two-tier system: primary storage → priority location → PDL. +A fifth strategy type refills **priority locations** - locations associated with a PDL from which the PDL is replenished. This allows a two-tier system: primary storage → priority location → PDL. ## Efficiency Modes @@ -280,7 +280,7 @@ Dynamic replenishment runs periodically (or on manual trigger) and follows this ## Dynamic Picking Emptying Tasks (Vidage) -Dynamic PDLs created by the shipping demand strategy are temporary — they exist only for the duration of the order they were created for. Once the order is shipped, the dynamic PDL may still contain leftover stock that should be returned to bulk storage. +Dynamic PDLs created by the shipping demand strategy are temporary - they exist only for the duration of the order they were created for. Once the order is shipped, the dynamic PDL may still contain leftover stock that should be returned to bulk storage. **Emptying tasks (vidage)** are generated automatically on a schedule to clear unused dynamic picking locations: - The system identifies dynamic PDLs whose associated shipping orders are complete (shipped or cancelled) @@ -326,21 +326,21 @@ When a single equipment cannot traverse from the reserve sub-warehouse to the pi ### Typical setup -- **Sub-warehouse A** (`WHST_ANCIEN_BAT`) — PDLs to replenish -- **Sub-warehouse B** (`WHST_TOUR`) — high reserves +- **Sub-warehouse A** (`WHST_ANCIEN_BAT`) - PDLs to replenish +- **Sub-warehouse B** (`WHST_TOUR`) - high reserves - Equipment `CACES06` (only one certified for height) is **forbidden** in sub-warehouse A ### Key configuration points | Element | Requirement | |---|---| -| Automation element | Type **"Transport"** — mandatory even in 100% manual warehouses | -| Transport sub-location | Type **"Buffer"** (⚠️ defaults to "Automatic" when created — change manually); sub-warehouse accessible from both equipment types | +| Automation element | Type **"Transport"** - mandatory even in 100% manual warehouses | +| Transport sub-location | Type **"Buffer"** (⚠️ defaults to "Automatic" when created - change manually); sub-warehouse accessible from both equipment types | | Equipment types | `PICKING` (access work zones of picking + both sub-warehouses) and `RESERVE` (access reserve work zone + sub-WH B only) | | Equipment groups | Two groups, one per equipment type | | Routes | Transport → sub-WH A ; each group → Transport ; `EqGroup PICKING` → both sub-warehouses ; `EqGroup RESERVE` → sub-WH B only | -> ⚠️ Routes are created by default with the **"Galileo"** transport — switch them to **"RF"** manually. +> ⚠️ Routes are created by default with the **"Galileo"** transport - switch them to **"RF"** manually. ### Flow @@ -348,7 +348,7 @@ When a single equipment cannot traverse from the reserve sub-warehouse to the pi 2. The reserve equipment (e.g. `CACES06`) picks up the support and drops it on the **intermediate Buffer location** 3. The picking equipment (e.g. `PIK01`) picks up the task from **Tâches → Tâches de réapprovisionnement** and drops the stock on the destination PDL -> Troubleshooting — "support n'existe pas" when scanning the buffer location: verify that the transit sub-location is of type **"Buffer"** (not "Automatic"). +> Troubleshooting - "support n'existe pas" when scanning the buffer location: verify that the transit sub-location is of type **"Buffer"** (not "Automatic"). Upstream MSSCC documentation: `replenishments/intermediate_stations.md` and `EasyS/configurations/IntermediateET/index.md`. @@ -380,23 +380,23 @@ In automatic warehouses, the picking conveyor (PK) generates demand that drives | Interface | Path | |---|---| -| Web — replenishment strategies | "Configuration" → "Replenishment strategies" | -| Web — sub-WH replenishment strategies | "Configuration" → "Replenishment strategies between sub-warehouses" | -| Web — picking dedicated locations | "Warehouse" → "Picking dedicated locations" | -| Web — enable/disable automatic replenishment | "Warehouse" → "Picking dedicated locations" → "Enable replenishments" | -| Web — delete when empty | "Warehouse" → "Picking dedicated locations" → "Delete when empty" | -| Web — label printing | "Warehouse" → "Picking dedicated locations" → label action | -| Web — shipping demand replenishment | "Shipping" → "Shipping orders" → "Enable replenishment" | -| RFT — particular demand replenishment | Menu "Replenishment" → specific location/aisle | -| RFT — shipping order demand | Menu "Replenishment" → "For shipping orders" | -| RFT — assign item to location | Menu "Utilities" → "Assign item to loc." | -| Web — automatic job | "Control" → "Jobs" → TryToReplenishProductLocations | +| Web - replenishment strategies | "Configuration" → "Replenishment strategies" | +| Web - sub-WH replenishment strategies | "Configuration" → "Replenishment strategies between sub-warehouses" | +| Web - picking dedicated locations | "Warehouse" → "Picking dedicated locations" | +| Web - enable/disable automatic replenishment | "Warehouse" → "Picking dedicated locations" → "Enable replenishments" | +| Web - delete when empty | "Warehouse" → "Picking dedicated locations" → "Delete when empty" | +| Web - label printing | "Warehouse" → "Picking dedicated locations" → label action | +| Web - shipping demand replenishment | "Shipping" → "Shipping orders" → "Enable replenishment" | +| RFT - particular demand replenishment | Menu "Replenishment" → specific location/aisle | +| RFT - shipping order demand | Menu "Replenishment" → "For shipping orders" | +| RFT - assign item to location | Menu "Utilities" → "Assign item to loc." | +| Web - automatic job | "Control" → "Jobs" → TryToReplenishProductLocations | ## Related -- [Picking](picking.md) — replenishment feeds PDLs that picking tasks consume; PDL stock assignment depends on replenishment being current -- [Putaway](putaway.md) — putaway engine checks PDLs first and can auto-create PDL assignments during container placement -- [Stock](stock.md) — stock status and logistic attributes are key criteria for replenishment eligibility -- [Container (LPN)](container.md) — container-mode PDLs replenish by moving whole containers; source containers must allow replenishment -- [Task](task.md) — replenishment generates Container replenishment or Stock replenishment tasks; also Picking tasks for inter-sub-warehouse replenishment -- [Location](location.md) — PDLs are locations with item assignment; "Allow replenishment source/target" logics control eligibility +- [Picking](picking.md) - replenishment feeds PDLs that picking tasks consume; PDL stock assignment depends on replenishment being current +- [Putaway](putaway.md) - putaway engine checks PDLs first and can auto-create PDL assignments during container placement +- [Stock](stock.md) - stock status and logistic attributes are key criteria for replenishment eligibility +- [Container (LPN)](container.md) - container-mode PDLs replenish by moving whole containers; source containers must allow replenishment +- [Task](task.md) - replenishment generates Container replenishment or Stock replenishment tasks; also Picking tasks for inter-sub-warehouse replenishment +- [Location](location.md) - PDLs are locations with item assignment; "Allow replenishment source/target" logics control eligibility diff --git a/wiki/concepts/shipping.md b/wiki/concepts/shipping.md index 038646b..0aef919 100644 --- a/wiki/concepts/shipping.md +++ b/wiki/concepts/shipping.md @@ -47,7 +47,7 @@ last_compiled: "2026-04-17" ## Overview -Shipping is the end-to-end process of fulfilling customer orders: from order receipt through stock assignment, preparation (picking or container shipping), consolidation, truck loading, and closure. EasyWMS represents outbound work through **shipping orders** — the central document linking customer demand to warehouse operations. +Shipping is the end-to-end process of fulfilling customer orders: from order receipt through stock assignment, preparation (picking or container shipping), consolidation, truck loading, and closure. EasyWMS represents outbound work through **shipping orders** - the central document linking customer demand to warehouse operations. Shipping orders typically arrive from the ERP via `SOR` messages but can be created manually from the web interface. For the canonical shipping order lifecycle and all statuses (Waiting, Reserved, Released, In Preparation, Paused, Closed/Archived, etc.) see [Outbound Order](order-outbound.md). @@ -119,7 +119,7 @@ Release can be: **ERP message sent:** `SOC` (order status change) **Transaction recorded:** `OUT.CST` -**Parameter:** `MAX_AUTORELEASED_OUTBOUNDORDERS` — maximum orders auto-released simultaneously +**Parameter:** `MAX_AUTORELEASED_OUTBOUNDORDERS` - maximum orders auto-released simultaneously ### Release by Sub-warehouse @@ -140,7 +140,7 @@ Multiple shipping orders are picked together (same picking path). After picking, ### Fusions -Multiple shipping orders are shipped together without ungrouping — typically for orders going to the same customer. Picked stock can be placed in shared containers without redistribution. +Multiple shipping orders are shipped together without ungrouping - typically for orders going to the same customer. Picked stock can be placed in shared containers without redistribution. ### Waves @@ -177,17 +177,17 @@ A stock-assignment strategy and/or a prepackaging strategy can be attached to th **Per-type tabs** : - **Picking d'ordres groupés** : grouping criteria (carrier, mono-ligne, mono-unité, critère personnalisé), group size (max orders / lines / volume), filters (stock rangé, crossdocking, UdM, critère perso), ungrouping (UAP + packing buffer), minimum conditions (min qty, min orders). -- **Vague de picking** : carrier + critère perso ; max orders, volume, UdM, min orders. Checkbox **"Generate tasks on release"** — if set, tasks are created when the wave is released ; otherwise at operator pickup time. +- **Vague de picking** : carrier + critère perso ; max orders, volume, UdM, min orders. Checkbox **"Generate tasks on release"** - if set, tasks are created when the wave is released ; otherwise at operator pickup time. - **Picking d'ordre** : for single-order templates. Filters on UdM + critère perso only. **Scheduler.** Templates can run between two hours on selected weekdays, with a configurable interval in minutes. Two daily windows (e.g. 9–10h and 15–16h) require **duplicating** the template. -**Criteria** are mandatory (at least one per template). Each criterion rejects orders that don't match — two tabs are available : +**Criteria** are mandatory (at least one per template). Each criterion rejects orders that don't match - two tabs are available : - **Ordre d'expédition** : Code, Description, Type (`Customer`, `Transfer`, `DirectTransfer`, `Fabrication`, `Manuel`, `Retour`…), Class, Owner, Mono-ligne, Mono-unité, Follow sequence, Auto-release, Carrier, Transport type, N hours before release/loading, N hours late, Country/City/Postal code. - **Ligne d'ordre d'expédition** : item type, item family, danger, stackability, voluminous, single parcel. -**Critère personnalisé — LINQ syntax** : +**Critère personnalisé - LINQ syntax** : ```csharp // Criterion on the outbound order itself (ex: orders imported with source = "WEB") @@ -227,10 +227,10 @@ Typical need: order prepared from multiple origins (manual + automatic aisles, d 3. Empty source containers are deleted if configured; task cancellation follows **Transactions:** -- `CON.CREATE` — new consolidation container created -- `STK.MOVE` — stock moved from source to destination -- `CON.DELETE` — empty source container deleted -- `TSK.CANCEL` — tasks for deleted container canceled +- `CON.CREATE` - new consolidation container created +- `STK.MOVE` - stock moved from source to destination +- `CON.DELETE` - empty source container deleted +- `TSK.CANCEL` - tasks for deleted container canceled HPKS (laser pick-term tray) illuminates the destination division for easy identification. @@ -262,7 +262,7 @@ When route sequencing is planned by a TMS, the ERP sends a **`RUT` file** instea Operational flow : -1. **Integrate the RUT file.** Orders appear in the orders view but must be handled from the **routes view** — releasing them individually is not the nominal path. +1. **Integrate the RUT file.** Orders appear in the orders view but must be handled from the **routes view** - releasing them individually is not the nominal path. 2. **Launch the route** → each order is auto-released with its stock assignment. 3. **Prepare the orders** in any convenient internal order. 4. **Create a truck load** and attach it to the route. A template can create the load automatically at route release. @@ -300,14 +300,14 @@ Loads represent a physical transport vehicle (truck, van) that will carry one or ### Multi-zone Loading (Virtual Dock) -Warehouses with multiple storage/preparation areas can use a **virtual dock** — a common dock reference for all zones. Carriers collect stock from different physical zones, but all are referenced to the same virtual dock for tracking purposes. +Warehouses with multiple storage/preparation areas can use a **virtual dock** - a common dock reference for all zones. Carriers collect stock from different physical zones, but all are referenced to the same virtual dock for tracking purposes. -### Truck Loading — SmartUI configuration reference (Mecalux France) +### Truck Loading - SmartUI configuration reference (Mecalux France) Standard EasyWMS exposes two truck-loading modes at dock level : -- **No buffer** — order auto-ships as soon as it lands on the dock -- **Buffer + dock** — an intermediate control step validates pallets against the load before shipment +- **No buffer** - order auto-ships as soon as it lands on the dock +- **Buffer + dock** - an intermediate control step validates pallets against the load before shipment **Load creation modes (per order type: unitary, route, group, merged, wave, by carrier):** @@ -316,12 +316,12 @@ Standard EasyWMS exposes two truck-loading modes at dock level : | **Automatic (planned)** | Load created at order release; strict container control (scanning a container from another order raises an error) | | **Non planifié** | Load created at release; **no container control** | | **Manuel (planned)** | Load created manually; strict container control | -| RFT — manual, no control | Created from RFT; no container control (indicative only) | -| RFT — from a route | Load tied to an existing route | +| RFT - manual, no control | Created from RFT; no container control (indicative only) | +| RFT - from a route | Load tied to an existing route | EasyS minimum: **one buffer + one dock** per dock used. The buffer can be carried in `` on SOR02, or assigned manually via SmartUI **Ordres de sortie → "Assigner quai/poumon"**. -**SmartUI — Configuration → Chargements:** +**SmartUI - Configuration → Chargements:** | Option | Effect | |---|---| @@ -332,24 +332,24 @@ EasyS minimum: **one buffer + one dock** per dock used. The buffer can be carrie | Quantity validation | Same semantics as picking | | **Allow load of all stock** | Adds a RFT button to load all free stock in one action | -**RFT — create a load from the floor:** `Ordres de sortie → Chargement camion → Charger les conteneurs → Nouveau`. To **disable** this path, set every order-type mode to something other than "Non planifiée". As soon as one type is "Non planifiée", operators can create loads from RFT. +**RFT - create a load from the floor:** `Ordres de sortie → Chargement camion → Charger les conteneurs → Nouveau`. To **disable** this path, set every order-type mode to something other than "Non planifiée". As soon as one type is "Non planifiée", operators can create loads from RFT. -**RFT — execute a load (`EasyWMS.TruckLoad_GetLoads_UI`):** +**RFT - execute a load (`EasyWMS.TruckLoad_GetLoads_UI`):** 1. `Ordres de sortie → Chargement camion → Charger les conteneurs` 2. Filter by dock/buffer or by load 3. Select the load (status `Ready to load` if the whole order is prepared) -4. Scan pallets — button **"Conteneur"** lists remaining containers ; **"Effectuer"** closes the load even if pallets are missing +4. Scan pallets - button **"Conteneur"** lists remaining containers ; **"Effectuer"** closes the load even if pallets are missing > ℹ️ During loading the load status reads **"Loading"** (red on RFT). -**Delivery-note printing at load close:** when the BL is configured to print on order close, **closing the truck load triggers the print** — including for a partial close. On a two-step load (remainder), the BL is printed at each close and always covers **all shipped lines of the order**. +**Delivery-note printing at load close:** when the BL is configured to print on order close, **closing the truck load triggers the print** - including for a partial close. On a two-step load (remainder), the BL is printed at each close and always covers **all shipped lines of the order**. **Truck unloading (RFT):** menu `Décharger les conteneurs` → scan the container → scan the drop-off location (default: the end-of-preparation buffer). ### Order Merge vs Load -Truck loading handles **loads** — merging happens **before** load creation on the shipping orders themselves. A merged order behaves as a single order when assigning a load, but ERP traceability remains per-original-order (see [Outbound Order → Merge](order-outbound.md#merge-order-fusion)). +Truck loading handles **loads** - merging happens **before** load creation on the shipping orders themselves. A merged order behaves as a single order when assigning a load, but ERP traceability remains per-original-order (see [Outbound Order → Merge](order-outbound.md#merge-order-fusion)). ## Truck Loading (RFT Process) @@ -378,7 +378,7 @@ Operators at the dock register each item loaded using the RFT: - Auto-close: last item loaded triggers close process (seal registration, report collection) - Partial close: configured to allow closing without all units loaded -## PS Groups (Automatic Warehouse — Outbound Conveyors) +## PS Groups (Automatic Warehouse - Outbound Conveyors) PS (Pallet Shuttle or outbound conveyor) groups are logical groupings of outbound conveyors in automatic warehouses. Each group configures which PS stations belong to it and how they are filled (criteria for which PS station gets the next container). @@ -451,25 +451,25 @@ Multiple shipping orders can be merged into the same client container if they me | Interface | Path | |---|---| -| Web — shipping orders | Menu "Shippings" → "Shipping orders" | -| Web — routes | Menu "Shippings" → "Routes" | -| Web — loads | Menu "Shippings" → "Loads" | -| Web — waves | Menu "Shippings" → "Waves" | -| Web — groups/fusions | Menu "Shippings" → "Groups" | -| Web — shipping templates | Menu "Configuration" → "Shipping templates" | -| Web — PS groups | Menu "Control" → "PS groups" | -| RFT — truck loading | Menu "Shipping" → "Load truck" | -| RFT — consolidation | Menu "Shipping orders" → "Packaging" | +| Web - shipping orders | Menu "Shippings" → "Shipping orders" | +| Web - routes | Menu "Shippings" → "Routes" | +| Web - loads | Menu "Shippings" → "Loads" | +| Web - waves | Menu "Shippings" → "Waves" | +| Web - groups/fusions | Menu "Shippings" → "Groups" | +| Web - shipping templates | Menu "Configuration" → "Shipping templates" | +| Web - PS groups | Menu "Control" → "PS groups" | +| RFT - truck loading | Menu "Shipping" → "Load truck" | +| RFT - consolidation | Menu "Shipping orders" → "Packaging" | ## Related -- [Picking](picking.md) — picking is the core preparation activity within the shipping process -- [Replenishment](replenishment.md) — picking dedicated locations are replenished when stock runs out during order preparation -- [Container (LPN)](container.md) — containers are the main unit tracked through shipping, loading, and delivery -- [Crossdocking](crossdocking.md) — some shipping orders can bypass storage through crossdocking -- [Reception](reception.md) — inbound stock feeds the inventory that shipping orders consume -- [Outbound Order](order-outbound.md) — shipping orders (SOR/SOF/SOC) drive the entire shipping process; order type determines destination and process -- [Task](task.md) — shipping generates Shipping and Loading tasks; task priority inherits from order priority -- [[cutting-stock]] — cutting stock has special shipping profile requirements (excess %, enter quantity mode = Manually) -- [[stations]] — Dock (type 34), Stage (type 33), PS (type 4), Consolidation (type 17) stations are central to shipping -- [Prepackaging](prepackaging.md) — dedicated page for prepackaging strategy configuration, ERP (SOR02) payload, and tested behaviors +- [Picking](picking.md) - picking is the core preparation activity within the shipping process +- [Replenishment](replenishment.md) - picking dedicated locations are replenished when stock runs out during order preparation +- [Container (LPN)](container.md) - containers are the main unit tracked through shipping, loading, and delivery +- [Crossdocking](crossdocking.md) - some shipping orders can bypass storage through crossdocking +- [Reception](reception.md) - inbound stock feeds the inventory that shipping orders consume +- [Outbound Order](order-outbound.md) - shipping orders (SOR/SOF/SOC) drive the entire shipping process; order type determines destination and process +- [Task](task.md) - shipping generates Shipping and Loading tasks; task priority inherits from order priority +- [[cutting-stock]] - cutting stock has special shipping profile requirements (excess %, enter quantity mode = Manually) +- [[stations]] - Dock (type 34), Stage (type 33), PS (type 4), Consolidation (type 17) stations are central to shipping +- [Prepackaging](prepackaging.md) - dedicated page for prepackaging strategy configuration, ERP (SOR02) payload, and tested behaviors diff --git a/wiki/concepts/stations.md b/wiki/concepts/stations.md index fa97748..2a38fcb 100644 --- a/wiki/concepts/stations.md +++ b/wiki/concepts/stations.md @@ -72,16 +72,16 @@ Easy WMS defines 37+ standard station types. Types are identified by a numeric c | Code | Type | Name | Description | |------|------|------|-------------| -| 0 | ALM | Warehouse | Set of storage locations (shelves, ground locations, any storage element). Not connected to TMS — no machine communication. Involved in: location (destination), extraction (source), transfer (source+destination). Can be configured to allow/deny inbounds or outbounds independently. | +| 0 | ALM | Warehouse | Set of storage locations (shelves, ground locations, any storage element). Not connected to TMS - no machine communication. Involved in: location (destination), extraction (source), transfer (source+destination). Can be configured to allow/deny inbounds or outbounds independently. | ### Inbound / Conveyor Stations (AS/RS) | Code | Type | Name | Description | |------|------|------|-------------| | 3 | PIE | Pallet Check Unit | Dimensional + identification control of containers. TMS sends height, weight, status, and label data to Easy WMS. Easy WMS validates and routes: correct → warehouse; wrong → REAC/RECH. All stations with a gauge arch or scale must be configured as PIE. PIE events evaluate flags: 65536=correct, 256=barcode error, 512=recovered container, 1024/66560=correct+empty, 3=holes+studs, 4=overheight, 8–64=overhangs, 128=weight excess. | -| 9 | ME | Aisle Inbound Conveyor | Interchange point with AS/RS (TRASLO). Final optimization before container enters the machine. Checks stacker crane characteristics (number of extractors, conveyors). If container arrives at ME with both putaway and picking tasks, putaway is cancelled and container goes to picking. Final location decision point — refines but doesn't replace initial search. Required in all automatic warehouses with stacker cranes. | -| 10 | MS | Outbound Conveyor | AS/RS unload point — where the machine unloads an extracted container onto the conveyor. Not mandatory (in Galileo IV the location is freed at AS/RS loading), but recommended for additional control, ring saturation prevention, and movement statistics. Taskless containers (order cancelled) return to vault. | -| 11 | MU | Putaway Conveyor | Searches for a putaway location by applying configured strategies. Only acts on containers without tasks or containers whose destination task points to this station. Useful when PIE is far from the warehouse — PIE skips location search, MU refines it just before warehouse entry. If problem generating movement: movement generated with origin=destination, flagged "With conflict"; cleared when possible. | +| 9 | ME | Aisle Inbound Conveyor | Interchange point with AS/RS (TRASLO). Final optimization before container enters the machine. Checks stacker crane characteristics (number of extractors, conveyors). If container arrives at ME with both putaway and picking tasks, putaway is cancelled and container goes to picking. Final location decision point - refines but doesn't replace initial search. Required in all automatic warehouses with stacker cranes. | +| 10 | MS | Outbound Conveyor | AS/RS unload point - where the machine unloads an extracted container onto the conveyor. Not mandatory (in Galileo IV the location is freed at AS/RS loading), but recommended for additional control, ring saturation prevention, and movement statistics. Taskless containers (order cancelled) return to vault. | +| 11 | MU | Putaway Conveyor | Searches for a putaway location by applying configured strategies. Only acts on containers without tasks or containers whose destination task points to this station. Useful when PIE is far from the warehouse - PIE skips location search, MU refines it just before warehouse entry. If problem generating movement: movement generated with origin=destination, flagged "With conflict"; cleared when possible. | | 13 | APL | Stacker / Unstacker | Handles stacking and unstacking operations for empty containers. | | 14 | LANZ | Shuttle | Shuttle station for Pallet Shuttle operations. | | 18 | PKE | PK Inbound Conveyor | Entry to the picking inbound conveyor. | @@ -91,15 +91,15 @@ Easy WMS defines 37+ standard station types. Types are identified by a numeric c | Code | Type | Name | Description | |------|------|------|-------------| -| 1 | TRASLO | AS/RS | Automated Storage/Retrieval System — the crane or machine. Bidirectional: loads from ME (inbound), unloads into MS (outbound). Communication via protocol (Galileo IV supports loading event + location release simultaneously). | +| 1 | TRASLO | AS/RS | Automated Storage/Retrieval System - the crane or machine. Bidirectional: loads from ME (inbound), unloads into MS (outbound). Communication via protocol (Galileo IV supports loading event + location release simultaneously). | ### Picking Stations | Code | Type | Name | Description | |------|------|------|-------------| | 2 | PK | Picking Conveyor | Managed from the "Picking" view. Operator is guided: what to pick, how much, where to put it. Supports multiple locations per station (multiple containers simultaneously). Operations: direct picking, container/item count, replenishments. Can have associated RECH reject station. Empty container removal requires location configured for empty container handling. | -| 4 | PS | Outbound Conveyor | Final point of automatic transport — container leaves the warehouse. Management cycle of Easy WMS ends here (no more tasks). May have a display panel showing operator where to carry the container. Location types: Dynamic (Easy WMS tracks container depth) or Automatic (Easy WMS knows only which container is on PS, not which follows). | -| 16 | MP | Preparation Zone | Zone for order preparation — used in semi-automatic picking operations. | +| 4 | PS | Outbound Conveyor | Final point of automatic transport - container leaves the warehouse. Management cycle of Easy WMS ends here (no more tasks). May have a display panel showing operator where to carry the container. Location types: Dynamic (Easy WMS tracks container depth) or Automatic (Easy WMS knows only which container is on PS, not which follows). | +| 16 | MP | Preparation Zone | Zone for order preparation - used in semi-automatic picking operations. | | 17 | Consolidation | Consolidation Station | Consolidation station for grouping picked stock by shipping order. | | 53 | PCS | Sequencing Control Point | Point where order sequencing is controlled in the transport flow. | | 54 | PB | Proximity Buffer | Buffer near a picking station to temporarily hold containers. | @@ -112,19 +112,19 @@ Easy WMS defines 37+ standard station types. Types are identified by a numeric c | Code | Type | Name | Description | |------|------|------|-------------| | 5 | REAC | Reconditioning | Destination for containers that fail PIE validation but can be corrected and re-injected into the flow. | -| 7 | RECH | Rejects | Destination for definitively rejected containers — not reintegrable. | -| 20 | ET | Transit Station | Intermediate station inserted in routes to break task flow. Does not perform any WMS management — designed for flexibility and external system integration (robotic arm, labeling machine, vertical warehouse, etc.). For automatic locations: only one container at a time (new arrival sends previous to Lost & Found). For non-automatic (buffer) locations: multiple containers allowed. TMS must always report aisle=1 in station update. | +| 7 | RECH | Rejects | Destination for definitively rejected containers - not reintegrable. | +| 20 | ET | Transit Station | Intermediate station inserted in routes to break task flow. Does not perform any WMS management - designed for flexibility and external system integration (robotic arm, labeling machine, vertical warehouse, etc.). For automatic locations: only one container at a time (new arrival sends previous to Lost & Found). For non-automatic (buffer) locations: multiple containers allowed. TMS must always report aisle=1 in station update. | | 21 | CME | Inbound Control Station | Control point for inbound conveyors. | -| 42 | RETENTION | Retention | Retention station — holds containers that require manual review or authorization before continuing their route. | +| 42 | RETENTION | Retention | Retention station - holds containers that require manual review or authorization before continuing their route. | | 43 | DESK | Desk | Desk station for administrative or manual operations. | | 55 | ECB | Empty Containers Buffer | Buffer specifically for empty containers waiting to be stacked or reused. | -| 58 | ETQ | Labeller | Labeling machine station — container passes through and is automatically labeled. | +| 58 | ETQ | Labeller | Labeling machine station - container passes through and is automatically labeled. | ### Dock & Stage Stations | Code | Type | Name | Description | |------|------|------|-------------| -| 33 | Stage | Stage (Shipping/Receiving) | Floor area for temporary stock storage, typically near docks. Receiving stages: for stock pending putaway. Shipping stages: for client containers awaiting truck load. One of each can be set as default. Locations are DockStage type — Easy WMS does not control exact container position. Capacity = 0 means unlimited. Cannot be used for putaway; cannot generate tasks from stage (only from warehouse-type locations). | +| 33 | Stage | Stage (Shipping/Receiving) | Floor area for temporary stock storage, typically near docks. Receiving stages: for stock pending putaway. Shipping stages: for client containers awaiting truck load. One of each can be set as default. Locations are DockStage type - Easy WMS does not control exact container position. Capacity = 0 means unlimited. Cannot be used for putaway; cannot generate tasks from stage (only from warehouse-type locations). | | 33 | PKS | Packing Station | Packing station for packaging operations (shares type code 33 with Stage). | | 34 | Dock | Dock | Point of receipt or shipping. Types: inbound dock, outbound dock, or combined. At least one must be configured. Locations are DockStage type. No exact position tracking. Route must exist (even indirect) from container location to dock for task generation. Multiple locations per dock supported. | @@ -133,7 +133,7 @@ Easy WMS defines 37+ standard station types. Types are identified by a numeric c | Code | Type | Name | Description | |------|------|------|-------------| | 38 | Kit | Kits Assembly | Station for assembling kit items. | -| 57 | CONVEYOR | Conveyor (eCommerce) | Conveyor station for eCommerce operations — container-based order consolidation. | +| 57 | CONVEYOR | Conveyor (eCommerce) | Conveyor station for eCommerce operations - container-based order consolidation. | | 59 | VAS | VAS Conveyor | Conveyor station for executing Value Added Services. | | 61 | Cutting | Cutting Station | Station where cutting stock is cut in integrated or delegated picking processes. Composed of a receiving stage and a shipping stage (configurable: 1 shared stage, 2 dedicated stages, or shared stages across multiple cutting stations). Can be locked via "Stations" view to prevent stock assignment. | | 65 | AGV | AGV Station | AGV robot station. | @@ -146,7 +146,7 @@ A single physical station can have more than one role, enabling context-sensitiv **PIE with multiple roles:** A PIE station configured as a rejection or reconditioning station simultaneously. The workstation view updates to show the appropriate interface (PIE vs RECH/REAC) based on the container's task. Configuration: arrange both stations in EasyS, create PIE→RECH/REAC route, add RECH/REAC as Error Entity for PIE. Then assign role in SmartUI "Stations" view via "Assign new role". -**PK with multiple roles:** PK station acting also as a reject station. When a container is rejected at PIE, the target reject station is the PK that originally handled the container — enabling workload balance and operator accountability. No SmartUI role assignment needed. Configuration: arrange PK+RECH in EasyS, create route, add RECH as Error Entity for PK. Special case: if no dedicated reject station exists, PK itself can be the PIE's error entity. +**PK with multiple roles:** PK station acting also as a reject station. When a container is rejected at PIE, the target reject station is the PK that originally handled the container - enabling workload balance and operator accountability. No SmartUI role assignment needed. Configuration: arrange PK+RECH in EasyS, create route, add RECH as Error Entity for PK. Special case: if no dedicated reject station exists, PK itself can be the PIE's error entity. ## Station Code Translation (FR / ES / EN) @@ -169,7 +169,7 @@ Mecalux teams work across three languages; the same station can appear in logs a ## Station Capacity Semantics (GALILEO view) -Station capacity has a **different meaning** on PK and PS than on other stations — this trips up Gateway log analysis. +Station capacity has a **different meaning** on PK and PS than on other stations - this trips up Gateway log analysis. | Layer | Generic station (conveyor/TK) | PK and PS | |-------|-------------------------------|-----------| @@ -181,7 +181,7 @@ Worked example (PK): 1 physical slot + 4 in transit on intermediate conveyors + ## Route configuration in EasyS (robotics) -In robotics installations, **every** movement between automated stations requires a route in EasyS. A single task (e.g. `PIE → Miniload`) can generate **N movements** (4 is typical) — the WMS creates one task, the routing table allows each hop. +In robotics installations, **every** movement between automated stations requires a route in EasyS. A single task (e.g. `PIE → Miniload`) can generate **N movements** (4 is typical) - the WMS creates one task, the routing table allows each hop. > If no path exists, EasyWMS creates a **reject task** toward the configured reject station. @@ -195,7 +195,7 @@ EasyS route types (cross-reference with Manager table below): | **Manual** | Operator action triggered by a WMS task | | **Virtual** | Instantaneous automatic movement (e.g. output → consolidation) | -**Reject routes** (in red) are special: they give the **task destination** (not the movement destination). Different `IdentError` reasons can target different reject destinations — see [IdentErrorType](https://msscc.mecalux.com/documentation/Development/master/ES/apis/easywms/Domain/IdentErrorType.md). +**Reject routes** (in red) are special: they give the **task destination** (not the movement destination). Different `IdentError` reasons can target different reject destinations - see [IdentErrorType](https://msscc.mecalux.com/documentation/Development/master/ES/apis/easywms/Domain/IdentErrorType.md). For the protocol layer and message exchange (Search / End / Event / station updates), see [GALILEO Integration](../architecture/galileo-integration.md). For bring-up and simulation, see [Galileo Simulation](../operations/galileo-simulation.md). @@ -210,7 +210,7 @@ Easy WMS generates tasks based on configured routes. Before generating a task, i 1. That a route exists between source and destination. 2. That the route is **active** (all stations in route are not locked). -Exception: shipping full containers via dock — only checks that a route exists, not whether it's active. +Exception: shipping full containers via dock - only checks that a route exists, not whether it's active. If the shortest active route is blocked, Easy WMS immediately tries an alternative route. @@ -218,7 +218,7 @@ If the shortest active route is blocked, Easy WMS immediately tries an alternati ### Route Managers (Executors) -Each simple route requires a declared manager — the type of element that will execute tasks on that route: +Each simple route requires a declared manager - the type of element that will execute tasks on that route: | Manager | Executor | |---------|----------| @@ -226,7 +226,7 @@ Each simple route requires a declared manager — the type of element that will | Monorail | Monorail system | | RF | Operator with RFT (radio frequency terminal) | | Voice | Operator with voice terminal | -| Virtual | Automatic — task auto-completes when container arrives at source station, no physical action | +| Virtual | Automatic - task auto-completes when container arrives at source station, no physical action | | PTL | Pick-to-Light system | | External | External system (AGV, vertical warehouse, ERP, etc.) | | APS3D Fleet Manager | APS3D cart system | @@ -278,10 +278,10 @@ Docks and stages are created in **EasyS** (or **Warehouse Designer**), not in Sm ## Related -- [[location]] — Location types associated with each station (DockStage, buffer, conventional) -- [[task]] — Every movement is a task; tasks decompose into simple route movements -- [[warehouse-designer]] — Stations are created in EasyS/Warehouse Designer, transferred to SmartUI -- [[picking]] — PK, MP, Workzone, Decision, PKE, TenseFlow, Consolidation all support picking -- [[reception]] — Dock, Stage, PIE stations are central to receiving workflows -- [[shipping]] — Dock, Stage, PS, Consolidation stations support outbound flow -- [[putaway]] — PIE triggers location search; MU refines it closer to warehouse +- [[location]] - Location types associated with each station (DockStage, buffer, conventional) +- [[task]] - Every movement is a task; tasks decompose into simple route movements +- [[warehouse-designer]] - Stations are created in EasyS/Warehouse Designer, transferred to SmartUI +- [[picking]] - PK, MP, Workzone, Decision, PKE, TenseFlow, Consolidation all support picking +- [[reception]] - Dock, Stage, PIE stations are central to receiving workflows +- [[shipping]] - Dock, Stage, PS, Consolidation stations support outbound flow +- [[putaway]] - PIE triggers location search; MU refines it closer to warehouse diff --git a/wiki/concepts/stock-adjustment.md b/wiki/concepts/stock-adjustment.md index eeb7c2c..3834b84 100644 --- a/wiki/concepts/stock-adjustment.md +++ b/wiki/concepts/stock-adjustment.md @@ -36,9 +36,9 @@ last_compiled: "2026-04-17" A **stock adjustment** is any manual modification to a stock record's quantity, unit of measure (UoM), or logistic attributes that corrects a discrepancy between the physical reality and the WMS records. Every adjustment requires a **reason** for traceability. Adjustments can be made from three interfaces: -- **RF terminal (RFT)** — field operators correcting detected errors -- **SmartUI (PC web)** — manager-level adjustments from the web interface -- **Workstation / picking conveyor** — adjustments at an automatic warehouse PK station +- **RF terminal (RFT)** - field operators correcting detected errors +- **SmartUI (PC web)** - manager-level adjustments from the web interface +- **Workstation / picking conveyor** - adjustments at an automatic warehouse PK station EasyWMS always notifies the ERP of stock changes via **STV** (stock variation) messages, unless the stock originates from a still-open reception (in which case the change is reflected in the interface but no STV is sent until reception closes). @@ -146,13 +146,13 @@ Every adjustment requires a **reason code** selected from the master. Reasons ar ### RF Terminal Adjustments Available options from `RFT > Utilities`: -- **Increase item** — quantity increase -- **Decrease item** — quantity decrease -- **Location adjustment** — full adjustment (qty + UoM + AL + status) -- **Manual Movement** — move stock/container (see [manual-movements](../concepts/manual-movements.md)) +- **Increase item** - quantity increase +- **Decrease item** - quantity decrease +- **Location adjustment** - full adjustment (qty + UoM + AL + status) +- **Manual Movement** - move stock/container (see [manual-movements](../concepts/manual-movements.md)) RFT also supports: -- **Adjust in picking location with partitions** — reading a partition label sets both location and item +- **Adjust in picking location with partitions** - reading a partition label sets both location and item - **Adjustment during count** (in-count adjustments reported separately) ### SmartUI (Web) Adjustments @@ -211,7 +211,7 @@ A manager must then approve or cancel via `Warehouse > Stock adjustments`: **On adjustment (immediate):** - EasyWMS sends **STV** (stock variation) to ERP for each affected stock line -**Exception — open reception:** +**Exception - open reception:** - If adjusted stock belongs to a still-open reception, changes are reflected in the WMS interface but **no STV is sent** until reception closes **Double validation:** @@ -225,7 +225,7 @@ A manager must then approve or cancel via `Warehouse > Stock adjustments`: - Adjusting stock with active tasks triggers automatic task cancellation or decrement, then re-release of affected order lines. - Adjustment at quantity = 0 in a container: the container is **removed** or **left empty** depending on the location's "remove empty container" configuration. - ASN containers (pre-notified, not yet received) cannot be adjusted. -- Client stock (already prepared/loaded for a shipping order) has special handling — it can be adjusted but incompatibility with the order line triggers unassignment. +- Client stock (already prepared/loaded for a shipping order) has special handling - it can be adjusted but incompatibility with the order line triggers unassignment. - For multi-reception stock, the operator selects which specific reception's stock is being adjusted. - Cutting stock (non-consolidating UoM) can only be adjusted in whole stretch quantities; partial cutting requires the cutting process. @@ -241,13 +241,13 @@ A manager must then approve or cancel via `Warehouse > Stock adjustments`: Double validation is activated per item via its **count profile** (field: double validation flag in `inventory_management/double_validation/items/count_profile.md`). -### Count Profile — validation modes (WMS ≥ 2023-02-22) +### Count Profile - validation modes (WMS ≥ 2023-02-22) A **Count Profile** (`Configuration → Count Profiles`) decides whether stock adjustments for an item go straight through or wait for supervisor approval. | Mode | Effect | |---|---| -| **Never** | No validation required — STV is sent immediately | +| **Never** | No validation required - STV is sent immediately | | **Always** | Every adjustment is held as `Pending` | | **According to tolerance** | Held as `Pending` **only if** the adjustment exceeds the configured tolerance | @@ -260,7 +260,7 @@ A **Count Profile** (`Configuration → Count Profiles`) decides whether stock a | Maximum positive adjust | Absolute increase allowed without validation (base UoM) | | Maximum negative adjust | Absolute decrease allowed without validation (base UoM) | -> ℹ️ Count Profiles cannot yet be created via ITM — master data only in SmartUI. +> ℹ️ Count Profiles cannot yet be created via ITM - master data only in SmartUI. Attach the profile to an item by editing the item and selecting its Count Profile. @@ -270,7 +270,7 @@ Attach the profile to an item by editing the item and selecting its Count Profil - **Rights:** group `SuperAdmin` or `Administrateur` (Manager/Operator not allowed by default). - **Group rights do not disable validation.** Even a SuperAdmin creating the adjustment from RFT still triggers the SmartUI validation step if the item has a Count Profile requiring it. -- Default view shows only `Pending` — enable the history filter to see validated/rejected past adjustments. +- Default view shows only `Pending` - enable the history filter to see validated/rejected past adjustments. - Row colours : **green** = validated / no profile / profile "Never" / below tolerance; **red** = rejected. **Cancel behaviour:** @@ -279,9 +279,9 @@ Attach the profile to an item by editing the item and selecting its Count Profil ### French UI labels reminder -- **Pending** — no transaction, no ERP communication (stock change *is already applied* in the WMS, only ERP sync is held) -- **Validé** — STV sent to ERP -- **Annulé** — stock delta reverted in WMS; no transaction, no ERP message +- **Pending** - no transaction, no ERP communication (stock change *is already applied* in the WMS, only ERP sync is held) +- **Validé** - STV sent to ERP +- **Annulé** - stock delta reverted in WMS; no transaction, no ERP message > ⚠️ Validation only gates the **ERP communication**. The physical stock delta is already reflected in the warehouse whatever the validation outcome. @@ -295,7 +295,7 @@ Attach the profile to an item by editing the item and selecting its Count Profil | `RFT > Utilities > Decrease item` | RFT | | `RFT > Utilities > Location adjustment` | RFT | | `Workstations > Picking > Others > Stock Adjustment` | PC | -| `Warehouse > Stock` (SmartUI — logistic attributes) | PC | +| `Warehouse > Stock` (SmartUI - logistic attributes) | PC | | `Warehouse > Stock adjustments` (double validation review) | PC | | `Masters > Adjustment reasons` | PC | @@ -316,11 +316,11 @@ Attach the profile to an item by editing the item and selecting its Count Profil ## Related -- [[stock]] — Adjustment modifies stock records; STV and STK.ADJ are core stock transactions -- [[count]] — Counts generate adjustments; double validation applies to count-triggered adjustments too -- [[quality-control]] — Quality locks affect picking/replenishment eligibility; separate from adjustments but share CST.STK vs STK.ADJ transactions -- [[location]] — Adjustment behavior (empty container removed vs. kept) depends on location config -- [[product-item]] — Count profile on item controls double validation activation -- [[container]] — Adjustments to container stock trigger task/assignment re-evaluation -- [[cutting-stock]] — Cutting stock adjustments follow indivisibility rules; label printing from location adjustment (source label only) -- [[labels]] — Labels can be printed for cutting stock during location adjustment process +- [[stock]] - Adjustment modifies stock records; STV and STK.ADJ are core stock transactions +- [[count]] - Counts generate adjustments; double validation applies to count-triggered adjustments too +- [[quality-control]] - Quality locks affect picking/replenishment eligibility; separate from adjustments but share CST.STK vs STK.ADJ transactions +- [[location]] - Adjustment behavior (empty container removed vs. kept) depends on location config +- [[product-item]] - Count profile on item controls double validation activation +- [[container]] - Adjustments to container stock trigger task/assignment re-evaluation +- [[cutting-stock]] - Cutting stock adjustments follow indivisibility rules; label printing from location adjustment (source label only) +- [[labels]] - Labels can be printed for cutting stock during location adjustment process diff --git a/wiki/concepts/stock-assignment.md b/wiki/concepts/stock-assignment.md index a4e61cf..11bb31b 100644 --- a/wiki/concepts/stock-assignment.md +++ b/wiki/concepts/stock-assignment.md @@ -12,7 +12,7 @@ related: - concepts/crossdocking.md - concepts/cutting-stock.md - concepts/task.md - - modules/tenseflow.md + - concepts/tense-flow.md last_compiled: "2026-04-17" --- @@ -22,7 +22,7 @@ last_compiled: "2026-04-17" **Stock assignment** is the engine that binds concrete stock to outbound work. Given an outbound order line (and its `OutboundOrderLineDetails`), it decides **which stock lines** will fulfil the demand and **what type of task** will be created to physically move them (picking, container shipping, replenishment, virtual picking). -Every line detail is assigned independently — a line can have several details either because the requested item is a **non-assembled kit** (one detail per component) or because **alternative items** have been configured (if the main item is short, the WMS adds an extra detail with the substitute item and zeroes the main item's quantity). +Every line detail is assigned independently - a line can have several details either because the requested item is a **non-assembled kit** (one detail per component) or because **alternative items** have been configured (if the main item is short, the WMS adds an extra detail with the substitute item and zeroes the main item's quantity). The assignment engine is a chain of workflows all prefixed `StockAssignProcess_*`. The main entry point is `StockAssignProcess_AssignOutboundLine_PR`, which loops over the line's details through `StockAssignProcess_AssignOutboundOrderLineDetails_PR`. @@ -38,16 +38,16 @@ Loads the outbound line detail, locks it for the assignment run, and reads the m Workflow: `StockAssignProcess_GetAvailableStockForOutboundOrderLineDetails_PR` -Calls the query **`Stocks_AssignableForProductOutboundOrderLineDetailsAndStockAssignStrategy`**. Additional filters on assignable stock (e.g., custom-attribute filtering, reservations, supplier constraints) are added as extra `where` clauses on this query — once they are in place, SmartUI surfaces them under the **"Trace d'assignations de stock"** button for auditability. +Calls the query **`Stocks_AssignableForProductOutboundOrderLineDetailsAndStockAssignStrategy`**. Additional filters on assignable stock (e.g., custom-attribute filtering, reservations, supplier constraints) are added as extra `where` clauses on this query - once they are in place, SmartUI surfaces them under the **"Trace d'assignations de stock"** button for auditability. ### 3. Apply assignment strategy Two branches: -- **Kits, manufacturing orders, TenseFlow** — the WMS prioritises stock already sitting in the dedicated consumption zone (assembly zone, production supply zone, TenseFlow supply zone) through `StockAssignProcess_CalculateByAssignmentManufacturingAndKits_PR`. This avoids pulling stock across zones when an in-zone alternative exists. -- **Standard details** — applies the outbound priorities (preferred status, preferred UoM…) and then: - - `Stocks_ApplyOutboundLogic_PR` — applies the shipping logic of the item (FIFO, FEFO, LIFO, custom). - - `StockAssignProcess_CalculateEfficiencyMode_PR` — applies the efficiency mode (see [concepts/replenishment.md](replenishment.md#efficiency-modes) and the outbound efficiency settings on the shipping profile). +- **Kits, manufacturing orders, TenseFlow** - the WMS prioritises stock already sitting in the dedicated consumption zone (assembly zone, production supply zone, TenseFlow supply zone) through `StockAssignProcess_CalculateByAssignmentManufacturingAndKits_PR`. This avoids pulling stock across zones when an in-zone alternative exists. +- **Standard details** - applies the outbound priorities (preferred status, preferred UoM…) and then: + - `Stocks_ApplyOutboundLogic_PR` - applies the shipping logic of the item (FIFO, FEFO, LIFO, custom). + - `StockAssignProcess_CalculateEfficiencyMode_PR` - applies the efficiency mode (see [concepts/replenishment.md](replenishment.md#efficiency-modes) and the outbound efficiency settings on the shipping profile). The candidate list is narrowed and finally validated by `StockAssignProcess_ValidateStockList_PR`. @@ -55,15 +55,15 @@ The candidate list is narrowed and finally validated by `StockAssignProcess_Vali Two sibling workflows: -- `StockAssignProcess_CreateAssignments_PR` — writes the assignment rows (visible in SmartUI under **Allocations de stock**). -- `Outbound_StockAssignCreateOrderLineDetailsTasks_PR` — translates each assignment into a task of the appropriate type (see below). +- `StockAssignProcess_CreateAssignments_PR` - writes the assignment rows (visible in SmartUI under **Allocations de stock**). +- `Outbound_StockAssignCreateOrderLineDetailsTasks_PR` - translates each assignment into a task of the appropriate type (see below). ## Assignment types | Type | Description | |---|---| | **PickingLocations** | Classical picking task on a location flagged as picking. The stock is already at a pickable place. | -| **ReplenishmentAssignment** | The candidate location permits replenishment but the on-hand quantity is insufficient. The engine creates a **picking task and a parallel replenishment task** — covers both static (PDL-driven) and dynamic replenishment scenarios. | +| **ReplenishmentAssignment** | The candidate location permits replenishment but the on-hand quantity is insufficient. The engine creates a **picking task and a parallel replenishment task** - covers both static (PDL-driven) and dynamic replenishment scenarios. | | **ShippingContainer** | The full container (mono-reference) is needed and the location allows container shipping. A container-shipping task is created instead of a picking task. | | **PickingContainer** | Specific to **TenseFlow**. A `BufferReplenishment` task is created first, moving the container to the supply zone ; during virtual picking, virtual picking tasks are generated against the buffered stock. | @@ -71,15 +71,15 @@ Two sibling workflows: ### Kits -If **any component** of a non-assembled kit cannot be assigned, **no component is assigned** — the engine rolls back and leaves the line short so the operator does not start half-kits. The matching behaviour for assembled kits (ready-made component) is standard. +If **any component** of a non-assembled kit cannot be assigned, **no component is assigned** - the engine rolls back and leaves the line short so the operator does not start half-kits. The matching behaviour for assembled kits (ready-made component) is standard. ### Crossdocking -When the item allows crossdocking, an inbound expected to arrive shortly will block the engine from re-assigning the outbound line to existing stock — it will wait for the crossdocking candidate. Customers who do not want this behaviour comment out the crossdocking branch in the stock search query. +When the item allows crossdocking, an inbound expected to arrive shortly will block the engine from re-assigning the outbound line to existing stock - it will wait for the crossdocking candidate. Customers who do not want this behaviour comment out the crossdocking branch in the stock search query. ### Alternatives -When the main item cannot cover the line quantity, the engine inserts a new detail with the alternative item and sets the main item's remaining quantity to zero. The alternative detail goes through the same pipeline — it may itself fall back to another alternative if further shortage occurs. +When the main item cannot cover the line quantity, the engine inserts a new detail with the alternative item and sets the main item's remaining quantity to zero. The alternative detail goes through the same pipeline - it may itself fall back to another alternative if further shortage occurs. ## Customisation points @@ -87,31 +87,31 @@ When the main item cannot cover the line quantity, the engine inserts a new deta |---|---| | Expose more line-detail fields to the engine | Extend `Select` in `StockAssignProcess_GetLockAndUpdateDetail_PR` | | Filter candidate stock on a new criterion | Add `where` clauses in `Stocks_AssignableForProductOutboundOrderLineDetailsAndStockAssignStrategy` (visible in SmartUI "Trace d'assignations de stock") | -| Generate **only picking tasks** (e.g., for waves — wave mode only consumes picking tasks) | Modify `StockAssignProcess_GetStockToAssignForStrategy_PR` ; if the WMS version has the assignment-merge feature, also modify `Outbound_CreatePickingLocationsTasks_PR` | +| Generate **only picking tasks** (e.g., for waves - wave mode only consumes picking tasks) | Modify `StockAssignProcess_GetStockToAssignForStrategy_PR` ; if the WMS version has the assignment-merge feature, also modify `Outbound_CreatePickingLocationsTasks_PR` | | Disable crossdocking blocking | Comment out the crossdocking predicate in the stock search query | ## Observability -- **SmartUI → Allocations de stock** — shows which stock line is reserved for which outbound line detail, with the assignment type. -- **"Trace d'assignations de stock"** button — exposes the extra filters added to `Stocks_AssignableForProductOutboundOrderLineDetailsAndStockAssignStrategy` so support can see why a candidate was rejected. +- **SmartUI → Allocations de stock** - shows which stock line is reserved for which outbound line detail, with the assignment type. +- **"Trace d'assignations de stock"** button - exposes the extra filters added to `Stocks_AssignableForProductOutboundOrderLineDetailsAndStockAssignStrategy` so support can see why a candidate was rejected. ## Common issues | Symptom | Likely cause | |---|---| | Outbound line stays in `StockFailure` despite visible stock | Filter on the assignment query (custom clause), preferred status rejecting everything, or logistic attribute mismatch | -| Kit line assigned with some components but not all | Should not happen — rollback rule is absolute. Check if components were split across two details by an alternative cascade | +| Kit line assigned with some components but not all | Should not happen - rollback rule is absolute. Check if components were split across two details by an alternative cascade | | Expected replenishment-plus-picking not generated | Picking location does not actually permit replenishment, or all candidate reserves are locked | -| Container shipping task created when picking was expected | Line quantity equals full container quantity **and** location allows container shipping — disable the container-shipping branch on the location if not desired | +| Container shipping task created when picking was expected | Line quantity equals full container quantity **and** location allows container shipping - disable the container-shipping branch on the location if not desired | ## Related -- [[stock]] — the data model assignment writes against -- [[order-outbound]] — outbound lines and their `OutboundOrderLineDetails` are the inputs of the engine -- [[picking]] — most assignment outputs are consumed as picking tasks -- [[replenishment]] — `ReplenishmentAssignment` type materialises the replenishment-plus-picking pairing -- [[kits]] — kit handling special case (all-or-nothing rollback, dedicated assembly-zone preference) -- [[crossdocking]] — assignment waits for inbound crossdocking candidates unless disabled -- [[cutting-stock]] — cutting items use the same pipeline with cut-specific post-processing -- [[task]] — tasks are the tangible output of each assignment -- [[tenseflow]] — the PickingContainer assignment type is the TenseFlow-specific path +- [[stock]] - the data model assignment writes against +- [[order-outbound]] - outbound lines and their `OutboundOrderLineDetails` are the inputs of the engine +- [[picking]] - most assignment outputs are consumed as picking tasks +- [[replenishment]] - `ReplenishmentAssignment` type materialises the replenishment-plus-picking pairing +- [[kits]] - kit handling special case (all-or-nothing rollback, dedicated assembly-zone preference) +- [[crossdocking]] - assignment waits for inbound crossdocking candidates unless disabled +- [[cutting-stock]] - cutting items use the same pipeline with cut-specific post-processing +- [[task]] - tasks are the tangible output of each assignment +- [[tenseflow]] - the PickingContainer assignment type is the TenseFlow-specific path diff --git a/wiki/concepts/stock.md b/wiki/concepts/stock.md index fbaed4c..84b5c2d 100644 --- a/wiki/concepts/stock.md +++ b/wiki/concepts/stock.md @@ -39,11 +39,11 @@ last_compiled: "2026-04-17" ## Overview -A **stock record** (stock line) is the physical instance of an item in the warehouse at a specific moment — a quantity of a particular item, owned by a specific owner, in a specific location or container, with specific logistic attributes and status. It is distinct from the item master: the item defines what the product is; the stock defines how much of it exists, where, and in what state. +A **stock record** (stock line) is the physical instance of an item in the warehouse at a specific moment - a quantity of a particular item, owned by a specific owner, in a specific location or container, with specific logistic attributes and status. It is distinct from the item master: the item defines what the product is; the stock defines how much of it exists, where, and in what state. Stock is created when goods are received, consumed when goods are shipped, and transformed (split, merged, adjusted) throughout warehouse operations. The WMS maintains an exact, real-time view of all stock across every location and container in the warehouse. All WMS processes (putaway strategies, stock assignment for outbound orders, replenishment, counting) operate against stock records. -A single item in the warehouse can have many stock lines — one per unique combination of container, logistic attributes, and status. For example, the same SKU in three different lot numbers stored in two locations will produce at least 6 separate stock lines. +A single item in the warehouse can have many stock lines - one per unique combination of container, logistic attributes, and status. For example, the same SKU in three different lot numbers stored in two locations will produce at least 6 separate stock lines. ## Types @@ -53,7 +53,7 @@ Stock is classified by its storage context and status: - **Containerized stock**: stock inside a container (LPN). The container holds the stock and can be moved as a unit. The stock line references both the container and the location of the container. - **Loose stock**: stock directly in a location, not in a container. Common in conventional manual locations with picking dedicated partitions. -- **Client stock**: stock that has been prepared (picked) for a specific outbound order, now in a client (outbound) container. Special rules apply — quantity, UoM, and logistic attributes cannot be adjusted like regular stock. +- **Client stock**: stock that has been prepared (picked) for a specific outbound order, now in a client (outbound) container. Special rules apply - quantity, UoM, and logistic attributes cannot be adjusted like regular stock. - **ASN stock**: stock pre-notified by the ERP but not yet physically received. Located in the virtual ASN location. Cannot be adjusted. ### By status @@ -62,7 +62,7 @@ Stock carries up to three parallel status dimensions: | Status type | Description | Set by | |---|---|---| -| **System status** | Internal WMS status (e.g., normal, reserved, assigned) | Automatic — driven by stock assignment and task creation | +| **System status** | Internal WMS status (e.g., normal, reserved, assigned) | Automatic - driven by stock assignment and task creation | | **User status** | Quality or business-driven lock (e.g., "Quarantine", "Hold") | Manually by user, or via ERP STR message. Has optional end date. | | **Receiving status** | Quality control status set during reception | At reception, automatically based on receipt order configuration | @@ -192,7 +192,7 @@ Stock adjustments allow operators to correct discrepancies between the WMS recor > **WSC / SCR**: To get the complete stock image, the ERP sends an **SCR** request and EasyWMS responds with a **WSC** file. This can be: > - Grouped by item (one line per item/owner/status) > - Detailed (with location and container) -> - The WSC does NOT discriminate "available to sell" — use stock status filtering for that. +> - The WSC does NOT discriminate "available to sell" - use stock status filtering for that. > - Stock at 0 can optionally be included (configurable). > - Can be sent on-demand or on a scheduled basis (once/day or at intervals). @@ -211,7 +211,7 @@ EasyWMS supports a **double validation** mechanism for stock adjustments. When a Configuration (per item, in **inventory profile**): | Setting | Behavior | |---------|---------| -| **Never** | No double validation — adjustments applied immediately | +| **Never** | No double validation - adjustments applied immediately | | **Always** | All adjustments require manager validation | | **By tolerance** | Requires validation only if delta exceeds a configured threshold (absolute value or %) | @@ -271,7 +271,7 @@ The grouped stock reports provide aggregate views of stock without the per-line |---|---|---| | Cannot adjust ASN stock | Stock is in pre-notified container not yet received | Receive the container first via the reception process | | Cannot adjust client stock | Stock is prepared for a shipping order in a client container | Un-prepare the stock via shipping management, then adjust | -| Adjustment fails — reason required | No adjustment reason selected | Create reasons in Masters; select one before adjusting | +| Adjustment fails - reason required | No adjustment reason selected | Create reasons in Masters; select one before adjusting | | Stock not visible in view | Stock in virtual location (ASN, Lost_Found) or filtered out | Remove filters; check virtual locations explicitly | | Stock in lock not assignable | User or receiving status prevents shipping | Release the lock (manually or via STR from ERP); or add required status to SOR line | | Quantity jumps after decrease | Other stock from the same item was consolidated | Separate stock lines if needed; use "From multiple receptions" selection | @@ -279,15 +279,15 @@ The grouped stock reports provide aggregate views of stock without the per-line ## Related -- [[container]] — stock is either containerized (in an LPN) or loose; container locks and type affect stock eligibility -- [[location]] — every stock record has a location; location logics (allow shipping, allow replenishment) determine eligibility -- [[product-item]] — item defines the static attributes; stock is the physical quantity with runtime attributes -- [[reception]] — stock is created during the reception process; receiving status can be set at receipt -- [[picking]] — stock is assigned and picked for outbound orders; picking consumes stock quantity -- [[shipping]] — shipping closes orders and removes stock from the warehouse -- [[count]] — counts verify the accuracy of stock records; discrepancies trigger adjustments -- [[stock-adjustment]] — detailed adjustment procedures (quantity, UoM, logistic attributes) -- [[stock-assignment]] — the allocation engine that binds stock lines to outbound order line details (`StockAssignProcess_*` workflows, assignment types, customisation points) -- [[order-outbound]] — stock assignment links specific stock lines to SOR lines; reserves and assignments -- [[task]] — tasks move stock between locations; running tasks block certain stock adjustments -- [[erp-interface]] — STV message reports stock changes; SCR/WSC for stock contrasts; STR for status locks +- [[container]] - stock is either containerized (in an LPN) or loose; container locks and type affect stock eligibility +- [[location]] - every stock record has a location; location logics (allow shipping, allow replenishment) determine eligibility +- [[product-item]] - item defines the static attributes; stock is the physical quantity with runtime attributes +- [[reception]] - stock is created during the reception process; receiving status can be set at receipt +- [[picking]] - stock is assigned and picked for outbound orders; picking consumes stock quantity +- [[shipping]] - shipping closes orders and removes stock from the warehouse +- [[count]] - counts verify the accuracy of stock records; discrepancies trigger adjustments +- [[stock-adjustment]] - detailed adjustment procedures (quantity, UoM, logistic attributes) +- [[stock-assignment]] - the allocation engine that binds stock lines to outbound order line details (`StockAssignProcess_*` workflows, assignment types, customisation points) +- [[order-outbound]] - stock assignment links specific stock lines to SOR lines; reserves and assignments +- [[task]] - tasks move stock between locations; running tasks block certain stock adjustments +- [[erp-interface]] - STV message reports stock changes; SCR/WSC for stock contrasts; STR for status locks diff --git a/wiki/concepts/supplier.md b/wiki/concepts/supplier.md index 5fce4be..ac6cdac 100644 --- a/wiki/concepts/supplier.md +++ b/wiki/concepts/supplier.md @@ -19,7 +19,7 @@ last_compiled: "2026-04-10" ## Overview -A **supplier** is a company or entity that supplies stock to the warehouse. Suppliers are referenced on receipt orders (inbound) and return orders (outbound). Every inbound flow — whether a standard delivery, ASN-based reception, or stock return — traces back to a supplier. +A **supplier** is a company or entity that supplies stock to the warehouse. Suppliers are referenced on receipt orders (inbound) and return orders (outbound). Every inbound flow - whether a standard delivery, ASN-based reception, or stock return - traces back to a supplier. Suppliers are master data entities managed in WMS (or synced from ERP via SUP message). When the Owner Extensions module is active, each supplier must be assigned to an owner. @@ -68,8 +68,8 @@ Suppliers are master data entities managed in WMS (or synced from ERP via SUP me ## Related -- [[reception]] — dock reception references the supplier; supplier container and loose stock reception modes exist -- [[order-inbound]] — receipt orders (ROR) reference the supplying entity; returns indicate the supplier destination -- [[product-item]] — items can be received only from suppliers linked via receipt orders -- [[owner-extensions]] — when active, suppliers must be assigned to an owner; supplier code is prefixed with owner code -- [[erp-interface]] — SUP message syncs supplier master from ERP +- [[reception]] - dock reception references the supplier; supplier container and loose stock reception modes exist +- [[order-inbound]] - receipt orders (ROR) reference the supplying entity; returns indicate the supplier destination +- [[product-item]] - items can be received only from suppliers linked via receipt orders +- [[owner-extensions]] - when active, suppliers must be assigned to an owner; supplier code is prefixed with owner code +- [[erp-interface]] - SUP message syncs supplier master from ERP diff --git a/wiki/concepts/task.md b/wiki/concepts/task.md index 036e94d..e4cef07 100644 --- a/wiki/concepts/task.md +++ b/wiki/concepts/task.md @@ -85,17 +85,17 @@ In **automatic warehouses**, tasks are executed by automated systems (AS/RS, AGV ↓ Task CREATED (pending movement generation) ↓ - PENDING — waiting for movement to be generated + PENDING - waiting for movement to be generated ↓ - GENERATED — movement created, no operator/machine assigned yet + GENERATED - movement created, no operator/machine assigned yet ↓ - IN PROCESS — currently being executed + IN PROCESS - currently being executed ↓ - FINISHED — task completed successfully - + FINISHED - task completed successfully + (at any point from Generated or In Process) ↓ - CANCELED — task stopped by user action + CANCELED - task stopped by user action ``` ### Status transitions @@ -110,7 +110,7 @@ In **automatic warehouses**, tasks are executed by automated systems (AS/RS, AGV ## Tasks and movements -The task defines **from where to where** (source station → destination station). The actual path may pass through multiple intermediate stations. Easy WMS decomposes the task into **movements** — each movement covers one segment (one station to the next). +The task defines **from where to where** (source station → destination station). The actual path may pass through multiple intermediate stations. Easy WMS decomposes the task into **movements** - each movement covers one segment (one station to the next). Each segment has a configured **manager** (who/what executes it): - **RF**: human operator with radio frequency terminal @@ -133,7 +133,7 @@ Movement release (reset In Execution → Pending) is available for resolving inc ## Business rules - **Cannot manually complete** picking, counting, replenishment (stock replenishment type), kit assembly, or consolidation tasks. These must be completed through their respective processes. -- **Task assignment** to user or equipment respects work zone restrictions — if the equipment cannot access the required work zone or aisle, the task will not be executable. +- **Task assignment** to user or equipment respects work zone restrictions - if the equipment cannot access the required work zone or aisle, the task will not be executable. - **Equipment incompatibility**: equipment that cannot transport the container type specified in the task is ineligible. - **Priority** drives task sequencing within a process queue (lower number = higher priority; values: Very Low, Low, Normal, High, Urgent). - **Task cancellation**: container stays where the operator reports it (user must indicate the location, including position for rack locations or depth for channel locations). @@ -152,7 +152,7 @@ For manual warehouse RF execution, the priority ordering is: **Shipping tasks:** Round number → Priority → Empty channel → Stackability → Distance → Creation date -**Wave picking:** Priority (of the wave/orders assigned) → Route path (right and left sides, low to high — no second rounds) +**Wave picking:** Priority (of the wave/orders assigned) → Route path (right and left sides, low to high - no second rounds) **Order picking (RF):** For task selection: assigned to user/equipment first → Priority → Release date. For task execution: same as automatic tasks. @@ -201,16 +201,16 @@ Transactions are generated by the underlying process (not by semi-automatic mode | Task created but not assignable | Equipment type incompatible with container type in task | Assign different equipment; check equipment container type configuration | | Task cannot be manually completed | Task type is picking, counting, stock replenishment, kit assembly, or consolidation | Complete via the appropriate process screen (picking station, count screen, etc.) | | Movement stuck In Execution | Automatic system malfunction or communication failure | Use Movement Release to reset to Pending; investigate automation incident | -| Canceled task — container not found | Operator reported wrong location at cancellation | Run a count or check Last Known Location; resolve via Lost & Found if needed | +| Canceled task - container not found | Operator reported wrong location at cancellation | Run a count or check Last Known Location; resolve via Lost & Found if needed | | Task not generated after process trigger | Work zone restriction prevents any available equipment from executing | Check work zone configuration and available equipment | ## Related -- [[location]] — tasks always have a source and destination location; location type (rack, compact, etc.) determines coordinate precision in tasks -- [[container]] — most automatic warehouse tasks move containers; task references container code and type -- [[stock]] — stock tasks (picking, replenishment) specify item, quantity, and logistic attributes -- [[putaway]] — putaway process generates Putaway tasks; PIE/MU/TRL/ALM stations trigger automatic task creation -- [[picking]] — picking process generates Picking tasks; wave/group picking generates batches of tasks -- [[shipping]] — shipping process generates Shipping and Loading tasks for consolidation and dock delivery -- [[replenishment]] — replenishment generates Container replenishment or Stock replenishment tasks to PDLs -- [[count]] — count processes generate Location count, Container count, or Item count tasks +- [[location]] - tasks always have a source and destination location; location type (rack, compact, etc.) determines coordinate precision in tasks +- [[container]] - most automatic warehouse tasks move containers; task references container code and type +- [[stock]] - stock tasks (picking, replenishment) specify item, quantity, and logistic attributes +- [[putaway]] - putaway process generates Putaway tasks; PIE/MU/TRL/ALM stations trigger automatic task creation +- [[picking]] - picking process generates Picking tasks; wave/group picking generates batches of tasks +- [[shipping]] - shipping process generates Shipping and Loading tasks for consolidation and dock delivery +- [[replenishment]] - replenishment generates Container replenishment or Stock replenishment tasks to PDLs +- [[count]] - count processes generate Location count, Container count, or Item count tasks diff --git a/wiki/concepts/tense-flow.md b/wiki/concepts/tense-flow.md index 16ad931..9a1eee6 100644 --- a/wiki/concepts/tense-flow.md +++ b/wiki/concepts/tense-flow.md @@ -16,12 +16,12 @@ last_compiled: "2026-04-17" ## Overview -Tense Flow (FR : *flux tendu*) enables picking directly from one or more source supports — typically to prepare an outbound order **straight from reception** without first putting the stock away. The stock never hits a "normal" storage location : it is replenished to a dedicated buffer (FR : *poumon PREPARATION*) and consumed from there virtually. +Tense Flow (FR : *flux tendu*) enables picking directly from one or more source supports - typically to prepare an outbound order **straight from reception** without first putting the stock away. The stock never hits a "normal" storage location : it is replenished to a dedicated buffer (FR : *poumon PREPARATION*) and consumed from there virtually. The flow combines: 1. A **tense-flow element** + an associated **buffer stage** (typically named `PREPARATION`). 2. A **replenishment task** from the source location(s) to the buffer, triggered at order release. -3. **Virtual picking** on the RF terminal — the operator scans the source support + the newly created client container and declares the picked quantity. +3. **Virtual picking** on the RF terminal - the operator scans the source support + the newly created client container and declares the picked quantity. 4. A closing step that transfers the client containers to the shipping buffer. ## EasyS Configuration @@ -31,7 +31,7 @@ The flow combines: 3. Associate the tense-flow element to the buffer as a `Delivery Stage`. 4. Configure the source locations (buffers and racks) with the option **"Allow origin of replenishement of tense flow"** set to true, otherwise the replenishment task generated at "Lancer en flux tendu" will find no candidate origins. -> ⚠️ Tense Flow always creates a replenishment task *towards the buffer first* — the source locations must be eligible as tense-flow origins, not only as normal-flow origins. +> ⚠️ Tense Flow always creates a replenishment task *towards the buffer first* - the source locations must be eligible as tense-flow origins, not only as normal-flow origins. ## Functional Flow @@ -48,7 +48,7 @@ RFT menu : **Tâches → Tâches à flux tendu**. Execute the task to move stock RFT menu : **Ordres de sortie → Picking virtuel**. 1. Scan the **source support** (the pallet / container now at the buffer). -2. Create a **new client container** — use the **"Générer SSCC"** button to assign a fresh SSCC. +2. Create a **new client container** - use the **"Générer SSCC"** button to assign a fresh SSCC. 3. Scan the new container or the destination location. 4. Enter the item + picked quantity (and any logistic attributes). @@ -60,16 +60,16 @@ Once all the client containers are filled, transfer them to the `EXPEDITION` buf ## Common Errors -**"Lancer en flux tendu" creates no replenishment task** : either the outbound order is not released yet, or the source locations are not marked as `Allow origin of replenishement of tense flow`. Tense Flow replenishment uses a separate eligibility flag from the standard replenishment — enable it on the candidate origins. +**"Lancer en flux tendu" creates no replenishment task** : either the outbound order is not released yet, or the source locations are not marked as `Allow origin of replenishement of tense flow`. Tense Flow replenishment uses a separate eligibility flag from the standard replenishment - enable it on the candidate origins. -**Virtual picking screen rejects the source scan** : the stock is not on the `PREPARATION` buffer yet — the replenishment task must be executed first. +**Virtual picking screen rejects the source scan** : the stock is not on the `PREPARATION` buffer yet - the replenishment task must be executed first. -**Remaining stock is not proposed for putaway** : the tense-flow element is not associated to the buffer as a `Delivery Stage` — re-check EasyS step 3. +**Remaining stock is not proposed for putaway** : the tense-flow element is not associated to the buffer as a `Delivery Stage` - re-check EasyS step 3. ## Related -- [Picking](picking.md) — tense flow is a special picking mode that bypasses storage -- [Replenishment](replenishment.md) — tense flow generates an upstream replenishment task with its own eligibility flag -- [Reception](reception.md) — tense flow is commonly used to ship freshly received stock without storing it first -- [Outbound Order](order-outbound.md) — tense flow is triggered on a released outbound order -- [Stations & Routes](stations.md) — tense-flow buffer and element are configured alongside standard stations +- [Picking](picking.md) - tense flow is a special picking mode that bypasses storage +- [Replenishment](replenishment.md) - tense flow generates an upstream replenishment task with its own eligibility flag +- [Reception](reception.md) - tense flow is commonly used to ship freshly received stock without storing it first +- [Outbound Order](order-outbound.md) - tense flow is triggered on a released outbound order +- [Stations & Routes](stations.md) - tense-flow buffer and element are configured alongside standard stations diff --git a/wiki/concepts/transactions.md b/wiki/concepts/transactions.md index b09fc56..f22304f 100644 --- a/wiki/concepts/transactions.md +++ b/wiki/concepts/transactions.md @@ -23,7 +23,7 @@ last_compiled: "2026-04-17" ## Overview -Easy WMS records every significant state change as a **Transaction** — an immutable audit log entry. Transactions serve two purposes: +Easy WMS records every significant state change as a **Transaction** - an immutable audit log entry. Transactions serve two purposes: 1. **Audit trail**: Who did what, when, and on which objects 2. **ERP integration trigger**: "Post-processed" transactions generate ERP messages (see [ERP Interface](erp-interface.md)) @@ -54,7 +54,7 @@ The **Post-processed** flag indicates whether the transaction triggers an ERP me ### Regeneration from SmartUI -The Transactions view gives an end-to-end snapshot of every action done by the WMS. When a transaction is in status **`Envoyé`** (sent) or **`Génération d'erreur`** (generation error), SmartUI allows **regenerating the ERP file** directly — any modification made to the associated BOO code since the original send will be applied to the regenerated message. This is the standard lever used to recover from a post-processing hiccup or a fixed BOO without having to provoke the functional trigger a second time. +The Transactions view gives an end-to-end snapshot of every action done by the WMS. When a transaction is in status **`Envoyé`** (sent) or **`Génération d'erreur`** (generation error), SmartUI allows **regenerating the ERP file** directly - any modification made to the associated BOO code since the original send will be applied to the regenerated message. This is the standard lever used to recover from a post-processing hiccup or a fixed BOO without having to provoke the functional trigger a second time. ## Transaction Catalog @@ -64,20 +64,20 @@ The Transactions view gives an end-to-end snapshot of every action done by the W |------|---------------|-------------|-------------| | `CON.ASN.001` | Yes | Container received for ASN order | ASO | | `CON.CNL.ASN` | Yes | Pre-notified container rejected/deleted | ASK | -| `CON.COC` | No | Client container closed in Preparation Zone (MP) | — | -| `CON.COS.001` | No | Container entered outbound conveyor (PS) | — | -| `CON.CREATE` | No | Container created (manual, picking, or count) | — | -| `CON.DELETE` | No | Container deleted (L&F or after count) | — | -| `CON.LOAD` | No | Container loaded during truck loading | — | -| `CON.LOCATE` | No | Container moved to storage via putaway task | — | -| `CON.MOVE` | No | Container moved without putaway task (or from L&F) | — | +| `CON.COC` | No | Client container closed in Preparation Zone (MP) | - | +| `CON.COS.001` | No | Container entered outbound conveyor (PS) | - | +| `CON.CREATE` | No | Container created (manual, picking, or count) | - | +| `CON.DELETE` | No | Container deleted (L&F or after count) | - | +| `CON.LOAD` | No | Container loaded during truck loading | - | +| `CON.LOCATE` | No | Container moved to storage via putaway task | - | +| `CON.MOVE` | No | Container moved without putaway task (or from L&F) | - | | `CON.PIE` | Yes | Container entered via PIE station | ASO | -| `CON.PRINT` | No | Packing list + client container label print trigger | — | -| `CON.RECEP` | No | Container received in any reception process | — | -| `CON.SEND.L&F` | No | Container sent to Lost & Found | — | -| `CON.SHIPPED` | No | Container status changed to Shipped (order close) | — | -| `CON.SHIPPING` | No | Shipping task confirmed for container | — | -| `CON.VASDONE` | No | VAS template applied to container | — | +| `CON.PRINT` | No | Packing list + client container label print trigger | - | +| `CON.RECEP` | No | Container received in any reception process | - | +| `CON.SEND.L&F` | No | Container sent to Lost & Found | - | +| `CON.SHIPPED` | No | Container status changed to Shipped (order close) | - | +| `CON.SHIPPING` | No | Shipping task confirmed for container | - | +| `CON.VASDONE` | No | VAS template applied to container | - | **Key data fields by transaction:** - `CON.ASN.001`: ContainerCode, LocationCode, Document1=ReceiptCode, Document2=ContainerTypeCode @@ -90,9 +90,9 @@ The Transactions view gives an end-to-end snapshot of every action done by the W | Code | Post-processed | Description | ERP Message | |------|---------------|-------------|-------------| -| `COU.CLS` | No | Count closed | — | -| `COU.CNL` | No | Count canceled | — | -| `COU.CST` | No | Count status changed | — | +| `COU.CLS` | No | Count closed | - | +| `COU.CNL` | No | Count canceled | - | +| `COU.CST` | No | Count status changed | - | | `COU.END` | Yes | Count closed/canceled (ERP-initiated count) | COF | **Notes:** @@ -106,26 +106,26 @@ The Transactions view gives an end-to-end snapshot of every action done by the W | Code | Post-processed | Description | ERP Message | |------|---------------|-------------|-------------| | `STK.ADJ` | Yes | Stock quantity adjusted (SmartUI/RF/workstation) | STV | -| `STK.ASN` | No | Stock created in ASN container (pre-notified) | — | -| `STK.CREATE` | No | Stock created manually or from ASN loose stock | — | -| `STK.DELETE` | No | Stock line deleted (fused stock split) | — | -| `STK.KIT.COMP` | No | Stock consumed for kit assembly | — | -| `STK.KIT.UCOMP` | No | Stock obtained from kit disassembly | — | +| `STK.ASN` | No | Stock created in ASN container (pre-notified) | - | +| `STK.CREATE` | No | Stock created manually or from ASN loose stock | - | +| `STK.DELETE` | No | Stock line deleted (fused stock split) | - | +| `STK.KIT.COMP` | No | Stock consumed for kit assembly | - | +| `STK.KIT.UCOMP` | No | Stock obtained from kit disassembly | - | | `STK.KIT.MOUNT` | Yes | Kit assembled | KST | | `STK.KIT.UMOUNT` | Yes | Kit disassembled | UNK | -| `STK.LOAD` | No | Stock moved during truck loading | — | -| `STK.LOCATE` | No | Stock moved to storage via putaway task | — | -| `STK.MOVE` | No | Stock moved manually (or inside container after CON.MOVE) | — | -| `STK.PICKING` | No | Picking confirmed (stock moved from source to picking container) | — | -| `STK.RECEP` | No | Stock created during reception (supplier/return/blind) | — | +| `STK.LOAD` | No | Stock moved during truck loading | - | +| `STK.LOCATE` | No | Stock moved to storage via putaway task | - | +| `STK.MOVE` | No | Stock moved manually (or inside container after CON.MOVE) | - | +| `STK.PICKING` | No | Picking confirmed (stock moved from source to picking container) | - | +| `STK.RECEP` | No | Stock created during reception (supplier/return/blind) | - | | `STK.REP.001` | Yes | Pre-notified loose stock replenished (auto warehouse) | SRO | | `STK.REP.CNL` | Yes | Pre-notified loose stock canceled (auto warehouse) | SRK | -| `STK.SCR` | No | Stock scrapped from RF terminal | — | -| `STK.SEND.L&F` | No | Stock sent to Lost & Found | — | -| `STK.SHIPPED` | No | Stock shipped (container status = Shipped) | — | +| `STK.SCR` | No | Stock scrapped from RF terminal | - | +| `STK.SEND.L&F` | No | Stock sent to Lost & Found | - | +| `STK.SHIPPED` | No | Stock shipped (container status = Shipped) | - | | `STK.SPLIT` | Yes | Stock UoM broken down (picking or workstation split) | STV (split) | -| `STK.UMERGE` | No | Fused stock line split/un-merged | — | -| `STK.VASDONE` | No | VAS template applied to stock | — | +| `STK.UMERGE` | No | Fused stock line split/un-merged | - | +| `STK.VASDONE` | No | VAS template applied to stock | - | **Key data fields by transaction:** - `STK.ADJ`: LocationCode, ContainerCode, Quantity, TaskNumber @@ -161,8 +161,8 @@ The Transactions view gives an end-to-end snapshot of every action done by the W | Code | Post-processed | Description | ERP Message | |------|---------------|-------------|-------------| | `REC.CLS` | Yes | Receipt manually or auto-closed (with stock) | REF | -| `REC.CNL` | No | Receipt manually canceled | — | -| `REC.CST` | No | Receipt status changed (Pending → Receiving) | — | +| `REC.CNL` | No | Receipt manually canceled | - | +| `REC.CST` | No | Receipt status changed (Pending → Receiving) | - | --- @@ -173,8 +173,8 @@ The Transactions view gives an end-to-end snapshot of every action done by the W | `OUT.CLS` | Yes | Shipping order closed/force-closed | SOF | | `OUT.CNL` | Yes | Shipping order canceled | SOF | | `OUT.CST` | Yes | Shipping order status changed | SOC | -| `OUT.GRP` | No | Shipping order added to group/fusion | — | -| `OUT.UNG` | No | Shipping order removed from group/fusion | — | +| `OUT.GRP` | No | Shipping order added to group/fusion | - | +| `OUT.UNG` | No | Shipping order removed from group/fusion | - | --- @@ -182,11 +182,11 @@ The Transactions view gives an end-to-end snapshot of every action done by the W | Code | Post-processed | Description | ERP Message | |------|---------------|-------------|-------------| -| `ROU.CLS` | No | Route closed | — | -| `ROU.CNL` | No | Route canceled | — | -| `ROU.CST` | No | Route status changed | — | +| `ROU.CLS` | No | Route closed | - | +| `ROU.CNL` | No | Route canceled | - | +| `ROU.CST` | No | Route status changed | - | | `LOAD.CLS` | Yes | Load closed (manual or auto on route close) | LOF | -| `LOAD.CST` | No | Load paused or reactivated | — | +| `LOAD.CST` | No | Load paused or reactivated | - | --- @@ -213,7 +213,7 @@ The Transactions view gives an end-to-end snapshot of every action done by the W |------|---------------|-------------|-------------| | `WOR.CLS.001` | Yes | Work order (kits/manufacturing) closed | WOF | | `WOR.CNL.001` | Yes | Work order canceled | WOF | -| `WOR.CST.001` | No | Work order status changed | — | +| `WOR.CST.001` | No | Work order status changed | - | --- @@ -259,7 +259,7 @@ The Transactions view gives an end-to-end snapshot of every action done by the W | Code | Post-processed | Description | ERP Message | |------|---------------|-------------|-------------| -| `SCR.DET` | No | Stock contrast detail (intermediate) | — | +| `SCR.DET` | No | Stock contrast detail (intermediate) | - | | `SCR.REQ` | Yes | Stock contrast requested | WSC | | `STOCKSYNC.ASKED` | Yes | Full warehouse stock sync to ERP requested | WSC | @@ -275,7 +275,7 @@ The Transactions view gives an end-to-end snapshot of every action done by the W ## Notification Events -Notification Events are operational alerts that fire when specific conditions arise. They are distinct from transactions — they do not generate ERP messages, but they can trigger SCEM subscriptions (email, SMS, web alerts). +Notification Events are operational alerts that fire when specific conditions arise. They are distinct from transactions - they do not generate ERP messages, but they can trigger SCEM subscriptions (email, SMS, web alerts). See [Supply Chain Event Management](../modules/supply-chain-event.md) for subscription management. @@ -345,13 +345,13 @@ Additional notification events are defined by optional modules: ## Related -- [ERP Interface](erp-interface.md) — ERP messages triggered by post-processed transactions -- [Stock](stock.md) — STK.ADJ, STK.MOVE, STK.PICKING -- [Container](container.md) — CON.* transactions -- [Inbound Order](order-inbound.md) — INO.CST, INO.CLS → ROC, ROF -- [Outbound Order](order-outbound.md) — OUT.CST, OUT.CLS → SOC, SOF -- [Count](count.md) — COU.END → COF -- [Quality Control](quality-control.md) — CST.STK → STC -- [Application Dictionary](../architecture/application-dictionary.md) — Commands and Events that generate transactions -- [Security](../architecture/security.md) — Transactions as audit trail -- [Supply Chain Event Management](../modules/supply-chain-event.md) — Notification event subscriptions +- [ERP Interface](erp-interface.md) - ERP messages triggered by post-processed transactions +- [Stock](stock.md) - STK.ADJ, STK.MOVE, STK.PICKING +- [Container](container.md) - CON.* transactions +- [Inbound Order](order-inbound.md) - INO.CST, INO.CLS → ROC, ROF +- [Outbound Order](order-outbound.md) - OUT.CST, OUT.CLS → SOC, SOF +- [Count](count.md) - COU.END → COF +- [Quality Control](quality-control.md) - CST.STK → STC +- [Application Dictionary](../architecture/application-dictionary.md) - Commands and Events that generate transactions +- [Security](../architecture/security.md) - Transactions as audit trail +- [Supply Chain Event Management](../modules/supply-chain-event.md) - Notification event subscriptions diff --git a/wiki/concepts/warehouse-designer.md b/wiki/concepts/warehouse-designer.md index 1986628..1fb07ac 100644 --- a/wiki/concepts/warehouse-designer.md +++ b/wiki/concepts/warehouse-designer.md @@ -61,7 +61,7 @@ Defines the physical dimensions of containers used in the warehouse. The contain | Gauge | Maximum deviation in width due to cargo slump (mm). Effective width = empty width + 2× gauge | | Shippable as package | Can be shipped directly in eCommerce process | -**Container relationships:** Each container type can declare interior container types — a maximum number of smaller containers that fit inside (nesting/palletizing rules). Relationships are added, deleted, or edited independently. +**Container relationships:** Each container type can declare interior container types - a maximum number of smaller containers that fit inside (nesting/palletizing rules). Relationships are added, deleted, or edited independently. **Deletion:** Cannot delete a container type in use by any location. System shows total locations affected + breakdown by warehouse before allowing deletion. @@ -139,7 +139,7 @@ Editing an equipment type can cause incompatibilities in location searches or or ### Equipment -A physical means of transporting containers through the warehouse — operators with carts, forklifts, manual handling devices, etc. Equipment is associated with tasks: putaway, replenishment, picking, shipping. +A physical means of transporting containers through the warehouse - operators with carts, forklifts, manual handling devices, etc. Equipment is associated with tasks: putaway, replenishment, picking, shipping. **Attributes:** @@ -241,7 +241,7 @@ Full three-dimensional representation of the warehouse: | Feature | Description | |---------|-------------| | General status | Locked aisles (inbound/outbound/both), AS/RS PK work modes, PIE and route status, MP preparation zones | -| Station status | Click any station: capacity, occupation %, work mode, etc. — varies by station type | +| Station status | Click any station: capacity, occupation %, work mode, etc. - varies by station type | | Shelf status | Click any shelf: free/occupied/blocked locations summary | | Container search | Find a specific container (LPN) by code | | Item search | Locate all stock of a specific item across the warehouse | @@ -300,8 +300,8 @@ Visual activity intensity map overlaid on 2D view: ## Related -- [[location]] — Rack types and storage zones directly configure location properties -- [[stations]] — Stations created in EasyS; Warehouse Designer edits docks/stages/shelves post-transfer -- [[container]] — Container types define dimensions used in warehouse design -- [[putaway]] — Storage zones and subwarehouses configure putaway strategy targeting -- [[replenishment]] — Work zones define equipment eligibility for replenishment tasks +- [[location]] - Rack types and storage zones directly configure location properties +- [[stations]] - Stations created in EasyS; Warehouse Designer edits docks/stages/shelves post-transfer +- [[container]] - Container types define dimensions used in warehouse design +- [[putaway]] - Storage zones and subwarehouses configure putaway strategy targeting +- [[replenishment]] - Work zones define equipment eligibility for replenishment tasks diff --git a/wiki/concepts/weights.md b/wiki/concepts/weights.md index c270e49..02370a4 100644 --- a/wiki/concepts/weights.md +++ b/wiki/concepts/weights.md @@ -9,7 +9,7 @@ related: - concepts/product-item.md - concepts/reception.md - concepts/stations.md - - modules/pie.md + - concepts/mechanical-elements.md last_compiled: "2026-04-17" --- @@ -17,7 +17,7 @@ last_compiled: "2026-04-17" ## Overview -EasyWMS tracks **five distinct weight fields** on every container and **two weight fields** on every stock line. These fields support reception sanity checks, detection of shrinkage or miscounts at the PIE (weighing station), and variable-weight items (e.g., meat, fish, fruit sold by the kilo). Understanding which field is updated by which event — and which one the shipping / reporting logic reads — is critical: the French UI term *"poids théorique"* is ambiguous (it can mean either of two different fields). +EasyWMS tracks **five distinct weight fields** on every container and **two weight fields** on every stock line. These fields support reception sanity checks, detection of shrinkage or miscounts at the PIE (weighing station), and variable-weight items (e.g., meat, fish, fruit sold by the kilo). Understanding which field is updated by which event - and which one the shipping / reporting logic reads - is critical: the French UI term *"poids théorique"* is ambiguous (it can mean either of two different fields). ## Container-level weight fields @@ -31,7 +31,7 @@ Five fields, each with a distinct trigger and formula. | **Real Weight** | Poids réel | `max(Calculated Weight, Theoretical Scale Weight)` | Recomputed automatically when its inputs change | | **Theoretical Scale Weight** | Poids théorique (balance) | Scale Weight − adjustments | Set after PIE pass, then updated by adjustments | -> ⚠️ **Translation trap** — *"Poids théorique"* in French maps to **two different fields** in English: +> ⚠️ **Translation trap** - *"Poids théorique"* in French maps to **two different fields** in English: > - **Poids théorique (article)** = `Theoretical Weight` (from the item master) > - **Poids théorique (balance)** = `Theoretical Scale Weight` (from the scale, minus adjustments) > @@ -54,13 +54,13 @@ On each stock line (`Stock` record): | **Poids (kg)** | Real weight of the line | | **Poids théorique (kg)** | Theoretical weight of the line, from the item master | -Stock-line weights are updated on stock adjustments, weighings, and custom processes **only when the item is configured as variable-weight**. The PIE does **not** update stock-line weights directly — it updates container-level fields only. +Stock-line weights are updated on stock adjustments, weighings, and custom processes **only when the item is configured as variable-weight**. The PIE does **not** update stock-line weights directly - it updates container-level fields only. ## Behavior at stock creation -- **Real weight of the stock (line)** starts at `0` — it is only populated by a PIE pass, a `StockAdjust` on a variable-weight item, or a custom. +- **Real weight of the stock (line)** starts at `0` - it is only populated by a PIE pass, a `StockAdjust` on a variable-weight item, or a custom. - **Theoretical weight of the stock (line)** is computed immediately from the item master. -- **Container tare weight** (pallet type weight in EasyS) is **frozen at container creation** — changing the tare in EasyS later **does not propagate** to existing containers. Only newly created containers pick up the new tare. +- **Container tare weight** (pallet type weight in EasyS) is **frozen at container creation** - changing the tare in EasyS later **does not propagate** to existing containers. Only newly created containers pick up the new tare. ## PIE pass @@ -97,11 +97,11 @@ The workflow **`Stock_CheckWeightToCreateStockInContainer_UI`** runs at stock cr - Compares the entered weight against the item master. - If the item is variable-weight and the tolerance is exceeded, it **raises an RFT alert** (does not reject). -> Reject-rather-than-alert behaviour at the PIE requires a custom workflow — see *Open questions* below. +> Reject-rather-than-alert behaviour at the PIE requires a custom workflow - see *Open questions* below. ## Worked examples -### Fixed-weight item — 25 kg pallet, item weighs 250 kg +### Fixed-weight item - 25 kg pallet, item weighs 250 kg | Step | Calculated | Scale | Theoretical (item) | Real | Theoretical Scale | |---|---|---|---|---|---| @@ -114,9 +114,9 @@ The workflow **`Stock_CheckWeightToCreateStockInContainer_UI`** runs at stock cr |---|---|---|---|---|---| | New pallet | 280 | 280 | 274 | 274 | 280 | -> Theoretical (item) = 250 (goods) + 24 (new pallet tare). The older pallet keeps 275 — confirming that the container tare is frozen at creation. +> Theoretical (item) = 250 (goods) + 24 (new pallet tare). The older pallet keeps 275 - confirming that the container tare is frozen at creation. -### Variable-weight item — 10 bags, 100 kg declared +### Variable-weight item - 10 bags, 100 kg declared | Step | Calculated | Scale | Theoretical (item) | Real | Theoretical Scale | |---|---|---|---|---|---| @@ -134,8 +134,8 @@ The workflow **`Stock_CheckWeightToCreateStockInContainer_UI`** runs at stock cr ## Related -- [[container]] — all five weight fields are attributes of the container ; see "SSCC and weights" on the container page -- [[stock]] — the two stock-line fields, updated for variable-weight items -- [[product-item]] — logistic profile carries the variable-weight and "Poids moyen" flags, item master holds unit weight -- [[reception]] — receipt line can carry the expected weight used by "Poids moyen" at stock creation -- [[stations]] — PIE station type drives scale-weight capture +- [[container]] - all five weight fields are attributes of the container ; see "SSCC and weights" on the container page +- [[stock]] - the two stock-line fields, updated for variable-weight items +- [[product-item]] - logistic profile carries the variable-weight and "Poids moyen" flags, item master holds unit weight +- [[reception]] - receipt line can carry the expected weight used by "Poids moyen" at stock creation +- [[stations]] - PIE station type drives scale-weight capture diff --git a/wiki/glossary.md b/wiki/glossary.md index 7eae4ab..6b02dee 100644 --- a/wiki/glossary.md +++ b/wiki/glossary.md @@ -1,5 +1,5 @@ --- -title: "Glossary — EasyWMS / Mecalux" +title: "Glossary - EasyWMS / Mecalux" type: glossary sources: - wiki/concepts/container.md @@ -86,7 +86,7 @@ related: last_compiled: "2026-04-17" --- -# Glossary — EasyWMS / Mecalux +# Glossary - EasyWMS / Mecalux All terms specific to EasyWMS (by Mecalux), including product names, abbreviations, AD element names, ERP message codes, and field names. General WMS/logistics terms are included only when EasyWMS usage differs from industry standard. @@ -109,8 +109,8 @@ Self-navigating forklift or carrier used in automatic warehouses. Communicates w **AI (Application Identifier)** GS1 prefix code embedded in a barcode to identify the type of data that follows. Examples: AI(00) = SSCC, AI(02) = GTIN, AI(10) = lot, AI(17) = expiry date. -**ALM station (Almacén — Storage)** -Station type used as a pure storage entry/exit point. Containers are deposited at ALM stations for AS/RS retrieval to racks. In the FR/EN translation matrix: ALM (ES) = MAG (FR) = AIS (EN). See [Mechanical Elements — Station codes](concepts/mechanical-elements.md#3-station-codes--fr--es--en-matrix). +**ALM station (Almacén - Storage)** +Station type used as a pure storage entry/exit point. Containers are deposited at ALM stations for AS/RS retrieval to racks. In the FR/EN translation matrix: ALM (ES) = MAG (FR) = AIS (EN). See [Mechanical Elements - Station codes](concepts/mechanical-elements.md#3-station-codes---fr--es--en-matrix). **AP / APC / APR (Apilador de Paletas)** Pallet stacker machines. **AP** = Empty Pallet Stacker, **APC** = Chain Pallet Stacker, **APR** = Roller Pallet Stacker. See [Mechanical Elements](concepts/mechanical-elements.md#1-machine--equipment-acronyms-es--en). @@ -119,10 +119,10 @@ Pallet stacker machines. **AP** = Empty Pallet Stacker, **APC** = Chain Pallet S Automatic Pallet Shuttle variant using supercapacitors (SUPERCAP) instead of batteries. Faster charge cycles, shorter standalone runtime. See [Mechanical Elements](concepts/mechanical-elements.md). **ATC (Abatible Transportador de Cadenas)** -Lift-up gate Chain Conveyor — chain conveyor with a retractable gate for pedestrian passage. See [Mechanical Elements](concepts/mechanical-elements.md). +Lift-up gate Chain Conveyor - chain conveyor with a retractable gate for pedestrian passage. See [Mechanical Elements](concepts/mechanical-elements.md). **Automatic Aisle** -EasyS station element representing a stacker crane (TK) or Miniload. Linked to a rack; all locations inside the rack are reachable only through this aisle. See [Galileo Simulation — §3.4](operations/galileo-simulation.md#34-automatic-aisle-tk--miniload). +EasyS station element representing a stacker crane (TK) or Miniload. Linked to a rack; all locations inside the rack are reachable only through this aisle. See [Galileo Simulation - §3.4](operations/galileo-simulation.md#34-automatic-aisle-tk--miniload). **APS (Automated Pallet Shuttle)** 3D compact storage system managed by the APS3D module. Locations tagged as APS or APSFIFO. The Fleet Manager controller coordinates lifts, shuttles, and conveyors. See [APS3D](modules/aps3d.md). @@ -175,13 +175,13 @@ Putaway strategy variant applied **before** standard location strategies, used f A container whose stock is assigned to a specific shipping order. The `Is client LPN` flag is true. Client containers are created during picking and track the prepared stock from pick face to shipping dock. See [Container](concepts/container.md). **Client stock** -Stock that is inside a client container — i.e., stock that has been prepared for a specific outbound order. Cannot be adjusted without first un-preparing the shipment. +Stock that is inside a client container - i.e., stock that has been prepared for a specific outbound order. Cannot be adjusted without first un-preparing the shipment. **CMC (Container Movement Confirmation)** Inbound ERP request message. Asks the WMS to move a container between locations. Generates a Manual Movement task. See [ERP Interface](concepts/erp-interface.md). **CME station (Control Miniload Entrée)** -Control station at the entry of a Miniload/TK. If the downstream TE is full, CME recirculates the container to avoid collision. Must report a "route full" status (3) when saturated — see [Stations](concepts/stations.md#route-configuration-in-easys-robotics) and [Galileo Integration](architecture/galileo-integration.md). +Control station at the entry of a Miniload/TK. If the downstream TE is full, CME recirculates the container to avoid collision. Must report a "route full" status (3) when saturated - see [Stations](concepts/stations.md#route-configuration-in-easys-robotics) and [Galileo Integration](architecture/galileo-integration.md). **Conclure (replenishment)** French SmartUI label for the **Top-off / Particular Demand** replenishment strategy. Pre-brings stock based on reserved outbound orders on the picking locations. See [Replenishment](concepts/replenishment.md). @@ -245,10 +245,10 @@ Automatic conveyor element that routes containers to different destinations base Process of moving containers between locations to optimize space and picking efficiency. Two strategies: **rotation** (by ABC class) and **shipping** (pre-position for orders). Automatic warehouse only. See [Defragmentation](concepts/defragmentation.md). **Division (location cart)** -A subdivision of a **Location cart** used for wave / group picking. Each division is identified and can be tied to a specific order or wave, so one cart holds several concurrent pickings without mixing stock. See [Picking](concepts/picking.md#location-carts-chariots-à-emplacement). +A subdivision of a **Location cart** used for wave / group picking. Each division is identified and can be tied to a specific order or wave, so one cart holds several concurrent pickings without mixing stock. See [Picking](concepts/picking.md#location-carts-chariots-à-emplacement-for-multi-order-picking). **DirectTransfer** -Value of the `` field in the `SOR(01|02)` shipping order message, used for inter-warehouse transfers. Closing the expedition at origin automatically generates an `ASO01` on destination, pre-creating the incoming ASN container. Deleting the container from SmartUI triggers `ASK01`. Both messages carry **no reference to the source shipping order**. See [Order Outbound](concepts/order-outbound.md#asn--directtransfer-flow) and [Reception](concepts/reception.md#directtransfer--inter-warehouse-asn-flow). +Value of the `` field in the `SOR(01|02)` shipping order message, used for inter-warehouse transfers. Closing the expedition at origin automatically generates an `ASO01` on destination, pre-creating the incoming ASN container. Deleting the container from SmartUI triggers `ASK01`. Both messages carry **no reference to the source shipping order**. See [Order Outbound](concepts/order-outbound.md#asn---directtransfer-flow) and [Reception](concepts/reception.md#directtransfer---inter-warehouse-asn-flow). **Delete_StockStatusJob_PR** Background job. Automatically removes time-expired stock quality locks. Runs every 15 minutes by default. See [Quality Control](concepts/quality-control.md). @@ -260,7 +260,7 @@ Multi-Carrier XML message used to **merge** (fuse) several outbound orders into Entity combining a carrier + consignee for a shipment. Holds tracking number, delivery note, and carrier label. Created when a shipping order is packaged at a Multi-Carrier station. See [Multi-Carrier](modules/multi-carrier.md). **Dialog (AD)** -An AD element type representing a multi-step operator flow — typically a wizard or guided process on the RF terminal or SmartUI. Examples: `ReceptionDialog`, `PickingDialog`, `CountDialog`. Each step is a form with specific validations. See [Application Dictionary](architecture/application-dictionary.md). +An AD element type representing a multi-step operator flow - typically a wizard or guided process on the RF terminal or SmartUI. Examples: `ReceptionDialog`, `PickingDialog`, `CountDialog`. Each step is a form with specific validations. See [Application Dictionary](architecture/application-dictionary.md). **DOM (Distributed Order Management)** EasyWMS module for multi-node warehouse networks. Orchestrates sales orders across nodes using a 5-stage engine (region → carrier → stock → capacity → strategies). See [DOM](modules/dom.md). @@ -269,17 +269,17 @@ EasyWMS module for multi-node warehouse networks. Orchestrates sales orders acro Inventory control process where count discrepancies or adjustments require a second approval by a supervisor/manager before being committed to stock. Controlled via item count profile and `DOUBLE_VALIDATION_ACTIVE` parameter. See [Stock Adjustment](concepts/stock-adjustment.md) and [Count](concepts/count.md). **DeleteEmptyContainers** -Station/location parameter that decides what happens to empty supports. Robotics default for automated locations: **Not Delete**. Picking stations (PK) may use `Delete` or `Ask` when operators physically remove empty containers. See [Galileo Simulation — §3.1](operations/galileo-simulation.md#31-location--container-settings). +Station/location parameter that decides what happens to empty supports. Robotics default for automated locations: **Not Delete**. Picking stations (PK) may use `Delete` or `Ask` when operators physically remove empty containers. See [Galileo Simulation - §3.1](operations/galileo-simulation.md#31-location--container-settings). **DTR (Document Technique de Référence)** -Reference document listing all technical elements for a robotics project (hardware, IPs, services, accounts) and the responsibility split between Mecalux and the client. Template on [Confluence](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000562515980). See [Robotics Project Lifecycle — §2](operations/robotics-project-lifecycle.md#2-dtr--document-technique-de-référence). +Reference document listing all technical elements for a robotics project (hardware, IPs, services, accounts) and the responsibility split between Mecalux and the client. Template on [Confluence](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000562515980). See [Robotics Project Lifecycle - §2](operations/robotics-project-lifecycle.md#2-dtr---document-technique-de-référence). --- ## E **Exiger (replenishment)** -French SmartUI label for the **Dynamic / On-Demand** replenishment strategy — replenishment triggered when picking consumption empties a picking location, regardless of threshold. See [Replenishment](concepts/replenishment.md). +French SmartUI label for the **Dynamic / On-Demand** replenishment strategy - replenishment triggered when picking consumption empties a picking location, regardless of threshold. See [Replenishment](concepts/replenishment.md). **Est renseigné (Count)** SmartUI flag on a Count Order Line (`CountOrderLineVList`) that controls whether the line is **informed** (expected quantity visible to operator) or **blind** (hidden). Historical ERP sends it via COR `IsInformed`; SmartUI can toggle it per line afterwards. See [Count](concepts/count.md#blind-vs-informed-mode). @@ -288,31 +288,31 @@ SmartUI flag on a Count Order Line (`CountOrderLineVList`) that controls whether Barcode standard for item identification. EAN-13 is the most common; used on item labels and for carton identification. Related to GS1/GTIN standards. See [Labels](concepts/labels.md). **EasyS** -Mecalux's layout configuration tool for EasyWMS, and **3D robotics simulator** that speaks the same protocol as GALILEO. Used to: (1) define physical warehouse topology — aisles, racks, locations, stations, equipment groups, routes; (2) run a full simulation with an EasyWMS Gateway for development and demos (port 3000, Start → Simulation 3D, PIE injection via PIE Info tab). Shared demo VM at Mecalux France: ALL on LYOITSW02 (`10.58.10.75`). See [Galileo Simulation](operations/galileo-simulation.md). +Mecalux's layout configuration tool for EasyWMS, and **3D robotics simulator** that speaks the same protocol as GALILEO. Used to: (1) define physical warehouse topology - aisles, racks, locations, stations, equipment groups, routes; (2) run a full simulation with an EasyWMS Gateway for development and demos (port 3000, Start → Simulation 3D, PIE injection via PIE Info tab). Shared demo VM at Mecalux France: ALL on LYOITSW02 (`10.58.10.75`). See [Galileo Simulation](operations/galileo-simulation.md). **EasyWMS Gateway** Windows service (`EasyWMSGateway2015`) that brokers all communication between EasyWMS and the automation layer (GALILEO in production, EasyS in simulation). Installed at `C:\Program Files\Mecalux\EasyWMS Gateway 2015`; config at `C:\ProgramData\Mecalux\EasyWMS Gateway 2015\Config\MainObject.config` (tenantCode + TokenUser); logs at `C:\ProgramData\Mecalux\EasyWMS Gateway 2015\Logs\AllLog.log`; uses TCP port 3000. See [Galileo Integration](architecture/galileo-integration.md). **End (GALILEO message)** -GALILEO-to-WMS message that signals a movement has completed. Carries an `EndErrorCode` (0 = OK, 1 = deposit error, 2 = extraction error, 4 = inconsistent order — config mismatch, 7 = gauge error). Processed by `Galileo_EndCreatedEventHandler_PR`. See [Galileo Integration — End](architecture/galileo-integration.md#3-end-log--end0-end1-). +GALILEO-to-WMS message that signals a movement has completed. Carries an `EndErrorCode` (0 = OK, 1 = deposit error, 2 = extraction error, 4 = inconsistent order - config mismatch, 7 = gauge error). Processed by `Galileo_EndCreatedEventHandler_PR`. See [Galileo Integration - End](architecture/galileo-integration.md#3-end-log--end0-end1-). **EndErrorCode** -Numeric code attached to a GALILEO End message. Value `4` is the most common diagnostic — indicates a configuration drift between EasyWMS and GALILEO (missing location, wrong allowed container type, X/Y out of range, impossible crossing). See [Galileo Troubleshooting — §3.1](operations/galileo-troubleshooting.md#31-enderrorcode--4-most-frequent). +Numeric code attached to a GALILEO End message. Value `4` is the most common diagnostic - indicates a configuration drift between EasyWMS and GALILEO (missing location, wrong allowed container type, X/Y out of range, impossible crossing). See [Galileo Troubleshooting - §3.1](operations/galileo-troubleshooting.md#31-enderrorcode--4-most-frequent). **Empileur (EMP / APL)** Pallet stacker station (code 13). See [Stations](concepts/stations.md) and [Mechanical Elements](concepts/mechanical-elements.md). **EMS (Sistema electrovía aérea)** -Overhead Electric Monorail — suspended pallet transport system. See [Mechanical Elements](concepts/mechanical-elements.md). +Overhead Electric Monorail - suspended pallet transport system. See [Mechanical Elements](concepts/mechanical-elements.md). **ECB (Empty Container Buffer)** -Station type 55 — buffer specifically for empty containers waiting to be stacked or reused. See [Stations](concepts/stations.md). +Station type 55 - buffer specifically for empty containers waiting to be stacked or reused. See [Stations](concepts/stations.md). **Event (GALILEO message)** -GALILEO-to-WMS message declaring container presence at a checkpoint. Primary source is the PIE (barcode + gauge + weight). Content varies by station; flags `65536`=OK, `256`=barcode error, `512`=recovered, `1024`/`66560`=empty OK, `4`=overheight. Processed by `Galileo_PIEEventHandler_PR`. See [Galileo Integration — Event](architecture/galileo-integration.md#1-event-log--event). +GALILEO-to-WMS message declaring container presence at a checkpoint. Primary source is the PIE (barcode + gauge + weight). Content varies by station; flags `65536`=OK, `256`=barcode error, `512`=recovered, `1024`/`66560`=empty OK, `4`=overheight. Processed by `Galileo_PIEEventHandler_PR`. See [Galileo Integration - Event](architecture/galileo-integration.md#1-event-log--event). **ETQ (Étiqueteuse)** -Labeller station type 58 — an automatic labelling machine through which a container passes to receive a printed label. See [Stations](concepts/stations.md). +Labeller station type 58 - an automatic labelling machine through which a container passes to receive a printed label. See [Stations](concepts/stations.md). **eCommerce module** EasyWMS add-on module for e-commerce fulfillment. JIT reception flow: single-unit orders go to packing, multi-unit to ungrouping, no-order stock to storage. See [eCommerce](modules/ecommerce.md). @@ -326,7 +326,7 @@ In EasyWMS, an equipment is a physical device (forklift, hand truck, conveyor se **ERP Interface** The set of standardized messages exchanged between EasyWMS and the customer's ERP system (SAP, Oracle, etc.). Three-letter codes identify each message type (ROR, SOR, ASN, ROF, SOF, etc.). See [ERP Interface](concepts/erp-interface.md). -**ET station (Estación de Tránsito — Transit)** +**ET station (Estación de Tránsito - Transit)** Station type used as an intermediate buffer between two zones that cannot directly route to each other. A conveyor element in EasyS; appears in the "Automatic elements" group. Required for multi-zone replenishment flows. See [Stations](concepts/stations.md). **Event (AD)** @@ -351,7 +351,7 @@ Shipping/storage logic where the oldest stock (by receipt date) is consumed firs **Fleet Manager** Controller software/hardware that coordinates APS3D shuttle movements, lifts, and conveyors. Communicates with EasyWMS via the Fleet Manager protocol. See [APS3D](modules/aps3d.md) and [Stations](concepts/stations.md). -**Fusion (order fusion) — synonym Merge** +**Fusion (order fusion) - synonym Merge** Grouping of two or more shipping orders into a single picking wave for joint preparation. Orders in a fusion share picking tasks. See [Shipping](concepts/shipping.md). --- @@ -362,10 +362,10 @@ Grouping of two or more shipping orders into a single picking wave for joint pre Windows service provided by Mecalux that bridges Easy WMS workflows and the PostgreSQL exchange tables used by the AGV module. Serializes AGV tasks into `agv_outputqueue` / `agv_eag`, reads fleet manager responses from `agv_inputqueue` / `agv_age` / `agv_ags`. Polls at configurable intervals (default 1 second). Creates all PostgreSQL tables and sequences on first startup. Config file: `C:\ProgramData\Mecalux\EasyWMS GatewayAGV 2015\`. See [AGV](modules/agv.md) and [AGV Installation Guide](operations/agv-installation.md). **Galileo** -Mecalux's production **Transport Management System (TMS)** — the automation layer that drives conveyors, stacker cranes (TK/Miniload), shuttles, AGVs and lifts. Has **no predictive vision**; only requests orders from EasyWMS and executes them. Also used inside EasyS as the label of the conveyor route type (opposed to Manual / Virtual) — a "Galileo" route is a physical hop that requires Gateway communication. See [Galileo Integration](architecture/galileo-integration.md) and [Stations](concepts/stations.md). +Mecalux's production **Transport Management System (TMS)** - the automation layer that drives conveyors, stacker cranes (TK/Miniload), shuttles, AGVs and lifts. Has **no predictive vision**; only requests orders from EasyWMS and executes them. Also used inside EasyS as the label of the conveyor route type (opposed to Manual / Virtual) - a "Galileo" route is a physical hop that requires Gateway communication. See [Galileo Integration](architecture/galileo-integration.md) and [Stations](concepts/stations.md). **Galileo_PIEEventHandler_PR / Galileo_SearchCreatedEventHandler_PR / Galileo_EndCreatedEventHandler_PR** -The three core workflows consuming GALILEO messages: PIE events (inbound identification), Search requests (next-hop routing — can fire dozens per second, do not activate instance tracing carelessly), and End notifications (movement complete / error). See [Galileo Integration — AD entry points](architecture/galileo-integration.md#application-dictionary-entry-points). +The three core workflows consuming GALILEO messages: PIE events (inbound identification), Search requests (next-hop routing - can fire dozens per second, do not activate instance tracing carelessly), and End notifications (movement complete / error). See [Galileo Integration - AD entry points](architecture/galileo-integration.md#application-dictionary-entry-points). **GalileoMovTrackingCreateCommand** Preferred AD command for pushing a movement order to GALILEO (over the deprecated `GalileoMovTrackingCreateChangingTargetCommand`). Transition: movement `Generated` → `In progress`, container placed on virtual location **Mov**. See [Galileo Integration](architecture/galileo-integration.md). @@ -393,10 +393,10 @@ Mecalux cobot integration protocol. The Cobot module connects robotic picking ar Period immediately after MEP (go-live) during which the dev team handles bug fixes on the `develop` branch. Ends when the project is transferred to the Support team (TLM). See [Git Branch Lifecycle](operations/git-branch-lifecycle.md). **IdentError / IdentErrorType** -Enum of rejection reason codes (PIE barcode unreadable, overheight, overhang, overweight, no ASN match…). Different IdentErrors can route containers to different reject destinations using **reject routes** (displayed in red in EasyS). Reference: [IdentErrorType doc](https://msscc.mecalux.com/documentation/Development/master/ES/apis/easywms/Domain/IdentErrorType.md). See [Galileo Simulation — §3.11](operations/galileo-simulation.md#311-reject-configuration). +Enum of rejection reason codes (PIE barcode unreadable, overheight, overhang, overweight, no ASN match…). Different IdentErrors can route containers to different reject destinations using **reject routes** (displayed in red in EasyS). Reference: [IdentErrorType doc](https://msscc.mecalux.com/documentation/Development/master/ES/apis/easywms/Domain/IdentErrorType.md). See [Galileo Simulation - §3.11](operations/galileo-simulation.md#311-reject-configuration). **IMS (Sistema electrovía invertida)** -Inverted Electric Monorail — floor-based inverted monorail variant of EMS. See [Mechanical Elements](concepts/mechanical-elements.md). +Inverted Electric Monorail - floor-based inverted monorail variant of EMS. See [Mechanical Elements](concepts/mechanical-elements.md). --- @@ -429,10 +429,10 @@ Performance metrics tracked in the Data Analytics module or displayed on the 3PL ## L **Location cart (chariot à emplacement)** -Mobile cart divided into numbered **divisions**, used at the RFT for wave and group picking so a single operator prepares multiple orders in one pass without mixing stock. Requires specific SmartUI configuration (cart type, division count, assignment to work area). See [Picking](concepts/picking.md#location-carts-chariots-à-emplacement). +Mobile cart divided into numbered **divisions**, used at the RFT for wave and group picking so a single operator prepares multiple orders in one pass without mixing stock. Requires specific SmartUI configuration (cart type, division count, assignment to work area). See [Picking](concepts/picking.md#location-carts-chariots-à-emplacement-for-multi-order-picking). **LogisticAttributeCreateLogisticCaptureCommand** -Run Command that adds a **capture mode** to an existing logistic attribute. Used with `CaptureMode = 2` and `CaptureProcess = 2` to create an attribute with **no capture mode** — that is, one auto-generated by custom code rather than prompted on the RFT/SmartUI. See [Product / Item](concepts/product-item.md#creating-a-logistic-attribute-without-a-capture-mode). +Run Command that adds a **capture mode** to an existing logistic attribute. Used with `CaptureMode = 2` and `CaptureProcess = 2` to create an attribute with **no capture mode** - that is, one auto-generated by custom code rather than prompted on the RFT/SmartUI. See [Product / Item](concepts/product-item.md#creating-a-logistic-attribute-without-a-capture-mode). **LneTrmAlternative** Sub-field of `` in `SOR(01|02)`. Boolean flag enabling the **substitute item** feature at line level. When `true`, the WMS may ship the configured substitute items (see shipping profile mode: Partiel / Substitution / Tout ou rien) if the primary item has insufficient stock. Returned in `SOF` alongside `LneDIsAlternative` to flag the actual substitute used. See [Product / Item](concepts/product-item.md#alternative--substitute-items) and [Order Outbound](concepts/order-outbound.md#alternative-items-sor-flag--sof-feedback). @@ -478,22 +478,22 @@ A stock or container relocation performed without generating a task. Eight move Automatic warehouse station where containers exit the system onto multiple possible conveyor lanes. See [Stations](concepts/stations.md). **ME / TE (Aisle Inbound Conveyor / Table d'entrée)** -Station type 9 — the conveyor at the entry of a TK/Miniload. Can hold multiple containers (layout uses Positions + Stack); configure `Logical X = 991` except for tables embedded in the rack. FR: TE, ES: ME, EN: Input Conveyor (IC). See [Stations](concepts/stations.md) and [Galileo Simulation — §3.8](operations/galileo-simulation.md#38-entry--outbound-tables-te--ts-on-the-tk). +Station type 9 - the conveyor at the entry of a TK/Miniload. Can hold multiple containers (layout uses Positions + Stack); configure `Logical X = 991` except for tables embedded in the rack. FR: TE, ES: ME, EN: Input Conveyor (IC). See [Stations](concepts/stations.md) and [Galileo Simulation - §3.8](operations/galileo-simulation.md#38-entry--outbound-tables-te--ts-on-the-tk). **MS / TS (Outbound Conveyor / Table de sortie)** -Station type 10 — the outbound conveyor of a TK/Miniload. Shares the Positions + Stack configuration pattern with ME/TE. FR: TS, ES: MS, EN: Output Conveyor (OC). See [Stations](concepts/stations.md). +Station type 10 - the outbound conveyor of a TK/Miniload. Shares the Positions + Stack configuration pattern with ME/TE. FR: TS, ES: MS, EN: Output Conveyor (OC). See [Stations](concepts/stations.md). **MP / TP (Preparation Zone / Table de préparation)** -Station type 16. Preparation tables linked to a picking station (PK) where operators deposit picked stock. Routes: **Manual** PK → MP, **Galileo** MP → outbound table, **Virtual** MP → consolidation. Assignment mode (Automatic / Manual) set via **Menu → Control → Workstations**. In manual mode, tasks do not generate until the outbound order is assigned to a table. See [Picking — PK/MP setup](concepts/picking.md#pk--mp-setup-and-assignment-mode). +Station type 16. Preparation tables linked to a picking station (PK) where operators deposit picked stock. Routes: **Manual** PK → MP, **Galileo** MP → outbound table, **Virtual** MP → consolidation. Assignment mode (Automatic / Manual) set via **Menu → Control → Workstations**. In manual mode, tasks do not generate until the outbound order is assigned to a table. See [Picking - PK/MP setup](concepts/picking.md#pk--mp-setup-and-assignment-mode). **Miniload (ML / STL / TK)** -Light-load automated stacker crane used for bins/cases (typically ≤ 50–100 kg per load). Nomenclature: `ML` = Miniload, `B` (post-ML) = Bicolumn, `EPSF` = pelle simple fond (1 charge), `EPDF` = pelle double fond (1 charge, double-depth rack), `ECDF` = courroie double fond (2 charges). Each model drives the TE/TS table configuration in EasyS. See [Mechanical Elements — §4](concepts/mechanical-elements.md#4-miniload-nomenclature-tk--ml). +Light-load automated stacker crane used for bins/cases (typically ≤ 50–100 kg per load). Nomenclature: `ML` = Miniload, `B` (post-ML) = Bicolumn, `EPSF` = pelle simple fond (1 charge), `EPDF` = pelle double fond (1 charge, double-depth rack), `ECDF` = courroie double fond (2 charges). Each model drives the TE/TS table configuration in EasyS. See [Mechanical Elements - §4](concepts/mechanical-elements.md#4-miniload-nomenclature-tk--ml). **Mov (virtual location)** -System virtual location that temporarily holds a container while it is physically travelling between two stations. Set on movement transition `Generated` → `In progress`; cleared on End with `EndErrorCode=0`. See [Galileo Integration — Task lifecycle](architecture/galileo-integration.md#tasks-vs-movements). +System virtual location that temporarily holds a container while it is physically travelling between two stations. Set on movement transition `Generated` → `In progress`; cleared on End with `EndErrorCode=0`. See [Galileo Integration - Task lifecycle](architecture/galileo-integration.md#tasks-vs-movements). **Manual Action (EasyS)** -Test-mode checkbox on a picking station in EasyS. When ticked, the container **does not leave automatically** after picking confirmation — the operator must click **Liberate** to release it. Essential for stepping through flows during simulation. See [Galileo Simulation — §7](operations/galileo-simulation.md#7-extract-a-container-from-the-miniload). +Test-mode checkbox on a picking station in EasyS. When ticked, the container **does not leave automatically** after picking confirmation - the operator must click **Liberate** to release it. Essential for stepping through flows during simulation. See [Galileo Simulation - §7](operations/galileo-simulation.md#7-extract-a-container-from-the-miniload). **MT / MTB (Transelevador de paletas)** Monocolumn (MT) and Bicolumn (MTB) pallet stacker cranes. Heavy-duty variants of the miniload used for Euro-pallets. See [Mechanical Elements](concepts/mechanical-elements.md). @@ -505,13 +505,13 @@ Spanish manufacturer and developer of EasyWMS and EasyS. Headquarters in Barcelo Go-live event for a project. Pivot moment of [Git Branch Lifecycle](operations/git-branch-lifecycle.md): before MEP the CdP merges `develop`→`master` and deletes `develop`; Hypercare follows on a freshly-recreated `develop`. **MSSCODE** -Internal Mecalux Gitea instance hosting all project repositories. Authentication via SSH key (ed25519) — see [SSH Keys Setup](operations/ssh-keys-setup.md). Cloning via SSH (not HTTPS) is mandatory once the SSH key is configured in Sourcetree. +Internal Mecalux Gitea instance hosting all project repositories. Authentication via SSH key (ed25519) - see [SSH Keys Setup](operations/ssh-keys-setup.md). Cloning via SSH (not HTTPS) is mandatory once the SSH key is configured in Sourcetree. **MOR01 (Manufacturing Order)** Inbound ERP message for manufacturing production orders. Triggers stock consumption of components and creation of finished goods. See [Manufacturing](modules/manufacturing.md). **Montage sur demande** -Kit configuration flag (French: "on-demand assembly"). When `YES`, the WMS auto-creates an assembly work order at the integration of an outbound order containing a kit shortage. When `NO`, kit fabrication is only triggered by a manual or ERP-originated WOR — the WMS emits no automatic alert. See [Kits](concepts/kits.md#kit-shortage-handling). +Kit configuration flag (French: "on-demand assembly"). When `YES`, the WMS auto-creates an assembly work order at the integration of an outbound order containing a kit shortage. When `NO`, kit fabrication is only triggered by a manual or ERP-originated WOR - the WMS emits no automatic alert. See [Kits](concepts/kits.md#kit-shortage-handling). **Movirack** Mecalux mobile racking system where rack bays slide laterally to open aisles on demand. Five work modes: Manual, Auto, Timing, Autoparking, Autopicking. See [Movirack](modules/movirack.md). @@ -533,7 +533,7 @@ EasyWMS add-on for carrier integration. Manages deliveries (carrier + consignee) ## N **NEUT / ROUJE pattern (Split reception)** -Mecalux France reception split convention. Incoming stock is split between two complementary buffers at reception to enforce picking-vs-reserve separation : `NEUT` (neutral / picking-ready) and `ROUJE` (customs-held / reserve). Combines with four putaway strategies (direct-to-picking, picking + reserve, reserve only, customs-hold). See [Reception](concepts/reception.md#reception-split-strategy). +Mecalux France reception split convention. Incoming stock is split between two complementary buffers at reception to enforce picking-vs-reserve separation : `NEUT` (neutral / picking-ready) and `ROUJE` (customs-held / reserve). Combines with four putaway strategies (direct-to-picking, picking + reserve, reserve only, customs-hold). See [Reception](concepts/reception.md#reception-split-strategy-mecalux-france-pattern). **Negative picking** Automatic warehouse picking mode where an empty container is sent to a storage channel; the AS/RS picks the desired stock from the channel into the empty container. Used in LIFO channels. See [Picking](concepts/picking.md). @@ -588,13 +588,13 @@ Picking mode where the operator picks directly into the final shipping box, elim **Pick and Pass** Picking mode where multiple operators each pick one zone; the client container passes from operator to operator along a conveyor or route until all lines are complete. See [Picking](concepts/picking.md). -**PIE station (Punto de Introducción de Entrada — Automatic Inbound Point)** +**PIE station (Punto de Introducción de Entrada - Automatic Inbound Point)** The entry point of an automated warehouse. Validates dimensions, weight, and identity of incoming containers. Routes valid containers inward; rejects non-conforming containers to a rejection station. On the GALILEO side, the PIE is seen as a standalone station whose events trigger the `Galileo_PIEEventHandler_PR` workflow on EasyWMS. See [Stations](concepts/stations.md), [GALILEO Integration](architecture/galileo-integration.md) and [Reception](concepts/reception.md). **PK conveyor / PK station (Picking conveyor)** A picking workstation on the conveyor system. Operators work at a PC; containers arrive on the conveyor and are processed (picked, received, consolidated, counted) before continuing on the conveyor. PK station capacity is given per-route (unlike miniload TKs which give capacity per-station). See [Stations](concepts/stations.md) and [GALILEO Integration](architecture/galileo-integration.md). -**PKE station (Punto de Extracción de Salida — Picking Extraction Point)** +**PKE station (Punto de Extracción de Salida - Picking Extraction Point)** Extraction point *from* a picking workstation, used on a "full" PK→PKE route for robotics simulation tests. Pairs with an ME (Manual Entry) target. See [Galileo Simulation](operations/galileo-simulation.md) and [Robotics Project Lifecycle](operations/robotics-project-lifecycle.md). **PLC (Programmable Logic Controller)** @@ -625,14 +625,14 @@ Illuminated display devices mounted at picking locations. Guide operators during See **PTL**. Variant of PTL picking where devices are mounted on both shelves and equipment. See [Configuration Guide](operations/configuration-guide.md). **ProductConversion (OutboundLine)** -Optional attribute of a shipping order line — can be `null` when the order specifies a container code but no item (e.g. a request for a specific support without product). Code review enforces a null-check. See [Code Review Process](operations/code-review-process.md). +Optional attribute of a shipping order line - can be `null` when the order specifies a container code but no item (e.g. a request for a specific support without product). Code review enforces a null-check. See [Code Review Process](operations/code-review-process.md). --- ## Q **Poids balance / Poids calculé / Poids réel / Poids théorique (article) / Poids théorique (balance)** -The five container-level weight fields tracked by the WMS. *"Poids théorique"* is ambiguous in French — always disambiguate between **article** (from item master) and **balance** (from scale minus adjustments). See [Weights](concepts/weights.md). +The five container-level weight fields tracked by the WMS. *"Poids théorique"* is ambiguous in French - always disambiguate between **article** (from item master) and **balance** (from scale minus adjustments). See [Weights](concepts/weights.md). **Quality lock** A stock status applied to specific stock to block one or more operations (picking, replenishment, shipping, counting). Two subtypes: **receiving status** (applied at reception) and **user status** (applied manually or via ERP). See [Quality Control](concepts/quality-control.md). @@ -648,7 +648,7 @@ One of three EasyWMS API families. Executes LINQ-based queries against Views or Manufacturing module recipe types: `RCP01` = standard manufacturing recipe (components → finished good); `RCP02` = quartering recipe (split one item into portions). See [Manufacturing](modules/manufacturing.md). **REAC station (Reactivation)** -Pallet Shuttle charging station variant — reactivates/charges a PS cart. See [Stations](concepts/stations.md). +Pallet Shuttle charging station variant - reactivates/charges a PS cart. See [Stations](concepts/stations.md). **Receipt** A WMS document that records the physical receipt of stock (containers and/or loose stock) within a reception session. Multiple receipts can be created against the same receipt order. Receipt is distinct from receipt order. See [Reception](concepts/reception.md). @@ -684,13 +684,13 @@ Handheld or vehicle-mounted barcode scanning terminal used by warehouse operator Outbound ERP message. Sent when a receipt order changes status (opened, partially received, closed). See [ERP Interface](concepts/erp-interface.md). **Real Weight (Poids réel)** -Container weight field computed as `max(Calculated Weight, Theoretical Scale Weight)`. Acts as the "best known" weight — theoretical when no PIE pass has occurred, scale-derived once it has. Reported on shipping documents. See [Weights](concepts/weights.md). +Container weight field computed as `max(Calculated Weight, Theoretical Scale Weight)`. Acts as the "best known" weight - theoretical when no PIE pass has occurred, scale-derived once it has. Reported on shipping documents. See [Weights](concepts/weights.md). **ROF (Receipt Order Fulfilled)** -Outbound ERP message. Sent when a receipt order is fully fulfilled (all lines received). Two variants: `ROF01` (standard) and `ROF02` (extended line-level detail — used when the inbound order was generated from a `Transfer` shipping order in the two-warehouse flow, and for returns). See [ERP Interface](concepts/erp-interface.md). +Outbound ERP message. Sent when a receipt order is fully fulfilled (all lines received). Two variants: `ROF01` (standard) and `ROF02` (extended line-level detail - used when the inbound order was generated from a `Transfer` shipping order in the two-warehouse flow, and for returns). See [ERP Interface](concepts/erp-interface.md). **Routine (replenishment)** -French SmartUI label for the **Stockout / threshold-based** replenishment strategy — triggers when the picking location drops below its configured minimum. See [Replenishment](concepts/replenishment.md). +French SmartUI label for the **Stockout / threshold-based** replenishment strategy - triggers when the picking location drops below its configured minimum. See [Replenishment](concepts/replenishment.md). **ROR (Receipt Order Request)** Inbound ERP message. Creates a receipt order in EasyWMS. Multiple variants for supplier receipts, ASN pre-notifications, returns, and transfers. See [ERP Interface](concepts/erp-interface.md). @@ -706,13 +706,13 @@ Inbound ERP message. Creates or updates a shipping route in EasyWMS. See [ERP In ## S **SAC (Stock Analysis Classification)** -Outbound ERP message (`SAC01`) sent manually from SmartUI after running the ABC rotation analysis. Carries item code + suggested ABC class. The ERP uses it to update item classification. Not automatic — the WMS operator must explicitly trigger it. See [ERP Interface](concepts/erp-interface.md#module-specific-erp-messages). +Outbound ERP message (`SAC01`) sent manually from SmartUI after running the ABC rotation analysis. Carries item code + suggested ABC class. The ERP uses it to update item classification. Not automatic - the WMS operator must explicitly trigger it. See [ERP Interface](concepts/erp-interface.md#module-specific-erp-messages). **SaaS (Software as a Service)** Cloud-hosted deployment of EasyWMS on Amazon infrastructure. Includes VPN requirements, SaaS-specific API endpoints, and Amazon SaaS certification for mobile apps (Android 10 requirement for Marketplaces). See [System Architecture](architecture/overview.md). **SCADA (Supervisory Control And Data Acquisition)** -Supervision UI layer of the automation installation. In Mecalux robotics, SCADA is distinct from both GALILEO (TMS logic) and EasyWMS (business logic) — it shows the physical machine state to operators and maintenance teams. See [GALILEO Integration](architecture/galileo-integration.md). +Supervision UI layer of the automation installation. In Mecalux robotics, SCADA is distinct from both GALILEO (TMS logic) and EasyWMS (business logic) - it shows the physical machine state to operators and maintenance teams. See [GALILEO Integration](architecture/galileo-integration.md). **SCEM (Supply Chain Event Management)** EasyWMS module for real-time event notification. Users subscribe to notification events and receive alerts via web, email, or SMS. See [Supply Chain Event Management](modules/supply-chain-event.md). @@ -739,7 +739,7 @@ Spanish acronym for WMS. Used interchangeably with WMS in Mecalux Spain-originat EasyWMS's web-based user interface (browser). Used by supervisors and managers for administration, monitoring, and configuration. Distinct from RFT (handheld terminal) screens. See [System Architecture](architecture/overview.md). **Station update / Route update (GALILEO)** -Two status streams GALILEO pushes to EasyWMS roughly every 1–3 seconds. They carry real-time physical state (station busy/free, route status, movement progress) and are written in the Gateway log. Not `Event` messages — they do not trigger workflows, only update state. See [GALILEO Integration](architecture/galileo-integration.md) and [Galileo Troubleshooting](operations/galileo-troubleshooting.md). +Two status streams GALILEO pushes to EasyWMS roughly every 1–3 seconds. They carry real-time physical state (station busy/free, route status, movement progress) and are written in the Gateway log. Not `Event` messages - they do not trigger workflows, only update state. See [GALILEO Integration](architecture/galileo-integration.md) and [Galileo Troubleshooting](operations/galileo-troubleshooting.md). **SOC (Shipping Order Confirmation)** Outbound ERP message. Sent when a shipping order changes status (released, prepared, in progress, completed). See [ERP Interface](concepts/erp-interface.md). @@ -763,7 +763,7 @@ GS1-standard 18-digit numeric identifier for a logistics unit (LPN). The default Transaction prefix for stock-level events. Key types: `STK.RECEP` (received), `STK.MOVE` (moved), `STK.ADJ` (adjusted), `STK.PICK` (picked), `STK.SHIP` (shipped), `STK.REP` (replenished), `STK.MAN.PRODUCTION` (manufacturing). See [Transactions](concepts/transactions.md). **SSCC prefix (change)** -Changing the SSCC prefix sequence is done in **EasyS** (the configurator). Open the warehouse, **double-click the warehouse name** to expose the SSCC/numbering panel, adjust the prefix and/or sequence number, save. Has no effect on already-created containers. See [Container](concepts/container.md#changing-the-sscc-sequence-prefix). +Changing the SSCC prefix sequence is done in **EasyS** (the configurator). Open the warehouse, **double-click the warehouse name** to expose the SSCC/numbering panel, adjust the prefix and/or sequence number, save. Has no effect on already-created containers. See [Container](concepts/container.md#changing-the-sscc-prefix). **Stock assignment** The allocation engine that decides which concrete stock lines fulfil each outbound order line detail, and which task type (picking, shipping, replenishment, virtual picking) will be created. Built around the `StockAssignProcess_*` workflows. See [Stock Assignment](concepts/stock-assignment.md). @@ -794,13 +794,13 @@ A logical partition of a warehouse with independent stock management rules. Item Container weight field computed as *Scale Weight − adjustments*. Initialised after the first PIE pass, then adjusted by subsequent stock moves. Input to Real Weight. See [Weights](concepts/weights.md). **Theoretical Weight (Poids théorique article)** -Container weight field computed as *item-master unit weight × quantity + container tare*. Set at creation and on every adjustment. Note : the container tare is **frozen at creation** — changing the pallet-type weight in EasyS does not propagate. See [Weights](concepts/weights.md). +Container weight field computed as *item-master unit weight × quantity + container tare*. Set at creation and on every adjustment. Note : the container tare is **frozen at creation** - changing the pallet-type weight in EasyS does not propagate. See [Weights](concepts/weights.md). **Transit buffer (intermediate buffer)** -EasyS element of type **Transport** whose sub-location is a **Buffer** (not Automatic) used to bridge two sub-warehouses served by different equipment groups. Pattern: reserve-equipment drops on the buffer, picking-equipment picks up. Critical detail: the sub-location is created as `Automatic` by default and must be manually changed to `Buffer`. See [Location](concepts/location.md#transit-buffer-between-sub-warehouses) and [Replenishment](concepts/replenishment.md#inter-sub-warehouse-replenishment-via-intermediate-buffer). +EasyS element of type **Transport** whose sub-location is a **Buffer** (not Automatic) used to bridge two sub-warehouses served by different equipment groups. Pattern: reserve-equipment drops on the buffer, picking-equipment picks up. Critical detail: the sub-location is created as `Automatic` by default and must be manually changed to `Buffer`. See [Location](concepts/location.md#transit-buffer-between-sub-warehouses) and [Replenishment](concepts/replenishment.md#inter-sub-warehouse-replenishment-via-an-intermediate-buffer). **Transfer (SorType)** -Shipping order type for inter-warehouse transfers with a **reciprocal inbound order** at the destination. Unlike `DirectTransfer` (which only raises an ASN via ASO), `Transfer` creates a full ROR at destination carrying the source SOR reference ; the destination ROF02 (on close) reconciles the source. See [Order Outbound](concepts/order-outbound.md#transfer-two-warehouse-flow) and [ERP Interface](concepts/erp-interface.md). +Shipping order type for inter-warehouse transfers with a **reciprocal inbound order** at the destination. Unlike `DirectTransfer` (which only raises an ASN via ASO), `Transfer` creates a full ROR at destination carrying the source SOR reference ; the destination ROF02 (on close) reconciles the source. See [Order Outbound](concepts/order-outbound.md#transfer---two-warehouse-flow-inbound-order-created) and [ERP Interface](concepts/erp-interface.md). **Task** The atomic unit of work in EasyWMS. A task represents a single movement (container or stock from location A to location B). Tasks belong to a process (putaway, picking, replenishment, count, etc.) and follow a lifecycle: Pending → Generated → In Process → Finished/Canceled. See [Task](concepts/task.md). @@ -814,8 +814,8 @@ French term for a carrier route. Integrated from a TMS via the `RUT` inbound ERP **TK (Transstockeur / Stacker crane)** Spanish/French term for a stacker crane serving a single miniload aisle. In GALILEO stations, a TK is seen as one station per miniload (capacity = number of container slots held on its forks). Opposite: a TKB is a bicolumn (double) miniload. See [Mechanical Elements](concepts/mechanical-elements.md) and [Stations](concepts/stations.md). -**TMS (Transport Management System — two meanings)** -Two distinct usages in EasyWMS docs: (1) **Robotics TMS**: GALILEO (production) or EasyS (simulator), which physically drives conveyors, stacker cranes and shuttles — see [GALILEO Integration](architecture/galileo-integration.md). (2) **Carrier TMS**: external carrier-booking software, integrates via Yard Management and Multi-Carrier. +**TMS (Transport Management System - two meanings)** +Two distinct usages in EasyWMS docs: (1) **Robotics TMS**: GALILEO (production) or EasyS (simulator), which physically drives conveyors, stacker cranes and shuttles - see [GALILEO Integration](architecture/galileo-integration.md). (2) **Carrier TMS**: external carrier-booking software, integrates via Yard Management and Multi-Carrier. **Tracking (GALILEO)** On the GALILEO side, a "tracking" is the live movement object (container + target station + progress). EasyWMS creates a tracking via the `GalileoMovTrackingCreateCommand` when it decides where a container should go; the tracking closes when GALILEO sends back an **End** message. Distinct from a WMS **task**, which may span multiple trackings. See [GALILEO Integration](architecture/galileo-integration.md). @@ -847,7 +847,7 @@ Continuous maintenance team that delivers complementary "offers" via `release` b The measurement unit for an item (piece, kilogram, liter, meter, etc.). EasyWMS supports multiple UoMs per item with conversion factors. The base UoM is used for all internal calculations; presentation UoMs are used at reception and picking. See [Product / Item](concepts/product-item.md). **UserImagesURI** -Setting in the WMS `appsettings.json` that specifies the filesystem folder resolved for item pictures transmitted via `ITM01 filename.jpg`. Typical value: `C:/MLX/Data/Pictures/`. The WMS service account must have read access. See [ERP Interface](concepts/erp-interface.md#itm--image-fields). +Setting in the WMS `appsettings.json` that specifies the filesystem folder resolved for item pictures transmitted via `ITM01 filename.jpg`. Typical value: `C:/MLX/Data/Pictures/`. The WMS service account must have read access. See [ERP Interface](concepts/erp-interface.md#itm---image-fields). **uGNA / uGNAConsole** Mecalux command-line utility (`C:\Program Files (x86)\Mecalux\uGNA\uGNAConsole.exe`) used to export the WMS configuration / master data / parameters to XML files (option `-Z:`). Output is committed to the project Git in `..\test`. Distinct from the GNA service (interfacing layer). See [uGNA Data Export](operations/ugna-data-export.md) and [GNA, Services & License](operations/gna-services-license.md). diff --git a/wiki/modules/3pl-portal.md b/wiki/modules/3pl-portal.md index f2c7918..27aba05 100644 --- a/wiki/modules/3pl-portal.md +++ b/wiki/modules/3pl-portal.md @@ -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 diff --git a/wiki/modules/agv.md b/wiki/modules/agv.md index 2f8acd2..079f735 100644 --- a/wiki/modules/agv.md +++ b/wiki/modules/agv.md @@ -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 diff --git a/wiki/modules/aps3d.md b/wiki/modules/aps3d.md index 375f193..72c9c2d 100644 --- a/wiki/modules/aps3d.md +++ b/wiki/modules/aps3d.md @@ -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` diff --git a/wiki/modules/automation-dashboard.md b/wiki/modules/automation-dashboard.md index 3007ee4..16937b5 100644 --- a/wiki/modules/automation-dashboard.md +++ b/wiki/modules/automation-dashboard.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 diff --git a/wiki/modules/billing-3pl.md b/wiki/modules/billing-3pl.md index 435d60e..f53a6b0 100644 --- a/wiki/modules/billing-3pl.md +++ b/wiki/modules/billing-3pl.md @@ -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 diff --git a/wiki/modules/client-specific-rules.md b/wiki/modules/client-specific-rules.md index cb74baa..167e688 100644 --- a/wiki/modules/client-specific-rules.md +++ b/wiki/modules/client-specific-rules.md @@ -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 diff --git a/wiki/modules/cobot.md b/wiki/modules/cobot.md index 0f1a629..14186b2 100644 --- a/wiki/modules/cobot.md +++ b/wiki/modules/cobot.md @@ -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 diff --git a/wiki/modules/data-analytics.md b/wiki/modules/data-analytics.md index d15cbde..9dde411 100644 --- a/wiki/modules/data-analytics.md +++ b/wiki/modules/data-analytics.md @@ -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 diff --git a/wiki/modules/directives.md b/wiki/modules/directives.md index fdc665f..d8c3aa2 100644 --- a/wiki/modules/directives.md +++ b/wiki/modules/directives.md @@ -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 diff --git a/wiki/modules/dom.md b/wiki/modules/dom.md index 6f712d1..9e82508 100644 --- a/wiki/modules/dom.md +++ b/wiki/modules/dom.md @@ -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 diff --git a/wiki/modules/ecommerce.md b/wiki/modules/ecommerce.md index 9f13f12..14904ac 100644 --- a/wiki/modules/ecommerce.md +++ b/wiki/modules/ecommerce.md @@ -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 diff --git a/wiki/modules/faults-management.md b/wiki/modules/faults-management.md index 297aa9c..3779f00 100644 --- a/wiki/modules/faults-management.md +++ b/wiki/modules/faults-management.md @@ -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 diff --git a/wiki/modules/labor-management.md b/wiki/modules/labor-management.md index 11a9b12..e5138d6 100644 --- a/wiki/modules/labor-management.md +++ b/wiki/modules/labor-management.md @@ -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 diff --git a/wiki/modules/manufacturing.md b/wiki/modules/manufacturing.md index 233f7ca..49ef851 100644 --- a/wiki/modules/manufacturing.md +++ b/wiki/modules/manufacturing.md @@ -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 diff --git a/wiki/modules/marketplaces.md b/wiki/modules/marketplaces.md index 63b904a..fc1a52f 100644 --- a/wiki/modules/marketplaces.md +++ b/wiki/modules/marketplaces.md @@ -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 diff --git a/wiki/modules/movirack.md b/wiki/modules/movirack.md index b63fbc5..6625de5 100644 --- a/wiki/modules/movirack.md +++ b/wiki/modules/movirack.md @@ -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 diff --git a/wiki/modules/multi-carrier.md b/wiki/modules/multi-carrier.md index a42630a..6bdcebe 100644 --- a/wiki/modules/multi-carrier.md +++ b/wiki/modules/multi-carrier.md @@ -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 diff --git a/wiki/modules/owner-extensions.md b/wiki/modules/owner-extensions.md index a5c17ac..a293c2f 100644 --- a/wiki/modules/owner-extensions.md +++ b/wiki/modules/owner-extensions.md @@ -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 diff --git a/wiki/modules/pallet-shuttle.md b/wiki/modules/pallet-shuttle.md index e19f581..53b1743 100644 --- a/wiki/modules/pallet-shuttle.md +++ b/wiki/modules/pallet-shuttle.md @@ -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 diff --git a/wiki/modules/slotting.md b/wiki/modules/slotting.md index 97a9942..0cb0d8d 100644 --- a/wiki/modules/slotting.md +++ b/wiki/modules/slotting.md @@ -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 diff --git a/wiki/modules/store-fulfillment.md b/wiki/modules/store-fulfillment.md index 35fc120..d368e5b 100644 --- a/wiki/modules/store-fulfillment.md +++ b/wiki/modules/store-fulfillment.md @@ -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 diff --git a/wiki/modules/supply-chain-event.md b/wiki/modules/supply-chain-event.md index 91204f2..b342dd7 100644 --- a/wiki/modules/supply-chain-event.md +++ b/wiki/modules/supply-chain-event.md @@ -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 diff --git a/wiki/modules/vas.md b/wiki/modules/vas.md index 8be8d91..899cfa4 100644 --- a/wiki/modules/vas.md +++ b/wiki/modules/vas.md @@ -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 diff --git a/wiki/modules/yard-management.md b/wiki/modules/yard-management.md index 610c323..e6ed870 100644 --- a/wiki/modules/yard-management.md +++ b/wiki/modules/yard-management.md @@ -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 diff --git a/wiki/operations/agv-installation.md b/wiki/operations/agv-installation.md index 1f77b61..14083b1 100644 --- a/wiki/operations/agv-installation.md +++ b/wiki/operations/agv-installation.md @@ -1,5 +1,5 @@ --- -title: "AGV Module — Installation Guide" +title: "AGV Module - Installation Guide" type: operation sources: - sources/archives/Documentation Module AGV.md @@ -10,11 +10,11 @@ related: last_compiled: "2026-05-15" --- -# AGV Module — Installation Guide +# AGV Module - Installation Guide ## Overview -This guide covers the end-to-end installation of the AGV module for Easy WMS. The module relies on a PostgreSQL intermediary database, an ODBC driver, an Oracle DBLink (dg4odbc), the Gateway AGV Windows service, and the AGV application package deployed into Easy WMS. For the functional description of the module, see [AGV — Automated Guided Vehicles](../modules/agv.md). +This guide covers the end-to-end installation of the AGV module for Easy WMS. The module relies on a PostgreSQL intermediary database, an ODBC driver, an Oracle DBLink (dg4odbc), the Gateway AGV Windows service, and the AGV application package deployed into Easy WMS. For the functional description of the module, see [AGV - Automated Guided Vehicles](../modules/agv.md). ## Prerequisites @@ -35,7 +35,7 @@ dir C:\Mecalux\Motor\oracle\Product\ > Throughout this guide, `[ORACLE_HOME]` refers to the full path, e.g. `C:\Mecalux\Motor\oracle\Product\19.27.0.0\dbhome_1`. **Always replace** `[ORACLE_HOME]` **with your actual path** - leaving the placeholder is a frequent cause of failure. -## Step 1 — Install PostgreSQL +## Step 1 - Install PostgreSQL Download PostgreSQL >= 14 from the official EDB site and install with default options. Note the listening port - this is critical: PostgreSQL <= 17 uses port **5432**, while **PostgreSQL 18+ defaults to port 5433**. @@ -63,13 +63,13 @@ netsh advfirewall firewall add rule name="PostgreSQL AGV" dir=in action=allow pr Adjust the port number if using PostgreSQL 18+ (5433). -## Step 2 — Install the PostgreSQL ODBC driver +## Step 2 - Install the PostgreSQL ODBC driver > The download link in the official MSS documentation is dead. Go to the PostgreSQL ODBC releases page and download the latest `psqlodbc_x64.msi` (not the wrapper setup.exe). Install the MSI with default options. -## Step 3 — Configure the System DSN (64-bit ODBC) +## Step 3 - Configure the System DSN (64-bit ODBC) Open **ODBC Data Sources (64-bit)** (`C:\Windows\System32\odbcad32.exe`), go to the **System DSN** tab (not User DSN), click **Add**, and select the **PostgreSQL Unicode(x64)** driver. @@ -84,11 +84,11 @@ Open **ODBC Data Sources (64-bit)** (`C:\Windows\System32\odbcad32.exe`), go to In the **Datasource** tab, **uncheck "Bools as Char"**. Click **Test** to verify the connection. -> **Critical — DSN name case**: the name `PostgreSQL35W` (capital P and W) is used verbatim in **5 different Oracle configuration files**. The case must be **absolutely consistent** across all files. Using `POSTGRESQL35W` (all caps) or `postgresql35w` (all lowercase) will cause a silent dg4odbc failure. See the Troubleshooting section for details. +> **Critical - DSN name case**: the name `PostgreSQL35W` (capital P and W) is used verbatim in **5 different Oracle configuration files**. The case must be **absolutely consistent** across all files. Using `POSTGRESQL35W` (all caps) or `postgresql35w` (all lowercase) will cause a silent dg4odbc failure. See the Troubleshooting section for details. -## Step 4 — Install and start the Gateway AGV +## Step 4 - Install and start the Gateway AGV -### 4.1 — Verify the configuration file +### 4.1 - Verify the configuration file The config file is located at `C:\ProgramData\Mecalux\EasyWMS GatewayAGV 2015\`. The XML file must contain exactly **one** `` section. If it contains two (e.g., for two stations), the provider will not initialize and the service will crash with `Migration DataBase Provider No Initialized`. @@ -121,7 +121,7 @@ Verify that the connection string points to the correct PostgreSQL database: > If using **PostgreSQL 18+** (port 5433), add the port explicitly: `Host=localhost;Port=5433;user id=mecaluxAGV;...` -### 4.2 — First startup (table creation) +### 4.2 - First startup (table creation) Start the Gateway AGV service (`services.msc` > EasyWMS GatewayAGV). Check the log at `C:\ProgramData\Mecalux\EasyWMS GatewayAGV 2015\Logs\AllLog.log` for successful migration lines: @@ -132,15 +132,15 @@ Start the Gateway AGV service (`services.msc` > EasyWMS GatewayAGV). Check the l If these lines appear, the tables were created successfully. Errors after these lines are normal (the Gateway tries to communicate with the fleet manager which is not yet connected). **Stop the service** after verification. -### 4.3 — Verify created tables +### 4.3 - Verify created tables In PgAdmin4, under the AGV database > Schemas > public > Tables, there should be 7 tables: `agv_age`, `agv_ags`, `agv_eag`, `agv_inputqueue`, `agv_maintenance`, `agv_outputqueue`, `std_migrationinfo`. And 6 sequences: `agv_age_id_seq`, `agv_ags_id_seq`, `agv_eag_id_seq`, `agv_inputqueue_id_seq`, `agv_maintenance_id_seq`, `agv_outputqueue_id_seq`. -### 4.4 — Execute PostgreSQL scripts +### 4.4 - Execute PostgreSQL scripts Open the Query Tool in PgAdmin4 on the AGV database and execute: -**Script 1 — Notification function** (publishes an event on every row change): +**Script 1 - Notification function** (publishes an event on every row change): ```sql CREATE FUNCTION public."NotifyOnDataChange"() @@ -165,7 +165,7 @@ END $BODY$; ``` -**Script 2 — Trigger on the inputqueue table**: +**Script 2 - Trigger on the inputqueue table**: ```sql CREATE TRIGGER "OnDataChange" @@ -174,19 +174,19 @@ FOR EACH ROW EXECUTE PROCEDURE public."NotifyOnDataChange"(); ``` -## Step 5 — Configure the external PostgreSQL user +## Step 5 - Configure the external PostgreSQL user This user will be used by the Oracle DBLink to access the AGV tables from the WMS. -### 5.1 — Create the user +### 5.1 - Create the user In PgAdmin4: create a login role `externalAGV` with a password and login privilege. -### 5.2 — Grant CONNECT on the database +### 5.2 - Grant CONNECT on the database In the AGV database properties > Security tab, add `externalAGV` with the **CONNECT** privilege. -### 5.3 — Grant permissions on tables and sequences +### 5.3 - Grant permissions on tables and sequences **Quick option (dev environment)**: @@ -211,11 +211,11 @@ GRANT ALL ON agv_ags_id_seq TO "externalAGV"; GRANT ALL ON agv_inputqueue_id_seq TO "externalAGV"; ``` -## Step 6 — Configure the Oracle DBLink to PostgreSQL +## Step 6 - Configure the Oracle DBLink to PostgreSQL This is the most delicate step. Oracle uses the **dg4odbc** component (Database Gateway for ODBC) to connect to PostgreSQL via the ODBC DSN created in Step 3. The configuration touches 3 Oracle files and requires a Listener restart. -### 6.1 — Edit tnsnames.ora +### 6.1 - Edit tnsnames.ora File: `[ORACLE_HOME]\network\admin\tnsnames.ora` @@ -234,7 +234,7 @@ Leave a blank line between the previous entry and this one. `(HS=OK)` is mandato > **Common error**: if the identifier is indented (space or tab before `PostgreSQL35W =`), Oracle returns `ORA-12154: TNS:could not resolve the connect identifier specified`. This is a subtle trap because the rest of the file works fine with indentation. -### 6.2 — Edit listener.ora +### 6.2 - Edit listener.ora File: `[ORACLE_HOME]\network\admin\listener.ora` @@ -250,7 +250,7 @@ Add a `SID_DESC` block in the existing `SID_LIST_LISTENER` section: > **Critical**: the `ORACLE_HOME` path in this block must be the **real, complete path** of your Oracle installation. Never leave a placeholder like `[VERSION]` - this causes `TNS-12518` / `ORA-28545` errors. The listener starts without error and the SID appears in `lsnrctl status`, making the problem hard to diagnose. **Verify** that the `ORACLE_HOME` in the PostgreSQL35W block is **identical** to the other `SID_DESC` blocks in the file. -### 6.3 — Create initPostgreSQL35W.ora +### 6.3 - Create initPostgreSQL35W.ora Go to `[ORACLE_HOME]\hs\admin\`, duplicate the file `initdg4odbc.ora`, rename the copy to `initPostgreSQL35W.ora` (name must match the SID_NAME exactly, case-sensitive), and replace all content with: @@ -261,7 +261,7 @@ HS_FDS_TRACE_LEVEL = 0 Do not leave the template lines from the original file. For debugging, temporarily set `HS_FDS_TRACE_LEVEL = 4` for detailed dg4odbc traces. Reset to 0 after diagnosis. -### 6.4 — Restart the Oracle Listener +### 6.4 - Restart the Oracle Listener ``` lsnrctl stop @@ -276,7 +276,7 @@ lsnrctl status Expected output: `Service "PostgreSQL35W" has 1 instance(s). Instance "PostgreSQL35W", status UNKNOWN, has 1 handler(s) for this service...` The UNKNOWN status is normal for a Heterogeneous Service - the process is launched on demand. -### 6.5 — Grant CREATE DATABASE LINK to db_read +### 6.5 - Grant CREATE DATABASE LINK to db_read Connect as **sysdba** and grant: @@ -286,7 +286,7 @@ GRANT CREATE DATABASE LINK TO db_read; > The target user is **db_read** (the Easy WMS read model schema). The database link and synonyms must be owned by db_read. Do not create the link under SYS - it will not be visible from db_read. -### 6.6 — Create the Database Link +### 6.6 - Create the Database Link Connect as **db_read** (not sysdba): @@ -298,7 +298,7 @@ CREATE DATABASE LINK AGV > **Double quotes** around the user and password are **mandatory**. Oracle converts identifiers to uppercase by default, but PostgreSQL is case-sensitive. Without quotes, Oracle sends `EXTERNALAGV` instead of `externalAGV` and authentication fails. -### 6.7 — Test the DBLink +### 6.7 - Test the DBLink ```sql SELECT * FROM "agv_inputqueue"@AGV; @@ -306,7 +306,7 @@ SELECT * FROM "agv_inputqueue"@AGV; If the query returns `no rows selected`, the link works. The tables are simply empty at this stage. -### 6.8 — Create Oracle synonyms +### 6.8 - Create Oracle synonyms Still connected as **db_read**: @@ -322,9 +322,9 @@ CREATE SYNONYM agv_outputqueue FOR "agv_outputqueue"@AGV; Verify all synonyms: `SELECT * FROM agv_inputqueue;` (repeat for each). All queries must pass without error (`no rows selected` is expected). -## Step 7 — Install the AGV module in Easy WMS +## Step 7 - Install the AGV module in Easy WMS -### 7.1 — Modify response.xml +### 7.1 - Modify response.xml Add the AGV entries in the deployment `response.xml`: @@ -340,11 +340,11 @@ Add the AGV entries in the deployment `response.xml`: ``` -### 7.2 — Run the deploy +### 7.2 - Run the deploy -Execute the deploy using **option 16 — Install application**. +Execute the deploy using **option 16 - Install application**. -### 7.3 — Restart the Gateway AGV +### 7.3 - Restart the Gateway AGV After the deploy completes, restart the Gateway AGV service in `services.msc`. @@ -413,5 +413,5 @@ If this test passes but the Oracle DBLink fails, the problem is in the dg4odbc c ## Related -- [AGV — Automated Guided Vehicles](../modules/agv.md) — Functional documentation: architecture, protocol, monitoring, errors -- [Stations](../concepts/stations.md) — Station types including AGV (type 65), equipment groups, routes +- [AGV - Automated Guided Vehicles](../modules/agv.md) - Functional documentation: architecture, protocol, monitoring, errors +- [Stations](../concepts/stations.md) - Station types including AGV (type 65), equipment groups, routes diff --git a/wiki/operations/code-review-process.md b/wiki/operations/code-review-process.md index bebcc57..f9a8631 100644 --- a/wiki/operations/code-review-process.md +++ b/wiki/operations/code-review-process.md @@ -19,11 +19,11 @@ last_compiled: "2026-04-17" Procédure interne Mecalux EasyWMS France pour la **revue d'une tâche de développement custom** avant intégration sur `develop`. La revue se fait sur **trois axes** complémentaires, généralement par des reviewers distincts (parfois cumulés) : -1. **Revue Code** — qualité technique, conventions de nommage, identification du custom (`CST_`), gestion des `null`, erreurs classiques sur le modèle Outbound/Kit -2. **Revue Fonctionnel** — exécution des cas de test Jira, comportement des touches `Enter` / `Échap` sur les dialogues -3. **Revue Documentation** — Jira commentée, présence des éléments dans la branche Git, mise à jour du **reten** (manuel de retention en Markdown — cf. [development-methodology](development-methodology.md)) +1. **Revue Code** - qualité technique, conventions de nommage, identification du custom (`CST_`), gestion des `null`, erreurs classiques sur le modèle Outbound/Kit +2. **Revue Fonctionnel** - exécution des cas de test Jira, comportement des touches `Enter` / `Échap` sur les dialogues +3. **Revue Documentation** - Jira commentée, présence des éléments dans la branche Git, mise à jour du **reten** (manuel de retention en Markdown - cf. [development-methodology](development-methodology.md)) -Sources : Confluence EasyWMS France — *Revue - Code* (v10, 08/01/2026), *Revue - Fonctionnel* (v2, 27/02/2024), *Revue - Documentation* (v3, 04/03/2024). +Sources : Confluence EasyWMS France - *Revue - Code* (v10, 08/01/2026), *Revue - Fonctionnel* (v2, 27/02/2024), *Revue - Documentation* (v3, 04/03/2024). > Référentiel global Mecalux Espagne : [code review checklist](https://msscc.mecalux.com/documentation/Development/master/ES/map_development_concepts/code_review/index.md), [nomenclature](https://msscc.mecalux.com/documentation/Development/master/ES/map_development_concepts/nomenclature/index.md), [null management best practices](https://msscc.mecalux.com/documentation/Development/master/ES/map_application_development/null_management_best_practices/index.md). @@ -56,7 +56,7 @@ Si le projet utilise les **kits sans assemblage** (cf. [kits](../concepts/kits.m > ⚠️ Sur les requêtes en **writing**, l'attribut `ProductConversion` d'une ligne d'ordre de sortie peut être `null`. -Cas : la commande demande un **support spécifique** sans article — on a alors le **code support renseigné mais pas l'article**, donc pas de conversion produit. +Cas : la commande demande un **support spécifique** sans article - on a alors le **code support renseigné mais pas l'article**, donc pas de conversion produit. ### 1.4 Identification du custom dans le code @@ -113,7 +113,7 @@ Chaque nouvel élément ou élément modifié doit être **préfixé `CST_`**. T Particulièrement : **`FirstOrDefault()`** doit être sécurisé. ```csharp -// ❌ Dangereux — exception si aucun ordre n'existe +// ❌ Dangereux - exception si aucun ordre n'existe Context.OutboundOrders.FirstOrDefault(s => s.Code == outboundOrderCode).OutboundLines // ✅ Sécurisé @@ -156,7 +156,7 @@ Vérifier la **présence des éléments modifiés** dans la branche Git concern > Vérification utile : l'**historique des commits** Git du développeur pour s'assurer qu'il n'a **pas inclus de modifications hors périmètre** de sa tâche. Ce cas survient quand le dev a été réalisé **avec une custom app qui n'était pas au même "niveau"** que la branche sur laquelle il l'exporte (typiquement : création de la branche **après** import de la custom app dans le Builder, alors que d'autres commits ont eu lieu entre temps). > -> Cf. [custom-application-management](custom-application-management.md) — règles d'import/export pour éviter ce cas. +> Cf. [custom-application-management](custom-application-management.md) - règles d'import/export pour éviter ce cas. ### 3.3 Reten @@ -166,9 +166,9 @@ Vérifier que la description de la tâche est **présente dans le reten** avec * |---|---| | Le custom **modifie le comportement d'un process** | Décrit dans les **chapitres de process** (Entries, Exits, Picking, etc.) avec **description fonctionnelle, technique et éléments custom** | | Le custom **ne modifie pas le comportement d'un process** | Présent dans les **tableaux d'éléments custom en fin de reten**, avec description de la modification | -| Des **custom attributes** ont été utilisés | Listés dans la partie **"1.2 General custom elements"** du reten — et **idéalement aussi dans la tâche Jira liée** au custom quand il s'agit d'un process custom | +| Des **custom attributes** ont été utilisés | Listés dans la partie **"1.2 General custom elements"** du reten - et **idéalement aussi dans la tâche Jira liée** au custom quand il s'agit d'un process custom | -> Le reten est un manuel de retention en **Markdown**, géré dans le repo Git du projet (cf. [development-methodology](development-methodology.md#manuel-de-reten)). +> Le reten est un manuel de retention en **Markdown**, géré dans le repo Git du projet (cf. [development-methodology](development-methodology.md#1-phase-de-développement)). --- @@ -183,8 +183,8 @@ Vérifier que la description de la tâche est **présente dans le reten** avec * ## Related -- [Git Workflow (Git Flow)](git-workflow.md) — workflow Git Flow où s'insèrent les revues (avant `Finish Feature`) -- [Git Branch Lifecycle](git-branch-lifecycle.md) — la revue est faite avant l'intégration dans `develop` (phase 1) -- [Custom Application Management](custom-application-management.md) — règles d'import/export pour éviter les modifs hors périmètre -- [Development Methodology](development-methodology.md) — vue d'ensemble (reten, branches, custom apps) -- [Kits](../concepts/kits.md) — utile pour comprendre les pièges sur `OutboundOrderOutboundOrderLineDetails` (kits sans assemblage) +- [Git Workflow (Git Flow)](git-workflow.md) - workflow Git Flow où s'insèrent les revues (avant `Finish Feature`) +- [Git Branch Lifecycle](git-branch-lifecycle.md) - la revue est faite avant l'intégration dans `develop` (phase 1) +- [Custom Application Management](custom-application-management.md) - règles d'import/export pour éviter les modifs hors périmètre +- [Development Methodology](development-methodology.md) - vue d'ensemble (reten, branches, custom apps) +- [Kits](../concepts/kits.md) - utile pour comprendre les pièges sur `OutboundOrderOutboundOrderLineDetails` (kits sans assemblage) diff --git a/wiki/operations/configuration-guide.md b/wiki/operations/configuration-guide.md index d8bbbca..d746a83 100644 --- a/wiki/operations/configuration-guide.md +++ b/wiki/operations/configuration-guide.md @@ -43,7 +43,7 @@ Before configuring Easy WMS, verify the infrastructure: | Item | Requirement | |------|-------------| | **IIS version** | IIS 10+ on Windows Server 2019 or later | -| **Application pools** | Main pool + Background Jobs pool + Integration pool — all configured as .NET CLR v4 | +| **Application pools** | Main pool + Background Jobs pool + Integration pool - all configured as .NET CLR v4 | | **Database** | Oracle 19c+ or PostgreSQL 13+ | | **Environment variable** | `ASPNETCORE_ENVIRONMENT = Production` (not Development) | | **WIFI** | 802.11n/ac coverage in all RF terminal work areas; separate VLAN for WMS traffic | @@ -60,8 +60,8 @@ All physical warehouse configuration is done in **EasyS** (the visual layout con 1. Create the **warehouse** entity with type (manual / automatic / mixed). 2. Define **sub-warehouses** if needed (physical separation or different logistics rules). -3. Create **storage zones** — group aisles by temperature, hazard class, or ABC zone. -4. Create **working zones** — assign equipment types with permission per process (reception, putaway, picking, replenishment, count). +3. Create **storage zones** - group aisles by temperature, hazard class, or ABC zone. +4. Create **working zones** - assign equipment types with permission per process (reception, putaway, picking, replenishment, count). ### 1.2 Location Types @@ -91,11 +91,11 @@ For each process, at least one station of the appropriate type is required: |--------------|------|--------------| | Dock | 34 | Inbound/outbound vehicle docking | | Stage | 33 | Pre/post-dock staging | -| PIE | — | Automatic inbound sorter | +| PIE | - | Automatic inbound sorter | | PK conveyor | 2 | Picking/reception workstation | -| ALM | — | Storage station | -| ME/MU/MS | — | Multi-exit/multi-unit/multi-stock conveyors | -| ET (Transit) | — | Intermediate replenishment station | +| ALM | - | Storage station | +| ME/MU/MS | - | Multi-exit/multi-unit/multi-stock conveyors | +| ET (Transit) | - | Intermediate replenishment station | | Consolidation | 17 | Order consolidation | | Decision | 63 | Routing decision point | | Workzone | 64 | Manual picking zone | @@ -126,10 +126,10 @@ Defined in EasyS. Key attributes: 1. Create items in WMS UI or via **ITM ERP message**. 2. Assign mandatory profiles: - - **Reception profile** — required before any receipt can be created. - - **Shipping profile** — required before any shipping order line can be assigned. - - **Putaway profile** — optional; if absent, default warehouse strategy is used. - - **Count profile** — required for ABC-driven cycle counts. + - **Reception profile** - required before any receipt can be created. + - **Shipping profile** - required before any shipping order line can be assigned. + - **Putaway profile** - optional; if absent, default warehouse strategy is used. + - **Count profile** - required for ABC-driven cycle counts. 3. Configure logistic attributes (lot, expiry, serial number, quality, etc.) per item or item type. 4. Set UoM and conversions; define base UoM clearly. 5. For cutting stock items: assign cutting profile with min/max quantities, cutting tolerance, and label configuration. @@ -148,16 +148,16 @@ Defined in EasyS. Key attributes: | Parameter | Default | Effect | |-----------|---------|--------| -| `ALLOW_CREATE_RECEPTION` | — | Allow WMS to create a receipt without a pre-existing order | -| `AutoCloseReception` | — | Auto-close receipt when all lines are fulfilled | -| `USE_EXCLUSIVE_RESERVE_STRICT_MODE` | — | Block ASN reception if referenced receipt order is missing | -| `RECEPTION_NUM_DAYS_PRODUCTION_DATE_MARGIN` | — | Minimum remaining shelf life required at reception | -| `LPN_CHECK_CODE_GS1LABEL` | — | Validate LPN code against GS1 SSCC format | -| `CONTAINER_CHECK_CODE_REPEATED_FOR_LABELS` | — | Prevent LPN code reuse (vs station codes, locations, aliases) | +| `ALLOW_CREATE_RECEPTION` | - | Allow WMS to create a receipt without a pre-existing order | +| `AutoCloseReception` | - | Auto-close receipt when all lines are fulfilled | +| `USE_EXCLUSIVE_RESERVE_STRICT_MODE` | - | Block ASN reception if referenced receipt order is missing | +| `RECEPTION_NUM_DAYS_PRODUCTION_DATE_MARGIN` | - | Minimum remaining shelf life required at reception | +| `LPN_CHECK_CODE_GS1LABEL` | - | Validate LPN code against GS1 SSCC format | +| `CONTAINER_CHECK_CODE_REPEATED_FOR_LABELS` | - | Prevent LPN code reuse (vs station codes, locations, aliases) | ### 3.2 PIE Station (Automatic Inbound) -Configure rejection handling — all PIE error types must have an explicit rejection route: +Configure rejection handling - all PIE error types must have an explicit rejection route: | Error Type | Destination | |------------|-------------| @@ -190,11 +190,11 @@ If receiving without RFT (containers enter PIE directly): Putaway strategies execute in order. The recommended sequence for most deployments: -1. **Assigned location** (PDL / item-assigned location) — highest priority. -2. **Channel filling** (compact, APS) — fill partially-occupied channels first. -3. **Storage zone by ABC** — A-class items near pick face; C-class items at depth. -4. **Crossdocking zone** (if applicable) — for items with `Enable crossdocking` active. -5. **Default zone** — catch-all for any remaining containers. +1. **Assigned location** (PDL / item-assigned location) - highest priority. +2. **Channel filling** (compact, APS) - fill partially-occupied channels first. +3. **Storage zone by ABC** - A-class items near pick face; C-class items at depth. +4. **Crossdocking zone** (if applicable) - for items with `Enable crossdocking` active. +5. **Default zone** - catch-all for any remaining containers. Key strategy attributes: @@ -208,19 +208,19 @@ Key strategy attributes: ### 4.2 Restrictions Configure restrictions to prevent mixing incompatible items in the same location/aisle/zone: -- "Do not locate in same zone" — e.g., hazardous + non-hazardous. -- "Do not locate in same aisle" — e.g., temperature classes. -- "Do not fit on higher heights" — for fragile items. -- "Do not putaway adjacent" — for certain chemical incompatibilities. +- "Do not locate in same zone" - e.g., hazardous + non-hazardous. +- "Do not locate in same aisle" - e.g., temperature classes. +- "Do not fit on higher heights" - for fragile items. +- "Do not putaway adjacent" - for certain chemical incompatibilities. ### 4.3 PDL Creation (Picking Dedicated Locations) PDLs are configured per item per location. Required settings: -- **Maximum stock level** — triggers top-off replenishment. -- **Minimum stock level** — triggers stockout replenishment. -- **Replenishment mode** — Container or Stock. -- **Enable automatic replenishment** — must be explicitly checked. -- **Delete when empty** — enable for seasonal items only. +- **Maximum stock level** - triggers top-off replenishment. +- **Minimum stock level** - triggers stockout replenishment. +- **Replenishment mode** - Container or Stock. +- **Enable automatic replenishment** - must be explicitly checked. +- **Delete when empty** - enable for seasonal items only. For locations with drawers/boxes (small parts): use partition labels with pre-generated coordinates. Enable `RF_PICKING_CONFIRM_LOCATION` to require location scan at picking. @@ -241,11 +241,11 @@ When PDLs and stock source are in physically separate zones that cannot be direc | Parameter | Default | Effect | |-----------|---------|--------| -| `RF_PICKING_CONFIRM_LOCATION` | — | Require location scan before picking | -| `MAX_CONTAINER_WEIGHT` | — | Client container weight limit | -| `PICK_AND_PASS_ENABLED` | — | Enable Pick & Pass mode | -| `VOICE_ENABLED` | — | Enable voice-guided picking | -| `CUTTING_PRINTER` | — | Printer for cutting stock labels | +| `RF_PICKING_CONFIRM_LOCATION` | - | Require location scan before picking | +| `MAX_CONTAINER_WEIGHT` | - | Client container weight limit | +| `PICK_AND_PASS_ENABLED` | - | Enable Pick & Pass mode | +| `VOICE_ENABLED` | - | Enable voice-guided picking | +| `CUTTING_PRINTER` | - | Printer for cutting stock labels | ### 5.2 PTL Configuration (Pick To Light / Put To Light) @@ -286,7 +286,7 @@ When PDLs and stock source are in physically separate zones that cannot be direc The `TryToReplenishProductLocations` background job runs automatically. Configure: - Job schedule (recommended: every 5–15 minutes). -- `MAX_NUM_LOTS_REPLENISHMENT` — maximum lot lines per replenishment container (prevents mixing). +- `MAX_NUM_LOTS_REPLENISHMENT` - maximum lot lines per replenishment container (prevents mixing). ### 6.3 Replenishment from Picking Locations @@ -294,7 +294,7 @@ Used for locations with boxes/drawers (small parts): 1. Assign minimum and maximum stock levels per PDL. 2. Enable `Stockout` strategy. 3. Place stock in a nearby storage location for FEFO/FIFO compliance. -4. If FIFO/FEFO required: configure the PDL's source location to "take from height" — the system maintains the FEFO sequence during replenishment. +4. If FIFO/FEFO required: configure the PDL's source location to "take from height" - the system maintains the FEFO sequence during replenishment. --- @@ -321,7 +321,7 @@ Configure per lock type (in `Masters > Lock Types`): 1. Create a **count schedule**: item ABC class, warehouse zones, and frequency (how many items per iteration). 2. Create **count iterations** from the schedule: each iteration covers a subset of the total item population. 3. Generate **count order** from iteration: produces location or item count tasks. -4. Cycle count orders are **non-re-releasable** once canceled — create new orders if needed. +4. Cycle count orders are **non-re-releasable** once canceled - create new orders if needed. ### 7.4 Double Validation @@ -337,13 +337,13 @@ Enable per item (count profile) when count discrepancies require manager approva Three mandatory configuration elements: -### Step 1 — Enable crossdocking on items +### Step 1 - Enable crossdocking on items `Inventory > Items > item > "Enable crossdocking"` attribute = True. -### Step 2 — Configure crossdocking locations +### Step 2 - Configure crossdocking locations In EasyS: activate **"Is crossdocking location"** on target locations. -### Step 3 — Create crossdocking putaway strategies +### Step 3 - Create crossdocking putaway strategies - Create strategies with **"Crossdocking"** attribute enabled. - For placing loose stock (partial container): also enable **"Loose stock"** attribute. - For placing whole containers: use a strategy with "Crossdocking" only (no "Loose stock"). @@ -400,7 +400,7 @@ Key message pairs to configure at go-live: ### 10.2 Integration Application Pool - Separate IIS pool from main application. -- Monitor for stops — ERP messages queue if integration pool is down. +- Monitor for stops - ERP messages queue if integration pool is down. - Log location: check both IIS logs and WMS application logs. ### 10.3 API Keys @@ -433,10 +433,10 @@ Key events to subscribe for go-live monitoring: | Event | Severity | When to Subscribe | |-------|----------|--------------------| -| `Notification_GNAImportError` | Error | Always — ERP message parsing failures | +| `Notification_GNAImportError` | Error | Always - ERP message parsing failures | | AGV error codes (1001–2503) | Error | If AGV module active | | PS fault/tilt | Error | If Pallet Shuttle module active | -| Stock failure on outbound order | Warning | Always — operational visibility | +| Stock failure on outbound order | Warning | Always - operational visibility | ### 11.3 Yard Management @@ -509,7 +509,7 @@ Create roles from most to least permissive; assign permissions explicitly per ro Assign station roles to users/roles: - Role determines which station types the user can log into from the RFT. -- Station role is checked at RFT login — rejected if not assigned. +- Station role is checked at RFT login - rejected if not assigned. ### 12.3 Owner Isolation (3PL) @@ -525,42 +525,42 @@ Assign station roles to users/roles: Key parameters to review at each deployment. Full documentation in [Parameters](../concepts/parameters.md). ### Reception -- `ALLOW_CREATE_RECEPTION` — allow blind receipts -- `AutoCloseReception` — auto-close on completion -- `LPN_CHECK_CODE_GS1LABEL` — enforce GS1 SSCC format -- `RECEPTION_NUM_DAYS_PRODUCTION_DATE_MARGIN` — shelf life check at receipt +- `ALLOW_CREATE_RECEPTION` - allow blind receipts +- `AutoCloseReception` - auto-close on completion +- `LPN_CHECK_CODE_GS1LABEL` - enforce GS1 SSCC format +- `RECEPTION_NUM_DAYS_PRODUCTION_DATE_MARGIN` - shelf life check at receipt ### Picking -- `RF_PICKING_CONFIRM_LOCATION` — enforce location scan -- `PICK_AND_PASS_ENABLED` — enable Pick & Pass mode -- `VOICE_ENABLED` — enable voice picking +- `RF_PICKING_CONFIRM_LOCATION` - enforce location scan +- `PICK_AND_PASS_ENABLED` - enable Pick & Pass mode +- `VOICE_ENABLED` - enable voice picking ### Replenishment -- `MAX_NUM_LOTS_REPLENISHMENT` — lot mixing limit per container +- `MAX_NUM_LOTS_REPLENISHMENT` - lot mixing limit per container - TryToReplenishProductLocations job schedule ### Defragmentation -- `MAX_DEFRAG_TASKS` — max concurrent defragmentation tasks -- `MAX_OPTIMIZATION_DEFRAG_CHANNEL` — max channels optimized per run -- `MAX_DEFRAG_ATTEMPT` — retries before skipping a container +- `MAX_DEFRAG_TASKS` - max concurrent defragmentation tasks +- `MAX_OPTIMIZATION_DEFRAG_CHANNEL` - max channels optimized per run +- `MAX_DEFRAG_ATTEMPT` - retries before skipping a container ### AGV / Pallet Shuttle - `PS_MAX_MINUTES_BATTERY_FULL_LOAD` = 300 (max battery life under load) - `PS_MIN_MINUTES_BATTERY_LOAD` = 90 (minimum before return to charge) ### Multi-Carrier -- `MC_TRACKING_ARCHIVES_PATH` — carrier tracking files directory -- `MC_DEFAULT_CARRIER` — fallback carrier if auto-selection fails +- `MC_TRACKING_ARCHIVES_PATH` - carrier tracking files directory +- `MC_DEFAULT_CARRIER` - fallback carrier if auto-selection fails --- ## Related -- [Parameters](../concepts/parameters.md) — Complete parameter reference with all values -- [Troubleshooting](troubleshooting.md) — Error resolution guide -- [Stations & Routes](../concepts/stations.md) — Full station type reference -- [Warehouse Designer](../concepts/warehouse-designer.md) — EasyS-based layout configuration -- [Putaway](../concepts/putaway.md) — Strategy pipeline and configuration details -- [Replenishment](../concepts/replenishment.md) — PDL and strategy configuration details -- [System Architecture](../architecture/overview.md) — IIS, pools, and background jobs -- [Security](../architecture/security.md) — Roles, authentication, and permissions +- [Parameters](../concepts/parameters.md) - Complete parameter reference with all values +- [Troubleshooting](troubleshooting.md) - Error resolution guide +- [Stations & Routes](../concepts/stations.md) - Full station type reference +- [Warehouse Designer](../concepts/warehouse-designer.md) - EasyS-based layout configuration +- [Putaway](../concepts/putaway.md) - Strategy pipeline and configuration details +- [Replenishment](../concepts/replenishment.md) - PDL and strategy configuration details +- [System Architecture](../architecture/overview.md) - IIS, pools, and background jobs +- [Security](../architecture/security.md) - Roles, authentication, and permissions diff --git a/wiki/operations/custom-application-management.md b/wiki/operations/custom-application-management.md index 1da3ebf..406c46d 100644 --- a/wiki/operations/custom-application-management.md +++ b/wiki/operations/custom-application-management.md @@ -29,13 +29,13 @@ Règles de base : > ⛔ Une mauvaise manipulation ici peut entraîner la **perte de vos développements**. Procéder avec soin. -Source : Confluence EasyWMS France — *Gestion de la custom application* (v12, 20/12/2022). +Source : Confluence EasyWMS France - *Gestion de la custom application* (v12, 20/12/2022). ## 1. Création de l'application custom À n'exécuter qu'**une seule fois par projet** (le premier développeur). Les autres devs font un **Import** (cf. section 2). -### Option A — Partir d'une app existante du Toolkit +### Option A - Partir d'une app existante du Toolkit Si le projet réutilise des modifications déjà packagées dans le dépôt [**FRANCE_OPERATIONS_TOOLS**](https://msscode.mecalux.com/Proyectos_SW/FRANCE_OPERATIONS_TOOLS.git) (ex. modifications habituelles du module transporteur) : @@ -46,7 +46,7 @@ Si le projet réutilise des modifications déjà packagées dans le dépôt [**F ``` Exemple : `..\FRANCE_OPERATIONS_TOOLS\Module transporteur` -### Option B — Créer une application vierge +### Option B - Créer une application vierge Dans **EasyBuilder** : @@ -78,7 +78,7 @@ Après création, faire un **1ᵉʳ export sur la branche `develop`** du dépôt | Vous rejoignez un projet en cours | **Oui** (première action) | | Vous venez de merger votre branche dans `develop` | **Oui** (réimporter le `develop` à jour) | | Un collègue a poussé une modif majeure sur `develop` | **Oui** après `git pull` | -| Vous démarrez la journée sur votre branche perso | **Non** — travailler sur votre export local | +| Vous démarrez la journée sur votre branche perso | **Non** - travailler sur votre export local | ## 3. Export de l'application custom @@ -104,7 +104,7 @@ Après création, faire un **1ᵉʳ export sur la branche `develop`** du dépôt ### Suites logiques -- **Commit + push** sur la branche de votre tâche — cf. [git-workflow](git-workflow.md#3--commit-de-vos-modifications) +- **Commit + push** sur la branche de votre tâche - cf. [git-workflow](git-workflow.md#3-commit-de-vos-modifications) - Les fichiers exportés peuvent être **séparés en plusieurs** pour un même élément AD (workflow, source C#, DESIGN…). Bien prendre **tous** les fichiers portant le nom de l'élément modifié. ## Règles de coexistence multi-développeurs @@ -113,7 +113,7 @@ Après création, faire un **1ᵉʳ export sur la branche `develop`** du dépôt |-----------|--------| | Plusieurs devs sur le projet | Chacun sur sa **branche GIT personnelle** (cf. [development-methodology](development-methodology.md)) | | Éviter les écrasements | **Export systématique** en fin de tâche + **import** après merge dans `develop` | -| Éléments en Check-out | À **Check-in avant export** — sinon perte silencieuse | +| Éléments en Check-out | À **Check-in avant export** - sinon perte silencieuse | | Structure commune (toolkit) | Utiliser **FRANCE_OPERATIONS_TOOLS** en option A de création | ## Common errors @@ -127,8 +127,8 @@ Après création, faire un **1ᵉʳ export sur la branche `develop`** du dépôt ## Related -- [Application Dictionary](../architecture/application-dictionary.md) — contenu packagé dans la custom app (Commands, Queries, Entities, Views, Dialogs, Events, Workflows) -- [Development Methodology](development-methodology.md) — stratégie de branches et cadre dans lequel s'inscrit la gestion de la custom app -- [First Deployment](first-deployment.md) — création initiale de la custom app (étape 9) et référencement dans `DeployConfig.yaml` (étape 10) -- [Deploy Existing Application](deployment-existing-app.md) — import custom app lors d'un redéploiement (étape 6 si anciens scripts) -- [Git Workflow](git-workflow.md) — rythme commit/push et gestion des branches +- [Application Dictionary](../architecture/application-dictionary.md) - contenu packagé dans la custom app (Commands, Queries, Entities, Views, Dialogs, Events, Workflows) +- [Development Methodology](development-methodology.md) - stratégie de branches et cadre dans lequel s'inscrit la gestion de la custom app +- [First Deployment](first-deployment.md) - création initiale de la custom app (étape 9) et référencement dans `DeployConfig.yaml` (étape 10) +- [Deploy Existing Application](deployment-existing-app.md) - import custom app lors d'un redéploiement (étape 6 si anciens scripts) +- [Git Workflow](git-workflow.md) - rythme commit/push et gestion des branches diff --git a/wiki/operations/deploy-test-application.md b/wiki/operations/deploy-test-application.md index a473c65..075b031 100644 --- a/wiki/operations/deploy-test-application.md +++ b/wiki/operations/deploy-test-application.md @@ -27,7 +27,7 @@ Procédure interne Mecalux EasyWMS France pour **livrer un lot de développement Le pivot de la procédure est la **création d'un tag Git** sur le commit `develop` choisi : cela garantit que la version déployée et testée par le CdP est **figée**, indépendamment de tout commit ultérieur sur `develop` (potentiellement en cours de dev / non testé). -Source : Confluence EasyWMS France — *Déployer l'application en test* (v1, 20/12/2022). +Source : Confluence EasyWMS France - *Déployer l'application en test* (v1, 20/12/2022). ## Convention de nommage des tags @@ -64,7 +64,7 @@ git checkout Appliquer le point de contrôle Hyper-V **"Deploy 0"** sur la VM de test **avant** le déploiement. -> Le checkpoint "Deploy 0" est créé à la fin de la procédure d'installation initiale de la VM (cf. [vm-installation](vm-installation.md)) — c'est l'état "VM prête à recevoir un déploiement, vide de tout projet". +> Le checkpoint "Deploy 0" est créé à la fin de la procédure d'installation initiale de la VM (cf. [vm-installation](vm-installation.md)) - c'est l'état "VM prête à recevoir un déploiement, vide de tout projet". ### 3. Déploiement de l'application existante @@ -74,7 +74,7 @@ Suivre la procédure complète : [deployment-existing-app](deployment-existing-a ### 4. Réinstallation du GNA (si besoin) -Si la livraison contient des modifications BOO du GNA → réinstaller le GNA : [gna-services-license — Réinstallation](gna-services-license.md#réinstallation-du-gna). +Si la livraison contient des modifications BOO du GNA → réinstaller le GNA : [gna-services-license - Réinstallation](gna-services-license.md#réinstallation-dun-gna). ### 5. Installer le **printer service** et la **licence** @@ -82,9 +82,9 @@ Suivre la procédure : [gna-services-license](gna-services-license.md) (sections ### 6. Valider la VM -Procédure de validation post-déploiement : [vm-installation — Validation](vm-installation.md#validation-de-la-vm). +Procédure de validation post-déploiement : [vm-installation - Validation](vm-installation.md#validation-de-la-vm). -> En particulier vérifier l'accès SmartUI / consoleRF / EasySTS depuis le PC du CdP — utiliser les ports NAT ([vm-network-routing](vm-network-routing.md)) si la VM de test est sur un autre poste. +> En particulier vérifier l'accès SmartUI / consoleRF / EasySTS depuis le PC du CdP - utiliser les ports NAT ([vm-network-routing](vm-network-routing.md)) si la VM de test est sur un autre poste. ### 7. Mise à jour des tâches Jira @@ -117,10 +117,10 @@ Le tag fige le commit → la livraison est **reproductible** et **garantie sans ## Related -- [Git Branch Lifecycle](git-branch-lifecycle.md) — phase "développement initial", quand cette procédure s'applique -- [Git Workflow (Git Flow)](git-workflow.md) — opérations Git détaillées (CLI / SourceTree) -- [Deploy Existing Application](deployment-existing-app.md) — procédure de redéploiement réutilisée à l'étape 3 -- [Deploy Specific Commit](deployment-specific-commit.md) — procédure jumelle pour figer un commit sur sa propre VM de dev (vs VM de test partagée ici) -- [GNA, Services & License](gna-services-license.md) — étapes 4 (réinstallation GNA) et 5 (printer + licence) -- [VM Installation & Validation](vm-installation.md) — checkpoint "Deploy 0" et validation post-déploiement -- [VM Network Routing](vm-network-routing.md) — accès distant à la VM de test depuis le PC du CdP +- [Git Branch Lifecycle](git-branch-lifecycle.md) - phase "développement initial", quand cette procédure s'applique +- [Git Workflow (Git Flow)](git-workflow.md) - opérations Git détaillées (CLI / SourceTree) +- [Deploy Existing Application](deployment-existing-app.md) - procédure de redéploiement réutilisée à l'étape 3 +- [Deploy Specific Commit](deployment-specific-commit.md) - procédure jumelle pour figer un commit sur sa propre VM de dev (vs VM de test partagée ici) +- [GNA, Services & License](gna-services-license.md) - étapes 4 (réinstallation GNA) et 5 (printer + licence) +- [VM Installation & Validation](vm-installation.md) - checkpoint "Deploy 0" et validation post-déploiement +- [VM Network Routing](vm-network-routing.md) - accès distant à la VM de test depuis le PC du CdP diff --git a/wiki/operations/deployment-existing-app.md b/wiki/operations/deployment-existing-app.md index b2442d0..f0ca1df 100644 --- a/wiki/operations/deployment-existing-app.md +++ b/wiki/operations/deployment-existing-app.md @@ -26,9 +26,9 @@ Procédure de **redéploiement** d'un projet EasyWMS déjà initialisé sur une Elle **ne couvre pas le premier déploiement** d'un projet neuf (cf. [first-deployment](first-deployment.md)), ni le déploiement d'un commit figé (cf. [deployment-specific-commit](deployment-specific-commit.md)). -Source : Confluence EasyWMS France — *Déploiement d'une application existante* (v20, 04/07/2024). +Source : Confluence EasyWMS France - *Déploiement d'une application existante* (v20, 04/07/2024). -## Étape 1 — Vérifier `env.secrets.yaml` +## Étape 1 - Vérifier `env.secrets.yaml` Dans **`C:\deploy\env.secrets.yaml`** sur la VM, vérifier les paramètres BDD : @@ -46,7 +46,7 @@ Dans **`C:\deploy\env.secrets.yaml`** sur la VM, vérifier les paramètres BDD : | `Server` | `localhost` | | `Password` (toutes BDD) | `robmec` | -## Étape 2 — Déploiement complet +## Étape 2 - Déploiement complet Ouvrir **PowerShell en administrateur** dans **`C:\deploy`** de la VM (`cd C:\deploy`). @@ -76,13 +76,13 @@ Exemple : À exécuter uniquement si le projet repose encore sur les anciens scripts (pas `deploy_repository.ps1`). -### 3 — Deploy 1 (Complete) +### 3 - Deploy 1 (Complete) ```powershell .\deploy.ps1 # choisir "1. Complete" ``` -### 4 — Intégrer la config entrepôt (Load) +### 4 - Intégrer la config entrepôt (Load) ```powershell .\deploy.ps1 # choisir "2. Load" @@ -94,7 +94,7 @@ Charge : > Alternative : **EasyS → Transfert Data** vers la VM. -### 5 — Assignation utilisateur +### 5 - Assignation utilisateur ```powershell .\Commands\commands.ps1 @@ -102,13 +102,13 @@ Charge : Ou via **SmartUI → Organisation → Utilisateurs** → éditer `mecalux` → ajouter les sites autorisés. -### 6 — Import de l'application custom +### 6 - Import de l'application custom -Voir [custom-application-management — Import](custom-application-management.md#import). +Voir [custom-application-management - Import](custom-application-management.md#import). -## Étape 7 — Désactiver les instances en BDD (OBLIGATOIRE) +## Étape 7 - Désactiver les instances en BDD (OBLIGATOIRE) -> ⚠️ Sans cette étape, **les instances ne fonctionneront pas** — cette modification est requise à **chaque redéploiement** (le fichier `Tenants.xml` est régénéré). +> ⚠️ Sans cette étape, **les instances ne fonctionneront pas** - cette modification est requise à **chaque redéploiement** (le fichier `Tenants.xml` est régénéré). Dans **`C:\inetpub\wwwroot\ApplicationService\Tenants.xml`**, remplacer : @@ -148,9 +148,9 @@ Puis : `iisreset` ou recyclage du pool **ApplicationService**. ## Related -- [VM Installation](vm-installation.md) — pré-requis VM + validation -- [First Deployment](first-deployment.md) — à lire d'abord si le projet n'a jamais été déployé -- [Deploy Specific Commit](deployment-specific-commit.md) — variante pour cibler un commit figé plutôt qu'un HEAD de branche -- [Custom Application Management](custom-application-management.md) — import/export de la custom app -- [Git Workflow](git-workflow.md) — sélection de la branche cible -- [GNA, Services & License](gna-services-license.md) — réinstaller GNA après redéploiement si scripts BOO modifiés +- [VM Installation](vm-installation.md) - pré-requis VM + validation +- [First Deployment](first-deployment.md) - à lire d'abord si le projet n'a jamais été déployé +- [Deploy Specific Commit](deployment-specific-commit.md) - variante pour cibler un commit figé plutôt qu'un HEAD de branche +- [Custom Application Management](custom-application-management.md) - import/export de la custom app +- [Git Workflow](git-workflow.md) - sélection de la branche cible +- [GNA, Services & License](gna-services-license.md) - réinstaller GNA après redéploiement si scripts BOO modifiés diff --git a/wiki/operations/deployment-specific-commit.md b/wiki/operations/deployment-specific-commit.md index cf02b77..a5acc86 100644 --- a/wiki/operations/deployment-specific-commit.md +++ b/wiki/operations/deployment-specific-commit.md @@ -23,7 +23,7 @@ Procédure pour déployer une VM de développement sur un **commit figé** plut Le principe : créer un tag GIT sur le commit cible, créer une branche à partir de ce tag, puis utiliser le mécanisme standard de déploiement par branche (`deploy_repository.ps1 `). -Source : Confluence EasyWMS France — *Déploiement d'une VM sur un commit spécifique* (v3, 09/06/2023). +Source : Confluence EasyWMS France - *Déploiement d'une VM sur un commit spécifique* (v3, 09/06/2023). ## Prérequis @@ -78,14 +78,14 @@ Côté VM, utiliser le script de déploiement standard en référençant la nouv .\deploy_repository.ps1 NomDuProjetGit NomDeLaNouvelleBranche ``` -La suite (Tenants.xml → `InMemory`, `iisreset`…) suit la procédure standard de redéploiement : cf. [deployment-existing-app](deployment-existing-app.md#étape-7--désactiver-les-instances-en-bdd-obligatoire). +La suite (Tenants.xml → `InMemory`, `iisreset`…) suit la procédure standard de redéploiement : cf. [deployment-existing-app](deployment-existing-app.md#étape-7---désactiver-les-instances-en-bdd-obligatoire). ## Règles pratiques -- **Un tag + une branche par version à déployer** — ne jamais forcer le déploiement directement sur un commit détaché, qui échapperait au script de déploiement (basé sur branche). -- **Nommage `-V` incrémental** — facilite la lecture de l'historique et le support côté client. -- **Fetch all tags avant toute opération** — sinon risque de recréer un tag qui existe déjà, ou de manquer la version cible. -- **Pousser tags et branches** — si l'autre dev / l'environnement de test doit pouvoir y accéder, le push est indispensable. +- **Un tag + une branche par version à déployer** - ne jamais forcer le déploiement directement sur un commit détaché, qui échapperait au script de déploiement (basé sur branche). +- **Nommage `-V` incrémental** - facilite la lecture de l'historique et le support côté client. +- **Fetch all tags avant toute opération** - sinon risque de recréer un tag qui existe déjà, ou de manquer la version cible. +- **Pousser tags et branches** - si l'autre dev / l'environnement de test doit pouvoir y accéder, le push est indispensable. ## Common errors @@ -96,6 +96,6 @@ La suite (Tenants.xml → `InMemory`, `iisreset`…) suit la procédure standard ## Related -- [Deploy Existing Application](deployment-existing-app.md) — procédure de déploiement standard (référencée en étape 4) -- [First Deployment](first-deployment.md) — première initialisation d'un projet -- [Git Workflow](git-workflow.md) — stratégie de branches générale +- [Deploy Existing Application](deployment-existing-app.md) - procédure de déploiement standard (référencée en étape 4) +- [First Deployment](first-deployment.md) - première initialisation d'un projet +- [Git Workflow](git-workflow.md) - stratégie de branches générale diff --git a/wiki/operations/development-methodology.md b/wiki/operations/development-methodology.md index eb75d46..4c0e311 100644 --- a/wiki/operations/development-methodology.md +++ b/wiki/operations/development-methodology.md @@ -22,10 +22,10 @@ Méthode de développement interne Mecalux EasyWMS France pour les **custom appl Objectifs : -1. **Réduire les temps de compilation** — chaque développeur compile uniquement sa propre branche +1. **Réduire les temps de compilation** - chaque développeur compile uniquement sa propre branche 2. **Distinguer clairement** trois états : ce qui est **en production**, ce qui est **à livrer** (validé, prêt pour release) et ce qui est **en cours de développement** (non validé) -Référence source : Confluence EasyWMS France — *Présentation méthode de développement* (v8, 29/12/2023). +Référence source : Confluence EasyWMS France - *Présentation méthode de développement* (v8, 29/12/2023). ## Stratégie de branches GIT @@ -49,7 +49,7 @@ Référence source : Confluence EasyWMS France — *Présentation méthode de d 1. Lorsqu'une partie ou la totalité des développements est terminée, la custom application est déployée sur une **machine dédiée hébergée sur le serveur de test**. 2. Les **testeurs** testent depuis ce serveur sans avoir à monter une machine sur leur propre PC. -3. Correction des bugs — **deux options** (point à valider selon le chantier) : +3. Correction des bugs - **deux options** (point à valider selon le chantier) : - **Option A** : le développeur corrige **directement sur le serveur de test**. - **Option B** : le développeur corrige sur sa **machine de développement locale** puis **redéploie sur le serveur de test**. @@ -75,10 +75,10 @@ post-production ───────────────● ─── (cré ## Règles pratiques -- **Ne jamais committer directement sur `master`** — toute modification passe par `développement` puis release. -- **Ne jamais merger `post-production` prématurément** — cela écraserait des correctifs présents sur `master`. +- **Ne jamais committer directement sur `master`** - toute modification passe par `développement` puis release. +- **Ne jamais merger `post-production` prématurément** - cela écraserait des correctifs présents sur `master`. - **Redéploiement de la custom app après chaque merge/rebase** pour vérifier que la compilation passe et que l'app démarre. -- **Fichier Markdown obligatoire pour le manuel de reten** durant tout le développement — la conversion vers DOC n'intervient qu'en fin de chantier. +- **Fichier Markdown obligatoire pour le manuel de reten** durant tout le développement - la conversion vers DOC n'intervient qu'en fin de chantier. ## Common errors @@ -89,6 +89,6 @@ post-production ───────────────● ─── (cré ## Related -- [System Architecture Overview](../architecture/overview.md) — contexte de déploiement custom apps (IIS, compilation, SaaS vs on-premise) -- [Application Dictionary](../architecture/application-dictionary.md) — éléments AD packagés dans la custom app -- [Configuration Guide](configuration-guide.md) — configuration post-déploiement +- [System Architecture Overview](../architecture/overview.md) - contexte de déploiement custom apps (IIS, compilation, SaaS vs on-premise) +- [Application Dictionary](../architecture/application-dictionary.md) - éléments AD packagés dans la custom app +- [Configuration Guide](configuration-guide.md) - configuration post-déploiement diff --git a/wiki/operations/first-deployment.md b/wiki/operations/first-deployment.md index 7efac1a..88b38a3 100644 --- a/wiki/operations/first-deployment.md +++ b/wiki/operations/first-deployment.md @@ -26,9 +26,9 @@ Procédure de **premier déploiement** d'un projet EasyWMS sur une VM de dévelo Cette procédure n'est exécutée qu'**une seule fois par projet**. Pour tous les déploiements ultérieurs (autre dev rejoignant le projet, redéploiement après modif), voir [deployment-existing-app](deployment-existing-app.md). -Source : Confluence EasyWMS France — *Premier déploiement* (v39, 07/08/2025). +Source : Confluence EasyWMS France - *Premier déploiement* (v39, 07/08/2025). -## Étape 1 — `DeployConfig.yaml` +## Étape 1 - `DeployConfig.yaml` Le fichier **`build/DeployConfig.yaml`** du dépôt GIT du projet pilote le déploiement. S'il est absent, le télécharger et l'y placer. Champs critiques à vérifier : @@ -79,7 +79,7 @@ Data: test ### StandardApplications -Les applications à installer — reprendre la liste `` du `responses.xml` du projet, en ne gardant que celles avec `Use="Yes"` : +Les applications à installer - reprendre la liste `` du `responses.xml` du projet, en ne gardant que celles avec `Use="Yes"` : ```yaml StandardApplications: @@ -88,7 +88,7 @@ StandardApplications: ### EnabledModules -Liste complète des modules à activer — reprendre la balise `` du `responses.xml`, **sauf `EasyWMS`** (inclus par défaut). +Liste complète des modules à activer - reprendre la balise `` du `responses.xml`, **sauf `EasyWMS`** (inclus par défaut). > ⚠️ **Problème connu versions 24.xx.xx.xx** : l'étape *"Importing apps with AD..."* peut durer très longtemps et échouer avec une erreur `System.Management.Automation.RuntimeException`. Dans ce cas, ajouter **`ToggleService`** à la liste. @@ -127,7 +127,7 @@ EnabledModules: ### Customs (application custom) -Laisser **vide pour ce premier déploiement** — renseigné à l'étape 10. +Laisser **vide pour ce premier déploiement** - renseigné à l'étape 10. ### Users @@ -140,13 +140,13 @@ Users: Groups: SuperAdmin,Administrators,Managers,Operators ``` -## Étape 2 — Déposer le fichier de layout EasyS +## Étape 2 - Déposer le fichier de layout EasyS Placer le fichier de configuration entrepôt EasyS (ex : `MAPAB_layout.cfg2014`) dans le dossier **`layout_config/`** du dépôt GIT. -> ⚠️ Bien **commit et push** après dépôt — le script de déploiement clone le GIT. +> ⚠️ Bien **commit et push** après dépôt - le script de déploiement clone le GIT. -## Étape 3 — Vérifier `env.secrets.yaml` sur la VM +## Étape 3 - Vérifier `env.secrets.yaml` sur la VM Dans **`C:\deploy\env.secrets.yaml`** de la VM, vérifier que les paramètres BDD correspondent à la BDD de la VM : @@ -156,7 +156,7 @@ Dans **`C:\deploy\env.secrets.yaml`** de la VM, vérifier que les paramètres BD | `Server` | `localhost/orcl` (Oracle) / `localhost` (PostgreSQL) | | `Password` (toutes BDD) | `robmec` | -## Étape 4 — Déploiement complet (script unifié) +## Étape 4 - Déploiement complet (script unifié) Ouvrir **PowerShell en administrateur** dans **`C:\deploy`** de la VM : @@ -188,13 +188,13 @@ Exemple : À n'exécuter que si le projet utilise les **anciens scripts** `deploy.ps1` + `commands.ps1` (pas `deploy_repository.ps1`). -### 5 — Deploy 1 (Complete) +### 5 - Deploy 1 (Complete) ```powershell .\deploy.ps1 # choisir "1. Complete" ``` -### 6 — Load (config entrepôt + paramètres uGNA) +### 6 - Load (config entrepôt + paramètres uGNA) ```powershell .\deploy.ps1 # choisir "2. Load" @@ -206,7 +206,7 @@ Ce qui est chargé : > Alternative : charger le layout via **EasyS → Transfert Data** vers la VM. -### 7 — Assignation utilisateur +### 7 - Assignation utilisateur ```powershell .\Commands\commands.ps1 @@ -214,7 +214,7 @@ Ce qui est chargé : Alternative SmartUI : **Organisation → Utilisateurs** → sélectionner `mecalux` → ajouter les sites autorisés. -## Étape 8 — Désactiver les instances en BDD (OBLIGATOIRE) +## Étape 8 - Désactiver les instances en BDD (OBLIGATOIRE) > ⚠️ **Sans cette modification, les instances ne fonctionnent pas.** @@ -241,13 +241,13 @@ Activer le mode **Regular expression** dans `Replace` (`Ctrl+H`) : Chaque occurrence est remplacée en conservant le nom de Tenant. -## Étape 9 — Créer l'application custom +## Étape 9 - Créer l'application custom Procéder à la création initiale de la custom app et son premier export sur GIT. -Voir [custom-application-management — Création](custom-application-management.md#creation). +Voir [custom-application-management - Création](custom-application-management.md#creation). -## Étape 10 — Compléter `DeployConfig.yaml` avec le Custom +## Étape 10 - Compléter `DeployConfig.yaml` avec le Custom Une fois la custom app créée et exportée, renseigner la section `Customs` : @@ -270,7 +270,7 @@ Désormais, chaque déploiement ultérieur (`deploy_repository.ps1`) reprendra a | Clé | Type | Rôle | |-----|------|------| | `TenantName` / `TenantCode` | string | Identifiant du tenant EasyWMS | -| `DBEngine` | enum | `Oracle` / `PostgreSQL` / `SQLServer` / `MySQL` — doit matcher `env.secrets.yaml` | +| `DBEngine` | enum | `Oracle` / `PostgreSQL` / `SQLServer` / `MySQL` - doit matcher `env.secrets.yaml` | | `MAPSeed` | string (version) | Version WMS à déployer depuis mapdeploy | | `License` | enum | `PRO` / `ADVANCE` / `ENTERPRISE` | | `Warehouse` | path | Chemin relatif layout EasyS (`.cfg2014`) | @@ -291,11 +291,11 @@ Désormais, chaque déploiement ultérieur (`deploy_repository.ps1`) reprendra a ## Related -- [VM Installation](vm-installation.md) — pré-requis : VM Hyper-V créée et validée -- [Deploy Existing Application](deployment-existing-app.md) — déploiements ultérieurs (autres devs, redéploiement, changement de branche) -- [Deploy Specific Commit](deployment-specific-commit.md) — déployer un commit figé plutôt que le HEAD d'une branche -- [Custom Application Management](custom-application-management.md) — étape 9 (création initiale de la custom app) -- [Git Workflow](git-workflow.md) — stratégie de branches pour le projet -- [GNA, Services & License](gna-services-license.md) — installation des services GNA, Printer, License WMS après déploiement -- [System Architecture Overview](../architecture/overview.md) — stack cible (IIS, BDD, services) -- [Parameters](../concepts/parameters.md) — paramètres WMS chargés via uGNA (étape 6) +- [VM Installation](vm-installation.md) - pré-requis : VM Hyper-V créée et validée +- [Deploy Existing Application](deployment-existing-app.md) - déploiements ultérieurs (autres devs, redéploiement, changement de branche) +- [Deploy Specific Commit](deployment-specific-commit.md) - déployer un commit figé plutôt que le HEAD d'une branche +- [Custom Application Management](custom-application-management.md) - étape 9 (création initiale de la custom app) +- [Git Workflow](git-workflow.md) - stratégie de branches pour le projet +- [GNA, Services & License](gna-services-license.md) - installation des services GNA, Printer, License WMS après déploiement +- [System Architecture Overview](../architecture/overview.md) - stack cible (IIS, BDD, services) +- [Parameters](../concepts/parameters.md) - paramètres WMS chargés via uGNA (étape 6) diff --git a/wiki/operations/galileo-simulation.md b/wiki/operations/galileo-simulation.md index cfbd118..740fe75 100644 --- a/wiki/operations/galileo-simulation.md +++ b/wiki/operations/galileo-simulation.md @@ -25,7 +25,7 @@ last_compiled: "2026-04-17" EasyS is the 3D simulation front-end that speaks the same protocol as GALILEO. Running EasyS + EasyWMS Gateway on a dev VM lets you reproduce the full robotic flow (PIE → Miniload → PK → PS) without physical hardware. This page covers Gateway install, EasyS simulation configuration, PIE event injection, pick/shipping test flows, and station/route synchronisation procedures. Shared demo environment (Mecalux France): -- VM **ALL** on server **LYOITSW02** — IP `10.58.10.75` +- VM **ALL** on server **LYOITSW02** - IP `10.58.10.75` - Credentials: `mecalux / mecalux` - Warehouse: `WRH_MIXTE` (miniload + conveyor path) @@ -45,10 +45,10 @@ File: `C:\ProgramData\Mecalux\EasyWMS Gateway 2015\Config\MainObject.config` 1. Set **tenantCode** = the WMS tenant you want to target 2. Fill the **TokenUser** connection section (not `ClientUser`) -3. Passwords must be encrypted — run `PasswordEncrypt.exe` from `C:\Program Files\Mecalux\EasyWMS Gateway 2015` +3. Passwords must be encrypted - run `PasswordEncrypt.exe` from `C:\Program Files\Mecalux\EasyWMS Gateway 2015` 4. Start the Windows service **EasyWMSGateway2015** -Logs go to `C:\ProgramData\Mecalux\EasyWMS Gateway 2015\Logs\AllLog.log` — see [Galileo Troubleshooting](galileo-troubleshooting.md). +Logs go to `C:\ProgramData\Mecalux\EasyWMS Gateway 2015\Logs\AllLog.log` - see [Galileo Troubleshooting](galileo-troubleshooting.md). ## 2. Open port 3000 on the VM @@ -82,8 +82,8 @@ Every miniload location must be bound to a **rack type** with the exact dimensio At each PIE pass, GALILEO returns: -- **PLC Container Type** — derived from width -- **PLC Height Type** — derived from height +- **PLC Container Type** - derived from width +- **PLC Height Type** - derived from height Procedure: @@ -108,10 +108,10 @@ To simulate a TK, add an **Automatic Aisle**. The aisle ↔ rack link works like | Automatic Aisle | Stacker crane / Miniload | | PIE | Entry identification (label + weigh) | | Picking (PK) | Picking conveyor | -| PKE | PK entry control — if full, recirculate | +| PKE | PK entry control - if full, recirculate | | Inbound Table (ME) | Conveyor into the TK/Miniload | | Outbound Table (MS) | Conveyor out of the TK/Miniload | -| CME | TK/Miniload entry control — if full, recirculate | +| CME | TK/Miniload entry control - if full, recirculate | | Outbound Post | Exit conveyor (operator can pick the container up) | | MP | Preparation table (stock drop after pick) | | Transporter | Plain conveyor with no special function | @@ -122,12 +122,12 @@ Full catalogue: [Stations & Routes](../concepts/stations.md); translation matrix Two layout patterns for double-depth racks: -- **Case #1** (most common at Mecalux France) — best for **mono-product** supports (several supports share the same item inside the TK). Rotation zones split by front face / rear face. -- **Case #2** — best for **multi-product** supports (a given item never lives in two supports simultaneously). Reduces relocations during picking without pre-emptive defragmentation. +- **Case #1** (most common at Mecalux France) - best for **mono-product** supports (several supports share the same item inside the TK). Rotation zones split by front face / rear face. +- **Case #2** - best for **multi-product** supports (a given item never lives in two supports simultaneously). Reduces relocations during picking without pre-emptive defragmentation. ### 3.7 Route configuration -Every movement needs a route in EasyS between origin and destination. A single task `PIE → Miniload` typically generates **4 movements** — the WMS creates one task, but the routing table must allow every hop. +Every movement needs a route in EasyS between origin and destination. A single task `PIE → Miniload` typically generates **4 movements** - the WMS creates one task, but the routing table must allow every hop. > If no path exists, EasyWMS generates a **reject task** toward the reject station. @@ -147,7 +147,7 @@ Multiple containers can sit on a TE/TS at once: 1. Size the table large enough physically 2. Lay out containers in **Positions** (side by side) and **Stack** (one behind the other) -3. **Logical X = 991** — except tables embedded in the rack, which inherit the replaced location's coordinates +3. **Logical X = 991** - except tables embedded in the rack, which inherit the replaced location's coordinates ### 3.9 Multidirectional tables (LTM) @@ -157,7 +157,7 @@ Set `routing options = 1` for every feeder conveyor allowed to deposit a contain 1. Add a conveyor with role **Picking** 2. Create a **Workstation** to drive the station from SmartUI -3. Define routes — where stock can arrive from, where it can leave to +3. Define routes - where stock can arrive from, where it can leave to Preparation table (TP/MP) routes: - **Manual** route from picking table → preparation tables @@ -172,7 +172,7 @@ The reject route lets the WMS redirect containers with no valid route. - Add a **VIRTUAL** route → floor zone so lost containers are moved off the simulation automatically - Reject routes render in **red**. Unlike normal routes, the red route gives the **task destination** (not the movement destination). -Different rejection reasons (`IdentError`) can point to different destinations — see [IdentErrorType](https://msscc.mecalux.com/documentation/Development/master/ES/apis/easywms/Domain/IdentErrorType.md). +Different rejection reasons (`IdentError`) can point to different destinations - see [IdentErrorType](https://msscc.mecalux.com/documentation/Development/master/ES/apis/easywms/Domain/IdentErrorType.md). ## 4. SmartUI workstation configuration @@ -183,14 +183,14 @@ Companion configuration once the EasyS layout is in place. Each preparation table is linked to a picking station. After picking confirmation, stock moves from the container to the chosen preparation table. **Assignment mode:** -- **Automatic** — WMS assigns the next order to a table -- **Manual** — operator assigns via **Menu → Control → Picking-station assignment** +- **Automatic** - WMS assigns the next order to a table +- **Manual** - operator assigns via **Menu → Control → Picking-station assignment** > ⚠️ In manual mode, **tasks do not generate until the shipping order is assigned to a table**. To switch mode: **Menu → Control → Workstations** → select preparation table(s) → **Modify assignment mode**. -> ⚠️ The preparation table must have a route to the shipping dock of the order — otherwise tasks won't generate. +> ⚠️ The preparation table must have a route to the shipping dock of the order - otherwise tasks won't generate. ### 4.2 Picking table max-concurrent orders @@ -206,7 +206,7 @@ To cap how many orders a picking table can handle in parallel: 2. Click **Start** 3. Enter the WMS server IP → **Next** 4. Uncheck **Generate simulation report** → click **Simulation 3D** -5. Watch the Gateway log (`AllLog.log`) — lots of lines with no errors = connection OK +5. Watch the Gateway log (`AllLog.log`) - lots of lines with no errors = connection OK ## 6. Inject a container at the PIE @@ -218,9 +218,9 @@ To cap how many orders a picking table can handle in parallel: - Container Type: corresponding PLC Container Type - Weight - Height Type: corresponding PLC Height Type -4. Click **Save** — a pallet/bin visibly moves on the conveyor +4. Click **Save** - a pallet/bin visibly moves on the conveyor -> ⚠️ **Valid putaway strategies must exist** — even for empty containers. No valid location ⇒ reject. +> ⚠️ **Valid putaway strategies must exist** - even for empty containers. No valid location ⇒ reject. ### Simulate a read error @@ -228,7 +228,7 @@ Tab **Scripts** on the PIE → **Prepare event** → paste: ``` machine.Flags = "256"; ``` -Then inject the container. `256` = barcode error (see [GALILEO Integration — PIE flag table](../architecture/galileo-integration.md)). +Then inject the container. `256` = barcode error (see [GALILEO Integration - PIE flag table](../architecture/galileo-integration.md)). ## 7. Extract a container from the miniload @@ -258,7 +258,7 @@ On order release, the WMS: Tasks are of type `pickingContainer`. After pick confirmation: **Store container** → **Liberate** to return the container to the miniload. -> Verify preparation-table config **before** launching an order — tasks won't generate if routes to the dock are missing. +> Verify preparation-table config **before** launching an order - tasks won't generate if routes to the dock are missing. ## 8. Speed up simulation @@ -287,7 +287,7 @@ Context.StationRoutes.Where(sr => sr.Manager.ToString() == "Galileo") ? sr.StationTo.RealLocations.FirstOrDefault().LogicalCoordinate.Side : 0, AisleNumber = sr.StationTo.AisleNumber }) -// union with StationFrom — full query on Confluence +// union with StationFrom - full query on Confluence .OrderBy(sr => sr.StationType) .ThenBy(sr => sr.StationNumber) ``` @@ -315,16 +315,16 @@ More diagnostic steps: [Galileo Troubleshooting](galileo-troubleshooting.md). ## Common errors -- **Container injected at PIE but immediately rejected** — no valid putaway strategy covers the (container type, height type) combo, or no route exists to any storage location -- **Tasks don't generate after order launch** — preparation table has no route to the dock, or assignment mode is Manual and the order isn't assigned -- **Station stays loaded indefinitely in EasyS** — Manual Action ticked without running Liberate -- **Gateway starts but no activity** — wrong `tenantCode` or `TokenUser` password; check Gateway log -- **Connection refused from EasyS** — port 3000 not open, or Gateway service not started +- **Container injected at PIE but immediately rejected** - no valid putaway strategy covers the (container type, height type) combo, or no route exists to any storage location +- **Tasks don't generate after order launch** - preparation table has no route to the dock, or assignment mode is Manual and the order isn't assigned +- **Station stays loaded indefinitely in EasyS** - Manual Action ticked without running Liberate +- **Gateway starts but no activity** - wrong `tenantCode` or `TokenUser` password; check Gateway log +- **Connection refused from EasyS** - port 3000 not open, or Gateway service not started ## Related -- [GALILEO Integration](../architecture/galileo-integration.md) — protocol reference -- [Galileo Troubleshooting](galileo-troubleshooting.md) — log patterns, fault codes -- [Robotics Project Lifecycle](robotics-project-lifecycle.md) — where simulation fits in the project plan +- [GALILEO Integration](../architecture/galileo-integration.md) - protocol reference +- [Galileo Troubleshooting](galileo-troubleshooting.md) - log patterns, fault codes +- [Robotics Project Lifecycle](robotics-project-lifecycle.md) - where simulation fits in the project plan - [VM Installation](vm-installation.md) · [VM Network Routing](vm-network-routing.md) - [Stations & Routes](../concepts/stations.md) · [Mechanical Elements](../concepts/mechanical-elements.md) · [Putaway](../concepts/putaway.md) diff --git a/wiki/operations/galileo-troubleshooting.md b/wiki/operations/galileo-troubleshooting.md index bbc19e3..c2e6e0c 100644 --- a/wiki/operations/galileo-troubleshooting.md +++ b/wiki/operations/galileo-troubleshooting.md @@ -21,7 +21,7 @@ last_compiled: "2026-04-17" How to read Gateway logs, interpret station / route updates, trace a container through a simulation or production run, and resolve the most common GALILEO faults (EndErrorCode=4, 1116 incorrect task, variator faults). Pair this page with [GALILEO Integration](../architecture/galileo-integration.md) for the protocol reference and [Galileo Simulation](galileo-simulation.md) for the bring-up procedure. -## 1. Gateway log — location & structure +## 1. Gateway log - location & structure `C:\ProgramData\Mecalux\EasyWMS Gateway 2015\Logs\AllLog.log` @@ -46,7 +46,7 @@ Fields carried on each update: | **CurrentCount** | Trackings currently on the station | | **Aisle** | Aisle number bound to the station | -> The couple **StationType + StationNumber** is unique — always identify a station by that pair. +> The couple **StationType + StationNumber** is unique - always identify a station by that pair. ### 1.2 Route update line @@ -56,13 +56,13 @@ Fields carried on each update: | StationTypeDestination / StationNumberDestination | Destination station | | **Status** | `1` = free, `3` = full | -(Protocol also defines `0` = no comms, `2` = electromechanical fault — see [GALILEO Integration](../architecture/galileo-integration.md).) +(Protocol also defines `0` = no comms, `2` = electromechanical fault - see [GALILEO Integration](../architecture/galileo-integration.md).) ### 1.3 Event, Search, End -- **Event** — typically a PIE event with barcode + weight + dimensions + container/height types -- **Search** — a TK or conveyor asking for the next order -- **End** — confirmation the container reached its destination (with an error code) +- **Event** - typically a PIE event with barcode + weight + dimensions + container/height types +- **Search** - a TK or conveyor asking for the next order +- **End** - confirmation the container reached its destination (with an error code) ## 2. Trace a container in klogg @@ -82,15 +82,15 @@ Two search patterns are usually enough to reconstruct a container's history. This two-step pattern answers most "where is container X?" questions without paging through the whole log. -## 3. End error codes — diagnosis +## 3. End error codes - diagnosis | Code | Meaning | First action | |------|---------|--------------| -| `0` | Movement complete | None — next movement generated | +| `0` | Movement complete | None - next movement generated | | `1` | Deposit error | Inspect the destination location, relocation/reject task expected | | `2` | Extraction error | Inspect the source location, relocation/reject task expected | -| `4` | Inconsistent order | WMS/GALILEO config mismatch — see section 3.1 | -| `7` | Gauge error | Container fails dimensional check — routed to REAC / RECH | +| `4` | Inconsistent order | WMS/GALILEO config mismatch - see section 3.1 | +| `7` | Gauge error | Container fails dimensional check - routed to REAC / RECH | ### 3.1 EndErrorCode = 4 (most frequent) @@ -103,14 +103,14 @@ GALILEO did not understand the order. Root cause is **always** a configuration d - Two containers planned to cross paths (impossible movement) - Coordinate system discrepancy between sides of the entry table vs the aisle -**Resolution — 4 steps:** +**Resolution - 4 steps:** 1. Grab the frame sent to GALILEO from the Gateway log (Station types, numbers, coordinates, container/height type) 2. Open the GALILEO program: `C:\\Programme\.mgp` (double-click to launch) -3. Compare the station list between GALILEO and EasyS — aisle, allowed types, X/Y — line by line -4. Use the station query shipped with [Galileo Simulation — §9.1](galileo-simulation.md) to dump the WMS-side view +3. Compare the station list between GALILEO and EasyS - aisle, allowed types, X/Y - line by line +4. Use the station query shipped with [Galileo Simulation - §9.1](galileo-simulation.md) to dump the WMS-side view -If you change anything on the GALILEO side, also sync the change in EasyS (and vice versa) — the two systems must stay in lock-step. +If you change anything on the GALILEO side, also sync the change in EasyS (and vice versa) - the two systems must stay in lock-step. ## 4. GALILEO fault codes @@ -119,16 +119,16 @@ Faults reported on the GALILEO SCADA / Automation Dashboard. See [Automation Das | Code | Name | Typical causes | |------|------|----------------| | **1116** | Incorrect task CU1 | Location locked on GALILEO but not on EasyWMS (or vice versa); location exists in EasyWMS but not in GALILEO; same location has different allowed container types on each side; WMS asks to deposit on the left rack while the container sits on the right fork of the miniload (and vice versa) | -| **1201** | Variator fault X | — (variator hardware fault on axis X) | +| **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` at the automation layer — same root cause, different reporting surface. +Fault 1116 is the configuration-drift counterpart of `EndErrorCode=4` at the automation layer - same root cause, different reporting surface. ## 5. Change the WMS address inside GALILEO When the WMS server IP or DNS changes (migration, VM rename, network reconfig), the GALILEO side must be updated so the PLC can reach the new Gateway. -> ⚠️ The Confluence page for this procedure contains only screenshots (no extractable text). Refer to [Confluence — Changer l'adresse du WMS dans GALILEO](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000756076552) for the step-by-step screen walkthrough. +> ⚠️ The Confluence page for this procedure contains only screenshots (no extractable text). Refer to [Confluence - Changer l'adresse du WMS dans GALILEO](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000756076552) for the step-by-step screen walkthrough. High-level: update the WMS IP / hostname inside the GALILEO program configuration (the `.mgp` file under `C:\\Programme\`) and restart the GALILEO runtime. Then verify the Gateway log picks up the new connection. @@ -136,19 +136,19 @@ High-level: update the WMS IP / hostname inside the GALILEO program configuratio Before opening a ticket or calling Support: -- [ ] Gateway service (`EasyWMSGateway2015`) is **Running** -- [ ] `AllLog.log` shows recent traffic (not frozen, no error spike) -- [ ] Port 3000 is open on the WMS host (inbound + outbound) -- [ ] `tenantCode` and `TokenUser` in `MainObject.config` match the target WMS -- [ ] The specific (StationType, StationNumber) pair exists on both sides with identical parameters -- [ ] Allowed container types + PLC Height Type couple match on both sides -- [ ] No untracked containers stranded on blind conveyors (LBC, LRL — see [Mechanical Elements](../concepts/mechanical-elements.md)) -- [ ] Automation Dashboard fault report consulted to correlate with machine-level faults +- ☐ Gateway service (`EasyWMSGateway2015`) is **Running** +- ☐ `AllLog.log` shows recent traffic (not frozen, no error spike) +- ☐ Port 3000 is open on the WMS host (inbound + outbound) +- ☐ `tenantCode` and `TokenUser` in `MainObject.config` match the target WMS +- ☐ The specific (StationType, StationNumber) pair exists on both sides with identical parameters +- ☐ Allowed container types + PLC Height Type couple match on both sides +- ☐ No untracked containers stranded on blind conveyors (LBC, LRL - see [Mechanical Elements](../concepts/mechanical-elements.md)) +- ☐ Automation Dashboard fault report consulted to correlate with machine-level faults ## Related -- [GALILEO Integration](../architecture/galileo-integration.md) — protocol reference, workflows, command/event catalogue -- [Galileo Simulation](galileo-simulation.md) — EasyS bring-up, station sync query +- [GALILEO Integration](../architecture/galileo-integration.md) - protocol reference, workflows, command/event catalogue +- [Galileo Simulation](galileo-simulation.md) - EasyS bring-up, station sync query - [General Troubleshooting Guide](troubleshooting.md) - [Stations & Routes](../concepts/stations.md) · [Mechanical Elements](../concepts/mechanical-elements.md) -- [Automation Dashboard](../modules/automation-dashboard.md) — fault reporting UI +- [Automation Dashboard](../modules/automation-dashboard.md) - fault reporting UI diff --git a/wiki/operations/git-branch-lifecycle.md b/wiki/operations/git-branch-lifecycle.md index bed821e..f90dbdd 100644 --- a/wiki/operations/git-branch-lifecycle.md +++ b/wiki/operations/git-branch-lifecycle.md @@ -16,12 +16,12 @@ last_compiled: "2026-04-17" Stratégie de gestion **par phase de projet** des branches Git pour les projets EasyWMS France : qui fait quoi, à quel moment, sur quelle branche. Cette page complète : -- [development-methodology](development-methodology.md) — vue d'ensemble (master / développement / post-production) -- [git-workflow](git-workflow.md) — procédure opérationnelle Git Flow (CLI / SourceTree) +- [development-methodology](development-methodology.md) - vue d'ensemble (master / développement / post-production) +- [git-workflow](git-workflow.md) - procédure opérationnelle Git Flow (CLI / SourceTree) …en explicitant les **règles de gouvernance** entre les acteurs (Dev, CdP, Support, TMA) au fil du cycle de vie : **Développement → Mise en service (MEP) → Hypercare → TLM (Tierce Maintenance) → TMA (Tierce Maintenance Applicative)**. -Source : Confluence EasyWMS France — *Gestion du GIT* (v1, 27/02/2024). +Source : Confluence EasyWMS France - *Gestion du GIT* (v1, 27/02/2024). ## Acteurs @@ -90,9 +90,9 @@ Outil : **Git Flow dans Sourcetree**. ## 4. Pendant la TLM et la TMA -### a. Branches `hotfix` — équipe Support +### a. Branches `hotfix` - équipe Support -**Cas 1 — Modifications longues / conséquentes ou testées sur intégration d'abord :** +**Cas 1 - Modifications longues / conséquentes ou testées sur intégration d'abord :** | # | Acteur | Action | |---|---|---| @@ -100,14 +100,14 @@ Outil : **Git Flow dans Sourcetree**. | 2 | Support | Merger `hotfix` → `master` à la livraison | | 3 | Support | **Prévenir l'équipe TMA** qu'une livraison a eu lieu *(pour mise à jour des branches `release` en cours)* | -**Cas 2 — Modifications directes en production :** +**Cas 2 - Modifications directes en production :** | # | Acteur | Action | |---|---|---| | 1 | Support | **Exporter la production dans `master`** | | 2 | Support | **Prévenir l'équipe TMA** qu'une livraison a eu lieu | -### b. Branches `release` — équipe TMA +### b. Branches `release` - équipe TMA | # | Acteur | Action | |---|---|---| @@ -123,7 +123,7 @@ Outil : **Git Flow dans Sourcetree**. > ⚠️ Communication **bidirectionnelle obligatoire** sur les livraisons : > - Dev ↔ CdP (pendant le projet) -> - **Support ↔ TMA** (pendant TLM/TMA — chaque livraison de l'un impose un re-merge de l'autre) +> - **Support ↔ TMA** (pendant TLM/TMA - chaque livraison de l'un impose un re-merge de l'autre) > > Une livraison non communiquée provoque des conflits Git lourds + risque de régressions en prod. @@ -152,6 +152,6 @@ master ──────────────────────── ## Related -- [Development Methodology (Custom Apps)](development-methodology.md) — stratégie haut niveau master/développement/post-production -- [Git Workflow (Git Flow)](git-workflow.md) — commandes Git Flow CLI + SourceTree (le "comment" opérationnel) -- [Deploy Test Application](deploy-test-application.md) — création du tag `-V` et déploiement de la livraison en test +- [Development Methodology (Custom Apps)](development-methodology.md) - stratégie haut niveau master/développement/post-production +- [Git Workflow (Git Flow)](git-workflow.md) - commandes Git Flow CLI + SourceTree (le "comment" opérationnel) +- [Deploy Test Application](deploy-test-application.md) - création du tag `-V` et déploiement de la livraison en test diff --git a/wiki/operations/git-workflow.md b/wiki/operations/git-workflow.md index b10d30e..fb786ba 100644 --- a/wiki/operations/git-workflow.md +++ b/wiki/operations/git-workflow.md @@ -30,7 +30,7 @@ Workflow **Git Flow** appliqué aux projets EasyWMS France. Git Flow est une ext La gestion est expliquée en parallèle via **invite de commande (CLI)** et **[SourceTree](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000088854571)** (configuré en anglais). -Source : Confluence EasyWMS France — *Gestion des versions du projet avec GIT* (v27, 22/08/2025). +Source : Confluence EasyWMS France - *Gestion des versions du projet avec GIT* (v27, 22/08/2025). ### Ressources externes @@ -90,7 +90,7 @@ git flow feature start ### Déployer la VM sur la nouvelle branche -1. Appliquer le point de contrôle **"DEPLOY 0"** sur la VM (cf. [vm-installation](vm-installation.md#7--point-de-contrôle-deploy-0)) +1. Appliquer le point de contrôle **"DEPLOY 0"** sur la VM (cf. [vm-installation](vm-installation.md#7-point-de-contrôle-deploy-0)) 2. Déployer la branche : cf. [deployment-existing-app](deployment-existing-app.md) > Si une pop-up de connexion apparaît sur SmartUI après déploiement : [procédure dédiée Confluence](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000144789544) @@ -99,11 +99,11 @@ Vous êtes prêt à commencer vos développements. ✅ ## 3. Commit de vos modifications -### Étape préalable — exporter les modifications +### Étape préalable - exporter les modifications Avant tout commit, exporter **tout ce qui a été modifié** : -1. **Custom app** → cf. [custom-application-management — Export](custom-application-management.md#export) +1. **Custom app** → cf. [custom-application-management - Export](custom-application-management.md#export) 2. **Paramètres / config WMS modifiés** → export datas via **[uGNA](ugna-data-export.md)** (procédure complète avec liste des entités et erreurs droits) 3. **Fichiers BOO du GNA modifiés** → exécuter [`GNAGetDataForGit.ps1`](gna-services-license.md#sauvegarder-la-configuration-sur-le-git) @@ -132,7 +132,7 @@ git push > ℹ️ Les fichiers générés par l'export de la custom app sont **séparés en plusieurs fichiers** pour un même élément (workflow, source C#, DESIGN…). Bien prendre **tous** les fichiers portant le nom de l'élément modifié. -> ⚠️ **Règle absolue : commit et push ses développements tous les soirs avant de quitter les bureaux** — évite toute perte (perte/vol/casse du PC). +> ⚠️ **Règle absolue : commit et push ses développements tous les soirs avant de quitter les bureaux** - évite toute perte (perte/vol/casse du PC). ## 4. Fin de la tâche de développement @@ -177,10 +177,10 @@ git rebase --continue ``` **SourceTree :** -1. **Ne pas faire de commit** — uniquement **"stage"** les fichiers résolus +1. **Ne pas faire de commit** - uniquement **"stage"** les fichiers résolus 2. **"Continue Rebase"** 3. Répéter pour chaque commit de `develop` -4. Recommencer la clôture de la feature — cette fois **sans cocher "Rebase"** +4. Recommencer la clôture de la feature - cette fois **sans cocher "Rebase"** ### 4.4 Mettre à jour Jira @@ -188,11 +188,11 @@ Passer le ticket à **"Revue de code"**. ## Checklist journalière -- [ ] `git pull` en début de journée sur votre branche -- [ ] Commits petits et explicites tout au long de la journée -- [ ] **Avant commit** : export custom app + uGNA + GNA (si concerné) -- [ ] **Soir** : tous les commits poussés sur le remote (**règle absolue**) -- [ ] Avant clôture : `develop` à jour + rebase réussi +- ☐ `git pull` en début de journée sur votre branche +- ☐ Commits petits et explicites tout au long de la journée +- ☐ **Avant commit** : export custom app + uGNA + GNA (si concerné) +- ☐ **Soir** : tous les commits poussés sur le remote (**règle absolue**) +- ☐ Avant clôture : `develop` à jour + rebase réussi ## Parameters / Branches Git Flow @@ -202,7 +202,7 @@ Passer le ticket à **"Revue de code"**. | Bugfix | `bugfix/` | `develop` | `develop` | Corrections de bugs sur le développement en cours | | Release | `release/` | `develop` | `master` + `develop` | Préparation d'une release | | Hotfix | `hotfix/` | `master` | `master` + `develop` | Correctifs urgents en production | -| Support | `support/` | `master` | — | Maintien d'une version antérieure | +| Support | `support/` | `master` | - | Maintien d'une version antérieure | ## Common errors @@ -216,12 +216,12 @@ Passer le ticket à **"Revue de code"**. ## Related -- [Development Methodology](development-methodology.md) — cadre général (branches `master`/`développement`/`post-production`, phases dev/test/post-prod) -- [Git Branch Lifecycle](git-branch-lifecycle.md) — gouvernance par phase de projet (Dev / MEP / Hypercare / TLM / TMA), rôles Dev/CdP/Support/TMA -- [SSH Keys Setup (MSSCODE & Sourcetree)](ssh-keys-setup.md) — clé SSH ed25519 pour ne plus saisir les identifiants MSSCODE -- [Custom Application Management](custom-application-management.md) — export/import systématique avant commit -- [uGNA Data Export](ugna-data-export.md) — export config WMS via `uGNAConsole.exe -Z:` (étape pré-commit) -- [Code Review Process](code-review-process.md) — revue Code/Fonctionnel/Documentation avant `Finish Feature` -- [Deploy Existing Application](deployment-existing-app.md) — déploiement après pull ou changement de branche -- [Deploy Specific Commit](deployment-specific-commit.md) — figer un commit pour démo / debug -- [GNA, Services & License](gna-services-license.md) — sauvegarde GIT des scripts BOO avant commit +- [Development Methodology](development-methodology.md) - cadre général (branches `master`/`développement`/`post-production`, phases dev/test/post-prod) +- [Git Branch Lifecycle](git-branch-lifecycle.md) - gouvernance par phase de projet (Dev / MEP / Hypercare / TLM / TMA), rôles Dev/CdP/Support/TMA +- [SSH Keys Setup (MSSCODE & Sourcetree)](ssh-keys-setup.md) - clé SSH ed25519 pour ne plus saisir les identifiants MSSCODE +- [Custom Application Management](custom-application-management.md) - export/import systématique avant commit +- [uGNA Data Export](ugna-data-export.md) - export config WMS via `uGNAConsole.exe -Z:` (étape pré-commit) +- [Code Review Process](code-review-process.md) - revue Code/Fonctionnel/Documentation avant `Finish Feature` +- [Deploy Existing Application](deployment-existing-app.md) - déploiement après pull ou changement de branche +- [Deploy Specific Commit](deployment-specific-commit.md) - figer un commit pour démo / debug +- [GNA, Services & License](gna-services-license.md) - sauvegarde GIT des scripts BOO avant commit diff --git a/wiki/operations/gna-services-license.md b/wiki/operations/gna-services-license.md index 62057da..460ac0e 100644 --- a/wiki/operations/gna-services-license.md +++ b/wiki/operations/gna-services-license.md @@ -20,13 +20,13 @@ last_compiled: "2026-04-17" Procédures d'installation et de gestion des **services adjacents** au WMS sur une VM de développement : -- **GNA** (Generic Notification Applications) — service de messagerie ERP ↔ WMS : sauvegarde GIT des scripts/XSD + réinstallation sur VM -- **Label Printer** — service d'impression d'étiquettes -- **Licence WMS** (EasySTS) — demande / import de la licence projet pour que la VM fonctionne au-delà de 7 jours +- **GNA** (Generic Notification Applications) - service de messagerie ERP ↔ WMS : sauvegarde GIT des scripts/XSD + réinstallation sur VM +- **Label Printer** - service d'impression d'étiquettes +- **Licence WMS** (EasySTS) - demande / import de la licence projet pour que la VM fonctionne au-delà de 7 jours -Le GNA est le composant qui porte la communication ERP (messages tels que `ROR`, `SOR`, `STV`, `SOF`…) — voir [erp-interface](../concepts/erp-interface.md) pour la sémantique fonctionnelle des messages. +Le GNA est le composant qui porte la communication ERP (messages tels que `ROR`, `SOR`, `STV`, `SOF`…) - voir [erp-interface](../concepts/erp-interface.md) pour la sémantique fonctionnelle des messages. -Source : Confluence EasyWMS France — *Installation Services et Licence WMS* (v19, 15/04/2025). +Source : Confluence EasyWMS France - *Installation Services et Licence WMS* (v19, 15/04/2025). ## Service GNA @@ -50,9 +50,9 @@ Le script **exporte les fichiers nécessaires à l'installation du GNA** (script > ⚠️ Les XSD sont **composés à l'installation** à partir des fichiers du dossier `XSD_Source` de votre GNA. > -> **Ne pas copier directement le XML du dossier `XSD` de votre GNA** — il serait pris comme "source" et recomposé avec les `XSD_Source` des autres applications, entraînant des **duplications de lignes**. +> **Ne pas copier directement le XML du dossier `XSD` de votre GNA** - il serait pris comme "source" et recomposé avec les `XSD_Source` des autres applications, entraînant des **duplications de lignes**. -#### Exemple — composition du fichier SOF02 +#### Exemple - composition du fichier SOF02 Le fichier final `C:\ProgramData\Mecalux\GnaService2015\XSD\SOF02.xsd` peut être composé de : @@ -66,7 +66,7 @@ Le fichier final `C:\ProgramData\Mecalux\GnaService2015\XSD\SOF02.xsd` peut êtr > ⚠️ Avec les nouvelles versions des scripts (GNA installé lors du deploy depuis le repository), le GNA **n'est plus installé au même endroit** qu'auparavant. Le script peut planter car il ne trouve pas les dossiers GNA. -**Solution** — modifier les chemins dans **`responses.xml`** du dossier `InstallApplications` : +**Solution** - modifier les chemins dans **`responses.xml`** du dossier `InstallApplications` : ```xml @@ -86,7 +86,7 @@ Récupérer le dossier GNA créé par le script et l'ajouter au GIT dans : \services\GNA ``` -Puis commit + push (cf. [git-workflow](git-workflow.md#3--commit-de-vos-modifications)). +Puis commit + push (cf. [git-workflow](git-workflow.md#3-commit-de-vos-modifications)). ### Réinstallation d'un GNA @@ -106,7 +106,7 @@ Procédure à suivre si le GNA a déjà été installé sur la VM et doit être ``` Choisir l'option **"complete"**. -> En cas d'erreur : voir Confluence *Installation GNA — Exécution de l'installation*. +> En cas d'erreur : voir Confluence *Installation GNA - Exécution de l'installation*. ## Service Label Printer @@ -140,11 +140,11 @@ La date de validité est mise à jour dans **EasySTS**. ## Règles pratiques -- **GIT commit du dossier `\services\GNA`** à chaque modification de script BOO — sinon les autres devs travaillent sur une version obsolète. -- **Ne jamais pousser le XML composé** de `XSD/` — uniquement les fichiers de `XSD_Source` (sinon duplications). +- **GIT commit du dossier `\services\GNA`** à chaque modification de script BOO - sinon les autres devs travaillent sur une version obsolète. +- **Ne jamais pousser le XML composé** de `XSD/` - uniquement les fichiers de `XSD_Source` (sinon duplications). - **Vérifier les chemins `responses.xml`** si le script d'export plante (nouvelle location `C:\Program Files\...`). -- **Toujours dézipper `InstallApplication.zip` frais** lors d'une réinstallation — ne pas réutiliser un dossier existant qui pourrait mélanger les versions. -- **Licence à renouveler avant expiration** — sinon WMS inutilisable sur la VM. +- **Toujours dézipper `InstallApplication.zip` frais** lors d'une réinstallation - ne pas réutiliser un dossier existant qui pourrait mélanger les versions. +- **Licence à renouveler avant expiration** - sinon WMS inutilisable sur la VM. ## Common errors @@ -157,8 +157,8 @@ La date de validité est mise à jour dans **EasySTS**. ## Related -- [System Architecture Overview](../architecture/overview.md) — architecture IIS / services WMS -- [ERP Interface](../concepts/erp-interface.md) — messages ERP portés par le GNA (ROR/SOR/SOF/STV/etc.) -- [First Deployment](first-deployment.md) — déploiement initial (GNA inclus dans `EnabledModules`) -- [Deploy Existing Application](deployment-existing-app.md) — redéploiement après mise à jour GNA -- [Git Workflow](git-workflow.md) — commit/push du dossier `\services\GNA` après modification de scripts BOO +- [System Architecture Overview](../architecture/overview.md) - architecture IIS / services WMS +- [ERP Interface](../concepts/erp-interface.md) - messages ERP portés par le GNA (ROR/SOR/SOF/STV/etc.) +- [First Deployment](first-deployment.md) - déploiement initial (GNA inclus dans `EnabledModules`) +- [Deploy Existing Application](deployment-existing-app.md) - redéploiement après mise à jour GNA +- [Git Workflow](git-workflow.md) - commit/push du dossier `\services\GNA` après modification de scripts BOO diff --git a/wiki/operations/robotics-project-lifecycle.md b/wiki/operations/robotics-project-lifecycle.md index 7041676..b2fdd1f 100644 --- a/wiki/operations/robotics-project-lifecycle.md +++ b/wiki/operations/robotics-project-lifecycle.md @@ -23,24 +23,24 @@ last_compiled: "2026-04-17" ## Overview -Robotics projects — installations with mechanized hardware (miniload, TK, conveyors, APS, AGV…) — require tighter coordination than pure-software projects because physical installation, electrical work and IT integration run in parallel. This page covers the organizational roles, reference documents, planning artifacts, and the station-test milestone that validates the WMS ↔ GALILEO configuration before go-live. +Robotics projects - installations with mechanized hardware (miniload, TK, conveyors, APS, AGV…) - require tighter coordination than pure-software projects because physical installation, electrical work and IT integration run in parallel. This page covers the organizational roles, reference documents, planning artifacts, and the station-test milestone that validates the WMS ↔ GALILEO configuration before go-live. ## 1. Project organization A robotics project pulls in multiple Mecalux stakeholders: -- **Chef de chantier** — site supervisor for the mechanical build -- **Chef de projet IT** — IT lead (WMS + automation integration) -- **Responsable électricité** — electrical lead -- **Responsable de projet** — master coordinator who aligns the above, owns the schedule, and guarantees everyone has the right information at the right time +- **Chef de chantier** - site supervisor for the mechanical build +- **Chef de projet IT** - IT lead (WMS + automation integration) +- **Responsable électricité** - electrical lead +- **Responsable de projet** - master coordinator who aligns the above, owns the schedule, and guarantees everyone has the right information at the right time The **Responsable de projet** is the single point of escalation; without them, gaps between disciplines (e.g. the rack is installed but the DTR has not been validated) lead to slippage. -> The canonical organisational diagram for a robotics project is on [Confluence — Organisation d'un projet Robotique](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000434425874). +> The canonical organisational diagram for a robotics project is on [Confluence - Organisation d'un projet Robotique](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000434425874). -## 2. DTR — Document Technique de Référence +## 2. DTR - Document Technique de Référence -The **DTR (Document Technique de Référence)** lists every technical element required for an automated installation — hardware, IP addresses, services, accounts — along with the **responsibility split between Mecalux and the client**. +The **DTR (Document Technique de Référence)** lists every technical element required for an automated installation - hardware, IP addresses, services, accounts - along with the **responsibility split between Mecalux and the client**. The DTR answers "who provides what and by when": - WMS server specs and OS @@ -49,23 +49,23 @@ The DTR answers "who provides what and by when": - Services (Active Directory, DNS, NTP, SMTP) - Physical access and ports opened between segments -The DTR template lives on [Confluence — DTR configuration réseau et matériel](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000562515980) as a table format. Fill a copy per project; track outstanding client deliverables in Jira. +The DTR template lives on [Confluence - DTR configuration réseau et matériel](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000562515980) as a table format. Fill a copy per project; track outstanding client deliverables in Jira. ## 3. Planning (Miniload installation) Two reference plannings used on every miniload project: -1. **Global installation planning** — overview of all phases (civil works → rack install → electrical → PLC commissioning → WMS integration → tests → go-live) -2. **IT ROB planning** — the slice owned by the IT Robotics team (VM install, WMS deploy, EasyS configuration, Gateway, station tests, Hypercare) +1. **Global installation planning** - overview of all phases (civil works → rack install → electrical → PLC commissioning → WMS integration → tests → go-live) +2. **IT ROB planning** - the slice owned by the IT Robotics team (VM install, WMS deploy, EasyS configuration, Gateway, station tests, Hypercare) -Both plannings live as Gantt images on [Confluence — Planning Installation Miniload](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000567955477). Copy the Gantt at project kick-off and adjust dates to site reality. +Both plannings live as Gantt images on [Confluence - Planning Installation Miniload](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000567955477). Copy the Gantt at project kick-off and adjust dates to site reality. ## 4. Reference documentation | Document | Purpose | Location | |----------|---------|----------| | **Control_Communications_Interface_EN_GB.pdf** | All station types, event types, PIE flags | [MSSCC Automation docs](https://msscc.mecalux.com/documentation/Automation/master/ES/Documents/GalileoAWS/Control_Communications_Interface_EN_GB.pdf) | -| **EasyWMSGateway_ControlInterface_EN.pdf** | Frame structure (low-level — used when a frame translation looks wrong) | [MSSCC services docs](https://msscc.mecalux.com/documentation/documentation/master/ES/docs_downloads/services/docs/EasyWMSGateway_ControlInterface_EN.pdf) | +| **EasyWMSGateway_ControlInterface_EN.pdf** | Frame structure (low-level - used when a frame translation looks wrong) | [MSSCC services docs](https://msscc.mecalux.com/documentation/documentation/master/ES/docs_downloads/services/docs/EasyWMSGateway_ControlInterface_EN.pdf) | | **Stations index** | Station-specific behaviours and quirks | [MSSCC Stations index](https://msscc.mecalux.com/documentation/documentation/master/EN/areas/layout/stations/index.md) | Use them as the source of truth when writing the functional spec / interface document with GALILEO. @@ -105,7 +105,7 @@ Context.StationRoutes.Where(sr => sr.Manager.ToString() == "Galileo") ? sr.StationTo.RealLocations.FirstOrDefault().LogicalCoordinate.Side : 0, AisleNumber = sr.StationTo.AisleNumber }) -// union with StationFrom — see full query on Confluence +// union with StationFrom - see full query on Confluence .OrderBy(sr => sr.StationType) .ThenBy(sr => sr.StationNumber) ``` @@ -128,22 +128,22 @@ Verify during simulation by temporarily saturating each route and confirming the Consolidated checklist merging what each phase must deliver: -- [ ] DTR signed by client and Mecalux (hardware, IPs, services provisioned) -- [ ] VM installed, joined to the domain, reachable via VPN (see [VM Installation](vm-installation.md) / [VM Network Routing](vm-network-routing.md)) -- [ ] EasyWMS deployed (see [First Deployment](first-deployment.md)) -- [ ] EasyS layout matches the execution plan (racks, stations, routes, PLC Types) -- [ ] Gateway installed, `tenantCode` + `TokenUser` configured, port 3000 open -- [ ] Station test query matches GALILEO `.mgp` station list -- [ ] PLC Container Type / PLC Height Type coupling validated in simulation -- [ ] "Full" route checks passed (CME→TE, PKE→PK, ET→PS) -- [ ] End-to-end flows validated in EasyS (PIE → Miniload → PK → PS) -- [ ] Reject route + floor virtual route configured (no lost container) -- [ ] Automation Dashboard wired up with the client's monitoring (see [Automation Dashboard](../modules/automation-dashboard.md)) +- ☐ DTR signed by client and Mecalux (hardware, IPs, services provisioned) +- ☐ VM installed, joined to the domain, reachable via VPN (see [VM Installation](vm-installation.md) / [VM Network Routing](vm-network-routing.md)) +- ☐ EasyWMS deployed (see [First Deployment](first-deployment.md)) +- ☐ EasyS layout matches the execution plan (racks, stations, routes, PLC Types) +- ☐ Gateway installed, `tenantCode` + `TokenUser` configured, port 3000 open +- ☐ Station test query matches GALILEO `.mgp` station list +- ☐ PLC Container Type / PLC Height Type coupling validated in simulation +- ☐ "Full" route checks passed (CME→TE, PKE→PK, ET→PS) +- ☐ End-to-end flows validated in EasyS (PIE → Miniload → PK → PS) +- ☐ Reject route + floor virtual route configured (no lost container) +- ☐ Automation Dashboard wired up with the client's monitoring (see [Automation Dashboard](../modules/automation-dashboard.md)) ## Related -- [GALILEO Integration](../architecture/galileo-integration.md) — protocol reference -- [Galileo Simulation](galileo-simulation.md) — EasyS bring-up, PIE injection, station sync -- [Galileo Troubleshooting](galileo-troubleshooting.md) — log analysis, faults +- [GALILEO Integration](../architecture/galileo-integration.md) - protocol reference +- [Galileo Simulation](galileo-simulation.md) - EasyS bring-up, PIE injection, station sync +- [Galileo Troubleshooting](galileo-troubleshooting.md) - log analysis, faults - [VM Installation](vm-installation.md) · [VM Network Routing](vm-network-routing.md) · [First Deployment](first-deployment.md) - [Mechanical Elements](../concepts/mechanical-elements.md) · [Stations & Routes](../concepts/stations.md) diff --git a/wiki/operations/ssh-keys-setup.md b/wiki/operations/ssh-keys-setup.md index 535f47d..dc61026 100644 --- a/wiki/operations/ssh-keys-setup.md +++ b/wiki/operations/ssh-keys-setup.md @@ -13,9 +13,9 @@ last_compiled: "2026-04-17" ## Overview -Procédure interne Mecalux EasyWMS France pour générer une **clé SSH ed25519**, l'enregistrer sur **MSSCODE** (le Gitea interne Mecalux) et la connecter à **Sourcetree**. Une fois en place, Sourcetree n'a plus à demander les identifiants MSSCODE à chaque opération Git — seul le mot de passe de la clé SSH est exigé à l'ouverture de Sourcetree. +Procédure interne Mecalux EasyWMS France pour générer une **clé SSH ed25519**, l'enregistrer sur **MSSCODE** (le Gitea interne Mecalux) et la connecter à **Sourcetree**. Une fois en place, Sourcetree n'a plus à demander les identifiants MSSCODE à chaque opération Git - seul le mot de passe de la clé SSH est exigé à l'ouverture de Sourcetree. -Source : Confluence EasyWMS France — *Configuration d'une clé SSH pour MSSCODE et Sourcetree* (v2, 28/01/2026). +Source : Confluence EasyWMS France - *Configuration d'une clé SSH pour MSSCODE et Sourcetree* (v2, 28/01/2026). ## 1. Génération de la clé SSH @@ -36,8 +36,8 @@ ssh-keygen -t ed25519 -C "your_email@example.com" > ⚠️ Le mot de passe de la clé est **unique et non modifiable**. En cas d'oubli, il faut **régénérer une nouvelle paire de clés**. Une clé sans mot de passe est techniquement possible mais **fortement déconseillée**. Deux fichiers sont créés dans `C:\Users\\.ssh\` : -- `id_ed25519` — clé **privée** (à ne jamais partager) -- `id_ed25519.pub` — clé **publique** (à enregistrer sur MSSCODE) +- `id_ed25519` - clé **privée** (à ne jamais partager) +- `id_ed25519.pub` - clé **publique** (à enregistrer sur MSSCODE) ## 2. Enregistrement de la clé sur MSSCODE @@ -87,5 +87,5 @@ Le lien SSH est exposé sur la page du dépôt MSSCODE (bouton "Code" / "Clone" ## Related -- [Git Workflow (Git Flow)](git-workflow.md) — opérations Git quotidiennes effectuées avec cette clé -- [Git Branch Lifecycle](git-branch-lifecycle.md) — cycle des branches Git par phase de projet +- [Git Workflow (Git Flow)](git-workflow.md) - opérations Git quotidiennes effectuées avec cette clé +- [Git Branch Lifecycle](git-branch-lifecycle.md) - cycle des branches Git par phase de projet diff --git a/wiki/operations/troubleshooting.md b/wiki/operations/troubleshooting.md index e66211b..f967a37 100644 --- a/wiki/operations/troubleshooting.md +++ b/wiki/operations/troubleshooting.md @@ -49,11 +49,11 @@ Organized by **symptom category**. Each entry: symptom → cause → solution. F - **Cause:** Order code unknown to WMS or ROR message not yet received from ERP. - **Solution:** Enable `ALLOW_CREATE_RECEPTION` to allow blind receipt creation; or have ERP resend the ROR message first. -### ASN container rejected at PIE — order doesn't exist +### ASN container rejected at PIE - order doesn't exist - **Cause:** The receipt order referenced in the ASN message has not yet arrived in WMS. - **Solution:** If `USE_EXCLUSIVE_RESERVE_STRICT_MODE` is inactive, container can still be received and the reserve is formalized later. If active, resolve the absent receipt order first before retrying PIE entry. -### Quantity discrepancy at PIE — container sent to reconditioning +### Quantity discrepancy at PIE - container sent to reconditioning - **Cause:** ASN pre-notified quantity doesn't match the received quantity, and the receipt order does not allow excess. - **Solution:** Correct the discrepancy at the reconditioning station, then retry induction into the PIE. @@ -79,7 +79,7 @@ Organized by **symptom category**. Each entry: symptom → cause → solution. F ### Transfer receipt order has no ASN - **Cause:** The source warehouse did not close the corresponding Transfer-type shipping order. -- **Solution:** Verify the source warehouse has closed the transfer shipping order — ASN is auto-generated at that point. +- **Solution:** Verify the source warehouse has closed the transfer shipping order - ASN is auto-generated at that point. ### Order stuck in "Receiving" status - **Cause:** Associated receipts are still open (not yet closed). @@ -97,11 +97,11 @@ Organized by **symptom category**. Each entry: symptom → cause → solution. F ## 2. Putaway -### No valid location found — manual warehouse +### No valid location found - manual warehouse - **Cause:** All strategies exhausted; no location meets the combination of criteria + restrictions + rules. Common causes: all eligible zones full, location type mismatch, strategy sequence incomplete. - **Solution:** Operator must manually select a destination. Review: strategy sequence coverage, restrictions not overly restrictive, no locations marked full or locked. -### No valid location found — automatic warehouse (rejection task generated) +### No valid location found - automatic warehouse (rejection task generated) - **Cause:** All aisles at the relocation percentage limit, no route from current station to any candidate, or weight limit exceeded everywhere. - **Solution:** Container is diverted to rejection station. Review aisle relocation configuration, available routes, and weight constraints. @@ -144,7 +144,7 @@ Organized by **symptom category**. Each entry: symptom → cause → solution. F - **Solution:** Check lock type configuration. If the reason for the lock is resolved, unlock the LPN and re-process using alternative stock. ### Cannot modify LPN type or division type -- **Cause:** LPN is not empty — still contains stock. +- **Cause:** LPN is not empty - still contains stock. - **Solution:** Pick out or move all stock from the LPN, then change the type. ### ASN LPN cannot be deleted @@ -175,7 +175,7 @@ Organized by **symptom category**. Each entry: symptom → cause → solution. F - **Cause:** Stock is prepared for a shipping order inside a client container. - **Solution:** Un-prepare the stock via Shipping management, then adjust. -### Adjustment fails — reason required +### Adjustment fails - reason required - **Cause:** No adjustment reason selected; none configured for the Adjustment capture process. - **Solution:** Create reasons in `Masters > Adjustment reasons`; select one before submitting the adjustment. @@ -195,7 +195,7 @@ Organized by **symptom category**. Each entry: symptom → cause → solution. F ## 5. Picking / Order Preparation -### Order line stays incomplete — no stock assigned +### Order line stays incomplete - no stock assigned - **Cause:** All stock assignment strategies exhausted without finding eligible stock. Typical causes: stock status blocks picking, count task active on the picking location, no PDL configured for item, extraction errors at candidate locations. - **Solution:** Check stock statuses, cancel any active count tasks on the location, verify PDL configuration, resolve extraction errors. @@ -267,7 +267,7 @@ Organized by **symptom category**. Each entry: symptom → cause → solution. F - **Cause:** WMS-ERP integration issue, or order was closed without an active ERP connection. - **Solution:** Check integration configuration; retry via forced resend if the functionality is available. -### Cannot cancel order — stock already prepared +### Cannot cancel order - stock already prepared - **Cause:** Picking tasks have been completed; stock is in a client container. - **Solution:** Undo preparation (un-prepare from the consolidation or truck loading view) before canceling. @@ -312,14 +312,14 @@ Organized by **symptom category**. Each entry: symptom → cause → solution. F ## 8. Count / Stock Adjustment ### Count order stuck in "Releasing" -- **Cause:** Automatic warehouse — containers are still moving at release time. +- **Cause:** Automatic warehouse - containers are still moving at release time. - **Solution:** Wait until all containers have reached a static location, then release the count order. -### Count line shows conflict icon — no stock +### Count line shows conflict icon - no stock - **Cause:** Item count line requested for an item with zero stock in the warehouse. - **Solution:** Use "Force Close" to finalize the line; review item master to understand the discrepancy. -### Count line shows conflict icon — location not configured for count +### Count line shows conflict icon - location not configured for count - **Cause:** Location does not have the "Allow count" flag enabled in EasyS. - **Solution:** Fix the location configuration in EasyS, or delete the problematic line. @@ -332,7 +332,7 @@ Organized by **symptom category**. Each entry: symptom → cause → solution. F - **Expected behavior:** Task distribution adjusts dynamically. Fine-tune schedule parameters if distribution is too uneven. ### Cannot re-release a cycle count after cancel -- **Cause:** By design — cycle count orders are non-re-releasable. +- **Cause:** By design - cycle count orders are non-re-releasable. - **Solution:** Create a new manual count for the affected locations. ### No adjustment reasons visible on RFT @@ -384,14 +384,14 @@ Organized by **symptom category**. Each entry: symptom → cause → solution. F - **Solution:** Assign different equipment; check equipment-container type compatibility configuration. ### Task cannot be manually completed -- **Cause:** Task type is picking, counting, stock replenishment, kit assembly, or consolidation — these must be completed through their respective process screens. +- **Cause:** Task type is picking, counting, stock replenishment, kit assembly, or consolidation - these must be completed through their respective process screens. - **Solution:** Complete via the appropriate screen (picking station, count screen, etc.). ### Movement stuck "In Execution" - **Cause:** Automatic warehouse malfunction or communication failure. - **Solution:** Use "Movement Release" to reset the movement back to Pending; investigate the automation incident. -### Task canceled — container not found at location +### Task canceled - container not found at location - **Cause:** Operator reported the wrong location at cancellation, or the container was moved without a system record. - **Solution:** Run a count on the expected location; use Lost & Found if needed. @@ -403,7 +403,7 @@ Organized by **symptom category**. Each entry: symptom → cause → solution. F ## 11. AGV & Pallet Shuttle -### AGV notification events — full error code table +### AGV notification events - full error code table | Code | Error | |------|-------| @@ -419,10 +419,10 @@ Organized by **symptom category**. Each entry: symptom → cause → solution. F | 2003 | Extraction error at non-storage location | | 2004 | Putaway error at non-storage location | | 2005 | Manual cancellation from AGV interface | -| 2500 | Communication error — sending order | -| 2501 | Communication error — priority update | -| 2502 | Communication error — cancellation | -| 2503 | Communication error — destination change | +| 2500 | Communication error - sending order | +| 2501 | Communication error - priority update | +| 2502 | Communication error - cancellation | +| 2503 | Communication error - destination change | ### AGV extraction error - **Behavior:** No container found at pickup location. @@ -448,7 +448,7 @@ Organized by **symptom category**. Each entry: symptom → cause → solution. F ### Pallet Shuttle low battery - **Behavior:** PS completes current tasks → returns to pickup position → disconnects → awaits AGV dispatch to charging station. If no charging station is available: user is notified. -### PS task in process — cannot be canceled +### PS task in process - cannot be canceled - **Cause:** AGV system is already involved in the movement. - **Note:** Only tasks in "Pending" state (waiting/pending shipping with CREATE action) can be canceled. Tasks in any other state must complete. @@ -556,11 +556,11 @@ Organized by **symptom category**. Each entry: symptom → cause → solution. F ## Related -- [Parameters](../concepts/parameters.md) — Full parameter reference; values controlling most behaviors above -- [ERP Interface](../concepts/erp-interface.md) — All ERP message types, fields, and error codes -- [Transactions](../concepts/transactions.md) — Transaction codes for audit trail investigation -- [Security](../architecture/security.md) — Role and permission configuration -- [System Architecture](../architecture/overview.md) — IIS pools, background jobs, infrastructure -- [Quality Control](../concepts/quality-control.md) — Stock status lock/unlock system -- [AGV](../modules/agv.md) — Full AGV error code reference -- [Pallet Shuttle](../modules/pallet-shuttle.md) — PS diagnostics and error handling +- [Parameters](../concepts/parameters.md) - Full parameter reference; values controlling most behaviors above +- [ERP Interface](../concepts/erp-interface.md) - All ERP message types, fields, and error codes +- [Transactions](../concepts/transactions.md) - Transaction codes for audit trail investigation +- [Security](../architecture/security.md) - Role and permission configuration +- [System Architecture](../architecture/overview.md) - IIS pools, background jobs, infrastructure +- [Quality Control](../concepts/quality-control.md) - Stock status lock/unlock system +- [AGV](../modules/agv.md) - Full AGV error code reference +- [Pallet Shuttle](../modules/pallet-shuttle.md) - PS diagnostics and error handling diff --git a/wiki/operations/ugna-data-export.md b/wiki/operations/ugna-data-export.md index 7f46429..ac27481 100644 --- a/wiki/operations/ugna-data-export.md +++ b/wiki/operations/ugna-data-export.md @@ -17,9 +17,9 @@ last_compiled: "2026-04-17" Procédure interne Mecalux EasyWMS France pour **exporter la configuration / les données du WMS** (paramètres, profils, master data, etc.) depuis une VM via **uGNA Console**, et les commiter dans le Git du projet (dossier `..\test`). -À exécuter **systématiquement** avant tout commit dès qu'une nouvelle configuration, transporteur, paramètre ou autre master data a été ajouté(e) ou modifié(e) sur la VM. C'est l'une des trois étapes pré-commit (avec l'export custom app et la sauvegarde GNA si BOO modifiés) listées dans [git-workflow](git-workflow.md#étape-préalable--exporter-les-modifications). +À exécuter **systématiquement** avant tout commit dès qu'une nouvelle configuration, transporteur, paramètre ou autre master data a été ajouté(e) ou modifié(e) sur la VM. C'est l'une des trois étapes pré-commit (avec l'export custom app et la sauvegarde GNA si BOO modifiés) listées dans [git-workflow](git-workflow.md#étape-préalable---exporter-les-modifications). -Source : Confluence EasyWMS France — *Export des données via uGNA* (v5, 18/10/2023). +Source : Confluence EasyWMS France - *Export des données via uGNA* (v5, 18/10/2023). ## ⚠️ Prérequis : VM à jour @@ -49,10 +49,10 @@ L'option `-Z:` accepte une liste séparée par virgules. La commande standard ci | Domaine | Entités | |---|---| -| Master data — Owners / Accounts | `owner`, `account`, `accounttype`, `company` | -| Master data — Items | `product`, `productfamily`, `productype`, `productlocation`, `alias`, `uom` | -| Master data — Suppliers / Carriers | `supplier`, `suppliertype`, `agency`, `deliveriescarrier`, `carrierselectionconfiguration` | -| Master data — Kits & Hazards | `kit`, `hazzardclass`, `divtype` | +| Master data - Owners / Accounts | `owner`, `account`, `accounttype`, `company` | +| Master data - Items | `product`, `productfamily`, `productype`, `productlocation`, `alias`, `uom` | +| Master data - Suppliers / Carriers | `supplier`, `suppliertype`, `agency`, `deliveriescarrier`, `carrierselectionconfiguration` | +| Master data - Kits & Hazards | `kit`, `hazzardclass`, `divtype` | | Profils | `logisticprofile`, `receptionprofile`, `putawayprofile`, `shippingprofile`, `cuttingprofile`, `countprofiles` | | Stratégies | `putawaystrategy`, `putawayrestriction`, `replenishmentstrategy`, `stockassignstrategy`, `stockassignstrategyV2`, `ShippingProfileAssignmentStrategy`, `stockclassificationbyzone` | | Classes & ABC | `inboundclass`, `outboundclass`, `abc` | @@ -83,7 +83,7 @@ Si l'export échoue avec une erreur d'écriture sur `C:\Program Files (x86)\Meca ## Related -- [Git Workflow (Git Flow)](git-workflow.md) — étape pré-commit "export uGNA" -- [GNA, Services & License](gna-services-license.md) — sauvegarde des fichiers BOO du GNA (`GNAGetDataForGit.ps1`), processus distinct de l'export uGNA -- [First Deployment](first-deployment.md) — l'arborescence `..\test` est consommée à la première installation (`Data: test/`) -- [Deploy Existing Application](deployment-existing-app.md) — les exports uGNA sont rechargés à chaque redéploiement +- [Git Workflow (Git Flow)](git-workflow.md) - étape pré-commit "export uGNA" +- [GNA, Services & License](gna-services-license.md) - sauvegarde des fichiers BOO du GNA (`GNAGetDataForGit.ps1`), processus distinct de l'export uGNA +- [First Deployment](first-deployment.md) - l'arborescence `..\test` est consommée à la première installation (`Data: test/`) +- [Deploy Existing Application](deployment-existing-app.md) - les exports uGNA sont rechargés à chaque redéploiement diff --git a/wiki/operations/vm-installation.md b/wiki/operations/vm-installation.md index e902f12..183fc8f 100644 --- a/wiki/operations/vm-installation.md +++ b/wiki/operations/vm-installation.md @@ -25,7 +25,7 @@ La VM sert de cible de déploiement pour : - La **custom application** du projet (via EasyBuilder) - Les services adjacents (GNA, Printer Service, EasySTS License, SmartUI, etc.) -Sources : Confluence EasyWMS France — *Installation de la VM sur Hyper-V* (v30, 02/12/2025) + *Valider sa machine virtuelle* (v7, 14/02/2023). +Sources : Confluence EasyWMS France - *Installation de la VM sur Hyper-V* (v30, 02/12/2025) + *Valider sa machine virtuelle* (v7, 14/02/2023). ## Prérequis @@ -78,7 +78,7 @@ La convention `DEV-` évite les interconnexions non désirées entre VM - IP : `10.255.255.2` - Masque : `255.255.255.0` - Passerelle : `10.255.255.1` -4. **Advanced → DNS** — saisir les 4 serveurs DNS Mecalux : +4. **Advanced → DNS** - saisir les 4 serveurs DNS Mecalux : - `192.168.0.102` - `192.168.0.104` - `192.168.0.56` @@ -88,7 +88,7 @@ La convention `DEV-` évite les interconnexions non désirées entre VM ## 5. Renommer la VM (Windows) 1. **Paramètres Windows → System → About** (en bas du volet gauche) -2. **"Rename this PC"** — saisir le nom de la VM +2. **"Rename this PC"** - saisir le nom de la VM > ⚠️ **Avant redémarrage**, mettre à jour les fichiers Oracle suivants (remplacer `localhost` par le nouveau nom) : > - `tnsnames.ora` @@ -106,13 +106,13 @@ La convention `DEV-` évite les interconnexions non désirées entre VM Avant le premier point de contrôle, installer ce qui est nécessaire : -- **Git** (obligatoire) — vérifier avec `git --version` ; à défaut : [git-scm.com/download/win](https://git-scm.com/download/win) +- **Git** (obligatoire) - vérifier avec `git --version` ; à défaut : [git-scm.com/download/win](https://git-scm.com/download/win) - Éditeurs personnels (Sublime Text, VSCode, Notepad++…) - SourceTree si absent du template (voir [git-workflow](git-workflow.md)) ## 7. Point de contrôle "Deploy 0" -Créer un point de contrôle **"Deploy 0"** — c'est le snapshot de référence à partir duquel un nouveau projet pourra être déployé (cf. [first-deployment](first-deployment.md)). +Créer un point de contrôle **"Deploy 0"** - c'est le snapshot de référence à partir duquel un nouveau projet pourra être déployé (cf. [first-deployment](first-deployment.md)). Entre deux projets, on applique ce point de contrôle pour repartir d'une VM propre. @@ -123,7 +123,7 @@ Après le premier déploiement d'un projet sur la VM (cf. [first-deployment](fir ### 1. Vérifier les services et IIS 1. Service Windows **MongoDB** démarré (sinon : démarrer) -2. **IIS Manager** — pour chacune des applications ci-dessous, `Browse` doit ouvrir la page sans erreur : +2. **IIS Manager** - pour chacune des applications ci-dessous, `Browse` doit ouvrir la page sans erreur : - **`AD`** (Application Dictionary API) - **`ApplicationService`** - **`EasySTS`** (License) @@ -163,8 +163,8 @@ Si la connexion à **consoleRF** boucle sur l'input du nom d'utilisateur : ## Related -- [System Architecture Overview](../architecture/overview.md) — stack IIS/ASP.NET Core/Oracle/PostgreSQL déployée sur la VM -- [First Deployment](first-deployment.md) — déploiement initial d'un projet sur une VM fraîchement créée -- [Deploy Existing Application](deployment-existing-app.md) — redéploiement sur VM déjà préparée -- [GNA, Services & License](gna-services-license.md) — installation des services adjacents (GNA, Printer, License WMS) -- [Development Methodology](development-methodology.md) — méthode de travail et stratégie de branches autour de la VM +- [System Architecture Overview](../architecture/overview.md) - stack IIS/ASP.NET Core/Oracle/PostgreSQL déployée sur la VM +- [First Deployment](first-deployment.md) - déploiement initial d'un projet sur une VM fraîchement créée +- [Deploy Existing Application](deployment-existing-app.md) - redéploiement sur VM déjà préparée +- [GNA, Services & License](gna-services-license.md) - installation des services adjacents (GNA, Printer, License WMS) +- [Development Methodology](development-methodology.md) - méthode de travail et stratégie de branches autour de la VM diff --git a/wiki/operations/vm-network-routing.md b/wiki/operations/vm-network-routing.md index 583f2ca..8a382bb 100644 --- a/wiki/operations/vm-network-routing.md +++ b/wiki/operations/vm-network-routing.md @@ -20,7 +20,7 @@ Cette page décrit : - Les modes d'accès (localhost depuis la VM, IP depuis un autre poste) - Les passerelles VPN à utiliser depuis une délégation Europe -Source : Confluence EasyWMS France — *Routage vers les VM* (v7, 11/08/2023). +Source : Confluence EasyWMS France - *Routage vers les VM* (v7, 11/08/2023). ## 1. Tableau de correspondance NAT @@ -32,7 +32,7 @@ Source : Confluence EasyWMS France — *Routage vers les VM* (v7, 11/08/2023). | Oracle | 1521 | **15210** | 15211 | | SMB | 445 | **4450** | 4451 | -> Toute requête TCP reçue sur le PC hôte sur le port **8080** est redirigée vers **10.255.255.2:80** (l'IP fixe de la VM, cf. [vm-installation](vm-installation.md#configuration-réseau-ipv4)). Le port externe n°2 sert quand on doit faire tourner **deux VMs en parallèle** sur le même hôte. +> Toute requête TCP reçue sur le PC hôte sur le port **8080** est redirigée vers **10.255.255.2:80** (l'IP fixe de la VM, cf. [vm-installation](vm-installation.md#4-configuration-réseau-dans-la-vm-locale)). Le port externe n°2 sert quand on doit faire tourner **deux VMs en parallèle** sur le même hôte. ### Commandes Windows utiles @@ -50,21 +50,21 @@ Depuis l'intérieur de la VM, on utilise **`localhost`** + port interne, ou dire | EasyBuilder en HTTPS | `localhost:4430` | | SmartUI via DNS | `https:///smartui/` | -> Note : `4430` est le port externe NAT — depuis la VM, accéder via `localhost:443` fonctionne aussi pour HTTPS interne. La doc Confluence donne `localhost:4430` car la VM peut être interrogée via la machine hôte qui résout le NAT. +> Note : `4430` est le port externe NAT - depuis la VM, accéder via `localhost:443` fonctionne aussi pour HTTPS interne. La doc Confluence donne `localhost:4430` car la VM peut être interrogée via la machine hôte qui résout le NAT. ## 3. Accès **depuis un autre PC** -`localhost` et le **DNS de la VM** ne sont **pas accessibles** depuis un autre poste — il faut utiliser l'**IP du PC hôte** suivie du port externe NAT. +`localhost` et le **DNS de la VM** ne sont **pas accessibles** depuis un autre poste - il faut utiliser l'**IP du PC hôte** suivie du port externe NAT. ### Récupérer son IP -**Option A — Paramètres Windows :** +**Option A - Paramètres Windows :** 1. Clic droit sur l'icône réseau dans la barre des tâches 2. **"Ouvrir les paramètres réseau et Internet"** 3. **"Propriétés"** de l'adaptateur Ethernet 4. Récupérer l'**adresse IPv4** -**Option B — PowerShell :** +**Option B - PowerShell :** ```powershell ipconfig ``` @@ -79,7 +79,7 @@ Récupérer l'**IPv4** de l'adaptateur Ethernet. | SmartUI | `192.168.164.214:4430/smartui` | | Bureau à distance (RDP) | `192.168.164.214:33890` | -> Pour que SmartUI s'affiche correctement depuis le PC hôte, il faut aussi avoir vidé `defaultURL` dans `SmartUI\script\config.js` (cf. [vm-installation — Validation](vm-installation.md#validation-de-la-vm)). +> Pour que SmartUI s'affiche correctement depuis le PC hôte, il faut aussi avoir vidé `defaultURL` dans `SmartUI\script\config.js` (cf. [vm-installation - Validation](vm-installation.md#validation-de-la-vm)). ## 4. Utilisation avec le VPN Mecalux @@ -113,5 +113,5 @@ No Hyper-V NAT connectivity ## Related -- [VM Installation (Hyper-V) & Validation](vm-installation.md) — création de la VM, IP fixe `10.255.255.2`, commutateur InternoNAT -- [Deploy Test Application](deploy-test-application.md) — déploiement d'une livraison sur la VM de test (utilise ces accès réseau) +- [VM Installation (Hyper-V) & Validation](vm-installation.md) - création de la VM, IP fixe `10.255.255.2`, commutateur InternoNAT +- [Deploy Test Application](deploy-test-application.md) - déploiement d'une livraison sur la VM de test (utilise ces accès réseau)