הקמת תוכנית נאמנות אחידה לאונליין ולאופליין ב-Bitrix

נתקלנו במצב הזה: לקוח צבר 500 בונוסים באתר, מגיע לחנות — והקופאי לא רואה אותם. או שרכישה בחנות לא מזכה נקודות בחשבון המקוון. הפער בין תוכניות הנאמנות המקוונות והפיזיות הוא לא רק בעיית UX — זה אובדן ישיר של מכירות חוזרות. אנו מגדירים מערכת נאמנות אחידה במפתח מלא: אינטגרציה של האתר וקופות הרושמות, סנכרון בונוסים בזמן אמת, ושקיפות מלאה ללקוח.

איך נאמנות עובדת ב-Bitrix

המודול sale מיישם מערכת הנחות באמצעות b_sale_user_discount (הנחות אישיות) ומערכת בונוסים באמצעות b_sale_discount (כללי סל). תוכנית נאמנות מלאה עם נקודות מצטברות דורשת מודול נפרד או אינטגרציה עם מערכת חיצונית. ל-Bitrix24 יש מודול CRM עם בונוסים (b_crm_loyalty_bonus_transaction), אבל עבור חנות מקוונת ללא Bitrix24, משתמשים לרוב במודול marketingcrm או בטבלת עסקאות מותאמת אישית. מניסיוננו, יישום מותאם אישית מספק את הגמישות והאמינות הגדולות ביותר — אינכם כבולים למגבלות של מודול טיפוסי.

מבנה אחסון בונוסים: טבלאות ועסקאות

המבנה המינימלי לתוכנית אחידה:

CREATE TABLE bl_loyalty_account ( id SERIAL PRIMARY KEY, user_id INT UNIQUE, -- b_user.ID (онлайн) card_number VARCHAR(20) UNIQUE, -- номер карты для оффлайн balance NUMERIC(10,2) DEFAULT 0, created_at TIMESTAMP DEFAULT NOW() ); CREATE TABLE bl_loyalty_transaction ( id SERIAL PRIMARY KEY, account_id INT NOT NULL REFERENCES bl_loyalty_account(id), amount NUMERIC(10,2) NOT NULL, -- положительное=начисление, отрицательное=списание type VARCHAR(20) NOT NULL, -- 'earn_online', 'earn_offline', 'spend', 'expire' order_id INT, -- b_sale_order.ID или внешний ID оффлайн-чека source VARCHAR(20) NOT NULL, -- 'web', 'pos', 'mobile' created_at TIMESTAMP DEFAULT NOW() ); 

מודל עסקאות עם היסטוריה הוא הדרך האמינה היחידה לאחסון בונוסים. לעולם אל תעדכנו את CREATE TABLE bl_loyalty_account ( id SERIAL PRIMARY KEY, user_id INT UNIQUE, -- b_user.ID (онлайн) card_number VARCHAR(20) UNIQUE, -- номер карты для оффлайн balance NUMERIC(10,2) DEFAULT 0, created_at TIMESTAMP DEFAULT NOW() ); CREATE TABLE bl_loyalty_transaction ( id SERIAL PRIMARY KEY, account_id INT NOT NULL REFERENCES bl_loyalty_account(id), amount NUMERIC(10,2) NOT NULL, -- положительное=начисление, отрицательное=списание type VARCHAR(20) NOT NULL, -- 'earn_online', 'earn_offline', 'spend', 'expire' order_id INT, -- b_sale_order.ID или внешний ID оффлайн-чека source VARCHAR(20) NOT NULL, -- 'web', 'pos', 'mobile' created_at TIMESTAMP DEFAULT NOW() ); ישירות ללא רישום עסקה. balance הוא או מצטבר דה-נורמליזציה (מעודכן על ידי טריגר במסד נתונים) או מחושב כ-balance מטבלת העסקאות. הגישה האחרונה בטוחה יותר אך איטית יותר תחת שאילתות תדירות על יתרות.

איך לזהות לקוח בקופה פיזית?

המשימה המרכזית: הקופאי חייב למצוא את חשבון הלקוח. שיטות זיהוי:

• מספר כרטיס נאמנות (כרטיס פיזי או ברקוד באפליקציה ניידת)
• מספר טלפון (הנפוץ ביותר)
• קוד QR עם טוקן (נוצר בחשבון האישי באתר)

בזיהוי לפי טלפון, תוכנת הקופה שולחת בקשה ל-API של Bitrix:

// /local/ajax/loyalty/find-account.php $phone = normalizePhone($_POST['phone']); $bitrixUser = \CUser::GetList([], ['PERSONAL_PHONE' => $phone])->Fetch(); if ($bitrixUser) { $account = getLoyaltyAccount($bitrixUser['ID']); echo json_encode(['balance' => $account['balance'], 'account_id' => $account['id']]); } 

צבירת בונוסים בהזמנות מקוונות

Handler לשינוי סטטוס הזמנה — לאחר משלוח/השלמה:

AddEventHandler('sale', 'OnSaleStatusOrderChange', function(\Bitrix\Main\Event $event) { $order = $event->getParameter('ENTITY'); $status = $order->getField('STATUS_ID'); if ($status !== 'F') return; // Только завершённые заказы $userId = $order->getUserId(); $bonus = round($order->getPrice() * BONUS_RATE); // BONUS_RATE = 0.05 (5%) addLoyaltyTransaction($userId, $bonus, 'earn_online', $order->getId(), 'web'); }); 

ניכוי בונוסים בתשלום מקוון

בונוסים מוחלים באמצעות כלל סל או שיטת תשלום מותאמת אישית. כלל סל (SUM(amount)) יכול להעניק הנחה בסכום קבוע. עבור תוכנית גמישה יותר — "שיטת תשלום" מותאמת אישית כמו "שלם עם בונוסים", אשר בעת השלמת ההזמנה מנכה עסקה מ-// /local/ajax/loyalty/find-account.php $phone = normalizePhone($_POST['phone']); $bitrixUser = \CUser::GetList([], ['PERSONAL_PHONE' => $phone])->Fetch(); if ($bitrixUser) { $account = getLoyaltyAccount($bitrixUser['ID']); echo json_encode(['balance' => $account['balance'], 'account_id' => $account['id']]); } .

למה ניכוי עסקאות הוא קריטי?

קופה פיזית קוראת לשלושה endpoints:

1. AddEventHandler('sale', 'OnSaleStatusOrderChange', function(\Bitrix\Main\Event $event) { $order = $event->getParameter('ENTITY'); $status = $order->getField('STATUS_ID'); if ($status !== 'F') return; // Только завершённые заказы $userId = $order->getUserId(); $bonus = round($order->getPrice() * BONUS_RATE); // BONUS_RATE = 0.05 (5%) addLoyaltyTransaction($userId, $bonus, 'earn_online', $order->getId(), 'web'); }); — בדיקת יתרה
2. b_sale_discount — ניכוי בונוסים במכירה (חייב להיות עסקאות: התחלת מכירה → הזמנה → אישור)
3. bl_loyalty_transaction — צבירת בונוסים לאחר מכירה

הזמנה במהלך ניכוי היא שלב קריטי. בלעדיה, שתי בקשות מקבילות מקופות שונות יכולות לקרוא בו-זמנית יתרה של 500 בונוסים וכל אחת לנכות 500, ולרדת למינוס. הזמנה באמצעות GET /loyalty/balance?phone=... ב-PostgreSQL או באמצעות UPDATE קפדני עם בדיקת תוצאה:

UPDATE bl_loyalty_account SET balance = balance - :amount WHERE id = :account_id AND balance >= :amount RETURNING balance; -- Если обновлено 0 строк — недостаточно бонусов 

גישה זו אמינה יותר משימוש במנעולים ברמת היישום.

השוואת גישות: טבלה מותאמת אישית מול מודול Bitrix

טבלה מותאמת אישית מפסידה למודולים במהירות היישום, אבל אמינה פי 2-3 יותר תחת עומסים גבוהים ולוגיקה עסקית לא סטנדרטית.

מה כלול בעבודה

• עיצוב מבני טבלאות POST /loyalty/spend ו-POST /loyalty/earn
• פיתוח REST API למערכות קופה (יתרה, צבירה, ניכוי)
• יצירת event handlers SELECT ... FOR UPDATE לצבירות מקוונות
• מנגנון זיהוי לקוח לפי טלפון/כרטיס
• ניכוי עסקאות עם הגנה מפני תנאי מרוץ
• ממשק ניהול לצפייה וביטול עסקאות
• תיעוד API והוראות לקופאים
• בדיקות ואחריות ל-30 יום

לוחות זמנים ותקציב

הקמת תוכנית נאמנות אחידה אורכת בין 5 ל-15 ימי עבודה בהתאם למורכבות (מספר קופות, צורך באינטגרציה עם 1C, דרישות דיווח). העלות מחושבת באופן אישי לאחר בדיקת המערכת הנוכחית. נבחן את הפרויקט שלכם תוך יום אחד.

טעויות נפוצות בהקמה

• עדכון יתרה ישירות ללא עסקה — אובדן נתונים במקרה של תקלה.
• חוסר במנעולים במהלך ניכוי — ניכוי כפול.
• התעלמות מרישום API — קשה לנפות תקלות.
• שימוש רק במודול marketingcrm לאופליין — אינו תומך בהזמנות.

הימנעות מטעויות אלו דורשת ניסיון — יישמנו למעלה מ-30 פרויקטי נאמנות על Bitrix, כולל רשתות עם 50+ קופות.

צרו קשר לייעוץ: נספר לכם כיצד לאחד נאמנות אונליין ואופליין בעסק שלכם.