Загальні відомості

Цей документ дає роз’яснення для маркетплейсів щодо реалізації функцій Переліків оренди в ЕТС. Технічна інформація про безпосередні виклики та моделі даних доступна за посиланням https://procedure-sandbox.prozorro.sale/api/doc, розділ Registry

Поточна (перша) версія реєстрів є тимчасовою, і передбачає обмежений набір дій, який є мінімально необхідним для задоволення вимог, що містяться в НПА, які регламентують процес оренди державного/комунального майна в Україні

Слова “реєстр” і “перелік” в контексті цього документу тотожні

Авторизація користувачів та майданчиків

Операції запису/модифікації виконуються від імені майданчика. Для всіх сутностей реєстру в базі реєстру зберігається тільки ідентифікатор майданчика (поле owner). Інформація, яку майданчик передає в моделі організацій або користувачів, є виключно атрибутами сутностей, і участі в авторизації на боці бази реєстру не приймають.

Майданчик, по аналогії з ЦБД, забезпечує аутентифікацію та авторизацію кінцевих користувачів з накладенням аналогічних нефункціональних вимог до реалізації

Представник майданчика, перед наданням дозволу на реєстрацію користувача з певною роллю, на основі документів має пересвідчитись, що потенційний користувач має достатньо повноважень від своєї організації на ведення роботи в реєстрі. Для фізичних осіб, що претендують на роль Потенційного орендаря, зазначена перевірка повноважень природньо не потрібна

Ролі

Майданчик має надавати користувачу можливість діяти від наступних ролей з відповідним переліком доступних активностей:

• Орендодавець (sellingEntity):
  • Створення об’єкта. При цьому дані про користувача і його організацію мають примусово вноситись в модель sellingEntity
  • Редагування власного об’єкта
  • Створення дії
  • Редагування власної дії
  • Перегляд всіх існуючих об’єктів
  • Перегляд всіх існуючих дій
  • Перегляд всіх існуючих заявок
• Балансоутримувач (propertyOwner):
  • Створення об’єкта. При цьому дані про користувача і його організацію мають примусово вноситись в модель propertyOwner
  • Редагування власного об’єкта
  • Створення дії
  • Редагування власної дії
  • Перегляд всіх існуючих об’єктів
  • Перегляд всіх існуючих дій
  • Перегляд всіх існуючих заявок
• Потенційний орендар (requestor):
  • Створення заявки
  • Перегляд всіх існуючих об’єктів
  • Перегляд всіх існуючих дій
  • Перегляд всіх існуючих заявок
• Орган управління (governer):
  • Створення дії
  • Редагування власної дії
  • Перегляд всіх існуючих об’єктів
  • Перегляд всіх існуючих дій
  • Перегляд всіх існуючих заявок
• Орган охорони культурної спадщини (heritageController):
  • Створення дії
  • Редагування власної дії
  • Перегляд всіх існуючих об’єктів
  • Перегляд всіх існуючих дій
  • Перегляд всіх існуючих заявок

Органи управління та Органи охорони культурної спадщини, вірогідно, найближчим часом користуватись системою не будуть, тому їх створення можна відтермінувати

За погодженням з організаціями-користувачами майданчик може створювати додаткові ієрархії, функції підтвердження тощо всередині або між різними організаціями. В переліку вище наведено перелік обов’язкових функцій, які мають бути доступні на всіх майданчиках

Сутності і моделі даних

Реєстр передбачає наявність трьох основних видів сутностей - об’єкт, дія і заявка.

Реєстр не передбачає наявності будь-яких послідовних бізнес-процесів. Факт того, що певний набір об’єктів, заявок і дій пов’язаний одне з іншим, може (опціонально) бути зазначений користувачем, який володіє певними сутностями шляхом вказання пов’язаних сутностей. Наприклад, якщо заявка відноситься до вже існуючого об’єкту, то користувач може вказати в relatedObjectId ідентифікатор цього об’єкту. Або якщо дія має якусь попередню пов'язану дію, то користувач може вказати її ідентифікатор в relatedActionId

Моделі даних реєстру, назви яких співпадають з назвами базових моделей ЦБД, всередині також є цілком ідентичними. Модель base.ManagingEntity співпадає з моделлю base.SellingEntity ЦБД

Об’єкт

Сутність, що власне містить інформацію про певний фізичний об’єкт (або декілька однотипних фізичних об’єктів, об’єднаних в один логічний об’єкт), який потенційно може бути зданий в оренду. 

Об’єкт може бути одним з чотирьох типів:

• Нерухомість (registry.RealEstate, re)
• Єдиний майновий комплекс (registry.JointPropertyComplex, jpc)
• Транспорт (registry.Vehicle)
• Інше (registry.Other)

Один об’єкт може містити декілька фізичних об’єктів (item) одного типу (наприклад, декілька будівель в RealEstate). Створення об’єктів з різними типами item всередині тимчасово неможливо

Опис об’єкта складається з:

• Інформації про організації, які об’єктом керують на різних ролях (relatedOrganizations). ОНОВЛЕННЯ: на майданчику має бути реалізована можливість створення об'єктів виключно від імені юридичних осіб. Реєстр тимчасово дозволяє відправити відправити схему UA-IPN, наполегливе прохання не користуватись цим. Опція буде прибрана в найближчих релізах
• Інформації про рішення, які наразі прийнято по об’єкту (statusesDecisions). До цього ж блоку відноситься значення listType та statusInList, які визначають тип переліку (ключова інформація про об’єкт, яка визначає подальше проведення/непроведення аукціону)
• Інформація про обмеження, які будуть накладені на орендаря в разі укладення угоди оренди (leaseRules)
• Вартісних характеристики об’єкту (valuesCharacteristics)
• Електронних копії документів, що певним чином описують об’єкт (documents)
• Кількісно-якісні характеристики самого фізичного об’єкта (registryObjectItems). Може бути масивом. Складається з трьох основних частин:
  • Назва, опис та загальна класифікація (basicInfo)
  • Фізичне розташування (placing)
  • Характеристики, специфічні для конкретного типу об’єктів (*Props) 

Логіка заповнення полів: Обмеження щодо використання майна (заборонені цільові призначення) (intendedUse), Спосіб обмеження цільового призначення об'єкта(intendedUseRestrictionMethod), Цільове призначення об'єкта оренди (за наявності)(intendedUseRestrictionDescription) в структурі leaseRules

1. Якщо поле intendedUseRestrictionMethod має значення:
   
   1. Тільки зазначене (onlyDescribed) → 
      1. Поле intendedUse є неактивним
      2. Організатор повинен в полі intendedUseRestrictionDescription вручну ввести перелік дозволених призначень
2. Якщо поле intendedUseRestrictionMethod має значення:
   1. Окрім зазначеного (exceptDescribed) → 
      1. Організатор повинен в полі intendedUse обрати до 5-ти значень зі словника 
      2. Поле intendedUseRestrictionDescription є необов'язковим для заповнення організатором
3. Якщо поле intendedUseRestrictionMethod має значення:
   1. Без обмежень (No restrictions) → 
      1. Поле intendedUse є неактивним
      2. Поле intendedUseRestrictionDescription є необов'язковим для заповнення організатором

Дія

Сутність, яка забезпечує реалізацію активностей в ЕТС, які мають виконувати орендодавеці та балансоутримувачі (registry.LeaseAction). Перелік формальних дій, які мають виконувати представники цих організацій, доступний у вигляді переліку в кінці цього документу

Дія включає в себе інформацію про особу, що виконує дію (actingEntity). Модель має заповнюватись майданчиком автоматично з використанням авторизаційних даних користувача.

Окрім інформації про виконавця дії модель передбачає заповнення наступної інформації:

• Роль особи, що виконує дію (actingEntityRole)
• Тип дії (actionType). Перелік доступних типів передбачає тільки загальну категорізацію, і не має відповідності один-до-одного з переліком формальних дій. Наприклад, для варіантів 4 та 8 формальних дій має використовуватись опція decisionPublication
• Опису дії (actionDescription)
• Ідентифікатори сутностей, з якими логічно пов’язана дія (relatedObjectId, relatedRequestId, relatedActionId)
• Електронні копії пов’язаних документів (documents)

Поле actionStatus наразі є статичним і в бізнес-логіці участі не бере

Заявка

Сутність, яку має право створити будь-яка фізична або юридична особа, і в якій вона виявляє бажання  мати певні орендні відносини з державними/комунальними установами

Структура даних заявки передбачає інформацію про:

• Заявника (requestor). Може застосовуватись модель організації або контакту (для фізичної особи)
• Організацію, яка, на думку заявника є орендодавцем по потенційному об’єкту оренди (sellingEntity). У разі некоректного заповнення моделі заявка гарантовано не потрапить до відповідного орендодавця, оскільки пошук передбачається по ЄДРПОУ
• Тип заявки (requestType). Основні типи заявок - про включення об’єкту до реєстру та на продовження терміну дії актуального контракту оренди
• Ідентифікатор об'єкту, з якими логічно пов’язана заявка (relatedObjectId)
• Текстовий опис заявки (requestDescription)
• Пов’язані документи (documents)

Поле requestStatus наразі є статичним і в бізнес-логіці участі не бере

Синхронізація та пошук

Впродовж найближчого часу передбачається створення механізмів дзеркала (Mirror) та пошуку (Search) по аналогії з механізмами, що працюють в ЦБД. До моменту їх створення фактично майданчик може працювати тільки з об’єктами, власником яких він є. Це досягається шляхом збереження ідентифікаторів сутностей на боці майданчика, і наступним (за потреби) використанням ендпоінта GET /api​/registry​/{obj_id}

Сервіс документів

Робота з документами реалізована в точності так само, як і сервіс документів в ЦБД

Доступні активності

Нижче наведено короткий опис активностей, які мають надаватись користувачам згідно їх ролей

• Створення об’єкта

Метод:  POST ​/api​/registry​/{obj_type}

Має передаватись набір даних, що відповідає одній з моделей: 

1. registry.RealEstate
2. registry.JointPropertyComplex
3. registry.Vehicle
4. registry.OtherProperty

• Редагування власного об’єкта
  Метод: PATCH ​/api​/registry​/{obj_type}

Має передаватись відредагований набір даних

• Додавання item до раніше створених об’єктів
  Метод: PUT ​/api​/registry​/{obj_id}​/items

• Створення дії
  Метод: TBD

• Редагування власної дії
  Метод: TBD

• Створення заявки
  Метод: TBD

• Перегляд всіх існуючих об’єктів
  Метод: TBD

• Перегляд всіх існуючих дій
  Метод: TBD

• Перегляд всіх існуючих заявок
  Метод: TBD

Типи переліків

Для об'єктів реєстру важливою характеристикою є відношення об'єкту до певного переліку, а також статус об'єкту в цьому переліку

За ці дані відповідають поля об'єкту registry.%type%.statusesDecisions.listType так registry.%type%.statusesDecisions.statusInList

Всі об'єкти за замовчанням відносяться до першого типу переліку (listType = First). Значення listType = Second має бути цілеспрямовано зазначено орендодавцем

Значення statusInList:

• inactive передбачає, що об'єкт фактично не буде виставлятись на аукціон 
• approved передбачає, що має відбутись аукціон або організована оренда без аукціону
• waiting означає, що орендодавець ще не прийняв ніякого рішення

Передбачається, що будь-яке рішення по зміні значень listType та/або statusInList орендодавець має підтверджувати шляхом створення Дії, або, щонайменше, завантаженням електронної копії відповідного паперового рішення ьезпосередньо в об'єкт

Перелік формальних дій, що реалізуються за допомогою створення сутностей “Заявка” та “Дія”:

• Балансоутримувач надсилає орендодавцю копію рішення про намір передачі майна в оренду через ЕТС
• Орендодавець публікує рішення балансоутримувача через особистий кабінет в ЕТС (п. 23 Порядку)
• Балансоутримувач вносить в ЕТС інформацію про потенційний об’єкт оренди (п. 25, 26 Порядку)
• Балансоутримувач повідомляє орендаря про прийняте рішення про намір передачі об’єкта в оренду або про відмову у передачі об’єкта в оренду
• Балансоутримувач надсилає орендодавцю через ЕТС клопотання про включення об’єкту в перелік (п.п. 27, 28 Порядку)
• Орендодавець активує інформацію про потенційний об’єкт оренди (п.п. 25, 28 Порядку)
• Орендодавець публікує в ЕТС своє рішення про включення об’єкту до переліку 1 чи 2 типу (п.п. 27, 28 Порядку)
• Орендодавець повідомляє заявника через ЕТС про рішення про включення об’єкту до переліку 1 чи 2 типу або про відмову у включенні (п. 28 Порядку)
• Орендодавець повідомляє балансоутримувача через ЕТС про рішення про включення об’єкту до переліку 1 чи 2 типу або про відмову у включенні (п. 28 Порядку)
• Орендодавець публікує в ЕТС рішення про зміну або скасування рішення про включення об’єкту в Перелік (п. 33 Порядку)
• Орендодавець дозавантажує в ЕТС документи, що стосуються об’єкта
• Заявник подає орендодавцю через ЕТС уточнену заяву, якщо було відмовлено у включенні об’єкта в перелік на підставі п. 3,8 ч. 1 ст. 7 ЗУ (п. 31 Порядку)
• Потенційний орендар подає через ЕТС заяву на оренду об’єкта, що знаходиться в переліку 1 чи 2 типу (п. 50 Порядку)
• Орендодавець оприлюднює в ЕТС інформаційне повідомлення про передачу об’єкта оренди без проведення аукціону
• Орендодавець вносить / змінює інформацію про об’єкт в перелік 1 чи 2 типу
• Орендодавець виключає об’єкт із переліку 1 чи 2 типу
• Орендодавець змінює статус об’єкта в переліку 1 чи 2 типу
• Чинний орендар подає через ЕТС заяву на продовження договору оренди
• Балансоутримувача завантажує документи в ЕТС з можливістю закріплення їх за конкретною заявою по об’єкту незалежно від орендодавця.
• Орендодавець надсилає балансоутримувачу заяву про включення об’єкта в перелік через ЕТС.
• Комунікація між балансоутримувачем, уповноваженим органом управління, органом культурної спадщини, орендодавцем відбувається в ЕТС