Open ndrhzn opened 7 months ago
Для контрактних процедур, котрі проводяться через Prozorro, ми можемо забирати дані з OCDS API, використовуючи cdu_response/contractingProcesses/summary/tender/id.
https://public-api.prozorro.gov.ua/api/2.5/tenders/{id}?opt_schema=ocds
Наприклад, https://public-api.prozorro.gov.ua/api/2.5/tenders/9ad27ae02c144c48996474732e8e0cd7?opt_schema=ocds
Це видасть нам так званий compiled OCDS release, де мають бути дані для всіх стадій контрактної процедури.
В такому разі ми можемо у цьому релізі забирати releases/tender/procuringEntity та releases/tender/procurementMethod
Що стосується інших, чи є відповідь від Павла стосовно інтеграційної шини? Чи є доступ до інтеграційної шини? Якщо вже є працююча інтеграційна шина, краще все брати з неї і не розпорошуватись по багатьох сервісах зогляду на потенційну можливість змін на тих сервісах і те, що як я зрозумів в інтеграційною шинаю нам так чи інакше доведеться працювати. Тим не менш, якщо інтеграційна шина це не готова, щоб рухатись далі, ми готові ванатжити дані з API Prozorro
Відповіді та доступу поки немає. За відсутності відповіді та доступу ми можемо поки вчинити наступним чином
Блюсь, що так не вийде, бо без даних BI не працює, а генерувати дані це в будь-якому випадку подвійна робота. Якщо зараз треба зробити цю сторінку, давайте завантажимо дані з API Prozorro, в майбутньому, сподіваюсь дані з ІШ по структурі не будуть дуже сильно відрізнятись від структури що віддає Prozorro API і великих змін не потребуватиме, особливо зважаючи не те, що для нашої поточної аналітики не потрібна повний набір даних у всіх підпорядкованих, що віддає API
Блюсь, що так не вийде, бо без даних BI не працює, а генерувати дані це в будь-якому випадку подвійна робота.
Не дуже зрозумів цю частину. Я наче не пропонував працювати без даних, або ж генерувати дані. Зараз йдеться про дві змінні, котрі нам потрібні, але котрих немає в API DREAM. Моя пропозиція полягала в тому, аби до зʼясування обставин доступу до інтеграційної шини відмалювати таблицю без цих двох змінних.
Вибачаюсь, мабуть це я запрацювався і неправильно зрозумів. Так, згоден з вашою попередньою пропозицією.
Є перший варіант таблиці (поки без додаткових даних Prozorro). https://qsdemo.rbcgrp.com/sense/app/b0f13ce0-e592-48bc-9432-6da4de1f8cfb/sheet/cd5d5131-9f22-46ce-b040-bc57443c106c/state/analysis
З того, на що одразу звертається увага @andrzejbeletsky
Варто пропрацювати кодлісти - які вже є в документації, приєднати, яких немає - задокументувати запит до проєктного офісу і команди розробки
Числа варто форматувати в такий же спосіб, як ми форматуємо їх на інших аркушах - аби була відбивка розрядів і було зручно читати
У змінній "Дата ініціації" достатньо давати YYYY-MM-DD
У змінній "Номер договору" варто вирівняти все по одній стороні
Також є набір питань до проєктного офісу та команди розробки щодо логіки даних, які я опишу окремим коментарем
Питання щодо даних, котрі стосуються контрактних процедур
У даних є тестові та помилково створені записи. Чи існує у нас якийсь механізм / алгоритм видалення цих даних. Де має відбуватися це видалення - на стороні АРІ чи на стороні ВІ?
Є записи, для котрих ми навіть не знаємо платформу проведення закупівлі (відсутнє значення для змінної "Платформа"). Чи це є валідні записи? Як це можливо бізнесово?
Є записи, в яких дата ініціації може бути на декілька років пізніше від дати підписання договору. Ймовірно йдеться про дату ініціації в системі DREAM. Чи має в таких випадках сенс змінна "Дата ініціації" взагалі? Чи не мало б для нас сенс забирати цю змінну з Prozorro? (питання щодо коректності цієї змінної у тих випадках, коли закупівлі проводяться не на Prozorro, лишається відкритим)
Є записи, у котрих дата дії завершення договору може бути у 2016 чи 2017 році, але при цьому статус договору - active (не complete). Чи це є коректний статус договору в такому випадку? Як це можливо бізнесово? Оскільки ця змінна фіксує радше заплановану дату завершення дії договору, а не фактичну, чи не є сенс нам додатково фіксувати, коли контракт був завершений фактично?
Take a look https://qsdemo.rbcgrp.com/sense/app/b0f13ce0-e592-48bc-9432-6da4de1f8cfb/sheet/cd5d5131-9f22-46ce-b040-bc57443c106c/state/analysis Корекція вигляду даних. В таблиці залишились рядки, де є "Номер договору".
TODO кодлисти PROZORRO
Код-листи для перекладу: Contract status , additionalProcurementCategories , platform , status contractingProcesses https://docs.google.com/spreadsheets/d/1efMobfMAItctWak9UmULWInX02GH5TeKXsWXFHkG5Ww/edit?pli=1#gid=1823168069
Задача цього блоку - представляти детальні дані щодо контрактних процедур у табличному вигляді для дослідження, сортування, фільтрування. Таблиця має відповідати на питання "хто купив що у кого, коли, в який спосіб, та за скільки".
Пропоную для початку включити в цю таблицю наступні стовпчики
До цієї таблиці можна додати наступні фільтри