Bio/Demo conversion testing includes the following areas:

• Student Bio/Demo  Person Information - Minimum of 50-100 records
• Student Bio/Demo  Citizenship
  • USA citizenship - Minimum of 50 records
  • Citizenship from supplemental file- Minimum of 50 records
• Birth Country and Location from supplemental file - Minimum of 50 records
• Student Bio/Demo  Visa - Minimum of 50 records
• Student Bio/Demo  Ethnicity - Minimum of 50 records
• Student Bio/Demo  Disability and Accommodation (Cycle 2 and after) - Minimum of 50 records
• Residency (Cycle 2 and after) - Minimum of 50 records including a variety of Residency codes and Residency exceptions
• Emergency Contacts - Minimum of 50 records

The Validation Results and Feedback are due NO LATER THAN on the last  day of the Data Validation Period. It is strongly recommended that issues  are reported EARLY in the validation period and are not held until the  end of the period. Validation Results and Feedback are for reporting  closure of the college's validation activities for the conversion cycle.  To view a list of the validation periods please refer to the timeline topic in the Data Validation Overview - Getting Started Guide.

Questions regarding the data validation activities can be directed to the Functional Analyst or Campus Solutions Lead.

Kyrsten Catlin - Campus Solutions Functional Analyst

• [email protected]
• 360-704-4393

Amanda Hoover -  Campus Solutions Functional Analyst

• [email protected]
• 360-704-1042

Rebecca Poe- Campus Solutions Core Lead

• [email protected]
• 360-704-1062

John Henry Whatley- Campus Solutions Project Manager

• [email protected]
• 360-704-1060

College Validation

Compare the following student Bio/Demo data between PeopleSoft and Legacy

• Name
• Address
• Phone Number
• Email Address
• Gender
• National ID (ex. SSN)
• Date of Birth

It is recommended that colleges validate a minimum of 50-100 records in each of the validation areas listed above using the queries provided or by selecting students based on your own legacy reporting.  Colleges will need to determine what percentage of their legacy data to evaluate to be confident with conversion results.

Names from one of the legacy systems will convert to the Primary Name Type in PeopleSoft.  Former names are not a part of the conversion process at this time.  Existing PeopleSoft records that are updated in conversion will see a new effective dated row for the Primary Name type.

The single Name field in SMS is converted into the separate First Name, Middle Name, and Last Name fields in PeopleSoft. The spaces are used to differentiate between the names, beginning with Last Name, then First Name, and finally Middle Name. Names that do not follow this format were provided by the college via a supplemental conversion file, and will take priority over the name that would have converted from the student legacy system. Any names separated by spaces after the first three will not be converted.

The legacy Admissions screen (SM2001) depicted below shows one source for the Student Name:

A student who is also an employee will have a name source from the PPMS system and it will represent their legal name as displayed on their Social Security Card.  

A student with no admissions record in SMS may have a name source from FAM, based on an incoming ISIR record.

To validate the name information converted to PeopleSoft follow the navigational path and steps below:

PeopleSoft Navigation Path: NavBar Icon > Navigator Icon > Campus Community > Personal Information > Biographical > Names

1. Navigate to the Names page
2. Input the ID, click the Include History checkbox and click Search
3. Click the Names link at the top right of the page
4. Click the Names History link for the Primary Name Type
5. The page will display middle name and any effective dated rows for the names associated with the ID
   • If name data was not updated by a converting record, only one row will display.

Addresses updated in conversion will populate the Address Types as shown below. Existing PeopleSoft records that are updated in conversion will have a new effective dated row for these Address Types.

PeopleSoft Navigation Path: Main Menu > Campus Community > Personal Information > Add/Update a Person

1. Navigate to the Add/Update a Person page
2. Input the ID, click the Include History checkbox and click Search
3. Click the Addresses tab at the top left of the page
4. Click the Edit/View Address Detail link for the Home Address Type

The page will display any effective dated rows for the address associated with the ID

Phone numbers updated in conversion will populate the Phone Types as shown below. If the Stu Day Phone and Stu Eve Phone values coming from a legacy system are the same, then the phone number will only be converted to the Home Phone Type. Phone numbers in PeopleSoft are not effective dated, and an existing phone number can be overwritten for the Phone Types below by a converting record based on the priority logic applied.

The legacy Admissions screen (SM2001) depicted below shows the sources for the Student Phone:

To validate the phone information converted to PeopleSoft follow the navigational path and steps below:

PeopleSoft Navigation Path: Main Menu > Campus Community > Personal Information > Add/Update a Person

1. Navigate to the Add/Update a Person page.
2. Input the ID and click Search.
3. The phone numbers will display towards the bottom right on the Biographical Details tab.

Email addresses updated in conversion will populate the Email Types as shown below. Email addresses in PeopleSoft are not effective dated, and an existing email can be overwritten for the email types below by a converting record based on the priority logic applied.

• Note that if the incoming student legacy record takes priority, the email address inserted will first come from the Alternate Student Email supplemental file provided by the college for the conversion cycle. If the college has elected not to submit the supplemental file, or if a student is not listed in that file, then the email address will be sourced from the Email Address field on the SM5016 Alternate Address screen in the legacy system.

The legacy Alternate Address screen (SM5016) depicted below shows the sources for the Student Email Address:

To validate the email information converted to PeopleSoft follow the navigational path and steps below:

PeopleSoft Navigation Path: Main Menu > Campus Community > Personal Information > Add/Update a Person

1. Navigate to the Add/Update a Person page
2. Input the ID and click Search
3. The email address will display towards the bottom right on the Biographical Details tab

Sex is converted into the Sex field in PeopleSoft. Sex in PeopleSoft is not effective dated, and an existing value can be overwritten by a converting record based on the priority logic applied.

The legacy Admissions screen (SM2001) depicted below shows the sources for the Student Sex:

To validate the sex value converted to PeopleSoft follow the navigational path and steps below:

PeopleSoft Navigation Path: Main Menu > Campus Community > Personal Information > Add/Update a Person

1. Navigate to the Add/Update a Person page
2. Input the ID click Search
3. Sex will display in the Biographical History section toward the top of the page on the Biographical Details tab

National ID (SSN or ITIN) in PeopleSoft is not effective dated, and an existing National ID can be overwritten by a converting record based on the priority logic applied.

The legacy Admissions screen (SM2001) depicted below shows the sources for the Student SSN or National ID:

To validate the National ID information converted to PeopleSoft follow the navigational path and steps below:

PeopleSoft Navigation Path: Main Menu > Campus Community > Personal Information > Add/Update a Person

1. Navigate to the Add/Update a Person page
2. Input the ID and click Search
3. The National ID will display in the National ID section toward the middle of the page on the Biographical Details tab

Date of Birth in PeopleSoft is not effective dated, and an existing Date of Birth can be overwritten by a converting record based on the priority logic applied.

The legacy Admissions screen (SM2001) depicted below shows the sources for the Student Date of Birth:

To validate the Date of Birth information converted to PeopleSoft follow the navigational path and steps below:

PeopleSoft Navigation Path: Main Menu > Campus Community > Personal Information > Add/Update a Person

1. Navigate to the Add/Update a Person page
2. Input the ID and click Search
3. Date of Birth will display in the Personal Information section at the top of the page on the Biographical Details tab

Citizenship data is extracted via conversion activity referred to as C-017. The table below identifies the PeopleSoft field and the source field from legacy. The attached crosswalk document below contains the citizenship values from the CITIZ-STAT legacy field and the numeric value (and its translation) that will be loaded into PeopleSoft on the CITIZENSHIP_STATUS field.

Converting colleges provide citizenship and birth country data as supplemental files for international students. These files are loaded at the time of conversion. The citizenship row inserted into PeopleSoft for the international students indicated in the Country of Citizenship supplemental file is in addition to a “USA” row, if it exists in legacy for that student.

If the student was not provided in the Birth Country supplemental file, then no Birth Country will be added to the student’s record.

• Duplicates are the main cause of errors with Citizenship data. An existing duplicate from the legacy system would need to be resolved by the converting college in the legacy system prior to future conversion cycles.  An existing duplicate in PeopleSoft will be reported to the ERP support team to validate and resolve in PeopleSoft prior to future conversion cycles.  
• Birth Country will only apply from the supplemental file to students converted from SMS.  If the source of Student data is from PPMS and the student appeared in the supplemental file, that data may not convert.
• If your college has an incoming employment record for a student and it takes priority during the conversion, then the student may have a citizenship row for a non-USA country, but will not have a USA citizenship row, as USA citizenship is not converted from employment records.
• If PeopleSoft values do not match what is in your legacy system it is most commonly due to another college's record for the same student taking priority during the conversion process. For steps to determine if this may be the case, please review "Source Tips and Clues" in the "Conversion Backgtorund - Student Bio/Demo - Person Information" section.

Converting colleges should use the supplemental files they provided for citizenship and birth country and select approximately 50 of the records to validate that these were populated as expected in PeopleSoft. Additionally, colleges should verify that the legacy USA citizenship status converted correctly using the provided query in the following section.

Citizenship data in PeopleSoft is not effective dated, and existing citizenship can be overwritten by a converting record based on the priority logic applied.

PeopleSoft Navigation Path: Main Menu > Campus Community > Personal Information > Identification > Citizenship > Citizenship and Passport

1. Navigate to the Citizenship/Passport page
2. Input the ID and click Search
3. Click the View All link in the top right corner

PeopleSoft Query Navigation Path: Main Menu > Reporting Tools > Query > Query Viewer

CTC_VAL_BIO_CITIZENSHIP  Returns citizenship data and PeopleSoft and legacy IDs for converted employees and students converted from your college based on the External System codes entered in the prompts. Refer to the External System table in the “Conversion Validation Steps  Bio/Demo” section for your college’s External System codes.

Birth country data in PeopleSoft is not effective dated, and existing Birth Information can be overwritten by a converting record based on the priority logic applied.

PeopleSoft Navigation Path: Main Menu > Campus Community > Personal Information > Add/Update a Person

1. Navigate to the Add/Update a Person page
2. Input the ID and click Search
3. Click the link for Birth Information in the Person Information section next to Date of Birth

PeopleSoft Query Navigation Path: Main Menu > Reporting Tools > Query > Query Viewer

CTC_VAL_BIO_BIRTH_COUNTRY  Returns birth country data and PeopleSoft and legacy IDs for converted employees and students converted from your college based on the External System codes entered in the prompts. Refer to the External System table in the “Conversion Validation Steps  Bio/Demo” section for your college’s External System codes.

Visa and permit data is extracted via conversion activity referred to as C-018.  The table below identifies the PeopleSoft field and the source field from legacy. Visa type is determined from the value in the CITIZ-STAT legacy field and translated to a visa type per the attached crosswalk document below.

• Some two-digit years in the Visa status date convert to the year 19XX instead of 20XX.
• If a student already exists in PeopleSoft with Visa/Permit data, this is not updated by incoming colleges.

Converting colleges should use the query provided in the following section and select a minimum of 50 records to validate that Visa/Permit status was populated as expected in PeopleSoft.

Ethnicity data is extracted and cross walked to the PeopleSoft value based on the crosswalk attached below. The data is extracted via conversion activity referred to as C-014. The table below identifies the PeopleSoft field and the source field from legacy. The Hispanic flag in PeopleSoft is set to “Y” based on the Census Race Codes that are added to the student’s record in PeopleSoft. The Ethnic Group Crosswalk Table below indicates which Ethnic Groups will trigger the “Y” value. The primary ethnicity flag will be set to “Y” for the value in the CENSUS-RACE-CD legacy field.

• FAM does not store ethnicity data. If the record converted from FAM and the student does not have any SMS data, then the ethnicity field will be blank.
• If the Eth Orig legacy field is blank or has a space, then Census Race Codes for the student are not extracted from legacy, and subsequently are not converted into PeopleSoft.
• If PeopleSoft values do not match what is in your legacy system it is most commonly due to another college's record for the same student taking priority during the conversion process. For steps to determine if this may be the case, please review "Source Tips and Clues" in the "Conversion Backgtorund - Student Bio/Demo - Person Information" section.

Converting colleges should use the query provided in the following section and select a minimum of 50 records to validate that ethnicity data was populated as expected in PeopleSoft.

Ethnicity data is effective dated. A student record may have multiple rows for Ethnic Groups, and converting data will be added to the list, if it is not already present. Note that ‘NSPEC’ is not inserted if values already exist on the student’s record. The ‘Primary’ and ‘Hispanic’ flags are not effective dated and may be replaced based on information from converting records.

Navigation Path: Main Menu > Campus Community > Personal Information > Biographical > Personal Attributes > Ethnicity

1. Navigate to the Ethnicity page
2. Input the ID and click Search
3. Confirm that the Ethnic Group code matches legacy

PeopleSoft Query Navigation Path: Main Menu> Reporting Tools> Query > Query Viewer

CTC_VAL_BIO_ETHNICITY  Returns ethnicity data and PeopleSoft and legacy IDs for converted employees and students converted from your college based on the External System codes entered in the prompts. Refer to the External System table in the “Conversion Validation Steps  Bio/Demo” section for your college’s External System codes.

Disability and accommodation data are extracted via conversion activity referred to as C-019. The table below identifies the PeopleSoft field and the source field from legacy.  There are two sets of data that are converted to PeopleSoft: one will convert as a “Disabled” yes/no indicator and the other will convert for that student’s accommodation data.

Diagnosis Code

The extract process converts the legacy values into a series of two-character values that include a number in the first position and a letter value in the second position. If a value from legacy includes a number in the first position, that number and the proceeding letter value will be considered one code and validated against the crosswalk table below. If it is not in the crosswalk, it will be bypassed. Any letter values of “A” through “S” after that will have a corresponding number value assigned just prior to the letter, per the crosswalk table below. All other values will be excluded from the extract. One row for each valid diagnosis code will be inserted into the student’s Accommodation record.

Example 1: A student with the legacy value “2EKQ” would have three diagnosis code rows in the Accommodation record in PeopleSoft: one each for “2E”, “K”, and “Q”. The latter two would be converted to “6K” and “7Q”.

Example 2: A student with the legacy value “6NE” would have two diagnosis code rows in the Accommodation record in PeopleSoft: one each for “6N” and “E”. The latter would be converted to “2E”.

Example 3: A student with the legacy value “2NS” would have one diagnosis code row in the Accommodation record in PeopleSoft for “S”. “2N” is not a valid value in the crosswalk below and would be excluded, and “S” would be converted to “8S”.

Accommodation Crosswalk Table:

• If the disability flag = Y on a preexisting record, this value will not be removed if an incoming record takes priority where no disability flag exists.
• If PeopleSoft values do not match what is in your legacy system it is most commonly due to another college's record for the same student taking priority during the conversion process. For steps to determine if this may be the case, please review "Source Tips and Clues" in the "Conversion Backgtorund - Student Bio/Demo - Person Information" section.

Converting colleges should use the queries provided in the following section and select a minimum of 50 records to validate that disability and accommodation data was populated as expected in PeopleSoft.

The Disabled flag (checkbox) in PeopleSoft is not effective dated, and an existing value of “N” (or no checkmark) can be overwritten with a “Y” (checkmark) from disability data from a converting record based on priority logic applied.

PeopleSoft Navigation Path: Main Menu > Campus Community > Personal Information > Add/Update a Person

1. Navigate to the Add/Update a Person page
2. Input the ID and click Search
3. Click on the Regional tab
4. Converted person records should have the Disabled box check at the bottom left of this page

Accommodation Data is not effective dated, and Diagnosis Codes from converting records are added to those that may have existed previously in PeopleSoft based on the priority logic applied.

Navigation Path: Main Menu > Campus Community > Personal Information > Health Information > Accommodation Data

1. Navigate to the Accommodation Data page
2. Input the ID and click Search
3. Validate that the Diagnosis Code matches legacy based on the crosswalk above
   • Students may have more than one code in PeopleSoft, click View All to view all converted codes

PeopleSoft Query Navigation Path: Main Menu > Reporting Tools > Query > Query Viewer

CTC_VAL_BIO_DISAB_ACCOM  Returns disability and accommodation values, along with PeopleSoft and legacy IDs for converted employees and students converted from your college, based on the External System codes entered in the prompts. A new row is returned by this reported for every Diagnosis Code that exists on a student’s record. Refer to the External System table in the “Conversion Validation Steps  Bio/Demo” section for your college’s External System codes.

Residency data is extracted via conversion activity referred to as C-019. All converted students’ residency data is converted with their last term or last 4 quarters/terms if they were enrolled in the last year.

• If the student has duplicate records in legacy, then residency fails to load. Duplicates will be sent to colleges for cleanup.
• If there is an error in the student’s program/plan stack, then residency fails to load.
• If there is a mismatch between students’ program/plan stack career and the residency career, then residency fails to load.
• If the student had no enrollment in legacy or if the enrollment fails to convert, then residency fails to load.
• Applicants with Prior Enrollment - Residency (RES STAT and FEE PAY STAT) is extracted from SM5018 for applicant students with prior enrollment, even if more recent admissions data has been entered on SM2001. The ctcLink project team will identify the students with different RES STAT and FEE PAY STAT codes and correct their records during go-live weekend.

Converting colleges should use the query provided in the section below and select a minimum of 50 records to validate that residency data was populated as expected in PeopleSoft.

• Residency Code
• Students with International residency
• Students with residency exceptions
  • For students who converted with Out of State, Undetermined, or International Residency who also had a residency exception, Residency will reflect the Legacy residency value but the Tuition Residency field will be updated to In State based on the residency exception code.

Emergency contact data is extracted via conversion activity referred to as C-016 and consists of the Emergency contact Name and Phone number.

• If PeopleSoft values do not match what is in your legacy system it is most commonly due to another college's record for the same student taking priority during the conversion process. For steps to determine if this may be the case, please review "Source Tips and Clues" in the "Conversion Backgtorund - Student Bio/Demo - Person Information" section.

Converting colleges should use the query provided in the section below and select a minimum of 50 percent of the records to validate that emergency contact information was populated as expected in PeopleSoft.