ТЗ на B2B-портал: роли, договорные цены и согласование заказа

Почему B2B-портал требует отдельного ТЗ

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

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

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

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

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

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

Договорные цены и доступный ассортимент

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

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

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

Заказ и маршрут согласования

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

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

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

Остатки, отгрузки и документы

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

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

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

Интеграции и эксплуатация

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

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

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

Приёмка на двух организациях

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

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

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

Состав первой очереди и оценка

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

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