...
- Ідентифікатори організації або особи (bids.bidders.identifier)
- Адреса (bids.bidders.address)
- Контактна особа (bids.bidders.contactPoint)
- Цінова пропозиція (bids.value)
- bids.value.amount >= procedure.value.amount. В іншому випадку ЦБД має повертати валідаційну помилку.
- Обсяг (bids.quantity)
- bids.quantity не НЕ може бути менше procedure.minimalPart. Може дорівнювати чи бути більше, але не більше, ніж procedure.items[0].quantity
bids.value - (цінова пропозиція) зазначається із двома знаками після коми
...
| Технічна назва | Бізнесова назва | Перехід з | За умови | Коментар | ||||||
|---|---|---|---|---|---|---|---|---|---|---|
| pending | Очікується протокол | При створенні Аварду АБО pending_waiting АБО pending_admission | Автоматично. Дискваліфіковано Авард у статусі pending протягом qualificationPeriod: pending_waiting → pending АБО Ручна дія. pending_admission → pending: Учасник погодився закрити залишок обсягу | Перехід із pending_waiting: Лише у випадку, якщо Організатор дискваліфікував одного чи більше Переможців, Аварди, що перебувають у статусі pending_waiting автоматично можуть змінити свій статус на pending за умови, що обсяг, який вказано в їх заявці повністю покривається залишком від обсягу, що залишився і не настала дата qualificationPeriod.endDate. Якщо завершився qualificationPeriod і після 20 р.д. Організатор дискваліфіковує переможця, наступний у черзі, який очікує, вже НЕ отримує статус pending (на 21-й день вже не має бути Авардів у статусі pending_waiting, бо визначено одного, хто змінив свій статус на pending_admission, а всі інші змінили свій статус на cancelled)
Організатор вказав обсяг procedure.items.quantity == 1000 Учасник_1 бажає придбати awards.items.quantity == 700 по найбільшій ціні 120 Учасник_2 бажає придбати awards.items.quantity == 200 по ціні 110 Учасник_3 бажає придбати awards.items.quantity == 400 по ціні 100 В запропонований обсяг, що реалізує Організатор потрапляють тільки Учасник_1 і Учасник_2, бо їх сумарна заявка 700+200 = 900. (Учасник_3 не потрапляє в квоту, бо в його заяві quantity == 400, а залишок після Учасник_1 і Учасник_2 тільки 100) В даному прикладі, Учасник_3 отримує статус pending_waiting Після цього Організатор дискваліфіковує Учасника_1 з його пропозицією 700. Учасник_3 автоматично отримує статус pending з своєю пропозицією 400, бо 400 повністю покривається обсягом 1000 (першого дискваліфікували, другий 200, третій 400, 200+400 = 600, що менше, ніж 1000) Приклад2: Організатор вказав procedure.items.quantity == 1000 Учасник_1 запропонував awards.items.quantity == 100 по найбільшій ціні 120 Учасник_2 запропонував awards.items.quantity == 200 по ціні 110 Учасник_3 запропонував awards.items.quantity == 900 по ціні 100 Обсяг 1000 повністю покриває тільки запропоновані обсяги Учасника_1 і Учасника_2. Запропонований Учасником_3 обсяг повнітю не реалізується (він запропонував 900, а після розподілення між першим і другим учасниками, залишилось не розподілено тільки (1000 - 100 - 200) == 700 ) В даному прикладі Учасник_3 отримує статус pending_waiting Після цього Організатор дискваліфіковує Учасника_1 з його пропозицією 100. Учасник_3 НЕ отримує статус pending з своєю пропозицією 900, бо 900 повністю не покривається залишком обсягу (1000 - 200 = 800 - залишок обсягу, а Учасник_3 пропонує 900, що більше, ніж 800) Його статус залишається pending_waiting. P.S.: в майбутньому він отримає статус "Умовний переможець" (pending_admission) і зможе погодитись забрати залишок, який складає 800 із його заявлених 900. Перехід із pending_admission: Учасник в статусі pending_admission має можливість вказати обсяг, який він готовий забрати і змінити статус на pending. Далі відбувається його кваліфікація за логікою кваліфікації інших переможців. | ||||||
| pending_waiting | Очікується рішення | При створенні Аварду | Автоматично. Статус отримують Аварди одразу після завершення роботи модуля аукціону | Статус pending_waiting отримують Аварди, які перебувають у списку результатів Модуля Аукціону за умови, що обсяг, який вони вказали в заявці на участь повністю НЕ покривається обсягом, який вказав Організатор в оголошенні, з причини, що обсяг вже закритий іншими пропозиціями учасників, що запропонували більшу ціну. Приклад 1: Організатор вказав обсяг procedure.items.quantity == 1000 Учасник_1 вказав в заявці awards.items.quantit == 700 по найбільшій ціні 120 Учасник_2 вказав в заявці awards.items.quantit == 200 по ціні 110 Учасник_3 вказав в заявці awards.items.quantit == 200 по ціні 100 Обсяг 1000 повністю покриває тільки запропоновані в заявках Учасника_1 і Учасника_2. Бажаний Учасником_3 обсяг повнітю не реалізується (він запропонував 200, а після розподілення між першим і другим учасниками, залишилось не розподілено тільки (1000 - 700 - 200) == 100 ) В даному прикладі тільки третій учасник отримує статус pending_waiting Приклад 2: Організатор вказав квоту procedure.items.quantity == 1000 Учасник_1 вказав в заявці awards.items.quantit 1000 по найбільшій ціні 100 Учасник_2 вказав в заявці 800 по ціні 110 Учасник_3 вказав в заявці 700 по ціні 100 Обсяг 1000 повністю покриває тільки бажаний обсяг Учасника_1. Бажаний Учасником_2 обсяг повністю не реалізується (він запропонував 800, а після Учасника_1 , залишилось не розподілено (1000 - 1000) == 0 ) В даному прикладі другий і третій учасники отримують статус pending_waiting Організатор не може дискваліфікувати Учасника, що очікує рішення Учасник не має можливості відмовитись від очікування. | ||||||
| pending_admission | Умовний переможець | pending_waiting | Автоматично. Завершився qualificationPeriod.endDate АБО Автоматично. За умови, що всі Awards, що мали статус pending отримали статус active і їх повʼязані Contracts[] також отримали статус active (Організатор успішно кваліфікував всіх Переможців, підписав протоколи і договори, залишилось вирішити питання тільки з залишком запропонованого обсягу, що може бути закритий "умовним переможцем") АБО Автоматично. За умови, що взагалі відсутні Аварди у статусі pending | Статус pending_admission отримує тільки один Award, який знаходиться у статусі pending_waiting і запропонував найбільшу після Переможців ціну за умови, що залишився нерозполіделий залишок. У випадку, коли Організатор успішно кваліфікував всіх переможців (всі Awards у статусі pending набули статусу active і їх повʼязані contracts[] також набули статусу active), не чекаючи 20-го дня після завершення МА, учасник одразу отримує статус pending_admission і отримує можливість погодитись чи відмовитись від залишку обсягу. Це потрібно для того, щоб після успішної кваліфікації переможців, небуло необхідності чекати завершення періоду кваліфікації для погодження умовним переможцем своє право на набуття статуса переможця. В момент отримання Авардом статусу pending_admission, всі інші Аварди, які перебувають у статусі pending_waiting отримують статус cancelled (дискваліфікація Переможців вже неможлива, бо закриті протоколи+договори. Вибор іншого "умовного переможця" не передбачений) В цьому статусі Умовний переможець може:
| ||||||
| active | Переможець. Очікується договір | pending | Ручна дія. Організатор надсилає запит на зміну статуса Awards[].status: pending → active | Після завантаження в Awards[] протоколу Організатор надсилає запит на зміну Awards[].status: pending → active чим підтверджує підписання протоколу. ЦБД автоматично створює до цього аварду contracts[] у статусі pending | ||||||
| cancelled | Учасник не став переможцем | pending_admission АБО pending_waiting | із pending_admission: Ручна дія. Учасник ("Умовний переможець") відмовляється "забрати" нерозподілений залишок і надсилає запит на зміну статуса АБО Автоматично. Якщо протягом awards.admissionPeriod учасник ("Умовний переможець") не надав відповіді із pending_waiting: Автоматично. В момент, коли будь-який Авард набуває статусу pending_admission, всі інші Аварди, які знаходяться у статусі pending_waiting автоматично набувають статус cancelled | Термінальний статус. Після набуття статусу pending_admission "Умовний переможець" має можливість відмовитись забрати залишок обсягу і скасувати свою заявку (змінити статус Аварда з pending_admission на cancelled). Якщо протягом awards.admissionPeriod учасник ("Умовний переможець") не надав відповіді, то ЦБД автоматично змінює статус його Аварда. Після набуття статусу pending_admission "Умовний переможець" всі Аварди, які на цей момент заходились у статусі pending_waiting набувають статус cancelled | ||||||
| unsuccessful | Дискваліфіковано | pending АБО active | Ручна дія. Організатор надсилає запит на зміну award.status: pending → unsuccessful Ручна дія. Організатор надсилає запит на зміну статуса Аварда active → unsuccessful | Термінальний статус. pending → unsuccessful: ЦБД має валідувати, що в Авард завантажено документ з documentType: rejectionProtocol АБО act При зміні статуса з pending → unsuccessful ЦБД має валідувати, що заповнено awards.terminationReason значенням зі словника active → unsuccessful: При зміні статуса з active → unsuccessful Організатору необхідно заповнити поле terminationReason значенням зі словника Обовʼязково завантажити документ з documentType: rejectionProtocol АБО act |
Логіка проведення кваліфікації
Одразу по завершенню роботи Модуля аукціону (далі - МА) генеруються Аварди, кількість яких відповідає кількості Бідів, які на момент початку МА мали статус active.
Всі Аварди створюються в статусі verification. Порядок розміщення Авардів важливий і логіка формування порядку описана тут. Паралельно з цим починається verificationPeriod, який триває 10 р.д.
Протягом цих 10 р. д. Організатор має верифікувати учасника і змінити статус Аварда з verification на waiting, або дискваліфікувати і змінити статус Аварда з verification на rejected (тут валідація на док rejectionProtocol).
- Якщо Організатор верифікував всіх учасників швидше, ніж за 10 р.д. у нього має бути можливість надіслати запит на зміну статуса процедури qualification → active_qualification. При цьому verificationPeriod.endDate в API не змінюється. Якщо на момент зміни статусу процедури наявні Аварди у статусі verification, їх статус автоматично змінюється на waiting.
- Якщо Організатор НЕ верифікував всіх учасників протягом 10 р.д. (завершився verificationPeriod), то ЦБД автоматично змінює статус процедури qualification → active_qualification. При цьому, якщо на момент зміни статусу процедури наявні Аварди у статусі verification, їх статус автоматично змінюється на waiting. (бізнесово називається "Мовчазна згода")
Якщо всі Аварди набули статус waiting ТА rejected і не залишилось Авардів у статусі verification, ЦБД автоматично розраховує параметр BasicSell-multiAwards Брухт\щебінь (декілька переможців) (бере quantity всіх Авардів у статусі waiting, сумує їх і вираховує 80%) (x_quantityLimit не може бути більше за items.quantity. Описано тут)
Після цього ЦБД розподіляє всі Аварди, які перебувають у статусі waiting по статусам pending або pending_waiting за наступною логікою:
- Перевіряється Авард з найменшим value (запропонував наймену ціну), береться його quantity і порівнюється з x_quantityLimit.
- Якщо awards[0].items.quantity <= x_quantityLimit, то Авард отримує статус pending
- Якщо awards[0].items.quantity > x_quantityLimit, то Авард отримує статус pending_waiting
...
Expand title Ситуація, коли немає Переможців Можливо таке, що перший Авард одразу отримає статус pending_waiting. Логічно, що всі наступні Аварди також отримають цей статус.
В такому випадку, перший Авард має одразу отримати статус pending_admission і слідувати логіці цього статуса.
Наприклад,
Організатор вказав procedure.items.quantity == 10 000
Учасник_1 запропонував 10 000 по найменшій ціні 10
Учасник_2 запропонував 500 по ціні 11
Учасник_3 запропонував 500 по ціні 12
Всі три учасники успішно пройшли перевірку документів (awards.status == waiting)
ЦБД розраховує x_quantityLimit == (10000 + 500 + 500) * 0.8 == 8 800
Реалізувати є можливість тільки 8800, а перший Авард пропонував 10000, що є більше, ніж очікується. Він одразу автоматично отримує статус pending_waiting, і всі наступні Аварди також.
Система має перевірити "Всі наявні Аварди у статусі pending_waiting? і якщо так, то
Одразу після цього автоматично перший Авард отримає статус pending_admission і може погодитись на 8800 із своїх 10000, які він ставив спочатку. В момент отримання статусу pending_admission, всі інші Аварди отримують статус cancelled
Якщо він відмовиться ставити 8800 замість 10000, то процедура вважається неуспішною. Наступних Авардів вже не кваліфікують.
- Перевіряється наступний Авард із черги. Береться його quantity і порівнюється з (x_quantityLimit - awards[0].items.quantity).
- Якщо awards[1].items.quantity <= (x_quantityLimit - awards[0].items.quantity) залишку, то Авард отримує статус pending
- Якщо awards[1].items.quantity > (x_quantityLimit - awards[0].items.quantity) залишку, то Авард отримує статус pending_waiting
- Аналогічна перевірка відбувається з кожним наступним Авардом до моменту, коли перший Авард отримує статус pending_waiting. Коли перший із всіх Авардів отримає статус pending_waiting, то всі наступні також автоматично отримують цей статус.
За результатами автоматичного розподілення, всі Аварди, які мали статус waiting отримують новий статус pending АБО pending_waiting.
Залежності від періоду verificationPeriod немає. Організатор може раніше завершення цього періоду провести перевірку документів учасників і запитом змінити статус процедури з qualification → active_qualification.
Після цього ЦБД для кожного Аварда у статусі pending генерує протокол.
Від Організатора очікується
- АБО завантаження підписаного протоколу до Аварду, а також завантаження в документи процедури documentType: x_verificationAct + зміна статуса Аварда на protocol_signed
- АБО завантаження в Авард документа documentType: act і подальша дискваліфікація цього Аварда (зміна статуса Аварда на unsuccessful), а також завантаження в документи процедури documentType: x_verificationAct
Організатор може дискваліфікувати тільки Авард у статусі pending і не може дискваліфікувати Авард у статусі pending_waiting
Авард у статусі protocol_signed може автоматично змінити свій статус на unsuccessful за умови, що повʼязаний contract набув статусу cancelled.
Якщо Організатор дискваліфіковує Авард, ЦБД має виконати перевірку першого у списку Аварду у статусі pending_waiting.
- Якщо обсяг першого в порядку Аварду у статусі pending_waiting дорівнює чи менше нерозподіленого залишку, то цей Авард автоматично змінює свій статус на pending. Приклади тут
- Якщо обсяг першого в порядку Аварду у статусі pending_waiting більше нерозподіленого залишку, то Авард залишається в статусі pending_waiting. Приклади тут
Кваліфікація Авардів продовжується поки не залишиться жодного Аварда у статусі pending.
Всі Аварди, що отримували статус pending мають бути АБО кваліфіковані (отримати статус protocol_signed), АБО дискваліфіковані (отримати статус unsuccessful).
Як тільки всі Аварди, що мали статус pending змінили свій статус, Авард, що має статус pending_waiting і знаходиться перший у списку, отримує статус pending_admission (бізнесово називається "Умовний переможець")
Власнику Аварда у статусі pending_admission має бути доступна можливість надіслати запит, в якому вказати quantity. При виконанні запиту ЦБД має перевірити, що quantity, яке вказав Аавард у своєму запит <= нерозподіленому залишку, що дорівнює x_quantityLimit - sum(quantity) всіх Авардів, що отримали статус active.
Після цього "Умовний переможець" має надіслати запит на зміну статуса Аварда pending_admission → pending
Організатор кваліфікує цей Авард і змінює його статус на protocol_signed, або дискваліфікує і змінює статус на unsuccessful.
Робота з Авардами на цьому завершується.
ПРИКЛАДИ:
...
Документи обʼєкта кваліфікації (awards.documents)
| documentType | Назва Укр | Назва Анг | Опис | Обовʼязковіть | Публічність |
|---|---|---|---|---|---|
| auctionProtocol | Протокол аукціону | Auction protocol | Протокол підписується і завантажується для кожного учасника окремо Завантажити документ auctionProtocol можна тільки в Авард у статусі pending Бізнесово - вантажити необхідно індивідуальний протокол, який генерується, як тільки процедура набуває статусу active_qualification і Авард в статусі pending | Так Для зміни awards.status: pending → active | Так |
| rejectionProtocol | Протокол відхилення | Rejection protocol | Завантажується Організатором у разі відмови Переможцем підписувати протокол або договір. Обовʼязково необхідно заповнити поле terminationReason однією причиною зі словника | Так Для зміни awards.status: pending → unsuccessful Для зміни awards.status: active → unsuccessful | Так |
| act | Акт про відмову | Refusal act | Завантажується Організатором у разі відмови Переможцем підписувати протокол або договір. Обовʼязково необхідно заповнити поле terminationReason однією причиною зі словника | Так Для зміни awards.status: pending → unsuccessful Для зміни awards.status: active → unsuccessful | Так |
| digitalSignature | Цифровий підпис | Digital signature | Цифровий підпис | Ні | Так |
Логіка проведення кваліфікації
Одразу по завершенню роботи Модуля аукціону (далі - МА) генеруються Аварди, кількість яких відповідає кількості Бідів, які на момент початку МА мали статус active.
Порядок розміщення Авардів важливий!
Логіка формування порядку Awards:
За результатами роботи МА (auctionPeriod) пропозиції сортуються від найбільшої ціни до найменшої, а у випадку співпадіння ціни, вище відображається пропозиція розміщена раніше.
Часом розміщення пропозиції вважається час першого розміщення заяви у ЦБД, а, у випадку редагування пропозиції під час періоду прийому пропозицій, час фіксації змін у заяві у ЦБД.
При формуванні порядку Авардів, необхідно дивитись на Awards.value, але якщо value декількох Авардів однакове, необхідно подивитись, чи відрізняється у кожного bid-а bids.initialValue від bids.value:
- Якщо учасник оновлював свою ставку протягом МА (bids.value < bids.initialValue), то часом розміщення ставки вважається час оновлення ставки протягом МА
- Якщо учасник НЕ оновлював свою ставку протягом МА (bids.value == bids.initialValue), то часом розміщення ставки вважається bids.dateModified
- Якщо у декількох Авардів однакове value і ці декілька учасників оновлювали свої ставки протягом МА, то вище в рейтингу має бути той, хто оновлював свою ставку раніше
- Якщо у декількох Авардів однакове value при цьому один із них НЕ оновлював ставку протягом МА, а інші оновлювали, то вище в рейтингу має бути той, хто НЕ оновлював ставку протягом МА. (бо він розмістив своє value раніше). Його bids.dateModified вважається датою і часом розміщення ставки. Інші учасники своє value розмістили точно пізніше, бо вони оновлювали value протягом МА. Їх порядок має бути згідно часу оновлення їх ставок.
Одразу після завершення МА, ЦБД формує Аварди і розподіляє їх по статусам pending або pending_waiting за наступною логікою:
- Перевіряється Авард з найбільшим value (запропонував найбільшу ціну), береться awards[0].items[0].quantity і віднімається від procedure.items[0].quantity.
- Результат різниці двох числе зберігається на беку
- Перевіряється наступний Авард, який запропонував другу за величиною ціну, береться awards[1].items[0].quantity і віднімається від отриманого в попередньому кроці числа
- Якщо результатом другого віднімання є відʼємне число, то цей Авард отримує статус pending_waiting і всі наступні Аварди також отримують цей статус
- Якщо результатом другого віднімання є 0 або додатнє число, то цей Авард отримує статус pending також
- Перевіряється третій Авард і виконуються дії описані в п.3
За результатами автоматичного розподілення, всі Аварди отримують статус pending АБО pending_waiting.
Приклади
Для кожного Аварда, який отримав статус pending ЦБД генерує протокол.
Одночасно з завершенням роботи МА починається qualificationPeriod в процедурі, який триває 20 р.д. а також у Авардів, які отримали статус pending починається awards.verificationPeriod, який триває 6 р.д.
Протягом qualificationPeriod Організатор має кваліфікувати учасника, завантажити підписаний протокол в Авард і змінити Awards[].status: pending → active
АБО
дискваліфікувати учасника, завантажити в Авард документ rejectionProtocol АБО act та змінити Awards[].status: pending → unsuccessful
У випадку, коли завершився qualificationPeriod, але з учасниками не підписано Протокол та\чи Договір, ніяких автоматичних змін у статусі процедури чи Авардів, які мають статус pending НЕ відбувається.
| Note | ||
|---|---|---|
| ||
Зі сторони Майданчика за 24 години до завершення qualificationPeriod, надсилання повідомлення Організатору про завершення періоду кваліфікації. |
Організатор може дискваліфікувати тільки Авард у статусі pending і не може дискваліфікувати Авард у статусі pending_waiting
Якщо Організатор дискваліфікує Авард, ЦБД має виконати перевірку:
- Чи ще триває qualificationPeriod?
- якщо "так", то для першого у списку Аварду у статусі pending_waiting.
- Якщо обсяг першого у списку Аварду у статусі pending_waiting дорівнює чи менше нерозподіленого залишку, то цей Авард автоматично змінює свій статус на pending. Приклади тут
- якщо "так", то для першого у списку Аварду у статусі pending_waiting.
- Якщо обсяг першого в порядку Аварду у статусі 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
Організатор кваліфікує цей Авард і змінює його статус на protocol_signed, або дискваліфікує і змінює статус на unsuccessful.
Робота з Авардами на цьому завершується.
ПРИКЛАДИ:
| Назва в прикладах | шлях в API | Бізнесова назва |
|---|---|---|
| Організатор | - | Замовник |
| Обсяг | procedure.items[0].quantity | Розмір частки річної квоти |
| Макс ціна | procedure.value.amount | Цінова пропозиція (max) |
| Обсяг пропозиції | procedure.bids[*].quantity | Розмір частки квоти в заяві |
| Ціна пропозиції | procedure.bids[*].value | Цінова пропозиція за 1 кВт⋅год |
Приклад 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 і його Авард отримує статус protocol_signed
ЦБД перевіряє, що відсутні інші Аварди у статусі pending і автоматично змінює статус Учасника_2 на pending_admission (умовний переможець. Пропонуємо забрати нерозподілений залишок).
Всі інші Аварди, які на момент отримання Учасником_2 статусу pending_admission перебували у статусі pending_waiting, автоматично отримують статус cancelled
Учасник_2 приймає пропозицію реалізувати 1800 нерозподіленого залишку із 2000, які він пропонував початково.
Учасник_2 надсилає запит і статус його Аварда змінюється на pending
а) Організатор успішно кваліфікує Учасника_2, змінює статус Аварда на protocol_signed
Результат: Обсяг 4800 закритий Учасником_1, який забрав 3000 і Учасником_2, який забрав залишок - 1800. Учасник_3 не забрав жодного обсягу
б)
Організатор дискваліфікує Учасника_2, змінює статус Аварда на unsuccessful
Результат: Обсяг 4800 частково закритий Учасником_1, який забрав 3000. Учасник_2 дискваліфікований. Учасник_3 не забрав жодного обсягу
Приклад 2:
- Організатор вказав Обсяг == 10000
- Організатор вказав Макс ціну == 12
...
Всі інші Аварди, які на момент отримання Учасником_2 статусу pending_admission перебували у статусі pending_waiting, автоматично отримують статус cancelled
Учасник_2 НЕ приймає пропозицію реалізувати 1800 нерозподіленого залишку із 2000, які він пропонував початково.він пропонував початково.
Учасник_2 надсилає запит і статус його Аварда змінюється на pending
а) Організатор успішно кваліфікує Учасника_2, змінює статус Аварда на protocol_signed
Результат: Обсяг 4800 закритий Учасником_1, який забрав 3000 і Учасником_2, який забрав залишок - 1800. Учасник_3 не забрав жодного обсягу
б)
Організатор дискваліфікує Учасника_2, змінює статус Аварда на unsuccessfulУчасник_2 надсилає запит і статус його Аварда змінюється на cancelled
Результат: Обсяг 4800 частково закритий Учасником_1, який забрав 3000. Учасник_2 відмовився закрити залишок, що склада 1800дискваліфікований. Учасник_3 не забрав жодного обсягу. Паралельно з цим відбувається процес підписання Договорів.
Приклад 32:
- Організатор вказав Обсяг == 10000
- Організатор вказав Макс ціну == 12
...
Учасник_2:
1800 - 2000 < 0
В даному прикладі Обсяг пропозиції Учасника_2 НЕ покривається x_quantityLimit, бо після Учасника_1 залишився нерозподілений залишок 1800, а Обсяг пропозиції Учасник_2 - більший і дорівнює 2000
Учасник_2 отримує статус pending_waiting
Після того, як Учасник_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 НЕ покривається x_quantityLimit, бо після Учасника_1 залишився нерозподілений залишок 1800, а Обсяг пропозиції Учасник_2 - більший і дорівнює 2000
Учасник_2 отримує статус pending_waiting
Після того, як Учасник_2 отримав статус pending_waiting, наступні учасники також отримуть цей статус автоматично, незважаючи на те, що їх обсяг пропозиції покривається нерозподіленим залишком (вони запропонували більшу ціну).
Учасник_3 отримує статус pending_waiting
Організатор успішно кваліфікує Учасника_1 і його Авард отримує статус protocol_signed
ЦБД перевіряє, що відсутні інші Аварди у статусі pending і автоматично змінює статус Учасника_2 на pending_admission (умовний переможець. Пропонуємо забрати нерозподілений залишок).
Всі інші Аварди, які на момент отримання Учасником_2 статусу pending_admission перебували у статусі pending_waiting, автоматично отримують статус cancelled
Учасник_2 НЕ приймає пропозицію реалізувати 1800 нерозподіленого залишку із 2000, які він пропонував початково.
Учасник_2 надсилає запит і статус його Аварда змінюється на cancelled
Результат: Обсяг 4800 частково закритий Учасником_31, який запропонував 1000забрав 3000. Учасник_1 і Учасник_2 дискваліфіковані2 відмовився закрити залишок, що склада 1800. Учасник_3 не забрав жодного обсягу. Паралельно з цим відбувається процес підписання Договорів.
Приклад 43:
- Організатор вказав Обсяг == 10000
- Організатор вказав Макс ціну == 12
...
Учасник_2:
- Обсяг пропозиції == 10002000
- Ціна пропозиції == 11
Учасник_3:
- Обсяг пропозиції == 20001000
- Ціна пропозиції == 12
Всі три учасники успішно пройшли перевірку документів і отримали статус Аварда waiting
...
Учасник_1 отримує статус pending
Учасник_2:
1800 - 1000 = 8002000 < 0
В даному прикладі Обсяг пропозиції Учасника_2 НЕ покривається x_quantityLimit, бо після Учасника_1 залишився нерозподілений залишок 1800, а Обсяг пропозиції Учасник_1 - менший, дорівнює 10002 - більший і дорівнює 2000
Учасник_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 і його Авард отримує статус protocol_signed
Організатор успішно кваліфікує Учасника_2 і його Авард отримує статус protocol_signed
Коли всі Awards, які були у статусі pending успішно кваліфіковані, ЦБД перевіряє наявніть Авардів у статусі pending_waiting
Учасник_3 має статус Аварда pending_waiting, його запропонований обсяг повністю не покривається залишком обсягу, що залишився після розподілення між Учасником_1 і Учасником_2
В даному випадку Учасник_3 отримує статус pending_admission
Учасник_3 має протягом 5-ти днів погодитись "закрити залишок" (залишок складає 800, а Учасник_3 пропонував 2000) і надіслати запит на зміну статуса на pending
Організатор успішно кваліфікує Учасника_3, статус Аварда змінюється на protocol_signed
отримує статус 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 дискваліфікованіРезультат: 4800 повністю закритий Учасником_1 у розмірі 3000, Учасником_2 у розмірі 1000, Учасником_3 у розмірі 800. Паралельно з цим відбувається процес підписання Договорів.
У випадку бездіяльності Організатора протягом qualificationPeriod, все одно на 30 р.д. відбувається визначення Умовного переможця, де сума "нерозподіленого залишку" визначається згідно актуального на той момент протоколу.
Приклад 5Приклад 4:
- Організатор вказав Обсяг == 10000
- Організатор вказав Макс ціну == 12
...
Учасник_1:
- Обсяг пропозиції == 60003000
- Ціна пропозиції == 10
Учасник_2:
- Обсяг пропозиції == 40001000
- Ціна пропозиції == 11
Учасник_3:
- Обсяг пропозиції == 2000
- Ціна пропозиції == 12
Всі три Обидва учасники успішно пройшли перевірку документів і отримали статус Аварда waiting
ЦБД розрахувала x_quantityLimit == (6000 3000 + 2000 + 40001000) * 0,8 == 80004800
ЦБД розподіляє Обсяги пропозицій учасників::
Учасник_1:
4800 - 3000 = 1800
В даному прикладі Обсяг пропозиції Учасника_1 покривається x_quantityLimit
Учасник_1 отримує статус pending
Учасник_2:
8000 1800 - 6000 1000 = 2000800
В даному прикладі Обсяг пропозиції пропозиції Учасника_1 2 покривається x_quantityLimit, бо після Учасника_1 залишився нерозподілений залишок 1800, а Обсяг пропозиції Учасник_1 - менший, дорівнює 1000
Учасник_1 2 отримує статус pending
Учасник_23:
2000 - 4000 <0800 - 2000 < 0
В даному прикладі Обсяг пропозиції Учасника_2 3 НЕ покривається x_quantityLimit, бо після Учасника_1 залишився нерозподілений залишок 20001800, частина якого розподілилася на Учасника_2, він забрав 1000, Учаснику_3 залишилось 800, а Обсяг пропозиції Учасника_2 3 - більший, дорівнює 4000
Протягом qualificationPeriod (29 р.д.) Організатор був бездіяльним і НЕ дискваліфікував Учасника_1 і НЕ кваліфікував успішно.
На 30 р.д. визначається "Умовний переможець" і Учасник_2 набуває статусу pending_admission. Йому пропонується закрити нерозподілений залишок, який становить 2000.
Тобто, те, що з Учасником_1 не завершено кваліфікацію, не впливає на визначення обсягу "нерозподіленого залишку"
Учасник_2 погоджується закрити 2000.
Після цього:
Організатор успішно кваліфікує Учасника_1 і його Авард отримує статус protocol_signed, підписують договір
Організатор успішно кваліфікує Учасника_2 і його Авард отримує статус protocol_signed, підписують договір
2000
Учасник_3 отримує статус pending_waiting
Організатор успішно кваліфікує Учасника_1 і його Авард отримує статус protocol_signed
Організатор успішно кваліфікує Учасника_2 і його Авард отримує статус protocol_signed
Коли всі Awards, які були у статусі pending успішно кваліфіковані, ЦБД перевіряє наявніть Авардів у статусі pending_waiting
Учасник_3 має статус Аварда pending_waiting, його запропонований обсяг повністю не покривається залишком обсягу, що залишився після розподілення між Учасником_1 і Учасником_2
В даному випадку Учасник_3 отримує статус pending_admission
Учасник_3 має протягом 5-ти днів погодитись "закрити залишок" (залишок складає 800, а Учасник_3 пропонував 2000) і надіслати запит на зміну статуса на pending
Організатор успішно кваліфікує Учасника_3, статус Аварда змінюється на protocol_signed
Результат: 4800 повністю Результат: 8000 закритий Учасником_1 у розмірі 60003000, Учасником_2 у розмірі 2000
Документи обʼєкта кваліфікації (awards.documents)
...
Обовʼязковіть
...
Завантажується Організатором для кожного Аварда, який не пройшов перевірку документів протягом verificationPeriod
Поле terminationReason в даному випадку заповнювати не обовʼязково
...
Так
Для зміни awards.status: verification → rejected
...
Протокол підписується і завантажується для кожного учасника окремо
| Expand | ||
|---|---|---|
| ||
"Гарантований покупець протягом двох робочих днів з дати оприлюднення протоколу про результати аукціону підписує протоколи про результати аукціону щодо кожного переможця" |
Завантажити документ auctionProtocol можна тільки в Авард у статусі pending
Бізнесово - вантажити необхідно індивідуальний протокол, який генерується, як тільки процедура набуває статусу active_qualification і Авард в статусі pending
...
Так
Для зміни awards.status: pending → protocol_signed
...
Завантажується Організатором у разі відмови Переможцем підписувати протокол або договір.
Для того, щоб Організатор дискваліфікував учасника, Авард якого перебуває у статусі pending або protocol_signed, має бути завантажено хоча б один документ з documentType: act
В поле terminationReason аварду записується причина із довідника
Поле terminationReason має бути обов'язково заповнено для зміни awards.status: pending → unsuccessful чи protocol_signed → unsuccessful
...
Так
Для зміни awards.status: pending → unsuccessful
Так
Для зміни awards.status: protocol_signed → unsuccessful
...
1000, Учасником_3 у розмірі 800. Паралельно з цим відбувається процес підписання Договорів.
У випадку бездіяльності Організатора протягом qualificationPeriod, все одно на 30 р.д. відбувається визначення Умовного переможця, де сума "нерозподіленого залишку" визначається згідно актуального на той момент протоколу.
Приклад 5:
- Організатор вказав Обсяг == 10000
- Організатор вказав Макс ціну == 12
Прийшло три Учасника:
Учасник_1:
- Обсяг пропозиції == 6000
- Ціна пропозиції == 10
Учасник_2:
- Обсяг пропозиції == 4000
- Ціна пропозиції == 11
Обидва учасники успішно пройшли перевірку документів і отримали статус Аварда waiting
ЦБД розрахувала x_quantityLimit == (6000 + 4000) * 0,8 == 8000
ЦБД розподіляє Обсяги пропозицій учасників:
Учасник_1:
8000 - 6000 = 2000
В даному прикладі Обсяг пропозиції Учасника_1 покривається x_quantityLimit
Учасник_1 отримує статус pending
Учасник_2:
2000 - 4000 <0
В даному прикладі Обсяг пропозиції Учасника_2 НЕ покривається x_quantityLimit, бо після Учасника_1 залишився нерозподілений залишок 2000, а Обсяг пропозиції Учасника_2 - більший, дорівнює 4000
Протягом qualificationPeriod (29 р.д.) Організатор був бездіяльним і НЕ дискваліфікував Учасника_1 і НЕ кваліфікував успішно.
На 30 р.д. визначається "Умовний переможець" і Учасник_2 набуває статусу pending_admission. Йому пропонується закрити нерозподілений залишок, який становить 2000.
Тобто, те, що з Учасником_1 не завершено кваліфікацію, не впливає на визначення обсягу "нерозподіленого залишку"
Учасник_2 погоджується закрити 2000.
Після цього:
Організатор успішно кваліфікує Учасника_1 і його Авард отримує статус protocol_signed, підписують договір
Організатор успішно кваліфікує Учасника_2 і його Авард отримує статус protocol_signed, підписують договір
Результат: 8000 закритий Учасником_1 у розмірі 6000, Учасником_2 у розмірі 2000
...
Підписання контракту з переможцем (contracts)
...