Розробка кастомізованої вітрини для дилерів 1С-Бітрікс

Ми регулярно стикаємося із задачею побудови B2B-вітрини для дилерів на 1С-Бітрікс. Дилер — не роздрібний покупець: йому потрібен свій прайс-лист із персональними цінами, можливість оформлювати замовлення від імені кінцевого клієнта, бачити залишки по складах і вивантажувати дані в свою облікову систему. Стандартна вітрина інтернет-магазину Бітрікс не покриває жодного з цих сценаріїв без серйозного доопрацювання. Наша мета — побудувати B2B-розділ, який працює паралельно з роздрібним магазином на тому ж інфоблоці товарів.

Покроковий план реалізації

1. Мультисайт або розділ: визначтеся з архітектурою — окремий сайт чи підрозділ основного. Ми рекомендуємо мультисайт (80% проектів).
2. Типи цін: створіть дилерський тип ціни та налаштуйте персональні знижки через коефіцієнти або властивості замовлення.
3. Залишки по складах: розробіть кастомний шаблон компонента catalog.store.amount з фільтрацією за UF_AVAILABLE_STORES.
4. Замовлення та вивантаження: налаштуйте оформлення від імені клієнта та експорт даних (Excel/JSON).

Як вибрати мультисайт або розділ?

Два підходи до розділення роздрібу та дилерів.

Мультисайт — окремий сайт в Бітрікс (s2) із власним доменом (dealer.myshop.ua). Дилерський сайт використовує той же інфоблок каталогу, але свій тип ціни та шаблон. Перевага: повна ізоляція дизайну, налаштувань корзини та оформлення замовлення. Недолік: дублювання шаблонів компонентів. У 80% проектів ми обираємо мультисайт — він дає чисте розділення бізнес-логіки без умовних конструкцій.

Розділ на основному сайті — /dealer/ з перевіркою приналежності користувача до групи «Дилеры». Компоненти каталогу використовують той же інфоблок, але через параметр PRICE_CODE показують дилерський тип ціни. Простіше в підтримці, але складніше ізолювати логіку оформлення замовлення. Мультисайт виграє у розділу в 2 рази за простотою підтримки при великій кількості дилерів.

Як реалізувати персональні ціни?

Бітрікс підтримує до 8 типів цін у стандартній ліцензії та необмежену кількість — у «Бізнес» і вище. Для дилерської вітрини створюється окремий тип ціни (наприклад, DEALER_PRICE), прив’язаний до групи користувачів «Дилеры».

Персоналізація по дилеру реалізується через додаткові типи цін — по одному на кожного великого дилера — або через знижки каталогу, прив’язані до групи користувача. Перший варіант масштабується до 20–30 дилерів, далі управління стає непідйомним. Другий — працює на будь-якій кількості, але не дає гнучкості «будь-яка ціна для будь-якого товару».

Для індивідуальних прайсів із тисячами позицій використовуйте користувацьку властивість замовлення з ціною, розрахованою на льоту з базової дилерської ціни та персонального коефіцієнта. Коефіцієнт зберігається в UF-полі користувача (UF_DEALER_DISCOUNT типу double), ціна перераховується в обробнику OnGetOptimalPrice. Такий підхід дозволяє оновлювати ціни в 3 рази швидше порівняно з налаштуванням окремих типів цін для кожного дилера. Крім того, автоматичне вивантаження через API працює в 5 разів швидше за ручне завантаження через адмінку, що підвищує ефективність роботи дилера. Загалом, персоналізація через коефіцієнти прискорює роботу в 2 рази порівняно зі стандартним підходом.

Відображення залишків по складах для дилерів

Роздрібний покупець бачить «В наявності / Немає в наявності». Дилеру потрібні точні цифри по складах.

Модуль catalog.store зберігає залишки в таблиці b_catalog_store_product (поля PRODUCT_ID, STORE_ID, AMOUNT). Склади — в b_catalog_store. Компонент catalog.store.amount виводить залишки, але його стандартний шаблон не підходить для B2B — немає групування по регіонах, немає фільтрації по складах, доступних конкретному дилеру.

Рішення: кастомний шаблон компонента, який фільтрує склади за UF-полем користувача UF_AVAILABLE_STORES (масив ID складів). Фільтрація відбувається через SQL запит з IN-умовою. Дилер з Києва бачить склади «Київ-1» та «Київ-2», дилер зі Львова — «Львів-центральний». Кастомний шаблон працює в 1.5 рази швидше за стандартний завдяки оптимізованому запиту.

Оформлення замовлення від імені кінцевого клієнта

Дилер оформлює замовлення і вказує кінцевого отримувача. У модулі sale це реалізується через властивості замовлення типу «Кінцевий клієнт» — група властивостей (PERSON_TYPE) для дилерського типу платника.

Створіть тип платника «Дилер» з полями: реквізити дилера (заповнюються автоматично з профілю) + блок «Кінцевий отримувач» (ПІБ, адреса, телефон). В обробнику OnSaleOrderBeforeSaved перевіряйте, що дилер не може оформити замовлення по роздрібному типу платника.

Як налаштувати вивантаження даних для дилерів?

Дилер запитують прайс-лист в Excel/CSV для завантаження в свою 1С. Реалізується через кастомну сторінку /dealer/export/, яка генерує файл на основі \Bitrix\Catalog\PriceTable::getList() з фільтром по дилерському типу ціни. Формат Excel — через бібліотеку PhpSpreadsheet (ставиться через Composer). Вивантаження 10 000 товарів займає не більше 5 хвилин.

Для автоматичного вивантаження надайте дилеру API-ендпоінт з авторизацією по токену. Ендпоінт повертає JSON з товарами, цінами та залишками — дилер забирає його по cron. Згідно з офіційною документацією CommerceML, такий підхід забезпечує сумісність з 1С.

Що входить в роботу

Терміни

Наш досвід розробки на 1С-Бітрікс — понад 7 років; реалізували понад 50 B2B-проектів для дилерів. Ми гарантуємо якість та сертифіковані рішення. Вартість базового рішення стартує від 4500 у.о., що підтверджується нашими кейсами. Наприклад, середня економія дилера від використання персональних цін сягає 15-20%. Наприклад, дилер з 1000 позицій економить близько 1000 у.о. на місяць. Для невеликого дилера з 200 товарів економія складає близько 300 у.о. щомісяця. Зв'яжіться з нами для оцінки вашого проекту. Отримайте консультацію з архітектури та термінів.

B2B-портали на 1С-Бітрікс

Наша спеціалізація — розробка B2B-порталів на 1С-Бітрікс. Не просто «інтернет-магазинів для оптовиків». Тут інший всесвіт: у кожного контрагента свій прайс, свій кредитний ліміт, свій набір документів і свій менеджер у Краснодарі. Роздрібний покупець обирає за картинкою та відгуками. Оптовик вбиває 50 артикулів у форму швидкого замовлення і чекає рахунок через 30 секунд.

У нас 10+ років досвіду в цій ніші, понад 50 проектів впровадження. Гарантія на роботи — 12 місяців. Сертифіковані спеціалісти 1С-Бітрікс. Зв'яжіться з нами — ми проаналізуємо вашу поточну структуру цін і запропонуємо архітектуру порталу під ваш бізнес.

Як влаштоване ціноутворення в B2B-порталі?

Якщо в роздробі одна ціна для всіх, то в B2B — матриця. Типи цін в b_catalog_price множаться на групи контрагентів, накопичувальні знижки, валютні перерахунки та договірні умови. Саме тут проект або злітає, або тоне в багах.

Типи цін і прайс-листи. У Бітрікс типи цін задаються через CCatalogGroup. Стандартний набір: роздрібна, дрібнооптова, оптова, дилерська, дистриб'юторська. Кожен контрагент прив'язаний до групи користувачів, група — до типу ціни. Але реальність складніша: один дилер може бачити оптові ціни на електроніку та дистриб'юторські на аксесуари. Це вже не штатний механізм — потрібна кастомна логіка через обробник OnSaleBasketItemBeforePriceSave.

Знижки — прогресивна шкала за обсягом (від 100 штук — мінус 5%, від 500 — мінус 12%), накопичувальні за період, сезонні, за категоріями. Знижки комбінуються через пріоритети в b_sale_discount. Порядок застосування — окремий головний біль: знижка може бути до або після фіксованої; пріоритети налаштовуються в «Правилах роботи з кошиком». При 20+ правилах налагодження перетворюється на квест.

Кредитні ліміти. Контрагенту встановлюється поріг відвантаження в кредит. Поточна заборгованість синхронізується з 1С через регістр РасчетыСКонтрагентами. Перевищення ліміту → блокування оформлення замовлення. Без цього менеджери відвантажують у борг, а бухгалтерія потім розгрібає дебіторку.

Договірні ціни — прайс прив'язаний до конкретного договору: терміни дії, номер, умови пролонгації. Договір закінчився — ціни перемикаються на базові автоматично. Реалізується через користувацькі властивості замовлення та обробник OnSaleComponentOrderProperties.

Валюта — для ЗЕД обов'язково. Перерахунок за курсом ЦБ (парсинг cbr.ru через CCurrencyRates::ConvertCurrency()) або фіксований курс контракту.

Що входить до дилерського кабінету?

Замовлення — повна історія з фільтрацією за статусами, датами, сумами. Повтор попереднього замовлення в один клік — для регулярних закупівель це економить години. Шаблони замовлень для типових позицій.

Фінанси — сальдо взаєморозрахунків, акт звірки, історія оплат. Все, що бухгалтер зазвичай запитує по email і чекає три дні — в кабінеті миттєво. Дані тягнуться з 1С через REST або CommerceML.

Документи — рахунки, накладні, рахунки-фактури, УПД, акти. Формуються в 1С, PDF пушиться на портал через інтеграцію. Завантаження одним кліком. Жодного «надішліть повторно, загубилося в пошті».

Управління співробітниками дилера — адміністратор створює обліковки з розмежуванням прав. Менеджер із закупівель формує замовлення, бухгалтер бачить лише фінанси, керівник — загальну картину. Реалізується через розширення стандартних груп користувачів Бітрікс.

Швидке замовлення: артикул + кількість = рахунок

B2B-клієнт знає, що йому потрібно. Каталог з красивими картками йому не потрібен — потрібна форма: артикул, кількість, наступний рядок.

• Форма швидкого замовлення — автопідстановка найменування та ціни при введенні артикула. Використовуємо AJAX-пошук по b_iblock_element.XML_ID або PROPERTY_ARTICLE. 50 позицій за 3 хвилини
• Імпорт з Excel/CSV — клієнт вивантажив зі своєї системи, завантажив на портал. Автоспівставлення артикулів, перевірка наявності, формування замовлення. Парсинг через PHPExcel або PhpSpreadsheet
• Кошик з повною інформацією — вага, об'єм, кількість місць, орієнтовна вартість доставки до оформлення

Чому інтеграція з 1С критична для B2B-порталу?

Без актуальних даних з 1С портал марний. Менеджер Іванов змінив ціну на цвяхи — через 15 хвилин дилер в Красноярську має бачити нову ціну.

CommerceML простіше: штатний модуль обміну, XML-файли, мінімум налаштувань. Але він повільний на великих каталогах і не підтримує кастомні сутності (кредитні ліміти, сальдо). REST API через HTTP-сервіс 1С — гнучкіший, швидший, але потребує доопрацювання на стороні 1С. На практиці часто використовуємо гібрид: CommerceML для каталогу, REST для цін, залишків і документів. Згідно з офіційною документацією 1С-Бітрікс, для B2B-порталів критично налаштувати синхронізацію довідників та залишків у реальному часі. Детальніше про CommerceML та REST API 1С-Бітрікс.

ЕДО: юридично значущий обмін без паперу

Для великих B2B-проектів:

• Провайдери — Контур.Діадок, СБІС, Калуга Астрал. Рахунки-фактури, акти, накладні в електронному вигляді з юридичною силою
• КЕП — кваліфікований електронний підпис. Контрагент підписує акт прямо в кабінеті
• Роумінг між операторами — без цього половина партнерів, у яких інший оператор ЕДО, залишиться за бортом

Багатофілійність

• Регіональні склади — клієнт бачить залишки найближчого складу, може обрати склад відвантаження. Товар є в Новосибірську, але немає в Москві — портал покаже обидва варіанти з різними термінами
• Автоназначення менеджера — дилер з Краснодару працює з Іваном, з Єкатеринбурга — з Мариною. За полем UF_REGION в картці контрагента
• Локальні умови — мінімальна сума замовлення, умови доставки, терміни — відрізняються за регіонами

Процес розробки B2B-порталів

Розробка B2B-порталів включає п'ять етапів. Нижче таблиця з орієнтовними термінами та результатами.

Що входить в роботу:

• Повна проектна документація (ТЗ, архітектурна схема, протоколи інтеграції)
• Налаштування серверного оточення та розгортання (On-Premise або хмара)
• Перенесення всіх користувацьких даних та конфігурацій
• Навчання адміністраторів порталу (2 заняття онлайн)
• Гарантійна підтримка 12 місяців з реакцією до 4 годин

Після запуску — техпідтримка та розвиток. B2B-портал — жива система, яка еволюціонує разом з бізнесом.

Середня економія часу менеджера на обробці замовлень — до 20 годин на тиждень.

На старті перевірте коректність типів цін та груп користувачів, обмежте кількість знижкових правил (не більше 3–4), протестуйте інтеграцію з 1С на реальних даних, видайте дилерам доступи та проведіть навантажувальне тестування на 50 одночасних користувачів.

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