Загальний огляд Інформаційного Повідомлення приватизації об’єкта оренди з невід’ємними поліпшеннями

Мета створення та нормативні засади

Відповідно до ЗУ “Про приватизацію державного і комунального майна” та постанови КМУ від 10.05.2018 року № 432 “Про затвердження Порядку проведення електронних аукціонів для продажу об’єктів малої приватизації та визначення додаткових умов продажу” розробити функціонал реєстру інформаційних повідомлень. В рамках Prozorro.Sale буде реалізовано сутність priority_announcement.

ЗУ "Про приватизацію державного та комунального майна"

Постанова

ТВ

Документ з вимогами до майданчиків

(Додати посилання)

Особливості реєстру

Особливості реєстру Інформаційних Повідомлень приватизації обʼєкта оренди з невідʼємними поліпшеннями

  1. Створення та робота із Інформаційним Повідомленням:
  1. Створення та робота із Процедурою та Аукціоном (МА):
  1. Виконання умов приватизації (контрактинг):

Структура даних

Посилання на схему

systemNamex-legalNameUax-legalNameEnTypereadOnlyОбовʼязковістьКоментар
idВнутрішній ідентифікаторIDstringtrue

owner Ідентифікатор майданчикаOwner IDstringtrue

ownerToken

stringtrue
Токен майданчика, через який створено об'єкт
objectId ІдентифікаторObject IDstringtrue
Example: JAS001-UA-20200220-12345
previousObjectIdІдентифікатор попереднього Інформаційного повідомленняPrevious Announcement Idstringtrue

автоматично підтягується з останнього Інформаційного повідомлення з однаковим asset

minLength: 1
example: JAS000-UA-YYYYMMDD-00000

titleНайменуванняAnnouncement titlebase.MultiLangfalse

Автоматично заповнюється з related asset.title, але може редагуватися.

minLength: 1

descriptionОписAnnouncement descriptionbase.MultiLangfalse

Автоматично заповнюється з related asset.description, але може редагуватися

minLength: 1

_specs




опис спеціфікацих за яких створюються похідні сутності
activeScenario

stringtrue

pipelineMethod

stringfalseТакEnum: [announcement, announcement-fast, announcement-manual, announcement-ultrafast, announcement-fast-prod, announcement-fast-prod-fast-first]
statusСтатус інформаційного повідомленняAnnouncement statusstringtrue
Enum: [pending, active_auction, active_contracting, sold, dissolved, deleted]
datePublishedДата публікаціїPublished datestring($date-time)true

dateModifiedДата останнього редагуванняDate modifiedstring($date-time)true

platformLegalDetailsПерелік та реквізити авторизованих електронних майданчиківPlatform legal detailsstringtrue
default: https://prozorro.sale/info/elektronni-majdanchiki-ets-prozorroprodazhi-cbd2
documents
















AnnouncementDocumentДокументи Інформаційного ПовідомленняAnnouncement Documentslist-object

Містить дані щодо структури документу
idІдентифікатор документуDocument IDstringtrue

titleНазва документуDocument titlebase.MultiLang


descriptionОпис документуDocument descriptionbase.MultiLang


urlПосилання на документDocument linkstringtrue
example: http://string.com
relatedDocumentПов'язаний документRelated documentstring

Ідентифікатор, що відображається тільки в документі digitalSignature та використовується
для відображення зв'язку між цифровим підписом та документом

example: 5e300ec4080b60d45dc28bb8

documentOfОб'єкт документуDocument objectstring

default: announcement

Enum: [announcement ]

documentTypeТип документуDocument typestring

Enum: [ notice, evaluationCriteria, contractProforma, clarifications, redemptionPreContract, сonstructionExpertise, essentialImprovements, valueConclusion, digitalSignature ]

datePublishedДата публікації документуDocument publishing datestring($date-time)true

x-default: now

dateModifiedОстання дата редагування документуDocument modified datestring($date-time)true

x-default: now

indexПараметр сортування ілюстраційDocument indexinteger($int64)

Чим менше значення поля, тим вище документ буде при відображенні на майданчиках.
Основним документом вважається документ з мінімальним значенням індексу.
Якщо параметр не зазначений, документи будуть виводитись останніми у переліку.
Якщо кілька документів мають однакове значення параметру, порядок сортування буде залежати від dateModified,
Пріоритет у документів доданих раніше.

formatФормат документуDocument formatstringtrue


languageМова документуDocument languagestring


hashХеш документуDocument hashstring


token

string


_ds_id

string

Ідентифікатор документа в document service

_ds_scope

string

Тип документа за доступом [public/private]

initialProps









ІnitialPropertiesПараметри для опису умов продажуDescribes extra properties used to build produced object



valueСтартова цінаStart pricebase.ValueWithTax
Так


guaranteeГарантійний внесокGuaranteebase.Value
Так


registrationFeeРеєстраційний внесокRegistration feebase.Value
Так


minimalStepРозмір кроку аукціонуMinimal stepbase.Value
Так


minNumberOfQualifiedBidsМінімальна кількість заявMinimal number of bidsinteger($int64)true

default: 1

bankAccountsБанківські рахунки організатораBank accountsbase.BankAccountsByType
Так

minItems: 3

accessDetailsПорядок ознайомлення з майном, час і місце проведення огляду об’єктаAuction access detailsbase.MultiLang


valueAddedTaxChargedНа фінальну суму нараховується ПДВValue added tax chargedboolean

default: true

dutchStepПараметри для опису умов продажуDescribes extra properties used to build produced objectbase.DutchStep

Поля dutchStepPercent та dutchStepValue автогенеруються на рівні ЦБД, без можливості внесення змін Організатором
Для поля dutchStepQuantity ЦБД формує дефолтне, Організатор має можливість змінити дефолтне значення.

saleConditionНаявність умов продажуSale conditionsstringfalse

default: yes

relatedEntitieі

base.RelatedEntity
Так

minItems: 1
maxItems: 1

список пов'язаних сутностей, які необхідні для створення сутностей producedEntities

decisions




AnnouncementDecision

 
Так

Рішення про затвердження умов продажу

decisionTitleНайменування рішенняDecision titlestring

Так

minLength: 1

decisionNumberНомер рішенняDecision numberstring
Так

minLength: 1

decisionDateДата рішенняDecision datestring($date-time)
Так


decisionOfТип рішенняDecision ofstring
Так

default: announcement

Enum:[ announcement ]

producedEntities

base.ProducedEntitytrue

default: List []

список створених сутностей

extraSpecs


ExtraSpec

 
Так

default: List []

поле необхідне для уточнення базових значень спеціфікацій

periodsУточнення до періодівBase periods specs overwrite configbase.PeriodSpec


dutchStepКрок голландського раундуDutch stepsbase.DutchStep


cancellations

base.Cancellation

x-format: list-object
default: List []

periods 

 

Опис всіх періодів об'єкта

rectificationPeriodПеріод редагування лотаRectification Periodbase.Period


timer

string($date-time)true

x-format: timer
x-serialize_when_none: false

час до наступної події

archiveId

stringtrue

x-format: object-id
x-serialize_when_none: false

proceduresInfo

multidicttrue

autogenerated field with information about all related procedures

 additionalInformation Додаткова інформаціяAdditional information list-object true

 default: List []

_meta

base.MetaDat


_version

integer($int64)true


_protected

booleantrue

default: false

Класифікатори та словники

Інформаційне Повідомлення має посилання (relatedEntities) на пов’язаний Об’єкт реєстру МП. При створенні Об’єкту реєстру МП використовуються обов’язкові словники: - основний класифікатор: CAV - додатковий класифікатор державного майна: dm

Логіка роботи з Класифікаторами описана у ТЗ по Об’єктам реєстру МП:
Посилання на ТЗ по Об'єкта реєстру МП

Періоди і статуси

Конфігураційний файл з періодами и статусами

Загальна схема процесу публікації Інформаційного Повідомлення

Схема “Загальний процес продажу об'єктів малої приватизації”

Функціонал ролей в рамках періодів

Timeline

Схема “Timeline Інформаційного Повідомлення”

Статуси Інформаційного Повідомлення

Схема “Модель статусів Інформаційного Повідомлення”

Опис періодів

Типи, опис документів та робота з ними

Під час публікації Інформаційного Повідомлення або під час періода виправлення помилок (rectificationPeriod), окрім додавання нових документів або заміни раніше доданих документів безпосередньо у Інформаційне Повідомлення, доступна можливість додати нові або оновити існуючі документи Об'єкта реєстру МП.

Загальні документи по розробці

Робота із сутностями та документами сутностей

В даному документі описані загальні та базові принципи та особливості роботи із сутностями (bid, award, documents, items, questions) та документами сутностей.

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

Робота із сутностями

Для роботи із сутностями (bid, award, documents, items, questions) процедури буде закладено 2 режими: 

Робота із документами

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

Будь-який приватний документ, який учасник завантажив до заяви на участь, має бути доступний для ознайомлення учаснику, який його завантажив та Замовнику аукціону, в якому учасник бере участь, у відповідний період процедури.

Етапи роботи із документами:

1-й етап: Користувач системи завантажує документ\документи в особистому кабінеті, після чого майданчик - завантажує документ\документи до DS та додає до відповідної сутності (завантажені документи зберігаються в ЦБД та відображаються на майданчику).

2-й етап: Користувач системи має наступні можливості:

Можливі два варіанти на вибір щодо відображення попередніх версій документів процедури, біда, аварду, протоколу на майданчику:

Виключенням є робота із скасуванням аукціону (documentType.cancellationDetails), завантаження такого документу та натискання кнопки відбувається в рамках першого етапу, тому працювати із таким документом в рамках ЦБД неможливо.

Всі зміни таких документів можуть відбуватися тільки на рівні майданчика.

* Після завершення аукціону, протягом періоду підписання протоколу (verificationPeriod), учасники мають можливість довантажити до bid'а набір документів для усунення формальних недоліків (усі типи документів, що дозволені для bid`а) - ТІЛЬКИ ДЛЯ RENEWABLES.
- У разі довантаження оновленої версії документу, тип документу (documentType) та його неймінг (legalName) має співпадати, з документом, який на етапі розміщення заяви було додано до bid'а. Можливо тільки довантажити документи, всю інформацію bid`а (поля та документи), яка була збережена в період подання пропозицій (tenderPeriod), змінювати неможливо.
- Видалення документів bid'а, які були завантажені в період подання пропозицій (tenderPeriod), на етапі кваліфікації заборонено.

Особливості роботи із цифровим підписом

Цифровий підпис (ЕЦП/КЕП) накладається поза ЦБД. Завантажується в ЦБД окремим файлом (тільки підпис або підписаний файл) digitalSignature, в якому присутнє поле relatedDocument, де додається посилання на оригінальний документ (id документу), вже завантажений до DocumentService.

relatedDocument - ідентифікатор, що відображається тільки в документі digitalSignature та використовується для відображення зв'язку між цифровим підписом та документом сутності процедури.

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

Цифровий підпис документу необов'язковий, обов'язковість вказується в ТЗ процедури, за умови відповідних вимог в нормативних документах.

Технічні особливості роботи із цифрового підпису

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

Обмежень щодо розширення файлу на стороні ЦБД відсутні

Вимоги до майданчиків

Можливі 2 варіанти реалізації цифрового підпису:

  1. Окремо документ цифрового підпису та назву/посилання на оригінальний документ
  2. Поряд з оригінальним документом виводити пов'язані файли цифрового підпису

Схеми по роботі з Інформаційним Повідомленням

Схема “Загальний процес”

Порядок малої приватизації під час дії воєного стану

Повідомлення

Повідомлення щодо публікації інформаційного повідомлення

Повідомлення щодо редагування Інформаційного Повідомлення

Повідомлення щодо розформування Інформаційного Повідомлення

Послідовність створення ланцюжка Процедур аукціонів

Послідовність та кількість аукціонів

Для продажу Об'єктів малої приватизації під час воєнного стану визначена наступна послідовність аукціонів та типи аукціонів: - Перший аукціон - англійський з переважним правом - Другий аукціон - англійський з переважним правом - Третій аукціон - англійський - Четвертий аукціон - англійський - Четвертий аукціон - англійський зі знижкою 50% - Пʼятий аукціон - голландський - Шостий аукціон - голландський зі знижкою 50%

Умови для створення наступної Процедури

Особливості часових параметрів

Для автоматичного створення та публікації Процедур аукціонів використовуються наступні параметри:

Приклад: якщо Перша Процедура набула статусу Procedure.status: unsuccessful, то Друга або Третя Процедура (в залежності від виконання умов) буде створена автоматично одразу.

Приклад:

Стартова ціна

Організатор задає значення стартової ціни першого аукціону (допускається тільки валюта - ГРН). Стартові ціни для наступних аукціонів розраховуються автоматично без можливості редагування.

Автоматичний перерахунок гарантійних внесків

то розмір ГВ розраховується як:

Має відбуватись перевірка: якщо дві будь-які Процедури по одному asset у всіх повʼязаних ІП знаходяться у статусі unsuccessful і обидві мають хоч один award у статусі unsuccessful, то має відпрацьовувати механіз перерахунку ГВ для всіх Процедур, окрім першої (бо для першої завжди == announcement.initialProps.guarantee ).

*- враховуються будь які попередні 2 аукціона з продажу об'єкта протягом поточного та всіх попередніх ІП Гарантійний внесок також може бути відредагований вручну Організатором безпосередньо у Процедурі (для другої та наступних процедур ланцюжка) під час clarificationPeriod (48 годин після публікації процедури)

  1. У Announcement Організатор заповняє поля guarantee
  2. При автоматичному створенні 1-ї Процедури SPE поля guarantee мають скопіюватись у SPE.
  3. В нас закладено, що у Першій Процедурі не має бути можливості редагувати поля guarantee, які скопіювались із Announcement
  4. При автоматичному створенні 2-ї Процедури SPE поле guarantee має == 20% від Поточної ціни Аукціона (поточна ціна ==  Стартовова ціна аукцінону)
  5. В нас закладено, що у Організатора має бути можливість редагувати поля guarantee у другій Процедурі SPE. Тобто, значення guarantee, яке ми заклали, - дефолтне, з можливістю змінити.
  6. При автоматичному створенні 3-ї Процедури SPE поле guarantee має == 20% від Поточної ціни Аукціона (поточна ціна ==  Стартовова ціна аукцінону)
  7. В нас закладено, що у Організатора має бути можливість редагувати поля guarantee у другій Процедурі SPE. Тобто, значення guarantee, яке ми заклали, - дефолтне, з можливістю змінити.
  8. При автоматичному створенні 4-ї Процедури SPD поле guarantee має == 20% від Поточної ціни лота (поточна ціна == 50% від Стартової)
  9. В нас закладено, що у Організатора має бути можливість редагувати поля guarantee у третій Процедурі SPE. Тобто, значення guarantee, яке ми заклали, - дефолтне, з можливістю змінити.
  10. При автоматичному створенні 5-ї Процедури SPD поле guarantee має == 20% від Поточної ціни лота (поточна ціна == 50% від Стартової)
  11. В нас закладено, що у Організатора має бути можливість редагувати поля guarantee у четвертій Процедурі SPD. Тобто, значення guarantee, яке ми заклали, - дефолтне, з можливістю змінити.
  12. При автоматичному створенні 6-ї Процедури SPD поле guarantee має == 20% від Поточної ціни лота (поточна ціна == 50% від Стартової)
  13. В нас закладено, що у Організатора має бути можливість редагувати поля guarantee у четвертій Процедурі SPD. Тобто, значення guarantee, яке ми заклали, - дефолтне, з можливістю змінити.

Виключення: якщо два будь-які попередні Аукціони у ланцюжку (навіть не підряд, а, наприклад, Перший і Третій) завершилися з причини дискваліфікації Bid-ів, то ми маємо підставити дефолтне значення guarantee, яке == 50% від Поточної ціни лота АБО 30 мінімальних заробітніх плат (обирається більше значення)

  1. При створенні ІП Організатор вказав стартову ціну (value) == 1 000 000 грн і guarantee == 200 000 грн
  2. При автоматичному створенні Першої Процедури SPE у ній value == 1 000 000 грн і guarantee == 200 000 грн. Організатор НЕ може вносити змін у це поле.
  3. При автоматичному створенні Другої Процедури SPE у ній value == 1 000 000 грн і guarantee == 200 000 грн. Організатор може вносити зміни у це поле протягом періоду редагування.
  4. При автоматичному створенні Третьої Процедури SPE у ній value == 1 000 000 грн і guarantee == 200 000 грн. Організатор може вносити зміни у це поле протягом періоду редагування.
  5. При автоматичному створенні Четвертої Процедури SPE у ній value == 500 000 грн і guarantee == 100 000 грн. (бо ціна SPE_1 / 2 == 500 000 грн і 20% == 100 000 грн). Організатор може вносити зміни у це поле протягом періоду редагування.
  6. При автоматичному створенні Пʼятої Процедури SPE у ній value == 500 000 грн і guarantee == 100 000 грн. (бо ціна SPE_1 / 2 == 500 000 грн і 20% == 100 000 грн). Організатор може вносити зміни у це поле протягом періоду редагування.
  7. При автоматичному створенні Пʼятої Процедури SPE у ній value == 500 000 грн і guarantee == 100 000 грн. (бо ціна SPE_1 / 2 == 500 000 грн і 20% == 100 000 грн). Організатор може вносити зміни у це поле протягом періоду редагування.

При автоматичному створенні будь якої з процедур МП має відбутись перевірка, чи попередні два аукціони мають дискваліфікованих бідів (з будь-якої причини):

Якщо в результаті дій Організатора виявилося, що guarantee перерахувалося згідно логіки Автоматичний перерахунок гарантійних внесків, то відповідні значення мають змінитись і в _specs.pipeline.stages[].calculatedData.guarantee.
Тобто, значення параметрів мають бути однакові в Процедурі і в Інформаційному повідомленні.

Логіка для розрахунку guarantee у наступних процедурах не міняється.

Правила заокруглення

У разі автоматичного розрахунку суми плат та/або внесків у випадках, якщо розмір відповідної суми включає числове значення менше копійки, ЦБД автоматично заокруглює відповідну суму за такими правилами: сума, що закінчується від 0,0001 до 0,4999 копійки, заокруглюється в бік зменшення до найближчої суми, яка дорівнює цілій копійці; сума, що закінчується від 0,5 до 0,9999 копійок, заокруглюється в бік збільшення до найближчої суми, яка дорівнює цілій копійці.

Логіка відображення створених та не створених Процедур у структурі відповіді Інформаційного Повідомлення (_specs.calculatedData)

1. Коли тільки створено ІП (announcement.status: pending), відповідь на запит по ІП має містити:

2. Коли створено Першу Процедуру (announcement.status: active_auction), відповідь має містити:

3. Коли створено Другу Процедуру (announcement.status: active_auction), відповідь має містити:

4. Коли створено Третю Процедуру (announcement.status: active_auction), відповідь має містити:

Коли завершується неуспішно Третя Процедура (Procedure.status: unsuccessful) із Ланцюжка, то необхідно перевірити, чи були у Третій Процедурі дискваліфіковані Біди і якщо Так, то створюється Четверта Процедура

У відповідь ІП необхідно додати інформацію про Четверту Процедуру:
5. Коли створено Четверту Процедуру (announcement.status: active_auction), відповідь має містити:

6. Коли Перша, Друга або Третя Процедура переходить у статус complete (Announcement.status:active_contracting)

Якщо в результаті дій Організатора виявилося, що guarantee перерахувалося згідно логіки Автоматичний перерахунок гарантійних внесків, то відповідні значення мають змінитись і в _specs.pipeline.stages[].calculatedData.guarantee.
Тобто, значення параметрів мають бути однакові в Процедурі і в Інформаційному повідомленні.

pipelineMethod

Зв'язок статусів усіх сутностей процесу малої приватизації

Матриця статусів