Search Results ast_sales_team_ptr_v




Overview
Explore in AI Chat

Overview

AST_SALES_TEAM_PTR_V is a TeleSales (AST) reporting view owned by the APPS schema. It presents sales team access records for partner organizations, joining TeleSales access rows to partner and customer master data, address information, lookup meanings, territory names, and partner profile attributes. In practice the view answers the question "which partner contacts on a sales team have access to which customers, and in what role." Because it exposes partner party identifiers, partner numbers, and partner-level classifications, it is frequently queried when older partner-number-based integrations must be reconciled against the 11i/12.x trading community model, where partner identity moved to the HZ_PARTIES.PARTY_ID / PARTY_NUMBER model. The view is valid and read-only; it carries no DML of its own and inherits the transactional columns of its driving access table.

Underlying Base Objects

The view is defined across the following documented objects: AS_ACCESSES_ALL (view), AS_LOOKUPS (view), FND_LOOKUP_VALUES (synonym), FND_TERRITORIES_VL (view), HZ_LOCATIONS (synonym), HZ_PARTIES (synonym), HZ_PARTY_SITES (synonym), PV_ATTRIBUTE_CODES_VL (view), PV_MATCH_V3_PUB (package), and PV_PARTNER_PROFILES (synonym). AS_ACCESSES_ALL supplies the core access rows and is the driving object; HZ_PARTY_SITES and HZ_LOCATIONS are joined with outer (+) operators so address data is optional. PV_PARTNER_PROFILES provides partner-level attributes such as PARTNER_LEVEL, and PV_MATCH_V3_PUB.GET_PARTNER_TYPES is invoked as a PL/SQL function to derive partner type. Two aliased instances of AS_LOOKUPS resolve the role and relationship codes, while FND_LOOKUP_VALUES resolves certificate level and FND_TERRITORIES_VL supplies the territory short name.

Key Columns

Common Use Cases and Queries

The most frequent requirement is locating partner parties by their number, which is why "partner_number" surfaces alongside this view; the number is exposed as CUST.PARTY_NUMBER. Typical uses include auditing sales team composition, reporting partner access to customers, and driving partner-facing integrations that still identify partners by number rather than ID.

  • Find access rows for a partner by number:
    SELECT access_id, partner_customer_id, party_name, party_number, salesforce_role_code, meaning FROM ast_sales_team_ptr_v WHERE party_number = :partner_number;
  • List team leaders with partner type and level:
    SELECT party_name, party_number, partnerType, partLevel, certLevel FROM ast_sales_team_ptr_v WHERE team_leader_flag = 'Y';
  • Report frozen or reassignment-pending access:
    SELECT access_id, party_number, freeze_date, reassign_reason FROM ast_sales_team_ptr_v WHERE freeze_flag = 'Y' OR reassign_flag = 'Y';
  • Join to HZ_PARTIES for additional partner attributes using CUST.PARTY_ID-equivalent identifiers, or group by territory_short_name for regional coverage reports.

Because the view calls PV_MATCH_V3_PUB.GET_PARTNER_TYPES and PV_ATTRIBUTE_CODES_VL per row via scalar subqueries, performance degrades on unfiltered scans; restrict queries by partner number, customer, or territory and ensure indexes on AS_ACCESSES_ALL and HZ_PARTIES are current. The view is intended for query and reporting only and should not be treated as an updateable entity.