Покупатель смотрит карточку товара и задаёт себе два вопроса: «есть ли он в наличии» и «когда я его получу». Если ответа нет прямо здесь, человек либо уходит искать у конкурента, либо оформляет заказ вслепую — а потом менеджер звонит с неприятным «этой позиции нет, будет через три недели». И то и другое бьёт по конверсии и по доверию.
В этой статье разберём, как вывести реальное наличие и понятный срок доставки прямо в карточку товара на 1С-Битрикс: откуда брать остатки, как учесть склады и регион, как посчитать срок через службы доставки и как всё это показать, не убив скорость страницы. Тема тесно связана с качеством обмена данными, поэтому попутно затронем автоматизацию продаж и склада на 1С.
Коротко
- Наличие и срок — главные факторы решения о покупке; их место в карточке, а не в корзине или в звонке менеджера.
- Остатки приходят обменом с 1С по CommerceML; показывайте их по складу отгрузки клиента, а не «суммой по всем».
- Срок доставки — это готовность товара плюс время службы доставки по региону; объединяйте их в одну понятную фразу.
- Считайте тяжёлое отдельно от композитного кэша: статика мгновенно, наличие и расчёт доставки — быстрой догрузкой.
Почему наличие и срок решают в карточке
Карточка товара — точка принятия решения. Здесь покупатель уже заинтересован и ищет причины либо купить, либо уйти. Наличие и срок доставки — два самых сильных таких фактора: они прямее цены влияют на «покупаю сейчас или нет». Если товар «в наличии, отгрузим завтра» — сомнений меньше; если статус пустой или «уточняйте у менеджера» — сомнения растут.
Отсутствие этой информации не делает покупателя терпеливее — оно делает его тревожнее. Человек не хочет оформлять заказ, чтобы через день услышать про перенос сроков. Поэтому вывод честного наличия и реального срока прямо в карточку — это не украшение, а работа над конверсией и снижением нагрузки на колл-центр, который иначе завален вопросами «а это есть?».
Что именно показывать покупателю
«Показать наличие» — на деле несколько взаимосвязанных сведений, и каждое отвечает на свой вопрос клиента.
- Статус наличия. Есть / мало / под заказ / нет — короткий понятный сигнал.
- Склад отгрузки. С какого склада поедет товар именно этому клиенту, а не «есть где-то на остатках».
- Готовность к отгрузке. Когда товар можно собрать: сегодня, завтра, через N дней (для позиций под заказ).
- Срок доставки. Сколько едет до адреса клиента выбранной службой.
- Способы получения. Самовывоз со склада, курьер, пункт выдачи — с их сроками.
Не обязательно вываливать всё сразу: рознице хватает статуса и ориентира по сроку, опту нужны точные остатки по складам. Набор данных стоит подбирать под аудиторию и группу клиента.
Откуда берутся остатки: обмен с 1С
Источник правды об остатках — учётная система. На сайт остатки попадают при обмене с 1С по протоколу CommerceML: выгрузка передаёт количество по складам, и торговый каталог 1С-Битрикс сохраняет их у товаров и торговых предложений. Карточка затем читает эти сохранённые значения.
Ключевой параметр здесь — частота обмена. Между выгрузками остаток на сайте — это снимок на момент последней синхронизации. Для медленно оборачиваемых товаров хватает выгрузки раз в несколько часов; для ходовых позиций обмен делают частым или дополняют онлайн-запросом остатка в 1С в момент открытия карточки. Настройку стабильного и достаточно частого обмена остатками мы закрываем услугой автоматизации продаж и склада на 1С, а тонкости надёжной интеграции по API разбираем в материале про REST, вебхуки и безопасность в Битрикс.
Наличие по складам и регион клиента
В распределённой торговле «есть в наличии» — вопрос «где именно есть». Один товар лежит на московском складе и отсутствует на региональном, а клиенту отгружают с ближайшего. Показывать сумму остатков по всем складам опасно: клиент видит «в наличии», а с его склада отгрузки товара нет.
Поэтому карточка должна знать регион посетителя — по выбранному городу, сохранённому в сессии, или по геолокации — и показывать наличие на складе отгрузки для этого региона. Это часть мультирегиональной архитектуры: города, привязка складов к регионам, региональные цены. Механику остатков и складов удобно проектировать вместе с моделью данных каталога; про грамотную работу с данными в ядре мы писали в статье про D7 ORM в Битрикс.
Из чего складывается срок доставки
Срок, который видит клиент, — это сумма двух независимых частей, и путать их нельзя.
| Часть срока | Что означает | Источник данных |
|---|---|---|
| Готовность товара | Когда товар можно собрать и передать в доставку | Остаток на складе, свойство «срок поставки» для позиций под заказ |
| Время доставки | Сколько едет от склада до адреса клиента | Служба доставки по региону и способу |
| Итоговый срок | Понятная клиенту фраза «получите к дате» | Сумма готовности и времени доставки |
Товар в наличии — готовность нулевая или «сегодня-завтра»; товар под заказ — готовность равна сроку поступления из свойства или графика поставок. Дальше прибавляется время службы доставки. Итог показывают человеческой фразой, а не двумя разрозненными числами, которые клиент должен складывать сам.
Службы доставки и расчёт срока
Время доставки до адреса считают службы доставки — их обработчики в 1С-Битрикс возвращают срок и стоимость по региону, весу и способу. Курьер по городу, пункт выдачи, транспортная компания до другого региона — у каждого свой срок. Чтобы показать его в карточке, обработчику передают регион клиента и параметры товара и получают ориентир.
Здесь два подводных камня. Первый — скорость: обращение к внешнему API службы доставки медленное, и дёргать его на каждый просмотр карточки нельзя. Второй — стабильность: внешний сервис может быть недоступен, и карточка не должна из-за этого ломаться. Оба решаются кэшированием ответа по ключу «товар + регион + способ» и аккуратной обработкой ошибок внешнего сервиса — подход, общий для любых внешних интеграций, который мы разбираем в статье про REST-вебхуки и безопасность.
Статусы наличия вместо голых цифр
Показывать точное число «на складе 1473 шт» рознице обычно не нужно и даже вредно — это выдаёт конкурентам данные об оборотах и не помогает покупателю. Полезнее пороговые статусы:
- «В наличии». Остаток выше порога — можно смело брать.
- «Осталось мало». Остаток ниже порога — лёгкий стимул не откладывать заказ.
- «Под заказ». На складе нет, но привезём — со сроком поступления.
- «Нет в наличии». С предложением аналога или уведомления о поступлении.
При этом опту точное количество нужно: он планирует крупную закупку и должен знать, хватит ли остатка. Разумное решение — пороговые статусы для гостя и розницы, точный остаток по складам — для авторизованного оптового клиента в его группе. Как разделять данные и цены по группам клиентов, мы подробно показываем в материале про разработку модуля под Битрикс, где логику статусов удобно вынести в отдельный компонент.
Что показывать, когда товара нет
Статус «нет в наличии» без продолжения — это тупик и потерянный заказ. Отсутствие товара нужно превращать в сценарий, который удерживает клиента:
- Срок поступления. Если товар под заказ — покажите ориентировочную дату из свойства или графика поставок.
- Уведомление о поступлении. Кнопка «сообщить, когда появится» с подпиской по e-mail.
- Аналоги. Предложите похожие товары, которые есть в наличии прямо сейчас.
- Предзаказ. Для ожидаемых позиций — возможность оформить заказ заранее.
Такой блок превращает разочарование в действие: клиент либо подписывается, либо берёт аналог, либо оставляет предзаказ — вместо того чтобы просто закрыть вкладку.
Скорость: композит, кэш и догрузка
Наличие и расчёт доставки — динамические данные: они зависят от региона, склады обновляются, службы доставки отвечают с задержкой. Если считать всё синхронно при каждом заходе, карточка будет медленной. Правильная архитектура разделяет статику и динамику.
- Статика — из композита. Описание, фото, характеристики отдаются из кэша композитного сайта мгновенно.
- Наличие и цена клиента — догрузкой. Персональные данные (склад региона, цена группы) подтягиваются отдельным быстрым запросом после отдачи страницы.
- Расчёт доставки — по требованию и с кэшем. Обращение к службе доставки кэшируется по ключу и не блокирует показ карточки.
- Остаток — из индексируемого поля. Чтение остатка идёт из подготовленных данных каталога, а не тяжёлым запросом на лету.
Такой подход держит карточку быстрой даже на большом каталоге, а инфраструктурную основу для этого мы описали в статье про хостинг и BitrixVM.
Реализация в 1С-Битрикс пошагово
Сборка наличия и сроков в карточке сводится к понятной последовательности. Названия пунктов зависят от редакции и версии, но логика такова:
- Настройте обмен остатками. Убедитесь, что CommerceML передаёт количество по складам достаточно часто и стабильно.
- Привяжите склады к регионам. Определите склад отгрузки для каждого региона и научите карточку понимать город клиента.
- Заведите статусы наличия. Пороговые правила «в наличии / мало / под заказ / нет» с точным остатком для опта.
- Добавьте свойство «срок поставки». Для позиций под заказ — источник даты поступления из 1С.
- Подключите расчёт доставки. Обработчик службы доставки возвращает срок по региону; ответ кэшируется.
- Разделите статику и динамику. Композит отдаёт карточку мгновенно, наличие и доставка догружаются.
- Оформите блок «нет в наличии». Уведомление о поступлении, аналоги, предзаказ.
- Проверьте на боевых данных. Разные регионы, товары в наличии и под заказ, недоступность службы доставки.
Частые ошибки
- Сумма остатков по всем складам. Клиент видит «в наличии», а с его склада отгрузки товара нет.
- Срок доставки без готовности товара. Показан только срок службы доставки, а товар при этом под заказ на три недели.
- Синхронный расчёт доставки. Обращение к внешнему API на каждом просмотре тормозит карточку и падает при недоступности сервиса.
- Точное количество всем. Розница не нуждается в цифре «1473 шт», а конкуренты узнают ваши обороты.
- «Нет в наличии» тупиком. Без аналогов, уведомления и предзаказа — это просто потерянный заказ.
- Редкий обмен остатками. Ходовой товар «есть» на сайте, но давно ушёл со склада — заказ срывается после оформления.
- Наличие ломает композит. Персональные данные попадают в общий кэш, и клиенты видят чужой регион или цену.
Чек-лист внедрения
- Обмен остатками настроен. Количество по складам приходит из 1С стабильно и достаточно часто.
- Склад отгрузки определяется. Карточка знает регион клиента и показывает наличие на нужном складе.
- Статусы наличия работают. Пороговые статусы для розницы, точный остаток для опта в его группе.
- Срок собран из двух частей. Готовность товара плюс время доставки, показаны одной понятной фразой.
- Расчёт доставки закэширован. Внешний API не дёргается на каждый просмотр и не роняет карточку.
- Скорость сохранена. Статика из композита, наличие и доставка догружаются отдельно.
- Сценарий «нет в наличии». Срок поступления, уведомление, аналоги, предзаказ на месте.
- Проверено на реальных данных. Разные регионы, склады, товары в наличии и под заказ.
Вывод
Наличие и срок доставки — это ответ на два главных вопроса покупателя в карточке товара. Дайте честный статус по складу отгрузки и понятный срок «получите к дате» — и конверсия вырастет, а колл-центр разгрузится от однотипных вопросов. Ключ к этому — качественный обмен остатками с 1С, привязка складов к регионам и аккуратный расчёт доставки, который не тормозит страницу.
Соберите статику из композитного кэша, а наличие, цену клиента и расчёт срока догрузите отдельно — тогда карточка останется быстрой даже на большом каталоге. А поскольку всё держится на данных из учётной системы, начните с настройки стабильной синхронизации складских остатков: без неё любые статусы в карточке будут врать.