Интеграция WMS-системы склада с 1С-Битрикс

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

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

Что такое WMS и почему её связывают с магазином

WMS (Warehouse Management System) — это система управления складом, которая отвечает за физику товара: где именно он лежит, как его принять, разместить, отобрать и отгрузить. В отличие от простого складского учёта, WMS оперирует не абстрактным «остатком по номенклатуре», а конкретными адресами хранения — ячейками, зонами, паллетами. Один и тот же SKU может лежать в пяти разных ячейках, в разных партиях и с разными сроками годности, и WMS точно знает, откуда его выгоднее и безопаснее отобрать под конкретный заказ.

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

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

• Актуальные остатки. Витрина показывает то, что реально можно купить, а не то, что было вчера вечером.
• Резервы под заказ. Оформленный заказ мгновенно «замораживает» товар, чтобы его не продали повторно.
• Прозрачная комплектация. Покупатель и менеджер видят, на каком этапе заказ: собран, упакован, передан в доставку.
• Отгрузки без пересорта. WMS контролирует, что отгружен именно тот товар и в том количестве, что заказан.

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

Доступный остаток против физического: ключевое различие

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

Допустим, в ячейках склада лежит 10 единиц товара — это физический остаток. Из них 3 уже зарезервированы под оплаченные заказы, которые ждут отгрузки. Ещё 2 единицы отобраны в зону комплектации под заказы, которые собираются прямо сейчас. Одна единица помечена как брак и ждёт списания. Сколько можно продать на витрине? Не 10, а 10 − 3 − 2 − 1 = 4 единицы. Вот это и есть доступный остаток — то количество, которое магазин имеет право пообещать новому покупателю.

Формула доступного остатка в общем виде выглядит так:

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

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

Архитектура связки: WMS, 1С и Битрикс

Прежде чем настраивать обмен, полезно нарисовать общую картину: какие системы участвуют, кто чем владеет и в какую сторону текут данные. В типовом проекте среднего и крупного магазина участвуют три контура.

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

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

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

Напрямую или через 1С: как выбрать контур

Выбор топологии — это не вопрос «как красивее», а вопрос ответственности, скорости и стоимости поддержки. Разберём оба варианта честно, с плюсами и минусами.

Обмен через 1С. Если у вас уже есть учётная 1С и она обменивается с сайтом по CommerceML 2.x, самый дешёвый путь — подключить WMS к 1С, а не к сайту. Тогда сайт вообще не знает про WMS: он как обычно получает от 1С товары, цены, остатки и статусы заказов, просто теперь эти остатки уже учитывают физику склада. Плюс — вы переиспользуете штатный, годами обкатанный обмен Битрикса с 1С. Минус — цепочка длиннее, и данные доезжают до сайта с задержкой на два обмена (WMS → 1С, затем 1С → сайт). Если базовый обмен с 1С у вас идёт раз в 15 минут, то и остатки на витрине будут отставать примерно на этот интервал. Как устроен штатный обмен с 1С, мы подробно разбираем в статье про интеграцию интернет-магазина с 1С.

Прямая связка WMS ↔ Битрикс. Когда нужна скорость, близкая к реальному времени, или когда 1С не хочет или не может быть посредником, WMS интегрируют с Битриксом напрямую через REST API. WMS шлёт события об изменении остатков и статусов в очередь, Битрикс их обрабатывает за секунды. Плюс — минимальная задержка и полный контроль над форматом обмена. Минус — вы берёте на себя то, что раньше делала 1С: согласование справочников, гарантию доставки сообщений, идемпотентность и обработку ошибок. Прямая интеграция требует надёжной очереди и аккуратной инженерии — эту тему мы отдельно раскрываем в материале про API, очереди и надёжность интеграций на Битрикс.

Как выбрать на практике? Ориентируйтесь на три фактора:

1. Есть ли рабочая 1С в контуре. Если 1С уже обменивается с сайтом и вас устраивает задержка обмена — идите через 1С, это дешевле в разработке и поддержке.
2. Насколько критична скорость. Если товар оборачивается быстро и остатки единичные, задержка в 15 минут порождает пересорт — тогда нужна прямая связка или сокращение интервала обмена до реального времени.
3. Кто владеет справочниками. Единый источник номенклатуры и единиц измерения должен быть один. Если это 1С — логично держать её в контуре хотя бы для справочников, даже при прямой связке остатков.

Резервы под заказ: как это работает по шагам

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

Разберём типовой сценарий резервирования по шагам:

1. Покупатель добавляет товар в корзину. На этом этапе резерв обычно ещё не создаётся — корзина живёт недолго и брошенных корзин много. Витрина продолжает показывать доступный остаток.
2. Заказ оформлен. Битрикс создаёт заказ и ставит «мягкий» резерв на своей стороне — уменьшает доступный остаток на витрине, чтобы следующий покупатель не купил ту же единицу. Штатный модуль торгового каталога умеет резервировать под заказ автоматически.
3. Заказ подтверждён или оплачен. Резерв становится «твёрдым» и передаётся дальше — в 1С и/или в WMS. Теперь склад знает, что эти единицы нужно отложить под конкретный заказ.
4. WMS формирует задание на отбор. Товар физически резервируется в ячейках: WMS выбирает, из каких именно ячеек и партий брать, с учётом сроков годности и маршрута отбора.
5. Отбор и упаковка. Кладовщик отбирает товар, WMS переводит его в зону комплектации. Физический остаток в исходных ячейках уменьшается.
6. Отгрузка. Товар покидает склад. Резерв закрывается, физический остаток окончательно списывается, статус заказа обновляется до «отгружен», и это уезжает обратно на сайт покупателю.

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

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

Жизненный цикл заказа от корзины до отгрузки

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

Типовое соответствие статусов выглядит так:

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

Отдельно продумайте частичную отгрузку. В опте нередко заказ отгружают не целиком: часть позиций есть, часть под заказ. WMS должна уметь сообщить, что отгружено 8 из 10 позиций, а сайт — корректно это отразить и не закрывать заказ целиком. Если ваш процесс допускает частичные отгрузки, заложите их в маппинг статусов с самого начала — дорабатывать потом сложнее.

Остатки в реальном времени: события и очередь

Фраза «остатки в реальном времени» звучит красиво, но за ней стоит конкретная инженерия. Есть два принципиально разных подхода к синхронизации остатков.

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

События (push через очередь). WMS сама сообщает об изменении: «остаток товара A-1001 изменился, теперь доступно 4». Событие попадает в очередь сообщений, а интеграционный слой применяет его к Битриксу за секунды. Меняется только то, что реально изменилось, задержка минимальна. Это и есть «реальное время» в честном смысле. Минус — нужна надёжная очередь и защита от потери и задвоения сообщений.

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

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

1. WMS фиксирует изменение. Отбор, приёмка, списание брака — любое движение, меняющее доступный остаток.
2. Событие кладётся в очередь. С уникальным идентификатором, SKU, новым значением остатка и временной меткой.
3. Потребитель забирает сообщение. Интеграционный слой на стороне Битрикса читает очередь.
4. Проверка на дубль. По идентификатору события проверяем, не обработали ли мы его уже (идемпотентность).
5. Применение к каталогу. Обновляем остаток товара в торговом каталоге Битрикса, сбрасываем кэш нужного раздела.
6. Подтверждение. Сообщаем очереди, что обработали, — сообщение удаляется. Если упали до подтверждения, сообщение вернётся и обработается снова.

Согласование справочников и единиц измерения

Самая недооценённая часть WMS-интеграции — это не остатки, а справочники. Два товара «одинаковы» только тогда, когда все системы согласны, что это один и тот же товар. Если WMS знает позицию под своим внутренним кодом, 1С — под артикулом, а Битрикс — под символьным кодом или внешним ID, интеграция превращается в постоянную сверку «кто есть кто».

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

• Один ключ на всю цепочку. Выберите поле, которое одинаково во всех системах, и сопоставляйте товары только по нему. Не по названию — названия расходятся мгновенно.
• Ключ стабилен во времени. Если артикул товара может измениться, вы получите «новый» товар, а старый повиснет с остатком. Ключ должен быть неизменным.
• Новые товары заводятся в источнике истины. Договоритесь, где рождается номенклатура (обычно 1С или WMS), и не создавайте товары вручную на сайте — иначе им не с чем будет сопоставиться.

Отдельная боль — единицы измерения. WMS может вести учёт в штуках, а продавать вы хотите в упаковках или коробах. Если 1 короб = 12 штук, и это соотношение не согласовано, остаток «84 штуки» превратится на витрине в «84 короба», и покупатель закажет в 12 раз больше, чем есть. Коэффициенты пересчёта единиц должны быть частью справочника и применяться при обмене явно.

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

Реализация в 1С-Битрикс

Перейдём к конкретике на стороне Битрикса: какие модули, компоненты и настройки задействованы и в каком порядке всё собирается. Отталкиваемся от того, что каталог у вас уже на модуле «Торговый каталог» (редакция «Малый бизнес» или «Бизнес» — в «Старте» интернет-магазина нет).

Где хранятся остатки. В Битриксе остатки живут на уровне торгового каталога и складов. Модуль catalog поддерживает складской учёт: у каждого товара есть количество (QUANTITY), а при включённом многоскладовом режиме — остатки по складам в таблице складов (store_product). Резервы ведёт модуль sale через поле резерва в заказе. Задача интеграции — писать сюда доступные остатки из WMS и корректно управлять резервами.

Как принимать данные из WMS. Для приёма событий и запросов удобнее всего использовать модуль rest и написать собственные REST-методы (или обработчик входящего вебхука), которые WMS вызывает при изменении остатка или статуса. Внутри метода вы применяете изменение через API торгового каталога и заказов. Для исходящих данных (заказы, резервы на склад) — либо штатный обмен с 1С по CommerceML, либо собственный экспорт заказов через REST.

Пошаговый порядок внедрения на стороне Битрикса:

1. Проверьте редакцию и модули. Нужны модули «Торговый каталог» (catalog), «Интернет-магазин» (sale) и «REST API» (rest). Включите многоскладовый режим, если складов несколько.
2. Заведите склады. Создайте в Битриксе склады, соответствующие складам WMS, и пропишите коды сопоставления. Витрина будет суммировать доступные остатки по нужным складам.
3. Согласуйте ключ товаров. Убедитесь, что у всех товаров заполнен внешний код (XML_ID) или артикул, по которому WMS их однозначно находит.
4. Сделайте приёмник остатков. REST-метод или вебхук, который принимает событие «SKU X, склад Y, доступно N», проверяет идемпотентность и обновляет остаток через API каталога.
5. Настройте передачу заказов. При смене статуса заказа на «оплачен/подтверждён» отправляйте заказ и резерв в WMS (напрямую или через 1С).
6. Обработайте обратные статусы. Приёмник статусов отгрузки, который обновляет статус заказа в sale и виден покупателю в личном кабинете.
7. Настройте сброс кэша. После обновления остатка сбрасывайте тегированный кэш соответствующего раздела каталога, иначе витрина покажет старое число.
8. Включите журналирование. Пишите в лог каждое входящее и исходящее сообщение с идентификатором — это спасёт при разборе расхождений.

Схематично «пульт» интеграции в админке — журнал обмена — выглядит примерно так:

Идемпотентность, надёжность и сверка

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

Идемпотентность. Это свойство обработчика давать один и тот же результат, сколько бы раз ни пришло одно и то же сообщение. Очереди по своей природе доставляют сообщения «хотя бы один раз» — а значит, иногда дважды. Если событие «остаток стал 4» обработать дважды без защиты, во второй раз ничего страшного (остаток и так 4). Но событие «уменьши остаток на 1» при задвоении спишет две единицы вместо одной. Поэтому передавайте абсолютные значения остатка, а не дельты, и снабжайте каждое сообщение уникальным идентификатором, по которому обработчик отсекает повторы.

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

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

Порядок надёжной сверки:

1. Полная выгрузка из WMS. Ночью, в час низкой нагрузки, WMS формирует снимок доступных остатков по всем позициям и складам.
2. Сравнение по ключу. Интеграция сопоставляет остатки по артикулу и складу, фиксирует расхождения.
3. Отчёт о расхождениях. Список «где сайт разошёлся со складом» уходит в лог и, при большом числе, — ответственному на почту.
4. Исправление. Остатки на сайте приводятся к значениям WMS (источник истины по физике).
5. Анализ причин. Если расхождений много, ищут корневую причину: потерянные события, ручные правки, ошибки маппинга.

Несколько складов и распределение резервов

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

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

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

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

Тема распределения остатков и резервов между несколькими складами достаточно объёмна, чтобы вынести её отдельно — детально мы разбираем её в статье про обмен остатками с нескольких складов и WMS, включая сценарии с транзитными складами и точками выдачи.

Сравнение сценариев интеграции

Сведём варианты интеграции в одну таблицу, чтобы было проще выбирать под свою ситуацию.

Часто оптимум — гибрид: справочники и цены идут через 1С (там их источник истины), а критичные по скорости остатки и статусы отгрузки — прямой событийной связкой WMS ↔ Битрикс. Так вы получаете и надёжность штатного обмена, и скорость реального времени там, где она реально нужна.

Метрики и мониторинг обмена

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

Настройте оповещения хотя бы на две метрики: рост длины очереди и всплеск ошибок обработки. Эти два сигнала ловят большинство инцидентов до того, как они выльются в пересорт и жалобы. Остальные метрики достаточно смотреть в ежедневном отчёте по сверке.

Частые ошибки при интеграции

• Синхронизируют физический остаток вместо доступного — витрина обещает то, что уже зарезервировано под другие заказы, начинается пересорт.
• Передают изменения остатка дельтами («минус 1») вместо абсолютных значений — при задвоении сообщения остаток «уплывает» и расходится с реальностью.
• Нет идемпотентности — одно и то же событие обрабатывается дважды, товар списывается лишний раз.
• Резерв не снимается по таймауту неоплаты и при отмене — доступный остаток медленно протекает в ноль на популярных позициях.
• Сопоставляют товары по названию, а не по стабильному ключу (артикулу) — при малейшем расхождении названий остаток «повисает» на несопоставленной позиции.
• Игнорируют единицы измерения — короба и штуки путаются, покупатель заказывает в разы больше или меньше, чем есть.
• Дёргают API напрямую без очереди — при недоступности сайта событие теряется навсегда, без шанса на повтор.
• Не делают регулярную сверку — микрорасхождения копятся месяцами и всплывают внезапно большим пересортом в пик продаж.

Чек-лист внедрения

Сведём всё в практический список, по которому удобно принимать готовность WMS-интеграции перед запуском:

1. Определён доступный остаток. Согласована формула «доступно = физически − резервы − отбор − брак» и кто её считает.
2. Выбрана топология. Решено, идёт обмен через 1С, напрямую или гибридом, и почему именно так.
3. Согласованы справочники. Единый стабильный ключ товаров, коэффициенты единиц измерения, коды складов сопоставлены во всех системах.
4. Резервы под контролем. Настроены мягкий и твёрдый резерв, автоснятие по отмене и таймауту неоплаты, защита от двойного резервирования.
5. Обмен идёт через очередь. События буферизуются, доставка гарантирована, подтверждение — только после применения.
6. Обработка идемпотентна. Передаются абсолютные остатки, дубли отсекаются по идентификатору события.
7. Статусы согласованы. Маппинг статусов заказа и склада настроен, обратный поток отгрузок доходит до личного кабинета.
8. Сверка автоматизирована. Ночная полная сверка остатков с отчётом о расхождениях и автоисправлением.
9. Мониторинг включён. Оповещения на рост очереди и ошибки обработки, ежедневный отчёт по сверке и пересорту.
10. Кэш сбрасывается. После обновления остатка тегированный кэш раздела каталога инвалидируется, витрина показывает свежее число.

Вывод

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