Results for “xtr_brokerage_categories”

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

Overview

XTR_BROKERAGE_CATEGORIES is a Treasury (XTR) module reference table within Oracle E-Business Suite 12.1.1 and 12.2.2. It stores the alpha-numeric reference values used to classify brokerage relationships associated with Treasury parties. In practice, this table functions as a controlled lookup list: each row defines a valid brokerage category code that can be assigned to a party record elsewhere in the Treasury schema.

Because the table holds a narrow, slowly-changing set of descriptive reference values, a heuristic Data Vault classification would model it as hub-leaning — the primary key BROKERAGE_CATEGORY behaves like a business key (a hub), with DESCRIPTION acting as an attached descriptive attribute. The table is referenced (not referencing) by downstream Treasury entities through two foreign keys, reinforcing its role as a parent lookup in the relational hierarchy. It is owned by the XTR schema and is a VALID, enabled object.

Key Information Stored

The documented physical schema in ETRM 12.2.2 contains two columns. The most important are:

• BROKERAGE_CATEGORY — the primary key and business-key candidate, unique across the table via the XTR_BROKERAGE_CATEGORIES_PK constraint. It holds the alpha-numeric code that identifies a brokerage category, such as a classification used to categorize a Treasury counterparty's brokerage arrangement.
• DESCRIPTION — the human-readable label associated with each brokerage category code, used in validation lists of values (LOVs), form dropdowns, and reports.

Since the primary key is a natural business key (the category code itself) rather than a meaningless surrogate, there is no separate generated surrogate column documented. The PK uniquely enforces the one-code-per-row rule, so every reference from child tables resolves to exactly one category definition.

Common Use Cases and Queries

Typical usage centers on populating selection lists, validating stored category codes, and reporting brokerage relationships by category.

• List of values / dropdowns: Retrieve the ordered category set for a Treasury form field:
  SELECT brokerage_category, description FROM xtr_brokerage_categories ORDER BY brokerage_category;
• Referential validation: Confirm a party's assigned category exists before insert/update.
• Reporting: Join to XTR_PARTY_INFO to count parties per brokerage category, or to identify parties missing a valid category.
• Data-quality audit: Detect orphaned child rows where BROKERAGE_CATEGORY does not resolve to a parent category record.

A sample join pattern: SELECT c.brokerage_category, c.description, COUNT(p.party_id) FROM xtr_brokerage_categories c LEFT JOIN xtr_party_info p ON p.brokerage_category = c.brokerage_category GROUP BY c.brokerage_category, c.description;

Related Objects

Two documented foreign keys reference this table, meaning XTR_BROKERAGE_CATEGORIES acts as the parent lookup for both:

• XTR_PARTY_DEFAULTS.BROKERAGE_CATEGORY → XTR_BROKERAGE_CATEGORIES.BROKERAGE_CATEGORY — records the default brokerage category configured for a Treasury party.
• XTR_PARTY_INFO.BROKERAGE_CATEGORY → XTR_BROKERAGE_CATEGORIES.BROKERAGE_CATEGORY — stores the brokerage classification on the party information record itself.

These relationships establish the category table as a shared reference across party setup and party default data, so changes to a category code propagate in meaning across all Treasury party records that reference it. The child tables should be joined on the shared BROKERAGE_CATEGORY column, and both benefit from foreign-key indexes to keep those lookups efficient.