Search Results p_transaction_step_id




Overview

APPS.HR_PROCESS_CONTACT_SS is an Oracle E-Business Suite sealed PL/SQL package body that governs the maintenance of contact relationships attached to a person or assignment record within Oracle Human Resources and Oracle Payroll. In EBS terms, a "contact" is a person or organization linked to an employee or applicant — for example an emergency contact, a dependent, a beneficiary, a bondholder, or a third-party payee — and the relationship is stored in PER_CONTACT_RELATIONSHIPS with associated descriptive and attribute flexfield data. This package encapsulates the contact relationship lifecycle: it exposes validation, creation, update, and end-dating logic that is called from the Contact form and from HR contact-related business processes rather than executing its own user interface.

The "_SS" suffix indicates a supplemental "server-side" helper package used by the contact processing flow. It is the mid-tier engine that reads the contact form or transaction context, compares proposed values against the current database row, applies Row Who and object version checks, and finally delegates the persistent write to the public HR contact API. It therefore acts as an orchestration layer, shielding calling code from the complexity of direct DML against contact tables.

Key Procedures and Functions

The package exposes a broad API surface. Data-retrieval helpers include GET_CONTACT_RELATIONSHIP_TT, GET_CONTACT_FROM_TT, GET_CONTACT_REGIONS_STATUS_TT, and GET_EMRG_REL_ID, which return contact rows and emergency-relationship identifiers for the caller, often as table-of-type (TT) collections. Change-detection routines IS_REC_CHANGED, IS_CON_REC_CHANGED, and IS_CONTACT_ADDED compare incoming attribute values against the stored row to decide whether a database write is required. IS_ADDRESS_UPDATED and UPDATE_OBJECT_VERSION support address changes and optimistic locking of the object version number.

The core transactional procedures are CREATE_CONTACT_TT, UPDATE_CONTACT_RELATIONSHIP, END_CONTACT_RELATIONSHIP, and DELETE_TRANSACTION_STEPS, which stage, update, end-date, or clear pending contact data. PROCESS_CREATE_CONTACT_API, PROCESS_API, PROCESS_END_API, and CALL_CONTACT_API perform the actual submission to the contact API layer. Supporting validation routines include CHECK_NI_UNIQUE, VALIDATE_REL_START_DATE, SAVE_FOR_LATER_VALIDATION, and UPDATE_CONTACT_RELATIONSHIP. Collectively, these 24 documented program units cover the create, update, validate, defer, and terminate paths of a contact relationship.

Tables Accessed

The package reads and writes PER_CONTACT_RELATIONSHIPS, the primary contact relationship entity, and references PER_ALL_PEOPLE_F for the person or contact person, PER_ALL_ASSIGNMENTS_F and PER_PERIODS_OF_SERVICE for employment context, PER_ADDRESSES for contact addresses, and HR_COMMENTS for free-text comments. BEN_LER_F supplies benefit life-event reason references used in start and end reasons, while the HR_API_TRANSACTION_STEPS and HR_API_TRANSACTION_VALUES tables hold the transaction step and value rows consumed by the API processing model — these are the tables reached through the p_transaction_step_id parameter referenced in the seeded cursor and delete logic. WF_ACTIVITY_ATTR_VALUES supports workflow integration, and PLITBLM provides the PL/SQL table lookup buffer used by HR table-handler APIs.

Usage Notes

HR_PROCESS_CONTACT_SS is typically invoked from the Contact and Personal Information forms, and from HR business processes that must validate and persist contact relationships using the transactional API framework. Because it participates in the HR API transaction step model, callers pass a transaction step identifier so that values can be staged and validated before the contact API is called. Custom code should call the supported public contact API rather than calling this package's internal routines directly; the package is documented as referenced by two other packages, confirming its role as a shared internal dependency. Relevant in EBS 12.1.1 and 12.2.2, where the same contact processing behavior applies.