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