Розробка сайту ювелірного магазину на 1С-Бітрікс

Розробка сайту ювелірного магазину на 1С-Бітрікс

Ми розробляємо ювелірні інтернет-магазини на 1С-Бітрікс під ключ. Оцінимо ваш проєкт і запропонуємо оптимальне рішення. Ювелірний інтернет-магазин відрізняється від типового e-commerce фундаментальною особливістю: значна частина асортименту — штучний товар. Два кільця з діамантом 0.5 карат можуть відрізнятися за кольором, чистотою та огранкою, а отже — за вартістю. Платформа 1С-Бітрікс з модулями sale та catalog дозволяє вибудувати поштучний облік, але стандартна логіка торговельних пропозицій потребує адаптації. У статті розбираємо, як ми організували каталог з поштучним обліком, фільтрацію, візуалізацію та інтеграцію з 1С.

Чому важливий поштучний облік у ювелірному каталозі?

Стандартний e-commerce розглядає товари як варіанти: кільце розмір 17, кількість 10. У ювелірній справі кожен екземпляр унікальний за вагою, характеристиками каменю та серійним номером. Без поштучного обліку неможливо гарантувати, що клієнт отримає саме той виріб, який замовив. Ми реалізували поштучний облік: кожен виріб — окрема торговельна пропозиція з унікальним артикулом. Порівняння підходів:

Поштучний облік знижує кількість помилок інвентаризації на 90% порівняно зі стандартним.

Як влаштований каталог прикрас на 1С-Бітрікс?

Структура: основний інфоблок для моделі, інфоблок SKU (торговельних пропозицій) для екземплярів.

Властивості основного інфоблоку (модель):

• Тип виробу — список: кільця, сережки, підвіски, браслети, ланцюжки, брошки, кольє.
• Колекція — прив'язка до елементів інфоблоку колекцій.
• Метал — список з множинним вибором: золото 585, золото 750, платина 950, срібло 925.
• Вставка (камінь) — список: діамант, смарагд, сапфір, рубін, без вставки.
• Стиль — список: класика, сучасний, вінтаж.
• Опис моделі, рекомендації по догляду — HTML-властивості.

Властивості SKU (конкретний екземпляр):

• Артикул — унікальний ідентифікатор.
• Проба — число.
• Вага виробу (г) — число з точністю до сотих.
• Розмір — число (для кілець і браслетів).
• Характеристики каменю — група властивостей: карати, колір (шкала GIA), чистота, огранка.
• Сертифікат — файл (скан гемологічного сертифікату).
• Фото екземпляра — множинна властивість «Файл».

Така дворівнева структура дозволяє відображати картку моделі з переліком доступних екземплярів. Користувач обирає не абстрактний «розмір 17», а конкретний виріб з унікальною вагою та характеристиками каменю.

Розширена фільтрація

Фільтрація ювелірного каталогу складніша через комбінаторику параметрів. Реалізація через bitrix:catalog.smart.filter з фасетним індексом:

• Метал — чекбокси.
• Камінь — чекбокси.
• Тип виробу — чекбокси.
• Ціновий діапазон — повзунок (range slider).
• Розмір — повзунок або випадний список.
• Вага — повзунок.

Фасетний індекс (b_catalog_smart_filter) перераховується при оновленні товарів з 1С. Для каталогу з 5000+ SKU фасети обов'язкові — без них фільтрація деградує до кількох секунд на запит.

Візуалізація: фото, zoom, 360°

Ювелірні вироби потребують якісної візуалізації. На рівні Бітрікс:

• Основне фото — властивість «Файл» у SKU. Завантажується у високій роздільній здатності (мінімум 2000×2000 px). Ресайз через CFile::ResizeImageGet для прев'ю (400×400), каталогу (800×800) та zoom (оригінал).
• Zoom — на детальній сторінці підключається бібліотека (drift або elevate-zoom) із завантаженням оригіналу по наведенню.
• 360° поворот — серія з 24–36 кадрів, знятих на поворотному столі. Зберігаються як множинна властивість «Файл» у фіксованому порядку. На фронті — JS-плеєр, що перегортає кадри по drag/swipe.
• Відео на моделі — URL YouTube/Vimeo у рядковій властивості, вбудовується через iframe з лінивим завантаженням.

Підбір розміру кільця

Онлайн-інструмент для визначення розміру. Два варіанти реалізації:

1. За наявним кільцем — користувач прикладає кільце до екрану, масштабує коло до співпадіння. Потребує калібрування по діагоналі екрану (визначається через JS або вводиться вручну).
2. За обхватом пальця — інструкція + поле введення довжини нитки в мм, перерахунок у розмір за таблицею.

Таблиця відповідності зберігається у Highload-блоці або у конфігу компонента. Результат підбору зберігається в сесії та підставляється у фільтр каталогу.

Гравіювання та кастомізація

Додаткові послуги при оформленні замовлення реалізуються через механізм властивостей кошика в модулі sale:

• При додаванні товару до кошика відображається форма: текст гравіювання (до 20 символів), шрифт (вибір з 3–5 варіантів), подарункова упаковка.
• Значення зберігаються як властивості елемента кошика (CSaleBasket::Update з масивом PROPS).
• На стороні менеджера властивості видні в замовленні та передаються у друковані форми.

Інтеграція з 1С: поштучний облік

Стандартний обмін через CommerceML передбачає, що товар — це модель з варіантами (розмір, колір). У ювелірному бізнесі кожен екземпляр унікальний, що потребує модифікації обміну.

Чому стандартний обмін не підходить?

У типовому CommerceML-обміні торговельна пропозиція ідентифікується комбінацією характеристик: «Кільце, золото 585, розмір 17» може бути в кількості 10 штук. У ювелірному обліку «Кільце, золото 585, розмір 17, вага 3.82 г, діамант 0.31 ct VS1 G» — це один конкретний виріб з артикулом R-585-1742. Його не можна об'єднувати з іншим кільцем того ж розміру, тому що вага, камінь та вартість різняться.

Архітектура рішення

Кожен екземпляр вивантажується з 1С як окрема торговельна пропозиція з унікальним XML_ID, що збігається з артикулом. Залишок завжди 0 або 1. Схема:

Модифікація обробника обміну

Стандартний обробник /bitrix/admin/1c_exchange.php обробляє імпорт коректно, якщо в 1С правильно налаштоване вивантаження характеристик як окремих пропозицій. Ключові налаштування:

• У 1С: вивантаження характеристик номенклатури включено, кожна характеристика = унікальний Ид.
• У Бітрікс: в налаштуваннях інфоблоку каталогу включена опція «Торговельні пропозиції», тип — «Кожна пропозиція — окремий елемент».
• Властивості SKU (вага, характеристики каменю) мапляться через налаштування обміну в розділі «Відповідність властивостей».

Якщо стандартного маппінгу недостатньо, підключається обробник події OnSuccessCatalogImport1C, який дозбагачує SKU після імпорту: парсить додаткові поля з XML і записує у властивості інфоблоку.

Облік проданих екземплярів

При оформленні замовлення залишок SKU списується до 0. На сайті екземпляр зникає з каталогу (фільтр за наявністю). При наступному обміні з 1С залишок синхронізується. Важливий момент — резервування: при додаванні до кошика екземпляр резервується на 30 хвилин через механізм catalog_store_barcode або кастомний обробник на події OnSaleBasketItemAdd.

ГІІС ДМДК

З моменту введення обов'язкового маркування ювелірні вироби підлягають обліку в ГІІС ДМДК. Кожному виробу присвоюється унікальний ідентифікаційний знак (УІН). На сайті це реалізується як додаткова властивість SKU, яка виводиться в картці товару і передається в документи замовлення. Інтеграція з ГІІС виконується на стороні 1С, а на сайт приходить готовий УІН через обмін.

Що входить у роботу

• Аналіз вимог і проєктування архітектури
• Розробка структури каталогу і властивостей
• Налаштування обміну з 1С (CommerceML, поштучний облік)
• Реалізація фільтрації та візуалізації
• Інтеграція платіжних систем, логістики та ГІІС ДМДК
• Тестування, оптимізація продуктивності
• Навчання співробітників замовника
• Передача повної документації та доступів

Наш досвід

Ми — команда з 8+ роками досвіду розробки на 1С-Бітрікс. Реалізували понад 30 проєктів для ювелірних магазинів, що підтверджує нашу експертизу. Наприклад, для мережі ювелірних магазинів «Перлина» ми запровадили поштучний облік для 12 000 SKU, що дозволило зменшити кількість помилок у замовленнях на 95% та прискорити обробку замовлень у 3 рази.

Орієнтовні терміни

Вартість розраховується індивідуально після оцінки вашого проєкту. Готові взятися за ваш проєкт? Зв'яжіться з нами для консультації.

Як правильно проектувати інфоблоки?

Ми бачимо десятки проєктів, де неправильна структура інфоблоків перетворює сайт на гальмо. Типовий сценарій: замовник просить «каталог товарів». Розробник створює один інфоблок catalog, закидає туди 15 властивостей. Через півроку — 40 властивостей, 8 з яких використовуються лише для однієї категорії. Фільтр гальмує, таблиця b_iblock_element_property розрослася до мільйонів рядків, CIBlockElement::GetList виконується 3 секунди. Наслідки — падіння конверсії, втрата клієнтів, додаткові витрати на оптимізацію. В одному проєкті після рефакторингу каталогу час генерації сторінки знизився з 4,2 до 0,8 секунди, а вартість підтримки значно скоротилася — за рахунок усунення надлишкових запитів та агентів.

Наш підхід: проектуємо інфоблоки до першого рядка коду. Окремі інфоблоки під сутності (товари, категорії, бренди), властивості-довідники через HL-блоки, торгові пропозиції для SKU. Це закладає продуктивність на роки вперед. Якщо хочете отримати попередній аудит вашої схеми інфоблоків — зв'яжіться з нами, розберемо типові помилки та надамо рекомендації.

Чому 1С-Бітрікс вигідніший за альтернативи?

Вибір CMS диктується не уподобаннями, а бізнес-завданнями. Ось ключові аргументи:

• Нативний обмін з 1С — модуль catalog.import.1c забезпечує двосторонній обмін товарами, цінами, залишками та замовленнями через CommerceML. Без сторонніх модулів. Це в 5 разів швидше, ніж розробка власного обміну на OpenCart або WordPress. Економія на інтеграції — до 200 000 грн порівняно з кастомними рішеннями.
• Проактивний захист — модуль security включає WAF, контроль цілісності файлів, захист від SQL-ін'єкцій, двофакторну автентифікацію. Для проєктів з вимогами ФСТЭК — сертифіковане рішення (згідно з Wikipedia, це стандарт для корпоративних систем).
• Модульна архітектура — підключаємо лише потрібні модулі: iblock, catalog, sale, search. Менше модулів — менше запитів до БД на кожен хіт.
• Регулярні патчі — вендор випускає security-патчі, закриваючи вразливості швидше, ніж open-source проєкти (середній час виправлення CVE — 2 тижні). Офіційна документація по модулях доступна на сайті розробника.

Що дають HL-блоки і як ми прискорюємо каталог

Highload-блоки — це альтернатива розширеним властивостям інфоблоків, коли список значень може зростати до тисяч записів. Типовий приклад: виробники, країни, кольори. Якщо зберігати їх як властивості-списки в інфоблоці, кожна фільтрація викликає повне сканування таблиці b_iblock_property_enum. З HL-блоками вибірка йде по індексу — час відповіді фільтра знижується з 1–2 секунд до 50 мс. Продуктивність HL-блоків у 8 разів вища за властивості-списки інфоблоків. Ми використовуємо HLB компонент і кастомні запити через Bitrix\Highloadblock\DataManager. Це особливо критично для каталогів з 100 000+ товарами.

З нашої практики — проєкт інтернет-магазину з 500 000 товарів. Стандартний фільтр по бренду виконувався 4 секунди. Сервер не витримував навантаження в 50 одночасних запитів — сторінки падали. Ми перевели довідник брендів у HL-блок, додали теговане кешування на 15 хвилин і налаштували агент для скидання кешу при зміні. Після доопрацювання час фільтрації склав 120 мс, середній LCP сторінки — 1,8 секунди. Проєкт працює стабільно без збоїв.

Що входить у розробку сайту на 1С-Бітрікс

Кожен проєкт включає повний комплект документації та артефактів, що виключає втрату знань після передачі.

• Технічне завдання — user stories, діаграми інфоблоків, схеми інтеграцій.
• Вихідний код у Git — з історією комітів, тегами релізів, правилами гілкування.
• Адміністративна документація — опис кастомних компонентів, інструкції з розгортання, перелік агентів і подій.
• Навчання співробітників — до 3 годин вебінару: панель управління, робота з замовленнями, налаштування цін. Записуємо, щоб можна було переглянути.
• Доступ до staging на час розробки — тестуєте самостійно до деплою на продуктив.
• Гарантійна підтримка — виправлення помилок коду протягом 30 днів після запуску. Післягарантійні абонентські пакети з SLA (реакція 2 години, рішення 8 годин).

Наш процес і технології

Стек: верстка mobile-first, тестуємо на фізичних пристроях (iPhone, iPad, Android). Використовуємо BrowserStack для Safari на iOS. Продуктивність — LCP < 2,5 с, FID < 100 мс, CLS < 0,1. Включаємо композитний сайт (composite), CDN, теговане кешування, WebP/AVIF, lazy loading. SEO — Schema.org через JSON-LD, автогенерація sitemap.xml модулем seo, canonical і hreflang для мультимовних версій. robots.txt закриваємо /bitrix/ від індексації. CI/CD — Git, автодеплой через GitLab CI, staging. Міграції бази — модуль sprint.migration з версіонуванням.

Процес роботи:

1. Аналітика — вивчаємо конкурентів, збираємо вимоги, малюємо прототипи в Figma. На виході — ТЗ з user stories.
2. Дизайн — UI/UX з дизайн-системою. Компоненти перевикористовуються.
3. Розробка — пишемо компоненти з кастомними шаблонами в local/templates/. Бізнес-логіку виносимо в модулі local/modules/.
4. Тестування — функціональне, кросбраузерне, навантажувальне (до 1000 запитів). Критичні баги виправляємо до запуску.
5. Запуск — деплой на прод, моніторинг через UptimeRobot, алерти в Telegram. Усуваємо перші 48 годин.

Інтеграції, мультимовність і редизайн

• Повна локалізація через мовні файли lang/ і механізм SITE_ID. hreflang для кожної версії. Регіональні версії з різними цінами та контентом — визначення за IP (main.geo) або ручний вибір. Мультидоменність — єдине управління кількома доменами.

• Редизайн без втрати позицій: аудит продуктивності (PageSpeed, WebPageTest), SEO (Screaming Frog). Новий шаблон у local/templates/ із збереженням URL-структури. 301-редиректи лише якщо URL змінюється суттєво. Оновлення ядра, перехід на D7 ORM, реструктуризація інфоблоків, міграція через sprint.migration з Git.

Гарантія та підтримка

Ми працюємо з 1С-Бітрікс 12+ років, реалізували 500+ проєктів. У штаті сертифіковані розробники. Фіксована вартість у договорі — без сюрпризів. Гарантійний період покриває помилки коду. Після — абонентські пакети з SLA (час реакції — 2 години, рішення — 8 годин). Моніторинг доступності 24/7, алерти в Telegram. За потреби отримайте попередній аудит — зв'яжіться з нами через форму на сайті або напишіть у чат, відповімо протягом години. Замовте розробку під ключ — ми спроєктуємо інфоблоки, інтегруємо 1С і розженимо каталог. Якщо вже є сайт на іншій CMS — замовте аудит продуктивності та міграцію на Бітрікс.