Расчёт юнит-экономики и финансовая отчётность по продажам на маркетплейсах
Продажи шли на двух маркетплейсах, а понимание прибыли собиралось из сводных таблиц, которые собирались вручную и устаревали к моменту готовности. Мы построили систему, которая сама забирает данные площадок по API, раскладывает выручку по всем удержаниям и считает юнит-экономику по каждой позиции, а не «в среднем по складу».
- Период
- 2026
- Отрасль
- Производство
Что изменилось
- Excel вручную → автоматически
- Сбор финансовой отчётности по площадкамдо внедрения отчёт собирался руками из выгрузок обеих площадок в сводных таблицах; после данные приходят по API и отчёт формируется системой
- По каждому SKU
- Точность расчёта прибылидо внедрения маржа оценивалась усреднённо по ассортименту; после юнит-экономика считается на уровне отдельной позиции, с учётом её собственных удержаний и логистики
У каждой величины указано, с чем сравнивали и за какой период.
Что было не так
Продажи идут на двух площадках, и каждая отдаёт свои данные по-своему: свои отчёты, свои сроки, свои названия для одних и тех же вещей. Чтобы понять, сколько компания заработала, кто-то выгружал отчёты с обеих, сводил их в таблицу и сверял с тем, что видит производство.
Главная сложность не в объёме работы, а в том, что выручка на маркетплейсе это не то, что приходит на счёт. Между ценой на витрине и деньгами компании лежат комиссия площадки, логистика, хранение, приёмка, возвраты, штрафы и скидки по акциям. Часть этих удержаний приходит позже самой продажи, и привязать их к конкретному товару в сводной таблице вручную практически невозможно.
Поэтому прибыль считалась усреднённо, котлом по всему ассортименту. А в таком расчёте убыточная позиция не видна: она прячется за прибыльными, продолжает продаваться и тихо съедает маржу остальных. Вопрос «какой товар нам невыгоден» не имел ответа, хотя был самым важным.
И отдельно стоит 1С. Учёт жил своей жизнью, отчётность по маркетплейсам своей, и сведение одного с другим было ещё одной ручной операцией в конце периода.
Вопрос «какая позиция приносит убыток» не имел ответа: усреднённый расчёт прятал убыточные товары за прибыльными.
Что мы построили
Систему, которая забирает данные сама. Подключения к API Wildberries и Ozon работают по расписанию: заказы, продажи, возвраты и отчёты о реализации приходят в общую базу без участия человека и приводятся к единому виду так, что позиция с обеих площадок становится одной позицией с двумя каналами продаж.
На этих данных стоит расчёт юнит-экономики. Система раскладывает выручку по всем удержаниям площадки: комиссия, логистика, хранение, приёмка, возвраты, штрафы, скидки. Затем добавляет себестоимость и показывает, сколько компания зарабатывает на конкретной позиции. Не в среднем и не по категории, а по товару.
Поверх этого стоит внутренняя финансовая отчётность: то, что раньше собиралось вручную к концу периода, теперь строится из тех же данных в любой момент. Отчёт перестал быть результатом чьей-то недели и стал состоянием системы.
Позиция с обеих площадок стала одной позицией с двумя каналами продаж, и у неё появилась собственная, а не усреднённая, экономика.
Как данные доезжают целиком
Синхронизация с площадками это не разовая кнопка, а постоянный фоновый процесс, и устроен он так, чтобы переживать сбои. API маркетплейсов отвечают не всегда: лимиты запросов, таймауты, отчёты, которые формируются не мгновенно. Поэтому выгрузки идут очередями задач по расписанию: задача, не выполнившаяся с первого раза, возвращается в очередь, а не теряется молча.
Это важнее, чем кажется. В финансовом отчёте незаметно пропавшая часть данных хуже явной ошибки: отчёт выглядит готовым, цифры правдоподобны, и решение принимается по неполной картине. Очередь с повторами это то, что делает «данные доехали целиком» проверяемым свойством, а не надеждой.
Отдельные удержания приходят от площадки с задержкой, уже после самой продажи. Система привязывает их к тем продажам, к которым они относятся, и пересчитывает экономику позиции, поэтому отчёт за период уточняется по мере поступления данных, а не остаётся снимком на день выгрузки.
Связка с 1С
1С осталась учётной системой компании, система маркетплейсов её не заменяет и не дублирует. Между ними налажен обмен: данные ходят в обе стороны, и та ручная сверка в конце периода, ради которой кто-то садился сводить выгрузки, из процесса исчезла.
Из 1С приходит то, без чего юнит-экономика не считается: себестоимость. Без неё расчёт по площадкам показывает только то, сколько удержала площадка, но не то, заработала ли компания. Обратно уходит отчётность по продажам и удержаниям, уже разложенная по позициям.
В результате учёт и продажи на маркетплейсах перестали быть двумя разными версиями реальности, которые кто-то раз в месяц приводит к согласию.
Что это дало
У компании появился ответ на вопрос, которого раньше не было: сколько приносит каждая позиция после всех удержаний площадки. Это меняет не отчётность, а решения: какой товар двигать, какой пересчитать по цене, какой выводить из ассортимента.
Сбор отчёта перестал быть работой. Данные приходят сами, удержания раскладываются сами, отчёт доступен тогда, когда он нужен, а не через неделю после конца периода.
И расчёт стал воспроизводимым. Пока экономика считается в сводной таблице, она зависит от того, кто и как её собрал; в системе одни и те же данные всегда дают одну и ту же цифру, и эту цифру можно разобрать до исходной строки отчёта площадки.
На чём построено
Технологии проекта взяты из общего реестра компании: у каждой описана роль и класс задач, где мы её применяли.
Интерфейс
- TypeScriptОсновной язык интерфейса
- ReactБиблиотека интерфейсов
Серверная часть
- Node.jsОсновная серверная среда
- FastifyБыстрый веб-сервер на Node.js
- RabbitMQОчередь сообщений между сервисами
- BullMQФоновые и отложенные задачи
Данные
- PostgreSQLОсновная база данных
- RedisКеш, сессии и очереди
Интеграции
- 1СОбмен с учётной системой компании
- Ozon, WildberriesAPI маркетплейсов
Инфраструктура
- DockerУпаковка сервисов в контейнеры
- NginxБалансировка, маршруты, HTTPS
- LinuxСерверная операционная система
Что применяли в проекте
Каждая услуга это отдельный раздел с составом работ и ориентиром по стоимости.
У вас похожая задача?
Первый разговор ни к чему не обязывает: разберём вашу ситуацию и скажем, нужен ли вам такой проект вообще.
Другие проекты
- ИИ-обработка входящих заявок: ответы клиентам в Telegram, почте и на сайтеСистема собирает обращения из трёх каналов, отвечает на них сама по материалам заказчика и передаёт человеку то, что должен решать человек
- Единый канал заявок: Telegram-бот, форма сайта и переписка с клиентом в Битрикс24Заявки из бота и с сайта попадают в воронку Битрикс24 сами, а менеджер отвечает клиенту в Telegram прямо из карточки сделки
- Автосалон: выгрузка автомобилей на Авито и Авто.ру и сбор заявок в Битрикс24Объявления публикуются и обновляются из учётных данных салона, а обращения с обеих площадок попадают в воронку как сделки