Себестоимость проданного, если закупочная цена менялась: как это считает сервис

Открываете отчёт по одному и тому же артикулу — и видите разную себестоимость в разных строках: у мартовского заказа одна цифра, у июньского другая. Это не сбой и не рассинхрон данных: каждый заказ считается по закупочной цене, которая действовала на дату его продажи, а не по той, что стоит в карточке товара сейчас. Как правильно заводить новую цену датой, а не переписывать старую, — уже разобрано в статье «Что входит в себестоимость товара, кроме цены закупки». Здесь — другой вопрос: как читать готовый отчёт, если в нём уже несколько цен на один SKU, и почему сумма за период не равна «цена × количество».

Почему у одного артикула в отчёте разная себестоимость в разных строках

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

Возьмём пример. По артикулу заведены две цены: 400 ₽ — действовала до 9 июня включительно, 520 ₽ — с 10 июня (поставщик поднял закупку). Заказ от 3 марта посчитается по 400 ₽, потому что в марте действовала именно эта цена. Заказ от 12 июня посчитается уже по 520 ₽ — на дату этой продажи в истории действует новая запись. Оба числа в отчёте верны одновременно: они просто относятся к разным заказам одного и того же товара, проданным по разные стороны от даты смены цены.

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

Как это суммируется за период

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

Проверить это легко от противного. Если бы сервис считал себестоимость за период по текущей цене (520 ₽ × 4 заказа), вышло бы 2 080 ₽ — расходы марта и мая оказались бы завышены на 240 ₽, хотя тогда партия стоила дешевле. Если бы, наоборот, взять старую цену (400 ₽ × 4 заказа) — 1 600 ₽, и уже занижены были бы расходы июня и июля. Реальная сумма — 1 840 ₽, потому что у каждого заказа своя цена, действовавшая именно в день его продажи.

Здесь стоит сказать честно, чего в этом расчёте нет. Это не средневзвешенная себестоимость (WAC) — сервис не считает одну общую цену на весь склад пропорционально объёму каждой партии. Это и не списание по очереди прихода (FIFO) — нет понятия «сначала продаётся старая партия, потом новая», нет остатков по партиям и нет выбора, из какой партии списать конкретную единицу. Партионного учёта в сервисе нет вовсе — правило одно и то же для каждого заказа: себестоимость берётся по цене, действовавшей на дату продажи, и ничего не усредняется ни с ценой до, ни с ценой после.

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

Если сравниваете со своей бухгалтерией и не сходится

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

Проверяется это за пару минут: откройте историю цены по конкретному артикулу (устройство истории разобрано в статье «Себестоимость и история закупочных цен») и сверьте даты начала действия с датами реальных поставок или счетов от поставщика. Если дата в системе расходится с тем, когда цена изменилась по факту, — поправьте её на верную; как найти нужную запись и изменить дату конкретной цены — в статье «Раздел „Цены“: закупочная стоимость товаров». После правки прошлые заказы в затронутом интервале пересчитаются автоматически.

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

Общая формула прибыли, куда себестоимость входит одним из слагаемых, — в статье «Как считается прибыль» (пример там разобран на Wildberries, но сама формула — комиссия, логистика, себестоимость по дате продажи и налог — общая для всех площадок).

Если цена так и не задана

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

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

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

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