суббота, 24 сентября 2016 г.

Реализация платежного календаря


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

Платежный календарь “как по договору” у нас ведется в 1С. Для этого мы пользуемся штатными средствами 1С, такими как “Планируемое поступление ДС” и “Заявка на расходование ДС”. Я не знаю предприятия, в котором фактические платежи осуществляются строго по запланированному месячному календарю от и до, поэтому платежный календарь “на каждый день” мы ведем в Гугл Таблице. Реализовано это несложно. План на месяц изначально составлялся в Таблице. Переход в облако упростил процесс планирования. Раньше каждый сотрудник планировал свою часть в своей таблице Excel, потом все это куда-то пересылалось, корректировалось, объединялось. Сейчас все делается в одной Гугл Таблице в разграниченным по листам доступом и сводным листом. В нужный момент доступ всем отключается и сводные данные переносятся в платежный календарь. Вид плановой таблицы я приведу ниже.


Факт в платежный календарь заливает специально обученный человек. Чтобы упростить и максимально автоматизировать эту задачу был создан специальный отчет в 1С под формат Таблицы. Программиста для этого нанимать не обязательно, это можно сделать SQL-запросом в “консоли отчетов” 1С. Останавливаться не буду подробно, потому что во-первых, структура запроса зависит от конкретной конфигурации 1С, во-вторых, если Вы только начали внедрять похожую схему можно сформировать Таблицу под имеющийся в 1С отчет (пишите мне, если есть вопросы, попробую ответить). Из отчета данные переливаются легко и быстро, нажатием комбинаций клавиш Ctrl-C, Ctrl-V. Вот так выглядит лист “Факт”


Поскольку мы делаем не “для галочки” нужно убедиться, что данные правильные. Для этого надо сверить остатки. Их мы ведем на соседнем листе “Остатки”




Считаются они автоматически следующей формулой многофакторного суммирования (для ячейки C10):
=SUMIFS('Факт'!$E:$E;'Факт'!$B:$B;'Остатки'!$C$1;'Факт'!$A:$A;'Остатки'!A10)+C9
То есть, мы суммируем все значения в колонке E на листе “Факт”, у которых расчетный счет (значение в колонке B на листе “Факт”) совпадает с указанным в заголовке (ячейка C1) и дата совершения операции (значение в колонке A на листе “Факт”) совпадает с указанной в строке (ячейка A10). Полученная сумма это оборот по счету за день и нам надо прибавить остаток на предыдущий день (ячейка C9). В Excel есть аналогичная функция многофакторного суммирования - СУММЕСЛИМН().


Основной целью платежного календаря является планирование и предотвращение кассовых разрывов. Для этого составляется так называемый бюджет движения денежных средств - БДДС. Фактически, это подневной план остатков на расчетных счетах. Выглядит он примерно так




Изначально он формируется на основании поданных планов на месяц. Теперь надо сделать так, чтобы он пересчитывался в соответствии с фактически совершенными платежами и поступлениями. Причем пересчет должен быть автоматическим, потому что любые ручные операции это источник человеческого фактора. Для этого остаток на утро мы формируем формулой (для ячейки B9)
=IF(A9>'Отчет'!$B$4;E8;'Остатки'!B9)
В Excel эта функция называется ЕСЛИ(). Если дата строки в БДДС больше установленной текущей даты (лист “Отчет” ячейка B4) - остаток на утро берется плановый, если дата равна текущей или меньше - то остаток берется по факту. Таким образом, при внесении факта и установки текущей даты, БДДС до конца месяца пересчитывается автоматически (уже при написании блога возникла идея скрипта, который при появлении отрицательных остатков будет автоматически рассылать тревожные письма кому надо).


Важнейшей функцией платежного календаря является то, что он является инструментом контроля платежной дисциплины. Приведенных таблиц для этого недостаточно. Например, нам вовремя не оплатил клиент как было запланировано, из-за этого нам не хватило денег оплатить нашему поставщику очередной платеж. Если мы посмотрим на фактический остаток (около нуля) то он будет практически равен плановому. Хотя очевидно, что ситуация не соответствует плановому сценарию. У финансового директора должен быть инструмент, позволяющий ему оперативно увидеть, что имеются отклонения по поступлению денег от клиентов и эти отклонения покрыты за счет денег, запланированных на ключевых поставщиков. Сейчас я расскажу как это сделать.


В первую очередь для этого нам нужен ключ - дополнительная аналитика, позволяющая различать платежи. В моем бизнесе этой аналитикой является сделка. Мы со всеми контрагентами ведем учет по сделкам, для этого ведем в 1С документы “Заказ покупателя” и “Заказ поставщика” и привязываем к ним план и факт платежей. В платежном календаре план поступлений на листе “Поступления” выглядит так




Сначала поясню таблицу, которая начинается в девятой строке. Первые пять колонок копируются исполнителями из 1С при планировании календаря на месяц. В колонке “Просрочено” стоит простая формула (для ячейки F10):
=IF(D10<$B$2;1;0)
и условное форматирование. Если дата поступления позже даты отчета (ячейка B2), то ставится ноль, если дата поступления раньше - ставится единица и клетка закрашивается в красный цвет. В колонке Оплачено стоит формула (для ячейки E10):
=SUMIFS('Факт'!E:E;'Факт'!C:C;'Поступления'!A10;'Факт'!D:D;'Поступления'!C10)
Этой формулой суммируем все фактические поступления денег от данного контрагента по данной сделке. Достаточно было условия по сделке, контрагент тут стоит для дополнительного контроля ошибок. И в последней колонке стоит сумма отклонения поступлений по данной сделке. Теперь легко формируется верхняя сводная таблица. Там мы суммируем в строке “Поступления план” все плановые поступления, у которых в колонке “Просрочено” стоит единица (для ячейки B4):
=SUMIFS(E:E;F:F;1)
Это планируемые поступления на сегодня. В следующей ячейке (B5) суммируем факт (колонка G) по тем же строкам (с единичкой в колонке “Просрочено”). Ставим отклонение - просто разность. Аналогично со строкой “Поступления план (вперед)” - сумма планируемых и фактических платежей у которых в колонке “Просрочено” стоит 0 (дата поступления позже текущей). Строка “Поступления внеплан” формируется так. В первой плановой ячейке очевидно всегда 0, это же внеплан. В ячейке C6 формула
=SUMIFS('Факт'!E:E;'Факт'!F:F;"Оплата покупателя")-C5-C4
то есть, общая сумма фактических поступлений на текущую дату без тех поступлений, которые были запланированы, их мы уже посчитали. Таким образом, мы видим отсюда, что из запланированных на месяц 75 103,12 рублей поступлений 18 518,73 рублей должны были по плану поступить на текущую дату. Из поступивших на расчетный счет 23 839,81 рублей только 656,15 были запланированы, а остальное это новые продажи. Дефицит плана поступлений составил 17 862,58 рублей, он весь был покрыт новыми сделками.


Аналогичным образом формируются плановые листы по поставщикам, зарплате и любые другие какие Вы сочтете нужными для своего бизнеса. И уже можно собрать сводный отчет о движении денежных средств на листе “Отчет”




Отсюда видно что запланированные поступления меньше на 245 871,99 рублей, при этом частично этот дефицит покрывается за счет новых продаж. Итого по поступлениям мы в плюсе на 5 615,01 рублей. Платежи в графике, но нам пришлось внепланово совершить платеж в размере 21 000,00 рублей. Итого на сегодня отклонение от платежного календаря на 15 384,98 рублей. При этом запас на счетах у нас был всего 4 868,00, то есть мы уже не укладываемся и понятно из-за чего.


Для работы данного платежного календаря достаточно всего трех ручных действий:
  1. планирование на месяц - осуществляется раз в месяц исполнителями;
  2. подготовка таблицы - осуществляется раз в месяц специально обученным сотрудником: очистить лист факт, проставить текущий месяц, проставить остатки на начало месяца;
  3. залить фактические движения денежных средств - осуществляется ежедневно специально обученным сотрудником путем копирования из отчета 1С. Занимает вместе со сверкой остатков и установкой в отчете текущей даты не более 15 минут.   
И состояние наших финансов я легко могу понять практически в любой момент из любой точки планеты где есть Интернет.


Напоследок скажу пару слов про выбор ключа - дополнительной аналитики для разнесения транзакций. Крайне важно, чтобы выбор ключа был обусловлен реальными бизнес-процессами компании, то есть, определялся теми понятиями, которыми оперируют Ваши исполнители во взаимодействии с исполнителями контрагента (Ваши снабженцы с менеджерами поставщиков, Ваши менеджеры по продажам со снабженцами клиентов, Ваши логисты с диспетчерами транспортных компаний) и которые закреплены в договоре: счета, сделки, поставки, поручения, спецификации и так далее. У нас работа ведется по сделкам, поэтому дополнительный ключ это сделка. Исполнитель по договору в текущей работе вынужден классифицировать транзакции по сделкам - если это предоплата, то надо заказывать товар и планировать отгрузку, если это закрытие дебиторки по сделке, то ничего делать не надо. Поэтому такая аналитика в платежном календаре не добавляет работы и не путает исполнителей. Например, можно взять производство. Там поставки сырья обычно осуществляются по длящемуся договору, который не делят на сделки и условия оплаты не изменяются в течении длительного периода. Тогда ключом должен быть договор (или лучше контрагент, если с этим контрагентом больше нет других договоров). Не позволяйте финансистам выдумывать дополнительные аналитики исходя из своего понимания! В случае, если дополнительные аналитики для планирования будут навязаны исполнителям финансовой службой, БДДС на Вашем предприятии так и останется сакральным знанием финансовой службы и непонятной аббревиатурой. В то время как при должном подходе это может быть очень эффективным инструментом управления бизнесом.


 


Комментариев нет:

Отправить комментарий