Первый этап лучше выбирать не по числу экранов, а по действию, которое клиент сможет завершить. Для этого нужно связать интерфейс, данные из учётной системы и работу ответственного сотрудника. Не обязательно переносить в кабинет все функции компании.
Один путь: войти, найти заказ, получить документ, задать вопрос
Разберём условный кабинет поставщика для корпоративных покупателей. Представитель клиента входит от своей организации, находит её заказ, проверяет статус, скачивает доступный документ и при необходимости задаёт вопрос менеджеру по этому заказу.
Такой путь полезен сам по себе: клиент получает сведения по своей покупке, а вопрос приходит с понятным контекстом. Но завершить его нельзя, если документ не связан с заказом, организация пользователя не определена или обращение не получает ответственного.
До проектирования стоит пройти этот сценарий вместе с клиентским менеджером. Где он сейчас берёт сведения? Какие статусы вправе сообщать? Какой документ можно отдать клиенту? Что он делает, если запись ещё не появилась в учёте? Ответы определяют состав первого этапа точнее, чем пожелание «сделать удобный портал».
Что включить в первый рабочий этап
В таблице — пример состава, а не обязательная комплектация любого кабинета. Источники и критерии должны соответствовать реальным правилам компании.
| Функция | Результат для участника | Источник | Критерий приёмки |
|---|---|---|---|
| Вход и выбор организации | Человек работает от разрешённой компании | Учётные записи и подтверждённые связи пользователя с организацией | После выбора компании доступны только её разрешённые данные |
| Список и карточка заказа | Клиент находит свою покупку и видит её состояние | Заказ и его статус в 1С | Состав и статус совпадают с контрольной записью в учёте |
| Документ заказа | Клиент получает относящийся к заказу файл | Документ, связанный с заказом в учётной системе | Открывается нужный файл; чужой документ недоступен |
| Вопрос менеджеру | Обращение сохраняет связь с заказом | Текст клиента, номер заказа и назначенный получатель | Менеджер видит обращение по нужному заказу, клиент — факт его получения |
| Новая заявка | Клиент передаёт пожелания, не выдавая их за принятый заказ | Данные, введённые в кабинете | Заявка зарегистрирована один раз и явно ожидает решения сотрудника |
Для такого этапа можно отложить рекомендации товаров, сложные бонусные правила или самостоятельное управление всеми договорами. Нельзя отложить проверку организации, если без неё клиент увидит чужой заказ. Нельзя убрать обработку недоступного документа, если получение документа — заявленный результат.
Полезный способ проверить границу — пройти путь целиком без устных подсказок разработчика. Если после третьего шага всё равно приходится искать сведения вручную в другом месте, нужно решить: это согласованное действие сотрудника или незавершённая часть кабинета.
Кто владеет данными
Не стоит делать кабинет второй независимой учётной системой. Для каждого значения определяют место изменения и источник подтверждения. Ниже — учебное распределение ответственности.
| Данные | Где создаются или изменяются | Что делает кабинет |
|---|---|---|
| Связь человека с компанией | Подтверждает назначенный администратор по правилам доступа | Показывает только разрешённые организации |
| Новая заявка | Клиент вводит состав в кабинете | Сохраняет заявку и передаёт её на обработку |
| Принятый заказ и условия | Ответственный сотрудник подтверждает в 1С | Получает подтверждённые сведения, не рассчитывает их заново |
| Статус выполнения | Меняется в учётной системе по фактическому событию | Показывает полученный статус и момент его обновления |
| Документ | Формируется в установленном учётном процессе | Предоставляет разрешённую версию по связи с заказом |
| Вопрос по заказу | Пишет клиент, обрабатывает менеджер | Сохраняет контекст обращения и доступное клиенту состояние обработки |
В этой схеме заявка и заказ — разные состояния. Сообщение «Заявка получена» не подтверждает наличие товара, цену или дату отгрузки. Подтверждение появляется только после предусмотренного решения сотрудника. Надпись на экране должна отражать именно это событие.
Человек не равен организации
Один сотрудник может представлять несколько компаний. Организация, выбранная на экране, ещё не доказывает право на её документы: связь нужно проверять при обращении к данным. Право видеть заказ также не означает право менять его состав или выгружать все документы компании.
Начальная матрица должна определить хотя бы просмотр, изменение черновика, получение документов и обращение к менеджеру. Подробную матрицу прав стоит согласовать до реализации. Общий ориентир OWASP по авторизации — выдавать необходимые полномочия и проверять их при каждом запросе. В кабинете это относится и к прямому скачиванию файла, а не только к видимым кнопкам.
Что показывать, пока обмен не завершён
Если обновление статуса задержалось, прежнее значение нельзя молча выдавать за только что проверенное. В условном интерфейсе можно показать последний полученный статус и время обновления, а рядом — пояснение, что новых сведений пока нет. Допустимую задержку определяет процесс: для ознакомления с историей и подтверждения новой отгрузки условия могут различаться.
При недоступном обмене клиенту нужен понятный выбор. Например, посмотреть сохранённую историю или задать вопрос менеджеру. Если сервер не подтвердил приём новой заявки, интерфейс сообщает именно об отсутствии подтверждения, а не предлагает создать ещё одну покупку. Менеджер проверяет, появилась ли операция в принимающей системе, прежде чем запускать повтор.
Повторное действие должно оставаться связанным с той же заявкой. Изменение её состава — отдельная операция по согласованным правилам. После восстановления связи проверяют не только исчезновение сообщения об ошибке, но и соответствие заказа, статуса и документа.
Граница внешнего обмена с 1С
Возможность подключения зависит от конфигурации, версии, размещения и доступных интерфейсов. Документация 1С об HTTP-сервисах описывает обработку запросов по шаблонам URL и методам и формирование ответа. Это механизм платформы, а не готовая интеграция для каждой базы.
АИС Сокол разрабатывает кабинет и внешний обмен. Разработка и доработка внутренней конфигурации 1С в эту услугу не входят; необходимые действия согласуются с ответственным специалистом 1С. Границы такого участка описаны в услуге Внешний обмен с учётной системой, а подготовка — в материале Выбор и проверка обмена с 1С.
Как принять первый сценарий
Подготовьте тестовую организацию, её заказ и документ, а также отдельную организацию, данные которой этому пользователю недоступны. Клиент должен войти, найти свой заказ, получить правильный файл и отправить вопрос назначенному менеджеру. Проверяющий сопоставляет результат с учётом, а не только с макетом экрана.
Затем проходят исключения: попытку открыть чужой документ, повтор отправки заявки, получение устаревшего статуса и недоступность обмена. Для каждого случая заранее записывают ожидаемый экран, состояние записи и действие ответственного. Проверки выполняют в согласованной среде, без обращения к чужим рабочим данным.
Результатом этапа становится этот путь вместе с правилами данных, проверками и инструкцией разбора ошибок. До начала работ определяют состав и стоимость; наличие 1С само по себе ещё не задаёт объём проекта.
По теме: Роли и права на документы.
Опишите, что клиент должен сделать от входа до получения результата, какие документы ему нужны и где сейчас находятся эти сведения.
