Results for “csc_cust_plans_audit_v”

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

Overview

The CSC_CUST_PLANS_AUDIT_V view is an APPS-owned database view within the CSC (Customer Care) product module of Oracle E-Business Suite, valid in both 12.1.1 and 12.2.2. It exposes audit information for customer plans maintained by the Customer Care application. The view is defined over the CSC_CUST_PLANS_AUDIT base table and is documented as being used within the lock row event of server-side APIs, meaning it primarily supports programmatic access to plan audit records rather than end-user reporting directly. Its design reinforces the audit trail semantics of the underlying table while enriching the raw audit rows with descriptive attributes drawn from related plan, party, customer account, lookup, and user objects, so that developers and integrators can present audit data in a human-readable and referentially meaningful form.

Underlying Base Objects

The view is constructed by joining the audit table CSC_CUST_PLANS_AUDIT (referenced through a synonym) to several supporting objects. CSC_PLAN_HEADERS_VL supplies the plan name and plan group code, while CSC_LOOKUPS is joined twice to translate the plan group code and plan status code into their descriptive meanings under the lookup types CSC_PLAN_GROUP and CSC_PLAN_STATUS. FND_USER provides the user name for the last updater. HZ_PARTIES and HZ_CUST_ACCOUNTS supply party number, party name, party type, account number, and account name. All base references are documented as synonyms or views in the APPS schema, and the joins form the row-level context for each audit entry. Notably, the joins to CSC_LOOKUPS for the plan group code are outer joins (denoted by the (+) operator), so plans lacking a matching group code are still returned.

Key Columns

• ROW_ID — the ROWID of the underlying audit row, often used by APIs for row locking.
• PLAN_AUDIT_ID, PLAN_ID — the audit record identifier and the associated customer plan identifier.
• PARTY_ID, PARTY_NUMBER, PARTY_NAME, PARTY_TYPE — party attributes derived from HZ_PARTIES.
• CUST_ACCOUNT_ID, ACCOUNT_NUMBER, ACCOUNT_NAME — customer account attributes from HZ_CUST_ACCOUNTS.
• PLAN_GROUP_CODE, GROUP_NAME — the plan group code and its lookup meaning (CSC_PLAN_GROUP).
• PLAN_NAME — the descriptive plan name from CSC_PLAN_HEADERS_VL.
• PLAN_STATUS_CODE, PLAN_STATUS_MEANING — the status code and its lookup meaning (CSC_PLAN_STATUS).
• REQUEST_ID, PROGRAM_APPLICATION_ID, PROGRAM_ID, PROGRAM_UPDATE_DATE — concurrent program context for the creating process.
• CREATION_DATE, LAST_UPDATE_DATE, CREATED_BY, LAST_UPDATED_BY, USER_NAME, LAST_UPDATE_LOGIN — standard audit columns, with USER_NAME resolved from FND_USER.
• ATTRIBUTE1 – ATTRIBUTE15, ATTRIBUTE_CATEGORY — flexible descriptive flexfield columns carried through from the audit table.
• OBJECT_VERSION_NUMBER — optimistic locking column.

Common Use Cases and Queries

Typical usage centres on tracing who changed a customer plan, when, and to what status, while simultaneously surfacing party and account context. Because the view is used in the lock row event of server-side APIs, it may be queried to retrieve the current ROW_ID for concurrency control. A representative query returning recent audit entries for a given plan is:

SELECT plan_id, plan_name, plan_status_meaning, party_name, account_number, user_name, last_update_date FROM csc_cust_plans_audit_v WHERE plan_id = :p_plan_id ORDER BY last_update_date DESC;

Analysts may also filter by status meaning or group name to reconcile plan state transitions, or join the view back to CSC_CUST_PLANS_AUDIT for the full audit history. Integration code commonly selects ROW_ID alongside OBJECT_VERSION_NUMBER before performing an update, ensuring that the locked row has not been modified by another session.