Process Registrations
This process triggers after payments are entered in the register, typically once per day. The process selects all new payments and determines for each if it was made on the exact date it was due and for the exact amount it was due.
If so, the process moves the ‘Date Paid To’ up to the day that the policy has been paid for and marks the payment as ‘applied’. The ‘Date Paid To’ is an attribute associated with the policy attached data. If not, the process marks the policy for a recalculation by creating a mutation. The recalculation process that follows (which is a separate process) then realigns the payments made with the calculation periods for that policy.
This process can be started by making a POST request to the URI: https://<context:root>/api/specific/processregistrations. This process is an example of Long Running Operations through REST. The general concepts of these operations are described in the HTTP API/IP Concepts chapter of the integration guide. A grant for access restriction 'processregistrations IP' must be provided to be able to initiate this operation.
The following steps are carried out per distinct approved policy for which new registrations are available. If there are registrations that do not match to any policy, then an informative message 'POL-FL-PREG-001' gets logged for each distinct mismatch encountered. Matching is performed by comparing the correlation id of the registrations to the GID of the policy. Unmatched registrations are then marked 'Ignored', so that they are not picked up again when the process runs for the next time.
Select Registrations
The process selects all payments registrations with status ‘new’. First, the process applies negative payments (refunds) when present. A refund negates payments of the past, starting with the most recent (based on pay date) and working its way back.
If there are no refunds to apply then the process applies the new payments starting with the earliest (based on pay date) and working its way forward.
Apply Refunds
For every refund, the process creates offset (-) registrations until the total absolute value of the offsets equals to the refund amount. The process starts by offsetting the most recent payments - New and Applied (ordered by pay date descending). The registrations are grouped by the pay date (this includes payments, refunds, refund offsets, carry forwards and carry forward offsets) and offsets are created corresponding to a maximum of their sum value until the total absolute value of the offsets equals to the refund amount. If there are not enough applied payments that can be offset, the process raises 'POL-FL-PREG-002'
The offset (-) gets the pay date of the payment that it offsets. The status of the offset(s) and refund is set to 'Applied'
After all the refunds are applied, the next step determines the effective date from which the premium must be recalculated. To do that, the process selects the policy calculation period with the pay date same as that of the earliest applied payment (based on pay date) getting offset in this process. The policy mutation of type recalculation gets created with an effective date set to the start date of this policy calculation period (earliest, if multiple). If no period gets selected, then the process raises POL-FL-PREG-003'. If there is no applied payment being offset, no mutation is created (that is, if only the payment(s) in the status 'new' are offset).
Consider the following example to clarify the process of applying refunds (creation of offsets and mutation)
| Correlation ID | Code Type | Amount | Pay date | Status |
|---|---|---|---|---|
POLICY A |
PAYMENT |
100 |
9-June-2019 |
Applied |
POLICY A |
PAYMENT |
20 |
9-June-2019 |
Applied |
POLICY A |
PAYMENT |
150 |
9-July-2019 |
Applied |
POLICY A |
PAYMENT |
-180 |
10- August -2019 |
New |
Here for policy A, a refund of -180 is registered as of 10-August-2019. The effect of the applying refund is that the payments of July and beyond are offset until the refund amount runs out. After the refund gets applied:
| Correlation ID | Code Type | Amount | Pay Date | Status |
|---|---|---|---|---|
POLICY A |
PAYMENT |
100 |
9-June-2019 |
Applied |
POLICY A |
PAYMENT |
20 |
9-June-2019 |
Applied |
POLICY A |
REFUND_OFFSET |
- 30 |
9-June-2019 |
Applied |
POLICY A |
PAYMENT |
150 |
9-July-2019 |
Applied |
POLICY A |
REFUND_OFFSET |
-150 |
9-July-2019 |
Applied |
POLICY A |
PAYMENT |
-180 |
10- August -2019 |
Applied |
POLICY A |
REFUND_OFFSET |
180 |
10- August -2019 |
Applied |
ssuming the policy calculation periods are calendar months and the pay date is after the month start, policy mutation for policy A gets created with an effective date of 1st June. The process of applying payment registration stops and the process moves to the next policy.
Suppose there is a new refund for value 50 for POLICY A as of 11 August, this refund offsets payment of 9th June as the total payment for July sum up to zero.
After the refund of 50 is applied
| Correlation ID | Code Type | Amount | Pay Date | Status |
|---|---|---|---|---|
POLICY A |
PAYMENT |
100 |
9-June-2019 |
Applied |
POLICY A |
PAYMENT |
20 |
9-June-2019 |
Applied |
POLICY A |
REFUND_OFFSET |
-30 |
9-June-2019 |
Applied |
POLICY A |
REFUND_OFFSET |
-50 |
9-June-2019 |
Applied |
POLICY A |
PAYMENT |
150 |
9-July-2019 |
Applied |
POLICY A |
SYSTEM_OFFSET |
-150 |
9-July-2019 |
Applied |
POLICY A |
PAYMENT |
-180 |
10- August -2019 |
Applied |
POLICY A |
SYSTEM_OFFSET |
180 |
10- August -2019 |
Applied |
POLICY A |
PAYMENT |
-50 |
11-August-2019 |
Applied |
POLICY A |
REFUND_OFFSET |
50 |
11-August-2019 |
Applied |
The code of the offset registration is system generated unique value and codeType is set to REFUND_OFFSET
Apply Payments
In this step, the process tries to assess if the payment for a policy calculation period is on time and is exact or not. To do that the process must first identify the policy calculation period from where the payments are yet to be applied. This is the policy calculation period that follows the 'Date Paid To'. If the 'Date Paid To' is null, the the system selects the policy calculation period in which the earliest policy enrollment product starts.
If no policy calculation period is found, system stops the process of applying payments and moves to the next policy in the selection. This is possible for advance payment scenario wherein customer has paid unsolicited payment and the premium is not yet calculated in the system. This payment will get applied in the next step 'Apply Registrations to Periods'.
After the policy calculation period is determined, the subsequent step is to find out if the received payment is on time or not, and is exact or not.
Existing Mutations?
If a policy mutation of type recalculation exists then the process of applying payments stops and the process moves to the next policy.
Apply Payments
The process sums up the payments in the status 'new' , applied refunds and refund offsets having the pay date same as that on the selected policy calculation period and all the carry overs in the status 'new' (registration with the codeType 'CarryOver'). Carry overs are generated by the recalculation process. The total registration amount is compared to the total amount due for the (unapplied) policy calculation period(s). To calculate the amount due for the periods, the process sums up the non reversed latest calculation result of the selected policy calculation period and the policy calculation period(s) starting after the selected period, and having the same pay date. This is because multiple policy calculation periods having the same pay date can exist and it is possible that the system receives a single payment corresponding to all these period is received.
If the system finds no calculation result then the payments (and carry over) remain in the status 'new' and process moves to the next policy.
If the total registration amount is equal to the total on the calculation result(s), the policy calculation period(s) qualifies for 'on time' payment. The effect of 'on time' payment is that the 'Date Paid To' on the attached data gets updated to the most recent calculation period end date and the status on the payments (and offset) gets updated to 'Applied'. The attribute applied pay date on the carry over gets set to the pay date of the payment. The process then moves to the next (unapplied) policy calculation period and the steps are repeated until there is no more payment in the status 'new'.
If the total registration amount is more or less compared to the total amount on the calculation result(s) then the process creates a policy mutation of type recalculation with an effective date equal to the start date of the selected policy calculation period. The status of the payments and the 'Date Paid To' is not updated. The registrations are not applied any further and the process moves to the next policy.
If no payments can be found on the pay date of the policy calculation period (early or late payments) but there is at least one payment for a different pay date in the status 'new' and the payments are in order, that is, there exists no payment registrations in status 'applied' with the pay date being after the pay date on the earliest new payment registration, then the process creates a policy mutation of type recalculation with an effective date equal to the start date of the selected policy calculation period. If the payment registrations are not applied in order then the system must consider the pay date on the earliest new payment registrations while determining the effective date. In such a case, the effective date is set to the start date of the policy calculation period or the pay date of the earliest new payment registration, whichever is earlier. The status of the payments (and carry over) and the 'Date Paid To' is not updated. The payments are not applied any further and the process moves to the next policy.
Messages
The following messages can occur during this process
| Code | Sev | Message Text |
|---|---|---|
POL-FL-PREG-001 |
Informative |
No policy with the correlation id {correlationId} found in the system |
POL-FL-PREG-002 |
Fatal |
Insufficient applied payments to apply the refund received with the pay date {pay date} for the correlation id {correlationId} |
POL-FL-PREG-003 |
Fatal |
Mutation could not be created for correlation id {correlationId} after applying refunds as policy calculation period with the pay date {date} is not found |
Examples
Scenario A : on time and exact payment
In this scenario the registration of amount 100 is received on the pay date of the calculation period. The amount expected for the period is also 100. Therefore payment is on time and is exact. The 'Date Paid To' is updated to the period end date and the registration is considered as 'Applied'.
Scenario B: late payment or insufficient payment
In this scenario the registration of amount 100 is received after the pay date of the calculation period. The amount expected for the period is 100 but it is received late. For this scenario, this process will not find any registration on the pay date of the calculation period and therefore the 'Date Paid To' is not updated and a policy mutation of type recalculation with an effective date of payment pay date is created ( as the pay date is earlier compared to the policy calculation period start date). The fact that the payment is late is visible to the process during the premium recalculation process. For details refer to the AU premium calculation specifications.
Response
As is described in Long Running Operations through REST there are multiple ways in which one can get the response/result of this long running operation. Typically though one would opt for using notification events.
A notification message can be sent out to a pre-configured endpoint. The notification endpoint can be configured on 'ohi.activityprocessing.notification.endpoint.PROCESS_REGISTRATIONS' or to a more generic endpoint: ohi.activityprocessing.notification.endpoint.
If the notification endpoint is configured on the specific: PROCESS_REGISTRATIONS, all other related properties like media type, authentication, etc. are also fetched based on PROCESS_REGISTRATIONS, or else defaults are used. Similarly, if the endpoint for the notification is configured without the specific code, then all other properties are fetched on a generic use case code 'ActivityNotificationClient'. Please see section Outbound RESTful Service Invocations in Integration Guide for the process and more properties.
The notification message has the common notification structure as described in the chapter Long Running Operations through REST in the Integration Guide.