Розробка сайту доставки їжі на 1С-Бітрікс

Розробка сайту доставки їжі на 1С-Bitrix

Сайт доставки їжі — повнофункціональний e-commerce проект з особливостями общепиту. Тут не просто каталог та кошик: є зони доставки з різним часом та мінімумами, модифікатори страв (соус, розмір, добавки), інтеграція з кухонною системою для автоматичної передачи замовлень та стеження курьєра. 1С-Bitrix закриває основу через модуль sale та торговий каталог, а специфіку доставки наращуємо користувацькими обработчиками та інтеграціями.

Каталог меню: інфоблок з торговими пропозиціями

Каталог будується на торговому каталозі Bitrix. Кожна страва — елемент інфоблока з прив'язаним торговим каталогом. Категорії (піца, суші, бургери, напитки, десерти) — розділи інфоблока.

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

• Склад — текстове поле
• Вага — числова властивість (грами)
• Калорійність / БЖУ — числові властивості
• Час приготування — числова (хвилини), використовується при розрахунку часу доставки
• Позначки — множинний список (гостра, вегетаріанська, новинка, хіт)
• Фотографія — обов'язкова файлова властивість

Модифікатори через торові пропозиції (SKU). Піца 25 см та 35 см — дві торові пропозиції з різною ціною та вагою. Добавки (подвійний сир, бекон, грибы) — реалізуються через властивості торових пропозицій типу «список» з надбавкою. При виборі добавки JS-компонент на фронтенді перераховує підсумкову вартість.

Альтернативний підхід для масових модифікаторів (соуси до кожної страви) — окремий інфоблок «Добавки» зі зв'язком «багато до багатьох» через властивість прив'язки. На фронтенді при додаванні страви в кошик з'являється попап вибору добавок.

Промокоди та програма лояльності

Промокоди — штатний механізм модуля sale. Типи скидок:

• Фіксована сума при замовленні від N рублей
• Відсоток на все замовлення або категорію
• Безплатна доставка
• Подарунок при замовленні (додавання товара з нульовою вартістю)

Програма лояльності — накопичувальна. Внутрішній рахунок користувача (модуль sale, розділ «Рахунки покупців»): нарахування бонусів у відсотках від замовлення, списання при наступному замовленні. Правила нарахування настроюються через бізнес-логіку модуля без користувацької розробки.

Push-сповіщення про статус замовлення

При зміні статусу замовлення (прийнято → готується → в дорозі → доставлено) клієнт отримує сповіщення. Канали:

• SMS — через messageservice з підключеним провайдером (SMS.ru, SMSC)
• Email — шаблони поштових подій модуля sale
• Push у браузер — Web Push API (Service Worker + VAPID-ключі)

Push-сповіщення реалізуються користувацьким обработчиком подій OnSaleStatusOrder. При зміні статусу обработчик перевіряє підписку користувача та відправляє push через Web Push протокол. Підписка запитується при першому замовленні.

Кошик з зонами доставки

Кошик доставки їжі відрізняється від звичайного інтернет-магазину. Ключові особливості:

Зони доставки за геолокацією. Місто ділиться на зони, кожна з власними параметрами:

Зони зберігаються в highload-блоці з полігонами координат (GeoJSON). При оформленні замовлення клієнт вводить адресу, JavaScript відправляє запит в Яндекс.Геокодер (або DaData), отримує координати та визначає зону через point-in-polygon. Результат кешується по адресі.

Реалізація в sale: зони доставки підключаються як служби доставки (обработчик CDeliveryHandler). Користувацький обработчик отримує координати з властивості замовлення, визначає зону та повертає вартість та строки. Якщо адреса за межами зон — доставка недоступна, оформлення блокується.

Мінімальна сума замовлення перевіряється у двох місцях: на фронтенді (JS блокує кнопку оформлення) та на бекенді (обработчик OnSaleBeforeOrderAdd повертає помилку). Подвійна перевірка виключає обхід через прямий POST-запит.

Часові слоти. Клієнт вибирає «як можна швидше» або конкретний слот (12:00–12:30, 12:30–13:00). Доступні слоти генеруються динамічно: поточний час + час приготування найдовшої страви в кошику + час доставки по зоні. Слоти в минулому та перевантажені (ліміт замовлень на слот) — недоступні.

Інтеграція з кухонною системою

Передача замовлення в iiko або R-Keeper — обов'язкова інтеграція для автоматизації. Без неї менеджер вручну переносить замовлення з сайту в касову систему, втрачаючи час та допускаючи помилки.

Схема взаємодії з iiko:

1. Замовлення оформлене на сайті → подія OnSaleOrderAdd
2. Обработчик формує JSON-запит до iiko Transport API (/api/1/deliveries/create)
3. У запиті: позиції з SKU з довідника iiko (маппінг через властивість інфоблока «ID в iiko»), адреса, телефон, коментар, час доставки
4. iiko повертає ID замовлення, який зберігається у властивість замовлення Bitrix
5. Cron-агент раз у 2 хвилини опитує iiko по статусу замовлень (/api/1/deliveries/by_id)
6. При зміні статусу (готується → готово → в дорозі) — оновлюється статус замовлення в sale, запускаються сповіщення

Маппінг номенклатури — критичний етап. Кожній страві на сайті відповідає позиція в iiko. Зв'язок через властивість інфоблока «Зовнішній ID». При додаванні нової страви адміністратор повинен заповнити це поле — без нього замовлення не передасться. Валідація при збереженні елемента через обработчик OnBeforeIBlockElementUpdate.

Модифікатори передаються як вкладені об'єкти в JSON. Структура модифікаторів iiko та сайту повинна збігатися — маппінг настроюється при інтеграції та фіксується в документації.

Обработка помилок: якщо iiko недоступна — замовлення зберігається в Bitrix зі статусом «Чекає передачи на кухню». Cron-агент повторює спробу кожні 5 хвилин. Менеджер бачить такі замовлення в окремому фільтрі адміністративної панелі та може передати вручну.

R-Keeper працює аналогічно, але через XML-протокол (R-Keeper XML API) або проміжний сервіс (UCS Delivery). Принцип той же: маппінг, передача, опрос статусів.

Стеження курьєра

Базова реалізація — статуси замовлення без карти. Розширена — відображення курьєра на карті.

Для розширеної версії: курьєр використовує мобільний додаток (власний або сторонній — Яндекс.Маршрутизація, Bringo), який передає координати. Сайт отримує координати через API курьєрської служби та відображає на Яндекс.Карте в особистому кабінету клієнта. Оновлення — за запитом (кнопка «Оновити») або автоматично через polling кожні 30 секунд.

Етапи розробки

Разом: 12–14 тижнів. Основний ризик по строкам — інтеграція з кухонною системою: залежить від документації та стабільності API на стороні iiko/R-Keeper.