Search Results update_sit

Overview

HR_SIT_API is a public PL/SQL package owned by the APPS schema that provides the supported programmatic interface for maintaining "Special Information Types" (SIT) records against a person in Oracle E-Business Suite Human Resources. A Special Information Type, defined in the PER_SPECIAL_INFO_TYPES table, allows an installation to capture user-defined, flexfield-based data about an employee or applicant — for example, professional memberships, security clearances, or language proficiencies — beyond the standard person attributes delivered by the product. HR_SIT_API encapsulates the validation, key-flex derivation, date-tracked insert, update, and delete logic required to create, amend, or remove those records safely, so that concurrent programs, forms, and custom extensions do not manipulate the underlying PER_PERSON_ANALYSES table directly.

The package is classified as an API in the ETRM repository for both EBS 12.1.1 and 12.2.2. The header of the package body (pesitapi.pkb 120.2.12010000.2) is unchanged across these releases, indicating a stable interface through the 12.x line. It is referenced by seven other packages, confirming it is a dependency of higher-level HR datapump or person-maintenance APIs rather than an isolated utility.

Key Procedures and Functions

The documented interface exposes four entry points:

• CREATE_SIT — Inserts a new Special Information Type record for a person. It accepts a global validation flag (p_validate), the person and business group identifiers, the key flexfield structure number for the SIT, an effective date, comments, and the date-from / date-to range that makes the record date-tracked. It also accepts request and program audit columns and twenty generic descriptive flexfield attribute columns, followed by the SIT key segments that identify the particular information type. When p_validate is true, all business rules run but no row is committed.
• UPDATE_SIT — Amends an existing Special Information Type record. This is the procedure most commonly sought by developers searching for "update_sit". It applies the same validation and key-flex processing as CREATE_SIT to an already-existing row, supporting changes to dates, comments, flexfield attributes, and segments while preserving the audit columns and date-track integrity of the person's SIT history.
• DELETE_SIT — Removes an existing SIT record, again honouring the validation flag so callers can perform a trial run before committing the deletion.
• LCK — A locking routine used to obtain a row-level lock on the target SIT record. It is invoked internally by UPDATE_SIT and DELETE_SIT to serialise concurrent modifications against the same person/analysis row and prevent lost updates.

Tables Accessed

The package operates against four APPS synonyms:

• PER_PERSON_ANALYSES — The primary transactional table. Each Special Information Type occurrence is stored as an analysis row linked to a person and an analysis criteria; INSERT, UPDATE, and DELETE operations all target this table.
• PER_ANALYSIS_CRITERIA — Defines the analysis criteria that back each Special Information Type, supplying the validation rules and flexfield binding used when a record is created or changed.
• PER_SPECIAL_INFO_TYPES — Holds the SIT definition itself, including the associated key flexfield structure, and is read to confirm that the supplied information type is valid and correctly configured.
• FND_ID_FLEX_STRUCTURES — The key flexfield structure repository. It is queried to resolve the p_id_flex_num structure and to drive key-flex segment validation for the SIT segments passed into CREATE_SIT and UPDATE_SIT.

Usage Notes

HR_SIT_API is intended for use from PL/SQL only — Oracle does not document it as a form-level or concurrent-program entry point. Typical invocations come from the Person Extra Information form, HR datapump routines, and custom conversion or interface scripts that load legacy special information data into PER_PERSON_ANALYSES. The seven dependent packages further indicate use within Oracle's own HR person-maintenance stack.

Callers should observe the following conventions. Always run the procedure first with p_validate => TRUE, inspect the returned status, and only then re-invoke with p_validate => FALSE to commit. Supply a meaningful p_effective_date and the correct business group, since both are used in flexfield and date-track validation. Populate the p_program_application_id, p_program_id, p_request_id, and p_program_update_date audit columns so the resulting rows are traceable to their originating process. Because the package writes to a date-tracked table, updates that change the effective range should be performed through UPDATE_SIT rather than by direct DML, preserving the integrity of SIT history and the row locks enforced by LCK.