...
| rectificationPeriod | Період редагування | Дата та час публікації процедури в ЦБД | rectificationPeriod.startDate + 2 р.д., завершення о 20:00 (завжди припадає на робочий день) | Статус процедури змінюється: active_rectification → active_tendering Редагування полів процедури більше недоступне | Період "Період редагування" починється одразу, як тільки відбувається публікація процедури в ЦБД |
| tenderPeriod | Період подання пропозицій | tenderPeriod.startDate == rectificationPeriod.endDate | о 20:00 в день, що передує дню початку аукціону auctionPeriod.startDate (може припадати на НЕробочий день) | Статус процедури змінюється: active_tendering → active_auction | Період "Прийняття заяв на участь" починається одразу, як тільки завершується "Період редагування", що тривав 2 р.д. |
| questionPeriod | Період запитань | Дата та час публікації процедури в ЦБД | Може припадати на НЕробочий день. о 20:00 за 1 р.д. до початку аукціону | - | |
| enquiryPeriod | Період відповідей | Дата та час публікації процедури в ЦБД | о 20:00 за 1 р.д. до початку аукціону | - | |
| auctionPeriod | Аукціон | Завжди припадає на робочий день. Вказується організатором при публікації процедури. ЦБД приймає тільки auctionPeriod.startDate >= datePublished + к.д. | Момент завершення роботи модуля аукціону | Статус процедури змінюється: active_auction → qualification | auctionPeriod.endDate присутній виключно за умови наявності не менш ніж 2 заяв на участь (bids[].status: active) на момент tenderPeriod.endDate |
| qualificationPeriod | Період кваліфікації | qualificationPeriod.startDate == auctionPeriod.endDate | qualificationPeriod.endDate == qualificationPeriod.startDate + n р.д. о 18:00 | На рівні ЦБД: відсутній На рівні майданчика: за 24 години до завершення, надсилання повідомлення Організатору про завершення періоду кваліфікації. |
**Всі періоди кваліфікації завершуються Організатором аукціону вручну (не автоматична дія), але повинна бути реалізована фіксація порушення строків
Статуси процедури
| draw.io Diagram | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
...
Технічна назва | Бізнесова назва | Перехід з | За умови | Коментар |
|---|---|---|---|---|
| active_rectification | Редагування доступне | момент публікації оголошення в ЦБД | Ручна дія. Заповнені всі обовʼязкові поля для створення процедури в ЦБД | Майданчик Організатора робить запит до ЦБД та передає об'єкт процедури. У разі правильно сформованого об'єкта процедури, ЦБД повертає майданчику id та token створеного об'єкта процедури, процедура набуває статус "Редагування доступне" (active_rectification). |
| active_tendering | Прийняття заяв на участь | active_rectification | Автоматично. Настав момент rectificationPeriod.endDate | Завершився Період редагування (rectificationPeriod), почався період Прийняття заяв на участь (tenderPeriod) |
| active_qualification | Очікується опублікування протоколу | active_auction | Автоматично. Завершилась робота Модуля аукціону (настав момент auctionPeriod.endDate) | Для кожного учасника, що мав bids[].status == active на момент auctionPeriod.startDate, в обʼєкті процедури створюється Award у статусі pending АБО pending_waiting (деталі розподілу в розділі Статуси Awards). Для award у статусі pending відбувається 1 фаза кваліфікації переможця (робота із протоколом) Аварди в статусі unsuccessful свій статус не змінюють. |
| active_awarded | Очікується підписання договору | active_qualification | Ручна дія. Організатор надсилає запит на зміну status: active_qualification → active_awarded | По завершенню роботи із протоколом, Організатор натискає кнопку “Протокол затверджено”, статус процедури змінюється на “Очікується підписання договору” (active_awarded) - 2 фаза кваліфікації переможця, а саме в частині роботи із договором. |
| complete | Аукціон завершено | active_qualification | Ручна дія. Організатор надсилає запит на зміну status: active_awarded → complete | Термінальний статус. При виконанні дії зміни статуса на complete ЦБД перевіряє:
|
| unsuccessful | Аукціон не відбувся | active_tendering active_qualification active_awarded | Автоматично.
| Термінальний статус. |
cancelled | Аукціон скасовано | active_rectification active_tendering active_qualification active_awarded | Ручна дія. Організатору у всіх статусах Процедури, окрім термінальних статусів, доступна опція "Скасування" Процедури. Для скасування процедури, Організатору необхідно:
Після цього, при натисканні кнопки, надсилається запит в ЦБД на скасування. Статус процедури автоматично змінюється → cancelled | Термінальний статус. |
Документи процедури
documentType | Назва Укр | Назва Анг | Опис | Обовʼязковіть для публікації процедури | Публічність |
|---|---|---|---|---|---|
| illustration | Ілюстрації | Illustration | Зображення, що можуть додаватися Організатором до процедури | Так | Так |
| notice | Паспорт торгів | Auction notice | Офіційне повідомлення, що містить деталі аукціону | Ні | Так |
| technicalSpecifications | Копії документів та матеріалів на лот | Technical specificatons | Детальна інформація про лот | Ні | Так |
| evaluationCriteria | Кваліфікаційні вимоги | Evaluation criteria | Вимоги до потенційних учасників аукцціону | Ні | Так |
| contractProforma | Типова форма договору про надання послуги | Contract proforma | Типова форма договору про надання послуги | Ні | Так |
| x_presentation |
Документ НЕ обовʼязковий при публікації процедури.
Документ НЕ обовʼязковий для редагування процедури.
Ні
Скасування аукціону
| Презентація | Presentation | Презентація | Ні | Так | |
| property_doc | Документи на майно | Property documents | Документи що підтверджують право власності організатора на лот, відсутність встановлених законом обтяжень (обмежень), відсутність встановлення законом обтяжень (обмежень) та заборон на відчудження лотів | Так, якщо організатор ФОП (sellingEntity.identifier.scheme - всі значення крім UA-EDR зі схеми ua_identifier) | Так |
| clarifications | Погодження змін до опису лоту. Опис причин редагування. | Clarifications | Документ не потрібно вносити до списку документів при створенні аукціону. Має бути доступний для завантаження в rectificationPeriod | Ні (обов'язковий лише для внесення змін в поля лоту) | Так |
Скасування аукціону
Рішення Організатора про відміну аукціону повинне бути викладене у Рішення Організатора про відміну аукціону повинне бути викладене у формі розпорядчого акта (рішення, наказу, розпорядження, протоколу тощо)
...
| draw.io Diagram | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Перевірка
Технічна назва | Бізнесова назва | Перехід з | За умови | Коментар |
|---|---|---|---|---|
| draft | Чернетка заяви | момент публікації заявки в ЦБД | Ручна дія. Учасник надсилає запит на публікацію Bid-а | Публікація заяви на участь доступна тільки протягом tenderPeriod-а процедури. Мають бути заповнені:
Опублікувати бід можна без документів, але без обовʼязкових документів не буде можливості активувати Біда. Майданчик Учасника робить запит до ЦБД та передає об'єкт заяви на участь. У разі правильно сформованого об'єкта заяви на участь, ЦБД повертає майданчику token для активації заяви на участь, заява на участь набуває статус “Чернетка заяви” (draft). |
| active | Підтверджена заява | draft | Ручна дія. Учасник надсилає запит на зміну статуса Bid-а | Мають бути заповнені обовʼязкові поля:
та обовʼязкові документи Майданчик Учасника надсилає запит на активацію заяви на участь в ЦБД, заява на участь змінює статус на “Підтверджена заява” (active) та вважається опублікованою. |
| inactive | Деактивована заява | draft | Ручна дія. Учасник має можливість:
| У разі редагування оголошення (поля + документи) Організатором, заяви на участь (у статусах draft та/або active) учасників автоматично переходять у статус inactive. Таку заяву на участь можна повторно перевести у статус active. Або анулювати за бажанням учасника. |
| deleted | Видалена заява | active | Ручна дія. Учасник надсилає запит на зміну статуса Bid-а | У разі анулювання заяви на участь учасником вона набуває статус “Видалена заява” (deleted). Скасувати свою заявку на участь є можливість тільки протягом tenderPeriod |
...
Технічна назва | Бізнесова назва | Перехід з | За умови | Коментар |
|---|---|---|---|---|
| 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_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 Організатор не може дискваліфікувати Учасника, що очікує рішення Учасник не має можливості відмовитись від очікування. |
| 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
- Організатор
- Завантаження протоколу (обов'язкова дія - з можливістю замінити протокол);
- Переведення статусу учасника до наступного статусу “Переможець. Очікується договір”;
- Дискваліфікація учасника;
- Учасник:
- Можливість завантажити та замінити протокол (не обов'язкова дія - з можливістю замінити протокол).
- Умови зміни статусу - автоматично присвоюється переможцю під час генерації авардів.
- Очікується рішення
- Технічний ідентифікатор - pending_waiting
- Організатор - відсутній
- Учасник
- Можливість 2-му учаснику відмовитися від очікування (до моменту дискваліфікації 1-го учасника та за умови, що процедура у не термінальному статусі)
- Умови зміни статусу - автоматично присвоюється 2-му (після переможця) учаснику під час генерації авардів
- Переможець. Очікується договір
- Технічний ідентифікатор - active
- Організатор:
- Завантаження договору (з можливістю замінити);
- Дискваліфікація учасника (до завершення аукціону);
- Підтвердження оплати;
- Завершення аукціону.
- Учасник
- Можливість 2-му учаснику відмовитися від очікування до моменту дискваліфікації 1-го переможця.
- Умови зміни статусу - Організатор підтверджує підписання протоколу і award змінює свій статус на active.
- Коментар - Дискваліфікувати переможця можливо до завершення аукціону. Відмовитися від очікування 2-му учаснику можливо до моменту дискваліфікації 1-го учасника або завершення аукціону.
- Дискваліфіковано
- Технічний ідентифікатор - unsuccessful
- Організатор - функціонал відсутній
- Учасник - функціонал відсутній
- Умови зміни статусу - дискваліфікація учасника на будь-якому етапі кваліфікації
- Учасник не став переможцем
- Технічний ідентифікатор - cancelled
- Організатор - функціонал відсутній
- Учасник - функціонал відсутній
- Умови зміни статусу
- 2-й учасник відмовився від очікування
- Статус змінюється лише після завершення аукціону
- Аукціон перейшов в термінальний статус (complete), у зв’язку з чим 2-й учасник не набув статусу переможця (за умови, що 2-й учасник відмовився від очікування).
Підписання контракту з переможцем (contracts)
...
- - функціонал відсутній
- Учасник - функціонал відсутній
- Умови зміни статусу
- 2-й учасник відмовився від очікування
- Статус змінюється лише після завершення аукціону
- Аукціон перейшов в термінальний статус (complete), у зв’язку з чим 2-й учасник не набув статусу переможця (за умови, що 2-й учасник відмовився від очікування).
Підписання контракту з переможцем (contracts)
Статуси Contracts
В даній процедурі логіка contracts[] відрізняється від контрактингу базової процедури там, що contracts є не наслідком успішно підписаного протоколу, а має підписуватись в один період.
Ця зміна спричинена тим, що за умови, якщо Договір НЕ підписано, ЦБД автоматично розподіляє частину обсягу лота, між учасниками з наступними найменшими за величиною ціновими пропозиціями відповідно до рейтингу цінових пропозицій
draw.io Diagram border true diagramName StatusContracts simpleViewer false width links auto tbstyle top lbox true diagramWidth 437 revision 1
| pending | Очікується договір | Момент створення Awards[] у статусі pending | Автоматично. Якщо будь-який Авард набуває статусу protocol_signed, то ЦБД автоматично створює повʼязаний contracts у статусі pending. | Через те, що розподіл нерозподіленого залишку згідно Постанови може відбуватися ПІСЛЯ підписання протоколу, за умови, що дискваліфікували Учасника на етапі підписання Договору, contracts створюються не після того, як Award набув статусу active, а як тільки Award набув статус protocol_signed |
| active | Договір підтверджено | pending | Ручна дія. Організатор завантажує документ contracts[x].documents.documentType: contractSigned і після цього надсилає запит на зміну contracts.status: pending → active | Повʼязаний Авард має бути у статусі protocol_signed. З технічної сторони, договір вважається підписаним і закритим, коли Організатор змінює contracts.status: pending → active + ЦБД автоматично змінює статус повʼязаного Аварду protocol_signed → active. |
| cancelled | Договір скасовано | pending | Автоматично. За умови дискваліфікації Аварда із protocol_signed → unsuccessful | Для того, щоб дискваліфікувати Учасника з причини того, що НЕ підписано договір, необхідно надіслати запит на зміну статуса Аварда protocol_signed → unsuccessful |
Документи контракту (contracts.documents)
Обовʼязковіть | |||||
|---|---|---|---|---|---|
| contractSigned | Підписаний договір | Signed contract | Завантажується для кожного Переможця з ким підписано договір | Так Для зміни contracts.status: pending → active | Так |
| contractAnnexe | Додатки до договору | Contract annexe | Додатки до договору | Ні | Так |
| contractNotice | Повідомлення про договір | Contract notice | Повідомлення про договір | Ні | Так |
| digitalSignature | Цифровий підпис | Digital signature | Цифровий підпис | Ні | Так |
- Очікується договір
- Технічний ідентифікатор - pending
- Організатор
- Завантаження підписаного договору з учасником;
- Підтвердження підписання договору;
- Дискваліфікація учасника.
- Учасник - відсутній
- Умови зміни статусу - автоматично присвоюється переможцю під час генерації авардів.
- Договір підтверджено
- Технічний ідентифікатор - active
- Організатор:
- Завершення аукціону.
- Учасник - відсутній
- Умови зміни статусу - Організатор підтвердив договір.
- Договір скасовано
- Технічний ідентифікатор - cancelled
- Організатор - відсутній
- Учасник - відсутній
- Умови зміни статусу - Організатор аукціону дискваліфікував учасник через неможливість підписання договору або неотримання оплати.
Опис періодів
...
Період підготовки
Статус процедури - поза системою
...
- Публікація оголошення
...
Період редагування
Статус процедури - Прийняття заяв на участь
...