среда, 5 октября 2016 г.

Ежедневный реестр оплат

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

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


Решение принято. Дальше заводим Гугл Таблицу, называем ее “Реестр платежей”, даем доступ к ней всем людям, которым позволено тратить деньги компании и ждем часа Х. Чтобы вносимая информация была в едином формате задаем шапку таблицы и запрещаем ее редактировать путем установки защищенного диапазона в меню “Данные/Защищенные листы и диапазоны”. Вот так это выглядит у меня




Поскольку “Платежный календарь” у нас уже в облаке, то остаток на расчетном счете берем из него формулой
=IMPORTRANGE("Тут пишем ID таблицы с остатками";"Сводный отчет!C28:C28")


Вопреки расхожему мнению, навязанному нам известными мультипликационными героями, чтобы продать что-нибудь ненужное, надо не только купить что-нибудь ненужное, но и затратить титанические усилия для того, чтобы его кому-нибудь “впарить”. И все это время надо еще и где-то хранить это ненужное. Чтобы не обременять себя этими излишними хлопотами нужно всего лишь контролировать, что в реестре оплат стоят платежи по согласованным сделкам (у нас их согласовывает операционный директор, у него зарплата большая, в случае чего можно выдать ее чем-нибудь ненужным). А поскольку все сделки у нас согласовываются электронной подписью и лежат на Гугл Диске, то достаточно в Таблицу встроить скрипт, который будет к каждому платежу автоматически подбирать подписанный документ. Скрипт вызывается через добавленный пункт меню “Оплаты/Проверить”. Код скрипта тут.


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




Кнопка “Согласование” сделана для операционного директора. Он смотрит в час Х реестр первым и если его все устраивает, то он нажимает эту кнопку. Появляется отметка “ОК” напротив ячейки “Согласовано” и у всех кроме меня отключается доступ на редактирование. После этого я могу чего-то еще поисправлять сам, прямо здесь, на корпоративном сайте (ну не могу я себя лишить удовольствия вручную суммы срезать, что поделать, кризис) и нажать кнопку “Утверждаю”. При нажатии на нее происходят те же самые действия: текущая таблица в формате PDF уходит с моего адреса по электронной почте исполнителю - на ту электронную почту, которая указана в ячейке G3 (оплачивает). То есть, чтобы изменить исполнителя (а также, “согласованта” и “утвержданта”) не надо менять код, достаточно зайти под аккаунтом, в котором лежит таблица и поменять данные в ячейках.


На всякий случай добавлена кнопка “Проверить”. Чтобы с корпоративного сайта запустить скрипт поиска подписанных документов к платежам.


В заключении пара лайфхаков.


Чтобы автоматически вернуть исполнителям права на редактирование реестра каждое утро по триггеру запускается скрипт. Проблема в том, что в скрипт надо как-то передать информацию каким именно пользователям надо выдать права. Чтобы, следуя принципу Оккама, не плодить сущности я сделал так. При нажатии на кнопку “Согласовано” пользователь не просто удаляется из редакторов Таблицы, а получает права на просмотр. И утром по триггеру все “просмотрщики” переносятся в редакторы. Таким образом, у меня нет дополнительного реестра людей, работающих с реестром. Достаточно человеку выдать доступ на редактирование и он автоматически встроится в рабочий бизнес-процесс.


Также для меня до сих пор загадка почему Google не выдает имя пользователя через конструкцию Session.getActiveUser(), ведь авторизовавшись перед запуском скрипта пользователь подтвердил автоматически свое согласие на знакомство (или обратно, если бы хотел остаться анонимусом не авторизовывался бы по требованию). Конструкция работает для платных аккаунтов, но если запустить другой скрипт через UrlFetchApp информация о пользователе опять же потеряется. В данном случае мне важно определять пользователя и я решил вопрос через разграничение прав на работу с Таблицей. То есть, я выделил специальные ячейки Таблицы. Например, ячейка F1 доступна на редактирование только для “согласованта” - это делается штатными средствами. Далее в скрипте производится попытка записать чего-нибудь в эту ячейку. Если происходит ошибка, значит скрипт запущен пользователем не уполномоченным на согласование реестра о чем ему тут же сообщается. Аналогично и с ячейкой “утвержданта”.  

Коды скриптов: Гаджет согласования платежей, API реестра платежей

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

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