Calculate Premium

The Calculate Premium activity is started by the user. This is the only activity in the premium calculation context that is started by a user; all other activities in this context are automatically started by the system itself.

The user can control the scope of the calculation by selecting values for the following parameters:

Brand

If specified, the calculation only picks up policies for that brand. If not, then the calculation picks up policies due for calculation from any brand.

Group Client

If specified, the calculation only picks up policies for the group accounts in the group client*. If not, then calculation picks up policies due for calculation from any account.

Group Account

If specified, the calculation only picks up policies for that group account. If not, then the calculation picks up policies due for calculation from any account ^[1].
If unspecified is selected, the calculation only picks up individual policies (group client parameter should be empty in that case).

Calculation Input Date

Based on the mandatory calculation input date, the calculation period is selected for each policy. This is the period up to and including which premium is to be calculated. The calculation automatically includes earlier periods that need to be (re) calculated. It is also possible that the calculation automatically includes future periods, that is, for policies for which premium is pre-paid.

Look Back Date

It prevents the system from recalculating premium for the calculation periods before this date. When not specified, it is set to the Calculation Input Date.

Premium Financial Transaction Function

This function facilitates the modification of 1) financial transaction details and 2) financial transaction and financial transaction process data attributes of the premium financial transaction.

Commission Financial Transaction Function

This function facilitates the modification of 1) financial transaction details and 2) financial transaction and financial transaction process data attributes of the commission financial transaction.

Disable Grouping on Reversal Indicator for Invoice Lines?

Default behavior is that invoice lines are grouped on (among others) the reversal indicator; as a consequence credit and debit invoice lines can never result in a single zero result invoice line. Setting the parameter to 'Y' will disable this default behavior.

Generate Policy Calculation Periods?

Generate policy calculation period up to the input calculation date for a policy where 1) policy calculation periods are not already present and 2) policy calculation period applies. The applicability of policy calculation period is driven by the indicator policy calculation period on the collection setting.

Replace Policy Calculation Periods?

When set to Yes in combination with the indicator Generate Policy Calculation Periods, the policy calculation periods are replaced from the date equal to policy mutation effective date that is nearest to and after the look back date up to the input calculation date

Ignore policies that belong to CHANGED group clients?

When set to Yes the system will not calculate policies for group clients that have the status CHANGED. The setting has no impact on policies that do not belong to a group client.

Add group client event when a policy calculation fails?

When set to Yes the system will add a group client event to the group client when calculation for one or more policies of that group client raises a fatal message.The setting has no impact if the policy does not belong to a group client.

Set group client status to CHANGED when a policy calculation fails?

When set to Yes the system will set the status of the group client to CHANGED when calculation for one or more policies of that group client raises a fatal message. The setting has no impact if the policy does not belong to a group client.

The only purpose of this activity is to split up the calculation load over each combination of brand and group account. Within the context of splitting up the load, the system treats all individual policies together as one separate group account.

This activity starts one new Calculate Premium per Group Account activity for each distinct combination of brand and group account. If the user sets the parameter 'Ignore policies that belong to CHANGED group clients?' to yes, the system will not create new activities for group accounts where the Group client of the group account has the status Changed.

If a single group account (X) includes policies that belong to brand A and other policies that belong to brand B, it is possible to start a calculation for only those policies that belong to account X and brand A, or only those policies that belong to account X and brand B. If the user specifies account X as a parameter - and leaves the brand empty - then the calculation picks up all policies that belong to account X, both for brand A and B.

The following messages can occur during this activity:

Code	Severity	Message Text
POL-VL-CAPR-001	Fatal	Brand code {code} is unknown
POL-VL-CAPR-002	Fatal	Group account code {code} is unknown
POL-VL-CAPR-004	Fatal	Look back date {date} must be on or before the calculation input date {calculation_input_date}
POL-VL-CAPR-005	Fatal	Function dynamic logic code {code} is unknown or has an invalid signature
POL-VL-CAPR-006	Fatal	Group client code {code} is unknown

Calculate Premium per Group Account

The Calculate Premium activity creates and starts the Calculate Premium per Group Account activities. These activities cannot be started directly by the user, although starting the Calculate Premium for a specific group account and brand has the same effect.

The purpose of this activity is to select all policies that may be eligible for calculation. These are all policies (latest Approved versions) that:

• belong to the specified group account, or - if the group account parameter has the value unspecified - have no group account. A policy belongs to a group account if the policy group account relation has not ended before the look-back date
  

and

• have a policy enrollment product that has not ended before the look back date or have a non-reversed calculation result with a calculation period start date that includes or starts after the look back date.

For each of the eligible policies, this activity starts a new Calculate Premium per Policy activity.

Calculate Premium per Policy

The Calculate Premium per Group Account activity creates and start the Calculate Premium per Policy activities.The following image shows the process steps in this activity:

The following sections contain detailed descriptions of the system logic for each of these steps.

If any of the steps raises a message (for example if the activity finds multiple applicable premium schedule lines), the activity sets the element_id of the message to the policy code of the policy in context (for example: element_id="POL0002340"). If the policy is part of a group client, the activity sets the element id of the message to the policy code plus the group client code of the policy in context, separated by a semicolon (for example: element_id='POL0002340;GRC0076543").

If any of the steps raises a message, and the activity parameter 'Add group client event when a policy calculation fails?' is set to yes, and the policy is part of a group client, the system adds a Group Client Event record with the description 'Premium calculation failed' to that group client. There will be only one group client event added to the group client for each group client that has one or more failing policy premium calculation.

If any of the steps raises a fatal business error message and the activity parameter 'Set group client status to CHANGED when a policy calculation fails?' is set to yes, and the policy is part of a group client, the system sets the status of the group client to CHANGED. The system will not set the status in case an invalid activity parameter value raises a fatal message (e.g Brand code {code} is unknown).

Generate Policy Calculation Period

The system only executes this step when the Generate Policy Calculation Periods? parameter is Yes.

This step is identical to the Generate Policy Calculation Period per Policy activity as explained in Generate Policy Calculation Periods.

This step requires three parameters:

Generate Up To Date

The system uses the value from the premium calculation parameter _Calculation Input Date

Replace From Date

When the premium calculation parameter Replace Policy Calculation Periods? is Yes, the system uses the policy mutation effective date that is nearest to and after the value in the premium calculation parameter Look Back Date.
If the premium calculation parameter Replace Policy Calculation Periods? is No, this parameter is not applicable.

Look Back Date

The system used the value from the premium calculation parameter Look Back Date.

If there is no policy mutation with an effective date after the look back date, then the system will not replace policy calculation periods.

Select Calculation Periods

The first step in this activity is to determine the time spans for which the policy has to be calculated or recalculated. These can be past calculation periods, that is, periods that have not been calculated yet or have to be recalculated due to retroactive changes, or they can be future periods, that is, if the premium is to be paid upfront for several calculation periods.

First the system selects the system calculation periods (when available) that include the look back date, up to the specified calculation input date.

Then the system selects all the policy calculation periods (when available) with the calculation date on or before the calculation input date and that start on or after the look back date.

Then the system creates a single timeline composite of system calculation periods and policy calculation periods.

Policy calculation periods, when present, have a higher priority over system calculation periods. The system does not consider any system period if a policy calculation period (selected or not) overlaps with it. Consider the following examples to clarify:

Example 1

The following system calculation periods exist:

Start Date	End Date	Display Name
1 Jan 2020	31 Jan 2020	January 2020
1 Feb 2020	28 Feb 2020	February 2020
1 Mar 2020	31 Mar 2020	March 2020

The following policy calculation periods exist:

Start Date	End Date	Calculation Date
1 Jan 2020	31 Jan 2020	15 Dec 2019
1 Feb 2020	28 Feb 2020	15 Jan 2020

If you start premium calculation with the calculation input date 15 Jan 2020 and look back date 15 Jan 2020, the system selects system calculation period January 2020 because it includes the look back date.

It also selects the policy calculation period starting at 1 Feb 2020 because the calculation date is on or before the calculation input date, and it starts on or after the look back date.

The selected policy calculation period overlaps with the selected system calculation period. Therefore, the system will not consider the system calculation period in plotting the timeline.

Example 2

The same system calculation periods as in example 1 exist.

The following policy calculation periods exist:

Start Date	End Date	Calculation Date
1 Jan 2020	3 Jan 2020	1 Jan 2020
4 Jan 2020	31 Jan 2020	4 Jan 2020

If you start premium calculation with the calculation input date 4 Jan 2020 and look back date 14 Jan 2020, the system selects system calculation period January 2020 because it includes the look back date.

It also selects the policy calculation period starting at 4 Jan 2020 because the calculation date is on or before the calculation input date, and it starts on or after the look back date.

The selected policy calculation period overlaps with the selected system calculation period. Therefore, the system will not consider the system calculation period in plotting the timeline.

Identify Calculation Period Segments

Per selected calculation period, the system detects if there have been changes to the policy’s group account and/or contract period in that calculation period. If so, the system subdivides the calculation period into smaller calculation period segments, that is, one segment per combination of group account period and contract period.

Contract periods without overlapping group account periods, and group account periods without overlapping contract periods also result in separate calculation period segments.

The system will calculate and store the calculated results for each segment separately.

Contract and group account changes are typically not as frequent as the recurrence of calculation periods.In most situations there is only one calculation period segment that covers the full calculation period.

Reference Date of the Calculation Period Segments

If the calculation period segment belongs to a policy calculation period, the system uses the reference date setting on the policy calculation period; if that policy calculation period reference date is blank, the system uses the policy calculation period start date.

If the calculation period segment belongs to a system calculation period and is for a policy contract period,the system uses the reference date from the contract period in which the calculation period segment starts; if that contract period reference date is blank, the system uses the contract period start date.

If the calculation period segment belongs to a system calculation period but is not for a policy contract period, the system uses the reference date setting on the system calculation period; if that system calculation period reference date is blank, then the system uses the system calculation period start date.

Collection Cycles for System Calculation Period

If the last period in the selection is a system calculation period, then the system must determine the future calculation periods.

The driving attributes that control how far into the future the system calculates are the advance length, the advance unit of measure and the span reference date. These attributes are part of the collection setting. Collection settings can be specified on multiple levels: policy, group account or group client.

The system does not directly control the premium collection cycle as this is the responsibility of the down stream accounts receivable system. However, in order to support different collection cycles downstream, the system does need to know exactly how far to calculate ahead. For example, if the accounts receivable system collects premium once a year, the premium calculation activity needs to be aware that it needs to calculate twelve months into the future, once per year.

The system searches all collections settings that are valid on the reference date of the last calculation period segment that maps to the selected period. If the system finds multiple levels of collection settings, it will use the following priority to select the applicable collection setting:

1. Policy

2. Group Account

3. Group Client

4. Parent Group Client (and further up the Group Client hierarchy)

The system considers the group client hierarchy that is in the context of the calculation period segment’s group account.

If the system cannot find a collection setting for a calculation period segment, or the identified collection setting has the indicator policy calculation period set to 'Y', the system will not calculate into the future.

If the collection setting specifies an advance period, the system calculates the premium once per advance period, for all calculation periods that start within that advance period. The span reference date is the date from which the system extrapolates the advance periods. The extrapolated span reference date is stored on each calculation result that belongs to a single cycle as calculation date. Thereby making it possible to identify the calculation results that are part of one cycle.

This feature supports the situation where a payer wants to calculate and create invoices upfront. For example, it can be set up to calculate and create an invoice message for month 1, 2 and 3 at the start of quarter 1, calculate and send an invoice for month 4, 5, and 6 at the start of quarter 2 and so on.

This also means that when the user runs the calculation for February, the system selects the calculation for March (again) as eligible for recalculation. The system does not look beyond the collection cycle of the specified calculation period. So when the user runs the calculation for March, the system does not select the calculation period for April, as it belongs to the next collection cycle.

The span reference date setting identifies the start of the first collection cycle. The first calculation period of all subsequent cycles is determined based on an extrapolation of this date.

Once the future calculation periods are identified, system re-plots the calculation period timeline, identifies Calculation Period Segments within these periods and computes the reference date as applicable per segment.

For any gaps in the timeline, that is, system and policy calculation period both do not exist, the message 'POL-FL-CAPR-019 is logged for each gap.

Code	Severity	Message Text
POL-FL-CAPR-019	Informative	No system or policy calculation period identified between {date1} and \{date2 }

Reverse Future Calculation Results

The system flags existing calculation results for reversal if they

• have a start date after the start date of the calculation period to which the input calculation date belongs to,

• and have no future periods corresponding to them,

• and have been identified as eligible for recalculation,

• and are not already reversed,

The policy version in context is set as the reversal policy on the results. The system does not recalculate these calculation period segments of these calculation periods. It will pick them up in the last step 'Write Calculation Results and Financial Transactions' of the premium calculation process.

This situation can occur if a policy has (accidentally) been calculated too far into the future, and the results are not reversed using Reverse Calculation Result process. For details on Reverse Calculation Results refer to the chapter 'Reverse Calculation Results' in this guide.

Reverse Calculation Results Without Corresponding Calculation Periods

If there are previous calculation results that have a start date within the current calculation timeline, but do not have any calculation period with the same start date in the timeline, then the system flags these results for reversal.

Verify Calculation Periods

The previous step resulted in a list of all calculation periods for a single policy that may require (re)calculation. This step filters the list down to only the calculation periods needing (re)calculation.

The system runs the next step for each of the identified calculation periods individually.

Past Results
The system removes the calculation period from the list if there is a previous non reversed calculation result, but there are no policy mutations that take effect before or on the last day of the calculation period.

This check makes sure that past calculations that are still valid are not recalculated.

The system retains the calculation period in the list if there is a previous non reversed calculation result and at least one policy mutation that takes effect before or on the last day of the calculation period. It reverses all the existing calculation results related to the calculation period. The policy version in context is set as the reversal policy.

This check makes sure that calculation periods with mutations are recalculated and all the existing results are reversed.

Verify Calculation Period Segments

The next sub-steps are executed individually for every calculation period segment in every verified calculation period.

Calculation Period Segment Without Enrollments

If there is no previous calculation result and there is no effective policy enrollment product during (any part of) the calculation period segment, the system removes the calculation period segment from the list.

For a policy with a contract period, if there is a previous calculation result and there is no effective contract period during any part of the calculation period segment, the system removes the calculation period segment from the list.

This check prevents the system from attempting to calculate calculation period segments of a calculation period for a policy during which there is no enrollment (and contract) yet.

Retroactively Ended Policies

If there is a previous calculation result, but there is no effective policy enrollment product during (any part of) the calculation period segment, the system flags the calculation period segment results for financial reversal.

If there is a previous calculation result related to a contract period, but there is no effective contract period during any part of the calculation period segment, the system flags the calculation period segment results for financial reversal.

This situation can occur in the following cases:

• If all policy enrollment products (and contract period) on the policy have been end-dated or

• When a contract start date or policy group account changes

Select Policy Enrollment Products

Per calculation period segment the system selects the policy enrollment products that have time overlap with the calculation period segment. It then iterates the subsequent steps per verified calculation period segment, per overlapping policy enrollment product.

Calculate Enrollment Product Premium

This section describes how the system determines the premium for the combination of a calculation period segment and a single policy enrollment product. It repeats these steps for every policy enrollment product under the policy.

Determine Premium Schedules and Definitions

The system finds the applicable premium schedules by first retrieving the applicable enrollment product or group account product. The enrollment product or group account product links (directly or through the group account or group client) to one or more premium schedules. The premium schedules link to their schedule definitions.

Premium schedules can be assigned on multiple levels: enrollment product, group account product, group account or group client. The system only considers assigned premium schedules that are effective on the reference date. If the system finds effective premium schedules for a policy enrollment product on multiple levels, it uses the following priority to select the applicable premium schedules:

1. Group Account Product

2. Group Account

   1. In the context of a specific Enrollment Product Category (assigned premium schedule with a specified Enrollment Product Category)

   2. For all enrollment products (assigned premium schedule without a specified Enrollment Product Category)

3. Group Client

   1. In the context of a specific Enrollment Product (assigned premium schedule with a specified Enrollment Product)

   2. In the context of a specific Enrollment Product Category (assigned premium schedule with a specified Enrollment Product Category)

   3. For all enrollment products (assigned premium schedule without a specified Enrollment Product or Enrollment Product Category)

4. Parent Group Client (and further up the Group Client hierarchy): same sub levels apply as specified for the Group Client level

5. Enrollment Product

The system only selects the premium schedules of the most specific level. For premium schedules that are assigned to a group account or a group client, the system only selects the premium schedules of the most specific sub level. So if, for example, a group client has both an assigned premium schedule with a specified enrollment product and an assigned premium schedule without a specified enrollment product or enrollment product category, only one of those will be applied depending on the policy enrollment product that is being evaluated.

The premium schedules tell the system if it has to apply the premium amounts (to be retrieved in the next step) per calendar year, per calculation period or for a specific number of days. If the premium applies per calendar year, and the calculation period to which the calculation period segment in context belongs is configured such that it spans more than one year, the system logs message POL-FL-CAPR-001.

It is possible that the system finds multiple premium schedules on the most specific level. If this occurs then the system evaluates each of the premium schedules separately, producing a separate calculation result line per premium schedule. Effectively, that means that the base premium is the sum of all the premium rates retrieved from each premium schedule.

If a retrieved schedule definition has a schedule condition, then the system evaluates that condition to determine if the selected schedule(s) that is/are based on that definition should be applied or not.

If a retrieved schedule definition is not enabled, the system logs message POL-FL-CAPR-002.

If no premium schedules can be determined for the policy enrollment product, the system logs message POL-FL-CAPR-011.

Code	Severity	Message Text
POL-FL-CAPR-001	Fatal	The calculation period cannot extend beyond a year when the premium amount applies per year
POL-FL-CAPR-002	Fatal	The schedule definition \{schedule definition code} is not enabled
POL-FL-CAPR-011	Fatal	Policy enrollment product {code} has no premium schedules

Policy Based Premium Schedules

If the premium schedule definition is of type 'Policy Based Premium', the system calculates the premium only once per policy instead of once per policy enrollment product. In this case the system calculates the premium for policy enrollment products where:

1. The enrolled person is the policy holder.

2. If the policy holder is not enrolled for the enrollment product, the system calculates the premium for the oldest enrolled person on the policy (for this enrollment product).

The system ignores all other policy enrollment products for the same premium schedule.

Mixed Premium Schedule Types

It is possible to have a mix of 'Premium' and 'Policy Based Premium' premium schedules on an enrollment product. If this occurs, the system evaluates each of the premium schedules separately, producing separate calculation result lines according to the logic that belongs to the premium schedule type. This means that the premium from a 'Policy Based Premium' premium schedule results in a single calculation result line per policy, and the premiums from a 'Premium' premium schedule result in a calculation result line per policy enrollment product (if applicable).

Example:

This example explains a policy with 3 enrolled persons. All persons are enrolled on the same enrollment product that has a 'Premium' and a 'Policy Based Premium' premium schedule assigned. There are only two premium tier definitions, Single and Family. This policy qualifies as a Family tier policy. The extra premium schedules covers additional benefits where the system calculates the premium per enrolled person based on the age of the person.

Enrolled Person	Age	Policy Holder?	Enrollment Product	Premium Schedule	Schedule Definition Type
John Doe	41	Y	STANDARD_PLUS	STANDARD	Policy Based Premium
				STANDARD_PLUS	Premium
Jane Doe	38	N	STANDARD_PLUS	STANDARD	Policy Based Premium
				STANDARD_PLUS	Premium
Benjamin Doe	10	N	STANDARD_PLUS	STANDARD	Policy Based Premium
				STANDARD_PLUS	Premium

The associated premium schedules are as follows:

STANDARD

Tier	Premium
Single	$50.00
Family	$90.00

STANDARD_PLUS

Age From	Age To	Premium
0	10	$20.00
11	20	$18.00
21	50	$15.00
51	75	$20.00f
76	90	$22.00
91		$25.00

The total premium for this policy is $90.00 for the STANDARD coverage
$15.00 (John Doe) + $15.00 (Jane Doe) + $20.00 (Benjamin Doe) for the STANDARD_PLUS coverage, so a total of $140.00 for this policy.

Determine Value Reference Date

The reference date identified in the previous step (Reference Date of the Calculation Period Segment) for the calculation period segment is also the value reference for a calculation period segment that is in context of a system calculation period.

For calculation segment that is in context of a policy calculation period, the value reference date may be specified on the schedule definition. When specified, this is the date value of the policy calculation period field referenced by Reference Date Field Name on the schedule definition. If the reference date field name is not set or set to a field (name) that does not exist, or the field value (on policy calculation period) is null, then the system considers the calculation period segment reference date as value reference date. The system evaluates this step for each identified premium schedule.

Select Time Periods

The value reference date identified in the previous step drives the time period selection for each premium schedule.

For group account policies, the system first retrieves the group account time period that includes the value reference date. The system then retrieves the default time period and enrollment product time period that includes the start date of the selected group account time period. If the group account time period does not exist, the system retrieves the default time period and the enrollment product time period that includes the value reference date.

For individual policies, the system first retrieves the enrollment product time period that includes the reference date. The system then retrieves the default time period that includes the start date of the selected enrollment product time period. If the enrollment product time period does not exist, the system retrieves the default time period that includes the value reference date.

Either way, the resulting default time period determines the set of premiums schedule lines that are evaluated.

Once the appropriate default time period, (if applicable) enrollment product time period and group account time period have been retrieved for all the identified premium schedules, they are used by all following steps that apply to the policy enrollment product premium.

If for any premium schedule the default time period cannot be determined, the system logs the following message:

Code	Severity	Message Text
POL-FL-CAPR-010	Fatal	No default time period can be determined for Premium Schedule {code}

Determine Premium Schedule Line

This step determines the premium amount per retrieved premium schedule.

If

• the premium is specified on the policy enrollment product,

• and the schedule definition type is not 'Policy Based Premium'
  or
  the calculation period in context of the calculation period segment is not the policy calculation period,

the system uses the premium on the policy enrollment product for further calculation. The system disregards the premium schedule lines.

For enrollment products with a policy based premium schedule, the system always calculates the premium based on the premium schedule. Similarly, if the calculation period in context of the calculation period segment is a policy calculation period, the system always calculates the premium based on the premium schedule.

If not, the system has to find the matching premium schedule line to obtain the appropriate premium amount. The line that matches is the one for which the policy enrollment product satisfies all specified line conditions. These configurable conditions are typically on the person’s demographics - such as age or gender - and /or on the choices the person made on the policy, such as the co-payment amount.

The premium schedule line holds either an amount or a dynamic logic function. If the system finds an amount, it uses this value to further calculate the premium. If the system finds a dynamic logic function, it runs the logic to calculate the premium amount. If the system finds a premium schedule line with an amount in a different currency than the enrollment product premium currency, it ignores the line (so no premium is calculated).

If multiple applicable premium schedule lines exist in a retrieved premium schedule, the system raises the following message:

Code	Severity	Message Text
POL-FL-CAPR-009	Fatal	Multiple applicable premium schedule lines exist for policy enrollment product {code} and premium schedule {code}

If the system finds no applicable premium schedule line in a retrieved premium schedule and the schedule definition has 'Indicator Fatal If Not Found' set to Yes, the system raises the following message.

Code	Severity	Message Text
POL-FL-CAPR-020	Fatal	Premium value is not specified for the premium schedule \{schedule code}, for member \{member code} and enrollment product \{enrollment product code} within the calculation period \{calculation period start date}.

Determine Premium Amount

The system evaluates premium schedule lines by comparing the field values on the premium schedule line to the field values on (or applicable to) the policy enrollment product. The fields on the schedule lines are called schedule dimensions. The system looks for a premium schedule line that matches on all dimensions; when it finds it, it uses the premium amount on that line, or the result of the dynamic logic function found on that line, for further calculation.

The system only evaluates a dimension on the schedule line if it has a value.

All dimensions are the result of configuration. See the guide on premium configuration for details. There are four types of configurable schedule dimensions; parameter dimensions, dynamic field dimensions, generic dimensions and premium tiers. This last type is only available for schedules definitions that belong to the type 'Policy Based Premium'. The system evaluates each of these four types differently.

Parameter Dimensions

The system evaluates parameter dimensions by comparing the value on the premium schedule line to the parameter value that applies to the policy enrollment product. Each parameter value has its own time-effective span. The appropriate parameter values to consider are the ones effective on the reference date.

Depending on the configuration of the schedule dimensions, the determined parameter value either has to be equal to the value on the premium schedule line, or the determined parameter value has to be within a range specified on the premium schedule line. If the line specifies a range, the parameter value has to be equal or greater than the range from field but no greater than the range to field. For parameters of type amount the currency on the determined parameter value has to be equal to the currency of the parameter on the premium schedule line.

The policy enrollment product has its own start and end date. The system retrieves the parameter values that apply on the reference date, except in the scenario where the policy enrollment period starts after, or ends before the reference date. If it starts after the reference date, the system uses the start date of the policy enrollment product instead. If it ends before the reference date, the system uses the policy enrollment end date instead.

Dynamic Field Dimensions

The system evaluates dynamic field dimensions by comparing the value on the premium schedule line with the value of the dynamic field. A dynamic field dimension evaluates one specific dynamic field. These can be dynamic fields on any of the following entities:

Entity	Context of
Enrollment Product	The enrollment product as specified by the Policy Enrollment Product
Policy Enrollment	The person or object as specified by the Policy Enrollment Product
Policy Enrollment Product	The Policy Enrollment Product for which the premium is being computed for
Group Account Product	The group account product as specified by the Policy Enrollment Product
Group Account	The group account of the group account product
Group Client	The group client of the group account product, that is the group client of the group account that the group account product belongs to
Policy and Policyholder	The policy for which the premium is being computed and the policyholder of this policy
Collection Setting	The collection setting for which the premium is being computed
Policy Calculation Period	The policy calculation period that us being calculated
Relation	The person as specified by the Policy Enrollment Product
Relation Address	The default address of the person
Insurable Object1..10 [2] 2. The system supports up to 10 types of insurable objects, e.g. Cars, Boats, etc. Each insurable object type can have its own definition of dynamic fields.	The object as specified by the Policy Enrollment Product

If the evaluation of premium schedule lines tries to compare a dynamic field dimension on the premium schedule line with a dynamic field that is not configured on the entity in context, the premium schedule line is ignored.

Consider a policy with policy enrollments for two different insurable entity types: a person and a car. The configuration of the person holds a dynamic field Age. The car does not hold this dynamic field. Premium schedule lines that have Age as a dimension can only be evaluated for policy enrollment products for persons. The lines are ignored when evaluating them against policy enrollment products for cars.

The policyholder has its own time-effectiveness. To be able to match the dynamic field values of the policyholder with the values on premium schedule lines, first the appropriate policyholder needs to be retrieved. The system retrieves the policyholder that applies on the reference date, except in the scenario where the policy enrollment period starts after, or ends before the reference date. If it starts after the reference date, the system uses the start date of the policy enrollment product instead. If it ends before the reference date, the system uses the policy enrollment product end date instead. The same applies for retrieving the address of the enrolled person.

It is also possible that the dynamic field values are time-effective. In this case the system uses the reference date, the policy enrollment start date or the policy enrollment end date (as specified above) to retrieve the appropriate dynamic field value.

Consider a premium schedule definition that has the dynamic field dimension 'Student Status'. The 'Student Status' is a dynamic field on the person record. This dynamic field is time valid. When the system determines the applicable premium schedule line, it evaluates the value on the premium schedule line for the person that is enrolled for the enrollment product. The system compares the value of the 'Student Status' field for this person on the reference date (or policy enrollment product start/end date) to the value on the premium schedule line.

Depending on the configuration of the schedule dimensions, the dynamic field value either has to be equal to the value on the premium schedule line, or the dynamic field value has to be within a range specified on the premium schedule line, in order for the premium schedule line to apply. If the line specifies a range, the dynamic field value has to be equal or greater than the range from field but no greater than the range to field. For multi-value dynamic fields at least one dynamic field value has to be equal to the value on the premium schedule line, or at least one dynamic field value has to be within a range specified on the premium schedule line (as described above).

Generic Dimensions

The third type of the configurable dimensions is generic. Generic dimensions allow the configuration of customized comparisons that cannot be achieved by the other types of dimensions.

Like the other two dimension types, a generic dimension is a column in a premium schedule, but the difference is that there is no embedded evaluation logic. Instead, the user can configure this evaluation logic by setting up a dynamic condition and attaching it the schedule definition. This condition has access to the fields on the premium schedule line and the policy enrollment product and is required to return a boolean value.

The system only considers a premium schedule line to match the policy enrollment product if the user configured evaluation condition returns true for the combination of the line and the policy enrollment product.

If there is no evaluation function configured for the premium schedule, the system ignores the generic dimensions when determining the matching premium schedule line.

Was the person or object enrolled?

This step determines if the policy enrollment product has full or partial overlap with the calculation period segment. The policy enrollment products that have no overlap at all have been disqualified in a previous step.

If the policy enrollment product starts after the calculation period start date to which the calculation period segment in context belongs, or if the policy enrollment product ends before the calculation period end date to which the calculation period segment in context belongs, then the person or object was partially enrolled during the calculation period. In all other situations, the person or object was fully enrolled for the product during the calculation period.

For the premium calculation process, in case of the policy with a contract period, if the policy enrollment product starts before the calculation period segment contract start date, then the system uses the contract period start date of the calculation period segment in context for the policy enrollment product start date instead. Similarly, if the policy enrollment end date ends after the calculation period segment contract period end date, then the system uses the contract period end date of the calculation period segment in context for policy enrollment product end date instead.

Premium Tiers

The last type of the configurable dimensions is the premium tier. Premium tiers are not configured as schedule dimensions as such but can be defined on premium schedule lines directly. Premium tiers are only applicable to premium schedules with a schedule definition of type 'Policy Based Premium'.

A premium tier evaluates to true if its conditions are met by the distinct set of eligible policy enrollments within the policy. A policy enrollment is eligible when it has a policy enrollment product that is active on the reference date on an enrollment product that is linked to the same premium schedule as the one that is evaluated.

A premium tier matches if the following conditions are met:

1. The number of distinct eligible policy enrollments meets the condition set on the tier (e.g. no more than 5)

2. The set of distinct eligible policy enrollments meets the conditions set by the each and every one of the premium tier types (E.g. there must be exactly 1 Primary and no more than 3 children).

The following example illustrates the mapping of premium tiers to policy enrollments:

The above example maps to the following premium schedule:

Tier	Amount	Currency
Single	800.00	USD
Small Family	1,400.00	USD
Large Family	1,900.00	USD
Group	2,400.00	USD

A policy with 3 enrolled persons, a primary, a spouse and 1 child matches the premium schedule line for the 'Small Family' Tier. A premium of 1.400 USD is applied in this case. Let’s assume that the policy enrollment with enrollment type Primary is also the policy holder. The system assigns the premium of 1.400 USD to this policy enrollment product. It calculates no individual premium for the spouse and child.

Calculate Premium Amounts

At this point the system has established the applicable premium amount and if the policy enrollment product partially or fully overlaps with the calculation period. The next step is to determine how the premium amount maps to the calculation period segment. For example, if the premium amount applies over a full year, and the calculation period segment only spans a month, the premium amount needs to be reduced to the amount appropriate for the calculation period segment.

The rest of this section contains a high-over calculation logic. The next chapter in this guide describes the calculation and reconciliation process in detail.

There are five methods of calculations:

• Calculation period based (see Calculation Period Based for more information)

• Contract period based (see Contract Period Based for more information)

• Calendar year based (see Calendar Year Based for more information)

• Day based (see Day Based for more information)

• Policy Calculation Period (see Policy Calculation Period Based for more information)

Which of these methods the system applies depends on the three settings.

The first setting is the calculation period in context of the calculation period segment.

• policy calculation period
  This leads to the policy calculation period based method.

• system calculation period
  This leads to either calculation period based, contract year based, calendar year based or day based method.

The second is the amount interpretation setting on the premium schedule in combination with system calculation period in context. This tells the system whether the retrieved premium amount applies per:

• calculation period, regardless of how many days it spans
  This choice leads to the calculation period based method.

• specific number of days
  This choice leads to a day based method.

• or to a calendar year, i.e., the system can derive a daily rate
  This choice leads to either the contract or calendar year based method.

Note that if the calculation period in context is a policy calculation period, and the amount interpretation on the premium schedule is calculation period, the system raises the fatal message POL-FL-CAPR-16.

Code	Severity	Message Text
POL-FL-CAPR-016	Fatal	For policy calculation period \{start date} premium cannot be calculated as amount interpretation on the premium schedule \{premium schedule code} is set to calculation period

The third setting is whether the policy is on a contracted time period in combination with system calculation period. This tells the system whether it should calculate towards:

• a fixed premium rate for the full time span of the contracted period
  This choice leads to the contract period based method

• or to (possibly different) premium rates per calculation
  This choice leads to the calendar year based method

There are more settings (described in the next chapter) that have an impact on the calculation, depending on which method is applied.

Amount Distribution The amount distribution setting is relevant in the context of contract, calendar year, policy calculation period based methods. It provides the choice of whether the premium is evenly spread over the days or evenly spread over the calculation periods in the contracted period or calendar year. Distributing the premium over calculation periods has the administrative advantage that the charged premium is the same amount for every calculation period, even if not all calculation periods span the same number of days. For the contract based method it has the additional consequence that the system needs to reconcile premium in the last calculation period segment.

This setting can be specified on multiple levels: enrollment product, group account product, group account and group client. If the setting is found on multiple levels, the following priority is used to select the applicable setting:

1. Group Account Product

2. Group Account

3. Group Client

4. Parent Group Client (and further up the Group Client hierarchy)

5. Enrollment Product

If no amount distribution setting can be determined (when it is needed), the following error message is returned:

Code	Severity	Message Text
POL-FL-CAPR-012	Fatal	The amount distribution setting cannot be determined for policy enrollment product {code}

Partial Period Resolution

The partial period resolution setting is relevant in the calculation period based method. It specifies what the charge is for a partial period: per day, no charge, full period or enrolled days threshold. If the enrolled days threshold is specified then the charge is full period if the enrolled days threshold is met, else there is no charge. Note that if there is no charge, the system stops the evaluation of the policy enrollment product in context.

This setting can be specified on multiple levels: enrollment product, group account product, group account and group client. If the setting is found on multiple levels, the following priority is used to select the applicable setting:

1. Group Account Product

2. Group Account

3. Group Client

4. Parent Group Client (and further up the Group Client hierarchy)

5. Enrollment Product

If no partial period resolution setting can be determined (when it is needed), the following error message is returned:

Code	Severity	Message Text
POL-FL-CAPR-013	Fatal	The partial period resolution setting cannot be determined for policy enrollment product {code}

Reconciliation

Last Calculation Period Segement and Contract

For premium calculated using contract based method, the last calculation period segment is significant because it determines premium by reconciliation rather than calculation. If the retrieved premium applies per year and the policy is tied to a contracted period, the system uses the last calculation period segment to reconcile.

The system detects that calculation period segment is the last calculation period segment by the following logic:

• If the policy enrollment product ends before the end of the contract period, the last calculation period segment is the one during which the policy enrollment product ends.

• If the policy enrollment product does not end during the contract period, the last calculation period segment is the period that starts in the contract period and ends on or after the last day of the contract period.

If the system detects that the calculation period segment is the last and is in context of a system calculation period, it calculates the target total premium for the full enrolled period by deriving the daily rate and multiplying it by the number of enrolled days. Next, the system retrieves all past calculation results within the contracted period that belong to the same group account (or no group account) as the calculation period segment in context, to determine what has already been charged. Finally, the system determines the premium, adjustments and surcharges for the last calculation period segment, such that the aggregated result of all calculations in the contracted period equals the target premium amount.

Consider a yearly premium amount of 1,200.00 and suppose the calculation periods are calendar months, and the premium is evenly distributed over the months. This means the system calculates 1,200.00 / 12 months = 100.00 premium every month. The policy is on a calendar year contract.

The policy enrollment product starts on January 15th. For January, the system charges 54.84 (17 / 31 x 100) and for February and March, the system charges 100.00 which is according to the settings. However, some time after the calculation for March and before the calculation for April, the group account of the policy changes as on April 14th.

When the system starts the April calculation, it detects that this is (now) the last calculation period segment for the person or object. This means it evaluates the total number of enrolled days in the year. This amounts to 17 + 28 + 31 + 14 = 90 days. So actually, the premium for the enrolled period is 90 x 1,200 / 365 = 295.89. Because the system already charged 254.84 for January, February and March, it will charge 41.05 for April instead of 100.00.

Last Split Policy Calculation Period Segment

For premium calculated using policy calculation period based method, the last split of a policy calculation period is significant because it determines premium by reconciliation rather than calculation.

The system detects that split policy calculation period is the last when the policy calculation period end date is equal to the policy calculation period span end date

If the system detects that the policy calculation period is the last split, it calculates the target total premium for the full enrolled policy calculation period span given by the span start and end dates. Next, the system retrieves all past calculation results of the other splits that belong to the same policy calculation period span, to determine what has already been charged. Finally, the system determines the premium, adjustments and surcharges for the last split period segment, such that the aggregated result of all calculations in the policy calculation period span equals the target premium amount.

Whether reconciliation for a line will apply or not further dependents on the following:

• The retrieved value from the schedule: The system compares the retrieved value for the schedule definition for the previous calculation results that belong to the policy calculation periods within the span with the value retrieved for the current (split) policy calculation period. This value must be the same for all the (split) policy calculation periods in the span.

• The nature of the enrollment - full or partial over the policy calculation period span (without split), in combination with the schedule definition type:

  • Product Premium: The member must be enrolled over the full policy calculation period span on the product for the product premium to be reconciled.

  • Add-on Premium: The member must be enrolled for the full policy calculation period span on the add-on for the add-on premium to be reconciled.

  • Percentage based Adjustment: Depends on the scope of adjustment:

    • When the scope is a total premium, then the member must be enrolled for the full policy calculation period span on the product, and add-ons

    • When the scope is a specific add-on premium, then the member must be enrolled for the full policy calculation period span on the add-ons

    • When the scope is a specific product, then the member must be enrolled for the full policy calculation period span on the enrollment product

  • Amount based Adjustment: The member must be enrolled over the full policy calculation period span on the product for the adjustment to be reconciled.

  • Percentage based Surcharge: Depends on surcharge rule evaluation:

    • When a surcharge is on premium, then the member must be enrolled for the full policy calculation period span on the product and the add-ons.

    • When a surcharge is after adjustment, then surcharge reconciliation applies only if all the adjustments are reconciled by the system

  • Amount based Surcharge: The member must be enrolled over the full policy calculation period span on the product for the surcharge to be reconciled.

The following image shows typical combinations of settings and circumstances, and the corresponding calculation in context of a system calculation period:

The following image shows typical combinations of settings and circumstances, and the corresponding calculation in context of policy calculation period:

Calculate Add-on Premium

This section describes how the system determines premium for policy add-ons. The following image shows the steps and decision points for this part of the process.

Identify Add-ons

The first step is to list all the policy add-ons that apply. These are all the policy add-ons - for the enrollment product that is currently calculated - that overlap in time with the calculation period segment.

Determine Add-on Value

The next step is to determine the add-on’s premium value. The same add-on can have different premium values for different (group account) enrollment products or even within a (group account) enrollment product.

Per identified add-on, the system first tries to find the applicable add-on premium schedule. That is the add-on premium schedule that applies to the identified add-on and the enrollmentproduct time period applicable on the reference date. If the system cannot find the add-on premium schedule, it raises fatal message POL-FL-CAPR-005 (see Messages section below). The system ignores add-on premium schedules with a disabled schedule definition.

If the system finds the applicable add-on premium schedule, the next step is to find the applicable add-on premium schedule line within the selected add-on premium schedule based on value reference date. Steps to determine the value reference date and to select the applicable time periods per add-on schedule are similar to premium schedule value reference and time period selection steps.

The evaluation of the add-on premium schedule lines is identical to the evaluation of the premium schedule lines, except that the systerm uses the policy add-on start and end dates instead of the policy enrollment product start and end dates where applicable (for example when retrieving the appropriate time valid dynamic field values, and the reference date is not within the policy add-on time validity). The system accepts only one matching add-on premium schedule line. If the system finds more than one matching line, it raises fatal message POL-FL-CAPR-009 (see Messages section below). If the system does not find any matching line, it raises fatal message POL-FL-CAPR-005 (see Messages section below).

After the system has found the matching add-on premium schedule line, in case of a group account policy, it will check if there is an add-on override specified on the group account product level for the group account time period applicable on the value reference date. If so, it uses the value specified on the add-on override instead of the value specified on the add-on premium schedule line. Note that the system only considers override values when it identified an applicable group account time periods.

An add-on premium schedule line and a group account product add-on override specify an amount, a percentage or a dynamic logic function that calculates an amount. The system uses the amount (specified on the line/override or calculated by the dynamic logic function) or percentage to calculate the add-on premium (see below). Note that if the dynamic logic function returns an amount in a different currency than the premium currency specified on the enrollment product, the system ignores the selected add-on premium schedule line (it calculates no add-on premium).

Enrolled?

Policy add-ons have their own start and end date, which may not be aligned with the start and end date of the policy enrollment product. Therefore, the system evaluates add-on enrollment separately from the policy enrollment product. It is evaluated in the same way, so the person or object can be fully, partially, or not enrolled at all for a particular add-on.

Calculate Add-on Premium

At this point, the system has retrieved the applicable add-on premium value, and it also knows if the person or object was fully or partially enrolled. The next processing step translates the add-on premium value to the resulting premium for the calculated period segment. For example, the add-on premium amount could apply per year, while the calculated period is a calendar month.

The system uses the same amount distribution, amount interpretation and partial period resolution settings that have been used for the product premium calculation, to calculate the add-on premium amount for the calculation period segment. This calculation is the same as for the enrollment product. That means that if premium applies per year for a contracted policy, then the system also automatically reconciles the policy add-on premium, in the last calculation period segment (in context of a system calculation period), exactly as described for the policy enrollment product. The add-on premium value can either be an amount, or a percentage of the product premium (total premium of all premium schedules of the enrollment product) that has been determined in the previous steps.

Consider an enrollment product that has a premium schedule that applies 1,200.00 per year. In this case, an add-on value of 6% implies add-on premium of 72.00 yearly. On an enrollment product that has a premium schedule that applies 100.00 per calculation period, the add-on value of 6% is interpreted as an additional 6.00 per calculation period. Similarly, if the premium is 10.00 per week, add-on of 10% would imply add-on premium of 1.00 per week add-on premium of 1.00 per week_

The policy add-on has its own time effectiveness. This means the last calculation period segment for the policy add-on may not (also) be the last calculation period segment for the policy enrollment product in case of contract based method. It is possible that the system reconciles the premium (when calculating premium using contract based method) for a terminated policy add-on, while it applies the regular premium calculation for the policy enrollment product.

Messages

The following messages can occur in this step of the process:

Code	Severity	Message Text
POL-FL-CAPR-005	Fatal	Add-on value is not specified for the add-on \{add-on code}, for enrollment product \{enrollment product code} within the calculation period \{calculation period start date}
POL-FL-CAPR-009	Fatal	Multiple applicable add-on premium schedule lines for add-on \{add-on code} exist for policy enrollment product {code}

Calculate Surcharges on Premium

This section describes the calculation process for the surcharge that applies to the base premium, that is, the premium before any adjustments are applied. The following image shows the process steps.

Identify Surcharges

The first step identifies the surcharge schedule definitions that apply. These are all enabled schedule definitions of the type surcharge and with surcharge rule evaluation set to on premium. If a retrieved schedule definition has a schedule condition, then the system evaluates that condition to determine if the surcharge should be applied or not.

The system repeats the following steps in this section for each applicable surcharge schedule definition, that is for each surcharge type.

All surcharge rules apply to the base premium, so the sequence in which the system evaluates the surcharge types does not affect the calculation results.

Determine Surcharge Rule

The next step determines the applicable surcharge rule for the evaluated surcharge type.

For each surcharge types system computes the value reference date and the applicable time periods. Steps to determine the value reference date and to select the application time periods per surcharge type (schedule definition) are similar to premium schedule value reference and time period selection steps.

Only the surcharge rules for the applicable default time period and surcharge type are eligible for evaluation.

The evaluation of the eligible surcharge rules is identical to the evaluation of the premium schedule lines. The system matches the surcharge rules by comparing the values in the schedule dimensions to the data elements on the policy enrollment product. The system accepts only one matching surcharge rule (per surcharge type). If the system finds more than one matching rule, it logs a fatal message. During the evaluation the system ignores surcharge rules with amounts of any currency other than the premium currency, which is specified on the enrollment product.

Determine Surcharge Value

The surcharge value tells the system how much surcharge it has to add to the premium (or to deduct if the value is negative). It is expressed as either a nominal amount or as a percentage of the base premium. The base premium is the aggregated premium for the enrollment product and all applicable add-ons. If the surcharge type specifies a 'scoped on' premium schedule type, then it only applies if a premium schedule of the specified type has been applied.

The system uses the surcharge value that is attached to the matched surcharge rule.

Enrolled?

The surcharge calculation depends on whether the person or object is fully or partially enrolled with the policy enrollment product. If the person or object was partially enrolled, the system calculates the surcharge amount based on the applicable calculation method.

Calculate Surcharge Amount

At this point, the system has retrieved the applicable surcharge value, and it also knows if the person or object was fully or partially enrolled. The next step is to translate the surcharge value to the resulting surcharge amount for the calculation period segment.

If the surcharge value is an amount, the system uses the same amount distribution, amount interpretation and partial period resolution settings that have been used for the product premium calculation to calculate the surcharge amount for the calculation period segment.

In case a percentage applies instead of an amount, then the premium schedule amount interpretation determines the next steps.

Amount Interpretation: Calculation period

The system applies the percentage surcharge value directly on the base premium of the calculation period segment (applicable only in context of a system calculation period).

Amount Interpretation: Calendar Year

The system applies the percentage surcharge value directly on the base premium of the calculation period segment, except when last period reconciliation is applicable. Last period reconciliation is applicable for the last calculation period segment in case of contracted policy and for the last split of a policy calculation periods.

For reconciliation the system calculates applicable surcharge amount. This calculation is identical to the calculation of the add-on premium amount except that the the system calculates the surcharge amount using the base premium amount that has been determined in the previous steps.

Consider an enrollment product that has a premium schedule that applies 1,200.00 per year and an add-on premium schedule that applies an additional 10%. This means that a base premium of 1,320.00 is applicable yearly. A surcharge value of 5% implies that a total surcharge amount of 66.00 applies per year and is considered as an input to calculate the surcharge amount for the calculation period segment.

Amount Interpretation: Specific Year

The system applies the percentage surcharge value directly on the base premium of the calculation period segment, except when last period reconciliation is applicable. For amount interpretation specific last period reconciliation is applicable for the last split of a policy calculation period. In this case the system calcualtes the surcharge amount for the specific number of days and is then prorated to find the applicable amount for the policy calculation period span, this is then the applicable surcharge amount for the policy calculation period for the reconciliation purpose.

Consider an enrollment with 8% surcharge on premium $45.43 with specific days setting set to 7 days. If the policy calculation periods are weekly then the applicable amount as input for reconciliation is 8% of $45.43. Surcharge amount per week (unrounded) = 3.6344.

If the calculation is using monthly policy calculation periods and premium distribution is evenly, then the applicable amount for the full monthly span as per policy calculation period based method will be $15.97. This amount is used as the target total surcharge to be charged.

Messages

The following messages can occur in this step of the process:

Code	Severity	Message Text
POL-FL-CAPR-006	Fatal	Multiple applicable surcharge rules for the \{surcharge type} exist for policy enrollment product {code}

If no applicable surcharge rule exists in a retrieved surcharge schedule and the schedule definition has 'Indicator Fatal If Not Found' set to Yes, the system raised the following fatal message.

Code	Severity	Message Text
POL-FL-CAPR-021	Fatal	Surcharge rule is not specified for the \{surcharge type}, within the calculation period \{calculation period start date}.

Calculate Adjustments

This section describes the calculation process for the adjustments. Adjustments can be defined at 2 levels: enrollment product and group (group client, group account and group account product). For policies based on a group account, the system applies both types of adjustments and both are based on the base premium. The following image shows the process steps:

Determine Adjustments

The first step identifies the adjustment types, and the order in which they apply. Adjustment types only apply if they have been linked to the policy enrollment product through the set up of assigned adjustments. If the adjustment type specifies a 'scoped on' premium schedule type, then it only applies if a premium schedule of the specified type has been applied. If the adjustment type specifies a 'scoped on' add-on, then it only applies if the specified add-on has been applied.

The system always (both for individual policies and group account policies) considers the assigned adjustments set up under the enrollment product that are effective on the reference date. For group account policies, the system also considers the assigned adjustments set up under the group account product, group account and/or group client that are effective on the reference date; the system then applies these adjustments together with the assigned adjustments set up under the enrollment product. Note that the system considers the group hierarchy in the context of a calculation period segment group account.

Group adjustments can be assigned on multiple levels: group account product, group account or group client. If the system finds group adjustments for a policy enrollment product on multiple levels, it uses the following priority to select the applicable adjustments:

• Group Account Product

• Group Account

  • In the context of a specific Enrollment Product Category (assigned adjustment with a specified Enrollment Product Category)

  • For all enrollment products (assigned premium schedule without a specified Enrollment Product Category)

• Group Client

  • In the context of a specific Enrollment Product (assigned adjustment with a specified Enrollment Product)

  • In the context of a specific Enrollment Product Category (assigned adjustment with a specified Enrollment Product Category)

  • For all enrollment products (assigned adjustment without a specified Enrollment Product or Enrollment Product Category)

• Parent Group Client (and further up the Group Client hierarchy): same sub levels apply as specified for the Group Client level

The system only selects the group adjustments of the most specific level. For adjustments that are assigned to a group account or a group client, the system only selects the adjustments of the most specific sub level. So if for example on a group client has both an assigned adjustment with a specified enrollment product, and an assigned adjustment without a specified enrollment product or enrollment product category, only one of those will be applied depending on the policy enrollment product.

If a retrieved adjustment type (schedule definition) has a schedule condition, then the system evaluates that condition to determine if the adjustment should be applied or not.

An assigned adjustment always specifies a sequence number. This sequence number determines in which order the system applies the adjustment types to the calculated premium, in case there is more than one applicable adjustment type. The order matters because adjustment values can be nominal amounts as well as percentages of the base premium and in some cases as dynamic logic functions which calculates the amount.

Lower sequence numbers apply before higher sequence numbers, for example an adjustment type with sequence "1" applies before an adjustment type with sequence "2". This means that the calculation of the adjustment type with sequence "2" is based on the premium remains after the adjustment type with sequence "1" has been applied. This is especially relevant if the adjustment type with sequence "2" is specified as a percentage.

The system apllies adjustment types that have the same sequence number simultaneously. They ignore each others calculations, and the system aggregates and applies the calculated adjustment amounts at the same time.

Note that if the system applies adjustments and group adjustments on a policy enrollment product, the ordering as specified above applies across the two levels (so for example an adjustment with sequence 2 will be applied after a group adjustment with sequence 1, but before a group adjustment with sequence 3).

Determine Adjustment Rule

The system repeats the following steps per adjustment type.

The next step determines the applicable value reference date and the time periods for the adjustment type. Steps to determine the value reference date and to select the applicable time periods per adjustment type (schedule definition) are similar to premium schedule value reference and time period selection steps. Only adjustment rules that apply to the determined default time period for a adjustment type are eligible for evaluation.

The evaluation of the eligible adjustment rules is identical to the evaluation of the premium schedule lines. The system matches the adjustment rules by comparing the values in the schedule dimensions to the data elements on the policy enrollment product. The system accepts only one matching adjustment rule (per adjustment type). If the system finds more than one matching rule, it logs a fatal message. During the evaluation, the system ignores adjustment rules with amounts for any other currency than the premium currency. This does not apply to adjustment rules where the value is specified in the context of the enrollment product or the account product as these will always be either specified in the premium’s currency or as a percentage.

Determine Adjustment Value

The adjustment value tells the system how much adjustment to subtract from the premium (or add to it if the value is positive). It is expressed as either a nominal amount, a percentage on the base premium or a dynamic logic function which calculates the amount. The result of the dynamic logic function can be prorated when partial calculation periods apply. This depends on the configuration of the adjustment rule where the dynamic logic function is defined as prorated or not prorated.

The base premium for an adjustment depends on the scope defined in the schedule definition. This can be either:

• the total aggregated premium for the enrollment product or group account product and all applicable add-ons (including adjustments of lower sequences)

• the enrollment product or group account product premium only (including adjustments of lower sequences that are applied on the product premium)

  • if a specific 'scoped on' premium schedule type is specified on the adjustment type then only the premium and adjustments of that product component (premium schedule of the specific type) are taken into account instead of the premium and adjustments of all product components (premium schedules)

• the add-on(s) premium only (including adjustments of lower sequences that are applied on the add-on(s) premium)

  • if a specific 'scoped on' add-on is specified on the adjustment type then only the premium and adjustments of that add-on are taken into account instead of the premium and adjustments of all add-ons

The system uses the adjustment value that is attached to the matching adjustment rule. If an overriding value (in context of applicable enrollment /group account time periods) is specified on the enrollment product or group account product,then the system uses that value instead of the default value. Note that the system only considers override values when it identifies applicable enrollment or group account time periods.

Enrolled?

The adjustment calculation depends on whether the person or object is fully or partially enrolled with the policy enrollment product. If the person or object is partially enrolled, the system calculates the adjustment amount based on the applicable calculation method.

Calculate Adjustment Amount

At this point, the system has retrieved the applicable adjustment value, and it also knows if the person or object was fully or partially enrolled. The next processing step translates the adjustment value to the adjustment amount that applies to the calculated period segment. For example, the adjustment value could apply per year, while the calculated period is a calendar month.

If the adjustment value is an amount, the system uses the same amount distribution, amount interpretation and partial period resolution settings that have been used for the product premium calculation to calculate the adjustment amount for the calculation period segment. In case a percentage applies instead of an amount, the calculation of adjustment is identical to the calculation of the surcharge.

Messages

The following messages can occur in this step of the process:

Code	Severity	Message Text
POL-FL-CAPR-007	Fatal	Multiple applicable adjustment rules for the \{adjustment type} exist for policy enrollment product {code}

If no applicable adjustment rule exists in a retrieved adjustment schedule, and the schedule definition has 'Indicator Fatal If Not Found' set to Yes, the system raises the following fatal message.

Code	Severity	Message Text
POL-FL-CAPR-022	Fatal	Adjustment rule is not specified for the \{adjustment type} for member \{member code} and enrollment product \{enrollment product code} within the calculation period \{calculation period start date}.

Calculate Surcharges - After Adjustment

This section explains the calculation processes for the post adjustment surcharges. The steps to calculate the surcharge amount are identical to the steps described in the section "Calculate Surcharges" with two differences.

1. In this step of the process, the system evaluates only enabled surcharge schedule definition with surcharge rule evaluation set to after adjustment.

2. In this step of the process, the system calcualtes surcharge values that are specified as a percentage using the premium including the adjustments rather than the base premium amount.

Calculate Commissions

Calculating commission is an integrated part of the premium calculation. It cannot be started separately. However, premium calculation only calculates commissions when the system property to calculate commissions is set to 'true'. For more details on system properties please see System Properties.

For a detailed description of commission calculation please see Calculate Commission.

Write Calculation Results

This is the last step of the calculate premium per policy activity which creates a new calculation result record and financial transaction after executing all the preceding steps. The system repeats this step per verified calculation period segment.

Note that if there exists a calculation result with contract period and/or group account or neither as the verified calculation period segment in context, then the system creates no new calculation result record; instead the system adds all the calculation result lines of the verified segment to the existing calculation result.

The calculation result record is a snapshot of the premium calculation end results. It stores the outcome of a premium calculation within the context of a single policy and calculation period segment.

The calculation result lines created during the calculation process - for premium, policy based premium, surcharges and adjustments and commission - are all linked to the calculation result record.

Calculation Result Record

A calculation result record stores the following information:

Fields	Description
Total Base Premium	Sum of the enrollment product premium schedules and add-ons premium amounts
Total Base Premium Currency	The currency of the total base premium (picked up from the calculation result lines)
Total Adjustment	Sum of the adjustment amounts
Total Adjustment Currency	The currency of the total adjustment (picked up from the calculation result lines)
Total Surcharge	Sum of the surcharge amounts
Total Surcharge Currency	The currency of the total surcharge (picked up from the calculation result lines)
Total Result	Total result (total base premium + total surcharge total adjustment)
Total Result Currency	The currency of the total result (picked up from the calculation result lines)
Total Commission	Sum of the commission amounts
Total Commission Currency	The currency of the total commission (picked up from the commission result lines)
Version	The version of the premium calculation. The version number is incremented with each recalculation for the same policy and same calculation period.
Policy	The policy version to which this calculation result applies
Reversal Policy	The policy version in which this calculation result is reversed
Calculation Period Start Date	The start date of the calculation period to which the calculation result applies
Calculation Period Start Date	The end date of the calculation period to which the calculation result applies
Reference Date	The reference date (contract or calculation period) which is used to determine the assignments
Contract Period Start Date	The start date of the policy contract period to which calculation result applies
Group Account	The group account the policy belongs for which calculation result is created
Calculation Date	The collection cycle date computed by extrapolation of the span reference date For system calculation period the span reference date is the date from which the system extrapolates the advance periods. It stores this extrapolated span reference date on each calculation results that belong to a single cycle as calculation date. When no collection setting is specified, it is the system period start date.
Pay Date	The calculation date of the policy calculation period
Dynamic Fields	For policy calculation periods: The value of a dynamic field on the policy calculation period is copied to a dynamic field on the calculation result that has the same usage name as the dynamic field on the policy calculation period.

Calculation Result Line Record

The system stores the result of each calculation step (premium, surcharge, adjustment) in a calculation result line record. This record keeps track of both the input amounts and settings as well as the outcome. For distributed surcharges, instead of creating one calculation result line for the total surcharge, the system creates a separate surcharge calculation result line for every applicable component (product premium schedule, add-on and adjustment) with a reference to the calculation result line of that component.

A calculation result line record stores the following information:

Fields	Description
Policy Enrollment Product	The policy enrollment product that was the subject of the calculation
Type	The type of the calculation result line (premium, policy based premium, add-on premium, adjustment, group adjustment or surcharge)
Schedule Definition	The premium schedule definition, add-on premium schedule definition, adjustment type, group adjustment type or surcharge type that was evaluated
Premium Schedule	The premium schedule that was the subject of the calculation
Premium Schedule Line	The premium schedule line that was the subject of the calculation
Adjustment Rule	The adjustment rule that was applied
Add-on	The add-on that was the subject of the calculation
Add-on Premium Schedule Line	The add-on premium schedule line that was the subject of the calculation
Start Date
End Date	The time span within the calculation period segment during which the policy enrollment product (or add-on) is effective
Sequence	Specifies the order in which the steps have been applied. Especially relevant for adjustment types, for which the order is configurable.
Calculation Result Line	The calculation result line that this calculation result line is created for when a surcharge is distributed across the applicable components
Amount Distribution	Stores the distribution setting value that was applied in the calculation
Amount Interpretation	Stores the interpretation setting value that was applied in the calculation
Partial Period Resolution	Stores the resolution setting value that was applied in the calculation
Enrolled Days	The number of enrolled days in the calculation period (only specified for a partial period enrollment)
Total Days	The total number of days in the calculation period or calendar year (only specified for a partial period enrollment)
Retrieved Amount	Stores the amount that was retrieved (or calculated by a dynamic logic function) from the premium schedule line, (overriding) adjustment value, add-on premium schedule line or group account product overriding add-on.
Retrieved Amount Currency	The currency of the retrieved amount (picked up from the related enrollment product)
Percentage	Stores the percentage that was retrieved from the (overriding) adjustment value, add-on premium schedule line or group account product overriding add-on
Input Amount	The aggregated result of all preceding calculation steps that was the starting point for the calculation represented by this calculation result line.
Input Amount Currency	The currency of the input amount (picked up from the related enrollment product)
Result Amount	The delta amount that was the result of the calculation step represented by this calculation result line
Result Amount Currency	The currency of the result amount (picked up from the related enrollment product)

Commission Result Line Record

The system stores the result of the commission calculation step in a commission result line record. This record keeps track of both the input amounts and settings as well as the outcome. A commission result line record stores the following information:

Fields	Description
Policy Enrollment Product	The policy enrollment product that was the subject of the calculation
Broker	The applicable broker
Agent	The applicable agent
Third Party	The relation that gets the commission when broker agent switch rule specifies 'Third Party' for existing or new enrollments
Sequence	Specifies the calculation order
Percentage	Stores the percentage that was retrieved from the policy enrollment product or group commission rate configuration
Retrieved Amount	The configured amount on the group commission rates or policy enrollment product
Retrieved Amount Currency	The currency of the retrieved amount
Input Amount	The computed base amount for the calculation for this commission result line on which percentage commission is applied (for percentage commission)
Input Amount Currency	The currency of the input amount (picked up from the related enrollment product)
Commission Amount	The computed amount that was the result of the calculation step represented by this commission result line
Commission Amount Currency	The currency of the commission amount (picked up from the related enrollment product)
Start Date	The start and end date of the commission period

Rounding

The scale of the calculation results (the maximum number of decimals allowed) in the database restricts how accurate these money data can be stored. More scale allows for more preciseness on a detail level (e.g. VAT on a premium for a member); this way a downstream system could do final rounding only after aggregation (e.g. on a group account).

All amount columns in calculation results, (except retrieved amount) calculation result lines and commission result lines allow for 12 decimals. A system property can be set to specify the number to which each of the number(22,12) columns will be rounded: default is 2, maximum is 12. For example, a value of 0.123456789012 with the system property for rounding set to 4 will result in a value of 0.1235 (identical to 0.123500000000) written to the database.

Discarding Policy Mutations

After the system has stored the calculation results, it removes all the policy mutations considered in the premium run.

The system discards all policy mutation records that were present at the start of the activity if there are no future calculation period with any calculation period segments to be recalculated. This includes policy mutations that take effect on a date that lies further into the past than the specified look back date.

Create Financial Transactions

The calculation results are converted to data structures in the financial subsystem to generate invoices and accounting data. These data structures are referred to as 'Financial Transactions'.

The financial transaction represents the calculation outcome for the calculation period segment and policy. For every calculation result that the system creates, it also creates corresponding premium and commission financial transactions. Financial transactions for premium reside under the base financial object of type Premium; financial transactions for commissions reside under the base financial object of type Premium Based Commission (for an explanation of the data structure, refer to the the Financial Implementation Guide).

A financial transaction has financial transaction detail(s). These financial transaction details correspond to the calculation result lines for the premium financial transaction and to the commission result lines for the commission financial transaction. If reinsurance applies, additional payable financial transaction details are created for those receivable financial transaction details specified in the reinsurance settings.

For premium financial transactions, the system determines per calculation result line how many financial transaction details have to be created and who the bill receiver is for every financial transaction detail (that is, to what the counterparty code on the financial transaction detail process data is set). This is done based on premium bill allocations that are valid on the reference date ^[3]. These allocations can be specified on the policy and/or on the group client(s) related to the policy. Premium bill allocations are defined as a combination of the following dimensions: group account (only for allocations in the context of group clients), premium schedule type, add-on, schedule definition, enrollment product, enrollment product category and insurable class. None of these dimensions is required. If a dimension is specified, it needs to match the context of the calculation result line. So if for example an enrollment product and an add-on are specified on the allocation, that allocation will only apply to calculation result lines for that specific add-on in the context of that specific enrollment product.

Multiple allocations can be defined per group client and/or policy. If applicable allocations are found on multiple levels for a calculation result line, the following priority is used to select the applicable level:

1. Policy

2. Group Client

3. Parent Group Client (and further up the Group Client hierarchy)

If multiple applicable allocations are found on the selected level, the most specific allocation is selected based on the weight of the dimensions:

1. Group Account (can only be specified on allocations in the context of a group client)

2. Premium Schedule Type or Add-on

3. Schedule Definition

4. Enrollment Product

5. Enrollment Product Category

6. Insurable Class

The insurable class dimension has the lowest weight, the enrollment product category dimension has double the weight of the insurable class dimension and so on. The allocation with the highest total weight is selected. So if for example two allocations exist that match the context of the calculation result line, where the first allocation has a specified group account and an enrollment product and the second allocation has a specified group account and an insurable class, the first allocation will be selected because it has the highest total weight.

After the applicable allocation is selected, a separate financial transaction detail is created per bill receiver assigned to the selected allocation for the applicable percentage of the amount. So for example if there are five calculation result lines for which an allocation applies and two bill receivers under that allocation (for example policyholder and group account), ten financial transaction details will be created.

If no premium bill allocation is selected, one single financial transaction detail is created for the calculation result line. For individual policies if a default billing account is specified on the policy, that billing account will be the bill receiver (counterparty code on the financial transaction detail’s process data is set to the billing account code). For group account policies, if a default billing account is specified on the group client of the group account, that billing account will be the bill receiver (counterparty code on the financial transaction detail’s process data is set to the billing account code). If no default billing account is configured, the counterparty code will not automatically be set by the system.

The system creates premium and commission financial transactions with zero amount and no financial transaction details for the calculation results that are flagged for financial reversal in the 'Reverse Future Results' and 'Verify Calculation Period Segments' steps. The system also creates commission financial transactions with zero amount and no financial transaction details when commission result line(s) exist for past calculation period, but no commission result line is created in the current calculation period segment. _This situation can occur, for example, when the assigned broker agent is end-dated or if the commission percentages/amounts are removed retroactively. _

The premium financial transaction can be customized by the 'Premium Financial Transaction' dynamic logic function. This function is executed per calculation result for a policy. The mapping of the fields between calculation result lines and financial transaction details can also be customized by it. Similarly, 'Commission Financial Transaction' dynamic logic function can be used to customized commission financial transaction.

For premiums and commissions, if the calculation period segment is the subject of recalculation, then the system creates a reversal financial transaction which is the reversal of the financial transaction corresponding to the version previous to the latest recalculated version of the calculation result. The system also creates reversal financial transaction of the financial transaction corresponding to the latest calculation result version for the calculation results that are reversed in the 'Reverse Future Results' and 'Verify Calculation Periods' steps. The reversal financial transaction inherits values from the original financial transaction that it represents and therefore, no dynamic logic function is executed during its creation.

Note that the amount columns (total amount in Financial Transaction and amount in Financial Transaction Detail) allow for the same scale as the calculation amounts - number(22,12) - and follow the rounding that has been applied to the calculation amounts (as described in the previous section).

The financial transactions are further processed in the financial sub system to generate Financial Message(s) for the financial application connector that is being used. More information on the financial transaction and financial processing can be found in the guide for financial.

---

1. The system picks up other group accounts for calculations even though a group account is specified as parameter when multiple group accounts are encountered with a single calculation period which is found to be eligible for (re)calculation.

3. A premium bill allocation is considered valid if the reference date is on or between the bill allocation’s start- and end date and the allocation is active.