Reorganize Legal Entities_UA

Ціль

Даний сервіс (WS) призначений для створення взаємозв'язку реорганізованої юридичної особи співробітником НСЗУ з використанням цифрового підпису (DS).

Основні положення

1. Це метод на graphQl використовується тільки в панелі адміністрування НСЗУ.

2. Тільки автентифіковані та авторизовані співробітники НСЗУ з відповідним скоупом може реорганізувати юридичну особу.

3. Запит повинен бути підписаний цифровим підписом (DS).

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

Вхідні параметри

Вхідними параметрами являються підписані дані в форматі PKCS7. Дані повинні бути розпаковані та верифіковані за допомогою схеми Json.

На основі типу реорганізації, підписані дані (signedData) повинні містити наступні поля:

типи реорганізації ACCESSION, MERGING, DIVIDING, SEPARATING

Поля для підпису:

Тип реорганізації TRANSFORMATION

Поля для підпису:

Валідації

Авторизація

• Перевірити валідність токену доступу(існує)

  • в разі помилки - повернути 401 (“Invalid access token”)

• Перевірити, що токен дійсний(expires_at => now())

  • в разі помилки - повернути 401 (“Invalid access token”)

• Перевірити скоупи користувача на можливість виконання даної дії (scope = 'legal_entity:merge')

  • в разі невалідних скоупів - повернути 403 (“Your scope does not allow to access this resource. Missing allowances: legal_entity:merge”)

Перевірити цифровий підпис

• Перевірити, що декодовані вхідні дані підписані

  • в разі помилки - повернути 422 (“document must be signed by 1 signer but contains 0 signatures”)

• Перевірити, що цифровий підпис (DS) валідний та дійсний

• Перевірити, що цифровий підпис (DS) належить користувачу

  • Перевірити, що ЄДРПОУ з цифрового підпису (DS) та legal_entities.edrpou співпадають

    • в разі помилки - повернути 409 (“Signer EDRPOU doesn’t match with requester edrpou”)

  • Перевірити, що ДРФО з цифрового підпису та party.tax_id співпадають

    • в разі помилки - повернути 409 (“Signer DRFO doesn't match with requester tax_id“)

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

1. Перевірити, що вхідні дані містять всі необхідні поля

   1. в разі помилки - повернути 422 ('Required property <field_name> was not present')

2. Перевірити значення type наявний в довіднику LEGAL_ENTITY_REORGANIZATION_TYPES.

   1. в разі помилки - повернути 422 error ('Value is not allowed in enum')

3. Перевірити, що значення reason_date є частиною merged_from для юридичної особи inserted_at по дані та current_date (не раніше ніж merged_from дата реєстрації юридичної особи та не пізніше ніж дата процесу реорганізації).

   1. в разі помилки - повернути помилку 422 ('Reorganization reason date can’t be earlier than legal entity registration date and later than reorganization date')

4. Перевірити merged_from та merged_to для юридичної особи не в рамках процесу реорганізації (запит: select * from related_legal_entities where merged_from_id in ($merged_from_id, $merged_to_id) and is_active=true and type in ('ACCESSION', ‘MERGING’, ‘DIVIDING’); returns empty result):

   1. в разі помилки - повернути 409 ('Reorganized and successor legal entities must not be in the process of reorganization')

5. Перевірити merged_from legal_entity

   1. Перевірити, що merged_from присутній для юридичної особи

      1. в разі помилки - повернути 404 ('Reorganized legal entity was not found')

   2. Перевірити, що сутність merged_from для юридичної особи в статусі ='active' або 'suspended'

      1. в разі помилки - повернути 409 ('Reorganized legal entity must be active or suspended')

   3. Перевірити, що merged_from_legal_entity.name з запиту=legal_entites.name

      1. в разі помилки - повернути 422 ('Invalid reorganized legal entity name')

   4. Перевірити, що merged_from_legal_entity.edrpou з запиту=legal_entites.edrpou

      1. в разі помилки - повернути 422 ('Invalid reorganized legal entity edrpou')

   5. Перевірити, що merged_from_legal_entity.id<>merged_to_legal_entity.id

      1. в разі помилки - повернути 422 ('Reorganized and successor legal entities must be different')

6. (Допустимо для типів реорганізації ACCESSION, MERGING, DIVIDING, SEPARATING)
   Перевірити merged_to legal_entity (кожний об'єкт в масиві).

   1. Перевірити, що кожна сутність merged_to для юридичної особи вказана та унікальна в масиві

      1. в разі помилки - повернути 422 ('Successor legal entities must be different and exist')

   2. Перевірити, що кожна сутність merged_to legal entity в статусі='active' 

      1. в разі помилки - повернути 409 ('Successor legal entity must be active')

   3. Перевірити merged_to_legal_entity.name з запиту=legal_entites.name

      1. в разі помилки - повернути 422 ('Invalid successor legal entity name')

   4. Перевірити merged_to_legal_entity.edrpou з запиту=legal_entites.edrpou

      1. в разі помилки - повернути 422 ('Invalid successor legal entity edrpou')

7. (Допустимо для типів реорганізації TRANSFORMATION)
   Перевірити merged_from.legal_entity_type. Допустимі значення: MSP, PRIMARY_CARE, EMERGENCY, OUTPATIENT.

   1. в разі помилки - повернути 422 ('Invalid legal entity type')

8. (Допустимо для типів реорганізації ACCESSION, MERGING, DIVIDING, SEPARATING)
   Перевірити merged_to.legal_entity_type and merged_from.legal_entity_type. Допустимі значення переміщень дивитися в таблиці нижче.

   1. в разі помилки - повернути 422 ('Invalid legal entity type')

Допустимі значення переміщень для юридичної особи

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

Сервісна логіка залежить від типу реорганізації:

Типи реорганізації Приєднання, Злиття, Поділ

Створити та запустити асинхронні джоби.з типом reorganize_legal_entities

Джоба повинна містити метадані зі значеннями з вхідних параметрів.

Джоба повинна виконувати наступні кроки:

1. Оновити для юридичної особи merged_from активних співробітників (окрім OWNER) до статусу ‘APPROVED’, оновити статус в таблиці співробітників (PRM DB):

   1. встановити статус = ‘REORGANIZED’

   2. встановити updated_at = now()

   3. встановити updated_by = $user_id

2. Оновити для юридичної особи merged_from, що реорганізована, декларації співробітників, оновити дату закінчення строку дії в таблиці декларацій (OPS DB):

   1. встановити end_date = now() + значення конфігураційного параметру LEGAL_ENTITY_REORGANIZATION_TRANSITION_PERIOD

   2. встановити updated_at = now()

   3. встановити updated_by = $user_id

3. Оновити тип користувача для юридичної особи merged_from в таблиці користувачів (MITHRIL DB):

   1. встановити client_type_id = $MSP_LIMITED_ID(3770c4b3-05cd-42d9-8e15-233b193aee86)

   2. встановити updated_at = now()

4. Відмінити всі погодження (approvals) для юридичної особи merged_from в таблиці додатку (MITHRIL DB)

5. Зробити всі токени для юридичної особи merged_from як такі, для яких закінчився строк дії (MITHRIL DB):

   1. встановити expires_at=now(unix time)

   2. встановити updated_at = now()

6. Встановити для юридичної особи merged_from legal сутності договору як такі, що потребують перевірки в таблиці (PRM DB):

   1. встановити is_suspended = true

   2. встановити status_reason = ‘DEFAULT’

   3. встановити reason = ‘Реорганізація СГуСОЗ’

   4. встановити updated_at = now()

   5. встановити updated_by = $user_id

7. Для кожної пари юридичних осіб merged_from та merged_to створитти окрему задачу.
   Задача повинна містити метадані з значенням merged_to_legal_entity з вхідних даних.
   Кожна задача повинна містити наступні кроки

   1. Встановити взаємозв'язок юридичних осіб як запис в related_legal_entities table (PRM DB) у відповідності до Legal Entities Reorganization data model_EN

   2. Зберегти підписний контент до сховища даних для кожного запису related_legal_entities

8. Після того, як всі задачі виконані успішно, оновити статус юридичної особи merged_from в таблиці legal_entities (PRM DB):

   1. встановити status = 'REORGANIZED'

   2. встановити updated_at = now()

   3. встановити updated_by = $user_id

Тип реорганізації Виділ

Створити та запустити асинхронну задачу з типомreorganize_legal_entities

Задача повинна містити метадані зі значеннями з вхідних параметрів.

Джоба повинна виконувати наступні кроки:

1. Оновити для юридичної особи merged_from співробітників з типом ‘DOCTOR’, встановити статус ‘APPROVED’ та party_id для юридичної особи правонаступника, оновити статус в таблиці співробітників (PRM DB):

   1. встановити status = ‘REORGANIZED’

   2. встановити updated_at = now()

   3. встановити updated_by = $user_id

2. Оновити для реорганізованої юридичної особи merged_from декларації співробітників, оновити дату закінчення для декларацій в таблиці (OPS DB):

   1. встановити end_date = now() + value of LEGAL_ENTITY_REORGANIZATION_TRANSITION_PERIOD config

   2. встановити updated_at = now()

   3. встановити updated_by = $user_id

3. Оновити ролі для співробітників юридичної особи merged_from та встановити статус ‘reorganized’ для user_roles таблиця (MITHRIL DB):

   1. встановити role_id = $DOCTOR_LIMITED_ID(c61f8475-6474-4314-a99a-e0eb193f2996)

   2. встановити updated_at = now()

4. Перемістити всі значення для співробітників юридичної особи merged_from в статус ‘reorganized’ в таблиці (MITHRIL DB)

5. Зробити всі токени для юридичної особи merged_from в статусі ‘reorganized’ як такі, для яких закінчився строк дії (MITHRIL DB):

   1. встановити expires_at=now(unix time)

   2. встановити updated_at = now()

6. Встановити для юридичної особи merged_from legal сутності договору як такі, що потребують перевірки в таблиці (PRM DB):

   1. встановити is_suspended = true

   2. встановити status_reason = ‘DEFAULT’

   3. встановити reason = ‘Реорганізація СГуСОЗ’

   4. встановити updated_at = now()

   5. встановити updated_by = $user_id

7. Для кожної пари юридичних осіб merged_from legal entity та merged_to створити окрему задачу.
   Задача повинна містити метадані зі значеннями merged_to_legal_entity з вхідних параметрів.
   Кожна задача повинна виконувати наступні кроки:

   1. Додати запис по взаємозв'язку до таблиці related_legal_entities (PRM DB) у відповідності доLegal Entities Reorganization data model_EN

   2. Зберегти підписаний контент до сховища даних для кожного запису сутності related_legal_entities.

Тип реорганізації Перетворення

Створити та запустити асинхронну джобу з типом reorganize_legal_entities

Джоба повинна містити метадані зі значеннями з вхідних параметрів.

Джоба повинна виконувати наступні кроки:

1. Оновити даними по ЄДР для сутності merged_from дані в полях таблиці legal_entities (PRM DB):

   1. встановити edr_data_id = null

   2. встановити updated_at = now()

   3. встановити updated_by = $user_id

2. Виконати процес upsert_edr_data, який використовується для оновлення або збереження даних з ЄДР для юридичної особи:

   1. Оновити або додати дані edr_data для юридичної особи merged_from по ЄДРПОУ на основі даних по ЄДР у відповіді в таблиці edr_data (PRM DB)

   2. Оновити дані юридичної особи merged_from по ЄДР на основі отриманих даних ЄДР у відповіді в таблиці legal_entities (PRM DB)

   3. Оновити edr_data_id для юридичної особи merged_from в таблиці legal_entities (PRM DB)

3. Встановити статус договору з юридичною особою merged_from як той, що потребує перевірки в таблиці (PRM DB):

   1. встановити is_suspended = true

   2. встановити status_reason = ‘DEFAULT’

   3. встановити reason = ‘Реорганізація СГуСОЗ’

   4. встановити updated_at = now()

   5. встановити updated_by = $user_id

4. Оновити статус юридичної особи merged_from legal в таблиці legal_entities (PRM DB):

   1. встановити status = 'SUSPENDED'

   2. встановити updated_at = now()

   3. встановити updated_by = $user_id

5. Додати запис по взаємозв'язку з merged_from та merged_to data реорганізованої юридичної особи в таблиці related_legal_entities (PRM DB) у відповідності до Legal Entities Reorganization data model_EN
   В разі, якщо запис вже існує (юридична особа була реорганізована з типом TRANSFORMATION раніше), отримати id запису related_legal_entities.

6. Зберегти підписаний контент до сховища даних з наступною назвою: MEDIA_STORAGE_MERGED_LEGAL_ENTITIES_RESOURCE_NAME_<REORGANIZATION_DATE_IN_UNIX_TIME>