Руководитель интернет-магазина видит одно обращение клиента, но внутри него проходят три разных процесса: регистрация запроса, движение товара и возврат денег. Если свести их к одному статусу «возврат оформлен», система может преждевременно изменить остаток, сообщить о несуществующей выплате или повторно отправить денежную команду.
Автоматизация возвратов товара должна связывать события, не смешивая их. Заявление открывает процесс. Обратная доставка показывает движение отправления. Приёмка подтверждает фактически полученное количество и состояние. Refund фиксирует отдельную денежную операцию.
Какую задачу решает этот процесс
Представим ситуацию руководителя интернет-магазина: покупатель заказал несколько товаров и хочет вернуть один. Сотрудник принял заявление, перевозчик создал номер отправления, склад ещё ничего не получил, а деньги пока не возвращены. Руководителю нужно видеть реальное состояние каждого этапа, а не общий оптимистичный статус.
Целевой результат — возврат проходит от обращения до фактического товарного и денежного события. Для этого процесс хранит три связанные, но независимые сущности:
- Обращение фиксирует, что покупатель запросил возврат конкретной строки заказа и количества.
- Товар проходит разрешение на возврат, обратную доставку и приёмку.
- Деньги проходят согласование суммы и отдельную операцию refund с подтверждением платёжного провайдера.
Граница процесса тоже важна. Рекламация оценивает претензию и основания для решения. Бот статуса только сообщает уже записанное состояние; он не определяет право на возврат и не заменяет решение специалиста. Подробнее о такой информационной роли диалога — в материале про бота статуса заказа.
Какие данные и правила подготовить
До настройки автоматизации определите источник каждого поля, ответственного за него и момент, когда значение становится известным. Обязательные поля нужны для регистрации запроса. Условные появляются только на соответствующем этапе. Неизвестное нельзя заменять догадкой.
Ниже — короткий синтетический образец. Все идентификаторы, названия, количества и статусы условны и не относятся к клиенту Switch On AI.
| Поле и условное значение | Источник | Ответственный | Требование |
|---|---|---|---|
order_id = ORD-1007 | Система заказов | Владелец процесса продаж | Обязательное |
order_line_id = LINE-02 | Система заказов | Владелец процесса продаж | Обязательное |
ordered_qty = 1 | Строка заказа | Владелец процесса продаж | Обязательное |
return_qty = 1 | Заявление с проверкой по строке | Оператор поддержки | Обязательное |
reason = не подошёл размер | Заявление покупателя | Оператор поддержки | Обязательное для процесса, но не юридическая оценка |
return_authorization = RMA-204 | Процесс возврата | Ответственный за возвраты | Условное: после разрешения |
tracking_id = TRK-8801 | Данные перевозчика | Логист | Условное: после оформления доставки |
inspection_result = принят, комплектность подтверждена | Складская приёмка | Сотрудник склада | Неизвестное до получения товара |
refund_id | Платёжный провайдер | Финансовый ответственный | Неизвестное до создания операции |
Если таблица не помещается, прокрутите её вправо. С клавиатуры используйте стрелки.
Отдельно согласуйте справочники причин, допустимые переходы статусов, правило расчёта суммы и действия при расхождении. Юридические сроки и обязанности должен задать специалист заказчика на основании применимых норм и условий продажи — автоматизация не выводит их из причины обращения.
Как зарегистрировать возврат по конкретному товару
Заявление нужно связать не только с номером заказа, но и с конкретной строкой. Иначе частичный возврат может закрыть весь заказ или затронуть другой товар.
Для строки полезно хранить заказанное количество, ранее подтверждённые возвраты и новое запрошенное количество. Базовая проверка выглядит так:
return_qty ≤ ordered_qty − returned_qty_before
В синтетическом примере для LINE-02: ordered_qty = 1, returned_qty_before = 0, return_qty = 1. Подстановка даёт 1 ≤ 1 − 0, поэтому количество допустимо. Для двух остальных строк условного заказа return_qty = 0. Возвращается одна из трёх товарных единиц, а заказ целиком не закрывается.
После проверки система может зарегистрировать заявление и присвоить ему RMA — идентификатор разрешения или заказа на возврат. Официальная документация Microsoft Dynamics 365 Supply Chain Management описывает RMA как опорный идентификатор процесса и связывает строку возврата со строкой исходного заказа. Там же разделены физический возврат и операция без физического возврата. Это пример документированной модели конкретной платформы, а не подтверждение её использования или совместимости с магазином читателя.
Регистрация RMA организует работу, но не доказывает право покупателя на возврат. Такое решение принимает уполномоченный специалист заказчика по установленным правилам.
Как пройти путь от обратной доставки до приёмки
События движения товара должны идти последовательно:
- Создано разрешение
RMA-204. - Зарегистрирован номер отправления
TRK-8801. - Отправление передано перевозчику.
- Товар фактически получен складом.
- Склад проверил количество, комплектность и состояние.
Созданная накладная означает только подготовку обратной доставки. Даже переданное перевозчику отправление остаётся товаром «в пути», а не «принято». Результат приёмки появляется после фактического получения и проверки.
Если склад обнаружил недостачу или расхождение состояния, интеграция создаёт отдельную задачу ответственному и сохраняет исходные данные проверки. Она не должна принимать решение только по статусу накладной. Дальнейшее действие — принять товар, отклонить его, вернуть покупателю или применить другой согласованный вариант — определяет специалист заказчика.
Момент изменения учётного остатка тоже задаётся правилами используемой системы. Статус «принят» сам по себе не позволяет утверждать, что остаток уже увеличен.
Как подтвердить возврат денег
Перед денежной операцией финансовый ответственный или согласованное правило подтверждает количество, сумму и метод возврата. Система сохраняет основание расчёта, идентификатор операции и финальный статус провайдера.
Для защиты от повтора денежной команде нужен стабильный ключ, составленный из данных процесса. В синтетическом примере это ORD-1007:LINE-02:RMA-204. Повторное обращение с тем же ключом не должно создавать новый refund.
Если провайдер принял операцию, процесс сохраняет refund_id и ожидает финального состояния. Полученный статус succeeded подтверждает завершение именно этой операции. Если провайдер отвечает отказом или не возвращает финальный статус, автоматизация создаёт отдельную задачу финансовому ответственному. Она не запускает бесконтрольный новый возврат денег.
Повтор webhook тоже обрабатывается идемпотентно: уже известное событие обновляет или подтверждает сохранённое состояние, но не создаёт вторую денежную операцию.
Учебный пример: путь от входных данных до результата
Ниже — полностью синтетический учебный пример, а не клиентский кейс, файл проверки или результат внедрения Switch On AI. Все названия, идентификаторы, суммы, количества и статусы условны.
В ORD-1007 находятся три товарные единицы в трёх строках. Покупатель возвращает только LINE-02: одна заказанная единица, ранее подтверждённых возвратов нет, запрошена одна единица. Остальные две строки не меняются.
Условная цена LINE-02 — 2400 ₽. Склад принял одну единицу, согласованная корректировка — 0 ₽. Поэтому учебный расчёт воспроизводится так:
refund_amount = unit_price × accepted_qty − agreed_adjustment
2400 × 1 − 0 = 2400 ₽
В расчёт не входят два других товара. Возврат стоимости доставки не предполагается: для него понадобилось бы отдельное правило заказчика.
| Этап | Документ или событие | Ответственный | Статус товара | Статус денег |
|---|---|---|---|---|
| Заявление | Условный запрос по LINE-02, return_qty = 1 | Оператор | У покупателя | Не начат |
| Разрешение | Условный RMA-204 | Ответственный за возвраты | Ожидает отправки | Не начат |
| Обратная доставка | Условный TRK-8801 | Логист | В пути | Не начат |
| Приёмка | Условный accepted_qty = 1 | Сотрудник склада | Принят | Сумма подтверждена: 2400 ₽ |
| Refund | Условный RF-501 | Финансовый ответственный и провайдер | Принят | succeeded |
| Повтор webhook | Условный EV-900 получен повторно | Интеграция | Без изменения | succeeded, новая операция не создана |
Если таблица не помещается, прокрутите её вправо. С клавиатуры используйте стрелки.
Первый webhook EV-900 переводит RF-501 в succeeded. Повтор того же EV-900 только подтверждает сохранённый статус. Итог учебного сценария: принят один товар, создана одна операция на 2400 ₽, refund_count = 1.
Главный вывод: принятие заявления ещё не меняет остаток и не означает выплату. Эти результаты появляются только после соответствующих товарных и денежных событий.
Как проверить результат перед запуском
Проверка должна отдельно наблюдать обращение, товар и деньги. Частичный возврат не закрывает весь заказ, а сроки и обязанности не задаются без решения специалиста и применимого юридического основания.
| Сценарий | Ожидаемый результат | Сигнал ошибки | Действие человека |
|---|---|---|---|
| Нормальный путь | Условные accepted_qty = 1, refund_amount = 2400 ₽, refund_count = 1; две остальные строки заказа не изменены | Нет refund_id или финального статуса | Финансовый ответственный сверяет операцию у провайдера и фиксирует решение |
| Недостача или товар не принят | accepted_qty = 0, автоматический refund не создаётся | return_qty не совпадает с accepted_qty | Ответственный изучает результат приёмки и выбирает дальнейшее действие |
| Повтор события | Сохраняется один RF-501, новая выплата не создаётся | refund_count стал больше 1 | Интеграцию останавливают для этой операции, финансовый ответственный сверяет платежи |
| Отказ провайдера | Статус отказа сохранён, создана отдельная задача | Процесс показывает успех без финального подтверждения | Финансовый ответственный выясняет причину и отдельно разрешает следующее действие |
Если таблица не помещается, прокрутите её вправо. С клавиатуры используйте стрелки.
Перед запуском также проверьте, что система не называет созданную накладную приёмкой, не меняет статус всех строк заказа из-за одной возвращённой позиции и не сообщает покупателю о выплате до финального статуса провайдера.
Что согласовать для внедрения
Готовый инструмент может хранить заказы, RMA, складские события или платежи, но наличие таких сущностей не доказывает, что они уже связаны в нужной последовательности. До разработки нужно проверить конкретную версию системы, API, права доступа, доступные события и правила повторной обработки. Совместимость и тарифы подтверждаются отдельно.
Собственная интеграция может связывать строку заказа, обратную доставку, приёмку и refund, вести независимые статусы и передавать исключения человеку. ИИ-помощник уместен там, где нужно разобрать неструктурированное обращение и подготовить данные для проверки. Бот может принять заявление или показать сохранённый статус. Детерминированная интеграция выполняет согласованные проверки и обмен данными. Эти форматы не взаимозаменяемы.
Switch On AI разрабатывает ИИ-помощника, бота или интеграцию для описанной операции после проверки данных и API. Цель такого проекта — провести возврат от обращения до фактического товарного и денежного события, сохранив решения специалистов на предусмотренных этапах. Правила юридического, бухгалтерского и отраслевого учёта задаёт и проверяет специалист заказчика.
Следующий шаг — разобрать одну операцию возврата и согласовать прототип без замены учётной системы. Для разговора достаточно условного примера заказа, перечня систем и правил, по которым сотрудники сейчас принимают товар и подтверждают сумму. Прототип проверяет согласованный фрагмент сценария и не равен полноценному внедрению; состав, сроки и ожидаемый эффект без изучения процесса не определяются.
Вопросы по этой задаче
Чем возврат отличается от претензии?
Претензия требует оценки обстоятельств и решения уполномоченного специалиста. Процесс возврата организует связанный товарный и денежный поток после такого решения: заявление, обратную доставку, приёмку и refund. Бот статуса может сообщить записанное состояние, но не оценивает претензию.
Как учесть частичный возврат?
Заявление связывают с конкретной строкой заказа и количеством. Проверяют, что новое количество не превышает заказанное за вычетом уже подтверждённых возвратов. Остальные строки сохраняют свои статусы, поэтому возврат одной позиции не закрывает весь заказ.
Почему заявление не означает возврат денег?
Заявление только запускает процесс. Оно не подтверждает передачу товара перевозчику, складскую приёмку или денежную операцию. Выплату подтверждают отдельные данные: согласованная сумма, refund_id и финальный статус платёжного провайдера.