Мы постоянно видим ситуации когда владелец компании, или руководители проверяют счета в чатах телеграма или ватсапа, скидывают бухгалтеру на оплату или сами проводят в приложении банка. Тут кроется один большой пиздец состоящий из большого количества маленьких, на первый взгляд незначительный пиздецов.
- Невозможно валидно найти счета одного контрагента
- Невозможно узнать статус счета без личных переписок
- Трудно определить кто инициировал оплату счета, если человек не контактировал с ним (например бухгалтер)
- Данные постоянно теряются, нет истории
- Но самое главное — нельзя вести бюджет
Из хороших новостей — это довольно легко исправляется если воткнуть процесс похожий на это:
В этой схеме нужна одна общая система BPM/ERP — что ты решил использовать, в ней отдельные учетки для разных пользователей разделенные по правам доступа. Очевидно HR специалисту который заносит счет для пополнения баланса на сайте HH.ru не надо иметь возможность квалить все счета. Бухгалтер так-же не должен принимать решение по подтверждению/отмене оплаты, он чисто исполнитель. Так-же тут может быть сколько угодно уровней проверки счета (но по факту больше 2 не требуется почти никогда)
Мастхев на этапе создания счета:
- Файл счета — как подтверждение, ну и дополнительно там будет много полезной инфы в дальнейшем для самой оплаты
- Сумма — мы должны сохранить ее для дальнейшего агрегирования (например построить отчет «сумма счетов за месяц»)
- ИНН контрагента — что-бы в будущем считать сколько и кому мы оплатили денег, без этого у нас теряется большое количество данных
- ID — что-бы при необходимости обращаться к нему напрямую, а не «Помнишь мы мебель покупали весной, найди эту платежку»
- Title — человеческое название инвойса, что-бы быстро выбирать его из списка
Что было бы круто иметь на этапе создания счета:
- Очень полезно знать контрагента (привязывать его к конкретному счету, по сути можно это делать через ИНН, но так удобнее)
- «От кого платим» — у тебя может быть несколько юрлиц, и конкретный счет должен быть оплачен именно от этой твоей компании, потому что там например подписан договор.
- Дата когда его надо оплатить, а может быть и не одна — если инвойс надо оплатить частями, тогда должна быть связка «Дата-Сумма-Статус», а статус должен включать в себя Не надо оплачивать / Надо оплачивать / Оплачен, в рамках каждой части
- Заказ к которому относится этот счет, что-бы потом посчитать сумму денег по конкретному заказу и получить более точную практическую юнит экономику
Вот наше видение:
После сохранения инвойса, ему присваивается ID и он лежит в реестре счетов со статусом «#1 На проверке». Когда пришел его час, ответственный специалист (например финдир) — открывает страницу с реестром счетов, и проставляет статусы в соответствии с его видением «Надо/не надо». Что важно на этом этапе:
- Надо что-бы этот сотрудник открывал полную карточку счета (проваливался в сингл документ), внутри могут быть комментарии, условия оплаты, частичные оплаты и что угодно другое — поэтому пусть открывает каждый документ отдельно
- При переводе счета в оплату (типа успех на этом этапе) — надо проставлять категорию из БДР, что-бы делать проверку на лимит бюджета в этой категории. Если делать это позже — бюджет не будет согласовываться и ты всегда будешь иметь проблемы
- Ну и собственно менять статус на «#2 ожидает оплаты»
Тут вступает в силу бухгалтер которому этим действием фактически поставили задачу «Слышь, оплати, да», и он/она в заранее оговоренное время, например вторник и четверг в 16:00 — заходит в банк, забивает счета и проводит оплаты, попутно меняя статус на «#3 Оплачено», вообще отлично если обратно прикрепляется файл платежки что-бы инициатор инвойса (помнишь HR с счетом из хедхантера из начала поста) имел возможность выслать PDFку подтвердив факт оплаты еще до поступления бабок на расчетный счет контрагента, потому что там могут быть медленные бухгалтеры которые еще день будут проводить бабки у себя в системе, но это уже не твоя проблема, верно?)
Как собрать себе такой процесс «На коленке» без BPM/ERP и любой другой системы?
- Понадобится Битрикс24 с тарифом «Стандарт» и выше или любая другая система где можно создать «Кастомный тип данных» с редактированием мета данных, есть учетки и им можно назначать права доступа. В рамках битрикса это делается на RPA, переходит на страницу https://@Имя твоего портала@.bitrix24.ru/rpa/ — нажимаем кнопку «Добавить RPA», накидываем стадии, и указываем кто из пользователей/групп пользователей видит каждый этап.
- Если нет даже Битрикса, но процесс нужен — можно реализовать хоть в гугл таблицах, корректно разметив столбцы с данными, а файлы хранить в облаке вставляя ссылки. Да, будет не удобно, да не будет истории в привычном понимании. Но быстро и бесплатно.
Если необходимы инструкции «как сделать» — обращайся в нашу телегу, тамскорее всего уже есть готовые решения и шаблоны документов