Search Results gms_award_status

Overview

The APPS.GMS_AWARD_STATUS package is a small, purpose-built PL/SQL package belonging to the Oracle Grants Management (GMS) application family within Oracle E-Business Suite. It is declared with AUTHID CURRENT_USER, meaning its SQL statements execute under the privileges of the invoking user rather than the package owner, which is a common convention for utility routines that must respect the caller's data-access context and any row-level security applied in GMS. The package encapsulates award-status resolution logic — specifically, the determination of a primary member (personnel) associated with a given award. Its scope is deliberately narrow: the source header (gmsawrls.pls 115.3) and the documented procedure list confirm a single public function. Because it exposes only one routine and is referenced by zero other packages, it functions as a leaf-level utility invoked by forms, concurrent programs, or custom extensions rather than as a shared framework API. Its naming and the presence of the $Header RCS tag indicate it was authored as part of the original GMS release stream and has remained stable, with the last recorded revision dating to 2002.

Key Procedures and Functions

The package exposes a single documented function:

• GMS_PRIMARY_MEMBER — Accepts an award identifier (a NUMBER, conventionally the AWARD_ID) and returns a NUMBER. Its purpose is to resolve and return the identifier of the primary member associated with the specified award. This is typically used to determine the principal investigator or key personnel record that should be treated as primary for a given award, supporting downstream display, approval routing, or reporting decisions that depend on knowing who owns the award academically.

The metadata documents exactly one procedure or function, and no additional parameters are enumerated in the available source excerpt. No other public or private routines are documented for this package, so implementations should treat GMS_PRIMARY_MEMBER as the sole supported entry point.

Tables Accessed

Although the source excerpt does not show the function body, the documented table references via APPS synonyms identify the data the package works with:

• GMS_AWARDS — The core award header table. It supplies the award context keyed by the incoming AWARD_ID and would be consulted to validate or locate the award record.
• GMS_PERSONNEL — The award personnel assignment table. This is the primary source for resolving which member qualifies as the "primary" member, since it holds the relationship between awards and the people associated with them, including any primary-member flag or role designation.

Together these tables allow the function to move from an award identifier to the corresponding personnel record that represents the award's principal or primary member. No write operations are implied by the documented signature, which returns a NUMBER; the package behaves as a read-only lookup utility.

Usage Notes

Because GMS_AWARD_STATUS is classified as OTHER and is referenced by no other packages, it is not part of an automated call chain within the GMS schema. Typical invocation scenarios include:

• Oracle Forms — Grants Management forms that need to display or default the primary member for an award can call GMS_PRIMARY_MEMBER from a post-query or when-validate trigger, passing the current award ID.
• Concurrent programs and reports — Reporting logic that must group or filter award data by primary member can call this function per award row.
• Custom extensions and integrations — Developers building extensions on GMS who require the same primary-member resolution can reuse the package rather than reimplementing the lookup against GMS_PERSONNEL, ensuring consistency with standard Grants behavior.

Callers should note the AUTHID CURRENT_USER declaration: the invoking user must possess the necessary privileges on GMS_AWARDS and GMS_PERSONNEL (typically via the APPS synonym grants). The function returns a NUMBER and does not raise a documented exception contract, so custom code should defensively handle NULL or unexpected return values when an award has no designated primary member. Given the stable revision history, the interface can be regarded as reliable across EBS 12.1.1 and 12.2.2.