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