Search Results validate_notify_resp_id




Overview
Explore in AI Chat

Overview

APPS.BIS_RESPONSIBILITY_PVT is a private PL/SQL API package in Oracle E-Business Suite that provides the internal programmatic interface for managing Responsibility data within the Process Manufacturing (PMF) framework. The package body (source file BISVRSPB.pls) is owned by the APPS schema and classified as a private (PVT) API, meaning it is intended for internal consumption by other EBS packages and Oracle-delivered components rather than as a documented integration surface for customer extensions. Responsibilities in EBS define the menu, function, and data-security context in which a user operates; this package exposes the queries and validations needed to enumerate, retrieve, and validate responsibilities for a given user, with particular emphasis on identifying the correct Notification Responsibility used in Oracle Workflow notifications. The current body header references a 2006 revision and notes prior fixes relating to Workflow role lookup performance (bug 5140269) and general issues (bug 4363854), reflecting the package's long-standing role in PMF configuration pages.

Key Procedures and Functions

The package exposes eleven documented procedures and functions:

  • RETRIEVE_USER_RESPONSIBILITIES — Returns the set of responsibilities assignable to a specified user, honoring effective start and end dates on both the responsibility and the user-responsibility-group assignment.
  • RETRIEVE_ALL_RESPONSIBILITIES — Returns the complete list of responsibilities available for selection, independent of a specific user.
  • RETRIEVE_RESPONSIBILITY — Fetches a single responsibility record, typically to populate a detail or confirmation region.
  • VALIDATE_DEF_NOTIFY_RESP_ID — Validates the default notification responsibility identifier supplied by the caller.
  • RETRIEVE_NOTIFY_RESP_NAME — Returns the descriptive name associated with a notification responsibility identifier.
  • VALIDATE_NOTIFY_RESP_ID — The procedure most closely associated with the search term "validate_notify_resp_id"; confirms that a supplied notification responsibility identifier is valid and usable before it is persisted or passed to Workflow.
  • VALUE_ID_CONVERSION — Converts between internal identifiers and the display values used in PMF user interfaces.
  • DFR_VALUE_ID_CONVERSION — Performs the equivalent conversion for the dependent/default responsibility variant.
  • REMOVEDUPLICATES — Eliminates duplicate entries from a responsibility collection before it is returned to the caller.
  • GET_NOTIFY_RESP_AK_INFO — Retrieves alternate-key information for a notification responsibility, supporting lookup and validation logic.

All parameter lists are defined in the package specification and are not reproduced here; callers should reference the deployed specification in the target instance.

Tables Accessed

The documented data access path is through APPS synonyms. The primary query joins FND_RESPONSIBILITY_VL (the responsibility definition view) with FND_USER_RESP_GROUPS (the user-to-responsibility assignment table), filtering on effective dates and restricting to the 'W' version indicator for the responsibility definition. The package also references HTP (Oracle's HTML generation package) and PLITBLM, both of which are supplied PL/SQL utilities rather than application data tables. Historical comments in the source note that the Workflow role lookup was changed from WF_ROLES to WF_ROLE_LOV_VL to address performance on the Target Owner list of values in PMF pages.

Usage Notes

BIS_RESPONSIBILITY_PVT is invoked by PMF setup and administration pages, principally the target-owner and notification-responsibility list of values, and by the eight EBS packages documented as referencing it. It is not registered as a concurrent program entry point. Because it is a private API, custom code should avoid direct dependency; where responsibility validation is required, the supported approach is to call the corresponding public or workflow-facing API. The package returns status and error information through its OUT parameters rather than raising unhandled exceptions, so callers must inspect the returned status before relying on the returned collection. Behavior is consistent across EBS 12.1.1 and 12.2.2, as the underlying FND data model for responsibilities and user assignments is unchanged between those releases.