Purpose

This job designed for initial and further regular synchronization of Parties with the DRFO registry. In addition, it can work on a schedule to make synchronization of updated Parties via Employee Request whose DRFO data hasn’t been updated online due to technical reasons.

Key points

1. Job can't modify Party data - only existing data is checked

2. Job gets DRFO records using strict Party data, such as last name, first name etc. (w/o any assumptions and data modifications)

3. DRFO record assumed unique within RNOKPP. So if such record does not exists in drfo_data table (MIMIR db) it will be created, if exists - updated.

4. The result of the job is saved/updated DRFO data and linked to the Party.

5. As tax_id and birth_date are unique for the Party, there is no need to check if another parties are linked to the same DRFO data.

Configuration

Data flow

Scheduller starts according to DRFO_PARTY_SYNCHRONIZATION_SCHEDULE cron parameter. It creates oban job that selects Parties that match to some filter parameters. For each the job receives Party’s data on input and returns the result of reconciliation with the DRFO registry to output (details in “Step description” section below):

• If tax ID is valid - the DRFO data is saved/updated and linked to the Party with successful status in party_verifications table

• if tax ID is closed - the DRFO data is saved/updated and linked to the Party, but with unsuccessful status in party_verifications table

• if tax ID is incorrect (not exist in DRFO registry) - the DRFO data is not saved/updated and not linked to the Party. But unsuccessful status sets to party_verifications table.

UML

Open

Source:

Open

Step description

In this section details of UML steps are described

Step 1. Get list of Parties

Get list of Parties that meets the following criteria (using logical AND):

• has at least one active and approved Employee

• prm.party_verifications.drfo_synced_at is null OR drfo_synced_at <= current_date - DRFO_PARTY_VALIDATION_PERIOD_DAYS

• exclude parties who has drfo_verification_status = IN_REVIEW and drfo_verification_reason = AUTO (such status means they has already being processed by the job at the moment)

Order selected records in descending way by:

• drfo_verification_status = VERIFICATION_NEEDED and drfo_verification_reason = ONLINE_TRIGGERED (should be at the top of the list)

Step 2. Call InfoRNOKPPDRFO

Update party_verifications record by party_id:

• drfo_verification_status = IN_REVIEW

• drfo_verification_reason = AUTO

Check party’s RNOKPP - invoke RPC call with third-party service https://e-health-ua.atlassian.net/wiki/spaces/RNOKPP/pages/17271128443/DRFO+Trembita+methods_ph2_EN#Info%D0%A0N%D0%9E%D0%9APPDRFO using following request params:

• RNOKPP = prm.parties.tax_id

• last_name = prm.parties.last_name

• first_name = prm.parties.first_name

• middle_name = prm.parties.second_name (skip if empty)

• date_birth = prm.parties.birth_date

Step 3. Create or update drfo_data

If RNOKPP check in Step 2 was successful and result=0 returned. Get record from mimir.drfo_data table by rnokpp:

• if not found - create a record.

• if found - updated the record.

Step 4. Update Party

Invoke the Step If party_verifications.drfo_verification_status still IN_REVIEW

After DRFO record was stored in Step 3 - update party_verifications record by party_id:

• drfo_data_id = mimir.drfo_data.id

• drfo_data_result = 10. The value according to DRFO_RESULT dictionary.

• drfo_synced_at = date and time when synchronization has been performed (current datetime)

• drfo_verification_status = VERIFIED

• drfo_verification_reason = AUTO

Step 4.1. Update Persons

Invoke the Step If person_verifications.drfo_verification_status is not IN_REVIEW

If active Persons linked to the same drfo_data_id (person_verifications table), then compare person’s data with drfo data: last_name, first_name, middle_name and date_birth. If these data are different, update person_verifications record:

• drfo_verification_status = VERIFICATION_NEEDED

• drfo_verification_reason = ONLINE_TRIGGERED

• drfo_data_id = null

• drfo_data_result = null

• drfo_synced_at = null

Step 5. Create or update drfo_data

If RNOKPP check in Step 2 was unsuccessful and result=2 returned. Create/update record as described in Step 3, but with setting info_result = 2

Step 6. Update Party

After DRFO record was stored in Step 5 - update party_verifications record by party_id:

• drfo_data_id = mimir.drfo_data.id

• drfo_data_result = 12. The value according to DRFO_RESULT dictionary.

• drfo_synced_at = date and time when synchronization has been performed (current datetime)

• drfo_verification_status = NOT_VERIFIED

• drfo_verification_reason = AUTO

Step 6.1. Update Persons

If active Persons linked to the same drfo_data_id (person_verifications table), then compare person’s data with drfo data: last_name, first_name, middle_name and date_birth:

• If these data are different, update person_verifications record:

  • drfo_verification_status = VERIFICATION_NEEDED

  • drfo_verification_reason = ONLINE_TRIGGERED

  • drfo_data_id = null

  • drfo_data_result = null

  • drfo_synced_at = null

• Else:

  • drfo_verification_status = NOT_VERIFIED

  • drfo_verification_reason = AUTO

  • drfo_data_id = mimir.drfo_data.id

  • drfo_data_result = 12. The value according to DRFO_RESULT dictionary.

  • drfo_synced_at = date and time when synchronization has been performed (current datetime)

Step 7. Update Party

If RNOKPP not found or party was not identified in DRFO: result in (1, 4, 42) returned after Step 2 - update party_verifications record by party_id:

• drfo_data_id = null

• drfo_data_result = 11, 14 or 142 according to value of DRFO_RESULT dictionary.

• drfo_synced_at = date and time when synchronization has been performed (current datetime)

• drfo_verification_status = NOT_VERIFIED

• drfo_verification_reason = AUTO

Step 8. Rollback party verification status

If technical error: result = 3, error in (1000, 1004), timeout, etc. returned after Step 2 - the Party is considered unprocessed.

If party_verifications.drfo_verification_status still IN_REVIEW:

• rollback to previous drfo_verification_status and drfo_verification_reason (that was set before IN_REVIEW in Step 2)