Обмен нельзя моделировать простым удалением старой позиции и созданием новой. Исходная продажа уже связана с оплатой, доставкой, чеками, скидкой и складскими движениями. Если система перезаписывает заказ, поддержка и бухгалтерия теряют доказуемую историю, а повторная синхронизация может создать неверные списания или отправления.

Остановите массовое переоформление и возьмите один проблемный обмен. Восстановите граф связей: исходный заказ, возвращаемая позиция, платеж, возврат или доплата, обратная доставка, новая отгрузка и кассовые документы. История должна дополняться новыми событиями, а не заменяться.

Что проверить в первую очередь

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

  • Проверьте, удаляется ли исходная позиция физически или только меняет состояние.
  • Сопоставьте платежные transaction ID и суммы возврата или доплаты.
  • Найдите обе доставки и их внешние трек-номера.
  • Проверьте складские движения возврата и резерв новой позиции.
  • Убедитесь, что скидка, налог и чек связаны с исходной операцией и корректировками.

Почему возникает проблема

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

  • Обмен реализован как редактирование существующего заказа без неизменяемой истории.
  • Новый заказ создается, но parent_order_id или exchange_case_id не сохраняется.
  • Связи оплаты и доставки зависят только от текущей позиции, которую удаляют.
  • Внешний API возвращает новый идентификатор, а локальная таблица перезаписывает старый.
  • Компенсирующие операции выполняются вне общей транзакции и частично теряются.

Пошаговая диагностика

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

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

Модель обмена как связанного набора операций

Обмен удобнее хранить отдельным кейсом, который объединяет неизменяемую исходную продажу и новые компенсирующие действия.

  • Исходный заказ и позиции остаются доступными для аудита.
  • Exchange case содержит причину, автора, возвращаемые и выдаваемые позиции.
  • Возврат, доплата и новая доставка имеют собственные идентификаторы и статусы.
  • Все сущности связаны с исходным заказом и кейсом обмена.
  • Интерфейс собирает единую временную шкалу без перезаписи исторических фактов.

Как исправить проблему

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

  • Запретите физическое удаление оплаченных позиций и замените его переходом состояния.
  • Добавьте exchange_case и явные ссылки old_item_id, new_item_id и source_order_id.
  • Храните платежные и логистические операции отдельными append-only записями.
  • Используйте outbox для надежной отправки возврата, резерва и новой доставки.
  • Для поврежденной истории подготовьте миграцию, которая сначала строит отчет предполагаемых связей и не создает финансовых операций автоматически.

Безопасный порядок внедрения

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

Как проверить результат

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

  • Из карточки обмена доступны исходная оплата, возврат или доплата и обе доставки.
  • Повтор команды после таймаута не создает второй возврат или отправление.
  • Отмена обмена корректно освобождает резерв и сохраняет журнал.
  • Бухгалтерская и складская сверка видит все операции без заднего редактирования.
  • Пользовательский статус понятен, но не скрывает исходные документы от поддержки.

Типичные ошибки при исправлении

  • Клонировать заказ без связи с оригиналом.
  • Переносить transaction ID на новый заказ и терять контекст исходного списания.
  • Менять сумму оплаченного заказа вместо создания возврата или доплаты.
  • Удалять старую доставку после формирования новой.
  • Пытаться автоматически восстановить финансовые связи только по совпадению суммы и даты.

Как предотвратить повторение

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

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

Что контролировать после выпуска

  • Количество успешных и ошибочных операций в разрезе версии, канала и типа сценария.
  • Возраст необработанных записей, длину очередей, число повторных попыток и долю окончательных отказов.
  • Расхождение между пользовательским статусом и фактическим состоянием в базе или внешней системе.
  • Появление новых кодов ошибок после релиза и изменение времени выполнения ключевой операции.
  • Сигналы от поддержки и бизнес-метрики, которые могут показать скрытый частичный сбой.

Что подготовить для технического разбора

  • Описание ожидаемого и фактического поведения с точной последовательностью действий.
  • Время проблемы, идентификатор тестового объекта и версии затронутых компонентов.
  • Фрагменты журналов до и после ошибки без секретов и персональных данных.
  • Перечень последних изменений и уже выполненных проверок.
  • Безопасный доступ к тестовой среде либо способ воспроизвести сбой без влияния на клиентов.

Частые вопросы

Нужно ли создавать новый заказ при обмене?

Это зависит от учета, но даже новый заказ должен явно ссылаться на исходный и общий кейс обмена.

Можно ли редактировать старую позицию?

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

Как восстановить уже потерянные связи?

По журналам API, платежным идентификаторам и доставкам можно построить кандидатов, однако каждую финансовую связь нужно подтверждать перед записью.

Когда нужна помощь специалиста

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