План создания веб‑системы для RFQ: роли, этапы процесса, модель данных, сбор и нормализация котировок, удобное сравнение предложений и безопасность.
RFQ (Request for Quotation, «запрос котировок») — это формализованный запрос цены и условий поставки на конкретный товар или услугу с заранее заданными параметрами: количество, сроки, Incoterms/доставка, гарантия, сервис, валюта и т. п. Главная задача RFQ — получить сопоставимые предложения и выбрать лучший вариант по понятным критериям.
Важно не путать RFQ с другими форматами:
В реальных закупках RFQ часто живёт в письмах и Excel. Отсюда типовые проблемы: разные версии файлов, «потерянные» правки, неполные ответы, несогласованные единицы измерения, хаос в комментариях и неочевидно, почему выбран именно этот поставщик.
Отдельная боль — ручное сведение котировок: кто-то прислал цену с НДС, кто-то без; сроки указаны в рабочих днях, а не календарных; доставка включена только у части участников. Приложение должно снимать именно эти «трения», а не просто дублировать табличку в вебе.
Система должна ускорять сбор предложений и приводить ответы к единому формату, чтобы сравнение было честным и быстрым. Покупатель получает прозрачную картину: кто ответил, на какие позиции и на каких условиях; поставщик — понятную форму без лишних шагов.
Итоговый результат — сравнение в таблице, расчет TCO (полной стоимости владения) и фиксируемое обоснование выбора.
Заранее определите, для каких сценариев делается система: прямые закупки (сырьё, компоненты) или непрямые (услуги, офисные категории), а также поддерживаются ли единичные заявки или рамочные предложения (на период/объём).
Эти границы помогают не раздувать MVP и не смешивать разные процессы в одном интерфейсе.
Чёткие роли — основа понятного workflow закупок: кто инициирует RFQ, кто оценивает, кто отвечает, а кто только наблюдает и согласует. Если не договориться об этом заранее, система быстро превращается в «чат с файлами» и несколькими версиями правды.
Инициатор создаёт RFQ, заполняет позиции, сроки и условия, выбирает круг поставщиков и публикует запрос. На нём же — коммуникации: ответы на вопросы, уточнения, напоминания и фиксация договорённостей прямо в карточке RFQ (а не в почте).
Категорийный менеджер задаёт правила игры: критерии оценки (цена, сроки, условия оплаты, сервис, риски), веса, требования к документам и минимальные условия допуска. Он же принимает финальное решение — либо инициирует дополнительный раунд.
Для поставщика важна простота: открыть приглашение, заполнить предложение, задать вопросы и приложить файлы (коммерческое предложение, спецификацию, сертификаты). Хорошая практика — ограничить количество полей до нужного минимума и поддержать черновики, чтобы участник не терял прогресс.
Администратор отвечает за справочники и правила: единицы измерения, валюты, шаблоны RFQ, роли и доступы, политики хранения файлов, сроки хранения и аудит действий. Это снижает хаос и упрощает безопасность закупок.
Эти роли обычно не «ведут» RFQ, но влияют на исход: просматривают предложения, оставляют комментарии, участвуют в согласовании условий и проверке рисков. Для них важно разграничение прав: видеть, но не менять; комментировать, но не редактировать цифры.
Практический ориентир: у каждой роли должно быть 1–2 ключевых действия и понятный уровень доступа (просмотр, комментарии, редактирование, утверждение). Это ускоряет сравнение и снижает число спорных правок.
Эффективный workflow RFQ держится на простом принципе: покупатель задаёт правила один раз, а система дальше «ведёт» процесс и фиксирует всё важное — сроки, версии, ответы и решения.
Покупатель создаёт RFQ в статусе «Черновик»: описание потребности, позиции, условия поставки/оплаты, требования к документам и дедлайн. В черновике удобно согласовать текст внутри компании.
После публикации RFQ получает неизменяемый номер и версию, а выбранным поставщикам уходят приглашения (ссылка на портал и срок подачи). Важно, чтобы приглашения можно было отправлять волнами: добавили поставщика — он видит актуальную версию.
Поставщики задают вопросы в отдельном потоке Q&A. Для каждого вопроса фиксируются автор, время и статус ответа.
Ключевой момент — настройка видимости: ответ может быть «только этому поставщику» или «публично для всех приглашённых», чтобы выравнивать условия и снижать риск разночтений.
До дедлайна поставщик может сохранять черновик предложения и отправить финальную версию. Система проверяет полноту: заполнены цены, сроки, приложены обязательные файлы, подтверждены условия. После дедлайна — только просмотр (или приём по регламенту с отметкой «поздно»).
Покупатель сравнивает предложения и при необходимости отправляет запрос уточнений по конкретным строкам или условиям (с отдельным сроком ответа). Затем формируется короткий список финалистов.
Решение фиксируется протоколом: кто победил, по каким критериям, какие отклонения приняты. Далее — экспорт в файл или передача в закупочную систему, чтобы не переносить данные вручную.
На старте важно зафиксировать границы первой версии: цель MVP — провести RFQ «от публикации до сравнения» без ручных таблиц и бесконечных уточнений по почте. Всё, что не влияет на этот путь напрямую, лучше отложить.
Создание RFQ: покупатель задаёт сроки, условия, список позиций и критерии оценки.
Приглашения поставщиков: выбор из списка/ввод e‑mail, отправка ссылок, контроль статуса «приглашён/открыл/ответил».
Подача предложений: поставщик заполняет цену и условия по каждой позиции, прикладывает файлы (прайс, спецификацию), может сохранить черновик и отправить финально.
Сравнение предложений: таблица по позициям и итогам, базовый расчёт итоговой стоимости и подсветка несоответствий.
Чтобы предложения были сопоставимы, договоритесь о «жёстком минимуме»:
Справочники для MVP: валюты, единицы измерения, (опционально) типы НДС/налога, шаблоны условий.
Без сложных согласований, многоуровневых ролей, EDI/ERP‑интеграций и продвинутых правил доступа по подразделениям. Эти вещи часто «съедают» сроки — лучше планировать их после пилота.
Заложите измеримость с первого дня:
Даже в MVP стоит поддержать несколько валют и конвертацию «для сравнения» (с указанием курса и даты), а также нормализацию единиц измерения (например, штуки/упаковки). Это снижает риск некорректных итогов и повышает доверие к сравнительной таблице.
Хорошая модель данных RFQ — основа для удобного workflow закупок: без неё невозможно корректно собирать предложения, сравнивать «яблоки с яблоками» и вести аудит.
Практичный подход: сразу отделить «запрос» (RFQ) от «позиций» (line items) и от «котировок» (quotes), чтобы поставщики могли отвечать частично, а покупатель — сравнивать по строкам.
Сущность RFQ обычно хранит метаданные и управление жизненным циклом:
Связи: RFQ 1→N к позициям и 1→N к приглашённым поставщикам.
Позиции — это то, что реально сравнивается:
Важно: требования лучше хранить структурировано (поля/атрибуты) плюс вложения — так поставщику проще отвечать в одном формате.
Сущность Поставщик и связанные Контакты поддерживают управление поставщиками:
Связи: поставщик 1→N контактов; поставщик N↔N RFQ через таблицу «приглашения» (с датой приглашения и статусом участия).
Котировка привязывается к конкретному RFQ и поставщику и содержит:
Рекомендуется хранить версионность котировки (черновик/отправлено/отозвано) и историю изменений.
Чтобы снизить хаос в переписке, полезно завести сущности:
Это упрощает контроль, соответствие требованиям и разбор спорных ситуаций без поиска «по письмам».
Покупательский интерфейс — место, где RFQ формируется быстро и без ошибок. Хорошая цель: менеджер закупок создаёт запрос за 10–15 минут, а коллеги понимают, что именно ушло поставщикам.
Сделайте форму «живой»: автосохранение черновика каждые 10–20 секунд и явный индикатор статуса (Черновик → На согласовании → Опубликован). Если пользователь закрыл вкладку, он должен вернуться туда, где остановился.
Проверки заполнения лучше разделить на два уровня:
Для большинства RFQ позиции удобнее импортировать. Дайте шаблон с колонками (SKU/описание, количество, единица, требуемый срок, комментарий) и встроенную валидацию:
Показывайте результат импорта как предпросмотр с подсветкой проблем, чтобы пользователь исправил всё до публикации.
Изменения после отправки неизбежны. Версионирование должно отвечать на два вопроса: «что изменилось?» и «кого уведомить?». Покажите дифф: новые/удалённые позиции, изменение количеств, дедлайна, требований.
При публикации новой версии добавьте выбор уведомлений: всех приглашённых поставщиков или только тех, кто уже начал отвечать.
До публикации задайте критерии сравнения: цена, срок, качество/соответствие, риски (например, наличие сертификатов). Важно разрешить разные веса критериев по категориям.
Права доступа: кто может редактировать, кто — публиковать, кто — только просматривать. Типовой минимум — роли «Автор», «Согласующий», «Публикатор» плюс журнал действий для внутреннего контроля.
Портал поставщика решает одну задачу: быстро и без ошибок довести участника до отправки котировки. Чем меньше «трения» (лишних полей, непонятных требований, повторной авторизации), тем выше шанс получить предложение вовремя и в сравнимом виде.
Оптимальный старт — приглашение по email с одноразовой ссылкой. По ней поставщик сразу попадает в нужный RFQ, без поиска и ручного ввода идентификаторов.
Дайте варианты: регистрация (для постоянных поставщиков) или гостевой доступ (для разовых). В обоих случаях важно явно показать, что именно будет видно покупателю и какие данные обязательны.
На главном экране достаточно списка RFQ с простыми статусами: «Приглашён», «Черновик», «Отправлено», «Отозвано», «Просрочено». Рядом — дедлайн, контакт закупщика и быстрый переход к форме.
Полезная деталь: предупреждение за 24/3 часа до дедлайна прямо в интерфейсе, чтобы поставщик не пропустил срок.
Форма должна повторять структуру запроса: котировка по позициям (цена, валюта, минимальная партия, срок поставки, срок действия цены) и блок «общие условия» (оплата, инкотермс/доставка, гарантия, комментарии). Валидации — «на месте»: например, запрет отрицательных цен и подсветка обязательных полей.
Добавьте загрузку документов (сертификаты, спецификации) с ограничениями типов и размеров: PDF/DOCX/XLSX/JPG, лимит на файл и общий лимит на заявку. Покажите список вложений, кто их увидит, и фиксируйте версии при обновлениях.
Перед отправкой — короткое подтверждение с итогом (количество позиций, сумма/диапазон, валюта, сроки). После отправки котировку стоит разрешить отозвать или обновить до дедлайна: при каждом изменении фиксируйте время и причину, чтобы покупателю было проще ориентироваться в актуальной версии.
Даже идеальный RFQ превращается в «яблоки против апельсинов», если поставщики присылают цены в разных валютах, с разными единицами измерения и по-разному трактуют налоги и скидки. Поэтому сбор предложений — это управляемый процесс приведения данных к единому стандарту.
Сделайте так, чтобы система не принимала предложение, пока не заполнены обязательные поля и не пройдены базовые проверки:
Проверки лучше делать и на фронтенде (для удобства), и на сервере (для надёжности).
После сохранения предложения система должна рассчитывать «нормализованные» значения, не затирая оригинал:
Храните вместе с расчётом и курс, и дату курса — иначе позже будет сложно объяснить происхождение цифр.
Разрешите поставщику честно указать отклонения: аналог вместо запрошенной модели, минимальная партия, частичная поставка по графику. Для этого удобно разделять:
Коммерческое предложение в PDF удобно приложить, но сравнение требует структуры. Практика: хранить строки и условия в базе, а файлы — отдельно (как вложения с версией и хешем). Так и аудит проще, и поиск работает.
Заранее определите политику: автоматически помечать опоздавшие предложения как «late», запрещать редактирование после дедлайна, но разрешать просмотр и отдельное одобрение покупателем. Это снимает споры и сохраняет прозрачность процесса.
Хорошее сравнение котировок — это не «кто дешевле», а быстрый способ увидеть разницу по каждой позиции, понять полную стоимость владения (TCO) и зафиксировать обоснование выбора.
Основа интерфейса — таблица «позиции × поставщики». Для каждой позиции показывайте ключевые поля: цена, срок поставки, MOQ (минимальная партия), условия оплаты/поставки, срок действия предложения.
Поддержите «несовпадения»: если поставщик предложил аналог/замену, это должно быть видно (например, метка «эквивалент», комментарий и ссылка на спецификацию).
Рядом с ценой по позиции и итогом по поставщику выводите составляющие полной стоимости:
Пользователь должен видеть, что именно включено в итог и откуда берутся цифры.
Чтобы не утонуть в данных, добавьте фильтры и группировки: по поставщику, по позиции/категории, по отклонениям от требований, по рискам (например, просрочки, отсутствие сертификатов, нестабильные сроки).
Сделайте балльную модель с настраиваемыми весами (цена, срок, качество, условия). Разрешите ручную корректировку балла, но обязательно требуйте короткое объяснение — это дисциплинирует и помогает в аудите.
Экспорт отчёта в PDF/XLSX должен включать таблицу сравнения, расчёт TCO, применённые фильтры/веса и «протокол выбора» (кто и когда утвердил, почему выбран поставщик). Это экономит время на согласованиях и снижает спорные ситуации.
Даже идеальная форма RFQ не спасёт процесс, если вопросы, уточнения и договорённости живут в разрозненных письмах и чатах. Встроенные коммуникации делают закупку «самодокументируемой»: что спросили, кто ответил, когда изменили требования и почему выбрали конкретного поставщика.
Покупателю обычно важны короткие обсуждения прямо в контексте позиции или всего RFQ: комментарии, упоминания коллег и мини‑задачи.
Практичный минимум:
Так меньше переписок, а новым участникам проще понять, что уже решено.
Поставщики почти всегда задают вопросы: про аналоги, сроки, упаковку, требования к документам. Удобно поддержать два режима:
Критически важна история: вопрос, ответ, кто автор, версия спецификации на момент ответа. Тогда изменения требований не превращаются в спор.
Уведомления должны быть событийными и управляемыми: публикация RFQ, изменения в спецификации, новые вопросы/ответы, напоминания о дедлайне, «котировка отправлена/обновлена». Дайте настройки частоты (сразу/дайджест) и канала (почта, внутри приложения).
Начните с простого: почтовые уведомления и SSO (например, SAML/OIDC) для корпоративных аккаунтов. Дальше — интеграции через API: выгрузка выбранного предложения в ERP/CRM, синхронизация справочников контрагентов, статусы согласований. Полезно предусмотреть вебхуки «RFQ опубликован», «дедлайн изменён», «поставщик подал котировку».
Аудит‑лог помогает разбирать спорные ситуации и готовить внутренние отчёты: кто пригласил поставщика, кто менял условия, когда открывали и сравнивали предложения. Делайте логи неизменяемыми, с фильтрами и экспортом — это снижает риски и ускоряет внутренние проверки.
Безопасность в RFQ‑системе — это не только «логин и пароль». Здесь важно защитить коммерческие условия, зафиксировать историю решений и исключить подмену данных — иначе сравнение котировок теряет смысл.
Задайте роли и права так, чтобы пользователь видел только то, что нужно для его задачи: покупатель — свои RFQ и ответы, поставщик — только приглашённые запросы, руководитель — отчёты и утверждения.
Практика: отдельные разрешения на создание RFQ, приглашение поставщиков, просмотр цен, утверждение выбора, выгрузку файлов.
Частая ошибка — показывать предложения сразу всем участникам процесса. Правильнее: до дедлайна котировки «запечатаны» (никто со стороны покупателя не видит суммы), после — открываются для сравнения.
Если нужен дополнительный контроль, добавьте режим «двух ключей»: открытие только после подтверждения двумя ответственными.
Встроенный журнал действий должен отвечать на вопросы «кто, что, когда и откуда изменил»:
Сделайте экспорт журнала (CSV/PDF) и неизменяемые события для критичных действий.
Шифруйте данные «в пути» и «в покое», храните файлы с ограниченными ссылками и сроком жизни. Настройте резервное копирование с проверкой восстановления и политику хранения: сколько держим котировки и вложения, когда удаляем, кто может запросить удаление.
Введите версионирование RFQ и котировок. После утверждения ключевые поля должны стать неизменяемыми (только новая версия или формальный процесс исправления с причиной и согласованием). Это снижает риск манипуляций и упрощает проверку.
Для RFQ‑системы чаще всего не нужен «космический» стек. Важнее предсказуемость, безопасность и удобная поддержка. Стартуйте с простого решения, которое можно масштабировать без переписывания.
Для MVP обычно выигрывает модульный монолит: единое приложение, общая база, понятный деплой.
Когда появятся признаки роста (много интеграций, отдельные команды, нагрузка на загрузку файлов/уведомления), можно выделять сервисы по доменам: уведомления, поиск, импорт/экспорт, расчёт TCO. Это помогает избежать преждевременной сложности и оставить пространство для эволюции.
REST хорошо подходит для типовых операций (RFQ, позиции, котировки, статусы), особенно если планируются интеграции с ERP/почтой/SSO.
GraphQL удобен для «толстых» экранов сравнения, где нужен один запрос с вложенными данными. Практичный подход — начать с REST и точечно добавить GraphQL позже.
Обязательно продумайте:
Для RFQ и котировок чаще всего оптимальна реляционная БД (PostgreSQL): связи, транзакции, аудит.
Файлы (ТЗ, спецификации, прайсы) лучше хранить в объектном хранилище (S3‑совместимом), а в БД — только метаданные и ссылки.
Для поиска и фильтрации начните с индексов и продуманной схемы; полнотекст подключайте по необходимости.
Наблюдаемость — не роскошь: централизованные логи, метрики (время ответа, ошибки, очереди), трассировка и алерты помогут находить проблемы до жалоб пользователей.
Если цель — быстро проверить гипотезу и провести пилот, разумно собрать первую версию на платформе TakProsto.AI. Это vibe‑coding подход: вы описываете workflow (статусы RFQ, роли, Q&A, сравнение, экспорт), а дальше через чат итеративно собираете веб‑приложение без долгой рутины программирования.
Практично, что TakProsto.AI из коробки ориентирован на российский рынок: развёртывание и хостинг на серверах в России, работа с локализованными и open‑source LLM‑моделями, а также экспорт исходников. Для типового RFQ‑MVP стек понятный: фронтенд на React, бэкенд на Go, база PostgreSQL. Полезны и «операционные» функции для пилота: planning mode (чтобы заранее согласовать сценарии и модель данных), snapshots и rollback (чтобы безопасно откатывать изменения), подключение кастомного домена.
По тарифам можно стартовать с Free/Pro, а при росте перейти на Business или Enterprise — когда появятся требования к расширенным доступам, SLA и процессам.
Запуск RFQ‑системы — это не «выкатить форму», а обеспечить повторяемый процесс: запрос → сбор предложений → сравнение → выбор. На старте лучше вложиться в проверку критичных сценариев и подготовку данных, чем пытаться охватить все функции сразу.
Соберите пирамиду тестов под ключевой путь RFQ → получение котировок → выбор поставщика:
Отдельно проверьте права доступа (кто видит цены, файлы, комментарии) и сценарии дедлайнов: закрытие приёма, продление, опоздавшие котировки, смена часового пояса.
Для запуска почти всегда нужны миграции и импорт: справочник номенклатуры, единицы измерения, список поставщиков, условия поставки.
Сделайте шаблоны импорта (CSV/XLSX) и «песочницу» проверки: система должна подсвечивать ошибки строк и давать понятный отчёт, иначе запуск затянется.
Начните с пилота: одна категория закупок и ограниченный пул поставщиков (например, 5–15), фиксированные правила сравнения и короткий цикл обратной связи.
После пилота развивайте систему по ценности:
Так вы получите продукт, который стабильно работает «в поле» и постепенно обрастает функциями, а не усложняет процесс.
RFQ (Request for Quotation) — это запрос цены и условий поставки по заранее заданным параметрам (количество, сроки, доставка/Incoterms, валюта, налоги, гарантия и т. д.).
Цель — получить сопоставимые предложения и выбрать поставщика по прозрачным критериям, а не собирать разрозненные КП в письмах и Excel.
Типовые боли:
Приложение закрывает это единым форматом ответов, контролем полноты и фиксируемым протоколом выбора.
Минимальный набор ролей:
Базовый workflow:
MVP должен закрывать путь «опубликовали → получили → сравнили»:
Интеграции с ERP/EDI, сложные согласования и тонкие матрицы доступов лучше отложить до пилота.
Чтобы предложения сравнивались «яблоки с яблоками», зафиксируйте минимум:
Справочники для старта: валюты, единицы измерения (и опционально ставки/типы налогов).
Практичная модель данных:
Рекомендуемый набор мер:
Так проще объяснять итоговые суммы и избегать споров.
Минимум по сравнениям:
Финалом сделайте отчёт/экспорт с таблицей, TCO и протоколом решения.
Ключевые практики безопасности:
Это защищает коммерческие условия и упрощает внутренние проверки.
На старте закрепите для каждой роли 1–2 ключевых действия и уровень доступа.
Важно разделять «оригинальные значения» и «нормализованные для сравнения» (например, после конвертации валют).
