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