...
Посилання на конфігураційний файл з періодами та статусами
Перелік схем:
- Timeline процедури
- Схема "Загальний процес аукціонів"
- Схема "Публікація оголошення та прийняття заяви про участь"
- Схема "Аукціон"
- Схема "Кваліфікація (робота з договором та протоколом)"
Інформація про процедуру
Загальна схема процедури
...
Повний перелік полів в Swagger
Організатор аукціону, під час публікації оголошення, вказує необхідні поля процедури. Вони вказані в ТЗ з вимогами до майданчиків.
Документи процедури
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 | Цифровий підпис | Ні | Набуває значення документу з яким позв'язаний |
Повідомлення при публікації оголошення
Публікація процедури (Редагування оголошення)
...
documentType | Назва Укр | Назва Анг | Опис | Обовʼязковіть для публікації процедури | Публічність |
|---|---|---|---|---|---|
| clarifications | Погодження змін до опису лоту. Опис причин редагування. | Clarifications | Документ не потрібно вносити до списку документів при створенні аукціону. Має бути доступний для завантаження в rectificationPeriod | Ні (обов'язковий лише для внесення змін в поля лоту) | Так |
Публікація заяви на участь
Повідомлення при редагуванні оголошення (загальні)
Обговорення аукціону (запитання-відповідь)
Посилання на схему «Обговорення електронних аукціонів (запитання-відповідь)»
Повідомлення при обговоренні аукціону (запитання-відповідь)
Публікація заяви на участь
Періоди у заяви на участь відсутні.
...
У разі коли в момент закінчення кінцевого строку подання заяв про участь в аукціоні подано менше зазначеної організатором мінімальної кількості заяв, ЦБД автоматично присвоює аукціону статус “аукціон не відбувся” (unsuccessful)
...
Робота із заявою на участь
...
...
Публікація оголошення та прийняття заяви про участь"
...
Робота із заявою на участь
Учасник, що подав пропозицію в період дії статусу процедури active_tendering, має можливість вносити зміни в поля заяви на участь, анулювати заяву та завантажувати, замінювати документи в рамках статусу процедури active_tendering.
У випадку переходу аукціону у статус Аукціон не відбувся (unsuccessful) або Аукціон відмінено (cancelled), до завершення періоду аукціону (auctionPeriod), ставки учасників залишаються закритими для всіх, включаючи Організатора аукціону і доступні виключно для майданчика, який розмістив ставку у ЦБД.
Статуси заяви на участь (біда)
Схема "Статуси bid"
| draw.io Diagram | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Технічна назва | Бізнесова назва | Перехід з | За умови | Коментар | ||||
|---|---|---|---|---|---|---|---|---|
| draft | Чернетка заяви | момент публікації заявки в ЦБД | ||||||
Технічна назва | Бізнесова назва | Перехід з | За умови | Коментар | ||||
| draft | Чернетка заяви | момент публікації заявки в ЦБД | Ручна дія. Учасник надсилає запит на публікацію Bid-а | active | Підтверджена заява | draft | Ручна дія. Учасник надсилає запит на зміну статуса публікацію Bid-а | Публікація заяви на участь доступна тільки протягом tenderPeriod-а процедури. Мають бути заповненіМають бути заповнені обовʼязкові поля:
та обовʼязкові документиОпублікувати бід можна без документів, але без обовʼязкових документів не буде можливості активувати Біда. Майданчик Учасника надсилає запит на активацію робить запит до ЦБД та передає об'єкт заяви на участь. У разі правильно сформованого об'єкта заяви на участь в ЦБД, ЦБД повертає майданчику token для активації заяви на участь, заява на участь змінює статус на “Підтверджена заява” (active) та вважається опублікованою.набуває статус “Чернетка заяви” (draft). |
| active | Підтверджена | inactive | Деактивована заява | draft | Ручна дія. Учасник має можливість:надсилає запит на зміну статуса Bid-а | Мають бути заповнені обовʼязкові поля:
та обовʼязкові документи Майданчик Учасника надсилає запит на активацію заяви на участь в ЦБД, заява на участь змінює статус на “Підтверджена заява” (active) та вважається опублікованою. | ||
| inactive | Деактивована заява | draft | Ручна дія. Учасник має можливість:
| У разі редагування оголошення (поля + документи) Організатором, заяви на участь (у статусах draft та/або active) учасників автоматично переходять у статус inactive. Таку заяву на участь можна повторно перевести у статус active. Або анулювати за бажанням учасника. | ||||
| deleted | Видалена заява | active | Ручна дія. Учасник надсилає запит на зміну статуса Bid-а | У разі анулювання заяви на участь учасником вона набуває статус “Видалена заява” (deleted). Скасувати свою заявку на участь є можливість тільки протягом tenderPeriod |
...
documentType | Назва Українською | Назва Англійською | Опис | Обовʼязковіть для активації bid-а | Публічність |
|---|---|---|---|---|---|
| commercialProposal | Заява на участь | bid | Заява на участь | Ні | Так |
| x_passport | Копія паспорта або документу, що посвідчує особу | Passport or identity document | Паспорт або інший документ що посвідчує особу (для фізичної особи нерезидента) | Ні | Ні |
| x_IPN | Копія РНОКПП | RNTRC | Копія ІПН | Ні | Ні |
| x_tenderersRegisterExtract | Витяг ЄДРПОУ | Register extract | Копія витягу з ЄДРПОУ або копыю документа про реэстрацію у державі її місцезнаходження (витяг із торговельного, банківського або єдиного реєстру, тощо) | Ні | Так |
| x_nonResidentRegistrations | Документ про реєстрацію у державі її місцезнаходження (для юридичних осіб - нерезидентів) | Non Resident Registrations | Копія документа про реєстрацію у державі її місцезнаходження (для юридичної особи-нерезидента) | Ні | Так |
| x_registrationFeeApproval | Документ, що підтвкрджує сплату реєстраційного внеску | Registration fee approval | Документ, що підтвкрджує сплату реєстраційного внеску | Ні | Так |
| x_guaranteeApproval | Документ, що підтверджує сплату гарантійного внеску | Guarantee approval | Документ, що підтверджує сплату гарантійного внеску | Ні | Так |
| qualificationDocuments | Документи, що підтверджують відповідність вимогам | Qualification document | Документи, що підтверджують відповідність вимогам | Ні | Так |
...
Повідомлення при розміщення заяви на участь
- lotId
- title
- description
- previousAuctionId
- tenderAttempts
- sellingEntity
- bankAccounts
- x_documentRequirements
- x_additionalInformation
- discount
- accessDetails
- value
- valueAddedTaxCharged
- minimalStep
- minNumberOfQualifiedBids
- items
- guarantee
- registrationFee
- documents
- schedule
- valuePeriod
- leaseDuration
Аукціон
Після переходу за посиланням, учасник потрапляє на сторінку проведення аукціону (модуль аукціону).
Схема "Аукціон"
...
Деактивація заяви на участь
У разі редагування оголошення (поля + документи) Організатором, заяви на участь (у статусах draft та/або active) учасників автоматично переходять у статус inactive. Таку заяву на участь можна повторно перевести у статус active. В учасника має бути можливість анулювати свою заяву на участь після деактивації (перевести bid в статус deleted). Необхідно виводити інформацію про факт редагування та історичні дані на Майданчику.
Поля, в які можна вносити зміни в період редагування (rectificationPeriod) і після зміни яких деактивуються заяви на участь
- lotId
- title
- description
- previousAuctionId
- tenderAttempts
- sellingEntity
- bankAccounts
- x_documentRequirements
- x_additionalInformation
- discount
- accessDetails
- value
- valueAddedTaxCharged
- minimalStep
- minNumberOfQualifiedBids
- items
- guarantee
- registrationFee
- documents
- schedule
- valuePeriod
- leaseDuration
Аукціон
Після переходу за посиланням, учасник потрапляє на сторінку проведення аукціону (модуль аукціону).
Інформація про отримання посилання на аукціон
ТЗ з модулю аукціону
...
Особливості роботи в ЦБД та вимоги до майданчиків
Для визначення чинного орендаря в системі, Організатор повинен зазначити дані чинного орендаря у тому числі його ЄДРПОУ/ІНН/ID. Під час реєстрації чинного орендаря, як учасника, на майданчику (обов'язково повинен зазначити ЄДРПОУ/ІНН/ID) та активації заяви на участь, система за ЄДРПОУ/ІНН/ID ідентифікує заяву на участь (тільки у статусі active) такого учасника та надає майданчику підтвердження, що такий учасник є чинним орендарем. За наявності такого підтвердження:
- Майданчик інформує учасника, що його закрита цінова пропозиція прийнята та отримала відповідну ознаку;
- Учасник в особистому кабінеті отримує ознаку "Учасник з переважним правом".
...
Формування протоколу
...
За результатами періоду аукціону (auctionPeriod), за умови наявності 2-х та більше заяв в рамках періоду подання пропозицій, основні умови відбору переможців Організатором аукціону - найвища валідна ставка та відповідність учасника кваліфікаційним вимогам.
Пропозиції сортуються від більшої ціни до меншої, а, у випадку співпадіння ціни, вище відображається пропозиція розміщена раніше. Часом розміщення пропозиції вважається час першого розміщення заяви у ЦБД, а, у випадку редагування пропозиції під час періоду подання пропозицій (tenderPeriod), час фіксації змін у заяві у ЦБД.
ЦБД формує award'и тільки для двох учасників з найвищими валідними ставками (другий award за наявності такого учасника). Авард учасника з найвищою валідною ставкою отримує статус pending, а авард учасника з другою найвищою ставкою (за наявності) отримує статус pending_waiting.
Перевірка документів учасників та підписання протоколу
За умови успішного проведення аукціону, процедура переходить у період кваліфікації та розпочинається період підписання протоколу, статус процедури змінюється на active_qualification, починається робота із протоколом.
Якщо усіх учасників, що пройшли до кваліфікації, дискваліфіковано, ЦБД автоматично змінює статус процедури на unsuccessful.
Після періоду аукціону (auctionPeriod) Організатор здійснює перевірку документів (поза системою) всіх учасників аукціону та приймає рішення щодо кваліфікації учасників.
- Протокол аукціону (documentType:auctionProtocol) підписується переможцем аукціону та оператором електронного майданчика, з якого переможець подав цінову пропозицію, за допомогою кваліфікованого електронного підпису уповноваженої особи.
- Організатор опубліковує підписаний протокол аукціону в ЕТС протягом 10-ти робочих днів після дня його завершення.
- В Організатора є можливість підтвердити протокол і після завершення періоду підписання протоколу (verificationPeriod), обмеження на майданчику не мають встановлюватись.
- Після завантаження протоколу організатор натискає кнопку "Протокол затверджено", після чого майданчик передає award’у такого учасника статус active (“Переможець. Очікується договір”).
- В результаті чого для цього award’у створюється contract в статусі pending у масиві contracts.
- У учасника, який кваліфікується є можливість завантаження та заміни Протоколу до bid`a (не обов’язкова дія), але завантаження цього документу учасником не призводить до зміни статусів в системі.
- Для учасника з другою за розміром ціновою пропозицією (за наявності такого), одразу після аукціону, формуються award, що отримує статус pending_waiting, якщо його ставка була валідною.
- У випадку, якщо ставка цього учасника не є валідною, формування award'у для такого учасника не здійснюється.
- Єдина дія, яка може бути виконана в цей момент - це ручне скасування очікування - учасник може забрати свій гарантійний внесок, втрачаючи шанс стати переможцем аукціону. У разі відмови від очікування майданчик передає такому award'y статус cancelled.
- Якщо перший award дискваліфіковують, а другий не самодискваліфікувався, після набуття статусу 2-го award'у pending, 2-й учасник проходить процедуру кваліфікації по такому самому принципу як 1-й переможець (процедура знову набуває статус "Очікується опублікування протоколу" (active_qualification)).
- Якщо ж кваліфікація 1-го award'у пройшла успішно, та Організатор аукціону підтвердив виконання умов договору для 1-го award'у, у такому випадку ЦБД, під час зміни статусу процедури на complete, автоматично змінює статус 2-го award'у на cancelled.
- У разі невідповідності переможця аукціону вимогам, Організатор аукціону повинен дискваліфікувати учасника, після чого майданчик передає статус “unsuccessful” award`у такого учасника до ЦБД.
- Завершення періоду підписання протоколу (verificationPeriod) - період триває доти, доки Організатор не підтвердить протокол.
Періоди Awards
...
Технічна назва
...
Бізнесова назва
...
Дата початку
...
Дата завершення
...
Результат завершення
...
Коментар
...
В момент набуття Авардом статуса pending
...
Період формується в Аварді з моменту набуття Авардом статусу pending
Якщо Авард був у статусі pending і отримав signingPeriod, то після зміни статуса на інший (protocol_signed, active OR unsuccessful) період залишається незмінним.
Аварди в інших статусах цей період не отримують.
...
Статуси Awards
Схема "Статуси awards"
...
Технічна назва
...
Бізнесова назва
...
Перехід з
...
За умови
...
Коментар
...
Автоматично.
Присвоюється переможцю під час генерації авардів
...
- Завантаження протоколу (обв'язкова дія - з можливістю замінити протокол)
- Переведення статусу учасника до наступного статусу "Переможжець. Очікується договір"
- Дискваліфікація учасника
Учасник має можливість:
- Завантажити та замінити протокол (не обов'язкова дія - з можливістю замінити протокол)
...
Автоматично.
Присвоюється 2-му (після переможця) учаснику під час генерації авардів
...
Статус pending_waiting автоматично присвоюється 2-му (після переможця) учаснику під час генерації авардів
2й учасник має можливість відмовитися від очікування (до моменту дискваліфікації 1-го учасника та за умови, що процедура у не термінальному статусі)
...
Організатор підтверджує підписання протоколу і award змінює свій статус з pending на active.
Термінальний статус.
Організатор має можливість:
- Завантаження договору (з можливістю замінити);
- Дискваліфікація учасника (до завершення аукціону);
- Підтвердження оплати;
- Завершення аукціону.
2й Учасник має можливість:
- відмовитися від очікування до моменту дискваліфікації 1-го переможця.
...
pending_waiting
...
- 2-й учасник відмовився від очікування
- Статус змінюється лише після завершення аукціону
- Аукціон перейшов в термінальний статус (complete), у зв’язку з чим 2-й учасник не набув статусу переможця (за умови, що 2-й учасник відмовився від очікування).
Термінальний статус.
...
pending
...
Ручна дія.
Організатор надсилає запит на зміну award.status: pending → unsuccessful
...
Термінальний статус.
`1. pending → unsuccessful:
ЦБД має валідувати, що в Авард завантажено документ з documentType: rejectionProtocol/act
При зміні статуса з pending → unsuccessful ЦБД має валідувати, що заповнено awards.terminationReason значенням зі словника
Обовʼязково завантажити документ act "про відмову" в Авард.
2. active → unsuccessful:
ЦБД має валідувати, що в Авард завантажено документ з documentType: rejectionProtocol/act
При зміні статуса з active → unsuccessful ЦБД має валідувати, що заповнено awards.terminationReason значенням зі словника
При цьому contracts автоматично змінить свій статус на cancelled
Обовʼязково завантажити документ rejectionProtocol/act "про відмову" в Авард.
Аукціону
Протокол про результати аукціону формується автоматично у вигляді структурованого машиночитаємого файлу (JSON або YAML) та оприлюднюється в формі електронного документу електронною торговою системою в день завершення аукціону (одразу по завершенню періоду аукціону).
Майданчик має відображати посилання для завантаження (друкування) протоколу у PDF та HTML форматах
Шаблони електронного протоколу аукціону:
Повідомлення щодо аукціону
Кваліфікація (Підписання протоколу)
Схема Схема "Кваліфікація (робота з договором та протоколом)"
За результатами періоду аукціону (auctionPeriod), за умови наявності 2-х та більше заяв в рамках періоду подання пропозицій, основні умови відбору переможців Організатором аукціону - найвища валідна ставка та відповідність учасника кваліфікаційним вимогам.
Пропозиції сортуються від більшої ціни до меншої, а, у випадку співпадіння ціни, вище відображається пропозиція розміщена раніше. Часом розміщення пропозиції вважається час першого розміщення заяви у ЦБД, а, у випадку редагування пропозиції під час періоду подання пропозицій (tenderPeriod), час фіксації змін у заяві у ЦБД.
ЦБД формує award'и тільки для двох учасників з найвищими валідними ставками (другий award за наявності такого учасника). Авард учасника з найвищою валідною ставкою отримує статус pending, а авард учасника з другою найвищою ставкою (за наявності) отримує статус pending_waiting.
Перевірка документів учасників та підписання протоколу
За умови успішного проведення аукціону, процедура переходить у період кваліфікації та розпочинається період підписання протоколу, статус процедури змінюється на active_qualification, починається робота із протоколом.
Якщо усіх учасників, що пройшли до кваліфікації, дискваліфіковано, ЦБД автоматично змінює статус процедури на unsuccessful.
Після періоду аукціону (auctionPeriod) Організатор здійснює перевірку документів (поза системою) всіх учасників аукціону та приймає рішення щодо кваліфікації учасників.
- Протокол аукціону (documentType:auctionProtocol) підписується переможцем аукціону та оператором електронного майданчика, з якого переможець подав цінову пропозицію, за допомогою кваліфікованого електронного підпису уповноваженої особи.
- Організатор опубліковує підписаний протокол аукціону в ЕТС протягом 10-ти робочих днів після дня його завершення.
- В Організатора є можливість підтвердити протокол і після завершення періоду підписання протоколу (verificationPeriod), обмеження на майданчику не мають встановлюватись.
- Після завантаження протоколу організатор натискає кнопку "Протокол затверджено", після чого майданчик передає award’у такого учасника статус active (“Переможець. Очікується договір”).
- В результаті чого для цього award’у створюється contract в статусі pending у масиві contracts.
- У учасника, який кваліфікується є можливість завантаження та заміни Протоколу до bid`a (не обов’язкова дія), але завантаження цього документу учасником не призводить до зміни статусів в системі.
- Для учасника з другою за розміром ціновою пропозицією (за наявності такого), одразу після аукціону, формуються award, що отримує статус pending_waiting, якщо його ставка була валідною.
- У випадку, якщо ставка цього учасника не є валідною, формування award'у для такого учасника не здійснюється.
- Єдина дія, яка може бути виконана в цей момент - це ручне скасування очікування - учасник може забрати свій гарантійний внесок, втрачаючи шанс стати переможцем аукціону. У разі відмови від очікування майданчик передає такому award'y статус cancelled.
- Якщо перший award дискваліфіковують, а другий не самодискваліфікувався, після набуття статусу 2-го award'у pending, 2-й учасник проходить процедуру кваліфікації по такому самому принципу як 1-й переможець (процедура знову набуває статус "Очікується опублікування протоколу" (active_qualification)).
- Якщо ж кваліфікація 1-го award'у пройшла успішно, та Організатор аукціону підтвердив виконання умов договору для 1-го award'у, у такому випадку ЦБД, під час зміни статусу процедури на complete, автоматично змінює статус 2-го award'у на cancelled.
- У разі невідповідності переможця аукціону вимогам, Організатор аукціону повинен дискваліфікувати учасника, після чого майданчик передає статус “unsuccessful” award`у такого учасника до ЦБД.
- Завершення періоду підписання протоколу (verificationPeriod) - період триває доти, доки Організатор не підтвердить протокол.
Періоди Awards
Технічна назва | Бізнесова назва | Дата початку | Дата завершення | Результат завершення | Коментар |
|---|---|---|---|---|---|
| awards.signingPeriod | Період підписання протоколу та договору | В момент набуття Авардом статуса pending | signingPeriod.endDate == signingPeriod.startDate + 15 р.д. | На рівні ЦБД: відсутній | Період формується в Аварді з моменту набуття Авардом статусу pending Якщо Авард був у статусі pending і отримав signingPeriod, то після зміни статуса на інший (active OR unsuccessful) період залишається незмінним. Аварди в інших статусах цей період не отримують. |
Статуси Awards
Схема "Статуси awards"
| draw.io Diagram | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Технічна назва | Бізнесова назва | Перехід з | За умови | Коментар |
|---|---|---|---|---|
| pending | Очікується протокол | Автоматично. Присвоюється переможцю під час генерації авардів | Організатор має можливість:
Учасник має можливість:
| |
| pending_waiting | Очікується рішення | Автоматично. Присвоюється 2-му (після переможця) учаснику під час генерації авардів | Статус pending_waiting автоматично присвоюється 2-му (після переможця) учаснику під час генерації авардів 2й учасник має можливість відмовитися від очікування (до моменту дискваліфікації 1-го учасника та за умови, що процедура у не термінальному статусі) | |
| active | Переможець. Очікується договір | pending | Організатор підтверджує підписання протоколу і award змінює свій статус з pending на active. | Термінальний статус. Організатор має можливість:
2й Учасник має можливість:
|
| cancelled | Учасник не став переможцем | pending_waiting |
| Термінальний статус. |
| unsuccessful | Дискваліфіковано | pending | Ручна дія. Організатор надсилає запит на зміну award.status: pending → unsuccessful | Термінальний статус. `1. pending → unsuccessful: ЦБД має валідувати, що в Авард завантажено документ з documentType: rejectionProtocol/act При зміні статуса з pending → unsuccessful ЦБД має валідувати, що заповнено awards.terminationReason значенням зі словника Обовʼязково завантажити документ act "про відмову" в Авард. 2. active → unsuccessful: ЦБД має валідувати, що в Авард завантажено документ з documentType: rejectionProtocol/act При зміні статуса з active → unsuccessful ЦБД має валідувати, що заповнено awards.terminationReason значенням зі словника При цьому contracts автоматично змінить свій статус на cancelled Обовʼязково завантажити документ rejectionProtocol/act "про відмову" в Авард. |
Документи обʼєкта кваліфікації (awards.documents)
documentType | Назва Українською | Назва Англійською | Опис | Обовʼязковіть | Публічність |
|---|---|---|---|---|---|
| rejectionProtocol | Документ, що підтверджує дискваліфікацію | Rejection protocol | Завантажується у разі дискваліфікації учасника (окремо зазначається причина), за умови прийняття рішення Організатором; | Так Для зміни awards.status: pending → unsuccessful | Так |
| auctionProtocol | Протокол аукціону | Auction protocol | Протокол підписується і завантажується для кожного учасника окремо | Так Для зміни awards.status: pending → active | Так |
| act | Документ, що підтверджує відмову | Refusal act | Завантажується у разі відмови Переможцем підписувати протокол або договір. Документ має бути можливість завантажити у Організатора та у Переможця. Для того, щоб Організатор дискваліфікував учасника, Авард якого перебуває у статусі pending або protocol_signed, має бути завантажено хоча б один документ з documentType: act Поле terminationReason має бути обов'язково заповнено для зміни awards.status: pending → unsuccessful | Так Для зміни awards.status: pending → unsuccessful | Так |
Повідомлення щодо кваліфікації (загальні)
Кваліфікація (Підписання контракту з переможцем (contracts))
Після підписання договору Організатор має завантажити договір (documentType:contractSigned), заповнити обов'язкові поля договору (крім обов'язкових при створенні, для активації необхідно заповнити поля dateSigned, title, contractNumber, description, contractTotalValue) та підтвердити договір. Після цього майданчик переводить contract в статус active.
В Організатора аукціону є можливість підтвердити договір (documentType:contractSigned) і після завершення періоду підписання договору (signingPeriod), обмеження на майданчику не мають встановлюватись.
До переведення договору в статус active, Організатор повинен мати можливість виправити поля договору та вкладені файли.
Завершення аукціону (переведення у статус complete)
Після підтвердження договору, Організатор аукціону завершує аукціон. Після чого процедура змінює статус на complete.
Схема Схема "Кваліфікація (робота з договором та протоколом)"
Статуси Contracts
Схема "Статуси Contracts"
| draw.io Diagram | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Технічна назва | Бізнесова назва | Перехід з | За умови | Коментар |
|---|---|---|---|---|
| pending | Очікується договір | Момент створення Awards[] у статусі active | Автоматично. Якщо будь-який Авард набуває статусу active, то ЦБД автоматично створює повʼязаний contracts у статусі pending. | Організатор має можливість:
contracts створюються не після того, як Award набув статусу active |
| active | Договір підтверджено | pending | Ручна дія. Організатор завантажує документ contracts[x].documents.documentType: contractSigned і після цього надсилає запит на зміну contracts.status: pending → active | Повʼязаний Авард має бути у статусі active. З технічної сторони, договір вважається підписаним і закритим, коли Організатор змінює contracts.status: pending → active. Якщо змінився contracts.status: pending → active, це означає, що завантажено Підписаний договір (contracts.documents.documentType: contractSigned) |
| cancelled | Договір скасовано | pending | Автоматична. За умови дискваліфікації Аварда із active → unsuccessful | Для того, щоб дискваліфікувати Учасника з причини того, що НЕ підписано договір або неотримано оплату, організатору необхідно надіслати запит на зміну статуса Аварда active → unsuccessful |
Документи контракту (contracts.documents)
documentType | Назва Українською | Назва Англійською | Опис | Обовʼязковіть | Публічність |
|---|---|---|---|---|---|
| contractSigned | Підписаний договір | Signed contract | Підписаний договір | Так | Так |
| contractAnnexe | Додатки до договору | Contract annexe | Додатки до договору | Ні | Так |
| contractNotice | Повідомлення про договір | Contract notice | Офіційне повідомлення, що містить деталі договору | Ні | Так |
| paymentInformation | Інформація про розрахунки | Payment Information | Відомості про розрахунки переможцем аукціону | Ні | Так |
| transferAct | Акт приймання - передачі | Transfer act | Акт приймання - передачі | Ні | Так |
Умови дискваліфікації
Дискваліфікація Організатором
У разі дискваліфікації переможця на етапі роботи із договором (signingPeriod), Організатор аукціону складає та оприлюднює в електронній торговій системі протокол відхилення (documentType:rejectionProtocol) або/та акт про відмову (documentType:act) та натискає на кнопку “Дискваліфікувати” і вказує одну причину з переліку причин (причина записуються в поле terminationReason аварду):
Після чого майданчик передає статус unsuccessful award`у учасника, внаслідок чого ЦБД автоматично переводить договір у статус cancelled. Вказана причина, а також статус учасника, повинні відображатися на майданчику.
- Перелік причин дискваліфікації:
- Відмова або непідписання протоколу
- Відмова або непідписання договору
- Відсутні обов’язкові документи
- Невнесення передоплати або оплати за договором
- Участь в аукціоні з більше, ніж 1 майданчика
До переведення статусу award`у учасника в unsuccessful, Організатор повинен мати можливість змінити причину дисквалифікації та завантажити або замінити документ/ти.
Повідомлення щодо кваліфікації (загальні)
Скасування аукціону
Рішення Організатора про відміну аукціону повинне бути викладене у формі розпорядчого акта (рішення, наказу, розпорядження, протоколу тощо)
Скасувати процедуру є можливість у статусах, окрім термінальних
У разі відміни аукціону ЦБД автоматично присвоює аукціону статус “Аукціон відмінено”.
Деталі описано тут
Документи скасування процедури (cancellations.documents)
documentType | Назва Укр | Назва Анг | Опис | Обовʼязковіть для скасування процедури | Публічність |
|---|---|---|---|---|---|
| cancellationDetails | Причини скасування | Cancellation details | Інформація щодо причин скасування аукціону | Так | Так |
| digitalSignature | Цифровий підпис | Digital signature | Цифровий підпис | Ні | Набуває значення документу з яким позв'язаний |
Повідомлення при скасування аукціону
Загальні документи по розробці
Особливості роботи із сутностями та документами
Особливості роботи із цифровим підписом
Цифровий підпис (ЕЦП/КЕП) накладається поза ЦБД. Завантажується в ЦБД окремим файлом (тільки підпис або підписаний файл) digitalSignature, в якому присутнє поле relatedDocument, де додається посилання на оригінальний документ (id документу), вже завантажений до DocumentService.
relatedDocument - ідентифікатор, що відображається тільки в документі digitalSignature та використовується для відображення зв'язку між цифровим підписом та документом сутності процедури.
За бажанням Організатору або учасника на всіх етапах процедури, де йде робота із документами сутностей (завантаження, оновлення документу) є можливість, до будь-якого документу, застосувати цифровий підпис, або за умови обов'язковості у разі, якщо це вимагають нормативні документи, такі особливості вказуються в ТЗ кожної окремої процедури.
Цифровий підпис документу необов'язковий, обов'язковість вказується в ТЗ процедури, за умови відповідних вимог в нормативних документах.
Технічні особливості роботи із цифрового підпису
ПЗ за рахунок якого створюється цифровий підпис - за бажанням майданчика, централізоване рішення поки не пропонуємо, заплановано у беклог, проте строки поки невідомі.
Обмежень щодо розширення файлу на стороні ЦБД відсутні
Вимоги до майданчиків
Можливі 2 варіанти реалізації цифрового підпису:
- Окремо документ цифрового підпису та назву/посилання на оригінальний документ
- Поряд з оригінальним документом виводити пов'язані файли цифрового підпису
...
documentType
...
Назва Українською
...
Назва Англійською
...
Опис
...
Обовʼязковіть
...
Публічність
...
Завантажується у разі дискваліфікації учасника (окремо зазначається причина), за умови прийняття рішення Організатором;
...
Так
Для зміни awards.status: pending → unsuccessful
...
Протокол підписується і завантажується для кожного учасника окремо
...
Так
Для зміни awards.status: pending → active
...
Завантажується у разі відмови Переможцем підписувати протокол або договір.
Документ має бути можливість завантажити у Організатора та у Переможця.
Для того, щоб Організатор дискваліфікував учасника, Авард якого перебуває у статусі pending або protocol_signed, має бути завантажено хоча б один документ з documentType: act
В поле terminationReason аварду записується причина із довідника
Поле terminationReason має бути обов'язково заповнено для зміни awards.status: pending → unsuccessful
...
Так
Для зміни awards.status: pending → unsuccessful
...
Повідомлення щодо кваліфікації (загальні)
Кваліфікація (Підписання контракту з переможцем (contracts))
Після підписання договору Організатор має завантажити договір (documentType:contractSigned), заповнити обов'язкові поля договору (крім обов'язкових при створенні, для активації необхідно заповнити поля dateSigned, title, contractNumber, description, contractTotalValue) та підтвердити договір. Після цього майданчик переводить contract в статус active.
В Організатора аукціону є можливість підтвердити договір (documentType:contractSigned) і після завершення періоду підписання договору (signingPeriod), обмеження на майданчику не мають встановлюватись.
До переведення договору в статус active, Організатор повинен мати можливість виправити поля договору та вкладені файли.
Завершення аукціону (переведення у статус complete)
Після підтвердження договору, Організатор аукціону завершує аукціон. Після чого процедура змінює статус на complete.
Схема Схема "Кваліфікація (робота з договором та протоколом)"
Статуси Contracts
Схема "Статуси Contracts"
...
Технічна назва
...
Бізнесова назва
...
Перехід з
...
За умови
...
Коментар
...
Автоматично.
Якщо будь-який Авард набуває статусу active, то ЦБД автоматично створює повʼязаний contracts у статусі pending.
...
Організатор має можливість:
- Завантаження підписаного договору з учасником;
- Підтвердження підписання договору;
- Дискваліфікації учасника.
contracts створюються не після того, як Award набув статусу active
...
Ручна дія.
Організатор завантажує документ contracts[x].documents.documentType: contractSigned і після цього надсилає запит на зміну contracts.status: pending → active
Повʼязаний Авард має бути у статусі active.
...
Якщо змінився contracts.status: pending → active, це означає, що завантажено Підписаний договір (contracts.documents.documentType: contractSigned)
...
Автоматична.
За умови дискваліфікації Аварда із active → unsuccessful
Для того, щоб дискваліфікувати Учасника з причини того, що НЕ підписано договір або неотримано оплату, організатору необхідно надіслати запит на зміну статуса Аварда active → unsuccessful
Документи контракту (contracts.documents)
...
documentType
...
Назва Українською
...
Назва Англійською
...
Опис
...
Обовʼязковіть
...
Публічність
...
Підписаний договір
...
Так
...
Додатки до договору
...
Ні
...
Офіційне повідомлення, що містить деталі договору
Ні
...
Умови дискваліфікації
Дискваліфікація Організатором
У разі дискваліфікації переможця на етапі роботи із договором (signingPeriod), Організатор аукціону складає та оприлюднює в електронній торговій системі протокол відхилення (documentType:rejectionProtocol) або/та акт про відмову (documentType:act) та натискає на кнопку “Дискваліфікувати” і вказує одну причину з переліку причин (причина записуються в поле terminationReason аварду):
Після чого майданчик передає статус unsuccessful award`у учасника, внаслідок чого ЦБД автоматично переводить договір у статус cancelled. Вказана причина, а також статус учасника, повинні відображатися на майданчику.
- Перелік причин дискваліфікації:
- Відмова або непідписання протоколу
- Відмова або непідписання договору
- Відсутні обов’язкові документи
- Невнесення передоплати або оплати за договором
- Участь в аукціоні з більше, ніж 1 майданчика
До переведення статусу award`у учасника в unsuccessful, Організатор повинен мати можливість змінити причину дисквалифікації та завантажити або замінити документ/ти.
Повідомлення щодо кваліфікації (загальні)
Скасування аукціону
Рішення Організатора про відміну аукціону повинне бути викладене у формі розпорядчого акта (рішення, наказу, розпорядження, протоколу тощо)
Скасувати процедуру є можливість у статусах, окрім термінальних
У разі відміни аукціону ЦБД автоматично присвоює аукціону статус “Аукціон відмінено”.
Деталі описано тут
Документи скасування процедури (cancellations.documents)
...
documentType
...
Назва Укр
...
Назва Анг
...
Опис
...
Обовʼязковіть для скасування процедури
...
Публічність
...