| Table of Contents | ||
|---|---|---|
|
Одночасно розпочинається період подання заяв на участь та період редагування
Реалізація в ЦБД
Процедури: | 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 (На стороні Майданчика ще може надсилатися нотифікація Учаснику, що Процедура була відредагована і заява на участь деактивована)
...
Особливості відображення на порталі
Відсутні особливості для відображення на порталі
Вимоги до відображення на інтерфейсі майданчика
- Майданчик забезпечує можливість редагування оголошення після публікації в рамках Періоду редагування
- Для редагування доступні поля, які передав майданчик організатора під час оголошення процедури, крім дати та часу початку аукціону та типу процедури. У випадку відмінної логіки роботи, поля, доступні для редагування, та винятки визначаються на рівні окремого документу з вимогами до майданчиків.
- Для підтвердження внесених змін (поля оголошення) Організатор має можливість завантажити документ - "Погодження змін до опису лоту. Опис причин редагування." має містити перелік змін, які вносяться в оголошення, причину внесення таких змін. Він має бути доступний для завантаження в період редагування (обов’язковість документу визначається на рівні окремого документу з вимогами до майданчиків).
- Для редагування Організатору необхідно натиснути кнопку “Редагувати аукціон” та “Зберегти” для підтвердження змін
- Під одне завантаження такого документу відкривається тимчасове вікно (1 година), протягом якого Організатор може вносити зміни в поля оголошення ПЛАНУЄТЬСЯ ДО РЕАЛІЗАЦІЇ В МАЙБУТНЬОМУ
- Протягом періоду редагування та періоду відповідей Організатор аукціону може завантажувати та замінити документи оголошення (без документу "Погодження змін до опису лоту. Опис причин редагування.")
- Необхідно виводити інформацію про історію змін документів
Сповіщення
Коли | Кому | Рекомендований текст* |
|---|---|---|
| При спробі відредагувати оголошення без попереднього завантаження документа clarafications | Організатору | Для редагування оголошення необхідно завантажити документ "Погодження змін до опису лоту. Опис причин редагування" |
Нотифікації
При деактивацій заяви
(bid status active →inactive)
Для участі в аукціоні необхідно повторно активувати заяву.
*Текст повідомлення може відрізнятися від запропонованого у випадку, якщо суть повідомлення користувачу не втрачається.
Якщо користувач не активував свою пропозицію, наступного дня за 24 години необхідно надсилати повторне сповіщення на e-mail та в особистий кабінет. Сповіщення повторювати кожен день до активації/скасування заяви на участь або до завершення прийому заяв на участь. В учасника має бути можливість анулювати свою заяву на участь після деактивації.
Період редагування завершується до початку періоду приймання пропозицій
Реалізація в ЦБД
Процедури: | LRE, LSE/LSP, LLE/LLD/LLP, RMA, SUE/SUD, LAE/LAP |
| Коли |
|
| Передумова |
|
Дії |
|
Запит: | PATCH /api/procedures/{procedure_id} |
...
prozorro.sale/api/doc#/active_rectification/update_procedure | |
Валідації: |
|
Результат: |
|
Додаткові умови: | *Організатор підчас редагування може одночасно редагувати:
|
Особливості відображення на порталі
Відсутні особливості для відображення на порталі
Вимоги до відображення на інтерфейсі майданчика
- Майданчик забезпечує можливість редагування оголошення після публікації в рамках Періоду редагування
- Для редагування доступні поля, які передав майданчик організатора під час оголошення процедури, крім дати та часу початку аукціону та типу процедури. У випадку відмінної логіки роботи, поля, доступні для редагування, та винятки визначаються на рівні окремого документу з вимогами до майданчиків.
- Для редагування Організатору необхідно натиснути кнопку “Редагувати аукціон” та “Зберегти” для підтвердження змін
- Необхідно виводити інформацію про історію змін документів
Період редагування відбувається до оголошення процедури
Реалізація в ЦБД
Процедури: | SPE/SPD, LPE |
| Коли |
|
| Передумова |
|
Дії |
|
Запит: | https://procedure-sandbox.prozorro.sale/api/doc#/asset/asset_update_item |
Валідації: |
|
Результат: |
|
Додаткові умови: | *Організатор підчас редагування може одночасно редагувати:
|
Особливості відображення на порталі
Відсутні особливості для відображення на порталі
Вимоги до відображення на інтерфейсі майданчика
- Майданчик забезпечує можливість редагування ІП та Об'єкту реєстра після публікації в рамках Періоду редагування
- Для редагування доступні поля, які передав майданчик організатора під час оголошення ІП та Об'єкта реєстра, крім автоматично заповнених полів. У випадку відмінної логіки роботи, поля, доступні для редагування, та винятки визначаються на рівні окремого документу з вимогами до майданчиків.
- Для підтвердження внесених змін до полів ІП (поля оголошення) Організатор має завантажити документ - "announcement.documents.documentType: clarifications" який має містити перелік змін, які вносяться в ІП, причину внесення таких змін. Він має бути доступний для завантаження в період редагування (обов’язковість документу визначається на рівні окремого документу з вимогами до майданчиків).
- Для редагування Організатору необхідно натиснути кнопку “Редагувати ІП” та “Зберегти” для підтвердження змін
- Необхідно виводити інформацію про історію змін документів
Сповіщення
Коли | Кому | Рекомендований текст* |
|---|---|---|
| При спробі відредагувати поля ІП без попереднього завантаження документа clarafications | Організатору | Для редагування оголошення необхідно завантажити документ "announcement.documents.documentType: clarifications" |
*Текст повідомлення може відрізнятися від запропонованого у випадку, якщо суть повідомлення користувачу не втрачається.
Період редагування відсутній
Реалізація в ЦБД
Процедури: | RCE/RSD |
Особливості відображення на порталі
Відсутні особливості для відображення на порталі
Вимоги до відображення на інтерфейсі майданчика
Майданчик не надає можливості редагування оголошення після публікації в рамках всіх періодів процедури
Перелік процедур, де період редагування процедури розпочинається одночасно з періодом подачі пропозицій учасниками:
...
...
| Children Display | ||
|---|---|---|
|
...