Разработка кастомных процессов согласования Битрикс24

Разработка кастомных процессов согласования Битрикс24

Стандартный конструктор бизнес-процессов Битрикс24 закрывает простые линейные маршруты. Договор на согласование: юрист → финансовый директор → генеральный. Это работает. Но бизнес сложнее: сумма договора определяет, кто согласует; юрист в отпуске — передать заместителю; несколько согласующих одновременно, и нужно не менее двух «за»; при отклонении — автоматический возврат инициатору с комментарием и счётчиком итераций. Вот где начинается кастомная разработка.

Когда стандартного конструктора недостаточно

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

Кастомное решение строится на одном из двух фундаментов:

• Расширенный БП в дизайнере — добавляем кастомные activity-блоки, которые реализуют нужную логику
• Смарт-процессы CRM — используем как контейнер для согласования с роботами и триггерами
• Полностью кастомное приложение — собственная система согласования, интегрированная с Битрикс24 через 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. По истечении второго порога — автоматическое решение по умолчанию (автоматическое одобрение или эскалация выше)

Реализуется через агенты Битрикс или через планировщик в кастомном приложении.

Интеграция с внешними системами в процессе

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

• 1С:ЭДО — при финальном согласовании отправляем документ в систему электронного документооборота
• ERP — при одобрении договора на поставку создаём заказ поставщику
• Email/Telegram — уведомление внешнего контрагента («Ваш договор согласован»)

Этапы разработки

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