Обратная логистика Ozon — за что я плачу при невыкупах и возвратах

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

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

За какой путь товара назад платит продавец

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

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

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

Почему больше невыкупов обычно означает больше расходов

По моим магазинам за 90 дней доля возвратов от выкупа составила: Магазин 1 — 4,5%, Магазин 2 — 3,3%, Магазин 3 — 2,0%, Магазин 4 — 1,0%. В среднем показатель равен 2,4% при выкупе 46 659 431 ₽. Эти данные показывают, насколько различается соотношение возвратов и выкупа между магазинами. Они не показывают стоимость обратной перевозки и не заменяют долю невыкупленных отправлений. У меня нет в этом наборе фактов суммы обратной логистики, поэтому выводить её из стоимости выкупа я не буду.

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

Где искать обратную логистику в Ozon Seller

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

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

Чтобы ответить, сколько стоит обратная логистика Ozon для конкретного товара, я сопоставляю начисление с действующим условием тарификации. Проверяю схему работы, параметры товара, маршрут и дату оказания услуги — именно те признаки, от которых по документам зависит расчёт. Универсальную цену за возврат я здесь не называю: без этих данных она только вводит в заблуждение. Разницу между схемами работы удобнее проверять через сравнение полной стоимости продажи на ФБО и ФБС, а не через отдельную комиссию. Если операция остаётся непонятной, сохраняю её идентификатор и запрашиваю расшифровку у поддержки, вместо того чтобы подгонять таблицу под итоговую выплату.

Как посчитать обратную логистику на одну продажу

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

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

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

Ошибка, из-за которой невыкупы выглядят бесплатными

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

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

Что проверить в своих заказах завтра

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

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