Results for “inc_creation_date”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

CS_INCIDENTS_PURGE_AUDIT_B is an audit table in the CS (Service) product schema of Oracle E-Business Suite, valid in both 12.1.1 and 12.2.2. It stores the audit trail produced by the Service Request Data Purge concurrent program. When that program removes eligible service request (incident) records from the operational CS tables, it writes a corresponding row into this table to record which incidents were purged, when, and by whom. The table therefore serves as a historical record that supports compliance, troubleshooting, and reconciliation after destructive purge operations.

Within a Data Vault-style model, the metadata's heuristic classification suggests a link table, since the structure is dominated by foreign key relationships to external entities (incidents, incident types, parties, and item instances) rather than by descriptive attributes. Note that this classification is a modeling suggestion derived from the FK topology; in EBS practice the table functions principally as an operational audit log keyed to the purged incident.

Key Information Stored

The table carries 17 documented columns. The most significant are listed below.

• PURGE_ID — the internal purge identifier that anchors each purge execution record.
• INCIDENT_ID — the surrogate primary key and the incident identifier; it is also the single column of unique index CS_INCIDENTS_PURGE_AUD_B_U1, making it the effective business-key candidate and the join point back to the source incident.
• INCIDENT_NUMBER — the user-facing service request number, retained so consumers can reference the purge historically without joining to the purged base table.
• INCIDENT_TYPE_ID — reference to the incident type of the purged record.
• CUSTOMER_ID — reference to the party (customer) associated with the purged incident.
• INVENTORY_ITEM_ID and INV_ORGANIZATION_ID — the inventory item and operating unit context of the affected product configuration.
• CUSTOMER_PRODUCT_ID — reference to the customer product (item instance) linked to the purge.
• INC_CREATION_DATE and INC_LAST_UPDATE_DATE — the original creation and last-update timestamps of the incident at the time of purge.
• PURGED_DATE and PURGED_BY — when and by which user the purge was executed.
• CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY, and LAST_UPDATE_LOGIN — standard EBS WHO-column audit metadata for the audit row itself.

Common Use Cases and Queries

Typical uses include confirming whether a specific service request was purged, reporting purge activity over a period, and validating purge volumes for governance. A representative query counting purges by operator within a date range follows:

SELECT purged_by, COUNT(*) purged_count
FROM   cs.cs_incidents_purge_audit_b
WHERE  purged_date BETWEEN :from_date AND :to_date
GROUP  BY purged_by;

To reconstruct detail for a given incident, join the audit row to reference entities:

SELECT a.incident_number, t.name incident_type,
       p.party_name, a.purged_date, a.purged_by
FROM   cs.cs_incidents_purge_audit_b a,
       cs.cs_incident_types_b t,
       hz_parties p
WHERE  a.incident_type_id = t.incident_type_id
AND    a.customer_id     = p.party_id
AND    a.incident_id     = :incident_id;

Related Objects

• CS_INCIDENTS_ALL_B — joined on INCIDENT_ID; the base service request table whose purged rows this audit references.
• CS_INCIDENT_TYPES_B — joined on INCIDENT_TYPE_ID for incident type descriptions.
• HZ_PARTIES — joined on CUSTOMER_ID for customer (party) identity.
• CSI_ITEM_INSTANCES — joined on CUSTOMER_PRODUCT_ID for the installed base instance.
• CS_INCIDENTS_ALL_TL and related incident child tables — operational companions to the base table affected by the same purge program.
• Service Request Data Purge concurrent program — the process that populates this table.