C1-FIAUDEV
If this algorithm is attached to the Audit system event of the Group Membership (C1-Membership), Individual Membership (C1-IndMembership), Benefit (C1-Benefits), and Person (C1_PERSON_BO) business objects, it is invoked whenever you define, 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 whenever a group membership is added to a policy plan, an individual membership is added to a health plan, member person is added to a group or individual membership, and a membership benefit is added for a group or individual membership. It also creates the audit event whenever the group or individual membership, member person, and membership benefit details are updated. However, note that the audit events are created in the update scenario when the element listed for auditing in the age-based, tier-based, or benefit pricing rule type is updated. The system considers only those pricing rule types whose pricing rules are effective during the respective entity (i.e. group or individual membership, member person, or membership benefit whichever is updated) date range.
It creates one or more audit events in the Pending status. 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.
The system creates an audit event whenever the group or individual membership start and end dates and member person's start and end dates are changed in the system irrespective of whether these fields are listed for auditing or not in the age-based or tier-based pricing rule types.
Before creating an audit event, the system checks whether an audit event for the entity ID with the same effective date already exists in the Pending or Error status for the respective action. If so, the system does not create a new audit event for the entity. Instead, the system adds a new log entry in the existing audit event.
For each audit event, this algorithm derives the group or individual memberships on the policy or health plan, respectively, which is impacted and the pricing rule types whose pricing rules are defined on the respective policy or health plan. A repricing entity detail record is then created 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 Pending. Once the repricing entity detail records are created successfully, the status of the audit event is changed to Complete.
It contains the following parameters:
-
Audit Event Business Object - Used to specify the business object using which you want to create the audit event.
-
Audit Event Pending Status - Used to specify the status in which you want to create the audit event. This parameter is also used for determining whether an audit event for the entity ID already exists in the system.
-
Audit Event Error Status - Used to specify the status in which an audit event is transitioned when an error occurs while processing the audit event. This parameter is used for determining whether an audit event for the entity ID already exists in the system.
All the above parameters are mandatory.
Related Topics
| For more information on... | See... |
|---|---|
| How the audit events are created and processed for an age based or tier based pricing rule | Age Based and Tier Based Pricing Rules Audit Process |
| How the audit events are created and processed for a membership | Membership Audit Process |
| How the audit events are created and processed for a person | Person Audit Process |
| How the audit events are created and processed for a membership benefit | Membership Benefit Audit Process |