Пов'язана інформація

IL.Sign declaration request

Специфікація

Apiary

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

Процес асинхронний. Якщо всі перевірки успішно виконані, асинхронний процес створення персони починається з обробки повідомлення.

Сервісна логіка

1. Тільки автентифіковані та авторизовані користувачі можуть використовувати даний сервіс.

2. Тільки запити на декларацію в статусі APPROVED можуть бути підписані.

3. Запит може бути підписаний тільки співробітником, який працює в тій же самій юридичній особі, в який був створений запит.

Авторизувати користувача

1. Перевірити валідність токену доступу

   1. Повернути 401 в разі неуспішної валідації

2. Перевірити скоупи на можливість виконання даної дії (scope = 'declaration_request:sign')

   1. Повернути 403 в разі неуспішних скоупів

Цифровий підпис

Декодувати контент, що закодований в цифровому підписі.
Використати метод по генеруванню цифрового підпису WS. Метод перевіряє цифровий підпис та повертає результат.
Див сервіс specification

Перевірити ДРФО

1. Перевірити, що ДРФО в деталях сертифікату вказано та є валідним

2. Перевірити, що ДРФО в деталях сертифікату відповідає ДРФО для Party

   1. Отримати party.tax_id за допомогою employee_id в масиві даних для персони

   2. Порівняти ДРФО зі Сертифікату з party.tax_id

      1. Змінити DRFO та TAX_ID на великі літери

      2. Змінити DRFO та TAX_ID на літери кирилиці

      3. Змінити DRFO на кирилицю та порівняти як літери кирилиці

   3. В разі неуспішнох валідації - згенерувати помилку 422

Мапінг латинських літер з кирилицею

%{"A" => "А", "B" => "В", "C" => "С", "E" => "Е", "H" => "Н", "I" => "І", "K" => "К", "M" => "М", "O" => "О", "P" => "Р", "T" => "Т", "X" => "Х"}

Перевірити запит

1. Перевірити запит, використовуючи схеми JSON (Див specification)

   1. В разі неуспішних валідацій - згенерувати помилку 422

2. Перевірити статус запиту на декларацію

   1. Якщо статус не APPROVED, - повернути помилку 'Incorrect status'

Перевірити статус верифікації персони

• перевірити, що verification_status не дорівнює NOT_VERIFIED.

  • в разі помилки - повернути 409, "Patient is not verified"

Перевірити первинну декларації

Отримати parent_declaration_id з IL_DB.declaration_requests.parent_declaration_id.

• Якщо parent_declaration_id заповнено, перевірити, що первинна декларація існує та має статус 'active'

  • в разі помилки - повирнути 404 ("Active parent declaration was not found")

Перевірити підписний контент

Перевірити декодований підписний контент з попередньо створеним в IL.db.

SELECT data.data_to_be_signed
FROM declaration_requests
WHERE id = {:id}

В разі, якщо вони не відповідають - згенерувати помилку 422 (message: "Signed content does not match the previously created content")

Перевірити співробітника

Declaration_request може бути підписаний будь-яким співробітником з відповідними скоупами для відповідної legal_entity_id.

1. Отримати legal_entity_id (client_id) з токену

2. Отримати employee_id з запиту

3. Перевірити, що $.client_id=employees.legal_entity_id 

   1. в разі помилки повернути 422 

Перевірити мітку patient_signed

• Якщо "patient_signed" не наявний в запиті, повернути 422 ("required property patient_signed was not present")

• Якщо "patient_signed"=false в запиті, повернути 422 ("Patient must sign declaration form")

• Якщо “patient_signed”=null, перевірити, що parent_declaration_id заповнений,

  • в разі помилки, повернути 422 ("Patient must sign declaration form")

Перевірити читабельний номер декларації

Отримати declaration_number з declarations.declaration_number.

• якщо вказано повернути 422 - повідомлення 'Declaration with the same declaration_number is already exist in DB' 

Обробка

Зберегти підписану декларацію до сховища даних

1. Отримати url для завантаження декларації.
   Використовувати метод Request a Secret WS

2. Оновити підписану декларацію в сховищі даних

Оновити запит на декларацію:

1. Змінити статус сутності в IL_DB.declaration_request на SIGNED

2. Встановити updated_at - now() (Отримати поточні дату та час)

3. Встановити updated_by - user_id (Отримати користувача з токену)

Отримати активні декларації

Здійснити пошук по активним деклараціям з використанням MPI ID

1. Якщо знайдено, - розірвати їх та створити нову декларацію.

   • Якщо не знайдено - створити нову декларацію.

Призупити декларацію

В разі, якщо знайдено активну декларацію - розірвати всі шляхом зміни статусу на INACTIVE.

В разі, якщо parent_declaration_id для запиту на декларації не вказано - розірвати parent_declaration з вказаною причиною reason = 'auto_reorganization'.

Створити декларацію

1. Перевірити authentication_method_current

   SELECT authentication_method_current
   FROM declaration_requests
   WHERE id = {:id}
   
   

   1. Якщо "type" = "OFFLINE"

      1.  встановити статус декларації "PENDING_VERIFICATION"

      2. встановити причину на 'offline'

   2. якщо "type" = "OTP" - встановити статус декларації "ACTIVE" 

   3. якщо "type" = "NA" - перевірити parent_declaration_id, якщо заповнено то встановити статус декларації "ACTIVE"

2. Перевірити мітку на персоні 'no_tax_id'

   1. якщо 'no_tax_id'=true та parent_declaration_id заповнені

      1. встановити статус декларації "PENDING_VERIFICATION"

      2. встановити причину на 'no_tax_id'

   2. якщо ‘no_tax_id’=true та parent_declaration_id заповнені - встановити статус декларації "ACTIVE"

3. Створити нову декларацію шляхом додавання нової сутності до таблиці декларацій ops_db без declaration_id.

   1. якщо є доступний запис в таблиці декларацій з тим самим id та declaration_request_id, повернути ok до IL