Problem:
In Disbursement Schedule Setup, Programs sub-tab, when an administrator saved changes, the screen did not appear to respond. The Save button was still clickable and allowed saving the changes multiple times.

Cause:
The screen did not disable the Save button when the system was still saving changes.

Fix:
The screen disables the save button when the system is saving changes. The screen displays a gray overlay and stops accepting input until the changes are saved. The screen then goes into View mode.

Testing:
In Regent Award, authenticate with a user role with permissions to Edit Disbursement Schedule. Navigate to the Disbursement Schedule, Programs sub-tab. Edit the disbursement schedule’s selected programs. Add and remove many programs. Click the Save button exactly once. Confirm the system disables the Save button after clicking once. Confirm the screen blocks additional input with a visual gray overlay. Wait for the screen to change to View mode. Refresh. Confirm the list of selected programs are matching the changes. Reload RNA Setup before packaging with the changed programs.

Problem:
A school could not Export Student Transactions (EST) due to errors EST-0059 or “the student needs to be packaged,” even after repackaging students multiple times.

Cause:
Several different users at a school had updated the same set of configuration settings over several hours. However, the system unexpectedly took many more hours to save all the changes. The EST errors occurred due to the delay in persisting all the new configuration changes to the database.

Fix:
Regent analyzed many configuration screens for possible inefficiencies when saving changes to the database. Regent updated many screens with faster code. For example, when a Disbursement Schedule is saving multiple changes to the selected Programs, the system first makes a list of all the changed program selections, and then saves all the changes together at once. Previously, that screen was saving each individual changed program to the database one at a time. Separately, Regent also has improved logic for marking a student as being queued for repackaging after configuration is changed.

Testing:
Many configuration screens were updated with faster code for saving changes; refer to the list below. Testing needs to confirm the system correctly saves all new configuration changes, and only those changes, to the database. It might be helpful to take a screenshot of the previous configuration settings to compare against the new changed settings. Testing also needs to confirm the changes are saved quickly enough to allow repackaging a student with the updated configuration and successful EST. Remember to always reload RNA setup to apply any configuration changes before repackaging, and click Refresh if needed to view updates.

To test: In a test environment, identify a student who has unpaid disbursements ready to EST. Keep a browser window open with the student’s Academic Plan visible. Open a separate browser for the Export Student Transactions screen and select the student but do not yet Export. In a third browser window, make configuration changes and Save per the list below. Refresh to view the configuration changes. Confirm the system saved the new changes and did not update any other settings. Reload RNA Setup. Go back to the student’s Academic Plan and repackage using the Modify Academic Plan wizard (MAP). View the student Summary Tab and Refresh until the Last Packaged date is updated. Switch to the Export Student Transaction screen and EST the student. Confirm the student is not blocked with errors EST-0059 or a message saying the student needs to be packaged.

The following configuration screens were updated:

1. Disbursement Schedule Setup, Sites sub-tab
2. Disbursement Schedule Setup, Programs sub-tab
3. Institution Setup, General tab
4. Campus Setup, General tab
5. Program Setup, Sites sub-tab
6. Program Setup, Terms/Enrollment Levels sub-tab
7. Term Setup, Programs sub-tab
8. Fund Setup, Sites sub-tab
9. Fund Setup, Programs sub-tab
10. Fund Setup, Budgets sub-tab, Sites selection
11. Cost Setup → Cost Groups, selected Site Associations
12. Cost Setup → Cost Groups, selected Program Associations

Problem:
‘Personal Information’ header in Student Demographics section of Master Access Questionnaire was missing the last letter.

Cause:
The code had incorrect spelling.

Fix:
The spelling of “Information” has been corrected.

Testing:
Open a new Access Master document in the Student Experience Portal. Confirm the Personal Information header is spelled correctly.

Problem:
A Fund was configured in Fund Setup to 'Exclude Header/Trailer Terms.’ When students added Summer enrollment, the system unexpectedly increased the amounts in the past Fall and Spring terms.

Cause:
The system did not correctly adjust the cost balances for the ineligible Summer term.

Fix:
The system correctly accounts for costs in ineligible terms.

Testing:
Use the institutional Fund configured with ‘Exclude Header/Trailer Terms’ and packaging to a percentage of COA. Reload RNA setup if needed. Package a student who has an award from that fund and amounts in the Fall and Spring terms, and who does not yet have Summer registration. Add registration for Summer. Repackage the student. Confirm the system calculates the correct, unchanged amounts based on Fall and Spring costs only.

Problem:
A student had an Overlapping Academic Year (OAY) with relatively low loan amounts. Regent awarded separate loans for the the overlap period and the remainder of the Academic Year, with the same Subsidized and Unsubsidized loan amounts in all the terms in the AY.

Cause:
Regent did not correctly check for the calculated eligible amount in the overlap period terms being the same as the normal unadjusted per-PP amount for the whole Academic Year.

Fix:
Regent only creates a separate loan period for the overlap terms if the sum of the overlap term amounts, plus the OAY amounts, would exceed the annual limits. Regent also checks that the student has an active enrollment within the OAY.

Testing:
Ensure configuration is enabled to adjust loan amounts for overlapping years. Package a student who has overlapping loans with amounts from a previous OAY, and the previous loan amounts are low enough that Regent can package normal calculated award amounts in the overlap terms and the remaining terms in the AY. Package the student. Confirm the system creates one Subsidized and one Unsubsidized loan for the year-long default loan period. Confirm the loan amounts are the same throughout all the terms in the AY. Confirm the loan period dates match the full AY dates.

Problem:
In Fund Setup, the ‘Amount Per Payment Period’ configuration settings were unexpectedly blocking multiple rows within the same FAY and same effective dates that had different, non-overlapping enrollment levels. The system also unexpectedly did not start with empty values for the Min/Max Enrollment Units, and unexpectedly blocked unique rows with empty FAY and Effective Dates.

Cause:
Several settings in Fund Setup were not allowing unique combinations of values. The system was still requiring values for FAY, Effective Date range, and Enrollment Units Min/Max when the rows were otherwise configured correctly with non-overlapping, unique configurations.

Fix:
The system includes Enrollment when checking for the unique combination of values in the ‘Amount per Payment Period.’ Specifically, the system looks for non-overlapping ranges for Enrollment Status Min/Max and Enrollment Units Min/Max and uses the enrollment when checking for unique combinations of rows. The Optional fields were also changed to not require values.

Testing:
In a test environment, add and save a new non-Title-IV Fund in Fund Setup. Configure the ‘Amount Per Payment Period’ with several rows having different, non-overlapping, Enrollment Level ranges. Confirm the system allows configuring and saving multiple rows that have different FAY. Confirm the system allows multiple rows per FAY if they are unique by date range, FAY, and enrollment level. Confirm the system allows saving unique rows that have only Enrollment Level selected and have blank values for FAY, Effective Dates, Min and Max Enrollment Units.

Problem:
The Saved Parameter Sets editor did not allow saving changes due to validation errors. The Institution and OPE-ID fields had no values selected.

Cause:
On initial load, the data was missing to display on the user interface when the Saved Parameter Sets editor was opened.

Fix:
The loading procedure was adjusted to display the data correctly.

Testing:
Expand the Processes on the left hand navigation. Select Saved Parameter Sets. Select any saved parameter set, such as TSM or FAH. Click on View/Edit button. Confirm the ‘Institution’ and '8 Digit OPE-ID' fields are populated. If the instance has multiple Institutions, confirm you can search on the Institution menu and OPE-ID values.

Problem:
Regent Award unexpectedly set Sorting Elements and Ranking Elements back to the first selected value when the first selected value was not removed from the table by the ‘Remove All’ button.

Cause:
Regent Award had incorrect logic around ‘Remove’ button.

Fix:
Regent Award is updated to apply the same functionality to ‘Remove’ button as the ‘Remove All’ button.

Testing:
In Regent Award, create a Ranking and Priority with the High School GPA for Sorting Elements. For Ranking Elements, select a Ranking type of Weighted Points. Click ‘Edit’ and change the Sorting Elements and Ranking Elements to Cumulative GPA clicking the ‘Remove’ button.

Problem:
In Document Setup, Document Due Date and Expiration, when the document’s configuration selected the “Year After FAY” for the Year, Regent used the subsequent year after the second year of the FAY for the document’s expiration date, e.g., FAY 2022-2023 used FAY 2023-2024.

Cause:
The system used an incorrect formula for the FAY range calculation.

Fix:
The system uses the correct formula for FAY range calculation.

Testing:
Test by configuring a document to be expired, and try to assign the expired document to a student. In Document Setup, configure a Document with the expiration of “Year After FAY,” similar to the following configuration:

• FAY-scoped Document Requirement, such as the Proof of Identity/Statement of Educational Purpose
• Scope is a single Federal Award Year, such as 2022-2023
• Date Used for Document Due Date Assignment: Static Date
  • Month: January
  • Day: 1
  • Year: Year After FAY
• Date Used for Document Expiration Date Assignment: Static Date
  • Month: January
  • Day: 2
  • Year: Year After FAY

Reload RNA Setup.

To test, take any student and add the document with that expired FAY, such as “2022-2023 Proof of Identity/Statement of Educational Purpose”, for Federal Award Year: 2022-2023. The document should not be assigned. The system should show the validation message: “Document expired.“

Problem:
Multiple bulk change actions on the tasks queue did not apply changes for all selected bulk change actions.

Cause:
When the Task was updated from the queue list with the first of the bulk change operations, its versioning stayed the same, which prevented the saving on the next bulk operation update. The problem occurred for updating tasks when the second and later bulk operations took place.

Fix:
Regent has updated logic to refresh the task versioning before each next bulk update. The change also fixed the proper task updating sequence.

Testing:
Go to Task section > Assigned Task section. Click on a task queue, such as Review ISIR. Select an action and several tasks. Click on “+ Add another bulk change action”. Select the action for the second Bulk change action. Repeat adding another bulk change action. Click on Submit button. Confirm all set actions were applied on the selected tasks. Note, by design, the system will only allow updating the currently visible tasks.

Problem:
The PWD Gross Amount was incorrectly rounded.

Cause:
The code was missing the round to Net logic that occurs prior to calculating the fee.

Fix:
The code was updated to round to Net prior to calculating the fee.

Testing:

Identify an existing student with the rounding issue. Recreate the original R2T4 for the student (ensure a PWD is created). Review and confirm the PWD gross loan amount on the PWD tab is rounding as expected.

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.

Purpose of Script:

Un-delete objects related to a Disbursement record marked as ‘Must Not Delete,’ to eliminate “orphaned” Disbursement records.

Data Changed by the Script:

Previously deleted Payment Period, Enrollment, and AYs related to a non-deleted Disbursement record will be restored.

How to Access the Script: 

Included in 6.3.1.0 release.

How to Test the Script:

Find a Disbursement record sent to COD and subsequently zeroed out. Ensure related Payment Period, Enrollment, and AY records have not been deleted.