Согласование счетов в Битрикс24: из РПА в бизнес-процессы за два дня.

Сеть развлекательных заведений в двух городах - Москве и Санкт-Петербурге. На портале Битрикс24 - 43 сотрудника, от генерального директора до администраторов площадок. Портал живой: CRM работает с июля 2026 года, лиды приходят ежедневно, согласование трат идёт потоком около 33 заявок в неделю.

Согласование жило в РПА ("Роботизация бизнеса") - отдельном инструменте Битрикс24: 10 стадий, роботы на каждой. Цепочка выглядела разумно: заявка, утверждение руководителем, счёт, проверка бухгалтерией, оплата. При разборе выяснилось, что до финала заявки не доходят: 15 штук висели в предпоследней стадии, и формально ни один процесс не был завершён.

Данных в заявке при этом не было. Сумма, поставщик и срок оплаты существовали только внутри приложенного PDF счёта - итог трат за месяц посчитать нельзя, отчётов нет. Город хранился в поле типа "адрес", по которому не сгруппировать, поэтому его дублировали руками в названии заявки. Об отклонении автор не узнавал: заявка молча оседала в стадии "Отклоненные".

Клиент перешёл на тариф "Профессиональный", где доступны бизнес-процессы, и попросил перевести согласование на них: сначала заявки на оплату счетов, следом - месячный бюджет на маркетинг.

• →15 заявок зависли в предпоследней стадии - ни один процесс не был завершён
• →Сумма, поставщик и срок оплаты - только внутри PDF счёта, отчётов по тратам нет
• →Отклонённая заявка оседала молча - автор об этом не узнавал

По датам шаблонов на портале видно: за три недели до нас клиент сам пытался собрать согласование на бизнес-процессах. Правил типовой шаблон "Счет на оплату", завёл второй - и у обоих остался включённым автозапуск: при создании заявки стартовали два процесса одновременно. Завели три тестовые заявки и ушли обратно в РПА.

Для нас это подсказка, где именно людям становится трудно: конструктор бизнес-процессов прощает меньше, чем РПА. Чужие шаблоны мы не удаляли - только выключили им автозапуск, чтобы они не мешали новому процессу.

Первую схему нарисовали со слов клиента - и при сверке со скринами реального РПА она разошлась с фактами в шести местах. Согласующих на первом шаге оказалось двое: финансовый директор и генеральный, решает любой. Существовала отдельная стадия "Ожидает оплаты" с собственным решением, которую в пересказе схлопнули. А директор по маркетингу оказался оператором всего процесса, хотя в рассказе не звучал вовсе.

То же с бюджетом: со слов - один согласующий, по факту - два последовательных, генеральный и затем финансовый директор. Поэтому переносили по настройкам: выгрузили стадии, роботов и поля старого процесса, перенесли логику один в один, а каждое отличие выписали клиенту отдельной таблицей.

Схемы обоих процессов нарисовали в BPMN: дорожки по ролям, поток сверху вниз, влезает в A4 и читается с телефона. Клиент вносил правки по схеме до сборки - это дешевле, чем переделывать собранный процесс.

Основой взяли типовой процесс Битрикс24 "Счет на оплату": в нём уже готовы 13 полей - сумма, валюта, номер счёта, закрывающие документы. Добавили 6 своих и собрали собственный шаблон бизнес-процесса: 19 полей заявки.

Роли перенесли из РПА один в один, включая дублёров: финансовый директор согласует, бухгалтерия проверяет документы и отмечает оплату. На каждом шаге решает тот, кто открыл задание первым, - отпуск одного человека не останавливает процесс.

Прогнали процесс на живом тесте вместе с клиентом, починили всплывшее - и клиент начал заводить реальные заявки.

Перенос один в один - основа. По дороге закрыли то, что в РПА мешало каждый день:

• →Автопроверка счёта: два отдельных файловых поля - перечень товаров и счёт. Если счёт приложен сразу, процесс пропускает ручную стадию, которую раньше проходила каждая заявка
• →Автор узнаёт об отклонении: приходит уведомление "заявка отклонена, свяжитесь с финансовым директором". Раньше - тишина
• →Отклонить без пояснения нельзя: комментарий при отклонении обязателен
• →История решений сохраняется: кто согласовал и с каким комментарием - пишется в поля заявки. Штатно облачный Битрикс24 хранит задания завершённого процесса только сутки
• →Новая стадия после оплаты: сбор закрывающих документов. Раньше всё заканчивалось на "Оплачено"
• →Сумма стала полем - впервые можно посчитать траты за месяц
• →Город стал списком: Москва или Санкт-Петербург, отчёты группируются

Старые заявки доигрывают в РПА, новые заводятся в бизнес-процессе, в день отсечки у РПА снимается право запуска.

Один риск на стыке закрыли правилом. В старых заявках суммы нет - она внутри PDF, поэтому сверить дубли между двумя системами нечем. У бухгалтерии на переходный период правило: два основания на один счёт - платёж стоп.

От первого разбора скринов до процесса, в котором клиент заводит реальные заявки, прошло два дня. Поток около 33 заявок в неделю идёт по новому маршруту, право подать заявку - у всех 43 сотрудников. Второй процесс, месячный бюджет на маркетинг, согласован по схеме и собирается следом.

Если у вас согласование живёт в РПА, в почте или в чатах и итог трат за месяц посчитать нечем - расскажем, как перенести его на бизнес-процессы без потерь. Оставьте заявку - разберём ваш процесс.