Search Results bic_address_v




Overview
Explore in AI Chat

Overview

BIC_ADDRESS_V is a database view in Oracle E-Business Suite 12.1.1 and 12.2.2 that belongs to the BIC – Customer Intelligence product family. Within the ETRM registry, this module is explicitly flagged as obsolete, meaning it is no longer part of the supported functional footprint in current releases. The view was originally designed to expose a single, pre-formatted address string derived from customer location data, allowing downstream reports, integration layers, and Customer Intelligence analytics to consume a human-readable address without repeatedly concatenating address segments at query time.

The view's documented purpose is precise: "View on HZ_LOCATIONS which gives formatted address." Rather than presenting the discrete address attributes stored on the base table, BIC_ADDRESS_V collapses the multi-line address into one text value using newline (CHR(10)) delimiters. This makes it convenient for display in fixed-width reports, mailing labels, letter templates, and similar presentation-oriented outputs. Because the metadata notes that the object is "Not implemented in this database," deployments must confirm the view's actual presence before depending on it; where it does exist, it should be treated as a legacy object with no forward-compatibility guarantees.

Underlying Base Objects

The view is defined over a single base table: HZ_LOCATIONS, the central store for addresses in the Oracle Trading Community Architecture (TCA) data model. TCA is the foundation for customers, parties, sites, and locations across Receivables, Order Management, and CRM modules. Referencing HZ_LOCATIONS situates the view squarely within the customer and location master data domain.

The documented view text is:

  • SELECT LOC.LOCATION_ID LOCATION_ID, LOC.ADDRESS1||CHR(10)||LOC.CITY||', '||LOC.STATE||'-'||LOC.POSTAL_CODE||CHR(10)||LOC.COUNTY||CHR(10)||LOC.COUNTRY||CHR(10) ADDRESS FROM HZ_LOCATIONS LOC WITH READ ONLY

Two structural points follow from this definition. First, because it is a read-only projection over a single table, the view introduces no joins and therefore no aggregation or filtering logic; it is a formatting convenience only. Second, the ETRM documentation records no other referenced base objects, so any extension of address formatting beyond HZ_LOCATIONS columns is outside the documented scope. The WITH READ ONLY clause confirms that the view cannot be used as a DML target, reinforcing its reporting-only role.

Key Columns

The view exposes exactly two columns, as recorded in the documented metadata:

  • LOCATION_ID — The unique identifier of the location record, mapped directly from HZ_LOCATIONS.LOCATION_ID. This is the primary key of the underlying table and the join key used to relate the address to parties, sites, and accounts elsewhere in TCA.
  • ADDRESS — A concatenated, formatted string assembled from ADDRESS1, CITY, STATE, POSTAL_CODE, COUNTY, and COUNTRY. Line breaks are inserted with CHR(10), and punctuation (a comma after the city and a hyphen between state and postal code) is embedded within the concatenation.

Because the formatting is hard-coded, the column always returns a single string regardless of which address elements are populated on the source row; missing elements simply contribute no content between the delimiters.

Common Use Cases and Queries

Typical usage involves retrieving a display-ready address for a given location, or joining the view to TCA entities to enrich a report. A basic lookup by location identifier:

  • SELECT location_id, address FROM bic_address_v WHERE location_id = :p_location_id;

For integration or correspondence scenarios, the view is joined to site or party tables to resolve addresses for a customer account. A representative query joins through the location identifier:

  • SELECT a.address FROM bic_address_v a, hz_cust_site_uses_all s WHERE a.location_id = s.location_id AND s.site_use_code = 'BILL_TO';

Given the module's obsolete status, teams maintaining 12.1.1 or 12.2.2 environments and encountering this object should consider replacing it with a direct query over HZ_LOCATIONS or with the standard TCA address formatting functionality. Any conversion should preserve the column names (LOCATION_ID, ADDRESS) so that dependent reports and interfaces continue to function without modification.