Пошаговый план, как спроектировать веб‑приложение для прайс‑листов и договоров поставщиков: роли, данные, импорт, согласование, аудит, интеграции и безопасность.
Главная цель такого веб‑приложения — стать единым источником правды по ценам и коммерческим условиям поставщиков: что именно мы покупаем, по какой цене, на каких условиях, в какой период это действует и на каком документе основано.
Когда прайсы приходят в почту, мессенджеры и файлы «Финал_финал2.xlsx», а договоры лежат в разных папках, компания теряет управляемость. В итоге решения принимаются по устаревшим данным, а ответственность «размазана» между отделами.
Приложение собирает в одном месте:
Идеальная картина: пользователь открывает карточку товара или поставщика и видит актуальную цену, дату вступления в силу, источник (прайс/договор) и кто это утвердил.
Дальше разберём путь от требований и MVP до внедрения: как описать сценарии, выстроить модель данных, организовать импорт и нормализацию прайсов, настроить версионирование и согласование, контролировать сроки договоров, продумать роли/права и аудит, подключить интеграции (например, с 1С) и подготовить отчётность. Это позволит запустить систему без лишней сложности и спокойно развивать её после MVP.
Хороший MVP начинается не с экранов, а с договорённостей: кто работает в системе, какие решения принимает и что считается «успехом». Для приложения прайсов и договоров важно сразу описать минимальный набор сценариев, который даст бизнес‑эффект уже в первом релизе.
Соберите список ролей и зафиксируйте, что каждая из них делает в системе:
Обычно хватает 3–4 сквозных сценариев:
Загрузка прайса (закупщик или поставщик) → проверка формата → нормализация → статус «на согласовании».
Согласование цен → комментарии и правки → итоговое «утверждено/отклонено».
Подписание и хранение договора → прикрепление скана/файла → контроль сроков действия.
Продление → напоминания → создание новой версии условий без потери истории.
Чтобы MVP не превратился в «просто хранилище файлов», заранее задайте метрики:
Зафиксируйте ограничения: регламенты согласования, допустимые форматы документов (XLSX/CSV/PDF), требования к доступам и журналу действий.
Согласуйте, что точно делаем в первом релизе (статусы, роли, базовые уведомления, простой маршрут согласования), а что переносим: сложные матрицы маршрутов, тонкую настройку прав по атрибутам, продвинутую аналитику, редактирование прайса «внутри» системы. Это снижает риск затянуть запуск и позволяет быстро проверить ценность.
Если задача — быстро проверить гипотезу и показать работающий прототип бизнесу, полезно рассмотреть подход vibe‑coding. Например, в TakProsto.AI можно собрать каркас приложения (React‑интерфейс, сервер на Go, PostgreSQL), описав сценарии и сущности в формате требований и экранов прямо в чате. Это не заменяет постановку задач и контроль качества, но заметно ускоряет первые итерации: импорт прайса, статусы согласования, карточки договоров, базовый аудит и экспорт.
Дополнительно удобно, что платформа поддерживает экспорт исходников, снапшоты и откат (rollback), а также развёртывание и хостинг с хранением данных на серверах в России — это часто критично для закупочных и юридических контуров.
Чтобы веб‑приложение для закупок не превращалось в «табличный хаос», начните с простой, но точной модели данных. Она должна поддерживать управление прайс‑листами поставщиков, реестр договоров поставщиков и последующее версионирование прайс‑листов без переделок.
Базовая сущность — поставщик: реквизиты и контакты, статусы (активен/на проверке/заблокирован), категории и привязка к филиалам или юрлицам вашей группы. Важно хранить несколько контактных лиц (для цен, логистики, договоров) и служебные поля для аудита изменений (кто и когда обновил данные).
Номенклатура — это не «строка из прайса», а нормализованный справочник: SKU/артикул, единицы измерения, упаковки, коэффициенты пересчёта, аналоги/замены. Если у вас есть главный справочник (например, в 1С), заранее заложите поле внешнего идентификатора для интеграции и сопоставления.
Прайс‑лист хранит не только цены, но и контекст: период действия, валюта, минимальная партия, условия поставки/оплаты, склад/регион (если влияет на цену). Каждая позиция прайса должна ссылаться на номенклатуру и содержать цену, НДС/ставку, кратность, сроки поставки.
В договоре фиксируются номер, тип, даты (подписания/начала/окончания), ответственные, лимиты, приложения и сканы. Полезно выделить «сроки уведомлений» для контроля сроков договоров.
Ключевой вопрос — какой договор покрывает какой прайс и для каких товаров. На практике это решается связью «договор—прайс» (один договор может покрывать несколько прайсов) и правилами применимости на уровне позиций (категория, филиал, бренд, группа товаров). Это упрощает согласование цен и делает последующие проверки (лимиты, сроки, актуальность) более автоматическими.
Импорт — это точка, где поставщик чаще всего «спотыкается»: у каждого свой формат, названия колонок и правила округления. Поэтому важно сделать загрузку предсказуемой и максимально самообслуживаемой, чтобы команда закупок не превращалась в техподдержку.
Начните с поддержки XLSX и CSV — этого достаточно для большинства поставщиков. В интерфейсе загрузки дайте:
Если поставщик загрузил «свой» файл, система должна предложить сопоставить колонки (маппинг) один раз и сохранить как шаблон для следующих загрузок.
Проверки лучше разделить на блокирующие и предупреждения. Типовые блокировки:
Предупреждения: подозрительно большие скачки цены, отсутствие штрихкода, неизвестная единица измерения.
Нормализация должна приводить строки прайса к вашей «канонической» номенклатуре:
Ключевой принцип: каждое решение по сопоставлению сохраняется как правило для будущих импортов.
Импорт делайте пакетным: файл принимается, ставится в очередь, а поставщик получает понятный отчёт об ошибках (скачать CSV/Excel с проблемными строками и комментариями).
Обязательно храните оригинальный файл и результат нормализации (например, в виде таблицы и экспортируемого файла) — это упрощает разбор спорных ситуаций и повторную обработку без повторной загрузки.
Чтобы закупки не «жили в письмах», прайс должен быть не просто файлом, а набором версий с понятной историей: кто загрузил, когда, на основании какого договора и какие строки реально изменились. Это снижает споры, ускоряет согласование и помогает быстро восстановить факты.
Каждая загрузка создаёт новую версию с метаданными: поставщик, источник (портал/почта/интеграция), автор, дата и комментарий. Полезно хранить также хэш файла и результат нормализации (сколько строк распознано, какие ошибки).
Минимальный набор полей версии:
Пользователю важна разница по позициям: какие цены изменились, что добавилось, что удалилось. Покажите дифф в терминах каталога: товар/артикул/единица измерения/цена/валюта/минимальная партия.
Такой дифф должен уметь подсветить:
Частый кейс — поставщик заранее присылает прайс «с 1 числа». Поэтому у строки цены должны быть даты действия: дата_начала и дата_окончания (опционально). Это позволяет отложенную активацию без ручных напоминаний.
Если периоды пересекаются, система должна действовать предсказуемо: например, запрещать пересечения для одной и той же позиции и договора, или разрешать только при более высоком приоритете (акция поверх базовой цены) с обязательным комментарием.
Полная история изменений (версия → кто/когда/почему → дифф) становится доказательной базой для разборов: почему цена в заказе отличалась, кто утвердил, какие условия действовали на дату поставки. Это также поддерживает требования по ролям, правам доступа и внутреннему контролю без лишней бюрократии.
Хаос в ценах чаще всего возникает не из‑за ошибок в файлах, а из‑за неясного процесса: кто должен проверить, в какие сроки и по каким правилам можно принять новые условия. Поэтому для прайсов важен понятный «конвейер» согласования — с прозрачными статусами, комментариями и фиксированными решениями.
Задайте простой набор статусов и не усложняйте переходы:
черновик → на согласовании → утверждено → активно → архив.
Черновик — поставщик или менеджер загрузил прайс и заполнил основные атрибуты. «На согласовании» — документ зафиксирован, редактирование ограничено (только через возврат на доработку). «Утверждено» — решение принято, но ещё не применено. «Активно» — цены и условия действуют в закупках. «Архив» — старые версии для истории.
Маршруты стоит строить не «по фамилиям», а по понятным правилам:
Так вы избегаете ручной настройки под каждый прайс и получаете предсказуемые сроки.
В интерфейсе согласования важны две кнопки: «Утвердить» и «Вернуть на доработку».
При возврате система должна требовать комментарий и собирать список замечаний (по строкам прайса, по условиям поставки, по минимальной партии). Это превращает «переделайте» в конкретные задачи и сокращает итерации.
Уведомления делайте двух типов: email и внутренние. Полезны напоминания по срокам: кому согласовать до даты, когда заканчиваются текущие условия.
Обязательно ведите журнал решений: кто, когда и почему утвердил/отклонил. Это помогает в спорных ситуациях, при проверках и просто дисциплинирует процесс — решения становятся аргументированными, а не «на словах».
Договоры лучше хранить не «как файлы в папке», а как управляемые записи с понятными статусами и сроками. Тогда закупки и финансы видят одну и ту же картину: что действует, что на согласовании, а что уже пора продлевать.
В карточке договора фиксируйте минимум, который нужен для работы без лишних переписок:
Важно: привязка к прайсу должна быть не просто ссылкой на файл, а на конкретную версию прайс‑листа, чтобы условия можно было восстановить «как было на дату».
Система должна сама следить за датами:
Удобно, когда на карточке есть «таймлайн»: подписан → действует → скоро окончание → продлён/закрыт.
Приложения (спецификации, допсоглашения) ведите как отдельные сущности с:
Нужны быстрые фильтры: по контрагенту, статусу, ответственному, диапазону дат, признаку «скоро заканчивается».
Добавьте шаблоны документов и чек‑лист обязательных вложений (скан, спецификация, реквизиты, доверенность). Это снижает риск «подписали, но забыли приложить важное» и ускоряет цикл согласования.
Ошибки в прайсах и договорах часто возникают не из‑за «плохих данных», а из‑за неясных полномочий: кто может править, кто утверждает, кто просто смотрит. Поэтому доступы и аудит лучше заложить в MVP сразу — иначе позже придётся «разматывать» конфликты и искать виновных вручную.
Используйте RBAC (role-based access control) с понятными правами: просмотр, редактирование, утверждение, экспорт. Обычно хватает ролей вроде «Закупки», «Юрист», «Финансы», «Администратор», а также «Наблюдатель» для чтения.
Важно разделить права на уровне объектов:
Добавьте ограничения по подразделениям/филиалам: сотрудник видит только «свои» договоры и прайсы, а не весь реестр. Для портала поставщика правило ещё жёстче: поставщик имеет доступ только к собственным загрузкам, своим договорам и протоколам согласования.
Аудит‑лог должен отвечать на вопросы «кто», «что», «когда» и «из какого контекста». Минимальный набор:
Файлы прайсов и договоров храните с проверкой прав на скачивание, сроками хранения и понятными правилами удаления/архивации. Если есть риск пересылки «вовне», добавьте водяные знаки на выгрузки (например, дата, пользователь, подразделение).
Начните с простого: сильные пароли или SSO, 2FA при наличии, ограничение массовых выгрузок (лимиты, очереди, запрет «скачать всё» без отдельного права), защита от перебора и ботов. Для прозрачности можно вести отчёт «кто что экспортировал» и показывать его руководителю закупок.
Портал поставщика — это «входная точка», где контрагент сам загружает прайс‑лист, видит статус проверки и быстро отвечает на замечания. Чем понятнее интерфейс, тем меньше ручной переписки и тем быстрее прайс доходит до закупок в корректном виде.
В личном кабинете поставщик должен видеть понятный маршрут: черновик → загружено → на проверке → есть замечания → согласовано/отклонено. Рядом — краткая история: кто и когда оставил комментарий, какие файлы приложены, что требуется исправить.
Полезно добавить карточку последней успешной загрузки и кнопку «загрузить новую версию», чтобы поставщик не создавал дубли.
Чтобы снизить процент ошибок, дайте поставщику:
Ссылки на материалы лучше держать внутри портала, например: /help/supplier-price-template и /help/how-to-upload.
Вместо длинных писем удобнее комментарии прямо по позициям прайса: закупщик пишет замечание к конкретной строке, поставщик отвечает там же. Дополнительно предусмотрите прикрепление подтверждающих документов (письмо производителя, спецификация, скрин счёта) к позиции или к загрузке целиком.
Заранее задайте правила, чтобы портал оставался управляемым:
При нарушении — понятное сообщение, что именно исправить.
Сделайте короткий онбординг: 3–5 шагов с «первой загрузкой», чек‑листом и мини‑сценариями («как ответить на замечание», «как заменить файл», «где посмотреть статус»). Это снижает нагрузку на поддержку и ускоряет согласование с первых дней.
Интеграции — это то, что превращает реестр прайсов и договоров в рабочий инструмент закупок, а не в «ещё одну таблицу». На старте важно определить 2–3 ключевые системы и договориться, где хранится «истина» по справочникам и ценам.
Чаще всего нужны:
Минимальный набор синхронизации: номенклатура, контрагенты, единицы измерения. Практика: назначить внешний ключ (например, erp_id) и хранить соответствия. Если у поставщика свои коды — поддержать таблицу маппинга и правила автосопоставления (по штрихкоду, артикулу, названию + производителю).
Заранее фиксируется правило: например, утверждённый прайс в приложении является источником истины для закупочных цен, а ERP — для фактических документов. При конфликте (в ERP цена уже изменена) полезны варианты: блокировка выгрузки, создание инцидента на согласование, либо приоритет по дате/статусу («утверждено» всегда выше).
Для MVP достаточно REST API:
GET /api/v1/suppliers, POST /api/v1/suppliersGET /api/v1/items, POST /api/v1/mappingsPOST /api/v1/price-lists:import, GET /api/v1/price-lists/{id}POST /api/v1/contracts, GET /api/v1/contracts/{id}Доступ — по токенам (service accounts), с правами по ролям. Добавьте лимиты (например, 60 запросов/мин) и идемпотентность на импорт.
Вебхуки ускоряют интеграции без опроса: price_list.approved, contract.expires_soon, mapping.conflict_detected.
Сделайте выгрузки в XLSX/CSV: текущие цены по поставщикам, история изменений за период, реестр договоров с датами окончания и ответственными. Это закрывает потребность «быстро отдать отчёт» даже до полной автоматизации в 1С/ERP.
Отчётность — это место, где система перестаёт быть «хранилищем файлов» и становится инструментом управления: показывает, что требует решения сегодня, где риски по срокам и какие цены «поехали».
Сделайте стартовую страницу для закупок и финансов с несколькими понятными блоками:
Важно: каждый блок должен проваливаться в список с фильтрами, а не быть «красивой картинкой».
Мониторинг изменений цен лучше строить как правила, которые легко объяснить бизнесу:
Сигнал должен показывать: что изменилось, на сколько, с какого прайса/версии, кто загрузил и в каком статусе согласование.
Минимальный набор отчётов для MVP:
Добавьте поиск по документам и метаданным (поставщик, договор, номер, период, категория) и быстрые фильтры. Выгрузки — в XLSX/CSV, а для регулярных задач — расписание отправок на почту или в корпоративный канал уведомлений (например, «каждый понедельник список договоров, истекающих в ближайшие 30 дней»).
На этапе MVP важнее предсказуемость и скорость изменений, чем идеальная «микросервисность». Поэтому чаще всего выигрывает аккуратный монолит: один серверный проект, единая база, понятная схема деплоя. При этом стоит сразу заложить модульную структуру внутри проекта (прайсы, договоры, согласование, аудит), чтобы позже без боли выделять сервисы при росте нагрузки.
Основные сущности (поставщики, товары, строки прайсов, договоры, статусы согласования) удобно хранить в реляционной БД — так проще поддерживать связи, ограничения и отчёты. А исходные файлы прайс‑листов и приложений к договорам лучше отправлять в объектное хранилище (S3‑совместимое или аналог): дешевле, надёжнее, проще управлять версиями файлов.
Импорт прайса, нормализация, сверки и рассылка уведомлений не должны «висеть» в запросе пользователя. Вынесите их в фоновые задачи через очередь (например, Redis/RabbitMQ). Пользователь загрузил файл — получил статус «в обработке», а результат увидит через пару минут.
Дайте системе базовую «гигиену»:
Минимальный набор для спокойной эксплуатации: регулярные резервные копии БД, журналирование действий и ошибок, алерты по сбоям импорта и недоступности хранилища. Если нужно — добавьте страницу /status для быстрой проверки состояния ключевых компонентов.
Запуск такого приложения лучше планировать как управляемый проект, а не «большой взрыв». Цель этапа после разработки MVP — быстро получить пользу, не сломав текущие процессы закупок и работы с поставщиками.
Начните с пилота на 1–2 поставщиках: одном «простом» (типовой прайс, минимум исключений) и одном «сложном» (нестандартные колонки, частые изменения цен). На пилоте вы проверите не только импорт, но и реальные ожидания пользователей: кто инициирует загрузку, кто согласует, кто утверждает.
После пилота закрепите правила: какие статусы используются, кто владелец данных по поставщику, какой SLA по согласованию. Затем подключайте поставщиков волнами — например, по 5–10 в неделю.
Чтобы MVP сразу стал рабочим инструментом, перенесите минимум:
Не пытайтесь с первого дня «оцифровать всё прошлое». Историю можно добавлять выборочно, когда появится понятный запрос.
Проверяйте импорт на реальных прайс‑листах поставщиков: разные форматы, кодировки, «кривые» заголовки, объединённые ячейки. Отдельно прогоните сценарии прав доступа и согласования: кто видит черновик, кто может утверждать, что происходит при откате/перезагрузке файла.
Сделайте короткие регламенты на 1–2 страницы, шаблоны прайс‑листов и FAQ для поставщиков. Полезно добавить страницу /help с примерами типовых ошибок импорта и их исправления.
Собирайте улучшения в бэклог и приоритизируйте по экономии времени и снижению рисков: правила ценообразования (наценки/скидки), расширенная аналитика, автосверки с учётной системой, уведомления о расхождениях и аномалиях.
Лучший способ понять возможности ТакПросто — попробовать самому.