Search Results oki_role_maps

Overview

The OKI_ROLE_MAPS table resides in the OKI schema, which supports the Contracts Intelligence module (OKI) within Oracle E-Business Suite 12.1.1 and 12.2.2. Its documented purpose is to map contract roles and contact roles to specific reporting values. In practice, this table acts as a configuration and lookup bridge between the role assignments recorded against contracts or contacts and the standardized codes consumed by Contracts Intelligence reporting, analytics, and extraction programs. It allows implementers to control how role information is translated into reportable categories without altering the underlying transactional role data.

From a Data Vault modeling perspective, the metadata classifies OKI_ROLE_MAPS as a standalone object — it carries neither inbound nor outbound foreign keys to other OKI transactional tables, aside from a reference to FND_SECURITY_GROUPS. This suggests it functions as a reference or configuration entity rather than a hub, link, or satellite in a strict Data Vault sense. In a dimensional model it would most naturally resolve to a small reference dimension or lookup table used to decode role usage values.

Key Information Stored

The table is defined with eleven documented columns. The most significant are described below.

• ROLE_USE — Part of the composite primary key; identifies the role usage context that the mapping applies to (for example, whether the mapping targets a contract role or a contact role).
• SCS_CODE — The second component of the composite primary key; holds the source or reporting code that pairs with ROLE_USE to uniquely identify a mapping row.
• RLE_CODE — The role code assigned to the mapping; represents the contract or contact role being translated into a reporting value.
• CRO_CODE — The corresponding reporting value or target code that the role is mapped to for reporting purposes.
• OBJECT_VERSION_NUMBER — Optimistic locking column used by the AOL/ORM framework to detect concurrent updates.
• SECURITY_GROUP_ID — Foreign key to FND_SECURITY_GROUPS, controlling which security group owns the row and therefore which users or responsibilities can see it.
• Audit columns — CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, and LAST_UPDATE_LOGIN capture standard who/when audit information maintained automatically by the EBS framework.

The surrogate primary key is OKI_ROLE_MAPS_PK, defined over (ROLE_USE, SCS_CODE). A unique index, OKI_ROLE_MAPS_U1, exists on the same column pair (ROLE_USE, SCS_CODE), confirming this combination as the documented business-key candidate. Because the primary key is a natural composite rather than a system-generated sequence, applications must supply both ROLE_USE and SCS_CODE when inserting mapping rows.

Common Use Cases and Queries

Typical usage centers on decoding and validating role-to-reporting mappings. A common query retrieves all mappings for a given role usage context:

• SELECT role_use, scs_code, rle_code, cro_code FROM oki_role_maps WHERE role_use = :p_role_use;
• Join to FND_SECURITY_GROUPS on SECURITY_GROUP_ID to restrict results to the caller's security group: SELECT m.rle_code, m.cro_code FROM oki_role_maps m, fnd_security_groups g WHERE m.security_group_id = g.security_group_id AND g.security_group_id = :p_group;
• Reporting extracts use CRO_CODE as the decoded value for role analytics, allowing contract role counts or contact role distributions to be grouped by reporting category rather than raw role code.
• Data validation routines verify that every role assigned on a contract or contact has a corresponding mapping row, flagging unmapped roles before report generation.

Related Objects

Given the standalone classification, the documented dependencies are limited. The principal relationships are:

• FND_SECURITY_GROUPS — referenced via OKI_ROLE_MAPS.SECURITY_GROUP_ID, governing row-level visibility.
• OKI_ROLE_MAPS_PK / OKI_ROLE_MAPS_U1 — the primary key constraint and unique index enforcing uniqueness of (ROLE_USE, SCS_CODE).
• Other OKI Contracts Intelligence role and contract objects that consume the RLE_CODE and CRO_CODE values at report runtime; these are logical dependents rather than documented foreign-key relationships.
• Standard EBS audit and concurrency infrastructure (CREATED_BY/LAST_UPDATED_BY referencing FND_USER) that maintains the audit columns.

Because the metadata records no foreign keys from other tables back to OKI_ROLE_MAPS, integration is driven primarily by shared role and reporting code values rather than enforced referential constraints.