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