Search Results customer_address1




Overview
Explore in AI Chat

Overview

APPS.OKL_AM_PARTIES_UV is a read-only Oracle EBS database view that exposes a denormalized, customer-oriented projection of party and address information sourced from the Oracle Trading Community Architecture (TCA) registry. It is documented under the ETRM metadata set for Oracle EBS 12.1.1 and 12.2.2 as an APPS-owned object. The view presents a distinct list of individuals or organizations that participate as "customer" parties, together with their address, city, state, postal code, and country attributes. Because the columns are aliased with the CUSTOMER_ prefix (for example, CUSTOMER_ADDRESS1, CUSTOMER_PARTY_NAME), the view is designed to be consumed by reporting and integration logic that needs a flattened customer-party record without issuing multi-table joins against HZ_PARTIES and HZ_RELATIONSHIPS directly.

The view is particularly relevant to the user search term "customer_address1," which maps directly to the CUSTOMER_ADDRESS1 column exposed by the view (derived from HZ_PARTIES.ADDRESS1).

Underlying Base Objects

The view is defined over exactly two TCA base objects, both referenced through APPS synonyms:

  • HZ_PARTIES (SYNONYM) — the TCA party master table, aliased as HZPO in the view text, supplying party name, party type, party ID, and the address columns.
  • HZ_RELATIONSHIPS (SYNONYM) — the TCA relationship table, aliased as HZPR, which supplies the relationship context used to filter the party set.

The join is expressed as HZPR.OBJECT_ID = HZPO.PARTY_ID, with predicates restricting the result to active, effective, forward-directional relationships. This means a party appears only when a qualifying relationship row exists in HZ_RELATIONSHIPS; HZ_PARTIES alone is not sufficient.

Key Columns

Common Use Cases and Queries

The view is typically used to populate reports, BI Publisher data templates, or interface extracts requiring a current customer address. A representative query retrieving address and name by party ID:

SELECT CUSTOMER_PARTY_ID,
       CUSTOMER_PARTY_NAME,
       CUSTOMER_ADDRESS1,
       CUSTOMER_ADDRESS2,
       CUSTOMER_CITY,
       CUSTOMER_STATE,
       CUSTOMER_POSTAL_CODE,
       CUSTOMER_COUNTRY
FROM   APPS.OKL_AM_PARTIES_UV
WHERE  CUSTOMER_ADDRESS1 IS NOT NULL
ORDER  BY CUSTOMER_PARTY_NAME;

Typical scenarios include validating that a party has a populated primary address line before invoicing or correspondence, feeding address data into a lease or contract output, and reconciling customer identity across TCA. Because the definition applies DISTINCT, consumers should expect de-duplicated rows even when multiple qualifying relationship records exist. The effective-dating predicates (START_DATE <= SYSDATE and NVL(END_DATE, SYSDATE) >= SYSDATE) mean results reflect only currently valid relationships, so the view should be re-queried rather than cached for point-in-time accuracy.