Search Results gms_awards_contacts




Overview
Explore in AI Chat

Overview

GMS_AWARDS_CONTACTS is a table in the GMS (Grants Accounting) schema within Oracle E-Business Suite, holding the association between awards and the contacts (individuals or parties) tied to them. In the EBS 12.1.1 and 12.2.2 data models, the GMS schema underpins the Grants Accounting module, and this table serves as the junction that records which contacts are attached to a sponsored award and in what capacity. Its metadata description is "Contacts of award," confirming its role as a subordinate child of the award entity.

The mined Data Vault classification for this object is standalone. In data-vault modeling terms, this suggests the table is neither a pure hub nor a conventional satellite in the mined graph; it behaves as a self-contained association table anchored to the award. Rather than treating it as an independent hub, modelers should view it as a dependent link-like construct that resolves the many-to-many relationship between awards and contacts, carrying descriptive attributes (such as the primary flag and usage code) directly on the relationship.

Key Information Stored

The table contains 10 documented columns. The most significant are:

The unique index GMS_AWARDS_CONTACTS_U1 is defined on (AWARD_ID, CONTACT_ID, CUSTOMER_ID, USAGE_CODE), which serves as the business-key candidate. This composite key enforces that a given contact-party pair can appear only once per usage code for an award. There is no separate standalone surrogate primary key documented beyond the uniqueness constraint on this composite.

Common Use Cases and Queries

The most common reporting need is to list contacts for a given award, often filtered by usage code or primary flag. A straightforward join pattern is:

  • SELECT c.contact_id, c.customer_id, c.usage_code, c.primary_flag FROM gms_awards_contacts c WHERE c.award_id = :award_id;
  • To retrieve only the primary contact per award usage: ... WHERE c.primary_flag = 'Y' AND c.usage_code = :usage;
  • To resolve the parent award details, join to IGF_AW_AWARD_ALL on c.award_id = a.award_id.

Typical scenarios include generating award contact lists for correspondence, validating that each award has at least one primary contact per usage, and feeding downstream notifications or workflow routing. Because the unique key is on the composite of award, contact, customer, and usage, integrity checks that detect duplicate or missing contacts are naturally expressed with GROUP BY over those columns.

Related Objects

The FK relationship from GMS_AWARDS_CONTACTS.AWARD_ID to IGF_AW_AWARD_ALL is the central dependency. The award header in IGF_AW_AWARD_ALL is the master entity against which all contact rows are validated. Contact and customer identifiers typically resolve against the Trading Community Architecture (TCA) party/customer model, so joins to HZ_PARTIES or HZ_CUST_ACCOUNTS are common when contact names and addresses are required. The usage code is usually validated against a GMS lookup, and the primary flag drives presentation logic in the Grants Accounting award forms and concurrent programs. Reporting views and DBI (Daily Business Intelligence) extracts for Grants Accounting frequently read this table alongside award, funding, and budget tables to produce sponsor and contact summaries.