Account and Price Item Derivation (for the Claim Pricing Rule Type Category)
The Validate Transaction and Derive Price Item (C1-TXNIP) batch maps a claim transaction to one or more price item and price item parameters which are defined in the respective primary pricing rule type. This is possible 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 specified in the primary pricing rule type on the derivation date. The system considers the paid date as the derivation date while fetching the effective pricing rules for the claim transactions. This algorithm first searches for the effective pricing rule for a price item 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 which is defined for the policy at the bill group level, it inherits the effective pricing rule for a price item from the parent customer level.
For example, if the system receives a claim transaction with the following details:
-
UDF_DATE_1 is set to 15-01-2018
-
Transaction Record Type is set to TR1
Transaction Record Type | Primary Pricing Rule Type | Price Item | Pricing Rule | Pricing Start Date | Pricing End Date | Assignment Level |
---|---|---|---|---|---|---|
TR1 | CLAIM | 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 |
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 paid 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.
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.
Price Item | Priority | Invoice Type | Account |
---|---|---|---|
P1 | 10 | Standard | A1 |
20 | Retention | A2 | |
P2 | 10 | Retention | A2 |
20 | Standard | A1 |
Example 2: Priority Based Account Derivation
In the example 2, while mapping the claim 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 claim 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.
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 claim transaction is mapped to the following price item and account combinations:
Price Item | Effective Pricing Rule | Account | Active Contract | Transaction Leg |
---|---|---|---|---|
P1 | PR1 | A1 | C1 | TL1 |
P2 | PR2 | A2 | C2 | TL2 |
P3 | PR3 | A3 | C3 | TL3 |
Example 3: Transaction Leg Derivation
If a pricing group is used while defining a pricing rule for a bill group, the system fetches the pricing rule for a claim transaction when the following conditions are met:
-
The paid date of the claim transaction falls within the pricing rule’s date range.
-
The employee attributes specified in the claim transaction match the criteria defined in any one of the pricing group rule.
Let us understand this with the help of an example. A claim 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_DATE_1 is set to 04-06-2018
-
Transaction Record Type is set to TR1
Transaction Record Type | Primary Pricing Rule Type | Price Item | Pricing Rule | Pricing Start Date | Pricing End Date | Pricing Group | Rule 1 | Rule 2 |
---|---|---|---|---|---|---|---|---|
TR1 | CLAIM | PP1 | PR1 | 01-01-2018 | 31-12-2018 | PG1 | Source System = X, Parameter 1 = Western, Parameter 2 = Indian, Parameter 3 = HR, and Parameter 4 = Permanent | Source System = X, Parameter 1 = Eastern, and Parameter 2 = Indian, Parameter 3 = HR, and Parameter 4 = Permanent |
Example 4: Effective Pricing Rule is Defined Using a Pricing Group
In the example 4, the system considers the PR1 pricing rule for PP1 because of the following reasons:
-
The paid date (i.e. 04-06-2018) of the claim 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 claim transaction match the criteria defined in the Rule 1 (i.e. Source System = X, Location = Western, Nationality = Indian, Employee Department = HR, and Employee Status = Permanent)
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 the example 4, the price item parameter group is created and it contains the pricing group rule parameter. For example, Group A contains Pricing Group Rule Parameter = Rule 1.
In the example 4, 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 claim 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_DATE_1 is set to 04-06-2018
-
Transaction Record Type is set to TR2
Transaction Record Type | Primary Pricing Rule Type | Price Item | Pricing Rule | Pricing Start Date | Pricing End Date | Pricing Group | Rule 1 | Rule 2 |
---|---|---|---|---|---|---|---|---|
TR2 | CLM | PP1 | PR1 | 01-01-2018 | 31-12-2018 | PG1 | Source System = X and Parameter 1 = Western | Source System = X and Parameter 1 = Eastern |
PP2 | PR2 | 01-01-2018 | 31-12-2018 | PG2 | Source System = X, Parameter 1 = Eastern, Parameter 2 = Indian, Parameter 3 = HR, and Parameter 4 = Permanent | Source System = X, Parameter 1 = Western, Parameter 2 = Indian, Parameter 3 = HR, and Parameter 4 = Permanent |
Example 5: Effective Pricing Rule Derivation Using Best Fit Match for Pricing Parameters
In the example 5, the system could not find the 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 PR1 as the effective pricing rule for PP1. 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 PR1 as the effective pricing rule for PP1. 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 PR1 as the effective pricing rule for PP1. If not, the status of the transaction is changed to Error.
In the example 5, the system considers Rule 1 where Source System = X and Parameter 1 = Western as the best fit match, and therefore 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 Pricing Group Rule Parameter = Rule 1 and another contains 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 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. Let us understand this with the help of an example:
Price Item | Effective Pricing Rule | Account | Active Contract | Transaction Leg |
---|---|---|---|---|
PP1 | - | - | - | - |
PP2 | PR2 | - | - | - |
PP3 | PR3 | A3 | C3 | TL1 |
PP4 | - | - | - | - |
PP5 | PR5 | A2 | C1 | TL2 |
PP6 | PR6 | A1 | - | - |
Example 6: No. of Transaction Legs Derived
In the example 6, 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 claim transaction.
If the eligibility rule type is defined of a price item, the system maps the claim 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 7: Price Item Eligibility for Transaction Leg Derivation
In the example 7, 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 claim 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.