Search Results resource_alias




Overview
Explore in AI Chat

Overview

PA_RESOURCE_LIST_V is an Oracle Applications (APPS) view in the Projects (PA) module that presents details about a resource list and the individual members associated with that list. A resource list in Oracle Projects is a reusable grouping of resources — such as employees, organizations, or other assignable entities — that can be applied when planning projects, defining project teams, or controlling assignment behavior. The view flattens the relationship between a resource list header (PA_RESOURCE_LISTS) and its member rows (PA_RESOURCE_LIST_MEMBERS), joining each member back to its canonical resource definition in PA_RESOURCES so that both the list-level and member-level attributes are available in a single queryable structure.

Because it is a view rather than a base table, PA_RESOURCE_LIST_V carries no independent data; it is a reporting and integration convenience layer owned by the APPS schema. Reports, concurrent programs, and interface logic that must resolve a resource alias to an actual resource, or that must enumerate the membership of a given resource list, can query this view instead of manually joining the three base objects. In Oracle EBS 12.1.1 and 12.2.2, the view remains a stable read-only construct, with status VALID in the data dictionary.

Underlying Base Objects

The view definition joins three principal sources:

  • PA_RESOURCE_LISTS (VIEW) — supplies the resource list header, providing the list name and the control flag that governs how the list may be used.
  • PA_RESOURCE_LIST_MEMBERS (SYNONYM) — supplies each member row, including the member's alias and labor-tracking flag, and the foreign key to the parent list.
  • PA_RESOURCES (SYNONYM) — supplies the authoritative resource name for each resource identifier referenced by a member row.

The documented ETRM metadata additionally records references to FND_PROFILE (PACKAGE) and PA_CROSS_BUSINESS_GRP (PACKAGE), which reflect the standard Oracle Projects security and multi-organization constructs invoked when these objects are accessed through supported APIs or when the underlying base objects are queried under business-group and profile-option restrictions. The join predicates are equality-based: RLM.RESOURCE_LIST_ID = RL.RESOURCE_LIST_ID and RLM.RESOURCE_ID = R.RESOURCE_ID.

Key Columns

  • RESOURCE_LIST_ID — unique identifier of the resource list (header).
  • RESOURCE_LIST_NAME — the descriptive name of the resource list, sourced from PA_RESOURCE_LISTS.NAME.
  • RESOURCE_LIST_MEMBER_ID — unique identifier of the individual member row within the list.
  • RESOURCE_ID — identifier of the underlying resource, joinable to PA_RESOURCES.
  • RESOURCE_ALIAS — the alternate name (alias) by which the member is known within the list; this is the column most relevant to alias-based lookups.
  • RESOURCE_NAME — the canonical resource name from PA_RESOURCES.NAME.
  • RESOURCE_TRACK_AS_LABOR_FLAG — indicates whether the member is tracked as labor for cost and utilization purposes.
  • RESOURCE_CONTROL_FLAG — list-level flag controlling usage or enforcement behavior of the list.

Common Use Cases and Queries

A frequent requirement is resolving a member alias to its resource, since aliases are user-facing identifiers that must be translated to real resource records during interface or import processing. Another common scenario is enumerating all members of a given resource list for validation or reporting.

Sample query resolving an alias across all lists:

  • SELECT resource_list_id, resource_list_name, resource_list_member_id, resource_id, resource_alias, resource_name, resource_track_as_labor_flag, resource_control_flag FROM apps.pa_resource_list_v WHERE resource_alias = :p_alias;

Sample query listing membership for a specific list:

  • SELECT resource_list_member_id, resource_id, resource_alias, resource_name, resource_track_as_labor_flag FROM apps.pa_resource_list_v WHERE resource_list_id = :p_list_id ORDER BY resource_alias;

Note that the view does not itself apply organization or business-group filtering beyond what the base objects and their security packages impose; callers requiring cross-business-group enforcement should rely on the standard Projects security routines (for example, through PA_CROSS_BUSINESS_GRP and FND_PROFILE-based access) rather than assuming the view filters rows. Because it is a read-only view, no DML should be issued against PA_RESOURCE_LIST_V; maintenance of resource lists and members must be performed through the supported Oracle Projects forms or APIs.