Search Results sub_for_approval

Overview

AMW_PROC_APPROVAL_PKG is the approval engine for Oracle E-Business Suite's Enterprise Risk Management (ERM) module, known in the applications as Oracle Application Management Suite / Governance, Risk, and Compliance (GRC). The package orchestrates the full lifecycle of approval processing for ERM "processes" — the hierarchical representations of business processes, sub-processes, risks, controls, objectives, and significant elements that organizations model and assess. Its central responsibility is to move a process definition through submission, hierarchical validation, approval or rejection, and the persistence of the resulting approved structure.

The package is declared with AUTHID CURRENT_USER and, as the header comment (version 120.0, dated May 2005) indicates, has been maintained to support both the forms-based ERM interface and the WebADI (Web Applications Desktop Integrator) spreadsheet integration. The addition of the p_webadi_call parameter on SUB_FOR_APPROVAL reflects a deliberate design decision: when a process is submitted from WebADI, the hierarchical approval check is bypassed, because that validation is not applicable to the spreadsheet-driven workflow.

Key Procedures and Functions

• SUB_FOR_APPROVAL — Initiates the approval workflow for a given process. It accepts a process identifier and an optional WebADI-call indicator; when invoked from WebADI, the internal call to CHECK_HIER_APPROVED is suppressed.
• APPROVE / REJECT — Terminal actions that mark a submitted process as approved or rejected respectively, taking the process identifier as input.
• CHECK_HIER_APPROVED — Validates whether the process hierarchy has satisfied approval requirements. It exists in two overloads: a simple form taking only the process identifier, and a form that additionally returns a result flag and an output message.
• APPROVE_ASSOCIATIONS — Approves the association records (risks, controls, objectives, and similar linkages) attached to a process as part of the approval action.
• WRITE_APPROVED_HIERARCHY — Persists the approved hierarchy, with optional process identifier and a required step number, recording the denormalized approved structure.
• AUTOAPPROVE — Programmatic approval that follows the standard EBS API convention, exposing commit, validation-level, and message-list parameters along with return status, message count, and message data outputs.
• CHECK_APPROVAL_SUBM_ELIGIB — Determines whether a process is eligible for approval submission, returning a result indicator and message and following the same API-standard parameter pattern as AUTOAPPROVE.
• PROD_ERR_UNAPR_OBJ_ASS_EX — Produces error diagnostics for unapproved objective associations, accepting a process identifier, an approval option, a raise-exception flag, and returning a result and message.
• PROD_ERR_MODIFIED_NSCHILDLIST and PROD_ERR_UNAPPR_NSVAR — Companion error-reporting routines that surface problems with modified nonstandard child lists and unapproved nonstandard variations, each returning a result and message.
• WEBADI_APPROVE — The entry point used by the WebADI integration to drive approval from the desktop spreadsheet interface.

Tables Accessed

The package reads and writes the core ERM data model through APPS synonyms. It consults and updates AMW_PROCESS for process definitions, AMW_PROC_HIERARCHY_DENORM for the denormalized hierarchy, AMW_APPROVED_HIERARCHIES for the stored approved structure, and AMW_PROCESS_LOCKS for concurrency control. Association and linkage data is drawn from AMW_ACCT_ASSOCIATIONS, AMW_CONTROL_ASSOCIATIONS, AMW_OBJECTIVE_ASSOCIATIONS, and AMW_RISK_ASSOCIATIONS. Supporting master data includes AMW_CONTROLS_B, AMW_RISKS_B, AMW_SIGNIFICANT_ELEMENTS, and AMW_NONSTANDARD_VARIATIONS_B. DUAL is used for single-row evaluations.

Usage Notes

AMW_PROC_APPROVAL_PKG is invoked primarily from the ERM forms interface when users submit, approve, or reject processes, and from the WebADI integration for spreadsheet-based approval. It is also referenced by two other packages in the schema, indicating reuse by higher-level ERM workflow or validation logic. Because the procedures follow FND_API conventions (commit flags, validation levels, message lists, and return status), it is well suited to custom extensions that need to trigger approval programmatically. The diagnostic routines (PROD_ERR_*) are typically called by validation paths to generate user-facing error messages. Administrators should ensure all APPS synonyms are valid and that concurrent approval operations are serialized via AMW_PROCESS_LOCKS.