Search Results amw_audit_scope_processes

Overview

The AMW_AUDIT_SCOPE_PROCESSES table belongs to the Oracle Internal Controls Manager (AMW) product family, a module that is now classified as obsolete in Oracle E-Business Suite release 12.1.1 and 12.2.2. The table stores aggregated counts and metrics for audit processes that fall within the scope of an engagement, segmented by organization. Each row links a business process to a specific audit project (engagement) and captures quantitative rollups such as the number of risks evaluated, controls assessed, and findings raised during the engagement lifecycle.

From a Data Vault modeling perspective, the heuristic classification derived from the foreign key structure identifies this object as standalone. Because the table carries both the engagement context (via AUDIT_PROJECT_ID) and the process/organization context, a standalone classification suggests it functions as a fact- or satellite-style table that records measured outcomes rather than a pure junction between two entities. The table is documented in the ETRM metadata as "not implemented in this database," meaning the physical object may be absent or only present in specific environments where AMW was previously deployed.

Key Information Stored

The table contains 20 documented columns. The most significant columns fall into three groupings.

• Engagement and scope keys: AUDIT_PROJECT_ID identifies the parent engagement and carries a foreign key to AMW_AUDIT_PROJECTS. ORGANIZATION_ID, PROCESS_ID, and PROCESS_ORG_REV_ID together define the specific process within an organizational context that is being audited.
• Risk and control metrics: RISKS_EVALUATED, UNMITIGATED_RISKS, and TOTAL_RISKS capture the risk population and its disposition. CONTROLS_EVALUATED, INEFFECTIVE_CONTROLS, and TOTAL_CONTROLS provide the parallel control assessment counts. EVALUATION_OPINION_ID links to the recorded opinion for the scope entry.
• Issue and finding counts: OPEN_FINDINGS and OPEN_ISSUES record outstanding deficiencies raised against the process during the engagement.
• Standard EBS audit and multi-tenancy columns: CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN, and OBJECT_VERSION_NUMBER support concurrency and change tracking. SECURITY_GROUP_ID references FND_SECURITY_GROUPS to enforce multi-organization data security.

AUDIT_PROJECT_ID, ORGANIZATION_ID, and PROCESS_ID constitute the primary business-key candidate for uniquely identifying a scope record. No single surrogate primary key column is documented separately; the composite of these identifiers functions as the effective key. OBJECT_VERSION_NUMBER implements optimistic locking rather than acting as a business key.

Common Use Cases and Queries

Typical usage centers on audit reporting and engagement dashboards. A common pattern aggregates metric columns by engagement to produce a rollup of scope-wide risk and control coverage:

• Summing TOTAL_RISKS, RISKS_EVALUATED, and UNMITIGATED_RISKS grouped by AUDIT_PROJECT_ID to assess engagement coverage.
• Comparing INEFFECTIVE_CONTROLS against TOTAL_CONTROLS to calculate control effectiveness ratios per process.
• Joining OPEN_FINDINGS and OPEN_ISSUES to identify processes with unresolved deficiencies.

A sample query joining back to the engagement header might read:

SELECT s.AUDIT_PROJECT_ID, s.ORGANIZATION_ID, s.PROCESS_ID, s.TOTAL_RISKS, s.INEFFECTIVE_CONTROLS, s.OPEN_FINDINGS FROM AMW_AUDIT_SCOPE_PROCESSES s WHERE s.AUDIT_PROJECT_ID = :p_project_id;

Because the table is obsoleted, queries typically appear in legacy reporting or migration efforts rather than active application code.

Related Objects

The most significant relationships, grounded in the documented foreign keys, are:

• AMW_AUDIT_PROJECTS — joined on AUDIT_PROJECT_ID; the parent engagement record.
• FND_SECURITY_GROUPS — joined on SECURITY_GROUP_ID; enforces organization-level data access.
• AMW_AUDIT_SCOPE_* family tables — sibling scope tables (for organizations, risks, and controls) that share the AUDIT_PROJECT_ID context.
• AMW_PROCESSES / process definition tables — referenced by PROCESS_ID to resolve process names and hierarchy.
• HR_OPERATING_UNITS or ORG_ORGANIZATION_DEFINITIONS — resolved via ORGANIZATION_ID to label the organization in reports.

These relationships support reconstructing full engagement scope for historical audit reporting and data archival.