Разработка отчетов по остаткам товаров 1С-Битрикс

Мы разрабатываем специализированные отчёты по остаткам товаров для 1С-Битрикс под ключ. В нашей практике частый запрос: «Покажи, что заканчивается на складе». Задача решается по-разному в зависимости от структуры учёта: один склад или несколько, синхронизация с 1С или автономный учёт, торговые предложения или простые товары. Стандартные средства Битрикс дают только базовые фильтры в административной части. Для операционной работы нужны специализированные отчёты. Наш опыт — 8+ лет, 50+ проектов — гарантирует, что вы получите работающее решение без сюрпризов. Экономия времени после внедрения — до 10 часов в неделю, а точность данных — 100%.

Какие проблемы решают отчёты по остаткам?

Менеджеры тратят часы на ручной сбор данных из разных разделов админки. Ошибки в Excel, устаревшие цифры, потерянные заказы из-за отсутствия товара — всё это решается автоматическими отчётами. Автоматизация исключает человеческий фактор: данные всегда актуальны на момент генерации, а пороги срабатывания настраиваются под категории товаров.

Как хранятся остатки в 1С-Битрикс?

Остатки в Битрикс хранятся в нескольких таблицах в зависимости от режима учёта:

• b_catalog_product — поле QUANTITY (суммарный остаток), QUANTITY_RESERVED (зарезервировано)
• b_catalog_store_product — остатки по складам (store_id, product_id, amount, quantity_reserved)

При работе с торговыми предложениями (SKU): базовый товар (b_iblock_element с типом товар) не имеет остатка — остатки задаются на уровне SKU (b_catalog_product.product_id = sku_element_id).

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

Отчёт «товары с критическим остатком»

SELECT
    ie.id,
    ie.name,
    prop_art.value    AS article,
    sect.name         AS section,
    cp.quantity       AS stock,
    cp.quantity_reserved AS reserved,
    cp.quantity - cp.quantity_reserved AS available
FROM b_catalog_product cp
JOIN b_iblock_element ie ON ie.id = cp.id
LEFT JOIN b_iblock_element_property prop_art
    ON prop_art.iblock_element_id = ie.id
    AND prop_art.iblock_property_id = :article_prop_id
LEFT JOIN b_iblock_section sect ON sect.id = ie.iblock_section_id
WHERE ie.iblock_id = :iblock_id
  AND ie.active = 'Y'
  AND (cp.quantity - cp.quantity_reserved) <= :min_stock_threshold
ORDER BY (cp.quantity - cp.quantity_reserved) ASC;

Остатки по складам с детализацией (для многоскладского учёта)

SELECT
    ie.name             AS product_name,
    prop_art.value      AS article,
    cs.title            AS store_name,
    cs.address          AS store_address,
    csp.amount          AS store_amount,
    csp.quantity_reserved AS store_reserved
FROM b_catalog_store_product csp
JOIN b_catalog_store cs ON cs.id = csp.store_id AND cs.active = 'Y'
JOIN b_iblock_element ie ON ie.id = csp.product_id
LEFT JOIN b_iblock_element_property prop_art
    ON prop_art.iblock_element_id = ie.id
    AND prop_art.iblock_property_id = :article_prop_id
WHERE ie.iblock_id = :iblock_id
  AND csp.amount > 0
ORDER BY ie.name, cs.sort;

Отчёт по SKU (торговым предложениям)

SKU — это модификации товара (размер, цвет). Для отчёта по остаткам SKU используйте этот запрос:

SELECT
    parent.name     AS product_name,
    sku.name        AS sku_name,
    prop_color.value AS color,
    prop_size.value  AS size,
    cp.quantity      AS stock
FROM b_iblock_element sku
JOIN b_iblock_element parent ON parent.id = sku.wf_parent_id -- для старого API
-- Или через b_catalog_product_offer для D7:
JOIN b_catalog_product_offer cpo ON cpo.id = sku.id
JOIN b_iblock_element parent ON parent.id = cpo.owner_id
JOIN b_catalog_product cp ON cp.id = sku.id
LEFT JOIN b_iblock_element_property prop_color
    ON prop_color.iblock_element_id = sku.id AND prop_color.iblock_property_id = :color_prop_id
LEFT JOIN b_iblock_element_property prop_size
    ON prop_size.iblock_element_id = sku.id AND prop_size.iblock_property_id = :size_prop_id
WHERE sku.iblock_id = :sku_iblock_id AND sku.active = 'Y'
ORDER BY parent.name, sku.name;

Кейс: автоматизация рассылки отчётов для магазина одежды

Магазин одежды: 3 000 SKU, 2 склада (Москва и Санкт-Петербург), синхронизация с 1С раз в час. Байер каждое утро проверял Excel с остатками — файл обновлялся вручную раз в день. Мы реализовали автоматический отчёт «критические остатки» с рассылкой по email в 8:00 утра.

Реализация:

1. SQL-запрос по таблицам b_catalog_store_product + b_iblock_element_property (цвет, размер)
2. Генерация XLSX через PhpSpreadsheet с условным форматированием: красный — остаток 0–1, жёлтый — 2–5
3. Агент Битрикс, запускаемый раз в сутки в 7:45, генерирует файл и сохраняет в /upload/reports/
4. Отправка письма через \Bitrix\Main\Mail\Event::send() с вложением байеру и директору

function GenerateLowStockReport(): string
{
    $generator = new StockReportGenerator();
    $file = $generator->generateLowStock(threshold: 5);

    $savedPath = '/upload/reports/low_stock_' . date('Y-m-d') . '.xlsx';
    copy($file, $_SERVER['DOCUMENT_ROOT'] . $savedPath);

    \Bitrix\Main\Mail\Event::send([
        'EVENT_NAME' => 'LOW_STOCK_REPORT',
        'LID'        => 's1',
        'C_FIELDS'   => [
            'REPORT_DATE' => date('d.m.Y'),
            'FILE_PATH'   => $savedPath,
        ],
    ]);

    unlink($file);
    return __FUNCTION__ . '();';
}

Результат: отчёт сократил время подготовки данных байером с 30 минут до 0 — файл ждёт в почте. В 10 раз быстрее ручного формирования — это реальная экономия.

Почему стоит выбрать автоматизацию?

Автоматический отчёт исключает человеческий фактор: не нужно помнить о загрузке, не нужно отправлять вручную, данные всегда актуальны на момент генерации. Плюс — возможность настроить разные пороги срабатывания для разных категорий товаров. Подробнее о структуре данных.

Типичные ошибки при разработке отчётов по остаткам

Неправильные JOIN в SQL: например, забывают учесть резервы (QUANTITY_RESERVED) или не учитывают многоскладской учёт. Игнорирование торговых предложений: отчёт показывает остатки только базовых товаров, а SKU остаются без внимания. Отсутствие проверки актуальности данных: если обмен с 1С задержался, отчёт покажет неверные цифры. Мы помогаем избежать этих ошибок на этапе анализа — получите консультацию, чтобы ваш отчёт работал без сбоев.

Что входит в разработку отчёта под ключ

• Анализ текущей структуры учёта (склады, SKU, 1С-обмен)
• Написание и оптимизация SQL-запросов
• Разработка модуля генерации XLSX с условным форматированием
• Настройка агента для автозапуска по расписанию
• Создание простого UI для ручного запуска и фильтрации
• Инструкция для администратора (где файлы, как добавить получателей)
• Тестирование на ваших данных

Закажите разработку — мы покажем, как ваш бизнес сэкономит время и деньги.

Сравнение способов получения данных об остатках

Сроки и стоимость

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

Почему аналитика 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 и выбору подходящего инструмента сквозной аналитики для вашего Битрикс-проекта.