Search Results gms_awards_boundary_dates_chk




Overview
Explore in AI Chat

Overview

The APPS.GMS_AWARDS_BOUNDARY_DATES_CHK package provides centralized date-validation logic for Oracle Grants Management award and project records. Its principal business function is to ensure that boundary dates entered against an award or project — start dates, end dates, and installment dates — remain internally consistent and do not conflict with existing baselined budgets, encumbrances, expenditures, or other transactional activity. The package is classified as an OTHER API in the ETRM metadata, indicating that it is not a public, supported interface but rather an internal validation utility referenced by Oracle Grants forms and concurrent processing. The header revision string (gmsawvds.pls 120.1) and embedded bug references (Bug 2269791 and Bug 4138033) confirm that the package has been maintained to address specific date-integrity defects reported against earlier releases. Although documented under 12.1.1 and 12.2.2, the object is identical in both releases, and the header date of 2005 indicates it predates the 12.x family and has remained stable.

Key Procedures and Functions

The metadata documents four procedures, each designed to validate a distinct date boundary and return a message to the caller rather than raising an unhandled exception.

  • VALIDATE_START_DATE — Validates an award start date for a given award identifier. It checks that the proposed start date is sensible relative to the award's other date attributes and existing activity.
  • VALIDATE_END_DATE — Validates an award end date for a given award identifier. This is the procedure most directly associated with the user search term validate_end_date; it is the entry point used when a user changes an award's completion or expiration date and the system must confirm no transactions fall outside the revised boundary.
  • VALIDATE_INSTALLMENT — Added specifically for Bug 2269791, this procedure validates changes to installment dates when a baselined budget already exists for the award. It prevents installment schedule modifications that would invalidate baselined budget data.
  • VALIDATE_PROJ_START_DATE — Validates a change to a project start date, checking whether any transactions exist outside the modified date range. Bug 4138033 added an optional task identifier so that validation can be narrowed to a specific task within the project.

The metadata also lists VALIDATE_PROJ_COMPLETION_DATE in the source excerpt, which performs the analogous check for project completion dates and likewise accepts the optional task parameter introduced by Bug 4138033. The summary procedure count of four reflects the distinctively documented procedures in ETRM, but the source excerpt confirms five declared procedures in total.

Tables Accessed

The package reads from a broad set of transactional and budgetary tables through APPS synonyms. Grants Management tables — GMS_AWARD_DISTRIBUTIONS, GMS_BUDGET_LINES, GMS_BUDGET_VERSIONS, GMS_ENCUMBRANCE_ITEMS_ALL, and GMS_RESOURCE_ASSIGNMENTS — supply the award-level budget, encumbrance, and resource data against which date changes are tested. Oracle Projects tables PA_TASKS and PA_EXPENDITURE_ITEMS_ALL provide task structure and expenditure activity, allowing the package to detect transactions falling outside a proposed project date boundary. Purchasing and Payables tables — AP_INVOICES_ALL, AP_INVOICE_DISTRIBUTIONS_ALL, PO_DISTRIBUTIONS_ALL, PO_LINES_ALL, PO_REQUISITION_LINES_ALL, and PO_REQ_DISTRIBUTIONS_ALL — are queried to identify commitments, invoices, and requisition distributions that would conflict with a revised award boundary. DUAL is used for simple scalar evaluations.

Usage Notes

The package is invoked internally by Oracle Grants Management forms — most notably the Award Management and Project date-entry regions — at the point where a user commits a boundary date change. It is also callable from custom PL/SQL that needs to replicate the same validation before performing a direct update to award or project date columns. Because the procedures return an out message rather than raising exceptions, callers must explicitly inspect the returned message string and raise or display an error themselves. ETRM records zero packages referencing this object, confirming that it is a leaf-level validation utility with no dependent public APIs.