You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 68 Next »


Посилання:

Голосарій

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

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

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

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

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

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

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

Цінова пропозиція - ціна продажу 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. Параметр НЕ обовʼязковий до заповнення. Організатор може вказати "Області, у яких розподіляється обсяг лота"
  • 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 к.д. 

Верхню - не обмежуємо

23. Аукціон проводиться не раніше ніж через 30 днів, але не пізніше ніж через 90 днів після опублікування оголошення про проведення аукціону.

Момент завершення роботи модуля аукціону

Статус процедури змінюється:

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.endDatequalificationPeriod.endDate == qualificationPeriod.startDate + 29 р.д. о 18:00

На рівні ЦБД: відсутній

На рівні майданчика: за 24 години до завершення, надсилання повідомлення Організатору про завершення періоду кваліфікації. 

зараз має назву waitingPeriod, перейменувати


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


Технічна назваБізнесова назваПерехід зЗа умовиКоментар
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). 

Аварди в статусі unsuccessful свій статус не змінюють.

В момент переходу процедури у статус active_qualification, ЦБД розраховує значення поля x_quantityLimit - це 80% від суми awards.quantity всіх Авардів, які на момент зміни статуса процедури на active_qualification отримали Awards.status <> unsuccessful

Тобто, x_quantityLimit включає в себе 80% від quantity тільки тих Авардів, які успішно пройшли перевірку документів АБО Організатор не виконав дій, що вказують на успішну перевірку документів Учасника. І не включає quantity Авардів, які явно не пройшли перевірку документів і мали статус unsuccessful

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


Якщо Організатор надіслав запит на зміну статуса процедури, то verificationPeriod.endDate в API не змінюється.

completeАукціон завершеноactive_qualification

Ручна дія.

Організатор надсилає запит на зміну status: active_qualification → complete

Термінальний статус.

При виконанні дії зміни статуса на complete ЦБД перевіряє:

  • Всі contracts[] мають статус active або unsuccessful (має бути хочаб один contract у статусі active)
  • Всі Awards[] мають бути у статусі active, cancelled чи unsuccessful (має бути хоча б один award у статусі active)
unsuccessfulАукціон не відбувся

active_tendering

qualification

active_qualification

Автоматично.

  • Якщо на момент tenderPeriod.endDate подано менше 2-х заяв на участь;
  • Якщо в рамках кваліфікації Замовник дискваліфікував усіх учасників.
    • Жоден учасник не пройшов етап перевірки документів
    • Дискваліфіковані всі учасники на етапі підписання Протоколів і Договорів

Термінальний статус.

cancelled

Аукціон скасовано

active_rectification

active_tendering

qualification

active_qualification

Ручна дія.

Організатору у всіх статусах Процедури, окрім active_auction, доступна опція "Скасування" Процедури.

Для скасування процедури, Організатору необхідно:

  • Завантажити документ в cancellations[].documents з documentType: cancellationDetails
  • Вказати причину скасування (cancellations.reason) довільним текстом ЧИ зробимо словник? (зараз робимо опцію вибора із словника renewablesCancellationReason
    • 36. Гарантований покупець має право відмінити аукціон до моменту його завершення в разі:

      • скасування, втрати чинності або внесення змін до рішення Кабінету Міністрів України про проведення аукціонів у відповідному році;
      • виникнення непередбачуваних технічних чи програмних неполадок, що унеможливлюють роботу електронної торгової системи та проведення аукціону, на підставі інформації адміністратора електронної торгової системи.
  • Вказати дату прийняття рішення про скасування (cancellations.datePublished)

Після цього, при натисканні кнопки, надсилається запит на скасування. Статус процедури автоматично змінюється → cancelled

Термінальний статус.

Для зміни статусу процедури на “Аукціон відмінено” Організатор зобов’язаний в особистому кабінеті натиснути кнопку “Скасувати аукціон”, завантажити документ з причинами скасування, вказати причину скасування, після чого майданчик надсилає запит до ЦБД на зміну статусу процедури на “Аукціон відмінено”.

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

documentTypeНазва УкрНазва АнгОпис

Обовʼязковіть для публікації процедури

Публічність
illustrationІлюстраціїIllustrationЗображення, що можуть додаватися Організатором до процедуриНіТак
technicalSpecificationsТехнічні специфікаціїTechnical specificationsТехнічні параметри об’єкта електроенергетикиНіТак
evaluationCriteriaКваліфікаційні вимогиEvaluation criteriaПерелік документів, необхідних для участі в аукціоні, та вимоги до їх оформленняТакТак
contractProformaТипова форма договору про надання послугиContract proformaТипова форма договору про надання послугиТакТак
x_lotInfoENДокумент, що містить оголошення англійською мовоюAnnouncements in EnglishДокумент, що містить оголошення англійською мовою

Так

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

Так
x_verificationActАкт про результати перевірки документів учасниківVerification actЗагальний акт про результати перевірки документів усіх учасників, в якому зазначається перелік учасників, що успішно пройшли перевірку, і тих, що втратили статус учасника

Ні *

* має бути можливість завантажити документ коли procedure.status: qualification або active_qualification

"гарантований покупець складає та оприлюднює загальний акт про результати перевірки документів усіх учасників, в якому зазначає перелік учасників, що успішно пройшли перевірку, і тих, що втратили статус учасника"


Так
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-а процедури.

Мають бути заповнені:

  • value
  • quantity
  • bidders

Опублікувати бід можна без документів, але без обовʼязкових документів не буде можливості активувати Біда.

activeПідтверджена заяваdraft

Ручна дія.

Учасник надсилає запит на зміну статуса Bid-а

Мають бути заповнені обовʼязкові поля:

  • value
  • quantity
  • bidders

та обовʼязкові документи

deletedВидалена заяваactive

Ручна дія.

Учасник надсилає запит на зміну статуса Bid-а

Скасувати свою заявку на участь є можливість тільки протягом tenderPeriod

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

documentTypeНазва УкрНазва АнгОпис

Обовʼязковіть для активації bid-а

Публічність
x_guaranteeФінансове забезпеченняFinancial supportБанківська гарантія для участі в аукціоні, надана на користь гарантованого покупцяТакТак
х_ultimateBeneficiaryInfoІнформація про кінцевого бенефіціарного власникаUltimate beneficiary informationІнформація про кінцевого бенефіціарного власника. У разі коли особа не має кінцевого бенефіціарного власника, зазначається інформація про відсутність кінцевого бенефіціарного власника та причина його відсутностіТакТак
 x_governingBodyInfoІнформація про органи управлінняGoverning bodies informationКопії документів, що містять інформацію про органи управління учасника, який має намір взяти участь в аукціоні, та їх персональний склад (статут, протоколи, накази, інші документи, що містять інформацію про органи управління та їх персональний склад)НіТак
 x_relatedPartiesІнформація про пов'язаних осібRelated parties informationІнформацію про осіб, пов’язаних із учасником, який має намір взяти участь в аукціоні, відносинами щодо здійснення контролюНіТак
 x_generationTypeДовідка із зазначенням виду альтернативного джерела енергіїGeneration type certificateУ разі участі в технологічно нейтральному аукціоні довідку в довільній формі, підписану уповноваженою особою суб’єкта господарювання, із зазначенням виду альтернативного джерела енергії, щодо якого він має намір набути право на підтримкуНіТак
eligibilityDocumentsІнформація щодо технічних параметрів (характеристик) установки Eligibility documentІнформація щодо технічних параметрів (характеристик) установки зберігання енергії (встановлена потужність, ємність, інші параметри)НіТак
digitalSignatureЦифровий підписDigital signatureЦифровий підписНіТак


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

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

За результатами періоду аукціону (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

Зараз, якщо Умовний переможець протягом 5р.д. не дає відповіді, то він автоматично відмовляється. Залишаємо? - ТАК (повʼязано з банківською гарантією)


Період формується для Авардів у статусі 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 → unsuccessful (обовʼязково попередньо завантажує та може замінити документ 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

У разі коли після 29 робочих днів з дати завершення аукціону переможець або гарантований покупець відмовляються від підписання протоколу про результати аукціону або договору про надання послуги відповідно до вимог цього Порядку, визначення нових переможців не проводиться.

АБО

Ручна дія.

pending_admission → pending: Учасник погодився закрити залишок обсягу


Перехід із waiting:

Статус pending отримують Аварди, які перебувають перші у списку результатів Модуля Аукціону і які успішно пройшли етап перевірки документів (award.status <> unsuccessful) за умови, що обсяг, який вони запропонували повністю покривається розрахованим значенням x_quantityLimit

Організатор має можливість:

    • Завантажити і замінити awards.document: documentType: auctionProtocol (обов'язкова дія для подальшої зміни статуса Аварда на protocol_signed)
    • Змінити Awards.status: pending → protocol_signed
    • Змінити Awards.status: pending → unsuccessful

Учасник має можливість завантажити та замінити протокол awards.document: documentType: auctionProtocol


Перехід із pending_waiting:

Лише у випадку, якщо Організатор дискваліфікував одного чи більше Переможців, Аварди, що перебувають у статусі pending_waiting автоматино можуть змінити свій статус на pending за умови, що обсяг, який вони запропонували повністю покривається залишком від обсягу, що залишився і не настала дата qualificationPeriod.endDate. Якщо завершився qualificationPeriod і після 29 р.д. Організатор дискваліфіковує переможця, наступний у черзі, який очікує вже НЕ отримує статус pending (на 30-й день вже не має бути Авардів у статусі pending_waiting, бо визначено одного, хто змінив свій статус на pending_admission, а всі інші змінили свій статус на cancelled)

У разі коли після 29 робочих днів з дати завершення аукціону переможець або гарантований покупець відмовляються від підписання протоколу про результати аукціону або договору про надання послуги відповідно до вимог цього Порядку, визначення нових переможців не проводиться.


Приклад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 <> unsuccessful) за умови, що обсяг, який вони запропонували повністю НЕ покривається розрахованим значенням x_quantityLimit, з причини, що обсяг вже закритий іншими пропозиціями учасників, що запропонували меншу ціну.


Приклад 1:

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

Учасник_1 запропонував awards.items.quantit  == 3 000 по найменшій ціні 10

Учасник_2 запропонував awards.items.quantit  ==  1 000 по ціні 11

Учасник_3 запропонував awards.items.quantit  ==  2 000 по ціні 12

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

ЦБД розраховує x_quantityLimit == (3000 + 1 000 + 2 000) * 0.8 == 4 800

Обсяг 4 800 повністю покриває тільки запропоновані обсяги Учасника_1 і Учасника_2. Запропонований Учасником_3 обсяг повнітю не реалізується (він запропонував 2 000, а після розподілення між першим і другим учасниками, залишилось не розподілено тільки (4 800 - 3 000 - 1 000) == 800 )

В даному прикладі тільки третій учасник отримує статус pending_waiting

Приклад 2:

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

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

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

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

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

ЦБД розраховує x_quantityLimit == (3000 + 1 000 + 2 000) * 0.8 == 4 800

Обсяг 4 800 повністю покриває тільки запропонований обсяг Учасника_1. Запропонований Учасником_2 обсяг повністю не реалізується (він запропонував 2 000, а після Учасника_1 , залишилось не розподілено тільки (4 800 - 3 000) == 1800 )

В даному прикладі другий і третій учасники отримують статус pending_waiting


Організатор не може дискваліфікувати Учасника, що очікує рішення

Учасник не має можливості відмовитись від очікування.

pending_admissionПідтвердження набуття статусу переможцяpending_waiting

Автоматично.

Завершився qualificationPeriod.endDate

АБО

Автоматично.

За умови, що всі Awards, що мали статус pending отримали статус active

(Організатор успішно кваліфікував всіх Переможців, залишилось вирішити питання тільки з залишком запропонованого обсягу, що може бути закритий "умовним переможцем")

АБО

Автоматично.

За умови, що взагалі відсутні Аварди у статусі pending

(це виключення описано тут)


Статус pending_admission отримує тільки один Award, який знаходиться у статусі pending_waiting і запропонував найменшу після Переможців ціну.

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

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

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

В момент отримання Авардом статусу pending_admission, всі інші Аварди, які перебувають у статусі pending_waiting отримують статус cancelled

(дискваліфікація Переможців вже неможлива, бо закриті протоколи+договори. Вибор іншого "умовного переможця" не передбачений в нормативці)

В цьому статусі Умовний переможець може:

  • вказати обсяг, на який учасник погоджується (обсяг має дорівнювати або бути меншим за нерозподілений залишок) і
  • надіслати запит на зміну Award.status: pending_admission → pending (підтвердити набуття статусу переможця)
  • Відмовитися від набуття статусу переможця - надіслати запит на Award.status: pending_admidssion →  cancelled
  • Бездіяльність умовного переможця протягом awards.admissionPeriod (принцип мовчазної відмови), автоматична зміна Award.status: pending_admidssion →  cancelled
activeДоговір підписаноprotocol_signed

Автоматично.

Якщо повʼязаний contracts набув статуса active

Термінальний статус.

Якщо змінився contracts.status: pending → active, це означає, що

завантажено Підписаний договір (contracts.documents.documentType: contractSigned)

Це потрібно для того, щоб за умови дискваліфікації Переможця на етапі підписання Договору, ЦБД зробила перевірку "qualificationPeriod.endDate вже пройшов?":

  • якщо НІ, то відпрацьовує логіка визначення переходу наступного Аварда із pending_waiting → pending і підписання протоколу і договору з наступним учасником.
  • якщо ТАК, то наступних у черзі Авардів не кваліфікуємо
cancelledУчасник не став переможцем

pending_admission

АБО

pending_waiting

із pending_admission:

Ручна дія.

Учасник ("Умовний переможець") відмовляється "закрити" нерозподілений залишок і надсилає запит на зміну статуса

АБО

Автоматично.

Якщо протягом awards.admissionPeriod учасник ("Умовний переможець") не надав відповіді


із pending_waiting:

Автоматично.

В момент, коли будь-який Авард набуває статусу pending_admission, всі інші Аварди, які знаходяться у статусі pending_waiting автоматично набувають статус cancelled

Термінальний статус.

Після набуття статусу pending_admission "Умовний переможець" має можливість відмовитись від запропонованого обсягу і скасувати свою заявку (змінити статус Аварда з pending_admission на cancelled).

Якщо протягом awards.admissionPeriod учасник ("Умовний переможець") не надав відповіді, то ЦБД автоматично змінює статус його Аварда.





Після набуття статусу pending_admission "Умовний переможець" всі Аварди, які на цей момент заходились у статусі pending_waiting набувають статус cancelled

unsuccessfulДискваліфіковано

verification

АБО

pending

АБО

protocol_signed

Ручна дія.

Організатор надсилає запит на зміну award.status:verification → unsuccessful

Організатор надсилає запит на зміну award.status: pending → unsuccessful

Автоматично.

Якщо статус повʼязаного contracts набуває статуса cancelled

Термінальний статус.

verification → unsuccessful: завантажується документ rejectionProtocol для кожного Аварда, який не пройшов перевірку документів протягом verificationPeriod

Поле terminationReason в даному випадку заповнювати не обовʼязково

pending → unsuccessful: ЦБД має валідувати, що в Авард завантажено документ з documentType: act

При зміні статуса з pending → unsuccessful ЦБД має валідувати, що заповнено awards.terminationReason значенням зі словника

protocol_signed → unsuccessful: terminationReason заповнюється автоматично варіантом "7" : "Відмова від підписання договору"

Документ act "про відмову" завантажується в contract.

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

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

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

ПРИКЛАДИ:

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

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

documentTypeНазва УкрНазва АнгОпис

Обовʼязковіть

Публічність
rejectionProtocolАкт про невідповідністьRejection protocol

Завантажується для кожного Аварда, який не пройшов перевірку документів протягом verificationPeriod

Поле terminationReason в даному випадку заповнювати не обовʼязково

Так

Для зміни awards.status: verification → unsuccessful

Так
auctionProtocolПротокол аукціонуAuction protocol

Протокол підписується і завантажується для кожного учасника окремо

"Гарантований покупець протягом двох робочих днів з дати оприлюднення протоколу про результати аукціону підписує протоколи про результати аукціону щодо кожного переможця"


Так

Для зміни awards.status: pending → protocol_signed


Так
actАкт про відмовуRefusal act

Завантажується у разі відмови Переможцем підписувати протокол.

Документ має бути можливість завантажити у Організатора та у Переможця.

Для того, щоб Організатор дискваліфікував учасника, Авард якого перебуває у статусі pending, має бути завантажено хоча б один документ з documentType: act 
В поле terminationReason аварду записується причина із довідника

Поле terminationReason має бути обов'язково заповнено для зміни awards.status: pending → unsuccessful

Так

Для зміни awards.status: pending → unsuccessful


Так
x_guaranteeФінансове забезпеченняFinancial support

Банківська гарантія для участі в аукціоні, надана на користь гарантованого покупця.

При підписанні протоколу може виникнути потреба в завантаженні оновленої банківської гарантії.

НіТак
digitalSignatureЦифровий підписDigital signatureЦифровий підписНіТак

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

Статуси Contracts

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

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


Технічна назваБізнесова назваПерехід зЗа умовиКоментар
pendingОчікується договірМомент створення Awards[] у статусі pending

Автоматично.

Якщо будь-який Авард набуває статусу protocol_signed, то ЦБД автоматично створює повʼязаний contracts у статусі pending.

Через те, що розподіл нерозподіленого залишку згідно Постанови може відбуватися ПІСЛЯ підписання протоколу, за умови, що дискваліфікували Учасника на етапі підписання Договору,

contracts створюються не після того, як Award набув статусу active, а як тільки Award набув статус protocol_signed

activeДоговір підтвердженоpending

Ручна дія.

Організатор завантажує документ contracts[x].documents.documentType: contractSigned і після цього надсилає запит на зміну contracts.status: pending → active

Повʼязаний Авард має бути у статусі protocol_signed.

З технічної сторони, договір вважається підписаним і закритим, коли Організатор змінює contracts.status: pending → active + ЦБД автоматично змінює статус повʼязаного Аварду protocol_signed → active.

cancelledДоговір скасованоpending

Ручна дія.

Організатор надсилає запит на зміну contracts.status: pending → cancelled

Має бути завантажено документ contracts.documents.documentType: act

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


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

documentTypeНазва УкрНазва АнгОпис

Обовʼязковіть

Публічність
contractSignedПідписаний договірSigned contract

Завантажується для кожного Переможця з ким підписано договір

Так

Для зміни contracts.status: pending → active

Так
contractAnnexeДодатки до договоруContract annexe

Додатки до договору

Ні

Так
contractNoticeПовідомлення про договірContract notice

Повідомлення про договір

Ні


Так
actАкт про відмовуRefusal act

Завантажується у разі відмови Переможцем підписувати договір.

Документ має бути можливість завантажити у Організатора та у Переможця.

Для того, щоб Організатор дискваліфікував учасника, contracts якого перебуває у статусі pending, має бути завантажено документ з documentType: act

Так

Для зміни contracts.status: pending → unsuccessful

Так
digitalSignatureЦифровий підписDigital signatureЦифровий підписНіТак

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

Завершення аукціону (переведення у статус 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 (що це ?)



Архів


renewables.RenewablesMultiAwardsProcedure  typereadOnlyx-legalNameUax-legalNameEnpatternКоментар
owner  stringtrueІдентифікатор майданчикаBroker identifier

ownerToken

string($uuid)true



_id

stringtrueВнутрішній ідентифікатор аукціонуID

datePublished  string($date-time)trueДата публікації процедуриPublished date

dateModified  string($date-time)trueОстання дата зміни процедуриProcedure date modified

auctionId  stringtrueІдентифікатор аукціонуAuction ID

previousAuctionId  string
Номер попереднього аукціонуPrevious auction Id^(RM[a-zA-Z][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



schemestring
Тип ідентифікації Замовника аукціону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 - обовʼязково для публікації процедури


postalCodestring
Поштовий індексZIP code
pattern: ^[0-9]{5}$

representativeInfo 

Інформація щодо підтвердження повноваженьRepresentative information


contactPoint 

model

base.ContactPoint








name

model

base.multiLang


ПІБMain contact name
uk_UA - обовʼязково для публікації процедури


emailstring($email)
Адреса електронної пошти
Main contact e-mail
обовʼязково для публікації процедури


telephonestring
Номер телефонуPhone number
обовʼязково для публікації процедури


faxNumberstring
Номер факсуFax number



urlstring($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
 






ВИДАЛЯЄМО
bankAccounts
 






 


  • No labels