Search Results pay_dyt_contracts_pkg




Overview
Explore in AI Chat

Overview

PAY_DYT_CONTRACTS_PKG is an Oracle EBS PL/SQL package that resides in the APPS schema and carries a status of VALID in both release 12.1.1 and 12.2.2. Its naming convention ("DYT" for date-tracked or date-effective, and "CONTRACTS" for the Contracts business entity) places it within the Oracle Payroll and Oracle Human Resources date-tracked entity infrastructure. The package supports the date-tracked processing model used by the Contracts (CTC) entity, which is a datetracked (effective-dated) object in Oracle HRMS. In this model, the base record and its associated date-tracked history are maintained in separate tables, and the application relies on database triggers to keep those tables synchronized whenever a change is committed. PAY_DYT_CONTRACTS_PKG provides the PL/SQL helper logic invoked by the row-level triggers (PER_CTC_RKD, PER_CTC_RKI, PER_CTC_RKU) that fire against the Contracts table. In effect, the package encapsulates the routine behavior required to keep the Contracts entity consistent with the DateTrack framework, insulating trigger code from repetitive procedural logic.

Key Procedures and Functions

The ETRM metadata documents four entry points within this package:

  • PER_CONTRACTS_F_ARU_ARU — a date-tracked helper routine associated with the Contracts entity's after-row-update (ARU) processing path. Consistent with the naming pattern PER_<ENTITY>_F_ARU_ARU, this function is the core worker that performs the post-update synchronization steps for a Contracts record, applying the after-update/after-update sequencing used by the DateTrack model.
  • AFTER_INSERT — invoked in the trigger's after-insert phase to carry out post-insert processing for a newly created Contracts row, ensuring that dependent date-tracked data is populated or reconciled immediately after insert.
  • AFTER_UPDATE — executed in the after-update phase to handle the consequences of modifying an existing Contracts record, including any DateTrack-sensitive adjustments required after the primary row is changed.
  • AFTER_DELETE — called in the after-delete phase to process the removal of a Contracts record, cleaning up or adjusting related data so that no orphaned date-tracked information remains.

No parameter lists are documented for these procedures or functions, so their exact signatures should be verified against the deployed source via the EBS "Show Dependent Code" feature before being referenced directly from custom code.

Tables Accessed

The ETRM metadata for this object does not enumerate the specific database tables accessed. Based on the documented dependency graph — the package is referenced by the Contracts triggers PER_CTC_RKD, PER_CTC_RKI, and PER_CTC_RKU — the package operates on the tables underlying the Contracts date-tracked entity, namely the base PER_CONTRACTS table and its associated date-tracked/date-history counterpart, together with any dependent tables written during the after-insert, after-update, and after-delete paths. Confirmation of the precise table list is best obtained by inspecting the package body in the EBS environment, since the metadata excerpt does not record it.

Usage Notes

PAY_DYT_CONTRACTS_PKG is not normally called from forms, concurrent programs, or custom code directly. Its documented callers are the three Contracts triggers — PER_CTC_RKD, PER_CTC_RKI, and PER_CTC_RKU — which means the package is exercised automatically whenever a Contracts record is inserted, updated, or deleted through the standard Oracle HRMS forms or any API that manipulates the underlying table. The package itself depends on SYS.STANDARD and shows a dependency block reference, indicating it is pure PL/SQL built on core language services. Because the logic is trigger-driven, custom extensions should modify Contracts data only via supported APIs and forms so that this package and its trigger callers execute as intended. Direct invocation is documented as technically possible (it is referenced by three other packages) but should be avoided, as it bypasses the trigger context the routine expects. Before depending on any procedure signature, developers should retrieve the package source using the standard ETRM or "Show Dependent Code" facility, since the metadata records only names, not parameters.