На одному з проєктів з 60 постачальниками щодня менеджер витрачав 3 години на синхронізацію залишків через Excel. Після впровадження кабінету постачальника час скоротився до 10 хвилин. Такий самий біль — у багатьох дропшипінгових магазинів: постачальники не бачать свої замовлення, оновлюють ціни через листи, а помилки при ручному введенні сягають 12%. Розробка окремого особистого кабінету для кожного постачальника на 1С-Бітрікс вирішує ці проблеми: ізольовані права, власні товари та замовлення, масове завантаження CSV. Ми автоматизуємо рутину так, що постачальник витрачає 15 хвилин замість 4 годин — і помилки прямують до нуля.
Наш досвід: понад 10 років розробки на Бітрікс, 50+ проєктів в e-commerce. Гарантуємо стабільну роботу кабінету при навантаженні до 100 одночасно активних постачальників. Оцінимо ваш проєкт за 2 дні: зв'яжіться з нами для консультації.
Як організувати розмежування прав для постачальників?
У Бітрікс розмежування прав реалізується через групи користувачів. Створюємо групу «Постачальники» через API:
$groupId = CGroup::Add([ 'ACTIVE' => 'Y', 'NAME' => 'Постачальники', 'STRING_ID' => 'SUPPLIERS', ]); Прив'язка конкретного постачальника до його товарів — через HL-блок SupplierProduct або властивість інфоблоку SUPPLIER_ID типу «Прив'язка до користувача» (E). Розділ кабінету постачальника закривається через перевірку групи:
if (!$USER->IsAuthorized() || !$USER->IsInGroup($supplierGroupId)) { LocalRedirect('/auth/?backurl=' . urlencode($_SERVER['REQUEST_URI'])); } Докладніше про групи користувачів — у документації.
Склад кабінету: товари, замовлення, ціни
Що входить до блоку «Мої товари»?
Список товарів постачальника з поточним залишком і ціною. Запит через CIBlockElement::GetList з фільтром по SUPPLIER_ID:
$userId = $USER->GetID(); $res = CIBlockElement::GetList( ['NAME' => 'ASC'], [ 'IBLOCK_ID' => CATALOG_IBLOCK_ID, 'ACTIVE' => 'Y', 'PROPERTY_SUPPLIER_ID' => $userId, ], false, false, ['ID', 'NAME', 'DETAIL_PAGE_URL', 'PREVIEW_PICTURE', 'PROPERTY_SUPPLIER_ID'] ); Для кожного товару показуємо поточний залишок з b_catalog_store_product і ціну з b_catalog_price. Кожен постачальник має свій склад (b_catalog_store) — це дозволяє відстежувати залишки незалежно.
Як постачальник оновлює ціни та залишки?
Постачальник відправляє AJAX-запит з форми. Обробник перевіряє приналежність товару та виконує оновлення:
// /local/ajax/supplier-update.php $productId = (int)$_POST['product_id']; $newPrice = (float)$_POST['price']; $newQty = (int)$_POST['quantity']; $ownerCheck = CIBlockElement::GetProperty( CATALOG_IBLOCK_ID, $productId, 'sort', 'asc', ['CODE' => 'SUPPLIER_ID', 'VALUE' => $USER->GetID()] ); if (!$ownerCheck->Fetch()) { echo json_encode(['error' => 'Доступ заборонено']); die(); } $priceRow = CCatalogPrice::GetList( [], ['PRODUCT_ID' => $productId, 'CATALOG_GROUP_ID' => BASE_PRICE_GROUP_ID] )->Fetch(); if ($priceRow) { CCatalogPrice::Update($priceRow['ID'], ['PRICE' => $newPrice, 'CURRENCY' => 'RUB']); } else { CCatalogPrice::Add([ 'PRODUCT_ID' => $productId, 'CATALOG_GROUP_ID' => BASE_PRICE_GROUP_ID, 'PRICE' => $newPrice, 'CURRENCY' => 'RUB', ]); } $storeProductRow = CCatalogStoreProduct::GetList( [], ['PRODUCT_ID' => $productId, 'STORE_ID' => getSupplierStoreId($userId)] )->Fetch(); if ($storeProductRow) { CCatalogStoreProduct::Update($storeProductRow['ID'], ['AMOUNT' => $newQty]); } else { CCatalogStoreProduct::Add([ 'PRODUCT_ID' => $productId, 'STORE_ID' => getSupplierStoreId($userId), 'AMOUNT' => $newQty, ]); } echo json_encode(['success' => true]); Як постачальник бачить свої замовлення?
Постачальник бачить лише ті замовлення, в яких є його товари. Прямий запит до b_sale_order не підходить — потрібен зв'язок через кошик:
$supplierId = $USER->GetID(); $connection = \Bitrix\Main\Application::getConnection(); $orders = $connection->query(" SELECT DISTINCT o.ID, o.DATE_INSERT, o.PRICE, o.STATUS_ID, o.USER_ID, u.NAME, u.LAST_NAME, u.EMAIL FROM b_sale_order o JOIN b_sale_basket b ON b.ORDER_ID = o.ID JOIN b_iblock_element_property ep ON ep.IBLOCK_ELEMENT_ID = b.PRODUCT_ID AND ep.IBLOCK_PROPERTY_ID = " . SUPPLIER_PROP_ID . " AND ep.VALUE_NUM = {$supplierId} LEFT JOIN b_user u ON u.ID = o.USER_ID WHERE o.DATE_INSERT >= DATE_SUB(NOW(), INTERVAL 90 DAY) ORDER BY o.DATE_INSERT DESC LIMIT 100 "); На детальній сторінці замовлення постачальник бачить лише свої позиції кошика.
Підтвердження відвантаження та статуси
Постачальник підтверджує відвантаження своєї частини замовлення через інтерфейс. Статус фіксується в HL-блоці SupplierShipment з полями: UF_ORDER_ID, UF_SUPPLIER_ID, UF_STATUS (pending/confirmed/shipped/delivered), UF_TRACKING, UF_DATE_SHIPPED. Коли всі постачальники замовлення встановили статус shipped, агент автоматично змінює статус замовлення Бітрікс на «Відправлено».
Масове завантаження через CSV
Для постачальників з великим асортиментом (5000+ позицій) передбачена форма завантаження CSV-файлу з колонками: артикул, ціна, залишок. PHP-обробник знаходить товар за CML2_ARTICLE, перевіряє приналежність постачальнику, і якщо все коректно — оновлює ціну та залишок. Ліміт на кількість рядків (до 5000) виключає таймаут PHP. Для більших партій використовуємо фонові агенти.
Порівняння підходів до управління постачальниками
| Підхід | Ручне управління | Наш кабінет постачальника |
|---|---|---|
| Час на оновлення 100 товарів | 2 години | 5 хвилин |
| Ризик помилок | 12% | <1% |
| Доступ до даних | Повний до адмінки | Тільки свої товари та замовлення |
| Масштабування | До 10 постачальників | До 100+ постачальників |
Етапи розробки
| Етап | Тривалість | Результат |
|---|---|---|
| Аналітика | 1–2 дні | Вимоги, прототипи, рольова модель |
| Проектування | 2–3 дні | Архітектура БД, структура компонентів |
| Реалізація | 5–10 днів | Готовий функціонал: компоненти, AJAX, інтеграції |
| Тестування | 2–3 дні | Перевірка прав, навантаження до 100 сесій |
| Деплой та документування | 1–2 дні | Встановлення, кешування, навчання менеджерів |
Загальні терміни: від 1 до 4 тижнів залежно від складності (базовий кабінет — 1–1.5 тижні, повноцінний зі складом та CSV — 2–3 тижні, багатомовний з аналітикою — 3–4 тижні).
Чому стандартний особистий кабінет не підходить?
Вбудований модуль my в Бітрікс орієнтований на покупців: кошик, історія замовлень, особисті дані. Для постачальника потрібні інші сутності — управління залишками, масове завантаження, відстеження відвантажень. Крім того, без додаткових налаштувань постачальник не може бути обмежений лише своїми товарами. Тому потрібна розробка окремого компонентного рішення з власною системою прав.
Типові помилки, які ми запобігаємо
- Відсутність перевірки прав на AJAX-запитах — зловмисник може оновлювати чужі ціни. Всі обробники перевіряють SUPPLIER_ID.
- Немає тегованого кешування — при 100 постачальниках сторінка завантажується понад 10 секунд. Використовуємо кеш з тегами користувача.
- Склад постачальника не створюється автоматично — залишки всіх постачальників змішуються. Ми створюємо склад при реєстрації постачальника через подію OnBeforeUserRegister.
Переваги автоматизації
Автоматичний обмін даними з постачальниками в 5 разів швидший за ручне введення. Помилки при ручному оновленні трапляються в 12% транзакцій — з нашим кабінетом цей показник прямує до нуля. Кожен постачальник економить мінімум 3 години на день на звірці залишків.
Отримайте консультацію з архітектури кабінету — опишіть вашу ситуацію, і ми запропонуємо оптимальне рішення. Замовте розробку кабінету постачальника під ключ і почніть приймати замовлення через 1–2 тижні.