Розробка інтернет-магазину на 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С отримує сесійні куки
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). Стандартна поставка включає обробники для ЮКассу, CloudPayments, Сбербанку. Нестандартні шлюзи (ERIP для Беларусі, наприклад) потребують написання власного обробника з урахуванням протоколу банку.

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

Фасетний пошук та продуктивність каталогу

Фасетний індекс — це передвичислені таблиці, які зберігають зв'язок «значення властивості → кількість товарів». Без нього фільтрація за властивостями на каталозі в 50 000 товарів займає секунди. З фасетом — мілісекунди.

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

Додаткові заходи по продуктивності:

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

SEO для товарних сторінок

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

Для електронної комерції критичні:

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

Грамотно спроектований інтернет-магазин на Бітрікс — це не просто «поставили коробку та залили товари». Це продумана архітектура каталогу, надійний обмін з системою обліку та комерційна логіка, що враховує специфіку бізнесу.