Price Item Pricing Verification

In this process, the system behaves in the following manner:

If the Multi Parameter Based Pricing feature is...	Then...
Disabled	The system checks whether effective pricing is available for the account, price item or regular bundle (to which the price item belongs) or parent (regular) bundle (to which the regular bundle belongs) and/or TOU combination on the processing date. The system searches for the price item, regular bundle or parent bundle pricing depending on the value defined for the Prefer Price Item Over Bundle parameter in the price assignment search algorithm (which is defined for the division to which the account belongs). If the price item belongs to a regular bundle and the effective pricing is available for the regular bundle at the account level, the system considers the regular bundle as the final price item and maps it to the transaction leg. If the effective pricing is not available for the regular bundle, the system checks whether the effective pricing is available for the parent bundle (if assigned) at the account level. If the effective pricing is available for the parent bundle, the system considers the parent bundle as the final price item and maps it to the transaction leg. If the effective pricing is not available for the price item, regular bundle, or parent bundle, the status of the transaction leg is changed to Error (EROR). If the effective pricing is not available for one or more price items to which a transaction is mapped, the status of the transaction is also changed to Error (EROR).
Enabled	The system checks whether effective pricing is available for the account, price item or regular bundle (to which the price item belongs) or parent (regular) bundle (to which the regular bundle belongs)and/or price item parameters (parameter group) combination on the processing date. The system searches for the price item, regular bundle or parent bundle pricing depending on the value defined for the Prefer Price Item Over Bundle parameter in the price assignment search algorithm (which is defined for the division to which the account belongs). The system searches for a price with exact match at all levels defined in the search order. If the exact match is available at two or more levels, the price assignment at the higher precedence level is considered for calculating the charges. But, if the system does not find the exact match at any level, it searches for the best fit match at all levels. For more information about best fit match, see Multi Parameter Based Pricing. If the system finds the best fit match with same weight at multiple levels, the price assignment at the higher precedence level is considered for calculating the charges. If the price item belongs to a regular bundle and the exact or best fit price is available for the regular bundle at the account level, the system considers the regular bundle as the final price item and maps it to the transaction leg. If the exact or best fit price is not available for the regular bundle, the system checks whether the exact or best fit price is available for the parent bundle (if assigned) at the account level. If the exact or best fit price is available for the parent bundle, the system considers the parent bundle as the final price item and maps it to the transaction leg. If the exact or best fit price is not available for the price item, regular bundle, or parent bundle, the status of the transaction leg is changed to Error (EROR). If the exact or best fit price is not available for one or more price items to which a transaction is mapped, the status of the transaction is also changed to Error (EROR).

If the Multi Parameter Based Pricing feature is...

Then...

Disabled

The system checks whether effective pricing is available for the account, price item or regular bundle (to which the price item belongs) or parent (regular) bundle (to which the regular bundle belongs) and/or TOU combination on the processing date. The system searches for the price item, regular bundle or parent bundle pricing depending on the value defined for the Prefer Price Item Over Bundle parameter in the price assignment search algorithm (which is defined for the division to which the account belongs).

If the price item belongs to a regular bundle and the effective pricing is available for the regular bundle at the account level, the system considers the regular bundle as the final price item and maps it to the transaction leg. If the effective pricing is not available for the regular bundle, the system checks whether the effective pricing is available for the parent bundle (if assigned) at the account level. If the effective pricing is available for the parent bundle, the system considers the parent bundle as the final price item and maps it to the transaction leg. If the effective pricing is not available for the price item, regular bundle, or parent bundle, the status of the transaction leg is changed to Error (EROR). If the effective pricing is not available for one or more price items to which a transaction is mapped, the status of the transaction is also changed to Error (EROR).

Enabled

The system checks whether effective pricing is available for the account, price item or regular bundle (to which the price item belongs) or parent (regular) bundle (to which the regular bundle belongs)and/or price item parameters (parameter group) combination on the processing date. The system searches for the price item, regular bundle or parent bundle pricing depending on the value defined for the Prefer Price Item Over Bundle parameter in the price assignment search algorithm (which is defined for the division to which the account belongs).

The system searches for a price with exact match at all levels defined in the search order. If the exact match is available at two or more levels, the price assignment at the higher precedence level is considered for calculating the charges. But, if the system does not find the exact match at any level, it searches for the best fit match at all levels. For more information about best fit match, see Multi Parameter Based Pricing. If the system finds the best fit match with same weight at multiple levels, the price assignment at the higher precedence level is considered for calculating the charges.

If the price item belongs to a regular bundle and the exact or best fit price is available for the regular bundle at the account level, the system considers the regular bundle as the final price item and maps it to the transaction leg. If the exact or best fit price is not available for the regular bundle, the system checks whether the exact or best fit price is available for the parent bundle (if assigned) at the account level. If the exact or best fit price is available for the parent bundle, the system considers the parent bundle as the final price item and maps it to the transaction leg. If the exact or best fit price is not available for the price item, regular bundle, or parent bundle, the status of the transaction leg is changed to Error (EROR). If the exact or best fit price is not available for one or more price items to which a transaction is mapped, the status of the transaction is also changed to Error (EROR).

Note:

The processing date which is stamped against a transaction leg is used to determine effective pricing for the transaction leg.

The order in which the system searches effective pricing for the price item, regular bundle, or parent (regular) bundle at the same level depends on the value defined for the Prefer Price Item Over Bundle parameter in the price assignment search algorithm. If the value of the Prefer Price Item Over Bundle parameter is set to Y, the system first searches whether effective pricing is available for the price item. If the effective pricing is not available for the price item, then the system searches whether effective pricing is available for the regular bundle at the same level. If the effective pricing is not available for the regular bundle, then the system searches whether effective pricing is available for the parent bundle at the same level. However, if the value of the Prefer Price Item Over Bundle parameter is set to N, the system first searches whether effective pricing is available for the parent bundle. If the effective pricing is not available for the parent bundle, then the system searches whether effective pricing is available for the regular bundle at the same level. If the effective pricing is not available for the regular bundle, then the system searches whether effective pricing is available for the price item at the same level.

In addition, the status of the transaction and transaction leg is changed to Error (EROR) when:

There is no contract available with the specified contract type on the transaction date or when the contract is inactive.
There are multiple effective contracts of the same contract type (available on the transaction date) in Active, Pending Stop, or Stop status.
The Price Assignment Search algorithm is not defined for the division.
The parameter values are either not defined or invalid in the Price Assignment Search algorithm on the processing date.
The period in which the transaction date falls is not defined in the aggregation schedule.

Once the effective pricing is determined for the initial or final price item, the values of the following pricing attributes are retrieved:

Ignore Transaction
Aggregate Transaction
Aggregation Schedule
Rating Criteria
Price Assignment ID
Account ID (in case of account agreed and price list pricing)
Person ID (in case of customer agreed and price list pricing)
Price List ID (in case of price list pricing)
Contract ID
Regular Bundle Code
Pricing Currency

In addition, the system invokes the algorithms attached to the following algorithm spots of the derived account's division in the specified sequence for the self-funded health insurance business:

TFM - Contract Derivation - You can attach an algorithm created using the SA_DERV_POPC algorithm type to this algorithm spot. If the account has multiple active contracts of the contract type which is associated with the price item, this algorithm derives the contract which is associated with the policy and maps it to the transaction leg. The manner in which the system derives the active contract for the account differs in the following scenarios:

If the effective pricing rule stamped against the transaction leg is defined at ...	Then...
The bill group level	The system first fetches the policy derived for the transaction and then derives the active contract which is associated with the policy.
The parent customer level	The system first fetches the bill group to which the account belongs and then the policy where the bill group is associated with the policy using the policy person role which is specified in the Bill Group Policy Person Role option type of the C1-ASOBLLNG feature configuration. Once the policy is derived, the system derives the active contract which is associated with the policy.

TFM - Verify Pricing Post-Processing - You can attach an algorithm created using the C1-VRPR_POPC algorithm type to this algorithm spot. This algorithm removes the price assignment ID and price item parameter group ID from the summary ID column of each transaction leg.

You can execute this process through a multi-threaded batch named Price Item Pricing Verification (C1-TXNVP). You can specify either of the following parameters while executing this batch:

Parameter Name	Description	Mandatory (Yes or No)
Transaction Header ID	Used when you want to find the price item pricing for transactions which are received in a particular transaction feed.	No
Transaction Source	Used when you want to find the price item pricing for transactions which are received from a particular transaction source.	No
Division	Used when you want to find the price item pricing for transactions belonging to a particular division.	No
Chunk Size	Used to specify the number of transactions you want to execute in each work unit.	Yes
Thread Pool Name	Used to specify the thread pool on which you want to execute the batch.	No

Note that the Price Item Pricing Verification (C1-TXNVP) batch does not change the status of the transaction and its legs. You need to execute the Update Status (C1-TXNEX) batch to update the status of the transaction and its legs. Besides updating the status, the Update Status (C1-TXNEX) batch determines the rate for transaction legs whose effective pricing has either of the following set of attributes:

Ignore Transaction is set to Yes and Rating Criteria is set to Rate Transactions (RITX)
Ignore Transaction is set to No, Aggregate Transaction is set to Yes, and Rating Criteria is set to Rate individual transactions and aggregate calc lines across transactions (RITA)

Each set of pricing attributes indicates how the transaction legs must be rated before billing. For more information about the different ways in which a transaction leg can be rated, see Transaction Rating Before Billing.

You can specify either of the following parameters while executing this batch:

Parameter Name	Description	Mandatory (Yes or No)
Transaction Header ID	Used when you want to change the status of transactions which are received in a particular transaction feed.	No
Transaction Source	Used when you want to change the status of transactions which are received from a particular transaction source.	No
Division	Used when you want to change the status of transactions belonging to a particular division.	No
Shuffle Work Unit	Used to indicate whether you want to shuffle the work units across threads to correct the uneven thread processing time. The valid values are: Y N Note: By default, the parameter value is set to N.	No
Chunk Size	Used to specify the number of transactions you want to execute in each work unit.	Yes
Maximum Batch Count	Used to specify the maximum number of transactions after which the data must be transferred to the database.	Yes
Thread Pool Name	Used to specify the thread pool on which you want to execute the batch.	No

Note:

You must specify same parameters in the Product Pricing Verification (C1-TXNVP) and Update Status (C1-TXNEX) batches. Otherwise, erroneous results might occur.

If you want to do some preprocessing activities before invoking the rates engine, you need to attach a preprocessing algorithm on the TFM - Rate Pre-Processing algorithm entity in the Algorithms tab of the Division screen. Note that the system invokes the algorithm which is attached on the derived account's division and not on the division to which the transaction belongs. A sample preprocessing algorithm type named C1_RTCL_PRPC is shipped with the product. It does not have any business logic. If you want to undertake some preprocessing activities before invoking the rates engine, you need to create custom algorithm type and attach the respective algorithm on the TFM - Rate Pre-Processing algorithm spot of the respective division. You can refer to the C1_RTCL_PRPC algorithm type to understand the input parameters that must be passed to the custom algorithm type.

If a transaction leg is ignored and not considered for billing, the status of the transaction leg is changed to Ignored (IGNR), whereas the status of the transaction remains as Initial Price Item Determined (INPD). However, if all legs of a transaction are ignored and not considered for billing, the status of the transaction and transaction legs is changed to Ignored (IGNR).

You can store the price item pricing information, and thereby improve the Price Item Pricing Verification (C1-TXNVP) batch performance. If you set the Use Materialized Views option type of the C1_FM feature configuration to true, the system will store the product pricing information in the following tables:

CI_PRC_AGRD
CI_PRC_PL
CI_PRC_INH_PL

But, if you set the Use Materialized Views option type of the C1_FM feature configuration to false, the system will not store the product pricing information in the above mentioned tables. If there are any pricing changes, you will have to update these tables before executing the Price Item Pricing Verification (C1-TXNVP) batch. You can update the product pricing information in these tables by executing the Refresh Pricing (C1-TXNRP) batch. Ideally, you must execute the Refresh Pricing (C1-TXNRP) batch after you execute the Flush All Caches (F1-FLUSH) batch in the transaction aggregation cycle. You can specify the following parameters while executing the Refresh Pricing (C1-TXNRP) batch:

Parameter Name	Description	Mandatory (Yes or No)
Division	Used when you want to update the price item pricing information of accounts belonging to a particular division.	No
Chunk Size	Used to specify the number of persons whose regular and post-processing price item pricing information you want to update in each work unit.	Yes
Thread Pool Name	Used to specify the thread pool on which you want to execute the batch.	No

Related Topics

For more information on...	See...
Transaction Leg Status Transition	Transaction Leg Status Transition
How to set the C1_FM feature configuration	Setting the C1_FM Feature Configuration