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

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

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

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

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

Архитектура каталога с торговыми предложениями заслуживает отдельного разбора, потому что именно здесь совершается большинство ошибок. Торговое предложение — это самостоятельный элемент инфоблока со своими свойствами, ценами, остатками и штрихкодами. У одного товара может быть 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) с кешированием на уровне компонента и тегированным кешем.

Почему фасетный индекс критичен для каталога?

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

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

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

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

Как обмен с 1С влияет на производительность?

Обмен реализуется модулем 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, но их часто приходится дорабатывать — добавлять выбор ПВЗ на карте, корректировать расчёт для нестандартных грузов.

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

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

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

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

Что входит в работу

В состав услуги по разработке интернет-магазина на 1С-Битрикс входит:

• Проектирование архитектуры каталога (инфоблоки, SKU, свойства, цены).
• Настройка обмена с 1С через CommerceML или REST API.
• Интеграция платёжных шлюзов (ЮKassa, Сбер, CloudPayments и др.).
• Подключение служб доставки (СДЭК, Boxberry, Почта России).
• Разработка фасетного поиска и фильтрации.
• Настройка SEO-шаблонов, sitemap, микроразметки.
• Развёртывание на продакшене, настройка композитного кеша и CDN.
• Документация по архитектуре и доступы к администрированию.
• Обучение контент-менеджеров работе с каталогом и заказами.
• Техническая поддержка в течение 3 месяцев после запуска.

Сроки разработки зависят от сложности проекта: от 30 до 90 рабочих дней. Оценим ваш проект бесплатно — свяжитесь с нами для консультации.