Disaggregation Request through Audit Event
Until now, the system enabled you to disaggregate transactions when a disaggregation request was created for an account. The system enabled you to manually create a disaggregation request for an account from the user interface. Now, the system enables you to automatically create a disaggregation request for an account through an audit event. The system enables you to create an automatic disaggregation request in the following scenarios:
-
While changing the person’s attributes (i.e. when a person’s fields or characteristics are updated)
-
While changing the account’s attributes (i.e. when an account’s fields or characteristics are updated)
-
While adding or updating a price list
-
While assigning a price list to a person or an account
-
While updating the price list assignment of a person or an account
-
While assigning a price item to a person, account, or price list
-
While updating the price assignment of a person, account, or price list
To enable the automatic disaggregation request creation, you need to do the following:
-
Attach the C1-REAUDEVNT algorithm to the Audit system event of the C1_PERSON_BO, C1_PLASGNEDIT, C1_PRICEASGN_BO, C1_F_ADDPLBO, or C1-AccountBO business object, respectively
-
Set the Eligible for Audit Event option type of the entity business object to Y
-
Define an active audit event type for the entity business object in the system
For more information on how to create an audit event type, refer to the Entity Audit section in Oracle Revenue Management and Billing Banking User Guide or Oracle Revenue Management and Billing Insurance User Guide.
If the C1-REAUDEVNT algorithm is attached to the Audit system event of a business object, it is invoked whenever you create, edit, or delete the respective entity. It checks whether an active audit event type exists for the entity business object. If so, it considers the active audit event type and creates the audit event using the respective audit event type. The system creates the audit event while:
-
Creating an entity when the Add Action option is selected in the audit event type
-
Editing an entity when the Update All option is selected in the audit event type or when the updated element is listed in the Audit Elements for Entity Update section
-
Deleting an entity when the Delete Action option is selected in the audit event type
The entity type and entity ID for which an audit event is created are added corresponding to the audit event in the C1_AUDIT_EVENT table. In addition, the effective date is stamped corresponding to the audit event in the C1_AUDIT_EVENT table. Note that if the entity has a start date, then the effective date is set to the entity's start date. But, if the entity does not have a start date, then the effective date is set to the system date.
Once the audit event is created in the Pending status, you need to execute the Disaggregation Request through Audit Event (C1-DISTA) batch. Until now, the Disaggregation Request through Audit Event (C1-DISTA) batch was used to process audit events which are created for a self-funded pricing rule. Now, this batch is used to process the audit events which are created for the persons, accounts, self-funded pricing rules, price lists, price list assignments, and price assignments.
Once a disaggregation request is created for an audit event, you need to execute the following batches in the specified sequence:
-
Pending Bill Segments Deletion (C1-BSEGD)
-
Pending Bill Deletion (C1-PNBD)
-
Identify Transactions for Disaggregation (C1-IDENT)
-
Process Non-Aggregated Transactions (C1-PDTXN)
-
Clean Up (C1-TXNCU) with the Request Type parameter set to DISAGG
-
Update Disaggregation Request Status (C1-DRSUA)