Розробка особистого кабінету користувача на 1С-Бітрікс

Розробка особистого кабінету користувача на 1С-Bitrix

Клієнт дзвонить менеджеру: «Який статус мого замовлення?», «Надішліть акт звірки за минулий квартал», «Мені потрібен дублікат рахунку». Менеджер лізе в 1С, формує документ, відправляє на пошту. П'ять хвилин на кожен запит, двадцять таких дзвінків на день — півтора години часу на роботу, яку повинен робити особистий кабінет. На 1С-Bitrix ОК будується з готових компонентів, але повноцінний B2B-кабінет з мультипользовательским доступом і інтеграцією з 1С завжди потребує доопрацювання.

Архітектура особистого кабінету

Типовий ОК — розділ сайту /personal/ з набором підрозділів, кожен з яких реалізований компонентом Bitrix або кастомною сторінкою.

Стандартні компоненти:

• bitrix:main.profile — перегляд й редагування профілю
• bitrix:sale.personal.order — список замовлень з детализацією
• bitrix:sale.personal.order.cancel — скасування замовлення
• bitrix:catalog.viewed — переглянуті товари
• bitrix:main.feedback — форма звернення

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

Маршрутизація всередині ОК — через ЧПУ-правила в .urlrewrite.php або комплексний компонент з SEF-режимом. Другий варіант зручніше: усі сторінки ОК управляються з одного місця.

Розмежування прав доступу

Система прав у Bitrix спирається на групи користувачів. Для ОК це виглядає так:

• Зареєстрований користувач — базовий доступ: профіль, свої замовлення
• Оптовий клієнт — оптові ціни, додаткові розділи (дебіторка, акти звірки)
• Контрагент — документи й взаєморозрахунки по своїй організації
• Партнер — реферальна статистика, маркетингові матеріали

Групи призначаються при реєстрації через обробник OnAfterUserRegister або вручну менеджером. Права перевіряються на двох рівнях: файлова система (/personal/b2b/ — доступ лише для групи «Оптовики») і всередині компонентів (фільтрація даних по $USER->GetID()).

Deep-dive: B2B-кабінет з мультипользовательским доступом

Стандартний ОК — один користувач, один акаунт, його замовлення. У B2B від однієї організації працюють закупівельник, бухгалтер, керівник — і кожному потрібен свій набір даних і прав. Це головна архітектурна задача.

Сутність «Організація». Створюється через highload-блок або інфоблок з полями: назва, ІНН, КПП, юридична адреса, умови оплати, кредитний ліміт. Користувачі прив'язуються до організації через користувацьке властивість UF_COMPANY_ID.

Ролі всередині організації:

Адміністратор організації додає співробітників через інтерфейс ОК: відправляє запрошення по email, новий користувач реєструється й автоматично прив'язується до організації з вказаною роллю. Не потрібно дзвонити менеджеру й просити «додайте нашого нового закупівельника».

Технічна реалізація:

• Прив'язка користувач -> організація зберігається в UF_COMPANY_ID або в окремій таблиці зв'язків (для підтримки мультиорганізаційного доступу, коли один людина працює з кількома юрлицами)
• Ролі — окремий highload-блок: user_id, company_id, role
• При авторизації в сесію завантажується контекст організації й роль користувача
• Компоненти фільтрують дані по company_id: закупівельник бачить свої замовлення, адміністратор — усі замовлення організації
• Переключення між організаціями — селектор у шапці ОК

Узгодження замовлення. У великих організаціях замовлення не йде поставщику напрямки:

1. Закупівельник формує замовлення (статус «Чорновик»)
2. Керівник закупівель отримує сповіщення, перевіряє склад і бюджет
3. Узгоджує або повертає на доопрацювання з коментарем
4. Після узгодження замовлення переходить у статус «Підтверджено» й йде в обробку

Реалізується через кастомні статуси замовлення в модулі sale й обробники подій OnSaleOrderBeforeSaved, OnSaleStatusOrder.

Розділи особистого кабінету

Замовлення

Компонент sale.personal.order — список з фільтрацією по статусу, даті, сумі. Детализація: склад, статуси оплати й доставки, трек-номер. Розширення:

• Повторне замовлення — копіювання складу в корзину однією кнопкою
• Рекламація — форма претензії, прив'язана до конкретного замовлення й позиції
• Друковані форми — генерація рахунку, акту, накладної через \Bitrix\Sale\Order::getDocuments()

Документи

Розділ для скачування закриваючих документів: рахунків, актів, рахунків-фактур, УПД. Документи генеруються з модуля sale або завантажуються з 1С через інтеграцію. Зберігання — у прив'язці до замовлення або до користувача через highload-блок.

Для B2B критично, щоб бухгалтер бачив усі документи організації, а не лише свої. Фільтрація по company_id, а не по user_id.

Звернення

Тікет-система: користувач створює звернення, прикладає файли, бачить історію й статус. Реалізація — через модуль support (техпідтримка) або кастомна на інфоблоці / смарт-процесі CRM. Другий варіант зручніше, якщо звернення повинні попадати в CRM й обробляються менеджером у звичному інтерфейсі.

Баланс й взаєморозрахунки

Для B2B-клієнтів: поточний баланс, історія платежів, дебіторська заборгованість. Дані приходять з 1С через REST або файловий обмін. Акт звірки формується за запитом — користувач натискає кнопку, запит йде в 1С, PDF повертається за кілька хвилин.

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

Зв'язка ОК з 1С — обов'язковий елемент для B2B. Стандартний модуль обміну sale + catalog синхронізує каталог й замовлення, але для повноцінного ОК потрібен розширений обмін.

З 1С у ОК:

• Історія замовлень, включаючи оформлені по телефону або через менеджера
• Дебіторська заборгованість по контрагенту
• Акти звірки у PDF
• Персональні ціни й скидки по прайс-листу контрагента
• Статуси відгрузки й оплати

Обмін — через REST API (модуль rest), SOAP-сервіси або CommerceML з розширеною схемою. Для високонавантажених систем дані кешуються у highload-блоках: при запиті користувача ОК читає локальний кеш, а не чекає відповіді від 1С. Синхронізація — по розпорядженню (cron-агент) або за подією (webhook при змінах даних у 1С).

Безпека

ОК працює з персональними даними й фінансовою інформацією. Мінімальний набір заходів:

• HTTPS для всього розділу /personal/
• CAPTCHA або rate-limiting на формі авторизації — захист від перебору
• Двохфакторна аутентифікація через модуль security (OTP)
• Логування дій користувача в модулі «Проактивна захист»
• Автоматичне завершення сесії при бездіяльності (налаштовується в модулі security)
• Для B2B — опціональне обмеження сесії по IP

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

Вартість розраховується після аналізу вимог — занадто великий розкид між «профіль + замовлення» і «мультиорганізаційний B2B-кабінет з узгодженням й інтеграцією з трьома обліковими системами».