Title: Revise Task ‘Review Late DL Disbursement – Payment Period Ended’

Tickets: RS-20674; RS-20719

Description:

The task 'Review Late DL Disbursement – Payment Period Ended' (created in 5.3.1.0) has been renamed 'Review Late Disbursement- Loan Period Ended'. The original 5.3.1.0 task trigger requirement based on "payment period end date in the past" has been changed to "loan period end date in the past" for term and non-term. The task will trigger when there is a non-R2T4, unpaid Direct Loan disbursement for a loan period that has ended, so institutions may offer those funds to the borrower for acceptance prior to disbursement.

Title: Document Setup - Electronic Signature: Override Signature Requirements

Tickets: RS-20436; RS-20569; RS-20570; RS-20571; RS-20572; RS-20573; RS-20574

Description:
Regent has added a new Document Setup configuration setting, Override Signature Requirements. The new setting works with the preexisting setting, Require Electronic Signature. Regent uses these two settings together to determine whether an electronic signature requirement for a student’s document should be 'Student Only’ or change to ‘Student and Parent,’ based on the student’s dependency status. There are three options for the new setting on the Electronic Signature sub-tab in Document Setup:

• Do Not Override (Default): The document signature requirement configured for ‘Require Electronic Signature’ will not be overridden.
  • The preexisting ‘Require Electronic Signature’ options will not change. Those options are: 1) Not Required, 2) Only Student Signature Required, 3) only Parent Signature Required, and 4) Both Student and Parent Signatures Required.
• ISIR Dependency Status: Regent will use the ISIR dependency status to determine whether only the student (Independent) or both the student and parent (Dependent) must sign the document.
  • If the Document uses this setting, but the student does not have an ISIR for a FAY, Regent will fall back to the ‘Smart Form Dependency Questions’ option. If the Document or Smart Form does not have the dependency questions, the system will default to requiring both student and parent signatures.
• Smart Form Dependency Questions: This configuration can be applied in cases where dependency status is evaluated but an ISIR is unavailable, such as a Regent Access or a state-based financial aid application. Those Smart Forms have a series of dependency-determination questions. Regent will set the signature requirements based on the dependency status determined by the Smart Form.

Upon upgrade, a build script will automatically set all ISIR Verification Worksheet configurations to “ISIR Dependency Status,” and Regent Access questionnaires will be configured to “Smart Form Dependency Questions.” All other documents that currently require a signature will be set to “Do Not Override.”

The enhanced functionality will only apply to documents that are newly created or updated from the Student Experience Portal after deployment. The system will not change the signature behaviors for existing documents in the legacy SNAP portal.

Title: Increase Character Limit for Fund Display Name

Tickets: RS-20537; RS-20538; RS-20541

Description: Field length of ‘Display Name’ in Fund Setup>Fund Detail, has been increased from 30 to 60 alphanumeric characters.

Title: Export Document Requirement: Export Information About Document File Attachments

Tickets: RS-19742; RS-20454; RS-20455; RS-20456; RS-20457; RS-20458; RS-20470

Description:
The Export Document Requirement (XML) Export Process has been enhanced. The process may now optionally include information about the Document File Attachments, such as the attachment file names. Schools may use the additional File Attachment information for integration with external systems. The related process entry in the Process Log also has an improved Students tab with a list of students and documents. A related Script, RS-20458, may also be used to do a one-time export of all existing student Documents and their file attachment information.

Title: COD Regulatory Updates- Spring 2021 (FAY 2021-2022)

Tickets: RS-19948; RS-19949; RS-20622; RS-20666; RS-20667; RS-20668

Description:

The following COD regulatory changes have been made for FAY 2021-2022:

• Implementation of new COD Schema 4.0e in Regent Award Integration, for COD Import Processes

• Addition of 2021-2022 COD Message Classes to SAIG Mailbox Integration, including for ASLA

• Update to Rebuild files for Pell YTD, Direct Loans, and TEACH to reference FAY 2021-2022

Note: Please ensure any documents related to processing 2021-2022 funds are FAY-scoped. Also, note that SAIG configuration options for 2021-2022 manual vs automated processing will default based on how those options were configured by the institution for 2020-2021. Regent recommends that clients review SAIG configurations to ensure optimal process operation for institutional needs.

Problem:
Regent Student Experience Portal was unexpectedly showing an error message notification "Int cannot represent non-integer value: ###" after student login.

Cause:
Regent Award was incorrectly processing Registered Units when they contained a decimal.

Fix:
Regent Award was updated to ensure fractional Registered Units do not cause errors on Regent Student Experience Portal.

Testing:
Logon to Student Experience Portal as a student that has a fractional amount of Registered Units in the current Academic Year. Make sure no error messages appear.

Problem:
The Verification Worksheet Smart Form was incorrectly displaying the Children and Dependent information after the user indicated a change in marital status.

Cause:
The Verification Worksheet Smart Form was not configured to hide the Children and Dependent information if a change in marital status is present.

Fix:
The Verification Worksheet was updated to not display the Children and Dependent information if the user indicates a change in marital status.

Testing:
Identify a student selected for verification. Complete the Verification Worksheet and indicate a change in marital status. Confirm the Smart Form immediately navigates the user to the signature section and the Children and Dependent information does not display.

Problem:
For several COD Rebuild Pell Grant awards, the Pell amounts did not change after students gained additional Pell eligibility.

Cause:
The awards were imported as part of conversion. The import process set the User Accepted Amount on the Pell Grants to match the imported amount. When the students had increased eligibility, the system only repackaged the awards to that original amount.

Fix:
The system does not set the User Accepted Amount for "passive acceptance" funds that have an initial award status of Accepted.

Testing:
Configure the Title IV loans in Fund Setup to have a mix of initial status of Active Acceptance (Initial Status of "Offered") and Passive Acceptance (Initial Status of "Accepted"). Note the fund configuration for "Allow Students to Accept Lower Amounts or Decline Awards from the Student Portal." Make sure the Pell Grant is configured with Initial Status of Accepted and "Allow Students to Accept Lower Amounts or Decline Awards from the Student Portal" = No. Import several COD Rebuild files for each fund type, with each award's amounts lower than the maximum possible eligibility. Confirm the initial import and packaging preserves the imported amounts. Update the student's course data or other information so the awards now have higher eligibility. Package and repackage the student. Confirm the system repackages the Pell at higher amounts. Confirm all other funds with "Allow Students to Accept Lower Amounts or Decline Awards from the Student Portal" set to "No" are also repackaged at the higher eligible amounts. Confirm the Title IV loan funds with "Allow Students to Accept Lower Amounts or Decline Awards from the Student Portal" = Yes still remain at their original imported award amounts.

Problem:
A conversion student with a Parent PLUS loan started in the second term of a Scheduled Academic Year (SAY). When the student was packaged, the system canceled the PLUS loan.

Cause:
The system incorrectly calculated the eligible PLUS amount when the year-long loan period contained a rebuild award, and the loan was awarded for only part of the year.

Fix:
The system correctly calculates PLUS eligibility when a student has a PLUS loan on a shortened loan period that does not cover the full Academic Year.

Testing:
Find a test Dependent student who has a program start in the second or third term of a SAY AY, and who has a COD Rebuild Parent PLUS award. Process the student and the Parent PLUS loan through the Conversion Wizard. Package the student. Confirm the system does not cancel the loan. View the loan on the Academic Plan. Confirm the amount is correct. View the loan's Disbursement Details. Confirm the loan period dates are correct. View the Loans tab and select the PLUS loan. Confirm the Financial Award Period dates are correct.

Problem:
A student had a Manual Academic Year for a Scheduled Academic Year (SAY) calendar. When the SAY dates were exported to COD, the system did not export the same dates from the Manual Academic Year.

Cause:
The system did not apply the Manual Academic Year dates when the system set the data to export to COD.

Fix:
The system uses the Manual Academic Year dates when defining the AY dates to export to COD.

Testing:
Create a Manual AY for a SAY student, either manually or via script. Package the student. Confirm the manual AY dates are displayed on the Loans tab. Export the loan to COD; use the "COD Export Override" checkbox on the COD tab if needed. Review the COD export data. Confirm the Academic Year dates in the COD data match the Manual AY dates from Regent Award.

Problem:
Two students had programs starting in the second, Winter term of a Scheduled Academic Year (SAY) program. When the students were packaged, the system unexpectedly omitted the first, Fall term from the SAY on the Academic Plan.

Cause:
The students had fully-anticipated programs with no non-transfer courses. When Regent Award built the Academic Year, the system did not add the regular SAY terms to the Academic Year before the Anticipated program's start date.

Fix:
If a SAY student is anticipated to start a program after the SAY's starting term, the system adds in the regular SAY term(s) before the anticipated program's start date.

Testing:
Load an SBL and ISIR for a SAY test student who has only transfer data, and has an anticipated Program Start Date for the second or third term of the SAY. Package the student. Review the Academic Plan screen. Confirm the AY dates are correct. Confirm the earlier terms in the same SAY, prior to the program start date, are present and are marked with a purple "H" (Historic) marker.

Problem:
Regent Award was unexpectedly awarding student in the SAY term that was prior to program start term.

Cause:
Regent Award was adding Summer header via script solution resulting in incorrect Academic Year structure.

Fix:
Regent Award was updated to ensure that SAY Academic Year will be starting from Summer term if it has 'is Header' setting enabled. Setting is set via custom script.

Testing:
Run script to set 'is Header' setting to be true for Summer term in question. Package the student studying in SAY Quarter Term Program starting in Fall, Winter or Spring term. Make sure Academic Year is starting from Summer term.

Problem:
Regent Award failed to include the 4th term within a SAY when Academic Period Type was ‘Standard Term Quarter’.

Cause:
The system was not able to correctly set "IsHeader=True" flag for Summer. As result it was not included in the SAY.

Fix:
Regent Award logic was updated to add required flag for 'Standard Term Quarter' calendar type.

Testing:
Prior to testing, update Academic Period Type to Standard Term Quarter both for the program (via Program setup) the affected student is enrolled and for terms (via Term setup). Reload RNA setup. Run packaging. Review Academic Plan. All AYs should start with Summer term and contain 4 terms where Summer is the Header and Spring is the completing one.

Problem:
When some Scheduled Academic Year (SAY) AYs were exported to COD, the system always included the optional Summer header terms, regardless of the students' actual enrollment or loans in the Summer term.

Cause:
The system was adding the optional Summer header term to the SAY AY regardless of enrollment in the term.

Fix:
For non-Manual Academic Years, the system does not include optional Summer header terms in the AY dates when exporting to COD, unless the student has enrollment and loans in the term. If the student begins their program after the first term in the SAY AY, Regent Award will only add placeholder terms (marked as "Historic" in Regent Award) for the prior terms in the regular Scheduled Academic Year. However, if a student has a Manual Academic Year, the system will export the dates set by the Manual Academic Year.

Testing:
Package a SAY student who has a program start date in the second regular scheduled term in a SAY AY. Refresh the Academic Plan. Confirm the AY dates match the SAY AY dates and do not include the optional summer header. Review the Loans tab. Confirm the Academic Year dates match the SAY AY dates in the Academic Plan. Create a Manual AY for a SAY student, either manually or via script, containing the optional Summer header. Package the student. Confirm the Loans tab displays the manual AY dates. Export the loan to COD; use the "COD Export Override" checkbox on the COD tab if needed. Review the COD export data. Confirm the Academic Year dates in the COD data match the Manual AY dates from Regent Award.

Purpose of Script:
The build script sets the default Document Setup configuration values for the new e-signature setting, Override Signature Requirements. The script allows new Documents that need an e-signature to maintain their correct signature workflow.

Data Changed by the Script:
The script sets the "Override Signature Requirements" configuration values in Document Setup. The values depend on the type of documents.

• ISIR Verification Worksheet Smart Forms: set to ISIR Dependency Status
• Regent Access and State Financial Aid Application Questionnaires: set to Smart Form Dependency Questions
• All other Documents: set to Do Not Override.

The script does not make any changes to e-signature workflows for Documents already assigned to students.

How to Access the Script:
The build script is automatically included in the upgrade to the 5.3.2.0 release.

How to Test the Script:
Before the upgrade, identify a Document Requirement that is configured to use an Electronic Signature. Upgrade to 5.3.2.0. View the Document Setup configuration, Electronic Signature tab. Confirm the new value for Override Signature Requirements matches the expected value based on the type of document.

Purpose of Script:
This one-time script is used for initial integration with a school's external Document system. The script will trigger an export of all Student Document Requirements in the next Export Student Documents (XML) process. The purpose is to allow a school to export the complete set of existing Student Documents, such as when a school will start using the additional information about file attachments (enhancement in RS-19742).

Data Changed by the Script:
The script marks all student Document Requirements as needing to be exported. Normally, Regent only exports student Document Requirements if the Document has a change. The script flags all Documents as having a change, so the system will export every Student Document for the Export Document Requirement (XML) process.

How to Access the Script:
The script is available upon request, by a Customer Zone ticket.

How to Test the Script:
Ensure sFTP is available and configured. In a test database, run the script. In Regent's Export Process, run the Export Document Requirement (XML) process. View the Process Log and confirm the process has successfully finished. Review the resulting Export Student Documents file. Confirm the document information is exported successfully.

Purpose of Script:
The build script pre-populates the date values for two new configuration settings in Term Setup, SAP Evaluation Period Start Date and SAP Evaluation Period End Date. The purpose is to automatically set those configuration settings to the value formerly stored in the single Term Setup field, SAP Date. The former Term Setup SAP Date field has been renamed Reanticipate Academic Plan Date to match that field's remaining functionality.

Data Changed by the Script:
The script copies the current value of the former Term Setup setting, SAP Date into the two new configuration settings in Term Setup, SAP Evaluation Period Start Date and SAP Evaluation Period End Date.

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

How to Test the Script:
Before upgrading, view the Term Setup configuration screen. Note the value for the SAP Date field. Upgrade to 5.3.2.0. After the upgrade, log in and navigate to Term Setup. Confirm the new configuration settings, SAP Evaluation Period Start Date and SAP Evaluation Period End Date both have the same value as the former SAP Date field (which is now renamed Reanticipate Academic Plan).