У листопаді 2021 року у модулі аналітики проВІ відбулися значні зміни. Оптимізація має забезпечити більш стабільну роботу проВІ. Саме для того щоб Вам було більш зручно працювати із модулем, наша команда впровадила наступні зміни у проВІ: 

• Тендери і лоти об'єднано в одну таблицю у моделі даних.
• Із проВІ видалено російкомовні довідники (фокус на англо- та україномовних довідниках).
• Видалено неактуальні та застарілі листи з проВІ.

Об'єднання таблиці лоти та тендери

Тепер Лот виходить на перше місце. Це досить логічно, адже саме лот є центральним об'єктом закупівель: на його рівні подають пропозиції, відбуваються торги, підписують угоди. На практиці ці зміни не сильно вплинуть на вашу роботу, але деякі речі (про які ми напишемо трохи згодом) потрібно буде враховувати під час обчислень. 

Для кращого розуміння, що саме змінилося у модулі аналітики, необхідно розібратись із тим, як будується модель даних — основа роботи проВІ. 

Кожен день ми вивантажуємо дані про публічні закупівлі із системи Prozorro, та зберігаємо їх у нашому сховищі даних. Завантажені дані ми систематизуємо у таблиці. Створені таблиці ми зв’язуємо між собою за допомогою ключових полів, тобто таких, що є однаковими для декількох таблиць. Сукупність таблиць та зв'язків між ними і є моделлю даних. 

Раніше дані про тендери і лоти зберігалися в окремих таблицях. У спрощеному вигляді ці таблиці можна представити так: 

Таблиця з тендерами:

Таблиця з лотами: 

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

Так стовпчик Ідентифікатор Тендеру стане ключовим, а між таблицями з'явиться зв’язок, завдяки якому ми можемо подивитися всю інформацію про тендер чи лот, не зазираючи у кожну таблицю окремо.  

Зв’язавши таблиці, ми утворили простеньку модель даних. При цьому, кожна з таблиць: і тендери, і лоти — існує окремо одна від одної. 

Якщо ми хотіли порахувати суму тендеру за такої моделі даних, то могли скористатися формулою Sum(СуммаТендера) як в розрізі самого тендеру, так і в розрізі лотів. Фактично, коли ми запитували Sum(СуммаТендера) на рівні лота, система зверталася до таблиці з даними про сам тендер і брала ці дані звідти. 

Розглянемо таку ситуацію на прикладі дволотового тендеру UA-2020-05-18-005606-c.

На прикладі гарно видно, що як в розрізі лота, так і в розрізі тендеру, сума тендеру відображається коректно і дорівнює 10 000 грн. Зверніть увагу на записи про суму тендеру в розрізі кожного лота і на підсумок:

Сума тендеру для кожного з цих лотів — 10 000 грн, і це правильно. Але якщо просто підсумувати записи в стовпчику Sum(СуммаТендера), вийде 20 000, що звісно буде некоректно відображати дійсність, хоча й теж працюватиме цілком логічно. Так само логічно, як це спрацювало в стовпчику Sum(СуммаЛота): сума очікуваної вартості першого лота (1000) + сума очікуваної вартості другого лота (9000) = сума очікуваних вартостей лотів (10 000). Коректний підсумковий результат у стовпчику Sum(СуммаТендера) досягався саме завдяки тому, що дані про тендери та лоти зберігалися у різних таблицях. Якщо пояснити спрощено, то алгоритм працював так: 

1. до модуля надходить запит про суму тендеру для конкретного лота
2. система бере дані про ідентифікатор тендеру цього лота з таблиці лотів
3. система знаходить цей тендер в таблиці з тендерами та вертає для нього значення очікуваної вартості

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

Тепер повернемося до наших таблиць із прикладу. У результаті оптимізації ми об'єднали їх в одну мега-таблицю. При цьому, головним став лот, тобто кожен рядок тепер  містить запис про один конкретний лот. 

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

Давайте уважно подивимося на створену таблицю. Кожен рядок дорівнює лоту. Лоти 11111111-а та 11111111-в належать до одного і того самого тендеру: 11111111. Сума очікуваної вартості тендеру — 500 000. Якщо ми поставимо питання, яка сума очікуваної вартості тендеру для лота 11111111-а, відповідь буде 500 000. Те саме — для лота 11111111-в. Якщо в таблиці, що має такий вигляд, порахувати суму очікуваної вартості тендерів, просто додаючи дані з кожної комірки стовпчика “Очікувана вартість тендера”, чи буде ця сума відображати дійсність? Звісно, ні. 

Подивимося на прикладі нашого тендеру 11111111: 

500 000 + 500 000 = 1 000 000

Щоб правильно вирішити поставлене завдання, потрібно підсумувати очікувану вартість лотів досліджуваного тендеру: 

300 000 + 200 000 = 500 000

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

У проВІ відбулося те саме, що і в нашому прикладі. Давайте подивимось на той самий тендер UA-2020-05-18-005606-c в модулі після оптимізації.

Оскільки таблиці з тендерами більше не існує, а є лише запис про очікувану вартість тендеру для кожного лота, модуль логічно складає значення кожної комірки для колонки Sum(СуммаТендера).  

При цьому показник “Сума тендера” працює коректно, і якщо його використати без функції агрегування Sum, у якості Виміру, він покаже достовірні дані. 

Але якщо йдеться не про один тендер, найпростішим варіантом дізнатися загальну суму тендерів буде все ж порахувати загальну суму всіх лотів.

Тепер усі дані про тендер ми запишемо на рівні лота, там само, як ви побачили це на прикладі вище. Кожен рядок нової таблиці буде містити інформацію про конкретний лот та його ознаки: суму очікуваної вартості лота, організатора та учасників, пропозиції учасників, опис тендера, до якого цей лот належить, очікувану вартість цього тендера і так далі.  Ось так зараз у проВІ буде виглядати багатолотовий тендер:

Загальна сума тендеру складає 148 433 746 грн, а кількість лотів - 4. Якщо рахувати суму тендеру для кожного лота окремо, то дані будуть відображатися коректно. Якщо просто обрати показник “Сума тендера” на рівні окремо взятого тендеру чи лота, то цей показник також покаже коректну суму. Але якщо спробувати порахувати суму за допомогою функції агрегування Sum ([Сума тендера]), то система очікувано  просумує всі записи про суму тендеру. А їх 4, по одній для кожного з лотів. Тож замість 148 433 746 грн ми отримаємо суму, в 4 разів більшу. 

Так само Sum ([Сума тендера]) спрацює у розрізі ідентифікатора тендеру, адже у багатолотових закупівлях на кожен тендер буде стільки записів про суму тендеру, скільки лотів є в цьому тендері. Приклад нижче ілюструє цю проблему: 

Оскільки у відборі обрано лише ті тендери, в яких кількість лотів 10, то Sum ([Сума тендера]) для кожного тендеру рівно в 10 разів більша за реальну. У цьому прикладі насправді обрано не тендери, а всі лоти, що належать до десятилотових тендерів. Звучить трохи складно, але ідея насправді досить проста: після злиття таблиць і фокусуванні на лотах, під час відбору тендеру ви завжди обираєте лоти. Якщо натиснути на конкретний ідентифікатор тендеру, буде обрано усі лоти, що до нього належать. 

Так само як очікувана вартість тендеру, себе будуть поводити й інші поля, що стосуються саме тендерів. До них належать:

• Сума тендера
• Кількість лотів у тендері
• СуммаТендера_Валюта
• ШагУменьшения
• ШагУменьшения_Валюта
• СуммаГарантииПредложения
• СуммаГарантииПредложения_Валюта
• TenderAmountEUR
• MinStepEUR
• GuaranteeEUR
• Период приема предложений д. (показник Період прийому пропозицій, д)
• Период от аукциона до завершения (показник Період від аукціону до завершення)
• Годин на подання пропозицій
• Кількість звернень до органу моніторингу
• К-сть змін одного файла ТД (максимальна)

Наприклад, показник “Кількість лотів у тендері” буде коректно відображати дані, якщо використовувати його як Вимір (Dimensions). Але не варто використовувати його у функціях агрегування. Функція Sum([Кількість лотів у тендері]) просумує кількість учасників лота стільки разів, скільки лотів є в тендері. Тобто для 10 лотової закупівлі вона  формула порахує 100, що звісно ж буде помилкою.

Надійним способом порахувати кількість лотів є Count (ИдентификаторЛота). Ця функція визначить кількість записів про лоти. 

Деякі показники, що розраховувалися раніше на рівні тендеру, було видалено. До них вналежать: 

• Экономия
• SavingsEUR
• Avg%TenderEconomy (Середній %економії по тендеру серед лотів)
• HTenderEconomyFlag (Avg%TenderEconomy>=0,6)
• % економії (на рівні тендера)
• КоличествоУчастников (в тендері)
• TenderersQty (показник Середня кількість учасників)
• КоличествоНовыхУчастников (в тендері)
• Длительность тендера (показник Середня тривалість тендерів)
• IDStatusGrTender
• СтатусГр
• StatusGr
• СтатусКл
• StatusCl
• IDStatusClTender

Фокус на англо- та україномовних довідниках

Підтримка проВІ вимагає постійного оновлення та актуалізації показників та довідників. Якщо в модулі є три мовні версії, то це фактично три модулі різними мовами. Дублювання показників декількома мовами ускладнює пошук необхідного для роботи показника, а також вимагає ресурсів нашої команди для постійної підтримки та актуалізації кожного з довідників. Тому в межах оптимизації проВІ ми сфокусувалися на пітримці найактуальніших довідників. Після оновлення, у проВІ залишилися виключно англо- та україномовні довідники.  

На практиці це означає, що якщо ви використовували в своїх об'єктах (таблицях/графіках тощо) російськомовні довідники, на кшталт “Год”, після оновлення вони перестануть відображати актуальну інформацію. Тому варто замінити “Год” на “Рік”. 

Тож радимо перевірити, чи не використовуються зараз у ваших об'єктах російськомовні версії довідників. Повний перелік російськомовних довідників є за посиланням. 

Видалення застарілих листів з проВІ

Після оптимізації з проВІ також зникнуть застарілі листи:

• Показники
• Довільне
• Проблеми
• СРМ

Із різних причин об'єкти на вказаних листах втратили свою актуальність, а правильність розрахунку більшості з них викликає в нас сумнів. Наразі ми не маємо ресурсів для актуалізації вказаних об’єктів. Ба більше, велика кількість з них дуже рідко дійсно ставала в пригоді користувачам. А втім, підтримка та актуалізація інформації на цих листах вимагала часу та інших ресурсів, тому ми вирішили їх видалити. Найголовніше те, що всі необхідні об’єкти наші користувачі мають можливість створити самостійно — саме в цьому полягає перевага професійного модуля. У разі, якщо щось не вдається, на допомогу завжди прийдуть учасники групи Професійний модуль аналітики Прозорро та команда Аналітичних інструментів Prozorro. 

Важливо наголосити, що нововведення вплинуть на всі об'єкти, що використовують показники по тендерах, а також російськомовні довідники. Саме тому, якщо ви ще не провели інвентаризацію свої об'єктів, варто це зробити перед початком роботи у проВІ. Не зволікайте!