Aggregation

Once the price item pricing verification is complete, you can aggregate the transaction legs, create a billable charge, and update the SQI values in the billable charge. In the aggregation process, the system behaves in the following manner:

If the Multi Parameter Based Pricing feature is...	Then...
Disabled	The system checks the value defined in the Aggregate Transaction field. If the Aggregate Transaction field is set to No, the system creates one billable charge (with the Billable status) for each transaction leg. However, if the Aggregate Transaction field is set to Yes, the system creates one billable charge (with the Billable status) for all transactions legs having the same price item and TOU combination and whose transaction date falls between the aggregation schedule. Note: During the billable charge creation, the system also considers the contract start and end dates along with the aggregation schedule. If the contract start date falls between the aggregation schedule, the billable charge start date is equal to the contract start date. If the contract start date is earlier than the aggregation schedule start date, the billable charge start date is equal to the aggregation schedule start date. If the contract end date is earlier than the aggregation schedule end date, the billable charge end date is equal to the contract end date. If the contract end date is later than the aggregation schedule end date, the billable charge end date is equal to the aggregation schedule end date. However, if the contract start date is later than the aggregation schedule end date or if the contract end date is earlier than the aggregation schedule start date, the status of the transaction leg is changed to Error (EROR). If the aggregated billable charge already exists for the account, price item and TOU combination and there is no bill segment associated with the billable charge, the system will update the SQI values in the existing billable charge.
Enabled	The system checks the value defined in the Aggregate Transaction field. If the Aggregate Transaction field is set to No, the system creates one billable charge (with the Billable status) for each transaction leg. However, if the Aggregate Transaction field is set to Yes, the system creates one billable charge (with the Billable status) for all transaction legs having the same price item and price item parameters (parameter group) combination and whose transaction date falls between the aggregation schedule. Note: During the billable charge creation, the system also considers the contract start and end dates along with the aggregation schedule. If the contract start date falls between the aggregation schedule, the billable charge start date is equal to the contract start date. If the contract start date is earlier than the aggregation schedule start date, the billable charge start date is equal to the aggregation schedule start date. If the contract end date is earlier than the aggregation schedule end date, the billable charge end date is equal to the contract end date. If the contract end date is later than the aggregation schedule end date, the billable charge end date is equal to the aggregation schedule end date. However, if the contract start date is later than the aggregation schedule end date or if the contract end date is earlier than the aggregation schedule start date, the status of the transaction leg is changed to Error (EROR). If the aggregated billable charge already exists for the account, price item and price item parameters combination and there is no bill segment associated with the billable charge, the system will update the SQI values in the existing billable charge.

If the Multi Parameter Based Pricing feature is...

Then...

Disabled

The system checks the value defined in the Aggregate Transaction field. If the Aggregate Transaction field is set to No, the system creates one billable charge (with the Billable status) for each transaction leg. However, if the Aggregate Transaction field is set to Yes, the system creates one billable charge (with the Billable status) for all transactions legs having the same price item and TOU combination and whose transaction date falls between the aggregation schedule.

Note:

During the billable charge creation, the system also considers the contract start and end dates along with the aggregation schedule. If the contract start date falls between the aggregation schedule, the billable charge start date is equal to the contract start date. If the contract start date is earlier than the aggregation schedule start date, the billable charge start date is equal to the aggregation schedule start date. If the contract end date is earlier than the aggregation schedule end date, the billable charge end date is equal to the contract end date. If the contract end date is later than the aggregation schedule end date, the billable charge end date is equal to the aggregation schedule end date. However, if the contract start date is later than the aggregation schedule end date or if the contract end date is earlier than the aggregation schedule start date, the status of the transaction leg is changed to Error (EROR).

If the aggregated billable charge already exists for the account, price item and TOU combination and there is no bill segment associated with the billable charge, the system will update the SQI values in the existing billable charge.

Enabled

The system checks the value defined in the Aggregate Transaction field. If the Aggregate Transaction field is set to No, the system creates one billable charge (with the Billable status) for each transaction leg. However, if the Aggregate Transaction field is set to Yes, the system creates one billable charge (with the Billable status) for all transaction legs having the same price item and price item parameters (parameter group) combination and whose transaction date falls between the aggregation schedule.

Note:

If the aggregated billable charge already exists for the account, price item and price item parameters combination and there is no bill segment associated with the billable charge, the system will update the SQI values in the existing billable charge.

The transaction aggregation is done based on the aggregation schedule defined in the price item pricing. You can use the following standard schedules or you can create your own custom schedules for aggregation:

Daily
Weekly
Monthly
Quarterly
Yearly

Once the billable charge is created, the system aggregates the SQIs defined for the price item - division combination using the aggregation function and then updates the billable charge with the respective SQI values. If the aggregation function is based on the transaction amount or on any other user defined amount and the transaction or user defined currency is different from the pricing currency, the system does currency conversion if the appropriate exchange rate is available in the system. The processing date which is stamped against a transaction leg is used to determine effective exchange rate for the transaction leg.

Once the SQI values are updated in the billable charge, the rate is determined for the transaction leg whose effective pricing has either of the following set of attributes:

Ignore Transaction is set to No, Aggregate Transaction is set to Yes, and Rating Criteria is set to Aggregate transactions and then rate aggregated SQs (AGTR)
Ignore Transaction is set to No, Aggregate Transaction is set to No, and Rating Criteria is set to Rate Transactions (RITX)

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.

Note: If you want to do some preprocessing activities while determining rate, 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 price item. It does not have any business logic. If you want to undertake some preprocessing activities while determining rate for transaction legs, 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.

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

TFM - Billable Charge Post Processing - You can attach an algorithm created using the C1_BCHG_POPC algorithm type to this algorithm spot. This algorithm invokes the algorithm which is attached to the Bill After Date Determination system event of the respective pricing rule type. For more information, refer to the Bill After Date Determination section.

Once the billable charge is created and updated successfully, the status of the transaction leg is changed to Completed (COMP). However, if the SQIs are not defined for the price item - division combination, the transaction aggregation rule is not defined for the SQI, or if the exchange rate is not available during currency conversion, the status of the transaction leg is changed to Error (EROR). If all legs of a transaction are in the Completed (COMP) status, the status of the transaction is changed to Completed (COMP). But, if any of the transaction leg is in the Error (EROR) status, the status of the transaction is changed to Error (EROR).

You can execute this process through a multi-threaded batch named Service Quantity Calculation (C1-TXNSQ). 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 create the billable charges for transactions which are received in a particular transaction feed.	No
Transaction Source	Used when you want to create the billable charges for transactions which are received from a particular transaction source.	No
Division	Used when you want to create the billable charges 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
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

The Service Quantity Calculation (C1-TXNSQ) batch does not change the status of the transaction and its legs. You need to execute the Mark Completion (C1-TXNCM) batch to update the status of the transaction and its legs. Besides updating the status, the Mark Completion (C1-TXNCM) batch does the following with other legs when billable charge is not created for one or more transaction legs:

Rate for other transaction leg is determined using the following set of pricing attributes...	Then....
Ignore Transaction is set to Yes and Rating Criteria is set to Rate Transactions (RITX)	The corresponding calculation lines of the transaction leg are deleted.
Ignore Transaction is set to No, Aggregate Transaction is set to No, and Rating Criteria is set to Rate Transactions (RITX)	The corresponding billable charge and calculation lines of the transaction leg are deleted.
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)	The corresponding calculation lines of the transaction leg are deleted.
Ignore Transaction is set to No, Aggregate Transaction is set to Yes, and Rating Criteria is set to Aggregate transactions and then rate aggregated SQs (AGTR)	The corresponding billable charge and calculation lines are not deleted.
Ignore Transaction is set to No, Aggregate Transaction is set to No, and Rating Criteria is set to Do Not Rate Transactions	The corresponding non-aggregated billable charge is deleted.

You can specify either of the following parameters while executing the Mark Completion (C1-TXNCM) 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
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 Service Quantity Calculation (C1-TXNSQ) and Mark Completion (C1-TXNCM) batches. Otherwise, erroneous results might occur.

If you want to perform some post-processing activities on a billable charge, you need to attach a post-processing algorithm on the TFM - Billable Charge Post-Processing algorithm entity in the Algorithms tab of the Division screen. This algorithm is triggered once the billable charge is created and SQIs are updated in the billable charge. 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 post-processing algorithm type named C1_BCHG_POPC is shipped with the product. It does not have any business logic. If you want to undertake some post-processing activities on a billable charge, you need to create custom algorithm type and attach the respective algorithm on the Feed Management Billable Charge Post-Processing algorithm spot of the respective division. You can refer to the C1_BCHG_POPC algorithm type to understand the input parameters that must be passed to the custom algorithm type.

Related Topics

For more information on...	See...
Transaction Leg Status Transition	Transaction Leg Status Transition