Посилання:
Голосарій
Аукціон закритого типу - аукціон, в якому з моменту активації модуля аукціону до моменту завершення аукціону електронною торговою системою не відображається (не публікується) жодна інформація, що подана учасниками в заявах про участь або доданих до них документах, а також цінові пропозиції, які були змінені протягом часу, відведеного на оновлення таких пропозицій; Роль спостерігача на МА передбачена і протягом перебігу МА відображає в полі інформації тільки текст "Учасники подають закриті цінові пропозиції". Після завершення МА, інформація щодо ставок відкривається і Спотерігач може побачити Учасників і їх ставки.
Під час проведення МА:
Після завершення МА:
Величина потужності - встановлена потужність, щодо якої учасник має намір набути право на підтримку;
Оголошення - процедура продажу річної квоти
Організатор - замовник аукціону (в Нормативці фігурує як "Гарантований покупець")
Переможець - учасник, який набуває право на підтримку у виробництві електричної енергії за результатами аукціону. Переможців може бути необмежена кількість, яка сумарно їх пропозиція закривається обʼємом квоти, яку виставив Організатор.
Умовний переможець - учасник, що йде наступним за останнім у рейтингу переможцем відповідно до протоколу про результати аукціону і якому надається можливість набути право на підтримку в обсязі частини величини потужності;
Учасник - суб’єкт господарювання, який має намір взяти участь в аукціоні, пройшов процедуру реєстрації в електронній торговій системі, отримав відповідне підтвердження про реєстрацію для участі в аукціоні та індивідуальний код учасника відповідно до Регламенту роботи електронної торгової системи;
Цінова пропозиція - ціна продажу 1 кВт·год електричної енергії, яка декларується учасником та інформація про яку подається в електронній торговій системі до закінчення кінцевого строку подання заяв про участь в аукціоні або в ході проведення аукціону шляхом оновлення такої цінової пропозиції.
Максимальний розмір цінової пропозиції учасника - найбільша ціна у євроцентах за 1 кВт·год, яку може вказати учасник в своїй заявці на участь. Вказує Організатор при публікації оголошення,чим обмежує максимально можливу ставку.
Мета створення процедури та нормативні засади
Відповідно до Постанови від 27 грудня 2019 р. № 1175 КМУ "Про запровадження конкурентних умов стимулювання виробництва електричної енергії з альтернативних джерел енергії".
Визначається механізм процедури підготовки та проведення аукціону з розподілу квоти підтримки для стимулювання виробників електричної енергії з альтернативних джерел енергії з використанням електронної торгової системи, порядок функціонування електронної торгової системи та визначення переможця за результатами проведення аукціону, порядок укладення та публікації договору купівлі-продажу в електронній торговій системі, розмір та порядок сплати винагороди операторам авторизованих електронних майданчиків та інші питання проведення аукціонів.
З метою проведення аукціонів з розподілу квот підтримки для електричної енергії з альтернативних джерел енергії в межах системи ProZorro.Sale реалізовано sellingMethod: timber-multiAwards. Така процедура надає змогу Замовнику здійснити продаж квот підтримки для електричної енергії, в рамках аукціону, необмеженій кількості учасників, а учаснику придбати частину заявленої квоти підтримки для електричної енергії у лоті Замовником, саме ту кількість обсягу, що потрібна учаснику.
Загальна інформація про роботу процедури
Критерієм вибору переможця є цінова пропозиція, що складається з ціни за 1 кВт*годину та обсяг генерації у кВт, за умови відповідності пропозиції учасника кваліфікаційним критеріям, визначеним Замовником аукціону.
Кваліфікація відбувається після завершення аукціону, попередньої кваліфікації немає.
За наявності 2-х та більше заяв на участь за результатами періоду подання пропозицій (tenderPeriod), процедура переходить у період аукціону (auctionPeriod). У протилежному випадку аукціон визнається таким, що не відбувся. Статус аукціону автоматично змінюється на unsuccessful.
За результатами аукціону пропозиції учасників сортуються по ціні та кваліфікуються ті учасники, яким вистачило запропонованого Замовником аукціону обсягу квоти. У випадку дискваліфікації одного з учасників, кваліфікація переходить до наступного учасника в черзі.
Особливості процедури
- На етапі публікації Процедури:
- в одній процедурі може бути тільки один item
- На етапі подання заяв на участь:
- учасник може подати одну або більше заяв на участь в одному аукціоні, відповідно до кількості об'єктів електроенергетики наявних у нього. (Один Учасник може мати декілька різних обʼєктів енергетики, які можуть приймати участь в одному аукціоні окремими заявками)
- Аукціон:
- для запуску МА на момент tenderPeriod.endDate має бути мінімум два bids[] у статусі active (minNumberOfQualifiedBids==2). Якщо менше двух статус процедури змінюється на unsuccessful
- "сліпий" аукціон (детально описано в ТЗ "renewables auction")
- Кваліфікація:
- кількість переможців необмежена
- наявність необмеженої кількості учасників, що очікують
- наявність одного умовного переможця
Опис класифікаторів
Під час публікації процедури ЦБД автоматично генерує значення для
itmes[0].classification.scheme == CAV
- itmes[0].classification.id == 09300000-2
Основний класифікатор (код) - 09300000-2 - Електрична, теплова, сонячна та атомна енергія. Посилання на словник
При публікації процедури, Організатор може вказати (не обовʼязково) Додатковий класифікатор "Вид джерела енергії" (одне значення з словника)
Посилання на legalName endpoint
Timeline процедури
Публікація процедури
Створення оголошення
При публікації оголошення про проведення аукціону, Організатором аукціону необхідно заповнити обовʼязкові поля:
- Інформація про Замовника (sellingEntity)
- Ідентифікатори Замовника аукціону (Код ЄДРПОУ або ІПН або паспорт) (identifier)
- Місцезнаходження Замовника аукціону (повна адреса) (address)
- Інформація про контактну особу (contactPoint)
- Номер лоту (lotId)
- Повну назву Аукціону (заголовок) (title)
- Опис аукціону (description)
- Вимоги до оформлення документів (x_documentRequirements)
- Максимальний розмір цінової пропозиції учасника (value)
- Інформація про лот, що пропонується на аукціон, із зазначенням його розміру (items.quantity, items.description)
- items.unit.code (ЗАПОВНЮЄТЬСЯ ЦБД АВТОМАТИЧНО == KWT із словника )
- items.classification == CAV 09300000-2 (ЗАПОВНЮЄТЬСЯ ЦБД АВТОМАТИЧНО)
- items.regions[] - новий параметр, який необхідно додати до items. Параметр НЕ обовʼязковий до заповнення. Організатор може вказати "Області, у яких розподіляється обсяг лота"
- Документи
- Дата та час проведення аукціону (auctionPeriod.startDate)
Повний перелік полів в Swagger
Редагування оголошення
Протягом періоду редагування (rectifiactionPeriod) Організатор аукціону має право самостійно вносити зміни в опис лоту та оголошення щодо продажу лота в ЕТС.
Організатор має можливість внести зміни в ті поля які він заповнював самостійно під час публікації аукціону, окрім орієнтовного часу початку аукціону.
Для підтвердження внесених змін Організатор має можливість завантажити документ - "Погодження змін до опису лоту. Опис причин редагування." (documentType:clarifications), має містити перелік змін, які вносяться в оголошення, причину внесення таких змін. Він має бути доступний для завантаження в період редагування (rectificationPeriod) та не є обов'язковим.
Протягом періоду редагування (rectificationPeriod) та Періоду прийняття заяв на участь (tenderPeriod) Організатор процедури може завантажувати та замінювати документи оголошення (procedure.documents[])
Періоди процедури
| Технічна назва | Бізнесова назва | Дата початку | Дата завершення | Результат завершення | Коментар |
|---|---|---|---|---|---|
| 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 + 30 к.д. Верхню - не обмежуємо | Момент завершення роботи модуля аукціону | Статус процедури змінюється: active_auction → qualification | auctionPeriod.endDate присутній виключно за умови наявності не менш ніж 2 заяв на участь (bids[].status: active) на момент tenderPeriod.endDate |
| verificationPeriod | Період верифікації документів | verificationPeriod.startDate == auctionPeriod.endDate | verificationPeriod.endDate == verificationPeriod.startDate + 10 р.д. о 18:00 | Статус процедури змінюється: qualification → active_qualification | Можлива Ручна дія зміни статуса qualification → active_qualification. Організатор натискає кнопку "Перевірку документів завершено", на ЦБД надсилається запит на зміну статуса Процедури. verificationPeriod.endDate не змінюється в API |
| qualificationPeriod | Період кваліфікації | qualificationPeriod.startDate == auctionPeriod.endDate | qualificationPeriod.endDate == qualificationPeriod.startDate + 29 р.д. о 18:00 | На рівні ЦБД: відсутній На рівні майданчика: за 24 години до завершення, надсилання повідомлення Організатору про завершення періоду кваліфікації. |
Статуси процедури
| Технічна назва | Бізнесова назва | Перехід з | За умови | Коментар |
|---|---|---|---|---|
| active_rectification | Редагування доступне | момент публікації оголошення в ЦБД | Ручна дія. Заповнені всі обовʼязкові поля для створення процедури в ЦБД | Майданчик Організатора робить запит до ЦБД та передає об'єкт процедури. У разі правильно сформованого об'єкта процедури, ЦБД повертає майданчику id та 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.endDate) | Для кожного учасника, що мав bids[].status == active на момент auctionPeriod.startDate, в обʼєкті процедури створюється Award у статусі verification Подальша робота Організатора і учасників відбувається з Awards[] |
| active_qualification | Очікується оприлюднення протоколу та підписання договору | qualification | Автоматично. Завершився verificationPeriod, що тривав 10 р.д
Ручна дія. Організатор натискає кнопку "Перевірку документів завершено", на ЦБД надсилається запит на зміну статуса Процедури. | В момент зміни procedure.status: qualification → active_qualification, всі Аварди, що знаходяться у статусі verification автоматично набувають статусу waiting ("Мовчазна згода") Після цього ЦБД автоматично змінює статус всіх Авардів, що знаходяться у статусі waiting на pending АБО pending_waiting (деталі розподілу в розділі Статуси Awards). Аварди в статусі rejected свій статус не змінюють. В момент переходу процедури у статус active_qualification, ЦБД розраховує значення поля x_quantityLimit - це 80% від суми awards.quantity всіх Авардів, які на момент зміни статуса процедури на active_qualification отримали Awards.status <> rejected Тобто, x_quantityLimit включає в себе 80% від quantity тільки тих Авардів, які успішно пройшли перевірку документів АБО Організатор не виконав дій, що вказують на успішну перевірку документів Учасника ("Мовчазна згода"). І не включає quantity Авардів, які явно не пройшли перевірку документів і мали статус rejected ВАЖЛИВО! ЦБД має взяти менше із двох значень. Приклад1: Квота = 10000 Учасник_1 запропонував = 10000 Учасник_2 запропонував = 10000 Обидва учасники успішно пройшли перевірку документів. ЦБД розраховує x_quantityLimit == (10000+10000) * 0.8 = 16000 x_quantityLimit == 10000 Приклад2: Квота = 10000 Учасник_1 запропонував = 5000 Учасник_2 запропонував = 7000 Обидва учасники успішно пройшли перевірку документів. ЦБД розраховує x_quantityLimit == (5000+7000) * 0.8 = 9600 x_quantityLimit == 9600 Якщо Організатор надіслав запит на зміну статуса процедури, то verificationPeriod.endDate в API не змінюється. |
| complete | Аукціон завершено | active_qualification | Ручна дія. Організатор надсилає запит на зміну status: active_qualification → complete | Термінальний статус. При виконанні дії зміни статуса на complete ЦБД перевіряє:
|
| unsuccessful | Аукціон не відбувся | active_tendering qualification active_qualification | Автоматично.
| Термінальний статус. |
cancelled | Аукціон скасовано | active_rectification active_tendering qualification active_qualification | Ручна дія. Організатору у статусах Процедури active_rectification та active_tendering, qualification та active_qualification доступна опція "Скасування" Процедури. Для скасування процедури, Організатору необхідно:
Після цього, при натисканні кнопки, надсилається запит на скасування. Статус процедури автоматично змінюється → cancelled | Термінальний статус. Для зміни статусу процедури на “Аукціон скасовано” Організатор зобов’язаний в особистому кабінеті натиснути кнопку “Скасувати аукціон”, завантажити документ з причинами скасування, вказати причину скасування, після чого майданчик надсилає запит до ЦБД на зміну статусу процедури на “Аукціон відмінено”. ВАЖЛИВО звернути увагу, що нормативно скасувати процедуру можна тільки до МА, але ми залишаємо таку можливість і після МА тільки для форс-мажорних обставин. Технічно скасування доступне і в qualification та active_qualification |
Документи процедури
| 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 P.S.: x_verificationAct - це протокол, який генерується після перевірки документів. Псля "перевірки документів" - це коли процедура набула статусу active_qualification. Тільки в цьому протоколі відображено хто пройшов перевірку документів і які учасники втратили статус учасника, бо не пройшли перевірку документів. Можливість завантажити x_verificationAct є в статусі процедури qualification, але згідно Постанови, вантажити потрібно саме протокол, який генерується після перевірки документів. | Так |
| guaranteeTemplate | Примірна форма банківської гарантії для участі в аукціоні | Bank guarantee template | Примірна форма банківської гарантії для участі в аукціоні | Ні | Так |
| clarifications | Погодження змін до опису лоту. Опис причин редагування. | Clarifications | Документ НЕ обовʼязковий при публікації процедури. Документ НЕ обовʼязковий для редагування процедури. | Ні | Так |
| digitalSignature | Цифровий підпис | Digital signature | Цифровий підпис | Ні | Так |
Скасування аукціону
Рішення Організатора про відміну аукціону повинне бути викладене у формі розпорядчого акта (рішення, наказу, розпорядження, протоколу тощо)
Скасувати процедуру є можливість у всіх статусах, окрім active_auction
У разі відміни аукціону ЦБД автоматично присвоює аукціону статус “аукціон не відбувся”.
Деталі описано тут
Документи скасування процедури (cancellations.documents)
| documentType | Назва Укр | Назва Анг | Опис | Обовʼязковіть для скасування процедури | Публічність |
|---|---|---|---|---|---|
| cancellationDetails | Причини скасування | Cancellation details | Інформація щодо причин скасування аукціону | Так | Так |
| digitalSignature | Цифровий підпис | Digital signature | Цифровий підпис | Ні | Так |
Публікація заяви на участь
Періоди у заяви на участь відсутні.
Можливість подавати заяви на участь є тільки протягом періоду процедури tenderPeriod
Для публікації біда, обовʼязково мають бути заповнені поля: bids.bidders.identifier, bids.bidders.address, bids.bidders.contactPoint, bids.value та bids.quantity
bids.quantity не може бути більше procedure.items[0].quantity. Може дорівнювати чи бути менше.
bids.value - (цінова пропозиція) зазначається в євроцентах за 1 кВт·год (євроцентів/кВт·год) із двома знаками після коми
bids.value.amount <= procedure.value.amount. В іншому випадку ЦБД має повертати валідаційну помилку.
Один учасник може, з точки зору системи, подати декілька заявок на участь. Бізнесово, це виглядає як, Субʼєкт господарювання має декілька обʼєктів, які можуть генерувати електроенергію.
До закінчення tenderPeriod учасники мають право анулювати заяви про участь в аукціоні або внести до них зміни, зокрема шляхом завантаження оновлених редакцій доданих до заяви документів.
У разі коли в момент закінчення кінцевого строку подання заяв про участь в аукціоні подано менше двох заяв, ЦБД автоматично присвоює аукціону статус “аукціон не відбувся” (unsuccessful)
Статуси заяви на участь
| Технічна назва | Бізнесова назва | Перехід з | За умови | Коментар |
|---|---|---|---|---|
| draft | Чернетка заяви | момент публікації заявки в ЦБД | Ручна дія. Учасник надсилає запит на публікацію Bid-а | Публікація заяви на участь доступна тільки протягом tenderPeriod-а процедури. Мають бути заповнені:
Опублікувати бід можна без документів, але без обовʼязкових документів не буде можливості активувати Біда. |
| active | Підтверджена заява | draft | Ручна дія. Учасник надсилає запит на зміну статуса Bid-а | Мають бути заповнені обовʼязкові поля:
та обовʼязкові документи |
| deleted | Видалена заява | active | Ручна дія. Учасник надсилає запит на зміну статуса Bid-а | Скасувати свою заявку на участь є можливість тільки протягом tenderPeriod |
Документи заяви на участь (bids.documents)
| documentType | Назва Укр | Назва Анг | Опис | Обовʼязковіть для активації bid-а | Публічність |
|---|---|---|---|---|---|
| auctionProtocol | Протокол аукціону | Auction protocol | Переможець в особистому кабінеті має можливість завантажити протокол Технічно завантажити Протокол в Біда учасник може тільки коли його повʼязаний Авард знаходиться в статусі pending. Тобто, наприклад, якщо Організатор вже завантажив підписаний протокол в Авард і змінив статус Аварда pending → protocol_signed, то Бід вже не може завантажити свою версію Протоколу в свій Бід. Він отримає помилку: "Forbidden state - {{award_status_name}}. Cannot add bid document in current state" Бізнесово - вантажити потрібно індивідуальний протокол, який генерується, як тільки процедура набуває статусу active_qualification | Ні | Так |
| 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 | Цифровий підпис | Ні | Так |
Необхідно передбачити можливість Учаснику додавати і замінювати документи в 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
| Технічна назва | Бізнесова назва | Перехід з | За умови | Коментар |
|---|---|---|---|---|
| verification | Перевірка документів | Момент auctionPeriod.endDate створюються Awards[] | Автоматично. По завершенню аукціону, процедура переходить у статус qualification ("Перевірка документів"). ЦБД генерує Awards[] у статусі verification для всіх учасників. | За результатами роботи МА (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 протягом МА. Їх порядок має бути згідно часу оновлення їх ставок. За умови НЕ успішної перевірки документів, Організатор змінює статус Awards[].status: verification → rejected (обовʼязково попередньо завантажує та може замінити документ awards.documents: documentType: rejectionProtocol) Організатор має можливість завантажити та заміни в Процедурі документ documentType:x_verificationAct |
| waiting | Документи перевірено | verification | Ручна дія. У Організатора має бути можливість змінювати 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 <> rejected) за умови, що обсяг, який вони запропонували повністю покривається розрахованим значенням 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. Далі відбувається його кваліфікація за логікою кваліфікації інших переможців. |
| protocol_signed | Підписано протокол | pending | Ручна дія. ЦБД має валідувати, що в Авард завантажено документ з documentType: auctionProtocol | Так як, дискваліфікувати Учасника має бути можливість у випадку, коли підписано Протокол і НЕ підписано Договір, використовуємо цей статус для відображення факту підписання Протоколу. |
| pending_waiting | Очікується рішення | waiting | Автоматично. Завершився verificationPeriod.endDate | Статус pending_waiting отримують Аварди, які перебувають у списку результатів Модуля Аукціону і які успішно пройшли етап перевірки документів (award.status <> rejected) за умови, що обсяг, який вони запропонували повністю НЕ покривається розрахованим значенням 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 і отримує можливість погодитись чи відмовитись від залишку обсягу. Це потрібно для того, щоб після успішної кваліфікації переможців, небуло необхідності чекати завершення періоду кваліфікації для погодження умовним переможцем своє право на набуття статуса переможця. В момент отримання Авардом статусу pending_admission, всі інші Аварди, які перебувають у статусі pending_waiting отримують статус cancelled (дискваліфікація Переможців вже неможлива, бо закриті протоколи+договори. Вибор іншого "умовного переможця" не передбачений в нормативці) В цьому статусі Умовний переможець може:
|
| 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 |
| rejected | Відхилено | verification | Ручна дія. Організатор надсилає запит на зміну award.status:verification → rejected
| Термінальний статус. verification → rejected: завантажується документ rejectionProtocol для кожного Аварда, який не пройшов перевірку документів протягом verificationPeriod Поле terminationReason в даному випадку в Аварді заповнювати не обовʼязково |
| unsuccessful | Дискваліфіковано | pending АБО protocol_signed | Ручна дія. Організатор надсилає запит на зміну award.status: pending → unsuccessful Ручна дія. Організатор надсилає запит на зміну статуса Аварда protocol_signed → unsuccessful | Термінальний статус. pending → unsuccessful: ЦБД має валідувати, що в Авард завантажено документ з documentType: act При зміні статуса з pending → unsuccessful ЦБД має валідувати, що заповнено awards.terminationReason значенням зі словника protocol_signed → unsuccessful: При зміні статуса з protocol_signed → unsuccessful Організатору необхідно заповнити поле terminationReason значенням зі словника Обовʼязково хавантажити документ act "про відмову" в Авард. |
Логіка проведення кваліфікації
Одразу по завершенню роботи Модуля аукціону (далі - МА) генеруються Аварди, кількість яких відповідає кількості Бідів, які на момент початку МА мали статус active.
Всі Аварди створюються в статусі verification. Порядок розміщення Авардів важливий і логіка формування порядку описана тут. Паралельно з цим починається verificationPeriod, який триває 10 р.д.
Протягом цих 10 р. д. Організатор має верифікувати учасника і змінити статус Аварда з verification на waiting, або дискваліфікувати і змінити статус Аварда з verification на rejected (тут валідація на док rejectionProtocol).
- Якщо Організатор верифікував всіх учасників швидше, ніж за 10 р.д. у нього має бути можливість надіслати запит на зміну статуса процедури qualification → active_qualification. При цьому verificationPeriod.endDate в API не змінюється. Якщо на момент зміни статусу процедури наявні Аварди у статусі verification, їх статус автоматично змінюється на waiting.
- Якщо Організатор НЕ верифікував всіх учасників протягом 10 р.д. (завершився verificationPeriod), то ЦБД автоматично змінює статус процедури qualification → active_qualification. При цьому, якщо на момент зміни статусу процедури наявні Аварди у статусі verification, їх статус автоматично змінюється на waiting. (бізнесово називається "Мовчазна згода")
Якщо всі Аварди набули статус waiting ТА rejected і не залишилось Авардів у статусі verification, ЦБД автоматично розраховує параметр x_quantityLimit (бере quantity всіх Авардів у статусі waiting, сумує їх і вираховує 80%) (x_quantityLimit не може бути більше за items.quantity. Описано тут)
Після цього ЦБД розподіляє всі Аварди, які перебувають у статусі waiting по статусам pending або pending_waiting за наступною логікою:
- Перевіряється Авард з найменшим value (запропонував наймену ціну), береться його quantity і порівнюється з x_quantityLimit.
- Якщо awards[0].items.quantity <= x_quantityLimit, то Авард отримує статус pending
- Якщо awards[0].items.quantity > x_quantityLimit, то Авард отримує статус pending_waiting
- Перевіряється наступний Авард із черги. Береться його 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 немає. Організатор може раніше завершення цього періоду провести перевірку документів учасників і запитом змінити статус процедури з qualification → active_qualification.
Після цього ЦБД для кожного Аварда у статусі pending генерує протокол.
Від Організатора очікується
- АБО завантаження підписаного протоколу до Аварду, а також завантаження в документи процедури documentType: x_verificationAct + зміна статуса Аварда на protocol_signed
- АБО завантаження в Авард документа documentType: act і подальша дискваліфікація цього Аварда (зміна статуса Аварда на unsuccessful), а також завантаження в документи процедури documentType: x_verificationAct
Організатор може дискваліфікувати тільки Авард у статусі pending і не може дискваліфікувати Авард у статусі pending_waiting
Авард у статусі protocol_signed може автоматично змінити свій статус на unsuccessful за умови, що повʼязаний contract набув статусу cancelled.
Якщо Організатор дискваліфіковує Авард, ЦБД має виконати перевірку першого у списку Аварду у статусі pending_waiting.
- Якщо обсяг першого в порядку Аварду у статусі pending_waiting дорівнює чи менше нерозподіленого залишку, то цей Авард автоматично змінює свій статус на pending. Приклади тут
- Якщо обсяг першого в порядку Аварду у статусі pending_waiting більше нерозподіленого залишку, то Авард залишається в статусі pending_waiting. Приклади тут
Кваліфікація Авардів продовжується поки не залишиться жодного Аварда у статусі pending.
Всі Аварди, що отримували статус pending мають бути АБО кваліфіковані (отримати статус protocol_signed), АБО дискваліфіковані (отримати статус unsuccessful).
Як тільки всі Аварди, що мали статус pending змінили свій статус, Авард, що має статус pending_waiting і знаходиться перший у списку, отримує статус pending_admission (бізнесово називається "Умовний переможець")
Власнику Аварда у статусі pending_admission має бути доступна можливість надіслати запит, в якому вказати quantity. При виконанні запиту ЦБД має перевірити, що quantity, яке вказав Аавард у своєму запит <= нерозподіленому залишку, що дорівнює x_quantityLimit - sum(quantity) всіх Авардів, що отримали статус active.
Після цього "Умовний переможець" має надіслати запит на зміну статуса Аварда pending_admission → pending
Організатор кваліфікує цей Авард і змінює його статус на protocol_signed, або дискваліфікує і змінює статус на unsuccessful.
Робота з Авардами на цьому завершується.
ПРИКЛАДИ:
| Назва в прикладах | шлях в API | Бізнесова назва |
|---|---|---|
| Організатор | - | Замовник |
| Обсяг | procedure.items[0].quantity | Розмір частки річної квоти |
| Макс ціна | procedure.value.amount | Цінова пропозиція (max) |
| Обсяг пропозиції | procedure.bids[*].quantity | Розмір частки квоти в заяві |
| Ціна пропозиції | procedure.bids[*].value | Цінова пропозиція за 1 кВт⋅год |
Приклад 1:
- Організатор вказав Обсяг == 10000
- Організатор вказав Макс ціну == 12
Прийшло три Учасника:
Учасник_1:
- Обсяг пропозиції == 3000
- Ціна пропозиції == 10
Учасник_2:
- Обсяг пропозиції == 2000
- Ціна пропозиції == 11
Учасник_3:
- Обсяг пропозиції == 1000
- Ціна пропозиції == 12
Всі три учасники успішно пройшли перевірку документів і отримали статус Аварда waiting
ЦБД розрахувала x_quantityLimit == (3000 + 2000 + 1000) * 0,8 == 4800
ЦБД розподіляє Обсяги пропозицій учасників:
Учасник_1:
4800 - 3000 = 1800
В даному прикладі Обсяг пропозиції Учасника_1 покривається x_quantityLimit
Учасник_1 отримує статус pending
Учасник_2:
1800 - 2000 < 0
В даному прикладі Обсяг пропозиції Учасника_2 НЕ покривається x_quantityLimit, бо після Учасника_1 залишився нерозподілений залишок 1800, а Обсяг пропозиції Учасник_2 - більший і дорівнює 2000
Учасник_2 отримує статус pending_waiting
Після того, як Учасник_2 отримав статус pending_waiting, наступні учасники також отримуть цей статус автоматично, незважаючи на те, що їх обсяг пропозиції покривається нерозподіленим залишком (вони запропонували більшу ціну).
Учасник_3 отримує статус pending_waiting
Організатор успішно кваліфікує Учасника_1 і його Авард отримує статус protocol_signed
ЦБД перевіряє, що відсутні інші Аварди у статусі pending і автоматично змінює статус Учасника_2 на pending_admission (умовний переможець. Пропонуємо забрати нерозподілений залишок).
Всі інші Аварди, які на момент отримання Учасником_2 статусу pending_admission перебували у статусі pending_waiting, автоматично отримують статус cancelled
Учасник_2 приймає пропозицію реалізувати 1800 нерозподіленого залишку із 2000, які він пропонував початково.
Учасник_2 надсилає запит і статус його Аварда змінюється на pending
а) Організатор успішно кваліфікує Учасника_2, змінює статус Аварда на protocol_signed
Результат: Обсяг 4800 закритий Учасником_1, який забрав 3000 і Учасником_2, який забрав залишок - 1800. Учасник_3 не забрав жодного обсягу
б)
Організатор дискваліфікує Учасника_2, змінює статус Аварда на unsuccessful
Результат: Обсяг 4800 частково закритий Учасником_1, який забрав 3000. Учасник_2 дискваліфікований. Учасник_3 не забрав жодного обсягу
Приклад 2:
- Організатор вказав Обсяг == 10000
- Організатор вказав Макс ціну == 12
Прийшло три Учасника:
Учасник_1:
- Обсяг пропозиції == 3000
- Ціна пропозиції == 10
Учасник_2:
- Обсяг пропозиції == 2000
- Ціна пропозиції == 11
Учасник_3:
- Обсяг пропозиції == 1000
- Ціна пропозиції == 12
Всі три учасники успішно пройшли перевірку документів і отримали статус Аварда waiting
ЦБД розрахувала x_quantityLimit == (3000 + 2000 + 1000) * 0,8 == 4800
ЦБД розподіляє Обсяги пропозицій учасників:
Учасник_1:
4800 - 3000 = 1800
В даному прикладі Обсяг пропозиції Учасника_1 покривається x_quantityLimit
Учасник_1 отримує статус pending
Учасник_2:
1800 - 2000 < 0
В даному прикладі Обсяг пропозиції Учасника_2 НЕ покривається x_quantityLimit, бо після Учасника_1 залишився нерозподілений залишок 1800, а Обсяг пропозиції Учасник_2 - більший і дорівнює 2000
Учасник_2 отримує статус pending_waiting
Після того, як Учасник_2 отримав статус pending_waiting, наступні учасники також отримуть цей статус автоматично, незважаючи на те, що їх обсяг пропозиції покривається нерозподіленим залишком (вони запропонували більшу ціну).
Учасник_3 отримує статус pending_waiting
Організатор успішно кваліфікує Учасника_1 і його Авард отримує статус protocol_signed
ЦБД перевіряє, що відсутні інші Аварди у статусі pending і автоматично змінює статус Учасника_2 на pending_admission (умовний переможець. Пропонуємо забрати нерозподілений залишок).
Всі інші Аварди, які на момент отримання Учасником_2 статусу pending_admission перебували у статусі pending_waiting, автоматично отримують статус cancelled
Учасник_2 НЕ приймає пропозицію реалізувати 1800 нерозподіленого залишку із 2000, які він пропонував початково.
Учасник_2 надсилає запит і статус його Аварда змінюється на cancelled
Результат: Обсяг 4800 частково закритий Учасником_1, який забрав 3000. Учасник_2 відмовився закрити залишок, що склада 1800. Учасник_3 не забрав жодного обсягу. Паралельно з цим відбувається процес підписання Договорів.
Приклад 3:
- Організатор вказав Обсяг == 10000
- Організатор вказав Макс ціну == 12
Прийшло три Учасника:
Учасник_1:
- Обсяг пропозиції == 3000
- Ціна пропозиції == 10
Учасник_2:
- Обсяг пропозиції == 2000
- Ціна пропозиції == 11
Учасник_3:
- Обсяг пропозиції == 1000
- Ціна пропозиції == 12
Всі три учасники успішно пройшли перевірку документів і отримали статус Аварда waiting
ЦБД розрахувала x_quantityLimit == (3000 + 2000 + 1000) * 0,8 == 4800
ЦБД розподіляє Обсяги пропозицій учасників:
Учасник_1:
4800 - 3000 = 1800
В даному прикладі Обсяг пропозиції Учасника_1 покривається x_quantityLimit
Учасник_1 отримує статус pending
Учасник_2:
1800 - 2000 < 0
В даному прикладі Обсяг пропозиції Учасника_2 НЕ покривається x_quantityLimit, бо після Учасника_1 залишився нерозподілений залишок 1800, а Обсяг пропозиції Учасник_2 - більший і дорівнює 2000
Учасник_2 отримує статус pending_waiting
Після того, як Учасник_2 отримав статус pending_waiting, наступні учасники також отримуть цей статус автоматично, незважаючи на те, що їх обсяг пропозиції покривається нерозподіленим залишком (вони запропонували більшу ціну).
Учасник_3 отримує статус pending_waiting
Організатор дискваліфікує Учасника_1 і його Авард отримує статус unsuccessful
При дискваліфікації Учасника із статуса pending → unsuccessful, ЦБД перевіряє наявніть Авардів у статусі pending_waiting
Якщо в рамках періоду очікування результатів кваліфікації (qualificationPeriod) один з award’ів у статусі pending дискваліфіковують, ЦБД розподіляє обсяг переможців, яких було дискваліфіковано, між учасниками з авардами у статусі pending_waiting з наступними найменшими за величиною ціновими пропозиціями. При цьому, вже розрахований обсяг квоти 80% не змінюється. Якщо в результаті для учасника, з award'ом у статусі pending_waiting, формується обсяг, що повністю задовольняє його заяву, award такого учасника переходить до статусу pending. З моменту зміни статусу такого award’у на pending для такого учасника формується окремий період опублікування протоколу та підписання договору (signingPeriod) 15 робочих днів (аналогічно до award'ів, які сформувались спочатку).
Учасник_2 автоматично отримує статус pending
Учасник_3 залишається в статусі pending_waiting
Якщо Організатор дискваліфікує Учасника_2, то Учасник_3 отримає статус pending і почнеться його кваліфікація.
Учасник_3 успішно кваліфіковано.
Результат: Обсяг 4800 частково закритий Учасником_3, який запропонував 1000. Учасник_1 і Учасник_2 дискваліфіковані. Паралельно з цим відбувається процес підписання Договорів.
Приклад 4:
- Організатор вказав Обсяг == 10000
- Організатор вказав Макс ціну == 12
Прийшло три Учасника:
Учасник_1:
- Обсяг пропозиції == 3000
- Ціна пропозиції == 10
Учасник_2:
- Обсяг пропозиції == 1000
- Ціна пропозиції == 11
Учасник_3:
- Обсяг пропозиції == 2000
- Ціна пропозиції == 12
Всі три учасники успішно пройшли перевірку документів і отримали статус Аварда waiting
ЦБД розрахувала x_quantityLimit == (3000 + 2000 + 1000) * 0,8 == 4800
ЦБД розподіляє Обсяги пропозицій учасників:
Учасник_1:
4800 - 3000 = 1800
В даному прикладі Обсяг пропозиції Учасника_1 покривається x_quantityLimit
Учасник_1 отримує статус pending
Учасник_2:
1800 - 1000 = 800
В даному прикладі Обсяг пропозиції Учасника_2 покривається x_quantityLimit, бо після Учасника_1 залишився нерозподілений залишок 1800, а Обсяг пропозиції Учасник_1 - менший, дорівнює 1000
Учасник_2 отримує статус pending
Учасник_3:
800 - 2000 < 0
В даному прикладі Обсяг пропозиції Учасника_3 НЕ покривається x_quantityLimit, бо після Учасника_1 залишився нерозподілений залишок 1800, частина якого розподілилася на Учасника_2, він забрав 1000, Учаснику_3 залишилось 800, а Обсяг пропозиції Учасника_3 - більший, дорівнює 2000
Учасник_3 отримує статус pending_waiting
Організатор успішно кваліфікує Учасника_1 і його Авард отримує статус protocol_signed
Організатор успішно кваліфікує Учасника_2 і його Авард отримує статус protocol_signed
Коли всі Awards, які були у статусі pending успішно кваліфіковані, ЦБД перевіряє наявніть Авардів у статусі pending_waiting
Учасник_3 має статус Аварда pending_waiting, його запропонований обсяг повністю не покривається залишком обсягу, що залишився після розподілення між Учасником_1 і Учасником_2
В даному випадку Учасник_3 отримує статус pending_admission
Учасник_3 має протягом 5-ти днів погодитись "закрити залишок" (залишок складає 800, а Учасник_3 пропонував 2000) і надіслати запит на зміну статуса на pending
Організатор успішно кваліфікує Учасника_3, статус Аварда змінюється на protocol_signed
Результат: 4800 повністю закритий Учасником_1 у розмірі 3000, Учасником_2 у розмірі 1000, Учасником_3 у розмірі 800. Паралельно з цим відбувається процес підписання Договорів.
У випадку бездіяльності Організатора протягом qualificationPeriod, все одно на 30 р.д. відбувається визначення Умовного переможця, де сума "нерозподіленого залишку" визначається згідно актуального на той момент протоколу.
Приклад 5:
- Організатор вказав Обсяг == 10000
- Організатор вказав Макс ціну == 12
Прийшло три Учасника:
Учасник_1:
- Обсяг пропозиції == 6000
- Ціна пропозиції == 10
Учасник_2:
- Обсяг пропозиції == 4000
- Ціна пропозиції == 11
Обидва учасники успішно пройшли перевірку документів і отримали статус Аварда waiting
ЦБД розрахувала x_quantityLimit == (6000 + 4000) * 0,8 == 8000
ЦБД розподіляє Обсяги пропозицій учасників:
Учасник_1:
8000 - 6000 = 2000
В даному прикладі Обсяг пропозиції Учасника_1 покривається x_quantityLimit
Учасник_1 отримує статус pending
Учасник_2:
2000 - 4000 <0
В даному прикладі Обсяг пропозиції Учасника_2 НЕ покривається x_quantityLimit, бо після Учасника_1 залишився нерозподілений залишок 2000, а Обсяг пропозиції Учасника_2 - більший, дорівнює 4000
Протягом qualificationPeriod (29 р.д.) Організатор був бездіяльним і НЕ дискваліфікував Учасника_1 і НЕ кваліфікував успішно.
На 30 р.д. визначається "Умовний переможець" і Учасник_2 набуває статусу pending_admission. Йому пропонується закрити нерозподілений залишок, який становить 2000.
Тобто, те, що з Учасником_1 не завершено кваліфікацію, не впливає на визначення обсягу "нерозподіленого залишку"
Учасник_2 погоджується закрити 2000.
Після цього:
Організатор успішно кваліфікує Учасника_1 і його Авард отримує статус protocol_signed, підписують договір
Організатор успішно кваліфікує Учасника_2 і його Авард отримує статус protocol_signed, підписують договір
Результат: 8000 закритий Учасником_1 у розмірі 6000, Учасником_2 у розмірі 2000
Документи обʼєкта кваліфікації (awards.documents)
| documentType | Назва Укр | Назва Анг | Опис | Обовʼязковіть | Публічність |
|---|---|---|---|---|---|
| rejectionProtocol | Акт про невідповідність | Rejection protocol | Завантажується Організатором для кожного Аварда, який не пройшов перевірку документів протягом verificationPeriod Поле terminationReason в даному випадку заповнювати не обовʼязково | Так Для зміни awards.status: verification → rejected | Так |
| auctionProtocol | Протокол аукціону | Auction protocol | Протокол підписується і завантажується для кожного учасника окремо Завантажити документ auctionProtocol можна тільки в Авард у статусі pending Бізнесово - вантажити необхідно індивідуальний протокол, який генерується, як тільки процедура набуває статусу active_qualification і Авард в статусі pending | Так Для зміни 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 | Так |
| digitalSignature | Цифровий підпис | Digital signature | Цифровий підпис | Ні | Так |
Підписання контракту з переможцем (contracts)
Статуси Contracts
В даній процедурі логіка contracts[] відрізняється від контрактингу базової процедури там, що contracts є не наслідком успішно підписаного протоколу, а має підписуватись в один період.
Ця зміна спричинена тим, що за умови, якщо Договір НЕ підписано, ЦБД автоматично розподіляє частину обсягу лота, між учасниками з наступними найменшими за величиною ціновими пропозиціями відповідно до рейтингу цінових пропозицій (Постанова. п 55)
| Технічна назва | Бізнесова назва | Перехід з | За умови | Коментар |
|---|---|---|---|---|
| pending | Очікується договір | Момент набуття Award-ом статусу protocol_signed | Автоматично. Якщо будь-який Авард набуває статусу 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. При зміні contracts[].status: pending → active, на ЦБД має відбутися перевірка на наявність в contracts[].documents документа з documentType: contractSigned |
| cancelled | Договір скасовано | pending | Автоматично. За умови дискваліфікації Аварда із protocol_signed → unsuccessful | Для того, щоб дискваліфікувати Учасника з причини того, що НЕ підписано договір, необхідно надіслати запит на зміну статуса Аварда protocol_signed → unsuccessful (логка описана в статусі Аварду) |
Документи контракту (contracts.documents)
| documentType | Назва Укр | Назва Анг | Опис | Обовʼязковіть | Публічність |
|---|---|---|---|---|---|
| contractSigned | Підписаний договір | Signed contract | Завантажується для кожного Переможця з ким підписано договір | Так Для зміни contracts.status: pending → active | Так |
| contractAnnexe | Додатки до договору | Contract annexe | Додатки до договору | Ні | Так |
| contractNotice | Повідомлення про договір | Contract notice | Повідомлення про договір | Ні | Так |
| digitalSignature | Цифровий підпис | Digital signature | Цифровий підпис | Ні | Так |
Умови завершення аукціону
Завершення аукціону (переведення у статус complete)
Організатор має можливість завершити аукціон у разі підтвердження або дискваліфікації учасників, які не пройшли кваліфікацію (всі Awards знаходяться у статусі active, unsuccessful, cancelled). Після завершення роботи із договором з кожним переможцем, Замовник аукціону натискає на кнопку “Завершити аукціон”. Після чого процедура змінює статус на complete.
Скасування аукціону
У Органзатора є можливість скасувати процедуру, коли процедура має один із статусів:
active_rectification
active_tendering
qualification
active_qualification
Використовуємо cancellations[] модель.
Для скасування Замовник аукціону має:
- завантажити документ cancellations[].documents з documentType: cancellationDetails
- вказати причину скасування в cancellations[].reason із словника
- вказати фактичну дату скасування в cancellations[].datePublished
Зміни, які необхідно внести в процедуру:
accessDetails - видалити поле (зараз обовʼязкове, хоча я не бачу в Постанові нічого про "Порядок та можливий час ознайомлення з лотом")
x_additionalInformation - зробити НЕ обовʼязкове поле (зараз обовʼязкове, хоча я не бачу в Постанові нічого про те, що треба ОБОВʼЯЗКОВО надавати "Додаткові відомості". Навпаки: "Оголошення про проведення аукціону може містити інші відомості, необхідні для його проведення")
bankAccounts - видалити. згідно переписки з ГарПок:
bids.qualified - прибрати із біда. Не несе взагалі ніякої логіки
minNumberOfQualifiedBids - мінімально допустиме значення == 2.
contracts - стандартна логіка contracts не підходить. Через те, що, якщо Договір не підписано, то ЦБД має автоматично визначити нового переможця, якщо ще не завершився qualificagionPeriod. Потрібна логіка описана
contracts - status - прибрати зайві paid, signed,unsuccessful
В Swagger наявні renewables.GreenProcedure та renewables.RenewablesMultiAwardsProcedure - треба залишити лише renewables.RenewablesMultiAwardsProcedure
datePublished - x-legalNameUa змінити на *Дата публікації процедури*.
previousAuctionId прибрати в Swagger можливість додавання UA-PS-YYYY-MM-DD-000000-0
items.unit.code - зробити "KWT" - readOnly: true автогенерованє.
cancellation - змінити на базову модель base.Cancellation
x_valueUAH - прибрати
Всі зміни по полям зазначені нижче: зелений - додати, червоний - видалити, помаранчевий - змінити
| renewables.RenewablesMultiAwardsProcedure | type | readOnly | x-legalNameUa | x-legalNameEn | Коментар | ||
|---|---|---|---|---|---|---|---|
| owner | string | true | Ідентифікатор майданчика | Broker identifier | |||
| ownerToken | string($uuid) | true | |||||
| _id | string | true | Внутрішній ідентифікатор аукціону | ID | |||
| datePublished | string($date-time) | true | Дата публікації процедури | Published date | |||
| dateModified | string($date-time) | true | Остання дата зміни процедури | Procedure date modified | |||
| auctionId | string | true | Ідентифікатор аукціону | Auction ID | REM | ||
| previousAuctionId | string | Номер попереднього аукціону | Previous auction Id | pattern: ^(REM[0-9]{3}-UA-[0-9]{8}-[0-9]{5}) | |||
| sellingMethod | string | Тип процедури | Procedure type | renewables-multiAwards renewables-multiAwards-ultra-fast renewables-multiAwards-fast renewables-multiAwards-fast-manual renewables-multiAwards-fast-auction-manual-qualification renewables-multiAwards-fast-auction-prod renewables-multiAwards-initial-auction renewables-multiAwards-initial-qualification renewables-multiAwards-initial-qualification-prod renewables-multiAwards-initial-qualification-fast renewables-multiAwards-initial-auction-manual | |||
| sellingEntity | model | Інформація про замовника аукціону | Auction customer information | ||||
| name | model base.multiLang | Найменування Замовника аукціону | Name of the auction customer | ||||
| identifier | model base.Identifier | Ідентифікатори Замовника аукціону | Customer ID | ||||
| scheme | string | Тип ідентифікації Замовника аукціону | Customer ID type | Допустимі тільки значення зі словника Для публікації процедури обовʼязково заповнено | |||
| legalName | model base.multiLang | Повна юридична назва організації | Legal name | Для публікації процедури обовʼязково заповнено legalName.uk_UA | |||
| id | Код ЄДРПОУ або ІПН або паспорт | Legal ID | Для публікації процедури обовʼязково заповнено | ||||
| address | model base.AddressUa | ||||||
| countryName | model base.multiLang | Країна | Country | uk_UA = Enum:[Україна] uk_UA - Для публікації процедури обовʼязково для заповнення | |||
| region | model base.multiLang | Область | Region | uk_UA = Enum: uk_UA - Для публікації процедури обовʼязково для заповнення | |||
| locality | model base.multiLang | Населений пункт | Locality | uk_UA -Для публікації процедури обовʼязково для заповнення | |||
| streetAddress | model base.multiLang | Адреса | Address | uk_UA - Для публікації процедури обовʼязково для заповнення | |||
| postalCode | string | Поштовий індекс | ZIP code | pattern: ^[0-9]{5}$ | |||
| representativeInfo | string | Інформація щодо підтвердження повноважень | Representative information | ||||
| contactPoint | model base.ContactPoint | ||||||
| name | model base.multiLang | ПІБ | Main contact name | uk_UA - Для публікації процедури обовʼязково для заповнення | |||
| string($email) | Адреса електронної пошти | Main contact e-mail | Для публікації процедури обовʼязково для заповнення | ||||
| telephone | string | Номер телефону | Phone number | Для публікації процедури обовʼязково для заповнення | |||
| faxNumber | string | Номер факсу | Fax number | ||||
| url | string($uri) | Веб адреса | Website | ||||
| x_verificationDocuments | list[] model base.VerificationDocumentInfo | Ліцензія | Business verification documents | ||||
| description | model base.multiLang | Опис документа | Document description | ||||
| id | string | Номер документа | Business verification documents ID | ||||
| date | string($date-time) | Дата видачі документа | Business verification documents date | ||||
| lotId | string | Номер лоту | Lot number | Для публікації процедури обовʼязково для заповнення | |||
| title | model base.multiLang | Заголовок аукціону | uk_UA - Для публікації процедури обовʼязково для заповнення | ||||
| description | model base.multiLang | Опис аукціону | uk_UA - Для публікації процедури обовʼязково для заповнення | ||||
| accessDetails | ВИДАЛЯЄМО | ||||||
| bankAccount |
| ВИДАЛЯЄМО в постанові нічого не вказано про банківські реквізити. із погоджувальної таблиці: "Ця інформація не зберігається в системі, а відображається кожним майданчиком окремо." - це про Банківські реквізити оператора авторизованого електронного майданчика для сплати переможцем зазначеної винагороди
| |||||
| x_documentRequirements | model base.multiLang | Вимоги до оформлення документів | Document requirements | uk_UA - Для публікації процедури обовʼязково для заповнення | |||
| x_additionalInformation | model base.multiLang | Додаткові відомості | Other requirements and additional information | НЕ ОБОВʼЯЗКОВЕ | |||
| x_quantityLimit | number($float) | true | 80% сукупної величини потужності учасників | 80% limit | |||
| value | model ValueWithTax | Максимальна цінова пропозиція | Max bid value | ||||
| currency | string | Валюта | Currency | Enum: [eurocent] Для публікації процедури обовʼязково для заповнення | |||
| amount | number($float) | Сума | Amount | Для публікації процедури обовʼязково для заповнення | |||
| valueAddedTaxIncluded | boolean | true | Податок | Tax | default: false readOnly: true ЦБД не має приймати value.valueAddedTaxIncluded == true, а зараз приймає. Допустиме значення тільки false Якщо майданчик не передав, то автозаповнити як false | ||
| guarantee | ВИДАЛИТИ | ||||||
| bankGuaranteeDetails | model base.multiLang | Інформація щодо банківської гарантії | Bank guarantee info | Інформація щодо банківської гарантії | |||
| minimalStep | model base.Value | true | Розмір кроку аукціону | Minimal Step | Організатор НЕ передає це поле. При публікації процедури автоматично генерується, як: "currency": "eurocent", | ||
| currency | string | true | Валюта | Currency | default: eurocent | ||
| amount | number($float) | true | Сума | Amount | default: 0.01 | ||
| minNumberOfQualifiedBids | integer($int64) | true | Мінімальна кількість заяв учасників | Minimal number of bids | default: 2 | ||
| tenderAttempts | integer($int64) | Лот виставляється | Attempt number | default: 1 minimum: 1 | |||
| items[] | list[] model renewables.Item | Склад лота | Lot composition | МАЄ БУТИ МОЖЛИВІСТЬ ДОДАТИ ТІЛЬКИ ОДИН item В МАСИВ! | |||
| id | string | true | Внутрішній ідентифікатор обʼєкта | Item ID |
| ||
| description | model base.multiLang | Опис лота | Item description | uk_UA - Для публікації процедури обовʼязково для заповнення | |||
| classification | model Classification | Класифікатор | Classification |
| |||
| scheme | string | true | Схема класифікатора | Item classification scheme | default: CAV Автозаповнюється ЦБД при публікації процедури Організатор НЕ передає це поле | ||
| description | model base.multiLang | true | Опис коду классифікатора | Classification ID | default: "uk_UA": "Електрична, теплова, сонячна та атомна енергія", Автозаповнюється ЦБД при публікації процедури Організатор НЕ передає це поле | ||
| id | string | true | Код классифікатора | Classification ID | default: 09300000-2 Автозаповнюється ЦБД при публікації процедури Організатор НЕ передає це поле | ||
| unit | model base.Unit | true | Одиниці виміру обʼєкта | Item unit | Автозаповнюється ЦБД при публікації процедури Організатор НЕ передає це поле | ||
| code | string | true | Код одиниці виміру | Unit code | default: KWT | ||
| name | model base.multiLang | true | Назва одиниці виміру | Item unit name | default: "uk_UA": "Кіловат-година", | ||
| quantity | number($float) | Розмір частки річної квоти | Item quantity | Для публікації процедури обовʼязково для заповнення | |||
| address |
| ВИДАЛЯЄМО | |||||
| itemProps[] | model Renewables |
| |||||
| regions[] | string | Області, в яких розподіляється обсяг лота | Lot regions | Enum: [Автономна Республіка Крим, Вінницька область, Волинська область, Дніпропетровська область, Донецька область, Житомирська область, Закарпатська область, Запорізька область, Івано-Франківська область, Київська область, Київ, Кіровоградська область, Луганська область, Львівська область, Миколаївська область, Одеська область, Полтавська область, Рівненська область, Севастополь, Сумська область, Тернопільська область, Харківська область, Херсонська область, Хмельницька область, Черкаська область, Чернівецька область, Чернігівська область] | |||
| techParams | string | Технічні параметри установок зберігання енергії, які можуть бути встановлені на об’єкті | Technical parameters of energy storage installations that can be installed at the facility |
| |||
| timeSlots | string | Денні часові інтервали, протягом яких учасник може набути право на підтримку | Daily time intervals during which the economic entity can acquire the right to support |
| |||
| loadProfiles | string | Профілі навантаження об’єкта електроенергетики | Load profiles of the power plant |
| |||
| additionalClassifications[] | list[] model AdditionalClassification | Вид джерела енергії | Type of energy source | МАЄ БУТИ МОЖЛИВІСТЬ ДОДАТИ ТІЛЬКИ ОДИН additionalClassification В МАСИВ! | |||
| scheme | string | Схема додаткового класифікатору | Item additional classification scheme | Dict: generationType | |||
| description | model base.multiLang | true | Опис додаткового класифікатору | Item additional classification description | Автозаповнюється цз словника generationType згідно коду | ||
| id | string | Код додаткового класифікатору | Item additional classification ID | x-dictionaries: List [ "generationType" ] | |||
|
| ||||||
| documents[] | model base.Documents | documentOf: auction documentType: [illustration, technicalSpecifications, evaluationCriteria, contractProforma, x_lotInfoEN, x_verificationAct, guaranteeTemplate, clarifications, digitalSignature] | |||||
| bids[] | model renewables.Bid | Заява на участь | Bid |
| |||
| owner | string | true | Ідентифікатор майданчика | Broker ID |
| ||
| ownerToken | string($uuid) | true |
| ||||
| id | string | true | Ідентифікатор заяви на часть | Bid ID |
| ||
| bidders[] | model base.Organization | Інформація учасника | Bidder info |
| |||
| name | model base.multiLang | true | Повна юридична назва організації або ПІБ | Legal name or Full Name | Автозаповнюється автоматично із identifier.legalName.* | ||
| identifier | model base.Identifier | Ідентифікатори організації або особи | Identifier | scheme* string Обирається одне значення зі словників: legalName* model base.MultiLang id* string Обовʼязкові поля для активації Біда | |||
| address | model anyOf -> base.Address OR baseAddressUa | Адреса | Address | Обовʼязкові поля для активації Біда: countryName region locality streetAddress | |||
| representativeInfo | string | Інформація щодо підтвердження повноважень | Representative information | ||||
| contactPoint | model base.ContactPoint | Контактна особа | Main contact | Обовʼязкові поля для активації Біда name telephone | |||
| datePublished | string($date-time) | true | Дата заяви на участь | Bid date |
| ||
| dateModified | string($date-time) | true | Остання дата редагування ставки | Bid modified date |
| ||
| status | string | Статус заяви на участь | Bid status | Enum:[draft, active, deleted] | |||
| value | model Value | Цінова пропозиція за 1 кВт*год | Price per 1 kW·h | Обовʼязкове поле для активації Біда | |||
| currency | string | Валюта | Currency | Enum:[eurocent] Обовʼязкове поле для активації Біда | |||
| amount | number($float) | Сума | Amount | Обовʼязкове поле для активації Біда | |||
| documents[] |
| model base.Documents | Документи до заяви про участь | Bid documents | documentOf: bid documentType: [auctionProtocol, x_guarantee, х_ultimateBeneficiaryInfo, x_governingBodyInfo, x_relatedParties, x_generationType, eligibilityDocuments, digitalSignature] | ||
| participationUrl | string | true | Веб-адреса для участі в аукціоні | Bidder participation link |
| ||
| order | integer($int64) | true |
| ||||
| classification[] | ВИДАЛИТИ | ||||||
| additionalClassifications[] | ВИДАЛИТИ | ||||||
| unit | model Unit | true | readOnly: true | ||||
| code | string | true | Код одиниці виміру | Unit code | default: KWT | ||
| name | model base.multiLang | true | Назва одиниці виміру | Item unit name | default: "uk_UA": "Кіловат-година", | ||
| quantity | number($float) | Розмір частки квоти в заяві | Bid quantity | Обовʼязкове поле для активації Біда | |||
| qualified |
| ВИДАЛИТИ | |||||
| initialValueAmount | number($float) | true | Початкова ставка | Start bid amount |
| ||
| questions[] | model base.Questions | Запитання до аукціону | Q&A |
| |||
| awards[] | model | Обʼєкт кваліфікації | Award |
| |||
| id | string | true | ідентифікатор обʼєкта кваліфікації | Award ID |
| ||
| title | model base.multiLang | Назва обʼєкта кваліфікації | Award title | Я БИ ВИДАЛИВ Awards.title та Awards.description. Вони не заповнюються і не розумію навіщо потрібні. Але присутні у всіх Процедурах | |||
| description | model base.multiLang | Опис обʼєкта кваліфікації | Award description |
| |||
| status | string | Статус | Status | Enum: [verification, waiting, pending, pending_waiting, procotol_signed, pending_admission, active, rejected, unsuccessful, cancelled] | |||
| terminationReason | string | Причина дискваліфікації | Termination Reason | ||||
| datePublished | string($date-time) | true | Дата створення | Award published date |
| ||
| value | model | Цінова пропозиція | Award price |
| |||
| currency | string | Валюта | Currency | Enum:[eurocent] | |||
| amount | number($float) | Сума | Value | ||||
| buyers[] | model base.Organization | Дані учасника | Award buyer info | КОПІЮЄТЬСЯ ІЗ ПОВʼЯЗАНОГО BID | |||
| name | model base.multiLang | Повна юридична назва організації або ПІБ | Legal name or Full Name | ||||
| identifier | model base.Identifier | Ідентифікатори організації або особи | Identifier | ||||
| address | model base.Address base.AddressUa | Адреса | Address | ||||
| representativeInfo | string | Інформація щодо підтвердження повноважень | Representative information | ||||
| contactPoint | model base.ContactPoint | Контактна особа | Main contact | ||||
| items[] |
| ||||||
| id | string | true | Внутрішній ідентифікатор обʼєкта | Item ID | копіюється id айтема із процедури | ||
| description | model base.multiLang | Опис лота | Item description | копіюється description айтема із процедури | |||
| classification | model Classification | Класифікатор | Classification | копіюється classification айтема із процедури | |||
| unit | копіюється із повʼязаного Біда | ||||||
| quantity | number($float) | Розмір частки квоти | Award quantity | ЛОГІКА ВІДОБРАЖЕННЯ quantity в Аварді:
копіюється із повʼязаного Біда | |||
| address | ВИДАЛЯЄМО | ||||||
| itemProps[] | модель items[].itemProps використовуємо таку саму, як і в процедурі вище Копіюється із процедури | ||||||
| additionalClassifications[] | Копіюється із процедури | ||||||
| |||||||
| documents[] | model Documents | documentOf: award documentType:[rejectionProtocol, auctionProtocol, act, digitalSignature] | |||||
| dateModified | string($date-time) |
| |||||
| bidId | string |
| |||||
| signingPeriod | model base.Period |
| |||||
| admissionPeriod | model base.Period | ||||||
| timer | string($date-time) | true | |||||
| archiveId | string | true | |||||
| contracts[] | model renewables.Contract | ||||||
| id | string | true | |||||
| awardId | string | true | |||||
| contractNumber | string | ||||||
| title | model base.multiLang | ||||||
| description | model base.multiLang | ||||||
| value | model Value | ||||||
| currency | |||||||
| amount | |||||||
| contractTotalValue | model Value | ||||||
| currency | |||||||
| amount | |||||||
| items[] | копіюється із повʼязаного Award в тій самій структурі | ||||||
| buyers[] | копіюється із повʼязаного Award | ||||||
| status | Статус | Status | Enum:[pending,active,cancelled] | ||||
| dataSigned | Дата підписання договору | Contract date signed | |||||
| datePublished | |||||||
| dateModified | |||||||
| documents[] | model Document | Документи договору | Contract documents | documentOf: contract documentType: [contractSigned, contractAnnexe, contractNotice, digitalSignature] | |||
| contractTime | ВИДАЛИТИ | ||||||
| x_valueUAH | ВИДАЛИТИ | ||||||
| rectificationPeriod | model base.Period | true | Період редагування | Rectification period | |||
| enquiryPeriod | model base.Period | true | Період відповідей | Enquiry period | |||
| tenderPeriod | model base.Period | true | Період прийняття заяв на участь | Tender period | |||
| auctionPeriod | model base.Period | true | Аукціон | Auction | |||
model base.Period | ПЕРЕЙМЕНУВАТИ НА qualificationPeriod | ||||||
| qualificationPeriod | model base.Period | true | Період кваліфікації | Qualification period | те саме, що й waitingPeriod (замінити назву) | ||
| verificationPeriod | model base.Period | true | Період верифікації документів | Verification period | |||
| questionPeriod | model base.Period | true | Період запитань | Question period | |||
| status | true | Статус | Status | Enum: [active_rectification, active_tendering, active_auction, qualification, active_qualification, complete, unsuccessful, cancelled] | |||
| cancellations[] | model base.Cancellation | Скасування аукціону | Auction cancelleation | ||||
| id | string | true | |||||
| reason | model base.multiLang | ||||||
| documents[] | model Documents | documentOf: cancellation documentType: [cancellationDetails, digitalSignature] | |||||
| datePublished | string($date-time) | Дата прийняття рішення про скасування | Cancellation date |
