Search Results amw_constraint_waivers_b




Overview
Explore in AI Chat

Overview

AMW_CONSTRAINT_WAIVERS_B is a core table within the Oracle E-Business Suite Internal Controls Manager (AMW) product, a module associated with Oracle Application Access Controls Governor and the broader governance, risk, and compliance feature set. The table stores the definition records of constraint waivers — explicit exceptions granted when a user or a responsibility is permitted to bypass a constraint that would otherwise restrict access, transaction, or segregation-of-duties enforcement. In ETRM releases 12.1.1 and 12.2.2, the object resides in the AMW schema and is reported as VALID, with a documented physical schema of 17 columns in 12.1.1.

Each record is polymorphic. The OBJECT_TYPE discriminator determines how the generic key columns PK1 through PK5 are interpreted. When OBJECT_TYPE equals USER, PK1 carries the User Id. When OBJECT_TYPE equals RESP, PK1 carries the Responsibility Id and PK2 carries the Responsibility Application Id. This design allows the same table to hold waivers for fundamentally different security principals without separate structures. The _B suffix indicates this is a base (definition) table that is typically paired with a _TL translation table for descriptive, language-dependent attributes, which is the conventional Oracle EBS pattern for seeded and user-defined setups.

From a heuristic Data Vault modeling perspective, the metadata classifies this object as standalone and its mined FK structure shows no downstream dependents. On that basis, the object is best modeled as a satellite attached to a constraint hub, with CONSTRAINT_REV_ID acting as the link to the constraint revision it qualifies.

Key Information Stored

The table's most significant columns fall into four groups.

The same CONSTRAINT_WAIVER_ID also appears as a foreign key in AMW_CONSTRAINT_WAIVERS, indicating the _B table holds the header definition while the companion table holds the detail or translated rows.

Common Use Cases and Queries

Typical use cases include identifying every user or responsibility currently exempt from a given constraint, auditing overdue or expiring waivers, and reconciling waiver grants against access provisioning during a controls review.

A representative query listing active user waivers:

SELECT w.CONSTRAINT_WAIVER_ID, w.PK1 USER_ID, w.START_DATE, w.END_DATE
FROM   AMW.AMW_CONSTRAINT_WAIVERS_B w
WHERE  w.OBJECT_TYPE = 'USER'
AND    w.START_DATE <= SYSDATE
AND    (w.END_DATE IS NULL OR w.END_DATE >= SYSDATE);

To resolve responsibility waivers, join on FND_RESPONSIBILITY using PK1 and PK2, and to recover the governing constraint, join AMW_CONSTRAINTS_B on CONSTRAINT_REV_ID. Reporting should always filter by OBJECT_TYPE before interpreting PK column values, since a bare join on PK1 can match the wrong principal type.

Related Objects

  • AMW_CONSTRAINTS_B — referenced via CONSTRAINT_REV_ID; supplies the constraint definition each waiver overrides.
  • AMW_CONSTRAINT_WAIVERS — references CONSTRAINT_WAIVER_ID; the companion detail or translation structure.
  • FND_SECURITY_GROUPS — referenced via SECURITY_GROUP_ID; governs security partitioning.
  • FND_USER — joined through PK1 when OBJECT_TYPE equals USER.
  • FND_RESPONSIBILITY — joined through PK1 and PK2 when OBJECT_TYPE equals RESP.