Search Results gr_field_names_pub




Overview
Explore in AI Chat

Overview

GR_FIELD_NAMES_PUB is a public PL/SQL package in the APPS schema that belongs to the Oracle E-Business Suite governance, risk, and compliance (GRC) product family — specifically the component historically delivered as Oracle Applications "GR" (the predecessor naming used within the ETRM/GRC data model). Its documented business function is to resolve and return the display names of fields, labels, and related metadata used throughout the GRC user interface. In EBS environments, the GRC modules present configurable fields, labels, and label classes whose captions are not hard-coded; they are stored as rows in label and property tables and rendered at runtime. GR_FIELD_NAMES_PUB provides the public, callable interface through which forms, concurrent programs, and other PL/SQL units obtain the correct, language-aware field names without directly querying the underlying label and property tables.

The package is classified as a PUB (public) API, which indicates it is an officially supported entry point intended for invocation by other application code. It is marked VALID in both 12.1.1 and 12.2.2, confirming availability across the two release lines.

Key Procedures and Functions

The documented package exposes a single public program unit:

  • FIELD_NAMES — The sole documented procedure/function in the package. It is the entry point that returns field-name information for the caller. Because the ETRM metadata does not publish the formal parameter list, the exact signature is not reproduced here; callers should obtain the signature from the package specification in the database (for example, by describing APPS.GR_FIELD_NAMES_PUB or querying ALL_ARGUMENTS) before invoking it. Its purpose is to resolve the field names associated with GRC labels and properties, driving consistent caption and field-name display across the application.

Tables Accessed

The package reads from the following tables, referenced through APPS synonyms:

  • GR_LABELS_B and GR_LABELS_TL — the base and translation tables holding label definitions. The _TL table supplies the language-specific text, which is why FIELD_NAMES supports multiple languages.
  • GR_LABEL_CLASSES_B — classifies labels into logical groups, allowing the package to return names organized by label class.
  • GR_LABEL_PROPERTIES — associates labels with properties and attributes that govern how field names are resolved and displayed.
  • GR_PROPERTIES_B — stores the property definitions referenced by the label-property relationships.
  • FND_LANGUAGES — the Oracle Applications language table, used to determine the active or requested language for translated label retrieval.
  • PLITBLM — a PL/SQL internal table type (associative array) commonly used in EBS APIs to pass collections of identifiers or names. Its presence suggests FIELD_NAMES accepts or builds a bulk collection of field identifiers and returns corresponding names for set-based processing.

No insert, update, or delete targets are documented; the package behaves as a read-only metadata resolver.

Usage Notes

GR_FIELD_NAMES_PUB is referenced by the package GR_FIELD_NAMES_PUB itself (a self-reference in the dependency listing) and depends on FND_API and the SYS.STANDARD package, consistent with standard EBS API conventions — notably FND_API for the standard API return-status and message-handling framework. No other packages are documented as referencing it, indicating it is called primarily from Oracle Forms, concurrent programs, or customer and partner customizations rather than from a deep internal package chain.

Typical invocation scenarios include: rendering GRC form fields with the correct configured and translated captions; custom concurrent programs or reports that must output field names matching the on-screen labels; and integration or extension code that needs to resolve a label or property key to its human-readable field name. Because the package is a supported PUB API, direct queries against the underlying GR_LABELS and GR_PROPERTIES tables should be avoided in favor of calling FIELD_NAMES, which applies the correct language resolution and class/property logic and insulates custom code from schema changes.