Клиент заказал 300 грамм сыра и полкило помидоров к ужину на сегодня, к 19:00. Пока курьер едет, сыр на складе закончился, помидоры оказались по 480 грамм в упаковке, а слот на вечер уже переполнен. Обычный интернет-магазин на таких вводных ломается — а для продуктового это будни. E-grocery живёт в мире веса, сроков годности, слотов и замен, которых нет у магазина электроники или одежды.
Разберём особенности разработки продуктового интернет-магазина на 1С-Битрикс: как продавать весовой товар, учитывать сроки годности, показывать актуальные остатки, планировать слоты доставки и обрабатывать замены. И почему обмен с 1С здесь должен работать почти в реальном времени. Навести порядок в остатках и обмене помогает наша автоматизация продаж и склада на 1С.
Коротко
- E-grocery — это весовой товар, сроки годности, слоты доставки и замены, которых нет у обычного магазина.
- Наличие и цены должны обновляться почти в реальном времени, иначе продаётся отсутствующее и списанное.
- Слоты доставки имеют конечную вместимость — это отдельная логика планирования сборки и курьеров.
- 1С-Битрикс подходит: дробное количество, единицы измерения и обмен с 1С расширяются под специфику продуктов.
Чем e-grocery сложнее обычного магазина
На первый взгляд продуктовый магазин — тот же каталог и корзина. Но под капотом почти каждый привычный механизм работает иначе. Товар скоропортящийся, поэтому наличие и сроки годности критичны. Часть позиций весовая — количество дробное, а итоговая сумма известна только после сборки. Доставка привязана ко времени: свежее нельзя оставить у двери.
Добавьте огромный, быстро меняющийся ассортимент, частые повторные покупки и пиковые нагрузки в вечерние часы — и получится, что e-grocery сложнее классического e-commerce почти по всем осям. Именно поэтому продуктовый магазин нельзя собрать «как обычный» и надеяться, что специфика решится сама. Каждую особенность закладывают в архитектуру заранее.
Весовой товар и кратность
Ключевая особенность продуктов — весовой товар. Сыр, овощи, мясо продаются на развес, и обычная модель «штука = единица» тут не работает. В 1С-Битрикс это решают через дробное количество и единицы измерения торгового каталога: цена задаётся за килограмм, а покупатель выбирает вес.
- Цена за единицу измерения. Основа — цена за кг или литр, а сумма в корзине считается по фактическому количеству.
- Шаг и минимальная фасовка. Чтобы нельзя было заказать «5 грамм», задают шаг (100 г) и минимум.
- Штучный товар с известным весом. Для фасованного считают средний вес упаковки, а точный уточняют на сборке.
- Коррекция после сборки. Фактический вес отличается от заказанного, поэтому сумма пересчитывается — это нужно предусмотреть.
Именно поддержка дробного количества и последующей коррекции суммы отличает продуктовую корзину от обычной. Без неё клиент увидит одну сумму при заказе и другую при оплате — источник недовольства.
Сроки годности и партионный учёт
Продукты скоропортящиеся, и продавать то, что уже списано или не доедет свежим, недопустимо. Поэтому сроки годности и партионный учёт — не опция, а обязательная часть системы. Ведёт их 1С: партии, даты производства, списание просрочки. Сайт должен получать эти данные и не показывать негодный товар.
На практике это значит: товары с истёкшим сроком автоматически скрываются, для свежих категорий показывают дату или остаточный срок, а логика «сначала отгружаем то, что скорее испортится» живёт в учётной системе. Сайт здесь — витрина актуального состояния, а источник правды о партиях и сроках — 1С. Поэтому качество этой части напрямую зависит от обмена, о котором ниже, и от порядка в учёте — это зона нашей услуги аудита и оптимизации 1С.
Наличие в реальном времени
Обычный магазин переживёт обмен остатками раз в сутки. Для e-grocery это катастрофа: скоропортящиеся позиции расходятся за часы, и вчерашние остатки означают продажу того, чего уже нет. Поэтому наличие обновляется часто или запрашивается онлайн, а к моменту сборки заказанное должно реально лежать на полке.
Хорошая практика — показывать наличие в разрезе конкретного магазина или даркстора, откуда собирают заказ клиента, и учитывать резервы под уже оформленные заказы на выбранный слот. Тогда система не «продаёт» одну и ту же последнюю пачку двум покупателям. Чем актуальнее остатки, тем меньше замен и разочарований — это прямой фактор удержания клиента.
Слоты доставки и их вместимость
Продукты нельзя оставить у двери — клиент должен быть дома, поэтому доставка привязана к временным интервалам (слотам). Клиент выбирает «сегодня 18:00–20:00», и это принципиально отличает e-grocery от магазина, где доставка «в течение 3 дней».
Главная сложность — вместимость слота. На каждый интервал доступно конечное число заказов, зависящее от количества сборщиков и курьеров. Когда слот заполнен, его нужно закрывать, а клиенту предлагать другой. Это отдельная логика планирования:
- Расчёт вместимости. Сколько заказов реально собрать и развезти в интервал с учётом ресурсов.
- Резервирование при оформлении. Клиент, выбравший слот, занимает место — оно уменьшает доступность для других.
- Закрытие заполненных слотов. Переполненные интервалы скрываются, чтобы не набрать невыполнимых заказов.
- Зоны доставки. Разные районы обслуживаются разными слотами и складами.
Эту логику добавляют поверх стандартного оформления заказа Битрикс. Она тесно связана с наличием и остатками, поэтому её проектируют вместе с обменом — как единый механизм, а не отдельные модули.
Замены товаров на сборке
Даже при хорошем учёте часть заказанного может закончиться к моменту сборки. В e-grocery это норма, и на этот случай нужна логика замен. Клиент заранее решает, согласен ли он на замену и какую именно:
| Стратегия замены | Что делает сборщик | Что видит клиент |
|---|---|---|
| Согласен на аналог | Подбирает похожий товар | Уведомление о замене и новой сумме |
| Только тот же бренд | Ищет замену того же производителя | Подтверждение при отличии цены |
| Без замен | Исключает позицию из заказа | Возврат стоимости позиции |
| По согласованию | Связывается с клиентом | Решение в чате/звонке при сборке |
Замены требуют возможности редактировать состав заказа после оформления и пересчитывать сумму: вес и цена заменителя отличаются. Клиента обязательно уведомляют об изменениях. Это сложная механика, но без неё продуктовый магазин упирается в постоянные отмены. Логика редактирования заказа и обмена с 1С здесь пересекается с темой REST и вебхуков в Битрикс.
Каталог продуктов и умный фильтр
Продуктовый каталог большой, быстро меняется и требует богатых свойств. Покупатель ищет не «товар», а «безлактозное молоко до 200 ккал без сахара», поэтому умный фильтр (компонент catalog.smart.filter) по нутриентам и признакам критичен.
- Состав и БЖУ. Калорийность, белки, жиры, углеводы как свойства для фильтрации.
- Диетические признаки. Без сахара, безлактозное, веган, безглютеновое — частые запросы.
- Аллергены и температурный режим. Важны и для фильтра, и для сборки/доставки.
- Вес/объём, бренд, страна. Базовые характеристики для подбора и сравнения.
Богатые свойства и большой ассортимент нагружают каталог, поэтому фильтр и выдачу оптимизируют кэшированием и аккуратной индексацией свойств инфоблоков. Иначе на пике каталог начинает тормозить именно тогда, когда идёт основной трафик.
Повторные заказы и списки покупок
Продукты покупают регулярно и во многом одно и то же — это отличает e-grocery от разовых покупок. Значит, ценность повторного заказа огромна: механизмы, которые ускоряют рутинную закупку, прямо влияют на удержание и частоту покупок.
Что стоит заложить: быстрый повтор прошлого заказа одним действием, сохранённые списки покупок («на неделю», «завтрак»), избранное и историю. Клиент, у которого корзина собирается за минуту из привычного списка, возвращается чаще. Эти сценарии живут в личном кабинете и связаны с историей заказов из 1С — их удобно проектировать вместе с общей автоматизацией на 1С.
Обмен с 1С для скоропорта
Всё описанное — остатки, сроки, цены, заказы — упирается в обмен с учётной системой. Для e-grocery стандартного обмена CommerceML раз в день мало: остатки скоропорта нужно обновлять часто, а заказы отправлять в 1С сразу, чтобы их успели собрать к слоту.
Типовое решение — комбинация: базовый обмен каталогом и заказами по CommerceML плюс более частое (или онлайн) обновление остатков и цен по ключевым категориям через дополнительные механизмы. Заказы уходят в 1С немедленно после оформления, а статусы сборки и замен возвращаются на сайт. Надёжность и мониторинг этого обмена критичны — сбой означает продажу того, чего нет. Архитектуру такого обмена и работу с данными мы разбираем в статье про D7 ORM в Битрикс.
Производительность под пиковой нагрузкой
E-grocery живёт по расписанию: основной трафик приходит в предвечерние часы, когда люди заказывают ужин. Большой каталог, частые обновления остатков и всплеск заказов в узкое окно создают серьёзную нагрузку, к которой готовятся заранее.
- Кэширование каталога и фильтра. Тяжёлые выборки кэшируются, а динамика (остаток, цена) догружается точечно.
- Композитный сайт. Статическая часть страниц отдаётся мгновенно, снижая нагрузку на бэкенд.
- Готовность к пикам. Инфраструктура рассчитывается на вечерний всплеск, а не на средний трафик.
- Разделение нагрузки обмена. Частый обмен остатками не должен конкурировать за ресурсы с витриной.
Вопросы инфраструктуры под такую нагрузку мы подробно разбираем в материале про хостинг и инфраструктуру на BitrixVM.
Частые ошибки
- Обмен раз в сутки. Остатки скоропорта устаревают, магазин продаёт то, чего нет, — вал замен и отмен.
- Нет коррекции суммы. Весовой товар заказан, а пересчёт по факту не предусмотрен — суммы расходятся.
- Слоты без вместимости. Набирается больше заказов, чем реально собрать и развезти к времени.
- Игнор замен. Отсутствие товара на сборке ведёт к отмене вместо замены — потеря клиента.
- Бедный фильтр. Нельзя отобрать по диете и составу — покупатель не находит нужное в огромном каталоге.
- Нет учёта сроков годности. На витрине висит списанный или просроченный товар.
- Не выдержали пик. Каталог тормозит именно в вечерние часы основного спроса.
Чек-лист запуска
- Весовой товар настроен. Дробное количество, единицы измерения, шаг фасовки и коррекция суммы после сборки.
- Учтены сроки годности. Просрочка скрывается, для свежих категорий показан срок, партии ведёт 1С.
- Наличие актуально. Остатки обновляются часто, учитываются резервы под слоты.
- Слоты работают. Рассчитана вместимость, заполненные интервалы закрываются, есть зоны доставки.
- Замены реализованы. Клиент задаёт стратегию, состав заказа редактируется, сумма пересчитывается.
- Умный фильтр по нутриентам. Диета, состав, аллергены, БЖУ доступны для отбора.
- Обмен с 1С настроен. Частое обновление остатков, мгновенная отправка заказов, возврат статусов сборки.
- Готовность к пику. Кэширование, композит и инфраструктура рассчитаны на вечерний всплеск.
Вывод
Продуктовый интернет-магазин — это не «обычный магазин с едой», а система, где почти каждый механизм работает иначе. Весовой товар с дробным количеством, сроки годности, актуальные остатки, слоты доставки с вместимостью и логика замен — всё это нужно заложить в архитектуру с самого начала, а не докручивать потом.
1С-Битрикс справляется с e-grocery: инфоблоки и торговый каталог поддерживают дробное количество и богатые свойства, а недостающую специфику — слоты, замены, частый обмен — добавляют разработкой поверх стандартных механизмов. Ключ к рабочему продуктовому магазину — обмен с 1С почти в реальном времени и честное наличие: тогда к моменту сборки заказанное действительно лежит на полке.
