Multi-Warehouse Order Consolidation in 1C-Bitrix

Imagine: an online store with three warehouses – Moscow, Saint Petersburg, Yekaterinburg. A customer orders three items, each from a different warehouse. Without consolidation, the system will send three parcels with triple delivery costs. The customer is unhappy, the margin drops. We solve this pro

Our competencies:

Frequently Asked Questions

Imagine: an online store with three warehouses – Moscow, Saint Petersburg, Yekaterinburg. A customer orders three items, each from a different warehouse. Without consolidation, the system will send three parcels with triple delivery costs. The customer is unhappy, the margin drops. We solve this problem with custom logic on Bitrix. Over 10+ years, we have implemented more than 50 projects in warehouse logistics, and our solution stably works under loads of up to 10,000 orders per day. At the same time, delivery costs for customers are reduced by an average of 30%, and one client saved 1.2 million rubles in a year due to smart distribution.

Why doesn't Bitrix consolidate orders by default?

The standard "Warehouses" module in 1C-Bitrix stores inventories in b_catalog_store_product and reservations in b_sale_reserve_quantity, but does not provide a mechanism for automatically selecting a warehouse when placing an order. The developer must manually write the distribution logic. We use \Bitrix\Catalog\StoreProductTable::getList() with a filter by PRODUCT_ID and the condition AMOUNT > 0 to get available balances. Then we select a warehouse according to the strategy set in the settings. We take into account not only availability, but also distance to the client, delivery cost, and warehouse load.

Consolidation strategies: comparison

Strategy Order execution speed Number of parcels Delivery costs
Maximum speed High (immediate shipping) Many (per warehouse) High
Minimum number of parcels Low (waiting for assembly) One Low (single delivery)
Hybrid Medium Optimal 40% lower than maximum

Strategy 1: Maximum speed – each item is shipped from the nearest warehouse immediately upon availability. The customer receives multiple parcels. Implementation: upon order creation, an agent immediately splits it into sub-orders by warehouse.

Strategy 2: Minimum number of parcels – wait for the entire order to be assembled at one "main" warehouse, where the required items are moved. Implementation: inter-warehouse transfer via b_catalog_store_document with type M.

Strategy 3: Hybrid – ship available items immediately, wait for backorders. Optimal balance between speed and delivery cost. The hybrid strategy reduces the number of parcels by 2–3 times compared to maximum speed, while keeping delivery time acceptable. According to our data, the hybrid strategy is 40% more cost-effective in terms of logistics.

How do we split an order into sub-orders?

We create the bl_order_shipments table with fields order_id, store_id, status, items_json. Upon order confirmation, the agent analyzes the basket:

foreach ($basket as $item) { $stores = StoreProductTable::getList([ 'filter' => ['PRODUCT_ID' => $item->getProductId(), '>AMOUNT' => 0], 'order' => ['AMOUNT' => 'DESC'], ])->fetchAll(); $bestStore = $stores[0]['STORE_ID'] ?? $defaultStoreId; $shipments[$bestStore][] = [ 'product_id' => $item->getProductId(), 'quantity' => $item->getQuantity(), ]; } 

Each group is written into bl_order_shipments. Sub-order statuses are tracked independently. When a warehouse document changes (e.g., shipment), the agent updates the status of the corresponding sub-order.

The warehouse selection logic is configured via b_option: for each product, you can set a priority – first stocks at the warehouse, then backorder items. If the warehouse has insufficient stock, we look at others. If none – we set pending. This allows changing the strategy without programmer intervention.

Display to the client: logistics transparency

In the personal account and order email, we show the breakdown: Parcel 1 (Moscow warehouse): 2 items – shipped, Parcel 2 (SPb warehouse): 1 item – in transit. The personal account component retrieves data from bl_order_shipments and merges them with the main order via order_id. This increases trust and reduces support inquiries.

Work process: stages and timelines

Stage Duration Result
Warehouse scheme audit 1–2 days Analytical note
Strategy design 1–2 days Technical specification
Development of agents and tables 2–5 days Working code
Testing 1–2 days Test report
Deployment and documentation 1 day Instructions and training

What's included in the work?

  • Audit of your current warehouse scheme and stock levels
  • Design of a consolidation strategy tailored to your business
  • Development of the bl_order_shipments table and distribution agents
  • Strategy configuration via b_option (switchable without a programmer)
  • Implementation of sub-order display in the personal account and admin panel
  • Integration with 1C via CommerceML for synchronization of stocks and shipments
  • Documentation for the modification and training for your managers
  • Six months of free support warranty on the code

Deadlines and cost

Deadlines – from 5 to 14 business days, depending on the number of warehouses and integration complexity. Cost is calculated individually after an audit. Get a turnkey solution: we will analyze your workflow and suggest the optimal consolidation strategy. Contact our specialists – we work with all configurations of Bitrix and guarantee results. Order an audit of your current warehouse scheme – it's free and non-binding.