Search Results cancel_document

Overview

APPS.PO_WIP_INTEGRATION_GRP is a Group (GRP) type PL/SQL package body in the Oracle E-Business Suite Purchasing and Work in Process integration layer. Its principal role is to expose a controlled, API-form interface between Oracle Purchasing documents (Purchase Orders, Purchase Agreements, and Releases) and the WIP-related document change workflow, allowing callers to apply validated changes to these documents and to cancel them where permitted. The package is a thin wrapper rather than a business-rules engine: UPDATE_DOCUMENT, for example, delegates the real validation and application of change requests to PO_DOCUMENT_UPDATE_GRP.update_document, meaning the actual integrity, approval, and derived-change logic resides in the Purchasing change API.

The package conforms to the standard Oracle EBS API conventions, including compatible-version checking (FND_API.Compatible_API_Call), an p_init_msg_list flag to control FND_MSG_PUB.initialize, the standard x_return_status out parameter, and a debug log toggled by the AFLOG_ENABLED profile option. These conventions make it safe to call from forms, concurrent programs, and custom PL/SQL, with errors and messages surfaced through the FND message stack.

Key Procedures and Functions

The ETRM metadata documents four procedures in this package:

• UPDATE_DOCUMENT — Invokes the PO Change API to validate and apply requested changes, together with any derived changes, to a Purchase Order, Purchase Agreement, or Release. It also governs whether submission checks run and whether approvals are launched, and it returns API errors through a PO_API_ERRORS_REC_TYPE out parameter.
• CANCEL_DOCUMENT — Cancels a Purchasing document through the same integration layer. This is the procedure surfaced when users search for "cancel_document," and it is the counterpart to UPDATE_DOCUMENT for document lifecycle termination.
• UPDATE_REQUISITION — Applies validated changes to a requisition, following the same API pattern so that requisition updates originating from WIP-side processes are routed through the standard PO change validation path.
• CANCEL_REQUISITION — Cancels a requisition, complementing UPDATE_REQUISITION for requisition lifecycle management.

Each procedure inherits the standard wrapper behavior: version compatibility screening, optional message-stack initialization, and propagation of x_return_status to the caller.

Tables Accessed

The documented table reference for this package is PLITBLM (accessed via an APPS synonym). PLITBLM is the standard Oracle EBS client-event / message-logging interface table used by the FND message and debug facilities, so its involvement here is consistent with the package's FND_MSG_PUB and AFLOG_ENABLED logging behavior rather than with direct storage of purchasing data. The Purchase Order, agreement, release, and requisition rows themselves are manipulated indirectly by the underlying PO Change API (PO_DOCUMENT_UPDATE_GRP and its dependencies); this wrapper package does not itself contain the table-maintenance logic.

Usage Notes

Because PO_WIP_INTEGRATION_GRP is classified as a GRP (group) API, it is intended as the supported entry point for programmatic changes to purchasing documents with WIP involvement. Typical callers include Oracle Purchasing and WIP forms, concurrent programs performing mass document updates or cancellations, and custom extensions requiring validated PO, agreement, release, or requisition changes.

When invoking CANCEL_DOCUMENT or UPDATE_DOCUMENT, callers should always inspect x_return_status and drain messages from the FND stack; the boolean conversion of p_init_msg_list permits message reuse inside iterative loops. The package is referenced by one other package, indicating it is a dependency in the WIP-integration call chain and should be modified or replaced only with that dependency in mind. From a release standpoint, the source header (115.3, dated 2004) indicates the implementation predates 12.1.1 and remains stable across 12.1.1 and 12.2.2, although the documented ETRM metadata for 12.2.2 should be treated as authoritative for procedure signatures.