...
За результатами періоду аукціону (auctionPeriod) пропозиції сортуються від меншої ціни до більшої, а у випадку співпадіння ціни, вище відображається пропозиція розміщена раніше. Часом розміщення пропозиції вважається час першого розміщення заяви у ЦБД, а, у випадку редагування пропозиції під час періоду прийому пропозицій, час фіксації змін у заяві у ЦБД. По завершенню аукціону, процедура переходить у статус qualification - фазу перевірки документів учасників. ЦБД генерує award'и для N учасників у статусі verification. award'и формуються для всіх учасників, відповідно до поданих кількості заяв на участь. Валідною ставкою вважається та, що рівна або менша за значення value.amount.
Документи обʼєкта кваліфікації (awards.documents)
...
Обовʼязковіть
...
Завантажується для кожного Аварда, який не пройшов перевірку документів протягом verificationPeriod
Поле terminationReason в даному випадку заповнювати не обовʼязково
...
Так
Для зміни awards.status: verification → unsuccessful
...
Протокол підписується і завантажується для кожного учасника окремо
| Expand | ||
|---|---|---|
| ||
"Гарантований покупець протягом двох робочих днів з дати оприлюднення протоколу про результати аукціону підписує протоколи про результати аукціону щодо кожного переможця" |
Так
Для зміни awards.status: pending → active
...
Завантажується у разі відмови Переможцем підписувати протокол.
Документ має бути можливість завантажити у Організатора та у Переможця.
Для того, щоб Організатор дискваліфікував учасника, Авард якого перебуває у статусі pending, має бути завантажено хоча б один документ з documentType: act
В поле terminationReason аварду записується причина із довідника
Поле terminationReason має бути обовєязково заповнено для зміни awards.status: pending → unsuccessful
Так
Для зміни awards.status: pending → unsuccessful
...
Банківська гарантія для участі в аукціоні, надана на користь гарантованого покупця.
При підписанні протоколу може виникнути потреба в завантаженні оновленої банківської гарантії.
...
Кваліфікація
Періоди Awards
...
verificationPeriod.endDate
...
Період формується в Аварді з моменту набуття Авардом статусу pending
Якщо Авард був у статусі pending і отримав signingPeriod, то після зміни статуса на інший (active OR unsuccessful) період залишається в endpoint
Аварди в інших статусах цей період не отримують.
...
qualificationPeriod.endDate
...
Періоди Awards
| Технічна назва | Бізнесова назва | Дата початку | Дата завершення | Результат завершення | Коментар |
|---|---|---|---|---|---|
| awards.signingPeriod | Період підписання протоколу та договору | verificationPeriod.endDate | signingPeriod.endDate ==signingPeriod.startDate + 15 р.д. | На рівні ЦБД: відсутній | Період формується в Аварді з моменту набуття Авардом статусу pending Якщо Авард був у статусі pending і отримав signingPeriod, то після зміни статуса на інший (active OR unsuccessful) період залишається в endpoint Аварди в інших статусах цей період не отримують. |
| awards.admissionPeriod | Період прийняття рішення щодо набуття статусу переможця | qualificationPeriod.endDate | admissionPeriod.endDate == admissionPeriod.startDate + 5 р.д. | На рівні ЦБД: відсутній | Період формується для Авардів у статусі pending_admission |
| Anchor | ||||
|---|---|---|---|---|
|
| draw.io Diagram | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
| Технічна назва | Бізнесова назва | Перехід з | За умови | Коментар | ||||||
|---|---|---|---|---|---|---|---|---|---|---|
| verification | Перевірка документів | Момент auctionPeriod.endDate створюються Awards | Автоматично. По завершенню аукціону, процедура переходить у статус qualification (Перевірка документів). ЦБД генерує Awards[] у статусі verification для всіх учасників, відповідно до поданих кількості заяв на участь. Валідною ставкою вважається та, що рівна або менша за значення value.amount. |
Часом розміщення пропозиції вважається час першого розміщення заяви у ЦБД, а, у випадку редагування пропозиції під час періоду прийому пропозицій, час фіксації змін у заяві у ЦБД. При формуванні порядку Авардів, необхідно дивитись на Awards.value, але якщо value декількох Авардів однакове, необхідно подивитись, чи відрізняється у кожного bid-а bids.initialValue від bids.value: 1) Якщо учасник оновлював свою ставку протягом МА (bids.value < bids.initialValue), то часом розміщення ставки вважається час оновлення ставки протягом МА 2) Якщо учасник НЕ оновлював |
...
| Технічна назва | Бізнесова назва | Перехід з | За умови | Коментар | ||||||
|---|---|---|---|---|---|---|---|---|---|---|
| verification | Перевірка документів | Момент auctionPeriod.endDate створюються Awards | Автоматично. По завершенню аукціону, процедура переходить у статус qualification (Перевірка документів). ЦБД генерує Awards[] у статусі verification для всіх учасників, відповідно до поданих кількості заяв на участь. Валідною ставкою вважається та, що рівна або менша за значення value.amount. | | Anchor | queue | queue | За результатами роботи МА (auctionPeriod) пропозиції сортуються від меншої ціни до більшої, а у випадку співпадіння ціни, вище відображається пропозиція розміщена раніше.Часом розміщення пропозиції вважається час першого розміщення заяви у ЦБД, а, у випадку редагування пропозиції під час періоду прийому пропозицій, час фіксації змін у заяві у ЦБД. При формуванні порядку Авардів, необхідно дивитись на Awards.value, але якщо value декількох Авардів однакове, необхідно подивитись, чи відрізняється у кожного bid-а bids.initialValue від bids.value: 1) Якщо учасник оновлював свою ставку протягом МА (bids.value < == bids.initialValue), то часом розміщення ставки вважається час оновлення ставки протягом МА 2) Якщо учасник НЕ оновлював свою ставку протягом МА (bids.value == bids.initialValue), то часом розміщення ставки вважається bids.dateModified bids.dateModified 3) Якщо у декількох Авардів однакове value 3) Якщо у декількох Авардів однакове value і ці декілька учасників оновлювали свої ставки протягом МА, то вище в рейтингу має бути той, хто оновлював свою ставку раніше 4) Якщо у декількох Авардів однакове value при цьому один із них НЕ оновлював ставку протягом МА, а інші оновлювали, то вище в рейтингу має бути той, хто НЕ оновлював ставку протягом МА. (бо він розмістив своє value раніше). Його bids.dateModified вважається датою і часом розміщення ставки. Інші учасники своє value розмістили точно пізніше, бо вони оновлювали value протягом МА. Їх порядок має бути згідно часу оновлення їх ставок. Організатор має можливість завантажити та заміни в Аварді документ documentType:rejectionProtocol (лише після цього ЦБД дає можливість змінити Awards.status: verification → unsuccessful ) Організатор має можливість завантажити та заміни в Процедурі документ documentType:x_verificationAct | |||
| waiting | Документи перевірено | verification | Ручна дія. У Організатора має бути можливість змінювати Awards.status: verification → waiting. Обовʼязкові документи для цієї зміни статуса відсутні. Автоматично. Якщо на момент verificationPeriod.endDate залишились Awards у статусі verification, то ЦБД змінює їх статус на waiting | Подальша робота з Авардом відбувається із цього статуса. Частину Авардів в статус waiting може перевести Організатор, а e випадку, коли ЦБД автоматично змінила Awards.status: verification → waiting , він є проміжковим і після цього ЦБД також автоматично змінить статус на pending або pending_waiting | ||||||
| pending | Очікується протокол | waiting АБО pending_waiting АБО pending_admission | Автоматично. waiting → pending: Завершився verificationPeriod.endDate АБО Автоматично. pending_waiting → pending: Дискваліфіковано Авард у статусі pending АБО Ручна дія. pending_admission → pending: Учасник погодився закрити залишок обсягу | Перехід із waiting: Статус pending отримують Аварди, які перебувають перші у списку результатів Модуля Аукціону і які успішно пройшли етап перевірки документів (award.status <> unsuccessful) за умови, що обсяг, який вони запропонували повністю покривається розрахованим значенням x_quantityLimit Організатор має можливість:
Учасник має можливість завантажити та замінити протокол auctionProtocol (не обов'язкова дія) Перехід із pending_waiting: Лише у випадку, якщо Організатор дискваліфікував одного чи більше Переможців, Аварди, що перебувають у статусі pending_waiting автоматино можуть змінити свій статус на pending за умови, що обсяг, який вони запропонували повністю покривається залишком від обсягу, що залишився.
Організатор вказав procedure.items.quantity == 10 000 Учасник_1 запропонував awards.items.quantit == 3 000 по найменшій ціні 10 Учасник_2 запропонував awards.items.quantit == 1 000 по ціні 11 Учасник_3 запропонував awards.items.quantit == 2 000 по ціні 12 Всі три учасники успішно пройшли перевірку документів (awards.status == waiting) ЦБД розраховує x_quantityLimit == (3000 + 1 000 + 2 000) * 0.8 == 4 800 Обсяг 4 800 повністю покриває тільки запропоновані обсяги Учасника_1 і Учасника_2. Запропонований Учасником_3 обсяг повнітю не реалізується (він запропонував 2 000, а після розподілення між першим і другим учасниками, залишилось не розподілено тільки (4 800 - 3 000 - 1 000) == 800 ) В даному прикладі тільки третій учасник отримує статус pending_waiting Після цього Організатор дискваліфіковує Учасника_1 з його пропозицією 3 000. Учасник_3 автоматично отримує статус pending з своєю пропозицією 2 000, бо 2 000 повністю покривається обсягом 4 800 (першого дискваліфікували, другий 1 000, третій 2 000, 1000+2000 = 3000, що менше, ніж 4800) Приклад2: Організатор вказав procedure.items.quantity == 10 000 Учасник_1 запропонував awards.items.quantit == 1 000 по найменшій ціні 10 Учасник_2 запропонував awards.items.quantit == 1 000 по ціні 11 Учасник_3 запропонував awards.items.quantit == 8 000 по ціні 12 Всі три учасники успішно пройшли перевірку документів (awards.status == waiting) ЦБД розраховує x_quantityLimit == (1 000 + 1 000 + 8 000) * 0.8 == 8 000 Обсяг 8000 повністю покриває тільки запропоновані обсяги Учасника_1 і Учасника_2. Запропонований Учасником_3 обсяг повнітю не реалізується (він запропонував 8 000, а після розподілення між першим і другим учасниками, залишилось не розподілено тільки (8 000 - 1 000 - 1 000) == 6 000 ) В даному прикладі тільки третій учасник отримує статус pending_waiting Після цього Організатор дискваліфіковує Учасника_1 з його пропозицією 1 000. Учасник_3 НЕ отримує статус pending з своєю пропозицією 8000, бо 8000 повністю не покривається залишком обсягу (8000 - 1000 = 7000 - залишок обсягу, а Учасник_3 пропонує 8000, що більше, ніж 7000) Його статус залишається pending_waiting. P.S.: в майбутньому він отримає статус "Умовний переможець" (pending_admission) і зможе погодитись реалізувати залишок, який складає 7000 із його запропонованих 8000. Перехід із pending_admission: Учасник в статусі pending_admission має можливість вказати обсяг, який він готовий закрити і змінити статус на pending. Далі відбувається його кваліфікація за стандартною логікою | ||||||
| pending_waiting | Очікується рішення | waiting | Автоматично. Завершився verificationPeriod.endDate | Статус pending_waiting отримують Аварди, які перебувають у списку результатів Модуля Аукціону і які успішно пройшли етап перевірки документів (award.status <> unsuccessful) за умови, що обсяг, який вони запропонували повністю НЕ покривається розрахованим значенням x_quantityLimit, з причини, що обсяг вже закритий іншими пропозиціями. Приклад 1: Організатор вказав procedure.items.quantity == 10 000 Учасник_1 запропонував awards.items.quantit == 3 000 по найменшій ціні 10 Учасник_2 запропонував awards.items.quantit == 1 000 по ціні 11 Учасник_3 запропонував awards.items.quantit == 2 000 по ціні 12 Всі три учасники успішно пройшли перевірку документів (awards.status == waiting) ЦБД розраховує x_quantityLimit == (3000 + 1 000 + 2 000) * 0.8 == 4 800 Обсяг 4 800 повністю покриває тільки запропоновані обсяги Учасника_1 і Учасника_2. Запропонований Учасником_3 обсяг повнітю не реалізується (він запропонував 2 000, а після розподілення між першим і другим учасниками, залишилось не розподілено тільки (4 800 - 3 000 - 1 000) == 800 ) В даному прикладі тільки третій учасник отримує статус pending_waiting Приклад 2: Організатор вказав procedure.items.quantity == 10 000 Учасник_1 запропонував awards.items.quantit 3 000 по найменшій ціні 10 Учасник_2 запропонував 2 000 по ціні 11 Учасник_3 запропонував 1 000 по ціні 12 Всі три учасники успішно пройшли перевірку документів (awards.status == waiting) ЦБД розраховує x_quantityLimit == (3000 + 1 000 + 2 000) * 0.8 == 4 800 Обсяг 4 800 повністю покриває тільки запропонований обсяг Учасника_1. Запропонований Учасником_2 обсяг повнітю не реалізується (він запропонував 2 000, а після Учасника_1 , залишилось не розподілено тільки (4 800 - 3 000) == 1800 ) В даному прикладі другий і третій учасники отримують статус pending_waiting Організатор не може дискваліфікувати Учасника, що очікує рішення Учасник не має можливості відмовитись від очікування. | ||||||
| pending_admission | Підтвердження набуття статусу переможця | pending_waiting | Автоматично. Завершився qualificationPeriod.endDate АБО Автоматично. За умови, що всі Awards, що мали статус pending отримали статус active (Організатор успішно кваліфікував всіх Переможців, залишилось вирішити питання тільки з залишком апропонованого обсягу, що може бути закритий "умовним переможцем") АБО Автоматично. За умови, що взагалі відсутні Аварди у статусі pending | Статус pending_admission отримує тільки один Award, який знаходиться у статусі pending_waiting і запропонував найменшу після Переможців ціну. Згідно Постанови "Учасник, що набуває статусу умовного переможця, визначається на 30-й робочий день після завершення аукціону", але у випадку, коли Організатор успішно кваліфікував всіх переможців (всі Awards у статусі pending набули статусу active), не чекаючи 30-го дня після завершення МА, учасник одразу отримує статус pending_admission і отримує можливість погодитись чи відмовитись від залишку обсягу. Це потрібно для того, щоб після успішної кваліфікації переможців, небуло необхідності чекати завершення періоду кваліфікації для погодження умовним переможцем своє право на набуття статуса переможця. В цьому статусі Умовний переможець може:
| ||||||
| active | Очікується договір | pending | Ручна дія. Організатор надсилає запит на зміну award.status: pending → active ЦБД має валідувати, що в Авард завантажено документ з documentType: auctionProtocol | |||||||
| cancelled | Учасник не став переможцем | pending_admission АБО pending_waiting | Ручна дія. Учасник (умовний переможець) надсилає запит на зміну статуса Автоматично. В момент, коли будь-який Авард набуває статусу pending_admission, всі інші Аварди, які знаходяться у статусі pending_waiting автоматично набувають статус cancelled | Після набуття статусу pending_admission "Умовний переможець" має можливість відмовитись від запропонованого обсягу і скасувати свою заявку (змінити статус Аварда з pending_admission на cancelled) Після набуття статусу pending_admission "Умовний переможець" всі Аварди, які на цей момент заходились у статусі pending_waiting набувають статус cancelled | ||||||
| unsuccessful | Дискваліфіковано | pending АБО verification | Ручна дія. Організатор надсилає запит на зміну award.status: pending → unsuccessful ЦБД має валідувати, що в Авард завантажено документ з documentType: act |
...
За результатами автоматичного розподілення, всі Аварди, які мали статус waiting отримують новий статус pending АБО pending_waiting.
Залежності від періоду verificationPeriod немає. Організатор може раніше завершення цього періоду провести перевірку документів учасників і запитом змінити статус процедури з qualification → active_qualification.
Після цього ЦБД для кожного Аварда у статусі pending генерує протокол.
Від Організатора очікується
- АБО завантаження підписаного протоколу до Аварду, а також завантаження в документи процедури documentType: x_verificationAct + зміна статуса Аварда на active
- АБО завантаження в Авард документа documentType: act і подальша дискваліфікація цього Аварда (зміна статуса Аварда на unsuccessful), а також завантаження в документи процедури documentType: x_verificationAct
Організатор може дискваліфікувати тільки Авард у статусі pending і не може дискваліфікувати Авард у статусі pending_waiting
Якщо Організатор дискваліфіковує Авард, ЦБД має виконати перевірку першого у списку Аварду у статусі pending_waiting.
- Якщо обсяг першого в порядку Аварду у статусі pending_waiting дорівнює чи менше нерозподіленого залишку, то цей Авард автоматично змінює свій статус на pending. Приклади тут
- Якщо обсяг першого в порядку Аварду у статусі pending_waiting більше нерозподіленого залишку, то Авард залишається в статусі pending_waiting. Приклади тут
Кваліфікація Авардів продовжується поки не залишиться жодного Аварда у статусі pending.
Всі Аварди, що отримували статус pending мають бути АБО кваліфіковані (отримати статус active), АБО дискваліфіковані (отримати статус unsuccessful).
Як тільки всі Аварди, що мали статус pending змінили свій статус, Авард, що має статус pending_waiting і знаходиться перший у списку, отримує статус pending_admission (бізнесово називається "Умовний переможець")
Власнику Аварда у статусі pending_admission має бути доступна можливість надіслати запит, в якому вказати quantity. При виконанні запиту ЦБД має перевірити, що quantity, яке вказав Аавард у своєму запит <= нерозподіленому залишку, що дорівнює x_quantityLimit - sum(quantity) всіх Авардів, що отримали статус active.
Після цього "Умовний переможець" має надіслати запит на зміну статуса Аварда pending_admission → pending
Організатор кваліфікує цей Авард і змінює його статус на active, або дискваліфікує і змінює статус на unsuccessful.
Робота з Авардами на цьому завершується.
ПРИКЛАДИ:
...
pending_waiting.
Залежності від періоду verificationPeriod немає. Організатор може раніше завершення цього періоду провести перевірку документів учасників і запитом змінити статус процедури з qualification → active_qualification.
Після цього ЦБД для кожного Аварда у статусі pending генерує протокол.
Від Організатора очікується
- АБО завантаження підписаного протоколу до Аварду, а також завантаження в документи процедури documentType: x_verificationAct + зміна статуса Аварда на active
- АБО завантаження в Авард документа documentType: act і подальша дискваліфікація цього Аварда (зміна статуса Аварда на unsuccessful), а також завантаження в документи процедури documentType: x_verificationAct
Організатор може дискваліфікувати тільки Авард у статусі pending і не може дискваліфікувати Авард у статусі pending_waiting
Якщо Організатор дискваліфіковує Авард, ЦБД має виконати перевірку першого у списку Аварду у статусі pending_waiting.
- Якщо обсяг першого в порядку Аварду у статусі pending_waiting дорівнює чи менше нерозподіленого залишку, то цей Авард автоматично змінює свій статус на pending. Приклади тут
- Якщо обсяг першого в порядку Аварду у статусі pending_waiting більше нерозподіленого залишку, то Авард залишається в статусі pending_waiting. Приклади тут
Кваліфікація Авардів продовжується поки не залишиться жодного Аварда у статусі pending.
Всі Аварди, що отримували статус pending мають бути АБО кваліфіковані (отримати статус active), АБО дискваліфіковані (отримати статус unsuccessful).
Як тільки всі Аварди, що мали статус pending змінили свій статус, Авард, що має статус pending_waiting і знаходиться перший у списку, отримує статус pending_admission (бізнесово називається "Умовний переможець")
Власнику Аварда у статусі pending_admission має бути доступна можливість надіслати запит, в якому вказати quantity. При виконанні запиту ЦБД має перевірити, що quantity, яке вказав Аавард у своєму запит <= нерозподіленому залишку, що дорівнює x_quantityLimit - sum(quantity) всіх Авардів, що отримали статус active.
Після цього "Умовний переможець" має надіслати запит на зміну статуса Аварда pending_admission → pending
Організатор кваліфікує цей Авард і змінює його статус на active, або дискваліфікує і змінює статус на unsuccessful.
Робота з Авардами на цьому завершується.
ПРИКЛАДИ:
| Назва в прикладах | шлях в API | Бізнесова назва |
|---|---|---|
| Організатор | - | Замовник |
| Обсяг | procedure.items[0].quantity | Розмір частки річної квоти |
| Макс ціна | procedure.value.amount | Цінова пропозиція (max) |
| Обсяг пропозиції | procedure.bids[*].quantity | Розмір частки квоти в заяві |
| Ціна пропозиції | procedure.bids[*].value | Цінова пропозиція за 1 кВт⋅год |
Приклад 1:
- Організатор вказав Обсяг == 10000
- Організатор вказав Макс ціну == 12
Прийшло три Учасника:
Учасник_1:
- Обсяг пропозиції == 3000
- Ціна пропозиції == 10
Учасник_2:
- Обсяг пропозиції == 2000
- Ціна пропозиції == 11
Учасник_3:
- Обсяг пропозиції == 1000
- Ціна пропозиції == 12
Всі три учасники успішно пройшли перевірку документів і отримали статус Аварда waiting
ЦБД розрахувала x_quantityLimit == (3000 + 2000 + 1000) * 0,8 == 4800
ЦБД розподіляє Обсяги пропозицій учасників:
Учасник_1:
4800 - 3000 = 1800
В даному прикладі Обсяг пропозиції Учасника_1 покривається x_quantityLimit
Учасник_1 отримує статус pending
Учасник_2:
1800 - 2000 < 0
В даному прикладі Обсяг пропозиції Учасника_2 НЕ покривається x_quantityLimit, бо після Учасника_1 залишився нерозподілений залишок 1800, а Обсяг пропозиції Учасник_2 - більший і дорівнює 2000
Учасник_2 отримує статус pending_waiting
Після того, як Учасник_2 отримав статус pending_waiting, наступні учасники також отримуть цей статус автоматично, незважаючи на те, що їх обсяг пропозиції покривається нерозподіленим залишком (вони запропонували більшу ціну).
Учасник_3 отримує статус pending_waiting
Організатор успішно кваліфікує Учасника_1 і його Авард отримує статус active
ЦБД перевіряє, що відсутні інші Аварди у статусі pending і автоматично змінює статус Учасника_2 на pending_admission (умовний переможець. Пропонуємо забрати нерозподілений залишок).
Всі інші Аварди, які на момент отримання Учасником_2 статусу pending_admission перебували у статусі pending_waiting, автоматично отримують статус cancelled
Учасник_2 приймає пропозицію реалізувати 1800 нерозподіленого залишку із 2000, які він пропонував початково.
Учасник_2 надсилає запит і статус його Аварда змінюється на pending
а) Організатор успішно кваліфікує Учасника_2, змінює статус Аварда на active
Результат: Обсяг 4800 закритий Учасником_1, який забрав 3000 і Учасником_2, який забрав залишок - 1800. Учасник_3 не забрав жодного обсягу
б)
Організатор дискваліфікує Учасника_2, змінює статус Аварда на unsuccessful
Результат: Обсяг 4800 частково закритий Учасником_1, який забрав 3000. Учасник_2 дискваліфікований. Учасник_3 не забрав жодного обсягу
Приклад 2Приклад 1:
- Організатор вказав Обсяг == 10000
- Організатор вказав Макс ціну == 12
...
Після того, як Учасник_2 отримав статус pending_waiting, наступні учасники також отримуть цей статус автоматично, незважаючи на те, що їх обсяг пропозиції покривається нерозподіленим залишком (вони запропонували більшу ціну).
Учасник_3 отримує статус pending_waiting
Організатор успішно кваліфікує Учасника_1 і його Авард отримує статус active
ЦБД перевіряє, що відсутні інші Аварди у статусі pending і автоматично змінює статус Учасника_2 на pending_admission (умовний переможець. Пропонуємо забрати нерозподілений залишок).
Всі інші Аварди, які на момент отримання Учасником_2 статусу pending_admission перебували у статусі pending_waiting, автоматично отримують статус cancelled
Учасник_2 НЕ приймає пропозицію реалізувати 1800 нерозподіленого залишку із 2000, які він пропонував початково.
Учасник_2 надсилає запит і статус його Аварда змінюється на pending
а) Організатор успішно кваліфікує Учасника_2, змінює статус Аварда на active
Результат: Обсяг 4800 закритий Учасником_1, який забрав 3000 і Учасником_2, який забрав залишок - 1800. Учасник_3 не забрав жодного обсягу
б)
він пропонував початково.
Учасник_2 надсилає запит і статус його Аварда змінюється на cancelledОрганізатор дискваліфікує Учасника_2, змінює статус Аварда на unsuccessful
Результат: Обсяг 4800 частково закритий Учасником_1, який забрав 3000. Учасник_2 дискваліфікованийвідмовився закрити залишок, що склада 1800. Учасник_3 не забрав жодного обсягу
Приклад 23:
- Організатор вказав Обсяг == 10000
- Організатор вказав Макс ціну == 12
...
В даному прикладі Обсяг пропозиції Учасника_2 НЕ покривається x_quantityLimit, бо після Учасника_1 залишився нерозподілений залишок 1800, а Обсяг пропозиції Учасник_2 - більший і дорівнює 2000
Учасник_2 отримує статус pending_waiting
Учасник_2 отримує статус pending_waiting
Після того, як Учасник_2 отримав статус pending_waiting, наступні учасники також отримуть цей статус автоматично, незважаючи на те, що їх обсяг пропозиції покривається нерозподіленим залишком (вони запропонували більшу ціну).
Учасник_3 отримує статус pending_waiting
Організатор успішно кваліфікує Учасника_1 і його Авард отримує статус active
ЦБД перевіряє, що відсутні інші Аварди у статусі pending і автоматично змінює статус Учасника_2 на pending_admission (умовний переможець. Пропонуємо забрати нерозподілений залишок).
Всі інші Аварди, які на момент отримання Учасником_2 статусу pending_admission перебували у статусі pending_waiting, автоматично отримують статус cancelled
Учасник_2 НЕ приймає пропозицію реалізувати 1800 нерозподіленого залишку із 2000, які він пропонував початково.
Після того, як Учасник_2 отримав статус pending_waiting, наступні учасники також отримуть цей статус автоматично, незважаючи на те, що їх обсяг пропозиції покривається нерозподіленим залишком (вони запропонували більшу ціну).
Учасник_3 отримує статус pending_waiting
Організатор дискваліфікує Учасника_1 і його Авард отримує статус unsuccessful
При дискваліфікації Учасника із статуса pending → unsuccessful, ЦБД перевіряє наявніть Авардів у статусі pending_waiting
Якщо в рамках періоду очікування результатів кваліфікації (qualificationPeriod) один з award’ів у статусі pending дискваліфіковують, ЦБД розподіляє обсяг переможців, яких було дискваліфіковано, між учасниками з авардами у статусі pending_waiting з наступними найменшими за величиною ціновими пропозиціями. При цьому, вже розрахований обсяг квоти 80% не змінюється. Якщо в результаті для учасника, з award'ом у статусі pending_waiting, формується обсяг, що повністю задовольняє його заяву, award такого учасника переходить до статусу pending. З моменту зміни статусу такого award’у на pending для такого учасника формується окремий період опублікування протоколу та підписання договору (signingPeriod) 15 робочих днів (аналогічно до award'ів, які сформувались спочатку).
Учасник_2 автоматично отримує статус pending
Учасник_3 залишається в статусі pending_waiting
Якщо Організатор дискваліфікує Учасника_2, то Учасник_3 отримає статус pending і почнеться його кваліфікація.
Учасник_3 успішно кваліфіковано.Учасник_2 надсилає запит і статус його Аварда змінюється на cancelled
Результат: Обсяг 4800 частково закритий Учасником_1, який забрав 3000. Учасник_2 відмовився закрити залишок, що склада 1800. Учасник_3 не забрав жодного обсягу3, який запропонував 1000. Учасник_1 і Учасник_2 дискваліфіковані
Приклад 4Приклад 3:
- Організатор вказав Обсяг == 10000
- Організатор вказав Макс ціну == 12
...
Учасник_2:
- Обсяг пропозиції == 20001000
- Ціна пропозиції == 11
Учасник_3:
- Обсяг пропозиції == 10002000
- Ціна пропозиції == 12
Всі три учасники успішно пройшли перевірку документів і отримали статус Аварда waiting
...
Учасник_1 отримує статус pending
Учасник_2:
1800 - 2000 < 01000 = 800
В даному прикладі Обсяг пропозиції Учасника_2 НЕ покривається x_quantityLimit, бо після Учасника_1 залишився нерозподілений залишок 1800, а Обсяг пропозиції Учасник_2 1 - більший і менший, дорівнює 20001000
Учасник_2 отримує статус pending_waitingПісля того, як Учасник_2 отримав статус pending_waiting, наступні учасники також отримуть цей статус автоматично, незважаючи на те, що їх обсяг пропозиції покривається нерозподіленим залишком (вони запропонували більшу ціну).
Учасник_3:
800 - 2000 < 0
В даному прикладі Обсяг пропозиції Учасника_3 НЕ покривається x_quantityLimit, бо після Учасника_1 залишився нерозподілений залишок 1800, частина якого розподілилася на Учасника_2, він забрав 1000, Учаснику_3 залишилось 800, а Обсяг пропозиції Учасника_3 - більший, дорівнює 2000
Учасник_3 отримує статус pending_waiting
Організатор дискваліфікує успішно кваліфікує Учасника_1 і його Авард отримує статус unsuccessful
При дискваліфікації Учасника із статуса pending → unsuccessful, ЦБД перевіряє наявніть Авардів у статусі pending_waiting
Якщо в рамках періоду очікування результатів кваліфікації (qualificationPeriod) один з award’ів у статусі pending дискваліфіковують, ЦБД розподіляє обсяг переможців, яких було дискваліфіковано, між учасниками з авардами у статусі pending_waiting з наступними найменшими за величиною ціновими пропозиціями. При цьому, вже розрахований обсяг квоти 80% не змінюється. Якщо в результаті для учасника, з award'ом у статусі pending_waiting, формується обсяг, що повністю задовольняє його заяву, award такого учасника переходить до статусу pending. З моменту зміни статусу такого award’у на pending для такого учасника формується окремий період опублікування протоколу та підписання договору (signingPeriod) 15 робочих днів (аналогічно до award'ів, які сформувались спочатку).
Учасник_2 автоматично отримує статус pending
Учасник_3 залишається в статусі pending_waiting
Якщо Організатор дискваліфікує Учасника_2, то Учасник_3 отримає статус pending і почнеться його кваліфікація.
Учасник_3 успішно кваліфіковано.
Результат: Обсяг 4800 частково закритий Учасником_3, який запропонував 1000. Учасник_1 і Учасник_2 дискваліфіковані
Приклад 4:
- Організатор вказав Обсяг == 10000
- Організатор вказав Макс ціну == 12
Прийшло три Учасника:
Учасник_1:
- Обсяг пропозиції == 3000
- Ціна пропозиції == 10
Учасник_2:
- Обсяг пропозиції == 1000
- Ціна пропозиції == 11
Учасник_3:
- Обсяг пропозиції == 2000
- Ціна пропозиції == 12
Всі три учасники успішно пройшли перевірку документів і отримали статус Аварда waiting
ЦБД розрахувала x_quantityLimit == (3000 + 2000 + 1000) * 0,8 == 4800
ЦБД розподіляє Обсяги пропозицій учасників:
Учасник_1:
4800 - 3000 = 1800
В даному прикладі Обсяг пропозиції Учасника_1 покривається x_quantityLimit
Учасник_1 отримує статус pending
Учасник_2:
1800 - 1000 = 800
В даному прикладі Обсяг пропозиції Учасника_2 покривається x_quantityLimit, бо після Учасника_1 залишився нерозподілений залишок 1800, а Обсяг пропозиції Учасник_1 - менший, дорівнює 1000
Учасник_2 отримує статус pending
Учасник_3:
800 - 2000 < 0
В даному прикладі Обсяг пропозиції Учасника_3 НЕ покривається x_quantityLimit, бо після Учасника_1 залишився нерозподілений залишок 1800, частина якого розподілилася на Учасника_2, він забрав 1000, Учаснику_3 залишилось 800, а Обсяг пропозиції Учасника_3 - більший, дорівнює 2000
Учасник_3 отримує статус pending_waiting
Організатор успішно кваліфікує Учасника_1 і його Авард отримує статус active
Організатор успішно кваліфікує Учасника_2 і його Авард отримує статус active
Коли всі Awards, які були у статусі pending успішно кваліфіковані, ЦБД перевіряє наявніть Авардів у статусі pending_waiting
Учасник_3 має статус Аварда pending_waiting, його запропонований обсяг повністю не покривається залишком обсягу, що залишився після розподілення між Учасником_1 і Учасником_2
В даному випадку Учасник_3 отримує статус pending_admission
Учасник_3 має протягом 5-ти днів погодитись "закрити залишок" (залишок складає 800, а Учасник_3 пропонував 2000) і надіслати запит на зміну статуса на pending
Організатор успішно кваліфікує Учасника_3, статус Аварда змінюється на active
...
active
Організатор успішно кваліфікує Учасника_2 і його Авард отримує статус active
Коли всі Awards, які були у статусі pending успішно кваліфіковані, ЦБД перевіряє наявніть Авардів у статусі pending_waiting
Учасник_3 має статус Аварда pending_waiting, його запропонований обсяг повністю не покривається залишком обсягу, що залишився після розподілення між Учасником_1 і Учасником_2
В даному випадку Учасник_3 отримує статус pending_admission
Учасник_3 має протягом 5-ти днів погодитись "закрити залишок" (залишок складає 800, а Учасник_3 пропонував 2000) і надіслати запит на зміну статуса на pending
Організатор успішно кваліфікує Учасника_3, статус Аварда змінюється на active
Результат: 4800 повністю закритий Учасником_1 у розмірі 3000, Учасником_2 у розмірі 1000, Учасником_3 у розмірі 800
Документи обʼєкта кваліфікації (awards.documents)
| documentType | Назва Укр | Назва Анг | Опис | Обовʼязковіть | Публічність | |||||
|---|---|---|---|---|---|---|---|---|---|---|
| rejectionProtocol | Акт про невідповідність | Rejection protocol | Завантажується для кожного Аварда, який не пройшов перевірку документів протягом verificationPeriod Поле terminationReason в даному випадку заповнювати не обовʼязково | Так Для зміни awards.status: verification → unsuccessful | Так | |||||
| auctionProtocol | Протокол аукціону | Auction protocol | Протокол підписується і завантажується для кожного учасника окремо
| Так Для зміни awards.status: pending → active | Так | |||||
| act | Акт про відмову | Refusal act | Завантажується у разі відмови Переможцем підписувати протокол. Документ має бути можливість завантажити у Організатора та у Переможця. Для того, щоб Організатор дискваліфікував учасника, Авард якого перебуває у статусі pending, має бути завантажено хоча б один документ з documentType: act Поле terminationReason має бути обовєязково заповнено для зміни awards.status: pending → unsuccessful | Так Для зміни awards.status: pending → unsuccessful | ||||||
| x_guarantee | Фінансове забезпечення | Financial support | Банківська гарантія для участі в аукціоні, надана на користь гарантованого покупця. При підписанні протоколу може виникнути потреба в завантаженні оновленої банківської гарантії. | Ні | Так | |||||
| digitalSignature | Цифровий підпис | Digital signature | Цифровий підпис | Ні | Так |
Підписання контракту з переможцем (contracts)
...