Search Results close_old_notif

Overview

POS_WCAPPROVE_PVT is a private PL/SQL package in the APPS schema that supports the workflow-driven approval of Workforce Confirmation Receipts (WCR) and related receiving documents within Oracle E-Business Suite. The package header comment defines its purpose precisely: "APIs called from the receiving processor to approve WCR document." It acts as the procedural backbone that Oracle Workflow invokes at runtime to evaluate, route, and record approval decisions on receiving transactions.

The API classification of PVT indicates that this is an internal, non-public package. Oracle does not document it for direct customer invocation, and its interfaces may change between releases without notice. It is embedded in the 12.1.1 and 12.2.2 code lines and is referenced by one other package, confirming its role as a lower-level service rather than an entry point. The package header carries the header string $Header: POSVWCAS.pls 120.6 2006/01/09, showing it was created on 15-Feb-2005 and has been maintained since, which means its core workflow logic predates the 12.1.1 release and is shared across the 12.1.1 and 12.2.2 code lines.

Key Procedures and Functions

The documented 39 procedures and functions fall into several functional groups:

• Workflow lifecycle: START_WF_PROCESS launches the approval workflow for a document; SET_STARTUP_VALUES initializes the workflow item attributes and activity variables; GET_WC_ATTRIBUTES retrieves the receipt attributes needed to drive routing decisions.
• Notification handling: CLOSE_OLD_NOTIF closes stale notifications for a document when a newer action supersedes them, preventing approvers from acting on obsolete work items.
• Workflow-info maintenance: UPDATE_WORKFLOW_INFO updates the workflow item and status information for the in-flight approval.
• Routing: GET_NEXT_APPROVER determines the next approver in the approval hierarchy.
• Decision processing: APPROVE_OR_REJECT, APPROVE_SHIPMENT_LINES, REJECT_SHIPMENT_LINES, and REJECT_DOC apply approval or rejection outcomes to the affected document and its shipment lines.
• Approval list handling: UPDATE_APPROVAL_LIST_RESPONSE writes the approver's response back to the approval list.
• Action history: INSERT_ACTION_HISTORY, UPDATE_ACTION_HISTORY, UPDATE_ACTION_HISTORY_APPROVE, UPDATE_ACTION_HISTORY_REJECT, UPDATEACTIONHISTORY, UPDATEPOACTIONHISTORY, INSERTPOACTIONHISTORY, and INS_ACTIONHIST_SUBMIT record the audit trail of who approved or rejected what and when.
• Utility: GET_USER_NAME resolves the user name for display and audit purposes.

Tables Accessed

The package reads and writes a broad set of APPS-synonymed tables. PO_ACTION_HISTORY, PO_DISTRIBUTIONS_ALL, and PO_DOC_STYLE_HEADERS anchor the purchasing and action-history side, recording approval decisions and, where relevant, distributing the resulting encumbrance or charge information. FND_USER, PER_ALL_PEOPLE_F, PER_ALL_ASSIGNMENTS_F, and PER_ASSIGNMENT_STATUS_TYPES supply approver identity, assignment, and active-status data used to determine valid approvers and resolve user names. HR_LOCATIONS_ALL and HR_LOCATIONS_ALL_TL provide location descriptions used in document detail and notifications. FINANCIALS_SYSTEM_PARAMETERS supplies system-level defaults, particularly currency and period controls relevant to receiving approvals. FND_ATTACHED_DOCUMENTS supports document attachments surfaced to the approver. MTL_UNITS_OF_MEASURE provides UOM detail for receipt lines. PA_PROJECTS_ALL, GMS_AWARDS_ALL, and GMS_AWARD_DISTRIBUTIONS support project- and grant-related receiving, ensuring that approvals fall through to project or award context where applicable.

Usage Notes

This package is not intended for direct customer invocation. It is called by the receiving processor and by Oracle Workflow itself, which invokes the notification and function-activity procedures using the standard Workflow callback signature: itemtype, itemkey, actid, funcmode, and resultout. UPDATE_WORKFLOW_INFO, GET_WC_ATTRIBUTES, GET_NEXT_APPROVER, CLOSE_OLD_NOTIF, and the approval, rejection, and action-history procedures are all invoked as workflow function activities during the approval process. The package is referenced by one other package, indicating a layered dependency. Because it is a PVT package, customizations should not call it directly; instead, extensions should target documented public APIs or add workflow activities that invoke supported interfaces. Any direct dependency risks breakage on upgrade, and the package's presence in both 12.1.1 and 12.2.2 should not be read as a guarantee of interface stability between those releases.