Загальні сценарії: Зелені аукціони (renewables): процедура
Глоссарій
- tenderPeriod - період подачі початкових пропозицій
- enquiryPeriod - період уточнень, коли можна задати питання та отримати відповіді на них.
- rectificationPeriod - період, коли Організатор може вносити зміни в процедури. Триває 48 годин після публікації процедури. У цей період ЦБД не приймає закриті цінові пропозиції учасників.
- auctionPeriod - період, коли проводиться аукціон.
- verificationPeriod - період, коли Організатор кваліфікує переможця. Результатом цього періоду є завантаження та підтвердження протоколу Організатором.
- signingPeriod - період, коли Організатор завантажує та активує контракт.
- startDate - дата та час початку періоду.
- endDate - дата та час закінчення періоду.
- Валідна ставка - це ставка, що рівна або менша за значення value.amount
- CAV-PS та CPV - основний класифікатор. Деталі по роботі з класифікаторами https://docs.google.com/document/d/10ExA2rhhbk8u558rv9VSef_531UROwxYNdcyR25Gyt8/edit CBD3-GE-UC-heading=h.mdysz87o4uja
- CPVS - додатковий класифікатор.
- Кваліфікація - процес, що включає роботу з протоколом та договором після завершення аукціону (авардинг, awarding). Під час кваліфікації визначається відповідність переможця\переможців критеріям та факт виконання переможцем вимог (вимоги та критерії визначає Організатор при публікації аукціону або є зазначеними в Регламенті роботи ЕТС). Кваліфікацію проходять одночасно декілька учасників.
Процедура розподілу квот
Загальний огляд процедури розподілу квот
З метою проведення аукціонів з розподілу квот підтримки для електричної енергії з альтернативних джерел енергії в межах системи ProZorro.Sale CDB3 реалізовано procurementMethodType: renewables. Крім продажу квот, схожі процедури та тип аукціону можуть використовуватись для продажу товарів де, крім ціни, учасник зазначає обсяг товару, який бажає придбати.
Критерієм вибору переможця є цінова пропозиція, що складається з ціни за 1 КВт-годину та обсяг генерації у МВт, за умови відповідності пропозиції учасника кваліфікаційним критеріям, визначеним Організатором.
Кваліфікація відбувається після завершення аукціону. Попередньої кваліфікації немає
За результатами аукціону пропозиції учасників сортуються по ціні та кваліфікуються ті учасники, яким вистачило запропонованого Організатором обсягу квоти. У випадку дискваліфікації одного з учасників, кваліфікація переходить до наступного учасника в черзі, якщо такий учасник не відкликав свій гарантійний внесок до моменту потенційної кваліфікації.
Загальні відомості про процедуру
Додати посилання на загальне ТЗ після появи
Документація до api: http://procedure-prozorro-sale.raccoongang.com/api/doc
Схема "Загальний процес аукціонів" renewables (ЦБД-2) - Сonfluence
Public API
- sandbox
- production
Формування лоту
Етап відбувається поза системою.
Організатор укладає договір щодо організації аукціону з Оператором електронного майданчика.
Організатор готує умови аукціону, приймає всі необхідні внутрішні рішення відповідно до Регламенту та інших пов’язаних НПА та готує необхідні документи.
Важливо! Організатор відповідальний за юридичну сторону підготовки аукціону: він має сформувати точний перелік вимог до покупців щодо наявних дозволів, ліцензій тощо. Також Організатор відповідальний за аналіз НПА, що впливають на проведення його аукціону (за винятком загальних положень, як то Регламент ЦБД)
Організатор готує заявку на проведення Електронних торгів в ЕТС (на стороні майданчика) через Особистий кабінет.
Після підготовки лоту і оформлення усієї необхідної документації починається етап “Створення процедури”.
Порядок проведення електронних торгів
Створення процедури
Під час створення процедури, Організатор виконує наступні дії:
- зазначає необхідну інформацію в полях оголошеного аукціону (структуру даних аукціону див. нижче).
- завантажує документацію (відповідно до Регламенту та пов’язаних НПА)
CBD3-GE-UC-001 | Створення процедур Тести API ЦБД |
Роль | Гарантований покупець - Організатор |
Передумови | |
Очікуваний результат | Організатор вказує єдину дату при заведенні процедури - орієнтовний час початку аукціону (auctionPeriod.startDate у запиті, auctionPeriod.shouldStartAfter у api після створення процедури). Точну дату початку торгів визначає система з огляду на поточну завантаженість, інформація про точну дату фіксується автоматично у полі auctionPeriod.startDate. |
Актуальний результат : При створенні процедури організатор вказує лише бажану дату проведення торгів, виходячи з цієї дати автоматично визначається дата проведення, та може відрізнятися від бажаної дати проведення вказаної організатором у більшу сторону. Дата не редагується | Майданчик: |
ЦБД: виходячи с бажаної дати проведення вказаної організатором та навантаження ЦБД розраховує дату проведення аукціону, яка фіксується автоматично у полі auctionPeriod.startDate. Дата проведення визначена ЦБД не може бути відредагована |
CBD3-GE-UC-002 | Створення процедури Тести API ЦБД |
Роль | Гарантований покупець - Організатор |
Передумови | Завантаження clarifications - Уточнення до питань заданих учасниками. Опис причин редагування |
Очікуваний результат | Дата початку торгів не може змінюватись Організатором після публікації. |
Актуальний результат : | Майданчик: Значення полів: дата проведення аукціону, бажаний об'єм не можуть бути відредаговані. Для збереження виправлень обов'язково завантажується документ clarifications ( Уточнення до питань заданих учасниками. Опис причин редагування) |
ЦБД: При збереженні відредагованої процедури до ЦБД передаються виправлені значення та замінюють попередні значення До ЦБД передається документ clarifications з описом причин редагування |
CBD3-GE-UC-003 | Створення процедури Тести API ЦБД |
Роль | ЦБД |
Передумови | |
Очікуваний результат | Перенесення дати (перепланування аукціону) можливе у випадку непередбачуваних технічних збоїв під час проведення аукціонів з метою захисту прав Учасників торгів (fail-safe поведінка), і виконується автоматично на стороні ЦБД або у випадку адміністративного втручання, якщо штатні механізми ЦБД не відпрацювали коректно і автоматичного перенесення не відбулось. |
Актуальний результат: Перенесення дати (перепланування аукціону) можливе у випадку непередбачуваних технічних збоїв під час проведення аукціонів з метою захисту прав Учасників торгів (fail-safe поведінка), і виконується автоматично на стороні ЦБД або у випадку адміністративного втручання, якщо штатні механізми ЦБД не відпрацювали коректно і автоматичного перенесення не відбулось. | Майданчик: |
ЦБД: Перенесення дати (перепланування аукціону) можливе у випадку непередбачуваних технічних збоїв під час проведення аукціонів з метою захисту прав Учасників торгів (fail-safe поведінка), і виконується автоматично на стороні ЦБД або у випадку адміністративного втручання, якщо штатні механізми ЦБД не відпрацювали коректно і автоматичного перенесення не відбулось. |
CBD3-GE-UC-004 | Створення процедури Функціонал або задачі майданчику |
Роль | Гарантований покупець - Організатор |
Передумови | |
Очікуваний результат | Лише Організатор може оголосити електронні торги, сформувавши їх параметри та опублікувавши умови продажу майна\права користування та вимоги до учасників. |
Актуальний результат Тільки користувач з роллю Організатор торгів може оголосити торги створивши та опублікувавши процедуру, після заповнення всіх обов'язкових полів | Майданчик: |
ЦБД: До публікації процедури ЦБД не залучається |
CBD3-GE-UC-005 | Створення процедури Функціонал або задачі майданчику |
Роль | Гарантований покупець - Організатор |
Передумови | |
Очікуваний результат | Організатор може зберегти аукціон без публікації в ЦБД - для внесення змін та перегляду (чернетка). Це - обов’язковий функціонал, що має бути присутній на майданчику. |
Актуальний результат Після створення аукціону, але до публікації в ЦБД, організатор має можливість зберегти на майданчику чернетку аукціону, яку можна повністю редагувати та видаляти без будь-яких наслідків | Майданчик: Організатор до публікації має право зберегти процедуру у статусі draft. |
ЦБД: До публікації процедури ЦБД не залучається |
CBD3-GE-UC-006 | Створення процедури |
Функціонал або задачі майданчику | |
Роль | Гарантований покупець - Організатор |
Передумови | |
Очікуваний результат | Майданчик забезпечує можливість редагування сформованої заявки на проведення Електронних торгів (чернетки) до моменту публікації оголошення про проведення Електронних торгів у ЦБД. У Організатора є можливість оголосити аукціон на основі попереднього аукціону (створити копію аукціону) |
Актуальний результат Після створення заявки, але до публікації в ЦБД, організатор має можливість зберегти на майданчику чернетку заявки, яку можна повністю редагувати та видаляти без будь-яких наслідків | Майданчик: Організатор до публікації має право зберегти процедуру у статусі draft. Така процедура редагується, повторно зберігається та видаляється без обмежень. Наявна можливість публікації процедури з раніше створенного/збереженного/попередньо відредагованої чернетки. |
ЦБД: До публікації процедури ЦБД не залучається |
CBD3-GE-UC-007 | Створення процедури Тести API ЦБД |
Роль | Гарантований покупець - Організатор |
Передумови | |
Очікуваний результат | При публікації оголошення про проведення аукціону, Організатором вноситься наступна інформація (частина полів заповнюються системою автоматично):
|
Актуальний результат | Майданчик: Публікація оголошення про проведення аукціону можлива лише після заповнення всіх обов’язкових полів та завантаження документів до item. При публікації відбувається перевірка заповненості полів даними |
ЦБД: |
CBD3-GE-UC-008 | Функціонал або задачі майданчику |
Роль | Учасник |
Передумови | |
Очікуваний результат | До участі допускаються учасники, які сформували необхідний пакет документів (залежить від вимог Організатора і зазначається у аукціоні) і вчасно сплатили гарантійний внесок. Перевіркою документів і наявності гарантійного внеску займається Оператор електронного майданчика. |
Актуальний результат Перевірка відповідністі учасника вимогам висунутим Організатором лежить повністю на майданчику, за замовчуванням вважається, що відображені документи перевірено, а гарантійний внесок сплачено. Майданчик має проставляти відповідну відмітку (з датою та часом перевірки). | Майданчик: На даному етапі Організатор натискає кнопку підтвердження або відхилення документів учасника, відбувається зміна статусу аварду. Зміна статусу аварду відбувається відповідно до існуючих процедур |
ЦБД: |
CBD3-GE-UC-009 | Тести API ЦБД |
Роль | Учасник |
Передумови | |
Очікуваний результат | До завершення аукціону з Учасниками напряму контактують виключно Оператори електронних майданчиків. |
Актуальний результат | Майданчик: До завершення аукціону відсутній зв’язок замовника та потенційних переможцем/ями. Всі консультації надає майданчик. |
ЦБД: До завершення аукціону відсутній зв’язок замовника та потенційних переможцем/ями. Всі консультації надає майданчик. |
Аукціон з заздалегідь визначеною земельною ділянкою (розписати детальніше)
CBD3-GE-UC-010 | Функціонал або задачі майданчику Входить до скоупу функціональних тестів API ЦБД |
Роль | |
Передумови | Status: active.rectification (Період редагування) |
Очікуваний результат | При публікації аукціону у ЦБД, система визначає startDate та endDate періоду редагування з урахуванням дати, переданої при публікації до ЦБД. |
Актуальний результат | Майданчик: Організатор - гарантований покупець заповнює поля аукціону та натискає на кнопку "Опублікувати", після успішної публікації майданчик виводить та відображає автоматично розраховану дату початку та кінця періоду редагування Після натискання кнопки “Опублікувати” система автоматично визначає дату початку періоду редагування та кінець періоду редагування. Дата відображається на:
|
ЦБД: Після натискання кнопки "Опублікувати" Організатором - гарантованим покупцем до ЦБД передаються наступні автогенеровані поля: 1. ata.id 2. data.auctionID ЦБД розраховує, повертає майданчику та відображає в api startDate та endDate active.rectification (Період редагування) |
CBD3-GE-UC-011 | Тести API ЦБД |
Роль | ЦБД |
Передумови | Status: |
Очікуваний результат | Створена процедура набуває статусу active.rectification. З виконанням цих дій до створеної процедури додаються поля, що генеруються автоматично, в тому числі тривалості періодів. |
Актуальний результат | Маданчик: Після публікації і набуття процедурою статусу active.rectification, майданчик виводить значення startDate та endDate active.rectification (Період редагування) та статус процедури - Період редагування |
ЦБД: статус процедури одразу по публікації active.rectification, окрім статусу процедури в api фіксується startDate та endDate active.rectification |
CBD3-GE-UC-012 | Тести API ЦБД |
Роль | |
Передумови | |
Очікуваний результат | Період редагування завжди триває 48 годин. rectificationPeriod.startDate, при цьому, дорівнює моменту появи процедури в ЦБД. rectififcationPeriod.endDate визначається як (rectificationPeriod.startDate + 48 год) |
Актуальний результат: Після публікації процедури дата початку періоду редагування завжди дорівнює моменту публікації, відображається на:
Дата закінчення періоду редагування відображається на:
Та завжди розраховується як rectificationPeriod.startDate + 48 годин | Майданчик: Після публікації процедури дата початку періоду редагування завжди дорівнює моменту публікації, відображається на:
Дата закінчення періоду редагування відображається на:
Та завжди розраховується як rectificationPeriod.startDate + 48 годин |
ЦБД: Після публікації процедури дата початку періоду редагування завжди дорівнює моменту публікації, відображається на:
Дата закінчення періоду редагування відображається на:
Та завжди розраховується як rectificationPeriod.startDate + 48 годин |
CBD3-GE-UC-013 | Функціонал або задачі майданчику Входить до скоупу функціональних тестів API ЦБД |
Роль | |
Передумови | |
Очікуваний результат | Документи аукціону є можливість завантажувати\змінювати і після завершення періоду редагування. |
Актуальний результат: Завершення періоду редагування не блокує можливості довантажити/замінити документи до аукціону. Видалення документів неможливе. Документ що був замінений відображається перекресленим. | Майданчик: |
ЦБД: |
CBD3-GE-UC-014 | Тести API ЦБД |
Роль | |
Передумови | |
Очікуваний результат | Під час rectificationPeriod’у Організатор має змогу відредагувати окремі поля, інформація про це міститься у таблиці зі структурою даних. |
Актуальний результат | Майданчик: Протягом active.rectification (періоду редагування) можливо редагувати поля згідно таблиці |
ЦБД: поля відредаговані в період active.rectification (періоду редагування) перезаписуються, попередні значення не зберігаються |
Структура даних процедури Аукціон (до кейсу 014)
Поле | Опис | Редаг-ся |
id | рядок, автогенерований, лише для читання Приклад: 64fb59935cd5402691b1d1c43765a6ba | ні |
auctionID | Рядок, автогенерований, лише для читання, Ідентифікатор процедури | ні |
procurementMethodType:renewables | Тип даних:Рядок, Тип процедури аукціону: Аукціон з розподілу квот підтримки на виробництво електроенергії з альтернативних джерел енергії Коротка назва: “Зелені аукціони” required | ні |
procuringEntity | Organization, Гарантований покупець (безпосередньо заводить процедуру і проводить аукціон), required | так |
Рядок, Для схеми UA-EDR - код ЄДРПОУ або ІПН | так | |
procuringEntity.identifier.legalName | Рядок, Повна юридична назва (наприклад - ПУБЛІЧНЕ АКЦІОНЕРНЕ ТОВАРИСТВО "УКРПОШТА") | так |
lotIdentifier | Рядок, Номер лоту, required | так |
title | Рядок, Найменування об’єкту, required | так |
description | Рядок, Опис лоту, required | так |
value | Value, Стартова вартість аукціону “Зелений тариф”, required | так |
value.currency | Валюта (для зеленої енергетики може використовуватись євро), required | ні |
guarantee | Guarantee, Розмір гарантійного внеску, required | так |
minimalStep | Value, Мінімальний крок аукціону required | так |
auctionPeriod.startDate | Date, Дата початку торгів, required | ні |
minNumberOfQualifiedBids | Integer, Мінімальна кількість учасників аукціону (за замовчуванням 2, за регламентом має бути мінімум 2 учасники) | ні |
tenderAttempts | Integer, Лоти виставляються, не обов'язково При публікації: Значення від 1 до 10, та варіант “Невідомо”. Якщо інформація відсутня, в інтерфейсі майданчика нічого не відображається | так |
items | Array of Items, обов’язково Склад лоту, актив Активи, які входять у склад лоту, лот має містити не менше одного item`у | так |
documents | Array of Documents Усі документи та пов’язані додатки Документація, що стосується продажу лоту на аукціоні і додається Організатором під час публікації або редагування торгів. Наприклад фото, типовий договір і т.д. http://dgf.api-docs.ea2.openprocurement.io/en/latest/upload.html - робота з Document service | так |
CBD3-GE-UC-015 | |
Тести API ЦБД | |
Роль | Учасник |
Передумови | |
Очікуваний результат | На час rectificationPeriod вводиться обмеження на рівні ЦБД по розміщенню закритих цінових пропозицій. Публікація закритих цінових пропозицій можлива після завершення цього періоду. |
Актуальний результат До завершення періоду редагування на рівні ЦБД заблоковано розміщення закритих пропозицій | Майданчик: До завершення rectificationPeriod (Періоду редагування) розміщенню закритих цінових пропозицій заборонено. Публікація закритих цінових пропозицій можлива після завершення цього періоду. |
ЦБД: До завершення rectificationPeriod (Періоду редагування) на рівні ЦБД заблоковано розміщення закритих пропозицій |
CBD3-GE-UC-016 | Тести API ЦБД |
Роль | Гарантований покупець - Організатор |
Передумови | |
Очікуваний результат | Значення rectificationPeriod.endDate не може змінюватись Організатором. |
Актуальний результат Дата завершення періоду завершення періоду редагування rectificationPeriod.endDate завжди визначається автоматично та не може бути відредаговане Організатором | Майданчик: |
ЦБД: rectificationPeriod.endDate не може бути выдредаговано стандартними методами |
CBD3-GE-UC-017 | Тести API ЦБД |
Роль | Організатором |
Передумови | Настання Період уточнень: rectificationPeriod |
Очікуваний результат | Значення rectificationPeriod.endDate не може змінюватись Організатором. |
Актуальний результат Дата завершення періоду редагування розраховується автоматично при публікації процедури в ЦБД та не може бути змінена при редагуванні процедури | Майданчик: Дата завершення періоду редагування розраховується автоматично при публыкації та не може бути відредагованою при переведені процедури в режи редагування |
ЦБД: rectificationPeriod.endDate розраховується автоматотично та не може бути відредаговано. |
CBD3-GE-UC-018 | Тести API ЦБД |
Роль | Організатором |
Передумови | |
Очікуваний результат | Тип процедури (procurementMethodType) неможливо змінити. |
Актуальний результат | Майданчик: Тип процедури присвоюється автоматично системою та не може бути змінено |
ЦБД: Тип процедури procurementMethodType присвоюється автоматично системою та не може бути змінено |
CBD3-GE-UC-019 | |
Роль | Організатор |
Передумови | |
Очікуваний результат | Для видалення items змінюємо кількість (items.quantity) на 0. При необхідності, 0 можна знову змінити на потрібне значення. |
Актуальний результат Для видалення items змінюємо кількість (items.quantity) на 0. При необхідності, 0 можна знову змінити на потрібне значення. | Майданчик: |
ЦБД: |
CBD3-GE-UC-020 | |
Роль | Організатор |
Передумови | |
Очікуваний результат | Для редагування\додавання items необхідно передавати повний перелік існуючих items (їх id). У випадку додавання item, якщо не передати попередній перелік, буде пропатчено перший item. Для редагування доступні поля items: address, description і т.д. |
Актуальний результат Для редагування\додавання items необхідно передавати повний перелік існуючих items (їх id). У випадку додавання item, якщо не передати попередній перелік, буде пропатчено перший item. Для редагування доступні поля items: address, description і т.д | Майданчик: |
ЦБД: Для редагування\додавання items необхідно передавати повний перелік існуючих items (їх id). У випадку додавання item, якщо не передати попередній перелік, буде пропатчено перший item. Для редагування доступні поля items: address, description і т.д |
CBD3-GE-UC-021 | Функціонал або задачі майданчику |
Роль | Організатор |
Передумови | |
Очікуваний результат | У Виконавця присутня можливість виправити мета інформацію і вкладені файли (виклик PUT /documents/{did} ) і після завершення періоду редагування. При цьому, змінені файли відображаються на веб-сайті Майданчика перекресленими. |
Актуальний результат У Виконавця присутня можливість виправити мета інформацію і вкладені файли (виклик PUT /documents/{did} ) і після завершення періоду редагування. При цьому, змінені файли відображаються на веб-сайті Майданчика перекресленими. Повне видалення інформації неможливе. | Майданчик: виконавець має змогу відредагувати мета інформацію та вкладені файли (виклик 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 Дата відображається на:
| Майданчик: майданчик "підтягує" з ЦБД та відображає на сторінці аукціону назву періоду в якому перебуває процедура
|
ЦБД/API: enquiryPeriod.startDate = rectificationPeriod.startDate enquiryPeriod.endDate = tenderPeriod.endDate |
CBD3-GE-UC-018/1 | Тести API ЦБД |
Роль | |
Передумови | Настання Період уточнень: enquiryPeriod |
Очікуваний результат | Особливості Періоду уточнень: enquiryPeriod 1. можливість учаснику задати питання закінчується за 1 день (о 18:00 попереднього дня) до enquiryPeriod.endDate 2. організатор може надавати відповіді в рамках всього enquiryPeriod |
Актуальний результат У учасника немає бути можливості задати питання після 18:00 дня що передує дню проведення торгів У організатора повинна бути можливість відповісти на запитання учасників в рамках всього періоду Приклад роботи з питаннями у туторіалі api-docs: https://procedure-prozorro-sale.raccoongang.com/api/doc#/questions | Майданчик: |
ЦБД: з моменту настання 20:00 дня що передує дню проведення аукціону учасник втрачає можливість |
CBD3-GE-UC-019/1 | Функціонал або задачі майданчику |
Роль | |
Передумови | Настання Період уточнень: enquiryPeriod |
Очікуваний результат | Майданчики зобов’язані:
Всі питання / відповіді зберігаються в ЕТС і є доступними всім для перегляду, незалежно від статусу Електронних торгів. |
Актуальний результат Майданчик надсилає в персональний кабінет та на пошту повідомлення про отримання запитання. В разі ненадання відповіді, повідомлення про питання надсилається 1 раз на добу. | Майданчик: при наявності питання до лоту/аукціону майданчик надсилає Гарантованому покупцеві сповіщення про таке питання |
ЦБД: |
CBD3-GE-UC-020/1 | |
Тести API ЦБД | |
Роль | |
Передумови | Настання Період уточнень: enquiryPeriod |
Очікуваний результат | Запитання Учасників є анонімними до закінчення Електронного аукціону. З метою збереження анонімності, ЕТС не надає можливості приєднання файлів до питання. Запитання має бути сформульоване виключно в текстовому вигляді. Запитання можливо задавати виключно до лоту, не до окремих items |
Актуальний результат Майданчик попереджає (в інструкції) та слідкує за тим, щоб питання не містило вкладених файлів, було сформоване виключно текстовим та задавалося до лоту, а не окремих items | Майданчик: в окремій або загальній інструкції (залежить від реалізації майданчика) окремим пунктом вказано що: запитання задається ло лоту, а не окремих items запитапитання до лоту не має містити вкладень (вкладених файлів) запитання до лоту мають виключно текстовий формат |
ЦБД: |
Status: active.tendering (Прийняття заяв на участь)
CBD3-GE-UC-021/1 | Тести API ЦБД |
Роль | |
Передумови | Настання Період подачі пропозицій: tenderPeriod |
Очікуваний результат | Після створення аукціону, система визначає startDate та endDate періоду подачі пропозицій учасниками. tenderPeriod.startDate починається одразу після завершення rectificationPerod.endDate. Мінімальна тривалість періоду складає 30 робочих днів. В статусі active.tendering учасникам дозволяється подавати закриті початкові пропозиції (bids). |
Актуальний результат: Періоду подачі пропозицій учасниками. tenderPeriod.startDate починається одразу після завершення періоду редагування rectificationPerod.endDate. Дата завершення періоду подачі закритих пропозицій tenderPeriod.endDate дорівнює tenderPeriod.startDate + мінімум 30 робочих днів Дата відображається на:
| Майданчик: майданчик підтягує з ЦБД та відображає на сторінці аукціону інформацію про початок та завершення tenderPeriod (період подачі пропозицій) інформація про початок періоду подачі пропозицій підтягується з рядка tenderPeriod.startDate інформація про завершення першення періоду подачі пропозицій підтягується з рядка tenderPeriod.endDate |
ЦБД: Періоду подачі пропозицій учасниками. tenderPeriod.startDate починається одразу після завершення періоду редагування rectificationPerod.endDate. tenderPeriod.endDate дорівнює tenderPeriod.startDate + мінімум 30 робочих днів |
CBD3-GE-UC-022 | Тести API ЦБД |
Роль | Учасник |
Передумови | Настання Період подачі пропозицій: tenderPeriod |
Очікуваний результат | Закриті пропозиції містять:
|
Актуальний результат Учасник заповнює поля описані в очікуваному результаті поля та розміщує закриту цінову пропозицію | Майданчик: Майданчик має контролювати заповнення полів закритої пропозиції, та після заповнення передати інформацію про закриту пропозицію до ЦБД. Закриті пропозиції містять:
|
ЦБД: |
CBD3-GE-UC-023 | Тести API ЦБД |
Роль | Учасник |
Передумови | Настання Період подачі пропозицій: tenderPeriod |
Очікуваний результат | tenderPeriod.startDate завжди рівний rectificationPerod.endDate |
Актуальний результат | Майданчик |
ЦБД: tenderPeriod.startDate = rectificationPerod.endDate |
CBD3-GE-UC-024 | Тести API ЦБД |
Роль | |
Передумови | Настання Період подачі пропозицій: tenderPeriod |
Очікуваний результат | tenderPeriod.endDate завжди наступає о 20.00 дня, що передує дню проведення аукціону (крім тих випадків, коли auction.Period.startDate був змінений штатними механізмами роботи системи). В момент настання tenderPeriod.endDate статус процедури змінюється на active.auction. |
Актуальний результат Період подачі пропозицій tenderPeriod.endDate закінчується виключно о 20:00 дня, що передує дню проведення аукціону. В момент настання tenderPeriod.endDate процедура змінює статус на active.auction. Дата відображається на:
| Майданчик: Майданчик відображає завершення періоду редагування о 20:00 дня що передує дню проведення аукціону Після настання 20:00 дня що передує аукціону подача закритих пропозицій блокується В момент настання кінця періоду прийняття пропозицій відображуваний статус процедури - Аукціон |
ЦБД: |
CBD3-GE-UC-026 | Тести API ЦБД | ||||||||||||||||||||||||||||||||
Роль | Учасник | ||||||||||||||||||||||||||||||||
Передумови | |||||||||||||||||||||||||||||||||
Очікуваний результат | Для участі в аукціоні суб’єкти господарювання разом із заявою довільної форми обов’язково подають набір документів. | ||||||||||||||||||||||||||||||||
Актуальний результат Учасник подає заяву у довільній формі, та, визначений організатором набір документів з переліку: Типи документів
| Майданчик: Для участі в аукціоні суб’єкти господарювання разом із заявою довільної форми обов’язково подають набір документів. Типи документів
| ||||||||||||||||||||||||||||||||
ЦБД: |
CBD3-GE-UC-027 | Входить до скоупу функціональних тестів API ЦБД |
---|---|
Роль | |
Передумови | |
Очікуваний результат | Майданчик розміщує ставку bid у ЦБД у статусі draft. У випадку успішного розміщення отримує від ЦБД токен bid`a (access token) і переводить ставку у статус active. Майданчик несе відповідальність за збереження access token та його нерозголошення. |
Актуальний результат | Майданчик: розміщує ставку bid у ЦБД у статусі draft. У випадку успішного розміщення отримує від ЦБД токен bid`a (access token) і переводить ставку у статус active. Майданчик несе відповідальність за збереження access token та його нерозголошення. |
Майданчик розміщує ставку bid у ЦБД у статусі draft. У випадку успішного розміщення отримує від ЦБД токен bid`a (access token) і переводить ставку у статус active. Майданчик несе відповідальність за збереження access token та його нерозголошення. |
Роль | |
Передумови | |
Очікуваний результат | Якщо розміщення ставки у статусі draft не відбулось або ЦБД не повернула токен доступу, майданчик надсилає повторний запит для розміщення. Якщо запит на переведення ставки у статус active був не успішний, майданчик надсилає повторний запит для активації ставки. Важливо не розміщувати bid одразу у статусі active, так як у випадку, якщо майданчик не отримає або втратить токен для цього bid`a, ставка буде розміщена у ЦБД але у майданчика не буде до неї доступу. https://procedure-prozorro-sale.raccoongang.com/api/doc#/bids |
Актуальний результат | Якщо розміщення ставки у статусі draft не відбулось або ЦБД не повернула токен доступу, майданчик надсилає повторний запит для розміщення. Якщо запит на переведення ставки у статус active був не успішний, майданчик надсилає повторний запит для активації ставки. Важливо не розміщувати bid одразу у статусі active, так як у випадку, якщо майданчик не отримає або втратить токен для цього bid`a, ставка буде розміщена у ЦБД але у майданчика не буде до неї доступу. https://procedure-prozorro-sale.raccoongang.com/api/doc#/bids |
CBD3-GE-UC-029 | Тести API ЦБД |
---|---|
Роль | Учасник |
Передумови | |
Очікуваний результат | Учасник має право вносити зміни та уточнення до поданої ним цінової пропозиції до закінчення періоду прийому пропозицій, визначених для даних Електронних торгів (tenderPeriod.endDate). |
Актуальний результат: До завершення періоду прийому закритих пропозицій (після публікації в ЦБД) Учасник може редагувати свою пропозицію. Виключення становить об’єм енергії який пропонується, а вартість редагується лише в сторону зменшення. | Майданчик: з моменту публікації і до завершення прийому пропозицій Учасник може змінювати дані в своїй пропозиці. Окрім запропонованого об'єму (редагування поля повністтю заблоковане), а вартість може бути відредаговано виключно в сторону зменшення |
ЦБД: |
CBD3-GE-UC-031 | Тести API ЦБД |
---|---|
Роль | Учасник, Організатор |
Передумови | |
Очікуваний результат | Вся історія змін, внесених в період подачі пропозицій tenderPeriod, зберігається в ЦБД. |
Актуальний результат Всі зміни внесені в період внесення пропозицій tenderPeriod мають зберігатися в ЦБД | Майданчик: всі зміни внесені в період подачі пропозицій передаються до ЦБД та зберігаються там |
ЦБД: змінені документи в період подачі пропозицій замінюються, в той час як значення полей перезаписується. |
CBD3-GE-UC-032 | Тести API ЦБД |
---|---|
Роль | Учасник |
Передумови | |
Очікуваний результат | Запит на анулювання пропозиції та внесення змін до пропозиції може надійти тільки на Майданчику, через який було зареєстровано пропозицію від відповідного Учасника. |
Актуальний результат | Майданчик: Всі дії з заявкою (анулювання та редагування) учасник виконує виключно через майданчик, з якого заявку було подано |
ЦБД: порівнюється інформація про майданчик з якого було подано пропозицію та про майданчик з якого намагається відбутися передача виправлень, у разі співпадіння правки передаються та зберігаються. |
CBD3-GE-UC-033 | Тести API ЦБД |
---|---|
Роль | Учасник |
Передумови | |
Очікуваний результат | Анулювати можна тільки пропозицію в аукціоні, що має статус в Електронних торгах - "Прийняття заяв на участь" (active.tendering). |
Актуальний результат Виключно протягом періоду "Прийняття заяв на участь" (active.tendering) Учасник має змогу анулювати заявку на участь | Майданчик: протягом періоду "Прийняття заяв на участь" (active.tendering) учасник має змогу анулювати свою заґвку |
ЦБД: протягом "Прийняття заяв на участь" (active.tendering) інформація про анулювання заявки передається до ЦБД та зберігається там |
CBD3-GE-UC-034 | Тести API ЦБД |
---|---|
Роль | |
Передумови | |
Очікуваний результат | Після розкриття цінових пропозицій, інформація про анульовані пропозиції Учасників не розкривається у публічному api. Майданчик повертає Учаснику гарантійний внесок. |
Актуальний результат При розкритті пропозицій анульовані не розкриваються, а ігноруються. | Майданчик: При розкритті майданчик відображає список пропозицій виключаючи анульовані. Анульовані пропозиції ігноруються і не публікуються. Власнику анульованної пропозиції майданчик повертає гарантійний внесок. Повернення гарантійного внеску відбувається після розкриття цінових пропозицій. |
ЦБД: |
CBD3-GE-UC-035 | Тести API ЦБД |
---|---|
Роль | |
Передумови | |
Очікуваний результат | Для видалення майданчик відправляє наступний запит до ЦБД: DELETE auctions/auction_id/bids/bid_id?acc_token=your_access_token |
Актуальний результат Для видалення майданчик відправляє наступний запит до ЦБД: DELETE auctions/auction_id/bids/bid_id?acc_token=your_access_token | Майданчик: в разі видалення видалення пропозиції з майданчика передається (після ручних маніпуляцій по видаленню пропозиції) передає запит до ЦБД: DELETE auctions/auction_id/bids/bid_id?acc_token=your_access_token |
ЦБД: після отримання та успішної обробки запиту : DELETE auctions/auction_id/bids/bid_id?acc_token=your_access_token запис по пропозиції може бути видалена/прихована |
CBD3-GE-UC-036 | Тести API ЦБД |
---|---|
Роль | |
Передумови | |
Очікуваний результат | Якщо на етапі active.tendering було розміщено 2 і більше закритих цінові пропозиції, після завершення етапу статус процедури змінюється на active.auction. У протилежному випадку аукціон визнається таким, що не відбувся. Статус змінюється на unsuccessful. |
Актуальний результат Мінімальна кількість учасників 2 і більше, в цьому випадку | Майданчик: Майданчик підтягує з api та відображає статус процедури: у разі наявності 2 і більше закритих заявок процедура набуває статус Аукціон (active.auction) у разі наявності менше 2 закритих пропозицій або менше процедуна рабуває статус Торги не відбулися (unsuccessful) |
ЦБД: у разі наявності 2 і більше закритих заявок процедура набуває статус Аукціон (active.auction) у разі наявності менше 2 закритих пропозицій або менше процедуна рабуває статус Торги не відбулися (unsuccessful) |
CBD3-GE-UC-037 | Тести API ЦБД |
---|---|
Роль | |
Передумови | |
Очікуваний результат | Модуль аукціонів генерує унікальні посилання на участь в аукціоні для кожного учасника, які майданчики отримують з ЦБД шляхом синхронізації та передають своїм учасникам. |
Актуальний результат Мінімум за 5 - 15 хвилин до початку аукціону всі учасники отримують на пошту/ у особистий кабінет унікальне згенероване ЦБД посилання. Посилання має бути унікальним для кожного учасника | Майданчик: за 5-15 хвилин після зміни статусу на Аукціон (active.auction) всі продуктивні учасники на пошту отримують унікльні посилання |
ЦБД: за 5-15 хвилин після зміни статусу на Аукціон (active.auction) для всіх продуктивних учасників фармуються унікальні посилання для участі, які передаються через майданчики учасникам |
,
CBD3-GE-UC-038 | Входить до скоупу функціональних тестів API ЦБД |
---|---|
Роль | |
Передумови | |
Очікуваний результат | До завершення аукціону або переходу аукціону у статус unsuccessful ставки учасників залишаються закритими для всіх, включаючи організатора аукціону і доступні виключно для майданчика, який розмістив ставку у ЦБД. |
Актуальний результат До завершення аукціону (продуктивного чи не продуктивного) ставки та закриті пропозиції доступні лише майданчику з якого зроблені та учаснику який їх зробив. | Майданчик: До завершення аукціону (продуктивного чи не продуктивного) ставки та закриті пропозиції доступні лише майданчику з якого зроблені та учаснику який їх зробив. |
ЦБД: До завершення аукціону (продуктивного чи не продуктивного) ставки та закриті пропозиції доступні лише майданчику з якого зроблені та учаснику який їх зробив. |
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 (Аукціон) |
Очікуваний результат | Учасник торгів, після отримання цього посилання від Майданчика, переходить за url на свою індивідуальну сторінку і бере участь в Аукціоні. Аукціон проводиться централізовано, у модулі аукціону, який є частиною ЦБД. Особливості проведення аукціону за посиланням: https://docs.google.com/document/d/1thjxU87HIkXD1PgQKpShMpV46UYBB3xvStW5Mb8Gegc/edit CBD3-GE-UC- |
Актуальний результат: Учасник переходить за посиланням, дочікується запуску модуля аукціону та приймає участь у аукціоні післі централізованого запуску модуля | Майданчик: Учасник переходить за посиланням, дочікується запуску модуля аукціону та приймає участь у аукціоні післі централізованого запуску модуля Завчасний перехід за почиланням учасника не призводить до запуску модуля |
ЦБД: |
Status: qualification
Період верифікації потенційного переможця verificationPeriod (Період перевірки документів учасників)
CBD3-GE-UC-041 | Тести API ЦБД |
Роль | |
Передумови | Status: qualification |
Очікуваний результат | endDate періодів в процесі Awarding’у фіксуються на рівні 18:00. |
Актуальний результат | Всі періоди в Awarding завжди закінчуються о 18:00 |
CBD3-GE-UC-042 | ++++ |
Тести API ЦБД | |
Роль | |
Передумови | Status: qualification |
Очікуваний результат | По завершенню аукціону, процедура переходить у статус qualification - фазу перевірки документів учасників. ЦБД формує award`и для N учасників у статусі verification. award`и формуються для всіх учасників, в залежності від кількості заяв на участь |
Актуальний результат | Одразу після завершення роботи модуля аукціону ЦБД формує протокол, а процедура набуває (в разі позитивного сценарію) статус qualification. ЦБД формує award`и для N учасників у статусі verification. award`и формуються для всіх учасників, в залежності від кількості заяв на участь |
CBD3-GE-UC-043 | |
Функціонал або задачі майданчику | |
Роль | |
Передумови | Status: qualification |
Очікуваний результат | Валідною ставкою вважається та, що рівна або менша за значення 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) та оприлюднюється в формі електронного документу електронною торговою системою в день завершення аукціону. |
CBD3-GE-UC-046 | |
Тести API ЦБД | |
Роль | |
Передумови | Status: qualification |
Очікуваний результат | Учасниками вважаються користувачі, які подали повний пакет коректних документів і відповідають вимогам законодавства. Після аукціону Організатор протягом 10 робочих днів (verificationPeriod) здійснює перевірку документів всіх учасників аукціону і підтверджує наявність документів учасника (натискає на майданчику на кнопку “Підтвердити”, після чого майданчик передає award`у такого учасника статус waiting до ЦБД), або відхиляє учасника (завантажує документ - “Акт про невідповідність” - documentType: rejectionProtocol та натискає на кнопку “Відхилити”, після чого майданчик передає статус “unsuccessful” award`u учасника). |
Актуальний результат | Учасником вважається користувач, який надав повний пакет документів (заява + документи, визначені Організатором).
або
|
CBD3-GE-UC-047 | |
Функціонал або задачі майданчику | |
Роль | Організатор, майданчик |
Передумови | Status: qualification |
Очікуваний результат | Після того, як не залишилось учасників, документи яких розглядаються (всі документи або підтверджено, або відхилено), організатор повинен оприлюднити “Загальний акт перевірки” documentType: x_verificationAct щодо результатів перевірки документів. Організатор завантажує “Загальний акт перевірки”, натискає кнопку “Перевірку документів завершено”, після чого майданчик змінює статус процедури на active.qualification. |
Актуальний результат | Після того як Організатор опрацював всі документи всіх Учасників (підтвердив коректність наданого пакету документів або відхилив надані документи) Організатор завантажує “Загальний акт перевірки”, натискає кнопку “Перевірку документів завершено”, після чого майданчик змінює статус процедури на active.qualification. |
CBD3-GE-UC-048 | |
Функціонал або задачі майданчику | |
Роль | Організатор, майданчик |
Передумови | Status: qualification |
Очікуваний результат | Якщо є учасники у статусі verification, в Організатора можливість перевести процедуру до статусу active.qualification відсутня. Якщо в процедурі відсутній документ x_verificationAct - можливість перевести процедуру у статус active.qualification відсутня. Додати документ з таким типом можливо тільки на етапі перевірки документів учасника. |
Актуальний результат | В разі, якщо у Організатора залишилися не опрацьовані пакети документів Учасників, Організатор можнемає ливості перевести процедуру до статусу active.qualification. Якщо в процедурі відсутній документ x_verificationAct - можливість перевести процедуру у статус active.qualification відсутня. Додати документ з таким типом можливо тільки на етапі перевірки документів учасника. |
CBD3-GE-UC-049 | |
Входить до скоупу функціональних тестів API ЦБД Функціонал або задачі майданчику | |
Роль | |
Передумови | Status: qualification |
Очікуваний результат | Можливо 2 варіанти, з автоматичним завершенням та з ручним. В ЦБД закладаємо можливість перемикатись між опціями Варіант А. Автоматичне завершення періоду - якщо по завершенню періоду присутні award`и у статусі verification, такі award`и автоматично змінюють свій статус на waiting, статус процедури автоматично змінюється на active.qualification. Діє принцип мовчазної згоди, ті учасники, документи яких не розглянуто вважаються такими, що успішно пройшли перевірку документів. Варіант Б. Автоматичне завершення періоду відсутнє, Організатор має вручну змінити статус award`ів з verification на waiting та процедури з qualification на active.qualification. У структурі verificationPeriod з’являється додаткове поле з інформацією про порушення термінів. |
Актуальний результат | Можливо 2 варіанти, з автоматичним завершенням та з ручним. В ЦБД закладаємо можливість перемикатись між опціями Варіант А. Автоматичне завершення періоду - якщо по завершенню періоду присутні award`и у статусі verification, такі award`и автоматично змінюють свій статус на waiting, статус процедури автоматично змінюється на active.qualification. Діє принцип мовчазної згоди, ті учасники, документи яких не розглянуто вважаються такими, що успішно пройшли перевірку документів. Варіант Б. Автоматичне завершення періоду відсутнє, Організатор має вручну змінити статус award`ів з verification на waiting та процедури з qualification на active.qualification. У структурі verificationPeriod з’являється додаткове поле з інформацією про порушення термінів. |
CBD3-GE-UC-050 | |
Входить до скоупу функціональних тестів API ЦБД | |
Роль | |
Передумови | Status: qualification |
Очікуваний результат | Після завершення аукціону, протягом verificationPeriod, поки award знаходиться у статусі verification, учасники мають можливість довантажити до bid`а набір документів для усунення формальних недоліків. Типи документів та неймінг співпадають з документами, які на етапі розміщення заяви додаються до bid`а. Можливо тільки довантажити документи, всю інформацію bid`а (поля та документи), яка була збережена на етапі tenderPeriod, змінювати неможливо. |
Актуальний результат | Можливо тільки довантажити документи, всю інформацію bid`а (поля та документи), яка була збережена на етапі tenderPeriod, змінювати неможливо. |
CBD3-GE-UC-051 | |
Входить до скоупу функціональних тестів API ЦБД | |
Роль | |
Передумови | Status: active.qualification |
Очікуваний результат | Після зміни статусу процедури на active.qualification, розраховується обсяг квоти, виходячи з сумарного обсягу учасників, які успішно пройшли перевірку документів. Розрахований обсяг квоти складає 80% від суми обсягів у заявах учасників, але не більше за обсяг квоти, вказаний при публікації аукціону організатором. Після чого змінюється статус award`ів таких учасників і починається етап роботи з протоколом та договором. |
Актуальний результат | Розрахований обсяг квоти складає 80% від суми обсягів у заявах учасників, але не більше за обсяг квоти, вказаний при публікації аукціону організатором. Після чого змінюється статус award`ів таких учасників і починається етап роботи з протоколом та договором. |
CBD3-GE-UC-052 | |
Тести API ЦБД | |
Роль | |
Передумови | Status: active.qualification |
Очікуваний результат | signingPeriod.startDate періоду роботи з протоколом та договором формується:
|
Актуальний результат | signingPeriod.startDate періоду роботи з протоколом та договором формується:
|
CBD3-GE-UC-053 | |
Роль | Входить до скоупу функціональних тестів API ЦБД |
Передумови | Status: active.qualification |
Очікуваний результат | Пропозиції сортуються від меншої ціни до більшої, а, у випадку співпадіння ціни, вище відображається пропозиція розміщена раніше. Часом розміщення пропозиції вважається час першого розміщення заяви у ЦБД, а, у випадку редагування пропозиції під час періоду прийому пропозицій, час фіксації змін у заяві у ЦБД. |
Актуальний результат | Пропозиції сортуються від меншої ціни до більшої, а, у випадку співпадіння ціни, вище відображається пропозиція розміщена раніше. Часом розміщення пропозиції вважається час першого розміщення заяви у ЦБД, а, у випадку редагування пропозиції під час періоду прийому пропозицій, час фіксації змін у заяві у ЦБД. |
.
CBD3-GE-UC-054 | |
Входить до скоупу функціональних тестів API ЦБД | |
Роль | |
Передумови | Status: active.qualification |
Очікуваний результат | Первинно на SigningPeriod виділено до 15 робочих днів після закінчення verificationPeriod для кожного award`у, але період триває доти, доки Організатор не переведе процедуру в наступний статус (на рівні ЦБД необхідно реалізувати параметр автоматичної зміни статусу award`у, аналогічно до завершення verificationPeriod). |
Актуальний результат | Первинно на SigningPeriod виділено до 15 робочих днів після закінчення verificationPeriod для кожного award`у, але період триває доти, доки Організатор не переведе процедуру в наступний статус (на рівні ЦБД необхідно реалізувати параметр автоматичної зміни статусу award`у, аналогічно до завершення verificationPeriod). |
CBD3-GE-UC-055 | |
Входить до скоупу функціональних тестів API ЦБД | |
Роль | |
Передумови | Status: active.qualification |
Очікуваний результат | SigningPeriod це період який відноситься до award`у, він формується окремо для кожного учасника під час набуття таким учасником статусу pending. Дата початку та завершення періоду для різних учасників може відрізнятися. |
Актуальний результат | Дата початку та завершення періоду для різних учасників може відрізнятися, так як він формується окремо для кожного учасника під час набуття таким учасником статусу pending. |
CBD3-GE-UC-056 | |
Входить до скоупу функціональних тестів API ЦБД | |
Роль | |
Передумови | Настання періоду очікування кваліфікації переможців (pending) |
Очікуваний результат | Award’ам учасників з найнижчими ставками присвоюється статус pending. При однакових цінових пропозиціях, переможцем вважається той учасник, що подав пропозицію раніше. Час подачі пропозицій враховується та відображається відповідно до стандарту, наприклад: 2019-10-11T14:54:12.708333+03:00 |
Актуальний результат | Award’ам учасників з найнижчими ставками присвоюється статус pending. При однакових цінових пропозиціях, переможцем вважається той учасник, що подав пропозицію раніше. Час подачі пропозицій враховується та відображається відповідно до стандарту, наприклад: 2019-10-11T14:54:12.708333+03:00 |
CBD3-GE-UC-057 | |
Входить до скоупу функціональних тестів API ЦБД | |
Роль | |
Передумови | |
Очікуваний результат | Процедура кваліфікації знаходиться в періоді підписання протоколу, у цей час Організатор зобов’язаний завантажити і підтвердити протокол аукціону (documentType: auctionProtocol) в цей award. |
Актуальний результат | Процедура кваліфікації знаходиться в періоді підписання протоколу, у цей час Організатор зобов’язаний завантажити і підтвердити протокол аукціону (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 ЦБД | |
Роль | Організатор |
Передумови | |
Очікуваний результат | У разі відмови переможця від підписання протоколу про результати аукціону, гарантований покупець складає та оприлюднює в електронній торговій системі акт (documentType: act), натискає на кнопку “Дискваліфікувати учасника” і вказує одну чи декілька причин зі списку:
Після чого майданчик передає статус unsuccessful award`у учасника |
Актуальний результат | У разі відмови переможця від підписання протоколу про результати аукціону, гарантований покупець складає та оприлюднює в електронній торговій системі акт (documentType: act), натискає на кнопку “Дискваліфікувати учасника” і вказує одну чи декілька причин зі списку:
Після чого майданчик передає статус unsuccessful award`у учасника |
.
CBD3-GE-UC-063 | |
Функціонал або задачі майданчику | |
Роль | |
Передумови | Очікує рішення (pending.waiting) |
Очікуваний результат | Для учасників, які не отримали бажану квоту, одразу після аукціону, формуються award’и, що отримують статус pending.waiting. Такі учасники не можуть відмовитись від очікування і чекають на дискваліфікацію попередніх учасників або завершення періоду повернення банківських гарантій (29 робочих днів з моменту завершення аукціону). |
Актуальний результат | Для учасників, що не отримали квоту, одразу після завершення роботи модуля аукціону формуються award’и зі статусом pending.waiting. Учасники для яких сформовано award’и з pending.waiting не мають можливості відмовитися від очікування, а очікують на дискваліфікацію попередніх учасників або завершення періоду повернення банківських гарантій. |
.
CBD3-GE-UC-064 | |
Тести API ЦБД | |
Роль | |
Передумови | |
Очікуваний результат | Якщо один з award’ів у статусі pending дискваліфіковують, і у процедурі є учасники у статусі pending.waiting, відбувається перерозподіл квоти, що звільнилась. Якщо після перерозподілу не використано весь обсяг, залишок обсягу переходить наступному учаснику у статусі pending.waiting |
Актуальний результат | При дискваліфікації учасника його квота передається наступному, за чергою, учаснику з статусом pending.waiting та відбувається переозподіл квоти. Якщо після розподілу всеодно є залишок, він передається наступному учаснику з статусом pending.waiting |
.
CBD3-GE-UC-065 | |
Тести API ЦБД | |
Роль | |
Передумови | |
Очікуваний результат | У випадку, якщо після розподілу квоти залишок менший за обсяг наступного учасника, формується award учасника з обсягом, що залишився після розподілу. |
Актуальний результат | У випадку, якщо після розподілу квоти залишок менший за обсяг наступного учасника, формується award учасника з обсягом, що залишився після розподілу. |
.
CBD3-GE-UC-066 | |
Тести API ЦБД | |
Роль | |
Передумови | |
Очікуваний результат | У випадку дискваліфікації переможця, ЦБД розподіляє обсяг переможців, яких було дискваліфіковано, між учасниками з наступними найменшими за величиною ціновими пропозиціями. При цьому, вже розрахований обсяг квоти 80% не змінюється. |
Актуальний результат | У випадку дискваліфікації переможця, ЦБД розподіляє обсяг переможців, яких було дискваліфіковано, між учасниками з наступними найменшими за величиною ціновими пропозиціями. При цьому, вже розрахований обсяг квоти 80% не змінюється. |
.
CBD3-GE-UC-067 | |
Тести API ЦБД | |
Роль | |
Передумови | |
Очікуваний результат | Якщо в результаті для учасника формується обсяг, що повністю задовольняє його заяву, award такого учасника переходить до статусу pending. З моменту зміни статусу такого award’у на pending для такого учасника формується окремий signingPeriod 15 робочих днів (аналогічно до award`ів, які сформувались спочатку). |
Актуальний результат | Якщо в результаті перерозподілу вивільненої квоти для учасника формується обсяг, що повністю задовольняє його заяву, award такого учасника переходить до статусу pending. |
..
CBD3-GE-UC-068 | |
Входить до скоупу функціональних тестів API ЦБД | |
Роль | |
Передумови | |
Очікуваний результат | Award може знаходитись у статусу pending.waiting не довше 29 робочих днів після завершення аукціону (на 29-й робочий день о 23:59). Після завершення періоду, відбувається перевірка можливості кваліфікувати учасника, у випадку відсутності такої можливості, award`и автоматично переходять у статус cancelled |
Актуальний результат | Award може знаходитись у статусу pending.waiting не довше 29 робочих днів після завершення аукціону (на 29-й робочий день о 23:59). Після завершення періоду, відбувається перевірка можливості кваліфікувати учасника, у випадку відсутності такої можливості, award`и автоматично переходять у статус cancelled |
.
CBD3-GE-UC-069 | |
Входить до скоупу функціональних тестів API ЦБД | |
Роль | |
Передумови | |
Очікуваний результат | Якщо після завершення періоду повернення банківських гарантій (на 30-й робочий день о 00:00 після завершення аукціону), є учасник у статусі pending.waiting, з обсягом квоти, яка не повністю задовольняє заявку учасника, у award`a такого учасника автоматично формується admissionPeriod тривалістю в 5 робочих днів. Award такого учасника набуває статус pending.admission (умовний переможець):
|
Актуальний результат | Якщо після завершення періоду повернення банківських гарантій (на 30-й робочий день о 00:00 після завершення аукціону), є учасник у статусі pending.waiting, з обсягом квоти, яка не повністю задовольняє заявку учасника, у award`a такого учасника автоматично формується admissionPeriod тривалістю в 5 робочих днів. Award такого учасника набуває статус pending.admission (умовний переможець):
|
.
CBD3-GE-UC-070 | |
Входить до скоупу функціональних тестів API ЦБД | |
Роль | |
Передумови | Завершення аукціону (переведення у статус complete) |
Очікуваний результат | Після підтвердження або дискваліфікації учасників, які не пройшли кваліфікацію (відсутні award`и у статусі pending та pending.waiting), Організатор натискає на кнопку “Завершити аукціон”. Після чого процедура змінює статус на complete. |
Актуальний результат | Організатор натискає кнопку “Завершити аукціон” після того як документ всіх учасників було опрацьовано (підтверджено або дискваліфіковано), тобто відсутні award`и у статусі pending та pending.waiting. Після натискання на кнопку “Завершити аукціон” процедура змінює статус на complete. |
.
Скасування аукціону
CBD3-GE-UC-071 | |
Тести API ЦБДа | |
Роль | |
Передумови | |
Очікуваний результат | Замовник має право відмовитися від проведення Електронних торгів, шляхом скасування аукціону. Для скасування Замовник зобов’язаний завантажити документ із зазначенням причини скасування аукціону. Технічно можливість скасування аукціону присутня до моменту переходу в один з термінальних статусів. |
Актуальний результат | Замовник має право відмовитися від проведення Електронних торгів, шляхом скасування аукціону. Для скасування Замовник зобов’язаний завантажити документ із зазначенням причини скасування аукціону. Технічно можливість скасування аукціону присутня до моменту переходу в один з термінальних статусів. |
.
CBD3-GE-UC-072 | |
Функціонал або задачі майданчику Входить до скоупу функціональних тестів API ЦБД | |
Роль | |
Передумови | |
Очікуваний результат | Скасувати аукціон можливо у будь-якому не термінальному статусі процедури, окрім active.auction. |
Актуальний результат | До переходу процедури в один з термінальних статусів окрім active.auction аукціон можливо скасувати |
.
CBD3-GE-UC-0 | |
Роль | |
Передумови | |
Очікуваний результат | |
Актуальний результат |
.