Масове прив’язування торгових пропозицій 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. Правильна архітектура дає суттєву економію. Зв'яжіться з нами, щоб прикинути вигоду для вашого проєкту.

Що таке фасетний індекс і чому він важливий?

Основна продуктивність криється тут. Без фасетного індексу кожен клік по фільтру — 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 успішних проєктів за плечима.