...
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-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-040 | Входить до скоупу функціональних тестів API ЦБД | |
|---|---|---|
Роль | Учасник | |
Передумови | Status: active.auction (Аукціон) | |
Очікуваний результат Учасник переходить за посиланням, дочікується запуску модуля аукціону та приймає участь у аукціоні післі централізованого запуску модуля | Учасник торгів, після отримання цього посилання від Майданчика, переходить за url на свою індивідуальну сторінку і бере участь в Аукціоні. Аукціон проводиться централізовано, у модулі аукціону, який є частиною ЦБД. Особливості проведення аукціону за посиланням: https://docs.google.com/document/d/1thjxU87HIkXD1PgQKpShMpV46UYBB3xvStW5Mb8Gegc/edit CBD3-GE-UC- | |
Майданчик: Учасник переходить за посиланням, дочікується запуску модуля аукціону та приймає участь у аукціоні післі централізованого запуску модуля Завчасний перехід за почиланням учасника не призводить до запуску модуля | ||
| ЦБД: |
...
CBD3-GE-UC-047 | Функціонал або задачі майданчику | ||
|---|---|---|---|
Роль | Організатор, майданчик | ||
Передумови | Status: qualification | ||
Очікуваний результат Після того, як не залишилось учасників, документи яких розглядаються (всі документи або підтверджено, або відхилено), організатор повинен оприлюднити | “Загальний акт перевірки” documentType: x_verificationAct щодо результатів перевірки документів. Організатор завантажує “Загальний акт перевірки”, натискає кнопку “Перевірку документів завершено”, після чого майданчик змінює статус процедури на active.qualification.
| Актуальний результат Після того, як не залишилось учасників, документи яких розглядаються (всі документи або підтверджено, або відхилено), організатор повинен оприлюднити “Загальний акт перевірки” documentType: x_verificationAct щодо результатів перевірки документів. Організатор завантажує “Загальний акт перевірки”, натискає кнопку “Перевірку документів завершено”, після чого майданчик змінює статус процедури на active.qualification. Якщо є учасники у статусі verification, в Організатора можливість перевести процедуру до статусу active.qualification відсутня. Якщо в процедурі відсутній документ x_verificationAct - можливість перевести процедуру у статус active.qualification відсутня. Додати документ з таким типом можливо тільки на етапі перевірки документів учасника. | Майданчик: після того, як Організатор - гарантований покупець опрацював всі документи всіх Учасників, завантажує “Загальний акт перевірки”, натискає кнопку “Перевірку документів завершено” документи “Загальний акт перевірки” передається до ЦБД та відображається на майданчику статус процедури Кваліфікація учасників Якщо є учасники у статусі verification, в Організатора можливість перевести процедуру до статусу active.qualification відсутня. Якщо в процедурі відсутній документ x_verificationAct - можливість перевести процедуру у статус active.qualification відсутня. Додати документ з таким типом можливо тільки на етапі перевірки документів учасника. |
| ЦБД: |
CBD3-GE-UC-048 | Функціонал або задачі майданчику |
|---|---|
Організатор, майданчик | |
Передумови | 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 |
Очікуваний результат |
Можливо 2 варіанти, з автоматичним завершенням та з ручним. В ЦБД закладаємо можливість перемикатись між опціями
Варіант А.
Варіант А. Автоматичне завершення періоду - якщо по завершенню періоду присутні award`и у статусі verification, такі award`и автоматично змінюють свій статус на waiting, статус процедури автоматично змінюється на active.qualification. Діє принцип мовчазної згоди, ті учасники, документи яких не розглянуто вважаються такими, що успішно пройшли перевірку документів |
Варіант Б.
Автоматичне завершення періоду відсутнє, Організатор має вручну змінити статус award`ів з verification на waiting та процедури з qualification на 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 | Входить |
|---|
CBD3-GE-UC-050
| до скоупу функціональних тестів API ЦБД Функціонал або задачі майданчику | |
|---|---|
Роль | |
Передумови | Status: qualification |
Очікуваний результат Після завершення аукціону, протягом verificationPeriod, поки award знаходиться у статусі verification, учасники мають можливість довантажити до bid`а набір документів для усунення формальних недоліків. Типи документів та неймінг співпадають з документами, які на етапі розміщення заяви додаються до bid`а. Можливо тільки довантажити документи, всю інформацію bid`а (поля та документи), яка була збережена на етапі tenderPeriod, змінювати неможливо. | Майданчик: з моменту завершення роботи модуля аукціону і до завершення verificationPeriod, а award має статус verification учасники мають можливість використовуючи функціонал майданчика виключно довантажити до bid`а набір документів для усунення недоліків. Типи документів та неймінг співпадають з документами, які на етапі розміщення заяви додаються до bid`а. Дані збереженні на етапі tenderPeriod не редагуються |
ЦБД: від завершення роботи модулю аукціону і до завершення verificationPeriod, а award має статус verification майданчик передає довантажені документи які записуються до bid`а. Типи документів та неймінг співпадають з документами, які на етапі розміщення заяви додаються до bid`а. Дані bid`а (поля та документи) збережені на етапі tenderPeriod не змінюються |
ЦБД:
CBD3-GE-UC-051
Функціонал або задачі майданчику
CBD3-GE-UC-051 | Входить до скоупу функціональних тестів API ЦБД Функціонал або задачі майданчику |
|---|
Роль | |
Передумови | Status: active.qualification |
Очікуваний результат |
Майданчик:
Після зміни статусу процедури на active.qualification, розраховується обсяг квоти, виходячи з сумарного обсягу учасників, які успішно пройшли перевірку документів. Розрахований обсяг квоти складає 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
Очікуваний результат
Первинно на SigningPeriod виділено до 15 робочих днів після закінчення verificationPeriod для кожного award`у, але період триває доти, доки Організатор не переведе процедуру в наступний статус (на рівні ЦБД необхідно реалізувати параметр автоматичної зміни статусу award`у, аналогічно до завершення verificationPeriod).
| Входить до скоупу функціональних тестів API ЦБД Функціонал або задачі майданчику | |
|---|---|
Роль | |
Передумови | Status: active.qualification |
Очікуваний результат Первинно на 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 |
Актуальний результат
CBD3-GE-UC-057 | Входить до скоупу функціональних тестів API ЦБД Функціонал або задачі майданчику |
|---|---|
Роль | |
Передумови | |
Очікуваний |
Процедура кваліфікації знаходиться в періоді підписання протоколу, у цей час Організатор зобов’язаний завантажити і підтвердити протокол аукціону (documentType: auctionProtocol) в цей award.
результат Процедура кваліфікації знаходиться в періоді підписання протоколу, у цей час Організатор зобов’язаний завантажити і підтвердити протокол аукціону (documentType: auctionProtocol) в цей award |
. | |
| неактуально |
Роль | |
Передумови | |
Очікуваний результат | Якщо протокол завантажено і підтверджено раніше - 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`у учасника |
.
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% не змінюється. |
...