Розробка дилерського порталу на 1С-Бітрікс

Розробка дилерського порталу на 1С-Бітрікс

Дилерська мережа з 80 компаній та менеджер, що вручну розсилає прайс-листи по пошті щопонеділка — це не процес, це вузьке місце. Дилерський портал на Бітриксі закриває три речі одночасно: самостійне оформлення замовлень дилером, індивідуальні умови для кожного партнера та автоматичну синхронізацію з 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. Другий варіант чистіший — не ломається при оновленнях модуля.

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

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

• Фільтрацію по властивості інфоблока: додаємо властивість 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.

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

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

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

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

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

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

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

Часові рамки

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