Возврат денег и обмен товара начинаются с обращения клиента, но создают разные финансовые и складские последствия. Если система хранит один статус return, отчёты, остатки и платежи быстро расходятся.

Не добавляйте ещё один флаг в существующую запись. Опишите два процесса, их документы и допустимые переходы, затем выделите общий объект обращения и отдельные операции refund и exchange.

Что сделать в первую очередь

  • Составьте примеры полного возврата, частичного возврата и обмена.
  • Сверьте текущие статусы с платежами и складом.
  • Найдите места, где return автоматически означает возврат денег.
  • Остановите автоматические действия для неоднозначных заявок.

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

Проблема появляется, когда бизнес-событие клиента смешано с бухгалтерской и складской операцией.

  • Один enum описывает причину и результат.
  • Обмен оформляется как возврат плюс ручная продажа.
  • Частичный возврат не связан с позициями заказа.
  • Складское поступление автоматически запускает refund.
  • Webhook платежа повторно меняет общий статус.

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

  • Постройте state diagram обоих процессов.
  • Сопоставьте каждую позицию с движением товара и денег.
  • Проверьте повтор webhook и отмену операции.
  • Разберите обмен с доплатой и возвратом разницы.
  • Сравните отчёт продаж с фактическими платежами.

Как исправить

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

  • Создайте return_request с типом refund или exchange.
  • Храните позиции и количество отдельно.
  • Создавайте refund только после утверждённого перехода.
  • Оформляйте замену как связанную операцию с новым товаром.
  • Добавьте журнал переходов и идемпотентные внешние платежи.

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

  • Возврат и обмен дают разные документы и отчёты.
  • Частичная операция затрагивает только выбранные позиции.
  • Повтор webhook не создаёт вторую выплату.
  • Склад и платежи сходятся после всех сценариев.

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

  • Зафиксируйте state machine в документации.
  • Покройте тестами обмен с доплатой и частичный refund.
  • Не разрешайте ручной переход в невозможный статус.
  • Проводите регулярную сверку платежей и заказов.

Чего не стоит делать

  • Не исправляйте отчёт, оставляя неверную модель.
  • Не привязывайте возврат денег только к приходу товара на склад.
  • Не удаляйте историю изменённых операций.

Что подготовить для диагностики

  • Текущая схема статусов.
  • Примеры проблемных заказов без персональных данных.
  • Правила склада и оплаты.
  • Список интеграций с CRM, кассой и платёжным сервисом.

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

Можно ли оформить обмен как два заказа?

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

Когда запускать возврат денег?

В момент, определённый правилами бизнеса, но только после проверенного перехода и с идемпотентной операцией провайдера.

Когда стоит обратиться за помощью

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

Итог

Разделение возврата и обмена делает отчёты и автоматизацию предсказуемыми. Я могу спроектировать статусы, миграцию данных и интеграции со складом и платежами.