Розробка кастомних процесів узгодження Бітрікс24

Розробка користувацьких процесів узгодження Bitrix24

Стандартний конструктор бізнес-процесів Bitrix24 закриває прості лінійні маршрути. Договір на узгодження: юрист → фінансовий директор → генеральний. Це працює. Але бізнес складніший: сума договору визначає, хто узгоджує; юрист у відпустці — передати заступнику; кілька узгоджувачів одночасно, і потрібно не менше двох «за»; при відхиленні — автоматичний повернення ініціатору з коментарем та лічильником ітерацій. Ось де починається користувацька розробка.

Коли стандартного конструктора недостатньо

Штатний дизайнер БП Bitrix24 має обмеження: складні умовні маршрути (більше 3–4 розгалужень) перетворюються на нечитаємий схему. Динамічні учасники (список узгоджувачів визначається на ходу, виходячи з даних документа) вимагають PHP-коду в блоці «Виконати код». Інтеграція з зовнішніми системами (отримати дані з ERP, записати результат у 1С) — тільки через HTTP-запити з того ж блока. Версіонування процесів (старі запущені екземпляри працюють за старою версією, нові — за новою) відсутнє.

Користувацьке рішення будується на одному з двох фундаментів:

• Розширений БП в дизайнері — додаємо користувацькі activity-блоки, які реалізують потрібну логіку
• Смарт-процеси CRM — використовуємо як контейнер для узгодження з роботами та тригерами
• Повністю користувацький додаток — власна система узгодження, інтегрована з Bitrix24 через REST API

Користувацькі activity-блоки

Activity — це PHP-клас, який реалізує \Bitrix\Bizproc\Activity\Base. Він з'являється в дизайнері БП як стандартний блок, але містить довільну логіку.

Структура користувацької activity:

class SendToErpActivity extends \Bitrix\Bizproc\Activity\Base
{
    public function execute(\CBPActivity $activity): \CBPActivityExecutionStatus
    {
        $dealId = $activity->getDealId(); // отримуємо параметр з БП

        $erpClient = new ErpApiClient();
        $result = $erpClient->createApprovalRequest($dealId);

        if ($result->isSuccess()) {
            $activity->setVariable('ERP_REQUEST_ID', $result->getId());
            return \CBPActivityExecutionStatus::Closed;
        }

        // Помилка — можемо повернути Faulting для обробки в БП
        return \CBPActivityExecutionStatus::Faulting;
    }
}

Блок реєструється у bitrix/activities/ або /local/activities/. Після реєстрації з'являється в дизайнері як стандартний елемент і підтримує налаштування параметрів через форму.

Динамічні учасники

Список узгоджувачів, що визначається даними документа — частий запит. Наприклад: сума угоди до 500 000 рублів — узгоджує керівник відділу, від 500 000 до 2 000 000 — плюс фінансовий директор, вище — плюс генеральний. І це для кожного підрозділу своя матриця.

Реалізація: activity-блок «Визначити узгоджувачів» обчислює список користувачів на основі даних документа та таблиці повноважень. Таблиця повноважень зберігається в HL-блоці або окремій таблиці в БД. Результат — масив user_id, який передається в наступний блок «Узгодження» як параметр.

// HL-блок "Повноваження узгодження"
// Поля: DEPARTMENT_ID, AMOUNT_FROM, AMOUNT_TO, APPROVER_USER_ID, APPROVER_ROLE
$approvers = ApprovalMatrixTable::getList([
    'filter' => [
        'DEPARTMENT_ID' => $departmentId,
        '<=AMOUNT_FROM' => $amount,
        '>=AMOUNT_TO' => $amount,
    ],
]);

Заступники та делегування

Узгоджувач у відпустці або в командировці — процес не повинен висіти. Два варіанти:

Автоматичне делегування. Перед відправкою завдання на узгодження перевіряємо статус користувача (через user.get або через користувацьке поле профілю «замішує»). Якщо користувач відсутній — завдання йде заступнику.

Делегування за істечення часу. Якщо завдання не виконане за X годин — теж йде заступнику. Реалізується через блок «Пауза» в БП + умова: якщо завдання не виконане до моменту закінчення паузи — перехід за гілкою делегування.

Матрицю заміщення ведемо в HL-блоці: USER_ID, SUBSTITUTE_USER_ID, DATE_FROM, DATE_TO. Activity-блок перевіряє актуального заступника на момент запуску.

Паралельне узгодження з порогом

Три узгоджувачи одночасно, достатньо двох «за»:

[Паралельний блок]
  ├── Завдання: Узгоджувач 1
  ├── Завдання: Узгоджувач 2
  └── Завдання: Узгоджувач 3
[Блок очікування: 2 з 3 завершені з результатом "Узгоджено"]
[Умова: результат?]
  ├── Так → Наступний етап
  └── Ні → Відхилено

У стандартному дизайнері це реалізується через «Паралельну активність» + користувацьку activity «Агрегація голосів». Activity стежить за накопленням відповідей у змінній БП та повертає Closed тільки коли поріг досягнуто.

Історія узгодження та аудит

Кожна дія узгоджувача (затвердив, відхилив, повернув на доробку) фіксується:

• У коментарі до документа через crm.timeline.comment.add
• У користувацькому полі історії (багаторядковий текст з append)
• У окремому HL-блоці «Історія узгоджень» з полями: дата, користувач, дія, коментар, версія документа

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

Ескалація та SLA

Для кожного етапу встановлюємо SLA (час виконання). Якщо термін порушено:

1. Сповіщення самому узгоджувачу («Ви не відповіли на запит узгодження, термін істік»)
2. Сповіщення його керівнику («Ваш підлеглий не узгодив документ вчасно»)
3. По істечені другого порога — автоматичне рішення за замовчуванням (автоматичне затвердження або ескалація вище)

Реалізується через агенти Bitrix або через планувальник у користувацькому додатку.

Інтеграція з зовнішніми системами в процесі

При запуску узгодження та при зміні статусу — сповіщення зовнішніх систем:

• 1С:ЕДО — при остаточному узгодженні відправляємо документ у систему електронного документообігу
• ERP — при затвердженні договору на постачання створюємо замовлення постачальнику
• Email/Telegram — сповіщення зовнішнього контрагента («Ваш договір узгоджено»)

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

Зріла система узгодження — це не налаштований БП в дизайнері, а сукупність користувацьких блоків, правил маршрутизації та аудитної бази. Така система живе роками і вимагає мінімального втручання при зміні бізнес-правил — достатньо оновити таблицю повноважень.