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

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

Каталог без корзины — это когда товар показан, описан, отфильтрован, но кнопки «Купить» нет. Вместо неё — «Запросить цену», «Оставить заявку», «Скачать прайс». Типичная история для B2B: промышленное оборудование, строительные материалы, автозапчасти, коммерческая недвижимость. Цена зависит от объёма, региона, курса валюты — публиковать фиксированную бессмысленно. Или товар штучный: один экскаватор, один объект недвижимости — корзина тут абсурд.

С точки зрения Битрикса это принципиально другая архитектура. Не «интернет-магазин минус корзина», а отдельный класс проекта со своими решениями на каждом уровне — от лицензии до структуры инфоблоков.

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

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

Выбор зависит от сценария:

На «Старте» каталог строится целиком на модуле iblock. Товар — элемент инфоблока, категория — раздел. Свойства инфоблока — характеристики товара. Всё. Никаких торговых обёрток.

Структура инфоблоков без 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 нет таблицы b_iblock_element_property с множителем вариаций. Если товар имеет 15 свойств и нет SKU — это 15 строк в EAV на элемент. С SKU по 5 вариаций — 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-код инфоблока). Генерируется автоматически, позволяет строить запросы через ::getList() с filter, select, runtime. Плюс: полный контроль над SQL, можно добавить кеширование результатов фильтрации
2. Elasticsearch / Sphinx — для каталогов от 50К позиций. Индексация через агент или обработчик события OnAfterIBlockElementUpdate. Фильтрация — 5-20ms на любом объёме. Минус: дополнительная инфраструктура
3. Фильтр на Highload-блоке — если каталог перенесён в HLBlock, фильтрация идёт по плоской таблице с индексами. Быстро, но теряются штатные SEO-компоненты инфоблоков

Рекомендация для большинства проектов: стандартный catalog.smart.filter + правильные индексы в БД. Кастом — только когда данные доказывают необходимость.

CIBlockElement::GetList vs D7: что использовать

Старое API: CIBlockElement::GetList($arOrder, $arFilter, $arGroupBy, $arNavStartParams, $arSelectFields). Работает, документировано, примеров тысячи. Проблема — нет строгой типизации, нет автодополнения в IDE, фильтры через массивы-соглашения (">=PROPERTY_POWER" => 100).

D7 API: \Bitrix\Iblock\Elements\ElementEquipmentTable::getList([...]). Строгие типы, fluent-интерфейс, runtime-поля, registerRuntimeField() для computed-колонок. IDE понимает структуру, рефакторинг безопасен.

Практическое правило: новый код — на D7, существующий — не переписывать ради переписывания. CIBlockElement::GetList никуда не денется, Битрикс поддерживает обратную совместимость десятилетиями. Но если строите фильтр или агрегацию с нуля — 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}. Для каталога без корзины «купить» заменяем на «характеристики и цена» или «заказать».

ЧПУ настраиваются через шаблон URL в параметрах компонента 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 с priceCurrency без price. Google поймёт, Яндекс примет через Вебмастер.

Сравнение товаров без модуля sale

Штатное сравнение в Битриксе (bitrix:catalog.compare.list) зависит от модуля catalog. На «Старте» не работает. Решение — кастомный компонент сравнения.

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

На React-фронте (headless/SPA-подход) — сравнение хранится в state или localStorage, данные тянутся через REST API /rest/iblock.element.get или кастомный контроллер.

«Запросить цену» вместо «Купить»

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

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

Варианты CTA-кнопок в зависимости от отрасли:

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

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

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

Для каталога без корзины обмен обычно односторонний: 1С → сайт. Номенклатура, остатки, характеристики. Реализуется через:

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

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

Этапы и сроки

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

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

Каталог без корзины оправдан, если выполняется хотя бы два условия:

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

Если через полгода понадобится корзина — переход с каталога на магазин при правильной архитектуре (инфоблоки, разделение логики) занимает 2-4 недели: подключение модуля sale, добавление типов цен, настройка платёжных систем и служб доставки. Данные каталога остаются без изменений.