Search Results award_project




Overview

GMS_PROJECT_TYPES is a read-only view owned by the APPS schema within the Oracle E-Business Suite Grants Accounting (GMS) module. It exposes a filtered, reporting-friendly projection of Oracle Projects project type definitions, and its defining characteristic is an explicit exclusion of the reserved project type value AWARD_PROJECT. Because Grants Accounting relies on the distinction between sponsored and non-sponsored project types, the view provides a stable, secure access point through which grant-related concurrent programs, forms, and reports can resolve project type descriptions and classifications without exposing the internal award project construct that the applications layer manages separately.

The view is registered in ETRM with a VALID status and is available in both 12.1.1 and 12.2.2. In EBS reporting and integration scenarios, it functions as a semantic layer over the PA_PROJECT_TYPES lookup, narrowing the result set to legitimate user-selectable project types and normalizing a nullable flag column into a predictable value.

Underlying Base Objects

GMS_PROJECT_TYPES is defined over a single documented base object: the synonym PA_PROJECT_TYPES, which resolves to the Oracle Projects project type definition table in the same APPS schema. There is no join, aggregation, or union in the view definition; the transformation is limited to a WHERE predicate and a DECODE expression. Consequently, the view inherits the multi-org partitioning of its base object through the ORG_ID column and does not introduce any additional denormalization.

The defining predicate restricts rows to those where PA.PROJECT_TYPE <> 'AWARD_PROJECT'. In Grants Accounting, award projects are created and maintained through internal award processing rather than being offered as a general project type choice. Filtering this reserved type prevents it from appearing in project-type lists and lookup queries that drive user-facing configuration and reporting.

Key Columns

  • PROJECT_TYPE — The project type identifier, carried directly from PA_PROJECT_TYPES. It is the primary semantic key of the view and excludes the reserved AWARD_PROJECT value.
  • DESCRIPTION — The user-facing description of the project type, used in list of values displays, reports, and configuration screens.
  • PROJECT_TYPE_CLASS_CODE — The classification code that determines the behavior of the project type, including its associated project and task flexfield structures and costing behavior. Grants Accounting uses this code to distinguish sponsored project types from capital and indirect types.
  • SPONSORED_FLAG — A flag indicating whether the project type is sponsored. The view applies DECODE(SPONSORED_FLAG, NULL, 'N', SPONSORED_FLAG), guaranteeing a non-null value so that downstream reports and integrations never encounter a null sponsored indicator.
  • ORG_ID — The operating unit identifier used by Multi-Org security, enabling the view to be queried within the context of a specific operating unit through standard EBS org-secured views and policies.

Common Use Cases and Queries

The view is primarily used in Grants Accounting reporting and in integration interfaces that must restrict project type selection to sponsored, non-award types. Typical scenarios include driving lists of values in custom forms, validating project type values in inbound interfaces, and producing configuration reports of available sponsored project types.

  • Retrieving all sponsored project types for a specific operating unit:
SELECT project_type, description, project_type_class_code
FROM   apps.gms_project_types
WHERE  sponsored_flag = 'Y'
AND    org_id = :p_org_id
ORDER BY project_type;
  • Resolving the description and classification for a single project type:
SELECT project_type, description, project_type_class_code, sponsored_flag
FROM   apps.gms_project_types
WHERE  project_type = :p_project_type;

Because the view already excludes AWARD_PROJECT and normalizes SPONSORED_FLAG, consuming code should not need to reapply those filters, though adding an explicit ORG_ID predicate remains necessary in any Multi-Org secured query. As with all APPS views, access should be granted through the standard Grants Accounting responsibilities rather than directly to the base table.