Expand technical specification content
This commit is contained in:
Ruslan Bakiev
@@ -1,34 +1,32 @@
|
||||
import { defineConfig } from 'vitepress';
|
||||
|
||||
export default defineConfig({
|
||||
title: 'Фрегат ЛК',
|
||||
title: 'Техническое задание',
|
||||
description: 'Техническое задание на разработку личного кабинета Фрегат',
|
||||
lang: 'ru-RU',
|
||||
cleanUrls: true,
|
||||
themeConfig: {
|
||||
nav: [
|
||||
{ text: 'ТЗ', link: '/tz/' },
|
||||
{ text: 'Этап 1', link: '/tz/stage-1/' },
|
||||
{ text: 'Текущее состояние', link: '/appendix/current-state' },
|
||||
{ text: 'Техническое задание', link: '/' },
|
||||
],
|
||||
sidebar: [
|
||||
{
|
||||
text: 'Техническое задание',
|
||||
items: [
|
||||
{ text: 'Обзор', link: '/tz/' },
|
||||
{ text: 'Нормативная база', link: '/tz/normative-base' },
|
||||
{ text: 'Контур продукта', link: '/tz/product-scope' },
|
||||
{ text: 'Роли и доступ', link: '/tz/roles-access' },
|
||||
{ text: 'Функциональные требования', link: '/tz/functional-requirements' },
|
||||
{ text: 'Данные и интеграции', link: '/tz/data-integrations' },
|
||||
{ text: 'Этап 1 (UX/UI)', link: '/tz/stage-1/' },
|
||||
{ text: 'Приемка и артефакты', link: '/tz/acceptance' },
|
||||
{ text: '0. Общие положения', link: '/' },
|
||||
{ text: '1. Основания и нормативная база', link: '/tz/normative-base' },
|
||||
{ text: '2. Назначение и границы продукта', link: '/tz/product-scope' },
|
||||
{ text: '3. Роли и права доступа', link: '/tz/roles-access' },
|
||||
{ text: '4. Функциональные требования', link: '/tz/functional-requirements' },
|
||||
{ text: '5. Данные и интеграции', link: '/tz/data-integrations' },
|
||||
{ text: '6. Экранные формы и текстовые прототипы', link: '/tz/stage-1/' },
|
||||
{ text: '7. Приемка и состав артефактов', link: '/tz/acceptance' },
|
||||
],
|
||||
},
|
||||
{
|
||||
text: 'Приложения',
|
||||
items: [
|
||||
{ text: 'Текущее состояние продукта', link: '/appendix/current-state' },
|
||||
{ text: 'А. Текущее состояние продукта', link: '/appendix/current-state' },
|
||||
],
|
||||
},
|
||||
],
|
||||
|
||||
127
docs/index.md
127
docs/index.md
@@ -1,34 +1,103 @@
|
||||
---
|
||||
layout: home
|
||||
# Техническое задание на разработку программного продукта
|
||||
|
||||
hero:
|
||||
name: "Личный кабинет Фрегат"
|
||||
text: "Подробное техническое задание"
|
||||
tagline: "Черновой пакет документов по договору №28/04-26ПО от 28 апреля 2026 года"
|
||||
actions:
|
||||
- theme: brand
|
||||
text: Открыть ТЗ
|
||||
link: /tz/
|
||||
- theme: alt
|
||||
text: Этап 1
|
||||
link: /tz/stage-1/
|
||||
## 0. Общие положения
|
||||
|
||||
features:
|
||||
- title: По договору и спецификации
|
||||
details: Структура документа собрана на основании договора, приложения со спецификацией и текущей реализации продукта.
|
||||
- title: По ГОСТ-логике
|
||||
details: Каркас построен по логике ГОСТ 19.201-78, но адаптирован под современный B2B веб-продукт.
|
||||
- title: Из кода, а не из фантазий
|
||||
details: В документ вынесены реальные роли, разделы, сценарии и сущности, которые уже заложены в продукте.
|
||||
---
|
||||
Наименование программного продукта: `Личный кабинет Фрегат`.
|
||||
|
||||
Этот пакет нужен как основа для согласования полного ТЗ и отдельного первого этапа. В текущей версии мы фиксируем:
|
||||
Заказчик: ООО `Фрегат Групп`.
|
||||
|
||||
- рамки продукта
|
||||
- состав ролей и интерфейсов
|
||||
- сценарии клиента и менеджера
|
||||
- требования к данным и интеграциям
|
||||
- границы этапа 1 по UX/UI
|
||||
- состав итоговых артефактов и приемки
|
||||
Основания для разработки:
|
||||
|
||||
Рекомендуемый следующий шаг: пройти разделы `/tz/` сверху вниз, внести уточнения по спорным бизнес-правилам и после этого выпускать согласованную редакцию.
|
||||
- договор на разработку программного продукта №28/04-26ПО от 28 апреля 2026 года
|
||||
- приложение №1 к договору: спецификация основных требований к программному обеспечению `Личный кабинет Фрегат`
|
||||
- текущая реализованная кодовая база клиентской и серверной части
|
||||
|
||||
Настоящее техническое задание определяет:
|
||||
|
||||
- назначение программного продукта
|
||||
- состав и границы системы
|
||||
- состав ролей и прав доступа
|
||||
- функциональные и информационные требования
|
||||
- требования к интеграциям
|
||||
- требования к интерфейсным формам
|
||||
- порядок приемки и состав передаваемых материалов
|
||||
|
||||
## Содержание
|
||||
|
||||
1. [Основания и нормативная база](/tz/normative-base)
|
||||
2. [Назначение и границы продукта](/tz/product-scope)
|
||||
3. [Роли и права доступа](/tz/roles-access)
|
||||
4. [Функциональные требования](/tz/functional-requirements)
|
||||
5. [Данные и интеграции](/tz/data-integrations)
|
||||
6. [Экранные формы и текстовые прототипы](/tz/stage-1/)
|
||||
7. [Приемка и состав артефактов](/tz/acceptance)
|
||||
8. [Приложение. Текущее состояние продукта](/appendix/current-state)
|
||||
|
||||
## Назначение продукта
|
||||
|
||||
Программный продукт предназначен для автоматизации взаимодействия между клиентами ООО `Фрегат Групп` и сотрудниками компании в части:
|
||||
|
||||
- регистрации и подключения клиентов
|
||||
- выбора готовой продукции
|
||||
- оформления заявок на заказ
|
||||
- оформления заявок на расчет индивидуальной продукции
|
||||
- согласования стоимости и условий доставки
|
||||
- сопровождения заказов по статусам
|
||||
- уведомления клиентов по изменениям
|
||||
- отображения бонусного и реферального контура
|
||||
|
||||
## Ожидаемый результат разработки
|
||||
|
||||
Результатом выполнения работ должен являться развернутый на инфраструктуре заказчика B2B веб-продукт, который:
|
||||
|
||||
- предоставляет отдельный клиентский и менеджерский интерфейс
|
||||
- работает на desktop и mobile
|
||||
- обеспечивает управление заказным контуром без отображения цены до ручной обработки менеджером
|
||||
- обеспечивает хранение и отображение данных по клиентам, товарам, заявкам и заказам
|
||||
- получает и отображает данные из 1С в согласованном объеме
|
||||
- обеспечивает уведомления по email и подключенным мессенджерам
|
||||
- позволяет сопровождать бонусную и реферальную программу
|
||||
|
||||
## Объект автоматизации
|
||||
|
||||
Объектом автоматизации являются процессы взаимодействия с B2B клиентами ООО `Фрегат Групп`, включая:
|
||||
|
||||
- подключение новых клиентов
|
||||
- работу с каталогом готовой продукции
|
||||
- оформление и согласование заявок
|
||||
- сопровождение заказов
|
||||
- информирование клиентов
|
||||
- бонусные и реферальные механики
|
||||
|
||||
## Состав системы
|
||||
|
||||
В состав системы входят:
|
||||
|
||||
- клиентский веб-интерфейс
|
||||
- менеджерский веб-интерфейс
|
||||
- серверная бизнес-логика
|
||||
- хранилище данных
|
||||
- интеграционный слой обмена с 1С
|
||||
- модуль уведомлений
|
||||
- модуль бонусной программы
|
||||
- модуль административных настроек
|
||||
|
||||
## Общие требования к реализации
|
||||
|
||||
Система должна быть реализована как единый программный продукт, в котором:
|
||||
|
||||
- клиент не видит стоимость товара до обработки заявки менеджером
|
||||
- менеджер управляет ценой, доставкой и согласованием
|
||||
- данные по заказам и статусам могут обновляться от внешней системы 1С
|
||||
- доступ к функциям определяется ролью пользователя
|
||||
- действия пользователей журналируются
|
||||
|
||||
## Принцип детализации настоящего ТЗ
|
||||
|
||||
Настоящий документ описывает не абстрактную концепцию, а конкретный состав продукта. Поэтому дальнейшие разделы фиксируют:
|
||||
|
||||
- реальные модули системы
|
||||
- реальные действия клиента и менеджера
|
||||
- реальные данные, подлежащие хранению и отображению
|
||||
- реальные экранные формы и их состав
|
||||
- реальные интеграционные требования
|
||||
|
||||
@@ -1,62 +1,72 @@
|
||||
# Приемка и передаваемые артефакты
|
||||
# 7. Приемка и состав артефактов
|
||||
|
||||
## Этапность приемки
|
||||
## 7.1 Общие положения приемки
|
||||
|
||||
Разработка и приемка продукта выполняются последовательно.
|
||||
Приемка должна подтверждать, что разработанный программный продукт соответствует настоящему техническому заданию, договору и спецификации.
|
||||
|
||||
### Этап 1
|
||||
При приемке должны проверяться:
|
||||
|
||||
Критерий завершения:
|
||||
- функциональность клиентского контура
|
||||
- функциональность менеджерского контура
|
||||
- работа с каталогом
|
||||
- работа с заявками на заказ
|
||||
- работа с заявками на расчет
|
||||
- работа с заказами
|
||||
- работа уведомлений
|
||||
- работа бонусного контура
|
||||
- работа интеграционного обмена в согласованном объеме
|
||||
|
||||
- заказчик согласовал 2-3 сверстанные страницы
|
||||
- подтвержден визуальный подход
|
||||
- подтверждена логика ключевых сценариев
|
||||
## 7.2 Критерии приемки
|
||||
|
||||
### Этап 2
|
||||
Продукт считается соответствующим требованиям, если:
|
||||
|
||||
Критерий завершения:
|
||||
- все обязательные сценарии выполняются
|
||||
- роли и права разграничены корректно
|
||||
- статусы и история изменений отображаются корректно
|
||||
- каталог и остатки отображаются корректно
|
||||
- клиент не видит цену до публикации условий менеджером
|
||||
- менеджер может обрабатывать заявки и публиковать условия
|
||||
- система сохраняет и отображает историю значимых действий
|
||||
|
||||
- реализован весь функционал, описанный в ТЗ, без интеграции с 1С
|
||||
- стороны подтвердили работоспособность сценариев внутри системы
|
||||
## 7.3 Передаваемые артефакты
|
||||
|
||||
### Этап 3
|
||||
|
||||
Критерий завершения:
|
||||
|
||||
- настроен обмен с 1С
|
||||
- подтверждена работоспособность интеграционных сценариев
|
||||
- устранены блокирующие дефекты по интеграции
|
||||
|
||||
## Итоговые артефакты, которые должны быть переданы
|
||||
|
||||
По договору и спецификации в финальном комплекте должны быть:
|
||||
В состав передаваемых материалов должны входить:
|
||||
|
||||
- исходный код всех разработанных компонентов
|
||||
- перечень сторонних модулей и версий
|
||||
- дистрибутивные комплекты и зависимости
|
||||
- схема взаимодействия модулей
|
||||
- схема движения данных
|
||||
- перечень используемых сторонних модулей и их версий
|
||||
- сведения об используемых внешних API
|
||||
- схемы взаимодействия модулей
|
||||
- схемы движения данных
|
||||
- схемы баз данных и связей
|
||||
- описание используемых сторонних API
|
||||
- распределение ролей пользователей
|
||||
- сетевые требования, порты и протоколы
|
||||
- обучающие материалы
|
||||
- исходные графические материалы
|
||||
- схема графического интерфейса
|
||||
- исходные графические и интерфейсные материалы
|
||||
|
||||
## Что нужно зафиксировать в актах приемки по этапам
|
||||
## 7.4 Требования к документации
|
||||
|
||||
В акте или приложении к акту по каждому этапу желательно отдельно перечислять:
|
||||
Документация должна позволять:
|
||||
|
||||
- что именно показывалось заказчику
|
||||
- какие сценарии проверялись
|
||||
- какие замечания были сняты
|
||||
- какие вопросы перенесены на следующий этап
|
||||
- развернуть продукт
|
||||
- сопровождать продукт
|
||||
- понимать архитектуру модулей
|
||||
- понимать состав данных
|
||||
- понимать состав пользовательских ролей
|
||||
- понимать сценарии интеграционного обмена
|
||||
|
||||
## Открытые вопросы перед выпуском финальной редакции ТЗ
|
||||
## 7.5 Требования к фиксации замечаний
|
||||
|
||||
- окончательный перечень страниц первого этапа
|
||||
- полный состав статусов заявок и заказов
|
||||
- формат и объем бонусного контура на первом релизе
|
||||
- обязательные поля клиента и контрагента
|
||||
- формат данных и событий для интеграции с 1С
|
||||
При приемке каждая выявленная проблема должна быть классифицирована по влиянию:
|
||||
|
||||
- блокирующий дефект
|
||||
- критичный дефект
|
||||
- некритичное замечание
|
||||
- пожелание к развитию
|
||||
|
||||
Каждое замечание должно иметь:
|
||||
|
||||
- описание
|
||||
- шаги воспроизведения
|
||||
- ожидаемый результат
|
||||
- фактический результат
|
||||
- статус устранения
|
||||
|
||||
@@ -1,105 +1,167 @@
|
||||
# Данные и интеграции
|
||||
# 5. Данные и интеграции
|
||||
|
||||
## Основные сущности
|
||||
## 5.1 Основные сущности данных
|
||||
|
||||
В текущем ТЗ должны быть формально закреплены следующие сущности:
|
||||
Система должна оперировать следующими основными сущностями:
|
||||
|
||||
- пользователь
|
||||
- роль
|
||||
- контрагент
|
||||
- клиентская заявка на подключение
|
||||
- заявка на подключение
|
||||
- товар
|
||||
- остаток по складу
|
||||
- складской остаток
|
||||
- корзина
|
||||
- заявка на заказ
|
||||
- заявка на расчет
|
||||
- заказ
|
||||
- событие статуса заказа
|
||||
- событие изменения статуса
|
||||
- уведомление
|
||||
- бонусная связь
|
||||
- бонусная транзакция
|
||||
- заявка на вывод
|
||||
- заявка на вывод вознаграждения
|
||||
|
||||
## Минимальный состав данных по ключевым сущностям
|
||||
## 5.2 Обязательные данные по сущностям
|
||||
|
||||
### Пользователь
|
||||
|
||||
Обязательные поля:
|
||||
|
||||
- идентификатор
|
||||
- имя
|
||||
- email
|
||||
- телефон
|
||||
- роль
|
||||
- статус доступа
|
||||
- связанные мессенджеры
|
||||
- привязанный контрагент
|
||||
- статус учетной записи
|
||||
- связанный контрагент
|
||||
- подключенные каналы уведомлений
|
||||
|
||||
### Контрагент
|
||||
|
||||
Обязательные поля:
|
||||
|
||||
- идентификатор
|
||||
- наименование компании
|
||||
- ИНН
|
||||
- КПП
|
||||
- юридический адрес
|
||||
- контактные лица
|
||||
- закрепленный менеджер
|
||||
|
||||
### Товар
|
||||
|
||||
- SKU
|
||||
- наименование
|
||||
- тип товара
|
||||
- параметры товара
|
||||
- флаги кастомизации
|
||||
- остатки по складам
|
||||
|
||||
### Заявка на заказ / расчет
|
||||
Обязательные поля:
|
||||
|
||||
- идентификатор
|
||||
- SKU
|
||||
- наименование
|
||||
- тип продукции
|
||||
- набор параметров
|
||||
- остатки по складам
|
||||
- признаки доступности
|
||||
|
||||
### Заявка на заказ
|
||||
|
||||
Обязательные поля:
|
||||
|
||||
- идентификатор
|
||||
- тип заявки
|
||||
- инициатор
|
||||
- состав позиций или параметры изделия
|
||||
- дата создания
|
||||
- состав позиций
|
||||
- количество
|
||||
- комментарий клиента
|
||||
- статус
|
||||
- история изменений
|
||||
- стоимость после обработки
|
||||
- параметры доставки
|
||||
- закрепленный менеджер
|
||||
- стоимость после обработки
|
||||
- параметры доставки после обработки
|
||||
|
||||
### Заявка на расчет
|
||||
|
||||
Обязательные поля:
|
||||
|
||||
- идентификатор
|
||||
- инициатор
|
||||
- дата создания
|
||||
- параметры изделия
|
||||
- комментарий клиента
|
||||
- статус
|
||||
- закрепленный менеджер
|
||||
- стоимость после обработки
|
||||
- параметры доставки после обработки
|
||||
|
||||
### Заказ
|
||||
|
||||
- идентификатор во внутренней системе
|
||||
Обязательные поля:
|
||||
|
||||
- внутренний идентификатор
|
||||
- внешний идентификатор 1С
|
||||
- статус
|
||||
- даты статусов
|
||||
- состав
|
||||
- даты изменений
|
||||
- состав заказа
|
||||
- стоимость
|
||||
- доставка
|
||||
- связанная заявка
|
||||
- связанная клиентская заявка
|
||||
|
||||
## Интеграции
|
||||
## 5.3 Требования к данным каталога
|
||||
|
||||
### Интеграция с 1С
|
||||
Для каждой позиции в каталоге система должна хранить и отображать:
|
||||
|
||||
На уровне ТЗ фиксируем две группы обменов.
|
||||
- тип товара
|
||||
- параметры выбора
|
||||
- описание параметров
|
||||
- остатки по складам
|
||||
- доступные варианты
|
||||
- признаки кастомизации, если они применимы
|
||||
|
||||
#### Входящие события
|
||||
## 5.4 Интеграция с 1С
|
||||
|
||||
- создание нового заказа
|
||||
- изменение заказа
|
||||
- обновление статуса
|
||||
- обновление параметров доставки
|
||||
- обновление состава и других полей заказа
|
||||
Интеграция с 1С должна обеспечивать обмен данными о заказах и каталоге.
|
||||
|
||||
#### Методы получения данных
|
||||
### Входящие события
|
||||
|
||||
- получение заказов клиента
|
||||
- получение каталога
|
||||
- получение характеристик товаров
|
||||
- получение остатков по складам
|
||||
Система должна принимать:
|
||||
|
||||
## Что нужно зафиксировать отдельно до финальной версии
|
||||
- событие создания заказа
|
||||
- событие изменения заказа
|
||||
- событие изменения статуса
|
||||
- событие изменения доставки
|
||||
- событие изменения состава или иных параметров
|
||||
|
||||
- контракт webhook-событий
|
||||
- идентификаторы и правила синхронизации сущностей
|
||||
- правила дедупликации заказов
|
||||
- политика ретраев и повторной обработки
|
||||
- требования к логированию ошибок интеграции
|
||||
### Методы получения данных
|
||||
|
||||
## Требования к журналированию
|
||||
Система должна получать:
|
||||
|
||||
Для спорных операций система должна хранить:
|
||||
- список заказов клиентов
|
||||
- каталог товаров
|
||||
- характеристики товаров
|
||||
- остатки по складам
|
||||
|
||||
## 5.5 Требования к интеграционному обмену
|
||||
|
||||
Интеграционный слой должен обеспечивать:
|
||||
|
||||
- сопоставление внутренних идентификаторов и идентификаторов 1С
|
||||
- защиту от дублирования событий
|
||||
- журналирование входящих событий
|
||||
- повторную обработку неуспешных событий
|
||||
- сохранение истории обновлений
|
||||
|
||||
## 5.6 Требования к журналированию
|
||||
|
||||
Для ключевых операций система должна хранить:
|
||||
|
||||
- кто инициировал действие
|
||||
- когда оно произошло
|
||||
- когда произошло действие
|
||||
- какой объект был изменен
|
||||
- какое было предыдущее значение статуса
|
||||
- какое стало новое значение статуса
|
||||
- какое состояние было до изменения
|
||||
- какое состояние стало после изменения
|
||||
|
||||
## 5.7 Бонусные данные
|
||||
|
||||
Для бонусного контура система должна хранить:
|
||||
|
||||
- текущий баланс
|
||||
- историю начислений
|
||||
- историю списаний
|
||||
- реферальные связи
|
||||
- заявки на вывод
|
||||
- статус обработки заявок на вывод
|
||||
|
||||
@@ -1,116 +1,130 @@
|
||||
# Функциональные требования
|
||||
# 4. Функциональные требования
|
||||
|
||||
## 1. Авторизация и подключение
|
||||
## 4.1 Авторизация и регистрация
|
||||
|
||||
Система должна поддерживать два способа входа клиента в продукт:
|
||||
Система должна поддерживать два сценария подключения клиента:
|
||||
|
||||
- регистрация по персональному приглашению
|
||||
- самостоятельная регистрация с последующим согласованием менеджером
|
||||
- самостоятельная регистрация через форму
|
||||
|
||||
### Обязательные сценарии
|
||||
### Требования
|
||||
|
||||
- создание приглашения менеджером
|
||||
- отправка приглашения по email
|
||||
- самостоятельная подача заявки на подключение
|
||||
- approve/reject заявки менеджером
|
||||
- завершение регистрации и установка учетных данных
|
||||
- привязка пользователя к контрагенту
|
||||
- подключение Telegram и Max как каналов уведомлений
|
||||
1. Менеджер должен иметь возможность отправить клиенту приглашение на email.
|
||||
2. Клиент должен иметь возможность завершить регистрацию по полученной ссылке.
|
||||
3. Клиент должен иметь возможность подать самостоятельную заявку на подключение.
|
||||
4. После самостоятельной регистрации система должна сформировать заявку на рассмотрение менеджером.
|
||||
5. Менеджер должен иметь возможность approve/reject заявки.
|
||||
6. При approve система должна отправить клиенту приглашение для завершения регистрации.
|
||||
7. После завершения регистрации клиент должен получить доступ к кабинету.
|
||||
8. Клиент должен иметь возможность подключить Telegram и Max как каналы уведомлений.
|
||||
|
||||
## 2. Каталог готовой продукции
|
||||
## 4.2 Каталог готовой продукции
|
||||
|
||||
Система должна предоставлять клиенту витрину готовой продукции.
|
||||
Система должна отображать клиенту каталог готовой продукции без отображения цены.
|
||||
|
||||
### Обязательные сценарии
|
||||
### Требования
|
||||
|
||||
- просмотр списка типов товаров
|
||||
- переход в карточку конкретного типа товара
|
||||
- выбор параметров продукции
|
||||
- просмотр доступных вариантов
|
||||
- сравнение остатков по складам
|
||||
- добавление позиции в корзину без отображения цены
|
||||
1. Система должна отображать список типов продукции.
|
||||
2. Система должна позволять перейти в карточку конкретного типа товара.
|
||||
3. Система должна отображать параметры выбора товара.
|
||||
4. Система должна отображать доступные варианты товара.
|
||||
5. Система должна отображать остатки по складам по каждой позиции.
|
||||
6. Система должна позволять добавить позицию в корзину.
|
||||
7. Система не должна отображать стоимость на этапе выбора товара.
|
||||
8. Система должна отображать текстовые описания параметров и сценариев применения.
|
||||
|
||||
### Обязательные особенности
|
||||
|
||||
- по каждой позиции должны отображаться характеристики товара
|
||||
- по каждой позиции должны отображаться остатки по складам
|
||||
- клиент не должен видеть цену на этапе выбора
|
||||
- каталог должен поддерживать как стандартные параметры, так и информационные описания по применению
|
||||
|
||||
## 3. Корзина и заявка на заказ
|
||||
## 4.3 Корзина и заявка на заказ
|
||||
|
||||
Система должна позволять клиенту собрать корзину и отправить заявку менеджеру.
|
||||
|
||||
### Обязательные сценарии
|
||||
### Требования
|
||||
|
||||
- просмотр корзины
|
||||
- изменение количества позиций
|
||||
- удаление позиции
|
||||
- отправка заявки на заказ
|
||||
- фиксация состава заявки без цены
|
||||
- передача заявки закрепленному менеджеру
|
||||
1. Клиент должен видеть список выбранных позиций.
|
||||
2. Клиент должен иметь возможность изменить количество.
|
||||
3. Клиент должен иметь возможность удалить позицию.
|
||||
4. Клиент должен иметь возможность отправить заявку на заказ.
|
||||
5. После отправки заявки система должна зафиксировать состав позиций без стоимости.
|
||||
6. Система должна назначить заявку закрепленному менеджеру.
|
||||
7. Система должна сохранить время создания заявки и инициатора.
|
||||
|
||||
## 4. Обработка заявки менеджером
|
||||
## 4.4 Менеджерская обработка заявки
|
||||
|
||||
Менеджер должен иметь возможность вручную обработать заявку.
|
||||
Менеджер должен иметь возможность обработать заявку вручную.
|
||||
|
||||
### Обязательные сценарии
|
||||
### Требования
|
||||
|
||||
- открытие заявки менеджером
|
||||
- заполнение стоимости по позициям или по заявке
|
||||
- указание параметров доставки
|
||||
- публикация обновленных условий клиенту
|
||||
- повторная корректировка до перевода в работу
|
||||
- перевод заявки в работу
|
||||
- отмена заявки
|
||||
1. Менеджер должен видеть состав заявки.
|
||||
2. Менеджер должен видеть данные клиента и контрагента.
|
||||
3. Менеджер должен иметь возможность указать стоимость.
|
||||
4. Менеджер должен иметь возможность указать параметры доставки.
|
||||
5. Менеджер должен иметь возможность оставить комментарий.
|
||||
6. Менеджер должен иметь возможность опубликовать условия клиенту.
|
||||
7. Менеджер должен иметь возможность повторно изменить условия до перевода заявки в работу.
|
||||
8. Менеджер должен иметь возможность перевести заявку в работу.
|
||||
9. Менеджер должен иметь возможность отменить заявку.
|
||||
|
||||
Система должна фиксировать:
|
||||
## 4.5 Заявка на расчет
|
||||
|
||||
- инициатора изменения
|
||||
- дату и время действия
|
||||
- историю изменения статусов
|
||||
Система должна поддерживать сценарий заявки на расчет индивидуальной продукции.
|
||||
|
||||
## 5. Заявка на расчет
|
||||
### Требования
|
||||
|
||||
Если готовая продукция не подходит, система должна переводить клиента в сценарий расчета.
|
||||
1. Клиент должен иметь возможность перейти в расчетный сценарий, если готовая продукция не подходит.
|
||||
2. Клиент должен иметь возможность заполнить параметры изделия.
|
||||
3. Клиент должен иметь возможность отправить заявку на расчет.
|
||||
4. Менеджер должен иметь возможность обработать заявку на расчет так же, как и заказную заявку.
|
||||
5. Система должна публиковать стоимость клиенту только после ручной обработки менеджером.
|
||||
|
||||
### Обязательные сценарии
|
||||
### Параметры расчетной заявки
|
||||
|
||||
- переход из каталога в заказ с расчетом
|
||||
- заполнение параметров изделия
|
||||
- отправка заявки на расчет
|
||||
- ручная обработка стоимости менеджером
|
||||
- публикация расчета клиенту
|
||||
- перевод расчета в работу или отмену
|
||||
|
||||
### Базовые параметры расчета
|
||||
|
||||
Минимально в ТЗ должны быть закреплены:
|
||||
Минимально система должна поддерживать передачу следующих параметров:
|
||||
|
||||
- тип продукции
|
||||
- ширина
|
||||
- длина
|
||||
- толщина
|
||||
- цвет
|
||||
- дополнительные параметры по конкретному типу товара
|
||||
- микронность или эквивалентный параметр толщины
|
||||
- специальные параметры в зависимости от типа продукции
|
||||
- комментарий клиента
|
||||
|
||||
## 6. Заказы и сопровождение
|
||||
## 4.6 Статусы заявок
|
||||
|
||||
Для заявок на заказ и заявок на расчет система должна поддерживать статусы, достаточные для управления процессом.
|
||||
|
||||
Минимально должны быть предусмотрены следующие состояния:
|
||||
|
||||
- создана
|
||||
- отправлена менеджеру
|
||||
- обработана менеджером
|
||||
- условия опубликованы
|
||||
- в работе
|
||||
- отменена
|
||||
|
||||
Для каждого изменения статуса система должна фиксировать:
|
||||
|
||||
- инициатора
|
||||
- дату и время
|
||||
- предыдущее состояние
|
||||
- новое состояние
|
||||
|
||||
## 4.7 Заказы и сопровождение
|
||||
|
||||
Система должна отображать клиенту список заказов и карточку каждого заказа.
|
||||
|
||||
### Обязательные сценарии
|
||||
### Требования
|
||||
|
||||
- просмотр списка заказов
|
||||
- фильтрация по периоду
|
||||
- просмотр карточки заказа
|
||||
- отображение статуса из 1С
|
||||
- отображение изменений по заказу
|
||||
- отправка трекинг-уведомлений
|
||||
1. Система должна отображать список заказов клиента.
|
||||
2. Система должна поддерживать фильтрацию истории заказов по периоду.
|
||||
3. Система должна отображать карточку заказа.
|
||||
4. Система должна отображать актуальный статус заказа.
|
||||
5. Система должна отображать историю изменений по заказу.
|
||||
6. Система должна отображать стоимость и параметры доставки, если они доступны.
|
||||
7. Система должна отображать дату актуальности данных.
|
||||
|
||||
## 7. Уведомления
|
||||
## 4.8 Уведомления
|
||||
|
||||
Система должна поддерживать многоканальные уведомления.
|
||||
Система должна поддерживать уведомления по нескольким каналам.
|
||||
|
||||
### Каналы
|
||||
|
||||
@@ -118,23 +132,35 @@
|
||||
- Telegram
|
||||
- Max
|
||||
|
||||
### События
|
||||
### События уведомлений
|
||||
|
||||
- приглашение к регистрации
|
||||
- approve/reject подключения
|
||||
- публикация условий по заявке
|
||||
- изменение статуса заказа
|
||||
- изменения по бонусному балансу
|
||||
- изменения бонусного баланса
|
||||
- обработка заявки на вывод
|
||||
|
||||
## 8. Бонусная программа
|
||||
## 4.9 Бонусная программа
|
||||
|
||||
Бонусный контур должен быть описан в ТЗ как отдельная функциональная область.
|
||||
Система должна поддерживать бонусный контур как полноценную функциональную область продукта.
|
||||
|
||||
Минимально должны быть зафиксированы:
|
||||
### Требования
|
||||
|
||||
- реферальная привязка клиентов
|
||||
- начисления и списания
|
||||
- журнал бонусных операций
|
||||
- магазин вознаграждений
|
||||
- заявка на вывод
|
||||
- менеджерская обработка заявок на вывод
|
||||
1. Менеджер должен иметь возможность создавать реферальные связи.
|
||||
2. Система должна хранить бонусные начисления и списания.
|
||||
3. Клиент должен видеть текущий бонусный баланс.
|
||||
4. Клиент должен видеть историю бонусных операций.
|
||||
5. Клиент должен иметь возможность использовать бонусы в рамках правил программы.
|
||||
6. Клиент должен иметь возможность подать заявку на вывод при достижении минимального порога.
|
||||
7. Менеджер должен иметь возможность обрабатывать заявку на вывод.
|
||||
8. Система должна уведомлять клиента об изменениях бонусного состояния.
|
||||
|
||||
## 4.10 Административные настройки
|
||||
|
||||
Система должна предоставлять административные разделы для управления:
|
||||
|
||||
- параметрами каталога
|
||||
- шаблонами уведомлений
|
||||
- параметрами синхронизации
|
||||
- бонусным контуром в разрешенной части
|
||||
|
||||
@@ -1,79 +1,108 @@
|
||||
# Контур продукта
|
||||
# 2. Назначение и границы продукта
|
||||
|
||||
## Назначение
|
||||
## 2.1 Назначение системы
|
||||
|
||||
`Личный кабинет Фрегат` предназначен для того, чтобы клиент мог самостоятельно работать с заказами и взаимодействием с менеджером в единой системе без постоянной ручной переписки.
|
||||
`Личный кабинет Фрегат` предназначен для переноса клиентского B2B взаимодействия из разрозненной переписки и ручного обмена файлами в единый веб-интерфейс.
|
||||
|
||||
## Основные пользовательские блоки
|
||||
Система должна обеспечить:
|
||||
|
||||
### Для клиента
|
||||
- единый вход клиента в процессы компании
|
||||
- цифровой выбор готовой продукции
|
||||
- цифровую отправку заявок на заказ и расчет
|
||||
- ручное согласование коммерческих условий менеджером
|
||||
- прозрачное сопровождение заказа по статусам
|
||||
- уведомление клиента о значимых изменениях
|
||||
|
||||
## 2.2 Границы продукта
|
||||
|
||||
Продукт охватывает следующие функциональные области:
|
||||
|
||||
- регистрация и подключение клиента
|
||||
- каталог готовой продукции
|
||||
- карточка товара и выбор параметров
|
||||
- корзина и отправка заявки на заказ
|
||||
- заявка на расчет кастомной продукции
|
||||
- менеджерская обработка заявок
|
||||
- карточка заказа и история заказов
|
||||
- уведомления
|
||||
- бонусная и реферальная программа
|
||||
- административные настройки
|
||||
|
||||
Продукт не предназначен для:
|
||||
|
||||
- самостоятельного расчета цены клиентом
|
||||
- бухгалтерского учета
|
||||
- публичной B2C торговли
|
||||
- самостоятельного изменения клиентом бизнес-правил компании
|
||||
|
||||
## 2.3 Пользовательские контуры
|
||||
|
||||
### Клиентский контур
|
||||
|
||||
Клиентский контур должен включать:
|
||||
|
||||
- вход и завершение регистрации
|
||||
- профиль компании и контактов
|
||||
- каталог готовой продукции
|
||||
- карточка товара с параметрами и остатками
|
||||
- корзина
|
||||
- заявка на заказ
|
||||
- заявка на расчет кастомной продукции
|
||||
- список заказов
|
||||
- карточка заказа
|
||||
- профиль компании
|
||||
- каталог продукции
|
||||
- карточку товара
|
||||
- корзину
|
||||
- список заявок и заказов
|
||||
- карточку заказа
|
||||
- уведомления
|
||||
- бонусная программа
|
||||
- бонусный кабинет
|
||||
|
||||
### Для менеджера
|
||||
### Менеджерский контур
|
||||
|
||||
- обработка заявок на подключение
|
||||
- обработка клиентских заказов и расчетов
|
||||
- ручное заполнение стоимости и условий доставки
|
||||
- публикация обновленных условий клиенту
|
||||
- просмотр клиентов и контрагентов
|
||||
- управление реферальными связями
|
||||
- обработка бонусных операций и заявок на вывод
|
||||
- настройка каталога, уведомлений и синхронизации
|
||||
Менеджерский контур должен включать:
|
||||
|
||||
## Ключевые бизнес-сценарии
|
||||
- обработку заявок на подключение
|
||||
- обработку заказных заявок
|
||||
- обработку расчетных заявок
|
||||
- работу с клиентами
|
||||
- работу с заказами
|
||||
- бонусные операции
|
||||
- административные настройки
|
||||
|
||||
### Сценарий 1. Подключение клиента
|
||||
## 2.4 Основные бизнес-сценарии
|
||||
|
||||
1. Клиент получает приглашение или самостоятельно подает заявку.
|
||||
2. Менеджер проверяет данные.
|
||||
3. При approve клиент завершает регистрацию.
|
||||
4. Клиент получает доступ в кабинет.
|
||||
### Сценарий А. Подключение нового клиента
|
||||
|
||||
### Сценарий 2. Заказ готовой продукции
|
||||
1. Клиент получает приглашение от менеджера или самостоятельно подает заявку на подключение.
|
||||
2. Менеджер проверяет данные клиента.
|
||||
3. Менеджер принимает решение approve/reject.
|
||||
4. При approve система отправляет клиенту ссылку для завершения регистрации.
|
||||
5. Клиент завершает регистрацию и получает доступ в кабинет.
|
||||
|
||||
1. Клиент открывает каталог.
|
||||
2. Выбирает тип товара и параметры.
|
||||
3. Видит доступные остатки по складам.
|
||||
4. Добавляет позиции в корзину.
|
||||
5. Отправляет заявку без цены.
|
||||
6. Менеджер проставляет цену и условия доставки.
|
||||
7. Клиент получает обновленные условия.
|
||||
8. Одна из сторон переводит заявку в работу или отменяет ее.
|
||||
### Сценарий Б. Заказ готовой продукции
|
||||
|
||||
### Сценарий 3. Заявка на расчет
|
||||
1. Клиент открывает каталог готовой продукции.
|
||||
2. Клиент выбирает тип товара.
|
||||
3. Клиент выбирает параметры товара.
|
||||
4. Клиент видит доступные варианты и остатки по складам.
|
||||
5. Клиент добавляет позиции в корзину.
|
||||
6. Клиент отправляет заявку без цены.
|
||||
7. Менеджер указывает стоимость и условия доставки.
|
||||
8. Клиент получает обновленные условия и принимает решение.
|
||||
|
||||
1. Клиент понимает, что готовая продукция не подходит.
|
||||
2. Переходит в режим расчета.
|
||||
3. Заполняет параметры продукции.
|
||||
4. Отправляет заявку менеджеру.
|
||||
5. Менеджер указывает цену и условия доставки.
|
||||
6. Клиент получает расчет и принимает решение.
|
||||
### Сценарий В. Заявка на расчет
|
||||
|
||||
### Сценарий 4. Сопровождение заказа
|
||||
1. Клиент понимает, что готовый товар не подходит под задачу.
|
||||
2. Клиент переходит в режим расчета.
|
||||
3. Клиент заполняет параметры изделия.
|
||||
4. Клиент отправляет заявку на расчет.
|
||||
5. Менеджер указывает стоимость и условия доставки.
|
||||
6. Клиент получает расчет и может продолжить работу по заявке.
|
||||
|
||||
1. После создания заказа статусы поступают из 1С.
|
||||
2. Клиент видит актуальный статус и изменения.
|
||||
3. Система отправляет уведомления по подключенным каналам.
|
||||
### Сценарий Г. Сопровождение заказа
|
||||
|
||||
## Границы первой проектной фиксации
|
||||
1. Заказ создается и получает статус.
|
||||
2. Изменения по заказу поступают в систему.
|
||||
3. Клиент видит актуальный статус и обновленные данные.
|
||||
4. Система отправляет уведомления клиенту.
|
||||
|
||||
Для первой полноценной редакции ТЗ мы фиксируем все разделы продукта, но детализируем в первую очередь:
|
||||
### Сценарий Д. Бонусная программа
|
||||
|
||||
- авторизацию и подключение клиента
|
||||
- каталог и заказ готовой продукции
|
||||
- расчет кастомной продукции
|
||||
- менеджерскую обработку заявки
|
||||
- карточку заказа и список заказов
|
||||
|
||||
Бонусная программа должна быть описана в ТЗ, но на раннем этапе может иметь меньшую глубину детализации интерфейсов, чем заказный контур.
|
||||
1. Менеджер создает или поддерживает реферальную связь.
|
||||
2. Система отражает бонусные начисления и изменения баланса.
|
||||
3. Клиент видит бонусный баланс и историю операций.
|
||||
4. Клиент может использовать бонусы или подать заявку на вывод в рамках правил программы.
|
||||
|
||||
@@ -1,62 +1,89 @@
|
||||
# Роли и доступ
|
||||
# 3. Роли и права доступа
|
||||
|
||||
## Основные роли
|
||||
## 3.1 Состав ролей
|
||||
|
||||
### Клиент
|
||||
В системе должны быть предусмотрены следующие базовые роли:
|
||||
|
||||
Клиент работает в личном кабинете своей организации и имеет доступ только к данным, относящимся к его компании.
|
||||
- клиент
|
||||
- менеджер
|
||||
- суперменеджер
|
||||
|
||||
Клиент может:
|
||||
## 3.2 Роль `Клиент`
|
||||
|
||||
- войти по приглашению или после approve заявки
|
||||
- редактировать профиль и контактные данные в разрешенных пределах
|
||||
Клиент представляет организацию-контрагента и работает только в рамках данных своей компании.
|
||||
|
||||
Клиент должен иметь возможность:
|
||||
|
||||
- завершить регистрацию по приглашению
|
||||
- подать заявку на подключение
|
||||
- просматривать и редактировать собственные профильные данные в разрешенной части
|
||||
- подключать каналы уведомлений
|
||||
- выбирать готовую продукцию
|
||||
- создавать заявки на заказ
|
||||
- создавать заявки на расчет
|
||||
- просматривать заказы, статусы, историю и уведомления
|
||||
- просматривать бонусную информацию и подавать заявки на вывод, если это предусмотрено правилами
|
||||
- работать с каталогом готовой продукции
|
||||
- добавлять товары в корзину
|
||||
- отправлять заявку на заказ
|
||||
- отправлять заявку на расчет
|
||||
- просматривать список своих заказов
|
||||
- просматривать карточку заказа
|
||||
- просматривать уведомления
|
||||
- просматривать бонусный баланс и историю операций
|
||||
- подавать заявку на вывод, если это разрешено правилами программы
|
||||
|
||||
### Менеджер
|
||||
## 3.3 Роль `Менеджер`
|
||||
|
||||
Менеджер работает с закрепленными клиентами, их заявками, заказами и бонусными операциями.
|
||||
Менеджер представляет сотрудника компании, закрепленного за клиентами.
|
||||
|
||||
Менеджер может:
|
||||
Менеджер должен иметь возможность:
|
||||
|
||||
- рассматривать заявки на подключение
|
||||
- approve/reject регистрацию
|
||||
- approve/reject регистрацию клиента
|
||||
- привязывать клиента к контрагенту
|
||||
- принимать клиентские заявки на заказ и расчет
|
||||
- вручную указывать стоимость и параметры доставки
|
||||
- получать заявки на заказ
|
||||
- получать заявки на расчет
|
||||
- указывать стоимость
|
||||
- указывать параметры доставки
|
||||
- публиковать условия клиенту
|
||||
- переводить заявку в работу или отменять ее
|
||||
- просматривать связанные с клиентами данные
|
||||
- управлять реферальными связями и бонусными операциями
|
||||
- переводить заявку в работу
|
||||
- отменять заявку
|
||||
- просматривать карточки клиентов
|
||||
- просматривать карточки заказов
|
||||
- работать с бонусными связями и заявками на вывод
|
||||
|
||||
### Суперменеджер
|
||||
## 3.4 Роль `Суперменеджер`
|
||||
|
||||
Суперменеджер имеет все права менеджера плюс расширенные права на управление данными и настройками.
|
||||
Суперменеджер является расширенной административной ролью.
|
||||
|
||||
Суперменеджер может:
|
||||
Суперменеджер должен иметь все права менеджера, а также дополнительно:
|
||||
|
||||
- работать со всеми клиентами, а не только со своими
|
||||
- управлять настройками каталога
|
||||
- управлять шаблонами уведомлений
|
||||
- управлять параметрами синхронизации
|
||||
- выполнять административные операции по бонусной системе
|
||||
- доступ ко всем клиентам и всем заказам
|
||||
- управление настройками каталога
|
||||
- управление настройками уведомлений
|
||||
- управление настройками синхронизации
|
||||
- расширенный доступ к бонусному контуру
|
||||
|
||||
## Ограничения доступа
|
||||
## 3.5 Матрица доступа
|
||||
|
||||
| Действие | Клиент | Менеджер | Суперменеджер |
|
||||
| --- | --- | --- | --- |
|
||||
| Завершение регистрации | Да | Нет | Нет |
|
||||
| Подача заявки на подключение | Да | Нет | Нет |
|
||||
| Просмотр каталога | Да | Да | Да |
|
||||
| Добавление товара в корзину | Да | Нет | Нет |
|
||||
| Отправка заявки на заказ | Да | Нет | Нет |
|
||||
| Отправка заявки на расчет | Да | Нет | Нет |
|
||||
| Указание стоимости и доставки | Нет | Да | Да |
|
||||
| Публикация условий клиенту | Нет | Да | Да |
|
||||
| Перевод заявки в работу | Да | Да | Да |
|
||||
| Отмена заявки | Да | Да | Да |
|
||||
| Управление настройками каталога | Нет | Нет | Да |
|
||||
| Управление настройками уведомлений | Нет | Нет | Да |
|
||||
| Управление синхронизацией | Нет | Нет | Да |
|
||||
|
||||
## 3.6 Ограничения и безопасность доступа
|
||||
|
||||
Система должна обеспечивать:
|
||||
|
||||
- раздельные интерфейсы клиента и менеджера
|
||||
- изоляцию клиентских данных по контрагенту
|
||||
- контроль административных настроек только для расширенных ролей
|
||||
- журналирование ключевых действий по заявкам и заказам
|
||||
|
||||
## Открытые вопросы для финальной фиксации
|
||||
|
||||
- может ли один клиент иметь несколько пользователей внутри одной организации
|
||||
- как разделяются полномочия между менеджером и суперменеджером в части справочников
|
||||
- кто именно может изменять каталог, уведомления и бонусные настройки
|
||||
- требуется ли дополнительная роль наблюдателя или оператора
|
||||
- доступ клиента только к собственному контрагенту и его объектам
|
||||
- ограничение административных функций по ролям
|
||||
- журналирование действий пользователя
|
||||
- возможность аудита изменения статусов и условий заявок
|
||||
|
||||
@@ -1,84 +1,204 @@
|
||||
# Этап 1: UX/UI
|
||||
# 6. Экранные формы и текстовые прототипы
|
||||
|
||||
## Назначение этапа
|
||||
## 6.1 Общие требования к экранным формам
|
||||
|
||||
Первый этап нужен не для полной разработки продукта, а для согласования визуального подхода, экранной структуры и базовой логики пользовательских сценариев.
|
||||
Экранные формы должны обеспечивать понятную навигацию, читаемое отображение статусов, явное разделение клиентского и менеджерского контура и однозначную привязку действий к текущему объекту.
|
||||
|
||||
Согласно приложению к договору, на этапе должны быть представлены `2-3 сверстанные страницы` с основными элементами интерфейса.
|
||||
Для всех ключевых форм должны выполняться требования:
|
||||
|
||||
## Рекомендуемый состав страниц этапа
|
||||
- на экране должен быть понятен текущий объект работы
|
||||
- должен быть виден текущий статус объекта
|
||||
- действия пользователя должны соответствовать роли и статусу объекта
|
||||
- клиент не должен видеть стоимость до публикации условий менеджером
|
||||
- остатки по складам должны отображаться в наглядном виде
|
||||
|
||||
### Страница 1. Каталог / карточка товара
|
||||
## 6.2 Клиентские формы
|
||||
|
||||
Цель страницы:
|
||||
### 6.2.1 Главная страница клиента
|
||||
|
||||
- показать, как клиент выбирает готовую продукцию
|
||||
- показать параметры, доступные варианты и остатки
|
||||
- показать переход к заказу и к расчету
|
||||
Назначение:
|
||||
|
||||
Что должно быть на странице:
|
||||
- входная точка в систему
|
||||
- доступ к основным разделам
|
||||
- отображение важных текущих событий
|
||||
|
||||
- список или карточка типа товара
|
||||
- иллюстрация товара
|
||||
- выбор параметров
|
||||
- описания параметров и сценариев применения
|
||||
- доступные варианты
|
||||
- индикация остатков по складам
|
||||
Состав:
|
||||
|
||||
- шапка с навигацией
|
||||
- блок быстрых переходов
|
||||
- блок актуальных заказов
|
||||
- блок последних уведомлений
|
||||
|
||||
Прототип:
|
||||
|
||||
```text
|
||||
+-------------------------------------------------------------+
|
||||
| Header: каталог | заказы | уведомления | бонусы | профиль |
|
||||
+-------------------------------------------------------------+
|
||||
| Быстрые действия |
|
||||
| [Каталог] [Мои заказы] [Бонусы] [Профиль] |
|
||||
+-------------------------------------------------------------+
|
||||
| Актуальные заказы |
|
||||
| № | статус | дата | действие |
|
||||
+-------------------------------------------------------------+
|
||||
| Последние уведомления |
|
||||
+-------------------------------------------------------------+
|
||||
```
|
||||
|
||||
### 6.2.2 Каталог продукции
|
||||
|
||||
Назначение:
|
||||
|
||||
- показать доступные товарные направления
|
||||
- дать переход в карточку типа товара
|
||||
|
||||
Состав:
|
||||
|
||||
- поиск
|
||||
- сетка карточек типов продукции
|
||||
|
||||
### 6.2.3 Карточка типа товара
|
||||
|
||||
Назначение:
|
||||
|
||||
- выбор параметров товара
|
||||
- просмотр остатков и доступных вариантов
|
||||
- добавление в корзину
|
||||
|
||||
Состав:
|
||||
|
||||
- заголовок
|
||||
- изображение
|
||||
- блок параметров
|
||||
- блок описания параметров
|
||||
- SKU выбранной позиции
|
||||
- действие `В корзину`
|
||||
- действие перехода в расчетный сценарий
|
||||
- таблица доступных вариантов
|
||||
|
||||
### Страница 2. Карточка заявки / заказа клиента
|
||||
Прототип:
|
||||
|
||||
Цель страницы:
|
||||
```text
|
||||
+-------------------------------------------------------------+
|
||||
| Назад | Тип товара |
|
||||
+-------------------------------------------------------------+
|
||||
| Изображение | Параметры выбора | SKU / В корзину |
|
||||
| | ширина | |
|
||||
| | длина | |
|
||||
| | толщина | |
|
||||
| | цвет / надпись | |
|
||||
+-------------------------------------------------------------+
|
||||
| Таблица доступных вариантов |
|
||||
| SKU | ширина | длина | толщина | остатки | действие |
|
||||
+-------------------------------------------------------------+
|
||||
```
|
||||
|
||||
- показать, как клиент видит созданную заявку или заказ
|
||||
- показать статусы, историю изменений и опубликованные менеджером условия
|
||||
### 6.2.4 Корзина
|
||||
|
||||
Что должно быть на странице:
|
||||
Назначение:
|
||||
|
||||
- номер заявки или заказа
|
||||
- текущий статус
|
||||
- состав заказа
|
||||
- стоимость после обработки менеджером
|
||||
- параметры доставки
|
||||
- история статусов
|
||||
- действия `Отправить в работу` / `Отменить`, если стадия это допускает
|
||||
- проверка состава заказа
|
||||
- корректировка количества
|
||||
- отправка заявки
|
||||
|
||||
### Страница 3. Менеджерская обработка заявки
|
||||
### 6.2.5 Карточка заявки / заказа
|
||||
|
||||
Цель страницы:
|
||||
Назначение:
|
||||
|
||||
- показать рабочее место менеджера
|
||||
- показать, как менеджер вносит стоимость и условия
|
||||
- отображение состава, статуса, стоимости, доставки и истории
|
||||
|
||||
Что должно быть на странице:
|
||||
Прототип:
|
||||
|
||||
- данные клиента
|
||||
- состав заявки или параметры расчета
|
||||
- поле стоимости
|
||||
- блок доставки
|
||||
- комментарий менеджера
|
||||
```text
|
||||
+-------------------------------------------------------------+
|
||||
| № заявки / заказа | Статус |
|
||||
+-------------------------------------------------------------+
|
||||
| Состав |
|
||||
+-------------------------------------------------------------+
|
||||
| Стоимость и доставка |
|
||||
+-------------------------------------------------------------+
|
||||
| История изменений |
|
||||
+-------------------------------------------------------------+
|
||||
| [Отправить в работу] [Отменить] |
|
||||
+-------------------------------------------------------------+
|
||||
```
|
||||
|
||||
### 6.2.6 Список заказов
|
||||
|
||||
Назначение:
|
||||
|
||||
- просмотр текущих и архивных заказов
|
||||
- фильтрация по периоду
|
||||
|
||||
### 6.2.7 Уведомления
|
||||
|
||||
Назначение:
|
||||
|
||||
- просмотр истории уведомлений по всем объектам
|
||||
|
||||
### 6.2.8 Бонусный кабинет
|
||||
|
||||
Назначение:
|
||||
|
||||
- просмотр бонусного баланса
|
||||
- просмотр истории операций
|
||||
- выполнение действий в рамках бонусной программы
|
||||
|
||||
## 6.3 Менеджерские формы
|
||||
|
||||
### 6.3.1 Список клиентов
|
||||
|
||||
Назначение:
|
||||
|
||||
- просмотр клиентов
|
||||
- переход в карточку клиента
|
||||
|
||||
### 6.3.2 Карточка клиента
|
||||
|
||||
Назначение:
|
||||
|
||||
- просмотр компании, заявок, заказов и бонусных связей
|
||||
|
||||
### 6.3.3 Карточка обработки заявки
|
||||
|
||||
Назначение:
|
||||
|
||||
- ввод стоимости и доставки
|
||||
- публикация условий клиенту
|
||||
- действия по статусу заявки
|
||||
- управление статусом
|
||||
|
||||
## Что должно быть согласовано по результату этапа
|
||||
Прототип:
|
||||
|
||||
- визуальный стиль кабинета
|
||||
- логика компоновки клиентских и менеджерских экранов
|
||||
- базовый набор UI-паттернов
|
||||
- структура основных карточек и таблиц
|
||||
- подход к отображению статусов, уведомлений и складских остатков
|
||||
```text
|
||||
+-------------------------------------------------------------+
|
||||
| Клиент | Контрагент | Менеджер |
|
||||
+-------------------------------------------------------------+
|
||||
| Состав заявки / параметры изделия |
|
||||
+-------------------------------------------------------------+
|
||||
| Стоимость |
|
||||
| Доставка |
|
||||
| Комментарий менеджера |
|
||||
+-------------------------------------------------------------+
|
||||
| [Опубликовать условия] [В работу] [Отменить] |
|
||||
+-------------------------------------------------------------+
|
||||
```
|
||||
|
||||
## Что не требуется завершать на этом этапе
|
||||
### 6.3.4 Список заказов менеджера
|
||||
|
||||
- полную реализацию бизнес-логики
|
||||
- реальные интеграции с 1С
|
||||
- все вспомогательные разделы
|
||||
- полную настройку бонусной программы
|
||||
Назначение:
|
||||
|
||||
## Связанные материалы, которые желательно приложить к этапу
|
||||
- просмотр заказов по клиентам
|
||||
- контроль текущих статусов
|
||||
|
||||
- экранная карта
|
||||
- список состояний каждой из 3 страниц
|
||||
- перечень компонентов интерфейса
|
||||
- список открытых вопросов, блокирующих следующий этап
|
||||
### 6.3.5 Настройки каталога
|
||||
|
||||
Назначение:
|
||||
|
||||
- управление параметрами типов продукции
|
||||
- управление описаниями и вариантами
|
||||
|
||||
### 6.3.6 Настройки уведомлений и синхронизации
|
||||
|
||||
Назначение:
|
||||
|
||||
- управление шаблонами сообщений
|
||||
- управление параметрами обмена
|
||||
|
||||
Reference in New Issue
Block a user