Объединить несколько выгрузок в одну таблицу несложно. Сложно сделать так, чтобы итог можно было проверить.
В одном файле продажа может быть строкой заказа, в другом — товаром, в третьем — финансовой операцией. Даты, знаки и идентификаторы означают разное. Простое копирование колонок создаёт красивую сводку, но часто уничтожает путь к источнику.
Правильный единый отчёт строится в три слоя: исходные данные → нормализованные операции → управленческая сводка.
Шаг 1. Зафиксируйте назначение
Сначала запишите, какое решение поддерживает отчёт. Для прибыли нужны продажи, возвраты, услуги, реклама и себестоимость. Для выплат — начисления, удержания и банк. Для запасов — товар, склад, статус и момент снимка.
Не пытайтесь поместить все бизнес-вопросы в одну строку. У каждого набора должно быть своё зерно: минимальная единица записи.
Шаг 2. Сохраните исходный слой
Каждую выгрузку храните без ручного редактирования. Вместе с ней фиксируйте:
- источник и кабинет;
- имя файла или пакет загрузки;
- период;
- время получения;
- версию схемы;
- контрольное количество строк и сумму.
Исходный слой нужен не для отчёта руководителю, а для доказательства. Если итог изменился, команда должна вернуться к конкретной строке, а не к неизвестной копии Excel.
Шаг 3. Создайте карту полей
Для каждого источника опишите соответствие общей модели.
| Общее поле | Возможные исходные значения | Правило |
|---|---|---|
| product_id | SKU, vendor code, marketplace item ID | хранить все ID, выбрать стабильный внутренний ключ |
| operation_type | sale, return, logistics, storage, fee | нормализовать через справочник, не по свободному тексту |
| event_at | order date, sale date, report date, payout date | хранить тип даты рядом со значением |
| amount | начисление или удержание | закрепить знак для каждого типа операции |
| source_ref | order ID, report row, operation ID | не терять при агрегации |
Не называйте две разные сущности одинаково. «Сумма» без валюты, типа операции и знака не является аналитическим полем.
Шаг 4. Нормализуйте, не стирая происхождение
Нормализованная строка должна содержать бизнес-поля и технический след:
источник → кабинет → файл/пакет → исходная строка → правило преобразования → нормализованная операция.
Если один исходный документ превращается в несколько операций, связь должна сохраниться. Если строка отклонена, храните причину: неизвестный SKU, неверная дата, отсутствующая валюта или неподдержанный тип.
Шаг 5. Разделите даты и знаки
Заказ, реализация, отчёт и выплата могут попадать в разные периоды. Выберите главную дату для каждой сводки, но не удаляйте остальные.
Так же поступайте со знаком. Продажа, возврат, компенсация и удержание должны иметь документированное направление. «Исправить минусы» вручную — быстрый путь к двойному учёту.
Шаг 6. Соберите управленческую сводку
Только после нормализации создавайте показатели:
- признанная выручка;
- возвраты и корректировки;
- комиссии и услуги;
- логистика и хранение;
- реклама;
- себестоимость;
- прибыль и маржа;
- начисления и выплаты.
Сводка может быть по периоду, товару, складу или кабинету. Каждый показатель должен раскрываться до нормализованных операций и далее до источника.
Шаг 7. Выполните три сверки
- Структурная: все ли строки получили тип, товар, дату и валюту?
- Финансовая: совпадают ли контрольные суммы источника и нормализованного слоя?
- Управленческая: объяснена ли разница между начислениями, выплатой и рассчитанной прибылью?
Небалансированный отчёт можно показывать, если отклонение видно и имеет статус. Скрывать разницу опаснее, чем честно обозначить неполное покрытие.
Пример маршрута строки
Представим удержание логистики на 420 ₽. В едином отчёте должны сохраниться: кабинет, исходный документ, ID операции, товар, склад, дата отчёта, дата продажи, тип «логистика», сумма −420 ₽ и версия правила сопоставления.
Тогда рост логистики на дашборде можно раскрыть до операции. Без этого команда видит только красный показатель и не знает, исправлять тариф, данные или процесс.
Как применять подход в ProfitVena
Сегодня в ProfitVena подтверждён live-сценарий Wildberries. Profit Engine и Product 360 связывают финансовый результат с товаром и исходным контекстом. Полнота зависит от подключённых источников и настроек рабочего пространства.
Единый live-отчёт по другим маркетплейсам нельзя считать доступным, пока конкретные подключения не подтверждены. Для них описанная модель — архитектура подготовки и дорожная карта, а не заявление о работающей синхронизации.
Forecast Center также готовится к интеграции и доступен как превью.
Техническая часть обновлена в ProfitVena.
ProfitVena развивается ООО «Виксора» и входит в экосистему Виксора.
Методика: «Единый отчёт по нескольким маркетплейсам».
Предыдущая статья: «Юнит-экономика SKU в ProfitVena».
Следующая: какие управленческие отчёты действительно нужны продавцу каждую неделю.
