Зелёная галочка ещё не означает, что цена изменилась: как проектировать кабинет селлера

Я Антон Фокин, CEO Qtim. В едином кабинете селлера самая важная часть скрыта за интерфейсом: система должна различать отправку данных и подтверждённый результат.

Один статус превращает сбой в сюрприз

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

Документация WB API для цен и скидок прямо предусматривает проверку результата загрузки. Поэтому зелёная галочка сразу после запроса сообщает только об одном этапе. Для рабочего интерфейса нужны четыре состояния:

• создано;

• отправлено;

• принято в обработку;

• применено или отклонено.

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

У цены, остатка и заказа разные источники истины

Цена может рассчитываться в ERP, физический остаток храниться в 1С или WMS, а доступное к продаже количество зависеть от резервов. Маркетплейс подтверждает собственную проекцию этих данных.

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

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

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

Очередь исключений полезнее ещё одного графика

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

• отклонённые цены;

• расхождения остатков;

• заказы между статусами;

• документы, которые не сформировались.

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

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

Одна операция, две площадки и итоговые статусы

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

В проекте HOTZ мы реализовали смежный механизм: единый каталог и двусторонний обмен с 1С для товаров, остатков и заказов. В проекте для «Тепломаш» общая платформа синхронизировала каталоги, цены, остатки и обработку заказов трёх брендов. Это системы другого типа, но архитектурная задача похожа: согласовать данные нескольких контуров в одном слое.

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

Критерий короткий: если сотрудник завершает одну бизнес-операцию в нескольких системах, единому кабинету есть что объединять.

На странице о разработке личных кабинетов и экосистем мы подробнее описали состав такого решения.