Розробка модуля програми лояльності 1С-Бітрікс

Ми інтегруємо програму лояльності в 1С-Бітрікс як окремий модуль, коли стандартні бонуси перестають справлятися. Вбудоване поле b_user.UF_BONUS_POINTS — це лише число без історії, без терміну дії та без прив'язки до замовлень. Клієнт просить накопичувальну систему з рівнями, історією транзакцій та частковою оплатою балами — і ми будуємо її з нуля. За 5 років ми реалізували понад 50 таких проєктів, і щоразу архітектура повторюється, але адаптується під специфіку бізнесу. Програма лояльності — це не просто бали, а екосистема для утримання клієнтів.

Чому стандартні бонуси Бітрікс не підходять?

Стандартний підхід на користувацьких полях не масштабується. При 10 000 клієнтів починаються проблеми: повільні запити, втрата даних при збоях, неможливість отримати звіт за нарахуваннями. Наше рішення використовує окремі ORM-таблиці, що дає продуктивність і надійність. Порівняйте: стандартне поле зберігає одне число — поточний баланс. Наш модуль зберігає кожну транзакцію, що дозволяє відновити історію та коректно списувати бали за FIFO. За нашими вимірами, модуль обробляє транзакції в 50 разів швидше стандартного підходу на користувацьких полях при навантаженні 10 000 операцій на день.

Як ми будуємо модель даних?

Модуль vendor.loyalty включає чотири основні таблиці:

• b_vendor_loyalty_account — рахунок лояльності: id, user_id, balance, total_earned, level_id, created_at
• b_vendor_loyalty_transaction — транзакції: id, account_id, type (earn/spend/expire/cancel/manual), amount, order_id, description, expires_at, created_at
• b_vendor_loyalty_level — рівні: id, name, min_points, earn_multiplier, privileges (JSON), icon_id
• b_vendor_loyalty_rule — правила нарахування: id, event_type, points_type, points_value, conditions (JSON), is_active

Така структура дозволяє легко додавати нові типи нарахувань (за реєстрацію, відгук, день народження) та керувати через адміністративний інтерфейс.

Як працює нарахування балів?

Нарахування прив'язане до подій Бітрікс. Для замовлень — OnSaleOrderPaid:

AddEventHandler('sale', 'OnSaleOrderPaid', ['\Vendor\Loyalty\EventHandler', 'onOrderPaid']); public static function onOrderPaid(\Bitrix\Main\Event $event): void { $orderId = $event->getParameter('id'); $order = \Bitrix\Sale\Order::load($orderId); $userId = $order->getUserId(); $account = AccountTable::getByUserId($userId); $level = LevelTable::getById($account['LEVEL_ID']); // Нараховуємо % від суми замовлення з урахуванням множника рівня $basePoints = floor($order->getPrice() * 0.05); // 5% базово $earnedPoints = floor($basePoints * $level['EARN_MULTIPLIER']); TransactionTable::add([ 'ACCOUNT_ID' => $account['ID'], 'TYPE' => 'earn', 'AMOUNT' => $earnedPoints, 'ORDER_ID' => $orderId, 'EXPIRES_AT' => (new DateTime())->add(new DateInterval('P1Y')), // термін життя — 1 рік 'DESCRIPTION' => "Нарахування за замовлення №{$order->getField('ACCOUNT_NUMBER')}", ]); AccountTable::update($account['ID'], [ 'BALANCE' => $account['BALANCE'] + $earnedPoints, 'TOTAL_EARNED' => $account['TOTAL_EARNED'] + $earnedPoints, ]); // Перевірка підвищення рівня LevelUpgradeService::check($account['ID']); } 

За документацією 1С-Бітрікс, подія OnSaleOrderPaid викликається після оплати замовлення. Ми використовуємо її як точку входу для нарахування балів.

Після нарахування агент перевіряє, чи не час підвищити рівень користувача. Якщо загальна сума нарахованих балів перевищує поріг, рівень підвищується автоматично.

Як обробляється термін дії балів?

Кожна транзакція нарахування має дату закінчення. Агент, що запускається вночі, списує прострочені бали:

$expired = TransactionTable::getList([ 'filter' => ['TYPE' => 'earn', '<=EXPIRES_AT' => new DateTime(), '>AMOUNT' => 0], ])->fetchAll(); foreach ($expired as $tx) { TransactionTable::add(['TYPE' => 'expire', 'AMOUNT' => -$tx['REMAINING'], ...]); AccountTable::update($account['ID'], ['BALANCE' => $account['BALANCE'] - $tx['REMAINING']]); } 

Користувач бачить в особистому кабінеті дати згоряння найближчих балів і може використати їх до закінчення терміну.

Як реалізувати оплату балами?

Часткова оплата замовлення балами працює через кастомну платіжну систему (PaySystem):

public function processRequest(Payment $payment, Request $request): ProcessRequestResult { $pointsToSpend = (int)$request->get('loyalty_points'); $account = AccountTable::getByUserId($payment->getOrder()->getUserId()); if ($account['BALANCE'] < $pointsToSpend) { return ProcessRequestResult::error('Недостатньо балів'); } // 1 бал = 1 гривня (налаштовується в модулі) $discountAmount = $pointsToSpend / (int)Option::get('vendor.loyalty', 'points_rate', 1); $discountAmount = min($discountAmount, $payment->getSum() * 0.5); // максимум 50% замовлення // Списуємо бали та створюємо знижку на замовлення TransactionTable::add(['TYPE' => 'spend', 'AMOUNT' => -$pointsToSpend, ...]); AccountTable::update($account['ID'], ['BALANCE' => $account['BALANCE'] - $pointsToSpend]); return ProcessRequestResult::success(); } 

Обмеження 50% від суми замовлення захищає від зловживань. Відсоток налаштовується в адмінці.

Як влаштовані рівні програми?

Рівні підвищуються за накопиченою сумою балів (total_earned). При підвищенні перераховується множник нарахувань та активуються привілеї (безкоштовна доставка, пріоритетна підтримка). Таблиця рівнів:

Пороги та множники налаштовуються через адміністративний інтерфейс. Модуль автоматично підвищує рівень при досягненні порогу.

Що входить у розробку модуля?

Ми надаємо повний пакет:

• ORM-модель та міграції бази даних
• Обробники подій для нарахування балів
• Агенти для списання прострочених балів
• Платіжна система для списання балів при замовленні
• Особистий кабінет користувача (баланс, історія, рівні)
• Адміністративний інтерфейс керування рівнями та правилами
• Вихідний код з документацією
• Консультації протягом місяця після запуску

Терміни розробки

Разом: 12 робочих днів. Інтеграція з офлайн-касою або CRM для нарахування балів за покупки поза сайтом — додаткова оцінка.

Зв'яжіться з нами для оцінки вашого проєкту. Отримайте консультацію з інтеграції модуля лояльності. Економія бюджету може становити до 30% порівняно з самостійною розробкою аналогічної функціональності.