Search Results check_default

Overview

APPS.PER_PERSON_TYPES_PKG is the Oracle E-Business Suite PL/SQL package that encapsulates the core data‑maintenance logic for the Person Type entity within Oracle HRMS. A person type classifies individuals tracked in the HRMS person model — examples include Employee, Applicant, Contingent Worker, and Ex‑Employee — and controls both the display label seen by users and the internal system name against which application logic validates. The package is the procedural counterpart to the PERWSDPT form (Define Person Type), and it centralizes the validation and persistence rules needed to keep person type definitions consistent across business groups.

Authored with AUTHID CURRENT_USER semantics, the package has been maintained since the mid‑1990s, as reflected in its header comments. Of particular relevance to the term "check_default", the CHECK_DEFAULT procedure was added in November 2000 to address Bug 1494778, and the related CHECK_DUPLICATE_SYSTEM_NAME procedure (added in 1996 for Bug 338753) enforces the rule that a user may not define two person types with the same system name where a default of "Yes" is requested. Together these routines ensure that exactly one person type per business group can assume the default role for a given system name.

Key Procedures and Functions

The package exposes fourteen documented procedures, spanning validation, DML, and translation utilities:

• CHECK_DEFAULT — validates the default flag entered for a person type, ensuring defaulting rules are respected. This is the routine most directly associated with the "check_default" search term.
• CHECK_DUPLICATE_NAME — verifies the user‑person‑type display name does not violate uniqueness constraints.
• CHECK_DUPLICATE_SYSTEM_NAME — ensures a user does not set the default flag to "Yes" while entering a duplicate system name.
• INSERT_ROW — inserts a new person type record, including the ID, business group, active and default flags, and system/user type names.
• LOCK_ROW — provides pessimistic locking of a person type row to prevent concurrent modification.
• UPDATE_ROW — updates an existing person type definition.
• DELETE_ROW — removes a person type row.
• CHECK_DELETE — validates whether a person type may be deleted given its existing usages.
• CHECK_SYSTEM_DELETE — performs equivalent validation for system‑seeded person types.
• LOAD_ROW — loads person type data during moves and installations.
• TRANSLATE_ROW — loads translated (MLS) person type data.
• ADD_LANGUAGE — adds a new language row for multi‑language support.
• SET_TRANSLATION_GLOBALS — establishes context settings required for translation processing.
• VALIDATE_TRANSLATION — validates translation rows before persistence.

Tables Accessed

The package reads and writes the following tables via APPS synonyms:

• PER_PERSON_TYPES / PER_PERSON_TYPES_S — the base and date‑tracked (or MLS surrogate) definition tables where person type rows are inserted, updated, locked, and deleted.
• PER_PERSON_TYPES_TL — the translated table holding language‑specific display names; accessed by ADD_LANGUAGE, LOAD_ROW, TRANSLATE_ROW, and the translation validation routines.
• PER_PERSON_TYPE_USAGES_F — the usage fact table consulted by CHECK_DELETE to determine whether a person type is referenced and therefore cannot be removed.
• HR_ALL_ORGANIZATION_UNITS — the organization/ business group hierarchy, supplying business‑group context for validations.
• FND_LANGUAGES — the languages registry used by the multilingual support routines.
• DUAL — used for lightweight existence and flag checks.

Usage Notes

PER_PERSON_TYPES_PKG is typically invoked from the Define Person Type form (PERWSDPT), where the CHECK_* routines fire during field validation and the DML procedures execute on save, update, and delete. Translation‑related procedures are called through the standard Oracle MLS loading infrastructure and by the LOAD_ROW/TRANSLATE_ROW mechanism used during seed data installation, patching, and environment migration. The package is not documented as being referenced by other PL/SQL packages (referenced by 0 other packages), so customer extensions should treat it as an internal supporting API rather than a formally published integration point. Custom code that creates or maintains person types outside the standard form should call the validation procedures before the DML procedures to preserve the same integrity guarantees the form enforces.