Results for “asf_organization_relat_lov_v”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

The APPS.ASF_ORGANIZATION_RELAT_LOV_V view is a reporting and list-of-values (LOV) construct belonging to the ASF – Sales Online product family in Oracle E-Business Suite 12.1.1 and 12.2.2. Its documented purpose is to expose related organization records, providing a denormalized, query-ready projection that joins relationship data from the Trading Community Architecture (TCA) model against lookup values. Because the view resolves party relationships into human-readable form, it is typically consumed by Oracle Forms LOVs, concurrent programs, and custom reports that need to present or select organizations associated with a given party.

The view is owned by the APPS schema and is listed with a VALID status in ETRM. In the context of a user search for rel_party_id, this object is relevant because it exposes a column of exactly that name, making it a natural source when resolving relationship records back to the related party identifier.

Underlying Base Objects

ETRM documents the view as being defined over three referenced base objects:

• HZ_PARTIES (SYNONYM) — the TCA master entity storing party records, aliased as PAR in the view text. It supplies the party name, party identifier, party type, and party status.
• HZ_RELATIONSHIPS (SYNONYM) — the TCA relationship table, aliased as REL, holding the subject/object pairing, relationship code, and relationship status.
• AR_LOOKUPS (VIEW) — the Receivables lookup view, aliased as AR, used to translate the relationship code into a displayed meaning from the PARTY_RELATIONS_TYPE lookup type.

The joins enforced in the view text are significant: the relationship is validated only where REL.OBJECT_ID = PAR.PARTY_ID, and both the subject and object table names must equal HZ_PARTIES. Status filters restrict rows to active (A) or inactive (I) states on both the relationship and the party record.

Key Columns

• PARTY_NAME / NAME — the name of the related party drawn from HZ_PARTIES. The view text selects PAR.PARTY_NAME twice, which is why both PARTY_NAME and NAME appear in the documented column list.
• PARTY_ID — the primary key of the related (object) party.
• PARTY_TYPE — indicates whether the party is an organization, person, or group.
• STATUS — the relationship status from HZ_RELATIONSHIPS, filtered to A or I.
• REL_PARTY_ID — the related party identifier surfaced by the view; this is the column associated with the user's search term and is used to bind relationship selectors to a specific party.
• SUBJECT_ID — the party identifier on the subject side of the relationship.
• OBJECT_ID — the party identifier on the object side of the relationship.
• RELATIONSHIP_TYPE — the decoded meaning of the relationship code, sourced from AR_LOOKUPS.

Common Use Cases and Queries

Typical scenarios include populating an LOV of related organizations during sales order entry, auditing the relationship network around a customer, and resolving rel_party_id values encountered in ASF transaction data back to a party name and type.

A representative query retrieving all active relationships for a given subject party:

• SELECT rel_party_id, party_name, party_type, relationship_type
• FROM apps.asf_organization_relat_lov_v
• WHERE subject_id = :p_subject_id
• AND status = 'A';

To resolve a specific rel_party_id back to its descriptive attributes, filter on that column directly. Because the view joins the TCA relationship and party tables with an inner join, only parties that satisfy all status and table-name conditions are returned. Reports should therefore not assume that every HZ_RELATIONSHIPS row appears; relationships involving non-party subject or object tables are intentionally excluded. For 12.1.1 and 12.2.2, the underlying TCA and AR objects are consistent, so the view can be used interchangeably across both releases within the ASF Sales Online context.