Обмен заказами и статусами: МойСклад и сайт на Битрикс

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

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

Зачем связывать МойСклад и сайт на Битрикс

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

Что даёт двусторонний обмен на практике:

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

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

Архитектура обмена: кто источник истины

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

• Каталог и остатки: МойСклад → сайт. Номенклатура, цены и остатки формируются в учётной системе и выгружаются на витрину. Сайт их только отображает и не редактирует напрямую.
• Заказы: сайт → МойСклад. Факт оформления заказа рождается на витрине. Сайт передаёт заказ в учёт, где он превращается в документ и дальше живёт по складским правилам.
• Статусы и резервы: МойСклад → сайт. Что происходит с заказом после оформления — резерв, сборка, отгрузка, — решает склад. Эти изменения возвращаются на витрину, чтобы покупатель видел прогресс.
• Данные покупателя: сайт → МойСклад. Контакты, адрес доставки, комментарий к заказу вводит покупатель. Они уезжают вместе с заказом и привязываются к контрагенту в МойСклад.

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

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

Чтобы обмен был предсказуемым, заказ нужно рассматривать не как разовое событие, а как объект с жизненным циклом. У него есть последовательность состояний, и на каждом переходе может срабатывать обмен. Типовой путь заказа в связке сайта и МойСклад выглядит так:

1. Оформлен на сайте. Покупатель прошёл корзину и оформление, заказ сохранён в 1С-Битрикс со всеми позициями, суммой и контактами.
2. Передан в МойСклад. Обмен создаёт в учётной системе документ «Заказ покупателя», привязывает контрагента и позиции по артикулам.
3. Зарезервирован. МойСклад ставит резерв под позиции заказа, доступный остаток уменьшается, и это возвращается на витрину.
4. Собран. Склад скомплектовал заказ; статус меняется в МойСклад и уезжает обратно на сайт.
5. Отгружен. Создаётся документ отгрузки, резерв списывается в фактическое движение товара, статус на сайте обновляется на «Отгружен».
6. Доставлен / выдан. Финальный статус закрывает заказ; при необходимости фиксируется оплата.

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

Как заказ попадает в МойСклад

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

Когда покупатель завершает оформление, в 1С-Битрикс срабатывает событие сохранения заказа. На этом моменте у нас есть выбор архитектуры: передать заказ в МойСклад прямо сейчас (синхронно) или поставить в очередь на передачу (асинхронно). Правильный ответ почти всегда — асинхронно.

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

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

При передаче обмен собирает из заказа Битрикса документ МойСклад:

• Контрагент. По телефону или email ищется существующий контрагент; если не найден — создаётся новый. Так один покупатель не плодит десяток карточек.
• Позиции. Каждая строка заказа связывается с товаром МойСклад по артикулу или внешнему коду, переносится количество и цена.
• Скидки и итоги. Итоговая сумма, скидки и стоимость доставки переносятся так, чтобы сумма документа совпала с суммой заказа на сайте до копейки.
• Внешний идентификатор. Заказу проставляется внешний ключ (обычно ID заказа Битрикса), по которому обмен потом находит этот же документ и не создаёт дубль.

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

Сопоставление статусов: карта соответствий

Обратный поток — возврат статусов на витрину — целиком держится на одном документе: карте соответствия статусов. Проблема в том, что понятия статуса в МойСклад и в 1С-Битрикс не совпадают. В МойСклад у заказа покупателя свои этапы, у отгрузки — свои. В Битриксе — свой список статусов заказа, который вы задаёте под бизнес-процесс магазина. Задача обмена — однозначно перевести одно в другое.

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

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

Несколько правил, которые делают карту статусов рабочей:

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

Возврат статусов на витрину

Разобравшись с картой соответствия, посмотрим на механику: как именно сайт узнаёт, что статус в МойСклад изменился. Есть два подхода, и они не взаимоисключающие.

Опрос по расписанию (поллинг). Агент 1С-Битрикс с заданной периодичностью (например, раз в 5–15 минут) запрашивает у API МойСклад заказы, изменившиеся с момента прошлой синхронизации, и обновляет их статусы на сайте. Плюс — простота и предсказуемость: не нужен внешне доступный обработчик, всё инициирует сайт. Минус — задержка: статус на витрине обновляется не мгновенно, а в пределах интервала опроса.

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

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

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

Отгрузки, резервы и остатки

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

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

Отгрузка. Документ отгрузки в МойСклад фиксирует фактическое движение товара со склада покупателю. В этот момент резерв «превращается» в реальное списание, физический остаток уменьшается. Для обмена появление отгрузки — сигнал сменить статус заказа на «Отгружен» и передать этот статус на сайт.

Остаток на витрине. Сайт получает остатки из МойСклад по расписанию. Ключевой вопрос — какой именно остаток выгружать: физический или доступный (за вычетом резервов). Для интернет-магазина почти всегда нужен доступный, чтобы не продать уже обещанный товар.

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

Сопоставление товаров и клиентов

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

Товары. Позиция заказа на сайте должна однозначно указывать на товар в МойСклад. Связывать по названию — ошибка: названия правят, они не уникальны, в них опечатки. Правильный ключ — артикул (Article) или внешний код (externalCode). Артикул задаётся в номенклатуре МойСклад и в карточке товара Битрикса; обмен ищет соответствие именно по нему. Если каталог изначально выгружается из МойСклад, соответствие устанавливается автоматически при выгрузке и хранится в свойстве товара.

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

Отдельно стоит сказать про торговые предложения (SKU). Если у товара есть вариации — размеры, цвета, — то в заказе фигурирует конкретное торговое предложение, и связывать с МойСклад нужно именно его, по артикулу варианта, а не родительского товара. Иначе резерв встанет «на модель вообще», а не на конкретный размер, и склад соберёт не то.

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

Заказ — это не только позиции, но и способ оплаты и доставки. Их тоже нужно согласовать между системами, иначе документ в МойСклад будет неполным, а отчётность — кривой.

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

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

Важно заранее сопоставить справочники: способы оплаты и доставки в 1С-Битрикс и соответствующие им сущности в МойСклад. Как и со статусами, здесь нужна карта соответствия — «наложенный платёж на сайте → тип оплаты X в МойСклад». Без неё каждый нестандартный способ будет ломать передачу заказа.

Очередь, идемпотентность и надёжность

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

Три опоры надёжного обмена:

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

Идемпотентность на практике реализуется через внешний идентификатор. У заказа Битрикса есть ID; при передаче он проставляется документу МойСклад как externalCode. Перед созданием документа обмен спрашивает: «есть ли уже заказ с таким externalCode?». Есть — обновляем существующий, нет — создаём новый. Тот же принцип для статусов: обновление до состояния, в котором заказ уже находится, ничего не ломает.

Ещё один важный аспект — лимиты API МойСклад. У облачного API есть ограничения на частоту запросов. Обмен должен уважать эти лимиты: не долбить API в лоб, а выдерживать паузы, группировать запросы (batch), кэшировать справочники. При всплеске заказов (распродажа) очередь сглаживает нагрузку, растягивая отправку во времени, вместо того чтобы упереться в лимит и начать терять данные.

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

Перейдём от принципов к тому, где именно всё это живёт в 1С-Битрикс. Технически у обмена есть несколько точек опоры в платформе.

• Модуль «Интернет-магазин» (sale). Заказы, статусы заказа, оплаты и отгрузки — это сущности модуля sale. Статусы заказа настраиваются в разделе «Магазин → Настройки → Статусы заказов», где у каждого статуса есть символьный код — тот самый ключ для карты соответствия.
• Обработчики событий заказа. На события OnSaleOrderSaved (и связанные) вешается логика постановки заказа в очередь на передачу в МойСклад. Так обмен не встроен «намертво» в оформление, а реагирует на событие.
• Агенты и cron. Периодические задачи — опрос МойСклад на предмет смены статусов, обработка очереди на передачу заказов, выгрузка остатков — выносятся в агенты Битрикса, запускаемые по cron, а не «на хитах».
• Свойства товара и заказа. Для хранения внешних ключей (артикул/код МойСклад у товара, ID документа у заказа) используются свойства инфоблока и заказа. Это «клей», по которому системы находят друг друга.
• HTTP-клиент к API. Обращения к JSON API МойСклад делаются через встроенный HTTP-клиент Битрикса с авторизацией токеном, обработкой кодов ответа и уважением к лимитам.

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

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

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

Собственная интеграция через API. Своё решение поверх JSON API МойСклад даёт полный контроль: любое сопоставление полей, произвольная карта статусов, тонкая работа с резервами и складами, встраивание в существующие бизнес-процессы. Цена — разработка и последующее сопровождение. Этот путь оправдан, когда процессы магазина заметно отличаются от типовых или когда обмен — часть более крупной интеграции (например, ещё и с 1С или CRM).

Как это выглядит в админке

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

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

Модуль или своя интеграция — сравнение

Чтобы выбор способа реализации был осознанным, сведём отличия готового модуля и собственной интеграции в таблицу.

Практический ориентир: если у вас типовой магазин с одним складом и стандартными статусами — начинайте с готового модуля, он закроет задачу быстро и дёшево. Если процессы нестандартные, складов несколько, а обмен с МойСклад — лишь часть большей интеграции (с 1С, CRM, службами доставки) — закладывайте собственное решение, оно окупится управляемостью. Нередко разумен гибрид: коробочный модуль для базового потока плюс небольшие доработки под специфику.

Мониторинг и разбор расхождений

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

• Глубина очереди. Сколько заказов ждёт передачи прямо сейчас. Растёт и не уменьшается — значит, обмен встал.
• Возраст последней синхронизации. Когда обмен в последний раз успешно отработал. Давно — повод бить тревогу.
• Доля ошибок. Сколько операций падает. Всплеск ошибок — сигнал о смене API, протухшем токене или изменении данных.
• Расхождения остатков. Периодическая сверка остатков сайта и МойСклад по выборке товаров ловит «уехавшие» позиции.

Когда расхождение всё-таки случилось, разбор идёт от журнала обмена. По внешнему ключу заказа находится история его передачи: когда ушёл, какой ответ вернул МойСклад, менялся ли статус. В 90% случаев причина видна сразу: заказ не прошёл из-за отсутствующего в МойСклад товара, статус не сопоставлен, токен просрочен. Хороший обмен делает такой разбор минутным делом, плохой — превращает в раскопки по всей системе.

Частые ошибки

• Передают заказ в МойСклад синхронно при оформлении — недоступность API роняет корзину, и заказ теряется на последнем шаге.
• Сопоставляют товары по названию вместо артикула — при малейшем расхождении названий позиция не находится или задваивается.
• Выгружают на витрину физический остаток вместо доступного — товар продаётся «в минус», потому что резервы не учтены.
• Нет карты соответствия статусов — обмен либо игнорирует статусы, либо ставит на сайте что-то невнятное, и покупатель не понимает, что с заказом.
• Отсутствует идемпотентность — повторная отправка или дублирующий вебхук создают в МойСклад второй документ на тот же заказ.
• Опрашивают API «все заказы подряд», а не изменённые — с ростом базы синхронизация упирается в лимиты и замедляется.
• Запускают агенты обмена «на хитах» — на тихом сайте обмен встаёт, на нагруженном дёргается хаотично.
• Не ведут журнал операций — при расхождении нечего анализировать, разбор превращается в гадание.

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

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

1. Разграничена ответственность. Зафиксировано, какая система источник истины по каждому виду данных: остатки — МойСклад, факт заказа — сайт.
2. Товары сопоставлены. У всех товаров есть стабильный ключ связи (артикул/внешний код) с номенклатурой МойСклад; SKU связаны по вариантам.
3. Клиенты дедуплицируются. Настроен поиск контрагента по телефону/email/ИНН, повторные заказы не плодят карточки.
4. Передача через очередь. Заказ сохраняется на сайте всегда, а в МойСклад уходит асинхронно с повторами при сбое.
5. Идемпотентность есть. У заказа внешний ключ, повторная отправка не создаёт дубль документа.
6. Карта статусов составлена. Каждому состоянию МойСклад сопоставлен статус заказа Битрикс по символьному коду; отмена прописана отдельно.
7. Остатки — доступные. На витрину выгружается доступный остаток за вычетом резервов, склад(ы) выбраны осознанно.
8. Оплата и доставка согласованы. Способы оплаты и доставки сопоставлены между системами, суммы совпадают до копейки.
9. Агенты на cron. Опрос статусов, обработка очереди и выгрузка остатков запускаются по реальному расписанию сервера.
10. Мониторинг настроен. Отслеживаются глубина очереди, возраст синхронизации и доля ошибок; есть журнал и алерты.

Вывод

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