01 С этой ситуацией обращаются
- 01 продавцу вернулся другой товар, неполный комплект или товар с повреждениями
- 02 товар числится возвращённым, но фактически продавец его не получил
- 03 площадка зафиксировала утрату товара или спорный логистический статус
- 04 продавцу отказали в компенсации
- 05 появилось удержание, корректировка или иное финансовое последствие
- 06 в кабинете и финансовом отчёте указаны разные основания одной операции
- 07 есть спор о том, на каком этапе возникли подмена, брак, недостача или повреждение
- 08 поддержка ссылается на системный статус, но не объясняет, какие события подтверждают этот вывод
Первый вопрос Бюро — не «как отменить санкцию», а «какая проверяемая цепочка данных привела платформу к этому выводу».
02 Что именно мог зафиксировать маркетплейс
Маркетплейс фиксирует не намерение продавца или покупателя, а цифровые события внутри своей информационной среды. В зависимости от конкретной ситуации значение могут иметь:
- 01 создание поставки или заказа
- 02 приёмка товара
- 03 присвоение логистического статуса
- 04 движение между складом, сортировочным центром и ПВЗ
- 05 выдача товара покупателю
- 06 оформление возврата
- 07 повторная приёмка возвращённого товара
- 08 изменение статуса товара
- 09 финансовая корректировка, удержание или компенсация
Факт цифрового события и вывод о нарушении — не одно и то же. Между ними должна существовать проверяемая связь.
03 Какие цифровые признаки могут потребовать проверки
В конкретной ситуации значение могут иметь:
- 01 временные метки приёмки, выдачи, возврата и повторной приёмки
- 02 последовательность логистических статусов
- 03 идентификаторы заказа, поставки, возврата и товара
- 04 сведения о складе, ПВЗ или ином логистическом этапе
- 05 данные о весе, габаритах и комплектации
- 06 фото- и видеоматериалы, если они доступны
- 07 сведения о возврате, отказе или переупаковке
- 08 данные финансового отчёта продавца
- 09 история обращений в поддержку
Бюро не предполагает заранее, какие именно технические признаки использовала платформа. Сначала устанавливается, какие данные действительно следуют из уведомления, правил площадки и доступных материалов.
04 Где возникает риск ошибочной квалификации
Одинаковый внешний результат может иметь разное происхождение. Причиной могут быть:
- 01 ошибка комплектации до поставки
- 02 повреждение при перевозке
- 03 ошибка при приёмке
- 04 пересорт
- 05 возврат покупателем
- 06 неполный возврат
- 07 подмена товара
- 08 утрата на одном из логистических этапов
- 09 ошибка сопоставления цифровой записи с конкретной единицей товара
Поэтому итоговый статус или ограничение требует отдельной проверки фактической цепочки происхождения событий.
05 Что необходимо разделить
При проверке важно не смешивать четыре разных уровня:
- 01 Факт физического события. Что произошло с конкретной единицей товара
- 02 Цифровая запись. Какой статус и в какой момент сформировала система
- 03 Квалификация платформы. Как маркетплейс объяснил причину события и связал её с определённым этапом или лицом
- 04 Финансовая мера. Удержание, отказ в компенсации, перерасчёт, списание или другое последствие
Связь между цифровым событием и алгоритмической оценкой ещё не означает автоматически, что применённая мера обоснована. Проверяется вся последовательность — от происхождения события до последствия для продавца.
06 Wildberries
Для Wildberries проверка начинается не с общего предположения о «подмене» или «утрате», а с конкретного основания, которое отражено в кабинете продавца, отчёте реализации, уведомлении платформы, детализации удержания или действующей редакции оферты. При разборе важно сопоставить номер заказа или возврата, дату выдачи и возврата, логистические статусы, дату применения удержания, данные финансового отчёта, доступные фото- и видеоматериалы и историю обращений в поддержку.
Главный вопрос — совпадает ли фактически зафиксированная последовательность событий с тем основанием, по которому Wildberries применил меру.
07 Ozon
Для Ozon проверка строится по тем же принципам, но правила и механика площадки анализируются отдельно от Wildberries. Устанавливается, какой статус Ozon присвоил товару или возврату, к какому заказу относится событие, какие логистические статусы ему предшествовали, какое финансовое последствие возникло и как платформа сформулировала основание.
Сначала проверяется, какое конкретное основание указала или применила платформа.
08 Какие данные и документы нужно сопоставить
Для первичной проверки важно собрать не максимум документов, а минимальный набор, который позволяет восстановить спорную цепочку событий. Обычно сопоставляются:
- 01 уведомление маркетплейса
- 02 скриншоты личного кабинета
- 03 номера спорных заказов, поставок и возвратов
- 04 даты приёмки, выдачи и возврата
- 05 логистические статусы
- 06 фото и видео упаковки, получения и распаковки, если имеются
- 07 акты, претензии и обращения в поддержку
- 08 детализация финансового отчёта
- 09 редакция оферты и правил, действовавшая в соответствующий период
Сначала восстанавливается минимальный доказательный контур, после чего становится понятно, каких данных действительно не хватает для проверки основания решения платформы.
09 Что проверяет Бюро
Бюро восстанавливает проверяемую последовательность событий и сопоставляет цифровой, финансово-хозяйственный и договорный контекст. В рамках проверки можно:
- 01 восстановить точную хронологию спорных событий
- 02 сопоставить доступные цифровые, финансовые и документальные данные
- 03 определить, какая редакция правил действовала на дату события
- 04 проверить, соответствует ли применённая мера указанному основанию
- 05 отделить факт цифрового события от алгоритмической оценки
- 06 выявить противоречия между данными кабинета, документами, финансовым отчётом и объяснением платформы
- 07 установить, какие выводы подтверждаются материалами, а какие остаются предположением
- 08 определить, каких данных не хватает для дальнейшего разбора
- 09 подготовить структурированную позицию для обращения в поддержку, претензионной работы или передачи профильному юристу
Проверка строится не вокруг предположения, что платформа ошиблась, а вокруг вопроса: подтверждается ли её вывод всей доступной цепочкой данных и применимых правил.
10 Что нельзя утверждать без подтверждения
До анализа конкретных данных нельзя заранее утверждать, что маркетплейс ошибся или что спорная ситуация имела только одно объяснение. Бюро не заявляет без подтверждения, что:
- 01 подмена была совершена покупателем, сотрудником ПВЗ, склада или продавцом
- 02 товар был утрачен именно на конкретном логистическом этапе
- 03 любой спорный возврат автоматически даёт право на компенсацию
- 04 системный статус платформы сам по себе доказывает фактическую причину события
- 05 удержание или отказ в компенсации автоматически являются неправомерными
- 06 компенсация или возврат денежных средств гарантированы
Граница между техническим признаком, алгоритмической оценкой и доказанным фактом устанавливается только по материалам конкретной ситуации. Именно здесь определяются границы допустимой цифровой атрибуции.
11 Что может быть результатом проверки
Результатом проверки становится не общий вывод «платформа права» или «платформа ошиблась», а структурированная картина того, что подтверждается данными и на чём основано применённое решение. По итогам могут быть сформированы:
- 01 хронология движения конкретного товара
- 02 карта логистических статусов и физических событий
- 03 сопоставление возврата или утраты с финансовой операцией
- 04 перечень противоречий и расхождений
- 05 анализ применённого основания и действовавшей редакции правил
- 06 перечень данных, которых не хватает для окончательного вывода
- 07 структурированная позиция для обращения в поддержку или претензионной работы
- 08 техническая часть материалов для профильного юриста
Контур М4 используется как дополнительный слой проверки цифрового основания и не заменяет решение суда, экспертизу, работу профильного юриста или полномочия самой платформы.
12 Официальные источники
Wildberries
Ozon