Results for “ra_addresses_all”

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

Overview

RA_ADDRESSES_ALL is the master table of customer address information in the Oracle Receivables (AR) module of Oracle E-Business Suite. It stores the physical and functional addresses associated with customer records, including bill-to, ship-to, and market-use designations, and serves as the address repository consumed across the entire EBS order-to-cash and lead-to-order lifecycle. The table is owned by the AR schema and is valid in both Oracle EBS 12.1.1 and 12.2.2. The _ALL suffix reflects the multi-organization architecture introduced with the trading community model: records are partitioned by ORG_ID, and the various _ALL synonyms and layer views expose the appropriate operating unit slice to each application.

Applying Data Vault modeling heuristics to the documented foreign-key structure, RA_ADDRESSES_ALL classifies as a hub. Its primary key, ADDRESS_ID, is a surrogate key referenced by a wide array of dependent and transactional tables, and the table carries descriptive attributes (address lines, flags, territory identifiers, and customer profiling columns) rather than being a pure junction or correlation row. A Data Vault design might therefore model ADDRESS_ID as the hub business key, with the address attributes placed in an accompanying satellite, and the relationships to RA_CUSTOMERS, RA_TERRITORIES, and AR_LOCATION_COMBINATIONS treated as links.

Key Information Stored

The table contains 97 documented columns. The most operationally significant are:

• ADDRESS_ID — Surrogate primary key defined by the unique index RA_ADDRESSES_U1 and constrained by RA_ADDRESSES_PK. This is the value other applications store as their address foreign key.
• CUSTOMER_ID — Foreign key to RA_CUSTOMERS, identifying the party that owns the address.
• ORG_ID — Operating unit identifier. Together with ORIG_SYSTEM_REFERENCE it forms the unique index RA_ADDRESSES_U2, a documented business-key candidate supporting multi-org access control.
• STATUS — Lifecycle status of the address record (for example active or inactive), governing whether the site is selectable in transactions.
• ADDRESS1 through ADDRESS4, CITY, STATE, PROVINCE, COUNTY, POSTAL_CODE, COUNTRY — The formatted and unformatted address components.
• TERRITORY_ID — Foreign key to RA_TERRITORIES, tying the address to a sales territory.
• SERVICE_TERRITORY_ID — Territory used for service coverage.
• LOCATION_ID — Foreign key to AR_LOCATION_COMBINATIONS, linking the customer address to the tax-determining location.
• BILL_TO_FLAG, SHIP_TO_FLAG, MARKET_FLAG — Usage indicators determining the business purpose of each site.
• ORIG_SYSTEM_REFERENCE — Identifier of the record in the source system from which the address was imported.
• TP_HEADER_ID — Trading-partner header reference, anchored by the unique index RA_ADDRESSES_U3.
• ATTRIBUTE1–ATTRIBUTE15 and GLOBAL_ATTRIBUTE1–20 — Descriptive flexfield and global descriptive flexfield storage.

Common Use Cases and Queries

Typical usage includes customer master reporting, address validation and deduplication, bill-to/ship-to assignment during order entry, tax location determination, and data migration reconciliation. A basic query joining addresses to customers and sites resembles the following:

SELECT a.ADDRESS_ID, a.CUSTOMER_ID, a.ADDRESS1, a.CITY, a.STATE, a.POSTAL_CODE, a.COUNTRY, su.SITE_USE_CODE FROM RA_ADDRESSES_ALL a, RA_SITE_USES_ALL su WHERE a.CUSTOMER_ID = :customer_id AND su.ADDRESS_ID = a.ADDRESS_ID AND a.STATUS = 'A';

Because RA_ADDRESSES_ALL is multi-org, reporting queries should constrain ORG_ID through the MO operating unit profile or the appropriate _ALL layer view. A common integration pattern resolves the address foreign key on RA_CUSTOMER_TRX_ALL.REMIT_TO_ADDRESS_ID back to the descriptive columns here, and another resolves SO_HEADERS_INTERFACE_ALL.SHIP_ADDRESS_ID or INVOICE_ADDRESS_ID during order import validation. Address cleansing exercises typically scan ADDRESS1, CITY, POSTAL_CODE, and COUNTRY for nulls or anomalies, while territory-realignment reporting joins TERRITORY_ID and SERVICE_TERRITORY_ID to RA_TERRITORIES.

Related Objects

The table participates in a broad network of documented foreign-key relationships:

• RA_CUSTOMERS — referenced via RA_ADDRESSES_ALL.CUSTOMER_ID; the owning party of each address.
• RA_TERRITORIES — referenced via TERRITORY_ID.
• AR_LOCATION_COMBINATIONS — referenced via LOCATION_ID, supplying tax-determining location detail.
• RA_SITE_USES_ALL — references ADDRESS_ID and stores the site-use codes (bill-to, ship-to) that qualify each address.
• RA_CUSTOMER_TRX_ALL — references REMIT_TO_ADDRESS_ID, tying transactions to remit-to addresses.
• RA_PHONES — references ADDRESS_ID, storing telephone numbers by address.
• SO_HEADERS_INTERFACE_ALL — references SHIP_ADDRESS_ID and INVOICE_ADDRESS_ID for order import validation.
• AS_LEADS_ALL and AS_SALESFORCE — reference ADDRESS_ID and PARTNER_ADDRESS_ID respectively for lead and sales-force address assignment.
• MTL_CUSTOMER_ITEMS and MTL_INTERCOMPANY_PARAMETERS — reference ADDRESS_ID in the inventory and intercompany flows.
• PA_PROJECT_CUSTOMERS, PA_DRAFT_INVOICES_ALL, PA_TASKS — reference bill-to and ship-to address columns for project billing.

Address creation and maintenance are ordinarily performed through the trading community APIs and the Customer Standard/Receivables forms rather than by direct DML, preserving the complex validation and primary-address rules enforced by the application layer.