Self-Funded Pricing Rule Versioning

Until now, the system enabled you to edit a self-funded pricing rule when it is not referred for any transaction in the system. If you wanted to edit a referred pricing rule, you had to manually cancel bill segments of the accounts and create the disaggregation and/or reseeding requests for the accounts. Once the transactions are disaggregated, the system allowed you to edit the self-funded pricing rule.

Now, the system enables you to edit a self-funded pricing rule even when it is referred for a transaction in the system. On editing a referred self-funded pricing rule, the system will do the following:

• Automatically cancel the bill segments of the accounts and create the disaggregation and/or reseeding requests for the accounts

• Increment the version of the referred self-funded pricing rule in the system

Now, the system maintains version numbers for a self-funded pricing rule. On creating a self-funded pricing rule, the version number of the self-funded pricing rule is set to 1. Also, when a self-funded policy is renewed, the version number of each self-funded pricing rule is set to 1.

If a self-funded pricing rule is referred for a transaction, the system creates a new version of the self-funded pricing rule when you edit it. The system does versioning of a self-funded pricing rule when a set of pre-defined fields are edited. For more information about the fields for which versioning is configured, refer to Oracle Revenue Management and Billing Insurance User Guide. The system will automatically cancel the bill segments and create the disaggregation and/or reseeding requests for the accounts when you implement the Entity Audit feature for the self-funded pricing rules. The entity audit framework is configured for the following business objects in this release:

• C1-PricingRuleAncillary

• C1-PricingRuleClaim

• C1-PricingRuleRetEnroll

• C1-PricingRuleRetTypeClaim

• C1-PricingRuleASL

• C1-PricingRuleSSL

• C1-PricingRuleLevelFunded

• C1-PricingRuleDiscArrangement

The Eligible for Audit Event option type in all the above listed business objects is set to Y and the C1-PRVERSION algorithm is attached to the Audit system event of the above listed business objects.

To implement the Entity Audit feature, you need to create an active audit event type for the above listed business objects where the audit usage is set to Disaggregation/Reseeding. Here, you need to specify a list of fields from the respective business object which you want to audit or monitor. The following audit event types are shipped for the respective pricing rule business object:

You can use the above audit event types or create a custom audit event type for the required business object. On editing a referred self-funded pricing rule, the system does the following:

Note that the new version of the self-funded pricing rule will have the same pricing rule ID. However, on editing a self-funded pricing rule which is not referred for a transaction, the system edits the existing version of the self-funded pricing rule and does not create a new version of the self-funded pricing rule with incremental version number.

A new batch named C1-DISTA is introduced in this release. The C1-DISTA batch checks whether there are any audit events for the self-funded pricing rules in the Pending status. If an audit event for a self-funded pricing rule is in the Pending status, the system checks whether the self-funded pricing rule is created using a primary pricing rule type. If so, the system derives the person for whom the self-funded pricing rule is created. If the person type of the derived person is Parent Customer, the system fetches all accounts of the parent customer and its bill groups. However, if the person type of the derived person is Bill Group, the system fetches all accounts of the bill group. Once the accounts are derived, the system cancels the bill segments of the accounts and creates a disaggregation request for these accounts. The system then confirms whether you want to create reseeding requests for the related pricing rule types (if any). If you click the OK button, the system creates the reseeding requests. While creating a reseeding request for a related pricing rule type, the system derives all accounts from the accumulation group and then creates a reseeding request for each such account. Finally, the batch changes the status of the audit event to Complete.

Once the disaggregation and reseeding requests are created for the accounts, you need to disaggregate the transactions using the disaggregation batches. On executing the C1-DRSUA batch, the system changes the status of the disaggregation or reseeding request to Complete and then executes the C1-UPDAUDEVE algorithm attached to the Post-Processing system event of the batch control. This algorithm changes the status of the new version of the self-funded pricing rule (for which disaggregation is completed) to Active and changes the status of the old version of the self-funded pricing rule to Inactive.

Note that you cannot edit a self-funded pricing rule in the Active status when an audit event for the self-funded pricing rule is in the Pending status. You cannot edit or delete a self-funded pricing rule which is in the Disaggregation Initiated status. Also, you cannot edit the related self-funded pricing rule in the Active status when the new version of the primary self-funded pricing rule is in the Disaggregation Initiated status.