Настройка массовой привязки торговых предложений 1С-Битрикс

Тысячи торговых предложений висят без привязки к товару — после массового импорта из 1С или миграции с другой платформы. В результате в карточке товара пусто, цены и остатки не передаются, корзина не работает. Восстановить привязку вручную для 10 000 SKU — неделя рутины. Мы решаем эту задачу с помощью скриптов массовой привязки по XML_ID, артикулу или внешней таблице. Экономия до 70% времени по сравнению с ручным трудом. Опыт более 10 лет и 500+ успешных проектов позволяют гарантировать корректную работу каталога. Получите консультацию — проведём бесплатный анализ базы данных и предложим оптимальное решение.

Почему важно правильно привязывать торговые предложения?

Без корректной привязки через свойство CML2_LINK Битрикс не может собрать единый торговый каталог. Предложения не отображаются в карточке товара, цены и остатки не передаются в корзину, а фильтр по фасетам выдаёт пустые результаты. Особенно критично для интернет-магазинов с большим ассортиментом — ошибка привязки ведёт к потере конверсии и росту возвратов. Стоимость такой ошибки может достигать десятков тысяч рублей потерянной выручки за день.

Как массово восстановить привязку торговых предложений?

Шаг 1. Анализ структуры данных

Определяем инфоблоки товаров (catalogIblockId) и предложений (offersIblockId). Проверяем свойство CML2_LINK в b_iblock_property.

SELECT COUNT(*)
FROM b_iblock_element ie
WHERE ie.IBLOCK_ID = {offers_iblock_id}
AND NOT EXISTS (
    SELECT 1 FROM b_iblock_element_property iep
    INNER JOIN b_iblock_property ip ON ip.ID = iep.IBLOCK_PROPERTY_ID
    WHERE iep.IBLOCK_ELEMENT_ID = ie.ID
    AND ip.CODE = 'CML2_LINK'
    AND iep.VALUE IS NOT NULL
);

Шаг 2. Массовая привязка по XML_ID

Самый распространённый сценарий — товары и предложения имеют артикул из 1С в поле XML_ID. Мы создаём карту соответствия и устанавливаем CML2_LINK пакетами по 200 записей. Это в 20 раз быстрее ручной привязки.

$offersIblockId = 11;

$propRes = \Bitrix\Iblock\PropertyTable::getList([
    'filter' => ['IBLOCK_ID' => $offersIblockId, 'CODE' => 'CML2_LINK'],
    'select' => ['ID'],
])->fetch();

$linkPropertyId = $propRes['ID'];

$catalogIblockId = 10;
$productMap = [];
$productsRes = \CIBlockElement::GetList([], ['IBLOCK_ID' => $catalogIblockId], false, false, ['ID', 'XML_ID']);
while ($row = $productsRes->Fetch()) {
    $productMap[$row['XML_ID']] = $row['ID'];
}

$offersRes = \CIBlockElement::GetList([], ['IBLOCK_ID' => $offersIblockId], false, false, ['ID', 'XML_ID']);

$batch = [];
while ($row = $offersRes->Fetch()) {
    $parentXmlId = substr($row['XML_ID'], 0, 8);
    if (!isset($productMap[$parentXmlId])) continue;
    $parentId = $productMap[$parentXmlId];
    $batch[]  = ['offer_id' => $row['ID'], 'parent_id' => $parentId];
    if (count($batch) >= 200) {
        bindOffersToProducts($batch, $offersIblockId, $linkPropertyId);
        $batch = [];
    }
}
if (!empty($batch)) {
    bindOffersToProducts($batch, $offersIblockId, $linkPropertyId);
}

function bindOffersToProducts(array $batch, int $iblockId, int $propId): void
{
    foreach ($batch as $item) {
        $existing = \Bitrix\Iblock\ElementPropertyTable::getList([
            'filter' => ['IBLOCK_ELEMENT_ID' => $item['offer_id'], 'IBLOCK_PROPERTY_ID' => $propId],
            'select' => ['ID'],
        ])->fetch();
        if ($existing) {
            \Bitrix\Iblock\ElementPropertyTable::update($existing['ID'], ['VALUE' => $item['parent_id']]);
        } else {
            \Bitrix\Iblock\ElementPropertyTable::add([
                'IBLOCK_ELEMENT_ID' => $item['offer_id'],
                'IBLOCK_PROPERTY_ID' => $propId,
                'VALUE' => $item['parent_id']
            ]);
        }
    }
}

Шаг 3. Привязка через CSV-маппинг

Если логика определения родителя сложнее (например, по цвету и размеру), используем внешнюю таблицу. Пример файла:

offer_xml_id,parent_xml_id
SKU-001-RED,PROD-001
SKU-001-BLUE,PROD-001

Скрипт загружает маппинг, находит ID элементов по XML_ID и устанавливает CML2_LINK. Производительность — до 10 000 привязок в минуту.

Как проверить корректность привязки?

После выполнения привязки обязательно:

1. Выборочно проверьте карточки товаров на публичной части — предложения должны отображаться.
2. Сбросьте тегированный кэш инфоблоков.
3. Переиндексируйте фасетный фильтр, если предложения участвуют в фильтрации.

\Bitrix\Iblock\InformationBlock::cleanTagCache($catalogIblockId);
\Bitrix\Iblock\InformationBlock::cleanTagCache($offersIblockId);
\Bitrix\Iblock\PropertyIndex\Manager::markIblockToReindex($offersIblockId);

Сравнение ручной и автоматической привязки

Что входит в услугу

• Документация по текущей структуре привязки.
• Тестовый скрипт на копии базы (staging).
• Запуск массовой привязки на боевой базе.
• Отчёт о результатах: сколько предложений привязано, сколько пропущено.
• Консультация по дальнейшей интеграции с CommerceML для предотвращения повторных сбоев.

Типичные ошибки при привязке

• Отсутствие уникального ключа — когда XML_ID дублируются или пусты.
• Разные шаблоны генерации артикулов — приходится писать кастомные парсеры.
• Игнорирование кэширования — после привязки обязательно сбрасывать кэш инфоблоков.
• Неполная переиндексация — фасетный фильтр показывает старые данные.

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

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

Почему выбирают нашу команду

Наш опыт в восстановлении больших каталогов исчисляется сотнями успешных проектов. Мы работаем с магазинами, где количество торговых предложений превышает 100 000 единиц. Каждый проект индивидуален, и мы учитываем специфику хранения данных в вашей базе. Использование пакетной обработки и оптимизированных SQL-запросов позволяет нам работать с нагруженными базами данных без риска блокировок. После завершения работы предоставляем подробный отчёт о результатах и рекомендации по профилактике подобных проблем в будущем. Наши специалисты прошли официальное обучение по архитектуре 1С-Битрикс и имеют сертификаты разработчиков, что гарантирует высокое качество выполнения работы во всех случаях.

Наш подход к решению

Каждая задача требует индивидуального анализа и тщательного планирования. Мы не используем шаблонные решения — каждый проект адаптируется под конкретные требования и существующую инфраструктуру. Наша команда имеет опыт работы с проектами разного масштаба: от небольших магазинов до высоконагруженных платформ с миллионами операций в день.

Гарантии и поддержка

Мы даём гарантию на выполненную работу сроком на 12 месяцев. В течение этого периода исправляем любые возникающие проблемы бесплатно. После завершения проекта предоставляем полную документацию и обучение для вашей команды. Техническая поддержка доступна в течение 30 дней после запуска — мы поможем устранить любые вопросы.

Разработка каталога 1С-Битрикс: как превратить фильтр за 4 секунды в мгновенный отклик

В интернет-магазине 80 000 товаров, умный фильтр на Битрикс тормозит — каждый клик по свойству превращается в 4-секундное ожидание. Покупатель тыкает чекбокс «бренд Apple», смотрит на вертящийся лоадер и уходит к конкурентам. Конверсия падает на 20%. Это знакомая боль. Мы занимаемся разработкой каталога 1С-Битрикс и фильтрации: проектируем архитектуру, которая держит полмиллиона позиций без деградации — за счёт фасетных индексов, правильного выбора хранилищ и тегированного кэширования. Если ваш магазин теряет деньги на медленном фильтре — закажите аудит текущей архитектуры, мы оценим проблему за один день.

Как инфоблоки влияют на производительность каталога?

Инфоблоки — основа каталога, но на проектах с десятками тысяч товаров они становятся узким местом. Стандартный bitrix:catalog.smart.filter генерирует JOIN на 6–8 таблиц свойств (b_iblock_element_property), и MySQL уходит в full scan. Меняем подход: на этапе проектирования определяем, какие свойства пойдут в инфоблок, а какие — в Highload-блоки. Для справочных данных (бренды, города, размерные сетки) используем HLB: они работают с отдельной таблицей без overhead b_iblock_element_property. Когда выпадающий список «Города» грузится 8 секунд из-за 5000 значений — это сигнал переносить их на HLB. Каталог на 80 000 товаров с фильтром за 4 секунды теряет около 1,2 млн рублей в год из-за ухода клиентов — такую экономию даёт правильная архитектура. Свяжитесь с нами, чтобы прикинуть выгоду для вашего проекта.

Что такое фасетный индекс и почему он важен?

Основная производительность кроется здесь. Без фасетного индекса каждый клик по фильтру — SQL-запрос с JOIN по b_iblock_element, b_iblock_element_property, b_catalog_price и ещё паре таблиц. На 100 000 товаров такой запрос выполняется 2–4 секунды. С фасетным индексом — 30–80 мс. Согласно официальной документации, фасетный индекс сокращает время выполнения запроса в десятки раз (в реальных проектах — до 50 раз). Механизм: 1С-Битрикс создаёт таблицу b_catalog_smart_filter, куда складывает предрассчитанные комбинации «раздел + свойство + значение + количество товаров». При фильтрации движок обращается к этой плоской таблице вместо сбора данных из нормализованной структуры инфоблоков.

При настройке фасетного индекса часто допускают одни и те же промахи. Индекс создают не для всех разделов, забывают настроить фоновую переиндексацию после массового импорта — тогда счётчики свойств перестают соответствовать реальному количеству товаров. Включают в фасет все свойства подряд, даже служебные, что раздувает таблицу b_catalog_smart_filter. На каталогах свыше 300 тысяч позиций её размер может превышать гигабайт — без мониторинга через SHOW TABLE STATUS LIKE 'b_catalog_smart_filter' не обойтись. Вывод: фасетный индекс даёт радикальное ускорение, но требует вдумчивой настройки и автоматической переиндексации через агент CIBlockCatalog::ReindexFacet или cron.

Почему Highload-блоки быстрее инфоблоков для справочников?

На практике лучшая архитектура — гибридная. Товары и разделы живут в инфоблоках — там SEO, визуальный редактор, штатные компоненты каталога. А справочные свойства с тысячами значений переносим в Highload-блоки. Пользовательские данные (избранное, просмотренные, сравнение) — тоже в HLB, они быстро растут, и инфоблоки под это не заточены. Хотите узнать, какую архитектуру выбрать для вашего каталога? Свяжитесь с нами — проанализируем структуру данных и дадим рекомендации.

SEO-фильтры: как получить ЧПУ и не попасть под фильтр Яндекса?

Стандартный фильтр генерирует ?filter[brand]=apple&filter[color]=black — поисковики такие URL либо не индексируют, либо считают дублями. А запрос «ноутбуки apple чёрные» — самый конверсионный низкочастотный трафик. Делаем ЧПУ: /catalog/noutbuki/brand-apple/color-black/ с уникальными title, description и H1. Не шаблонными «Купить {бренд} в Минске», а осмысленными — с учётом конкретной комбинации.

• Канонические URL — чтобы /brand-apple/color-black/ и /color-black/brand-apple/ не дублировались.
• Контроль количества индексируемых комбинаций — 10 свойств по 20 значений дают миллионы страниц, Яндекс за такое бьёт фильтром.
• Автоматическая sitemap для SEO-страниц фильтрации.
• Административный интерфейс для менеджера — он сам решает, какие пересечения индексировать.

Закажите внедрение SEO-фильтров — получите готовый инструмент для привлечения низкочастотного трафика с ростом конверсии до 30%.

Какие методы дают ощутимый прирост производительности?

• Выборка только нужных полей через arSelect — никаких SELECT * по инфоблокам.
• Управляемый кэш с тегами: добавили товар — кэш пересоздался автоматически.
• Композитный кэш для анонимов: TTFB < 100 мс, HTML отдаётся без запуска PHP.
• Индексы на свойствах, участвующих в фильтрации — без них MySQL сканирует b_iblock_element_property целиком.
• Мониторинг TTFB: если каталог отвечает дольше 500 мс — лезем в slow query log.

Что входит в комплексную разработку каталога на 1С-Битрикс

Мы передаём не просто работающий код, а полный комплект документации и инструментов для самостоятельного управления. В deliverables входят:

• Аудит текущей архитектуры каталога и фильтрации.
• Проектная документация с описанием схемы данных, распределения по инфоблокам и Highload-блокам, фасетного состава.
• Готовый умный фильтр с ajax-режимом, группировкой и сохранением состояния.
• Настроенный фасетный индекс с cron-переиндексацией.
• SEO-фильтры с ЧПУ, уникальными метатегами, каноникалами и sitemap.
• Интеграция быстрого просмотра и сортировок (AJAX, мобильная адаптация).
• Документация по эксплуатации для менеджеров: как добавлять свойства, управлять индексами и SEO-комбинациями.
• Гарантийная поддержка 30 дней после сдачи — исправляем инциденты и отвечаем на вопросы.

Как мы разрабатываем каталог: пошаговый план

Мы не просто ставим компоненты. Процесс включает:

1. Аудит текущего каталога — разбор структуры свойств, выявление узких мест, проверка индексов и кэша.
2. Проектирование архитектуры — распределение данных между инфоблоками и HLB, определение фасетного состава.
3. Разработка умного фильтра — кастомизация шаблона, ajax-режим, группировка, сохранение состояния.
4. Настройка фасетного индекса — создание, cron-переиндексация, мониторинг.
5. SEO-фильтры — ЧПУ, метатеги, каноникалы, sitemap.
6. Интеграция быстрого просмотра и сортировок — AJAX-модалка с фото, ценой, наличием, предзагрузка при наведении. На мобильных — bottom sheet вместо попапа.
7. Обучение менеджеров — как управлять свойствами, индексами и SEO-комбинациями.
8. Гарантийная поддержка — 30 дней после сдачи.

Сроки реализации

Каталог окупается через рост конверсии и приток SEO-трафика по низкочастотке. Покупатель находит товар за два клика, а не уходит после первого тычка в фильтр. Получите консультацию — оценим ваш проект в течение дня и предоставим расчёт стоимости с roadmap работ по разработке каталога 1С-Битрикс. Свяжитесь с нами через форму на сайте — сертифицированные специалисты и более 200 успешных проектов за плечами.