Содержание

Определения

Глобальный сервис программный продукт, обеспечивающий возможность сделать заказ цепочки услуг из любых сервисов, пользуясь технологиями платформы ShariX, вне зависимости от точки входа заказа (через API).
Metaservice (метасервис, meta - service) это видимая для клиента самостоятельная единица Сервиса как бизнеса. У одной компании (юрлица) может быть несколько сервисов. Один сервис может включать в себя результат взаимодействия нескольких компаний. Имеет свой брендинг, дизайн, позиционирование на рынке, набор конкретных услуг (service). Соответственно id_metaservice - идентификатор такого мета-сервиса.
id_metaservice уникальный идентификатор мета-сервиса, необходимый для синхронизации данных. Один и тот же провайдер может быть для нескольких мета-сервисов, соответственно если происходят изменения в одном, то либо форсируется изменение во всех (если возможно), либо снимается is_global. Соответственно при изменении is_global в true должно происходить согласование с остальными копиями в других сервисах. Нужен в том числе для того, чтобы выяснять, в каких еще сервисах есть этот провайдер.
service идентификатор конкретной услуги. Услуга обладает ценой и исполнителем. Соответственно id_service - идентификатор такой услуги.
is_global означает необходимость синхронизации данных, так как данные должны храниться на основной платформе, чтобы их можно было использовать в других услугах и сервисах, реализованных на платформе.
is_visible означает видимость для составления цепочки услуг. Цепочка услуг - последовательность услуг различных поставщиков/сервисов, покупаемых клиентом в “пакетном” режиме (например, аренда и доставка арендуемого предмета, или аренда нескольких предметов одновременно, или аренда и оказание услуги человеком на арендуемой площадке и так далее).
datalink адрес фактического размещения на физическом носителе, если информация настолько велика, что не может храниться внутри БД.

Общая схема

Синхронизируемая часть едина и неизменна для всех видов сервисов, если эти сервисы функционируют в состоянии подключения к платформе. Вся специфика по каршерингу выносится отдельно в локальную часть и хранится в отдельном репозитории.

Цвета заливки строк таблиц:

Серый значения, получаемые автоматом (идентификаторы, отметки времени и тп)
Зеленый то, что вводится пользователем текстом или вручную (например - написал имя)
Синий то, что является результатом обработки формой текущего интерфейса действий пользователя (например - поставил галку)
Фиолетовый то, что наследуется системой в результате действий пользователя (например - выбранный пользователь, сервис и так далее)

Текущая без раскраски (материал для ознакомления, требует сведение):

Прошлая схема БД:

Назначение таблиц

Client

Client – Клиент/пользователь/аккаунт в системе, который по логике получает услугу. В системе могут существовать пользователи, у которых не назначена роль клиента. Поэтому клиенты определены отдельной таблицей.

Provider

Provider – единица описания поставщика услуг/ответственного лица за определенный ресурс (например, машину). По сути - это надстройка к клиентскому аккаунту, иллюстрирующая, что данный пользователь может выступать не только в роли потребителя. То есть, по тому, какие “провайдеры” находятся по идентификатору пользователя - можно установить конкретный список услуг данного пользователя.

Поле Описание
type тип поставщика (партнер/ответственное лицо/поставщик услуг). Смысл такой - провайдер это статус пользователя, который, в зависимости от применения, может нести разный смысл и подразумевает под собой какой-то тип действия. Обычные исполнители - это провайдеры услуг (код 3). Ответственные за какое-то имущество, которые сдают его в аренду - это тоже провайдеры (код 2). Ответственные за набор услуг перед метасервисом (фактически - назначенные админы) - это провайдеры-партнеры (код 1)
company (id) уникальный идентификатор компании, от лица которой выступает провайдер. Смысл такой - ответственны могут быть только одушевленные лица, компании - не одушевленные. Все услуги предоставляются через компании-партнеры, самозанятые или ИП являются единицами таких компаний.
user_id (id) уникальный идентификатор конкретного пользователя системы (meta-user), который будет оказывать услугу. Один пользователь может быть провайдером нескольких услуг. Статус провайдера означает, что с данным пользователем может быть установлена связь, как с исполнителем.
requirements требования для того, чтобы можно было предоставлять услуги любые в этом метасервисе в целом (самые строгие)
status статус пользователя в системе относительно прохождения проверок (activity_status) (может быть active только в том случае, если ticket, влияющий на статус - закрыт.
ticket_status id последнего актуального тикета, касающийся статуса. Если он меняет статус на закрытый - вызывается проверка, которая смотрит, нет ли другого открытого по пользователю.
location_type статическая или динамическая локация оказания услуги. Если статическая, а исполнитель находится существенно за пределами локации - то тогда статус автоматом оффлайн для приема новых заявок.
default_location локация по умолчанию для объекта.

Resource

Resource/Список ресурсов – автомобили/дома/объекты сервиса.

Поле Описание
type_id определение типа ресурса по его уникальному идентификатору в соответствии с классификатором
user_id (id_responsible_user?) уникальный идентификатор ответственного (за состояние, доступность и так далее - то есть для договора) пользователя - идентификатор провайдера, по которому восстанавливается конкретный пользовательский аккаунт
requirements код необходимого (самый строгий) для того, чтобы ресурс мог стать активным.
status статус ресурса в системе относительно прохождения проверок (activity_status) (может быть active только в том случае, если ticket, влияющий на статус - закрыт.
ticket_status id последнего актуального тикета, касающийся статуса. Если он меняет статус на закрытый - вызывается проверка, которая смотрит, нет ли другого открытого по пользователю.

Relationship

Relationship/Взаимоотношение – описание связей (желательных - как имеющиеся договорные отношения, и нежелательных - как пожелание любой из сторон)

Поле Описание
id уникальный идентификатор связи
user_id_who (id) уникальный идентификатор инициатора договорных отношений
user_id_whom (id) уникальный идентификатор того с кем связываются
neg_type_id (id) тип договорных отношений по его уникальному идентификатору
requirements код необходимого (самый строгий) для того, чтобы ресурс мог стать активным. Оно вставляется автоматом, в соответствии с профилем метасервиса. Далее, если кому-то из партнеров или пользователей надо строже - применяется более строгий вариант на данную связь.
status (статус обработки заявки в системе заявок)
ticket_status id заявки, по которой происходит проверка статуса relationship. State меняется только в результате изменений в заявке.

Company

Company - это таблица с партнерами сервисов. Партнер сервиса - юридическое лицо или ИП, которое непосредственно организует работу с исполнителями и отвечает перед клиентами и перед сервисом за качество оказанных услуг. Юридически это лица, фактически оказывающие услуги по договору.

Поле Описание
legal_name настоящее имя юридического лица
representative (provider_id) уникальный идентификатор представителя компании. Это обязательно пользователь-провайдер определенного типа. То есть нельзя назначить ответственного, который не может быть ответственным.
requirements код необходимого (самый строгий) для того, чтобы ресурс мог стать активным. Оно вставляется автоматом, в соответствии с профилем метасервиса. Далее, если кому-то из партнеров или пользователей надо строже - применяется более строгий вариант на данную связь.
status (статус обработки заявки в системе заявок)
ticket_status id заявки, по которой происходит проверка статуса relationship. State меняется только в результате изменений в заявке.

Servicetype

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

Поле Описание
id идентификатор типа услуги
codename латинское наименование услуги в системе
caption наименование услуги для отображения пользователю
description текстовое описание услуги
requirements код требований на основе вспомогательных таблиц-справочников
price_type ценообразование - код допустимых вариантов или код параметров, принимаемых во внимание и способ их учета (по сути хорошо закодировать формулу)
status активность на основе системы заявок
ticket_status id последнего актуального тикета, касающийся статуса. Если он меняет статус на закрытый - вызывается проверка, которая смотрит, нет ли другого открытого по пользователю.
link_agreement ссылка на договор в вики об оказании услуги данного типа (аренда, перевозка и тп)

Service

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

Поле Описание
servicetype_id тип оказываемой услуги по классификатору услуг сервиса. По сути указание родительского элемента.
id_provider уникальный идентификатор поставщика услуг (фактически определяет, какой пользователь будет оказывать услугу). Одному заказу соответствует 1 услуга, которую выполняет конкретный Исполнитель (провайдер). Провайдер может при этом предлагать несколько услуг на выбор, но текущему заказу может соответствовать только одна.
resource_id так как ресурсы сами услугу оказать не могут, а также один ресурс может быть представлен в виде разных услуг, то фактически с точки зрения смысла системы ресурс - это как неодушевленный пользователь. Без провайдера, который с его помощью оказывает услугу - никуда. Поле остается пустым, если сервис не предусматривает использование услуг. Стоит обратить внимание, что это не обязательно ответственный за ресурс. Например, за состояние автомобиля может быть ответственен пользователь (он и указывается в таблице со свойствами ресурса), а услугу доступа или перевозки может оказывать иное лицо.
requirements код необходимого (самый строгий) для того, чтобы ресурс мог стать активным. Оно вставляется автоматом, в соответствии с профилем метасервиса. Далее, если кому-то из партнеров или пользователей надо строже - применяется более строгий вариант на данную связь.
id_metaservice уникальный идентификатор мета-сервиса, необходимый для синхронизации данных. Один и тот же провайдер может быть для нескольких мета-сервисов, соответственно если происходят изменения в одном, то либо форсируется изменение во всех (если возможно), либо снимается is_global. Соответственно при изменении is_global в true должно происходить согласование с остальными копиями в других сервисах. Нужен в том числе для того, чтобы выяснять, в каких еще сервисах есть этот провайдер.
price_alg шаблон алгоритма расчета цены для оказываемой услуги (по этой переменной определяется, какую функцию для расчета цены вызывать)
price_km значение параметра стоимости 1км данного поставщика для данного шаблона услуги
price_min значение параметра стоимости 1мин данного поставщика для данного шаблона услуги
price_amount значение параметра стоимости 1 услуги данного поставщика для данного шаблона услуги
service_status статус спецификации типа услуги, принимает значения Online, Offline, Preorder with Gap. Online/offline выставляются по проверке параметров и желанию пользователя (например, если пользователь переключает себя online, но по какой-то причине ему такую услугу оказывать запрещено - оно не переключится, то есть надо перед сменой значения этого поля всегда запускать проверку)
status активность на основе системы заявок
ticket_status id последнего актуального тикета, касающийся статуса. Если он меняет статус на закрытый - вызывается проверка, которая смотрит, нет ли другого открытого по пользователю.

Documents

Documents - это одна таблица со всеми документами. Вообще в концепции предполагалось, что таких таблиц должно быть много под каждый тип для удобства поиска. То есть отдельно таблица с паспортами, отдельно с правами, отдельно с какими-нибудь разрешениями и так далее. Базово на данном этапе - это сводная таблица.

Поле Описание
doc_type тип документа (паспорт/паспорт 1 страница и т д) в соответствии с классификатором типов документов (см описание в Requirements)
expire_date срок окончания действия документа.
datalink адрес фактического размещения на физическом носителе, если информация настолько велика, что не может храниться внутри БД.
userid уникальный идентификатор пользователя (конкретного клиентского аккаунта) являющегося владельцем данного документа
company_id идентификатор компании, к которой относится документ, если таковая есть (может не быть)
check_level (check-levels) информация об уровне проверки. Документ может быть проверен как платформой, так и мета-сервисом, так и партнером мета-сервиса, а может быть и никем (просто загружен). Указывается, так как достоверность проверки разная. Документ, проверенный только на низком уровне, не принимается во внимание как имеющийся до прохождения более высокоуровневой проверки. Информацию об уровнях проверки можно посмотреть по словарю Requirements. В данной таблице хранится информация о наиболее высоком уровне проверки.
checked_by userid проверившего
check_date timestamp проверки
status активность на основе системы заявок
ticket_status id последнего актуального тикета, касающийся статуса. Если он меняет статус на закрытый - вызывается проверка, которая смотрит, нет ли другого открытого по пользователю.

Permissions

Permissions/Разрешения - (проверки/экзамены). По смыслу это что-то вроде “документа на право что-то делать” - на данном этапе это ограничено метасервисом/платформой, при этом он может быть полностью цифровым (выданным платформой/сервисом).

Поле Описание
id_permission уникальный идентификатор определяющий наличие разрешения из множества в словаре - выданных пользователю/клиенту/аккаунту
id_metaservice уникальный идентификатор мета-сервиса, необходимый для синхронизации данных. check_level - тип проверки в соответствии с классификатором проверок.
user_id уникальный идентификатор пользователя/клиента/аккаунта, которым была пройдена проверка и получено разрешение
checked_by userid проверившего
check_date timestamp проверки
status (статус обработки заявки в системе заявок)
ticket_status id заявки, по которой происходит проверка статуса relationship. State меняется только в результате изменений в заявке.

Orders

Orders/Заказы current_orders (смысл такой, что записи в этой таблице могут меняться по ходу осуществления заказов, после - заказ записывается в историю - order_list_log)

Поле Описание
service_id спецификатор услуги провайдера, нужен для установления цены (id_service - уникальный идентификатор шаблона услуги, необходим для установления цены и исполнителей).
service_type_id тип заказа по классификатору услуг
state текущий статус заказа из возможных на платформе
time_placed время размещения заказа
time_start время начала оказания услуги
time_finish_predicted предварительное/расчетное время до окончания оказания услуги
time_finish_real фактическое время окончания (точное установленное время)
order_place_start место, которое фиксируется как точка с которой начался совершаться заказ
order_place_predicted предполагаемое место (например парковка) завершения заказа, может совпадать с начальным, а также обязательно должно быть доступным для завершения (в случае с авто - в разрешенной зоне завершения, например)
order_place_real фактическое место где был завершен заказ (например - машина припаркована “здесь”)
provider (id) уникальный идентификатор поставщика услуги/аккаунта, который оказывает услугу. Если несколько провайдеров собираются мета-сервисом в цепочку, где на уровне связи с клиентом нельзя установить одно ответственное лицо, то указывается вспомогательный мета-провайдер сервиса, и это означает, что мета-сервис несет ответственность перед пользователем за сборку услуги воедино.
receiver (id) пользователь/аккаунт, который принимает оказываемые услуги
client (id) клиент/аккаунт, который оплачивает все оказанные услуги
predicted_price расчетная цена с учетом тарифа поставщика услуг. predicted_price рассчитывается посредством вызова функции get_price на основе данных о поставщике, услуге, тарифе для услуги и предполагаемой длительности и километражу (если он актуален).
real_price цена с учетом тарифа поставщика услуг по факту оказания услуги. real_price рассчитывается после превышения predicted_price с интервалом раз в 10 минут и/или по завершению заказа