Search Results account_termination_date




Overview
Explore in AI Chat

Overview

CSC_HZ_PARTY_ACCOUNTS_V is a Customer Care (CSC) module view owned by the APPS schema and defined with VALID status in Oracle E-Business Suite 12.1.1 and 12.2.2. It consolidates party, customer account, and account role information into a single denormalized projection, allowing callers, order capture flows, and reporting utilities to retrieve the accounts and roles associated with a trading party without joining the underlying Trading Community Architecture (TCA) tables directly. The view is registered in the ETRM repository under the title "View: CSC_HZ_PARTY_ACCOUNTS_V" with the description "Account and Role information of a Party." Because it is a view rather than a table, it carries no independent storage, no DML support, and no primary key of its own beyond the ROWID of HZ_PARTIES exposed as ROW_ID. Its principal value is as a stable, pre-joined read interface for customer-facing and service-oriented components that need account context keyed by party.

Underlying Base Objects

The documented metadata lists three referenced base objects, each resolved through an APPS synonym: HZ_CUST_ACCOUNTS, HZ_CUST_ACCOUNT_ROLES, and HZ_PARTIES. The view joins them as follows: HZ_CUST_ACCOUNTS is joined to HZ_PARTIES on PARTY_ID, and HZ_CUST_ACCOUNTS is outer-joined to HZ_CUST_ACCOUNT_ROLES on both PARTY_ID and CUST_ACCOUNT_ID using the (+) operator. The outer join is significant: a customer account with no recorded account role still appears in the result set, with role columns such as PRIMARY_FLAG and ROLE_TYPE returned as null. Similarly, the primary key of HZ_CUST_ACCOUNTS (CUST_ACCOUNT_ID) is the join driver, so a party that exists only as a party record, with no customer account, is not returned by this view despite HZ_PARTIES appearing first in the FROM clause. Practitioners should therefore treat the view as account-centric, not party-centric, even though it projects PARTY columns.

Key Columns

The projection exposes seventeen columns. Identity and naming columns include ROW_ID (HZ_PARTIES.ROWID), PARTY_ID, PARTY_NUMBER, PARTY_NAME, and PARTY_TYPE from HZ_PARTIES, together with COUNTRY. Account attributes include CUST_ACCOUNT_ID, ACCOUNT_NUMBER, ACCOUNT_NAME, STATUS, ACCOUNT_TERMINATION_DATE, ACCOUNT_ACTIVATION_DATE, and LAST_UPDATE_DATE. Role attributes consist of PRIMARY_FLAG and ROLE_TYPE (documented in the column list as ROLE). The user search term "account_activation_date" maps directly to ACCT.ACCOUNT_ACTIVATION_DATE, sourced from HZ_CUST_ACCOUNTS. This column records the date on which the customer account became active and is commonly used to filter recently activated accounts, measure onboarding latency, or drive welcome and renewal communications. It should not be confused with ACCOUNT_TERMINATION_DATE, which marks the end of the account's active life. STATUS reflects account lifecycle state, such as active or inactive, and is typically evaluated alongside these two date columns.

Common Use Cases and Queries

Typical scenarios include customer care agent screens that display a party alongside all of its accounts and roles, onboarding and activation reporting, and integration extracts that feed downstream CRM or billing systems. To locate accounts activated within a given period, filtering on the activation date is straightforward:

  • SELECT party_number, party_name, account_number, account_name, account_activation_date, status FROM csc_hz_party_accounts_v WHERE account_activation_date >= :p_from_date AND account_activation_date < :p_to_date < 1;
  • SELECT cust_account_id, account_number, primary_flag, role_type FROM csc_hz_party_accounts_v WHERE party_id = :p_party_id ORDER BY primary_flag DESC;
  • SELECT party_id, party_name, account_number, account_termination_date FROM csc_hz_party_accounts_v WHERE party_type = 'ORGANIZATION' AND status = 'A' AND account_termination_date IS NULL;

Because the role join is outer, queries that require a role must add a predicate such as role_type IS NOT NULL, and callers must anticipate duplicate rows where a party holds multiple accounts or multiple roles. The view is read-only, so all maintenance of activation and termination dates must be performed against HZ_CUST_ACCOUNTS itself. Performance depends on the indexes on HZ_CUST_ACCOUNTS.PARTY_ID and the role join keys; heavy activation-date reporting may warrant a materialized copy or a bespoke query against HZ_CUST_ACCOUNTS where the TCA joins are not required.