# Кейс fashion-ритейлера - PIM и маркетплейс-данные

Canonical: https://www.kt-team.ru/cases/fashion-retailer-pim-marketplace

Source: https://www.kt-team.ru/cases/fashion-retailer-pim-marketplace

Как команда уточнила идентификаторы, правила передачи цен и остатков, статусы интеграции и отображение ошибок в PIM-контуре.

![Схема обмена товарными данными между PIM и маркетплейсом](/assets/original/fashion-retailer-pim-marketplace.svg)

- **2 SKU:** разведены родительский и товарный идентификаторы
- **3 правила полей:** уточнены данные для цен, остатков и классификации
- **1 пробная отправка:** использована для проверки сообщений и статусов

## Контекст

В PIM-контуре fashion-ритейлера товарные данные уходят во внешний канал продаж. На стыке PIM, коннектора и внешней площадки были спорные места: какие идентификаторы считать основными, какие поля обязательны и где пользователю видеть статус обмена.
Работа была сосредоточена не на добавлении еще одного канала, а на выравнивании контракта данных и диагностики.

## Задача

Нужно было убрать неоднозначность в идентификаторах, не передавать лишние поля в потоках цен и остатков, а также сделать ошибки интеграции видимыми для бизнес-пользователей внутри PIM.
Отдельно требовалось проверить отправку сообщений на ограниченном наборе данных, чтобы не разносить ошибку на весь поток.

## Решение

Команда разнесла родительский и товарный идентификаторы, описала правила для цен и остатков и договорилась, какие статусы коннектор возвращает обратно в PIM.
Для спорных мест использовали пробную отправку: сначала проверяется ограниченное число сообщений, затем результат разбирается по данным и по техническому маршруту.

- Развели роли двух SKU-идентификаторов.
- Сократили набор обязательных полей для цен и остатков.
- Вернули статусы и ошибки в пользовательский PIM-сценарий.

## Результат

У команды появилась более понятная схема обмена: бизнес видит состояние товара, интеграционная команда понимает, где искать ошибку, а поток цен и остатков не перегружен лишними атрибутами.
Рабочий результат - подготовка интеграции к более стабильной эксплуатации без раскрытия внутренних деталей площадки и клиента.