Загальний огляд Інформаційного Повідомлення

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

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

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

TODO

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

Особливості реєстру Інформаційних Повідомлень у ЦБД-2 (оновленій)

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

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

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

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

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

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

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

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

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

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

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

Timeline

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Діаграма “Ланцюжок аукціонів для Малої приватизації під час воєнного стану”

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

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

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

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

Приклад: якщо Перша Процедура набула статусу 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% від Поточної ціни Аукціона (поточна ціна == 50% від Стартової)
  5. В нас закладено, що у Організатора має бути можливість редагувати поля guarantee у другій Процедурі SPE. Тобто, значення guarantee, яке ми заклали, - дефолтне, з можливістю змінити.
  6. При автоматичному створенні 3-ї Процедури SPD поле guarantee має == 20% від Поточної ціни лота (поточна ціна == 50% від Стартової)
  7. В нас закладено, що у Організатора має бути можливість редагувати поля guarantee у третій Процедурі SPD. Тобто, значення guarantee, яке ми заклали, - дефолтне, з можливістю змінити.
  8. При автоматичному створенні 4-ї Процедури SPD поле guarantee має == 20% від Поточної ціни лота (поточна ціна == 50% від Стартової)
  9. В нас закладено, що у Організатора має бути можливість редагувати поля guarantee у четвертій Процедурі SPD. Тобто, значення guarantee, яке ми заклали, - дефолтне, з можливістю змінити.

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

  1. При створенні ІП Організатор вказав стартову ціну (value) == 1 000 000 грн і guarantee == 200 000 грн
  2. При автоматичному створенні Першої Процедури SPE у ній guarantee == 200 000 грн. Організатор НЕ може вносити змін у це поле.
  3. При автоматичному створенні Другої Процедури SPE у ній guarantee == 100 000 грн. (бо ціна у \SPE_2 == 500 000 грн і 20% == 100 000 грн). Організатор може вносити зміни у це поле протягом періоду редагування.
  4. При автоматичному створенні Третьої Процедури SPD має відбутись перевірка, чи перші два аукціони мають дискваліфікованих бідів (з будь-якої причини):
  1. При автоматичному створенні Четвертої Процедури SPD має відбутись перевірка, чи серед попередньо проведених трьох аукціонах, хоча б два аукціони мають дискваліфікованих бідів (з будь-якої причини):

Якщо в результаті дій Організатора виявилося, що 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

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

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