Search Results po_unique_identifier_control




Overview
Explore in AI Chat

Overview

APPS.PO_REQUISITION_HEADERS_PKG is the primary PL/SQL API package for managing the header records of purchase requisitions in Oracle E-Business Suite Release 12.1.1 and 12.2.2. A purchase requisition represents an internal request to procure goods or services, and its header stores controlling information such as the requisition number (Segment1), preparer, authorization status, active date range, document type, description, cancel flag, and the descriptive flexfield attribute columns. This package encapsulates the insert, delete, validation, and summarization logic required to maintain rows in the PO_REQUISITION_HEADERS table without requiring callers to manage primary key generation, WHO columns, or MOAC (Multi-Org Access Control) context directly.

The package header in the release 12 code line carries the signature marker referencing <R12 MOAC>, indicating that the org_id parameter was introduced to support the multi-org security model that governs which operating unit owns each requisition. The body header comment ($Header: POXRIH1B.pls 120.5) identifies it as a non-shipped (noship) internal component of the Purchasing (PO) module, classified under ETRM as API classification OTHER.

Key Procedures and Functions

  • INSERT_ROW — Creates a new requisition header row. It accepts the full set of requisition header attributes, including preparer, segment values, active dates, authorization status, type lookup code, cancel flag, closed code, interface source information, the descriptive flexfield attributes (Attribute1 through Attribute15), and p_org_id. It generates the requisition_header_id from the PO_REQUISITION_HEADERS_S sequence and returns the ROWID and generated identifier to the caller.
  • DELETE_ROW — Removes a requisition header identified by its primary key, providing the controlled deletion path for header records.
  • GET_REAL_SEGMENT1 — Derives or returns the effective requisition number (Segment1) for a requisition, accounting for the internal numbering behavior that the base table may store indirectly.
  • CHECK_UNIQUE — Validates uniqueness constraints on requisition header values, typically the requisition number within the operating unit, before insert or update processing proceeds.
  • GET_REQ_TOTAL — Returns the aggregated monetary total for a requisition, derived from its associated requisition lines, and is commonly used by approval and display logic.

Tables Accessed

  • PO_REQUISITION_HEADERS — The base table holding requisition header rows; the package performs the insert, delete, and lookup operations against it.
  • PO_REQUISITION_HEADERS_S — The sequence used to generate unique requisition_header_id values during insert processing.
  • PO_REQUISITION_LINES — The requisition line table, read to compute requisition totals for GET_REQ_TOTAL.
  • PO_HISTORY_REQUISITIONS — The requisition action history table, referenced to support auditing or history-related processing.
  • DUAL — Used in the sequence-fetch cursor (SELECT po_requisition_headers_s.nextval FROM sys.dual) to obtain the next primary key value.

Usage Notes

PO_REQUISITION_HEADERS_PKG is an internal, non-shipped API rather than a formally published public interface. It is referenced by five other packages within the Purchasing application and is invoked indirectly through the Requisition entry and maintenance forms, concurrent programs that import or process requisitions, and workflow-driven approval or return activities that update authorization status and header flags. Custom code should generally prefer the supported Requisition open interfaces or the documented PO_REQUISITION_HEADERS_APIS / PO_REQUISITION_HEADERS_APIS2 public packages rather than calling this body directly. Where direct invocation is necessary, callers must respect the MOAC org_id parameter so that the correct operating unit context is applied and multi-org security is not bypassed. Because the package is marked noship and versioned at 120.5, behavior may vary across release levels, and any custom dependency on it should be regression-tested against each EBS 12.1.1 and 12.2.2 upgrade.