Дилерський портал на 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 день — зв'яжіться з нами для консультації.

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