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 |
Refund memos (system generated) |
PAYMENT |
REFUND_MEMO |
API Registrations
The following rules apply to processed and system-generated registrations:
-
Registrations with Type
PAYMENTand Code TypeCARRYOVER,CARRYOVER_OFFSET,REFUND_OFFSET, orREFUND_MEMOare system-generated. You can’t create, update, or delete these registrations through the APIs. -
Creation and deletion of registrations with Type
PAYMENT, Code TypePAYMENT, and Status A (Applied) are not allowed. In addition, updates to thecorrelationId,status,codeType,type,amount,payDate, andappliedPayDateattributes are not permitted for these registrations. -
If a registrations has a corresponding entry in the Payment Refunds table (that is, registrations has been fully or partially refunded), updates to the
correlationId,status,codeType,type,amount,payDate, andappliedPayDateattributes are not permitted for these registrations.
Calculate Premium
-
Generate period activity splits the periods to align 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 2020/01/01, but must be calculated as of 22 days before policy start, then the collection setting must be set to 2020/01/01 - 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.