...
Технічна назва | Бізнесова назва | Перехід з | За умови | Коментар | ||||||
---|---|---|---|---|---|---|---|---|---|---|
active_rectification | Редагування доступне | момент публікації оголошення в ЦБД | Ручна дія. Заповнені всі обовʼязкові поля для створення процедури в ЦБД | Майданчик Організатора робить запит до ЦБД та передає об'єкт процедури. У разі правильно сформованого об'єкта процедури, ЦБД повертає майданчику token створеного об'єкта процедури, процедура набуває статус "Редагування доступне" (active_rectification). | ||||||
active_tendering | Прийняття заяв на участь | active_rectification | Автоматично. Настав момент rectificationPeriod.endDate | Завершився Період редагування (rectificationPeriod), почався період Прийняття заяв на участь (tenderPeriod) | ||||||
active_auction | Аукціон | active_tendering | Автоматично. Завершився період прийому заяв на участь. В момент auctionPeriod.startDate | У визначену дату та час ЦБД, за наявності необхідної кількості заяв (перевірка кількості поданих заяв відбувається на рівні ЦБД, для проведення аукціону необхідно не менше 2 заяв на участь), змінює статус процедури з “Прийняття заяв на участь” (active_tendering) на “Аукціон” (active_auction). | ||||||
qualification | Перевірка документів учасників | active_auction | Автоматично. Завершився auctionPeriod | по кожному учаснику, що мав bids[].status == active на момент auctionPeriod.startDate, в обʼєкті процедури створюється Award у статусі verification За умови успішної превірки документів, Організатор змінює статус Awards[].status: verification → waiting (обовʼязкових документів немає) За умови НЕ успішної перевірки документів, Організатор змінює статус Awards[].status: verification → unsuccessful (обовʼязково документ awards.documents: documentType: rejectionProtocol) | ||||||
active_qualification | Очікується оприлюднення протоколу та підписання договору | qualification | Автоматично. Завершився verificationPeriod, що тривав 10 р.д
+ Ручна дія. Організатор натискає кнопку "Перевірку документів завершено", на ЦБД надсилається запит на зміну статуса Процедури. verificationPeriod.endDate не змінюється в API. Всі Відбувається перевірка і всі Awards, що знаходяться у статусі verification набувають статусу waiting | Аварди, що на момент зміни статуса процедури перебували у статусі waiting АБО verification автоматично змінюють статус на pending АБО pending_waiting (деталі в розділі Статуси Awards). Awards[].status: [waiting,verification] → pending OR pending_waiting Аварди в статусі unsuccessful свій статус не змінюють.
| ||||||
complete | Аукціон завершено | active_qualification | Ручна дія. Присутній хоча б один Contract у статусі active | Термінальний статус. Після завершення роботи із договором, Організатор аукціону натискає на кнопку “Завершити аукціон”. зміни статусу процедури на “Аукціон завершено”. | ||||||
unsuccessful | Аукціон не відбувся | active_tendering qualification active_qualification | Автоматично.
| Термінальний статус. | ||||||
cancelled | Аукціон скасовано | active_rectification active_tendering qualification active_qualification | Ручна дія. Організатору у всіх статусах Процедури, окрім procedure.status: active_auction, доступна опція "Скасування" Процедури. Для скасування процедури, Організатору необхідно:
Після цього, при натисканні кнопки, надсилається запит на скасування. Статус процедури автоматично змінюється → cancelled | Термінальний статус. Для зміни статусу процедури на “Аукціон відмінено” Замовник зобов’язаний в особистому кабінеті натиснути кнопку “Скасувати аукціон”, завантажити документ з причинами скасування та обрати одну з нижчезазначених причин скасування, після чого майданчик Замовника передає запит до ЦБД на зміну статусу процедури на “Аукціон відмінено”. |
...
Технічна назва | Бізнесова назва | Перехід з | За умови | Коментар | ||||||
---|---|---|---|---|---|---|---|---|---|---|
verification | Перевірка документів | Момент auctionPeriod.endDate створюються Awards | Автоматично. По завершенню аукціону, процедура переходить у статус qualification (Перевірка документів). ЦБД генерує Awards[] у статусі verification для всіх учасників, відповідно до поданих кількості заяв на участь. Валідною ставкою вважається та, що рівна або менша за значення value.amount. |
Часом розміщення пропозиції вважається час першого розміщення заяви у ЦБД, а, у випадку редагування пропозиції під час періоду прийому пропозицій, час фіксації змін у заяві у ЦБД. При формуванні порядку Авардів, необхідно дивитись на 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 протягом МА. Їх порядок має бути згідно часу оновлення їх ставок. Організатор має можливість завантажити та заміни в Аварді документ 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 | Очікується протокол | waitingwaiting АБО 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_admission "Умовний переможець" має можливість відмовитись від запропонованого обсягу і скасувати свою заявку (змінити статус Аварда з pending_admission на cancelled) | ||||||
unsuccessful | Дискваліфіковано | pending АБО verification | Ручна дія. Організатор надсилає запит на зміну award.status: pending → unsuccessful ЦБД має валідувати, що в Авард завантажено документ з documentType: act |
Логіка проведення кваліфікації
...
Одразу по завершенню роботи Модуля аукціону (далі - МА) генеруються Аварди, кількість яких відповідає кількості Бідів, які на момент початку МА мали статус active.
Всі Аварди створюються в статусі verification. Порядок розміщення Авардів важливий і логіка формування порядку описана тут. Паралельно з цим починається verificationPeriod, який триває 10 р.д.
Протягом цих 10 р. д. Організатор має Верифікувати учасника і змінити статус Аварда з verification на waiting, або дискваліфікувати і змінити статус Аварда з verification на unsuccessful (тут валідація на док rejectionProtocol).
- Якщо Організатор верифікував всіх учасників швидше, ніж за 10 р.д. у нього має бути можливість надіслати запит на зміну статуса процедури qualification → active_qualification. При цьому verificationPeriod.endDate в API не змінюється. Якщо на момент зміни статусу процедури наявні Аварди у статусі verification, їх статус автоматично змінюється на waiting.
- Якщо Організатор НЕ верифікував всіх учасників протягом 10 р.д. (завершився verificationPeriod), то ЦБД автоматично змінює статус процедури qualification → active_qualification. При цьому, якщо на момент зміни статусу процедури наявні Аварди у статусі verification, їх статус автоматично змінюється на waiting. (бізнесово називається "Мовчазна згода")
Якщо всі Аварди набули статус waiting ТА unsuccessful і не залишилось Авардів у статусі verification, ЦБД автоматично розраховує параметр x_quantityLimit (бере quantity всіх Авардів у статусі waiting, сумує їх і вираховує 80%)
Після цього ЦБД розподіляє всі Аварди, які перебувають у статусі waiting по статусам pending або pending_waiting за наступною логікою:
- Перевіряється Авард з найменшим value (запропонував наймену ціну), береться його quantity і порівнюється з x_quantityLimit.
- Якщо awards[0].items.quantity <= x_quantityLimit, то Авард отримує статус pending
- Якщо awards[0].items.quantity > x_quantityLimit, то Авард отримує статус pending_waiting
Anchor exception_1 exception_1
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_admission і може погодитись на 8800 із своїх 10000, які він ставив спочатку.
Якщо він відмовиться ставити 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 немає. Організатор може раніше завершення цього періоду провести перевірку документів учасників.
Після цього ЦБД для кожного Аварда у статусі pending генерує протокол.
Від Організатора очікується
- АБО завантаження підписаного протоколу до Аварду, а також завантаження в документи процедури documentType: x_verificationAct + зміна статуса Аварда на active
- АБО завантаження в Авард документа documentType: act і подальша дискваліфікація цього Аварда (зміна статуса Аварда на unsuccessful), а також завантаження в документи процедури documentType: x_verificationAct
Організатор може дискваліфікувати тільки Авард у статусі pending і не може дискваліфікувати Авард у статусі pending_waiting
Якщо Організатор дискваліфіковує Авард, ЦБД має виконати перевірку першого у списку Аварду у статусі pending_waiting.
- Якщо обсяг першого в порядку Аварду у статусі pending_waiting дорівнює чи менше нерозподіленого залишку, то цей Авард автоматично змінює свій статус на pending. Приклади тут
...
- Це схоже на те, що ціну треба виносити на рівень айтему і вказувати для кожного айтема окремо - ВІДПОВІДЬ: НЕ МОЖЕ БУТИ В ОДНІЙ ПРОЦЕДУРІ ДВА АЙТЕМА З РІЗНИМИ КЛАСИФІКАТОРАМИ. Тому треба додати валідацію на публікацю такого.
...