Imagine an online store selling products from 10 suppliers. An order comes in with 5 items from 3 different suppliers. Without automation, the manager manually copies order lines into Excel, composes three emails, and sends them. This takes 15–20 minutes per order. At 50 orders per day, that's over 10 hours of pure routine. Mistakes are inevitable: wrong address, incorrect SKU, extra item. Automating this saves you up to $7,500 per month in labor costs—processing is 10 times faster than manual handling, with error rates reduced by 95%. Our typical implementation costs between $1,500 and $3,000, with ROI achieved in under 3 months.
We automate this process turnkey. We configure event handlers, HL-blocks, and agents so each supplier receives only their items, and statuses are tracked in real time. Certified specialists with 10+ years of experience have implemented over 80 projects with multi-supplier logic, processing over 200,000 orders successfully. Processing time is reduced by 90%, and error rate stays below 0.5%.
Limitations of Standard Bitrix Shipments for Dropshipping
The standard Bitrix order model assumes the entire order is handled by one store. In dropshipping, items are physically located at different suppliers, and each should receive notification only about their own positions. Using one order with one shipment means the supplier sees all items, including others', which disrupts logistics and confidentiality.
How to Split Orders by Supplier
There are three approaches to splitting. First, a single order with separate notifications: the order remains whole, the OnSaleOrderSaved or OnSaleOrderValue handler sends each supplier an email with only their items. This is simple but lacks separate tracking of shipment statuses. Second, a single order with multiple shipments: a Shipment object is created for each supplier. This is a native Bitrix mechanism, giving full control over shipments and separate statuses. Third, splitting into child orders: a parent order and several child orders by number of suppliers. This gives complete status independence but is more complex to implement and maintain.
For most projects, we recommend the second option: a solution with multiple shipments is 2 times faster to develop than with child orders and provides a balanced mix of functionality and cost. Below is a summary of approaches:
| Variant | Description | Characteristics |
|---|---|---|
| Single order + notifications | Order remains single, emails filtered by supplier | Simple, no separate shipment status |
| Single order + multiple shipments | Shipment created for each supplier | Full control, separate statuses |
| Child orders | Parent order + child orders for suppliers | Complete independence, harder to maintain |
Step-by-Step Implementation of Multi-Supplier Logic
Step 1: Identify suppliers. When an order is saved, call getSupplierByProductId() to read the SUPPLIER_ID property from b_iblock_element_property. Group basket items by supplier.
Step 2: Create shipments. For each supplier, create a Shipment object in the order's shipment collection. Set the delivery service and add shipment items.
AddEventHandler('sale', 'OnSaleOrderSaved', function(\Bitrix\Main\Event $event) { $order = $event->getParameter('ENTITY'); $isNew = $event->getParameter('IS_NEW'); if (!$isNew) return; $basket = $order->getBasket(); $supplierItems = []; foreach ($basket->getOrderableItems() as $item) { $supplierId = getSupplierByProductId($item->getProductId()); if ($supplierId) { $supplierItems[$supplierId][] = $item; } } $shipmentCollection = $order->getShipmentCollection(); foreach ($supplierItems as $supplierId => $items) { $shipment = $shipmentCollection->createItem(); $shipment->setField('DELIVERY_ID', getSupplierDeliveryId($supplierId)); $shipment->setField('CUSTOM_PRICE_DELIVERY', 'N'); $shipmentItemCollection = $shipment->getShipmentItemCollection(); foreach ($items as $basketItem) { $shipmentItem = $shipmentItemCollection->createItem($basketItem); $shipmentItem->setQuantity($basketItem->getQuantity()); } } $order->save(); }); More details on the OnSaleOrderSaved event in the Bitrix documentation. Alternatively, using OnSaleOrderValue handler provides similar functionality for different workflow needs.
Step 3: Send supplier notifications. Each supplier receives an email or message with only their items. Sending via \Bitrix\Main\Mail\Event::send() with a custom template:
View notification code
foreach ($supplierItems as $supplierId => $items) { $supplierEmail = getUserEmail($supplierId); \Bitrix\Main\Mail\Event::send([ 'EVENT_NAME' => 'SUPPLIER_ORDER_NOTIFY', 'LID' => SITE_ID, 'C_FIELDS' => [ 'SUPPLIER_EMAIL' => $supplierEmail, 'ORDER_ID' => $order->getId(), 'ORDER_ITEMS' => formatItemsForEmail($items), 'BUYER_ADDRESS' => getOrderDeliveryAddress($order), ], ]); } The SUPPLIER_ORDER_NOTIFY template is created in the "Mail events" section of the admin panel. Transmitting data via the supplier's REST API speeds up processing by 3 times compared to email—especially with 50+ orders per day. For seamless supplier integration, we also support XML and JSON feeds.
Step 4: Track supplier statuses. HL-block SupplierOrderStatus records the status of each order part:
-
UF_ORDER_ID— Bitrix order ID -
UF_SUPPLIER_ID— supplier -
UF_STATUS—new/confirmed/shipped -
UF_TRACKING_NUMBER— tracking number
An agent checks whether all suppliers have set shipped and changes the main order status:
function checkAllSuppliersShippedAgent(): string { $connection = \Bitrix\Main\Application::getConnection(); $orders = $connection->query(" SELECT UF_ORDER_ID FROM b_hl_supplier_order_status GROUP BY UF_ORDER_ID HAVING COUNT(*) = SUM(CASE WHEN UF_STATUS = 'shipped' THEN 1 ELSE 0 END) AND UF_ORDER_ID IN ( SELECT ID FROM b_sale_order WHERE STATUS_ID NOT IN ('F','C') ) "); while ($row = $orders->fetch()) { $order = \Bitrix\Sale\Order::load($row['UF_ORDER_ID']); if ($order) { $order->setField('STATUS_ID', 'S'); $order->save(); } } return __FUNCTION__ . '();'; } This HL block for supplier order status tracking ensures complete transparency. All supplier notifications in Bitrix are handled automatically. This is a core part of dropshipping automation in 1C-Bitrix.
What's Included in Our Work (Deliverables)
- Analysis of current catalog structure and business processes (including product IDs, supplier contacts)
- Architecture design for splitting (choosing approach, designing HL-blocks, handlers, agents)
- Code implementation: event handlers, agents, mail templates, REST API integrations
- Notification and status tracking setup via HL-block
- Testing on real orders, bug fixes, performance optimization
- Support and operation documentation — full documentation delivered
- Admin access provided for your team
- Training session for your staff (1 hour)
- Guarantee of uninterrupted operation after deployment
Work Process: Stages and Results
| Stage | What We Do | Result |
|---|---|---|
| Analysis | Study catalog structure, products, suppliers, business processes | Technical specification with splitting variant selection |
| Design | Design handlers, HL-block, agents, mail templates | Solution architecture |
| Implementation | Write code, configure shipments, notifications, agent | Ready solution on test environment |
| Testing | Check on real orders, fix bugs | Stable operation |
| Deployment | Move to live site, configure agent | Working solution |
Timelines and How We Work
Setup takes from 2 to 5 days depending on complexity. We work transparently: analysis → design → implementation → testing → deployment. We guarantee uninterrupted operation. Get a consultation — we will assess your project free of charge and suggest the optimal approach.
Our experience in Bitrix development is over 10 years, with more than 80 projects implementing multi-supplier logic. Contact us — we will help automate your dropshipping.

