באתרי B2B, מחירים לרוב אינם פומביים—הם תלויים בכמות, באזור ובתנאי החוזה. במקום כפתור 'קנייה', נדרש כפתור 'בקשת מחיר': RFQ (בקשת הצעת מחיר). המודול הסטנדרטי sale אינו תומך בלוגיקה זו; הוא דורש מחיר פומבי ותשלום מיידי. בנינו מודול RFQ מותאם אישית מאפס, המעבד עד 200 בקשות ביום עבור מפיץ ציוד תעשייתי. במקרה זה, זמן התגובה ירד מ-3 ימים ל-4 שעות, ואובדן הבקשות ירד מ-25% לפחות מ-1%. קבלו ייעוץ עם המהנדס שלנו כדי לדון כיצד ליישם RFQ בפרויקט שלכם.
איזה כאב פותר מודול ה-RFQ?
ללא RFQ, מנהלים מאבדים בקשות בדוא"ל, זמני התגובה נמתחים ל-2–3 ימים, ולקוחות עוברים למתחרים. עבור מפיץ הציוד התעשייתי, ראינו זאת ממקור ראשון: 4,000 פריטים ללא מחירים פומביים, החלפת דוא"ל ידנית הובילה לאובדן של 25% מהבקשות. מודול ה-RFQ הופך את כל התהליך לאוטומטי: בקשה → עיבוד → הצעת מחיר → הזמנה.
ארכיטקטורת RFQ: טבלאות ומכונת מצבים
בקשת RFQ עוברת מספר סטטוסים: new → processing → quoted → accepted → rejected → ordered. לאחר accepted, הלקוח יכול לבצע הזמנה במחיר המוסכם דרך המודול הסטנדרטי sale.
טבלת הבקשות 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
);טבלת פריטי הבקשה 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 ); :
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
);מכונת המצבים מיושמת כאוטומט סופי: לכל סטטוס יש כללי מעבר והרשאות גישה. לדוגמה, מעבר מ-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, נשלחות הודעות ללקוח.
כיצד עובד תהליך ה-RFQ?
- הלקוח מוסיף מוצרים לעגלת ה-RFQ ושולח בקשה.
- המנהל מקבל הודעה ומעבד את הבקשה בלוח הניהול.
- המנהל קובע מחירים לכל פריט ומעביר את הבקשה לסטטוס
accepted. - הלקוח מקבל הודעה, נכנס לחשבון האישי שלו, ומאשר או דוחה את ההצעה.
- עם האישור, נוצרת הזמנה עם המחירים המוסכמים.
כפתור 'בקשת מחיר' מחליף את כפתור 'הוסף לעגלה' בכרטיסי המוצר—או מתקיים במקביל אם לחלק מהמוצרים יש מחירים פומביים. הלוגיקה נקבעת ב-rejected של רכיב quoted:
$showRFQ = ($arResult['ITEM_PRICES'][0]['PRICE'] ?? 0) === 0 || $arResult['ITEM']['PROPERTIES']['PRICE_ON_REQUEST']['VALUE'] === 'Y';
$arResult['SHOW_RFQ'] = $showRFQ;נתוני עגלת ה-RFQ נשמרים בסשן או בטבלת 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; , והמנהל מקבל הודעה.
אינטגרציה עם CRM והודעות
כאשר בקשה עוברת לסטטוס bl_rfq, נוצרת עסקה ב-CRM דרך שיטת ה-REST API draft. שורות המוצרים מועברות דרך new. הודעת המנהל מתבצעת דרך new ודוא"ל עם התבנית crm.deal.add.
בממשק הניהול, המנהל ממלא crm.deal.productrows.set, ומגדיר את הסטטוס ל-\Bitrix\Im\Notify::send(). הלקוח מקבל דוא"ל עם קישור לחשבון האישי שלו. עם האישור, הסטטוס הופך ל-RFQ_NEW_REQUEST, ולאחר מכן נוצרת הזמנה ב-price_quoted עם מחירים קבועים.
למה RFQ עדיף על עיבוד ידני?
| קריטריון | החלפת דוא"ל ידנית | מודול ה-RFQ שלנו |
|---|---|---|
| זמן תגובה | 2–3 ימים | 4 שעות |
| אובדן בקשות | 25% | <1% |
| אינטגרציית CRM | ידנית | אוטומטית |
| מכונת מצבים | אין | 6 סטטוסים |
מקרה אמיתי: מפיץ ציוד תעשייתי
מצב: 4,000 פריטים ללא מחירים פומביים, מנהלים טיפלו בבקשות ידנית דרך דוא"ל—זמן תגובה 2–3 ימים, 25% מהבקשות אבדו.
יישום:
- עגלת RFQ עם אפשרות להוספת מוצרים מרובים
- יצירה אוטומטית של עסקה ב-CRM Bitrix24 בעת שליחת בקשה
- חשבון אישי ללקוח עם היסטוריית בקשות וסטטוסים
- הודעות דוא"ל למנהל (מיידיות) וללקוח (בשינוי סטטוס)
- המרה בלחיצה אחת של הצעת מחיר מאושרת להזמנה
תוצאה: זמן עיבוד הבקשות ירד ל-4 שעות (פי 12 מהר יותר), אובדן הבקשות ירד ל-0%. המערכת מתמודדת עם עד 200 בקשות יומיות ללא תקלות.
תהליך הפיתוח ולוח זמנים
| שלב | לוח זמנים |
|---|---|
| עיצוב סכמה ומכונת מצבים | מיומיים |
| בקאנד: טבלאות, בקרים, סוכנים | מ-4 ימים |
| פרונטאנד: כפתור, עגלת RFQ, חשבון אישי | מ-4 ימים |
| אינטגרציית CRM | מיומיים |
| הודעות דוא"ל ובדיקות | מיומיים |
מה כולל הפיתוח
- עיצוב מכונת המצבים של RFQ ומודל הנתונים
- החלפה/הוספה של כפתור 'הוסף לעגלה' עבור מוצרים ללא מחיר פומבי
- עגלת RFQ עם ניהול פריטים ב-AJAX
- ממשק ניהול לעיבוד בקשות עם קביעת מחירים
- אינטגרציה עם מודול Bitrix24 CRM (עסקאות, שורות מוצרים)
- סעיף היסטוריית בקשות בחשבון האישי של הלקוח
אנו מבטיחים פתרון יציב המבוסס על שנים של ניסיון בפיתוח עבור Bitrix. הזמינו פיתוח מודול RFQ—הוא יחסוך למנהלים שלכם שעות של עבודה ידנית. נבחן את הפרויקט שלכם ונציע לוח זמנים כולל. צרו קשר כדי לדון בפרטים.

