Дилерський портал на 1С-Бітрікс: система ролей, ціни, інтеграція з 1С

Якщо у вас 80 дилерів, менеджери витрачають півдня на розсилку прайсів. Це вузьке місце, яке ми усуваємо. Портал закриває три завдання: самостійне оформлення замовлень дилером, індивідуальні умови для кожного партнера та автоматична синхронізація з 1С без участі людини. Оцінимо проект за 1 день — зв'яжіться з нами для безкоштовної консультації.

Головна відмінність дилерського порталу від звичайного B2B — ієрархія «виробник → дилер → субдилер». Один дилер може мати кілька торгових точок і співробітників з різними правами. Штатна модель груп користувачів Бітрікс (b_user_group) тут недостатня — вона не зберігає зв'язок «користувач належить компанії».

Реалізація через D7 ORM: створюємо сутність DealerCompany (таблиця b_dealer_company) з полями ідентифікатора в 1С, статусу, типу дилера, регіону. Зв'язок користувачів з компанією — через таблицю b_dealer_company_user з полем ролі. Ролі: owner, manager, accountant — з різними правами на створення замовлень, перегляд документів, управління співробітниками. Авторизація через bitrix:system.auth.form доповнюється кастомним обробником. При вході користувача визначаємо його компанію та тип дилера, кешуємо в сесії. Всі наступні запити до цін і каталогу йдуть з урахуванням dealer_type.

Як налаштувати ціноутворення для різних типів дилерів?

Дилерське ціноутворення — найскладніша частина. Типова схема:

• Базовий прайс (публічний або закритий)
• Дилерська знижка за типом (silver, gold, platinum) — відсоток від базової ціни
• Індивідуальні контрактні позиції — конкретні артикули за фіксованою ціною
• Акційні умови з датою дії

Стандартний механізм CATALOG_GROUP_ID в b_catalog_price покриває перші два рівні. Для контрактних позицій потрібен Highload-блок dealer_contract_prices зі структурою: UF_DEALER_ID, UF_PRODUCT_ID, UF_PRICE, UF_CURRENCY, UF_DATE_FROM, UF_DATE_TO. При запиті ціни перевіряємо спочатку контрактну позицію, потім дилерський тип, потім базову.

Логіка пріоритету цін впроваджується через подію OnBeforeSaleOrderDoFinalAction або через кастомний провайдер цін, що реалізує Bitrix\Catalog\v2\Price\BasePriceProvider. Другий варіант чистіший — він не ламається при оновленнях модуля sale. Згідно з документацією Бітрікс, BasePriceProvider забезпечує сумісність з майбутніми оновленнями. Кастомне рішення на Бітріксі краще готового CRM-модуля за гнучкістю ціноутворення.

Каталог і залишки

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

• Фільтрацію за властивістю інфоблоку: додаємо властивість AVAILABLE_FOR_DEALER_TYPES (тип «список»), вказуємо типи дилерів. У компоненті bitrix:catalog.section додаємо фільтр PROPERTY_AVAILABLE_FOR_DEALER_TYPES = тип поточного дилера.
• Highload-блок асортименту: для гнучкого налаштування — таблиця dealer_assortment (UF_DEALER_ID, UF_IBLOCK_SECTION_ID). Дилеру доступні лише розділи каталогу, перелічені в його записах.

Залишки — через штатний модуль catalog, таблиця b_catalog_store_product. Для дилерського порталу важливо показувати залишки на конкретних складах, доступних дилеру (склад у його регіоні). Зв'язок дилер → склад зберігається в Highload-блоці, в компоненті перевизначається запит до b_catalog_store_product.

Документообіг і фінанси

Дилери запитують документи постійно — рахунки, накладні, акти звірки. Зберігати їх у Бітріксі надмірно, якщо вони вже є в 1С. Схема роботи:

1. Портал запитує список документів дилера через REST-сервіс 1С (або вивантаження в проміжну таблицю)
2. Документи кешуються в Highload-блоці dealer_documents: UF_DEALER_ID, UF_DOC_TYPE, UF_DOC_NUMBER, UF_DATE, UF_AMOUNT, UF_FILE_URL
3. Синхронізація по крону кожні 2 години через агент модуля main (CAgent::AddAgent)
4. PDF-файли запитуються за вимогою, кешуються в /upload/dealer/docs/ на 24 години

Заборгованість і ліміт кредиту — аналогічно: Highload-блок dealer_credit (UF_DEALER_ID, UF_LIMIT, UF_CURRENT_DEBT, UF_OVERDUE). При перевищенні ліміту або наявності прострочення — заборона на оформлення замовлення реалізується через обробник події OnBeforeSaleOrderAdd.

Що робити, якщо дилер перевищує кредитний ліміт?

При кожному створенні замовлення спрацьовує обробник OnBeforeSaleOrderAdd: перевіряється поточна заборгованість дилера з dealer_credit. Якщо ліміт перевищено або є прострочення, замовлення блокується, а дилеру надсилається сповіщення. Це виключає ризики несплати та автоматизує контроль.

Сповіщення та комунікація

Портал без сповіщень — половина роботи. Налаштовуємо:

• Поштові події (CEventType, CEvent::Send): зміна статусу замовлення, наближення терміну оплати, новий прайс
• Push-сповіщення через модуль pull (якщо є мобільний додаток)
• Стрічка подій в кабінеті дилера — Highload-блок dealer_events з подіями, позначеними як прочитані

Інтеграція з CRM

Якщо у виробника Бітрікс24, дилерський портал синхронізується з CRM:

• Реєстрація нового дилера → створює компанію в CRM (crm.company.add)
• Замовлення дилера → угода в CRM з прив'язкою до компанії
• Зміна статусу угоди → зміна статусу замовлення на порталі через вебхук

Зв'язок реалізується через REST API Бітрікс24, зберігання ID сутностей CRM у користувацьких полях компанії.

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

• Аналітика та проектування: прототип, технічне завдання
• Розробка системи ролей та авторизації
• Ціноутворення всіх рівнів (знижки, контрактні ціни, акції)
• Особистий кабінет дилера з історією замовлень та документами
• Інтеграція з 1С через CommerceML або REST
• Тестування та деплой на бойовий сервер
• Навчання співробітників та передача доступів
• Гарантійна підтримка 6 місяців

Терміни

Разом: 14–24 тижні. Розкид визначається глибиною інтеграції з 1С та кількістю кастомних бізнес-правил з ціноутворення. Оцінимо ваш проект за 1 день — зв'яжіться з нами для консультації.

Замовте розробку дилерського порталу та отримайте безкоштовний аудит поточних процесів. Це допоможе точно оцінити терміни та обсяг робіт.

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