Search Results rcv_shipment_headers_pkg




Overview

RCV_SHIPMENT_HEADERS_PKG is a PL/SQL package owned by the APPS schema in Oracle E-Business Suite, classified under the ETRM documentation as an "OTHER" API type. It provides the low-level Data Manipulation Language (DML) layer for the RCV_SHIPMENT_HEADERS entity, the master table that stores receipt header information within Oracle's Receiving (RCV) module. Each row in RCV_SHIPMENT_HEADERS represents a receipt or shipment header, capturing supplier, shipment, receipt, and organizational context that downstream receipt lines, transactions, and accounting entries depend upon.

The package is a thin, single-table access layer rather than a business-event API. Its role is to encapsulate the physical insert, update, delete, and locking operations against the receipt header and its associated _S (sequence/audit) table, so that other receiving components—most notably the public receipt API FLM_RECEIPT_PUB—can manipulate receipt header records through a controlled, consistent code path. Because it is documented as referenced by only one other packaged object, its scope is intentionally narrow: it supports the receipt header maintenance performed by higher-level receiving processes rather than exposing a full spectrum of business validation rules.

Key Procedures and Functions

The ETRM metadata documents four procedures in this package, all standard DML primitives:

  • INSERT_ROW — Creates a new shipment/receipt header record, writing the header attributes supplied by the caller into RCV_SHIPMENT_HEADERS. It is the entry point used when a new receipt header must be established before receipt lines can be attached.
  • UPDATE_ROW — Modifies the attributes of an existing shipment header identified by its primary key, allowing callers to change header-level information after the receipt has been created.
  • DELETE_ROW — Removes a shipment header record. This is typically invoked during correction or purge activity when a receipt header is no longer valid, subject to the referential constraints imposed by dependent receipt lines and transactions.
  • LOCK_ROW — Acquires a row-level lock on a shipment header, typically via SELECT ... FOR UPDATE semantics, to prevent concurrent modification. This supports serialized access when two processes or sessions attempt to update the same receipt header.

The documented metadata does not publish explicit parameter lists for these procedures, so callers should inspect the package specification in the target environment rather than assume argument signatures.

Tables Accessed

The package operates against the following objects, referenced through APPS synonyms:

  • RCV_SHIPMENT_HEADERS — The base table holding receipt/shipment header rows. All four procedures target this table directly.
  • RCV_SHIPMENT_HEADERS_S — The companion sequence table that supplies or stores the primary key values used when inserting new header rows, ensuring unique, system-generated identifiers.
  • RCV_PARAMETERS — Referenced to obtain receiving configuration and setup values, such as defaulting rules or organizational parameters that influence header processing.

Usage Notes

RCV_SHIPMENT_HEADERS_PKG is an internal, low-level component. It is invoked by the public receipt API FLM_RECEIPT_PUB, which is the documented referencing package, rather than being called directly by end-user forms or concurrent programs. Standard Oracle Receiving transactions—receipt creation, correction, and cancellation—flow through higher-level APIs and forms, which in turn delegate the physical header DML to this package.

The package also references itself internally, reflecting shared utility logic reused across its procedures. Customizations and extensions should avoid bypassing the public APIs to call RCV_SHIPMENT_HEADERS_PKG directly; doing so risks omitting validation, defaulting, and audit-table maintenance performed by the calling layer. When custom code must manipulate receipt headers, the recommended practice is to invoke FLM_RECEIPT_PUB or the appropriate Oracle Receiving public API, letting this package handle the underlying header persistence. Because the documentation is limited, developers should validate procedure signatures and behavior against the specific 12.1.1 or 12.2.2 instance before relying on undocumented aspects.