Учёт заказов с Ozon и Wildberries в одном месте

Заказ пришёл на Ozon в десять утра, ещё три — на Wildberries к обеду, а вечером нужно понять, сколько единиц товара осталось на складе и сколько бизнес на этом заработал. Если для ответа приходится открывать два личных кабинета и таблицу-«прокладку» в Excel — вы не одиноки. Так работает большинство селлеров, которые начинали с одной площадки, а потом закономерно пришли на вторую. Схема рабочая, но хрупкая — и рано или поздно она перестаёт справляться с объёмом.

Почему учёт по отдельным кабинетам — это боль, а не просто неудобство

У Ozon и Wildberries разные личные кабинеты, разный формат выгрузок, разная логика статусов заказов и разные отчёты о начислениях. Пока заказов пять в день, это терпимо. Больно становится, когда объём растёт.

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

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

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

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

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

Что такое «единый учёт заказов» и что он даёт

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

Все заказы Ozon и Wildberries — в одном списке. Не нужно открывать два кабинета, чтобы понять, сколько заказов пришло за день и на какую сумму. Список общий, статусы сопоставимы, фильтры работают сразу по обеим площадкам.

Единые остатки на маркетплейсах. Товар на складе один и тот же, независимо от того, продаётся он на одной площадке, на двух или ещё и в собственном магазине. Это как раз и защищает от ситуации, когда один и тот же остаток «продан» дважды в разных кабинетах.

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

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

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

Как это работает на практике: интеграция по API

Технически единый учёт строится на подключении личных кабинетов Ozon и Wildberries через API — без ручной выгрузки файлов и последующей загрузки их куда-то ещё. Логика простая:

1. Импорт товаров, остатков и цен. Каталог товаров на Ozon и WB подтягивается автоматически и сопоставляется с товарами на вашем складе — вручную сверять артикулы не нужно.
2. Подтягивание заказов. Новые заказы с Ozon и Wildberries поступают в общий список по мере поступления, со своими статусами и суммами.
3. Синхронизация остатков в обе стороны. Когда товар продан на одной площадке, остаток на складе уменьшается — и это видно во всей системе, а не только в одном кабинете.
4. Учёт денег. Данные по заказам ложатся в финансовый учёт как выручка — без отдельного переноса из отчётов о начислениях.

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

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

FBO, FBS и почему остатки — не такая простая история

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

Ассортимент на Ozon и WB не всегда совпадает

Частая ситуация — часть товаров продаётся только на одной площадке: где-то категория конкурентнее, где-то не подошли требования к карточке или упаковке. Это нормально, но усложняет учёт: если смотреть только на одну площадку, картина ассортимента искажается, а таблица «руками» рано или поздно перестаёт поспевать за новыми SKU. При едином учёте товары на Ozon и WB видны как общий каталог с пометкой, где именно каждая позиция продаётся сейчас, — это упрощает и закупку, и решение о том, куда выводить новый товар.

Что смотреть в отчётности, если торгуете на нескольких площадках

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

Отдельно стоит сравнивать эти показатели между площадками: один и тот же товар может быть прибыльным на Wildberries и убыточным на Ozon (или наоборот) — из-за разной комиссии, логистики и конкуренции в категории. Без разбивки по площадкам это различие просто не видно — в общем отчёте оно усредняется и прячется. Если заказы и склад уже объединены — как, например, в STOKAN, где юнит-экономика считается по каждому товару с учётом комиссий, логистики и себестоимости, — такая разбивка строится сама, а не по итогам ручной сверки в конце месяца.

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

Чек-лист: как навести порядок за одну неделю

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

1. Выпишите все точки продаж — Ozon, Wildberries, возможно собственный сайт или магазин — и отметьте, где именно сейчас считаются остатки и по каким правилам (FBO, FBS или свой склад).
2. Найдите места ручного переноса. Где данные копируются из кабинета в таблицу вручную — именно там чаще всего рождаются ошибки, и именно эти места стоит автоматизировать в первую очередь.
3. Сведите остатки в одно место. Даже если заказы пока обрабатываются раздельно, единый складской учёт уже снимает риск продать то, чего физически нет на обеих площадках сразу.
4. Подключите заказы через API, а не через периодическую выгрузку файлов — это уберёт задержку между продажей и обновлением остатка и избавит от ручного импорта отчётов.
5. Постройте отчёт по марже, а не только по выручке. Оборот без учёта комиссий и логистики — красивая, но обманчивая цифра, которая маскирует убыточные позиции.
6. Проверьте товары по отдельности. Найдите хотя бы одну позицию, которая продаётся, но не приносит прибыли, — и решите, что с ней делать: изменить цену, сменить площадку или снять с продажи.
7. Сравните одинаковые товары между площадками. Если один и тот же SKU продаётся и на Ozon, и на Wildberries, посмотрите, не «кормит» ли он на самом деле только одну из них — на второй позиция может годами держаться в ноль.

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

Вместо вывода

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