Розробка сайту-каталогу без кошика на 1С-Бітрікс

Розробка сайту-каталогу без кошика на 1С-Бітрікс

Каталог без кошика — це сайт, де товар показано, описано, відфільтровано, але онлайн-покупка неможлива. Замість кнопки «Купити» — «Запитати ціну», «Замовити дзвінок», «Завантажити прайс». Модель характерна для B2B: промислове обладнання, будівельні матеріали, автозапчастини, комерційна нерухомість. Ціна залежить від обсягу замовлення, регіону, умов договору — публікувати фіксовану безглуздо. Або товар одиничний: один екскаватор, один об'єкт — кошик тут не потрібен.

З боку архітектури Бітрікса це не «інтернет-магазин мінус кошик». Це окремий клас проєкту з власними рішеннями на кожному рівні — від ліцензії до структури інфоблоків.

Ліцензія: «Старт» чи «Стандарт»

Перше питання, яке впливає на бюджет. Редакція «Старт» не містить модулів sale і catalog. Немає торгових пропозицій (SKU), немає типів цін, немає кошика, немає замовлень. Для каталогу без кошика — саме те, що треба. Редакція «Стандарт» містить catalog, але дозволяє використовувати його вибірково: увімкнути властивості торгового каталогу для інфоблоку, не підключаючи sale. Це дає торгові пропозиції й множинні ціни без кошика.

Структура інфоблоків без SKU

Без торгових пропозицій структура спрощується принципово. Один інфоблок — один каталог. Немає зв'язки «товар → SKU» через PROPERTY_CML2_LINK. Немає таблиці b_catalog_product. Немає b_catalog_price.

Типова структура для каталогу промислового обладнання:

Інфоблок «Каталог обладнання» (тип catalog, API-код equipment):

• Розділи — категорії (Насоси → Відцентрові → Горизонтальні)
• Елементи — товарні позиції
• Властивості:
  • MANUFACTURER (довідник, прив'язка до Highload-блоку) — виробник
  • ARTICLE (рядок, індексоване) — артикул
  • POWER (число) — потужність, кВт
  • WEIGHT (число) — маса, кг
  • MATERIAL (список) — матеріал корпусу
  • DOCS (файл, множинне) — PDF-документація
  • GALLERY (файл, множинне) — фотографії
  • PRICE_ON_REQUEST (чекбокс) — ціна за запитом
  • IN_STOCK (список: «В наявності», «Під замовлення», «Знято з виробництва»)

Довідники зберігаються в Highload-блоках. Виробники, одиниці виміру, країни. HLBlock «Виробники» — таблиця b_hlbd_manufacturers з полями UF_NAME, UF_LOGO, UF_COUNTRY, UF_WEBSITE. Прив'язка з інфоблоку через властивість типу «Довідник».

Чому це важливо для продуктивності: без SKU кожен товар генерує один рядок на властивість у EAV-таблиці b_iblock_element_property. Товар із 15 властивостями = 15 рядків. Додайте 5 варіантів SKU — і це вже 75 рядків на товар. На 10К товарів різниця між 150К і 750К рядків відчутна при фільтрації.

Фільтрація: catalog.smart.filter без модуля catalog

Компонент bitrix:catalog.smart.filter працює на інфоблоках і без модуля catalog. Але є нюанс: фасетні індекси (таблиці b_catalog_sm_*) доступні лише при активованому модулі catalog. На «Старті» фасетів немає.

Без фасетів фільтрація виконується прямими запитами до b_iblock_element_property. На каталозі до 10-15К позицій з 10 властивостями для фільтрації — прийнятно, 100-300ms. На 50К+ — вже проблема, 2-5 секунд.

Альтернативи для великих каталогів:

1. Кастомний фільтр на D7 ORM — Bitrix\Iblock\Elements\ElementXxxTable (де Xxx — API-код інфоблоку). Автоматично згенеровані ORM-класи підтримують ::getList() із filter, select, runtime. Повний контроль над SQL, можна додати кешування результатів
2. Elasticsearch / Sphinx — для каталогів від 50К позицій. Індексація через обробник події OnAfterIBlockElementUpdate. Фільтрація — 5-20ms незалежно від обсягу. Мінус: додаткова інфраструктура
3. Каталог на Highload-блоці — фільтрація по плоскій таблиці з індексами. Швидко, але втрачаються штатні SEO-компоненти інфоблоків

Для більшості проєктів каталогу без кошика до 30К позицій стандартний catalog.smart.filter із правильними індексами в базі — достатнє рішення.

CIBlockElement::GetList проти D7 ORM

Старе API: CIBlockElement::GetList($arOrder, $arFilter, $arGroupBy, $arNavStartParams, $arSelectFields). Працює, задокументоване, прикладів тисячі. Фільтри через масиви-угоди (">=PROPERTY_POWER" => 100). Немає строгої типізації, IDE не розуміє ключі фільтра.

D7 API: \Bitrix\Iblock\Elements\ElementEquipmentTable::getList([...]). Строгі типи, fluent-інтерфейс, runtime-поля для обчислюваних колонок. IDE розуміє структуру класу, рефакторинг безпечний. Вбудований managed cache через параметр cache — без ручного обгортання в CPHPCache.

Практичне правило: новий код — на D7, робочий legacy — не переписувати заради переписування. CIBlockElement::GetList підтримується і ніякого deprecation не буде. Але для нового фільтра чи агрегації D7 дає передбачуваний SQL, який можна профілювати через \Bitrix\Main\Diag\SqlTracker.

SEO для каталогу на інфоблоках

Модуль iblock має вбудовані SEO-шаблони. Налаштовуються на рівні інфоблоку: вкладка «SEO» → шаблони для розділів і елементів. Змінні:

• {=this.Name} — назва елемента/розділу
• {=this.PreviewText} — анонс
• {=this.property.MANUFACTURER} — значення властивості
• {=parent.Name} — назва батьківського розділу

Шаблон <title> для товару: {=this.Name} — {=parent.Name}, характеристики від {=this.property.MANUFACTURER}. Для каталогу без кошика слово «купити» у title не використовуємо — немає можливості покупки, пошукові системи й відвідувачі помітять невідповідність.

ЧПУ налаштовуються через параметри компонентів catalog.section / catalog.element:

• Розділ: /catalog/#SECTION_CODE#/
• Елемент: /catalog/#SECTION_CODE#/#ELEMENT_CODE#/

SECTION_CODE і ELEMENT_CODE генеруються автоматично з назви (транслітерація) при увімкненій опції «Транслітерувати символьний код при додаванні елемента».

Мікророзмітка — Schema.org Product без Offer (немає ціни для покупки). Вказуємо name, description, image, brand, sku (артикул). Для «ціна за запитом» — пропускаємо offers або використовуємо priceSpecification без price.

Порівняння товарів без модуля sale

Штатне порівняння (bitrix:catalog.compare.list) залежить від модуля catalog. На «Старті» не працює. Рішення — кастомний компонент порівняння.

Зберігання: масив ID обраних товарів у $_SESSION['COMPARE_LIST'][IBLOCK_ID] або в cookie для незалогінених відвідувачів. Вивід: CIBlockElement::GetList по масиву ID з вибіркою всіх властивостей, рендер у таблицю «властивість — значення по товарах». Реалізація — 8-12 годин розробки, включаючи JS для додавання/видалення без перезавантаження сторінки.

На React-фронті порівняння зберігається в state або localStorage. Дані товарів завантажуються через REST API (/rest/iblock.element.get) або кастомний контролер.

«Запитати ціну» замість «Купити»

Центральний UX-патерн каталогу без кошика. Реалізація через модуль webform або кастомний обробник.

Форма прив'язується до елемента каталогу: в прихованому полі передається ELEMENT_ID і ELEMENT_NAME. Менеджер отримує лист: «Запит ціни на [назва товару], артикул [XXX], від [ім'я, телефон, email]». Дані зберігаються в інфоблоці заявок або в Highload-блоці для відстеження конверсії.

Варіанти CTA-кнопок залежно від галузі:

• Обладнання: «Запитати комерційну пропозицію»
• Нерухомість: «Записатися на перегляд»
• Автозапчастини: «Уточнити наявність і ціну»
• Меблі на замовлення: «Розрахувати вартість»

Обмін з 1С без модуля sale

На редакції «Старт» штатний обмін CommerceML (/bitrix/admin/1c_exchange.php) недоступний. Альтернатива — кастомний імпорт через CSV/XML або REST API.

Для каталогу без кошика обмін зазвичай односторонній: 1С → сайт. Номенклатура, залишки, характеристики. Варіанти реалізації:

• Агент (CAgent) за розкладом, що парсить XML-вивантаження з 1С
• Cron-завдання, яке викликає скрипт імпорту через CLI
• REST API, якщо 1С налаштована відправляти HTTP-запити через HTTPСоединение

На «Стандарті» з модулем catalog штатний обмін CommerceML працює повноцінно — просто модуль sale не підключається.

Типові галузі для каталогу без кошика

Промислове обладнання. Насоси, компресори, верстати. Десятки технічних характеристик, PDF-документація, сертифікати. Ціна — за запитом, бо залежить від комплектації та обсягу замовлення.

Будівельні матеріали. Цегла, арматура, утеплювачі. Ціна за одиницю безглузда — продають палетами, машинами, вагонами. Калькулятор обсягу + форма запиту.

Автозапчастини (B2B). Каталог за VIN або cross-reference. Наявність змінюється щогодини, ціна — за домовленістю з постачальником. Кошик неможливий без інтеграції з ERP в реальному часі.

Комерційна нерухомість. Кожен об'єкт унікальний. Площа, поверх, клас будівлі, фото, планування. «Записатися на перегляд» замість «Купити».

Етапи та терміни

1. Проєктування (3-5 днів) — структура інфоблоків, карта властивостей для фільтрації, прототипи в Figma
2. Дизайн (1-2 тижні) — каталог, картка товару, фільтр, порівняння, форми заявок
3. Розробка (2-5 тижнів) — верстка, інтеграція з Бітрікс, налаштування фільтра, форми, SEO
4. Наповнення та імпорт (3-7 днів) — завантаження товарів, налаштування обміну з 1С за потреби
5. Тестування та запуск (3-5 днів) — кросбраузерність, мобільна версія, PageSpeed, передача в експлуатацію

Коли каталог — правильний вибір, а коли потрібен магазин

Каталог без кошика виправданий, якщо виконуються хоча б дві умови:

• Ціни непублічні або залежать від контексту (обсяг, регіон, договір)
• Угода потребує переговорів — не можна оформити за 2 кліки
• Асортимент складний: товар описується 15+ характеристиками, обирається за специфікацією
• Немає складської логістики на боці сайту

Якщо через півроку знадобиться кошик — перехід із каталогу на магазин при правильній архітектурі займає 2-4 тижні: підключення модуля sale, додавання типів цін, налаштування платіжних систем і служб доставки. Дані каталогу залишаються без змін.