Process Registrations
This operation triggers after payments are entered in the register, typically once per day. The operation 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 operation 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 operation 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 operation 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 Developer 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.
| 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 |
Applied |
|
|
|
|
|
Assuming 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.
| 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 ` |
|
|
|
|
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 |
|
REFUND_OFFSET |
|
|
|
| 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 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'). Recalculation a premium generates carryovers. The operation covers the total registration amount to the total amount due for the (not applied) policy calculation periods. 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 periods starting after the selected period that have the same pay date. This is because multiple policy calculation periods that receive a corpus amount have the same pay date.
If the operation 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) and indicator create policy mutation on registration is null , 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'.
There are policy calculation periods where premium can be zero.
When Oracle Health Insurance receives a registration with a zero amount for such a period, this operation applies registration (with zero amount) to that period.
It updates the pay date of the period and the pay date of the calculation result to the pay date of the registration.
The operation sets the Date Paid To to the end date of the policy calculation period.
Then, the operation checks the next period and applies a registration with zero amount to that period.
It updates the Date Paid To and the pay date for both the policy calculation period and the calculation result.
The operation continues to check periods until it finds a policy calculation period with a non-zero calculation result or there are no new periods.
When applying multiple registrations to such consecutive policy calculation periods, the operation marks the registrations as Applied. It updates the pay date of the policy calculation periods and the calculation results to the pay date of the earliest registration.
In the following cases when:
-
the create policy mutation indicator on the registration is set to yes (even for on-time payments) or
-
the total registration amount is more or less compared to the total amount on the calculation result.
The process creates a policy mutation of type recalculation. The start date of the selected policy calculation period becomes the effective date of the policy mutation. 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" chapter 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 Security 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 Security Guide.