Когда на оптовый сайт приходит новый дилер, ему нужно дать его цены. Между "зарегистрировался" и "увидел свою цену" стоит работа менеджера: узнать компанию, найти её в учётной системе, разобраться, на каких условиях она работает, и проставить нужный тариф в карточке пользователя. На каждого нового клиента - несколько ручных действий, и каждое из них можно сделать неверно.
Почему подключение нельзя оставить оператору
Цена ошибки несимметрична.
- →Занизил тариф - компания продаёт дешевле, чем договаривалась, и замечает это не сразу.
- →Завысил - клиент видит цену выше обещанной и звонит с претензией.
- →Поторопился и одобрил непроверенного - закрытые дилерские цены ушли к тому, кто их видеть не должен, в том числе к конкуренту.
Устройство оптового клиента добавляет сложности. У одного регионального дилера шесть юридических лиц - два общества и четыре предпринимателя, и снабженец может зарегистрироваться с реквизитами любого из них. Сотрудников тоже несколько, и все они должны получить одни и те же условия. А когда компания переходит на новый тариф, поменять его нужно сразу всем.
Требовалось решение, при котором оператор не назначает тарифы вообще: коммерческая политика ведётся в 1С, а сайт лишь применяет её.
Решение
Клиент вводит ИНН - сайт узнаёт компанию
Клиент вводит ИНН - и сайт узнаёт его компанию. Дальше всё происходит без человека.
Вот путь снабженца этого дилера. Он указал ИНН одного из шести юридических лиц своей компании. Сайт нашёл это юридическое лицо в справочнике из более чем 11 тысяч контрагентов, поднялся от него к компании-владельцу, взял её тариф и открыл соответствующие ценовые колонки. Подкатной домкрат, который розничный покупатель видит примерно за 10 250 ₽, для этого снабженца стоит около 7 700 ₽.
Ключевое здесь - где именно закреплён тариф. Он привязан не к юридическому лицу, а к компании целиком. Поэтому какой из шести ИНН ни введи - результат один и тот же. Скидка отражает отношения с компанией, а не отдельную строку в реестре юридических лиц, и система устроена именно так.
Форма, которая не спрашивает лишнего
У формы две вкладки. Юридическое лицо вводит ИНН и КПП, предприниматель - только ИНН: сайт проверяет прямо при вводе, что "ИНН индивидуального предпринимателя состоит из 12 цифр". Реквизиты компании, банковские счета, юридический адрес - ничего этого не спрашивают: всё уже есть в справочнике.
Узнавание происходит незаметно. Клиент нажимает "Зарегистрироваться", и в этот момент сайт находит его компанию среди тысяч записей. Ни выпадающих списков, ни уточняющего вопроса "ваша ли это компания?" - клиент даже не догадывается, что его узнали.
Справочник, в котором идёт поиск, целиком приходит из 1С: более 11 тысяч контрагентов, из них 6 210 - компании и предприниматели. На сайте его никто не ведёт: появился в учётной системе новый клиент - через несколько секунд он есть и на сайте.
Тонкость, которую клиент не видит: предприниматель в 1С заведён как контрагент-физическое лицо, а не как организация. Поэтому вкладка "Индивидуальный предприниматель" ищет его среди физических лиц, а вкладка "Юридическое лицо" - среди организаций. Разницу учётной системы приняла на себя форма, а не человек.
Тариф вычисляется, а не назначается
Тип клиента - это то, что превращает витрину в персональную. Он определяет, какие ценовые колонки открыты покупателю, а значит - какую цену тот видит в каталоге, по какой цене фильтрует и сортирует, что попадает в его корзину и счёт.
Один и тот же товар стоит по-разному для пяти разных типов клиента. Розничный покупатель платит за подкатной домкрат около 10 250 ₽, постоянный - на 5-12% меньше, оптовый клиент - примерно на 15%, дилер - примерно на четверть. Разница между крайними значениями - около 2 550 ₽ на каждой единице, и умножается она на объём дилерской закупки.
Всего типов клиента 19, из них 11 - дилерские ступени. Ни один из них не заводится на сайте руками: справочник повторяет учётную систему, и новый тип, появившийся в 1С, возникает на сайте сам и сам подключается к ценовой матрице. Матрица - это 741 правило: 19 типов клиента на 13 категорий товара. Подробно ценовая механика разобрана в разборе персональных цен.
Сама же цепочка "юридическое лицо - компания - тариф" не рвётся ни разу: компания-владелец заполнена у всех контрагентов справочника. Это значит, что тариф вычислим для любого клиента базы - в том числе для того, кто ещё ни разу не заходил на сайт. Он не назначается при регистрации, он к этому моменту уже существует.
Одна отметка - четырнадцать полей
Быстро - не значит без контроля. Между регистрацией и дилерскими ценами стоит человек, но его работа сведена к одному вопросу: настоящая ли это компания и тот ли человек её представляет.
Заявка на подключение создаётся сама в момент регистрации - с уже подобранным контрагентом, уже вычисленным тарифом и приложенными документами. Модератор получает письмо "Заявка на модерацию" со ссылкой "Открыть заявку", проверяет документы и ставит одну отметку.
Дальше решение применяется само: четырнадцать полей профиля покупателя заполняются без единого ручного ввода - контрагент, тип клиента, реквизиты, права на просмотр заказов коллег. Заодно заказы последних дней дооформляются на юридическое лицо: клиент, успевший что-то заказать до одобрения, не остаётся с заказом "от физического лица".
Самое интересное происходит в конце. Тип клиента, который модератор видел в заявке, пересчитывается заново по цепочке из 1С - и перекрывает то, что стоит в форме. Даже если бы модератор захотел выдать тариф вручную, это не сработало бы: последнее слово всегда за учётной системой.
До одобрения дилерских цен не существует
Пока заявка не одобрена, сотрудник дилерской компании ходит по сайту как обычный розничный посетитель: каталог открыт целиком, карточки, характеристики и наличие - на месте, но цены розничные, а кнопка оформления заказа не работает. В корзине он видит объяснение: "Ваш аккаунт в данный момент проходит процедуру подтверждения. Дождитесь окончания этой процедуры, чтобы продолжить оформление заказа".
До одобрения: каталог открыт полностью, но цены розничные, а оформление заказа закрыто. Дилерских цен не видно - их для этого покупателя просто не существует.
После отметки модератора: тот же товар, та же страница, тот же вход. Изменился только тип клиента в профиле - и вся витрина пересчиталась: каталог, фильтры по цене, корзина, счёт.
Устроено это не запретом, а подстановкой. У неодобренного покупателя система просто не спрашивает личный тип клиента - она берёт розничный. Дилерских цен для него не существует: их не прячут от него, их для него не рассчитывают. Прятать нечего - значит, нечему и утечь.
Тот же принцип держит и оформление заказа: попытка отправить заказ в обход формы упирается в проверку на стороне сервера: "Оформление заказа недоступно. Обратитесь к администратору". Витрина, кнопка и сервер проверяют одно и то же независимо друг от друга.
Условия меняются в 1С - новый тариф получает вся команда
Тариф приходит к клиенту не только в момент регистрации.
Когда компания переходит на новые условия, коммерческий отдел меняет ей тариф в 1С - и всё. Сайт замечает смену, находит все юридические лица этой компании, всех сотрудников по этим лицам и обновляет тип клиента каждому одним проходом. Менеджеру не нужно помнить, что у регионального дилера шесть юридических лиц и несколько сотрудников с личными учётными записями: команда снабжения увидит новые цены при следующем открытии каталога.
Свежесть здесь измеряется секундами: очередь выгрузок из 1С сайт проверяет каждые ~10 секунд.
Как это устроено внутри
Общая картина - на схеме: тариф нигде не хранится "у пользователя", он вычисляется цепочкой справочников, каждый из которых приходит из 1С.
| Решение | Как сделано |
|---|---|
| Подбор компании | Поиск по ИНН среди более чем 11 тысяч контрагентов прямым запросом к справочнику, в момент отправки формы. Вкладка предпринимателя ищет среди контрагентов-физических лиц: так предприниматель заведён в 1С |
| Расчёт тарифа | Цепочка из трёх справочников: юридическое лицо → компания-владелец → тип клиента. Тариф - свойство компании, поэтому все её юридические лица получают один тип |
| Заявка на подключение | Обычный элемент списка в панели управления: реквизиты, документы, отметка о решении. Отдельного интерфейса модерации нет - модератор работает в штатной административной панели |
| Перенос решения | Сохранение элемента списка запускает перенос 14 полей в профиль покупателя: контрагент, тип клиента, реквизиты, права на просмотр заказов коллег и оформление на другие юридические лица |
| Приоритет расчёта | После переноса полей тип клиента пересчитывается по цепочке заново и перекрывает значение из формы; свойство самой заявки при этом тоже приводится к расчётному |
| Права доступа | Два поля профиля: отметка о подключении (можно ли оформлять заказ) и тип клиента (по какой цене). Группы пользователей платформы не участвуют |
| Розничная видимость | Не отдельная ветка и не отдельный шаблон: у неодобренного покупателя личный тип клиента просто не запрашивается, вместо него подставляется розничный |
| Обратная волна | Смена тарифа компании в 1С перехватывается на сохранении справочника: обратным обходом находятся все её юридические лица и все их пользователи, тип обновляется каждому |
| Новые типы клиента | Создаются обработчиком обмена сами: тип, появившийся в 1С, возникает в справочнике сайта и подключается к ценовой матрице без участия разработчика |
| Дооформление заказов | При одобрении заказы последних дней получают привязку к юридическому лицу и идентификатор компании из 1С, после чего помечаются к передаче в учётную систему |
Почему расчёт намеренно затирает то, что ввёл человек. Обычно ручной ввод считается приоритетнее автоматики - оператор ведь видит ситуацию. Здесь наоборот: сначала тип клиента из формы попадает в набор для сохранения, а следом пересчитывается по цепочке и перекрывается. Причина в том, что у коммерческой политики один источник истины, и это 1С. Поле в заявке - не решение, а отражение; если бы оно могло победить расчёт, у компании появились бы два источника тарифа, и рано или поздно они бы разошлись. Именно поэтому ошибка оператора при назначении тарифа технически невозможна: назначать нечего.
Почему не группы пользователей. Штатный путь платформы для разграничения доступа - группы и матрица прав. Девятнадцать тарифов означали бы девятнадцать групп и матрицу прав на каждый справочник, которую нужно поддерживать вручную и синхронизировать с 1С. Вместо этого доступ решают два поля профиля, а число тарифов ни на что не влияет: их может стать двадцать пять - код не изменится.
Что это дало бизнесу
| Раньше | Стало |
|---|---|
| Реквизиты нового клиента диктовались по телефону и вводились руками | Клиент вводит один ИНН - компания узнаётся в справочнике из 1С |
| Оператор искал компанию в 1С и назначал тариф вручную | Тариф вычисляется цепочкой "юридическое лицо - компания - тип клиента": назначать нечего |
| Ошибку в тарифе первым находил клиент | Расчёт перекрывает ручной ввод даже у модератора; последнее слово всегда за 1С |
| Смена условий дилера - обход всех его сотрудников вручную | Условия меняются в 1С - новый тариф получает вся команда клиента одним проходом |
| Закрытые цены берегла внимательность оператора | До одобрения дилерских цен не существует: их не прячут - их не рассчитывают |
| Подключение занимало дни | Подключение занимает минуту и одну отметку модератора |
В цифрах
| Показатель | Значение |
|---|---|
| Контрагентов в справочнике сайта | более 11 тысяч - весь справочник приходит выгрузкой из 1С |
| Из них компаний и предпринимателей | 6 210 - их и находит поиск по ИНН |
| Типов клиента | 19, из них 11 - дилерские ступени |
| Правил ценовой матрицы | 741 - 19 типов клиента на 13 категорий товара |
| Полей профиля, заполняемых одной отметкой модератора | 14 |
| Контрагентов со связью "юридическое лицо - компания" | 100% - тариф вычислим для любого клиента базы |
| Подхват выгрузок из 1С | очередь проверяется каждые ~10 секунд |
| Разброс цены одного товара по типам клиента | примерно от 7 700 до 10 250 ₽ (пример из рабочего каталога) |
Подключение оптовиков - часть большой B2B-платформы: каталог, дилерский кабинет и двусторонний обмен с 1С. Что вошло в проект целиком - в кейсе B2B e-commerce платформы.
