Search Results ar_addresses_v




Overview
Explore in AI Chat

Overview

AR_ADDRESSES_V is a PL/SQL view owned by the APPS schema in Oracle E-Business Suite Receivables (AR). It is a classic Oracle Forms base-table view, originally defined with a comment noting its purpose for Oracle Forms 4 address blocks, and it continues to serve as the foundation for the address region of the Customers form in release 12.1.1 and 12.2.2. The view exposes one row per customer account site address, joining the site assignment record to its underlying location and territory data, and supplies a server-side formatted address string generated by ARP_ADDR_PKG.FORMAT_ADDRESS.

Because the view acts as a Forms base table, it carries the ROWID of the site row as ROW_ID and the mandatory WHO columns (CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN, OBJECT_VERSION_NUMBER) so that the form can perform inserts, updates, and optimistic locking against it. Reporting and integration teams also use it as a convenient denormalized source of customer addresses, since it resolves the HZ location, territory, and language joins that would otherwise require multi-table SQL.

Underlying Base Objects

The documented base objects are HZ_CUST_ACCT_SITES, HZ_LOCATIONS, HZ_LOC_ASSIGNMENTS, HZ_PARTY_SITES, FND_TERRITORIES_VL, FND_LANGUAGES_VL, AR_LOOKUPS, and the package ARP_ADDR_PKG. The view is anchored on HZ_CUST_ACCT_SITES (aliased ADDR), which supplies the CUST_ACCT_SITE_ID, CUST_ACCOUNT_ID, STATUS, ORIG_SYSTEM_REFERENCE, TERRITORY_ID, KEY_ACCOUNT_FLAG, and the ATTRIBUTE1–ATTRIBUTE15 flexfield columns. The site is linked through HZ_PARTY_SITES and HZ_LOC_ASSIGNMENTS to HZ_LOCATIONS (aliased LOC), which provides the ADDRESS1–ADDRESS4, CITY, COUNTY, STATE, PROVINCE, POSTAL_CODE, COUNTRY, ADDRESS_KEY, LANGUAGE, and ADDRESS_LINES_PHONETIC columns. Territory attributes such as TERRITORY_SHORT_NAME and ADDRESS_STYLE are read from FND_TERRITORIES_VL (aliased TERR), while FND_LANGUAGES_VL yields LANGUAGE_DESCRIPTION and AR_LOOKUPS backs customer category lookups. ARP_ADDR_PKG.FORMAT_ADDRESS is invoked at query time to build CONCATENATED_ADDRESS.

Note the R12 architecture: the older AR customer tables have been replaced by the Trading Community Architecture (TCA) model, so AR_ADDRESSES_V is effectively a compatibility and Forms-support layer over HZ_CUST_ACCT_SITES and its TCA relations rather than over legacy AR_ADDRESSES storage.

Key Columns

  • ROW_ID – ROWID of the underlying site row, enabling Forms DML.
  • ADDRESS_ID – The CUST_ACCT_SITE_ID, the primary site identifier.
  • CUSTOMER_ID – The CUST_ACCOUNT_ID linking the site to the customer account.
  • STATUS – Site status (for example, active or inactive).
  • ADDRESS1–ADDRESS4, CITY, COUNTY, STATE, PROVINCE, POSTAL_CODE, COUNTRY – Raw location components.
  • CONCATENATED_ADDRESS – Preformatted address derived from the location columns via the address style.
  • TERRITORY_SHORT_NAME, ADDRESS_STYLE, TERRITORY_ID – Territory and formatting attributes.
  • LANGUAGE, LANGUAGE_DESCRIPTION – Language code for the address and its descriptive text.
  • KEY_ACCOUNT_FLAG, CUSTOMER_CATEGORY_CODE – Flags and profile classification used by the customer form.
  • ATTRIBUTE_CATEGORY, ATTRIBUTE1–ATTRIBUTE15 – Descriptive flexfield context and segments at the site level.
  • CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN, OBJECT_VERSION_NUMBER – Standard audit and locking columns.

Common Use Cases and Queries

Typical reporting scenarios include retrieving a customer’s bill-to or ship-to addresses for statements, invoices, and extracts, and reconciling site addresses with TCA location data. A simple lookup for one account:

SELECT address_id, customer_id, concatenated_address, country, status FROM apps.ar_addresses_v WHERE customer_id = :p_customer_id AND status = 'A' ORDER BY address_id;

Because FORMAT_ADDRESS is executed per row, the view can be costly over large volumes. For bulk reporting, join HZ_LOCATIONS directly and format the address in the report layer, or use the view only when the delivered formatting logic is required. When the view is used as a Forms base table, DML must respect the site and WHO columns; direct inserts and updates should normally be routed through TCA or Receivables APIs rather than performed against the view.