Results for “party_status”

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

Overview

CSC_CUSTOMERS_AUDIT_HIST is a Customer Care (CSC) module table in the Oracle E-Business Suite that records the historical progression of a customer's criticality designation. The table captures an audit trail whenever the criticality flag associated with a party or customer account changes, including the identification of the change event, the actor responsible, and any override justification applied. Because customer criticality frequently drives service-level commitments, escalation paths, and prioritization logic in service and order management flows, this table provides the evidentiary record behind those determinations.

From a Data Vault modeling perspective, the mined foreign-key structure suggests a satellite-leaning classification. The table behaves as a dependent, descriptive history store keyed to a parent customer entity (via PARTY_ID) rather than as an independent hub or an associative link. This classification is heuristic and should be treated as a modeling suggestion rather than a documented Oracle design statement.

Key Information Stored

The table contains 36 documented columns. The most significant are:

• CUST_HIST_ID — the surrogate primary key, enforced by CSC_CUSTOMERS_AUDIT_HIST_PK and also carried by the unique index CSC_CUSTOMERS_AUDIT_HIST_U1. This is the row-level identifier for each criticality change event.
• PARTY_ID — foreign key to CSC_CUSTOMERS, identifying the customer party whose criticality changed.
• CUST_ACCOUNT_ID — foreign key to HZ_CUST_ACCOUNTS, tying the change to a specific customer account.
• SECURITY_GROUP_ID — foreign key to FND_SECURITY_GROUPS, governing row-level access control across the multi-org/multi-group model.
• SYS_DET_CRITICAL_FLAG — the system-determined criticality value calculated by application logic.
• OVERRIDE_FLAG — indicates whether the system-determined criticality was manually overridden.
• OVERRIDDEN_CRITICAL_FLAG — the manually substituted criticality value when an override occurred.
• OVERRIDE_REASON_CODE — the coded justification attached to a manual override.
• CHANGED_DATE / CHANGED_BY — when and by whom the criticality change was applied.
• PARTY_STATUS — the party status in effect at the time of the change.
• REQUEST_ID, PROGRAM_APPLICATION_ID, PROGRAM_ID, PROGRAM_UPDATE_DATE — concurrent program context identifying the process that performed the change.
• ATTRIBUTE1–ATTRIBUTE15 and CONTEXT — the standard DFF (descriptive flexfield) columns for extending the record.
• CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN — the standard WHO audit columns.

The surrogate key CUST_HIST_ID is distinct from any business-key candidate; the unique index U1 duplicates the primary key column, meaning no separate composite business key is documented.

Common Use Cases and Queries

The primary use case is reconstructing the criticality history of a customer for dispute resolution, compliance, and service-level forensics. A typical query retrieves the ordered history for a party:

• SELECT CUST_HIST_ID, PARTY_ID, CUST_ACCOUNT_ID, SYS_DET_CRITICAL_FLAG, OVERRIDE_FLAG, OVERRIDDEN_CRITICAL_FLAG, OVERRIDE_REASON_CODE, CHANGED_DATE, CHANGED_BY FROM CSC.CSC_CUSTOMERS_AUDIT_HIST WHERE PARTY_ID = :p_party_id ORDER BY CHANGED_DATE DESC;

Reporting scenarios include identifying the frequency and reasons for manual overrides (grouping by OVERRIDE_REASON_CODE), auditing changes made by a specific user within a date range, and correlating concurrent program runs (via REQUEST_ID) with downstream criticality shifts. Security-conscious queries must filter by SECURITY_GROUP_ID to respect the operating group context.

Related Objects

• CSC_CUSTOMERS — joined on CSC_CUSTOMERS_AUDIT_HIST.PARTY_ID = CSC_CUSTOMERS.PARTY_ID; the parent party record.
• HZ_CUST_ACCOUNTS — joined on CSC_CUSTOMERS_AUDIT_HIST.CUST_ACCOUNT_ID = HZ_CUST_ACCOUNTS.CUST_ACCOUNT_ID; the customer account context.
• FND_SECURITY_GROUPS — joined on SECURITY_GROUP_ID; enforces row-level security.
• FND_CONCURRENT_REQUESTS — joined on REQUEST_ID; identifies the concurrent process responsible for a change.
• FND_USER — joined on CHANGED_BY or CREATED_BY to resolve the acting user.