Warehouse Management Software Development

Engineering teams building Warehouse Management Systems for 3PLs, distribution centres, or e-commerce fulfilment operations deal with a set of operational data problems that compound at scale: put-away task assignment that must minimise travel while respecting location constraints, pick wave optimisation across hundreds of concurrent orders, short-pick handling that does not hold up an entire wave, and task interleaving that uses worker deadhead time for productive work. Scrums.com builds dedicated teams for your WMS domain: engineers who design location management schemas, wave optimisation algorithms, task dispatch engines, and carrier integration layers. Every architecture decision is made to serve software companies building fulfilment infrastructure, not the consumer placing a single order.

Receiving, Put-Away, and Location Management Architecture

Warehouse locations are the foundational reference table. A warehouse_locations table stores every bin: zone, aisle, bay, level, bin label, location type (RECEIVING, STORAGE, PICK, BULK, STAGING, SHIPPING), capacity in units, capacity in kilograms, and current utilisation. Location type constrains what operations can reference each location: picks can only draw from PICK and STORAGE locations; put-away targets can include BULK and STORAGE but not SHIPPING. This constraint lives in configuration, not application code, so warehouse operators can restructure zones without a deployment.

Inbound shipments generate an ASN (Advanced Shipping Notice) with expected items and quantities. When a shipment arrives, the receiving workflow proceeds: dock assignment, carton or pallet scan, item scan with quantity, optional quality check, and put-away task generation. Each step writes to a receiving_events append-only log. Put-away tasks reference a source location (RECEIVING dock) and a target location determined by the slotting algorithm: fast-moving SKUs are slotted to pick faces near packing stations, heavy items are placed at floor level, and frequently co-picked items are slotted adjacent to each other. Slotting rules are stored in a slotting_config table and evaluated at task generation time rather than hardcoded.

Location inventory is a materialised view derived from a warehouse_movements append-only table: every put-away, pick, replenishment, and transfer writes a movement row. Current stock per location per item per lot is always derived from this ledger, never from a mutable quantity field. This means location audit trails are complete, historical location states are reconstructable, and discrepancies between expected and actual are investigated through the movement log.

Pick, Pack, and Ship Operations

Pick waves batch multiple orders together for efficient picking. A waves table holds orders included, pick method (SINGLE, BATCH, ZONE, CLUSTER), and status. Within a wave, pick tasks are sequenced by location to minimise travel distance: a nearest-neighbour heuristic for standard operations, an OR-Tools VRP solver for high-volume operations with complex aisle layouts. Each pick_task records wave ID, order ID, item ID, lot ID, pick-from location, required quantity, and is assigned to a picker via the task dispatcher. Actual quantity picked is recorded on completion; any short pick (actual quantity less than required) generates a short_pick_event that triggers either a re-pick from an alternative location or a backorder creation against the order line.

Packing tasks receive the picked items for an order, apply cartonisation logic (box type recommended from pre-configured box_types based on item dimensions and weights), record final weight and dimensions, and generate a shipping label. Carrier rate shopping runs at label generation: rates are fetched from configured carriers via EasyPost or direct APIs, and the cheapest qualifying service level is selected, or overridden by a customer-account-level preference stored in account_shipping_rules. The tracking number and label URL are written to the shipping_tasks record and pushed back to the OMS.

Warehouse management systems like these are built and delivered by dedicated engineering teams through our mobile app development service.

Task Interleaving and Labour Management

Deadhead travel (a worker moving empty-handed between tasks) is the primary source of lost productivity in a warehouse. Task interleaving reduces it by dispatching the most productive available task near the worker's current location when they complete their current task, regardless of task type. When a picker completes a pick task, the task dispatcher queries the task_pool for OPEN tasks within a configurable proximity radius, ranked by priority and estimated travel time. A nearby put-away or replenishment task is often dispatched instead of sending the worker back to the start of the next pick wave.

The task pool is a single table covering all task types: PUT_AWAY, PICK, REPLENISHMENT, CYCLE_COUNT, and TRANSFER. Each task carries task type, priority, location ID, estimated duration, and status (OPEN, ASSIGNED, IN_PROGRESS, COMPLETE). Worker sessions record start, end, tasks completed, lines picked, and error count. A productivity_kpis materialised view computes lines picked per hour, error rate, and tasks completed per shift (per worker, per zone, per shift), refreshed at shift end for supervisor review.

Labour standards are defined in a labour_standards table: engineered time in minutes per task type. Variance from standard, measured as (actual time minus standard time) divided by standard time, is computed per worker per task type over a rolling period. Workers whose variance exceeds a configurable threshold surface in the labour management dashboard for coaching or re-training review. Replenishment triggers fire automatically when a pick face (PICK location) reaches minimum quantity threshold, creating a replenishment task to pull stock from the bulk reserve before a picker arrives at an empty location.

Integrations, Returns Processing, and Warehouse Analytics

OMS integration drives the fulfilment lifecycle. Inbound orders from the OMS create fulfilment_orders in the WMS; status updates (PICKED, PACKED, SHIPPED) are pushed back via webhook on each task completion. The OMS never needs to poll for status: every state change in the WMS triggers an outbound event. ERP integration publishes stock journal entries from warehouse movements and goods receipt confirmations that match to purchase order receipts in the ERP. An integration_log records every inbound and outbound message with status and retry count.

Returns processing starts with a Return Authorisation (RA) that pre-registers the expected return before the item arrives. When the item is scanned at the receiving dock, the returns inspection workflow runs: condition assessment drives a disposition decision from a typed enum (RESTOCK, QUARANTINE, DISCARD, RETURN_TO_VENDOR). Restocked items write warehouse movements and immediately update location inventory. Quarantined items create a quality_hold record and are moved to a quarantine location; they are excluded from available stock until the hold is resolved.

Warehouse analytics are built as materialised views over append-only event tables. The warehouse_kpis view computes: orders shipped per day, on-time shipment rate, pick accuracy rate (correct items and quantities on first pick), receiving cycle time (dock arrival to put-away completion), dock-to-stock hours, and space utilisation by zone. These KPIs refresh nightly and are available via API for BI dashboards. No KPI logic lives in application code: the views are the single source of definition for each metric.