Что такое виртуальная поставка на Ozon и как не задвоить остатки
Виртуальное отражение партии не означает, что товар уже принят на складе Ozon. Разбираю, чем такой сценарий отличается от обычной поставки, где проверить условия его подключения и как учитывать товар, чтобы не получить лишние остатки и неверный план закупок.
В рабочей таблице я однажды поставил партии статус «на складе» по созданной заявке, а не по документу приёмки. Для планирования закупок этого оказалось достаточно: таблица показывала запас, на который я уже рассчитывал при следующих продажах. Физически товар ещё не был принят. Ошибка была не в арифметике, а в том, что я назвал разные события одинаковыми словами. С виртуальной поставкой на Ozon такая путаница особенно опасна: запись о партии легко принять за подтверждение её фактического наличия.
Я разделяю сведения о будущей поставке, физическое местонахождение товара и количество, которое площадка разрешает продавать. Эти показатели могут относиться к одной партии, но отвечают на разные вопросы. Если свести их в общую колонку «остаток», становится непонятно, что уже можно обещать покупателю и чем получится выполнить это обещание. Поэтому сначала нужно понять механику виртуальной поставки, затем проверить условия именно своего кабинета и только после этого менять учёт. Само слово «виртуальная» ничего не говорит ни о бесплатной доставке, ни об отсутствии обязанности привезти товар.
Что такое виртуальная поставка на Ozon
В контексте предварительного размещения партии виртуальная поставка — это сценарий, при котором информация о товаре отражается в системе раньше его фактической приёмки складом. Его смысл в разделении информационного события и физического движения коробок. Возможность открыть продажи до приёмки, порядок отображения такого количества и последующая передача товара зависят от условий конкретной программы. Обычная заявка на поставку сама по себе не означает подключение такого сценария. У меня нет актуального текста предложения из вашего кабинета, поэтому я не буду обещать, что любой созданный документ автоматически делает товар доступным покупателям.
Чем отличаются обычная и виртуальная поставки
Обычная поставка на склад
Заявка описывает запланированную передачу товара
Фактическое количество подтверждается результатами приёмки
Создание заявки не равно появлению принятого остатка
План продаж зависит от доступности принятого товара
Виртуальная поставка
Информационное отражение партии опережает физическую приёмку
Продажи до приёмки возможны лишь по условиям программы
Обязанность передать товар сохраняется
Предварительный и физический остатки требуют раздельного контроля
Обычный сценарий подходит для планирования по принятому запасу, виртуальный стоит рассматривать при доступной программе и надёжно обеспеченной партии.
Главное отличие здесь не в способе упаковки и не в том, кому принадлежит грузовик. Меняется момент, когда сведения о партии начинают участвовать в работе площадки, а в разрешённых программой случаях — в продажах. При этом товар всё равно должен пройти предусмотренную физическую передачу и приёмку. Я не приравниваю такую поставку к FBS: предварительное отражение будущего складского запаса само по себе не означает отгрузку каждого заказа со своего склада. И не считаю её способом исправить любые расхождения: если название встречается в контексте излишков или корректирующих документов, сначала нужно выяснить назначение именно этой операции.
Лист сборки: что и в каком количестве везти в каждый кластер, со штрихкодами. Печатается на бумагу — сборщик отмечает фактическое количество прямо в нём.
Где проверить условия программы до создания поставки
Я начинаю с предложения или описания функции внутри Ozon Seller, если оно доступно моему магазину. Из него перехожу к действующей справке, условиям участия и документам, на которые ссылается площадка. Названия пунктов меню могут меняться, поэтому искать нужно описание самого сценария, а не пытаться повторить путь по старому скриншоту. Проверяю, для каких товаров и складов он открыт, как подключается и какое событие запускает обязательства продавца. Если в кабинете такого предложения нет, я не делаю вывод, что его можно включить обычным созданием заявки.
Дальше мне нужны ответы на вопросы о доступности товара для покупателей, допустимом объёме партии и сроке её фактической передачи. Отдельно проверяю, что происходит при опоздании, недостаче, отмене поставки или изменении состава. Расходы ищу в применимых тарифах и условиях программы, а не в чужом расчёте, где могли быть другая категория и другой склад. Если описание оставляет двусмысленность, отправляю поддержке конкретный сценарий с товаром, складом и планируемой операцией. Ответ сохраняю вместе с редакцией условий, чтобы позднее понимать, на каком основании я принимал решение.
Не считайте виртуально отражённое количество подтверждением физической приёмки. Перед открытием продаж проверьте, какое именно обязательство возникает по условиям доступной вам программы и чем оно обеспечено. Обещание поставщика отгрузить товар не заменяет готовую партию, если вы уже должны выполнить обязательства перед площадкой. Если момент начала продаж или порядок передачи товара неясен, сначала получите разъяснение, а не проверяйте правила на оплаченных заказах.
По каждому складу видно доступный остаток, резерв и то, что уже едет, — с датой прибытия. Ozon эту дату не сообщает: она считается по заявке на поставку и реальному сроку доставки в кластер, а если срок вышел, а товар всё ещё в пути, дата подсвечивается.
Как виртуальная поставка влияет на остатки и учёт
Для управленческого учёта я веду партию через состояния, а не создаю новый запас при каждом изменении статуса. Товар может оставаться у меня, находиться в пути или быть принятым на складе Ozon. Отдельно храню предварительно заявленное количество и доступность для продажи по данным площадки. Эти сведения нельзя бездумно складывать: доступность описывает возможность заказа, а местонахождение — где лежат уже купленные мной единицы. Ещё нужен резерв под обязательства, иначе товар, обещанный в рамках программы, легко повторно направить в другой канал.
Как провести партию через управленческий учёт
1
Зафиксировать исходную партию
Запишите артикулы, фактическое количество и закупочную стоимость. Отделите уже полученный товар от того, который поставщик только обещал передать.
2
Связать заявку с товаром
Привяжите виртуальную поставку к существующей партии. Не создавайте дополнительный приход только из-за появления записи в кабинете.
3
Выделить обязательства по программе
Отразите резерв согласно действующим условиям и фактическим заказам. Проверьте, не используется ли та же партия для других продаж.
4
Отразить физическую передачу
По подтверждению отгрузки переместите товар из своего склада в путь. Общая стоимость принадлежащего вам запаса от этого движения не увеличивается.
5
Сверить результат приёмки
Перенесите подтверждённое количество в принятый складской запас. Расхождения оставьте отдельной позицией до выяснения, а предварительную запись обновите без повторного прихода.
На этом участке я особенно внимательно смотрю на частичное подтверждение количества и расхождения. Если часть партии принята, оставшиеся единицы нельзя автоматически считать ни потерянными, ни лежащими на складе Ozon. Их состояние нужно подтвердить документами: они могут оставаться в обработке, возвращаться или требовать разбирательства. Для этого в учёте полезна отдельная отметка «расхождение», привязанная к конкретной поставке. Подробности проверки документов и количества я разобрал в статье про доверительную приёмку на Ozon, где объясняю, почему статус операции не заменяет сверку товара.
Есть и менее заметная проблема: разные отчёты могут обновляться в разные моменты. Я сверяю остатки на сопоставимую дату и сохраняю время выгрузки, иначе движение партии выглядит как необъяснимая недостача. Для продажи ориентируюсь на показатель доступности, предусмотренный площадкой, а для оценки имущества — на физические состояния и подтверждающие документы. В бухгалтерском учёте основания для признания и перемещения запасов согласовываю с бухгалтером; управленческая метка не заменяет первичку. Создание виртуальной поставки само по себе не даёт основания объявлять стоимость товара расходом от продажи или признавать выручку.
Как посчитать остаток и где возникает двойной приход
В таблице я показываю условную партию без продаж, возвратов и подтверждённых потерь, чтобы было видно именно движение товара. Это пример управленческого расчёта, а не описание допустимого графика поставки по программе Ozon. Сначала беру исходное фактическое количество, затем распределяю его между своим складом, дорогой и приёмкой. Стоимость каждой части получаю умножением её количества на условную закупочную стоимость единицы. Предварительно заявленную партию показываю справочно, а последние строки помогают увидеть, что случится, если ошибочно добавить её к физическому запасу.
Пример расчёта остатка и двойного прихода — числа условные
Условная закупочная стоимость единицы — 400 ₽. Продаж и потерь нет.
Позиция
Количество
Стоимость
Участие в остатке
Исходная купленная партия
100 шт.
40 000 ₽
База для сверки
Виртуально заявленная партия
100 шт.
40 000 ₽
Справочно, не дополнительный приход
Осталось на своём складе
20 шт.
8 000 ₽
Включается
Находится в пути
20 шт.
8 000 ₽
Включается
Принято складом Ozon
60 шт.
24 000 ₽
Включается
Правильный общий остаток
100 шт.
40 000 ₽
Сумма физических состояний
Остаток с повторным виртуальным приходом
200 шт.
80 000 ₽
Ошибочное сложение
Завышение запаса
100 шт.
40 000 ₽
Несуществующий дополнительный товар
Пример, числа условные. Тарифы и удержания Ozon в расчёте не используются.
В примере из таблицы физические части в сумме полностью объясняют исходную партию. Виртуальная запись не добавляет к ней товар, потому что описывает те же самые единицы. Для повторения расчёта у себя я сначала вычитаю отгруженное количество из собственного склада, затем вычитаю принятое количество из товара в пути. Принятое добавляю в соответствующий складской остаток, а реализованные единицы списываю отдельно по подтверждённым операциям. Возвраты и выявленные расхождения проверяю своими документами, чтобы не маскировать их общей корректировкой. После этого сравниваю сумму физических состояний с расчётным остатком партии.
Конкретная ошибка выглядит просто: продавец загружает виртуально заявленное количество как приход, а после приёмки ещё раз оприходует тот же товар. В примере из таблицы деньги на закупку потрачены однократно, но система показывает лишний запас и завышенную стоимость товара. Это ещё не означает, что такая же сумма уже потеряна наличными. Реальные потери возникают дальше: продавец откладывает нужную закупку, обещает несуществующий товар или направляет обеспечивающую партию в другой канал. Если вдобавок повторно списать себестоимость при обработке разных статусов, отчёт покажет заниженную прибыль. Поэтому я исправляю связь событий с партией, а не подгоняю итоговый остаток вручную.
Кому подходит такой сценарий и что проверить завтра
Я бы рассматривал виртуальную поставку там, где партия уже обеспечена, а физическая передача управляется предсказуемо. Под этим я понимаю подтверждённое наличие товара, понятный маршрут и возможность выполнить требования доступной программы. Дополнительный смысл появляется, если разрешённое условиями предварительное открытие продаж действительно решает задачу магазина. Но ожидаемый спрос не делает поставщика надёжнее и не устраняет задержки перевозки. Если товар ещё предстоит произвести, а дата готовности существует только в переписке, запас прочности у такого решения гораздо меньше.
Обычную поставку я предпочту, если не могу уверенно связать каждое обещание площадке с конкретным товаром. То же касается ситуации, когда складской учёт ведётся общей суммой, а продажи параллельно идут через разные каналы без общего резерва. Виртуальная доступность в таком случае увеличивает число обязательств, но не количество коробок. Отдельно я проверю качество подготовки груза: предварительная запись не отменяет требований к его физической передаче. Проверки перед отгрузкой собраны в статье о том, как упаковать товар для Ozon, чтобы проблемы с подготовкой партии не добавились к рискам планирования.
Экономику такого решения я оцениваю через дополнительные продажи и дополнительные расходы относительно обычного сценария. Из выручки по действительно состоявшимся продажам вычитаю себестоимость, фактические удержания площадки, расходы на передачу партии и прочие затраты, относящиеся к этим продажам. Затем отдельно смотрю, потребовались ли срочная перевозка, дополнительная обработка или деньги на восстановление сорванного графика. Если для программы предусмотрены отдельные начисления, беру их из действующих условий и отчётов, а не подставляю знакомую ставку. Без этих данных нельзя честно утверждать, что виртуальная поставка дешевле обычной или обязательно увеличивает прибыль.
Для нескольких магазинов мне нужен учёт, в котором можно восстановить происхождение числа, а не просто увидеть красивый итог. Из-за этого я и сделал SellOps, не найдя готового решения, которому мог бы доверять свои расчёты. Мой подход к работе с аналитикой описан на странице о том, как устроен сервис, но сама проверка начинается с исходных данных продавца. Ни сервис, ни собственная таблица не определят физическое наличие по одному названию статуса. Поэтому документ поставки, движение партии и результат приёмки я рассматриваю как связанные, но разные события.
Завтра я бы начал с выбранной партии, которую планируется передать на Ozon, и выписал её фактическое местонахождение рядом с состоянием в кабинете. Затем открыл бы действующие условия доступной программы и зафиксировал момент возникновения обязательств, порядок передачи и последствия расхождений. В рабочей таблице разделил бы заявленное количество, собственный склад, товар в пути, принятое количество и резерв. После сверки проверил бы, не попадает ли предварительная запись в общий остаток повторно. Если партия сходится по документам, а обязательства обеспечены товаром, можно оценивать пользу сценария; если нет, сначала нужно исправить учёт и план передачи.
Как передавать коды маркировки в Ozon на FBS и что делать с УПД
Разбираю путь кода от получения товара до сборки заказа FBS, передачи сведений в Ozon и проверки возврата. Объясняю, почему УПД не заменяет код в отправлении, где искать причину ошибки и что меняется при работе по FBO.