Search Results amw_acct_associations




Overview
Explore in AI Chat

Overview

AMW_ACCT_ASSOCIATIONS is a table in the Oracle E-Business Suite Internal Controls Manager (ICM) module, delivered under the AMW product schema. Within the EBS 12.1.1 and 12.2.2 release families, this object is documented as part of the obsolete Internal Controls Manager footprint. Its stated purpose is to record an association between a general ledger account and a process managed within the ICM framework: a row is written once an account is associated with a process. In practical terms, the table functions as a registry of account-to-process linkages used by ICM's control and audit workflow, supporting the assessment of account-level risk, the derivation of process scope, and the audit of which accounts fall under a given control process.

From a data modeling perspective, the ETRM metadata provides a heuristic Data Vault classification of standalone. This classification is a mined suggestion rather than an authoritative declaration; it reflects the fact that the table's primary key is a single surrogate identifier and that its foreign key relationships point outward to reference objects rather than establishing the table itself as a dependent satellite or a composite-key link. The classification is useful for warehouse design exercises, but implementers should validate it against their own modeling conventions.

Key Information Stored

The table is owned by the AMW schema and documents 37 columns in the 12.1.1 physical schema. The most significant columns are summarized below.

Common Use Cases and Queries

The primary use case is identifying which accounts are in scope for a given ICM process, and conversely which processes touch a given account. A typical reporting query joins the association to accounts and processes:

  • Process scope report: SELECT acct_assoc_id, natural_account_id, object_type, pk1, pk2 FROM amw_acct_associations WHERE statement_id = :statement_id
  • Account coverage lookup: SELECT * FROM amw_acct_associations WHERE natural_account_id = :natural_account_id
  • Active versus deleted associations: filter on deletion_date IS NULL AND deletion_approval_date IS NULL to exclude retired linkages.
  • Security-scoped extraction: constrain by security_group_id to respect the operating unit or organization partition.
  • Audit trail analysis: compare association_creation_date and approval_date to measure approval latency, and deletion_date against deletion_approval_date for removal governance.

Because the table is part of the obsolete ICM module, most 12.1.1 and 12.2.2 environments will find it empty or unused. Queries should therefore be preceded by a row-count check, and reports should degrade gracefully when no associations exist.

Related Objects

  • MSD_AUDIT_SQL_STATEMENTS — joined via AMW_ACCT_ASSOCIATIONS.STATEMENT_ID = MSD_AUDIT_SQL_STATEMENTS.STATEMENT_ID; supplies the audit statement definition context.
  • FND_SECURITY_GROUPS — joined via AMW_ACCT_ASSOCIATIONS.SECURITY_GROUP_ID = FND_SECURITY_GROUPS.SECURITY_GROUP_ID; drives row-level security partitioning.
  • AMW_ACCT_ASSOCIATIONS_PK / AMW_ACCT_ASSOCIATIONS_U1 — the primary key constraint and unique index on ACCT_ASSOC_ID, which govern uniqueness and drive index-based access paths.
  • GL_CODE_COMBINATIONS — referenced conceptually through NATURAL_ACCOUNT_ID and ORIG_SYSTEM_ACCT_VALUE for account validation and description enrichment, although no direct foreign key is documented.
  • STATEMENT_LINE_ID parent object — the audit statement line entity referenced by STATEMENT_LINE_ID, linking the association to the specific line item assessed.

Implementers should treat the documented foreign keys as the authoritative integration points and verify any additional joins against the target instance's actual constraint definitions, since the obsolete status of the module may result in residual or partially populated metadata.