Налаштування масового переміщення товарів між розділами 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С-Бітрікс: Структура таблиць інфоблоків