Search Results access_profile_rec_type

Overview

AS_ACCESS_PUB is a public PL/SQL API package owned by the APPS schema in Oracle E-Business Suite (documented against Release 12.1.1 and 12.2.2). Its stated purpose, taken directly from the package header, is to provide "a public API for manipulating access related info in OSM" (Oracle Sales Management / Oracle Sales). The package declares AUTHID CURRENT_USER, meaning its SQL executes under the privileges of the calling schema rather than the definer, a standard convention for EBS public APIs that must respect the caller's security context.

The package is the canonical programmatic entry point for creating and maintaining sales team access records and for evaluating whether a given user has visibility or modification rights over customers, leads, opportunities, persons, and organizations. It is classified as PUB (public), signalling that Oracle supports its direct invocation from customer code, unlike private/internal packages which may change without notice.

Key Procedures and Functions

The package exposes sixteen documented procedures and functions, which fall into three functional groups.

• Sales team maintenance: CREATE_SALESTEAM, UPDATE_SALESTEAM, and DELETE_SALESTEAM perform the DML lifecycle for sales team access records built from the sales_team_rec_type composite record.
• Validation: VALIDATE_ACCESSPROFILES verifies access profile data prior to or independent of a DML operation.
• Access predicate/check functions: HAS_VIEWCUSTOMERACCESS, HAS_UPDATECUSTOMERACCESS, HAS_VIEWLEADACCESS, HAS_UPDATELEADACCESS, HAS_VIEWOPPORTUNITYACCESS, HAS_UPDATEOPPORTUNITYACCESS, HAS_VIEWPERSONACCESS, and HAS_UPDATEPERSONACCESS return whether the current user holds view or update privileges on a specific entity. HAS_ORGANIZATIONACCESS, HAS_PERSONACCESS, HAS_LEADACCESS, and HAS_OPPORTUNITYACCESS provide the corresponding generic access checks.

Because ETRM documents only the procedure names, parameter lists must be obtained from the actual package specification before calling these APIs.

Tables Accessed

Two base tables are documented as referenced through APPS synonyms.

• AS_SALES_LEAD_CONTACTS: read and written by the sales team APIs. The sales_team_rec_type record mirrors this table's columns extensively, carrying identifiers such as access_id, customer_id, address_id, salesforce_id, person_id, lead_id, sales_group_id, partner identifiers, freeze and reassign flags, and the DFF attribute_category/attribute1-15 columns. This confirms AS_SALES_LEAD_CONTACTS is the primary DML target of CREATE_SALESTEAM, UPDATE_SALESTEAM, and DELETE_SALESTEAM.
• HZ_RELATIONSHIPS: the Trading Community Architecture relationship table, used to resolve person-to-organization and party hierarchies required by the HAS_*ACCESS functions when determining whether an access grant exists for the caller.

Usage Notes

In the context of the user's search for access_profile_rec_type, it is important to note that the documented composite type in this package is sales_team_rec_type, not access_profile_rec_type. The record is built around the sales team access model and is the structure passed to the sales team APIs. The access profile concept is represented in the package through VALIDATE_ACCESSPROFILES and the HAS_* access check functions.

Typical invocation occurs from Oracle Sales forms and concurrent programs, and from customer-written PL/SQL that needs to enforce the same access rules as the application. Because the package declares AUTHID CURRENT_USER and is referenced by 37 other packages, callers must be granted EXECUTE on APPS.AS_ACCESS_PUB and must not alter it. The downloadable_flag parameter on sales_team_rec_type is documented as obsolete and should be ignored in new code.