Search Results release_post_query




Overview
Explore in AI Chat

Overview

APPS.PO_RELEASES_SV4 is a server-side PL/SQL package body within the Oracle E-Business Suite Purchasing (PO) module. It belongs to the family of "SV" (server validation/supply) packages that support the Oracle Purchasing forms and business logic for blanket and planned purchase order releases. In EBS 12.1.1 and 12.2.2, this package is classified under the API classification of OTHER, meaning it is not a formally published public API but rather an internal support package invoked by Oracle Purchasing forms and related code paths.

The primary business function of PO_RELEASES_SV4 is to supply release-level data required by the Purchasing release entry form. Specifically, it computes and returns release totals, determines whether encumbrance (reserved) amounts should be displayed, resolves shipping and freight-related attributes, and returns agreement status information. The presence of the release_post_query procedure — the object the user targeted in their search — confirms the package's role as a query/post-query support routine for the release form block, populating non-database and derived fields after a release record is queried.

Key Procedures and Functions

ETRM documents six procedures/functions in this package. The two explicitly named in the metadata are:

  • release_post_query — The central routine, executed in the POST-QUERY trigger of the release form block. It accepts the release identifier, release type, and purchase order header identifier, and returns the release total, a secondary total (blanket or planned), the encumbrance display flag, ship-via code, shipment number, ship-to organization code, agreement status, freight terms, FOB, and pay-on display value. Internally it calls po_core_s.get_total to derive release and header totals and PO_CORE_S.should_display_reserved to determine whether reserved/encumbered amounts should be shown to the user. Bug 2567391 replaced a direct call to po_line_locations_pkg_s3.select_summary with po_core_s.get_total('R', ...) to correct a rounding problem in the running-total implementation. Bug 3378554 added the ship-to organization, authorization status, freight terms, FOB, and pay-on parameters.
  • NAME — A documented identifier routine in the package, consistent with standard EBS package conventions where a NAME procedure/function exposes the object name for diagnostic and registration purposes.

Other documented routines in the six-entry list (for example GET_RELEASE_NUM) follow the same internal-support pattern. GET_RELEASE_NUM supplies release numbering information used when the form must display or validate a release number. Because the metadata does not enumerate the remaining entries, they are not described further here; parameter details for any routine must be taken from the actual package source rather than inferred.

Tables Accessed

The package reads the following tables through APPS synonyms:

  • PO_RELEASES — The primary release header table, supplying ship-via lookup code and release-level attributes returned by release_post_query.
  • PO_HEADERS — The parent document header, used to resolve blanket/planned agreement attributes and header-level totals.
  • PO_LINE_LOCATIONS — Shipment-level data underlying the release totals and ship-to information computed by the package.
  • MTL_PARAMETERS — Inventory organization parameters, consulted when deriving ship-to organization defaults and validation.
  • HR_ORGANIZATION_INFORMATION — Organization classification data used to resolve ship-to organization codes.
  • FINANCIALS_SYSTEM_PARAMETERS — Financials options, referenced in support of encumbrance and reserved-amount display determination.

Usage Notes

PO_RELEASES_SV4 is typically invoked from the Oracle Purchasing release entry form, where release_post_query is triggered in the POST-QUERY block trigger each time a release record is fetched. It is also referenced by four other packages in the EBS code base, indicating reuse in additional server-side purchasing flows. Because the package is classified as OTHER and carries a "noship" header with a 2006 vintage, it should be treated as an internal, version-sensitive implementation rather than a supported public API. Custom code should not call it directly; any extension or debug effort should account for the bug fixes noted in the source (Bugs 2567391 and 3378554), which affect the totals and ship-to/freight fields returned to the form.