Розробка особистого кабінету продавця на маркетплейсі 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, частота дайджестів)
• Управління працівниками (суб-аккаунти з обмеженими правами — якщо потрібно)
• Статистика верифікації: які документи прийняті, які потребують оновлення

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