Search Results field_names

Overview

GR_FIELD_NAMES_PUB is the public application programming interface for maintaining field name metadata within the Oracle E-Business Suite Process Manufacturing (OPM) label and field framework. The package is owned by APPS and is classified as a public (PUB) API, meaning it is intended for invocation by external callers such as Oracle Forms, concurrent programs, and custom extensions rather than being restricted to internal use.

The header comment identifies the package as the "public layer for the FIELD NAMES API," indicating that it wraps lower-level validation and persistence logic behind a stable, callable interface. The package was authored by Peter Lowe of OPM Unlimited Development, with the initial version written on 06 December 2008 and subsequently updated on 10 July 2008 under Bug 7247651. The version string GRPIFNSB.pls 120.4, dated 19 November 2010, reflects the final shipped revision of the body referenced by the ETRM documentation.

The business purpose of the package is to register, describe, and classify field names used in label generation and technical parameter handling. It supports multi-language installations through language and source-language parameters, allowing field descriptions and labels to be maintained across the languages defined in the application.

Key Procedures and Functions

• set_debug_flag — A private forward-declared function that returns a single-character debug indicator. It evaluates the FND_LOG runtime level and returns 'Y' or 'N'. The body is notable in that it unconditionally sets the flag to 'Y', so debug logging is always considered active for this package.
• FIELD_NAMES — The sole documented public procedure. It is the entry point for creating, updating, or otherwise processing a field name definition. Its signature accepts the standard API control arguments (API version, initialization of the message list, and commit), an action indicator, and object and field identifiers. It further receives a field name class, a technical parameter flag, language and source-language codes, a description, and a PL/SQL table of label properties. It returns the standard outcome triplet: return status, message count, and message data.

The procedure declares its own API name constant ('FIELD_NAMES') and API version (1.0) internally, consistent with Oracle's API conventions for error attribution via FND_MSG_PUB.

Tables Accessed

The documented table references, resolved through APPS synonyms, comprise the label and property metadata repository:

• GR_LABELS_B and GR_LABELS_TL — Base and translated label definitions; the _TL table supports the multi-language parameters accepted by FIELD_NAMES.
• GR_LABEL_CLASSES_B — Label class definitions used to associate a field name with its classification (the p_field_name_class argument).
• GR_LABEL_PROPERTIES — Property rows for labels; this is the table populated from the p_label_properties_tab collection.
• GR_PROPERTIES_B — Property definitions that constrain valid label properties.
• FND_LANGUAGES — The installed language list, used to validate language codes and determine translation requirements.
• PLITBLM — A standard Oracle Applications temporary/interface table used for bulk processing.

Usage Notes

GR_FIELD_NAMES_PUB is typically invoked from the OPM label setup forms or from concurrent programs that load or migrate field name definitions. Custom code should call FIELD_NAMES rather than touching the underlying GR_LABELS and GR_LABEL_PROPERTIES tables directly, because the procedure performs the validation, class resolution, and message handling required for data integrity.

Callers must always inspect x_return_status; the conventional values are FND_API.G_RET_STS_SUCCESS, FND_API.G_RET_STS_ERROR, and FND_API.G_RET_STS_UNEXP_ERROR. When the status is not success, x_msg_count and x_msg_data should be used to retrieve the error stack. The p_commit argument controls transaction boundaries, so callers that process multiple field names in one logical unit should pass FND_API.G_FALSE and commit explicitly. The ETRM metadata records no other packages referencing this API, so its use is confined to direct invocation contexts. The unconditional debug flag is a known quirk of version 120.4 and may increase FND_LOG output in environments with logging enabled.