Logo
Блог

Блог

Про платежный календарь

Пролог

Это статья-мечта. Моя мечта об эффективном инструменте для управления деньгами. Какой он, идеальный платежный календарь? Что он умеет и как себя ведет? На что обратить внимание, если вы собрались автоматизировать управление деньгами на фирме? Как сделать так, чтобы Заявки на оплату работали?

Про все это я постараюсь написать, исходя из своей практики работы в бизнесах разных размеров и направлений. Я постараюсь передать свое видение эффективного инструмента для управления деньгами. Расскажу о том, чего мне не хватало в данном инструменте, как на должности исполнителя (казначея), так и на должности распорядителя ресурсов (генерального директора).

Актуальность тяжело переоценить

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

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

В любом бизнесе, независимо от его размера, управление деньгами – одна из главных функций финансиста. Если для годового или квартального периода в реализации этой функции помогают бюджеты, то в более коротком периоде планирования (неделя, день) используется платежный календарь и система заявок на оплату. Эти два инструмента можно далее называть системой управления денежными средствами (СУДС).

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

Функция ежедневного планирования поступлений и оплат, анализ дефицитов (кассовых разрывов) – называется казначейской. Эта функция может быть возложена как на одного сотрудника, так и на целый отдел. Конечно функции казначея намного шире. Это не только планирование приходов и расходов денег, но и получение финансирования, размещение свободных остатков, управление валютным риском, иногда даже и сбор долгов. Но в этом посте я хочу остановиться только на платежном календаре и заявках на оплату.

Гугл не такой большой

Если Вы погуглите «Платежный календарь» и «автоматизация», то найдете совсем немного информации. Вернее, вы найдете много ссылок по этой теме, но они, так или иначе, будут сводится к одним и тем же статьям: консультации и презентации продуктов фирмы «Инталев» на базе 1С, советы как построить платежный календарь в Excel и некоторые решения других компаний все на той же 1С.
Инталев для большинства компаний дорогой по деньгам. И даже если фирма может себе позволить его купить, то она сильно будет «завязана» на специалистов Инталева. Только не подумайте, что я их критикую. Ни в коем случае!

Если у Вас получилось внедрить и поддерживать Корпоративные финансы от Инталева без Инталева – «наше Вам с кисточкой!».

Я сам, лет десять назад не мог придумать как в холдинге удобно автоматизировать исключение внутренней прибыли по нереализованным товарам при консолидации. Если бы не поехал тогда в Инталев на бесплатную консультацию – сам бы, наверное, и не придумал. Но опять же, Инталев делает продукты на 1С, а это — не комильфо в стратегическом плане.

Про другие платежные календари на базе 1С я не хочу писать. И даже не из-за большой стоимости на них, а просто потому, что для работы с ними вам придётся «разворачивать» на фирме 1Ску. Кроме того, эти системы управления деньгами наследуют все «прелести удобства» 1Ски, про которые я уже писал.

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

И хотя я, как и большинство, пользуюсь «самопальным» платежным календарем в екселе, я мечтаю об Идеальном инструменте казначея. Мечтаю о системе управления деньгами, которая будет легкой и удобной, веб-ориентированной, динамичной и масштабируемой, и с ценой $100 за программу. Вы можете спросить «ну как удобная система может стоить всего сто баксов?». Отвечу: может, она не очень сложна в разработке. Подумайте, каждому бизнесу эта система важна и нужна. В Украине под миллион бизнесов. Если сделать такую систему и продать хотя бы каждому сотому предприятию, эта система для своих разработчиков принесет $1’000’000. Так что если вдруг есть заинтересовались — давайте объединимся и создадим продукт  🙂

Легкость

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

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

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

В-третьих, это легкость обучения. Интерфейс системы должен быть прост и интуитивен. Пользователь должен «идти» по системе, а она – ожидаемо себя вести.  Это и корректность перехода фокуса по полям, и отсутствие закладок, и правильные кнопки, и подсказки. Закладки в системах – это вообще дикая вещь. В 1Ске они прям везде. Закладка заставляет отрываться от клавиатуры на мышку и тратить время впустую. И вот только не надо здесь говорить, что мол по контрол-табу можно бегать между вкладками, не отрывая рук от клавиатуры! Вы много видели бухгалтеров-экономистов, которые на практике «давят цифру» в 1Ске без мыши? Их реально единицы. Любая форма, любой диалог, любая панель в системе должна быть одностраничной, с минимумом информации. Пример: контакты в gmail – посмотрите, при добавлении нового контакта, гугл ведь «не вываливает» пользователю все возможные поля к заполнению – только необходимый минимум. А если уже надо больше добавить инфо по тому или иному событию – вот вам плюсик на форме (или, например, клавиша Ins) и, в зависимости от контекста, система предлагает вам добавить поле и его значение.

Фишки и удобство

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

  • Интерактивность. Самое главное – это механизм drag&drop. Казначей или распорядитель средств должен иметь возможность просто перетянуть тот или иной платеж на другой день, без захода в конкретную настройку платежа. Одно движение! Перетянул оплату на завтра, и в тот же момент весь календарь обновился. Надо перетянуть на следующую неделю – вытянул платеж к границе формы и система тебе вывалила перед глазами календарь на месяц, где ты можешь опустить платеж в конкретный день. При этом доступна «отмена» действий с памятью шагов двадцать назад.
  • Сценарии. Мы должны иметь возможность моделировать ситуации. Например, мы составили сбалансированный календарь на следующую неделю, но дальше размышляем. А если завтра Вася не заплатит, ну тогда мы послезавтра Пете не заплатим, и передвигаем Петю на пятницу. И наличие кнопки сверху «запомнить сценарий». Мы можем запоминать и использовать разные сценарии календаря, например, реальный, оптимистичный, пессимистичный.
  • Неточный поиск. Неточный поиск вы все знаете – в гугле вы только начинаете набирать буквы, и он тут же предлагает вам варианты. Вот так и в системе должен работать неточный поиск во всему: от элементов интерфейса программы, до данных, введенных пользователем. При этом поиск должен быть «умным» и предлагать варианты, в зависимости от контекста.
  • Теги (ярлыки). К любому объекту (от контрагента, до самого платежа) вы можете привязать любое количество ярлыков (тегов). По сути, все статьи движения денег – это тоже иерархические теги. Отчетность или саму форму календаря вы можете фильтровать по тегам, исключая те или иные. Вспомните интернет магазины, там похожая система при фильтрации товаров. Таким образом вы можете «навесить» на стандартный платеж, скажем за продукты в офис, кроме самой статьи «содержание офиса/продукты», тег «встреча акционеров». Или, например, поступление от покупателя «затегаете» каким-либо проектом. Таким образом вы получите возможность видеть и формировать отчеты в большей детализации. Вас не будет ограничивать продуманная заранее жесткая иерархия субконто (аналитик), как это происходит в 1Ске.
  • Периодичность. Это еще одна фишка, которую вы прекрасно знаете на практике. Вспомните, при планировании события в обычном календаре гугл или аутлук, вы можете задать периодичность события (например, повторять каждый месяц, повторять каждую пятницу, прекратить через 5 повторений и т.д.). Подобный механизм надо иметь и для платежного календаря. Например, возможность указать повторение платежа для аренды или оплаты за связь.
  • Мультивалютность. Здесь можно написать очень много, но скажу кратко. Календарь должен «держать» в себе несколько курсов для одной валюты (например, это может быть НБУ, курс нашего банка, наличный курс). Мы можем одним переключателем сразу отразить весь календарь в другой валюте. Для некоторых платежей может быть настроен один курс, для некоторых другой (например, для аренды — коммерческий курс покупки, умноженный на коэффициент, а для оплаты за товар – курс НБУ). Система корректно пересчитывает все платежи в выбранный курс, учитывая настройки пользователя. 
  • Транзитность платежей. Очень кратко суть транзитности. Она возникает, когда вы продаете или покупаете валюту (у вас проходит несколько приходов-расходов по валютным и гривневым счетам, которые относятся к одной операции); когда вы перебрасываете деньги внутри группы предприятий или между счетами (у вас по сути нет операции с третьими лицами, но отразить движение денег нужно). Для отражения таких транзитных сумм имеется определенная сложность, если наш платежный календарь в екселе или 1С. Система должна убирать эту проблему.
  • Привязки и зависимости. Этот механизм позволяет пользователю легко сделать привязку или зависимость от какого-то события. Когда это нужно? Например, ваш лизинговый платеж зависит от коммерческого курса валюты; ваша аренда за офис пересчитывается в валюту только если курс перескакивает определенную границу; ваш платеж дилеру увеличивается только в случае роста курса валюты; ваш платеж осуществляется только тогда, когда есть определенный приход; ваш платеж осуществляется только совместно с другим платежом, например, налоги при зарплате. Это непростой механизм и его сложно разработать. Скажем так, спрограммировать его не сложно, но сделать так, чтобы этот инструмент был интуитивно понятен не программисту, – сложно.
  • Прямая работа. Это работа непосредственно в форме календаря. Эта фишка как-раз относится к легкости внедрения. Вы можете писать числа (платежи) прямо в форме календаря, не указывая множества дополнительных полей. Точно так, как и встречу вы можете назначить в гугл-календаре просто на форме, так и платеж в платежном календаре вы пишите сумму сразу на форме. Захотите уточнить – кликаете и открывается форма настройки конкретного платежа. Это позволяет очень быстро «прикидывать» сценарии.
  • Индикаторы в ячейках. В ячейке календаря с каждым платежом есть определенные значки. Не расписывая долго, вот вам пример того, как это может обозначаться: если в екселе у вас формула отличается от близлежащих, ексел в виде значка возле ячейки указывает на возможную неточность. Кликнув по такому значку ексела, вы можете сказать, что все ок, или поменять значения. Вот так и в платежном календаре должны быть индикаторы ячейки (например, платеж перенесен, валютный, привязан и т.д.).
  • Аудит изменений. Желателен трекинг любых изменений в календаре, с указанием автора. В принципе так, как это реализовано в гугл-документах и дорогих ERP системах.
  • Умные подсказки. Я не буду писать здесь про искусственный интеллект, но система должна указывать Вам на нестандартные операции. Пример — Приват24. Вы помните, как Приват, при незнакомых/нестандартных платежах, запрашивает дополнительные авторизации? Или как гугл вам подсказывает «возможно вы имели ввиду это?» Вот так в идеале и должен работать Платежный календарь, посмотрев на вашу статистику – он предлагает не только выбрать контрагента, назначение платежа или сумму, но даже может составить план оплат на будущий период, опираясь на статистику. Естественно, что пользователь на любом этапе может не принять, предложенное системой и поставить свои цифры, буквы, даты.
  • Умная квитовка платежей. Под квитовкой я здесь подразумеваю сопоставление платежей. То есть сравнение того, что прошло по выписке банка с тем, что есть в платежном календаре. Это не просто поиск по ЕГРПОУ, это многоуровневая проверка системой плана и факта и предложение совместить конкретный факт с конкретным планом. Разницы могут возникать и в суммах, и в датах, и даже в контрагентах (вспомните: вам, должна быть знакома ситуация, когда заплатил ФОП Петренко В.М. вместо ФОП Петренко А.С. с возмущением «да какая разница, это ж моя жена, просто у нее лимит вышел»). Мы такую систему разрабатывали на Ласка Лизинг. Там это было проблемой, так как сотни платежей от лизингополучателей, каждый платеж в нашем учете надо было разбивать на тело и комиссию, кроме того, у каждого лизингополучателя было по несколько договоров с множеством счетов. Естественно, половина клиентов платила так, как в счетах написано, а половина – абы как – просто копировала старую платежку и писала сумму, которую готовы заплатить. Мы с программистом сделали систему, которая очень корректно определяла платежи и предлагала варианты квитовки, бухгалтеру на оплатах. Повысили скорость работы бухгалтера с рабочего дня до часа. Кроме квитовки банк-календарь очень важно сопоставление с системой заявок на оплату. Тут имеется ввиду, что казначей может планировать календарь до того, как возникнет сама заявка на оплату. То есть, казначей запланировал оплату канцтоваров на следующей неделе в оценочной сумме 3’000, а офис-менеджер через пару дней подготовила заявку на оплату на 2’850 и запустила по системе акцепта. Календарь должен «отловить» похожесть этих двух платежей и, при импорте заявок на оплату, предложить сквитовать (совместить) платежи в один, который и будет основным.

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

Конечно система должна быть веб-ориентированной. Генеральный директор, который сейчас отдыхает на Канарах, должен со своего ipad зайти и глянуть «че там как».

Конечно система должна быть масштабируемой. Она должна уметь «разворачиваться» от маленькой компании (где функции финансового директора, казначея, бухгалтера по оплате, инициатора платежа и, часто, даже акцептанта, «лежат на плечах» единственного главбуха), до крупного холдинга (где несколько казначеев и они имеют разные уровни доступа к данным платежного календаря).

Заявки на оплату

Про заявки на оплату можно найти достаточно информации в интернете. Система заявок заложена в стандартные 1Ски. Единственная проблема – она там не работает. Вернее, она как-то работает, но не так как нужно. Покажите мне хотя бы сотню компаний из тех 300’000 официальных пользователей 1С, которые достали из желтой коробки заявки на оплату и начали в них работать.

Писать много здесь не буду, расскажу только те моменты, которые считаю удобными для себя.

  • Заявка-молния. Особый тип заявок, который инициатор платежа выбирает, когда надо срочно совершить платеж (знакомые всем финансистам «пожары» срочно-срочно). В данном случае Заявка попадает сразу на все точки маршрута с индикацией срочности, не проходя обычный пусть – инициатор/казначей/акцептант/бухгалтер. Это дает возможность бухгалтеру сделать платежку «по звонку» от директора, при этом система не рушится – то есть никакой платеж не идет мимо системы. Если вдруг от какого-то менеджера 80% платежей идут «молниями» — на следующем совещании руководителей отделов просто поднимается вопрос – в чем причина, как этих пожаров избежать.
  • Индикатор долга и оплат непосредственно в форме заявки. Прямо на форме в виде надписей нужно видеть долг на сегодня (по тем данным, которые есть в системе) и последние три оплаты. Мне 1Сники показывают и доказывают «смотрите, зачем три, зачем на форме – вот можно зайти и увидеть все платежи по контрагенту!». Друзья, ну какие все платежи? Куда зайти? У кого на это есть время? При акцептах и согласовании оплат, очень часто у руководителя возникает всего два вопроса к финансисту: «1. Оля, че так много? 2. Мы ж недавно им платили?». На что финансист обычно дает два ответа: «1. Константин, так гляньте – уже ж месяц прошел. 2. Посмотрите, вот прошлые три платежа — мы обычно им столько и платим».
  • Разные схемы маршрутов. Это реализовано в системах, но не всегда удобно. Просто обратите внимание, в самом обычном случае, заявки идут по маршруту: инициатор-казначей-финдиректор-акцептант. Но в той или иной ситуации может присутствовать, как я называю эту роль, контролер. Например, при закупке сырья – директор по производству, при оплате за транспорт – главный логист, при комуналке – административный директор и т.д.
  • Обратите внимание на то, что один пользователь может занимать разные роли в системе (например, быть инициатором и казначеем). Также обратите внимание на возможность корректного делегирования ролей в системе, чтобы, когда казначей уходит в отпуск, то он не передавал свой пароль, скажем финдиру, а просто делегировал на определенный срок свою роль.
  • Группировка заявок. Здесь имеется ввиду, что могут быть заявки разные (суммы, получатели, назначения платежа и даже инициаторы), но по сути, это один платеж. Например, регистрационные платежи при авто, или налоги по зарплате и т.д. это разные заявки. В то же время, для финансового директора, а тем более для акцептанта – это один платеж: «за машину», «зарплата» и т.д. Важно, чтобы казначей мог группировать любые заявки, и они отражались как одна.
  • Рассрочка платежа. Все, наверное, встречали ситуации, когда руководитель говорит «половину счета плати сегодня, вторую на следующую неделю». Вот для этих ситуаций и существует рассрочка платежа. Мы реализовали это на одной из моих мест работы таким образом. Была кнопка «рассрочить», при нажатии которой, возникал диалог с табличкой дата/сумма. Вы записывали сегодняшнюю сумму и разницу от суммы заявки оно показывало вам через неделю. Естественно вы могли тут же подкорректировать дату и сумму. Тогда оно добавляло следующую строку с датой через неделю и остатком суммы. По нажатию кнопки, все заявка копировалась в даты и суммы рассрочек и связывалась между собой, чтобы можно было быстро «поднять» весь ряд. Реализация этого механизма сделана не через таблицу (как в стандартной 1С), а именно через копии заявок, так как есть в практике ситуации, когда какой-то платеж контрагент уже просит на другое юрлицо. Обращайте внимание также и на возможность подобных ситуаций.

Вместо эпилога

Это были мои мысли и советы в случаях автоматизации управления деньгами. Конечно они не охватывают, наверное, и половины нюансов, которые могут возникать на предприятиях. Если захотите поделиться своими мыслями – пишите мне на почту – включу ваши предложения в эту статью, с указанием вашего авторства 😉

Надеюсь что-то из написанного выше будет Вам полезно!

Спасибо, что дочитали 🙂