Versions Compared

Old Version 9

changes.mady.by.user valeriia denysenko

Saved on

compared with

New Version 10

changes.mady.by.user valeriia denysenko

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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

...

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

...

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

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

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

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

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

  • Організатору
    • Коли - після створення Інформаційного Повідомлення в ЦБД та набуття їм статуса “Опубліковано” (pending)
    • Що - Інформаційне повідомлення опубліковане. Ви можете виправити технічні помилки протягом 48 годин після публікації.
    • Коментарі - Повідомлення надходить протягом 5 хв.

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

  • Організатору
    • Коли - після збереження змін у Інформаційному Повідомленні або Об’єкті, які зроблені протягом rectificationPeriod
    • Що - Зміни в Інформаційному Повідомленні успішно виконані
    • Коментарі - Повідомлення надходить протягом 5 хв.

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

  • Організатору
    • Коли - після набуття Інформаційним Повідомленням статусу “Об’єкт не продано” (dissolved)
    • Що - Інформаційне повідомлення розформовано. Для продовження продажу Об'єкта малої приватизації створіть нове Інформаційне Повідомлення
    • Коментарі - Повідомлення надходить протягом 5 хв.

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

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

...

titleДіаграма "Ланцюжок аукціонів для Малої приватизації""

сутностей

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

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

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

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

  • Режим 1 - робота з усім переліком сутностей одного типу. Для видалення, редагування або додавання сутності, майданчик передає повний перелік сутностей одного типу, який замінює попередній.
  • Режим 2 - робота з окремою сутністю, можливість звернутися до ID сутності та відредагувати всі або окремі її поля або видалити таку сутність.

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

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

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

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

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

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

  • змінити статус сутності, а саме натиснути відповідну кнопку в особистому кабінеті (після зміни статусу працювати із документами сутності, які були додані до неї у попередньому статусі, неможливо)
  • завантажити нові документи;
  • оновити завантажені документи (в DS версія попереднього документу залишається, а в сутності прибирається, після чого довантажується в DS новий документ, у якого додається поле з ID версії попереднього документу, історія зберігається в history)

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

  • Відображати документи перекресленими;
  • Виводити кнопку "Історія змін" (кнопка відображається у випадку, якщо dateModified документа відрізняється від datePublished)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Організатору
    • Коли - після створення Інформаційного Повідомлення в ЦБД та набуття їм статуса “Опубліковано” (pending)
    • Що - Інформаційне повідомлення опубліковане. Ви можете виправити технічні помилки протягом 48 годин після публікації.
    • Коментарі - Повідомлення надходить протягом 5 хв.

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

  • Організатору
    • Коли - після збереження змін у Інформаційному Повідомленні або Об’єкті, які зроблені протягом rectificationPeriod
    • Що - Зміни в Інформаційному Повідомленні успішно виконані
    • Коментарі - Повідомлення надходить протягом 5 хв.

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

  • Організатору
    • Коли - після набуття Інформаційним Повідомленням статусу “Об’єкт не продано” (dissolved)
    • Що - Інформаційне повідомлення розформовано. Для продовження продажу Об'єкта малої приватизації створіть нове Інформаційне Повідомлення
    • Коментарі - Повідомлення надходить протягом 5 хв.

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

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

Expand
titleДіаграма "Ланцюжок аукціонів для Малої приватизації""

draw.io Diagram
bordertrue
diagramNameІП з невід’ємними поліпшеннями
simpleViewerfalse
width
linksauto
tbstyletop
lboxtrue
diagramWidth321
revision4


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

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

  • Перша Процедура створюється автоматично по завершенню announcement.rectificationPeriod (Як тільки наступає announcement.rectificationPeriod.endDate)

  • Друга (можлива), Третя, Четверта, Пʼята та можлива Шоста Процедура аукціону автоматично створюється одразу, якщо попередня Процедура набула статусу unsuccessful.

  • Друга Процедура аукціону створюється тільки у випадку, коли Перша Процедура аукціону перейшла в статус unsuccessful. внаслідок дискваліфікації учасників де один з учасників, учасник з переважним правом з будь-якої причини. Якщо на етапі кваліфікації award-ів відбулася дискваліфікація переможця, а можливий наявний другий учасник сам відмовився від очікування (award.status:cancelled) або також був дискваліфікований, то такий аукціон вважається зірваним і це є причиною створення Другої Процедури. Тобто, логіка наступна: якщо Процедура-1 має статус unsuccessful і у неї є хоч один award (але обовʼязково учасник з переважним правом) у статусі unsuccessful, то має створитись Процедура-2, якщо серед учасників в статусі unsuccessful немає учасника з переважним правом, тоді створюється Процедура - 3.

  • Шоста Процедура аукціону створюється тільки у випадку, коли Пʼята

...

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

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

  • Перша Процедура створюється автоматично по завершенню announcement.rectificationPeriod (Як тільки наступає announcement.rectificationPeriod.endDate)

  • Друга, Третя та можлива Четверта Процедура аукціону автоматично створюється одразу, якщо попередня Процедура набула статусу unsuccessful.

  • Четверта Процедура аукціону створюється тільки у випадку, коли третя Процедура аукціону перейшла в unsuccessful внаслідок дискваліфікації учасників з будь-якої причини. Якщо на етапі кваліфікації award-ів відбулася дискваліфікація переможця, а можливий наявний другий учасник сам відмовився від очікування (award.status:cancelled),то такий аукціон вважається зірваним і це є причиною створення четвертої шостої Процедури. Тобто, логіка наступна: якщо Процедура-3 5 має статус unsuccessful і у неї є хоч один award у статусі unsuccessful, то має створитись Процедура-46.

  • Якщо статус Процедури змінено на cancelled, то наступна Процедура не створюється, а Інформаційне Повідомлення автоматично набуває статусу dissolved.

  • За замовчанням кількість аукціонів - 34. Мінімальна кількість -1 (якщо Перша процедура успішна).Можливий Четвертий , Можливий 2й та 6й аукціон за умови, що Третій Перший та Пʼятий відповідно завершився з причини дискваліфікації Учасників.

  • В залежності від значення tenderAttempts, відображати назву аукціону:

    • 1 - "Аукціон з переважним правом"
    • 2 - "Повторний аукціон з переважним правом" 
    • 3 1 - "Аукціон без умов або аукціон з умовами"
    • 2 4 - "Аукціон із зниженням стартової ціни"
    • 3 5 - "Аукціон за методом покрокового зниження стартової ціни та подальшого подання цінових пропозицій"
    • 4 6 - "Повторний аукціон за методом покрокового зниження стартової ціни та подальшого подання цінових пропозицій"

...

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

  • Період на подачу пропозицій (робочих днів) (extraSpecs[].periods.periodName: tenderPeriod duration)
    • Особливості:
      • Визначається Організатором;
      • Значення загальне для 2-*, 3-, 4-, 5-, 6-ї* Процедури із ланцюжка;
      • Період на подачу пропозицій - це tenderPeriod, який буде мати 2-*,3-,4-,5-, 6-ї*та Процедура.
      • ЦБД валідує тільки нижнє значення tenderPeriodDuration >= 3 р.д.;
      • ЦБД не валідує верхнє значення tenderPeriodDuration.
    • Технічна особливість: На інтерфейсі Майданчика при створенні ІП має бути одне поле, в якому Організатор може вказати тривалість "Періоду прийняття пропозицій". Органіщатор Організатор вказує кількість в днях один раз на інтерфейсі.
    • Але коли Майданчик передає запит на ЦБД, то має це значення закопіювати і передати в трьох місцях: extraSpecs[1].periods.periodName: tenderPeriod duration, extraSpecs[2].periods.periodName: tenderPeriod duration, extraSpecs[3].periods.periodName: tenderPeriod duration, extraSpecs[4].periods.periodName: tenderPeriod duration, extraSpecs[5].periods.periodName: tenderPeriod duration

Приклад:

  • Перша Процедура набула статусу Procedure.status: unsuccessful у п’ятницю 1615.0905.20222026
  • Друга Процедура буде автоматично створена у п'ятницю 1615.0905.2022 2026 одразу.
  • У Другої Процедури розпочинається tenderPeriod, який буде тривати таку кількість робочих днів, яку вказав Організатор у полі “Період на подачу пропозицій”. День створення Другої Процедури не враховується.
    • Якщо Організатор вказав extraSpecs.periods.periodName: tenderPeriod duration == 20 днів, то tenderPeriod починається у дату створення Процедури, але відрахунок 20-ти днів має починатися з 1918.0905.2022 2026 (понеділок);
    • Якщо Дата початку Модулю Аукціону припадає на вихідний або святковий день, то Аукціон буде перенесений вперед на найближчий робочий день.

...

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

...

  • При створенні ІП у запиті на ЦБД мають передаватись заповнені поля guarantee. Їх заповнює Організатор.

  • На стороні ЦБД валідація лише на "обов'язковість заповнення".

  • На майданчику можна пропонувати Організатору автозаповнення полей guarantee, що == 20% стартової ціни поточного аукціона (20% від announcement.InitialProps.value).

  • Протягом 48 годин, доки у ІП триває rectificationPeriod поле guarantee можна редагувати.

  • Для першої процедури у ланцюжку ГВ завжди копіюється із announcement.initialProps.guarantee.

  • Для другої і наступних Процедур у ланцюжку, якщо будь які попередні два аукціона* з продажу цього Об’єкта не відбулись (статус процедури “unsuccessful”) з наступних причин дискваліфікації учасників (статус аварду “unsuccessful”):

    • Не відповідає вимогам статті 8 ЗУ "Про приватизацію державного і комунального майна”;
    • Не подав документи або відомості, обов’язкове подання яких передбачено ЗУ “Про приватизацію державного і комунального майна”;
    • Подав неправдиві відомості про себе;
    • Відмовився від підписання протоколу про результати електронного аукціону;
    • Відмовився від укладення договору;
    • Відмовився від підписання протоколу аукціону або договору купівлі-продажу щодо того самого об’єкта приватизації, що підтверджується відповідним актом;
    • Не сплатив ціну продажу об’єкта приватизації у встановлений строк щодо того самого об’єкта приватизації, що підтверджується відповідним актом;
    • Не сплатив ціну продажу об'єкта приватизації у встановлений строк.

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

  • 50% стартової ціни поточного аукціону АБО
  • 30 мін заробітних плат станом на 01.01. року, у якому оприлюднюється Інформаційне Повідомлення; треба обрати більше з двох значень.

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

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

  • Логіка розрахунку guarantee при створенні Процедур у ланцюжку ІП:
  1. У Announcement Організатор заповняє поля guarantee
  2. При автоматичному
    3. створенні 
  3. створенні 1-ї
    4.  Процедури
  4.  Процедури SPE поля guarantee мають скопіюватись у SPE.
  5. В нас закладено, що у Першій Процедурі не має бути можливості редагувати поля guarantee, які скопіювались із Announcement
  6. При автоматичному
    7. створенні 
  7. створенні 2-ї
    8.  Процедури
  8.  Процедури SPE поле guarantee має == 20%
    9. від 
  9. від Поточної
    10.  ціни
  10.  ціни Аукціона (поточна ціна == 50%
    11. від 
  11. від Стартової)
  12. В нас закладено, що у Організатора має бути можливість редагувати поля guarantee у другій Процедурі SPE. Тобто, значення guarantee, яке ми заклали, - дефолтне, з можливістю змінити.
  13. При автоматичному
    14. створенні 
  14. створенні 3-ї
    15.  Процедури
  15.  Процедури SPD поле guarantee має == 20%
    16. від 
  16. від Поточної
    17.  ціни
  17.  ціни лота (поточна ціна == 50%
    18. від 
  18. від Стартової)
  19. В нас закладено, що у Організатора має бути можливість редагувати поля guarantee у третій Процедурі SPD. Тобто, значення guarantee, яке ми заклали, - дефолтне, з можливістю змінити.
  20. При автоматичному
    21. створенні 
  21. створенні 4-ї
    22.  Процедури
  22.  Процедури SPD поле guarantee має == 20%
    23. від 
  23. від Поточної
    24.  ціни
  24.  ціни лота (поточна ціна == 50%
    25. від 
  25. від Стартової)
  26. В нас закладено, що у Організатора має бути можливість редагувати поля 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 має відбутись перевірка, чи перші два аукціони мають дискваліфікованих бідів (з будь-якої причини):
  • якщо НІ: guarantee == 100 000 грн. (бо ціна у \SPD_3 == 500 000 грн і 20% == 100 000 грн.) Організатор може вносити зміни у це поле протягом періоду редагування.
  • якщо ТАК: guarantee == 250 000 грн (бо ціна у SPD_3 == 500 000 грн і 50% == 250 000 грн.) Організатор може вносити зміни у це поле протягом періоду редагування.
  1. При автоматичному створенні Четвертої Процедури SPD має відбутись перевірка, чи серед попередньо проведених трьох аукціонах, хоча б два аукціони мають дискваліфікованих бідів (з будь-якої причини):
  • якщо НІ: guarantee == 100 000 грн. (бо ціна у SPD_4 == 500 000 грн і 20% == 100 000 грн.) Організатор може вносити зміни у це поле протягом періоду редагування.
  • якщо ТАК: guarantee == 250 000 грн (бо ціна у SPD_4 == 500 000 грн і 50% == 250 000 грн.) Організатор може вносити зміни у це поле протягом періоду редагування.

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

  • Виключення: Якщо при створенні Announcement Організатор вказав стартову ціну (value) == 1 000 000 грн і guarantee == 300 000
    •  грн
  •  грн то Перша Процедура має створитися з guarantee == 300 000 грн

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

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

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

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

...

  • Кількість Процедур у ланцюжку - три;
  • Порядковий номер кожної процедури:
    • Для Першої Процедури tenderAttempts == 1
    • Для Другої Процедури tenderAttempts == 2
    • Для Третьої Процедури tenderAttempts == 3
  • Статус кожної Процедури - scheduled;
  • sellingMethod:
    • Перша Процедура - smallPrivatization-englishenglishPriority
    • Друга Процедура - smallPrivatization-english
    • Третя Процедура - smallPrivatization-english
    • Четверта Процедура - smallPrivatization-dutch
  • Стартова ціна Об'єкта (value):
    • Перша Процедура - announcement.initialProps.value
    • Друга Процедура - announcement.initialProps.value
    • Третя Процедура - 50% від announcement.initialProps.valueТретя
    • Четверта Процедура - 50% від announcement.initialProps.value
  • Крок аукціону (minimalStep):
    • Для Першої Процедури - значення, що вказав Організатор при створенні ІП у announcement.initialProps.minimalStep
    • Для Другої Процедури - значення, що дорівнює 1% від value Поточної Другої Процедури.
    • Для Третьої Процедури - значення, що дорівнює 1% від value Поточної Третьої Процедури.
  • Дата проведення аукціону (periods.periodName:auctionPeriod:startDate):
    • Для Першої Процедури це дата, яку вказав Організатор у полі extraSpecs.periods.auctionPeriod.startDate при створенні ІП
    • Для Другої і Третьої Процедури ця дата не визначена і поле виводити не потрібно.
  • Період між аукціонами (periods.periodName:tenderPeriod.duration):
    • Для Першої Процедури - відсутній
    • Для Другої і Третьої Процедури значення, що вказав Організатор при створенні ІП у extraSpecs.periods.periodName:tenderPeriod.duration
  • Розмір гарантійного внеску (guarantee):
    • Для Першої Процедури значення, що Організатор вніс у announcement.initialProps.guarantee
    • Для Другої і Третьої Процедури по формулі: announcement.initialProps.guarantee == 20% від (50% від announcement.initialProps.value)

...