Search Results update_requisition

Overview

PO_REQ_DOCUMENT_UPDATE_GRP is a PL/SQL package body owned by the APPS schema in Oracle E-Business Suite. The "GRP" suffix classifies it as a group-type API, meaning it exposes a higher-level entry point that coordinates lower-level validation and processing logic rather than performing all work inline. Its business function is to apply updates to existing requisition documents within the Purchasing module. When a user or process needs to modify requisition header or line attributes — pricing, quantities, distribution details, or status-related fields — this package serves as the orchestration layer that standardizes input validation, invokes the underlying business checks, and routes the changes to the appropriate update logic.

The package header comment (revision 115.1, dated 2003) indicates the body dates to the earlier Purchasing code line and is still shipped in the 12.1.1 and 12.2.2 file systems. It is documented in ETRM with an API classification of GRP and includes debug instrumentation controlled by the AFLOG_ENABLED profile option, allowing FND logging to be enabled for diagnostics without code changes.

Key Procedures and Functions

ETRM documents a single public procedure for this package: UPDATE_REQUISITION. This is the primary entry point for applying requisition changes. Based on the group pattern and the internal validate_inputs helper shown in the source excerpt, UPDATE_REQUISITION accepts a requisition changes record that carries header-level and line-level change sets, validates them, and then performs the update. Parameter lists are not reproduced here; the documented contract is limited to the procedure name and its role as the update driver.

The internal helper validate_inputs performs input integrity checks before any write occurs. Documented validations include confirming that the header ID and line ID input tables are the same size, and enforcing that each entity supplies a mandatory Requisition Header ID. Line information is treated as optional, but a header is always required. Detailed validation rules are maintained in the companion package PO_REQ_DOCUMENT_CHECKS_PVT, specifically its req_status_check routine, which validate_inputs calls. Null line-change tables are padded to the line count using dummy collections so that downstream logic can safely index every row, and a progress variable (l_progress) is maintained for error tracing.

Tables Accessed

ETRM records one table referenced through an APPS synonym: PLITBLM. This is an FND/PLSQL internal table used as a generic table-of-varchar2 structure, and its presence reflects the package's use of PL/SQL collection plumbing rather than a direct read or write of a business table. The actual requisition rows are persisted by the underlying requisition DML logic invoked through the change-record structures (PO_REQ_CHANGES_REC_TYPE), not directly by this group package. Administrators should therefore not expect this body to contain direct INSERT or UPDATE statements against PO_REQUISITION_HEADERS_ALL or PO_REQUISITION_LINES_ALL in the documented metadata.

Usage Notes

Because it is a group API, UPDATE_REQUISITION is normally invoked from Oracle Purchasing forms or from other server-side packages rather than called directly by end users. ETRM records that this package body is referenced by two other packages, confirming it sits beneath higher-level requisition workflows. Typical invocation scenarios include the Requisition form (when a buyer or requester modifies a saved requisition), approval-driven status updates routed through the requisition checks package, and custom extensions that need to apply corrections to requisition data using supported APIs. In Oracle EBS 12.1.1 and 12.2.2 the object resides in the APPS schema and should be called through the APPS synonym. Custom code should pass a properly populated requisition changes record, check the returned status and message count, and respect the API version parameter. Enabling AFLOG_ENABLED is recommended during troubleshooting, as the body writes debug output through FND logging keyed by the package name prefix.