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

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