Перейти к содержимому
BXWiki

Сверка каталога после обмена - числа, расхождения, отчёт

Проверяем каталог после сеанса обмена: считаем не общее число товаров, а те разрезы, в которых обычно и прячется потеря.

Решение

Снимаем ключевые числа по разрезам:

$iblock = 5;
printf("всего=%d активных=%d без раздела=%d\n",
    CIBlockElement::GetList([], ['IBLOCK_ID' => $iblock], []),
    CIBlockElement::GetList([], ['IBLOCK_ID' => $iblock, 'ACTIVE' => 'Y'], []),
    CIBlockElement::GetList([], ['IBLOCK_ID' => $iblock, 'SECTION_ID' => false], []));
// общее число почти всегда в порядке: расхождение прячется в разрезах

Общее число товаров - самый бесполезный показатель из всех. Каталог с тысячей позиций, из которых треть неактивна и не привязана к разделам, по общему счёту выглядит здоровым.

Ищем позиции без цены и без картинки:

SELECT COUNT(*) FROM b_iblock_element e
LEFT JOIN b_catalog_price p ON p.PRODUCT_ID = e.ID AND p.CATALOG_GROUP_ID = 1
WHERE e.IBLOCK_ID = 5 AND e.ACTIVE = 'Y' AND p.ID IS NULL;
-- то же самое для DETAIL_PICTURE: активные товары без изображения

Товар без цены не купить, а товар без картинки не выбрать. Эти два разреза отвечают на вопрос «что сломалось» точнее, чем журнал обмена, потому что показывают итог, а не ход сеанса.

Сравниваем с тем, что приехало в файле:

Окно терминала
grep -c '<Товар>' /home/bitrix/www/upload/1c_catalog/import*.xml
grep -c '<Предложение>' /home/bitrix/www/upload/1c_catalog/offers*.xml
# число позиций в файле и есть ожидаемый результат сеанса

Файл обмена задаёт ожидание, а база показывает случившийся факт. Разница между ними - это и есть объём потери, и её видно сразу, без разбора сообщений об ошибках.

Ставим сверку в расписание и шлём отчёт:

if ($withoutPrice > 0 || $withoutPicture > 50) {
    CEvent::Send('CATALOG_SYNC_REPORT', SITE_ID, [
        'NO_PRICE' => $withoutPrice, 'NO_PICTURE' => $withoutPicture,
    ]);
}
// письмо приходит, только когда есть о чём сообщать

Отчёт присылают только при найденном расхождении. Ежедневное письмо «всё хорошо» перестают читать через неделю, а письмо, приходящее раз в месяц, читают с первой строки.

Сверять сразу после сеанса не стоит: часть работы платформа доделывает отложенно. Разумный порядок - сверка через полчаса после окончания обмена, а не в ту же минуту.

Сверку удобно держать тем же скриптом, что и выгрузку прайса. Оба задания читают одни и те же разрезы каталога, и общий код избавляет от двух расходящихся представлений о том, что считать нормой.

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

Типичные проблемы

Числа сходятся, а покупатели жалуются.

Сверка идёт по общему числу товаров без всяких разрезов. Потеря прячется в неактивных позициях и в товарах без цены.

Отчёт приходит с ложной тревогой.

Сверка запущена сразу после сеанса, до конца отложенных работ. Проверку сдвигают на полчаса после окончания обмена.

Товары есть, а купить нельзя.

У части позиций нет цены нужного типа. Разрез по цене показывает это сразу, а журнал обмена - нет.

Отчёты перестали читать.

Письмо приходит каждый день независимо от результата сверки. Сообщать стоит только о найденных расхождениях.

Сверка не видит проблем с вариантами.

Считаются только сами товары, а предложения нет. У каталога с вариантами их считают отдельным разрезом.

Частые вопросы

Какие разрезы считать обязательными?

Активные без цены, активные без картинки, без раздела и число предложений. Этих четырёх хватает для ежедневной сверки.

Как понять, сколько позиций ожидать?

По числу элементов в файле обмена. Оно же показывает, был ли сеанс полным или частичным.

Кому слать отчёт?

Тому, кто может исправить: контент-менеджеру и ответственному за учётную систему. Разработчику - только при технических ошибках.

Нужно ли хранить историю сверок?

Да, хотя бы числа по дням. Тогда видно, когда именно началось расхождение, а не только что оно есть.

Смежное

Первоисточник