Разработка кастомных отчетов для интернет-магазина 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-эндпоинт для графиков
└── assets/
    ├── chart.min.js
    └── dashboard.css

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

Deep-dive: отчёт 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 секунд, и делать это при каждом открытии страницы нецелесообразно.

Этапы разработки кастомных отчётов

Кастомные отчёты — это инвестиция в управляемость бизнеса. Штатные средства Битрикса дают старт, но для принятия решений на основе данных нужна аналитика, заточенная под конкретный бизнес-процесс.