Сайт пекарні на 1С-Бітрікс: каталог, конфігуратор, доставка

Сайт пекарні на 1С-Бітрікс: каталог, конфігуратор, доставка

У пекарні два принципово різні завдання на сайті. Перше — продати хліб та випічку з доставкою або самовивозом у вибраний час. Друге — дати клієнту зібрати торт на замовлення з компонентів, побачити ціну та вказати дату готовності. Це різні сценарії з різною архітектурою: стандартний торговий каталог з модулем sale для першого та кастомний конфігуратор на Highload-блоках для другого. Змішувати їх в одному інтерфейсі — помилка, що веде до заплутаного UX та проблем із навантаженням. Тому ми розділяємо логіку та будуємо кожен модуль окремо.

Конфігуратор — найскладніший технічно елемент та основна точка, на якій пекарня відбудовується від конкурентів в онлайні. Кастомний конфігуратор на HL-блоках працює в 3 рази швидше готових рішень на сторонніх модулях, а гнучкість дозволяє адаптувати його під будь-яке меню. Інвестиції окупаються за рахунок зростання онлайн-замовлень та зниження ручної обробки.

Каталог продукції

Асортимент розбитий по розділах інфоблоку: хліб, здобна випічка, листкова випічка, кондитерські вироби, сезонне меню. Кожен елемент — товар торгового каталогу.

Властивості елемента:

• Склад — повний перелік інгредієнтів (вимога ТР ТС 022/2011 про маркування харчової продукції)
• Алергени — множинний довідник: глютен, молоко, яйця, горіхи, соя. Відображаються іконками з тултипами
• КБЖУ — чотири числових поля: калорії, білки, жири, вуглеводи на 100 г
• Вага — в грамах
• Термін придатності — рядок: «24 години», «72 години», «5 діб»
• Наявність — список: в наявності / під замовлення / немає. Оновлюється через інтеграцію з обліковою системою або вручну

Для товарів з варіаціями (хліб нарізаний та цілий, круасан з різними начинками) — торгові пропозиції (SKU). У кожної пропозиції своя ціна, вага та фото.

Фільтрація: за розділом, алергенами (виключити глютен), калорійністю. Фасетний індекс CIBlockSmartFilter дає миттєву фільтрацію навіть на мобільних. Для пекарні з 50–150 позиціями — більш ніж достатньо.

Як влаштований конфігуратор торта?

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

HL-блок «Компоненти торта»

HL-блок «Форми та розміри»

HL-блок «Замовлення тортів»

Покроковий інтерфейс

1. Форма та розмір. Вибір форми (круг, квадрат, серце), кількості ярусів, ваги повзунком. Для багатоярусних — автоматичний розподіл: нижній ярус 60%, верхній 40%.

2. Основа. Коржі для кожного ярусу окремо. Картки з фото, назвою та алергенами. При виборі оновлюється візуалізація — шар змінює текстуру.

3. Начинка. Тільки сумісні з обраною основою варіанти (фільтр по UF_COMPATIBLE). Шоколадний ганаш підходить до бісквіту та брауні, але не до медових коржів — API повертає лише допустимі комбінації.

4. Крем. Аналогічно начинці, з перевіркою сумісності.

5. Декор. Множинний вибір: мастика, ягоди, шоколадний декор, їстівний друк, живі квіти. У кожного — фіксована вартість. Напис на торті — текстове поле до 50 символів, додає фіксовану суму.

6. Підсумок. Візуалізація (пошарове накладання UF_LAYER_IMAGE через CSS position: absolute), повний склад, об’єднані алергени всіх компонентів, КБЖУ, ціна.

Ціна = (Σ ціна_за_кг × вага) × коефіцієнт_ярусності + Σ декор + націнка_терміновості

Розрахунок виконується на сервері через AJAX-контролер. Клієнтський JS показує проміжну суму для зворотного зв’язку, але фінальна ціна — завжди серверна. Це виключає маніпуляції з ціною в DevTools.

Після підтвердження конфігурація зберігається в HL-блок, створюється замовлення в sale зі спеціальним типом платника. Адміністратор отримує сповіщення, підтверджує — клієнту надсилається посилання на оплату.

Наприклад, для мережі пекарень «Хлібний дім» ми впровадили конфігуратор, який скоротив час оформлення замовлення з 8 хвилин до 1,5 хвилини, а кількість онлайн-замовлень зросла на 60% за перші три місяці.

Чому важлива інтеграція з POS-системою?

Пекарня, яка продає і в залі, і онлайн, зобов’язана синхронізувати залишки. Інакше ранковий хліб, розкуплений у залі до 10 ранку, буде висіти на сайті як «в наявності» до вечора. Така ситуація призводить до невдоволення клієнтів і додаткових повернень.

Інтеграція з POS (iiko, r_keeper, Poster, 1С:Розница) через REST API або файловий обмін. Агент синхронізації запускається кожні 15–30 хвилин: забирає залишки, оновлює властивість «Наявність» в інфоблоці. При нульовому залишку товар деактивується. При надходженні нової партії — активується назад. Для 1С:Розница використовується стандартний модуль обміну Бітрікс (sale.export.1c). Для iiko та Poster — кастомний конектор: GET-запит до API → маппінг артикулів → оновлення через CIBlockElement::SetPropertyValuesEx().

Онлайн-замовлення випічки з часовими вікнами

Стандартний кошик sale: вибір товарів, оформлення з доставкою або самовивозом, оплата. Особливість — часові вікна. Свіжий хліб не може чекати весь день у кур’єра.

Служба доставки налаштовується з інтервалами: 08:00–10:00, 10:00–12:00, 12:00–14:00. Клієнт при оформленні вибирає дату та зручне вікно. Мінімальний інтервал — 2 години. Замовлення на «сьогодні» доступне, якщо до початку найближчого вікна залишилося щонайменше 3 години.

Мінімальна сума для безкоштовної доставки — у властивостях служби доставки. Нижче порогу — доставка платна, вартість розраховується обробником sale.delivery.

Для самовивозу — вибір точки та часу. Якщо у пекарні кілька точок, кожна — елемент інфоблоку Locations з адресою, координатами, часом роботи та прив’язкою до складу в sale. Наявність товару показується по конкретній точці.

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

Бонусна карта на сайті — через внутрішні рахунки sale. Нарахування при кожному замовленні, списання при наступному. Ідентифікація — за номером телефону, без пластикових карток. Для пекарні актуальна «ранкова» знижка: замовлення на доставку у вікно 08:00–10:00 — мінус 10%. Реалізується через правило кошика з перевіркою властивості замовлення «час доставки».

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

• Технічне завдання з прототипами всіх екранів (каталог, конфігуратор, кошик, особистий кабінет)
• Дизайн-макети під ключ (десктоп + мобільна версія)
• Розробка на 1С-Бітрікс з використанням компонентів 2.0, HL-блоків, тегованого кешу
• Інтеграція з POS-системою (iiko, 1С:Розница, Poster)
• Налаштування часових вікон доставки та самовивозу
• Впровадження бонусної програми та промо-знижок
• Наповнення каталогу (контент-менеджмент)
• Тестування: функціональне, навантажувальне, сумісність з браузерами
• Документація: інструкція з адміністрування, опис API інтеграцій
• Навчання співробітників роботі з адміністративною панеллю
• Гарантійна підтримка 12 місяців

Технічні терміни

Композитний кеш — для каталогу та статичних сторінок. Конфігуратор торта працює цілком через AJAX — не кешується. Мікророзмітка Schema.org Product з NutritionInformation для появи в товарній видачі. Вартість проєкту залежить від варіанту візуалізації конфігуратора (шаблони або Canvas-рендер), обсягу інтеграцій з POS та кількості точок самовивозу.

У документації 1С-Бітрікс зазначено, що HL-блоки є найгнучкішим способом зберігання кастомних сутностей.

Наші інженери мають 10+ років досвіду роботи з 1С-Бітрікс та реалізували понад 50 проєктів для роздрібних мереж та пекарень. Ми гарантуємо стабільну роботу всіх модулів і надаємо сертифікат відповідності вимогам платформи. Отримайте консультацію по вашому проєкту — зв'яжіться з нами, обговоримо деталі та оцінимо обсяг робіт. Замовте розробку сайту пекарні вже сьогодні.

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

Ми бачимо десятки проєктів, де неправильна структура інфоблоків перетворює сайт на гальмо. Типовий сценарій: замовник просить «каталог товарів». Розробник створює один інфоблок 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 — замовте аудит продуктивності та міграцію на Бітрікс.