Заявка на повернення надійшла, менеджер ставить статус «Схвалено», але товар ще не відправлено, а 1С уже чекає проведення. Клієнт чекає гроші, склад не знає, що робити, і заявка зависає на тиждень. Без чіткої системи статусів повернення перетворюються на хаос: 15% заявок губляться, 30% обробляються довше 5 днів. Стандартний набір статусів з коробки — «Очікує», «Схвалено», «Відхилено» — не покриває реальних бізнес-сценаріїв. Ми налаштовуємо статуси так, щоб кожен крок відображав вашу логіку: від запиту документів до обміну або повернення грошей. У результаті час обробки скорочується на 30–40%, а клієнти отримують прозорий процес. Скорочення ручної обробки — до 30%, штрафи за прострочення повернень знижуються на 40%.
Чому стандартних статусів не вистачає?
Стандартний модуль інтернет-магазину пропонує лише кілька статусів повернення. Цього достатньо для простого магазину з поодинокими поверненнями. Але якщо у вас десятки замовлень на день, інтеграція з 1С і складський облік, потрібні кастомні статуси. Наприклад:
- Статус «Потрібні документи» — коли клієнт не додав фото товару.
- Статус «Товар в дорозі» — після схвалення, поки відправлення ще не дійшло.
- Статус «Обмін» — замість повернення грошей клієнт обрав інший товар.
Порівняйте стандартний і кастомний набір у таблиці:
| Характеристика | Стандартний набір | Кастомний набір |
|---|---|---|
| Кількість статусів | 3–4 | 7–10 |
| Сповіщення | Тільки базові | На кожну стадію з індивідуальним шаблоном |
| Обмеження переходів | Проста послідовність | Рольові правила (адмін/менеджер) |
| Інтеграція з 1С | Ні | Автоматична синхронізація статусів |
Як кастомізація статусів повернення прискорює обробку заявок?
Кастомні статуси скорочують час обробки на 30–40%: менеджеру не потрібно гадати, що робити далі, а система автоматично направляє заявку потрібним маршрутом. Наприклад, при статусі «Потрібні документи» клієнту надходить лист із запитом, а менеджеру — нагадування перевірити відповідь. Це виключає ручні нагадування та втрату заявок. Порівняно зі стандартним процесом, кастомні статуси обробляють заявки вдвічі швидше.
Де живуть статуси повернення в базі даних?
Статуси повернення зберігаються в таблиці 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С-Бітрікс: Робота зі статусами повернень