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

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

Штатна аналітика модуля sale у 1С-Бітрікс покриває базові сценарії — виручка за період, кількість замовлень, конверсія за статусами. Але щойно бізнес виходить за межі «скільки продали за місяць», починаються проблеми. Потрібна сегментація клієнтів, аналіз за менеджерами з урахуванням повернень, розбивка маржинальності за категоріями товарів — і штатних інструментів уже недостатньо.

Власні звіти розв'язують це завдання: повний контроль над вибіркою даних, довільна групування та агрегація, візуалізація у потрібному форматі та експорт для подальшої роботи.

Штатні звіти модуля sale: що є і чого не вистачає

Модуль sale надає кілька вбудованих звітів через адміністративний розділ: звіт за замовленнями, звіт за товарами, зведення за статусами. Вони працюють через компонент bitrix:sale.report.construct та використовують внутрішній механізм побудови звітів.

Обмеження штатних звітів:

• Фіксований набір групувань — не можна додати довільне поле
• Немає кросс-таблиць (pivot) — неможливо побудувати матрицю «товар × регіон»
• Відсутній когортний аналіз та RFM-сегментація
• Експорт лише у CSV з обмеженим форматуванням
• Немає можливості будувати складені метрики (LTV, середній чек з урахуванням повернень, маржинальність)

Для магазинів з обігом від кількох тисяч замовлень на місяць цих звітів об'єктивно мало.

ORM-запити через OrderTable та суміжні сутності

Основа власних звітів — D7 ORM Бітрікс. Ключові таблиці:

ORM дозволяє будувати запити з JOIN-ами, групуванням та агрегатними функціями без написання сирого SQL. Приклад — виручка за місяцями з групуванням за менеджером:

$result = OrderTable::getList([
    'select' => [
        'MONTH' => new ExpressionField('MONTH', "DATE_TRUNC('month', %s)", ['DATE_INSERT']),
        'RESPONSIBLE_ID',
        'TOTAL' => new ExpressionField('TOTAL', 'SUM(%s)', ['PRICE']),
        'CNT' => new ExpressionField('CNT', 'COUNT(%s)', ['ID']),
    ],
    'filter' => [
        '>=DATE_INSERT' => DateTime::createFromPhp(new \DateTime('2024-01-01')),
        '!STATUS_ID' => 'F', // виключаємо скасовані
    ],
    'group' => ['MONTH', 'RESPONSIBLE_ID'],
    'order' => ['MONTH' => 'ASC'],
]);

Для складних запитів з підзапитами та CTE іноді потрібно використовувати $DB->Query() напряму — ORM не охоплює всі SQL-конструкції.

Групування та агрегація: типові розрізи

Практика показує, що бізнесу частіше за все потрібні такі розрізи:

За періодами — день, тиждень, місяць, квартал. Використовується DATE_TRUNC у PostgreSQL або DATE_FORMAT у MySQL. Важливо враховувати часовий пояс сервера при агрегації за днями.

За товарами та категоріями — JOIN з BasketTable та інфоблоками каталогу. Тут потрібно акуратно обробляти SKU: торгові пропозиції (SKU) посилаються на основний елемент через PROPERTY_CML2_LINK, та групування варто робити саме за батьківським товаром.

За менеджерами — поле RESPONSIBLE_ID у замовленні. Корисно доповнювати дані з \Bitrix\Main\UserTable (ПІБ, відділ) та рахувати не лише виручку, а й кількість оброблених замовлень, середній чек, відсоток скасувань.

За регіонами — через властивості замовлення (місто, область) або через привязку до місцезнаходжень (\Bitrix\Sale\Location\LocationTable). Дерево місцезнаходжень Бітрікс дозволяє агрегувати за рівнями — місто → область → країна.

Візуалізація та експорт

Для відображення графіків на власній сторінці адміністрування добре себе зарекомендував Chart.js — легка бібліотека, що не потребує збірки. Підключається через CDN або локальний файл у /local/admin/. Дані передаються JSON-масивом з PHP.

Типовий набір візуалізацій для дашборду e-commerce:

• Line chart — динаміка виручки та замовлень за періодами
• Bar chart — порівняння менеджерів або категорій
• Doughnut — частки платіжних систем або статусів
• Heatmap (через плагін chartjs-chart-matrix) — активність за днями тижня та годинами

Експорт в Excel реалізується через PhpSpreadsheet. Бібліотека встановлюється через Composer у /local/:

cd /home/bitrix/www/local
composer require phpoffice/phpspreadsheet

PhpSpreadsheet дозволяє формувати файли з форматуванням, формулами, кількома листами — повноцінні звіти, які бухгалтерія може використовувати без додаткової обробки.

Дашборд у адміністративній панелі

Власна сторінка розміщується у /local/admin/. Для інтеграції з адміністративним меню використовується файл /local/admin/menu.php або обробник події OnBuildGlobalMenu.

Структура типового дашборду:

/local/admin/
├── custom_dashboard.php      # точка входу
├── reports/
│   ├── sales_by_period.php   # звіт за періодами
│   ├── rfm_analysis.php      # RFM-аналіз
│   └── manager_stats.php     # статистика менеджерів
├── ajax/
│   └── report_data.php       # AJAX-endpoint для графіків
└── assets/
    ├── chart.min.js
    └── dashboard.css

Кожна сторінка підключає пролог (require_once $_SERVER['DOCUMENT_ROOT'].'/bitrix/modules/main/include/prolog_admin_before.php') та використовує клас CAdminPage для однорідного оформлення. Для AJAX-запитів — окремі endpoints з перевіркою прав через $APPLICATION->GetGroupRight('sale').

Глибокий аналіз: звіт RFM-аналізу клієнтів

RFM-аналіз сегментує клієнтів за трьома параметрами:

• Recency — давність останньої покупки
• Frequency — частота покупок за період
• Monetary — сума покупок за період

Кожен параметр оцінюється за шкалою від 1 до 5 (квінтилі). Комбінація дає 125 сегментів, які групуються у практично корисні категорії: «лояльні», «засипаючі», «втрачені», «нові перспективні».

Алгоритм побудови:

1. Вибір усіх клієнтів з завершеними замовленнями за період аналізу (зазвичай 12 місяців)
2. Для кожного клієнта розраховуємо три метрики — дата останнього замовлення, кількість замовлень, загальна сума
3. Розподіляємо клієнтів за квінтилями для кожної метрики. Квінтилі рахуються через NTILE(5) OVER (ORDER BY ...) у SQL або програмно через сортування та розділення масиву на 5 рівних частин
4. Призначаємо сегмент за комбінацією R-F-M

SQL-запит для розрахунку базових метрик:

SELECT
    o.USER_ID,
    MAX(o.DATE_INSERT) AS last_order_date,
    EXTRACT(DAY FROM NOW() - MAX(o.DATE_INSERT)) AS recency_days,
    COUNT(o.ID) AS frequency,
    SUM(o.PRICE) AS monetary
FROM b_sale_order o
WHERE o.STATUS_ID NOT IN ('F', 'CA')
  AND o.DATE_INSERT >= NOW() - INTERVAL '12 months'
  AND o.PAYED = 'Y'
GROUP BY o.USER_ID

Маппінг сегментів. Не всі 125 комбінацій однаково корисні. На практиці використовується спрощена таблиця:

Відображення в дашборді. RFM-звіт виводиться як таблиця з фільтрацією за сегментом та можливістю експорту списку клієнтів. Окремо — treemap-візуалізація розподілу клієнтів за сегментами (розмір блоку = кількість клієнтів, колір = monetary).

Для автоматизації звіт запускається за розкладом через агента Бітрікс (CAgent). Результат кешується у окрему таблицю — перерахунок на 50 000 клієнтів займає 10-15 секунд, та робити це при кожному відкритті сторінки недоцільно.

Етапи розробки власних звітів

Власні звіти — це інвестиція в керованість бізнесу. Штатні засоби Бітрікс дають старт, але для прийняття рішень на основі даних потрібна аналітика, заточена під конкретний бізнес-процес.