Online verification of Parties with DRACS death acts registry_EN

Purpose

This process gets death acts data of specific party from the DRACS registry through Trembita exchange gateway and uses it for further comparison with party.

Key points

1. This process process uses cron parameter to configure its start time.

2. This process process is used to obtain all death acts of specified party from DRACS registry.

3. This process process gets limited amount of parties for synchronization with DRACS death acts registry.

4. This process process uses Oban job processing library as jobs management tool.

Configuration

Service logic

1. Get list of Parties with at least one active employee that must be verified online with DRACS death acts registry by following params from PRM db:

   1. party_verifications.dracs_death_online_status = ‘READY’

2. Sort obtained list by party_verifications.updated_at field in ascending order (first updated party verification record must be first synchronized with DRACS death acts registry).

3. Limit obtained list with DRACS_DEATH_ACTS_PARTIES_SYNC_BATCH_SIZE value from chart params.

   1. if resulting list is empty - end process

4. Get first party from obtained list.

5. Update party_verifications table by party_id:

   1. set dracs_death_online_status = ‘IN_PROCESS’

6. Get parties death acts - perform GetDeathArByFullNameAndBirthDate DRACS method (DRACS Trembita methods | GetDeathArByFullNameAndBirthDate) with following params:

   1. Name = parties.first_name

   2. OnDate = parties.birth_date

   3. Patronymic = parties.second_name

   4. Surname = parties.last_name

7. Get ResultData field from GetDeathArByFullNameAndBirthDate method response and decode it from base64 to get XML file of death acts list.

   1. in case GetDeathArByFullNameAndBirthDate ResultCode <> 0 or connection error or timeout is occured - check that parties dracs_death_online_status = ‘IN_PROCESS’

      1. if true - rollback it in party_verifications table by party_id:

         1. set dracs_death_online_status = ‘READY’

         2. set updated_at = now()

      2. if false - skip this party, go to next party in list (return to p.5)

8. Parse obtained XML file and form death acts list.

   1. in case empty death acts list is returned - check that parties dracs_death_online_status = ‘IN_PROCESS’,

      1. if true - update party_verifications table in PRM db for party_id:

         1. in case dracs_death_verification_status = ‘VERIFICATION_NEEDED’ and dracs_death_verification_reason = ‘ONLINE_TRIGGERED’ - update parties dracs death verification status:

            1. set dracs_death_verification_status = ‘VERIFIED’

            2. set dracs_death_verification_reason = ‘AUTO_ONLINE’

            3. set dracs_death_online_status = ‘COMPLETED’

            4. set updated_at = now()

            5. set updated_by = system_user()

         2. for any other dracs_death_verification_status and dracs_death_verification_reason combination - update parties dracs_death_online_status:

            1. set dracs_death_online_status = ‘COMPLETED’

            2. set updated_at = now()

            3. set updated_by = system_user()

      2. if false - skip this party, go to next party in list (return to p.5)

9. Save each death act from formed list to dracs_death_acts table in transaction according to fields matching (located in the table below)

10. For each death act validate duplicates - check existence of death act in dracs_death_acts table with following conditions: ar_reg_date = ArRegDate and ar_reg_number = ArRegNumber

    1. in case not found - insert new act record to dracs_death_acts table, also add technical data:

       1. set id = autogenerate uuid

       2. set inserted_at = now()

       3. set updated_at = now()

       4. set persons_compare_status = ‘READY’

       5. set parties_compare_status = ‘READY'

       6. set settlement_id from uadresses service using RPC call with following logic:

          1. in case locality is null or locality_type = ‘Район’ - get settlement_id where settlement_name = district and area_name = region

          2. in case locality is not null - get settlement_id where settlement_name = locality and area_name = region

    2. in case found - check that condition op_date = OP_DATE and ar_op_name = AR_OP_NAME is also met for found record

       1. in case condition is met - full duplicate of death acts already exists, update dracs_death_acts table for found record:

          1. set updated_at = now()

       2. in case condition is not met - death act was updated, check that fields of death act from database (according to fields matching, but exclude technical fields ar_reg_date, ar_reg_number, op_date, ar_op_name) were updated in DRACS registry

          1. in case at least one field was updated

             1. save existing record to dracs_death_acts_hstr table

                1. dracs_death_act_id = id of current death act from dracs_death_acts table

                2. dracs_death_act_data = full data of current death act in jsonb format (without technical fields, use fields matching from table below)

                3. inserted_at = now()

             2. fully update existing death act in dracs_death_acts table with new values from DRACS registry

                1. set persons_compare_status = ‘READY’

                2. set parties_compare_status = ‘READY'

                3. set updated_at = now()

                4. set settlement_id from uadresses service using RPC call with following logic:

                   1. in case locality is null or locality_type = ‘Район’ - get settlement_id where settlement_name = district and area_name = region

                   2. in case locality is not null - get settlement_id where settlement_name = locality and area_name = region

          2. in case none of the fields were updated - update dracs_death_acts table for found death act:

             1. op_date = OP_DATE from response

             2. ar_op_name = AR_OP_NAME from response

             3. updated_at = now()

11. Update existing verification candidates according to saved death acts list:

    1. in case saved death act is cancelled (ar_op_name = 2 or 3) or fully updated from DRACS (ar_op_name = 4and existing act was saved to dracs_death_acts_hstr table) - check existence of active verification candidates in MPI db (with person_verification_candidates.status = ‘NEW’, person_verification_candidates.enitity_type = ‘death_act’ and person_verification_candidates.enitity_id = dracs_death_act_id) and in PRM db (with party_verification_candidates.status = ‘NEW’, party_verification_candidates.enitity_type = ‘death_act’ and party_verification_candidates.enitity_id = dracs_death_act_id)

       1. in case found

          1. deactivate verification candidates:

             1. set status = ‘DEACTIVATED’

             2. set status_reason = 'DEATH_ACT_UPDATED'

             3. set updated_at = now()

          2. update persons and parties compare status for death acts with ar_op_name = 2 or 3

             1. set persons_compare_status = ‘PROCESSED’

             2. set parties_compare_status = ‘PROCESSED'

       2. in case not found

          1. update persons and parties compare status for death acts with ar_op_name = 2 or 3

             1. set persons_compare_status = ‘PROCESSED’

             2. set parties_compare_status = ‘PROCESSED'

12. Get only active death acts with ar_op_name = 1 or 4 from obtained list.

    1. in case no active death acts for party were found - check that parties dracs_death_online_status = ‘IN_PROCESS’,

       1. if true - update party_verifications table in mpi db for party_id:

          1. in case dracs_death_verification_status = ‘VERIFICATION_NEEDED’ and dracs_death_verification_reason = ‘ONLINE_TRIGGERED’ - update parties dracs death verification status:

             1. set dracs_death_verification_status = ‘VERIFIED’

             2. set dracs_death_verification_reason = ‘AUTO_ONLINE’

             3. set dracs_death_online_status = ‘COMPLETED’

             4. set updated_at = now()

             5. set updated_by = system_user()

          2. for any other dracs_death_verification_status and dracs_death_verification_reason combination - update parties dracs_death_online_status:

             1. set dracs_death_online_status = ‘COMPLETED’

             2. set updated_at = now()

             3. set updated_by = system_user()

       2. if false - skip this party, go to next party in list (return to p.5)

13. Send parties data and active death acts list to comparison endpoint - check that parties dracs_death_online_status = ‘IN_PROCESS’

    1. if true - proceed with comparison process

       1. Prepare active death acts list for comparison with party according to Offline comparison of death acts with Parties | Step 2. Data preparation and potential candidates select, p.2

       2. Compare party with each active death act using existing logistic regression predicative method as described here: Offline comparison of death acts with Parties | Step 3. Death act comparison process

    2. if false - skip this party, go to next party in list (return to p.5)

14. When found death act with high or average comparison probability (white or grey zone) - check that parties dracs_death_online_status = ‘IN_PROCESS’

    1. if true - proceed with comparison result processing:

       1. Create verification candidate with party_id and dracs_death_act_id in party_verification_candidates table in PRM db according to Offline comparison of death acts with Parties | Step 4.1. White or grey zone

          1. if active verification candidate between party_id and dracs_death_act_id already exists - skip death act

       2. Update parties verification status in party_verifications table based on current dracs death verification status of party:

          1. in case dracs_death_verification_status = ‘NOT_VERIFIED’ - do not update parties dracs death verification status

          2. in case dracs_death_verification_status = ‘VERIFICATION_NEEDED’ and dracs_death_verification_reason = ‘ONLINE_TRIGGERED’ - update parties dracs death verification status:

             1. set dracs_death_verification_status = ‘NOT_VERIFIED’

             2. set dracs_death_verification_reason = ‘AUTO_ONLINE’

             3. set updated_at = now()

             4. set updated_by = system_user()

          3. in case dracs_death_verification_status = ‘VERIFICATION_NEEDED’ and dracs_death_verification_reason = ‘INITIAL’ - update parties dracs death verification status:

             1. set dracs_death_verification_status = ‘NOT_VERIFIED’

             2. set dracs_death_verification_reason = ‘AUTO_ONLINE’

             3. set updated_at = now()

             4. set updated_by = system_user()

          4. in case dracs_death_verification_status = ‘VERIFIED’ - update parties dracs death verification status:

             1. set dracs_death_verification_status = ‘NOT_VERIFIED’

             2. set dracs_death_verification_reason = ‘AUTO_ONLINE’

             3. set updated_at = now()

             4. set updated_by = system_user()

    2. if false - skip this party, go to next party in list (return to p.5)

15. When no death act with average or high comparison probability is found (black zone) - check that parties dracs_death_online_status = ‘IN_PROGRESS’

    1. if true - proceed with comparison result processing:

       1. Update parties verification status in party_verifications table based on current dracs death verification status of party:

          1. in case dracs_death_verification_status = ‘NOT_VERIFIED’ - do not update parties dracs death verification status

          2. in case dracs_death_verification_status = ‘VERIFICATION_NEEDED’ and dracs_death_verification_reason = ‘ONLINE_TRIGGERED’ - update parties dracs death verification status:

             1. set dracs_death_verification_status = ‘VERIFIED’

             2. set dracs_death_verification_reason = ‘AUTO_ONLINE’

             3. set updated_at = now()

             4. set updated_by = system_user()

          3. in case dracs_death_verification_status = ‘VERIFICATION_NEEDED’ and dracs_death_verification_reason = ‘INITIAL’ - do not update parties dracs death verification status

          4. in case dracs_death_verification_status = ‘VERIFIED’ - do not update parties dracs death verification status

    2. if false - skip this party, go to next party in list (return to p.5)

16. When all death acts were fully compared with party, update party_verifications table in PRM db for party_id

    1. set dracs_death_online_status = ‘COMPLETED’

    2. set updated_at = now()

    3. set updated_by = system_user()

17. Select next party from obtained list and return to p.5 of process.

    1. in case no more parties available - end process