Что значит статус «Ищем товар» на Ozon и как не потерять компенсацию

Возврат с отметкой «Ищем товар» я поначалу оставлял без отдельной записи: раз площадка ищет, значит, остаётся дождаться результата. Ошибка была не в ожидании, а в том, что у меня не было следующего действия по этому случаю. Товар ещё не вернулся в доступный остаток, деньги за него не поступили, а я уже переключился на поставки и рекламу. При следующей сверке приходилось заново искать отправление и вспоминать, что произошло. С тех пор такую отметку я воспринимаю как повод завести отдельную строку контроля, а не как обещание, что вопрос закроется сам.

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

Что означает «Ищем товар» у отправления или возврата

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

Дальше я смотрю последнюю подтверждённую операцию: что было принято, передано или доставлено до начала поиска. Отдельно проверяю количество, потому что проблема с частью отправления не должна превращаться в списание всего его состава. Если товар продавался по FBS, подтверждение передачи площадке особенно нужно для восстановления цепочки движения. При FBO я также начинаю с документов и событий по товару, а не с предположения, что ответственность уже установлена самим статусом. Продавцу в Ozon Seller нужна история его отправления: объяснение похожей надписи в покупательском приложении не заменяет проверку продавцовских документов.

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

Сколько длится поиск и что проверять во время ожидания

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

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

Чем заканчивается поиск и когда случай действительно закрыт

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

Масштаб возвратов объясняет, почему я не держу такие вопросы в памяти. По моим магазинам за 90 дней доля возвратов от выкупа составила: Магазин 1 — 4,3%, Магазин 2 — 3,4%, Магазин 3 — 2,0%, Магазин 4 — 1,0%. Средний показатель в переданных расчётах — 2,4% при выкупе 48 108 742 ₽. Здесь речь именно о возвратах относительно выкупа, а не о доле потерянных отправлений. Эти данные дают контекст для контроля возвратов, но не позволяют определить, сколько товаров искали и по скольким полагалась компенсация.

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

Как посчитать потери и проверить компенсацию

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

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

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

Как найти потерянный товар на Ozon и не забыть про деньги

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

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

Завтра я бы начал с просмотра доступных разделов отправлений и возвратов, где остались случаи со статусом «Ищем товар», и перенёс их в отдельную таблицу. Для каждого записал бы последнее событие, недостающий документ и конкретное следующее действие: проверить движение, уточнить порядок поиска или сверить компенсацию. Затем отдельно просмотрел бы случаи, где статус уже сменился, но подтверждения получения товара или расчётов пока нет. Для каждого ожидания поставил бы дату следующей проверки, не выдавая собственный рабочий срок за установленный Ozon. Закрывать такую строку стоит не потому, что надпись исчезла, а потому, что понятно, что стало с товаром и чем закончились расчёты.