Проектування торгових пропозицій (SKU) 1С-Бітрікс

Проектування торгових пропозицій (SKU) 1С-Бітрікс

Торгові пропозиції в Бітрікс — це механізм, що дозволяє одному товару мати кілька варіантів з різними цінами, залишками та характеристиками. Звучить просто, але реалізація цього механізму викликає більше питань на практиці, ніж будь-яка інша частина каталогу. Як розмежувати властивості товару та властивості пропозиції? Як коректно налаштувати фільтрацію за атрибутами SKU? Чому після налаштування обміну з 1С пропозиції дублюються замість оновлення? Відповіді на ці питання — в архітектурних рішеннях, прийнятих при проектуванні.

Технічна схема SKU у Бітрікс

Торгова пропозиція у Бітрікс — це елемент окремого інфоблоку, прив'язаний до батьківського товару з основного інфоблоку каталогу. У базі даних:

• b_iblock_element — товар в основному інфоблоці (батько, тип TYPE_PRODUCT)
• b_iblock_element — пропозиція в інфоблоці офферів (тип TYPE_OFFER)
• b_catalog_product.OWNER_ID — зв'язок пропозиції з батьківським товаром
• b_catalog_price — ціна на рівні пропозиції
• b_catalog_store_amount — залишки на складах на рівні пропозиції

Налаштування зв'язку: Контент → Каталог → [інфоблок] → Налаштування → Торгові пропозиції. Тут вказується інфоблок офферів і властивість-зв'язка (CML2_LINK або кастомна властивість типу «Прив'язка до елементів інфоблоку»).

Розмежування властивостей: товар vs. пропозиція

Найбільш критична проектна задача. Правило: властивість належить пропозиції, якщо її значення впливає на ціну або залишок, або якщо вона унікальна для конкретного варіанту.

Приклади:

• Властивості товару: назва, опис, бренд, категорія, зображення, технічні характеристики (не варіативні)
• Властивості пропозиції: колір, розмір, об'єм, комплектація, артикул (SKU-код), штрихкод, зображення варіанту

Помилка — помістити колір і розмір у властивості батьківського товару: тоді неможливо відфільтрувати «сині сукні розміру M», тому що ці атрибути не пов'язані із залишками та ціною конкретного варіанту.

Компонент bitrix:catalog.element і відображення SKU

Стандартний компонент картки товару bitrix:catalog.element підтримує відображення торгових пропозицій: перемикання варіантів, динамічне оновлення ціни та зображення через AJAX-запит до методу CatalogElementComponent.getProductData. При проектуванні важливо розуміти, що цей компонент робить окремий запит за даними пропозицій — отже, вони мають бути правильно структуровані та кешовані.

Якщо пропозицій у товару багато (50+), стандартний компонент може генерувати важкі запити. Рішення: ліниве завантаження варіантів через REST або примусове обмеження кількості відображуваних пропозицій з «показати більше».

Фільтрація за властивостями пропозицій

Стандартний компонент bitrix:catalog.smart.filter вміє фільтрувати за властивостями інфоблоку офферів — для цього в налаштуваннях компонента потрібно вказати OFFER_IBLOCK_ID. Але фасетний індекс будується окремо для інфоблоку офферів і для основного інфоблоку. Щоб фільтр за кольором показував лише товари, у яких є варіант потрібного кольору — фасет має бути увімкнений саме на інфоблоці офферів.

Складний випадок: фільтр за властивістю товару І за властивістю пропозиції одночасно. Стандартний фасет не підтримує cross-iblock фільтрацію «з коробки» — потрібна кастомна доробка компонента фільтра.

Обмін з 1С та торгові пропозиції

У CommerceML 2 торгові пропозиції передаються в секції ЗначенняРеквізитів з атрибутом характеристики. Стандартний обмін Бітрікс вміє створювати та оновлювати пропозиції з вивантаження 1С. Критичні точки:

• XML-ID пропозиції має бути унікальним і стабільним між обмінами
• Якщо 1С змінює ідентифікатори характеристик — пропозиції дублюються замість оновлення
• Зображення пропозицій передаються окремо від зображень товару

При проектуванні потрібно погодити з командою 1С формат XML-ID пропозицій до початку розробки.

Кейс: меблевий магазин з 14 000 SKU

Магазин м'яких меблів. 1 200 моделей, кожна в 8–20 варіантах тканини/кольору. Сумарно 14 000 торгових пропозицій.

Проблема після первинного налаштування: фільтр за кольором працював некоректно — показував товари, у яких колір був у властивості батьківського товару, а не у пропозиціях. Диван «Марко» мав колір «бежевий» у властивості товару, але конкретні варіанти з цим кольором були розпродані.

Коректне рішення:

1. Колір і матеріал перенесені у властивості інфоблоку офферів
2. Фасетний індекс налаштований на інфоблоці офферів
3. У компонент розділу додана перевірка: товар показується в результатах фільтра лише якщо у нього є пропозиція з залишком > 0 І з потрібним кольором
4. Зображення варіантів — у властивості пропозиції, зображення моделі — в батьківському товарі

Після перенесення: коректна фільтрація, «немає в наявності» за конкретними варіантами без приховування товару цілком.

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

• Аналіз варіативності товарів: які атрибути варіюються
• Проектування розмежування властивостей товар/пропозиція
• Налаштування зв'язку інфоблоків (основний + офери)
• Планування фасетного індексу для інфоблоку офферів
• Маппінг полів CommerceML для коректного обміну з 1С
• Схема відображення SKU на картці товару
• Тестування сценаріїв фільтрації після налаштування

Строк: 3–8 робочих днів залежно від складності варіативності та вимог до фільтрації.