Developing a Dropshipping Schema with Suppliers on 1C-Bitrix
When processing orders manually with 10 suppliers, up to 15% errors occur — lost orders, duplicates, incorrect stock levels. Scaling to 50 suppliers makes the process unmanageable. We have designed over 30 dropshipping schemas on 1C-Bitrix that process up to 5,000 orders per day without manual intervention. The key challenges are real-time stock synchronization and correct routing with multiple suppliers. Off-the-shelf modules cannot handle these tasks. A poorly designed schema breaks when adding a second supplier or when volume exceeds 100 orders per day. Our experience: 7+ years in Bitrix development and 30+ projects. We guarantee correct routing and timely stock syncing. Contact us for a free assessment of your project — we will analyze your current infrastructure and prepare a solution.
Why Standard Modules Are Not Suitable for Dropshipping?
Ready-made modules often offer simple supplier substitution but ignore complex routing, multiple stock sources, and rejection automation. We have to design a custom data model and handlers adaptable to any supplier.
Data Model for Linking Products and Suppliers
The central question: how to link a product to a supplier and store data for order routing.
The product information block (b_iblock_element, b_iblock_element_property) stores retail data: name, description, images, properties. We leave that untouched.
HL-block Supplier — supplier directory:
b_uts_supplier (auto-generated table of the HL-block)
- ID
- UF_NAME — supplier name
- UF_EMAIL — email for notifications
- UF_WEBHOOK_URL — URL for POST notifications
- UF_API_KEY — API key for supplier access
- UF_FEED_URL — URL of the stock feed (XML/CSV/JSON)
- UF_FEED_FORMAT — feed format
- UF_LEAD_TIME — order processing time (days)
- UF_ACTIVE — active flag
HL-block SupplierProduct — link between products and suppliers:
b_uts_supplier_product
- ID
- UF_PRODUCT_ID — ID of the info-block element (
b_iblock_element.ID) - UF_SUPPLIER_ID — ID of the supplier (
b_uts_supplier.ID) - UF_SUPPLIER_SKU — supplier's SKU
- UF_PURCHASE_PRICE — purchase price
- UF_CURRENCY — purchase currency
- UF_STORE_ID — supplier's warehouse (
b_catalog_store.ID) - UF_MIN_QUANTITY — minimum order quantity
- UF_IS_PRIMARY — primary supplier (if multiple)
Warehouses (b_catalog_store) — one per supplier. Stock in b_catalog_store_product. This is the standard Bitrix mechanism, no need to reinvent the wheel.
How to Design Order Routing?
The router's task: when an order is created, split the cart, group items by supplier, and transmit each part to the respective supplier. The complication: one product may have multiple suppliers. We need selection logic: by price, availability, priority. We implement this via UF_IS_PRIMARY combined with current stock check.
namespace Local\Dropshipping;
use Bitrix\Highloadblock\HighloadBlockTable;
use Bitrix\Main\Application;
class SupplierResolver
{
/**
* Returns the best supplier for a product:
* first the primary supplier with stock > 0, otherwise any with stock
*/
public static function resolve(int $productId, int $quantity): ?array
{
$conn = Application::getConnection();
// Find suppliers with sufficient stock
$result = $conn->query("
SELECT sp.UF_SUPPLIER_ID, sp.UF_SUPPLIER_SKU, sp.UF_PURCHASE_PRICE,
sp.UF_IS_PRIMARY, csp.AMOUNT
FROM b_uts_supplier_product sp
JOIN b_catalog_store_product csp
ON csp.PRODUCT_ID = sp.UF_PRODUCT_ID
AND csp.STORE_ID = sp.UF_STORE_ID
WHERE sp.UF_PRODUCT_ID = {$productId}
AND csp.AMOUNT >= {$quantity}
ORDER BY sp.UF_IS_PRIMARY DESC, sp.UF_PURCHASE_PRICE ASC
LIMIT 1
");
return $result->fetch() ?: null;
}
}
Transmitting the Order to the Supplier
Three transmission channels, in order of preference:
- Webhook (REST API of the supplier) — the best option. We POST a JSON with order data to the supplier's URL, and they respond with confirmation:
private static function sendWebhook(string $url, string $apiKey, array $payload): bool
{
$http = new \Bitrix\Main\Web\HttpClient();
$http->setHeader('Content-Type', 'application/json');
$http->setHeader('Authorization', 'Bearer ' . $apiKey);
$http->setTimeout(10);
$response = $http->post($url, json_encode($payload));
$status = $http->getStatus();
\Bitrix\Main\Diag\Debug::writeToFile(
['url' => $url, 'status' => $status, 'response' => $response],
'Dropshipping webhook',
'/local/logs/dropshipping.log'
);
return $status === 200;
}
-
Email with an HTML table — when the supplier has no API. Email template via
CEvent::Send, eventDROPSHIPPING_ORDER_NEW. Table of line items, delivery address, transfer amount. -
File exchange via FTP/SFTP — for suppliers working with 1C. We generate XML in CommerceML format and place it on the supplier's FTP. They pick it up on schedule.
Stock Synchronization
Stock becomes outdated quickly — the main challenge of any dropshipping schema. Three strategies:
| Strategy | Description | Latency | Supplier Requirements |
|---|---|---|---|
| Push from supplier | Webhook when stock changes | Minutes | API with callback |
| Pull on schedule | Agent downloads feed every N minutes | 15-30 min | Feed (XML/CSV/JSON) |
| Reservation | Reduce stock at order creation | Instant | None |
- Push from supplier — the supplier notifies us via webhook on stock change. We implement an endpoint with API key validation.
- Pull on schedule — a Bitrix agent downloads the supplier's feed every 30 minutes and updates stock. Feeds come in XML (1C format), CSV, JSON.
-
Reservation — if pull is impossible, we decrease stock in
b_catalog_store_productafter order creation. Not precise but better than nothing.
Margin Calculation
Purchase price is stored in UF_PURCHASE_PRICE of the HL-block. Retail price is in b_catalog_price. The difference is the margin. A margin report can be queried directly from the database:
SELECT
be.NAME AS product_name,
cp.PRICE AS retail_price,
sp.UF_PURCHASE_PRICE AS purchase_price,
cp.PRICE - sp.UF_PURCHASE_PRICE AS margin_abs,
ROUND((cp.PRICE - sp.UF_PURCHASE_PRICE)
/ cp.PRICE * 100, 1) AS margin_pct
FROM b_iblock_element be
JOIN b_catalog_price cp ON cp.PRODUCT_ID = be.ID AND cp.CATALOG_GROUP_ID = 1
JOIN b_uts_supplier_product sp ON sp.UF_PRODUCT_ID = be.ID AND sp.UF_IS_PRIMARY = 1
WHERE be.IBLOCK_ID = :catalog_iblock_id
AND be.ACTIVE = 'Y'
ORDER BY margin_pct ASC;
How Are Supplier Rejections Handled?
A supplier may reject an order (out of stock, address error). We need a status HL-block for tracking:
b_uts_supplier_order
- UF_ORDER_ID — Bitrix order ID (
b_sale_order.ID) - UF_SUPPLIER_ID — supplier ID
- UF_STATUS — pending / confirmed / rejected / shipped / delivered
- UF_SUPPLIER_ORDER — order number at the supplier
- UF_TRACKING — tracking number
- UF_REJECT_REASON — rejection reason
- UF_DATE_UPDATE — last update date
On status rejected, an agent notifies the manager and, if an alternative supplier for the same product exists, automatically redirects the order.
Step-by-Step Setup of Dropshipping
How to implement the schema in 5 steps (expand)
- Audit — analyze the current catalog, integrations, number of suppliers, and order volume (average 500-1000 orders per day).
- Model design — create HL-blocks Supplier and SupplierProduct, set up warehouses for each supplier.
- Router development — write the logic for selecting a supplier by priority and stock.
- Transmission channel integration — webhooks, email, or FTP depending on supplier capabilities.
- Testing and launch — load test with 1000+ orders, monitor for a week.
Timelines
| Configuration | Components | Duration |
|---|---|---|
| Single supplier, email notifications | HL-blocks + handler + template | 1–2 weeks |
| Multiple suppliers, webhooks | + router + sync API | 3–4 weeks |
| Full schema with feeds, cabinet, and analytics | + pull feeds + supplier portal + margin report | 6–8 weeks |
What Is Included in the Result
- Data model (HL-blocks Supplier and SupplierProduct) with fields tailored to your suppliers.
- Order router supporting N suppliers with priority-based selection.
- Integration with suppliers: webhooks, email, or FTP — individually for each.
- Near-real-time stock synchronization.
- Rejection handling with automatic redirection to an alternative supplier.
- Architecture documentation and an operations manual.
- Manager training (2 hours) and technical support for 30 days.
Contact us for a free assessment of your task. We will analyze the number of suppliers, order volumes, and existing infrastructure. Order the development of a turnkey dropshipping schema — get a reliable solution that won't break as your business grows.