ShariX Open Docs

Эта страница только для чтения. Вы можете посмотреть её исходный текст, но не можете его изменить. Сообщите администратору, если считаете, что это неправильно.
===== Типы пользователей ИС =====

==== META-USER ====
Пользователь (META-USER) - принадлежит ShariX, но у сервиса могут быть локальные пользователи (этот пользователь все равно дублируется с пустой структурой и флагом IS_GLOBAL на платформе). Зарегистрирован в системе. META-USER - базовая единица пользователя платформы, на которую могут быть назначены дополнительные права в соответствии с иными ролями. В зависимости от дополнительных прав на основе этого пользователя могут получаться как клиенты, так и исполнители, так и ответственные лица. Управление загруженными документами в собственном профиле. Изменение параметров собственного бронирования. Отправка запроса на установление взаимоотношений с организацией-партнером. Отправка запроса на установление взаимоотношений с сервисом. Ввод карты для снятия денег.

ИС любого сервиса состоит из следующих уровней:
  * уровень платформы (PLATFORM-*) - не является сервисом вообще, а часть нашего программного продукта, которая обладает описанными свойствами, которые надо указывать ровно для того, чтобы оно с ней дружило. Юридический смысл - поставщик ПО.
  * уровень сервиса (METASERVICE-*). Юридический смысл - агент по конкретному виду услуг. (Например, сервис каршеринга). Устанавливает возможные профили услуг (схемы тарифов).
  * уровень партнера сервиса (PARTNER-*). Юридический смысл - компания, предоставляющая услугу, которой управляет сервис. Выбирает актуальные для организации схемы тарифов из доступных в вышестоящем сервисе, устанавливает цифровые значения тарифов.

На каждом уровне (платформа, сервис, партнер) могут быть вспомогательные пользователи следующего вида:

==== Администратор статических процессов =====
Администратор статических процессов (*-ADMIN) - ответственное лицо организации перед уровнем выше (если есть). Организация - это структура в БД, которая не имеет своего отдельного аккаунта для входа. К ней назначается ответственный - админ, который представляет ее интересы. Он назначает любые иные права внутри организации, либо удовлетворяет запросы на них. Имеет доступ к статистическим и финансовым показателям, отчетности, просмотр данных по существующим договорам. Регистрирует организации на 1 уровень ниже и назначает ответственных в них. Управляет статусом доступности организаций на 1 уровень ниже. Устанавливает взаимоотношения или подтверждает запросы на взаимоотношения с организациями на 1 уровень ниже в случае их наличия в системе (юридический смысл - подписание договора). Управление тарифами (в рамках уровня).
Изначально админ регистрирует организацию и предоставляет документы на уровень выше (если есть), подтверждающие право его представления организации. Если такое ответственное лицо от организации меняется - это происходит методом ручных обработок заявок ответственными на уровень выше (если есть).

==== Модератор динамических процессов ====
Модератор динамических процессов (*-SUPERVISOR) - ответственное лицо (может быть несколько) за функционирование организации. Выдает подтверждения на спецправа сотрудникам колл-центра и техподдержке при обработке заявок и ситуаций, назначает любые права внутри организации, помимо равных ему и админа. Управление статусом доступности организаций, стоящих на ступень ниже (модератор платформы - сервисами, модератор сервисов - партнерами, партнеры - связью с исполнителями (если предусмотрено смыслом сервиса))

==== Сотрудник (оператор) call-центра ====
Сотрудник (оператор) call-центра (*-SUPPORT) - информационная обработка поступающих заявок, внесение изменений при удовлетворении запроса соответствующим его уровню *-SUPERVISOR. Взаимодействие с пользователями, которые имеют право обратиться. Операторы колл-центра внутри организации оказывают поддержку только в зоне ответственности функционирования организации, при несоответствии запросов отправляют заявку на 1 уровень выше или ниже.

==== Техподдержка (*-TECHSUPPORT) ====
Техподдержка (*-TECHSUPPORT) - физическая обработка заявок без непосредственного взаимодействия с пользователями (обработка ошибок ПО, оборудования или иных физических проявлений ошибок), при наличии на то прав/задания, подтвержденного модератором динамических процессов.

==== Исполнитель (PROVIDER) ====
Исполнитель (PROVIDER) - зарегистрированный пользователь, способный осуществлять заказы.

==== Клиент (CLIENT) ====
Клиент (CLIENT) - зарегистрированный пользователь, способный делать заказы.

==== Гость ====
ГОСТЬ - незарегистрированный пользователь с самым минимальным уровнем прав, достаточных только для ознакомления/просмотра с услугами, но не дающие ему возможности для пользования таковыми. Пользователь может отправить заявку на регистрацию.


===== Сценарии и возможности =====

==== METASERVICE-ADMIN ====
представление интересов сервиса перед платформой:
  * получение и отправление отчетности по взаимодействию с партнером (счета и акты по оказанным услугам, счета и акты по услугам агента, акты сверки)
  * получение и отправление отчетности по взаимодействию с платформой (счета и акты по оказанным услугам, счета и акты по услугам агента, акты сверки)
  * получение информации по выплатам (текущая сводная информация по заявкам и статусам накапливаемой оплаты) (так как взаиморасчет раз в неделю)
  * указание счета для финансовых поступлений
  * загрузка и удаление документов, подтверждающих право оказания услуг
  * создание схем услуг в рамках сервиса (ST_REQUEST админу платформы)
  * (metaservice_roles) назначение любых прав (кроме своего уровня) внутри организации, удовлетворение запросов на них (ACCESS_REQUEST) (назначение - создание заявки за другого пользователя и тут же ее удовлетворение с точки зрения процесса, в системе хранится лог заявки)
  * (partner_activation) активация и деактивация аккаунтов партнеров (заключение и расторжение договора) (статусы ACTIVE/CHECK/BLOCKED в любых комбинациях) (обработка заявки NEG_REQUEST)
  * (metaservice_partner_docs) управление статусами проверки актуальности документов, загруженных пользователями внутри организации (переключение с NEW на OK или с NEW на ERROR, или OK на ERROR) (это обработка ST_REQUEST и изменение статуса документа, если документ глобальный - с предупреждением, что в случае ошибочной деактивации документа ответственность на деактивировавшем, и предлагается выполнить действие без влияния на документы, либо можно отправить запрос на уровень платформы)
  * (metaservice_partner_docs) управление статусами проверки актуальности документов, загруженных партнерами для установления взаимоотношений (переключение с NEW на OK или с NEW на ERROR, или OK на ERROR) (это обработка ST_REQUEST и изменение статуса документа, если документ глобальный - с предупреждением, что в случае ошибочной деактивации документа ответственность на деактивировавшем, и предлагается выполнить действие без влияния на документы, либо можно отправить запрос на уровень платформы)
  * назначение ответственного в организации-партнере (удовлетворение запроса - реализуется через базовые механизмы META-USER по удовлетворению заявок, направленных пользователю) (назначение - создание заявки за другого пользователя и тут же ее удовлетворение с точки зрения процесса, в системе хранится лог заявки, необходимо подтверждение назначаемого, без него организация неактивна или действует под управлением предыдущего назначенного, если он был)
  * Обработка заявок, назначенных на себя (ASSIGNED)

==== METASERVICE-SUPERVISOR ====
  * (operational_control_extra) Удовлетворение или отмена заявок на получение дополнительных прав пользователей в рамках операции по заявке (например, ЧТО - надо перечислить все сценарии) (изменение статуса ACCESS_REQUEST)
  * (operational_control) Управление статусами заявок (ST_REQUEST) с доступными правами (кроме заявок админа) внутри организации, создание и комментирование заявок любого типа, назначенных на любого пользователя внутри организации
  * (activity_control) Управление статусами активности пользователей внутри организации, кроме админа и пользователей с аналогичными правами (только переключение между ACTIVE и CHECK, отправка запроса на подтверждение BLOCKED) (это частный случай обработки ST_REQUEST)
  * (access_control) Управление правами пользователей внутри организации, кроме админа и пользователей с аналогичными правами (это действие обработки заявки ST_REQUEST или действие назначения) (ПРОВЕРИТЬ ТИП ЗАЯВКИ)
  * (metaservice_partner_docs) Управление статусом проверки документов партнеров PARTNER-ADMIN (переключение с NEW на OK или с NEW на ERROR, или OK на ERROR) (это обработка ST_REQUEST и изменение статуса документа, если документ глобальный - с предупреждением, что в случае ошибочной деактивации документа ответственность на деактивировавшем, и предлагается выполнить действие без влияния на документы, либо можно отправить запрос на уровень платформы)
  * Обработка заявок, назначенных на себя (ASSIGNED)

==== METASERVICE-SUPPORT ====
информационная обработка поступающих заявок:
  * (service_request) чтение заявок NEW и переназначение на другого специалиста внутри организации, а также перенос на уровень партнера или платформы (ASSIGNED), обработка (IN PROGRESS->DONE) или закрытие без выполнения (WONTFIX, DUPLICATE)
  * (service-inbox) заведение заявок в системе при обработке звонков и чатов
  * прием входящих перенаправленных другими операторами звонков от платформы и партнеров
  * (service-inbox) прием сообщений в чате (чат сразу сделать формой заявки и продолжающимися комментариями)
  * отправка запросов ACCESS_REQUEST на уровень METASERVICE_SUPERVISOR (тут кстати вопрос - при удовлетворении доступа изменения вносит запросивший или подтвердивший?)

Зона ответственности - работа программного обеспечения на уровне сервиса (ПО по управлению доступа к автомобилям), договорные отношения на уровне сервиса.

==== METASERVICE-TECHSUPPORT ====
(service-inbox-tech)
  * Техническая обработка поступающих заявок (IN PROGRESS->DONE) или закрытие без выполнения (WONTFIX, DUPLICATE)
  * Запрос на получение доступа к автомобилям партнеров при необходимости в результате обработки поступающих заявок
  * Взаимодействие с ресурсами партнеров при наличии доступа

Зона ответственности - работа программного обеспечения на уровне сервиса (ПО по управлению доступа к автомобилям). 

==== PARTNER-ADMIN ====
представление интересов организации перед сервисом:
  * получение и отправление отчетности по взаимодействию с сервисом (счета и акты по оказанным услугам, счета и акты по услугам агента, акты сверки)
  * получение и отправление отчетности по взаимодействию с платформой (счета и акты по оказанным услугам, счета и акты по услугам агента, акты сверки)
  * получение информации по выплатам (текущая сводная информация по заявкам и статусам накапливаемой оплаты) (так как взаиморасчет раз в неделю)
  * указание счета для получения финансовых поступлений
  * загрузка и удаление документов, подтверждающих право оказания услуг
  * активация и деактивация действующих схем услуг
  * назначение и изменение тарифов внутри выбранных действующих схем услуг (ST_REQUEST админу сервиса)
  * (partner_roles) назначение любых прав (кроме своего уровня) внутри организации, удовлетворение запросов на них (назначение - создание заявки за другого пользователя и тут же ее удовлетворение с точки зрения процесса, в системе хранится лог заявки)
  * (provider_docs, resource_docs) управление статусами проверки актуальности документов, загруженных пользователями внутри организации (переключение с NEW на OK или с NEW на ERROR, или OK на ERROR) (это обработка ST_REQUEST и изменение статуса документа, если документ глобальный - с предупреждением, что в случае ошибочной деактивации документа ответственность на деактивировавшем, и предлагается выполнить действие без влияния на документы, либо можно отправить запрос на уровень платформы)
  * активация и деактивация допущенных к управлению водителей (DRIVER) (заключение и расторжение договора) (статусы ACTIVE/CHECK/BLOCKED в любых комбинациях) (это действие обработки заявки ST_REQUEST или действие назначения)
  * Обработка заявок, назначенных на себя (ASSIGNED)

==== PARTNER-SUPERVISOR ====
  * (service_request_edit) Удовлетворение или отмена заявок на редактирование заявок/бронирований (ACCESS_REQUEST в отношении изменения SERVICE_REQUEST) (должен быть автоаппрув на уровень выше, если такая опция есть у партнера)
  * (operational_control_extra) Удовлетворение или отмена заявок на получение дополнительных прав пользователей в рамках операции по заявке (например, на открытие автомобиля в технических целях - надо перечислить все сценарии) (изменение статуса ACCESS_REQUEST)
  * (operational_control) Управление статусами заявок (ST_REQUEST) с доступными правами (кроме заявок админа) внутри организации, создание и комментирование заявок любого типа, назначенных на любого пользователя внутри организации
  * (activity_control) Управление статусами активности пользователей внутри организации, кроме админа и пользователей с аналогичными правами (только переключение между ACTIVE и CHECK, отправка запроса на подтверждение BLOCKED) (это частный случай обработки ST_REQUEST)
  * (access_control) Управление правами пользователей внутри организации, кроме админа и пользователей с аналогичными правами (это действие обработки заявки ST_REQUEST или действие назначения) (проверить тип заявки)
  * (provider_docs, resource_docs) Управление статусом проверки документов исполнителей и ресурсов (переключение с NEW на OK или с NEW на ERROR, или OK на ERROR) (это обработка ST_REQUEST и изменение статуса документа, если документ глобальный - с предупреждением, что в случае ошибочной деактивации документа ответственность на деактивировавшем, и предлагается выполнить действие без влияния на документы, либо можно отправить запрос на уровень платформы)
  * Обработка заявок, назначенных на себя (ASSIGNED)

==== PARTNER-SUPPORT ====

Важно: в концепции предполагается, что сопровождением заказов сервиса занимается сервис, а не партнер.

(partner-inbox)
информационная обработка поступающих заявок:
  * чтение заявок NEW и переназначение на другого специалиста внутри организации, а также перенос на уровень сервиса (ASSIGNED), обработка (IN PROGRESS->DONE) или закрытие без выполнения (WONTFIX, DUPLICATE)
заведение заявок в системе при обработке звонков и чатов
  * прием заявок от пользователей по телефону
  * перенаправление звонков на уровень выше
  * прием сообщений в чате (чат сразу сделать формой заявки и продолжающимися комментариями)
  * отправка запросов ACCESS_REQUEST на уровень PARTNER_SUPERVISOR (тут кстати вопрос - при удовлетворении доступа изменения вносит запросивший или подтвердивший?)

Зона ответственности - работа программного обеспечения на уровне автомобиля (ПО по управлению доступа к автомобилям), договорные отношения на уровне партнера, управление доступностью ресурсов, обработка первичных заявок клиентов.

==== PARTNER-TECHSUPPORT ====
(partner-inbox-tech)
  * Техническая обработка поступающих заявок (IN PROGRESS->DONE) или закрытие без выполнения (WONTFIX, DUPLICATE)
  * Запрос на получение доступа к автомобилям внутри организации при необходимости в результате обработки поступающих заявок
  * Взаимодействие с автомобилями внутри организации при наличии доступа

Зона ответственности - работа программного обеспечения на уровне автомобиля (ПО по управлению доступа к автомобилям).

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

==== CLIENT ====
  * Оставление заявок на заказы, в целом - обычный пользователь, если не требуется чего-то иного. Отличается от обычного пользователя тем, что согласился с условиями определенного договора.

==== GUEST ====
  * Регистрация
  * Просмотр страниц с публичными документами
  * Просмотр страниц с публичным описанием платформы и сервиса