Разработка сайта доставки еды на 1С-Битрикс

Разработка сайта доставки еды на 1С-Битрикс

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

Каталог меню: инфоблок с торговыми предложениями

Каталог строится на торговом каталоге Битрикс. Каждое блюдо — элемент инфоблока с привязанным торговым каталогом. Категории (пицца, суши, бургеры, напитки, десерты) — разделы инфоблока.

Свойства элемента:

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

Модификаторы через торговые предложения (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 заказа, который сохраняется в свойство заказа Битрикс
5. Cron-агент раз в 2 минуты опрашивает iiko по статусу заказов (/api/1/deliveries/by_id)
6. При смене статуса (готовится → готов → в пути) — обновляется статус заказа в sale, срабатывают уведомления

Маппинг номенклатуры — критичный этап. Каждому блюду на сайте соответствует позиция в iiko. Связь через свойство инфоблока «Внешний ID». При добавлении нового блюда администратор обязан заполнить это поле — без него заказ не передастся. Валидация при сохранении элемента через обработчик OnBeforeIBlockElementUpdate.

Модификаторы передаются как вложенные объекты в JSON. Структура модификаторов iiko и сайта должна совпадать — маппинг настраивается при интеграции и фиксируется в документации.

Обработка ошибок: если iiko недоступна — заказ сохраняется в Битрикс со статусом «Ожидает передачи на кухню». Cron-агент повторяет попытку каждые 5 минут. Менеджер видит такие заказы в отдельном фильтре административной панели и может передать вручную.

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

Отслеживание курьера

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

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

Этапы разработки

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