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

Начать стоит с каталога интеграций МоегоСклада. На 8 октября 2026 года там есть готовые подключения интернет-магазинов; официальный сайт для разработчиков отдельно описывает передачу заказов, цен и остатков через API.

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

Сканер штрихкодов в приложении проверяют на камере телефона и повреждённых этикетках.

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

«Есть на складе» и «можно продать» расходятся после резерва. Справка МоегоСклада на 8 октября 2026 года считает «Доступно» как остаток плюс ожидание минус резерв. Ожидание включает ещё не полученный товар.

Приложение для склада должно подтверждать фактическую приёмку на месте.

Для продажи из наличия ожидаемая поставка не подходит. В учебном примере на складе 10 единиц, 4 зарезервированы, ещё 3 ожидаются. По формуле сервиса доступно 9, а из текущего наличия свободно 6; склад и правило продажи здесь заданы для примера.

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

Заказ с сайта ещё не означает отгрузку со склада. Компания выбирает момент резерва и того, кто меняет статус: сайт, менеджер или склад. Агенту нужно это решение, иначе он заполнит пробел своим предположением.

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

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

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

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

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

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

Наш опыт относится к машине, которая строит vibecoding.ru. На её открытой странице работы видны выпуски и описание проверок. В истории новостного конвейера мы проходили потерю поля между путями записи; это пример устройства обмена данными, а не внедрение МоегоСклада.

31 июля 2026 года поле сцены обложки передавалось вручную и терялось на части путей. Передачу свели в единый маппинг: описание того, какое поле куда попадает, с проверкой полноты. Как убрать повторяемые правила, показывает разбор технического долга.

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

Рабочий обмен нужен и после выпуска. Менеджеру показывают последнюю успешную сверку, очередь ошибок и заказы, которым требуется разбор; назначенный ответственный получает сигнал о сбое. В уроке «Руль, окно и сторож» курса «Агентная разработка» мы разбираем связку правил, наблюдения и проверок.

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

Принимать интеграцию нужно из репозитория, к которому у компании есть доступ. Вместе с кодом передают таблицу полей и статусов, сценарии проверки и инструкцию запуска. По условиям /services на 8 октября 2026 года мы работаем в ветке репозитория клиента.

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

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

На 8 октября 2026 года разработка по подписке «Один проект» стоит 250 000 ₽ в месяц. Инженер ведёт машину агентов в репозитории клиента; поток означает одну задачу в работе, следующая ждёт в очереди. Поставить подписку на паузу можно в любой месяц.

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

Готовый модуль, который проходит ваши сценарии, не требует подписки ради установки. Заказная разработка уместна, когда нужно менять код обмена и развивать его дальше. Следующий шаг для такого запроса: обсудить правила обмена на странице услуг.

1. Сначала проверьте готовый модуль на сценариях своей торговли.

2. Запишите, какое наличие сайт вправе обещать покупателю.

3. Примите заказ, резерв и отмену вместе с повтором и сбоем.

4. Заберите код, проверки, описание обмена и порядок восстановления.

5. Считайте работу инженера, лицензии и эксплуатацию отдельными статьями бюджета.