Multi-DC ERPNext retailers and distributors hit the same wall: a Sales Order defaults to a single set warehouse, so fulfillment teams manually decide where to ship from, split lines by hand, and discover backorders only after the Delivery Note fails. ERPNext core gives you per-warehouse Bin stock and a default warehouse on the Item and Warehouse Setup, but it has no engine that weighs live availability, customer proximity, and shipping cost together to pick the cheapest, fastest source per order line. The result is over-shipping from distant DCs, split orders that could have been consolidated, stranded stock in the wrong region, and margin quietly bleeding into freight.

We build a proper Frappe app (installed via bench get-app / bench install-app) that adds an allocation engine on top of your existing ERPNext data — no fork, no core patching. At its heart is a whitelisted server-side method that computes real-time available-to-promise per warehouse by reading Bin.actual_qty net of reserved and in-transit quantities, then scores each candidate warehouse against configurable weights for proximity (warehouse-to-shipping-address distance via geocodes or a zone matrix), fulfillment cost, and stock-health rules you define. A new Allocation Rule DocType and a per-order Allocation Plan child table make the logic transparent and auditable: planners see exactly why line 3 was sourced from the East DC and split across two warehouses, and can override before submission.

The engine binds to ERPNext through hooks.py document events — typically on_submit/validate on Sales Order — so allocation runs automatically at the moment orders are confirmed, and a scheduler_events hourly job re-evaluates open backorders as replenishment lands. When a single warehouse cannot fulfill a line, split-shipment logic generates multiple Delivery Note drafts by source; when nothing is available, backorder and partial-allocation rules apply per your policy. Inventory-balancing suggestions surface as draft Stock Entry (Material Transfer) records that rebalance stock toward demand. Client Scripts add the planner UI — a ship-from picker and a "why this warehouse" explainer on the Sales Order form — and everything is exposed over the Frappe REST API and whitelisted methods so your storefront, OMS, or 3PL can call allocation headlessly. Access is governed by ERPNext Role Profiles and DocType permissions, so only allocation planners can edit rules while sales users see read-only plans.

Because this is build-to-order, nothing ships as a generic download. We start with a scoping call to map your warehouse network, cost model, proximity data, and split/backorder policies, then build and configure the app against Frappe/ERPNext v15 or v16, validate it on a staging copy of your site through UAT, and deploy with a documented rollback path. Typical delivery is one working week from confirmed scope. You receive the full source, the git repository, technical and user documentation, a training session for your planners, and a post-go-live support window.