Search Results get_po_req_approved_msg

Overview

PO_WF_DOCUMENT is an Oracle E-Business Suite PL/SQL package owned by the APPS schema and classified as an "OTHER" API within the ETRM repository. Its source header (POXWMSGS.pls, version 115.2) identifies it as a message-generation utility for the Oracle Purchasing workflow. Its single purpose is to construct the displayable message content and document-type identifiers that appear in Oracle Workflow notifications routed to requisition approvers. When a requisition approval workflow raises an event — submission for approval, approval, rejection, or the absence of a qualified approver — this package assembles the notification body that the approver or requisition owner sees in the Worklist or e-mail notification.

The package is declared AUTHID CURRENT_USER, meaning its SQL executes with the privileges of the invoking session rather than as definer-rights APPS code. All six documented procedures share an identical call signature shape, passing in a document identifier and a display_type parameter together with two IN OUT NOCOPY output parameters: the assembled document text and its document_type classification. The display_type argument is the caller-supplied directive the procedures use to determine how each message body should be formatted — for example, plain text suitable for e-mail versus the Worklist presentation form. Because it is an IN parameter, the workflow notification activity supplies this value at runtime, and the procedure returns the correspondingly formatted content.

Key Procedures and Functions

The package exposes six documented procedures, all of the form get_*_msg or get_*_details, each accepting document_id and display_type as inputs and returning document and document_type as output:

• GET_PO_REQ_APPROVE_MSG — Builds the notification message presented when a requisition is sent for approval, i.e., the "approve this requisition" task notification.
• GET_PO_REQ_APPROVED_MSG — Builds the message confirming that a requisition has been approved.
• GET_PO_REQ_NO_APPROVER_MSG — Builds the notification issued when no valid approver can be resolved for the requisition (for example, an empty approval hierarchy).
• GET_PO_REQ_REJECT_MSG — Builds the message accompanying a requisition rejection.
• GET_REQ_LINES_DETAILS — Assembles the requisition line-level detail that is embedded inside the approval notification, supplying quantity, item, and distribution information to the approver.
• GET_ACTION_HISTORY — Assembles the approval action-history section of the notification, showing prior approver actions and timestamps.

Internally, helper routines obtain the document text and document classification consistent with the supplied display_type, so the same business event can render differently across Worklist and e-mail channels.

Tables Accessed

Through APPS synonyms, the package reads requisition data to populate notification content:

• PO_REQUISITION_HEADERS, PO_REQUISITION_LINES, PO_REQ_DISTRIBUTIONS_ALL — Source of header, line, and distribution detail shown in the approval and line-detail messages.
• PO_ACTION_HISTORY — Supplies the prior approval actions enumerated by GET_ACTION_HISTORY.
• MTL_SYSTEM_ITEMS_KFV — Resolves item descriptions for the line details.
• FND_CURRENCIES — Provides currency information for monetary display.
• WF_ITEMS — The Oracle Workflow item table, used to correlate the notification with its workflow item type, item key, and notification context.

Usage Notes

PO_WF_DOCUMENT is not a user-facing API. It is invoked by the Oracle Purchasing requisition approval workflow as the message-generation callback for notification activities. Each workflow function activity passes the requisition document identifier and a display_type value and receives the rendered message back in the document and document_type output parameters for display in the Worklist, e-mail, or other notification channel. The ETRM metadata records zero packages referencing PO_WF_DOCUMENT, confirming that its callers are workflow definitions rather than other PL/SQL packages. Customizations should be limited to extending or wrapping the message content, as altering the shared display_type handling affects every requisition notification produced by the workflow.