Представьте: на маркетплейсе сотни продавцов, каждый день регистрируются десятки юрлиц. Без автоматической проверки документов администратор тонет в рутине — открывает 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 месяцев гарантии. Получите консультацию — оценим ваш проект за один день.