Одночасно розпочинається період подання заяв на участь та період редагування
Реалізація в ЦБД
Процедури: | BSE/BSD, GFE/GFD, ALE, AAE, CSE/CSD, BRE/BRD, RLE/RLD, CLE/CLD, NLE/NLD APE/APD SSW |
| Коли | - Статус процедури: active_rectification
- Період процедури: rectificationPeriod
|
| Передумова | - Завантажено документ clarifications (обов’язкова дія для редагування ПОЛІВ Процедури)
- Завантажено документи, які необхідно замінити в оголошенні (у випадку редагування документів)
|
Дії | - Записує нові дані в поля, які потребують оновлення (Доступне редагування лише тих полів, які Організатор заповнював при публікації оголошення)*
- Додає посилання на опубліковані в документ сервісі документи, які необхідно замінити*
|
Запит: | PATCH /api/procedures/{procedure_id}
https://procedure-sandbox.prozorro.sale/api/doc#/active_rectification/update_procedure
|
Валідації: | - Організатор може вносити зміни тільки в ті поля, які заповнював при публікації оголошення
|
Результат: | - ЦБД оновлює дані оголошення
- В разі наявності бідів в статусі active, ЦБД переводить заяви в статусі active у статус inactive (інактивуються біди) (НЕ для всіх Процедур! Див нижче таблицю)
|
Додаткові умови: | *Організатор підчас редагування може одночасно редагувати: - поля оголошення і документи
- тільки поля оголошення
- тільки документи оголошення
|
Сповіщення: | У випадку відсутності завантаження документа clarifications {
"message": {
"documents": "Procedure cannot be updated without clarifications document. To update procedure data upload clarifications document first"
}
} |
Особливості інактивації Біда (поле inactivationDate)
Якщо протягом rectificationPeriod була змінена Процедура (PATCH), то до цієї Процедури в API response додається поле inactivationDate заповнене датою PATCH процедури ( inactivationDate == dateModified )
Якщо процедуру PATCH-ать повторно, то поле inactivationDate оновлюється новою датою і так з кожним PATCH.
Для чого це потрібно по крокам:
- Опублікували Процедуру, почався active_tendering
- Біди подали і активували заяви на участь
- Після цього Організатор відредагував Процедуру (PATCH)
- Біди отримали статус inactivate (ЦБД їм змінило статус автоматично)
- В mirror потрапила змінена процедура, але нічого про Біди в ній ще нема (public API не віддає в mirror бідів по процедурі у статусі active_tendering) і Організатор не бачить Бідів в public API.
Майданчикам Бідів треба якось зрозуміти, що їх Біди деактивувалися і оновити їм статус.
- Через mirror прилітає змінена Процедура і вони бачать, що зʼявилося поле inactivationDate. Це є тригер для того, щоб пересинхронізувати своїх Бідів і оновити їм статус active -> inactivate (На стороні Майданчика ще може надсилатися нотифікація Учаснику, що Процедура була відредагована і заява на участь деактивована)
Щоб Майданчикам кожен раз НЕ пересинхронізовувати своїх бідів, як тільки вони отримують через mirror змінену процедуру, краще завʼязуватись на inactivationDate, а не на dateModified (бо dateModified оновлюється навіть при зміних, що не є потрібними для даної ситуації (наприклад, коли до Процедури додають "запитання чи відповідь"))
Зараз Майданчикам зручно завʼязати логіку на inactivationDate і не закидувати нас постійно запитами для синхронізації Бідів.
Особливості відображення на порталі
Відсутні особливості для відображення на порталі
Вимоги до відображення на інтерфейсі майданчика
- Майданчик забезпечує можливість редагування оголошення після публікації в рамках Періоду редагування
- Для редагування доступні поля, які передав майданчик організатора під час оголошення процедури, крім дати та часу початку аукціону та типу процедури. У випадку відмінної логіки роботи, поля, доступні для редагування, та винятки визначаються на рівні окремого документу з вимогами до майданчиків.
- Для підтвердження внесених змін (поля оголошення) Організатор має можливість завантажити документ - "Погодження змін до опису лоту. Опис причин редагування." має містити перелік змін, які вносяться в оголошення, причину внесення таких змін. Він має бути доступний для завантаження в період редагування (обов’язковість документу визначається на рівні окремого документу з вимогами до майданчиків).
- Для редагування Організатору необхідно натиснути кнопку “Редагувати аукціон” та “Зберегти” для підтвердження змін
- Під одне завантаження такого документу відкривається тимчасове вікно (1 година), протягом якого Організатор може вносити зміни в поля оголошення ПЛАНУЄТЬСЯ ДО РЕАЛІЗАЦІЇ В МАЙБУТНЬОМУ
- Протягом періоду редагування та періоду відповідей Організатор аукціону може завантажувати та замінити документи оголошення (без документу "Погодження змін до опису лоту. Опис причин редагування.")
- Необхідно виводити інформацію про історію змін документів
Сповіщення
Нотифікації
| | | |
|---|
При деактивацій заяви
(bid status active →inactive)
| Учаснику | Ваша заява деактивована у зв‘язку з тим, що Організатором було відредаговано оголошення.
Для участі в аукціоні необхідно повторно активувати заяву. | Кожні 24 години, поки зава знаходиться в статусі inactive, до завершення tenderPeriod |
*Текст повідомлення може відрізнятися від запропонованого у випадку, якщо суть повідомлення користувачу не втрачається.
Якщо користувач не активував свою пропозицію, наступного дня за 24 години необхідно надсилати повторне сповіщення на e-mail та в особистий кабінет. Сповіщення повторювати кожен день до активації/скасування заяви на участь або до завершення прийому заяв на участь. В учасника має бути можливість анулювати свою заяву на участь після деактивації.
Перелік процедур, де період редагування процедури розпочинається одночасно з періодом подачі пропозицій учасниками:
| | |
|---|
| BSE/BSD | Так | |
| GFE/GFD | Ні | - |
| ALE | Так |
|
| AAE | Ні | - |
| CSE/CSD | Так |
|
| BRE/BRD | Так |
|
| RLE/RLD | Так |
|
| CLE/CLD | Так |
|
| NLE/NLD | Так |
|
| APE/APD | Так |
|
| SSW | Так | |
Період редагування завершується до початку періоду приймання пропозицій
