Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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Цифровий підписНіТак

...

draw.io Diagram
bordertrue
diagramNamerenewables awards statuses
simpleViewerfalse
width
linksauto
tbstyletop
lboxtrue
diagramWidth12801240
revision910

Технічна назваБізнесова назваПерехід зЗа умовиКоментар
verificationПеревірка документівМомент auctionPeriod.endDate створюються Awards[]

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

По завершенню аукціону, процедура переходить у статус qualification ("Перевірка документів"). ЦБД генерує Awards[] у статусі verification для всіх учасників.

Anchor
queue
queue
За результатами роботи МА (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

Expand
titleіз Постанови

У разі коли після 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)

Expand
titleіз Постанови

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


Anchor
example_1
example_1
Приклад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Організатор надсилає запит на зміну статуса Аварда protocol_signed → unsuccessful

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

verification → unsuccessful:

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

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

pending → unsuccessful:

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

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

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

При зміні статуса з protocol_signed → unsuccessful Організатору необхідно заповнити поле terminationReason значенням зі словника

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

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

...

Результат: 4800 повністю закритий Учасником_1 у розмірі 3000, Учасником_2 у розмірі 1000, Учасником_3 у розмірі 800. Паралельно з цим відбувається процес підписання Договорів.

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

...

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

...

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

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

...

Так

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

...

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

Expand
titleіз Постанови

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

Так

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

...

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

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

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

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

Так

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

...

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

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

...

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

...

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

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

...

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

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

...

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

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

...

Ручна дія.

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

...

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

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



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

Приклад 5:

  • Організатор вказав Обсяг == 10000
  • Організатор вказав Макс ціну == 12

Прийшло три Учасника:

Учасник_1:

  • Обсяг пропозиції == 6000
  • Ціна пропозиції == 10

Учасник_2:

  • Обсяг пропозиції == 4000
  • Ціна пропозиції == 11


Обидва учасники успішно пройшли перевірку документів і отримали статус Аварда waiting

ЦБД розрахувала x_quantityLimit == (6000 + 4000) * 0,8 == 8000

ЦБД розподіляє Обсяги пропозицій учасників:

Учасник_1:

8000 - 6000 = 2000

В даному прикладі Обсяг пропозиції Учасника_1 покривається x_quantityLimit

Учасник_1 отримує статус pending

Учасник_2:

2000 - 4000 <0

В даному прикладі Обсяг пропозиції Учасника_2 НЕ покривається x_quantityLimit, бо після Учасника_1 залишився нерозподілений залишок 2000, а Обсяг пропозиції Учасника_2 - більший, дорівнює 4000

Протягом qualificationPeriod (29 р.д.) Організатор був бездіяльним і НЕ дискваліфікував Учасника_1 і НЕ кваліфікував успішно.

На 30 р.д. визначається "Умовний переможець" і Учасник_2 набуває статусу pending_admission. Йому пропонується закрити нерозподілений залишок, який становить 2000.

Тобто, те, що з Учасником_1 не завершено кваліфікацію, не впливає на визначення обсягу "нерозподіленого залишку"

Учасник_2 погоджується закрити 2000.

Після цього:

Організатор успішно кваліфікує Учасника_1 і його Авард отримує статус protocol_signed, підписують договір

Організатор успішно кваліфікує Учасника_2 і його Авард отримує статус protocol_signed, підписують договір

Результат: 8000 закритий Учасником_1 у розмірі 6000, Учасником_2 у розмірі 2000

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

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

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

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

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

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

Так

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

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

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

Expand
titleіз Постанови

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


Так

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

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

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

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

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

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

Так

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

Так

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

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

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

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

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

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

Anchor
contract_statuses
contract_statuses
Статуси Contracts

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

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


draw.io Diagram
bordertrue
diagramNamecontracts_statuses_renewables
simpleViewerfalse
width
linksauto
tbstyletop
lboxtrue
diagramWidth437
revision2

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

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

За умови дискваліфікації Аварда із protocol_signed → unsuccessful

Для того, щоб дискваліфікувати Учасника з причини того, що НЕ підписано договір, необхідно надіслати запит на зміну статуса Аварда protocol_signed → unsuccessful

Expand
titleіз Постанови

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


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

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

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

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

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

Так

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

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

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

Ні

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

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

Ні


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

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

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

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



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

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-legalNameEnКоментар
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 Idpattern: ^(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:[Україна]

...

Ручна дія.

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

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

Expand
titleіз Постанови

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

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

...

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

...

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

...

Так

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

...

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

...

Ні

...

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

Ні

...

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

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

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

...

Так

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

...

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

Завершення аукціону (переведення у статус 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-legalNameEnКоментарowner  stringtrueІдентифікатор майданчикаBroker identifierownerTokenstring($uuid)true_idstringtrueВнутрішній ідентифікатор аукціонуIDdatePublished  string($date-time)trueДата публікації процедуриPublished datedateModified  string($date-time)trueОстання дата зміни процедуриProcedure date modifiedauctionId  stringtrueІдентифікатор аукціонуAuction IDpreviousAuctionId  stringНомер попереднього аукціонуPrevious auction Idpattern: ^(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 informationname

model

base.multiLang

Найменування Замовника аукціонуName of the auction customeridentifier

model

base.Identifier

Ідентифікатори Замовника аукціонуCustomer IDschemestringТип ідентифікації Замовника аукціонуCustomer ID type

Допустимі тільки значення зі словника

При публікації процедури обовʼязково заповнено

legalName

model

base.multiLang

Повна юридична назва організаціїLegal nameПри публікації процедури обовʼязково заповнено legalName.uk_UAidКод ЄДРПОУ або ІПН або паспорт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

Населений пунктLocalityuk_UA - обовʼязково для публікації процедуриstreetAddress

model

base.multiLang

АдресаAddressuk_UA - обовʼязково для публікації процедуриpostalCodestringПоштовий індексZIP codepattern: ^[0-9]{5}$representativeInfo Інформація щодо підтвердження повноваженьRepresentative informationcontactPoint 

model

base.ContactPoint

name

model

base.multiLang

ПІБMain contact name


uk_UA - обовʼязково для публікації процедури

emailstring($email)Адреса електронної пошти
Main contact e-mail


region

model

base.multiLang


ОбластьRegion

uk_UA = Enum:
[ Автономна Республіка Крим, Вінницька область, Волинська область, Дніпропетровська область, Донецька область, Житомирська область, Закарпатська область, Запорізька область, Івано-Франківська область, Київська область, Київ, Кіровоградська область, Луганська область, Львівська область, Миколаївська область, Одеська область, Полтавська область, Рівненська область, Севастополь, Сумська область, Тернопільська область, Харківська область, Херсонська область, Хмельницька область, Черкаська область, Чернівецька область, Чернігівська область ]

uk_UA - обовʼязково для публікації процедури

telephone


locality
stringНомер телефонуPhone number

model

base.multiLang


Населений пунктLocalityuk_UA - обовʼязково для публікації процедури
faxNumberstringНомер факсуFax numberurlstring($uri)Веб адресаWebsitex_verificationDocuments 


streetAddress

model

base.multiLang


АдресаAddressuk_UA - обовʼязково для публікації процедури


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

representativeInfo 

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

contactPoint 
list[]

model

base.

VerificationDocumentInfo

ContactPoint

Ліцензія






name
Business verification documents Expand
titleвід ГП
Просимо все ж таки залишити інформацію про ліцензію, оскільки в нормативно-правових документах не зазначається безпосередньо ДП "

model

base.multiLang


ПІБMain contact nameuk_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
Expand
titleвід ГП

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



 description

model

base.multiLang


Опис документаDocument description 

 id

string


Номер документаBusiness verification documents ID 

 date

string($date-time)


Дата видачі документаBusiness verification documents date 
lotId
 string
Номер лотуLot numberобовʼязково для публікації процедури
title
 

model

base.multiLang


Заголовок аукціону
uk_UA - обовʼязково для публікації процедури
description
 

model

base.multiLang


Опис аукціону
uk_UA - обовʼязково для публікації процедури
accessDetails
 





ВИДАЛЯЄМО
bankAccount
 

 




ВИДАЛЯЄМО

Expand
titleуточнено

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

Image Modified

x_documentRequirements

model

base.multiLang


Вимоги до оформлення документівDocument requirementsuk_UA - обовʼязково для публікації процедури
x_additionalInformation
 

model

base.multiLang


Додаткові відомостіOther requirements and additional informationНЕ ОБОВʼЯЗКОВЕ
x_quantityLimit
 

number($float)

true80% сукупної величини потужності учасників 80% limit 
value
 

model

ValueWithTax


Максимальна цінова пропозиціяMax bid value 
 currency 

string


ВалютаCurrency

Enum: [eurocent]

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

 amount 

number($float)


СумаAmount обовʼязково для публікації процедури
 valueAddedTaxIncluded 

boolean

trueПодатокTaxdefault: false
guarantee
 





ВИДАЛИТИ 

Expand
titleіз уточнень

має бути не в числовому форматі, а в описовому з можливістю прикриплення файлу з примірною формою банківської гарантії для участі в аукціоні. В описній частині наступне -Безвідклична банківська гарантія для участі в аукціоні у розмірі 5 євро за кожен кіловат потужності об’єкта електроенергетики, або черги (пускового комплексу) об’єкта електроенергетики, щодо якого учасник має намір набути право на підтримку, надану на користь гарантованого покупця.* *Банківська гарантія для участі в аукціоні має бути видана на строк, що становить не менше 50 робочих днів після дати проведення аукціону, вказаної в оголошенні про проведення аукціону +10 робочих днів для її повернення або виставлення вимоги. Примірна форма безвідкличної банківської гарантії для участі в аукціоні в додатку до оголошення


bankGuaranteeDetails
 

model

base.multiLang


Інформація щодо банківської гарантіїBank guarantee infoІнформація щодо банківської гарантії
minimalStep

model

base.Value

trueРозмір кроку аукціонуMinimal Step

 

 currency

string

trueВалютаCurrency

default: eurocent

 amount
number($float)trueСумаAmount

default: 0.01

minNumberOfQualifiedBids
 

integer($int64)

trueМінімальна кількість заяв учасниківMinimal number of bids

default: 2

tenderAttempts
 

integer($int64)


Лот виставляєтьсяAttempt number

default: 1

minimum: 1

items[]
 

list[]

model

renewables.Item


Склад лотаLot composition

МАЄ БУТИ МОЖЛИВІСТЬ ДОДАТИ ТІЛЬКИ ОДИН item В МАСИВ!
НЕ МОЖЕ БУТИ ДЕКІЛЬКА items

 id 

string

trueВнутрішній ідентифікатор обʼєктаItem ID

 

 description 

model

base.multiLang


Опис лотаItem description

uk_UA - обовʼязково для публікації процедури

 classification 

model

Classification


КласифікаторClassification

 

 
scheme

string

trueСхема класифікатораItem classification scheme

default: CAV

Автозаповнюється ЦБД при публікації процедури

 
description

model

base.multiLang

trueОпис коду классифікатораClassification ID

default:

"uk_UA": "Електрична, теплова, сонячна та атомна енергія",
"en_US": "Electricity, heating, solar and nuclear energy"

Автозаповнюється ЦБД при публікації процедури

 

 
id

string

trueКод классифікатораClassification ID

default: 09300000-2

Автозаповнюється ЦБД при публікації процедури

 unit 

model

base.Unit

trueОдиниці виміру обʼєктаItem unit

 

 
code

string

trueКод одиниці виміруUnit code

default: KWT

 
name

model

base.multiLang

trueНазва одиниці виміруItem unit name

default:

"uk_UA": "Кіловат-година",
"en_US": "kilowatt hour"

 quantity 

number($float)

 Розмір частки річної квотиItem quantity


 address 

 

 

ВИДАЛЯЄМО

 additionalClassifications[] 

list[]

model

AdditionalClassification

 Вид джерела енергіїType of energy source

МАЄ БУТИ МОЖЛИВІСТЬ ДОДАТИ ТІЛЬКИ ОДИН additionalClassification В МАСИВ!
НЕ МОЖЕ БУТИ ДЕКІЛЬКА additionalClassification в одному айтемі !

  scheme

string

 Схема додаткового класифікаторуItem additional classification schemeDict: generationType
   description

model

base.multiLang

 trueОпис додаткового класифікаторуItem additional classification description

 Автозаповнюється цз словника generationType згідно коду

   id

 string

 Код додаткового класифікатору
Item additional classification ID

 x-dictionaries: List [ "generationType" ]

 location 

model

base.Location

   

 

 documents[]  

model

base.Documents

   

documentOf: auction

documentType: illustration, technicalSpecifications, evaluationCriteria, contractProforma, x_lotInfoEN, x_verificationAct, clarifications, digitalSignature

 bids[]  

model

renewables.Bid

 Заява на участь Bid

 

 owner 

string

 trueІдентифікатор майданчика Broker ID

 

 ownerToken 

string($uuid)

 true  

 

 id 

string

 trueІдентифікатор заяви на часть Bid ID

 

 bidders
bankGuaranteeDetails 

model

bankGuaranteeDetails

Інформація щодо банківської гарантії description 

model

base.multiLang

ОписDescription documents
[] 

model

base.

Document

documentOf: bankGuaranteeDetails

documentType: bankGuaranteeExample

Organization

 Інформація учасника Bidder info

 

  name
minimalStep

model

base.

Value

multiLang

true
Розмір кроку аукціону
Повна юридична назва організації або ПІБLegal name or Full Name

Автозаповнюється автоматично із identifier.legalName.*

Minimal Step

  
currency
identifier
string

model

true

base.Identifier

ВалютаCurrency

default: eurocent

 amountnumber($float)trueСумаAmount

default: 0.01

minNumberOfQualifiedBids 

integer($int64)

trueМінімальна кількість заяв учасниківMinimal number of bids

default: 2

tenderAttempts 

integer($int64)

Лот виставляєтьсяAttempt number

default: 1

minimum: 1

items[] 

list[]

model

renewables.Item

Склад лотаLot composition

МАЄ БУТИ МОЖЛИВІСТЬ ДОДАТИ ТІЛЬКИ ОДИН item В МАСИВ!
НЕ МОЖЕ БУТИ ДЕКІЛЬКА items

 id 

string

trueВнутрішній ідентифікатор обʼєктаItem ID

 

 description 

model

base.multiLang

Опис лотаItem description

uk_UA - обовʼязково для публікації процедури

 classification 

model

Classification

КласифікаторClassification

 

 scheme

string

trueСхема класифікатораItem classification scheme

default: CAV

Автозаповнюється ЦБД при публікації процедури

 description

model

base.multiLang

trueОпис коду классифікатораClassification ID

default:

"uk_UA": "Електрична, теплова, сонячна та атомна енергія",
"en_US": "Electricity, heating, solar and nuclear energy"

Автозаповнюється ЦБД при публікації процедури

 

 id

string

trueКод классифікатораClassification ID

default: 09300000-2

Автозаповнюється ЦБД при публікації процедури

 unit 

model

base.Unit

trueОдиниці виміру обʼєктаItem unit

 

 code

string

trueКод одиниці виміруUnit code

default: KWT

 name

model

base.multiLang

trueНазва одиниці виміруItem unit name

default:

"uk_UA": "Кіловат-година",
"en_US": "kilowatt hour"

 Ідентифікатори організації або особиIdentifier

scheme*

string
x-dictionaries: List [ "identifiers", "ua_identifiers" ]

x-legalNameUa: Ідентифікатори організації

x-legalNameEn: ID type

Обирається одне значення зі словників:
https://procedure-sandbox.prozorro.sale/api/classifiers/identifiers
https://procedure-sandbox.prozorro.sale/api/classifiers/ua_identifiers

legalName*

model

base.MultiLang

id*

string
x-legalNameUa: Код ЄДРПОУ або ІПН або паспорт

x-legalNameEn: ID

  address

model

anyOf -> base.Address

OR baseAddressUa

 АдресаAddress

Обовʼязкові для публікації біда поля:

countryName

region

locality

streetAddress

  representativeInfo

string

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

model

base.ContactPoint

 Контактна особаMain contact

Обовʼязкові для публікації біда поля:

name

email

telephone

 datePublished string($date-time) trueДата заяви на участь Bid date

 

 dateModified 

 string($date-time)

 trueОстання дата редагування ставкиBid modified date

 

 status 

 string

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

 Enum:[draft, active, deleted]

 value 

model

Value

 Цінова пропозиція за 1 кВт*годPrice per 1 kW·h

 

  currency

string

 ВалютаCurrency

Enum:[eurocent]

  amountnumber($float) СумаAmount

 

 documents[]

 

model

base.Documents

 Документи до заяви про участьBid documents

documentOf: bid

documentType: x_guarantee, х_ultimateBeneficiaryInfo, x_governingBodyInfo, x_relatedParties, x_generationType, eligibilityDocuments, digitalSignature

 participationUrl 

 string

 trueВеб-адреса для участі в аукціоніBidder participation link

 

 order

  integer($int64)

 true  

 

 classification[]



  

ВИДАЛИТИ

 additionalClassifications[]



  

ВИДАЛИТИ

 unit 

model

Unit

   

 

  code

string

trueКод одиниці виміруUnit code

default: KWT

  name

model

base.multiLang

trueНазва одиниці виміруItem unit name

default:

"uk_UA": "Кіловат-година",
"en_US": "kilowatt hour"

 quantity 

 number($float)

 Розмір частки квоти в заяві Bid quantity

 

 qualified 

 

   

 ВИДАЛИТИ

 initialValueAmount 

 number($float)

 trueПочаткова ставкаStart bid amount

 

questions
 quantity 

number($float)

 Розмір частки річної квотиItem quantity address 

 

 

ВИДАЛЯЄМО

 additionalClassifications[] 

list[]

model

AdditionalClassification

 Вид джерела енергіїType of energy source

МАЄ БУТИ МОЖЛИВІСТЬ ДОДАТИ ТІЛЬКИ ОДИН additionalClassification В МАСИВ!
НЕ МОЖЕ БУТИ ДЕКІЛЬКА additionalClassification в одному айтемі !

  scheme

string

 Схема додаткового класифікаторуItem additional classification schemeDict: generationType   description

model

base.multiLang

 trueОпис додаткового класифікаторуItem additional classification description

 Автозаповнюється цз словника generationType згідно коду

   id

 string

 Код додаткового класифікатору
Item additional classification ID

 x-dictionaries: List [ "generationType" ]

 location 

model

base.Location

   

 

 documents[]  

model

base.Documents

   

documentOf: auction

documentType: illustration, technicalSpecifications, evaluationCriteria, contractProforma, x_lotInfoEN, x_verificationAct, clarifications, digitalSignature

 bids
[]  

model

renewables

base.

Bid

Questions

 
Заява на участь
Запитання до аукціонуQ&A
 Bid

 

awards[] 
owner
 
string

model

 
true
Ідентифікатор майданчика
Обʼєкт кваліфікаціїAward
 Broker ID

 

 
ownerToken
id 
string($uuid)

 

true

   

 

id
 
string
title 
true
Ідентифікатор заяви на часть Bid ID

 

 
bidders[]
 

model

base.Organization
 
Інформація учасника Bidder info

 

 
datePublished
description 

 

   

 

 
dateModified
status 

 

   

 

 
status
terminationReason 

 

   

 

 
value
datePublished 

 

   

 

 
documents[]
value 

 

   

 

 
participationUrl
buyers[] 

 

   

 

 
order
items[] 

 

   

 

 
classification
documents[] 

 

ВИДАЛИТИ
  
additionalClassifications[]
 

 

ВИДАЛИТИ

 
unit
dateModified 

 

   

 

 
quantity
bidId 

 

   

 

 
qualified
signingPeriod 

 

   

 

 
initialValueAmount
admissionPeriod