Массовое изменение цен запускайте из зафиксированного и утверждённого набора, а не из таблицы, которую продолжают редактировать. Для каждой строки сохраните старое значение, новое значение и область магазина. До рабочего старта испытайте остановку на разрешённом тестовом наборе.
Остановка предотвращает следующие отправки, но не отменяет уже принятую площадкой цену. Поэтому возврат — отдельная операция со своими проверками. Он не должен затирать более свежие решения менеджера. Эта статья о контроле технического запуска, а не о выборе скидок или оценке коммерческой выгоды.
Что утверждает ответственный
- Конкретный список предложений и магазин, где меняется цена.
- Исходный снимок и правила допустимого изменения.
- Исключения, которые нельзя отправлять.
- Критерии остановки и сотрудника, принимающего решение.
После утверждения рассчитайте неизменяемый идентификатор набора или контрольную сумму его содержимого. Если входной файл изменился, это уже другой запуск и ему требуется новое согласование. Предварительный просмотр должен показывать добавленные, исключённые и неоднозначные строки отдельно. Пустое поле цены не является автоматически разрешённым нулём.
Части запуска имеют собственный итог
| Состояние части | Что делает исполнитель | Можно отправлять следующую? |
|---|---|---|
| Ещё не отправлена | Повторно проверить остановку и актуальность | По правилам запуска |
| Подтверждённо принята | Сохранить результат и проверить чтением | Если проверка пройдена |
| Подтверждённо отклонена | Записать причину и остановить либо исключить | Только по согласованной политике |
| Исход неизвестен | Выяснить состояние без слепого повтора | Нет, пока не решён риск |
Для конкретного метода установки цен магазина Яндекс Маркет описывает принятие информации и отложенное обновление каталога. Его применимость зависит от настройки отдельных цен. Документация проверена 11 октября 2026 года. Размеры частей и темп выбирайте по актуальным ограничениям используемого метода; универсальный размер пакета для всех площадок здесь не предлагается.
Модель журнала запуска:
run_id: <согласованный запуск>
item_key: <предложение + магазин>
before: <снимок>
after: <утверждённая цена>
state: prepared / sent / verified / failed / unknown
Это внутренние поля, не параметры API площадки.Перед отправкой следующей части проверьте флаг остановки и текущее право исполнителя. Сохраняйте фактический результат каждой части, а не один общий процент успеха. Ошибка доступа, неоднозначное соответствие и временный отказ требуют разных решений. Без такого журнала после аварии невозможно понять, какие цены уже применились.
Возврат сравнивает нынешнюю цену с нашей правкой
Условный пример: запуск сменил цену A на B, затем менеджер утвердил C. Возврат к A теперь затрёт решение менеджера. Кандидатом на возврат является только строка, где подтверждено применение B и текущее состояние всё ещё соответствует этой правке. Если оно другое, создайте конфликт для ручного решения.
Даже чтение B перед записью A не закрывает гонку: между этими действиями может появиться C. Если площадка не поддерживает условную запись по версии, нужна согласованная координация авторов или ручное разрешение конфликтных строк. Не обещайте атомарный откат всего каталога при последовательных внешних запросах. Возврат тоже проверяется повторным чтением.
Репетиция остановки важнее быстрого полного прохода
- Запустить малый тестовый набор с известным исходным состоянием.
- Остановить после подтверждённой части: остальные не отправляются.
- Возобновить тот же запуск без повторного изменения проверенных строк.
- Изменить одну строку другим разрешённым способом.
- Подготовить возврат: изменённая другим автором строка выделена как конфликт.
Перед разработкой такой операции соберите правила утверждения, источники цен и пример конфликтного возврата. Надёжный запуск оставляет проверенный результат по каждой позиции и понятную границу остановки. Скорость обработки имеет смысл только после того, как эти границы работают.