Search Results perform_versioning

Overview

OE_VERSIONING_UTIL is an internal utility package in the Oracle Order Management (OM) module of Oracle E-Business Suite, residing under the APPS schema and classified as a UTIL-type API. Its principal business function is to manage versioning and audit-trail capture for Order Management documents, including orders, blankets, and their associated lines, price adjustments, and sales credits. When a user or process modifies a document attribute that is flagged as version-controlled, this package determines whether the change warrants a new version, records the changed records into the appropriate history tables, and enforces the business rules governing when a reason code or comment must be captured.

The package relies on a set of package-level globals (for example, G_Audit_Header_Reason_Required, G_Temp_Reason_Code, and G_Temp_Reason_Comments) and on two PL/SQL collection types, Audit_Trail_Rec_Type and Audit_Trail_Tbl_Type, that hold audit metadata such as entity ID, history type code, and whether a reason is required. These globals and tables coordinate audit information across the various versioning entry points during a single logical transaction.

Key Procedures and Functions

• EXECUTE_VERSIONING_REQUEST — The primary entry point for requesting a versioning operation against a header, invoked with a header ID, document type, and optional changed attribute. Returns standard message count, message data, and return status outputs.
• PERFORM_VERSIONING — Performs the actual versioning logic after a request has been validated, operating on the same header, document type, and changed attribute inputs.
• RECORD_CHANGED_RECORDS — Writes the set of modified records to the appropriate history tables, driven by version and phase-change flags.
• RESET_GLOBALS — Resets the package-level global variables to their default state, ensuring no stale audit context leaks between operations.
• CHECK_SECURITY — Validates security against a specified column and an on-operation action, preventing unauthorized versioning or audit operations.
• IS_REASON_RQD — Indicates whether a reason is required for the current audit context.
• IS_AUDIT_REASON_CAPTURED — Determines, for a given entity code and entity ID, whether an audit reason has already been captured.
• CAPTURED_REASON — Returns the reason captured for the current audit context; this is the function most commonly referenced by callers searching on the term "captured_reason."
• CAPTURE_AUDIT_INFO — Populates audit information (entity code, entity ID, history type code) into the package collections, priming the reason and history-type context for subsequent calls.
• GET_REASON_INFO — Retrieves the reason code and comments recorded for the audit trail.

Tables Accessed

The package reads and writes the Order Management history and base tables through APPS synonyms. Order and blanket headers and lines are referenced through OE_ORDER_HEADERS_ALL, OE_BLANKET_HEADERS_ALL, and OE_BLANKET_HEADERS_EXT. Historical records are maintained in OE_ORDER_HEADER_HISTORY, OE_ORDER_LINES_HISTORY, OE_BLANKET_HEADERS_HIST, OE_PRICE_ADJS_HISTORY, and OE_SALES_CREDIT_HISTORY. The PLITBLM table is used as a PL/SQL index-by table work area. Together these objects support the capture and retrieval of version and audit-reason data associated with header, line, adjustment, and sales-credit changes.

Usage Notes

OE_VERSIONING_UTIL is not a standalone public API; it is invoked indirectly by Oracle Order Management forms and by other OM packages during order entry and update processing, and it is referenced by 22 other packages. Custom code requiring versioning or audit-reason logic should call the documented procedures rather than referencing the globals directly, and should expect the Oracle Forms UI to supply the reason code and comments when IS_REASON_RQD or IS_AUDIT_REASON_CAPTURED signals that a reason is mandatory. The G_UI_Called flag distinguishes UI-driven invocations from programmatic ones, which affects reason-capture expectations. Because it is a UTIL-class internal package, its signature is subject to change between releases; the 120.1 header indicates the shipped source baseline.