Search Results identifying_flag

Overview

The APPS.HZ_CUSTOMER_PARTY_SITE_FIND_V view is a Receivables (AR) reporting object that presents a consolidated, user-facing picture of customers, their party records, and their associated addresses. It is a "find" view in the Oracle Trading Community Architecture (TCA) / Receivables family, designed to support customer search, lookup, and selection screens rather than transactional processing. The view returns one row per customer account and party site combination, enriched with descriptive location and territory information, so that applications and reports can present a single denormalized result set joining party, account, account site, party site, and location data.

In Oracle EBS 12.1.1 and 12.2.2 the object is owned by APPS and carries a VALID status. Its principal role is to serve as a read-only query source for forms, concurrent programs, and custom integrations that need to locate customers by name or address. Because it is a view, it inherits the TCA data model beneath it and is subject to the same multi-org and security considerations as the base tables.

Underlying Base Objects

The documented base objects referenced by the view are FND_TERRITORIES_TL, HZ_CUST_ACCOUNTS, HZ_CUST_ACCT_SITES, HZ_LOCATIONS, HZ_PARTIES, and HZ_PARTY_SITES, all accessed through APPS synonyms. The view text defines a UNION of two branches. The first branch joins HZ_CUST_ACCOUNTS to HZ_PARTIES on PARTY_ID, to HZ_CUST_ACCT_SITES on CUST_ACCOUNT_ID, to HZ_PARTY_SITES on PARTY_SITE_ID, and to HZ_LOCATIONS on LOCATION_ID, with FND_TERRITORIES_TL supplying the translated country description. The second branch returns party-level rows (where no customer account exists) using an outer join to FND_TERRITORIES_TL and a literal customer identifier of -1.

Territory translation is filtered by USERENV('LANG') so that the country description matches the session language. This dependency on FND_TERRITORIES_TL means the view is sensitive to language settings and can return different country descriptions across sessions.

Key Columns

The view exposes a broad set of customer, party, and address attributes. Notable columns include CUST_ACCOUNT_ID, PARTY_ID, CUST_ACCT_SITE_ID, PARTY_SITE_NUMBER, and ADDRESS_KEY, which serve as the primary join and surrogate keys. Descriptive columns include PARTY_NAME, PERSON_FIRST_NAME, PERSON_LAST_NAME, ACCOUNT_NUMBER, and ACCOUNT_NAME.

Address columns include ADDRESS1 through ADDRESS4, CITY, STATE, POSTAL_CODE, COUNTY, PROVINCE, COUNTRY (the translated territory description), and COUNTRY_CODE. Customer-attribute columns include STATUS, CUSTOMER_TYPE, CUSTOMER_CLASS_CODE, CATEGORY_CODE, SIC_CODE, TAX_REFERENCE, TAXPAYER_ID (mapped from JGZZ_FISCAL_CODE), and ORIG_SYSTEM_REFERENCE. Regarding the IDENTIFYING_ADDRESS_FLAG column central to the search, it is sourced from HZ_PARTY_SITES.IDENTIFYING_ADDRESS_FLAG in the customer-account branch and is hard-coded to 'Y' in the party-only branch. This flag indicates whether a party site is the identifying address for the party, which is essential for presenting a single canonical address per customer in search results.

Common Use Cases and Queries

Typical uses include customer lookup screens, duplicate-customer analysis, and integration extracts that require a flattened customer-and-address record. A common pattern is to filter on the identifying address flag to return one address per party:

• Customer search by name and number: SELECT CUST_ACCOUNT_ID, PARTY_NAME, ACCOUNT_NUMBER FROM HZ_CUSTOMER_PARTY_SITE_FIND_V WHERE UPPER(PARTY_NAME) LIKE 'ACME%';
• Identifying address resolution: SELECT PARTY_ID, ADDRESS1, CITY, STATE, COUNTRY FROM HZ_CUSTOMER_PARTY_SITE_FIND_V WHERE IDENTIFYING_ADDRESS_FLAG = 'Y';
• Country-filtered extracts: SELECT ACCOUNT_NUMBER, PARTY_NAME, COUNTRY FROM HZ_CUSTOMER_PARTY_SITE_FIND_V WHERE COUNTRY_CODE = 'US';

Because the view is a UNION and exposes no ROWID, it should be treated as read-only. Queries that return large result sets benefit from filtering on CUST_ACCOUNT_ID, PARTY_ID, or ACCOUNT_NUMBER to leverage the underlying indexes on the base tables.