Налаштування масової зміни властивостей товарів в 1С-Бітрікс
У каталозі 15 000 товарів потрібно проставити нову властивість «Матеріал» у 8 000 позицій певної категорії, виправити друкарську помилку в значенні фасетного фільтра у 2 000 товарів, зняти прапорець «Рекомендований» у половини асортименту. Через картку товару це тижні роботи. Ми вирішуємо такі завдання пакетним оновленням через API з контролем цілісності даних. У нас за плечима більше 10 років досвіду в розробці на Бітрікс — ми знаємо, як оновити властивості тисяч товарів за години, а не дні. На каталозі з 15 000 товарів ручне оновлення зайняло б 3–4 тижні, автоматизація скорочує до 1–2 днів. Економія часу — близько 90%, а вартість розраховується індивідуально — від 100$.
Де зберігаються властивості
Властивості товарів у Бітрікс зберігаються в кількох місцях залежно від типу:
- Поля елемента (
NAME,PREVIEW_TEXT,ACTIVEта ін.) —b_iblock_element - Властивості інфоблоку —
b_iblock_element_property, деIBLOCK_PROPERTY_ID— ID властивості,VALUE— значення - Множинні властивості — кілька рядків у
b_iblock_element_propertyз однимIBLOCK_ELEMENT_IDі однимIBLOCK_PROPERTY_ID - Властивості типу «Список» —
VALUEмістить текстове значення,VALUE_ENUM_ID— посилання наb_iblock_property_enum
Для торговельних пропозицій — аналогічна структура, але IBLOCK_ID вказує на інфоблок пропозицій, а не основний каталог. Розуміння цієї структури необхідне для вибору оптимального методу оновлення.
Як масово оновити властивості товарів без просідання продуктивності?
Для невеликих обсягів (до 1 000 елементів) підходить CIBlockElement::SetPropertyValues. Код робочий:
$iblockId = 10; // ID інфоблоку каталогу $propertyCode = 'MATERIAL'; $newValue = 'Хлопок 100%'; // Отримуємо список елементів потрібної секції $res = \CIBlockElement::GetList( [], ['IBLOCK_ID' => $iblockId, 'SECTION_ID' => 42, 'ACTIVE' => 'Y'], false, false, ['ID'] ); while ($row = $res->Fetch()) { \CIBlockElement::SetPropertyValues( $row['ID'], $iblockId, $newValue, $propertyCode ); } Однак на великих обсягах цей метод повільний — він читає поточні значення, порівнює, оновлює. Кожен виклик — кілька SQL-запитів. Для обсягів від 1 000 елементів настійно рекомендуємо пряме оновлення через D7 ORM.
Швидке оновлення через D7 ORM
Для обсягів від 1 000 елементів використовуйте пряме оновлення b_iblock_element_property:
use Bitrix\Iblock\ElementPropertyTable; // Спочатку отримуємо ID властивості $propertyId = getPropertyIdByCode($iblockId, 'MATERIAL'); // Отримуємо ID елементів пакетами $elementIds = getElementIdsBySectionBatch($iblockId, $sectionId, 500); foreach (array_chunk($elementIds, 500) as $chunk) { // Перевіряємо, у кого вже є запис $existing = ElementPropertyTable::getList([ 'filter' => [ 'IBLOCK_PROPERTY_ID' => $propertyId, 'IBLOCK_ELEMENT_ID' => $chunk, ], 'select' => ['ID', 'IBLOCK_ELEMENT_ID'], ])->fetchAll(); $existingMap = array_column($existing, 'ID', 'IBLOCK_ELEMENT_ID'); foreach ($chunk as $elementId) { if (isset($existingMap[$elementId])) { // Оновлюємо існуючий запис ElementPropertyTable::update($existingMap[$elementId], ['VALUE' => 'Хлопок 100%']); } else { // Вставляємо новий ElementPropertyTable::add([ 'IBLOCK_ELEMENT_ID' => $elementId, 'IBLOCK_PROPERTY_ID' => $propertyId, 'VALUE' => 'Хлопок 100%', ]); } } } Після прямої зміни таблиці потрібно скинути кеш інфоблоку:
\Bitrix\Iblock\InformationBlock::cleanTagCache($iblockId); \Bitrix\Main\Application::getInstance()->getTaggedCache()->clearByTag('iblock_id_' . $iblockId); Чому після масового оновлення властивостей не працює фасетний фільтр?
Після зміни властивостей, які використовуються в розумному фільтрі (catalog.smart.filter), необхідно перебудувати фасетний індекс. Інакше значення не оновляться у фільтрі. Ми завжди включаємо переіндексацію в процес робіт.
\Bitrix\Iblock\PropertyIndex\Manager::markIblockToReindex($iblockId); // або примусово: $indexer = new \Bitrix\Iblock\PropertyIndex\Indexer($iblockId); $indexer->startIndex(); $indexer->continueIndex(0); $indexer->endIndex(); На каталозі 50 000+ товарів переіндексація займає кілька хвилин — запускайте у фоні через агент або cron. Згідно з документацією 1С-Бітрікс, рекомендується запускати переіндексацію у фонових процесах, щоб не блокувати користувачів.
Деталі переіндексації
Фасетний індекс будується на основі таблиць `b_iblock_element_property` і `b_iblock_property_enum`. Якщо ви оновлюєте властивості безпосередньо через SQL, індекс може не відповідати актуальним даним. Перебудова індексу через `PropertyIndex\Manager` гарантує синхронізацію. Для великих каталогів (від 100 000 товарів) використовуйте поетапну індексацію через агент з кроком по 1000 елементів.Особливості оновлення спискових властивостей
Властивості типу «Список» (використовуються у фасетному фільтрі) зберігають у VALUE текстове значення, а в VALUE_ENUM_ID — ID з b_iblock_property_enum. При зміні значення потрібно оновлювати обидва поля.
// Знаходимо ID нового значення в переліку $enumRes = \CIBlockPropertyEnum::GetList( [], ['PROPERTY_ID' => $propertyId, 'VALUE' => 'Синій'] ); $enum = $enumRes->Fetch(); $enumId = $enum['ID']; // Оновлюємо ElementPropertyTable::update($existingPropId, [ 'VALUE' => 'Синій', 'VALUE_ENUM_ID' => $enumId, ]); Якщо потрібного значення ще немає в переліку — спочатку додайте його через CIBlockProperty::SetEnumValues() або безпосередньо в b_iblock_property_enum.
Імпорт CSV як альтернатива
Для нетехнічних користувачів або регулярних оновлень краще підходить імпорт CSV через Каталог → Імпорт. Шаблон файлу: перший рядок — заголовки з кодами полів (ID, PROPERTY_MATERIAL, PROPERTY_COLOR). Бітрікс оновлює тільки ті властивості, колонки яких присутні у файлі.
Обмеження стандартного імпорту: немає підтримки умов («оновити властивість тільки якщо поточне значення пусте»). Для таких сценаріїв — тільки скрипти.
Покроковий план та порівняння методів
- Аналіз структури: з'ясувати, які властивості та скільки елементів потрібно оновити.
- Вибір методу: для <500 товарів —
SetPropertyValues, для більших — D7 ORM. - Розробка скрипта з контролем помилок та логуванням.
- Тестування на копії бази або невеликій вибірці (10-20 елементів).
- Запуск оновлення, скидання кешу та переіндексація фасетів.
- Валідація результатів.
Порівняння методів:
| Метод | Швидкість | Складність | Підтримка умов |
|---|---|---|---|
| SetPropertyValues | Повільно (до 1000 ел.) | Низька | Ні |
| D7 ORM | Швидко (від 1000 ел.) | Середня | Так (у коді) |
| CSV-імпорт | Середньо | Низька | Тільки по ID |
Що входить у налаштування масової зміни властивостей
У рамках роботи ми:
- Аналізуємо поточну структуру властивостей та дані
- Вибираємо метод (API, D7 ORM, CSV)
- Пишемо скрипти з контролем помилок
- Тестуємо на вибірці
- Запускаємо повне оновлення та перебудовуємо кеш і фасетний індекс
- Надаємо документацію
Гарантуємо збереження даних та мінімізацію простою.
Терміни та вартість
| Обсяг | Метод | Час | Вартість |
|---|---|---|---|
| До 500 товарів | Admin UI / SetPropertyValues | 1–3 години | від 100$ |
| 500–5 000 товарів | D7 пакетне оновлення | 3–6 годин | від 300$ |
| 5 000–50 000 товарів | D7 + черга + переіндексація | 1–2 дні | від 800$ |
Як замовити налаштування
Якщо вам потрібно масово оновити властивості товарів, зв'яжіться з нами. Ми оцінимо обсяг робіт і запропонуємо рішення під ключ. Отримайте консультацію — просто напишіть. Ваш каталог буде приведений до ладу без болю та простоїв.







