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.buyers.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.buyers.identifier.scheme = UA-EDR
  • award.status ∈ {pending_waiting, pending_admission, pending}
  • інтеграція має статус active
Основний сценарій
Альтернативний сценарій

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

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

  1. Учасник подає заявку
  2. Майданчик активує заявку
  3. Заявка переходить у кваліфікацію
  4. ЦБД
створює
  1. створює award
  2. ЦБД перевіряє умови запуску інтеграції
  3. ЦБД виконує авторизацію в ЄДР (отримує JWT токен)
  4. ЦБД відправляє запит до ЄДР
з
  1. з code = ЄДРПОУ
  2. ЄДР повертає дані КБВ (може бути список)
  3. ЦБД валідовує відповідь
  4. Дані відповідають
моделі
  1. моделі beneficiariesGeneralInfo
  2. ЦБД записує дані
в
  1. в award.beneficiaries
  2. Оновлює:
  • award.dateModified
  • procedure.dateModified
  • systemDateModified
Альтернативний сценарій

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

Помилка API → UC3/UC11-15
Результат

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

...