Page History

...

1. Майданчик, залучає користувача до участі в аукціоні де звіт з інформацією про КБВ є обовʼязковим
2. Учасник є юридичною особою
3. Учасник подає заявку на участь
4. Майданчик активує заявку на участь
5. ЦБД отримує дані про активацію заявки на участь
6. ЦБД перевіряє чи є документ з типом в заявці якщо витяг ЄДР - x_tenderersRegisterExtract, якщо заява в довільній формі - x_ultimateBeneficiaryInfo - наразі цих типів документів немає в SUE/SUD
   1. Якщо в bid немає документа з визначеним типом:
      1. ЦБД надсилає івент до системи з технічним id користувача та кодом ЄДРПОУ користувача та owner
      2. Система фіксує івент і фіксує отримані дані
      3. Перевіряє чи документ з типом в 
      4. Система надсилає запит до ЄДР з авторизаційним ключем і даними для пошуку
      5. ЄДР повертає відповідь на запит:
         1. в форматі переліку полів для формування звіту
            1. Система  опрацьовую отриману інформацію
            2. Система формує звіт
         2. в форматі звіту 
         3. помилка (перелік можливих зазначено нижче)
      6. Система додає сформований звіт до документ сервісу з привʼязкою до технічного id учасника 
      7. Варіанти наступних дій:
         1. 1.Варіант  
            1. Система додає інформацію в transfer блок bid
            2. Майданчик отримує токен до документа і надає користувачу відповідно до технічного id bid виконувати дії над документом
            3. Учасник бачить звіт в своєму кабінеті
         2. 2.Варіант Система підвантажує дані в bid самостійно - не виглядає як релевантний кейс
            1. Майданчик забирає в разі потреби викачує документ
   2. Якщо в bid наявний документ з визначеним типом:
      1. ЦБД не надсилає івент до системи

User Story

Проблемні питання:

1. Використання існуючого документ сервісу. Відповідно до загальної логіки роботи з документ сервісом і документів які завантажені в procedure/bid/award/contract зі сторони Адміністратора ми не зможемо завантажувати документи від учасника тощо, відповідно вони не зможуть з ним працювати якщо не скачають і заново не завантажать в біда а тоді буде дублювання інформації. 
2. Для процедур де цей документ є обовʼязковим, учасники не зможуть активувати біда без наявності цих документів, відповідно логіка повинна відпрацювати на етапі створення bid учасника в статусі draft.
3. Питання юридичної можливості вносити зміни в bid якщо ми будемо це робити без схеми майданчик надсилає нам запит і у відповідь отримує звіт ?
4. Питання відповідно до того що нам треба закрити можливість створювати декілька запитів від одного учасника 
   1. Технічне рішення яке може закрити дану можливість
      1. Фіксація технічного id учасника та owner, яке використовувалось для надсилання запиту
      2. Аналіз кількості запитів та/або блокування наступних запитів на формування звітів (order = 1 )
5. Питання який саме звіт/документ хочемо отримувати ? (Наразі є варіанти:
   1. Відомості (витяг) з Єдиного державного реєстру юридичних осіб, фізичних осіб-підприємців та громадських формувань з підписом технічного адміністратора - Підходить для ЮО та ФОП (але для ФОП немає сенсу якщо потрібна інформація про КБВ) 
   2. Відомості (витяг) з Єдиного державного реєстру юридичних осіб, фізичних осіб-підприємців та громадських формувань без підписа технічного адміністратора- Підходить для ЮО та ФОП (але для ФОП немає сенсу якщо потрібна інформація про КБВ) 
   3. Інформація про кінцевого бенефіціарного власника юридичної особи - документ сформований учасником на імʼя директора ЕТМ
   4. Структура власності майданчика  - документ сформований учасником 
   Як учасник аукціону, я хочу мати звіт з інформацією про КБВ, для проходження успішної кваліфікації 

Як працює сервіс ЄДР

Сервіс ЄДР реалізований як API для автоматичного отримання даних для формування звіту/документу звіту про КБВ учасника торгів. Взаємодія працює по протоколу HTTP з використанням авторизації через JWT. Загальна логіка процесу: спочатку через метод авторизації отримуємо access та refresh токени, а потім використовуємо їх для виклику ендпоінту отримання даних для формування звіту/документу звіту за кодом ЄДРПОУ. - Детальніше буде додано після отримання тестового ключа

...

1. Авторизація (отримання токенів)

2. Оновлення access_token

3. Метод отримання унікального ідентифікатора

   1. Метод: POST

   2. Ендпоінт: https://targetServer/1.0/subjects?code=ХХХХХХХХ, де code - код ЄДРПОУ учасника

   3. Приймає на вхід:

      • Обовʼязковий query-параметр: code
      • Заголовок: Authorization: Bearer <access_token>

   4. Приклад запиту:

   5. Приклади відповіді:

      1. Якщо code знайдено, а також токен авторизації є валідним:

      2. Якщо code не знайдено:

      3. Якщо сплив термін дії токена авторизації:

      4. Якщо сервіс наразі недоступний: 

4. Метод отримання звіту

   1. Метод: POST

   2. Ендпоінт: https://targetServer/2.0/get-documents/ID, де ID - унікальний ідентифікатор

   3. Приймає на вхід:

      1. Обовʼязковий query-параметр: IDЗаголовок: Authorization: Bearer <access_token>

   4. Приклад запиту:

   5. Приклади відповіді:

      1. Якщо ID знайдено, а також токен авторизації є валідним:

      2. Якщо ID не знайдено:

      3. Якщо сплив термін дії токена авторизації:

      4. Якщо сервіс наразі недоступний: 

5. Метод отримання даних для формування звіту
   1. Метод: POST
   2. Ендпоінт: https://targetServer/1.0/subjects?code=ХХХХХХХХ, де code - код ЄДРПОУ учасника
   3. Приймає на вхід:
      1. Обовʼязковий query-параметр: code
      2. Заголовок: Authorization: Bearer <access_token>

   4. Приклад запиту:

   5. Приклади відповіді:

      1. Якщо code знайдено, а також токен авторизації є валідним:

      2. Якщо code не знайдено:

      3. Якщо сплив термін дії токена авторизації:

      4. Якщо сервіс наразі недоступний: 

...

Зміни в АРІ ЦБД

...

Необхідно додати валідацію на активацію заяви на участь виключно для процедур RCE, RCD. 

Дану валідацію необхідно додати в ендпоінт:

PATCH​/api​/procedures​/{procedure_id}​/bids​/{bid_id}​/status

Валідація має спрацьовувати при спробі активувати заяву на участь (draft → active). Валідація перевіряє наявність діючого контракту у учасника через сервіс УЗ. Валідація відбувається після перевірки за допомогою ЄДРПОУ учасника (в ЦБД цим значенням є bids.bidders.identifier.id) наявності активного контракту з УЗ. 

• Для перевірки діючого контракту нас цікавить виключно поле "hasContract". Значення інших полів ігноруємо. 
• Валідацію може бути не пройдено виключно якщо чітко зазначено значення поля hasContract як false. 

Додаткове поле в моделі bids

Необхідно розширити модельку bids для процедур УЗ. 

Нове поле - bids.uzAgreementCheck. Тип поля - string.

x-legalNameUa: Результат перевірки договору з УЗ
x-legalNameEn: UZ contract verification result

Можливі значення:

• verified - означає, що заяву на участь було активовано після успішної перевірки через сервіс УЗ.
• not_verified - означає, що заяву на участь було активовано, проте перевірку не було виконано. 

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

• verified
  • Заяву активовано. Перевірку виконано.
  • Bid activated. Verification completed.
• not_verified
  • Заяву активовано без перевірки.
  • Bid activated without verification.

Особливості поля:

• Поле є автогенерованим
• Поле з'являється в заяві на участь лише після активації заяви на участь
• Міграції відсутні (в старих процедурах не додаємо дане поле)

Успішний сценарій активації заяви на участь:

1. Учасник створює заяву на участь через майданчик, і вона отримує початковий статус draft.

2. Майданчик ініціює зміну статусу заяви з draft на active через метод patch.

3. ЦБД перевіряє тип процедури, і якщо це не RCE або RCD, активація завершується за стандартною логікою без перевірки контракту через сервіс УЗ.

4. Для процедур RCE/RCD система перевіряє наявність діючого токену або виконує POST-запит на авторизацію в сервісі УЗ для отримання access_token.

5. ЦБД виконує GET-запит до ендпоінту ActiveUzTransportAgreement, передаючи код ЄДРПОУ учасника (в модельці учасника це bids.bidders.identifier.id) в параметрах та токен у заголовку

6. При отриманні від сервісу УЗ відповіді 200 OK з параметром "hasContract": true, ЦБД підтверджує наявність договору.

   1. Не перевіряємо дату завершення контракту та не робимо жодної логіки на поле endDate

7. Система додає поле bids.uzAgreementCheck зі значенням verified, та успішно змінює статус заяви на active та повертає майданчику відповідь 200 OK. 

8. Якщо сервіс УЗ повертає статус 400 та "hasContract": false, ЦБД блокує активацію та видає 422 помилку про відсутність договору: "bids.bidders.identifier.id - no active contract found".

9. У разі технічної недоступності сервісу УЗ (статус 500 або таймаут), ЦБД ігнорує валідацію, додає поле bids.uzAgreementCheck зі значенням not_verified та дозволяє активацію заяви, щоб не блокувати процес подання.

Сценарії у випадку помилок при авторизації

...

Помилка 401 (невірний логін чи пароль)

...

1. Додає поле bids.uzAgreementCheck зі значенням not_verified
2. Змінює статус на active без подальших перевірок
3. Згенерувати ALERT та надіслати його в канал в слек

...

1. Повторно пробує отримати токен (автоматично, без необхідності ще раз відправляти запит на активацію (3 рази: через 1 секунду, через 3 секунди та через 5 секунд)
2. При повторній помилці - додає поле bids.uzAgreementCheck зі значенням not_verified
3. Змінює статус на active без подальших перевірок

Сценарції у випадку помилок при оновленні токена авторизації 

...

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

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

Сценарії у випадку помилок при перевірці контракта

...

Пропускає валідацію. Додає поле bids.uzAgreementCheck зі значенням not_verified. Міняє статус заяви на active.

...

Запускається цикл переавторизації: 

1. Спробувати оновити токен через refresh_token
2. Якщо спроба не вдалась - спробувати отримати новий токен через логін та пароль
3. Якщо авторизація успішна - повторно виконати перевірку
4. Якщо авторизація неуспішна - один зі сценаріїв у випадку помилок при авторизації

...

Пропускає валідацію. Додає поле bids.uzAgreementCheck зі значенням not_verified. Міняє статус заяви на active.

...

- Опис буде додано після погодження