Маржа четырёх маркетплейсов в одной системе

Ситуация

С чего всё начиналось

E-commerce бизнес продаёт через несколько маркетплейсов и ведёт учёт в МойСклад. Нужен общий контур для финансов, закупок, категорийных менеджеров и performance-команды.

Продажи, комиссии, логистика, реклама и остатки жили в разных кабинетах. P&L по SKU собирался вручную и не давал надежной картины маржи.

Что изменено

Что я сделал

Спроектировал слои raw/core/analytics, описал правила финучёта P&L, собрал витрины и логику экрана решения, добавил сверки и критерии приёмки.

• Выручка признается по дате события маркетплейса, возвраты сторнируют тот же аналитический контур.
• Комиссия, логистика, хранение, эквайринг, себестоимость и реклама нормализуются в единую управленческую P&L структуру.
• SKU, юрлица, склады и площадки приводятся к справочникам перед расчётом маржи.
• Contribution profit, EBITDA и чистая прибыль считаются через управленческий план счетов, а не через сырые статьи кабинетов.

Что получилось

Результат

P&L по SKU стал доступен в начале месяца: 10-е → 2-е число

• Финансовый срез по SKU переносится из позднего ручного закрытия в ранний управленческий цикл.
• SKU с отрицательной маржей и дефицитом стали видны до закрытия периода, а не после ручной сверки.
• Финансы, закупка и performance получили один источник для решений по цене, рекламе и пополнению.

Как это проверено

Проверка и границы

• Итоговая выручка витрины сверяется с выгрузками кабинетов с заданным допуском.
• Контрактные проверки контролируют типы, обязательные поля и диапазоны.
• Reconciliation остатков выполняется против учётного источника на конец дня.
• Приёмка проверяет разрезы P&L, SLA загрузки и корректность drilldown.

публичный кейс обезличен; рабочий dashboard использует демо-данные. не заявляется рост прибыли; показан переход к раннему управленческому решению по марже.

Техническое приложение

Как устроено внутри

Для тех, кто проверяет решение по существу: источники, слои данных, правила расчёта и артефакты передачи.