...

•  Загальний огляд sanctionedAssets-english
  •  Мета створення процедури та нормативні засади
  •  Загальна інформація про роботу процедури
  •  Глоссарій процедури
•  Процедура
  •  Особливості процедури
  •  Механіка аукціону
  •  Опис класифікаторів та їх словників
  •  Статуси процедури
  •  Періоди процедури
  •  Документи процедури
•  Заява на участь
•  Статуси заяви на участь
•  Документи заяви на участь
•  Авард
•  Статуси учасників на етапі кваліфікації (awards)
•  Періоди Award
•  Документи Аварду
•  Умови вибору переможця
•  Період очікування (waitingPeriod)
•  Можливий сценарій
•  Підтвердження оплати
•  Дискваліфікація Учасника
•  Договір
•  Статуси Contracts
•  Документи contract
•  Робота з договором
•  Пролонгація
•  Пролонгація періоду підписання договору
•  Завершення аукціону (переведення у статус complete)
•  Створення та редагування оголошення
•  Формування лота, опис дій поза системою
•  Перелік обов'язкової інформації для відображення на майданчику
•  Створення оголошення
•  Редагування оголошення
•  Розміщення заяви на участь nonperformingLoans-english
•  Робота із заявою на участь
•  Результати періоду подання пропозицій (tenderPeriod)
•  Скасування аукціону nonperformingLoans-english
•  Аукціон nonperformingLoans-english
•  Послідовний раунд (англійський)**
•  Пауза
•  Розкриття
•  Послідовність кроків:
•  Особливості роботи із сутностями та документами
•  Посилання на свагер та конфігураційний файл, який включає в себе:
•  Нотифікація процедури
•  Схеми процедури
•  Перелік схем:
•  Особливості роботи процедури для тестування nonperformingLoans-english
•  Типи процедур для тестуванн

уточнити про 

інформацію про договори оренди об’єкта - пошук по документу

Загальний огляд sanctionedAssets-english

...

Бізнес назва - Продаж санкційного майна

• Регламент - посилання

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

...

1. Об'єктом продажу є пул активів
2. мінімальна кількість заяв для можливості успішного проведення аукціону за замовчуванням minNumberOfQualifiedBids = 1, але у Організатор присутня можливість при публікації процедури передати minNumberOfQualifiedBids =2 - будемо це робити чи ні? Даємо можливість обирати чи ні?
   1. Якщо заява тільки одна, то для викупу сума цінової пропозиції має бути не менше стартової ціни (просто стартова ціна, не стартова+крок)
   2. У випадку проведення аукціону і наявності більше 1 учасника, переможна пропозиція під час МА має бути не менше стартова ціна + крок. - Мені тут якщо чесно трішки дивно
3. Аукціон:
   • англійський аукціон
4. На перших порах відповідальність за публікацію ланцюжку процедур буде на організаторі 
5. Скасувати можемо тільки до проведення аукціону? Тобто тільки зі статусу active_tendering? Електронний аукціон може бути відмінено за рішенням організатора аукціону на будь-якому етапі до дня його проведення.

Механіка аукціону

1. Якщо tenderAttempts = 1, то поле previousAuctionId не використовується.
   Якщо tenderAttempts > 1 поле previousAuctionId використовується та є обов'язкове;  - давайте цю валідацію додамо, виглядає непогано, щоб хоч якось ланцюжок фіксувати в цбд

Механіка аукціону

Англійський Англійський аукціон

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

...

Ендпоінти з класифікаторами:

• CAV
• CPVS
• dm? 

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

...

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

...

"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"
	}
}

"auctionPeriod

"enquiryPeriod": {
	"endDatestartDate": {
		"difftime": "1 days11:00 - 13:00",
		"directionvalidation": "backward",{
			"fromis_business_day": "auctionPeriod.startDate"true,
			"timemin": "18:00"
	},
	"startDate": {
{
				"diff": "8 days",
				"direction": "forward",
				"error": "raise",
				"from": "now",
				"time": "11:00",
				"is_business_day": true
			}
		}
	}
}

"qualificationPeriod": {
	"endDate": {
		"diff": "18 business days",
		"direction": "forward",

"auctionPeriod": {
	"startDate": {
		"time": "11:00 - 13:00",
		"validation": {
			"is_business_day": true,
			"min": {
				"diff": "8 days",
				"direction": "forward",
				"error": "raise",
				"from": "now",
				"time": "1118:00"
	},
				"is_business_day"startDate": true{
			}"from": "now"
		}
	}
}

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

"waitingPeriod": {
	"endDate": {
		"diff": "30 days",
		"direction": "forward",
		"from": "now",
		"time": "18:00"
	},
	"startDate": {
		"from": "now"
	}
}

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

...

Ілюстрація

...

ні

...

technicalSpecifications

...

evaluationCriteria

...

contractProforma

...

x_presentation

...

x_nonperformingLoansPublicAssetCertificate

...

x_nda

...

clarifications

...

Опис причин редагування

...

Цифровий підпис

(Особливості роботи із цифровим підписом)

...

Заява на участь

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

...

Технічна назва

...

Бізнесова назва

...

Перехід з

...

За умови

...

Коментар

...

Ручна дія.

Учасник надсилає запит на публікацію Bid-а

...

Публікація заяви на участь доступна тільки протягом tenderPeriod

Мають бути заповнені поля:

• value

• bidders

Майданчик Учасника робить POST запит до ЦБД та передає об'єкт заяви на участь. У разі правильно сформованого об'єкта заяви на участь, ЦБД повертає майданчику token для активації заяви на участь, заява на участь набуває статус “Чернетка заяви” (draft).

...

draft

inactive

...

Ручна дія.

Учасник надсилає запит на зміну статуса Bid-а

...

Активувати заяву на участь є можливість тільки протягом tenderPeriod.

Майданчик Учасника надсилає запит на активацію заяви на участь в ЦБД, заява на участь змінює статус на “Підтверджена заява” (draft, inactive→ active) та вважається Опублікованою.

...

draft

active

...

Автоматична дія.

Учасник має можливість:

• активувати заяву на участь (вперше, або повторно)
• видалити свою заяву на участь

...

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

...

draft

active

inactive

...

Ручна дія.

Учасник надсилає запит на зміну статуса Bid-а

АБО

Автоматична дія.

Організатор скасовує процедуру до початку МА

...

У разі видалення (анулювання) заяви на участь учасником вона набуває статус “Видалена заява” (deleted).

Скасувати свою заявку на участь є можливість тільки протягом tenderPeriod

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

...

Авард

Статуси учасників на етапі кваліфікації (awards)

...

Award’и формуються на ЦБД автоматично після заверешення аукціону, або за умови наявності одного учасника, одразу після завершення tenderPeriod

Максимально може бути сформовано чотири Аварди:

• один у статусі "Очікується оплата" - pending (1-й award)
• і до трьох у статусі "Очікується рішення" - pending_waiting (2,3,4-ті award-и)

...

Технічна назва

...

Бізнесова назва

...

Перехід з

...

За умови

...

Коментар

...

МА (переможець)

АБО

pending_waiting

...

...

• Завантаження протоколу (обв'язкова дія - з можливістю замінити протокол)
• Переведення статусу учасника до наступного статусу "Переможець. Очікується договір"
• Дискваліфікація учасника

Учасник має можливість:

• Завантажити та замінити протокол (не обов'язкова дія - з можливістю замінити  протокол)
  • Технічно учасник завантажує протокол тільки в свій Бід

...

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

Присвоюється наступним після переможця учасникам під час генерації авардів (до трьох Авардів може отримати цей статус)

(2,3,4-ті award-и)

...

Статус pending_waiting автоматично присвоюється наступним, після переможця за величиною ставки, учасникам під час генерації авардів.

Авардів, які отримують статус pending_waiting може бути від 0 до 3. Це залежить від кількості учасників, які подали валідні ставки протягом tenderPeriod і аукціону.

• Учасник, який після переможця, має другу за розміром ставку (2-й Award) НЕ може відмовитись від очікування і забрати свій гарантійний внесок.
• Учасники, які після переможця мають третю і четверту ставки (3-й і 4-й Awards) - можуть відмовитись від очікування, забрати свій Гарантійний внесок за умови, що завершився "Період очікування" (настала дата і час waitingPeriod.endDate)

...

Ручна дія.

Організатор підтверджує оплату і змінює статус award pending → active

...

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

Організатор має можливість:

• Завантаження договору (з можливістю замінити);
• Дискваліфікація учасника (до завершення аукціону);
• Завершення аукціону.

Учасники мають можливість:

• Учасник, який після переможця, має другу за розміром ставку (2-й Award) НЕ може відмовитись від очікування і забрати свій гарантійний внесок.
• Учасники, які після переможця мають третю і четверту ставки (3-й і 4-й Awards) - можуть відмовитись від очікування, забрати свій Гарантійний внесок за умови, що завершився "Період очікування" (настала дата і час waitingPeriod.endDate)

...

pending_waiting

...

Ручна дія.

Учасники, які після переможця мають третю і четверту ставки (3-й і 4-й Awards) мають статус pending_waiting можуть відмовився від очікування після waitingPeriod.endDate. Їх Аварди набувають статус cancelled

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

Процедура набула термінального статусу complete та учасники, які мають Авард 2,3 і 4 в статусі pending_waiting → cancelled

...

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

...

pending

АБО

active

Ручна дія.

Організатор дискваліфікує переможця і надсилає запит на зміну award.status: pending → unsuccessful

Організатор не підписує договір з переможцем і надсилає запит на зміну award.status: active → unsuccessful

...

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

1. pending → unsuccessful:

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

При зміні статуса з pending → unsuccessful ЦБД має валідувати, що заповнено awards.terminationReason значенням зі словника

2. active → unsuccessful:

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

При зміні статуса з active → unsuccessful ЦБД має валідувати, що заповнено awards.terminationReason значенням зі словника

При цьому contracts автоматично змінить свій статус на cancelled

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

Я так розумію тут 1 в 1 документи як в приватизації? і щось навіть не знаю, жодного обовʼязкового документу? точно? 

Заява на участь

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

Деактивуємо заяву на участь якщо редагується процедура? Не бачив про це нічого в нормативці, і в звичайній приватизації є тільки три статуса: deleted, active, draft

Схема приватизації - Модель статуса заяви на участь (біда) у процедурі Мала приватизація

Схема NLE - Image Added

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

Авард

Статуси учасників на етапі кваліфікації (awards)

як я поняв відмови від очікування немає

Award’и формуються на ЦБД автоматично після заверешення аукціону, або за умови наявності одного учасника, одразу після завершення tenderPeriod

Якщо авардів більше 1, вони формуються наступним чином: 

• один у статусі "Очікується оплата" - pending (1-й award)
• інші в статусі "Очікується рішення" - pending_waiting (2,3,4-ті award-и)

Періоди Award

"paymentPeriod": {
	"endDate": {
		"diff": "10 business days",
		"direction": "forward",
		"from": "now"
	},
	"startDate": {
		"from": "now"
	}
}

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

Документи Аварду

redemptionDecision - потрібен документ викупу? 

Умови вибору переможця

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

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

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

ЦБД формує award'и для інших учасників (за наявності) з найвищими ставками:

• Найвища ставка - отримує Award у статусі pending (1-й award)
• Наступні валідні ставки (за наявності) - отримують статус pending_waiting 

Особливості:

• У випадку, якщо ставка учасника не є валідною, формування award'у для такого учасника не здійснюється
• Якщо авард учасника вже в статусі pending_waiting, вони не можуть відмовитись від очікування 

ЦБД формує contracts[] для Переможця у статусі pending також одразу при переході процедури у статус pending_payment

Публікація протоколу

Очікується опублікування протоколу - дописати логіку

Періоди Award

...

Технічна назва

...

Бізнесова назва

...

Дата початку

...

Дата завершення

...

Результат завершення

...

Коментар

...

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

...

"paymentPeriod": {
	"endDate": {
		"diff": "10 business days",
		"direction": "forward",
		"from": "now"
	},
	"startDate": {
		"from": "now"
	}
}

...

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

...

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

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

Документи Аварду

...

documentType

...

Назва Українською

...

Назва Англійською

...

Опис

...

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

...

Публічність

...

Завантажується у разі дискваліфікації учасника (окремо зазначається причина), за умови прийняття рішення Організатором;

...

Так

Для зміни awards.status: pending → unsuccessful

...

Завантажується у разі дискваліфікації учасника (окремо зазначається причина: відмова Переможцем підписувати договір/протокол), за умови прийняття рішення Учасником.

Документ має бути можливість завантажити у Організатора та у Переможця.

Для того, щоб Організатор дискваліфікував учасника, Авард якого перебуває у статусі pending або protocol_signed, має бути завантажено хоча б один документ з documentType: act 
В поле terminationReason аварду записується причина із довідника

Поле terminationReason має бути обов'язково заповнено для зміни awards.status: pending → unsuccessful

...

Так

Для зміни awards.status: pending → unsuccessful

...

Ні

...

Умови вибору переможця

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

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

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

ЦБД формує award'и для 4 учасників (за наявності) з найвищими ставками:

• Найвища ставка - отримує Award у статусі pending (1-й award)
• Наступні три валідні ставки (за наявності) - отримують статус pending_waiting (2, 3, 4-й award’и)

Особливості:

• У випадку, якщо ставка учасника не є валідною, формування award'у для такого учасника не здійснюється
• Учасник з 2-м award`ом (друга, після переможця ставка) не може відмовитися від очікування і отримати свій гарантійний внесок до отримання процедурою термінального статусу (complete, cancelled або unsuccessful)
• Учасники з 3-м і 4-м award-ом можуть відмовитись від очікування, забрати свій гарантійний внесок, втрачаючи шанс стати переможцем аукціону, лише після завершення періоду очікування (waitingPeriod).

В кабінеті Учасника має бути реалізовано кнопку “Відмовитись від очікування”, натискання якої передає award'y статус cancelled.

Якщо кнопку "Відмовитись від очікування" натисне 2-й Award, то ЦБД поверне помилку: "Cannot discqualify award that comes next to active award object with status pending_waiting"

ЦБД формує contracts[] для Переможця у статусі pending також одразу при переході процедури у статус pending_payment

Період очікування (waitingPeriod)

Розпочинається одночасно з кваліфікацією переможця за умови його наявності.

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

Результатом існування waitingPeriod є:

Учасники, для яких було створено 3-1 і 4-й Аварди (якщо вони наявні) отримують можливість відмовитись від очікування тільки після завершення waitingPeriod

Організатор має можливість зменшити тривалість waitingPeriod за потреби. Щоб достроково завершити період очікування, Організатор повинен: - Натиснути кнопку “Завершити період очікування”

Внаслідок виконання даної дії майданчик надсилає запит на PATCH процедури, де передає waitingPeriod.endDate

Якщо waitingPeriod.startDate < передане значення < waitingPeriod.endDate та waitingPeriodUpdated = false, то ЦБД змінює:

• значення дати завершення періоду очікування waitingPeriod.endDate на значення, було передано Організатором
• значення ідентифікатора зміни періоду очикування waitingPeriodUpdated на true

У Організатора є можливість лише один раз змінити waitingPeriod.endDate. Поле waitingPeriodUpdated - це ознака того, чи змінював Організатор дату завершення періоду очікування

Якщо дата waitingPeriod.endDate вже в минулому, то учасники з 3 та 4 award-ами в статусі ”Очікує рішення” pending_waiting можуть відмовитися від очікування.

В разі відмови статус award’у змінюється з pending_waiting →  cancelled “Учасник не став переможцем”

Можливий сценарій

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

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

• Авард 1: Переможець, який зробив найбільшу ставку. Його Авард отримує статус pending
• Авард 2: Учасник, який зробив другу за величиною ставку (або просто пізніше) після Переможця. Його Авард отримує статус pending_waiting
• Авард 3: Учасник, який зрбив третю після переможця за величиною ставку. Його Авард отримує статус pending_waiting
• Авард 4: Учасник, який зрбив четверту після переможця за величиною ставку. Його Авард отримує статус pending_waiting

В JSON всі чотири Аварди будуть розташовані за величиною ставки: від переможця - до учасника з найменшою ставкою

В той самий момент, коли почалася кваліфікація і авто-згенерувалися Авари, ЦБД також автоматично генерує watinigPeriod в процедурі і встановлює waitingPeriod.startDate == момент початку кваліфікації та waitingPeriod.endDate == waitingPeriod.startDate + 30 кд

Поки триває waitingPeriod, Авард 2, Авард 3 і Авард 4 не мають можливості відмовитись від очікування (змінити Awards[].status: pending_waiting → cancelled). ЦБД буде повертати помилку при спробі надіслати запит на зміну статусу Аварда.

Після завершення waitingPeriod, Авард 2 і далі не буде мати можливості відмовитись від очікування. Єдина можливість повернути ГВ для Аварда 2, це дочекатися Успішної кваліфікації Переможця, або скасування процедури.

Але після завершення waitingPeriod, Авард 3 і Авард 4 отримають можливість відмовитись від очікування (змінити Awards[].status: pending_waiting → cancelled) і звернутись до Майданчика з запитом "повернути ГВ"

Якщо Організатор дискваліфікує Переможця (Авард 1), то він отримує статус unsuccessful, а Авард 2 набуде статусу pending і розпочнеться його кваліфікація. При чому, Авард 3 і Авард 4 НЕ втрачають можливості відмовитись від очікування по завершенню waitingPeriod. Правило "відсутність можливості відмовитись від очікування" працює тільки для Учасника, який зробив другу за величиною ставку (Авард 2) і не переходить на наступних учасників навіть за умови дискваліфікації попередніх.

...

На майданчиках відображається інформація про учасників, що кваліфікуються:

...

Підтвердження оплати

Процедура набула статусу pending_payment і розпочалась кваліфікація розпочалось очікування оплати від переможця.

Award переможця отримав статус pending та в Аварді сформувався “Період оплати” (award.paymentPeriod)

Contract переможця також сформувався одночасно з Авардом і отримав статус “Очікується договір” - pending також сформувався одночасно з Авардом і отримав статус “Очікується договір” - pending отут треба уточнення, коли саме має формуватись цей договір. я думаю після публікації протоколу, ні? або можна як зазвичай одразу після переходу процедури в статус active_qualification

Для завершення роботи з оплатою Організатору потрібно:

Все що нижче перепровірити в нормативці

• Вказати дату сплати коштів за лот. Для цього необхідно надіслати запит на PATCH contracts.datePaid 

  Expand
  title приклад
  curl --location --request PATCH 'https://procedure-sandbox.prozorro.sale/api/procedures/69158092f559f36d2b2bc667/contracts/c1cd945b2f624cddb6da32ebaa25b1eb?acc_token=f9df0ca4-5992-4ac9-9852-4f605665b710' \ --header 'Authorization: *****************' \ --header 'Content-Type: application/json' \ --data '{     "datePaid": "2025-11-15T13:30:37.413Z" }'

• Завантажити в систему документ що підтверджує оплату documentType: paymentDetails (не обов’язкова дія). Для цього необхідно надіслати запит на POST contracts.documents[] 

  Expand
  title приклад
  curl --location 'https://procedure-sandbox.prozorro.sale/api/procedures/69158092f559f36d2b2bc667/contracts/c1cd945b2f624cddb6da32ebaa25b1eb/documents?acc_token=f9df0ca4-5992-4ac9-9852-4f605665b710' \ --header 'Authorization: ************' \ --header 'Content-Type: application/json' \ --data '{     "token": "eyJ0eXAiOiJK**********zm4Ag",     "title": {         "uk_UA": "Квитанція про оплату"     },     "description": {         "uk_UA": "Квитанція про оплату"     },     "documentOf": "contract" }'

• Натиснути кнопку “Підтвердити оплату” - це запит на зміну статусу Аварду pending → active 

  Expand
  title приклад
  curl --location --request PATCH 'https://procedure-sandbox.prozorro.sale/api/procedures/69158092f559f36d2b2bc667/awards/8baec7bf04904805baeb637fd9381777/status?acc_token=f9df0ca4-5992-4ac9-9852-4f605665b710' \ --header 'Authorization: **************' \ --header 'Content-Type: application/json' \ --data '{     "status": "active" }'

...

Перелік причин дискваліфікації terminationReason: - це ж стандартні причини? 

"1": {
	"en_US": "Refused to sign the contract/protocol",
	"uk_UA": "Відмовився від підписання договору/протоколу"
},
"2": {
	"en_US": "The winner of the auction is a debtor and/or guarantor under credit agreements and agreements to ensure the fulfillment of obligations",
	"uk_UA": "Переможець аукціону є боржником та/або поручителем за кредитними договорами та договорами забезпечення виконання зобов'язань"
},
"3": {
	"en_US": "Knowingly gave false information",
	"uk_UA": "Свідомо надав неправдиву інформацію"
},
"4": {
	"en_US": "Full payment for the lot was not made on time/the winner refused to pay",
	"uk_UA": "Повна оплата коштів за лот не здійснена в строк/відмовився від оплати"
},
"5": {
	"en_US": "The winner of the auction participated in auctions from several marketplace",
	"uk_UA": "Переможець аукціону брав участь в аукціонах з кількох майданчиків"
},
"6": {
	"en_US": "Other",
	"uk_UA": "Інше"
}

...

Якщо award в статусі pending або active дискваліфіковують, учасник з наступною за величиною цінової пропозиції з award'ом в статусі pending_waiting набуває статусу pending та проходить процедуру кваліфікації по такому самому принципу як попередній переможець (процедура знову набуває статус "Очікується оплата" (active_awarded → pending_payment). Період кваліфікації qualificationPeriod формується повторно з усіма вкладеними періодами (award.signingPeriod, award.paymentPeriod) - тут треба б уточнити, чи переноситься ця логіка

Договір

Статуси Contracts

...

Модель статусів контракту великої приватизації - англійський аукціон - беремо оце? наче як ок, в нормативці ні слова про якісь відхилення 

...

Документи contract

Незрозуміло, що тут має бути. Приватизація - contractNotice, contractSigned, contractAnnexe, preliminaryContract, digitalSignature

...

• Завантажити договір (documentType:contractSigned) 
• Завантажити протокол (documentType:auctionProtocol) - протокол має бути завантажений раніше, але чи лишаємо цю валідацію? 
• Заповнити обов'язкову інформацію договору:
  • Назва договору

  • Опис

  • Дата підписання

  • Номер договору

• Натиснути на кнопку “Підтвердити договір” (Надіслати запит на зміну статусу Contract: pending → active) - це робимо? 

Результатом етапу підписання договору є:

...

До переведення договору в статус active Організатор має можливість виправити поля договору та вкладені файли. - що по редагуванню? 

Пролонгація

Про пролонгацію не слова. Видаляємо?

Статус процедури: active_awarded
Період аварду: award.signingPeriod

...

Пролонгація періоду підписання договору

Про пролонгацію не слова. Видаляємо?

Процедура знаходиться в статусі “Очікується підписання договору” active_awarded, статус award’у “Переможець” active, статус contract`у “Очікується договір” pending.

...

Для публікації оголошення Організатор повинен: -

• заповнити поля процедури (частина полів заповнюються системою автоматично), повний перелік полів за посиланням: https://procedure-staging.prozorro.sale/api/doc#

...

• вказати дату проведення аукціону auctionPeriod_startDate (тривалість періоду tenderPeriod мінімум 7 календарних днів не враховуючи дня публікації процедури)

...

• натиснути кнопку “Опублікувати оголошення”

Внаслідок чого статус процедури змінюється на “Прийняття заяв на участь” active_tendering.
У Організатора аукціону є можливість оголосити аукціон на основі попереднього аукціону (створити копію будь-якого аукціону у будь-якому статусі).

...

1. завантажити документ "Погодження змін до опису лоту. Опис причин редагування." (documentType:clarifications), що містить перелік змін, які вносяться в оголошення, причину внесення таких змін - тут питання, чи це потрібно
2. внести зміни до полів процедури (крім технічних полівполів - мається на увазі що? міняємо опис процедури, опис лоту? відповідно до МП робимо можливість редагування?) та/або завантажити/замінити документи оголошення
3. ініціювати збереження внесених змін.
   У випадку внесення змін в поля процедури статус заяв на участь (bid’а) змінюється з active на inactive статус процедури залишається незмінним. - питання чи це буде
   У випадку завантаження/зміни документів статус заяв на участь та процедури залишається без змін. - додаткове питання, чи це буде
   Організатор аукціону може завантажувати документи оголошення протягом усього періоду прийняття пропозицій tenderPeriod.

сінк що з цього має лишитись 

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

...

Посилання на схему «Обговорення електронних аукціонів (запитання-відповідь)»

Розміщення заяви на участь

...

sanctionedAssets-english

Робота із заявою на участь

Процедура знаходиться в статусі “Прийняття заяв на участь” active_tendering, Учасник пройшов реєстрацію на майданчику.
Для участі в аукціоні Учаснику необхідно: -

• сплатити гарантійний внесок

...

• сплатити реєстраційний внесок, якщо лотом є майно банку

...

• заповнити поля заяви https://procedure-staging.prozorro.sale/api/doc#

...

• завантажити необхідні документи

...

• вказати закриту цінову пропозицію (сума коштів закритої цінової пропозиції>= початкова ціна лота/ціна реалізації)

...

• тут може дорівнювати початковій ціні? 
• ініціювати надсилання заяви на розгляд Оператору майданчика.

Внаслідок виконаних дій створюється заява bid в статусі draft, статус процедури залишається незмінним. Заява у статусі draft не може брати участь в аукціоні.
Для участі Учасника в аукціоні Оператору необхідно:-

• перевірити виконання умов Організатора та наявність гарантійного внеску (та реєстраційного внеску, якщо лотом є майно банку)

...

• активувати заяву.

Внаслідок виконаних дій статус заяви (bid’а) змінюється з draft на active, статус процедури залишається незмінним. Після активації заяви Учасник може змінювати суму закритої цінової пропозиції. Зміна суми закритої цінової пропозиції не призводить до зміни статусу заяви (bid’а).

...

• За наявності лише 1 заяви на участь та minNumberOfQualifiedBids=1 за результатами етапу подання пропозицій, процедура одразу набуває статусу кваліфікації, з урахуванням Особливостей процедури.
• За наявності лише 1 заяви на участь та minNumberOfQualifiedBids=2 за результатами етапу подання пропозицій, процедура одразу набуває статусу unsuccessful. - вирішити чи можна змінювати мінімальну кількість учасників 
• За наявності 2-х та більше заяв на участь та minNumberOfQualifiedBids=1,2 за результатами етапу подання пропозицій, спочатку процедура набуває статусу active_auction, а вже за результатами аукціону статусу кваліфікації, в разі подання валідних ставок (стартова + крок).

У випадку переходу аукціону у статус Аукціон не відбувся (unsuccessful) або Аукціон скасовано (cancelled) - не забути поправити тут в разі відсутності скасування після тендер періода, до завершення періоду аукціону (auctionPeriod), ставки учасників залишаються закритими для всіх, включаючи Організатора аукціону і доступні виключно для майданчика, який розмістив ставку у ЦБД.

Перелік типів документів даного етапу
Перелік періодів та статусів етапу та посилання на їх опис
Умови скасування заяви
Інформація про отримання посилання на аукціон
Посилання на схему «Розміщення закритої цінової пропозиції»

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

...

sanctionedAssets-english

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

Для скасування Організатор аукціону зобов’язаний передати:

• Документ (documentType:cancellationDetails)
• Причину скасування (cancellation.reason) (Організатор аукціону вказує вручну) - нормативка мовчить
• Фактичну дату скасування (cancellations.date)

Перелік типів документів даного етапу
Типи, опис документів та робота з ними nonperformingLoans-english
Перелік періодів та статусів етапу та посилання на їх опис
Функціонал ролей в рамках періодів nonperformingLoans-english

Аукціон

...

sanctionedAssets-english

ТЗ з модулю аукціону

Послідовний раунд (англійський)**

...

Перелік періодів та статусів етапу та посилання на їх опис
Функціонал ролей в рамках періодів nonperformingLoanssanctionedAssets-english - чи це треба чи ні
Формування протоколу Аукціону

...

Swagger UI
Ендпоінт із ліглнеймами періодів, статусів - знайти посилання
Ендпоінт з класифікаторами
Ендпоінт зі словниками

...

Схеми процедури

Перелік схем:

Перемалювати схеми після узгодження всіх моментів 

1. Timeline процедури nonperformingLoans-english ЦБД-3
2. Схема "Загальний процес аукціонів" nonperformingLoans-english
   • Схема "Зміна статусів процедури" nonperformingLoans-english
3. Схема "Публікація оголошення та прийняття заяви про участь" nonperformingLoans-english (ЦБД-3)
   • Схема "Робота із заявою на участь" nonperformingLoans-english ЦБД-3
   • Схема "Обговорення електронних аукціонів (запитання-відповідь)" nonperformingLoans-english (ЦБД-3)
   • Схема "Розміщення закритої цінової пропозиції" nonperformingLoans-english (ЦБД-3)
   • Схема "Відміна аукціону" nonperformingLoans-english ЦБД-3
4. Схема "Аукціон" nonperformingLoans-english ЦБД-3
   • Схема "Оголошення раунду" nonperformingLoans-english ЦБД-3
5. Схема "Кваліфікація (робота з договором та протоколом)" nonperformingLoans-english ЦБД-3
   • Award`s timeline процедури nonperformingLoans-english ЦБД-3
   • Схема "Пролонгація аукціону" nonperformingLoans-english ЦБД-3
   • Схема "Зміна статусів авардів" nonperformingLoans-english

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

...

sanctionedAssets-english

Типи процедур для тестування

...