Search Results get_member_role




Overview
Explore in AI Chat

Overview

AS_SALES_ORG_MANAGER_PVT is a private PL/SQL package owned by the APPS schema in Oracle E-Business Suite, defined with AUTHID CURRENT_USER. It provides a set of generic commodity APIs used across the Oracle Sales Management (OSM) subsystem. The package encapsulates the logic required to resolve sales organization structures: sales groups, sales representatives (salesreps), sales team members, reporting relationships, and the organizational roles that members hold within a sales force hierarchy. Because it is an internal (PVT) API rather than a public API, it is not intended for direct invocation by external or customer-developed integrations; instead it is consumed by other Oracle applications modules that need to navigate the sales organization model consistently. The package history traces its creation to July 1998, and the header reflects a maintenance revision from December 2002, confirming its role as a long-standing internal component of the sales foundation layer. It is referenced by 20 other packages, indicating broad internal reuse across the OSM and related sales application modules.

Key Procedures and Functions

  • GET_SALES_GROUPS — Returns one or more sales group records matching supplied criteria. Documented criteria include sales_group_id and sales_group_name. The procedure uses the AS_SALES_GROUP_PUB record and table types to receive input criteria and return the resulting sales group collection, along with standard API return status, message count, and message data outputs.
  • GET_CURRENTUSER — Resolves the currently logged-in user context so that downstream sales organization queries can be scoped to the active user session. It typically works in conjunction with FND_USER-based identity resolution.
  • GET_SALES_MEMBERS — Retrieves the members belonging to a sales group or sales force. This procedure supports the assembly of sales team rosters from the resource and group membership tables.
  • GET_SALES_RELATIONS — Returns the hierarchical or lateral relationships that exist between sales organization entities, such as manager-to-subordinate or salesrep-to-manager associations. The package defines relationship constants including G_NO_RELATION (0), G_FIRSTLINE_MANAGER (1), G_HIGHER_MANAGER (2), G_IDENTICAL_SALESFORCE (3), and G_SALESREP (4), which classify the nature of each returned relationship.
  • GET_MEMBER_ROLE — Returns the role assigned to a sales team member. This is the procedure most commonly sought by developers investigating sales role resolution; it draws on the JTF_RS role definition tables to map a resource to its functional role within the sales organization.

Tables Accessed

The package reads from several APPS-synonymed tables. FND_USER supplies application user identity information used by GET_CURRENTUSER. JTF_RS_GROUPS_DENORM and JTF_RS_GROUP_MEMBERS provide the denormalized group and group-membership data used by GET_SALES_GROUPS and GET_SALES_MEMBERS. JTF_RS_RESOURCE_EXTNS holds extended resource attributes for salesreps and other resources. JTF_RS_ROLES_B and JTF_RS_ROLE_RELATIONS supply role definitions and role-to-role relationships consumed by GET_MEMBER_ROLE and GET_SALES_RELATIONS. DBMS_SQL and DUAL are used for dynamic SQL execution and single-row expressions respectively. These tables collectively represent the Resource Manager (JTF_RS) and FND foundation model on which the sales organization hierarchy is built.

Usage Notes

As a private API, AS_SALES_ORG_MANAGER_PVT is invoked internally by Oracle Sales Management forms, concurrent programs, and higher-level public APIs rather than being called directly from customer extensions. When a user queries sales groups, retrieves sales team membership, or asks for the role a member plays, the calling OSM layer delegates to this package. Custom development should prefer the corresponding public API (such as AS_SALES_GROUP_PUB) and rely on AS_SALES_ORG_MANAGER_PVT only for diagnostic or read-only investigation. Because the package uses AUTHID CURRENT_USER, privileges are evaluated against the invoking schema, and callers must have appropriate access to the underlying JTF_RS and FND tables. Standard API conventions apply: x_return_status, x_msg_count, and x_msg_data should be checked after each call before consuming returned collections.