Bill Group Derivation and Pricing Parameters Audit Process

If you add or edit the derivation and pricing parameters for a bill group, the system checks whether an active audit event type exists for the C1-BillLevel business object. If an active audit event type exists for the business object, the system creates an audit event for the bill level ID (i.e. bill group and sort ID combination) using the audit event type. The audit event is created in the Pending status. Note that the system creates one audit event for a bill group and sort ID combination irrespective of the number of changes made to the bill group and sort ID combination. In addition, an effective date is stamped corresponding to the audit event which later helps in deriving the timeline during premium calculation. Note that the effective date is set to the date from when the derivation and pricing parameters are effective for the bill group and sort ID combination.

For example, a parent customer named PC1 has two bill groups - BG1 and BG2 and the derivation and pricing parameters are edited for the following combinations:

In such case, the system will create four audit events - one for BG1 and 10 combination with the effective date as 01-01-2019, another for BG1 and 20 combination with the effective date as 07-01-2019, third for BG2 and 10 combination with the effective date as 01-01-2019, and fourth for BG2 and 20 combination with the effective date as 05-01-2019.

On executing the Audit Event Process Monitor (C1-AUDEV) batch, the system considers the audit events in the Pending or Error status. By default, it considers the audit events in the Pending status. The system checks whether the C1-AUDBILLVL algorithm is attached to the respective audit event type. If the C1-AUDBILLVL algorithm is attached to the audit event type, it identifies the parent customer of the bill group for whom the derivation and pricing parameters are defined or edited. It then considers all policies of the parent customer and its bill groups and extracts a list of memberships defined on the respective policy plans. It also identifies the active pricing rules on these policy plans and the pricing rule types using which these active pricing rules are created in the system. The system then checks whether the characteristic types specified in the bill group derivation algorithm on each pricing rule type are defined on any extracted list of membership. If so, the system then checks whether the characteristic values match the derivation and pricing parameters of the bill group. If one or more characteristic values do not match the derivation and pricing parameters of the bill group, the system creates a repricing entity detail record for each membership, pricing rule type, and effective date combination in the CI_​REPRC_​ENTITY_​DTL table. The status of the repricing entity detail record is set to P.

Let us understand this with the help of an example.

In such case, the system creates four audit events - AE1 for BG1 and 10 combination with the effective date as 01-01-2019, AE2 for BG1 and 20 combination with the effective date as 01-01-2019, AE3 for BG2 and 10 combination with the effective date as 01-01-2019, and AE4 for BG2 and 20 combination with the effective date as 01-01-2019.

Now, let us assume that...

• PC1 has two policies - P1 (where no bill group is associated) and P2 (where BG1 is associated)

• BG1 has one policy named P2 (where PC1 is the policy holder)

• P1 has one plan named PP1 and P2 has one plan named PP2

• PP1 has two memberships - M1 and M2,

• PP2 has three memberships - M3, M4, and M5

• PRT1 and PRT2 are associated with PP1

• PRT3 is associated with PP2

• PP1 has two active pricing rules - PR1 (which is created using PRT1) and PR2 (which is created using PRT2)

• PP2 has one active pricing rule - PR3 (which is created using PRT3)

In such case, the system will create the repricing entity detail records for each audit event in the CI_​REPRC_​ENTITY_​DTL table.

Once the repricing entity detail records are created successfully, the status of the audit event is set to Complete. However, if an error occurs while creating the repricing entity detail records for an audit event, the status of the audit event is set to Error.