Управление БД для глобального fashion-бренда — распутали заказы, сток и возвраты с дюжины маркетплейсов.

Хаос

Глобальный fashion-производитель продавал через свои магазины, опт и больше дюжины маркетплейсов. Каждый канал отдавал свою схему: SKU не сходились внутри, возвраты вешались не на тот склад, сток двоился после акций.

Финансы не могли свести выручку по каналам. Ops не мог сказать, какой маркетплейс дал всплеск возвратов. У руководства стояли дашборды на таблицах, которые не соглашались друг с другом.

Подход

Под NDA разложили каждый входящий фид, зафиксировали канонические сущности продукта и заказа и собрали управляемое хранилище с lineage — каждая строка ведётся к исходному файлу, каналу и времени забора.

• Слой приёма — заборы по расписанию и SFTP-дропы, нормализация в staging
• Правила матчинга — внутренний SKU, EAN, ID маркетплейсов со скором уверенности
• Трансформы dbt — протестированные модели заказов, стока, возвратов, маржи по каналу
• Задачи сверки — сироты, двойные движения стока, расхождения VAT

Что изменилось у клиента

Одна база, которой доверяет руководство. P&L по каналам без марафонов VLOOKUP. Возвраты уходят в правильный узел фулфилмента. Онбординг нового маркетплейса — конфигурация, а не трёхмесячный BI-проект.

Пометка NDA

Имя клиента, точные каналы и дашборды конфиденциальны. Это резюме класса задачи и формы решения, не больше.