Search Results per_kr_addresses




Overview
Explore in AI Chat

Overview

PER_KR_ADDRESSES is a Human Resources (PER) module table owned by the HR schema in Oracle E-Business Suite. Its documented description is simply "KR specific," indicating that it stores address data localized for South Korea (country code KR). The table functions as a reference and validation source for Korean postal addresses, capturing the hierarchical components used in that country's addressing conventions—such as province/city, district, town or village, house number, road name, and postal code. In Oracle EBS, this object supports the entry, validation, and reporting of employee and third-party addresses originating in Korea, ensuring that address data conforms to local postal structures rather than the generic free-form address model used elsewhere.

From a Data Vault modeling perspective, the documented metadata classifies this object as standalone (a heuristic derived from its foreign-key structure). This suggests modeling it as a standalone hub or reference table rather than as a link participating in extensive foreign-key relationships, since no dependent relationships were mined from the schema.

Key Information Stored

The surrogate primary key is POSTAL_CODE_ID, defined by the constraint PER_KR_ADDRESSES_PK. This identifier uniquely references each Korean address record. A second unique index, PER_KR_ADDRESSES_UK1, defines the business-key candidate composed of CITY_PROVINCE, DISTRICT, TOWN_VILLAGE#1, HOUSE_NUMBER, ROAD_NAME, LEGISLATIVE_DISTRICT, and PUBLIC_HOUSING_NAME—together these establish the natural uniqueness of an address.

The most significant columns include:

  • POSTAL_CODE_ID — surrogate primary key identifying the address record.
  • POSTAL_CODE — the Korean postal code value.
  • CITY_PROVINCE — the city or province component.
  • DISTRICT — the district within the city/province.
  • TOWN_VILLAGE#1 — the town or village designation.
  • HOUSE_NUMBER — the numeric house identifier.
  • ROAD_NAME — the road or street name.
  • LEGISLATIVE_DISTRICT — the legislative district designation.
  • PUBLIC_HOUSING_NAME — the name of a public housing complex, where applicable.
  • POSTAL_CODE_SEQUENCE — sequence ordering for postal code entries.
  • ENABLED_FLAG — indicates whether the address record is active.
  • REMARKS — free-text remarks.
  • Standard audit columns: CREATED_BY, CREATION_DATE, LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN.

In total the physical schema documents 17 columns.

Common Use Cases and Queries

Typical uses include validating Korean addresses during employee or applicant data entry, populating address-list-of-values (LOV) pickers, and generating localized reports. A query to retrieve all active Korean addresses for a given postal code would resemble:

  • SELECT postal_code, city_province, district, town_village#1, road_name FROM per_kr_addresses WHERE postal_code = :p_code AND enabled_flag = 'Y';
  • Lookups by business key: SELECT postal_code_id FROM per_kr_addresses WHERE city_province = :city AND district = :district AND house_number = :house;
  • Reporting on address coverage: SELECT city_province, COUNT(*) FROM per_kr_addresses GROUP BY city_province;

Because the table is standalone, reporting joins generally resolve through POSTAL_CODE_ID against employee or location address tables rather than through inbound foreign keys.

Related Objects

Given the standalone classification, direct foreign-key dependencies within this table are not documented. As a KR-specific reference object, it is most closely associated with the broader PER address framework, including generic address structures and the postal code validation logic used across HR and geography modules. The primary related elements are:

  • PER_KR_ADDRESSES_PK — the primary-key constraint on POSTAL_CODE_ID.
  • PER_KR_ADDRESSES_UK1 — the unique business-key constraint.
  • PER address and location tables that reference Korean addresses by postal code.
  • Geography/postal code validation objects that consume the KR address ranges.
  • HR employee and applicant address interfaces that supply or validate Korean address input.

Because the documented relationship data classifies this object as standalone, implementers should treat it as a self-contained reference table and confirm integration points against the specific ETRM version (12.1.1 or 12.2.2) in use.