Про систему
Замовникам
Постачальникам
Майданчикам
Регламенти
Регламент
Регламент аукціонів Rialto
Контакти
Процедури
Конкурентний вибір
Запит цінових пропозицій
Аукціон на підвищення
Блог

Конкурентний вибір

Мета

Дозволити замовнику вибирати кілька переможців одного тендеру, розділяючи предмет закупівлі між учасниками вже після розкриття. Це дозволить:

  • закупити різні номенклатури у різних постачальників за оптимальними цінами (якщо постачальники погодяться зберегти ціну при скороченні обсягу замовлення)
  • закупити необхідний обсяг частинами, якщо не буде учасника, який буде готовий виконати все замовлення повністю

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

Короткий опис

Загальні параметри тендера

  1. procurementMethodType = belowThresholdSelect 
  2. Додається поле priceDisclosure, "Правила розкриття", яке може мати значення:
    None - "не розкривати",
    Minimal - "розкривати мінімальну ціну" (На даному етапі реалізації, використовується тільки опція Minimal). Застосування цього параметра див нижче, в розділі "Подача пропозицій"
  3. Поле "Крок аукціону" на рівні майданчиків повинно бути приховано. За замовчуванням, в ЦБД передаватиметься цифра 1. Але так як аукціон проводитися не буде, ця цифра не має значанія, вона необхідна як "заглушка", для зменшення кількості рефакторінга.
  4. Додається поле completeOnly, "Пропозиція подається в повному обсязі", зі значеннями true і false. Правила застосування цього атрибута див. Нижче, в розділі "Подача пропозицій" 

}

    ]

    "priceDisclosure": "Minimal",

    "completeOnly": true

  }

Нецінові критерії 


Застосування нецінових критеріїв (features) в кожній окремій позиції може переускладнити систему і з точки зору логіки, і з точки зору інтерфейсу користувача, що ускладнить розробку і збільшить строки введення процедури в експлуатацію. На першому етапі використання нецінових критеріїв для цього типу процедури буде заборонено. Якщо буде запит від замовників, зробимо пізніше.
Таким чином, при спробі з боку майданчика додати в тендер вузол features, ЦБД повертатиме помилку

Мультилоти 


У даній процедурі лоти втрачають сенс, тому для нього ЦБД не прийматиме інформацію про лоти. Таким чином, при спробі з боку майданчика додати в тендер вузол lots, ЦБД повертатиме помилку 


Період уточнень


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


Подача пропозицій 


Учасник повинен буде подавати свою пропозицію, вказуючи пропоновану кількість і ціну по кожній номенклатурі (item) тендера.
Якщо при оголошенні тендеру зазначено "Пропозиція подається в повному обсязі" = "так", постачальник не може змінювати кількість або залишати який-небудь рядок без цінової пропозиції. Якщо "Пропозиція подається в повному обсязі" = "ні", постачальник може зменшувати кількість і / або залишати позиції без цінової пропозиції (хоча б один рядок з ціновою пропозицією повинен бути)
В ЦБД потраплятимуть дані як в цілому по сумі всієї пропозиції, так і кількість і сума пропозиції за кожною номенклатурою. Ціна за одиницю в ЦБД не зберігається
Для зручності користувачів на майданчиках рекомендується додатково ввести поле "ціна за одиницю" і налаштувати тріангуляцію (досить ввести будь-які два з трьох полів - кількість, ціна за одиницю і сума - щоб трете поле оновилося автоматично).

У пропозиції постачальника (Bid), по аналогії з вузлом lotValues, додатково з'являється окремий масив itemValues, в який майданчик записує інформацію щодо кількості і ціни кожної номенклатури
"ItemValues": [{ "relatedItem": "ce841e08420044118d07a350a17b1d95", "date": "2017-05-15T13: 32: 03.797471 + 03: 00", "quantity": 416795, "value": { "currency": " UAH "," amount ": 25000," valueAddedTaxIncluded ": true}}],

При обробці запиту від майданчика, ЦБД розраховує суму всіх номенклатур і записує її в вузол value:
"Value": { "currency": "UAH", "amount": 7952448.6, "valueAddedTaxIncluded": true},

Bid:
            {
                    },
                    "ItemValues": [{
                        "RelatedItem": "ece70999616a496388ce775540eb5fdc",
                        "Date": "2020-08-04T17: 17: 48.184527",
                        "Quantity": 1,
                        "Value": {
                            "Currency": "UAH",
                            "Amount": 1,
                            "ValueAddedTaxIncluded": true
                        }

Крім того, якщо в тендері визначений параметр "Правила розкриття" = "не розкривати", учасники не бачать інформацію про конкуруючі пропозиції. Якщо це параметр має значення "Розкривати мінімальну ціну", учасник для кожної позиції бачить мінімальну ціну за одиницю, але не бачить загальної кількості поданих пропозицій і назв учасників-конкурентів. Якщо це параметр має значення "Розкривати всі ціни", учасник для кожної позиції бачить ціну за одиницю всіх конкуруючих пропозицій. Застосування такого параметра дозволить учасникам торгуватися протягом періоду подачі пропозицій

Аукціон


Аукціон в реальному часі не передбачений в MVP. Учасники повинні ставити фінальні ціни в ході періоду подачі пропозицій. 


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

По завершенню статусу active.tendering, процедура переходить відразу в статус active.qualification. Коли замовник визначає першого переможця, майданчик (НЕ ЦБД, як в інших процедурах) формує award: приклад тендеру 

Замовник проводить переговори з постачальником, в ході яких він може додати або видалити позиції, а також змінити кількість, яка закуповується, та ціну постачальника. Інформація за пропозицією кожного учасника виводиться замовнику у вигляді таблиці, в якій він може редагувати значення itemValues (а саме - кількість і ціну за одиницю), майданчик контролює при цьому, що відредагований варіант не перевищує реальні значення цих полів в itemValues bid-а. Як тільки замовник сформує в таблиці фінальний варіант, він може натиснути на кнопку "оголосити переможцем" навпроти відповідного учасника і після цього, майданчик відправляє в ЦБД award по цьому учаснику. Черговість від найменшої ціни до найбільшої дотримуватися не повинна, формувати award-и можна в будь-якій послідовності. 

В структурі award перевіряються наступні валідації: 

  • збіг даних учасника у award з його bid (тобто, відрізняться в меншу сторону можуть тільки значення полів awards: itemValues: quantity і awards: itemValues: value: amount) 
  • загальна сума полів awards: itemValues: quantity не перевищує загальну суму items: quantity тендера 
  • поле awards: value: amount повинне дорівнювати сумі полів awards: itemValues: value: amount award-а 


Скасування рішення (зміна статусу award на cancelled) повинна бути заборонена на майданчиках для цієї процедури - потрібно попередити користувача, що рішення щодо переможців є фінальним. Після цього, майданчик переводить всі award-и в статус active - процедура переходить в active.awarded статус.

Логіка контрактингу збережена, схожа на контракти в мультилотових тендерах: контракт формується по кожному active award окремо. За активації останнього contract, тендер переходить в статус complete.