Page History

...

Документи обʼєкта кваліфікації (awards.documents)

Логіка проведення кваліфікації

...

1. Якщо учасник оновлював свою ставку протягом МА (bids.value < bids.initialValue), то часом розміщення ставки вважається час оновлення ставки протягом МА
2. Якщо учасник НЕ оновлював свою ставку протягом МА (bids.value == bids.initialValue), то часом розміщення ставки вважається bids.dateModified
3. Якщо у декількох Авардів однакове value і ці декілька учасників оновлювали свої ставки протягом МА, то вище в рейтингу має бути той, хто оновлював свою ставку раніше
4. Якщо у декількох Авардів однакове value при цьому один із них НЕ оновлював ставку протягом МА, а інші оновлювали, то вище в рейтингу має бути той, хто НЕ оновлював ставку протягом МА. (бо він розмістив своє value раніше). Його bids.dateModified вважається датою і часом розміщення ставки. Інші учасники своє value розмістили точно пізніше, бо вони оновлювали value протягом МА. Їх порядок має бути згідно часу оновлення їх ставок.

Одразу після завершення МА, ЦБД формує Аварди і розподіляє їх Сформовані Аварди ЦБД розподіляє по статусам pending або pending_waiting за наступною логікою:

...

За результатами автоматичного розподілення, всі Аварди отримують статус pending АБО pending_waiting.

Приклади

Для кожного Аварда, який отримав статус pending ЦБД генерує генерується протокол.

Одночасно з завершенням роботи МА починається qualificationPeriod в процедурі, який триває 20 р.д. а також у Авардів, які отримали статус pending починається awards.verificationPeriod, який триває 6 р.д.

...

• Чи ще триває qualificationPeriod?
  • якщо "так", то для першого у списку Аварду у статусі pending_waiting .відбувається перевірка:
    • Якщо обсяг першого у списку Аварду у статусі pending_waiting дорівнює чи менше нерозподіленого залишку, то цей Авард автоматично змінює свій статус на pending. Приклади тут
• Якщо обсяг першого в порядку Аварду у статусі pending_waiting більше нерозподіленого залишку, то Авард залишається в статусі pending_waiting. Приклади тут

...

Як тільки всі Аварди, що мали статус pending змінили свій статус, Авард, що має статус pending_waiting і знаходиться перший у списку, отримує статус pending_admission (бізнесово називається "Умовний переможець")

Власнику Аварда у статусі pending_admission має бути доступна можливість надіслати запит, в якому вказати quantity. При виконанні запиту ЦБД має перевірити, що quantity, яке вказав Аавард у своєму запит <= нерозподіленому залишку, що дорівнює x_quantityLimit - sum(quantity) всіх Авардів, що отримали статус activeобсяг, на який він погоджується і готовий купити (quantity), але цей обсяг не може бути менше procedure.minimalPart і більше за нерозподілений залишок.

Якщо обсяг поза діапазоном, то ЦБД надсилає валідаційну помилку.

Після цього "Умовний переможець" має надіслати запит на зміну статуса Аварда pending_admission → pending

Організатор кваліфікує цей Авард і змінює його статус на protocol_signedactive, або дискваліфікує і змінює статус на unsuccessful.

Робота з Авардами на цьому завершується.

Приклад 1:

• Організатор вказав Обсяг == 100001000
• Організатор вказав Макс Мін ціну == 12100
• Організатор вказав Мін частку == 200

Прийшло три Учасника, за результатами МА:

Учасник_1:

• Обсяг пропозиції бажаний == 3000200Ціна пропозиції
• Фінальна ставка == 10120

Учасник_2:

• Обсяг пропозиції бажаний == 2000300Ціна пропозиції
• Фінальна ставка == 11110

Учасник_3:

• Обсяг пропозиції бажаний == 1000400
• Ціна пропозиції == 12

Всі три учасники успішно пройшли перевірку документів і отримали статус Аварда waiting

ЦБД розрахувала x_quantityLimit == (3000 + 2000 + 1000) * 0,8 == 4800

• Фінальна ставка== 100

ЦБД ЦБД розподіляє Обсяги пропозицій учасників:

Учасник_1:

4800 1000 - 3000 200 = 1800800

В даному прикладі Обсяг пропозиції Учасника_1 покривається x_quantityLimitвміщається в обсяг продажу

Учасник_1 отримує статус pending

Учасник_2:

1800 - 2000 < 0800 - 300 = 500

В даному прикладі Обсяг пропозиції  пропозиції Учасника_2 НЕ покривається x_quantityLimit, бо після Учасника_1 залишився нерозподілений залишок 1800, а Обсяг пропозиції Учасник_2 - більший і дорівнює 2000вміщається в обсяг продажу

Учасник_2 отримує статус pending_waitingПісля того, як Учасник_2 отримав статус pending_waiting, наступні учасники також отримуть цей статус автоматично, незважаючи на те, що їх обсяг пропозиції покривається нерозподіленим залишком (вони запропонували більшу ціну).

Учасник_3:

500 - 400 = 100

В даному прикладі Обсяг пропозиції Учасника_3 вміщається в обсяг продажу

Учасник_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

кваліфікує віх трьох учасників і за умови успішної кваліфікації, буде реалізовано 200+300+400 = 900

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

Варто звернути увагу, що Організатор вказав "Мін частку" == 200. Відповідно, учасники не мали змогу подати заяву на участь з меншим бажаним обсягом ( <=200 ). В той самий час, учасники не могли подати заяву в якій вказати бажаний обсяг більше Обсягу вказаного організатором ( >= 1000 )

Результат: Організатор реалізував обсяг 900 трьом учасникам. Учасник_1 забрав частку 200, Учасник_2 забрав частку 300 і Учасник_3 забрав 400. У Організатора залишилось 100, які він може реалізувати в іншому аукціоні.

Приклад 2:

• Організатор вказав Обсяг == 1000
• Організатор вказав Мін ціну == 100
• Організатор вказав Мін частку == 200

Прийшло три Учасника, за результатами МА:

Учасник_1:

• Обсяг бажаний == 500
• Фінальна ставка == 120

Учасник_2:

• Обсяг бажаний == 400
• Фінальна ставка == 110

Учасник_3:

• Обсяг бажаний == 800
• Фінальна ставка== 100

ЦБД розподіляє Обсяги пропозицій учасників:

Учасник_1:

1000 - 500 = 500

В даному прикладі Обсяг пропозиції Учасника_1 вміщається в обсяг продажу

Учасник_1 отримує статус pending

Учасник_2:

500 - 400 = 100

В даному прикладі Обсяг пропозиції Учасника_2 вміщається в обсяг продажу

Учасник_2 отримує статус pending

Учасник_3:

100 - 800 < 0

В даному прикладі Обсяг пропозиції Учасника_3 НЕ вміщається в обсяг продажу

Учасник_3 отримує статус pending_waiting

Організатор успішно кваліфікує Учасника_1 і його Авард отримує статус active, в ЦБД автоматично публікується Contract для Учасника_1 у статусі pending

Організатор успішно кваліфікує Учасника_2 і його Авард отримує статус active, в ЦБД автоматично публікується Contract для Учасника_1 у статусі pending

Авард Учасника_3 залишається в статусі pending_waiting та Contract для нього не створюється.

Організатор підписує договір з Учасник_1 і змінює статус Contracts[].status: pending → active

Організатор підписує договір з Учасник_2 і змінює статус Contracts[].status: pending → active

ЦБД перевіряє, що відсутні інші Аварди у статусі pending, а також Аварди у статусі active у яких є повʼязаний contract у статусі pending (Всі учасники, які отримували статус pending вже успішно кваліфіковані та з обома підписано договір):

Залишився тільки Учасник_3 з Авардом у статусі pending_waiting

ЦБД виконує наступну перевірку:

Нерозподілений обсяг >= мін частці, яку вказав Організатор? (Із запропонованої Організатором 1000 Учасник_1 забрав 500 і Учасник_2 забрав 400. Нерозподілений залишок == 100. При публікації процедури Організатор вказав Мін залишок == 200) 

• • 100 >= 200 ? - ні

Тому статус Аварда Учасника_3 змінюється Awards.status: pending_waiting → cancelled

Результат: Запропонований Організатором Обсяг 1000 частково закритий Учасником_1, який забрав 500. Учасник_2 забрав 400. Учасник_3 не забрав нічого

Приклад 3:

• Організатор вказав Обсяг == 1000
• Організатор вказав Мін ціну == 100
• Організатор вказав Мін частку == 200

Прийшло три Учасника, за результатами МА:

Учасник_1:

• Обсяг бажаний == 500
• Фінальна ставка == 120

Учасник_2:

• Обсяг бажаний == 400
• Фінальна ставка == 110

Учасник_3:

• Обсяг бажаний == 800
• Фінальна ставка== 100

ЦБД розподіляє Обсяги пропозицій учасників:

Учасник_1:

1000 - 500 = 500

В даному прикладі Обсяг пропозиції Учасника_1 вміщається в обсяг продажу

Учасник_1 отримує статус pending

Учасник_2:

500 - 400 = 100

В даному прикладі Обсяг пропозиції Учасника_2 вміщається в обсяг продажу

Учасник_2 отримує статус pending

Учасник_3:

100 - 800 < 0

В даному прикладі Обсяг пропозиції Учасника_3 НЕ вміщається в обсяг продажу

Учасник_3 отримує статус pending_waiting

Організатор успішно кваліфікує Учасника_1 і його Авард отримує статус active, в ЦБД автоматично публікується Contract для Учасника_1 у статусі pending

Організатор дискваліфікує Учасника_2 і його Авард отримує статус unsuccessful

В момент дискваліфікації ЦБД перевіряє чи бажаний обсяг Учасника_3 покривається нерозподіленим залишком? (Учасник_3 бажає придбати 800, а нерозподілений залишок == 500, бо із 1000 запропонованого обсягу 500 вже забрав Учасник_1)

В наведеному прикладі, Учасник_3 бажає придбати 800, а нерозподілений залишок == 500.

Тому Авард Учасника_3 залишається в статусі pending_waiting.

Організатор підписує договір з Учасник_1 і змінює статус Contracts[].status: pending → active

ЦБД перевіряє, що відсутні інші Аварди у статусі pending, а також Аварди у статусі active у яких є повʼязаний contract у статусі pending (Всі учасники, які отримували статус pending вже кваліфіковані з підписаними  договорами або дискваліфіковані):

Залишився Учасник_3 з Авардом у статусі pending_waiting

ЦБД виконує наступну перевірку:

Нерозподілений обсяг >= мін частці, яку вказав Організатор? (Із запропонованої Організатором 1000 Учасник_1 забрав 500, а Учасник_2 дискваліфікований. Нерозподілений залишок == 500. При публікації процедури Організатор вказав Мін залишок == 200) 

• • 500 >= 200 ? - так

Тому статус Аварда Учасника_3 змінюється Awards.status: pending_waiting → pending_admission

Організатор успішно кваліфікує Учасника_3 і його Авард отримує статус active, в ЦБД автоматично публікується Contract для Учасника_3 у статусі pending

З Учасник_1 підписується договір та Contracts[].status: pending → active

З Учасник_3 підписується договір та Contracts[].status: pending → active

Результат: Запропонований Організатором Обсяг 1000 Результат: Обсяг 4800 частково закритий Учасником_1, який забрав 3000500. Учасник_2 дискваліфікованийзабрав 400. Учасник_3 не забрав жодного обсягунічого

Приклад 24:

• Організатор вказав Обсяг == 10000
• Організатор вказав Макс ціну == 12

...