Search Results gms_encumbrance_groups




Overview

GMS_ENCUMBRANCE_GROUPS is a Grants Accounting (GMS) view in Oracle E-Business Suite Release 12.1.1 and 12.2.2. It exposes the definition and control attributes of encumbrance groups — logical containers that aggregate related encumbrances for a sponsored project or award so that funds checking, control balances, and reporting can be performed at the group level rather than on individual encumbrance lines. Encumbrance groups are the mechanism by which Grants Accounting ties together requisitions, purchase orders, and other commitment documents that share a common funding source, enabling aggregate control over committed funds.

The view is not a stored object; it is a runtime projection of GMS_ENCUMBRANCE_GROUPS_ALL filtered by the current organization context. The ETRM metadata notes that the view is "Not implemented in this database," meaning the deployed instance examined contained no compiled version of this object, though the definition and column list are documented.

Underlying Base Objects

The view is defined solely over GMS_ENCUMBRANCE_GROUPS_ALL, the multi-organization (partitioned by ORG_ID) table that stores all encumbrance group headers across operating units. No additional base tables are documented in the ETRM metadata. The filter predicate applies the standard EBS organization-security pattern using USERENV('CLIENT_INFO'), extracting the first ten characters (or NULL when the first character is a space) and comparing it to ORG_ID, with a default of -99 when no organization context is set. This ensures that users see only encumbrance groups belonging to their current operating unit, consistent with the MULTI_ORG_VIEWS convention used throughout Grants Accounting. Because the view is read-only in practice, DML against encumbrance group definitions must be performed against GMS_ENCUMBRANCE_GROUPS_ALL or through the Grants Accounting application forms and APIs, which is significant when the view is unavailable (as noted above).

Key Columns

  • ENCUMBRANCE_GROUP — Primary identifier/name of the encumbrance group.
  • ENCUMBRANCE_GROUP_STATUS_CODE — Status of the group (for example, active, closed, or cancelled), governing whether new encumbrances may be attached.
  • ENCUMBRANCE_ENDING_DATE — Date through which the group remains effective for encumbrance control.
  • SYSTEM_LINKAGE_FUNCTION — The function or source system that created and owns the linkage for the group, distinguishing groups originating from different feeder applications. This is the column most often targeted by searches involving the term system_linkage_function.
  • CONTROL_COUNT — Number of encumbrance records controlled under the group.
  • CONTROL_TOTAL_AMOUNT — Aggregate encumbered amount controlled by the group.
  • TRANSACTION_SOURCE — Indicates the origin transaction type for the group.
  • ORG_ID — Operating unit that owns the group, and the column used by the organization-security predicate.
  • DESCRIPTION and the standard WHO audit columns (CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN) provide descriptive and audit context.

Common Use Cases and Queries

The view is used to report group-level commitment balances, to diagnose why certain documents are subject to fund control, and to audit groups by source system or status. A typical diagnostic query retrieves groups by linkage function:

  • SELECT encumbrance_group, encumbrance_group_status_code, encumbrance_ending_date, control_total_amount FROM gms_encumbrance_groups WHERE system_linkage_function = :p_linkage_function;
  • SELECT org_id, COUNT(*), SUM(control_total_amount) FROM gms_encumbrance_groups GROUP BY org_id; — balance summary by operating unit.
  • SELECT encumbrance_group, control_count, control_total_amount FROM gms_encumbrance_groups WHERE encumbrance_group_status_code = 'ACTIVE' AND encumbrance_ending_date < SYSDATE; — groups expiring for follow-up.

Because the view is not implemented in the reference database and inherits organization security from USERENV('CLIENT_INFO'), queries must be run from a session context that sets CLIENT_INFO correctly, otherwise all rows default to ORG_ID -99 and no data is returned.