...

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

Порядок малої приватизації

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

...

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

Робота із сутностями та документами сутностей відбувається за стандартною схемою (додати посилання) 

Перелік документів

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

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

В даному документі описані загальні та базові принципи та особливості роботи із сутностями (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 хв.

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

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

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

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

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

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

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

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

...

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

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

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

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

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

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

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

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

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

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

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

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

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

• Дата початку Першого аукціону (extraSpecs.periods.periodName: auctionPeriod startDate)
  • Особливості:
    • Дата аукціону визначається Організатором;
    • Час аукціону визначається ЦБД в період з 11:00 - 13:00 при автоматичному створенні Першої Процедури;
    • Перша Процедура буде буде створена автоматично, як тільки завершиться announcement.rectificationPeriod. Модуль Аукціону буде запущено у дату, яку вказав Організатор у Дата початку Першого аукціону та час визначений ЦБД при створенні процедури. У період між датою створення Першої Процедури і “Дата початку Першого аукціону” триває tenderPeriod Першої Процедури, який завершується о 20:00 дня, що передує дню “Дата початку Першого аукціону”.
    • Період між створенням Першої Процедури і “Дата початку Першого аукціону” не може бути менше 4 робочих днів (auctionPeriod_startDate >= currentDate + 4 wd);
    • Максимальна кількість днів між створенням Першої Процедури і “Дата початку Першого аукціону” 366 календарних днів.
    • Друга та наступні Процедури створюються автоматично одразу, тільки якщо попередня Процедура із ланцюжка ІП набула статусу Procedure.status: unsuccessful або unpublished - статуси яких набувають 2-а та 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

Приклад 1:

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

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

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

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

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

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

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

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

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

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

Значення tenderAttempts не змінюється від кількості оголошених Процедур

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

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

• Дата початку Першого аукціону (extraSpecs.periods.periodName: auctionPeriod startDate)
  • Особливості:
    • Дата аукціону визначається Організатором;
    • Час аукціону визначається ЦБД в період з 11:00 - 13:00 при автоматичному створенні Першої Процедури;
    • Перша Процедура буде буде створена автоматично, як тільки завершиться announcement.rectificationPeriod. Модуль Аукціону буде запущено у дату, яку вказав Організатор у Дата початку Першого аукціону та час визначений ЦБД при створенні процедури. У період між датою створення Першої Процедури і “Дата початку Першого аукціону” триває tenderPeriod Першої Процедури, який завершується о 20:00 дня, що передує дню “Дата початку Першого аукціону”.
    • Період між створенням Першої Процедури і “Дата початку Першого аукціону” не може бути менше 4 робочих днів (auctionPeriod_startDate >= currentDate + 4 wd);
    • Максимальна кількість днів між створенням Першої Процедури і “Дата початку Першого аукціону” 366 календарних днів.
    • Друга та наступні Процедури створюються автоматично одразу, тільки якщо попередня Процедура із ланцюжка ІП набула статусу Procedure.status: unsuccessful

Приклад: якщо Перша Процедура набула статусу 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

Приклад 1:

• 1-а Процедура набула статусу Procedure.status: unsuccessful у п’ятницю 15.05.2026 де було дискваліфіковано всіх учасників які приймали участь в кваліфікації, але серед них не було учасника з переважним правом
• 2-а Процедура буде автоматично створена у п'ятницю 15.05.2026 одразу.
• У 2-ї Процедури розпочинається tenderPeriod, який буде тривати таку кількість робочих днів, яку вказав Організатор у полі “Період на подачу пропозицій”. День створення Процедури не враховується.
  • Якщо Організатор вказав extraSpecs.periods.periodName: tenderPeriod duration == 20 днів, то tenderPeriod починається у дату створення Процедури, але відрахунок 20-ти днів має починатися з 18.05.2026 (понеділок);
• У 3-,4-,5-ї Процедури розпочинається tenderPeriod, за умови переходу попередньої опублікованої Процедури в статус unsuccessful, який буде тривати таку кількість робочих днів, яку вказав Організатор у полі “Період на подачу пропозицій”. День створення Процедури не враховується.
  • Якщо Організатор вказав extraSpecs.periods.periodName: tenderPeriod duration == 20 днів, то tenderPeriod починається у дату створення Процедури, але відрахунок 20-ти днів має починатися з 18.05.2026 (понеділок);
• 5-а Процедура статусу Procedure.status: unsuccessful:
  • Не було учасників в Процедурі → 6-а Процедура не публікується + 6-а Процедура в spec[1] автоматично перейде у статус unpublished
  • Було дискваліфіковано всіх учасників які приймали участь в кваліфікації →  6-й Процедурі розпочинається tenderPeriod, який буде тривати таку кількість робочих
• Перша Процедура набула статусу Procedure.status: unsuccessful у п’ятницю 15.05.2026 де було дискваліфіковано всіх учасників які приймали участь в кваліфікації, але серед них не було учасника з переважним правом
• Друга Процедура буде автоматично створена у п'ятницю 15.05.2026 одразу.
• У Другої Процедури розпочинається tenderPeriod, який буде тривати таку кількість робочих 
  • днів, яку вказав Організатор у полі “Період на подачу пропозицій”. День створення
  Другої
  • Процедури не враховується.
    • Якщо Організатор вказав extraSpecs.periods.periodName: tenderPeriod duration == 20 днів, то tenderPeriod починається у дату створення Процедури, але відрахунок 20-ти днів має починатися з 18.05.2026 (понеділок);
    Якщо Дата початку Модулю Аукціону припадає на вихідний або святковий день, то Аукціон буде перенесений вперед на найближчий робочий день.

Приклад 2:

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

Приклад 3:

• У 4-,5-ї Процедури розпочинається tenderPeriod, за умови переходу попередньої опублікованої Процедури в статус unsuccessful, який буде тривати таку кількість робочих днів, яку вказав Організатор у полі “Період на подачу пропозицій”. День створення Процедури не враховується.
  • Якщо Організатор вказав extraSpecs.periods.periodName: tenderPeriod duration == 20 днів, то tenderPeriod починається у дату створення Процедури, але відрахунок 20-ти днів має починатися з 18.05.2026 (понеділок);
• 5-а Процедура статусу Procedure.status: unsuccessful:
  • Не було учасників в Процедурі → 6-а Процедура не публікується + 6-а Процедура в spec[1] автоматично перейде у статус unpublished
  • Було дискваліфіковано всіх учасників які приймали участь в кваліфікації →  6-й Процедурі
• Перша Процедура набула статусу Procedure.status: unsuccessful у п’ятницю 15.05.2026 де було дискваліфіковано всіх учасників які приймали участь в кваліфікації і серед них був учасник з переважним правом
• Друга Процедура буде автоматично створена у п'ятницю 15.05.2026 одразу і набуде статусу unpublished.
• Третя Процедура буде автоматично створена у п'ятницю 15.05.2026 одразу після набуття другою Процедурою статусу unpublished
• У Третьої Процедури
  • розпочинається tenderPeriod, який буде тривати таку кількість
   
  • робочих
   
  • днів, яку вказав Організатор у полі “Період на подачу пропозицій”. День створення
  Другої
  • Процедури не враховується.
    • Якщо Організатор вказав extraSpecs.periods.periodName: tenderPeriod duration == 20 днів, то tenderPeriod починається у дату створення Процедури, але відрахунок 20-ти днів має починатися з 18.05.2026 (понеділок);
    Якщо Дата початку Модулю Аукціону припадає на вихідний або святковий день, то Аукціон буде перенесений вперед на найближчий робочий день.

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

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

...