Problem:
In pre-release beta testing for Regent Access, when a user tried to create a Parent account, the system gave an Application Error, @userType is not a parameter for snap_User_Create.

Cause:
An old Student Portal (SNAP) code change from several years ago was accidentally omitted from more recent versions of the code. Some new Regent Access functionality in 5.5.0.0 depended on the missing code.

Fix:
The missing SNAP code was updated.

Testing:
In the 5.5.0.0 certified release, test creating a Parent account in Regent Access. Confirm the account is successfully created without the error message.

Problem:
Some awards could not export to COD, causing failures in the COD Export process and the Export Student Transactions (EST) process.

Cause:
The COD Export process created some duplicated records when an institution had a mixture of some awards at sites set up as a Third-Party Servicer. The system could not receive COD responses to the invalid, duplicated records.

Fix:
A one-time data-cleanup script was developed to remove the unnecessary duplicate records. The COD Export process was updated to prevent creating those invalid, non-exported records that incorrectly blocked COD Export and the EST process.

Testing:
In a test environment, run the data-cleanup script list-only to identify affected records. Note the affected students and awards. Run the data-cleanup script to update and remove the duplicate records. Navigate to an affected student and clear any blocking Documents or Tasks. Export the student’s award to COD. Confirm the award is exported successfully. On an award needing to be paid, export the record as a paid disbursement (DRI=true). Confirm the disbursement is successfully exported.

Problem:
At a Regent Award school, some COD Rebuild awards were rejected at COD with Edit 994, missing the <EnrollmentStatus> value.

Cause:
The students had an actual enrollment status of ‘None,’ which cannot be exported to COD as a valid Enrollment Status. Although the awards should be canceled, COD could not process the cancelation due to the missing enrollment status field.

Fix:
For COD Rebuild awards only, if the student’s Enrollment Level is ‘Actual - None’ and cannot be determined from the student's existing award data, then Regent Award will send the default enrollment level value (Full Time, Three Quarter Time, etc.) that is configured in the 'Anticipated Enrollment Level Type' configured in Program Setup.

Testing:
Package an affected student, where the Enrollment Level is ‘Actual-None’ and who has a COD Rebuild award that was rejected by COD with code 994 Enrollment Status. Export the award to COD. Open the COD data file from the Process Log. Confirm the <EnrollmentStatus> value in the Disbursement block is equal to the ‘Anticipated Enrollment Level Type’ configured in Program Setup.

Problem:
Some students' ISIRs were previously Verified by the school. When subsequent ISIRs were loaded in the 5.4.3.0 release, the new ISIRs had the default configured status of “Selected, Not Verified (Inherited)” instead of “Verified (Inherited).”

Cause:
A logic bug overwrote the inherited Verified status with the configured default status of “Selected, Not Verified.”

Fix:
The logic was corrected to preserve the original Verified status for ISIRs that inherit the verification status. In addition, a cleanup script was developed to correct the ISIR status to “Verified (Inherited)” for any ISIRs that were changed due to the bug.

Testing:
Test with a Regent Review or Regent Award school configured to Inherit ISIR verification status. Find a student who has an ISIR that is Selected and was previously Verified. Load a new ISIR transaction that is Selected for Verification. On the student’s ISIR tab, confirm the new ISIR has a status of “Verified (Inherited).”

Problem:
After loading the NSLDS Financial Aid History (FAH) data, some Pell Grant awards were unexpectedly reduced or changed to Year-Round Pell (YRP).

Cause:
The school had different values for the school’s Office of Postsecondary Education Identifier (OPEID) and the school’s Federal School Code (FSC). Regent Award compared the different OPEID and FSC values and interpreted that the students had received Pell Grants at a different institution. Regent Award then reduced the Pell Grant amounts to prevent overawarding the students' Pell in the same FAY.

Fix:
Regent Award was updated to compare the OPEID value, not the FSC value, when determining whether a Pell Grant has been awarded at a different school in NSLDS FAH data.

Testing:
Find a student who is eligible for a Pell Grant, and who has Pell awarded for a current FAY. Load NSLDS FAH data with the same OPEID value in the Attended School Code as the Regent Award school’s OPEID and a different FSC value. Package the student. Confirm the Pell amount is not reduced.

Problem:
At a BBAY term school, the Summer 2021 term disappeared from the Academic Plan when a Substantially Equal (SE) program change was completed.

Cause:
During the program change, Regent Award failed to add the missing Summer term into the new Academic Year.

Fix;
Regent Award’s logic was adjusted to allow the missing Summer term to be queued for processing and added into the Academic Year when the system detects that the Summer term is not on the Academic Plan,

Testing:
Load Student Batch Load (SBL) data with a Program Change. Complete the program change as Substantially Equal. Confirm that Summer 2021 is present in the Academic Year. Confirm if the Spring term appears as the anchoring (first) term in a BBAY, the Summer term always follows.

Problem: Step 1 of MAP Does Not Fully Load for Roles Without the View/Edit Packaging Philosophy Override Permission Enabled

Cause: The Packaging Philosophy Override and the Plan Packaging Philosophy Override default options should allow users without View/Edit Packaging Philosophy Override permission to successfully proceed through the MAP Step1 with the default options selected.

Fix: MAP Step 1 was updated to allow users without View/Edit Packaging Philosophy Override permission to proceed using the default packaging philosophy set.

Testing:

Login to REM with a role that does not have the View/Edit Packaging Philosophy Override Permission enabled and select a student record. Navigate to the Academic Plan tab. Select MAP. Ensure Step 1 of MAP loads and MAP can be performed.

Problem:
Regent changed some Direct Loan amounts after importing the NSLDS Financial Aid History (FAH) data.

Cause:
The Direct Loan amounts were incorrectly calculated because of the following issues: 1. incorrect loan fees recalculation; 2. incorrectly using manual loan amounts in the aggregate total calculation; and 3. processing loans toward the aggregate limits that were older than 200 days before the NSLDS FAH import date.

Fix:
The code was updated to ensure the Direct Loan amounts are calculated correctly.

Test:
Identify several affected students with their total Direct Loans near the lifetime limits. Load NSLDS FAH data if needed. Package the students. Review the Direct Loan amounts. Confirm the calculated amounts are accurate.

Problem:
Some Term BBAY students had unexpected refunds on Unsubsidized Direct Loans.

Cause:
The unsubsidized loans were in the first half of a two-term Academic Year. The system applied Subsidized eligibility to future terms within the same AY, when the term's start date was reached but those later terms were ineligble due to enrollment of less-than-half-time (LTHT) or None. Those later Subsidized loans resulted in reduced eligibility for Unsubsidized loans that were in earlier terms within the same Academic Year.

Fix:
Regent Award does not award loans for terms with anticipated or actual enrollment levels of LTHT or None. Those ineligible terms are not included in the Loan Period when the term’s start date is reached.

Testing:
Use a test environment with the server date set to just after the second term in the AY, e.g. just after the Fall term’s start date for a Summer-Fall AY. Find an affected student who has LTHT or None enrollment levels in the second (Fall) term in the AY. Package the student. Confirm the student has their full Unsubsidized eligibility awarded as expected.

Problem:
For clock-hour students, in the Return of Title IV Funds (R2T4) Wizard, some values in percentages were incorrectly rounded to four decimal places instead of three decimal places.

Cause:
The system used an incorrect percentage rounding procedure.

Fix:
A code fix was applied to correct the percentage rounding procedure. Values in percentages in Step 2 of R2T4 wizard are rounded to three decimal places.

Testing:
Perform an R2T4 for a clock hour student. Verify the system rounds values in percentages to three decimal places.

Problem:
Regent unexpectedly attempted to export paid COD rebuilt disbursements.

Cause:
Regent recalculated fees for paid rebuilt awards and calculated net amount based on origination fee for next Federal Award Year (FAY). The recalculated amount was not equal to the paid amount and the disbursement was exported to COD.

Fix:
Regent was updated to make sure fees are not calculated for rebuild awards initially created as paid.

Testing:
In Regent, find a student that has an ongoing Academic Year with Direct Loans originated and partially paid before October 1. Rebuild a student and Import Direct Loan data. Package the student import and run Export COD Process. Make sure paid disbursements are not included in the export file.

Problem:
Regent Award sent incorrect Disbursement Net Amounts and Disbursement Fee Amounts in the COD Export process for some canceled awards, resulting in COD Reject Edit 077.

Cause:
For awards that went through the “Cancel/Recreate” process due to a Loan Fee change, Regent Award did not zero out some amounts on the newly-canceled awards. The <DisbursementNetAmount> and <DisbursementFeeAmount> were exported with the positive amounts.

Fix:
Regent Award was updated to zero out the Disbursement Net Amounts and Disbursement Fee Amounts for canceled awards after the "Cancel/Recreate" process.

Testing:
In a test environment, locate a student who has an affected award that was canceled and recreated on Oct 1 with COD Reject 077 code. Package the student, such as with the Modify Academic Plan wizard. Perform a COD Export for the awards, using the ‘COD Export Override’ on the COD tab if needed. Examine the COD Export data file. Confirm the awards that were canceled on October 1 have “0.00” values for the <DisbursementNetAmount> and <DisbursementFeeAmount> fields.

Problem:
At a school with a SIS-provided SAP policy, the system generated SAP records with a SAP status of ‘Not Calculated’ for periods without any SBL-supplied SAP GPA data.

Cause:
The school was configured with ‘Delay SAP Calculation Due to Missing Grades’ enabled, which only applies to Regent Calculated SAP status. The system unexpectedly created a ‘Not Calculated’ SAP record with the reason, ‘Missing Grades.’

Fix:
The system no longer creates a ‘Not Calculated’ SAP record if the student has a SIS-provided or other non-Calculated SAP policy.

Testing:
At a school with a SIS-provided SAP policy, find a student who does not have any SIS-provided SAP record for a previous SAP review period. Package the student. Confirm the system does not create a ‘Not Calculated’ SAP record.

Problem:
The Satisfactory Academic Progress (SAP) status was calculated incorrectly for some students. The affected students failed to meet the Maximum Timeframe (MTF) requirements. The system unexpectedly set the SAP status to ‘FA Warning’ instead of ‘MTF Suspended.’

Cause:
Regent Award had incorrect precedence logic when a student had a Manual SAP record. Additionally, the ‘FA Warning’ SAP step was causing the system to not set the 'MTF Suspended' status.

Fix:
A code fix changed the ordering logic for the check of manual SAP records. The system also has an improved check to see if a non-Manual SAP record should be set to a status of ‘MTF Suspended.’

Testing:
At a school with Regent Calculated SAP, navigate to an affected student who is failing to meet the Maximum Timeframe. On the Awards tab, access the SAP Wizard from the ‘Calculate SAP’ button. Delete any preexisting Manual SAP Records for the SAP Review Period being evaluated. Click ‘Run SAP.’ Close the SAP Wizard. Refresh the Awards screen. Click ‘Calculate SAP’ again to view the SAP Wizard. View the student’s SAP status. Confirm the SAP status is ‘MTF Suspended.’

Problem:
Some students were able to edit Pell Grant awards from the Student Experience Portal.

Cause:
The affected Pell awards were created in Regent using the Rebuild and Conversion process. The Rebuild/Conversion process mistakenly set all the Pell awards to have an initial award status of ‘OFFERED,’ even though their current status was ‘ACCEPTED.’ The Student Experience Portal uses the award’s Initial Status to help determine whether a student can edit an Accepted-status award from the Student Portal.

Fix:
The Conversion process was updated to use the same rules for setting an award’s initial status as the normal packaging process. First, if the fund uses a UDF to set the status and that UDF is present on the student, the system creates the award using the status from the UDF value (“OFFERED” or “ACCEPTED”). Next, if the fund is configured to use the Override Award Status and the student meets those override criteria, the system sets the award’s initial status to the Override Award Status. Finally, if neither of those apply, the system sets the award’s initial status value to match the Initial Status configured in Fund Setup.

Testing:
Use a test environment that has the Student Experience Portal. Import test data for a student, including a COD Rebuild Pell Grant award, using the Conversion process. Package the student. Confirm the Pell award is currently in ‘ACCEPTED’ status. Create a test account for the student in the Student Experience Portal. Browse to the Financial Aid component. Confirm the Pell award displays as view-only. Confirm the student cannot edit the Pell amount from the Student Experience portal.

Problem:
The Student Experience Portal displayed an unexpected error message for some students: “Check back later to review Financial Aid.” The Portal was configured with cache enabled.

Cause:
When cache was enabled, the system did not pass in all the options for some alternative types of packaging such as SAP calculations. The system also incorrectly applied a timestamp for the current Academic Year when the student was packaged on the last day of an AY.

Fix:
The system correctly sends the options for alternative packaging. The code was updated to remove the incorrect time comparison when determining whether an AY was the current AY. Additional logic was added to fall back to load a non-cached version of the year so the student can still process if the cached version is somehow unavailable. In that fall-back event, the system will record a message in the server logs for later troubleshooting.

Testing:
In a test environment with the Student Experience Portal, ensure that cache and Regent Plan are enabled. Create test accounts for the affected students. Test the Portal functionality with several affected students, including accepting aid through the Financial Aid and My Borrowing - Select a Borrowing Plan. Confirm the actions are successful. Confirm the system does not display the ‘Check back later’ error to the student.

Problem:
In Student Documents, Regent Award did not display the Message text for the Document.

Cause:
The Student Documents screen incorrectly identified the Message field in the user interface.

Fix:
Regent Award was updated to correctly identify the Message field in the Regent Award screen.

Testing:
Identify a Document where the Document Setup's Message field is populated in Regent Award. Add the Document to the student in Needed status. In the student’s Documents screen, confirm the same Message text is displayed. In Advisor Assist or using a test account in the Student Portal, view the student’s Documents. Confirm the Message text is visible on the Documents from the Student Portal.

Problem:
Fully paid COD rebuilt disbursements were unexpectedly selected by COD during the export.

Cause:
Regent Award incorrectly tried to recalculate fees for a fully paid rebuild award disbursement, despite it was initially created by the Rebuild Process in a paid status. This caused the net amount of the award to be updated and not equal the total paid amount of the award, thereby inadvertently exporting to COD with an incorrect amount.

Fix:
Regent Award was updated to not recalculate fees for rebuild disbursements initially created in a paid status.

Testing:
In Regent Award, rebuild the student data for a student with COD awards that are fully disbursed. Ensure the award disbursements are created in a paid status. Run the Export COD process. Ensure the awards do not export to COD.

Problem:
The Regent Student Experience Portal (StudentX) had incorrect radio-button behavior where an option was selected by clicking on the white space next to it.

Cause:
StudentX used a non-customized User Interface element with incorrect behavior.

Fix:
StudentX was updated to use a radio-button control that triggers selection of the selected option by direct clicking on the option.

Testing:
In the Student Experience Portal, open the Financial Aid tile for a student who has an Offered-status award. Open the ‘Review and Update’ area. Click on the white space on the right side of the radio-button selection option. Confirm the system does not select the option.

Problem:
Two Institutional awards did not package to their expected amounts. The funds were both configured to package to “% of Additional COA Requirement” for specific Cost Items.

Cause:
In some cases when there were Loan Periods with different lengths, Regent Award calculated Costs and packaged with a slightly different fund ordering than the Packaging Philosophy specified.

Fix:
The Packaging Philosophy was enhanced in the 5.5.0.0 release. The funds are packaged in the correct order. The remaining costs are calculated correctly for each Fund.

Testing:
Navigate to a currently affected student in a current, active Academic Year. Clear any blocking Documents or Tasks, and confirm the student has any Documents required for the funds in a Satisfied status. Package the student. Confirm the Cost amounts are correct. Confirm the award amounts are correct and match the percentage of eligible Costs.

Problem:
In the Export for Student Transactions (EST) process, the Federal Supplemental Educational Opportunity Grant (FSEOG) was unexpectedly blocked by error code EST-0033 although the student was eligible.

Cause:
Regent Award incorrectly calculated the eligibility for funds having an alternative FAY (Alt-FAY) calendar when processing EST verification.

Fix:
A code fix was applied for funds having an Alt-FAY calendar. The logic uses the same eligibility calculation approach as during the award calculation.

Testing:
Find an affected student who has an unpaid FSEOG award. Run the EST for DRI process. Confirm no override error codes occur. Confirm the EST-for-DRI process sets the DRI (paid) flag to a value of True.

Problem:
An Institutional award did not package to the full amount. The fund was configured to package to “% of Additional COA Requirement.”

Cause:
In some cases, Regent Award calculated Costs and packaged with a slightly different fund other than the Packaging Philosophy specified.

Fix:
The Packaging Philosophy was enhanced in the 5.5.0.0 release. The funds are packaged in the correct order. The remaining costs are calculated correctly for each Fund.

Testing:
Navigate to a currently affected student in a current, active Academic Year. Clear any blocking Documents or Tasks, and confirm the student has any Documents required for the fund in a Satisfied status. Package the student. Confirm the award amount is correct and matches the percentage of eligible Costs.

Problem:
Regent Student Portal unexpectedly allowed alphabetic characters for numeric fields in Verification Worksheet smart-form.

Cause:
Regent Student Portal was not validating input characters for a set of fields in the Verification Worksheet smart-form.

Fix:
Regent Student Portal was updated to make sure only numeric values are allowed for identified list of fields.

Testing:
In Regent, add Verification Worksheet for the student. Open student in Regent Student Portal and then open the Verification Worksheet smart-form. Navigate to the following fields and enter alphanumeric values: "Age of the primary parent", "Age of the second parent", "Age of the first child", "Age of this dependent" and "Dependent's relationship to your parents". Make sure only numeric values are allowed as input.

Problem:
For some students with an R2T4, Regent Award calculated an unexpected amount of break days in the R2T4 Wizard Step 2.

Cause:
The system used an incorrect R2T4 date mask for calculating the length of the scheduled days and break days.

Fix:
The R2T4 Step 2 numerator and denominator calculations were updated to use a corrected “mask” for determining the days that do or do not count for the R2T4 calculations.

Testing:
Test in an environment that can set the server date to within an affected payment period. Test with both term and nonterm students. Find affected students who have terms or payment periods that include the dates of June 30, 2021 and July 1, 2021. Add and save a new R2T4 for an affected payment period that includes an Institutional Break. In Step 2, confirm the numerator is counting days during the Institutional Break as break days. Confirm the numerator is not counting days past the Date of Withdrawal (WDD) as days of attendance. Confirm the Denominator does not include any Break Days as days the student was expected to attend. Test using an R2T4 WDD prior to July 1, 2021 and again using the new logic for a WDD on or after July 1, 2021. Confirm the Break Days are calculated as expected.

Problem:
A Communication email sent after a Program Change did not reflect any awarded funds.

Cause:
The communication template used data from historic Academic Years to reflect the awarded funds.

Fix:
A check was added to extract award-related data from non-historic AYs for Communications.

Testing:
Load a Student Batch Load (SBL) file with the program change data for the affected student. Complete the program change. Run the ‘FA Offer’ communication for the student. View the Communication email. Confirm the award amounts are correct in the email. Confirm the funds awarded for the new program are present in the Communication.

Problem:
After importing some Institutional awards, Regent Award showed an error in the Conversion Wizard: ‘RNA failed to process one or more Imported awards.’

Cause:
The awards were from a non-Title-IV fund configured to not require an ISIR. However, Regent was incorrectly processing the awards as needing a Verified ISIR during the Import Awards and Disbursements (IAD) process.

Fix:
Regent Award’s Import Awards process was updated to ensure the Title IV award verification does not affect non-Title IV awards from funds that are configured to not require an ISIR. The system also has improved logic for handling IAD data when the system cannot link the imported disbursement to a nonterm payment period.

Testing:
In Regent Award, find a student undergoing the Conversion Process who does not have a verified ISIR. Create an Import Award and Disbursements data file with an award for a non-Title-IV fund that does not require an ISIR, in a Loan Period that ended in the past. Import the IAD file. Review the student in the Conversion Wizard. Confirm no errors appear in the "All Imported Awards" section next to the Imported Award.

Problem:
A fund was configured to package to a percentage of the ‘Additional COA Requirement’ in the Packaging Philosophy. When the award was packaged, the system awarded a different amount than expected.

Cause:
Regent Award calculated the remaining Costs and award amounts using a slightly different order than the Packaging Philosophy specified.

Fix:
The Packaging Philosophy was enhanced in the 5.5.0.0 release. The funds are packaged in the correct order.

Testing:
Testing is date-dependent. Test with a current affected student, or use a test environment where the server date can be changed to be during a time period when the issues occurred. Repackage the student with the award in a current period, with an affected fund that uses the ‘Additional COA Requirement.’ Confirm the system applies the correct amount based on the specific configured Costs.

Problem:
An Institutional Scholarship was canceled after a Substantially Equal Program Change (SE PC) between two programs. Both programs were eligible for the fund.

Cause:
Regent Award applied the funds using a slightly different order than the Packaging Philosophy specified.

Fix:
The Packaging Philosophy was enhanced in the 5.5.0.0 release. The funds are packaged in the correct order.

Testing:
Navigate to a student currently in the old program. Confirm the current award from the affected fund is in Accepted Status. Load a SE PC Student Batch Load (SBL) data file. Ensure the SBL data was correctly imported in the Process Log. Go to the student’s Academic Plan. Package the student. Refresh. Open the Program Management Wizard. Complete the Program Change as Substantially Equal. Confirm the fund is awarded correctly for both terms in the program.

Purpose of Script:
The script performs data cleanup for ISIRs affected by an ISIR inheritance bug that applied the default status instead of the inherited Verified status.

Data Changed by the Script:
The script corrects the ISIR status from "Selected, Not Verified (Inherited)" to "Verified (Inherited)" for students who had a previously verified ISIR.

How to Access the Script:
Schools may request the script in a CZ ticket. The root cause is fixed in the 5.5.0.0 release. The data-cleanup script is also automatically included in the release.

How to Test the Script:
View an affected student's ISIR tab. Observe the incorrect status, "Selected, Not Verified (Inherited)." Run the script or (alternatively) upgrade to the 5.5.0.0 release. Refresh the ISIR tab. Confirm the new corrected status, "Verified (Inherited)."

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 5.5.0.0 release. Each customer will receive this script update automatically when they upgrade to the 5.5.0.0 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 on the Academic Plan screen. Package the student using the Modify Academic Plan wizard (MAP). Perform the upgrade. Refresh the Process Log. Confirm the Process CE Rollup process is Complete. View the affected student. Repackage the student using MAP. Refresh the Academic Plan screen. Confirm the total units match the course data.

Purpose of Script:
This on-demand data-cleanup script removes Manual Anticipated Units that caused a specific error for a nonterm student, “Duplicate Pell Award... FAY#…FAY# (cross FAY amounts) detected on Payment Period.”

Data Changed by the Script:
The script removes Manual Anticipated Units from the student’s payment periods.

How to Access the Script:
An affected Regent Award client may open a CZ ticket and work with their Account Manager to run the script on demand for specific students.

How to Test the Script:
In a test environment, run "System – Batch Packaging Errors" and check packaging errors that match error pattern listed in Purpose of the Script above to identify any affected students. Run the List Only version of the script for each affected student and confirm student is listed in the result. Run Update version of the script. Refresh the Academic Plan. Package the student. Confirm whether the student is packaged successfully.