Габариты в отчёте Маркета отличаются: проверьте источник данных

Выгрузили новые размеры товара, а отчёт API по-прежнему показывает другие значения? До повторной отправки проверьте, чей набор данных вы читаете. Для товара, привязанного к карточке Маркета, поле weightDimensions в отчёте по товарам возвращает габариты этой карточки. Это прямо указано в описании метода Маркета.

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

Соберите данные для одного SKU

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

В рабочую таблицу внесите:

Для отчёта используется POST /v2/campaigns/{campaignId}/stats/skus со списком shopSkus. Документация допускает от 1 до 500 SKU в одном списке. Метод доступен для FBY, FBS, Экспресса и DBS. Для диагностики достаточно одного SKU; расширяйте проверку после того, как поняли происхождение значений.

Разделите отправленные размеры и размеры карточки

Найдите в ответе свою позицию и проверьте наличие marketSku. Это идентификатор карточки Маркета. Если товар уже к ней привязан, рассматривайте weightDimensions как данные карточки, а не как квитанцию с эхом отправленных вами размеров.

Сопоставьте карточку с фактическим товаром: вариант, комплектация и единица продажи должны соответствовать проверяемому SKU. Отдельно сравните размерные поля. По документации отчёта линейные размеры указаны в сантиметрах, вес в килограммах. Перед сравнением приведите исходящие сведения к этим единицам.

Не делайте из этого отчёта вывод о складском контрольном обмере или окончательной сумме логистики. Правило происхождения weightDimensions описывает конкретный ответ API и не заменяет документы обмеров и начислений.

Выберите следующее действие по результату

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

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

Если marketSku отсутствует, не переносите правило о привязанной карточке на этот случай автоматически. Сохраните полный ответ и проверьте состояние сопоставления отдельно. Если проблему не удаётся локализовать, обращение в поддержку должно содержать конкретные запросы и ответы, время, магазин и SKU. Токены и заголовки авторизации из приложений удалите.

Как закрыть проверку

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

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