Results for “ibe_msite_resps_b”

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

Overview

IBE_MSITE_RESPS_B is a base table in the IBE (iStore) product schema of Oracle E-Business Suite, present in both 12.1.1 and 12.2.2. It defines the responsibilities that are authorized for use by a Specialty Store, which is the iStore construct representing a partner, reseller, or specialty storefront hosted on the same or a separate Oracle EBS instance. Each row associates a single iStore site with a single Oracle Applications responsibility, optionally qualified by a security group and a group code.

In the EBS architecture the table functions as a configuration and security assignment object rather than a transactional entity. It governs which application menus and self-service functions a given storefront's administrative users may access when the Specialty Store feature is in use. The table carries standard Oracle WHO columns, a multitenancy/security column, and effective-dating columns, and it participates in a translated pair with IBE_MSITE_RESPS_TL for language-dependent descriptive attributes.

From a Data Vault modeling perspective (a heuristic classification derived from the foreign key structure), the object is satellite-leaning. It holds descriptive and qualifying attributes — start and end dates, sort order, group code — that describe the relationship between a storefront and a responsibility, rather than acting as an independent business hub or a pure association link.

Key Information Stored

The table documents fifteen columns in the 12.2.2 physical schema. The most significant are as follows.

• MSITE_RESP_ID — the surrogate primary key, enforced by the IBE_MSITE_RESPS_B_PK constraint. It uniquely identifies each storefront-to-responsibility assignment.
• MSITE_ID — the foreign key to IBE_MSITES_B identifying the Specialty Store site to which the assignment belongs.
• RESPONSIBILITY_ID and APPLICATION_ID — together they form the foreign key into FND_RESPONSIBILITY, naming the responsibility being granted and its owning application.
• SECURITY_GROUP_ID — references FND_SECURITY_GROUPS and controls the security grouping under which the responsibility is visible.
• GROUP_CODE — a grouping qualifier that distinguishes assignment sets; it appears in both business-key candidate indexes.
• START_DATE_ACTIVE and END_DATE_ACTIVE — the effective dating range of the assignment, allowing responsibilities to be granted and revoked over time without deleting the row.
• SORT_ORDER — controls the display sequence of responsibilities where the storefront presents them in a list.
• OBJECT_VERSION_NUMBER and the WHO audit columns (CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN) — support optimistic locking and audit trail requirements.

Two unique indexes define business-key candidates. IBE_MSITE_RESPS_B_U1 covers (MSITE_RESP_ID, GROUP_CODE), and IBE_MSITE_RESPS_B_U2 covers (MSITE_ID, RESPONSIBILITY_ID, GROUP_CODE, APPLICATION_ID). The latter is the meaningful natural key: a given responsibility may be assigned to a storefront only once per group code and application.

Common Use Cases and Queries

Typical use cases include auditing which responsibilities a specialty storefront can exercise, verifying effective-dated assignments at a point in time, and diagnosing access problems reported by storefront administrators.

A basic listing of active responsibilities for a storefront:

SELECT r.msite_id, r.responsibility_id, r.application_id,
       r.group_code, r.start_date_active, r.end_date_active
FROM   ibe_msite_resps_b r
WHERE  r.msite_id = :msite_id
AND    TRUNC(SYSDATE) BETWEEN NVL(r.start_date_active, SYSDATE)
                          AND NVL(r.end_date_active, SYSDATE);

Joining to FND_RESPONSIBILITY resolves the responsibility name and application, while joining to IBE_MSITE_RESPS_TL through MSITE_RESP_ID supplies translated display text. A common reconciliation query compares assignments against the FND_RESPONSIBILITY catalog to detect orphaned or misapplied grants. Reporting extracts typically join to IBE_MSITES_B for site identity and to FND_SECURITY_GROUPS for group context.

Related Objects

• IBE_MSITES_B — the parent storefront definition; joined on IBE_MSITE_RESPS_B.MSITE_ID = IBE_MSITES_B.MSITE_ID.
• FND_RESPONSIBILITY — the responsibility catalog; joined on RESPONSIBILITY_ID and APPLICATION_ID.
• FND_SECURITY_GROUPS — the security group reference, joined on SECURITY_GROUP_ID.
• IBE_MSITE_RESPS_TL — the translated child table; joined on MSITE_RESP_ID = IBE_MSITE_RESPS_TL.MSITE_RESP_ID.

These four objects constitute the immediate dependency boundary of IBE_MSITE_RESPS_B. Any change to a storefront's responsibility grants should be propagated through the iStore administration APIs rather than by direct DML, so that the translated table and audit columns remain consistent.