Open

Method is used for approve or reject employee request.

See service specification

Authorize

1. Verify the validity of access token

2. Check user scope employee_request:update in order to perform this action

   1. In case error - return 401 error

Check action in request

1. if action = APPROVE, add user new role

2. if action - REJECT, update employee request status on REJECTED 

Update employee request status to REJECTED

Invoke WS to update employee request status with parameter 'action'='reject' 

See service specification

Get Employee Request Details

Invoke WS Get Employee Request by ID for further employee creation

 See service specification

Create user in Auth

Create user in Auth

Create/Update employee

Open

1. Search party_id by tax_id (tax_id or passport_number) and birth_date for deduplication Party

   1. If found, update object party - Update party WS

   2. If not found, - Create object party 

2. Update Party.  See specification

   1. The following fields can't be changed:

      1. tax_id (tax_id or passport_number) 

      2. birth_date

   2. If doctor object in ER is null, don't update party.eductions/party.qualifications/party.specialities/party.science_degree. Otherwise update those objects.

   3. if about_myself/working_experience is null or empty string - don't update correspondent fields in parties.

3. Create party WS. See specification

   1. create related entity party-user in PRM 

4. Chech employee_id in request

   1. if employee_id is exist in request, Update employee.

   2. if  employee_id is not exist, Create employee.

5. Update employee. See specification

   1. The following fields can't be changed:

      1. employee_type

      2. legal_entity_id

      3. start_date

   2. if employee_type = 'DOCTOR', update doctor object

   3. if one of next fields were changed:

      1. first_name

      2. second_name

      3. last_name
         find contracts with contractor_owner_id=$owner_id and status='VERIFIED'. Set ops.contracts.is_suspended=true

6. Create new employee. See specification

   1. If (employee_type = OWNER || employee_type = PHARMACY_OWNER) : deactivate all other records with the employee_type = OWNER
      or employee_type = PHARMACY_OWNER for the legal_entity,
      where new owner is creating:

In case new OWNER was added find contracts with contractor_owner_id=$old_owner_id and status='VERIFIED'.

Set ops.contracts.is_suspended=true

Create related entity party-user

Create related entity party-user

It can be only one pair user_id-party_id.

party_id cannot be updated for the user_id.

Check that there is no records in party_users for the stated in employee_request user_id

If not - return 422 error: "ЦЯ EMAIL-АДРЕСА ВЖЕ ЗАЙНЯТА ІНШИМ КОРИСТУВАЧЕМ"

Add role

Add user role by invoke service - название метода

Role is assigned according to employee_type

See service logic

See service spesification

Update employee request status to APPROVED

Invoke WS to update employee request status with parameter 'action'='approve' 

See service specification

Send Email

Send email with successful registration using WS - Send Message (TBD)

Temporarily use Postmark

Submit party on verification

Create or update existing record in party_verifications table for a party according to logic in sections below. Also, set:

• updated_at = now()

• updated_by = user uuid

• inserted_at = now() (for new records)

• inserted_by = user uuid (for new records)

DRFO registry verification

Set to party verification record as ready for online verification with DRFO registry:

• drfo_data_id = NULL

• drfo_data_result = NULL

• drfo_synced_at = NULL

• drfo_verification_status = VERIFICATION_NEEDED

• drfo_verification_reason = ONLINE_TRIGGERED

Then party will be verified online with DRFO registry via separate process:DRFO data synchronization for Parties_EN

DRACS death acts registry verification

Set to party verification record as ready for online verification with DRACS death acts registry:

• dracs_death_verification_status = VERIFICATION_NEEDED

• dracs_death_verification_reason = ONLINE_TRIGGERED

• dracs_death_online_status = READY

Then party will be verified online with DRACS death acts registry via separate process: Online verification of Parties with DRACS death acts registry_EN

DRACS name change acts registry verification

If party is created, set values in party_verifications table:

• dracs_name_change_verification_status = VERIFICATION_NOT_NEEDED

• dracs_name_change_verification_reason = INITIAL

If party is updated and persons dracs_name_change_verification_status = ‘VERIFICATION_NEEDED’:

• Check existence of verification candidates for party_id with status = ‘NEW’ and entity_type in (‘dracs_marriage_act', ‘dracs_divorce_act’, ‘dracs_change_name_act’) in the party_verification_candidates table:

  • if found:

    • Compare updated party data with them using following processes for each entity_type:

      • for dracs_marriage_act - RC_Offline comparison of marriage acts with Persons (DRACS 2.0) | Step 3. Marriage act comparison process

      • for dracs_divorce_act - RC_Offline comparison of marriage acts with Persons (DRACS 2.0) | Step 3. Divorce act comparison process

      • for dracs_change_name_act - RC_Offline comparison of marriage acts with Persons (DRACS 2.0) | Step 3. Change name act comparison process

    • If a candidate does not already match the updated party’s data - deactivate them, set:

      • status = ‘DEACTIVATED’

      • status_reason = ‘PARTY_UPDATED’

      • updated_at = now()

    • If no more active candidates for name change left - update party DRACS change name verification status, set values:

      • dracs_name_change_verification_status = VERIFIED

      • dracs_name_change_verification_reason = AUTO_OFFLINE

      • dracs_name_change_verification_comment = null

Calculate cumulative verification status

Calculate parties cumulative verification status based on parties verification status in each stream: DRFO registry verification, DRACS death acts registry verification, DRACS name change acts registry verification according to logic described at Party verification status model | Cumulative verification status

• Set calculated status to parties.verification_status field

• Create StatusChangeEvent for each active employee related to a party in event manager with new verification status if it was changed