Developing a Dropshipping Schema with Suppliers on 1C-Bitrix

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 an 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:

1. 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;
}

2. Email with an HTML table — when the supplier has no API. Email template via CEvent::Send, event DROPSHIPPING_ORDER_NEW. Table of line items, delivery address, transfer amount.

3. 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:

• 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_product after 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

Timelines

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 an 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.