Search Results post_query

Overview

RCV_CORRECTION_SV is a server-side PL/SQL package owned by the APPS schema in Oracle E-Business Suite. Its name follows the standard EBS convention for a "server-side view/logic" package (the _SV suffix), and it is the programmatic engine behind the Enter Corrections window in the Receiving module. That window allows receiving clerks to view and modify receipt and receiving-transaction attributes after the original transaction has been recorded — for example, correcting the destination subinventory, locator, hazard class, UN number, or deliver-to information on an inbound shipment line.

The package is documented with an AUTHID CURRENT_USER declaration, meaning that its unqualified references to database objects are resolved against the calling user's schema and privileges rather than the definer's. In practice, it executes under the privileges of the APPS user when invoked from the standard Receiving forms, while still honoring the session user's security context. The header comment identifies the package as the "wrapper" for the Enter Corrections post-query logic, confirming its role as the single entry point for the query-time processing that populates the Corrections block on screen.

The source header carries a creation date of 24-MAY-95 (Sanjay Kothary), and the RCS identifier indicates a last revision in 2004, so the package has been stable across many releases and is carried forward into 12.1.1 and 12.2.2 without functional redesign.

Key Procedures and Functions

• NAME — A documented member of the package. In EBS _SV packages a NAME routine typically returns or maintains a descriptive label for the entity being processed, allowing the Corrections form to display a readable identifier for the transaction or source document. The metadata documents its existence without exposing a body.
• POST_QUERY — The principal documented procedure and the wrapper for the Enter Corrections post-query logic. It accepts the identifying context of the transaction being corrected — transaction ID, receipt source code, organization, shipment header and line, PO header, line, release and line-location, item, destination, and transaction/creation dates — together with hazard and UN data. It returns a large set of OUT parameters that supply the derived and final values the Corrections form needs: final destination type code and display, final location and subinventory, destination context, job/schedule and operation sequence displays, department code, production line, BOM resource ID, deliver-to person and location IDs, person, location, hazard class, UN number, locator type and ID, counts, available and tolerable quantities, UOM, and the PO distribution count. It is called during the query phase to default and validate values shown to the user; it does not itself commit a correction.

Tables Accessed

• RCV_SHIPMENT_LINES — the core receiving transaction table, read to retrieve the receipt line attributes (destination, quantities, PO references) that the post-query logic defaults and displays.
• MTL_UNITS_OF_MEASURE — read to derive the unit of measure display for the transaction quantity.
• PO_HAZARD_CLASSES — read to resolve hazard class descriptions for the returned hazard class display value.
• PO_UN_NUMBERS — read to resolve UN number descriptions.
• WMS_LICENSE_PLATE_NUMBERS — read in Warehouse Management-enabled organizations to resolve license plate (LPN) context for the destination.

All tables are referenced through APPS synonyms, consistent with the package's shared-schema design.

Usage Notes

RCV_CORRECTION_SV is not a public integration API. It is an internal supporting package invoked by the Oracle Receiving forms (the Enter Corrections window and related receipt-maintenance UI) during block query processing; the ETRM metadata records zero packages referencing it, indicating no external dependency footprint. Customizations should not call it directly to post corrections — that work belongs to the receiving transaction APIs (RCV_Transactions) — but it may legitimately be called from custom forms or reporting code that needs the same destination- and hazard-defaulting logic. Because the OUT parameters expose derived destination and deliver-to values, callers must supply the full transaction context. Any modification risks signature incompatibility with the forms that depend on it.