Search Results amw_process_code_s

Overview

AMW_RL_HIERARCHY_PKG is a PL/SQL package body owned by the APPS schema within Oracle E-Business Suite. It forms part of the Oracle Enterprise Taxation and Risk Management (ETRM) / Audit Management application, supporting the creation, revision, and maintenance of the process hierarchy used to organize risks, controls, and related audit objects. Unlike a public API package, this body is classified as OTHER and functions primarily as an internal engine behind the ETRM hierarchy and approval screens. Its central responsibility is to keep the hierarchical structure of processes consistent, propagate child additions and deletions through denormalized tables, and maintain the count aggregates (risk and control counts) exposed on hierarchy views.

The package is invoked internally by other ETRM components; ETRM documentation records that it is referenced by six other packages and depends on security utilities (AMW_SECURITY_PUB, AMW_SECURITY_UTILS_PVT), utility helpers (AMW_UTILITY_PVT), and Oracle foundation APIs (FND_API, FND_MSG_PUB, FND_MESSAGE, FND_CONCURRENT, FND_GLOBAL, FND_ATTACHED_DOCUMENTS2_PKG), along with workflow views such as WF_ACTIVITIES_VL and AMW_WF_PROCESS_HIERARCHY_VL.

The presence of the AMW_PROCESS_CODE_S sequence in the dependency list, which underlies the user search term "amw_process_code_s", reflects the package's role in inserting and revising process records as hierarchy nodes are added or copied.

Key Procedures and Functions

The package exposes 41 documented procedures and functions. Core structural operations include ADD_EXISTING_PROCESS_AS_CHILD, which attaches an existing process as a child node, and DELETE_CHILD, which removes a child and triggers cleanup of dependent denormalized data. IMPORT_WF_PROCESS imports an activity or process originating in Oracle Workflow into the ETRM hierarchy. IS_ANCESTOR_IN_HIERARCHY and IS_DELETED_PROCESS are validation routines used to prevent invalid or recursive relationships; IS_LOCKED_PROCESS checks process locks prior to modification.

A family of procedures maintains denormalized data and counts:

• UPDATE_DENORM, UPDATE_APPROVED_DENORM, and UPDATE_DENORM_ADD_CHILD refresh the denormalized hierarchy tables after structural changes.
• UPDATE_ORG_COUNT and UPDATE_ALL_ORG_COUNTS recompute organization-level counts.
• UPDATE_LATEST_RISK_COUNTS, UPDATE_LATEST_CONTROL_COUNTS, UPDATE_RC_LATEST_COUNTS, and UPDATE_ALL_LATEST_RC_COUNTS update latest-revision risk and control counts.
• UPDATE_APPROVED_RISK_COUNTS, UPDATE_APPROVED_CONTROL_COUNTS, UPDATE_APPR_RISK_COUNTS, and UPDATE_APPR_CONTROL_COUNTS update approved-hierarchy counts.
• REVISE_PROCESS_IF_NECESSARY governs creation of process revisions when an approved or locked hierarchy must be amended.

Tables Accessed

The package reads and writes the principal ETRM hierarchy tables: AMW_PROCESS, AMW_LATEST_HIERARCHIES, AMW_APPROVED_HIERARCHIES, AMW_PROC_HIERARCHY_DENORM, AMW_ORG_HIERARCHY_DENORM, and AMW_CHILD_ORDER_S. Association tables — AMW_ACCT_ASSOCIATIONS, AMW_CONTROL_ASSOCIATIONS, AMW_OBJECTIVE_ASSOCIATIONS, and AMW_RISK_ASSOCIATIONS — are queried to reconcile counts when nodes move.

Process metadata, naming, and sequencing are handled through AMW_PROCESS_CODE_S (sequence), AMW_PROCESS_S, AMW_PROCESS_NAME_S, AMW_PROCESS_NAMES_TL, AMW_PROCESS_ORGANIZATION, and AMW_PARAMETERS. Concurrency is managed through AMW_PROCESS_LOCKS. Views AMW_CURR_APP_HIERARCHY_RL_V, AMW_LATEST_HIERARCHY_RL_V, AMW_LATEST_REVISIONS_V, AMW_SIGNIFICANT_ELEMENTS, and AMW_WF_PROCESS_HIERARCHY_VL supply current-state data to the update logic.

Usage Notes

AMW_RL_HIERARCHY_PKG is not an end-user-facing API; it is invoked by ETRM forms (process hierarchy and approval screens), concurrent programs that recompute counts or import workflow processes, and dependent ETRM packages. It relies on FND_GLOBAL for session context and FND_MSG_PUB for error propagation, so callers should expect standard EBS API error handling behavior. Because it manipulates AMW_PROCESS_LOCKS and denormalized tables directly, it should be called within the ETRM application flow rather than directly from custom code; direct invocation risks stale denormalized counts or orphaned child-order rows.