Интеграция 1С-Битрикс с МойСклад: товары, остатки, цены и заказы

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

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

Что такое МойСклад и зачем связывать его с сайтом

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

Для интернет-магазина МойСклад закрывает ровно ту часть, которую нельзя вести на сайте: реальный складской учёт. Сайт умеет показывать каталог и принимать заказы, но не знает, сколько товара физически лежит на складе, что уже зарезервировано и что в пути от поставщика. Всё это живёт в учётной системе. Интеграция соединяет две половины: витрину и учёт.

Что даёт связка сайта и МойСклад

Интеграция снимает с людей рутину, в которой человек ошибается чаще всего: перенос товаров, обновление цен, сверку остатков и ручное заведение заказов. Когда учётная система и сайт обмениваются данными автоматически, витрина всегда показывает актуальный ассортимент и цену, а заказы попадают в МойСклад без копирования руками.

• Единый источник товаров. Номенклатура ведётся в одном месте — в МойСклад, а сайт получает её следом. Не нужно поддерживать каталог в двух системах.
• Актуальные остатки. Наличие на витрине отражает реальный склад, и магазин не продаёт то, чего уже нет.
• Цены без ручного переноса. Изменили прайс в МойСклад — новая цена приехала на сайт по расписанию или по событию.
• Заказы в учёте. Оформленный на сайте заказ создаётся в МойСклад как документ, менеджер работает с ним в привычном интерфейсе.

Признаки, что интеграцию пора настраивать

Если вы узнаёте свой магазин в нескольких пунктах ниже — обмен с МойСклад окупится быстро:

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

МойСклад или 1С: вместе или вместо

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

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

Три типовых сценария

• Только МойСклад. Весь товарный и складской учёт ведётся в МойСклад, 1С нет или она используется отдельно бухгалтерией. Сайт обменивается с МойСклад по API — это самый чистый случай, о нём и вся статья.
• МойСклад и 1С вместе. МойСклад ведёт оперативный склад и торговлю, 1С — бухгалтерию и финансы; между собой они тоже обмениваются. Сайт связывают с той системой, где «живут» остатки и заказы, чаще с МойСклад.
• Переход с 1С на МойСклад. Компания уходит с коробочной 1С в облако. Тогда обмен с сайтом переводят с CommerceML на API МойСклад, и здесь важно бережно перенести идентификаторы, чтобы не потерять связь с уже существующим каталогом.

Что синхронизируется между Битрикс и МойСклад

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

В терминах МойСклад товар — это product, вариант товара — variant (модификация), склад — store, остаток — часть отчёта по остаткам или «ассортимента», заказ покупателя — customerorder, отгрузка — demand, тип цены — pricetype. Дальше в статье мы разберём, как правильно связать эти сущности с объектами Битрикса, потому что именно на маппинге чаще всего возникают ошибки.

Способы интеграции: модуль, REST API, сервис-прослойка

У обмена с МойСклад нет одного «штатного» протокола, как CommerceML у 1С. Поэтому первый архитектурный выбор — каким способом связывать системы. Их три, и они отличаются трудозатратами, гибкостью и стоимостью поддержки.

1. Готовый модуль из Маркетплейса Битрикс

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

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

2. Собственный обмен по REST API

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

Минус — это разработка, её нужно проектировать, тестировать и поддерживать. Зато результат ложится ровно на ваши процессы, а не наоборот.

3. Промежуточный сервис (middleware)

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

Для одного магазина с одним складом middleware чаще избыточен — достаточно модуля или прямого обмена. Но для мультиканальной торговли это самый устойчивый вариант.

Как устроен REST API МойСклад

Независимо от способа, в основе обмена лежит REST API МойСклад — набор HTTP-адресов, к которым обращается сайт, чтобы читать и записывать данные. Формат обмена — JSON: и запросы, и ответы представляют собой структурированные объекты. Это принципиально иной транспорт, чем файловый XML CommerceML: здесь нет «пакета на диске», есть живые вызовы к облаку.

Работает это так. Каждая сущность в МойСклад — товар, модификация, склад, заказ — доступна по своему адресу (endpoint). Сайт отправляет запрос: «дай список товаров», «дай остатки по складам», «создай заказ покупателя» — и получает ответ в JSON. Чтение делается запросами на получение, создание и изменение — запросами на запись. У каждой сущности есть уникальный идентификатор, по которому её потом находят и обновляют.

Авторизация: токен доступа

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

Основные сущности API

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

Товары и модификации: что приходит на сайт

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

Что переносится с товаром

• Наименование, код, артикул. Базовые реквизиты, по которым товар узнаётся и ищется.
• Папка (группа). Определяет, в какой раздел каталога попадёт товар.
• Описание. Текст карточки, если он ведётся в МойСклад.
• Атрибуты и характеристики. Дополнительные поля товара (бренд, страна, материал) — становятся свойствами инфоблока.
• Изображения. Если фото прикреплены к товару в МойСклад, они переносятся на сайт.
• Единица измерения. Штуки, метры, килограммы — важно для отображения и заказа.

Что лучше вести на сайте, а не в МойСклад

Как и с 1С, полезно заранее разделить зоны ответственности за контент. МойСклад — учётная система, её сильная сторона в цифрах и остатках, а не в продающих текстах и SEO. Практичное разделение:

• Из МойСклад приходит: наименование, артикул, цена, остаток, базовые характеристики, иногда основное фото.
• На сайте ведётся: продающие описания, галерея, SEO-поля (title, description), видео, баннеры — то, чего в учёте нет.
• Защита от затирания: поля, которыми «хозяйствует» сайт, исключаются из перезаписи обменом, чтобы выгрузка из МойСклад не очищала их пустыми значениями.

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

Модификации МойСклад → торговые предложения Битрикс

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

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

1. Родительский товар МойСклад маппится на элемент инфоблока товаров (карточку).
2. Каждая модификация маппится на торговое предложение в инфоблоке предложений, привязанное к этой карточке.
3. Характеристики модификации (размер, цвет) переносятся в свойства торговых предложений, чтобы работал выбор варианта и фильтр.
4. Связь товар→модификация сохраняется по стабильным идентификаторам, чтобы при повторном обмене предложения не оторвались от карточки.

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

Остатки по складам и «честное» наличие

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

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

Резервы и доступное количество

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

Цель — чтобы число «в наличии» на сайте было честным. Расхождение между витриной и складом подрывает доверие покупателя сильнее, чем честное «нет в наличии», поэтому остаткам уделяют столько внимания. Логику резервов проговаривают с интегратором отдельно: где создаётся резерв (на сайте или в МойСклад при создании заказа) и как он влияет на отображаемое наличие.

Несколько складов и правила отображения

• Суммарный остаток. Простейший вариант — сложить доступное по всем складам, которые участвуют в продажах на сайте.
• По складам. Показывать наличие в разрезе точек: «в наличии в Москве», «под заказ в Казани».
• Исключение служебных складов. Брак, витрина, транзит — такие склады обычно не должны попадать в «общее наличие» на сайте.

Цены и типы цен МойСклад

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

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

Цены по группам клиентов для B2B

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

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

Валюта и округление

Проверьте, в какой валюте ведутся цены в МойСклад и как они должны показываться на сайте. Для большинства российских магазинов всё в рублях, и вопрос снимается. Согласуйте и правила округления, чтобы на витрине не появлялись цены вроде «1 249,87 ₽» там, где в учёте красиво «1 250 ₽». Это лучше задать единообразно на старте.

Синхронизация заказов туда и обратно

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

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

Что важно передать в заказе

• Позиции с привязкой к номенклатуре. Каждая строка заказа связывается с товаром или модификацией по идентификатору, иначе заказ уедет «без товаров» или с несопоставленными позициями.
• Контрагент. Покупатель заводится или находится в справочнике контрагентов; для B2B это конкретная организация, для розницы — физлицо или единый «розничный покупатель».
• Склад и цена. С какого склада отгрузка и по какому типу цены оформлен заказ — чтобы суммы в учёте совпали с сайтом.
• Доставка и оплата. Способ доставки, адрес, признак оплаты — как атрибуты или поля заказа, по договорённости.

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

Через обмен заказами синхронизируется не только сам заказ, но и его жизненный цикл. В МойСклад заказ проходит стадии: создан, зарезервирован, собран, отгружен, оплачен. Эти состояния важно отразить на сайте, чтобы покупатель не звонил «а что с моим заказом», а менеджер не дублировал работу.

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

Отдельно стоит продумать «неидеальные» сценарии, которые в рознице случаются постоянно: частичная отгрузка, когда часть позиций есть, а часть под заказ; дозаказ; возврат и отмена. Для каждого нужно решить, как он отражается в обмене — новым документом, изменением статуса или корректировкой состава. Это не столько техника, сколько описание ваших бизнес-процессов: обмен лишь переносит то, что вы заранее договорились считать «частичной отгрузкой» или «возвратом». Чем подробнее эти сценарии проговорены до настройки, тем меньше ручных правок и звонков покупателям будет потом.

Маппинг справочников: как связать сущности

Самая «невидимая», но критичная часть обмена — соответствие сущностей и идентификаторов. Чтобы при каждом сеансе сайт обновлял существующие товары, а не создавал их заново, у каждой сущности должен быть стабильный код, одинаковый от обмена к обмену. В МойСклад у каждого объекта есть уникальный идентификатор; на стороне Битрикса он сохраняется как внешний код элемента (XML_ID).

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

Что с чем связывается

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

Вебхуки против расписания

Есть два принципиальных способа поддерживать данные в актуальном состоянии: спрашивать МойСклад по расписанию (pull) или получать уведомления о событиях по вебхукам (push). Их часто противопоставляют, но на практике лучший результат даёт комбинация.

Вебхуки: реакция на событие

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

Минус вебхуков — они не дают стопроцентной гарантии доставки. Если сайт в момент события был недоступен, вебхук может не дойти, и данные разойдутся. Поэтому на одних вебхуках обмен не строят.

Расписание: периодический опрос

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

Частота обмена: что как часто гонять

Не нужно (и вредно) гонять весь каталог каждые пять минут — это упрётся в лимиты API и нагрузит обе системы без пользы. Рациональнее разнести обмен по типам данных и их «скоропортящести».

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

Такое разделение снимает нагрузку: тяжёлый полный обмен идёт раз в сутки, а лёгкие частые сеансы (остатки, статусы) почти не нагружают ни API, ни сайт. Заодно это бережёт лимиты API МойСклад, о которых ниже.

Обработка ошибок и идемпотентность

Обмен по API — это сеть, а сеть иногда падает: обрыв связи, тайм-аут, ответ с ошибкой, превышение лимита. Плохой обмен на любой такой ситуации «спотыкается» и оставляет данные наполовину обновлёнными. Хороший — устроен так, чтобы сбой не приводил к дублям и потерям, а перезапуск был безопасным.

Идемпотентность: перезапуск без вреда

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

Что должен уметь обмен при сбоях

• Повторные попытки. При временной ошибке (тайм-аут, лимит) операция повторяется через паузу, а не бросается сразу.
• Пошаговость. Каталог идёт страницами; обмен помнит, на какой позиции остановился, и продолжает с неё.
• Логи. Каждый сеанс пишет журнал: что передано, сколько позиций, какие ошибки. По логам находят точку сбоя.
• Уведомления. Если обмен упал или давно не проходил, ответственный получает сигнал, а не узнаёт о проблеме по жалобам покупателей.
• Валидация данных. Некорректные позиции (без цены, без единицы, с битым идентификатором) откладываются в «карантин», а не роняют весь сеанс.

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

Лимиты API и производительность обмена

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

Приёмы бережного обмена

• Пакетная выгрузка. Забирать товары и остатки списками со страницами, а не по одному запросу на позицию. Один запрос на сотню товаров лучше, чем сто запросов по одному.
• Постраничная навигация. Большой каталог выгружается страницами фиксированного размера — так и в лимит ответа укладываемся, и обмен можно возобновить.
• Фильтры и «только изменённое». Запрашивать не весь каталог каждый раз, а изменения с момента последнего сеанса, где это возможно.
• Разумные интервалы. Не запускать тяжёлые полные обмены слишком часто; частые сеансы делать лёгкими (только остатки, только статусы).
• Реакция на превышение лимита. При ошибке «слишком часто» обмен делает паузу и повторяет запрос, а не «долбит» API дальше.

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

С производительностью на стороне Битрикса действуют те же правила, что и при обмене с 1С: под тяжёлый процесс поднимают лимиты PHP (время выполнения и память), отключают лишние пересчёты на время массовой загрузки, а витрину защищают композитным сайтом и кэшированием, чтобы обмен не влиял на скорость каталога.

Чем это отличается от обмена с 1С по CommerceML

Если вы знакомы с обменом Битрикса и 1С, полезно увидеть разницу явно. Задачи одинаковые — товары, остатки, цены, заказы, — но транспорт и механика другие.

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

Пошаговая настройка интеграции

Когда способ выбран и данные в МойСклад приведены в порядок, настройка сводится к понятной последовательности. Часть шагов делается в МойСклад, часть — на сайте.

На стороне МойСклад

1. Наведите порядок в номенклатуре. Товары разложены по папкам, без дублей и «мусорных» позиций; заполнены наименование, артикул, единица измерения, цены и характеристики.
2. Настройте модификации. Товары с вариантами заведены как товар плюс модификации (а не отдельными позициями), у характеристик единообразные значения.
3. Проверьте типы цен и склады. Заведены нужные типы цен (розница, опт) и определены склады, остатки которых уходят на сайт.
4. Заведите пользователя интеграции. Отдельный пользователь с нужными правами; получите для него токен доступа к API.
5. Настройте вебхуки. Включите уведомления по нужным событиям (остатки, заказы, товары) на адрес обработчика сайта.

На стороне сайта (1С-Битрикс)

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

Первый пробный обмен

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

Безопасность: токены и доступы

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

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

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

Мини-кейс: магазин на МойСклад

Чтобы всё вышесказанное не осталось теорией, коротко опишем типичный для нас сценарий (детали обобщены, без названий клиентов — по нашей редполитике мы не раскрываем проекты без согласия).

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

Задача. Сделать МойСклад единым источником товаров, остатков и цен, настроить автоматический обмен и двустороннюю синхронизацию заказов, не уронив скорость витрины.

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

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

Частые ошибки при интеграции с МойСклад

Большинство проблем повторяются из проекта в проект. Зная их заранее, вы сэкономите дни отладки:

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

Чек-лист перед запуском обмена

Короткий список, по которому удобно свериться до того, как включить обмен на боевом сайте:

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

Когда интеграция нужна, а когда нет

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

Когда обмен точно нужен

• Товарный и складской учёт ведётся в МойСклад, и его нужно показывать на сайте актуально.
• Ассортимент большой, цены и остатки меняются часто, а заказов много — ручная сверка не справляется.
• Несколько складов и типов цен, есть B2B-клиенты с разными прайсами.
• Нужно, чтобы заказы с сайта сразу попадали в учёт и обрабатывались менеджером в МойСклад.

Когда можно повременить

• Ассортимент небольшой и стабильный, цены и остатки меняются редко — обновить вручную дешевле, чем настраивать обмен.
• Учёт пока не ведётся системно: сначала стоит навести порядок в МойСклад, а потом связывать с сайтом.
• Магазин на этапе запуска, и важнее сначала проверить спрос, чем строить полную интеграцию.

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

Вывод

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

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