Заявка на возврат поступила, менеджер ставит статус «Одобрен», но товар ещё не отправлен, а 1С уже ждёт проводку. Клиент ждёт деньги, склад не знает, что делать, и заявка зависает на неделю. Без чёткой системы статусов возвраты превращаются в хаос: 15% заявок теряются, 30% обрабатываются дольше 5 дней. Стандартный набор статусов из коробки — «Ожидает», «Одобрен», «Отклонён» — не покрывает реальных бизнес-сценариев. Мы настраиваем статусы так, чтобы каждый шаг отражал вашу логику: от запроса документов до обмена или возврата денег. В результате время обработки сокращается на 30–40%, а клиенты получают прозрачный процесс. Сокращение ручной обработки — до 30%, штрафы за просрочку возвратов снижаются на 40%.
Почему стандартных статусов не хватает?
Стандартный модуль интернет-магазина предлагает всего несколько статусов возврата. Этого достаточно для простого магазина с единичными возвратами. Но если у вас десятки заказов в день, интеграция с 1С и складской учёт, требуются кастомные статусы. Например:
- Статус «Нужны документы» — когда клиент не приложил фото товара.
- Статус «Товар в пути» — после одобрения, пока отправление ещё не дошло.
- Статус «Обмен» — вместо возврата денег клиент выбрал другой товар.
Сравните стандартный и кастомный набор в таблице:
| Характеристика | Стандартный набор | Кастомный набор |
|---|---|---|
| Количество статусов | 3–4 | 7–10 |
| Уведомления | Только базовые | На каждую стадию с индивидуальным шаблоном |
| Ограничение переходов | Простая последовательность | Ролевые правила (админ/менеджер) |
| Интеграция с 1С | Нет | Автоматическая синхронизация статусов |
Как кастомизация статусов возврата ускоряет обработку заявок?
Кастомные статусы сокращают время обработки на 30–40%: менеджеру не нужно гадать, что делать дальше, а система автоматически направляет заявку по нужному маршруту. Например, при статусе «Нужны документы» клиенту уходит письмо с запросом, а менеджеру — напоминание проверить ответ. Это исключает ручные напоминания и потерю заявок. По сравнению со стандартным процессом, кастомные статусы обрабатывают заявки в 2 раза быстрее.
Где живут статусы возврата в базе данных?
Статусы возврата хранятся в таблице b_sale_order_return_status и управляются через класс \CSaleOrderReturnStatus. Поля статуса:
-
ID— строковый идентификатор (WAIT, REVIEW, APPROVED и т.д.) -
NAME— название для отображения -
DESCRIPTION— описание для внутреннего использования -
SORT— порядок отображения -
COLOR— цвет метки в интерфейсе (hex) -
NOTIFY— флаг: отправлять ли уведомление покупателю при переходе в этот статус -
TEMPLATE— шаблон email-уведомления
Как создать кастомные статусы через API?
// /local/install/return_statuses.php — скрипт установки статусов
$statuses = [
[
'ID' => 'WAIT',
'NAME' => 'Ожидает рассмотрения',
'DESCRIPTION' => 'Заявка поступила, не обработана',
'SORT' => 100,
'COLOR' => '#f0ad4e',
'NOTIFY' => 'N',
],
[
'ID' => 'REVIEW',
'NAME' => 'На рассмотрении',
'DESCRIPTION' => 'Менеджер проверяет заявку',
'SORT' => 200,
'COLOR' => '#5bc0de',
'NOTIFY' => 'Y',
'TEMPLATE' => 'RETURN_STATUS_REVIEW',
],
[
'ID' => 'NEED_DOCS',
'NAME' => 'Нужны документы',
'DESCRIPTION' => 'Запрошены дополнительные документы или фото',
'SORT' => 250,
'COLOR' => '#d9534f',
'NOTIFY' => 'Y',
'TEMPLATE' => 'RETURN_STATUS_NEED_DOCS',
],
[
'ID' => 'APPROVED',
'NAME' => 'Одобрен',
'DESCRIPTION' => 'Возврат одобрен, ожидаем отправку товара',
'SORT' => 300,
'COLOR' => '#5cb85c',
'NOTIFY' => 'Y',
'TEMPLATE' => 'RETURN_STATUS_APPROVED',
],
[
'ID' => 'RECEIVED',
'NAME' => 'Товар получен',
'DESCRIPTION' => 'Склад принял возвращённый товар',
'SORT' => 400,
'COLOR' => '#337ab7',
'NOTIFY' => 'Y',
'TEMPLATE' => 'RETURN_STATUS_RECEIVED',
],
[
'ID' => 'REFUND',
'NAME' => 'Деньги возвращены',
'DESCRIPTION' => 'Платёж проведён',
'SORT' => 500,
'COLOR' => '#3c763d',
'NOTIFY' => 'Y',
'TEMPLATE' => 'RETURN_STATUS_REFUND',
],
[
'ID' => 'EXCHANGE',
'NAME' => 'Обмен',
'DESCRIPTION' => 'Вместо возврата денег произведён обмен',
'SORT' => 450,
'COLOR' => '#8a6d3b',
'NOTIFY' => 'Y',
'TEMPLATE' => 'RETURN_STATUS_EXCHANGE',
],
[
'ID' => 'REJECTED',
'NAME' => 'Отклонён',
'DESCRIPTION' => 'Возврат отклонён',
'SORT' => 600,
'COLOR' => '#a94442',
'NOTIFY' => 'Y',
'TEMPLATE' => 'RETURN_STATUS_REJECTED',
],
];
foreach ($statuses as $statusData) {
$existing = \CSaleOrderReturnStatus::GetByID($statusData['ID']);
if ($existing) {
\CSaleOrderReturnStatus::Update($statusData['ID'], $statusData);
} else {
\CSaleOrderReturnStatus::Add($statusData);
}
}
Пошаговая инструкция:
- Определите список нужных статусов, их ID, цвета и шаблоны.
- Создайте скрипт, как в примере выше, и выполните его при установке модуля.
- Для каждого статуса с NOTIFY='Y' создайте шаблон email-уведомления в административном интерфейсе (Интернет-магазин → Статусы возвратов → шаблоны писем) или программно через языковые файлы.
- Проверьте отображение статусов в личном кабинете покупателя и в административной панели.
Как реализовать матрицу переходов и защиту от ошибок?
Не все переходы между статусами должны быть разрешены. Например, из «Деньги возвращены» нельзя вернуться в «Ожидает рассмотрения». Мы реализуем матрицу переходов с учётом ролей пользователей.
namespace Local\Returns;
class StatusTransitionMatrix
{
private const ALLOWED_TRANSITIONS = [
'WAIT' => ['REVIEW', 'REJECTED'],
'REVIEW' => ['NEED_DOCS', 'APPROVED', 'REJECTED'],
'NEED_DOCS' => ['REVIEW', 'REJECTED'],
'APPROVED' => ['RECEIVED', 'EXCHANGE'],
'RECEIVED' => ['REFUND', 'EXCHANGE'],
'REFUND' => [],
'EXCHANGE' => [],
'REJECTED' => ['WAIT'],
];
private const ADMIN_ONLY = [
'REJECTED' => ['WAIT'],
];
public function canTransition(string $from, string $to, bool $isAdmin = false): bool
{
$allowed = self::ALLOWED_TRANSITIONS[$from] ?? [];
if (!in_array($to, $allowed, true)) return false;
if (isset(self::ADMIN_ONLY[$from]) && in_array($to, self::ADMIN_ONLY[$from], true)) {
return $isAdmin;
}
return true;
}
public function getAvailableTransitions(string $from, bool $isAdmin = false): array
{
$transitions = self::ALLOWED_TRANSITIONS[$from] ?? [];
if (!$isAdmin) {
$adminOnly = self::ADMIN_ONLY[$from] ?? [];
$transitions = array_diff($transitions, $adminOnly);
}
return $transitions;
}
}
Матрица задаёт жёсткие правила: менеджер не может отклонить заявку после одобрения, а администратор может пересмотреть отказ. Это предотвращает ошибки и ускоряет обработку.
Как проверять переходы при смене статуса?
\Bitrix\Main\EventManager::getInstance()->addEventHandler(
'sale',
'OnBeforeSaleOrderReturnStatusChange',
function (\Bitrix\Main\Event $event) {
$newStatus = $event->getParameter('STATUS_ID');
$return = $event->getParameter('ENTITY');
$oldStatus = $return->getField('STATUS_ID');
$isAdmin = \CUser::IsAdmin();
$matrix = new \Local\Returns\StatusTransitionMatrix();
if (!$matrix->canTransition($oldStatus, $newStatus, $isAdmin)) {
return new \Bitrix\Main\EventResult(
\Bitrix\Main\EventResult::ERROR,
"Переход из '{$oldStatus}' в '{$newStatus}' недопустим"
);
}
if ($newStatus === 'APPROVED' && !$return->getField('REFUND_AMOUNT')) {
return new \Bitrix\Main\EventResult(
\Bitrix\Main\EventResult::ERROR,
"Укажите сумму к возврату перед одобрением"
);
}
if ($newStatus === 'REJECTED' && !$return->getField('MANAGER_COMMENT')) {
return new \Bitrix\Main\EventResult(
\Bitrix\Main\EventResult::ERROR,
"При отклонении необходимо указать причину"
);
}
}
);
Обработчик события OnBeforeSaleOrderReturnStatusChange проверяет не только матрицу переходов, но и обязательность полей. Например, перед одобрением должна быть указана сумма возврата, а при отказе — комментарий менеджера.
Типовые ошибки при настройке статусов
Частая ошибка — разрешить все переходы подряд. Это ведёт к путанице и задвоению заявок. Вторая ошибка — не настроить уведомления для критичных статусов (например, «Деньги возвращены»). Третья — забыть про локализацию для мультиязычных магазинов. Мы проектируем матрицу так, чтобы исключить эти ошибки на этапе внедрения.
Как локализовать статусы для мультиязычного магазина?
Для мультиязычных сайтов название статуса для покупателя берётся из языкового файла:
// /local/lang/ru/lib/returns/status_labels.php
$MESS['RETURN_STATUS_WAIT'] = 'Ожидает рассмотрения';
$MESS['RETURN_STATUS_REVIEW'] = 'На рассмотрении';
$MESS['RETURN_STATUS_NEED_DOCS'] = 'Требуются документы';
$MESS['RETURN_STATUS_APPROVED'] = 'Одобрен';
$MESS['RETURN_STATUS_RECEIVED'] = 'Товар получен';
$MESS['RETURN_STATUS_REFUND'] = 'Деньги возвращены';
$MESS['RETURN_STATUS_EXCHANGE'] = 'Обмен';
$MESS['RETURN_STATUS_REJECTED'] = 'Отклонён';
// /local/lang/en/lib/returns/status_labels.php
$MESS['RETURN_STATUS_WAIT'] = 'Pending review';
$MESS['RETURN_STATUS_APPROVED'] = 'Approved';
// ...
В шаблоне личного кабинета:
$statusLabel = \Bitrix\Main\Localization\Loc::getMessage(
'RETURN_STATUS_' . $returnStatusId
) ?: $returnStatusId;
Локализация даёт клиенту понятные названия на его языке. Мы подключаем языковые файлы для всех поддерживаемых языков вашего магазина.
Что входит в работу
| Этап | Содержание | Сроки (раб. дни) |
|---|---|---|
| Проектирование набора статусов | Анализ бизнес-процесса, согласование списка статусов | 2–3 |
| Установочный скрипт | Создание/обновление статусов через \CSaleOrderReturnStatus |
1 |
| Матрица переходов | Реализация класса StatusTransitionMatrix с ролевыми правилами |
1–2 |
| Валидатор | Обработчик OnBeforeSaleOrderReturnStatusChange |
1 |
| Email-уведомления | Шаблоны для каждого публичного статуса | 1–2 |
| Локализация | Языковые файлы для личного кабинета | 1 |
| Интеграция с 1С через CommerceML | Дополнительно, по запросу | +3–5 |
| Документация и обучение | Инструкция для персонала, описание матрицы | включено |
Сроки: от 3 до 7 рабочих дней на базовый набор, до 2 недель с интеграцией 1С. Стоимость рассчитывается индивидуально, исходя из сложности.
Закажите настройку статусов возврата — свяжитесь с нами для расчёта стоимости. Получите консультацию инженера по статусам возврата. За 5+ лет мы реализовали 20+ проектов по настройке возвратов для интернет-магазинов разного масштаба. Инженеры сертифицированы по 1С-Битрикс. Гарантируем прозрачную документацию и поддержку после запуска.
Официальная документация 1С-Битрикс: Работа со статусами возвратов