Search Results delete_req

Overview

APPS.PO_REQS_SV is a server-side PL/SQL package in Oracle E-Business Suite Purchasing (PO) that encapsulates all server logic required to access and manipulate the requisitions entity. As the header comment documents, the package "contains all server side procedures that access the requisitions entity," and it is declared with AUTHID CURRENT_USER, meaning it executes with the privileges of the invoking user rather than the defining schema. This design makes it a shared, reusable service layer invoked primarily by the Purchasing approvals and control forms rather than by end users directly.

The package’s central business responsibility is supporting the requisition approval and control workflow: querying the current authorization status of a requisition, locking the header row to prevent concurrent modification during a status change, updating header status fields based on a control action, and performing related insert, update, and delete operations against the requisition structure. It is classified in ETRM under the generic API classification OTHER, indicating it is not a formally published or supported public API but an internal server package. Three other packages reference it, which confirms it functions as a dependency in the requisition control call stack.

Key Procedures and Functions

The package exposes nine documented procedures and functions. Descriptions below reflect the documented intent; where the metadata supplies only the name, the purpose is inferred from the requisition-control context.

• lock_row_for_status_update — Locks the target row in PO_REQUISITION_HEADERS for update, used by the approvals and control forms to serialize status changes and prevent lost updates.
• get_reqs_auth_status() — Retrieves the requisition authorization status; typically called before a control action to determine the current state.
• update_reqs_header_status — Updates the requisition header status fields based on a control action and reason, recording action history codes. The documented algorithm shows it sets the header authorization status to CANCELLED when the control action is CANCEL and all lines are closed, and handles cases where lines remain on an open PO shipment.
• delete_children() — Removes the child records (lines and distributions) associated with a requisition, used as a prerequisite to deleting the parent.
• delete_req() — Performs deletion of a requisition. This is the procedure matched by the user’s search term "delete_req" and is the primary entry point for requisition deletion logic in this package.
• insert_req() — Inserts a requisition record, creating the header structure on which subsequent operations act.
• update_oe_flag() — Updates an order-entry related flag on the requisition, reflecting purchasing/order-entry integration state.

Tables Accessed

The package operates against the core Purchasing requisition tables accessed through APPS synonyms:

• PO_REQUISITION_HEADERS — the requisition header; locked and updated by the status procedures and the target of insert/delete.
• PO_REQUISITION_LINES — requisition lines; examined to determine whether all lines are closed and removed by delete_children.
• PO_REQ_DISTRIBUTIONS — requisition distributions; child records maintained and deleted alongside lines.
• PO_ACTION_HISTORY — records the action history codes associated with control actions, supporting traceability of status changes.

Usage Notes

PO_REQS_SV is invoked by the Purchasing requisition approvals and control forms whenever a user approves, rejects, returns, or cancels a requisition, and by the server-side logic that performs requisition deletion and insertion. Because it is not a formally supported public API, custom code should exercise caution: direct calls can bypass required concurrency-control and history-recording behavior. Customizations that must delete or manipulate requisitions should prefer the same entry points the forms use, ensuring lock_row_for_status_update is honored and action history is written. In 12.1.1 and 12.2.2 the package remains a server-side internal component under APPS, consistent with its original header revision dating to 2005.