Разработка личного кабинета продавца на маркетплейсе 1С-Битрикс

Разработка личного кабинета продавца на маркетплейсе 1С-Битрикс

Стандартный личный кабинет Битрикс (/personal/) рассчитан на покупателя: история заказов, избранное, адреса доставки. Для продавца нужен принципиально другой интерфейс — управление каталогом, обработка входящих заказов, финансовая аналитика. Это самостоятельный раздел сайта с собственной логикой доступа, компонентами и AJAX-обработчиками.

Архитектура доступа

Кабинет продавца — закрытый раздел, доступный только пользователям в группе «Продавцы». Защита реализуется на двух уровнях:

Уровень URL — в настройках раздела (b_iblock_rights или настройки публичного раздела) доступ только для группы «Продавцы». Неавторизованный пользователь получает редирект на страницу входа.

Уровень данных — каждый запрос к данным (товары, заказы, аналитика) фильтрует по UF_VENDOR_ID = $USER->GetID(). Это защита от IDOR-атак: продавец не может получить данные другого продавца, подставив чужой ID в запросе.

// Принципиальный паттерн — обязательно в каждом запросе
$vendorId = $USER->GetID();
if (!$USER->IsInGroup(VENDOR_GROUP_ID)) {
    LocalRedirect('/login/');
}

// Все выборки данных — с жёстким фильтром по vendorId
$products = CIBlockElement::GetList(
    ['NAME' => 'ASC'],
    ['IBLOCK_ID' => CATALOG_IBLOCK_ID, 'UF_VENDOR_ID' => $vendorId]
);

Управление товарами

Это центральный раздел кабинета. Функциональность:

Список товаров — таблица с пагинацией, фильтрацией по категории/статусу/активности. Под капотом — CIBlockElement::GetList() с фильтром UF_VENDOR_ID. Для производительности при большом каталоге (1000+ товаров) — добавляем индекс на UF_VENDOR_ID в MySQL/PostgreSQL.

Добавление/редактирование товара — форма с полями основного инфоблока и инфоблока торговых предложений. Ключевые нюансы:

• При добавлении принудительно устанавливаем UF_VENDOR_ID = $USER->GetID() — продавец не выбирает это поле сам
• ACTIVE = 'N' при добавлении (товар уходит на модерацию), UF_MODERATION_STATUS = 'pending'
• Загрузка изображений через CFile::SaveFile() в папку /upload/vendor_{$vendorId}/
• Выбор категории — из разрешённых (некоторые категории могут требовать дополнительной верификации)

Массовые операции — изменение цен, остатков, статуса через CSV-загрузку или AJAX. CSV-импорт: fgetcsv() + пакетное обновление через CIBlockElement::Update() с проверкой, что все редактируемые ID принадлежат текущему продавцу.

Остатки по складам — если маркетплейс работает с несколькими складами, управление остатками через CCatalogStoreProduct с фильтрацией складов продавца.

Управление заказами

Продавец видит только суб-заказы, связанные с его товарами. Интерфейс:

Список суб-заказов — с фильтрами по статусу, дате, сумме. Суб-заказы из таблицы mp_sub_orders (кастомная таблица маркетплейса, см. статью о multi-vendor архитектуре). JOIN с b_sale_order для получения данных покупателя.

Детали суб-заказа — список позиций, данные для доставки (адрес, получатель), кнопки смены статуса. Статусы, которые продавец может менять: confirmed → shipped, shipped → delivered. Отмену инициирует платформа или покупатель, не продавец в одностороннем порядке.

Печатные формы — накладная, этикетка для доставки. Генерация PDF через fpdf/tcpdf или через шаблон HTML с print.css.

Автоматические уведомления — при поступлении нового суб-заказа продавец получает уведомление на email (CEvent::Send()) и/или Telegram (webhook). Настраивается в профиле продавца.

Финансовый раздел

Баланс и операции. Таблица финансовых операций mp_finance_log с полями: тип (sale / commission / payout / refund), сумма, дата, привязка к суб-заказу. Текущий баланс = сумма всех операций по UF_VENDOR_ID. Выводится в виде timeline-таблицы с постраничной навигацией.

Запрос выплаты. Продавец может запросить выплату накопленного баланса (если остаток выше минимального порога). Запрос создаёт запись в таблице mp_payout_requests со статусом pending. Менеджер платформы обрабатывает вручную или через API платёжного шлюза.

Отчёты. Продажи за период, комиссии, возвраты — в табличном формате с экспортом в Excel (через PHPExcel/PhpSpreadsheet или встроенный Bitrix-экспорт).

Аналитика

Базовая аналитика продавца:

Данные выводятся через AJAX-запросы, графики — через Chart.js или ApexCharts. Тяжёлые агрегации выносятся в кэш (Redis или b_cache) с обновлением раз в час через агента Битрикс.

Профиль и настройки продавца

• Редактирование юридических данных и реквизитов
• Загрузка документов (с версионированием: новые документы уходят на повторную проверку)
• Настройки уведомлений (email, Telegram, частота дайджестов)
• Управление сотрудниками (суб-аккаунты с ограниченными правами — если нужно)
• Статистика верификации: какие документы приняты, какие требуют обновления

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