Настройка системы споров и арбитража маркетплейса 1С-Битрикс
Покупатель получил не тот товар или не получил ничего — он открывает спор. Продавец не согласен с претензией. Нужна третья сторона — платформа. В 1С-Битрикс нет готового инструмента для споров, это кастомная разработка поверх системы заказов.
Модель данных споров
Спор привязан к суб-заказу. Таблица mp_disputes:
| Поле | Тип | Описание |
|---|---|---|
| ID | int, AI | |
| SUB_ORDER_ID | int | FK на суб-заказ |
| INITIATOR_ID | int | USER_ID покупателя |
| VENDOR_ID | int | FK на продавца |
| REASON | varchar | not_received / wrong_item / damaged / other |
| DESCRIPTION | text | Описание проблемы |
| STATUS | varchar | open / seller_response / arbitrage / resolved / closed |
| RESOLUTION | varchar | refund / partial_refund / reject / exchange |
| ADMIN_USER_ID | int | Менеджер-арбитр |
| CREATED_AT | datetime | |
| RESOLVED_AT | datetime |
Вложения к спору (фото) — отдельная таблица mp_dispute_attachments с FILE_ID (через CFile).
Процесс спора
Этап 1 — Открытие спора. Покупатель открывает спор через личный кабинет, если заказ в статусе delivered и не истёк срок (например, 14 дней с получения). Статус суб-заказа меняется на dispute_open, платёж на выплату продавцу замораживается.
Этап 2 — Ответ продавца. Продавец получает уведомление, в течение N дней (например, 3) должен ответить: согласиться с возвратом, предложить частичный возврат или аргументированно отказать. Ответ фиксируется в таблице mp_dispute_messages.
Этап 3 — Арбитраж. Если стороны не договорились или продавец не ответил в срок — спор переходит в арбитраж. Менеджер платформы изучает переписку, фото, данные заказа. Принимает решение (RESOLUTION).
Этап 4 — Исполнение решения. При refund — инициируется возврат покупателю через API платёжной системы, запись в mp_finance_log уменьшает баланс продавца. При reject — выплата продавцу разблокируется.
Интерфейсы
Покупатель: форма открытия спора, чат с продавцом, статус рассмотрения.
Продавец: уведомление о новом споре, форма ответа с возможностью прикрепить документы, результат решения.
Администратор: список открытых споров с SLA-таймером (сколько осталось до просрочки), детальный просмотр переписки, форма принятия решения.
Переписка по спору — отдельная таблица mp_dispute_messages с полями DISPUTE_ID, SENDER_TYPE (buyer/seller/admin), TEXT, CREATED_AT. Обновление интерфейса — через polling или WebSocket.
Сроки
Базовая система споров (открытие, ответ продавца, решение администратора) — 2–3 недели. Автоматизация просроченных ответов и исполнения решений — дополнительно 1 неделя.