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

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

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

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

• 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 — запросы на больших объёмах тормозят.
• Игнорирование дублей кодов — при повторном выводе возможны расхождения.

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