Уявіть: на маркетплейсі сотні продавців, щодня реєструються десятки юросіб. Без автоматичної перевірки документів адміністратор тоне в рутині — відкриває PDF, звіряє ІПН, вручну перемикає статуси. Помилка коштує дорого: продавець іде до конкурента, а майданчик втрачає комісію. Ручне опрацювання однієї заявки обходиться в сотні гривень за часом адміністратора — при 200 заявках на місяць це значні витрати. Автоматизація скорочує ці витрати на 80%.
Ми вирішуємо цю проблему: налаштовуємо реєстрацію продавців на 1С-Бітрікс так, щоб процес збору даних юрособи, перевірки та онбордингу працював без збоїв. Правильно налаштований онбординг скорочує час виходу продавця на майданчик на 30% і підвищує конверсію реєстрації на 25%. Отримайте консультацію — оцінимо ваш проект за один день.
Як влаштована реєстрація продавців на Бітрікс?
Продавець у системі — це користувач b_user у спеціальній групі (наприклад, «Продавці», b_user_group). Додаткові дані юрособи ми зберігаємо в UF-полях користувача (b_user_field) або в окремому HL-інфоблоці зі зв'язком через UF_USER_ID. Такий підхід дозволяє гнучко розширювати профіль без зміни ядра. Всі поля індексовані — перевірка ІПН виконується за мілісекунди.
Основні поля реєстраційної форми продавця:
- Тип суб'єкта (ТОВ/ФОП/фізособа)
- Повне найменування організації
- ІПН, КПП (для юросіб), ОГРН/ОГРНИП
- Юридична адреса
- Контактна особа, телефон, email
- Банківські реквізити
- Посилання на документи (статут, свідоцтво) — завантаження через
CFile
Статусна модель: registered → documents_pending → under_review → active | rejected Статус зберігається в UF-полі користувача. При кожному переході — автоматичний лист через CEvent::Send() за шаблоном подій Бітрікс. Це стандартний механізм, описаний у документації Бітрікс. Для складнішої логіки використовуємо агенти та події — наприклад, автоматичний перехід у статус under_review після завантаження документів.
Чому важливо автоматизувати онбординг?
Без автоматизації адміністратору доводиться вручну перевіряти документи, перемикати статуси та надсилати листи. Це повільно та загрожує помилками. Автоматизація ж виконується за секунди та виключає людський фактор. Після схвалення продавець одразу отримує доступ до інструментів майданчика.
Порівняння підходів:
| Критерій | Стандартна реєстрація | Кастомна реєстрація продавців |
|---|---|---|
| Збір даних юрособи | Тільки базові поля | Розширені поля + завантаження документів |
| Перевірка контрагентів | Немає | Інтеграція з DADATA/ФНС API |
| Онбординг | Ручний | Автоматичний: welcome-лист, налаштування кабінету |
| Час на реєстрацію | 1–2 дні (ручна обробка) | 5–10 хвилин (автоматично) |
Як реалізувати перевірку контрагентів через DADATA або ФНС?
Перевірка контрагентів — ключовий етап. Типова помилка — відсутність валідації ІПН. Якщо продавець ввів невірний ІПН, перевірка документів затягується, і 30% заявок відвалюються. Ми впроваджуємо перевірку через API ФНС за 2 секунди. Для цього створюється зовнішній обробник на PHP, що викликається з агента або події. Результат зберігається в UF-полі UF_CONTRAGENT_STATUS. Якщо статус «не знайдено», продавець бачить помилку та може виправити дані.
Приклад реалізації перевірки через DADATA:
// Виклик API DADATA для перевірки ІПН $url = 'https://suggestions.dadata.ru/suggestions/api/4_1/rs/findById/party'; $data = ['query' => $inn]; $options = [ 'http' => [ 'header' => "Content-Type: application/json\r\nAuthorization: Token $api_key\r\n", 'method' => 'POST', 'content' => json_encode($data) ] ]; $context = stream_context_create($options); $result = file_get_contents($url, false, $context); Результат — дані про юрособу: найменування, адреса, статус. Якщо організація зареєстрована, ІПН коректний.
Що робити, якщо перевірка контрагента не пройшла?
Якщо API повертає помилку або дані не знайдено, продавець отримує сповіщення з проханням перевірити ІПН. Адміністратор може вручну підтвердити дані через адмін-інтерфейс. Для складних випадків (наприклад, неспівпадіння адреси) ми додаємо можливість завантажити скан свідоцтва. Всі дії логуються в b_event_log для аудиту.
Що входить до нашої роботи
- Підготовка технічного завдання зі схемами статусної моделі та інтеграцій
- Розробка кастомної форми реєстрації з розширеними полями
- Налаштування статусної моделі та подійних листів
- Інтеграція з сервісами перевірки контрагентів (DADATA, ФНС API)
- Створення адміністративного інтерфейсу для керування заявками
- Онбординг: автоматичне призначення групи, створення особистого кабінету, welcome-лист
- Документація (опис схем, інструкції для адміністратора)
- Навчання співробітників роботі з системою
- Підтримка після запуску (2 тижні безкоштовно)
Етапи статусної моделі та час опрацювання
| Статус | Дія | Час (авто) | Час (ручний) |
|---|---|---|---|
| registered | Перевірка полів | 1 сек | 1–2 хв |
| documents_pending | Завантаження документів | 1 хв | 10–30 хв |
| under_review | Перевірка контрагента | 5 сек | 30–60 хв |
| active | Онбординг | 10 сек | 1–2 години |
Орієнтовні терміни
Базова настройка (форма + статусна модель + сповіщення) — від 1 до 2 тижнів. Якщо потрібна інтеграція з DADATA або ФНС API — від 3 до 4 тижнів. Терміни уточнюються після аналізу ваших вимог. Замовте консультацію — ми підберемо оптимальне рішення.
Типові помилки при налаштуванні:
- Неправильне зв'язування HL-блока з користувачем (забувають
UF_USER_ID) - Відсутність індексів на поля ІПН/ОГРН — гальмує перевірку
- Занадто довгі статусні моделі (більше 5 статусів плутають адміністратора)
- Ігнорування шаблонів подій — листи не надсилаються
Уникнути цих проблем допомагає наш досвід — ми вже запустили більше 50 маркетплейсів на Бітрікс і даємо 6 місяців гарантії. Отримайте консультацію — оцінимо ваш проект за один день.