Search Results insert_user
Overview
CSL_FND_USER_ACC_PKG is an Oracle Applications (APPS) owned PL/SQL package that forms part of the Customer Support/Service Logistics (CSL) integration layer responsible for propagating FND_USER records into the ACC (Advanced Customer Care / resource) repository. The package is declared with AUTHID CURRENT_USER, meaning all unqualified object references are resolved in the schema of the calling user rather than in the APPS schema itself. This is a deliberate design choice in EBS 12.1.1 and 12.2.2 that allows the package to execute with the privileges of the invoker, which is important for security and for supporting the multi-org, multi-schema architecture of the E-Business Suite.
At a functional level, the package provides the DML façade that keeps the ACC user table synchronized with the FND_USER table whenever a user is created, modified, or removed. It is classified as an "OTHER" API rather than a formal public API, indicating that it is intended primarily for internal use by CSL components rather than as a broadly supported extension point.
Key Procedures and Functions
- REPLICATE_RECORD — A boolean function that determines whether a given user record should be replicated into the ACC repository. It acts as a filter or gating check: only when it returns TRUE will the caller proceed with an insert, update, or delete operation. This prevents replication of users that are not relevant to the CSL/ACC domain (for example, users who do not correspond to service resources).
- INSERT_USER — The procedure invoked when a new user must be inserted into the ACC table. It is described in the package header as the entry point called "when a user needs to be inserted into ACC table." It accepts the user identifier and an associated resource identifier.
- UPDATE_USER — The procedure called when an existing user record must be updated in the ACC table, keeping the replicated copy aligned with changes made in FND_USER (for example, changes to the associated resource or user attributes).
- DELETE_USER — The procedure invoked when a user must be removed from the ACC table, typically in response to a user being end-dated or deleted in FND_USER.
The three DML procedures share a common signature shape (a user identifier plus a resource identifier), reflecting their role as a coordinated set of synchronization handlers. REPLICATE_RECORD is used as the precondition check for all three.
Tables Accessed
The only documented table referenced through APPS synonyms is FND_USER. The package reads FND_USER to identify the user and to evaluate whether replication is required (via REPLICATE_RECORD), and it uses the user/resource identifiers to write to the ACC-side table that holds the replicated user data. Because the ACC table is not separately documented in the metadata, the exact target name is not listed; FND_USER remains the authoritative source record from which the ACC copy is derived. The package therefore behaves as a one-way propagation mechanism: FND_USER is the source of truth, and the ACC user table is the dependent target.
Usage Notes
CSL_FND_USER_ACC_PKG is referenced by four other packages in the APPS schema, which indicates that it is not typically invoked directly by end users or by ad-hoc scripts. Instead it is called from within the CSL user-management flow — most likely triggered when FND_USER records are maintained through the standard EBS user administration forms, or when CSL concurrent programs process resource and user synchronization.
Because the package performs direct DML against the ACC repository, custom code should call it only when the standard CSL synchronization path cannot be used, and it should always respect the REPLICATE_RECORD precondition before invoking INSERT_USER, UPDATE_USER, or DELETE_USER. Given its AUTHID CURRENT_USER declaration and its classification as an "OTHER" API, developers should verify schema privileges and expect no formal support commitment for direct invocation. In both 12.1.1 and 12.2.2 the package structure is identical; the source header revision (115.2) indicates it has remained stable across releases.
-
APPS.CSL_FND_USER_ACC_PKG SQL Statements
12.1.1
-
APPS.CSL_FND_USER_ACC_PKG SQL Statements
12.2.2
-
PACKAGE: APPS.CSL_FND_USER_ACC_PKG
12.1.1
-
PACKAGE BODY: APPS.CSL_FND_USER_ACC_PKG
12.1.1
-
PACKAGE BODY: APPS.CSL_FND_USER_ACC_PKG
12.2.2
-
PACKAGE: APPS.CSL_FND_USER_ACC_PKG
12.2.2
-
APPS.FND_FUNCTION_SECURITY_CACHE SQL Statements
12.2.2
-
PACKAGE: APPS.FND_FUNCTION_SECURITY_CACHE
12.1.1
-
APPS.FND_FUNCTION_SECURITY_CACHE SQL Statements
12.1.1
-
PACKAGE: APPS.FND_FUNCTION_SECURITY_CACHE
12.2.2
-
PACKAGE BODY: APPS.FND_FUNCTION_SECURITY_CACHE
12.2.2
-
PACKAGE BODY: APPS.FND_FUNCTION_SECURITY_CACHE
12.1.1
-
APPS.CSL_FND_USER_ACC_PKG dependencies on JTM_HOOK_UTIL_PKG
12.2.2
-
APPS.CSL_FND_USER_ACC_PKG dependencies on JTM_MESSAGE_LOG_PKG
12.2.2
-
APPS.CSL_FND_USER_ACC_PKG dependencies on JTM_MESSAGE_LOG_PKG
12.1.1
-
APPS.CSL_FND_USER_ACC_PKG dependencies on JTM_HOOK_UTIL_PKG
12.1.1
-
APPS.FND_FUNCTION_SECURITY_CACHE dependencies on WF_PARAMETER_LIST_T
12.2.2
-
APPS.FND_FUNCTION_SECURITY_CACHE dependencies on WF_PARAMETER_LIST_T
12.1.1