Обзор подсистемы - финансы

Система управления финансами.

Ядром этой подсистемы является обработка - платежный календарь

Платежный календарь у нас строится на основании данных об остатках из управленческого счета. Также берутся плановые поступления либо расходы из бюджета и сюда же добавляются по мере создания заявок на оплату. Отщепляем кусочки от бюджета и передаем их в заявки на оплату.

Как это все происходит? Заходим в заявки на оплату - создаем новую.

Например, мы платим с предприятия САБ на контур 2 тысячи рублей.

Дальше у нас идет подсветка, что в бюджете у нас по данному предприятию 75 тысяч. Почему 75 тысяч?

Потому что бюджетировали мы на октябрь по статье оплата поставщикам 100 тысяч

Однако из-за того что у нас предыдущие две заявки на 10-15 тысяч уже съели лимит по статье, соответственно новая заявка у нас она подсвечивает доступный лимит 75 тысяч

Cтартуем заявку на исполнение.

Исполнение заявки это не значит факт самой оплаты, а это значит команда на оплату от казначея. То есть это значит, после того, как мы стартанули заявку, возвращаемся в платежный календарь, мы видим, что у нас на сегодня заявлена оплата 2000 по заявке.

И ушла часть бюджета. Было 75, стало 73. То есть мы вот этой обработкой можем строить прогнозные остатки на конец месяца и, соответственно, управлять финансированием.

То есть мы можем тут переносить оплату на следующий день, дробить оплату, допустим по 1000 мы раздробим ее 27 число и можно опять же собрать ее вместе. И соответственно, мы тем самым управляем остатками.

Это у нас функционал казначея, которому ввалится пул этих заявок, на основании этих заявок, как только он направлялся, скажем так, финансированный через платежный календарь, собрал платежи текущего дня и дает команду платить. Что значит дает команду? Это создание сводного реестра, который включает все платежи на текущий день и который опять же можем мы согласовать.

Но как правило сводный реестр - платежи согласуются с финансовым директором. Сразу на исполнение пускай у нас идет. Исполнение сводного реестра это у нас операционисты. Если у нас несколько операционистов, то мы можем каждого операциониста закрепить за конкретным расчетным счетом организации. В данном случае у нас один операционист, один расчетный счет. Нажимаем “Стартовать и закрыть”

После того, как мы стартанули, сумма ушла из платежного календаря, остался у нас бюджет, но она ушла не совсем до конца. Мы можем увидеть в режиме и увидеть развернуто на исполнении реестры. То есть мы видим остаток рабочий и остаток на начало рабочий. Они еще у нас не исполнены, они не выгружены в клиент банк, оплаты по ним фактически не было, но они у нас здесь дополнительно могут быть показаны.

Вернем настройки текущие. Вот здесь у нас 463 тысячи уже, то есть с учетом созданных реестров платежей.

Дальше уже работа операциониста. Операционист поступает на начальную страницу задачка – “оплатить по реестру”

Заходит в эту задачу. Вот здесь можно увидеть в печатной форме, также есть здесь команда документов

Но это больше не задача операциониста, это больше задача некого финансового отдела контроля, либо же казначея.

Это проверка соответствия бюджету.

Здесь мы видим, текущий актуальный план, текущая заявка, факт всего с учетом предыдущих заявок.

И видим остаток опять же, который мы видели в платежном календаре

Вот таким образом операционист у нас формирует платежи.

В принципе у нас один платеж. Нажимаем

Автоматически открывается обработка выгрузки клиент-банка один у нас расчетный счет, но их также может быть несколько, все это работает и по нескольким расчетным счетам

И выгружаем в клиент-банк

Соответственно затем мы загружаем за предыдущий период выписки из клиент-банка и мы получаем факт движения ДДС, который мы можем обработать по статьям. Но у нас уже есть загруженная заявка на вот эти 10 тысяч.

В факте она будет выглядеть вот таким образом. Тут у нас сценарий, выбираем отчет о ДДС. Месяц октябрь. Формируем. Вот наш план, который мы можем также здесь расшифровать.