Most businesses running ERPNext eventually hit the same wall: the ERP is excellent at Items, Purchase Orders, Sales Orders, BOMs and Accounting – but it doesn’t answer the question a warehouse supervisor asks fifty times a day: “Where, physically, is this stock right now and who is moving it?”
That gap is usually filled with spreadsheets, WhatsApp messages to the floor and manual reconciliation at month-end. The fix isn’t a bigger ERP – it’s a dedicated execution layer that owns the physical journey of stock while ERPNext stays the system of record.
Why a Separate Execution Layer
ERPNext knows what was ordered and what should be in stock. It doesn’t model the physical journey in between – receiving, putaway, picking, packing, dispatch. A WMS layer hooks into two ERPNext events – a submitted Purchase Receipt and a submitted Sales Order – and takes over from there.
Benefits of this separation:
- No fragile customizations on core ERPNext doctypes
- Clean upgrade path, since ERPNext internals stay untouched
- A dedicated data model for locations, tasks and scans
- Independent scaling of warehouse operations logic
A Location Hierarchy Built for Putaway Logic
Physical space is modeled as a six-level hierarchy, from facility down to bin, with capacity, pick-face flag and allowed item groups tracked at the lowest level.
- Warehouse → Zone → Rack → Level → Section → Bin
- Occupancy tracked per bin
- Allowed item groups per bin
- Foundation for a future live floor-plan view
One Function Every Stock Movement Must Pass Through
No stock movement happens in isolation. Receiving, putaway, picking, packing, dispatch, transfer and cycle-count correction all pass through a single function.
- Requires item, quantity, operator, timestamp and reference document
- Updates live stock balance
- Writes an audit log row every time
- No exceptions for “quick fixes”
The Automation Engine: “Everything Must Be Linked”
No stock movement happens in isolation. Every stock-affecting action – receiving, putaway, picking, packing, dispatch, transfer, cycle-count correction – passes through one function, which logs the item, quantity, operator, timestamp and reference document and updates the audit trail every time.
On top of that sits an automation chain that mirrors how a warehouse actually runs:
- QC is conditional — routed only when required; a failed inspection rejects the receipt instead of letting bad stock in
- Reservation happens before picking — stock is earmarked the moment a Sales Order is submitted, not during the pick
- Pack and Dispatch chain automatically — each triggers the next step without anyone needing to remember it
- The system watches itself — pick-face levels checked every 30 minutes, SLA breaches every 15
Exceptions and Variances as First-Class Data
Barcodes/QR code get scanned wrong, counts don’t match, bins run empty. These are modeled directly rather than patched around:
- Mismatched scans block the transaction and log an exception
- Cycle count mismatches raise a Stock Variance and an Approval
- Approved variances auto-correct the stock balance
- Nothing is fixed without a trail
Beyond the Core Flow
- Batch and lot traceability with recall status down to bin-level quarantine quantity
- Return-to-Vendor documents generated from failed QC inspections
- Labor logs measured against defined productivity standards
- Carton specifications for future pack-to-box matching
- RFID/IoT tag tracking fields ready for hardware integration
How This Approach Scales
The design keeps a single automation chain – receive, inspect, putaway, reserve, pick, pack, dispatch — as the backbone, while leaving clear extension points for what comes next.
Key focus areas:
- Six-level location hierarchy with bin-level capacity and occupancy
- Single audited stock-movement function with no bypass path
- Conditional QC routing with automatic RTV generation
- Exception, variance and approval doctypes for reconciliation
- Batch/lot traceability with recall support
- Labor standards and productivity variance tracking
- Mobile scan-driven interface for floor operations
- Extension points for pick-path optimization, slotting and live device integration
What’s Left for Later
Pick-path optimization, wave/slotting, a full visual warehouse map, manufacturing/WIP integration and live carrier or device connections are out of scope for v1 the data model already supports them, but the drivers and optimization logic come later.
How SwayAlgo Approaches Warehouse Technology
At SwayAlgo, technology starts with the operational problem, not a feature list. For warehouse environments, that means understanding how inventory actually moves, where information gets lost and where disconnected processes create friction before a single line of code gets written.
The result isn’t just another app. It’s a more connected way of operating.
Conclusion
A warehouse doesn’t need a bigger ERP. It needs one function every movement passes through, one audit trail with no gaps and an automation chain that mirrors how the floor actually works. The next step for any rollout is the same discipline applied elsewhere: a functional-spec pass per module, a permission matrix per role and a phased go-live.
