Налаштування системи спорів та арбітражу маркетплейсу 1С-Bitrix
Покупець отримав не той товар або не отримав нічого — відкриває спір. Продавець не згоден з претензією. Потрібна третя сторона — платформа. В 1С-Bitrix немає готового інструмента для спорів, це користувацька розробка поверх системи замовлень.
Модель даних спорів
Спір прив'язаний до суб-замовлення. Таблиця 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 тиждень.