Account and Price Item Derivation (for the Specific Stop-Loss and Aggregate Stop-Loss Pricing Rule Type Categories)

Once the Validate Transaction and Derive Price Item (C1-TXNIP) batch calls the primary pricing rule type specified in the transaction record type, it calls the related pricing rule types (if any) defined in the primary pricing rule type. Note that the related pricing rule types are called one by one in the specified sequence. Let us understand this with the help of an example.

The following table illustrates how related pricing rule types can be sequenced in a claim pricing rule type:
Primary Pricing Rule Type	Sequence	Related Pricing Rule Type
CLAIM	10	SPECIFIC STOP-LOSS
CLAIM	20	AGGREGATE STOP-LOSS

Example 1: Related Pricing Rule Type Sequence

In the example 1, the system first calls the related pricing rule type with the highest sequence (i.e. 10) once the CLAIM pricing rule type is called. The system calls the related pricing rule type irrespective of whether the transaction legs are derived using the primary pricing rule type. Once the SPECIFIC STOP-LOSS pricing rule type is called, the system calls the related pricing rule type with the next sequence (i.e. 20). This process continues until all related pricing rule types defined in the primary pricing rule type are called one by one in the specified sequence.

If the eligibility rule type is defined for a related pricing rule type, the system considers the related pricing rule type for deriving the transaction legs when the eligibility rule is satisfied. If the eligibility rule is not satisfied, the system does not consider the related pricing rule type for deriving the transaction legs. Let us understand this with the help of an example.

The following table illustrates a claim pricing rule type where eligibility criteria is considered while deriving transaction legs for the related pricing rule types:
Primary Pricing Rule Type	Sequence	Related Pricing Rule Type	Eligibility Criteria Met
CLAIM	10	SPECIFIC STOP-LOSS	Yes
CLAIM	20	AGGREGATE STOP-LOSS	No

Example 2: Related Pricing Rule Type Eligibility Criteria

In the example 2, the eligibility criteria is defined for the SPECIFIC STOP-LOSS and AGGREGATE STOP-LOSS pricing rule types. However, the eligibility criteria for the AGGREGATE STOP-LOSS pricing rule type was not satisfied, and therefore it is not used for deriving the transaction legs.

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 eligible related pricing rule type. This is possible when you attach an algorithm created using the C1_ACCPRISL algorithm type to the Account and Price Item Derivation system event of the related pricing rule type.

Note: Ideally, the pricing rule types where the pricing rule type category is set to Specific Stop-Loss or Aggregate Stop-Loss should not have price item parameters for which the parameter usage is set to Pricing. This is because the system will not use these price item parameters while searching for an effective pricing rule for the respective price items.

This algorithm fetches an effective pricing rule for each price item specified in the related pricing rule type. It searches for an effective pricing rule for a price item at the bill group level. It derives an effective pricing rule for each price item using the incurred and paid dates specified in the claim transaction. It fetches an effective pricing rule where the following conditions are met:

The incurred and paid dates of the claim transaction fall within the incurred and paid date ranges defined in the parent accumulation group (which is derived through the parent customer's pricing rule).
A transaction leg is already created for at least one price item and price item parameters combination which is specified in the accumulation criteria.

For run-in claim transactions, this algorithm fetches an effective pricing rule where the following conditions are met:

The run-in incurred and paid dates of the claim transaction fall within the run-in incurred and paid date ranges defined in the run-in accumulation group (which is derived through the parent customer's pricing rule).
The effective pricing rule exists for at least one price item and price item parameters combination which is specified in the accumulation criteria.

For example, if the system receives a claim transaction with the following details:

UDF_CHAR_1 is set to Western
UDF_CHAR_2 is set to BG1
UDF_DATE_1 is set to 18-02-2018
UDF_DATE_2 is set to 28-02-2018
Transaction Record Type is set to TR1

For example, the following table illustrates the pricing structure defined for various related pricing rules:
Transaction Record Type	Primary Pricing Rule Type	Related Pricing Rule Type	Price Item in Related Pricing Rule Type	Pricing Rule	Incurred Date Range in Associated Parent Customer's Pricing Rule	Paid Date Range in Associated Parent Customer's Pricing Rule	Accumulation Criteria
Transaction Record Type	Primary Pricing Rule Type	Related Pricing Rule Type	Price Item in Related Pricing Rule Type	Pricing Rule	(i.e. in Parent Accumulation Group)		Accumulation Criteria
TR1	CLAIM	SPECIFIC STOP-LOSS	S1	C1S1	01-01-2017 - 31-12-2017	01-01-2017 - 28-02-2018	Price Item: CLAIM, Price Item Parameters: Location = Western, Employee Group = BG1
				C2S1	01-01-2018 - 31-12-2018	01-01-2018 - 28-02-2019	Price Item: CLAIM, Price Item Parameters: Location = Western, Employee Group = BG1
				C2S1	01-01-2018 - 31-12-2018	01-01-2018 - 28-02-2019	Price Item: CLM, Price Item Parameters: Location = Western, Employee Group = BG1
			S2	C1S2	01-01-2017 - 31-12-2017	01-01-2017 - 28-02-2018	Price Item: CLM, Price Item Parameters: Location = Western, Employee Group = BG1
			S2	C2S2	01-01-2018 - 31-12-2018	01-01-2018 - 28-02-2019	Price Item: CLM, Price Item Parameters: Location = Western, Employee Group = BG1

Note:

Price Item in Primary Pricing Rule Type: CLM; Price Item Parameters in Primary Pricing Rule Type where the Eligible for Stop-Loss option is selected: Location = UDF_CHAR_1 and Employee Group = UDF_CHAR_2.

Here, the incurred date is mapped to the UDF_DATE_1 field and the paid date is mapped to the UDF_DATE_2 field in the CLAIM pricing rule type.

Example 3: SSL and ASL Effective Pricing Rule Derivation for Claim Transaction

In the example 3, the system fetches the C2S1 and C2S2 pricing rules for S1 and S2, respectively, because of the following reasons:

Incurred date mentioned in the claim transaction falls within the incurred date range (i.e. 01-01-2018 - 31-12-2018) defined in the parent accumulation group.
Paid date mentioned in the claim transaction falls within the paid date range (i.e. 01-01-2018 - 28-02-2019) defined in the parent accumulation group.
A transaction leg already exists for the following price item and price item parameters combination which is specified in the accumulation criteria of the C2S1 and C2S2 pricing rules:
- Price Item: CLM, Price Item Parameters: Location = Western and Employee Group = BG1

Let us take another example where the system receives a run-in claim transaction with the following details:

UDF_CHAR_1 is set to Eastern
UDF_CHAR_3 is set to Active
UDF_DATE_3 is set to 18-06-2017
UDF_DATE_4 is set to 01-07-2017
Transaction Record Type is set to TR2

For example, the following table illustrates the pricing structure defined for various related pricing rules:
Transaction Record Type	Primary Pricing Rule Type	Related Pricing Rule Type	Price Item in Related Pricing Rule Type	Pricing Rule	Run-in Incurred Date Range in Associated Parent Customer's Pricing Rule	Run-in Paid Date Range in Associated Parent Customer's Pricing Rule	Accumulation Criteria
Transaction Record Type	Primary Pricing Rule Type	Related Pricing Rule Type	Price Item in Related Pricing Rule Type	Pricing Rule	(i.e. in Run-in Accumulation Group)		Accumulation Criteria
TR2	CLAIM	AGGREGATE STOP-LOSS	AS1	C1AS1	01-01-2017 - 31-12-2017	01-01-2017 - 28-02-2018	Price Item: CLAIM, Price Item Parameters: Location = Eastern, Employee Status = Active
				C2AS1	01-01-2018 - 31-12-2018	01-01-2018 - 28-02-2019	Price Item: CLAIM, Price Item Parameters: Location = Eastern, Employee Status = Active
				C2AS1	01-01-2018 - 31-12-2018	01-01-2018 - 28-02-2019	Price Item: CLM, Price Item Parameters: Location = Eastern, Employee Status = Active
			AS2	C1AS2	01-01-2017 - 31-12-2017	01-01-2017 - 28-02-2018	Price Item: CLM, Price Item Parameters: Location = Eastern, Employee Status = Active
			AS2	C2AS2	01-01-2018 - 31-12-2018	01-01-2018 - 28-02-2019	Price Item: CLM, Price Item Parameters: Location = Eastern, Employee Status = Active

Note:

Price Items in Primary Pricing Rule Type: CLAIM and CLM; Price Item Parameters in Primary Pricing Rule Type where the Eligible for Stop-Loss option is selected: Location = UDF_CHAR_1 and Employee Status = UDF_CHAR_3.

Here, the run-in incurred date is mapped to the UDF_DATE_3 field and the run-in paid date is mapped to the UDF_DATE_4 field in the CLAIM pricing rule type.

Example 4: SSL and ASL Effective Pricing Rule Derivation for Run-in Claim Transaction

In the example 4, the system fetches the C1AS1 and C1AS2 pricing rules for AS1 and AS2, respectively, because of the following reasons:

Run-in incurred date mentioned in the claim transaction falls within the run-in incurred date range (i.e. 01-01-2017 - 31-12-2017) defined in the run-in accumulation group.
Run-in paid date mentioned in the claim transaction falls within the run-in paid date range (i.e. 01-01-2017 - 28-02-2018) defined in the run-in accumulation group.
An effective pricing rule exists for the following price item and price item parameters combination which is specified in the accumulation criteria of the C1AS1 and C1AS2 pricing rules:
- Price Item: CLAIM, Price Item Parameters: Location = Eastern, Employee Status = Active
- Price Item: CLM, Price Item Parameters: Location = Eastern, Employee Status = Active

The system then checks whether the ASSL Credit Account (in case of specific stop-loss pricing rule) and ASL Credit Account (in case of aggregate stop-loss pricing rule) is specified in the associated parent customer's pricing rule. If so, the system considers the respective account for billing. Otherwise, the system 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 related pricing rule type.

For example, the following table illustrates the accounts to which the charges of S1 and S2 should be billed based on the given priority:
Related Pricing Rule Type	Price Item	Priority	Invoice Type	Account
SPECIFIC STOP-LOSS	S1	10	Standard	A1
	S1	20	Retention	A2
	S2	10	Retention	A2
	S2	20	Standard	A1

Example 5: Priority Based Account Derivation

In the example 5, while mapping the claim transaction to S1, 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 S2, 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, the following table illustrates how the related transaction legs are created for each price item, price item parameters, and account combination:
Transaction Record Type	Primary Pricing Rule Type	Related Pricing Rule Type	Price Item in Related Pricing Rule Type	Effective Pricing Rule	Account	Active Contract	Transaction Leg
TR1	CLAIM	SPECIFIC STOP-LOSS	S3	PRS3	A1	C3	TL3
TR1	CLAIM	SPECIFIC STOP-LOSS	S4	PRS4	A2	C4	TL4

Example 6: Transaction Leg Derivation

In the example 6, the system creates two transaction legs - TL3 and TL4 for the claim transaction. Once a transaction leg is created, the respective effective pricing rule is stamped against the transaction leg. Usually, once a transaction leg is created in the Validate Transaction and Derive Price Item (C1-TXNIP) batch, the price item parameters (for which the parameter usage is set to Pricing) of the transaction leg are grouped. The system does not support multiple parameter based pricing for the pricing rule types where the pricing rule type category is set to Specific Stop-Loss and Aggregate Stop-Loss. Therefore, when the price item parameters are not specified, the price item parameter group ID is set to 1 corresponding to each transaction leg - TL3 and TL4.

Note: A price item parameter 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.

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 incurred and paid dates of the claim transaction fall within the incurred and paid date ranges defined in the parent accumulation group (which is derived through the parent customer's pricing rule).
A transaction leg is already created for at least one price item and price item parameters combination which is specified in the accumulation criteria.
The employee attributes specified in the claim transaction match the criteria defined in any one of the pricing group rule.

Similarly, the system will fetch the pricing rule for a run-in claim transaction when the following conditions are met:

The run-in incurred and paid dates of the claim transaction fall within the run-in incurred and paid date ranges defined in the run-in accumulation group (which is derived through the parent customer's pricing rule).
The effective pricing rule exists for at least one price item and price item parameters combination which is specified in the accumulation criteria.
The employee attributes specified in the run-in 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_CHAR_6 is set to Senior Manager
UDF_CHAR_7 is set to BG1
UDF_DATE_1 is set to 31-12-2018
UDF_DATE_2 is set to 28-02-2019
Transaction Record Type is set to TR1

For example, the following table illustrates an effective related pricing rule which is defined using a specific stop-loss pricing rule type and where a pricing group is used:
Transaction Record Type	Primary Pricing Rule Type	Related Pricing Rule Type	Price Item in Related Pricing Rule Type	Pricing Rule	Incurred Date Range in Associated Parent Customer's Pricing Rule	Paid Date Range in Associated Parent Customer's Pricing Rule	Pricing Group	Pricing Group Rule	Accumulation Criteria
Transaction Record Type	Primary Pricing Rule Type	Related Pricing Rule Type	Price Item in Related Pricing Rule Type	Pricing Rule	(i.e. in Parent Accumulation Group)		Pricing Group	Pricing Group Rule	Accumulation Criteria
TR1	CLAIM	SPECIFIC STOP-LOSS	S1	PR1	01-01-2018 - 31-12-2018	01-01-2018 - 28-02-2019	PG1	Rule 1 (where Source System = X, Parameter 1 = Western, Parameter 2 = Indian, Parameter 3 = HR, and Parameter 4 = Permanent)	Price Item: CLM; Price Item Parameters: Designation = Senior Manager and Employee Group = BG1
								Rule 1 (where Source System = X, Parameter 1 = Western, Parameter 2 = Indian, Parameter 3 = HR, and Parameter 4 = Permanent)	Price Item: CLM; Price Item Parameters: Designation = Senior Manager and Employee Group = BG2
								Rule 2 (where Source System = X, Parameter 1 = Eastern, and Parameter 2 = Indian, Parameter 3 = HR, and Parameter 4 = Permanent)	Price Item: CLM; Price Item Parameters: Designation = Senior Manager and Employee Group = BG1
								Rule 2 (where Source System = X, Parameter 1 = Eastern, and Parameter 2 = Indian, Parameter 3 = HR, and Parameter 4 = Permanent)	Price Item: CLM; Price Item Parameters: Designation = Senior Manager and Employee Group = BG2

Note:

Price Item in Primary Pricing Rule Type: CLM; Price Item Parameters in Primary Pricing Rule Type where the Eligible for Stop-Loss option is selected: Designation = UDF_CHAR_6 and Employee Group = UDF_CHAR_7.

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 incurred date is mapped to the UDF_DATE_1 field, and the paid date is mapped to the UDF_DATE_2 field in the CLAIM pricing rule type.

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

In the example 7, the system considers the PR1 pricing rule for S1 because of the following reasons:

Incurred date mentioned in the claim transaction falls within the incurred date range (i.e. 01-01-2018 - 31-12-2018) defined in the parent accumulation group.
Paid date mentioned in the claim transaction falls within the paid date range (i.e. 01-01-2018 - 28-02-2019) defined in the parent accumulation group.
The employee attributes specified in the claim 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).
A transaction leg already exists for the following price item and price item parameters combination which is specified in the accumulation criteria of the PR1 pricing rule:
- Price Item: CLM; Price Item Parameters: Designation = Senior Manager and Employee Group = BG1

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 7, 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 7, 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. 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_CHAR_6 is set to Senior Manager
UDF_CHAR_7 is set to BG1
UDF_DATE_1 is set to 06-06-2018
UDF_DATE_2 is set to 27-06-2018
Transaction Record Type is set to TR2

For example, the following table illustrates the effective related pricing rules which are available during the best fit match:
Transaction Record Type	Primary Pricing Rule Type	Related Pricing Rule Type	Price Item in Related Pricing Rule Type	Pricing Rule	Incurred Date Range in Associated Parent Customer's Pricing Rule	Paid Date Range in Associated Parent Customer's Pricing Rule	Pricing Group	Pricing Group Rule	Accumulation Criteria
Transaction Record Type	Primary Pricing Rule Type	Related Pricing Rule Type	Price Item in Related Pricing Rule Type	Pricing Rule	(i.e. in Parent Accumulation Group)		Pricing Group	Pricing Group Rule	Accumulation Criteria
TR2	CLAIM	SPECIFIC STOP-LOSS	S1	PR1	01-01-2018 - 31-12-2018	01-01-2018 - 28-02-2019	PG1	Rule 1 (where Source System = X and Parameter 1 = Western)	Price Item: CLAIM; Price Item Parameters: Designation = Senior Manager; Employee Group = BG1
								Rule 1 (where Source System = X and Parameter 1 = Western)	Price Item: CLAIM; Price Item Parameters: Designation = Senior Manager; Employee Group = BG2
								Rule 2 (where Source System = X and Parameter 1 = Eastern)	Price Item: CLAIM; Price Item Parameters: Designation = Senior Manager; Employee Group = BG1
								Rule 2 (where Source System = X and Parameter 1 = Eastern)	Price Item: CLAIM; Price Item Parameters: Designation = Senior Manager; Employee Group = BG2
			S2	PR2	01-01-2018 - 31-12-2018	01-01-2018 - 28-02-2019	PG2	Rule 1 (where Source System = X, Parameter 1 = Eastern, Parameter 2 = Indian, Parameter 3 = HR, and Parameter 4 = Permanent)	Price Item: CLAIM; Price Item Parameters: Designation = Senior Manager; Employee Group = BG2
								Rule 1 (where Source System = X, Parameter 1 = Eastern, Parameter 2 = Indian, Parameter 3 = HR, and Parameter 4 = Permanent)	Price Item: CLAIM; Price Item Parameters: Designation = Senior Manager; Employee Group = BG1
								Rule 2 (where Source System = X, Parameter 1 = Western, Parameter 2 = Indian, Parameter 3 = HR, and Parameter 4 = Permanent)	Price Item: CLAIM; Price Item Parameters: Designation = Senior Manager; Employee Group = BG2
								Rule 2 (where Source System = X, Parameter 1 = Western, Parameter 2 = Indian, Parameter 3 = HR, and Parameter 4 = Permanent)	Price Item: CLAIM; Price Item Parameters: Designation = Senior Manager; Employee Group = BG1

Note:

Price Item in Primary Pricing Rule Type: CLAIM; Price Item Parameters in Primary Pricing Rule Type where the Eligible for Stop-Loss option is selected: Designation = UDF_CHAR_6 and Employee Group = UDF_CHAR_7.

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

In the example 8, 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 S1. 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 8, the system considers Rule 1 where Source System = X and Parameter 1 = Western as the best fit match in the PR1 pricing rule for S1. In addition, a transaction leg already exists for the following price item and price item parameters combination which is specified in the accumulation criteria of the PR1 pricing rule:

Price Item: CLAIM; Price Item Parameters: Designation = Senior Manager; Employee Group = BG1

Therefore, the system fetches PR1 as the effective pricing rule for S1. In addition, the system fetches PR2 as the effective pricing rule for S2. 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 related 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.

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:
Related Pricing Rule Type	Price Item	Effective Pricing Rule	Account	Active Contract	Transaction Leg
AGGREGATE STOP-LOSS	AS11	-	-	-	-
	AS12	PR12	A1	C1	TL11
	AS13	PR13	-	-	-
	AS14	PR14	A2	-	-
	AS15	PR15	-	-	-
	AS16	-	-	-	-
	AS17	PR17	A2	C2	TL12

Example 9: No. of Transaction Legs Derived

In the example 9, the system could not find the effective pricing rule for AS11 and AS16, the required account for AS13 and AS15, and the active contract for AS14 on A2. Therefore, in this case, the system creates two transaction legs - TL11 and TL12 for the transaction.

If the eligibility rule type is defined for a price item, the system maps the 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, the following table illustrates the related pricing rule types where eligibility criteria is considered while deriving transaction legs for the price items:
Sequence	Related Pricing Rule Type	Rule Type Eligibility Criteria Met	Price Item	Price Item Eligibility Criteria Met	Effective Pricing Rule	Account	Active Contract	Transaction Leg
10	SPECIFIC STOP-LOSS	Yes	SS1	Yes	PR1	A1	C1	TL1
			SS2	-	PR2	A2	C2	TL2
			SS3	No	-	-	-	-
20	AGGREGATE STOP-LOSS	No	AS4	-	-	-	-	-
			AS5	-	-	-	-	-
			AS6	-	-	-	-	-

Example 10: Price Item Eligibility for Transaction Leg Derivation

In the example 10, the eligibility criteria is defined for the SPECIFIC STOP-LOSS and AGGREGATE STOP-LOSS pricing rule types. However, the eligibility criteria for the AGGREGATE STOP-LOSS pricing rule type was not satisfied, and therefore it is not used for deriving the transaction legs. The eligibility criteria for SS1 was satisfied, but the eligibility criteria for SS3 was not satisfied. Therefore, in this case, the system creates two transaction legs (i.e. TL1 and TL2) for the claim transaction. For more information about the related pricing rule type eligibility and price item eligibility features, refer to the Related Pricing Rule Type Eligibility and Price Item Eligibility sections, respectively.

Once a transaction leg is created, the effective pricing rule's start date is set as the processing date corresponding to the transaction leg.