Search Results approvers_tbl_type

Overview

DPP_APPROVAL_PVT is a private (PVT) PL/SQL package in the APPS schema that provides the underlying approval-processing engine for Oracle EBS procurement document flows, most notably procurement contracts, sourcing, and related approval-routed transactions. It abstracts the interaction between EBS transaction objects and the Oracle Approval Management Engine (AME), allowing a calling application to resolve an ordered list of approvers, record approval or rejection actions against a transaction, maintain an adjacency-style access table, and dispatch workflow events and notifications when approval status changes. The package implements the standard EBS API contract — an API version parameter, initialization of the message list, a validation level, and the three standard x_return_status, x_msg_data, and x_msg_count OUT parameters — so it can be consumed consistently by concurrent programs, form-based logic, and OAF or custom components. The header comment carries an RCS identifier dated 2008, indicating the core logic long predates the 12.1.1 and 12.2.2 releases in which the object is still shipped.

Key Procedures and Functions

The package exposes nine documented procedures. Because the published signature metadata is partial, only names and purposes are described here.

• GET_APPROVERS — Resolves the approvers applicable to a transaction, returning them through the package's approvers table type (APPROVERS_TBL_TYPE, based on APPROVERS_REC_TYPE with approver type, approver ID, and approver level).
• GET_ALLAPPROVERS — The broader variant of the above and the object most commonly targeted by customizations. It populates the richer APPROVERSTABLE (a PL/SQL associative array of APPROVERRECORD, indexed by BINARY_INTEGER), whose fields include user and person identifiers, name components, API insertion flag, authority flag, approval status, approval type, group-or-chain identifier, occurrence, source, approver sequence, approver e-mail, and approver group name. This structure is what developers typically reference when searching for "get_allapprovers."
• UPDATE_USER_ACTION — Applies a single approval or rejection to a transaction, driven by APPROVAL_REC_TYPE (object type, object ID, status code, action code, and the FND user ID performing the action).
• PROCESS_USER_ACTION — The orchestration wrapper that processes a submitted user action through validation, persistence, event raising, and notification.
• RAISE_EVENT — Publishes a business event through the Workflow event system.
• SEND_NOTIFICATION — Issues the notification associated with an approval or rejection.
• ADD_ACCESS and REVOKE_ACCESS — Grant and remove approver access records, maintaining the package's access table and its sequence.
• CLEAR_ALL_APPROVALS — Resets approval state for a transaction.

Tables Accessed

Access to base objects is through APPS synonyms. AME_APPROVAL_GROUPS and AME_APPROVAL_GROUP_MEMBERS supply the AME approval-group definitions and their members used when resolving approvers and evaluating group-or-chain membership. DPP_APPROVAL_ACCESS and its sequence DPP_APPROVAL_ACCESS_SEQ hold the package's own approver-access rows and the surrogate keys used when adding or revoking access. DPP_TRANSACTION_HEADERS_ALL identifies the transactional document under approval. FND_USER resolves user IDs to application users, while JTF_RS_RESOURCE_EXTNS and its resource joins support sales-resource-based approver resolution. WF_EVENTS, WF_PARAMETER_LIST_T, and WF_PARAMETER_T are the Workflow Business Event System tables used by RAISE_EVENT. PLITBLM is the standard PL/SQL indexed-table utility used to marshal array data.

Usage Notes

Because it is a PVT package, DPP_APPROVAL_PVT is not a supported public integration point; Oracle does not guarantee signature stability across patches. It is invoked internally by the procurement approval flows, and is referenced by three other packages, which constitute the supported call path. Custom code should avoid direct calls and instead use the supported public APIs of the calling modules. Where unavoidable — for example, diagnostic scripts or reporting extracts that read approver lists — GET_ALLAPPROVERS is the entry point of choice, and callers must declare variables of type DPP_APPROVAL_PVT.APPROVERSTABLE, respect the p_api_version, p_init_msg_list, and p_validation_level conventions, and check x_return_status and the message stack before consuming results. On 12.1.1 and 12.2.2 the object behaves identically from a caller's perspective; the 12.2 online-patching model does not alter its interface, though any change to the EBS code level may re-ship the package body and invalidate dependent custom objects, so recompilation and revalidation of custom callers after patching is recommended.