Introduction

This Business Process Analysis (BPA) and System Configuration document describes the functionality and configuration settings related to the Data Conversion process in Regent Award.  Data Conversion is the process by which multiple disparate sources of data are correlated and imported into Regent Award in order to build an accurate historical and future financial package for students. 

This document defines the following items associated with the Data Conversion process: 

• Expectations of the Data Conversion process 

• Selecting appropriate Academic Years (AY) 

• Inputs and outputs 

• Common Data Conversion issues 

• Specifications for the school’s configuration of the following: 

  • Data requirements  

  • User Roles 

  • Documents 

  • Tasks 

  • Additional Configuration 

Process Overview

The Data Conversion process also referred to as the “Rebuild Process” is the process by which multiple disparate sources of data are correlated and imported into Regent Award in order to build an accurate historical and future financial package for students to align with current SIS. It allows Regent Award to continue awarding and disbursing students who are in the middle of a FAY/Academic Year when the school goes live in Regent Award. Regent Award used the data to assure the student is not over awarded for the open. It also allows the school to continue disbursing undisbursed funds for students who are in open Academic Years at the time of go live in Regent Award. In rare instances, data Conversion s are done to show historical data of a previous FAY for visual purposes only. Bulk and Manual Data Conversion.

The Data Conversion Process will attempt to convert the student population in an automated fashion. The bulk of data Data Conversion is executed by Regent Education as part of the Go-Live process.

Regent Education anticipates a majority of the student population to process without manual intervention. There are many factors that impact the accuracy of the Data Conversion process, therefore a successful data import into Regent Award may result in issues when creating an Academic Plan.

When Regent Award cannot automatically create the Academic Plan through the Data Conversion Process, an entry is created in the “Data Conversion Process Review” queue that alerts the user that manual review is required to reconcile data. There are different categories of issues that require manual intervention. Resolution of these issues can occur pre go-live, at go live or post go-live. Additionally, some issues will require schools to perform SBL changes or alterations to other SIS-generated input. Lastly, issues may also require updated files (e.g. SBL, COD or Import Award file).

The process for those students remaining in the 'Data Conversion Process Review' queue will be manually converted by a member of the school’s Data Conversion team using the Regent Award 'Data Conversion Wizard.'

Iterative Approach

The Data Conversion process is executed by Regent Education several times prior to Go-Live, which will correspond with the execution of the Validation process. The goal of each iteration is to learn from the previous results, make any changes necessary, and re-run the Data Conversion Process with those changes in place.

There are several possible changes required to improve the results of the Data Conversion Process. These changes may include, but are not limited to:

• Configuration changes in Regent Award

• Changes or additions to the Term configuration from the school

• Changes to the SBL including:

  • Historical course information provided

  • Program and term associations

  • Course information

• Updated Pell and COD files

• Changes to the Import Awards file

Regent will provide detailed analysis results after each iteration of the Data Conversion process. This allows both the Regent and school teams to collaborate on changes to improve the results.

Selecting the Appropriate Years to Convert

Prior to the Data Conversion Process, Regent and the school will collaboratively determine the appropriate  Federal Award Year(s) and Academic Years (AYs) to rebuild.  The AY population should ensure there is enough data to support the Data Conversion Process without providing too much data to make the Data Conversion more difficult. 

Multiple factors influence the Data Conversion Process for rebuilding the AYs.  These considerations include: 

• The time of year targeted for Go-Live 

• Financial Aid structure (SAY vs. BBAY1, 2 or 3) 

• Availability of clean data from the Student Information System 

• Existing awarding policies 

• Previous change of academic structure 

Academic Year 0 (AY0)

The purpose of AY0 is to house awards for closed/ historical AY(s). During the Data Conversion Process, Regent Award receives a significant amount of data that helps build the Academic Plan, including a COD Rebuild file and an Import Award file with award information from the school’s Financial Aid Management (FAM) system.  The information is likely a combination of current and historical data.  Regent Award uses all historical, current and forthcoming data to build the Academic Plan for the current and future payment periods. All historical FA information (AYs that have ended; are the past) is combined into Academic Year 0 (AY0).  AY0 is also referred to as a historical AY.  There are cases when a student will have multiple AY0 records, depending on the provided data. For example, when the end of the Federal Award Year (FAY) extends into multiple AY periods therefore a student may have more than one historic AY. 

Student Re-entry

When a student re-enters the school, although the student may not be in Regent Award, the student’s COD rebuild information will already have been imported, as all student rebuild information will be added into the system at go-live. 

To handle a re-entry student on the SBL, one of two things are required.  If the student was already sent into Regent Award, but their active flag was set to “false”, this flag would need to be flipped to “true”.  For students never sent to Regent, their active flag would be set as “true” upon sending.  For both sets of students, all their information, current active program, and course information will need to be sent in the SBL file. 

If the student was not previously sent to Regent, an Import Award file will need to be generated that will contain all the student’s Title IV funds for the corresponding aid year(s).  If the student is re-entering in the middle of an aid year, then the Import Award file will also need to include any institutional, state or other funds. Once the SBL and Import Award data has been sent to Regent Award, the student will need to go through the standard data Conversion process. 

Data Conversion Process Inputs

Data Conversion relies on data from the following sources: 

• COD 

  • YTD Pell Files 

  • COD Rebuild Files 

• CPS 

  • ISIRs 

• Institution- SIS/ AR/ FAM 

  • SBL File 

  • Import Award Files 

  • Import Student Documents  

• Regent Award Data Conversion   

  • Regent Award Configuration  

Open

Sequence of Events 

The Data Conversion Process is performed in a specific sequence to build Academic Plans for the students.  The Data Conversion Process typically follows this sequence: 

• Student Batch Load (SBL)  

• YTD ISIR files  

• YTD Pell files 

• COD Rebuild files 

• Import Award file(s)  

• Document Import file(s)  

• Alignment of Active ISIR file(s)  

• Adjust Auto-Withdrawn Terms Process  

• Align Imported Awards Process  

• Realignment of One-Time Costs Process  

• Alignment of Program Units  

• Update AY0 Awards to Manual Process 

The data imported during the Data Conversion Process matches to the SBL and ISIR files that exist in Regent Award, which creates student Academic Plans based on the Direct Loan data.  If no Direct Loan data is present, the Academic Plan is created based on the program academic calendar type.  

STUDENT BATCH LOAD (SBL) – REQUIRED 

The SBL file is required for the Data Conversion Process.  The SBL must adhere to all the rules outlined in the SBL Specifications documentation.  Additionally, the SBL file must contain the following: 

• Historical course data marked as “transfer,” where appropriate 

• Program and course information for current/ future enrollment 

• Course information for prior enrollment is dependent on the Data Conversion strategy.  

YEAR TO DATE ISIR FILE(S) – REQUIRED 

The Year-to-Date (YTD) ISIR file for each year being rebuilt is required.  These files are requested by the school through CPS.   
YTD Pell Rebuild File(s) – REQUIRED 

As with the ISIR, the Pell Rebuild files are required for each Federal Award Year (FAY) and PELL ID, where applicable.  These files contain the students’ historical Pell Awards and are used in determining the student’s remaining eligibility based on awards previously received. 

These files are requested by the school through COD and provided in a standardized format. 

COD REBUILD FILE(S) – REQUIRED 

The COD Rebuild files are required for each FAY and OPEID, when applicable.  These files contain all loan data for the requested FAYs and are used to create and allow Regent Award to manage the loans and create accurate loan ID(s) from go- live forward.  The file includes disbursement information and adjustments.  

These files are requested by the school from COD and provided in a standardized format. 

IMPORT AWARD FILE(S) – REQUIRED 

The Import Awards file is another required input for the Data Conversion process, which allows schools to provide award information from their AR and/or FAM for both COD and non-COD funds.   

Within the file, schools should provide both COD and non-COD awards in the initial Import Awards file.  By providing the COD awards and their external term ID’s, Regent Award can increase the possibility of automated Data Conversion and create the most accurate Academic Plan.  Subsequent incremental Import Awards files used for on-going processing typically will not contain COD awards. 

Special consideration is given for $0 transactions.  This is a known issue around the COD Rebuild files where students will likely have $0 disbursements randomly associated with their record.  In many cases, these disbursements truly should be $0, but in other cases, there should be a dollar amount associated with the transaction.  Regent Award has no way to differentiate the two scenarios, so this information must come from the school in the Import Award file to achieve a higher probability for automated Data Conversion.  For a legitimate transaction, where the disbursements sum up to the actual award amount, Regent has created a script to not block these scenarios and will not require manual intervention, see Scripts section for Ignore $0 Disbursements when Disbursement Sum equals Award amount script.  

Title IV Funds

When converting students, Regent Award requires that an Import Award file be sent in support of the rebuild files from COD.  The data from the SIS assists in aligning dates with payment periods in Regent Award.  All Title IV awards and supporting disbursements for the FAYs being converted should be provided at the time of data Conversion. 

Institutional Funds

For institutional awards, like scholarships or grants that the school offers, these awards and disbursements should be sent for all FAYs being converted. Schools should consider special considerations for FAY alternative scheduled funds and aggregate limits.  

Manual vs. Automatic Awards

On the Import Award file there is an option to denote an award as being either manual or automatic. This field indicates whether packaging should treat this as a "manual award." If the award is treated as a manual award, packaging will create the award, however Regent Award will not attempt to make any changes during subsequent packaging runs.

If the award is not flagged as manual, Regent Award will adjust eligibility according to configuration settings.  

However, Regent Award will bring in rebuild Title IV awards via the Data Conversion process as non-manual even if they are marked as “manual awards” on the Import Award file. If the school wants to make any Title IV funds manual, Regent can execute a script to mark the necessary awards as manual, post data Conversion.    

Disbursement Records are only allowed to be imported for awards flagged as “manual”. 

BUDGETED FUNDS

For funds that have an associated budget, such as FSEOG, special care needs to be given to be ensure that there is sufficient budget available for the fund(s) at the time of Data Conversion to support import or rebuild awards being converted.  Failure to ensure that sufficient budget is available will result in the budgeted award being canceled and alternative fund(s) being packaged to make up the difference.  Schools also have the option to configure the “Offset Fund Budget Amounts for Import Awards.” If set to “True”, schools will provide Regent with the remaining amount of the budget Data Conversion to be awarded new awards after Data Conversion.

IMPORT STUDENT DOCUMENTS FILE(S) – OPTIONAL

Data Conversion the Data Conversion  process the Data Conversion  process the Data Conversion  process Data Conversion the Data Conversion  process Regent Award has no knowledge of the documents submitted prior to Data Conversion  that satisfy C-Codes or verification group requirements posted to the system used before Regent Award.  Schools may require synchronization of existing document statuses in their SIS/Document Management System with the documents created in Regent Award during the Data Conversion process.  Some documents are automatically created in Regent Award during the Data Conversion process.  For example, documents can be created via ISIR import, packaging or SBL load. The best results for document alignment are achieved using the Document Import process.  

ACTIVE ISIR FILE – REQUIRED

Regent Award follows a specific logic for determining the active ISIR (sometimes referred to as the paying ISIR).  In some cases, a school may have used a logic that differs from Regent Award’s in determining which ISIR is set to active.  A difference in the active ISIR from Regent Award to the SIS could result in a perceived discrepancy in the packaging of the student.  The school has the option at Go-Live, and the iterations leading up to it, to provide an extract with active ISIR information to Regent Award to ensure the active ISIR in Regent Award matches the active ISIR in the SIS. 

Regent has created a series of scripts to synchronize ISIR data and will not require manual intervention, see Scripts section for Active ISIR matching scripts.  

ADJUSTING AUTO-WITHDRAWN TERMS – REQUIRED 

An Auto-Withdrawn term is defined as a term where a student has no registered course data by the configured auto-withdrawn date for that term. Students that have a substantially equal program change in the middle of an open AY can have completed terms marked as "Auto-Withdrawn." This occurs because the units for those terms are associated to a prior program and were potentially sent to Regent Award as internal transfer courses in the SBL file.    

Regent has created a script that identifies the affected population and returns a spreadsheet containing student, program, and payment period data.  Based on the volume of affected students, the user may choose to resolve student cases manually or in bulk. See Scripts section for Adjusting Auto Withdrawn Terms script.  

To calculate the correct cost of attendance, enrollment level, and awarding eligibility, a course adjustment must be created in Regent Award for the affected terms. The course adjustment record requires creation with the appropriate unit totals for each applicable category (e.g. registered program applicable units, census units, etc.). The unit totals for each category are applied to the auto-withdrawn terms for recalculation. 

When a course adjustment is created at the payment period level, a corresponding negative offset should be applied at the program level for the same number of units to prevent double counting towards program completion.  

ALIGNMENT OF IMPORT AWARDS – REQUIRED 

The Alignment of Import Awards Script addresses scenarios when overlapping academic years exist in the Import Award data. The disbursements for FAY based funds (Pell, TEACH, etc.) on the import file are associated to a payment period, but that payment period can exist in multiple AYs. When this occurs, the disbursements are associated to the first occurrence of the payment period, which is not always the correct AY/payment period. This script is run to correct the disbursement’s payment period association based on the AY date provided in the Import Award file. See Scripts section for Alignment of Import Awards Script. 

The process for making the adjustments are as follows: 

1. The Regent Team will run the query on the Regent Award environment. 

2. The Regent Team will provide the school with the output. 

3. The school will review the output to confirm accuracy and provide approval of the query results to the Regent Team.  

4. The Regent Team will run the script to set the proper payment periods as described in the output provided in step 2 above. 

REALIGNMENT OF ONE-TIME COSTS- REQUIRED 

Some schools have one-time costs that are charged to students at a specific point in their program.  An example would be a mandatory technology fee that is charged in the first payment period of the students’ enrollment.  During Data Conversion, Regent Award must have this cost configured for COA purposes for an any new students but would not have the required knowledge of when the actual fee was applied to continuing students.  In these situations, a custom script would need to be developed to be run at the time of Data Conversion to realign when the one-time fee hit a student’s academic plan.  Failure to move these one-time costs would result in artificially inflated costs for a single payment period at the time of Data Conversion. 

ALIGNMENT OF CONFIGURED PROGRAM UNITS  

A manual override is needed to ensure the total program course units submitted on the SBL are less than or equal to the total program units configured for the program in Regent Award.  This is not required for schools that have configured the SBL to send the Program Units Override attribute. 

SET ALL AY0 AWARDS TO MANUAL  

The majority of the time, all AY0 Awards are required to be set to manual.  There are cases when this is not necessary.  For example:  FAY based funds crossing between AY0 and AY1 should not be set to manual if the school wishes to keep those funds automated. 

In the cases where AY0 awards are to be set to manual, this is accomplished by running a database script, which sets a pre-defined subset of Academic Year 0 (AY0) awards to a status of “Manual.”  It ensures rebuild/import awards in an AY0 are not automatically adjusted since they are in closed periods.  Often, enrollment data is missing in these periods, and auto-packaging these awards may result in award adjustments.  Regent Award should not manage paid rebuild disbursements (manual or automatic).  See Scripts section for Set All AY0 Awards to Manual Script. 

Preparation for Go-Live

Several activities will occur prior to go-live to prepare for the Data Conversion.  Those activities are outlined below. 

Blackout Period 

There is a mandatory blackout period as part of the Data Conversion.  The length of this blackout is typically 3 business days, although some business factors can influence this duration.  The blackout period requires no additional processing of loans or Pell to COD, either through the SIS or directly online.  This blackout period allows COD to finalize any pending transactions so that the most current and up-to-date information is reflected on the COD Rebuild and YTD Pell files when requested for Data Conversion.  Failure to adhere to this blackout will result in discrepancies in data and errant packaging of students. 

Training and Practice 

Early testing and execution by the Data Conversion team leader(s) are recommended prior to the Go-Live sequence and for those users with less experience. Regent recommends establishing three tiers of escalation to facilitate issue resolution and to ensure potential issues do not slow overall progress: 

• “Tier 3”- Those individuals involved with testing of the Data Conversion process, training, and extensive knowledge of the process. 

• “Tier 2”- The individuals trained by “Tier 3” that have had training and a good bit of practice of the Data Conversion categories and activity. 

• “Tier 1”- The individuals trained by “Tier 2”/” Tier 3” that may have been trained in some but not all Data Conversion categories. 

Planning and Resources 

During the testing of Data Conversion, the team will begin to get a feel for the complexity of issues and time frame for resolution.  Students stuck in the Data Conversion queue can be categorized and a time estimate can be associated with each category of students based upon the expected volume in a category.  This knowledge can then be used to determine how many resources will be required and for how long. 

Regent recommends that schools plan on centralizing the team as much as possible to allow collaboration and better support.  It is also recommended that schools provide a workspace for each Data Conversion  Team Member with dual monitor capabilities to allow them to look at both Regent Award and the SIS concurrently. 

COD 

Early review and execution of the Data Conversion Process in Regent Award may uncover some issues or changes that must be made prior to Go-Live. Students may have already undergone validation but may require external corrections through COD and/or the SIS.  If changes are made via COD, the changes will take effect after a new rebuild file is loaded. 

SBL 

During the Data Conversion process, it may be determined that data sent from the SIS into Regent Award via the SBL is invalid.  For example, transfer courses sent with incorrect dates will create a conflict in Regent Award when an attempt is made to create an Academic Plan.  Another example is an external term ID from the SIS that does not match the external term ID as configured in Regent Award.  Issues such as these, which originate from SIS generated data and are sent to Regent Award via the SBL, are corrected by the school and often require an update of the code that generates the SBL file. 

IMPORT AWARDS 

There are times when an updated Import Awards file is needed to update current student data.  Typical changes include externalTermID, disbursement amounts, disbursement statuses, award amounts, and award AY.  These changes are made in the SIS, exported out on a new Import Awards file, and used in the next iteration of the Data Conversion process. 

There are typically many changes to data leading up to Go-Live, and the goal is to have them all completed prior to Go-Live.  Should changes need to be made after Go-Live, the school will coordinate with the Regent team to determine the best approach in correcting the data. 

Imports Awards Review Queue 

The “Import Awards Review” queue allows users to evaluate students that received a validation error during the Data Conversion process.  This queue applies to schools that send students’ current and/or historical award and disbursement data in batch via the “Import Awards and Disbursements (XML)” process.  Students in this queue may also be listed in the Data Conversion Review queue.  

The Import Award Review queue displays pre-Data Conversion and post-Data Conversion students. To differentiate between pre-Data Conversion and post-Data Conversion student, users utilize the “Post Data Conversion” flag to filter results to either include or to not include post-Data Conversion students in the queue display. 

REGENT AWARD CONFIGURATION 

Regent Award has numerous configuration options that require exact data matches between the school’s SIS configuration and their unique Regent Award configuration.  It is critical that data such as program and term information are sent to Regent Award on the SBL match what is configured in the environment.  Configuration issues are often found when patterns are identified during the analysis of the Data Conversion process results. 

It is very important that a change control process is in place to identify, seek approval, and implement the noted changes.  It is also equally important that the school verify the implemented change fixes the identified issue and produces the desired results. 

Typically, identification of changes needed to configuration will originate with the Regent Team after a pattern or discrepancy is determined.  The team will work with the school to better understand the rationale behind the original configuration option.  Configuration changes will be retested, and the results reported back to the school. See Institutional Configuration for configured settings. 

Go-Live Sequence

The Go-Live Sequence is a series of events for the process of taking the client live.  There are numerous steps involved in the process, and many of them are dependent on the prior step meaning there is a great deal of linearity.  The school’s policies, procedures, and data all contribute to building a Go-Live Sequence that meets the specific business and technology needs of the client. The Go-Live Sequence will be developed and tested as part of the iterative process of Data Conversion. 

Data Conversion Outputs

Outputs are provided to the school by the Regent Team after each iteration of the Data Conversion process.   

Data Conversion Process Outputs 

The Data Conversion Process Output provides metrics around the Data Conversion results.  The output is compiled into a spreadsheet and provided to the school.  The output results also contain the Data Conversion Queue list as well as the Import Award Review Queue.  These results can be reviewed to determine patterns of errors and a direction for analysis. In many cases review of the Data Conversion exceptions in the Data Conversion queue is sufficient.   

The output includes: 

• A Data Conversion summary provides insight into the overall success of the Data Conversion to include rebuild counts and differences 

• The eligible vs. ineligible students that schools are attempting to convert 

• The eligible and ineligible breakdown and details 

• A comprehensive report detailing Data Conversion information per student is for both the Data Conversion Queue and Import Awards Queue 

 Configuration Settings Outputs 

The Configuration Setting Output identifies unusual or missing configurations, such as a missing CIP code or an unusually configured lengthy break.  The output also identifies data issues ranging from excess units for a student in their selected program to not matching COD grade level.  

Configurations and Key Decisions

Data Conversion Data Requirements 

STUDENT BATCH LOAD FILE 

The Student Batch Load (SBL) file, at the time of Data Conversion , should contain all the data nodes for all students that are defined as active.  This includes the student, academicInformation, courseData and any other pertinent nodes (i.e. for SAP, ATB, Breaks, etc.).   

The Regent Award “Managed on Date” is the earliest Academic Year Start Date of any Data Conversion award (a combination of Academic Year scoped COD Rebuild and Import Award data).  

When preparing to send SBL files for the Data Conversion process, the school should provide all Program History from the Regent Award “Managed on Date” forward.  The school is expected to provide the appropriate historical Program Change data as defined in the Program Change SBL documentation. 

Courses prior to the Regent Award “Managed on Date” should be transferred into either the first term on or after the Regent Award “Managed on Date” or into a Super Term. The first term for each student should be the Payment Period/Term that holds any Academic Year scoped Disbursements. 

Program Start Date 

During the Discovery Phase of the project, the teams collaboratively determine which FAY’s will be rebuilt for the Data Conversion process.  This decision will impact what Program Start Date should be sent over on the SBL.  The rules for the Program Start Date differs from term to non-term. 

Additionally, the Regent Award Program Start Date is the start date of the earliest non-transfer, not withdrawn before course start, course in the SBL File. If the Regent Award Program Start Date for a student is after the Regent Award “Managed On” date, the student has gone through some form of Program Change or Re-Entry.  

• When the Regent Award Program Start Date falls within the student’s first Regent Award Academic Year, then it is likely the student had a Substantially Equal Program Change.   

• For Not Substantially Equal Program changes (or Track Switches) future Payment Periods are put into the next Academic Year.  

• For Regent Award to calculate Awarding Eligibility Regent needs to be able to calculate the Cost of Attendance for all payment periods in the Loan Period / AY. 

Term 

For Term based programs, schools will send over the Program Start Date to coincide with either the first term of the first FAY which is being rebuilt OR the actual start date of the program if it is after the start date of the first term configured in the first FAY being rebuilt.  This approach may result in both external and internal transfer courses. 

Non-Term 

For non-term, the program start date should be sent over as the actual start date of the program.   

At the time of Data Conversion historical course data will need to be sent to Regent Award.  This is done by way of flagging courses as transfers.  There are two types of transfers: external and internal. 

External Transfers 

External transfers are courses that have been taken at a different school that has been transferred in.  These courses and their corresponding information need to be accounted for at the time of Data Conversion. 

Term 

For Term based programs, external transfers taken before the program start date should be sent in to align with the same term as the Program Start Date.  

In the event the courses were taken AFTER the Program Start Date, then the courses should be sent to align with the next term of active enrollment. For example, if terms are setup as Spring 2016, Fall 2016, and Spring 2017.  The student started their program in the Spring 2016 term, but then the student takes a Summer 2016 course at another school. In this case, the course should be marked as an external transfer for the Fall 2016 term. This assumes that the student has active enrollment for Fall 2016.  

Non-Term 

External transfers for non-term programs should be sent in as an external transfer course with the actual dates that courses were taken.   

Internal Transfers 

Internal transfers are courses that have been taken at the school prior to the Program Start Date. 

Term 

Internal transfers for a term-based program should be sent in to align with the first term of the new Program. The Student’s program start date should be the same as the first term’s start date.  This means that the for any internal transfer course, the externalTermId should correspond to the same term as the Program Start Date. The course start and end dates would indicate the dates in which the course was taken and do not need to fall within the first term of the Student’s program. 

IMPORT AWARDS 

When doing a Data Conversion, an Import Award file is required for Title IV Funds.  There are other use cases, specifically for non-Title IV Funds, that may also apply. 

STUDENT DOCUMENT IMPORT FILE 

When doing a Data Conversion, a Student Document Import File is required for Regent Award to appropriately reflect student document requirements and statuses from the SIS.   

ACTIVE ISIR FILE 

When doing a Data Conversion, an Active ISIR File is required for Regent Award to appropriately reflect the student’s active ISIR as determined by the SIS. 

Institutional Configuration 

The Data Conversion process options are set by the Regent team based upon knowledge gained during the Discovery Phase. The options are explained and reviewed with the customer and, based on iterative testing and results of the Data Conversion process, are subject to change. Options are configurable and listed in the Rebuilds and Import Awards section of Institution Setup on the user interface (UI) of Regent Award; however, some options are hard coded via scripts run by the Regent IT Operations team. 

Open

Scripts

Common Data Conversion Process Issues

The following are common issues encountered during the Data Conversion process and how to address them.

No Course Data

Failed to match payment period for import award disbursement

Samples

FAILED TO MATCH PAYMENT PERIOD FOR IMPORT AWARD DISBURSEMENT SAMPLES

Sample 1

Open

Sample 2

Open

Import award disbursement termId is not in the associated student bbay modification

Samples

IMPORT AWARD DISBURSEMENT TERMID IS NOT IN THE ASSOCIATED STUDENT BBAY MODIFICATION SAMPLES

Sample 1

Open

Sample 2

Open

Sample 3

Open

Import Award disbursement's payment period is not contained by the award period or the award period was not found

Samples

IMPORT AWARD DISBURSEMENT'S PAYMENT PERIOD IS NOT CONTAINED BY THE AWARD PERIOD OR THE AWARD PERIOD WAS NOT FOUND SAMPLES

Sample 1

Open

Sample 2

Open

 

ALL AY MODIFICATION RECORDS MUST BE I N THE 'READY TO PACKAGE' STATUS

Samples

ALL AY MODIFICATION RECORDS MUST BE IN THE 'READY TO PACKAGE' STATUS SAMPLES

Sample 1

Open

Sample 2

Open

 

Sample 3

Open

 

One or more Payment Periods could not be resolved for a COD Rebuild award

Samples

ONE OR MORE PAYMENT PERIODS COULD NOT BE RESOLVED FOR A COD REBUILD AWARD SAMPLES

Sample 1

Open

 

Failed to process import award: Failed to create loan period for import award

AY modification skips a term that should exist

Samples

AY MODIFICATION SKIPS A TERM THAT SHOULD EXIST SAMPLES

Sample 1

Open

Sample 2

 

Open

AY modification has an invalid Federal Award Year assigned to it

Samples

AY MODIFICATION HAS AN INVALID FEDERAL AWARD YEAR ASSIGNED TO IT SAMPLES

Sample 1

Open

Sample 2

Open

 

At least one disbursement for this award has a $0 amount that may not actually be $0 and needs to be reviewed

Import award amount doesn't equal the sum of its disbursements.

Import award disbursement has a mismatch between its payment period and loan period FAY

Samples

IMPORT AWARD DISBURSEMENT HAS A MISMATCH BETWEEN ITS PAYMENT PERIOD AND LOAN PERIOD FAY SAMPLES

Sample 1

Open

 

AY Modification's Term was not found in the Program

Samples

AY MODIFICATION'S TERM WAS NOT FOUND IN THE PROGRAM SAMPLES

Sample 1

Open

 

Import award has an invalid federal award year based on its start/end dates

Import award disbursement's paid amount is greater than amount

AY Modification is invalid. A Term that should anchor the AY is not included

Academic plan's Site was not found

 AY modification has an invalid Federal Award Year assigned to it

 Academic Plan contains duplicate Academic year numbers

Academic Plan has no academic years generated

AY Modification for Academic Year is invalid. A Term should be contained in this modification and is not included