Title: Program Change Automation: Set Substantially Equal Flag for New and Future Program Changes Only

Tickets: RS-22451;

Description:
For term-based programs, the Course Enrollment logic has been updated for automated Program Changes using Program Groups. The system has improved logic for setting the “Substantially Equal” (SE) flag for program changes. The system will update the flag for new programs that are not currently the student’s active program. The system will not change the flag for already-executed program changes. To be marked for program change automation, the potential new program must have never been active for the student, and the new program must start on or after the start date for the student’s current active program.

Title: Updated the Amount Per Payment Period Section on Fund Configuration to Always Display

Tickets: RS-22434; RS-22370;

Description:

The Amount Per Payment Period configuration in Fund Setup has been made available for Academic Year scope funds. The Award Distribution Options configuration has also been made available for Academic Year scope funds to allow the Amount Per Payment Period to be distributed on a per payment period basis by selecting the ‘Distribute Using Payment Period Amounts’ option.

See the Customer Zone Knowledge Base topic Fund Setup Data Elements

Title: Updated Fund Configuration to Support Exclusion of Headers and Trailers

Tickets: RS-22373; RS-22370;

Description:

A new configuration, 'Exclude Header and Trailers' has been added on the Fund Setup General tab. When this configuration is set, terms configured with a Header or Trailer are not included in the award distribution across payment periods for term-based programs. This configuration is not available for Title IV funds or funds configured with a Ruleset.

See Customer Zone Knowledge Base topic: Fund Setup Data Elements

Title: Added Fund Configuration to Support Award Proration

Tickets: RS-22371; RS-22370;

Description:

A new configuration, ‘Prorate Distribution Amounts’ was added on the Fund Setup General tab. When this configuration is set, the calculated distribution amounts will be prorated based on the program applicable, registered units for the period out of the minimum full-time enrollment level for the program. Anticipated periods will use anticipated units for the period. This configuration will not apply to nonterm programs and is not available for Title IV funds or funds configured with a Ruleset.

See the Customer Zone Knowledge Base topic Fund Setup Data Elements

Title: Updated the Fund Priorities Configuration on the Packaging Philosophy Setup

Tickets: RS-22346; RS-22244; RS-22245; RS-22246; RS-22247; RS-22248; RS-22249; RA-185;

Description:

Three new Package To options were added to Packaging Philosophy Setup:

1. Packaging Grids
   1. When Packaging Grid is selected, the fund uses the Packaging Grid Setup to determine the ‘Package To’ limit (e.g. % of COA).
   2. When Packaging Grid is selected, the ‘Package to Amount’ defaults to N/A, and the ‘Package to Amount’ field is non-editable and grayed out.
   3. This option is only available for non-Title IV funds.
2. % of Full Need
   1. When % of Full Need is selected, the fund is packaged to 100% of Need (COA minus EFC).
3. Flat Amount to COA
   1. When Flat Amount to COA is selected, the fund is packaged with the flat amount configured up to the total Cost of Attendance and is subject to the remaining unmet COA.
4. Flat % to COA
   1. When Flat % to COA is selected, the fund is packaged with the % configured up to the total Cost of Attendance and is subject to the remaining unmet COA.

The % of FM Need was also renamed to % of Remaining Need (COA minus EFC minus EFA) to better define and differentiate with the new % of Full Need option.

See the Customer Zone Knowledge Base topic Packaging Philosophy Setup Data Elements

Title: Added Communication Context Variables

Tickets: RS-22319;

Description:
The following configurations were added as communications context variables in order to create communications context variables that can be used in communication templates (e.g. emails, text):

• Website Address and Email Address configurable fields in the new ‘Content Used in Communications’ section
• Portal address (portal login page link) associated with the REM instance

See the Customer Zone Knowledge Base topics Institution Setup Data Elements, Campus Setup Data Elements, and Site Setup Data Elements

Title: Communications: Add General Configuration Settings for Enterprise, Institution, Campus, and Site Setup

Ticket: RS-22306;

Description:
Additional fields were added to the Communications context variables. Communications may be configured to include values from the ‘General’ tabs for the configuration settings in Enterprise Setup, Institution Setup, Campus Setup, and Site Setup. The values may be used directly, or when the field is configured to ‘Inherit’ from the previous level.

See the Customer Zone Knowledge Base topic Regent Award Communication Templates.

Title: Send Confirmation Email Communication for Smart Forms Submitted from Student Experience

Tickets: RS-22232; RS-22231; RS-22233; RS-22234; RS-22266; RS-22268; RS-22267;

Description:

Email Communication will be sent when a Smart Form is successfully completed in Student Experience (signed by student or parent), if the communication is configured in Regent Award Portal Settings, to confirm submission of the document and advise the student of next steps. If an EFC is calculated, for Verification Worksheet and Financial Aid Application forms, the EFC will display within the email when an Independent student has signed or when the parent of a Dependent student has signed.

To activate the communication, clients should select ‘Student Experience: Smart Form Submitted Email’ for the ‘Smart Form Submitted Email’ field in Institution Setup>Portal Tab>General tab>Communication Settings.

See Customer Zone Knowledge Base topic: Student Email Confirmation of Successful Smart Form Submission

Title: Align Transaction Numbers between Regent Access and Student Portal

Tickets: RS-21338; RS-22211; RS-22297; RS-22298; RS-22299; RS-22300; RS-22427;

Description: Regent has improved the logic for integrating Regent Access transaction numbers with Student Portal transactions in the database. Previously, when a Smart Form needed to match to the ISIR-formatted eAccess Export (Access Questionnaire record), there could sometimes be inconsistencies between the two sets of transaction numbers. For example, if there were more Regent Access transactions than submitted Smart Form transactions, there could be a mismatch in transaction number values. To prevent problems, Regent has added the unique identifier (the ‘snapApplicationID’ value) to the exported data. The eAccess Export process will populate the value at positions 3030 to 3044 in the Regent Access exported ISIR-formatted data. Note, this enhancement only affects the Regent Access Application exports, not the ISIR correction related exports. Additionally, if Regent Access is enabled, a new section on the ISIR tab will display as ‘Regent Access Fields’. This new section will include the applicationID, eAccessISIR, mainFederalSchoolCode and studentExternalID.

See the Customer Zone Knowledge Base topic Access - Export Files

Title: Updated “Paper Process” Smart Form Workflows for Dependent Students

Tickets: RS-21338; RS-22210; RS-22302; RS-22303; RS-22304; RS-22305; RS-22322;

Description: Per changes made in 5.5, additional work was needed to close gaps in the Paper Process workflow for Dependent Students. Paper Process includes the option to “upload” a form and the option to submit via an “approved method”. Workflows have been updated for two scenarios.  The first, when a dependent student eSigns and their parent uses the paper process, the PDF will not show the EFC when the parent still needs to sign.  EFC is also suppressed on the PDF for upload after the ISIR is generated.  The second scenario that has been updated is for a dependent student where the student paper signs and their parent eSigns.  After the PDF is persisted to Regent Award, the ISIR is not generated until the parent eSigns.  Once the parent has eSigned, the ISIR will generate but the EFC is suppressed until an ISIR correction updates that both signatures have been received.  

Title: Password Controls

Tickets: RS- 22205; RS-22244; RS-22245; RS-22246; RS-22247; RS-22248; RS-22249; RA-185;

Description:

New configurations have been made available to support password requirements and security. Regent can now configure both Regent Award and Student Experience Portal environments with school-specific password requirements such as the number of days before a password is required to be reset or the length of the password (minimum number of characters). Schools may submit a Customer Zone ticket to request Regent to update the Password Controls for a specific environment (e.g. QA and/or Prod). Minimum default values for password controls are required to meet industry standards.

Title: Ability to upload .HEIC extension (Apple iOS) documents in Student Experience

Tickets: RS-21338; RS-22189; RS-22264; RS-22252;

Description: Apple (iOS/iPhone) has a new .HEIC extension for their high-resolution picture files. Students are now able to upload .HEIC documents in the Student Experience Portal.

See the Customer Zone Knowledge Base topic Document Setup Data Elements

Title: Processes Tab In Regent Award has been reorganized

Tickets: RS-19198; RS-22119;

Description: The Processes tab in Regent Award has been reorganized to help clients find the proper process more easily. It is now grouped by Imports, Exports, System, Rebuild/COD WB, Schedules and SAIG. The Process Log remains at the top of the list.

See the Customer Zone Knowledge Base topic Importing Student Document Requirements

Title: Updates to the 2022-2023 Verification Worksheet

Tickets: RS-17908; RS-22063; RS-22283; RS-22284;

Description: The 2022-2023 Verification Worksheet is available to Regent Review clients. All year references have been incrementally updated for the new Federal Award Year. Any references to 'virtual currency' and 'IRS 10040 NR EZ' have been removed. Any references to Selective Service and Drug Convictions have been removed as these no longer affect student eligibility.

See the Customer Zone Knowledge Base topic

Title: Document Setup: *‘*Block My Borrowing Tool’

Tickets: RS-22037; RS-22003; RS-22098; RS-22099; RS-22100; RS-22101; RS-22166; RS-22169; RS-22170; RS-22171;

Description: An Institution can now disable the My Borrowing tool in Regent Plan for individual students. The school may configure a blocking Document Requirement using a new field in Document Setup, 'Block My Borrowing Tool.' The Document must be Student or AY-scoped. If one or more document(s) configured to block My Borrowing is present in one of the following statuses ('Needed', ‘Incomplete’, ‘Received’, ‘Unsatisfied’), then My Borrowing will be blocked in Student Experience for all AYs (student-scoped) or for the specified AY (AY-scoped). If all those configured blocking document(s) exist in ‘Waived’ or 'Satisfied’ status for the student, and My Borrowing would have been available otherwise, My Borrowing will be available to the student.

See the Customer Zone Knowledge Base topics Document Setup Data Elements and My Borrowing

Title: R2T4 Wizard: Automatically Populate Step 2 Values for Clock Hour Programs

Tickets: RS-22117; RS-21552; RS-22403; RS-22415;

Description:
For manual and automated R2T4s, the R2T4 Wizard in Regent Award has been updated to automatically populate values in Step 2 for Clock Hour programs using an SBL field and the student’s Academic Plan data. The wizard only auto-populates the ‘Hours Scheduled to Complete’ when that value is sent in the SBL R2T4 node in the ‘Clock Hours Scheduled to Complete.’ Regent Award then automatically calculates and populates the Total Hours in Period, Percentage of Period Complete, and Box H. Users may manually enter or override the editable values.

Title: My Borrowing “Decline All Loans” Option is now more prominent

Tickets: RS-22412; RS-21510; RS-22158; RS-22185; RS-22224;

Description: In the Student Experience portal, the My Borrowing tool option to “Decline All Loans” has been made more prominent. New Regent Award configuration has been added under Institution Setup to support the Decline Loan Options. Clients are able to edit the display name, informational text and location of the Decline Loan Options button.

See the Customer Zone Knowledge Base topics My Borrowing , My Borrowing Setup

Title: Student Experience Accessibility Improvements

Tickets: RS-21441; RS-22139; RS-22140; RS-22141; RS-22142; RS-22143; RS-22144;

Description:
The Regent Student Experience Portal (StudentX) has improved accessibility for students with disabilities. Several items have updated colors with higher contrast ratios. Additional improvements were made to make features more accessible to screen readers.

Title: Fall Regulatory Updates for 2022-2023 FAY

Tickets: RS-22278; RS-21430; RS-21429; RS-21417; RS-21418; RS-21419; RS-21420; RS-21421; RS-21422; RS-21423; RS-21424; RS-21426; RS-21427; RS-21428; RS-22091; RS-22239; RS-22260; RS-22276; RS-22280; RS-22285; RS-17907;

Description:

Regent Award and Regent Review have been updated for the annual regulatory changes for the 2022-2023 FAY.

• Updated processes to support 2022-2023 ISIR Import and ISIR Corrections.
• Added text to the Identity Verification Wizard for 2022-2023 FAY: High school completion confirmation is no longer required starting with the 2022-2023 FAY. CPS will not accept status options #4 or #6 for 2022-2023 or future years.
• Updated SAIG message classes in Regent Award/Regent Review in order to process ISIRs for the 2022-2023 FAY.
• Updated screens to make 2022-2023 data available in ISIR Details and ISIR Verification/Correction Wizard and Compare Wizard.
• Updated SAR Comment Codes in Regent Award per regulatory changes for 2022-2023 FAY.
• Updated 2022-2023 ISIR reject codes in Regent Award to support 2022-2023 FAY processing.
• Added TEACH sequestration percentage reduction values for 2022-2023 FAY. (Same values as last year.)

Title: Gaps in the 180-Day Rule Functionality for Non-Term Students

Tickets: RS-19990; RS-18601; RS-22375; RS-22378; RS-22380; RS-22382; RS-22377; RS-22384; RS-22385; RS-22387;

Description: This enhancement addresses inconsistencies with the 180 day indicator when a payment period is closed due to the 180 day rule. Three scenarios have been addressed to fix gaps in the 180-Day rule functionality. They are as follows:

R2T4: A nonterm payment period will cease expanding when an R2T4 is in 'Open' or 'Finalized' status. This does not affect the Nonterm R2T4 Extrapolation functionality.  If the R2T4 is closed as ‘not needed’ or is reversed, the configured nonterm payment period expansion option will resume control over the payment period end date.

180 Day Payment Period End Date Freeze: A nonterm payment period is closed and the Payment Period End Date will no longer shift when 180 days have elapsed since the later of the withdrawal date of an attended, program applicable course or the end date of a non-withdrawn, program applicable, attended course.  Attendance is assumed upon receipt of a Last Day of Attendance, an Attended Flag, or confirmation of Course Completion. This rule applies if a student does not attend any courses for 180 days after completion of the first payment period in the academic year. 

Reentry: If the student begins a new course after the 180th day, a new academic year will be created beginning on the Course Start Date - the end date of the previous payment period/academic year will not change. If a student returns to a nonterm payment period (in the same or a substantially equal program) within the 180 days, the current payment period and all future payment periods and academic years are pushed out to adjust for the newly extended payment period, and the period of nonattendance will be treated as a student level break for R2T4.

See the Customer Zone Knowledge Base topic

Title: Expanded Packaging Philosophy ‘Package To’ functionality with new Packaging Grid Configuration

Tickets: RS-13678; RS-22347; RS-22348; RS-22359; RS-22358; RS-22360; RS-22361; RS-22369;

Description:

Regent added new packaging functionality to determine a fund award amount based on one or two variables configured on an indexed grid. The grid variables determine the amount or percentage that will be used for the ‘Package To’ limit. For example, a chart or grid may have GPA ranges across one axis and EFC ranges across the other, and a student’s ‘Package To’ target is identified via the grid cell corresponding to the student’s GPA and EFC. The award amount is then calculated using the ‘Packaging To' target amounts. All other eligibility stipulations configured for the fund (such as a requirement for SAP or ISIR) continue to apply.

Problem:
A few students had duplicated items on the Academic Plan. For example, some had multiple loans with the same FAID value, or duplicated disbursements with the same disbursement number value. When the affected students were repackaged, Regent Award did not give an error on the screen, but the students' ‘Last Packaged’ date was not updated. For those failed repackagings, the Process Log displayed an RNA Analysis process with an Error: the ‘Academic Plan record(s) were not valid for persistence and therefore were not saved.’

Cause:
A rare, timing-dependent logic bug could sometimes occur if a Regent Award user triggered two or more separate packaging runs in a nearly simultaneous timeframe. The issue happened when each packaging run would create its own new objects (new Awards, new Disbursements, etc.), and then both packaging runs would save those new items. The glitch resulted in duplicated objects saved to the affected student’s Academic Plan. The error only occurred when the student was packaged and repackaged quickly by a user, and not from Batch Packaging.

Fix:
A data-cleanup script RS_22416 was developed to remove duplicated objects from the currently affected students. The root cause was fixed by moving the code that checks for the updated Academic Plan version to the end of the packaging logic. The updated code will not persist the data from a packaging run (it does not save any new objects) if the Academic Plan version has already changed. Schools may open a CZ Support ticket to request their Account Manager run the RS_22416 script to identify potentially impacted students, and run the cleanup script if needed.

Testing:
Testing the root cause needs to move very quickly to try to trigger multiple, different packaging runs in a short amount of time. One way to try to create the issue (on a currently unaffected student) is to do an action that would create new awards, and then immediately repackage. For example, a user might clear a student’s blocking Document or process an undergrad-to-graduate Program Change, and then immediately re_package using the Modify Academic Plan (MAP) wizard twice in a row. To confirm the fix, view the Process Log and see if any processes resulted in an expected error _(as expected, if any process could not finish before another repackaging). Refresh the Academic Plan again. Confirm the Academic Plan does not contain any duplicated awards. Package the student again. View the Student Summary tab. Confirm the ‘Last Packaged’ date and time match the time of the most recent successful packaging run.

Problem:
Regent Access form unexpectedly showed incorrect IRS field references for field hints in the State Federal Student Aid Application.

Cause:
Regent Access form incorrectly used the previous years' IRS field reference for the 22-23 year application.

Fix:
Regent Access form has been updated to ensure IRS field references used for hints corresponds to the actual IRS form.

Testing:
In Regent Access, complete the Federal Student Aid Application for 22-23. Review Text and Hints for Parent Information, Student Income and Tax Data to make sure it has correct field references for the most recent IRS forms.

Problem:
Regent Verification Worksheet Form (VWS) unexpectedly did not allow a user to enter an age less than 14 years for children and/or other dependents.

Cause:
Regent VWS field validation logic was incorrectly applied for children and dependents instead of parents.

Fix:
Regent VWS age field validation logic was updated to allow entry for children and dependents starting from 0 years old.

Testing:
In Regent, open VWS and make sure a user can enter an age value for children and/or other dependents starting from 0 years old.

Problem:
In the College Financing Plan (CFP) communication PDF attachment, the “For More Information” block displayed incorrect information for the school address, telephone, and email.

Cause:
The template used incorrect default values for the affected fields. If the school’s values were not available, the CFP displayed those default values.

Fix:
The template’s logic was corrected to use a default value of blank for the affected fields. The template was updated to use the Inherited values, if available. The template also does not display the label for an empty value on the “Telephone:” or “Email:” fields.

Testing:
In Regent Award 5.5.2.0 or later, configure the CFP Communication with the updated template content. Generate the CFP for a test student. View the CFP PDF. Review the “For More Information” block. Confirm the “For More Information” block matches the information from the test student’s Site.

Problem:
A Pell award was paid and disbursements were exported to COD with DRI=true (Disbursement Release Indicator flag is marked as Paid). The system increased the Pell award amount to the regular Scheduled Pell amount. However, the student had less than 100% remaining in Pell Lifetime Eligibility Usage (LEU).

Cause:
Regent Award had incorrect timing when adjusting a student’s Pell usage using the LEU value from a COD response. The system incorrectly assumed some COD disbursement amounts were fully paid as of the internal release date when the disbursements were first exported to COD, when the disbursements were not yet accepted by COD as paid.

Fix:
Regent Award does not adjust a student’s available Pell LEU amounts for a COD response until the disbursements are fully accepted as paid (DRI=true) for the imported COD response.

Testing:
Note: Testing will need to simulate COD data and use a “time machine” test environment that can change the server date. Start with a Pell-eligible student who has less than 100% Pell LEU remaining from an NSLDS or ISIR data source, and who has a fully unpaid, full-time Pell Grant award that is currently lower than the regular Pell Grant Scheduled Amount. If the Pell award is not already Accepted at COD, then originate the award (export to COD with DRI=false) and mock a COD Origination Accepted response. Package the student. Review the Pell amount. Confirm the Pell amount is still only matching the student’s remaining LEU (not the regular FT amount). Change the test server’s date to later, after the scheduled release date for the initial disbursements. Re-export the Pell disbursements to COD with DRI=true. Create a simulated, Accepted COD response having the higher Pell LEU percentage. Import the simulated COD acceptance. Package the student. Confirm the system keeps the Pell award at the remaining LEU amount. On the student’s History tab, confirm the Pell LEU percentage matches the amount in the imported COD file.

Problem:
Some students in a four-term Scheduled Academic Year (SAY) had Title IV Direct Loans in all the terms in the AY. The students enrolled at least half-time in the first term and the last term. Later, the students dropped below half-time status in the second and/or third terms, creating a “donut” scenario with no loans for the middle term(s) in the AY. When their loans were repackaged, the system unexpectedly “front-loaded” the full year’s eligibility amount into the very first term. The system zeroed out the loans in the eligible later term(s) after the “donut hole” (non-loan) term(s).

Cause:
The system awarded the full amount to the very first award in an AY. The system accidentally skipped awarding loans for the later, separate loan period that covered the later term(s) in the AY.

Fix:
The system awards loans for all the eligible enrollments in the AY. The system divides the amounts across eligible enrollments that occur before and after “donut hole” terms that do not have loans.

Testing:
Test using a “time machine” environment that can change the server date. Set the server date to a time during the Summer term. Navigate to a student who has unpaid Title IV loans for the Summer-Fall-Winter-Spring terms, and who has at least half-time registration for all four terms. Package the student. Confirm the Title IV amount is divided equally across all four eligible terms. Change the student’s Actual registration in Fall to LTHT. Package the student. Confirm the loans are repackaged and divided equally across the Summer, Winter, and Spring terms. Change the Actual registration in Winter to LTHT. Package the student. Confirm the loans are repackaged and divided equally across the eligible Summer and Spring terms only. Change the Actual registration back to at least half-time for all four terms in Summer, Fall, Winter, and Spring. Repackage the student. Confirm the loan amounts are divided equally across all four terms. Repeat these tests with the server date set during the Fall and Winter terms. Confirm the loan amounts are still spread evenly across all the eligible terms in the AY. Finally, change the student’s registration from all four terms to at least HT in the first and third terms only. Set the server date back to a time during the first term. Repackage the student. Confirm the system allocates the loan amounts to the eligible first and third terms only.

Problem:
The ‘Advisor Assist’ tab gave an occasional error: ‘The operation has timed out.’

Cause:
An external website could not be reached for the Single Sign-On (SSO) support.

Fix:
An additional retry was added so if the error occurs, Regent will wait one second and try again to reach the external site.

Testing:
Note, the error is intermittent and was difficult to reproduce. At a school using Single Sign-On, sign into Regent Award or Regent Review. Access a student’s ‘Advisor Assist’ tab. Confirm the system displays the student’s Student Experience Portal information. Confirm the ‘operation has timed out’ error is not displayed.

Problem:
After a school imported some NSLDS Financial Award History (FAH) data files, Regent Award unexpectedly reduced the Subsidized or Unsubsidized loans for some students.

Cause:
The affected students were near their Lifetime Aggregate limits, but the NSLDS data did not contain all their current Regent Award loans. When Regent Award adjusted the students' lifetime aggregate balances to re-award current loans, the missing loans were not properly subtracted in the adjustment.

Fix:
When Regent Award adjusts the total aggregate balances, Regent considers all loans within 200 days prior to the data’s effective date.

Testing:
Navigate to an affected student who has Federal Direct Subsidized or Unsubsidized loans in a current or future academic year. Load NSLDS FAH data. Package the student. Confirm the loans are packaged to the student’s remaining aggregate totals.

Problem:
The incorrect wording was present for dependent students on the Electronic Signature Process page of ‘Sign My Forms’ section on the 2021-2022 WA Application for State Financial Aid (WASFA) application.

Cause:
Verbiage on Electronic Signature Process page did not reflect that it was a parent eSign, rather it was a student eSign.

Fix:
The verbiage was updated to 'Parent Certification' on the Electronic Signature page.

Testing:
Log in as a new user and start the 2021-2022 WA Application for State Financial Aid (WASFA) application.
During the registration, set DOB as 01/01/2004 to make the student dependent. The 'Sign My Forms' section for a dependent student should contain the word 'Parent' instead of 'Student.'

Problem:
In Modify Award Wizard (MAW), when a user tried to Finish from the Academic Plan preview screen, the error appeared: “Modified Academic Plan Information. No current Academic Plan Information Found.”

Cause:
One part of the packaging system tried to change an existing disbursement number. Another part of the system did not allow the change to be saved to the database.

Fix:
A code change was done to prevent the change of previously generated disbursement numbers during repackaging.

Testing:
Navigate to an affected student. In the Awards tab, perform MAW to edit the Pell Grant. Finish. Refresh the Academic Plan. Confirm the Pell Grant was successfully changed.

Problem:
Regent Award was unexpectedly showing numeric codes instead of wording in the subsequent updated transaction PDF application when a correction file is processed.

Cause:
Some 'list' type data fields for the PDF attachment were displaying a number value instead of the option value for the items in the list.

Fix:
Updated the application correction process to properly display the option description instead of an option value.

Testing:
In Regent Award, import the correction file for a student's application and then export a new PDF file. Confirm the following questions have a text description: Student's Marital Status, Do you have children, Do you have dependents, Did you become a resident of the state before 01/01/2016?, High School Diploma or Equivalent, Educational Plans, Student's 2019 Tax Return Information, School list.

Problem:
Regent Award unexpectedly set incorrect AY start/end dates to a single-term length and sent the dates to COD which resulted in COD reject code 046 for Direct Subsidized Loan.

Cause:
The loan was from a single-term academic year (AY). Regent set the COD begin/end date according to the term. This date range caused the 046 reject code from COD.

Fix:
The AY begin/end dates for COD were extended to the full academic year by ending the AY with the next sequential term's end date (next 2 terms for quarter program type).

Testing:
Find the affected student having a single-term AY dates at COD. Package the student. View the AY dates on the Loans tab. Confirm the AY dates are correct. Export the Sub/Unsub loan to COD for EST for DRI = true. View the dates in the COD export file. Confirm the AY dates are not a single-term length.

Problem:
Regent Award was unexpectedly limiting Direct Subsidized Loans due to the Subsidized Usage Limit Applies (SULA) rules, when ‘Apply SULA Calculations’ was disabled for the program.

Cause:
Regent Award was missing a check for the configuration setting in the eligibility rules logic.

Fix:
Regent Award was updated to add the check for the configuration to the eligibility rule.

Testing:
In Regent Award, configure the ‘Apply SULA Calculations’ with a value of “No.” Package a student who has a Direct Subsidized loan that should be limited by SULA, such as a student with a Subsidized Usage Period value of 5 or higher. Confirm the student’s current and future Subsidized loans are not reduced due to SULA rules.

Problem:
The system did not round correctly for some 2021-2022 Pell Grants when the program's Period Type was Quarter (three terms per Academic Year), but four terms were present in the AY. The rounding error caused overawarding by $0.01 for some students.

Cause:
The application made incorrect rounding operations when the Pell Grant rounding was configured to "Cent" by rounding up the amounts for $0.01.

Fix:
The rounding logic was updated to use the correct rounding rules for cents.

Testing:
Find the affected student. Run packaging. Verify packaging results. Confirm the Pell award amounts are repackaged based on enrollment level amounts as per 2021-2022 Pell Grant scheduled amounts.

Problem:
For a clock-hour student, the packaged Unsubsidized loan amounts were incorrectly decreased by $1 during the proration for a shortened remaining period of study in a nonterm Academic Year.

Cause:
The student had a loan period that held canceled awards from a prior FAY. During the processing of the loans in that loan period, the stored award period amount had rounding that adjusted the award amounts, but did not round the amounts applied to the student’s Aggregate amount.

Fix:
Regent added an adjustment to the award period aggregate fund balances rounding logic.

Testing:
Find the affected student. Navigate to the Academic Plan. Run packaging. Verify that Unsub loan amounts are split equally between two terms. Confirm none of the amounts are reduced by $1.

Problem:
Regent Award was unexpectedly calculating Unmet Need/Unmet Cost using Subsidized and Unsubsidized gross amounts.

Cause:
Regent Award application incorrectly calculated Unmet Need when a period had been canceled or loan(s) in the past.

Fix:
Regent Award application was updated to accurately calculate Unmet Need when a period has been canceled or a loan(s) is in the past.

Testing:
Identify a student with a canceled period. Go to the Award Tab and review the calculated Unmet Need/Unmet Cost to ensure the system is using the net amount of Subsidized and Unsubsidized Loan amounts. Repeat these steps for a student with a loan(s) in the past.

Problem:
The attempt to modify Direct Unsub loan in 'Offered' status via MAW failed with an error: Cancelled award amount exceeds paid amount.

Cause:
The system was incorrectly handling the status for loans modified via Modify Award Wizard. As result, the warning about an invalid award was triggered.

Fix:
The conditions to verify the award's status were updated to not trigger when the award is manually modified.

Testing:
Find the affected student. Navigate to the Awards tab. Edit the Direct Unsubsidized loan via Modify Award Wizard. Click Finish. Confirm no errors occur when you pass through Modify Award Wizard steps.

Problem:
'Total' PWD Pell amounts in Allocation of Post-withdrawal Disbursement section mismatched the PWD amount calculated in Box 1 of PWD tab.

Cause:
The system incorrectly picked the non-recalculated ‘Could Have Been Disbursed’ value when creating PWD for Pell.

Fix:
A fix was added to use the recalculated values only.

Testing:
Find the affected student. Add R2T4 resulting into PWD. Verify that both 'Total' amounts at Allocation of Post-withdrawal Disbursement section and PWD amounts calculated at Box 1 of PWD tab are identical.

Problem:
An Undergraduate-to-Graduate Program Change prevented a 2020-2021 FAY award to be awarded from the 2020-2021 ISIR.

Cause:
The system used the wrong estimated EFC value. The system used the EFC associated with the award period during packaging.

Fix:
The EFC logic was updated to use the loan period’s estimated EFC instead of the award period’s estimated EFC.

Testing:
Find the affected student. Perform the Undergraduate-to-Graduate program change. At the final packaging step, verify that the 2020-2021 FAY loans are packaged in 'Offered' status for the new program.

Problem:
The 'cancelled award amount exceeds paid amount' error was received when the packaging launched via Modify Academic Plan (MAP) wizard.

Cause:
Regent Award did not accurately handle the sums of paid and cancelled awards. This resulted in the cancelled award amount exceeding the paid amount and triggered an error during packaging.

Fix:
Calculation checks have been added to ensure that the paid awards amounts are updating when the awards are cancelled.

Testing:
Find the affected student. Run packaging via Modify Award Wizard. Verify that no errors occur at STEP 1 - 3 of the wizard.

Problem:
Regent unexpectedly packaged Direct Loans not using the latest NSLDS information from Financial Aid History (FAH) files.

Cause:
Regent incorrectly used older NSLDS information when the Academic Year had manual and non-manual Direct Loans simultaneously.

Fix:
Regent was updated to ensure packaging is using the latest available NSLDS information.

Testing:
In Regent Award, find a student that has both manual and non-manual Direct Loans in their Academic Year. Load NSLDS FAH file. Package student and make sure Regent is using data from the latest loaded file.

Problem:
A processed Not Substantially Equal (NSE) program change with a SAY calendar did not start a new Academic Year as per NSE flow.

Cause:
The application didn't start a new NSE SAY program in the next Academic Year. This behavior occurred when the old program ended in Spring and the new program started in a Summer Trailer term.

Fix:
Regent Award flow was updated to start a new NSE SAY program at a new, separate AY with the same SAY AY dates as the original program’s SAY AY, where a Summer trailer will be added on the end of that new AY. Fall and Spring will be set as 'Historic' to fulfill the SAY Academic Year's structure.

Testing:
Import an SBL with a program change between two Substantially Equal (SE) term SAY programs, and the new program's start date is in Summer. Complete the program change as NSE via Program Management Wizard. Review Academic Plan. Confirm the new program starts at Summer of the subsequent Academic Year. Confirm the SAY terms going after the original program, and prior to the new program, are in 'Historic' status.

Problem:
A school reported an increase in COD Reject Edit 205, Payment Period Start Date is outside the Award Begin and End dates.

Cause:
The school had manually edited some loans and changed them to single-term loans, zeroing out disbursements in the later term. Regent did not export the zeroed-out disbursements to COD because they were for terms outside the loan period dates.

Fix:
Modify Award Wizard (MAW) was updated to mark all disbursements on an edited award to be re-exported to COD, including any zeroed-out disbursements. Regent will then export all the disbursements to COD, including $0 canceled disbursements. A data-cleanup script RS_22414 was also developed. The script can force COD export for all disbursements for a list of awards.

Testing:
Test with a student with a current loan covering all terms in an Academic Year. Edit the loan in MAW, changing it to a single-term loan with $0 for the other terms in the AY. Export the loan to COD. View the exported COD data file. Confirm the exported file contains the disbursements, including the $0 disbursements.

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.6.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.