Багатолотові закупівлі

Мета

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

Нормативна база

• Законопроект “Про публічні закупівлі”
• Наказ МЕРТ №921 “Про затвердження Порядку визначення предмета закупівлі”

Стислий огляд процесу:

Замовник оголошує процедуру, розділену на лоти. Учасник подає кваліфікаційні документи один раз на всю процедуру. Якщо окремі лоти вимагають окремих документів, учасник завантажує окремо кваліфікаційні документи на процедуру і окремо на лоти. Аукціон проводиться не по процедурі в цілому, а по кожному лоту окремо. Для зменшення ризику цінових змов, результати всіх аукціонів відкриваються одночасно після повного завершення аукціонів по всій процедурі.

Структура документів побудована таким чином:

Детальний огляд процесу:

Оголошення процедури

Замовник оголошує процедуру, визначаючи наступні елементи на рівні номенклатури (item):

• Код ДК
• Код CPV
• Опис предмету закупівлі
• Кваліфікаційні вимоги та вимоги до предмету закупівлі
• Планова сума закупівлі
• Кількість закупівлі
• Одиниці виміру
• Ключові дати процедури

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

• Опис лоту
• Очікувана вартість

Перевірки:

• перші п’ять символів коду класифікатора ДК мають співпадати з кодом ДК всієї процедури.
• перші три символи коду класифікатора CPV мають співпадати з кодом CPV всієї процедури

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

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

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

Аукціон

Тендер переходить в статус “Аукціон” в момент початку аукціону хоча б по одному лоту. Аукціон відбувається по кожному лоту окремо. Дані про учасників і подані пропозиції публікуються лише після завершення всіх аукціонів закупівлі.

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

Тендер переходить в стан “Кваліфікація” після завершення останнього аукціону тендеру.

Кваліфікація відбувається за стандартною процедурою, по кожному окремому лоту.

Вимоги до Майданчика:

• Можливість Замовника вибрати багатолотову процедуру і створити необмежену кількість лотів.
• Можливість Замовника змінювати структуру лотів, додавати нові і видаляти існуючі - до завершення періоду уточнень.
• Можливість Замовника визначити кваліфікаційні вимоги в цілому по процедурі (загальні) і по кожному лоту окремо (специфічні для лота).
• Можливість Постачальника подати документи (вкладені файли) на всю процедуру в цілому і по кожному лоту окремо, у відповідності до вимог Замовника.
• Автоматична перевірка однорідності предмету закупівлі по всіх лотах і всіх номенклатурах тендеру.
• Можливість задати запитання в цілому по процедурі або по окремих лотах.
• Адаптація до всіх змін АРІ, визначених у вимогах до ЦБД.

Вимоги до аукціону

• Переналаштування аукціонів (формування посилання на сторінку аукціона, модуль планування аукціонів) із об’єкту Тендер на об’єкт Лот.
• Модифікація планувальника аукціонів для врахування лотів.
• Зберігання результатів аукціонів у БД аукціону без публікації до завершення останнього лоту аукціону.
• Зберігання результатів аукціонів у БД аукціону у файлі audit.yml без публікації до завершення останнього лоту аукціону.
• Зміна екранних форм сторінки аукціонів.

Вимоги (зміни) до ЦБД

• Додатковий об’єкт (лот).
• API (POST), який дозволяє записати та змінити тендер в ЦБД.
• Валідація даних з урахуванням багатолотовості.
• API (GET), який повертає перелік тендерів з лотами.
• Зміна залежності номенклатури (item) з тендеру на лот.
• API (POST, PATCH), який дозволяє подати пропозицію із розіділенням елементів даних і документів (attachment) на такі, які стосуються всіх лотів процедури і такі, які стосуються окремого лоту.
• Переналаштування об’єкту Award з тендеру на лот.
• Зміна послідовності визначення переможця з тендеру на лоти.
• API (POST, PATCH) Переналаштування контрактів таким чином, щоб можна було на кожен лот завантажувати окремий договір, або один договір на декілька лотів.
• Зміна прив’язки документів (attachment) з тендеру на лот.
• API (POST, PATCH) Переробка запитань таким чином, щоб можна було запитання задавати як по тендеру в цілому, так і по індивідуальному лоту.
• Розрахункові поля (наприклад, обрахунок очікуваної вартості тендеру як сума вартостей всіх лотів).
• Модифікація точки доступу між аукціоном і ЦБД, включаючи синхронізацію даних.
• Зберігання результатів аукціонів у ЦБД без публікації до завершення останнього лоту аукціону.
• Переведення тендеру у стан “Кваліфікація” тільки після завершення аукціонів по всіх лотах.
• Переведення тендеру у стан “Завершено” тільки після завершення процедури закупівлі по всіх лотах.
• Автоматична перевірка однорідності предмету закупівлі по всіх лотах і всіх номенклатурах тендеру.
• Інтеграція з якісними показниками, які можуть відрізнятись від лоту до лоту.
• Сумісність з безлотовими процедурами (для Майданчиків, які не підтримують багатолотові закупівлі):
  • автоматична генерація лоту для безлотових тендерів (для майданчиків, які не підтримують ці процедури);
  • можливість ручного запису значень полів, які для багатолотових процедур обраховуються автоматично.