Проектування структури каталогу товарів 1С-Бітрікс
Найдорожча помилка в e-commerce проєкті на Бітрікс — це неправильна структура каталогу, виявлена через 6 місяців після запуску. Переробка структури інфоблоків з даними, налаштованим обміном з 1С та працюючим сайтом — це не «доробка», це фактично новий проєкт з міграцією. Тому проектування структури каталогу виконується до написання першого рядка коду і до налаштування обміну з 1С.
Модулі, задіяні в каталозі
Каталог товарів у Бітрікс — це не один модуль, а взаємодія кількох:
-
iblock— зберігання товарів та їх властивостей -
catalog— торгова логіка: ціни, залишки, знижки, типи товарів (b_catalog_product,b_catalog_price,b_catalog_store_amount) -
sale— кошик і оформлення замовлення -
search— повнотекстовий пошук
Структура каталогу проектується з урахуванням усіх модулів, а не лише iblock. Наприклад, якщо планується мультискладський облік — у b_catalog_store потрібно описати склади, і це впливає на те, як відображаються залишки на картці товару.
Схема «один інфоблок» vs. «кілька інфоблоків»
Класична дилема. Кілька інфоблоків для різних категорій товарів виглядають привабливо (у кожної категорії свої властивості), але створюють проблеми:
- Фільтр не може працювати за властивостями з різних інфоблоків
- Обмін з 1С налаштовується окремо для кожного інфоблоку
- Пошук по всьому каталогу вимагає об'єднання результатів
Один інфоблок для всього каталогу — правило за замовчуванням. Властивості, специфічні для категорій, додаються до загальної схеми і залишаються порожніми у товарів інших категорій. Це «марнотратно» лише на перший погляд: порожні значення в b_iblock_element_property не зберігаються.
Виняток: каталог з принципово різною структурою даних (наприклад, фізичні товари та цифрові послуги в одному магазині) — тоді два інфоблоки виправдані, але з єдиною системою пошуку та окремими компонентами.
Ієрархія розділів і глибина вкладеності
Розділи каталогу (b_iblock_section) — це дерево категорій. Проектується з урахуванням:
- SEO: URL виду
/catalog/electronics/smartphones/або/catalog/smartphones/ - Навігації: скільки рівнів у меню відображається користувачу
- Фільтрації: на якому рівні застосовується фасет
Практичне правило: не більше 4 рівнів вкладеності. Глибше — проблеми з побудовою ЧПУ, хлібними крихтами та управлінням в адміністративній панелі.
Розділи vs. властивості для класифікації: якщо товар належить до кількох категорій (наприклад, «Кабель HDMI» — і в «Кабелі», і в «Телевізійне обладнання») — прив'язка лише до одного розділу втрачає другу класифікацію. У таких випадках додаткова класифікація зберігається у властивості-довіднику, а не в розділах.
Торгові пропозиції (SKU): коли і як
Торгові пропозиції потрібні, коли товар має варіанти з різними цінами або залишками. Реалізація в Бітрікс: батьківський елемент основного інфоблоку + пов'язаний інфоблок офферів, прив'язаний через налаштування Catalog.Offers у модулі catalog.
Важливе проектне рішення: які властивості належать товару, а які — торговій пропозиції. Колір і розмір — властивості пропозиції (у кожного варіанту свої). Бренд і опис — властивості батьківського товару. Порушення цієї логіки призводить до помилок у фільтрації: фільтр за кольором повинен працювати на рівні офферів.
Ціни, знижки, типи цін
Структура ціноутворення проектується на старті:
- Скільки типів цін потрібно (
b_catalog_price_type): базова, оптова, дилерська? - Як застосовуються знижки: правила знижок (
b_catalog_discount) або накопичувальні програми (b_catalog_discount_coupon)? - Як ціни пов'язані з групами користувачів?
Для B2B-магазину з індивідуальними цінами для кожного клієнта стандартна система типів цін не підходить — потрібна кастомна логіка через обробники подій модуля catalog.
Кейс: проектування каталогу для виробника меблів на замовлення
Виробник корпусних меблів. Особливість: товар — не стандартний продукт, а конфігурований виріб (висота, ширина, матеріал фасаду, фурнітура). Ціна залежить від конфігурації.
Стандартна схема SKU не підходила: комбінацій занадто багато для попереднього створення офферів.
Проектне рішення:
- Інфоблок «Колекції» — батьківські елементи (шафа-купе «Модерн», кухня «Класика»)
- HL-блок
hl_materials— 48 варіантів матеріалів з ціновими коефіцієнтами (UF_PRICE_COEF) - HL-блок
hl_hardware— 120 варіантів фурнітури - Компонент конфігуратора — кастомний, будує підсумкову ціну на JS на основі даних HL-блоків через REST API Бітрікс
- У кошик додається елемент зі складом конфігурації у вигляді JSON у властивості замовлення
Каталог працює 3 роки, обсяг — 240 колекцій, структура не змінювалася.
Склад роботи з проектування структури каталогу
- Аналіз асортименту та бізнес-вимог
- Схема інфоблоків: основний каталог, офери, допоміжні
- Проектування ієрархії розділів
- Схема властивостей з типами та участю у фасеті
- Проектування торгових пропозицій
- Структура цін і типів цін
- Схема обміну з 1С: маппінг полів, periodичність, напрямок
- Оцінка обсягу і прогноз навантаження
Строк: від 1 тижня для стандартного каталогу до 3–4 тижнів для складних конфігурованих продуктів або мультибрендового маркетплейсу.