Wildberries 24 июня добавил метод получения подключённых опций и пакетов «Конструктора тарифов». Он находится в разделе информации о продавце: GET /api/common/v1/tariff-constructor/options. Разработчики могут использовать эти сведения, чтобы согласовать настройки внешнего сервиса с конфигурацией конкретного кабинета.

Что стало доступно через API

По объявлению WB, метод возвращает информацию обо всех опциях и пакетах, подключённых продавцом в конструкторе. Вызов доступен через Сервисный токен любой категории. Это означает, что интеграция может опираться на прочитанное состояние кабинета, а не только на список настроек, который сотрудник когда-то вручную занёс во внешнюю таблицу.

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

Почему ручные настройки со временем расходятся

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

Автоматическое чтение настроек позволяет обнаруживать такие изменения. Вместо молчаливой перезаписи формул полезно формировать уведомление: какой пакет появился или исчез, когда система это заметила и какие расчёты используют настройку. Тогда финансовый сотрудник сможет проверить влияние, а разработчик — сохранить воспроизводимую историю конфигурации.

Как внедрить сведения в учётную систему

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

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

Как проверить пользу нового источника

Начните с одного кабинета и сопоставьте результат API с тем, что видит сотрудник в конструкторе. Проверьте полный набор опций и пакетов, включая те, которыми редко пользуются. Если внешний сервис не получает данные, выясняйте причину доступа отдельно от бизнес-состояния: ошибка запроса не должна интерпретироваться как отсутствие подключённых услуг.

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