Results for “pay_terms”

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

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:

• CUST_ACCOUNT_ID, PARTY_ID, ACCOUNT_NUMBER, ORIG_SYSTEM_REFERENCE — account identity and external reference keys.
• STATUS and DESCRIPTION — the raw status code and its AR_LOOKUPS description (CODE_STATUS lookup type).
• CUSTOMER_TYPE, CUSTOMER_CLASS_CODE — classification attributes used in eligibility and posting rules.
• PAYMENT_TERM_ID and NAME — the payment term identifier from HZ_CUST_ACCOUNTS and its language-specific name from RA_TERMS_TL. This is the column pair most relevant to searches for pay_terms.
• TAX_CODE and TAX_ROUNDING_RULE — tax determination and rounding behavior for the account.
• CURRENT_BALANCE, WRITE_OFF_ADJUSTMENT_AMOUNT, SUSPENSION_DATE, ACCOUNT_ESTABLISHED_DATE — collections-oriented financial and lifecycle attributes.
• ATTRIBUTE_CATEGORY and ATTRIBUTE1–ATTRIBUTE20 — the descriptive flexfield context and segments.
• OBJECT_VERSION_NUMBER — optimistic locking indicator, plus standard WHO columns (CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN).

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.