Search Results assign_to_full_name

Overview

The view AS_SALES_LEADS_LISTS_V belongs to the Oracle EBS Sales Foundation (AS) module and is documented as the "Sales Leads List View." It presents a denormalized, reporting-friendly projection of sales lead data maintained by the Sales Foundation lead-capture and lead-qualification functionality. Rather than requiring consumers to join the base lead entity to multiple lookup, person, and reference tables, this view pre-resolves descriptive attributes — statuses, contact roles, channels, budget statuses, decision timeframes, and lead ranks — into human-readable meanings.

The view plays a significant role in reporting and integration because it shields downstream consumers (custom reports, Discoverer workbooks, OBIEE extracts, interface programs, and outbound integration feeds) from the coding schemes stored in the base tables. The presence of columns such as CREATED_BY_FULL_NAME, ASSIGN_TO_FULL_NAME, STATUS, CONTACT_ROLE, and CHANNEL indicates that the view is intended for end-user-facing queries rather than operational DML, since all expressions are read-only derivations of the underlying lead rows.

Underlying Base Objects

The ETRM metadata records no explicitly documented base objects for this view, and the "Implementation/DBA Data" note states it is "Not implemented in this database" — meaning the view definition exists in the ETRM reference but may not be deployed in every environment. The view text, however, makes the principal base object evident: the sales lead entity, aliased as LEAD, which corresponds to the Sales Foundation leads table (AS_SALES_LEADS family). Supporting objects referenced in the definition include the person tables reached through PER1 and PER2 aliases (FND/PER person and assignment data used to resolve creator and assignee names), the generic lookup view FND_LOOKUPS (represented as LOOK4 for the channel meaning), and the standard Oracle lookup function GET_MEANING.

Because GET_MEANING is invoked repeatedly, the view is implicitly dependent on the lookup types SALES_LEAD_STATUS, LEAD_CONTACT_ROLE, BUDGET_STATUS, DECISION_TIMEFRAME, and SALES_LEAD_RANK. Any customization of these lookup types will be reflected automatically in the view output, since the meanings are resolved at query time rather than stored.

Key Columns

• SALES_LEAD_ID, LEAD_NUMBER — primary identifier and user-visible lead number.
• STATUS_CODE / STATUS — the coded status and its lookup-resolved meaning via GET_MEANING('SALES_LEAD_STATUS', ...).
• CONTACT_ROLE_CODE / CONTACT_ROLE — coded and decoded contact role from the LEAD_CONTACT_ROLE lookup.
• CHANNEL_CODE / CHANNEL — channel code and its meaning, resolved through the lookup alias LOOK4.
• BUDGET_STATUS_CODE / BUDGET_STATUS and BUDGET_AMOUNT, CURRENCY_CODE — budget qualification attributes.
• DECISION_TIMEFRAME_CODE / DECISION_TIMEFRAME and LEAD_RANK_CODE / RANK — qualification and prioritization attributes.
• ASSIGN_TO_PERSON_ID, ASSIGN_TO_FULL_NAME, ASSIGN_DATE, ACCEPT_FLAG — assignment and acceptance tracking.
• CREATED_BY_FULL_NAME (and first/last name components) plus the standard WHO columns (CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY) — audit and ownership attribution.
• ATTRIBUTE_CATEGORY and ATTRIBUTE1–ATTRIBUTE15 — descriptive flexfield segments for customer extensions.

Common Use Cases and Queries

Typical usage centers on lead pipeline reporting, assignment monitoring, and integration extracts. A representative query counts leads by decoded status:

SELECT STATUS, COUNT(*) FROM AS_SALES_LEADS_LISTS_V GROUP BY STATUS;

Assignment monitoring can list open leads with their assignees and channels:

SELECT LEAD_NUMBER, ASSIGN_TO_FULL_NAME, CHANNEL, RANK, BUDGET_AMOUNT FROM AS_SALES_LEADS_LISTS_V WHERE ACCEPT_FLAG = 'N';

Integration programs frequently select the decoded columns to populate downstream CRM or marketing systems, while flexfield-based queries filter on ATTRIBUTE_CATEGORY and specific ATTRIBUTEn segments. Because the decoded values depend on GET_MEANING, queries returning large result sets should account for the lookup function overhead, and any report relying on this view should verify the view is actually deployed in the target instance given the "Not implemented" note.