Вместо 4000+ условий в Bitrix24 я сделал отдельное приложение.

Клиент занимается временным хранением автомобилей и другой техники. Вся работа идёт в Bitrix24: сделки, контрагенты, даты поступления и выдачи. Там же должна автоматически появляться стоимость хранения, которую потом выставляют заказчику.

Если очень упростить, задача звучит смешно: машина приехала, постояла, мы посчитали дни и получили сумму. Казалось бы, чего тут вообще разрабатывать.

А потом открываешь реальные условия.

У клиента 11 видов груза, несколько крупных контрагентов, у каждого свои бесплатные дни и свои тарифы. Стоимость хранения прогрессивная: чем дольше техника стоит на складе, тем дороже могут становиться следующие сутки. Есть праздничные дни, которые вообще не должны попадать в платный период. И всё это нужно ежедневно считать для сотен сделок.

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

Только считало это всё не очень.

На большей части сделок стоимость оставалась нулевой. Счётчик мог начать расти ещё во время бесплатного периода. Праздники вроде бы находились, но потом результат перезаписывался следующими действиями. В одном из полей вместо количества дней вообще могло появиться прекрасное значение «9+1».

А часть расчёта была накопительной: вчера что-то насчитали, сегодня сверху добавили ещё. Если вчера ошиблись — поздравляю, сегодня считаем уже от неправильной суммы.

И всё бы ничего, если бы мы считали количество отправленных писем или какой-нибудь внутренний KPI. Но здесь результат расчёта — это реальные деньги, которые компания должна получить за хранение.

Можно было всё переделать на бизнес-процессах. Я даже посчитал

Проект начался с аудита. Я разобрал существующие БП, поля сделок, стадии, тарифы, бесплатные дни, праздники и сам принцип расчёта.

Сначала действительно была мысль: ладно, сейчас нормально перепишем бизнес-процессы и разойдёмся.

А потом я разложил всю логику по вариантам.

Если делать её классическими ветками Bitrix24 — с контрагентами, 11 видами груза, тарифными ступенями и остальными условиями — получится больше 4000 веток.

Четыре тысячи.

Сделать можно. Я вообще много чего могу сделать в Bitrix24, вопрос только — зачем.

Потому что потом у одного контрагента поменяется тариф. Добавится ещё один вид груза. Появится новое исключение. Через полгода кто-нибудь откроет этот бизнес-процесс, увидит перед собой дерево размером с карту московского метро и аккуратно закроет вкладку.

А самое весёлое начнётся, когда бухгалтер спросит: «А почему по этой машине такая сумма?»

И нужно будет выяснить, через какую именно комбинацию из этих условий прошла конкретная сделка.

Вот в этот момент я решил, что хватит мучить Bitrix24.

CRM оставили заниматься тем, для чего она здесь действительно нужна: хранить сделки, компании, стадии и данные сотрудников. А расчёт денег я вынес в отдельное приложение.

Bitrix24 снаружи, нормальная математика внутри

Для сотрудников ничего принципиально не поменялось. Никому не пришлось учиться работать в ещё одной системе или держать рядом очередную таблицу.

Сотрудник как обычно ведёт сделку в Bitrix24: выбирает контрагента и вид груза, указывает дату поступления автомобиля, двигает сделку по стадиям, а при выдаче ставит фактическую дату.

Дальше приложение всё делает само.

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

1. сделка в Bitrix24
2. условия контрагента
3. бесплатный период
4. минус праздники
5. ступени тарифа
6. сумма → обратно в сделку

Тарифы при этом больше не спрятаны где-то на 2743-й ветке бизнес-процесса. Они хранятся отдельно и нормально редактируются. Нужно изменить условия конкретного контрагента — меняем условия конкретного контрагента, а не идём с фонариком внутрь огромной схемы.

Сам принцип расчёта я тоже поменял. Никакого «вчера было 50 000 ₽, сегодня добавим ещё 3 000 ₽». Каждый раз приложение берёт исходные данные сделки и считает стоимость заново.

Исправили дату — пересчиталось. Изменились исходные данные — пересчиталось. Ошибка не тянется дальше просто потому, что когда-то уже успела попасть в поле.

Получается чуть менее «магически», зато сильно надёжнее. Я вообще за такую магию.

«А почему здесь столько денег?»

Отдельно хотелось решить ещё одну вещь, которую я очень не люблю в автоматизации: когда система выдаёт пользователю готовое число и предлагает просто в него поверить.

Особенно если это число — деньги.

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

То есть если в Bitrix24 стоит определённая сумма, её можно разложить обратно до конкретных дней и ставок.

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

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

Поэтому перед заморозкой приложение делает финальный расчёт по актуальным данным, записывает его в Bitrix24 и проверяет, что запись действительно прошла. Только после этого сумма фиксируется.

Потому что «мы у себя всё посчитали» и «правильная сумма действительно записалась в CRM» — немного разные вещи.

Сначала приложение пять дней считало деньги и никому их не показывало

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

Поэтому примерно пять дней приложение работало в shadow-режиме. Оно забирало реальные сделки, выполняло настоящий расчёт, вело журнал — и ничего не записывало обратно в Bitrix24.

Сначала считаем.
Потом сравниваем.
Потом включаем.

На первой большой сверке получили расхождения примерно в 410 сделках из 413.

Выглядело бодро.

Можно было закрывать ноутбук и идти осваивать новую профессию.

Но начали разбирать сделки вручную и выяснили, что на большей части из них старые бизнес-процессы вообще не записали стоимость. Там стоял ноль.

То есть новое приложение было не с чем сравнивать: эталон, относительно которого мы собирались проверять новый расчёт, сам не работал.

В итоге взяли реальные сделки и руками прошли расчёт по тарифам и датам. После сверки приложение переключили в боевой режим, а старые БП отключили. Не удалили — просто выключили. Я люблю возможность откатиться больше, чем красивые истории о том, как всё заработало с первого раза.

Потом 415 сделок превратились в 1200+

На старте приложение обрабатывало около 415 активных сделок. Через две недели их стало больше 1200.

Сама математика от этого особенно не напряглась. Зато напрягся Bitrix24.

При массовом обновлении большого количества сделок мы упёрлись в ограничения REST API. А первая версия быстрой проверки ещё и умудрялась реагировать на собственные изменения: приложение обновило сделку, увидело, что сделка изменилась, снова её пересчитало и снова обновило.

На десяти сделках — забавно. На тысяче — уже нет.

Bitrix24 в какой-то момент просто ограничил метод обновления, и пришлось перестраивать механику уже исходя не из документации, а из того, как портал ведёт себя под реальной нагрузкой.

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

Новые сделки и важные изменения при этом по-прежнему подхватываются примерно в течение минуты, а ночью проходит полный контрольный пересчёт.

Это, кстати, хороший пример того, почему я не очень люблю оценивать подобные задачи словами «там же просто формула».

Формула действительно простая.

Сделать так, чтобы эта формула каждый день правильно считала деньги на 1200+ живых сделках, переживала ошибки API, изменения данных, параллельные процессы и при этом могла объяснить каждый свой результат — уже немного другая работа.

Что получилось

За три недели три проблемных бизнес-процесса превратились в отдельное приложение, которое само получает данные из Bitrix24, рассчитывает стоимость хранения и возвращает результат обратно.

Сейчас оно работает с 1200+ активными сделками, 11 видами груза и индивидуальными условиями нескольких крупных контрагентов. Новые сделки подхватываются в течение минуты, ночью проходит контрольный пересчёт, окончательная стоимость фиксируется при завершении хранения, а любую сумму можно открыть и проверить до конкретных дней и тарифов.

При этом для сотрудников ничего не стало сложнее. Они как работали в Bitrix24, так там и работают. Просто вместо трёх БП и потенциальных 4000+ веток условий за расчёт теперь отвечает отдельный инструмент.

И вот это как раз тот тип проектов, который мне нравится.

Не «внедрить Bitrix24 ради внедрения Bitrix24» и не пытаться доказать, что любую задачу можно решить роботами. Bitrix24 — хорошая база. Сделки, CRM, автоматизация, API — всё на месте. А дальше к нему можно нормально дописывать то, чего конкретному бизнесу не хватает.

У меня на сайте это сформулировано проще: Bitrix24 — это только начало.

Здесь буквально так и получилось.

Если стандартного функционала достаточно — отлично, не надо ничего изобретать. Если задача превращается в бизнес-процесс на 4000+ условий, значит, пора остановиться и подумать, действительно ли бизнес-процесс — лучший инструмент.