Search Results raise_wf_bus_event
Overview
APPS.FUN_WF_COMMON is the shared Workflow utility package for the Oracle E-Business Suite Financials (FUN) products, most notably Payables and Receivables. Its role is to centralize the recurring logic required to integrate FUN transactions with the Oracle Workflow engine and the Approvals Management Engine (AME). Rather than duplicating approval and notification code across individual transaction packages, the FUN product family funnels those operations through FUN_WF_COMMON.
The metadata confirms the package is VALID in the APPS schema and classified as OTHER in the ETRM API registry. It depends only on SYS and STANDARD, meaning it is a low-level building block rather than a consumer of other APPS packages, which reinforces its position as a foundational utility layer. In contrast, it is referenced by eight higher-level packages, including FUN_GLINT_WF, FUN_INITIATOR_WF_PKG, FUN_MULTI_SYSTEM_WF_PKG, FUN_RECIPIENT_WF, FUN_TRX_PUB, and FUN_TRX_PVT, confirming that the transaction and workflow sub-components of Financials depend on it to raise events, manage approval statuses, and resolve approvers.
Key Procedures and Functions
The ETRM register documents eighteen procedures and functions. They fall into three functional clusters:
- Approval and AME resolution: GET_AME_CONTACTS, GET_AME_ADMIN, GET_AME_APPROVERS, and GET_AME_ROLE_LIST retrieve approver and administrator identities from AME for a given transaction context. IS_USER_VALID_APPROVER and VALIDATE_APPROVER perform the corresponding validation checks. GET_CONTACT_ROLE resolves a role for a contact, supporting the Payables/Receivables approval chain.
- Workflow event and status management: RAISE_WF_BUS_EVENT, GENERATE_EVENT_KEY, and CONCAT_MSG_STACK raise Business Events and assemble event payloads/messages. RAISE_COMPLETE signals completion, while UPDATE_STATUS_ERROR, UPDATE_STATUS_RECEIVED, and UPDATE_STATUS_COMPLETE maintain the transactional status fields used to track workflow progress. WF_ABORT terminates a workflow process and SET_INVOICE_REQD_FLAG marks invoice-required processing. IS_ARAP_BATCH_MODE distinguishes AP from AR batch-mode processing.
No parameter signatures are published in the ETRM excerpt; the names above are the authoritative interface as documented.
Tables Accessed
FUN_WF_COMMON reaches these objects through APPS synonyms:
- FND_USER, WF_LOCAL_ROLES, WF_USER_ROLE_ASSIGNMENTS: resolve users, roles, and role assignments for approval and notification processing.
- HZ_PARTIES, HZ_ORG_CONTACTS, HZ_ORG_CONTACT_ROLES, HZ_RELATIONSHIPS: the Trading Community Architecture tables used to obtain contact and contact-role information for approver lookups via AME.
- WF_ITEM_ACTIVITY_STATUSES, WF_PARAMETER_LIST_T: workflow runtime state and parameter tables used to query or update item/activity status and pass parameters into workflow calls.
- FUN_TRX_BATCHES and FUN_TRX_HEADERS: the FUN transaction batch and header tables whose status and invoice-required flags are updated by the UPDATE_STATUS_* and SET_INVOICE_REQD_FLAG routines.
- DUAL and PLITBLM: utility references for single-row evaluation and PL/SQL index-by table typing.
Usage Notes
Because FUN_WF_COMMON is referenced by FUN_TRX_PUB, FUN_TRX_PVT, and the FUN_*_WF packages, it is normally invoked indirectly. A user or concurrent program initiates an AP/AR transaction or batch, the transaction layer calls the relevant FUN_*_WF package, and that package delegates to FUN_WF_COMMON to resolve AME approvers, raise workflow events, and refresh transaction status. END users therefore encounter it through approval routing and notification screens and through the Workflow status monitor rather than through a dedicated form or concurrent program.
Custom development should call the public procedures above rather than manipulating WF_ITEM_ACTIVITY_STATUSES or FUN_TRX_HEADERS directly, since the package encapsulates the correct event-key generation, message assembly, and status transitions. Because the package is validated against 12.1.1 and 12.2.2, custom code that invokes it should be re-tested after any Financials patch, as the procedure inventory has evolved across releases.