You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 33 Next »

Документація

Загальний опис

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

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

  1. Додати до базової моделі award необовʼязкову до заповнення поле beneficiaries моделю даних beneficiariesGeneralInfo (модель даних наведено нижче)
  2. Налаштувати інтеграцію з ЄДР де після відпраки запиту заповнюється модель beneficiariesGeneralInfo
  3. При внесенні інформації змінюємо award.dateModified, dateModified (procedure) та systemDateModified
  4. Майданчики відображають дану інформацію організатору в його кабінеті. Відображення в інших місцях не є обовʼязковою (портал, кабінети учасників)
  5. Модель даних beneficiariesGeneralInfo
    Технічна назваБізнес назва (x-legalName)ТипRead onlyОбовʼязковість (потребує уточнень)Коментар
    uk_UAen_US
    beneficiaries
    		Інформація про кінцевого бенефеціарного влсникаInformation about the ultimate beneficial owner
    		list of objectstruefalse
     

    beneficiariesGeneralInfo


    		  objecttruefalse


    		beneficialNameПІБ кінцевого бенефеціарного власникаFull name of the ultimate beneficial ownerstring (multilang)truetrueВ запиті Прізвище це відповідь на один запит, Імʼя та По батькові - відповідь на інший запит


    		addressАдресаAddressmodeltruetrue


    beneficiariesType

    		Тип бенефіціарного володінняType of 

    beneficiaries

    		string (multilang)truetrue


    		roleРоль КБВ по відношенню до пов’язаного суб’єкта
    		stringtruetrueВідповідь на запит текстове відображення ролі (roleText)


    interest

    		Відсоток частки статутного капіталу або відсоток права голосу
    		float truetrue


    indirectInterest

    		Відсоток частки статутного капіталу або відсоток права голосу у разі непрямого впливу
    		floattruetrue


    otherImpact

    		Інший характер та міру впливу
    		 




    beneficiaryFalse

    		Ознака можливої недостовірності інформації про КБВ
    		 




    excluded

    		Ознака виключення відомостей про КБВ за вказівкою Міністерства юстиції України
    		 




    isMissing

    		Ознака відсутності КБВ юридичної особи
    		 




    reason

    		Причина відсутності КБВ юридичної особи
    		 




    		informationDateДата отримання данихDate of informationstring ($dateTime)truetrue

Технічні вимоги до автоматичного збагачення award даними КБВ з ЄДР

  1. Майданчик, залучає користувача до участі в аукціоні де звіт з інформацією про КБВ (x_ultimateBeneficiaryInfo) визначений як тип документу
  2. Учасник є юридичною особою
  3. Учасник подає заявку на участь
  4. Майданчик активує заявку на участь
  5. Заявка на участь перейшла в кваліфікацію
  6. Під час створення award (асинхронний запит)ЦБД направляє запит в ЄДР з авторизаційним ключем і даними для пошуку де виконуються умови:
    1. Для award в статусах: pending_waiting, pending_admission, pending 
    2. Для award.bidders.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. Процедури, яких немає в переліку не використовують даний функціонал - РО попереджено що додавання нових напрямків йде через розробку
  7. ЦБД отримує дані з ЄДР
    1. Перевіряє отримані дані:
      1. Якщо в отриманій відповіді містяться дані, які не можна внести в award → ЦБД не вносить дані в award
      2. Якщо в отриманій відповіді містяться дані, які можна внести в award → ЦБД вносить дані в award 
        1. При внесенні даних змінюється:
          1. award.dateModified
          2. dateModified (procedure)
          3. systemDateModified

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

  1. Тип поля beneficiaryInfo в award - list of objects
  2. Запит на ЄДР може віддати дані про декількох КБВ
  3. Потрібно передбачити що повторний запит відправляється в разі отримання відповіді 500 або 502 омежений 3ма спробами 
  4. Якщо не вдається отримати відповідь виводимо в поле текст "Не вдалось отримати інформацію з сервісу"
  5. Нам потрібно фіксувати повідомленням в Slack канал якщо отримуємо відповіді:
    1. 400
    2. 401
    3. 402
    4. 403
    5. 404
    6. 406
    7. 429

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

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

Дія тестового ключа 6 місяців

Доступні ендпоінти (Потребує перевірки та доповнення після отримання тестових ключей)

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

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

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

    1. Метод: POST

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

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

      • Обовʼязковий query-параметр: code

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

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

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

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

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

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

Також можливий кейс, що АРІ поверне 403 помилку, якщо, наприклад, ЄДР змінить права доступу нашого акаунту.

Перелік кодів помилок 

Коди помилок та відповідей:

Коди відповідей HTTP

Код

Текст

Пояснення

200

OK

Запит успішно оброблено і повернуто результат

400

Bad Request

Запит має помилку або не може бути оброблений. Відповідне повідомлення з поясненнями додане до відповіді.

401

Unauthorized

Параметри авторизації не правильні, або не вказані взагалі.

402

PaymentRequired

Для виконання запиту необхідна оплата.

403

Forbidden

Запит вірний але в обробці відмовлено. Відповідне повідомлення з поясненнями додано до відповіді.

404

Not Found

Адреса не правильна або ресурс до якого йде запит не існує.

406

Not Acceptable

Дані передані в запиті мають не зрозумілий формат.

429

Many Requests

API повертає таку відповідь коли вичерпано обмеження запитів до ресурсу.

500

Internal Server Error

Щось зламалось.

502

Bad Gateway

Сервіс вимкнено або проходить оновлення.

Повідомлення з інформацією про помилку.

У разі помилки API повертає відповідь з поясненням, формат - JSON, наприклад:

{"errors":[{"message":"Invalid or expired token","code":2}]}

Перелік кодів помилок

У відповіді, окрім повідомлення з поясненням, додатково надається код помилки, який можна використовувати для автоматизованої обробки. Протягом часу, текстове повідомлення може модифікуватись, але код залишається незмінним.

Код

Текст

Пояснення

1

Could not authenticate you або Authentication credentials were not provided

Помилка аутентифікації.

2

Invalid or expired token

Недіючий або некоректний токен.

3

Your account is not permitted to access this resource

Відповідь надається разом із HTTP статусом 403. Користувач, з використанням токену якого було виконано аутентифікацію, не має достатніх прав для виконання запиту.

4

Sorry, that page does not exist

Відповідь надається разом із HTTP статусом 404. Сторінка до якої виконується запит не знайдена.

5

Paiment required

Відповідь надається разом із HTTP статусом 402. Недостатньо коштів для виконання платного запиту.

6

Parse Error або `search_date` has wrong format

Відповідь надається разом із HTTP статусом 400. Не правильний формат одного або декількох параметрів запиту.

9

Rate limit exceeded

Відповідь надається разом із HTTP статусом 429. Вичерпано кількість запитів, дозволених виконати протягом проміжку часу.

10

`code` or `passport` parameter must be provided.

У запиті не надано параметрів необхідних для виконання пошуку.

11

`passport` parameter has wrong value.

Один або більше параметрів запиту має невірний формат.

20

Internal error

Відповідь надається разом із HTTP статусом 500.

Правила обробки помилок

HTTP codeДія системи
400Slack alert, дані не записуються
401Slack alert, спроба оновити token
402Slack alert, дані не записуються
403Slack alert, дані не записуються
404Slack alert, дані не записуються
406Slack alert, дані не записуються
429Slack alert, дані не записуються
500Retry до 3 разів
502Retry до 3 разів

User Story 1

ЯкЦБД Prozorro.Sale
я хочуавтоматично отримувати та зберігати інформацію про кінцевих бенефіціарних власників (КБВ) з ЄДР при створенні award
щобзабезпечити актуальність, централізацію та зменшити залежність від ручного введення даних

USE CASE 1 — Успішне отримання та збереження КБВ

Назва

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

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

Acceptance Criteria

1

GivenВсі умови виконані

When

Створюється award

Then

Відправляється запит до ЄДР

2


Given

ЄДР повернув валідні дані

When

Дані проходять валідацію

Then

Вони записуються в award.beneficiaries

3

GivenДані записані

Then

оновлюються всі dateModified:

  • award.dateModified
  • dateModified (procedure)
  • systemDateModified


USE CASE 2 — Дані не можуть бути внесені

Назва

Відмова у записі КБВ
Актори
  • ЦБД (primary)
  • ЄДР API (external)
Передумови

Отримано HTTP код:
400, 401, 402, 403, 404, 406, 429

Основний сценарій
  1. ЦБД отримує відповідь від ЄДР
  2. Перевіряє структуру
  3. Дані:
    • неповні / некоректні / не мапляться
  4. ЦБД НЕ записує дані
Результат

award без змін


Acceptance Criteria

1

GivenДані не відповідають моделі

When

Виконується валідація

Then

Дані не записуються


USE CASE 3 — Retry при помилках 500 / 502

Назва

Повторна спроба отримання даних
Актори
  • ЦБД (primary)
  • ЄДР API (external)
Передумови

Отримано HTTP код:
500, 502

Основний сценарій
  1. ЦБД відправляє запит
  2. Отримує 500 або 502
  3. Виконує retry
  4. Повторює до 3 разів
Альтернативний сценарій

після 3 невдалих спроб → fallback

Результат
  • якщо успіх → UC1
  • якщо ні → запис тексту помилки


Acceptance Criteria

1

GivenОтримано 500/502

When

Виконується retry

Then

Система повторює запит до 3 разів

2

GivenВсі retry невдалі

Then

Записується повідомлення:
"Не вдалось отримати інформацію з сервісу"


USE CASE 4 — Логування помилок в Slack

Назва

Моніторинг інтеграції з ЄДР
Актори
  • ЦБД (primary)
  • ЄДР API (external)
Передумови
  • Отримано HTTP код:
    400, 401, 402, 403, 404, 406, 429
Основний сценарій
  1. ЦБД отримує помилку
  2. Формує повідомлення
  3. Відправляє в Slack канал
Результат
  • команда отримує alert


Acceptance Criteria

1

GivenОтримано помилку зі списку

When

Обробляється відповідь

Then

Відправляється повідомлення в Slack


USE CASE 5 — Інтеграція не запускається

Назва

Неініціювання запиту до ЄДР
Актори
  • ЦБД (primary)
  • ЄДР API (external)
Передумови

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

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

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


Acceptance Criteria

1

GivenУмови не виконані

When

Створюється award

Then

запит до ЄДР не виконується


USE CASE 6 — Обробка множинних КБВ

Назва

Запис кількох бенефіціарів
Актори
  • ЦБД (primary)
  • ЄДР API (external)
Передумови
  • Процедура входить в перелік дозволених (LLE, LLD, …, SUD)
  • В процедурі використовується документ x_ultimateBeneficiaryInfo
  • Учасник є юридичною особою
  • award.bidders.identifier.scheme = UA-EDR
  • award.status ∈ {pending_waiting, pending_admission, pending}
Основний сценарій
  1. ЄДР повертає список КБВ
  2. ЦБД мапить кожен запис
  3. Формує list of objects
  4. Записує в award.beneficiaries[]
Результат

Збережено всі КБВ


Acceptance Criteria

Acceptance Criteria

1

GivenЄДР повертає кілька КБВ

When

Відбувається запис

Then

Всі КБВ зберігаються в масиві


User Story 2

ЯкЦБД Prozorro.Sale
я хочузупиняти направлення запитів до ЄДР після першого отримання помилки 402 або 429
щобне створювати зайве навантаження на сервіс, не витрачати ліміти та уникати повторних неуспішних запитів до моменту відновлення доступу/поповнення коштів. 
додатковоПісля внесення коштів або відновлення ліміту система має відновити направлення запитів до ЄДР.

USE CASE 1 — Зупинка запитів після отримання 402

Назва

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

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

Acceptance Criteria

1

GivenВсі умови виконані

When

Створюється award

Then

Відправляється запит до ЄДР

2


Given

ЄДР повернув валідні дані

When

Дані проходять валідацію

Then

Вони записуються в award.beneficiaries

3

GivenДані записані

Then

оновлюються всі dateModified:

  • award.dateModified
  • dateModified (procedure)
  • systemDateModified


Use Case 1 — 

Назва

Автоматичне призупинення інтеграції з ЄДР при помилці 402 Payment Required

Актори

  • ЦБД
  • ЄДР
  • Адміністратор/відповідальна команда
  • Slack канал

Передумови

  • Інтеграція з ЄДР активна
  • ЦБД направляє запит до ЄДР для отримання даних КБВ
  • ЄДР повертає HTTP 402
  • У вимогах уже передбачено фіксацію таких помилок у Slack.

Основний сценарій

  1. ЦБД направляє запит до ЄДР.
  2. ЄДР повертає відповідь 402 Payment Required.
  3. ЦБД фіксує факт отримання помилки.
  4. ЦБД змінює внутрішній статус інтеграції з ЄДР на умовний:
    • suspended;
    • або payment_required;
    • або temporarily_disabled.
  5. ЦБД припиняє направлення нових запитів до ЄДР.
  6. ЦБД відправляє повідомлення в Slack канал.
  7. Для нових awards, які підпадають під умови інтеграції, запит до ЄДР не виконується.
  8. У відповідному полі/технічному статусі фіксується причина:
    • Запити до ЄДР тимчасово призупинено через необхідність оплати.

Результат

  • Нові запити до ЄДР не направляються.
  • Команда отримала повідомлення про необхідність внесення коштів.
  • Дані КБВ для нових awards тимчасово не збагачуються.

Acceptance Criteria

AC1
Given ЦБД отримала від ЄДР відповідь 402
When система обробляє відповідь
Then інтеграція з ЄДР переходить у статус призупинення.

AC2
Given інтеграція має статус призупинення через 402
When створюється новий award, який відповідає умовам інтеграції
Then ЦБД не направляє запит до ЄДР.

AC3
Given отримано 402
When система фіксує помилку
Then повідомлення надсилається в Slack канал.

Use Case 2 — Зупинка запитів після отримання 429

Назва

Автоматичне призупинення інтеграції з ЄДР при помилці 429 Many Requests

Актори

  • ЦБД
  • ЄДР
  • Slack канал
  • Адміністратор/відповідальна команда

Передумови

  • Інтеграція з ЄДР активна
  • ЦБД направляє запит до ЄДР
  • ЄДР повертає HTTP 429
  • 429 означає, що вичерпано обмеження запитів до ресурсу.

Основний сценарій

  1. ЦБД направляє запит до ЄДР.
  2. ЄДР повертає відповідь 429 Many Requests.
  3. ЦБД фіксує помилку.
  4. ЦБД призупиняє направлення нових запитів до ЄДР.
  5. ЦБД відправляє повідомлення в Slack канал.
  6. Нові awards, які підпадають під інтеграцію, не ініціюють запит до ЄДР.
  7. Система фіксує причину призупинення:
    • Перевищено ліміт запитів до ЄДР.

Результат

  • Інтеграція тимчасово зупинена.
  • Нові запити до ЄДР не виконуються.
  • Команда повідомлена про перевищення ліміту.

Acceptance Criteria

AC1
Given ЦБД отримала відповідь 429
When система обробляє відповідь
Then направлення нових запитів до ЄДР зупиняється.

AC2
Given інтеграція призупинена через 429
When створюється новий award
Then ЦБД не направляє запит до ЄДР.

AC3
Given отримано 429
When система обробляє помилку
Then повідомлення надсилається в Slack канал.

Use Case 3 — Відновлення запитів після внесення коштів

Назва

Ручне або автоматичне відновлення інтеграції з ЄДР після внесення коштів

Актори

  • Адміністратор/відповідальна команда
  • ЦБД
  • ЄДР

Передумови

  • Інтеграція з ЄДР була призупинена через 402
  • Кошти внесено / доступ до сервісу відновлено

Основний сценарій

  1. Відповідальна команда вносить кошти.
  2. Адміністратор ініціює відновлення інтеграції.
  3. ЦБД змінює статус інтеграції з:
    • payment_required / suspended
    • на active.
  4. ЦБД відновлює направлення запитів до ЄДР.
  5. При створенні наступного award ЦБД знову виконує стандартну логіку запиту до ЄДР.
  6. Якщо ЄДР повертає 200, дані КБВ обробляються та записуються в award.

Результат

  • Інтеграція з ЄДР активна.
  • Нові запити знову направляються.
  • Дані КБВ можуть бути отримані та внесені в award.

Acceptance Criteria

AC1
Given інтеграція призупинена через 402
And кошти внесено
When адміністратор активує інтеграцію
Then статус інтеграції змінюється на active.

AC2
Given інтеграція активна після відновлення
When створюється новий award
Then ЦБД направляє запит до ЄДР.

AC3
Given ЄДР після відновлення повертає 200
When ЦБД отримує валідні дані
Then дані записуються в award.beneficiaries.

Use Case 4 — Відновлення після вичерпання ліміту запитів

Назва

Відновлення інтеграції після помилки 429

Актори

  • ЦБД
  • Адміністратор/відповідальна команда
  • ЄДР

Передумови

  • Інтеграція була призупинена через 429
  • Ліміт запитів поновлено або відповідальна команда підтвердила можливість повторного використання сервісу

Основний сценарій

  1. Відповідальна команда перевіряє, що ліміт запитів відновлено.
  2. Адміністратор активує інтеграцію.
  3. ЦБД змінює статус інтеграції на active.
  4. Наступні awards знову запускають запит до ЄДР.
  5. Якщо ЄДР повертає успішну відповідь — дані обробляються за стандартним сценарієм.

Результат

  • Запити до ЄДР відновлені.
  • Система продовжує автоматичне збагачення awards даними КБВ.

Acceptance Criteria

AC1
Given інтеграція призупинена через 429
When ліміт запитів відновлено
And адміністратор активує інтеграцію
Then ЦБД знову направляє запити до ЄДР.

AC2
Given інтеграція активована після 429
When створюється award
Then запит до ЄДР виконується.

Додаткове бізнес-правило для ТЗ


Рекомендовані статуси інтеграції

СтатусОпис
activeЗапити до ЄДР виконуються
payment_requiredОтримано 402, запити зупинено
rate_limit_exceededОтримано 429, запити зупинено
suspendedЗагальний статус призупинення
restoredІнтеграцію відновлено

Ключові бізнес-правила (дуже важливо)

  • Інтеграція тригериться тільки при створенні award
  • Запит асинхронний
  • Дані записуються тільки якщо валідні
  • Запис — атомарний (все або нічого)
  • Можливі декілька КБВ
  • Retry тільки для:
    • 500
    • 502
  • Slack alert тільки для:
    • 4xx + 429
  • Fallback текст при недоступності ЄДР
  • У разі отримання першої відповіді від ЄДР з HTTP статусом 402 або 429 ЦБД має призупинити направлення всіх наступних запитів до сервісу ЄДР до моменту ручного або автоматичного відновлення інтеграції після внесення коштів / відновлення ліміту.


  • No labels