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