...
| Expand | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Загальні документи по розробці
Робота із сутностями та документами сутностей
В даному документі описані загальні та базові принципи та особливості роботи із сутностями (bid, award, documents, items, questions) та документами сутностей.
Індивідуальні особливості та характеристики (технічні ідентифікатори, назви українською/англійською, опис документу, обов'язковість, публічність і т.і.) описані в кожному окремому ТЗ процедури.
Робота із сутностями
Для роботи із сутностями (bid, award, documents, items, questions) процедури буде закладено 2 режими:
- Режим 1 - робота з усім переліком сутностей одного типу. Для видалення, редагування або додавання сутності, майданчик передає повний перелік сутностей одного типу, який замінює попередній.
- Режим 2 - робота з окремою сутністю, можливість звернутися до ID сутності та відредагувати всі або окремі її поля або видалити таку сутність.
Робота із документами
Будь-який публічний документ який користувач завантажив до відповідної сутності, має бути доступний для ознайомлення будь-якому користувачу на будь-якому із підключених майданчиків, у відповідний період процедури.
Будь-який приватний документ, який учасник завантажив до заяви на участь, має бути доступний для ознайомлення учаснику, який його завантажив та Замовнику аукціону, в якому учасник бере участь, у відповідний період процедури.
Етапи роботи із документами:
1-й етап: Користувач системи завантажує документ\документи в особистому кабінеті, після чого майданчик - завантажує документ\документи до DS та додає до відповідної сутності (завантажені документи зберігаються в ЦБД та відображаються на майданчику).
2-й етап: Користувач системи має наступні можливості:
- змінити статус сутності, а саме натиснути відповідну кнопку в особистому кабінеті (після зміни статусу працювати із документами сутності, які були додані до неї у попередньому статусі, неможливо)
- завантажити нові документи;
- оновити завантажені документи (в DS версія попереднього документу залишається, а в сутності прибирається, після чого довантажується в DS новий документ, у якого додається поле з ID версії попереднього документу, історія зберігається в history)
Можливі два варіанти на вибір щодо відображення попередніх версій документів процедури, біда, аварду, протоколу на майданчику:
- Відображати документи перекресленими;
- Виводити кнопку "Історія змін" (кнопка відображається у випадку, якщо dateModified документа відрізняється від datePublished)
Виключенням є робота із скасуванням аукціону (documentType.cancellationDetails), завантаження такого документу та натискання кнопки відбувається в рамках першого етапу, тому працювати із таким документом в рамках ЦБД неможливо.
Всі зміни таких документів можуть відбуватися тільки на рівні майданчика.
* Після завершення аукціону, протягом періоду підписання протоколу (verificationPeriod), учасники мають можливість довантажити до bid'а набір документів для усунення формальних недоліків (усі типи документів, що дозволені для bid`а) - ТІЛЬКИ ДЛЯ RENEWABLES.
- У разі довантаження оновленої версії документу, тип документу (documentType) та його неймінг (legalName) має співпадати, з документом, який на етапі розміщення заяви було додано до bid'а. Можливо тільки довантажити документи, всю інформацію bid`а (поля та документи), яка була збережена в період подання пропозицій (tenderPeriod), змінювати неможливо.
- Видалення документів bid'а, які були завантажені в період подання пропозицій (tenderPeriod), на етапі кваліфікації заборонено.
Особливості роботи із цифровим підписом
Цифровий підпис (ЕЦП/КЕП) накладається поза ЦБД. Завантажується в ЦБД окремим файлом (тільки підпис або підписаний файл) digitalSignature, в якому присутнє поле relatedDocument, де додається посилання на оригінальний документ (id документу), вже завантажений до DocumentService.
relatedDocument - ідентифікатор, що відображається тільки в документі digitalSignature та використовується для відображення зв'язку між цифровим підписом та документом сутності процедури.
За бажанням Організатору або учасника на всіх етапах процедури, де йде робота із документами сутностей (завантаження, оновлення документу) є можливість, до будь-якого документу, застосувати цифровий підпис, або за умови обов'язковості у разі, якщо це вимагають нормативні документи, такі особливості вказуються в ТЗ кожної окремої процедури.
Цифровий підпис документу необов'язковий, обов'язковість вказується в ТЗ процедури, за умови відповідних вимог в нормативних документах.
Технічні особливості роботи із цифрового підпису
ПЗ за рахунок якого створюється цифровий підпис - за бажанням майданчика, централізоване рішення поки не пропонуємо, заплановано у беклог, проте строки поки невідомі.
Обмежень щодо розширення файлу на стороні ЦБД відсутні
Вимоги до майданчиків
Можливі 2 варіанти реалізації цифрового підпису:
- Окремо документ цифрового підпису та назву/посилання на оригінальний документ
- Поряд з оригінальним документом виводити пов'язані файли цифрового підпису
Схеми по роботі з Інформаційним Повідомленням
...