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

Мета

Цей WS призначений для створення контракту від юридичної особи власником або адміністратором. Перед створенням запиту документи повинні бути завантажені. Тоді запит може бути схвалений або відхилений стороною НСЗУ. Після цього, МІС повинен схвалити запит від їх сторони (актуально лише для договору капітації). Якщо запит було схвалено з обох сторін, його можна підписати.

Використовуючи цей сервіс, можна створити договір реімбурсації, а також договір капітації. Різниця між цими двома типами контрактів описана в Моделі даних договору реімбурсації (див відповідний розділ на публічній сторінці Confluence ).

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

Вхідні дані - це підписані дані у форматі PKCS7. Дані повинні бути розпаковані та перевірені за допомогою схеми (Capitation Contract_request) або схеми JSON (Reimbursement Contract_request) Для того, щоб змінити підписаний контракт, слід надіслати номер_договору. У цьому випадку start_date та end_date взяті з існуючого контракту і не повинні бути присутніми в payload (за винятком випадків пролонгації контракту.

Для цих випадків перевірки описані нижче). Якщо цей запит на контракт змінюється на інший, ідентифікатор попереднього запиту на контракт (Створити запит на контракт # попередній_запит) повинен бути надісланий як payload.

Авторизація

Перевірити валідність доступу токену:
1. в разі помилки 401 ('Invalid access token')
Перевірити набір даних contract_request:create перед виконанням дії
1. в разі помилки 401 у відповіді ('Invalid access token')
Якщо BLOCK_UNVERIFIED_PARTY_USERS є true, тоді перевірити дані співробітника на свіпадіння наступним умовам: verification_status != NOT_VERIFIED або (verification_status = NOT_VERIFIED та updated_at <= current_date - UNVERIFIED_PARTY_PERIOD_DAYS_ALLOWED):
1. в разі неспівпадіння - повернути 403 ("Access denied. Party is not verified")

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

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

Валідація цифрового підпису (ЦП)

Нам потрібно перевірити ЦП базуючись на формі власності юридичної особи. ЦП може належати фізичній особі-підприємцю або юридичній особі. Як і попередня версія ЦП, він може містити tax_id у полі EDRPOU, а не в DRFO, перевірка повинна виконуватися, як описано нижче:

Взяти client_id з token
Знайти prm.legal_entities по client_id
Перевірити EDRPOU або DRFO співпадіння prm.legal_entities.EDRPOU
1. Перевірити, що EDRPOU в деталях Certificate не пусто
  1. Перевірити, що Certificate_details.EDRPOU=prm.legal_entities.EDRPOU
2. в разі, якщо валідація a. не проходить - Перевірити, що DRFO в деталях Certificate не пусто
  1. Поміняти DRFO та prm.legal_entities.EDRPOU на великі літери
  2. Перевірити та поміняти DRFO та prm.legal_entities.EDRPOU на Кирилицю
  3. Перевірити та поміняти DRFO та Cyrillic на Кирилицю
  4. Перевірити, що Certificate_details.DRFO=prm.legal_entities.EDRPOU
в разі, якщо валідація не проходить - згенерувати помилку 422
Перевірити, що SURNAME в деталях Certificate дорівнює LAST_NAME в Party
1. Взяти user_id → user_parties.party_id → parties.last_name та порівняти з прізвищем з ЦП
  1. Поміняти prm.parties.LAST_NAME та Certificate details.SURNAME на великі літери
  2. Перевірити та поміняти prm.parties.LAST_NAME та Certificate details.SURNAME на Кирилицю
  3. в разі, якщо валідація не проходить - згенерувати помилку 422

Валідація DRFO

Взяти parties.tax_id використовуючи party_users.party_id від user_id.
Порівняти DRFO в Certificate з party.tax_id
1. Поміняти DRFO та TAX_ID на великі літери
2. Перевірити та поміняти DRFO та TAX_ID на Кирилицю
3. Перевірити та поміняти DRFO на Кирилицю
в разі, якщо валідація не проходить - згенерувати помилку 422

Перевірка ролей

Завантажити з token:

Перевірити client_id (is_blocked=false)
1. в разі помилки згенерувати код 403 ('Client is blocked')
Перевірити контрагента в договорі contractor_legal_entity активний чи призупинений
1. в разі помилки згенерувати код 403 - ('Client is not active')

Валідація запиту

Валідація contract_type:
1. юридична особа з типом в (MSP,PRIMARY_CARE) може створити тілько договір капітації, юридична особа з типом в (PHARMACY) може створити тілько договір реімбурсації
  1. в разі помилки 409 - "Contract type "{contract_type}" is not allowed for legal_entity with type "{legal_entity_type}" "
Валідація previous_request_id
1. вибрати id from contract_request де id=$.previous_request_id
  1. якщо дані не знайдено згенерувати помилку 422 ("previous_request does not exist")
2. Перевірити previous_request status не рівно ('SIGNED')
  1. в разі помилки згенерувати код 422 ('In case contract exists new contract request should be created')
3. Перевір contractor_legal_entity_id попереднього запиту рівний до contractor_legal_entity_id поточного запиту
  1. в разі помилки згенерувати код 422 ('Previous request doesn't belong to legal entity')
4. Для договоду реімбурсації: Перевірити що id_form з $.previous_request_id рівний до id_form для запиту
  1. в разі помилки згенерувати код 422 ('Id_form from previous request is not equal to id_form from request')
Валідація contractor_divisions
1. для договору капітації:
  1. Превірити, що підрозділ належить до legal_entity та divisions.status='active'
    1. в разі помилки згенерувати код 422 переглянути $divisions ('Division must be active and within current legal_entity')
  2. Перевірити, що підрозділ в масиві зустрічається тільки один раз
    1. в разі помилки згенерувати код 422 переглянути $divisions ('Division duplicates')
2. для договору реімбурсації повернути помилку 422 ('schema does not allow additional properties')
Валідація start_date
1. перевірити формат start_date (^(\\d{4}(?!\\d{2}\\b))((-?)((0[1-9]|1[0-2])(\\3([12]\\d|0[1-9]|3[01]))?|W([0-4]\\d|5[0-2])(-?[1-7])?|(00[1-9]|0[1-9]\\d|[12]\\d{2}|3([0-5]\\d|6[1-6])))?)?$)
  1. в разі помилки згенерувати код 422 error $start_date ('"expected \"<start_date>" to be a valid ISO 8601 date"')
2. рік в start_date повинен співпадати з поточним або наступним роком (current+1).
  1. в разі помилки згенерувати код 422 error $start_date ('Start date must be within this or next year')
Валідація end_date (Примітка. Дані валідації дійсні для випадків, коли contract_number не проходить перевірки в запиті. Якщо contract_number перевірено, проводяться валідації з 10.п)
1. перевірити формат end_date (^(\\d{4}(?!\\d{2}\\b))((-?)((0[1-9]|1[0-2])(\\3([12]\\d|0[1-9]|3[01]))?|W([0-4]\\d|5[0-2])(-?[1-7])?|(00[1-9]|0[1-9]\\d|[12]\\d{2}|3([0-5]\\d|6[1-6])))?)?$)
  1. в разі помилки згенерувати код 422 error $end_date ('"expected \"<end_date>" to be a valid ISO 8601 date"')
2. рік повинен $end_date може бути наступним роком після 'start_date' якщо повний період договору не перевищує 1 року.
3. $end_date повинна бути більше або рівнятися $start_date
  1. в разі помилки згенерувати код 422 ('The end_date should be greater or equal than the start_date')
4. різниця між $end_date та $start_date повинна бути не більше ніж 1 рік (365 або 366 днів)
  1. в разі помилки згенерувати код 422 ('The difference between end_date and start_date is more than one year')
Валідація contractor_owner_id
1. Перевірити employees.employee_id=contractor_owner_id та client_id=employee.legal_entity_id та employee_type в ('OWNER', 'ADMIN') та status='APPROVED' та is_active=true
  1. в разі помилки згенерувати код 422 Error ('Contractor owner must be an active OWNER or ADMIN and within current legal entity in contract request')
Якщо в напиті було надіслано contract_number:
1. перевірити структуру номеру договору XXXX-1234-5678-C , де:
  1. XXXX - порядок: номер + літери з переліку (A, E, H, K, M, P, T, X)
  2. 1234-5678 - рандомного згенерований номер та літери A, E, H, K, M, P, T, X.
2. перевірити, що договір з даним contract_number
  1. в разі помилки згенерувати код 422 ('Contract with such contract number does not exist')
3. перевірити, що договір не в статусі 'TERMINATED'
  1. в разі помилки згенерувати код 409 ('Can not update terminated contract')
4. employee_divisions, start_date, end_date не можуть бути оновлені. Якщо є активний договіп з таким contract_number зкопіювати start_date, end_date та contractor_legal_entity_id з уже діючого договору. Це не можливо зробити через запит.
  1. в разі помилки згенерувати код 422
5. перевірити підтверджений contract_type такий же, що і в діючому договорі з номером =contract_number
  1. в разі помилки згенерувати код 409 ('Submitted contract_type does not correspond to previously created content`)
6. для запитів для договорів капітації та реімбурсації:
  1. якщо $contract_number та $end_date проходять перевірки в запиті:
    1. $end_date повинна бути більше або рівна $start_date
      1. в разі помилки згенерувати код 422 ('The year of end_date should be one year greater or equal to start_date')
    2. $end_date повинна бути меньше $end_date попереднього договору та меньше або дорівнювати даті плюс 3 місяці
      1. в разі помилки згенерувати код 422 ('The end_date should be greater than of the previous contract and less than or equal to three months')
  2. якщо $contract_number w/o $end_date проходять перевірки в запиті:
    1. $end_date береться з попереднього договору.
7. для договору реімбурсації:
  1. перевірити id_form такий же
    1. в разі помилки повернути 409 ('Submitted id_form does not correspond to previously created content`)
  2. якщо medical_programs відповідає - перевірити згідно опису в п.13 нижче
Валідація contractor_payment_details:
1. якщо payer_account не дорівнює ^UA[0-9]{22}$ або ^UA[0-9]{27}$ -> MFO повинен запитуваись
Валідація id_from з довідника CONTRACT_TYPE (для договору капітації) та REIMBURSEMENT_CONTRACT_TYPE (для договору реімбурсації) :
1. в разі помилки згенерувати код 422 ('value is not allowed in enum')
Валідація - відсутні інші активні (VERIFIED) договори, створені даним legal_entity_id за даний period(contract_request.start_date <= contract.end_date and contract_request.end_date => contract.start_date) тим самим contract_type та id_form (для договору реімбурсації)
1. в разі помилки згенерувати код 422 ('Active contract is found. Contract number must be sent in request')
Для договору капітації: Валідація external_contractors
1. Перевірити external_contractors.divisions.id наявна для contractor_divisions.id
  1. в разі помилки згенерувати код 422 $divisions ('The division is not belong to contractor_divisions')
2. Перевірити external_contractors.contract.expires_at>start_date
  1. в разі помилки згенерувати код 422 $contract.expires_at ('Expires date must be greater than contract start_date')
3. Встановити external_contractors.legal_entity_id='client_id'
4. division_id з external_contractors блоку повинна бути належна до юридичної особи яка включається до договору капітації. В external_contractors.legal_entity_id необхідно вказати юридичну особу counter-party для даного division_id.
Для договору капітації: Валідація external_contractor_flag:
1. якщо external_contractors не null тоді external_contractor_flag повинен бути true
2. якщо external_contractors не null тоді external_contractor_flag повинен бути false
  1. в разі помилки згенерувати код 422 $external_contractor_flag ('Invalid external_contractor_flag')
3. якщо external_contractors не був відправлений в запиті тоді встановити external_contractor_flag до false.
Для договору реімбурсації: Валідація medical_programs:
1. Перевірити, що всі medical_programs з submitted ids існують
  1. в разі помилки згенерувати код 422 переглянути $medical_programs[...] ('Reimbursement program with such id does not exist')
2. Перевірити, що medical_programs з підтвердженим id це активна програма
  1. в разі помилки згенерувати код 422 переглянути $medical_programs[...] ('Reimbursement program is not active')
3. Перевірити, що всі медичні програми з вказаним MEDICATION type:
  1. в разі помилки згенерувати код 422 переглянути $medical_programs[...] (‘Program with such id is not a reimbursement program')
4. Перевірити, що medical_programs з підтвердженим id відповідає до id_form згідно наведеного переліку:

id_form	medical_programs
PMD_1	REIMBURSEMENT_CONTRACT_REQUEST_MEDICAL_PROGRAM_IDS_DOSTUPNI_LIKY
INSULIN_1	REIMBURSEMENT_CONTRACT_REQUEST_MEDICAL_PROGRAM_IDS_INSULIN
ND_1	REIMBURSEMENT_CONTRACT_REQUEST_MEDICAL_PROGRAM_IDS_NETSUKROVYY_DIABET

в разі помилки повернути код помилки 422 $medical_programs[...] ('Medical program is not allowed for this action')
Примітка. Для id_form=INSULIN_1 та PSYCHIATRY дві програми повинні бути вказані.
1. в разі помилки повернути код 409 $medical_programs ('The composition of medical programs does not correspond to the allowed composition')
Перевірити список медичних програм в масиві на відсутність дублів id:
1. в разі помилки повернути код 409 $medical_programs (‘The list of medical programs contains duplicates')

Визначити первісний договір (опціонально)

В разі, якщо запит містить параметри '$.contract_number':

знайти договір, що відповідає '$contract_number', передається:
1. якщо відстній договір з зазначеним номером договору, згенерувати помилку 422 ('Contract with such contract number does not exist')
2. якщо договір в статусі 'Terminated', згенерувати код 409 ('Can not update terminated contract')
встановити parent_contract_id значення як contract.id

Пошук запитів, що очікують на розгляд

Перевірити, що є в наявності

для того ж contractor_legal_entity_id
для того ж періоду [start_date, end_date]
статус в ('NEW', 'IN_PROCESS','APPROVED', 'NHS_SIGNED', 'PENGIND_NHS_SIGN')
id_form

В разі, якщо такий запит відсутній - змінити цей статус на 'TERMINATE'

Зберегти запит на договір

Додати запис до IL.contract_request в статусі 'NEW'

встановити - contractor_legal_entity_id=$client_id

Зберегти підписаний договір до сховища

Отримати url для завантаженого договору.

Параметр	Джерело
timestamp	:TIMESTAMP
resource_name	:INITIAL_CONTRACT_REQUEST
resource_id	:CONTRACT_REQUEST_ID
action	'GET'
bucket	'CONTRACT_REQUEST'

Завантажити підписаний договір до сховища.

RC_Create Contract Request_UA