Page History

...

1. Учасник є юридичною особою
2. Учасник подає заявку на участь
3. Майданчик активує заявку на участь
4. Заявка на участь перейшла в кваліфікацію
5. Під час створення award ЦБД направляє асинхроний запит в ЄДР з авторизаційним ключем і даними для пошуку де виконуються умови:
   1. Для award в статусах: pending_waiting, pending_admission, pending 
   2. Для award.buyers.identifier.UA-EDR
   3. Для процедур з переліку процедур
      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

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

Аутентифікація до API ЄДР здійснюється за допомогою статичного API токена.

Токен передається у заголовку: Authorization: Token {API_TOKEN}

Обмін даними здійснюється по протоколу HTTPS, що забезпечує захищене передавання токена.

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

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

...

1. Інтеграція тригериться тільки при створенні award в модель даних beneficiariesGeneralInfo
2. Запит асинхронний
3. Дані записуються тільки якщо валідні
4. Запис — атомарний (все або нічого):
   1. або записуються всі КБВ (якщо хоча б один КБД не валідний  - не записується жоден)
   2. або записується один fallback - обʼєкт
   3. Основний сценарій:
   4. Створюється award
   5. Перевіряються умови
   6. Виконується авторизація в ЄДР
   7. Виконується запит до ЄДР
   8. Отримується відповідь
   9. Відбувається валідація
   10. Якщо валідно:
       • запис у award.beneficiaries[]
       • оновлення:
         • award.dateModified
         • procedure.dateModified
         • systemDateModified
5. Retry (до 3 разів) тільки для: 500, 502
   1. retry з exponential backoff
   2. після 3 спроб → fallback де systemReason = "Не вдалось отримати інформацію з сервісу"
6. API_TOKEN зберігається:
   - у захищеному конфігураційному середовищі
   - не логуються
   - не передається у відкритому вигляді

Обмеження

1. Система не повинна виконувати безкінечні повторні запити.
2. Інтеграція не виконується без умов
3. Частковий запис даних заборонений

...

Правила додаткової обробки помилок

1. Обробка 401

   1. означає невалідний або відкликаний токен

   2. retry НЕ виконується

   3. надсилається Slack alert

   4. статус інтеграції →

   5. отримано 401

   6. refresh token

   7. повторити запит (1 раз)

      Якщо refresh fail

      integration status =

      auth_error

   8. повідомлення в slack

2. Обробка 404

   1. Отримано 404
   2. запис в поле systemReason = "Суб'єкт не знайдено в ЄДР"

...

...