Пошаговый план создания веб‑приложения для закупок: роли, маршруты согласования, бюджетный контроль, интеграции, безопасность, отчёты и внедрение.
Веб‑приложение для закупок нужно, чтобы переводить «хочу купить» из переписок и таблиц в управляемый процесс: заявка → согласование → заказ → приёмка → закрывающие документы. Главная цель — сделать согласование заявок на покупку предсказуемым и проверяемым: кто инициировал, кто и почему одобрил/отклонил, какой бюджет затронут и что реально было поставлено.
В MVP обычно достаточно четырёх базовых функций:
Решение полезно компаниям, где закупки затрагивают несколько ролей: инициаторы из подразделений, отдел закупок, финансы (контроль бюджета), руководители (утверждение), иногда — склад/логистика (приёмка). Особенно заметен эффект там, где много повторяющихся покупок, а согласования идут через почту и мессенджеры.
Начните с процессов, которые дают быстрый выигрыш:
Целевой результат — меньше ручных согласований и ошибок в данных: не нужно уточнять суммы, статьи, ответственных и сроки «по кругу».
Успех удобно измерять метриками: время цикла от заявки до заказа, прозрачность (доля заявок со всеми обязательными данными и историей решений), соблюдение лимитов (сколько заявок блокируется или корректируется из‑за превышений), снижение числа возвратов на доработку.
Чтобы веб‑приложение для закупок не превратилось в «универсальную форму на все случаи», сначала зафиксируйте роли и решения, которые они принимают. Это упрощает настройку прав доступа и маршрутов согласования.
Инициатор — создаёт электронные заявки на закупку и отвечает за корректность данных (что купить, зачем, сроки, центр затрат).
Согласующие — руководитель, владелец бюджета, служба безопасности/ИТ/юристы (по необходимости). Их задача — подтверждать целесообразность, соответствие политике и лимитам.
Закупщик — подбирает поставщика, сравнивает предложения, фиксирует условия и ведёт коммуникации.
Бухгалтерия/финансы — проверяет статьи затрат, НДС/первичку, готовность к оплате, соответствие регламенту.
Администратор — управляет справочниками, правилами маршрутизации, ролями и правами доступа, аудитом и журналом действий.
Инициатор: «Как инициатор, я хочу создать заявку из шаблона и приложить коммерческое предложение, чтобы ускорить запуск закупки». «…хочу отменить заявку до утверждения, если потребность исчезла».
Согласующий: «Как руководитель, я хочу видеть сумму и обоснование, чтобы быстро решить — согласовать или вернуть на доработку». «…хочу делегировать согласование на время отпуска».
Закупщик: «Как закупщик, я хочу заменить поставщика на этапе выбора, чтобы отразить лучшие условия без потери истории». «…хочу оформить частичную поставку, чтобы закрывать заявку поэтапно».
Бухгалтерия: «Как бухгалтер, я хочу проверить реквизиты и условия оплаты, чтобы снизить риск ошибок в документах».
Минимальный набор событий: создание заявки → согласование → возврат на доработку → повторное согласование → отмена. Важно фиксировать причину возврата и кто инициировал изменение — это основа для аудита и анализа узких мест.
Отдельно продумайте: срочную закупку (ускоренный purchase approval workflow с обязательным пост‑контролем), замену поставщика (с сохранением версии и комментариев) и частичную поставку/закрытие (остаток в заявке, корректировка сроков и сумм).
Опишите правила в виде матрицы: по сумме, категории, центру затрат и риску. Например: до лимита — руководитель, выше лимита — владелец бюджета, для ИТ‑закупок — дополнительное согласование ИТ, для договоров — юрист. Чем точнее матрица, тем меньше ручных исключений и тем проще автоматизация закупок.
На этом этапе важно договориться не только о том, «как выглядит заявка», но и какие данные система обязана хранить так, чтобы их можно было проверять, согласовывать, передавать в учёт и анализировать.
Минимальный набор полей стоит фиксировать вместе с финансами и закупками — иначе позже появятся «обязательные мелочи», из‑за которых заявки начнут возвращаться.
Обычно в заявке нужны:
Отдельно решите, будет ли заявка построчной (несколько позиций) или «одним лотом». Это сильно влияет на структуру данных и проверку лимитов.
Заранее перечислите типы вложений и правила обязательности:
Правило обязательности часто зависит от суммы, статьи бюджета или типа закупки — это лучше формализовать сразу.
Чтобы избежать ручного ввода и ошибок, определите справочники: товары/услуги, подразделения, статьи бюджета, поставщики. Важно согласовать владельца каждого справочника и частоту обновления.
Опишите проверки: обязательность полей, диапазоны сумм, запрет отрицательных значений, контроль лимитов по центру затрат/проекту/статье бюджета.
Для удобства пользователей заложите черновики и шаблоны для повторяющихся покупок: копирование прошлой заявки, предзаполнение реквизитов и автоподстановку аналитик из профиля пользователя.
Маршрут согласования — это набор правил, по которым заявка на закупку проходит через нужных людей и фиксирует их решения. Хорошо спроектированный маршрут сокращает задержки и снижает риск «ручных исключений», которые потом сложно объяснять аудиторам.
Обычно в приложении стоит поддержать несколько типов маршрутов, чтобы покрыть разные случаи без постоянных доработок:
Практика: храните правила в виде настраиваемых условий (конструктор), а не в программировании — так бизнес сможет менять пороги и участников без релиза.
Важно заранее определить, что означает «параллельное согласование»: требуется все “за” или достаточно большинства/одного ответственного.
Чтобы заявки не «зависали», задайте эскалацию: если нет решения за N часов/дней — напоминание, затем передача на замещающего или руководителя.
Добавьте условия автоматического одобрения: мелкие расходы в рамках лимита, типовые позиции у утверждённых поставщиков, повторяющиеся закупки по шаблону.
Возврат должен быть полноценным состоянием процесса: согласующий оставляет комментарий, отмечает обязательные исправления (например, приложить КП, уточнить статью бюджета), а заявка возвращается на конкретный шаг или автору — с сохранением истории изменений и причин возврата.
Бюджетный контроль — это не «бухгалтерия в интерфейсе», а набор простых проверок, которые не дают заявке уйти в работу без денег и прозрачного решения по превышениям.
Практика показывает, что одной проверки недостаточно — лучше поставить «ворота» в нескольких точках:
Минимальный набор, который покрывает большинство компаний:
Важно заранее решить правило приоритета, если заявка попадает в несколько разрезов: например, сперва проверяем проект, затем центр затрат.
Чтобы избежать двойных трат, добавьте резерв:
Пример правила: «Доступный лимит = Лимит периода − Факт расходов − Резервы по согласованным заявкам».
Не блокируйте бизнес «намертво». Лучше сделать управляемые варианты:
Простой пример: лимит 100 000 ₽, уже зарезервировано 80 000 ₽. Заявка на 30 000 ₽ даёт превышение 10 000 ₽ → система добавляет финальное согласование и помечает заявку как «Требует решения по превышению».
Хороший UX в системе закупок — это когда пользователь тратит время на решение, а не на поиск кнопок и справок. В интерфейсах заявок и согласований важно сделать процесс «прозрачным»: где сейчас заявка, кто следующий, что нужно от меня и какие последствия у действия.
Список заявок — стартовая точка для большинства ролей. Он должен отвечать на вопрос «что происходит» за 5–10 секунд: статус, сумма, автор, подразделение, поставщик (если уже выбран), дата создания и крайний срок.
Карточка заявки — место, где принимают решения. Удобно, когда она разделена на блоки: предмет закупки и обоснование, суммы и статьи, вложения, маршрут согласования, история действий.
Экран согласования можно встроить в карточку, но лучше выделить зону фокуса: что согласующий должен проверить (сумма, лимиты, документы, поставщик) и какие действия доступны.
Фильтры должны закрывать типовые запросы: статус, автор, поставщик, сумма, период. Добавьте быстрые пресеты вроде «На мне», «Просроченные», «Требуют уточнения». Поиск — по номеру заявки, названию, комментарию и реквизитам.
В карточке нужна понятная «лента» обсуждения: комментарии, упоминания, прикреплённые файлы, решения и причины отклонения. Критично, чтобы история была неизменяемой и привязана к шагам процесса: тогда легче разбирать спорные ситуации и ускорять повторные согласования.
Для согласующих важны быстрые кнопки: одобрить, отклонить, вернуть на доработку, делегировать. После нажатия показывайте короткое подтверждение с последствиями (например, «уйдёт на финансовый контроль») и обязательные поля (причина отклонения).
Используйте понятные статусы, подсказки к полям и автозаполнение (подразделение автора, валюта, тип закупки, шаблоны позиций). Чем меньше вручную вводят суммы и реквизиты, тем ниже риск ошибок — и тем быстрее проходит согласование.
Правильная модель данных делает согласование заявок на покупку предсказуемым: легко проверять лимиты, находить «узкие места» и не терять историю решений. Ниже — минимальный набор сущностей и то, как обычно устроены статусы и переходы.
В основе веб‑приложения для закупок обычно лежат:
Связи обычно такие: одна заявка → много позиций и одна заявка → много шагов согласования. При этом шаги могут быть последовательными или параллельными (например, финансы и безопасность).
Минимальная цепочка: черновик → на согласовании → одобрено / отклонено. На практике полезно добавить статусы «на доработке» (когда согласующий вернул с комментариями) и «отменено» (когда инициатор снял заявку).
Важно заранее описать правила переходов: кто может переводить в «на согласовании», когда разрешено редактирование позиций, что делать с заявкой после отклонения (создавать новую или переоткрывать старую).
Вложения (КП, спецификации, обоснования) лучше хранить как отдельную сущность, связанную с заявкой/позициями, с политиками:
Если после одобрения меняется сумма или состав позиций, не стоит «тихо» править утверждённую заявку. Практика — вводить версии:
Безопасность в закупках — это не только «защита от взлома», но и предсказуемость процессов: кто имеет право создавать заявки, кто может их согласовывать и как доказать корректность действий при проверках.
Начните с простой, понятной модели прав. Обычно достаточно RBAC (доступ по ролям) с дополнительными ограничителями по организационной структуре.
Например:
Важно предусмотреть делегирование (отпуск/замена) и запрет конфликтов интересов (инициатор не может сам себе финально согласовать).
Если в компании есть SSO (SAML/OIDC), подключайте его: меньше паролей — меньше рисков и обращений в поддержку.
Если SSO нет, задайте минимальные требования:
Для внутреннего контроля нужен аудит: кто, когда и что сделал. Логируйте создание/изменение заявки, смену статусов, комментарии, решения согласующих, изменения маршрутов и лимитов.
Критично обеспечить неизменяемость ключевых событий: записи журнала не должны правиться задним числом даже администратором. Практика — отдельное хранилище для аудита, запрет UPDATE/DELETE (только добавление) и контроль целостности (например, хэш‑цепочки).
Шифруйте данные при передаче (TLS) и «на диске» (шифрование баз/бэкапов). Регулярные резервные копии с проверкой восстановления важнее, чем факт их наличия.
Заранее задайте сроки хранения: заявки и аудит могут храниться дольше операционных данных. Опишите политику удаления/архивации и доступ к архиву — это снижает риски и упрощает проверки.
Хорошие уведомления — это не «спам по каждому чиху», а аккуратное управление вниманием. Согласующий должен быстро понять, что от него нужно, к какому сроку и чем это грозит (например, остановкой закупки).
Сделайте три канала и дайте пользователю (или администратору) настройки: где получать срочное, а где — только сводки. Практика:
Важно: любые уведомления должны вести по прямой ссылке в нужное место, например: /requests/123?tab=approval.
У каждой задачи согласования задайте SLA: срок реакции и срок решения. Напоминания лучше делать ступенчато: за 24 часа до дедлайна, в момент дедлайна и эскалация руководителю через N часов просрочки. При этом учитывайте календарь (выходные/праздники) и часовой пояс.
В интерфейсе согласующего нужна простая «панель принятия решений»: что требует действия сейчас, что просрочено, что вернулось на повторное согласование. Добавьте фильтры по подразделению, сумме, типу закупки и «быстрые действия» (согласовать/вернуть/задать вопрос) без лишних переходов.
Сообщение должно помещаться в один экран и содержать контекст (сумма, поставщик, статья бюджета, дедлайн) и 1–2 ссылки.
Тема: Требуется согласование заявки №{id} до {deadline}
Коротко: {title}
Сумма: {amount} {currency}
Инициатор: {requester}
Открыть заявку: /requests/{id}
Принять решение: /approvals/{approval_id}
Если заявку вернули на доработку, повторное уведомление должно подсвечивать, что именно изменилось: сумма, спецификация, сроки, вложения. Минимум — список изменённых полей и ссылка на сравнение версии: /requests/{id}/changes. Это снижает раздражение и ускоряет повторное решение.
Интеграции определяют, насколько приложение для закупок будет «встроено» в реальные процессы компании. Ошибка на этом этапе часто приводит к двойному вводу данных: заявка живёт в одном месте, бюджет — в другом, а заказ поставщику формируют вручную.
Обычно нужны три потока данных:
Сразу определите «источник истины» (source of truth): где хранятся актуальные цены, карточки поставщиков и итоговые статусы документов. Например, цены могут быть в каталоге, поставщики — в ERP, а статусы согласования — в вашем приложении.
Ключевой сценарий — автоматическое создание заказа (PO/заказ поставщику) после финального одобрения заявки. На практике важно заранее описать:
Для массовых операций удобны CSV/Excel: загрузка номенклатуры, лимитов, матрицы согласующих. При этом лучше добавлять шаблоны и валидацию на импорт.
Для системной интеграции используйте API и вебхуки: события по смене статуса заявки (создана → на согласовании → одобрена → отклонена → заказ создан) позволяют подключать уведомления, задачи в сервис‑деске и обновление данных в ERP. Подробные требования к событиям и идемпотентности запросов стоит зафиксировать заранее в техническом описании (см. /blog/requirements-for-approval-workflows).
Аналитика в веб‑приложении для закупок нужна не «для красоты», а чтобы управлять расходами и дисциплиной процесса. Хороший набор отчётов помогает увидеть, где теряются деньги, время и качество данных — и быстро улучшать правила согласования заявок на покупку.
Начните с понятных срезов:
Руководителям редко нужны детали по каждой заявке. Дайте им панель «сигналов»:
Важно: один клик должен открывать расшифровку до конкретной электронной заявки на закупку.
Добавьте автоматические проверки и отчёты по нарушениям:
Отдельно ведите метрики качества данных: доля заполненных обязательных полей, частота правок после отправки, процент заявок без категории/проекта. Это напрямую влияет на точность аналитики и успешность интеграции с ERP.
Экспорт (XLSX/CSV) нужен, но только с ролевыми ограничениями. Разделяйте доступ к аналитике: финансовые показатели — для уполномоченных, операционные метрики — для руководителей команд. Журналируйте выгрузки так же, как действия в процессе согласования заявок на покупку.
Запуск системы закупок лучше планировать как управляемый процесс: сначала — понятный MVP, затем — пилот, и только после этого масштабирование. Так вы быстрее получите пользу и снизите риск «застрять» на бесконечных доработках.
Для первого релиза достаточно цепочки «заявка → согласование → заказ» и нескольких обязательных вещей вокруг неё:
Важно заранее зафиксировать, что не входит в MVP (например, сложные тендерные процедуры или продвинутые каталоги), чтобы команда не распылялась.
Проверяйте не только «счастливый путь», но и то, что чаще ломается в реальности:
Запускайте пилот на одном подразделении с понятными KPI: доля заявок «в системе», среднее время согласования, количество возвратов.
Обучение делайте коротким: одна страница «как создать заявку», шаблоны заявок под типовые покупки и FAQ «почему вернули на доработку»/«что писать в обосновании».
Собирайте улучшения в backlog и вводите контроль изменений: кто может править маршруты согласования, как согласуются изменения лимитов и правил. Полезно завести регулярный цикл (например, раз в 2–4 недели) с приоритизацией по влиянию на скорость согласований и соблюдение бюджета.
Отдельный практический момент: если вы хотите быстро собрать рабочий прототип внутренних процессов (формы, статусы, роли, уведомления, журнал действий) и показать его бизнесу до начала «тяжёлой» разработки, можно использовать TakProsto.AI. Это vibe‑coding платформа для российского рынка: вы описываете процесс и экраны в чате, а система помогает собрать веб‑приложение на React с бэкендом на Go и PostgreSQL, с возможностью выгрузки исходников, деплоя, снапшотов и отката. Такой подход удобен именно на этапе MVP и пилота, когда важно быстро проверить маршруты согласования и модель данных на реальных пользователях.
Для MVP достаточно замкнуть базовую цепочку: заявка → согласование → заказ → приёмка.
Практичный минимум:
Сфокусируйтесь на процессах с быстрым эффектом:
Это обычно даёт сокращение времени цикла и меньше возвратов на доработку.
Минимальный набор ролей:
Соберите минимально необходимые данные, чтобы заявку можно было проверить и провести дальше:
Отдельно решите, будет ли заявка построчной (несколько позиций) или одним лотом — это влияет на лимиты и структуру данных.
Заранее зафиксируйте типы файлов и условия обязательности, чтобы избежать постоянных возвратов:
Практика: обязательность зависит от суммы, категории или статьи бюджета, и это лучше оформить как правила в системе.
Хороший маршрут должен быть настраиваемым, а не «зашитым» в программирование.
Базовые критерии маршрутизации:
Для параллельных шагов заранее определите правило: нужно или достаточно .
Чтобы заявки не «висели», задайте управляемые механики:
Важно: любое действие должно оставлять след в истории (кто, когда, почему).
Обычно ставят бюджетные «ворота» в нескольких точках:
Чтобы избежать двойных трат, используйте резервирование: резерв создаётся после одобрения и уменьшает доступный лимит до заказа.
Сделайте возврат отдельным состоянием процесса:
Если после одобрения меняются сумма или состав позиций, используйте версии и запускайте повторное согласование только по затронутым правилам.
Минимальные интеграции обычно такие:
Определите «источник истины» для каждого справочника и продумайте обмен:
Чёткие роли упрощают права доступа и правила маршрутизации.