Тендеры и запросы цен (RFQ) в B2B-портале

В крупных сделках цена редко берётся из прайс-листа. Партия на несколько миллионов, поставка под проект, товар со сроком изготовления — здесь покупатель сначала спрашивает «сколько будет стоить именно моя спецификация и в какие сроки», а поставщик отвечает индивидуальным расчётом. Этот переговорный этап и называется RFQ (Request for Quotation, запрос цены). В большинстве компаний он до сих пор живёт в почте и Excel: письма теряются, версии спецификаций расходятся, а сравнить три предложения — это отдельный вечер с калькулятором.

B2B-портал переводит эту рутину в управляемый процесс: покупатель собирает запрос в личном кабинете, поставщики вносят котировки в единую форму, система сравнивает их по цене и срокам, а согласованное предложение одним действием превращается в заказ. Ниже — как устроить полный цикл RFQ на 1С-Битрикс: процесс, роли, структура данных, реализация и метрики. Материал основан на наших проектах по разработке B2B-порталов — с реальными статусами, обменом с 1С и разграничением доступа.

Что такое RFQ и зачем тендеры в B2B

RFQ (запрос цены, запрос котировок) — это формализованное обращение покупателя к одному или нескольким поставщикам с просьбой рассчитать стоимость и условия поставки конкретного набора позиций. В отличие от заказа по прайсу, где цена известна заранее, в RFQ цена — предмет ответа. Покупатель фиксирует, что и сколько ему нужно, а поставщик отвечает, по какой цене, в какие сроки и на каких условиях он готов это поставить.

В B2B такой сценарий возникает постоянно. Оптовая цена зависит от объёма партии, а объём каждый раз разный. Товар производится под заказ, и себестоимость меняется вместе с курсом сырья. Проектная поставка включает нестандартную комплектацию, монтаж и логистику, которые невозможно заранее уложить в прайс. Наконец, закупщик крупной компании обязан по регламенту собрать несколько предложений и выбрать лучшее — это уже мини-тендер. Во всех этих случаях обычная корзина «добавить в заказ» не работает: нужен переговорный контур.

Разница между RFQ и тендером — в масштабе и формальности, а не в сути. Запрос цены одному постоянному поставщику — это лёгкий RFQ. Тот же запрос, разосланный трём поставщикам с дедлайном и правилами отбора, — уже тендер (конкурентная процедура). Технически на портале это один и тот же объект: заявка со спецификацией, к которой прикрепляются одна или несколько котировок. Поэтому имеет смысл проектировать единый модуль, который одинаково обслуживает и простой запрос цены, и полноценную закупочную процедуру.

Зачем это переносить на портал, если можно продолжать в почте? Затем же, зачем компании вообще заводят B2B-кабинет: чтобы убрать ручной труд, ошибки и потери. У RFQ на портале есть измеримые выгоды. Единая спецификация исключает расхождение версий — все работают с одной таблицей позиций. История переписки и файлов привязана к запросу, а не разбросана по ящикам сотрудников. Сравнение предложений автоматизировано и прозрачно, что важно и для скорости, и для антикоррупционного контроля. А главное — путь от запроса до заказа сокращается с недель до дней, потому что исчезают паузы «жду, пока пришлют актуальный расчёт».

Жизненный цикл запроса цены: от заявки до заказа

Чтобы модуль был предсказуемым, у запроса должен быть чёткий жизненный цикл — набор статусов, между которыми возможны только разрешённые переходы. Это ядро всей системы: статус определяет, кто что видит, какие кнопки доступны и какие уведомления уходят. Классический цикл RFQ выглядит так.

1. Черновик. Покупатель собирает спецификацию: добавляет позиции, указывает количества, требования, сроки. Запрос виден только внутри его компании, поставщики его ещё не получают.
2. На согласовании (опционально). Если сумма или регламент требуют, черновик уходит на внутреннее согласование бюджета. Пока он не согласован, отправить его наружу нельзя.
3. Отправлен. Запрос разослан выбранным поставщикам. Стартует таймер приёма котировок (дедлайн). Спецификацию менять уже нельзя — иначе поставщики считают по разным условиям.
4. Сбор котировок. Поставщики вносят цены, сроки и комментарии. Покупатель видит, кто ответил, а кто ещё нет. В закрытой процедуре цены до дедлайна скрыты.
5. Сравнение. После дедлайна (или досрочно) покупатель сравнивает предложения в единой таблице и выбирает победителя по цене, срокам и условиям.
6. Согласование итога. Выбор победителя, если нужно, проходит финальное утверждение уполномоченным лицом с правом подписи.
7. Принят → заказ. Победившая котировка превращается в заказ: состав и цены фиксируются, создаётся заказ Битрикса, запрос закрывается со ссылкой на номер заказа.
8. Отклонён / отменён. Терминальные статусы для запросов, которые не переросли в сделку. Хранятся для аналитики и истории отношений с контрагентом.

Ключевая идея — необратимость части переходов. После статуса «Отправлен» спецификацию нельзя редактировать: это гарантия, что все поставщики отвечают на идентичный запрос. Если требования изменились, корректный путь — отменить текущий RFQ и создать новую версию, а не править отправленный. Такую дисциплину проще заложить в статусную модель, чем контролировать вручную.

Роли и участники процесса

RFQ — командный процесс, и его правильная работа держится на разграничении ролей. В нём участвуют две стороны: закупающая (клиент портала) и поставляющая (внутренние отделы или внешние поставщики). Внутри каждой стороны роли тоже разные.

• Инициатор / закупщик. Сотрудник компании-клиента, который собирает спецификацию и запускает запрос. Он видит все свои RFQ и полученные котировки, но не всегда имеет право принять итоговое предложение самостоятельно.
• Согласующий / руководитель. Утверждает бюджет запроса и/или выбор победителя. Его подпись — контрольная точка перед превращением RFQ в заказ. У него право вето, но обычно нет права редактировать спецификацию.
• Наблюдатель. Бухгалтерия, финансовый контроль или смежный отдел — видит запросы и результаты, но не влияет на процесс. Полезен для прозрачности и аудита.
• Поставщик / отдел продаж. Сторона, которая отвечает котировкой. Видит только адресованные ему запросы и только свои предложения — чужие цены ему недоступны.
• Администратор процедуры. Со стороны портала следит за регламентом: дедлайнами, корректностью данных, разрешает спорные ситуации. Часто это менеджер площадки.

Разделение «кто создаёт», «кто согласует» и «кто принимает» — не бюрократия ради бюрократии, а защита от ошибок и злоупотреблений. Когда одно лицо и формирует запрос, и выбирает победителя, и принимает предложение, теряется контроль над крупными тратами. Поэтому роли стоит разносить хотя бы для запросов выше определённого порога суммы. Логику разграничения доступа мы детально разбираем в отдельном материале про роли и права на B2B-портале — она напрямую применима к RFQ.

Типы процедур: RFI, RFQ, RFP и аукцион

«Запрос поставщику» — это семейство процедур, и полезно различать их, потому что данные и интерфейс у них отличаются. На практике B2B-портал чаще всего обслуживает четыре формата.

Для минимально жизнеспособного модуля достаточно RFQ — он покрывает большинство сделок. RFI обычно решается формой предквалификации и картотекой поставщиков. RFP отличается от RFQ тем, что в ответе поставщик прикладывает не только цифры, но и описание решения, поэтому в котировке появляются текстовые поля и вложения, а сравнение становится частично экспертным, а не чисто числовым. Аукцион — самый сложный формат: он требует живого обновления ставок и таймера, поэтому его внедряют отдельно и только когда закупки действительно однородны. Начинайте с RFQ, а остальные форматы добавляйте по мере зрелости процесса.

Архитектура RFQ-модуля на 1С-Битрикс

Прежде чем говорить об интерфейсе, определимся со структурой данных. От неё зависит, насколько гибко модуль переживёт рост требований. Удачная модель RFQ на 1С-Битрикс строится на нескольких сущностях, связанных между собой.

• Запрос (RFQ). Головной объект: номер, автор, компания-заказчик, статус, дедлайн, комментарий, привязка к договору. Хранится как элемент инфоблока «Запросы цен» или как запись highload-блока с полями процедуры.
• Позиции запроса (спецификация). Строки: товар (привязка к каталогу или свободная позиция), количество, единица измерения, требования. Это дочерние записи, связанные с запросом по его идентификатору.
• Котировка (предложение). Ответ одного поставщика: цены по позициям, срок поставки, условия оплаты и доставки, валюта, срок действия предложения, файлы. К одному запросу может относиться несколько котировок.
• Строки котировки. Цена и параметры по каждой позиции спецификации — чтобы сравнение шло построчно, а не только по итоговой сумме.
• Итоговый заказ. Стандартный заказ модуля «Интернет-магазин», созданный из принятой котировки и связанный с исходным RFQ обратной ссылкой.

Почему именно так, а не «всё в одном заказе с кастомными полями»? Потому что у RFQ принципиально иная кардинальность: одна заявка — много предложений, и построчное сравнение требует отдельного хранения строк котировок. Пытаться уложить это в структуру заказа Битрикса неудобно — заказ рассчитан на один согласованный состав, а не на набор конкурирующих. Поэтому RFQ живёт в своих сущностях (инфоблоки/highload), и лишь на финальном шаге материализуется в заказ. Такой подход хорошо согласуется с логикой оптовых заявок и коммерческих предложений, где заявка тоже предшествует заказу.

Выбор между инфоблоками и highload-блоками зависит от объёмов и требований. Инфоблоки удобны интерфейсом, свойствами и правами «из коробки», их проще показывать в админке и раздавать доступ. Highload-блоки выигрывают на больших объёмах строк (тысячи позиций и котировок) и там, где нужна производительность выборок. Практичный компромисс: сам запрос и котировки — в инфоблоках (их немного, важен UX и права), а построчные данные спецификации и предложений — в highload-блоках, если каталоги позиций большие.

Как покупатель создаёт запрос цены

Точка входа в RFQ — форма создания запроса в личном кабинете. Хороший сценарий делает её максимально близкой к привычной корзине, чтобы покупатель не переучивался. Есть несколько способов наполнить спецификацию.

1. Из каталога. Рядом с кнопкой «В корзину» у товара есть «Запросить цену». Так позиции с индивидуальными условиями сразу попадают в черновик RFQ, а не в обычный заказ.
2. Из корзины. Собранную корзину целиком можно перевести в запрос цены — удобно, когда клиент хочет получить спеццену на весь набор, а не по прайсу.
3. Загрузкой файла. Спецификацию из Excel или CSV покупатель загружает по артикулам и количествам — портал сопоставляет строки с каталогом. Этот сценарий пересекается с быстрым заказом по артикулу и Excel.
4. Свободными позициями. Для товаров вне каталога закупщик добавляет строку вручную: наименование, характеристики, количество. Это важно для проектных поставок, где номенклатуры ещё нет в базе.

Помимо позиций, в запросе указываются общие условия: желаемый срок поставки, адрес, требования к качеству и сертификатам, комментарий поставщику, дедлайн приёма котировок и список адресатов. На этом же шаге прикладываются файлы — чертежи, ТЗ, образцы. Всё это критично: чем полнее исходные данные, тем точнее и сопоставимее будут котировки, и тем меньше уточняющих итераций.

Отдельного внимания заслуживает выбор адресатов. Для простого запроса цены это один постоянный поставщик. Для тендера — список из нескольких. На портале, где поставщики внешние, адресатов выбирают из справочника; на портале дистрибьютора, где «поставщик» — это внутренние отделы или филиалы, запрос маршрутизируется между ними. В обоих случаях список адресатов фиксируется в момент отправки и определяет, кто увидит запрос и сможет ответить.

Ответ поставщика: котировка и условия

Получив запрос, поставщик видит спецификацию и заполняет котировку. Ключевая задача интерфейса здесь — сделать ответ быстрым и структурированным, чтобы предложения были сопоставимы. Поставщик заполняет цену построчно, по каждой позиции спецификации, а не одной суммой: это позволяет покупателю сравнивать не только итог, но и цены по отдельным товарам.

Помимо цен, котировка несёт условия, которые часто важнее самой цены:

• Срок поставки. По позиции или на весь заказ — «со склада завтра» против «под заказ через три недели» может перевесить разницу в цене.
• Условия оплаты. Предоплата, отсрочка, разбивка платежей. Отсрочка напрямую связана с кредитными лимитами и отсрочкой контрагента.
• Условия доставки. Самовывоз, доставка до склада, включена ли она в цену, регион.
• Срок действия предложения. До какой даты цена действительна — защита поставщика от скачков себестоимости.
• Минимальная партия и кратность. Иногда поставщик готов дать цену только на кратный объём — этот нюанс мы разбираем в статье про кратность и спецификации в каталоге.
• Валюта и НДС. Важно для международных и смешанных закупок, чтобы сравнение приводилось к единой базе.

Чтобы облегчить поставщику расчёт, портал может подставлять подсказки: последнюю цену этой позиции, актуальный остаток и себестоимость из 1С, историю прошлых котировок. Это ускоряет ответ и снижает риск ошибки. При этом важно, чтобы черновик котировки был приватным — поставщик спокойно считает, сохраняет и лишь затем отправляет финал. После отправки (и особенно после дедлайна) котировка фиксируется, иначе теряется честность процедуры.

Сравнение предложений и скоринг

Сердце тендера — экран сравнения. Здесь покупатель видит все полученные котировки бок о бок и принимает решение. Хорошая таблица сравнения устроена так: строки — позиции спецификации (плюс итоговая строка), столбцы — поставщики, а в ячейках — цены и условия. Лучшее значение по каждому критерию подсвечивается, чтобы взгляд сразу находил выгодные предложения.

Как видно из примера, «самое дешёвое» и «самое выгодное» — не одно и то же. Поставщик B даёт минимальную сумму, но требует предоплату, долгий срок и доставку отдельно. Поставщик C быстрее всех, но дороже. Поэтому в серьёзных процедурах чистое сравнение цен дополняют скорингом — взвешенной оценкой по нескольким критериям.

Скоринг работает так: каждому критерию (цена, срок, условия оплаты, надёжность поставщика) присваивается вес, значения нормализуются и складываются во взвешенный балл. Итоговый рейтинг подсказывает победителя объективно, а не «по ощущению». Веса задаёт закупщик под конкретную процедуру: где-то решает цена, где-то — скорость. На 1С-Битрикс скоринг реализуется расчётом на стороне сервера при выводе таблицы сравнения, а формула хранится в настройках процедуры. Это снимает субъективность и особенно ценно для регламентированных закупок, где выбор нужно обосновать.

Помимо чисел, на этом же экране полезны служебные признаки: кто из адресатов ещё не ответил, чьи предложения просрочены по сроку действия, какие цены выше прошлой закупки. Такие маркеры экономят закупщику время и не дают принять невыгодное или устаревшее предложение.

Согласование условий и бюджета

Выбор победителя редко бывает единоличным решением закупщика. В компаниях со зрелым закупом сделка выше порога проходит согласование — иногда двойное: сначала утверждается бюджет запроса, затем — конкретный победитель. Портал должен уметь встроить этот контур, не превращая его в тормоз.

Механика согласования на RFQ повторяет логику согласования заказов, которую мы подробно разбираем в материале про согласование заказов на B2B-портале. Отличие в том, что согласуется не готовый заказ, а выбор из нескольких предложений. Согласующий видит таблицу сравнения, обоснование выбора закупщика (почему не самый дешёвый, если это так) и либо утверждает, либо отправляет на пересмотр с комментарием.

Чтобы согласование не растягивалось, полезны несколько практик. Уведомления с прямой ссылкой на экран сравнения — согласующий не ищет запрос, а сразу видит суть. Дедлайн согласования с эскалацией — если руководитель не ответил за срок, запрос уходит выше или напоминание повторяется. Мобильный доступ — утвердить с телефона важнее, чем кажется, потому что именно ожидание подписи чаще всего тормозит закупку. И полная история решений: кто, когда и с каким комментарием согласовал — это и аудит, и защита от споров.

Многоступенчатое согласование удобно моделировать бизнес-процессом Битрикса (модуль «Бизнес-процессы») либо собственным движком статусов с матрицей «сумма → кто согласует». Для типовых сценариев штатных бизнес-процессов достаточно; для сложной матрицы согласований с разными ветками под категории закупок обычно пишут кастомную логику, потому что она прозрачнее и быстрее визуального конструктора на больших объёмах.

Превращение RFQ в заказ

Финальный и самый ценный шаг — материализация согласованного RFQ в заказ. Именно здесь переговорный процесс становится реальной сделкой в учёте. Когда уполномоченное лицо принимает победившую котировку, портал выполняет цепочку действий.

1. Фиксирует условия. Состав, цены, сроки и условия победившей котировки замораживаются — дальше они не редактируются, чтобы заказ соответствовал тому, что согласовали.
2. Создаёт заказ. Через API \Bitrix\Sale\Order формируется новый заказ: по каждой позиции спецификации создаётся элемент корзины с ценой из котировки, проставляется покупатель, контрагент и договор.
3. Переносит контекст. В заказ копируются согласованные условия оплаты и доставки, комментарии, файлы и ссылка на исходный RFQ — чтобы менеджер видел всю предысторию.
4. Закрывает запрос. RFQ переводится в статус «Реализован», проигравшие котировки помечаются, всем адресатам уходят уведомления об итоге процедуры.
5. Выгружает в 1С. Готовый заказ уходит в учётную систему обменом, как обычный заказ, и дальше живёт по стандартному циклу отгрузки и оплаты.

Технически ключевой момент — сделать создание заказа атомарным и идемпотентным. Атомарным, чтобы при сбое не осталось «половины заказа»: либо заказ создан целиком, либо не создан вовсе (транзакция и проверка результата операций Sale API). Идемпотентным, чтобы повторное нажатие «Принять» или двойной клик не породили два заказа — для этого перед созданием проверяется, не связан ли RFQ уже с заказом. Эти детали кажутся мелочью, но именно на них чаще всего спотыкаются самописные реализации.

Отдельно продумайте частичное принятие. Иногда по одному запросу выгоднее взять часть позиций у поставщика A, а часть — у B (сплит-заказ). Если бизнес этого требует, модель должна позволять формировать заказ из строк разных котировок. Это усложняет логику, поэтому включайте её только при реальной потребности, а не «на всякий случай».

Реализация в 1С-Битрикс

Соберём архитектуру в конкретные инструменты платформы. RFQ-модуль не требует экзотики — он собирается из штатных механизмов 1С-Битрикс, что важно для поддерживаемости.

• Инфоблоки для запросов и котировок: свойства под статус, дедлайн, адресатов, суммы. Права доступа инфоблоков дают базовое разграничение «кто что видит».
• Highload-блоки для построчных данных спецификации и котировок при больших объёмах — они держат нагрузку лучше свойств инфоблока.
• Модуль «Интернет-магазин» и Sale API (\Bitrix\Sale\Order, Basket) — для создания итогового заказа из принятой котировки.
• Группы пользователей и права — для ролей инициатора, согласующего, поставщика и наблюдателя. Видимость действий проверяется в компонентах.
• События и обработчики — на смену статуса RFQ вешаются обработчики: уведомления, создание заказа, закрытие процедуры.
• Агенты и cron — для дедлайнов: закрытие приёма котировок по времени, открытие цен в закрытой процедуре, напоминания об истечении срока согласования.
• Модуль «Почтовые события» и push — для оповещений участникам на каждом переходе статуса.
• Бизнес-процессы (опционально) — для визуального согласования, если матрица утверждений простая.
• REST/CommerceML-обмен — для подтягивания остатков и себестоимости из 1С в котировки и выгрузки готового заказа обратно.

Интерфейсную часть в личном кабинете собирают на кастомных компонентах: список запросов с фильтром по статусу, карточка запроса со спецификацией, форма котировки для поставщика, экран сравнения. Компоненты работают через API D7, кэшируются управляемым кэшем и учитывают роль текущего пользователя. Верстка — адаптивная, потому что согласующие часто заходят с телефона, а закупщики работают с большими таблицами на десктопе.

Важное архитектурное решение — где считать бизнес-логику. Всё, что касается денег и статусов (скоринг, создание заказа, проверка прав на переход), должно жить на сервере в отдельном сервисном слое, а не в шаблонах компонентов и тем более не на фронтенде. Это делает логику тестируемой, переиспользуемой между компонентами и REST-методами и защищённой от подмены на клиенте. Шаблоны компонентов только отображают то, что подготовил сервис.

Как это выглядит в интерфейсе

Чтобы закупщику было удобно вести множество процедур одновременно, список запросов оформляют как доску или таблицу со статусами. Схематично панель управления запросами выглядит так: колонки по статусам, карточки запросов с ключевыми данными и счётчиком полученных котировок.

С карточки запроса закупщик проваливается в детали: спецификацию, список котировок, экран сравнения и историю. Поставщик в своём кабинете видит только адресованные ему запросы и форму ответа. Согласующий получает отдельную очередь «Ждут моего решения». Такое разведение интерфейсов по ролям — не украшательство, а способ не показывать человеку лишнее и не давать ему действий, на которые у него нет прав.

Интеграция с 1С и CRM

RFQ-модуль становится по-настоящему полезным, когда связан с учётной системой и CRM. Автономный портал заставляет менеджеров дублировать данные вручную; интегрированный — избавляет от этого и повышает точность.

Обмен с 1С работает в обе стороны. Из 1С в портал подтягиваются номенклатура, единицы измерения, актуальные остатки и себестоимость — последнее особенно ценно для расчёта котировок внутренними отделами. Из портала в 1С уходит готовый заказ, созданный из принятого RFQ, как стандартный документ обмена (CommerceML) или через REST. Так закупка, начавшаяся как переговоры на портале, бесшовно попадает в учёт без ручного ввода. Тонкости связки портала с учётной системой и ERP мы разбираем в материале про интеграцию B2B-портала с ERP.

Связь с CRM (в том числе Битрикс24) полезна для стороны продаж. Входящий RFQ может автоматически создавать сделку или лид, чтобы менеджер видел закупочный запрос клиента в своей воронке и вёл его до заказа. История котировок обогащает карточку клиента, а конверсия «запрос → сделка» становится измеримой метрикой продаж. Это превращает RFQ из чисто закупочного инструмента в источник данных для коммерции.

Практический совет по интеграции: не пытайтесь синхронизировать вживую каждое поле в момент действия пользователя — это делает портал зависимым от доступности 1С. Надёжнее очередь обмена: RFQ и заказы копятся и выгружаются пакетно по расписанию или по событию, а при недоступности учётной системы портал продолжает работать и досылает данные позже. Тему интеграций в целом закрывает наша услуга по интеграциям.

Доступы и конфиденциальность цен

Закупочная процедура чувствительна к утечкам: если поставщик заранее узнает цены конкурентов, конкуренция исчезает, а если чужой сотрудник увидит запрос — нарушается коммерческая тайна. Поэтому доступ в RFQ-модуле проектируется строго.

• Изоляция по компаниям. Сотрудник видит только запросы своей организации. Это базовое требование мультитенантного B2B-кабинета.
• Приватность котировок. Поставщик видит свой запрос и свою котировку, но не котировки конкурентов. Сводную таблицу сравнения видит только покупатель.
• Закрытый конверт. В строгих процедурах цены становятся видимыми покупателю только после дедлайна — до него даже он не подсматривает предложения, что исключает «подгонку». Открытие по расписанию делает агент.
• Права на действия. Создать, отправить, согласовать, принять — разные права у разных ролей. Кнопка недоступна, если у пользователя нет права, а не просто спрятана в интерфейсе.
• Журнал действий. Кто, когда и что сделал — фиксируется. Для регламентированных закупок это обязательное условие аудита.

Технически всё это опирается на систему прав 1С-Битрикс: права доступа к элементам инфоблоков, проверки в сервисном слое перед каждым чувствительным действием и агенты для отложенного открытия данных. Важно, чтобы проверка прав была на сервере, а не только в шаблоне: спрятать кнопку недостаточно, нужно запретить само действие на уровне обработчика. Иначе прямой запрос в обход интерфейса обойдёт защиту.

Метрики закупочного процесса

Внедрив RFQ, важно измерять эффект — иначе непонятно, стало ли лучше. Процесс запросов цен даёт богатую аналитику, которой в почте и Excel просто не существует.

Эти показатели удобно вывести на дашборд закупок, чтобы руководитель видел картину целиком, а не отдельные запросы. Подходы к построению таких панелей мы разбираем в статье про аналитику и дашборды B2B-портала. Ключевой смысл метрик — управляемость: когда виден средний срок цикла и доля просроченных согласований, понятно, что именно чинить, чтобы закупки шли быстрее и дешевле.

Частые ошибки

• Разрешают редактировать спецификацию после отправки — поставщики отвечают на разные условия, и сравнение теряет смысл.
• Показывают поставщикам чужие котировки — конкуренция исчезает, цены выравниваются вверх.
• Сравнивают предложения только по итоговой сумме, игнорируя срок, доставку и НДС — «дешёвое» оказывается дороже в реальности.
• Не приводят котировки к единой базе (валюта, включённая доставка, ставка НДС) — таблица сравнения вводит в заблуждение.
• Совмещают в одном лице создание, согласование и принятие крупного запроса — теряется контроль над тратами.
• Делают создание заказа неидемпотентным — двойной клик по «Принять» порождает два заказа в 1С.
• Не связывают заказ с исходным RFQ — пропадает сквозная история и аналитика конверсии.
• Проверяют права только в шаблоне, пряча кнопки, — прямой запрос в обход интерфейса обходит защиту.
• Забывают про дедлайны и напоминания — запросы «висят», согласования тормозят, поставщики не отвечают вовремя.

Чек-лист внедрения

Сведём готовность RFQ-модуля в практический список, по которому удобно принимать процесс перед запуском.

1. Статусная модель описана. Определены все статусы запроса и разрешённые переходы; спецификация фиксируется после отправки.
2. Роли разграничены. Инициатор, согласующий, наблюдатель и поставщик имеют разные права; порог обязательного согласования настраивается.
3. Спецификацию удобно собирать. Доступны все способы наполнения: из каталога, корзины, файла и свободными позициями.
4. Котировка сопоставима. Форма ответа поставщика собирает цену построчно, срок, условия оплаты и доставки, валюту и НДС.
5. Сравнение работает. Экран сравнения подсвечивает лучшие значения, при необходимости считает взвешенный скоринг.
6. Согласование встроено. Крупные запросы уходят на утверждение с уведомлением, дедлайном и историей решений.
7. Заказ создаётся корректно. Принятие котировки формирует заказ атомарно и идемпотентно, с двусторонней связью RFQ ↔ заказ.
8. Конфиденциальность обеспечена. Изоляция по компаниям, приватность котировок, при необходимости закрытый конверт; права проверяются на сервере.
9. Интеграция настроена. Остатки и себестоимость приходят из 1С, готовый заказ выгружается обратно очередью обмена.
10. Метрики собираются. Зафиксированы время цикла, конверсия в заказ, отклик поставщиков и экономия от конкуренции.

Вывод

Тендеры и запросы цен — это про сделки, где цена не берётся из прайса, а рождается в переговорах. B2B-портал на 1С-Битрикс переводит эти переговоры из почты и Excel в управляемый процесс: единая спецификация, сопоставимые котировки, прозрачное сравнение, согласование по ролям и превращение согласованного предложения в заказ одним действием. Соберите модуль на штатных механизмах платформы, разграничьте доступ, свяжите с 1С — и путь от запроса до заказа сократится с недель до дней, а каждая закупка станет измеримой и защищённой от ошибок.