Search Results call_funds_reversal




Overview
Explore in AI Chat

Overview

PO_MODIFY_REQUISITION_PVT is a private PL/SQL package in the APPS schema whose name carries the PVT suffix denoting it as the internal implementation layer of the Purchasing requisition modification API. It provides the procedural logic that supports split, create, update, and delete operations against requisition lines within Oracle Purchasing. The package is classified under the Oracle E-Business Suite API architecture, where public (PUB) packages expose documented interfaces to callers and private (PVT) packages encapsulate the underlying business logic, validation, and DML that those public interfaces invoke. In this capacity, PO_MODIFY_REQUISITION_PVT handles the mechanics of manipulating requisition line records, coordinating the financial and distribution records that accompany a requisition line, and standardizing error propagation through the FND_API framework.

The package is documented against Oracle EBS 12.1.1 and 12.2.2, and its status is VALID in the ETRM repository. Its dependency graph confirms a tight coupling to FND_API error-handling utilities, the PO_TBL_NUMBER and PO_TBL_VARCHAR2000 PL/SQL table types used for bulk parameter passing, and the STANDARD package. The package is referenced by zero other packages, consistent with its private designation; it is intended to be called by the requisition modification public API rather than directly by external code.

Key Procedures and Functions

Four procedures are documented in the package metadata, each corresponding to a distinct stage of the requisition modification lifecycle:

  • CREATE_REQUISITION_LINES — Creates new requisition line records as part of a modification transaction, populating the requisition line tables and associated attribute structures. It supports the addition of lines to an existing requisition during an online or programmatic modification.
  • SPLIT_REQUISITION_LINES — Implements requisition line splitting, dividing an existing line into multiple lines while preserving the relationship between the original and resulting distribution records. The presence of PO_REQ_SPLIT_LINES_GT among the referenced tables confirms use of a global temporary table to stage split-line data before final processing.
  • POST_MODIFY_REQUISITION_LINES — Performs the final posting and validation of modification changes after create, split, update, or delete operations have been staged. This represents the commit-oriented phase of the modification workflow, ensuring consistency across the affected requisition tables.
  • CALL_FUNDS_REVERSAL — Handles the reversal of funds reservations associated with requisition lines. When requisition amounts or distributions change, or lines are cancelled, this procedure interacts with budgetary control to reverse the corresponding encumbrance or funds check.

No parameter signatures are documented in the available metadata, and none should be assumed.

Tables Accessed

The package operates against a focused set of requisition and purchasing tables, referenced through APPS synonyms. The primary DML targets are PO_REQUISITION_HEADERS_ALL, PO_REQUISITION_LINES_ALL (with its PO_REQUISITION_LINES synonym and PO_REQUISITION_LINES_S sequence), and PO_REQ_LINES_EXT_B, which stores the descriptive flexfield and extension attribute data for requisition lines. PO_REQ_SPLIT_LINES_GT serves as the staging global temporary table for split operations. POR_ITEM_ATTRIBUTE_VALUES holds item attribute values associated with requisition lines, while PO_UDA_AG_TEMPLATE_USAGES supports user-defined attribute template usage. PO_ONLINE_REPORT_TEXT is used for online reporting output, FINANCIALS_SYSTEM_PARAMETERS supplies financial system configuration, and FND_NEW_MESSAGES provides message retrieval for error and informational messages. DUAL and PLITBLM appear as standard PL/SQL infrastructure references.

Usage Notes

As a PVT package, PO_MODIFY_REQUISITION_PVT is not intended for direct invocation by customer-written code, concurrent programs, or forms. It is called internally by the public requisition modification API, which is the supported entry point exposed to Oracle Purchasing forms and integrating applications. Customizations that bypass the public API and call this package directly risk breaking the transactional integrity maintained by POST_MODIFY_REQUISITION_LINES and may not correctly trigger funds reversal logic. Organizations extending requisition modification should instead invoke the supported public API and rely on this package transparently. The presence of FND_API dependencies indicates that errors are surfaced through the standard EBS API exception and message stack, so callers should expect the conventional x_return_status and x_msg_count/x_msg_data reporting pattern when the public API wraps these procedures.