Transaction Disaggregation

As the aggregation cycle is different from the billing cycle, there might be situations when due to pricing changes, the billable charges are no longer valid. In such cases, you need to disaggregate the transactions. In the following scenarios, the system automatically creates a disaggregation request in the CI_​TXN_​DISAGG_​REQ table:

However, there are various other scenarios for which you have to disaggregate the transactions. But, at the moment, the system does not automatically create a disaggregation request for these scenarios in the CI_​TXN_​DISAGG_​REQ table. You will have to create an appropriate disaggregation request in this table. The system allows you to create a disaggregation request manually through the Disaggregation Request screen or through a batch named Disaggregation Request Creation (C1-DISTG).

In the following scenarios, you have to create an appropriate disaggregation request for the account or person, respectively:

• Effective price item pricing assigned to an account is overridden.

• Variance parameter in the price item pricing assigned to an account is changed.

• A price list assignment has expired or a price list is no longer available to an account.

• Effective price item pricing assigned to a person is overridden.

• Variance parameter in the price item pricing assigned to a person is changed.

• A price list assignment has expired or a price list is no longer available to a person.

• A price item is added to a price list.

• The following details in the price item pricing assigned to a price list is changed:

  • Variance Parameter

  • Effective Start Date

  • Effective End Date

  • Aggregation Schedule

  • Ignore Transaction

  • Rating Criteria

  • Aggregate Transaction

• A new bundle is created.

• A price item is added to a bundle.

• A price item is removed from a bundle.

• A bundle is eliminated (that is, all its price item are removed).

• A price item is added.

• A price list hierarchy is changed.

• SQIs associated with a price item - division combination are changed.

• Transaction aggregation rule defined for an SQI is changed or deleted.

• Business rules used for initial price item mapping are changed.

At present, the system disaggregates transactions at the account level and not at the price item level. Let us understand this with the help of an example. The following table lists the accounts and price items to which T1 is mapped:

Now, if the pricing of P1 assigned to A1 changes, the system creates a disaggregation request for A1 and identifies all transaction legs which are mapped to A1 for disaggregation. In this example, the system will consider the first two transaction legs - T1-A1-P1 and T1-A1-P2 - for disaggregation even if the pricing of P2 assigned to A1 has not changed.

The Disaggregation Request Creation (C1-DISTG) batch creates a disaggregation request for an account. When you create a disaggregation request for an account, the transactions mapped to the account are disaggregated. This batch is a multi-threaded batch. The multi-threading is based on account ID and chunks for multi-threading are created based on numerical distribution of account ID. You can specify either of the following parameters while executing this batch:

Before you proceed with the disaggregation process, you need to ensure that there are no pending bills for the accounts whose transactions need to be disaggregated. If there are pending bills for these accounts, you need to first execute the Pending Bill Segments Deletion (C1-BSEGD) batch and then execute the Pending Bill Deletion (C1-PNBD) batch. While executing these batches in the specified order, ensure that you specify the same parameters in both these batches. For more information about these batches, see Oracle Revenue Management and Billing Batch Execution Guide.

Once a disaggregation request is either manually or automatically created for an account, you need to execute the following batches in the specified order to disaggregate transactions:

• Identify Transactions for Disaggregation (C1-IDENT) - This batch fetches disaggregation requests which are created for accounts from the CI_​TXN_​DISAGG_​REQ table. It identifies the transactions and the corresponding aggregated and non-aggregated billable charges for disaggregation. If the bill segment of a billable charge is in the Pending Cancel or Frozen status, the system will not identify the billable charge for deletion. You can specify either of the following parameters while executing this batch:

  Parameter Name	Description	Mandatory (Yes or No)
  Division	Used when you want to identify the transactions of accounts belonging to a particular division for disaggregation.	No
  Account ID	Used when you want to identify the transactions of a particular account for disaggregation.	No
  Bill Cycle	Used when you want to identify the transactions of accounts having a particular bill cycle for disaggregation.	No
  Disaggregate Transactions From Date	Used when you want to identify the transactions which were performed from a particular date onwards for disaggregation. Note: You must specify the date in the YYYY-MM-DD format. The aggregated billable charge, which is affected, should not contain a transaction leg whose transaction date is earlier than the date specified in this parameter. Otherwise, erroneous results will occur. Therefore, ensure that you specify the appropriate value for the Disaggregate Transactions From Date parameter.	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
  Post-Processing Algorithm	Used to attach a post-processing algorithm. This algorithm is triggered once the transactions and corresponding billable charges are identified for disaggregation.	No
  Exclude Canceled Billable Charges (Y or N)	Used to indicate whether you want to exclude the aggregated and non-aggregated billable charges which are in the Canceled status during the disaggregation process. The valid values are: Y N Note: If you do not specify any value, by default, the parameter value is set to N.	No
  Thread Pool Name	Used to specify the thread pool on which you want to execute the batch.	No

• Process Non-Aggregated Transactions (C1-PDTXN) - This batch processes the identified transactions, deletes the required transaction legs, and changes the status of the transaction to Uploaded (UPLD). If a non-aggregated billable charge exists for a transaction leg and the corresponding bill segment is in the Cancel status, then:

  • The billable charge is cancelled.

  • The corresponding transaction leg and calculation lines (if any) are deleted.

  • The status of the transaction is changed to Uploaded (UPLD).

  However, if a non-aggregated billable charge exists for a transaction leg, but if the bill segment is not yet generated, then the billable charge, the corresponding calculation lines (if any), and transaction leg are deleted, and the status of the transaction is changed to Uploaded (UPLD). If a non-aggregated billable charge is in the Cancel status, then the corresponding transaction leg and calculation lines (if any) are deleted and the status of the transaction is changed to Uploaded (UPLD). If the rate is determined for a transaction leg which is in the Ignored (IGNR) status, the calculation lines are deleted along with the transaction leg during disaggregation.

  If aggregated billable charge exists for a transaction leg, then the corresponding transaction legs and calculation lines (if any) are deleted and the status of the transaction is changed to Uploaded (UPLD). You can specify either of the following parameters while executing this batch:

  Parameter Name	Description	Mandatory (Yes or No)
  Division	Used when you want to disaggregate the transactions of accounts belonging to a particular division.	No
  Account ID	Used when you want to disaggregate the transactions of a particular account.	No
  Bill Cycle	Used when you want to disaggregate the transactions of accounts having a particular bill cycle.	No
  Disaggregate Transactions From Date	Used when you want to disaggregate the transactions which were performed from a particular date onwards. Note: You must specify the date in the YYYY-MM-DD format.	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

  Note:

  If you want to undertake some preprocessing activities (such as cleaning data in any custom tables) during the disaggregation process, you need to attach a preprocessing algorithm on the TFM - Disaggregation Pre-Processing algorithm entity in the Algorithms tab of the Division screen. This algorithm is triggered when you execute the Process Non-Aggregated Transactions (C1-PDTXN) batch. 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_​DSAG_​PRPC is shipped with the product. It does not have any business logic. If you want to undertake some preprocessing activities during the disaggregation process, you need to create custom algorithm type and attach the respective algorithm on the TFM - Disaggregation Pre-Processing algorithm spot of the respective division. You can refer to the C1_​DSAG_​PRPC algorithm type to understand the input parameters that must be passed to the custom algorithm type.

• Clean Up (C1-TXNCU) - This batch deletes an aggregated billable charge when all the corresponding transaction legs which were aggregated in the billable charge are deleted during disaggregation. If an aggregated billable charge exists for a transaction leg and the corresponding bill segment is in the Cancel status, then:

  • The billable charge is cancelled.

  • The status of the transaction is changed to Uploaded (UPLD).

  However, if an aggregated billable charge exists for a transaction leg, but if the bill segment is not yet generated, then the billable charge, and the corresponding calculation lines (if any) are deleted, and the status of the transaction is changed to Uploaded (UPLD). If an aggregated billable charge is in the Cancel status, then the corresponding calculation lines (if any) are deleted and the status of the transaction is changed to Uploaded (UPLD).

  While executing the Clean Up (C1-TXNCU) batch during disaggregation, you must set the Request Type parameter to DISAGG. For more information about the parameters that you can specify while executing this batch, refer to Clean Up.

• Update Disaggregation Request Status (C1-DRSUA) - This batch changes the status of the disaggregation request in the CI_​TXN_​DISAGG_​REQ table to COMPLETE. You can specify either of the following parameters while executing this batch:

  Parameter Name	Description	Mandatory (Yes or No)
  Account ID	Used when you want to update the disaggregation requests’ status of a particular account.	No
  Division	Used when you want to update the disaggregation requests’ status of accounts belonging to a particular division.	No
  Bill Cycle	Used when you want to update the disaggregation requests’ status of accounts having a particular bill cycle.	No
  Disaggregate Transactions From Date	Used when you want to update the disaggregation requests’ status of accounts whose transactions were performed from a particular date onwards and the bill segments created for these transactions are in the Pending Cancel or Frozen status. Note: You must specify the date in the YYYY-MM-DD format.	Yes
  Chunk Size	Used to specify the number of transactions you want to execute in each work unit.	Yes
  Update Status Algorithm	Used to attach a custom algorithm which indicates when the status of the disaggregation request in the CI_​TXN_​DISAGG_​REQ table must be changed to COMPLETE. Note: If an algorithm is specified in this parameter, the system uses the custom logic and not the in-built logic for updating the status of the disaggregation requests.	No
  Exclude Canceled Billable Charges (Y or N)	Used to indicate whether you want to change the status of the disaggregation request to COMPLETE when the canceled billable charges are excluded during the disaggregation process. The valid values are: Y N Note: If you do not specify any value, by default, the parameter value is set to N. You must specify the same value for this parameter while executing the Identify Transactions for Disaggregation (C1-IDENT) and Update Disaggregation Request Status (C1-DRSUA) batches during the disaggregation process. Otherwise, erroneous results will occur.	No
  Thread Pool Name	Used to specify the thread pool on which you want to execute the batch.	No

Related Topics