Search Results check_unique_f




Overview
Explore in AI Chat

Overview

PAY_USER_COLUMNS_PKG is the Oracle EBS Payroll (PAY) package responsible for maintaining user-defined columns that extend the standard structure of user tables in the payroll and HR data model. User columns allow implementers to attach customer-specific attributes to payroll user tables without directly altering Oracle-delivered schema objects. This package provides the programmatic interface for inserting, updating, deleting, and validating rows in the PAY_USER_COLUMNS entity and its associated translation and instance tables. It also implements the standard EBS multi-lingual (TL) translation pattern, including language installation and translation validation routines. The package follows the conventional EBS table-handler design: row-level DML procedures, a lock procedure for optimistic concurrency control, uniqueness validation procedures, and a delete-eligibility check. Because the data model involves a translated (TL) table, the package includes the supporting ADD_LANGUAGE, TRANSLATE_ROW, SET_TRANSLATION_GLOBALS, and VALIDATE_TRANSLATION utilities that are typical of Oracle EBS translation-enabled entities. The package exposes a global variable g_dml_status and a corresponding detection routine, RETURN_DML_STATUS, which callers use to determine whether a DML operation succeeded within the current session.

Key Procedures and Functions

  • INSERT_ROW — Creates a new user column definition, including its identifier, owning user table, business group, legislation attributes, name, and formula reference.
  • UPDATE_ROW — Modifies an existing user column definition. Supports a base user column name parameter for translated column scenarios.
  • DELETE_ROW — Removes a user column row identified by its rowid.
  • LOCK_ROW — Acquires a row-level lock to support optimistic locking before update operations.
  • CHECK_UNIQUE — Validates that the combination of user column name, user table, and business group is unique.
  • CHECK_UNIQUE_F — Form-specific variant of the uniqueness check that additionally considers the legislation code (and base user column name).
  • CHECK_DELETE — Determines whether a user column may be deleted, typically by verifying that no dependent records exist.
  • ADD_LANGUAGE — Inserts translation rows for a new language as part of language installation.
  • TRANSLATE_ROW — Maintains translated attribute values for the TL table.
  • CHECK_BASE_UPDATE — Verifies whether the base (non-translated) record can be updated in the context of translation handling.
  • SET_TRANSLATION_GLOBALS — Initializes package-level globals used by the translation routines.
  • VALIDATE_TRANSLATION — Validates translation data before it is committed.
  • RETURN_DML_STATUS — Returns the value of the package global g_dml_status, indicating whether the most recent DML operation in the package succeeded.

Tables Accessed

  • PAY_USER_COLUMNS — The primary base table holding user column definitions.
  • PAY_USER_COLUMNS_S — The sequence/primary key tracking table used to generate unique identifiers.
  • PAY_USER_COLUMNS_TL — The translated table storing language-specific column name attributes.
  • PAY_USER_COLUMN_INSTANCES_F — The instance table representing user column values per user table instance; referenced by the delete-eligibility check.
  • FND_LANGUAGES — Consulted by the translation and language installation routines to resolve active languages.

Usage Notes

PAY_USER_COLUMNS_PKG is normally invoked indirectly rather than called by end users. Oracle Forms-based maintenance of user columns relies on the row-handler procedures (INSERT_ROW, UPDATE_ROW, DELETE_ROW, LOCK_ROW) together with the CHECK_UNIQUE_F validation. Language installation and translation maintenance invoke ADD_LANGUAGE and TRANSLATE_ROW through the standard EBS multi-lingual utilities. Concurrent programs and other payroll packages reference the package when synchronizing user column metadata, which is consistent with the metadata showing it is referenced by thirteen other packages. Custom code should follow the same pattern: perform the DML procedure, then call RETURN_DML_STATUS to confirm success before committing. Callers must supply valid business group and legislation context, since uniqueness and delete eligibility depend on these attributes. Direct DML against the underlying tables should be avoided, as the package enforces the required integrity, translation, and locking semantics.