Account and Price Item Derivation (for the Retention Type Enrollment Based Pricing Rule Type Category)

The Validate Transaction and Derive Price Item (C1-TXNIP) batch maps the retroactive and non-retroactive enrollment transactions to one or more price item and price item parameters which are defined in the respective primary pricing rule type. This is possible only when an algorithm created using the C1_​ACCPRIDRV algorithm type is attached to the Account and Price Item Derivation system event of the primary pricing rule type.

This algorithm fetches the effective pricing rule for each price item and price item parameters combination specified in the primary pricing rule type on the derivation date. The system considers the coverage end date and coverage start date as the derivation date while fetching the effective pricing rules for the retroactive and non-retroactive enrollment transactions, respectively. This algorithm first searches for the effective pricing rule for a price item and price item parameters combination which is defined for the policy at the bill group level. If the system does not find any effective pricing rule for a price item and price item parameters combination which is defined for the policy at the bill group level, it inherits the effective pricing rule for a price item and price item parameters combination from the parent customer level.

For example, if the system receives a non-retroactive enrollment transaction with the following details:

  • UDF_​DATE_​1 is set to 01-02-2018

  • UDF_​DATE_​2 is set to 28-02-2018

  • Transaction Record Type is set to TR3

The following table illustrates how the pricing rules are defined for the enrollment transactions at different assignment levels:
Transaction Record Type Primary Pricing Rule Type Price Item Pricing Rule Pricing Start Date Pricing End Date Assignment Level
TR3 RETENTION TYPE ENROLLMENT BASED P1 C1P1 01-01-2018 31-12-2018 Parent Customer
C2P1 01-01-2018 31-12-2018 Bill Group
C3P1 01-01-2019 30-06-2019 Bill Group
P2 C1P2 01-06-2017 31-12-2017 Bill Group
C2P2 01-01-2018 31-12-2018 Parent Customer
C3P2 01-01-2019 30-06-2019 Bill Group
Note: Here, the coverage start date is mapped to the UDF_​DATE_​1 field and the coverage end date is mapped to the UDF_​DATE_​2 field in the RETENTION TYPE ENROLLMENT BASED pricing rule type.

Example 1: Effective Pricing Rule Derivation

In the example 1, the system fetches C2P1 and C2P2 pricing rules for P1 and P2, respectively, which are effective on the coverage start date. Note that the effective pricing rule for P1 is derived at the bill group level, whereas the effective pricing rule for P2 is derived from the parent customer level.

While fetching the effective pricing rule, the system first searches for exact match for the price item parameters at both the levels. For example, if the system receives a retroactive enrollment transaction with the following details:

  • UDF_​CHAR_​1 is set to Western

  • UDF_​CHAR_​2 is set to Active

  • UDF_​DATE_​1 is set to 01-03-2018

  • UDF_​DATE_​2 is set to 31-03-2018

  • Transaction Record Type is set to TR4

The following table illustrates the effective pricing rules which are available at different assignment levels for an enrollment transaction during the exact match:
Transaction Record Type Primary Pricing Rule Type Price Item Price Item Parameters Pricing Rule Pricing Start Date Pricing End Date Price Item Parameters in Pricing Rule Fees Assignment Level
TR4 ENROLLMENT BASED FEES P1 Location = UDF_​CHAR_​1 and Employee Status = UDF_​CHAR_​2 C1P1 01-01-2018 31-12-2018 Location = Western and Employee Status = Active $10 Parent Customer
Location = Eastern and Employee Status = Active $12
Location = Eastern and Employee Status = Retired $11
Location = Western and Employee Status = Retired $9
C2P1 01-01-2018 31-12-2018 Location = Western and Employee Status = Active $8 Bill Group
Location = Eastern and Employee Status = Active $9
Location = Eastern and Employee Status = Retired $10
Location = Western and Employee Status = Retired $9
Note: Here, the coverage start date is mapped to the UDF_​DATE_​1 field and the coverage end date is mapped to the UDF_​DATE_​2 field in the ENROLLMENT BASED FEES pricing rule type.

Example 2: Exact Match for Price Item Parameters

In the example 2, the system fetches the C2P1 pricing rule for P1 because of the following reasons:

  • The coverage end date (i.e. 31-03-2018) of the retroactive enrollment transaction falls within the date range (i.e. 01-01-2018 to 31-12-2018) of the C2P1 pricing rule which is defined at the bill group level.

  • It contains the exact match for the price item parameters which are received in the transaction.

If the system cannot find the exact match for the price item parameters at both the levels, the system searches for the best fit match for the price item parameters first at the bill group level and then at the parent customer level. For example, if the system receives a retroactive enrollment transaction with the following details:

  • UDF_​CHAR_​1 is set to Western

  • UDF_​CHAR_​2 is set to Active

  • UDF_​CHAR_​3 is set to HR

  • UDF_​CHAR_​4 is set to Indian

  • UDF_​DATE_​1 is set to 01-03-2018

  • UDF_​DATE_​2 is set to 31-03-2018

  • Transaction Record Type is set to TR5

For example, the following table illustrates the effective pricing rules which are available during the best fit match:
Transaction Record Type Primary Pricing Rule Type Price Item Price Item Parameters Pricing Rule Pricing Start Date Pricing End Date Price Item Parameters in Pricing Rule Fees Assignment Level
TR5 ENROLLMENT BASED CHARGES P3 Location = UDF_​CHAR_​1, Employee Status = UDF_​CHAR_​2, Employee Department = UDF_​CHAR_​3, and Nationality = UDF_​CHAR_​4 C1P3 01-01-2018 31-12-2018 Location = Western and Employee Status = Active $10 Bill Group
Location = Eastern and Employee Status = Active $12
Location = Eastern and Employee Status = Retired $11
Location = Western and Employee Status = Retired $9
Note:

Here, the coverage start date is mapped to the UDF_​DATE_​1 field and the coverage end date is mapped to the UDF_​DATE_​2 field in the ENROLLMENT BASED CHARGES pricing rule type.

Here, the Location and Employee Status parameters are mandatory for P3. However, the Employee Department and Nationality parameters are optional with the priority set to 1 and 2, respectively.

Example 3: Best Fit Match for Price Item Parameters

In the example 3, the system could not find the exact match for the price item parameters (i.e. Location = Western, Employee Status = Active, Employee Department = HR, and Nationality = Indian) in the effective pricing rule for P3. Therefore, the system searches for the best fit match. While searching for the best fit match, the system rules out the optional parameter with lowest priority (i.e. Nationality = Indian) and checks whether pricing is defined for the price item parameters (i.e. Location = Western, Employee Status = Active, and Employee Department = HR) in the effective pricing rule. If so, it considers C1P3 as the effective pricing rule for P3. If not, the system rules out the optional parameter with the next lowest priority (i.e. Employee Department = HR) and checks whether pricing is defined for the price item parameters (i.e. Location = Western and Employee Status = Active) in the effective pricing rule. If so, it considers C1P3 as the effective pricing rule for P3. If not, the status of the transaction is changed to Error.

In the example 3, the system considers pricing defined for the price item parameters (i.e. Location = Western and Employee Status = Active) as the best fit match, and therefore fetches C1P3 as the effective pricing rule for P3. While fetching the effective pricing rule, the system considers only those price item parameters specified in the primary pricing rule type for which the parameter usage is set to Pricing. For retroactive enrollment transactions, the system considers only those effective pricing rules where the Exempt Retro Transactions option is not selected.

The system then derives the account with a particular invoice type (to which a price item must be billed) based on the priority which is defined for the respective price item in the pricing rule type.

For example, the following table illustrates the accounts to which the charges of P1 and P2 should be billed based on the given priority:
Price Item Priority Invoice Type Account
P1 10 Standard A1
20 Retention A2
P2 10 Retention A2
20 Standard A1

Example 4: Priority Based Account Derivation

In the example 4, while mapping the enrollment transaction to P1, the system checks whether an account where the Invoice Type (C1INVTYP) characteristic is set to Standard exists for the bill group. If so, it considers the standard account (A1) of the bill group for billing. However, if an account where the Invoice Type (C1INVTYP) characteristic is set to Standard does not exist for the bill group, the system checks whether an account where the Invoice Type (C1INVTYP) characteristic is set to Retention exists for the bill group. If so, it considers the retention account (A2) of the bill group for billing. If an account where the Invoice Type (C1INVTYP) characteristic is set to Retention does not exist for the bill group, the status of the transaction is changed to Error.

Similarly, while mapping the enrollment transaction to P2, the system considers the account of the bill group which is available based on the priority. The system derives the billing account for only those price items for which the effective pricing rule is derived.

Note: The characteristic type which indicates the type of account (for example, C1INVTYP) must be specified in the Invoice Type Characteristic Type option type of the C1-ASOBLLNG feature configuration. Otherwise, erroneous results might occur.

Once the account is derived, the system then checks whether the account has one active contract of the contract type which is associated with the price item. If so, it fetches the contract for further processing. Once the effective pricing rule, account, and active contract are derived, the transaction is mapped to the respective price item, price item parameters, and account. A transaction leg is created for each price item, price item parameters, and account combination. For example, if the system receives a non-retroactive enrollment transaction with the following details:

  • UDF_​CHAR_​1 is set to Western

  • UDF_​CHAR_​2 is set to Active

  • UDF_​CHAR_​3 is set to HR

  • UDF_​DATE_​1 is set to 01-03-2018

  • UDF_​DATE_​2 is set to 31-03-2018

  • Transaction Record Type is set to TR5

For example, the following table illustrates that transaction legs are created only when effective pricing rule and account with an active contract are derived for a price item and price item parameters combination:
Transaction Record Type Primary Pricing Rule Type Price Item Price Item Parameters Effective Pricing Rule Best Fit Match for Price Item Parameters in Effective Pricing Rule Account Active Contract Transaction Leg
TR5 ENROLLMENT BASED FEES P1 Location = UDF_​CHAR_​1, Employee Status = UDF_​CHAR_​2, Employee Department = UDF_​CHAR_​3, and Nationality = UDF_​CHAR_​4 PR1 Location = Western and Employee Status = Active A1 C1 TL1
P2 PR2 Location = Western and Employee Status = Active A2 C2 TL2
P3 PR3 Location = Western and Employee Status = Active A3 C3 TL3
Note: Here, the coverage start date is mapped to the UDF_​DATE_​1 field and the coverage end date is mapped to the UDF_​DATE_​2 field in the ENROLLMENT BASED FEES pricing rule type.

Example 5: Transaction Leg Derivation

In the example 5, the system maps the non-retroactive enrollment transaction to the following price item, price item parameters, and account combinations:

  • Price Item: P1; Price Item Parameter: Location = Western, Employee Status = Active, and Employee Department = HR; and Account: A1

  • Price Item: P2; Price Item Parameter: Location = Western, Employee Status = Active, and Employee Department = HR; and Account: A2

  • Price Item: P3; Price Item Parameter: Location = Western, Employee Status = Active, and Employee Department = HR; and Account: A3

Note: The nationality information of an employee is not received in the UDF_​CHAR_​4 field, and therefore the non-retroactive enrollment transaction is not mapped to the Nationality price item parameter.

In the example 5, the system creates three transaction legs - TL1, TL2, and TL3 for the non-retroactive enrollment transaction. Once a transaction leg is created, the respective effective pricing rule is stamped against the transaction leg. In addition, the price item parameters of the transaction leg are grouped. In the example 5, the system creates one price item parameter group which contains the following price item parameters:

  • Location = Western

  • Employee Status = Active

  • Employee Department = HR

A group is used to determine the price item pricing. A unique group ID is generated for each group. If a group with a set of price item parameters already exists in the system, a new group is not created. Instead, the existing group is used for determining the price item pricing.

Note: The price item parameter group contains only those price item parameters included in the pricing rule type for which the parameter usage is set to Pricing.

The following table describes how the system fetches a pricing rule when a pricing group is used while defining the pricing rule for a bill group:

If the transaction is a... Then the system fetches the pricing rule when the following conditions are met...
Retroactive enrollment transaction

  • The coverage end date of the retroactive enrollment transaction falls within the pricing rule's date range.

  • The exact or best fit match is available for the price item parameters in the effective pricing rule.

  • The retroactive enrollment transaction satisfies the criteria defined in any one of the pricing group rule.
Non-retroactive enrollment transaction

  • The coverage start date of the non-retroactive enrollment transaction falls within the pricing rule's date range.

  • The exact or best fit match is available for the price item parameters in the effective pricing rule.

  • The non-retroactive enrollment transaction satisfies the criteria defined in any one of the pricing group rule.

Let us understand this with the help of an example. A retroactive enrollment transaction is received with the following details:

  • UDF_​CHAR_​1 is set to X

  • UDF_​CHAR_​2 is set to Western

  • UDF_​CHAR_​3 is set to Indian

  • UDF_​CHAR_​4 is set to HR

  • UDF_​CHAR_​5 is set to Permanent

  • UDF_​CHAR_​6 is set to Senior Manager

  • UDF_​CHAR_​7 is set to BG1

  • UDF_​DATE_​1 is set to 01-03-2018

  • UDF_​DATE_​2 is set to 31-03-2018

  • Transaction Record Type is set to TR6

For example, the following table illustrates an effective pricing rule which is defined using a retention type enrollment based pricing rule type and where a pricing group is used:
Transaction Record Type Primary Pricing Rule Type Price Item Price Item Parameters Pricing Rule Pricing Start Date Pricing End Date Pricing Group Pricing Group Rule Price Item Parameters Fees
TR6 ENROLLMENT BASED FEES PP1 Designation = UDF_​CHAR_​6; Employee Group = UDF_​CHAR_​7 PR1 01-01-2018 31-12-2018 PG1 Rule 1 (where Source System = X, Parameter 1 = Western, Parameter 2 = Indian, Parameter 3 = HR, and Parameter 4 = Permanent) Designation = Senior Manager and Employee Group = BG1 $10
Rule 1 (where Source System = X, Parameter 1 = Western, Parameter 2 = Indian, Parameter 3 = HR, and Parameter 4 = Permanent) Designation = Senior Manager and Employee Group = BG2 $12
Rule 2 (where Source System = X, Parameter 1 = Eastern, and Parameter 2 = Indian, Parameter 3 = HR, and Parameter 4 = Permanent) Designation = Senior Manager and Employee Group = BG1 $8
Rule 2 (where Source System = X, Parameter 1 = Eastern, and Parameter 2 = Indian, Parameter 3 = HR, and Parameter 4 = Permanent) Designation = Senior Manager and Employee Group = BG2 $9
Note: Here, the source system is mapped to the UDF_​CHAR_​1 field, the parameter 1 is mapped to the UDF_​CHAR_​2 field, the parameter 2 is mapped to the UDF_​CHAR_​3 field, the parameter 3 is mapped to the UDF_​CHAR_​4 field, the parameter 4 is mapped to the UDF_​CHAR_​5 field, the coverage start date is mapped to the UDF_​DATE_​1 field, and the coverage end date is mapped to the UDF_​DATE_​2 field in the ENROLLMENT BASED FEES pricing rule type.

Example 6: Effective Pricing Rule is Defined Using a Pricing Group

In the example 6, the system considers the PR1 pricing rule for PP1 because of the following reasons:

  • The coverage end date (i.e. 31-03-2018) of the retroactive enrollment transaction falls within the PR1 pricing rule's date range (i.e. 01-01-2018 to 31-12-2018).

  • The employee attributes specified in the retroactive enrollment transaction match the criteria defined in the Rule 1 (i.e. Source System = X, Parameter 1 = Western, Parameter 2 = Indian, Parameter 3 = HR, and Parameter 4 = Permanent)

  • The employee attributes specified in the retroactive enrollment transaction match the price item parameters defined within the Rule 1.

The system then stores the pricing group rule which is satisfied against a parameter which is defined in the Pricing Group Rule Parameter option type of the C1-ASOBLLNG feature configuration. In such case, the price item parameter group contains the price item parameters and the pricing group rule parameter. For example, Group A contains Designation = Senior Manager, Employee Group = BG1, and Pricing Group Rule Parameter = Rule 1.

In the example 6, the system could find the exact match for pricing parameters defined in the pricing group rule. However, if the exact match is not available, the system finds the effective pricing rule using the best fit match for the pricing parameters defined in the pricing group rule. Note that the system searches for the exact match in the effective pricing rules at both the bill group and parent customer levels. If the exact match is not available at both the levels, the system finds the effective pricing rule using the best fit match for the pricing parameters (defined in the pricing group rule) first at the bill group level and then at the parent customer level.

Let us understand this with the help of an example. A non-retroactive enrollment transaction is received with the following details:

  • UDF_​CHAR_​1 is set to X

  • UDF_​CHAR_​2 is set to Western

  • UDF_​CHAR_​3 is set to Indian

  • UDF_​CHAR_​4 is set to HR

  • UDF_​CHAR_​5 is set to Permanent

  • UDF_​CHAR_​6 is set to Senior Manager

  • UDF_​CHAR_​7 is set to BG1

  • UDF_​DATE_​1 is set to 01-05-2018

  • UDF_​DATE_​2 is set to 31-05-2018

  • Transaction Record Type is set to TR6

For example, the following table illustrates the effective pricing rules which are available during the best fit match:
Transaction Record Type Primary Pricing Rule Type Price Item Price Item Parameters Pricing Rule Pricing Start Date Pricing End Date Pricing Group Pricing Group Rule Price Item Parameters in Pricing Rule Fees
TR6 ENROLLMENT BASED FEES PP1 Designation = UDF_​CHAR_​6, Employee Group = UDF_​CHAR_​7 PR1 01-01-2018 31-12-2018 PG1 Rule 1 (where Source System = X and Parameter 1 = Western) Designation = Senior Manager; Employee Group = BG1 $20
Rule 1 (where Source System = X and Parameter 1 = Western) Designation = Senior Manager; Employee Group = BG2 $21
Rule 2 (where Source System = X and Parameter 1 = Eastern) Designation = Senior Manager; Employee Group = BG1 $18
Rule 2 (where Source System = X and Parameter 1 = Eastern) Designation = Senior Manager; Employee Group = BG2 $19
PP2 PR2 01-01-2018 31-12-2018 PG2 Rule 1 (where Source System = X, Parameter 1 = Eastern, Parameter 2 = Indian, Parameter 3 = HR, and Parameter 4 = Permanent) Designation = Senior Manager; Employee Group = BG2 $5
Rule 1 (where Source System = X, Parameter 1 = Eastern, Parameter 2 = Indian, Parameter 3 = HR, and Parameter 4 = Permanent) Designation = Senior Manager; Employee Group = BG1 $5
Rule 2 (where Source System = X, Parameter 1 = Western, Parameter 2 = Indian, Parameter 3 = HR, and Parameter 4 = Permanent) Designation = Senior Manager; Employee Group = BG2 $6
Rule 2 (where Source System = X, Parameter 1 = Western, Parameter 2 = Indian, Parameter 3 = HR, and Parameter 4 = Permanent) Designation = Senior Manager; Employee Group = BG1 $9
Note: Here, the source system is mapped to the UDF_​CHAR_​1 field, the parameter 1 is mapped to the UDF_​CHAR_​2 field, the parameter 2 is mapped to the UDF_​CHAR_​3 field, the parameter 3 is mapped to the UDF_​CHAR_​4 field, the parameter 4 is mapped to the UDF_​CHAR_​5 field, the coverage start date is mapped to the UDF_​DATE_​1 field, and the coverage end date is mapped to the UDF_​DATE_​2 field in the ENROLLMENT BASED FEES pricing rule type.

Example 7: Effective Pricing Rule Derivation Using Best Fit Match for Pricing Parameters

In the example 7, the system could not find exact match for the pricing parameters (i.e. Source System = X, Parameter 1 = Western, Parameter 2 = Indian, Parameter 3 = HR, and Parameter 4 = Permanent) in the effective pricing rule for PP1. Therefore, the system searches for the best fit match. While searching for the best fit match, the system rules out the optional parameter 4 (i.e. Parameter 4 = Permanent) and then checks whether the pricing group rule where Source System = X, Parameter 1 = Western, Parameter 2 = Indian, and Parameter 3 = HR exists in the effective pricing rule. If so, it considers the pricing group rule for further processing. If not, the system then rules out the optional parameter 3 (i.e. Parameter 3 = HR) and then checks whether the pricing group rule where Source System = X, Parameter 1 = Western, and Parameter 2 = Indian exists in the effective pricing rule. If so, it considers the pricing group rule for further processing. If not, the system then rules out the optional parameter 2 (i.e. Parameter 2 = Indian) and then checks whether the pricing group rule where Source System = X and Parameter 1 = Western exists in the effective pricing rule. If so, it considers the pricing group rule for further processing. If not, the status of the transaction is changed to Error.

In the example 7, the system considers Rule 1 where Source System = X and Parameter 1 = Western as the best fit match in the PR1 pricing rule for PP1. In addition, the employee attributes in the non-retroactive enrollment transaction satisfy the price item parameters (i.e. Designation = Senior Manager and Employee Group = BG1) defined within Rule 1. Therefore, the system fetches PR1 as the effective pricing rule for PP1. In addition, the system fetches PR2 as the effective pricing rule for PP2. The system creates two price item parameter groups - One contains Designation = Senior Manager, Employee Group = BG1, and Pricing Group Rule Parameter = Rule 1 and another contains Designation = Senior Manager, Employee Group = BG1, and Pricing Group Rule Parameter = Rule 2. Once the price item parameter group is created, the system creates the aggregation parameter group. An aggregation parameter group contains all price item parameters included in the pricing rule type for which the parameter usage is set to Aggregation.

If the effective pricing rule is not derived for a price item and price item parameters combination or if the account or active contract for the account is not derived, the system does not create a transaction leg for the respective price item.

For example, the following table illustrates that transaction legs are created only when effective pricing rule and account with an active contract are derived for a price item and price item parameters combination:
Primary Pricing Rule Type Price Item Price Item Parameters Effective Pricing Rule Account Active Contract Transaction Leg
ENROLLMENT BASED FEES PP1 Designation = UDF_​CHAR_​6, Employee Status = UDF_​CHAR_​7 - - - -
PP2 PR2 - - -
PP3 PR3 A3 C3 TL1
PP4 - - - -
PP5 PR5 A2 C1 TL2
PP6 PR6 A1 - -

Example 8: No. of Transaction Legs Derived

In the example 8, the system could not find the effective pricing rule for PP1 and PP4, the required account for PP2, and the active contract for PP6 on A1. Therefore, in this case, the system creates two transaction legs - TL1 and TL2 for the enrollment transaction.

If the eligibility rule type is defined of a price item, the system maps the enrollment transaction to the price item when the eligibility rule is satisfied. If the eligibility rule is not satisfied, the system does not consider the price item for billing. For example,

Price Item Eligibility Criteria Met Effective Pricing Rule Account Active Contract Transaction Leg
PE1 Yes PR1 A1 C1 TL1
PE2 - PR2 - - -
PE3 No - - - -
PE4 Yes - - - -
PE5 Yes PR3 A2 - -
PE6 Yes PR4 - - -

Example 9: Price Item Eligibility for Transaction Leg Derivation

In the example 9, the eligibility criteria was defined for PE1, PE3, PE4, PE5, and PE6. The eligibility criteria was satisfied for PE1, PE4, PE5, and PE6, but not for PE3. Further, the system could not find the effective pricing rule for PE4, the required account for PE2 and PE6, and the active contract for PE5 on A2. Therefore, in this case, the system creates one transaction leg (i.e. TL1) for the enrollment transaction. For more information, refer to the Price Item Eligibility section.

Once a transaction leg is created, the derivation date is set as the processing date corresponding to the transaction leg.