Посилання:
Мета створення процедури та нормативні засади
Відповідно до Постанови від 27 грудня 2019 р. № 1175 КМУ "Про запровадження конкурентних умов стимулювання виробництва електричної енергії з альтернативних джерел енергії".
Визначається механізм процедури підготовки та проведення аукціону з розподілу квоти підтримки для стимулювання виробників електричної енергії з альтернативних джерел енергії з використанням електронної торгової системи, порядок функціонування електронної торгової системи та визначення переможця за результатами проведення аукціону, порядок укладення та публікації договору купівлі-продажу в електронній торговій системі, розмір та порядок сплати винагороди операторам авторизованих електронних майданчиків та інші питання проведення аукціонів.
З метою проведення аукціонів з розподілу квот підтримки для електричної енергії з альтернативних джерел енергії в межах системи ProZorro.Sale реалізовано sellingMethod: timber-multiAwards. Така процедура надає змогу Замовнику здійснити продаж квот підтримки для електричної енергії, в рамках аукціону, необмеженій кількості учасників, а учаснику придбати частину заявленої квоти підтримки для електричної енергії у лоті Замовником, саме ту кількість обсягу, що потрібна учаснику.
Загальна інформація про роботу процедури
Критерієм вибору переможця є цінова пропозиція, що складається з ціни за 1 кВт*годину та обсяг генерації у кВт, за умови відповідності пропозиції учасника кваліфікаційним критеріям, визначеним Замовником аукціону.
Кваліфікація відбувається після завершення аукціону, попередньої кваліфікації немає.
За наявності 2-х та більше заяв на участь за результатами періоду подання пропозицій (tenderPeriod), процедура переходить у період аукціону (auctionPeriod). У протилежному випадку аукціон визнається таким, що не відбувся. Статус аукціону автоматично змінюється на unsuccessful.
За результатами аукціону пропозиції учасників сортуються по ціні та кваліфікуються ті учасники, яким вистачило запропонованого Замовником аукціону обсягу квоти. У випадку дискваліфікації одного з учасників, кваліфікація переходить до наступного учасника в черзі.
Особливості процедури
- На етапі публікації Процедури:
- В одній процедурі може бути тільки один item (ДОДАТИ ВАЛІДАЦІЮ)
- На етапі подання заяв на участь:
- учасник може подати одну або більше заяв на участь в одному аукціоні, відповідно до кількості об'єктів електроенергетики наявних у нього.
- Аукціон:
- для запуску МА на момент tenderPeriod.endDate має бути мінімум два bids[] у статусі active (minNumberOfQualifiedBids==2). Якщо менше двух статус процедури змінюється на unsuccessful
- "сліпий" аукціон (детально описано в ТЗ "сліпого" МА) (ДОДАТИ ПОСИЛАННЯ)
- Кваліфікація:
- кількість переможців необмежена
- наявність учасників, що очікують
- наявність умовного переможця
Опис класифікаторів
Під час публікації процедури ЦБД автоматично генерує значення для (ДОДАТИ ЦЕ В ФУНКЦІОНАЛ)
itmes[0].classification.scheme == CAV
- itmes[0].classification.id == 09300000-2
Основний класифікатор (код) - 09300000-2 - Електрична, теплова, сонячна та атомна енергія. Посиланняна словник
При публікації процедури, Організатор може вказати (не обовʼязково) Додатковий класифікатор "Вид джерела енергії" (одне значення з словника)
Посилання на legalName endpoint
legalName endpoint (ЗАМІНИТИ + ПРОВАЛІДУВАТИ)
Timeline процедури
Періоди процедури
| Технічна назва | Бізнесова назва | Дата початку | Дата завершення | Результат завершення | Коментар |
|---|---|---|---|---|---|
| rectificationPeriod | Період редагування | Дата та час публікації процедури в ЦБД | rectificationPeriod.startDate + 2 р.д., завершення о 20:00 (завжди припадає на робочий день) | Статус процедури змінюється: active_rectification → active_tendering Редагування полів процедури більше недоступне | ст.28 "Прийом заяв про участь в аукціоні починається з моменту розміщення оголошення про проведення аукціону..." |
| tenderPeriod | Період подання пропозицій | tenderPeriod.startDate == rectificationPeriod.endDate | о 20:00 в день, що передує дню початку аукціону auctionPeriod.startDate (може припадати на НЕробочий день) | Статус процедури змінюється: active_tendering → active_auction | |
| questionPeriod | Період запитань | Дата та час публікації процедури в ЦБД | Може припадати на НЕробочий день. о 20:00 за 1 р.д. до початку аукціону | - | |
| enquiryPeriod | Період відповідей | Дата та час публікації процедури в ЦБД | о 20:00 за 1 р.д. до початку аукціону | - | |
| auctionPeriod | Аукціон | Завжди припадає на робочий день. Вказується організатором при публікації процедури. ЦБД приймає тільки auctionPeriod.startDate >= datePublished + 30 к.д. | Момент завершення роботи модуля аукціону | Статус процедури змінюється: active_auction → qualification | Період auctionPeriod присутній виключно за умови наявності не менш ніж 2 заяв на участь (bids[].status: active) в період подання пропозицій (tenderPeriod) |
| verificationPeriod | Період перевірки документів | verificationPeriod.startDate == auctionPeriod.endDate | verificationPeriod.endDate == verificationPeriod.startDate + 10 р.д. о 18:00 | Статус процедури змінюється: qualification → active_qualification | УТОЧНИТИ + Ручна дія. Організатор натискає кнопку "Перевірку документів завершено", на ЦБД надсилається запит на зміну статуса Процедури. verificationPeriod.endDate не змінюється в API |
| qualificationPeriod | Період кваліфікації | qualificationPeriod.startDate == auctionPeriod.endDate | qualificationPeriod.endDate == qualificationPeriod.startDate + 30 р.д. о 18:00 | На рівні ЦБД: відсутній На рівні майданчика: за 24 години до завершення, надсилання повідомлення Організатору про завершення періоду кваліфікації. | зараз має назву waitingPeriod |
Статуси процедури
| Технічна назва | Бізнесова назва | Перехід з | За умови | Коментар |
|---|---|---|---|---|
| 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 свій статус не змінюють. В момент переходу процедури у статус active_qualification, ЦБД розраховує значення поля x_quantityLimit - це сума awards.value всіх Авардів, які на момент зміни статуса процедури на active_qualification отримали Awards.status in 'pending,pending_waiting' |
| complete | Аукціон завершено | active_qualification | Ручна дія. Присутній хоча б один Contract у статусі active | Термінальний статус. Після завершення роботи із договором, Організатор аукціону натискає на кнопку “Завершити аукціон”. зміни статусу процедури на “Аукціон завершено”. |
| unsuccessful | Аукціон не відбувся | active_tendering qualification active_qualification | Автоматично.
| Термінальний статус. |
| cancelled | Аукціон скасовано | active_rectification active_tendering qualification active_qualification | Ручна дія. Організатору у всіх статусах Процедури, окрім procedure.status: active_auction, доступна опція "Скасування" Процедури. Для скасування процедури, Організатору необхідно:
Після цього, при натисканні кнопки, надсилається запит на скасування. Статус процедури автоматично змінюється → cancelled | Термінальний статус. Для зміни статусу процедури на “Аукціон відмінено” Замовник зобов’язаний в особистому кабінеті натиснути кнопку “Скасувати аукціон”, завантажити документ з причинами скасування та обрати одну з нижчезазначених причин скасування, після чого майданчик Замовника передає запит до ЦБД на зміну статусу процедури на “Аукціон відмінено”. |
Типи і опис документів
Документи процедури
| 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 | Цифровий підпис | Ні | Так |
Документи скасування процедури (cancellations.documents)
| documentType | Назва Укр | Назва Анг | Опис | Обовʼязковіть для скасування процедури | Публічність |
|---|---|---|---|---|---|
| cancellationDetails | Причини скасування | Cancellation details | Інформація щодо причин скасування аукціону | Так | Так |
| digitalSignature | Цифровий підпис | Digital signature | Цифровий підпис | Ні | Так |
Документи заяви на участь (bids.documents)
| documentType | Назва Укр | Назва Анг | Опис | Обовʼязковіть для скасування процедури | Публічність |
|---|---|---|---|---|---|
| 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 | Цифровий підпис | Ні | Так |
Документи обʼєкта кваліфікації (awards.documents)
| documentType | Назва Укр | Назва Анг | Опис | Обовʼязковіть | Публічність |
|---|---|---|---|---|---|
| rejectionProtocol | Акт про невідповідність | Rejection protocol | Завантажується для кожного Аварда, який не пройшов перевірку документів протягом verificationPeriod Поле terminationReason в даному випадку заповнювати не обовʼязково | Так Для зміни awards.status: verification → unsuccessful | Так |
| auctionProtocol | Протокол аукціону | Auction protocol | Протокол підписується і завантажується для кожного учасника окремо | Так Для зміни awards.status: pending → active | Так |
| act | Акт про відмову | Refusal act | Завантажується у разі відмови Переможцем підписувати протокол. Документ має бути можливість завантажити у Організатора та у Переможця. Для того, щоб Організатор дискваліфікував учасника, Авард якого перебуває у статусі pending, має бути завантажено хоча б один документ з documentType: act Поле terminationReason має бути обовєязково заповнено для зміни awards.status: pending → unsuccessful | Так Для зміни awards.status: pending → unsuccessful | |
| x_guarantee | Фінансове забезпечення | Financial support | Банківська гарантія для участі в аукціоні, надана на користь гарантованого покупця. При підписанні протоколу може виникнути потреба в завантаженні оновленої банківської гарантії. | Ні | Так |
| digitalSignature | Цифровий підпис | Digital signature | Цифровий підпис | Ні | Так |
Кваліфікація
Періоди Awards
| Технічна назва | Бізнесова назва | Дата початку | Дата завершення | Результат завершення | Коментар |
|---|---|---|---|---|---|
| awards.signingPeriod | Період підписання протоколу та договору | verificationPeriod.endDate | signingPeriod.endDate == signingPeriod.startDate + 15 р.д. | На рівні ЦБД: відсутній | Період формується в Аварді з моменту набуття Авардом статусу pending Якщо Авард був у статусі pending і отримав signingPeriod, то після зміни статуса на інший (active OR unsuccessful) період залишається в endpoint Аварди в інших статусах цей період не отримують. |
| awards.admissionPeriod | Період прийняття рішення щодо набуття статусу переможця | qualificationPeriod.endDate | admissionPeriod.endDate == admissionPeriod.startDate + 5 р.д. | На рівні ЦБД: відсутній | Період формується для Авардів у статусі pending_admission |
Статуси Awards
| Технічна назва | Бізнесова назва | Перехід з | За умови | Коментар |
|---|---|---|---|---|
| verification | Перевірка документів | Момент auctionPeriod.endDate створюються Awards | Автоматично. По завершенню аукціону, процедура переходить у статус qualification (Перевірка документів). ЦБД генерує Awards[] у статусі verification для всіх учасників, відповідно до поданих кількості заяв на участь. Валідною ставкою вважається та, що рівна або менша за значення value.amount. | За результатами роботи МА (auctionPeriod) пропозиції сортуються від меншої ціни до більшої, а у випадку співпадіння ціни, вище відображається пропозиція розміщена раніше. Часом розміщення пропозиції вважається час першого розміщення заяви у ЦБД, а, у випадку редагування пропозиції під час періоду прийому пропозицій, час фіксації змін у заяві у ЦБД. При формуванні порядку Авардів, необхідно дивитись на 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 | Автоматично. Завершився verificationPeriod.endDate | Статус pending отримують Аварди, які перебувають перші у списку результатів Модуля Аукціону і які успішно пройшли етап перевірки документів (award.status <> unsuccessful) за умови, що обсяг, який вони запропонували повністю покривається розрахованим значенням x_quantityLimit Організатор має можливість:
Учасник має можливість завантажити та замінити протокол 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 повністю покриває тільки запропонований обсяг Учасника_1. Запропонований Учасником_2 обсяг повнітю не реалізується (він запропонував 2 000, а після Учасника_1 , залишилось не розподілено тільки (4 800 - 3 000) == 1800 ) В даному прикладі другий і третій учасники отримують статус pending_waiting Організатор не може дискваліфікувати Учасника, що очікує рішення Учасник не має можливості відмовитись від очікування. |
| pending_admission | Підтвердження набуття статусу переможця | pending_waiting | Автоматично. Завершився qualificationPeriod.endDate АБО Автоматично. Всі Awards, що мали статус pending отримали статус active (Організатор успішно кваліфікував всіх Переможців) | Статус pending_admission отримує тільки один Award, який знаходиться у статусі pending_waiting і запропонував найменшу після Переможців ціну. В цьому статусі Умовний переможець може:
|
| active | Очікується договір | pending | Ручна дія. Організатор надсилає запит на зміну award.status: pending → active ЦБД має валідувати, що в Авард завантажено документ з documentType: auctionProtocol | |
| cancelled | Учасник не став переможцем | pending_admission | Ручна дія. | |
| unsuccessful | Дискваліфіковано | pending | Ручна дія. Організатор надсилає запит на зміну award.status: pending → unsuccessful ЦБД має валідувати, що в Авард завантажено документ з documentType: act |
Логіка проведення кваліфікації
- Є можливість при публікації Процедури задати Класифікатор для кожного айтема (сонячна, вітер і т.д.). Класифікатори можуть бути різні у різних айтемів в одній процедурі.
- Ціна максимальна вказується один раз для всієї процедури, хоча в нормативці "У разі оголошення технологічно нейтрального аукціону зазначаються розміри максимальної цінової пропозиції для кожного виду альтернативного джерела енергії"
- Це схоже на те, що ціну треба виносити на рівень айтему і вказувати для кожного айтема окремо - ВІДПОВІДЬ: НЕ МОЖЕ БУТИ В ОДНІЙ ПРОЦЕДУРІ ДВА АЙТЕМА З РІЗНИМИ КЛАСИФІКАТОРАМИ. Тому треба додати валідацію на публікацю такого.
- При публікації Біда неможливо передати Класифікатор. Але після публікації до кожного Біда автоматично додається Класифікатор, значення якого копіюється із procedure.items[0].additionalClassification
- Ціна максимальна вказується один раз для всієї процедури, хоча в нормативці "У разі оголошення технологічно нейтрального аукціону зазначаються розміри максимальної цінової пропозиції для кожного виду альтернативного джерела енергії"