Ви запускаєте інтернет-магазин на 1С-Бітрікс із сотнями варіацій товарів: дивани в 20 кольорах, кросівки 10 розмірів, ноутбуки з різним об'ємом пам'яті. Стандартна схема інфоблоків часто не враховує особливостей багатоваріантного каталогу, що призводить до проблем при масштабуванні. Фільтр за параметрами повинен показувати лише те, що є в наявності, а обмін з 1С — не плодити дублікатів.
Якщо на цьому етапі припуститися помилки в проектуванні SKU, наслідки позначяться на продуктивності та точності залишків. Кожен зайвий запит до бази знижує швидкість відгуку, а неправильна зв'язка пропозицій породжує дублі. Ми проектуємо торгові пропозиції (SKU) так, щоб фільтрація працювала миттєво, а залишки не дублювалися.
Наш досвід — десятки проєктів із тисячами варіантів товарів. Ми знаємо, як правильно розмежувати властивості товару та пропозиції, налаштувати фасетний індекс та організувати стабільний обмін з 1С. Оцінимо ваш проєкт під ключ за 3–8 днів — просто зв'яжіться з нами. Отримайте консультацію, і ми розберемо вашу структуру каталогу.
Технічна схема SKU в Бітрікс
Торгова пропозиція — елемент інфоблока оферів, прив'язаний до батьківського товару. У БД:
-
b_iblock_element— товар (типTYPE_PRODUCT) -
b_iblock_element— пропозиція (типTYPE_OFFER) -
b_catalog_product.OWNER_ID— зв'язок -
b_catalog_price— ціна на рівні пропозиції -
b_catalog_store_amount— залишки
Термін SKU (Stock Keeping Unit) використовується для однозначної ідентифікації варіанту. Налаштування зв'язку: Контент → Каталог → [інфоблок] → Торгові пропозиції. Компонент catalog.element відображає картку товару; він повинен коректно вибирати активну пропозицію.
Як правильно розмежувати властивості товару та пропозиції?
Головне правило: властивість відноситься до пропозиції, якщо її значення змінює ціну або залишок. Наприклад:
- Властивості товару: назва, опис, бренд, категорія, базові зображення.
- Властивості пропозиції: колір, розмір, об'єм, артикул, штрихкод, зображення варіанту.
Помилка — помістити колір у товар: тоді неможливо відфільтрувати «сині сукні 42 розміру», оскільки залишки прив'язані до пропозиції.
| Тип властивості | Приклади | Впливає на ціну/залишок |
|---|---|---|
| Товару | Бренд, категорія, опис | Ні |
| Пропозиції | Колір, розмір, артикул | Так |
Чому фільтрація за властивостями пропозицій гальмує?
Стандартний компонент bitrix:catalog.smart.filter вміє фільтрувати за властивостями оферів, але фасетний індекс будується окремо. Якщо у товару 50+ пропозицій, запити можуть бути важкими. Кастомна фільтрація з правильним фасетом працює в 2–3 рази швидше. Складний випадок — одночасна фільтрація за властивостями товару та пропозиції: стандартний фасет не підтримує cross-iblock. Потрібна доопрацювання компонента, наприклад, кастомний фільтр з попереднім агрегуванням.
Для великих каталогів (сотні тисяч SKU) ми використовуємо фасетний індекс з попереднім агрегуванням. Це дає приріст швидкості на 40% порівняно зі стандартним рішенням. Наш досвід підтверджує: грамотне проектування фільтра окупається на етапі навантаження. Економія бюджету на доопрацюваннях може сягати 30%.
Як уникнути дублювання SKU при обміні з 1С?
У CommerceML пропозиції передаються в ЗначенняРеквізитів. Критично: XML-ID має бути унікальним та стабільним. За документацією 1С-Бітрікс, навіть одноразова зміна ідентифікатора веде до дублювання. Погодьте формат з командою 1С до старту.
| Проблема | Рішення |
|---|---|
| Дуби товарів при повторному вивантаженні | Стабільний XML-ID, унікальний для кожної характеристики |
| Неправильний мапінг властивостей | Погодити схему з 1С заздалегідь |
| Втрата зв'язку товар-пропозиція | Правильне налаштування властивості-зв'язки (CML2_LINK) |
Кейс з нашої практики: меблевий магазин з 14 000 SKU
Ми налаштовували каталог для магазину м'яких меблів: 1 200 моделей, кожна в 8–20 варіантах тканини — разом 14 000 пропозицій. Після первинного налаштування фільтр за кольором показував товари, у яких колір був у властивості батьківського товару, а не пропозиції. Диван «Марко» з кольором «бежевий» відображався, навіть якщо всі бежеві варіанти розпродані. Рішення:
- Перенесли колір та матеріал в інфоблок оферів.
- Налаштували фасетний індекс на інфоблоці пропозицій.
- У компонент розділу додали перевірку: товар показується, тільки якщо є пропозиція з залишком > 0 і потрібним кольором.
- Зображення варіантів — у властивості пропозиції, моделі — у товарі.
Після доопрацювання фільтрація запрацювала коректно, а «немає в наявності» відображається за конкретними варіантами без приховування товару. Економія часу на обробку запитів — 40%. Гарантуємо, що ваш каталог працюватиме без збоїв. Вартість володіння каталогом знижується на 20% завдяки правильній архітектурі.
Що входить у роботу з проектування SKU
Повний список етапів
- Аналіз варіативності товарів та виділення властивостей пропозицій.
- Проектування розмежування: які атрибути — товарні, які — оферні.
- Налаштування зв'язку інфоблоків та властивості-зв'язки.
- Планування фасетного індексу для коректної фільтрації.
- Мапінг полів CommerceML для стабільного обміну з 1С.
- Схема відображення SKU на картці товару.
- Тестування всіх сценаріїв фільтрації та відображення.
Наша команда має досвід у розробці на 1С-Бітрікс, реалізували понад 30 проєктів з торговими пропозиціями. Отримайте консультацію — зв'яжіться з нами для аналізу вашого проєкту.