Производственная компания с длинным циклом сделки. Договор подписывается на сумму, а деньги приходят частями — аванс, платёж после отгрузки партии, остаток по факту. Между первым платежом и последним проходит несколько месяцев.
Вопрос, с которого всё началось, звучал так: «Мы вроде работаем, оборот растёт, а денег больше не становится. Где-то теряем, но где — не видим».
Как это было устроено
В 1С была бухгалтерия: счета, платёжки, отгрузки. В Битрикс24 — продажи. Между ними ходил финансист с таблицей.
Таблица была неплохая, надо отдать должное. График платежей по каждому договору, отметки о поступлениях, формулы для остатка долга. Проблема была не в качестве таблицы, а в том, что она существовала отдельно от всего остального и обновлялась руками.
Маржу считали в конце месяца. Брали закрытые сделки, поднимали себестоимость, вычитали, получали цифру. Цифра была правильная и бесполезная: к моменту её появления решения по этим сделкам были приняты полтора месяца назад.
Из чего складывалась проблема
Долг пересчитывали вручную. Пришёл платёж — финансист открывает таблицу, находит строку, вычитает, сохраняет. Двадцать сделок в работе — двадцать строк, которые нужно держать в актуальном виде. Одна пропущенная — и клиенту либо звонят с напоминанием об уже оплаченном, либо не звонят о неоплаченном.
Прибыль была видна постфактум. Менеджер закрывал сделку и не знал, заработала на ней компания или нет. Скидку он давал, ориентируясь на «вроде нормально», потому что реальной маржи по конкретной сделке в момент переговоров никто не видел.
Оплаты и сделки жили порознь. В 1С деньги пришли, в CRM сделка всё ещё на прежней стадии. Менеджер узнавал об оплате, когда спрашивал бухгалтерию.
Про просрочку узнавали случайно. Не было механизма, который сам скажет «этот платёж должен был прийти неделю назад». Узнавали, когда кто-то вспоминал проверить.
Во что это обходилось
Первое — скидки. Когда менеджер не видит маржу, он торгуется вслепую. Отдельные сделки уходили с прибылью, близкой к нулю, и никто этого не замечал до конца месяца. Компания при этом считала эти сделки успешными: оборот же есть.
Второе — кассовые разрывы. Без живого платёжного календаря планирование сводилось к «вроде на следующей неделе должны заплатить». Пару раз это заканчивалось тем, что деньги на закупку сырья приходилось искать срочно.
Третье — время финансиста. Ведение таблицы и сверка с 1С — это не разовая работа, а фон, который занимает часть каждого дня.
Что мы сделали
Ключевое решение было не техническим: договорились, что платёж — это самостоятельный объект, а не строка в таблице и не поле в сделке. У него есть плановая дата, сумма, статус, связь со сделкой и своя история.
Завели платёжный календарь смарт-процессом. Каждый платёж по договору — отдельная запись со стадиями: запланирован, ожидается, поступил, просрочен. Все платежи по сделке видны из её карточки, все платежи компании — на одной доске.
Настроили фиксацию поступлений. Оплата, проведённая в 1С, приходит в Битрикс24 и закрывает соответствующий платёж. Остаток долга по сделке пересчитывается сам — никто ничего не вычитает руками.
Собрали расчёт маржи по частям оплат. Это была основная разработка. Маржа считается не «по сделке целиком в конце», а нарастающим итогом: сколько денег уже поступило, какая часть себестоимости на них приходится, какая прибыль зафиксирована на сегодня. Менеджер видит эту цифру в карточке в момент разговора о скидке.
Добавили напоминания. За несколько дней до плановой даты ответственный получает задачу. Просроченный платёж подсвечивается на доске и уходит в отчёт руководителю.
Построили BI-отчёт. Маржа по направлениям, по менеджерам, по клиентам. Плюс платёжный календарь на период — что и когда должно прийти.
Чего это стоило
65 часов и около шести недель.
Самой трудоёмкой частью оказался не расчёт, а договорённость о методике. Что считать себестоимостью сделки — только материалы или с распределением накладных? Как учитывать частичную отгрузку, когда деньги пришли за одну партию, а расходы понесены на всю? Что делать с возвратами?
Мы задали эти вопросы на первой встрече и получили три разных ответа от трёх человек. Это нормально и встречается почти всегда — но пока методика не зафиксирована на бумаге, программировать нечего. На согласование ушло больше времени, чем на саму разработку.
Второй момент: пришлось заполнить себестоимость по действующей номенклатуре. Без неё расчёт возвращал бы красивые нули. Эту работу делал заказчик.
Что из этого вынести
Формулировка «мы не видим, где теряем деньги» почти всегда означает не отсутствие данных, а их разрозненность. Всё нужное у компании было: суммы в CRM, платежи в 1С, себестоимость в номенклатуре. Не было только места, где это сходится в одну цифру в нужный момент.
И отдельно про момент. Маржа, посчитанная в конце месяца, — это отчётность. Маржа, видная менеджеру во время переговоров о скидке, — это инструмент. Считается одинаково, стоит по-разному.