Reassessment Analysis

[roopeyds]

Additional Context

• Analysis Ticket #791
• Analysis Ticket #868

Acceptance Criteria

• [x] 2x 1-hour sessions with Dev team
• [x] 1 Dev to lead and investigate providing input to 2nd session
• [x] Taking into account the below areas, create tickets and structure of how to proceed
• Student Requests change
• Institution Requests change (program / Scholastic standing)
• Student Requests change
• Overawards
• Restrictions

[andrewsignori-aot]

Reassessment Workspace: https://www.figma.com/file/5xPLQ5ocqOrtGJdKf0vZp2/SIMS-Reassessment-Workspace?node-id=0%3A1

OA = Over Award NOA = Notice of Assessment CSL = Canadian Student Loan (federal loan) BCSL = BC Student Loan (provincial loan)

Assumptions

• The current assessment workflow could be reused to define the reassessment.
  • We can duplicate the application and mark it as overridden to allow the workflow to be executed again.
  • The assessment workflow currently receives only the application id as a parameter to start the process. We can send others parameters, like "mode: reassessment", to allow the workflow to be processed with the necessary alternative flows to handle the reassessment.
  • OA grants are not recorded on the student account. Only CSL and BCSL are kept under student account and must be taken into consideration for new disbursements (currently it is not considered in the assessment workflow) .
• Grants are part of the reassessment calculation only to define the OA while comparing the previous disbursement schedules with the new one generated by the reassessment workflow.
• When the Institution reports, for instance, an withdraw or early completion, the offering end date and costs will be impacted. We need to persist this new values somewhere and use them while doing the reassessment.
  • One possible option would be, when the change affects the offering and the change is final, we can generate a "Application Specific" offering to be associated with the cloned application.
  • Another option would be persist this data on DB and feed the workflow to allow it to reuse this data instead of the offering associated to the application.

Questions

• 1. When there is an OA in the student account and one assessment is generated taking it into the consideration, how does this impact the OA in the student account?
     • Should we "lock" the OA in the student account?
     • Should we track the assessment "consuming" the OA?
     • Should we do any change in the OA in the student account before the NOA is approved?
     • What is the level of audit that we need for the changes that are going to happen on the OA in the student account?
• 2. The reassessment can be initiated by a Student or by a Institution reporting a change.
     • When the student request a change, the assumption is that a new NOA will be generated and the student must approve it.
     • When the institution reports an early completion, the assumption is that the student has no action and there is no need for an NOA approval.
• 3. Are we going to display the OA information in the NOA. For instance, if there is an OA in the student account and the NOA was generating including a OS discount in the total, will it be clear in the NOA? It could be useful to the student see if there is something wrong and get in contact with the Ministry
• 4. If they pay the debit through NLSC, how does the system know it?
     • Not defined right now. The assumption is that there will be a manual way to Ministry edit it (we would need a ticket for that).
• 5. Does the Ministry needs to review every application that requires an reassessment?
     • What the Ministry need to see in order to approve the reassessment? Previous application?
• 6. How the student will request changes? To be defined on ticket #882
     • Are we going to use a new UI with the specific options?
     • Are we going to allow the student to reuse the same Student Application form?
• 7. When Institution changes a Program/Offering
     • Are we going to create a cloned of the program to keep the history for the others completed application?
     • What is considered an application that must be reassessed due to a Program/Offering change?
     • Any application after it is submitted?
     • If the application is completed and the end of study period is still a future date?
• 8. Are we going to use restrictions somewhere along the reassessment process?
• 9. Is there a maximum eligibility value for program year (Program Year Maximum/Life Time Maximum), do we need a new ticket for it?

Student Requests a Change

• It seems to be the same for an appeal. So there are no reason to believe that they would work differently.
• Student can have a form.io definition for every type of change that would be possibly requested.
• The same form.io definition can be displayed for the Ministry approval/denial.
• The student requests must be grouped and then submitted to the Ministry assessment.
• The Ministry could approve/deny one or many student requests.
• The student must see the feedback provided by the Ministry.
• The student can start a new request to reply to a Ministry denial.
• The Ministry will approve and trigger the process to start the reassessment.
• The same application can have multiple NOAs triggered by multiple change requests.
• An NOA will be always generated.
• We need to keep an audit and display which changes triggered a new NOA.

Restrictions

• Restrictions will be created, for instance, as part of the Institution reporting a Scholastic Change and will be manually handled by the Ministry user assessing the request.

Possible new DB structure

[abschwenker]

Added numbers to the above comment

1. Overawards should be subtracted from the account when the first COE is confirmed and the application is moved to completed It is ok if the student is not allowed to start a second application assessment at the same time.
2. Overawards need: Added by, added when possibly a status if need. Use a transaction based table not a running value
3. Overewards need a maul way to be added, add a row to table of manual added or subtracting
4. yes, the current approach resolved this, will be part of output ticket AC
5. yes, the current approach resolved this, will be part of output ticket AC
6. yes, the current approach resolved this, will be part of output ticket AC
7. yes, the current approach resolved this, will be part of output ticket AC
8. yes, the current approach resolved this, will be part of output ticket AC
9. yes, the current approach resolved this, will be part of output ticket AC
10. yes, we will have a restriction to stop the disbursement then be adjusted based on the outcome, will be part of output ticket AC
11. yes, We will have specific tickets for the grant/loan maximums

[abschwenker]

related pr: https://github.com/bcgov/SIMS/pull/1050