Search Results as_access_pub_w2

Overview

The APPS.AS_ACCESS_PUB_W2 package body is a public access-control utility belonging to the Oracle Sales Foundation (AS) module in Oracle E-Business Suite. Its documented status is VALID under the APPS schema in both EBS 12.1.1 and 12.2.2. Functionally, it is one of the companion "access" packages that encapsulate the security-checking logic used throughout the Sales and TeleSales (Field Sales) modules, exposing boolean-style predicates that determine whether a given user is permitted to view or update a specific sales entity.

The package is classified as an "OTHER" API under ETRM. It is a wrapper-style public package: it does not itself contain the underlying business rules but delegates to the core AS_ACCESS_PUB package, which is listed as its primary dependency. It also depends on FND_API (the Oracle Application Object Library API, indicating standardized error-handling and message conventions) and the SYS STANDARD package. Notably, AS_ACCESS_PUB_W2 is not referenced by any other database object, marking it as a terminal (leaf) package in the dependency chain.

Key Procedures and Functions

The ETRM metadata documents eight procedures/functions within this package body, all of which are access-predicate helpers:

• HAS_VIEWPERSONACCESS — Determines whether the current user has view (read) privileges on a person record.
• HAS_UPDATEPERSONACCESS — Determines whether the current user has update (write) privileges on a person record.
• HAS_PERSONACCESS — A consolidated or general person-access check that likely encompasses both view and update evaluation paths.
• HAS_VIEWLEADACCESS — Determines whether the current user may view a given sales lead.
• HAS_LEADACCESS — General lead-access predicate covering the lead entity.
• HAS_VIEWOPPORTUNITYACCESS — Determines whether the current user may view a given sales opportunity.
• HAS_OPPORTUNITYACCESS — General opportunity-access predicate.
• HAS_ORGANIZATIONACCESS — Determines whether the current user has access to a given organization (operating unit / sales organization context), which typically drives the visibility scope of the preceding personnel, lead, and opportunity checks.

The consistent HAS_* naming pattern and its pairing into view/general variants indicates a boolean-returning API used by UI construction logic to enable or disable regions, buttons, and query results.

Tables Accessed

The documented metadata records no directly referenced tables for this package body. Because it functions as a thin wrapper that delegates to AS_ACCESS_PUB, all table access is performed indirectly through that parent package. The underlying access rules in the Sales Foundation typically consult the Sales Force / resource-assignment and territory-access tables (such as AS_ACCESSES_ALL, AS_ACCESS_SETS, and related JTF resource tables) to resolve whether a user’s sales group, territory, or resource assignment grants visibility to the requested record.

Usage Notes

AS_ACCESS_PUB_W2 is a public API intended to be invoked from Sales Foundation forms, JSP/HTML-based TeleSales pages, and custom PL/SQL code that needs to enforce the same access rules as the standard Oracle Sales application. Typical invocation scenarios include:

• Calling HAS_VIEWOPPORTUNITYACCESS or HAS_VIEWLEADACCESS before rendering a record in an opportunity or lead results list.
• Calling HAS_UPDATEPERSONACCESS to gate an Update form or button in the person/contact management screens.
• Combining HAS_ORGANIZATIONACCESS with the entity-level predicates to enforce the correct operating-unit security scope in multi-org deployments.

Because the package is not referenced by any other database object, it is safe to treat it as an entry-point wrapper: developers should call it rather than the internal logic directly, and should expect the underlying access semantics—not the wrapper itself—to be modified when security configuration changes. In R12.2.2 online patching, the body is recompiled into the editioned APPS schema, so any custom callers should qualify calls with the standard APPS schema namespace and avoid hard-coding the package body’s internal logic.