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