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

Реструктуризация каталога: как не утонуть в рутине

Представьте: раздел «Смартфоны» разбивается на подразделы по брендам — 800 товаров нужно распределить за пару часов, иначе простой сайта. Или поставщик сменил категорирование, и 400 позиций повисли в неверных разделах, поиск выдаёт путаницу, а менеджеры тратят часы на ручное обновление. Если делать это руками через административную панель, на 800 товаров уйдёт около двух недель непрерывной работы — только клики, без учёта ошибок. Единственный выход — автоматизированное массовое перемещение. Например, в одном проекте мы перенесли 1200 товаров из раздела «Ноутбуки» в «Ультрабуки» за 3 минуты с помощью прямого SQL — без ошибок и простоев. Клиент сэкономил более 40 часов ручной работы.

Наша методика проверена на 150+ каталогах с объёмом от 300 до 50 000 товаров. За годы работы с 1С-Битрикс мы выстроили эффективные методы, которые учитывают внутреннее устройство инфоблоков, кэширование и права доступа. Ниже — технический разбор от структуры таблиц до оптимизации производительности, а в конце — готовое решение под ваш проект.

Структура разделов и привязка товаров

Разделы инфоблока хранятся в b_iblock_section. Привязка элемента к разделу — поле IBLOCK_SECTION_ID в b_iblock_element (основной раздел). Дополнительная привязка к нескольким разделам — таблица b_iblock_section_element: IBLOCK_ELEMENT_ID, IBLOCK_SECTION_ID, ADDITIONAL_PROPERTY_ID.

При перемещении товара нужно обновить оба места:

1. IBLOCK_SECTION_ID в b_iblock_element — основной раздел.
2. Запись в b_iblock_section_element — для корректной работы фильтров.

Перемещение через CIBlockElement::Update

Стандартный метод обновления с изменением раздела:

\CIBlockElement::Update($elementId, false, [ 'IBLOCK_SECTION_ID' => $newSectionId, ]); 

После Update() Битрикс автоматически обновляет b_iblock_section_element. Но метод медленный при массовом применении — каждый вызов проходит через события, кэш, права доступа.

Почему прямое SQL-обновление выгоднее?

При работе с каталогами от 500 элементов разница становится критической. CIBlockElement::Update загружает модули Битрикса, проверяет права, вызывает события. В фоновом режиме это приводит к зависаниям. Прямой SQL обходит эти слои, но требует тщательного контроля целостности данных. Мы используем его в связке с транзакциями и бекапом.

Прямое SQL-обновление для скорости:

global $DB; $elementIds = implode(',', array_map('intval', $productIds)); $newSection = (int)$newSectionId; $DB->Query(" UPDATE b_iblock_element SET IBLOCK_SECTION_ID = {$newSection} WHERE ID IN ({$elementIds}) "); $DB->Query(" DELETE FROM b_iblock_section_element WHERE IBLOCK_ELEMENT_ID IN ({$elementIds}) AND ADDITIONAL_PROPERTY_ID IS NULL "); foreach ($productIds as $id) { $DB->Query(" INSERT INTO b_iblock_section_element (IBLOCK_ELEMENT_ID, IBLOCK_SECTION_ID) VALUES ({$id}, {$newSection}) "); } 

Прямой SQL работает в 50-100 раз быстрее CIBlockElement::Update() для массовых операций, но требует ручного сброса кэша.

Сравнение способов перемещения

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

Как сбросить кэш после перемещения?

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

\Bitrix\Main\Application::getInstance()->getTaggedCache()->clearByTag('iblock_id_' . $iblockId); // Для конкретных разделов foreach (array_unique(array_merge($oldSectionIds, [$newSectionId])) as $secId) { \Bitrix\Main\Application::getInstance()->getTaggedCache() ->clearByTag('iblock_section_' . $secId); } 

Как автоматически распределить товары по разделам?

Для автоматического распределения товаров по разделам на основе свойств — например, по бренду:

$brandSectionMap = [ 'Apple' => 125, 'Samsung' => 126, 'Xiaomi' => 127, ]; $res = \CIBlockElement::GetList( [], ['IBLOCK_ID' => $iblockId, 'IBLOCK_SECTION_ID' => $sourceSection], false, false, ['ID', 'PROPERTY_BRAND'] ); while ($item = $res->GetNext()) { $brand = $item['PROPERTY_BRAND_VALUE']; $targetId = $brandSectionMap[$brand] ?? null; if ($targetId) { \CIBlockElement::Update($item['ID'], false, ['IBLOCK_SECTION_ID' => $targetId]); } } 

При больших объёмах этот скрипт запускается через агент Битрикса пакетами по 100-200 элементов с сохранением прогресса в b_option.

Как мы автоматизируем процесс: пошагово

1. Анализ структуры — изучаем текущие разделы, свойства, права доступа.
2. Разработка скрипта — пишем SQL или API-скрипт с учётом ваших условий.
3. Тестирование на копии — запускаем на staging-копии, проверяем целостность.
4. Запуск в продакшн — выполняем миграцию в часы минимальной нагрузки.
5. Сброс кэша — очищаем тегированные кэши и проверяем фронт.
6. Документация — передаём описание процедуры на случай повторения.

Что входит в нашу работу

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

Наш опыт и гарантии

Более 7 лет опыта разработки на Битрикс, 150+ успешных проектов по миграции и оптимизации каталогов. Сертифицированные специалисты. Экономия средств на администрирование каталога достигает 80% при автоматизации. Мы уверены в качестве, поэтому даём гарантию на работу скрипта.

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

Официальная документация 1С-Битрикс: Структура таблиц инфоблоков