Results for “amw_violations”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

AMW_VIOLATIONS is a transaction table within the Oracle E-Business Suite Internal Controls Manager module (product code AMW). It stores one row for each constraint violation check request executed against a compliance constraint definition. In Oracle EBS releases 12.1.1 and 12.2.2, the module is classified as obsolete, and the table is documented as not implemented in the reference database. Nonetheless, the object remains important for historical reference, upgrade assessment, and for environments where earlier Internal Controls Manager deployments persist.

Each record captures the lifecycle of a violation check: who requested it, when, against which constraint revision, and the resulting status and violator count. Downstream responsibility and user assignment records are keyed to a single violation through the VIOLATION_ID surrogate key.

From a Data Vault modeling perspective, the mined foreign key structure classifies AMW_VIOLATIONS as hub-leaning. The surrogate VIOLATION_ID plus its business context (CONSTRAINT_REV_ID, REQUEST_ID, STATUS_CODE) suggest it functions as a hub with descriptive satellites, while REQUESTS, RESPONSIBILITIES, and USERS behave as dependent link tables.

Key Information Stored

The primary key is AMW_VIOLATIONS_PK, defined on VIOLATION_ID, a system-generated surrogate identifier. Business identity is derived from CONSTRAINT_REV_ID (the constraint definition revision evaluated) and REQUEST_ID (the originating check request). The 33 documented columns include standard EBS WHO audit columns, 15 descriptive ATTRIBUTE flex columns, and SECURITY_GROUP_ID for multi-tenant data partitioning.

• VIOLATION_ID — surrogate primary key; uniquely identifies each check result.
• CONSTRAINT_REV_ID — foreign key to AMW_CONSTRAINTS_B; the constraint revision checked.
• REQUEST_ID — the concurrent or programmatic request that triggered the check.
• REQUEST_DATE — timestamp the check was submitted.
• REQUESTED_BY_ID — user who initiated the check.
• STATUS_CODE — outcome state of the violation run (e.g., completed, in progress).
• VIOLATOR_NUM — count of records found in violation.
• REVAL_REQUEST_ID / REVAL_REQUEST_DATE / REVAL_REQUESTED_BY_ID — re-evaluation request metadata for remediation cycles.
• SECURITY_GROUP_ID — FK to FND_SECURITY_GROUPS; controls visibility across operating units.
• OBJECT_VERSION_NUMBER — optimistic locking column.
• LAST_UPDATE_DATE / LAST_UPDATED_BY / CREATION_DATE / CREATED_BY — EBS WHO audit trail.
• ATTRIBUTE1–15 / ATTRIBUTE_CATEGORY — descriptor flexfields for extension data.

Common Use Cases and Queries

Typical usage centers on compliance reporting: listing violations by status, summarizing violator counts per constraint, and tracing remediation efforts. A representative query joining the constraint revision and requesting user follows:

• Active violations by constraint: SELECT v.VIOLATION_ID, c.CONSTRAINT_NAME, v.VIOLATOR_NUM FROM AMW_VIOLATIONS v JOIN AMW_CONSTRAINTS_B c ON v.CONSTRAINT_REV_ID = c.CONSTRAINT_REV_ID WHERE v.STATUS_CODE = 'COMPLETED';
• Violations awaiting re-evaluation: filter on REVAL_REQUEST_ID IS NOT NULL to isolate remediation runs.
• User responsibility assignments: join to AMW_VIOLATION_RESP and AMW_VIOLATION_USERS on VIOLATION_ID to list accountable parties.
• Audit and volume reporting: group by TRUNC(REQUEST_DATE) to trend violation checks over time.

Because the table carries a SECURITY_GROUP_ID, governed queries should enforce security group predicates consistent with the caller's operating unit to comply with EBS multi-org access rules.

Related Objects

Relationships are anchored on the VIOLATION_ID and CONSTRAINT_REV_ID keys:

• AMW_CONSTRAINTS_B — referenced via AMW_VIOLATIONS.CONSTRAINT_REV_ID; the constraint definition being checked.
• FND_SECURITY_GROUPS — referenced via AMW_VIOLATIONS.SECURITY_GROUP_ID; controls data segregation.
• AMW_VIOLATION_RESP — child table; AMW_VIOLATION_RESP.VIOLATION_ID → AMW_VIOLATIONS.VIOLATION_ID; stores responsible-party assignments.
• AMW_VIOLATION_USERS — child table; AMW_VIOLATION_USERS.VIOLATION_ID → AMW_VIOLATIONS.VIOLATION_ID; stores per-user assignments for a violation.
• FND_USER — conventional join target for REQUESTED_BY_ID and REVAL_REQUESTED_BY_ID to resolve user names.
• FND_CONCURRENT_REQUESTS — standard join on REQUEST_ID to retrieve concurrent program execution detail.

Given the module's obsolete status, these relationships should be validated against any surviving customizations before use in 12.1.1 or 12.2.2 environments.