...
Swagger можна знайти ТУТ на табі з відповідною назвою "Jobber" (зараз там ще нічого немає, але буде)
Майданчик повинен забезпечити можливість Організатору створити та керувати процесом реалізації санкційного активу шляхом публікації об'єкта типу: jobber.sanctionedAuctionChain
Публікація цього об'єкта автоматично запускає процес створення до трьох аукціонів відповідно до логіки, визначеної в ТЗ.
Майданчик не зобов'язаний реалізовувати конкретний дизайн інтерфейсу, але повинен забезпечити можливість введення, перегляду і редагування даних, визначених у цьому документі.
Шлях Організатора на Майданчику
Публікація ланцюжка
Бізнесово: У Організатора повинна бути можливість запустити Процес реалізації санкційного активу активу (ланцюжок аукціонів) шляхом публікації в ЦБД першого аукціону.Технічно: Від
| Note |
|---|
Важливо, що нормативно не існує такого поняття, як "ланцюжок". Організатор публікує саме перший аукціон (процедуру), але від Майданчика ЦБД буде очікувати запит на |
...
публікацію обʼєкта jobber.sanctionedAuctionChain Організатор запускає саме "Процес реалізації санкційного активу". Публікація може (і бажано) виглядати як створення Процедури. Окремо відображати якийсь "реєстр ланцюжків" не потрібно. Це технічні особливості. Організатор працює з Процедурами |
Обовʼязкові поля
Бізнесово: Оголосити електронний аукціон має право виключно організатор аукціону після затвердження затвердження стартових цін реалізації активу для всіх аукціонів.
...
| Назва поля | field | Коментар |
|---|---|---|
| Документи аукціону та пов'язані додатки | initialProps.documents | Використовується стандартна логіка Обовʼязкові документи для публікації ланцюжка відсутні. Описано в ТЗ |
| Мінімальна кількість заяв | initialProps.minNumberOfQualifiedBids | Поле не обовʼязкове для заповнення Організатор може передати явно 1 або 2 за необхідності Якщо не заповнює, то ЦБД автоматично проставить 1 |
| Порядок ознайомлення з майном, час і місце проведення огляду об’єкта | initialProps.accessDetails | |
| Додаткові відомості | initialProps.x_additionalInformation |
Технічні поля, які необхідно передати в запиті "невидимо" для Організатора
| Назва | field | Коментар |
|---|---|---|
| Метод | pipelineMethod | Необхідно передати "pipelineMethod": "sanctionAuctionChain" |
| Info | ||
|---|---|---|
| ||
Має бути можливість створити копію обʼєкта JSC із чернетки, яку заповнює Органіатор та може зберігти локально на Майданчику до публікації обʼєкта JSC |
Авто-створення першої процедури в ланцюжку
...
| Info |
|---|
Можна робити перший запит через 10 секунд після публікації "ланцюжка". Якщо повернувся пустий масив[], то повторний запит через 30 секунд і далі з інтервалом в 1 хв. Як варіант, отримання токену не автоматизовувати, а надати можливість Організатору отримувати по кнопці і переходити на Аукціон. Можна завʼязатися на Mirror і "відловлювати" обʼєкт там. Фільтр - по полю "owner". Ця реалізація на розсуд Майданчика, тут описані лише можливі варіанти.Головне, щоб Організатор мав можливість працювати з авто-створеною процедурою аналогічно як з тою, яка публікується "руками" Майданчик повинен забезпечити можливість:
відповідно до стандартних правил роботи з процедурами. Процедура нічим не відрізняється від стандартної процедури Prozorro.Sale. |
Приклад запиту для отримання id і токену процедури:
...
Відбувається стандартна робота з процедурою, яка не відрізняється від існуючого процесу.
Особливості
Редагування полів
Майданчик повинен забезпечити можливість Організатору переглянути інформацію про заплановані наступні аукціони.
Майданчик повинен відображати про наступні аукціони тривалість експозиціїВ інтерфейсі необхідно дати можливість Організатору побачити дані щодо запланованих другого і третього аукціонів.
Технічно можна отримати цю інформацію з запиту до обʼєкта JSC в полі _specs. Деталі Деталі тут в ТЗ
Спосіб відображення визначається Майданчиком. Наприклад, на сторінці Процедури, де Організатор бачить всю інформацію про поточну процедуру в окремому блоці чи на окремій табі також відображати "Інформацію про майбутні процедури"
З моменту створення першої процедури "ланцюжок" набуває статусу active.
В цьому статусі "ланцюжка" Організатор може редагувати поля:
- період експозиції для другої процедури (в днях) до моменту створення другої процедри в ланцюжку
- період експозиції для третьої процедури (в днях) до моменту створення третьої процедри в ланцюжку
В JSC редагуються тільки два вищевказані параметри.
...
Редагування параметрів ланцюжка
Після створення першої процедури Майданчик повинен забезпечити можливість редагування Організатором:
тривалості експозиції другого аукціону
тривалості експозиції третього аукціону
Редагування можливе лише до створення відповідної процедури.
Інші поля і документи в JSC редагуванню не підлягають.
| Note |
|---|
У Організатора повинна бути можливість редагувати поля першої створеної процедури, а також можливість редагувати: "Тривалість періоду експозиції лоту до другого аукціону (в днях)" |
| Info | ||
|---|---|---|
| ||
Редагування полів із JSC - це окремий запит. Це не редагування процедури. Зверніть увагу, що якщо Організатор редагує тільки поля для майбутніх процедур, то не потрібно надсилати запит на редагування для поточної процедури, бо це може призвести до деактивації бідів. Іншими словами - Організатор може редагувати:
В першому і другому випадках не потрібно слати два запити: PATCH на процедуру і PATCH на JSC, бо в цьому немає потреби і може призвести до деактивації бідів |
Авто-створення другої процедури в ланцюжку
Якщо перша процедура в ланцюжку отримала статус unsuccessful, то протягом 5 хвилин створюється друга процедура, в яку копіюються значення полів із першої процедури
...
, а також встановлюється дата auctionPeriod.startDate відповідно до періода експозиції
...
, який задав Організатор при публікації "ланцюжка"
...
Обʼєкт "ланцюжка" не змінює статус і залишаєтсья у статусі active
Деталі і приклади розрахунку стартової ціни описані в розділі "Поля що розраховуються автоматично при створенні другої і третьої процедури"
| Note | |||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| |||||||||||||||||||||||||||||||||
Такі поля, як:
автоматично скопіюються в другу процедуру із першої процедури! (не з "ланцюжка"!) Тобто, якщо Організатор редагував поля в першій процедурі, то в другу скопіюються відредаговані поля із першої процедури, а не першочергові із "ланцюжка". |
| Note |
|---|
У Організатора повинна бути можливість редагувати поля другої створеної процедури, а також можливість редагувати "Тривалість періоду експозиції лоту до третього аукціону (в днях)" |
Авто-створення третьої процедури в ланцюжку
Якщо друга процедура в ланцюжку отримала статус unsuccessful, то протягом 5 хвилин створюється третя процедура, в яку копіюються значення полів із другої процедури, а також встановлюється дата auctionPeriod.startDate відповідно до періода експозиції, який задав Організатор при публікації "ланцюжка"
Обʼєкт "ланцюжка" не змінює статус і залишаєтсья у статусі active
Деталі і приклади розрахунку стартової ціни описані в розділі "Поля що розраховуються автоматично при створенні другої і третьої процедури"
| Note |
|---|
У Організатора повинна бути можливість редагувати поля другої створеної процедури |
Копіювання даних між процедурами
Поля копіюються з попередньої процедури, не з JSC.
Це означає, що якщо Організатор редагував першу процедуру, то друга процедура використовує відредаговані значення.
Поведінка інтерфейсу (обовʼязкова функціональність)
Майданчик повинен забезпечити можливість:
- створити ланцюжок
- переглянути створені процедури
- Необхідно відображати поля процедури, а також "Інформація про дати і періоди аукціонів", які можуть бути опубліковані автоматично в майбутньому
- перейти до процедур
- редагувати процедури
- переглянути інформацію про майбутні процедури
- редагувати періоди експозиції