Search Results remove_plan

Overview

APPS.CSC_CORE_UTILS_PVT is a private (PVT-classified) PL/SQL utility package belonging to the Oracle E-Business Suite Customer Care (CSC) module. Its declared purpose, per the embedded source header (cscvcors.pls, version 115.19, last shipped 2002/12/04), is to house the common procedures, functions, and global variables shared across the Customer Care application. It is not an end-user-facing API; it is the internal toolbox that sibling Customer Care packages call for cross-cutting concerns such as plan lifecycle status handling, standard messaging and return-status constants, and database statistics collection.

The package is declared AUTHID CURRENT_USER, so it executes with the privileges of the invoking schema, which is relevant because it is almost always invoked from within the APPS schema by other Customer Care packages. The metadata confirms it is referenced by 39 other packages, making it a highly central, low-level dependency within the CSC stack. Its constants — G_PVT, G_PUB, G_APP_SHORTNAME (set to 'CSC'), G_PKG_NAME, L_UPDATE, and L_CREATE — establish a consistent naming and action-code convention reused throughout the module.

Key Procedures and Functions

The ETRM metadata documents 46 procedures and functions, grouped functionally as follows.

• Plan lifecycle routines: ENABLE_PLAN, DISABLE_PLAN, APPLY_PLAN, REMOVE_PLAN, MERGE_PLAN, and TRANSFER_PLAN. These correspond to the source history note dated 02-22-2001, which records that MERGE_PLAN and TRANSFER_PLAN were added specifically to support Party Merge. REMOVE_PLAN — the term the user searched for — is the counterpart routine that clears or detaches an existing plan record, typically invoked during cleanup, plan retirement, or merge processing.
• Standard API constants and return-status helpers: G_CREATE, G_UPDATE, G_TRUE, G_FALSE, and the return-status accessors G_RET_STS_SUCCESS, G_RET_STS_ERROR, and G_RET_STS_UNEXP_ERROR. These provide uniform success/failure signaling across Customer Care APIs.
• Missing-value sentinels: G_MISS_NUM, G_MISS_CHAR, and G_MISS_DATE. The source history entry dated 12-03-2002 notes the addition of a function to support FND_API.G_MISS* changes, aligning this package with the standard Oracle API missing-value convention.
• Validation-level constants: G_VALID_LEVEL_NONE, G_VALID_LEVEL_FULL, and G_VALID_LEVEL_INT, used to control the depth of validation performed by calling APIs.
• Statistics utility: GATHER_TABLE_STATS, added per the 05-04-2000 history entry to gather cost-based optimizer statistics on a specified table.

Tables Accessed

Through APPS synonyms, the package references CS_COUNTERS (the Customer Care module's sequence/counter source, used for generating internal identifiers), FND_APPLICATION (application registration and short-name lookup), and FND_CURRENCIES (currency validation and defaulting). It also depends on the DBMS_SQL and DBMS_TRANSACTION built-in packages — DBMS_SQL for dynamic SQL, most plausibly within GATHER_TABLE_STATS, and DBMS_TRANSACTION for savepoint and rollback handling in the plan utility routines.

Usage Notes

Because CSC_CORE_UTILS_PVT is a private package, it is not designed to be called directly from Oracle Forms or from external custom code; it is invoked internally by the other Customer Care packages that compose the module's public API surface. Customizations that need plan manipulation (REMOVE_PLAN, MERGE_PLAN, and similar) should be implemented through the corresponding Customer Care public APIs rather than through direct calls to this package, and any direct dependency should be treated as unsupported and subject to change. When troubleshooting plan-related behavior — particularly plan removal during Party Merge or plan cleanup — CSC_CORE_UTILS_PVT is the correct starting point for tracing the underlying logic, but the call path will normally originate from a higher-level CSC package or a concurrent program that invokes it. As with all database objects shipped with EBS 12.1.1 and 12.2.2, the package body should be inspected in the deployed instance to confirm the exact behavior, since the ETRM metadata reflects the documented signature set rather than runtime parameter values.