Финансовые ворота
Два железных правила из ТЗ («Финансовые "ворота"»), закрывающие 90 % проблем с деньгами:
- «Без ТЗ — нет денег». Финансовый отдел не запускает оплату по проекту, пока в CRM нет утверждённого ТЗ.
- «Без учёта расходов — нет оплаты». Счёт в чате не основание для платежа: расход должен быть заведён в системе и привязан к проекту.
Правила проверяются на сервере при создании платежа, а не только в интерфейсе.
Что считается обоснованием расхода
POST /api/v1/payments с direction=outgoing требует хотя бы одно из:
| Поле | Что это |
|---|---|
cost_item_id | Статья затрат проекта (project_cost_items) |
obligation_id | Позиция реестра обязательств или постоянный платёж |
allocations[] | Разнесение по выставленным документам |
Иначе — 400 payments_expense_required. Несуществующая ссылка отвечает payments_cost_item_not_found или payments_obligation_not_found с указанием поля.
Входящие платежи не блокируются: запрещать приём денег от клиента смысла нет.
Исключение — выплата зарплаты. Платёж, созданный доменной логикой при выплате утверждённой ведомости, обоснован самой ведомостью: у него нет статьи затрат, и правило к нему не применяется. Поле Internal заполняется только внутри системы, из HTTP его передать нельзя.
Проверка утверждённого ТЗ
Для каждого проекта, к которому относится платёж (через статью затрат, обязательство или документ), проверяется projects.has_approved_spec. Если ТЗ не утверждено — 409 payments_spec_required, в сообщении названо имя проекта.
Платежи вне проектов (аренда офиса, налоги, постоянные платежи без проекта) этим правилом не затрагиваются.
Мини-ТЗ для срочных работ
ТЗ допускает упрощённый путь: «Даже для срочных задач создается упрощенное Мини-ТЗ».
POST /api/v1/projects/:id/specs/express с обязательным comment создаёт сразу утверждённую версию ТЗ:
meta.express = true,meta.comment— причина;- версия видна в общем списке ТЗ и в аудите (
project.spec_express_created); - проект получает
has_approved_spec = true, и оплата разблокируется.
Без причины — 400 projects_spec_comment_required. Право то же, что на ведение карточки проекта: запись project_card в матрице прав.
Мини-ТЗ — это не обход правила, а его облегчённое исполнение: причина остаётся в истории, и по ней видно, какие проекты запускались в оплату без полноценной сметы.
История сделок поставщика
GET /api/v1/suppliers/:id/deals — лента работы с поставщиком (ТЗ, справочник «Поставщики»: «Контактные данные, реквизиты, история сделок»), новые записи первыми, канонический конверт списка.
kind | Что это | Сумма |
|---|---|---|
equipment | Оборудование поставщика в каталоге | Стоимость единицы |
logistics | Логистическая операция, в которой участвовало его оборудование | Фактическая или плановая стоимость операции |
У каждой строки есть дата, проект (если есть) и статус.