ИИ подключили к МойСклад — и вот что получит владелец бизнеса

Что именно получает владелец бизнеса, если подключить ИИ не к выгрузке CSV и не к демонстрационному дашборду, а к рабочему контуру МойСклад?

Чтобы ответить на этот вопрос, мы провели новый полный live-тест с отдельным маркером AI-MS-FULL-20260908-052335. Старые результаты не использовались как доказательство. Внутри нового прогона мы заново создали товары, контрагентов, склад, продажи, закупки, оплаты, возврат, перемещение, дефицит, пополнение и заблокированный заказ — то есть разыграли несколько дней реального малого торгового бизнеса.

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

Короткий итог теста

• 43/43 проверенных коллекции сущностей — PASS.
• 14/14 отчётов — PASS после проверки их реальных контрактов параметров.
• 5/5 тестов search/order/expand/pagination — PASS.
• bulk-создание контрагентов и товаров — PASS.
• создание и изменение заказов, поставок, отгрузок, перемещений, платежей, возвратов, закупок, задач, счетов, оприходований, списаний, инвентаризации, внутренних заказов и справочных сущностей — PASS в проверенном контуре.
• исходящий платёж возврата — PASS после обнаружения обязательного expenseItem.
• физический DELETE синтетического объекта — PASS с независимым GET-read-back 404.
• найдена эксплуатационная особенность: отчёты по остаткам обновляются не строго синхронно с записью документов. Нужен цикл write → poll → reconcile → accepted state.
• после теста весь синтетический бизнес приведён в терминальное нейтральное состояние, остатки 0/0/0/0, тестовые сущности архивированы или удалены.

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

Мы создали четыре товара с закупочными и продажными ценами, поставщика, трёх покупателей — Alpha, Beta и Gamma — и дополнительный резервный склад. Затем провели цепочку операций за пять условных рабочих дней.

Это важно: цель состояла не в том, чтобы проверить один GET-запрос, а в том, чтобы увидеть, сможет ли ИИ работать с зависимыми бизнес-событиями. Заказ влияет на остаток, отгрузка — на склад, платёж — на взаиморасчёты, возврат — на прибыль и баланс клиента, а закупка должна быть связана с реальным дефицитом, а не создана «потому что так попросили».

День 1. Поступление, продажа, оплата и первый сигнал о задержке отчётов

На склад поступили:

• товар A — 20 шт.;
• B — 30 шт.;
• C — 8 шт.;
• D — 60 шт.

Покупатель Alpha оформил заказ на 21 100 ₽. Заказ прошёл статусный переход, была создана и проведена отгрузка, затем входящий платёж на всю сумму.

Здесь проявилась первая важная эксплуатационная особенность. Сразу после успешных записей отчёт по остаткам ещё показывал состояние после поставки, без уже проведённой отгрузки. Позже отчёт догнал фактическое состояние. То есть успешный POST/PUT нельзя считать доказательством того, что агрегированный отчёт уже перестроен.

День 2. Частичная оплата и перемещение между складами

Beta оформил заказ и отгрузку на 43 300 ₽, но оплатил только 30 000 ₽. Система получила не просто факт «заказ есть», а управленческий контекст: неоплаченный остаток составил 13 300 ₽.

Дополнительно 15 единиц товара D были перемещены с основного склада на резервный. После convergence отчёта ИИ видел распределение товара по двум точкам хранения, а не только общий остаток.

День 3. Дефицит, задача сотруднику, возврат и финансовая ловушка

Gamma оформил заказ, которому требовалось 5 единиц товара C. Фактически доступна была только 1 единица. Дефицит — 4 шт.

Попытка создать задачу без ответственного вернула контрактную ошибку. После добавления обязательного assignee задача создалась корректно. Это полезная проверка: ИИ не должен «угадывать» обязательные поля и маскировать ошибки API красивым текстом.

В этот же день Alpha вернул одну единицу товара B на 1 400 ₽. Сам документ возврата создался корректно.

Первый запрос на возврат денег через paymentout вернул 412 / code 3000: для исходящего платежа требовалась статья расхода expenseItem. ИИ перечитал справочник /entity/expenseitem, нашёл статью «Возврат», повторил операцию и затем отдельно перечитал созданный платёж. Исправленный refund — PASS.

Но именно здесь появился важный управленческий вывод. До возврата денег баланс Alpha был −39 700 ₽, после возврата — −41 100 ₽. Клиент уже был должен компании, а автоматический возврат денег увеличил дебиторскую задолженность. Значит, финансовое действие нельзя запускать только по факту возврата товара. ИИ должен учитывать взаиморасчёты контрагента и в спорном случае остановиться на подтверждении руководителя.

День 4. Закупка под дефицит и восстановление исполнения заказа

Для закрытия дефицита был создан заказ поставщику: 12 единиц A и 10 единиц C на 20 400 ₽. Затем проведена поставка, связанная с заказом поставщику.

После поступления стало возможно провести отгрузку Gamma на 11 450 ₽. Задача по дефициту была переведена в done=true и независимо перечитана.

Это уже не сценарий «ИИ увидел остаток». Он проследил причинную цепочку: дефицит → закупочный документ → поставка → возможность исполнить клиентский заказ → закрытие задачи.

День 5. Главная управленческая ситуация: заказ есть, товара нет

После следующей крупной отгрузки товар A был полностью выбран до 0.

Затем появился новый заказ Beta на 11 600 ₽. Для него требовалось ещё 5 единиц A, а отгружено было 0.

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

не менять цену; причина блокировки — отсутствие товара; создать заказ поставщику ровно на недостающие 5 единиц A стоимостью 6 000 ₽ и связать его с заблокированным заказом.

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

Что получил владелец в цифрах

По итогам синтетического бизнеса ИИ собрал управленческую картину из разных сущностей МойСклад:

• чистые продажи — 115 550 ₽;
• валовая прибыль — 51 700 ₽;
• валовая маржа — 44,74%;
• прибыль по A — 28 800 ₽;
• по B — 8 400 ₽;
• по C — 7 500 ₽;
• по D — 7 000 ₽;
• входящие платежи, созданные в текущем прогоне, — 51 100 ₽;
• исходящий refund — 1 400 ₽;
• net по точным платежным документам текущего прогона — 49 700 ₽;
• дебиторская задолженность после возврата денег — 65 850 ₽.

Здесь есть важная методологическая деталь. Отчёт /report/money/plotseries является общим для аккаунта и содержал посторонние операции, поэтому мы не приписывали весь его денежный поток синтетическому сценарию. Для cash-фактов использовали только ID платежных документов, созданных в этом прогоне. Продажи и прибыль изолировали по ID и кодам синтетических товаров.

Какие API-пути были реально прочитаны

В live sweep прошли 43 коллекции сущностей:

/entity/product, /entity/assortment, /entity/counterparty, /entity/organization, /entity/employee, /entity/store, /entity/customerorder, /entity/purchaseorder, /entity/supply, /entity/demand, /entity/salesreturn, /entity/purchasereturn, /entity/move, /entity/inventory, /entity/enter, /entity/loss, /entity/invoicein, /entity/invoiceout, /entity/paymentin, /entity/paymentout, /entity/cashin, /entity/cashout, /entity/task, /entity/project, /entity/contract, /entity/saleschannel, /entity/pricelist, /entity/internalorder, /entity/processingorder, /entity/productiontask, /entity/webhook, /entity/currency, /entity/uom, /entity/service, /entity/variant, /entity/productfolder, /entity/retailstore, /entity/retaildemand, /entity/retailsalesreturn, /entity/prepayment, /entity/prepaymentreturn, /entity/commissionreportin, /entity/commissionreportout.

Дополнительно были прочитаны /context/employee, /entity/expenseitem и /context/companysettings/pricetype.

Какие отчёты прошли live-проверку

14/14 проверенных отчётов отработали:

• /report/stock/all;
• /report/stock/bystore;
• /report/stock/byoperation;
• /report/turnover/all;
• /report/turnover/byoperations;
• /report/profit/byproduct;
• /report/profit/byvariant;
• /report/profit/byemployee;
• /report/profit/bycounterparty;
• /report/profit/bysaleschannel;
• /report/counterparty/{id};
• /report/money/byaccount;
• /report/money/plotseries;
• /report/sales/plotseries.

Отдельно проверили реальные контракты параметров. Для stock/byoperation потребовался operation.id; для turnover/byoperations — период и фильтр по полному href товара; для plotseries — период и interval=day.

Путь /report/dashboard вернул 404 / code 1002: такой самостоятельный route не входит в принятый нами API-контур.

Search, сортировка, expand и pagination

Отдельно прошли пять параметрических тестов: поиск товара, сортировка заказов, expand=agent для заказа покупателя и две страницы offset-pagination. Все 5/5 — PASS.

Metadata: что реально существует, а что нельзя выдумывать

Metadata sweep дал 34/42 HTTP 200. Остальные ответы не стали маскировать как «ошибку интеграции»: у части типов отдельного /metadata-маршрута просто нет по контракту. Например, такие ответы получили для saleschannel, webhook, currency, uom, retailstore и expenseitem. Для incomeitem API вернул 412/code 1005 — неизвестный тип.

Практический вывод: коннектор должен знать реальную поверхность API, а не механически приписывать /metadata каждой коллекции.

Какие записи и CRUD мы проверили

• bulk create контрагентов — 4/4 PASS;
• bulk create товаров — 4/4 PASS;
• изменение цены товара → read-back → восстановление цены — PASS;
• project create/update/read/archive — PASS;
• productfolder create/update/read/archive — PASS;
• service create/update/read/archive — PASS;
• contract create/read/archive — PASS после обнаружения обязательного ownAgent;
• invoiceout и invoicein create/read/archive — PASS;
• purchasereturn — PASS;
• enter — PASS;
• loss — PASS;
• inventory — PASS;
• internalorder — PASS;
• task create и последующий done=true — PASS;
• paymentout/refund — PASS после корректного expenseItem;
• физический DELETE синтетического контрагента — HTTP 200, затем независимый GET вернул 404/code 1021 — PASS.

Негативные тесты дали не меньше пользы, чем успешные

Мы специально проверяли не только happy path.

• Цена без priceType → 412 / code 3000.
• Повторный code товара → 412 / code 3006, уникальность контролируется.
• Повторный externalCode создал новый объект с другим ID. Значит, externalCode нельзя использовать как надёжный idempotency key.
• Задача без assignee → контрактная ошибка.
• Contract без ownAgent → контрактная ошибка.
• Paymentout без expenseItem → 412/code 3000.
• При cleanup попытка снять проведение с отгрузки, пока связанный возврат оставался проведённым, дала 412 / code 3007. Сначала пришлось снять проведение с возврата и только затем повторить операцию.

Именно такие тесты определяют, можно ли доверять автоматизации в реальном бизнесе: система должна не просто уметь писать, а понимать обязательные поля, зависимости документов и безопасный порядок операций.

Eventual consistency: почему одного read-back недостаточно

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

После Day 1 успешная отгрузка уже существовала, но мгновенный stock-report ещё показывал предыдущую фазу. Во время cleanup отчёт временно показывал промежуточные отрицательные значения, а через несколько секунд сошёлся к правильному терминальному состоянию 0/0/0/0.

Поэтому production-интеграция должна считать действие завершённым только так:

write → перечитать целевой документ → poll агрегированного состояния → reconcile ожидаемое и фактическое → terminal accepted state.

Схема «POST вернул 200 — значит всё готово» для управленческого ИИ недостаточна.

Производительность и rate behavior

В последовательной серии из 10 чтений заказов получили 10/10 HTTP 200. Медиана — 563,7 мс, минимум — 541,7 мс, максимум — 1616,4 мс.

Параллельный bounded probe: 10 GET-запросов, 5 workers, также 10/10 HTTP 200; wall time — 1368,9 мс. После burst наблюдался rate limit 45, remaining 26, retry-after 0.

Это фактические измерения конкретного аккаунта и запуска, а не обещание SLA МоегоСклада.

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

Проверенный сейчас контур выглядит так:

чат владельца → изолированный сервер клиента → коннектор МойСклад → JSON API 1.2 → факты/отчёты → управленческий вывод → разрешённая запись → независимый read-back/reconciliation.

Секрет доступа не должен передаваться модели и не должен появляться в диалоге. В нашем тестовом executor токен хранится в защищённом хранилище, а аудит сохраняет только безопасные метаданные и SHA. Финальная проверка журнала не нашла Authorization, Bearer, access_token, маркер текущего теста или тела бизнес-документов.

Для тиражного подключения есть более зрелый путь через серверное решение МоегоСклада: при установке решения Vendor API передаёт разработчику токен JSON API 1.2, а при удалении/приостановке решения этот токен аннулируется. Это уже отдельный продуктовый путь, а не часть текущего benchmark. Официально МойСклад поддерживает публичные и приватные серверные решения и передачу Bearer-токена при активации решения: Vendor API 1.0.

Базовая документация рабочего контура: JSON API 1.2.

Что осталось за границей этого теста

• Webhook end-to-end не принят: под текущим CODE_FREEZE не разворачивали отдельный callback receiver.
• Vendor/Loyalty/Fiscal/QRPay/Phone — отдельные API-поверхности и требуют собственного provisioning/credential path; текущим Bearer JSON API тестом они не подтверждались.
• Production/retail/commission коллекции читались там, где были доступны, но полный write-lifecycle не имитировался без нужных бизнес-модулей и fixtures.
• Standalone public resource organizationbranch остаётся неподтверждённым.

Мы сознательно не называем эти участки PASS, потому что экспертный кейс должен отделять проверенное от предполагаемого.

Что в итоге получает владелец бизнеса

Не ещё один дашборд и не «чат поверх МоегоСклада».

Он получает возможность задавать управленческие вопросы к реальному операционному контуру:

• какие заказы сейчас невозможно исполнить и почему;
• где дефицит уже блокирует деньги;
• какой клиент должен компании и как возврат повлияет на взаиморасчёты;
• какое пополнение нужно сделать именно сейчас;
• какие действия можно выполнить автоматически, а какие нужно вынести на подтверждение;
• произошло ли действие фактически, а не просто вернул ли API код 200.

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

Возможности интеграции ИИ-ассистента с МойСклад

Обсудить подключение к вашему контуру МойСклад