Results for “sic_code”

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

Overview

AR_CUSTOMER_FIND_V is a denormalized reporting view owned by the APPS schema in Oracle E-Business Suite Release 12.1.1 and 12.2.2. It is part of the Oracle Receivables (AR) product and is designed to present a consolidated, flattened representation of customer account data drawn from the Oracle Trading Community Architecture (TCA) model. The view joins customer accounts, parties, party sites, account sites, locations, territories, and lookup code translations into a single row per customer account and site combination, allowing consumers to retrieve customer identification, address, classification, and contact attributes without writing complex multi-table joins.

Its primary role is to support ad hoc reporting, custom concurrent programs, forms-based customer search logic, and downstream integration extracts. Because it resolves foreign keys into descriptive values — for example, mapping lookup codes to their translated meanings — it is well suited to environments where business users or external systems require human-readable customer attributes rather than raw code values.

Underlying Base Objects

The view is defined over the following documented base objects, referenced through synonyms or views in the APPS schema:

• HZ_CUST_ACCOUNTS (CA) — the customer account master record.
• HZ_PARTIES (HP) — party name, number, tax reference, fiscal code, SIC code, and category code.
• HZ_CUST_ACCT_SITES_ALL (HCS) — account site assignments.
• HZ_PARTY_SITES (HPS) — party site records linking parties to locations.
• HZ_LOCATIONS (HL) — address components.
• FND_TERRITORIES_VL (TER) — country description derived from the territory code.
• AR_LOOKUPS (L_TYPE, L_CAT, L_CLASS) — three aliased instances supplying meaning text for customer type, category, and class lookups.

All joins to the site, location, territory, and lookup tables use outer joins (+), so a customer account is still returned even when site, address, or lookup information is absent. The inner joins are limited to HZ_CUST_ACCOUNTS to HZ_PARTIES, which guarantees a valid party for each account row.

Key Columns

The view exposes descriptive aliases rather than raw schema column names. The most significant include:

• CUSTOMER_ID — the underlying CUST_ACCOUNT_ID, the account's primary identifier.
• CUSTOMER_NAME, FIRST_NAME, LAST_NAME — party name and person name components from HZ_PARTIES.
• CUSTOMER_NUMBER — the ACCOUNT_NUMBER assigned to the account.
• ADDRESS1 through ADDRESS4, CITY, STATE, POSTAL_CODE, COUNTY, PROVINCE — address attributes from HZ_LOCATIONS.
• COUNTRY and COUNTRY_CODE — the territory description and the raw territory code.
• STATUS — account status.
• TAX_REG_NUMBER (TAX_REFERENCE) and TAXPAYER_ID (JGZZ_FISCAL_CODE) — tax registration attributes.
• TYPE, CATEGORY, and CLASS — translated meanings for customer type, customer category, and customer class, resolving values such as the CUSTOMER_CATEGORY lookup used by the CATEGORY column.
• SIC_CODE, PARTY_SITE_NUMBER, CUSTOMER_KEY, ADDRESS_KEY, ADDRESS_ID, PARTY_ID — identification and cross-reference keys used in integration and API calls.

Common Use Cases and Queries

Typical scenarios include customer master extracts, duplicate-detection reports, address validation, and interface staging for external CRM or billing systems. A common query filters by customer category using the resolved lookup meaning:

• SELECT cust_account_id, party_name, account_number, city, country FROM ar_customer_find_v WHERE category = :p_category;
• SELECT customer_id, customer_name, customer_number, category FROM ar_customer_find_v WHERE customer_number = :p_number;
• SELECT customer_name, address1, city, state, postal_code, country FROM ar_customer_find_v WHERE tax_reference = :p_tax_ref;

Because the view returns a row per account site, callers requiring one row per account should aggregate or filter on party_site_number. In Oracle EBS 12.1.1 and 12.2.2 the underlying TCA objects are unchanged, so the view behaves consistently across both releases.