Продавец подключает Яндекс Маркет к уже работающим WB и Ozon, а остатки, цены и заказы по нему пока ведутся вручную.
Учёт ведётся в 1С или МойСклад, интеграция с WB и Ozon уже работает, а Маркет добавляется отдельно. У Маркета своя логика: кабинет и магазины внутри него, модели FBY, FBS, Экспресс и DBS с разным набором методов, карантин цен и собственные лимиты. Перенести интеграцию с другой площадки один к одному не получается, а ручное обновление остатков в пик приводит к продаже товара, которого уже нет.
Остатки и цены из учётной системы, список магазинов кабинета и их моделей работы, сопоставление SKU Маркета с номенклатурой учёта, правила страхового запаса и минимальной цены, уведомления о заказах.
Остатки уходят из учёта со страховым запасом для магазинов FBS, Экспресс и DBS, цены передаются с проверкой нижней границы. Новые заказы приходят уведомлениями, полные данные забираются из API и передаются в учёт, статусы возвращаются на Маркет. Товары в карантине цен и несопоставленные SKU попадают в отчёт.
Партнёрский API Яндекс Маркета с Api-Key-токеном, 1С или МойСклад, n8n или Python, очередь запросов под лимиты, Google Sheets или BI для отчётов, Telegram для алертов.
Остатки и цены на Маркете совпадают с учётом, заказы попадают в учёт без ручного ввода, а проблемы с карантином и сопоставлением видны сразу.
Решение начинается с карты магазинов: какой магазин по какой модели работает и какие методы API ему доступны. По FBS, Экспресс и DBS остатки передаются из учёта, а по FBY их формирует склад Маркета из поставок, поэтому для FBY сценарий только читает остатки и оборачиваемость для планирования поставок. SKU сопоставляются с номенклатурой символ в символ: для Маркета «557722» и «0557722» разные товары.
Остатки уходят со страховым запасом, потому что обновление каталога занимает до нескольких минут. Цены передаются с нижней границей, а если новая цена сильно ниже прежней, Маркет может отправить товар в карантин и скрыть его с витрины до подтверждения: такие позиции сценарий собирает в отдельный список для менеджера. Запросы идут через очередь, не больше 4 одновременно, а ошибки разбираются, а не повторяются вслепую, иначе сценарий сам расходует лимит.
Заказы приходят API-уведомлениями: обработчик сразу отвечает Маркету, а заказ разбирает в очереди и передаёт в учёт. Опрос по расписанию остаётся страховкой на случай пропущенного уведомления. Доступ даётся отдельным Api-Key-токеном с минимальным набором прав, который удаляют после окончания работ с подрядчиком. Результат для бизнеса: Маркет работает от тех же данных, что и остальные площадки, а менеджер занимается исключениями, а не переносом цифр.
Сценарий подходит продавцам, которые уже работают с WB и Ozon и добавляют Яндекс Маркет, или начинают с Маркета при учёте в 1С или МойСклад. Особенно полезен при нескольких моделях работы в одном кабинете и ассортименте от сотен SKU. Если интеграция с другими площадками уже есть, учётная часть и правила переиспользуются, а для Маркета пишется свой адаптер.
Опишем, как адаптировать этот сценарий под ваши данные и системы. Без обязательств.
