Results for “as_sales_team_v”

22 results




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

Overview

AS_SALES_TEAM_V is a reporting view in the Oracle E-Business Suite Sales Foundation (AS) module that consolidates sales team assignment data into a single denormalized result set. Its documented description is simply "Sales team view," reflecting its purpose: to present the membership of sales teams (also known as salesforce teams) together with the descriptive attributes needed by forms, reports, and integration consumers without requiring callers to join the underlying transactional and reference tables themselves.

The view is defined over AS_ACCESSES_ALL, the principal repository of sales team and access assignment records, and enriches those rows with employee details from PER_PEOPLE_F, customer and address descriptions, resource group membership from the JTF_RS tables, and decoded lookup meanings from AS_LOOKUPS. It also exposes the standard EBS WHO columns (CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN, REQUEST_ID, PROGRAM_ID, PROGRAM_APPLICATION_ID, PROGRAM_UPDATE_DATE), making it suitable for audit-oriented and concurrent-program-driven extracts.

The ETRM metadata records the view as "Not implemented in this database" for the referenced environment and does not document an owner or referenced base objects, indicating the excerpt was captured from a partial or non-production instance. Nonetheless, the view text confirms its dependency set and its role as a read-only projection used by Sales Foundation functionality and by extension reporting.

Underlying Base Objects

Although the metadata lists no documented base objects, the view text identifies the following underlying objects:

All joins to the descriptive objects are outer joins (marked with the Oracle (+) operator), so a team assignment row is retained even when the corresponding employee, customer, address, or lookup record is absent.

Key Columns

  • ACCESS_ID, ACCESS_TYPE — the assignment identifier and its decoded type meaning.
  • PERSON_ID, FIRST_NAME, LAST_NAME, EMAIL_ADDRESS, WORK_TELEPHONE — the team member and contact information.
  • CUSTOMER_ID, CUSTOMER_NAME, CUSTOMER_NUMBER, ADDRESS_ID, CITY — the customer and address context of the assignment.
  • PARTNER_CUSTOMER_ID, PARTNER_ADDRESS_ID, PARTNER_CONT_PARTY_ID — the partner (channel) side of the team relationship.
  • TEAM_LEADER_FLAG, FREEZE_FLAG, REASSIGN_FLAG, FREEZE_DATE, REASSIGN_REASON — team governance and reassignment state.
  • GROUP_ID, GROUP_NAME — the resource group to which the member belongs.
  • SALESFORCE_ROLE_CODE, SALESFORCE_RELATIONSHIP_CODE and their decoded MEANING columns — role and relationship classification.
  • LEAD_ID, CREATED_PERSON_ID, SALESFORCE_ID, DOWNLOADABLE_FLAG — lead linkage and synchronization attributes.
  • ATTRIBUTE_CATEGORY and ATTRIBUTE1–15 — the standard EBS descriptive flexfield columns.

Common Use Cases and Queries

Typical consumers include sales team maintenance forms, territory and assignment reports, and integration extracts that publish sales team membership to external CRM or workflow systems such as a service portal's team-structure change process. A basic listing of active team members for a customer can be written as:

  • SELECT cust.customer_number, acc.person_id, hremp.first_name, hremp.last_name, hremp.email_address, aslkp1.meaning access_type, acc.team_leader_flag
  • FROM as_sales_team_v acc, per_people_f hremp
  • WHERE acc.person_id = hremp.person_id
  • AND acc.customer_id = :p_customer_id
  • AND TRUNC(SYSDATE) BETWEEN hremp.effective_start_date AND hremp.effective_end_date;

To identify team leaders for reassignment or governance review, filter on team_leader_flag = 'Y'. To assemble a complete team roster with group and role context, select GROUP_NAME, the decoded SALESFORCE_ROLE_CODE meaning, and the flexfield attributes. Because the view already performs the outer joins to PER_PEOPLE_F and the JTF resource tables, callers should avoid redundant joins to those objects and should apply the date-effectivity predicate against PER_PEOPLE_F only when querying HRM directly.