Search Results amw_cst_waiver_interface

Overview

The AMW_CST_WAIVER_INTERFACE table is a staging and interface table within the Oracle E-Business Suite Internal Controls Manager (AMW) module. Its documented purpose is to store the information required to create a constraint waiver. In practice, this table acts as an inbound holding area where waiver records are assembled—either through manual data entry, seeded scripts, or external feeds—before a concurrent program or validation routine processes them into the base constraint waiver tables. It is owned by the AMW schema and contains 42 documented columns in the ETRM 12.1.1 schema.

Under the heuristic Data Vault classification supplied in the metadata, this object is identified as standalone, meaning it does not behave cleanly as a hub, link, or satellite because its foreign-key topology is narrow and largely self-referential to the waiver domain. A reasonable modeling suggestion is to treat it as a staging or transient satellite that feeds a genuine hub (the constraint waiver) once validated, rather than as a durable dimension in its own right. Records in this table are typically short-lived: they are created, flagged for processing, and then either transferred to the base waiver tables or rejected.

Key Information Stored

The table carries a surrogate row identifier, INTERFACE_ID, and a batch grouping key, BATCH_ID, which are the primary business-key candidates for tracking an inbound load. Both are documented columns. The remaining significant columns fall into three groups:

• Waiver identity and target references: CONSTRAINT_WAIVER_ID (FK to AMW_CONSTRAINT_WAIVERS), CONSTRAINT_REV_ID (FK to AMW_CONSTRAINTS_B), CONSTRAINT_NAME, and TYPE_CODE, which establish which constraint the waiver applies to and its type.
• Context and ownership metadata: OBJECT_TYPE, USER_NAME, APPLICATION_SHORT_NAME, and RESPONSIBILITY_NAME, capturing who requested or owns the waiver and under which application and responsibility.
• Effective dating and workflow state: START_DATE, END_DATE, JUSTIFICATION, PROCESS_FLAG, ERROR_FLAG, and INTERFACE_STATUS, which drive the validation and transfer logic. Standard audit columns (LAST_UPDATE_DATE, LAST_UPDATED_BY, CREATION_DATE, CREATED_BY, LAST_UPDATE_LOGIN) and the 15 CST_ATTRIBUTE flexfields (CST_ATTRIBUTE_CATEGORY plus CST_ATTRIBUTE1–CST_ATTRIBUTE15) provide extensibility.

Common Use Cases and Queries

Typical scenarios include monitoring pending waiver loads, diagnosing rejected rows, and reconciling interface volume by batch. A common query retrieves unprocessed rows awaiting transfer:

• SELECT BATCH_ID, INTERFACE_ID, CONSTRAINT_NAME, INTERFACE_STATUS, ERROR_FLAG FROM AMW_CST_WAIVER_INTERFACE WHERE PROCESS_FLAG = 'N' OR ERROR_FLAG = 'Y';
• Count errors per batch: SELECT BATCH_ID, COUNT(*) FROM AMW_CST_WAIVER_INTERFACE WHERE ERROR_FLAG = 'Y' GROUP BY BATCH_ID;
• Join to the target waiver table to confirm a successful transfer: SELECT i.INTERFACE_ID, w.CONSTRAINT_WAIVER_ID FROM AMW_CST_WAIVER_INTERFACE i JOIN AMW_CONSTRAINT_WAIVERS w ON i.CONSTRAINT_WAIVER_ID = w.CONSTRAINT_WAIVER_ID;

Related Objects

The documented foreign keys define the two primary relationships, and both target tables are the most significant dependents:

• AMW_CONSTRAINT_WAIVERS — joined via CONSTRAINT_WAIVER_ID; the base table the interface ultimately populates.
• AMW_CONSTRAINTS_B — joined via CONSTRAINT_REV_ID; supplies the constraint definition being waived.

Beyond these, the AMW constraint waiver concurrent program and its validation logic are the principal consumers, reading pending rows and writing back INTERFACE_STATUS and ERROR_FLAG. Related constraint tables such as AMW_CONSTRAINTS_TL provide translated names when reporting on CONSTRAINT_NAME.