Search Results check_for_duplicates

Overview

PER_PERSON_ANALYSES_PKG is a PL/SQL package body owned by the APPS schema in Oracle E-Business Suite. It encapsulates the server-side logic required to maintain person analysis records, the dated analytical or special-information entries that Oracle HRMS stores against a person in PER_PERSON_ANALYSES. These records are classified by rows in PER_ANALYSIS_CATEGORIES / PER_ANALYSIS_CRITERIA and constrained by descriptive flexfield segments identified through an ID_FLEX_NUM.

The package is classified in ETRM as an OTHER API (not a public, supported business API). Its primary responsibility is validation and derived-value generation for person analyses — detecting conflicting records before insert, generating unique identifiers, deriving a single special-information type, producing unique case numbers, and recomputing the INFO_EXISTS derived flag. It is not designed to be called as a standalone business interface; it is intended for internal HRMS use.

Key Procedures and Functions

• CHECK_FOR_DUPLICATES — The routine most commonly associated with this package. It searches for existing PER_PERSON_ANALYSES rows for the same person, analysis criterion, business group, and ID flex structure that share the same start date and the same end date (with NULL end dates normalized to an end-of-time value by the caller). The ROWID parameter allows the current row to be excluded during an update. When a conflicting row is found, the routine raises the standard HRMS message HR_6012_ROW_INSERTED, preventing the duplicate from being saved.
• GET_UNIQUE_ID — Obtains a unique identifier for a person analysis record, used to seed the primary/surrogate key before insertion.
• SINGLE_INFO_TYPE — Derives a single special-information type for the record. The header comments document a maintenance change made to compensate for the PER_SPECIAL_INFO_TYPES_V view no longer populating INFO_EXISTS as of r115.
• UNIQUE_CASE_NUMBER — Generates a unique case number for the analysis record, ensuring case-numbered analyses do not collide.
• POPULATE_INFO_EXISTS — Recomputes and maintains the INFO_EXISTS derived flag associated with the analysis, keeping it consistent with the underlying special-information definition after the view change referenced above.

Tables Accessed

• PER_PERSON_ANALYSES — The principal table. Holds the dated person analysis rows that CHECK_FOR_DUPLICATES scans and that the other routines populate.
• PER_PERSON_ANALYSES_S — The translated (_S) shadow table, used when writing or reading descriptive/translatable analysis text.
• PER_ANALYSIS_CRITERIA — Joined in CHECK_FOR_DUPLICATES on ANALYSIS_CRITERIA_ID and filtered by ID_FLEX_NUM to establish the flexfield context of the criterion.
• PAY_LEGISLATION_RULES and PAY_RESTRICTION_VALUES — Payroll legislation and restriction tables consulted to validate that the analysis type is legal for the person's payroll legislation and that no restriction blocks the entry.

Usage Notes

In typical Oracle EBS 12.1.1 and 12.2.2 deployments, PER_PERSON_ANALYSES_PKG is invoked implicitly from the HRMS Person/Assignment forms and the Person Special Information forms when an analysis or special-information record is created or updated. It is not exposed as a concurrent program, and ETRM lists no other packages that reference it (referenced by 0), which reinforces its role as an internal helper rather than a shared API surface.

Customizations should not call these routines directly. Where a duplicate check is required in custom code, the supported approach is to perform an equivalent query against PER_PERSON_ANALYSES or to route the insert through the supported HRMS person APIs, since the message raised by CHECK_FOR_DUPLICATES (HR_6012_ROW_INSERTED, message dictionary 801) relies on the form's message-handling stack. Because the package body header references a broken dual maintenance between this file and a view definition, patch-level changes to PER_SPECIAL_INFO_TYPES_V can affect INFO_EXISTS behavior; implementations should verify current flag values after applying HRMS patches or family packs. As with all APPS-owned package bodies, any modification invalidates support and should be avoided.