Results for “as_opp_classification_v”

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

Overview

AS_OPP_CLASSIFICATION_V is a read-only database view owned by the APPS schema in Oracle E-Business Suite, delivered as part of the AS – Sales Foundation product family (the Sales/TeleSales application). It presents sales opportunity classification data — specifically records of interest classifications associated with leads and opportunities. The view combines the transactional interest rows from AS_INTERESTS with their descriptive context: the interest type, the primary and secondary interest codes, and the interest status meaning. It is intended for reporting, inquiry, and integration purposes where a denormalized, human-readable projection of opportunity/lead classification is required, avoiding the need to write multi-table joins against the underlying foundation tables directly.

The view is documented as VALID in ETRM for both 12.1.1 and 12.2.2. Because it is a view and not a table, it exposes no DML surface; all columns are derived from the underlying interest records and their lookup values.

Underlying Base Objects

Per the documented view text, AS_OPP_CLASSIFICATION_V is defined over the following base objects, all owned by APPS:

• AS_INTERESTS (VIEW) — the driving object, aliased INT. Provides the core interest rows: IDs, audit columns (WHO columns such as CREATED_BY, LAST_UPDATE_DATE), the interest type, primary/secondary interest codes, status code, description, lead reference, and the DFF attribute columns ATTRIBUTE_CATEGORY and ATTRIBUTE1–ATTRIBUTE15.
• AS_INTEREST_CODES_VL (VIEW) — joined twice (aliases PIC and SIC) to resolve the primary and secondary interest code IDs into their CODE values.
• AS_INTEREST_TYPES_VL (VIEW) — joined on INTEREST_TYPE_ID to return the INTEREST_TYPE description.
• AS_LOOKUPS (VIEW) — outer-joined on STATUS_CODE with LOOKUP_TYPE = 'INTEREST_STATUS' to yield the INTEREST_STATUS meaning.

All non-driving joins are outer joins (indicated by the (+) syntax), so classification rows are preserved even when a code, type, or status lookup is missing. The view is filtered implicitly by the constant predicate INT.INTEREST_USE_CODE = 'LEAD_CLASSIFICATION', restricting output to lead/opportunity classification interests.

Key Columns

• INTEREST_ID — primary key of the underlying interest record; the unique identifier for the classification.
• INTEREST_USE_CODE — always 'LEAD_CLASSIFICATION' for rows returned by this view.
• INTEREST_TYPE_ID / INTEREST_TYPE — the interest type identifier and its translated description.
• PRIMARY_INTEREST_CODE_ID / PRIMARY_INTEREST_CODE and SECONDARY_INTEREST_CODE_ID / SECONDARY_INTEREST_CODE — the ID and resolved code values for the primary and secondary classifications.
• STATUS_CODE / INTEREST_STATUS — the status lookup code and its meaning from AS_LOOKUPS.
• CUSTOMER_ID, ADDRESS_ID, CONTACT_ID, LEAD_ID — the party, location, contact, and lead context to which the classification applies.
• DESCRIPTION — free-text description of the interest.
• ATTRIBUTE_CATEGORY, ATTRIBUTE1–ATTRIBUTE15 — descriptive flexfield columns for customer-defined classification attributes.
• Audit columns — CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN, REQUEST_ID, PROGRAM_APPLICATION_ID, PROGRAM_ID, PROGRAM_UPDATE_DATE, plus ROW_ID.

Common Use Cases and Queries

Typical uses include lead/opportunity classification reporting, data validation for imports, and integration extracts that feed downstream CRM or analytics systems. A representative query returns all classifications for a given lead:

• SELECT interest_id, lead_id, interest_type, primary_interest_code, secondary_interest_code, interest_status FROM as_opp_classification_v WHERE lead_id = :lead_id;
• SELECT interest_status, COUNT(*) FROM as_opp_classification_v GROUP BY interest_status; — status distribution reporting.
• SELECT primary_interest_code, secondary_interest_code, COUNT(*) FROM as_opp_classification_v GROUP BY primary_interest_code, secondary_interest_code; — classification mix analysis.

Because all joins are outer, consumers should anticipate NULLs in INTEREST_TYPE, PRIMARY_INTEREST_CODE, SECONDARY_INTEREST_CODE, and INTEREST_STATUS. Queries should therefore use NVL or outer-aware filtering when lookups are expected to be populated.