Search Results amw_constraint_waivers

Overview

AMW_CONSTRAINT_WAIVERS is a transactional base table owned by the AMW schema, which supports the Oracle E-Business Suite Internal Controls Manager (ICM) module. As its name implies, the table stores information about constraint waivers — records that capture approved exceptions granted when a defined control constraint cannot be satisfied in the normal course of business. Constraint waivers are central to the ICM remediation workflow, where exceptions to a control must be formally documented, justified, and tracked through their active period.

The ETRM metadata explicitly notes that this table is not used from AME.E (Approvals Management Engine), underscoring that its role is confined to the ICM subsystem rather than the generic approval routing infrastructure. This distinction is important when tracing data lineage, because AME-based approval records reside in separate AME tables.

From a data modeling perspective, the metadata assigns a heuristic Data Vault classification of standalone. This is a mining-derived suggestion rather than a declared architectural decision; the table references two parent tables (FND_SECURITY_GROUPS and AMW_CONSTRAINTS_B) but is not itself grouped into a hub-link-satellite construct. Analysts should treat the standalone label as a modeling hint rather than a definitive classification.

Key Information Stored

The table contains 17 documented columns in the 12.1.1 release. The surrogate primary key, CONSTRAINT_WAIVER_ID, is enforced by the index AMW_CONSTRAINT_WAIVERS_PK and serves as the unique row identifier referenced by all child tables. Because no separate business-key unique index is documented, the surrogate key is the only documented uniqueness constraint.

• CONSTRAINT_WAIVER_ID — Surrogate primary key; the join anchor for all dependent tables.
• CONSTRAINT_REV_ID — Foreign key to AMW_CONSTRAINTS_B, identifying the constraint revision that the waiver applies to.
• SECURITY_GROUP_ID — Foreign key to FND_SECURITY_GROUPS, controlling multi-tenant visibility of the waiver record.
• OBJECT_TYPE — Classifies the object context to which the waiver relates.
• PK1 through PK5 — Generic foreign-key columns that flexibly identify the specific business object (control, process, or entity) covered by the waiver.
• START_DATE and END_DATE — Define the effective window during which the waiver is valid.
• OBJECT_VERSION_NUMBER — Supports optimistic locking for concurrent updates.
• CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — Standard Oracle who-columns for audit and provenance.

Common Use Cases and Queries

Typical reporting focuses on identifying active waivers and measuring their duration. A common query joins the base table to its translation table to retrieve descriptive text:

• Active waiver listing: SELECT w.constraint_waiver_id, w.start_date, w.end_date FROM amw.amw_constraint_waivers w WHERE SYSDATE BETWEEN w.start_date AND NVL(w.end_date, SYSDATE+1);
• Constraint context: join to AMW_CONSTRAINTS_B on CONSTRAINT_REV_ID to report the waiver against its parent control revision.
• Multilingual extraction: join AMW_CONSTRAINT_WAIVERS_TL on CONSTRAINT_WAIVER_ID for name and description in the session language.
• Interface staging reconciliation: join AMW_CST_WAIVER_INTERFACE on CONSTRAINT_WAIVER_ID to validate loaded waiver records.

Related Objects

• AMW_CONSTRAINTS_B — Referenced via CONSTRAINT_REV_ID; supplies the constraint revision definition.
• FND_SECURITY_GROUPS — Referenced via SECURITY_GROUP_ID; governs record visibility.
• AMW_CONSTRAINT_WAIVERS_B — Child table referencing CONSTRAINT_WAIVER_ID; holds base-language attributes.
• AMW_CONSTRAINT_WAIVERS_TL — Translation table referencing CONSTRAINT_WAIVER_ID; stores language-specific text.
• AMW_CST_WAIVER_INTERFACE — Interface table referencing CONSTRAINT_WAIVER_ID for bulk data loading.