Обмен остатками с несколькими складами и WMS в 1С-Битрикс

У вас не один склад, а несколько: центральный распределительный центр, магазины в двух-трёх городах, пункты выдачи и, возможно, товар «в пути» от поставщика. Каждая точка живёт своей жизнью — где-то товар есть, где-то закончился, где-то уже зарезервирован под чужой заказ. А на витрине покупатель видит одно короткое слово «в наличии» и уверен, что заберёт покупку сегодня. Стоит остаткам разойтись с реальностью — и начинается то, ради чего эту статью и читают: проданный дважды товар, отменённые заказы, звонки «а привезёте вообще?». Всё это лечится грамотно настроенным многоскладским учётом в Битрикс и правильным обменом остатками.

Это подробный гайд о том, как связать несколько складов, обмен остатками и витрину так, чтобы наличие было честным, а заказ уходил с правильного склада. Разберём, как устроены склады в модуле «Интернет-магазин», как остатки приходят по складам из 1С и WMS, как показывать наличие по пунктам выдачи, как выбирать склад отгрузки по приоритету и региону, что такое резервы и «честное» наличие, почему при нескольких каналах продаж растёт риск оверселлинга и как частый обмен остатками не уронить в производительность. Материал основан на нашей практике интеграций магазинов на 1С-Битрикс — по делу и без выдуманных цифр.

Что такое многоскладской учёт и зачем он магазину

Многоскладской учёт — это способ вести остатки товара отдельно по каждому месту хранения. Вместо одного числа «на складе 40 штук» система хранит матрицу: «в Москве 22, в Казани 11, в пункте выдачи 7». Для интернет-магазина это принципиально: наличие, резерв, срок доставки и даже цена доставки зависят от того, с какого именно склада поедет заказ. Пока склад один, вся эта сложность спрятана, но как только точек становится две и больше — учёт обязан различать их.

Модуль «Интернет-магазин» в 1С-Битрикс поддерживает несколько складов «из коробки»: их заводят в настройках торгового каталога, привязывают к остаткам, а компоненты каталога и оформления заказа умеют работать с наличием по складам. Но включить галочку мало — важно спроектировать, как склады соотносятся с реальной логистикой, как считается наличие для покупателя и по какому правилу выбирается склад отгрузки. Именно это проектирование, а не техника, определяет, будет магазин продавать честно или начнёт врать покупателю о наличии.

Когда одного склада уже недостаточно

Есть несколько типичных ситуаций, в которых плоский однопуловый учёт перестаёт работать и появляется потребность в складах:

• Розничная сеть с самовывозом. Покупатель хочет забрать товар в конкретном магазине, и наличие нужно показывать именно по этой точке, а не «в целом по компании».
• Распределительный центр плюс магазины. Основной запас лежит на РЦ, витринные остатки — в магазинах; отгрузка идёт то с РЦ, то из ближайшей точки.
• Региональная доставка. Склады в разных городах, и заказ выгоднее и быстрее отгрузить из ближнего к покупателю, а не гнать через всю страну.
• Пункты выдачи и постаматы. Часть запаса уже в точках выдачи, часть — на основном складе; их нужно различать по доступности и срокам.
• Товар в пути. Поставка от поставщика ещё не пришла, но её уже можно продавать как предзаказ — это отдельный «виртуальный» запас.

Что даёт правильный многоскладской учёт

Когда склады заведены и обмен остатками настроен, магазин получает не «галочку», а вполне ощутимые вещи:

• Честное наличие. Покупатель видит то, что реально можно купить и забрать, а не оптимистичную сумму по всем складам, часть которой уже в резерве.
• Наличие по точкам. «Есть в Москве сегодня, в Казани — под заказ» — покупатель сам выбирает удобный вариант.
• Оптимальную отгрузку. Заказ уходит с правильного склада — ближайшего, приоритетного или где есть весь состав, — что бережёт логистику и сроки.
• Меньше оверселлинга. Резервы списываются с конкретного склада, и один товар не продаётся дважды по разным каналам.

Как устроены склады в модуле «Интернет-магазин»

В 1С-Битрикс склад — это сущность модуля «Интернет-магазин» (точнее, торгового каталога). У склада есть название, статус активности, при необходимости — привязка к местоположению и к точке выдачи. Склады заводятся в административном разделе торгового каталога, и после этого остатки товаров можно распределять между ними. Пока многоскладской режим не включён, каталог работает с единственным «складом по умолчанию», и остаток — это одно число на товар или торговое предложение.

Ключевая настройка — режим учёта количества. Торговый каталог умеет работать в нескольких режимах: без учёта количества вообще, с учётом общего количества (один пул) и с учётом по складам (многоскладской режим). Именно последний включает распределение остатков по складам и списание резерва с конкретного склада. Переключение режима — это не косметика, а изменение того, как хранятся и считаются остатки, поэтому его выполняют осознанно и на копии, а не «на живом» каталоге в час пик.

Что важно про склад как сущность

• Активность. Склад можно временно выключить из продаж, не удаляя его и не теряя историю остатков.
• Привязка к местоположению. Склад можно связать с городом или регионом — это основа для выбора склада по геолокации покупателя.
• Связь с пунктом выдачи. Если товар выдаётся из магазина, склад сопоставляют с точкой самовывоза службы доставки.
• Служебные склады. Брак, витрина, транзит, резервный — их обычно исключают из «наличия для сайта», чтобы не показывать покупателю то, что продавать нельзя.

Привязка остатков к складам

Сердце многоскладского учёта — привязка количества к складу. В однопуловом режиме у товара (или торгового предложения) есть одно поле «количество». В многоскладском режиме количество хранится отдельными записями «товар × склад»: для каждой пары своё значение. Когда покупатель оформляет заказ, резерв списывается с конкретного склада, а не «вообще», и доступное наличие пересчитывается именно по этому складу.

Важно, что остатки почти всегда живут на уровне торгового предложения (SKU), а не карточки товара. «Синий M» может быть в Москве, а «синий L» — только в Казани, и это разные складские единицы. Поэтому базовая единица остатка — предложение, и обмен раскладывает количество по паре «SKU × склад». Если каталог с вариациями, эту механику важно держать в голове: подробно про сами вариации мы писали в разборе про торговые предложения (SKU) в 1С-Битрикс, а здесь добавляется ещё одно измерение — склад.

Из чего складывается остаток по складу

Отдельная тонкость — где именно ведётся резерв. Резерв может создаваться на сайте (модуль магазина откладывает товар при оформлении заказа) или в учётной системе (1С/WMS резервирует при создании документа заказа). Смешивать оба варианта без правила нельзя: получится либо двойной резерв, либо «дырка», когда ни одна система не отложила товар. До настройки чётко решают: кто хозяин резерва и как он влияет на доступное наличие, которое уезжает на витрину.

Единый пул или пул по складам

Первое стратегическое решение многоскладского магазина — как показывать наличие покупателю: единым пулом или по складам. Это не техническая мелочь, а выбор модели продаж, от которого зависит и витрина, и логистика, и обмен.

Единый пул остатков

Все склады, участвующие в онлайн-продажах, складываются в одно число «доступно». Покупатель не думает о складах — он видит «в наличии 35 шт», кладёт товар в корзину, а с какого склада отгрузить, решает уже система по своим правилам. Это простой и привычный для интернет-магазина сценарий: единая витрина, единая доставка, максимальный охват наличия. Минус — покупатель не знает, откуда поедет заказ, и для самовывоза такая модель не годится.

Пул по складам

Каждый склад продаётся отдельно. Покупатель выбирает город, точку или пункт выдачи, и наличие считается по конкретному складу. Это модель розничной сети и регионального магазина: «в наличии в вашем городе» честнее и понятнее, самовывоз работает из реальной точки. Минус — сложнее: витрина зависит от выбранного склада, обмен ведётся по всем точкам, а «размазанный» по складам товар может выглядеть как «нигде нет», хотя в сумме его достаточно.

Гибридная модель

На практике чаще всего работает комбинация. Онлайн-витрина показывает общий пул доступного («под доставку — 35 шт»), а рядом блок «наличие в пунктах выдачи» раскрывает остаток по конкретным складам для самовывоза. Так покупатель под доставку видит максимум, а под самовывоз — честную картину по точкам. Гибрид сложнее в настройке, но именно он закрывает и доставку, и самовывоз без вранья о наличии.

Обмен остатками по складам с 1С

В большинстве магазинов остатки приходят из 1С по обмену CommerceML — тому же протоколу, что переносит товары и цены. Общую механику этого обмена мы разбирали в отдельном руководстве про интеграцию магазина с 1С; здесь важно, что тот же обмен умеет передавать остатки не одним числом, а в разрезе складов.

Работает это так. В 1С есть свои склады (места хранения), и при выгрузке номенклатуры и остатков конфигурация может отдавать количество по каждому складу отдельно. В пакете обмена остатки приходят с указанием, к какому складу они относятся, а Битрикс раскладывает их по своим складам, сопоставленным со складами 1С. Если выгрузка складов не включена, остатки придут суммарно, и многоскладской учёт на сайте работать не будет, сколько складов ни заводи.

Что нужно, чтобы остатки поехали по складам

1. В 1С включена выгрузка складов и остатков по складам. Это настройка узла обмена: конфигурация должна отдавать количество в разрезе мест хранения, а не суммой.
2. На сайте заведены склады. Каждому складу 1С, который участвует в продажах, соответствует склад Битрикса.
3. Склады сопоставлены по идентификаторам. У складов есть стабильные коды, по которым обмен понимает, куда класть остаток. Без маппинга остатки «не найдут» свой склад.
4. Каталог в многоскладском режиме. Торговый каталог переключён на учёт по складам, иначе принимать разложенные остатки некуда.
5. Служебные склады отфильтрованы. Брак, транзит и витрина либо не выгружаются, либо исключены из «наличия для сайта».

Отдельно проговорите частоту. Товары и цены в CommerceML обычно гоняют реже (полный каталог — ночью), а остатки — отдельным лёгким пакетом гораздо чаще. В типовом обмене есть возможность выгружать только остатки, не трогая весь каталог, — именно эту «лёгкую» выгрузку и ставят на частое расписание. Про баланс частоты и нагрузки — ниже в разделах про частоту и производительность.

Синхронизация с WMS: складская система

Когда склад большой, к связке добавляется третий участник — WMS (Warehouse Management System), система управления складом. WMS ведёт адресное хранение (какой товар в какой ячейке), приёмку, размещение, комплектацию заказов и отгрузку. Для магазина её ценность в том, что WMS знает фактический остаток точнее всех: она фиксирует каждое физическое движение товара, а не «плановое» количество из учётной системы.

В типовой архитектуре роли разводят так: 1С остаётся мастером номенклатуры, цен и заказов, WMS управляет физическим складом и отдаёт оперативные остатки и статусы комплектации, а сайт показывает витрину и принимает заказы. Обмен между ними выстраивают цепочкой или через шину: заказ с сайта уходит в 1С, оттуда — задание на комплектацию в WMS, а обратно поднимаются фактические остатки и статус «собран / отгружен». Иногда сайт получает оперативные остатки напрямую от WMS, минуя 1С, чтобы наличие было максимально свежим.

Кто чей «хозяин» в связке сайт — 1С — WMS

Главная опасность связки трёх систем — рассинхрон и «кто последний записал». Если и 1С, и WMS правят остаток одного склада без правила, наличие начнёт скакать. Поэтому до внедрения фиксируют направление потоков: какой остаток считается истиной (обычно WMS для складов, где она работает), а какие системы его только читают. Обмен с WMS проектируют так же аккуратно, как с 1С: по стабильным идентификаторам, часто, с логами и защитой от оверселлинга.

Отображение наличия по складам на витрине

Как только остатки лежат по складам, встаёт вопрос вывода: что показать покупателю в списке каталога и на карточке. Здесь нет единственно верного ответа — способ зависит от выбранной модели (единый пул, по складам, гибрид) и от того, что важнее для конверсии: простота или прозрачность.

Варианты вывода наличия

• Суммарно «в наличии». Простейший вариант: складываем доступное по всем продающим складам и показываем «в наличии» или общее число. Подходит для единого пула и доставки.
• Статус вместо числа. Вместо точного количества — «много / мало / нет», чтобы не раскрывать точные остатки и не пугать словом «осталось 2».
• По складам списком. «Москва — есть, Казань — под заказ, СПб — нет». Честно и подробно, нужно для самовывоза и регионов.
• По складу пользователя. Определяем город покупателя (геолокация, выбор региона) и показываем наличие ближайшего склада, а остальное — свёрнуто.

Отдельно решите, как отображать «мало». Порог, с которого товар считается «мало», задаётся в настройках и влияет на психологию покупки: «осталось мало» подталкивает к заказу, но при многоскладском учёте «мало» на одном складе может соседствовать с «много» на другом. Логику агрегации статуса продумывают заранее, чтобы витрина не пугала дефицитом там, где товара в сумме достаточно.

Что важно не сломать при выводе

• Скорость каталога. Считать наличие по складам «на лету» для каждого товара в списке — дорого. Агрегированный остаток кэшируют, а тяжёлые расчёты выносят на момент обмена.
• Согласованность со фильтром. Фильтр «только в наличии» должен считать наличие по той же логике, что и вывод в карточке, иначе покупатель отфильтрует «в наличии», а внутри увидит «нет».
• Честность статуса. Доступное, а не физическое: даже красивый вывод по складам врёт, если в основе физический остаток с чужими резервами.

Наличие в карточке и пункты выдачи

Карточка товара — место, где покупатель принимает решение, и наличие здесь показывают подробнее, чем в списке. Хорошая карточка многоскладского магазина отвечает сразу на два вопроса: «можно ли заказать с доставкой» и «где забрать сегодня». Первый закрывает общий доступный остаток, второй — блок наличия по пунктам выдачи.

Блок «наличие в пунктах выдачи» — это разворачиваемый список складов-точек с их доступным остатком и, желательно, адресом и режимом работы. Покупатель сразу видит, в какой ближайшей точке товар есть в наличии, и может выбрать самовывоз именно оттуда. Если магазин работает с несколькими регионами, наличие удобно отсортировать по близости к покупателю: сначала его город, потом соседние.

Что показать в карточке при нескольких складах

1. Общий статус доставки. «Доступно к доставке: в наличии» — по суммарному доступному остатку продающих складов.
2. Наличие по точкам. Список пунктов выдачи с остатком: «есть», «мало», «под заказ», «нет».
3. Срок по каждому варианту. Самовывоз сегодня из точки, где есть; доставка завтра с РЦ; под заказ — со сроком поставки.
4. Действие. Кнопка «В корзину» для доставки и выбор точки для самовывоза — с честным наличием под каждый способ.

Самовывоз из конкретного склада

Самовывоз — главная причина, по которой магазины вообще заводят многоскладской учёт. При самовывозе покупатель забирает товар из конкретной точки, а значит, заказ должен жёстко привязаться к её складу: резерв списывается именно оттуда, и наличие этой точки уменьшается. Если самовывоз работает «из общего пула», случается классический провал: покупатель приезжает, а товара в выбранной точке нет, потому что он лежал на другом складе.

Правильная механика самовывоза выглядит так. Покупатель выбирает пункт выдачи, система показывает наличие именно этого склада, и в корзину попадает товар, доступный в этой точке. При оформлении заказ привязывается к складу точки, резерв уходит с него, а обмен передаёт в учётную систему, что заказ — на самовывоз из конкретного места. Дальше сотрудник точки видит заказ на сборку, откладывает товар, и покупатель забирает его без сюрпризов.

Тонкости самовывоза при нескольких складах

• Перемещение между складами. Если товара в выбранной точке нет, но он есть на РЦ, можно предложить «привезём в точку за N дней» — это уже перемещение, и его сроки честно показывают покупателю.
• Частичный самовывоз. Часть заказа есть в точке, часть — нет. Решите заранее: делить заказ, предлагать доставку остатка или ждать перемещения.
• Резерв под самовывоз. Товар в точке резервируется на разумный срок; если покупатель не забрал, резерв снимается и товар возвращается в продажу.
• Синхронизация с точкой. Сотрудник точки должен видеть заказ быстро — здесь частота обмена и уведомления особенно важны.

Выбор склада отгрузки: приоритет и регион

Для доставки (в отличие от самовывоза) склад отгрузки выбирает не покупатель, а система. Это одно из самых важных бизнес-правил многоскладского магазина: с какого склада поедет заказ, влияет на срок, стоимость логистики и на то, не «оголим» ли мы витринную точку. Правило проектируют заранее и реализуют в обработке заказа.

Типовые стратегии выбора склада

На практике редко используют одно правило — чаще каскад: сначала ищем склад в регионе покупателя, если там нет всего заказа — берём приоритетный РЦ, если и там неполно — дробим отгрузку или предлагаем часть под заказ. Каждый переход в этом каскаде — бизнес-решение с последствиями для сроков и затрат, поэтому его согласовывают с логистикой, а не «зашивают» по наитию.

Резервы и «честное» наличие

Мы уже несколько раз упомянули доступное наличие — пора разобрать его подробно, потому что это фундамент честной витрины. Физический остаток на складе почти никогда не равен тому, что можно продать: часть уже отложена под оформленные, но ещё не отгруженные заказы. Разница между физическим остатком и резервом и есть доступное количество — то самое «честное» наличие.

Резерв возникает в момент оформления заказа: система откладывает товар, чтобы его не купил кто-то ещё, пока заказ обрабатывается. При многоскладском учёте резерв всегда привязан к складу — резервируется не «вообще», а с конкретной точки, из которой поедет заказ. Поэтому доступное наличие считается по каждому складу: физический остаток склада минус резервы этого склада.

Жизненный цикл резерва

1. Оформление заказа. Товар резервируется с выбранного склада, доступное наличие уменьшается.
2. Обработка. Резерв держится, пока заказ собирают и готовят к отгрузке; товар «заморожен» от продажи другим.
3. Отгрузка. При отгрузке резерв превращается в списание: физический остаток уменьшается, резерв снимается.
4. Отмена или таймаут. Если заказ отменён или не оплачен в срок, резерв снимается, товар возвращается в доступное наличие.

Отдельно решают срок резерва. Держать товар зарезервированным бесконечно нельзя — неоплаченные заказы «съедят» весь доступный остаток. Поэтому вводят таймаут: если заказ не оплачен или не подтверждён за N часов, резерв снимается автоматически. Значение таймаута — компромисс между удобством покупателя и оборачиваемостью склада, и его подбирают под конкретный бизнес.

Отрицательные остатки и предзаказ

Не всё продаётся строго «в пределах наличия». Есть два штатных исключения — отрицательные остатки (продажа в минус) и предзаказ, — и оба при многоскладском учёте требуют отдельного решения по каждому складу.

Отрицательные остатки

Продажа «в минус» — это когда магазин принимает заказ, даже если доступный остаток уже ноль. Оправдано, когда товар всегда есть у поставщика и магазин уверен, что довезёт. Технически торговый каталог позволяет разрешить оформление заказа при нулевом или отрицательном остатке — но включать это глобально опасно: покупатель закажет то, чего нет, и на нескольких складах разом. Поэтому минус разрешают точечно: для конкретных товаров или складов, где поставка гарантирована.

Предзаказ и товар в пути

Предзаказ — более честный механизм: товар помечается «под заказ» со сроком поставки, и кнопка «В корзину» меняется на «Предзаказ». Это работает, когда есть «ожидаемый» остаток (товар едет от поставщика) или когда позиция принципиально поставляется под заказ. При нескольких складах важно не смешивать предзаказ с наличием: если на одном складе товар есть, а на другом только едет, покупателю показывают и «в наличии в Москве», и «под заказ, поставка через неделю» раздельно, а не усреднённый статус.

Общее правило: продажа в минус и предзаказ — это осознанный риск, а не «настройка по умолчанию». Их включают там, где бизнес готов отвечать за срок, и обязательно с честной коммуникацией сроков покупателю. Тихо продавать «в минус» на всех складах — прямой путь к отменам и жалобам.

Риск оверселлинга при нескольких каналах

Оверселлинг — продажа большего количества, чем реально есть, — главный кошмар многоскладской торговли. И чем больше каналов продаж, тем выше риск. Пока канал один (сайт) и обмен частый, оверселлинг редок. Но как только к сайту добавляются офлайн-касса, маркетплейсы и опт, один и тот же товар начинают продавать несколько систем одновременно, каждая со своим «снимком» остатка.

Классический сценарий: на складе одна последняя единица. Её видят и сайт, и маркетплейс, и касса. Пока обмен добежит до всех каналов, товар успевают продать дважды или трижды. Результат — отмена заказа, извинения, испорченная репутация, а на маркетплейсах ещё и штрафы за отмену. Многоскладской учёт усложняет картину: товар «размазан» по складам, и без единого расчёта доступного наличия каналы легко продают один и тот же остаток из разных пулов.

Как снижают риск оверселлинга

• Единый источник остатков. Все каналы берут доступное наличие из одного места (учётной системы или WMS), а не каждый из своего снимка.
• Высокая частота обмена. Чем быстрее остаток разлетается по каналам после продажи, тем меньше окно для двойной продажи.
• Резерв на общий пул. Продажа в любом канале сразу уменьшает доступное наличие для всех остальных.
• Буфер на «хвост». Для остродефицитных позиций держат небольшой буфер: последние единицы не выставляют во все каналы разом.
• Приоритет каналов. Решают, какой канал «важнее» на последней единице, чтобы отмена — если уж случилась — прошла в наименее болезненном канале.

Идеального решения без единого пула доступного наличия не существует: пока каждый канал считает остаток сам, оверселлинг — вопрос времени. Поэтому в мультиканальной торговле центральным элементом становится не сайт и не касса, а система, которая держит единый актуальный остаток и раздаёт его каналам. Часто эту роль берёт на себя 1С или WMS, иногда — отдельный сервис-интегратор.

Частота обмена остатками

Остатки — самые скоропортящиеся данные в магазине. Товар только что продали, и это нужно как можно быстрее отразить во всех каналах. Поэтому обмен остатками ставят на самое частое расписание из всех типов данных — гораздо чаще, чем каталог или даже цены.

Но «часто» не значит «весь каталог каждые пять минут». Гонять полный обмен постоянно — значит перегрузить и учётную систему, и сайт без всякой пользы. Правильный подход — разделить обмен по типам данных и частоте, а остатки выделить в отдельный лёгкий пакет, который передаёт только количество и только по изменившимся позициям.

Разумное расписание по типам данных

Для быстро расходящегося товара и мультиканальной торговли частоту остатков поднимают до предела разумного — вплоть до обмена по событию (продал — сразу разослал новый остаток). Для медленного товара хватает сверочного обмена раз в несколько минут или десятков минут. Разделять товары по «скорости» и гонять их с разной частотой — нормальная практика, экономящая ресурсы.

Производительность частого обмена

Частый обмен остатками — это постоянная нагрузка на сайт и учётную систему. Если его не спроектировать бережно, он либо начнёт тормозить витрину, либо будет отставать сам, сводя на нет всю идею «свежих остатков». Производительность здесь — не абстрактная забота, а прямое условие того, что частый обмен вообще возможен.

Приёмы бережного частого обмена

• Только изменённое. Передавать остатки не по всему каталогу, а по позициям, которые изменились с прошлого сеанса. Дельта вместо полного снимка.
• Пакетная запись. Обновлять остатки группами, а не по одной записи на запрос — иначе тысячи мелких операций «съедят» и базу, и время.
• Отключение лишних пересчётов. На время массового обновления остатков отключают тяжёлые обработчики и пересчёты, которые не нужны при смене одного количества.
• Точечная инвалидация кэша. Сбрасывать кэш только изменившихся товаров и разделов, а не весь каталог, иначе частый обмен будет постоянно «холодить» кэш.
• Композитный сайт и кэш витрины. Витрина отдаётся из кэша и не пересобирается на каждый заход, поэтому фоновый обмен не влияет на скорость страниц.
• Разнесение во времени. Тяжёлый полный каталог — ночью, лёгкие остатки — днём; они не конкурируют за ресурсы в пик.

Отдельная тема — фасетный индекс и фильтр «только в наличии». При многоскладском учёте наличие часто меняется, и если фильтр считает его «на лету» по всем складам, каталог будет тормозить. Агрегированный признак наличия кэшируют и обновляют вместе с остатками, а не пересчитывают на каждый запрос покупателя. Про устройство фасетного индекса и его связь с наличием мы подробно писали в материале про торговые предложения в 1С-Битрикс — при складах эта нагрузка только растёт.

Интеграция доставки со складом

Склад и доставка связаны теснее, чем кажется. Срок и стоимость доставки зависят от того, с какого склада едет заказ, а служба доставки, в свою очередь, диктует, какие пункты выдачи вообще доступны покупателю. Поэтому многоскладской учёт и интеграцию доставки проектируют вместе, а не по отдельности.

Например, при интеграции со службами вроде СДЭК или Boxberry пункты выдачи службы могут совпадать со складами-точками магазина или дополнять их. Заказ, отгружаемый с конкретного склада, рассчитывает срок и цену доставки от адреса этого склада до покупателя, а не «в среднем». Механику подключения таких служб мы разбирали в статье про доставку СДЭК и Boxberry, а здесь важно, что склад отгрузки — это вход в расчёт доставки.

Что связывает склад и доставку

• Адрес склада → расчёт срока. Служба доставки считает срок от точки отгрузки; выбор ближнего склада сокращает срок.
• Склад → тариф. Стоимость доставки зависит от расстояния, а значит, от склада отгрузки.
• Пункты выдачи ↔ склады. Точки самовывоза магазина сопоставляются с пунктами выдачи службы, чтобы наличие и адрес совпадали.
• Дробление заказа. Если заказ едет с двух складов, доставок может быть две — это влияет и на цену, и на коммуникацию с покупателем.

Маппинг складов и идентификаторы

Как и в любом обмене, невидимая, но критичная часть многоскладского учёта — соответствие складов и стабильность идентификаторов. Чтобы остатки из 1С или WMS ложились на нужный склад Битрикса, у складов должны быть стабильные коды, по которым обмен их сопоставляет. Если коды «плывут» или маппинг не задан, остатки либо не найдут свой склад, либо разложатся неправильно.

Маппинг складов делают явным: каждому складу учётной системы ставят в соответствие склад сайта. Это разовая настройка, но за ней следят: при добавлении нового склада в 1С его нужно завести и сопоставить на сайте, иначе его остатки «повиснут». Особенно аккуратно — с переименованием и пересозданием складов в учётной системе: если у склада поменялся идентификатор, обмен перестанет узнавать его остатки.

Практическое правило: до первого многоскладского обмена сверьте список складов на обеих сторонах и зафиксируйте соответствие письменно. Проверьте на тестовой копии, что остатки каждого склада ложатся именно туда, куда должны, а повторный обмен не путает склады и не сваливает всё в один пул. Ошибку маппинга дешевле поймать на копии, чем разбирать «слипшиеся» остатки на боевом каталоге.

Пошаговая настройка многоскладского обмена

Когда модель наличия выбрана и данные готовы, настройка складывается в понятную последовательность. Часть шагов делается в учётной системе, часть — на сайте, и порядок важен: склады и маппинг должны появиться до первого обмена остатками.

На стороне учётной системы (1С / WMS)

1. Наведите порядок в складах. Актуальный список мест хранения без дублей; служебные склады (брак, транзит) явно отделены от продающих.
2. Включите выгрузку остатков по складам. В узле обмена настройте передачу количества в разрезе складов, а не суммарно.
3. Определите резервы. Решите, где ведётся резерв и как он влияет на доступный остаток, который уходит на сайт.
4. Настройте частоту. Отделите лёгкую выгрузку остатков от полного каталога и поставьте её на частое расписание.

На стороне сайта (1С-Битрикс)

1. Включите многоскладской режим. Переключите торговый каталог на учёт количества по складам.
2. Заведите склады. Создайте склады, соответствующие продающим складам учётной системы; привяжите их к местоположениям и точкам выдачи.
3. Сопоставьте склады. Пропишите маппинг «склад учётной системы → склад Битрикса» по стабильным кодам.
4. Настройте вывод наличия. Определите, что показывать: суммарно, по складам или гибрид; настройте карточку и блок пунктов выдачи.
5. Опишите правило отгрузки. Реализуйте выбор склада (регион → приоритет → наличие целиком) в обработке заказа.
6. Настройте самовывоз. Свяжите точки выдачи со складами, чтобы заказ привязывался к складу выбранной точки.

Первый пробный обмен

Первый многоскладской обмен запускают только на тестовой копии. Прогоняют выгрузку и проверяют: разложились ли остатки по нужным складам, корректно ли считается доступное наличие с учётом резервов, показывает ли карточка наличие по точкам, уходит ли резерв с правильного склада при оформлении заказа, выбирается ли склад отгрузки по заданному правилу. На копии всплывает почти всё — и чинить это здесь на порядок дешевле, чем на живой витрине.

Мониторинг и сверка остатков

Частый обмен остатками работает надёжно только тогда, когда за ним следят. Обмен по событию и вебхукам не даёт стопроцентной гарантии доставки: сеть моргнула, сайт был недоступен, пакет потерялся — и остаток одного склада «застрял» на старом значении. Без мониторинга такое расхождение всплывёт нескоро — по жалобам покупателей и отменам.

Что должно быть в мониторинге

• Логи обмена. Каждый сеанс пишет, сколько позиций и по каким складам обновлено, какие ошибки были.
• Сверочный обмен. Поверх частых событийных сеансов — полная сверка остатков по расписанию (например, раз в сутки), которая устраняет накопленные расхождения.
• Уведомления. Если обмен упал или давно не проходил, ответственный получает сигнал, а не узнаёт о проблеме от покупателей.
• Контроль отставания. Метрика «когда последний раз обновлялись остатки склада» — сигнал, что канал застрял.
• Отчёт по расхождениям. Периодическая сверка сайт ↔ учётная система по остаткам, чтобы ловить систематические ошибки маппинга.

Логика здесь та же, что в любом надёжном обмене: событийные сеансы дают скорость, сверочный обмен по расписанию страхует от пропусков, а мониторинг превращает «тихий сбой» в заметный сигнал. Для многоскладского учёта это особенно важно — расхождение на одном складе легко не заметить в общей массе, пока оно не выльется в отменённый заказ.

Мини-кейс: сеть с самовывозом

Чтобы теория стала предметной, коротко опишем типичный для нас сценарий (детали обобщены, без названий клиентов — по редполитике мы не раскрываем проекты без согласия).

Ситуация. Розничная сеть с центральным РЦ и магазинами в нескольких городах вела витрину на 1С-Битрикс с единым остатком. Наличие показывалось «в целом по компании», самовывоз работал из общего пула, и покупатели регулярно приезжали в магазин за товаром, которого в этой точке не было. Онлайн-заказы к тому же «оголяли» витринные остатки магазинов.

Задача. Перевести магазин на многоскладской учёт, показывать честное наличие по точкам, привязать самовывоз к складу конкретного магазина и задать правило отгрузки для доставки, не уронив скорость каталога.

Решение. Сначала навели порядок в складах 1С и отделили служебные от продающих. Включили выгрузку остатков по складам и сопоставили склады с точками на сайте. На сайте перевели каталог в многоскладской режим, настроили вывод «наличие в пунктах выдачи» в карточке и общий доступный остаток под доставку. Самовывоз привязали к складу выбранной точки: резерв стал уходить именно с неё. Для доставки описали каскад «регион → приоритетный РЦ → наличие целиком», а витринным складам задали неснижаемый буфер, чтобы онлайн не опустошал офлайн. Остатки вынесли в отдельный частый обмен, поверх — ночную сверку и мониторинг.

Результат. Наличие на витрине стало соответствовать реальной картине по точкам, самовывоз перестал приводить к «приехал — а нет», а заказы поехали с правильных складов. Точные цифры по каждому проекту разные и зависят от исходного состояния данных, поэтому обещать «рост в N раз» было бы некорректно — но исчезновение отмен из-за расхождения остатков и жалоб на самовывоз клиенты отмечают сразу.

Частые ошибки многоскладского учёта

Большинство проблем повторяются из проекта в проект. Зная их заранее, вы сэкономите дни отладки и избежите отменённых заказов:

• Включили многоскладской режим сразу на бою. Переключение хранения остатков на живом каталоге в рабочее время — самая дорогая ошибка. Лечится одним правилом: сначала тестовая копия.
• 1С отдаёт остатки суммарно. На сайте склады заведены, а выгрузка идёт одним числом — многоскладской учёт не работает. Проблема на стороне 1С, не Битрикса.
• Нет маппинга складов. Остатки не находят свой склад и валятся в один пул или «повисают». Склады не сопоставлены по стабильным кодам.
• Показывают физический остаток вместо доступного. На витрине видно количество с чужими резервами, и товар продаётся дважды.
• Самовывоз из общего пула. Покупатель приезжает в точку, а товара там нет — он лежал на другом складе. Самовывоз должен привязываться к складу точки.
• Двойной резерв. И сайт, и 1С резервируют товар без согласования — доступный остаток занижается или, наоборот, теряется, и случается оверселлинг.
• Витринные склады «оголяются» онлайном. Правило отгрузки всегда берёт ближайший магазин, и офлайн-покупателям ничего не остаётся. Нужен буфер или исключение витринных складов.
• Тяжёлый обмен вместо лёгкого. Остатки гоняют вместе с полным каталогом, поэтому не могут делать это часто — и наличие отстаёт, растёт оверселлинг.
• Оверселлинг из-за нескольких каналов. Сайт, касса и маркетплейсы считают остаток каждый по-своему без единого пула доступного наличия.
• Нет мониторинга. Обмен остатками одного склада тихо застрял, а узнали через неделю по отменам. Нужны логи, сверка и уведомления.
• Продажа в минус включена глобально. Магазин принимает заказы на то, чего нет, по всем складам разом — вместо точечного разрешения там, где поставка гарантирована.

Чек-лист перед запуском

Короткий список, по которому удобно свериться до включения многоскладского обмена на боевом сайте:

• Список складов в учётной системе актуален; служебные склады отделены от продающих.
• В 1С включена выгрузка остатков по складам, а не суммарно.
• На сайте включён многоскладской режим учёта количества.
• Склады сайта заведены и сопоставлены со складами учётной системы по стабильным кодам.
• Выбрана модель наличия: единый пул, по складам или гибрид — и она реализована в выводе.
• На витрину выводится доступное (честное) наличие, а не физический остаток.
• Определён хозяин резерва и срок автоснятия резерва по неоплаченным заказам.
• Описано правило выбора склада отгрузки; витринным складам задан буфер.
• Самовывоз привязан к складу выбранной точки; наличие по точкам честное.
• Обмен остатками вынесен в отдельный лёгкий пакет и поставлен на частое расписание.
• Настроены логи, сверочный обмен по расписанию и уведомления об ошибках.
• Первый обмен отлажен на тестовой копии; остатки ложатся на нужные склады, повторный сеанс не путает пулы.

Когда многоскладской учёт нужен, а когда нет

Многоскладской учёт — не самоцель, а ответ на конкретную логистику. Полезно честно понимать, когда он окупается, а когда добавит сложности без пользы.

Когда он точно нужен

• Есть самовывоз из нескольких точек, и наличие важно показывать по каждой.
• Склады в разных регионах, и заказ выгодно отгружать из ближнего к покупателю.
• Розничная сеть: витринные остатки магазинов и запас РЦ нужно различать.
• Продажи идут по нескольким каналам, и без единого пула остатков растёт оверселлинг.
• Работает WMS, и её точные оперативные остатки нужно показывать на сайте.

Когда можно обойтись проще

• Склад фактически один, отгрузка всегда из одной точки — многоскладской режим только усложнит учёт.
• Нет самовывоза и региональной логистики: покупателю всё равно, откуда едет заказ.
• Магазин на этапе запуска — сначала проверить спрос на едином пуле, а склады добавить, когда появится реальная логистика.
• В учёте пока нет порядка со складами: сначала навести его в 1С, потом связывать с сайтом.

И обратная сторона ожиданий: многоскладской учёт переносит и раскладывает остатки, но не наводит порядок в вашей логистике и не принимает за вас решения. Если в учётной системе склады заведены хаотично, а резервы не описаны, ровно этот хаос приедет на витрину. Структуру складов, правила отгрузки и модель наличия определяете вы; обмен лишь честно отражает то, что вы решили.

Вывод

Многоскладской учёт в 1С-Битрикс — это не «галочка учёта по складам», а связная система: остатки в разрезе складов, честное доступное наличие с учётом резервов, продуманный вывод по точкам, правило выбора склада отгрузки и частый бережный обмен остатками с 1С и WMS. Техника здесь вторична — модуль «Интернет-магазин» умеет вести склады из коробки. Первично — проектирование: какую модель наличия показывать, где живёт резерв, по какому правилу уходит заказ и как не поймать оверселлинг при нескольких каналах.

Наведите порядок в складах учётной системы, включите выгрузку остатков по складам, сопоставьте склады по стабильным кодам, выведите на витрину доступное наличие, опишите правило отгрузки и вынесите остатки в частый лёгкий обмен со сверкой и мониторингом — и магазин перестанет врать покупателю о наличии. Витрина покажет честную картину по точкам, самовывоз перестанет подводить, а заказы поедут с правильных складов. Это и есть та надёжность, ради которой затевают многоскладской учёт.