Search Results get_real_segment1

Overview

APPS.PO_REQUISITION_HEADERS_PKG is the primary server-side PL/SQL package responsible for maintaining rows in the Oracle Purchasing requisition header entity. It encapsulates the insert and delete logic for the PO_REQUISITION_HEADERS table and supplies supporting utility routines used by the Purchasing forms, concurrent programs, and any custom code that must create or validate requisition headers programmatically. The package header carries the identifier POXRIH1S.pls and is owned by APPS, with the source header noting a 2005 revision; it remains the shipped interface for requisition header maintenance in Oracle EBS 12.1.1 and 12.2.2.

The package is classified as OTHER within the ETRM repository, indicating it is not a public, fully governed open interface such as PO_REQUISITIONS_INTERFACE, but rather an internal application-programming interface whose behavior is tightly coupled to the Purchasing schema. It is referenced by five other packages, confirming that requisition header manipulation is a shared dependency across Purchasing and adjacent modules.

Key Procedures and Functions

Six documented program units are exposed by the package specification:

• INSERT_ROW — Creates a new requisition header record. The signature enumerates the full attribute set of the header, including the requisition number (SEGMENT1, passed IN OUT NOCOPY because the value may be generated by the numbering logic), preparer, description, authorization status, note to authorizer, document type lookup code, transfer-to-Order-Entry flag, the fifteen descriptive flexfield attributes, the USSGL transaction code, government context, interface source columns, closed code, and manual flag. It also accepts the row identifier and requisition header identifier as IN OUT NOCOPY parameters and takes P_ORG_ID with a default of NULL for multi-org access control, reflecting the R12 MOAC model.
• DELETE_ROW — Removes a requisition header identified by its ROWID.
• GET_REAL_SEGMENT1 — Resolves the true (real) requisition number/segment value for a header. The source comment explicitly states that this procedure was created under Ben bug#465696 to resolve a performance problem, with a detailed explanation documented in POXRIHDB.pls. This is the routine most commonly referenced when developers search for get_real_segment1, since requisition numbering can differ from the stored value depending on document numbering setup and numbering overrides.
• CHECK_UNIQUE — Performs the uniqueness validation required before a requisition header can be persisted, ensuring no duplicate header is created.
• GET_REQ_TOTAL — Returns the aggregate monetary total for a requisition, summing the associated requisition lines.

Tables Accessed

The package reads and writes the requisition header tables PO_REQUISITION_HEADERS and its shadow table PO_REQUISITION_HEADERS_S, which stores the MLS/translated and historical column values. PO_REQUISITION_LINES is accessed to support header-level validation and to compute the requisition total via GET_REQ_TOTAL. PO_HISTORY_REQUISITIONS is used for maintaining the requisition audit/history trail. DUAL is used for single-row lookups and simple value resolution. All access is performed through APPS synonyms.

Usage Notes

PO_REQUISITION_HEADERS_PKG is invoked primarily by the Purchasing Requisitions form (POXRQVRQ/POXRIH) during header creation and deletion, and by requisition-related concurrent programs and workflow activities that must create headers outside of the form. Because it manipulates the base tables directly rather than through the open interface, custom code should invoke it with care: INSERT_ROW expects a fully populated attribute set, and the caller must supply a valid org context through P_ORG_ID in a multi-org environment. Developers resolving requisition numbering issues should call GET_REAL_SEGMENT1 rather than querying SEGMENT1 directly, since the stored value may be a temporary or placeholder number. DELETE_ROW should be used only where the requisition has no dependent lines that would violate integrity constraints.