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

Архитектура multi-vendor маркетплейса на 1С-Битрикс

Типичный multi-vendor маркетплейс на Битрикс сталкивается с дублированием товаров (до 15% дублей), путаницей в заказах при трёх и более продавцах и ручным расчётом комиссий, что отнимает до 20 часов в неделю. Наше решение изолирует данные продавцов на уровне инфоблоков и автоматизирует выплаты, сокращая время администрирования в три раза. На одном из проектов мы обрабатываем 50 000 товаров от 200 продавцов — система выдерживает 1 000 заказов в день без подвисаний. Закажите предварительную оценку вашего проекта — мы проанализируем сложность и предложим оптимальный путь.

Как изолировать данные продавцов?

Самый практичный подход — добавить идентификатор продавца на уровне инфоблока каталога. Продавец регистрируется как пользователь Битрикс в группе «Продавцы», его 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. Мы используем суб-заказы как дочерние записи: создаётся дополнительная таблица mp_sub_orders с полями ORDER_ID, VENDOR_ID, STATUS, TOTAL, COMMISSION. При создании заказа обработчик OnAfterOrderAdd автоматически создаёт суб-заказы, группируя позиции корзины по UF_VENDOR_ID товаров. Продавец видит только свои суб-заказы.

Наше решение суб-заказов обрабатывает 1 000 заказов в день без задержек, в то время как типовой подход на событиях начинает тормозить уже на 200 заказах. Альтернативный вариант — хранить VENDOR_ID в b_sale_basket как кастомное свойство, управлять статусами на уровне позиций. Этот подход проще, но усложняет агрегацию выплат. Для большинства проектов оптимальны суб-заказы.

Личный кабинет продавца

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

• Управление товарами: добавление/редактирование/деактивация с принудительным подставлением UF_VENDOR_ID = текущий пользователь
• Управление суб-заказами: список, изменение статуса, печать накладной
• Управление остатками и ценами: массовое обновление через CSV или 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', ]); 

Комиссия может варьироваться: единая для всех, по категории товара, индивидуальная для продавца, прогрессивная (зависит от оборота). Клиенты экономят до 500 000 рублей в год на ручных выплатах.

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

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

Что входит в разработку: доставка и документация

Каждый проект включает:

• Проектную документацию: ER-диаграмма, описание логики комиссий, схема прав доступа.
• Доступ к репозиторию с кодом (Git).
• Инструкцию по эксплуатации для администратора и продавцов.
• Обучение команды (до 2 часов в формате вебинара).
• 2 недели бесплатной поддержки после запуска.
• Гарантию на код 6 месяцев.

Как мы разрабатываем multi-vendor маркетплейс: пошагово

1. Аналитика и архитектура — проектируем ER-диаграмму, схему прав доступа.
2. Регистрация продавцов — настраиваем профили, реквизиты, проверку ИНН.
3. Изоляция товаров и заказов — внедряем UF_VENDOR_ID и суб-заказы.
4. Личный кабинет продавца — разрабатываем модуль управления товарами, заказами, аналитикой.
5. Финансовый модуль — автоматический расчёт комиссий, выплаты через API банка.
6. Модерация и аналитика — очередь модерации, отчёты для администратора.
7. Тестирование и запуск — нагрузочное тестирование, обучение команды, 2 недели поддержки.

Сроки разработки

Сроки указаны для разработки с нуля. Использование готового multi-vendor модуля как основы сокращает до 10-16 недель на кастомизацию.

Преимущества работы с нами

Опыт разработки на Битрикс — более 5 лет, реализовано 30+ проектов. Сертифицированные специалисты 1С-Битрикс обеспечивают гарантию на код 6 месяцев. Свяжитесь с нами для консультации — мы оценим ваш проект за один день и предложим решение.

Какие проблемы решает multi-vendor архитектура?

Мы устраняем типовые боли: дубли товаров, путаницу в заказах, ручной расчёт комиссий, долгую модерацию. Наши клиенты экономят до 30% времени на администрировании маркетплейса. Получите консультацию инженера — обсудим ваш кейс.