Ozon 22 октября предупредил разработчиков о конфликте интеграций при переходе к единой предельной цене. Если одна программа поддерживает значение в разделе цен, а другая отдельно управляет акциями, они могут постоянно перезаписывать результат друг друга. Продавец увидит меняющуюся сумму, хотя каждый отдельный запрос будет выглядеть корректным. Поэтому проверять нужно всю цепочку записи, а не только последний ответ API.

Как возникает повторное снижение

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

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

Составьте карту всех записывающих систем

Начните с одного товара, у которого изменение воспроизводится. Запишите артикул, время наблюдения, ожидаемое значение и фактическую последовательность сумм. Затем перечислите учётную систему, сервис управления рекламой, автоматические задания, таблицы загрузки и сотрудников, которые могут менять цены вручную. Чтение данных не равно записи: аналитический отчёт сам по себе не объясняет изменение поля.

Попросите разработчика сопоставить наблюдения с журналом исходящих запросов. Для диагностики нужны название процесса, назначение операции и переданное значение. Секреты и полные токены в такой журнал включать нельзя. Если доступно только сообщение «запрос выполнен», этого недостаточно для установления, какая система перезаписала цену и почему она выбрала именно такую сумму.

Отделите исходную базу от результата расчёта

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

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

Примите исправление на контрольных товарах

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

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