Search Results resp_violation_id

Overview

The AMW_VIOLAT_RESP_ENTRIES table is a core data repository within the Oracle E-Business Suite (EBS) 12.1.1 and 12.2.2, specifically for the Application Management (AMW) module. Its primary role is to support the segregation of duties (SoD) and risk management framework by storing granular details of individual incompatible access violations detected for a responsibility. When the system identifies that a responsibility has been granted access to conflicting functions or concurrent programs, a high-level violation record is created. This table provides the detailed line-item entries for that violation, cataloging each specific incompatible menu, function, or program that constitutes the risk. It is essential for audit trails, remediation tracking, and detailed compliance reporting.

Key Information Stored

The table's structure is designed to capture the violation's components and its lifecycle. The primary identifier, VIOLAT_RESP_ENTRY_ID, uniquely distinguishes each entry. The RESP_VIOLATION_ID column is a critical foreign key that links the entry to its parent violation record. The nature of the incompatible object is defined by the MENU_ID, FUNCTION_ID, and OBJECT_TYPE columns, where OBJECT_TYPE indicates whether the entry is a standard function ('FUNC') or a concurrent program ('CP'). The APPLICATION_ID stores the application identifier for concurrent programs. For audit purposes, the table includes standard WHO columns (CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE) and specific columns like ACCESS_GIVEN_DATE and ACCESS_GIVEN_BY_ID, which record when and by whom the incompatible access was originally granted to the responsibility.

Common Use Cases and Queries

A primary use case is generating detailed audit reports that list every specific function or program causing a segregation of duties violation for a given responsibility. This is crucial for security administrators tasked with remediation. Another scenario involves tracking the history of granted access to understand when a violation was introduced. A common query pattern retrieves all violation entries for a specific responsibility violation ID, joining to the parent table for context:

• SELECT vre.* FROM amw.amw_violat_resp_entries vre WHERE vre.resp_violation_id = :p_violation_id ORDER BY vre.object_type, vre.function_id;

To analyze violations by object type, a query might aggregate data: SELECT object_type, COUNT(*) FROM amw.amw_violat_resp_entries GROUP BY object_type;. For integration or data extraction, the standard SELECT statement provided in the ETRM documentation serves as the foundational template.

Related Objects

The AMW_VIOLAT_RESP_ENTRIES table has a defined relationship with a key parent table, as indicated by its foreign key constraint. The RESP_VIOLATION_ID column references the AMW_VIOLATION_RESP table (likely a typographical shortening of AMW_RESP_VIOLATIONS or similar in the provided metadata). This is the primary relationship, where the parent table holds the summary responsibility violation record. The table's primary key, AMW_VIOLAT_RESP_ENTRIES_PK on VIOLAT_RESP_ENTRY_ID, ensures each detail entry is unique. Furthermore, the ETRM notes that the table is referenced by a synonym (APPS.AMW_VIOLAT_RESP_ENTRIES), which is the standard access point for all EBS application code. A non-unique index, AMW_VIOLAT_RESP_ENTRIES_N1 on RESP_VIOLATION_ID, exists to optimize queries joining to or filtering by the parent violation ID.