Results for “effective_to_date”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

PA_RBS_HEADERS_AMG_V is a reporting view owned by the APPS schema in Oracle E-Business Suite, within the Projects (PA) product family. It presents header-level information for a resource breakdown structure (RBS), including its effective dating range, owning business group, and usage designation. The view name suffix "AMG" indicates it is exposed through Oracle Application Object Library (AOL) for use as a value set source, most commonly as the underlying query for a descriptive flexfield or key flexfield lookup — in this case, the "Resource Breakdown Structure" list of values. Its primary role is therefore as an integration and reporting layer that joins RBS header data to the business group name so that an LOV can display a meaningful, human-readable record.

Underlying Base Objects

The view is defined over two documented base objects: PA_RBS_HEADERS_VL and PER_BUSINESS_GROUPS. Specifically, the PER_BUSINESS_GROUPS view is outer-joined to PA_RBS_HEADERS_VL on BUSINESS_GROUP_ID, so that the business group name is returned alongside the RBS header row. Because PA_RBS_HEADERS_VL is a translated ("_VL") view, its NAME and DESCRIPTION columns are returned in the session's language. PA_RBS_HEADERS_VL itself is a secure (row-level) view over the PA_RBS_HEADERS base table, meaning that access is filtered by business group and by the MO: Operating Unit or equivalent security profile applied to the querying responsibility. The AMG view inherits those security constraints, so a query executed under a given responsibility returns only the RBS headers available to that business group.

Key Columns

• RBS_HEADER_ID — Primary key. Uniquely identifies a resource breakdown structure header and is the value typically stored in a foreign key column on dependent tables.
• EFFECTIVE_FROM_DATE / EFFECTIVE_TO_DATE — The date range over which the RBS header is active. A NULL EFFECTIVE_TO_DATE conventionally indicates an open-ended record. RBS assignments made outside this range are not valid.
• BUSINESS_GROUP_ID — The business group (HR organization) that owns the header. This drives row-level security and operating unit context.
• BUSINESS_GROUP_NAME — The descriptive name of the business group, sourced from PER_BUSINESS_GROUPS. This is the name shown to end users in the LOV.
• USE_FOR_ALLOC_FLAG — Indicates whether this RBS may be used to drive allocations. This is the column most commonly searched by users and is the flag a functional consultant inspects when a resource breakdown structure is not appearing in an allocation or resource-assignment LOV.
• NAME — The RBS name, returned from the translated (_VL) view in the session language.
• DESCRIPTION — The free-text description of the RBS, also language-sensitive via the _VL view.

Common Use Cases and Queries

The most frequent use of this view is as the source query of a value set that drives an LOV for the Resource Breakdown Structure field, and for ad hoc reporting on which RBS structures are active and allocation-enabled. Because the AMG view already resolves the business group name and honors row-level security, it is preferable to querying PA_RBS_HEADERS_VL directly when a display value is required. A typical query joins the RBS header to resource assignment or project allocation tables for validation:

SELECT rbs_header_id,
       name,
       business_group_name,
       effective_from_date,
       effective_to_date,
       use_for_alloc_flag
  FROM apps.pa_rbs_headers_amg_v
 WHERE use_for_alloc_flag = 'Y'
   AND TRUNC(SYSDATE) BETWEEN NVL(effective_from_date, TRUNC(SYSDATE))
                          AND NVL(effective_to_date, TRUNC(SYSDATE))
 ORDER BY name;

This pattern answers the question "which RBS structures can I currently use for allocation within my operating unit?" A second common scenario validates a specific header before storing its ID on a downstream row, for example when populating a resource assignment or project allocation record.

Because USE_FOR_ALLOC_FLAG is a stored column rather than a derived value, checking it directly is both correct and efficient; attempting to infer allocation eligibility from date ranges alone will produce false positives. When troubleshooting a missing or unexpected LOV entry, confirm the effective dates, the value of USE_FOR_ALLOC_FLAG, and the business group context of the responsibility under which the query is run.