Search Results po_req_document_cancel_grp




Overview
Explore in AI Chat

Overview

PO_REQ_DOCUMENT_CANCEL_GRP is a PL/SQL package owned by the APPS schema in Oracle E-Business Suite Release 12.1.1 and 12.2.2. Its classification within the ETRM repository is that of a Group or "GRP" package, a naming convention Oracle uses for packages that aggregate and expose a discrete set of related programmatic operations rather than serving as a single-purpose API. The object is documented with a status of VALID, indicating it is a supported and compiled component of the procurement module.

The business function of this package centres on the controlled cancellation of requisition documents. In the Oracle Purchasing and iProcurement flow, requisition documents progress through approval and eventual conversion into purchase orders or work orders. When a requisition must be withdrawn — for example because the underlying demand has disappeared, funding was withdrawn, or the document was created in error — the cancellation must be propagated to the downstream integration points that already consumed it. This package provides the entry point for that cancellation activity, encapsulating the logic required to mark a requisition document as cancelled and to notify the integration layers that depend on it.

Key Procedures and Functions

The ETRM metadata documents a single procedure within this package:

  • CANCEL_REQUISITION — the primary and only documented entry point of the package. As its name implies, it performs the cancellation of a requisition document. It is the procedure that callers invoke to terminate an active requisition through programmatic means rather than through manual form-based cancellation.

Consistent with the GRP classification, no additional public procedures or functions are documented. Parameter lists are not enumerated in the available metadata and should be confirmed against the deployed package specification before any custom invocation.

Tables Accessed

The documented dependency information records that PO_REQ_DOCUMENT_CANCEL_GRP references APPS.PO_TBL_NUMBER. PO_TBL_NUMBER is a standard Oracle Purchasing PL/SQL table type that carries numeric identifiers, typically used to pass collections of document or line identifiers between program units. Its presence indicates that the cancellation logic operates against requisition header or line identifiers supplied in set-based form.

Beyond the named table type, the package depends on the SYS.STANDARD package, which is the implicit PL/SQL standard library present in every compiled unit and confirms that no exotic external dependencies are involved. The metadata does not enumerate direct reads or writes to base tables such as PO_REQUISITION_HEADERS_ALL or PO_REQUISITION_LINES_ALL; however, given that the package is documented as cancelling requisitions, such base tables are necessarily affected indirectly through the procedure's execution path.

Usage Notes

PO_REQ_DOCUMENT_CANCEL_GRP is invoked programmatically rather than directly by end users. The dependency listing shows that it is referenced by two other packages in the APPS schema: PO_OM_INTEGRATION_GRP and PO_WIP_INTEGRATION_GRP. These integration packages handle the interface between Oracle Purchasing and, respectively, the Order Management and Work in Process modules. This confirms the intended invocation pattern: when an internally sourced requisition — one feeding an internal sales order or a work order — is cancelled, the integration packages call CANCEL_REQUISITION so that the downstream demand in Order Management or WIP is correspondingly released or reversed.

Custom code should not attempt to replicate this cancellation logic directly against the requisition tables. Where an external or bolt-on process must cancel a requisition, the appropriate approach is to invoke PO_REQ_DOCUMENT_CANCEL_GRP.CANCEL_REQUISITION after confirming the signature from the package specification, thereby preserving the integration callbacks that keep OM and WIP synchronized. Because the package forms part of the standard integration chain, it should be treated as Oracle-owned and patched only through standard EBS patching.