BasicSell-multiAwards Брухт\щебінь (декілька переможців)

Посилання:

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

Голосарій

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

НАЙБІЛЬШЕ СХОЖА НА basicSell-english

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

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

legalName endpoint 

Timeline процедури

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

Створення оголошення

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

• Інформація про Організатора аукціону (sellingEntity)
  • Ідентифікатори Організатора аукціону (Код ЄДРПОУ або ІПН або паспорт) (sellingEntity.identifier)
  • Адреса Організатора аукціону (повна адреса) (sellingEntity.address)
  • Інформація про контактну особу (sellingEntity.contactPoint)
• Номер лоту (lotId)
• Повну назву Аукціону (заголовок) (title)
• Опис аукціону (description)
• Банківські рахунки організатора (bankAccounts)
• Гарантійний внесок (guarantee)
• Розмір кроку аукціону (minimalStep)
• Мінімальна ціна за одиницю (value)
  • Розмірність одиниці (value.valuePer)
• Мінімальна частка, яку може викупити учасник (minimalPart)
• Інформація про лот (items)
  • Опис лоту (items.description)
  • Класифікатор лоту (items.classification)
  • Обсяг лоту (items.quantity)
  • Одиниці виміру (items.unit)
• Документи
• Дата проведення аукціону (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"
	}
}

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

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

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

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

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

• завантажити документ (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. ЦБД генерує award'и для N учасників у статусі pending.

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

Періоди Awards

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

Статуси Awards

Документи обʼєкта кваліфікації (awards.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, який триває 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. При виконанні запиту ЦБД має перевірити, що quantity, яке вказав Аавард у своєму запит <= нерозподіленому залишку, що дорівнює x_quantityLimit - sum(quantity) всіх Авардів, що отримали статус active.

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

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

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

ПРИКЛАДИ:

Приклад 1:

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

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

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

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

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

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

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

б) 

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

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

Приклад 2:

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

ЦБД перевіряє, що відсутні інші Аварди у статусі 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[] відрізняється від контрактингу базової процедури там, що contracts є не наслідком успішно підписаного протоколу, а має підписуватись в один період.

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

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

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

Завершення аукціону (переведення у статус 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 - прибрати

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

Архів