Search Results amw_groups_v

Overview

AMW_GROUPS_V is a reporting and integration view owned by the APPS schema within the AMW – Internal Controls Manager product of Oracle E-Business Suite. Its status is documented as VALID in both the 12.1.1 and 12.2.2 releases. The view presents a flattened, business-friendly representation of group records that are physically stored in the Oracle Trading Community Architecture (TCA) party model. Rather than exposing the raw TCA structure with its numeric identifiers and internal flags, AMW_GROUPS_V renames and reshapes key attributes so that consumers — particularly Internal Controls Manager forms, concurrent programs, and downstream reports — can retrieve group identity, name, mission text, and contact email in a single query.

The view is a thin projection layer. It does not aggregate, join multiple tables, or apply complex transformation logic; its value lies in column aliasing and in the WHERE clause filter that restricts results to the group partition of the party model. This makes it the canonical reference point whenever an ETRM or AMW component needs a list of organizational groups rather than individual parties or party sites.

Underlying Base Objects

The view text is defined over a single base object: HZ_PARTIES, aliased as GRP. No other base tables are documented as referenced. The filter clause is:

• GRP.PARTY_TYPE = 'GROUP' — restricts rows to records representing groups rather than persons, organizations, or relationships.
• GRP.STATUS = 'A' — retains only active party records.
• GRP.PARTY_ID = -1000 — a special-seed condition that is ORed with the preceding predicates, ensuring a designated system group (party ID -1000) is always returned even when it would otherwise fail the type or status test.

Because there is no join, the view is effectively a filtered and renamed SELECT against HZ_PARTIES. Any concurrent program or report that queries AMW_GROUPS_V inherits the indexing and security characteristics of HZ_PARTIES. Partitioning, TCA party maintenance, and the DQM (Data Quality Management) processes that update party records all affect the rows returned by this view.

Key Columns

The view exposes five columns, each an alias of a source column in HZ_PARTIES:

• GROUP_ID — aliases GRP.PARTY_ID. The unique identifier of the group within the TCA party model; used as the foreign key in AMW group membership and role assignments.
• GROUP_NAME — aliases GRP.PARTY_NAME. The display name of the group, used in list-of-values, reports, and approval hierarchies.
• GROUP_DESCRIPTION — aliases GRP.MISSION_STATEMENT. This is the column most commonly sought when users search for the term "group_description." It holds the free-text mission or purpose narrative associated with the group.
• GROUP_EMAIL_ADDRESS — aliases GRP.EMAIL_ADDRESS. The primary email contact for the group, useful in notification and workflow routing.
• GROUP_OBJECT_VERSION_NUMBER — aliases GRP.OBJECT_VERSION_NUMBER. The TCA optimistic locking token, required when the owning application must update the underlying HZ_PARTIES row.

Common Use Cases and Queries

Typical usages include populating group list-of-values in Internal Controls Manager, driving workflow notifications to group email addresses, and producing group inventory reports. A basic lookup by description keyword is shown below.

• Retrieve all groups whose description mentions a keyword: SELECT group_id, group_name, group_description FROM apps.amw_groups_v WHERE UPPER(group_description) LIKE '%AUDIT%';
• Fetch identity and email for a single group: SELECT group_name, group_email_address FROM apps.amw_groups_v WHERE group_id = :p_group_id;
• List active groups alphabetically for a report: SELECT group_name, group_description FROM apps.amw_groups_v ORDER BY group_name;
• Obtain the version token prior to an update: SELECT group_object_version_number FROM apps.amw_groups_v WHERE group_id = :p_group_id;

Because the view is a simple projection, these queries perform efficiently provided HZ_PARTIES is properly indexed on PARTY_TYPE, STATUS, and PARTY_ID. Note that any update to group attributes must be routed through the TCA party APIs rather than against this view, since it is not inherently updatable.