Глоссарій

tenderPeriod - період подачі початкових пропозицій

enquiryPeriod

enquiryPeriod - період уточнень, коли можна задати питання та отримати відповіді на них.
rectificationPeriod - період, коли Організатор може вносити зміни в процедури.

Триває

Триває 48 годин

після

після публікації процедури. У цей період ЦБД не приймає закриті цінові пропозиції учасників..
auctionPeriod - період, коли проводиться аукціон.
verificationPeriod - період, коли Організатор кваліфікує переможця. Результатом цього періоду є завантаження та підтвердження протоколу Організатором.
signingPeriod - період, коли Організатор

завантажує та активує контракт

- Гарантований покупець має завантажити протокол та договір, та підтвердити кожний з них окремо.
startDate - дата та час початку періоду.
endDate - дата та час закінчення періоду.
Валідна ставка - це ставка, що рівна або менша за значення value.amount
CAV-PS

та

CPV

та CPV - основний класифікатор. Деталі по роботі з

класифікаторами

класифікаторами https://docs.google.com/document/d/10ExA2rhhbk8u558rv9VSef_531UROwxYNdcyR25Gyt8/

edit CBD3-GE-UC-heading

edit#heading=h.mdysz87o4uja
CPVS - додатковий класифікатор.
Кваліфікація - процес, що включає перевірку документів учасника та роботу з протоколом та договором після завершення аукціону (авардинг, awarding). Під час кваліфікації визначається відповідність переможця\переможців критеріям та факт виконання переможцем вимог (вимоги та критерії визначає Організатор при публікації аукціону або є зазначеними в Регламенті роботи ЕТС). Кваліфікацію проходять одночасно декілька учасників.
Гарантований покупець – Організатор
Умовний переможець – учасник, що йде наступним за останнім в рейтингу переможцем відповідно до протоколу про результати аукціону, якому надається можливість набути право на підтримку в обсязі величини потужності.

Процедура розподілу квот

Загальний огляд процедури розподілу квот

З метою проведення аукціонів з розподілу квот підтримки для електричної енергії з альтернативних джерел енергії в межах системи ProZorro.Sale CDB3 реалізовано procurementMethodType: renewables. Крім продажу квот, схожі процедури та тип аукціону можуть використовуватись для продажу товарів де, крім ціни, учасник зазначає обсяг товару, який бажає придбати.

...

Timeline процедури розподілу квот підтримки на виробництво електроенергії з альтернативних джерел енергії renewables ЦБД-2 - Сonfluence

Формування лоту

Етап відбувається поза системою.

...

Після підготовки лоту і оформлення усієї необхідної документації починається етап “Створення процедури”.

Порядок проведення електронних торгів

Створення процедури

active.rectification

Під час створення процедури, Організатор виконує наступні дії:

...

CBD3-GE-UC-001	Створення процедур Фунціонал API ЦБД
Роль	Організатор - Гарантований покупець
Передумови
Очікуваний результат Організатор - Гарантований покупець вказує єдину дату при заведенні процедури - орієнтовний час початку аукціону (auctionPeriod.startDate у запиті, auctionPeriod.shouldStartAfter у api після створення процедури). Точну дату початку торгів визначає система з огляду на поточну завантаженість, інформація про точну дату фіксується автоматично у полі auctionPeriod.startDate При створенні процедури організатор вказує лише бажану дату проведення торгів, виходячи з цієї дати автоматично визначається дата проведення, та може відрізнятися від бажаної дати проведення вказаної організатором у більшу сторону. Дата не редагується	Майданчик: при створенні процедури на майданчику Організатор вказує бажану дату проведення , раніше якого аукціон не повинен розпочатися. При публікації аукціону майданчик передає обидві дати, а після успішної публікації майданчик відображає лише дату, сформовану системою
	ЦБД: виходячи с бажаної дати ЦБД: виходячи с бажаної дати проведення вказаної організатором та навантаження ЦБД розраховує дату проведення аукціону, яка фіксується автоматично у полі *auctionPeriod.startDate,* а після остаточного визначення системою дати проведення торгів, значення поля автоматично переписується, з бажаної дати на остаточну. Дата проведення визначена ЦБД не може бути відредагована
	Альтернативні (негативні) сценарії
CBD3-GE-UC-001.1n
Очікуваний результат: При створенні процедури організатор вказує лише бажану дату проведення торгів, виходячи з цієї дати автоматично визначається дата проведення, та може відрізнятися від бажаної дати проведення вказаної організатором у більшу сторону. збереження чернетки без обмежень публікація процедури з чернетки без заповненої *auctionPeriod.startDate* (бажана дата проведення аукціону) неможливе	Майданчик: при створенні процедури Організатор - гарантований покупець залишає поле *auctionPeriod.startDate* (бажана дата проведення аукціону) пустою та публікує процедуру. збереження в чернетку можливе публікація процедури з чернетки з пустою бажаною датою проведення аукціону неможлива
	ЦБД: при спробі передати до поля *auctionPeriod.startDate* (бажана дата проведення аукціону) значення null виводиться повідомлення про необхідність заповнення поля та помилку про неможливість збереження редагування.
CBD3-GE-UC-001.2n При створенні процедури організатор вказує лише бажану дату проведення торгів, виходячи з цієї дати автоматично визначається дата проведення, та може відрізнятися від бажаної дати проведення вказаної організатором у більшу сторону. збереження чернетки без обмежень публікація процедури з чернетки без заповненої *auctionPeriod.startDate* (бажана дата проведення аукціону) неможливе	Майданчик: при створенні процедури Організатор - гарантований покупець використовує дату як значення поля *auctionPeriod.startDate* (бажана дата проведення аукціону) меншою за поточну та публікує процедуру. збереження в чернетку можливе публікація процедури з чернетки бажаною датою меншою за дату публікації процедури неможлива
	ЦБД: при спробі передати в полі *auctionPeriod.startDate* (бажана дата проведення аукціону) менша за дату на момент публікації, то ЦБД формує помилку про некоректність введенної дати, дата не зберігається
CBD3-GE-UC-001.3n При створенні процедури організатор вказує лише бажану дату проведення торгів, виходячи з цієї дати автоматично визначається дата проведення, та може відрізнятися від бажаної дати проведення вказаної організатором у більшу сторону. збереження чернетки без обмежень публікація процедури з чернетки без заповненої *auctionPeriod.startDate* (бажана дата проведення аукціону) неможливе	Майданчик: поле дати не може містити літер, з майданчика можна ввести личе цифри, крапки (.) та слеш (/)
	при спробі передати в полі *auctionPeriod.startDate* (бажана дата проведення аукціону) передати символи відмінні від крапки (.), слешу (/) та цифр від 0 до 9 ЦБД формує помилку про некоректність введенної дати, введені дані не зберігаються

...

CBD3-GE-UC-009	Фунціонал API ЦБД
Роль	Учасник
Передумови

Очікуваний результат До завершення аукціону з Учасниками напряму контактують виключно Оператори електронних майданчиків.	Майданчик: До завершення аукціону відсутній зв’язок замовника та потенційних переможцем/ями. Всі консультації надає майданчик.
	ЦБД: До завершення аукціону відсутній зв’язок замовника та потенційних переможцем/ями. Всі консультації надає майданчик.
	Альтернативні (негативні) сценарії
CBD3-GE-UC-009.1n
До завершення аукціону з Учасниками напряму контактують виключно Оператори електронних майданчиків. При спробі задати питання на пряму виникає помилка про неможливість такої дії	Майданчик: Учасник знаходить інформацію про організатора та намагається задати йому питання.
	ЦБД: не задіяно

Аукціон з заздалегідь визначеною земельною ділянкою (розписати детальніше)

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 (Період редагування)
	Альтернативні (негативні) сценарії
CBD3-GE-UC-0010.1n	--
	ЦБД: Після натискання кнопки "Опублікувати" Організатором - гарантованим покупцем до ЦБД передаються наступні автогенеровані поля: 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	Фунціонал API ЦБД
Роль	ЦБД
Передумови	Status:
Очікуваний результат Створена процедура набуває статусу *active.rectification*. З виконанням цих дій до створеної процедури додаються поля, що генеруються автоматично, в тому числі тривалості періодів.	Майданчик: Після публікації і набуття процедурою статусу active.rectification, майданчик виводить значення startDate та endDate active.rectification (Період редагування) та статус процедури - Період редагування
	ЦБД: статус процедури одразу по публікації active.rectification, окрім статусу процедури в api фіксується startDate та endDate active.rectification
	Альтернативні (негативні) сценарії
CBD3-GE-UC-011.1n
Очікуваний результат: Створена процедура набуває статусу *active.rectification*. З виконанням цих дій до створеної процедури додаються поля, що генеруються автоматично, в тому числі тривалості періодів.	Майданчик: Після публікації процедура не набуває статусу active.rectification, не формується значення startDate* та endDate active.rectification (Період редагування)* та статус процедури - Період редагуванння не відображається на майданчику
	ЦБД: ЦБД одразу по публікації не присвоює статус active.rectification, відповідно новий статус нефіксується в арі та в api не фіксується startDate та endDate active.rectification
CBD3-GE-UC-011.2n
Очікуваний результат: Створена процедура набуває статусу *active.rectification*. З виконанням цих дій до створеної процедури додаються поля, що генеруються автоматично, в тому числі тривалості періодів.	Майданчик: Після публікації процедура набуває статусу active.rectification, значення startDate* та endDate active.rectification (Період редагування)* та статус процедури - Період редагуванння формується не валідними, сформовані невалідні строки відображаються на майданчику
	ЦБД: Після публікації процедура набуває статусу active.rectification який фіксується в арі значЗння startDate* та endDate active.rectification (Період редагування)* та статус процедури - Період редагуванння заповнюється не валідними датами, сформовані невалідні строки передаються майданчику

CBD3-GE-UC-012	Фунціонал API ЦБД
Роль
Передумови	Status: active.rectification (Період редагування)
Актуальний результат: Створена процедура набуває статусу active.rectification. З виконанням цих дій до створеної процедури додаються поля, що генеруються автоматично, в тому числі тривалості періодів. Період редагування завжди триває 48 один. *rectificationPeriod.startDate, при цьому, дорівнює моменту появи процедури в ЦБД. rectififcationPeriod.endDate* визначається як (rectificationPeriod.startDate + 48 год)	Майданчик: Після публікації процедури дата початку періоду редагування завжди дорівнює моменту публікації, відображається на: сторінці аукціону на майданчику сторінці аукціону на сайті ДП ПП у полі rectificationPeriod.startDate в арі Дата закінчення періоду редагування відображається на: сторінці аукціону на майданчику сторінці аукціону на сайті ДП ПП у полі rectififcationPeriod.endDate в арі Та завжди розраховується як rectificationPeriod.startDate + 48 годин
	ЦБД: Після публікації процедури дата початку періоду редагування завжди дорівнює моменту публікацыъ а обидві дати фіксуються в арі Дата закінчення періоду редагування фіксується в арі та завжди розраховується як rectificationPeriod.startDate+ 48 годин
	Альтернативні (негативні) сценарії
CBD3-GE-UC-012.1n
Актуальний результат: Створена процедура набуває статусу active.rectification. З виконанням цих дій до створеної процедури додаються поля, що генеруються автоматично, в тому числі тривалості періодів. Період редагування завжди триває 48 один. *rectificationPeriod.startDate, при цьому, дорівнює моменту появи процедури в ЦБД. rectififcationPeriod.endDate* визначається як (rectificationPeriod.startDate + 48 год)	Майданчик: Після публікації процедури дата початку періоду редагування завжди дорівнює моменту публікації, не відображається на: сторінці аукціону на майданчику сторінці аукціону на сайті ДП ПП у полі rectificationPeriod.startDate в арі Дата закінчення періоду редагування не відображається на: сторінці аукціону на майданчику сторінці аукціону на сайті ДП ПП у полі rectififcationPeriod.endDate в арі Та завжди розраховується як rectificationPeriod.startDate + 48 годин
	ЦБД: Після публікації процедури дата початку періоду редагування завжди дорівнює моменту публікації та обидві дати фіксуються в арі Дата закінчення періоду редагування фіксується в арі та завжди розраховується як rectificationPeriod.startDate+ 48 годин
CBD3-GE-UC-012.2n
Актуальний результат: Створена процедура набуває статусу active.rectification. З виконанням цих дій до створеної процедури додаються поля, що генеруються автоматично, в тому числі тривалості періодів. Період редагування завжди триває 48 один. *rectificationPeriod.startDate, при цьому, дорівнює моменту появи процедури в ЦБД. rectififcationPeriod.endDate* визначається як (rectificationPeriod.startDate + 48 год)	Майданчик: Після публікації процедури дата початку періоду редагування не дорівнює моменту публікації, не відображається на: сторінці аукціону на майданчику сторінці аукціону на сайті ДП ПП у полі rectificationPeriod.startDate в арі Дата закінчення періоду редагування не відображається на: сторінці аукціону на майданчику сторінці аукціону на сайті ДП ПП у полі rectififcationPeriod.endDate в арі Та розраховується як rectificationPeriod.startDate +/- 48 годин
	ЦБД: Після публікації процедури дата початку періоду редагування не дорівнює моменту публікації та обидві різні дати фіксуються в арі Дата закінчення періоду редагування фіксується в арі та розраховується як rectificationPeriod.startDate +/- 48 годин

...

CBD3-GE-UC-015	*Фунціонал API ЦБД*
Роль	Учасник
Передумови	Період редагування: rectificationPeriod
Очікуваний результат На час *rectificationPeriod* вводиться обмеження на рівні ЦБД по розміщенню закритих цінових пропозицій. Публікація закритих цінових пропозицій можлива після завершення цього періоду.	Майданчик: До завершення *rectificationPeriod* (Періоду редагування) розміщенню закритих цінових пропозицій заборонено. Публікація закритих цінових пропозицій можлива після завершення цього періоду.
	ЦБД: До завершення *rectificationPeriod* (Періоду редагування) на рівні ЦБД заблоковано розміщення закритих пропозицій
	Альтернативні (негативні) сценарії
CBD3-GE-UC-015.1n
Очікуваний результат: На час *rectificationPeriod* вводиться обмеження на рівні ЦБД по розміщенню закритих цінових пропозицій. Публікація закритих цінових пропозицій можлива після завершення цього періоду.	Майданчик: При спробі розмішення закритих цінових пропозицій до завершення *rectificationPeriod* (Періоду редагування) формується повідомлення про недопустимість таких дій, розміщення закритої цінової пропозиції не відбувається
	ЦБД: При спробі передачі до ЦБД закритої цінової пропозиції до завершення *rectificationPeriod* , ЦБД формує помилку про недопустимість таких дій, цінова пропозиція не приймається та не фіксується у арі

...

CBD3-GE-UC-018	Фунціонал API ЦБД
Роль	Організатор
Передумови	Status: active.rectification (Період редагування)
Очікуваний результат: Тип процедури (*procurementMethodType*) неможливо змінити.	Майданчик: Тип процедури присвоюється автоматично системою та не може бути змінено
	ЦБД: Тип процедури *procurementMethodType* присвоюється автоматично системою та не може бути змінено
	Альтернативні (негативні) сценарії
CBD3-GE-UC-018.1n
Очікуваний результат: Тип процедури (*procurementMethodType*) неможливо змінити.	Майданчик: При спробі редагування значення поля *procurementMethodType* (Тип процедури) майданчик виводить повідомлення про недопустимість редагування, формується помилка про неможливість редагування поля, зміни не зберігаються
	ЦБД: При спробі Організатором відредагувати значення поля *procurementMethodType* (Тип процедури) ЦБД формує помилку про заборону редагування поля, повідомлення про недопустимість редагування поля, зміни, що пропонуються не зберігаються

CBD3-GE-UC-019
Роль	Організатор
Передумови	Status: active.rectification (Період редагування)
Очікуваний результат: Для роботи із переліком сутностей (bid, award, documents, items, questions) одного типу майданчик передає повний перелік сутностей одного типу, який замінює попередній.	Майданчик: Для видалення, редагування або додавання сутності, майданчик передає повний перелік сутностей одного типу, який замінює попередній. Стосується усіх сутностей
	ЦБД: ЦБД приймає від майданчика перелік замінених сутностей одного типу та оновлює або видаляє сутності
	Альтернативні (негативні) сценарії
CBD3-GE-UC-019.1n
Очікуваний результат: Для роботи із переліком сутностей (bid, award, documents, items, questions) одного типу майданчик передає повний перелік сутностей одного типу, який замінює попередній. Стосується усіх сутностей	Майданчик: При спробі передати для видалення, редагування або додавання сутності, майданчик передає перелік сутностей різного типу, для заміни попередній, формується помилка, про те, що перелік містить сутності різного типу, повідомлення про те, що перелік сутностей потрібно переформувати. Зміни, що передавалися переліком не приймаються
	ЦБД: ЦБД не приймає від майданчика перелік замінених сутностей, якщо перелік містить сутності різного типу. Формується помилка про неможливість оновити перелік сутностей, перелік не оновлюється або не видаляє сутності

CBD3-GE-UC-020
Роль	Організатор
Передумови	Status: active.rectification (Період редагування)
	Для редагування\додавання items необхідно передавати повний перелік існуючих items (їх id). У випадку додавання item, якщо не передати попередній перелік, буде пропатчено перший item. Для редагування доступні поля items: address, description і т.д.
Очікуваний результат Для роботи із сутностями (bid, award, documents, items, questions) процедури буде закладено режим: - робота з окремою сутністю, можливість звернутися до ID сутності та відредагувати всі або окремі її поля або видалити таку сутність.	Майданчик: Для роботи із окремим сутностями (bid, award, documents, items, questions) реалізується можливість звернутися до ID сутності та відредагувати всі або окремі її поля або видалити таку сутність
	ЦБД: ЦБД приймає від майданчика, видаляє або оновлює нові дані конкретного ID сутності або окремого її поля
	Альтернативні (негативні) сценарії
CBD3-GE-UC-020.1n
Очікуваний результат Для роботи із сутностями (bid, award, documents, items, questions) процедури буде закладено режим: - робота з окремою сутністю, можливість звернутися до ID сутності та відредагувати всі або окремі її поля або видалити таку сутність.

CBD3-GE-UC-021	Фунціонал майданчиків
Роль	Організатор
Передумови	Status: active.rectification (Період редагування)
Очікуваний результат У Виконавця присутня можливість виправити мета інформацію і вкладені файли (виклик PUT /documents/{did} )і після завершення періоду редагування, але до переведення contract`y до статусу active. і після завершення періоду редагування. При цьому, змінені файли відображаються на веб-сайті Майданчика перекресленими.	Майданчик: Організатор має змогу відредагувати мета інформацію та вкладені файли (виклик PUT /documents/{did} ) після завершення active.rectification (Період редагування) замінені документи доступні для завантаження та перегляду, відображаються в інтерфейсах перекресленим повне видалення інформації неможливе
	ЦБД: і замінений і документ на який замінили відображаються в арі тип та інші параметри, окрім посилання на документ, дати та часу завантаження, ідентичні повне видалення інформації недоступне

Період уточнень: enquiryPeriod (період уточнень - час, коли учасники задають питання, а Організатор відповідає на них)

CBD3-GE-UC-017/1	Фунціонал API ЦБД
Роль
Передумови	Настання Період уточнень: 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*
	Альтернативні (негативні) сценарії
CBD3-GE-UC-017/1.1n
Очікуваний результат Період уточнень - час, коли учасники задають питання, а Організатор відповідає на них - називається **enquiryPeriod. enquiryPeriod.startDate співпадає з rectificationPeriod.startDate. enquiryPeriod.endDate співпадає з tenderPeriod.endDate**	Майданчик: Початок періоду уточнень enquiryPeriod не співпадає з початком періоду редагування rectificationPeriod, а дата завершення періоду уточнень співпадає з кінцем періоду подачі закритих пропозицій tenderPeriod Дата відображається на: сторінці аукціону на майданчику сторінці аукціону на сайті ДП ПП в полях enquiryPeriod.startDate та tenderPeriod.endDate в арі майданчик "підтягує" з ЦБД та відображає на сторінці аукціону назву періоду в якому перебуває процедура Період уточнень, при цьому дата початка періоду уточнень починається з початком періодом редагування Дата завершення періоду уточнень співпадає з кінцем періоду подачі закритих пропозицій
	ЦБД: *enquiryPeriod.startDate* не співпадає з *rectificationPeriod.startDate* *enquiryPeriod.endDate* не співпадає з *tenderPeriod.endDate*

...

CBD3-GE-UC-020/1	Тести API ЦБД Фунціонал майданчиків
Роль
Передумови	Настання Період уточнень: enquiryPeriod
Очікуваний результат	Запитання Учасників є анонімними до закінчення Електронного аукціону. З метою збереження анонімності, ЕТС не надає можливості приєднання файлів до питання. Запитання має бути сформульоване виключно в текстовому вигляді. Запитання можливо задавати виключно до лоту, не до окремих items
Актуальний результат Майданчик попереджає (в інструкції) та слідкує за тим, щоб питання не містило вкладених файлів, було сформоване виключно текстовим та задавалося до лоту, а не окремих items	Майданчик: в окремій або загальній інструкції (залежить від реалізації майданчика) окремим пунктом вказано що: запитання задається до лоту, а не окремих items запитапитання до лоту не має містити вкладень (вкладених файлів) запитання до лоту мають виключно текстовий формат Запитання Учасників є анонімними до закінчення Електронного аукціону. З метою збереження анонімності, ЕТС не надає можливості приєднання файлів до питання. Запитання має бути сформульоване виключно в текстовому вигляді. Запитання можливо задавати виключно до лоту, не до окремих items
	ЦБД: ЦБД приймає та фіксує валідно сформовані питання Перелік полів, що відносяться до передачі питань з майданчика до ЦБД: https://docs.google.com/spreadsheets/d/1P3PDY0RPXewHPat0CTSXW_K3bq29bJDefCgzFWBDgAU/edit?ts=5dc421bd#gid=882183553
	Альтернативні (негативні) сценарії
CBD3-GE-UC-020/1.1n
Майданчик попереджає (в інструкції) та слідкує за тим, щоб питання не містило вкладених файлів, було сформоване виключно текстовим та задавалося до лоту, а не окремих items	в окремій або загальній інструкції (залежить від реалізації майданчика) окремим пунктом не прописано що: запитання задається до лоту, а не окремих items запитапитання до лоту не має містити вкладень (вкладених файлів) запитання до лоту мають виключно текстовий формат Запитання Учасників перестає бути анонімним раніше закінчення Електронного аукціону. При спробі долучити до запитання вкладень, формується повідомлення про те, що запитання не може містити вкладень, питання не публікується, поки недолік не буде виправлено. В разі, якщо запитання формується не тільки у текстовому форматі, формується повідомлення про те, що запитання не може містити вкладень, питання не публікується, поки недолік не буде виправлено. При спробі задати запитання не до лоту, а до окремих items, формується повідомлення про те, що запитання можливо поставити до лоту, а не окремих items , питання не публікується, поки недолік не буде виправлено.
	ЦБД: ЦБД не приймає та не зберігає питання, що містять вкладені файли або не є текстовими Перелік полів, що відносяться до передачі питань з майданчика до ЦБД: https://docs.google.com/spreadsheets/d/1P3PDY0RPXewHPat0CTSXW_K3bq29bJDefCgzFWBDgAU/edit?ts=5dc421bd#gid=882183553

Status: active.tendering (Прийняття заяв на участь)

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 робочих днів
	Альтернативні (негативні) сценарії
CBD3-GE-UC-021/1.1n
Очікуваний результат: Періоду подачі пропозицій учасниками. tenderPeriod.startDate починається одразу після завершення періоду редагування rectificationPerod.endDate.	Майданчик: майданчик не підтягує з ЦБД та не відображає сформовані ЦБД періоди
	ЦБД:
CBD3-GE-UC-021/1.2n
Дата завершення періоду подачі закритих пропозицій tenderPeriod.endDate дорівнює tenderPeriod.startDate + мінімум 30 робочих днів Дата відображається на: сторінці аукціону на майданчику сторінці аукціону на сайті ДП ПП в полях tenderPeriod.startDate та tenderPeriod.endDate в арі	Майданчик: При спробі встановити *tenderPeriod.endDate* меншим за *tenderPeriod.startDate* + 30 робочих днів виводиться повідомлення про необхадність виправити помилки формуваннятакого періоду, формується помилка про неможливість збереження такого періоду, некоректно сформований період не зберігається та не передається до ЦБД
	ЦБД: при спробі передати *tenderPeriod.endDate* меншим за *tenderPeriod.startDate* + 30 робочих днівформується помилка про некоректність формування періоду, невірно сформований період не приймається та не фіксується в ЦБД

CBD3-GE-UC-022	Фунціонал API ЦБД
Роль	Учасник
Передумови	Настання Період подачі пропозицій: tenderPeriod
Очікуваний результат Учасник заповнює поля описані в очікуваному результаті поля та розміщує закриту цінову пропозицію Закриті пропозиції містять: величину потужності об’єкта електроенергетики або черги (пускового комплексу) об’єкта електроенергетики, щодо якого учасник аукціону має намір набути право на підтримку; Мінімум 1МВт цінову пропозицію. Ціна зазначається у євроцентах за 1 кіловат-годину (євроцентів/кВт⋅год) з двома знаками після коми. Цінова пропозиція учасника аукціону не може бути вищою за рівень "зеленого" тарифу (value.amount). Граничний рівень задається Організатором аукціону на етапі публікації процедури у системі.	Майданчик: Майданчик має контролювати заповнення полів закритої пропозиції, та після заповнення передати інформацію про закриту пропозицію до ЦБД. Закриті пропозиції містять: величину потужності об’єкта електроенергетики або черги (пускового комплексу) об’єкта електроенергетики, щодо якого учасник аукціону має намір набути право на підтримку; Мінімум 1МВт цінову пропозицію. Ціна зазначається у євроцентах за 1 кіловат-годину (євроцентів/кВт⋅год) з двома знаками після коми. Цінова пропозиція учасника аукціону не може бути вищою за рівень "зеленого" тарифу (value.amount). Граничний рівень задається Організатором аукціону на етапі публікації процедури у системі.
	ЦБД: Майданчик формує з свого боку закриту цінову пропопозицію та передає до ЦБД. ЦБД з свого боку приймає дані та фіксує їх у поля

CBD3-GE-UC-023	Фунціонал API ЦБД
Роль	Учасник
Передумови	Настання Період подачі пропозицій: tenderPeriod
Очікуваний результат	tenderPeriod.startDate завжди рівний rectificationPerod.endDate
Актуальний результат	Майданчик
Актуальний результат	ЦБД: tenderPeriod.startDate = rectificationPerod.endDate

CBD3-GE-UC-024	Фунціонал API ЦБД
Роль
Передумови	Настання Період подачі пропозицій: 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-039	Фунціонал API ЦБД
Роль
Передумови	Status: active.auction (Аукціон)
Очікуваний результат	Після настання active.auction у ЦБД з'являється публічне посилання для глядачів аукціону і приватне посилання для кожного учасника у його закритій пропозиції. Фактично посилання стають доступними за 5 - 15 хвилин після зміни статусу, що пов’язано з технічними особливостями роботи ЦБД.
Актуальний результат: Загальне посилання для глядачів, розміщений на сторінці аукціону ресурсу ДП ПП та на сторінці аукціону на майданчику та унікальні посилання для участі (унікальні посилання для учасників формуються та передаються на електронні адреси/особисті документи) формуються за 5-15 хвилин до початку торгів. Перехід за посиланням не призводить до запуску модуля аукціону	Майданчик: Загальне посилання для глядачів, розміщений на сторінці аукціону ресурсу ДП ПП та на сторінці аукціону на майданчику та унікальні посилання для участі (унікальні посилання для учасників формуються та передаються на електронні адреси/особисті документи) формуються за 5-15 хвилин до початку торгів. Перехід за посиланням не призводить до запуску модуля аукціону
	ЦБД: ЦБД формує та передає майданчику загальне посилання для глядачів, розміщений на сторінці аукціону ресурсу ДП ПП та на сторінці аукціону на майданчику та унікальні посилання для участі (унікальні посилання для учасників формуються та передаються на електронні адреси/особисті документи) формуються за 5-15 хвилин до початку торгів. Перехід за посиланням не призводить до запуску модуля аукціонуЗагальне посилання для глядачів, розміщений на сторінці аукціону ресурсу ДП ПП та на сторінці аукціону на майданчику та унікальні посилання для участі (унікальні посилання для учасників формуються та передаються на електронні адреси/особисті документи) формуються за 5-15 хвилин до початку торгів. Перехід за посиланням не призводить до запуску модуля аукціону

CBD3-GE-UC-040	Фунціонал API ЦБД
Роль	Учасник
Передумови	Status: active.auction (Аукціон)
Очікуваний результат Учасник переходить за посиланням, дочікується запуску модуля аукціону та приймає участь у аукціоні післі централізованого запуску модуля Посилання унікальне і формується персонально для кожного учасника	Майданчик: Учасник переходить за посиланням, дочікується запуску модуля аукціону та приймає участь у аукціоні післі централізованого запуску модуля
	API/ЦБД на даному етапі всі дії з усіх ІР адрес фіксуються у логах, напряму у АРІ нічго не фіксується і не відображається.
	Альтернативні (негативні) сценарії
Завчасний перехід за почиланням учасника не призводить до запуску модуля	Майданчик: перехід за посиланням дляУчасника (Учасник попереднь залогінився на майданчик) - у разі співпадіння ролей посилання та акаунту на майданчику, відбувається перехід до дисклеймера (в якому перераховані основні правила та умови участі у аукціоні) після погодження з умовами викладеними у ньому (методом натискання кнопки "Так") відбувається перехід до модулю аукціону. Завчасний перехід до модулю не призводить до запуску модулю раніше запланованого часу. перехід за посиланням для Учасника (Учасник попереднь не залогінився на майданчик) у цому варіанті спочатку відбуваразі співпадіння ролей посилання та акаунту на майданчику, відбувається перехід до дисклеймера (в якому перераховані основні правила та умови участі у аукціоні) після погодження з умовами викладеними у ньому (методом натискання кнопки "Так") відбувається перехід до модулю аукціону. Завчасний перехід до модулю не призводить до запуску модулю раніше запланованого часу. перехід за посиланням для Учасника (учасник залогінений з роллю Організатор) при неспівпадінні ролей посилання і облікового запису відбувається перехід до модуля з роллю "Глядач" з можливісттю лише переглядати перебіг роботи модуля
	API/ЦБД на даному етапі всі дії з усіх ІР адрес фіксуються у логах, напряму у АРІ нічго не фіксується і не відображається.

Період верифікації потенційного переможця verificationPeriod (Період перевірки документів учасників)

CBD3-GE-UC-041	Фунціонал API ЦБД
Роль
Передумови	Status: qualification
Очікуваний результат: endDate періодів в процесі Awarding’у фіксуються на рівні 18: 00 за київським часом	Майданчик: endDate періодів в процесі verificationPeriod фіксуються на рівні 18: 00 за київським часом,
	ЦБД: verificationPeriod.endDate фіксуються на рівні 18: 00 за київським часом
CBD3-GE-UC-

042

++++

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

Роль

Передумови

Status: qualification

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

По завершенню аукціону, процедура переходить у статус qualification - фазу перевірки документів учасників. ЦБД формує award`и для N учасників у статусі verification. award`и формуються для всіх учасників, в залежності від кількості заяв на участь

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

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

041.1
Очікуваний результат: endDate періодів в процесі Awarding’у фіксуються на рівні 18: 00 за київським часом	Майданчик: Майданчик підтягує завіксовані дати з АРІ та відображає на сторінці аукціону
	ЦБД/АРІ: verificationPeriod.endDate фіксуються на рівні 18: 00 за київським часом, в разі якщо verificationPeriod.endDate припадає на вихідний день, то він переноситься таким чином, щоб verificationPeriod.endDate фіксувався о 18:00 за київським часом найближчого наступного робочого дня
CBD3-GE-UC-041.2
Очікуваний результат: endDate періодів в процесі Awarding’у фіксуються на рівні 18: 00 за київським часом	Майданчик: Майданчик підтягує завіксовані дати з АРІ та відображає на сторінці аукціону
	ЦБД/АРІ: verificationPeriod.endDate не має фіксуватися на час раніший за 18:00, та не може закінчуватися на день раніше, від попередньо розрахованого

CBD3-GE-UC-

043

042	++++
	Фунціонал

майданчиків

API ЦБД
Роль
Передумови	Status: qualification (фаза перевірки документів учасників)
Очікуваний результат

:

По завершенню аукціону, процедура переходить у статус qualification - фазу перевірки документів учасників.
ЦБД формує award`и для N учасників у статусі verification. award`и формуються для всіх учасників, в залежності від кількості заяв на участь

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

ЦБД/АРІ:
Одразу після завершення роботи модуля аукціону процедурі присвоюється та фіксується в АРІ статус qualification
ЦБД формує award`и для N учасників у статусі verification.
Кількість сформованих award`ів відповідає кількості учасників, що приймали участь у торгах та формуються для всіх учасників, в залежності від кількості заяв на участь

CBD3-GE-UC-043

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

Роль

Передумови

Status: qualification

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

Валідною ставкою вважається та, що

рівна або менша за значення value.amount.

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

Повна юридична назва Учасника
Розмір цінової пропозиції
Обсяг учасника

Розмір з заяви учасника
Фактичний розмір, який отримав учасник

Статус award
Документи учасника
Терміни на перевірку документів та завантаження протоколу\договору

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

Майданчик:

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

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

, відповідно, майданчик "підтягує" з ЦБД/АРІ по всім таким учасникам, наступну інформацію:

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

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

Не валідні ставки не передаються до ЦБД і не відображаються в АРІ

По всім учасникам, ставки яких визнано валідними, відображається наступна інформація: Повна юридична назва Учасника Розмір цінової пропозиції Обсяг учасника Розмір з заяви учасника Фактичний розмір, який отримав учасник Статус award Документи учасника Терміни на перевірку документів та завантаження протоколу\договору Документ з переліком полів: https://docs.google.com/spreadsheets/d/1P3PDY0RPXewHPat0CTSXW_K3bq29bJDefCgzFWBDgAU/edit?ts=5dc421bd#gid=1870318207
	Альтернативні (негативні) сценарії

Очікуваний результат: Не валідні ставки не передаються до ЦБД і не відображаються в АРІ	Майданчик: Майданчик не відображає на сторінці аукціону наступну інформацію: Повна юридична назва Учасника Розмір цінової пропозиції Обсяг учасника Розмір з заяви учасника Фактичний розмір, який отримав учасник Статус award Документи учасника Терміни на перевірку документів та завантаження протоколу\договору Документ з переліком полів: https://docs.google.com/spreadsheets/d/1P3PDY0RPXewHPat0CTSXW_K3bq29bJDefCgzFWBDgAU/edit?ts=5dc421bd#gid=1870318207
	ЦБД: ЦБД/АРІ не фіксує не дані у наступні поля: Повна юридична назва Учасника Розмір цінової пропозиції Обсяг учасника Розмір з заяви учасника Фактичний розмір, який отримав учасник Статус award Документи учасника Терміни на перевірку документів та завантаження протоколу\договору Документ з переліком полів: https://docs.google.com/spreadsheets/d/1P3PDY0RPXewHPat0CTSXW_K3bq29bJDefCgzFWBDgAU/edit?ts=5dc421bd#gid=1870318207

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

~~CBD3-GE-UC-044~~	~~Фунціонал API ЦБД~~
~~Роль~~
~~Передумови~~	~~Status: qualification~~
~~Очікуваний результат~~	ЦБД формує аварди у статусі verification для N учасників з найнижчими ціновими пропозиціями, відповідно до їх обсягу.
~~Очікуваний результат~~	Після завершення роботи модуля аукціона ЦБД формує рейтинг для N учасників одночасно враховуючи два параметри: найнижчу запропоновану вартість та найбільший об’єм

CBD3-GE-UC-045	Фунціонал API ЦБД
Роль
Передумови	Status: qualification
Очікуваний результат	Протокол про результати аукціону формується автоматично у вигляді структурованого машиночитаємого файлу (JSON або YAML) та оприлюднюється в формі електронного документу електронною торговою системою в день завершення аукціону.
Актуальний результат Протокол про результати аукціону формується автоматично у вигляді структурованого машиночитаємого файлу (JSON або YAML) та оприлюднюється в формі електронного документу електронною торговою системою в день завершення аукціону.	Майданчик: Після завершення роботи модуля аукціону майданчик "підтягує" зафіксований в API протокол, відображає його на сторінці аукціоні, у PDF та HTML форматах, протокол доступний для зкачування
	ЦБД: Одразу після завершення роботи модуля аукціону ЦБД у вигляді структурованого машиночитаємого файлу (JSON або YAML) Посилання на сформований выдображається у API

ЦБД:

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

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

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

або

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

ЦБД:

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

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

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

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

CBD3-GE-UC-046	Фунціонал API ЦБД
Роль
CBD3-GE-UC-044	Фунціонал API ЦБД
Роль
Передумови	Status: qualification
Очікуваний результат	ЦБД формує аварди у статусі verification для N учасників з найнижчими ціновими пропозиціями, відповідно до їх обсягу.
Актуальний результат	Після завершення роботи модуля аукціона ЦБД формує рейтинг для N учасників одночасно враховуючи два параметри: найнижчу запропоновану вартість та найбільший об’єм
CBD3-GE-UC-045	Фунціонал API ЦБД
Роль
Передумови	Status: qualification
Очікуваний результат	Протокол про результати аукціону формується автоматично у вигляді структурованого машиночитаємого файлу (JSON або YAML) та оприлюднюється в формі електронного документу електронною торговою системою в день завершення аукціону.
Актуальний результат Протокол про результати аукціону формується автоматично у вигляді структурованого машиночитаємого файлу (JSON або YAML) та оприлюднюється в формі електронного документу електронною торговою системою в день завершення аукціону.	Майданчик: Протокол про результати аукціону формується автоматично у вигляді структурованого машиночитаємого файлу (JSON або YAML) та оприлюднюється в формі електронного документу електронною торговою системою в день завершення аукціону.
	CBD3-GE-UC-046	Фунціонал API ЦБД
Роль
Передумови	Status: qualification
Очікуваний результат	Учасниками вважаються користувачі, які подали повний пакет коректних документів і відповідають вимогам законодавства. Після аукціону Організатор протягом 10 робочих днів (verificationPeriod) здійснює перевірку документів всіх учасників аукціону і підтверджує наявність документів учасника (натискає на майданчику на кнопку “Підтвердити”, після чого майданчик передає award`у такого учасника статус waiting до ЦБД), або відхиляє учасника (завантажує документ - “Акт про невідповідність” - documentType: rejectionProtocol та натискає на кнопку “Відхилити”, після чого майданчик передає статус “unsuccessful” award`u учасника).
Майданчик: Учасником вважається користувач, який надав повний пакет документів (заява + документи, визначені Організатором). Після завершення роботи модулю аукціону, протягом verificationPeriod (10 робочих днів) Організатор перевіряє документи та: підтверджує наявність документів учасника (натискає на майданчику на кнопку “Підтвердити”, після чого майданчик передає award`у такого учасника статус waiting до ЦБД), або відхиляє учасника (завантажує документ - “Акт про невідповідність” - documentType: rejectionProtocol та натискає на кнопку “Відхилити”, після чого майданчик передає статус “unsuccessful” award`u учасника).
CBD3-GE-UC-047	Фунціонал майданчиків
Роль	Організатор, майданчик
Передумови	Status: qualification
Очікуваний результат	Майданчик: після того, як Організатор - гарантований покупець опрацював всі документи всіх Учасників, завантажує “Загальний акт перевірки”, натискає кнопку “Перевірку документів завершено” документи “Загальний акт перевірки” передається до ЦБД та відображається на майданчику статус процедури Кваліфікація учасників Якщо є учасники у статусі verification, в Організатора можливість перевести процедуру до статусу active.qualification відсутня. Якщо в процедурі відсутній документ x_verificationAct - можливість перевести процедуру у статус active.qualification відсутня. Додати документ з таким типом можливо тільки на етапі перевірки документів учасника.
ЦБД:
CBD3-GE-UC-048	Фунціонал майданчиків Фунціонал API ЦБД
Організатор, майданчик
Передумови	Status: qualification
Очікуваний результат Якщо є учасники у статусі verification, в Організатора можливість перевести процедуру до статусу active.qualification відсутня. Якщо в процедурі відсутній документ x_verificationAct - можливість перевести процедуру у статус active.qualification відсутня. Додати документ з таким типом можливо тільки на етапі перевірки документів учасника.	Майданчик: Якщо є хоча б один учасник у статусі Перевірка документів (verification), в Організатора можливість перевести процедуру до статусу active.qualification відсутня. Якщо в процедурі відсутній документ x_verificationAct - можливість перевести процедуру у статус active.qualification відсутня. Додати документ з типом x_verificationAct можливо тільки на етапі перевірки документів учасника.
	ЦБД:

CBD3-GE-UC-049

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

Учасниками вважаються користувачі, які подали повний пакет коректних документів і відповідають вимогам законодавства. Після аукціону Організатор протягом 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`

CBD3-GE-UC-047	Фунціонал майданчиків
Роль	Організатор, майданчик

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


Передумови	Status: qualification
Очікуваний результат

Варіант А.

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

Майданчик:

Варіант А.

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

CBD3-GE-UC-049/1

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

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

Передумови

Status: qualification

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

Варіант Б.

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

Майданчик:

Варіант Б.

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

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

ЦБД:

CBD3-GE-UC-050

Фунціонал API ЦБД
Фунціонал майданчиків

Роль

Передумови

Status: qualification

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

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

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

Майданчик:

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

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

ЦБД:

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

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

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

Альтернативні (негативні) сценаріїМожливо тільки довантажити документи, всю інформацію bid`а (поля та документи), яка була збережена на етапі tenderPeriod, змінювати неможливо.Майданчик:
ЦБД:

CBD3-GE-UC-051

Фунціонал API ЦБД
Фунціонал майданчиків

Роль

Передумови

Status: active.qualification

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

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

Майданчик:ЦБД:

CBD3-GE-UC-052

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

Роль

Передумови

Status: active.qualification

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

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

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

Мацданчик:

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

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

ЦБД:

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

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

Альтернативні (негативні) сценаріїCBD3-GE-UC-052.1n

CBD3-GE-UC-053

Фунціонал API ЦБД
Фунціонал майданчиківРольПередумови

Status: active.qualification

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

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

Майданчик:

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

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

у разі редагування пропозиції під час

Після того, як не залишилось учасників, документи яких розглядаються (всі документи або підтверджено, або відхилено), організатор повинен оприлюднити “Загальний акт перевірки” documentType: x_verificationAct щодо результатів перевірки документів. Організатор завантажує “Загальний акт перевірки”, натискає кнопку “Перевірку документів завершено”, після чого майданчик змінює статус процедури на active.qualification.	Майданчик: після того, як Організатор - гарантований покупець опрацював всі документи всіх Учасників, завантажує “Загальний акт перевірки”, натискає кнопку “Перевірку документів завершено” документи “Загальний акт перевірки” передається до ЦБД та відображається на майданчику статус процедури Кваліфікація учасників Якщо є учасники у статусі verification, в Організатора можливість перевести процедуру до статусу active.qualification відсутня. Якщо в процедурі відсутній документ x_verificationAct - можливість перевести процедуру у статус active.qualification відсутня. Додати документ з таким типом можливо тільки на етапі перевірки документів учасника.
	ЦБД:
	Фунціонал API ЦБД
CBD3-GE-UC-047.1
Якщо є учасники у статусі verification, в Організатора можливість перевести процедуру до статусу active.qualification відсутня.	Майданчик: якщо є хоча б один учасник у статусі verification у Організатора заблоковано завантаження документу “Загальний акт перевірки” documentType: x_verificationAct щодо результатів перевірки документів.. Процедура не набуває статусу active.qualification не небуває
	ЦБД: в разі наявності хоча б одного учасника у статусі verification API не приймає від Майданчика документ “Загальний акт перевірки” documentType: x_verificationAct та не переводить процедуру у статус active.qualification
CBD3-GE-UC-047.2
Якщо в процедурі відсутній документ x_verificationAct - можливість перевести процедуру у статус active.qualification відсутня.	Майданчик: При спробі перевести процедуру у статус active.qualification без завантаження “Загальний акт перевірки” documentType: x_verificationAct щодо результатів перевірки документів виводиться повідомлення/помилка про неможливість такої дії
	ЦБД: в разі спроби перевести процедуру у статус active.qualification без попереднього завантаження “Загальний акт перевірки” documentType: x_verificationAct щодо результатів перевірки документів API не приймає зміну статусу
CBD3-GE-UC-047.3
Додати документ з таким типом можливо тільки на етапі перевірки документів учасника.	Майданчик: поза межами статусу qualification завантаження документу x_verificationAct заблоковано, поля/кнопки для завантаження документу відсутні, в разі спроби завантаження документу x_verificationAct виводиться помилка/текстове повідомлення про невідповідність статусу процедури діям, що виконуються, про неможливість завантажити докумен
	ЦБД: поза межами статусу qualification завантаження документу x_verificationAct заблоковано, при спробі маданчика передати майданчика передати документ x_verificationAct до ЦБД формується помилка про невідповідність дії статусу, документ не приймається і не фіксуєтьс в АРІ, процедура статус не змінює.

~~CBD3-GE-UC-048~~	~~Фунціонал майданчиків~~ включений до CBD3-GE-UC-047 ~~Фунціонал API ЦБД~~
	~~Організатор, майданчик~~
~~Передумови~~	~~Status: qualification~~
~~Очікуваний результат~~ Якщо є учасники у статусі verification, в Організатора можливість перевести процедуру до статусу active.qualification відсутня. Якщо в процедурі відсутній документ x_verificationAct - можливість перевести процедуру у статус active.qualification відсутня. Додати документ з таким типом можливо тільки на етапі перевірки документів учасника.	~~Майданчик:~~ Якщо є хоча б один учасник у статусі Перевірка документів (verification), в Організатора можливість перевести процедуру до статусу active.qualification відсутня. Якщо в процедурі відсутній документ x_verificationAct - можливість перевести процедуру у статус active.qualification відсутня. ~~Додати документ з типом x_verificationAct можливо тільки на етапі перевірки документів учасника.~~
	~~ЦБД:~~

CBD3-GE-UC-049

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

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

Передумови

Status: qualification

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

Варіант А.

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

Майданчик:

Варіант А.

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

ЦБД:

Варіант А.

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

CBD3-GE-UC-049/1

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

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

Передумови

Status: qualification

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

Варіант Б.

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

Майданчик:

Варіант Б.

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

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

ЦБД:

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

CBD3-GE-UC-050	Фунціонал API ЦБД Фунціонал майданчиків
Роль
Передумови	Status: qualification
Очікуваний результат Після завершення аукціону, протягом verificationPeriod, поки award знаходиться у статусі *verification, учасники мають можливість довантажити до bid`а* набір документів для усунення формальних недоліків. Типи документів та неймінг співпадають з документами, які на етапі розміщення заяви додаються до bid`а.	Майданчик: з моменту завершення роботи модуля аукціону і до завершення verificationPeriod, а award має статус *verification* учасники мають можливість використовуючи функціонал майданчика виключно щоб довантажити до bid`а набір документів для усунення недоліків. Типи документів та неймінг співпадають з документами, які на етапі розміщення заяви додаються до bid`а. Дані збереженні на етапі tenderPeriod не редагуються
	ЦБД: від завершення роботи модулю аукціону і до завершення verificationPeriod, а award має статус *verification* майданчик передає довантажені документи які записуються до bid`а. Типи документів та неймінг співпадають з документами, які на етапі розміщення заяви додаються до bid`а. Дані bid`а (поля та документи) збережені на етапі tenderPeriod не змінюються
	Альтернативні (негативні) сценарії
CBD3-GE-UC-050.1
Очікуваний результат Можливо тільки довантажити документи, всю інформацію bid`а (поля та документи), яка була збережена на етапі tenderPeriod, змінювати неможливо.	Майданчик: в разі якщо спроба довантажити до bid`а документи відбувається протягом verificationPeriod, поки award знаходиться у статусі verification, але неймінг та тип документів відрізняється від того, що був завантажений на етапі розміщення заяви форміється повідомлення/помилка про неможливість довантажити нові документи. Завантажувані документи до ЦБД не передаються
	ЦБД: в разі якщо спроба довантажити до bid`а документи відбувається протягом verificationPeriod, поки award знаходиться у статусі verification, але неймінг та тип документів відрізняється від того, що був завантажений на етапі розміщення заяви ЦБДформіється повідомлення/помилка про неможливість довантажити нові документи. Завантажувані документи до ЦБД не фіксуються
CBD3-GE-UC-050.2
Очікуваний результат Дані bid`а (поля та документи) збережені на етапі tenderPeriod не змінюються	Майданчик: При спробі змінити дані bid`а (поля та документи) збережені на етапі tenderPeriod не змінюються, при спробі відредагувати такі дані майданчик виводить повідомлення/помилку про недопустимість таких дій. Відредаговані дані ані bid`а (поля та документи) збережені на етапі tenderPeriod не змінюються не передаються до ЦБД
	ЦБД При спробі передати айданчиком доЦБД змінити дані bid`а (поля та документи) збережені на етапі tenderPeriod не змінюються, при спробі відредагувати такі дані майданчик виводить повідомлення/помилку про недопустимість таких дій. Відредаговані дані ані bid`а (поля та документи) збережені на етапі tenderPeriod не змінюються не передаються до ЦБД

CBD3-GE-UC-051	Фунціонал API ЦБД Фунціонал майданчиків
Роль
Передумови	Status: active.qualification
Очікуваний результат: Після зміни статусу процедури на active.qualification, розраховується обсяг квоти, виходячи з сумарного обсягу учасників, які успішно пройшли перевірку документів. Розрахований обсяг квоти складає 80% від суми обсягів у заявах учасників, але не більше за обсяг квоти, вказаний при публікації аукціону організатором. Після чого змінюється статус award`ів таких учасників і починається етап роботи з протоколом та договором.	Майданчик:
	ЦБД: варіанти розрахунку рейтингу: - якщо бажаний об'єм Гарантованого покупця (items.quantity) менший за 80% від загальної суми всіх об'ємів (x_quantityLimit), то між учасниками розподіляється бажаний об'єм Гарантованого покупця - якщо бажаний об'єм Гарантованого покупця (items.quantity) більший за 80% від загальної суми всіх об'ємів (x_quantityLimit), то між учасниками розподіляється 80% від загальної суми всіх об'ємів - якщо бажаний об'єм Гарантованого покупця (items.quantity) дорівнює 80% від загальної суми всіх об'ємів (x_quantityLimit), то між учасниками розподіляється будьякий, так як вони рівні

CBD3-GE-UC-051.1
Очікуваний результат: розрахунку рейтингу: - якщо бажаний об'єм Гарантованого покупця (items.quantity) менший за 80% від загальної суми всіх об'ємів (x_quantityLimit), то між учасниками розподіляється бажаний об'єм Гарантованого покупця (items.quantity)	Майданчик:
	ЦБД: (items.quantity) < (x_quantityLimit) (items.quantity) розподіляється між Учасниками, що пройшли перевірку документів, вишуковані у рейтинг, починаючи з учасника, що запропонував найменшу ціну. Усі учасники, яким задовольнили запропонований ними об'єм статус змінюється з waiting на pending
CBD3-GE-UC-051.2
якщо бажаний об'єм Гарантованого покупця (items.quantity) більший за 80% від загальної суми всіх об'ємів (x_quantityLimit), то між учасниками розподіляється 80% від загальної суми всіх об'ємів
	ЦБД: (items.quantity) > (x_quantityLimit) (x_quantityLimit) розподіляється між Учасниками, що пройшли перевірку документів, вишуковані у рейтинг, починаючи з учасника, що запропонував найменшу ціну. Усі учасники, яким задовольнили запропонований ними об'єм статус змінюється з waiting на pending
CBD3-GE-UC-051.3
якщо бажаний об'єм Гарантованого покупця (items.quantity) дорівнює 80% від загальної суми всіх об'ємів (x_quantityLimit), то між учасниками розподіляється будьякий, так як вони рівні
	ЦБД: (items.quantity) = (x_quantityLimit) між учасниками розподіляється будьякий, так як вони рівні. Усі учасники, яким задовольнили запропонований ними об'єм статус змінюється з waiting на pending
CBD3-GE-UC-051.4
Якшо після розподілу об'єму Гарантованого покупця (items.quantity) або 80% від загальної суми всіх об'ємів (x_quantityLimit) наявний залишок, який не задовольняє пропозицію наступного кваліфікованого учасника, залишок може бути повністтю або частково бути надано наступному за останім кваліфікованим учасником. Статус такого учасника pending.waiting
	ЦБД: Всім учасникам заявки яких не було задоволено до waitingPeriod.endDate набуває статус pending.waiting
CBD3-GE-UC-051.5
Якшо після розподілу об'єму Гарантованого покупця (items.quantity) або 80% від загальної суми всіх об'ємів (x_quantityLimit) наявний залишок, який не задовольняє пропозицію наступного кваліфікованого учасника, залишок може бути повністтю або частково бути надано наступному за останім кваліфікованим учасником. Статус такого учасника pending.waiting
	ЦБД: при наявності нерозподіленого залишку квоти, який не задовольняє в повному обсязі об'єм вказаний у заяві учника, нерозподілений об'єм заморожується на 29 робочих днів до появи учасника pending.waiting на 30-й робочий день о 00:00

CBD3-GE-UC-052	Фунціонал API ЦБД
Роль
Передумови	Status: active.qualification
Очікуваний результат *signingPeriod.startDate* періоду роботи з протоколом та договором формується: від дати завершення аукціону, для учасників, обсяг заявок яких задовольняється одразу після завершення перевірки документів з дати такої дискваліфікації та оновлення статусу учасника, для учасників, які набувають право на отримання квоти після дискваліфікації одного з переможція	Майданчик: майданчик вичитує з ЦБД сформовані періоди та відображає їх на сторінці аукціону
	ЦБД: з настанням *signingPeriod.startDate* періоду роботи з протоколом та договором формується: від дати завершення аукціону (*"auctionPeriod": endDate), для учасників, обсяг заявок яких задовольняється одразу після завершення перевірки документів з дати такої дискваліфікації та оновлення статусу учасника, для учасників, які набувають право на отримання квоти після дискваліфікації одного з переможція endDate* фіксуються на рівні 18: 00 за київським часом

CBD3-GE-UC-053	Фунціонал API ЦБД Фунціонал майданчиків
Роль
Передумови	Status: active.qualification
Очікуваний результат Пропозиції сортуються від меншої ціни до більшої, а, у випадку співпадіння ціни, вище відображається пропозиція розміщена раніше. Часом розміщення пропозиції вважається час першого розміщення заяви у ЦБД, а, у випадку редагування пропозиції під час періоду прийому пропозицій, час фіксації змін у заяві у ЦБД.	Майданчик:
	ЦБД: одразу після завершення роботи модуля ЦБД формує рейтинг (проміжний) виходячи з вартості за 1 кВт (від меншої до більшої) та часу подання пропозиції: - в разі редагування пропозиції, часом подання вважається час фіксації останіх змін - в разі наявності двох пропозицій однакових за вартісттю, вища відображається та, що була розміщена раніше

CBD3-GE-UC-054	Фунціонал API ЦБД Фунціонал майданчиків
Роль
Передумови	Status: active.qualification Очікується опублікування протоколу та підписання договору signingPeriod
Очікуваний результат Первинно на *SigningPeriod* виділено до 15 робочих днів після закінчення verificationPeriod для кожного award`у, але період триває доти, доки Організатор не переведе процедуру в наступний статус (на рівні ЦБД необхідно реалізувати параметр автоматичної зміни статусу award`у	Майданчик: гарантований покупець протягом Автоматичний перехід процедури до наступного статусу відсутній. *SigningPeriod* триває до 15 робочих днів з моменту закінчення verificationPeriod для кожного award`у Перехід на наступний статус відбувається лише після того, як Організатор - гарантований покупец вручну переведе процедуру
	ЦБД: SigningPeriod.startDate формується від verificationPeriod.endDate та триває до тих пір коли Організатор натисне на кнопку “Завершити аукціон”. Після чого процедура змінює статус на complete.

CBD3-GE-UC-054.1n
Процедура може набути статус complete виключно разі відсутності award`ів pending та pending.waiting	Майданчик: До тих пір, поки наявні award`и в статусі pending та/або pending.waiting можливість Організатором натиснути на кнопку “Завершити аукціон” та перевести процедуру у статус complete заблокована (кнопка відсутня)
	ЦБД: В разі спроби перевести процедуру в статус complete при наявності award`ів pending та/або pending.waiting формується помилка про недопустимість таких дій, зміна статусу не відбувається і в АРІ не фіксуються
CBD3-GE-UC-054.2n
Процедура може набути статус complete виключно в тому разі відсутності award`ів pending та pending.waiting	Майданчик: В разі спроби перевести процедуру в статус complete при наявності award`ів pending та/або pending.waiting майданчик формує/вичитує інтерпретує та виводить помилку про недопустимість таких дій, зміна статусу не відбувається і в АРІ не фіксуються
	ЦБД: В разі спроби перевести процедуру в статус complete при наявності award`ів pending та/або pending.waiting формується помилка про недопустимість таких дій, зміна статусу не відбувається і в АРІ не фіксуються

CBD3-GE-UC-055	Фунціонал API ЦБД Фунціонал майданчиків
Роль
Передумови	Status: active.qualification Очікується опублікування протоколу та підписання договору signingPeriod
Очікуваний результат *SigningPeriod* це період який відноситься до award`у, він формується окремо для кожного учасника під час набуття таким учасником статусу *pending*. Дата початку та завершення періоду для різних учасників може відрізнятися.	Майданчик: *SigningPeriod* це період який відноситься до award`у, він формується окремо для кожного учасника під час набуття таким учасником статусу pending. Дата початку та завершення періоду для різних учасників може відрізнятися.
	ЦБД: ЦБД формує *SigningPeriod* індивідуально з моменту під час набуття таким учасником статусу *pending.* Дата початку та завершення*SigningPeriod* формується для кожного учасника

CBD3-GE-UC-056	Фунціонал API ЦБД Фунціонал майданчиків
Роль
Передумови	Настання періоду очікування кваліфікації переможців (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)

CBD3-GE-UC-057	Фунціонал API ЦБД Фунціонал майданчиків
Роль
Передумови
Очікуваний результат Процедура кваліфікації знаходиться в періоді підписання протоколу, у цей час Організатор зобов’язаний завантажити і підтвердити протокол аукціону (documentType: auctionProtocol) в цей award.	Майданчик: протягом SigningPeriod (Періоду підписання протоколу) Організатор - Гарантований покупець вантажить протокол аукціону (documentType: auctionProtocol) в цей award.
	ЦБД: приймає пртягом SigningPeriod приймає та записує документ з типом documentType: auctionProtocol) в цей award

CBD3-GE-UC-057.1
Процедура кваліфікації знаходиться в періоді підписання протоколу, у цей час Організатор зобов’язаний завантажити і підтвердити протокол аукціону (documentType: auctionProtocol) в цей award.	Майданчик: До настання SigningPeriod можливість завантаження протоколу аукціону (documentType: auctionProtocol) в award заблокована. В разі спроби передати документ до ЦБД до настання SigningPeriod майданчик вичитує/інтерпретує та візуадлізує помилку про недопустимість дії. Зміна статусу не відбувається
	ЦБД: При спробі передати до ЦБД протокол аукціону (documentType: auctionProtocol) в award до настання SigningPeriod.startDate ЦБД формує помилку, протокол не приймаєтьсята не фіксується в ЦБД
CBD3-GE-UC-057.2
Організатор зобов’язаний завантажити і підтвердити протокол аукціону (documentType: auctionProtocol) в цей award.	Майданчик: В разі спроби передати протокол з будь-яким іншим типом, окрім documentType: auctionProtocol Майданчик вичитує/інтепретує помилку сформовану ЦБД про невідповідність типу документу, документ до ЦБД не передається
	ЦБД: Якщо Майданчик передає протокол з типом не documentType: auctionProtocol формується помилка про невідповідність типу документу, документ не приймається і не фіксується

~~CBD3-GE-UC-058~~	неактуально
~~Роль~~
~~Передумови~~
~~Очікуваний результат~~	Якщо протокол завантажено і підтверджено раніше - award учасника переходить до статусу “Очікується договір” (active).
~~Актуальний результат~~	Якщо протокол завантажено і підтверджено раніше - award учасника переходить до статусу “Очікується договір” (active).

CBD3-GE-UC-059	Фунціонал майданчиків Фунціонал API ЦБД
Роль	Організатор
Передумови
Очікуваний результат: В Організатора є можливість підтвердити протокол і після завершення *SigningPeriod,* обмеження на майданчику не мають встановлюватись.	Майданчик: Майданчики не мають обмежувати підтвердження Організатором протоколу після завершення *SigningPeriod*
	ЦБД: ЦБД приймає та фіксує протокол після настання *SigningPeriod.endDate*

CBD3-GE-UC-060	Фунціонал майданчиків Фунціонал API ЦБД
Роль	Організатор
Передумови
Очікуваний результат Після завантаження протоколу організатор натискає кнопку "Протокол затверджено", після чого майданчик переключає статус award’у в active. В результаті чого для цього award’у створюється contract відповідного учасника в статусі pending у масиві contracts.	Майданчик: Після завантаження протоколу організатор натискає кнопку "Протокол затверджено", після чого майданчик переключає статус award’у в active.
	ЦБД: В результаті дій майданчика для цього award’у створюється contract відповідного учасника в статусі pending у масиві contracts.

CBD3-GE-UC-061	Фунціонал майданчиків Фунціонал API ЦБД
Роль	Учасник
Передумови
Очікуваний результат У учасника, який кваліфікується є можливість завантаження Протоколу (тип документу auctionProtocol) в award (не обов’язкова дія), але завантаження цього документу учасником не призводить до зміни статусів в системі.	Майданчик: У учасника, який кваліфікується є можливість завантаження Протоколу (тип документу *auctionProtocol*) в award (не обов’язкова дія), але завантаження цього документу учасником не призводить до зміни статусів в системі.
	ЦБД: Завантаження Протоколу (тип документу auctionProtocol) в award учасником не призводить до зміни статусів в системі.
CBD3-GE-UC-061.1n
У учасника, який кваліфікується є можливість завантаження Протоколу (тип документу auctionProtocol) в award (не обов’язкова дія), але завантаження цього документу учасником не призводить до зміни статусів в системі.	Майданчик: У разі, якщо учасник, який кваліфікується завантажує документу з типом Протокол (тип документу *auctionProtocol*) в award (не обов’язкова дія), а завантаження цього документу учасником призводить до спроби зміни статусів в системі, майданчик вичитує/інтерпретує та виводить помилку ЦБД про неможливість такої дії
	Майданчик: В разі спроби зміни статусів у системі після завантаження *auctionProtocol* учасником, який кваліфікується формується помилка про недопустимість зміни статусу.

ЦБД:

CBD3-GE-UC-054

Фунціонал API ЦБД
Фунціонал майданчиків

Роль

Передумови

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

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

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

Майданчик:

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

CBD3-GE-UC-055

Фунціонал API ЦБД
Фунціонал майданчиківРоль

Передумови

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

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

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

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

ЦБД:

CBD3-GE-UC-056

Фунціонал API ЦБД
Фунціонал майданчиків

Роль

Передумови

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

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

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

Майданчик:

Майданчик выдображає рейтинг

CBD3-GE-UC-057

Фунціонал API ЦБД
Фунціонал майданчиків

Роль

Передумови

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

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

~~CBD3-GE-UC-058~~

неактуально

Роль

Передумови

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

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

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

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

CBD3-GE-UC-059

Фунціонал майданчиків
Фунціонал API ЦБД

Роль

Організатор

Передумови

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

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

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

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

CBD3-GE-UC-060

Фунціонал майданчиків
Фунціонал API ЦБД

Роль

Організатор

Передумови

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

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

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

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

CBD3-GE-UC-061

Фунціонал майданчиків
Фунціонал API ЦБД

Роль

Учасник

Передумови

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

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

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

Завантаження цього документу учасником не призводить до зміни статусів в системі.

CBD3-GE-UC-062

Фунціонал майданчиків
Фунціонал API ЦБДОрганізатор

Передумови

CBD3-GE-UC-062	Фунціонал майданчиків Фунціонал API ЦБД
Організатор
Передумови
Очікуваний результат У разі відмови переможця від підписання протоколу про результати аукціону, Гарантований покупець складає та оприлюднює в електронній торговій системі акт (documentType: act), натискає на кнопку “Дискваліфікувати учасника” і вказує одну чи декілька причин зі списку: Переможець Відмовився від підписання протоколу Не надав обов’язкові документи Після чого майданчик передає статус unsuccessful award`у учасника	Майданчик: Гарантований покупець (поза системою) складає акт (documentType: act) та завантажує його до ЕТЦ після чого натискає кнопку “Дискваліфікувати учасника” і вказує одну чи декілька причин зі списку: Переможець Відмовився від підписання протоколу Не надав обов’язкові документи Після чого майданчик передає статус unsuccessful award`у учасника, а після зміни статусу такого/таких award'ів учасників відображає оновлений статус на сторінці аукціону
	ЦБД: Приймає від Майданчика документ з типом documentType: act та причину дискваліфікації, фіксує у відповідних полях АРІ після чого змінює статус award`у такого учасника учасника на unsuccessful
CBD3-GE-UC-062.1н
Очікуваний результат У разі відмови переможця від підписання протоколу про результати аукціону, Гарантований покупець складає та оприлюднює в електронній торговій системі акт (documentType: act), натискає на кнопку “Дискваліфікувати учасника” і вказує одну чи декілька причин зі списку: Переможець Відмовився від підписання протоколу Не надав обов’язкові документи Після чого майданчик передає статус unsuccessful award`у учасника	Майданчик: При спробі дискваліфікувати Учасника без завантаження акту (documentType: act) майданчик вичитує/інтерпретує та відображає помилку сформовану у ЦБД. Дискваліфікація не можлива, дані до ЦБД не передаються
	ЦБД: При спробі передати Майданчиком дискваліфікацію Учасника без завантаження акту (documentType: act) ЦБД формує помилку. Дискваліфікація не можлива, статус award ЦБД не змінює
CBD3-GE-UC-062.2н

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

У разі відмови переможця від підписання протоколу про результати аукціону,

гарантований

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

Переможець

Відмовився від підписання

протоколу

протоколу
Не надав обов’язкові документи

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

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

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

Не надав обов’язкові документи

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

CBD3-GE-UC-063	Фунціонал майданчиків
Роль
Передумови	Очікує рішення (pending.waiting)
Очікуваний результат Для учасників, які не отримали бажану квоту, одразу після аукціону, формуються award’и, що отримують статус pending.waiting. Такі учасники не можуть відмовитись від очікування і чекають на дискваліфікацію попередніх учасників або завершення періоду повернення банківських гарантій (29 робочих днів з моменту завершення аукціону).	Майданчик: Учасники, що не отримали квоту (статус pending.waiting) не можуть відмовитися від очікування протягом періоду Очікування кваліфікації/дискваліфікації переможців (waitingPeriod). Кнопка для відмови від очікування/самодискваліфікації відсутня.
	ЦБД: award’и з статусом pending.waiting не можуть набути статуси unsuccessful та cancelled за власної ініціативи

CBD3-GE-UC-064	Фунціонал API ЦБД
Роль
Передумови
Очікуваний результат Якшо після розподілу об'єму Гарантованого покупця (items.quantity) або 80% від загальної суми всіх об'ємів (x_quantityLimit) наявний залишок, який не задовольняє пропозицію наступного кваліфікованого учасника, залишок може бути повністтю або частково бути надано наступному за останім кваліфікованим учасником.	Майданчик: Майданчик відображає зміну статусів award протягом 5 хвилин з моменту зміни статусу
	ЦБД: В разі якщо протягом waitingPeriod дискваліфіковують учасника/учасників з статусом pending дискваліфіковується, звільнена квота сумується (за наявності) з нерозподіленим залишком і в разі, якщо просумованого нерозподіленого залишку достатньо для покриття заявки наступного, за рейтингом, учасника (статус учасника pending.waiting) то такий учасник набеває статус pending	Якщо один з award’ів у статусі pending дискваліфіковують, і у процедурі є учасники у статусі pending.waiting, відбувається перерозподіл квоти, що звільнилась. Якщо після перерозподілу не використано весь обсяг, залишок обсягу переходить наступному учаснику у статусі pending.waiting	Актуальний результат	При дискваліфікації учасника його квота передається наступному, за чергою, учаснику з статусом pending.waiting та відбувається переозподіл квоти. Якщо після розподілу всеодно є залишок, він передається наступному учаснику з статусом pending.waiting

CBD3-GE-UC-065
	Фунціонал API ЦБД

Роль


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

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

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

Якшо після розподілу об'єму Гарантованого покупця (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 з обсягом, що менший поданій заявці

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

.

CBD3-GE-UC-066
	Фунціонал API ЦБД

Роль

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

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

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

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

...

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

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

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

CBD3-GE-UC-067	Фунціонал API ЦБД
Роль
Передумови
Очікуваний результат

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

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

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

ЦБД:

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

..

CBD3-GE-UC-068	Фунціонал API ЦБД
Роль
Передумови
Очікуваний результат Award може знаходитись у статусу pending.waiting не довше 29 робочих днів після завершення аукціону (на

29

30-й робочий день о

23

00:

59

00). Після завершення періоду, відбувається перевірка можливості кваліфікувати учасника, у випадку відсутності такої можливості, award`и автоматично переходять у статус cancelled

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

Майданчик:

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

ЦБД:
Award може знаходитись у статусу pending.waiting не довше 29 робочих днів після завершення аукціону (на

29

30-й робочий день о

23

00:

59

00). Після завершення періоду, відбувається перевірка можливості кваліфікувати учасника, у випадку відсутності такої можливості, award`и автоматично переходять у статус cancelled

.

CBD3-GE-UC-069
	Фунціонал API ЦБД
Роль
Передумови
Очікуваний результат	Якщо після завершення періоду повернення банківських гарантій (на 30-й робочий день о 00: 00 за київським часом, після завершення аукціону), є учасник у статусі pending.waiting, з обсягом квоти, яка не повністю задовольняє заявку учасника, у award`a такого учасника автоматично формується admissionPeriod тривалістю в 5 робочих днів. Award такого учасника набуває статус pending.admission (умовний переможець): Учасник протягом 5 робочих днів має погодитися або відмовитися від обсягу, який залишився після кваліфікації переможця/ців. У випадку погодження на обсяг, що залишився, умовний переможець в особистому кабінеті надає підтвердження на набуття статусу переможця (pending) та зобов’язаний вказати розмір обсягу, на який погоджується: поле - award.quantity (вказаний обсяг повинен дорівнювати або бути меншим обсягу, що залишився). Після чого у award`a формується signingPeriod, на який виділяється до 15 робочих днів, але період триває доти, доки Організатор не переведе процедуру в наступний статус. У випадку відмови від обсягу, що залишився, або бездіяльності учасника протягом admissionPeriod необхідно передати зміну статусу award`у з pending.admission на cancelled.

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

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

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

.

CBD3-GE-UC-070	Фунціонал API ЦБД
Роль
Передумови	Завершення аукціону (переведення у статус complete)
Очікуваний результат Після підтвердження або дискваліфікації учасників, які не пройшли кваліфікацію (відсутні award`и у

статусі

статусі pending та pending

та pending

.waiting), Організатор натискає на кнопку “Завершити аукціон”. Після чого процедура змінює статус

на

на 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	Фунціонал API ЦБДа
Роль
Передумови
Очікуваний результат	Замовник має право відмовитися від проведення Електронних торгів, шляхом скасування аукціону. Для скасування Замовник зобов’язаний завантажити документ із зазначенням причини скасування аукціону. Технічно можливість скасування аукціону присутня до моменту переходу в один з термінальних статусів.

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

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

.

CBD3-GE-UC-072
	Фунціонал майданчиків Фунціонал API ЦБД
Роль
Передумови
Очікуваний результат	Скасувати аукціон можливо у будь-якому не термінальному статусі процедури, окрім active.auction.
Актуальний результат	До переходу процедури в один з термінальних статусів окрім active.auction аукціон можливо скасувати

...

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

CBD3-GE-UC-0
Роль
Передумови
Очікуваний	результат
Очікуваний	результат

.

Space shortcuts

Page tree

Page History

Versions Compared

Old Version 108

New Version Current

Key

Глоссарій

Процедура розподілу квот

Загальний огляд процедури розподілу квот

Формування лоту

Порядок проведення електронних торгів

Створення процедури

active.rectification

Аукціон з заздалегідь визначеною земельною ділянкою (розписати детальніше)

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

Status:

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

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

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

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

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

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

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

Період уточнень: enquiryPeriod (період уточнень - час, коли учасники задають питання, а Організатор відповідає на них)

Status: active.tendering (Прийняття заяв на участь)

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

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

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

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

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

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

Період верифікації потенційного переможця verificationPeriod (Період перевірки документів учасників)

Status: qualification

Status: qualification

Status: qualification

Status: qualification

Status: qualification

Status: qualification

Status: qualification

Status: qualification

Status: qualification

Status: qualification

Status: qualification

Status: active.qualification

Status: active.qualification

Status: active.qualification

Status: qualification

Status: qualification

Status: qualification

Status: qualification

Status: active.qualification

Status: active.qualification

Status: active.qualification

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

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

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

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

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

Скасування аукціону

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

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

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

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