Search Results create_salesteam

Overview

AS_ACCESS_PVT is a private PL/SQL package in the APPS schema that centralizes the access-control and sales-team security logic for the Oracle Sales (AS) product family in Oracle E-Business Suite 12.1.1 and 12.2.2. Its central business purpose is to determine whether a given user, resource, or sales-team member may view or modify leads, opportunities, and customer records, and to maintain the composition of sales teams against those records. As a PVT-classified package it is not a published API; it is the internal implementation layer that supports the public AS_ACCESS_PUB package and other private packages. The ETRM metadata records AS_ACCESS_PVT as VALID in the APPS schema, with the package body present, and identifies AS_ACCESS_PUB, FND_API, and the SYS STANDARD package as its principal dependencies. It is referenced by six other packages — AST_ACCESS, AS_ACCESS_CUHK, AS_ACCESS_PUB, itself (recursive), AS_OPP_HEADER_PVT, AS_SALES_LEADS_PVT, and AS_SALES_LEAD_ENGINE_PVT — confirming that it sits beneath the transactional lead and opportunity APIs rather than being called directly by end users. The object is documented with twelve procedures or functions, split between sales-team maintenance routines and boolean access-predicate functions.

Key Procedures and Functions

The documented callable set falls into two functional groups:

• Sales-team maintenance: CREATE_SALESTEAM, DELETE_SALESTEAM, UPDATE_SALESTEAM, and VALIDATE_SALESTEAMITEMS. These routines create, remove, modify, and validate the membership records that constitute a sales team on a lead or opportunity.
• Access predicates: HAS_VIEWCUSTOMERACCESS, HAS_UPDATECUSTOMERACCESS, HAS_UPDATELEADACCESS, HAS_UPDATEOPPORTUNITYACCESS, HAS_LEADOWNERACCESS, HAS_OPPOWNERACCESS, HAS_VIEWLEADACCESS, and HAS_VIEWOPPORTUNITYACCESS. These functions return access determinations for the calling context — separating view versus update rights, lead versus opportunity objects, owner-based rights, and customer-level rights.

The public AS_ACCESS_PUB package exposes this functionality to callers, while the maintenance routines are invoked internally by the lead and opportunity private APIs. Parameter lists are not reproduced here; signatures should be taken from the package specification returned by the ETRM "show dependent code" listing.

Tables Accessed

Through APPS synonyms the package reads and writes the following tables:

• Sales team and lead data: AS_SALES_LEADS, AS_LEADS_ALL, AS_SALES_LEAD_RANKS_B, and AS_STATUSES_B — used to resolve the lead record, its team members, ranking, and current status.
• Resource and role model: JTF_RS_GROUPS_B, JTF_RS_GROUP_MEMBERS, JTF_RS_RESOURCE_EXTNS, JTF_RS_ROLES_B, and JTF_RS_ROLE_RELATIONS — the Resource Manager tables that define groups, roles, and resource extensions used to evaluate team membership and access rights.
• Party and person data: HZ_PARTIES, HZ_RELATIONSHIPS, and PER_ALL_PEOPLE_F — the Trading Community and HR sources providing customer, relationship, and person attributes.
• Partner data: PV_PARTNER_PROFILES — used when channel or partner-based access rules apply.

These reads support the access predicates; writes are confined to the sales-team maintenance procedures that populate and clear team member rows on the source records.

Usage Notes

AS_ACCESS_PVT is an internal dependency rather than a public entry point. It is normally invoked indirectly: end-user actions in the Oracle Sales forms for leads and opportunities, and calls made by AS_ACCESS_PUB, AST_ACCESS, AS_ACCESS_CUHK, AS_OPP_HEADER_PVT, AS_SALES_LEADS_PVT, and AS_SALES_LEAD_ENGINE_PVT. Concurrent programs or workflow that manipulate lead and opportunity records will reach this package through those private and public APIs. Customizations should call AS_ACCESS_PUB rather than AS_ACCESS_PVT, because the private package is subject to change without notice between releases and patches. Where custom code must replicate access checks, the HAS_* predicate functions are the appropriate documented behaviours to mirror. The package is dependent on FND_API, so callers must be within an initialized EBS session context with a valid application and responsibility.