Results for “add_information20”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

HR_H2PI_ADDRESSES_V is a seeded Oracle E-Business Suite view owned by the APPS schema and shipped with the PER — Human Resources product family. It is a component of the Oracle HR-to-Oracle Payroll Interface (H2PI), a legacy integration layer that extracts Human Resources person and assignment data into a structure consumable by Oracle Payroll. The view presents the primary address records of employees who qualify for the H2PI employee extract, formatted for downstream payroll processing and third-party payroll feeds.

Because the view is a presentation layer rather than a table, it carries no storage of its own. Its status is VALID in both 12.1.1 and 12.2.2, and it is defined identically in the ETRM 12.2.2 documentation. The object is most commonly encountered by technical consultants troubleshooting H2PI extraction logic, address mapping, or the customizable ADDR_ATTRIBUTE flexible-flex columns such as ADDR_ATTRIBUTE1.

Underlying Base Objects

The view is defined over two documented base objects:

• PER_ADDRESSES (referenced as synonym PA) — the core HR address entity holding all address records for a person, including primary, mailing, and other address types.
• HR_H2PI_EMPLOYEES_V (referenced as PP) — the H2PI employee view that identifies which persons are in scope for the payroll interface.

The defining query is a join that restricts PER_ADDRESSES to rows where PRIMARY_FLAG = 'Y', and further filters to persons who exist in HR_H2PI_EMPLOYEES_V via an EXISTS correlated subquery on PERSON_ID. In other words, only the designated primary address of each in-scope H2PI employee is surfaced. This mirrors standard Oracle HR address semantics, where a person may hold many addresses but only one is flagged primary at a given point in time.

Key Columns

• PERSON_ID, ADDRESS_ID, BUSINESS_GROUP_ID — primary keys and business group discriminator linking the address to the person and enterprise.
• STYLE, ADDRESS_TYPE, DATE_FROM, DATE_TO — address style (e.g., US, global), classification, and effective dating window.
• ADDRESS_LINE1..3, TOWN_OR_CITY, REGION_1..3, POSTAL_CODE, COUNTRY — the standard address components used for tax, mailing, and payroll output.
• TELEPHONE_NUMBER_1..3 — contact numbers carried alongside the address record.
• ADD_INFORMATION13..20 — additional descriptive flexfield segments surfaced for H2PI consumption.
• ADDR_ATTRIBUTE_CATEGORY and ADDR_ATTRIBUTE1..20 — the address descriptive flexfield context and its 20 global attribute segments. ADDR_ATTRIBUTE1, the column in the user's query, is the first of these developer-controlled slots, frequently repurposed by implementers to store client-specific data such as a payroll location code or statutory identifier.
• LAST_UPDATE_DATE — audit column supporting incremental extraction.

Common Use Cases and Queries

Typical scenarios include verifying that a primary address exists for each payroll-bound employee, extracting current addresses for a third-party payroll file, and diagnosing why ADDR_ATTRIBUTE1 is null or populated unexpectedly on the payroll interface. Because flexfield segments are context-sensitive, retrieving ADDR_ATTRIBUTE1 should normally be paired with ADDR_ATTRIBUTE_CATEGORY.

Sample query returning the primary address and first flexfield segment for a given person:

• SELECT person_id, address_id, addr_attribute_category, addr_attribute1, address_line1, town_or_city, postal_code, country FROM apps.hr_h2pi_addresses_v WHERE person_id = :p_person_id;

Sample query listing all H2PI employees with a populated ADDR_ATTRIBUTE1:

• SELECT person_id, address_id, addr_attribute1 FROM apps.hr_h2pi_addresses_v WHERE addr_attribute1 IS NOT NULL ORDER BY person_id;

Because the view applies its own PRIMARY_FLAG and H2PI-employee filters, no additional restriction is required to isolate in-scope primary addresses. Queries against this view run with APPS privileges and are suitable for use in concurrent programs, BI Publisher data templates, and ad-hoc SQL*Plus or SQL Developer sessions.