Как сделать веб-приложение для согласования расходов: настройте цепочку проект-статья-заявка-согласование, роли, историю решений и контроль чеков.
В агентстве расходы появляются каждый день: такси на встречу, материалы для съемки, подписка на сервис, срочная печать. Когда все это живет в переписках и таблицах, быстро начинается хаос: один и тот же расход обсуждают в трех чатах, суммы в отчетах не сходятся, а чек оказывается «где-то в личке у исполнителя».
Обычно болит одно и то же:
Мессенджер неудобен по простой причине: он не хранит процесс. Там нет обязательных полей, статусов, понятных правил «кто и когда должен ответить», и нет одного места, где видно картину по проекту. Учет превращается в бесконечные «скинь еще раз», «а это за что?» и «кто разрешил?».
Рабочий подход - собрать веб-приложение для согласования расходов вокруг понятной цепочки: проект - статья - заявка - согласование - чек. Важно продумать не только формы, но и правила: какие бывают статусы, кто может двигать заявку дальше, и что считается подтверждением.
Как выглядит результат на практике:
Если вы делаете веб-приложение для согласования расходов, начните с простого каркаса. Когда сущностей слишком много, люди путаются. Когда их мало, потом невозможно ответить на вопросы про деньги и ответственность.
Проект здесь - контейнер. Все заявки, чеки и решения живут внутри проекта. Так проще считать лимиты и делать отчеты, потому что расходы почти всегда смотрят по проектам, а не «вообще по компании».
Статья расхода нужна, чтобы расходы были сравнимы. Без нее все уйдет в поле «Комментарий»: один пишет «такси», другой «доставка», третий «логистика». Со статьями появляется понятная аналитика: сколько ушло на подрядчиков, материалы, командировки. На старте обычно хватает 10-20 статей и возможности добавлять новые.
Заявка - единица согласования. В ней хранится то, что нужно менеджеру и бухгалтерии: сумма, валюта, дата расхода (или плановая дата), кто тратит, по какой статье, короткий комментарий и, при необходимости, контрагент. Если вы строите workflow проект заявка согласование, то именно заявка проходит статусы и собирает решения.
Минимальный набор сущностей может быть таким:
Чек лучше хранить отдельным объектом. Тогда можно прикрепить несколько файлов к одной заявке (например, чек и акт) и не ломать модель.
Простой пример: в проекте «Ребрендинг» создают заявку по статье «Материалы» на 12 500 RUB, прикрепляют фото чека, руководитель утверждает, а бухгалтер отмечает, что документ принят.
Чтобы веб-приложение для согласования расходов не превратилось в «болото», сначала зафиксируйте цепочку статусов и правила переходов: кто и при каких условиях может двигать заявку дальше. Обычно хватает шести состояний: черновик, на согласовании, одобрено, отклонено, оплачено, закрыто.
Переходы делайте короткими и предсказуемыми, а исключения - явными:
Пример: аккаунт-менеджер подал 12 000 руб. за стоковые фото. Руководитель проекта одобрил 9 000 руб. и попросил заменить часть позиций. Система фиксирует «одобрено на 9 000», а остаток 3 000 уходит в новую заявку или корректировку.
Если роли заданы размыто, чеки снова начинают пересылать в мессенджерах, а суммы правят «на словах». Заранее решите две вещи: кто может создавать и править заявки, и кто имеет право их утверждать.
Обычно в агентстве хватает пяти ролей:
Права лучше ограничивать по контексту. Например, менеджер проекта видит только свои проекты, а сотрудник не может выбрать чужой проект или статью, запрещенную для этого проекта. Так меньше ошибок уже на этапе создания заявки.
Отдельно задайте пороги сумм. Простой вариант: до 10 000 руб. достаточно менеджера проекта, выше нужен финконтроль, а для крупных трат добавляется второе согласование (например, руководитель направления). Пороги лучше хранить в настройках проекта или статьи, а не в коде.
В интерфейсе показывайте каждому ровно то, что нужно для решения:
Пример: дизайнер покупает материалы на 6 500 руб. по проекту клиента. Он создает заявку и прикрепляет чек, менеджер проекта утверждает. Если бы сумма была 26 500 руб., заявка ушла бы еще и в финконтроль, а сотрудник сразу увидел бы, что нужно второе согласование.
После запуска веб-приложения для согласования расходов споры часто смещаются с «сколько потратили» на «кто разрешил и на каких условиях». История решений закрывает сразу три задачи: разбор конфликтов, подготовку к проверкам и передачу дел, когда менеджер уходит в отпуск.
Хорошая история - это не «лог ради лога». Она отвечает на четыре вопроса: кто сделал действие, что изменилось, когда это произошло и почему.
Хватает простого набора, который закрывает большинство случаев:
Ленту лучше показывать прямо в карточке заявки, чтобы не искать события по разным экранам.
При отклонении сделайте комментарий обязательным. Правило «без причины нельзя отправить назад» экономит время и снижает напряжение: заявитель сразу понимает, что исправить.
Еще одна частая проблема - заявка менялась несколько раз, и никто не помнит, что было «до». Здесь помогают версии: сохраняйте снимок заявки при важных изменениях (например, перед отправкой на согласование и после правок). Тогда можно быстро увидеть, кто поменял сумму и почему.
Если вы собираете приложение в TakProsto, удобно сразу заложить «события» и «версии» отдельными сущностями. Так лента остается стабильной и при росте количества заявок.
Интерфейс должен отвечать на два вопроса за пару кликов: сколько уже потрачено по проекту и что нужно согласовать прямо сейчас. Если для этого приходится проходить пять экранов, команда быстро вернется в чаты.
Первый экран лучше делать простым: список проектов и короткая сводка по статьям. Не бухгалтерский отчет, а понятные цифры: лимит, потрачено, осталось, где превышение. Это помогает руководителю проекта быстро понять контекст, а сотруднику - выбрать проект и статью.
Второй ключевой экран - список заявок. Тут важна скорость: фильтры по статусу, проекту, статье и инициатору, плюс действие «открыть следующую на согласовании».
Карточка заявки должна быть одной страницей без «пряток»: сумма, статья, поставщик, дата, способ оплаты, чек, комментарии и история решений. Согласующий видит все на одном экране и реже просит уточнений.
Согласование должно быть конкретным: две кнопки «Одобрить» и «Отклонить», поле «Причина» и короткий чек-лист перед одобрением:
Уведомления нужны только в моменты, когда человек должен что-то сделать. Сообщение должно быть коротким и предметным: «Заявка #128, проект X, 12 400 ₽, статья “Реквизит”. Нужен ответ до 18:00».
Если вы собираете прототип в TakProsto, просите сделать экраны «плоскими» и быстрыми: меньше переходов, больше ясности на одном экране.
Если начать разработку без общего описания процесса, у бухгалтерии, аккаунтов и руководителей проектов будут разные ожидания. Сначала договоритесь о терминах и о том, что считается «нормой».
Опишите путь «проект - статья - заявка - согласование» в 5-7 предложениях простым языком. Например: «Сотрудник создает заявку по проекту и статье, прикладывает чек, руководитель проекта проверяет смысл и сумму, бухгалтерия проверяет реквизиты, затем заявка либо утверждается, либо возвращается с комментарием».
Тут же согласуйте термины: что такое «статья», чем «заявка» отличается от «расхода», когда чек обязателен.
Дальше определите роли, границы ответственности и пороги сумм (например, до 10 000 руб. согласует руководитель проекта, выше - директор), а также кто видит чужие заявки.
На одном листе нарисуйте статусы и правила переходов. Не делайте их много: лишние статусы почти всегда превращаются в хаос. Для каждого перехода добавьте правило: кто может сделать действие и что требуется (комментарий, чек, подтверждение суммы).
Быстрая проверка перед прототипом:
Затем пройдите 3 типовых сценария: покупка материалов, такси после съемки, оплата подрядчика. Например: менеджер загрузил чек на 2 800 руб., руководитель проекта вернул из-за неверной статьи, менеджер исправил, бухгалтерия проверила реквизиты.
Финальный шаг - пилот на одном проекте на 1-2 недели. Обычно всплывают мелочи, которые решают успех: обязательный комментарий при возврате, автоподстановка статьи, запрет редактирования после отправки. Если делаете это в TakProsto, удобно начинать с planning mode и быстро уточнять правила до начала сборки.
Чаще всего проблема не в интерфейсе, а в правилах. Если они расплывчатые, веб-приложение для согласования расходов быстро превращается в чат с бесконечными уточнениями.
Хватает нескольких ограничений. Разделите статусы: «черновик», «на согласовании», «одобрено», «отклонено», «оплачено». После «одобрено» запретите менять сумму и проект без пересогласования.
Для отказа сделайте обязательное поле «причина» и короткие шаблоны (например, «нет бюджета», «нужен другой поставщик», «не хватает документа»). Дубли ловятся простым правилом: один чек (номер, дата, сумма, ИНН или хотя бы хеш файла) не может быть прикреплен дважды.
Хороший тест перед запуском: сможет ли новый сотрудник создать заявку за 30 секунд. Если нет, убирайте поля, которые не влияют на решение.
Одна заявка должна однозначно жить внутри проекта и конкретной статьи расходов. Без этого отчеты будут расходиться.
Сделайте один тестовый прогон на реальном кейсе. Например, «покупка реквизита для съемки на 7 500 руб.». Пусть сотрудник создаст заявку, приложит фото чека, а менеджер попробует одобрить с телефона.
Согласующий должен видеть минимум информации, чтобы принять решение быстро и безопасно.
Если вы настраиваете процесс через TakProsto, заложите роли и обязательные поля в форме, а комментарий к решению сделайте обязательным хотя бы для отказа. Это резко снижает количество вопросов «почему отклонили?».
Дизайнеру срочно нужен стоковый набор иконок для проекта. Он покупает его со своей карты, сохраняет чек и просит компенсацию. Чтобы не было переписки в мессенджерах и вопросов «кто разрешал?», все идет по одному маршруту: проект - статья - заявка - согласование.
Дизайнер создает заявку: выбирает проект, статью «Стоки и лицензии», указывает сумму, прикладывает чек. В комментарии пишет, зачем покупка нужна и где будет использоваться.
Руководитель проекта видит заявку по своим проектам. Он проверяет статью, наличие чека и адекватность суммы. Если все в порядке, отправляет дальше. Если нет - возвращает на доработку с причиной (например, «нужен чек с реквизитами»).
Финконтроль смотрит заявку с точки зрения правил. Допустим, в агентстве есть порог: все покупки по стокам выше определенной суммы требуют объяснения или подтверждения. Финконтроль запрашивает комментарий: почему нельзя взять дешевле и где будет использоваться лицензия. Ответ остается в заявке.
В итоге финконтроль может одобрить частично: например, компенсировать стандартную лицензию, а расширенную - не компенсировать без предварительного согласования. Причина фиксируется в решении, и ее не нужно потом искать по переписке.
После согласования бухгалтер отмечает факт оплаты: «выплачено», добавляет дату и способ (например, на карту сотрудника) и закрывает заявку. В карточке остается понятная история: кто проверил, кто запросил уточнение, кто и почему изменил сумму, и когда деньги ушли.
Для пилота не пытайтесь сразу охватить все проекты и виды затрат. Выберите один живой проект и соберите минимальный контур, который реально используют каждый день: проект - статья - заявка - согласование.
В TakProsto это удобно делать через planning mode: описываете процесс, роли и ограничения, затем переходите к прототипу в чате. Для старта достаточно, чтобы система принимала заявки, вела статусы, показывала нужные поля разным ролям и сохраняла историю действий.
На практике быстрее всего собираются:
Пару вещей лучше решить заранее, даже для небольшого пилота: нужен ли экспорт исходников, как будет устроено развертывание и хостинг, нужен ли свой домен, и как откатывать изменения, если обновление сломало процесс (в TakProsto для этого есть snapshots и rollback).
Рабочий ритм для пилота обычно такой:
Успех пилота лучше мерить цифрами: среднее время согласования, доля заявок без правок, число спорных случаев с вопросом «кто утвердил».
Следующий шаг: выберите проект для пилота и опишите 3-5 типовых заявок (такси, материалы, подписка, подрядчик). Этого достаточно, чтобы за несколько итераций получить рабочий процесс и понять, что масштабировать дальше.
Начните с минимального контура: проект, статья, заявка, согласование, файл чека. Этого достаточно, чтобы привязать трату к проекту, зафиксировать решение и не терять документы. Остальное добавляйте только после пилота, когда станет ясно, чего реально не хватает.
Сделайте простую цепочку: черновик → на согласовании → одобрено/отклонено → оплачено → закрыто. Главное правило: после одобрения нельзя незаметно менять сумму, проект или статью; любые исправления должны идти через пересогласование или отдельную корректировку, чтобы сохранялась ответственность.
Хороший минимум: сотрудник создает заявку и прикладывает чек, менеджер проекта утверждает по смыслу и бюджету, финконтроль проверяет лимиты и правила (по порогам), бухгалтер отмечает оплату и принятие документов, администратор настраивает справочники и доступы. Даже в маленьком агентстве лучше разделять «кто разрешил тратить» и «кто провел оплату».
Разрешите отправлять заявку без чека, но заставьте явно отметить причину и срок, когда чек появится. Дальше включите правило: без чека нельзя переводить в «оплачено» или «закрыто», а для некоторых статей можно сделать чек обязательным уже на этапе отправки на согласование.
Фиксируйте «одобрено на сумму X» как отдельный факт решения и требуйте комментарий, почему сумма отличается. Разницу лучше оформлять новой заявкой или корректировкой, чтобы не было ситуации «утверждали одно, оплатили другое».
Сделайте простую защиту: один и тот же чек не должен прикрепляться к разным заявкам. На практике это можно ловить по сочетанию суммы и даты, реквизитам продавца, номеру документа, а если это фото или PDF — по отпечатку файла, чтобы система предупреждала о повторе сразу при загрузке.
В карточке заявки должна быть лента событий: кто создал, кто и когда сменил статус, кто одобрил или отклонил, что именно менялось в сумме, статье и файлах, и по какой причине. Тогда вопрос «кто это утвердил» закрывается одним экраном, без поиска по чатам и памяти команды.
Сделайте первый экран про действие, а не про отчетность: что нужно согласовать сейчас и сколько уже потрачено по проекту. В карточке заявки держите все на одной странице: сумма, проект, статья, комментарий, чек, способ оплаты и история решений, чтобы согласующему не приходилось собирать контекст по разным вкладкам.
Опишите процесс и правила в planning mode: статусы, роли, пороги сумм, обязательные поля и требования к чеку. Затем попросите собрать прототип с формой заявки, маршрутом согласования, журналом событий и простыми фильтрами по статусам; после этого запустите пилот на одном проекте и по итогам недели-двух ужесточайте ограничения, которые реально экономят время.
Если нужен контроль и независимость, закладывайте экспорт исходников, развертывание и хостинг с самого начала, а для безопасных обновлений используйте snapshots и rollback. По данным и требованиям часто важно, что TakProsto работает на серверах в России и не отправляет данные в другие страны, поэтому это удобно для процессов с чеками, суммами и внутренними согласованиями.
