Search Results get_approval_path

Overview

APPS.PO_APPROVE_SV is a server-side PL/SQL package in Oracle E-Business Suite that supports the Purchasing document approval workflow. Its principal business function is to determine and supply the default approval path for a purchasing document (such as a purchase order, release, or quote) as it enters the approval routing cycle. The package encapsulates the decision logic that decides whether an approval path should be defaulted for the user at the time an approval action is initiated, based on the document's prior action history and the forwarding relationship between the current user and the default path.

The package is declared with AUTHID CURRENT_USER, meaning that its unqualified database object references are resolved against the privileges of the invoking user rather than the package owner. This design is consistent with other Oracle Purchasing server-side "SV" packages that expose thin, reusable business logic to the Oracle Forms-based Purchasing application and to workflow components. The $Header comment shows a version lineage dating to 2003, indicating the package has been a stable part of the approval infrastructure across multiple EBS releases, including 12.1.1 and 12.2.2.

Key Procedures and Functions

The documented package exposes six procedures/functions, including internal helpers and the public entry points:

• GET_APPROVAL_PATH — The primary public procedure and the object most frequently sought by developers. It determines the default approval path for a document and returns both the approval path name and the corresponding approval path identifier. Its algorithm, documented in the package source, follows three rules: (1) if the action is not the first action on the document, the same approval path used by the previous action is reused; (2) if it is the first action and the forwarding person belongs to the default approval path, that default path is applied; and (3) if the forwarding person does not belong to the default path, no approval path is defaulted. The procedure also returns the approval path and approval path ID as OUT NOCOPY parameters.
• TEST_GET_APPROVAL_PATH — A diagnostic or test wrapper mirroring the signature of GET_APPROVAL_PATH, used to validate path resolution logic without performing the full approval action.
• GET_DOCUMENT_TYPES — Retrieves required startup values from the PO_DOCUMENT_TYPES table, providing the document type and subtype context used by the path-resolution logic.
• GET_CHANGE_SUMMARY — Returns summary information regarding changes associated with a purchasing document, supporting the change-request and approval display flows.
• NAME — A utility identifier routine within the package.

Tables Accessed

The package reads and writes a focused set of Purchasing and HR tables through APPS synonyms:

• PO_ACTION_HISTORY — The central table for the "first action" determination. GET_APPROVAL_PATH queries this history to identify the previous action's approval path and to establish whether a prior action exists on the document.
• PO_DOCUMENT_TYPES — Supplies document type and subtype validation values used at startup and during path resolution.
• PER_POSITION_STRUCTURES — Used to evaluate the forwarding person's position hierarchy, supporting the rule that the forward-from person must belong to the default approval path.
• PO_CHANGE_REQUESTS — Supports the change-summary functionality associated with approval and change-order processing.
• DBMS_SQL and PLITBLM — Dynamic SQL and index-by-table utilities used internally by the package.

Usage Notes

PO_APPROVE_SV is typically invoked from the Oracle Purchasing approval user interface and from the PO Approval workflow when a user initiates an Approve, Forward, or similar action. It is referenced by two other packages, confirming its role as a shared service rather than a standalone entry point. Customizations and extensions that need to reproduce or extend the default approval path behavior can call GET_APPROVAL_PATH directly, but must respect the AUTHID CURRENT_USER semantics and ensure the calling session has appropriate access to the underlying synonyms. Because the package governs only the defaulting of an approval path — not the approval decision itself — it should be treated as a supportive routing utility within the broader PO approval workflow, and any direct invocation should be regression-tested against both 12.1.1 and 12.2.2 since the package is shipped as a standard, versioned Oracle object.