Search Results gms_award_pub




Overview
Explore in AI Chat

Overview

GMS_AWARD_PUB is the public PL/SQL API package for the Oracle E-Business Suite Grants Management (GMS) module, delivered in the APPS schema. In Oracle EBS 12.1.1 and 12.2.2, it serves as the supported entry point for programmatic manipulation of award records — the central business object of the grants lifecycle. Awards capture sponsored funding agreements, their terms, budgets, personnel, contacts, billing and rate schedules, and the installment and reporting structures that drive post-award administration.

The package follows the standard EBS API architecture: the _PUB package exposes a stable, documented interface intended for external callers, while delegating the substantive business logic, validation, and DML to the companion private package GMS_AWARD_PVT. This separation allows Oracle to evolve internal processing without breaking integrations that depend on the public signatures. Error signaling is handled through the FND message stack (FND_MSG_PUB, FND_MESSAGE), and caller context is derived from FND_GLOBAL and MO_GLOBAL, consistent with multi-org and API conventions used throughout the applications. The object is documented with a status of VALID and a PUBLIC API classification in the ETRM reference set, confirming it as an intended integration surface rather than an internal helper.

Key Procedures and Functions

ETRM documents nine public procedures and functions within GMS_AWARD_PUB:

  • CREATE_AWARD — Creates a new award header record in the grants repository, establishing the sponsored agreement and its core attributes.
  • COPY_AWARD — Duplicates an existing award to produce a new award, supporting renewal, continuation, or template-based award setup.
  • CREATE_INSTALLMENT — Defines an installment line associated with an award, used to schedule funded amounts over time.
  • CREATE_PERSONNEL — Adds personnel assignments to an award, identifying investigators or staff associated with the sponsored project.
  • CREATE_TERM_CONDITION — Attaches a term or condition to an award, capturing sponsor-imposed requirements and compliance clauses.
  • CREATE_REFERENCE_NUMBER — Adds a reference identifier to the award, such as a sponsor award number or internal cross-reference.
  • CREATE_CONTACT — Records a contact party for the award, supporting sponsor and administrative contact tracking.
  • CREATE_REPORT — Establishes a reporting requirement for the award, linking the award to its deliverable reporting obligations.
  • ADD_FUNDING — Adds funding to an award, updating the funded amounts that drive budgeting and billing.

Tables Accessed

The package references the following tables through APPS synonyms:

  • GMS_AWARDS_ALL — The primary award table, holding award header information. This is the principal target of CREATE_AWARD and COPY_AWARD.
  • GMS_INSTALLMENTS — Stores installment schedules tied to awards, written by CREATE_INSTALLMENT.
  • GMS_ALLOWABILITY_SCHEDULES — Holds allowability schedule definitions used to determine which cost categories are permissible under an award.
  • PA_BILLING_CYCLES — The Projects billing cycle reference, used when awards drive billing through Oracle Projects integration.

The dependency listing additionally identifies PA_IND_RATE_SCHEDULES, indicating interaction with indirect rate schedules for award rate configuration. Reference to GMS_AWARD_PVT confirms delegation of the core processing logic.

Usage Notes

GMS_AWARD_PUB is invoked whenever award data must be created or extended outside the standard Grants Management forms. Typical callers include the GMS award maintenance forms and concurrent programs that perform award creation, copying, or bulk loading. Custom integrations and extensions — for example, interfaces that import award data from external sponsor systems — should call the _PUB procedures rather than writing directly to the base tables, so that validation, defaults, message handling, and any downstream processing performed by GMS_AWARD_PVT are preserved.

As the package is not referenced by any other database object, it is a leaf-level API whose consumers are external: forms, concurrent managers, and custom code. Multi-org context must be initialized before invocation, given the dependency on MO_GLOBAL and FND_GLOBAL. Errors should be checked against the FND message stack after each call, per standard EBS API practice.