Search Results amw_work_ext_b




Overview
Explore in AI Chat

Overview

AMW_WORK_EXT_B is a table in the AMW schema, owned by the Oracle Internal Controls Manager (ICM) module, which forms part of the Oracle E-Business Suite governance, risk, and compliance (GRC) toolset. The table is documented as an "External FWK table for engagements." In the Oracle Application Framework/extensibility (FWK) model, external attribute tables provide a generic, descriptively sparse container that allows customers and implementers to store additional, site-specific attributes against a core business entity without modifying the delivered schema. In this case the extensible entity is the engagement record used by ICM.

The table is classified heuristically, through its foreign-key structure, as a standalone object under the Data Vault modeling convention. This classification should be treated as a modeling suggestion rather than a delivered design: the table's grain is effectively one row per extension set, keyed by a surrogate identifier, with no independent business history. The presence of audit columns (WHO columns) indicates it is maintained in the standard EBS audit pattern, and the large block of generic typed attribute columns confirms its role as a satellite-style attribute store attached to the parent engagement.

Key Information Stored

AMW_WORK_EXT_B contains 101 documented columns. The most significant of these are summarized below.

The only documented unique or primary key is EXTENSION_ID. Columns such as WORK_ID, ATTR_GROUP_ID, and AUDIT_PROJECT_ID are business-key candidates that typically participate in a composite uniqueness rule in the logical model, although no such unique index is documented in the supplied metadata.

Common Use Cases and Queries

The extension table is primarily queried for reporting and reconciliation of site-defined attributes attached to ICM engagements. A representative join retrieves every extension row with its parent audit project:

  • SELECT e.extension_id, e.audit_project_id, p.project_name, e.c_ext_attr1, e.n_ext_attr1 FROM amw.amw_work_ext_b e JOIN amw.amw_audit_projects p ON p.audit_project_id = e.audit_project_id;
  • SELECT COUNT(*) FROM amw.amw_work_ext_b WHERE attr_group_id = :group_id;
  • SELECT extension_id, last_update_date, last_updated_by FROM amw.amw_work_ext_b WHERE audit_project_id = :project_id ORDER BY last_update_date DESC;

Typical scenarios include extracting engagement-level custom attributes into a data warehouse, auditing which custom attributes have been populated versus left null, and validating that every active audit project has a corresponding extension row. Because the descriptive columns are generically named, the semantic meaning of each C_/N_/D_/UOM_ attribute is defined by implementation configuration rather than by the database, so queries must be interpreted against the customer's attribute-mapping documentation.

Related Objects

  • AMW_AUDIT_PROJECTS — the parent entity; joined on AMW_WORK_EXT_B.AUDIT_PROJECT_ID = AMW_AUDIT_PROJECTS.AUDIT_PROJECT_ID. This is the dominant dependency and the anchor for engagement reporting.
  • AMW_WORK_EXT_B_PK — the primary key constraint on EXTENSION_ID.
  • EBS WHO/audit infrastructure — the standard audit columns rely on FND audit facilities for user and login resolution.
  • Work and work-element tables in AMW — referenced through WORK_ID and WORK_ELEM_ID, linking the extension attributes to the engagement's work breakdown.
  • Attribute group metadata in AMW — referenced through ATTR_GROUP_ID, defining how the generic C_/N_/D_/UOM_ columns are labelled for the implementation.

Because the table is delivered as a standalone extension container with a single documented foreign key, dependencies outside AMW_AUDIT_PROJECTS and the AMW work structures are limited. Consumers of this table should treat it as a supplemental attribute store rather than a transactional driver.