Search Results old_party_number




Overview
Explore in AI Chat

Overview

CSI_IPH_DETAILS_V is an APPS-owned, VALID database view within the CSI (Install Base) product family in Oracle EBS 12.1.1 and 12.2.2. It is described in the ETRM metadata as the "Instance Party History details view." Its purpose is to expose the full audit trail of changes made to the parties (contacts, roles, vendors, employees and other party relationships) associated with an item instance in the Install Base. Each row of the view represents one historical change to an instance-party relationship, presenting the value of an attribute before the transaction (the OLD_ value) alongside the value after it (the NEW_ value).

The view is not a transactional entry surface; it is a read-only reporting and integration object. It supports queries that reconcile who was associated with an installed item at any point in time, what relationship type or role they held, and whether that association carried flags such as primary or preferred. The presence of the OLD_PRIMARY_FLAG / NEW_PRIMARY_FLAG column pair — the term that prompted the search for "old_primary_flag" — is characteristic of the view's before-and-after design and is central to auditing changes in the primary party designation of an instance.

Underlying Base Objects

The view is defined over three principal history and header objects and a set of lookups and descriptive joins. The documented base objects are CSI_I_PARTIES_H (synonym), CSI_I_PARTIES (synonym), CSI_I_PARTIES_H history, CSI_IPA_RELATION_TYPES (synonym), CSI_LOOKUPS (view), and, for party name and number resolution, HZ_PARTIES along with party-type sources such as JTF_RS_GROUPS_VL, JTF_RS_TEAMS_VL, PER_ALL_PEOPLE_F and PO_VENDORS.

The primary driving table is CSI_I_PARTIES_H, which stores the historical (audit) rows for instance parties; CSI_I_PARTIES holds the current detail rows. CSI_IPA_RELATION_TYPES supplies the relationship name and description both for the OLD and NEW relationship codes, while CSI_LOOKUPS supplies the meaning (translated party type) for the old and new party types. The inline subquery against CSI_I_PARTIES_H is used to derive the resolution of old and new party identifiers into display values (OLD_PARTY_NAME / OLD_PARTY_NUMBER and NEW_PARTY_NAME / NEW_PARTY_NUMBER) from the appropriate source. Collectively, these joins convert raw identifier columns into human-readable descriptions required for reporting.

Key Columns

Common Use Cases and Queries

Typical uses include install-base audits, SOX-style change reporting, and data reconciliation between the Install Base and party master. A frequent query is a primary-party history for an instance:

SELECT instance_id, transaction_id, old_party_name, new_party_name,
  DECODE(old_primary_flag,'Y','Yes','No') old_primary,
  DECODE(new_primary_flag,'Y','Yes','No') new_primary,
  last_update_date
FROM apps.csi_iph_details_v
WHERE instance_id = :p_instance_id
ORDER BY last_update_date DESC;

Another common pattern identifies parties whose primary status changed during a period, using OLD_PRIMARY_FLAG and NEW_PRIMARY_FLAG with the audit dates. Because the view joins multiple base objects, query performance is best when filtered by INSTANCE_ID or by a date range on LAST_UPDATE_DATE. Integration use is generally limited to extraction for reporting or reconciliation, since the view is read-only.