Search Results xtr_limit_types_pk

Overview

XTR_LIMIT_TYPES is a Treasury (XTR) module reference table in Oracle E-Business Suite 12.1.1 and 12.2.2 that stores the master list of limit type definitions available to the Treasury limit management framework. Each row describes a distinct category of exposure limit that the application can track — for example, counterparty limits, settlement limits, or instrument-specific exposure thresholds. The table functions as a lookup or validation source: users select a limit type when defining company-level limits, and the Treasury engine references the same definition when measuring exposure against those limits.

In Data Vault modeling terms, the metadata's heuristic classification suggests this object is hub-leaning. LIMIT_TYPE behaves as a durable business key that is referenced by other tables rather than referencing them, which is characteristic of a hub entity. Analysts designing a warehouse or analytical layer over EBS Treasury data may therefore treat XTR_LIMIT_TYPES as a candidate hub, with descriptive attributes such as NAME carried either on the hub or in a companion satellite depending on the modeling standard in use.

Key Information Stored

The documented physical schema for 12.2.2 shows seven columns. The most significant are:

• LIMIT_TYPE — the business key and primary key column (enforced by XTR_LIMIT_TYPES_PK and reinforced by unique index XTR_LIMIT_TYPES_U1). This is the code stored on dependent transactions and limit records; it is the column most often used in joins.
• NAME — the descriptive label presented to users when selecting or reporting on a limit type.
• FX_INVEST_FUND_TYPE — an attribute linking the limit type to foreign exchange investment fund behavior, indicating that some limit types carry fund-specific semantics used by Treasury FX processing.
• CREATED_BY, CREATED_ON, UPDATED_BY, UPDATED_ON — the standard EBS WHO columns providing audit lineage. These record the application user and timestamp for row creation and last modification, and are essential for audit reporting and for incremental extraction strategies.

The distinction between the surrogate-style primary key and the business-key candidate is minimal here: because LIMIT_TYPE is itself the primary key and the only column in the unique index, it serves simultaneously as the technical identifier and the business identifier. Any data vault or dimensional design should therefore treat LIMIT_TYPE as the stable join key across the Treasury limit schema.

Common Use Cases and Queries

Typical usage centers on validation, lookup joins, and reporting of limit definitions. A common pattern joins the type definition to the company limit assignments:

• Listing all defined limit types with their names for a valueset or LOV validation query: SELECT LIMIT_TYPE, NAME FROM XTR.XTR_LIMIT_TYPES ORDER BY LIMIT_TYPE;
• Resolving the descriptive name for company-level limits: SELECT c.LIMIT_TYPE, t.NAME, c.* FROM XTR.XTR_COMPANY_LIMITS c JOIN XTR.XTR_LIMIT_TYPES t ON c.LIMIT_TYPE = t.LIMIT_TYPE;
• Identifying limit types that are defined but never assigned to a company, by using an outer join or a NOT EXISTS predicate against XTR_COMPANY_LIMITS — useful for periodic configuration cleanup.
• Audit and change tracking, filtering on UPDATED_ON or CREATED_ON to detect newly introduced or recently re-labeled limit types.
• Extraction and integration, where LIMIT_TYPE and NAME are staged into a reference dimension for downstream exposure reporting.

Related Objects

The documented foreign key relationships place XTR_LIMIT_TYPES at the referenced (parent) side of the relationship. The principal dependent objects are:

• XTR_COMPANY_LIMITS — the primary dependent table, joined on XTR_COMPANY_LIMITS.LIMIT_TYPE = XTR_LIMIT_TYPES.LIMIT_TYPE. Company limit records cannot exist without a valid, pre-defined limit type.
• XTR_LIMIT_TYPES_PK and XTR_LIMIT_TYPES_U1 — the primary key constraint and unique index that guarantee uniqueness of LIMIT_TYPE and protect referential integrity for downstream tables.
• Treasury limit maintenance forms and concurrent programs — the EBS user interfaces and batch processes that read this table to populate limit-type selection lists and to validate limit entries.
• WHO column audit infrastructure — the standard EBS audit mechanisms built on CREATED_BY/UPDATED_BY, which govern traceability of changes to limit type definitions.

Because the object is a low-volume reference table, its principal analytical value lies in the descriptive NAME and the join integrity it provides to XTR_COMPANY_LIMITS and the wider Treasury exposure reporting chain.