Чем дилерский кабинет отличается от обычного клиентского

Начните с операции дилера

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

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

Разведите человека и организацию

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

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

Карта функций и источников

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

Определите права на действия

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

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

Согласуйте условия заказа

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

Разведите запрос заказа и подтверждённое обязательство поставки. Если менеджер проверяет доступность вручную, это часть сценария. Интерфейс должен говорить «заказ передан на подтверждение», когда именно такой процесс реализован.

Подготовьте интеграции и исключения

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

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

Проведите пилот на разных ролях

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

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

Пример пилота с двумя дилерами

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

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

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

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

Как проверить персональную цену дилера после изменения договора

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

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