Зелена енергетика

Посилання:

• Закон
• Постанова

Голосарій

Аукціон закритого типу - аукціон, в якому з моменту активації модуля аукціону до моменту завершення аукціону електронною торговою системою не відображається (не публікується) жодна інформація, що подана учасниками в заявах про участь або доданих до них документах, а також цінові пропозиції, які були змінені протягом часу, відведеного на оновлення таких пропозицій;

Величина потужності - встановлена потужність, щодо якої учасник має намір набути право на підтримку;

Оголошення - процедура продажу річної квоти

Організатор - замовник аукціону (в Нормативці фігурує як "Гарантований покупець")

Переможець - учасник, який набуває право на підтримку у виробництві електричної енергії за результатами аукціону.

Умовний переможець - учасник, що йде наступним за останнім у рейтингу переможцем відповідно до протоколу про результати аукціону і якому надається можливість набути право на підтримку в обсязі частини величини потужності;

Учасник - суб’єкт господарювання, який має намір взяти участь в аукціоні, пройшов процедуру реєстрації в електронній торговій системі, отримав відповідне підтвердження про реєстрацію для участі в аукціоні та індивідуальний код учасника відповідно до Регламенту роботи електронної торгової системи;

Цінова пропозиція - ціна продажу 1 кВт·год електричної енергії, яка декларується учасником та інформація про яку подається в електронній торговій системі до закінчення кінцевого строку подання заяв про участь в аукціоні або в ході проведення аукціону шляхом оновлення такої цінової пропозиції.

Максимальний розмір цінової пропозиції учасника  - найбільша ціна у євроцентах за 1 кВт·год, яку може вказати учасник в своїй заявці на участь. Вказує Організатор при публікації оголошення,чим обмежує максимально можливу ставку.

Мета створення процедури та нормативні засади

Відповідно до Постанови від 27 грудня 2019 р. № 1175 КМУ "Про запровадження конкурентних умов стимулювання виробництва електричної енергії з альтернативних джерел енергії".

Визначається механізм процедури підготовки та проведення аукціону з розподілу квоти підтримки для стимулювання виробників електричної енергії з альтернативних джерел енергії з використанням електронної торгової системи, порядок функціонування електронної торгової системи та визначення переможця за результатами проведення аукціону, порядок укладення та публікації договору купівлі-продажу в електронній торговій системі, розмір та порядок сплати винагороди операторам авторизованих електронних майданчиків та інші питання проведення аукціонів.

З метою проведення аукціонів з розподілу квот підтримки для електричної енергії з альтернативних джерел енергії в межах системи ProZorro.Sale реалізовано sellingMethod: timber-multiAwards. Така процедура надає змогу Замовнику здійснити продаж квот підтримки для електричної енергії, в рамках аукціону, необмеженій кількості учасників, а учаснику придбати частину заявленої квоти підтримки для електричної енергії у лоті Замовником, саме ту кількість обсягу, що потрібна учаснику.

Загальна інформація про роботу процедури

Критерієм вибору переможця є цінова пропозиція, що складається з ціни за 1 кВт*годину та обсяг генерації у кВт, за умови відповідності пропозиції учасника кваліфікаційним критеріям, визначеним Замовником аукціону.

Кваліфікація відбувається після завершення аукціону, попередньої кваліфікації немає.

За наявності 2-х та більше заяв на участь за результатами періоду подання пропозицій (tenderPeriod), процедура переходить у період аукціону (auctionPeriod). У протилежному випадку аукціон визнається таким, що не відбувся. Статус аукціону автоматично змінюється на unsuccessful.

За результатами аукціону пропозиції учасників сортуються по ціні та кваліфікуються ті учасники, яким вистачило запропонованого Замовником аукціону обсягу квоти. У випадку дискваліфікації одного з учасників, кваліфікація переходить до наступного учасника в черзі.

Особливості процедури

1. На етапі публікації Процедури:
   • в одній процедурі може бути тільки один item (ДОДАТИ ВАЛІДАЦІЮ)
2. На етапі подання заяв на участь:
   
   • учасник може подати одну або більше заяв на участь в одному аукціоні, відповідно до кількості об'єктів електроенергетики наявних у нього. (Один Учасник може мати декілька різних обʼєктів енергетики, які можуть приймати участь в одному аукціоні окремими заявками) 
     В нормативці є

     33. У разі коли учасник бере участь в аукціоні для набуття права на підтримку щодо двох чи більше об’єктів електроенергетики або черг будівництва (пускових комплексів) об’єктів електроенергетики, такий учасник подає окремі заяви про участь в аукціоні щодо кожного об’єкта або черги будівництва електричної станції.

3. Аукціон:
   • для запуску МА на момент tenderPeriod.endDate має бути мінімум два bids[] у статусі active (minNumberOfQualifiedBids==2). Якщо менше двух статус процедури змінюється на unsuccessful
   • "сліпий" аукціон (детально описано в ТЗ "renewables auction") 
4. Кваліфікація:
   • кількість переможців необмежена
   • наявність необмеженої кількості учасників, що очікують
   • наявність одного умовного переможця

Опис класифікаторів

• Під час публікації процедури ЦБД автоматично генерує значення для (ДОДАТИ ЦЕ НА РІВНІ ЦБД)

  • itmes[0].classification.scheme == CAV

  • itmes[0].classification.id == 09300000-2

Основний класифікатор (код) - 09300000-2 - Електрична, теплова, сонячна та атомна енергія. Посилання на словник

• При публікації процедури, Організатор може вказати (не обовʼязково) Додатковий класифікатор "Вид джерела енергії" (одне значення з словника)

Посилання на legalName endpoint

legalName endpoint (ЗАМІНИТИ + ПРОВАЛІДУВАТИ)

Timeline процедури

Публікація процедури

Створення оголошення

При публікації оголошення про проведення аукціону, Організатором аукціону необхідно заповнити обовʼязкові поля:

• Інформація про Замовника (sellingEntity)
  • Ідентифікатори Замовника аукціону (Код ЄДРПОУ або ІПН або паспорт) (identifier)
  • Місцезнаходження Замовника аукціону (повна адреса) (address)
  • Інформація про контактну особу (contactPoint)
• Номер лоту (lotId)
• Повну назву Аукціону (заголовок) (title)
• Опис аукціону (description)
• Вимоги до оформлення документів (x_documentRequirements)
• Максимальний розмір цінової пропозиції учасника (value)
• Розмір банківської гарантії для участі в аукціоні за 1 кВт (guarantee.amount, guarantee.currency (only EUR)) (МОЖЕМО DEFAULT ЗРОБИТИ 5 ЄВРО)
• Інформація про лот, що пропонується на аукціон, із зазначенням його розміру (items.quantity, items.description)
• items.unit.code (ЗАПОВНЮЄТЬСЯ ЦБД АВТОМАТИЧНО == KWT із словника )
  із Постанови

  29. Величина потужності зазначається у кіловатах (кВт).

• items.classification == CAV 09300000-2 (ЗАПОВНЮЄТЬСЯ ЦБД АВТОМАТИЧНО)
• items.regions[] - новий параметр, який необхідно додати до items. Параметр НЕ обовʼязковий до заповнення. Організатор може вказати "Області, у яких розподіляється обсяг лота"
• Документи
• Дата та час проведення аукціону (auctionPeriod.startDate)

Повний перелік полів в Swagger

Редагування оголошення

Протягом періоду редагування (rectifiactionPeriod) Організатор аукціону має право самостійно вносити зміни в опис лоту та оголошення щодо продажу лота в ЕТС.
Організатор має можливість внести зміни в ті поля які він заповнював самостійно під час публікації аукціону, окрім орієнтовного часу початку аукціону.
Для підтвердження внесених змін Організатор має можливість завантажити документ - "Погодження змін до опису лоту. Опис причин редагування." (documentType:clarifications), має містити перелік змін, які вносяться в оголошення, причину внесення таких змін. Він має бути доступний для завантаження в період редагування (rectificationPeriod) та не є обов'язковим.

Протягом періоду редагування (rectificationPeriod) та Періоду прийняття заяв на участь (tenderPeriod) Організатор процедури може завантажувати та замінювати документи оголошення (procedure.documents[])

Періоди процедури

Статуси процедури

Документи процедури

Скасування аукціону

Рішення Організатора про відміну аукціону повинне бути викладене у формі розпорядчого акта (рішення, наказу, розпорядження, протоколу тощо)

Скасувати процедуру є можливість у всіх статусах, окрім active_auction

У разі відміни аукціону ЦБД автоматично присвоює аукціону статус “аукціон не відбувся”.

Деталі описано тут

Документи скасування процедури (cancellations.documents)

Публікація заяви на участь

Періоди у заяви на участь відсутні.

Можливість подавати заяви на участь є тільки протягом періоду процедури 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)

Статуси заяви на участь

Документи заяви на участь (bids.documents)

Необхідно передбачити можливість Учаснику додавати і замінювати документи в bids[x].documents, коли бід знаходиться у статусі active. Після завершення роботи МА у Учасника такожм має бути можливість додавати і замінювати документи. 

Кваліфікація

За результатами періоду аукціону (auctionPeriod) пропозиції сортуються від меншої ціни до більшої, а у випадку співпадіння ціни, вище відображається пропозиція розміщена раніше. Часом розміщення пропозиції вважається час першого розміщення заяви у ЦБД, а, у випадку редагування пропозиції під час періоду прийому пропозицій, час фіксації змін у заяві у ЦБД. По завершенню аукціону, процедура переходить у статус qualification - фазу перевірки документів учасників. ЦБД генерує award'и для N учасників у статусі verification. award'и формуються для всіх учасників, відповідно до поданих кількості заяв на участь. Валідною ставкою вважається та, що рівна або менша за значення value.amount.

Періоди Awards

Статуси Awards

Логіка проведення кваліфікації

Одразу по завершенню роботи Модуля аукціону (далі - МА) генеруються Аварди, кількість яких відповідає кількості Бідів, які на момент початку МА мали статус active.

Всі Аварди створюються в статусі verification. Порядок розміщення Авардів важливий і логіка формування порядку описана тут. Паралельно з цим починається verificationPeriod, який триває 10 р.д.

Протягом цих 10 р. д. Організатор має верифікувати учасника і змінити статус Аварда з verification на waiting, або дискваліфікувати і змінити статус Аварда з verification на unsuccessful (тут валідація на док rejectionProtocol).

• Якщо Організатор верифікував всіх учасників швидше, ніж за 10 р.д. у нього має бути можливість надіслати запит на зміну статуса процедури qualification → active_qualification. При цьому verificationPeriod.endDate в API не змінюється. Якщо на момент зміни статусу процедури наявні Аварди у статусі verification, їх статус автоматично змінюється на waiting.
• Якщо Організатор НЕ верифікував всіх учасників протягом 10 р.д. (завершився verificationPeriod), то ЦБД автоматично змінює статус процедури qualification → active_qualification. При цьому, якщо на момент зміни статусу процедури наявні Аварди у статусі verification, їх статус автоматично змінюється на waiting. (бізнесово називається "Мовчазна згода")

Якщо всі Аварди набули статус waiting ТА unsuccessful і не залишилось Авардів у статусі verification, ЦБД автоматично розраховує параметр x_quantityLimit (бере quantity всіх Авардів у статусі waiting, сумує їх і вираховує 80%)

Після цього ЦБД розподіляє всі Аварди, які перебувають у статусі waiting по статусам pending або pending_waiting за наступною логікою:

• Перевіряється Авард з найменшим value (запропонував наймену ціну), береться його quantity і порівнюється з x_quantityLimit.
  • Якщо awards[0].items.quantity <= x_quantityLimit, то Авард отримує статус pending
  • Якщо awards[0].items.quantity > x_quantityLimit, то Авард отримує статус pending_waiting

• • теоретично можлива ситуація

    Можливо таке, що перший Авард одразу отримає статус pending_waiting. Логічно, що всі наступні Аварди також отримають цей статус.

    В такому випадку, перший Авард має одразу отримати статус pending_admission і слідувати логіці цього статуса.

    Наприклад, 

    Організатор вказав procedure.items.quantity == 10 000

    Учасник_1 запропонував 10 000 по найменшій ціні 10

    Учасник_2 запропонував 500 по ціні 11

    Учасник_3 запропонував 500 по ціні 12

    Всі три учасники успішно пройшли перевірку документів (awards.status == waiting)

    ЦБД розраховує x_quantityLimit == (10000 + 500 + 500) * 0.8 == 8 800

    Реалізувати є можливість тільки 8800, а перший Авард пропонував 10000, що є більше, ніж очікується. Він одразу отримує статус pending_waiting, і всі наступні Аварди також.

    Одразу після цього перший Авард отримає статус pending_admission  і може погодитись на 8800 із своїх 10000, які він ставив спочатку.

    Якщо він відмовиться ставити 8800 замість 10000, то процедура вважається неуспішною. Наступних Авардів вже не кваліфікують.

• Перевіряється наступний Авард із черги. Береться його quantity і порівнюється з (x_quantityLimit - awards[0].items.quantity). 
  • Якщо awards[1].items.quantity <=  (x_quantityLimit - awards[0].items.quantity) залишку, то Авард отримує статус pending
  • Якщо awards[1].items.quantity > (x_quantityLimit - awards[0].items.quantity) залишку, то Авард отримує статус pending_waiting
• Аналогічна перевірка відбувається з кожним наступним Авардом до моменту, коли перший Авард отримує статус pending_waiting. Коли перший із всіх Авардів отримає статус pending_waiting, то всі наступні також автоматично отримують цей статус.

За результатами автоматичного розподілення, всі Аварди, які мали статус waiting отримують новий статус pending АБО pending_waiting.

Залежності від періоду verificationPeriod немає. Організатор може раніше завершення цього періоду провести перевірку документів учасників і запитом змінити статус процедури з 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.

Робота з Авардами на цьому завершується.

ПРИКЛАДИ:

Приклад 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. Паралельно з цим відбувається процес підписання Договорів.

Документи обʼєкта кваліфікації (awards.documents)

Підписання контракту з переможцем (contracts)

Статуси Contracts

В даній процедурі логіка contracts[] відрізняється від контрактингу базової процедури там, що contracts є не наслідком успішно підписаного протоколу, а має підписуватись в один період.

Ця зміна спричинена тим, що за умови, якщо Договір НЕ підписано, ЦБД автоматично розподіляє частину обсягу лота, між учасниками з наступними найменшими за величиною ціновими пропозиціями відповідно до рейтингу цінових пропозицій (Постанова. п 55)

Документи контракту (contracts.documents)

Умови завершення аукціону

Завершення аукціону (переведення у статус complete)

Організатор має можливість завершити аукціон у разі підтвердження або дискваліфікації учасників, які не пройшли кваліфікацію (всі Awards у статусі active, unsuccessful, cancelled). Після завершення роботи із договором з кожним переможцем, Замовник аукціону натискає на кнопку “Завершити аукціон”. Після чого процедура змінює статус на complete.

Зміни, які необхідно внести в процедуру:

accessDetails - зробити НЕ обовʼязкове поле (зараз обовʼязкове, хоча я не бачу в Постанові нічого про "Порядок та можливий час ознайомлення з лотом")

x_additionalInformation - зробити НЕ обовʼязкове поле (зараз обовʼязкове, хоча я не бачу в Постанові нічого про те, що треба ОБОВʼЯЗКОВО надавати "Додаткові відомості". Навпаки: "Оголошення про проведення аукціону може містити інші відомості, необхідні для його проведення")

bankAccounts - переробити під bankAccounts (basicSell.BankAccountsByType) з двума accountType (payment, other). bankAccount з accountType == payment ОБОВʼЯЗКОВИЙ (банківські реквізити оператора авторизованого електронного майданчика для сплати переможцем винагороди.)

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 (що це ?)

Архів