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.

API Policy Calculation Periods

• The policy calculation periods must not be update or adjust periods using APIs as the 'Apply Registration to Periods' process will replace and (re)generate periods (always).