Цена уже изменилась, остаток ещё старый: где ломается единый кабинет селлера
Менеджер обновил цену и увидел зелёную галочку. На соседней вкладке остаток всё ещё прежний, а в кабинете маркетплейса товар уже участвует в акции. В этот момент непонятно главное: данные отправлены, приняты или действительно применены?
Обычный интерфейс скрывает рассинхронизацию за словом «успешно». Команда замечает её позже: когда заказ приходится отменять, скидка съедает маржу или бухгалтерия не находит закрывающий документ.
Привет, я Антон Фокин, CEO Qtim. Расскажу, из каких состояний складывается единый кабинет селлера, почему одной интеграции с API недостаточно и с какой операции стоит начинать собственную систему.
Зелёная галочка скрывает четыре разных состояния
Кнопка «Обновить цену» запускает цепочку. Кабинет формирует запрос, отправляет его на площадку, получает технический ответ, а затем ждёт результата обработки. На каждом шаге операция может остановиться.
Поэтому у изменения цены должно быть хотя бы четыре понятных состояния:
- создано в кабинете;
- отправлено на площадку;
- принято в обработку;
- применено или отклонено с причиной.
Если объединить их в одно «готово», интерфейс начинает врать. HTTP-ответ подтверждает доставку запроса, но ещё ничего не говорит о карточке товара. В документации WB API для загрузки цен и скидок отдельно предусмотрена проверка обработанного запроса: часть товаров может не обновиться, и причину нужно получить после отправки.
Похожая логика нужна для остатков, заказов и документов. Единый кабинет хранит идентификатор своей операции, идентификатор операции площадки, исходные данные, текущий статус и текст ошибки. Тогда менеджер видит, где именно остановился процесс, а разработчик может восстановить его по журналу событий.
Второй вопрос — источник истины. Цена может рассчитываться в ERP или отдельном сервисе, физический остаток жить в 1С или WMS, а доступное к продаже количество зависеть от резервов и правил конкретного маркетплейса. Перед разработкой мы фиксируем владельца каждого поля. Иначе две системы начинают по очереди перезаписывать друг друга, а «последнее обновление» превращается в случайную победу одного канала.
Цена и остаток приезжают в витрину с разной скоростью
На экране цена и остаток стоят рядом, поэтому легко принять их за единый набор данных. Для интеграции это две независимые команды со своими ограничениями, очередями и ошибками. Так и возникает сценарий «Цена уже изменилась, остаток ещё старый»: обновления доходят до площадки и подтверждаются независимо.
Маркетплейс может принять пакет цен, поставить его в обработку и вернуть итог позже. Запрос по остаткам способен пройти быстрее, но столкнуться с лимитом API при массовом обновлении. Официальная документация WB API отдельно описывает лимиты запросов и ответы 429 и 5xx. Такой ответ нельзя превращать в бесконечную серию повторов: она только усиливает нагрузку и отодвигает восстановление.
Мы закладываем управляемую очередь. После временной ошибки операция ждёт следующей попытки с растущим интервалом. Постоянная ошибка — например, некорректное значение — попадает в очередь исключений с понятной причиной. Повторная отправка использует тот же ключ идемпотентности, чтобы восстановление связи не создало дубль.
Для пользователя важны четыре времени: когда значение изменили в исходной системе, когда кабинет отправил его, когда площадка приняла запрос и когда результат подтвердился. Подпись «обновлено в 12:40» без уточнения события бесполезна. Она создаёт уверенность там, где пока есть только ожидание.
На главном экране лучше показать простую связку: текущее значение в источнике, подтверждённое значение на площадке, время последней сверки и действие при ошибке. Расхождение тогда становится рабочей задачей, а не сюрпризом в отчёте.
Один заказ проходит через несколько словарей статусов
С заказами сложнее: состояние меняется по обе стороны интеграции. Площадка создаёт заказ и переводит его по своей схеме. ERP резервирует товар. Склад подтверждает сборку. Служба доставки добавляет ещё один набор событий.
API Яндекс Маркета позволяет получать заказы через уведомления или регулярные запросы. Оба способа требуют контроля: уведомление может прийти повторно, а периодический опрос — временно не получить данные. Собственный кабинет должен принять событие один раз, сохранить исходный код площадки и перевести его во внутреннее состояние.
Полностью сводить разные словари к пяти универсальным словам опасно. Статус «готов к отгрузке» на двух площадках может требовать разных действий и документов. Поэтому интерфейс показывает понятное бизнес-состояние, а внутри сохраняет внешний код и историю переходов. Поддержка сможет ответить, почему заказ оказался в текущей точке, не собирая картину по скриншотам.
Остаток тоже нельзя хранить одним числом. Обычно команде нужны физическое количество, резерв, доступно к продаже и подтверждённое значение на каждой площадке. Формула доступного остатка должна находиться в одном месте. Когда её копируют в ERP, кабинет и интеграционный скрипт, расхождение становится вопросом времени.
Здесь особенно важна идемпотентность. Повторное событие не должно повторно списывать товар, создавать второй документ или запускать ещё одну отгрузку. Для менеджера это незаметная техническая деталь. Для бизнеса — защита от отмен, двойных операций и долгого ручного разбора.
Файл сформирован — документ ещё не получен
Документы редко попадают в первый прототип, потому что команда сосредоточена на каталоге и заказах. Потом выясняется, что менеджер по-прежнему скачивает отчёты на каждой площадке, переименовывает файлы и сверяет периоды.
Некоторые документы формируются асинхронно. В API Яндекс Маркета отчёт сначала нужно запросить, затем дождаться готовности и только потом получить файл. Кнопка «Скачать» в собственном кабинете должна отражать эту цепочку: запрос создан, отчёт формируется, файл готов, генерация завершилась ошибкой.
Сам файл — лишь часть объекта. Рядом нужны тип документа, площадка, юридическое лицо, период, версия, дата формирования и связь с заказами или выплатой. Если площадка пересобрала отчёт, кабинет обязан сохранить, какая версия ушла в бухгалтерию.
Полезный интерфейс отвечает на три вопроса без переписки: за какой период документ, готов ли он и кто уже его выгрузил. Так раздел с файлами становится частью процесса, а не общей папкой с непонятными названиями.
Главный экран кабинета — очередь исключений
Первый макет единого кабинета часто строят вокруг графиков: выручка, число заказов, остатки по складам. Эти данные полезны руководителю, но операционная команда открывает систему ради другого. Ей нужно понять, что сегодня требует вмешательства.
Мы выносим на первый экран:
- цены, которые площадка отклонила;
- товары с расхождением остатков;
- заказы, застрявшие между статусами;
- документы, которые не сформировались в ожидаемый срок.
Каждая строка ведёт к операции с историей: кто изменил данные, что отправил кабинет, какой ответ пришёл, сколько было попыток и что можно сделать сейчас. Для исправимой ошибки нужна кнопка повторной отправки. Для ошибки в исходных данных — ссылка на поле, которое следует изменить. Для недоступного API — время следующей попытки.
Журнал аудита здесь важнее красивой ленты активности. Он связывает действие сотрудника, версию данных и внешний ответ. Без этой связи спор «кто поменял цену» заканчивается поиском по чатам и логам нескольких систем.
Роли тоже проектируют вокруг операций. Категорийный менеджер меняет цены, сотрудник склада работает с отгрузкой, бухгалтер скачивает документы, руководитель видит сводную картину. Возможность посмотреть данные ещё не означает право повторить запрос или отменить действие.
Первый релиз должен провести одну операцию до конца
Попытка сразу объединить каталог, аналитику, рекламу, финансы и документы растягивает проект и откладывает проверку ключевой гипотезы. Для первого релиза лучше выбрать одну бизнес-операцию и провести её через весь контур.
Например: менеджер меняет цену в исходной системе, кабинет отправляет обновление на две площадки, получает итоговые статусы, показывает расхождения и позволяет безопасно повторить неуспешную операцию. В этом сценарии уже проверяются модель данных, очередь, права, журнал и обработка ошибок. Следующий поток можно добавлять на готовую основу.
В проекте HOTZ мы строили смежный механизм: единый каталог и двусторонний обмен с 1С для товаров, остатков и заказов. В проекте для «Тепломаш» общая платформа синхронизировала каталоги, цены, остатки и обработку заказов трёх брендов. Это не кабинеты селлера, однако в них виден тот же архитектурный принцип: один слой координирует данные нескольких систем и хранит правила обмена в понятном месте.
Собственная разработка нужна не каждому продавцу. При одной площадке, небольшом ассортименте и простых процессах команде часто достаточно штатного кабинета или готового коннектора. Свой слой оправдан, когда одна операция проходит через несколько площадок, ERP, склад и документооборот, а цена расхождения выше стоимости поддержки системы.
Критерий можно сформулировать в одну строку: если сотрудник завершает одну бизнес-операцию в нескольких системах, единому кабинету есть что объединять.
Начать стоит с карты источников данных и одного сквозного сценария. На странице о разработке личных кабинетов и экосистем мы собрали, какие интеграции и операционные механизмы обычно входят в такой контур.
