Автоматизация возвратов: как связать заявку, логистику, склад и выплату
Покупатель передал товар курьеру, склад принял посылку, а поддержка всё ещё видит статус «ожидаем отправку». Бухгалтер не получает основания для возврата денег. Каждый участник выполнил свою часть работы, но между системами процесс остановился.
Автоматизация возвратов нужна не только для формы в личном кабинете. Она должна связать заявление покупателя, обратную доставку, проверку товара и возврат платежа. Для этого важно определить отдельные состояния, ответственных и действия при расхождениях.
Возврат товара и возврат денег — разные операции
Посылка может ещё находиться в пути, а денежный возврат уже быть согласован. Бывает и обратная ситуация: товар принят, но платёжная операция не завершена. Поэтому один статус «возвращён» не даёт достаточной информации ни покупателю, ни сотруднику.
В документации Shopify отдельно описаны return — получение товара обратно, refund — возврат денег и exchange — обмен на другую позицию. Для собственной системы полезно сохранить это разделение, даже если в интерфейсе все действия находятся в одной карточке.
У карточки возврата должен быть собственный номер и связь с исходным заказом, конкретными строками покупки и платежами. Заказ из нескольких товаров может породить несколько обращений. Если хранить только общий номер покупки, система не сможет надёжно отличить новую заявку от повторной попытки вернуть ту же позицию.
Заявка должна знать состав исходной покупки
Форму лучше строить вокруг уже выполненного заказа: покупатель выбирает позиции и количество, указывает причину и прикладывает сведения, необходимые для этого сценария. Сотруднику не придётся вручную сопоставлять свободное описание «синяя куртка» с артикулом, размером и фактически выданным товаром.
На стороне сервиса стоит проверять, сколько единиц было получено, сколько уже возвращено и какие заявки ещё открыты. Повторное нажатие кнопки должно возвращать существующую заявку, а не создавать вторую. Для двух разных обращений по одному товару понадобится проверка доступного к возврату количества.
Условия приёма, сроки, документы и основания для решения необходимо согласовать с ответственными за процесс и юридической службой. Техническая схема не должна подменять эти правила. Автоматические проверки следует строить на согласованных условиях, а спорные случаи направлять сотруднику.
Обратная доставка заканчивается приёмкой, а не трек-номером
После согласования возврата система может создать отправление у перевозчика или инструкцию для сдачи в магазин. В карточке нужно связать номер заявки с номером отправления. Для нескольких посылок по одному обращению — сохранить каждую связь отдельно.
Статус перевозчика «доставлено» стоит трактовать как логистическое событие. Он не подтверждает, что внутри нужный товар в заявленном количестве. Для склада требуется собственный этап: сотрудник идентифицирует посылку, сверяет содержимое и фиксирует результат приёмки.
Минимальный набор сведений для проверки — товар, вариант, количество, состояние и обнаруженные расхождения. Для техники может понадобиться серийный номер, для комплектов — состав. Эти поля следует выбирать по ассортименту, а не переносить одинаковую длинную анкету на любую покупку.
Неизвестную посылку, недостачу или чужой товар лучше отправлять в отдельную очередь разбора. У такой задачи должны быть ответственный, причина остановки и срок следующего действия. Иначе исключение останется в комментарии и выпадет из основного процесса.
Принятый товар не всегда готов к повторной продаже
Физическое поступление на склад и возвращение в доступный остаток стоит разделить. Проверяемая позиция может находиться в карантине, повреждённая — ожидать решения, исправная — вернуться в продажу. В Shopify для недоступного запаса предусмотрены, в частности, состояния повреждения и контроля качества.
В интеграции с WMS нужно определить, какое событие меняет каждое количество. Приёмка увеличивает физическое наличие в соответствующем состоянии. Подтверждение годности переносит товар в доступный запас. Повтор сообщения о приёмке не должен увеличивать ни одно из этих значений второй раз.
Историю перемещений важно связать с заявкой. Тогда по одному возврату будет видно, где находится вещь и почему её ещё нельзя заказать. Для комплекта результат проверки можно хранить по составляющим, если складская и товарная модели поддерживают такой учёт.
Как автоматизировать выплату без двойного возврата
В техническом смысле речь обычно идёт о возврате исходного платежа, а не о произвольной выплате на новые реквизиты. Например, ЮKassa возвращает деньги на использованное платёжное средство, а доступность частичного возврата зависит от способа оплаты.
Сумму следует рассчитывать по сохранённым условиям покупки, а не по сегодняшней цене каталога. Нужно учитывать возвращаемые строки, распределённую скидку, уже проведённые возвраты и согласованные правила обработки доставки и бонусов. Формулу важно хранить в одном месте, а результат перед отправкой — фиксировать в заявке.
Проверять нужно и сумму, и параллельные операции. Если два сотрудника одновременно согласуют разные возвраты одного платежа, каждый запрос по отдельности может выглядеть корректным. Поэтому внутренний контроль должен учитывать не только завершённые, но и уже запущенные денежные операции.
После сетевого тайм-аута нельзя сразу создавать новый возврат: сервис мог принять первый запрос, а ответ потерялся. В правилах API ЮKassa повтор с теми же данными и ключом идемпотентности распознаётся как повторный. Эта гарантия действует 24 часа, поэтому собственной системе нужен долговременный журнал денежных операций.
Стоит различать две ситуации. При неизвестном результате сначала выясняют судьбу исходной операции. Если сервис подтвердил отмену, причину устраняют и отдельно решают, допустима ли новая попытка. Бесконечное повторение одной команды не заменяет обработку ошибки.
Какие состояния показывать сотруднику и покупателю
Внутри карточки полезно разделить четыре группы состояний:
- Обращение: создано, рассматривается, согласовано или требует уточнения.
- Логистика: ожидает отправки, в пути, доставлено в точку приёмки.
- Товар: принят, проверяется, годен к продаже или требует отдельного решения.
- Деньги: сумма согласована, операция отправлена, подтверждена или завершилась ошибкой.
Это пример внутренней модели, а не единый словарь для всех сервисов. Покупателю можно показывать более короткое объяснение, но оно должно опираться на подтверждённое событие: «товар получен и проходит проверку» или «возврат платежа отправлен в обработку».
Для сотрудника рядом нужны история переходов и разрешённое действие. Склад подтверждает приёмку, уполномоченный сотрудник согласует сумму, финансовая система сообщает результат. Возможность читать карточку не должна автоматически давать право повторно отправлять денежную операцию.
С чего начать внедрение
Для первого релиза достаточно одного канала продаж, одного способа обратной доставки и одного платёжного сценария. Важно провести возврат целиком, включая исключения, а не подключить несколько сервисов без подтверждения конечного результата.
До запуска стоит проверить повторную заявку, частичный возврат, несовпадение содержимого посылки, недоступность перевозчика и потерю ответа платёжного сервиса. Отдельный тест — товар уже принят, а денежная операция завершилась ошибкой. Он не должен возвращать складскую часть процесса в исходное состояние.
Измерять результат лучше по времени между этапами: от заявки до решения, от доставки до проверки, от согласования суммы до подтверждения денежной операции. Также полезны доля ручных действий и количество обращений в поддержку по статусу возврата. Среднее время всего процесса без разбивки не покажет, где сохраняется задержка.
На странице e-commerce-разработки Qtim описаны интеграции с оплатой, складом и учётными системами. Обсудить автоматизацию конкретного сценария возврата можно в Telegram.
