Search Results prepare_doc

Overview

APPS.AHL_GENERIC_APRV_PVT is a private (PVT) PL/SQL package within the Oracle E-Business Suite Application Object Library / Oracle Quality and Approval Management family, specifically associated with the AHL (Product Development / Quality) application module. It implements the generic approval workflow engine that drives routing, notification, and status transition logic for approval-enabled AHL objects. The package acts as the procedural backbone behind Oracle Workflow item types that require multi-stage, rule-based approvals, allowing business objects to be submitted, approved, rejected, forwarded, or reverted according to configured approval rules.

Because the package is classified as PVT, its subprograms are not intended as public integration APIs. Instead, they are invoked internally by Oracle Workflow process definitions, wrapper APIs, and the AHL approval framework. The package is declared AUTHID CURRENT_USER, so it executes with the privileges of the calling schema and typically runs under the APPS schema, accessing AHL application tables through APPS synonyms.

Key Procedures and Functions

The package exposes twenty documented procedures and functions. The principal entry point is START_WF_PROCESS, which launches a Workflow process for an approval-enabled object by accepting the object name, activity identifier, approval type, version number, originating status, new status, reject status, requester, requester notes, and optional workflow process, item type, and application usage code parameters. A record type, ObjRecTyp, models the approval object with attributes such as name, operating unit, object type, priority, start and end dates, description, owner, and application usage code.

A set of function-activity wrapper APIs supports standard Workflow activity nodes, each receiving item type, item key, activity id, function mode, and a result output parameter: SET_ACTIVITY_DETAILS, PREPARE_DOC, SET_APPROVER_DETAILS, and SET_FURTHER_APPROVAL. PREPARE_DOC prepares the document and its approval context before routing; SET_APPROVER_DETAILS populates approver information; SET_FURTHER_APPROVAL determines whether additional approval levels are required; and SET_ACTIVITY_DETAILS writes activity-level attributes for the workflow instance.

Notification handlers include NTF_APPROVAL, NTF_ERROR_ACT, NTF_APPROVAL_REMINDER, NTF_FORWARD_FYI, NTF_APPROVED_FYI, NTF_REJECTED_FYI, and NTF_FINAL_APPROVAL_FYI, covering approval requests, error actions, reminders, forwarding notifications, and informational notifications for approved, rejected, and final outcomes. Status management procedures include UPDATE_STATUS, REVERT_STATUS, REJECTED_UPDATE_STATUS, and APPROVED_UPDATE_STATUS. Query helpers include GET_APPROVAL_DETAILS, GET_APPROVER_INFO, and GET_API_NAME. HANDLE_ERROR centralizes exception processing for the workflow.

Tables Accessed

The package reads and writes through APPS synonyms. AHL_APPROVAL_API stores approval transaction state and is central to status updates. AHL_APPROVAL_RULES_B provides configured approval routing rules that determine approver selection and sequence. AHL_APPROVERS holds approver assignments for objects. Resource and role resolution relies on JTF_RS_ROLES_B and JTF_RS_ROLE_RELATIONS, which define role hierarchies used to expand approver groups and relationships.

Usage Notes

APPS.AHL_GENERIC_APRV_PVT is invoked indirectly rather than called directly by end users. Oracle Forms that submit AHL objects for approval route through START_WF_PROCESS, which then triggers Workflow item type activities mapped to the wrapper APIs. The notification procedures execute as Workflow notification activities, and the status procedures are called as function activities at approval or rejection outcomes. Custom code should not call PVT APIs directly; the supported approach is to invoke the public approval APIs and workflow processes that this package underpins. Because 22 other packages reference it, changes to this package carry broad impact across the AHL approval framework, and it should be treated as internal infrastructure in both 12.1.1 and 12.2.2.