# Кейс enterprise-компании - правила финансовых заявок

Canonical: https://www.kt-team.ru/cases/enterprise-finance-request-rules

Source: https://www.kt-team.ru/cases/enterprise-finance-request-rules

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

![Схема правил финансовых заявок и прав доступа](/assets/original/enterprise-finance-request-rules.svg)

- **1 блокер:** закрыт сценарий, в котором заявка не переходила в финальный статус
- **3 правила:** уточнены тип заявки, региональная доступность и фильтрация бюджетных строк
- **2 уровня доступа:** разделены права на строки бюджета и изменение суммы перед оплатой

## Контекст

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

## Задача

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

## Решение

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

- Разделили тип заявки и способ оплаты.
- Добавили региональное ограничение для недоступных платежных сценариев.
- Зафиксировали обязательную причину изменения суммы перед оплатой.

## Результат

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