Guidelines for Premium Calculation Process
This documents covers general implementation guidelines for Australian Localization premium calculation process.
Registrations
In order to apply registration payment using 'Process Registrations' and 'Apply Registrations to Periods', the following guidelines are required to be followed when payment registrations are sent in using file based import or generic api.
-
The correlation id on registration must be set to the policy GID. This makes it possible for process registration IP to apply payments to a policy.
-
The amount must be positive (zero or greater than zero) for credits and is negative for refunds.
-
The ‘payDate’ attribute on registration is set to the date on which money is received or refunded.
-
AU implementation must not make use of delete and update registration functionality.
-
Any updates to registrations for a payDate must be sent in as additional credits or refunds.
-
Registration must be sent in with field 'status' set to 'NEW'
-
The implementation must not make use of invoice mapping functionally for type code 'PAYMENT".
-
In case of refunds, registration will come in before (and not after) the actual invoice is processed by OHI
Payment Registrations Types
The following payment registration types are expected
Description | Type (TYPE) | Code Type |
---|---|---|
Payment or Refund Registrations |
PAYMENT |
PAYMENT |
Carry Over (system generated) |
PAYMENT |
CARRYOVER |
Carry Over Offset (system generated) |
PAYMENT |
CARRYOVER_OFFSET |
Refund Offsets (system generated) |
PAYMENT |
REFUND_OFFSET |
Calculate Premium
-
Generate period activity splits the periods to a line with calculation period segments based on contract periods and group account settings. Assumption is there is no use case with apply payments where one policy calculation period may contain multiple calculation period segments (no two periods are explicitly merged as part of segment dynamic logic)
-
Split bill functionally is not applicable in context of apply registrations
Generate Policy Calculation Periods
-
The collection setting must start on or before the span reference date
calculation date offset for a policy whose premium should be calculated before the pep start date. This is to ensure that system finds a valid collection setting during premium calculation for forward billing use case to generate periods when the calculation date is set to be before the period start date. For example, policy starts on 01/01/2020, but must be calculated as of 22 days before policy start, then the collection setting must be set to 01/01/2020 - 22 days. -
Policy calculation period must be split on the earliest PEP start date. This is needed when the earliest policy enrollment product takes effect in a policy calculation period corresponding to a previous billing cycle and was not calculated then but will be calculated in the upcoming (subsequent) billing run as catch up calculation.