Search Results duplicate_configuration




Overview
Explore in AI Chat

Overview

PER_RI_MNG_CFG_PKG is a PL/SQL configuration management package owned by the APPS schema in Oracle E-Business Suite. Its name derives from the Oracle Human Resources ("PER") product family, the "RI" (Responsibility Interface / Rules Information) subsystem, and its role as a configuration ("MNG_CFG") manager. The package provides the programmatic maintenance layer for Oracle HRMS configuration definitions — the records that describe named, reusable configurations for HR self-service and related responsibility-driven functionality. It exposes a narrow, purpose-built API surface consisting of two procedures, DELETE_CONFIGURATION and DUPLICATE_CONFIGURATION, which together support the lifecycle operations most commonly required when administrators clone, adapt, or retire an existing configuration. The package is classified in the ETRM repository as an OTHER API, meaning it is a supporting internal package rather than a public, externally supported integration interface; nevertheless, because it operates directly against documented configuration tables, it is frequently encountered when tracing setup, migration, or troubleshooting scenarios involving configuration duplication.

Key Procedures and Functions

  • DELETE_CONFIGURATION — Removes an existing configuration identified by a configuration code. A caller supplies the configuration code and an object version number used for optimistic locking and concurrency control. The procedure returns a status message through an OUT parameter, allowing the caller to determine whether the deletion succeeded or why it failed. This is the standard programmatic path for retiring obsolete or erroneous configuration records without resorting to direct SQL.
  • DUPLICATE_CONFIGURATION — Creates a new configuration by copying an existing one, identified by its configuration code, while assigning a caller-supplied configuration name and description. An Enterprise Sequence Number (ESN) parameter identifies the business group or enterprise context in which the new configuration is created. As with deletion, a message OUT parameter reports success or failure. This procedure is the documented mechanism behind the common "duplicate configuration" operation and is the object most relevant to searches for duplicate_configuration.

Both procedures communicate exclusively through named parameters and a message return value; no function-style return values are documented.

Tables Accessed

The package operates against two documented tables, reached through APPS synonyms:

  • PER_RI_CONFIG_INFORMATION — The primary configuration header store. Duplication reads the source row (and its descriptive attributes such as name and description) from this table and inserts the new configuration; deletion removes the corresponding row.
  • PER_RI_CONFIG_LOCATIONS — Holds configuration-to-location detail. Duplication must copy any location-level child rows associated with the source configuration so the new configuration is functionally complete, while deletion must remove them to avoid orphaned detail records.

Usage Notes

PER_RI_MNG_CFG_PKG is typically invoked indirectly. In a standard EBS 12.1.1 or 12.2.2 environment it is called from the Oracle HRMS configuration setup forms or from concurrent programs that administer configuration definitions, rather than being executed directly by end users. The ETRM metadata records no other packages referencing it, so its dependents are chiefly form-level logic, concurrent request handlers, and custom extensions.

Custom code performing configuration migrations or bulk duplications should call DUPLICATE_CONFIGURATION rather than inserting into the underlying tables directly, because the procedure enforces the insert of both header and location detail and applies concurrency checks via the ESN and object version parameters. Callers must always inspect the returned message parameter, since the procedures signal failure through that OUT value rather than by raising an exception. Direct calls should be made as the APPS schema or through a synonym, and any duplication activity should first be validated in a non-production environment because created configurations immediately participate in HRMS setup.