Search Results award_template_flag




Overview
Explore in AI Chat

Overview

GMS_AWARDS_SRS_V is a reporting view owned by the APPS schema in Oracle E-Business Suite, delivered as part of the GMS (Grants Accounting) product family. It exposes a narrow, denormalized projection of award master data intended primarily for Oracle Reports, BI Publisher extracts, and other SRS (Standard Reporting System) style outputs where a lightweight, read-only result set is preferable to the full column set of the underlying award entity. The view carries VALID status in the ETRM metadata for release 12.2.2 and remains structurally stable across 12.1.1 and 12.2.2.

The view is significant for the search term award_template_flag because it surfaces the AWARD_TEMPLATE_FLAG column directly, allowing report consumers to distinguish template awards from operational awards without joining to additional GMS tables. This makes the view a common source for award listing reports that must separate template records used for copying award structures from live, transactable awards.

Underlying Base Objects

GMS_AWARDS_SRS_V is defined over a single base object: the GMS_AWARDS table, referenced in the view definition through its APPS synonym. The view performs a simple projection — no aggregation, set operators, or joins are present in the documented view text — returning seven columns selected from GMS_AWARDS: AWARD_ID, AWARD_NUMBER, AWARD_SHORT_NAME, AWARD_PROJECT_ID, AWARD_TEMPLATE_FLAG, STATUS, and ORG_ID.

Because the relationship is a straight column-to-column mapping, filtering, sorting, and ORG_ID-based multi-org security behave identically to querying GMS_AWARDS directly, but with a reduced attribute footprint. The documented synonym reference (GMS_AWARDS) confirms that the view is intended to be resolved in the APPS context and that no cross-schema dependency beyond the standard APPS synonyms is introduced.

Key Columns

  • AWARD_ID — Primary key of the award record; the standard join key to GMS_AWARD_BUDGETS, GMS_AWARD_PROJECTS, and other Grants Accounting child entities.
  • AWARD_NUMBER — The user-visible award identifier used in reports and correspondence.
  • AWARD_SHORT_NAME — Abbreviated award name, frequently used in list-of-values and concise report layouts.
  • AWARD_PROJECT_ID — Reference to the associated project, linking the award to Oracle Projects (PA) for cost and billing processing.
  • AWARD_TEMPLATE_FLAG — Indicates whether the award is a template. Template awards are used as a source for creating new awards and typically should be excluded from operational reporting; this column is the primary reason users query this view.
  • STATUS — Lifecycle status of the award (for example, active versus terminated), controlling which records are eligible for downstream transactions.
  • ORG_ID — Operating unit identifier, enforcing Multi-Org Access Control (MOAC) so that report output is restricted to the operating units the user is authorized to access.

Common Use Cases and Queries

The most frequent use case is an award listing report that must exclude template awards. Filtering on AWARD_TEMPLATE_FLAG removes the template records that would otherwise clutter operational output.

Example — list all non-template awards for the current operating unit:

  • SELECT award_id, award_number, award_short_name, award_project_id, status FROM apps.gms_awards_srs_v WHERE award_template_flag = 'N';

Example — inventory awards marked as templates for administrative review:

  • SELECT award_number, award_short_name, status FROM apps.gms_awards_srs_v WHERE award_template_flag = 'Y' ORDER BY award_number;

Example — join to Oracle Projects for award-to-project reconciliation:

  • SELECT a.award_number, a.award_project_id, p.name FROM apps.gms_awards_srs_v a, apps.pa_projects_all p WHERE a.award_project_id = p.project_id AND a.status = 'ACTIVE';

Because the view is read-only and contains no user-defined logic, it is also suitable as a source for interface and integration extracts where only the core award header attributes are required. ORG_ID filtering is normally applied automatically through MOAC in a report context but should be added explicitly in ad hoc SQL executed outside a MOAC-aware session.