Есть один разговор, который повторяется почти в каждой компании со сложными расчётами. Спрашиваешь: «Какая у вас маржа по текущим договорам?» Отвечают: «В конце месяца посчитаем».
Это нормальный ответ для бухгалтерии. Но для управления это ответ «мы не знаем». Потому что решения - брать ли следующий заказ, давать ли скидку, хватит ли денег на закупку - принимаются сейчас, а не в конце месяца.
Разберём, почему так выходит, что с этим делать в Bitrix24 и почему расчёт по частям оплат - не бухгалтерская прихоть, а управленческая необходимость. С прицелом на бизнес в Минске и по всей Беларуси.
Почему Excel всегда опаздывает
Классическая схема: сделка закрылась - экономист выгрузил данные, свёл с оплатами и затратами, посчитал маржу. Через две-три недели после факта.
Проблема не в Excel. Excel считает прекрасно. Проблема в том, что расчёт отвязан от момента, когда происходит событие.
Из-за этого возникает несколько неприятных эффектов:
- Убыточная сделка видна постфактум. Когда уже нельзя ни пересогласовать цену, ни отказаться.
- Скидки раздаются вслепую. Менеджер не знает, сколько запаса прочности осталось в конкретной сделке, и торгуется от цены, а не от маржи.
- Дебиторка живёт отдельной жизнью. График платежей - в одной таблице, факт оплат - в другой, сделка - в третьей. Сходятся они раз в месяц, и то не всегда.
- Расчёт зависит от одного человека. Который считает, знает нюансы и однажды уходит в отпуск.
Что ломается конкретно, когда оплата идёт частями
Пока клиент платит один раз и сразу, всё относительно просто: закрыли сделку - посчитали. Как только появляется график платежей, конструкция разваливается.
Непонятно, сколько уже заработано
Сделка на условные 100 тысяч, из них оплачено 40. Какая по ней прибыль? Формально - никакой, сделка не закрыта. Фактически - часть маржи уже получена, и она есть в деньгах компании. Отчёт, который этого не показывает, врёт в обе стороны.
График платежей ведут вручную
Отдельная таблица с датами и суммами. При изменении условий её правят руками - иногда правят, иногда забывают. К третьему месяцу таблица и реальность расходятся, и никто не может сказать, где правда.
Просрочка обнаруживается случайно
Плановый платёж не пришёл. Об этом узнают, когда кто-то решит проверить. Или когда клиент сам позвонит. Или в конце квартала, при сверке. Между «просрочил» и «заметили» проходят недели, за которые долг успевает вырасти.
Остаток долга считают заново каждый раз
Простая арифметика, но выполняемая вручную, в разных таблицах, разными людьми - и потому регулярно с ошибками.
Почему это дорого
Замороженные деньги. Просроченная дебиторка - это ваш оборотный капитал, которым временно пользуется клиент. Бесплатно. Чем позже вы её замечаете, тем дольше это длится.
Убыточные сделки, которые не остановили. Если маржа видна только в конце, компания успевает набрать ещё несколько похожих сделок на тех же условиях.
Скидки не по делу. Без понимания маржи менеджер защищает цену, а не прибыль. Иногда он отдаёт пять процентов там, где было можно ноль, - и наоборот, упирается там, где скидка окупилась бы объёмом.
Управленческие решения по ощущениям. Самое дорогое. Когда цифры приходят с задержкой в месяц, руководитель начинает опираться на интуицию - и обычно она смещена в сторону оптимизма.
Как это решается: платёж как отдельная сущность
Ключевая идея - перестать считать платёж атрибутом сделки и сделать его самостоятельным объектом со своим жизненным циклом: план → факт → закрытие.
Технически это делается на смарт-процессах. Каждый плановый платёж - отдельный элемент со своей датой, суммой, статусом и связью со сделкой. Тогда система может с ним работать: напоминать, пересчитывать, подсвечивать.
В одном из наших проектов компания с оплатой по графику считала маржинальность вручную в Excel уже после закрытия сделки, и руководитель не видел реальную прибыль по текущим договорам. Механика решения (детали - в кейсе про расчёт маржи по частям оплат):
| Что происходит | Что делает система | Что получает бизнес |
|---|---|---|
| Менеджер запускает график платежей по сделке | Создаётся нужное количество плановых платежей на нужные даты и суммы | График не нужно вести в отдельной таблице |
| Приходит фактический платёж | Фиксируется сумма, пересчитывается остаток долга и маржа по оплаченному | Маржа известна в день оплаты, а не в конце месяца |
| Наступает дата планового платежа | Ответственному ставится напоминание, просрочки подсвечиваются отдельно | Просроченная дебиторка не теряется из вида |
Обратите внимание на третью строку. Она про то, что просрочку не надо искать - она сама себя показывает.
Что нужно решить до настройки
Техническая часть здесь простая. Сложная часть - договориться внутри компании о правилах счёта. Без этого автоматизация просто ускорит спор о том, чья цифра правильная.
Что входит в себестоимость. Только закупка? Плюс доставка? Плюс работа своих сотрудников? Плюс аренда и общие расходы? Правильного ответа нет, есть решение компании - но оно должно быть одно.
Откуда берётся себестоимость. Заносится менеджером руками, подтягивается из учёта, считается по нормативу. Каждый вариант рабочий, но у каждого своя цена в точности и в дисциплине.
Что считать датой оплаты. Дата платёжного поручения, дата поступления на счёт, дата разнесения бухгалтером. Разница в днях, но на границе месяца она принципиальна.
Как учитывать частичные платежи в разрезе позиций. Оплата закрывает сделку пропорционально или сначала гасит конкретные позиции? От этого зависит, как считается маржа по каждому поступлению.
Эти вопросы стоит разобрать до старта - примерно так же, как при подготовке технического задания на внедрение CRM.