What is WMS? — Orbita Knowledge Base

Definition

Orbita WMS is an optional module for tenants who require scan-led warehouse discipline. It owns operational inventory — quantities and locations as physically executed — not customer selling price, margin, AR/AP ledgers, or order intake authority.

WMS splits into two paired surfaces:

Desk Monitor — browser queues and monitors at /wms/*: receive, inbound control, exception disposition, rack registry, ledger, variance.
Floor Execution (PWA) — scan-primary mobile paths at /scan/*: receive intake, putaway, pick, transfer — wedge/camera driven, not soft-keyboard order entry.

Core WMS concepts:

Receive queue — PO-driven intake monitor; distinct from inbound header lifecycle authority.
Inbound control — document/header lifecycle and putaway readiness.
Rack map / slots — visual and registry authority for location occupancy.
Movement ledger — qty mutations over time; not the same as operational audit feed (events) or exception disposition.
Inventory variance — commercial vs warehouse reconciliation at balance views.
Trace report — barcode/lot DNA chain resolve.

WMS enforces FIFO timestamps on qualifying inbound paths, pallet profile caps, slot occupancy rules, and scan validation before progression. Wrong SKU, wrong location, or blocked slot states halt execution rather than deferring correction to month-end.

Product identity creation in Office does not silently create inbound stock or receive queue rows — inbound intent is explicit. This prevents ghost warehouse state from catalog edits alone.

Within Orbita, WMS occupies the warehouse segment of the provable execution chain and is essential evidence for stock-to-books alignment when physical execution risk is material.

Physical truth phase enforcement includes pallet profile caps (layers, cartons per layer, weight), rack zone class, slot mode, and destination occupancy validation. Preview palletization may recommend split loads; hard stops occur when profile or slot rules would create unsafe or ambiguous floor state.

Barcode governance maps tokens to SKU/lot context; trace report resolves DNA chains for investigations. Overview search may be an entry point — trace report remains the authoritative resolve surface for barcode/lot chain questions.

Purpose

WMS exists because commercial order truth and physical warehouse truth diverge by default unless execution is verified. Spreadsheets, honor-system picks, and post-hoc adjustments produce silent drift — finance discovers mismatch at invoice or audit time when causality is already lost.

Operational purposes:

Wrong-pick prevention — scan checkpoints bind SKU, batch, location, and quantity before ship.
Location truth — rack slots reflect occupancy; putaway cannot ignore occupied destinations where enforced.
Movement auditability — ledger history explains qty changes with attributable events.
Variance visibility — Office commercial qty vs WMS qty exposed for reconciliation, not hidden.
Exception disposition — inbound exceptions resolved at authority surface, not duplicated on audit feeds.

WMS does not exist to display commercial pricing or customer credit. Role boundary governance keeps WMS physical-only on catalog operator surfaces; finance and selling semantics stay in Office/Finance modules.

For distributors with chilled lines, batch/expiry metadata paths follow fetch-validate-execute: check existing batch/expiry from server state before prompting operators — redundant popups when data already exists are anti-patterns WMS design avoids.

Scan-primary flows avoid soft-keyboard sinks: wedge and camera listeners use readonly intake patterns so floor operators are not asked to type SKUs while holding cartons. Success and error feedback use timed auto-dismiss with manual escape — reducing stuck full-screen states during high-throughput shifts.

Test and smoke identifiers are filtered from default operator reads so certification harness rows do not pollute live queues, rack maps, or KPI denominators. Advanced audit toggles may include test data explicitly — default is operational truth only.

Workflow

1. Inbound intent

Supplier PO or inbound header creates receive expectation. Receive desk monitors queue; floor executes scan intake.

2. Receive execution

Carton/pallet scans validate against PO lines and product rules. Caps (e.g. cumulative carton limits) enforced server and client. SHORT_CLOSED and supplier semantics follow frozen receive lifecycle.

3. Putaway

Staging lines move to rack slots with recommendation/validation. Closed header with remaining staging may allow balance-only putaway when virtual lines exist — avoiding deadlock when document state and floor state diverge.

4. Storage and FIFO

Inbound timestamps preserve FIFO layers for pick allocation. Rack map shows occupant truth; slot inspector resolves conflicts.

5. Pick and ship

Pick scans commit against delivery demand. Hero/ladder flows stage scan steps — type resolution before downstream scan when required. Success feedback auto-resets; errors dismiss with operator escape.

6. Exceptions

Reject buffer floor paths link to exception control for disposition — one authority, not parallel “exception centers.”

7. Reconciliation

Balance workspace compares commercial vs warehouse qty. Finance consumes operational consequence — WMS does not post AP/AR.

8. Inbound extension timeline

Inventory inbound stages (first qualifying scan, putaway complete) extend unified timeline vocabulary for warehouse causal analysis. Segment duration metrics for putaway wait are computed in services — UI and Atlas read precomputed thresholds, they do not re-derive averages locally.

Supplier receive semantics include SHORT_CLOSED and partial receive policies aligned with finance GRNI consequence — operational close states must not fork from procurement bridge expectations documented in finance governance.

Example

Scenario: FMCG warehouse with 12 racks and mixed-SKU pallet loads.

PO arrives; receive desk shows eligible lines; floor scan intake validates SKU and carton count.
Putaway recommends slot from zone class and pallet profile; occupied slot returns destination error — operator chooses alternate.
FIFO layer timestamp recorded at inbound.
Order release generates pick demand; pick hero scans cartons; ratio math applies on mixed loads.
Mismatch scan aborts ship path; exception visible on desk monitor — not corrected in Excel.
Ledger shows movement chain; balance view flags 2-unit variance vs commercial inventory; bridge investigated before invoice.

Without WMS: Same company updates commercial inventory manually after pick. Chain evidence weakens — stock-to-books alignment relies on human discipline; disputes lack scan-grade proof.

Exception episode: Inbound carton rejected at floor; reject buffer execution links to exception control disposition. Audit feed shows the event timeline in human sentences — disposition happens at authority surface, not by editing audit rows.

Pallet recycle: When a pallet is emptied in defined flows, product binding clears for reuse — stale product scope on empty containers is a physical-truth defect that causes wrong picks on the next load.

FAQ

Is WMS required for Orbita?: No. Optional when floor scan evidence and location discipline are needed.
What is Desk Monitor vs Floor Execution?: Desk = queue/monitor/approve in browser. Floor = PWA scan execution. Both are labeled consistently — not duplicate authorities.
Does WMS show customer prices?: No on default operator surfaces. Commercial pricing is Office authority.
What is Inventory Variance?: Reconciliation between commercial inventory and warehouse operational qty — not a second warehouse.
Can Atlas run putaway?: No. Atlas observes; operators execute scans through WMS handlers.
What is Exception Control vs Audit Feed?: Exception Control disposes inbound exceptions. Audit Feed is read-only event visibility — different meanings, different surfaces.
Does creating a product auto-stock the warehouse?: No. Product identity does not create inbound/receive rows without explicit inbound intent.

Misconceptions

“WMS inventory page equals Office inventory.” False. Warehouse Inventory and Commercial Inventory are distinct; variance explains gaps.

“Audit log is where I close exceptions.” False. Disposition belongs to Exception Control; audit is read-only feed.

“Any scan success means shipment is correct.” False. Validation is contextual — SKU, batch, order line, and caps must align.

“WMS replaces FAOS orders.” False. WMS executes physical legs; orders and commercial context remain FAOS authority.

“Rack map is decorative.” False. It is visual authority paired with registry and slot enforcement rules.

“Movement ledger equals audit feed.” False. Ledger tracks qty mutations; audit feed tracks operator/system events — different semantics.

When It Matters

WMS matters when pick error cost, batch traceability, or location complexity exceed training-only mitigation — multi-SKU pallets, FEFO/FIFO lines, rack enforcement, and high daily scan volume. It matters less for pure trading desks that outsource physical handling without owned warehouse execution.

Enable WMS when leadership asks “prove what left the building” — not merely “show a stock number.”

WMS also matters during supplier disputes and internal shrink investigations: movement ledger plus trace report provide attributable history — generic inventory adjustments without movement rows are alignment red flags. Operators trained only on commercial inventory screens without floor discipline will see variance grow until scan enforcement is adopted.

Hero scan flows enforce staged navigation (scan RA → type resolution → scan RB) so shortcuts cannot skip validation steps that prevent wrong-type picks. Cooldown and same-code guards reduce double-scan accidents during high-speed shifts without blocking legitimate different-token scans.

Mixed-load carts with ratio math must stay on one pipeline — splitting state across duplicate UIs creates phantom qty, undermines pick integrity, and breaks assorted-carton shipment accountability.

Cumulative carton caps on receive intake are enforced in both client and server paths — raising limits in one layer without the other is a certification defect.