Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Метою розробки є інтеграція з ЄДР для автоматизації та централізації отримання даних про КБВ (кінцевого бенефеціарного власника) для учасників що є юридичними особами. Дана інформація може бути як обовʼязковою так і не обовʼязковою для певних процедур (наразі розробка інтеграції відбувається тільки для процедур де є документ з типом x_ultimateBeneficiaryInfo).

Для реалізації цієї інтеграції необхідно виконати дії:

...

  1. Учасник є юридичною особою
  2. Учасник подає заявку на участь
  3. Майданчик активує заявку на участь
  4. Заявка на участь перейшла в кваліфікацію
  5. Під час створення award ЦБД направляє асинхроний запит в ЄДР з авторизаційним ключем і даними для пошуку де виконуються умови:
    1. Для award в статусах: pending_waiting, pending_admission, pending 
    2. Для awardДля award.biddersbuyers.identifier.UA-EDR
    3. Для процедур де x_ultimateBeneficiaryInfo є типом документу. Перелік процедур
      1. LLE, LLD, LLP - Оренда за законом
      2. LRE - Земельні торги - оренда
      3. LSE + LSP - Земельні торги - продаж/продаж з переважним правом
      4. REM - Процедури розподілу квот
      5. SSW - Продаж майна приватних компаній (Закриті пропозиції)
      6. SPE + SPD - Мала приватизація
      7. LPE - Велика приватизація
      8. LAE + LAP + LAW - Продаж арештованої землі
      9. APE + APD - Арештовані активи АРМА
      10. SAE + SAD - Санкційне майно
      11. SUE+SUD - Спеціальні дозволи на користування надрами
      12. Процедури, яких немає в переліку не використовують даний функціонал - РО попереджено що додавання нових напрямків йде через розробку
  6. ЦБД отримує дані з ЄДР
    1. Перевіряє отримані дані:
      1. Якщо в отриманій відповіді містяться дані, які не можна внести в award → ЦБД не вносить дані в award
      2. Якщо в отриманій відповіді містяться дані, які можна внести в award → ЦБД вносить дані в award 
        1. При внесенні даних змінюється:
          1. award.dateModified
          2. dateModified (procedure)
          3. systemDateModified

...

Назва

Отримання та запис КБВ з ЄДР в award
Актори
  • ЦБД (primary)
  • ЄДР API (external)
Передумови
  • Процедура входить в перелік дозволених (LLE, LLD, …, SUD)
  • В процедурі використовується документ x_ultimateBeneficiaryInfo
  • Учасник є юридичною особою
    • award.biddersbuyers.identifier.scheme = UA-EDR
  • award.status ∈ {pending_waiting, pending_admission, pending}
  • інтеграція має статус active
Основний сценарій
  1. Учасник подає заявку
  2. Майданчик активує заявку
  3. Заявка переходить у кваліфікацію
  4. ЦБД створює award
  5. ЦБД перевіряє умови запуску інтеграції
  6. ЦБД виконує авторизацію в ЄДР (отримує JWT токен)
  7. ЦБД відправляє запит до ЄДР з code = ЄДРПОУ
  8. ЄДР повертає дані КБВ (може бути список)
  9. ЦБД валідовує відповідь
  10. Дані відповідають моделі beneficiariesGeneralInfo
  11. ЦБД записує дані в award.beneficiaries
  12. Оновлює:
  • award.dateModified
  • procedure.dateModified
  • systemDateModified
Альтернативний сценарій

Дані невалідні → UC2

Помилка API → UC3/UC11-15

Результат

award містить список валідних КБВ (може бути декілька)

...

Назва

Неініціювання запиту до ЄДР
Актори

ЦБД (primary)

Передумови

Будь-яка з умов НЕ виконується:

  • процедура не з визначеного переліку
  • відсутній x_ultimateBeneficiaryInfo
  • не юрособа
    • award.biddersbuyers.identifier.scheme = UA-EDR
  • статус award не підходить
Основний сценарій
  1. Створюється award
  2. ЦБД перевіряє умови
  3. Інтеграція НЕ запускається
Результат

Жодних запитів до ЄДР

...