Разработка схемы дропшиппинга с поставщиками 1С-Битрикс

Разработка схемы дропшиппинга с поставщиками 1С-Битрикс

Дропшиппинг на Битрикс — это не готовый модуль, а архитектурное решение. Неправильно спроектированная схема ломается при добавлении второго поставщика или при росте объёма до 100+ заказов в день. Правильно спроектированная работает при 50 поставщиках и тысяче заказов в сутки без ручного вмешательства.

Модель данных

Центральный вопрос: как связать товар с поставщиком, и как хранить данные для маршрутизации заказов.

Инфоблок товаров (b_iblock_element, b_iblock_element_property) хранит розничные данные: название, описание, изображения, характеристики. Это не трогаем.

HL-блок Supplier — справочник поставщиков:

b_uts_supplier (автогенерированная таблица HL-блока)
├── ID
├── UF_NAME          — название поставщика
├── UF_EMAIL         — email для уведомлений
├── UF_WEBHOOK_URL   — URL для POST-уведомлений
├── UF_API_KEY       — ключ доступа к API поставщика
├── UF_FEED_URL      — URL фида остатков (XML/CSV/JSON)
├── UF_FEED_FORMAT   — формат фида
├── UF_LEAD_TIME     — срок обработки заказа (дней)
└── UF_ACTIVE        — активность

HL-блок SupplierProduct — связь товаров и поставщиков:

b_uts_supplier_product
├── ID
├── UF_PRODUCT_ID       — ID элемента инфоблока (b_iblock_element.ID)
├── UF_SUPPLIER_ID      — ID поставщика (b_uts_supplier.ID)
├── UF_SUPPLIER_SKU     — артикул поставщика
├── UF_PURCHASE_PRICE   — закупочная цена
├── UF_CURRENCY         — валюта закупки
├── UF_STORE_ID         — склад поставщика (b_catalog_store.ID)
├── UF_MIN_QUANTITY     — минимальная партия
└── UF_IS_PRIMARY       — основной поставщик (если несколько)

Склады (b_catalog_store) — по одному на каждого поставщика. Остатки — в b_catalog_store_product. Это стандартный механизм Битрикс, не изобретаем велосипед.

Маршрутизация заказов

Задача маршрутизатора: при создании заказа разобрать корзину, сгруппировать позиции по поставщикам, передать каждому поставщику его часть.

Усложнение — один товар может иметь несколько поставщиков. Нужна логика выбора: по цене, по наличию, по приоритету. Реализуется через UF_IS_PRIMARY плюс проверка текущего остатка.

namespace Local\Dropshipping;

use Bitrix\Highloadblock\HighloadBlockTable;
use Bitrix\Main\Application;

class SupplierResolver
{
    /**
     * Возвращает лучшего поставщика для товара:
     * сначала основного с остатком > 0, иначе любого с остатком
     */
    public static function resolve(int $productId, int $quantity): ?array
    {
        $conn = Application::getConnection();

        // Находим поставщиков, у которых достаточно остатка
        $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;
    }
}

Передача заказа поставщику

Три канала передачи, в порядке предпочтительности:

1. Вебхук (REST API поставщика) — лучший вариант. Мы POST-им JSON с данными заказа на URL поставщика, он отвечает подтверждением:

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 с HTML-таблицей — когда поставщик не имеет API. Шаблон письма через CEvent::Send, событие DROPSHIPPING_ORDER_NEW. Таблица позиций, адрес доставки, сумма к перечислению.

3. Файловый обмен через FTP/SFTP — для поставщиков, работающих с 1С. Генерируем XML в формате CommerceML и кладём на FTP поставщика. Он забирает по расписанию.

Синхронизация остатков

Остатки устаревают быстро — проблема всей дропшиппинг-схемы. Три стратегии:

Push от поставщика — поставщик сам уведомляет об изменении остатка через вебхук. Реализуем эндпоинт:

// /local/ajax/supplier/update-stock.php
$apiKey    = $_SERVER['HTTP_X_API_KEY'] ?? '';
$supplierId = SupplierAuth::validateKey($apiKey);

if (!$supplierId) {
    http_response_code(403);
    die(json_encode(['error' => 'Unauthorized']));
}

$items = json_decode(file_get_contents('php://input'), true)['items'] ?? [];

foreach ($items as $item) {
    $productId = SupplierProduct::findBySupplierSku($supplierId, $item['sku']);
    if ($productId) {
        StockUpdater::updateSupplierStock($productId, $supplierId, (int)$item['quantity']);
    }
}

echo json_encode(['updated' => count($items)]);

Pull по расписанию — агент Битрикс каждые 30 минут скачивает фид поставщика и обновляет остатки. Фиды бывают XML (1С-формат), CSV, JSON.

Резервирование — если pull невозможен, после создания заказа сразу уменьшаем остаток на складе поставщика в b_catalog_store_product. Некорректно, но лучше ничего.

Расчёт маржи

Закупочная цена хранится в UF_PURCHASE_PRICE HL-блока. Розничная цена — в b_catalog_price. Разница — маржа. Отчёт по марже запрашивается прямо к базе:

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;

Обработка отказов поставщика

Поставщик может отклонить заказ (нет в наличии, ошибка адреса). Нужен статусный HL-блок для отслеживания:

b_uts_supplier_order
├── UF_ORDER_ID        — ID заказа Битрикс (b_sale_order.ID)
├── UF_SUPPLIER_ID     — ID поставщика
├── UF_STATUS          — pending / confirmed / rejected / shipped / delivered
├── UF_SUPPLIER_ORDER  — номер заказа у поставщика
├── UF_TRACKING        — трек-номер отправления
├── UF_REJECT_REASON   — причина отказа
└── UF_DATE_UPDATE     — дата последнего изменения

При статусе rejected запускается агент, который уведомляет менеджера и, если есть альтернативный поставщик того же товара, автоматически перенаправляет заказ.

Сроки реализации