Results for “iby_instrholder”

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

Overview

IBY_INSTRHOLDER is a table within the IBY (Payments) module of Oracle E-Business Suite, valid in both 12.1.1 and 12.2.2. It stores information about the holder of a payment instrument. The documentation describes the core purpose succinctly: a payment instrument can be held by different users, payees, or payers, and this table captures that ownership relationship. In practice, IBY_INSTRHOLDER acts as the association point between an instrument (such as a credit card or a bank account) and the party that holds or owns it, allowing the Payments module to resolve which party controls, uses, or is associated with a given instrument.

From a Data Vault modeling perspective, the supplied metadata yields a heuristic classification of link. This is a modeling suggestion rather than an EBS-imposed construct: the table's role as an intersection between instruments and their owners aligns naturally with a link structure connecting instrument and owner hubs. Implementers designing downstream analytical or integration models may treat IBY_INSTRHOLDER accordingly.

Key Information Stored

The documented physical schema for IBY_INSTRHOLDER in 12.2.2 contains 13 columns, owned by the IBY schema. The most important columns are:

• INSTRID — the instrument identifier, identifying the specific credit card or bank account. This column participates in the unique index IBY_INSTRHOLDER_INSTRID_U1, making it a business-key candidate.
• INSTRTYPE — the instrument type, distinguishing the class of instrument referenced by INSTRID.
• OWNERID — the identifier of the holder (user, payee, or payer) associated with the instrument.
• OWNERTYPE — the type of the owning party, qualifying the value held in OWNERID.
• OWNERADDRESSID — the address identifier associated with the instrument holder.
• ACTIVESTATUS — indicates whether the holder relationship is currently active.
• SECURITY_GROUP_ID — the security group for multi-org / data access control, with a foreign key to FND_SECURITY_GROUPS.
• OBJECT_VERSION_NUMBER — the optimistic locking version column used by the Oracle Applications framework.
• Audit columns: LAST_UPDATE_DATE, LAST_UPDATED_BY, CREATION_DATE, CREATED_BY, LAST_UPDATE_LOGIN — standard WHO columns tracking insert and update history.

The primary key is documented as IBY_INSTRHOLDER_UK, defined over (INSTRID, INSTRTYPE, OWNERID, OWNERTYPE). Note that the entity's unique index, IBY_INSTRHOLDER_INSTRID_U1, is defined on INSTRID alone. This table does not employ a single surrogate numeric primary key; the composite business key of instrument plus owner serves as the identifying key.

Common Use Cases and Queries

Typical use cases center on resolving which holder is associated with a given payment instrument. A frequent reporting pattern joins IBY_INSTRHOLDER to the instrument tables to enrich instrument records with owner information. For example, to list all holders of a specific instrument:

• SELECT h.OWNERID, h.OWNERTYPE, h.OWNERADDRESSID, h.ACTIVESTATUS FROM IBY.IBY_INSTRHOLDER h WHERE h.INSTRID = :instr_id AND h.INSTRTYPE = :instr_type;
• To filter only active holder relationships, add AND h.ACTIVESTATUS = 'Y' (or the applicable active value).
• To resolve a credit card instrument to its holder, join IBY_INSTRHOLDER to IBY_CREDITCARD on INSTRID.
• To resolve a bank account instrument, join to IBY_BANKACCT on INSTRID.

Because SECURITY_GROUP_ID is present, queries executed in a multi-org or secured context should respect the active security group. Reporting on holder coverage, duplicate holder assignments, or orphaned instrument-owner relationships is also common, particularly when validating data migrated between 12.1.1 and 12.2.2.

Related Objects

The documented foreign keys identify the principal related objects:

• IBY_CREDITCARD — referenced via IBY_INSTRHOLDER.INSTRID; supplies credit card instrument records.
• IBY_BANKACCT — referenced via IBY_INSTRHOLDER.INSTRID; supplies bank account instrument records.
• FND_SECURITY_GROUPS — referenced via IBY_INSTRHOLDER.SECURITY_GROUP_ID; enforces data access partitioning across the Applications framework.

These relationships confirm that IBY_INSTRHOLDER depends on the instrument definition tables for its INSTRID values and on FND_SECURITY_GROUPS for row-level security, positioning it as the ownership link between instruments and the parties who hold them.