Навигационное меню

Структура

Максимальная глубина: два уровня (родитель → дочерний пункт).

Дочерний пункт не может иметь детей.

РНП                              [все роли]
BI                               [ГД, Админ, Супер-Админ]
Администрирование                [Админ, Супер-Админ]
  └── Сотрудники
  └── Отделы
  └── Настройки
  └── Мониторинг данных
  └── Аудит

Доступность пунктов по ролям

Пункты, недоступные роли, не отображаются (не скрыты визуально, а отсутствуют в DOM).

Правила

• Группа "Администрирование" отображается только если у пользователя есть доступ хотя бы к одному дочернему пункту
• Активный пункт подсвечивается в меню
• Менеджер после логина попадает сразу на РНП (единственный доступный раздел)

Визуальные макеты интерфейсов — макеты интерфейса (PDF).

Роли и доступ (RBAC)

Обзор

Система ролей определяет, какие разделы и данные видит пользователь.

Детальная матрица доступа — отдельный документ.

Роли

Правила

• При создании пользователя из 1С — роль менеджер по умолчанию
• Роль супер-админ изменить нельзя (UI скрывает эту опцию)
• Один пользователь — одна роль
• Руководитель отдела получает доступ к товарам всех сотрудников отдела (независимо от роли)
• Доступ к прошлым периодам считаем по историческим SCD-назначениям, а не по текущей оргструктуре
• Менеджер в прошлом видит только те товары, где в тот период был назначен менеджером по историческому assignment
• РОП в прошлом видит только те товары, которые в тот период относились к сотрудникам его отдела по историческому состоянию
• Если по SCD связь на выбранный период не подтверждается, данные не показываем

Матрица доступа — «RBAC — Матрица доступа».

Панель администратора

Обзор

Раздел доступен только супер-админу и назначенным админам.

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

Глобальные настройки

Список параметров, которые администратор может изменить через UI:

API-токены внешних сервисов:

Список токенов и настроек будет пополняться.

Управление пользователями

Таблица всех пользователей системы.

Доступные действия на пользователе:

• Назначить роль — выбор из списка ролей (кроме супер-админа)
• Сменить пароль — задать новый пароль вручную (без текущего)
• Заблокировать / разблокировать — ручная блокировка
• Временно вернуть в работу — для уволенных (статус сбросится при следующей выгрузке из 1С)

Логика блокировки:

• Заблокированный пользователь не может войти и не может восстановить пароль
• Блокировка переопределяет статус из 1С: если сотрудник активен в 1С, но заблокирован вручную — доступ закрыт
• Для входа и reset действует precedence статусов: deleted -> уволен -> заблокирован -> inactive -> allow

Управление отделами

Функциональность:

• Создать / переименовать / удалить отдел
• Назначить руководителя отдела (один руководитель на отдел)
• Добавить / убрать сотрудников из отдела
• Сотрудник всегда в одном отделе (без отдела быть не может)

Руководитель отдела:

Пользователь с ролью РОП (RBAC), назначенный руководителем отдела через атрибут head_user_id на сущности отдела.

Роль РОП определяет уровень доступа, head_user_id определяет конкретный отдел.

head_user_id может ссылаться только на пользователя из этого же отдела.

Руководитель видит товары всех сотрудников своего отдела.

При удалении отдела:

Все сотрудники отдела переводятся в отдел по умолчанию.

Отдел по умолчанию удалить нельзя.

Глобальная настройка: отдел по умолчанию — куда попадает новый сотрудник из 1С, если явно не указан отдел.

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

• отдел по умолчанию для новых сотрудников;
• TTL ссылки восстановления пароля;
• срок хранения журнала аудита.

Мониторинг данных

Обзор

Раздел доступен только супер-админу и назначенным админам.

Показывает состояние ETL-пайплайнов (cron) и потока синхронизации из 1С. Только чтение — управление пайплайнами (перезапуск и т.д.) не предусмотрено в текущей версии.

ETL / Cron-пайплайны

Таблица всех cron-задач. Данные получаются из PG_ETL_PIPELINE_STATUS.

Колонки:

Поведение:

• Таблица обновляется автоматически раз в 60 секунд
• При статусе failed строка визуально выделяется

Синхронизация 1С → Kafka

Мониторинг синхронизации состоит из трёх operational-слоёв:

• входящие события на обработку;
• ошибки обработки / failed events;
• статусы прогонов интеграционных пайплайнов.
• сводный статус по каждому источнику / сущности загрузки.

На UI это может быть сведено в компактный блок, но логически это не одна универсальная “лента всего подряд”.

Базовый экран MVP: лента последних событий из Kafka-топика синхронизации сотрудников + ошибки обработки.

Колонки:

Параметры:

• Глубина отображения: последние N событий (N задаётся в глобальных настройках, рекомендация: 100)
• Сортировка: по времени, новые сверху

Сводный статус по источникам

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

Колонки:

Технические решения

• Оркестрация: cron-пайплайны. Статусы запусков читаются из БД (PG_ETL_PIPELINE_STATUS)

Журнал аудита

Обзор

Раздел доступен только супер-админу и назначенным админам.

Фиксирует все административные действия в системе. Только чтение.

Таблица событий

Колонки:

Типы отслеживаемых действий

Пользователи:

• Назначение / изменение роли (кому, с какой роли на какую)
• Блокировка / разблокировка пользователя
• Смена пароля пользователю администратором
• Временное восстановление уволенного сотрудника

Отделы:

• Создание / переименование / удаление отдела
• Добавление / удаление сотрудника из отдела
• Назначение / снятие руководителя отдела

Глобальные настройки:

• Изменение любого параметра (поле, старое значение, новое значение)
• Обновление API-токена внешнего сервиса (факт обновления без показа значения токена)

Сессии:

• Вход в систему (логин) под администраторской учётной записью
• Выход из системы

Фильтры

• Период (дата от / до)
• Администратор (выбор из списка)
• Тип действия (выбор из категорий)

Авторизация и управление пользователями

Обзор

Классическая авторизация по логину и паролю. Без SSO, LDAP, OAuth.

Источник пользователей — 1С, синхронизация через Kafka.

Роли и субординация — отдельный документ.

Экран логина

Поля:

• Email (логин, уникальный если заполнен)
• Пароль

Дополнительно:

• Ссылка "Забыл пароль" — всегда видна на экране логина

Восстановление пароля

• Пользователь вводит email на экране "Забыл пароль"
• Система проверяет на сервере: пользователь существует и доступен для входа
• Если активен — отправляем письмо со ссылкой для сброса
• Ссылка одноразовая, ограниченное время жизни (например, 1 час)
• Если пользователь не найден или недоступен для входа — показываем нейтральное сообщение (не раскрываем причину)
• Ограничение частоты запросов: лимит на количество запросов сброса по email и IP

Правило доступа к логину / reset:

• Если deleted_at заполнен — вход и reset запрещены
• Если сотрудник уволен (employment_status = fired) — вход и reset запрещены
• Если пользователь заблокирован вручную — вход и reset запрещены
• Если пользователь деактивирован (active = false) — вход и reset запрещены
• Иначе вход разрешён

Синхронизация пользователей из 1С

Источник: 1С Справочник Сотрудники / Физические лица → Kafka

Требования к данным из 1С:

• GUID сотрудника в 1С
• ФИО
• Email сотрудника — опционально, когда будет добавлен в модель
• Признак активности (работает / уволен) — опционально, когда будет добавлен в модель

Сценарий: новый пользователь появился в 1С

• Kafka доставляет событие с данными сотрудника
• Система создаёт пользователя по GUID из 1С
• ФИО используется как отображаемое имя
• Если email уже есть в модели — отправляем письмо на авторизацию
• Если email ещё нет — пользователь создаётся без возможности входа до появления email

Сценарий: пользователь уволен (признак активности = неактивен)

• Kafka доставляет событие обновления
• Система деактивирует аккаунт
• Все активные сессии инвалидируются немедленно
• При попытке логина — сообщение об отключённом аккаунте

Технические требования auth-слоя:

• Храним password_changed_at
• Ведём журнал неуспешных попыток входа
• Ведём журнал запросов на восстановление пароля для rate limit и расследования

Личный кабинет (шапка)

Обзор

Постоянный элемент интерфейса, доступный из любого экрана. Расположение: правый верхний угол.

Элемент в шапке

Инициалы пользователя или аватар → клик → дропдаун:

• Имя и email (только отображение)
• Сменить пароль
• Выйти

Смена пароля

Поля:

• Текущий пароль
• Новый пароль
• Подтверждение нового пароля

РНП — Блок фильтров

Обзор

Фильтры применяются глобально ко всему экрану РНП и определяют

какой срез данных видит пользователь. Все фильтры работают в комбинации (AND).

Менеджер по умолчанию видит только свои артикулы — фильтр по менеджеру

проставляется автоматически из его роли.

Фильтры

1. Период

• Тип: диапазон дат (date range picker)
• Пример: 01.01.26 — 31.01.26
• Источник: Показатель 1 — Дата из АПИ ВБ История остатков
• Частота обновления: раз в день
• Примечание: определяет диапазон строк в таблице РНП (одна строка = один день)

2. Категория 1С

• Тип: список (мультиселект)
• Пример: Ботинки
• Источник: Показатель 50 — Категория из 1С справочник Номенклатура
• Частота обновления: справочник, меняется редко
• Примечание: категория 1С ≠ категория WB, это разные справочники

3. Сезон продаж

• Тип: список (мультиселект)
• Пример: Зима
• Источник: Показатель 55 — Сезон продаж из 1С справочник Номенклатура
• Частота обновления: справочник, меняется редко

4. Коллекция

• Тип: список (мультиселект)
• Пример: Осень-Зима 2025-2026
• Источник: Показатель 44 — Коллекция из 1С Воронка продаж
• Частота обновления: по событию изменения назначения в 1С Воронка продаж
• Примечание: коллекция назначается динамически в 1С. Требует отдельного

хранения как SCD Type 2 по артикулам и периодам

5. Менеджер

• Тип: список (мультиселект)
• Пример: Аминова Анна
• Источник: Показатель 46 — Менеджер из 1С Воронка продаж
• Частота обновления: по событию изменения назначения в 1С Воронка продаж
• Примечание: один менеджер на артикул в текущем месяце, меняется помесячно.

Менеджер видит только свои артикулы — фильтр проставляется из RBAC автоматически.

РОП и ГД видят всё.

6. ABC

• Тип: список (мультиселект, A / B / C / DS)
• Пример: AC (выбрано A и C)
• Источник: Показатель 99 — расчётная величина, считается нами
• Алгоритм: еженедельно по понедельникам. Сортировка по заказам в штуках за неделю по убыванию, накопительная доля:
• A = товары, дающие первые 50% суммарной доли заказов
• B = следующие ~20%
• C = хвост до 100%
• DS (Dead Stock) = 0 заказов за последние N дней (настраивается в глобальных настройках, по умолчанию 14 дней = 2 недели)
• Частота обновления: раз в неделю (понедельник)
• Примечание: сейчас считается сторонней компанией в Excel → Google Sheets.

В новой системе считаем сами.

7. Количество дней на сайте

• Тип: диапазон (от / до)
• Пример: от 200 дней
• Источник: Показатель 113 — расчётная величина
• Формула: количество дат, в которые товар был в остатках
• Частота обновления: раз в день (инкрементально)

8. ВП, %

• Тип: диапазон (%, от / до)
• Пример: от 70%
• Источник: Показатель 81 — Валовая рентабельность — расчётная величина
• Формула: (Выручка - Себестоимость - Переменные расходы) / Выручка × 100%
• Частота обновления: раз в день

9. Артикул WB

• Тип: список / поиск (ввод вручную или мультиселект)
• Пример: 241547395
• Источник: Показатель 2 — Артикул WB из АПИ ВБ История остатков
• Частота обновления: раз в день

10. Артикул поставщика

• Тип: список / поиск (ввод вручную или мультиселект)
• Пример: e8688-15p
• Источник: Показатель 3 — Артикул поставщика из АПИ ВБ История остатков
• Частота обновления: раз в день

Группы выгрузок, которые питают фильтры

Группа A — WB API: История остатков

Питает: Артикул WB, Артикул поставщика, Период (даты), Категория WB (предмет), Бренд

• Endpoint: АПИ ВБ История остатков
• Частота: раз в день
• Тип загрузки: инкрементальный по дате

Группа B — 1С справочник Номенклатура

Питает: Категория 1С, Сезон продаж, Материал верха, Фабрика

• Source: 1С → Kafka
• Частота: справочник (редкие изменения, триггер по событию изменения)
• Тип загрузки: SCD Type 2 (история изменений важна)

Группа C — 1С Воронка продаж

Питает: Коллекция, Менеджер (назначение артикула)

• Source: 1С → Kafka
• Частота: по событию изменения; хранение как SCD Type 2
• Тип загрузки: SCD Type 2 (ключевой кейс — смена менеджера/коллекции помесячно)
• Критично: без этого источника невозможно разграничить данные по менеджерам

Группа D — Расчётные величины (считаем сами в DWH)

Питает: ABC, Количество дней на сайте, ВП%

• Источник расчёта: данные из групп A, B, C + планы из 1С
• Частота пересчёта: раз в день (ABC — раз в неделю)
• Хранение: в DWH как отдельные колонки витрины

РНП — Короткий отчёт

Обзор

Блок сводных KPI-карточек в верхней части экрана РНП. Отображает агрегированные показатели

по текущему фильтру. Все значения пересчитываются при изменении фильтров.

Структура отображения для первых трёх метрик: план / факт / % выполнения плана / дельта (факт − план).

Метрики

1. Выручка, млн. руб

• Отображение: план / факт / % плана / дельта
• План: Показатель 67 — Выручка План — 1С Планирование продаж
• Факт: Показатель 20 — Выкупы, руб — API WB v3 Sales Funnel, поле buyoutSum, раз в день
• % плана: Показатель 115 — Выполнение плана выручка — расчётная величина (факт / план)
• Дельта: Показатель 116 — Дельта выручка — расчётная величина (факт − план)

2. % проданного

• Отображение: план / факт / % плана / дельта
• План: Показатель 69 — План % проданного — 1С Планирование продаж
• Факт: Показатель 79 — Факт % проданного — расчётная величина
• % плана: Показатель 117 — Выполнение плана % проданного — расчётная величина
• Дельта: Показатель 118 — Дельта % проданного — расчётная величина

3. ЧП, руб

• Отображение: план / факт / % плана / дельта
• План: Показатель 77 — План ЧП — 1С Планирование продаж
• Факт: Показатель 95 — расчётная величина
• % плана: Показатель 119 — Выполнение плана чистая прибыль — расчётная величина
• Дельта: Показатель 120 — Дельта чистая прибыль — расчётная величина

4. % участия в акциях

• Отображение: только факт
• Факт: Показатель 121 — % участия в акциях — расчётная величина
• Формула: (сумма заказов по товарам, участвовавшим хотя бы в одной акции) / (сумма всех заказов) * 100
• Правило периода: если в фильтре выбран диапазон дат, считаем ровно по этому диапазону; если выбрана одна дата, считаем по этой дате и 6 предыдущим дням
• Скоуп по роли: менеджер считает только по своим товарам; РОП — по товарам своих сотрудников
• Примечание: нет план/факт структуры, только агрегированный процент по фильтру

5. Мотивация менеджера

• Отображение: только факт
• Факт: Показатель 122 — Мотивация менеджера — расчётная величина
• Примечание: видна только когда выбран конкретный менеджер (или для текущего менеджера по умолчанию)
• Формула: K = 0.7 Выполнение_по_выручке + 0.3 Выполнение_плана_по_валовой_прибыли
• K >= 95% → бонус 50 000
• K >= 100% → бонус 100 000
• K >= 105% → бонус 150 000
• Перевыполнение > 5% → доплата ещё 50 000
• Период: квартальная мотивация по всем коллекциям
• Бонус 5% от экономии рекламы — НЕ входит в П122, это отдельный бонус:
• Формула: 5% * (П102 - П157) при положительной разнице
• При отрицательной разнице (перерасход) депремирования нет

Группы выгрузок, которые питают короткий отчёт

Группа A — API WB v3: Sales Funnel

Питает: Выручка факт (Показатель 20)

• Endpoint: POST /api/analytics/v3/sales-funnel/products
• Частота: раз в день

Группа B — 1С Планирование продаж

Питает: план по Выручке, % проданного, ЧП (Показатели 67, 69, 77)

• Source: 1С → Kafka
• Частота: по событию изменения плана

Группа C — Расчётные величины (считаем сами в DWH)

Питает: % проданного факт, все показатели % плана и дельты, % участия в акциях, мотивация менеджера (Показатели 79, 115–122)

• Источник расчёта: данные из групп A, B + данные РНП
• Частота пересчёта: раз в день

РНП — Паспорт товара

Обзор

Паспорт — первый из трёх блоков в раскрываемой строке товара на экране РНП.

Содержит идентификационные и справочные данные по артикулу: кто производит, откуда, в какой коллекции, сколько заказано.

Данные преимущественно статичные (справочник), обновляются редко.

Поля

Идентификация

Классификация

Закупка и себестоимость

Дозаказ, шт считаем на нашей стороне как сумму количества по строкам заказов поставщику, где документ помечен признаком дозаказ, только в рамках актуального сезона / коллекции для артикула.

Прочее

Специальные блоки

Эластичность спроса

График зависимости заказов от цены и СПП/WB Club.

Визуализирует как менялись заказы при изменении цены.

Статус: MVP.

Источники: заказы (П7), цена факт (П42), СПП (П65) — все ежедневные.

Формулы: П42 = П20 / П19, П64 = П42 * (1 - П65).

Технический момент: СПП и цену нужно хранить историчски (запись раз в день), не только текущее значение.

История изменений карточки

Таймлайн с вехами: изменения фото, SEO, описания, категории, цены.

Статус: MVP.

Реализация: аудит-лог товара — при каждой ежедневной выгрузке из API сравниваем ключевые поля с предыдущим снимком, фиксируем дельту как событие. WB API историю не отдаёт, фиксируем сами.

Объединение / разъединение карточек

Функционал write-back через API WB — merge/split карточек товара.

Статус: MVP — выделяется в отдельный feature-документ, обсуждается отдельно.

Группы выгрузок

Группа A — API WB: История остатков

Питает: Артикул WB, Артикул поставщика, Категория WB, Бренд

• Частота: раз в день

Группа A2 — API WB: Seller Info

Питает: Юр лицо

• Source: GET /api/v1/seller-info
• Поля: sellerId, name, tin
• Правило: один токен WB = одно юр лицо; в хранилище сохраняем атрибут кабинета токена и прокидываем его во все WB-данные как технический признак источника
• Частота: при каждой полной загрузке WB + при подключении нового токена

Группа B — 1С справочник Номенклатура

Питает: Категория 1С, Сезон продаж, Материал верха, Фабрика, Повтор

• Source: 1С → Kafka
• Частота: справочник (триггер по событию изменения)

Группа C — 1С Воронка продаж

Питает: Коллекция

• Source: 1С → Kafka
• Частота: по событию изменения

Группа D — 1С Закупки

Питает: Заказано шт, Себестоимость руб/юани

• Source: 1С Заказ поставщику, 1С Приобретение товаров и услуг
• Для Дозаказ, шт в 1С Заказ поставщику нужен явный признак документа основной заказ / дозаказ
• Частота: событийно

Группа E — Расчётные величины

Питает: Кол-во дней на сайте

• Частота: раз в день

Паспорт товара — Объединение и разъединение карточек

Обзор

Функционал write-back через API WB. Позволяет объединить несколько карточек товара

в одну группу (единый imtID) или разъединить сгруппированные карточки.

Доступ: из блока "Паспорт" на экране РНП. Кнопка видна Менеджеру, РОП, Админу, Супер-Админу (по матрице «RBAC — Матрица доступа»). ГД — только чтение, кнопка скрыта.

Механика API WB

Один эндпоинт для обоих операций:

POST https://content-api.wildberries.ru/content/v2/cards/moveNm

Объединение — указываем targetIMT (imtID группы, куда добавляем) и массив nmIDs:

{
  "targetIMT": 123456,
  "nmIDs": [837459235, 828572090]
}

Разъединение — тот же эндпоинт, targetIMT не передаём, только nmIDs.

WB генерирует новые imtID для разъединённых карточек.

Если передать несколько nmID без targetIMT — они объединятся в новую группу с новым imtID.

Чтобы дать каждой карточке отдельный imtID — отправлять по одной за запрос.

Ограничения WB:

• Объединять можно только карточки с одинаковым предметом (subject / категория WB)
• Предмет — это категория WB (Показатель 4, например "Ботинки", "Кроссовки"). Это не категория 1С.
• Карточку "Ботинки" нельзя объединить с карточкой "Кроссовки" — WB вернёт ошибку.
• Именно поэтому список кандидатов для объединения обязательно фильтруется по предмету текущей карточки на нашей стороне, до отправки в API. Показываем пользователю только те карточки, у которых предмет совпадает.
• Максимум 30 nmID за один запрос
• Максимальный размер запроса: 10 МБ

Группа в API:

При запросе списка карточек (POST /content/v2/get/cards) каждая карточка возвращает nmID и imtID.

Карточки с одинаковым imtID — в одной группе. Это основа для отображения связей.

UI-флоу: объединение

• Пользователь с правом на операцию (Менеджер / РОП / Админ / Супер-Админ) открывает паспорт товара (текущая карточка — nmID и imtID известны)
• Нажимает "Объединить с другой карточкой"
• Система показывает список карточек-кандидатов:
• Фильтр по тому же предмету (subject) — ограничение API WB
• Фильтр по скоупу роли: Менеджер видит только свои товары, РОП — товары своего отдела, Админ/Супер-Админ — все товары
• Отображаем: фото, артикул WB (nmID), артикул поставщика, название
• Менеджер выбирает целевую карточку (или группу — targetIMT)
• Подтверждение действия (необратимо до явного разъединения)
• Вызов POST /content/v2/cards/moveNm с targetIMT и nmIDs: [текущий nmID]
• Показываем результат: успех / ошибка с текстом от WB

UI-флоу: разъединение

• Менеджер открывает паспорт товара, которая входит в группу (imtID совпадает у нескольких)
• Видит список карточек в текущей группе
• Нажимает "Разъединить"
• Подтверждение: выбирает какие карточки выводить из группы (или все)
• Вызов POST /content/v2/cards/moveNm без targetIMT, по одной карточке за запрос (если нужен уникальный imtID каждой)
• Результат: новые imtID присвоены WB автоматически

Технические решения

• История операций — каждое объединение и разъединение фиксируется в аудит-логе товара. В блоке "История изменений карточки" в паспорте — кнопка-ссылка на этот аудит.
• Re-sync после объединения — после успешного вызова API запускаем повторную синхронизацию по затронутым imtID, чтобы обновить данные в DWH.

РНП — Аналитика товара

Обзор

Второй из трёх блоков в раскрываемой строке товара на экране РНП.

По умолчанию свёрнут — отображается по клику на заголовок блока.

Содержит метрики план/факт/% плана/дельта за выбранный в фильтре период, воронку продаж и операционные показатели по конкретному артикулу.

Метрики план / факт

Структура отображения: план / факт / % выполнения плана / дельта (факт − план).

Финансовые

П97 в исходном xlsx — опечатка. Клиент подтвердил: факт ЧП = П95.

АВС-рейтинг

Воронка продаж (факт)

Источник переходов и конверсий: POST /api/analytics/v3/sales-funnel/products (API WB v3) — openCount, addToCartCount, ordersCount ежедневно по nmID.

Источник показов: внешний скрапер другой команды (данные из LK WB, раздел «Воронка продаж», поле «Показы»).

Примечание: поле views (показы) в WB API не реализовано. Реальное поле — openCount (переходы в карточку). Показы доступны только через внешний скрапер другой команды.

Операционные показатели

СПП (Скидка постоянного покупателя)

СПП в WB API недоступен. Источник — внешний скрапер другой команды.

Частота: раз в час (текущая практика клиента).

Хранить историчски ежедневно — необходимо для графика эластичности спроса в паспорте.

Группы выгрузок

Группа A — API WB v3: Sales Funnel

Питает: Выручка факт (П20), Выручка шт факт (П19), воронка (П18, П135, П136, П26)

• Endpoint: POST /api/analytics/v3/sales-funnel/products
• Частота: раз в день по nmID

Группа B — API WB: Продвижение

Питает: Расходы на рекламу факт (П21)

• Частота: раз в день

Группа C — 1С Планирование продаж

Питает: все плановые показатели и исходные плановые величины для downstream-расчётов (П67, П68, П69, П70, П71, П72–П78, П100, П102, П141, П156)

• Source: 1С → Kafka
• Для П102 используем поле Реклама внутренняя, руб
• Частота: по событию изменения плана

Группа D — Скрапинг

Питает: СПП (П65), Показы для CTR (П18)

• Источник реализации: готовый скрапер / парсер другой команды
• Частота: СПП — раз в час; Показы — раз в день

Группа E — Расчётные величины (DWH)

Питает: % проданного, ЧП%, ЧП руб, ДРР, АВС, воронка расчётные, операционные (П79, П80, П82, П89, П96, П99, П115–П133, П135–П140)

• Частота пересчёта: раз в день (АВС — раз в неделю)

РНП — История товара (rnp-detail-history)

Обзор

Третий блок в раскрываемой строке товара на экране РНП. Показывает исторические данные по артикулу в разрезе дней.

По умолчанию свёрнут — отображается по клику.

Структура отображения

Строки = метрики / поля.

Колонки = дни: первая колонка после названий — сегодня, следующая — вчера, и т.д. вправо в глубину истории.

Производительность: горизонтальный виртуальный скролл с ленивой подгрузкой колонок — браузер рендерит только видимые дни, остальные подгружаются по мере прокрутки.

Пустое состояние: до выбора фильтра таблица РНП не отображается вообще — соответственно и этот блок тоже.

Строки таблицы

Блок событий

План действий

Текстовое поле на каждый день.

• Сегодня: редактируемое до конца дня
• Вчера и ранее: только чтение

Заказы

Плановая оборачиваемость (П29, П30) и связанный с ней блок в текущий MVP не входят. Возвращаемся к ним в следующих итерациях после появления устойчивого источника в 1С.

Остатки

Цена

Финансы ВП

Себестоимость и затраты (скрыто для роли Менеджер)

Воронка и реклама

Отзывы

Write-back: цена и скидка

Кнопки "Выгрузка новой цены" и "Выгрузка новой скидки" — inline-форма в строке истории.

Механика:

• Пользователь вводит новое значение цены / скидки
• Система вызывает POST /api/v2/upload/task с nmId, price, discount
• Отображаем статус: успех / ошибка с текстом от WB
• После успеха — запускаем re-sync цены для этого nmID

Ограничения WB:

• Снижение цены более чем в 3 раза от предыдущей → товар попадает в "ценовой карантин"
• Обновление до 1000 nmID за один запрос (в нашем случае — одиночный артикул)

Write-back: участие в акции

По текущим ответам клиента механика блока акций в MVP выглядит так:

• WB предлагает цены и скидки для участия в акции
• менеджер принимает решение и вводит параметры участия в нашей системе
• индикатор 1/1 означает количество доступных акций для артикула; один артикул может участвовать одновременно в 2+ акциях
• автоакции у WB существуют как отдельная механика; в рабочем процессе клиент обычно исключает 100% товаров и затем добавляет участников поартикульно

В строке каждого дня (или в отдельном блоке на сегодня) отображается:

DS-товары и акции:

• Ручное участие (кнопка "Участвовать") — блокируется валидацией на FE + BE. ✓ Решение принято.
• Автоакции существуют как отдельная механика WB. Выход из автоакции выполняется через настройки самой акции. Техническая интеграция этого сценария требует отдельной проработки, так как стандартный promotion API покрывает не все auto-promotion кейсы.

РНП — Основная таблица

Обзор

Главная часть экрана РНП. Отображает список артикулов, соответствующих выбранным фильтрам.

Каждая строка — один артикул (nmID). Строка раскрывается аккордеоном в три блока:

«РНП — Паспорт товара» → «РНП — Аналитика товара» → «РНП — История товара».

Пустое состояние: пока фильтр не применён — таблица не отображается вовсе.

Колонки таблицы

Колонки видимые по умолчанию (без раскрытия строки):

Сортировка

• Сортировка по любой числовой колонке (клик на заголовок — ASC / DESC)
• По умолчанию: по выручке факт, убывание

Механика раскрытия строки

Клик на строку — строка раскрывается аккордеоном, под ней появляются три вложенных блока:

▼ Строка артикула (раскрыта)
  ├── [Паспорт товара]         ← первый, раскрыт по умолчанию
  ├── [Аналитика товара]       ← второй, свёрнут
  └── [История товара]         ← третий, свёрнут

• Каждый вложенный блок раскрывается/сворачивается независимо
• Несколько строк артикулов могут быть раскрыты одновременно
• Повторный клик на строку — сворачивает её целиком вместе со всеми блоками

Производительность

• Виртуализация строк: браузер рендерит только видимые строки таблицы
• Пагинация: стандартная, серверная. Параметры: offset, limit, perPage (дефолтное значение уточнить при разработке)
• История (горизонтальный скролл): виртуальный скролл колонок с ленивой подгрузкой — описан в «РНП — История товара»

RBAC

Решения

• Пагинация: стандартная серверная пагинация (offset / limit / perPage). Infinite scroll — не используем.

BI — Apache Superset (bi-superset)

Обзор

Отдельная страница с встроенными BI-дашбордами Apache Superset.

Предназначена для аналитики в свободном формате — настройка и просмотр дашбордов без ограничений по метрикам.

Доступ: ГД, Админ, Супер-Админ.

Структура страницы

• Вкладки (tabs) — каждая вкладка = один дашборд Superset
• Контент вкладки — iframe с дашбордом, монтируется через @superset-ui/embedded-sdk
• Количество вкладок и их названия определяются конфигурацией (см. ниже)

Конфигурация дашбордов

UUID дашбордов хранятся в конфиге деплоя (не в БД и не в настройках системы).

Изменение набора дашбордов → изменение конфига + редеплой.

Пример структуры конфига:

superset:
  dashboards:
    - id: "abc123-uuid"
      title: "Продажи"
    - id: "def456-uuid"
      title: "Остатки"
    - id: "ghi789-uuid"
      title: "Реклама"

Механика аутентификации (Guest Token)

WB-система не передаёт пользователей в Superset напрямую.

Доступ к дашбордам обеспечивается через Guest Token:

• Фронт при открытии вкладки вызывает наш backend: POST /api/internal/superset/guest-token
• Backend аутентифицируется в Superset через сервисный аккаунт (POST /api/v1/security/login)
• Backend запрашивает guest token: POST /api/v1/security/guest_token/ с resources: [{type: "dashboard", id: uuid}]
• Токен возвращается фронту, SDK монтирует iframe
• SDK автоматически обновляет токен (повторно вызывает fetchGuestToken) до его истечения

RLS не требуется — ГД, Админ и Супер-Админ видят все данные без ограничений.

Требования к конфигурации Superset

Фиксируется в superset_config.py при деплое:

FEATURE_FLAGS = {
    "EMBEDDED_SUPERSET": True
}

ENABLE_CORS = True
CORS_OPTIONS = {
    "origins": ["https://our-app-domain.com"]
}

TALISMAN_CONFIG = {
    "content_security_policy": {
        "frame-ancestors": ["https://our-app-domain.com"]
    }
}

Сервисный аккаунт Superset (логин/пароль для минтинга guest token) хранится в секретах backend-сервиса.

RBAC — Матрица доступа

Навигация

РНП — скоуп данных

РНП — скрытые поля (история товара)

Поля скрыты от роли Менеджер, остальные видят:

РНП — write-back операции

"Свои" — артикулы, назначенные менеджеру по историческому assignment на выбранный период.

"Отдел" — все артикулы менеджеров отдела по историческому составу отдела и assignment на выбранный период.

ГД — только чтение по всем артикулам.

Администрирование

Роль Супер-Админ не назначается через UI никем — создаётся при деплое, изменить нельзя.

Требования к данным из 1С

Всё что нам нужно получить из 1С через Kafka.

Документ — основа для постановки задачи подрядчику 1С.

Канал передачи для всех блоков: 1С → Kafka → наш ETL → DWH.

1. Сотрудники

Объект 1С: Справочник Сотрудники / Физические лица

Механика синхронизации:

• Новый сотрудник → создаём пользователя по GUID, отображаем ФИО
• Если у сотрудника есть email → отправляем письмо на авторизацию
• Если email отсутствует → пользователь создаётся, но вход недоступен до появления email
• Если сотрудник помечен как уволенный → немедленная инвалидация сессии, блокировка входа

Важно: если в текущей конфигурации 1С поля email и / или признака активности ещё нет, это не снимает требование с интеграционного контракта. Для запуска целевого auth-контура эти поля должны быть добавлены в модель 1С отдельной доработкой.

Отдел сотрудника: поле отдела из 1С не передаётся. Назначение в отдел — только через UI системы (раздел «Управление отделами»). Новый сотрудник из 1С автоматически попадает в «отдел по умолчанию» (настраивается в глобальных настройках).

2. Справочник Номенклатура

Объект 1С: Справочник Номенклатура

Тип загрузки: SCD Type 2 (история изменений важна)

3. Воронка продаж (назначение менеджера и коллекции)

Объект 1С: 1С Воронка продаж

Тип загрузки: SCD Type 2 (менеджер и коллекция меняются помесячно)

Критично: без этого источника невозможно разграничить данные по менеджерам за прошлые периоды.

4. Планирование продаж

Объект 1С: 1С Планирование продаж

Тип загрузки: плановые значения на месяц, обновляются при изменении плана

Примечание по рекламе: для П102 фиксируем поле Реклама внутренняя, руб в 1С Планирование продаж.

5. Приобретение товаров и услуг (себестоимость)

Объект 1С: Документ «Приобретение товаров и услуг»

Тип загрузки: событийный — появляется при фактическом поступлении товара

Источник: только 1С → Kafka. Excel как источник себестоимости исключён.

⚠️ Важно для подрядчика 1С — два жизненных цикла себестоимости:

• Первичная — появляется при создании заказа поставщику, до прихода товара
• Финальная — после получения УПД, пересчитывается по курсу из официального документа

Передавать нужно только проведённые документы «Приобретение товаров и услуг», не помеченные на удаление. Неподтверждённые и черновики исключаем.

6. Заказ поставщику

Объект 1С: Документ «Заказ поставщику»

Тип загрузки: событийный

Правило для Дозаказ, шт:

• Источник — строки документа 1С Заказ поставщику, а не ручной ввод
• В документе нужен явный допреквизит основной заказ / дозаказ
• Дозаказ, шт считаем у себя как сумму количества по строкам артикула во всех документах, помеченных как дозаказ, только в рамках актуального сезона / коллекции

7. Приходный ордер (план отгрузки)

Объект 1С: Документ «Приходный ордер»

Как найти: через связанные документы Заказа поставщику

Тип загрузки: событийный

⚠️ Транзиентное поле: мы не храним «плановую дату отгрузки» напрямую. При каждой загрузке берём дату проведения приходного ордера, добавляем 4 дня — и вот это и есть плановая дата. Никакого отдельного поля «план отгрузки» в 1С нет.

8. Нормативы для расчета планов

Объект 1С: Справочник / регистр «Нормативы для расчета планов»

Тип загрузки: справочник, меняется редко

Бизнес-правило выбора норматива (подтверждено клиентом, Ольга показала из 1С):

• Норматив выбирается по двум ключевым признакам: категория товара (одежда/обувь) и дата.
• Для каждого артикула определяется категория (из 1С Справочник Номенклатура), затем берётся норматив с ближайшей датой, соответствующей категории.
• Нормативы могут корректироваться при изменении экономики.

9. Справочник Сезон продаж (курс юань/руб)

Объект 1С: Справочник Сезон продаж

Тип загрузки: справочник

10. Реализация товаров и услуг (фактические отгрузки)

Объект 1С: Документ «Реализация товаров и услуг»

Тип загрузки: событийный

11. Показатели вне текущего обязательного контракта 1С

Эти показатели не входят в текущий обязательный контракт 1С.

Сводная таблица объектов

Требования к данным из API WB

Всё что нам нужно забирать из API Wildberries для РНП.

Документ — основа для постановки задач по ETL и интеграции с WB API.

Канал передачи для всех блоков: WB API → наш ETL → DWH.

Принципы

• Один ETL-контур может забирать сразу несколько показателей из одного метода API
• Ниже перечислены именно контуры ETL, а не просто список полей
• Если по показателю в reference-upd.xlsx нет Метод или есть явная пометка ? уточнить, такой элемент помечается отдельно
• Расчётные показатели, парсинг и скрапинг в этот документ не входят

Статусы валидации

• ✅ — контур и ключевые поля подтверждены официальной документацией WB через Context7; местами дополнительно подтверждены live API.
• ⚠️ — endpoint подтверждён, но в проектном использовании есть дополнительная бизнес-оговорка, derived-логика или составной ETL-блок.
• ➕ — контур добавлен осознанно на стороне проекта и не идёт как прямая строка из вкладки АПИ.

1. Sales Funnel v3

Статус валидации: ✅

Источник: WB Seller Analytics

Метод: POST /api/analytics/v3/sales-funnel/products

Домен: seller-analytics-api.wildberries.ru

Частота: раз в день

Гранулярность: nmID × день

Технические замечания:

• В reference-upd.xlsx часть НСИ также привязана к этому методу. Это допустимо, но финальный выбор источника НСИ зависит от архитектуры витрины.
• В текущем workbook этот метод одновременно используется как источник части НСИ, заказов, выкупов, рейтингов и клубных цен.

1A. Seller Info

Статус валидации: ✅ ➕

Источник: WB API Information

Метод: GET /api/v1/seller-info

Частота: при каждой полной загрузке WB + при подключении нового токена

Гранулярность: token / seller cabinet

Правило использования:

• Один токен WB = одно юр лицо
• Для каждого токена один раз читаем seller-info и сохраняем связку token -> sellerId -> tin -> name
• Во все downstream-данные из WB API добавляем технические поля wb_seller_id, wb_seller_tin, wb_seller_name
• Для П5 в витрине РНП используем tin как основной атрибут юрлица, name как display name

2. История остатков — товары

Статус валидации: ✅

Источник: WB Seller Analytics

Метод: POST /api/v2/stocks-report/products/products

Домен: seller-analytics-api.wildberries.ru

Частота: раз в день

Гранулярность: nmID × день

3. История остатков — склады WB

Статус валидации: ✅

Источник: WB Seller Analytics

Метод: POST /api/analytics/v1/stocks-report/wb-warehouses

Домен: seller-analytics-api.wildberries.ru

Частота: раз в день

Гранулярность: nmID × день

4. История остатков — офисы / склады

Статус валидации: ✅

Источник: WB Seller Analytics

Метод: POST /api/v2/stocks-report/offices

Домен: seller-analytics-api.wildberries.ru

Частота: раз в день

Гранулярность: nmID × офис × день

5. Карточки товаров

Статус валидации: ⚠️

Источник: WB Content API

Метод: POST /content/v2/get/cards/list

Домен: content-api.wildberries.ru

Частота: раз в день

Гранулярность: nmID

Правило для П38:

• П38 не читаем напрямую из WB API.
• created_at используем только как технический атрибут карточки WB и сохраняем в модели товара отдельно.
• П38 считаем на нашей стороне по ежедневным снимкам остатков как первую дату, когда мы увидели stockCount > 0.
• Если wb_card_created_at >= Y, то при первом снимке с stockCount > 0 записываем дату снимка в П38.
• Если wb_card_created_at < Y, то П38 автоматически не заполняем.
• После заполнения П38 не перезаписывается.

6. Продвижение — расходы

Статус валидации: ✅

Источник: WB Продвижение

Метод: GET /adv/v1/upd

Домен: advert-api.wildberries.ru

Частота: раз в день

Гранулярность: зависит от рекламной сущности WB, в витрине агрегируется до товара / периода

7. Продвижение — статистика

Статус валидации: ✅

Источник: WB Продвижение

Метод: GET /adv/v3/fullstats

Домен: advert-api.wildberries.ru

Частота: раз в день

Гранулярность: зависит от рекламной сущности WB, в витрине агрегируется до товара / периода

8. Supplier Orders Report

Статус валидации: ✅

Источник: WB Statistics API

Метод: GET /api/v1/supplier/orders

Домен: statistics-api.wildberries.ru

Частота: не зафиксирована в workbook

9. Календарь акций

Статус валидации: ✅

Источник: WB Promotion

Метод: GET /api/v1/calendar/promotions

Домен: dp-calendar-api.wildberries.ru

Частота: раз в день

Гранулярность: акция × период

Назначение в РНП:

• Получаем список акций за интересующий период
• Для каждой акции используем её id как вход в следующий метод проверки номенклатур

10. Номенклатуры в акции

Статус валидации: ✅

Источник: WB Promotion

Метод: GET /api/v1/calendar/promotions/nomenclatures

Домен: dp-calendar-api.wildberries.ru

Частота: раз в день

Гранулярность: promotionID × nmID

Правило использования:

• Сначала читаем calendar/promotions и получаем promotionID, name, даты акции
• Потом по каждому promotionID читаем calendar/promotions/nomenclatures
• Если нужный nmID найден и inAction=true, считаем, что товар участвует в акции с именем из первого метода

Ограничение WB:

• Метод calendar/promotions/nomenclatures не применим к автоакциям

11. Продажи по регионам

Статус валидации: ✅

Источник: WB Seller Analytics

Метод: GET /api/v1/analytics/region-sale

Домен: seller-analytics-api.wildberries.ru

Частота: не зафиксирована в workbook

12. Штрафы

Статус валидации: ✅

Источник: WB Reports

Точка входа в workbook: getMeasurementPenalties

Зафиксированный состав ETL:

• В разделе Retention Reports документации WB сейчас перечислены 5 методов
• Для агрегата Штрафы логично собирать все 5 денежных отчётов удержаний, так как даже warehouse-measurements содержит денежные поля удержания:
• GET /api/analytics/v1/measurement-penalties → поле penaltyAmount
• GET /api/analytics/v1/deductions → поле bonusSumm
• GET /api/v1/analytics/antifraud-details → поле details[].sum
• GET /api/v1/analytics/goods-labeling → поле amount
• GET /api/analytics/v1/warehouse-measurements → поле penaltyAmount ; дополнительно в ответе есть reversalAmount

Правило агрегации по умолчанию:

• Суммируем денежные поля удержаний по всем 5 отчётам
• Для warehouse-measurements по умолчанию берём penaltyAmount
• reversalAmount не включаем автоматически в метрику Штрафы, пока бизнес отдельно не подтвердит, что показатель должен считаться нетто

Проверено живым API:

• GET /api/v1/analytics/antifraud-details реально возвращает массив details[] с денежным полем sum
• GET /api/analytics/v1/measurement-penalties реально возвращает data.reports[] с полями penaltyAmount и reversalAmount

13. Элементы вне текущего API-контракта

Это строки из вкладки АПИ, которые пока не образуют готовый ETL-контур.

Сводка по контурам ETL

Требования к данным из парсинга и скрапинга

Всё что нам нужно получать не через официальные API, а через парсинг / скрапинг.

Документ — основа для постановки задач по non-API интеграциям для РНП.

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

Канал передачи для всех блоков: Внешний скрапер / парсер другой команды → наш ETL → DWH.

Принципы

• В текущий обязательный scope входят только те элементы, у которых в reference-upd.xlsx основной источник не API
• Альтернативные источники не учитываем
• Расчётные показатели сюда не входят

1. Показы и воронка продаж (история)

Источник: парсинг WB Seller (неофициальный endpoint)

Причина: поле "Показы" отсутствует в официальном WB OpenAPI; данные берутся из внутреннего аналитического endpoint'а WB Seller

1.1 Показы (П11) и полная воронка

Метод: POST https://seller-content.wildberries.ru/ns/analytics-api/content-analytics/api/v1/sales-funnel/report/product/history

Частота: раз в день (забираем сегодня + вчера; вчера — финальные данные, сегодня — меняются в течение дня)

Гранулярность: nmID × день

Тело запроса:

{
  "nmID": 820630478,
  "currentPeriod": {
    "start": "2026-04-05",
    "end": "2026-04-11"
  }
}

Ключевые поля ответа (data[].*):

Стратегия сбора:

• Забираем данные за сегодня и вчера каждый день
• Вчера — финальные данные (изменений больше не будет)
• Сегодня — промежуточные (могут меняться в течение дня)
• Накапливаем полную историю по дням для каждого nmID

Авторизация:

• Требуются заголовки authorizev3 и wb-seller-lk (JWT-токены)
• Токены обновляются через механизм авторизации WB Seller

Использование downstream:

• CTR клик (П18) = openCardCount.current / viewCount.current
• Воронка продаж
• Историческая аналитика по товару

2. СПП (Скидка постоянного покупателя)

Источник: парсинг WB Seller (неофициальный endpoint)

Причина: СПП отсутствует в официальном WB OpenAPI; данные берутся из внутреннего endpoint'а WB Discounts & Prices

2.1 СПП (П65)

Метод: POST https://discounts-prices.wildberries.ru/ns/dp-api/discounts-prices/suppliers/api/v1/list/goods/filter

Частота: раз в час

Гранулярность: nmID × timestamp

Тело запроса:

{
  "limit": 50,
  "offset": 0,
  "facets": [],
  "filterWithoutPrice": false,
  "filterWithLeftovers": false,
  "filterWithoutCompetitivePrice": false,
  "sort": "price",
  "sortOrder": 0
}

Ключевые поля ответа (data.listGoods[].*):

Стратегия сбора:

• Забираем данные раз в час — СПП может меняться в течение дня
• Накапливаем историю для расчёта цены покупателя и графика эластичности
• Пагинация через limit / offset — нужно проходить весь каталог

Авторизация:

• Требуются заголовки authorizev3 и wb-seller-lk (JWT-токены)

Использование downstream:

• Цена минус СПП (П64) = П42 * (1 - П65)
• График эластичности спроса
• История изменения цен для покупателя

3. Метрики заказов / выкупов (нишевые)

Источник: тот же endpoint, что и раздел 1 — парсинг WB Seller

Причина: эти показатели берутся из того же ответа /sales-funnel/report/product/history, что и Показы

Примечание: отдельный запрос не нужен — данные приходят в том же ответе, что и Показы (раздел 1).

Отличие П109–П112 от П7, П8, П19, П20:

• П7 (orderCount), П8 (orderSum), П19 (buyoutCount), П20 (buyoutSum) — берутся из официального WB API POST /api/analytics/v3/sales-funnel/products (домен seller-analytics-api.wildberries.ru)
• П109 (orderCount.current), П110 (orderSum.current), П111 (buyoutCount.current), П112 (buyoutSum.current) — берутся из неофициального парсинг-endpoint'а POST /ns/analytics-api/content-analytics/api/v1/sales-funnel/report/product/history (домен seller-content.wildberries.ru)
• Это разные источники: официальный API отдаёт агрегированные значения за период, парсинг-endpoint отдаёт daily-историю с полем .current за каждый день
• В MVP П7/П8/П19/П20 используются в основной таблице и аналитике; П109–П112 — нишевые метрики, которые могут отличаться от официальных из-за разной логики агрегации WB

4. Индекс локализации (ИЛ) и КТР

Источник: парсинг WB Seller (неофициальные endpoint'ы)

Причина: ИЛ и КТР недоступны через официальный WB OpenAPI; данные берутся из внутренних аналитических endpoint'ов WB Seller

4.1 Индекс локализации (П138)

Метод: POST https://seller-content.wildberries.ru/ns/analytics-api/content-analytics/api/v1/localization/report-by-nm

Частота: раз в день

Гранулярность: nmID × день

Тело запроса:

{
  "nmIDs": [],
  "subjectID": 0,
  "brand": "",
  "tagID": 0,
  "start": "2026-04-05",
  "end": "2026-04-11",
  "limit": 50,
  "offset": 0,
  "orderBy": {"field": "nonLocalOrderCount", "mode": "desc"},
  "stockType": ""
}

Ключевые поля ответа (data[].*):

4.2 КТР — Коэффициент территориального распределения (П139)

Метод: POST https://seller.wildberries.ru/ns/categories-info/suppliers-portal-analytics/api/v1/localization-list

Частота: раз в день

Гранулярность: справочник (обновляется раз в день)

Формат ответа (data.indexts[]):

{
  "index": 0.5,
  "left": 95,
  "right": 100,
  "pricePercent": 0
}

Правило расчёта П139:

• Берём значение localOrderPercent (П138) для конкретного nmID из endpoint'а 4.1
• Находим запись в indexts[], где left <= localOrderPercent <= right (включительно)
• Значение index найденной записи = КТР для данного товара

Авторизация:

• Оба endpoint'а требуют актуальные заголовки authorizev3 и wb-seller-lk (JWT-токены)
• Токены обновляются через механизм авторизации WB Seller; необходимо поддерживать актуальность сессии

Сводка по контурам

РНП — Карта происхождения MVP-показателей

Единый source of truth по показателям РНП, которые реально входят в MVP по листу MVP пояснения из reference-upd.xlsx.

Документ отвечает на три вопроса:

• где показатель используется в MVP;
• откуда он берётся в проектном контуре;
• как его получать или считать.

Правила

• Для одного показателя в проекте фиксируем один рабочий источник.
• Если показатель расчётный, считаем его в DWH на нашей стороне.
• Если показатель приходит из внешнего скрапера / парсера другой команды, в этом проекте мы не пишем свой сборщик: ждём готовую реализацию и принимаем результат в ETL.
• Детальные интеграционные контракты живут в «Требования к данным из 1С», «Требования к данным из API WB», «Требования к данным из парсинга и скрапинга».

Принятые оговорки

• В строке ЧП, руб на листе MVP пояснения есть опечатка: указан П97, но в проекте используем П95. Это уже зафиксировано в «РНП — Короткий отчёт» и «РНП — Аналитика товара».
• Показатели П109–П112 (Заказали/Выкупили из нишевой аналитики) в MVP по листу MVP пояснения не участвуют. Они остаются отдельным внешним парсерным контуром и в эту карту не входят.
• Для части WB-полей workbook расходится между листами метрики, меры и показатели и АПИ. В этой карте фиксируется уже выбранный проектный контракт, а не все исторические варианты из xlsx.

Статусы

• fixed — источник и правило достаточно определены для реализации.
• tech — бизнес-смысл уже понятен, но остаётся техническое уточнение по маппингу/формуле.

1. WB API

2. 1С

3. Внешний скрапер / парсер другой команды

Связанные зависимости вне MVP-таблицы:

• П11 Показы не отображается отдельной строкой в MVP, но нужен для расчёта П18 и П134.
• Внешние нишевые показатели П109–П112 остаются вне MVP, хотя тоже приходят из готового парсера другой команды.

4. Расчётные показатели в DWH

4.1 Воронка, фильтры и операционные показатели

4.2 План / факт, дельты и финансовые витринные метрики

5. Показатели вне текущего зафиксированного контура

6. Ненумерованные элементы MVP

Это важные элементы интерфейса РНП, которые присутствуют на листе MVP пояснения, но не имеют собственного номера показателя:

Что смотреть дальше

• Экранное размещение и UX: «РНП — Блок фильтров», «РНП — Короткий отчёт», «РНП — Паспорт товара», «РНП — Аналитика товара», «РНП — История товара», «РНП — Основная таблица»
• Контракты интеграций: «Требования к данным из 1С», «Требования к данным из API WB», «Требования к данным из парсинга и скрапинга»

Целевая модель данных

Целевое состояние данных для системы в целом:

• РНП;
• auth / RBAC / admin;
• ETL и мониторинг;
• write-back в WB;
• исторические факты и витрины.

Из этого документа сознательно исключены подвешенные блоки, вынесенные из текущего контура:

• П29, П30 — плановая оборачиваемость;
• П114 — достижение параметров оборачиваемости;
• другие future-элементы.

Рекомендация по хранению

Базовый вариант: PostgreSQL + ClickHouse.

• PG — operational state, auth, admin, mutable entities.
• CH — история, снапшоты, факты, derived-метрики, витрины.
• Часть текущего состояния можно дублировать из PG в CH, если это упрощает сборку витрин.

Правила

• Один токен WB = одно юрлицо.
• Продуктовый canonical business key: product_bk = wb_seller_tin + vendor_code.
• vendor_code остаётся пользовательским и интеграционным идентификатором, но в модели CH не считаем его глобально уникальным сам по себе.
• nm_id — карточка WB, imt_id — группа карточек WB.
• collection и manager храним как SCD Type 2.
• Справочные атрибуты 1С тоже храним исторически как SCD Type 2.
• Нормативы для расчёта планов из 1С храним отдельно от месячного плана продаж.
• wb_card_created_at — отдельный технический атрибут карточки WB.
• П38 не читается напрямую из WB API, а считается по нашим daily stock snapshots.
• Рекламный слой WB храним в двух фактах с разным grain: история расходов кампании отдельно от товарной статистики рекламы.
• Для расчётов РНП допускаем отдельные промежуточные поля в витринах, даже если они не показываются пользователю как самостоятельные показатели.
• Derived-метрики РНП считаются в CH, не в operational-слое.
• В auth-слое email считаем уникальным логином, если он заполнен.
• Precedence статусов пользователя для входа: deleted_at -> employment_status=fired -> is_blocked=true -> active=false -> иначе вход разрешён.
• PG_DEPARTMENTS.head_user_id может ссылаться только на пользователя того же отдела с ролью РОП; поле остаётся nullable.
• Все raw facts в CH хранят минимальный lineage: ingest_batch_id, pipeline_run_id, source_meta_json, loaded_at.
• В source_meta_json кладём source-specific lineage: Kafka topic/partition/offset/event_id, file name для выгрузок или request context для API-загрузок.
• Исторический доступ в РНП режем по SCD: прошлые периоды показываем по историческому assignment и историческому составу отдела, а не по текущему состоянию оргструктуры.

1. PostgreSQL

Это сущности, которые лучше держать в PG, потому что они часто мутируют, требуют точечных update/delete, участвуют в auth/RBAC или являются operational state.

erDiagram
    PG_ROLES {
        string code PK
        string name
        boolean is_system
        datetime created_at
        datetime updated_at
    }

    PG_DEPARTMENTS {
        bigint id PK
        boolean active
        string name
        bigint head_user_id FK
        boolean is_default
        datetime created_at
        datetime updated_at
        datetime deleted_at
    }

    PG_USERS {
        bigint id PK
        string employee_guid_1c UK
        boolean active
        string lastname
        string firstname
        string middlename
        string full_name
        string email UK
        string password_hash
        datetime password_changed_at
        string role_code FK
        bigint department_id FK
        string employment_status
        boolean is_blocked
        datetime invited_at
        datetime last_login_at
        datetime created_at
        datetime updated_at
        datetime deleted_at
    }

    PG_USER_SESSIONS {
        string session_id PK
        bigint user_id FK
        string refresh_token_hash
        string ip
        string user_agent
        datetime expires_at
        datetime revoked_at
        datetime created_at
    }

    PG_PASSWORD_RESET_TOKENS {
        string token_id PK
        bigint user_id FK
        string token_hash
        datetime expires_at
        datetime used_at
        datetime created_at
    }

    PG_AUTH_LOGIN_ATTEMPTS {
        bigint id PK
        bigint user_id FK
        string email
        string ip
        string user_agent
        string outcome
        string failure_reason
        datetime created_at
    }

    PG_PASSWORD_RESET_REQUESTS {
        bigint id PK
        bigint user_id FK
        string email
        string ip
        string request_status
        datetime created_at
    }

    PG_CORE_SETTINGS {
        bigint id PK
        bigint default_department_id FK
        int password_reset_ttl_minutes
        int admin_audit_retention_days
        int monitoring_feed_depth_days
        bigint updated_by_user_id FK
        datetime updated_at
    }

    PG_DYNAMIC_SETTINGS {
        string key PK
        string value_type
        json value_json
        bigint updated_by_user_id FK
        datetime updated_at
    }

    PG_EXTERNAL_SERVICE_TOKENS {
        bigint id PK
        string service_code
        string label
        string secret_ref
        boolean is_active
        datetime rotated_at
        datetime created_at
        datetime updated_at
    }

    PG_WB_CABINETS {
        bigint id PK
        bigint external_service_token_id FK
        string seller_id
        string tin
        string name
        boolean is_active
        datetime synced_at
        datetime created_at
        datetime updated_at
    }

    PG_ADMIN_AUDIT_LOG {
        bigint id PK
        bigint actor_user_id FK
        string action_type
        string entity_type
        string entity_id
        json before_payload
        json after_payload
        datetime created_at
    }

    PG_WRITEBACK_JOBS {
        bigint id PK
        string job_type
        string target_system
        string status
        string idempotency_key
        string external_task_id
        bigint requested_by_user_id FK
        int retry_count
        datetime next_retry_at
        string error_code
        datetime locked_at
        string worker_id
        string resync_status
        json request_payload
        json response_payload
        datetime created_at
        datetime finished_at
    }

    PG_WRITEBACK_JOB_ITEMS {
        bigint id PK
        bigint job_id FK
        bigint nm_id
        bigint imt_id_before
        bigint imt_id_after
        string result_status
        string error_code
        string error_text
        string external_item_id
        string resync_status
        datetime created_at
    }

    PG_PRODUCT_ACTION_PLANS {
        bigint id PK
        bigint nm_id
        date plan_date
        bigint author_user_id FK
        text plan_text
        datetime created_at
        datetime updated_at
    }

    PG_ETL_PIPELINE_STATUS {
        bigint id PK
        string pipeline_code
        string last_status
        datetime last_started_at
        datetime last_finished_at
        int duration_sec
        datetime next_run_at
        datetime data_watermark_at
        int freshness_lag_minutes
        bigint processed_rows
        bigint rejected_rows
        bigint skipped_rows
        bigint duplicate_rows
        string error_message
        datetime updated_at
    }

    PG_SOURCE_SYNC_STATUS {
        bigint id PK
        string source_system
        string source_entity
        string sync_status
        datetime last_success_at
        datetime data_watermark_at
        int freshness_lag_minutes
        bigint processed_rows
        bigint rejected_rows
        bigint skipped_rows
        bigint duplicate_rows
        string error_message
        datetime updated_at
    }

    PG_INTEGRATION_INBOX {
        bigint id PK
        string source_system
        string event_type
        string entity_type
        string entity_key
        string processing_status
        json payload
        datetime event_time
        datetime processed_at
    }

    PG_INTEGRATION_FAILED_EVENTS {
        bigint id PK
        bigint inbox_event_id FK
        string source_system
        string event_type
        string entity_type
        string entity_key
        string failure_stage
        string error_code
        string error_text
        json payload
        datetime failed_at
    }

    PG_INTEGRATION_PIPELINE_RUNS {
        bigint id PK
        string pipeline_code
        string run_status
        int processed_events
        int failed_events
        string error_code
        string error_text
        datetime started_at
        datetime finished_at
    }

    PG_ROLES ||--o{ PG_USERS : grants
    PG_DEPARTMENTS ||--o{ PG_USERS : has_users
    PG_DEPARTMENTS ||--o{ PG_CORE_SETTINGS : default_for_new_users
    PG_USERS ||--o{ PG_USER_SESSIONS : owns
    PG_USERS ||--o{ PG_PASSWORD_RESET_TOKENS : receives
    PG_USERS ||--o{ PG_AUTH_LOGIN_ATTEMPTS : attempts
    PG_USERS ||--o{ PG_PASSWORD_RESET_REQUESTS : requests_reset
    PG_USERS ||--o{ PG_ADMIN_AUDIT_LOG : acts
    PG_USERS ||--o{ PG_WRITEBACK_JOBS : requests
    PG_WRITEBACK_JOBS ||--o{ PG_WRITEBACK_JOB_ITEMS : contains
    PG_USERS ||--o{ PG_PRODUCT_ACTION_PLANS : authors
    PG_USERS ||--o{ PG_CORE_SETTINGS : updates
    PG_USERS ||--o{ PG_DYNAMIC_SETTINGS : updates
    PG_EXTERNAL_SERVICE_TOKENS ||--o{ PG_WB_CABINETS : identifies

2. ClickHouse: master data и исторические измерения

Это слой исторических измерений и текущего аналитического контекста товара.

erDiagram
    CH_DIM_PRODUCT_SCD {
        bigint product_sk PK
        string product_bk
        string vendor_code
        bigint nm_id
        bigint imt_id
        string wb_seller_tin
        string wb_seller_name
        string brand_name
        string subject_name
        datetime wb_card_created_at
        datetime valid_from
        datetime valid_to
        boolean is_current
    }

    CH_DIM_PRODUCT_ATTR_SCD {
        bigint product_attr_sk PK
        string product_bk
        string vendor_code
        string category_1c
        string kind_1c
        string product_category
        string season_code
        string features
        string gender
        string country
        string direction
        string group_name
        string material_upper
        string material_lining
        string upper_color
        string color
        string factory
        boolean is_repeat
        datetime valid_from
        datetime valid_to
        boolean is_current
    }

    CH_DIM_PRODUCT_ASSIGNMENT_SCD {
        bigint assignment_sk PK
        string product_bk
        string vendor_code
        string collection_code
        string manager_guid_1c
        datetime valid_from
        datetime valid_to
        boolean is_current
    }

    CH_DIM_SEASON_RATE {
        bigint season_rate_sk PK
        string season_code
        decimal cny_rub_rate
        datetime valid_from
        datetime valid_to
        boolean is_current
    }

    CH_DIM_PLAN_NORMS_SCD {
        bigint plan_norm_sk PK
        string norm_scope_key
        decimal wb_commission_percent
        decimal tax_percent
        decimal variable_cost_per_unit
        decimal fixed_cost_per_unit
        datetime valid_from
        datetime valid_to
        boolean is_current
    }

    CH_DIM_WB_PROMOTIONS {
        bigint promotion_id PK
        string name
        datetime start_date
        datetime end_date
        datetime loaded_at
    }

    CH_DIM_PRODUCT_SCD ||--o{ CH_DIM_PRODUCT_ATTR_SCD : has_attrs_history
    CH_DIM_PRODUCT_SCD ||--o{ CH_DIM_PRODUCT_ASSIGNMENT_SCD : has_assignment_history

3. ClickHouse: raw facts from WB

erDiagram
    CH_FACT_WB_SALES_FUNNEL_DAILY {
        date snapshot_date
        string product_bk
        bigint nm_id
        string wb_seller_tin
        string vendor_code
        int open_count
        int cart_count
        int order_count
        decimal order_sum
        int cancel_count
        int buyout_count
        decimal buyout_sum
        decimal share_order_percent
        int add_to_wishlist
        int wbclub_order_count
        int wbclub_buyout_count
        int time_to_ready
        decimal product_rating
        decimal feedback_rating
        decimal wbclub_avg_price
        string ingest_batch_id
        string pipeline_run_id
        json source_meta_json
        datetime loaded_at
    }

    CH_FACT_WB_STOCK_PRODUCT_DAILY {
        date snapshot_date
        string product_bk
        bigint nm_id
        string wb_seller_tin
        int stock_count
        decimal stock_sum
        string ingest_batch_id
        string pipeline_run_id
        json source_meta_json
        datetime loaded_at
    }

    CH_FACT_WB_STOCK_OFFICE_DAILY {
        date snapshot_date
        string product_bk
        bigint nm_id
        string office_id
        string office_name
        string region_name
        int stock_count
        string ingest_batch_id
        string pipeline_run_id
        json source_meta_json
        datetime loaded_at
    }

    CH_FACT_WB_STOCK_SIZE_DAILY {
        date snapshot_date
        string product_bk
        bigint nm_id
        bigint chrt_id
        string sku
        string warehouse_id
        int quantity
        string ingest_batch_id
        string pipeline_run_id
        json source_meta_json
        datetime loaded_at
    }

    CH_FACT_WB_STOCK_TRANSIT_DAILY {
        date snapshot_date
        string product_bk
        bigint nm_id
        string wb_seller_tin
        int in_way_to_client
        int in_way_from_client
        string ingest_batch_id
        string pipeline_run_id
        json source_meta_json
        datetime loaded_at
    }

    CH_FACT_WB_CONTENT_SNAPSHOT_DAILY {
        date snapshot_date
        string product_bk
        bigint nm_id
        bigint imt_id
        string main_photo_url
        json photos_json
        json tags_json
        datetime wb_card_created_at
        string ingest_batch_id
        string pipeline_run_id
        json source_meta_json
        datetime loaded_at
    }

    CH_FACT_WB_ADV_UPDATES {
        datetime upd_time
        bigint advert_id
        string camp_name
        string payment_type
        int advert_type
        int advert_status
        int upd_num
        decimal upd_sum
        string currency
        string ingest_batch_id
        string pipeline_run_id
        json source_meta_json
        datetime loaded_at
    }

    CH_FACT_WB_ADV_FULLSTATS_NM_DAILY {
        date stat_date
        bigint advert_id
        int app_type
        string product_bk
        bigint nm_id
        int views
        int clicks
        int atbs
        int orders
        int canceled
        int shks
        decimal spend_sum
        decimal sum_price
        decimal cpc
        decimal ctr
        decimal cr
        string ingest_batch_id
        string pipeline_run_id
        json source_meta_json
        datetime loaded_at
    }

    CH_FACT_WB_PROMOTION_NM_DAILY {
        date snapshot_date
        bigint promotion_id
        string product_bk
        bigint nm_id
        boolean in_action
        decimal price
        decimal plan_price
        decimal discount
        decimal plan_discount
        string ingest_batch_id
        string pipeline_run_id
        json source_meta_json
        datetime loaded_at
    }

    CH_FACT_WB_SUPPLIER_ORDERS_RAW {
        date order_date
        string product_bk
        bigint nm_id
        string vendor_code
        decimal discount_percent
        string ingest_batch_id
        string pipeline_run_id
        json raw_payload
        json source_meta_json
        datetime loaded_at
    }

    CH_FACT_WB_REGION_SALE_DAILY {
        date snapshot_date
        string product_bk
        bigint nm_id
        string region_code
        decimal sale_item_invoice_qty
        string ingest_batch_id
        string pipeline_run_id
        json raw_payload
        json source_meta_json
        datetime loaded_at
    }

    CH_FACT_WB_PENALTY_RAW {
        string report_type
        date event_date
        string product_bk
        bigint nm_id
        decimal amount
        string ingest_batch_id
        string pipeline_run_id
        json raw_payload
        json source_meta_json
        datetime loaded_at
    }

    CH_EVENT_PRODUCT_CARD_CHANGE {
        bigint event_id PK
        string product_bk
        bigint nm_id
        string change_type
        json before_payload
        json after_payload
        string ingest_batch_id
        string pipeline_run_id
        json source_meta_json
        datetime detected_at
        string source
    }

    CH_FACT_WB_REVIEWS_DAILY {
        date snapshot_date
        string product_bk
        bigint nm_id
        decimal feedback_rating
        int negative_review_count
        int total_review_count
        int reviews_to_override
        string ingest_batch_id
        string pipeline_run_id
        json source_meta_json
        datetime loaded_at
    }

    CH_DIM_PRODUCT_SCD ||--o{ CH_FACT_WB_SALES_FUNNEL_DAILY : has_sales_funnel
    CH_DIM_PRODUCT_SCD ||--o{ CH_FACT_WB_STOCK_PRODUCT_DAILY : has_stock
    CH_DIM_PRODUCT_SCD ||--o{ CH_FACT_WB_STOCK_OFFICE_DAILY : has_office_stock
    CH_DIM_PRODUCT_SCD ||--o{ CH_FACT_WB_STOCK_SIZE_DAILY : has_size_stock
    CH_DIM_PRODUCT_SCD ||--o{ CH_FACT_WB_STOCK_TRANSIT_DAILY : has_transit
    CH_DIM_PRODUCT_SCD ||--o{ CH_FACT_WB_CONTENT_SNAPSHOT_DAILY : has_snapshots
    CH_DIM_PRODUCT_SCD ||--o{ CH_FACT_WB_ADV_FULLSTATS_NM_DAILY : has_ad_stats
    CH_DIM_WB_PROMOTIONS ||--o{ CH_FACT_WB_PROMOTION_NM_DAILY : contains
    CH_DIM_PRODUCT_SCD ||--o{ CH_FACT_WB_PROMOTION_NM_DAILY : participates
    CH_DIM_PRODUCT_SCD ||--o{ CH_FACT_WB_SUPPLIER_ORDERS_RAW : has_supplier_orders
    CH_DIM_PRODUCT_SCD ||--o{ CH_FACT_WB_REGION_SALE_DAILY : has_region_sales
    CH_DIM_PRODUCT_SCD ||--o{ CH_FACT_WB_PENALTY_RAW : has_penalties
    CH_DIM_PRODUCT_SCD ||--o{ CH_EVENT_PRODUCT_CARD_CHANGE : has_changes
    CH_DIM_PRODUCT_SCD ||--o{ CH_FACT_WB_REVIEWS_DAILY : has_reviews

4. ClickHouse: raw facts from 1С и внешних парсеров

erDiagram
    CH_FACT_1C_PURCHASE_ORDERS {
        string order_id_1c
        date order_date
        string product_bk
        string vendor_code
        string season_code
        boolean is_reorder
        int ordered_qty
        decimal cost_cny
        string ingest_batch_id
        string pipeline_run_id
        json source_meta_json
        datetime loaded_at
    }

    CH_FACT_1C_RECEIPTS {
        string receipt_id_1c
        date receipt_date
        string product_bk
        string vendor_code
        decimal unit_cost_rub
        string ingest_batch_id
        string pipeline_run_id
        json source_meta_json
        datetime loaded_at
    }

    CH_FACT_1C_SALES_PLAN_MONTHLY {
        date plan_month
        string product_bk
        string vendor_code
        decimal revenue_plan_rub
        int qty_plan
        decimal price_plan_current
        decimal price_plan_next
        decimal pct_sold_plan
        decimal pct_sold_plan_collection
        decimal profit_plan_rub
        decimal unit_cost_plan
        decimal cost_plan_total
        decimal ad_cost_plan_rub
        int orders_plan_qty
        int carts_plan_qty
        int opens_plan_qty
        int views_plan_qty
        decimal shipments_plan_rub
        decimal avg_order_price_plan
        string ingest_batch_id
        string pipeline_run_id
        json source_meta_json
        datetime loaded_at
    }

    CH_FACT_1C_SHIPMENTS {
        string shipment_id_1c
        date shipment_date
        string product_bk
        string vendor_code
        decimal shipped_amount_rub
        string ingest_batch_id
        string pipeline_run_id
        json source_meta_json
        datetime loaded_at
    }

    CH_FACT_1C_RECEIVING_ORDERS {
        string receiving_order_id_1c
        date posting_date
        string product_bk
        string vendor_code
        int qty_to_ship
        string ingest_batch_id
        string pipeline_run_id
        json source_meta_json
        datetime loaded_at
    }

    CH_FACT_SPP_HOURLY {
        datetime snapshot_ts
        string product_bk
        bigint nm_id
        decimal spp_percent
        string ingest_batch_id
        string pipeline_run_id
        json source_meta_json
        datetime loaded_at
    }

    CH_FACT_VIEWS_DAILY {
        date snapshot_date
        string product_bk
        bigint nm_id
        int views
        string ingest_batch_id
        string pipeline_run_id
        json source_meta_json
        datetime loaded_at
    }

    CH_DIM_PRODUCT_SCD ||--o{ CH_FACT_1C_PURCHASE_ORDERS : has_orders
    CH_DIM_PRODUCT_SCD ||--o{ CH_FACT_1C_RECEIPTS : has_receipts
    CH_DIM_PRODUCT_SCD ||--o{ CH_FACT_1C_SALES_PLAN_MONTHLY : has_plans
    CH_DIM_PRODUCT_SCD ||--o{ CH_FACT_1C_SHIPMENTS : has_shipments
    CH_DIM_PRODUCT_SCD ||--o{ CH_FACT_1C_RECEIVING_ORDERS : has_receiving_orders
    CH_DIM_PRODUCT_SCD ||--o{ CH_FACT_SPP_HOURLY : has_spp
    CH_DIM_PRODUCT_SCD ||--o{ CH_FACT_VIEWS_DAILY : has_views
    CH_DIM_SEASON_RATE ||--o{ CH_FACT_1C_SALES_PLAN_MONTHLY : uses_rate

5. ClickHouse: derived marts

erDiagram
    CH_MART_RNP_DAILY {
        date snapshot_date
        bigint nm_id
        string product_bk
        string vendor_code
        string collection_code
        string manager_guid_1c
        string wb_seller_tin
        decimal revenue_plan
        decimal revenue_fact
        int qty_plan
        int orders_plan
        decimal buyout_sum
        int buyout_count
        int order_count
        int stock_count
        int stock_in_transit
        decimal price_plan_current
        decimal price_plan_next
        decimal price_fact
        decimal price_minus_spp
        decimal discount_percent_fact
        decimal stock_sum
        decimal wbclub_price
        decimal rating_feedback
        decimal spp_percent
        int views
        decimal click_ctr
        decimal cart_cr
        decimal order_cr
        decimal buyout_pct
        decimal pct_sold_plan
        decimal pct_sold_fact
        decimal gross_profit_plan
        decimal gross_profit_fact
        decimal gross_margin_plan
        decimal gross_margin_fact
        decimal drr_fact
        decimal all_commissions_fact
        decimal fx_diff_fact
        decimal autoffstock_pct
        string abc_class
        decimal penalties_fact
        int days_on_site_count
        decimal localization_index
        decimal ktr_value
        boolean in_action
        string promotion_name
        decimal ad_spend_fact
        decimal ad_click_ctr
        decimal cpo
        decimal shipped_pct
        decimal net_profit_plan
        decimal net_profit_fact
        decimal net_margin_plan
        decimal net_margin_fact
        decimal promotion_participation_pct
        int negative_review_count
        int reviews_to_override
        json calc_payload
        datetime loaded_at
    }

    CH_MART_RNP_ROLLUP {
        string period_grain
        date period_start_date
        bigint nm_id
        string product_bk
        string vendor_code
        string collection_code
        string manager_guid_1c
        string wb_seller_tin
        decimal revenue_plan
        decimal revenue_fact
        decimal revenue_plan_pct
        decimal revenue_delta
        decimal pct_sold_plan
        decimal pct_sold_fact
        decimal pct_sold_plan_pct
        decimal pct_sold_delta
        decimal net_profit_plan
        decimal net_profit_fact
        decimal net_profit_plan_pct
        decimal net_profit_delta
        decimal qty_plan_pct
        decimal qty_delta
        decimal price_plan_pct
        decimal price_delta
        decimal net_margin_plan
        decimal net_margin_fact
        decimal net_margin_plan_pct
        decimal net_margin_delta
        decimal ad_spend_plan
        decimal ad_spend_fact
        decimal ad_spend_plan_pct
        decimal ad_spend_delta
        decimal drr_plan
        decimal drr_fact
        decimal drr_plan_pct
        decimal drr_delta
        decimal gross_profit_plan
        decimal gross_profit_fact
        decimal gross_margin_plan
        decimal gross_margin_fact
        decimal promotion_participation_pct
        decimal manager_bonus_amount
        decimal localization_index
        decimal ktr_value
        json aggregated_payload
        datetime loaded_at
    }

    CH_DIM_PRODUCT_SCD ||--o{ CH_MART_RNP_DAILY : denormalizes
    CH_DIM_PRODUCT_SCD ||--o{ CH_MART_RNP_ROLLUP : denormalizes
    CH_DIM_PRODUCT_ASSIGNMENT_SCD ||--o{ CH_MART_RNP_DAILY : scopes
    CH_DIM_PRODUCT_ASSIGNMENT_SCD ||--o{ CH_MART_RNP_ROLLUP : scopes

6. Cross-store связи

Это не физические FK между БД, а логические связи, которые надо держать в голове при проектировании ETL и приложения.

erDiagram
    PG_WB_CABINETS {
        bigint id PK
        string seller_id
        string tin
        string name
    }

    PG_USERS {
        bigint id PK
        string employee_guid_1c
        string full_name
        string role_code
        bigint department_id
    }

    CH_DIM_PRODUCT_SCD {
        bigint product_sk PK
        string product_bk
        string vendor_code
        bigint nm_id
        bigint imt_id
        string wb_seller_tin
    }

    CH_DIM_PRODUCT_ASSIGNMENT_SCD {
        bigint assignment_sk PK
        string product_bk
        string vendor_code
        string collection_code
        string manager_guid_1c
    }

    PG_WB_CABINETS ||--o{ CH_DIM_PRODUCT_SCD : scopes_by_tin
    PG_USERS ||--o{ CH_DIM_PRODUCT_ASSIGNMENT_SCD : manages_by_guid

Что точно лучше держать в PG

• PG_USERS
• PG_ROLES
• PG_DEPARTMENTS
• PG_USER_SESSIONS
• PG_PASSWORD_RESET_TOKENS
• PG_AUTH_LOGIN_ATTEMPTS
• PG_PASSWORD_RESET_REQUESTS
• PG_CORE_SETTINGS
• PG_DYNAMIC_SETTINGS
• PG_EXTERNAL_SERVICE_TOKENS
• PG_WB_CABINETS
• PG_ADMIN_AUDIT_LOG
• PG_WRITEBACK_JOBS
• PG_WRITEBACK_JOB_ITEMS
• PG_PRODUCT_ACTION_PLANS
• PG_ETL_PIPELINE_STATUS
• PG_SOURCE_SYNC_STATUS
• PG_INTEGRATION_INBOX
• PG_INTEGRATION_FAILED_EVENTS
• PG_INTEGRATION_PIPELINE_RUNS

Что логично держать в CH

• все raw facts из 1С, WB API, внешних парсеров;
• все ежедневные снапшоты;
• все SCD-таблицы;
• все derived-витрины РНП;
• события изменений карточки WB.

Словарь таблиц

Ниже короткое человеческое объяснение, что означает каждая таблица.

PostgreSQL

• PG_ROLES

Справочник ролей RBAC. Нужен, чтобы явно хранить доступные роли системы: Менеджер, РОП, Админ, Супер-админ, ГД.

• PG_DEPARTMENTS

Справочник отделов. Хранит сами отделы, признак отдела по умолчанию и руководителя отдела. Если head_user_id заполнен, он должен указывать на пользователя из этого же отдела с ролью РОП.

• PG_USERS

Основная таблица пользователей приложения. Это не “исторический сотрудник”, а текущее состояние учётной записи: кто пользователь, активен ли он, заблокирован ли, в каком он отделе и какая у него роль.

• PG_USER_SESSIONS

Активные и завершённые пользовательские сессии. Нужна для logout, инвалидирования доступа и контроля активных логинов.

• PG_PASSWORD_RESET_TOKENS

Одноразовые токены для восстановления пароля. Нужны только auth-слою.

• PG_AUTH_LOGIN_ATTEMPTS

Журнал попыток входа. Нужен для истории неуспешных логинов, расследования проблем авторизации и базовых anti-bruteforce правил.

• PG_PASSWORD_RESET_REQUESTS

Журнал запросов на восстановление пароля. Нужен для rate limit и контроля частоты reset-запросов по email / IP.

• PG_CORE_SETTINGS

Typed-глобальные настройки системы, которые критичны для логики приложения. Здесь держим параметры вроде отдела по умолчанию, TTL reset-link и срока хранения аудита, чтобы не терять валидацию и ссылочную целостность.

• PG_DYNAMIC_SETTINGS

Динамические key-value настройки, которые не требуют отдельных FK и строгой схемы. Это запасной контейнер для действительно гибких настроек, а не место для критичных параметров бизнес-логики.

• PG_EXTERNAL_SERVICE_TOKENS

Хранилище подключённых внешних токенов и ссылок на секреты. Здесь не аналитика, а operational-конфигурация интеграций.

• PG_WB_CABINETS

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

• PG_ADMIN_AUDIT_LOG

Аудит административных действий. Хранит факт “кто что поменял” в users/departments/settings.

• PG_WRITEBACK_JOBS

Верхнеуровневая сущность write-back операции. Одна запись = один запрос/операция в сторону WB, например merge/split или изменение параметров участия в акции. Помимо факта операции хранит operational-поля для реальной эксплуатации: идемпотентность, внешний task/request id WB, ретраи, блокировку воркером и статус post-writeback re-sync.

• PG_WRITEBACK_JOB_ITEMS

Детализация write-back job по карточкам. Нужна, когда одна операция затрагивает несколько nm_id. На этом уровне фиксируем per-item результат, внешний идентификатор WB при необходимости, код ошибки и статус re-sync.

Write-back state machine:

• PG_WRITEBACK_JOBS.status: new -> running -> success
• PG_WRITEBACK_JOBS.status: new -> running -> failed -> retry_scheduled -> running
• PG_WRITEBACK_JOBS.status: running -> cancelled если операцию остановили до успешного завершения
• PG_WRITEBACK_JOBS.resync_status: not_needed -> done для операций без post-sync
• PG_WRITEBACK_JOBS.resync_status: pending -> running -> done
• PG_WRITEBACK_JOBS.resync_status: pending -> running -> failed -> retry_scheduled -> running
• PG_WRITEBACK_JOB_ITEMS.result_status: как минимум pending / success / failed / skipped
• PG_WRITEBACK_JOB_ITEMS.resync_status: повторяет lifecycle post-writeback re-sync на уровне конкретного nm_id

Правило: write-back и post-writeback re-sync считаем двумя разными state-машинами. У job может быть status = success, но resync_status = pending|running|failed, пока данные ещё не подтверждены обратной синхронизацией.

• PG_PRODUCT_ACTION_PLANS

Редактируемый пользователем “план действий” по товару. Это не импорт из 1С и не аналитика, а внутреннее прикладное поле системы.

• PG_ETL_PIPELINE_STATUS

Кэш статусов пайплайнов для админского экрана мониторинга. Помимо статуса последнего запуска держим operational-показатели вроде watermark, freshness lag и количества обработанных / rejected / skipped / duplicate строк.

• PG_SOURCE_SYNC_STATUS

Сводное состояние по каждому источнику и сущности загрузки. Нужен, чтобы мониторинг показывал не только “последний DAG зелёный”, но и реальную свежесть данных по каждому source-слою отдельно.

• PG_INTEGRATION_INBOX

Operational inbox для входящих интеграционных событий. Здесь живёт очередь на обработку и текущий processing state, но не долгоживущий аудит и не DLQ.

• PG_INTEGRATION_FAILED_EVENTS

Отдельный слой failed / dead-letter событий. Нужен для расследований, повторной обработки и хранения ошибок без превращения inbox в помойку.

• PG_INTEGRATION_PIPELINE_RUNS

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

ClickHouse: dimensions и SCD

• CH_DIM_PRODUCT_SCD

Главная историческая продуктовая размерность. Это точка, где стыкуются 1С и WB:

product_bk, vendor_code, nm_id, imt_id, юрлицо, базовые WB-атрибуты.

Канонический бизнес-ключ в аналитическом слое — product_bk = wb_seller_tin + vendor_code.

• CH_DIM_PRODUCT_ATTR_SCD

История справочных атрибутов товара из 1С: категория 1С, сезон, фабрика, материалы, повтор и т.д. Нужна, потому что атрибуты могут меняться во времени.

• CH_DIM_PRODUCT_ASSIGNMENT_SCD

История назначения товара на коллекцию и менеджера. Критична для корректной аналитики по менеджерам за прошлые периоды.

• CH_DIM_SEASON_RATE

История курса юань/руб по сезонам. Используется в расчётах и плановых моделях.

• CH_DIM_PLAN_NORMS_SCD

История нормативов для расчёта планов из 1С. Здесь лежат П83, П85, П87, П88. Держим отдельно от месячного плана продаж, потому что это другой источник и другой жизненный цикл. Business-grain нормативов подтверждён клиентом — norm_scope_key определяет scope норматива (категория/сезон/юрлицо/бренд/коллекция/тип товара или их комбинация).

• CH_DIM_WB_PROMOTIONS

Справочник акций WB. Хранит сами акции как отдельные сущности, а не участие товара в них.

ClickHouse: raw facts from WB

• CH_FACT_WB_SALES_FUNNEL_DAILY

Основной ежедневный WB-факт по карточке товара: открытия, корзины, заказы, выкупы, рейтинги, WB Club и т.д. Это одна из самых важных fact-таблиц для РНП.

• CH_FACT_WB_STOCK_PRODUCT_DAILY

Ежедневные агрегированные остатки по товару. Нужна для П33, П34, П38, П113 и других derived-метрик.

• CH_FACT_WB_STOCK_OFFICE_DAILY

Ежедневные остатки по офисам/складам WB. Это складской разрез, который нужен не для общего остатка, а для более детальной аналитики.

• CH_FACT_WB_STOCK_SIZE_DAILY

Ежедневные остатки по размеру и складу. Это слой, который нужен для расчёта П89 Аутоффсток и всех size-aware производных метрик.

• CH_FACT_WB_STOCK_TRANSIT_DAILY

Ежедневный факт по остаткам “в пути к клиенту / от клиента”.

• CH_FACT_WB_CONTENT_SNAPSHOT_DAILY

Ежедневный снапшот состояния карточки WB: фото, теги, imt_id, дата создания карточки. Нужен и для UI, и для аудита изменений карточки.

• CH_FACT_WB_ADV_UPDATES

История расходов на рекламу из GET /adv/v1/upd. Реальный grain по документации и live API: advert_id × upd_time. Здесь лежит cost-history кампании, а не товарный слой, и nm_id в этом факте нет.

• CH_FACT_WB_ADV_FULLSTATS_NM_DAILY

Детальная статистика рекламы из GET /adv/v3/fullstats. Реальный raw-grain по документации и live API: advert_id × stat_date × app_type × nm_id. Именно здесь живут товарные views / clicks / atbs / orders и spend на уровне nm_id.

• CH_FACT_WB_PROMOTION_NM_DAILY

Ежедневное участие конкретного товара в конкретной акции WB. Нужна для П104, истории участия в акциях и фильтрации “акционный товар / неакционный”.

• CH_FACT_WB_SUPPLIER_ORDERS_RAW

Raw-слой WB supplier/orders. Нужен в первую очередь для % скидки факт (П66) и как факт-источник для downstream-расчётов, где используется скидка WB.

• CH_FACT_WB_REGION_SALE_DAILY

Ежедневные продажи по регионам / ЦФО. Пока это узкоспециализированный слой для региональной аналитики.

• CH_FACT_WB_PENALTY_RAW

Raw-удержания и штрафы WB. Здесь не итоговая метрика, а сырые строки из retention reports, из которых потом собирается П103.

• CH_EVENT_PRODUCT_CARD_CHANGE

События изменений карточки WB. Это уже не снапшот, а дельта: что изменилось между двумя снапшотами.

• CH_FACT_WB_REVIEWS_DAILY

Ежедневные данные по отзывам: рейтинг, количество негативных отзывов, расчётное количество для перекрытия негатива. Источник — WB API (отзывы/рейтинги), агрегируется daily по nmID.

ClickHouse: raw facts from 1С

• CH_FACT_1C_PURCHASE_ORDERS

Raw-факт из заказов поставщику. Нужен для П45, П91, а также для расчёта Дозаказ, шт.

• CH_FACT_1C_RECEIPTS

Raw-факт из документов прихода / приобретения. Это фактическая себестоимость в рублях и дата поступления.

• CH_FACT_1C_SALES_PLAN_MONTHLY

Месячный плановый факт из 1С. Здесь лежат выручка план, цена план, реклама план, ЧП план и другие плановые величины.

• CH_FACT_1C_SHIPMENTS

Факт отгрузок из 1С. Нужен для П155 и связанных производных показателей.

• CH_FACT_1C_RECEIVING_ORDERS

Raw-факт из приходного ордера. Нужен для ненумерованного “плана отгрузки”: downstream считаем posting_date + 4 дня, само транзиентное поле отдельно не храним.

ClickHouse: external parser / scraper facts

• CH_FACT_SPP_HOURLY

История СПП из внешнего скрапера. Нужна для исторического анализа и расчёта цены для покупателя.

• CH_FACT_VIEWS_DAILY

История показов из внешнего скрапера. Нужна для CTR и воронки, потому что в WB API “показы” в нужном смысле нет.

ClickHouse: marts

• CH_MART_RNP_DAILY

Главная ежедневная широкая витрина РНП. Именно из неё удобнее всего строить экран РНП, графики, daily drill-down и derived-метрики. В этой витрине держим текущие daily/history показатели и промежуточные расчётные поля вроде fx_diff_fact, если они нужны для формул верхнего уровня.

• CH_MART_RNP_ROLLUP

Ограниченный acceleration-layer поверх daily-витрины. Здесь держим только фиксированные предагрегации по понятным grain, например week и month, без универсального scope_key. Произвольные диапазоны и произвольные комбинации фильтров считаем из CH_MART_RNP_DAILY.

7. Покрытие текущих показателей РНП

Текущее правило простое:

• raw-показатели и справочные атрибуты лежат в CH_FACT_ и CH_DIM_;
• daily/history и аналитические расчёты лежат в CH_MART_RNP_DAILY;
• short report и period-level предагрегации лежат в CH_MART_RNP_ROLLUP, но только для фиксированных grain week/month; произвольные диапазоны считаются из CH_MART_RNP_DAILY.

Что это закрывает по текущему scope РНП:

• WB API: П1, П2, П3, П4, П5, П6, П7, П19, П20, П21, П33, П40, П66, П103, П104, П142;
• 1С: П44, П45, П46, П47, П48, П50, П55, П59, П62, П67, П68, П69, П71, П72, П77, П83, П85, П87, П88, П90, П91, П102, П141, П155, П156;
• внешний скрапер: П65, а также показы для расчёта П18 и П134;
• derived daily/history: П18, П26, П37, П42, П64, П79, П80, П81, П82, П84, П86, П89, П99, П113, П134, П135, П136, П137, П138, П139, П150, П153, П154, П95, П96;
• derived period/short report: П115–П133, П140, П144, П145.

Короткий словарь терминов

Короткие определения для терминов, которые регулярно встречаются в спеках РНП и обсуждениях с клиентом.

Ous

Что это: рабочее обозначение показателя Аутоффсток (П89).

Смысл: доля отсутствующих размеров относительно полной размерной горки артикула.

Пример: если у артикула должно быть 6 размеров, а в наличии есть 4, то Ous = 2 / 6 = 33%.

Где используется: «РНП — Аналитика товара», «РНП — История товара», «Карта происхождения MVP-показателей».

Что уже понятно: для расчёта нужен размерный разрез остатков. Источник размерных остатков — GET /api/v3/stocks (WB API), где есть chrtId, warehouseId, quantity.

ИЛ

Что это: Индекс локализации (П138).

Смысл: показатель WB, связанный с тем, насколько заказы локализуются относительно нужных складов / кластеров.

Где используется: «РНП — Аналитика товара», «Карта происхождения MVP-показателей».

Источник: парсинг POST /ns/analytics-api/content-analytics/api/v1/localization/report-by-nm (seller-content.wildberries.ru), поле localOrderPercent по nmID.

Частота: раз в день.

КТР

Что это: Коэффициент территориального распределения (П139).

Смысл: показатель из методики WB по локализации, который используется в расчёте ИЛ.

Где используется: «РНП — Аналитика товара», «Карта происхождения MVP-показателей».

Источник: парсинг POST /ns/categories-info/suppliers-portal-analytics/api/v1/localization-list (seller.wildberries.ru).

Правило расчёта: берём localOrderPercent (П138) для nmID, находим запись в indexts[], где left <= localOrderPercent <= right (включительно), значение index = КТР.

Частота: раз в день.

СПП

Что это: Скидка постоянного покупателя (П65).

Смысл: скидка покупателя, которая влияет на фактическую цену для покупателя.

Где используется: «РНП — История товара», «РНП — Паспорт товара», «Требования к данным из парсинга и скрапинга», «Карта происхождения MVP-показателей».

Источник: парсинг POST /ns/dp-api/discounts-prices/suppliers/api/v1/list/goods/filter (discounts-prices.wildberries.ru), поле discountOnSite.

Частота: раз в час.

Связанная формула: П64 = П42 * (1 - П65).

Макеты интерфейса

Набор визуальных макетов интерфейса (схематичный «каркас» приложения с низкой детализацией) собран в едином документе: макеты интерфейса (PDF).

Содержит макеты разделов:

• РНП — основная таблица, фильтры, паспорт товара, аналитика, история
• Администрирование — настройки, сотрудники, модальные окна