Search Results po_wf_req_notification




Overview

PO_WF_REQ_NOTIFICATION is an Oracle E-Business Suite PL/SQL package owned by the APPS schema that supports the Oracle Workflow notification infrastructure for the Purchasing requisition approval cycle. It is the requisition-side counterpart to PO_WF_PO_NOTIFICATION, generating and formatting the notification messages that approvers and preparers receive while a requisition moves through the approval hierarchy. The package assembles message bodies from transactional and reference data, resolves approval actions, and exposes action-history and line-detail content for rendering in notification and the associated notification response views. Its status is documented as VALID in the ETRM reference for 12.1.1 and 12.2.2, and it is classified under the generic OTHER API category rather than as a public callable API.

Key Procedures and Functions

The documented object exposes fourteen procedures and functions oriented toward message construction and workflow decision support:

Tables Accessed

The package reads its core approval state from PO_APPROVAL_LIST_HEADERS and PO_APPROVAL_LIST_LINES, with PO_ACTION_HISTORY supplying the audit trail of prior approval actions. Requisition and item detail is drawn from MTL_SYSTEM_ITEMS_KFV and MTL_UNITS_OF_MEASURE, while HR_LOCATIONS_ALL and PER_ALL_PEOPLE_F resolve people and location attributes. FND_USER, HZ_PARTIES, FND_LANGUAGES, FND_CURRENCIES and FND_LOOKUP_VALUES provide user, party, language, currency and lookup reference data. FND_ID_FLEX_SEGMENTS, FND_SEGMENT_ATTRIBUTE_VALUES and FINANCIALS_SYSTEM_PARAMETERS resolve key flexfield and system-level accounting configuration.

Usage Notes

PO_WF_REQ_NOTIFICATION is invoked indirectly by the Oracle Purchasing requisition approval workflow rather than called directly by end users. Notifications are produced when a requisition is submitted for approval, when an approver acts, and when the process terminates. The dependency metadata shows that PO_WF_PO_NOTIFICATION references this package and that the package references itself, indicating internal reuse across notification paths. Customizations should avoid direct modification of the seeded package; extensions are best implemented through workflow attribute customization or wrapper logic. The package is not documented as a public API for external integration, so custom code should treat its procedures as internal workflow services.