Розробка B2B-порталу на 1С-Бітрікс

Розробка B2B-порталу на 1С-Бітрікс

Стандартний інтернет-магазин на Бітриксі не підходить для оптових продажів: там одна ціна для всіх, публічний каталог, відсутність кредитних лімітів і алгоритму узгодження замовлень. Коли менеджер з продажу витрачає 40 хвилин на оформлення кожного замовлення вручну через CRM, а дилер телефонує, щоб дізнатися залишки — це симптоми відсутності B2B-порталу, а не проблема персоналу.

Чим B2B-портал принципово відрізняється від публічного магазину

Архітектурно — інша логіка авторизації, інша модель ціноутворення і інший сценарій замовлення.

Авторизація та групи користувачів. У bitrix:sale користувач прив'язаний до однієї групи. У B2B потрібна ієрархія: компанія → контактна особа → роль (закупівельник, бухгалтер, директор). Штатні групи користувачів Бітрикс для цього не підходять — вони плоскі. Реалізується через кастомний модуль з таблицею зв'язків company_user і проміжною сутністю через D7 ORM (Bitrix\Main\ORM\Data\DataManager). Права на дії (створити замовлення, бачити заборгованість, змінити адресу доставки) задаються через бітову маску в Highload-блоці ролей.

Типи цін. Модуль catalog підтримує кілька типів цін: CATALOG_GROUP_ID у таблиці b_catalog_price. Для B2B це обов'язкова механіка — кожній групі користувачів призначається свій тип ціни. Але індивідуальні контрактні ціни складніше: потрібна окрема таблиця договірних позицій з пріоритетом вище базового типу. Реалізується через обробник події OnSaleOrderBeforeSaved або через кастомний провайдер цін, що імплементує Bitrix\Catalog\v2\Price\BasePriceProvider.

Каталог з залишками в реальному часі. B2B-покупці замовляють великими партіями і перевіряють доступність до оформлення. Дані про залишки в b_catalog_store_product оновлюються при синхронізації з 1С через CommerceML 2.10. Якщо синхронізація йде раз на годину — клієнт бачить застарілі дані. Рішення: REST API 1С + обробник змін на стороні Бітрикс, який оновлює залишки інкрементально через CCatalogStoreProduct::Update().

Ключові модулі та компоненти

Модуль sale — основа для кошика та замовлень. У B2B доробляється: додаємо статуси (На узгодженні, Узгоджено, Відхилено), налаштовуємо бізнес-процеси через модуль bizproc для маршрутизації замовлень за відповідальних осіб.

Модуль catalog — ціноутворення, торговельні пропозиції (SKU), управління складами. Для B2B обов'язково задіюється CatalogGroup (типи цін) і DiscountCoupon для разових акцій.

Модуль crm (якщо обрана схема з Бітрикс24) — синхронізація замовлень порталу з угодами CRM. Залежність двостороння: замовлення з порталу створює угоду, зміна статусу угоди змінює статус замовлення. Через REST API crm.deal.add / crm.deal.update з вебхуком назад.

Особистий кабінет — мінімальний набір: історія замовлень з повтором, поточні замовлення в роботі, заборгованість по актам звірки, документи (рахунки, накладні в PDF), управління контактними особами компанії.

Інтеграція з 1С

Це зазвичай найтрудомісткіша частина. Стандартний обмін через CommerceML закриває товари, ціни, склади, замовлення. Але не закриває:

• Кредитні лімити та заборгованість — виписується окремим XML або через REST-сервіс 1С. На стороні Бітрикс — кастомний Highload-блок b2b_credit_limits з полями: UF_COMPANY_ID, UF_CREDIT_LIMIT, UF_CURRENT_DEBT, UF_OVERDUE_DEBT, UF_UPDATED_AT
• Документи — рахунки та накладні зберігаються в 1С. Портал запитує список через REST, отримує посилання на PDF або бінарні дані. Кешуємо в /upload/b2b/docs/ з TTL 24 години
• Специфікації — індивідуальні договірні позиції, яких нема в загальному прайс-листі. Синхронізуються окремим форматом, зберігаються в Highload-блоці з прив'язкою до COMPANY_ID

Критично важливо: не ламати стандартний обмін CommerceML. Кастомні поля та логіка — через події OnBeforeCatalogImport1C, OnSuccessCatalogImport1C, окремі таблиці. Ядро обміну не чіпаємо.

Продуктивність під навантаженням

B2B-портал з 500+ активними компаніями та пиковим навантаженням на момент відкриття робочого дня — це інші вимоги, ніж у рітейлового магазину.

• Кеш каталогу — тегований, тег прив'язаний до IBLOCK_ID. CIBlock::clearIblockTagCache($iblockId) при оновленні залишків з 1С очищає лише потрібні сторінки
• Ціни — не кешуються на рівні компонента, якщо персональні. Альтернатива: кеш за ключем user_group_price_{groupId}_{productId}, інвалідація при зміні ціни
• Сесії — при наявності балансувальника між кількома серверами сесії переносяться в Redis, налаштування через \Bitrix\Main\Application::getInstance()->getSession()
• Пошук по каталогу — модуль search не справляється з B2B-фільтрами. Підключається Elasticsearch через кастомний індексатор, який обходить CIBlockElement::GetList і напрямки формує документи для індексу

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

Разом: 12-22 тижні залежно від глибини інтеграції з 1С і кількості кастомних бізнес-правил.

Що часто йде не так

Зберігають персональні ціни в сесії. Працює до перезавантаження PHP-FPM, при балансуванні — втрачаються. Ціни зберігаються в базі або Redis, не в сесії.

Синхронізація 1С блокує сайт. Повний імпорт CommerceML на 50К товарів займає 20-40 хвилин і тримає таблиці на lock. Переходимо на інкрементальний обмін: лише змінені позиції з моменту останньої синхронізації.

Бізнес-процеси узгодження написані в init.php. Логіка узгодження замовлень на 300 рядків у init.php — це технічний борг, який доведеться переписувати при будь-якій зміні правил. Виносимо в окремий модуль з конфігурованими правилами.