Регистрация и верификация B2B-клиентов на 1С-Битрикс

В рознице регистрация — формальность: имя, e-mail, пароль, и покупатель уже в деле. В опте так нельзя. За доступом к оптовому разделу стоят особые цены, отсрочки, минимальные партии и работа по договору с юрлицом — всё это коммерческая информация и особые условия, которые нельзя раздавать всем подряд. Поэтому вход нового партнёра в B2B почти всегда идёт через заявку и проверку: сначала компания подтверждает, что перед ней реальный контрагент, и только потом открывает цены и раздел. Грамотно выстроенная регистрация b2b битрикс — это не просто форма, а целый процесс: заявка → проверка → модерация → доступ.

Эта статья — практический разбор того, как принимать и проверять оптовых клиентов на 1С-Битрикс: какие поля собирать в форме регистрации юрлица и ИП, как устроено автозаполнение и проверка контрагента по ИНН, как организовать модерацию клиентов и статусы заявки, как присваивать группу и тип цен после одобрения и как привязывать пользователя к контрагенту в 1С. Материал из нашей практики разработки сайтов для B2B-компаний — по делу, без обещаний «гарантированного роста продаж».

Почему опт нельзя пускать «сразу»

Первый вопрос, который стоит задать перед проектированием регистрации: а зачем вообще проверять оптовика, если можно пустить сразу? Ответ в том, что доступ к опту — это не только вход в раздел, но и доступ к коммерчески чувствительным вещам. Открыть его без проверки означает раздать эти вещи кому угодно. Разберём, что именно рискует утечь и почему это важно.

• Цены. Оптовый и дилерский прайс — результат договорённостей и объёмов. Показывать его всем подряд — значит раскрывать конкурентам свою ценовую политику и обесценивать статус партнёра, ради которого он и регистрируется.
• Условия. Отсрочка платежа, минимальная партия, персональные скидки, работа по договору — всё это имеет смысл только внутри отношений «поставщик — контрагент», а не на открытой витрине для случайного гостя.
• Риски. Продажа юрлицу с отсрочкой — это, по сути, товарный кредит. Отгружать «в долг» неизвестной компании рискованно: нужно понимать, что контрагент реален, действует и за ним стоит конкретное юрлицо или ИП с реквизитами.
• Чистота базы. Без проверки в базу попадают дубли, фейки и «физики», притворяющиеся оптом. Это мешает менеджерам, ломает аналитику и путает обмен с 1С.

Поэтому вход в опт устроен как воронка с фильтром: заявку оставить может любой, а доступ получает только тот, кого компания проверила и одобрила. Это не бюрократия ради бюрократии, а защита цен, снижение рисков и поддержание порядка в клиентской базе. Дальше вся статья — про то, как собрать эту воронку на 1С-Битрикс из формы, статусов, модерации, групп и обмена с 1С так, чтобы она и защищала, и не отпугивала настоящих партнёров.

Путь клиента: от заявки до доступа

Прежде чем разбирать детали, полезно увидеть весь маршрут целиком. Регистрация B2B-клиента — это последовательность этапов, на каждом из которых заявка меняет своё состояние, а к пользователю применяются те или иные действия. От формы до открытого опта путь обычно один и тот же, отличаются лишь нюансы проверки.

Базовый маршрут выглядит так: заявитель заполняет форму → заявка попадает на модерацию → менеджер проверяет контрагента → при одобрении пользователю присваивается группа и тип цен и он привязывается к контрагенту в 1С → открывается доступ и начинается онбординг. На каждом переходе заявитель и менеджер получают уведомления, а заявка хранит свой статус.

Держите эту схему в голове по мере чтения: каждый следующий раздел детализирует один из её этапов. Сначала разберём форму и данные, затем автозаполнение и проверку, потом модерацию и статусы, присвоение группы и цен, привязку к 1С, роли пользователей и онбординг. Так частные решения будут складываться в единый процесс, а не в набор разрозненных настроек.

Что нужно узнать при регистрации оптовика

Форма регистрации — это компромисс между двумя противоположными желаниями. Компания хочет узнать о заявителе как можно больше, чтобы проверить и правильно завести контрагента. Заявитель хочет заполнить как можно меньше, чтобы не тратить время. Хорошая форма находит баланс: собирает достаточно для идентификации и проверки, но не превращается в анкету на десять экранов.

Чтобы решить, какие поля включать, полезно разделить данные по назначению:

• Идентификация контрагента. Тип клиента (юрлицо / ИП), название, ИНН, для юрлица — КПП. Это ядро, без которого нельзя ни проверить, ни завести контрагента.
• Связь с человеком. Контактное лицо, телефон, e-mail. По этим данным менеджер связывается с заявителем, а пользователь входит на сайт.
• Условия и профиль. Сфера деятельности, ожидаемые объёмы, регион — помогают менеджеру понять, какие условия предложить. Обычно необязательные.
• Финансовые реквизиты. Банковские реквизиты, юридический адрес, ОГРН — нужны для выставления счетов и договора. Их часто запрашивают не в форме, а позже, когда партнёр одобрен.

Отсюда следует важный принцип: не всё нужно спрашивать на первом шаге. Идентификацию и контакт — да, сразу. Финансовые реквизиты — можно позже, при оформлении первого заказа или подписании договора. Такой поэтапный сбор снижает порог входа: заявитель быстро оставляет заявку, а редкие поля заполняет тогда, когда уже мотивирован работать. Ниже разберём конкретный состав полей и то, как их организовать для юрлица и ИП.

Форма регистрации юрлица и ИП

Юрлицо и ИП — разные типы контрагентов, и набор реквизитов у них немного отличается. У юрлица есть КПП, у ИП его нет; у ИП в реквизитах фигурирует ОГРНИП вместо ОГРН. Поэтому удобно сделать переключатель типа клиента в начале формы, который показывает нужные поля. Ниже — типовой состав полей формы регистрации оптовика с пометкой обязательности.

Обратите внимание на колонку «Обязательность»: часть полей помечена как «позже» — их не стоит требовать на первом шаге. Банковские реквизиты нужны для счёта, а не для проверки заявки, поэтому их логично запросить, когда партнёр уже одобрен и оформляет первый заказ. Так первая форма остаётся короткой.

Технически такая форма в 1С-Битрикс собирается на пользовательских полях профиля или на отдельной сущности заявки. Реквизиты (ИНН, КПП, название) сохраняются в свойства пользователя или в запись заявки, чтобы менеджер видел их при модерации, а после одобрения они ушли в 1С. Ключевое поле — ИНН: именно оно будет использоваться и для автозаполнения, и для проверки, и для привязки к контрагенту.

Реквизиты, контактное лицо, документы

Разберём три группы данных подробнее, потому что именно вокруг них возникают вопросы при проектировании формы.

Реквизиты компании

Реквизиты — это то, что идентифицирует контрагента в юридическом и финансовом смысле: ИНН, КПП, ОГРН/ОГРНИП, юридический адрес, банковские данные. Для проверки и первичного заведения контрагента достаточно ИНН и КПП. Полные банковские реквизиты нужны позже — для счёта и договора. Поэтому реквизиты разумно разделить: «проверочные» (ИНН, КПП) собирать сразу, «платёжные» (расчётный счёт, банк, БИК) — на этапе первого заказа. Это уменьшает форму и не отпугивает заявителя длинной анкетой.

Контактное лицо

За юрлицом всегда стоит человек, и с ним работает менеджер. Контактное лицо — это имя, должность (по желанию), телефон и e-mail того, кто оставил заявку. Важно не путать контактное лицо с самой компанией: компания — контрагент, человек — пользователь сайта, привязанный к этому контрагенту. От одной компании таких людей может быть несколько (об этом в разделе про роли). E-mail контактного лица обычно становится логином, а телефон менеджер использует, чтобы подтвердить заявку и обсудить условия.

Документы

Иногда для верификации запрашивают документы: карточку предприятия, свидетельство, реквизиты на бланке. Это уместно в закрытых дилерских программах или при работе с крупными отсрочками, но повышает порог входа. Практичный подход — не требовать документы в форме регистрации, а запрашивать их выборочно на модерации, если заявка вызывает вопросы или условия того требуют. Для загрузки предусматривают поле «прикрепить файл» с ограничением по типу и размеру, а сами файлы хранят привязанными к заявке, доступными менеджеру.

Общий принцип этих трёх групп один: собирайте на входе минимум для проверки, а остальное запрашивайте по мере продвижения партнёра по воронке. Регистрация, которая требует всё и сразу, теряет заявителей ещё до отправки формы.

Автозаполнение по ИНН и сервисы проверки

Ручной ввод реквизитов — источник опечаток и повод бросить форму. Гораздо удобнее, когда заявитель вводит один ИНН, а система сама подтягивает остальное: название организации, КПП, ОГРН, юридический адрес, а нередко и статус (действующее / ликвидировано). Это и есть автозаполнение по ИНН — приём, который одновременно ускоряет заявку и служит первичной проверкой контрагента.

Работает это через внешние сервисы проверки контрагента. Они дают программный доступ к данным из открытых государственных реестров: по ИНН возвращают реквизиты и статус организации. Форма регистрации обращается к такому сервису в момент ввода ИНН и заполняет поля автоматически. Обзорно логику можно представить так:

У автозаполнения два эффекта. Первый — удобство: заявитель не переписывает реквизиты из учредительных документов, меньше ошибок в ИНН и КПП, форма заполняется в пару кликов. Второй — проверка: если по ИНН ничего не находится, найдено несоответствие или организация в статусе ликвидации, это видно сразу — либо заявителю, либо менеджеру при модерации. То есть автозаполнение — это ещё и первый фильтр антифрода.

Важно понимать границы: автозаполнение не заменяет модерацию. Оно подтверждает, что юрлицо существует и действует, но не отвечает на вопрос «стоит ли работать с этим контрагентом на оптовых условиях». Решение остаётся за менеджером. Конкретный сервис проверки выбирают по требованиям проекта — важно, что технически это отдельная интеграция с внешним источником данных, которую подключают к форме регистрации и, при необходимости, к карточке заявки в админке.

Проверка и верификация контрагента

Верификация оптовиков — это подтверждение, что заявитель тот, за кого себя выдаёт, и что с ним можно работать на оптовых условиях. Она складывается из нескольких уровней, которые дополняют друг друга. Не стоит полагаться на один способ — надёжность даёт именно их сочетание.

Первые три уровня можно частично автоматизировать: формат полей проверяется на форме, существование компании — сервисом по ИНН, дубли — поиском по базе. Они отсекают явный мусор и ошибки ещё до того, как заявка дойдёт до человека. Но финальные два — модерация и подтверждение контакта — остаются за менеджером, потому что решение «открыть опт» это бизнес-решение, а не технический флаг.

Полезно отличать проверку от верификации. Проверка — это факты: существует ли ИНН, действует ли компания, нет ли дубля. Верификация — это решение на основе этих фактов плюс политики компании: работаем или нет, на каких условиях, в какую группу. Система должна давать менеджеру факты в удобном виде (подсветить проблемы, показать реквизиты, статус, дубли), но не подменять собой решение. Хорошая модерация — это когда менеджер за минуту видит всё нужное и одним действием одобряет или отклоняет заявку.

Модерация менеджером и статусы заявки

Модерация — сердце процесса регистрации в опте. Именно здесь заявка превращается (или не превращается) в доступ. Чтобы модерация была управляемой, каждой заявке присваивают статус — её состояние на пути от отправки до решения. Статусы нужны обеим сторонам: менеджеру они дают понятную очередь работы, заявителю — обратную связь.

Типовой набор статусов заявки:

Статусы — это не просто ярлыки. Каждая смена статуса — точка, где что-то должно произойти: заявка попадает в очередь, менеджеру приходит уведомление, заявителю уходит письмо, при одобрении запускается присвоение группы и привязка к 1С. Поэтому статусную модель проектируют вместе с уведомлениями и действиями, а не как отдельный справочник.

Технически заявки удобно вести как отдельную сущность (например, элементы инфоблока заявок или записи highload-блока) со свойством «статус» и историей изменений, либо на статусах пользователя (активен/неактивен + группа «на модерации»). Менеджеру дают список заявок с фильтром по статусу и карточку с реквизитами, результатом проверки по ИНН и кнопками «одобрить»/«отклонить»/«запросить документы». Чем меньше кликов на типовое действие, тем быстрее обрабатываются заявки и тем меньше партнёров теряется в очереди.

Присвоение группы и типа цен

Момент одобрения заявки — это момент, когда пользователь получает доступ к опту. Технически это выражается в двух действиях: его переводят в нужную группу пользователей и тем самым открывают ему нужный тип цен. Эти две сущности — основа доступа в закрытом опте, и на них держится всё, что видит партнёр после входа.

Как это связано:

• Группа отвечает на вопрос «кто это». До одобрения пользователь либо неактивен, либо в промежуточной группе «на модерации». После одобрения его переводят в «Оптовые покупатели» или «Дилеры» — в зависимости от условий.
• Тип цены отвечает на вопрос «сколько для него стоит». Оптовая цена — отдельный тип цены в торговом каталоге, видимый только оптовой группе. Как только пользователь в этой группе, он автоматически видит оптовые цены как основные.
• Права на раздел решают «что он видит». Закрытый оптовый раздел каталога открыт правами именно оптовым группам, поэтому смена группы открывает и раздел.

То есть одно действие — перевод в группу — запускает всё сразу: открывается раздел, показываются цены, становится доступен личный кабинет. Не нужно вручную настраивать доступ под каждого партнёра: настройка делается один раз на уровне групп и типов цен, а конкретный пользователь просто попадает в нужную группу. Если уровней партнёрства несколько (опт, крупный опт, дилер), каждому соответствует своя группа со своим типом цен, и менеджер при одобрении выбирает, в какую группу поместить контрагента.

Эту связку «группа ↔ тип цены ↔ права» мы подробно разбираем в отдельных материалах — про закрытый оптовый раздел на 1С-Битрикс и про индивидуальные прайс-листы для B2B. В контексте регистрации важно запомнить: одобрение заявки — это не абстрактная «галочка», а конкретный перевод пользователя в группу, который и открывает ему опт.

Привязка к контрагенту в 1С

В большинстве B2B-проектов учёт ведётся в 1С, и заказы оптовика должны попадать на карточку правильного контрагента. Поэтому при одобрении заявки пользователя сайта привязывают к контрагенту в 1С. Здесь возможны два сценария: контрагент уже есть в 1С или его нужно создать.

• Контрагент есть. Если по ИНН (для юрлица — плюс КПП) в 1С находится существующий контрагент, нового пользователя сайта связывают с ним. Все его заказы и документы соотносятся с уже знакомой карточкой, где есть история, договор, условия.
• Контрагента нет. Если по ИНН совпадений нет, контрагент создаётся в 1С по данным заявки, а затем связывается с учётной записью на сайте.

Ключ сопоставления — ИНН. Именно поэтому ИНН собирают и проверяют так тщательно: это связующее звено между пользователем сайта и контрагентом в учётной системе. Привязка передаётся в обмене между сайтом и 1С по формату CommerceML: заказы уходят с идентификатором контрагента, документы и взаиморасчёты возвращаются на нужную карточку.

Главный риск на этом шаге — дубли. Если по одному ИНН завести двух контрагентов, история заказов, документы и взаиморасчёты разъедутся между двумя карточками, и разбираться потом придётся вручную. Поэтому перед созданием контрагента система (или менеджер) проверяет, нет ли уже такого ИНН в 1С и среди пользователей сайта. Проверка на дубли — обязательная часть привязки, а не опция. Ниже, в разделе про антифрод, разберём дубли подробнее.

Отдельно стоит держать в голове, что обмен с 1С — двусторонний: сайт отдаёт заказы и данные привязки, а 1С возвращает цены, статусы, документы. Регистрация встраивается в этот обмен ровно в точке привязки: как только пользователь связан с контрагентом, он начинает участвовать в общем потоке данных между сайтом и учётной системой.

Несколько пользователей одной компании

В B2B за одним контрагентом часто стоит не один человек, а несколько сотрудников: закупщик оформляет заказы, бухгалтер работает с документами, руководитель согласует крупные закупки. Все они должны заходить на сайт под своими учётными записями, но видеть данные одной компании — её цены, её историю, её баланс. Это модель «несколько пользователей — один контрагент».

Почему не обойтись одним общим логином на всех:

• Видно, кто что сделал. Отдельные учётки дают историю действий: кто оформил заказ, кто скачал документ. С общим логином всё обезличено.
• Гибкие права. Не всем сотрудникам нужен полный доступ. Закупщику — оформлять заказы, бухгалтеру — видеть документы, стажёру — только смотреть каталог. Роли решают это.
• Безопасность. Уволился сотрудник — отзываете его доступ, не меняя пароль всей компании. С общим логином пришлось бы менять пароль и раздавать заново всем.

Реализуют это через роли внутри компании. Обычно первый зарегистрировавшийся становится администратором контрагента и может приглашать коллег — по e-mail или ссылке-приглашению. Приглашённые проходят упрощённую регистрацию (компания уже проверена, повторная модерация не нужна) и получают роль, которую задал администратор. Типовой набор ролей:

Такая ролевая модель — часть личного кабинета дилера, где собраны заказы, документы, баланс и управление пользователями компании. Подробно устройство кабинета мы разбираем в статье про личный кабинет дилера на 1С-Битрикс, а под ключ собираем в рамках услуги разработки личного кабинета дилера. Для регистрации здесь важно одно: проектируя форму и привязку, сразу закладывайте возможность нескольких пользователей на контрагента, иначе потом придётся переделывать модель доступа.

Онбординг оптовика после входа

Одобрить заявку — половина дела. Вторая половина — сделать так, чтобы партнёр с первого входа понял, как здесь работать. Оптовик, который вошёл и не разобрался, где цены и как оформить заказ, — это нагрузка на менеджеров и риск, что он не начнёт заказывать. Поэтому после первого входа полезен короткий онбординг.

Что стоит показать новому партнёру:

1. Приветствие и подтверждение. Короткое «Доступ открыт, добро пожаловать» — чтобы партнёр понял, что модерация пройдена и он в опте.
2. Где цены и как заказать. Покажите, что теперь видны оптовые цены, объясните минимальную партию и кратность, если они есть.
3. Личный кабинет. Где смотреть историю заказов, скачивать документы, видеть баланс и реквизиты.
4. Приглашение коллег. Если работает несколько человек от компании — как пригласить их и раздать роли.
5. Контакт менеджера. Кто персональный менеджер и как с ним связаться по вопросам заказа и условий.

Онбординг не обязательно делать сложным. Достаточно нескольких карточек-подсказок, короткого приветственного экрана или блока «с чего начать» в кабинете. Главное — не вываливать всё сразу и не оставлять партнёра один на один с пустым каталогом. Цель — чтобы с первого входа было понятно, как заказывать и где искать нужное. Хорошо сделанный онбординг заметно снижает поток вопросов «а где посмотреть цену» и «как скачать счёт», разгружая менеджеров.

Уведомления заявителю и менеджеру

Регистрация с модерацией — это диалог двух сторон, растянутый во времени. Заявитель отправил форму и ждёт. Менеджер должен вовремя увидеть заявку. Между ними — уведомления, которые связывают процесс и не дают заявкам теряться. Проектировать их нужно вместе со статусами: каждой смене статуса соответствует своё письмо.

Кому и когда уходят уведомления:

Два уведомления критичны для конверсии. Первое — заявителю сразу после отправки: «заявка принята». Без него человек не знает, сработала ли форма, и часто уходит. Второе — заявителю при одобрении: «доступ открыт», со ссылкой на вход. Это приглашение начать работать, и оно должно быть понятным и быстрым. Уведомление менеджеру о новой заявке важно для скорости: чем быстрее менеджер увидит заявку, тем быстрее партнёр получит ответ.

Отдельно про отказ. Отклонённой заявке тоже стоит отправить уведомление — вежливое и по возможности с причиной. Молчание после заявки воспринимается хуже, чем аргументированный отказ. Технически уведомления в 1С-Битрикс делают на почтовых событиях и шаблонах писем, привязанных к смене статуса заявки, а для менеджеров дополнительно — уведомление в админке или в CRM.

Антифрод и дубликаты

Открытая форма регистрации — приманка для двух проблем: мусорных/фейковых заявок и дублей. Обе решаются не одной галочкой, а несколькими уровнями защиты, каждый из которых отсекает свой тип проблемы. Разберём их по порядку.

Против ботов и мусора

Базовая гигиена формы: капча или невидимая проверка на автоматизацию, ограничение частоты отправок с одного адреса, проверка обязательных полей и формата. Это отсекает автоматический спам и случайные пустые заявки ещё до модерации, чтобы менеджер не разбирал мусор.

Против фейковых компаний

Проверка ИНН по справочнику контрагентов: несуществующий или ликвидированный ИНН отсекается на форме или подсвечивается менеджеру. Это тот самый эффект автозаполнения по ИНН — оно же служит первичным антифродом. Компания, которой нет в реестре, не пройдёт дальше без внимания менеджера.

Против дублей

Перед созданием новой записи система ищет, нет ли уже такого ИНН среди пользователей сайта и контрагентов в 1С. Возможные исходы:

• Дубль-компания. По ИНН уже есть контрагент — вероятно, регистрируется второй сотрудник той же компании. Логичнее не плодить контрагента, а предложить присоединиться к существующему (через роли) или уведомить менеджера.
• Повторная заявка. Тот же ИНН уже подавал заявку — не создаём вторую, а показываем статус существующей.
• Совпадение по контакту. Тот же e-mail или телефон уже есть — сигнал проверить, не дубль ли это.

Финальный барьер антифрода — модерация. Даже если заявка прошла все автоматические проверки, решение открыть опт принимает человек. Автоматика отсекает явные проблемы и экономит время, но не отвечает за бизнес-решение. Именно поэтому саморегистрация без модерации в опте опасна: она снимает последний, самый важный барьер. Сочетание автоматических проверок и ручной модерации даёт и скорость, и надёжность.

Персональные данные: 152-ФЗ и согласия

Форма регистрации собирает персональные данные — как минимум ФИО контактного лица, телефон, e-mail, а часто и реквизиты. Это накладывает обязательства по закону о персональных данных (152-ФЗ). Тема юридическая, и здесь важна осторожность: технические решения не заменяют юридическую консультацию. Но со стороны реализации есть базовые вещи, которые закладывают на этапе разработки формы.

• Согласие на обработку. Форма должна содержать явное согласие на обработку персональных данных со ссылкой на политику конфиденциальности. Обычно это обязательный чекбокс, без которого форма не отправляется.
• Только нужные данные. Собирают тот минимум, который действительно нужен для цели (проверка и работа с контрагентом). Лишние поля — не только длинная форма, но и лишняя ответственность за данные.
• Хранение и доступ. Данные заявок хранят с ограничением доступа: их видят менеджеры, а не любой посетитель. Доступ к карточкам заявок разграничивают правами.
• Прозрачность цели. Заявителю понятно, зачем собираются данные и как они используются — это и требование закона, и элемент доверия.

Практический вывод для разработки: чекбокс согласия и ссылка на политику конфиденциальности — обязательная часть формы регистрации, а не опция. Состав собираемых данных согласуют с тем, что реально нужно для проверки и работы. Конкретные требования и формулировки согласий лучше уточнять у юриста компании — задача разработки в том, чтобы форма и хранение данных технически поддерживали выбранную политику, а не в том, чтобы её определять.

Куда ведёт оптовик после одобрения

Соберём картину того, что получает партнёр в результате всего процесса. Регистрация и верификация — это вход, а за входом должна быть ценность: то, ради чего оптовик проходил проверку. Наглядно можно представить это как несколько слоёв, которые открываются одобрением.

Эти слои открываются не по одному вручную, а разом — как следствие перевода в группу и привязки к контрагенту. Партнёр видит оптовые цены, попадает в закрытый раздел, получает личный кабинет с историей и документами и может пригласить коллег. Именно ради этого набора он и проходил регистрацию. Если после одобрения партнёр не видит ощутимой ценности — процесс проектировали зря.

Полный набор сценариев — закрытый раздел, персональные цены, кабинет, обмен с 1С — мы собираем в комплексе. Смежные материалы, которые дополняют эту статью: про закрытый оптовый раздел, про личный кабинет дилера и про индивидуальные прайс-листы. Все они — в рубрике «B2B и опт».

Реализация регистрации пошагово

Соберём процесс в понятную последовательность внедрения. Названия пунктов меню могут отличаться в зависимости от версии и редакции платформы, но порядок общий: от формы и групп к модерации и обмену с 1С, и в конце — проверка под ролями.

1. Спроектируйте форму. Переключатель «юрлицо/ИП», поля идентификации (название, ИНН, КПП), контакт, согласие на обработку данных. Редкие поля — на потом.
2. Заведите группы. Промежуточная «На модерации» и целевые «Оптовые покупатели» / «Дилеры» помимо гостей и розницы.
3. Настройте статусы заявок. Отдельная сущность заявки со статусами (новая, на проверке, нужны документы, одобрена, отклонена) и историей.
4. Подключите автозаполнение по ИНН. Интеграция формы с сервисом проверки контрагента: реквизиты и статус подтягиваются по ИНН.
5. Соберите карточку модерации. Список заявок с фильтром по статусу и карточка с реквизитами, результатом проверки и кнопками «одобрить/отклонить/запросить документы».
6. Настройте присвоение группы и цен. Одобрение переводит пользователя в оптовую группу, что открывает раздел и тип цен.
7. Настройте привязку к 1С. Сопоставление по ИНН: найден контрагент — привязка, нет — создание; проверка на дубли; передача связи в обмене.
8. Настройте уведомления. Письма заявителю и менеджеру на каждую смену статуса: принято, нужны документы, одобрено, отклонено.
9. Добавьте роли и приглашения. Возможность подключить нескольких пользователей одной компании с разными правами.
10. Сделайте онбординг. Короткое приветствие после первого входа: где цены, кабинет, как заказать, контакт менеджера.
11. Проверьте под ролями. Пройдите путь как заявитель (юрлицо и ИП), как менеджер на модерации, как одобренный оптовик и как приглашённый коллега.

Последний шаг критичен и его часто пропускают. Регистрация легко «выглядит правильно» в админке, но на практике ломается в деталях: не уходит письмо, статус не меняется, дубль создаётся, у приглашённого коллеги нет нужных прав. Сквозная проверка всего пути под всеми ролями ловит это до запуска. Пройти заявку целиком, от формы до открытого опта, глазами реального оптовика — лучший тест готовности.

Частые ошибки

Эти промахи в регистрации и верификации B2B-клиентов повторяются чаще всего — зная их, вы избежите потери партнёров и мусора в базе:

• Пускают в опт сразу. Саморегистрация без модерации открывает цены кому угодно — конкурент заводит «компанию» и видит весь прайс.
• Слишком сложная форма. Десять обязательных полей, включая банковские реквизиты, на первом шаге — заявитель бросает форму, не дойдя до кнопки.
• Нет обратной связи по заявке. Отправил форму — и тишина. Ни статуса, ни письма. Оптовик решает, что заявка потерялась, и уходит.
• Ручной ввод реквизитов. Без автозаполнения по ИНН заявитель переписывает данные вручную с опечатками, а первичной проверки нет.
• Дубли контрагентов. По одному ИНН заводят двух контрагентов — история заказов и взаиморасчёты разъезжаются между карточками.
• Один логин на всю компанию. Все сотрудники под общим паролем — не видно, кто что сделал, и не отозвать доступ уволившемуся.
• Молчаливый отказ. Отклонённой заявке не пишут ничего — это хуже для репутации, чем вежливый аргументированный отказ.
• Нет онбординга. Партнёр вошёл и не понял, где цены и как заказать — растёт нагрузка на менеджеров, часть партнёров не начинает работать.
• Забыли про согласие на данные. Форма собирает персональные данные без чекбокса согласия и ссылки на политику — нарушение требований.

Чек-лист

Короткий список для приёмки регистрации и верификации оптовиков перед запуском:

1. Форма адаптивна к типу клиента. Есть переключатель «юрлицо/ИП», поля подстраиваются, обязательное — только необходимое.
2. Автозаполнение по ИНН работает. Реквизиты подтягиваются, статус компании виден, несуществующий ИНН отсекается.
3. Статусы заявок заведены. Заявка проходит от «новой» до «одобрена/отклонена», статус хранится и виден.
4. Модерация удобна. Менеджер видит очередь, реквизиты и результат проверки, одобряет/отклоняет в пару кликов.
5. Группа и цены присваиваются. Одобрение переводит в оптовую группу и открывает раздел и тип цен.
6. Привязка к 1С по ИНН. Контрагент находится или создаётся, дубли не плодятся, связь идёт в обмене.
7. Уведомления настроены. Письма заявителю и менеджеру на каждую смену статуса, включая отказ.
8. Роли компании работают. Несколько пользователей на контрагента, приглашения, разграничение прав.
9. Согласие на данные есть. Чекбокс и ссылка на политику конфиденциальности в форме, доступ к заявкам ограничен.
10. Пройдено под ролями. Путь проверен как заявитель, менеджер, одобренный оптовик и приглашённый коллега.

Вывод

Регистрация и верификация B2B-клиентов на 1С-Битрикс — это не форма, а процесс: заявка → проверка → модерация → доступ. Опт нельзя пускать «сразу», потому что вместе с доступом партнёр получает закрытые цены и особые условия, которые дают только проверенным контрагентам. Форма собирает данные для идентификации (тип клиента, ИНН, КПП, реквизиты, контакт), автозаполнение по ИНН ускоряет заявку и служит первичной проверкой, а модерация со статусами превращает заявку в осознанное решение открыть опт.

После одобрения работает связка автоматики и учёта: пользователю присваивают группу и тип цен, привязывают к контрагенту в 1С по ИНН (без дублей), при необходимости подключают коллег с ролями и встречают партнёра коротким онбордингом. Уведомления на каждую смену статуса не дают заявкам теряться, антифрод и проверка на дубли держат базу чистой, а согласие на обработку данных закрывает требования 152-ФЗ. Собранный так процесс и защищает цены, и не отпугивает настоящих партнёров. Разобрать конкретный сценарий под ваш каталог и условия работы можно в рамках нашей услуги — начните с сайта для B2B-компании или изучите смежные материалы в рубрике «B2B и опт».