Розробка multi-vendor маркетплейсу на 1С-Бітрікс

Розробка multi-vendor маркетплейса на 1С-Бітрікс

З коробки 1С-Бітрікс — це інструмент для одного продавця. Перетворити його на маркетплейс, де сотні незалежних продавців управляють своїми товарами, замовленнями та виплатами — завдання, яке потребує серйозної архітектурної надбудови. Готових рішень класу «нажми кнопку й отримай Wildberries» не існує. Є кілька модулів від сторонніх розробників, які беруть на себе частину роботи, та кастомна розробка поверх них.

Що потрібно побудувати

Multi-vendor маркетплейс відрізняється від звичайного інтернет-магазину кількома принциповими речами:

Ізоляція даних продавців. Продавець A не повинен бачити товари, замовлення та аналітику продавця B. У базовому Бітрікс інфоблоки та каталог — спільні. Потрібно додати шар розмежування: або окремий інфоблок на кожного продавця (масштабується погано), або спільний інфоблок із полем VENDOR_ID та фільтрацією на всіх рівнях.

Незалежне управління. У кожного продавця — особистий кабінет для управління своїми товарами, замовленнями, цінами. Це не стандартний /personal/ Бітрікс, а кастомний розділ з кастомними компонентами.

Розділення замовлень. Покупець кладе в корзину товари від трьох продавців. У Бітрікс це одне замовлення в b_sale_order. Потрібно розбивати його на суб-замовлення, кожне з яких бачить тільки відповідний продавець.

Комісії та виплати. Платформа бере комісію з кожної продажі. Потрібен розрахунок комісій за правилами та механізм виплат продавцям (вручну або автоматично через API платежів).

Архітектура зберігання даних продавців

Найпрактичніший підхід — додати ідентифікатор продавця на рівні інфоблока каталогу. Продавець реєструється як користувач Бітрікс у групі «Продавці», його USER_ID використовується як VENDOR_ID.

Структура зберігання товарів:

Основний інфоблок каталогу розширюється UF-полем UF_VENDOR_ID (посилання на b_user.ID). Усі компоненти каталогу при виборці додають фільтр по UF_VENDOR_ID. У особистому кабінеті продавця — тільки елементи з його UF_VENDOR_ID.

Альтернатива для великих маркетплейсів: HighLoad-інфоблок як проміжний шар, який зберігає маппінг PRODUCT_ID → VENDOR_ID та використовується для швидких перевірок прав.

Таблиця продавців (додаткова, через HL-інфоблок або кастомну):

Розділення замовлень

Це найтехнічно складна частина. У b_sale_order замовлення єдине. Варіанти реалізації розділення:

Варіант 1: Суб-замовлення як дочірні записи. Створюється додаткова таблиця mp_sub_orders з полями ORDER_ID, VENDOR_ID, STATUS, TOTAL, COMMISSION. При створенні замовлення триггер (або обробник OnAfterOrderAdd) автоматично створює суб-замовлення, групуючи позиції корзини по UF_VENDOR_ID товарів. Продавець бачить тільки свої суб-замовлення.

Варіант 2: Окремі корзини. Корзина на сайті розділяється по продавцах візуально, і при оформленні створюється окремий b_sale_order на кожного продавця. Технічно простіше, але ускладнює UX для покупця (кілька платежів або один агрегований).

Варіант 3: Атрибути позицій замовлення. VENDOR_ID зберігається в b_sale_basket як кастомна властивість через b_sale_basket_props_value. При перегляді замовлення продавець бачить тільки свої позиції. Суб-замовлення не створюється, статус управляється на рівні позиції.

Для більшості проектів оптимальні варіант 1 або 3 — варіант 2 незручний для покупця при змішаній корзині.

Особистий кабінет продавця

Мінімальний склад кабінету продавця:

• Управління товарами: додавання/редагування/деактивація. Використовується стандартний API інфоблоків з примусовим підставленням UF_VENDOR_ID = $USER->GetID() при додаванні та фільтрацією при виборці
• Управління замовленнями (суб-замовленнями): список, зміна статусу, друк накладної
• Управління остатками та цінами: масове оновлення через CSV-загрузку або AJAX-редагування
• Аналітика: продажи за період, топ товарів, повернення. Дані з суб-замовлень з агрегацією
• Профіль та реквізити: документи, платіжні дані, статус верифікації
• Фінанси: нараховані комісії, історія виплат, баланс

Кабінет реалізується як окремий розділ сайту з шаблоном, компонентами та AJAX-обробниками. Права: користувач у групі «Продавці» + перевірка UF_VENDOR_ID на кожен запит.

Система комісій

Комісії розраховуються у момент створення суб-замовлення або при його переходу в фінальний статус (оплачено). Логіка:

// Спрощений псевдокод
$commissionRate = $vendor['UF_COMMISSION_RATE']
    ?? $categoryRate[$product['IBLOCK_SECTION_ID']]
    ?? $defaultRate;

$commission = $subOrder['TOTAL'] * $commissionRate / 100;

// Зберігаємо в таблицю фінансових операцій
MpFinanceTable::add([
    'VENDOR_ID' => $vendor['ID'],
    'ORDER_ID'  => $orderId,
    'TYPE'      => 'commission',
    'AMOUNT'    => -$commission,
    'STATUS'    => 'pending',
]);

Комісія може варіюватися: єдина для всіх, по категорії товару, індивідуальна для продавця, прогресивна (залежить від обороту).

Модерація товарів

Товари продавців перед публікацією проходять модерацію. Технічно це статус елемента інфоблока: при додаванні товар продавцем встановлюється ACTIVE = N та спеціальний статус UF_MODERATION_STATUS = 'pending'. Модератор (користувач у групі «Модератори») бачить чергу на модерацію, перевіряє, встановлює ACTIVE = Y або відхиляє з коментарем.

Сповіщення продавця при результаті модерації — через CEvent::Send() або вбудовані сповіщення Бітрікс.

Технічний стек та готові компоненти

На маркетплейсі є кілька готових multi-vendor рішень: Marketplace Builder (від різних студій), Multi-Vendor модулі. Вони беруть на себе реєстрацію продавців, базовий кабінет, розділення замовлень. Кастомна розробка потрібна для специфічної логіки комісій, нестандартного кабінету, складних інтеграцій.

Рекомендований підхід: взяти готовий модуль як основу, кастомізувати через события та шаблони. Це швидше, ніж з нуля, але дорожче, ніж «просто налаштувати».

Терміни розробки

Терміни для розробки з нуля. Використання готового multi-vendor модуля як основи скорочує до 10–16 тижнів на кастомізацію.