Одночасно розпочинається період подання заяв на участь та період редагування
Реалізація в ЦБД
Процедури: | BSE/BSD, GFE/GFD, ALE, AAE, CSE/CSD, BRE/BRD, RLE/RLD, CLE/CLD, NLE/NLD APE/APD SSW |
| Коли |
|
| Передумова |
|
Дії |
|
Запит: | PATCH /api/procedures/{procedure_id} |
Валідації: |
|
Результат: |
|
Додаткові умови: | *Організатор підчас редагування може одночасно редагувати:
|
Сповіщення: | У випадку відсутності завантаження документа clarifications { |
Особливості інактивації Біда (поле 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 година), протягом якого Організатор може вносити зміни в поля оголошення ПЛАНУЄТЬСЯ ДО РЕАЛІЗАЦІЇ В МАЙБУТНЬОМУ
- Протягом періоду редагування та періоду відповідей Організатор аукціону може завантажувати та замінити документи оголошення (без документу "Погодження змін до опису лоту. Опис причин редагування.")
- Необхідно виводити інформацію про історію змін документів
Сповіщення
| При спробі відредагувати оголошення без попереднього завантаження документа clarafications | Організатору | Для редагування оголошення необхідно завантажити документ "Погодження змін до опису лоту. Опис причин редагування" |
Нотифікації
При деактивацій заяви | Учаснику | Ваша заява деактивована у зв‘язку з тим, що Організатором було відредаговано оголошення. Для участі в аукціоні необхідно повторно активувати заяву. | Кожні 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 | Так |
|