Title: Adjust Cost Wizard: Display Error Messaging 
Ticket: RS-12136;

Description:
Regent 8's (R8) Adjust Cost Wizard was updated to display the same error messaging for packaging blocks (BP Errors, rebuild blocks, document blocks, tasks blocks, etc) as the Modify Academic Plan wizard.

Title: Awards Tab: Display all Cost Adjustments with their correct Cost Adjustment names
Ticket: RS-11977;

Description:
Regent 8 (R8) previously had two "gaps" in its functionality regarding the display of manual Cost Adjustments entered on the Awards tab.

1. If multiple Cost Adjustments were entered for a student for a single payment period, only one would be displayed on the Awards tab. R8 has been updated to properly display all cost adjustments provided for a student for a single payment period, each reflected on its own row in the Cost Detail portion of the Awards tab.
2. If Cost Adjustments were entered for different payment periods, all Cost Adjustments displayed in the same row and used only the “Cost Adjustment Name” of the first Cost Adjustments entered, as the label for the entire row. This issue has been corrected to display each Cost Adjustment properly labeled by name in its own row and under the correct payment period.

Title: Updating a COD Award's ISIR Transaction Number
Tickets: RS-3721; RS-12058; RS-12057;

Description

Regent8 (R8) was enhanced to ensure appropriate updates are made to a COD award's ISIR (CPS) Transaction Number when required. The ISIR Transaction Number is listed in the COD export file as “CPS Transaction Number” which is an Award level element. This enhancement affects Pell, TEACH, or Direct Loans (Sub, Unsub, Parent PLUS, GradPLUS).

Criteria
The following criteria determines if a COD reported award’s (Pell, TEACH, Sub, Unsub, Grad PLUS, and PLUS) ISIR Transaction Number is updated to the current, Active ISIR:

1. The award does not have an ISIR Transaction Number at all.
2. When a new ISIR transaction is made Active, R8 updates COD with the new ISIR Transaction Number for all affected awards (regardless of whether the award amount changed or any transactions are being processed at the time).
   • There are four exceptions to this rule. R8 does not update the CPS Transaction Number associated to an award if:
     1. The loan award has been paid in full.
     2. For an Undergraduate (UG) to Graduate (GR) program change, the Pell award is not updated to reflect the GR ISIR Transaction Number.
     3. For a UG to GR program change, the loans associated with the UG period are not updated to reflect the GR ISIRs Transaction Number (Sub and Parent PLUS must be UG).
     4. For a GR to UG program change, R8 will not update the GR loan with the UG ISIR Transaction Number.

Note that the ISIR Transaction Number on the Academic Plan for each award reflects the ISIR Transaction Number that R8 is reporting to COD.

Title: New configuration option, Offset Fund Budget Amounts For Import Awards

Tickets: RS-11447; RS-11621; RS-11622; RS-11623; RS-11624; RS-11625;

Description:

Regent8 (R8) currently offsets a budget's 'Balance Remaining to Offer' amount during the Import Awards and Disbursement (IAD) process (if the fund has an associated budget setup within Fund Setup). However, a school that has a need to import or on-board inactive students with budgeted funds via the IAD process may not want the fund's budget to update. Therefore, Regent has made this functionality configurable via a new Institution Setup option called, "Offset Fund Budget Amounts for Import Awards."

'Offset Fund Budget Amounts for Import Awards' was added to the Rebuild and Import Award Settings section of the General tab of Institution Setup. This new checkbox option defaults to selected (process is turned on). When this option is not selected (option is turned off), R8 will import IAD data without reducing the applicable fund budget.

Guidance for Current Customers

Customers that are currently processing awards for budgeted funds via the IAD process in a Regent Production environment are not impacted by this new option (post go-live). Current post go-live customers are advised to leave this option turned on. A customer that is not currently processing awards for budgeted funds via the IAD process in a Regent Production environment (pre go-live), may or may not need to turn off this option. A customer that always wants the fund's budget amounts to be offset (updated) via the IAD process should select this option (turn it on by selecting the checkbox). A customer that does not want the fund's budget amounts to be offset (updated) via the IAD process should turn off this option.

If 'Offset Fund Budget Amounts for Import Awards' is turned off, Regent assumes that awards created or updated in R8 by the Import Awards and Disbursement (IAD) process have already been accounted for by the fund budget in the school's pre-R8 system, and that fund budget amounts configured in R8 reflect what is remaining to award at the time of go-live. The budget amount value entered into R8 would be "total available budget" that R8 can award.

Please contact Client Support with any additional questions.

Important Note: 'Offset Fund Budget Amounts for Import Awards' is specific to the IAD process in regards to updating the fund budget; Regent continues to maintain the fund's budgets post conversion. For example, when 'Offset Fund Budget Amounts for Import Awards' is turned off, and a student has a budgeted fund imported via the IAD process for $10,000, the fund's budget is not updated during the IAD process. Later, the student withdraws from all their courses. R8 cancels the budgeted fund, and updates the budget by adding $10,000 back to the 'Balance Remaining to Offer' amount.

Title: Update to Allow Packaging to Move Paid Disbursements Configuration Option

Tickets: RS-8899; RS-11722; RS-11723; RS-11724; RS-11725; RS-11726;

Description:

In R8 Release 3.5.0.7, a configuration option was added to Institution Setup: 'Allow Packaging to Move Paid Disbursements.'  When this field is selected, R8 allows packaging to move paid disbursements from the payment period in which they were originally paid, to different payment period. When this field is not selected, RNA presents a packaging error and prevents the disbursement from being moved.

The business rules for this configuration option have been updated to add an exception.  When a paid or unpaid disbursement is moved manually, via the PP Override field in the Program Management Wizard, R8 allows a paid disbursement to move without triggering any type of error.

Title: New Year Round Pell Crossover Exceptions Report
Tickets: RS-11414; RS-11952; RS-11954; RS-11955;

Description:
Regent created a new report to support Year Round Pell (YRP), Year Round Pell Crossover Exceptions. This report provides information on Pell crossover awarding. It identifies students for whom the current, configured FAY Crossover Awarding option (on Institution Setup) has not resulted in the highest amount of Pell award the student could have received for the crossover payment period (PP). The report identifies cases where the student would have received a larger Pell award if the student had been packaged in the "other" FAY available for the crossover payment period.

The school should award Pell in the "most beneficial" manner for students. The school's definition of "most beneficial" may not necessarily mean awarding a student from the FAY that results in the highest dollar amount for the crossover term. If the school deems a student as most benefiting overall from being awarded Pell in the "other" FAY (versus the FAY currently chosen due to the Institution Setup's option, FAY Crossover Awarding), the FA User can manually change the crossover FAY for the payment period via MAP's Advanced Packaging screen. Schools may decide that the student's "most beneficial" outcome is to not refund Pell from one FAY and re-award Pell from another FAY.

If a school reviews a student returned in the report’s output as an exception (Return Exceptions Only equals "Yes") and they decide to not award the student from the “Other” FAY available for the crossover period (higher Pell dollar amount), this student will continue to display in future report outputs.

Informational Note: Advanced MAP does not allow a user to override the FAY crossover option on closed PP / terms.

Report Criteria

1. Payment periods / terms that begin before 7/1 and end after 6/30 are returned in the report output (referred to here as "crossover PPs").
2. Student's enrollment is Actual or Anticipated for the crossover PP.
3. Student has valid ISIRs in R8 for both FAYs for the crossover PP.
4. The student is Pell eligible for at least 1 of the 2 FAYs (Pell Eligible Flag = Y) involved in the crossover PP.
5. Both non-manual and manual awards are returned in the report output.
   1. For example, R8 will calculate the Pell amount in the crossover payment period in two ways: current crossover option vs. the “other” crossover option. The Pell award for the "current" FAY could be a manual award. The report will compare the amount of award potentially available if the crossover period were packaged using the "other" FAY, to the current, manual award.

Informational Note: When there is no Pell Schedule available for an FAY, R8 uses the prior FAY's Pell Schedule to determine the Pell award for that year (also known as the Supplemental Lookup). For example, if a future FAY is chosen or is included in the report's output because it is the adjacent FAY, the report output returns calculations based on the latest Pell Schedule.

Report Parameters

1. Enterprise: A dropdown for the Enterprise Name displays per Enterprise Setup.
2. Institution(s): A dropdown for the Institution Name(s) display(s) per Institution Setup(s).
3. Campus(es): A dropdown for the Campus Name(s) display(s) per Campus Setup(s).
4. Site(s): A dropdown for the Site Name(s) display(s) per Site Setup(s).
5. Type: A dropdown lists the options, “Term Based,” Non-Term Based,” and Non-Standard Term.”
6. FAY Crossover Period:
   1. The starting FAY for YRP eligibility is 2017-2018 (FAY 2018); therefore, the dropdown lists FAYs 2017-2018 and forward. If 2017-2018 is selected, the report will return student's packaged during the 2017-2018 crossover period, as well as the "other" FAY that was available to that crossover period, which may either be the former or latter FAY.
      1. For example: 2018-2019 is selected from the FAY Crossover Period parameter. A crossover PP has a start date of 5/17/2018 and an end date of 7/25/2018. This is defined as a crossover period due to the range crossing the 7/1 threshold. This payment period could be awarded from the former year (2017-2018), or from the latter year (2018-2019). The Current Crossover FAY option awarded the student from the former FAY per configuration. Therefore, the report will return R8's calculation for the "Other" Crossover FAY option as the "latter" FAY of 2018-2019.
   2. The report output is limited to the two adjacent FAYs. Meaning, R8 can only calculate the current FAY and either the former or latter FAY. Therefore, selection of multiple FAYs is not permitted.
7. Return Exceptions Only:
   1. Yes - Only returns students for whom the “Other" Crossover PP Pell Amount" is greater than the "Current Crossover PP Pell Amount."
   2. No - Returns all students regardless of the amount differences returned in the "Other" Crossover PP Pell Amount" and "Current Crossover PP Pell Amount."
8. Include Historic (AY0) Crossover Payment Periods?:
   1. Yes - The output results will include crossover PPs in an AY0.
   2. No - The output results will not include crossover PPs in an AY0.
9. Student is Active?:
   1. Select All - Returns both inactive and active students.
   2. Yes - Returns only active students.
   3. No - Returns only inactive students.

Report Output Results

1. ExternalID1: Student’s External Identifier 1 displays per the student's Summary tab.
2. ExternalID2: Student’s External Identifier 2 displays per the student's Summary tab.
3. First Name: Student’s First Name displays per the student's Summary tab.
4. Last Name: Student’s Last Name displays per the student's Summary tab.
5. Campus Name: Displays student's campus.
6. Site Name: Displays student's site.
7. Term / Payment Period: Displays the name of the crossover term / PP.
8. Payment Start Date: Displays the Payment Period Start Date for the Crossover Payment Period.
9. Payment End Date: Displays the Payment Period End Date for the Crossover Payment Period.
10. Crossover Payment Period is Historic (AY0)?: Returns Y or N, depending on whether or not the crossover payment period is in an AY0.
11. Current Crossover PP FAY: The FAY currently selected to use for the student’s crossover PP. For example, for 2016-2017, if the student’s crossover PP is currently packaged with 2016-2017, the report would return “2016-2017” in this field.
12. Current Crossover PP ISIR Transaction: Displays the transaction number of the ISIR currently used to package the crossover PP.
13. Current Crossover PP Active ISIR EFC: Displays the student's 9-month EFC from the ISIR (Primary EFC) currently used to package the crossover PP.
14. Current Crossover PP Pell Amount: Displays the student’s current Pell award amount.
15. Current ISIR's Transaction Processed Date: Displays the date that the current ISIR was processed.
16. Current Crossover FAY option: Returns either "former" or "latter." This value identifies how the student is currently configured to package (or how the student was packaged).
17. “Other” Crossover PP FAY: Displays the “other” FAY (that is not currently used to package the crossover PP). For example, for 2016-2017, if the student’s crossover PP is currently packaged with 2016-2017, the report would return “2017-2018” in this field.
18. “Other” Crossover PP ISIR Transaction #: Displays the transaction number of the "other" ISIR used to calculate the crossover PP.
19. “Other” Crossover PP Active ISIR EFC: Displays student's the 9-month EFC (Primary EFC) from the "other" ISIR used to calculate the crossover PP.
20. “Other” Crossover PP Pell Amount: Displays the student’s Pell award amount for the crossover.
21. "Other" ISIR's Transaction Processed Date: Displays the date that the "other" ISIR was processed.
22. "Other" Crossover FAY option: Returns either "former" or "latter." This value identifies how the student would have packaged if configured to use the "other" FAY.
23. Last Successful Packaged Date: Returns the last date that the student was successfully packaged.
24. Student is Active?: Returns Y if the student is active; N if the student is not active. Informational Note: Inactive students are listed as such on the student Summary tab. Students become inactive via the SBL file (active=false).

Title: "Maximum Eligibility" text references updated to "Available Amount."
Tickets: RS-11831; RS-11872;

Description:
The Awards Portlet has been updated to replace all text references of "Maximum Eligibility" with "Amount Available." Updates are reflected on the following areas of the Awards Portlet:

1. The Maximum Eligibility column's label name now displays "Amount Available" in the Awards grid. This column's information icon has been updated to display, "This is the amount available for all awards of this type."
2. The Action column displays award status messages for Unsubsidized Loans. The messages no longer reference "maximum eligibility." Messages now appear as, "You must accept your full Subsidized loan amount before accepting Unsubsidized loans."
3. The Action column's radio button label name has been updated from "Maximum Eligibility" to "Amount Available."
4. The red text listed beneath the Awards Grid now displays, "Note: Changes made to the amount you accept may result in the recalculation of the Current Amount and Amount Available for other awards when the Save Changes button is clicked."

Implementation Note: Items 3 & 4 above are associated to the SNAP Configuration setting “AwardsPortlet_DisplayActionOptions.” This setting must be set to “true” for the “Amount Available” radio button to display. SNAP configuration settings do not display on the Portal's User Interface. Please contact Client Support to configure this setting .

Problem: 
At a school configured to use a student-level census date, R8 miscalculated the student-level census date. A few students also had an incorrect Pell amount or incorrect census unit counts.

Cause: 
The system was using the term end date rather than the calculated term census date when determining whether a student had been packaged on a valid ISIR prior to the census date. In addition, for crossover terms, the student-level census calculation was sometimes not reset to use the term's correct FAY ISIR when calculating the crossover term's census date.

Fix: 
The code changed to use the configured term census date rather than the calculated term census date when determining whether a student had been packaged with a valid ISIR prior to the census date. In addition, the logic was corrected to use the correct FAY ISIR for census dates in crossover terms.

Testing: 
Package an affected student who has a valid ISIR (an ISIR with a non-blank EFC value). View the Awards tab, Enrollment Details for the affected terms, including a crossover term. For students who were packaged with a valid ISIR prior to a term's census date, the census date should match the term's census date. For students who were first packaged during the term, but after the term's census date, the census date should be their initial packaging date. In both cases, the census units should include all program-applicable units that were not withdrawn before the student's census date. Also, review any Pell Grant amounts. Pell should be recalculated normally based on the enrollment as of the Pell Recalculation Date.

Problem: 
The issue was that TEACH wasn't calculated correctly if there was at least one non-full time enrollment in the Academic Year (AY).

Cause: 
This was a gap in R8 functionally. TEACH was originally implemented to calculate only for full-time enrollments.

Fix: 
Updated the TEACH awarding logic to account for all types of enrollments: Full Time, Half Time, Three Quarter Time and Less than Half Time.

Testing: 
Locate a TEACH eligible student who has at least one non-full time enrollment in the AY.
Then add the TEACH grant and package the student. The TEACH eligibility should be calculated correctly for each term in the AY.

Problem:
The FSEOG Fund Budget's Accepted Amount was unexpectedly showing $0 on the Fund Setup - Budget tab.

Cause:
When the fund's budget updates for ImportAwards were being processed, the award's Accepted Amount was not set to the correct value.

Fix:
R8 was updated to ensure that award's Accepted Amount is correctly set when the Fund's Budget changes are being processed.

Testing:
Import an FSEOG award change for a student via the Import Awards and Disbursements process. Package the student. View the FSEOG Fund's Budget tab and ensure that the changed award amount are included in the Accepted Amount column.

Problem: 
When a school tried to bulk export some Letter communications, nothing was exported.

Cause: 
The staging process for Student Templates was missing a value for bulk exporting the communications type, Letter.

Fix: 
The stored procedure was updated to return the missing value for generating and exporting the Letter communications.

Testing:
First, set up a bulk export folder on the test server, and run any configuration scripts needed to use that folder from the test environment. Configure a Communications template and a Communication of type "Letter." Bulk export that communication for a set of students. Confirm the Letters were exported to the bulk export folder on the server. Open a student who received the communication. Confirm the communication is visible from the student's Activity Log.

Problem: 
In Fund Setup, the disabled option for "Allow Auto-Adjustment of Paid Disbursements" was unexpectedly changed to "No" for Federal Pell Grants. As a result, some Pell Grants could not change their paid disbursements during packaging.

Сause: 
A bug on the Fund Setup screen menus unexpectedly changed the value of "Allow Auto-Adjustment of Paid Disbursements" to "No" instead of "Yes." The problem affected three funds: Federal Pell Grant; Iraq and Afghanistan Service Grant (IASG); and Federal Work Study. The configuration setting changed unexpectedly whenever a user made any edits to the Fund Setup screen.

Fix: 
The Fund Setup screen was updated to keep the disabled option set to "Yes" for those funds unless it was separately configured via script. For schools that already had the setting incorrectly set to "No," a separate cleanup script was developed that could restore the correct value of "Yes" on the Fund Setup setting.

Testing: 
On a school with the normal default settings, open the Fund Setup screen for the Federal Pell Grant fund. Edit and Save. Refresh. The setting for "Allow Auto-Adjustment of Paid Disbursements" should maintain its value. The setting should still be disabled.

Problem
Rebuild Data was unexpectedly not visible in the Conversion Queue, while it was visible on the Academic Plan.

Cause
A recent code change accidentally omitted several columns from a stored procedure.

Fix
The R8 stored procedure was updated with the missing columns to ensure that rebuild data will be visible in both the Conversion Queue and the Program Management Wizard.

Testing
Navigate to the Conversion Queue and Program Management Wizard screens to observe that COD Rebuild data will be visible in the Conversion Queue and on the Program Management Wizard.

Problem:
Document attachments uploaded by the student on the Student Portal were not visible in R8 on the Documents tab.

Cause:
When document upload failed on the Student Portal, an error message was not being displayed to the user. The user had no way of knowing that the document upload was unsuccessful and expected to see it in R8.

Fix:
An error message will now be displayed to the user when document attachment upload fails: "Application error has occurred and has been reported to technical support. No further action is required on your part, please allow some time for the issue to be resolved."

Testing:
Upload a document attachment to the Student Portal. Ensure that the document has been uploaded successfully and that no error message is displayed. Verify that the document attachment is visible in R8.

Problem: 
After an upgrade, the system unexpectedly assigned the "Prior Year Data Conflict" document to all ISIRs.

Cause: 
A school-specific cleanup script, for a separate bug, was accidentally included in the general deployment. As a result, some Documents unexpectedly lost their associations to Comment Codes 394 to 401.

Fix: 
The problematic script was removed. The cleanup script was also updated to preserve the link between Documents and Comment Codes for other schools.

Testing: 
Import ISIRs that do not have comment codes 394 through 401. The students should not be assigned the "Prior Year Data Conflict" document. Separately, configure a Document to be auto-assigned by an ISIR code in the range 394 to 401 (example: code 399). Load an ISIR with that comment code. The ISIR should trigger the Document assignment.

Problem: 
When nonterm students had only one Payment Period in their final Academic Year, R8 unexpectedly only scheduled one single disbursement for their Federal Direct Loans.

Cause: 
The Institution Setup configuration setting, "Multiple Disbursement Requirement," was unexpectedly not applied to the student's Campus. As a result, the setting did not inherit to the Federal Direct Loan's Fund Setup.

Fix: 
The "Multiple Disbursement Requirement" setting now inherits from Institution Setup, to Campus Setup, and then to Fund Setup.

Testing: 
Package a Federal Direct Loan for a nonterm student in a single Payment Period Remaining Period of Study (RPS) Academic Year. R8 should create two disbursements in the Payment Period.

Problem: 
On the ISIR Correction and Verification Wizard, the screen unexpectedly did not allow users to provide any inputs containing spaces. For example, the screen prevented two-word city names such as OKLAHOMA CITY.

Cause: 
The on-screen validation did not allow spaces as valid input.

Fix: 
The validation was corrected to allow spaces.

Testing: 
In the ISIR Correction and Verification wizard, edit an ISIR. Enter a two-word city name that includes a space. The screen should allow the new value, and should not display any validation error.

Problem: 
When a user made a correction to the "Student's adjusted gross income from IRS form" field, via the "ISIR Verification/Correction Wizard," and then exported the ISIR Correction, the ISIR Export file showed that field's corrected value as truncated.

Cause: 
The corrected value is expected to be a maximum of 7 characters, but R8 saved the value as 10 characters. Thus, the value was getting exported incorrectly.

Fix: 
The issue was resolved by adding a validation check that prevents a user from entering invalid values for "Student’s Gross Adjusted Income from IRS form" field in the "ISIR Verification/Correction Wizard."

Testing: 
Enter a correction to the "Student's adjusted gross income from IRS form" field in the correct 7-digit format and verify that it results in the accurate amounts in the Export ISIR Corrections file.

Problem: 
If the left menu of R8 was open (not collapsed), and the browser was set to a zoom of 90% or greater zoom, R8 unexpectedly hid the "Comment Codes" column of the ISIR table on the student's ISIR tab.

Cause: 
The "Comment Codes" column did not have a fixed width.

Fix: 
The issue was fixed by setting a fixed width (70px) on the Comment Codes column. This prevents the column from disappearing/collapsing.

Testing: 
View Student's ISIR screen using various resolutions and browser zoom options. The Comment Codes are now visible.

Problem: 
For manual Pell awards, R8 was not calculating eligibility for Year-Round Pell (YRP) but was instead calculating only 100% Pell eligibility for a given FAY. YRP eligibility was also not correctly calculated for students who had received Pell at another school.

Cause:
R8 was not including manual Pell awards when performing YRP Pell calculations, only non-manual Pell awards were considered. Also, in cases where a student had received Pell at a prior school, R8 was looking at the Pell award's accepted amount and if it was less than the percentage of Pell used at the external school, per ISIR data, R8 was determining the entire award was ineligible for YRP.

Fix:
R8 logic was corrected to ensure that manual Pell awards use the same calculations as non-manual Pell awards to determine if the student is eligible for YTD Pell. R8 was also corrected to consider the amount of Pell eligibility used at a prior school in order to properly determine YRP eligibility at the R8 school but eliminated the comparison of this amount to the award's accepted amount in R8.

Testing: 
Package a student that is eligible for YRP for the FAY, but also has a manual Pell award in R8 for the FAY. The calculated eligibility for the student should reflect eligibility for YRP. Package a student who received Pell at another institution in the FAY. R8 should correctly calculate the remaining Pell eligibility for the FAY to include the student's eligibility for YRP.

Problem: 
During Batch Packaging, some students were receiving an unexpected error: Error processing batch data for Student [XXXXXX]. Error Msg: Exception of type 'System.Exception' was thrown.

Cause: 
The error was caused by Federal Supplemental Grant awards that were re-imported, and had lost the link to their associated Budget.

Fix: 
R8 now has an additional logic check when reprocessing imported awards that use Budgets. R8 keeps the budget linkage the same if an award is already linked to a budget.

Testing: 
Import and re-import a Budgeted award such as FSEOG. Package the student using MAP; or, run Batch Packaging and check the System Batch Packaging Errors report. The 'System.Exception' error message should not occur on the student.

Problem: 
The following packaging error was produced during all packaging processes:

Error validating plan for Student [52425]: The payment period on paid disbursement number [2] with fund Direct Unsubsidized Loan and paid amount 0 was moved from original pp 1703B to pp 1604B. / The payment period on paid disbursement number [2] with fund Direct Subsidized Loan and paid amount 0 was moved from original pp 1703B to pp 1604B.

Cause: 
A validation check at the end of the packaging process looks for scenarios where R8 is attempting to move a paid disbursement from its original payment period to another payment period, and prevents the change from occurring. In this particular case, R8 was attempting to move the disbursement because it was also attempting to remove the term from the student's academic plan.

Fix: 
The issue was resolved by allowing the term to remain in place and on the same Academic Year, when the term contains a paid disbursement. The validation message will then no longer be thrown because the term containing the paid disbursement does not move.

Testing: 
Packaging students. The error should not be produced.

Problem: 
Several BBAY1 students had duplicated Academic Years on their Academic Plans. The duplicated AYs both contained the same terms but had different award amounts on the different versions of the terms.

Cause: 
The students had incorrect course data. A program change across different Sites had incorrectly kept registration in courses for the original Site. Additionally, if a Manual SAP record was linked to one of the incorrect, duplicated terms, it caused a packaging error.

Fix: 
The Academic Plan logic was improved for term and nonstandard term programs. The Academic Plan now has an additional check to detect when a term already exists on the Academic Plan. In addition, the packaging error text was improved by adding the SAP date to the error when a Manual SAP record cannot be assigned to any Payment Period. If a user sees that error, then they will need to delete the problematic Manual SAP record; repackage; and (after repackaging) create a new, replacement Manual SAP record for the correct Payment Period.

Testing: 
On an affected student, correct any erroneous course data. Repackage the student. Review the Academic Plan and awards, and confirm the terms and Academic Years are displayed only once. If the system gives an error, "Manual SAP Record cannot be linked to any payment period," then delete the Manual SAP record for that SAP date and package the student. After repackaging, add a new, replacement Manual SAP record. The Academic Plan and awards should package without any duplicates.

Problem:
Enterprise field was unexpectedly hidden from the parameter screen on all R8 reports after first time the report was generated.

Cause:
The Enterprise field was improperly sized on the UI, making selection from the drop down impossible.

Fix:
The Enterprise field was properly resized.

Testing:
Generate any R8 report (ensuring that the Enterprise value is selected). Close the Report and regenerate the report. The Enterprise field should remain available.

Problem:
The "ISIR Student Listing" report was missing data from the Household Number of Students, Number in College, and Household Number of Parents. The report also omitted the associated Change Codes for each of these columns.

Cause:
The data view was unexpectedly comparing two identical values, so it could not detect changes.

Fix:
The data view logic was corrected to use both the original value and the changed value.

Testing:
Run the "ISIR Student Listing" report. Review the report output.

Problem: 
At a term-based school with a SIS-provided SAP policy, R8 unexpectedly blocked disbursements for some students with a payable SAP status. The disbursements were blocked with error EST-0057, SAP Status Prevents Release.

Cause: 
The students had multiple terms with the same term names. R8 was unexpectedly assigning the SAP status to some terms that were marked Historic.

Fix: 
A code change improved the logic for assigning SAP statuses to payment periods, when multiple payment periods share the same name. If one of the payment periods is marked Historic, R8 assigns the SAP status to the non-Historic payment period.

Testing: 
Import a SIS-provided SAP status on the SBL for a student who has a Historic payment period and a non-Historic payment period with the same term name. R8 should assign the SAP status to the non-Historic Payment Period. The student should be able to successfully disburse through EST.

Problem:
Some BBAY Term students had loans for a single term. R8 unexpectedly packaged the students with incorrect Loan Period dates matching the full Academic Year. The Financial Award End Dates unexpectedly included the extra, ineligible terms in the same Academic Year.

Cause:
The loans were packaged in an older version of R8 that had incorrect logic for truncating Loan Periods. Because the loans had dates ending in the past, R8 did not automatically repackage the loans or correct the loan period dates.

Fix:
Modify Award Wizard was updated to automatically correct the loan period dates if a user edits the loan.

Testing:
Navigate to a student with an affected loan. Edit the loan in Modify Award Wizard. Continue through MAW, making no changes, and click "Finish." Review the dates on the Loans tab. The Financial Award Begin and End dates should only include terms that have loan dollars. The Financial Award dates should be within the Academic Year dates.

Problem:
Students were getting an 'Object Reference Error' while filling out the Shopping Sheet.

Cause:
SNAP did not verify ISIR records for null values. Since the student did not have an ISIR record, the error was thrown.

Fix:
A null check was implemented for the Active ISIR since some anticipated students do not have ISIR records.

Testing:
To verify that this issue is resolved, complete an entire questionnaire. Verify that no application error is received and that the Shopping Sheet is successfully submitted.

Problem: 
A Regent Access file import failed due to an unexpected error, "Duplicate Transaction ID."

Cause: 
In the Student Portal, if a user double-clicked or otherwise retriggered a Smart Form button quickly (multiple times within 1 second), the system failed to increment the transaction ID.

Fix: 
The Smart Form button was updated to prevent users from triggering the transaction multiple times. Additionally, a cleanup script was created to remove the extra, duplicated transactions. The Transaction ID logic was also improved to use an internally calculated Transaction ID instead of depending on the Smart Form button click.

Testing: 
In a Student Portal Smart Form, double-click or quickly click the buttons multiple times for Start, Edit, and Re-submit. The system should only create one transaction.

Problem: 
When R8 assigned a task using the Task Assignment Process, the Task's Activity tab did not show the Task's assignment.

Cause: 
The Task Auto-Assignment procedure did not insert a Task Activity record.

Fix: 
The Task Auto-Assignment procedure was modified to add a new Task Activity record if a Task is auto-assigned, unassigned, or re-assigned.

Testing: 
At a school configured to use Task Auto-Assignment, run the Task Auto-Assignment Process. Browse to a student who had a task assigned. View the Task's Activity tab which should show the task's assignment.

Problem: 
A nonterm school had configured Institutional Breaks. When R8 anticipated some future nonterm Academic Years, without any backing course data, R8 unexpectedly scheduled the AYs to start during the configured Break dates.

Cause: 
The Academic Plan was created from the current date and the start/end dates were updated with the actual course data.

Fix: 
The code was modified to take into consideration Academic Breaks when creating an anticipated nonterm plan.

Testing: 
Package the student to confirm that R8 honors the configured Institutional Breaks on the Loans and the Academic Plan tabs.