-
Відкриті торги з особливостями
-
Однолотова
-
КЕП
ДК 021:2015 72260000-5 Послуги, пов’язані з програмним забезпеченням (послуги з доопрацювання прикладного програмного забезпечення Єдиної інформаційної системи соціальної сфери)
Період подачі пропозицій
до закінчення періоду залишилося 2 дні (до 17.11.25 11:00)
10 960 000.00
UAH з ПДВ
До закінчення прийому пропозицій
02
дн
09
год
32
хв
06
сек
Оплата за участь: 4 080.00 UAH
Період уточнення:
07.11.2025 16:21 - 14.11.2025 00:00
Відповідь надана
Технічні вимоги
Номер:
5e69454ed9a149f39a6740ad3e897473
Дата опублікування:
13.11.2025 23:52
Опис:
По МОЗ — які саме зміни в існуючому API потрібно внести (специфікація є?)
Для Дії — це інтеграція через existing Diia.ID/Diia API чи новий ендпоінт для подачі заяв
Чи існує поточна модель RBAC? Який формат — roles/permissions чи ієрархічні ACL
Чи є технічні вимоги до логіки «взяття на облік»?
Механізм подання звернень через ЦНАП — це новий API чи вбудовування у поточний модуль
Універсальне API — чи є архітектурна схема? Має бути REST чи event-based
Обробка "скасування смерті":
чи є процесинг ЕОС вже реалізований?
чи потрібно розробити повну бізнес-логіку перерахунку допомог
Чи є алгоритм визначення права на базову допомогу?
Чи потрібно оновити існуючі ендпоінти, чи створити новий модуль?
Чи є схема БД для розширення переліку учасників експерименту
Чи є діючі специфікації API/протоколи обміну для всіх перелічених реєстрів (МОЗ, ПФУ, Укрзалізниця, Дія, Реєстр судових рішень, тощо)
Відповідь:
«Доброго дня, шановний Учаснику, дякуємо за виявлений інтерес до даної закупівлі та надаємо відповіді на поставлені Вами запитання.
1.По МОЗ — які саме зміни в існуючому API потрібно внести (специфікація є?)
Актуалізувати налаштування API ЄІССС відповідно до оновлених полів та довідників, що впроваджені на стороні МОЗ: 1) синхронізувати назви, формати та обов’язковість полів; 2) оновити відображення довідникових значень; 3) забезпечити технічну коректність прийому даних у межах чинної моделі. Внести точкові модифікації у бізнес-логіку на стороні ЄІССС, зокрема: 1) адаптувати правила прийому, валідації та обробки рішень Центру оцінювання ЕКОПФО; 2) налаштувати відповідність статусів і процесів до оновлених вимог, без зміни процесної схеми; 3) уточнити алгоритми маршрутизації в частині обробки нових/оновлених атрибутів рішення. Доналаштувати механізм інтеграції з МОЗ, а саме: 1) забезпечити коректне зчитування оновлених даних; 2) адаптувати обробку помилок та валідаційних відповідей відповідно до актуальних форматів; 3) виконати технічне узгодження з МОЗ у частині тестових обмінів.
2. Для Дії — це інтеграція через existing Diia.ID/Diia API чи новий ендпоінт для подачі заяв
Відповідно до абзацу 1 пп.6.1. Технічних вимог, що містяться в Додатку 3 проєкту Договору про закупівлю послуг – доопрацювання (налаштування) повинні виконуватися на основі нормативно-правових актів, технічних вимог Замовника та з урахуванням результатів аналізу роботи існуючих підсистем і сервісів Виконавцем. Отже, Виконавець повинен запропонувати та погодити з Замовником відповідне технічне рішення.
3. Чи існує поточна модель RBAC? Який формат — roles/permissions чи ієрархічні ACL
В ЄІССС створена власна система розподілу доступу на основі рольової моделі на рівні бази даних та на прикладному рівні; використовується технологія Row Level Security (частина технології Oracle Virtual Private Database (VPD)).
4. Чи є технічні вимоги до логіки «взяття на облік»?
Відповідно до абзацу 1 пп.6.1. Технічних вимог, що містяться в Додатку 3 проєкту Договору про закупівлю послуг – доопрацювання (налаштування) повинні виконуватися на основі нормативно-правових актів, технічних вимог Замовника та з урахуванням результатів аналізу роботи існуючих підсистем і сервісів Виконавцем. Відповідні технічні вимоги викладені у додатку 7 тендерної документації.
5. Механізм подання звернень через ЦНАП — це новий API чи вбудовування у поточний модуль.
Дивись відповідь на п.2
6. Універсальне API — чи є архітектурна схема? Має бути REST чи event-based
Дивись відповідь на п.2
7. Обробка "скасування смерті":
чи є процесинг ЕОС вже реалізований?
чи потрібно розробити повну бізнес-логіку перерахунку допомог
Наразі окремий процесинг ЕОС для кейсу «Скасування акту про смерть» не реалізований, але всі необхідні базові компоненти (перевірки за ДПС/МВС, зміна статусу актового запису, робота зі СРКО, опрацювання спеціалістом) вже існують у поточній архітектурі ЄІССС. Відповідно, для підтримки цього кейсу потрібно не створювати новий процес, а доналаштувати наявний функціонал обробки актових записів і механізми взаємодії зі спеціалістом ПФУ. Нова бізнес-логіка не потрібна. Для реалізації перерахунку при “скасуванні смерті” необхідне доопрацювання вже існуючого функціоналу призупинення/поновлення виплат, а саме: додати відбір рішень, призупинених з причиною «Надійшов АЗ про смерть із ДРАЦС»; надати спеціалісту ПФУ інструмент для поновлення цих виплат після анулювання акту смерть; оновити статуси рішень та провести стандартний перерахунок згідно чинної логіки ЄІССС.
8. Чи є алгоритм визначення права на базову допомогу?
Чи потрібно оновити існуючі ендпоінти, чи створити новий модуль?
Чи є схема БД для розширення переліку учасників експерименту
Так, алгоритм визначення права на БСД є. Щодо оновлення – відповідно до абзацу 1 пп.6.1. Технічних вимог, що містяться в Додатку 3 проєкту Договору про закупівлю послуг – доопрацювання (налаштування) повинні виконуватися на основі нормативно-правових актів, технічних вимог Замовника та з урахуванням результатів аналізу роботи існуючих підсистем і сервісів Виконавцем. Отже, Виконавець повинен запропонувати та погодити з Замовником відповідне технічне рішення. Так, схема БД є.
9. Чи є діючі специфікації API/протоколи обміну для всіх перелічених реєстрів (МОЗ, ПФУ, Укрзалізниця, Дія, Реєстр судових рішень, тощо)
Так, є діючі специфікації API/протоколи обміну.»
Дата відповіді:
14.11.2025 16:03
Відповідь надана
система
Номер:
dc73742082f440e98713e4a212ddb1d1
Дата опублікування:
12.11.2025 19:47
Опис:
Чи є актуальна документація API для всіх реєстрів?
Чи надані тестові доступи до всіх зовнішніх систем?
Протокол інформаційної взаємодії з АТ «Укрзалізниця» - чи він вже узгоджений? Де документація?
Протоколи з ПФУ - чи узгоджені? Які саме дані передаються?
"Розроблене API" для МОЗ (4.1.1.3) - чи воно вже існує? Де специфікація?
Інтеграція з Порталом "Дія" - чи є готовий API від Дії? Чи вже налаштована інтеграція?
Рольова гілка ФСЗОІ - вона взагалі є в системі? Чи створюється з нуля?
Функціонал для ЦНАП - ЦНАП вже працюють в системі? Що саме доопрацьовується?
Функціонал "взяття на облік" - він існує для інших випадків? Чи це нова функція?
Зведені звіти по виплатах - чи є базовий механізм звітності? Чи робимо з нуля?
Механізм подання звернень через ЦНАП - ЦНАП взагалі можуть приймати звернення зараз?
Функціонал Базової соціальної допомоги - він вже частково реалізований згідно постанови № 371? Що саме доповнюється?
Чи всі зовнішні системи надають тестові (sandbox) середовища?
Чи є тестові дані для перевірки інтеграцій?
Хто відповідальний за координацію отримання доступів (з боку замовника)?
Відповідь:
Доброго дня, шановний Учаснику, дякуємо за виявлений інтерес до даної закупівлі та надаємо відповіді на поставлені Вами запитання.
1. Чи є актуальна документація API для всіх реєстрів?
Наявні договори про інформаційну взаємодію, в яких містяться специфікації. Додатково звертаємо увагу, що WSDL чинних інформаційних взаємодій міститься на веб-ресурсі Трембіти catalog.trembita.gov.ua
2. Чи надані тестові доступи до всіх зовнішніх систем?
Надання доступу до промислового і тестового середовищ регламентується підписаними договорами про інформаційну взаємодію. Перелік сервісів, які містять тестові середовища, розміщено на веб-ресурсі Трембіти catalog.trembita.gov.ua
3. Протокол інформаційної взаємодії з АТ «Укрзалізниця» - чи він вже узгоджений? Де документація?
Відповідно до першого абзацу пп.6.1. Технічних вимог, що містяться в Додатку 3 проєкту Договору про закупівлю послуг – доопрацювання (налаштування) повинні виконуватися на основі нормативно-правових актів, технічних вимог Замовника та, з урахуванням результатів аналізу роботи існуючих підсистем і сервісів Виконавцем.
4. Протоколи з ПФУ - чи узгоджені? Які саме дані передаються?
Відповідно до першого абзацу пп.6.1. Технічних вимог, що містяться в Додатку 3 проєкту Договору про закупівлю послуг – доопрацювання (налаштування) повинні виконуватися на основі нормативно-правових актів, технічних вимог Замовника та, з урахуванням результатів аналізу роботи існуючих підсистем і сервісів виконавцем.
5. "Розроблене API" для МОЗ (4.1.1.3) - чи воно вже існує? Де специфікація?
Так, існує. Відповідно до першого абзацу пп.6.1. Технічних вимог, що містяться в Додатку 3 проєкту Договору про закупівлю послуг – доопрацювання (налаштування) повинні виконуватися на основі нормативно-правових актів, технічних вимог Замовника та з урахуванням результатів аналізу роботи існуючих підсистем і сервісів виконавцем. Перелік сервісів розміщено на веб-ресурсі Трембіти catalog.trembita.gov.ua.
6. Інтеграція з Порталом «Дія» - чи є готовий API від Дії? Чи вже налаштована інтеграція?
Так, інтеграція з Дія налаштована, що визначено постановою КМУ №371, проте слід доналаштувати існуючу інформаційну взаємодію на предмет синхрон/асинхрон сервісу відповідно до умов 2-го етапу БСД, що передбачає отримання складу сім’ї від людини, в той час, як у 1 етапі інформація про членів сім’ї бралась з ЄІССС, якщо заявник та його сім’я є отримувачами визначених постановою КМУ №371 державних соціальних допомог. А також інші необхідні, що будуть визначені виконавцем в ході аналізу, доналаштування існуючої взаємодії з Дія.
7. Рольова гілка ФСЗОІ - вона взагалі є в системі? Чи створюється з нуля?
Так, ФСЗОІ має роль в ЄІССС. Відповідно до постанови КМУ від 27.01.2021 № 99 «Про затвердження Порядку формування, ведення та доступу до Реєстру надавачів та отримувачів соціальних послуг» ФСЗОІ є користувачем Реєстру надавачів та отримувачів соціальних послуг (Реєстр) та має право доступу до нього як складової ЄІССС.
8. Функціонал для ЦНАП - ЦНАП вже працюють в системі? Що саме доопрацьовується?
Наразі для ЦНАП недоступний функціонал подачі звернень на отримання соціальних послуг (звертаємо увагу на те, що є різниця між соціальними послугами та соціальними допомогами – для соціальних допомог у ЦНАП є доступ). Відтак потрібно доналаштувати механізм подання звернень на отримання соціальних послуг особами через ЦНАП, а також ЦНАП відображення для ЦНАП статусів заяв / звернень як у фронт-офісів.
9. Функціонал «взяття на облік» - він існує для інших випадків? Чи це нова функція?
Так, існує для інших випадків.
10. Зведені звіти по виплатах - чи є базовий механізм звітності? Чи робимо з нуля?
Так, існує базовий механізм, потребує доналаштування.
11. Механізм подання звернень через ЦНАП - ЦНАП взагалі можуть приймати звернення зараз?
Дивись відповідь на п.8
12. Функціонал Базової соціальної допомоги - він вже частково реалізований згідно постанови № 371? Що саме доповнюється?
Згідно з постанови КМУ від 25.03.2025 № 371 треба здійснити доналаштування в існуючій інформаційній взаємодії щодо отримання відомостей від інтегрованої системи ПФУ про отримувачів:
1) тимчасової державної допомоги дітям, батьки яких ухиляються від сплати аліментів, не мають можливості утримувати дитину або місце проживання їх невідоме;
2) державної соціальної допомоги особам, які не мають права на пенсію, та особам з інвалідністю; та повернення статусу щодо отримання БСД отримувачами зазначених допомог та позначку про відмову від них.
Також слід доналаштувати існуючу інформаційну взаємодію з Порталом Дія на предмет синхрон/асинхрон сервісу відповідно до умов 2 етапу БСД, що передбачає отримання складу сім’ї від людини, в той час, як у 1 етапі інформація про членів сім’ї отримувалась з ЄІССС, якщо заявник та його сім’я є отримувачами визначених постановою КМУ від 25.03.2025 № 371 державних соціальних допомог. А також інші необхідні, що будуть визначені виконавцем в ході аналізу, доналаштування функціоналу БСД відповідно до п. 3 постанови Кабінету Міністрів України від 25.03.2025 № 371 «Деякі питання реалізації експериментального проекту щодо надання базової соціальної допомоги», в частині доповнення до учасників експериментального проєкту осіб / сім’ї, не зазначені в абзаці третьому цього підпункту, якщо вони на дату звернення за призначенням базової соціальної допомоги відповідають вимогам та критеріям, визначеним Порядком реалізації експериментального проекту щодо надання базової соціальної допомоги, затвердженим цією постановою.
13. Чи всі зовнішні системи надають тестові (sandbox) середовища?
Надання доступу до промислового і тестового середовищ регламентується підписаними договорами про інформаційну взаємодію. Перелік сервісів, які містять тестові середовища, розміщено на веб-ресурсі Трембіти catalog.trembita.gov.ua
14. Чи є тестові дані для перевірки інтеграцій?
Зазвичай тестові дані формуються з контрагентом (тобто – стороною, яка надає або приймає інформаційну взаємодію). Проте, на тестовому середовищі ЄІССС містяться тестові дані, які можна використати для перевірки інтеграцій.
15. Хто відповідальний за координацію отримання доступів (з боку замовника)?
Доступи до середовищ ЄІССС надаються Адміністратором ЄІССС, якого визначено постановою КМУ від 14.04.2021 № 404 «Про затвердження Положення про Єдину інформаційну систему соціальної сфери» за дорученням Мінсоцполітики відповідно до листів-звернень Виконавця з описом запланованих робіт.
Дата відповіді:
14.11.2025 12:13
Відповідь надана
архітектура
Номер:
041a7523a9154d66a3171b001840da7f
Дата опублікування:
11.11.2025 17:01
Опис:
Які мови програмування використовуються ? Фреймворки, бібліотеки?
Відповідь:
Доброго дня, шановний Учаснику, дякуємо за виявлений інтерес до даної закупівлі.
Мови: C#, TypeScript, SQL/PLSQL
Фреймворки: ASP.NET, Angular
Бібліотеки: DevExpress, Olympus.NET, IIT.
Дата відповіді:
12.11.2025 17:04
Відповідь надана
архітектура
Номер:
9fef1435d0c04868820d9b90c6f5d8e7
Дата опублікування:
07.11.2025 19:34
Опис:
Просимо надати детальний опис програмного рішення, яке є предметом закупівлі, а саме:
загальний опис системи (її призначення, основні функції та модулі);
архітектуру рішення (серверну, клієнтську частини, взаємодію компонентів);
використовувані технології, фреймворки та мови програмування.
Ця інформація є необхідною для належного розуміння предмета закупівлі, можливості оцінки сумісності, обсягу робіт та підготовки коректної пропозиції учасниками. Без цих даних неможливо об’єктивно визначити вимоги до функціональності, інтеграції та підтримки програмного забезпечення.
Відповідь:
Доброго дня, шановний Учаснику, дякуємо за виявлений інтерес до даної закупівлі.
Загальний опис системи (її призначення, основні функції та модулі)
Відомості наведені в Положенні про Єдину інформаційну систему соціальної сфери, затвердженому постановою Кабінету Міністрів України від 14 квітня 2021 р. № 404 (в редакції постанови Кабінету Міністрів України від 27 жовтня 2023 р. № 1130).
Архітектура рішення (серверна, клієнтська частини, взаємодія компонентів)
Архітектура ЄІССС включає наступні компоненти:
- Сервери баз даних (основний та резервні), на яких функціонує єдина централізована база даних ЄІССС, що виконує зберігання та санкціоноване надання інформації, а також реалізує певну частину бізнес-логіки засобами системи керування базами даних.
- Сервери додатків, які реалізують частину бізнес та презентаційної логіки, функції обміну з іншими системами, у т. ч. забезпечують роботу web-користувачів.
- Тонкий (web) клієнт, який за допомогою web-інтерфейсу надає користувачам доступ до функцій та даних ЄІССС.
- Desktop-модулі, ПЗ яке неможливо реалізувати в тонкому (web) клієнті.
Внутрішня інформаційна взаємодія між компонентами ЄІССС базується на центральній базі даних ЄІССС, яка передбачає спільне використання інформаційних об’єктів, викликів процедур та/або запуск необхідних процесів за допомогою програмного інтерфейсу АРІ.
Інформаційна взаємодія ЄІССС з зовнішніми системами забезпечується через існуючу підсистему обміну даними із суб’єктами інформаційної взаємодії ЄІССС. Переважно використовується Система електронної взаємодії державних електронних інформаційних ресурсів «Трембіта».
Використовувані технології, фреймворки та мови програмування
Oracle Database Enterprise Edition
Стек технологій Microsoft WinForms, Windows Comminication Foundation та технології ASP.NET
Angular
ЄІССС працює на актуальних версіях веб-браузерів Microsoft Edge, MozillaFirefox, Chrome.
Дата відповіді:
10.11.2025 18:08
Відповідь надана
працівники
Номер:
59dcd6ae48824e5c9c63562aefb4666e
Дата опублікування:
07.11.2025 19:31
Опис:
У встановленій Вами вимозі щодо подання копії штатного розпису, трудових книжок або трудових/цивільно-правових договорів фактично унеможливлюється участь компаній, які співпрацюють із фахівцями на умовах договорів із фізичними особами-підприємцями (ФОП).
Звертаємо увагу, що чинне законодавство не обмежує учасників у виборі форми співпраці з персоналом, а господарська діяльність може здійснюватися як із найманими працівниками, так і на договірних засадах із ФОП.
Просимо внести зміни до тендерної документації, доповнивши вимогу можливістю підтвердження залучення персоналу договорами із ФОП, що виконують відповідні функції, — як рівноцінною формою підтвердження наявності працівників.
Відповідь:
Доброго дня, шановний Учаснику, дякуємо за виявлений інтерес до даної закупівлі.
Переліком документів для підтвердження інформації, викладеної у довідці, що містить інформацію про наявність в учасника працівників відповідної кваліфікації, які мають необхідні знання та досвід для виконання умов договору, передбачено надання учасником копії трудового договору або договору цивільно-правового характеру.
Дата відповіді:
10.11.2025 18:07