Search Results create_citizenship

Overview

APPS.HZ_PERSON_INFO_V2PUB is a public PL/SQL API package in the Oracle E-Business Suite Trading Community Architecture (TCA) or "Customer" data model. It is the second-generation ("V2") person information API whose role is to maintain the descriptive, non-party-record attributes associated with a person party. Where the core HZ_PARTY_V2PUB package governs the person record itself (name, party type, party number, and so on), HZ_PERSON_INFO_V2PUB governs the subordinate "person information" child entities: languages spoken, citizenships held, education, employment history, work classifications, and personal interests.

The package header was authored in 2005 (ARH2PISB.pls, version 120.12) and the object is classified as PUB, meaning Oracle supports direct invocation by external callers. It is owned by the APPS schema and is referenced by eleven other packages, reflecting its position as a shared dependency in the TCA person data model. In EBS 12.1.1 and 12.2.2 the package is available and carries the same public API surface.

Key Procedures and Functions

The documented public API exposes eighteen entities grouped as create, update, and retrieve operations across six person information sub-types. Each create operation inserts a new child row and returns the new primary key identifier for the created record; each update operation modifies an existing row and manages the object version number for optimistic locking; each get operation retrieves a record into the caller-supplied record structure.

• CREATE_PERSON_LANGUAGE / UPDATE_PERSON_LANGUAGE / GET_PERSON_LANGUAGE_REC — maintain the languages associated with a person, including the usage reference used to classify the language relationship.
• CREATE_CITIZENSHIP / UPDATE_CITIZENSHIP / GET_CITIZENSHIP_REC — maintain citizenship records for the person, including the country of citizenship.
• CREATE_EDUCATION / UPDATE_EDUCATION / GET_EDUCATION_REC — maintain educational background entries such as institution, degree, and dates.
• CREATE_EMPLOYMENT_HISTORY / UPDATE_EMPLOYMENT_HISTORY / GET_EMPLOYMENT_HISTORY_REC — maintain prior and current employment records, including employer, position, and date ranges.
• CREATE_WORK_CLASS / UPDATE_WORK_CLASS / GET_WORK_CLASS_REC — the operations relevant to a search on create_work_class. These maintain the person's work class, that is, the classification of their occupation or job category, held against the person party.
• CREATE_PERSON_INTEREST / UPDATE_PERSON_INTEREST / GET_PERSON_INTEREST_REC — maintain general interests recorded for the person.

Internally the package implements private worker procedures with a "do_" prefix (for example do_create_person_language, do_update_citizenship, do_create_work_class), which perform the actual validation and DML on behalf of the public wrappers. Parameters are passed as NOCOPY record types.

Tables Accessed

The package reads and writes the following base tables through APPS synonyms, one per information sub-type plus the party anchor:

• HZ_PERSON_LANGUAGE — language records for the party.
• HZ_CITIZENSHIP — citizenship records for the party.
• HZ_EDUCATION — education entries.
• HZ_EMPLOYMENT_HISTORY — employment history entries.
• HZ_WORK_CLASS — work class entries created and maintained by CREATE_WORK_CLASS, UPDATE_WORK_CLASS, and GET_WORK_CLASS_REC.
• HZ_PERSON_INTEREST — interest records.
• HZ_PARTIES — the master person party row, referenced to validate the party identifier and attach each child record to the correct person.

Usage Notes

The package is a programmatic API; it is not a concurrent program and has no report or form of its own. It is invoked from the Oracle Forms-based Trading Community and Customer Standard user interfaces, from other TCA packages (hence the eleven documented references), and from custom PL/SQL when a caller must insert person information attribute rows that the party API does not itself handle. The canonical pattern is to call HZ_PARTY_V2PUB.CREATE_PERSON to obtain a party identifier, then call the relevant create routine in this package, passing that party identifier and a record built for the corresponding REC_TYPE. Callers must initialize the record's x_return_status and inspect the returned status and message list after every call, as the API follows the standard TCA error-handling convention rather than raising unhandled exceptions. Updates require the current object version number, and the API enforces the TCA naming, validation, and multi-lingual conventions. Where a view or a later replacement API exists, Oracle recommends using the V2 API as this is the supported public interface for person information maintenance.