BasicSell-multiAwards (Декілька переможців. Ставки на підвищення)

Посилання:

• PRD
• Вимоги до майданчиків
• Вимоги до Порталу
• Вимоги до BI

Голосарій

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

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

Процедура - оголошення з продажу на аукціоні на підвищення ставок, з декількома переможцями

Організатор - замовник аукціону

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

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

Цінова пропозиція - ціна, яку пропонує Учасник за одиницю виставленої Організатором продукції. Розмірність одиниць вказує Організатор при публікації процедури (тонна, кілограм, ящик тощо). Ціна за одиницю декларується учасником та подається в ЕТС до закінчення кінцевого строку подання заяв про участь в аукціоні або в ході проведення аукціону шляхом оновлення такої цінової пропозиції.

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

Мета створення процедури та нормативні засади

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

З метою проведення аукціонів на підвищення ціни з кількома переможцями в межах системи Prozorro.Sale реалізовано sellingMethod: basicSell-multiAwards (partialAwards, fractionalAwards, spreadAwards). Така процедура надає змогу Замовнику здійснити продаж лоту, в рамках аукціону, необмеженій кількості учасників, а учаснику придбати саме ту кількість обсягу лота, що йому потрібна.

Загальна інформація про роботу процедури

Критерієм вибору переможця є цінова пропозиція, що складається з ціни за одиницю та кількість одиниць.

Кваліфікація відбувається після завершення аукціону, попередньої кваліфікації немає.

За результатами періоду подання пропозицій (tenderPeriod), процедура переходить у період аукціону (auctionPeriod). У протилежному випадку аукціон визнається таким, що не відбувся. Статус аукціону автоматично змінюється на unsuccessful.

За умовчанням, мінімальна кількість заяв для проведення торгів = 2. (minNumberOfQualifiedBids default == 2), але є можливість при публікації замінити на 1

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

Особливості процедури

ПРОЦЕДУРА СХОЖА НА basicSell-english та renewables-multiAwards

Відмінності:

1. На етапі публікації Процедури:
   • В одній процедурі може бути тільки один лот (item)
   • Організатор на етапі публікації вказує:
     • Обсяг, який реалізується (procedure.items[0].quantity)
     • Одиницю виміру обсягу (procedure.items[0].unit)
       • із словника unitCode
       • ЦБД приймає тільки
         • BX - ящик
         • D64 - блок
         • E50 - одиниця
         • GRM - грам
         • H87 - штуки
         • KGM - кілограм
         • LTR - літр
         • MTQ - метри кубічні
         • RM- пачка
         • TNE - тонни
     • Мінімальну ціну на одиницю обсягу, яку приймає ЦБД в заявах на участь (procedure.value.*)
     • Мінімальний обсяг, який може викупити учасник (procedure.minimalPart)
2. На етапі подання заяв на участь:
   
   • Учасник може подати тільки одну заяву на участь в одному аукціоні
   • Учасник в заяві на участь вказує:
     • Бажану кількість обсягу активу (bids[].quantity)
       • Бажана кількість не може бути менше за Мінімальний обсяг, що вказав Організатора (< procedure.minimalPart)
     • Цінову пропозицію за одиницю обсягу (bids[].value.*)
3. Аукціон:
   
   • Аукціон продажу частинами
4. Кваліфікація:
   • Кількість переможців необмежена
   • Наявність необмеженої кількості учасників, що кваліфікуються
   • Учасники, що очікують кваліфікації Переможців НЕ можуть відмовитись від очікування протягом qualifiationPeriod (20 р.д.)
   • Можливість учаснику, що очікує викупити нерозподілений залишок, який має бути не менше, ніж Мінімальний обсяг, який вказав Організатор.

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

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

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

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

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

basicSell-multiAwards - legal_names.json 

Timeline процедури

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

Створення процедури

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

• Інформація про Організатора аукціону (sellingEntity)
  • Ідентифікатори Організатора аукціону (Код ЄДРПОУ або ІПН або паспорт) (sellingEntity.identifier)
  • Адреса Організатора аукціону (повна адреса) (sellingEntity.address)
  • Інформація про контактну особу (sellingEntity.contactPoint)
• Номер лоту (lotId)
• Повну назву Аукціону (заголовок) (title)
• Опис аукціону (description)
• Банківські рахунки організатора (bankAccounts)
• Гарантійний внесок (guarantee)
• Мінімальна ціна за одиницю обсягу (value)
  • Сума (value.amount)
  • Валюта (value.currency) 
  • Розмірність одиниці (value.valuePer)
• Мінімальна частка, яку може викупити учасник (minimalPart)
• Інформація про лот (items)
  • Опис лоту (items.description)
  • Класифікатор лоту (items.classification)
  • Обсяг лоту (items.quantity)
  • Одиниці виміру (items.unit) із переліку:
    • BX - ящик
    • D64 - блок
    • E50 - одиниця
    • GRM - грам
    • H87 - штуки
    • KGM - кілограм
    • LTR - літр
    • MTQ - метри кубічні
    • RM- пачка
    • TNE - тонни
• Документи
• Дата проведення аукціону (auctionPeriod.startDate)

Повний перелік полів в Swagger (ДОДАТИ ПОСИЛАННЯ)

Редагування процедури

Протягом періоду редагування (rectifiactionPeriod) Організатор аукціону має право самостійно вносити зміни в поля та документи процедури .
Організатор має можливість внести зміни в поля які він заповнював самостійно під час публікації аукціону, окрім Дата проведення аукціону (auctionPeriod.startDate) та всіх автогенерованих полів:

Для внесення змін Організатор має попередньо завантажити документ - "Погодження змін до опису лоту. Опис причин редагування." (documentType: clarifications). Цей документ має містити перелік змін, які вносяться в оголошення, причину внесення таких змін. Він має бути доступний для завантаження в період редагування (rectificationPeriod) та є обов'язковим для подальшого внесення змін в поля процедури.

Протягом періоду редагування (rectificationPeriod) та періоду відповідей (enquiryPeriod) Організатор аукціону може завантажувати та замінювати документи процедури (procedure.documents[])

ВАЖЛИВО: Якщо на момент редагування полів\документів процедури вже існують Біди у статусі draft або active, то вони набувають статус inactive.

Перелік полів, при редагуванні яких відбувається інактивація бідів:

Періоди процедури

"rectificationPeriod": {
	"endDate": {
		"conditions": [],
		"diff": "6 days",
		"direction": 		"backward",
		"from": "auctionPeriod.startDate",
		"time": "18:00"
	},
	"startDate": {
	"from": "now"
	}
}

"tenderPeriod": {
	"endDate": {
		"diff": "1 days",
		"direction": "backward",
		"from": "auctionPeriod.startDate",
		"time": "20:00"
	},
	"startDate": {
	"from": "now"
	}
}

"questionPeriod": {
	"endDate": {
		"diff": "1 days",
		"direction": "backward",
		"from": "auctionPeriod.startDate",
		"time": "18:00"
	},
	"startDate": {
	"from": "now"
	}
}

"enquiryPeriod": {
	"endDate": {
		"diff": "1 days",
		"direction": "backward",
		"from": "auctionPeriod.startDate",
		"time": "18:00"
	},
	"startDate": {
	"from": "now"
	}
}

"auctionPeriod": {
	"startDate": {
		"conditions": [
			{
			"auto_set": true,
			"case": {
				"isPerishable": true
			},
			"diff": "2 business days",
			"direction": "forward",
			"error": "raise",
			"from": "now",
			"time": "11:00 - 13:00"
			}
		],
		"time": "11:00 - 13:00",
		"validation": {
			"is_business_day": true,
			"min": {
				"diff": "8 days",
				"direction": "forward",
				"error": "raise",
				"from": "now",
				"time": "11:00",
				"is_business_day": true
			}
		}
	}
}

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

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

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

Скасування процедури

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

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

• завантажити документ (documentType:cancellationDetails) щодо причин скасування;
• внести опис причини скасування (cancellation.reason) довільним текстом;
• вказати фактичну дату скасування (cancellations.date).

В разі скасування процедури ЦБД автоматично присвоює процедурі статус “аукціон не відбувся” (procedure.status: cancelled)

Документи скасування процедури (cancellations.documents)

Публікація заяви на участь

Періоди у заяви на участь ( bids[] ) відсутні.

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

Для публікації біда, обовʼязково мають бути заповнені поля:

• Ідентифікатори організації або особи (bids.bidders.identifier)
• Адреса (bids.bidders.address)
• Контактна особа (bids.bidders.contactPoint)
• Цінова пропозиція (bids.value)
  • bids.value.amount >= procedure.value.amount. В іншому випадку ЦБД має повертати валідаційну помилку.
• Обсяг (bids.quantity)
  • bids.quantity НЕ може бути менше procedure.minimalPart. Може дорівнювати чи бути більше, але не більше, ніж procedure.items[0].quantity

bids.value - (цінова пропозиція) зазначається із двома знаками після коми

Один учасник може подати тільки одну заяву на участь.

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

У разі коли в момент закінчення кінцевого строку подання заяв про участь в аукціоні подано менше двох заяв, МА не запускається і одразу відбувається кваліфікація одного учасника.

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

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

У разі редагування полів процедури Організатором, заяви на участь (у статусах draft та/або active) учасників автоматично переходять у статус inactive.

Таку заяву на участь можна повторно перевести у статус active.

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

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

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

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

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

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

Періоди Awards

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

Статуси Awards

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

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

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

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

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

Статуси 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 або active і не може дискваліфікувати Авард у статусі 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
• Організатор вказав Мін ціну == 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. Відповідно, учасники не мали змогу подати заяву на участь з меншим бажаним обсягом ( 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 і його Авард отримує статус 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 не забрав нічого. Нерозподілений залишок залишився у Організатора у розмірі 100

Приклад 3:

• Організатор вказав Обсяг == 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 і його Авард отримує статус 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.

Модель