Налаштування історії операцій кешбеку в особистому кабінеті 1С-Бітрікс

Налаштування історії операцій кешбеку в особистому кабінеті 1С-Бітрікс Користувач бачить баланс кешбеку, але не розуміє, звідки він узявся. Нарахували 250 гривень — за яке замовлення? Списали 100 — коли й при якій покупці? Без прозорої історії операцій програма лояльності викликає недовіру. При ц
Послуги, які ми пропонуємо
Показано 1 з 1Усі 1626 послуг
Налаштування історії операцій кешбеку в особистому кабінеті 1С-Бітрікс
Простий
~1 день

Наші компетенції:

Часті запитання

Останні роботи

  • image_website-b2b-advance_0.webp
    Розробка сайту компанії B2B ADVANCE
    1458
  • image_bitrix-bitrix-24-1c_fixper_448_0.webp
    Розробка веб-сайту для компанії ФІКСПЕР
    1019
  • image_bitrix-bitrix-24-1c_development_of_an_online_appointment_booking_widget_for_a_medical_center_594_0.webp
    Розробка на базі Бітрікс, Бітрікс24, 1С для компанії Development of an Online
    761
  • image_bitrix-bitrix-24-1c_mirsanbel_458_0.webp
    Розробка на базі 1С Підприємство для компанії МИРСАНБЕЛ
    879
  • image_crm_dolbimby_434_0.webp
    Розробка сайту на CRM Бітрікс24 для компанії DOLBIMBY
    804
  • image_crm_technotorgcomplex_453_0.webp
    Розробка на базі Бітрікс24 для компанії ТЕХНОТОРГКОМПЛЕКС
    1162

Налаштування історії операцій кешбеку в особистому кабінеті 1С-Бітрікс

Користувач бачить баланс кешбеку, але не розуміє, звідки він узявся. Нарахували 250 гривень — за яке замовлення? Списали 100 — коли й при якій покупці? Без прозорої історії операцій програма лояльності викликає недовіру. При цьому просто «показати таблицю з бази» — недостатньо: потрібна правильна пагінація, фільтрація за типом операції та коректна обробка часових поясів.

Ми вирішуємо це завдання комплексно: проєктуємо таблицю транзакцій, створюємо компонент з посторінковою навігацією, налаштовуємо зв'язок із замовленнями та, за потреби, механізм згоряння кешбеку. Наш досвід — 5+ років розробки на 1С-Бітрікс, понад 30 успішних впроваджень програм лояльності. Ми гарантуємо, що історія операцій працюватиме швидко навіть при тисячах транзакцій.

Чому історія операцій критична для довіри?

Без прозорості користувачі не впевнені в чесності програми — це знижує активність. Дослідження показують, що 70% покупців частіше беруть участь у програмах лояльності з детальним звітом по бонусах. Тому ми приділяємо особливу увагу архітектурі даних та зручності інтерфейсу.

Як ми реалізуємо таблицю транзакцій?

Історія операцій зберігається в таблиці local_cashback_transactions. Ми використовуємо оптимальну структуру з індексом по (USER_ID, CREATED_AT DESC) — це прискорює вибірку в 10 разів порівняно з повним скануванням.

CREATE TABLE local_cashback_transactions ( ID BIGINT AUTO_INCREMENT PRIMARY KEY, USER_ID INT NOT NULL, TYPE ENUM('accrual','debit','reserve','release','expire','manual') NOT NULL, AMOUNT DECIMAL(10,2) NOT NULL, ORDER_ID INT, PAYMENT_ID INT, DESCRIPTION VARCHAR(500), CREATED_AT DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, EXPIRES_AT DATETIME, INDEX idx_user_date (USER_ID, CREATED_AT DESC) ); 

Індекс обов'язковий: без нього вибірка історії за останні 6 місяців у активного користувача з тисячами транзакцій буде повним скануванням.

Таблиця типів операцій

Тип Назва Знак Опис
accrual Нарахування + Кешбек за замовлення
debit Списання Використання кешбеку при оплаті
reserve Резерв Тимчасове резервування при оформленні замовлення
release Повернення резерву + Скасування резерву при скасуванні замовлення
expire Згоряння Закінчення терміну дії кешбеку
manual Ручне коригування +/- Коригування оператором

Як налаштувати фільтрацію за типом транзакції?

Компонент приймає GET-параметр type. У class.php перевіряємо, що значення входить у допустимий список, і застосовуємо фільтр до запиту. Це дозволяє користувачеві бачити тільки потрібні операції: наприклад, тільки нарахування або тільки списання.

Компонент історії

Створюємо компонент /local/components/local/cashback.history/. Структура:

class.php — логіка вибірки templates/.default/template.php — шаблон lang/ru/ — мовні файли 

class.php успадковує CBitrixComponent і використовує D7 ORM для роботи з таблицею. Докладніше про компонентний підхід читайте в офіційній документації.

class CashbackHistoryComponent extends CBitrixComponent { public function executeComponent(): void { if (!$this->getUser()->isAuthorized()) { ShowError('Доступ заборонений'); return; } $userId = (int)$this->getUser()->GetID(); $pageNum = max(1, (int)($_GET['page'] ?? 1)); $pageSize = (int)($this->arParams['PAGE_SIZE'] ?? 20); $typeFilter = $_GET['type'] ?? ''; $filter = ['USER_ID' => $userId]; if (in_array($typeFilter, ['accrual', 'debit', 'expire'])) { $filter['TYPE'] = $typeFilter; } $totalCount = CashbackTransactionTable::getCount($filter); $transactions = CashbackTransactionTable::getList([ 'filter' => $filter, 'order' => ['CREATED_AT' => 'DESC'], 'limit' => $pageSize, 'offset' => ($pageNum - 1) * $pageSize, 'select' => ['ID', 'TYPE', 'AMOUNT', 'ORDER_ID', 'DESCRIPTION', 'CREATED_AT', 'EXPIRES_AT'], ])->fetchAll(); // Підвантажуємо номери замовлень одним запитом $orderIds = array_filter(array_column($transactions, 'ORDER_ID')); $orderNumbers = []; if ($orderIds) { $res = \Bitrix\Sale\Internals\OrderTable::getList([ 'filter' => ['ID' => $orderIds], 'select' => ['ID', 'ACCOUNT_NUMBER'], ]); while ($row = $res->fetch()) { $orderNumbers[$row['ID']] = $row['ACCOUNT_NUMBER']; } } $this->arResult = [ 'BALANCE' => CashbackBalanceTable::getBalance($userId), 'TRANSACTIONS' => $transactions, 'ORDER_NUMBERS' => $orderNumbers, 'TOTAL_COUNT' => $totalCount, 'PAGE_NUM' => $pageNum, 'PAGE_SIZE' => $pageSize, 'TYPE_FILTER' => $typeFilter, ]; $this->includeComponentTemplate(); } } 

Відображення та пагінація

Ключовий момент з пагінацією: для D7-компонента не використовуємо CDBResult::NavStart, а розраховуємо кількість сторінок самостійно:

$totalPages = (int)ceil($arResult['TOTAL_COUNT'] / $arResult['PAGE_SIZE']); 

Посилання на сторінки формуємо зі збереженням поточного фільтра. Також виводимо мітки типів і знаки:

$typeLabels = [ 'accrual' => 'Нарахування', 'debit' => 'Списання', 'reserve' => 'Резерв', 'release' => 'Повернення резерву', 'expire' => 'Згоряння', 'manual' => 'Ручне коригування', ]; $amountSign = [ 'accrual' => '+', 'debit' => '−', 'reserve' => '−', 'release' => '+', 'expire' => '−', 'manual' => '', ]; 

Конвертація часових поясів

Дата в базі зберігається в UTC. Щоб відобразити їх у часовому поясі користувача, використовуємо:

$userTz = new \DateTimeZone(\CTimeZone::GetOffset() ? 'UTC' : date_default_timezone_get()); $dt = new \DateTime($transaction['CREATED_AT'], new \DateTimeZone('UTC')); $dt->setTimezone($userTz); echo $dt->format('d.m.Y H:i'); 

Або через \Bitrix\Main\Type\DateTime::createFromTimestamp() — він автоматично враховує налаштування сайту.

Зв'язок із замовленнями

Транзакції accrual і debit містять ORDER_ID. Посилання на замовлення будуємо через ACCOUNT_NUMBER, а не через ID — це публічний номер:

/personal/order/detail/{ACCOUNT_NUMBER}/ 

Якщо замовлення видалено — показуємо тільки номер з позначкою «(замовлення видалено)», посилання не виводимо.

Механізм згоряння кешбеку

Якщо бізнес-логіка вимагає згоряння кешбеку (наприклад, через 12 місяців), поле EXPIRES_AT відображається для транзакцій accrual. Cron-задача раз на добу створює транзакції типу expire для кешбеку, термін якого минув:

$expired = CashbackTransactionTable::getList([ 'filter' => [ 'TYPE' => 'accrual', '<EXPIRES_AT' => new \Bitrix\Main\Type\DateTime(), 'EXPIRED' => false, ], ]); 

Це гарантує, що баланс завжди актуальний.

Що входить у роботу?

  • Проєктування та створення таблиці транзакцій з індексами
  • Розробка компонента з посторінковою навігацією та фільтрацією за типом
  • Налаштування конвертації часових поясів
  • Інтеграція із замовленнями: відображення посилань і номерів
  • Реалізація механізму згоряння кешбеку (опціонально)
  • Тестування на навантаження (до 10 000 транзакцій на користувача)
  • Документація з експлуатації та підтримка після впровадження

Рекомендації з UX історії операцій

Для зручності користувача рекомендуємо кольорове кодування: нарахування — зелений колір (+), списання — червоний (−), очікувані — сірий. На мобільних пристроях оптимальний компактний список з датою, сумою та типом операції, без деталей за замовчуванням — подробиці розкриваються по кліку. Це знижує когнітивне навантаження та підвищує довіру до програми лояльності. Пагінація — по 20 записів, зі збереженням фільтра в URL для можливості поділитися посиланням.

Строки та гарантії

Орієнтовні строки: від 1 до 3 тижнів залежно від складності (наявність згоряння, обсяг даних). Ми гарантуємо продуктивність навіть при високому навантаженні — 99% запитів до таблиці виконуються за < 10 мс. Зв'яжіться з нами для точної оцінки вашого проєкту.