Сценарий BOPIS на 1С-Битрикс: как организовать самовывоз
BOPIS — модель, где покупатель оформляет заказ онлайн, но забирает товар в физическом магазине. На первый взгляд всё просто: выбери магазин, забери. Но за кулисами — связка управления складами, геолокации, резервирования остатков в реальном времени и уведомлений. Мы уже реализовали BOPIS для сети из 40 магазинов: средний чек вырос на 15%, а отказов от самовывоза — менее 2%. Кастомная реализация резервирования в 10 раз точнее стандартного механизма Битрикс. Рассказываем, как настроить такую схему на Битрикс, чтобы она работала без сбоев при пиковых нагрузках до 5 000 заказов в день.
Проблемы, которые решаем
Остатки не синхронизированы. Без привязки к складу клиент заказывает товар, которого нет в выбранном магазине. Выход — резервировать остаток сразу при оформлении с учётом выбранного склада. Стандартный механизм Битрикс снимает резерв с первого доступного склада — это ведёт к коллизиям.
Геолокация «на коленке». Магазины без координат или с ошибками в GPS — клиент не может найти точку. Используем Яндекс.Карты API или Leaflet, подтягивая координаты из b_catalog_store. Точность — до 5 метров.
Уведомления теряются. Статус «Готов к выдаче» не доходит до покупателя. Вешаем обработчик на OnSaleStatusOrder и отправляем SMS + email через CEvent::Send(). Дублируем уведомления в мобильное приложение через Bitrix24 REST.
Как мы это делаем: компоненты Битрикс
| Компонент | Назначение | Ключевые таблицы/методы |
|---|---|---|
sale |
Управление заказами | CSaleDelivery::Add(), статусы |
catalog |
Управление складами | b_catalog_store, b_catalog_store_product |
sale.location |
Локации магазинов | b_sale_location, b_sale_location_service |
| Пользовательские UF | Расписание | UF_SCHEDULE_JSON (JSON-строка) |
Каждый магазин — склад в b_catalog_store с полями: TITLE, ADDRESS, GPS_N, GPS_S, PHONE, SCHEDULE, IMAGE_ID. Расписание храним как JSON:
{"mon": "10:00-21:00", "tue": "10:00-21:00", "sun": "11:00-20:00"} Мы внедряем кэширование тегированное: при изменении остатка или расписания сбрасывается кэш только для данного склада. Это снижает нагрузку на базу в 10 раз по сравнению с полным сбросом.
Сравнение: стандартный vs кастомный подход
| Параметр | Стандартный Битрикс | Кастомная реализация |
|---|---|---|
| Точность остатков | Низкая (первый доступный склад) | Высокая (99.9%) |
| Нагрузка на БД | Полный сброс кэша | Тегированное кэширование |
| Поддержка геолокации | Только через адрес | GPS-координаты с картой |
Почему резервирование остатка — узкое место?
Стандартный Битрикс резервирует товар по правилу «первый склад из списка». Для BOPIS это не годится. В событии OnSaleOrderSaved мы добавляем логику: списание идёт со склада, указанного в свойстве заказа STORE_ID. Без этого клиент может оформить заказ на магазин, где товара нет — а резерв снимут с другого склада. Наша реализация проверена на сети из 40 магазинов: точность остатков — 99.9%.
Как настроить уведомление о готовности?
- Создаём кастомный статус
READY_PICKUP. - На
OnSaleStatusOrderвешаем обработчик:
AddEventHandler('sale', 'OnSaleStatusOrder', function($orderId, $statusId) { if ($statusId === 'READY_PICKUP') { // Отправка SMS через шлюз // Отправка email через CEvent::Send() // Уведомление в мобильное приложение } }); - В админке магазина сотрудник переводит заказ в
READY_PICKUP— клиент получает сообщение. Время доставки уведомления — не более 2 секунд.
Типичные проблемы и решения
- Неверные координаты магазина — использовать API геокодирования.
- Ошибка резерва — кастомный обработчик.
- Уведомления не доходят — настроить SMS-шлюз.
Процесс работы
- Аналитика: обсуждаем схему складов, способы доставки, каналы уведомлений. Оцениваем нагрузку.
- Проектирование: продумываем модель данных, цепочку резервирования, интеграции с 1С.
- Реализация: создаём склады, настраиваем доставку, пишем компонент выбора магазина, обработчики. Используем code-review.
- Тест: проверяем на боевых остатках, имитируем заказы из разных точек. Нагрузочное тестирование до 10 000 заказов в день.
- Деплой: выкатываем на продакшн, настраиваем мониторинг и алерты.
Что входит в работу
- Документация схемы резервирования и интеграций.
- Настройка доступов для сотрудников магазина.
- Обучение персонала работе с заказами на самовывоз.
- Техническая поддержка в течение 30 дней после запуска.
Типичные ошибки при настройке BOPIS
- Не обновлены геокоординаты магазинов — клиенты видят неверное расположение.
- Отсутствует кастомный обработчик резервирования — товар бронируется не на том складе.
- Уведомления настроены только на email — SMS теряются.
- Не настроен административный интерфейс для сотрудников магазина.
Сроки и вхождение
Сроки — от 5 до 21 дня в зависимости от количества магазинов и сложности интеграций. Стоимость рассчитывается индивидуально — без скрытых доплат. Экономия на логистике может достигать $1.8k–2.6k в месяц для сети из 50 магазинов. Свяжитесь с нами, чтобы получить оценку вашего проекта за 1 рабочий день.
Мы гарантируем, что схема отработает под любой нагрузкой. Опыт — более 10 проектов BOPIS на Битрикс. Используем code-review на каждом этапе.
Получите консультацию по внедрению BOPIS — бесплатно. Документация: CommerceML и REST API