Розробка функціоналу запиту ціни (RFQ) на 1С-Бітрікс

На B2B-сайтах ціни часто не публікуються відкрито: вони залежать від обсягу, регіону, умов договору. Замість кнопки «Купити» потрібна кнопка «Запросити ціну» — RFQ (Request for Quotation). Стандартний модуль sale не підтримує цю логіку: він вимагає публічну ціну та миттєву оплату. Ми на практиці розробили кастомний RFQ-модуль, який вже обробляє до 200 заявок на день у нашого клієнта — дистриб'ютора промислового обладнання. У цьому кейсі час відповіді скоротився з 3 днів до 4 годин (внутрішня статистика проекту), а втрата заявок — з 25% до 0%. RFQ-модуль швидше ручної обробки в 12 разів. Наша команда має 7+ років досвіду розробки на 1С-Бітрікс та виконала більше 50 проектів. Отримайте консультацію інженера: як впровадити RFQ на вашому проекті. Орієнтовна вартість розробки — від $2,500 до $5,000 залежно від складності.

Яку біль вирішує RFQ-модуль?

Без RFQ менеджери втрачають запити в пошті, час відповіді затягується до 2–3 днів, а клієнти йдуть до конкурентів. У нашого клієнта — дистриб'ютора промислового обладнання — ми побачили це наочно: 4000 SKU без публічних цін, ручний обмін email призводив до втрати 25% запитів. RFQ-модуль автоматизує весь процес: заявка → обробка → КП → замовлення.

Архітектура RFQ: таблиці та статусна машина

RFQ-запит проходить кілька статусів: new → processing → quoted → accepted → rejected → ordered. Після accepted клієнт може оформити замовлення за узгодженою ціною через стандартний модуль sale. Ми використовуємо скінченний автомат (finite state machine) з формальними правилами переходів та транзакційністю оновлень статусів.

Таблиця заявок bl_rfq:

CREATE TABLE bl_rfq ( id SERIAL PRIMARY KEY, user_id INT REFERENCES b_user(ID), status VARCHAR(30) DEFAULT 'new', manager_id INT, comment TEXT, manager_note TEXT, created_at TIMESTAMP DEFAULT NOW(), updated_at TIMESTAMP DEFAULT NOW(), expires_at TIMESTAMP, order_id INT ); 

Позиції заявки bl_rfq_items:

CREATE TABLE bl_rfq_items ( id SERIAL PRIMARY KEY, rfq_id INT REFERENCES bl_rfq(id) ON DELETE CASCADE, product_id INT NOT NULL, sku_id INT, quantity NUMERIC(10,3), unit VARCHAR(20), price_requested NUMERIC(12,2), price_quoted NUMERIC(12,2), comment TEXT ); 

Статусна машина реалізована через кінцевий автомат: кожен статус має правила переходу та права доступу. Наприклад, перехід з new в processing доступний тільки менеджеру, а в quoted — тільки після заповнення всіх price_quoted. Для статусів accepted та rejected надсилаються сповіщення клієнту.

Як працює RFQ-процес?

1. Клієнт додає товари в RFQ-кошик і відправляє заявку.
2. Менеджер отримує сповіщення і обробляє заявку в адмін-панелі.
3. Менеджер виставляє ціни на кожну позицію і переводить заявку в статус quoted.
4. Клієнт отримує сповіщення, заходить в особистий кабінет і приймає або відхиляє пропозицію.
5. При прийнятті створюється замовлення за узгодженими цінами.

Кнопка «Запросити ціну» замінює «В кошик» на картках товарів — або співіснує, якщо частина товарів має публічну ціну. Логіка визначається в result_modifier.php компонента catalog.element:

$showRFQ = ($arResult['ITEM_PRICES'][0]['PRICE'] ?? 0) === 0 || $arResult['ITEM']['PROPERTIES']['PRICE_ON_REQUEST']['VALUE'] === 'Y'; $arResult['SHOW_RFQ'] = $showRFQ; 

Дані RFQ-кошика зберігаються в сесії або в таблиці bl_rfq зі статусом draft. При відправленні статус змінюється на new, менеджер отримує сповіщення.

Інтеграція з CRM та сповіщення

При переході заявки в статус new створюється угода в CRM через REST API crm.deal.add. Товарні позиції передаються через crm.deal.productrows.set. Сповіщення менеджеру — через \Bitrix\Im\Notify::send() та email з шаблоном RFQ_NEW_REQUEST.

Менеджер в адміністративному інтерфейсі заповнює price_quoted, ставить статус quoted. Клієнт отримує email з посиланням на особистий кабінет. При прийнятті статус accepted, потім створюється замовлення в b_sale_order з фіксованими цінами.

Переваги RFQ перед ручною обробкою