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

Начать стоит с каталога интеграций МоегоСклада. На 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. Считайте работу инженера, лицензии и эксплуатацию отдельными статьями бюджета.