Розробка інтернет-магазину на 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 робочих днів. Оцінимо ваш проєкт безкоштовно — зв'яжіться з нами для консультації.