Search Results oe_sop_util

Overview

OE_SOP_UTIL is a utility package in the Oracle E-Business Suite Order Management (OE) module. Its name reflects its role as a helper object for Sales Order Pad (SOP) processing. Rather than implementing transactional business logic such as order entry, pricing, or scheduling, the package provides lightweight session-context lookups that other Order Management components can call to resolve the identity of the user currently interacting with the application. It is declared with AUTHID CURRENT_USER, meaning its unqualified references resolve against the privileges of the invoking schema rather than the package owner. The package header carries a header comment dated 2005, indicating it is a long-standing, stable internal utility that has persisted across EBS releases including 12.1.1 and 12.2.2 without functional redesign. In the ETRM 12.2.2 documentation it is classified as a UTIL object, owned by APPS, and it exposes exactly two public subprograms: GET_RESOURCE_ID and GET_PERSON_ID.

Key Procedures and Functions

• GET_RESOURCE_ID — A function returning NUMBER. This is the entry point most commonly associated with the search term "get_resource_id." It returns the resource identifier corresponding to the current application user, allowing Order Management code to associate the session with a schedulable or assignable resource. Because the resource identifier is the primary key used throughout the JTF Resource Manager schema, this value is the natural join key when Order Management needs to attribute an action, task, or assignment to the logged-in user as a resource rather than merely as an FND user account.
• GET_PERSON_ID — A function returning NUMBER. This companion function returns the person identifier for the current user. It mirrors GET_RESOURCE_ID but resolves to the human-resources party record instead of the resource record, which is useful when downstream logic must reference the underlying person, such as for employee-level attributes held in the PER schema.

The two functions form a matched pair: one yields the resource-centric identity, the other the person-centric identity, both derived from the same session context. The documented header exposes no additional procedures, and the package is not referenced by any other packaged APIs in the ETRM inventory, confirming its role as a leaf-level utility.

Tables Accessed

Per the documented metadata, the package resolves its values through three tables reached by APPS synonyms:

• FND_USER — the Oracle Applications user repository. The session's user name is the starting point for both lookups, providing the join path from the logged-in application account to the associated employee or resource.
• JTF_RS_RESOURCE_EXTNS — the Resource Manager extension table that links a resource to its source system and source identifier. This is the table through which the resource ID returned by GET_RESOURCE_ID is determined.
• PER_ALL_PEOPLE_F — the effective-dated HR people table. It supplies the person record and person ID returned by GET_PERSON_ID.

The package reads from these tables; no write operations are documented.

Usage Notes

OE_SOP_UTIL is an internal utility and is not intended for customer-facing customization. It is typically invoked by Order Management forms, concurrent programs, or other Order Management PL/SQL routines that require the identity of the current user expressed as a resource or person. In the Sales Order Pad and related Order Management screens, such resolution is needed when defaulting assignment fields, stamping audit columns, or driving resource-based validation. Because the derived values depend on the application session, callers must run in a context where FND_GLOBAL user information is populated — an active Forms session or a concurrent program request. Custom code may call the functions, but doing so bypasses formal API contracts and documentation, so the safer practice is to obtain the resource or person identifier directly from the same underlying tables with an explicit, version-stable query. The package remains present, unchanged in interface, across both 12.1.1 and 12.2.2, and its signature is stable enough for existing custom callers to continue operating without modification.