...
| Технічна назва | Бізнесова назва | Перехід з | За умови | Коментар | ||||||
|---|---|---|---|---|---|---|---|---|---|---|
| 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 (Організатор успішно кваліфікував всіх Переможців, підписав протоколи і договори, залишилось вирішити питання тільки з залишком запропонованого обсягу, що може бути закритий "умовним переможцем") Три умови: 2. Відсутні Аварди у статусі pending 3. Відсутні Contracts у статусі pending Тоді ЦБД визначає Аварда, який набуває статус pending_admission | Статус 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 Організатору необхідно заповнити поле terminationReason значенням зі словника Обовʼязково завантажити документ з documentType: rejectionProtocol АБО act |
...