Кейсы

Как enterprise-компания стабилизировала финансовые заявки и права доступа

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

Ключевые тезисы

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

Контекст

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

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

Схема правил финансовых заявок и прав доступа
Схема правил финансовых заявок и прав доступа

Задача

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

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

Разобрать похожий проект с архитектором

Решение

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

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

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

Результат

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

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

Разобрать похожую задачу: Как enterprise-компания…

Отправить через: