Results for “client_code”

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

Overview

XTR_LINKED_TRANSACTIONS_V is an APPS-owned reporting view within the Oracle E-Business Suite Treasury (XTR) module. It presents a consolidated, de-normalized picture of treasury deals and transactions that have been associated with one another through a deal linking mechanism. Its central purpose is to expose, in a single result set, the relationships between linked deals across several transaction sources, including rollover transactions, standard treasury deals, exposure transactions, and intergroup transfers. The distinguishing column is DEAL_LINKING_CODE, which acts as the correlation key that ties multiple records together as part of the same linked transaction group.

Because the view joins raw treasury transaction data to the descriptive setup tables for deal types and deal subtypes, it surfaces the user-facing classifications (USER_DEAL_TYPE and USER_DEAL_SUBTYPE) rather than only the internal codes. This makes the view suitable for reporting, reconciliation, and downstream integration where a human-readable or code-translated view of linked treasury activity is required. The view is defined as a UNION ALL of several component queries, each drawing from a different transaction source, which is why records for rollovers, deals, exposures, and intergroup transfers can all appear in the same output.

Underlying Base Objects

The documented definition references the following base objects, all owned by APPS:

• XTR_ROLLOVER_TRANSACTIONS_V — source of rollover transactions; the first UNION ALL branch restricts to DEAL_TYPE = 'ONC' with a non-CANCELLED status.
• XTR_DEALS_V — source of standard treasury deals; the second branch excludes DEAL_TYPE values 'ONC' and 'CMF'.
• XTR_EXPOSURE_TRANSACTIONS_V — source of exposure transactions; the third branch requires a populated DEAL_LINK_CODE.
• XTR_INTERGROUP_TRANSFERS — source of intergroup transfer records.
• XTR_DEAL_TYPES — lookup supplying USER_DEAL_TYPE for each DEAL_TYPE.
• XTR_DEAL_SUBTYPES — lookup supplying USER_DEAL_SUBTYPE, joined on both DEAL_TYPE and DEAL_SUBTYPE.
• XTR_USER_ACCESS — package referenced for access control / security filtering.

All branches share a common filter: the deal linking code must be non-null and the record must not be CANCELLED. Each branch is joined to XTR_DEAL_TYPES and XTR_DEAL_SUBTYPES on the composite key of deal type and subtype.

Key Columns

• DEAL_LINKING_CODE — the correlation key identifying the linked group to which a transaction belongs.
• DEAL_NUM — the deal number (aliased from DEAL_NUMBER or DEAL_NO, and populated with 0 in the exposure branch).
• TRANS_NUM — the transaction number within the deal.
• CPARTY_CODE / CLIENT_CODE — counterparty and client identifiers; both are defaulted to blanks in certain branches.
• COMPANY_CODE — the internal company or legal entity.
• DEAL_TYPE and USER_DEAL_TYPE — the internal code and the user-facing deal type description.
• DEAL_SUBTYPE and USER_DEAL_SUBTYPE — the internal code and the user-facing subtype description; USER_DEAL_SUBTYPE is the column most relevant to the search term "user_deal_subtype".
• PRODUCT_TYPE, DEAL_DATE, CURRENCY_BUY, CURRENCY_SELL — deal economics, with CURRENCY_BUY derived from CURRENCY or CURRENCY_BUY depending on source.
• UPDATED_BY, UPDATED_ON — audit columns indicating the last modifying user and timestamp.

Common Use Cases and Queries

A frequent requirement is to report linked treasury transactions by their user-facing subtype. The following query returns all linked, non-cancelled transactions grouped by subtype:

• SELECT DEAL_LINKING_CODE, DEAL_NUM, TRANS_NUM, USER_DEAL_TYPE, USER_DEAL_SUBTYPE, CURRENCY_BUY FROM APPS.XTR_LINKED_TRANSACTIONS_V WHERE USER_DEAL_SUBTYPE = :p_subtype ORDER BY DEAL_LINKING_CODE;

To view every transaction belonging to a single linked group, filter on the linking code:

• SELECT TRANS_NUM, DEAL_TYPE, USER_DEAL_SUBTYPE, DEAL_DATE FROM APPS.XTR_LINKED_TRANSACTIONS_V WHERE DEAL_LINKING_CODE = :p_code;

Reconciliation and audit scenarios benefit from the UPDATED_ON column, for example retrieving all linked transactions modified within a given period:

• SELECT DEAL_LINKING_CODE, DEAL_NUM, UPDATED_BY, UPDATED_ON FROM APPS.XTR_LINKED_TRANSACTIONS_V WHERE UPDATED_ON >= :p_from_date;

Because the UNION ALL composition favors completeness over strict uniqueness, the view is best used for read-only reporting and integration extracts rather than as a transactional source, and callers should account for the possibility of multiple source rows sharing a linking code.