Search Results original_party_id




Overview
Explore in AI Chat

Overview

CS_W_RESOURCE_DETAILS_V is a Service (CS) module view that presents a unified, denormalized list of resources available to the Service application — primarily parties held in the Trading Community Architecture (TCA) registry and the contacts related to them. It is a reporting and integration aid rather than a transactional table. Because it consolidates party information, address data, contact phone numbers, e-mail, and fax derived through the CS_PARTIES_PKG API layer, it removes the need for external reports and interfaces to join HZ_PARTIES, HZ_PARTY_RELATIONSHIPS, and AR_LOOKUPS manually. The view carries a RULE hint, indicating it was written for the rule-based optimizer and is typically used in low-volume lookups and LOV-style queries rather than high-throughput batch processing.

The ETRM documentation records that the view is not implemented in this database, meaning the object definition should be validated against the actual instance before relying on it. The column ORIGINAL_PARTY_ID — the term the user searched on — acts as the anchor that links each returned row back to the top-level party from which the resource was derived.

Underlying Base Objects

The metadata does not document referenced base objects explicitly, but the embedded view text defines the query over two principal sources plus supporting lookups:

  • HZ_PARTIES (aliased HP) — the TCA party master, supplying party name, party number, party ID, party type, and the concatenated address components.
  • HZ_PARTY_RELATIONSHIPS (aliased HPR) — joined in the second UNION branch for relationships where the relationship type is CONTACT_OF, exposing the subject party's related contacts.
  • AR_LOOKUPS (aliased ARL) — an outer-joined lookup source on lookup type PARTY_TYPE, used to drive the SORT_ORDER decode.
  • CS_PARTIES_PKG — the Service parties PL/SQL package, called for phone, e-mail, and fax retrieval using FND_PROFILE values for phone type.

The view is a UNION of two branches: the first returns each party as its own resource, while the second returns contacts linked to a party through CONTACT_OF, with ORIGINAL_PARTY_ID carrying the parent party ID.

Key Columns

  • RESOURCE_NAME / RESOURCE_NUMBER / RESOURCE_ID — party name, party number, and party ID mapped to resource terminology.
  • RESOURCE_TYPE — the underlying PARTY_TYPE (for example PERSON, ORGANIZATION, PARTNER).
  • ADDRESS — a concatenation of ADDRESS1 through ADDRESS4, CITY, STATE, POSTAL_CODE, PROVINCE, and COUNTY.
  • ORIGINAL_PARTY_ID — in the first branch this equals PARTY_ID; in the contact branch it is the related object ID from HZ_PARTY_RELATIONSHIPS, i.e., the original or parent party. This is the discriminator between a party returned in its own right and a contact returned on behalf of another party.
  • RESOURCE_CATEGORY — literal 'PARTY', indicating all rows originate from the TCA party model.
  • SORT_ORDER — DECODE that yields 'AAAA' for PERSON and the party type otherwise, forcing persons to sort first.
  • WORK_PHONE, PAGER_PHONE, CELL_PHONE, HOME_PHONE, EMAIL, FAX — contact attributes resolved through CS_PARTIES_PKG using the CS_AR_* phone type profile options.

Common Use Cases and Queries

Typical consumption includes resource LOVs, contact directories, and extracting resource details for external systems, filtering on ORIGINAL_PARTY_ID to isolate the contacts belonging to a specific party.

SELECT resource_id, resource_name, resource_number, address,
       original_party_id, work_phone, email
FROM   cs_w_resource_details_v
WHERE  original_party_id = :party_id
ORDER  BY sort_order, resource_name;

SELECT resource_name, resource_type, cell_phone, home_phone
FROM   cs_w_resource_details_v
WHERE  resource_type = 'PERSON'
AND    original_party_id = resource_id;

Because the view is rule-hinted and calls PL/SQL functions per row, it should be used in bounded result sets. Confirm existence and column definitions against the target 12.1.1 or 12.2.2 instance before deployment, since the documentation flags it as not implemented in the reference database.