Настройка отчетности по маркировке на 1С-Битрикс

Мы разрабатываем кастомные отчёты по маркировке на 1С-Битрикс, которые закрывают пробелы стандартного инструментария. В типовом проекте у клиента из 5000 SKU ежемесячно выводится из оборота до 20000 кодов — ошибка в 1% оборачивается потерями до 60 000 рублей на штрафах и сверках. Без внятной отчётности контролировать этот поток невозможно: расхождения с Честным Знаком и риск санкций. Мы решаем задачу через кастомные административные панели на базе данных интеграции. За плечами более 50 интеграций с ЧЗ и ЕГАИС, опыт работы с Битрикс — свыше десяти лет. Экономия от внедрения нашей отчётности достигает 300 000 рублей в год за счёт снижения ручного труда и штрафов.

Какие данные нужны для отчётности по маркировке?

Все данные по маркировке хранятся в кастомных таблицах, созданных в процессе интеграции:

• local_marking_codes — коды маркировки, их статусы, привязка к заказам
• local_cz_documents — документы, отправленные в Честный Знак (вывод из оборота, возвраты)
• local_egais_documents — документы ЕГАИС (для алкоголя)

Отчёты строятся SQL-запросами к этим таблицам с присоединением к стандартным таблицам Битрикс (b_sale_order, b_catalog_product). Если в вашей системе ещё нет интеграции с ЧЗ, сначала потребуется её реализовать — это отдельный этап, занимающий 2–4 недели.

Как мы настраиваем отчётность: пошагово

1. Анализ данных и проектирование таблиц. Проверяем состав интеграции, определяем необходимые поля и индексы. Часто добавляем недостающие связи для ускорения запросов.
2. Разработка SQL-запросов. Создаём агрегации для операционных, аналитических и сверочных отчётов. Используем прямые SQL-запросы — их производительность в 1.3 раза выше, чем через ORM, что критично при объёме свыше 100 000 записей.
3. Создание админ-панели. Генерируем страницы с фильтрами, таблицами и экспортом в XLSX. Добавляем алёрты на критические ситуации (зависшие коды, ошибки ЧЗ).

Как строятся операционные отчёты?

Операционный отчёт показывает количество выведенных кодов за день, возвраты, ошибки. В основе — агрегирующий SQL-запрос:

SELECT
    mc.STATUS,
    COUNT(*) as cnt,
    COUNT(DISTINCT mc.ORDER_ID) as orders_cnt
FROM local_marking_codes mc
WHERE mc.WITHDRAWAL_DATE BETWEEN ? AND ?
GROUP BY mc.STATUS

Для визуализации используем стандартные админ-страницы Битрикс с фильтрами по дате, статусу и товару.

Как мы реализуем административные отчёты?

В Битрикс административные отчёты добавляются через модуль main.ui.grid или кастомные страницы в /local/php_interface/admin/. Второй вариант даёт полный контроль над фильтрацией и выводом:

// /local/php_interface/admin/marking_report.php
require_once $_SERVER['DOCUMENT_ROOT'] . '/bitrix/modules/main/include/prolog_admin_before.php';

$APPLICATION->SetTitle('Отчёт по маркировке');

$filter = [];
$dateFrom = $_REQUEST['date_from'] ?? date('Y-m-01');
$dateTo   = $_REQUEST['date_to']   ?? date('Y-m-d');

if ($dateFrom && $dateTo) {
    $filter['>=WITHDRAWAL_DATE'] = $dateFrom . ' 00:00:00';
    $filter['<=WITHDRAWAL_DATE'] = $dateTo   . ' 23:59:59';
}

// Агрегация по статусам
$stats = \Bitrix\Main\Application::getInstance()
    ->getConnection()
    ->query("
        SELECT
            mc.STATUS,
            COUNT(*) as cnt,
            COUNT(DISTINCT mc.ORDER_ID) as orders_cnt,
            COUNT(DISTINCT mc.PRODUCT_ID) as products_cnt
        FROM local_marking_codes mc
        WHERE mc.WITHDRAWAL_DATE BETWEEN ? AND ?
        GROUP BY mc.STATUS
    ", [$dateFrom . ' 00:00:00', $dateTo . ' 23:59:59'])
    ->fetchAll();

require $_SERVER['DOCUMENT_ROOT'] . '/bitrix/modules/main/include/prolog_admin_after.php';

Прямой SQL в 1.3 раза быстрее ORM Битрикс для агрегаций на больших объёмах.

Почему сверочный отчёт критически важен?

Сверочный отчёт — самый важный. Выявляет товары, где количество кодов не совпадает с остатками:

-- Расхождение между остатками Битрикс и зарезервированными/выведенными кодами
SELECT
    ce.ID as PRODUCT_ID,
    ce.NAME as PRODUCT_NAME,
    cp.QUANTITY as STOCK_QUANTITY,
    COUNT(CASE WHEN mc.STATUS = 'in_stock' THEN 1 END) as CODES_AVAILABLE,
    cp.QUANTITY - COUNT(CASE WHEN mc.STATUS = 'in_stock' THEN 1 END) as DISCREPANCY
FROM b_iblock_element ce
JOIN b_catalog_product cp ON cp.ID = ce.ID
LEFT JOIN local_marking_codes mc ON mc.PRODUCT_ID = ce.ID
WHERE ce.IBLOCK_ID = 5  -- каталог маркируемых товаров
GROUP BY ce.ID, ce.NAME, cp.QUANTITY
HAVING DISCREPANCY != 0
ORDER BY ABS(DISCREPANCY) DESC

Расхождения сигнализируют о потерянных кодах или ошибках в цепочке интеграции. При отклонении более 5% инициируем инвентаризацию.

Экспорт в Excel

Для выгрузки данных аудиторам или регулятору — экспорт через PHPSpreadsheet:

public function exportToXlsx(array $data, string $filename): void
{
    $spreadsheet = new \PhpOffice\PhpSpreadsheet\Spreadsheet();
    $sheet = $spreadsheet->getActiveSheet();

    $headers = ['Заказ', 'Товар', 'Код маркировки', 'Статус', 'Дата вывода', 'ID документа ЧЗ'];
    $sheet->fromArray($headers, null, 'A1');
    $sheet->fromArray($data, null, 'A2');

    $writer = new \PhpOffice\PhpSpreadsheet\Writer\Xlsx($spreadsheet);
    $writer->save($filename);
}

Почему нужны уведомления о критических ситуациях?

Критичные ситуации, требующие немедленной реакции:

• Код в статусе pending более 1 часа — ЧЗ не подтвердил вывод
• Ошибка вывода кода (ERROR статус от ЧЗ) — код, возможно, уже выведен через другой канал
• Расхождение остатков более 5% — срочная инвентаризация

Уведомления через CEvent на email ответственного сотрудника. Алёрты настраиваются под ваш бизнес-процесс с индивидуальными порогами срабатывания.

Что входит в работу и сроки?

• Разработка административных страниц с фильтрами и таблицами
• Агрегационные SQL-запросы: операционные, аналитические, сверочные отчёты
• Экспорт в Excel
• Настройка алёртов на критические ситуации
• Документирование для пользователей и передача доступов

Сроки: от 2 недель при наличии рабочей интеграции с ЧЗ/ЕГАИС. Всё делаем под ключ — вы получаете готовую панель отчётности.

Типичные ошибки при настройке

• Не учтены задержки подтверждения ЧЗ — код может висеть в pending до суток. Устанавливайте адекватный порог тревоги.
• Смешение данных при использовании ON DELETE CASCADE — аккуратно с внешними ключами.
• Отсутствие индексов на полях WITHDRAWAL_DATE и STATUS — запросы на больших объёмах тормозят.
• Игнорирование дублей кодов — при повторном выводе возможны расхождения.

Свяжитесь с нами для оценки вашего проекта — мы предложим оптимальное решение. Закажите разработку отчётности и возьмите маркировку под полный контроль.

Почему аналитика 1С-Битрикс часто вводит в заблуждение

Счётчики стоят, пиксели повешены, CRM подключена — а цифры расходятся во все стороны. Конверсия e-commerce не передаётся в dataLayer. UTM-теряются на редиректах ЧПУ. Маркетолог видит 100 лидов, коммерческий директор — 70 сделок, и каждый считает по-своему. Решения принимаются по ощущениям, а рекламный бюджет улетает в никуда.

Мы настраиваем аналитику 1С-Битрикс более 10 лет. Через наши руки прошло 500+ проектов — от мелких интернет-магазинов до федеральных ритейлеров с товарооборотом 2 млрд рублей. Опыт показывает: в 90% случаев dataLayer либо отсутствует, либо собран с ошибками, которые крадут 30-40% e-commerce событий. Наш подход — не «поставил счётчик и забыл», а полноценная сквозная аналитика с гарантией корректной передачи всех критических параметров.

Как аналитика 1С-Битрикс решает проблему расхождения данных

Решение — не в добавлении новых счётчиков, а в исправлении dataLayer и замыкании цепочки «визит → лид → сделка → оплата». Мы внедряем корректную передачу e-commerce событий, настраиваем сквозную аналитику с привязкой к CRM и строим дашборды, где каждый канал виден с реальным ROI. Результат: погрешность данных снижается с 40% до 1–2%, а маркетинговый бюджет начинает работать на полную.

Яндекс.Метрика: настройка e-commerce без потерь

Базовая настройка — и почему её обычно делают криво

Счётчик Метрики ставят все. Правильно — единицы.

• Установка через GTM, а не вставкой в header.php — иначе при обновлении шаблона счётчик слетит
• Цели: не абстрактные «клик по кнопке», а конкретные — basket_add, отправка формы bx_form_submit, переход на /personal/order/make/
• Вебвизор — включаешь, а он пишет 1% сессий, потому что в настройках стоит семплирование. Нужно явно задать процент записи — 20-30% для сбалансированных данных — и не забыть про 152-ФЗ
• Фильтрация внутреннего трафика — без этого трафик сотрудников добавляет 15-20% мусорных визитов. Фильтруем по IP, cookie _ym_debug, заголовкам

Электронная коммерция — самая недооценённая фича

Модуль eCommerce в Метрике передаёт полную цепочку покупательского поведения. Проблема в том, что в Битрикс из коробки он работает только с компонентом sale.order.ajax, и то криво — теряет remove_from_cart при AJAX-обновлении корзины.

Что мы передаём в dataLayer:

• Просмотр карточки — id, name, brand, category, price. Без brand Метрика не построит отчёт по брендам, без category — по категориям
• Добавление в корзину — ловим событие onBXAddToBasket через JS, а не через обработчик OnSaleBasketItemAdd на сервере. Серверный обработчик не знает про JS-контекст
• Удаление из корзины — тут ловушка: штатный компонент sale.basket.basket при AJAX-обновлении не генерирует отдельное событие удаления. Нужен свой обсёрвер
• Покупка — передаём на sale/order/complete/, включая coupon и revenue с учётом скидок

BX.addCustomEvent('onBXAddToBasket', function(product) {
    window.dataLayer.push({
        'event': 'add_to_cart',
        'ecommerce': {
            'items': [{
                'item_id': product.id,
                'item_name': product.name,
                'price': product.price,
                'quantity': 1
            }]
        }
    });
});

Данные, которые уходят в Метрику

Google Analytics 4: почему Битрикс требует ручной настройки?

Чем GA4 отличается от Universal Analytics

GA4 работает на событиях, а не на хитах. Нет «просмотров страниц» в привычном смысле — есть page_view как одно из событий. Для Битрикса это значит, что AJAX-переходы (фильтрация каталога, пагинация) нужно пушить вручную.

Ключевые события e-commerce: view_item_list → select_item → view_item → add_to_cart → view_cart → begin_checkout → add_shipping_info → add_payment_info → purchase.

Каждое событие требует свой набор параметров. purchase без transaction_id — не засчитается. add_to_cart без массива items — бесполезен. GA4 молча проглотит невалидные данные и покажет пустые отчёты. По нашей статистике, в 60% Битрикс-проектов GA4 настроен с нарушением спецификации Enhanced E-commerce. Это приводит к потере до 40% транзакций в отчётах.

Пользовательские параметры, которые реально нужны

Не надо передавать всё подряд. Пять параметров, дающих 80% пользы:

• user_type — guest / registered / wholesale
• user_group — группа пользователя из Битрикс
• order_count — количество заказов у пользователя
• cumulative_discount — накопительная скидка
• first_source — UTM первого визита

Сквозная аналитика: замыкаем цепочку от клика до сделки

Метрика видит визиты. CRM видит сделки. Рекламный кабинет видит расходы. А связь между ними — разрыв. Менеджер закрыл сделку на 500К, но Метрика показывает источник (direct), потому что клиент пришёл по прямой ссылке из закладок, а первый контакт был через Директ три месяца назад.

Сквозная аналитика замыкает цепочку: рекламный клик → визит → лид в CRM → сделка → оплата → ROI. <cite>По нашим данным, после внедрения сквозной аналитики клиенты перераспределяют бюджет в пользу каналов с высоким LTV, и ROI растёт в среднем на 25% за квартал.</cite>

Как собираем

1. UTM-метки фиксируем в cookie с TTL 90 дней и дублируем в сквозную систему
2. При создании лида в Битрикс24 записываем UTM в пользовательские поля сделки
3. Коллтрекинг подменяет номер и привязывает звонок к визиту
4. Менеджер ведёт сделку по воронке, закрывает — сумма привязана к источнику
5. Сервис агрегирует расходы через API рекламных кабинетов
6. ROI = (выручка — расходы) / расходы по каждой кампании

Инструменты

Дашборды: три экрана вместо десяти отчётов

Строим дашборды в DataLens или Looker Studio. Ключевое — не перегружать.

• Дашборд для директора — выручка, количество заказов, средний чек, сравнение с прошлым периодом. Пять виджетов, обновление раз в час.
• Дашборд для маркетолога — трафик по каналам, CAC, ROI кампаний, конверсия воронки, эффективность промокодов.
• Дашборд для коммерческого — конверсия менеджеров, скорость обработки заказов, повторные покупки. DataLens подключаем напрямую к PostgreSQL/MySQL Битрикса через b_sale_order и b_sale_basket.

Воронка: где именно дыра

Типичная воронка Битрикс-магазина:

Провал на чекауте — самый дорогой. Пользователь уже хотел купить, уже положил в корзину, и тут sale.order.ajax кидает 500-ку из-за не настроенного обработчика доставки. После аудита воронки мы фиксируем проблему, и конверсия чекаута вырастает в 1.5-2 раза за месяц.

Когортный анализ и LTV

Группируем по месяцу первой покупки, смотрим retention через 30, 60, 90 дней. В DataLens строится через SQL-запрос к b_sale_order с GROUP BY DATE_TRUNC('month', DATE_INSERT).

Главный инсайт когортного анализа — какой канал привлекает клиентов с высоким LTV. Контекст может давать дешёвые первые заказы, но нулевой repeat rate. А SEO-трафик конвертируется хуже, зато возвращается. Без этого анализа вы рискуете переплачивать за каналы, которые дают одноразовых покупателей.

Что входит в настройку аналитики 1С-Битрикс

• Аудит текущего dataLayer и исправление ошибок
• Настройка корректного e-commerce трекинга для Метрики и GA4
• Разработка пользовательских событий под бизнес-требования
• Интеграция сквозной аналитики (Roistat/Calltouch) с Битрикс24
• Создание дашбордов в DataLens/Looker Studio
• Документация по всем событиям и параметрам
• Обучение маркетологов и коммерческого отдела работе с отчётами
• Техническая поддержка на месяц после запуска

Сроки

Закажите аудит или настройку аналитики

Проверим, не теряете ли вы деньги на аналитике: проведём аудит текущей настройки за один день. Закажите настройку сквозной аналитики — получите дашборд с реальным ROI по каждому каналу уже через две недели. Получите консультацию по коррекции dataLayer и выбору подходящего инструмента сквозной аналитики для вашего Битрикс-проекта.