Custom 1C-Bitrix Warehouse Management Module Development

When an online store on 1C-Bitrix works with multiple warehouses, the standard catalog module quickly falls short?

Typical pain points: an item exists in the database but is already reserved by another order – up to 15% of orders are lost due to overselling; managers manually track transfers; integration with 1C overwrites reservations. We have encountered this dozens of times: for example, a store with three warehouses in different cities lost up to 15% of orders due to the lack of a reservation mechanism. The solution is a custom warehouse management module that processes orders 3 times faster than standard accounting. Over the past years, we have implemented over 50 such modules integrated with 1C:UT, YooKassa, ATOL, and CDEK. Contact us for a consultation – we will tell you how to reduce losses.

Why standard functionality is insufficient?

The standard catalog module stores the total quantity of goods in a warehouse but does not distinguish between physical and available stock. There is no mechanism for reservation against a specific order, and no ability to set a warehouse priority for shipment. Inter-warehouse transfers are not recorded with history. According to 1C-Bitrix documentation (https://dev.1c-bitrix.ru/), the OnSaleOrderSaved event allows intercepting an order save – this is the key entry point for our reservation logic. Our solution with a separate reservation table surpasses standard accounting by 3 times in order processing speed.

How we extend the data schema?

The module adds two main tables: b_catalog_store_reservation and b_catalog_store_movement.

How does reservation work at order placement?

When an order is created, goods are reserved at the warehouse via the OnSaleOrderSaved event handler. The process consists of several steps:

1. When the order is saved, the OnSaleOrderSaved event fires.
2. For each item, the source warehouse is determined according to the selected strategy.
3. A record is created in the b_catalog_store_reservation table with the quantity and order ID.
4. When the order is paid or canceled, the reservation is automatically released (RELEASED_AT is filled).

\Bitrix\Main\EventManager::getInstance()->addEventHandler( 'sale', 'OnSaleOrderSaved', [ReservationService::class, 'onOrderSaved'] ); 

This schema ensures that two different orders cannot get the same product.

How to choose a warehouse for shipment?

The warehouse selection strategy is configured in the module settings:

• FIFO – older stock is shipped first (by receipt date).
• Nearest warehouse – based on customer geolocation (requires coordinates).
• Warehouse priority – uses the SORT field (lower = higher priority).
• Minimum stock – empties warehouses with the smallest stock.

If one warehouse does not have enough stock, the system automatically splits the shipment across multiple warehouses. This prevents order cancellations due to shortages at a single warehouse.

Calculation of available stock

Available stock = physical stock minus active reservations:

public static function getAvailable(int $storeId, int $productId): float { $physical = \Bitrix\Catalog\StoreProductTable::getList([ 'filter' => ['=STORE_ID' => $storeId, '=PRODUCT_ID' => $productId], 'select' => ['AMOUNT'], ])->fetch()['AMOUNT'] ?? 0; $reserved = \Bitrix\Main\Application::getConnection()->query( "SELECT COALESCE(SUM(QUANTITY), 0) as RES FROM b_catalog_store_reservation WHERE STORE_ID = {$storeId} AND PRODUCT_ID = {$productId} AND RELEASED_AT IS NULL" )->fetch()['RES'] ?? 0; return max(0, (float)$physical - (float)$reserved); } 

On the product card and in the cart, the available stock is displayed. This eliminates the situation where a customer buys a product that is no longer in reserve.

Administrative interface

Three sections are added to the admin panel:

• Stocks by warehouse – matrix of product × warehouse with physical and available stock, filtering by category and warehouse.
• Transfers – creating a transfer document, confirming receipt at the destination warehouse.
• Reservations – list of active reservations with the ability to manually release.

Integration with 1C

During integration via standard exchange (/bitrix/admin/1c_exchange.php), stock from the module is synchronized with b_catalog_store_product via the OnSuccessCatalogImport1C event handler. Reservations are not overwritten: stock from 1C is treated as physical, and available stock is recalculated automatically.

Development timelines

What is included in the work

• Module development with API and configuration documentation.
• Source code with comments, unit tests.
• Integration setup with 1C, payment gateways, and shipping companies.
• Administrator training.
• Post-project support: 6-month warranty from the delivery date.

Our expertise

Over 10 years of development experience, more than 50 projects for stores with various logistics. Certified specialists in the 1C-Bitrix platform. We guarantee adherence to deadlines and transparency of work. Savings from overselling can reach 15% of turnover. Contact us for a consultation – we will discuss your project without obligation.

Additional information about inventory management methods is available on Wikipedia: FIFO, inventory management.