Search Results ra_addresses




Overview
Explore in AI Chat

Overview

RA_ADDRESSES is a Receivables (AR) module view that exposes customer address and party site information in a denormalized form. It consolidates data drawn from the Oracle Trading Community Architecture (TCA) model — principally customer accounts, party sites, and location records — into a single reporting surface tailored to Oracle Receivables. The view presents both general-purpose address attributes (address lines, city, state, postal code, country) and Receivables-specific business attributes such as business purpose flags (BILL_TO_FLAG, SHIP_TO_FLAG, MARKET_FLAG), territory assignments, specialist assignments, customer classification codes, and financial profiling fields.

In the context of Oracle EBS 12.1.1 and 12.2.2, RA_ADDRESSES serves as a convenience layer for reporting, integration, and custom development. It allows developers and analysts to retrieve a customer's addresses together with related customer attributes without writing complex multi-table joins across the TCA schema. Because the view spans both address-level and customer-level data, it is particularly useful in extracts, custom concurrent programs, and third-party integrations that need a flat, single-row-per-address result set.

Underlying Base Objects

The ETRM metadata classifies RA_ADDRESSES as "Not implemented in this database," which indicates that the view is a documented, seeded database object whose exact base-table composition is not enumerated in the reference metadata. The structure of the view — indicated by columns such as PARTY_ID, PARTY_SITE_ID, PARTY_LOCATION_ID, CUST_ACCT_SITE_ID, LOCATION_ID, SITE_NUMBER, and IDENTIFYING_ADDRESS_FLAG — shows that it is defined over the Trading Community Architecture tables, most notably HZ_PARTIES, HZ_PARTY_SITES, HZ_LOCATIONS, and HZ_CUST_ACCOUNT_SITES (through which it links to HZ_CUST_ACCOUNTS). The presence of both ADDRESS_ID and PARTY_SITE_ID reflects the migration from the older RA_ADDRESSES base table model to the TCA party-site model introduced in Release 11i and carried forward through 12.1.1 and 12.2.2.

Key Columns

  • THIRD_PARTY_FLAG — Indicates whether the address relates to a third-party entity, used in trade management and third-party (TP) processing contexts. This is the column the user searched for.
  • TP_HEADER_ID — Links the address to a third-party header record.
  • BILL_TO_FLAG, SHIP_TO_FLAG, MARKET_FLAG — Business purpose flags identifying the role of the site.
  • PARTY_ID, PARTY_SITE_ID, PARTY_LOCATION_ID — TCA identifiers for the party, its site, and the location.
  • IDENTIFYING_ADDRESS_FLAG — Marks the address as the identifying address for the party.
  • LOCATION_ID, ADDRESS_ID — Keys to the location and legacy address records.
  • SITE_NUMBER — The user-visible site number for the party site.
  • CUSTOMER_ID, CUSTOMER_CATEGORY_CODE, CUSTOMER_GROUP_CODE — Customer classification attributes.
  • TERRITORY_ID, TERRITORY, SERVICE_TERRITORY_ID — Territory and sales-territory assignments.
  • ADDRESS1–ADDRESS4, CITY, STATE, PROVINCE, POSTAL_CODE, COUNTY, COUNTRY — Standard address lines.
  • ORG_ID — Multi-org operating unit identifier, enabling operating-unit filtering.
  • DO_NOT_MAIL_FLAG, STATUS, ORIG_SYSTEM_REFERENCE — Status and source-system attributes for integration.

Common Use Cases and Queries

The view is commonly used to report customer ship-to and bill-to addresses, to extract address data for integrations, and to identify sites flagged for third-party processing. A typical query filtering on the searched column is:

  • SELECT party_id, party_site_id, site_number, address1, city, state, postal_code, third_party_flag FROM ra_addresses WHERE third_party_flag = 'Y' AND org_id = :p_org_id;
  • Reporting all bill-to addresses: SELECT customer_id, address1, city, third_party_flag FROM ra_addresses WHERE bill_to_flag = 'Y';
  • Finding identifying addresses for a party: SELECT party_id, site_number, identifying_address_flag FROM ra_addresses WHERE identifying_address_flag = 'Y';

Because the view exposes ORG_ID, queries should generally be restricted to a specific operating unit to avoid duplicate cross-org results.