Search Results is_approval_list_empty

Overview

PO_APPROVAL_LIST_WF1S is an Oracle E-Business Suite PL/SQL package owned by the APPS schema that provides the workflow callback procedures supporting the requisition and purchase order approval list processing within the Web Requisition and Purchasing approval workflows. Its header, POXWAL1S.pls, dates to the original Web Requisition 4.0 approval extension, and the package remains a standard component in both EBS 12.1.1 and 12.2.2. The package is declared AUTHID CURRENT_USER, so its unqualified references to workflow and purchasing objects resolve through the invoking user's privileges and APPS synonyms.

Functionally, the package determines whether a preparer-defined approval list exists for a document, locates and assigns that list to the workflow item, constructs a default routing list when none exists, and rebuilds lists whenever the approval path must be recalculated. It also maintains the approval action history and resolves the next approver and final approval response. Because the procedures are designed as Standard Oracle Workflow function activities rather than as general-purpose APIs, each accepts the workflow standard signature of itemtype, itemkey, actid, and funcmode, and returns a result value consumed by the workflow engine to direct the process branch.

Key Procedures and Functions

The documented interface exposes twenty procedures and functions organized around four concerns.

• Existence and discovery: DOES_APPROVAL_LIST_EXIST checks whether an approval list is present for the requisition. FIND_APPROVAL_LIST searches for a list created by the preparer through Web Requisition, records the list identifier on a workflow attribute, and stamps the list with the workflow itemtype and itemkey. IS_APPROVAL_LIST_EMPTY tests whether the located list contains any approvers.
• List construction and rebuild: BUILD_DEFAULT_APPROVAL_LIST generates a default routing list. REBUILD_LIST_FORWARD, REBUILD_LIST_DOC_CHANGED, and REBUILD_LIST_INVALID_APPROVER reconstruct the list when an approver forwards the document, when the approver modifies the document, or when the current approver is no longer valid.
• Approver resolution: GET_NEXT_APPROVER returns the succeeding approver in sequence, while GET_APPROVAL_RESPONSE derives the final response outcome for the document.
• History and response maintenance: INSERT_ACTION_HISTORY, INSERT_RES_ACTION_HISTORY, and UPDATE_ACTION_HISTORY_APPROVE, _TIMEOUT, _APP_FWD, _FORWARD, and _REJECT record approval, rejection, timeout, and forwarding events. UPDATE_APPROVAL_LIST_RESPONSE and UPDATE_APP_LIST_RESP_SUCCESS persist the list-level response. CREATE_ATTACH_INFO_TEMP builds temporary attachment information. IS_DOCUMENT_MANAGER_ERROR_1_2 is the routine associated with the search term "is_document_manager_error_1_2"; it evaluates whether a document manager error of the 1-2 condition has occurred and returns a result used by the workflow to redirect processing.

Tables Accessed

The package reads and writes the following objects through APPS synonyms.

• PO_DOCUMENT_TYPES — supplies document type attributes used to qualify the approval routing.
• WF_ITEMS and WF_ACTIVITIES — provide workflow item state and activity definitions driving callback execution.
• WF_NOTIFICATIONS — records the approval notifications sent to approvers and their responses.
• WF_PROCESS_ACTIVITIES — supports process-level activity lookup during list rebuilds.
• PLITBLM — the PL/SQL index-by table type used for in-memory collections passed between the package and its callers.

Usage Notes

PO_APPROVAL_LIST_WF1S is invoked by the Oracle Workflow engine as function activities within the requisition and purchasing approval workflows, not directly from forms or concurrent programs. The workflow process definition references each procedure by name; the engine passes itemtype, itemkey, actid, and funcmode, and interprets the returned result to select the next branch. The package is referenced by one other package, and customization should be limited to wrapping or extending the documented entry points, since the procedures depend on the workflow item context being established before they are called. Direct invocation from custom code is possible only when the identical workflow parameters and item context are supplied.