Особистий кабінет постачальника для дропшипінгу на 1С-Бітрікс

На одному з проєктів з 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. Для більших партій використовуємо фонові агенти.

Порівняння підходів до управління постачальниками

Етапи розробки

Загальні терміни: від 1 до 4 тижнів залежно від складності (базовий кабінет — 1–1.5 тижні, повноцінний зі складом та CSV — 2–3 тижні, багатомовний з аналітикою — 3–4 тижні).

Чому стандартний особистий кабінет не підходить?

Вбудований модуль my в Бітрікс орієнтований на покупців: кошик, історія замовлень, особисті дані. Для постачальника потрібні інші сутності — управління залишками, масове завантаження, відстеження відвантажень. Крім того, без додаткових налаштувань постачальник не може бути обмежений лише своїми товарами. Тому потрібна розробка окремого компонентного рішення з власною системою прав.

Типові помилки, які ми запобігаємо

• Відсутність перевірки прав на AJAX-запитах — зловмисник може оновлювати чужі ціни. Всі обробники перевіряють SUPPLIER_ID.
• Немає тегованого кешування — при 100 постачальниках сторінка завантажується понад 10 секунд. Використовуємо кеш з тегами користувача.
• Склад постачальника не створюється автоматично — залишки всіх постачальників змішуються. Ми створюємо склад при реєстрації постачальника через подію OnBeforeUserRegister.

Переваги автоматизації

Автоматичний обмін даними з постачальниками в 5 разів швидший за ручне введення. Помилки при ручному оновленні трапляються в 12% транзакцій — з нашим кабінетом цей показник прямує до нуля. Кожен постачальник економить мінімум 3 години на день на звірці залишків.

Отримайте консультацію з архітектури кабінету — опишіть вашу ситуацію, і ми запропонуємо оптимальне рішення. Замовте розробку кабінету постачальника під ключ і почніть приймати замовлення через 1–2 тижні.

Налаштування дропшипінгу на 1С-Бітрікс: інтернет-магазин без складу

Головне технічне завдання дропшипінг-магазину — не вітрина, а синхронізація залишків. Покупець оформив замовлення, а товар закінчився у постачальника 10 хвилин тому — і ви отримуєте повернення, негативний відгук і мінус до репутації на маркетплейсі. Ми будуємо дропшипінг-магазини на 1С-Бітрікс з автоматизацією всього ланцюжка: парсинг каталогу, синхронізація залишків кожні 5–15 хвилин, автоматична передача замовлень постачальнику, трекінг в особистому кабінеті. Послуги з налаштування дропшипінгу на 1С-Бітрікс включають повний цикл: від першого контакту з постачальником до SEO-оптимізації вітрини. За понад 6 років роботи ми запустили більше 40 таких магазинів — від single‑vendor до мультипостачальних каталогів на 300 000+ SKU.

Чому 1С-Бітрікс підходить для дропшипінгу?

Платформа дає готові інструменти для e-commerce: модуль «Інтернет-магазин», корзина, платіжні обробники, особистий кабінет — все з коробки. Не потрібно збирати магазин з плагінів. Обмін через CommerceML з постачальниками на 1С налаштовується за пару днів: вивантаження catalog.xml + offers.xml → автоматичний імпорт.

Мультипостачальник підтримує один товар від трьох постачальників з різними цінами. Бітрікс через типи цін (b_catalog_group) та мультисклад (b_catalog_store) дозволяє вести все в одній вітрині та підставляти кращу пропозицію. SEO-блок: bitrix:catalog.seo.filter для індексованих фільтрів, шаблони мета-тегів з підстановкою властивостей інфоблоку, автогенерація ЧПУ. Масштабованість — від 100 до 500 000+ товарів. При правильному налаштуванні фасетного індексу (b_catalog_iblock_index) каталог на півмільйона SKU працює без деградації.

Чи можна інтегрувати дропшипінг на 1С-Бітрікс без програмування?

Відповідь — ні, якщо ви хочете стабільної роботи. Типова помилка — спроба налаштувати імпорт через стандартний «Імпорт з XML» в адмінці. На каталозі з 10 000 товарів це призводить до таймаутів, дублів і ручного контролю. Ми пишемо кастомний імпортер під кожного постачальника — з обробкою помилок, інкрементальним оновленням і логуванням.

Технічна архітектура рішення

Імпорт каталогу: чому стандартний інструмент не працює на великих обсягах

Постачальники віддають дані хто як — і до кожного свій підхід:

• YML/XML-фіди (формат Яндекс.Маркет) — найпоширеніший. Парсимо через XMLReader (не SimpleXML — на великих фідах у 500 МБ він з'їсть всю пам'ять, а XMLReader споживає в 10 разів менше ресурсів)
• CSV/Excel — мапінг полів через конфіг, валідація, обробка кривих кодувань (так, досі постачальники надсилають CSV у Windows-1251)
• API постачальника — прямий доступ до каталогу в реальному часі, найнадійніший варіант
• CommerceML — стандартний формат обміну з 1С

Наш імпортер закриває рутину:

• Завантаження за розкладом через агент Бітрікс (CAgent::AddAgent) — кожні 15–60 хвилин, налаштовується під постачальника
• Мапінг категорій постачальника → розділи інфоблоку каталогу. Без ручного перетягування — правила задаються один раз
• Завантаження та оптимізація зображень: ресайз через CFile::ResizeImageGet, стиснення, конвертація у WebP
• Інкрементальне оновлення цін та залишків — без перестворення елементів інфоблоку. Оновлюємо лише змінені поля через CIBlockElement::SetPropertyValues та CCatalogProduct::Update
• Генерація унікальних описів — перефразування або AI-сервіси
• Націнка за правилами: відсоток, фікс, окремо за розділами каталогу

Без дедуплікації з'являються дублі товарів — вирішуємо мапінгом за артикулом або EAN. Якщо не налаштувати алерти при збоях фіду, магазин продає неіснуючі товари — налаштовуємо сповіщення менеджеру.

Як налаштувати синхронізацію залишків без втрат?

У дропшипінгу ви не контролюєте склад. Розбіжність між фідом і реальною наявністю — прямі збитки. Налаштування синхронізації кожні 5–60 хвилин (залежить від API/фіду постачальника). Автосховування товарів з нульовим залишком — CIBlockElement::Update(['ACTIVE' => 'N']). Жодної «порожньої» картки в catalog.section. Алерти менеджеру при масових розбіжностях — якщо раптом 30% каталогу обнулилося, це швидше збій фіду, ніж реальний розпродаж. Мультипостачальник: один товар від кількох джерел — через різні склади в b_catalog_store. Система підставляє пропозицію з наявністю та кращою ціною.

Обробка замовлень та логістика

Автоматична передача замовлень постачальнику — без ручного копіювання. Відправка через API, email (шаблон з b_event_message) або вивантаження в ОК постачальника. Розподіл позицій між постачальниками — якщо в sale.basket товари від різних джерел, замовлення розбивається на відвантаження. Отримання трек-номера → запис у властивість замовлення → сповіщення покупцеві через \Bitrix\Sale\Notify. Обробка часткової наявності: товар є в одного постачальника, немає в іншого — автоматичне розбиття замовлення.

Доставка в дропшипінгу — зона постачальника, але покупець бачить ваш бренд. Терміни доставки з урахуванням обробки у постачальника — не лише час транспортної компанії. Трекінг в особистому кабінеті через API СДЕК, Boxberry, Укрпошти. Об'єднання відправлень від кількох постачальників (при наявності проміжного складу). Повернення — координація між покупцем і постачальником через єдиний інтерфейс в адмінці. Брендована упаковка за домовленістю.

Ціноутворення та робота з кількома постачальниками

Націнка — те, на чому будується маржа. Відсоткова: 30% від закупівельної на весь каталог. Ступінчаста: до певної суми — 50%, наступний діапазон — 30%, вище — 20%. Категорійна: електроніка 15%, аксесуари 60%. Психологічне округлення через кастомне правило націнки. Моніторинг конкурентів — парсинг цін та автокоригування. RRP — рекомендована роздрібна ціна постачальника як верхній орієнтир.

Мультипостачальник розширює асортимент і страхує. Об'єднання каталогів в єдину структуру розділів інфоблоку. Дедуплікація — за артикулом (PROPERTY_ARTICLE) або EAN. Один товар = один елемент інфоблоку, кілька пропозицій у b_catalog_store. Автоматичний вибір постачальника: наявність → ціна → швидкість доставки. Окремий облік: закупівельні ціни в окремому типі цін (PURCHASE), історія замовлень, статистика. Панель з рейтингом надійності — хто зриває терміни, у кого розбіжності за залишками.

Унікалізація контенту та SEO

Десятки магазинів копіюють описи з фіду постачальника — і програють у SEO. Унікальні описи для топових категорій, що приносять основний трафік. Решта — шаблонна генерація з властивостей. Мета-теги за шаблоном: title і description через налаштування SEO інфоблоку: {=this.Name} купити в Києві | {=parent.Name} — ціна від {=this.catalog.price.BASE}. UGC — відгуки (iblock.vote), питання-відповіді, фото від покупців. Живий контент працює краще за копірайтинг. SEO-фільтри — bitrix:catalog.seo.filter створює індексовані сторінки перетинів: «червоні кросівки Nike 42 розмір» з унікальними мета-тегами.

Згідно з офіційною документацією 1С-Бітрікс, система підтримує до 20 типів цін і необмежену кількість складів.

Юридичні аспекти

Договір комісії або агентський з постачальником — юридична база. Інтеграція з ОФД за 54-ФЗ — фіскалізація чеків через sale.cashbox. Гарантія: перед покупцем відповідаєте ви, незалежно від відвантажувача. Налаштування бізнес-процесів (Bizproc) для автоматизації повернень.

Як ми запускаємо проєкт та що входить у роботу

Покрокова схема впровадження

1. Аудит постачальників — збираємо специфікації фідів, API, узгоджуємо мапінг.
2. Налаштування імпорту — пишемо парсер, валідацію, агенти синхронізації.
3. Налаштування магазину — дизайн, платіжні шлюзи, служби доставки.
4. Автоматизація замовлень — інтеграція передачі замовлень, трекінг, повернення.
5. SEO та унікалізація — мета-теги, описи, фільтри.
6. Тестування — контрольні сценарії, навантажувальні тести.
7. Деплой та моніторинг — запуск, алерти, документація.

Що входить у роботу та терміни

Повна документація: налаштування інтеграцій, параметри імпорту, API-ключі. Передача доступів: адмінка, хостинг, API. Навчання команди: робота з імпортом, управління замовленнями, звіти. Підтримка після запуску: 2 тижні безлімітних консультацій, далі за SLA.

Запускаємо дропшипінг-магазини з мінімальними вкладеннями та допомагаємо масштабувати — від одного постачальника до десятків, від сотні SKU до сотень тисяч. Замовте консультацію — зв'яжіться з нами, оцінимо завдання та запропонуємо оптимальне рішення під ключ. Отримайте безкоштовний аудит вашої схеми дропшипінгу прямо зараз.