Clean Up
There might be situations when a transaction is mapped to one or more price items and due to some reasons a billable charge could not be created for one of the price item. And, therefore the status of the transaction is changed to Error (EROR). In such case, you need to either recalculate SQIs in the aggregated billable charge or delete the aggregated billable charge depending on whether the aggregated billable charge includes transaction legs in the Completed (COMP) status. You can perform this clean up process through a multi-threaded batch named Clean Up (C1-TXNCU).
When the transaction legs in the Error (EROR) and Completed (COMP) statuses are aggregated together in a billable charge, the Clean Up (C1-TXNCU) batch does the following:
| Billable charge contain transaction legs with the following set of pricing attributes... | Then.... |
|---|---|
| Ignore Transaction is set to No, Aggregate Transaction is set to Yes, and Rating Criteria is set to Do Not Rate Transactions | The SQIs are recalculated in the billable charge. |
| 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 SQIs are recalculated in the billable charge and the rate is determined for aggregated service quantities. Once the rate is determined, pass through charges are calculated and accumulated accordingly. |
| 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 pass through charges are recalculated and accumulated accordingly. |
However, when the transaction legs in the Error (EROR) status are only aggregated in a billable charge, the Clean Up (C1-TXNCU) batch does the following:
| Billable charge contain transaction legs with the following set of pricing attributes... | Then.... |
|---|---|
| Ignore Transaction is set to No, Aggregate Transaction is set to Yes, and Rating Criteria is set to Do Not Rate Transactions | The aggregated billable charge is 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 aggregated billable charge and the corresponding calculation lines 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 aggregated billable charge is deleted. |
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.
The SQIs in an aggregated billable charge are recalculated only when the SQ Recalculation Required option type in the C1_FM feature configuration is set to Y. If you set the SQ Recalculation Required option type in the C1_FM feature configuration to N, the SQIs are not recalculated in an aggregated billable charge. We recommend you to recalculate SQIs in an aggregated billable charge when more than one account bears the charges for a transaction.
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 TFM - 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.
Besides the transaction aggregation process, the Clean Up (C1-TXNCU) batch is also used during the following sub-processes:
-
Cancellation - During the cancellation process, it deletes non-aggregated billable charges and recalculates SQIs in aggregated billable charges.
-
Disaggregation - During the disaggregation process, it deletes an aggregated billable charge when all the corresponding transaction legs which were aggregated in the billable charge are deleted during disaggregation.
You can specify either of the following parameters while executing the Clean Up (C1-TXNCU) batch:
| Parameter Name | Description | Mandatory (Yes or No) |
|---|---|---|
| Transaction Header ID | Used when you want to update or delete billable charges created
for transactions which are received in a particular transaction feed. Note: This parameter should not be used during the disaggregation process.
|
Yes (Conditional) Note: This parameter is required when you
set the request type to CNCL.
|
| Transaction Source | Used when you want to update or delete billable charges created
for transactions which are received from a particular transaction
source. Note: This parameter should not be used during the cancellation
and disaggregation processes.
|
No |
| Division | Used when you want to update or delete billable charges created
for transactions belonging to a particular division. Note: This parameter
should not be used during the cancellation process.
|
No |
| Account ID | Used when you want to update or delete billable charges created
for transactions of a particular account. Note: This parameter should
be used only during the disaggregation process.
|
No |
| Bill Cycle | Used when you want to update or delete billable charges created
for transactions of accounts having a particular bill cycle. Note: This parameter should be used only during the disaggregation process.
|
No |
| Disaggregate Transactions From Date | Used when you want to update or delete billable charges created
for transactions which were performed from a particular date onwards. Note:
You must specify the date in the YYYY-MM-DD format. This parameter should be used only during the disaggregation process. |
Yes (Conditional) Note: This parameter is required when you
set the request type to DISAGG.
|
| Request Type | Used to indicate the process during which you want to execute
the batch. The valid values are:
|
Yes |
| 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 |
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 |