Технічне завдання на розробку процедури “Продаж землі на англійському аукціоні з переважним правом”

Загальний огляд процедури

Паспорт процедури

РинокПродаж землі (landSell)
Бізнес назваПродаж землі з переважним правом на англійському аукціоні
Тип аукціонуАнглійський аукціон з переважним правом (priorityEnglish)
Технічна назва процедуриlandSell-priorityEnglish
Буквений ідентифікатор процедуриLSP
Процедура найбільше схожа на

- landSell-English

- landArrested-priorityEnglish

Мета створення процедури та нормативні засади

З метою проведення електронних аукціонів з продажу землі на англійському аукціоні з переважним правом, в рамках ProZorro.Sale реалізовано sellingMethod: landSell-priorityEnglish.

Відмінності від landSell-English

  1. На етапі роботи з оголошенням:
    1. Додано новий період процедури - період передачі переважного права (transferPriorityPeriod). В цей період Організатор може змінити дані учасників з переважним правом, відповідно від цього змінюються вказівники на переважне право (bid.priority) в учасників.
    2. Організатор вказує дані учасників з переважним правом currentTenants:
      1. До моменту запуску універсального модулю аукціону (модулю аукціону, що може працювати з подвійним переважним правом):
        1. може бути заповнений тільки 1 елемент списку з вказаним значенням currentTenants.priority == з переважним правом (0).
      2. Після запуску універсального модулю аукціону:
        1. можуть бути заповнені 2 елементи зі списку.
        2. Має бути обов'язково заповнено поле numberOfCurrentTenants.
        3. Якщо numberOfCurrentTenants == 1 може бути заповнений тільки один елемент масиву currentTenants.
        4. Якщо numberOfCurrentTenants == 1, то значення поля currentTenants.priority значення "Учасник з переважним правом" (currentTenants.priority == 0)
    3. В масиві currentTenants присутні наступні валідації:
      1. значення identifier.id в масиві currentTenants не можуть повторюватися
      2. значення поля priority в масиві currentTenants не можуть повторюватися
      3. якщо заповнений тільки один елемент масиву currentTenants, тоді currentTenants.priority == з переважним правом (0).
  2. На етапі роботи з заявою на участь:
    1. Учасник вказаний в currentTenants як учасник (priority == 0) з переважним правом при активації заяви отримує сповіщення що його заява прийнята як заява з переважним правом.
    2. Учасник вказаний в currentTenants як учасник (priority == 1) з переважним правом другої черги при активації заяви отримує сповіщення що його заява прийнята як заява з переважним правом другої черги.
    3. В учасників вказаних Організатором в currentTenants мають бути різні identifier.id.
    4. При зміні Організатором ідентифікатора учасників вказаних в currentTenants bid;
      1. якщо identifier.id учасника більше не вказаний в масиві currentTenants:
        1. статус bid’а учасника змінюється на inactive.
      2. якщо identifier.id вказаний в масиві currentTenants, але в нього змінилося значення поля priority:
        1. з 0 на 1 статус bid’а учасника змінюється на inactive, учаснику надсилається сповіщення, про те, що він може продовжити участь в аукціоні як учасник з переважним правом другої черги, але для цього необхідно повторно активувати заяву на участь;
        2. з 1 на 0, статус bid’а учасника не змінюється, учаснику приходить сповіщення про те, що його заява зареєстрована як заява учасника з переважним правом.
  3. На етапі аукціону:
    1. На першому етапі робота з модулем аукціону з переважним правом.
    2. На другому етапі робота з універсальним модулем аукціону.
  4. На етапі кваліфікації:
    1. Відсутні

Структура даних

Структура даних

Особливості структури даних

Нижче описані зміни в структурі даних відносно базової процедури продажу землі:

  1. currentTenants:
    1. maxItems: 2
    2. Items:
      1. allOf:
        1. Priority:
          1. Не може бути два item з однаковим пріоритетом

          2. Maximum: 1
          3. Словник “priorityType”: Values [0,1]
          4. default: 0
          5. readonly: true
  2. В існуючій моделі “Заява на участь” (landSell-priorityEnglish.Bid) змінюється:
    1. allOf:
      1. Priority:
        1. Тільки у двох bid може бути заповнене поле пріоритет. Значення "0" - може бути лише у одного bid, Значення "1" - може бути лише у одного bid

        2. maximum: 1
  3. Словник “priorityType”:
    1. default: 0
    2. readonly: true
    3. Values [0,1]

Мінімальна кількість учасників для початку кваліфікації = 2. Організатор не може змінити значення minNumberOfQualifiedBids

В період кваліфікації можна перейти в 2-х варіантах:

    1. За умови двох або більше заяв на участь
    2. Якщо є лише одна заява на участь, але цей аукціон проводиться повторно і цей один бід - від учасника, який єдиний брав участь в попередньому аукціоні (міститься в полі previousAuctionBidder)

Класифікатори та словники

Обов'язково використовується один основний класифікатор (CAV) та два додаткових (КВЦПЗ та КВЗУ). Передбачена можливість вказати декілька кодів КВЗУ. Необхідні значення класифікаторів описані в структурі даних. Значення основного класифікатора заповнюється у відповідності до значення додаткового класифікатора.

Періоди і статуси

Конфігураційний файл з періодами и статусами

Загальна схема процедури

Схема «Загальний процес»

Функціонал ролей в рамках періодів

https://drive.google.com/file/d/10S_lspGpgmdUMbSeFqRhez_uxUOMaaCT/view?usp=sharing

Статуси процедури

Статуси заяви на участь (біда)

https://drive.google.com/file/d/1EdQmIw0jUbibfJeQ-MQjZO-3E6Qxhr4S/view?usp=sharing

Статуси аварда

https://drive.google.com/file/d/1ePvBLfTrEcAoqzbCbvBb2xXag97nFHTn/view?usp=sharing

  1. Очікується протокол
    1. Технічний ідентифікатор - pending
    2. Організатор
      1. Завантаження протоколу (обов'язкова дія - з можливістю замінити протокол);
      2. Переведення статусу учасника до наступного статусу “Переможець. Очікується договір”;
      3. Дискваліфікація учасника;
    3. Учасник:
      1. Можливість завантажити та замінити протокол (не обов'язкова дія - з можливістю замінити протокол).
    4. Умови набуття статусу - автоматично присвоюється переможцю під час генерації авардів.
  2. Очікується рішення
    1. Технічний ідентифікатор - pending_waiting
    2. Організатор - відсутній
    3. Учасник
      1. Можливість 2-му учаснику відмовитися від очікування (до моменту дискваліфікації 1-го учасника та за умови, що процедура у не термінальному статусі)
    4. Умови набуття статусу - автоматично присвоюється 2-му (після переможця) учаснику під час генерації авардів
  3. Переможець. Очікується договір
    1. Технічний ідентифікатор - active
    2. Організатор:
      1. Завантаження договору (з можливістю замінити);
      2. Дискваліфікація учасника (до завершення аукціону);
      3. Підтвердження оплати;
      4. Завершення аукціону.
    3. Учасник
      1. Можливість 2-му учаснику відмовитися від очікування до моменту дискваліфікації 1-го переможця.
    4. Умови набуття статусу - Організатор підтверджує підписання протоколу і award змінює свій статус на active.
    5. Коментар - Дискваліфікувати переможця можливо до завершення аукціону. Відмовитися від очікування 2-му учаснику можливо до моменту дискваліфікації 1-го учасника або завершення аукціону.
  4. Дискваліфіковано
    1. Технічний ідентифікатор - unsuccessful
    2. Організатор - функціонал відсутній
    3. Учасник - функціонал відсутній
    4. Умови набуття статусу - дискваліфікація учасника на будь-якому етапі кваліфікації
  5. Учасник не став переможцем
    1. Технічний ідентифікатор - cancelled
    2. Організатор - функціонал відсутній
    3. Учасник - функціонал відсутній
    4. Умови набуття статусу
      1. 2-й учасник відмовився від очікування
      2. Організатор аукціону підтвердив оплату 1-им учасником (статус договору active), у зв’язку з чим 2-й учасник не набув статусу переможця (за умови, що 2-й учасник, не самодискваліфікувався).

Статуси контракту

https://drive.google.com/file/d/1W5Ysc5bAu1AvZDzr5CQXhUYhImK4pwGn/view?usp=sharing

  1. Очікується договір
    1. Технічний ідентифікатор - pending
    2. Організатор
      1. Завантаження підписаного договору з учасником;
      2. Підтвердження підписання договору;
      3. Дискваліфікація учасника.
    3. Учасник - відсутній
    4. Умови зміни статусу - автоматично присвоюється переможцю під час генерації авардів.
  2. Договір підписано
    1. Технічний ідентифікатор - signed
    2. Організатор:
      1. Підтвердження оплати.
    3. Учасник - відсутній
    4. Умови зміни статусу - Організатор підтвердив підписання договору з переможцем.
  3. Оплату за договором здійснено
    1. Технічний ідентифікатор - active
    2. Організатор:
      1. Завершення аукціону.
    3. Учасник - відсутній
    4. Умови зміни статусу - Організатор підтвердив отримання оплати.
  4. Договір скасовано
    1. Технічний ідентифікатор - cancelled
    2. Організатор - відсутній
    3. Учасник - відсутній
    4. Умови зміни статусу - Організатор аукціону дискваліфікував учасник через неможливість підписання договору або неотримання оплати.

Опис періодів

https://drive.google.com/file/d/1wCyAPmsTkuj7I7p3bainOeo63P4_L8DF/view?usp=sharing

Період підготовки - preleminaryPeriod (out of the system)

Статус процедури - поза системою

Період редагування - rectificationPeriod

Статус процедури - active_rectification

Період запитань - questionPeriod

Статус процедури - active_tendering

Період відповідей - enquiryPeriod

Статус процедури - active_tendering

Період передачі переважного права - transferPriorityPeriod

Статус процедури - active_tendering

Період подання пропозицій - tenderPeriod

Статус процедури - active_tendering

Період аукціону - auctionPeriod

Статус процедури - active_auction

Період кваліфікації - qualificationPeriod*

Статус процедури - active_qualification, active_awarded, pending_payment

Період підписання протоколу - award.verificationPeriod*

Статус процедури - active_qualification

Період підписання договору - award.signingPeriod*

Статус процедури - active_awarded

Період оплати - award.paymentPeriod*

Статус процедури - pending_payment

**Всі періоди кваліфікації завершуються Організатором аукціону вручну (не автоматична дія), але повинна бути реалізована фіксація порушення строків.

Типи, опис документів та робота з ними

Створення оголошення

Cтатус процедури: active_rectification, active_tendering Період процедури\аварду: tenderPeriod, rectificationPeriod

Редагування процедури

Статус процедури: active_rectification Період процедури\аварду: rectificationPeriod

Заява на участь

Статус процедури: active_tendering Період процедури\аварду: tenderPeriod

Cтатус процедури: active_qualification Період процедури\аварду: qualificationPeriod

Авард (об’єкт кваліфікації учасника)

Cтатус процедури: active_qualification Період процедури\аварду: qualificationPeriod

Cтатус процедури: active_qualification, active_awarded, pending_payment Період процедури\аварду: qualificationPeriod (award.verificationPeriod, award.signingPeriod, award.paymentPeriod)

Договір

Cтатус процедури: active_awarded Період процедури\аварду: qualificationPeriod (award.signingPeriod)

Cтатус процедури: pending_payment Період процедури\аварду: qualificationPeriod (award.paymentPeriod)

Скасування процедури

Cтатус процедури: active_rectification, active_tendering, active_auction, active_qualification, active_awarded, pending_payment Період процедури\аварду: rectificationPeriod, tenderPeriod, questionPeriod, enquiryPeriod, auctionPeriod, qualificationPeriod (award.verificationPeriod, award.signingPeriod, award.paymentPeriod)

Цифровий підпис

Cтатус процедури: active_tendering, active_auction, active_qualification, active_awarded, pending_payment Період процедури\аварду: rectificationPeriod, tenderPeriod, questionPeriod, enquiryPeriod, enquiryPeriod, qualificationPeriod (award.verificationPeriod, award.signingPeriod, award.paymentPeriod).

Загальні документи по розробці

Особливості роботи із сутностями та документами

Особливості роботи із цифровим підписом

Етапи процедури

Створення та редагування оголошення

Публікація оголошення

Організатор аукціону, під час публікації оголошення, вказує необхідні поля процедури. Вони вказані в ТЗ по інтерфейсу для майданчиків.

Присутня валідація на поле minimalStep.amount: значення мінімального кроку Аукціону має бути 1% (+/- 1 грн) від Стартової ціни (value.amount):
minimalStep.amount <= value.amount * 0.01 + 1
minimalStep.amount >= value.amount * 0.01 - 1

Поле minimalStep НЕ обовʼязкове для заповнення при публікації Процедури.
Якщо при публікації Процедури НЕ передається minimalStep, то значення автогенерується як 1% від Стартової ціни:
minimalStep.amount == value.amount * 0.01
minimalStep.currency == value.currency

Якщо при публікації Процедури передається НЕвалідне значення minimalStep.amount, ЦБД поверне помилку:

"message": {
        "minimalStep": "Wrong minimalStep value - {{передане при публікації значення minimalStep.amount}} Should be from {{X}} to {{Y}}"
    }

де Х - мінімально допустиме значення, що дозволить опублікувати Процедуру.
Y - максимально допустиме значення, що дозволить опублікувати Процедуру.

Учасник з попереднього аукціону (previousAuctionBidder)

Якщо при публікації процедури Організатор вказує номер попереднього аукціону (в полі previousAuctionId) і цей попередній аукціон не відбувся з причини того, що прийшов тільки один учасник, то в процедурі, що публікується наступною, ЦБД автоматично додасть інформацію про учасника, який прийшов на попередній аукціон в поле previuosAuctionBidder.

previousAuctionBіdder автогенерується, якщо tenderAttempts > 1 і попередній аукціон не відбувся через єдину заяву на участь. Заповнюється з попереднього аукціону, якщо він не відбувся з причини подання єдиної заяви на участь (заповнюється даними цього учасника).

Якщо після публікації такої процедури Організатор редагує поля таким чином, що прибирає із процедури інформацію про попередній аукціон з одним учасником протягом rectificationPeriod, то поле previousAuctionBidder також має зникнути автоматично.


Повідомлення при публікації оголошення

Редагування оголошення

Організатор має можливість внести зміни в ті поля які він заповнював самостійно під час публікації аукціону, окрім орієнтовного часу початку аукціону.

Протягом rectificationPeriod Організатор аукціону може завантажувати та замінювати документи оголошення. Для підтвердження внесених змін (поля оголошення) Організатор повинен обов'язково завантажити документ - clarifications. Протягом rectificationPeriod Організатор аукціону може завантажувати та замінювати документи оголошення без завантаження документу - "Погодження змін до опису лоту. Опис причин редагування".

Повідомлення при редагуванні оголошення (загальні)

Повідомлення при редагуванні оголошення

Обговорення аукціону (запитання-відповідь)

Посилання на схему «Обговорення електронних аукціонів (запитання-відповідь)»

Схема "Обговорення аукціонів"

Повідомлення при обговоренні аукціону (запитання-відповідь)

Розміщення заяви на участь

Робота із заявою на участь

Схема "Публікація оголошення та прийняття заяви про участь"

Робота із заявою на участь

Учасник, що подав пропозицію в період дії статусу процедури active_tendering, має можливість вносити зміни в поля заяви на участь, анулювати заяву та завантажувати, замінювати документи в рамках статусу процедури active_tendering.

Якщо учасник не бажає приймати участі в аукціоні після реєстрації, він не має переходити за посиланням на участь та приймати участь в торгах.

У випадку переходу аукціону у статус “Торги не відбулися” (unsuccessful) або “Торги скасовано” (cancelled), до завершення періоду аукціону (auctionPeriod), ставки учасників залишаються закритими для всіх, включаючи Організатора аукціону і доступні виключно для майданчика, який розмістив ставку у ЦБД.

Умови скасування заяви

Запит на анулювання пропозиції та внесення змін до пропозиції може надійти тільки на Майданчику, через який було зареєстровано пропозицію від відповідного Учасника.

У разі анулювання заяви учасником, майданчик надсилає запит до ЦБД щодо зміни статусу пропозиції на deleted. Анулювати можна тільки пропозицію в аукціоні, що має статус в Електронних торгах - "Прийняття заяв на участь". Після розкриття цінових пропозицій, інформація про неактивовані (draft) та анульовані (deleted) пропозиції Учасників не розкривається у публічному api. Майданчик повертає Учаснику гарантійний внесок.

Для видалення майданчик відправляє наступний запит до ЦБД: PATCH auctions/auction_id/bids/bid_id/status?acc_token=your_access_token та передати статус deleted.

Особливості відображення заяв на участь (бідів)

Bid зі статусом draft та deleted не з'являється у публічному АРІ після розкриття цінової пропозиції. Інформацію щодо bid’ів у статусі draft та deleted може побачити тільки майданчик учасника та адміністратор у логах ЦБД.

Bid зі статусом active та invalid присутні у публічному АРІ та розкриваються після завершення періоду аукціону (auctionPeriod). Bid'и у статусі active та invalid повинні відображатися на майданчику.

Важливо: При переході біда в статус deleted та invalid для учасника з переважним правом перестає відображатись поле priority

Перелік існуючих статусів заяви на участь

Технічний ідентифікаторНазва укр.
draftЧернетка заяви на участь
activeАктивована заява на участь
invalidНедійсна заява на участь
deletedВидалена заява на участь

Недопуск учасника

Під час створення процедури ЦБД додає у список disqualifiedBids ідентифікатори учасників, що були дискваліфіковані у попередніх аукціонах (значення масиву disqualifiedBids процедури вказаної в previousAuctionId + (за наявності) buyers.identifier.id авардів, що були дискваліфіковані в цій процедурі.

Список причин дискваліфікації для недопуску на наступні аукціони:

  1. Відмовився від підписання протоколу (причина 1 з словника landSellTerminationReason).
  2. Відмовився від укладення договору (причина 2 з словника landSellTerminationReason).
  3. Не сплатив належну суму за придбаний лот та/або суму витрат на підготовку лота до продажу (причина 4 з словника landSellTerminationReason).

Якщо учасника дискваліфікували через вищевказаний список причин, то в наступних аукціонах ЦБД не дозволяє активувати бід даного учасника. Для активації біда необхідно завантажити документ "Підстави для допуску дискваліфікованого учасника" (documentType:admissionReason).

В структурі повторного аукціону з'являється поле disqualifiedBids з масивом ідентифікаторів учасників, які не допускаються до активації заяви на участь.

Повідомлення при розміщення заяви на участь

Особливості роботи з учасником з переважним правом

Для визначення учасника з переважним правом в системі, Організатор повинен зазначити дані учасника з переважним, заповнивши структуру currentTenant. Під час реєстрації учасника з переважним правом, як учасника, на майданчику (обов'язково повинен зазначити ЄДРПОУ/ІПН/ID) та активації заяви на участь, система за ЄДРПОУ/ІПН/ID ідентифікує заяву на участь (тільки у статусі заяви на участь active) такого учасника та надає майданчику підтвердження, що такий учасник є учасником з переважним правом (за допомогою поля Bid.isCurrentTenant). За наявності такого підтвердження:

Організатор обов’язково має вказати дані учасника з переважним правом:

До запуску універсального модуля аукціону:

Після запуску універсального модуля аукціону:

Схема "Передача переважного права"

Дані учасників з переважним правом (currentTenants) можуть редагуватися протягом періоду передачі переважного права (transferPriorityPeriod). У разі внесення змін в хоча б в один ідентифікатор identifier.id учасника з переважним правом (currentTenants):

Учаснику який втратив ознаку учасника з переважним правом (статус bid`а змінився на inactive) приходить сповіщення про те, що він може взяти участь в аукціоні на правах учасника без переважного права, але для цього йому необхідно активувати заяву. У разі бездіяльності учасника заява на участь залишається у статусі inactive та не може брати участь в аукціоні.

У разі внесення змін в будь-які дані учасника з переважним правом (currentTenants) крім ідентифікатора (ЄДРПОУ/ІПН/ID) - заяви на участь не змінюють своїх статусів і ознака "Учасник з переважним правом" залишається у bid'а, в якого вона була.

Нотифікація по процедурі продаж землі з подвійним переважним правом

Скасування аукціону

Скасування аукціону

Скасувати аукціон можливо у будь-якому не термінальному статусі процедури.

Для скасування Організатор аукціону зобов’язаний завантажити документ (documentType:cancellationDetails) та внести опис причини скасування (cancellation.reason). Фактичну дату скасування (cancellations.date) Організатор аукціону вказує вручну.

Повідомлення при скасування аукціону

Інформація про отримання посилання на аукціон

Повідомлення щодо аукціону

Аукціон не відбувся

Аукціон

Аукціон

ТЗ з модулю аукціону

Схема "Аукціон"

Після переходу за посиланням, учасник потрапляє на сторінку проведення аукціону.

Ознайомча пауза

Послідовний раунд (англійський)

Пауза між раундами

Пріоритетний раунд (тільки для ролі учасника з переважним правом)

Розкриття

Послідовність кроків:

Переважне право

Під час періоду аукціону учасники з переважним правом мають право не робити ставки до 4-го раунду аукціону.

Для реалізації переважного права учасники з переважним правом має погодитися з:

Після завершення раунду переважного права модуль аукціону сортує bid`и з урахуванням ставок зроблених в раунді переважного права за параметрами:

  1. Розмір ставки
  2. Пріоритет учасника (0,1 або відсутній)
  3. Час ставки

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

Формування протоколу Аукціону

Шаблони електронного протоколу аукціону:

Кваліфікація

Схема "Кваліфікація (робота з договором та протоколом)"

За результатами періоду аукціону, основні умови відбору переможця Організатором аукціону - найвища ставка та відповідність учасника кваліфікаційним вимогам.

Пропозиції сортуються від більшої ціни до меншої, а, у випадку співпадіння ціни, вище відображається пропозиція розміщена раніше. Часом розміщення пропозиції вважається час першого розміщення заяви у ЦБД, а, у випадку редагування пропозиції під час періоду подання пропозицій (tenderPeriod), час фіксації змін у заяві у ЦБД.

ЦБД формує award'и тільки для двох учасників з найвищими валідними ставками (другий award за наявності такого учасника). Авард учасника з найвищою валідною ставкою отримує статус pending, а авард учасника з другою найвищою ставкою (за наявності) отримує статус pending_waiting.

Перевірка документів учасників та підписання протоколу

За умови успішного проведення аукціону, процедура переходить у період кваліфікації та розпочинається період підписання протоколу, статус процедури змінюється на active_qualification, починається робота із протоколом.

Якщо усіх учасників, що пройшли до кваліфікації, дискваліфіковано, ЦБД автоматично змінює статус процедури на unsuccessful.

Після періоду аукціону (auctionPeriod) Організатор здійснює перевірку документів (поза системою) всіх учасників аукціону та приймає рішення щодо кваліфікації учасників.

  1. Протокол аукціону (documentType:auctionProtocol) підписується переможцем аукціону та оператором електронного майданчика, з якого переможець подав цінову пропозицію, за допомогою кваліфікованого електронного підпису уповноваженої особи.
    1. Організатор опубліковує підписаний протокол аукціону в ЕТС протягом 10-ти робочих днів після дня його завершення.
    2. В Організатора є можливість підтвердити протокол і після завершення періоду підписання протоколу (verificationPeriod), обмеження на майданчику не мають встановлюватись.
    3. Після завантаження протоколу організатор натискає кнопку "Протокол затверджено", після чого майданчик передає award’у такого учасника статус active (“Переможець. Очікується договір”).
      1. В результаті чого для цього award’у створюється contract в статусі pending у масиві contracts.
  2. У учасника, який кваліфікується є можливість завантаження та заміни Протоколу до bid`a (не обов’язкова дія), але завантаження цього документу учасником не призводить до зміни статусів в системі.
  3. Для учасника з другою за розміром ціновою пропозицією (за наявності такого), одразу після аукціону, формуються award, що отримує статус pending_waiting, якщо його ставка була валідною.
    1. У випадку, якщо ставка цього учасника не є валідною, формування award'у для такого учасника не здійснюється.
    2. Єдина дія, яка може бути виконана в цей момент - це ручне скасування очікування - учасник може забрати свій гарантійний внесок, втрачаючи шанс стати переможцем аукціону. У разі відмови від очікування майданчик передає такому award'y статус cancelled.
    3. Якщо перший award дискваліфіковують, а другий не самодискваліфікувався, після набуття статусу 2-го award'у pending, 2-й учасник проходить процедуру кваліфікації по такому самому принципу як 1-й переможець (процедура знову набуває статус "Очікується оприлюднення протоколу" (active_qualification)).
    4. Якщо ж кваліфікація 1-го award'у пройшла успішно, та Організатор аукціону підтвердив виконання умов договору для 1-го award'у, у такому випадку ЦБД, під час зміни статусу процедури на complete, автоматично змінює статус 2-го award'у на cancelled.
  4. У разі невідповідності переможця аукціону вимогам, Організатор аукціону повинен дискваліфікувати учасника, після чого майданчик передає статус “unsuccessful” award`у такого учасника до ЦБД.
  5. Завершення періоду підписання протоколу (verificationPeriod) - період триває доти, доки Організатор не підтвердить протокол.

Підписання договору

Після підписання договору Організатор має завантажити договір (documentType:contractSigned), заповнити обов'язкові поля договору (крім обов'язкових при створенні, для активації необхідно заповнити поля dateSigned, title, contractNumber, description, contractTime.dateFrom, contractTime.dateTill) та підтвердити договір. Після цього майданчик переводить contract в статус signed.

В Організатора аукціону є можливість підтвердити договір (documentType:contractSigned) і після завершення періоду підписання договору (signingPeriod), обмеження на майданчику не мають встановлюватись.

До переведення договору в статус active, Організатор повинен мати можливість виправити поля договору та вкладені файли.

Підтвердження оплати

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

Значення поля lotPaymentConfirmation можна змінити скільки завгодно разів до моменту зміни статусу contract з signed на active.

Під час підтвердження оплати коштів Організатор може завантажити в систему documentType:paymentInformation. До моменту зміни статусу contract з signed documentType:paymentInformation можна замінити.

Завершення аукціону (переведення у статус complete)

Після підтвердження оплати, Організатор аукціону завершує аукціон. Після чого процедура змінює статус на complete.

Умови дискваліфікації

Дискваліфікація Організатором

У разі дискваліфікації переможця на етапі роботи із договором (signingPeriod), Організатор аукціону складає та оприлюднює в електронній торговій системі протокол відхилення (documentType:rejectionProtocol) або/та акт про відмову (documentType:act), дискваліфіковує учасника та вказує одну причину з переліку причин (причина записуються в поле terminationReason аварду):

Після чого майданчик передає статус unsuccessful award`у учасника, внаслідок чого ЦБД автоматично переводить договір у статус cancelled. Вказана причина, а також статус учасника, повинні відображатися на майданчику.

До переведення статусу award`у учасника в unsuccessful, Організатор повинен мати можливість змінити причину дисквалифікації та завантажити або замінити документ/ти.

Повідомлення щодо кваліфікації (загальні)

Повідомлення щодо кваліфікації