Кабинет дилера: требования к ролям, ценам, заказам и документам

С чего начинается ТЗ на кабинет дилера

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

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

Опишите организацию, договор и пользователя

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

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

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

Установите источник коммерческих условий

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

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

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

Согласуйте доступность и резервирование

Остаток на складе, доступный к обещанию объём и резерв — разные состояния. Опишите, что именно видит дилер, по каким складам и с какой задержкой. Значение «есть» не определяет срок отгрузки. Если доступность приблизительная, это нужно показывать понятным способом.

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

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

Опишите жизненный цикл заказа

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

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

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

Документы и интеграции

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

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

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

Приёмочные примеры до разработки

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

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

Отдельно проверьте мобильное использование и длинные заказы: поиск артикула, изменение количества, ошибки строк и сохранение при обрыве связи. Красивый пустой кабинет не показывает, как система ведёт себя на реальных рабочих данных.

Состав брифа для оценки

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

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