Search Results bsc_user_responsibility_v

Overview

BSC_USER_RESPONSIBILITY_V is a seed data and reporting view owned by the APPS schema, shipped as part of the Oracle Balanced Scorecard (BSC) product family. In Oracle EBS 12.1.1 and 12.2.2 it is delivered in VALID status and forms part of the standard APPS data dictionary. The view presents one row for each active combination of an EBS user and a Balanced Scorecard responsibility, effectively enumerating the population of users who are entitled to operate within the Balanced Scorecard application. Rather than exposing descriptive attributes of users or responsibilities, it acts as a scoped identity list: a narrow projection of two key columns, USER_ID and RESPONSIBILITY_ID. Its role is to provide downstream BSC programs, concurrent requests, and personalization logic with a pre-filtered set of user/responsibility pairs belonging exclusively to the Balanced Scorecard application, without requiring each consumer to re-derive the same multi-table join and date logic.

Underlying Base Objects

The view is defined over three Oracle EBS foundation objects. FND_USER (aliased FU) supplies the user identity and the user-level effective dating. FND_RESPONSIBILITY_VL (aliased FR) supplies the responsibility definition, including the owning application and the responsibility-level effective dating. FND_USER_RESP_GROUPS (aliased FUR) is the intersection table linking users to responsibilities, and it contributes both the USER_ID and RESPONSIBILITY_ID values projected by the view.

The join is deliberately explicit. FU.USER_ID = FUR.USER_ID ties the user record to its assignment. FR.RESPONSIBILITY_ID = FUR.RESPONSIBILITY_ID ties the assignment to the responsibility definition. A third predicate, FR.APPLICATION_ID = FUR.RESPONSIBILITY_APPLICATION_ID, disambiguates the responsibility because responsibility identifiers are only unique within an application. The final scope filter, FR.APPLICATION_ID = 271, restricts the result set to the Balanced Scorecard application. Note that the view does not reference FND_APPLICATION or FND_APPLICATION_VL; application 271 is hard-coded rather than resolved by name.

Key Columns

• USER_ID — The numeric primary key of the EBS user from FND_USER, propagated through FND_USER_RESP_GROUPS. This is a foreign key to FND_USER.USER_ID and is the column most commonly used to drive joins to user-facing tables such as FND_USER, PER_PEOPLE_F, or WF_LOCAL_ROLES.
• RESPONSIBILITY_ID — The numeric identifier of the responsibility from FND_RESPONSIBILITY_VL, propagated through FND_USER_RESP_GROUPS. It is unique only within an owning application, so it should be qualified by application whenever used outside the pre-filtered BSC context.

No descriptive columns (user name, responsibility name, application name) are exposed; consumers requiring those attributes must join to the underlying base tables themselves.

Common Use Cases and Queries

Typical uses include identifying the seeded or provisioned Balanced Scorecard user base, validating responsibility provisioning during implementations or upgrades, feeding entitlement checks in BSC customization, and reconciling assignments after a user data migration.

• Retrieve the raw user/responsibility pairs:

  SELECT user_id, responsibility_id FROM apps.bsc_user_responsibility_v;

• Resolve user names for reporting:

  SELECT v.user_id, u.user_name, u.start_date, u.end_date FROM apps.bsc_user_responsibility_v v, apps.fnd_user u WHERE u.user_id = v.user_id;

• Resolve responsibility names per assignment:

  SELECT v.user_id, r.responsibility_name FROM apps.bsc_user_responsibility_v v, apps.fnd_responsibility_vl r WHERE r.responsibility_id = v.responsibility_id AND r.application_id = 271;

• Count assigned users for capacity or licensing analysis:

  SELECT COUNT(DISTINCT user_id) FROM apps.bsc_user_responsibility_v;

Because the view embeds SYSDATE-based effective dating on both FND_USER and FND_RESPONSIBILITY_VL, results reflect only assignments that are currently active. Historical or future-dated entitlements are excluded and require querying FND_USER_RESP_GROUPS directly alongside the base user and responsibility tables. As with all APPS dictionary views, query access is governed by the standard APPS schema and responsibility-based security model.