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