Search Results new_context




Overview
Explore in AI Chat

Overview

CSI_IPAH_DETAILS_V is a reporting and inquiry view owned by the APPS schema in Oracle E-Business Suite releases 12.1.1 and 12.2.2. It belongs to the CSI – Install Base product family and exposes the historical audit trail of party account assignments made against install base instances. The view is described in ETRM as "Instance Party Accounts History details," which reflects its purpose: presenting each recorded change to an instance's party account relationship as a before-and-after pair of values.

The view is denormalized for reporting convenience. Rather than returning raw foreign keys, it joins the history table to customer accounts, parties, and relationship-type lookup tables to resolve readable names, account numbers, and relationship descriptions. Both the prior ("old") and current ("new") states of each attribute are carried side by side, so consumers can compare them directly without self-joining the history table. The object is defined as a view in the APPS schema with VALID status, and it is intended for read-only query access rather than as a transactional interface.

Underlying Base Objects

The documented base objects referenced by the view are CSI_IP_ACCOUNTS_H, CSI_IP_ACCOUNTS, CSI_I_PARTIES, CSI_IPA_RELATION_TYPES, HZ_CUST_ACCOUNTS, and HZ_PARTIES, all accessed through APPS synonyms. CSI_IP_ACCOUNTS_H is the driving table and supplies the historical rows, including the instance party account history identifier, the account identifier, and the transaction identifier that ties the record to the originating change. CSI_IP_ACCOUNTS provides the current instance account relationship, joined to establish the instance context. CSI_I_PARTIES links the account to the specific install base instance and party.

HZ_CUST_ACCOUNTS appears twice, aliased to resolve the old and new account number and account name. HZ_PARTIES likewise appears twice for the old and new party name. CSI_IPA_RELATION_TYPES is also joined twice, resolving the old and new relationship type codes into a name and description. This double-join pattern is what makes the view a self-contained audit report: every code column has a corresponding descriptive column alongside it.

Key Columns

The view exposes several categories of columns. Identity and linkage columns include IP_ACCOUNT_HISTORY_ID, IP_ACCOUNT_ID, TRANSACTION_ID, and INSTANCE_ID, which together identify the history record, the account, the transaction responsible for the change, and the affected instance. The central audit columns are OLD_PARTY_ACCOUNT_ID and NEW_PARTY_ACCOUNT_ID, OLD_RELATIONSHIP_TYPE_CODE and NEW_RELATIONSHIP_TYPE_CODE, and the old/new active start and end dates. These are the columns most often used to reconstruct relationship history, and NEW_RELATIONSHIP_TYPE_CODE is the counterpart to the frequently searched legacy column name old_relationship_type_code in the 12.1.1 code line.

Descriptive resolution columns include OLD_ACCOUNT_NUMBER, OLD_ACCOUNT_NAME, OLD_PARTY_NAME, OLD_RELATIONSHIP_NAME, and OLD_RELATIONSHIP_DESCR, with equivalent NEW_ variants. Address context is provided through OLD_BILL_TO_ADDRESS, NEW_BILL_TO_ADDRESS, OLD_SHIP_TO_ADDRESS, and NEW_SHIP_TO_ADDRESS. A set of fifteen attribute flexfield pairs (OLD_ATTRIBUTE1 through OLD_ATTRIBUTE15 and their NEW_ counterparts) plus OLD_CONTEXT and NEW_CONTEXT accommodates descriptive flexfield data captured at the time of change. Standard WHO columns (CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN) and OBJECT_VERSION_NUMBER support audit and concurrency tracking, while FULL_DUMP_FLAG indicates whether the record represents a complete snapshot of the relationship.

Common Use Cases and Queries

Typical uses include tracing when a customer account or party was reassigned on an install base instance, auditing relationship type changes over a period, and producing history reports for service or contract entitlement analysis. A representative query filtering on a relationship type change is shown below.

  • SELECT ip_account_history_id, instance_id, transaction_id, old_relationship_type_code, new_relationship_type_code, old_relationship_name, new_relationship_name, creation_date FROM csi_ipah_details_v WHERE old_relationship_type_code = 'CUSTOMER' ORDER BY creation_date DESC;
  • SELECT instance_id, old_account_number, new_account_number, old_party_name, new_party_name, last_update_date FROM csi_ipah_details_v WHERE instance_id = :p_instance_id;
  • SELECT full_dump_flag, COUNT(*) FROM csi_ipah_details_v GROUP BY full_dump_flag;

Because the view performs multiple outer-style joins across HZ and CSI tables, queries should filter by instance, account, or date range where possible to limit the row set. The view is read-only and should not be used as a target for DML.