Как проверить график выплат Ozon и спланировать закупки

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

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

Где проверить график выплат Ozon Seller

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

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

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

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

Почему деньги за заказ приходят позже доставки

В моих данных за 90 дней есть 20 639 доставленных заказов. Медианный срок доставки по ним — 2 дня, а 80% заказов доезжают за 4 дня и меньше. Медиана здесь показывает середину распределения сроков доставки, а не дату возвращения выручки на счёт. Показатель 80% тоже относится только к доставленным заказам из этой выборки. Ни срок ожидания выплаты после доставки, ни время банковского зачисления в этих числах не измерены.

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

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

Как посчитать разрыв между продажей и выплатой

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

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

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

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

Ошибка в закупках, которую не видно по выручке

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

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

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

Досрочная выплата Ozon Seller и цена ускорения

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

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

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

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