Search Results get_current_system

Overview

CS_SYSTEMS_COMMON_PUB is a public PL/SQL API package in the Oracle E-Business Suite Applications schema (APPS) that belongs to the Customer Support (CS) product family. It encapsulates the business logic governing "systems" — the configurable support entities that group customers, users, and service entitlements within Oracle Customer Support and the TeleService/Digital Service offerings. Its principal purpose is to resolve the relationship between application users (FND_USER records), parties (HZ_PARTIES / HZ_CUST_ACCOUNTS), and the systems to which they are associated, and to validate whether a given system is enabled, valid, and reachable for a specific user.

Because it is declared with AUTHID CURRENT_USER and is classified as a PUB API, the package is intended as a stable, externally callable interface. The header comment identifies it as a shipped EBS source file (cscommns.pls), and the API classification confirms it is safe to invoke from custom code, forms, and concurrent programs. The user search term user_exists corresponds directly to one of the documented procedures, USER_EXISTS, which is the entry point most commonly referenced when developers need to determine whether an FND_USER is recognized as a system-associated user.

Key Procedures and Functions

The package exposes two standalone functions and eight procedures. The functions returning scalar identifiers are:

• GET_PARTY_ID — returns the HZ_PARTIES party identifier corresponding to a given FND_USER user identifier.
• GET_SYSTEM_ID — returns the system identifier (from CS_SYSTEMS_ALL_B) corresponding to a supplied system name.

The following procedures follow the standard EBS API error-handling convention with API version, initialization flag, commit flag, and the x_return_status / x_msg_count / x_msg_data OUT parameters:

• IS_SYSTEM_ENABLED — validates that the current or specified system is in an enabled state before further processing is permitted.
• IS_SYSTEM_VALID — validates a system identified by system ID or system name.
• GET_CURRENT_SYSTEM — retrieves the system ID and system name currently in effect for a given user.
• GET_ALL_SYSTEMS_FOR_USER — returns a REF CURSOR (Sys_Info_Cursor) of all systems associated with a user.
• GET_ALL_CHILD_SYSTEMS — returns a REF CURSOR of the child systems subordinate to a parent system.
• IS_USER_ASSOCIATED_TO_SYSTEM — determines whether a specified user is linked to a specified system.
• ASSOCIATION_EXISTS — a generalized check for the existence of an association between the relevant support entities.
• USER_EXISTS — the procedure most frequently searched, confirming whether a given user record is recognized within the systems context, thereby supporting the association checks performed by its sibling procedures.

Tables Accessed

The package references the following tables through APPS synonyms:

• CS_SYSTEMS_ALL_B and CS_SYSTEMS_ALL_VL — the base and translated views holding system definitions, used for system validation and lookup.
• FND_USER — the application user repository, queried by USER_EXISTS, IS_USER_ASSOCIATED_TO_SYSTEM, and GET_ALL_SYSTEMS_FOR_USER.
• HZ_PARTIES and HZ_CUST_ACCOUNTS — the TCA party and customer account tables, used by GET_PARTY_ID to resolve a user to a party and by association checks linking parties to systems.
• PLITBLM — the standard EBS PL/SQL table used for message handling by the FND_MSG_PUB error stack integration.

Usage Notes

CS_SYSTEMS_COMMON_PUB is typically invoked from TeleService and Customer Support forms and from custom extensions that must resolve a user's system context before displaying entitlements, service requests, or system-specific data. Because it participates in the FND_API error-handling model, callers should initialize the message list, inspect x_return_status for FND_API.G_RET_STS_SUCCESS, and drain messages via FND_MSG_PUB.GET when errors occur. REF CURSOR outputs such as GET_ALL_SYSTEMS_FOR_USER must be explicitly fetched and closed by the caller. The package is not referenced by any other documented package, so it is normally called directly from form-level or concurrent logic rather than as an internal dependency. Standard EBS practice applies: pass a valid API version, use FND_API.G_FALSE for p_commit unless transaction control is intended, and test in a cloned environment before promoting custom callers between 12.1.1 and 12.2.2 instances.