Очікуваний результат

Організатор - Гарантований покупець  вказує єдину дату при заведенні процедури - орієнтовний час початку аукціону (auctionPeriod.startDate у запиті, auctionPeriod.shouldStartAfter у api після створення процедури).

Точну дату початку торгів визначає система з огляду на поточну завантаженість, інформація про точну дату фіксується автоматично у полі auctionPeriod.startDate

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

Дата не редагується

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

ЦБД:

виходячи с бажаної дати проведення вказаної організатором та навантаження ЦБД розраховує дату проведення аукціону, яка фіксується автоматично у полі auctionPeriod.startDate, а після остаточного визначення системою дати проведення торгів, значення поля  автоматично переписується, з бажаної  дати на остаточну.
Дата  проведення визначена ЦБД не може бути відредагована

Очікуваний результат:

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

збереження чернетки без обмежень 

публікація процедури  з чернетки без заповненої  auctionPeriod.startDate (бажана дата проведення аукціону) неможливе

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

збереження чернетки без обмежень 

публікація процедури  з чернетки без заповненої  auctionPeriod.startDate (бажана дата проведення аукціону) неможливе

ЦБД: 
при спробі передати в полі auctionPeriod.startDate (бажана дата проведення аукціону) менша за дату на момент публікації, то ЦБД формує помилку про некоректність  введенної дати, дата не зберігається

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

збереження чернетки без обмежень 

публікація процедури  з чернетки без заповненої  auctionPeriod.startDate (бажана дата проведення аукціону) неможливе

Роль

Гарантований покупець - Організатор

Передумови

Завантаження clarifications - Уточнення до питань заданих учасниками. Опис причин редагування

Очікуваний результат:

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

Майданчик: 
після публікації аукціону  Організатор протягом  active.rectification (Період редагування) може відредагувати процедуру.

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

Для збереження виправлень обов'язково завантажується документ clarifications ( Уточнення до питань заданих учасниками. Опис причин редагування)

Очікуваний результат:

При переведені після публікації  процедури в режим редагування значення дати не доступне для редагування
При спробі редагування процедуру після публікації, значення полів Значення  полів: дата проведення аукціону, бажаний об'єм не можуть бути відредаговані заблоковані та/або при спробі виправлення виводиться попередження про помилку. Корегування не зберігається

ЦБД:
при спробі примусового  редагування даних раніше записаних до полів дата проведення аукціону та бажаний об'єм виникає помилка про неможливість внесення змін та/або неможливість збереження змін. 

CBD3-GE-UC-002.2n

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

Майданчик:

після публікації аукціону  Організатор- гарантований покупець протягом  active.rectification (Період редагування) може відредагувати процедуру. Організатор видаляє значення  полів: дата проведення аукціону, бажаний об'єм  та зберігає виправлену процедуру.

ЦБД:

при спробі примусового  видалення даних раніше записаних до полів дата проведення аукціону та бажаний об'єм виникає помилка про неможливість внесення змін та/або неможливість збереження змін. 

Роль

ЦБД

Передумови

Очікуваний результат:

Перенесення дати (перепланування аукціону) можливе у випадку непередбачуваних технічних збоїв під час проведення аукціонів з метою захисту прав Учасників торгів (fail-safe поведінка), і виконується автоматично на стороні ЦБД або у випадку адміністративного втручання, якщо штатні механізми ЦБД не відпрацювали коректно і автоматичного перенесення не відбулось.

ЦБД: 

Перенесення дати (перепланування аукціону) можливе у випадку непередбачуваних технічних збоїв під час проведення аукціонів з метою захисту прав Учасників торгів (fail-safe поведінка), і виконується автоматично на стороні ЦБД або у випадку адміністративного втручання, якщо штатні механізми ЦБД не відпрацювали коректно і автоматичного перенесення не відбулось.

Роль

Гарантований покупець - Організатор

Передумови

Очікуваний результат

Лише Організатор може оголосити електронні торги, сформувавши їх параметри та опублікувавши умови продажу майна\права користування та вимоги до учасників.

Майданчик:
Лише власник облікового запису з типом "Організатор - Гарантований покупець" має право завести, оформити та оголосити торги за процедурою ЗЕ. 

Очікуваний результат: 

Лише Організатор може оголосити електронні торги, сформувавши їх параметри та опублікувавши умови продажу майна\права користування та вимоги до учасників.

Майданчик: 

у ролі Учасник та Спостерігач кнопка для створення процедури та форма для створення процедури відсутні

ЦБД:

При спробі передати до ЦБД поля, що належать до полей задіяних при створені процедури виникає помилка, дані не передаються, процедура не створюється

Роль

Гарантований покупець - Організатор

Очікуваний результат

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

Майданчик:  

Організатор до публікації має право зберегти процедуру у статусі draft. 
Це - обов’язковий функціонал, що має бути присутній на майданчику

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

Майданчик:

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

Роль

Гарантований покупець - Організатор

Передумови

Очікуваний результат

 Майданчик забезпечує можливість редагування сформованої заявки на проведення Електронних торгів (чернетки) до моменту публікації оголошення про проведення Електронних торгів у ЦБД. У Організатора є можливість оголосити аукціон на основі попереднього аукціону (створити копію аукціону)               

Майданчик:

Організатор до публікації має право право переглянути, відредагувати  та зберегти процедуру у статусі draft.
Така процедура редагується, повторно зберігається та видаляється без обмежень.
При  публікації процедури з раніше створенного/збереженного/попередньо відредагованої чернетки відбувається перевірка валідності даних, що передаютьься. 
При відсутності невалідних даних в полях процедура публікується без зауважень

Роль

Гарантований покупець - Організатор

Передумови

Очікуваний результат: 

При публікації оголошення про проведення аукціону, Організатором  вноситься  інформація (частина полів заповнюються системою автоматично)

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

• Назва аукціону
• Опис аукціону
• Дата початку торгів 
• Встановлення “Зеленого тарифу” (граничний розмір ставки учасника)
• Розміри гарантійного внеску;
• Інформація про лот (мінімум 1)
  • Обмежити вибір класифікаторами по типам генерації. Можливо потрібно буде розширити стандарт
  • Завжди МВт
• опис лоту
• код відповідного класифікатору лоту: CAV, CPV
• одиниці виміру активу\активів
• кількість активів (обсяг квоти)
• Адреса розташування активу (не обов'язково до заповнення)
• Документація до торгів (послання)
• Та інші обов’язкові поля

ЦБД: 

При передачі від майданчика до API  дані аналізуються на корректність та записуються до відповідних полів 

перелік полей: https://docs.google.com/spreadsheets/d/1P3PDY0RPXewHPat0CTSXW_K3bq29bJDefCgzFWBDgAU/edit?ts=5dc421bd#gid=1942304127

Очікуваний результат: 
При публікації оголошення про проведення аукціону, Організатором  вноситься  інформація (частина полів заповнюються системою автоматично)

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

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

• Назва аукціону
• Опис аукціону
• Дата початку торгів 
• Встановлення “Зеленого тарифу” (граничний розмір ставки учасника)
• Розміри гарантійного внеску;
• Інформація про лот (мінімум 1)
  • Обмежити вибір класифікаторами по типам генерації. Можливо потрібно буде розширити стандарт
  • Завжди МВт
• опис лоту
• код відповідного класифікатору лоту: CAV, CPV
• одиниці виміру активу\активів
• кількість активів (обсяг квоти)
• Адреса розташування активу (не обов'язково до заповнення)
• Документація до торгів (послання)
• Та інші обов’язкові поля
  але залишає незаповненим хоча б одне обов'язкове поле

ЦБД: 

При передачі від майданчика до API  дані аналізуються на заповнення всіх обов'язкових полів.  В разі виявлення незаповненого поля генерується помилка з повідомленням про необхідність заповнення усіх обов'язкових полів.

перелік полей: https://docs.google.com/spreadsheets/d/1P3PDY0RPXewHPat0CTSXW_K3bq29bJDefCgzFWBDgAU/edit?ts=5dc421bd#gid=1942304127

Очікуваний результат: 
При публікації оголошення про проведення аукціону, Організатором  вноситься  інформація (частина полів заповнюються системою автоматично)

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

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

• Назва аукціону
• Опис аукціону
• Дата початку торгів 
• Встановлення “Зеленого тарифу” (граничний розмір ставки учасника)
• Розміри гарантійного внеску;
• Інформація про лот (мінімум 1)
  • Обмежити вибір класифікаторами по типам генерації. Можливо потрібно буде розширити стандарт
  • Завжди МВт
• опис лоту
• код відповідного класифікатору лоту: CAV, CPV
• одиниці виміру активу\активів
• кількість активів (обсяг квоти)
• Адреса розташування активу (не обов'язково до заповнення)
• Документація до торгів (послання)
• Та інші обов’язкові поля
  але залишає незаповненим хоча б одне обов'язкове поле

ЦБД: 

При передачі від майданчика до API  дані аналізуються на заповнення всіх обов'язкових полів.  В разі виявлення поля заповненого невалідними даними  генерується помилка з повідомленням про необхідність заповнення валіними даними усіх обов'язкових полів (з вказанням проблемного поля)

перелік полей: https://docs.google.com/spreadsheets/d/1P3PDY0RPXewHPat0CTSXW_K3bq29bJDefCgzFWBDgAU/edit?ts=5dc421bd#gid=1942304127

CBD3-GE-UC-008

Роль

Учасник

Передумови

Очікуваний результат: 

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

Майданчик: 

Перевірка відповідністі учасника вимогам висунутим Організатором лежить  повністю на майданчику, за замовчуванням вважається, що відображені документи перевірено, а гарантійний внесок сплачено. Майданчик має проставляти відповідну відмітку (з датою та часом перевірки).

ЦБД: 

після натискання на майданчику кнопки- підтвердження перевірки документів та вчасного внесення гарантійного внеску в ЦБД фіксується час та дата натскання кнопки

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

Майданчик: 

Перевірка відповідністі учасника вимогам висунутим Організатором лежить  повністю на майданчику, за замовчуванням вважається, що відображені документи перевірено, а гарантійний внесок сплачено. Майданчик не проставляє відповідну відмітку (з датою та часом перевірки).

ЦБД: 

Після перевірки пакету документів та наявності сплаченого  гарантійного внеску майданчик передає таку відмітку до ЦБД

CBD3-GE-UC-009

Роль

Учасник

Передумови

Очікуваний результат
До завершення аукціону з Учасниками напряму контактують виключно Оператори електронних майданчиків. 

Майданчик:

До завершення аукціону відсутній зв’язок замовника та потенційних переможцем/ями. Всі консультації надає майданчик.

ЦБД: 

До завершення аукціону відсутній зв’язок замовника та потенційних переможцем/ями. Всі консультації надає майданчик.

Майданчик:

Учасник знаходить інформацію про організатора та намагається задати йому питання.

CBD3-GE-UC-010 

Роль

Передумови

Status: active.rectification (Період редагування)

Очікуваний результат:

Після публікації аукціону, система визначає startDate та endDate періоду редагування з урахуванням дати, переданої при публікації до ЦБД.

Майданчик:

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

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

• сторінці  аукціону на майданчику
• сторінці  аукціону на сайті ДП ПП
• у полях startDate та endDate в арі

ЦБД: 

Після натискання кнопки "Опублікувати"  Організатором - гарантованим покупцем до ЦБД передаються наступні автогенеровані поля:

1. ata.id

2. data.auctionID
3. data.owner
4. data.items.id
5. Масив полей документу, якщо він був завантажений під час створення оголошення
data.documents.id
data.documents.url
data.documents.datePublished
data.documents.dateModified

 ЦБД розраховує, повертає майданчику та відображає в api startDate та endDate  active.rectification (Період редагування)

ЦБД: 

Після натискання кнопки "Опублікувати"  Організатором - гарантованим покупцем до ЦБД передаються наступні автогенеровані поля:

1. data.id

2. data.auctionID
3. data.owner
4. data.items.id
5. Масив полей документу, якщо він був завантажений під час створення оголошення
data.documents.id
data.documents.url
data.documents.datePublished
data.documents.dateModified

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

CBD3-GE-UC-011

Роль

ЦБД

Передумови

Status:  

Очікуваний результат

Створена процедура набуває статусу active.rectification. З виконанням цих дій до створеної процедури додаються поля, що генеруються автоматично, в тому числі тривалості періодів. 

ЦБД:

статус  процедури одразу по публікації  active.rectification, окрім статусу процедури в api фіксується  startDate та endDate  active.rectification

Очікуваний результат:

Створена процедура набуває статусу active.rectification. З виконанням цих дій до створеної процедури додаються поля, що генеруються автоматично, в тому числі тривалості періодів. 

Майданчик:
Після публікації процедура не набуває статусу active.rectification, не формується  значення  startDate та endDate  active.rectification (Період редагування) та статус процедури - Період редагуванння  не відображається на майданчику

ЦБД:

ЦБД одразу по публікації не присвоює статус  active.rectification, відповідно новий статус нефіксується в арі та  в api не  фіксується  startDate та endDate  active.rectification

Очікуваний результат:

Створена процедура набуває статусу active.rectification. З виконанням цих дій до створеної процедури додаються поля, що генеруються автоматично, в тому числі тривалості періодів. 

ЦБД:

Після публікації процедура набуває статусу active.rectification який фіксується в арі
 значЗння  startDate та endDate  active.rectification (Період редагування) та статус процедури - Період редагуванння   заповнюється не валідними датами, сформовані невалідні строки  передаються майданчику

CBD3-GE-UC-012

Роль

Передумови

Status: active.rectification (Період редагування)

Актуальний результат:

Створена процедура  набуває статусу active.rectification. З виконанням цих дій до створеної процедури додаються поля, що генеруються автоматично, в тому числі тривалості періодів. Період редагування завжди триває 48 один. 
rectificationPeriod.startDate, при цьому, дорівнює моменту появи процедури в ЦБД.   rectififcationPeriod.endDate визначається як (rectificationPeriod.startDate + 48 год)

Майданчик: 

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

• сторінці  аукціону на майданчику
• сторінці  аукціону на сайті ДП ПП
• у полі rectificationPeriod.startDate в арі

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

• сторінці  аукціону на сайті ДП ПП
• у полі rectififcationPeriod.endDate  в арі

Та завжди розраховується як rectificationPeriod.startDate + 48 годин

ЦБД:

Після публікації процедури дата початку періоду редагування завжди дорівнює моменту публікацыъ а обидві дати фіксуються в арі

Дата закінчення періоду редагування фіксується в арі та  завжди розраховується як rectificationPeriod.startDate+ 48 годин

Актуальний результат:

Створена процедура  набуває статусу active.rectification. З виконанням цих дій до створеної процедури додаються поля, що генеруються автоматично, в тому числі тривалості періодів. Період редагування завжди триває 48 один. 
rectificationPeriod.startDate, при цьому, дорівнює моменту появи процедури в ЦБД.   rectififcationPeriod.endDate визначається як (rectificationPeriod.startDate + 48 год)

Майданчик: 

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

• сторінці  аукціону на майданчику
• сторінці  аукціону на сайті ДП ПП
• у полі rectificationPeriod.startDate в арі

Дата закінчення періоду редагування не  відображається на:

•  сторінці  аукціону на майданчику
• сторінці  аукціону на сайті ДП ПП
• у полі rectififcationPeriod.endDate  в арі

Та завжди розраховується як rectificationPeriod.startDate + 48 годин

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

Дата закінчення періоду редагування фіксується в арі та  завжди розраховується як rectificationPeriod.startDate+ 48 годин

Актуальний результат:

Створена процедура  набуває статусу active.rectification. З виконанням цих дій до створеної процедури додаються поля, що генеруються автоматично, в тому числі тривалості періодів. Період редагування завжди триває 48 один. 
rectificationPeriod.startDate, при цьому, дорівнює моменту появи процедури в ЦБД.   rectififcationPeriod.endDate визначається як (rectificationPeriod.startDate + 48 год)

Майданчик:

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

• сторінці  аукціону на майданчику
• сторінці  аукціону на сайті ДП ПП
• у полі rectificationPeriod.startDate в арі

Дата закінчення періоду редагування не  відображається на:

•  сторінці  аукціону на майданчику
• сторінці  аукціону на сайті ДП ПП
• у полі rectififcationPeriod.endDate  в арі

Та розраховується як rectificationPeriod.startDate +/- 48 годин

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

Дата закінчення періоду редагування фіксується в арі та  розраховується як rectificationPeriod.startDate +/- 48 годин

CBD3-GE-UC-013

                                                                                                                               Фунціонал API ЦБД

Роль

Передумови

Очікуваний результат

Документи аукціону є можливість завантажувати і після завершення періоду редагування.

Актуальний результат: 

Документи аукціону є можливість завантажувати\змінювати і після завершення періоду редагування, а саме до завершення періоду прийому пропозицій - tenderPeriod.endDate.

Завершення періоду редагування не блокує можливості довантажити/замінити документи до аукціону. Видалення документів неможливе. Документ що був замінений відображається перекресленим.

Майданчик:
майданчик  блокує можливість повного видалення документу, попередньо завантажений документ можливо лише замінити, при цьому, замінений документ відображається перекресленим. Можливість завантажити і продивитися замінений документ зберігається.
Довантаження та заміна документів зберігається до завершення періоду прийому пропозицій - tenderPeriod.endDate.

ЦБД:
і замінений і документ на який замінили відображаються в арі
тип та інші параметри, окрім посилання на документ, дати та часу завантаження, ідентичні

Майданчик:

при спробі видалення документу формується помилка та повідомлення про те, що документ можливо лише замінити 
Довантаження та заміна документів зберігається до завершення періоду прийому пропозицій - tenderPeriod.endDate.

ЦБД:

при спробі видалити зафіксований  в арі документ формується помилка про недопустимість  такої дії

Майданчик:

при спробі видалення документу поза межами tenderPeriod

формується помилка та повідомлення про те, що документ можливо лише замінити 
Довантаження та заміна документів зберігається до завершення періоду прийому пропозицій - tenderPeriod.endDate.

ЦБД:

при спробі видалити зафіксований  в арі документ поза tenderPeriod.endDate формується помилка про недопустимість  такої дії

Роль

Передумови

Очікуваний результат:

Під час rectificationPeriod’у Організатор має змогу відредагувати окремі поля, інформація про це міститься у таблиці зі структурою даних.

Майданчик:

Протягом active.rectification (періоду редагування) можливо редагувати поля  згідно таблиці

ЦБД:

поля відредаговані в період active.rectification (періоду редагування)  перезаписуються, попередні значення не зберігаються

procuringEntity- Organization, Гарантований покупець (безпосередньо заводить процедуру і проводить аукціон), required
procuringEntity.identifier.id- Рядок, Для схеми UA-EDR - код ЄДРПОУ або ІПН
procuringEntity.identifier.legalName- Рядок, Повна юридична назва (наприклад - ПУБЛІЧНЕ АКЦІОНЕРНЕ ТОВАРИСТВО "УКРПОШТА")
lotIdentifier- Рядок, Номер лоту, required
title- Рядок, Найменування об’єкту, required
description- Рядок, Опис лоту, required
value- Value, Стартова вартість аукціону “Зелений тариф”, required
guarantee- Guarantee, Розмір гарантійного внеску, required
minimalStep- Value, Мінімальний крок аукціону
tenderAttempts- Integer, Лоти виставляються, не обов'язково. При публікації: Значення від 1 до 10, та варіант “Невідомо”. Якщо інформація відсутня, в інтерфейсі                        майданчика нічого не  відображається 
items- Array of Items, обов’язково. Склад лоту, актив. Активи, які входять у склад лоту, лот має містити не менше одного  item`у
documents- Array of Documents. Усі документи та пов’язані додатки. Документація, що стосується продажу лоту на аукціоні і додається Організатором під час публікації                       або редагування торгів. Наприклад фото, типовий договір і т.д.

ЦБД:
при спробі передати від майданчика нові значення полів, що не можуть змінюватися, формується помилка, інформаційне повідомлення про недопустимість дій, а зміни не зберігаються

CBD3-GE-UC-015

Роль

Учасник

Передумови

Період редагування: rectificationPeriod

Очікуваний результат

На час rectificationPeriod вводиться обмеження на рівні ЦБД по розміщенню закритих цінових пропозицій. Публікація закритих цінових пропозицій можлива після завершення цього періоду. 

Майданчик: 

До завершення rectificationPeriod (Періоду редагування)  розміщенню закритих цінових пропозицій заборонено. Публікація закритих цінових пропозицій можлива після завершення цього періоду. 

ЦБД:

До завершення rectificationPeriod (Періоду редагування)  на рівні ЦБД заблоковано розміщення закритих пропозицій

Очікуваний результат:

На час rectificationPeriod вводиться обмеження на рівні ЦБД по розміщенню закритих цінових пропозицій. Публікація закритих цінових пропозицій можлива після завершення цього періоду. 

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

ЦБД:
При спробі передачі до ЦБД закритої цінової пропозиції до завершення rectificationPeriod , ЦБД формує помилку про недопустимість таких дій, цінова пропозиція не приймається та не фіксується у арі

CBD3-GE-UC-016

Роль

Гарантований покупець - Організатор

Передумови

Очікуваний результат

Значення rectificationPeriod.endDate не може змінюватись Організатором.

Майданчик:
Дата завершення періоду завершення  періоду редагування rectificationPeriod.endDate завжди визначається автоматично та не може бути відредаговане Організатором 

ЦБД: 

rectificationPeriod.endDate не може бути відредаговано стандартними методами

CBD3-GE-UC-017

Роль

Організатором

Передумови

Настання Період уточнень: rectificationPeriod

Очікуваний результат

Значення rectificationPeriod.endDate не може змінюватись Організатором.

Актуальний результат

Дата завершення періоду редагування розраховується автоматично при публікації процедури в ЦБД та не може бути змінена при редагуванні процедури

Майданчик:

Дата завершення періоду редагування розраховується автоматично при публыкації та не може бути відредагованою при переведені процедури в режи редагування

ЦБД: 

rectificationPeriod.endDate  розраховується автоматотично та не може бути відредаговано.

Роль

Організатор

Передумови

Status: active.rectification (Період редагування)

Очікуваний результат:

Тип процедури (procurementMethodType) неможливо змінити.

Майданчик:

Тип процедури присвоюється автоматично системою та не може бути змінено

ЦБД:

Тип процедури procurementMethodType присвоюється автоматично системою та не може бути змінено

Роль

Організатор

Передумови

Status: active.rectification (Період редагування)

Очікуваний результат:
Для роботи із переліком сутностей (bid, award, documents, items, questions) одного типу майданчик передає повний перелік сутностей одного типу, який замінює попередній.

Майданчик:

Для видалення, редагування або додавання сутності, майданчик передає повний перелік сутностей одного типу, який замінює попередній. Стосується усіх сутностей

ЦБД:

ЦБД приймає від майданчика перелік замінених сутностей одного типу та оновлює або видаляє сутності

Очікуваний результат:
Для роботи із переліком сутностей (bid, award, documents, items, questions) одного типу майданчик передає повний перелік сутностей одного типу, який замінює попередній.

Стосується усіх сутностей

Майданчик:

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

ЦБД:

ЦБД не  приймає від майданчика перелік замінених сутностей, якщо перелік містить сутності різного типу. Формується помилка про неможливість оновити перелік сутностей, перелік не оновлюється або не видаляє сутності

Роль

Організатор

Передумови

Status: active.rectification (Період редагування)

Для редагування\додавання items необхідно передавати повний перелік існуючих items (їх id). У випадку додавання item, якщо не передати попередній перелік, буде пропатчено перший item. 

Для редагування доступні поля items: address, description і т.д.

Очікуваний результат

Для роботи із сутностями (bid, award, documents, items, questions) процедури буде закладено  режим:
- робота з окремою сутністю, можливість звернутися до ID сутності та відредагувати всі або окремі її поля або видалити таку сутність.

Майданчик:

Для роботи із окремим сутностями (bid, award, documents, items, questions) реалізується можливість звернутися до ID сутності та відредагувати всі або окремі її поля або видалити таку сутність

ЦБД:

ЦБД приймає від майданчика, видаляє або оновлює нові дані конкретного ID сутності або окремого її поля

Очікуваний результат

Для роботи із сутностями (bid, award, documents, items, questions) процедури буде закладено  режим:
- робота з окремою сутністю, можливість звернутися до ID сутності та відредагувати всі або окремі її поля або видалити таку сутність.

CBD3-GE-UC-021

                                                                                                                                              Фунціонал майданчиків

Роль

Організатор

Передумови

Status: active.rectification (Період редагування)

Очікуваний результат

У Виконавця присутня можливість виправити мета інформацію і вкладені файли (виклик  PUT /documents/{did} )і після завершення періоду редагування, але до переведення contract`y до статусу active.  і після завершення періоду редагування. При цьому, змінені файли відображаються на веб-сайті Майданчика перекресленими.

Майданчик:

Організатор має змогу відредагувати мета інформацію та вкладені файли  (виклик  PUT /documents/{did} ) після завершення active.rectification (Період редагування)

замінені документи доступні для завантаження та перегляду, відображаються в інтерфейсах перекресленим

повне видалення інформації неможливе

ЦБД:
і замінений і документ на який замінили відображаються в арі
тип та інші параметри, окрім посилання на документ, дати та часу завантаження, ідентичні

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

CBD3-GE-UC-017/1

Роль

Передумови

Настання Період уточнень: enquiryPeriod

Очікуваний результат

Період уточнень - час, коли учасники задають питання, а Організатор відповідає на них - називається enquiryPeriod. enquiryPeriod.startDate співпадає з rectificationPeriod.startDate. enquiryPeriod.endDate співпадає з tenderPeriod.endDate

Майданчик:

Початок періоду уточнень  enquiryPeriod співпадає з початком періоду редагування rectificationPeriod, а дата завершення періоду уточнень співпадає з кінцем періоду подачі закритих пропозицій tenderPeriod 

Дата відображається на: 

• сторінці аукціону на майданчику
• сторінці  аукціону на сайті  ДП ПП
• в полях enquiryPeriod.startDate та tenderPeriod.endDate в арі

майданчик "підтягує" з ЦБД та відображає на сторінці аукціону назву періоду в якому перебуває процедура

•  Період уточнень, при цьому дата початка періоду уточнень  починається з початком періодом редагування 
• Дата завершення періоду уточнень співпадає з кінцем періоду подачі закритих пропозицій

ЦБД/API: 

enquiryPeriod.startDate = rectificationPeriod.startDate

enquiryPeriod.endDate = tenderPeriod.endDate

Очікуваний результат

Період уточнень - час, коли учасники задають питання, а Організатор відповідає на них - називається enquiryPeriod. enquiryPeriod.startDate співпадає з rectificationPeriod.startDate. enquiryPeriod.endDate співпадає з tenderPeriod.endDate

Майданчик:

Початок періоду уточнень  enquiryPeriod не співпадає з початком періоду редагування rectificationPeriod, а дата завершення періоду уточнень співпадає з кінцем періоду подачі закритих пропозицій tenderPeriod 

Дата відображається на: 

• сторінці аукціону на майданчику
• сторінці  аукціону на сайті  ДП ПП
• в полях enquiryPeriod.startDate та tenderPeriod.endDate в арі

майданчик "підтягує" з ЦБД та відображає на сторінці аукціону назву періоду в якому перебуває процедура

•  Період уточнень, при цьому дата початка періоду уточнень  починається з початком періодом редагування 
• Дата завершення періоду уточнень співпадає з кінцем періоду подачі закритих пропозицій

enquiryPeriod.startDate не співпадає з rectificationPeriod.startDate

enquiryPeriod.endDate не співпадає з tenderPeriod.endDate

Роль

Передумови

Настання Період уточнень: enquiryPeriod

Очікуваний результат

Особливості Періоду уточнень: enquiryPeriod

1. можливість учаснику задати питання закінчується за 1 день (о 18: 00 за київським часом, попереднього дня) до enquiryPeriod.endDate

2. організатор може надавати відповіді в рамках всього enquiryPeriod

Актуальний результат

Особливості даного періоду:

- можливість учаснику задати питання закінчується за 1 день (о 18: 00 за київським часом,  попереднього дня) до enquiryPeriod.endDate

- організатор може надавати відповіді в рамках всього enquiryPeriod

Приклад роботи з питаннями у туторіалі api-docs:   https://procedure-prozorro-sale.raccoongang.com/api/doc#/questions 

Майданчик: 

у Учасника немає бути можливості задати питання після 18: 00 за київським часом, дня що передує дню проведення торгів 

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

Приклад роботи з питаннями у туторіалі api-docs:   https://procedure-prozorro-sale.raccoongang.com/api/doc#/questions 

ЦБД:

з моменту  настання 18: 00 за київським часом, попереднього дня до enquiryPeriod.endDate учасник втрачає можливість задавати питання
організатор може надавати відповіді в рамках всього enquiryPeriod

Актуальний результат

Особливості даного періоду:

- можливість учаснику задати питання закінчується за 1 день (о 18: 00 за київським часом,  попереднього дня) до enquiryPeriod.endDate

- організатор може надавати відповіді в рамках всього enquiryPeriod

Приклад роботи з питаннями у туторіалі api-docs:   https://procedure-prozorro-sale.raccoongang.com/api/doc#/questions 

Майданчик: 

У випадку спроби  Учасника  задати питання після 18: 00 за київським часом, дня що передує дню проведення торгів  формується помилка, повідомлення про неможливість задати питання, питання не публікується, повідомлення Гарантованому покупцеві про нове питання не надсилається

у організатора повинна бути можливість відповісти на запитання учасників в рамках всього періоду enquiryPeriod

Приклад роботи з питаннями у туторіалі api-docs:   https://procedure-prozorro-sale.raccoongang.com/api/doc#/questions 

CBD3-GE-UC-019/1

Роль

Передумови

Настання Період уточнень: enquiryPeriod

Очікуваний результат

Майданчики зобов’язані:

• надсилати Організатору аукціону сповіщення про нові питання. 
• сповіщати Організатора раз на 24 години про наявність питань без відповідей.

Всі питання / відповіді зберігаються в ЕТС і є доступними всім для перегляду, незалежно від статусу Електронних торгів. 

Майданчик: 

при наявності питання до лоту/аукціону майданчик надсилає Гарантованому покупцеві сповіщення про таке питання
при наявності питання БЕЗ відповіді до лоту/аукціону майданчик надсилає Гарантованому покупцеві сповіщення про таке питання один раз на добу 

Майданчик надсилає в персональний кабінет та на пошту повідомлення про отримання запитання. В разі ненадання відповіді, повідомлення про питання надсилається 1 раз на добу.

Майданчики зобов’язані:

• надсилати Організатору аукціону сповіщення про нові питання. 
• сповіщати Організатора раз на 24 години про наявність питань без відповідей.

Всі питання / відповіді зберігаються в ЕТС і є доступними всім для перегляду, незалежно від статусу Електронних торгів.

Майданчик: 

Навіть при наявності питання до лоту/аукціону майданчик не надсилає Гарантованому покупцеві сповіщення про таке питання
Навіть при наявності питання БЕЗ відповіді до лоту/аукціону майданчик не надсилає Гарантованому покупцеві сповіщення про таке питання один раз на добу 

Майданчик не надсилає в персональний кабінет та на пошту повідомлення про отримання запитання. В разі ненадання відповіді, повідомлення про питання не надсилається 1 раз на добу.

Роль

Передумови

Настання Період уточнень: enquiryPeriod

Очікуваний результат

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

Актуальний результат

Майданчик попереджає (в інструкції) та слідкує за тим, щоб питання не містило вкладених файлів, було сформоване виключно текстовим та задавалося до лоту, а не окремих items 

Майданчик:

в окремій або загальній інструкції (залежить від реалізації майданчика) окремим пунктом вказано що:

запитання задається до лоту, а не окремих items 

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

запитання до лоту мають виключно текстовий формат

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

ЦБД:  

ЦБД приймає та фіксує валідно сформовані питання

Перелік полів, що відносяться до передачі питань з майданчика до ЦБД:
https://docs.google.com/spreadsheets/d/1P3PDY0RPXewHPat0CTSXW_K3bq29bJDefCgzFWBDgAU/edit?ts=5dc421bd#gid=882183553

Майданчик попереджає (в інструкції) та слідкує за тим, щоб питання не містило вкладених файлів, було сформоване виключно текстовим та задавалося до лоту, а не окремих items 

в окремій або загальній інструкції (залежить від реалізації майданчика) окремим пунктом не прописано що:

запитання задається до лоту, а не окремих items 

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

запитання до лоту мають виключно текстовий формат

Запитання Учасників перестає бути анонімним раніше  закінчення  Електронного аукціону.

При спробі долучити до запитання вкладень, формується повідомлення про те, що запитання не може містити вкладень, питання не публікується, поки недолік не буде виправлено. 
В разі, якщо запитання формується не тільки у текстовому форматі, формується повідомлення про те, що запитання не може містити вкладень, питання не публікується, поки недолік не буде виправлено. 
При спробі задати запитання не до лоту, а до окремих items, формується повідомлення про те, що запитання можливо поставити до лоту, а не окремих items , питання не публікується, поки недолік не буде виправлено. 

ЦБД:  

ЦБД не приймає та не зберігає питання, що містять вкладені файли або не є текстовими

Перелік полів, що відносяться до передачі питань з майданчика до ЦБД:
https://docs.google.com/spreadsheets/d/1P3PDY0RPXewHPat0CTSXW_K3bq29bJDefCgzFWBDgAU/edit?ts=5dc421bd#gid=882183553

CBD3-GE-UC-021/1

Фунціонал API ЦБД

Роль

Передумови

Настання Період подачі пропозицій: tenderPeriod

Очікуваний результат:

Періоду подачі пропозицій учасниками. tenderPeriod.startDate починається одразу після завершення періоду редагування rectificationPerod.endDate. 

Дата завершення періоду подачі закритих пропозицій tenderPeriod.endDate дорівнює  tenderPeriod.startDate  + мінімум 30 робочих днів

Дата відображається на: 

• сторінці аукціону на майданчику
• сторінці  аукціону на сайті  ДП ПП
• в полях tenderPeriod.startDate та tenderPeriod.endDate в арі 

Майданчик:

майданчик підтягує  з ЦБД та відображає на сторінці аукціону інформацію про початок та завершення tenderPeriod (період подачі пропозицій)

інформація про початок періоду подачі пропозицій підтягується з рядка tenderPeriod.startDate

інформація про завершення першення періоду подачі пропозицій підтягується з рядка tenderPeriod.endDate

ЦБД:

Періоду подачі пропозицій учасниками. tenderPeriod.startDate починається одразу після завершення періоду редагування rectificationPerod.endDate. 

tenderPeriod.endDate дорівнює  tenderPeriod.startDate  + мінімум 30 робочих днів

Майданчик:

майданчик  не підтягує з ЦБД та  не відображає сформовані  ЦБД періоди

ЦБД:

Дата завершення періоду подачі закритих пропозицій tenderPeriod.endDate дорівнює  tenderPeriod.startDate  + мінімум 30 робочих днів

Дата відображається на: 

• сторінці аукціону на майданчику
• сторінці  аукціону на сайті  ДП ПП
• в полях tenderPeriod.startDate та tenderPeriod.endDate в арі 

CBD3-GE-UC-022

Роль

Учасник

Передумови

Настання Період подачі пропозицій: tenderPeriod

Очікуваний результат

Учасник заповнює поля описані в очікуваному результаті поля та розміщує закриту цінову пропозицію

Закриті пропозиції містять:

1. величину потужності об’єкта електроенергетики або черги (пускового комплексу) об’єкта електроенергетики, щодо якого учасник аукціону має намір набути право на підтримку; Мінімум 1МВт
2. цінову пропозицію. Ціна зазначається у євроцентах за 1 кіловат-годину (євроцентів/кВт⋅год) з двома знаками після коми. Цінова пропозиція учасника аукціону не може бути вищою за рівень "зеленого" тарифу (value.amount). Граничний рівень задається Організатором аукціону на етапі публікації процедури у системі.

Майданчик:

Майданчик має контролювати заповнення полів закритої пропозиції, та після заповнення передати інформацію про закриту пропозицію до ЦБД. 

Закриті пропозиції містять:

1. величину потужності об’єкта електроенергетики або черги (пускового комплексу) об’єкта електроенергетики, щодо якого учасник аукціону має намір набути право на підтримку; Мінімум 1МВт
2. цінову пропозицію. Ціна зазначається у євроцентах за 1 кіловат-годину (євроцентів/кВт⋅год) з двома знаками після коми. Цінова пропозиція учасника аукціону не може бути вищою за рівень "зеленого" тарифу (value.amount). Граничний рівень задається Організатором аукціону на етапі публікації процедури у системі. 

CBD3-GE-UC-023

Роль

Учасник

Передумови

Настання Період подачі пропозицій: tenderPeriod

Очікуваний результат

tenderPeriod.startDate завжди рівний rectificationPerod.endDate 

Актуальний результат

Майданчик

ЦБД: 

tenderPeriod.startDate = rectificationPerod.endDate 

CBD3-GE-UC-024

Роль

Передумови

Настання Період подачі пропозицій: tenderPeriod

Очікуваний результат

tenderPeriod.endDate завжди наступає о 20.00 дня, що передує дню проведення аукціону. В момент настання tenderPeriod.endDate статус процедури змінюється на active.auction. 

Актуальний результат

Період подачі пропозицій tenderPeriod.endDate закінчується виключно о 20: 00 за київським часом, дня, що передує дню проведення аукціону. 
В разі автоматичного  перепланування проміжок між завершенням періоду подачі пропозицій  та запуском модюлю аукціону може бути більшим.

В момент настання tenderPeriod.endDate процедура змінює статус на active.auction. 

Дата відображається на: 

• сторінці аукціону на майданчику
• сторінці  аукціону на сайті  ДП ПП
• в полях tenderPeriod.endDate в арі

Майданчик:

Майданчик відображає завершення періоду редагування о 20: 00 за київським часом, дня що передує дню проведення аукціону 

Після настання 20: 00 за київським часом, дня що передує аукціону подача закритих  пропозицій блокується

В момент настання кінця періоду прийняття пропозицій відображуваний статус процедури - Аукціон

ЦБД:

CBD3-GE-UC-026

Роль

Учасник

Передумови

Очікуваний результат

Для участі в аукціоні суб’єкти господарювання разом із заявою довільної форми обов’язково подають набір документів.

Актуальний результат

Учасник подає заяву у довільній формі, та, визначений організатором набір документів з переліку:

Типи документів

Майданчик:

Для участі в аукціоні суб’єкти господарювання разом із заявою довільної форми обов’язково подають набір документів.

Типи документів

ЦБД:

Роль

Передумови

Очікуваний результат

Майданчик розміщує ставку bid у ЦБД у статусі draft. У випадку успішного розміщення отримує від ЦБД токен bid`a (access token) і переводить ставку у статус active. Майданчик несе відповідальність за збереження access token та його нерозголошення. 

Актуальний результат

Майданчик: 

розміщує ставку bid у ЦБД у статусі draft. У випадку успішного розміщення отримує від ЦБД токен bid`a (access token) і переводить ставку у статус active. Майданчик несе відповідальність за збереження access token та його нерозголошення. 

Майданчик розміщує ставку bid у ЦБД у статусі draft. У випадку успішного розміщення отримує від ЦБД токен bid`a (access token) і переводить ставку у статус active. Майданчик несе відповідальність за збереження access token та його нерозголошення. 

Роль

Передумови

Очікуваний результат

Якщо розміщення ставки у статусі draft не відбулось або ЦБД не повернула токен доступу, майданчик надсилає повторний запит для розміщення. Якщо запит на переведення ставки у статус active був не успішний, майданчик надсилає повторний запит для активації ставки. 

Важливо не розміщувати bid одразу у статусі active, так як у випадку, якщо майданчик не отримає або втратить токен для цього bid`a, ставка буде розміщена у ЦБД але у майданчика не буде до неї доступу. https://procedure-prozorro-sale.raccoongang.com/api/doc#/bids

Актуальний результат

Якщо розміщення ставки у статусі draft не відбулось або ЦБД не повернула токен доступу, майданчик надсилає повторний запит для розміщення. Якщо запит на переведення ставки у статус active був не успішний, майданчик надсилає повторний запит для активації ставки. 

Важливо не розміщувати bid одразу у статусі active, так як у випадку, якщо майданчик не отримає або втратить токен для цього bid`a, ставка буде розміщена у ЦБД але у майданчика не буде до неї доступу. https://procedure-prozorro-sale.raccoongang.com/api/doc#/bids

Роль

Учасник 

Передумови

Очікуваний результат

Учасник має право вносити зміни та уточнення до поданої ним цінової  пропозиції до закінчення періоду прийому пропозицій, визначених для даних Електронних торгів (tenderPeriod.endDate).

Актуальний результат:

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

Майданчик: 

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

ЦБД:

Роль

Учасник, Організатор

Передумови

Очікуваний результат

Вся історія змін, внесених в період подачі пропозицій tenderPeriod, зберігається в ЦБД.

Актуальний результат

Всі зміни внесені в період внесення пропозицій  tenderPeriod мають зберігатися  в ЦБД

 Майданчик: 

всі зміни внесені в період подачі пропозицій передаються до ЦБД та зберігаються там 

Роль

Учасник

Передумови

Очікуваний результат

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

Актуальний результат

Майданчик:

Всі дії з заявкою (анулювання та редагування) учасник виконує виключно через майданчик, з якого заявку було подано

ЦБД:

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

Роль

Учасник

Автоматичне завершення періоду - якщо по завершенню періоду присутні award`и у статусі verification, такі award`и автоматично змінюють свій статус на waiting, статус процедури автоматично змінюється на active.qualification. Діє принцип мовчазної згоди, ті учасники, документи яких не розглянуто вважаються такими, що успішно пройшли перевірку документів.

Передумови

Очікуваний результат

Анулювати можна тільки пропозицію в аукціоні, що має статус в Електронних торгах - "Прийняття заяв на участь" (active.tendering). 

Актуальний результат

Виключно протягом періоду "Прийняття заяв на участь" (active.tendering) Учасник має змогу анулювати заявку на участь

Майданчик: 

протягом періоду "Прийняття заяв на участь" (active.tendering) учасник має змогу анулювати свою заґвку

ЦБД:

протягом  "Прийняття заяв на участь" (active.tendering) інформація про анулювання заявки передається до ЦБД та зберігається там

Роль

Передумови

Очікуваний результат

Після розкриття цінових пропозицій, інформація про анульовані пропозиції Учасників не розкривається у публічному api. Майданчик повертає Учаснику гарантійний внесок.  

Актуальний результат

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

Майданчик: 

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

Власнику анульованної пропозиції майданчик повертає гарантійний внесок. Повернення гарантійного внеску відбувається після розкриття цінових пропозицій.

ЦБД:

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

Роль

Передумови

Очікуваний результат

Для видалення майданчик відправляє наступний запит до ЦБД: DELETE auctions/auction_id/bids/bid_id?acc_token=your_access_token

Актуальний результат

Для видалення майданчик відправляє наступний запит до ЦБД: DELETE auctions/auction_id/bids/bid_id?acc_token=your_access_token

Майданчик:

в разі видалення видалення пропозиції з майданчика передається  (після ручних маніпуляцій по видаленню пропозиції) передає запит до ЦБД: DELETE auctions/auction_id/bids/bid_id?acc_token=your_access_token

ЦБД:

після отримання та успішної обробки запиту : DELETE auctions/auction_id/bids/bid_id?acc_token=your_access_token  запис по пропозиції може бути видалена/прихована

Роль

Передумови

Очікуваний результат

Якщо на етапі active.tendering було розміщено 2 і більше закритих цінові пропозиції, після завершення етапу статус процедури змінюється на active.auction.  У протилежному випадку аукціон визнається таким, що не відбувся. Статус змінюється на unsuccessful.

Актуальний результат

Мінімальна кількість учасників 2 і більше, в цьому випадку
В разі  наявності 1 і менше учасників що подали закриті цінові пропозиції аукціон змінює статус на unsuccessful. Подання закритої цінової пропозиції поза межами tenderPeriod неможливе.

Майданчик:

Майданчик підтягує з api та відображає статус  процедури: 

у разі наявності 2 і більше закритих заявок процедура набуває статус Аукціон (active.auction)

у разі наявності менше 2 закритих пропозицій або менше процедуна рабуває статус Торги не відбулися (unsuccessful)

ЦБД:

у разі наявності 2 і більше закритих заявок процедура набуває статус Аукціон (active.auction)

у разі наявності менше 2 закритих пропозицій або менше процедуна рабуває статус Торги не відбулися (unsuccessful)

Роль

Передумови

Очікуваний результат

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

Актуальний результат

Мінімум за 5 - 15 хвилин до початку аукціону всі учасники отримують на пошту/ у особистий кабінет  унікальне згенероване ЦБД посилання. Посилання має бути унікальним для кожного учасника

Майданчик: 

за 5-15 хвилин після зміни статусу на Аукціон (active.auction) всі продуктивні учасники на пошту отримують унікльні посилання 

ЦБД: 

за 5-15 хвилин після зміни статусу на Аукціон (active.auction) для всіх продуктивних учасників формуються унікальні посилання для участі, які передаються через майданчики учасникам

Роль

Передумови

Очікуваний результат

До завершення аукціону або переходу аукціону у статус unsuccessful ставки учасників залишаються закритими для всіх, включаючи організатора аукціону і доступні виключно для майданчика, який розмістив ставку у ЦБД.

Актуальний результат

До завершення аукціону (продуктивного чи не продуктивного)  ставки та закриті пропозиції доступні лише майданчику з якого зроблені та учаснику який їх зробив. 

Майданчик:

До завершення аукціону (продуктивного чи не продуктивного)  ставки та закриті пропозиції доступні лише майданчику з якого зроблені та учаснику який їх зробив. 

ЦБД:

До завершення аукціону (продуктивного чи не продуктивного)  ставки та закриті пропозиції доступні лише майданчику з якого зроблені та учаснику який їх зробив. 

CBD3-GE-UC-039

Роль

Передумови

Status: active.auction (Аукціон)

Очікуваний результат

Після настання active.auction у ЦБД з'являється публічне посилання для глядачів аукціону і приватне посилання для кожного учасника у його закритій пропозиції. Фактично посилання стають доступними за 5 - 15 хвилин після зміни статусу, що пов’язано з технічними особливостями роботи ЦБД.

Актуальний результат:

Загальне посилання для глядачів, розміщений на сторінці аукціону ресурсу ДП ПП та на сторінці аукціону на майданчику та унікальні посилання для участі (унікальні посилання для учасників формуються та передаються на електронні адреси/особисті документи) формуються за 5-15 хвилин до початку торгів. Перехід за посиланням не призводить до запуску модуля аукціону

Майданчик:

Загальне посилання для глядачів, розміщений на сторінці аукціону ресурсу ДП ПП та на сторінці аукціону на майданчику та унікальні посилання для участі (унікальні посилання для учасників формуються та передаються на електронні адреси/особисті документи) формуються за 5-15 хвилин до початку торгів. Перехід за посиланням не призводить до запуску модуля аукціону

ЦБД: 

ЦБД формує та передає майданчику загальне посилання для глядачів, розміщений на сторінці аукціону ресурсу ДП ПП та на сторінці аукціону на майданчику та унікальні посилання для участі (унікальні посилання для учасників формуються та передаються на електронні адреси/особисті документи) формуються за 5-15 хвилин до початку торгів. Перехід за посиланням не призводить до запуску модуля аукціонуЗагальне посилання для глядачів, розміщений на сторінці аукціону ресурсу ДП ПП та на сторінці аукціону на майданчику та унікальні посилання для участі (унікальні посилання для учасників формуються та передаються на електронні адреси/особисті документи) формуються за 5-15 хвилин до початку торгів. Перехід за посиланням не призводить до запуску модуля аукціону

Роль

Учасник 

Передумови

Status: active.auction (Аукціон)

Очікуваний результат

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

Посилання унікальне і формується персонально для кожного учасника

Майданчик:

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

Майданчик: 

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

API/ЦБД
на даному етапі всі дії з усіх ІР  адрес фіксуються у логах, напряму у АРІ нічго не фіксується і не відображається.

Роль

Передумови

Status: qualification

Очікуваний результат:
endDate періодів в процесі Awarding’у фіксуються на рівні 18: 00 за київським часом

Майданчик:
endDate періодів в процесі verificationPeriod фіксуються на рівні 18: 00 за київським часом,

Роль

Передумови

Status: qualification

Очікуваний результат

Валідною ставкою вважається та, що рівна або менша за значення value.amount. 

На майданчиках відображається інформація про учасників, що кваліфікуються:

• Повна юридична назва Учасника
• Розмір цінової пропозиції
• Обсяг учасника
• Розмір з заяви учасника
• Фактичний розмір, який отримав учасник
• Статус award
• Документи учасника
• Терміни на перевірку документів та завантаження протоколу\договору

Майданчик:

Валідною ставкою вважається та, що рівна або менша за значення value.amount, відповідно, майданчик "підтягує" з ЦБД/АРІ  по всім таким учасникам, наступну інформацію:

1. Повна юридична назва Учасника
2. Розмір цінової пропозиції
3. Обсяг учасника
   1. Розмір з заяви учасника
   2. Фактичний розмір, який отримав учасник
4. Статус award
5. Документи учасника
6. Терміни на перевірку документів та завантаження протоколу\договору

ЦБД:  
Валідною ставкою вважається та, що рівна або менша за значення value.amount.  
 По всім учасникам, ставки яких визнано валідними, відображається наступна інформація:

1. Повна юридична назва Учасника
2. Розмір цінової пропозиції
3. Обсяг учасника
1. Розмір з заяви учасника
2. Фактичний розмір, який отримав учасник
4. Статус award
5. Документи учасника
6. Терміни на перевірку документів та завантаження протоколу\договору

Документ з переліком полів: 
https://docs.google.com/spreadsheets/d/1P3PDY0RPXewHPat0CTSXW_K3bq29bJDefCgzFWBDgAU/edit?ts=5dc421bd#gid=1870318207

1. Повна юридична назва Учасника
2. Розмір цінової пропозиції
3. Обсяг учасника
1. Розмір з заяви учасника
2. Фактичний розмір, який отримав учасник
4. Статус award
5. Документи учасника
6. Терміни на перевірку документів та завантаження протоколу\договору

Документ з переліком полів: 
https://docs.google.com/spreadsheets/d/1P3PDY0RPXewHPat0CTSXW_K3bq29bJDefCgzFWBDgAU/edit?ts=5dc421bd#gid=1870318207

1. Повна юридична назва Учасника
2. Розмір цінової пропозиції
3. Обсяг учасника
1. Розмір з заяви учасника
2. Фактичний розмір, який отримав учасник
4. Статус award
5. Документи учасника
6. Терміни на перевірку документів та завантаження протоколу\договору

Документ з переліком полів: 
https://docs.google.com/spreadsheets/d/1P3PDY0RPXewHPat0CTSXW_K3bq29bJDefCgzFWBDgAU/edit?ts=5dc421bd#gid=1870318207

Очікуваний результат:
ставка більша за значення value.amount вважається не валідними ставками не фіксуються і не передаються до ЦБД і не відображаються в АРІ

Роль

Передумови

Status: qualification

Очікуваний результат

ЦБД формує аварди у статусі verification для N учасників з найнижчими ціновими пропозиціями, відповідно до їх обсягу. 

Після завершення роботи модуля аукціона ЦБД формує рейтинг для N учасників одночасно враховуючи два параметри: найнижчу запропоновану вартість та найбільший об’єм

Роль

Передумови

Status: qualification

Очікуваний результат

Протокол про результати аукціону формується автоматично у вигляді структурованого машиночитаємого файлу (JSON або YAML) та оприлюднюється в формі електронного документу електронною торговою системою в день завершення аукціону.

Актуальний результат

Протокол про результати аукціону формується автоматично у вигляді структурованого машиночитаємого файлу (JSON або YAML) та оприлюднюється в формі електронного документу електронною торговою системою в день завершення аукціону.

Майданчик: 

Після завершення роботи модуля аукціону майданчик "підтягує" зафіксований в API  протокол, відображає його на сторінці  аукціоні, у PDF та HTML форматах, 
протокол доступний для зкачування

ЦБД:
Одразу після завершення роботи модуля аукціону  ЦБД  у вигляді структурованого машиночитаємого файлу (JSON або YAML)
Посилання на сформований  выдображається у API 

Роль

Передумови

Status: qualification

Очікуваний результат

Учасниками вважаються користувачі, які подали повний пакет коректних документів і відповідають вимогам законодавства. Після аукціону Організатор протягом 10 робочих днів (verificationPeriod) здійснює перевірку документів всіх учасників аукціону і підтверджує наявність документів учасника (натискає на майданчику на кнопку “Підтвердити”, після чого майданчик передає award`у такого учасника статус waiting до ЦБД), або відхиляє учасника (завантажує документ - “Акт про невідповідність” - documentType: rejectionProtocol  та натискає на кнопку “Відхилити”, після чого майданчик передає статус “unsuccessful” award`u учасника).

Актуальний результат

Учасником вважається користувач, який надав повний пакет документів (заява + документи, визначені Організатором).
Після завершення роботи модулю аукціону, протягом verificationPeriod (10 робочих днів) Організатор перевіряє документи та: 

•  підтверджує наявність документів учасника (натискає на майданчику на кнопку “Підтвердити”, після чого майданчик передає award`у такого учасника статус waiting до ЦБД), 

або 

• відхиляє учасника (завантажує документ - “Акт про невідповідність” - documentType: rejectionProtocol  та натискає на кнопку “Відхилити”, після чого майданчик передає статус “unsuccessful” award`u учасника).

Майданчик:

Учасником вважається користувач, який надав повний пакет документів (заява + документи, визначені Організатором).
Після завершення роботи модулю аукціону, протягом verificationPeriod (10 робочих днів) Організатор перевіряє документи та: 

•  підтверджує наявність документів учасника (натискає на майданчику на кнопку “Підтвердити”, після чого майданчик передає award`у такого учасника статус waiting до ЦБД), 

або 

• відхиляє учасника (завантажує документ - “Акт про невідповідність” - documentType: rejectionProtocol  та натискає на кнопку “Відхилити”, після чого майданчик передає статус “unsuccessful” award`u учасника).

ЦБД:

Гарантований покупець перерівяє наданий пакет документів протягом verificationPeriod (10 робочих днів) та:

• у разі підтвердження віладність документів майданчик передає award`у такого учасника статус waiting
• у разі відхилення до ЦБД завантажується документ “Акт про невідповідність” - documentType: rejectionProtocol та  передається статус “unsuccessful” award`

Роль

Організатор, майданчик

Передумови

Status: qualification

Очікуваний результат

Після того, як не залишилось учасників, документи яких розглядаються (всі документи або підтверджено, або відхилено), організатор повинен оприлюднити “Загальний акт  перевірки”  documentType: x_verificationAct щодо результатів перевірки документів.
Організатор завантажує “Загальний акт перевірки”, натискає кнопку “Перевірку документів завершено”, після чого майданчик змінює статус процедури на active.qualification.

Майданчик: 

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

документи  “Загальний акт перевірки” передається до ЦБД та відображається на майданчику статус процедури  Кваліфікація учасників

Якщо є учасники у статусі verification, в Організатора можливість перевести процедуру до статусу active.qualification відсутня.

Якщо в процедурі відсутній документ x_verificationAct - можливість перевести процедуру у статус  active.qualification відсутня. 

Додати документ з таким типом можливо тільки на етапі перевірки документів учасника.

Майданчик:
поза межами статусу qualification завантаження документу x_verificationAct заблоковано, поля/кнопки для завантаження документу відсутні, в разі спроби завантаження документу x_verificationAct виводиться помилка/текстове повідомлення про невідповідність статусу процедури діям, що виконуються, про неможливість завантажити докумен

Організатор, майданчик

Передумови

Status: qualification

Очікуваний результат

Якщо є учасники у статусі verification, в Організатора можливість перевести процедуру до статусу active.qualification відсутня.

Якщо в процедурі відсутній документ x_verificationAct - можливість перевести процедуру у статус  active.qualification відсутня. Додати документ з таким типом можливо тільки на етапі перевірки документів учасника.

Майданчик: 

Якщо є  хоча б один учасник у статусі Перевірка документів (verification), в Організатора можливість перевести процедуру до статусу active.qualification відсутня.

Якщо в процедурі відсутній документ x_verificationAct - можливість перевести процедуру у статус  active.qualification відсутня. 

Додати документ з типом x_verificationAct можливо тільки на етапі перевірки документів учасника.

ЦБД: 

Передумови

Status: qualification

Очікуваний результат

Варіант А. 

Автоматичне завершення періоду - якщо по завершенню періоду присутні award`и у статусі verification, такі award`и автоматично змінюють свій статус на waiting, статус процедури автоматично змінюється на active.qualification. Діє принцип мовчазної згоди, ті учасники, документи яких не розглянуто вважаються такими, що успішно пройшли перевірку документів.

Майданчик:

Варіант А.

Автоматичне завершення періоду:  якщо по завершенню періоду присутні award`и у статусі  Перевірка документів (verification), такі award`и автоматично змінюють свій статус на Документи перевірено (waiting), статус процедури автоматично змінюється на active.qualification.
Діє принцип мовчазної згоди, ті учасники, документи яких не розглянуто вважаються такими, що успішно пройшли перевірку документів.

Варіант А.

Автоматичне завершення періоду:  якщо по завершенню періоду присутні award`и у статусі  Перевірка документів (verification), такі award`и автоматично змінюють свій статус на Документи перевірено (waiting), статус процедури автоматично змінюється на active.qualification.
Діє принцип мовчазної згоди, ті учасники, документи яких не розглянуто вважаються такими, що успішно пройшли перевірку документів.

Передумови

Status: qualification

Очікуваний результат

Варіант Б. 

Автоматичне завершення періоду відсутнє, Організатор має вручну змінити статус award`ів з verification на waiting та процедури з qualification на active.qualification. У структурі verificationPeriod з’являється додаткове поле з інформацією про порушення термінів

Майданчик:

Варіант Б.

Майданчик атоматично НЕ  передаэ інформацію про завершення періоду: Організатор має вручну змінити статус award`ів з  Перевірка документів (verification) на  Документи перевірено (waiting) та процедури з qualification на active.qualification.

У структурі verificationPeriod з’являється додаткове поле з інформацією про порушення термінів

ЦБД:

ЦБД по завершенню періоду майданчик в ручному режимі передає  зміну статусу award`ів з  Перевірка документів (verification) на  Документи перевірено (waiting) після чого  процедура змінюється  з qualification на active.qualification. 
Додатково передається значення додаткового поля з інформацією про порушення термінів

Роль

Передумови

Status: qualification

Очікуваний результат

Після завершення аукціону, протягом verificationPeriod, поки award знаходиться у статусі verification, учасники мають можливість довантажити до bid`а набір документів для усунення формальних недоліків.

Типи документів та неймінг співпадають з документами, які на етапі розміщення заяви додаються до bid`а.

Майданчик:

з моменту завершення роботи модуля аукціону  і  до завершення verificationPeriod, а award має  статус verification учасники мають можливість використовуючи функціонал  майданчика  виключно щоб  довантажити до bid`а набір документів для усунення недоліків.

Типи документів та неймінг співпадають з документами, які на етапі розміщення заяви додаються до bid`а.  Дані збереженні на етапі  tenderPeriod  не редагуються

ЦБД:

від завершення роботи модулю аукціону  і до завершення verificationPeriod, а award має  статус verification майданчик передає довантажені документи які записуються до bid`а. 

Типи документів та неймінг співпадають з документами, які на етапі розміщення заяви додаються до bid`а.

Дані bid`а (поля та документи) збережені  на етапі tenderPeriod не змінюються

ЦБД: 

в разі якщо спроба довантажити до bid`а документи  відбувається протягом verificationPeriod,  поки award знаходиться у статусі verification, але неймінг та тип документів відрізняється від того, що був завантажений на етапі розміщення заяви ЦБДформіється повідомлення/помилка  про неможливість довантажити нові документи. Завантажувані документи  до ЦБД не фіксуються

Очікуваний результат

Дані bid`а (поля та документи) збережені  на етапі tenderPeriod не змінюються

ЦБД

При спробі передати айданчиком доЦБД  змінити дані bid`а (поля та документи) збережені  на етапі tenderPeriod не змінюються, при спробі відредагувати такі дані  майданчик виводить повідомлення/помилку  про недопустимість таких дій. Відредаговані дані ані bid`а (поля та документи) збережені  на етапі tenderPeriod не змінюються не передаються до ЦБД

Роль

Передумови

Status: active.qualification

Очікуваний результат:

Після зміни статусу процедури на active.qualification, розраховується обсяг квоти, виходячи з сумарного обсягу учасників, які успішно пройшли перевірку документів. Розрахований обсяг квоти складає 80% від суми обсягів у заявах учасників, але не більше за обсяг квоти, вказаний при публікації аукціону організатором.

Після чого змінюється статус award`ів таких учасників і починається етап роботи з протоколом та договором. 

ЦБД:
варіанти розрахунку рейтингу: 
 - якщо бажаний  об'єм Гарантованого покупця (items.quantity)  менший за 80% від загальної суми всіх об'ємів (x_quantityLimit), то між учасниками розподіляється бажаний  об'єм Гарантованого покупця 

 - якщо бажаний  об'єм Гарантованого покупця (items.quantity)  більший за 80% від загальної суми всіх об'ємів (x_quantityLimit), то між учасниками розподіляється 80% від загальної суми всіх об'ємів
  - якщо бажаний  об'єм Гарантованого покупця (items.quantity)  дорівнює  80% від загальної суми всіх об'ємів (x_quantityLimit), то між учасниками розподіляється будьякий, так як вони рівні 

Майданчик:

ЦБД:
(items.quantity) < (x_quantityLimit) 

(items.quantity) розподіляється  між Учасниками, що пройшли перевірку документів, вишуковані у рейтинг,  починаючи з учасника, що запропонував найменшу ціну. Усі учасники, яким задовольнили запропонований ними об'єм статус змінюється з waiting на pending

ЦБД:
(items.quantity) >  (x_quantityLimit) 

(x_quantityLimit) розподіляється  між Учасниками, що пройшли перевірку документів, вишуковані у рейтинг,  починаючи з учасника, що запропонував найменшу ціну. Усі учасники, яким задовольнили запропонований ними об'єм статус змінюється з waiting на pending

ЦБД:
(items.quantity) = (x_quantityLimit) 

між учасниками розподіляється будьякий, так як вони рівні. Усі учасники, яким задовольнили запропонований ними об'єм статус змінюється з waiting на pending 

ЦБД:

Всім учасникам заявки яких не було задоволено до waitingPeriod.endDate набуває статус pending.waiting

Роль

Передумови

Status: active.qualification

Очікуваний результат

signingPeriod.startDate періоду роботи з протоколом та договором формується:

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

ЦБД: 

з настанням signingPeriod.startDate  періоду роботи з протоколом та договором формується: 

• від дати завершення аукціону ("auctionPeriod": endDate), для учасників, обсяг заявок яких задовольняється одразу після завершення перевірки документів
• з дати такої дискваліфікації та оновлення статусу учасника, для учасників, які набувають право на отримання квоти після дискваліфікації одного з переможція 
• endDate фіксуються на рівні 18: 00 за київським часом

Status: active.qualification

Очікуваний результат

Пропозиції сортуються від меншої ціни до більшої, а, у випадку співпадіння ціни, вище відображається пропозиція розміщена раніше.
Часом розміщення пропозиції вважається час першого розміщення заяви у ЦБД, а, у випадку редагування пропозиції під час періоду прийому пропозицій, час фіксації змін у заяві у ЦБД.

Майданчик: 

ЦБД: 

одразу після завершення роботи модуля ЦБД формує рейтинг (проміжний) виходячи з вартості за 1 кВт  (від меншої до більшої)  та часу подання пропозиції: 
 - в разі редагування пропозиції, часом подання вважається час фіксації останіх змін
 - в разі наявності двох пропозицій однакових за вартісттю,  вища відображається та, що була розміщена раніше

Роль

Передумови

Status: active.qualification
Очікується опублікування протоколу та підписання договору signingPeriod

Очікуваний результат

Первинно на SigningPeriod виділено до 15 робочих днів після закінчення verificationPeriod для кожного award`у, але період триває доти, доки Організатор не переведе процедуру в наступний статус (на рівні ЦБД необхідно реалізувати параметр автоматичної зміни статусу award`у

Майданчик: 

гарантований покупець протягом 

Автоматичний перехід процедури до наступного статусу відсутній.
SigningPeriod триває до 15 робочих днів з моменту закінчення verificationPeriod для кожного award`у
Перехід на наступний статус відбувається лише після того, як Організатор - гарантований покупец вручну переведе процедуру

ЦБД:

SigningPeriod.startDate  формується від  verificationPeriod.endDate та триває до тих пір коли Організатор натисне на кнопку “Завершити аукціон”. Після чого процедура змінює статус на complete. 

Майданчик:

До тих пір, поки наявні award`и в статусі  pending та/або  pending.waiting можливість  Організатором натиснути на кнопку “Завершити аукціон”  та перевести процедуру у статус complete заблокована (кнопка відсутня)

ЦБД:

В разі спроби перевести процедуру в статус complete при  наявності award`ів pending та/або  pending.waiting формується помилка про недопустимість таких дій, зміна статусу не відбувається і в АРІ не фіксуються

Майданчик:

В разі спроби перевести процедуру в статус complete при  наявності award`ів pending та/або  pending.waiting майданчик  формує/вичитує інтерпретує та виводить  помилку про недопустимість таких дій, зміна статусу не відбувається і в АРІ не фіксуються

ЦБД:

В разі спроби перевести процедуру в статус complete при  наявності award`ів pending та/або  pending.waiting формується помилка про недопустимість таких дій, зміна статусу не відбувається і в АРІ не фіксуються

Передумови

Status: active.qualification
Очікується опублікування протоколу та підписання договору signingPeriod

Очікуваний результат

SigningPeriod це період який відноситься до award`у, він формується окремо для кожного учасника під час набуття таким учасником статусу pending. Дата початку та завершення періоду для різних учасників може відрізнятися.

Майданчик:
SigningPeriod це період який відноситься до award`у, він формується окремо для кожного учасника під час набуття таким учасником статусу pending. Дата початку та завершення періоду для різних учасників може відрізнятися.

ЦБД:

ЦБД формує SigningPeriod індивідуально з моменту  під час набуття таким учасником статусу pending. Дата початку та завершенняSigningPeriod  формується для кожного учасника 

Роль

Передумови

Настання періоду очікування кваліфікації переможців (pending)

Очікуваний результат

Award’ам учасників з найнижчими ставками присвоюється статус verification. При однакових цінових пропозиціях, переможцем вважається той учасник, що подав пропозицію раніше. Час подачі пропозицій враховується та відображається відповідно до стандарту, наприклад: 2019-10-11T14:54:12.708333+03: 00 за київським часом,
(посилання на стандарт https://en.wikipedia.org/wiki/ISO_8601)

Майданчик:

Вичитує та відображає на сторінці аукціону сформований ЦБД рейтинг

ЦБД: 

Одразу пісдя завершення роботи модуля аукціону, протягом кількох секунд, формується рейтинг за вартісттю від найменшої до найбільшою. В  разу наявності двох однакових цінових пропозицій вище відображається та, що була зроблена раніше (в разі редагування часом розміщення вважається час останнього редагування). Час фіксується за стандартом: 2019-10-11T14:54:12.708333+03: 00 за київським часом,
(посилання на стандарт https://en.wikipedia.org/wiki/ISO_8601)

Роль

Передумови

Очікуваний результат

Процедура кваліфікації знаходиться в періоді підписання протоколу, у цей час Організатор зобов’язаний завантажити і підтвердити протокол аукціону (documentType: auctionProtocol) в цей award.

Майданчик: 

протягом SigningPeriod (Періоду підписання протоколу) Організатор - Гарантований покупець вантажить 

протокол аукціону (documentType: auctionProtocol) в цей award.

ЦБД:

приймає пртягом SigningPeriod приймає та записує документ з типом documentType: auctionProtocol) в цей award 

ЦБД:

При спробі передати до ЦБД протокол аукціону (documentType: auctionProtocol) в award до настання SigningPeriod.startDate ЦБД формує помилку, протокол не приймаєтьсята не фіксується в ЦБД

Майданчик: 

В разі спроби передати протокол з будь-яким іншим типом, окрім documentType: auctionProtocol Майданчик вичитує/інтепретує помилку сформовану ЦБД про невідповідність типу документу, документ до ЦБД не передається 

ЦБД:

Якщо Майданчик передає протокол з типом не documentType: auctionProtocol формується помилка про невідповідність типу документу, документ не приймається і не фіксується 

CBD3-GE-UC-058

неактуально

Роль

Передумови

Очікуваний результат

Якщо протокол завантажено і підтверджено раніше - award учасника переходить до статусу “Очікується договір” (active).

Актуальний результат

Якщо протокол завантажено і підтверджено раніше - award учасника переходить до статусу “Очікується договір” (active).

Роль

Організатор

Передумови

Очікуваний результат:

В Організатора є можливість підтвердити протокол і після завершення SigningPeriod, обмеження на майданчику не мають встановлюватись.

ЦБД:
ЦБД приймає та фіксує протокол після настання SigningPeriod.endDate

Роль

Організатор

Передумови

Очікуваний результат
Після завантаження протоколу організатор натискає кнопку "Протокол затверджено", після чого майданчик переключає статус award’у в active. В результаті чого для цього award’у створюється contract відповідного учасника в статусі pending у масиві contracts.

Майданчик:
Після завантаження протоколу організатор натискає кнопку "Протокол затверджено", після чого майданчик переключає статус award’у в active. 

В результаті дій майданчика для цього award’у створюється contract відповідного учасника в статусі pending у масиві contracts.

Роль

Учасник

Передумови

 Очікуваний результат

У учасника, який кваліфікується є можливість завантаження Протоколу (тип документу auctionProtocol) в award (не обов’язкова дія), але завантаження цього документу учасником не призводить до зміни статусів в системі.

Майданчик:
У учасника, який кваліфікується є можливість завантаження Протоколу (тип документу auctionProtocol) в award (не обов’язкова дія), але завантаження цього документу учасником не призводить до зміни статусів в системі.

ЦБД:
Завантаження Протоколу (тип документу auctionProtocol) в award учасником не призводить до зміни статусів в системі.

Майданчик:

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

Передумови

Очікуваний результат

У разі відмови переможця від підписання протоколу про результати аукціону, Гарантований покупець складає та оприлюднює в електронній торговій системі акт (documentType: act), натискає на кнопку “Дискваліфікувати учасника” і вказує одну чи декілька причин зі списку: 

• Переможець 
• Відмовився від підписання протоколу
• Не надав обов’язкові документи 

Після чого майданчик передає статус unsuccessful award`у учасника

Майданчик:

Гарантований покупець (поза системою) складає акт (documentType: act)  та завантажує його до ЕТЦ   після чого натискає кнопку 

“Дискваліфікувати учасника” і вказує одну чи декілька причин зі списку: 

• Переможець 
• Відмовився від підписання протоколу
• Не надав обов’язкові документи 

Після чого майданчик передає статус unsuccessful award`у учасника, а після зміни статусу такого/таких award'ів учасників відображає оновлений статус на сторінці аукціону

ЦБД: 
Приймає від Майданчика документ з типом  documentType: act та причину дискваліфікації, фіксує у відповідних полях АРІ після чого змінює статус award`у  такого учасника учасника на unsuccessful  

Очікуваний результат

У разі відмови переможця від підписання протоколу про результати аукціону, Гарантований покупець складає та оприлюднює в електронній торговій системі акт (documentType: act), натискає на кнопку “Дискваліфікувати учасника” і вказує одну чи декілька причин зі списку: 

• Переможець 
• Відмовився від підписання протоколу
• Не надав обов’язкові документи 

Після чого майданчик передає статус unsuccessful award`у учасника

Майданчик:
При спробі дискваліфікувати Учасника без завантаження акту (documentType: act) майданчик вичитує/інтерпретує та відображає помилку сформовану у  ЦБД. Дискваліфікація не можлива, дані до ЦБД не передаються

ЦБД:
При спробі передати Майданчиком дискваліфікацію Учасника без завантаження акту (documentType: act)  ЦБД  формує помилку.  Дискваліфікація не можлива, статус  award  ЦБД не змінює

Очікуваний результат

У разі відмови переможця від підписання протоколу про результати аукціону, Гарантований покупець складає та оприлюднює в електронній торговій системі акт (documentType: act), натискає на кнопку “Дискваліфікувати учасника” і вказує одну чи декілька причин зі списку: 

• Переможець 
• Відмовився від підписання протоколу
• Не надав обов’язкові документи 

Після чого майданчик передає статус unsuccessful award`у учасника

CBD3-GE-UC-063

Роль

Передумови

Очікує рішення (pending.waiting)

Очікуваний результат

Для учасників, які не отримали бажану квоту, одразу після аукціону, формуються award’и, що отримують статус pending.waiting. Такі учасники не можуть відмовитись від очікування і чекають на дискваліфікацію попередніх учасників або завершення періоду повернення банківських гарантій (29 робочих днів з моменту завершення аукціону).

Майданчик: 
Учасники, що не отримали квоту  (статус pending.waiting) не можуть відмовитися від очікування протягом періоду Очікування кваліфікації/дискваліфікації переможців (waitingPeriod). Кнопка для відмови від очікування/самодискваліфікації відсутня. 

Роль

Передумови

Очікуваний результат

Якшо після розподілу  об'єму  Гарантованого покупця (items.quantity) або  80% від загальної суми всіх об'ємів (x_quantityLimit)  наявний  залишок, який не задовольняє пропозицію наступного кваліфікованого учасника, залишок може бути повністтю або частково бути надано  наступному за останім кваліфікованим  учасником.

Майданчик:

Майданчик відображає зміну статусів award протягом 5 хвилин з моменту зміни статусу

ЦБД:
В разі якщо протягом waitingPeriod дискваліфіковують учасника/учасників  з статусом pending  дискваліфіковується, звільнена квота сумується (за наявності) з нерозподіленим залишком і в разі, якщо просумованого  нерозподіленого залишку достатньо для покриття заявки наступного, за рейтингом,  учасника (статус учасника pending.waiting) то такий учасник набеває статус pending

CBD3-GE-UC-065

Фунціонал API ЦБД

Передумови

Очікуваний результат

Якшо після розподілу  об'єму  Гарантованого покупця (items.quantity) або  80% від загальної суми всіх об'ємів (x_quantityLimit)  наявний  залишок, який не задовольняє пропозицію наступного кваліфікованого учасника, залишок може бути повністтю або частково бути надано  наступному за останім кваліфікованим  учасником. Статус такого учасника pending.waiting,  

Майданчик:
Майданчик на сторінці аукціонцу відображає Очікує кваліфікації/дискваліфікації переможців (waitingPeriod), який триває 30 робочих днів 
Майданчик відображає зміну статусів award протягом 5 хвилин з моменту зміни статусу

ЦБД:

waitingPeriod.startDate завжди дорівнює verificationPeriod.endDate та триває 29 робочих днів, waitingPeriod.endDate наступає на 30 робочий день о 00:00

Наступний учасник після останнього учасника в статусі pending набуває статусу pending.admission

Для учасника з pending.admission формується award  з обсягом, що менший поданій заявці

.

CBD3-GE-UC-066

Фунціонал API ЦБД

Передумови

Очікуваний результат

Якшо після розподілу  об'єму  Гарантованого покупця (items.quantity) або  80% від загальної суми всіх об'ємів (x_quantityLimit)  наявний  залишок, який не задовольняє пропозицію наступного кваліфікованого учасника, залишок може бути повністтю або частково бути надано  наступному за останім кваліфікованим  учасником.

Майданчик:
Майданчик відображає зміну статусів award протягом 5 хвилин з моменту зміни статусу

ЦБД:
В разі якщо протягом waitingPeriod дискваліфіковують учасника/учасників  з статусом pending  дискваліфіковується, звільнена квота сумується (за наявності) з нерозподіленим залишком і в разі, якщо просумованого  нерозподіленого залишку достатньо для покриття заявки наступного, за рейтингом,  учасника (статус учасника pending.waiting) то такий учасник набеває статус pending

CBD3-GE-UC-067

Роль

Передумови

Очікуваний результат

Майданчик:
Майданчик відображає зміну статусів award протягом 5 хвилин з моменту зміни статусу

ЦБД:

Якщо в результаті перерозподілу вивільненої квоти для учасника формується обсяг, що повністю задовольняє його заяву, award такого учасника переходить до статусу pending.
З моменту зміни статусу такого award’у на pending для такого учасника формується окремий signingPeriod 15 робочих днів (аналогічно до award`ів, які сформувались спочатку). 

CBD3-GE-UC-068

Роль

Передумови

Очікуваний результат

Award може знаходитись у статусу pending.waiting не довше 29  робочих днів після завершення аукціону (на 30-й робочий день о 00:00). Після завершення періоду, відбувається перевірка можливості кваліфікувати учасника, у випадку відсутності такої можливості, award`и автоматично переходять у статус cancelled

Майданчик: 

Майданчик відображає зміну статусів award протягом 5 хвилин з моменту зміни статусу

ЦБД:
Award може знаходитись у статусу pending.waiting не довше 29  робочих днів після завершення аукціону (на 30-й робочий день о 00:00). Після завершення періоду, відбувається перевірка можливості кваліфікувати учасника, у випадку відсутності такої можливості, award`и автоматично переходять у статус cancelled

CBD3-GE-UC-069

Фунціонал API ЦБД

Роль

Передумови

Очікуваний результат

Якщо після завершення періоду повернення банківських гарантій (на 30-й робочий день о 00: 00 за київським часом, після завершення аукціону), є учасник у статусі pending.waiting, з обсягом квоти, яка не повністю задовольняє заявку учасника, у award`a такого учасника автоматично формується admissionPeriod тривалістю в 5 робочих днів. Award такого учасника набуває статус pending.admission (умовний переможець):

1. Учасник протягом 5 робочих днів має погодитися або відмовитися від обсягу, який залишився після кваліфікації переможця/ців. 
2. У випадку погодження на обсяг, що залишився, умовний переможець в особистому кабінеті надає підтвердження на набуття статусу переможця (pending) та зобов’язаний вказати розмір обсягу, на який погоджується: поле - award.quantity (вказаний обсяг повинен дорівнювати або бути меншим обсягу, що залишився). Після чого у award`a формується signingPeriod, на який виділяється до 15 робочих днів, але період триває доти, доки Організатор не переведе процедуру в наступний статус.
3. У випадку відмови від обсягу, що залишився, або бездіяльності учасника протягом admissionPeriod необхідно передати зміну статусу award`у з pending.admission на cancelled.

Якщо після завершення періоду повернення банківських гарантій (на 30-й робочий день о 00: 00 за київським часом, після завершення аукціону), є учасник у статусі pending.waiting, з обсягом квоти, яка не повністю задовольняє заявку учасника, у award`a такого учасника автоматично формується admissionPeriod тривалістю в 5 робочих днів. Award такого учасника набуває статус pending.admission (умовний переможець):

1. Учасник протягом 5 робочих днів має погодитися або відмовитися від обсягу, який залишився після кваліфікації переможця/ців. 
2. У випадку погодження на обсяг, що залишився, умовний переможець в особистому кабінеті надає підтвердження на набуття статусу переможця (pending) та зобов’язаний вказати розмір обсягу, на який погоджується: поле - award.quantity (вказаний обсяг повинен дорівнювати або бути меншим обсягу, що залишився). Після чого у award`a формується signingPeriod, на який виділяється до 15 робочих днів, але період триває доти, доки Організатор не переведе процедуру в наступний статус.
3. У випадку відмови від обсягу, що залишився, або бездіяльності учасника протягом admissionPeriod необхідно передати зміну статусу award`у з pending.admission на cancelled.

CBD3-GE-UC-070

Роль

Передумови

Завершення аукціону (переведення у статус complete)

Очікуваний результат

Після підтвердження або дискваліфікації учасників, які не пройшли кваліфікацію (відсутні award`и у статусі pending та pending.waiting), Організатор натискає на кнопку “Завершити аукціон”. Після чого процедура змінює статус на complete. 

Майданчик:

Після того, як всі award`и було опрацьовано і не залишилось award`ів pending та pending.waiting Гарантований покупець натискає на кнопку “Завершити аукціон”, відбувається перевірка  відсутності award`ів pending та pending.waiting  Після чого процедура змінює статус на complete. 

ЦБД:
Процедура може набути статус complete виключно в тому разі  відсутності award`ів pending та pending.waiting

CBD3-GE-UC-071

Роль

Передумови

Очікуваний результат

Замовник має право відмовитися від проведення Електронних торгів, шляхом скасування аукціону. Для скасування Замовник зобов’язаний завантажити документ із зазначенням причини скасування аукціону. Технічно можливість скасування аукціону присутня до моменту переходу в один з термінальних статусів. 

Замовник має право відмовитися від проведення Електронних торгів, шляхом скасування аукціону. Для скасування Замовник зобов’язаний завантажити документ із зазначенням причини скасування аукціону. Технічно можливість скасування аукціону присутня до моменту переходу в один з термінальних статусів.