Search Results oe_ame_parallel_s

Overview

APPS.OE_APPROVALS_WF is the Oracle Order Management workflow approval package responsible for driving sales document approvals — order, blanket, and contract headers — through the Workflow Engine (WF_ENGINE) and, where licensed, the Oracle Approvals Management (AME) engine. In Oracle EBS 12.1.1 and 12.2.2 it acts as the bridge between the Order Management transaction schema and the approval workflow process defined for Order Management, controlling approver determination, notification generation, response processing, and timeout handling. The package is documented as VALID with an API classification of OTHER and is not referenced by any other database object, which indicates it is a top-level API invoked directly by the Order Management workflow activities rather than by peer packages.

Key Procedures and Functions

The 22 documented routines cover the full approval lifecycle:

• INITIATE_APPROVAL — starts the approval cycle for a sales document.
• GET_NEXT_APPROVER / GET_NEXT_APPROVER_INTERNAL — determine the next approver in the sequence; the internal variant performs the core lookup logic.
• GET_CURRENT_APPROVER / GET_CURRENT_APPROVER_INTERNAL — retrieve the approver currently assigned to the document.
• APPROVE_APPROVAL, REJECT_APPROVAL — record the approve or reject decision.
• PROCESS_RESPONSE_APPROVE, PROCESS_RESPONSE_REJECT — interpret notification responses and advance the workflow accordingly.
• APPROVAL_TIMEOUT, APPROVAL_TIMEOUT_AME — handle approval periods that expire, for standard and AME-driven flows respectively.
• GET_AME_APPROVERS_LAUNCH, USE_AME_APPROVAL, IS_AME_EXCEPTION — control whether AME is used and how AME exceptions are detected.
• CHECK_PARALLEL_WF_STATUS — monitor the parallel workflow process, associated with OE_AME_PARALLEL_S.
• TREAT_AME_EXCEPTION_AS — define exception handling behaviour.
• GET_SALES_DOCUMENT_TYPE — classify the document being approved.
• GET_NOTIFICATION_ATTRIBUTES — supply attributes used to build the approval notification.
• PROCESS_BEAT_BY_FIRST — implement the "beat by first" approval ordering semantics.
• PUSH_BLOCK_ACTIVITY — push the workflow into a blocking activity.

Tables Accessed

Documented table references include OE_ORDER_HEADERS_ALL, OE_BLANKET_HEADERS_ALL and OE_BLANKET_HEADERS_EXT for the sales documents under approval; OE_APPROVER_LISTS, OE_APPROVER_LIST_MEMBERS and OE_APPROVER_TRANSACTIONS for the approval hierarchy and history of approver actions; OE_TRANSACTION_TYPES_ALL for document type definitions; OE_AME_PARALLEL_S as the staging table connecting the package to the parallel AME workflow process; PER_ALL_PEOPLE_F, PER_ALL_ASSIGNMENTS_F and FND_USER for approver identity resolution; HZ_PARTIES for party information; FND_LANGUAGES, FND_LOOKUP_VALUES for language and lookup handling; and AP_INV_APRVL_HIST for approval history. Documented package dependencies include AME_API2, AME_UTIL, AME_UTIL2, WF_ENGINE, WF_CORE, FND_API, FND_GLOBAL, OE_ORDER_WF_UTIL, OE_STANDARD_WF, OE_MSG_PUB, OE_GLOBALS and OE_DEBUG_PUB, confirming the package's role as an AME/workflow integration layer.

Usage Notes

OE_APPROVALS_WF is normally invoked indirectly by the Order Management approval workflow rather than called directly by end users. The order entry and blanket/contract forms initiate the workflow, which in turn calls these procedures. AME is invoked when the relevant Order Management profile options enable AME-based approvals, in which case AME_API2 determines the approver list and OE_AME_PARALLEL_S plus CHECK_PARALLEL_WF_STATUS handle the parallel process status. Custom code should avoid direct invocation of the internal routines and instead use the standard workflow APIs; where extension is required, note that the package is not referenced by other database objects, so changes to its behaviour affect only the Order Management approval workflow itself.