Search Results amw_control_associations




Overview
Explore in AI Chat

Overview

The AMW_CONTROL_ASSOCIATIONS table is a core transactional object within the Oracle E-Business Suite Internal Controls Manager (AMW) module. Its documented purpose is to store the associations that link controls to risks, forming the connective fabric of an organization's internal control framework. In practical terms, each row represents a discrete relationship — a control that has been tied to a risk, an assessment, or a related control object — along with the lifecycle metadata (creation, approval, effectivity, and deletion dates) that governs how that association is managed over time.

The table is owned by the AMW schema and carries a VALID status in the EBS 12.1.1 and 12.2.2 data dictionary. It is a physical table with 38 documented columns. The metadata's heuristic Data Vault classification describes this object as a link table. This is a modeling suggestion rather than a physical attribute: a link table captures associations between business keys, and AMW_CONTROL_ASSOCIATIONS performs exactly that function by joining controls to risks and other control revisions. The table's structure — with a surrogate key, two-point business references, and an Object Version Number — is consistent with the link-table pattern, though the presence of attribute columns and date-range fields gives it satellite-like characteristics as well.

Key Information Stored

The primary key of the table is AMW_CONTROL_ASSOCIATIONS_PK, defined on the CONTROL_ASSOCIATION_ID column. A second unique index, AMW_CONTROL_ASSOCIATIONS_U1, is also defined on CONTROL_ASSOCIATION_ID, confirming it as the sole unique business-key candidate.

Among the most functionally significant columns:

The distinction between the surrogate key (CONTROL_ASSOCIATION_ID) and the business-key candidate is important: the U1 index nominates CONTROL_ASSOCIATION_ID as the business key, but functionally the association's meaning derives from the CONTROL_ID / CONTROL_REV_ID / PK1–PK5 combination.

Common Use Cases and Queries

Typical reporting and integration scenarios include listing all associations for a given control or control revision, identifying currently effective associations for a date range, and auditing approval or deletion history. A representative pattern:

  • Join AMW_CONTROL_ASSOCIATIONS to AMW_CONTROLS_B on CONTROL_REV_ID = CONTROL_REV_ID to report controls and their associated risks.
  • Filter by EFFECTIVE_DATE_FROM <= SYSDATE AND (EFFECTIVE_DATE_TO IS NULL OR EFFECTIVE_DATE_TO >= SYSDATE) to return only active associations.
  • Use DELETION_DATE IS NULL to exclude soft-deleted links.
  • Incorporate SECURITY_GROUP_ID in the WHERE clause to respect data-access security.

Extract/load processes and Internal Controls Manager dashboards frequently consume this table to visualize control-to-risk coverage and gaps.

Related Objects

The documented foreign-key relationships identify the most significant dependent objects:

  • AMW_CONTROLS_B — referenced via CONTROL_REV_ID; the primary control-revision master.
  • CST_REVENUE_COGS_CONTROL — referenced via CONTROL_ID.
  • FND_SECURITY_GROUPS — referenced via SECURITY_GROUP_ID for security-group isolation.

Additional AMW module tables (risk definitions, assessments, and control-association history tables carrying the standard _B/_TL naming suffixes) are commonly joined through the PK1–PK5 generic key columns. Application programming interfaces and concurrent programs within the AMW module read and write this table when controls are linked to or unlinked from risks.