Problem:
The Student Summary Tab was not displaying the student’s current SAP status.

Cause:
The Student Summary Tab was displaying the most recently received data, regardless of whether or not Regent was using that data for the student’s actual Satisfactory Academic Progress (SAP) status.

Fix:
Regent records the SAP status on each payment period. The Student Summary Tab displays the SAP status from the most recent non-Historic payment period with an end date in the past (prior to today’s date). If the student’s first payment period has an end date in the future, Regent displays the SAP status for the first non-historic payment period.

Testing:
Load SAP data and package a student with a process that does a SAP check such as the Modify Academic Plan (MAP) wizard. Ensure the student has a SAP record created and visible in the SAP Wizard. Refresh the Student Summary Tab. Confirm the Student Summary Tab displays the most recent SAP record for the most recent past payment period. Find another student who has their first payment period starting in the future. Load SAP data and MAP that student to create a SIS-Historic SAP record. Confirm the Student Summary Tab displays the Historic SAP record.

Problem:
Some students with less-than-half-time (LTHT) enrollment levels were awarded from a fund. In Fund Setup. The fund was configured with an ‘Amount Per Payment Period’ and a minimum enrollment level of at least Half-Time.

Cause:
Regent did not apply the minimum enrollment levels when determining eligibility for the ‘Amount Per Payment Period’ grid. The Fund Setup screen, ‘Amount Per Payment Period’ grid was incorrectly requiring amounts. Additionally, the system was using the incorrect date ranges when applying the configured amounts and enrollment levels.

Fix:
When the ‘Amount Per Payment Period’ grid is configured with enrollment levels, Regent correctly applies the minimum and maximum enrollment levels when determining eligibility. The Fund Setup screen does not require amounts. The system uses the correct date constraints for Payment Period Start Date and Effective Date ranges. Additionally, the system removed the fund constraints so the ‘Amount Per Payment Period’ grid may be used for fund types of Federal Work Study (FWS) or Federal Supplemental Educational Opportunity Grant (SEOG).

Testing:
In Fund Setup, configure a Fund with enrollment levels in the ‘Amount Per Payment Period’ grid. Confirm the system allows saving rows in the grid with non-overlapping enrollment levels, and without entering any minimum or maximum amounts. Update the grid to have Payment Period Start Date and Effective Date constraints. Reload RNA setup. Package an eligible student from the configured fund in a current or future term. Confirm the award is packaged according to the configuration. Reduce the student’s enrollment level to below the minimum enrollment level in a payment period. Package the student. Confirm the system zeroes out the award in the affected payment period.

Problem:
In the SAP Wizard, if a student previously had a Historic SAP record, when a user added a new Manual SAP record for a future term, the wizard unexpectedly combined the new Manual record with the historic student SAP record.

Cause:
The SAP Wizard did not correctly display the new record when the Manual SAP record was added. The SAP Wizard also had some display problems when students had Historic student SAP records.

Fix:
The SAP Wizard displays SIS records along with Manual SAP records for future terms. The Source column also displays the actual source of the Student SAP record. Manual SAP records for AY1 and later are no longer mistakenly labeled Historic. The code also gets the data more efficiently for displaying in the SAP wizard.

Testing:
Test using test students who do not currently have any SAP data. Load a Historic SIS-provided SAP for a historic SAP policy prior to the student’s start date in Regent Award. Package the student using a process that includes a SAP check, such as the Modify Academic Plan wizard (MAP). View the SAP Wizard. Confirm the system displays the historic student SAP record. Load additional SAP data for a Calculated SAP policy. MAP the student. Confirm the SAP Wizard displays both the Historic SAP data and the new Calculated student SAP record. Add a Manual SAP record for a future term. Confirm the SAP Wizard displays the Manual SAP record in addition to the calculated and historic student SAP records.

Problem:
At a school with a Calculated SAP policy, Regent did not apply the SAP Status from SIS-provided Historic SAP records received prior to the student’s Academic Plan in Regent. The bug behavior was slightly different depending on whether ‘Auto-Generate SAP Node from Student GPA’ was enabled.

Cause:
When Regent checked for the initial SAP status, the system did not properly add the Historic student SAP Record to the list of Student SAP Records to save to the database.

Fix:
Regent includes the Historic student SAP Record when saving to the database.

Testing:
Testing will need two separate rounds of testing with different configuration. First, configure two SAP policies, with one historic SIS-provided SAP, and another with Calculated SAP. For the initial round of testing, set ‘Auto-Generate SAP Node from Student GPA’ to Yes. Reload RNA Setup. Import an SBL for a student as follows: the SBL contains a SIS-provided SAP node with a SAP date and SAP Review Period End Date dated within the SIS-provided SAP policy dates prior to the student’s first Academic Plan in Regent; and the student cumulative GPA value would result in a different SAP status than the SIS-provided SAP node’s status. Package the student with a process that includes a SAP check, such as the Modify Academic Plan wizard (MAP). View the SAP wizard. Confirm the system created a SIS provided historic SAP record matching the SIS provided SAP record status and dates. Import a new SBL for the student, with a later SBL Created date that falls during the Calculated SAP policy range, with a different cumulative GPA value, and without the SBL SAP node. MAP. View the SAP wizard. Confirm the system created an auto-generated SAP matching the cumulative GPA and with a SAP date matching the SBL created date on the SBL file.

For the second round of testing, configure ‘Auto-Generate SAP Node from Student GPA’ as No. Reload RNA Setup. Import an SBL with a historic SIS-provided SAP record for a SAP Review Period End Date within the SIS-provided SAP Policy date range, with the SAP Date dated later than the original SIS-Provided Historic SAP record. MAP. Confirm the system displays the new SIS-provided SAP record with the new SAP date. Import a new SBL for the student, with a later SBL Created date than the student’s current Calculated SAP record, that falls during the Calculated SAP policy range, with a different cumulative GPA value, and without any SBL SAP node. MAP. View the SAP wizard. Confirm the system did not create a Calculated student SAP record. Finally, import a new SBL with a later SBL date and containing a calculated SAP node. MAP. Confirm Regent creates a Calculated SAP record for the imported Calculated SAP node data.

Problem:
Regent canceled a student’s Subsidized and Unsubsidized loans when the student had eligibility in the single term.

Cause:
The system incorrectly cancelled eligible loans when a student’s Grade Level regressed and the loans were configured in Fund Setup with ‘Award Full Eligibility for Eligible Periods Only’ as False/unselected.

Fix:
Regent calculates the correct eligible amount when ‘Award Full Eligibility for Eligible Periods Only’ as False/unselected and the student’s eligibility is reduced due to grade level decrease.

Testing:
Test with Subsidized and Unsubsidized funds set to ‘Award Full Eligibility for Eligible Periods Only’ as False/unselected. Reload RNA Setup if needed. Package the affected undergraduate student who has a single-term loan period and has fewer total units than previously packaged, resulting in a lower grade level. Confirm the Subsidized loan amount correctly matches the Remaining Need in the single-term loan period. Confirm the Unsubsidized loan amount is awarded to the Remaining Cost of Attendance in the single-term loan period. Confirm the loan amounts do not exceed the limits for the student’s updated grade level.

Problem:
At a school prior to going live with Regent, a test student had a ‘FA Suspended’ Historic SAP status. Regent canceled awards in the very first term, but unexpectedly still awarded the second and later terms.

Cause:
The system reset the effective SAP status for later terms when the student only had a Historic SAP status.

Fix:
Regent applies the Historic SAP status to later terms. The system does not reset the effective SAP status.

Testing:
Use a test student who has a valid ISIR, does not currently have any SAP status, and has their first payment period starting in the future. Ensure the school has a SIS-provided SAP policy that covers the dates prior to the student’s first term. Ensure Institution Setup, ‘SAP FA Suspension cancels all future aid' is “Yes.” Reload RNA setup if needed. Load a SIS-provided SAP node node on the SBL with a date during the SIS-provided SAP policy and prior to the student’s first term. Package the student with a process that includes a SAP check, such as the Modify Academic Plan (MAP) Wizard. View the Awards tab, select the first term, and expand the Enrollment Details. Confirm the student now has a SAP status of ‘FA Suspended’ for the previous payment period. Confirm the student has all Title IV aid canceled for the first term and all subsequent terms in their Academic Plan.

Problem:

"The Award is unable to be processed at this time. Something is preventing RNA from processing the Award" blocking error in Add Award Wizard that was observed during adding Sub/Unsub loan into 23-24 FAY.

Cause:

Regent Award was not able to associate Award with existing valid enrollment record

Fix:

The condition was added to align validation logic on 'Add Award' screen

Testing:

Find the affected student. Navigate to ‘Awards'. Try to add Sub or Unsub via 'Add award’ for FAY23-24. no error should occur.

Problem:
For some students with an R2T4 calculation, the CBHD (Could Have Been Disbursed) amounts were doubled.

Cause:
The system applied the CHBD amount twice for some students configured with ‘Include Loan Disbursements Cancelled for Below Half Time Status’ set to “Yes.“

Fix:
The system calculates CHBD amounts correctly.

Testing:
Testing may need a time machine. Test with a date during the period when an affected R2T4 occurred. Navigate to an affected student in the term in which R2T4 (Return to Title Four) took place. Reverse the existing R2T4. Create a new R2T4 for the student. Confirm that CHBD amounts are not doubled.

Problem:

Some students were going through a cancel and recreate process having attendance in a term. The system was cancelling already paid loans.

Cause:

During Gen 1313, the system did not take into account the value of Attemped Program Applicable Units .

Fix:

The code change was applied so that the system will take into account Gen 1313 when the value of Attempted Program Applicable Units is greater than zero.

Testing:

Navigate to an affected student on an instance with a time machine, set time machine to fall in necessary payment period (where issue occurred). Make sure that student have paid loans, otherwise pay them. Withdraw student from courses for that payment period and make Modify Academic Plan. The system should not cancel already paid loans.

Problem:
A Regent Access scheduled process failed to create a data file for export using the saved parameters. When users ran the process manually, the data file was created correctly but the Process Log entry still incorrectly showed the default values under the Saved Parameters tab.

Cause:
For scheduled processes, Regent did not correctly load the saved parameters. The system always used the default values instead. The Process Log’s ‘Selection Parameters’ also used the default values.

Fix:
Regent has updated the Loading data to load all parameters.

Testing:
At an affected Regent Access client, ensure several Saved Parameter Sets are configured with different values and Update the Saved Parameter Sets. Schedule the processes to run. After the processes run as scheduled, view the Process Log entries. Confirm the Process Log Selection Parameters field displays the actual parameters that were used. Note the data, such as the number of records in the export files. Create a test account and start a new Regent Access application. Run an export process manually using non-default values that would result in exporting the new application. Confirm the new application is exported. Confirm the number of records includes the new application. View the Process Log’s Selection Parameters tab. Confirm the Selection Parameters tab displays the actual parameters that were used for the manual Export Process.

Problem:

Tuition cost items were not calculated properly at terms

Cause:

The range of the all the academic years was not being considered by Regent Award properly. It did not handle correctly the enrollments at Academic Years with BBAY modifications that caused cost items calculation failures

Fix:

Code changes were made to ensure that all enrollments within AYs are included into COA calculations and handled by the system correctly

Testing:

Find the affected student. Run the packaging. Review COA and tuition cost items (2023 UG) amounts within the terms. The tuition cost items should be zeroed out. But calculated basing cost items setup

Problem:

YRP Pell was split into multiple small disbursements for unknown reason, although disbursement schedule showed one disbursement of 100%

Cause:

While processing award’s data, the system had the rounding issue that caused new disbursement creation

Fix:

The condition causing the issue during the rounding was removed

Testing:

Find the affected student eligible for YRP. Run packaging. Verify the results. The system should not create multiple YRP disbursements

Problem:
When students had old loan data with blank Loan Period dates, Regent created Overlapping Academic Years (OAYs) with dates of 1/1/0001.

Cause:
Regent did not check for blank dates in the Loan Aggregate Detail data table when creating OAYs.

Fix:
Regent checks for the Loan Period start and end dates when creating OAYs.

Testing:
Package a student who has an older loan with blank Loan Period dates in the History tab, Loan Aggregates sub-tab. Confirm Regent does not create any Overlapping Academic Year (OAY) for that loan.

Problem:

Negative Loan Cost of Attendance is shown for Unasub loan for COD export process although the real COA is positive

Cause:

Regent Award allowed negative values for COA related properties during the calculations

Fix:

The logic was updated to exclude negative values at COA calculations

Testing:

Find the affected student. Run COD export. Verify that DirectLoanAttendanceCost field has no negative vlaues

Problem:
The system incorrectly built the Academic Plan for Scheduled Academic Year (SAY) students who each had a non-substantially equal (NSE) Program Change. The new programs were not placed in the expected new Academic Year (AY), e.g., the new Master’s program was not placed in the next AY with the same dates as the previous AY.

Cause:
The system incorrectly processed the middle year NSE program change for the Scheduled Academic Year (SAY).

Fix:
The system correctly processes this type of Program Change.

Testing:
Find an affected student. Run a script to roll back the most recent Program Change, e.g. RS-14748; and if needed, remove the program using the Program Management Wizard (PMW). Import a new Student Batch Load (SBL) file with Program Change data for the new program. Execute Modify Academic Plan (MAP). Process the Program Change as NSE. Confirm the new Master’s program is in a new AY with the same dates as the previous AY.

Purpose of Script:
This build script ensures Regent Award is using updated course data for all students upon upgrade. In some cases, resource conflicts at the database level might have caused deadlocks and stopped the Course Enrollment Rollup (CE Rollup) process from completing. Some students might have had pending data changes, such as new course information from the Student Batch Load (SBL) process. For the affected students, the system could not update information such as total unit values.

Data Changed by the Script:
The script identifies any students that have course data changes or other SIS-provided data that was loaded but was not yet fully processed. The script then runs the Course Enrollment Rollup (CE Rollup) process for those students. The CE Rollup process updates the unit totals and other information.

How to Access the Script:
The script is included in the deployment of the certified release of Regent Award. Each customer will receive this script update automatically when they upgrade to the certified release.

How to Test the Script:
Before upgrading, find an affected student who had SBL data loaded in a failed CE Rollup process, where the student’s current course data do not match the unit totals displayed on the Academic Plan screen. Perform the upgrade. Refresh the Process Log. Confirm the Process CE Rollup process is Complete. View the affected student. Repackage the student using the Modify Academic Plan wizard (MAP). Refresh the Academic Plan screen. Confirm the total units match the course data.

Title: Data View Updates per 6.5.0.0 Release

Tickets: RS-25984;

Description:

The following Data Views were created per changes to tables:

• dataExtract_EnrollmentCostItem_View_v001
• dataExtract_CostGroup_View_v005
• dataExtract_Document_View_v009
• dataExtract_Institution_View_v016
• dataExtract_InstitutionPortal_FinancialAid_View_v006
• dataExtract_Location_View_v013
• dataExtract_PaymentPeriod_View_v005
• dataExtract_RegentFundAwardDisbursementData_View_v002

See the Customer Zone Knowledge Base topic Regent Award Data View Data Dictionary