Run Calculation and Select in Set for a Group Account

In Run Calculation and Produce Invoice for a Group Account the complete process of a group account enrolling online is described, from premium calculation up to and including the production of a financial message. A variant of this would be to not do the financial processing (superseding and generating a financial message).

That way, the process would look like this:

calculate premium for a particular group account
The calculation of commission is embedded in the premium calculation as a percentage of the policy enrollment product premium and policy add-on premium. That’s why the commission calculation also takes place.
select financial transactions into a set

The first sub step is described in detail in the Implementation Guide for Premium Calculation while the second sub step is described in detail in the Implementation Guide for Financial.

Not performing the financial processing has as advantage, that more financial transactions can be added to the set(s) (one for premium and possibly one for commission financial transactions). When all additions are done, the financial processing can be completed at will through Supersede Financial Transactions and Generate Financial Message. Clearly, this advantage only makes sense when there is a need to add financial transactions - or maybe to inspect the contents of the financial message set(s).

The context needs to be set to the group account (see the Activity Integration Point in the Integration Guide for more detail), ensuring that only policies for the specified group account are picked up.

The parameters for the activity are as follows:

Name	Description
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	The look back date prevents the system from recalculating premium for the calculation periods before this 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?	The 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' disables 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?	System takes into account this setting only when the system property indicates that the registrations should not be applied to the 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 If the system property indicates that payments must be applied then the Replace From Date set to the earliest of: start date of the earliest policy calculation period which starts after the date paid to and has its pay date before the calculation input date. If the date paid to is not set then the start date of the earliest policy calculation period which starts on or after the earliest policy enrollment product and has its pay date before the calculation input date is considered. policy mutation effective date that is nearest to and after the premium calculation look back 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.

Name

Description

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

The look back date prevents the system from recalculating premium for the calculation periods before this 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?

The 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' disables 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?

System takes into account this setting only when the system property indicates that the registrations should not be applied to the 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

If the system property indicates that payments must be applied then the Replace From Date set to the earliest of:

start date of the earliest policy calculation period which starts after the date paid to and has its pay date before the calculation input date.
- If the date paid to is not set then the start date of the earliest policy calculation period which starts on or after the earliest policy enrollment product and has its pay date before the calculation input date is considered.
policy mutation effective date that is nearest to and after the premium calculation look back 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 following error messages can occur during validation of the input parameters:

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

Code

Severity

Message Text

POL-VL-CAPR-002

Fatal

Group account code {0} is unknown

POL-VL-CAPR-004

Fatal

Look back date {date} must be on or before the calculation input start date {input parameter calculation period}

POL-VL-CAPR-005

Fatal

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

In addition, error messages can come from one of the sub steps; the different sub steps in more detail

mutations
- Policy events for recalculation of level 'Group Account' (referring to the group account as specified by the input parameter), 'Policy' (referring to one of the policies of the group account at hand) or level 'Insurable Entity' (referring to one of the policy enrollments of one of the policies of the group account at hand) are picked up and translated into policy mutations (described in detail in the OHI Policies - Change Events Guide). That way, all policy mutations can be subjected to the premium calculation after which they can be discarded.
calculate premium (Default)
- If the look back date is unspecified, then the look back date is set to the calculation input date.
calculate premium (AU Localization, when system property indicates that the registrations should be applied to the periods)
- Process registrations and apply registrations to periods processes are executed before calculate premium and after events are translated to mutations
- The input value of the following parameters is not considered, instead the process always (re)set them to values as specified below (after executing apply registrations process):

Name	Description
Look Back Date	This is set to the Date Paid To plus one of the policy as determined by the apply registration process. This is to ensure that any periods to which payments have been applied are not accidentally re-calculated. These periods can only be re-calculated by 'Apply Registration to Periods' process. If Date Paid To is unspecified, the look back date is set to the earliest policy enrollment product starts or to the start date of the earliest non reversed calculation result or to the calculation input date, whichever is earlier. This is set per policy.
Generate Policy Calculation Periods	This is set to true

Name

Description

Look Back Date

This is set to the Date Paid To plus one of the policy as determined by the apply registration process. This is to ensure that any periods to which payments have been applied are not accidentally re-calculated. These periods can only be re-calculated by 'Apply Registration to Periods' process.
If Date Paid To is unspecified, the look back date is set to the earliest policy enrollment product starts or to the start date of the earliest non reversed calculation result or to the calculation input date, whichever is earlier.
This is set per policy.

Generate Policy Calculation Periods

This is set to true

select financial transactions into a set
A financial transaction set (one for premium and one for - if appropriate - for commission) is used to group financial transactions together for financial processing.
For convenience, a new financial transaction set will be created automatically into which all financial transactions for premium are put. If financial transactions for commissions also exist, then a different new financial transaction set is created into which the financial transactions for commission are put. The codes of the newly created financial transaction sets are published as a dynamic record 'financialTransactionSetCodes' on the activity.
If unhandled financial transactions already exist for the same base financial object, they are moved into the new financial transaction set as well. This situation is not likely for the portal use case, but it is possible when the group account makes a change in the portal while there were already unhandled financial transactions in the system.

Like for all activity types, an activity can be set up using the Activity IP (described in the HTTP Integration Points of the Integration Guide).