Search Results migrate_cer_rows




Overview
Explore in AI Chat

Overview

The APPS.BEN_PD_MIGRATE package is a PL/SQL migration utility within the Oracle E-Business Suite Advanced Benefits (BEN) module. Its business function is to move or convert benefit-related copied entity result data from one storage context to another as part of a data migration, copy, or upgrade cycle. The package is declared with AUTHID CURRENT_USER, meaning its procedures execute with the privileges of the invoking schema rather than with the definer's rights. This design is typical of internal migration routines that are executed in controlled administrative contexts where the caller already holds the necessary object privileges.

The source header file identifier (bepdcmig.pkh, version 115.0, dated 2003) indicates the package formed part of the original Benefits entity-copy framework delivered in the 11i generation and carried forward into EBS 12.1.1 and 12.2.2 without structural change. The API classification is documented as OTHER, confirming that it is not a public, supported business API but an internal migration procedure.

Key Procedures and Functions

The package exposes a single documented procedure:

  • MIGRATE_CER_ROWS — This is the sole public routine in the package specification. Its name indicates that it migrates "CER" (Copy Entity Results) rows. It accepts a single input of a copy entity transaction identifier, which scopes the migration to the result set produced by a specific copy-entity execution. The procedure is responsible for relocating or transforming the result rows generated during an entity copy operation so that downstream benefits processing can consume them from the correct source.

No additional functions or overloaded signatures are documented. The procedure does not return a value; it performs its work through direct DML against the tables described below and relies on the transaction context of the caller for commit or rollback control.

Tables Accessed

The documented tables referenced through APPS synonyms are:

  • BEN_COPY_ENTITY_RESULTS — the primary Benefits copy-entity results table, holding the outcome rows produced by a copy operation. This is the principal source and/or target of the migration.
  • BEN_COPY_ENTITY_RESULTS_S — the corresponding date-tracked shadow (or "_S") table that stores the historical or effective-dated version of each result row. The procedure must maintain this table in step with its base table to preserve date-track integrity.
  • PQH_COPY_ENTITY_RESULTS — the Public Sector / HR (PQH) counterpart results table, reflecting the shared copy-entity architecture used across HRMS products.
  • PQH_TABLE_ROUTE — a routing/configuration table that determines which physical or logical table a given entity's copy results should be directed to. The migration logic consults this to resolve the correct destination.
  • PLITBLM — an internal generic PL/SQL table/message utility used for bulk row handling or error messaging during the migration.

Usage Notes

BEN_PD_MIGRATE is an internal routine and is not intended for direct invocation by end users or customer extensions. It is typically called from within the Benefits copy-entity concurrent programs or from higher-level migration drivers that orchestrate a full benefit plan copy, upgrade, or data-conversion cycle. Because the package is referenced by zero other packages in the documented metadata, it is generally invoked as a top-level call within a processing flow rather than as a shared dependency.

When invoked, the caller must supply a valid copy entity transaction identifier created by the preceding copy-entity process. Transaction control (COMMIT and ROLLBACK) remains the responsibility of the calling program, so the migration participates in the caller's unit of work. Given its AUTHID CURRENT_USER declaration, execution privileges derive from the invoking schema, and administrators should ensure the job runs under a schema with appropriate access to the BEN and PQH tables. Because no formal public API contract is documented, the procedure should be treated as version-sensitive and invoked only through Oracle-delivered processing paths.