Содержание
Определения
Глобальный сервис | программный продукт, обеспечивающий возможность сделать заказ цепочки услуг из любых сервисов, пользуясь технологиями платформы 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 минут и/или по завершению заказа |