8.16 Release 4.1.0.0 Notes

A-B-A Program Change Enhancements

Description:

Regent 8 has been enhanced to accommodate students returning to a prior program (which is referred to as the A-B-A program change scenario). It is common for a student to change programs during their college career. The student enrolls in and attends Program A for a period of time. The student then has a program change into Program B. Student may or may not attend Program B, but Program B has become the active program in Regent 8. The student then changes programs back to Program A.

To address this scenario, schools must provide A-B-A program changes following newly defined guidance:

• Use the "next" nodes on the <academicInformation> of the SBL to indicate that the student is returning to Program A.
  • When Program A is received in the "next" nodes of the <academicInformation> on the SBL, and a record for the same program already exists, Regent 8 will create a new record for Program A.

Automated Program Change Enhancements

Description:

Regent 8 has been enhanced to accommodate automatically completed program changes when the two programs involved in the program change are substantially equal. This section outlines the changes to Regent 8 for automating program changes to continue awarding financial aid to the student in the new program, without manually performing the program change within Regent 8 (when the two programs are substantially equal).

Configuration Changes

The following changes have been implemented in Regent 8 setup to accommodate the Automated Program Change enhancement.

Institution Setup – General Setting Screen

The Institution Setup screen allows a customer to choose whether or not to use the Automated Program Change functionality. If a client chooses to use the Automated Program Change functionality, and is also using Regent's Abbreviated Period functionality, the client can further customize their Regent 8 setup by choosing whether or not to automate program changes during an Abbreviated Period. The "Automated SE Program Changes in Abbreviated Periods" setup option is available only if the "Enable Abbreviated Periods (Non-term Only)" (this configuration option is in the General Settings section of Institution setup) and the "Automate Program Changes for SE Program Groups" options are set to a value of "Yes."

Institution Setup – General Tab – NEW Automated Program Change Settings Section

Program Groups Screen

Regent 8 offers a configuration area called "Program Groups" which allows schools to group programs together for specific functionality or processing within Regent 8. Program Groups allow schools to designate one or more programs as substantially equal to one another. The Program Group Name and Description can be customized by the school. The school can choose from the list of "Available Programs," to create a customized group. The "Available Programs" list contains all of the programs available at all campuses within the chosen institution. A few business rules apply to Program Groups:

• Programs cannot be grouped if the programs are at different campuses with different attending and reporting IDs.
• If the programs are at different campuses, and both campuses have the same attending and reporting IDs, the programs can be grouped.
• If the programs are at the same campus, the programs can be grouped.

The following enhancements have been implemented on the current Program Groups screen:

1. Label tab heading "General."
2. Add the "External Program Group ID" field to the UI.
3. Add the "External ID" field to the grid in the top half of the screen.

Institution Setup - Program Groups
Substantially Equal programs should be grouped together by the end user. The criteria that should be followed when grouping two programs is as follows:

• The coursework in the payment period the student is transferring out of is substantially similar (program applicable) to the coursework the student will be taking when he or she first transfers in the new program.
• The payment period definitions are substantially equal in length in weeks of instructional time, as applicable;
• The two programs have the same values in Regent 8 Program Setup for Academic Calendar Type, Academic Period Type, Academic Unit Type, Units in Academic Year, and Weeks in Academic Year.

Therefore, the following validation checks will also be implemented on the Program Group setup screen:

1. Validation that the External Program Group ID value is unique within the Institution.
2. Validate that grouped programs contain the same value on Program Setup for Academic Calendar Type, Academic Period Type, Academic Unit Type. Units in Academic Year and Weeks in Academic Year.

When the Program Group is "saved," Regent 8 will identify students with outstanding program change tasks involving a program that was updated (programs added to or removed from the Program Group). Regent 8 will then execute the Course Enrollment Roll-up process to re-validate whether the two programs involved in the program change are Substantially Equal or Not Substantially Equal as a result of the change made to Program Groups.

Automating the Program Change

When the SBL data is imported, Regent 8 will recognize the existence of a new <externalProgramId> for the student, which was provided in the <nextProgramExternalProgramId> field. The presence of the new External Program ID field will trigger the creation of a new Course Enrollment Program (CEP) record, essentially a new program record, for the student. When the student is packaged, and if the new Institutional setting for "Automate Program Changes for SE Program Groups" is set to "Yes," Regent 8 will recognize that a new program record exists for the student and will perform several checks in order to determine whether or not the program change can be automated.

• Have the current ("Program A") and next ("Program B") programs been placed into the same Program Group?
  • Yes.
    • Do the following fields have the same value on Program Setup for both programs: Academic Calendar Type, Academic Period Type, Academic Unit Type, Units in Academic Year, and Weeks in Academic Year.
      • Yes.
        • Is the program term (or non-standard term) or non-term?
          • Non-term:
            • Is there a "Finalized" R2T4 on the final payment period where there is actual enrollment of the current ("Program A") program?
              • Yes; then Regent 8 will generate a program change task to be completed manually by the end user. The end user will have the option to manually process this program change as substantially equal.
              • No; Regent 8 will automate the program change effectively designating the next ("Program B") program as the program to become active.
          • Term or Non-standard term: Regent 8 will automate the program change effectively designating the next ("Program B") program as the program to become active.
      • No. Regent 8 will generate a program change task to be completed manually by the end user. The end user will have the option to manually process this program change as Substantially Equal.
  • No; Regent 8 will generate a program change task to be completed manually by the end user. The end user will NOT have the option to manually process this program change as Substantially Equal, the program change must be processed as Not Substantially Equal.

Program Management Wizard

Not all program changes will be automated by Regent 8. Not Substantially Equal program changes will need to be manually processed and, in most cases, cannot be overridden to Substantially Equal. However, a new exception to this rule has been implemented. As described above, if the two programs involved in a program change have been grouped into a program group, and have the same values on Program Setup for both programs in the following fields: Academic Calendar Type, Academic Period Type, Academic Unit Type, Units in Academic Year, and Weeks in Academic Year, Regent 8 will determine the two programs to be substantially equal to one another and automate the program change. If only Academic Calendar Type, Academic Period Type, Academic Unit Type values match between the two programs, and Units in Academic Year, and Weeks in Academic Year do not match between the two programs, Regent 8 will allow the end user to override the Not Substantially Equal determination on the program change to process the program change as Substantially Equal, manually within the PMW.
If a program change has been incorrectly processed or automated, a school can remove the program change if the new program has not yet become active. A program becomes active once the program completion date for Program A is in the past or the start date of Program B has arrived. Until the point that the new program is active, the PMW will still present the program change options to the end user. In the programs grid, the end user should choose "Remove" for a program that they do not want the student to change to, and finish out the remaining steps of the wizard. This will effectively cancel the program change.

Program Management Wizard

Activity Log Entries

Regent 8 will create an activity log entry at the time the program change is automated, which indicates that Regent 8 executed the program change.
Sample Activity Log text: The Program Change from BS in Business FP, Project Management FP to BS in Business FP, Business Administration FP, was automated based on the determination that the programs are Substantially Equal.
Regent 8 will also create an activity log entry at the time the new program becomes active.
Sample Activity Log text: The BS in Business FP, Business Administration FP is now the student's active program.

Reporting

A new report called "Setup – Program Group" was created to provide schools the ability to view current program group data; please see report details below.
Parameters / Filters:

• Enterprise
• Institution
• External Program Group ID

Output Columns:

• (Program Group) Name
• External Program Group ID
• (Program Group) Description
• Program Name
• Campus
• Program Type
• Credential
• Academic Calendar Type
• Academic Period Type
• Academic Unit Type
• Units in Academic Year
• Weeks in Academic Year
• Created Date (date the program group was created)
• Last Modified Date

Workflow

Automated Pre-start and X-day Post-start Program Changes

Description: 

Schools may allow students the flexibility of changing programs multiple times prior to their start date. Currently, completion of these program changes is a manual process within Regent 8 . Regent 8 creates a program change task, which must be manually completed by an end user. If the program change is not substantially equal, Regent 8 creates a new Academic Year (AY) for the start of the new program, which increments the student's starting AY on their Regent 8 Academic Plan to AY2, or higher.
Schools may also allow a student to change programs within a certain number of days of the start of the student's Academic Plan in Regent 8.
This section outlines the changes required to Regent 8 to automate these pre-start and X-day post start program change scenarios in a manner that essentially replaces the student's starting program in Regent 8 with the newly provided starting program. The student's starting AY in Regent 8 will remain AY1.

Configuration Changes

The Institution Setup screen will allow a customer to choose whether or not to use the Automated Pre-Start Program Change functionality. If a client chooses to use the Automated Pre-start Program Change functionality, Regent 8 will attempt to automate program changes occurring prior to the start of the student's Academic Plan in Regent 8 if the student has no paid awards (other than paid rebuild awards that would exist in AY0) on the existing program. If a client chooses "Yes" in the "Automated Pre-start Program Changes" field, the "Automate Program Changes within X days of Plan Start" field will become available (the field will remain inactive if "No" is chosen in the "Automated Pre-start Program Changes" field). The value entered in the "Automate Program Changes within X days of Plan Start" field will determine how many days after the start of the student's academic plan in Regent 8, that a program change can automated and take effect as of the start date. A negative value is not a valid entry for this field. Regent 8 will attempt to automate program changes occurring within the first X days of the start of the student's Academic Plan in Regent 8 if the student has no paid awards (other than paid rebuild awards that would exist in AY0) on the existing program. Access to both of these configuration options are controlled by Permissions.

Institution Setup – General Tab – NEW Automated Pre-Start Program Change Configuration Settings

Automating the Program Change

When the SBL data is imported, Regent 8 will recognize the existence of a new <externalProgramId> for the student. If the program start date for the student's current active program is today or a date in the future, or if the program change is occurring within the configured number of days from the start of the student's academic plan in Regent 8 (see "Post-Start Program Changes" section below), Regent 8 will automatically switch the student's active program to the newly received <externalProgramId>, making the new program the starting program for the student. When the actual start date (backed by course data) is available, Regent 8 will use that date to determine whether the active program's start date is today, or a future date. When the actual start date is not available, Regent 8 will use the anticipated start date (<programStartDate> provided on the SBL).
When the student's "starting program" has been updated, the academic plan will be updated with the new program information, and the starting Academic Year will be AY1. If the student does not have paid awards (other than paid rebuild awards that would exist in AY0) on the existing program, and those awards have been originated at COD, Regent 8 will update the awards with the new program data and re-export the award data to COD. If a student changes both program and start date, such that the new program start date now falls into a different FAY in which funds were originally originated, the awards must be cancelled, and new awards with a new Financial Award ID must be created by Regent 8. In this case, the student will have to re-accept the new awards on the portal. If the student has paid awards (other than paid rebuild awards that would exist in AY0) on the existing program, the pre-start program change will not be automated by Regent 8. These program changes must be processed manually using the Program Management Wizard in Regent 8.

Manual Academic Years

There may be two types of manual academic years existing on the student's Academic Plan prior to the pre-start program change; system generated manual academic years, or non-system generated (user created) manual academic years. For both types of manual academic years, regardless of whether or not the student's program start date changes at the time of the program change, Regent 8 will update manual academic year records with the new program data and they will remain on the student's Academic Plan post-program change.
Additional functionality has been implemented in cases when the start date of the prior program and new program differ and user created manual academic years (including Abbreviated Periods) exist on the student's academic plan. As stated above, Regent 8 will update the manual academic years with the new program information, and they will remain on the student's Academic Plan post-program change. However, these user-created manual academic years may now require updates due to the change in the start date of the student's Academic Plan. Regent 8 will alert the end user when this scenario occurs by generating a task (described in the "Task" section below) advising the user to review the student's manual academic year data, post-program change.

Program Changes Within X Days of Start

If a school performs a post-start, retro-dated program change within X days of the start of the student's Academic Plan, Regent 8 will automate the program change in the same manner, and using the same rules, as described above. The number of days is configurable, as described above. Once the student has paid awards in the first academic year of the existing program, Regent 8 will not automate this program change scenario.

Tasks

If user created manual academic years existed on the student's Academic Plan prior to the pre-start program change, Regent 8 will generate a task to inform the user that this data should be reviewed post program change. The "Review Automated Program Change with Manual AY" task will be triggered using the following criteria:

• The student has had an automated pre-start program change, and
• The start date of the program was changed from the old to new program, and
• User created manual academic years (including Abbreviated Periods) existed on the student's Academic Plan prior to the program change.

The task will notify the user of both the old and new program names, as well as the start date of each of the programs. If the student has several pre-start program changes, the task will be triggered each time the program changes, as long as the above criteria is met.

Activity Log Entries

Regent 8 will create an activity log entry at the time the program change is automated, which indicates that Regent 8 executed the program change. 

Sample Activity Log text: The BS in Business FP, Project Management FP Program was replaced as the starting program on the student's Academic Plan because a Program Change occurred prior to the start of the student's Academic Plan. BS in Business FP, Business Administration FP is now the starting program for the student.

Workflow

Allow Overlapping Academic Years for Track Changes

Description:

When a student changes tracks, their academic plan must be modified such that the new track starts at the beginning of a new Academic Year (AY). The new AY can overlap with the prior AY (from the prior track). Regent 8 has been enhanced to allow for the creation of a new manual AY at the start of the new track, that overlaps with the dates of the previous AY. The end user will no longer need to make use of the "Manually Shortened AY" checkbox in order to process a track change.
Regent has added a checkbox on the Manual AY editor within the Program Management Wizard (PMW), next to each term (displayed on the right side of the screen), to allow the term to be marked as "Allow Overlap." Designating a term as "Allow Overlap" will indicate to Regent 8 that another AY's dates will overlap with the dates of the "overlap" terms. When this checkbox is selected on a term in the middle of an AY, all subsequent terms in that AY must also be designated as "Allow Overlap."

Example:

• AY1 consists of 1603C, 1604C, and 1701C. 1701C is designated as "Allow Overlap." AY2 can be setup such that the start date of AY2 can be as early as the day after the end date of 1604C.

When this type of valid overlap is created, Regent 8 will display a yellow "warning" flag for Overlapping AYs in the PMW. The end user can override the flag in order to process the track change with the full length of the AY (which contains the first track the student attended).
A red "error" flag for Overlapping AYs will be thrown when the terms of two AYs overlap one another, and the new "Allow Overlap" checkbox was not used to create the overlap. This flag cannot be overridden by the end user; the AYs must be modified to properly create the overlap.

Processing a Track Change

From the PMW, select "Manage Academic Years/Loan Periods."

Next, select the AY containing the track the student is LEAVING.

When the Manual AY Editor opens, first ensure that all of the original terms for the AY are displayed in the multi-select box on the right side of the screen. For any terms in that AY in which the student did not attend or withdrew, select the "Allow Overlap" checkbox next to the term name. When the "Allow Overlap" checkbox is selected on a term in the middle of an Academic Year, all subsequent terms in that Academic Year must also be designated as "Allow Overlap." Designating a term as "Allow Overlap" will indicate to Regent 8 that another Academic Year's dates will overlap with the dates of the "overlap" terms. Note: DO NOT check the "Manually Shortened AY" checkbox. This feature is no longer needed in order to process track change scenarios.
Make any required edits to the loan periods within the AY to reflect the correct length of the loan period (the user will need to determine, on a case by case basis, how the loan period will need to be managed for the student, depending on the time of withdraw and funds retained in the final term of the prior track). Click "Save" on the Manual AY Editor.

If the user has selected the "Allow Overlap" checkbox on any term, the user will be presented the following warning message:
"Please ensure that the student is not actively enrolled in two different terms at the same time."
When the user selects "OK" on the warning message, Regent 8 will continue and save. If the user selects "Cancel" on the warning message, Regent 8 will return the user to the Manual AY Editor and will not save.

Select the AY where the student will begin the new track.

When the Manual AY Editor opens, ensure that all of the correct terms for the AY are displayed in the multi-selection box on the right side of the screen. Do not check the "Allow Overlap" checkbox for the terms in the new track/AY that will overlap the prior AY, because these terms will have active enrollment and awarding. Note: DO NOT check the "Manually Shortened AY" checkbox. This feature is no longer needed in order to process track change scenarios.
Make any required edits to the loan periods within the AY to reflect the correct length of the loan period (the user will need to determine, on a case by case basis, how the loan period will need to be managed for the student, depending on the time of withdraw and funds retained in the final term of the prior track). Click "Save" on the Manual AY Editor.

Click "Continue" at the top of the PMW.

After processing, a yellow "warning" flag for Overlapping AYs will display for the previously, modified AYs (from the instructions above). Select the "Override" checkbox next to those flags and select "Continue" from the PMW, once again.

Finish moving through the steps of the PMW until the wizard is complete. View the academic plan for the student to see that the AYs involved in the track change now overlap, and the new track begins at the start of a new AY.

Select the student "Task" tab, and open the "Review Track Change" task. Close out the "Review Track Change."
Correcting an incorrectly processed Track Change

From the PMW, select "Manage AY."

Next, select the AY containing the track the student has left.
When the Manual AY Editor opens, first rebuild the AY by ensuring that all of the original terms for the AY are displayed in the multi-select box on the right side of the screen. For any terms in that AY, in which the student did not attend or withdrew, select the "Allow Overlap" checkbox next to the term name. When the "Allow Overlap" checkbox is selected on a term in the middle of an Academic Year, all subsequent terms in that Academic Year must also be designated as "Allow Overlap." Designating a term as "Allow Overlap" will indicate to Regent 8 that another Academic Year's dates will overlap with the dates of the "overlap" terms. Note: DO NOT check the "Manually Shortened AY" checkbox. This feature is no longer needed in order to process track change scenarios. If this box is checked on the Manual AY editor, uncheck it.
Make any required edits to the loan periods within the AY to reflect the correct length of the loan period (the user will need to determine, on a case by case basis, how the loan period will need to be managed for the student, depending on the time of withdraw and funds retained in the final term of the prior track). Click "Save" on the Manual AY Editor.

If the user has selected the "Allow Overlap" checkbox on any term, the user will be presented the following warning message:
"Please ensure that the student is not actively enrolled in two different terms at the same time."
When the user selects "OK" on the warning message, Regent 8 will continue and save. If the user selects "Cancel" on the warning message, Regent 8 will return the user to the Manual AY Editor and will not save.

Select the AY where the student will begin the new track.
When the Manual AY Editor opens, ensure that all of the correct terms for the AY are displayed in the multi-selection box on the right side of the screen. Do not check the "Allow Overlap" checkbox for the terms in the new track/AY that will overlap the prior AY, because these terms will have active enrollment and awarding. Note: DO NOT check the "Manually Shortened AY" checkbox. This feature is no longer needed in order to process track change scenarios.
Make any required edits to the loan periods within the AY to reflect the correct length of the loan period (the user will need to determine, on a case by case basis, how the loan period will need to be managed for the student, depending on the time of withdraw and funds retained in the final term of the prior track). Click "Save" on the Manual AY Editor.

Click "Continue" at the top of the PMW. After processing, a yellow "warning" flag for Overlapping AYs will display on the previously, modified AYs (from the instructions above). Select the "Override" checkbox next to those flags, and select "Continue" from the PMW, once again.

Finish moving through the steps of the PMW until the wizard is complete.
View the academic plan for the student to see that the AYs involved in the track change now overlap, and the new track begins at the start of a new AY.

Select the student "Task" tab, and open the "Review Track Change" task. Close out the "Review Track Changes."

ISIR Levels for Graduate and Undergraduate Programs

Description:

Regent has enhanced awarding when students do not have an active ISIR that matches their program's Graduate or Undergraduate level. Regent 8 considers an ISIR to be a Graduate level ISIR when a student answers "Yes" to the FAFSA question 48 (ISIR Field 70), "Working on a Master's or Doctorate Program?" If a student answers "No" or leaves that question blank, Regent 8 considers the ISIR to be an Undergraduate-level ISIR. The ISIR's level is shown by the "Grad" Y or N value on the ISIR tab.
Awarding normally needs a matching ISIR at the same level as the program. For example, if a student has a Graduate ISIR, but enrolls in an Undergraduate program, Regent 8 will not use the Graduate ISIR for packaging the student's Undergraduate awards. Regent 8 also cancels any of the previously packaged awards that had used the mismatched ISIR. The same behavior occurs if a student has an Undergraduate ISIR and enrolls in a Graduate program. Regent 8 cancels any previous awards created with the mismatched ISIR, and will not package new Graduate awards with an Undergraduate ISIR. If a school is configured to award based on an "Estimated" EFC, Regent 8 will still try to create estimated awards for the program based on the existing ISIR's EFC. Regent 8 also notes the ISIR-program mismatch as a warning in the packaging log. When Regent 8 users are processing a Program Change and no matching active ISIR is available, the PMW will display an alert and prompt the user to select an active ISIR.
To ease the transition for the new enhancement, Regent is "grandfathering in" existing students who currently have a mismatched ISIR in the system. The affected students currently have an active Graduate ISIR in an Undergraduate program, or have an active Undergrad ISIR while in a Graduate program. For those students' current ISIRs only, Regent will do a one-time data update as part of the code upgrade (no separate scripts needed). The data update will let the students continue to be packaged as if their existing active ISIR correctly matched their program level. Those students can continue using that mismatched ISIR as long as it remains their Active ISIR. If any subsequent or corrected ISIRs are loaded for those students, the new ISIRs will need to match and have a correct answer for Field 70. Any other, future students with mismatched ISIRs will also need to correct their response to Field 70.

New packaging validation messages for manual awards in a cancelled status

Description: 

Regent added two packaging validation messages to alert users that a manual award requires modifications to ensure students receive full eligibility. Examples of these new messages are as follows:

• Validation #1: "{Student Name and ID}: Award [{Award ID}] [{Fund Name}] is invalid - cancelled award amount exceeds paid amount."
• For example: Error validating plan for Student [2425]: Award [2396695] (Federal Direct Unsubsidized Loan) is invalid - cancelled award amount exceeds paid amount.
• Validation #2: "{Student Name and ID}: Another Award [{Award ID}] [{Fund Name}] in the Award Period is invalid - cancelled award amount exceeds paid amount."
  • For example: Error validating plan for Student [2425]: Another Award (Award [2396695] (Federal Direct Unsubsidized Loan)) in the Award Period is invalid - cancelled award amount exceeds paid amount.

There are cases where a user may have edited a cancelled award (or changed the award's status to cancelled), via the Modify Award Wizard (MAW), and the resulting award's gross amount exceeds the award's paid amount. In which case, the student may still be eligible to receive disbursements for the award. Therefore, Regent added a packaging validation message (Validation #1 above) to alert users to review these manual awards. To resolve the error message, the user must reduce the award's gross amount to not exceed the award's paid amount via MAW. Validation #1's message is presented to the user during any Regent 8 packaging process. Regent 8 will only present the new validation message if the award meets the following criteria:

• Award is Title IV.
• Award is manual.
• The award status is cancelled.
• The award does not have a disbursement that is associated with an R2T4 or PWD.

There are other cases where users may have edited another award that resides on the same award period as the cancelled, manual award (mentioned above). In which case, Regent 8 will present the second new validation packaging message (Validation #2). This message is intended to alert users that they must first correct the other cancelled, manual award's amount before Regent 8 will allow other award modifications on the Award Period. Validation #2's message is only presented to the user within the Modify Award Wizard or Add Award Wizard (MAW/AAW).

COD updates

2017 – 2018 COD Schema Updates

Description:

Processing of the new 4.0c schema begins on March 24, 2017. As of this release, Regent 8 fully supports the new schema updates which now require student program information to be reported at the disbursement level. In the previous 3.5.0.12 release, support was added to allow the import of the unsolicited, system-generated files that are a part of normal COD processing and rebuild/year-to-date files that are used for data conversion.
The 4.1.0.0 release includes full processing support for the 2017-2018 award year using the new schema:

1. Awards for the 2017-2018 award year can now be exported in the new schema (4.0.c) and receive the Standard Response (RS) file in the same schema.
2. Awards in prior award years will continue to be exported in the prior (4.0.b) schema and receive the Standard Response (RS) file in the same schema. COD will continue to support this until the 2016-2017 aid year ends.
3. All award years for system generated files in the new schema (4.0c) can be imported into Regent 8; please see below for all file types which are displayed on the COD tab during the COD Import process:
   • Web-generated (WB) – used to update award records in Regent 8.
   • Credit Status (CS) – used for disbursement validation and to satisfy credit decision documents.
   • PLUS Acknowledgement (SP) – used to satisfy credit decision documents.
   • Entrance Counseling (EC) – used to satisfy entrance counseling documents.
   • Booking notification (BN) – used for displaying on COD tab only.
   • Direct Loan MPN response (PN) – used for disbursement validation and to satisfy MPN documents.
   • Pell Negative Disbursement (ND) – used to trigger Regent 8's Pell Negative Disbursement task.
   • Subsidized Usage (SU) – used for displaying on COD tab only.
   • TEACH Grant Agreement to Serve (AT) – used to satisfy TEACH Agreement to Serve documents.
   • COD DL Rebuild and Pell/TEACH year-to-date files using the new schema can now be imported.

Changes to Enrollment Status value sent to COD beginning 17/18

Description: 

For COD export files, beginning in award year 2017-2018 and forward, the EnrollmentStatus field, which is exported at the disbursement level, is required. Regent 8 has been updated to ensure proper enrollment status reporting of Direct Loans, TEACH, and Pell. The functionality described below will apply to all award years, both 2017-2018 and prior. Note: Pell is unaffected by applying this enhancement to all award years. Prior to 2017-2018, Pell awards exported out of Regent 8 using the 4.0b schema did not require the enrollment status field for Pell, therefore, it is not included on the COD export file from Regent 8.

Anticipated vs. Actual Enrollment Status

• Regent 8 will allow the enrollment status exported at the time of origination to be based on anticipated or actual enrollment.
• Any updates to the award or disbursement amount that lead to a COD export, if the disbursement is not paid (DRI=false), will also trigger a COD export from Regent 8 to update the enrollment status at COD. This enrollment status can be based on anticipated or actual enrollment as long as the disbursement is DRI=false.
  • If the disbursement has not yet been paid (DRI=false), and the disbursement is being cancelled at COD (previously > $0, but now $0), Regent 8 will NOT update the enrollment status on the disbursement, but will instead use the last COD accepted enrollment status as the enrollment status to be exported to COD when cancelling the disbursement.
  • If the disbursement has been paid (DRI=true), and the disbursement is being cancelled at COD, Regent 8 will NOT include the enrollment status tag in the COD export file, because there would be no change to the value of the tag,
• Regent 8 will ensure that when the disbursement is exported as DRI=true, the enrollment status exported to COD at that time will be based on actual enrollment. If actual enrollment or a valid enrollment status for the award cannot be determined, Regent 8 will provide the ability to include a manual Enrollment Status Override (for use on COD exports only).
• Regent 8 has been updated to provide the enrollment status tag on every disbursement, for every COD export.

Determination of Actual Enrollment Status value to export to COD

Regent 8 will use the following order of precedence when determining the enrollment status to be exported to COD at the time of disbursement (DRI=true). Per recent Department of Education guidance, Regent 8 will use the enrollment status reported for the first DRI=true disbursement for a term, for all subsequent disbursements for that term, as well as for any subsequent adjustments/refunds to those disbursements.

• Pell and TEACH – order of precedence for actual enrollment status value to be exported to COD:
  1. Manual Enrollment Status Override, if available. If this value is NULL or none,
  2. Use the first exported enrollment status on the first DRI=true disbursement within that payment period. If this value is NULL or none,
  3. Use the R2T4 Pell Recalculation Enrollment Status, if the student's enrollment is actual.
  4. If the enrollment is anticipated, or the R2T4 Pell Recalculation Enrollment Status is NULL or none, then use the Pell Recalculation Enrollment Status, if enrollment is actual.
  5. If the enrollment is anticipated, or the Pell Recalculation Enrollment Status is NULL or none, then use the Census Recalculation Enrollment Status, if enrollment is actual.
  6. If the enrollment is anticipated, or the Census Recalculation Enrollment Status is NULL or none, then use the RNA calculated enrollment status, if enrollment is actual.
  7. If the enrollment is anticipated, or the RNA calculated enrollment status is NULL or none, then require manual entry via the enrollment status override.

• Direct Loans – order of precedence for actual enrollment status value to be exported to COD:
  1. Manual Enrollment Status Override, if available. If this value NULL or none,
  2. Use the first exported enrollment status on the first DRI=true disbursement within that PP. If this value is NULL or none,
  3. RNA calculated enrollment status, if enrollment is actual. If the enrollment is anticipated, or the RNA calculated enrollment status if NULL or none, then require manual entry via the enrollment status override.

Manual Enrollment Status Override

Step 3 of the Modify Award Wizard (MAW) is being enhanced to provide the ability to override the enrollment status that is exported to COD for disbursements within a payment period. This feature is only available for COD-based awards, and will be used ONLY for COD export purposes at this time.
As with course overrides, Regent 8 will display the system calculated enrollment status value, based on actual enrollment, that would otherwise be exported to COD, as well as provide a drop-down field where an override value can be chosen. If the user removes the enrollment status override value, Regent 8 will revert to using the system calculated enrollment status for COD export purposes. Valid enrollment status override values for Pell and TEACH awards are Full-time, Three-quarters-time, Half-time and Less-than-half-time. Valid enrollment status override values for Direct Loan awards are Full-time, Three-quarters-time, and Half-time. Note: If the student's enrollment is anticipated, the MAW will display "None" as the Regent 8 calculated enrollment status. This value will be updated when the enrollment has become actual.
A disbursement level "COD Export Override" has also been added to Step 3 of MAW. Checking the "COD Export Override" checkbox will force the disbursement (and its related award data) to be exported on the next COD export, regardless of whether or not any award or disbursement related data changed. The COD Export Override checkbox may also be used on its own or in conjunction with the enrollment status override field when the user wants to force disbursement data to be included in the next COD export.
Both of these new fields are permission based. Activity log entries will be logged to provide an audit trail of usage to the manual enrollment status override including setting the override value, changing the override value, or removing the override value.

Disbursement and program association updates due to 17/18 COD changes

Description:

Prior to 2017-2018, updates to program related fields did not set the hasCODChanges flag in Regent 8; meaning, these changes did not initiate an export to COD from Regent 8.

• Published Program Length Weeks
• Weeks in Program Academic Year
• Special Programs Code
• Program Credential Level

However, it will be important for disbursements to be re-exported to COD in the event of a program change, due to these program related fields being moved to the disbursement level in the COD 4.0c schema. To solve for this issue, Regent 8 will queue a student for re-export to COD in the event of a program change. During the re-export to COD, Regent 8 will associate the paid disbursements to the program that the student was attending. However, there are three exception cases to this rule: late disbursements, Post-Withdrawal Disbursements (PWDS), and retro-dated program changes. Please see examples below.

Late Disbursements:

If a disbursement is not paid (DRI=false) after the end date of it's associated payment period and the disbursement is released (DRI=true) after the start date of the next program (Program B), then the disbursement remains associated to the original program (Program A).

Example:

PWD:

If a disbursement is set by a R2T4, the disbursement will be associated to the program associated to the payment period under which the R2T4 is being performed (Regent 8 will not update the disbursement to reflect the next program).

Example:

Retro-dated Program Change:

If the next program's (Program B) start date matches (or is prior to) the payment period start date then the next program (Program B) replaces the original program (Program A) for the payment period, in which case, all disbursements are associated to the next program (Program B), regardless of the disbursement's paid or unpaid status.

Example:

Nonterm to nonterm, mid-payment period, substantially equal Program Change:

In the case of a nonterm to nonterm, mid-payment period, substantially equal (SE) program change, current Regent 8 behavior reports all disbursements for the payment period using the program information for the program to which the student has transferred during the payment period. For example, a student is attending Program A in academic year (AY) 1, payment period (PP)1.  The student has a paid disbursement for Program A.  The student then moves to Program B (in the same PP) via a substantially equal (SE) program change.  The disbursement paid under Program A will be updated with Program B's program data, and reported to COD.  While this behavior is not necessarily incorrect, Regent does plan to offer more granular performance in the future.

TEACH Grant, Pell YTD, and Direct Loan Rebuild files updated for 2017 – 2018

Description:

Regent updated the COD Rebuild data record layouts for TEACH Grant, Pell YTD, and Direct Loan Rebuild files to support 2017-2018 files loaded via Regent 8's COD Rebuild Process.

Regulatory Updates for ISIR Reject Codes 2015 – 2016 and 2016 - 2017

Description:

To accommodate the Annual Regulatory Updates for 2015-2016 and 2016-2017 ISIR Reject Codes, Regent updated the hover text message content that displays in the Reject Codes column on the student's ISIR tab. Reject Codes 1, 4, 11, 20, and 21 now display the following messages:

• Reject Code: 1
  • "For a dependent student, if the Student's Asset Threshold Exceed field equals "Yes" or blank on the current transaction, provide the following: Student's Cash, Savings and Checking, Student's Real Estate/ Investment Net Worth, and Student's Business/ Investment Farm Net Worth. Also, if the Parents' Asset Threshold Exceed field equals "Yes" or blank on current transaction, provide the following: Parents' Cash, Savings, and Checking, Parents' Real Estate/ Investment Net Worth, and Parents' Business/Investment Farm Net Worth. For an independent student, if the Student's Asset Threshold Exceed field equals "Yes" or blank on current transaction, provide the following: Student's Cash, Savings and Checking, Student's Real Estate/ Investment Net Worth, and Student's Business/ Investment Farm Net Worth."
• Reject Code: 4
  • "Student's marital status date on the initial application is greater than the date the application was signed Or Student's marital status date on a correction transaction is greater than transaction receipt date."
• Reject Code 11
  • "If the student is dependent, review and correct at least one of the following: either Parents' Marital Status, or parent 1 Income From Work and parent 2 Income From Work. If the student is independent, review and correct at least one of the following: either Student's Marital Status or Student's Income Earned From Work and Spouse's Income Earned From Work.
• Reject 20
  • "If the student is dependent, review and correct at least one of the following: Student's tax return status or student's income or Parents' tax return status or income for the parent 1 and parent 2.If the student is independent, review and correct at least one of the following: Student's tax return completed status or income for the student and spouse."
• Reject Code: 21
  • "Student's corrected marital status date is greater than or equal to the application receipt date and less than or equal to the transaction receipt date."

ISIR Tab

Updates to headings on ISIR tab

Description:

Regent8 was enhanced by relabeling the "Sort Order" column on the ISIR tab to clearly describe the numbering that is displayed. The following headings were updated:

• "ISIR Field" on the main ISIR question tabs for ISIR Details and ISIR Verification/Correction Wizard, as well as the Compare ISIR Wizard.

• "CPS Correction #" on Verification group tabs for ISIR Details and ISIR Verification/Correction Wizard.

ISIR Print Format Improvements

Description:

Regent has enhanced the ISIR printed output feature to align with the Department of Education's ISIR Guide. Regent 8 has maintained the ability to print each individual ISIR, present or past, by clicking on the "View Report" button on the ISIR tab. However, the new printed output is concise, easier to read, and closely mimic's the ISIR Sample Output Document layout provided by DOE. The complete report can be printed at once.

Example:

Ability to Benefit (Student Eligibility Code) related field names updated for COD documentation

The following Ability to Benefit (Student Eligibility Code) related field names have been updated on the Student Details tab in Regent 8 to reflect the corresponding text field names used in the COD documentation.

Description:

1. Ability To Benefit Code:

1. Ability To Benefit Test Administrator Code:

1. Ability To Benefit Test Code:

Import SBL Process

Assume Attendance Enhancement

Description:

Regent8 has been enhanced to assume that the student maintains attendance in the course until such point in time that the course ends, or is withdrawn, whichever comes first. This section outlines the changes made to Regent 8 to implement this functionality. 

Configuration Changes

The Institution Setup screen allows a school to choose whether or not to use the Assume Attendance functionality. If a school sets the Assume Attendance value to 'Yes', and the "Effective as of" date is set, Regent 8 will assume attendance on courses whose end date is on or after the "Effective as of" date. Attendance will be assumed as of today's date (or the course withdraw or course end date), if at least one indication of attendance has been provided on the course via either the SBL or Course Overrides. This indication of attendance can be provided in the form of a Last Attended Date (LDA) or via the <attendance> flag on the SBL file, both of which are on the course level in Regent 8. When the Assume Attendance functionality is set to a value of "No," Regent 8 will calculate attendance based on the attendance data provided for the course on the SBL only. For example, if the last attended date on the course is set to a date of January 1, 2017, Regent 8 will calculate attendance as of January 1, 2017, not as of today's date (which is future of January 1, 2017). Note, the "Effective as of" date can be a date in the past from today.

Institution Setup – General Tab – NEW "Assume Attendance" Configuration Setting 

This configuration option will also be available at the Campus and Program setup levels in Regent 8. Programs can inherit the configured value from the Campus, and the Campus can inherit the configured value from the Institution. Furthermore, a new course level override has been implemented that will allow the school to control the ability to assume attendance at the course level. The default course level value will inherit from Program Setup.

Calculating Attendance

When the configuration setting to Assume Attendance is set to a value of "Yes," Regent 8 will determine if the LDA for a given course needs to be updated to today's date (or to the course's withdrawal date or end date as appropriate per the scenarios below) at the time of SBL import and just prior to packaging. During the both the SBL import process and when packaging is executed, Regent 8 will determine if we have received at least one indication of attendance for the course, and if so, update the last attended date for the course to today's date (or to the course's withdrawal date or end date as appropriate per the scenarios below). Some schools may load their SBLs during the day, and run packaging overnight, causing the SBL process and the packaging process to be executed on different days. For courses in which Regent 8 has received at least one indication of attendance, Regent 8 will update LDA BEFORE packaging is executed for the student, in order to ensure that the packaging process is using the most up to date data for the student. 
The process that reviews course data to determine whether or not the assumed LDA needs to be updated will use the following criteria in order to determine which courses to assess:

• Assess any course where the end date => (is on or after) "Effective as of" date and the most recent LDA is less than the withdraw date or end date of the course and the <attendance> flag = true (Note: when the <lastAttendedDate> value is provided on a course record, Regent 8 automatically sets the <attendance> flag = true)
• Assess all remedial and repeat courses even if they have become disqualified remedial units or disqualified repeat units
• Ignore transfer courses
• Ignore course withdrawn before the course start date
• Ignore deleted courses

An additional override field has been added to the course edit screen that will allow a school to turn off the Assume Attendance functionality for a single course. When the courses screen is in "edit" mod, the "SBL Value" column for the "Assume Attendance" field will display the value being used from configuration setup. In other words, if Assume Attendance is set to "Yes" for the student's program, then "Yes" will be shown in the "SBL Value" column for all of the student's courses. If a school has chosen NOT to use the configuration option to Assume Attendance, the override field can also be used to turn ON the assume attendance functionality for a single course. User access to this new feature is controlled by permissions.

Additional Business Rules

If a school has chosen the configuration option to Assume Attendance and provided at least one confirmation of attendance on the course (LDA or <attendance> flag) and the school updates the course start or end dates so that the LDA now falls outside of the bounds of the course start / end date:

• If the course start date is set to a future date, Regent 8 will NULL out the assumed LDA and set the <attendance> flag to a value of false.
  • If the <lastAttendedDate> is then imported on the SBL, and the date still falls outside of the bounds of the course, the SBL import process will not allow the update.
  • If the <attendance> flag is then re-imported on the SBL with a value of true, Regent 8 will accept this update and assume attendance for the course once the start date of the course has arrived.
• If course has already ended, Regent 8 will update the LDA to the course withdraw date or end date whichever comes first.

If a school has chosen the configuration option to Assume Attendance, and Regent 8 receives a withdraw date that is prior to the current assumed LDA, Regent 8 will adjust the assumed LDA value to the withdraw date.
If a school has chosen the configuration option to Assume Attendance, and Regent 8 receives a withdraw date that is prior to the course start, Regent 8 will NULL out the assumed LDA and set the <attendance> flag to a value of "false."
If a school has chosen the configuration option to Assume Attendance, and the LDA is updated to a date earlier than the date we are assuming. Regent 8 will continue assume attendance as of today's date.
If a school has chosen the configuration option to Assume Attendance, and the LDA is updated to a different date via course overrides, Regent 8 will continue to assume attendance as of today's date.
If a school has chosen the configuration option to Assume Attendance, and the LDA is updated to "blank" via course overrides, Regent 8 will null out the LDA value, however, in order for Regent 8 to stop assuming attendance for this course, the <attendance> flag will also need to be set to a value of "false" using course overrides. The course overrides screen has been enhanced to prompt the user to consider updating the <attendance> override field when the LDA value is overridden, and the LDA value when the <attendance> field is overridden. Alternatively, a school can use the new course level override option described above to stop assuming attendance for a single course.
When attendance data is removed from a course in which Regent 8 was previously assuming attendance, census units/weeks totals and census enrollment status will be recalculated by Regent 8. A school who has chosen to freeze Cost of Attendance (COA) as of the census date will need to manually adjust COA as needed per school policy.

"Effective As Of" Date Business Rules

Attendance will be assumed in courses whose end date => (is on or after) the "Effective as of" date.

• If the assume attendance functionality is "turned on" in configuration, used for a period of time, and then turned off, at the time the functionality is "turned off," there will be no change to attendance or course data to courses for which Regent 8 assumed attendance.
  • If the assume attendance functionality is "turned on" again at a later date (after being on, then off), Regent 8 will simply begin assuming attendance in courses whose end date => (is on or after) the new "Effective as of" date.

Activity Log Entries

Regent 8 will create an activity log entry, at the time of SBL import, to indicate that attendance was received on the course (Regent 8 currently logs detailed activity log entries for course override changes).
Sample Activity Log texts:

• The Last Attended Date for Fundamentals of Management, (External Course ID: 8542657) starting on 01/01/2017 has been provided as 03/15/2017.
• The Attendance Flag for Fundamentals of Management, (External Course ID: 8542657) starting on 01/01/2017 has been provided as true.

Regent 8 will also write an activity log entry when a course with attendance has its start date or end date shifted (via either SBL load or course overrides).
Sample Activity Log text:

• The Start Date for Fundamentals of Management, (External Course ID: 8542657) starting on 01/01/2017 has been updated to 03/15/2017, which has caused the Last Attended Date to fall outside of the course dates. The Last Attended Date has been set to blank for this course. The Attendance Flag has been set to a value of "false."
• The End Date for Fundamentals of Management, (External Course ID: 8542657) starting on 01/01/2017 has been updated to 12/15/2016, which has caused the Last Attended Date to fall outside of the course dates. The Last Attended Date has been set to the course end date of 12/15/2016 for this course.

Removed SBL validation on Enrolled Date

Description:

In Release 4 of Regent 8, a change was implemented to the validation of the SBL Import process. This change was that the Enrolled Date of a course could not be a future date to the date in which the SBL file is loaded into Regent 8. For example, Regent 8 would not allow enrolledDate=2018-03-11 to be imported on today's date that is 2017-03-11. The enrolled date would have needed to be less than today's date.
In Release 4.1.0.0, Regent is reverting this change, thereby removing this validation on the Enrolled Date field. However, clients using Regent 8's student level census functionality should continue to ensure that the Enrolled Date on their non-transfer, term courses are not future dates.
Back to Contents

Import SBL Process Update: Ability to update Program Completion Date for prior active programs

Description:

Previously, Regent 8 only allowed the program completion date to be set for the program that was currently active in Regent 8 at the time the SBL file was imported. Regent enhanced the Import SBL process to allow updates to a program's Program Completion Date field. In the Academic Information node of the SBL file, the program information provided through the main program node (externalProgramId), will allow Regent 8 to update the Program Completion Date for the program provided in the externalProgramId field on the <academicInformation> node of the SBL, regardless of whether or not that program is the student's current active program in Regent 8. If the student attended the program more than once during their academic plan in Regent 8, the latest "instance" of the program will be updated with the program completion date provided. Please see example below:
Example:

1. A SBL file is loaded into Regent 8 with the following on 10/1/2015:

<academicInformation externalProgramId="Program A" programCompletionDate="2017-12-15" programStartDate="2015-10-05">

1. A SBL file is loaded in Regent 8 with the following on 11/15/2016:

<academicInformation externalProgramId="Program A" programCompletionDate="2016-11-15" programStartDate="2015-10-05" nextProgramExternalProgramId="Program B" nextProgramStartDate="2016-12-15"/>

1. Program's A Program Completion Date is updated to 11/16/2016 in Regent 8.

Export COD Process

Reporting AY Dates to COD for Term-based Direct Loans

Description:

Regent 8 has improved reporting of Academic Year dates provided to COD on Direct Loans. For Term and Nonstandard Term students, Regent 8 reports the full AY dates, regardless of the student's enrollment pattern in the terms within the AY. When students are finishing their program with fewer terms than a normal, full AY, that shortened "Remaining Period of Study" (RPS) is also reported to COD with the full AY dates. The Loans tab shows the COD-reported AY dates as the Academic Year Begin and End Dates. If any term has a nonzero Direct Loan disbursement, Regent 8 includes that term in the loan's Academic Year Begin and End Dates and the loan's Financial Award Begin and End Dates. The improved Academic Year date reporting reduces the occurrence of COD Reject 046.

• For SAY programs, Regent 8 always reports the full Scheduled Academic Year dates to COD. For example, if a student graduates in the Fall semester, Regent 8 would still report the full SAY dates including Fall and Spring semesters. Many SAY calendars have additional, optional terms (such as Summer headers/trailers). Regent 8 includes those optional terms in the reported Academic Year dates if those optional terms have nonzero Direct Loan disbursements.
• For Borrower Based Academic Year (BBAY) programs, Regent 8 always reports the full BBAY AY dates to COD. The BBAY starts with the first term that has attendance, and continues for enough terms in the BBAY to complete the full AY. For example, a student might graduate at the end of the first term in a BBAY. When Regent 8 sends the student's loan dates to COD, Regent 8 reports a full AY including the first term and all the following terms to meet the correct BBAY length. The loan's Financial Award Begin and End Dates still only include the enrolled term.

Add Award Wizard

Awards do not change to Manual for amounts lower than Calculated Eligibility

Description:

An enhancement has been made to Regent 8 regarding the conditions under which an award is made "Manual" by Regent 8. If a user enters an Accepted, Offered, or Estimated amount that is less than or equal to the Calculated Eligibility amount, and makes no other changes in the wizard, Regent 8 will not mark the award as "Manual." Regent 8 will continue to manage the non-Manual award and adjust it as needed.
The wizard will still mark an award Manual if any of the following apply:

• Accepted, Offered, or Estimated amount is higher than the Calculated Eligibility.
• Payment Period amounts change.
• Disbursement amounts change.
• A disbursement is added or cancelled.
• Award status changes to Cancelled or Unfunded.

Informational note: A recommended workaround is as follows. If an award needs to keep its original amount during packaging, users can mark it manual by adding an extra disbursement and splitting the disbursement amounts via MAW/AAW.

Standard Reports

Student - SAP report enhancements

Description:

The Student-SAP report was enhanced with an option to include historic SAP records. A new filter "Include Historic SAP?" was added to the report parameter options. When the filter is set to a value of "No", the report output includes records based upon the chosen parameters for non-historic SAP periods. When this filter is set to "Yes", the report output includes the latest historic SAP record for all students returned by the selected report parameters, regardless of whether they also have a non-historic SAP status in the report output. Multiple records (historic and non-historic) may be returned for the same student. If a given student has multiple SAP records with the same SAP Date and Review Period, across all SAP sources, (SIS, Calculated and Manual records), the most restrictive SAP status will be used as the most current SAP status for the student for awarding and disbursement purposes in Regent 8.

Award Portlet Enhancements

Description:

Regent added new enhancements to the Awards Portlet in the Student Portal. The new enhancements require specific SNAP or Regent 8 configurations. New features include general updates to the Awards Screen, a new loan counseling option, a new Cost of Attendance (COA) grid, and new Action options for the Awards grid. Note: Schools should contact their Regent representative to enable these features.

General Updates

1. Regent updated the "Total Amount" field name in the Awards grid on the Award Portlet's Award screen, to "Current Amount" for schools that have Active Acceptance funds. Informational Note: "Active Acceptance" funds have an "Offered" status selected for the "Initial Award Status" field on Regent 8's Fund Setup.
   Example:
   
   
   
2. Regent enhanced the Academic Year (AY) dates on the Award Portlet's Award screen. The AY dates are now listed in a customizable banner. Regent uses the school's requested color themes on the AY banner. Schools should contact their Regent representative to make changes to their AY banner.
   Example:
   
   
   
3. Regent added a new banner feature for the Awards screen. The banner text displays, "Estimated Balance Due" with a numeric amount value. The amount value is the calculated amount of the student's Remaining Estimated Direct Costs. Please see calculation details below in the Cost of Attendance (COA) grid section. Schools interested in the new Estimated Balance Due banner should contact their Regent representative to turn on the applicable SNAP configurations.
   Example:
   

Loan Counseling Option

Regent added an enhancement that requires the student to acknowledge a Statement of Understanding (SOU) prior to viewing, accepting, or declining an Active Acceptance fund. Schools that are interested in this feature are required to set specific configuration options in Regent 8 and SNAP. The following enhancements act in the place of a loan counseling session to students via the Student Portal. Schools may choose which Active Acceptance funds and the informational message that students must acknowledge prior to being allowed to accept any fund amounts. Please see details below for supporting configuration needed for the loan counseling option.

Example of Loan Counseling Option:

Statement of Understanding - Fund Request: This is a Regent 8 value that was added to the Document Use section's dropdown option "Select the Process that this document facilitates" in Document Setup. Users must create a student-scoped document utilizing the "Statement of Understanding – Fund Request" value, in order to support the loan counseling "session" in the Student Portal. When a document using this value is setup and the student confirms the SOU via the Awards Portlet, SNAP will create a SATISFIED document in Regent 8.
Note: The "Statement of Understanding – Fund Request" value should be used only for student-scoped documents.

Require student to request fund on Student Portal:

This is a Regent 8 setting that is located on the General tab of Fund Setup in the Awarding Rules section. Users must enable this configuration to support the loan counseling option in the Student Portal. This setting only displays for funds configured as Active Acceptance. All Title IV funds that require Active Acceptance are recommended to enable this option. When this option is selected, schools must also configure a supporting configuration option in Document Setup (as described above). Please see below for additional details.

• Setup Note: The Statement of Understanding – Fund Request Document and the Fund Setup option Require student to request fund on Student Portal must both be configured to utilize SNAP's new loan counseling option. Meaning, as long as there is an award with Fund Setup's Require student to request fund on Student Portal setting checked (turned on), there must be a Regent 8 document configured to use the Statement of Understanding – Fund Request Document Use Type. When each setting is configured, the student is taken through a loan counseling "session" where they are required to acknowledge a SOU. Please see below for additional details.

Statement of Understanding (SOU) screen:

The SOU screen is a configurable screen in the Awards Portlet. Schools should contact their Regent representative to have their specific message added to the screen. Regent currently displays a generic message on the SOU screen. When a student opens the Award Portlet, a customizable SOU box displays at the top of the page. Students are instructed to select the "Statement of Understanding" button to view and acknowledge the Statement of Understanding screen. Once the student selects "Acknowledge" (on the SOU screen), a SATISFIED document is created for the student in Regent 8, and the student can view and edit funds that have Fund Setup's Require student to request fund on Student Portal option selected. If the student selects "cancel" (on the SOU screen), they will not be able to view and edit funds that have Fund Setup's Require student to request fund on Student Portal option selected.

Cost of Attendance (COA) grid

Regent created a new Cost of Attendance (COA) grid for the Award Portlet's Awards screen. The grid is an estimated COA based on an average of expected expenses. Schools interested in the new COA grid should contact their Regent representative to turn on the applicable SNAP configurations.

Example:

Details:

• Calculations for amount values:
  • Estimated Direct Costs - This is a title in the COA grid. Items that display in this section have "Direct Cost" selected in Regent 8's Cost Items in Cost Setup. The following categories are available to display:
    • Tuition and Fees
    • Books and Supplies
    • Room and Board
    • Personal/Misc
    • Transportation
    • Dependent Care
    • Study Abroad Expenses
    • Disability Expenses
    • Employment Expenses for Co-Op Study
    • Loan Fees
  • Total Estimated Direct Costs - This is the item total for categories listed under Estimated Direct Costs.
  • Estimated Indirect Costs - This is a title in the COA grid. Items that display in this section do not have "Direct Cost" selected in Regent 8's Cost Items in Cost Setup. The following categories are available to display:
    • Tuition and Fees
    • Books and Supplies
    • Room and Board
    • Personal/Misc
    • Transportation
    • Dependent Care
    • Study Abroad Expenses
    • Disability Expenses
    • Employment Expenses for Co-Op Study
    • Loan Fees
  • Total Estimated Indirect Costs - This is the item total for categories listed under Estimated Indirect Costs.
  • Total Estimated Cost of Attendance - This item displays the sum of Total Estimated Direct Costs and Total Estimated Indirect Costs. Cost Adjustments are not considered.
  • Less Total Accepted Awards - This item displays the student's awards that are already accepted.
  • Less Total Resources - This item is the amount of Regent 8's manual and imported resources. Exempt resources are not considered.
  • Remaining Estimated Direct Costs - This amount is the sum of Total Estimated Direct Costs minus Less Total Accepted Awards minus Less Total Resources.
  • Remaining Estimated Total Costs - This amount is the sum of Total Estimated COA minus Less Total Accepted Awards minus Less Total Resources.

Award Grid's Action Options

Regent added additional options to the Action column on the Awards grid. Schools interested in the new Action options should contact their Regent representative to turn on the applicable SNAP configurations. When the new Action options are in use, the Current Amount (for offered awards) is set to "$0," and awards in an OFFERED status will display BLANK (nothing at all) for the Payment Period amounts.

Example:

Details:

Each Action option will determine what amounts can display in the Current Amount field. Note: Once the student has accepted and saved an amount for an Unsubsidized loan, the student is no longer able to make any changes to a Subsidized loan. As a result, the Subsidized Loan's Action options no longer display, and a new message displays explaining why the student cannot edit the Subsidized loan.

Please see below for the new options and specific rules for each:

• Direct Costs: This amount is the sum of the Total Remaining Direct Costs minus the amount displayed under Less Total Accepted Awards minus the amount displayed under Less Total Resources. This option is ONLY available and Subsidized and Unsubsidized Loans. SNAP calculates the direct cost (DC) amount for loans at the time the Award screen is loaded. SNAP will maintain a running total of the remaining DC amount based on the student's input to enable/disable the DC option. If DC amounts are met, SNAP will disable the DC option in the Actions column, and update the tooltip for Current Amount field to say: "You have no more remaining direct costs." Please see Example 1 below. If there are remaining direct costs available, SNAP will populate the remaining amount available for a loan. Please see Example 2 below. The Current Amount field is not editable when using the Direct Costs option.
  • Example 1: A student has Sub 001 and Sub 002. Each loan's full eligible amount is $2,000. The Remaining Estimated Direct Costs are $2,000. The student selects "Direct Costs" for Sub 001. The student will see $2,000 populate in the Current Amount field for Sub 001. The student will also see the "Direct Costs" option become disabled in the Action column for Sub 002.
  • Example 2: A student has Sub 001 and Sub 002. Each loan's full eligible amount is $2,000. The Remaining Estimated Direct Costs are $3,000. The student selects "Direct Costs" for Sub 002. The student will see $2,000 populate in the Current Amount field for Sub 001. The student then selects the "Direct Costs" option in the Action column for Sub 002. The student sees $1,000 populate in the Current Amount field for Sub 002.
• Enter Amount: The Current Amount field is editable when using the Enter Amount option. The field validations ensure this amount cannot exceed the Maximum Eligibility amount, and the student must enter at least $1. If the student first selects this option and there is no amount populated ($0) or the amount is equal to the Maximum Eligibility amount, SNAP will automatically populate $1.
• Maximum Eligibility: When this option is selected, the amount listed in the Maximum Eligibility column is populated to the Current Amount field. The Current Amount field is not editable when using the Maximum Eligibility option.
• Later: The Current Amount field populates $0 when "Later" is selected for offered awards. The Current Amount field is not editable when using the "Later" option.
• Decline: This option only displays for offered awards. Once the student has accepted any amount for an award, the student no longer has access to the Decline option. When Decline is selected, the Current Amount field populates the amount listed in the Maximum Eligibility field. Once an award is declined, it will not display in the portal. The Current Amount field is not editable when using the Decline option.

Student Dataviews

New Dataview for Activity Log Entries

Description:

Regent created a new data extract view, dataExtract_ActivityLog_Last120Days_View_v001. This view returns Activity Log Entries in Regent 8 that were created in the last 120 days. Any entries older than 120 days are not populated in this view.
This view's schema matches the schema for the dataExtract_ActivityLog_View dataview. This view was created to decrease the size of the exported data view payload for customers who use Regent's BCP Export process. The view's data set has a significantly smaller sized footprint; therefore, it could also be useful for customers who import the data from the Regent8 Dataviews directly into their own databases.
Note: The current Activity Log Dataview, dataExtract_ActivityLog_View, returns all Activity Log Entries in the database. That view is not being deprecated and no changes have been made to that view.

New Dataview for Unmatched ISIR data

Description:

Regent created a new dataview called, "dataExtract_ISIR_UnmatchedStudent_View."
This view contains all unmatched ISIR data. 'Unmatched' refers to all ISIRs for which Regent 8 could not find a student match. The schema for this view matches the schema for the dataExtract_ISIR_View dataview except for the following columns that are not included:

• [studentId]
• [externalId1]
• [externalId2]
• [externalId3]
• [externalId4]
• [locationExternalId]
• [siteExternalId]