Клиент из Новосибирска находит нужный товар, видит «в наличии», оформляет заказ — а через день менеджер сообщает, что позиции на местном складе нет, отгрузка из Москвы, срок плюс неделя. Такой опыт разрушает доверие сильнее, чем честное «нет в наличии» с самого начала. В распределённом бизнесе поиск и каталог, показывающие наличие «вообще по компании», а не по складу клиента, — источник сорванных заказов и негатива.
Разберём, как сделать поиск и выдачу каталога на 1С-Битрикс с учётом региона клиента и остатков по складам: как определить регион, привязать к нему склад, показать реальное наличие в выдаче и отсортировать товары по доступности. И почему всё это держится на качестве обмена с 1С. Тема тесно связана с автоматизацией склада, которую мы закрываем услугой автоматизации продаж и склада на 1С.
Коротко
- Показывайте наличие по складу клиента, а не «вообще» — иначе клиент заказывает то, что ему не отгрузят.
- Определяйте регион и сопоставляйте ему склад по умолчанию; давайте пользователю сменить город.
- Сортируйте выдачу по доступности: в наличии на складе клиента — вверх, «под заказ» — со сроком.
- Актуальность наличия держится на частом и надёжном обмене остатками с 1С.
Почему «наличие вообще» вредит продажам
Многие магазины показывают один флажок «в наличии» на весь бизнес, суммируя остатки по всем складам. Для компании с одним складом это нормально. Но как только складов несколько и они разнесены по регионам, такой подход начинает вредить: клиент видит доступность, которой у него нет, оформляет заказ и упирается в реальность логистики.
Результат — сорванные сроки, отменённые заказы и подорванное доверие. Причём страдает и обратный сценарий: товар есть на складе клиента, но общий флажок показывает «мало» или «нет» из-за нулей на других складах, и продажа не случается. Правдивая, привязанная к региону картина наличия выгоднее для всех: клиент принимает решение по реальным данным, а магазин не собирает заведомо невыполнимые заказы.
Как определить регион пользователя
Первый шаг регионального поиска — понять, откуда клиент. Обычно используют комбинацию сигналов:
- Явный выбор. Переключатель города/региона — самый надёжный сигнал; выбор запоминают в cookie.
- Определение по IP. Первичная догадка при первом визите, которую пользователь может исправить.
- Профиль клиента. Для авторизованного B2B-клиента регион и склад отгрузки берут из его данных и договора.
- Сохранённый выбор. При повторном визите используют ранее выбранный регион.
Практичная схема: при первом заходе предложить регион по IP, дать явно сменить город и запомнить решение. Для оптовых клиентов приоритет за закреплённым в учётной системе регионом и складом. Мультирегиональная логика — отдельная архитектурная тема; смежные вопросы масштабирования мы затрагиваем в статье про хостинг и инфраструктуру BitrixVM.
Склад по умолчанию для региона
Определив регион, сайт должен сопоставить ему склад, по которому считается наличие и сроки. Это и есть склад по умолчанию для региона — основной пункт отгрузки клиентам данной географии.
Связь «регион — склад» задают как справочник соответствий. Иногда региону соответствует несколько складов с приоритетом, иногда — один. Главное, чтобы система однозначно знала, по какому складу показывать наличие конкретному посетителю.
Остатки по складам в торговом каталоге
Чтобы показывать наличие по складу, нужны остатки в разрезе складов. Торговый каталог 1С-Битрикс это поддерживает: у товара есть остатки по нескольким складам, а не одно суммарное число. Эти данные — фундамент всей региональной логики.
- Складской учёт включён. В торговом каталоге ведутся остатки по нескольким складам.
- Склады заведены. Каждый физический склад отгрузки представлен в системе.
- Остатки актуальны. Значения обновляются обменом из 1С с нужной частотой.
- Связь со складом клиента. Наличие берётся по складу, сопоставленному региону покупателя.
Без корректных остатков по складам региональный поиск построить нельзя — это данные, вокруг которых крутится всё остальное. Работу с такими данными на уровне выборок удобно вести через современный слой доступа, о котором мы пишем в материале про D7 ORM в Битрикс.
Наличие в выдаче поиска и каталога
Когда регион, склад и остатки на месте, их выводят в результаты. И в поиске, и в списке каталога, и в карточке товара наличие показывают применительно к клиенту:
- Статус по складу клиента. Не «есть на остатках», а «есть на вашем складе» / «нет на вашем складе».
- Остаток по нескольким складам. Если клиент готов забрать с разных складов — видно, где сколько.
- Срок поставки. Для позиций не с местного склада — ориентир по сроку, а не глухое «нет».
- Единая логика везде. Одинаковый расчёт наличия в поиске, каталоге и карточке, без противоречий.
Важно, чтобы наличие считалось одинаково во всех точках: если в поиске товар «в наличии», а в карточке «нет», доверие рушится. Единый механизм расчёта доступности — обязательное условие.
Сортировка по доступности
Показать наличие мало — выдачу стоит ещё и упорядочить по доступности. На большом каталоге без этого в топе легко оказываются позиции, которых на складе клиента нет.
| Статус товара | Позиция в выдаче | Что показать |
|---|---|---|
| Есть на складе клиента | Вверху | «В наличии», количество |
| Есть на другом складе | Ниже | Срок поставки |
| Только под заказ | Ещё ниже | «Под заказ», срок |
| Снят / нет нигде | В конце или скрыт | Аналоги |
Такая сортировка ставит на первое место то, что клиент реально может купить сейчас, и мягко опускает менее доступное, не пряча его полностью. Это повышает и конверсию, и удовлетворённость.
Товары не с того склада: статусы
Отдельный вопрос — что делать с товарами, которых нет на складе региона, но есть на других. Соблазн просто их спрятать вреден: покупатель видит обеднённый ассортимент и уходит. Лучше показать честный статус.
- «Нет на вашем складе, есть на центральном». С указанием срока поставки — клиент решает, ждать или нет.
- «Под заказ». Для позиций, которых нет в наличии нигде, но которые возят под клиента.
- Аналоги. Для отсутствующих товаров предложить похожие, доступные на складе клиента.
- Уведомление о поступлении. Дать подписаться на появление товара на нужном складе.
Честный статус с наличием по другим складам и сроком почти всегда работает лучше, чем пустота: он сохраняет ассортимент в глазах клиента и даёт ему варианты.
Регион, цена и группы клиентов
Регион часто влияет не только на наличие, но и на цену. В распределённом бизнесе условия могут различаться: региональные цены, логистические надбавки, локальные акции. Это реализуется через типы цен и, при необходимости, привязку к региону или группе клиента.
Поэтому региональный поиск нередко идёт в связке с региональным ценообразованием: клиент видит и своё наличие, и свою цену. Для B2B к этому добавляются цены по группам клиентов — дилерские, оптовые, розничные. Итоговая выдача учитывает и склад региона, и группу авторизованного клиента, показывая ему персональную картину доступности и стоимости.
Обмен с 1С и актуальность остатков
Вся региональная логика держится на одном условии — актуальности остатков. Остатки по складам приходят на сайт обменом с 1С, и если обмен идёт редко или с ошибками, поиск будет показывать неверную доступность, сколько бы правильно ни была настроена логика.
Поэтому ключевые вопросы — частота и надёжность обмена. Для товаров с быстрым оборотом остатки нужно обновлять чаще, иногда почти в реальном времени, чтобы «в наличии» на сайте соответствовало складу. Безопасную и надёжную передачу таких данных между системами мы разбираем в статье про REST, вебхуки и безопасность в Битрикс, а предсказуемое обновление интеграций — в материале про CI/CD и деплой.
Производительность и кэширование
Учёт склада и региона добавляет условия в выборку товаров, и на большом каталоге это может ударить по скорости, если не позаботиться о производительности.
- Индексированные поля. Остатки по складам и привязку региона держат так, чтобы фильтрация шла быстро.
- Кэш тяжёлых расчётов. Дорогие вычисления доступности кэшируют, а не считают на каждый запрос.
- Динамика поверх статики. Наличие и цену клиента отдают поверх закэшированной страницы, а не пересобирают всё.
- Композитный сайт. Статическая часть каталога отдаётся мгновенно, региональные данные догружаются.
Без этого региональная логика начнёт тормозить выдачу — особенно на каталогах в десятки и сотни тысяч позиций. Скорость каталога и корректность наличия должны идти рука об руку.
Частые ошибки
- Наличие «вообще». Один флажок на весь бизнес — клиент заказывает то, что ему не отгрузят.
- Нет смены региона. Определили по IP и не дали исправить — клиент заперт в чужом городе.
- Разное наличие в поиске и карточке. Разные механизмы расчёта дают противоречия и рушат доверие.
- Скрытие товаров не с того склада. Ассортимент выглядит беднее, продажи теряются.
- Редкий обмен остатками. Наличие на сайте не соответствует складу, «в наличии» оказывается ложью.
- Нет сортировки по доступности. В топе выдачи — недоступные клиенту позиции.
- Региональная логика тормозит каталог. Условия по складам не оптимизированы и не кэшируются.
Чек-лист внедрения
- Регион определяется. По IP, выбору и профилю; пользователь может сменить город, выбор запоминается.
- Склад привязан к региону. Есть справочник соответствий «регион — склад по умолчанию».
- Остатки по складам ведутся. В торговом каталоге включён складской учёт, склады заведены.
- Наличие едино везде. Одинаковый расчёт доступности в поиске, каталоге и карточке.
- Сортировка по доступности. В наличии на складе клиента — вверх, «под заказ» — со сроком.
- Честные статусы. Для товаров не с местного склада — срок, аналоги, подписка на поступление.
- Обмен остатками надёжен. Частота обновления соответствует обороту товаров.
- Скорость сохранена. Региональные условия оптимизированы и кэшируются, работает композитный сайт.
Вывод
Поиск и каталог, которые учитывают регион и наличие по складам, — это про честность перед клиентом и про меньшее число сорванных заказов. Определите регион, привяжите к нему склад по умолчанию, показывайте наличие и сроки применительно к покупателю и сортируйте выдачу по доступности. Товары не с местного склада не прячьте, а показывайте с честным статусом и сроком.
Технически всё это опирается на складской учёт торгового каталога 1С-Битрикс и на качество обмена остатками с 1С: логика хороша ровно настолько, насколько актуальны данные о наличии. Настройте надёжный и достаточно частый обмен, позаботьтесь о производительности через кэш и композитный сайт — и региональный поиск станет сильным конкурентным преимуществом вашего распределённого бизнеса.
