Results for “csm_acc_pkg”

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

Overview

CSM_ACC_PKG is a PL/SQL package body owned by the APPS schema in Oracle E-Business Suite, classified under the ETRM documentation as an "OTHER" API object. Its name and dependent table references indicate that it belongs to the Customer Support / Service (CSM) module family, specifically the area concerned with account and user administration. In EBS 12.1.1 and 12.2.2 the CSM schema objects underpin the Service responsibility, where technician and resource accounts must be synchronized with the underlying resource model.

The package encapsulates the create, update, and delete maintenance operations for these account records, together with an accessor that resolves an account identifier. It does not expose a formally registered public API in the ETRM sense; it is an internal utility package built for use by other CSM components. This is borne out by two documented facts: the package body is not referenced by any database object listed in the dependency report, yet it is itself referenced by 46 other packages. In other words, CSM_ACC_PKG sits near the bottom of the CSM call stack, being consumed by a wide set of callers rather than consuming them.

Key Procedures and Functions

The ETRM documentation records four procedures or functions in the package body:

• INSERT_ACC — Creates a new account record. This is the entry point used when a resource or user requires an associated CSM account to be established.
• DELETE_ACC — Removes an existing account record, supporting the cleanup path when a resource is retired or detached.
• UPDATE_ACC — Modifies an existing account record, allowing attribute changes to be persisted without recreating the account.
• GET_ACC_ID — Retrieves the identifier for an account, providing the lookup mechanism callers use to obtain a key before invoking the maintenance routines.

No parameter lists are documented in the available metadata, and none are asserted here. Together, the four routines form a conventional maintenance API: a read accessor plus insert, update, and delete operations.

Tables Accessed

The documented table references, resolved through APPS synonyms, are ASG_USER, JTF_RS_RESOURCE_EXTNS, DBMS_SQL, and PLITBLM. ASG_USER stores the resource and user account information that CSM relies on for assignment and ownership; the insert, update, and delete routines operate against it. JTF_RS_RESOURCE_EXTNS is the resource extension table in the JTF Resource Manager model, holding the extended attributes of resources that a CSM account is tied to, and is therefore the natural join partner when resolving an account to its owning resource.

DBMS_SQL and PLITBLM are Oracle-supplied packages rather than application tables. Their presence indicates that portions of CSM_ACC_PKG build and execute SQL dynamically, most likely to support flexible lookup logic such as GET_ACC_ID, where the query shape may vary with caller input.

Usage Notes

CSM_ACC_PKG is typically invoked indirectly. Because it is referenced by 46 other packages, it functions as a shared service called from higher-level CSM processing rather than being attached directly to a form or concurrent program. Customizations that need to create, change, or remove CSM accounts should call the corresponding routine on this package rather than issuing direct DML against ASG_USER, so that any validation, logging, and resource-extension handling coded into the package is preserved.

Internal dependencies on FND_GLOBAL and FND_LOG indicate that the package resolves the current application session context and writes to the Oracle EBS debug log. Developers troubleshooting account-related behavior in the Service module should therefore enable FND logging for the CSM_ACC_PKG module to capture diagnostic output. Note that the ETRM record lists CSM_PROFILE_PKG, CSM_UTIL_PKG, and ASG_DOWNLOAD among the package's dependencies, so failures in the account routines may originate in those shared CSM utilities. As with any internal, non-public API, procedure signatures are not guaranteed across patch levels and should be verified in the target instance before reuse.