Search Results update_global_picture

Overview

APPS.OE_ORDER_UTIL is a utility package within the Oracle Order Management (OM) module of Oracle E-Business Suite, available in releases 12.1.1 and 12.2.2. It is classified as a UTIL (utility) object in the ETRM repository and is owned by the APPS schema. The package supports the Order Management transaction infrastructure by providing shared services that other OM packages, forms, and workflow activities invoke. Rather than exposing a business transaction API such as OE_ORDER_PUB, OE_ORDER_UTIL concentrates on cross-cutting concerns: resolving dictionary attribute names, obtaining object-level locks on order entities, maintaining the session-level "global picture" of an order being processed, and emitting business events. The package is referenced by 75 other packages, confirming its role as a foundational dependency in the Order Management code stack.

Key Procedures and Functions

• GET_ATTRIBUTE_NAME — Function returning the translated display name of an attribute, resolved from the AK (Application Object Library) dictionary using the supplied attribute code. Used to resolve message tokens that display attribute names to users.
• LOCK_ORDER_OBJECT — Locks the order object, comprising the order header, lines, sales credits, and price adjustments belonging to that order, and returns a status value to the caller.
• UPDATE_GLOBAL_PICTURE — Maintains the package-level global state ("global picture") that holds the current order header, line, sales credit, and price adjustment records being processed.
• CLEAR_GLOBAL_PICTURE — Resets the global picture, discarding the retained header, line, sales credit, and adjustment records once processing completes.
• RETURN_GLB_ENT_INDEX — Returns an index into the global entity collections, allowing callers to locate a specific record within the cached global picture.
• GET_GLOBAL_OLD_HEADER_ID — Retrieves the header identifier of the prior header record held in the global old header structure.
• INITIALIZE_ACCESS_LIST — Initializes the access list structure used to control which actions are permitted during processing.
• ADD_ACCESS — Adds an action to the access list.
• IS_ACTION_IN_ACCESS_LIST — Tests whether a given action is present in the access list.
• GET_ACCESS_LIST — Returns the current access list.
• GET_PRECISION — Returns numeric precision information used for validation or formatting.
• RAISE_BUSINESS_EVENT — Raises a business event through the Workflow Business Event System, recording it in the event subscription structures.

The package also declares a substantial set of package globals, including G_Recursion_Without_Exception and paired current/old record sets for headers, lines, sales credits, and adjustments. These globals underpin the notification framework and recursion control logic.

Tables Accessed

• OE_ORDER_HEADERS and OE_ORDER_LINES / OE_ORDER_LINES_ALL — order header and line data read or written while refreshing the global picture.
• OE_SALES_CREDITS — sales credit records associated with a header or line.
• OE_PRICE_ADJUSTMENTS — price adjustment records attached to the order object.
• OE_RAISE_BUSINESS_EVENT_S — staging table for business events raised by RAISE_BUSINESS_EVENT.
• WF_PARAMETER_LIST_T — Workflow parameter list structure used to pass event arguments.
• DUAL and PLITBLM — utility access, including PL/SQL table indexing.

Usage Notes

OE_ORDER_UTIL is not an end-user API. It is invoked internally by Order Management forms, concurrent programs, workflow activities, and other OM packages that need attribute name resolution, entity locking, business event publication, or global state management. The LOCK_ORDER_OBJECT procedure is typically called before a transaction modifies an order, while UPDATE_GLOBAL_PICTURE and CLEAR_GLOBAL_PICTURE bracket the processing of an order within a session. Custom code should prefer the supported OE_ORDER_PUB API and treat OE_ORDER_UTIL as an internal dependency, since its globals and access-list behavior are tied to Order Management's recursion and notification framework. Because 75 packages depend on it, signature changes are tightly controlled across 12.1.1 and 12.2.2.