Интеграция интернет-магазина с МоимСкладом: остатки, заказы и контроль обмена

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

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

Начните с трёх маршрутов данных

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

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

Готовое подключение или собственная интеграция

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

У готового решения проверьте совместимость с версией магазина, поля, ошибки и регулярные платежи. Назначьте ответственного за проблему на стыке продуктов: разработчика сайта, автора модуля или интегратора.

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

Как сопоставить товары без дублей

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

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

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

Остаток, доступность и резерв — разные показатели

В условном примере на складе 12 единиц, 5 зарезервированы, ещё 2 составляют страховой запас. Если исходное поле содержит физическое количество, доступно 12 − 5 − 2 = 5. Для уже свободного остатка формула будет другой: сначала уточните смысл поля в коннекторе.

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

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

Что должно попасть из заказа в МойСклад

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

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

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

Повторная отправка и недоступность сервиса

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

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

Разбор сбоя: документ создан, ответ не дошёл

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

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

Как обрабатывать изменение, отмену и частичный возврат

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

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

Для частичного возврата используйте пример с несколькими позициями и доставкой. Согласуйте, какая часть суммы возвращается, что происходит со скидкой и куда попадает возвращённый товар. Проверку проводят на безопасном тестовом контуре; реальные деньги и фискальные операции без отдельного согласования не затрагивают.

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

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

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

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

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

Как рассчитать объём работ и выпустить обмен

Для оценки подготовьте CMS и её версию, список складов и типов цен, размер каталога, примеры модификаций и обезличенные заказы. Приложите текущие подключения: 1С, CRM, маркетплейсы и платёжные сервисы. Это позволит увидеть, не появится ли второй маршрут записи в те же поля.

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

Запускайте интеграцию на согласованной группе товаров и заказов, затем расширяйте охват. До переключения определите момент последней полной сверки, порядок обработки новых заказов и возврата к прежнему процессу. Восстановление старой базы поверх уже принятых заказов может потерять данные; план отката должен учитывать их отдельно.

Готовая таблица для задания и приёмки

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

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