Интерфейс настройки статусов, схемы переходов и причин измен

Необходимо разработать прототип интерфейса (Axure или другая система прототипирования) 

Требования к модулю: 

Реализация функционала строится на основе SPA (Single Page Application) 

Интерфейс настроек делится на 3 экрана: 
1. Группы и статусы 
2. Причины переходов 
3. Схема переходов 

Группы статусов и статусы 
Администратор определяет статусы, используемые в магазине, и распределяет их по группам. Статус всегда находится в одной конкретной группе. 

Свойства группы: 
1. Название 
2. Идентификатор (любая строка не длиннее 64 символов, используется в API), поле не обязательно для заполнения 
3. Цвет, по умолчанию не заполнено, пользователь может выбрать из заранее определенного списка цветов или указать свой с помощью панели выбора цвета 

Свойства статуса: 
1. Название 
2. Идентификатор (любая строка не длиннее 64 символов, используется в API), поле не обязательно для заполнения 
3. Принадлежность к группе 
4. Цвет, по умолчанию не заполнено, пользователь может выбрать из заранее определенного списка цветов или указать свой с помощью панели выбора цвета. Если указан, то цвет статуса имеет приоритет над цветом группы, которой принадлежит статус. 
Группы и статусы можно сортировать. 

Схема изменения статусов 
Администратор магазина задает правила, определяющие возможные изменения статусов, например: 
• Новый -> Подтвержден 
• Подтвержден -> Ожидается поступление 
• Подтвержден -> Передан в службу доставки 
• ЛЮБОЙ СТАТУС -> Отменен 

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

В начальном и конечном статусе можно задать специальное значение "Любой статус". Например, правило "ЛЮБОЙ СТАТУС" -> "ЛЮБОЙ СТАТУС" позволит изменить статус на любой из существующих. 
Также в правилах можно задать не только статус, но и целую группу. 

Порядок правил имеет значение. Система выбирает подходящее правило сверху вниз. Если на первом месте будет правило "Любой -> Любой", то все остальные правила обработаны не будут. Таким образом, в интерфейсе настроек нужно предусмотреть сортировку правил. 

Интерфейс редактора правил должен позволять фильтровать правила по начальному и конечному статусу или группе. 

Для каждой комбинации предыдущего и следующего статуса администратор может определить: 
1. Список причин перехода ("Нет в наличии", "Клиент отказался" и т.п, см. ниже) 
2. Правила проверки заказа, которым должен удовлетворять заказ при переходе в новый статус (фио заполнены, телефон указан, товар забронирован и т.п) – пока не делаем 
3. Список автоматических действий (отправка письма или смс, постановка задачи менеджеру, бронирование товара и т.п.) – пока не делаем 
4. Список групп пользователей, которым доступно совершение этого перехода статуса (старший менеджер может отменить заказ после его передачи в службу доставки, а рядовой менеджер – нет) – пока не делаем 

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

Свойства причины: 
1. Название 
2. Идентификатор (любая строка не длиннее 64 символов, используется в API), поле не обязательно для заполнения 
Администратор может добавлять необходимое кол-во возможных причин. Над каждой причиной возможны следующие операции: 
1. Переименование 
2. Изменение идентификатора 
3. Удаление (если причина уже используется в заказах, то удаление не сработает и пользователь увидит сообщение о невозможности удаления) 
4. Отключение/Включение 
5. Изменение порядка сортировки перетаскиванием 

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

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