Search Results oe_version_blanket_comp




Overview
Explore in AI Chat

Overview

OE_VERSION_BLANKET_COMP is an Oracle E-Business Suite PL/SQL package owned by the APPS schema and classified in the ETRM repository as an OTHER API. Its name reflects its core purpose: performing version comparison on blanket sales agreements within the Oracle Order Management (OE) module. Blanket sales agreements in EBS are versioned documents — each approved amendment creates a new version of the header, lines, and their associated attribute values, with historical snapshots retained for audit and reference. The package provides the programmatic machinery that allows two versions of the same blanket agreement to be compared side by side, resolving both current and historical rows, and returning the data in a form suitable for presentation in the Versions comparison UI.

The package is documented as VALID in both 12.1.1 and 12.2.2, and its dependency footprint confirms a tightly scoped role: it references OE_BLANKET_PUB (the public blanket agreement API) and the Oracle STANDARD package, and it is referenced by no other packages, indicating it is a leaf-level utility rather than a shared foundation module.

Key Procedures and Functions

The ETRM metadata documents nine callable units. Their purposes are as follows:

  • QUERY_HEADER_ROW — Retrieves a single header row for a specified blanket agreement version, supplying the header-level data used in the comparison display.
  • QUERY_HEADER_TRANS_ROW — Retrieves the translated (language-dependent) header row, returning the same logical header information resolved through the translation views.
  • QUERY_LINE_ROW — Retrieves an individual blanket agreement line for a given version, forming the line-level basis of the comparison.
  • QUERY_LINE_TRANS_ROW — Retrieves the translated version of a line row, providing language-resolved line attributes.
  • COMPARE_HEADER_VERSIONS — Compares the header attributes of two versions of the same blanket agreement and identifies which values differ.
  • COMPARE_LINE_VERSIONS — Performs the equivalent comparison at the line level, matching lines across the two versions and detecting differences.
  • COMPARE_ATTRIBUTES — Compares individual attribute values, supporting the granular difference detection used by the header and line comparison routines.
  • LINE_STATUS — Derives or returns the status of a blanket line within the versioning context.
  • GET_DFF_SEG_PROMPT — Returns the descriptive flexfield segment prompt for a given context, enabling the comparison display to label DFF segments meaningfully.

Tables Accessed

All table access is performed through APPS synonyms. The package reads the current blanket agreement definition from OE_BLANKET_HEADERS and OE_BLANKET_LINES (with OE_BLANKET_LINES_ALL providing the multi-organization line view), and reads the corresponding descriptive flexfield data from OE_BLANKET_HEADERS_EXT and OE_BLANKET_LINES_EXT. Historical versions — essential to any version comparison — are sourced from OE_BLANKET_HEADERS_HIST and OE_BLANKET_LINES_HIST. The presence of DUAL indicates internal scalar resolution, and PLITBLM is the standard Order Management PL/SQL index-by table type used to pass line collections between the query and comparison routines. The package is read-only with respect to document data; it does not create or amend blanket agreements, but rather queries and reconciles existing and historical rows.

Usage Notes

Because the package is referenced by no other packages, it is invoked directly rather than through a higher-level dependency chain. Its primary consumer is the blanket agreement version comparison form (Versions window) in Oracle Order Management, where it supplies header, line, flexfield, translation, and attribute-difference data to the UI. The same routines can be called from custom concurrent programs or bespoke PL/SQL when an implementation requires automated or batch comparison of blanket agreement versions, for example in audit reporting or approval workflows. Developers should invoke it only against blanket agreements that have multiple versions, and should treat it as a read-only utility for the blanket tables. As with all APPS-level APIs, direct modification of package source is not supported; any extension should wrap the documented procedures rather than alter them.