...
Функціонал ролей в рамках періодів
Timeline процедури
| draw.io Diagram | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
...
Документи заяви на участь (bids.documents)
documentType | Назва Українською | Назва Англійською | Опис | Обовʼязковіть для активації bid-а |
|---|
Необхідно передбачити можливість Учаснику додавати і замінювати документи в bids[x].documents, коли бід знаходиться у статусі active. Після завершення роботи МА у Учасника такожм має бути можливість додавати і замінювати документи протягом періоду Процедури qualification та active_qualification.
Кваліфікація
За результатами періоду аукціону (auctionPeriod) пропозиції сортуються від меншої ціни до більшої, а у випадку співпадіння ціни, вище відображається пропозиція розміщена раніше. Часом розміщення пропозиції вважається час першого розміщення заяви у ЦБД, а, у випадку редагування пропозиції під час періоду прийому пропозицій, час фіксації змін у заяві у ЦБД. По завершенню аукціону, процедура переходить у статус qualification - фазу перевірки документів учасників. ЦБД генерує award'и для N учасників у статусі verification. award'и формуються для всіх учасників, відповідно до поданих кількості заяв на участь. Валідною ставкою вважається та, що рівна або менша за значення value.amount.
Періоди Awards
...
В момент набуття Авардом статуса pending
...
Період формується в Аварді з моменту набуття Авардом статусу pending
Якщо Авард був у статусі pending і отримав signingPeriod, то після зміни статуса на інший (protocol_signed, active OR unsuccessful) період залишається незмінним.
Аварди в інших статусах цей період не отримують.
...
В момент набуття Авардом статуса pending_admission
...
На рівні ЦБД: Статус аварда автоматично змінюється з pending_admission → cancelled
...
Статуси Awards
...
Автоматично.
По завершенню аукціону, процедура переходить у статус qualification ("Перевірка документів"). ЦБД генерує Awards[] у статусі verification для всіх учасників.
Публічність | |||||
|---|---|---|---|---|---|
| eligibilityDocuments | Договір про приєднання об'єкта електроенергетики | Eligibility document | Договір з оператором електричних мереж включно з технічними умовами до нього. Інформація щодо технічних параметрів (характеристик) установки зберігання енергії (встановлена потужність, ємність, інші параметри) | Ні | Так |
| digitalSignature | Цифровий підпис | Digital signature | Цифровий підпис | Ні | Так |
Необхідно передбачити можливість Учаснику додавати і замінювати документи в bids[x].documents, коли бід знаходиться у статусі active. Після завершення роботи МА у Учасника такожм має бути можливість додавати і замінювати документи протягом періоду Процедури qualification та active_qualification.
Кваліфікація
За результатами періоду аукціону
...
(auctionPeriod) пропозиції сортуються від меншої ціни до більшої, а у випадку співпадіння ціни, вище відображається пропозиція розміщена раніше.
...
Часом розміщення пропозиції вважається час першого розміщення заяви у ЦБД, а, у випадку редагування пропозиції під час періоду прийому пропозицій, час фіксації змін у заяві у ЦБД. По завершенню аукціону, процедура переходить у статус qualification - фазу перевірки документів учасників. ЦБД генерує award'и для N учасників у статусі verification. award'и формуються для всіх учасників, відповідно до поданих кількості заяв на участь. Валідною ставкою вважається та, що рівна або менша за значення value.amount.
Періоди Awards
Технічна назва | Бізнесова назва | Дата початку | Дата завершення | Результат завершення | Коментар |
|---|---|---|---|---|---|
| awards.signingPeriod | Період підписання протоколу та договору | В момент набуття Авардом статуса pending | signingPeriod.endDate == signingPeriod.startDate + 15 р.д. | На рівні ЦБД: відсутній | Період формується в Аварді з моменту набуття Авардом статусу pending Якщо Авард був у статусі pending і отримав signingPeriod, то після зміни статуса на інший (protocol_signed, active OR unsuccessful) період залишається незмінним. Аварди в інших статусах цей період не отримують. |
| awards.admissionPeriod | Період прийняття рішення щодо набуття статусу переможця | В момент набуття Авардом статуса pending_admission | admissionPeriod.endDate == admissionPeriod.startDate + 5 р.д. | На рівні ЦБД: Статус аварда автоматично змінюється з pending_admission → cancelled | Період формується для Авардів у статусі pending_admission і продовжує відображатись в Аварді після зміни його статуса на будь-який інший. |
Статуси Awards
| draw.io Diagram | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Технічна назва | Бізнесова назва | Перехід з | За умови | Коментар |
|---|
При формуванні порядку Авардів, необхідно дивитись на Awards.value, але якщо value декількох Авардів однакове, необхідно подивитись, чи відрізняється у кожного bid-а bids.initialValue від bids.value:
1) Якщо учасник оновлював свою ставку протягом МА (bids.value < bids.initialValue), то часом розміщення ставки вважається час оновлення ставки протягом МА
2) Якщо учасник НЕ оновлював свою ставку протягом МА (bids.value == bids.initialValue), то часом розміщення ставки вважається bids.dateModified
3) Якщо у декількох Авардів однакове value і ці декілька учасників оновлювали свої ставки протягом МА, то вище в рейтингу має бути той, хто оновлював свою ставку раніше
4) Якщо у декількох Авардів однакове value при цьому один із них НЕ оновлював ставку протягом МА, а інші оновлювали, то вище в рейтингу має бути той, хто НЕ оновлював ставку протягом МА. (бо він розмістив своє value раніше). Його bids.dateModified вважається датою і часом розміщення ставки. Інші учасники своє value розмістили точно пізніше, бо вони оновлювали value протягом МА. Їх порядок має бути згідно часу оновлення їх ставок.
За умови НЕ успішної перевірки документів, Організатор змінює статус Awards[].status: verification → unsuccessful (обовʼязково попередньо завантажує та може замінити документ awards.documents: documentType: rejectionProtocol)
Організатор має можливість завантажити та заміни в Процедурі документ documentType:x_verificationAct
Ручна дія.
У Організатора має бути можливість змінювати Awards.status: verification → waiting. Обовʼязкові документи для цієї зміни статуса відсутні.
Автоматично.
Якщо на момент verificationPeriod.endDate залишились Awards у статусі verification, то ЦБД змінює їх статус на waiting
Подальша робота з Авардом відбувається із статуса waiting.
Частину Авардів в статус waiting може перевести Організатор, а у випадку, коли ЦБД автоматично змінила Awards.status: verification → waiting , він є проміжковим і після цього ЦБД також автоматично змінить статус на pending або pending_waiting
За умови успішної превірки документів, Організатор змінює статус Awards[].status: verification → waiting (обовʼязкових документів немає)| pending | Очікується протокол | waiting АБО pending_waiting АБО pending_admission | Автоматично. Завершився verificationPeriod.endDate: waiting → pending АБО Автоматично. Дискваліфіковано Авард у статусі pending АБО protocol_signed протягом qualificationPeriod: pending_waiting → pending АБО Ручна дія. pending_admission → pending: Учасник погодився закрити залишок обсягу | Перехід із waiting: Статус pending отримують Аварди, які перебувають перші у списку результатів Модуля Аукціону і які успішно пройшли етап перевірки документів (award.status <> unsuccessful) за умови, що обсяг, який вони запропонували повністю покривається розрахованим значенням x_quantityLimit Організатор має можливість:
Учасник має можливість завантажити та замінити протокол awards.document: documentType: auctionProtocol Перехід із pending_waiting: Лише у випадку, якщо Організатор дискваліфікував одного чи більше Переможців, Аварди, що перебувають у статусі pending_waiting автоматино можуть змінити свій статус на pending за умови, що обсяг, який вони запропонували повністю покривається залишком від обсягу, що залишився і не настала дата qualificationPeriod.endDate. Якщо завершився qualificationPeriod і після 29 р.д. Організатор дискваліфіковує переможця, наступний у черзі, який очікує вже НЕ отримує статус pending (на 30-й день вже не має бути Авардів у статусі pending_waiting, бо визначено одного, хто змінив свій статус на pending_admission, а всі інші змінили свій статус на cancelled) Приклад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 Після цього Організатор дискваліфіковує Учасника_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
Ручна дія.
ЦБД має валідувати, що в Авард завантажено документ з documentType: auctionProtocol
відбувається його кваліфікація за логікою кваліфікації інших переможців. | ||||
| 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 |
В даному прикладі другий і третій учасники отримують статус pending_waiting
Організатор не може дискваліфікувати Учасника, що очікує рішення
Учасник не має можливості відмовитись від очікування.
Автоматично.
Завершився qualificationPeriod.endDate
АБО
Автоматично.
За умови, що всі Awards, що мали статус pending отримали статус active
(Організатор успішно кваліфікував всіх Переможців, залишилось вирішити питання тільки з залишком запропонованого обсягу, що може бути закритий "умовним переможцем")
АБО
Автоматично.
За умови, що взагалі відсутні Аварди у статусі pending
Статус pending_admission отримує тільки один Award, який знаходиться у статусі pending_waiting і запропонував найменшу після Переможців ціну.
Згідно Постанови "Учасник, що набуває статусу умовного переможця, визначається на 30-й робочий день після завершення аукціону",
але у випадку, коли Організатор успішно кваліфікував всіх переможців (всі Awards у статусі pending набули статусу active), не чекаючи 30-го дня після завершення МА, учасник одразу отримує статус pending_admission і отримує можливість погодитись чи відмовитись від залишку обсягу.
Це потрібно для того, щоб після успішної кваліфікації переможців, небуло необхідності чекати завершення періоду кваліфікації для погодження умовним переможцем своє право на набуття статуса переможця.
В момент отримання Авардом статусу pending_admission, всі інші Аварди, які перебувають у статусі pending_waiting отримують статус cancelled
(дискваліфікація Переможців вже неможлива, бо закриті протоколи+договори. Вибор іншого "умовного переможця" не передбачений в нормативці)
В цьому статусі Умовний переможець може:
- вказати обсяг, на який учасник погоджується (обсяг має дорівнювати або бути меншим за нерозподілений залишок) і
- надіслати запит на зміну Award.status: pending_admission → pending (підтвердити набуття статусу переможця)
- Відмовитися від набуття статусу переможця - надіслати запит на Award.status: pending_admidssion → cancelled
- Бездіяльність умовного переможця протягом awards.admissionPeriod (принцип мовчазної відмови), автоматична зміна Award.status: pending_admidssion → cancelled
Автоматично.
Якщо повʼязаний contracts набув статуса active
Термінальний статус.
Якщо змінився contracts.status: pending → active, це означає, що
завантажено Підписаний договір (contracts.documents.documentType: contractSigned)
Це потрібно для того, щоб за умови дискваліфікації Переможця на етапі підписання Договору, ЦБД зробила перевірку "qualificationPeriod.endDate вже пройшов?":
- якщо НІ, то відпрацьовує логіка визначення переходу наступного Аварда із pending_waiting → pending і підписання протоколу і договору з наступним учасником.
- якщо ТАК, то наступних у черзі Авардів не кваліфікуємо
pending_admission
АБО
pending_waiting
із pending_admission:
Ручна дія.
Учасник ("Умовний переможець") відмовляється "закрити" нерозподілений залишок і надсилає запит на зміну статуса
АБО
Автоматично.
Якщо протягом awards.admissionPeriod учасник ("Умовний переможець") не надав відповіді
із pending_waiting:
Автоматично.
В момент, коли будь-який Авард набуває статусу pending_admission, всі інші Аварди, які знаходяться у статусі pending_waiting автоматично набувають статус cancelled
повністю покриває тільки запропонований обсяг Учасника_1. Запропонований Учасником_2 обсяг повністю не реалізується (він запропонував 2 000, а після Учасника_1 , залишилось не розподілено тільки (4 800 - 3 000) == 1800 ) В даному прикладі другий і третій учасники отримують статус pending_waiting Організатор не може дискваліфікувати Учасника, що очікує рішення Учасник не має можливості відмовитись від очікування. | ||||
| active | Договір підписано | protocol_signed | Автоматично. Якщо повʼязаний contracts набув статуса active | Термінальний статус. Якщо змінився contracts.status: pending → active, це означає, що завантажено Підписаний договір (contracts.documents.documentType: contractSigned) Це потрібно для того, щоб за умови дискваліфікації Переможця на етапі підписання Договору, ЦБД зробила перевірку "qualificationPeriod.endDate вже пройшов?":
|
| 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 | Дискваліфіковано | verification АБО pending АБО protocol_signed | Ручна дія. Організатор надсилає запит на зміну award.status:verification → unsuccessful Організатор надсилає запит на зміну award.status: pending → unsuccessful Ручна дія. Організатор надсилає запит на зміну статуса Аварда protocol_signed → unsuccessful | Термінальний статус. verification → unsuccessful: завантажується документ rejectionProtocol для кожного Аварда, який не пройшов перевірку документів протягом verificationPeriod Поле terminationReason в даному випадку заповнювати не обовʼязково pending → unsuccessful: ЦБД має валідувати, що в Авард завантажено документ з documentType: act При зміні статуса з pending → unsuccessful ЦБД має валідувати, що заповнено awards.terminationReason значенням зі словника protocol_signed → unsuccessful: При зміні статуса з protocol_signed → unsuccessful Організатору необхідно заповнити поле terminationReason значенням зі словника Обовʼязково хавантажити документ act "про відмову" в Авард. |
Логіка проведення кваліфікації+Приклади
Документи обʼєкта кваліфікації (awards.documents)
Обовʼязковіть | |||||
|---|---|---|---|---|---|
| rejectionProtocol | Акт про невідповідність | Rejection protocol | Завантажується для кожного Аварда, який не пройшов перевірку документів протягом verificationPeriod Поле terminationReason в даному випадку заповнювати не обовʼязково | Так Для зміни awards.status: verification → unsuccessful | Так |
| auctionProtocol | Протокол аукціону | Auction protocol | Протокол підписується і завантажується для кожного учасника окремо | Так Для зміни awards.status: pending → protocol_signed | Так |
| act | Акт про відмову | Refusal act | Завантажується у разі відмови Переможцем підписувати протокол або договір. Документ має бути можливість завантажити у Організатора та у Переможця. Для того, щоб Організатор дискваліфікував учасника, Авард якого перебуває у статусі pending або protocol_signed, має бути завантажено хоча б один документ з documentType: act Поле terminationReason має бути обов'язково заповнено для зміни awards.status: pending → unsuccessful чи protocol_signed → unsuccessful | Так Для зміни awards.status: pending → unsuccessful Так Для зміни awards.status: protocol_signed → unsuccessful | Так |
| x_guarantee | Фінансове забезпечення | Financial support | Банківська гарантія для участі в аукціоні, надана на користь гарантованого покупця. При підписанні протоколу може виникнути потреба в завантаженні оновленої банківської гарантії. | Ні | Так |
| digitalSignature | Цифровий підпис | Digital signature | Цифровий підпис | Ні | Так |
Термінальний статус.
Після набуття статусу pending_admission "Умовний переможець" має можливість відмовитись від запропонованого обсягу і скасувати свою заявку (змінити статус Аварда з pending_admission на cancelled).
Якщо протягом awards.admissionPeriod учасник ("Умовний переможець") не надав відповіді, то ЦБД автоматично змінює статус його Аварда.
Після набуття статусу pending_admission "Умовний переможець" всі Аварди, які на цей момент заходились у статусі pending_waiting набувають статус cancelled
verification
АБО
pending
АБО
protocol_signed
Ручна дія.
Організатор надсилає запит на зміну award.status:verification → unsuccessful
Організатор надсилає запит на зміну award.status: pending → unsuccessful
Ручна дія.
Організатор надсилає запит на зміну статуса Аварда protocol_signed → unsuccessful
Термінальний статус.
verification → unsuccessful:
завантажується документ rejectionProtocol для кожного Аварда, який не пройшов перевірку документів протягом verificationPeriod
Поле terminationReason в даному випадку заповнювати не обовʼязково
pending → unsuccessful:
ЦБД має валідувати, що в Авард завантажено документ з documentType: act
При зміні статуса з pending → unsuccessful ЦБД має валідувати, що заповнено awards.terminationReason значенням зі словника
protocol_signed → unsuccessful:
При зміні статуса з protocol_signed → unsuccessful Організатору необхідно заповнити поле terminationReason значенням зі словника
Обовʼязково хавантажити документ act "про відмову" в Авард.- Очікується протокол
- Технічний ідентифікатор - pending
- Організатор
- Завантаження протоколу (обов'язкова дія - з можливістю замінити протокол);
- Переведення статусу учасника до наступного статусу “Переможець. Очікується договір”;
- Дискваліфікація учасника;
- Учасник:
- Можливість завантажити та замінити протокол (не обов'язкова дія - з можливістю замінити протокол).
- Умови зміни статусу - автоматично присвоюється переможцю під час генерації авардів.
- Очікується рішення
- Технічний ідентифікатор - pending_waiting
- Організатор - відсутній
- Учасник
- Можливість 2-му учаснику відмовитися від очікування (до моменту дискваліфікації 1-го учасника та за умови, що процедура у не термінальному статусі)
- Умови зміни статусу - автоматично присвоюється 2-му (після переможця) учаснику під час генерації авардів
- Переможець. Очікується договір
- Технічний ідентифікатор - active
- Організатор:
- Завантаження договору (з можливістю замінити);
- Дискваліфікація учасника (до завершення аукціону);
- Підтвердження оплати;
- Завершення аукціону.
- Учасник
- Можливість 2-му учаснику відмовитися від очікування до моменту дискваліфікації 1-го переможця.
- Умови зміни статусу - Організатор підтверджує підписання протоколу і award змінює свій статус на active.
- Коментар - Дискваліфікувати переможця можливо до завершення аукціону. Відмовитися від очікування 2-му учаснику можливо до моменту дискваліфікації 1-го учасника або завершення аукціону.
- Дискваліфіковано
- Технічний ідентифікатор - unsuccessful
- Організатор - функціонал відсутній
- Учасник - функціонал відсутній
- Умови зміни статусу - дискваліфікація учасника на будь-якому етапі кваліфікації
- Учасник не став переможцем
- Технічний ідентифікатор - cancelled
- Організатор - функціонал відсутній
- Учасник - функціонал відсутній
- Умови зміни статусу
- 2-й учасник відмовився від очікування
- Статус змінюється лише після завершення аукціону
- Аукціон перейшов в термінальний статус (complete), у зв’язку з чим 2-й учасник не набув статусу переможця (за умови, що 2-й учасник відмовився від очікування).
Підписання контракту з переможцем (contracts)
Статуси
...
Contracts
- Очікується договір
- Технічний ідентифікатор - pending
- Організатор
- Завантаження підписаного договору з учасником;
- Підтвердження підписання договору;
- Дискваліфікація учасника.
- Учасник - відсутній
- Умови зміни статусу - автоматично присвоюється переможцю під час генерації авардів.
- Договір підтверджено
- Технічний ідентифікатор - active
- Організатор:
- Завершення аукціону.
- Учасник - відсутній
- Умови зміни статусу - Організатор підтвердив договір.
- Договір скасовано
- Технічний ідентифікатор - cancelled
- Організатор - відсутній
- Учасник - відсутній
- Умови зміни статусу - Організатор аукціону дискваліфікував учасник через неможливість підписання договору або неотримання оплати.
...