Generate Policy Calculation Periods

The Generate Policy Calculation Periods activity is started by the user. This is the only activity that is started by a user; all other activities in this chapter are automatically started by the system itself. The user can control the scope of the policy calculation period generation by selecting values for the following parameters:

Name Description

Brand

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

Group Client

If specified, the policy calculation period generation only picks up policies for the group accounts in the group client [1]. If not, then policy calculation period generation picks up policies from any account.

Group Account [2]

If specified, the policy calculation period generation only picks up policies for that group account. If not, then the policy calculation period generation picks up policies from any account. If unspecified is selected, the policy calculation period generation only picks up individual policies (group client parameter is left empty).

Generate Up To Date

This mandatory attribute specifies the date up to which the policy calculation periods are going to be generated. If advance period and UoM settings are applicable, then the system may generate periods beyond the generate up to date. This is to ensure that periods that belong to a collection cycle are generated together.

Replace From Date

Specifies the date from which the existing policy calculation periods are to be replaced.

Look Back Date [3]

Mandatory. The collection setting that ends before the look back date is not considered for the policy period generation

The purpose of this activity is to split up the policy calculation period generation load over each combination of brand and group account. Within the context of splitting up the load, individual policies are treated as a separate group account (under group account unspecified).

This activity starts one new Generate Policy Calculation Periods per Group account activity for each distinct combination of brand and group account.

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 policy calculation periods generation 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 policy calculation periods generation 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-GPCP-001

Fatal

Brand code {code} is unknown

POL-VL-GPCP-002

Fatal

Group client code {code} is unknown

POL-VL-GPCP-003

Fatal

Group account code {code} is unknown

POL-VL-GPCP-004

Fatal

Segment function dynamic logic code {code} is unknown or has an invalid signature

Generate Policy Calculation Periods per Group Account

This activity type is started by the Generate Policy Calculation Periods activity. The Generate Policy Calculation Periods per Group Account cannot be started directly by the user, although starting the Generate Policy Calculation Periods for a specific group account and brand has the same effect. This activity inherits all the parameters from the Generate Policy Calculation Periods activity.

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

  • belong to the group account, or - if the group account parameter has the value unspecified - have no group account are considered.

    • a policy belongs to a group account if the policy group account relation has not ended before the look-back date

  • have a policy enrollment product that has not ended before the look back date

Generate Policy Calculation Periods per Policy

Each "Generate Policy Calculation Periods per Group Account" activity creates one or more "Generate Policy Calculation Periods per Policy" activities. The following image shows the process steps in this activity:

Generate Policy Calculation Periods per Policy

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

Determine Collection Settings

As a first step the system identifies the applicable collection settings for a policy. The collection setting can be specified on multiple levels: policy, group account or group client. A policy can be associated with multiple group accounts during different time frames. If multiple group accounts are found and/or collection settings on multiple levels for a policy are found then the system identifies the applicable collection settings with their effective time spans.

The system selects group account relationships (when applicable) that have not ended before the look back date and for each relationship it selects the collection settings that have not ended before the look back date by applying the following priority.

  1. Policy

    • If no group account relationships are identified, then only policy level collection settings that have not ended before the look back date are considered

  2. Group Account

  3. Group Client

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

After the system identifies the collection settings, it determines their logical effective time spans. Each collection setting in the set is logically end dated a day before the setting on a more specific level becomes effective. The collecting settings on the group client or group account (not on the policy level) are also bounded by the start and end dates of the group account relationship.

This algorithm flattens all collection settings in the group hierarchy into a single (virtual) time line of applicable collection settings. Consider the following examples.

Example 1: Suppose the collection settings are configured as below.

Level Collection Setting Start Date End Date

Group Client ORCL

Setting A

1-Jan-2018

31-Dec-2018

Group Account ORCL Active

Setting B

1-April-2018

Policy

Setting C

1-Oct-2018

31-Dec-2018

Policy

Setting D

1-Jan-2019

A policy is linked to group account ORCL Active from 1-Jan-2018 and the activity is started with a look back date set as 1-Jan-2018. In this case the applicable collection settings (in context of the policy) with their effective start and end dates are:

Collection Setting Start Date End Date Description

Setting A

1-Jan-2018

31-March-2018

The Setting A is logically end dated as a specific level setting Setting B starts from 1-April-2018

Setting B

1-April-2018

30-Sep-2018

The Setting B is logically end dated as a specific level setting Setting C starts from 1-Oct-2018

Setting C

1-Oct-2018

31-Dec-2018

Setting D

1-Jan-2019

Example 2: Suppose the collection settings are configured as below.

Level Collection Setting Start Date End Date

Group Client ORCL

Setting A

1-Jan-2018

31-Dec-2018

Group Account ORCL Active

Setting B

1-April-2018

Policy

Setting C

1-Jan-2019

If Policy Group Account (ORCL ACTIVE) relationship starts on 1-Feb-2018 instead of 1-Jan-2018 as in the previous example and ends on 31-Dec-2018; policy is an individual policy from 1-Jan-2019 onward. The look back date is set as 1-Jan-2018. The applicable collection settings are:

Collection Setting Start Date End Date Description

Setting A

1-Feb-2018

31-March-2018

The Setting A starts on the start date of the group account relationship as the group account relationship start date is after the collection setting start date

Setting B

1-April-2018

31-Dec-2018

Setting C

1-Jan-2019

Alternatively, if Policy Group Account (ORCL ACTIVE) relationship starts on 1-May-2018 (instead of 1-Feb-2018 as in the previous use case), the applicable collection settings are:

Collection Setting Start Date End Date Description

Setting B

1-May-2018

31-Dec-2018

Setting A is not applicable as it logically ends before the group account relationship start date.

The logical start date of the Setting B is bounded by the start date of the group account relationship

Setting C

1-Jan-2019

Example 3: Suppose the collection settings are configured as below.

Level Collection Setting Collection Setting
Start Date
Collection Setting
End Date

Group Client ORCL

Setting A

1-Jan-2018

31-Dec-2018

Group Account ORCL Active

Setting B

1-April-2018

Group Account ORCL Retire

Setting C

1-Jan-2018

Policy

Setting D

1-June-2019

Policy Group Account (ORCL ACTIVE) relationship starts on 1-May-2018 and it ends on 31-Dec-2018; Policy is moved to another group account ORCL Retire from 1-Jan-2019 onward. The applicable collection settings in context of the policy with their effective start and end dates when the look back date is 1-Jan-2018 are:

Collection Setting Start Date End Date Description

Setting B

1-May-2018

31-Dec-2018

The policy group account relationship ends on 31-Dec-2018, therefore the Setting B is logically end dated on 31-Dec-2018

Setting C

1-Jan-2019

30-May-2019

The policy group account relationship starts on 1-Jan-2019, therefore the logical start date of the collection setting C is 1-Jan-2019

Setting D

1-June-2019

If the look back date is set to 1-Jan-2019, then the applicable collection settings are:

Collection Setting Start Date End Date Description

Setting C

1-Jan-2019

30-May-2019

The policy group account relationship ORCL Active is not selected as it ends before the look back date

Setting D

1-June-2019

Example 4: Suppose the collection settings are configured as below.

Level Collection Setting Collection Setting
Start Date
Collection Setting
End Date

Group Client ORCL

Setting A

1-Jan-2018

31-Dec-2018

Group Account ORCL Active

Setting B

1-April-2018

Group Account ORCL Retire

Setting C

1-June-2018

Policy

Setting D

1-Jan-2019

30-May-2019

Policy

Setting E

1-June-2019

Policy Group Account (ORCL ACTIVE) relationship starts on 1-May-2018 and ends on 31-Dec-2018; policy is moved to another group account ORCL Retire from 1-Jan-2019 onward. The applicable collection settings when the look back date is set as 1-Jan-2018 are:

Collection Setting Start Date End Date Description

Setting B

1-May-2018

31-Dec-2018

Setting D

1-Jan-2019

30-May-2019

Setting C is not applicable as there is setting Setting D on a specific level (policy).

Setting E

1-June-2019

When the look back date is set as 1-Dec-2018, the applicable collection settings are:

Collection Setting Start Date End Date Description

Setting B

1-May-2018

31-Dec-2018

The group account relationship and Setting B have not ended before the look back date.

Setting D

1-Jan-2019

30-May-2019

Setting E

1-June-2019

When the look back date is set as 1-Jan-2019, the applicable collection settings are:

Collection Setting Start Date End Date Description

Setting D

1-Jan-2019

30-May-2019

Setting B logically ends before the look back date (as the group account relationship ORCL Active ends before the look back date) and is therefore not considered.

Setting E

1-June-2019

Verify Policy for Policy Calculation Period Generation

The policy is excluded for the next steps if:

  • There is no collection setting (as identified in the previous set) with the indicator policy calculation period set to 'Yes' and no replace from date is specified * There is no collection setting (as identified in the previous set) with the indicator policy calculation period set to 'Yes' and there are no policy calculation periods to be replaced from the replace from date onward.

Replace Policy Calculation Periods

The activity has a replace from date parameter. This parameter can be used as a correction functionality to replace previously created policy calculation periods. When used the activity deletes the existing policy calculation periods with end dates on or after replace from date. The next step will then generate new policy calculation periods to replace the incorrect policy calculation periods if appropriate setting are specified.

If the system property indicates that the registrations should be applied to the periods and the replace from date is on or before the Date Paid To then the process replaces periods from the Date Paid To plus one.

Generate Policy Calculation Periods

The step does the following actions:

  1. Complete the previous collection setting time spans that have the indicator policy calculation period set to 'Yes' and have ended before the generate up to date. Generate policy calculation periods for the collection setting time spans that have the indicator policy calculation period set to 'Yes' and that include the generate up to date

Complete previous collection setting time spans

If there are previous collection settings with the indicator policy calculation period set to 'Yes', applicable to the policy (collection settings where the end date is before the generation up to date), the system checks if policy calculation periods are present up to the end date of the time validity of the collection setting. If this is not the case, the activity generates policy calculation periods for this policy up to the end of the collection setting time validity, possibly cutting the last policy calculation period short to the end date of the collection setting.

Generate policy calculation periods for current collection setting

For policies with a collection setting that has no end date or an end date after the generate up to date, the activity generates policy calculation periods.

Period Generation

The first step in generating policy calculation periods is to determine from which point forward new policy calculation periods have to be generated. This could be: . The start date of the collection setting. This is true for collection settings that don’t have any policy calculation periods yet. . The end date of the last policy calculation period for the policy within the time boundary of the collection setting

The timeline (start date & end date) for policy calculation periods generation is controlled by settings on the collection setting:

  • Span Reference Date
    The span reference date setting identifies the start of the first collection cycle and thus the first policy calculation period generation. The first policy calculation period of all subsequent cycles is determined based on an extrapolation of this date. For example if the Span Reference Date is set to 12-May-2019, the start date of the first generated policy calculation period is set to 12-May-2019. If span reference date is not specified, then the collection setting start date is taken as the span reference date.

  • Calculation Period Length & Calculation Period UoM
    These two attributes are always evaluated together. For example if these settings are set to 7 days, Policy Calculation Periods are generated with a time span of 7 days. When not specified, system defaults to 1 month.

  • Advance Length & Advance UoM
    These settings control up until which date policy calculation periods are generated. For example if the advance settings define 70 days, the system generates policy calculation periods that cover the a period of time of 70 days starting from the span reference date. All the policy calculation periods that start in this time frame are part of a collection cycle and these advance periods are expected to be calculated together by the premium calculation process. The other attributes of a policy calculation period get a default value during generation. While setting the defaults the system also takes into account the various offsets as specified by the collection method (if it exists) linked to the collection setting

  • Calculation Date

    • This date determines which policy calculation periods are part of a single collection cycle. Collection cycle time frame is determined based on the setting Advance Length and Advance UoM. Attribute calculation date offset on the collection method is also taken into account while setting this value. For the periods that are part of the first cycle (of the collecting setting), this date is set to the span reference date offset by the number of days as specified by the calculation date offset setting on the collection method. Calculation date for the policy periods that are part of the subsequent cycles is determined based on an extrapolation of the date as given by the span reference date plus the offset(see examples below).

  • Pay Date is set to the value as given by offsetting the extrapolated span reference date (applicable for the period) with the value as specified by the pay date offset setting on the collection method. Policy calculation periods that are part of a single collection cycle have the same pay date.

  • Reference Date is set to the value as given by offsetting the start date of the policy calculation period with the value as specified by the reference date offset setting on the collection method

  • Days

    • When the calculation period UoM setting is Month then:

      • For a policy with contract the days factor is computed as 365/12 multiplied by the calculation period length unless the policy calculation period starts in the contract period that includes Feb 29, in which case it is calculated as 366/12 multiplied by the calculation period length

      • For a policy without contract the days factor is computed as 365/12 multiplied by the calculation period length unless the policy calculation period starts in an annual period as set out from the leap year start month (system property) that includes Feb 29, in which case its 366/12 multiplied by the calculation period length. If the system property is not specified the days factor is computed as 365/12

    • Otherwise it is set to the number of days in the policy calculation period

  • Policy calculation period span start date and end dates are set to policy calculation period start and end date before any split a) by system or b) by segmentation dynamic logic.

More Advanced Periods

After the periods are generated up to the 'generate up to date', including all the advanced periods based on advanced period and UoM settings, the system may still have to generate more periods.

The system continues the policy calculation period generation till the generate up to date continues to be on or before that the calculation date (including more periods that belong to the collection cycle as the last period where this check is still true).

Period generation invoked in context of premium calculation

Premium calculation may specify the billing cycle for period generation. Setting billing cycle influences the dates for premium calculation for the past periods. The past periods could either be calculated in the current premium calculation process (Immediate Billing) or with the next billing cycle (Forward Billing).

Immediate Billing

When the billing cycle is set to immediate billing, then for all the policy calculation periods that are generated by the process the calculate date is set to generate up to date and pay date is set to the system date.

Forward Billing

When the billing cycle is set to forward billing, all the policy calculation periods where the calculation date is before the generate up to date, the calculate date and pay date are update to the dates of the subsequent billing cycle which has the calculation date on or after the generate up to date. This is to bill the past periods with the period that is to be billed next.

Split on Calendar Month

When this system property is set to true, the system splits the policy calculation period at the end of the calendar month when the policy calculation period spans over two calendar months.

Split periods to align with the policy contracts and group accounts

The system splits the policy calculation period at the end of the contract period or group account as follows

  • For a policy with contract period, if the specified calculation period has one or more contract periods and/or group account periods spanning it, then a split is created for every unique combination of contract period and group account period.

  • For a policy without a contract period, if the specified calculation period has one or more group account periods spanning it, then a split is created for every period spanned by each group account period within the specified calculation period is considered as a calculation period segment. In addition, a split is also created for the period within the calculation period without any group account period overlapping.

Collection Setting Boundaries

Special attention is needed for situations where policy calculation periods are close to the beginning or the end of a collection setting with policy calculation period set to Yes.

  • Collection setting start date
    If the span reference date is after the start date of the collection setting, the timespan between the collection setting start date and the start date of the first policy calculation period is filled up with policy calculation periods. It is possible that the first policy calculation period is cut short because the period between the start of the collection setting and the span reference date doesn’t map nicely to the policy calculation period length.

  • Collection setting end date
    A policy calculation period can never cross the boundary of a collection setting. In this case the last policy calculation period is cut short to the end date of the collection setting.

Policy Calculation Period Segments Dynamic Logic

There are situations where generated policy calculation periods need to be split up in shorter policy calculation periods. For this segment function system property can be specified. For details on the system property refer to the integration guide. For more details on the dynamic logic function refer Dynamic Logic guide.

A reason for splitting policy calculation periods in shorter periods could be that one of the enrolled members reaches a certain age (e.g 18 years) which has an immediate impact on the premium as off this day.

When specified, this dynamic logic function is executed for every generated policy calculation period. Apart from splitting up generated policy calculation periods it is also capable of setting values on the generated policy calculation period:

  • Calculation Date

  • Reference Date

  • Days (for example when evenly distribution is required in monthly calculations)

  • Dynamic fields

Change Event and Mutations

When the policy calculation periods are replaced, then policy mutation of type recalculation is created with an effective date set to the start date of the earliest period (re) generated . The cause on the mutation is set to PCP_REGENERATION.

No change event rules on policy calculation period are triggered when policy calculation periods are added, updated or deleted by this activity.

Examples

Example 1: Monthly Generation 3 Months in advance

This example shows a regular generation process.The collection setting is defined in the table below:

Start Date End Date Span Ref Date Advance Length Policy Calculation Periods Calculation Period Length

01-Jan-2019

01-Jan-2019

3 Months

Yes

1 Month

Generation 1

Generate Up To: 31-Jan-2019
Generation Result:

Start Date End Date Calculation Date

01-Jan-2019

31-Jan-2019

01-Jan-2019

01-Feb-2019

28-Feb-2019

01-Jan-2019

01-Mar-2019

31-Mar-2019

01-Jan-2019

The policy calculation period starting on 01-Jan-2019 is generated as a result of the activity parameter Generate Up To Date. The consecutive policy calculation periods are a result of the collection setting that defines that premium calculation is done 3 months in advance so future policy calculation periods have to be generated upfront to cover the advance collection settings.

The calculation date for the future policy calculation periods is the same for the whole set of policy calculation periods in the same "advance collection cycle".

Generation 2

Generate Up To: 01-Feb-2019 No policy calculation periods are generated because a policy calculation period already exists for February 2019.

Generation 3

Generate Up To: 01-Mar-2019 No policy calculation periods are generated because a policy calculation period already exists for March 2019.

Generation 4

Generate Up To: 01-Apr-2019
Generation Result:

Start Date End Date Calculation Date

01-Apr-2019

30-Apr-2019

01-Apr-2019

01-May-2019

31-May-2019

01-Apr-2019

01-Jun-2019

30-Jun-2019

01-Apr-2019

A new set of policy calculation periods is generated for the next premium calculation cycle.

Example 2: Multiple Collection Settings

Start Date End Date Span Ref Date Advance Length Policy Calculation Periods Calculation Period Length

01-Jan-2018

31-Dec-2018

01-Jan-2018

28 Days

Yes

7 Days

01-Jan-2019

07-Jan-2019

28 Days

Yes

14 Days

The span reference date is set to the first Monday in the collection setting so policy calculation periods will always start on a Monday.

The system has generated policy calculations periods up to 30-Dec-2018

Start Date End Date Calculation Date

01-Jan-2018

07-Jan-2018

01-Jan-2018

08-Jan-2018

14-Jan-2018

01-Jan-2018

..

..

..

03-Dec-2018

09-Dec-2018

03-Dec-2018

10-Dec-2018

16-Dec-2018

03-Dec-2018

17-Dec-2018

23-Dec-2018

03-Dec-2018

24-Dec-2018

30-Dec-2018

03-Dec-2018

The next generate policy calculation periods is started with generate up to date 31-Jan-2019

  • 1 day is remaining in the first collection setting. A policy calculation period is generated for this day. Calculation date is set based on the extrapolation of the span reference.

  • The first policy calculation period under the second collection setting starts at 07-Jan-2019 leaving a gap from the start of the collection setting. The activity fills this gap with a shorter policy calculation period. The calculation date is set to the start date of the system calculation period.

The result of this generate activity is

Start Date End Date Calculation Date

31-Dec-2018

31-Dec-2018

31-Dec-2018

01-Jan-2019

06-Jan-2019

10-Dec-2018

07-Jan-2019

20-Jan-2019

07-Jan-2019

21-Jan-2019

03-Feb-2019

07-Jan-2019

Example 3: Collection Settings on Multiple Levels (Group Account & Policy)

This example shows the effect of overlapping collection settings for a policy on different levels like Group Account Collection Settings and Policy Collection Settings.

Suppose that there is only a group account level collection setting with the following specification:

Start Date End Date Span Ref Date Advance Length Policy Calculation Periods Calculation Period Length

01-Jan-2018

01-Jan-2018

1 Months

Yes

10 Days

Policy Calculation Period generation with generate up to date 31-March-2018 results in the following policy calculation periods:

Start Date End Date Calculation Date

1-Jan-2018

10-Jan-2018

1-Jan-2018

11-Jan-2018

20-Jan-2018

1-Jan-2018

21-Jan-2018

30-Jan-2018

1-Jan-2018

31-Jan-2018

9-Feb-2018

1-Jan-2018

10-Feb-2018

19-Feb-2018

1-Feb-2018

20-Feb-2018

1-March-2018

1-Feb-2018

2-March-2018

11-March-2018

1-March-2018

12-March-2018

21-March-2018

1-March-2018

22-March-2018

31-March-2018

1-March-2018

Now, a new policy level collection setting is defined from February 2018 that will generate weekly calculation periods.

Start Date End Date Span Ref Date Advance Length Policy Calculation Periods Calculation Period Length

01-Feb-2018

01-Feb-2018

7 Days

Yes

7 Days

Policy Calculation Period generation depends heavily on the parameters passed to the generation process. To clarify consider the various generation scenarios as described below.

Generation 2

Generate Up To Date: 31-March -2018

Replace From Date: <empty>

No periods are generated as there are periods already present that include the generate up to date

Generation 3

Generate Up To Date: 31-March -2018
Replace From Date: 1-Jan-2018
Look Back Date: 1-Jan-2018

Since the collection settings are specified on the group account and the policy level, the system determines collection settings with their effective time spans as:

Level Start Date End Date Span Ref Date Advance Length Policy Calculation Periods Calculation Period Length

Group Account

01-Jan-2018

31-Jan-2018

01-Jan-2018

1 Month

Yes

10 Days

Policy

1-Feb-2018

01-Feb-2018

7 Days

Yes

7 Days

Generated Policy Calculation Periods:

Start Date End Date Calculation Date

1-Jan-2018

10-Jan-2018

1-Jan-2018

11-Jan-2018

20-Jan-2018

1-Jan-2018

21-Jan-2018

30-Jan-2018

1-Jan-2018

31-Jan-2018

31-Jan-2018

1-Jan-2018

1-Feb-2018

7-Feb-2018

1-Feb-2018

…​

…​

…​

22-March-2018

28-March-2018

22-March-2018

29-March-2018

4-April-2018

29-March-2018

If the policy collection setting is end dated on 28 -Feb-2018

Start Date End Date Span Ref Date Advance Length Policy Calculation Periods Calculation Period Length

01-Feb-2018

28-Feb-2018

01-Feb-2018

7 Days

Yes

7 Days

Generation 4

Generate Up To Date: 31-March -2018

Replace From Date: 1-Jan-2018

Look Back Date: 1-Jan-2018

Since the collection settings are specified on the group account and the policy level, the system determines collection settings with their effective time spans as:

Level Start Date End Date Span Ref Date Advance Length Policy Calculation Periods Calculation Period Length

Group Account

01-Jan-2018

31-Jan-2018

01-Jan-2018

1 Month

Yes

10 Days

Policy

1-Feb-2018

28-Feb-2018

1-Feb-2018

7 Days

Yes

7 Days

Group Account

1- March -2018

01-Jan-2018

1 Month

Yes

10 Days

Generated Policy Calculation Periods:

Start Date End Date Calculation Date

1-Jan-2018

10-Jan-2018

1-Jan-2018

11-Jan-2018

20-Jan-2018

1-Jan-2018

21-Jan-2018

30-Jan-2018

1-Jan-2018

31-Jan-2018

31-Jan-2018

1-Jan-2018

1-Feb-2018

7-Feb-2018

1-Feb-2018

8-Feb-2018

14-Feb-2018

8-Feb-2018

…​.

…​

…​

22-Feb-2018

28-Feb-2018

22-Feb-2018

1-March-2018

1-March-2018

1-March-2018

2-March-2018

12-March-2018

1-March-2018

12-March-2018

22-March-2018

1-March-2018

22-March-2018

31-March-2018

1-March-2018


1. 'Group accounts in the group client' also include those group clients that are part of the hierarchical structure under the group client in the parameter
2. The system picks up other group accounts for period generation even though a group account is specified as parameter when multiple group accounts are encountered in the period between the look back date and the generate up to date.
3. If the look back date on the group account’s group client has a value, this value overrules the look back date activity parameter.