За оптовым покупателем редко стоит одна компания. Автосервисная сеть закупает оборудование на пять юридических лиц и двух предпринимателей: у каждого свой расчётный счёт, своя бухгалтерия, свои основания для поставки. Решение о закупке принимает один человек - снабженец, который утром оформляет партию на одно ООО, а после обеда - на другое.
Типовой интернет-магазин такого покупателя не понимает. Он считает, что за учётной записью стоит ровно одно юридическое лицо, и предлагает завести отдельную запись на каждую компанию.
Сайт должен повторять реальную структуру клиента: одна учётная запись, все компании группы, единые условия закупки и понятная руководителю картина.
Почему типовой магазин этого не умеет
- →Пять паролей на одного снабженца. Чтобы купить от нужной компании, приходится выходить и входить заново - под отдельной учётной записью каждого ООО.
- →Условия расходятся. Скидку приходится заводить на каждое юридическое лицо отдельно - и со временем у компаний одной группы оказываются разные условия.
- →Руководитель не видит закупку. Он хочет знать, что и на какие суммы закупают его сотрудники, но каждый видит только собственные заказы - сводку руководитель собирает по телефону.
Решение
Один вход - все компании группы
Вот реальный покупатель рабочего каталога - региональная группа компаний. Один вход, семь юридических лиц.
Снабженец выбирает компанию одним нажатием, и она подставляется в заказ сама. Выбор сохраняется в учётной записи, а не в текущем сеансе: он остаётся в силе после выхода и доступен с любого устройства. Подставить чужую компанию нельзя - сайт проверяет каждый выбор по списку юридических лиц, закреплённых за этим клиентом в 1С.
Пять обществ с ограниченной ответственностью и два предпринимателя - и все они принадлежат одному партнёру, то есть одной группе компаний в учётной системе. Отсюда и вырастает всё решение.
Условия - на группу, документы - на юридическое лицо
Договариваются с группой целиком, а не с каждым ООО по отдельности. Поэтому сегмент покупателя и его персональные цены наследуются от партнёра и едины для всех компаний группы: снабженец видит одну и ту же цену независимо от того, от чьего имени он сейчас покупает. Разойтись по компаниям условия не могут - источник у них один.
Бухгалтерии же нужно обратное: чтобы поставка прошла по конкретному юридическому лицу с его реквизитами. Поэтому выбор компании меняет документы - счёт и заказ - но не цену.
Выбранная компания доходит до учётной системы: заказ уходит в 1С с указанием юридического лица, счёт выставляется на нужную компанию и возвращается в кабинет готовым документом. Реквизиты для счёта - ИНН, КПП, расчётный счёт, банк, БИК - приходят из 1С, и на сайте их не вводят вручную.
Если компания появилась в группе недавно и заказы успели оформить до того, как её подключили, они не остаются без юридического лица: сайт дополняет их сам и передаёт в 1С заново.
Руководитель видит закупку всей группы
Рядовой снабженец видит свои заказы - по всем компаниям группы сразу. Руководителю открывается закупка всей группы, и в списке появляется колонка "Менеджер": кто именно оформил каждый заказ.
Круг сотрудников определяется не так, как можно ожидать. Сайт не ведёт штатное расписание и не требует заносить туда людей: руководителю видны заказы всех, кто покупал на юридические лица его группы, а список собирается из самих заказов в момент открытия страницы. Новый сотрудник появляется в отчёте руководителя сам - как только оформит первый заказ на компанию группы.
Правила складываются: роль руководителя расширяет круг сотрудников, а точечная настройка добавляет отдельных коллег, если доступ нужно дать вне структуры группы. Заказы, заведённые в 1С напрямую, в кабинет не попадают - клиент видит собственную закупку через сайт.
Кому это нужно
Несколько юридических лиц закреплено примерно за каждым шестым оптовым клиентом - и ни за одним розничным. Это потребность только оптового покупателя: исключений в данных нет. Чаще всего у такого клиента две-три компании, максимум - семь под одним входом.
Причём почти все такие клиенты - настоящие группы компаний: их юридические лица принадлежат одному партнёру, а не собраны случайно. Модель "партнёр - юридические лица - сотрудники" повторяет реальную организацию оптовой торговли.
Как это устроено внутри
| Решение | Как сделано |
|---|---|
| Несколько компаний на одной учётной записи | Основное юридическое лицо плюс список дополнительных - оба поля ссылаются на справочник компаний из 1С. Список доступных собирается объединением обоих полей, повторы отбрасываются: клиент видит ровно свои компании, каждую по одному разу |
| Текущая компания | Отдельное поле учётной записи, а не признак сеанса: выбор остаётся в силе после выхода и общий для всех устройств. Сохраняется, только если компания есть в списке доступных клиенту |
| Подстановка в заказ | Приоритет: выбор в форме заказа, затем сохранённый выбор клиента, затем первая доступная компания. На каждом шаге - проверка принадлежности клиенту |
| Счёт | В заказ записывается компания и её код для 1С. Реквизиты в документ с сайта не переносятся: счёт формирует 1С и возвращает готовым файлом в кабинет |
| Заказы задним числом | Если компанию подключили после оформления заказов, они дополняются ссылкой на юридическое лицо за последнюю неделю и помечаются к передаче в 1С - без ручного вмешательства |
| Сегмент покупателя | Цепочка "компания - партнёр - тип клиента" разворачивается в поле учётной записи при одобрении заявки. Сменился тип у партнёра - он переписывается всем его пользователям автоматически |
| Видимость заказов | Круг сотрудников вычисляется из заказов на компании группы, а не из списка людей. Список собирается заново при каждом открытии страницы |
| Отбор списка | Фильтрация идёт по авторам заказов; заказы, заведённые в учётной системе, отсекаются отдельным признаком - в кабинете остаётся только закупка через сайт |
Почему список сотрудников не хранится, а вычисляется. Это решение обычно вызывает вопросы у коллег: вести штатное расписание кажется очевидным.
Хранить список сотрудников: завести на сайте штатное расписание и поддерживать его - заводить закупщиков, удалять уволенных, следить за расхождением с реальностью.
Вычислять из заказов: кто оформлял закупку на компании группы, тот и сотрудник. Список собирается в момент открытия страницы и не может устареть, потому что не хранится.
Почему отбор строится по юридическому лицу, а не по автору заказа. Штатный личный кабинет платформы показывает заказы строго их владельцу, и параметрами компонента это не меняется. Чтобы руководитель увидел чужие заказы, отбор пришлось строить по свойству заказа - юридическому лицу - а не по его автору.
Что это дало бизнесу
| Раньше | Стало |
|---|---|
| На каждую компанию группы - своя учётная запись | Один вход - все компании группы, до семи у клиента |
| Закупка от другой компании - выход и вход заново | Компания выбирается одним нажатием, и выбор запоминается |
| Реквизиты для счёта диктуют менеджеру по телефону | Счёт выставляется на выбранную компанию, реквизиты приходят из 1С |
| Отчёт о закупке руководитель просит у сотрудников | Руководителю видна закупка всей группы - с колонкой "Менеджер" |
| Скидку заводят на каждое ООО отдельно - условия расходятся | Условия согласованы с группой целиком - цена одна для всех её компаний |
| Новая компания группы - регистрация с нуля | Новая компания приходит выгрузкой из 1С и сама встаёт в кабинет |
В цифрах
| Показатель | Значение |
|---|---|
| Компаний в справочнике юридических лиц из 1С | 11 521 |
| Партнёров в справочнике | 11 672 |
| Юридических лиц у одного клиента | до 7 под одним входом |
| Оптовых клиентов с несколькими юридическими лицами | примерно каждый шестой |
| Розничных покупателей с несколькими компаниями | ни одного |
| Сегментов покупателей | 19; сегмент наследуется от партнёра |
| Компаний, привязанных к партнёру | 100% - условия ведутся на группу целиком |
| Покупка от другой компании группы | одно нажатие, без выхода из учётной записи |
Личный кабинет - часть большой B2B-платформы: каталог, дилерский кабинет и двусторонний обмен с 1С. Что вошло в проект целиком - в кейсе B2B e-commerce платформы.
