...
| documentType | Назва Укр | Назва Анг | Опис | Обовʼязковіть для публікації процедури | Публічність | |||||
|---|---|---|---|---|---|---|---|---|---|---|
| illustration | Ілюстрації | Illustration | Зображення, що можуть додаватися Організатором до процедури | Ні | Так | |||||
| technicalSpecifications | Технічні специфікації | Technical specifications | Технічні параметри об’єкта електроенергетики | Так | Так | |||||
| evaluationCriteria | Кваліфікаційні вимоги | Evaluation criteria | Перелік документів, необхідних для участі в аукціоні, та вимоги до їх оформлення | Так | Так | |||||
| contractProforma | Типова форма договору про надання послуги | Contract proforma | Типова форма договору про надання послуги | Так | Так | |||||
| x_lotInfoEN | Документ, що містить оголошення англійською мовою | Announcements in English | Документ, що містить оголошення англійською мовою | Так | Так | |||||
| x_verificationAct | Акт про результати перевірки документів учасників | Verification act | Загальний акт про результати перевірки документів усіх учасників, в якому зазначається перелік учасників, що успішно пройшли перевірку, і тих, що втратили статус учасника | Ні * * має бути можливість завантажити документ коли procedure.status: qualification або active_qualification
| Так | |||||
| clarifications | Погодження змін до опису лоту. Опис причин редагування. | Clarifications | Документ НЕ обовʼязковий при публікації процедури. Документ НЕ обовʼязковий для редагування процедури. | Ні | Так | |||||
| digitalSignature | Цифровий підпис | Digital signature | Цифровий підпис | Ні | Так |
Рішення Організатора про відміну аукціону повинне бути викладене у формі розпорядчого акта (рішення, наказу, розпорядження, протоколу тощо)
Скасувати процедуру є можливість у всіх статусах, окрім Auction
У разі відміни аукціону ЦБД автоматично присвоює аукціону статус “аукціон не відбувся”.
Документи скасування процедури (cancellations.documents)
| documentType | Назва Укр | Назва Анг | Опис | Обовʼязковіть для скасування процедури | Публічність |
|---|---|---|---|---|---|
| cancellationDetails | Причини скасування | Cancellation details | Інформація щодо причин скасування аукціону | Так | Так |
| digitalSignature | Цифровий підпис | Digital signature | Цифровий підпис | Ні | Так |
Публікація заяви на участь
Періоди у заяви на участь відсутні.
Публікація заяви на участь
Періоди у заяви на участь відсутні.
Можливість подавати заяви на участь є тільки протягом періоду процедури tenderPeriod
Для публікації біда, обовʼязково мають бути заповнені поля: bids.bidders.identifier, bids.bidders.address, bids.bidders.contactPoint, bids.value та bids.quantity
| Expand | ||
|---|---|---|
| ||
Заява про участь в аукціоні повинна містити повне та скорочене (за наявності) найменування юридичної особи, прізвище (за наявності), власне ім’я, по батькові (за наявності) фізичної особи - підприємця, закриту пропозицію, що складається з величини потужності та цінової пропозиції |
bids.quantity не може бути більше procedure.items[0].quantity. Може дорівнювати чи бути менше.
bids.value - (цінова пропозиція) зазначається в євроцентах за 1 кВт·год (євроцентів/кВт·год) із двома знаками після коми
bids.value.amount <= procedure.value.amount. В іншому випадку ЦБД має повертати валідаційну помилку.
У рамках одного аукціону щодо одного і того самого об’єкта лота учасник не може подати більше однієї заяви про участь в аукціоні (не може бути два біда у статусі active з однаковим identifier.id)
До закінчення tenderPeriod учасники мають право анулювати заяви про участь в аукціоні або внести до них зміни, зокрема шляхом завантаження оновлених редакцій доданих до заяви документів.
У разі коли в момент закінчення кінцевого строку подання заяв про участь в аукціоні подано менше двох заяв, ЦБД автоматично присвоює аукціону статус “аукціон не відбувся” (unsuccessful)Можливість подавати заяви на участь є тільки протягом періоду процедури tenderPeriod
Статуси заяви на участь
| draw.io Diagram | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
...
| documentType | Назва Укр | Назва Анг | Опис | Обовʼязковіть для скасування процедуриактивації bid-а | Публічність |
|---|---|---|---|---|---|
| x_guarantee | Фінансове забезпечення | Financial support | Банківська гарантія для участі в аукціоні, надана на користь гарантованого покупця | Так | Так |
| х_ultimateBeneficiaryInfo | Інформація про кінцевого бенефіціарного власника | Ultimate beneficiary information | Інформація про кінцевого бенефіціарного власника. У разі коли особа не має кінцевого бенефіціарного власника, зазначається інформація про відсутність кінцевого бенефіціарного власника та причина його відсутності | Так | Так |
| x_governingBodyInfo | Інформація про органи управління | Governing bodies information | Копії документів, що містять інформацію про органи управління учасника, який має намір взяти участь в аукціоні, та їх персональний склад (статут, протоколи, накази, інші документи, що містять інформацію про органи управління та їх персональний склад) | Ні | Так |
| x_relatedParties | Інформація про пов'язаних осіб | Related parties information | Інформацію про осіб, пов’язаних із учасником, який має намір взяти участь в аукціоні, відносинами щодо здійснення контролю | Ні | Так |
| x_generationType | Довідка із зазначенням виду альтернативного джерела енергії | Generation type certificate | У разі участі в технологічно нейтральному аукціоніУ разі участі в технологічно нейтральному аукціоні довідку в довільній формі, підписану уповноваженою особою суб’єкта господарювання, із зазначенням виду альтернативного джерела енергії, щодо якого він має намір набути право на підтримку | Ні | Так |
| eligibilityDocuments | Інформація щодо технічних параметрів (характеристик) установки | Eligibility document | Інформація щодо технічних параметрів (характеристик) установки зберігання енергії (встановлена потужність, ємність, інші параметри) | Ні | Так |
| digitalSignature | Цифровий підпис | Digital signature | Цифровий підпис | Ні | Так |
...
| Технічна назва | Бізнесова назва | Перехід з | За умови | Коментар | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 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 | Очікується протокол | waiting АБО pending_waiting АБО pending_admission | Автоматично. waiting → pending: Завершився verificationPeriod.endDate АБО Автоматично. pending_waiting → pending: Дискваліфіковано Авард у статусі pending протягом qualificationPeriod АБО Ручна дія. pending_admission → pending: Учасник погодився закрити залишок обсягу | Перехід із waiting: Статус pending отримують Аварди, які перебувають перші у списку результатів Модуля Аукціону і які успішно пройшли етап перевірки документів (award.status <> unsuccessful) за умови, що обсяг, який вони запропонували повністю покривається розрахованим значенням x_quantityLimit Організатор має можливість:
Учасник має можливість завантажити та замінити протокол auctionProtocol (не обов'язкова дія) Перехід із pending_waiting: Лише у випадку, якщо Організатор дискваліфікував одного чи більше Переможців, Аварди, що перебувають у статусі pending_waiting автоматино можуть змінити свій статус на pending за умови, що обсяг, який вони запропонували повністю покривається залишком від обсягу, що залишивсязалишком від обсягу, що залишився і не настала дата qualificationPeriod.endDate. Якщо завершився qualificationPeriod і після 29 р.д. Організатор дискваліфіковує переможця, наступний у черзі, який очікує (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_waiting | Ручна дія. Учасник (умовний переможець) надсилає запит на зміну статуса Автоматично. В момент, коли будь-який Авард набуває статусу pending_admission, всі інші Аварди, які знаходяться у статусі pending_waiting автоматично набувають статус cancelled | Після набуття статусу pending_admission "Умовний переможець" має можливість відмовитись від запропонованого обсягу і скасувати свою заявку (змінити статус Аварда з pending_admission на cancelled) Після набуття статусу pending_admission "Умовний переможець" всі Аварди, які на цей момент заходились у статусі pending_waiting набувають статус cancelled | |||||||||||
| unsuccessful | Дискваліфіковано | pending АБО verification | Ручна дія. Організатор надсилає запит на зміну award.status: pending → unsuccessful ЦБД має валідувати, що в Авард завантажено документ з documentType: act |
...
x_additionalInformation - не обовʼязкове поле (зараз обовʼязкове, хоча я не бачу в Постанові нічого про те, що треба ОБОВʼЯЗКОВО надавати "Додаткові відомості". Навпаки: "Оголошення про проведення аукціону може містити інші відомості, необхідні для його проведення")
bankAccounts - переробити під bankAccounts (basicSell.BankAccountsByType) з двума accountType (payment, other). bankAccount з accountType == payment ОБОВʼЯЗКОВИЙ (банківські реквізити оператора авторизованого електронного майданчика для сплати переможцем винагороди.)
bids.qualified - прибрати із біда. не несе взагалі ніякої логіки
minNumberOfQualifiedBids - мінімально допустиме значення == 2. За умови, якщо прийшло менше двох учасників, на момент tenderPeriod.endDate - проедура автоматино набуває статусу unsuccessful