Purpose

The method is used to approve or reject employee request

Specification

Logic

Open

Sample Request

Input parameters

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

Headers

Наприклад:

Content-Type:application/json

Authorization:Bearer YW5WcFkyVnFkV2xqWldwMWFXTmxDZzpjY1hwWTR0cWRZbGVjNHAxYUdsMXVJ

Request data validation

Check action in request

1. if action = APPROVE, add user new role

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

Processing

Update employee request status to REJECTED

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

See service specification

Sample Request

Get Employee Request Details

Invoke WS Get Employee Request by ID for further employee creation

See service specification

Sample Request

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', 'SPECIALIST' or 'ASSISTANT' 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

Add role

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

Role is assigned according to employee_type

See service logic

See service specification

Sample Request

Update employee request status to APPROVED

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

See service specification

Sample Request

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

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 according to logic described at Party verification status model:

• 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

Response structure

Example:

Post-processing processes

API paragraph not found

HTTP status codes