Реалізація в ЦБД

Особливості інактивації Біда (поле inactivationDate)

Якщо протягом rectificationPeriod була змінена Процедура (PATCH), то до цієї Процедури в API response додається поле inactivationDate заповнене датою PATCH процедури ( inactivationDate == dateModified )

Якщо процедуру PATCH-ать повторно, то поле inactivationDate оновлюється новою датою і так з кожним PATCH.

Для чого це потрібно по крокам:

1. Опублікували Процедуру, почався active_tendering
2. Біди подали і активували заяви на участь
3. Після цього Організатор відредагував Процедуру (PATCH)
4. Біди отримали статус inactivate (ЦБД їм змінило статус автоматично)
5. В mirror потрапила змінена процедура, але нічого про Біди в ній ще нема (public API не віддає в mirror бідів по процедурі у статусі active_tendering) і Організатор не бачить Бідів в public API.

Майданчикам Бідів треба якось зрозуміти, що їх Біди деактивувалися і оновити їм статус.

• Через mirror прилітає змінена Процедура і вони бачать, що зʼявилося поле inactivationDate. Це є тригер для того, щоб пересинхронізувати своїх Бідів і оновити їм статус active -> inactivate (На стороні Майданчика ще може надсилатися нотифікація Учаснику, що Процедура була відредагована і заява на участь деактивована)

Щоб Майданчикам кожен раз НЕ пересинхронізовувати своїх бідів, як тільки вони отримують через mirror змінену процедуру, краще завʼязуватись на inactivationDate, а не на dateModified (бо dateModified оновлюється навіть при зміних, що не є потрібними для даної ситуації (наприклад, коли до Процедури додають "запитання чи відповідь"))
Зараз Майданчикам зручно завʼязати логіку на inactivationDate і не закидувати нас постійно запитами для синхронізації Бідів.

Особливості відображення на порталі

Відсутні особливості для відображення на порталі

Вимоги до відображення на інтерфейсі майданчика

1. Майданчик забезпечує можливість редагування оголошення після публікації в рамках Періоду редагування
   • Для редагування доступні поля, які передав майданчик організатора під час оголошення процедури, крім дати та часу початку аукціону та типу процедури. У випадку відмінної логіки роботи, поля, доступні для редагування, та винятки визначаються на рівні окремого документу з вимогами до майданчиків.
2. Для підтвердження внесених змін (поля оголошення) Організатор має можливість завантажити документ - "Погодження змін до опису лоту. Опис причин редагування." має містити перелік змін, які вносяться в оголошення, причину внесення таких змін. Він має бути доступний для завантаження в період редагування (обов’язковість документу визначається на рівні окремого документу з вимогами до майданчиків).
   • Для редагування Організатору необхідно натиснути кнопку “Редагувати аукціон” та “Зберегти” для підтвердження змін
   • Під одне завантаження такого документу відкривається тимчасове вікно (1 година), протягом якого Організатор може вносити зміни в поля оголошення ПЛАНУЄТЬСЯ ДО РЕАЛІЗАЦІЇ В МАЙБУТНЬОМУ
3. Протягом періоду редагування та періоду відповідей Організатор аукціону може завантажувати та замінити документи оголошення (без документу "Погодження змін до опису лоту. Опис причин редагування.") 
4. Необхідно виводити інформацію про історію змін документів

Сповіщення

Нотифікації

*Текст повідомлення може відрізнятися від запропонованого у випадку, якщо суть повідомлення користувачу не втрачається.

Якщо користувач не активував свою пропозицію, наступного дня за 24 години необхідно надсилати повторне сповіщення на e-mail та в особистий кабінет. Сповіщення повторювати кожен день до активації/скасування заяви на участь або до завершення прийому заяв на участь. В учасника має бути можливість анулювати свою заяву на участь після деактивації.

Перелік процедур, де період редагування процедури розпочинається одночасно з періодом подачі пропозицій учасниками: