COGS в WooCommerce: как учитывать себестоимость товаров и прибыль по заказам

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

В современных версиях WooCommerce есть встроенная функция Cost of Goods Sold (COGS). Она позволяет хранить себестоимость простых товаров и вариаций, фиксировать стоимость проданных позиций в заказе и использовать эти данные как основу для расчёта прибыльности.

Ниже разберём, как включить COGS, как вести данные без потери истории и что проверить, если магазин раньше использовал отдельный плагин себестоимости.

Что такое COGS в WooCommerce

COGS — стоимость проданных товаров. В контексте интернет-магазина это прямые затраты на товар, который был продан: например, закупочная стоимость или производственная себестоимость единицы.

Официальная документация WooCommerce по COGS описывает функцию как способ хранить прямые затраты и получать данные, необходимые для расчёта маржи товаров и заказов.

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

Как включить встроенный COGS

Функция включается в WooCommerce → Settings → Advanced → Features. После активации в редакторе товара появляется поле Cost of Goods.

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

Это важно для каталогов, где один родительский товар имеет варианты с разной закупочной ценой. Например, размер, объём упаковки или комплектация могут менять не только цену продажи, но и реальную себестоимость.

Почему себестоимость должна фиксироваться в заказе

Стоимость закупки меняется со временем. Если сегодня товар обходится магазину в 800 ₽, а через месяц уже в 950 ₽, старый заказ не должен автоматически получить новую себестоимость.

WooCommerce сохраняет COGS на уровне позиции заказа. Поэтому последующее изменение стоимости продукта не переписывает автоматически историческую себестоимость уже созданных заказов.

Это принципиально для аналитики: иначе изменение закупочной цены сегодня изменяло бы показатели прошлых месяцев.

Простой пример расчёта

Допустим, товар продаётся за 3 000 ₽, а его COGS равен 1 800 ₽. Базовая товарная маржа до остальных расходов составляет 1 200 ₽.

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

COGS для вариативных товаров

У вариативного товара себестоимость особенно важно хранить на правильном уровне. Если все вариации реально стоят одинаково, можно использовать общее значение. Если закупочная цена различается, задавайте стоимость каждой вариации отдельно.

Не стоит рассчитывать себестоимость по формуле от розничной цены, если бизнес получает реальные закупочные данные из ERP или склада. Цена продажи может меняться из-за скидок и маркетинга, а COGS должен отражать прямую стоимость товара.

Массовое заполнение через CSV

Для большого каталога ручное редактирование сотен карточек неудобно. Встроенный CSV importer/exporter WooCommerce поддерживает COGS, поэтому данные можно выгружать, корректировать и импортировать обратно.

Перед массовым обновлением сначала экспортируйте небольшой тестовый набор. Проверьте названия колонок, SKU и сопоставление вариаций, затем выполните импорт на нескольких товарах и только после этого обновляйте весь каталог.

Практический процесс массового обновления каталога я отдельно разбирал в статье про импорт товаров WooCommerce из CSV без дублей.

Что происходит с возвратами

Возврат влияет не только на выручку, но и на стоимость проданных товаров. WooCommerce отображает COGS с учётом refunded items, поэтому при анализе заказа нужно смотреть фактическое состояние возврата, а не просто первоначальную сумму.

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

COGS и WooCommerce Analytics — не одно и то же

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

Для бизнеса это не проблема архитектуры данных: COGS уже хранится там, где его можно использовать. Но если нужен отдельный dashboard по марже, категориям, брендам, менеджерам или источникам рекламы, может потребоваться кастомный отчёт или внешняя BI-система.

Например, данные о себестоимости можно сопоставлять с источником заказа. Про UTM и встроенную атрибуцию есть отдельный материал про Order Attribution WooCommerce.

REST API и интеграции

WooCommerce развивает COGS не только как поле интерфейса. При внедрении функции были добавлены программные API и изменения REST API, чтобы себестоимость можно было использовать в интеграциях.

Если стоимость приходит из ERP, склада или поставщика, лучше определить один источник правды. Например, ERP хранит закупочную цену, а WooCommerce получает её при синхронизации. Обратная двусторонняя запись без правил приоритета легко создаёт цикл и перезаписывает актуальные данные устаревшими.

Для синхронизации нужны три правила

• однозначно сопоставлять товар или вариацию по стабильному ID/SKU;
• логировать старое и новое значение себестоимости;
• не переписывать исторические order item costs при обычном обновлении продукта.

Переход с отдельного COGS-плагина

Если магазин уже использует сторонний Cost of Goods plugin, не включайте новую функцию и не удаляйте старое расширение вслепую. Официальная документация предупреждает: при одновременной работе встроенного COGS и другого решения в интерфейсе могут появиться два значения стоимости.

Безопасная миграция начинается с инвентаризации:

1. определить, где старый плагин хранит себестоимость товаров;
2. понять, хранит ли он историческую стоимость в order items;
3. экспортировать контрольную выборку;
4. перенести данные на staging;
5. сравнить товары, вариации и несколько старых заказов;
6. только после проверки переключать production.

Не удаляйте старые meta-поля до подтверждения, что новая система содержит всё необходимое. Резервная копия базы перед массовой миграцией обязательна.

Типовые ошибки внедрения

• в COGS записывают розничную цену вместо прямой себестоимости;
• у вариаций с разной закупкой оставляют одно значение родителя;
• массово импортируют CSV без теста на нескольких товарах;
• перезаписывают исторические заказы текущей стоимостью товара;
• одновременно оставляют два COGS-решения и получают двойные показатели;
• считают разницу цена − COGS полноценной чистой прибылью;
• не определяют источник правды при синхронизации с ERP.

Как внедрять COGS на действующем магазине

1. Сделать резервную копию базы.
2. Проверить версию WooCommerce и доступность встроенной функции.
3. На staging включить COGS.
4. Заполнить несколько простых товаров и вариаций.
5. Создать тестовый заказ и проверить сохранённую стоимость строк.
6. Изменить COGS товара и убедиться, что старый заказ не изменился.
7. Проверить возврат.
8. Протестировать CSV export/import.
9. Если есть ERP — проверить направление синхронизации.
10. После контрольного сравнения переносить процесс на production.

Когда нужна кастомная аналитика

Встроенный COGS хорошо решает задачу хранения прямой себестоимости. Кастомная разработка нужна, когда бизнес хочет учитывать дополнительные переменные: комиссию маркетплейса, фактическую стоимость доставки, упаковку, платежный gateway, рекламный источник или разные закупочные партии.

В таком случае лучше не ломать core WooCommerce, а использовать его COGS как базовый слой и строить отдельный отчёт поверх поддерживаемых API. Для доработок магазина можно посмотреть услугу доработки WooCommerce.

Вывод

COGS в WooCommerce превращает себестоимость из случайного custom field в часть штатной модели магазина. Для простого каталога достаточно включить функцию и заполнить стоимость товаров. Для большого магазина важнее выстроить процесс: вариации, CSV, ERP, исторические заказы, возвраты и проверка миграции.

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