| Table of Contents | ||
|---|---|---|
|
Одночасно розпочинається період подання заяв на участь та період редагування
Реалізація в ЦБД
Приклади процедур: | BSE/BSD |
GFE/GFD |
ALE |
AAE |
CSE/CSD |
/CSP 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 | Організатору | Для редагування оголошення необхідно завантажити документ "Погодження змін до опису лоту. Опис причин редагування" |
Нотифікації
При деактивацій заяви
(bid status active →inactive)
Для участі в аукціоні необхідно повторно активувати заяву.
*Текст повідомлення може відрізнятися від запропонованого у випадку, якщо суть повідомлення користувачу не втрачається.
...
Перелік процедур, де період редагування процедури розпочинається одночасно з періодом подачі пропозицій учасниками:
| Напрям роботи | Біди переходять в inactive | Якщо редагуються поля: | |||||
|---|---|---|---|---|---|---|---|
| BSE/BSD | Так |
| |||||
| GFE/GFD | Ні | - | |||||
| ALE | Так |
| |||||
| AAE | Ні | - | |||||
| CSE/CSD/CSP | Так |
| |||||
| BRE/BRD | Так |
| |||||
| RLE/RLD | Так |
| |||||
| CLE/CLD | Так |
| |||||
| NLE/NLD | Так |
| |||||
| APE/APD | Так |
| |||||
| SSW | Так |
|
Період редагування завершується до початку періоду приймання пропозицій
Реалізація в ЦБД
Приклад процедур: | LRE LSE/LSP LLE/LLD/LLP RMA SUE/SUD LAE/LAP |
| Коли |
|
| Передумова |
|
Дії |
|
Запит: | PATCH /api/procedures/{procedure_id} |
Валідації: |
|
Результат: |
|
Додаткові умови: | *Організатор підчас редагування може одночасно редагувати:
|
Особливості відображення на порталі
Відсутні особливості для відображення на порталі
Вимоги до відображення на інтерфейсі майданчика
- Майданчик забезпечує можливість редагування оголошення після публікації в рамках Періоду редагування
- Для редагування доступні поля, які передав майданчик організатора під час оголошення процедури, крім дати та часу початку аукціону та типу процедури. У випадку відмінної логіки роботи, поля, доступні для редагування, та винятки визначаються на рівні окремого документу з вимогами до майданчиків.
- Для редагування Організатору необхідно натиснути кнопку “Редагувати аукціон” та “Зберегти” для підтвердження змін
- Необхідно виводити інформацію про історію змін документів
Період редагування відбувається до оголошення процедури
Реалізація в ЦБД
Процедури: | SPE/SPD LPE |
| Коли |
|
| Передумова |
|
Дії |
|
Запит: | https://procedure-sandbox.prozorro.sale/api/doc#/asset/asset_update_item |
Валідації: |
|
Результат: |
|
Додаткові умови: | *Організатор підчас редагування може одночасно редагувати:
|
Особливості відображення на порталі
Відсутні особливості для відображення на порталі
Вимоги до відображення на інтерфейсі майданчика
- Майданчик забезпечує можливість редагування ІП та Об'єкту реєстра після публікації в рамках Періоду редагування
- Для редагування доступні поля, які передав майданчик організатора під час оголошення ІП та Об'єкта реєстра, крім автоматично заповнених полів. У випадку відмінної логіки роботи, поля, доступні для редагування, та винятки визначаються на рівні окремого документу з вимогами до майданчиків.
- Для підтвердження внесених змін до полів ІП (поля оголошення) Організатор має завантажити документ - "announcement.documents.documentType: clarifications" який має містити перелік змін, які вносяться в ІП, причину внесення таких змін. Він має бути доступний для завантаження в період редагування (обов’язковість документу визначається на рівні окремого документу з вимогами до майданчиків).
- Для редагування Організатору необхідно натиснути кнопку “Редагувати ІП” та “Зберегти” для підтвердження змін
- Необхідно виводити інформацію про історію змін документів
Сповіщення
Коли | Кому | Рекомендований текст* |
|---|---|---|
| При спробі відредагувати поля ІП без попереднього завантаження документа clarafications | Організатору | Для редагування оголошення необхідно завантажити документ "announcement.documents.documentType: clarifications" |
*Текст повідомлення може відрізнятися від запропонованого у випадку, якщо суть повідомлення користувачу не втрачається.
Період редагування відсутній
Реалізація в ЦБД
Процедури: | RCE/RСD |
Особливості відображення на порталі
Відсутні особливості для відображення на порталі
Вимоги до відображення на інтерфейсі майданчика
Майданчик не надає можливості редагування оголошення після публікації в рамках всіх періодів процедури
| Children Display | ||
|---|---|---|
|
...