Search Results ast_salesrep_lov_v




Overview
Explore in AI Chat

Overview

AST_SALESREP_LOV_V is a seeded APPS-owned view in Oracle E-Business Suite Release 12.1.1 and 12.2.2, delivered as part of the AST (TeleSales) product family. Its name signals its principal purpose: it is a List of Values (LOV) source used by the TeleSales and related sales-application forms and pages. Rather than presenting a transactional fact, the view returns the set of sales representatives and sales group members that are currently valid and eligible to be selected as owners of sales-related entities. Oracle's own ETRM metadata documents the view with a status of VALID and an owner/schema of APPS, with base objects resolving to the JTF Resource Manager (JTF_RS) schema.

Underlying Base Objects

The view is defined over five documented base objects. JTF_RS_RESOURCE_EXTNS is the primary resource extension table, carrying the person-level attributes such as source name, phone and email. JTF_RS_GROUPS_VL supplies the translated sales-group header, and JTF_RS_GROUP_MEMBERS links resources to those groups. The role filtering is achieved through a correlated EXISTS subquery against JTF_RS_ROLE_RELATIONS and JTF_RS_ROLES_B. The join conditions require that the resource category be 'EMPLOYEE', that both resource and group start/end dates be active as of TRUNC(SYSDATE), that group-member delete_flag is not 'Y', and that an active role relation exists whose role MEMBER_FLAG is 'Y' and whose ROLE_TYPE_CODE is one of SALES, TELESALES, PRM or FIELDSALES. Because these predicates are embedded in the view definition, consumers automatically receive only currently valid, sales-eligible group members; no additional filtering is normally required.

Key Columns

The view exposes a deliberately LOV-friendly column set. The first three columns (IEU_LOV_COL1, IEU_LOV_COL2, IEU_LOV_COL3, IEU_LOV_COL4) are generic LOV display columns populated from selected expressions. OWNER_ID is constructed as a concatenation of RESOURCE_ID, GROUP_ID and SOURCE_ID and is the natural key value passed back by the LOV. SALES_GROUP_NAME and SALES_GROUP_ID identify the associated sales group, while SALESREP_FULL_NAME, SALESREP_LAST_NAME and SALESREP_FIRST_NAME carry the person's display name. EMPLOYEE_PERSON_ID maps to the underlying source/employee identifier, and SALESFORCE_ID identifies the resource record. WORK_TELEPHONE and EMAIL_ADDRESS expose the resource extension contact fields. The concatenated nature of OWNER_ID means downstream code frequently parses it to recover the individual resource and group identifiers.

Common Use Cases and Queries

The most common use is populating an LOV on sales forms and in custom concurrent programs that must resolve a sales-representative owner. A typical query selects the display and identifier columns while narrowing by group or name:

  • SELECT owner_id, salesrep_full_name, sales_group_name FROM apps.ast_salesrep_lov_v WHERE UPPER(salesrep_full_name) LIKE :p_name;
  • SELECT salesforce_id, employee_person_id, sales_group_id FROM apps.ast_salesrep_lov_v WHERE sales_group_id = :p_group_id;
  • SELECT owner_id FROM apps.ast_salesrep_lov_v WHERE salesforce_id = :p_resource_id;

Performance depends on indexed access to JTF_RS_RESOURCE_EXTNS and JTF_RS_ROLE_RELATIONS. Because the date and role predicates are baked in, the view is suitable for real-time LOV rendering and for integration extracts that feed downstream territory or commission logic, but it should not be used where historical or inactive representatives are required.