Search Results cst_attribute15

Overview

AMW.AMW_CST_WAIVER_INTERFACE is a transactional interface table in the Oracle E-Business Suite AMW (Constraint Management / Advanced Planning) schema. Its purpose is to stage the information required to create a Constraint waiver. Records are loaded into this table and then validated and processed by the constraint waiver import program, which converts valid rows into permanent records in AMW_CONSTRAINT_WAIVERS and AMW_CONSTRAINTS_B. The table resides in the APPS_TS_TX_DATA tablespace with a PCT Free of 10, and it is surfaced through the AMW FND design data definition.

The metadata's heuristic Data Vault classification for this object is standalone, reflecting its position as a staging entity with no upward dependents. This is best read as a modeling suggestion: AMW_CST_WAIVER_INTERFACE behaves as a satellite-like staging buffer around the constraint waiver hub (AMW_CONSTRAINT_WAIVERS) and the constraint revision table (AMW_CONSTRAINTS_B), rather than as a hub or link in its own right. In ETRM 12.1.1 the documented physical schema contains 42 columns; the column set is consistent across 12.1.1 and 12.2.2 because the object is delivered as part of the AMW product family and is not materially restructured between those releases.

Key Information Stored

The table's most consequential columns fall into four groups: identifiers, constraint definition, waiver subject, and processing control.

• BATCH_ID — groups rows submitted in the same interface run; the leading column of the nonunique index AMW_CST_WAIVER_INTERFACE_N1.
• INTERFACE_ID — surrogate identifier for each interface row, distinct from the business keys below.
• CONSTRAINT_WAIVER_ID and CONSTRAINT_REV_ID — foreign keys to AMW_CONSTRAINT_WAIVERS and AMW_CONSTRAINTS_B respectively; these are the true business-key candidates and are what the importing program resolves against.
• CONSTRAINT_NAME and TYPE_CODE — the human-readable constraint name and the constraint type code used during validation.
• OBJECT_TYPE — indicates whether the waiver applies to a responsibility (RESP) or a user (USER).
• USER_NAME, RESPONSIBILITY_NAME, APPLICATION_SHORT_NAME — the subject of the waiver depending on OBJECT_TYPE, together with the responsibility's owning application.
• START_DATE and END_DATE — the effective window during which the waiver is active.
• JUSTIFICATION — free-text rationale, up to 4000 characters; this is typically the audit-critical payload.
• PROCESS_FLAG, ERROR_FLAG, INTERFACE_STATUS — the processing state machine; PROCESS_FLAG drives selection by the concurrent program and INTERFACE_STATUS carries returned error messages.
• CST_ATTRIBUTE_CATEGORY and CST_ATTRIBUTE1 through CST_ATTRIBUTE15 — a descriptive flexfield. The user's search term, cst_attribute1, refers to this DFF segment: it is a VARCHAR2(150) column available for customer-defined context data attached to the waiver interface record.
• The standard Who columns (LAST_UPDATE_DATE, LAST_UPDATED_BY, CREATION_DATE, CREATED_BY, LAST_UPDATE_LOGIN) — audit columns populated automatically.

The table has no documented primary key constraint; uniqueness is not enforced at the interface layer, and the single index, AMW_CST_WAIVER_INTERFACE_N1 (NONUNIQUE, APPS_TS_TX_IDX, on BATCH_ID, TYPE_CODE, OBJECT_TYPE, PROCESS_FLAG), exists to accelerate the batch retrieval performed by the import process.

Common Use Cases and Queries

The dominant use case is staged bulk creation of constraint waivers from an external source such as a spreadsheet or custom form. A typical pattern loads rows with PROCESS_FLAG left null or set to a pending value, then runs the constraint waiver import concurrent program, which selects by batch.

• Monitoring a batch: SELECT interface_id, constraint_name, error_flag, interface_status FROM amw.amw_cst_waiver_interface WHERE batch_id = :batch_id ORDER BY interface_id;
• Isolating failures: SELECT * FROM amw.amw_cst_waiver_interface WHERE process_flag = 'E' AND error_flag = 'Y';
• Enquiring on the descriptive flexfield: SELECT interface_id, cst_attribute_category, cst_attribute1 FROM amw.amw_cst_waiver_interface WHERE cst_attribute1 = :value;
• Audit reporting on critical waivers: joining JUSTIFICATION, START_DATE, and END_DATE to produce an approval-evidence extract.

Reporting queries should always filter on PROCESS_FLAG and BATCH_ID to exploit AMW_CST_WAIVER_INTERFACE_N1, since the table accumulates rows across many runs and is purged manually by the implementer.

Related Objects

• AMW.AMW_CONSTRAINT_WAIVERS — target of the post-processing insert; joined on AMW_CST_WAIVER_INTERFACE.CONSTRAINT_WAIVER_ID.
• AMW.AMW_CONSTRAINTS_B — base constraints table; joined on AMW_CST_WAIVER_INTERFACE.CONSTRAINT_REV_ID.

Because the object is standalone in the documented relationship graph, no downstream tables carry a foreign key into it. Practical dependencies are therefore procedural: the constraint waiver import concurrent program, the FND descriptive flexfield definition registered against CST_ATTRIBUTE_CATEGORY, and the FND user and responsibility tables that supply the values stored in USER_NAME, RESPONSIBILITY_NAME, and APPLICATION_SHORT_NAME. Change impact analysis should be limited to those consumers rather than to any declarative FK chain.