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