Закупщик разослал запрос пяти поставщикам по почте, получил три ответа в разных форматах — один PDF, один в теле письма, один в Excel с другой структурой колонок — и теперь сравнивает их вручную, копируя цифры в свою таблицу. Через месяц финансовый директор спрашивает, почему выбрали именно этого поставщика, и закупщик судорожно ищет в почте письмо трёхнедельной давности. Знакомая ситуация для компаний, у которых закупки выросли за рамки того объёма, который можно вести без системы.
Ниже разбираем, как устроен портал закупок с электронными тендерами (RFQ — Request for Quote, запрос предложения) на 1С-Битрикс: приём заявок от поставщиков в единой структуре, сравнение предложений, аудиторский след решений и автоматизация закупочного цикла от заявки до заказа. Материал обобщает практику по разработке систем закупок и электронных тендеров на 1С-Битрикс.
Коротко
- RFQ — это структурированный запрос предложения нескольким поставщикам одновременно с сохранением всех ответов в единой системе.
- Портал закупок работает поверх трёх ролей: закупщик создаёт тендер, поставщик отвечает предложением, согласующий утверждает решение.
- Аудиторский след — сохранённая история предложений и обоснование выбора — критичен для внутреннего контроля даже вне регулируемых закупок по 44-ФЗ/223-ФЗ.
- Автоматический скоринг предложений по весу критериев — вспомогательный инструмент, а не замена решения ответственного сотрудника.
- Начинать стоит с базового цикла «заявка → предложения → выбор», интеграцию с 1С и многоуровневое согласование добавлять по мере роста объёма закупок.
Зачем закупкам отдельный портал вместо почты и звонков
Пока закупок немного, почта и телефон работают достаточно хорошо. Проблема начинается с масштабом: чем больше одновременных тендеров, тем выше цена ручного сведения предложений в единую таблицу и тем легче потерять контекст — кто что предложил, на каких условиях, и почему в итоге выбрали именно этого поставщика. Портал закупок решает три конкретные задачи, которые неудобно закрывать почтой.
Во-первых, структура данных. Когда предложение приходит в форме, а не в свободном письме, все поставщики отвечают по одним и тем же полям — цена за единицу, общая сумма, срок поставки, условия оплаты, — и их можно сравнивать построчно, а не вычитывать из разных по формату документов. Во-вторых, параллельность. Один тендер уходит сразу нескольким поставщикам, и закупщику не нужно вручную дублировать одно и то же письмо пяти адресатам и следить, кто ответил, а кто ещё нет. В-третьих, история. Каждое решение — кого выбрали и почему — остаётся зафиксированным в системе, а не в переписке, которую сложно поднять через полгода.
Отдельный практический эффект — скорость закупочного цикла. Когда поставщики видят статус своей заявки и срок, до которого нужно ответить, а закупщик видит все предложения в одном табличном виде сразу после поступления последнего ответа, цикл от запроса до решения сокращается — не потому что процесс стал сложнее, а потому что из него исчезли ожидание и ручная сверка.
Что такое RFQ и чем он отличается от тендера и аукциона
Термины «запрос предложения», «тендер» и «аукцион» в разговорной речи часто смешивают, хотя это разные форматы закупочных процедур с разной логикой выбора победителя.
| Формат | Как выбирается победитель | Когда уместен |
|---|---|---|
| RFQ (запрос предложения) | Закупщик сравнивает предложения по нескольким критериям и выбирает вручную или по скорингу | Стандартный закупочный цикл для большинства товаров и услуг |
| Тендер / конкурс | Формализованная многоэтапная процедура с критериями, объявленными заранее, иногда с переторжкой | Крупные суммы, сложные технические требования, регулируемые закупки |
| Электронный аукцион | Побеждает поставщик с наименьшей ценой после серии открытых ставок на понижение | Стандартизированный товар, где цена — единственный значимый критерий |
Для большинства коммерческих компаний, которые не относятся к регулируемым закупщикам, RFQ — самый практичный формат: он достаточно структурирован, чтобы дать сравнимые предложения, но не требует формальной строгости тендера с фиксированными этапами и жёсткими сроками, характерными для госзакупок. Портал закупок на 1С-Битрикс в этой статье описывается именно в логике RFQ, хотя тот же движок при необходимости можно донастроить под более формализованный многоэтапный тендер.
Роли портала: закупщик, согласующий, поставщик
Портал закупок строится вокруг трёх ролей с разными правами и разными экранами интерфейса — так же, как личный кабинет B2B-портала строится вокруг ролей клиентов, только здесь роли зеркальные: компания выступает не продавцом, а покупателем.
- Закупщик (сотрудник отдела закупок). Создаёт тендер, формулирует требования и список позиций, приглашает поставщиков, видит все поступившие предложения в сравнительной таблице и фиксирует решение.
- Согласующий (руководитель, финансовый директор). Утверждает решение закупщика по тендерам выше определённой суммы или определённой категории — отдельная роль, если в компании принято разделять инициатора закупки и того, кто её утверждает.
- Поставщик. Видит только тендеры, к участию в которых приглашён, подаёт предложение по структурированной форме, отслеживает статус своей заявки и результат тендера.
Важно спроектировать права так, чтобы поставщик не видел предложения конкурентов — иначе теряется смысл конкурентного запроса, а участники начинают подстраивать цену под уже известные условия других. Технически это разграничение реализуется теми же механизмами, что и разграничение видимости данных в личном кабинете дилерской сети — через привязку записи к конкретному пользователю или группе и проверку прав на каждый вывод данных, а не только скрытием элементов интерфейса.
Жизненный цикл тендера от заявки до решения
Тендер на портале закупок проходит через несколько статусов, и каждый переход между ними — это событие, которое стоит явно спроектировать: кто его инициирует, что происходит с данными и кому уходит уведомление.
- Черновик. Закупщик формирует тендер: список позиций, требования, срок подачи предложений, список приглашённых поставщиков.
- Опубликован. Тендер становится виден приглашённым поставщикам, каждый получает уведомление с сроком ответа.
- Приём предложений. Поставщики заполняют структурированную форму предложения; закупщик видит, кто уже ответил, а кто ещё нет.
- Сравнение. После истечения срока (или досрочно, если все ответили) закупщик получает сводную таблицу предложений по всем критериям.
- Решение. Закупщик выбирает победителя с обязательным полем обоснования; при необходимости решение уходит на согласование.
- Завершён. Все участники получают уведомление об итоге; выигравшее предложение может автоматически превратиться в заказ поставщику.
Отдельно стоит продумать, что происходит с непобедившими предложениями — они не удаляются, а остаются в истории со статусом «отклонено», потому что именно эта история и формирует аудиторский след, о котором ниже.
Регистрация и модерация поставщиков
Прежде чем поставщик сможет отвечать на тендеры, ему нужен доступ в закрытый раздел портала. Здесь применяется та же логика, что и в модерации регистрации дилеров в закрытом B2B-разделе: поставщик заполняет форму с реквизитами компании (ИНН, контактные данные, категория поставляемых товаров или услуг), заявка попадает в очередь на модерацию сотруднику закупок, и только после одобрения поставщик получает логин и видит раздел тендеров.
Важный нюанс — видимость. Одобренный поставщик не должен видеть все тендеры компании подряд, только те, к участию в которых его пригласили явно (или, в открытой модели закупок, все тендеры по категории, к которой относится поставщик). Смешение этих двух моделей — закрытых тендеров по приглашению и открытого пула для всех зарегистрированных поставщиков — стоит решить на этапе проектирования, а не оставлять как техническую случайность.
Структурированное сравнение предложений
Центральный экран портала закупок для закупщика — сравнительная таблица предложений по одному тендеру. Она собирается автоматически из структурированных ответов поставщиков и обычно строится так: строки — позиции закупки или поставщики целиком, столбцы — критерии сравнения.
| Поставщик | Цена, ₽ | Срок поставки | Условия оплаты | Статус |
|---|---|---|---|---|
| ООО «Стройснаб» | 1 240 000 | 14 дней | Постоплата 30 дней | Предложение получено |
| ООО «Металлторг» | 1 180 000 | 21 день | Предоплата 50% | Предложение получено |
| ИП Фёдоров | — | — | — | Не ответил |
Ключевое требование к такой таблице — сравнимость. Если один поставщик указал цену с НДС, а другой без, или один — за партию целиком, а другой — за единицу, таблица начинает врать при беглом просмотре. Форма подачи предложения должна жёстко фиксировать единицы измерения и состав цены (с НДС/без, включена ли доставка), чтобы поля были действительно сравнимы, а не только одинаково названы.
Скоринг и вес критериев выбора
Когда критериев несколько и они противоречат друг другу (самая низкая цена — не всегда самый короткий срок поставки), помогает скоринг — присвоение каждому критерию веса и расчёт итогового балла по каждому предложению. Например: цена — 50% веса, срок поставки — 30%, условия оплаты — 20%. Система нормализует значения по каждому критерию (лучшее значение получает максимум баллов) и считает взвешенную сумму.
Скоринг полезен как инструмент первичной сортировки и способ сделать критерии выбора прозрачными и зафиксированными заранее, а не подгоняемыми под уже выбранного поставщика постфактум. Но финальное решение почти всегда стоит оставлять за человеком: автоматический балл не видит репутацию поставщика, историю срывов сроков в прошлом или стратегическую ценность долгосрочных отношений — факторы, которые формулой не всегда удаётся корректно описать.
Аудиторский след: почему это не факультатив
Отдельная ценность портала закупок, которую легко недооценить на старте, — это неизменяемая история решений. Каждый тендер сохраняет: кто был приглашён, какие предложения поступили и когда, кто и когда принял решение, какое обоснование указано. Это не бюрократическая формальность, а защита самой компании: если через полгода возникает вопрос, почему выбрали именно этого поставщика при не самой низкой цене, ответ — в системе, а не в памяти сотрудника, который, возможно, уже не работает в компании.
Технически аудиторский след реализуется так, чтобы исторические записи не редактировались задним числом — статус и решение фиксируются один раз, а последующие изменения (если они вообще нужны) логируются отдельной записью с указанием, кто и когда внёс изменение, а не перезаписывают исходные данные. Это тот же принцип, что применяется к истории заказов в личном кабинете: данные о прошлом должны быть неизменны, чтобы им можно было доверять.
Как это выглядит в админке 1С-Битрикс
Тендеры настраиваются как отдельный раздел с привязкой поставщиков через группы пользователей и структурированными свойствами формы предложения. Схематично карточка тендера в админке выглядит так:
Связь с 1С: от решения тендера до заказа поставщику
Портал закупок приносит максимум пользы, когда результат тендера не заканчивается на экране «Победитель выбран», а автоматически превращается в документ в учётной системе. Минимальный уровень интеграции — выгрузка данных выигравшего предложения (поставщик, позиции, цены, условия) в 1С для формирования заказа поставщику вручную оператором на основе готовых данных, без повторного набора с нуля.
Более глубокий уровень — двусторонняя синхронизация: справочник поставщиков синхронизируется между порталом и 1С, чтобы не заводить контрагента дважды, а решение тендера автоматически создаёт документ заказа поставщику в учётной системе через API или файловый обмен. Также полезно синхронизировать историю закупок по каждому поставщику — сколько раз выигрывал тендеры, средние сроки поставки по факту, — чтобы эти данные были видны закупщику прямо на портале при принятии следующего решения, а не только в отчётах бухгалтерии.
Уровни автоматизации: с чего начать
| Уровень | Что входит | Кому подходит на старте |
|---|---|---|
| Базовый | Регистрация поставщиков, создание тендера, приём предложений, сравнительная таблица | Компаниям, которые сейчас ведут закупки по почте и Excel |
| Средний | + скоринг по весам критериев, многоуровневое согласование решения по сумме | Компаниям с регулярными закупками и несколькими согласующими |
| Продвинутый | + полная интеграция с 1С, автосоздание заказа поставщику, история закупок по поставщикам | Компаниям с высоким объёмом закупок, где ручной перенос данных — узкое место |
Как и с личным кабинетом B2B-портала, разумная стратегия — не проектировать сразу максимальный уровень, а запустить базовый цикл «заявка → предложения → решение», убедиться, что закупщики и поставщики им реально пользуются, и добавлять скоринг, согласование и глубокую интеграцию с 1С вторым и третьим этапом по мере роста объёма закупок.
Частые ошибки при внедрении
- Позволяют поставщикам видеть предложения конкурентов — конкурентный запрос перестаёт быть конкурентным.
- Не фиксируют единицы измерения и состав цены в форме предложения — сравнительная таблица формально заполнена, но реально несравнима.
- Удаляют отклонённые предложения вместо того, чтобы хранить их в истории со статусом «отклонено» — теряется аудиторский след.
- Подбирают веса критериев скоринга постфактум под уже выбранного поставщика вместо того, чтобы фиксировать их заранее.
- Не разделяют роли закупщика и согласующего там, где по сумме сделки требуется утверждение руководителя, — решения принимаются без контроля.
- Запускают сразу продвинутый уровень с полной интеграцией и многоэтапным согласованием, хотя реальный объём закупок компании этого не требует.
- Не продумывают, что происходит с тендером, если ни один поставщик не ответил до дедлайна, — процесс зависает без явного статуса.
- Результат тендера не связан с 1С — данные всё равно переносятся в заказ поставщику вручную, и часть экономии времени теряется.
Чек-лист перед стартом проекта
- Роли и права описаны. Кто создаёт тендер, кто согласует решение при какой сумме, как модерируется регистрация поставщика.
- Форма предложения структурирована. Определены обязательные поля, единицы измерения и состав цены, которые должны совпадать у всех поставщиков.
- Критерии выбора зафиксированы. Понятно, нужен ли скоринг и какие веса у критериев по умолчанию.
- Модель видимости тендеров выбрана. Закрытые тендеры по приглашению, открытый пул по категориям или комбинация.
- Связь с 1С определена. Ясно, какой уровень интеграции нужен на старте — ручная выгрузка данных или автоматическое создание заказа.
- Стартовый этап выбран. Понятно, какой уровень автоматизации запускается первым, что откладывается на следующие этапы.
Вывод
Портал закупок с электронными тендерами RFQ заменяет разрозненную переписку структурированным процессом: запрос предложения нескольким поставщикам одновременно, сравнимые ответы в едином виде, зафиксированное и обоснованное решение. Главная ценность такой системы — не скорость сама по себе, а аудиторский след и прозрачность критериев выбора, которые почта дать не может. Начинать стоит с базового цикла приёма и сравнения предложений, а скоринг, согласование и глубокую интеграцию с 1С добавлять по мере роста объёма закупок компании.
