Search Results hr_kiosk_address_api




Overview

APPS.HR_KIOSK_ADDRESS_API is a public PL/SQL API belonging to the Oracle E-Business Suite Human Resources (HR) product family. In the 12.1.1 and 12.2.2 releases it provides the server-side logic used by self-service and kiosk-style interfaces to create and maintain person addresses held in the PER_ADDRESSES table. The package is classified as an API in the ETRM repository and is owned by the APPS schema, which indicates it is intended for supported external invocation rather than internal-only use. Its principal business function is to encapsulate the validation, date-effectivity handling, and row-level maintenance of address records so that calling applications do not write directly to the underlying HR tables.

The package body declares the standard package-global variable used for error and message tracing, and its header comment identifies the source file as pekadapi.pkb (version 120.1, dated 2011/11/15). The procedures accept a broad set of address attributes — style, address type, effective dates, primary flag, up to three address lines, town or city, region lines, postal code, country, three telephone numbers, and a set of descriptive flexfield attributes — together with important business keys such as person identifier and effective date.

Key Procedures and Functions

The ETRM metadata documents six procedures in this package, divided evenly between creation and update operations, with country-specific variants for the United States and Great Britain:

  • CREATE_PERSON_ADDRESS — the generic creation routine; inserts a new dated address for a person, applying the standard address style and effectivity rules.
  • CREATE_US_PERSON_ADDRESS — a United States-specific creation routine that applies US address formatting and validation conventions.
  • CREATE_GB_PERSON_ADDRESS — a Great Britain-specific creation routine applying UK address conventions, including the postal code structure used in that territory.
  • UPDATE_PERSON_ADDRESS — the generic update routine; modifies an existing person address record while preserving date-effectivity history.
  • UPDATE_US_PERSON_ADDRESS — the United States-specific update variant.
  • UPDATE_GB_PERSON_ADDRESS — the Great Britain-specific update variant.

All six operate on the person address entity and return or propagate errors through the standard HR API exception mechanisms. Each variant respects the p_validate parameter convention, allowing a caller to perform a dry run without committing data.

Tables Accessed

The only documented table accessed through APPS synonyms is PER_ADDRESSES, the base table in which all person address records for Oracle HRMS are stored. Creation procedures insert new rows into this table, while update procedures modify existing rows, including the effective start and end dates that give the table its dated, history-tracked nature. Address style, primary flag, telephone details, and descriptive flexfield columns are all persisted to this table. No other tables are listed in the documented metadata, and the package is referenced by zero other packages, confirming it is a leaf-level API consumed by external callers rather than by other PL/SQL units.

Usage Notes

HR_KIOSK_ADDRESS_API is typically invoked from self-service or kiosk-style forms and from custom PL/SQL code that needs to maintain employee or applicant addresses without direct DML against PER_ADDRESSES. Because it is a public API, it should be preferred over direct table manipulation to ensure business rules, validation, and date-effectivity handling remain intact. Callers should supply a valid effective date and person identifier, choose the generic procedure unless territory-specific formatting is required, and use p_validate to test input before committing. When the search context involves a user or address value such as "domakosita a at," the relevant entry point is the create or update procedure matched to the person and country concerned.