Results for “ra_customers”

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

Overview

RA_CUSTOMERS is the master customer registry within the Oracle E-Business Suite Receivables (AR) module. Owned by the AR schema and documented as VALID in both release 12.1.1 and 12.2.2, it stores the core identification and defaulting attributes for every party with whom an organization conducts business—prospects, customers, and internal organizations alike. Practically every subledger transaction in Order Management, Receivables, Advanced Collections, Projects, and Shipping ultimately resolves to a row in this table. It is therefore one of the most heavily referenced objects in the entire EBS data model.

The customer record defined here is the header-level entity; addresses, contacts, and site-level usage information are stored in dependent tables such as RA_ADDRESSES_ALL and RA_SITE_USES_ALL. Many downstream processes—invoicing, dunning, statements, pricing, and credit checks—inherit their default behavior from the columns held on this hub. From a dimensional modeling perspective, the documented foreign-key topology suggests treating RA_CUSTOMERS as a hub in a Data Vault design: it carries the durable business key (CUSTOMER_ID) with relatively stable descriptive attributes, while transaction tables act as links and satellites around it.

Key Information Stored

The table exposes 117 documented columns. The most operationally significant are:

• CUSTOMER_ID — the surrogate primary key (RA_CUSTOMERS_PK) and the value propagated to virtually all dependent tables.
• CUSTOMER_NUMBER — the human-readable business identifier, uniquely enforced by RA_CUSTOMERS_UK1 / RA_CUSTOMERS_U3. This is the key most often exchanged with external systems.
• CUSTOMER_NAME, FIRST_NAME, LAST_NAME, PERSON_FLAG — party identification, distinguishing persons from organizations.
• CUSTOMER_TYPE, CUSTOMER_CLASS_CODE, CUSTOMER_CATEGORY_CODE, CUSTOMER_PROSPECT_CODE — classification used for reporting, pricing eligibility, and list segmentation.
• ORIG_SYSTEM and ORIG_SYSTEM_REFERENCE — the foreign key back to the source system; RA_CUSTOMERS_U2 enforces uniqueness on the reference, which is essential for TCA integration.
• STATUS — active/inactive indicator driving transaction eligibility.
• PAYMENT_TERM_ID, PRICE_LIST_ID, ORDER_TYPE_ID, PRIMARY_SALESREP_ID — defaulting attributes resolved against RA_TERMS_B, SO_PRICE_LISTS_B, SO_ORDER_TYPES_115_ALL, and RA_SALESREPS_ALL respectively.
• TAX_CODE, TAX_EXEMPT, TAX_EXEMPT_NUM — tax determination inputs used by E-Business Tax.
• DUNNING_SITE_USE_ID and STATEMENT_SITE_USE_ID — pointers into RA_SITE_USES_ALL defining which site receives collections correspondence and statements.
• GLOBAL_ATTRIBUTE_CATEGORY and the GLOBAL_ATTRIBUTE1–20 series — the standard EBS extension mechanism.

Note the distinction between the surrogate key (CUSTOMER_ID) and the alternate business keys enforced by unique indexes: CUSTOMER_NUMBER and ORIG_SYSTEM_REFERENCE. Either may serve as the stable join key in a warehouse, but CUSTOMER_ID remains the physical referential key across EBS.

Common Use Cases and Queries

Typical reporting and integration scenarios include customer master extracts, active customer counts by class, and identification of prospects for CRM campaigns. A common query pattern joins the customer hub to its profile extension:

• Master extraction: SELECT customer_id, customer_number, customer_name, status FROM ar.ra_customers WHERE status = 'A';
• Enriched reporting: SELECT c.customer_number, c.customer_name, p.collector_id FROM ar.ra_customers c JOIN ar.ar_customer_profiles p ON p.customer_id = c.customer_id;
• Site default resolution: SELECT c.customer_name, s.location FROM ar.ra_customers c JOIN ar.ra_site_uses_all s ON s.site_use_id = c.statement_site_use_id;
• External system reconciliation using ORIG_SYSTEM_REFERENCE to detect duplicate or orphaned records.
• Credit and collections analysis by joining to AR_CUSTOMER_PROFILE_AMOUNTS for credit limits.

DBA practitioners frequently use the table for sizing, index-rebuild validation, and impact analysis before running the Customer Merge program, which rewrites references to CUSTOMER_ID across dozens of dependent tables.

Related Objects

The relationship catalog identifies RA_CUSTOMERS as a hub referenced by an extensive network. The most consequential related objects are:

• RA_ADDRESSES_ALL and RA_SITE_USES_ALL — addresses and site-level usage; RA_SITE_USES_ALL is referenced by RA_CUSTOMERS via DUNNING_SITE_USE_ID and STATEMENT_SITE_USE_ID.
• AR_CUSTOMER_PROFILES and AR_CUSTOMER_PROFILE_AMOUNTS — credit, collector, and statement-cycle configuration keyed on CUSTOMER_ID.
• RA_CUSTOMER_RELATIONSHIPS_ALL — corporate hierarchies, referencing CUSTOMER_ID and RELATED_CUSTOMER_ID.
• SO_HEADERS_ALL and OE_HOLD_SOURCES_ALL — Order Management transactions and holds, joined on CUSTOMER_ID and HOLD_ENTITY_ID.
• RA_TERMS_B, SO_PRICE_LISTS_B, SO_ORDER_TYPES_115_ALL, and RA_SALESREPS_ALL — the lookup tables supplying the customer's default payment term, price list, order type, and salesperson.
• PA_PROJECT_CUSTOMERS and PA_AGREEMENTS_ALL — Projects integration through CUSTOMER_ID.
• RA_CUSTOMER_MERGE_HEADERS — records duplicate-merge activity, linking to CUSTOMER_ID via DUPLICATE_ID.

Collectively these dependencies confirm that RA_CUSTOMERS functions as the authoritative party hub for the Receivables subledger and the broader order-to-cash and CRM flows.