Search Results gms_notifications_v




Overview
Explore in AI Chat

Overview

GMS_NOTIFICATIONS_V is a reporting view owned by the APPS schema in Oracle E-Business Suite, validated and shipped with the Grants Accounting (GMS) product family. It presents a denormalized, human-readable projection of award notification records, joining each notification to its parent award and to the recipient's user and person identity. In the EBS architecture, this object is one of the standard seeded views supplied by the GMS module; it is not a base table, and no data is stored in it. All content is resolved at runtime from the underlying notification, award, and identity objects.

The view exists to support operational and analytical visibility into which users are notified about which award events. Rather than requiring report authors and integrators to reconstruct the four-way join between award, notification, FND user, and HR person records, the view exposes a single flat result set keyed on award and recipient. It is most commonly consumed by concurrent programs, custom reports, OAF or Forms extensions, and outbound integration extracts that need to enumerate award notification recipients. Because it resolves identity data through HR person and security packages, query output is subject to the same row-level security and effective-dating semantics that govern the underlying HR objects.

Underlying Base Objects

The documented base objects referenced by the view are GMS_AWARDS_ALL, GMS_NOTIFICATIONS, FND_USER, and PER_PEOPLE_X, each reached through APPS synonyms. GMS_AWARDS_ALL supplies the award header attributes; GMS_NOTIFICATIONS supplies the event and recipient keys; FND_USER supplies the application login name; and PER_PEOPLE_X supplies the formatted person name. The view text performs an inner join on AWARD_ID between GMS_AWARDS_ALL and GMS_NOTIFICATIONS, an inner join on USER_ID between GMS_NOTIFICATIONS and FND_USER, and an inner join on EMPLOYEE_ID to PERSON_ID between FND_USER and PER_PEOPLE_X.

The ETRM metadata additionally lists HR_GENERAL, HR_PERSON_NAME, and HR_SECURITY packages as referenced dependencies. These are invoked transitively through PER_PEOPLE_X, which is itself a view built on the HR person model. HR_SECURITY enforces row-level access to person records, HR_PERSON_NAME formats the display name, and HR_GENERAL provides shared HR utilities. Because the joins are inner joins, notifications whose recipient has no corresponding FND user, or whose user has no linked employee record, will not appear in query results.

Key Columns

  • ROW_ID — the ROWID of the GMS_NOTIFICATIONS row, useful for direct row identification and updates against the base table.
  • AWARD_ID — the unique identifier of the award, joinable to GMS_AWARDS_ALL.AWARD_ID.
  • AWARD_NUMBER — the business-facing award number used in reports and correspondence.
  • AWARD_SHORT_NAME — the abbreviated award name for display in lists and dashboards.
  • EVENT_TYPE — the award event that triggered the notification, indicating the nature of the alert.
  • USER_ID — the FND user identifier of the notification recipient.
  • USER_FULL_NAME — the formatted person name of the recipient, resolved through PER_PEOPLE_X.
  • USER_NAME — the application login name of the recipient from FND_USER.

Common Use Cases and Queries

Typical scenarios include auditing notification coverage for a portfolio of awards, generating recipient lists for a specific award event, and feeding downstream systems that require award-to-user mappings. A representative query lists all notifications for a given award:

  • SELECT award_number, award_short_name, event_type, user_name, user_full_name FROM apps.gms_notifications_v WHERE award_number = :award_number ORDER BY event_type, user_name;
  • SELECT user_name, user_full_name, COUNT(*) notifications FROM apps.gms_notifications_v GROUP BY user_name, user_full_name ORDER BY notifications DESC;
  • SELECT award_id, event_type, COUNT(DISTINCT user_id) recipients FROM apps.gms_notifications_v GROUP BY award_id, event_type;

Because HR_SECURITY participates in the person resolution, results may be filtered by the querying user's HR security profile, and report writers should test with the actual runtime responsibility. For bulk extraction, restrict by award_id or event_type to limit the join cost against the person view. The view is read-only and should never be used as a target for DML; modifications belong to GMS_NOTIFICATIONS.