RISK-1-15. Відсутність оприлюдненого договору про закупівлю за результатами процедури закупівлі.

Суть індикатора

Даний індикатор виявляє ситуації, коли в секції документів договору присутній електронний підпис, але документи скан копії підписаного контракту відсутні.

Законодавче обґрунтування індикатора

Відповідно до наказу МЕРТ №490 від 22.03.2016, електронний цифровий підпис накладається після внесення інформації, передбаченої формою документа.

Підстава для розробки індикатора

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

Методологія розрахунку індикатора

Етап існування процедури

Індикатор розраховується, коли процедура знаходиться на етапі тендерингу.

Рівень розрахунку

Індикатор розраховується на рівні лота.

Джерела даних для розрахунку

Для розрахунку індикатора вікористовуються наступні джерела даних:

  • API модуля тендеринга електронної системи закупівель

Типи процедур

Індикатор розраховується для наступних типів процедур:

  • aboveThresholdUA - відкриті торги
  • aboveThresholdEU - відкриті торги з публікацією англійською мовою
  • negotiation - переговорна процедура
  • negotiation quick - Переговорна прискорена

Типи замовників

Індикатор розраховується для замовників які в системі визначені як:
  • authority - Орган державної влади, місцевого самоврядування або правоохоронний орган
  • central - Юридична особа, що здійснює закупівлі в інтересах замовників (ЦЗО)
  • general - Юридична особа, яка забезпечує потреби держави або територіальної громади
  • social - Орган соціального страхування
  • special - Юридична особа, яка здійснює діяльність в одній або декількох окремих сферах господарювання

Стадії процедур

Подія, що вмикає розрахунок індикатора

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

Подія, що вимикає розрахунок індикатора

Розрахунок індикатора вимикається, коли інтервал часу між останньою переходом процедури у статус complete та поточною датою становить рік або більше.

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

Виходячи з подій, що вмикають та вимикають розрахунок індикатора, маємо наступні умови розрахунку:

  • Індикатор розраховується на наступні статуси процедур:
    • complete

Частота розрахунку

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

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

Поля для розрахунку

Для розрахунку індикатора використовуються наступні поля з API модуля тендеринга:

  • data.contracts
  • data.contracts.documents
  • data.contracts.documents.format
  • data.contracts.awardID
  • data.awards.lotID

Формула розрахунку

  1. Якщо json-документі, що відповідає процедурі немає блоку data.contracts зі статусом data.contracts.status = 'active', індикатор приймає значення -2. Розрахунок завершується.
  2. Якщо Якщо json-документі, що відповідає процедурі присутній блок data.contracts зі статусом data.contracts.status = 'active', але в ньому немає блоку data.contracts.documents, робимо наступне.

2.1.Знаходимо ідентификатор блоку data.contracts.id. За ним знаходимо об’єкт в модулі контрактингу.

2.2. Знаходимо там усі документи data.documents такі, що data.documents.documentOf = 'contract'. Якщо таких документів немає, то індикатор приймає значення -2. Розрахунок завершується. Якщо документи є, переходимо на наступний крок.

2.3. Якщо серед них є тільки data.contracts.documents.format = 'application/pkcs7-signature', індикатор приймає значення 1.

2.4. Якщо серед них є data.contracts.documents.format != 'application/pkcs7-signature', індикатор приймає значення 0.

  1. Якщо в блоці data.contracts.documents нема жодного документу, у якого data.contracts.documents.format не дорівнює application/pkcs7-signature, то робимо наступне.

3.1. Знаходимо ідентификатор блоку data.contracts.id. За ним знаходимо об’єкт в модулі контрактингу.

3.2. Знаходимо там усі документи data.documents такі, що data.documents.documentOf = 'contract'. Якщо таких документів немає, то індикатор приймає значення 1. Розрахунок завершується. Якщо документи є, переходимо на наступний крок.

3.3. Якщо серед них є тільки data.contracts.documents.format = 'application/pkcs7-signature', індикатор приймає значення 1.

3.4. Якщо серед них є data.contracts.documents.format != 'application/pkcs7-signature', індикатор приймає значення 0.

  1. Якщо в блоці data.contracts.documents є хоча б один документ, у якого data.contracts.documents.format не дорівнює application/pkcs7-signature, індикатор приймає значення 0.

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

  1. Визначити об’єкт data.awards, прив’язаний до договору, що перевіряється, через поле data.contracts.awardID.
  2. З визначеного об’єкту data.awards визначити через поле data.awards.lotID відповідний лот.
  3. Якщо у декількох лотах є один переможець (співпадають data.awards.suppliers.identifier.id в об’єктах, що посилаються на лоти data.awards.lotID), то в цих лотах достатньо завантажити договір у будь який один лот.

Фактори, що впливають на неточність розрахунку

  1. Індикатор може бути порахований неточно у випадках, коли замовники в окремих сферах господарювання і організації, що не є замовниками, помилково визначають себе в системі як загальні замовники.
  2. Індикатор може бути порахований неточно у випадках, коли замовником неправильно визначено тип процедури.
  3. Розподілення на роботи та послуги в CPV 45. На разі закупівлі з CPV 45 вважаються як “роботи” за виключенням коли в назві закупівлі присутні такі буквосполучання як “поточ” та “послуг” - такі закупівлі відносяться до послуг та застосовуються відповідні пороги та інші норми закону.
  4. Об’єкт контрактинг в модулі тендеренгу створюється в системі відразу коли виконується дія “намір укласти договір” з цього часу, замовник може робити будь які дії добавляти документи, накладати ЕЦП. Фактично підписання договору відбувається поза системою, з зобов’язанням замовника опублікувати договір на протязі двох днів. В системі замовник має заповнити мета дані по договору та накласти ЕЦП про достовірність цих даних та опублікувати договір. Після того як вказані умови виконані, майданчик за дорученням замовника переводить процедуру зі статусу active в статус complete після цього зміни в модулі тендеринг неможливі. Таким чином, були виявлені ситуації коли зміна статусу в процедурі відбулася без фактичної публікації документу договору в об’єкт контрактинг а потім замовник опублікував договір в модуль контрактингу в об’єкт “зміни до договору”.

В такому випадку індикатор буде спрацьовувати, але фактичного порушення виникати не буде.

4.3.8. Укладення договору (угоди)

Не раніше ніж через два робочі дні після визнання Переможця, Замовник повинен опублікувати і перевести в активний стан укладений договір, зазначивши такі обов’язкові поля (мета-інформацію):

  • Contracts:contractNumber
  • Contracts:value:amount
  • awards:value:amount
  • Contracts:dateSigned
  • Contracts:period:startDate
  • Contracts:period:endDate

До переведення контракту в статус active Замовник повинен мати можливість виправити мета-інформацію і вкладені файли (виклик PUT /contracts/{cid}/documents/{did} ).

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

Після цього Замовник накладає ЕЦП (в такому випадку автоматично змінюється статус на active) або змінює статус Зміни на active без накладання ЕЦП (тільки для belowThreshold).

Не раніше завершення періоду оскаржень і за відсутності нерозглянутих звернень (complaints зі статусом pending) Замовник переводить договір в статус «підписаний» (active), після чого окремою дією Замовник повинен перевести Тендер в статус complete.

На цьому процес завершується і ніякі додаткові зміни в документі не відбуваються.