Search Results p_request_id

Overview

OEXPURGE is an Oracle Order Management (OM) utility package owned by APPS and classified as OTHER within the ETRM reference for Oracle EBS 12.1.1 and 12.2.2. Its purpose is to support the archival and deletion of obsolete sales order data from the transactional schema. Order Entry generates a substantial volume of header, line, pricing, approval, freight, and RMA interface records over time; OEXPURGE provides the programmatic logic that evaluates eligibility for purge and physically removes qualifying rows. The package is invoked as part of the Order Purge workflow, in which a purge request is submitted, validated against open-order and open-invoicing conditions, and then executed against the selected order population. Because the purge process is destructive, the package is composed primarily of granular row-level purge functions that isolate individual child tables, together with validation functions that prevent removal of orders still referenced by downstream activity.

Key Procedures and Functions

The documented interface contains thirty-one procedures and functions organized into three functional groups.

• Selection and validation: SELECT_PURGE_ORDERS accepts an order number range, creation and last-update date ranges, an order category, and an order type, and drives selection of candidate orders for purge. SO_CHECK_OPEN_ORDERS, SO_CHECK_OPEN_INVOICED_ORDERS, SO_CHECK_OPEN_DEMAND_ORDERS, and SO_CHECK_OPEN_RETURNS evaluate whether an order, identified by number and type name, is still associated with open orders, open invoices, open demand, or open returns respectively; these act as gating checks before deletion proceeds.
• Purge execution: SO_ORDER_PURGE performs the master purge flow, accepting two dummy arguments and a commit point that controls intermediate commits to limit undo consumption. The remaining procedures and functions each target a specific child entity: SO_PURGE_HEADERS, SO_PURGE_LINES, SO_PURGE_LINE_DETAILS, SO_PURGE_LINE_SERVICE_DETAILS, SO_PURGE_LINE_APPROVALS, SO_PURGE_ORDER_APPROVALS, SO_PURGE_ORDER_CANCEL_LINES, and SO_PURGE_ORDER_CANCELLATIONS.
• Assignment, holds, and RMA: SO_PURGE_HOLD_RELEASES, SO_PURGE_HOLD_SOURCES, SO_PURGE_FREIGHT_CHARGES, SO_PURGE_NOTE_REFERENCES, and SO_PURGE_ORDER_APPROVALS remove ancillary references, while SO_PURGE_MTL_SO_RMA_INTERFACE and SO_PURGE_MTL_SO_RMA_RECEIPTS clean up return material authorization staging and receipt records.

Notably, the child-level purge functions accept a p_request_id parameter. This is the concurrent request identifier for the running Order Purge program, used to correlate purged rows with the submission logged in the concurrent manager and to support diagnostics and reporting on what a given purge run removed. SO_PURGE_FREIGHT_CHARGES, SO_PURGE_HEADERS, SO_PURGE_HOLD_RELEASES, SO_PURGE_HOLD_SOURCES, SO_PURGE_LINE_APPROVALS, SO_PURGE_LINE_DETAILS, SO_PURGE_LINE_SERVICE_DETAILS, and SO_PURGE_LINES all follow this convention, receiving a parent identifier (header, line, picking header, release, or source) and the parent request ID. Each returns a NUMBER, signaling success or the count of rows affected.

Tables Accessed

The package operates against the core Order Management tables and several related schemas through APPS synonyms:

• Order data: MTL_SALES_ORDERS serves as the authoritative order repository, while MTL_DEMAND supplies demand and reservation context used during open-order validation and header elimination.
• RMA: MTL_SO_RMA_INTERFACE and MTL_SO_RMA_RECEIPTS hold return authorization staging and receipt information cleaned by the RMA purge routines.
• Billing and returns: RA_CUSTOMER_TRX and RA_CUSTOMER_TRX_LINES are referenced to confirm invoice status before deletion, supporting SO_CHECK_OPEN_INVOICED_ORDERS.
• Order detail tables: SO_EXCEPTIONS, SO_EXCEPTIONS_S, SO_FREIGHT_CHARGES, SO_HOLD_RELEASES, SO_LINE_APPROVALS, SO_LINE_DETAILS, and SO_LINE_SERVICE_DETAILS hold header and line-adjacent records removed by the granular purge functions.
• Concurrent processing: FND_APPLICATION and FND_CONCURRENT_PROGRAMS tie the purge activity to the registered concurrent program definition and application context, enabling the request ID to be resolved and audited.

Usage Notes

OEXPURGE is not typically called interactively. It is executed through the Order Purge concurrent program in Oracle Order Management, which supplies the request ID captured by the child purge functions. Administrators select the order population to purge using the parameters of SELECT_PURGE_ORDERS — order number range, creation date window, last-update window, order category, and order type — and the concurrent manager then drives SO_ORDER_PURGE to perform the deletions with periodic commits governed by the commit point parameter.

The validation functions operate as pre-purge safeguards. Standard practice is to run the purge in report-only mode first so that open orders, invoiced orders, outstanding demand, and open returns are excluded rather than deleted, since removing such records would corrupt order lifecycle and billing integrity. Because the package is AUTHID CURRENT_USER and classified as OTHER rather than a supported public API, it should not be called directly from custom code without thorough regression testing in a cloned environment; Oracle reserves the right to change its internal signatures. Custom extensions should instead rely on documented Order Management APIs, using OEXPURGE only through its supported concurrent program entry point. Finally, because the operation is irreversible, a full schema or table-level backup should precede any production purge submission.