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

Ми більше 5 років на ринку, виконали 150+ проєктів для e-commerce, маємо сертифікати Bitrix Professional. Наші рішення проходять навантaжувальне тестування та гарантують стабільну роботу при пікових навантаженнях. Довідка: у Вікіпедії наведена базова інформація про платформу 1С-Бітрікс та протокол CommerceML.

Чому 1С-Бітрікс — флагман e-commerce?

Фасетний індекс на каталозі з 200 000 SKU не побудовано — bitrix:catalog.smart.filter відпрацьовує 4 секунди замість 200 мс, і покупець іде. Наша розробка інтернет-магазинів на 1С-Бітрікс виключає такі сценарії: від архітектури інфоблоків та типів цін до кластерної балансировки під пікові навантаження. Типова помилка новачків — не налаштовано композитний кеш (bitrix:main.composite), і сторінки карток завантажуються по 5 секунд. Це вбиває конверсію швидше, ніж будь-який баг у кошику.

Двостороння синхронізація з 1С через CommerceML — каталог, ціни, залишки, замовлення та статуси. Налаштовується з адмінки модулем catalog -> «Обмін з 1С». Вивантаження на маркетплейси через YML-фіди (catalog.export) для Яндекс.Маркет, Google Shopping, Ozon, Wildberries.

Як ми вирішуємо ключові проблеми продуктивності?

bitrix:catalog.smart.filter без фасетного індексу генерує запити, які кладуть MySQL. Рішення: будуємо b_catalog_iblock_index — час відповіді падає з 4 секунд до 100–200 мс. Для SEO-фільтрів використовуємо catalog.seo.filter — індексовані сторінки перетинів фільтрів з унікальними мета-тегами.

Композитний кеш (bitrix:main.composite) прискорює завантаження сторінок у 3–5 разів порівняно зі звичайним. Мета — TTFB картки товару < 200 мс. Для сесій використовуємо Redis (SESSION_SAVE_HANDLER = redis в .settings.php). Lazy load зображень, CDN для статики, оптимізація SQL (особливо JOIN-и на b_iblock_element_property).

Чому кешування критичне для інтернет-магазину?

Кожна секунда затримки завантаження сторінки знижує конверсію в середньому на 7%. При TTFB > 400 мс 32% користувачів залишають сайт. Композитний кеш віддає сторінку з HTML, минаючи виконання PHP та запити до бази — це дає виграш до 5 разів за часом. Для карток товарів з частими змінами цін та залишків використовуємо теговане кешування: інвалідація відбувається лише за порушеними сутностями. На практиці вдавалося знизити TTFB з 1,2 секунди до 180 мс. Економія часу на завантаження каталогу — до 60%.

Типи магазинів та їх особливості

Інтеграції: платіжні системи, доставка, CRM, маркетплейси

Платіжні системи. Обробники в sale.handlers: ЮKassa, CloudPayments, Тинькофф, Сбербанк, Apple Pay, Google Pay, розстрочка. Callback sale.payment.notify для підтвердження статусу. Доставка. Обробники sale.delivery для СДЭК, Boxberry, Почту Росії, DPD — розрахунок вартості по API в реальному часі, трекінг. Складський облік. Резервування (RESERVED = Y в b_sale_basket), автоматичне списання при відвантаженні, сповіщення при залишках нижче порогу, передзамовлення для товарів в дорозі. CRM. Бітрікс24 або amoCRM — замовлення з b_sale_order ідуть автоматично, клієнтська база синхронізується. Тригери: покинутий кошик, запит відгуку, реактивація. Маркетплейси. Вивантаження через YML на Ozon, Wildberries, Яндекс.Маркет. Замовлення стікаються в єдину систему. Аналітика та маркетинг. GA4, Яндекс.Метрика, email-розсилки (Unisender, SendPulse). Логістика. МійСклад, Антор — етикетки, складальні листи.

Міграція з інших CMS

Перехід з OpenCart, WooCommerce, Shopify, MODX: перенесення каталогу (елементи, властивості, розділи, зображення, SEO-URL), міграція клієнтської бази (b_user) та історії замовлень (b_sale_order), 301-редиректи через urlrewrite.php. Паралельна робота на перехідний період — старий сайт продає, новий приймається. Досвід команди — 50+ проектів міграції.

Що входить в роботу (deliverables)

Етапи та терміни

Середній проект — 2–4 місяці:

1. Аналітика (1–2 тижні) — бізнес-вимоги, структура каталогу, інтеграції, ТЗ
2. Дизайн (2–3 тижні) — прототипи, дизайн-система, макети
3. Розробка (4–8 тижнів) — компоненти, шаблони, інтеграції, наповнення
4. Тестування (1–2 тижні) — функціональне, навантажувальне, приймальне
5. Запуск (2–3 дні) — деплой, моніторинг, оперативна підтримка

Вартість розраховується індивідуально — зв'яжіться з нами для оцінки бюджету. Наприклад, магазин на 50 000 товарів з інтеграцією 1С та CRM — бюджет варіюється в залежності від складності. MVP для старту доступний за мінімальною планкою. Економія на завантаженні каталогу до 60% часу.

Програма лояльності та конверсія

Бонусна система: бали за покупки, відгуки, рекомендації. Правила нарахування за категоріями, ліміт оплати балами, термін згоряння — все в особистому кабінеті. VIP-рівні (бронза, срібло, золото, платина) з підвищеним кешбеком та безкоштовною доставкою. Рекомендації «Вам сподобається», «Доповніть покупку» — вбудовані інструменти Бітрікс + RetailRocket або Mindbox. Тригери: знижка до дня народження, промокод для повернення, ланцюжок за інтересами. Персоналізація через catalog.recommended.products та catalog.viewed.products. A/B-тестування двох варіантів картки на реальному трафіку. Enhanced E-commerce в GA4 та Яндекс.Метриці — повний шлях від кліка до повторного візиту.

Зв'яжіться з нами для розрахунку вашого проекту. Замовте розробку інтернет-магазину під ключ — отримайте готове рішення з гарантією та підтримкою.