14A. Assessment

This epic describes the issues of calculating students costs, student resources (contributions), student exceptions, student assessed need, student awards, assessment maximums.

****PY limits**
Part 1. Business Context**
**Expected outcome of the feature**
Include PY maximum limit for the calculation of awards which has a maximum PY limit to it.
Here is a very basic example for understanding the outcome.

Implement the PY maximum limits for PT assessments but the framework will be built in common to achieve the same for FT assessments as well.

**To get the total sum of a award assessed to student in the given PY we need**
Assessment calculations which belong to applications submitted by students of same PY must be calculated sequentially to determine how much the student already consumed(got assessed) for an award in a given PY

**Impact of sequential assessments to the system**

When assessments are executed sequentially and when a student has more than one assessment to be calculated, the assessment calculations will be executed sequentially.
And as an impact if a student has more than one assessments to be calculated, the other assessments which are sequentially behind will be waiting for the calculating assessment.
In accordance with the above point, if the calculating assessment runs into an error, then unless the error is troubleshooted the other assessments will not be calculated and be able to proceed further.
**Impact of PY deductions**
When a student has more than one applications submitted for the same PY, then changes happening one application like cancelling an assessed application, COE getting declined for an application, reassessment happening to an application
will have potential impact on the other application(s) and all the impacted applications need to be reassessed.
Here is a very basic example to understand the context above:

Due to this impact we now have to create a solution to perform reassessments to an application which is not complete.
The current system does not do reassessments for an application which is not complete.
The meaning of complete here is -> The first ever COE of the application is confirmed.
Here is the basic example to understand the above context

**Chronology**
From the moment we decide to run assessments sequentially and could see that when a student has more than one application for the same PY and change in one application can impact the calculations in other applications we need an order of chronology for following purposes.

As per analysis outcome there are 2 chronologies decided to be used.
Chronology 1: Ordering by study start date
Chronology 2: Ordering by assessment calculation date (assessment_date) of original assessment
These chronologies are going to be used for different purposes in the solution.

**Sequence to calculate assessments(sequential execution of assessments) - Chronology 1**
From the analysis and discussions with business it has been found that using the order of Study start date (from the offering) must be the sequence to calculate the assessments sequentially.

Here is a simple example

**Sequence to determine total award value of a given award assessed for a student for a given PY - Chronology 2**
To elaborate the header further, when every assessment calculation happen, we need to input the total award value consumed by the student for the given PY.

**Sequence to identify potentially impacted applications to run reassessment - Chronology 2**
As described earlier, when a student has more than one applications submitted for the same PY, then changes happening to one application like cancelling an assessed application, COE getting declined for an application, reassessment happening to an application
will have potential impact on the other application(s) and all the impacted applications need to be reassessed.

Note: To avoid long sentence, I will call this effect as cascading impact on applications further.

Hence to handle the cascading impact on application we need an order/chronology to find the impacted applications whenever there is a change in any application. As an outcome of multiple discussions with business, it has been identified that following the order of Original assessment calculation date would be the most suitable approach taking into considerations of many scenarios including some rare edge case scenarios as well.

Here is a simple example to understand the above context better(Please go through the entire example to understand highlighted portion)

**Part 2 Technical solution of the above described business requirement**
To achieve the above business requirement, here is the most suitable technical approach as per the analysis output.

Before getting into the parts of technical requirement, we need to understand 2 chronologies here.
Chronology 1: Ordering by study start date
Chronology 2: Ordering by assessment calculation date (assessment_date) of original assessment
These chronologies are going to be used for different purposes in the solution.

Here are the high level blocks of the technical requirement.

**Calculate assessments sequentially**
The process of calculating assessments sequentially means that, everything before the point of calculation will still happen in parallel in the same way as of now (e.g. Exceptions, PIR, Student income verification, Supporting user income verification(s)), but when workflow reaches the point of calculation, we will be having a node(service task, worker) which will check if this assessment is the first by the order of sequence to be processed? if Yes, the calculations happen for this assessment and until the assessment calculation and workflow is complete, other assessments will be waiting at the same point in assessment-gateway workflow.

To calculate assessments sequentially, Chronology 1 is used.(order by study start date)

Here is an example of how the outcome should look like

**Input PY total of all required awards to Camunda**
For all the awards which requires the PY maximum consideration during assessment, we need to send the total award value consumed by the student for that PY to assessment gateway. Chronology 2 must be used to get total consumed award for the PY.

Please look at the given example

**Create centralized logic to get all impacted applications**
As per the term mentioned in Part 1 comment cascading impact on applications, when any change happens to an application like,

**Cancelling an assessed application (Will be triggered from cancel-assessment queue)**
COE getting declined for an application (Will be triggered from cancel-assessment queue)
Reassessment happening to an application (Will be triggered from assessment-gatway-workflow)
we need to have a logic that identifies, all the potentially impact application due to one of the above actions and create a re-assessment for the identified applications to be potentially impacted.

We must use Chronology 2(order by original assessment calculated date) to execute this logic.

The logic on high level must be, get all the applications who's assessment calculation date(assessment_date) of it's original assessment is after the calculation date of the original assessment of application which is being changed.

**Creating re-assessment for applications that are not completed.**
We need this requirement as a solution to one of the following scenarios where there is cascading impact on applications and impacted application is not completed.

Consider the following scenario

In such situation, we need to re-assess an application which is not complete. As per the current behavior of the system, we do NOT create reassessments for applications which are not complete.

Cancelling assessments when COE is declined - Technical consideration
Currently we cancel assessment, when an assessed application is cancelled by the student.

As an outcome over PY analysis, when we touched the scenario of COE declined scenario, it came out as a good suggestion to cancel the assessment if the first COE of the assessment is declined.

Which indeed leads to, calling cancel-assessment queue, when a COE is declined.

Creation and order of implementation tickets
#2664 Execute assessment calculations in sequence
#2665 Identify related applications to create reassessments on application change and add that to cancel queue
Note: #2664 and #2665 can be worked in parallel

#2672 Input PY Award consumed and Create related application reassessment on reassessment
#2677 Call cancel assessment queue when COE is Declined
Note: #2672 and #2677 can be worked in parallel

#2673 Student application tracker adjustments for new assessment trigger type
#2674 Workflow E2E Tests
#2675 Workers E2E Tests
#2676 COE declined - Cancel assessment - Queue consumers E2E Tests
All the above tickets can be worked in parallel.

Start by reading implementation tickets #2664 and #2665, then follow the assessment-gateway-workflow and cancel-assessment queue references in this epic. Use tickets #2672, #2677, and the listed E2E test tickets to understand the concrete work split; the overall feature is done when sequential assessment processing, PY award totals, cascading reassessments, and COE-decline cancellation are covered.

Written by the indexing model from the issue text.