Про цей документ
Цей документ дає роз’яснення для маркетплейсів щодо реалізації функцій Переліків оренди в ЕТС. Технічна інформація про безпосередні виклики та моделі даних доступна за посиланням 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)
Дія
Сутність, яка забезпечує реалізацію активностей в ЕТС, які мають виконувати орендодавеці та балансоутримувачі (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}
Має передаватись набір даних, що відповідає одній з моделей:
- registry.RealEstate
- registry.JointPropertyComplex
- registry.Vehicle
- 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 типу
- Чинний орендар подає через ЕТС заяву на продовження договору оренди
- Балансоутримувача завантажує документи в ЕТС з можливістю закріплення їх за конкретною заявою по об’єкту незалежно від орендодавця.
- Орендодавець надсилає балансоутримувачу заяву про включення об’єкта в перелік через ЕТС.
- Комунікація між балансоутримувачем, уповноваженим органом управління, органом культурної спадщини, орендодавцем відбувається в ЕТС