Search Results cs_ra_addr_ship_rg_v




Overview

CS_RA_ADDR_SHIP_RG_V is a Service (CS) module reporting view that exposes customer product Ship-To locations. Its documented purpose is to present "Customer Product Ship locations" as a single, denormalized row per Ship-To site use, combining address attributes, site-use metadata, and customer identity. In Oracle EBS 12.1.1 and 12.2.2 environments, the view serves as a convenience layer over the Receivables address model (RA_ADDRESSES, RA_SITE_USES, RA_CUSTOMERS) joined to AR_LOOKUPS for usage-code descriptions. Rather than re-querying four base tables and reconstructing formatted address strings, report developers and integration routines can select directly from this view.

The object is relevant to the user search term city_state_zip because the view exposes a pre-formatted CITY_STATE_ZIP column. This column concatenates CITY, STATE, POSTAL_CODE, and COUNTRY with conditional delimiter logic, truncating the result to 240 characters. Consequently, the view is a natural source for address labels, shipping documentation, interface files, and any downstream process requiring a single-line city/state/postal representation.

The ETRM metadata notes that the view is not implemented in the documented database. This is a significant caveat: the definition should be treated as reference metadata rather than a guarantee that the object exists in a given instance. The view text is therefore best used as a specification to replicate, extend, or validate against the customer's actual database.

Underlying Base Objects

The documented base objects are RA_ADDRESSES (aliased A), RA_SITE_USES (aliased SU), AR_LOOKUPS (aliased LU), and RA_CUSTOMERS (aliased CUST). No other referenced base objects are documented, and the ETRM record lists the owner as blank.

Joins and filters are explicit:

  • CUST.CUSTOMER_ID = A.CUSTOMER_ID links addresses to customers.
  • SU.ADDRESS_ID = A.ADDRESS_ID links site uses to addresses.
  • SU.SITE_USE_CODE = LU.LOOKUP_CODE restricts lookups to site-use codes.
  • LU.LOOKUP_TYPE = 'SITE_USE_CODE' qualifies the lookup join.
  • CUST.STATUS = 'A' and A.STATUS = 'A' restrict output to active customers and active addresses.
  • SU.SITE_USE_CODE = 'SHIP_TO' restricts rows to Ship-To site uses only.

The view is therefore a filtered projection of the Ship-To subset of the Receivables address hierarchy, enriched with a decoded address-usage meaning.

Key Columns

  • SHIP_LOCATION — maps to SU.LOCATION; the location identifier associated with the site use.
  • SITE_USE_ID — primary identifier of the Ship-To site use; the practical key for joining back to RA_SITE_USES.
  • ADDRESS_USAGE — LU.MEANING decoded from the site-use code (that is, "Ship-To").
  • CUSTOMER_NAME / CUSTOMER_NUMBER / CUSTOMER_ID — customer identification from RA_CUSTOMERS.
  • ADDRESS_LINE_1 — concatenation of ADDRESS1 and ADDRESS2 separated by a comma.
  • ADDRESS_LINE_2 — concatenation of ADDRESS3 and ADDRESS4 with conditional comma handling.
  • CITY_STATE_ZIP — the formatted, 240-character-limited concatenation of CITY, STATE, POSTAL_CODE, and COUNTRY.
  • ADDRESS1–ADDRESS4, CITY, STATE, POSTAL_CODE, COUNTRY — discrete raw address components, preserved for parsing, sorting, or re-formatting.

Common Use Cases and Queries

Typical uses include shipping labels, service dispatch reports, customer master extracts, and integration payloads requiring validated Ship-To addresses. A representative query retrieving formatted Ship-To addresses for active customers is:

  • SELECT site_use_id, customer_number, customer_name, address_usage, address_line_1, address_line_2, city_state_zip FROM cs_ra_addr_ship_rg_v;
  • SELECT customer_number, address_line_1, city_state_zip FROM cs_ra_addr_ship_rg_v WHERE UPPER(city_state_zip) LIKE '%' || UPPER(:p_city_state_zip) || '%';
  • SELECT site_use_id, city_state_zip FROM cs_ra_addr_ship_rg_v WHERE customer_id = :p_customer_id ORDER BY site_use_id;

Because the view already enforces active-status and SHIP_TO filters, queries avoid re-implementing those predicates. Validation should still confirm the view exists, since the ETRM metadata records it as not implemented in the reference database.