Обмен 1С с несколькими складами: остатки, доступность и заказы

Если в 1С товар лежит на нескольких складах, стандартный обмен с сайтом обычно не показывает остаток по каждому складу отдельно: количества суммируются в одно значение, а склад в заказе покупателя не подставляется. Чтобы покупатель видел доступность по конкретной точке, а менеджер получал заказ с нужным складом, нужно заранее определить, какие склады участвуют в обмене, как их различать на сайте и кто отвечает за доработку выгрузки. Ниже — карта складских сценариев, сравнение подходов, учебный пример и проверяемый чек-лист.

Что решает обмен с несколькими складами и где проходят границы задачи

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

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

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

Прежде чем что-то настраивать, стоит развести три вопроса, которые часто объединяют в один.

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

Второй — витринный. Что из этих данных показывать покупателю и в каком виде. Здесь решение принимает бизнес: показывать ли конкретный склад, или только факт наличия, или срок поставки.

Третий — технический. Как эти данные доедут из 1С на сайт и как заказ вернётся обратно с нужным складом. Это задача технической интеграции.

Если смешать эти вопросы, обсуждение уходит в сторону: технические детали обсуждают раньше, чем определены правила, а правила меняют уже после начала работ.

Кто отвечает за результат

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

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

Как устроен стандартный обмен и почему остатки часто суммируются

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

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

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

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

Если обмен уже работает, но данные расходятся, полезно сначала разобрать типовые причины.

Карта складских сценариев: что показывать покупателю

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

Обычно встречаются такие сценарии.

Показать общий остаток. Покупатель видит суммарное количество по всем складам. Просто, не требует доработки, но не отвечает на вопрос о месте хранения.

Показать остаток по каждому складу. Покупатель видит разбивку: сколько где. Требует передачи складов на сайт и их отображения.

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

Привязать склад к клиенту. Для B2B-сценариев склад отгрузки может зависеть от договора или региона клиента. Требует хранения привязки и логики выбора.

Показать срок поставки вместо остатка. Вместо числа покупатель видит «доставка два дня» или «под заказ». Требует расчёта срока на основе склада и правил логистики.

Как заполнять карту сценариев

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

Карта не обязана быть большой. Достаточно одной страницы, где перечислены сценарии и решения по ним. Главное — чтобы она была согласована до начала технических работ, а не после.

Склад, доступность и срок поставки: как связать данные

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

Что такое доступность

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

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

Приоритет складов

Дальше возникает связь между складом и сроком. Если товар лежит на удалённом складе, срок доставки отличается от ближнего. Показывая остаток по складам, логично рядом отображать и срок, чтобы покупатель понимал, когда получит товар.

Ещё один момент — приоритет складов. Если товар есть на нескольких складах, с какого отгружать? Правило может быть простым (ближайший к клиенту) или сложным (с учётом загрузки, стоимости доставки, договора). Это правило должно быть определено до настройки обмена, иначе данные на сайте будут, а решения по ним — нет.

Здесь важно не переусложнить. Не всегда покупателю нужен конкретный склад. Иногда достаточно показать срок поставки, а выбор склада оставить внутренней логике. Решение зависит от того, влияет ли склад на ожидания клиента.

Перемещения и товары в пути: что учитывать

Товар в пути физически существует, но недоступен ни на одном складе. Если обмен передаёт только остатки, такие товары могут выглядеть доступными, хотя отгрузить их сейчас нельзя.

Отсюда несколько вопросов, которые стоит задать учётной системе.

Учитывается ли товар в пути при расчёте доступности. Если да, то на каком складе он числится и как это отражается в выгрузке.

Как обрабатываются перемещения между складами. Меняет ли это остаток на сайте и с какой задержкой.

Что происходит с резервами. Зарезервированный товар уменьшает доступность, но остаётся в остатке.

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

Варианты решения: сравнение подходов

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

Как выбирать подход

Таблица помогает выбрать направление, но не заменяет проверку поддержки в вашей версии 1С и сайта. Функционал внедрялся поэтапно и поддерживался не во всех конфигурациях, поэтому состав возможностей нужно уточнять отдельно.

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

Если обмен только предстоит настроить, общий порядок работ описан в материале Интеграция Битрикс с 1С: как настроить обмен товарами и заказами.

Учебный пример: три склада на тестовых данных

Учебный пример. Данные условные.

Входные условия

Условная компания «Ромашка» торгует крепежом. В 1С три склада: «Центральный», «Северный», «Южный». Сайт на Битрикс. Цены одинаковые на всех складах. Задача: показать покупателю, сколько товара на каждом складе, и передавать в заказ склад отгрузки.

Действия

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

Затем проверяют, что уходит в стандартной выгрузке: создают тестовый товар с разными остатками на трёх складах и смотрят файл предложений. Если количество приходит одним числом, значит, стандартная схема склады не различает.

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

Проверка и наблюдаемый результат

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

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

Как проверить результат и принять работу

Проверку удобно вести по списку. Каждый пункт выполняется на тестовом контуре, а не на рабочем сайте.

• Определены склады, участвующие в обмене, и их приоритет.
• Зафиксировано, какое значение считается доступным товаром.
• Проверено, что уходит в стандартной выгрузке до доработки.
• Создан тестовый товар с разными остатками на нескольких складах.
• Проверено, что остатки по складам приходят на сайт раздельно.
• Проверено, что общий остаток отображается корректно.
• Создан тестовый заказ и проверено заполнение склада отгрузки.
• Проверено, что после импорта в 1С склад в заказе указан верно.
• Изменён остаток в 1С и проверено обновление на сайте.
• Проверено поведение при нулевом остатке на складе.
• Проверено поведение при товаре в пути или в резерве.
• Зафиксирован план возврата: как откатить изменения, если что-то пойдёт не так.

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

Типичные ошибки и ограничения

Ошибки

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

Ошибка вторая — путать остаток и доступность. Если не учитывать резервы и товары в пути, сайт будет показывать товар доступным, когда его нельзя отгрузить.

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

Ошибка четвёртая — дорабатывать только одну сторону. Если изменить выгрузку в 1С, но не научить сайт принимать новые данные, результат не появится. И наоборот.

Ошибка пятая — проверять на рабочем сайте. Любая ошибка в обмене сразу видна покупателям.

Ограничения

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

Какие исходные данные подготовить для оценки

Чтобы оценить объём работ, нужен набор входных данных. Без них любая оценка будет приблизительной.

Список складов, которые участвуют в обмене, и их назначение. Какие из них отгружают товар покупателям, а какие играют вспомогательную роль.

Правило приоритета. С какого склада отгружать, если товар есть в нескольких местах.

Определение доступности. Какое значение считается доступным для нового заказа: остаток, остаток минус резерв, остаток с учётом товаров в пути.

Что видит покупатель. Разбивка по складам, один приоритетный склад, срок поставки или только факт наличия.

Конфигурация и версия 1С, а также версия сайта. От этого зависит, какие возможности доступны без доработки.

Текущее состояние обмена. Что уже настроено, какие данные ходят, где возникают расхождения.

Эти данные удобно свести в одну таблицу или документ. Тогда обсуждение с подрядчиком идёт предметно, а не на уровне общих пожеланий. Если обмен уже работает и вы хотите понять, что можно улучшить, полезно начать с обмена сайта на Битрикс с 1С и сверить текущую схему с описанными подходами.

FAQ