Разработка 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 недель на кастомизацию.