Как спроектировать персональные цены, роли и документы в B2B

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

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

Поэтому B2B-платформу недостаточно спроектировать как интернет-магазин с авторизацией и персональной ценой. Нужно описать модель отношений между компаниями, пользователями, договорами, ценами, полномочиями и документами. И сделать это желательно до разработки интерфейсов.

Начинать нужно не с пользователей, а с организаций

В B2C аккаунт обычно соответствует конкретному человеку. В B2B покупателем чаще является организация, а уже внутри неё работают пользователи.

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

Поэтому модель вида "пользователь → личный кабинет" быстро становится слишком простой.

Чаще появляется структура "организация → юридическое лицо → договор → пользователи → роли и полномочия".

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

Персональная цена редко хранится одним числом

Требование «показывать клиентам персональные цены» звучит просто, пока не начинается разбор правил ценообразования.

Цена может зависеть от:

• контрагента;
• договора;
• типа клиента;
• группы товаров;
• количества;
• региона;
• склада;
• валюты;
• условий оплаты;
• накопленной скидки;
• текущей акции;
• индивидуальной договорённости.

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

Без этого «персональные цены» остаются не функцией, а названием целого набора неизвестных правил.

Сначала определить источник цены

Одна из частых архитектурных ошибок — начать реализовывать ценообразование непосредственно на сайте, хотя бизнес-правила уже существуют в ERP.

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

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

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

Цена в каталоге и цена заказа — не всегда одно и то же

Дополнительная сложность появляется, если условия могут измениться между просмотром товара и оформлением заказа. Пользователь увидел цену утром, положил товар в корзину, а вечером изменился прайс или закончился период действия скидки.

Нужно заранее определить правила:

• фиксируется ли цена при добавлении в корзину;
• пересчитывается ли при оформлении;
• может ли измениться после отправки заказа;
• что видит пользователь, если цена изменилась;
• требуется ли дополнительное согласование.

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

Роли лучше проектировать через действия

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

• смотреть каталог;
• видеть персональные цены;
• видеть остатки;
• создавать заказ;
• редактировать заказ;
• отправлять на согласование;
• подтверждать заказ;
• отменять заказ;
• видеть заказы других сотрудников;
• скачивать документы;
• видеть взаиморасчёты;
• добавлять пользователей;
• назначать им права;
• переключаться между юридическими лицами.

После этого действия можно объединять в роли. Например, закупщик создаёт заказ, но не подтверждает его. Руководитель видит заказы подразделения и согласует суммы выше установленного лимита. Бухгалтер имеет доступ к счетам и закрывающим документам, но не работает с каталогом.

Так роли начинают отражать реальный процесс, а не условные названия в административной панели.

Одной роли иногда недостаточно

В сложных B2B-системах права зависят не только от того, что пользователь может делать, но и от того, с какими объектами.

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

Поэтому модель доступа иногда состоит из нескольких измерений: действие + область доступа + ограничения.

Например, пользователь может подтверждать заказы своего юридического лица до 500 000 рублей. Это уже не простая галочка «может подтверждать заказ». Такие правила лучше обнаружить на этапе обследования, потому что они влияют и на архитектуру прав, и на интерфейс.

Нужно продумать, кто управляет пользователями клиента

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

Может ли администратор дать другому сотруднику больше прав, чем имеет сам? Кто получает доступ к финансовым документам? Что происходит, когда сотрудник увольняется? Можно ли самостоятельно добавить пользователя с правом подтверждать крупные заказы?

Часть полномочий может управляться самим клиентом, а наиболее чувствительные — требовать подтверждения поставщика. Главное — определить эту границу заранее.

Согласование заказа — отдельный бизнес-процесс

В B2C кнопка «Оформить заказ» обычно завершает действия покупателя. В B2B после неё процесс внутри организации клиента может только начинаться.

Например, закупщик формирует заказ → руководитель согласует → бухгалтер подтверждает условия оплаты → заказ передаётся поставщику. Схема может зависеть от суммы, категории товаров, подразделения или договора.

При проектировании важно определить:

• кому отправляется заказ;
• кто может его изменить;
• что происходит после изменения;
• сколько уровней согласования возможно;
• можно ли отклонить заказ;
• можно ли вернуть его на доработку;
• кто получает уведомления;
• в какой момент заказ передаётся в ERP.

Если сначала реализовать обычную корзину, а согласования добавить позже, может потребоваться существенно менять модель статусов и бизнес-логику.

Статусы должны быть понятны обеим сторонам

У поставщика и покупателя может быть разное представление о жизненном цикле заказа. В ERP существуют внутренние статусы: создан, проверен, зарезервирован, передан на склад, частично отгружен. Клиенту не обязательно видеть каждый технический этап.

Одновременно в B2B-портале могут существовать собственные состояния: черновик, ожидает согласования внутри компании, отклонён, готов к отправке поставщику.

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

Документы связаны с заказом, договором и юридическим лицом

Раздел «Документы» тоже редко оказывается просто папкой с PDF. В B2B-платформе могут быть:

• счета;
• договоры;
• спецификации;
• накладные;
• акты;
• УПД;
• счета-фактуры;
• сертификаты;
• акты сверки;
• другие документы.

Для каждого типа нужно определить источник, момент появления и правила доступа. Например, счёт относится к конкретному заказу и юридическому лицу. Акт сверки — к контрагенту и периоду. Сертификат — к товару или партии.

Если документы просто складываются в общий список, при большом объёме пользоваться им быстро становится неудобно. Поэтому документы лучше проектировать как часть соответствующих бизнес-сущностей, а не как отдельное файловое хранилище.

Нужно определить источник документов

Документ может формироваться в ERP, системе электронного документооборота или непосредственно на платформе. Если источников несколько, важно заранее определить маршрут.

Например: заказ создаётся на B2B-платформе → передаётся в ERP → ERP формирует счёт → счёт возвращается в личный кабинет.

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

Документ должен быть доступен правильному пользователю

Права на документы могут отличаться от прав на заказ. Например, закупщик видит состав и статус заказа, но финансовые документы доступны только бухгалтеру. Руководитель может видеть документы всех подразделений, а сотрудник филиала — только своего.

Кроме роли могут учитываться:

• юридическое лицо;
• договор;
• подразделение;
• заказ;
• период;
• тип документа.

Поэтому модель доступа к документам должна опираться на те же организационные связи, что и остальные функции личного кабинета. Простая проверка «пользователь авторизован» для B2B здесь недостаточна.

Несколько юридических лиц усложняют интерфейс

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

Можно предложить пользователю сначала выбрать организацию, а затем показывать данные только для неё. В другом проекте переключатель юрлица доступен непосредственно внутри кабинета.

Важно не столько конкретное решение интерфейса, сколько отсутствие неоднозначности: пользователь должен понимать, от имени какой организации он сейчас действует. Ошибка здесь может привести не просто к неудобству, а к заказу или документу, оформленному на неправильное юридическое лицо.

Персональный ассортимент — продолжение той же модели

Цена может быть не единственным персональным условием. Одним клиентам доступен весь каталог, другим — только определённые бренды или категории. Часть товаров продаётся только по конкретным договорам. Где-то существуют индивидуальные артикулы или ассортиментные матрицы.

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

• каталог;
• поиск;
• рекомендации;
• аналоги;
• корзину;
• импорт товаров;
• индексацию поиска.

Добавить такую логику в конце проекта намного сложнее, чем заложить её в модель данных заранее.

Нужно определить поведение при недоступности ERP

Чем больше персональных условий рассчитывается во внутренних системах, тем сильнее B2B-платформа от них зависит.

Что увидит пользователь, если ERP временно недоступна? Можно ли показать последнюю известную цену? Разрешено ли собрать корзину? Можно ли отправить заказ в очередь и передать его позже? Или оформление нужно временно заблокировать?

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

Важные действия нужно журналировать

В корпоративной системе часто необходимо понимать не только текущее состояние объекта, но и историю изменений. Кто изменил состав заказа? Кто его согласовал? Когда поменялось юридическое лицо? Кто выдал пользователю дополнительное право? Какой документ был доступен на конкретную дату?

Поэтому для значимых операций стоит определить требования к журналированию.

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

Интерфейс появляется после модели отношений

Если начать проектирование B2B-платформы с макетов, очень легко получить красивый личный кабинет, который работает только для простого сценария: один пользователь → одна компания → одна цена → один договор → один заказ.

Поэтому сначала полезно собрать модель на уровне сущностей и правил.

Например:

Область	Что нужно определить
Организации	Контрагенты, юрлица, подразделения и связи между ними
Пользователи	Кто может работать от имени каждой организации
Роли	Какие действия доступны пользователям
Ограничения	Для каких объектов, сумм и подразделений действуют права
Договоры	Как договор связан с юрлицом, ценой и заказом
Цены	Где рассчитываются и какие условия на них влияют
Ассортимент	Одинаков ли каталог для разных клиентов
Заказы	Кто создаёт, редактирует и согласует
Статусы	Как сопоставляются процессы клиента и поставщика
Документы	Где формируются, к чему относятся и кто их видит
Интеграции	Какие данные приходят из ERP, CRM, ЭДО и других систем
Отказы	Что происходит при недоступности внешних систем
Аудит	Какие действия и изменения нужно сохранять

После этого гораздо проще проектировать экраны: уже понятно, какие данные и действия они должны поддерживать.

Не нужно переносить в личный кабинет всю ERP

При проектировании B2B-платформы возникает ещё одна крайность: попытка показать клиенту практически всё, что существует во внутренних системах компании. Но задачи клиента и сотрудника поставщика различаются.

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

Хорошая B2B-модель должна выдерживать рост сложности

На старте у компании может быть один тип клиентов и три роли. Через год появятся дилеры, несколько схем договоров, дополнительное согласование и новые документы. Предусмотреть абсолютно все будущие сценарии невозможно. Но можно не зашивать текущие правила слишком жёстко.

Например, если права строятся на наборе действий, новую роль проще собрать из существующих разрешений. Если цена связана с понятным источником и набором условий, проще добавить ещё одну схему ценообразования. Если документы привязаны к бизнес-сущностям, новый тип не требует перестраивать весь раздел.

Это не означает, что систему нужно заранее делать универсальной платформой на все случаи жизни. Задача — выбрать модель, которая соответствует сегодняшнему бизнесу и не превращает каждое естественное развитие в переделку ядра.

Персональные цены, роли и документы в B2B тесно связаны между собой. Цена зависит от того, от имени какой компании действует пользователь. Его роль определяет, может ли он оформить и согласовать заказ. Договор влияет на коммерческие условия. Документы появляются в результате этого процесса и должны быть доступны только тем, кто имеет соответствующие права.

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