Search Results csc_cust_plans_audit_pkg




Overview
Explore in AI Chat

Overview

CSC_CUST_PLANS_AUDIT_PKG is an Oracle E-Business Suite PL/SQL package owned by the APPS schema that provides the low-level data manipulation and locking interface for the Customer Plans Audit entity within the Customer Care (CSC) product family. In EBS 12.1.1 and 12.2.2, Customer Plans support the definition, assignment, and tracking of service plans, entitlements, and related customer commitments. Because changes to plan definitions and plan assignments carry contractual and financial consequences, the application maintains a dedicated audit trail. This package encapsulates the Create, Update, Lock, and Delete operations against that audit schema, isolating the audit-table mechanics from the higher-level Customer Plans business logic implemented in CSC_CUST_PLANS_PVT.

The package is classified in the ETRM repository under the API classification OTHER, indicating it is an internal supporting utility rather than a public, externally documented business API. Its status is VALID, confirming that the compiled package and package body are present and usable in the target instance.

Key Procedures and Functions

The package body exposes four documented procedures, corresponding to the standard audit-table maintenance pattern used throughout EBS:

  • INSERT_ROW — Inserts a new audit record into the Customer Plans Audit tables, capturing the newly created or modified plan data that must be preserved for historical reporting and compliance purposes.
  • UPDATE_ROW — Modifies an existing audit row, allowing corrections or staged updates to previously written audit entries.
  • LOCK_ROW — Acquires a row-level lock (typically via SELECT ... FOR UPDATE semantics) on an audit row to serialize concurrent access and to signal the caller that a transaction intends to modify the record.
  • DELETE_ROW — Removes an audit row, supporting purge, rollback, or corrective maintenance of the audit trail.

The ETRM metadata documents no parameter lists for these procedures. Callers should therefore consult the package specification in the target instance (ALL_ARGUMENTS, ALL_SOURCE) before direct invocation, since signatures vary by patch level and by release (12.1.1 versus 12.2.2).

Tables Accessed

The package operates against two documented tables, accessed through APPS synonyms:

  • CSC_CUST_PLANS_AUDIT — The primary audit table holding historical rows describing Customer Plans records and the changes applied to them.
  • CSC_CUST_PLANS_AUDIT_S — The corresponding sequence (or sequence-backed support object) used to generate unique primary keys for rows inserted into the audit table.

Read and write activity is therefore confined to the audit schema. The package does not directly manipulate the base Customer Plans tables; those are handled by CSC_CUST_PLANS_PVT, which delegates audit persistence to this package.

Usage Notes

CSC_CUST_PLANS_AUDIT_PKG is invoked indirectly. The ETRM dependency report shows it is referenced by CSC_CUST_PLANS_PVT, the private business logic layer that implements Customer Plans processing for forms, concurrent programs, and OAF pages. Typical invocation paths include:

  • Customer Care forms and OA framework pages where a user creates, updates, or deletes a Customer Plan, triggering the private layer to write an audit entry through INSERT_ROW or UPDATE_ROW.
  • Concurrent programs that batch-load or mass-maintain Customer Plans data, which must record the same audit trail as online transactions.
  • Custom or extension code that must preserve audit parity when modifying Customer Plans data outside the delivered UI.

Because LOCK_ROW is part of the interface, callers are expected to lock an audit row before updating or deleting it, consistent with EBS concurrency conventions. Direct calls to this package are not recommended in customizations; developers should prefer the public Customer Plans API surface in CSC_CUST_PLANS_PVT so that validation and audit logic remain consistent. As with all APPS-owned packages, the object should not be modified, and the two referenced tables should not be updated directly without accompanying audit maintenance.