Run Calculation and Produce Invoice for a Group Account

Policies for employers will most often refer to the employer group account. When an employer enrolls online, the employer will manage the choices of their employees online as well. After completion of all their choices, the employer wants to submit all the policies in one go and wait for the invoice.

The complete process of a group account enrolling online could look like this:

• the group account manages the enrollment process until all employees have made their choices

• the policies for the group account are created, submitted and approved in Oracle Health Insurance

• the group account initiates the obligation to pay from the portal

• Oracle Health Insurance calculates the premium for all policies of the group account and produces an invoice which is sent to the portal

• the employer pays which is reflected in the financial back end system

This process can also be used for managing changes to policies belonging to a group account. After the changes are submitted and approved in OHI, the same need can arise to initiate the obligation to pay and receive the invoice from Oracle Health Insurance after (re)calculation.

The process from calculation up to and including the production of an invoice is thus restricted to approved policies. It consists of the following sub steps:

• 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. The premium and commission results can be sent to different endpoints.

• select financial transactions into a set

• supersede financial transactions

• generate financial message (XML format)

The first sub step is described in detail in the Operations Guide for Premium Calculation while the subsequent sub steps are described in detail in the Implementation Guide for Financial. Here, the focus will be on how the integration works and where the processing differs from the descriptions in the Implementation Guides.

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

The parameters for the activity are as follows:

Table 1. Run Calculation and Produce Invoice for a Group Account

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.
Create Invoice Function	Function dynamic logic with signature Create Invoice XML fills the values of an invoice element for an invoice. They are executed once per invoice for the transactions being processed.
Create Invoice Line Function	Function dynamic logic with signature Create Invoice Line XML fills the values of an invoice line element for an invoice. They are executed once per invoice line for the transactions being processed.
Create Accounting Detail Function	Function dynamic logic with signature Accounting Detail XML fills the values of an accounting detail line. They are executed once per accounting detail for the transactions being processed.
Premium Endpoint	The endpoint to which the premium financial message generation notification is sent.
Commission Endpoint	The endpoint to which the commission financial message generation notification is sent.
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 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:

Table 2. Error Messages

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 context), 'Policy' (referring to one of the policies of the group account at hand, as described in the "Calculate Premium per Group Account" section Calculate Premium page of the Operations Guide within Premium Calculation chapter) 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 "Change Events" chapter in the Configuration 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):

Table 3. Parameters Not Considered

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. The two financial transaction sets for Premium and Premium Based Commission are exposed to two separate datafile sets. These data file sets contain an auto generated datafile set code with a prefix PRE and PBC respectively that enables to differentiate between the two datafile sets.

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 automatically 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 one of the new financial transaction sets 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.

• supersede financial transactions

• generate financial message (XML format)
  The dynamic logic for the creation of invoice, invoice line and account detail is mandatory, just as it is when starting the generation of the financial message directly within the application.
  Because two financial transaction sets were created whenever financial transactions for commissions exist, financial transactions for premium and financial transactions for commission can never come into the same financial message.
  The endpoints for premium and commission are both optional: if an endpoint is not specified, it defaults to the endpoint for Generate Financial Message in the properties file.

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

If the Currency Conversion (Billing or Commission) function dynamic logic exists, it will do the conversion as specified in the function. If the function does not find an exchange rate, technical error GEN-CURR-002 is thrown (see the "Dynamic Logic" chapter of the Developer Guide for more information).