У меня расходилась стоимость проданного товара, хотя количество продаж в таблице совпадало с отчётом магазина. Причина была в закупках: товар приходил по разной цене, а в справочнике оставалась только последняя себестоимость. Когда я обновлял её для новой поставки, старые продажи тоже начинали выглядеть иначе, словно поставщик задним числом изменил условия. Самое неприятное обнаруживалось при планировании следующего заказа: расчёт обещал свободные деньги, но часть средств уже была связана в товаре. После таких расхождений я стал проверять учёт не по красивому итоговому отчёту, а по возможности восстановить путь конкретной партии.
С несколькими магазинами эта проблема становится заметнее: товар может лежать у меня, ехать на приёмку, находиться на складе площадки или возвращаться от покупателя. Одновременно деньги за уже состоявшуюся продажу ещё не обязательно поступили на расчётный счёт. Поэтому, когда я выбираю программу для учёта товаров на маркетплейсе, меня интересуют связанные между собой движения товара и денег, а не просто перечень доступных отчётов. Ниже я разделю эти задачи и покажу порядок расчёта, который можно сначала проверить даже в таблице. По нему же удобно проверять сервис до переноса рабочих данных, пока ошибка ещё не затронула весь учёт.
Почему аналитика продаж не заменяет товарный учёт
Аналитика продаж отвечает на вопрос, что происходило со спросом и результатами продаж за выбранный период. Я смотрю через неё, какие позиции продаются, где меняется выручка и какие расходы ухудшают результат. Но график продаж сам по себе не объясняет, из какой закупочной партии списан товар и сколько эта партия стоила с доставкой до моего склада. Если исходной себестоимости нет, сервис может показать результат без неё либо использовать заданное продавцом приближение. Поэтому совпадение выручки с кабинетом ещё не доказывает, что прибыль посчитана на полных данных.
Товарный учёт начинается раньше продажи: с поступления, принадлежности товара и его стоимости. Складской учёт маркетплейса должен показывать, где находится товар, какие движения уже подтверждены и что пока нельзя обещать покупателю. Управленческий учёт селлера связывает эти сведения с расходами, обязательствами и результатом бизнеса, чтобы я мог решить, какую закупку потяну и какой товар стоит пополнять. При этом деньги на счёте остаются отдельным показателем: их наличие не означает, что все обязательства уже оплачены. Мне нужен не общий красивый баланс, а возможность перейти от итоговой суммы к операциям, из которых она сложилась.
Финансовый учёт для маркетплейса я проверяю по тому, различает ли он продажу, начисления площадки и фактическое поступление денег в банк. Между этими событиями могут появляться удержания, возвраты и корректировки, поэтому переносить сумму заказа прямо в свободные деньги нельзя. Часть исходных сведений я беру из кабинета, а затем сопоставляю их с закупками и банковскими операциями. В статье про я разбираю, какие данные искать на стороне площадки. Но ни один отчёт площадки не узнает сам, сколько я заплатил поставщику вне Ozon, если эти сведения не внесены или не загружены в систему.