Top of ENR | Index | Table of Contents | Feedback |
ENRF5900 - Merge Person with Two IDs
Purpose |
To merge the records of a student with two ID numbers into one ID number. |
|
SubSystem |
Enrolments |
|
Normally Run By | Enrolment Specialist | |
Anticipated Frequency | As required | |
Structure | Blocks | Merge IDs |
Merge Table Name | ||
Information | ||
Action Choice | ||
Buttons | Determine Actions | |
Merge Person IDs |
A person may be inadvertently recorded in the system under two (or more) ID numbers. This form is used to run a process which copies data from one of the ID numbers (Obsolete ID) into a single set of data under the other number (Current ID). Merge IDs block The Merge IDs block is used to record the two ID numbers that are to be merged. The Determine Actions button is then selected to display details of the data to be merged. Users of this function should have an understanding of the data being merged. Merge Table Name block When the Determine Actions button is selected, Callista determines which database tables from both ID numbers are involved in the merge process and displays their Descriptions in this block. Each of these tables can be selected in turn to determine the action(s) to be performed on the data they contain. Information block The Information block describes the information contained under both IDs prior to the merge process. Based on the information displayed here, choices are made as to the actions to be performed during the merge process. Not all data has to be merged. Where data relating to two students is recorded under one ID, it is possible to selectively merge this data into the two correct IDs by performing this process twice, once for each current ID. The block contains four fields, the fields on the left displaying information about data under the obsolete ID, the fields on the right displaying information about data under the current ID. The scroll bar on the extreme left is active when more than two information records exist for a merge table. The scroll bars to the right of each field are active when an information record occupies more than three lines of text. To interpret the data contained in these fields it is necessary to read the highlighted information in conjunction with the highlighted information in the Action Choice block. Action Choice block When information is highlighted in the Information block, the proposed actions to be performed on this information are displayed in the Action Choice block. The choice is then made as to whether or not to perform the action by selecting or deselecting the Perform Action check box. (Default is selected for all actions). Where the system determines that an action is not possible, the reason is displayed in the Action Choice block and the Perform Action check box is deselected. When all actions have been decided, the Merge Person IDs button is selected to perform the process. Successfully merged records are automatically saved and cannot be 'undone'. If the merge is unsuccessful, it is most likely because some data under the obsolete ID conflicts with data under the current ID. Callista provides detailed messages which enable the user to determine the reasons for the failed merge and take action to either:
Where a merge is unsuccessful, the Obsolete and Current Records remain in their pre-merge state. |
The Merge IDs block contains:
The Merge Table Name block contains:
The Information block contains:
The Action Choice block contains:
|
Rules/Notes:
|
To
merge the records from two ID numbers under one of those numbers using this form:
If the merge process is unsuccessful, error messages are displayed advising of the problem. Either:
Or:
|
Rules/Notes:
It is not possible to merge two IDs in BOTH directions, and an obsolete ID cannot subsequently be merged with another ID. When the merge process fails to copy any part of the obsolete data to the current ID, the whole process 'fails' and no obsolete data is transferred. Callista can identify many instances where data cannot be merged and reports on each in the Action Choice block. The Perform Action check box is automatically deselected in these cases. If the merge process fails, solutions should be sought from those action choices with the Perform Action check box selected. In most cases validations are disabled when merge data is inserted. Some tables can only be merged after other related tables have been successfully merged, for example, Student Unit Attempt data must be merged before Student Unit Attempt Outcomes can be merged. When some tables are merged then their related child records will also be merged, for example, Admission Application. The following Precedent details are included as part of the merge process:
For tables that include Start and End Date fields, options may be available to allow the records to be be merged in various ways. See the 'Start-End Date Options' section, below. |
Copy Disability Type details from Obsolete to Current:
PERSON_ID | DISABILITY TYPE | |
---|---|---|
1234 | MOBILITY | Obsolete ID |
2468 | SIGHT | Current ID |
The merged records will be:
PERSON_ID | DISABILITY TYPE | |
---|---|---|
1234 | MOBILITY | Obsolete |
2468 | MOBILITY | Current ID |
2468 | SIGHT | Current ID |
An Alternate ID record of Person ID Type OBSOLETE will be created for the Current Student.
An Alternate ID record of Person ID Type M-I will be created for the Obsolete Student.
If a record exists for the current id with the same start date as the obsolete id, or if the dates for obsolete and current data overlap, then the record cannot be merged.
If both the obsolete person and current person records have open ended dates and the obsolete record start date is before the current record start date date then the option is available to copy the obsolete person data and end date it (as day before current start_dt).
PERSON_ID | ADDR TYPE | START_DT | END_DT | ADDR_LINE_1 | |
---|---|---|---|---|---|
1234 | HOME | 01/01/2009 | Level 1, 17 Madden | Obsolete ID | |
2468 | HOME | 01/01/2010 | Level 4, 27 Brougham | Current ID |
The merged records will be:
PERSON_ID | ADDR TYPE | START_DT | END_DT | ADDR_LINE_1 | |
---|---|---|---|---|---|
1234 | HOME | 01/01/2009 | Level 1, 17 Madden | Obsolete ID | |
2468 | HOME | 01/01/2009 | 31/12/2009 | Level 1, 17 Madden | Current ID |
2468 | HOME | 01/01/2010 | Level 4, 27 Brougham | Current ID |
If both the obsolete person and current person records have the same open ended dates and the current record start date is before the obsolete start date date then the option is available to copy the obsolete person data and end date the current date (as day before the obsolete start date).
PERSON_ID | ADDR TYPE | START_DT | END_DT | ADDR_LINE_1 | |
---|---|---|---|---|---|
1234 | HOME | 01/01/2009 | Level 1, 17 Madden | Current ID | |
2468 | HOME | 01/01/2010 | Level 4, 27 Brougham | Obsolete ID |
The merged records will be:
PERSON_ID | ADDR TYPE | START_DT | END_DT | ADDR_LINE_1 | |
---|---|---|---|---|---|
1234 | HOME | 01/01/2009 | 31/12/2009 | Level 1, 17 Madden | Current ID |
1234 | HOME | 01/01/2010 | Level 4, 27 Brougham | Current ID | |
2468 | HOME | 01/01/2010 | Level 1, 17 Madden | Obsolete ID |
Applicant Records
Where an alternate person id of APPLCNT-ID exists for the obsolete ID, then the creation of the APPLCNT-ID record for the current record triggers a validation preventing the same applicant_id being linked to two students.
To overcome this, the action ‘Copy the Alternate Person ID for the Obsolete ID to the Current ID and delete from the Obsolete ID.' is available and so, during processing the APPLCNT-ID for the obsolete ID is deleted and then created for the Current ID.
If the Current ID has a CHESSN with a status of Active or Provisional, the Obsolete student CHESSN will not be copied across to the current person ID regardless of the status of the obsolete ID.
If the current ID doesn't already have a CHESSN of Provisional or Active but the obsolete ID does, then the CHESSN against the obsolete ID is set to Inactive and the CHESSN in it's pre-inactive state is copied to the current ID.
If the chessn for the obsolete person is inactive then it is not copied to the current ID.
If the current ID has a government citizenship status of 4,5 or 9 then the CHESSN is not copied from the obsolete ID. The CHESSN should remain as it is against the obsolete ID and so no actions are taken.
If a CHESSN has an outstanding request it is not copied from the obsolete to the current id. It is left against the obsolete id in it's current form.
For further details on CHESSN processing in Callista, go to the CHESSN/HEIMS pages listed in the Admissions Subsystem page.
Data from the following tables may be merged during this process. In some cases data in daughter tables will also be merged.
e.g. When data from the STUDENT_PROGRESSION_CHECK table is merged then data from the related STUDENT_PRG_COURSE, STUDENT_PRG_UNIT_SET, STUDENT_PRG_UNIT and STUDENT_PRG_RULE_CHECK may also be merged.
STDNT_UNIT_ATMPT_OUTCOME
STDNT_UNIT_ATMPT_ASS_ITEM
ADMISSION_APPL
ADM_APPL_ACCESS_EQUITY
ADM_APPL_ADM_STEP
ADMISSION_APPL_LETTER
ADM_APPL_LETTER_PHRASE
ADM_COURSE_APPL
ADMISSION_TEST_RESULT
ADMISSION_TEST_SUBSCORE
ADM_COURSE_APPL_INSTANCE
ADM_CRS_APPL_INST_CMNT
ADM_CRS_APPL_INST_NOTE
ADM_COURSE_APPL_INSTANCE_UNIT
AP_PERSON_MATCH
PERSON_DOCUMENT
STUDENT_UNIT_SET_ATTEMPT
PERSON_ADDR
PERSON_IMAGE
PERSON_CONCESSION
PERSON_DISABILITY
PERSON_PRIOR_EDUCATION
PERSON_STATISTICS_VET
PERSON_ENCUMBRANCE
PERSON_SERVICE
PERSON_SERVICE_MULTI_CHC_RESP
DUPLICATE_PERSON_ID
STUDENT_COURSE_TRANSFER
STUDENT_UNIT_TRANSFER
PERSON_CHESSN
PERSON_ENCUMBRANCE_EFFECT
ADV_STND_ORIGIN_INSTANCE
ADVANCED_STANDING
ADV_STND_UNIT
ADV_STND_UNIT_BASIS
ADV_STND_ALT_UNIT
ADV_STND_UNIT_LEVEL
ADV_STND_UNIT_LEVEL_BASIS
STUDENT_COURSE_INTERMISSION
STUDENT_CRS_ATMPT_NOTE
STUDENT_UNIT_ATMPT_NOTE
OUT_CORRESPONDENCE_REF
ACAI_ADVANCED_STANDING
ACAI_ADV_STND_UNIT
ACAI_ADV_STND_ALT_UNIT
ACAI_ADV_STND_UNIT_LEVEL
ENROLMENT_CONFIRMATION
STUDENT_CRS_SPCL_RQRMNT
PROOF_OF_PARTICIPATION
AUS_SCNDRY_EDUCATION
AUS_SCNDRY_EDU_SUBJECT
AUS_SCNDRY_EDU_OTH_SCORE
OS_SCNDRY_EDUCATION
OS_SCNDRY_EDU_SUBJECT
TERTIARY_EDUATION
TERTIARY_EDU_UNIT_ATTEMPT
PREV_PERSON_INSTN
EMPLOYMENT_DETAIL
PERSON_OTHER_QUALIFICATION
HEALTH_CARE_COVER
INTERNATIONAL_VISA
STUDENT_APPEAL
STUDENT_APPEAL_DCMNT
STUDENT_LOAD_VARIATION_DCMNT
STUDENT_LOAD_VARIATION
STUDENT_CRS_ATMPT_DELIVERY_GRP
STUDENT_CRS_ATMPT_DP_OVRD
STUDENT_CRS_ATMPT_DG_UOO_OVRD
SPCL_CONSIDERATION_APPL
Last Modified on 16 May, 2013 1:14 PM
History Information
Release Information | Project | Changes to Document |
15.0.0.3 | 1871 - Precedents - Part 2 | Added information about the merge process including Advanced Standing Precedent data. |
15.0 | 1668 - Merge ID Process | Added further information about the merge process including additional data that will now be merged |
12.1.0.1 | 1400 - Calipso 28759 | Updated link to Callista logo in Header |
12.0.0.2 | 1617 - SV - VU FEE-HELP | Added note about the inclusion of Fee Maintenance, Funding Source Exempt, and Funding Source Comments data. |
12.0.0.2 | 1647 - AVETMISS | Added Govt Industry Code field and note. |
10.0.0.0.0.0 | C20672 | Added 'Note' in first 'Rules/Note' area |