...
Протягом періоду редагування (rectificationPeriod) та Періоду прийняття заяв на участь (tenderPeriod) Організатор процедури може завантажувати та замінювати документи оголошення (procedure.documents[])
Періоди процедури
Технічна назва | Статус процедури | Бізнесова назва | Дата початку | Дата завершення | Результат завершення | Коментар |
|---|---|---|---|---|---|---|
| rectificationPeriod | active_tendering |
| Період редагування | Дата та час публікації процедури в ЦБД |
. | може припадати на неробочий день, завершується за 5 календарних днів до завершення періоду подання пропозицій, час завершення о 18:00 |
18:00 |
Статус процедури змінюється:
active_rectification → active_tendering
Редагування полів після завершення періоду процедури більше недоступне | Період "Період редагування" починється одразу, як тільки відбувається публікація процедури в ЦБД | |
| tenderPeriod | active_tendering | Період подання пропозицій |
Дата та час публікації процедури в ЦБД. | о 20:00 в день, що передує дню початку періоду аукціону auctionPeriod.startDate (може припадати на НЕробочий день) | Статус процедури змінюється автоматично: active_tendering → active_auction Статус процедури змінюється вручну організатором: | Період " |
| Період редагування" починється одразу, як тільки |
| відбувається публікація процедури в ЦБД | |
| questionPeriod | active_tendering |
| Період запитань | Дата та час публікації процедури в ЦБД. | Може припадати на НЕробочий день. о |
18:00 за 1 р.д. до початку аукціону | - | ||
| enquiryPeriod | active_tendering | Період відповідей | Дата та час публікації процедури в ЦБД. |
Може припадати на НЕробочий день. о 18:00 за 1 р.д. до початку аукціону | - | ||
| auctionPeriod | active_auction | Аукціон | Завжди припадає на робочий день. Вказується організатором при публікації процедури. |
ЦБД приймає тільки auctionPeriod.startDate >= datePublished + к.д.
Точна дата та час (часовий діапазон з 11:00 - 13:00) | Подія завершення аукціону (роботи модуля аукціону) може припадати на НЕробочий день. |
Статус процедури змінюється автоматично: active_auction → qualification Статус процедури змінюється вручну організатором: | auctionPeriod.endDate присутній виключно за умови наявності не менш ніж 2 заяв на участь (bids[].status: active) на момент tenderPeriod.endDate | |||
| qualificationPeriod | active_qualification active_awarded | Період кваліфікації | qualificationPeriod.startDate == auctionPeriod.endDate | Не може припадати на НЕробочий день. Автоматично не переводимо в інші статуси |
20 р.д. о 18:00 | На рівні ЦБД: відсутній На рівні майданчика: за 24 години до завершення, надсилання повідомлення Організатору про завершення періоду кваліфікації. |
**Всі періоди кваліфікації завершуються Організатором аукціону вручну (не автоматична дія), але повинна бути реалізована фіксація порушення строків
Статуси процедури
...
Статус процедури змінюється автоматично при умові відсутності awards в статусі active : active_auction → qualification Статус процедури змінюється вручну організатором:
| Формується за наявності переможця за результатами проведеного аукціону (період аукціону) або після періоду подання пропозицій, за наявності лише 1 заяви на участь, тривалість періоду до 20 робочих днів (не включаючи день проведення аукціону), період завершується вручну Організатором аукціону. Формується повторно з усіма вкладеними періодами за наявності 2-го учасника в якості переможця (в момент дискваліфікації 1-го учасника). |
**Всі періоди кваліфікації завершуються Організатором аукціону вручну (не автоматична дія), але повинна бути реалізована фіксація порушення строків
Статуси процедури
| draw.io Diagram | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Технічна назва | Бізнесова назва | Перехід з | За умови | Коментар |
|---|---|---|---|---|
| active_tendering | Прийняття заяв на участь | момент публікації оголошення в ЦБД | Автоматично. Заповнені всі обовʼязкові поля для створення процедури в ЦБД | Майданчик Організатора робить запит до ЦБД та передає об'єкт процедури. У разі правильно сформованого об'єкта процедури, ЦБД повертає майданчику id та token створеного об'єкта процедури, процедура набуває статус "Прийняття заяв на участь" (active_tendering). |
| active_auction | Аукціон | active_tendering | Автоматично. Завершився період Прийняття заяв на участь (кількість учасників не менша ніж вказано Організатором) | На момент завершення періоду "Прийняття заяв на участь"виконана умова переходу процедури для набуття статусу "Аукціон" (active_auction). |
| active_qualification | Очікується опублікування протоколу | active_auction | Автоматично. Завершилась робота Модуля аукціону (настав момент auctionPeriod.endDate) | Для кожного учасника, що мав bids[].status == active на момент auctionPeriod.startDate, в обʼєкті процедури створюється Award у статусі pending АБО pending_waiting (деталі розподілу в розділі Статуси Awards). Для award у статусі pending відбувається 1 фаза кваліфікації переможця (робота із протоколом) Аварди в статусі unsuccessful свій статус не змінюють. |
| active_awarded | Очікується підписання договору | active_qualification | Ручна дія. Організатор надсилає запит на зміну status: active_qualification → | |
Технічна назва | Бізнесова назва | Перехід з | За умови | Коментар |
| active_rectification | Редагування доступне | момент публікації оголошення в ЦБД | Ручна дія. Заповнені всі обовʼязкові поля для створення процедури в ЦБД | Майданчик Організатора робить запит до ЦБД та передає об'єкт процедури. У разі правильно сформованого об'єкта процедури, ЦБД повертає майданчику id та token створеного об'єкта процедури, процедура набуває статус "Редагування доступне" (active_rectification). |
| active_tendering | Прийняття заяв на участь | active_rectification | Автоматично. Настав момент rectificationPeriod.endDate | Завершився Період редагування (rectificationPeriod), почався період Прийняття заяв на участь (tenderPeriod) |
| active_qualification | Очікується опублікування протоколу | active_auction | Автоматично. Завершилась робота Модуля аукціону (настав момент auctionPeriod.endDate) | Для кожного учасника, що мав bids[].status == active на момент auctionPeriod.startDate, в обʼєкті процедури створюється Award у статусі pending АБО pending_waiting (деталі розподілу в розділі Статуси Awards). Для award у статусі pending відбувається 1 фаза кваліфікації переможця (робота із протоколом) Аварди в статусі unsuccessful свій статус не змінюють. |
| active_awarded | Очікується підписання договору | active_qualification | Ручна дія. Організатор надсилає запит на зміну status: active_qualification → active_awarded | По завершенню роботи із протоколом, Організатор натискає кнопку “Протокол затверджено”, статус процедури змінюється на “Очікується підписання договору” (active_awarded) - 2 фаза кваліфікації переможця, а саме в частині роботи із договором. |
| complete | Аукціон завершено | active_qualification | Ручна дія. Організатор надсилає запит на зміну status: active_awarded → complete | Термінальний статус. При виконанні дії зміни статуса на complete ЦБД перевіряє:
|
| unsuccessful | Аукціон не відбувся | active_tendering active_qualification active_awarded | Автоматично.
| Термінальний статус. |
cancelled | Аукціон скасовано | active_rectification active_tendering active_qualification active_awarded | Ручна дія. Організатору у всіх статусах Процедури, окрім термінальних статусів, доступна опція "Скасування" Процедури. Для скасування процедури, Організатору необхідно:
Після цього, при натисканні кнопки, надсилається запит в ЦБД на скасування. Статус процедури автоматично змінюється → cancelled | Термінальний статус. |
...
documentType | Назва Укр | Назва Анг | Опис | Обовʼязковіть для публікації процедури | Публічність |
|---|---|---|---|---|---|
| illustration | Ілюстрації | Illustration | Зображення, що можуть додаватися Організатором до процедури | Так | Так |
| notice | Паспорт торгів | Auction notice | Офіційне повідомлення, що містить деталі аукціону | Ні | Так |
| technicalSpecifications | Копії документів та матеріалів на лот | Technical specificatons | Детальна інформація про лот | Ні | Так |
| evaluationCriteria | Кваліфікаційні вимоги | Evaluation criteria | Вимоги до потенційних учасників аукцціону | Ні | Так |
| contractProforma | Типова форма договору про надання послуги | Contract proforma | Типова форма договору про надання послуги | Ні | Так |
| x_presentation | Презентація | Presentation | Презентація | Ні | Так |
| property_doc | Документи на майно | Property documents | Документи що підтверджують право власності організатора на лот, відсутність встановлених законом обтяжень (обмежень), відсутність встановлення законом обтяжень (обмежень) та заборон на відчудження лотів | Так, якщо організатор ФОП (sellingEntity.identifier.scheme - всі значення крім UA-EDR зі схеми ua_identifier) | Так |
| clarifications | Погодження змін до опису лоту. Опис причин редагування. | Clarifications | Документ не потрібно вносити до списку документів при створенні аукціону. Має бути доступний для завантаження в rectificationPeriod | Ні (обов'язковий лише для внесення змін в поля лоту) | Так |
| digitalSignature | Цифровий підпис | Digital signature | Цифровий підпис | Ні | Набуває значення документу з яким позв'язаний |
Скасування аукціону
Рішення Організатора про відміну аукціону повинне бути викладене у формі розпорядчого акта (рішення, наказу, розпорядження, протоколу тощо)
...
У разі відміни аукціону ЦБД автоматично присвоює аукціону статус “аукціон не відбувся”“Аукціон відмінено”.
Деталі описано тут
Документи скасування процедури (cancellations.documents)
...
| draw.io Diagram | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Технічна назва | Бізнесова назва | Перехід з | За умови | Коментар |
|---|---|---|---|---|
| draft | Чернетка заяви | момент публікації заявки в ЦБД | Ручна дія. Учасник надсилає запит на публікацію Bid-а | Публікація заяви на участь доступна тільки протягом tenderPeriod-а процедури. Мають бути заповнені:
Опублікувати бід можна без документів, але без обовʼязкових документів не буде можливості активувати Біда. Майданчик Учасника робить запит до ЦБД та передає об'єкт заяви на участь. У разі правильно сформованого об'єкта заяви на участь, ЦБД повертає майданчику token для активації заяви на участь, заява на участь набуває статус “Чернетка заяви” (draft). |
| active | Підтверджена заява | draft | Ручна дія. Учасник надсилає запит на зміну статуса Bid-а | Мають бути заповнені обовʼязкові поля:
та обовʼязкові документи Майданчик Учасника надсилає запит на активацію заяви на участь в ЦБД, заява на участь змінює статус на “Підтверджена заява” (active) та вважається опублікованою. |
| inactive | Деактивована заява | draft | Ручна дія. Учасник має можливість:
| У разі редагування оголошення (поля + документи) Організатором, заяви на участь (у статусах draft та/або active) учасників автоматично переходять у статус inactive. Таку заяву на участь можна повторно перевести у статус active. Або анулювати за бажанням учасника. |
| deleted | Видалена заява | active | Ручна дія. Учасник надсилає запит на зміну статуса Bid-а | У разі анулювання заяви на участь учасником вона набуває статус “Видалена заява” (deleted). Скасувати свою заявку на участь є можливість тільки протягом tenderPeriod |
Документи заяви на участь (bids.documents)
documentType | Назва Українською | Назва Англійською | Опис | Обовʼязковіть для активації bid-а | Публічність |
|---|---|---|---|---|---|
| commercialProposal | Заява на участь | bid | Заява на участь | Ні | Так |
| x_passport | Копія паспорта або документу, що посвідчує особу | Passport or identity document | Паспорт або інший |
Необхідно передбачити можливість Учаснику додавати і замінювати документи в bids[x].documents, коли бід знаходиться у статусі active. Після завершення роботи МА у Учасника такожм має бути можливість додавати і замінювати документи протягом періоду Процедури qualification та active_qualification.
Кваліфікація
За результатами періоду аукціону (auctionPeriod) пропозиції сортуються від меншої ціни до більшої, а у випадку співпадіння ціни, вище відображається пропозиція розміщена раніше. Часом розміщення пропозиції вважається час першого розміщення заяви у ЦБД, а, у випадку редагування пропозиції під час періоду прийому пропозицій, час фіксації змін у заяві у ЦБД. По завершенню аукціону, процедура переходить у статус qualification - фазу перевірки документів учасників. ЦБД генерує award'и для N учасників у статусі verification. award'и формуються для всіх учасників, відповідно до поданих кількості заяв на участь. Валідною ставкою вважається та, що рівна або менша за значення value.amount.
Періоди Awards
...
Технічна назва
...
Бізнесова назва
...
Дата початку
...
Дата завершення
...
Результат завершення
...
Коментар
...
В момент набуття Авардом статуса pending
...
Період формується в Аварді з моменту набуття Авардом статусу pending
Якщо Авард був у статусі pending і отримав signingPeriod, то після зміни статуса на інший (protocol_signed, active OR unsuccessful) період залишається незмінним.
Аварди в інших статусах цей період не отримують.
| документ що посвідчує особу (для фізичної особи нерезидента) | Ні | Ні | |||
| x_IPN | Копія РНОКПП | RNTRC | Копія ІПН | Ні | Ні |
| x_tenderersRegisterExtract | Витяг ЄДРПОУ | Register extract | Копія витягу з ЄДРПОУ або копыю документа про реэстрацію у державі її місцезнаходження (витяг із торговельного, банківського або єдиного реєстру, тощо) | Ні | Так |
| x_nonResidentRegistrations | Документ про реєстрацію у державі її місцезнаходження (для юридичних осіб - нерезидентів) | Non Resident Registrations | Копія документа про реєстрацію у державі її місцезнаходження (для юридичної особи-нерезидента) | Ні | Так |
| x_registrationFeeApproval | Документ, що підтвкрджує сплату реєстраційного внеску | Registration fee approval | Документ, що підтвкрджує сплату реєстраційного внеску | Ні | Так |
| x_guaranteeApproval | Документ, що підтверджує сплату гарантійного внеску | Guarantee approval | Документ, що підтверджує сплату гарантійного внеску | Ні | Так |
| qualificationDocuments | Документи, що підтверджують відповідність вимогам | Qualification document | Документи, що підтверджують відповідність вимогам | Ні | Так |
| digitalSignature | Цифровий підпис | Digital signature | Цифровий підпис | Ні | Набуває значення документу з яким позв'язаний |
Кваліфікація
За результатами періоду аукціону (auctionPeriod) пропозиції сортуються від меншої ціни до більшої, а у випадку співпадіння ціни, вище відображається пропозиція розміщена раніше. Часом розміщення пропозиції вважається час першого розміщення заяви у ЦБД, а, у випадку редагування пропозиції під час періоду прийому пропозицій, час фіксації змін у заяві у ЦБД. По завершенню аукціону, процедура переходить у статус qualification - фазу перевірки документів учасників. ЦБД генерує award'и для N учасників у статусі verification. award'и формуються для всіх учасників, відповідно до поданих кількості заяв на участь. Валідною ставкою вважається та, що рівна або менша за значення value.amount.
Періоди Awards (ПЕРЕВІРИТИ)
Технічна назва | Бізнесова назва | Дата початку | Дата завершення | Результат завершення | Коментар |
|---|---|---|---|---|---|
| awards.signingPeriod | Період підписання протоколу та договору | В момент набуття Авардом статуса pending | signingPeriod.endDate == signingPeriod.startDate + 15 р.д. | На рівні ЦБД: відсутній | Період формується в Аварді з моменту набуття Авардом статусу pending Якщо Авард був у статусі pending і отримав signingPeriod, то після зміни статуса на інший (protocol_signed, active OR unsuccessful) період залишається незмінним. Аварди в інших статусах цей період не отримують. |
| awards.admissionPeriod | Період прийняття рішення щодо набуття статусу переможця | В момент набуття Авардом статуса pending_admission | admissionPeriod.endDate == admissionPeriod.startDate + 5 хвилин. | На рівні ЦБД: Статус аварда автоматично змінюється з pending_admission → cancelled | Період формується для Авардів у статусі pending_admission і продовжує відображатись в Аварді після зміни його статуса на будь-який інший. |
Статуси Awards
| draw.io Diagram | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Технічна назва | Бізнесова назва | Перехід з | За умови | Коментар |
|---|---|---|---|---|
| pending | Очікується протокол | Автоматично. Присвоюється переможцю під час генерації авардів | Організатор має можливість:
Учасник має можливість:
| |
| pending_waiting | Очікується рішення | Автоматично. Присвоюється 2-му (після переможця) учаснику під час генерації авардів | Статус pending_waiting автоматично присвоюється 2-му (після переможця) учаснику під час генерації авардів 2й учасник має можливість відмовитися від очікування (до моменту дискваліфікації 1-го учасника та за умови, що процедура у не термінальному статусі) | |
| active | Переможець. Очікується договір | protocol_signed | Організатор підтверджує підписання протоколу і award змінює свій статус з pending на active. | Термінальний статус. Організатор має можливість:
2й Учасник має можливість:
Якщо змінився contracts.status: pending → active, це означає, що завантажено Підписаний договір (contracts.documents.documentType: contractSigned) |
| cancelled | Учасник не став переможцем | pending_waiting |
| Термінальний статус. |
| unsuccessful | Дискваліфіковано | pending |
...
В момент набуття Авардом статуса pending_admission
...
На рівні ЦБД: Статус аварда автоматично змінюється з pending_admission → cancelled
...
Статуси Awards
...
Технічна назва
Бізнесова назва
Перехід з
За умови
Коментар
waiting
АБО
pending_waiting
АБО
pending_admission
Автоматично.
Завершився verificationPeriod.endDate: waiting → pending
АБО
Автоматично.
Дискваліфіковано Авард у статусі pending АБО protocol_signed протягом qualificationPeriod: pending_waiting → pending
АБО
Ручна дія.
pending_admission → pending: Учасник погодився закрити залишок обсягу
Перехід із waiting:
Статус pending отримують Аварди, які перебувають перші у списку результатів Модуля Аукціону і які успішно пройшли етап перевірки документів (award.status <> unsuccessful) за умови, що обсяг, який вони запропонували повністю покривається розрахованим значенням x_quantityLimit
Організатор має можливість:
- Завантажити і замінити awards.document: documentType: auctionProtocol (обов'язкова дія для подальшої зміни статуса Аварда на protocol_signed)
- Змінити Awards.status: pending → protocol_signed
- Змінити Awards.status: pending → unsuccessful
Учасник має можливість завантажити та замінити протокол awards.document: documentType: auctionProtocol
Перехід із pending_waiting:
Лише у випадку, якщо Організатор дискваліфікував одного чи більше Переможців, Аварди, що перебувають у статусі pending_waiting автоматино можуть змінити свій статус на pending за умови, що обсяг, який вони запропонували повністю покривається залишком від обсягу, що залишився і не настала дата qualificationPeriod.endDate. Якщо завершився qualificationPeriod і після 29 р.д. Організатор дискваліфіковує переможця, наступний у черзі, який очікує вже НЕ отримує статус pending (на 30-й день вже не має бути Авардів у статусі pending_waiting, бо визначено одного, хто змінив свій статус на pending_admission, а всі інші змінили свій статус на cancelled)
Приклад1:
Організатор вказав procedure.items.quantity == 10 000
Учасник_1 запропонував awards.items.quantit == 3 000 по найменшій ціні 10
Учасник_2 запропонував awards.items.quantit == 1 000 по ціні 11
Учасник_3 запропонував awards.items.quantit == 2 000 по ціні 12
Всі три учасники успішно пройшли перевірку документів (awards.status == waiting)
ЦБД розраховує x_quantityLimit == (3000 + 1 000 + 2 000) * 0.8 == 4 800
Обсяг 4 800 повністю покриває тільки запропоновані обсяги Учасника_1 і Учасника_2. Запропонований Учасником_3 обсяг повнітю не реалізується (він запропонував 2 000, а після розподілення між першим і другим учасниками, залишилось не розподілено тільки (4 800 - 3 000 - 1 000) == 800 )
В даному прикладі тільки третій учасник отримує статус pending_waiting
Після цього Організатор дискваліфіковує Учасника_1 з його пропозицією 3 000.
Учасник_3 автоматично отримує статус pending з своєю пропозицією 2 000, бо 2 000 повністю покривається обсягом 4 800 (першого дискваліфікували, другий 1 000, третій 2 000, 1000+2000 = 3000, що менше, ніж 4800)
Приклад2:
Організатор вказав procedure.items.quantity == 10 000
Учасник_1 запропонував awards.items.quantit == 1 000 по найменшій ціні 10
Учасник_2 запропонував awards.items.quantit == 1 000 по ціні 11
Учасник_3 запропонував awards.items.quantit == 8 000 по ціні 12
Всі три учасники успішно пройшли перевірку документів (awards.status == waiting)
ЦБД розраховує x_quantityLimit == (1 000 + 1 000 + 8 000) * 0.8 == 8 000
Обсяг 8000 повністю покриває тільки запропоновані обсяги Учасника_1 і Учасника_2. Запропонований Учасником_3 обсяг повнітю не реалізується (він запропонував 8 000, а після розподілення між першим і другим учасниками, залишилось не розподілено тільки (8 000 - 1 000 - 1 000) == 6 000 )
В даному прикладі тільки третій учасник отримує статус pending_waiting
Після цього Організатор дискваліфіковує Учасника_1 з його пропозицією 1 000.
Учасник_3 НЕ отримує статус pending з своєю пропозицією 8000, бо 8000 повністю не покривається залишком обсягу (8000 - 1000 = 7000 - залишок обсягу, а Учасник_3 пропонує 8000, що більше, ніж 7000)
Його статус залишається pending_waiting.
P.S.: в майбутньому він отримає статус "Умовний переможець" (pending_admission) і зможе погодитись реалізувати залишок, який складає 7000 із його запропонованих 8000.
Перехід із pending_admission:
Учасник в статусі pending_admission має можливість вказати обсяг, який він готовий закрити і змінити статус на pending. Далі відбувається його кваліфікація за логікою кваліфікації інших переможців.
Автоматично.
Завершився verificationPeriod.endDate
Статус pending_waiting отримують Аварди, які перебувають у списку результатів Модуля Аукціону і які успішно пройшли етап перевірки документів (award.status <> unsuccessful) за умови, що обсяг, який вони запропонували повністю НЕ покривається розрахованим значенням x_quantityLimit, з причини, що обсяг вже закритий іншими пропозиціями учасників, що запропонували меншу ціну.
Приклад 1:
Організатор вказав квоту procedure.items.quantity == 10 000
Учасник_1 запропонував awards.items.quantit == 3 000 по найменшій ціні 10
Учасник_2 запропонував awards.items.quantit == 1 000 по ціні 11
Учасник_3 запропонував awards.items.quantit == 2 000 по ціні 12
Всі три учасники успішно пройшли перевірку документів (awards.status == waiting)
ЦБД розраховує x_quantityLimit == (3000 + 1 000 + 2 000) * 0.8 == 4 800
Обсяг 4 800 повністю покриває тільки запропоновані обсяги Учасника_1 і Учасника_2. Запропонований Учасником_3 обсяг повнітю не реалізується (він запропонував 2 000, а після розподілення між першим і другим учасниками, залишилось не розподілено тільки (4 800 - 3 000 - 1 000) == 800 )
В даному прикладі тільки третій учасник отримує статус pending_waiting
Приклад 2:
Організатор вказав квоту procedure.items.quantity == 10 000
Учасник_1 запропонував awards.items.quantit 3 000 по найменшій ціні 10
Учасник_2 запропонував 2 000 по ціні 11
Учасник_3 запропонував 1 000 по ціні 12
Всі три учасники успішно пройшли перевірку документів (awards.status == waiting)
ЦБД розраховує x_quantityLimit == (3000 + 1 000 + 2 000) * 0.8 == 4 800
Обсяг 4 800 повністю покриває тільки запропонований обсяг Учасника_1. Запропонований Учасником_2 обсяг повністю не реалізується (він запропонував 2 000, а після Учасника_1 , залишилось не розподілено тільки (4 800 - 3 000) == 1800 )
В даному прикладі другий і третій учасники отримують статус pending_waiting
Організатор не може дискваліфікувати Учасника, що очікує рішення
Учасник не має можливості відмовитись від очікування.
Автоматично.
Якщо повʼязаний contracts набув статуса active
Термінальний статус.
Якщо змінився contracts.status: pending → active, це означає, що
завантажено Підписаний договір (contracts.documents.documentType: contractSigned)
Це потрібно для того, щоб за умови дискваліфікації Переможця на етапі підписання Договору, ЦБД зробила перевірку "qualificationPeriod.endDate вже пройшов?":
- якщо НІ, то відпрацьовує логіка визначення переходу наступного Аварда із pending_waiting → pending і підписання протоколу і договору з наступним учасником.
- якщо ТАК, то наступних у черзі Авардів не кваліфікуємо
pending_admission
АБО
pending_waiting
із pending_admission:
Ручна дія.
Учасник ("Умовний переможець") відмовляється "закрити" нерозподілений залишок і надсилає запит на зміну статуса
АБО
Автоматично.
Якщо протягом awards.admissionPeriod учасник ("Умовний переможець") не надав відповіді
із pending_waiting:
Автоматично.
В момент, коли будь-який Авард набуває статусу pending_admission, всі інші Аварди, які знаходяться у статусі pending_waiting автоматично набувають статус cancelled
Термінальний статус.
Після набуття статусу pending_admission "Умовний переможець" має можливість відмовитись від запропонованого обсягу і скасувати свою заявку (змінити статус Аварда з pending_admission на cancelled).
Якщо протягом awards.admissionPeriod учасник ("Умовний переможець") не надав відповіді, то ЦБД автоматично змінює статус його Аварда.
Після набуття статусу pending_admission "Умовний переможець" всі Аварди, які на цей момент заходились у статусі pending_waiting набувають статус cancelled
verification
АБО
pending
АБО
protocol_signedРучна дія. Організатор надсилає запит на зміну award.status: |
pending |
Ручна дія.
Організатор надсилає запит на зміну статуса Аварда protocol_signed→ unsuccessful | Термінальний статус. |
verification → unsuccessful:
завантажується документ rejectionProtocol для кожного Аварда, який не пройшов перевірку документів протягом verificationPeriodПоле terminationReason в даному випадку заповнювати не обовʼязково
pending → unsuccessful: ЦБД має валідувати, що в Авард завантажено документ з documentType: act При зміні статуса з pending → unsuccessful ЦБД має валідувати, що заповнено awards.terminationReason значенням зі словника |
При зміні статуса з protocol_signed → unsuccessful Організатору необхідно заповнити поле terminationReason значенням зі словника
Обовʼязково завантажити документ act "про відмову" в Авард. |
Логіка проведення кваліфікації+Приклади
...