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

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

Интернет-магазин на 1С-Битрикс — это не шаблонная сборка, а инженерная задача, где модули sale, catalog, iblock и механизм обмена с 1С должны работать как единая система. Ошибки на этапе проектирования каталога или настройки торговых предложений приводят к тому, что через полгода магазин приходится переделывать. Ниже — разбор архитектуры, которая выдерживает рост ассортимента и нагрузки.

Модуль catalog: товары, SKU и типы цен

Каталог в Битрикс строится поверх инфоблоков. Товар — элемент инфоблока, а торговые предложения (SKU) — элементы привязанного дочернего инфоблока. Связь «товар → SKU» реализуется через свойство типа SKU (CML2_LINK). Это фундамент, от которого зависит всё остальное.

Архитектура каталога с торговыми предложениями заслуживает отдельного разбора, потому что именно здесь совершается большинство ошибок.

Торговое предложение — это самостоятельный элемент инфоблока со своими свойствами, ценами, остатками и штрихкодами. У одного товара может быть 5 предложений (цвет × размер), а может — 500 (как в электронных компонентах с разными параметрами). Структура инфоблока SKU определяет:

• Набор свойств-характеристик — те свойства, по которым предложения различаются (цвет, размер, объём). Тип свойства — справочник или строка, но для фасетного поиска предпочтительнее справочник (highload-блок).
• Цены — хранятся в таблице b_catalog_price с привязкой к конкретному SKU, а не к товару. Типов цен может быть несколько: розничная, оптовая, по акции. Каждый тип — запись в b_catalog_group.
• Складской учёт — остатки ведутся в b_catalog_store_product по каждому складу для каждого SKU. Если магазин мультисткладовой, нужна настройка приоритетов отгрузки.
• Штрихкоды — таблица b_catalog_store_barcode, привязка к SKU.

Ключевое правило: все коммерческие данные (цена, остаток, единица измерения) принадлежат торговому предложению, а не товару. Товар — это контейнер для описания, фотографий и SEO-данных.

При проектировании каталога с более чем 10 000 SKU необходимо:

1. Выносить справочники свойств в highload-блоки вместо строковых значений
2. Включать фасетный индекс (catalog.facet) для быстрой фильтрации
3. Использовать составные компоненты (bitrix:catalog.section, bitrix:catalog.element) с кешированием на уровне компонента и тегированным кешем

Обмен с 1С через CommerceML

Обмен реализуется модулем catalog через протокол CommerceML 2 (XML-формат). Процедура стандартная: 1С инициирует HTTP-запросы к скрипту /bitrix/admin/1c_exchange.php, передавая архив с XML-файлами.

Этапы обмена:

1. Авторизация (mode=checkauth) — 1С получает сессионные cookie
2. Инициализация (mode=init) — Битрикс сообщает лимит размера файла и директорию для загрузки
3. Загрузка файла (mode=file) — передача ZIP-архива по частям
4. Импорт каталога (mode=import) — парсинг import.xml (структура каталога, свойства, группы) и offers.xml (торговые предложения, цены, остатки)
5. Выгрузка заказов (mode=query) — Битрикс отдаёт XML с новыми заказами в формате CommerceML

Проблемы, которые возникают на каждом втором проекте:

• Таймауты при большом каталоге. Файл offers.xml весит 200 МБ, PHP падает по max_execution_time. Решение — пошаговый импорт: Битрикс обрабатывает файл порциями, возвращая progress вместо success, и 1С повторяет запрос.
• Дубли товаров. Если в 1С изменился XML_ID группы, Битрикс создаёт новую секцию вместо обновления. Нужна жёсткая привязка по XML_ID на уровне инфоблока.
• Конфликт цен. 1С выгружает все типы цен, но маппинг типа цены 1С → типу цены Битрикс задаётся в настройках обмена. Если маппинг сбился — цены перезаписываются неверно.
• Кодировка изображений. Путь к файлу картинки в XML содержит кириллицу, архиватор ломает имена. Решение — транслитерация имён файлов на стороне 1С перед выгрузкой.

Для проектов с обменом чаще одного раза в день стоит рассмотреть отказ от стандартного обмена в пользу прямого взаимодействия через REST API 1С или промежуточную очередь (RabbitMQ), где изменения обрабатываются инкрементально.

Модуль sale: корзина, оформление, оплата, доставка

Модуль sale управляет коммерческой логикой. Ключевые сущности:

• Корзина (Bitrix\Sale\Basket) — коллекция объектов BasketItem. Каждый элемент содержит ссылку на товар, количество, цену и набор свойств (размер, цвет — берутся из SKU).
• Заказ (Bitrix\Sale\Order) — контейнер: корзина + данные покупателя + оплаты + отгрузки.
• Оплата (Bitrix\Sale\Payment) — привязана к платёжной системе. Один заказ может содержать несколько оплат (частичная оплата бонусами + остаток картой).
• Отгрузка (Bitrix\Sale\Shipment) — привязана к службе доставки. Несколько отгрузок — если товары отправляются с разных складов.

Платёжные шлюзы подключаются как обработчики (sale_payment). Для каждого шлюза пишется класс-наследник Bitrix\Sale\PaymentSystem\BaseServiceHandler с методами initiatePay и processRequest (обработка callback). Стандартная поставка включает обработчики для ЮKassa, CloudPayments, Сбер. Нестандартные шлюзы (ЕРИП для Беларуси, например) требуют написания собственного обработчика с учётом протокола банка.

Службы доставки аналогично: класс-наследник Bitrix\Sale\Delivery\Services\Base. Расчёт стоимости зависит от веса, габаритов, зоны доставки. Для СДЭК и Boxberry есть готовые модули из Marketplace, но их часто приходится дорабатывать — добавлять выбор ПВЗ на карте, корректировать расчёт для нестандартных грузов.

Фасетный поиск и производительность каталога

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

Фасетный индекс нужно пересоздавать после массовых изменений каталога (импорт из 1С, массовое обновление свойств). Это делается через агент или вручную из панели администратора в разделе настроек инфоблока.

Дополнительные меры по производительности:

• Композитный кеш — для анонимных пользователей страницы каталога отдаются из HTML-кеша
• Тегированный кеш — инвалидация кеша при изменении конкретного товара, а не всего каталога
• CDN для изображений — Битрикс поддерживает вынос статики на внешнее хранилище через модуль clouds

SEO для товарных страниц

Модуль iblock поддерживает шаблоны SEO-полей: #ELEMENT_NAME#, #SECTION_NAME#, #PROPERTY_*#. Шаблоны задаются на уровне инфоблока или секции и автоматически генерируют <title>, <meta description>, <h1> для товаров, у которых эти поля не заполнены вручную.

Для e-commerce критичны:

• ЧПУ — настройка через свойства инфоблока и шаблон URL в настройках компонента
• canonical — чтобы страницы с параметрами фильтра не дублировали основную
• микроразметка — Schema.org Product с ценой, наличием, рейтингом
• sitemap — генерация через модуль seo с учётом разделов и товаров

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