Page History

...

1. На етапі публікації Процедури:
   • в одній процедурі може бути тільки один item
   • після публікації Організатор має можливість редагувати процедуру під час tenderPeriod. Редагування певних полів призводить до деактивації заяв на участь.
   • Організатор на етапі публікації вказує:
     • Обсяг, який реалізується
     • Мінімальну ціну на одиницю обсягу, яку приймає ЦБД в заявах на участь
     • Мінімальний обсяг, який може викупити учасник
2. На етапі подання заяв на участь:
   
   • учасник може подати тільки одну заяву на участь в одному аукціоні
   • учасник в заяві на участь вказує бажану кількість обсягу активу та ціну за одиницю обсягу
3. Аукціон:
   
   • аукціон продажу частинами
4. Кваліфікація:
   • кількість переможців необмежена
   • наявність необмеженої кількості учасників, що кваліфікуються
   • можливість учаснику, що очікує викупити нерозподілений залишок, який має бути не менше, ніж Мінімальний обсяг, який вказав Організатор.

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

• Під час публікації процедури з запиті необхідно передати для item:

  • Обовʼязковий Основний класифікатор - CAV

    • на рівні ЦБД можливість обрати:
      • 03000000-1 Сільськогосподарська, фермерська продукція, продукція рибальства, лісівництва та супутня продукція та всі вкладені коди
      • 09000000-3 Нафтопродукти, паливо, електроенергія та інші джерела енергії та всі вкладені коди
      • 14000000-1 Гірнича продукція, неблагородні метали та супутня продукція та всі вкладені коди
      • 15000000-8 Продукти харчування, напої, тютюн та супутня продукція та всі вкладені коди
      • 18000000-9 Одяг, взуття, сумки та аксесуари та всі вкладені коди
      • 19000000-6 Шкіряні та текстильні, пластмасові та гумові матеріали та всі вкладені коди
      • 22000000-0 Друкована та супутня продукція та всі вкладені коди
      • 24000000-4 Хімічна продукція та всі вкладені коди
      • 30000000-9 Офісна та комп’ютерна техніка, устаткування та приладдя, крім меблів та пакетів програмного забезпечення та всі вкладені коди
      • 44000000-0 Конструкції та конструкційні матеріали; допоміжна будівельна продукція (крім електроапаратури) та всі вкладені коди
  •  Не обовʼязковий Додаткові класифікатори - CPVS, CVZU

...

...

У Організатора є можливість скасувати процедуру в будь-якому НЕ термінальному статусі процедури (active_tendering, active_auction, active_qualification, active_awarded).

Для скасування Організатор має:

...

...

По завершенню аукціону, процедура переходить у статус active_qualification. ЦБД генерує award'и Awards[] у статусі pending для N учасників у статусі pending .

Award'и формуються Awards[] формується для всіх учасників, відповідно до поданих кількості заяв на участь. Валідною ставкою вважається та, що рівна або більша за значення value.amount.

...

...

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

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

Порядок розміщення Авардів важливий!

Логіка формування порядку Awards:

За результатами роботи МА (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 протягом МА. Їх порядок має бути згідно часу оновлення їх ставок.

Сформовані Аварди ЦБД розподіляє по статусам pending або pending_waiting за наступною логікою:

1. Перевіряється Авард з найбільшим value (запропонував найбільшу ціну), береться awards[0].items[0].quantity і віднімається від procedure.items[0].quantity.
2. Результат різниці двох числе зберігається на беку
3. Перевіряється наступний Авард, який запропонував другу за величиною ціну, береться awards[1].items[0].quantity і віднімається від отриманого в попередньому кроці числа
   • Якщо результатом другого віднімання є відʼємне число, то цей Авард отримує статус pending_waiting і всі наступні Аварди також отримують цей статус
   • Якщо результатом другого віднімання є 0 або додатнє число, то цей Авард отримує статус pending також
4. Перевіряється третій Авард і виконуються дії описані в п.3

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

Приклади

Для кожного Аварда, який отримав статус pending ЦБД генерується протокол.

Одночасно з завершенням роботи МА починається qualificationPeriod в процедурі, який триває 20 р.д. а також у Авардів, які отримали статус pending починається awards.verificationPeriod, який триває 6 р.д.

Протягом qualificationPeriod Організатор має кваліфікувати учасника, завантажити підписаний протокол в Авард і змінити Awards[].status: pending → active

АБО

дискваліфікувати учасника, завантажити в Авард документ rejectionProtocol АБО act та змінити Awards[].status: pending → unsuccessful

У випадку, коли завершився qualificationPeriod, але з учасниками не підписано Протокол та\чи Договір, ніяких автоматичних змін у статусі процедури чи Авардів, які мають статус pending НЕ відбувається.

Організатор може дискваліфікувати тільки Авард у статусі pending і не може дискваліфікувати Авард у статусі pending_waiting

Якщо Організатор дискваліфікує Авард, ЦБД має виконати перевірку:

• Чи ще триває qualificationPeriod?
  • якщо "так", то для першого у списку Аварду у статусі pending_waiting відбувається перевірка:
    • Якщо обсяг першого у списку Аварду у статусі pending_waiting дорівнює чи менше нерозподіленого залишку, то цей Авард автоматично змінює свій статус на pending. Приклади тут
• Якщо обсяг першого в порядку Аварду у статусі pending_waiting більше нерозподіленого залишку, то Авард залишається в статусі pending_waiting. Приклади тут

Кваліфікація Авардів продовжується поки не залишиться жодного Аварда у статусі pending.

Всі Аварди, що отримували статус pending мають бути АБО кваліфіковані (отримати статус active), АБО дискваліфіковані (отримати статус unsuccessful).

Як тільки всі Аварди, що мали статус pending змінили свій статус, Авард, що має статус pending_waiting і знаходиться перший у списку, отримує статус pending_admission ("Умовний переможець")

Власнику Аварда у статусі pending_admission має бути доступна можливість надіслати запит, в якому вказати обсяг, на який він погоджується і готовий купити (quantity), але цей обсяг не може бути менше procedure.minimalPart і більше за нерозподілений залишок.

Якщо обсяг поза діапазоном, то ЦБД надсилає валідаційну помилку.

Після цього "Умовний переможець" має надіслати запит на зміну статуса Аварда pending_admission → pending

Організатор кваліфікує цей Авард і змінює його статус на active, або дискваліфікує і змінює статус на unsuccessful.

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

...

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

Коли з учасником успішно підписано протокол і Award набуває статусу active, ЦБД автоматично генерує для цього учасника повʼязаний Contract у статусі pending

В процедурі з кількома переможцями одночасно може бути декілька Contracts[] у статусі pending

Періоди у contracts[] відсутні

Anchor
contract_statuses contract_statuses

Статуси Contracts

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

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

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

Порядок розміщення Авардів важливий!

Логіка формування порядку Awards:

За результатами роботи МА (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 протягом МА. Їх порядок має бути згідно часу оновлення їх ставок.

Сформовані Аварди ЦБД розподіляє по статусам pending або pending_waiting за наступною логікою:

1. Перевіряється Авард з найбільшим value (запропонував найбільшу ціну), береться awards[0].items[0].quantity і віднімається від procedure.items[0].quantity.
2. Результат різниці двох чисел - нерозподілений залишок
3. Перевіряється наступний Авард, який запропонував другу за величиною ціну, береться awards[1].items[0].quantity і віднімається від отриманого нерозподіленого залишку
   • Якщо результатом другого віднімання є відʼємне число, то цей Авард отримує статус pending_waiting і всі наступні Аварди також отримують цей статус
   • Якщо результатом другого віднімання є 0 або додатнє число, то цей Авард отримує статус pending також
4. Перевіряється кожен Авард і виконуються дії описані в п.3

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

Приклади

Для кожного Аварда, який отримав статус pending ЦБД генерується протокол.

Одночасно з завершенням роботи МА починається qualificationPeriod в процедурі, який триває 20 р.д. а також у Авардів, які отримали статус pending починається awards.verificationPeriod і awards.signingPeriod

Протягом qualificationPeriod Організатор має кваліфікувати учасника:

• завантажити підписаний протокол в awards[] і змінити Awards[].status: pending → active
• завантажити підписаний договір в contracts[] і змінити Contracts[].status: pending → active

АБО

дискваліфікувати учасника, завантажити в Авард документ rejectionProtocol АБО act та змінити Awards[].status: pending → unsuccessful

У випадку, коли завершився qualificationPeriod, але з учасниками не підписано Протокол та\чи Договір, ніяких автоматичних змін у статусі процедури чи Авардів, які мають статус pending НЕ відбувається.

Організатор може дискваліфікувати тільки Авард у статусі pending і не може дискваліфікувати Авард у статусі pending_waiting

Якщо Організатор дискваліфікує Авард, ЦБД має виконати перевірку та із переліку учасників, що очікують (за їх наявності) перевести в кваліфікацію:

• Чи завершився qualificationPeriod.endDate?
  • якщо "ні", то для першого у списку Аварду у статусі pending_waiting відбувається перевірка:
    • Якщо обсяг першого у списку Аварду у статусі pending_waiting дорівнює чи менше нерозподіленого залишку ТА дорівнює чи більше Мін частки, що вказав Організатор при публікації, то цей Авард автоматично змінює свій статус на pending. 
    • Якщо обсяг першого у списку Аварду у статусі pending_waiting більше нерозподіленого залишку чи менше Мін частки, то Авард залишається в статусі pending_waiting.

Кваліфікація Авардів продовжується поки не залишиться жодного Аварда у статусі pending та Контракта у статусі pending

Всі Аварди, що отримували статус pending мають бути АБО кваліфіковані (отримати статус active), АБО дискваліфіковані (отримати статус unsuccessful).

Визначення умовного переможця

Умовний переможець визначається в двох випадках:

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

В момент завершення qualificationPeriod ЦБД має

• взяти першого у списку Award, який має статус pending_waiting
• перевірити чи нерозподілений залишок, який залишився після переможців > за Мінімальну частку, що вказав Організатор (procedure.minimalPart)
  • якщо ні, то цей Авард, а також всі інші, які мають статус pending_waiting отримують статус cancelled
  • якщо так, то цей Авард отримує статус pending_admission і разом з ним можливість погодитись і забрати нерозподілений залишок, а всі інші Аварди, які мали статус pending_waiting отримують статус cancelled

!!! Статус Авардів, що мають статус pending чи active не впливає на цей вибір

      2. Зі всіма переможцями підписано договір

ЦБД має враховувати скільки Авардів отримувало статус pending (ці Аварди ми називаємо "Переможцями") і якщо всі Переможці отримали статус Аварда active, а також у них у повʼязаних contracts[] має статус active, це означає, що зі всіма переможцями підписано протокол і договір.

В цей момент ЦБД із переліку Авардів, які мають статус pending_waiting, має забрати перший у переліку Авард та змінити Awards[].status: pending_waiting → pending_admission ("Умовний переможець")

Власнику Аварда у статусі pending_admission має бути доступна можливість надіслати запит, в якому вказати обсяг, на який він погоджується і готовий купити (quantity), але цей обсяг не може бути менше procedure.minimalPart і більше за нерозподілений залишок.

Якщо обсяг,що передає "Умовний переможець" поза діапазоном, то ЦБД повертає валідаційну помилку.

Після цього "Умовний переможець" має надіслати запит на зміну статуса Аварда pending_admission → pending

Організатор кваліфікує цей Авард і змінює його статус на active, або дискваліфікує і змінює статус на unsuccessful.

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

Для всіх Авардів, які отримали статус active ЦБД створює contract у статусі pending

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

АБО

Організатор має можливість дискваліфікувати переможця на етапі підписання договору. Для цього необхідно до повязаного Аварду завантажити документ awards[].documents.documentType: rejectionProtocol OR act, заповнити причину скасування та надіслати запит на зміну awards[].status: active → unsuccessful

При такій дискваліфікації, повʼязаний contract отримує статус cancelled автоматично.

Під час дискваліфікації ЦБД має виконати перевірку

• Чи завершився qualificationPeriod.endDate?
  • якщо "ні", то для першого у списку Аварду у статусі pending_waiting відбувається перевірка:
    • Якщо обсяг першого у списку Аварду у статусі pending_waiting дорівнює чи менше нерозподіленого залишку ТА дорівнює чи більше Мін частки, що вказав Організатор при публікації, то цей Авард автоматично змінює свій статус на pending.
    • Якщо обсяг першого у списку Аварду у статусі pending_waiting більше нерозподіленого залишку чи менше Мін частки, то Авард залишається в статусі pending_waiting.

Приклад 1:

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

Приклад 1:

• Організатор вказав Обсяг == 1000
• Організатор вказав Мін ціну == 100
• Організатор вказав Мін частку == 200

Прийшло три Учасника, за результатами МА:

Учасник_1:

• Обсяг бажаний == 200
• Фінальна ставка == 120

Учасник_2:

• Обсяг бажаний == 300
• Фінальна ставка == 110

Учасник_3:

• Обсяг бажаний == 400
• Фінальна ставка== 100

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

Учасник_1:

1000 - 200 = 800

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

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

Учасник_2:

800 - 300 = 500

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

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

Учасник_3:

500 - 400 = 100

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

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

Організатор кваліфікує віх трьох учасників і за умови успішної кваліфікації, буде реалізовано 200+300+400 = 900

Якщо когось із учасників буде дискваліфіковано, то реалізований обсяг буде менше, відповіно, на бажаний обсяг дискваліфікованого учасника.

Варто звернути увагу, що Організатор вказав "Мін частку" == 200. Відповідно, учасники не мали змогу подати заяву на участь з меншим бажаним обсягом ( <=200 ). В той самий час, учасники не могли подати заяву в якій вказати бажаний обсяг більше Обсягу вказаного організатором ( >= 1000 )

Результат: Організатор реалізував обсяг 900 трьом учасникам. Учасник_1 забрав частку 200, Учасник_2 забрав частку 300 і Учасник_3 забрав 400. У Організатора залишилось 100, які він може реалізувати в іншому аукціоні.

Приклад 2:

• Організатор вказав Обсяг == 1000
• Організатор вказав Мін ціну == 100
• Організатор вказав Мін частку == 200

Прийшло три Учасника, за результатами МА:

Учасник_1:

• Обсяг бажаний == 500
• Фінальна ставка == 120

Учасник_2:

• Обсяг бажаний == 400
• Фінальна ставка == 110

Учасник_3:

• Обсяг бажаний == 800
• Фінальна ставка== 100

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

Учасник_1:

1000 - 500 = 500

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

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

Учасник_2:

500 - 400 = 100

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

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

Учасник_3:

100 - 800 < 0

В даному прикладі Обсяг пропозиції Учасника_3 НЕ вміщається в обсяг продажу

Учасник_3 отримує статус pending_waiting

Організатор успішно кваліфікує Учасника_1 і його Авард отримує статус active, в ЦБД автоматично публікується Contract для Учасника_1 у статусі pending

Організатор успішно кваліфікує Учасника_2 і його Авард отримує статус active, в ЦБД автоматично публікується Contract для Учасника_1 у статусі pending

Авард Учасника_3 залишається в статусі pending_waiting та Contract для нього не створюється.

Організатор підписує договір з Учасник_1 і змінює статус Contracts[].status: pending → active

Організатор підписує договір з Учасник_2 і змінює статус Contracts[].status: pending → active

ЦБД перевіряє, що відсутні інші Аварди у статусі pending, а також Аварди у статусі active у яких є повʼязаний contract у статусі pending (Всі учасники, які отримували статус pending вже успішно кваліфіковані та з обома підписано договір):

Залишився тільки Учасник_3 з Авардом у статусі pending_waiting

ЦБД виконує наступну перевірку:

Нерозподілений обсяг >= мін частці, яку вказав Організатор? (Із запропонованої Організатором 1000 Учасник_1 забрав 500 і Учасник_2 забрав 400. Нерозподілений залишок == 100. При публікації процедури Організатор вказав Мін залишок == 200) 

• • 100 >= 200 ? - ні

Тому статус Аварда Учасника_3 змінюється Awards.status: pending_waiting → cancelled

Результат: Запропонований Організатором Обсяг 1000 частково закритий Учасником_1, який забрав 500. Учасник_2 забрав 400. Учасник_3 не забрав нічого

Приклад 3:

• Організатор вказав Обсяг == 1000
• Організатор вказав Мін ціну == 100
• Організатор вказав Мін частку == 200

...

Учасник_1:

• Обсяг бажаний == 500200
• Фінальна ставка == 120

Учасник_2:

• Обсяг бажаний == 400300
• Фінальна ставка == 110

Учасник_3:

• Обсяг бажаний == 800400
• Фінальна ставка== 100

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

Учасник_1:

1000 - 500 200 = 500800

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

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

Учасник_2:

500 800 - 400 300 = 100500

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

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

Учасник_3:

100 - 800 < 0500 - 400 = 100

В даному прикладі Обсяг пропозиції Учасника_3 НЕ вміщається в обсяг продажу

Учасник_3 отримує статус pending_waiting

Організатор успішно кваліфікує Учасника_1 і його Авард отримує статус active, в ЦБД автоматично публікується Contract для Учасника_1 у статусі pending

Організатор дискваліфікує Учасника_2 і його Авард отримує статус unsuccessful

В момент дискваліфікації ЦБД перевіряє чи бажаний обсяг Учасника_3 покривається нерозподіленим залишком? (Учасник_3 бажає придбати 800, а нерозподілений залишок == 500, бо із 1000 запропонованого обсягу 500 вже забрав Учасник_1)

В наведеному прикладі, Учасник_3 бажає придбати 800, а нерозподілений залишок == 500.

Тому Авард Учасника_3 залишається в статусі pending_waiting.

Організатор підписує договір з Учасник_1 і змінює статус Contracts[].status: pending → active

ЦБД перевіряє, що відсутні інші Аварди у статусі pending, а також Аварди у статусі active у яких є повʼязаний contract у статусі pending (Всі учасники, які отримували статус pending вже кваліфіковані з підписаними  договорами або дискваліфіковані):

Залишився Учасник_3 з Авардом у статусі pending_waiting

ЦБД виконує наступну перевірку:

Нерозподілений обсяг >= мін частці, яку вказав Організатор? (Із запропонованої Організатором 1000 Учасник_1 забрав 500, а Учасник_2 дискваліфікований. Нерозподілений залишок == 500. При публікації процедури Організатор вказав Мін залишок == 200) 

• • 500 >= 200 ? - так

Тому статус Аварда Учасника_3 змінюється Awards.status: pending_waiting → pending_admission

кваліфікує віх трьох учасників і за умови успішної кваліфікації, буде реалізовано 200+300+400 = 900

Якщо когось із учасників буде дискваліфіковано, то реалізований обсяг буде менше, відповіно, на бажаний обсяг дискваліфікованого учасника.

Варто звернути увагу, що Організатор вказав "Мін частку" == 200. Відповідно, учасники не мали змогу подати заяву на участь з меншим бажаним обсягом ( bids[].quantity не може бути <=200 ). В той самий час, учасники не могли подати заяву в якій вказати бажаний обсяг більше Обсягу вказаного організатором ( bids[].quantity не може бути >= 1000 )

Результат: Організатор реалізував обсяг у розмірі в 900 одиниць трьом учасникам. Учасник_1 забрав частку 200, Учасник_2 забрав частку 300 і Учасник_3 забрав 400. У Організатора залишився нерозподілений залишок - 100, який він може реалізувати в іншому аукціоні.

Приклад 2:

• Організатор вказав Обсяг == 1000
• Організатор вказав Мін ціну == 100
• Організатор вказав Мін частку == 200

Прийшло три Учасника, за результатами МА:

Учасник_1:

• Обсяг бажаний == 500
• Фінальна ставка == 120

Учасник_2:

• Обсяг бажаний == 400
• Фінальна ставка == 110

Учасник_3:

• Обсяг бажаний == 800
• Фінальна ставка== 100

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

Учасник_1:

1000 - 500 = 500

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

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

Учасник_2:

500 - 400 = 100

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

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

Учасник_3:

100 - 800 < 0

В даному прикладі Обсяг пропозиції Учасника_3 НЕ вміщається в обсяг продажу

Учасник_3 отримує статус pending_waiting

Організатор успішно кваліфікує Учасника_1 і його Авард отримує статус active, в ЦБД автоматично публікується Contract для Учасника_1 у статусі pending

Організатор успішно кваліфікує Учасника_2 і його Авард Організатор успішно кваліфікує Учасника_3 і його Авард отримує статус active, в ЦБД автоматично публікується Contract для Учасника_1 у статусі pending

Авард Учасника_3 у залишається в статусі pending_waiting та Contract для нього не створюється.

Організатор підписує договір з З Учасник_1 підписується договір та і змінює статус Contracts[].status: pending → active

З Організатор підписує договір з Учасник_3 підписується договір та 2 і змінює статус Contracts[].status: pending → active

Результат: Запропонований Організатором Обсяг 1000 частково закритий Учасником_1, який забрав 500. Учасник_2 забрав 400. Учасник_3 не забрав нічого

Приклад 4:

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

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

Учасник_1:

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

Учасник_2:

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

Учасник_3:

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

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

...

ЦБД перевіряє, що відсутні інші Аварди у статусі pending, а також Аварди у статусі active у яких є повʼязаний contract у статусі pending (Всі учасники, які отримували статус pending вже успішно кваліфіковані та з обома підписано договір):

Залишився тільки Учасник_3 з Авардом у статусі pending_waiting

ЦБД виконує наступну перевірку:

Нерозподілений обсяг >= мін частці, яку вказав Організатор? (Із запропонованої Організатором 1000 Учасник_1 забрав 500 і Учасник_2 забрав 400. Нерозподілений залишок == 100. При публікації процедури Організатор вказав Мін залишок == 200) 

• • 100 >= 200 ? - ні

Тому статус Аварда Учасника_3 змінюється Awards.status: pending_waiting → cancelled

Результат: Запропонований Організатором Обсяг 1000 частково закритий Учасником_1, який забрав 500. Учасник_2 забрав 400. Учасник_3 не забрав нічого. Нерозподілений залишок залишився у Організатора у розмірі 100

Приклад 3:

• Організатор вказав Обсяг == 1000
• Організатор вказав Мін ціну == 100
• Організатор вказав Мін частку == 200

Прийшло три Учасника, за результатами МА:

Учасник_1:

• Обсяг бажаний == 500
• Фінальна ставка == 120

Учасник_2:

• Обсяг бажаний == 400
• Фінальна ставка == 110

Учасник_3:

• Обсяг бажаний == 800
• Фінальна ставка== 100

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

Учасник_1:

4800 1000 - 3000 500 = 1800500

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

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

Учасник_2:

1800 - 2000 < 0500 - 400 = 100

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

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

Учасник_3:

100 - 800 < 0

В даному прикладі бажаний обсяг Учасника_3 НЕ вміщається в обсяг продажу

Учасник_3 отримує статус pending_waiting

...

Організатор успішно кваліфікує Учасника_1 і його Авард отримує статус protocol_signedЦБД перевіряє, що відсутні інші Аварди active, в ЦБД автоматично публікується Contract для Учасника_1 у статусі pending і автоматично змінює статус Учасника_2 на pending_admission (умовний переможець. Пропонуємо забрати нерозподілений залишок).

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

Учасник_2 НЕ приймає пропозицію реалізувати 1800 нерозподіленого залишку із 2000, які він пропонував початково.

Учасник_2 надсилає запит і статус його Аварда змінюється на cancelled

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

Приклад 3:

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

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

Учасник_1:

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

Учасник_2:

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

Учасник_3:

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

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

ЦБД розрахувала x_quantityLimit == (3000 + 2000 + 1000) * 0,8 == 4800

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

Учасник_1:

4800 - 3000 = 1800

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

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

Учасник_2:

1800 - 2000 < 0

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

Учасник_2 отримує статус pending_waiting

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

Учасник_3 отримує статус pending_waiting

Організатор дискваліфікує Учасника_1 і його Авард отримує статус unsuccessful

При дискваліфікації Учасника із статуса pending → unsuccessful, ЦБД перевіряє наявніть Авардів у статусі pending_waiting

Якщо в рамках періоду очікування результатів кваліфікації (qualificationPeriod) один з award’ів у статусі pending дискваліфіковують, ЦБД розподіляє обсяг переможців, яких було дискваліфіковано, між учасниками з авардами у статусі pending_waiting з наступними найменшими за величиною ціновими пропозиціями. При цьому, вже розрахований обсяг квоти 80% не змінюється. Якщо в результаті для учасника, з award'ом у статусі pending_waiting, формується обсяг, що повністю задовольняє його заяву, award такого учасника переходить до статусу pending. З моменту зміни статусу такого award’у на pending для такого учасника формується окремий період опублікування протоколу та підписання договору (signingPeriod) 15 робочих днів (аналогічно до award'ів, які сформувались спочатку).

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

Учасник_3 залишається в статусі pending_waiting

Якщо Організатор дискваліфікує Учасника_2, то Учасник_3 отримає статус pending і почнеться його кваліфікація.

Учасник_3 успішно кваліфіковано.

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

Приклад 4:

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

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

Учасник_1:

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

Учасник_2:

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

Учасник_3:

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

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

ЦБД розрахувала x_quantityLimit == (3000 + 2000 + 1000) * 0,8 == 4800

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

Учасник_1:

4800 - 3000 = 1800

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

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

Учасник_2:

1800 - 1000 = 800

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

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

Учасник_3:

800 - 2000 < 0

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

Учасник_3 отримує статус pending_waiting

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

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

Коли всі Awards, які були у статусі pending успішно кваліфіковані, ЦБД перевіряє наявніть Авардів у статусі pending_waiting

Учасник_3 має статус Аварда pending_waiting, його запропонований обсяг повністю не покривається залишком обсягу, що залишився після розподілення між Учасником_1 і Учасником_2

В даному випадку Учасник_3 отримує статус pending_admission

Учасник_3 має протягом 5-ти днів погодитись "закрити залишок" (залишок складає 800, а Учасник_3 пропонував 2000) і надіслати запит на зміну статуса на pending

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

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

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

Приклад 5:

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

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

Учасник_1:

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

Учасник_2:

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

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

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

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

Учасник_1:

8000 - 6000 = 2000

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

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

Учасник_2:

2000 - 4000 <0

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

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

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

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

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

Після цього:

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

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

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

Підписання контракту з переможцем (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.

При зміні contracts[].status: pending → active, на ЦБД має відбутися перевірка на наявність в contracts[].documents документа з documentType: contractSigned

...

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

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

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

Організатор дискваліфікує Учасника_2 і його Авард отримує статус unsuccessful

В момент дискваліфікації ЦБД перевіряє чи бажаний обсяг Учасника_3 покривається нерозподіленим залишком? (Учасник_3 бажає придбати 800, а нерозподілений залишок == 500, бо із 1000 запропонованого обсягу 500 вже забрав Учасник_1)

В наведеному прикладі, Учасник_3 бажає придбати 800, а нерозподілений залишок == 500.

Тому Авард Учасника_3 залишається в статусі pending_waiting.

Організатор підписує договір з Учасник_1 і змінює статус Contracts[].status: pending → active

ЦБД перевіряє, що відсутні інші Аварди у статусі pending, а також Аварди у статусі active у яких є повʼязаний contract у статусі pending (Всі учасники, які отримували статус pending вже кваліфіковані з підписаними  договорами або дискваліфіковані):

Залишився Учасник_3 з Авардом у статусі pending_waiting

ЦБД виконує наступну перевірку:

Нерозподілений обсяг >= мін частці, яку вказав Організатор? (Із запропонованої Організатором 1000 Учасник_1 забрав 500, а Учасник_2 дискваліфікований. Нерозподілений залишок == 500. При публікації процедури Організатор вказав Мін залишок == 200) 

• • 500 >= 200 ? - так

Тому статус Аварда Учасника_3 змінюється Awards.status: pending_waiting → pending_admission

Учаснику_3 пропонується забрати нерозподілений залишок у розмірі 500 одиниць

Учасник_3 може погодитись, вказати обсяг, який він погоджується забрати (в даному випадку в діапазоні від 200 до 500) і надіслати запит на зміну статусу Awards.status: pending_admission → pending

     АБО

Учасник_3 може відмовитись забрати нерозподілений залишок у розмірі 500, бо його заявка була на купівлю 800 одиниць. В такому випадку його Авард набуває статус cancelled і переможцем залишається тільки Учасник_1

У разі першого варіанту: Учасник_3 погодився забрати нерозподілений залишок,

Організатор успішно кваліфікує Учасника_3 і його Авард отримує статус active, в ЦБД автоматично публікується Contract для Учасника_3 у статусі pending

З Учасник_1 підписується договір та Contracts[].status: pending → active

З Учасник_3 підписується договір та Contracts[].status: pending → active

Результат: Запропонований Організатором Обсяг 1000 частково закритий Учасником_1, який забрав 500. Учасник_2 дискваліфікований,  Учасник_3 забрав нерозподілений залишок 500

Приклад 4:

• Організатор вказав Обсяг == 1000
• Організатор вказав Мін ціну == 100
• Організатор вказав Мін частку == 200

Прийшло три Учасника, за результатами МА:

Учасник_1:

• Обсяг бажаний == 400
• Фінальна ставка == 120

Учасник_2:

• Обсяг бажаний == 500
• Фінальна ставка == 110

Учасник_3:

• Обсяг бажаний == 300
• Фінальна ставка == 100

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

Учасник_1:

1000 - 400 = 600

В даному прикладі бажаний обсяг Учасника_1 вміщається в обсяг продажу

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

Учасник_2:

600 - 500 = 100

В даному прикладі бажаний обсяг Учасника_2 вміщається в нерозподілений залишок

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

Учасник_3:

100 - 300 < 0

В даному прикладі бажаний обсяг Учасника_3 НЕ вміщається в нерозподілений залишок

Учасник_3 отримує статус pending_waiting

Організатор успішно кваліфікує Учасника_1 і його Авард отримує статус active, в ЦБД автоматично публікується Contract для Учасника_1 у статусі pending

Організатор дискваліфікує Учасника_2 і його Авард отримує статус unsuccessful

В момент дискваліфікації ЦБД перевіряє:

• Чи є Аварди у статусі pending_waiting?

В наведеному прикладі є - Учасник_3. Відбувається перевірка: чи бажаний обсяг Учасника_3 покривається нерозподіленим залишком? (Учасник_3 бажає придбати 300, а нерозподілений залишок == 600, бо із 1000 запропонованого обсягу 400 вже забрав Учасник_1)

Покривається, тому Авард Учасника_3 змінюється awards[].status: pending_waiting → pending

Організатор підписує договір з Учасник_1 і змінює статус Contracts[].status: pending → active

Організатор підписує протокол з Учасик_3 і змінює статус awards[].status: pending → active , для Учасник_3 в ЦБД створюється contracts[] у статусі pending

На етапі підписання договору відбувається дискваліфікація Учасника_3, Організатор завантажує в Авард Учасника_3 rejectionProtocol та надсилає запит на зміну awards[].status: active → unsuccessful

Contract Учасника_3 автоматично набуває статуса cancelled

В момент дискваліфікації ЦБД перевіряє:

• Чи є Аварди у статусі pending_waiting?

В наведеному прикладі Авардів у статусі pending_waiting не залишилось

Результат: Обсяг 1000 частково закритий Учасником_1, який забрав 400. Учасник_2 і Учасник_3 - дискваліфіковані

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

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

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

Модель

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

...

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

...

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

...

Так

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

...

...

Ні

...

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

Ні

...

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

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

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

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

У Органзатора є можливість скасувати процедуру, коли процедура має один із статусів:

active_rectification

active_tendering

qualification

active_qualification

Використовуємо cancellations[] модель.

Для скасування Замовник аукціону має:

• завантажити документ cancellations[].documents з documentType: cancellationDetails
• вказати причину скасування в cancellations[].reason із словника
• вказати фактичну дату скасування в cancellations[].datePublished

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

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

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

bankAccounts - видалити. згідно переписки з ГарПок: 

bids.qualified - прибрати із біда. Не несе взагалі ніякої логіки

minNumberOfQualifiedBids - мінімально допустиме значення == 2.

contracts - стандартна логіка contracts не підходить. Через те, що, якщо Договір не підписано, то ЦБД має автоматично визначити нового переможця, якщо ще не завершився qualificagionPeriod. Потрібна логіка описана 

contracts - status - прибрати зайві paid, signed,unsuccessful

В Swagger наявні renewables.GreenProcedure та renewables.RenewablesMultiAwardsProcedure - треба залишити лише renewables.RenewablesMultiAwardsProcedure

datePublished - x-legalNameUa змінити на *Дата публікації процедури*.

previousAuctionId прибрати в Swagger можливість додавання UA-PS-YYYY-MM-DD-000000-0

items.unit.code - зробити "KWT" - readOnly: true автогенерованє.

cancellation - змінити на базову модель base.Cancellation

x_valueUAH - прибрати

Всі зміни по полям зазначені нижче: зелений - додати, червоний - видалити, помаранчевий - змінити

renewables.RenewablesMultiAwardsProcedure  typereadOnly

	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

	BSM
disqualifiedBids			list[] string	true		Раніше дискваліфіковані	Previously disqualified	логіку робили для BSE/BSD тут необхідно таку ж логіку для BSM
previousAuctionId			string			Номер попереднього аукціону	Previous auction Id

pattern

pattern: ^(

REM

BS[EDMW][0-9]{3}-UA-[0-9]{8}-[0-9]{5}|[a-zA-Z]{2}-[a-zA-Z]{2}-[0-9]{4}-[0-9]{2}-[0-9]{2}-[0-9]{6}-[0-9])$
sellingMethod			string		+	Тип процедури	Procedure type

renewables

basicSell-multiAwards

renewables

basicSell-multiAwards-ultra-fast

renewables

basicSell-multiAwards-fast

renewables

basicSell-multiAwards-fast-manual

renewables

basicSell-multiAwards-fast-auction-manual-qualification

renewables

basicSell-multiAwards-fast-auction-prod

renewables

basicSell-multiAwards-initial-auction

renewables

basicSell-multiAwards-initial-qualification

renewables

basicSell-multiAwards-initial-qualification-prod

renewables

basicSell-multiAwards-initial-qualification-fast

renewables

basicSell-multiAwards-initial-auction-manual
sellingEntity			model base.Organization		+	Інформація про замовника аукціону

Auction customer information

Organizer information	Аналогічна, як у BSE
	name		model base.multiLang

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

		Повна юридична назва організації або ПІБ	Legal name or Full Name
	identifier		model base.Identifier		+	Ідентифікатори

Замовника аукціону

організації або особи

Identifier

Customer IDCustomer

		scheme	string

Тип ідентифікації Замовника аукціону

+

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

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

ID type

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

Обирається одне значення зі словників: https://procedure-sandbox.prozorro.sale/api/classifiers/identifiers https://procedure-sandbox.prozorro.sale/api/classifiers/ua_identifiers
		legalName	model base.multiLang		+	Повна юридична назва організації	Legal name	Для публікації процедури обовʼязково заповнено legalName.uk_UA
		id	string		+	Код ЄДРПОУ або ІПН або паспорт

Legal ID

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

	address		model anyOf → base.

AddressUacountryName

model

base.multiLang

КраїнаCountry

uk_UA = Enum:[Україна]

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

Address                base.AddressUa		+	Адреса	Address	Використовуємо готову модель із basicSell
		countryName

region

model base.multiLang

+

Область

Країна

Region

Country

uk_UA

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

- Для публікації процедури обовʼязково для заповнення
		region	model base.multiLang		+	Область	Region	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 nameuk_UA - Для публікації процедури обовʼязково для заповненняemailstring($email)Адреса електронної пошти
Main contact e-mailДля публікації процедури обовʼязково для заповненняtelephonestringНомер телефонуPhone numberДля публікації процедури обовʼязково для заповненняfaxNumberstringНомер факсуFax numberurlstring($uri)Веб адресаWebsitex_verificationDocuments 

base.ContactPoint		+	Контактна особа	Main contact	Використовуємо готову модель із basicSell
		name

list[]

model base.

VerificationDocumentInfo

multiLang

Ліцензія

+

Business verification documents

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

ПІБ	Main contact name	uk_UA - Для публікації процедури обовʼязково для заповнення
		email	string($email)		+	Адреса електронної пошти	Main contact e-mail
		telephone	string		+	Номер телефону	Phone number
		faxNumber	string			Номер факсу	Fax number
		url	string($uri)			Веб адреса	Website

 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	уточнено

для заповнення
accessDetails			model base.multiLang			Порядок ознайомлення з майном, час і місце проведення огляду об’єкта	Auction access details
bankAccounts			model basicSell.BankAccountsByType		+	Банківські рахунки	Bank accounts	Використовуємо готову модель із basicSell При публікації обов'язковоодинбанківськийрахунокзтипом guarantee івалютою UAH. Рахунківдлякожноготипув UAH/USD/EUR можебутибезліч.
	accountType					Тип рахунку	Account type	Enum: [ registrationFee, guarantee, other, payment ]
	accounts							Використовуємо готову модель basicSell.BankAccountWithCurrency

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

Image Removed

x_documentRequirements			model base.multiLang

Вимоги

Перелік та вимоги до оформлення документів

Document requirements

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

x_additionalInformation			model base.multiLang			Додаткові відомості

Other requirements and additional informationНЕ ОБОВʼЯЗКОВЕ

Other requirements and additional information

x_quantityLimit 

number($float)

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

value			model ValueWithTax		+

Максимальна

Мінімальна цінова пропозиція

Max

Min bid value
	currency		string		+	Валюта	Currency	Enum: [

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

UAH, USD, EUR]
	amount		number($float)		+	Сума	Amount

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

	valuePer		model base.Unit			Одиниця виміру	Measure unit	default: заповнюємо значенням із items[0].unit Організатор може передати інше значення за потреби (Наприклад, в REM ціна була за KWH, хоча items[].unit = KWT) Вказані одиниці ніяк не впливають на розрахунки! Тобто, якщо Організатор реалізує Тонни, а ціну вказує за Кг, то коректного автоматичного розрахунку ціни НЕ буде.
	valueAddedTaxIncluded		boolean

true

Податок

Tax

default

: falsereadOnly

: true

ЦБД не має приймати value.valueAddedTaxIncluded == true, а зараз приймає. Допустиме значення тільки false

Якщо майданчик не передав, то автозаповнити як false

guarantee 

ВИДАЛИТИ 

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

Організатор може передати інше значення за потреби
valueAddedTaxCharged			boolean			На фінальну суму нараховується ПДВ	Value added tax charged	default: false Організатор може передати інше значення за потреби
discount			model base.Discount			Знижка	Discount	Використовуємо готову модель із basicSell base.Discount
guarantee

bankGuaranteeDetails

model base.

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

Value		+	Гарантійний внесок	Guarantee	Використовуємо готову модель із basicSell base.Value
minimalStep			model base.Value	true		Розмір кроку аукціону	Minimal Step	Організатор НЕ передає це поле. При публікації процедури автоматично генерується, як: "

currency": "eurocent",

currency": == value.currency "amount": 0.01
	currency		string	true		Валюта	Currency	default:

 eurocent

== value.currency
	amount		number($float)	true		Сума	Amount	default: 0.01
minNumberOfQualifiedBids			integer($int64)

true

			Мінімальна кількість заяв учасників	Minimal number of bids	default: 2 Організатор може передати значення 1 за потреби minimum: 1 maximum: 2
tenderAttempts			integer($int64)			Лот виставляється	Attempt number	default: 1 minimum: 1
items[]			list[] model

renewables

basicSell-multiAwards.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

Enum: [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

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

Classification ID

Організатор НЕ передає це поле

	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							ВИДАЛЯЄМО
	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 В МАСИВ! НЕ МОЖЕ БУТИ ДЕКІЛЬКА 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" ]
	location		model base.Location
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 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] Обовʼязкове поле для активації Біда
		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": "Кіловат-година", "en_US": "kilowatt hour"
	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	dict: renewablesTerminationReason
	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 в Аварді: У статусі [verification, waiting, unsuccessful, pending, protocol_signed, active, pending_admission] - відображаємо quantity У статусі [cancelled, pending_waiting] - не відображаємо копіюється із повʼязаного Біда
		address						ВИДАЛЯЄМО
		itemProps[]						модель items[].itemProps використовуємо таку саму, як і в процедурі вище Копіюється із процедури
		additionalClassifications[]						Копіюється із процедури
		location
	documents[]		model Documents					documentOf: award documentType:[rejectionProtocol, auctionProtocol, act, digitalSignature]
	dateModified		string($date-time)
	bidId		string
	signingPeriod		model base.Period
	admissionPeriod		model base.Period
timer			string($date-time)	true
archiveId			string	true
contracts[]			model renewables.Contract
	id		string	true
	awardId		string	true
	contractNumber		string
	title		model base.multiLang
	description		model base.multiLang
	value		model Value
		currency
		amount
	contractTotalValue		model Value
		currency
		amount
	items[]							копіюється із повʼязаного Award в тій самій структурі
	buyers[]							копіюється із повʼязаного Award
	status					Статус	Status	Enum:[pending,active,cancelled]
	dataSigned					Дата підписання договору	Contract date signed
	datePublished
	dateModified
	documents[]		model Document			Документи договору	Contract documents	documentOf: contract documentType: [contractSigned, contractAnnexe, contractNotice, digitalSignature]
	contractTime							ВИДАЛИТИ
	x_valueUAH							ВИДАЛИТИ
rectificationPeriod			model base.Period	true		Період редагування	Rectification period
enquiryPeriod			model base.Period	true		Період відповідей	Enquiry period
tenderPeriod			model base.Period	true		Період прийняття заяв на участь	Tender period
auctionPeriod			model base.Period	true		Аукціон	Auction
waitingPeriod			model base.Period					ПЕРЕЙМЕНУВАТИ НА qualificationPeriod
qualificationPeriod			model base.Period	true		Період кваліфікації	Qualification period	те саме, що й waitingPeriod (замінити назву)
verificationPeriod			model base.Period	true		Період верифікації документів	Verification period
questionPeriod			model base.Period	true		Період запитань	Question period
status				true		Статус	Status	Enum: [active_rectification, active_tendering, active_auction,  qualification, active_qualification, complete, unsuccessful, cancelled]
cancellations[]			model base.Cancellation			Скасування аукціону	Auction cancelleation
	id		string	true
	reason		model base.multiLang
	documents[]		model Documents					documentOf: cancellation documentType: [cancellationDetails, digitalSignature]
	datePublished		string($date-time)			Дата прийняття рішення про скасування	Cancellation date