Page History

...

• Вимоги до майданчиків (ДОДАТИ)

Голосарій

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

...

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

...

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

  • Обовʼязковий Основний класифікатор - CAV (проговорити з Андрієм на ЦБД дозволити всі CAV, а на Майданчиках обмежити для брухту\щебню)

  • Не обовʼязковий Додаткові класифікатори - CPVS, CVZU

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

legalName endpoint 

• • CAV

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

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

legalName endpoint 

Timeline Timeline процедури

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

...

...

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

Протягом періоду Процедури qualification та active_qualification у Учасника також має бути можливість додавати і замінювати нові додані документи . 
Документи, які були додані до заяви на участь ДО проведення аукціону не має бути можливість замінювати (оновлювати).

В Постанові п. 37 зазначено, що учасник має мати можливість "завантаження оновлених редакцій доданих до заяви документів ДО закінчення кінцевого строку подання заяв про участь"

Деактивація заяви на участь

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

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

Періоди Awards

...

В момент набуття Авардом статуса pending

...

Період формується в Аварді з моменту набуття Авардом статусу pending

Якщо Авард був у статусі pending і отримав signingPeriod, то після зміни статуса на інший (protocol_signed, active OR unsuccessful) період залишається незмінним.

Аварди в інших статусах цей період не отримують.

Протягом tenderPeriod необхідно передбачити можливість Учаснику додавати і замінювати документи в bids[x].documents

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

За результатами періоду аукціону (auctionPeriod) пропозиції сортуються від найбільшої ціни до найменшої, а у випадку співпадіння ціни, вище відображається пропозиція розміщена раніше. Часом розміщення пропозиції вважається час першого розміщення заяви у ЦБД, а, у випадку редагування пропозиції під час періоду прийому пропозицій, час фіксації змін у заяві у ЦБД.

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

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

Періоди Awards

"verificationPeriod": {
	"endDate": {
		"diff": "6 business days",
		"direction": "forward",
		"from": "now",
		"time": "18:00"
	},
	"startDate": {
	"from": "now"
}

Anchor
awards_statuses awards_statuses

Статуси Awards

...

В момент набуття Авардом статуса pending_admission

...

На рівні ЦБД: Статус аварда автоматично змінюється з pending_admission → cancelled

...

pending

Ручна дія.

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

Автоматично.Завершився verificationPeriod.endDate

Статус отримують Аварди одразу після завершення роботи модуля аукціону

Статус pending_waiting отримують Аварди, які перебувають у списку результатів Модуля Аукціону і які успішно пройшли етап перевірки документів (award.status <> rejected) за Аукціону за умови, що обсяг, який вони запропонували повністю НЕ покривається розрахованим значенням BasicSell-multiAwards Брухт\щебінь (декілька переможців)вказали в заявці на участь повністю НЕ покривається обсягом, який вказав Організатор в оголошенні, з причини, що обсяг вже закритий іншими пропозиціями учасників, що запропонували меншу більшу ціну.

Приклад 1:

Організатор вказав квоту обсяг procedure.items.quantity == 10 0001000

Учасник_1 запропонував вказав в заявці awards.items.quantit  == 3 000 700 по найменшій найбільшій ціні 10120

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

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

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

ЦБД розраховує BasicSell-multiAwards Брухт\щебінь (декілька переможців) == (3000 + 1 000 + 2 000) * 0.8 == 4 800

вказав в заявці awards.items.quantit  ==  200 по ціні 110

Учасник_3 вказав в заявці awards.items.quantit  ==  200 по ціні 100

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

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

Приклад 2:

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

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

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

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

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

ЦБД розраховує BasicSell-multiAwards Брухт\щебінь (декілька переможців) == (3000 + 1 000 + 2 000) * 0.8 == 4 800

найбільшій ціні 100

Учасник_2 вказав в заявці  800 по ціні 110

Учасник_3 вказав в заявці  700 по ціні 100

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

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

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

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

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

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

АБО

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

За умови, що всі Awards, що мали статус pending отримали статус active і їх повʼязані Contracts[] також отримали статус active

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

АБО

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

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

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

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

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

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

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

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

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

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

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

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

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

Ручна дія.

Організатор надсилає запит на зміну статуса Awards[]

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

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

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

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

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

ЦБД автоматично створює до цього аварду contracts[] у статусі pending

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

verification

Ручна дія.

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

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

verification → rejected:

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

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

pending

АБО

active

Ручна дія.

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

Ручна дія.

Організатор надсилає запит на зміну статуса Аварда

active → unsuccessful