Search Results pay_terms




Overview
Explore in AI Chat

Overview

CSC_ACCOUNT_OVERVIEW_V is an APPS-owned reporting view within the Oracle E-Business Suite 12.1.1 and 12.2.2 codelines. It exposes a consolidated, denormalized projection of customer account master data, drawing its core attributes from HZ_CUST_ACCOUNTS and enriching them with translated lookup descriptions and payment term names. The view is typically consumed by Oracle Service (TeleService / Customer Care) and Collections screens that require an at-a-glance summary of a customer account, including its debt profile, status, tax handling, and credit-related attributes.

Its principal role in reporting and integration is to shield downstream SQL from the multi-table joins that would otherwise be required to resolve the account status description and payment term name. Because it resolves code meanings at the database level, the view provides presentation-ready values suitable for BI Publisher reports, OAF/Forms LOVs, and outbound interface extracts that must present human-readable customer classifications.

Underlying Base Objects

The ETRM-documented dependency list for this view comprises three objects:

  • HZ_CUST_ACCOUNTS — the master customer account entity that supplies the vast majority of columns (account identifier, party, status, tax, balances, and DFF attributes).
  • AR_LOOKUPS — joined on acct.status = ar.lookup_code with ar.lookup_type = 'CODE_STATUS', providing the descriptive status text.
  • RA_TERMS_TL — the translated payment terms table, outer-joined on acct.payment_term_id = pay_terms.term_id(+) and filtered by pay_terms.language(+) = USERENV('LANG') to return the term name in the session language.

The join topology is deliberate: the AR_LOOKUPS join is an inner join (equality predicate without an outer marker), whereas the payment terms join is an outer join. The consequence is that only accounts with a valid CODE_STATUS lookup row survive in the result set, while accounts lacking a valid or translated payment term still appear, with a null PAY_TERMS.NAME. The language-based outer join ensures the view never drops a row purely because a translated term is unavailable in the current session language.

Key Columns

Because the view is defined by a positional SELECT list, most columns retain their base names. Notable columns include:

The SELECT list also includes three literal NULL placeholders in the position after CUSTOMER_CLASS_CODE and after TAX_CODE. These are positional fillers that preserve a fixed column layout for legacy consumers; they carry no data and should be treated as reserved slots.

Common Use Cases and Queries

Typical scenarios include customer account overview pages, payment term audits, and collections extracts. A representative query listing accounts with their payment term names follows:

  • SELECT account_number, account_name, status, description, name AS payment_term, current_balance FROM apps.csc_account_overview_v WHERE org_id = :p_org_id ORDER BY account_number;
  • Auditing accounts with no resolvable payment term: SELECT cust_account_id, account_number FROM apps.csc_account_overview_v WHERE payment_term_id IS NOT NULL AND name IS NULL;
  • Balance-based collections reporting: SELECT account_number, name, current_balance FROM apps.csc_account_overview_v WHERE current_balance > 0 AND status = 'A';

Filtering on ORG_ID is essential in multi-organization deployments, since the view does not enforce operating unit security by itself. Because the payment terms join is language-sensitive, applications running under different session languages may return different NAME values for the same account, which should be accounted for in any cached or cross-language comparison.