Search Results ra_hcustomers




Overview
Explore in AI Chat

Overview

RA_HCUSTOMERS is a Receivables (AR) dictionary view that exposes customer information by joining the Receivables customer account layer (HZ_CUST_ACCOUNTS, aliased CUST_ACCT) to the Trading Community Architecture party layer (HZ_PARTIES, aliased PARTY). The name retains the legacy "RA_" prefix from the original Receivables customer model, and the view acts as a flattened, denormalized projection that presents party attributes and customer account attributes side by side in a single row per customer account. Its described purpose in the ETRM documentation is simply "Customer information."

The view played a significant role in Oracle EBS Releases 11i and early 12.x as a compatibility and reporting layer over the older RA_CUSTOMERS structure, allowing forms, reports, and third-party integrations written against the legacy customer schema to continue functioning after the introduction of the HZ_ (Trading Community) data model. In 12.1.1 and 12.2.2, Receivables and other modules generally favor the HZ_CUST_ACCOUNTS and HZ_PARTIES base tables directly, but RA_HCUSTOMERS remains available for query and for legacy report definitions.

Underlying Base Objects

The ETRM metadata lists no explicitly documented referenced base objects, and implementation status is recorded as "Not implemented in this database" for the tracked instance. The view text, however, is unambiguous about its sources: it selects from HZ_CUST_ACCOUNTS (CUST_ACCT) joined to HZ_PARTIES (PARTY), with the join driven by the party_id relationship between the two. The CUST_ACCT.ROWID is carried through as the first column, characteristic of a view intended to support Oracle Forms-based updates or row identification against the customer account entity.

Several columns are synthesized rather than directly stored. A literal 'CUSTOMER' string is projected in place of a former customer-type indicator, and multiple NULL placeholders are retained for attributes that were retired with the migration away from RA_CUSTOMERS, including CUSTOMER_GROUP_CODE, CUSTOMER_SUBGROUP_CODE, and NET_WORTH. Organization-specific party attributes are conditionally surfaced through DECODE on PARTY_TYPE, returning values only when the party is an ORGANIZATION and NULL for persons.

Key Columns

Common Use Cases and Queries

Typical uses include legacy customer master reports, reconciliation between RA_ and HZ_ based customer data, and integrations that must present a single flat customer row. A simple listing of active organizations illustrates the conditional column behavior:

  • SELECT customer_number, customer_name, party_number, status, tax_code FROM ra_hcustomers WHERE party_type = 'ORGANIZATION' AND status = 'A';
  • SELECT cust_account_id, party_id, customer_name, last_update_date FROM ra_hcustomers WHERE last_update_date >= SYSDATE - 1;
  • SELECT customer_number, employees_total, curr_fy_potential_revenue FROM ra_hcustomers WHERE party_type = 'ORGANIZATION';

For new development on 12.1.1 or 12.2.2, querying HZ_CUST_ACCOUNTS joined to HZ_PARTIES is the recommended approach; RA_HCUSTOMERS should be treated as a supported compatibility view rather than the primary integration point.