Search Results hz_person_language_u1




Overview

The AR.HZ_PERSON_LANGUAGE table is a core component of the Oracle E-Business Suite Trading Community Architecture (TCA) model, residing in the AR schema. It stores information about languages spoken by a party of the Person type, and it also supports other party types where language capability is tracked. Each row represents a single language associated with a party, meaning that a person who speaks multiple languages will have multiple records — one per language. The table captures not only whether a language is spoken, but the declared native language, the primary day-to-day language, and user-defined proficiency levels for reading, speaking, and writing.

In Oracle EBS 12.1.1 and 12.2.2, this object is registered as VALID in the ETRM (E-Business Suite Tables and Relationships Model), with FND Design Data AR.HZ_PERSON_LANGUAGE. It resides in the APPS_TS_TX_DATA tablespace with a PCT Free of 10. Based on the foreign key structure — referencing HZ_PARTIES and FND_LANGUAGES — a heuristic Data Vault classification suggests this object behaves as a link table, connecting a party entity to a language reference entity with descriptive attributes carried alongside. This classification is a modeling suggestion derived from the FK topology, not a documented EBS designation.

Key Information Stored

The table is defined with 23 documented columns. The most significant include:

Standard WHO and audit columns — LAST_UPDATE_DATE, LAST_UPDATED_BY, CREATION_DATE, CREATED_BY, LAST_UPDATE_LOGIN, and the concurrent program columns REQUEST_ID, PROGRAM_APPLICATION_ID, PROGRAM_ID, PROGRAM_UPDATE_DATE — are also present. The unique index HZ_PERSON_LANGUAGE_U1 on LANGUAGE_USE_REFERENCE_ID serves as the business-key candidate, while the non-unique index HZ_PERSON_LANGUAGE_N1 on PARTY_ID supports lookups by party.

Common Use Cases and Queries

The primary use case is retrieving the languages and proficiency details associated with a person or party. Because PARTY_ID is indexed by HZ_PERSON_LANGUAGE_N1, party-centric queries perform efficiently. A typical reporting query joins to HZ_PARTIES to resolve party identity:

  • List all languages for a party: SELECT language_name, native_language, primary_language_indicator FROM hz_person_language WHERE party_id = :party_id;
  • Identify primary or native speakers: filter on PRIMARY_LANGUAGE_INDICATOR = 'Y' or NATIVE_LANGUAGE = 'Y'.
  • Proficiency reporting: aggregate on READS_LEVEL, SPEAKS_LEVEL, WRITES_LEVEL, and SPOKEN_COMPREHENSION_LEVEL for skills-gap or resource analyses.
  • Validate languages against the reference list: join LANGUAGE_NAME to FND_LANGUAGES.

These patterns support customer profiling, HR competency reporting, and localization-driven communications.

Related Objects

The most significant objects related to this table through the documented FK relationships are:

  • HZ_PARTIES — joined via HZ_PERSON_LANGUAGE.PARTY_ID = HZ_PARTIES.PARTY_ID; the master party record.
  • FND_LANGUAGES — joined via HZ_PERSON_LANGUAGE.LANGUAGE_NAME = FND_LANGUAGES.LANGUAGE_CODE (or the corresponding language column); the language reference source.
  • HZ_PERSON_PROFILES — the person profile entity that extends party demographics and may correlate with language records.
  • Other TCA location, contact, and relationship entities keyed by PARTY_ID — including HZ_LOCATIONS and HZ_CONTACT_POINTS — that commonly participate alongside this table in party-level reporting.

Because the table is exposed as part of the TCA data model, it is typically accessed through the public TCA APIs (such as the party and person maintenance APIs) rather than through direct DML, ensuring the surrogate key and audit columns are populated correctly.